| | 1 | [[PageOutline]] |
| | 2 | |
| | 3 | |
| | 4 | == 11. WiMAX Experiments and Demos == |
| | 5 | |
| | 6 | |
| | 7 | === 11.1 Experiment Techniques === |
| | 8 | |
| | 9 | ==== Standalone Operation using OMF ==== |
| | 10 | |
| | 11 | [http://www.orbit-lab.org/wiki/HowToGetStarted ORBIT Experiments (getting started)][[BR]] |
| | 12 | |
| | 13 | ==== Tutorial on WiMAX Setup Using OMF ==== |
| | 14 | |
| | 15 | Gautam Bhanage: [http://groups.geni.net/geni/attachment/wiki/Gec7ClusterEAgenda/tutorial%20wimax%20setup%20%20GENI_GEC7_2.ppt slides] [[BR]] |
| | 16 | + System architecture[[BR]] |
| | 17 | + Control API[[BR]] |
| | 18 | + Use of the VM Grid service to setup an experiment[[BR]] |
| | 19 | + Example scenario[[BR]] |
| | 20 | |
| | 21 | |
| | 22 | ==== Instrumentation and Measurements using OML ==== |
| | 23 | |
| | 24 | Quick-start tutorial for OML at [http://omf.mytestbed.net/wiki/oml/Quick_Start_Tutorial info][[BR]] |
| | 25 | |
| | 26 | ==== Multiple WiMAX Experiments using Virtualization ==== |
| | 27 | |
| | 28 | |
| | 29 | === 11.2 Research Use Cases and Planned Experiments === |
| | 30 | |
| | 31 | At the GEC7 meeting on 3/16, Dipankar (Ray) Raychaudhuri led the campus projects in a discussion of research use cases and planned experiments. [[BR]] |
| | 32 | |
| | 33 | ==== Rutgers/WINLAB (1660/1657) ==== |
| | 34 | 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[[BR]] |
| | 35 | 2) Vehicular; car to car; car to infrastrucutre; geo cache PtoP; protocol to detect cars and then send.[[BR]] |
| | 36 | 3) Locations service, assuming multiple WiMAX BSs.[[BR]] |
| | 37 | |
| | 38 | ==== Columbia Univ (1770): ? ==== |
| | 39 | |
| | 40 | ==== NYU Poly (1751) ==== |
| | 41 | 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. [[BR]] |
| | 42 | 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.[[BR]] |
| | 43 | 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. [[BR]] |
| | 44 | 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.[[BR]] |
| | 45 | 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. [[BR]] |
| | 46 | 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. |
| | 47 | 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.[[BR]] |
| | 48 | |
| | 49 | ==== UCLA (1797) ==== |
| | 50 | 1) Vehicular networks[[BR]] |
| | 51 | 2) Applications: atmospheric science; public health; geo routing; store and forward.[[BR]] |
| | 52 | |
| | 53 | ==== Wisconsin (1724) ==== |
| | 54 | 1) Internet access, over multipel interfaces and miultiple networks[[BR]] |
| | 55 | 2) Public emergency services; latency, cost, rate; [[BR]] |
| | 56 | |
| | 57 | ==== UMass Amherst ==== |
| | 58 | 1) Integrate with current testbeds[[BR]] |
| | 59 | 2) Provide control over server side.[[BR]] |
| | 60 | |
| | 61 | ==== Colorado (1768): ? ==== |
| | 62 | |
| | 63 | ==== BBN Technologies ==== |
| | 64 | 1) When is WiMAX useful; ranges and capacities[[BR]] |
| | 65 | 2) Network management of entire system; utilize clients to measure and send reprots to the site.[[BR]] |
| | 66 | |
| | 67 | |
| | 68 | |
| | 69 | === 11.3 Completed Demos === |
| | 70 | |
| | 71 | |
| | 72 | |
| | 73 | ==== GEC6 Demo ==== |
| | 74 | |
| | 75 | See [http://groups.geni.net/geni/attachment/wiki/Gec6Agenda/2009-11-17%20GEC6%20WiMAX%20Demo.pdf "WiMAX Base Station Demo at GEC 6, November 17, 2009"][[BR]] |
| | 76 | |
| | 77 | This demo included: [[BR]] |
| | 78 | WiMAX coverage from Rutgers, WINLAB to an outdoor mobile client, driving in a loop. [[BR]] |
| | 79 | Throughput to an indoor mobile client, demonstrating imporved throughput due to traffic shaping. [[BR]] |
| | 80 | |
| | 81 | |
| | 82 | ==== GEC7 Demo ==== |
| | 83 | |
| | 84 | |
| | 85 | === 11.4 Planned Demos === |
| | 86 | |
| | 87 | ==== Demo Types ==== |
| | 88 | Demo A: Application Deployed on Federated WiMAX Testbeds on Multiple Campuses [[BR]] |
| | 89 | For example: Run Skype video clients on multiple handsets, located on at least three campuses. [[BR]] |
| | 90 | |
| | 91 | Demo R: Research Experiment Utilizing WiMAX Base Station and WiMAX Clients [[BR]] |
| | 92 | |
| | 93 | Demo V: Virtualization of WiMAX Testbeds to Accomodate Applications and Research Experiments [[BR]] |
| | 94 | For example: Simultaneously run Demo A and Demo R [[BR]] |
| | 95 | |
| | 96 | |
| | 97 | |
| | 98 | ==== Demo Plans for GEC8 and GEC9 ==== |
| | 99 | |
| | 100 | Brainstorming and discussion by group at GEC7 meeting on March 16:[[BR]] |
| | 101 | 1) Multi-campus application, e.g, wideband video between handsets; distributed conferencing; video content distribution[[BR]] |
| | 102 | 2) Mobile connectivity: car to car, car to infrastructure via WiMAX[[BR]] |
| | 103 | 3) Portable switch for Layer 2 connectivity; like Sprint mobile hot spot, except Layer 2; client to switch via WiFi, switch to infrastructure via WiMAX; good for campus access.[[BR]] |
| | 104 | 4) Virtualized WiMAX provides emergency slice; adjust network utilization to assure good QoS for emergency slice; reassign to accomplish dynamic provisioning.[[BR]] |
| | 105 | |
| | 106 | Stretch deployment goal discussed by Ivan, Harry and Tony on March 22: [[BR]] |
| | 107 | 1) Rutgers would ship three kits by mid-May to campuses. [[BR]] |
| | 108 | 2) Rutgers (with possible help from BBN) would get four campuses (e.g., Rutgers, BBN, UMass, and ?) setup with outdoor WiMAX systems by June 15. [[BR]] |
| | 109 | 3) Basic multi campus demo could be done by GEC8 [[BR]] |
| | 110 | 4) Extended multi campus demo could be done by GEC9 [[BR]] |
| | 111 | |
| | 112 | Submitted to Mark Berman on March 31: [[BR]] |
| | 113 | 1) Rutgers and Stanford have proposed a "Wirel" demo proposal for GEC9, that combines both WiMAX and OpenFlow elements. [[BR]] |
| | 114 | |
| | 115 | Demo plans for GEC8 and/or GEC9 discussed by Ray, Ivan, Harry, Mark and Tony on April 13: [[BR]] |
| | 116 | 1) Wirel demo is separate, only Rutgers and Stanford. [[BR]] |
| | 117 | 2) Goals for GEC8 demo: [[BR]] |
| | 118 | * WiMAX base station infrastructure is in place on multiple campuses (four?), and operational. [[BR]] |
| | 119 | * WiMAX base station is virtualized, with multiple slices, including (if possible) one multi-site slice. [[BR]] |
| | 120 | * A slice can be configured by an experimenter, including (if possible) downloading code into the slice's VM in the gateway. [[BR]] |
| | 121 | 3) Goals for GEC9 demo: [[BR]] |
| | 122 | * Full WiMAX capabilities. [[BR]] |
| | 123 | * Openness of the API. [[BR]] |
| | 124 | * Multicasting across the country, through multiple sites. [[BR]] |
| | 125 | * Rate adaptation to available bandwidth. [[BR]] |
| | 126 | * Meet the objective for a research experiment.[[BR]] |
| | 127 | 4) Specific demo ideas:[[BR]] |
| | 128 | * Basic video multicast.[[BR]] |
| | 129 | * Extended video multicast, with rate adapted to available bandwidth (under study now, not easy). |
| | 130 | * Multicast of test UDP packets, where measure available downstream rates at multiple sites, via multiple connectivity situations, and report back to measurement archive; might be extended to include available upstream rates; could eventually be used to automatically evaluate a network deployment.[[BR]] |
| | 131 | * Cache and forward, to provide a delay-tolerant network.[[BR]] |
| | 132 | * Use Layer 2 connectivity, but how?[[BR]] |
| | 133 | |
| | 134 | |
| | 135 | === 11.5 Experiment Issues === |
| | 136 | |
| | 137 | |
| | 138 | || No || Issue || Who || Opened || Resolved || Resolution || Note || |
| | 139 | || 11.1 || Establish experiment demo plan: Who will be responsible for each experiment/demo? Can we plan a completion date? || Mussman, Seskar, team, Berman || - || - || - || - || |
| | 140 | || 11.2 || Need to plan tutorial at Rutgers this summer, before GEC8, on getting started with WiMAX || Bhanage || 3/16/10 || - || - || - || |
| | 141 | || 11.3 || - || - || - || - || - || - || |
| | 142 | || 11.4 || - || - || - || - || - || - || |
| | 143 | || 11.5 || - || - || - || - || - || - || |
