Changes between Version 173 and Version 174 of WiMAXInteg


Ignore:
Timestamp:
04/20/10 16:09:03 (14 years ago)
Author:
hmussman@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WiMAXInteg

    v173 v174  
    154154[[Image(tablesiteplan.jpg, 60%)]]  [[BR]]
    155155
    156 Each project has been reviewing and updating their plans for research, which will help drive design of kit and software.   See Section 11, "WiMAX Experiments and Demos".
     156Each project has been reviewing and updating their plans for research, which will help drive design of kit and software. See Section 11, "WiMAX Experiments and Demos".  [[BR]]
     157
     158
     159=== Research Use Cases ===
     160
     161Dipankar (Ray) Raychaudhuri on 3/16:  Discussion of research use cases and planned experiments.  [[BR]]
     162Also, send email to Harry, or input on the wiki;  can help drive design of kit and software.  [[BR]]
     163       
     164Rutgers/WINLAB (1660/1657) on 3/16:[[BR]]
     1651)  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]]
     1662)  Vehicular; car to car;  car to infrastrucutre;  geo cache PtoP;  protocol to detect cars and then send.[[BR]]
     1673)  Locations service, assuming multiple WiMAX BSs.[[BR]]
     168
     169Columbia Univ (1770): ?  [[BR]]
     170
     171NYU Poly (1751) on 3/17:[[BR]]
     1721) 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]]
     1732)  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]]
     1743)  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]]
     1754)  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]]
     1765)  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]]
     1776)  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.
     1787)  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]]
     179
     180UCLA (1797) on 3/16:[[BR]]
     1811)  Vehicular networks[[BR]]
     1822)  Applications:  atmospheric science;  public health;  geo routing;  store and forward.[[BR]]
     183 
     184Wisconsin (1724) on 3/16:[[BR]]
     1851)  Internet access, over multipel interfaces and miultiple networks[[BR]]
     1862)  Public emergency services;  latency, cost, rate; [[BR]]
     187 
     188UMass Amherst of 3/16:[[BR]]
     1891)  Integrate with current testbeds[[BR]]
     1902)  Provide control over server side.[[BR]]
     191
     192Colorado (1768):  ? [[BR]]
     193
     194BBN Technologies:[[BR]]
     1951)  When is WiMAX useful;  ranges and capacities[[BR]]
     1962)  Network management of entire system;  utilize clients to measure and send reprots to the site.[[BR]]
    157197
    158198=== 5.3  GENI WiMAX Kits ===