Wireless Network Coding (WNC) Project
Funlab has created a SDR implementation for experimenting with 802.11 networks. The 802.11 physical layer is implemented using the Nuand BladeRF radio(http://nuand.com/) for the RF front end and an 802.11 physical layer core running on the Altera FPGA onboard the BladeRF platform. The FPGA feeds the physical layer information back to a host computer and takes commands from the host computer through USB 3.0. The MAC layer of 802.11 is implemented on the host computer in two stages. The first stage is the distributed coordinated function stage (DCF).The second stage – upper MAC layer – handles addressing between nodes on the same layer 2 network and transmission of data between these nodes. The block diagram below shows the main functionality of the system:
A current project using the above 802.11 test-bed is a Layer 2.5 implementation of wireless network coding (WNC). A new layer between layers 2 and 3 of the OSI network model is inserted to implement WNC. Layer 2.5 information transfer occurs within a layer 2 network and utilizes information from layer 2 to code information in such a way that the overall throughput of 802.11 is increased. The layer 2.5 system has 2 parts, the access point (AP), and the client (nodes A, B in the figures below). The AP has the job of coding frames together and sending them as a layer 2 broadcast signal.
Funlab’s WNC Testbed
BladeRF spec
The BladeRF is an affordable USB 3.0 Software Defined Radio (SDR) designed to allow students and RF enthusiasts to explore wireless communication, and to provide professionals with a versatile COTS waveform development platform. BladeRF is available for Linux, OSX, and Windows. All host software, firmware, and HDL are released under open source licenses and schematics are freely available. The FPGA and USB peripheral controller are programmable with free vendor-supplied tools and SDKs.
Features
- Frequency range of 300 MHz to 3.8 GHz
- Extendable down to HF/VHF bands with the XB-200 Module
- Independent RX and TX signal paths
- Half or full duplex operation
- Per-channel frequency, sample rate, bandwidth, and gain settings
- Direct access to analog ADC/DAC pins
- USB 3.0 Support
- Cypress FX3 SuperSpeed peripheral controller with integrated ARM926EJ-S
- Backwards compatible with USB 2.0 (with sample rate limitations)
- Up to 28 MHz of instantaneous bandwidth
- Software-selectable filter options from 1.5 MHz to 28 MHz
- Arbitrary sample rates up to 40 MSPS
- 12-bit IQ samples
- Factory Calibrated 1 PPM VCTCXO
- Calibrated within 1 Hz of 38.4 MHz reference
- Altera Cyclone IV FPGA
- 40 kLE or 115 kLE options available for custom signal processing and hardware accelerators
- Fully Customizable
- Expansion port with 32 I/O pins
- JTAG connectors
- SMB connector for MIMO configuration
- Power
- Fully bus powered over USB 3.0
- Optionally powered via external 5V DC jack
IETF Protocol to Access White Space (PAWS) Implementation
PAWS is an application layer protocol that allows use of spectrum for secondary users, and at the same time prevents interference for the primary user. A client device intending to use white space (WS) spectrum uses PAWS to contact the Spectrum database for querying re WS spectrum availability information. The database in turn schedules time of use and channel allocation for the device based on devices’ geo-location and applicable rule sets. From the client perspective, every time it wants to use WS spectrum, it needs to use a method which returns the availabilities of the spectrum as well as a proper power level. The database sends a list of allowed time/frequency/power values to the client to choose from. PAWS also includes other functionalities such as spectrum use notification from client to database. Below is a brief summary of the functionalities supported by PAWS: (bolded parts are required, others are optional)
- Database discovery from master device side
- Initialization from master device side
- Device registration at database side, but it is optional, and it can be implemented as separate component, or as part of Available spectrum query
- Available spectrum query for both master device and database
- Device validation
- Spectrum Use notify at device and database, when database requires it, database lets device knows in its Available spectrum query responses, then device reports its usage later
Headless (stand-alone) Blade-RF
As figure 1 shows, previous system configuration on blade-RF board supported data link and physical layer and was dependent to a host pc. Host pc was part of the system to run network, transport and application layer. In this architecture, Network layer is developed as a part of this system on the host pc, and transport layer is supported by Linux kernel.
Figure 1– System Architecture Dependent to Host PC
Although this system works with a host pc, there are several applications that system needs to work completely standalone. In headless blade-RF project a new architecture will be implemented which provides stand-alone mode for blade-RF. Stand-alone architecture will be used in different applications. As an access point, blade-RF needs to support network layer and this will be in new architecture. The other use of blade-RF boards is in embedded systems design and in these applications, system need to support application layer. In future design, blade-RF architecture will able also to run application layer on board.
Figure 2– Headless System Architecture
