A little while ago, we asked what you thought about the idea of conducting WiFi measurements in RIPE Atlas. After some consideration and community feedback, we now want to propose a way to implement this feature in RIPE Atlas and clarify exactly how these measurements will benefit the RIPE Atlas community.
Background
As we approach 10,000 active probes in the RIPE Atlas network, we've been thinking of how we can expand the network and make it the most beneficial for our users and the wider Internet community. Last November, we wrote a RIPE Labs article that discussed the idea of enabling WiFi measurements using RIPE Atlas probes, an idea that had been discussed by the RIPE Atlas community for some time.
In particular, this was something in which GÉANT , the European data network for the research and education community, had expressed interest. They want to use RIPE Atlas probes to measure the availability of eduroam, their world-wide wireless network developed for the international research and education community, which is used by many universities in more than 75 countries around the world.
We believe there could be other use cases similar to G ÉANT's, and began thinking of the different ways we could enable WiFi measurements, either using existing RIPE Atlas probes or a future version of the hardware. Please see the previous RIPE Labs article for more details about the different options we initially considered, as well as an explanation of exactly what we mean when we talk about WiFi measurements (i.e. measuring WiFi network availability, not using WiFi networks to send measurement data).
Weighing the options
After further consideration, we'd like to propose an experiment that would implement WiFi measurements using G ÉANT as a test case, in order to learn more about exactly what this would mean for us operationally and for RIPE Atlas users.
We did listen to your feedback on the RIPE Atlas mailing list and the RIPE Labs poll that accompanied the previous article, and the majority of people indicated that they want us to enable WiFi measurements on the existing v3 probes for those who opt-in to this feature. However, there are further questions about how to do this, and it's important that we first clarify exactly what will and will not be possible to measure.
We see three main options:
1) Anything goes and we allow any probe to measure any SSID. However, RIPE Atlas probes are explicitly designed *not* to measure local networks because of security and privacy concerns. If they could, then any RIPE Atlas user could collect information about other users' local networks, which is not the purpose of RIPE Atlas (and not something that we believe the vast majority of our users would want!). Even apart from the privacy issues, this isn't very useful, because users would have no information about which probes are connected within the particular SSID they want to measure. This means it will almost certainly not be possible for RIPE Atlas users to measure their own WiFi networks and connectivity.
2) Probe hosts indicate which SSIDs their probe can connect to. Again, we don't think this is very useful, because it relies on probe hosts knowing which networks their probes can connect to and somehow making this known to other probe hosts, either via tagging or some other method. Logistically, we just don't see this being sustainable.
3) The RIPE NCC maintains a whitelist of SSIDs that can be targeted. Although this would make it easier for those wanting to create measurements to know which networks are available as targets, they still wouldn't know which probes are available to perform the measurements within each network.
Although the first scenario involves the most serious security and privacy concerns, it's worth noting that all three of these scenarios involve security and privacy concerns in terms of other users being able to glean information about a probe host's connectivity to different networks as well as their geographical location.
When we talk about enabling WiFi measurements in RIPE Atlas, we therefore think it is only useful to do this for public or shared networks that may be of interest. G ÉANT 's use case fits into this framework nicely; they have a multi-provider, geographically distributed network and are interested in measuring its accessibility from the vantage points of its many users. We also believe this is a great opportunity to place probes in networks that are currently under-represented in RIPE Atlas and will provide valuable data for the entire community. Other organisations may also be interested in measuring the accessibility of their own networks for their own users and, depending on the results of the experiment with G ÉANT , we may make this possible in the future. Of course we will communicate our findings along with criteria about which organisations would be eligible in the future.
The implementation plan
Given all this, we plan to work with G ÉANT to enable WiFi measurements on probes that they will pay for and distribute within their eduroam network. This test case would give us a better understanding of whether it would be feasible and beneficial to offer organisations interested in WiFi measurements the option to purchase RIPE Atlas probes to distribute and install within their own networks so that they can conduct their own WiFi measurements in those networks. In order for these measurements to be useful, most organisations would need a large number of probes - likely up to several hundred. For this reason, and because the measurements will be of special benefit to the organisations themselves, we imagine asking interested organisations to cover the costs of the probes.
This means regular RIPE Atlas users wouldn't be able to conduct their own WiFi measurements. However, the measurements collected by these organisations would still be made publicly available; anyone would be able to access the measurement data from these WiFi networks. In addition, the WiFi probes would still conduct all of the built-in measurements that regular probes do and, as always, this data would be available to everyone. In this way, they would benefit all RIPE Atlas users and the wider Internet community and, hopefully, help RIPE Atlas expand into new networks.
We haven't yet settled on the probe hardware that will conduct the WiFi measurements for this test case, and are looking into various possibilities including using the current v3 probes or sourcing new hardware, but they will certainly have different firmware than the regular RIPE Atlas probes. As with all our developments, we'll keep you updated as things progress.
Feedback
As always, we want to know what you think of this plan, or anything else about RIPE Atlas you'd like to share your thoughts on. Here's how to get in touch:
- Leave a comment about this specific article below
- Subscribe to the RIPE Atlas mailing list for discussions with active users and RIPE Atlas developers: ripe-atlas [at] ripe [dot] net
- If you want to report a bug or problem: atlas [at] ripe [dot] net
Comments 2
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Matthias Šubik •
Adding to the two atlas probes I host, I host a probe for samknows.eu. This probe also measures the volume of wireless traffic around, besides internet bandwidth available and used. I would recommend to at least measure wifi noise with the atlas probes, as this would be very interesting if the noise changes over time, because of neighbouring users shifting to 5GHz, or weather, or mobile users migrating to LTE. Also if there could be a few probes placed in public wifi areas, they could pick up the usage numbers there. I guess you can even say if there is bad weather or good weather, as the usage patterns change. just my two cents. Matthias
Craig Partridge •
If it is easy, I'd also recommend simply capturing the number of WIFI transmissions and WIFI errors (e.g. reading from the local WIFI interface card). This will give you a sense of the quality of the WIFI network -- and I've already got a project going related to the likelihood that a WIFI error will slip past CRC-32, which could be combined with this data to estimate how many errors get past WIFI error checks worldwide...