Usage Policy

From CityLab Testbed
Revision as of 13:33, 14 March 2018 by Dvdakker (talk | contribs) (Created page with "Experimenters must comply with the [https://www.fed4fire.eu/terms/ Fed4Fire Umbrella Terms and Conditions] when running experiments on the CityLab Testbed. We're currently al...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Experimenters must comply with the Fed4Fire Umbrella Terms and Conditions when running experiments on the CityLab Testbed. We're currently also working on the Local Terms and Conditions for the CityLab testbed. Once these haver been finalized, experimenters will be required to comply with these as well. In the mean time, we ask all experimenters to effectively behave nicely and use caution and common sense when running experiments.

The main thing to keep in mind is that in contrast to, for example w.iLab-2, the CityLab testbed is not deployed in a fully-isolated playground-environment. Instead, the testbed is deployed in an outdoor city-environment surrounded by wireless devices operating in the same frequency bands using the same wireless technologies. This basically means that when you run experiments on the CityLab testbed you are running them in an uncontrolled and possibly hostile environment. People for instance love connecting to unsecured WiFi access points and there are plenty of amateur-radio enthusiasts around that love tinkering with GNU Radio and a hacked DVB-T dongle. You should therefore take the necessary precautions (e.g.: secure your access points) to prevent people from gaining unauthorized access to the CityLab testbed infrastructure.

To help you along the remainder of this page outlines some of the things to take into account when doing your experiments. If things are not 100% clear or you have a question about this, please don't hesitate to contact us at .

Regulatory Requirements

Since the CityLab testbed is deployed outdoors, you are required to adhere to rules of the BIPT (Belgian Institute for Postal services and Telecommunication) regarding wireless communications. To help you along we've listed some of the regulations below and provided links to others. These are however only intended to guide you along. For a definitive reference of what is and is not allowed you should consult the Frequency Plan of the BIPT.

  • WiFi @2.4GHz & 5GHz: Consult this website for a nice summary (in dutch) of the WiFi-channels & TX Powers you are allowed to use. If you don't speak dutch, you may try the Google Translated version instead.
  • IEEE 802.15.4 @2.4GHz: The same limits as for WiFi @2.4GHz apply. Since IEEE 802.15.4 operates in the same frequencies as WiFi and has a much lower TX-Power (0dBm instead of 20dBm), this should not be a problem.

For 868MHz and 433MHz technologies (this includes IEEE 802.15.4, LoRa and Dash7) the following limits apply:

FrequencyBand Allowed Frequencies Max TX Power Other Limitations

Frequency Band Allowed Frequencies Max TX-Power Max.
Duty Cycle
Additional Requirements
433 MHz 433.05 MHz - 434.04 MHz 10mW (10dBm) 10%
868MHz 863 MHz - 865 MHz 25mW (14dBm) 0.1% Must use CCA (Clear Channel Assessments)
865 MHz - 868.6 MHz 25mW (14dBm) 1% Duty Cycle requirement is waived if CCA is used
868.7 MHz - 869.2 MHz 25mW (14dBm) 0.1% Must use CCA
869.4 MHz - 869.64 MHz 25mW (14dBm) 0.1% Must use CCA
869.7 MHz - 870 MHz 25mW (14dBm) 0.1% Must use CCA

WiFi Testing

The following rules apply when doing WiFi tests on the CityLab testbed:

  • No (Active) WiFi tests in the city campus during the day. Most of the CityLab testbed nodes are deployed at the City Campus of the University of Antwerp. Since this campus also houses around 1000 employees and 10000 students who all rely on a stable WiFi-connection to do their work, active WiFi tests are not allowed during the opening hours of the City Campus' Library. Passive tests (such as background RSSI measurements), that do not require packets to be transmitted are allowed during the day. For active tests, you can use the nodes at the Middelheim Campus to prepare your tests during normal office hours and then schedule your tests to run after-hours on the nodes in the City Campus. Exemptions to this rule may be granted if needed and your experiments won't have too-large an impact on WiFi performance (e.g.: PING-ing is probably fine, iperf's probably aren't.). In either case this is something to be discussed with the CityLab System Administrators before you run your experiments.
  • Secure your WiFi connections'. As discussed above, the CityLab nodes are deployed in an area where every one with a smartphone is able to connect to unsecured WiFi Access Points. To prevent unauthorized access to the CityLab infrastructure you are required to secure all your wireless connections with WPA2 and a secure password. If, for whatever reason, you cannot use encryption for your experiments, contact the CityLab System Administrators(), so we can try to work out an alternative solution.
  • Don't provide Internet Access to external devices. If required for your experiments, you are allowed to connect external devices to the CityLab testbed infrastructure on two conditions:
  1. You must have full control over the devices you connect to theCityLab infrastructure (e.g: your own smartphone/laptop)
  2. You may not under any circumstances allow these devices to access the internet through the testbed infrastructure.
  • No network penetration testing. As discussed in the General Fed4Fire Terms you are not allowed to use the infrastructure for any illegal activity. Just so we're clear on this: that includes 'testing' how secure other WiFi networks in the area are.

Firewall Policy

To prevent any problems resulting from improper use of the CityLab infrastructure on the rest of the University Network, we apply strict filtering on both incoming and outgoing network connections. At this point only the following connections are allowed:

  • Incoming: Ping, SSH
  • Outgoing: Ping, SSH, HTTP, HTTPS, NTP, DNS, FTP

This is by no means a definitive list and more protocols may be added in the future. We also don't mind punching additional holes in the firewall to accommodate your experiments (just so long as you don't ask us to allow Bittorrent traffic). If you do require additional ports to be opened, please send an e-mail to and we'll see what we can do.