wiki:WiMAXExper

Version 5 (modified by hmussman@bbn.com, 9 years ago) (diff)

--

WiMAX Experiments

1. Mailing Lists

Suggested mailing lists for WiMAX experimenters:
GENI mailing lists, including the dev, discuss and geni-announce lists, plus working groups that cover your interests.
mail to wimax-experimenter@email.orbit-lab.org for experimenters / subscribe / mailman archieve

2. Meetings and Demos

3. Techniques

Standalone Operation using OMF

ORBIT Experiments (getting started)

Tutorial on WiMAX Setup Using OMF

Gautam Bhanage: slides
+ System architecture
+ Control API
+ Use of the VM Grid service to setup an experiment
+ Example scenario

Instrumentation and Measurements using OML

Quick-start tutorial for OML at info

Multiple WiMAX Experiments using Virtualization

4. Experiments by Developers

At the GEC7 meeting on 3/16, Dipankar (Ray) Raychaudhuri led the campus projects in a discussion of research use cases and planned experiments.

Rutgers/WINLAB (1660/1657)

1) Cache and forward architecture; disconnected OK; multi-hop OK; protocol to know when to store, and when to forward; extend to campus users; content library
2) Vehicular; car to car; car to infrastrucutre; geo cache PtoP; protocol to detect cars and then send.
3) Locations service, assuming multiple WiMAX BSs.

Columbia Univ (1770): ?

NYU Poly (1751)

1) Resource allocation with fairness. With physical layer measurements, such as signal-to-noise ratio (SNR) over different sub-channels, optimal resource management can be performed in the MAC layer for SSs at different locations. We will implement several conventional schedulers, e.g., Modified Deficit Round Robin (MDRR) to efficiently support different types of WiMAX traffic flows (UGS, rtPS, nrtPS, Best Effort). This work will focus on maximizing the overall system throughput, while assuring that each SS of predefined fairness in terms of data rate and delay constraint.
2) Cooperative transmission (multihop). One SS (here it may be a second BS or a virtualized second BS) may act as intermediate relay between an end SS and the BS. In the uplink, the relaying SS (second BS or a virtualized second BS) can intercept the signal from the end SS and then forward to the BS. Thus, the single-hop transmission is partitioned into two hops. By implementing and testing this function, we can show the performance enhancement of two-hop delivery over one-hop delivery in terms of either coverage extension or throughput improvement.
3) Cooperative Multicast real-time services. We will study the performance of multicast services in different setup of the testbed. We will measure the PER in different locations and study several schemes for the improvement of the QoS in different groups of stations, including cooperative schemes where particular clients will operate as relays and will forward the multicast streams to groups of stations with poor link quality. Video over wireless schemes will be developed and tested where application layer FEC or/and layered video schemes will be implemented.
4) Rate adaptation. We can test rate adaptation function in the open-source MAC layer driver. In response to the variation of physical layer channel, we can adjust the transmission rate of each SS adaptively such that a certain level of QoS can be guaranteed while the optimal data rate is maintained over time.
5) WiMAX/WiFi interconnection. Based on the fact that in the same Lab we operate a WiFi testbed similar to ORBIT, we are planning to investigate the dynamics of coexisting WiMAX and WiFi testbeds. In particular, we are planning to develop schemes where the clients of the network have two interfaces: one WiMAX and one WiFi. The clients are located relatively close to each other (in the same building) and they receive a video stream from the WiMAX BS. However, each client experiences different video quality due to the different packet errors at different locations. In order to improve the video quality, the clients setup an ad-hoc WiFi network. Each client buffers the video stream and figures our which packets are missing in a particular time window. Then it broadcasts requests to the ad-hoc network asking for the missing packets. Nodes that have those packets, reply by sending them to the node that initiated the process. In this way the wireless nodes recover the packets lost in their WiMAX interface though their WiFi interface.
6) Management of the WiMAX testbed. Since the WiMAX testbed will be used by several researchers in the University we will develop a managerial tool in order to give to researchers remote access and to make available particular parameters for defining and running experiments, collecting the results and monitoring the whole process. 7) Teaching purposes. Finally we are planning to use the WiMAX facility for teaching classes on wireless networks, wireless video applications and for several labs.

UCLA (1797)

1) Vehicular networks
2) Applications: atmospheric science; public health; geo routing; store and forward.

Wisconsin (1724)

1) Internet access, over multipel interfaces and miultiple networks
2) Public emergency services; latency, cost, rate;

UMass Amherst

1) Integrate with current testbeds
2) Provide control over server side.

Colorado (1768): ?

BBN Technologies

1) When is WiMAX useful; ranges and capacities
2) Network management of entire system; utilize clients to measure and send reprots to the site.

5. Demos by Developers

WiMAX Base Station Demo at GEC 6

See WiMAX Base Station Demo at GEC 6, November 17, 2009

This demo included:

WiMAX coverage from Rutgers, WINLAB to an outdoor mobile client, driving in a loop.
Throughput to an indoor mobile client, demonstrating imporved throughput due to traffic shaping.

ParkNet Demo at GEC9

See WiMAX ParkNet Demo at GEC 9, November 3, 2010

"Wirel" Demo at GEC9

This demo combines both WiMAX and OpenFlow elements.

Attachments (1)