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.

wimax arch

 

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.