wiki:Documentation/FAQ

Version 26 (modified by Surya Satyavolu, 19 years ago) ( diff )

—

Orbit > FAQ

FAQ

Here you can find the answer to some of the most frequently asked questions about Orbit Testbed. If you cannot find answers in this list, please ask your questions at orbit-user@orbit-lab.org.

The Orbit team is actively seeking new items to add to this list. If you would like to add an item, or have a suggestion on how to make this list more useful, please send us email at faq@orbit-lab.org.

Contents

1   ORBIT Profile

1.1   What types of experiments does ORBIT support?

The ORBIT radio grid emulator is an indoor wireless network testbed. It supports experimental research on a broad range of wireless networking issues and application concepts with various network topologies and network layer protocol options. It also support virtual mobility for mobile network protocol and application research. The ORBIT radio grid emulator currently uses 802.11a/b/g based radio cards. Some examples of systems and protocol designs that can be investigated on the ORBIT Testbed include:

  • Large-scale wireless access networks based on 802.11a/b/g radios along with new protocols for discovery, routing, mobility management, security, etc. under various indoor and outdoor usage scenarios and network topologies.
  • Mobile ad hoc networks (MANET), typically based on 802.11x radios, along with multi-hop ad hoc routing protocols such as AODV, DSR and new protocols.
  • Wireless sensor networks and pervasive computing applications.
  • Mobile applications such as location-based services, VoIP over MANET, mobile multicasting, etc.

In the future, the ORBIT Testbed will support other radio interfaces such as Blootooth, Zigbee, GNU Radio, and allow research on heterogenerous wireless networks. It can also accommodate new technologies such as UWB as they emerge.

1.2   Can I test my new physical layer model on ORBIT?

No. Due to indoor setup constrains, the ORBIT emulator grid does not capture all radio channel effects. The radio channels for the ORBIT Testbed will normally have no significant multipath effects. For physical layer radio testing, the absence of multipath would be unacceptable; however, for a wireless network testbed, the differences are less significant. A combination of channel impairment and multiuser interference results in the failure of the physical layer to provide a reliable link so that connectivity is lost at the network layer. Using programmable interference and grid mobility, the testbed can create similar variations in network connectivity.

1.3   Can I test my new 802.11 MAC scheduling scheme on ORBIT?

Yes and No. The ORBIT radio grid emulator currently uses standard 802.11a/b/g radio interface cards with Linux drivers (Intel IPW2200 and Atheros MADwifi). The drivers allow changing certain parameters such as channel, TX power, TX rate, etc. but not all. We are actively developing our drivers and are in constant contact with the card manufacturers to help expose whatever functionality the hardware is capable of. Stay tuned.

1.4   Do you support AODV?

Yes. We currently support AODV-UU routing protocol implementation version 0.9.1 that runs on kernel 2.6.12. Please refer to http://svn.orbit-lab.org/projects/orbit/wiki/Tutorial/UsingAODV for more details.

1.5   How is the mobility supported by ORBIT?

The ORBIT radio grid emulator support virtual mobility. Virtual mobiles are introduced for discretized grid mobility. Physically located off the radio grid, a virtual mobile has a network driver that delivers packets to a mobility controller. Via high speed wired Ethernet, the mobility controller encapsulates and forwards these packets to a radio grid node i, which simply decapsulates and transmits each packet. In addition, packets received by grid node i will be forwarded via the mobility controller to the virtual mobile. In short, the virtual mobile will appear to be at grid location i by using radio grid node i for transmitting and receiving packets. It will use grid radio node j when it "moves" to grid location j. Grid mobility can support discretized versions of commonly used mobility models such as Brownian motion or the random waypoint model. In addition to virtual grid mobility, we plan on a small number of programmable mobile robots. These mobiles will communicate with the radio grid and allow experimentation with finer grain mobility experiments.

1.6   What radio parameters can I measure?

Currently, RSSI, TX_power, noise, throughput, offered-load, and the number of frame retransmissions can be measured and collected. Users can select one or more of these parameters to be collected and stored in the database.

2   Getting Started

2.1   Who is eligible to use ORBIT?

As ORBIT name (Open-Access Research Testbed for Next-Generation Wireless Networks) says, almost all research or educational uses by those that have a need for it are appropriate and encouraged. These include use by universities, industrial research labs, and both US and non-US institutions. With some provisions, use for product development and evaluation by companies is also acceptable. Please email us if you are interested.

2.2   How do I start a project?

ORBIT is still under development. Please email us if you are interested in doing experiments with the ORBIT testbed. In the future there will be a web interface for the project application.

3   Using the ORBIT Testbed

3.2   Who do I email to request a time slot on a sandbox?

You dont need to email anyone. Just point your browser to: http://www.orbit-lab.org/ and click on Schedule. You will need your orbit username and password.

3.3   When should I reserve a slot and how is slot approval done?

If a user has an unapproved slot that will begin in 10 minutes, (s)he will receive an email stating the slot has been approved, the calendar will be updated to reflect this, and will be granted access to the requested resource.

You should continue to try to plan your experiment slots at least 24hrs in advance to ensure availabilty, and we will continue to approve them. In the event 2 users request the same slot, thereby causing a conflict, we will manually choose (based on a lottery system) who wins the slot. Conflicting slots will not be auto approved. This new addition of automatic slot approvals is mainly for unscheduled and unused slots that people can take advantage of at the last minute.

If at 4am you decide you want to run an experiment and there happens to be no one on the grid, you can go ahead and request the unused 4am slot, which will become approved shortly. There is no guarantee that someone else is not thinking the same thing, thereby causing a conflict, which the scheduler will disregard.

3.4   How do I request any available sandbox?

The reservation schedule will show you all the sandboxes and their availability. Please refer http://svn.orbit-lab.org/projects/orbit/wiki/SandBoxes for more details on the sandboxes.

3.5   Do I get root access on my radio nodes?

Yes. The nodes are yours to do what you will during your slot. Just ssh root@nodeX-Y and be greeted by the familiar root@node:~/# prompt.

3.6   Do my nodes have consoles I can look at?

Yes. Each of the radio nodes has its own serial console with which you can interact through the chasis manager (CM). From the experiment console machine, telnet 10.1.X.Y 3025 in the case of the grid, and telnet 10.1.10N.XXXXYYYY 3025 in the case of the sandbox where N is the sandbox number.

3.7   Can I reboot or power cycle my nodes?

Yes. Each of the radio nodes is independently power controlled by the chasis manager. If your node hangs, or is otherwise unresponsive, you can reboot it. From the console machine, wget -0 - http://repository:5012/cmc/ and use the XML interface to modify the state of your node.

3.8   Are there Linux sources and packages available locally?

Yes. We provide packages mainly for GNU/Debian Linux, but sources are also available that should compile on most distributions. We are also developing software components and libriaries for experiment control, data collection, and application development.

4   Hardware Setup

4.1   How many radio nodes are there?

Currently, we support 64 nodes in a 8*8 grid, and 10 1*2 node sandboxes. In the near future, this will be increased to 400 nodes in a 20*20 grid as well as an outdoor testbed consisting of 50 nodes located in and around Rutgers University, Busch Campus.

4.2   How many radio interfaces on each node?

There are two mini-PCI 802.11 a/b/g interfaces cards on each node. In addition to that, there will be USB-based Bluetooth and Zygbee interfaces.

4.3   Which wireless cards are used on Orbit nodes?

We use Atheros AR5212-based 802.11 a/b/g cards as well as Intel Pro-wireless 2915-based 802.11 a/b/g cards.

4.4   What OS do the nodes run?

The default Operating Systems that run on each of the radio nodes is Linux (Debian GNU/Linux 3.0 with Linux kernel 2.6). But every experimenter can load any OS they want.

4.5   Can I run my own Operating System?

Yes, you can run your own OS (or a customized version of an ORBIT-supported OS) on any of the radio nodes. We provide infrastructure to image the nodes involved in the experiment with the provided OS image.

4.6   Can I load my own software packages on my nodes?

Yes! If have one or more software packages that are appropriate for loading on the OS you have selected, you can arrange to have them loaded automatically via APT package system when your experiment is configured. You may specify a different list of software packages for each radio node in the experiment. When the node first boots after the experiment is configured, each of the packages will be installed.

4.7   How do I access the nodes?

You can log into the node by running the following command from respective console machine
  • ssh root@nodex-y

5   Recent questions from experimenters

5.1   How do you upload your own script onto the sb consoles?

Write the script in your favorite way. Then if you're on a windows box, use any sftp compatible client to upload it to your home dir on gateway (thus your home on console). If you're on a linux box: type 'scp your_new_script.rb username@gateway.orbit-lab.org:folder/you/want/it/to/go/into'

5.2   Do I need to compile the code (or prepare it in any way) before uploading it on the console?

No, Ruby scripts are interpreted by nodehandler. You do not need to compile the script. One way to check for syntax is to use the nodehandler flag -n i.e nodehandler -n <script_name>

This will run the script in debug mode and tell you if there are any syntax errors

5.3   How do we plot this data in an excel spreadsheet? Is there are a way other than manually copying it?

Please read 'Analyzing Measurement Results' section of the tutorial if you have not done it yet. One straightforward way is to use mysqldump to export your DB to comma separated values format, which can be exported into Excel easily. In addition there are a lot of free tools that can do mySQL-to-Excel conversion, such as

MySQL Query Browser http://www.mysql.com/products/tools/query-browser/

MYSQL Front http://www.mysqlfront.de/

MySQL Database 2 Excel KonvertR http://www.churm.com/konvertr/

SQLyog free edition http://www.webyog.com/sqlyog/index_sqlyogfree.php

5.4   Is it possible to set the channel of operation of the 802.11 nodes dynamically or initially?

Both are possible. Please read "ORBIT Specific methods" part of the tutorial to see the properties that you can set for the wireless interfaces on the node:

http://www.orbit-lab.org/userdoc/wiki/Tutorial/HowtoWriteScripts/OrbitRuby

5.6   How do I set the transmit power for the card?

If you are using nodehandler, all you need is to specify node.net.w0.tx_power = value

nodeagent will take care of the underlying commands

If you are running it on your own, then

iwconfig eth2 txpower <-12 to 20> for Intel

echo <power-level> >> /proc/sys/dev/ath0/txpowlimit

The values are from 1 to 100 in milliwatts which translate to 0 to 18dBm (it is clamped at 18 dBm)

On the 64 node grid, I dont think you will be able to achieve isolation even with -12 dBm , you may still need some noise.

5.7   What the physical distance between the nodes on sb9 and those on the main grid?

sb9 is a 64 node grid with dimensions of ~8 m by 8 m. The 400 node main grid is ~20 m by 20 m

5.8   What is the network topology of sb9? Can every node communicate with others directly through the wireless channel?

Using default power levels on the cards, every node can hear everyone else directly (all are one hop). For multihop topologies, we normally use noise injection on sb9. For further details you can refer to the link http://www.orbit-lab.org/userdoc/wiki/Tutorial/UseNoise which will provide a pointer on the kinds of topologies possible with the current noise antenna positions and power levels.

5.9   Where is antenna [4,4]?

For antenna positions refer to http://www.orbit-lab.org/userdoc/wiki/Tutorial/UseNoise. Currently, all four antennas inject noise generated by the Raw Signal Generator uniformly onto the grid. Individual control of power level settings at each antenna will be provided in the next release. The software, however, has the provision to accomodate this.

Hence, [4,4] is equivalent to [1,1] right now and using any one of these in experiment script will cause noise to be injected from all four antennas.

Note: See TracWiki for help on using the wiki.