WiMAX testbed

The setup NITOS testbed is currently using is a fixed setup (employing no mobility between BSs) that does not require an ASN-GW installation. The overall topology is summarized in the following picture.

For the proper configuration of the BS, the Netspan utility is required, provided by Airspan. Netspan is operating as an integrated service in a Windows Server 2008 box, and allows configuration of both the BS unit and the Service Flow on the WiMAX clients (Subscriber Stations – SSs).  The current setup provides experimentation support with WiMAX enabled clients, using a fixed frequency.

Enabling Experimantation with the WiMAX BS

In order to enable experimentation with the WiMAX BS, the OMF has been employed and some extensions have been added to it, in order to support centralized experimentation over the WiMAX BS. The overall framework consists of two parts:

1. The OMF framework controlling and managing the WiMAX clients, via a RC implementation running on the nodes.
2. A dedicated OMF installation that controls the BS and can set its parameters via REST based API.

Concerning the control and management of the WiMAX nodes, additions to current RCs have been added that feature:

• Loading the appropriate WiMAX driver during experimentation
• Setting up experimentation specific parameters to the WiMAX interface (IP addresses, turning it on, connecting to the BS)
• Wrappers have been written that control the WiMAX utilities that were provided by linuxwimax.com and are integrated in the baseline image of NITOS nodes.

Concerning the connection of the Teltonika modems, a separate OMF driver has been written from scratch, which facilitates the procedure of connecting to the BS since it is not that simple as the other modules. The overall functionality that is provided by the OMF driver is summarized as follows:

• Connecting to network (frequency, bandwidth)
• Disconnecting from currently associated network
• Setting connection options (adaptive MCS, report MCS, ARQ, etc.)
• IP address and netmask
  • If DHCP, will get IP address automatically. BUT, you may need to find out what this IP address is, to run fixip script. And you cannot access it directly from the node.
  • If no DHCP available, you need to set a static IP. Again, this presents a problem, because you cannot do it directly on the node.
  • Either way, use telnet libraries for Ruby to communicate with the icc0 interface, which is the actual WiMAX interface.

Apart from the first two additions (loading the driver, setting up addresses etc.), that are rather straightforward as we prepared an altered version based on the existing implementation over the WiFi experimentation, the wrappers provide an interface to OMF to control resources using the wimaxcu application. The application can control the WiMAX interface, turn hardware and software radios on/off, connect the interface to a BS, scan for existing BSs etc.

Regarding the second OMF installation that controls the BS, a dedicated OMF service has been adopted, in cooperation with NICTA and the RUTGERS University, New Jersey, who developed it, that is called wimaxrf. The extensions were based on an existing implementation that was designed to run over a WiMAX BS provided by NEC that has been adopted by the GENI project in United States.  However, several core extensions needed to be made, due to hardware incompatibilities. The overall extensions have been wrapped up as an OMF Aggregate manager service, and are provided as Open Source code.

The wimaxrf service can perform the operation of setting up experimentation properties of the BS, such as the BS operating frequency (in the 2.53-2.63 GHz bands), ARQ, HARQ etc.

As an addition to the wimaxrf service, a click installation has been employed, that is used to setup the experimentation datapath. The datapath concerns whether the nodes are going to have connection to the Internet over the WiMAX interface or just communicate with each other. The service has been designed in a way that a connection over the GEANT network will be able to be used in the future.

Every time that the BS is configured from the experimenter, a click instance is started, and according to the datapath profile that the experimenter has selected, sets up the appropriate bridges and tunnels for communication with the Airspan BS. All the communication between the wimaxrf host and the BS is performed via GRE tunnel interfaces, one for the Uplink and one for the Downlink. The new setup is depicted in the following picture.

You can continue to NITOS Portal for experimentation on WiMAX resources.

Indoor RF Isolated Testbed

 The NITOS RF Isolated Indoor Deployment consists of 50 Icarus nodes that feature multiple wireless interfaces (Wi-Fi, WiMAX, LTE) and is deployed in an isolated environment at a University of Thessaly's campus building. Experimenters are able to run and evaluate power demanding processing algorithms and protocols in a large scale testbed. It is also equipped with directional antennas and other advanced prototypes.

The Icarus nodes are placed in a symmetrical way around the isolated environment of NITOS indoor testbed forming a grid topology. The distance amongst the nodes is fixed to 1.2 meters and the height level is identical for all them as well. As a result, a uniform environment is created where all nodes are isobaric and of equal capabilities. You can find below a picture of the topology of the NITOS indoor testbed.

Outdoor Testbed

NITOS Outdoor deployment consists of powerful nodes that feature multiple wireless interfaces and allow for experimentation with heterogeneous (Wi-Fi, WiMAX, LTE) wireless technologies. It is deployed at the exterior of a University of Thessaly (UTH) campus building, as illustrated in the following figure and consists of 50 powerful nodes.

 The nodes are deployed all over the roof of the building, 25 of them in a grid topology and 25 of them spread accross the building's floors, as you can see in the topology image above.