RENEW Project Documentation

Version 1.0

Reconfigurable Ecosystem for Next-generation End-to-end Wireless

Current Capabilities & Roadmap

Current Platform Capabilities and Functional Blocks

The RENEW team has developed a set of tools (in Python/Matlab/C++) for users to get started using the platform, as well as a set of basic functional blocks (FPGA implementations) that enable their operation. Here’s a list of the main features currently supported by the platform:

Current Platform Capabilities

PYTHON (Non-realtime)

  • SISO Simple TX/RX: Continuous or one-shot SISO transmission/reception of a sinusoid or a wideband training sequence.
  • SISO OFDM TX/RX: Continuous or one shot transmission/reception of WiFi-like signal comprised of preamble and payload.
  • SISO TDD TX/RX: Transmission/reception of a signal by using a pre-defined scheduled (Relies on TDD Framer functional block).
  • Massive MIMO Receiver: Post-processing of pilots and data collected by massive MIMO base station using Sounder framework.
  • MIMO Beamsweep: Generate a beacon at base station and perform a beamsweep of the beacon.

C++ (Non-realtime)

  • Sounder: Capture

Matlab (Non-realtime)

  • OFDM SISO, MIMO, and SIMO: One shot transmission/reception of OFDM signals in different antenna configurations.
  • Massive MIMO Simulation: Basic simulation code of a massive MIMO system (No hardware, mostly for basic prototyping and proof of concept).

Here you can find a more detailed description of each tool.

Functional Blocks

Functional blocks are mainly implemented in the FPGA layer, however, these are configured and used by the host application through the middleware (described above). Below, we describe existing functional blocks in details and will refer to them in the rest of this documentation. In the RENEWLab section, we provide details on how these blocks can be configured and used in the RENEWLab exisiting code and how they can be used for writing new applications by the users. Note that depending on the role of the Iris device, some of the functional blocks may or may not be available on each Iris. More specifically, each Iris is either in the FAROS massive MIMO base station (BS-Iris) or used as a standalone client (Client-Iris). Below we specify which blocks are available for which role.

Note that, the list of these blocks will grow over time as more functionalities will be developed by the RENEW team.

Time Division Duplex (TDD) Framer

Each Iris implements a TDD framer at the FPGA level. Based on a user-defined frame schedule, the framer logic switches the radio mode between TX or RX mode with sample accurate timing. The framer divides time in frames. Each frame is further divided into subframes (interchangably called symbols, although each subframe can contain multiple OFDM symbols). During each subframe, the radio can either be in TX or RX mode. We define 5 subframe types, each handled in a different way:

  • i) Beacon (B) (BS-Iris role only): In every frame, the BS-Iris node transmits a beacon signal subrame B. The BS-Iris stores this signal in its FPGA block-RAM. Notice that the block-RAM can be preloaded by the host app.
  • ii) Pilot (P) Transmit: A pilot signal is transmitted from an FPGA block-RAM in this subframe type, in every frame. The block-RAM can be preloaded by the host app. This subframe type is supported by both BS-Iris and Client-Iris roles.
  • iii) Data Transmit (T): Samples streamed from host app using Soapy writeStream function are transmitted in this subframe. For example, a sine wave can be generated in a python application and “streamed” to the Iris board to be transmitted during the T subframe slot.
  • iv) Receive (R): Samples received from the radio in this subframe are streamed to host app and read through readStream function.
  • v) Guard Interval (G): In this subframe type, the radio is technically in RX mode, but nothing is streamed in this subframe by the FPGA to the host app. The purpose of this subframe is to enable flexible allocation of subframes and provide antenna orthogonality, or to provide support for TX/RX switching of the radio. Depending on the type of front-end used on Iris, the switch between TX and RX mode varies. For BRS/CBRS front-ends, this switching takes approximately 18 mircoseconds. The user is recommended to have a guard subframe when a switch from TX to RX occurs. As will be explained below, in the case of a Client-Iris, a subframe in which over-the-air synchronization occurs should be specified as G subframe.

In the figure below we present a schedule where a BS-Iris initially transmits a beacon (B) to Client-Iris. With the Client-Iris set to G during this subframe, the device uses the over-the-air sync mechanism mentioned above to detect the Beacon. In turn, the Client-Iris then sends a Pilot in P subframe after a Guard interval G subframe. Finally the BS-Iris transmits data in three T subframes with guard intervals subframes in between them. The schedule for each Iris is represented with a string. For example, the BS-Iris in the figure below will have to be configured with the string BGRGGGGGTGTGTGGG. Similarly, the Client-Iris schedule will be GGPGGGGGRGRGRGGG.

The TDD framer can be dynamically configured to enable operation in a user-defined manner. Below are a few parameters for the TDD framer configuration:

  • Frame mode: TDD framer can have 3 different modes.
    1. Free running: After the current frame ends, the Framer starts the next frame immediately. The first frame starts via a trigger.
    2. Triggered : Each individual frame requires a trigger to start.
    3. Continuous Resync: This is a combination of free running and triggered mode. By default, it behaves like free running, but if receives a trigger in the middle of the frame, it restarts the current frame. This mode is usually used in Client-Iris where synchronization of frames with BS-Irises is needed.
  • Max Frame: The maximum number of frames the framer counts. When it is reached, it will stop.
  • Symbol size : The number of baseband samples in each symbol (interchangably subframe) within a frame.
  • Frame Schedule : An array of strings including the letters BGPTR (described above) that defines the subframe types in each frame. The length of the string determines the number of subframes in a frame. A maximum number of 16 different schedules (strings) can be defined. So up tp every 16 consecutive frames will follow the corresponding schedule defined in the array. Although in most cases, only 1 schedule is used.
  • Beacon Start: A beacon signal can be smaller in number of samples than a full subframe. This parameters defines, which offset within a subframe B, the beacon transmission should start.
  • Beacon Stop: Similar to “beacon start”, this parameter defines which offset within a subframe B the beacon transmission should stop.
  • Dual Pilot: The framer can be configured to include two different pilots P in each frame. This is particularly for the case when sending two orthogonal pilots from each antenna on an Iris is needed.

Beacon Beamsweeper

The purpose of beacon beamsweeping in massive MIMO is to increase the range of beacon signals to reach the clients in the field. The reason is, beacons in general are supposed to be used by clients for cell discovery and initial attachment. Since prior to the attachment, there is no channel state information (CSI) available from the client for the base station to do closed-loop beamforming, it instead uses open-loop beamforming. That means it uses a codebook to sweep beacons in different directions. For more information on the concept, see this paper.

Beacon beamsweeping functionality is built into BS-Iris nodes. The number of beams is equal to the number of antennas (M) in the base station. To generate the beams, a distinct sequence of hadamard codes (with a length M) is loaded into each BS-Iris in Faros. Each BS-Iris multiplies the beacon signal with consecutive hadamard codes in the loaded sequence during consecutive frames. The superposition of hadamard-coded beacons transmitted by all antennas in Faros, will generate a beam in a different direction in every frame. In other words, in every M frames, M different beams are transmitted. The maximum beamforming gain achieved by beamsweeping is M2. For the beamsweeping operation to work properly, the hadamard sequences and the beacon signals must be loaded into their designated block-RAMs in the BS-Iris FPGA. Later in this documentation, we show how this will be done using SoapySDR function calls.

In the figure below we illustrate the operation of the beacon beamsweep.

Client Synchronization Block

Client-Irises include a beacon detection block in their FPGA logic. The beacon detection block includes time-domain correlation logic as well as adaptive thresholding logic which enables time synchrnization of the Client-Irises with the Faros base station, over-the-air. The beacon detection block output is a trigger signal that is tied to the TDD framer (described above) that can resynchronize the TDD framer at the Client-Iris whenever a new beacon is detected.

Note, there is a relatively fixed delay (at least in stationary clients) between the time the BS-Iris transmits the beacon and the time Client-Iris detects. That delay includes the RF path delay (BS-Iris and Client-Iris analog front-end path, and the time of flight) and the beacon detection processing delay. This delay offset can be calibrated by advancing the time in the Client-Iris.

Later in the documentation, we describe how this can be done using a SoapySDR function call.

Automatic Gain Control (AGC)

Automatic Gain Control is needed to adjust the received signal power to fall within a certain range. In particular, if the signal power is above this range, it could lead to saturation of the ADC (Analog-to-Digital Converter). On the other hand, if the signal power is below this range it could lead to ADC quantization errors. The received signal power can be adjusted by changing the settings on the amplifiers and attenuators present on the RF frontend and LMS7 transceiver chip. We have implemented an AGC block that includes a finite state machine (FSM), at the FPGA level. The AGC operates on Client-Iris boards. In the context of the TDD framer, upon detection of a beacon B the Client-Iris triggers the AGC process which attempts to fit the signal within a user-adjustable target range. This block automatically selects the best possible settings for all gain stages. After the entire frame is finished, the AGC block resets all gains to their default initial value. Notice the AGC is disabled by default but can be easily enabled as shown in the tutorials.

Transmit Power Control

While AGC is used in every legacy receiver, in massive MIMO where multiple clients transmit simultaneously to the Base Station, their different power levels become an issue when trying to demultiplex the signals. To solve this problem we rely on transmit power control at the Client-Iris devices. Currently we have a very simple implementation that works with the TDD framer, which adapts the transmitter gains across multiple frames . That is, if enabled, this mechanism will continuously increase the transmit gain at every consecutive frame. Based on pilot reception success at the BS-Irises, users can then select the most appropriate gain value. We are currently developing a more versatile power control mechanism, which will be available in the next couple of months.

Roadmap

Last updated on 30 Apr 2020 / Published on 12 Feb 2019