640 | | ==== R3.1) Airspan Installation Instructions ==== |
641 | | |
642 | | [http://wimax.orbit-lab.org/wiki/WiMAX/01b link] [[BR]] |
643 | | |
644 | | |
645 | | |
646 | | |
647 | | === R4) WiMAX Site Configuration === |
648 | | |
649 | | |
650 | | ==== R4.1) Updated WiMAX RF AggMgr for NEC Base Station ==== |
651 | | |
652 | | |
653 | | ==== R4.2) WiMAX RF AggMgr for Airspan Base Station ==== |
654 | | |
655 | | |
656 | | ==== R4.3) Adding OMF/OML Configuration ==== |
657 | | |
658 | | |
659 | | ==== R4.4) GIMI I&M Tool Set to Cover WiMAX Sites ==== |
660 | | |
661 | | |
662 | | ==== R4.5) Adding Login Service for Remote Users ==== |
663 | | |
664 | | |
665 | | ==== R4.6) Federating with ProtoGENI Cluster ==== |
666 | | |
667 | | |
668 | | ==== R4.7) Adding "Yellow Node" with WiFi Access Point, for Dual-homed Experiments ==== |
669 | | |
670 | | |
671 | | ==== R4.8) Adding Mobility/Handover Functions ==== |
672 | | Moderator: Parmesh Ramanathan (Wisconsin) [[BR]] |
673 | | |
674 | | Projects requiring handover include: Clemson, Wayne State and Wisconsin. [[BR]] |
675 | | Projects that can contribute handover technology include: Rutgers WINLAB and Wisconsin. [[BR]] |
676 | | Also, commercial handover technology available from Airspan. (Gregg Tome (Airspan)) [[BR]] |
677 | | Process to find a good solution? [[BR]] |
678 | | |
679 | | [ slides] [[BR]] |
680 | | |
681 | | === R5) Connecting WiMAX Site to Backbone Network === |
682 | | |
683 | | |
684 | | === R6) Mobile Station Platforms === |
685 | | |
686 | | |
687 | | ==== R6.1) Fixed Mobile Station using "Yellow Node" ==== |
688 | | |
689 | | |
690 | | ==== R6.2) Roaming Mobile Station using Linux Netbook ==== |
691 | | |
692 | | ==== R6.3) Linux driver for Teltonika modem ==== |
693 | | |
694 | | ==== R6.4) Roaming Mobile Station using Android Handset ==== |
| 635 | |
| 636 | j) Airspan installation instructions [http://wimax.orbit-lab.org/wiki/WiMAX/01b link] [[BR]] |
| 637 | |
702 | | === R8) Spectrum Survey Experiment === |
703 | | |
704 | | |
705 | | === R9) Throughput Experiment Using iperf === |
706 | | |
707 | | Manu Gosain (GPO) and Harry Mussman (GPO) [[BR]] |
708 | | |
709 | | Overview of basic throughput experiment, using bidirectional iperf, both TCP and UDP [[BR]] |
710 | | [http://groups.geni.net/geni/wiki/OMFWiMAXExperiments#GENIWiMAXExperimentsUsingOMFOML Basic throughput experiment using OMF/OML] [[BR]] |
711 | | |
712 | | The basic throughput experiments we have done utilize iperf, both TCP and UDP. [[BR]] |
713 | | In iperf, the data is generated in the client, and flows to the server. [[BR]] |
714 | | We put the client in the Mobile Station, and the server in the Base Station. [[BR]] |
715 | | We used -d dualtest (bidirectional mode), where test is initiated at the client, data begins to flow to the server, and then a second data flow starts at the server; at the end of the test, results are available at the client. [[BR]] |
716 | | Because of this, all tests can be initiated at the Mobile Station, and then results are available there. [[BR]] |
717 | | |
718 | | iperf results in the TCP mode depend upon buffer sizes; overall delay; and lost packets. [[BR]] |
719 | | Because of wireless propagation conditions, lost packets are common, and slight changes can significantly affect the measured throughput. [[BR]] |
720 | | Thus, TCP results are highly variable; we took multiple measurements at each point, and identified the best and worst results. [[BR]] |
721 | | It would certainly be good to have a better way to evaluate available channel bandwidth. [[BR]] |
722 | | On the other hand, most apps use TCP and the variable results are typical of how these apps would see the channel. [[BR]] |
723 | | |
724 | | iperf results in the UDP mode, counts % packets received, for a given (fixed) transmit rate. [[BR]] |
725 | | If the rate is set below the available bandwidth, typically 100% of the packets are received. [[BR]] |
726 | | If the rate is set above the available bandwidth, typically % of the packets are received typically equals available bandwidth divided by offered bandwidth, but there is no way to understand how many packets are actually lost. [[BR]] |
727 | | An extended test that ramped up the offered bandwidth in multiple tests, could actually verify the available bandwidth; this could then be repeated to see real variations in available bandwidth. [[BR]] |
728 | | |
729 | | References: [[BR]] |
730 | | [http://groups.geni.net/geni/attachment/wiki/GEC12WiMaxDeploymentAndExperimentation/201007-JT_Iperf.pptx iperf tutorial slides] [[BR]] |
731 | | [http://openmaniak.com/iperf.php iperf tutorial web site][[BR]] |
732 | | |
733 | | === R10) Throughput Experiment Using Bit Torrent === |
734 | | |
735 | | Fraida Fund (NYU Poly) [[BR]] |
736 | | |
737 | | [http://groups.geni.net/geni/attachment/wiki/GEC12WiMaxDeploymentAndExperimentation/NYU-Poly-WiMAX-BT-Experiment.pdf slides] [[BR]] |
738 | | |
739 | | Overview of throughput experiment, using bit torrent. [[BR]] |
740 | | Advantages [[BR]] |
741 | | |
742 | | [http://groups.geni.net/geni/attachment/wiki/GEC12WiMaxDeploymentAndExperimentation/NYU-Poly-WiMAX-BT-Experiment.pdf Reference] [[BR]] |
743 | | [http://witestlab.poly.edu/index.php/wimax/field-measurements.html More information & source code] [[BR]] |
744 | | [http://witestlab.poly.edu/index.php/component/user/?task=register Use the NYU-Poly WiMAX testbed] [[BR]] |
745 | | |
746 | | |
747 | | === R11) Raw IP and UDP Traffic Generators === |
748 | | |
749 | | Surat (Au) Teerapittayanon (MIT) [[BR]] |
750 | | |
751 | | Overview of new raw IP and UDP traffic generators, to accurately gauge available channel bandwidth. [[BR]] |
752 | | [http://groups.geni.net/geni/attachment/wiki/GEC12WiMaxDeploymentAndExperimentation/GEC12Slides_plusreadme.ppt slides] [[BR]] |
753 | | |
754 | | === R12) Using OMF and OML in Your Experiment === |
755 | | |
756 | | Christoph Dwertmann (NICTA) [[BR]] |
757 | | |
758 | | [http://groups.geni.net/geni/attachment/wiki/GEC12WiMaxDeploymentAndExperimentation/omf-gec10%20copy.pdf slides] [[BR]] |
759 | | |
760 | | [http://groups.geni.net/geni/wiki/OMFWiMAXExperiments#GENIWiMAXExperimentsUsingOMFOML Basic throughput experiment using OMF/OML] [[BR]] |
761 | | |
762 | | OML'ified apps we know of include:[[BR]] |
763 | | gpslogger[[BR]] |
764 | | Iperf[[BR]] |
765 | | omf_nmetrics[[BR]] |
766 | | omf_trace[[BR]] |
767 | | otg and otr[[BR]] |
768 | | wlanconfig_oml[[BR]] |
769 | | Yantt (Yet another network testing tool)[[BR]] |
770 | | SNMP wrapper[[BR]] |
771 | | |
772 | | [http://oml.mytestbed.net/projects/omlapp/wiki Repository for OML'ified apps] [[BR]] |
773 | | |
774 | | List of available modules with OMF and OML for use in your experiment [[BR]] |
775 | | Approach for adding OMF and OML interfaces to additional modules [[BR]] |
776 | | |
777 | | === R13) Remote Experiments === |
| 645 | |
832 | | === 2.3) Updated/new WiMAX RF AggMgr === |
833 | | 3:20pm [[br]] |
834 | | Ivan Seskar (Rutgers WINLAB) |
835 | | |
836 | | * Have updated WiMAX RF AggMgr for NEC base station to 2.5.3+; additional updates coming [[BR]] |
837 | | * Need to feed management data to centralized DB at WINLAB, for GENI-wide monitoring [[BR]] |
838 | | * Possible access to Clearwire, others. [[BR]] |
839 | | * Coming: New WiMAX RF AggMgr for Airspan base station [[BR]] |
840 | | * Plan first version by GEC15 |
841 | | |
842 | | |
843 | | === 2.4) Add mobility/handover functions === |
844 | | 3:25pm [[BR]] |
845 | | Parmesh Ramanathan (Wisconsin) [[BR]] |
846 | | |
847 | | * Projects requiring handover include: Clemson, Wayne State and Wisconsin. [[BR]] |
848 | | * Projects that can contribute handover technology include: Rutgers WINLAB and Wisconsin. [[BR]] |
849 | | * Also, commercial handover technology available from Airspan. (Gregg Tome (Airspan)) [[BR]] |
850 | | |
851 | | * Parmesh reports: student has started on process to find a good solution, will report at GEC15 [[BR]] |
852 | | |
853 | | |
854 | | === 2.5) Add "yellow nodes" to WiMAX Sites, as WiFi access points and fixed "mobile stations" === |
855 | | 3:35pm [[BR]] |
856 | | Ivan Seskar (WINLAB) [[BR]] |
857 | | |
858 | | * These are "yellow nodes", introduced in ORBIT testbed [[BR]] |
859 | | * Can be used as: fixed nodes; WiFi access points; fixed "mobile stations" [[BR]] |
860 | | * Currently used by: Rutgers WINLAB; NYU Poly; BBN [[BR]] |
861 | | |
862 | | * How can these be provided to sites? [[BR]] |
863 | | * Approximate cost: $800 - $1500 [[BR]] |
864 | | * Rutgers WINLAB has parts list, has been assembling [[BR]] |
865 | | * Need to poll sites for interest; then work up a plan. [[BR]] |
| 700 | |
| 701 | |
951 | | === 2.8) Roaming Mobile Station using Android Handset === |
952 | | 3:50pm [[BR]] |
953 | | Harry Mussman (GPO)[[BR]] |
954 | | |
955 | | * Summary of discussions with Sprint about unlocked HTC Evo handset [[BR]] |
956 | | * Must be unlocked by Sprint, so can register with GENI network [BR]] |
957 | | * Perhaps: 500 handsets, purchased by Rutgers WINLAB, approx $500 per handset, and distributed to sites [[BR]] |
958 | | * Harry reports: waiting for 3-way NDA to be signed, so that we can resume discussions with Sprint [[BR]] |
959 | | * Need to poll sites for interest [[BR]] |
960 | | |
961 | | |
962 | | * Also possible: Sprint MVNO arrangement for pay-as-you-go data service [[BR]] |
963 | | * Harry reports: waiting for 3-way NDA to be signed, so that we can resume discussions with Sprint [[BR]] |
964 | | * Need to poll sites for interest [[BR]] |
965 | | |
966 | | * Comments from Matt Sanders (Georgia Tech), who attended the WiMAX meeting [[BR]] |
967 | | * Along with other jobs, he reports to the CTO, and is campus wireless services manager. [[BR]] |
968 | | * He has extensive experience negotiating with carriers (and I believe Sprint). [[BR]] |
969 | | * We talked for some time, and he agreed to advise us as we continue our discussions with Sprint. [[BR]] |
970 | | |
971 | | * His comments: [[BR]] |
972 | | * 1) Sprint has multiple approaches to dealing with “enterprise customers”. One approach we might consider, for 3G/4G service: “Access Point Node” (APN), where designated mobile stations (typically associated with an enterprise) are assigned certain IP addresses, so that their traffic can be routed directly to the enterprise. (This is likely to be in a different business unit that the MVNO approach) [[BR]] |
973 | | * 2) Matt has a contact at HTC. He feels that they might well be willing to make a batch of Evos for us. We would have to talk with them to understand the minimum quantity. |
974 | | |
975 | | |