|Version 94 (modified by 7 years ago) ( diff ),|
Orbit > FAQ
Here you can find the answer to some of the most frequently asked questions about Orbit Testbed. If you have a question not in this list, please send your query to email@example.com.
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 firstname.lastname@example.org.
- 1 ORBIT Profile
- 2 Getting Started
- 3 Using the ORBIT Testbed
- 3.1 Is there a tutorial?
- 3.2 Who do I email to request a time slot on a sandbox?
- 3.3 When should I reserve a slot and how is slot approval done?
- 3.4 How do I request any available sandbox?
- 3.5 How do I access the grid or any sandboxes?
- 3.6 Do I get root access on my radio nodes?
- 3.7 Do my nodes have consoles I can look at?
- 3.8 Can I reboot or power cycle my nodes?
- 3.9 Is the ORBIT testbed firewalled?
- 3.10 How do I find out what hardware is attached to a node?
- 4 Hardware Setup
- 5 Software Questions
- 5.1 What OS do the nodes run?
- 5.2 Can I run my own Operating System?
- 5.3 Can I load my own software packages on my nodes?
- 5.4 How do I install software on the nodes?
- 5.5 Are there Linux sources and packages available locally?
- 5.6 How do I save an image of a node?
- 5.7 How do I image nodes with my own custom image?
- 5.8 How many images can I have? Do they get purged?
- 5.9 How do I access the nodes?
- 6 Recent questions from experimenters
- 6.1 How do you upload your own script onto the sb consoles?
- 6.2 I dont understand the prototype definition and application definition?
- 6.3 Do I need to compile the code (or prepare it in any way) before uploading it on the console?
- 6.4 How do we plot this data in an excel spreadsheet? Is there a way other than manually copying it?
- 6.5 Is it possible to set the channel of operation of the 802.11 nodes dynamically or initially?
- 6.6 How do I set the rate to a fixed value?
- 6.7 How do I set the transmit power for the card?
- 6.8 What the physical distance between the nodes on the main grid?
- 6.9 Is multihop possible on the grid?
- 6.10 Where is antenna [4,4]?
- 7 NodeHandler
- 8 Spectrum Related Issues
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.
ORBIT is short for Open-Access Research Testbed for Next-Generation Wireless Networks. Being an Open-Access Research Testbed, almost all research and educational uses by those with a need are appropriate and encouraged to participate. These include uses by universities, industry research labs, and both US and non-US institutions. With some provisions, use for product development and evaluation by commercial entities is also encouraged. Please email us at email@example.com if you are interested.
ORBIT is still under development. Please email us if you are interested in doing experiments with the ORBIT testbed and we can help you get started. Until then, take a look at the Tutorial.
Log in to http://www.orbit-lab.org/. There is a form to change your password and mailing list settings on the "Account" tab under "Preferences".
You can choose to "unsubscribe" from the mailing list . You can accomplish this by logging into the orbit webiste and "Preferences" option will appear just above the top menu bar on Orbit web page, choose "Account" and set your mailing list membership to "none".
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.
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.
Yes. We currently support AODV-UU routing protocol implementation version 0.9.1 that runs on kernel 2.6.12. Please refer to HowTo for more details.
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.
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.
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.
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 who wins the slot based on utilization over the last two weeks. 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.
The reservation schedule will show you all the sandboxes and their availability. Please refer SandBoxes for more details on the sandboxes.
Users can (and should) access respective consoles directly (i.e. you don't need intermediate ssh to gateway anymore); you still DO have to reserve respective resource in order to gain access during your time slot. You will need to setup up ssk keys, see: Documentation/SSHKeys.
Access to gateway.orbit-lab.org is not controlled by the scheduler and should be always available.
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.
Yes. Each of the radio nodes has its own serial console with which you can interact through the chasis manager (CM). The interaction method is different for the the different versions of CM. For newer versions of CM (3 and older) you can telnet directly to the CM and you will be connected to the serial console. For the older versions your telnet session must connect to port 3025. The CM's are named consX-Y.domain, where X,Y are the "coordinates" of the node you are trying to reach, and domain is the resource you reserved (ie. grid, sandbox1, etc..)
Sandbox 1 (node1-1) - telnet cons1-1.sb1.orbit-lab.org 3025 - Serial console of node1-1
Sandbox 5 (node1-1) - telnet cons1-1.sb5.orbit-lab.org - Serial console of node1-1
grid (node1-1) - telnet cons1-1.grid.orbit-lab.org - Serial console of node1-1
The nodes must be turned on in order to be able to telnet.
Yes. Each of the radio nodes is independently power controlled by the chassis manager. If your node hangs, or is otherwise unresponsive, you can reboot it. The preferable way to do perform such operations is given here Tutorial/HowToSwitch.
Yes. The nodes do not have direct access to the Internet. However, the machine used for initial login, "gateway.orbit-lab.org", does. The consoles are also open for direct access from outside. e.g in order to access console for sandbox2, use '''ssh firstname.lastname@example.org'''. Since your home directory on gateway is also accessible via the testbed consoles, it is possible to upload and download from the Internet on "gateway.orbit-lab.org" and copy files to your nodes from the testbed console.
The status can be used to determine what hardware is located on a specific node. More information can be found here: Software/bAM/jStatus .
Currently, we support 400 nodes in a 20*20 grid, and 10 1*2 node sandboxes. In the near future, this will also include an outdoor testbed consisting of up to 50 nodes located in and around Rutgers University, Busch Campus.
There are two mini-PCI 802.11 a/b/g interfaces cards on each node. In addition to that there are many USB-based Bluetooth, Zygbee and other interfaces. See the Status page for a complete list.
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. Nodes with x+y = even are Intel nodes where as x+y= odd are Atheros nodes.e.g node1-1 = Intel, node1-2 = Atheros and so on. NOTE: This applies only to sb9 (64 node grid). For the main grid, check IntelNodes.
The default Operating Systems that run on each of the radio nodes is Ubuntu 12.04 (from the baseline image). But every experimenter can load any OS they want.
Yes, you can install your own OS (or a customized version of an ORBIT-supported OS) on any of the radio nodes. We provide infrastructure to image the node in an experiment with any experimenter provided OS. For further information, go to Documentation/BuildingCustomOS
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 when you configure your experiment. You may specify a different list of software packages for each radio node in the experiment. There are no restrictions on what you put on the nodes.
This is a broad question. During your slot, the nodes are yours to do what you will, right down to the OS. If the experimenter requires his/her own OS, then installation of software is carried out using methods appropriate for that particular OS. There are no restrictions as to what/how software is installed on the node. The ORBIT development team recommends Debian GNU/Linux as the OS of choice for experimenting on the grid, but as is mentioned above, there are no restrictions. NOTE: Please be aware that we have not had the opportunity to develop our software for and experiment with other OSes and may not be able to answer your questions regarding them.
If you would like to use the ORBIT supplied baseline images, which are based on Debian GNU/Linux, then software is installed via the APT system (http://www.debian.org/doc/user-manuals#apt-howto). The testbeds have access to a local Debian mirror which is updated nightly. Anything available on the global Debian mirrors is locally accessible on orbit via the local Debian mirror.
Also, the baseline image has all of the normal Linux build components installed. You are more than welcome to compile from source and use your software through those mechanisms.
Yes. We provide packages mainly for GNU/Ubuntu Linux, but sources are also available that should compile on most distributions.
If you've modified the baseline, or even installed your own OS on a node, you can take a snapshot of the node's disk. The resulting image can be used on other nodes during your experiment and reused during other slots. To save a node's disk as an image issue the following command on the experiment console (NOT THE NODE'S SERIAL CONSOLE):
- email@example.com: omf save -n nodeX-Y.domain
where X and Y are the node's coordinates. The image will be named in the form username-node-fqdn-date.ndz and will be displayed in a status message during the save process. Please keep track of the image name as you will need to supply it during imaging.
ORBIT keeps your images on the machine named repository1 in the /export/omf/omf-images directory. They are considered temporary images unless you claim them by moving them to image repository with:
- mv username-node-fqdn-date.ndz ../your-active-image-name.ndz
Please bear in mind that the ORBIT software components (i.e. nodehandler/nodeagent, libmac, otr/otg, oml, and wireless drivers) are under constant development. The baseline image is continually updated with the latest stable releases of these components. If you are going to use your own derivative of the baseline and you use these components, may need to update these packages manually. Please watch the orbit-user mail list for development related news. More information can be found at this page: HowTo/HowToSave
You can image the nodes you need with your image using the following command from the "console" machine
- firstname.lastname@example.org: omf load -t topology -i imagename.ndz
Loading images is covered the the tutorial on node images located ...
You are encouraged to keep only your active image (and may be a couple more test images) under repository2:/export/orbit/image/ directory. repository2:/export/orbit/image/tmp folder is really temporary and it is provided for your convenience. You have to change both the image file names and their owners to yourself before copying to /export/orbit/images (from tmp) to claim them. Also, copying them to your local computer is always a good idea. Since it is impossible to keep too many claimed images, given hundreds of users of ORBIT, please keep them at a minimum number, deleting unnecessary old ones as appropriate. For now, unclaimed image files with unmodified names (nodeX-Y*.ndz owned by nobody:nogroup) that stayed unmodified for more than 5 months are deleted automatically in case the designated disk runs out of space. However, this policy might change in the future, should the disk space management need tighter control over the number and size of images a user can keep on our servers.
- You can log into the node by running the following command from respective console machine
- ssh root@nodex-y
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 email@example.com:folder/you/want/it/to/go/into'
The main idea is that for every new application, you create a Ruby class (called application definition) examples are otg.rb, otf.rb etc. These classes define all the properties of this application such as 1) What are the inputs it expects? 2) What are the measurements that it reports
The prototype is a particular subclass (if you will) that is bound to the particular application E.g sender.rb is the prototype that uses the underlying application defined in otg.rb..
Sender.rb may have different additional measurement options such as time-based or sample based filtering..(whereas the generic application definition otg.rb only specifies what it can report)
The experiment script (tutorial.rb) uses the prototype (instance of the prototype)
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
6.4 How do we plot this data in an excel spreadsheet? Is there 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
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: Tutorial/HowtoWriteScripts/OrbitRuby
node.net.w0.rate = '1M'
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.
The 400 node main grid is ~20 m by 20 m. Node separation is 1m.
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 or MAC filtering. For further details you can refer to the link HowTo/UseNoise which will provide a pointer on the kinds of topologies possible with the current noise antenna positions and power levels.
For antenna positions refer to HowTo/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.
- Our software is still under heavy development and bug fixes are being applied every day. To help us find the source of your issue,
- Please try to reproduce the problem on your own. If it is not reproduceable, save the experiment ID of your failed attempt in an email (with a brief description) to the user list.
- Try a smaller set of nodes. If a node in your group consistently throws errors, leave it out and use another. Email the coordinates of the deffective node to the user list with the experiment ID of the incomplete imaging procedure.