11am. IoT.
PETER STEINHAUSER: Right. Good morning everybody and welcome to the IoT working session of this RIPE 89 meeting.
Let's have a quick look at the agenda. So as usual we do a little bit of housekeeping, we have three great talks I think. OK, so housekeeping, just to go through this very quickly, we have the RIPE 88 minutes validation, the minutes have been published on the RIPE website in the working group space. So if you want to, you can have a look, the link is in the presentation as usual.
The code of conduct I mean, be nice. We can fight but we should have manners. Participation in person is clear so after a talk, if you have a question go to the mic, tell your affiliation, your name of course and for the remote participants, we will track the Q and A window in Meetecho, you can type your question there and we will read the question and the presenter then have a chance to answer.
OK, with this I will call up our first presenter, and I think he has a quite interesting real life topic. OK. Do you want to take the mic?
AZIZ SOLTOBAEK: Yes. Thank you. Hi everyone, thanks for attending this plenary session on IoT. We are going to discuss, we are going to move a bit from the theoretical discussions about advanced technologies to practical implementation on the ground and an example of our project that we have been implementing for the last two years an the topic of my preparation is called low cost weather stations and IoT in Kyrgyzstan challenging terrain, my name is Aziz, I am co‑founder of the Internet Society, Krygyzstan Chapter. So we are independent, we are working in the country since 2017.
So briefly, about our project. The project name, this project started two years ago as a part of the research funded by the foundation and the topic of our research was creating an open and secure IoT infrastructure for monitoring and prevent emergencies in mountains countries in the case of Kyrgyzstan.
So the research project is funded by the ISOC foundation grants initiative. We have several partners involved in the project to ensure sustainability in a like full engagement of everyone in this project, first of all it's the internet coat an the crown distinguished from the parties from the Abdus Salam international centre for theoretical physics, UNESCO institution based in Italy, the department of advanced technologies, central Asian institute for applied geosciences, those people who know the ground, all those natural disasters and could provide additional expertise for data interpretation and the use of IoT in the practical sense. The Ministry of emergency situations, which was quite helpful in solving some logistics issue with the practical installation and tackling some bureaucratic issues with the further use of the data, the academy of Sciences of the Kyrgyzstan department. Please meet our distinguished team, you can see here this wonderful gentalman Ermanno and Marco are from ICTP, using wireless technology in Europe, they transmit the data using wifi in a distance of three hundred and something kilometres and that's going to be, this is world record in the and two gentlemen to the left like me and Talant, our chair, and chair of the Kyrgyzstan chapter and co‑founder of the organisation.
First of all I'd like to talk about the importance of vitality of the context of that, there will be some kind of understanding of why we decided to think about it, it's all related, it is related to climate change and specifically central Asia, according to NASA reported by the climate change, central Asian region was the most affected on the, it was the hardest hit by climate crisis was the rise of the temperature as you could see on the screen, that this is actually the region of central Asia which is brown and the research period was actually covering a long period of time, so we see that the central Asia was actually covered ‑‑ affected the most.
And at the same time central Asia is a part of the so‑called third pole, this is the third pole, there's the North Pole, the south pole an the third pole relates to the largest reserve of fresh water outside of the polar regions. These are mountains in Asia that provide water resources for the population of almost two billion people and the Tarim mountains, and yeah, it actually is source for numerous number of the rivers that provide down, that provide the fresh water to downstream countries such as south and central Asian states, including Afghanistan. So there's an effective population of about 125 million people as of 2024.
So with this in mind we should consider the case of Kyrgyzstan, why envisage, you see in the picture, this is a beautiful lake in a high attitude mountains on the altitude of 3,600 metres, this is kind of, this is a boat I was on. So the general terrain of the, the general geography of the country, that 3% of the land is covered by mountains, it's sharply continental climate, it means during the summer times we have temperatures up to 45 degrees and in the winner time, in some areas like temperature goes up to minus 50 and minus 70, in the populated areas the temperatures, the difference between winter and summer is like 50 degrees, it's pretty sharp, not only during the year but also during the day or during the week. So, for example, today we could have a good weather, nice sunny day of 18 degrees celcius and tomorrow it's going to be a minus 5 and snowy and third day it's going to be sunny again. Quite sharp changes in the climate happening and it was the climate change happening, those fluctuations actually started happening more frequently than they used to be.
The average altitude of where we reside is 245 metres above sea level while the average altitude of Kyrgyzstan is 2,750 metres above the sea.
So there's a different kind of atmosphere pressure and different kind of climate change that happens and I feel there's less pressure here, I feel more freedom and comfortable compared to Kyrgyzstan and a bit uncomfortable sometimes.
So we have actually over 2,000 mountain lakes, out of which about 300 ‑‑ 320 of them cause ‑‑ pose a risk of emergency situations. So the mountain lakes can strike massive blow across central Asia, the country has experienced like natural disasters, we could say the number of natural disasters have increased. For example this year by the Ministry of emergency situations, the number of flash floods happened in the country increased up to 600 percent, compared to the last year which was a dramatic increase in the ‑‑ the impact of it to the populations living in the downstream is actually significant.
At the same time the highest temperature registered happened this year. So the country experienced mud flows on a weekly basis, there are incidents associated with mud flows, floods and which accounts for up to one third of all emergencies in the country.
Next slide, so in this kind of geography context, we should consider what the communication situation in the country is. So here in the picture you can see cellular coverage in the country, there's the borders of the Kyrgyzstan and those in pink, the places have we have connectivity, sometimes in the research papers or the kind of country profiles, we could see that 99% of the country actually covered by cellular connectivity which is not true, it's like 99% of the populated areas of the country are covered by the cellular but by mobile connectivity but most of the population reside in less than 7% of the area of the country.
The most of them actually, most of the area covered by mountains.
So it's pretty rough as, pretty rough environment.
That means that, but at the same time despite the fact that people, there's connectivity, most of the natural disasters, the sources of them actually happening closer to the mountains, the mountain news areas which are actually have no kind of communication coverage. So even like satellite connectivity experiences some challenges, for example, there's some kind of remote communities that wish to have some kind of communication and they have been actually thinking about satellite connectivity but due to the cloudy weather, which is like all the time happening there, we are kind of in a valley was low, kind of low kind of solar coverage than the satellite connectivity seems to be kind of not visible in like provision of 100% of the connectivity there.
Bearing this in mind, we should consider the terrain of the topography of Kyrgyzstan. We have just, I just want to present, unlike some countries, we have quite different types of ‑‑ starting from this kind of soil glaciated rocks in higher mountains, it's actually it's an installation at a glacier lake, it's called loamy soil and there's some kind of mud‑related type of soil and rocky soil. So this is kind of geography that affects what we should monitor and measure in order to kind of predict potential sources of the natural disasters in the country.
What we do. So, yeah. We also need to mention that sharp gradient in most of the locations, that means that this is a source for flash floods, the out burst, even the so‑called glacier area lake outburst floodings happening have pretty high type of, the speed of the flood actually is pretty fast compared to the ones that actually happening in more lower altitude countries.
That relates, that also kind of relates to the things that we have been monitoring and we wish to test it now in our project.
So talking about the tools we have been using to note things, to reach also kind of weather stations and some related and other devices that we used in our case, here we can see devices are just second tier weather stations, weather stations actually divided into two categories, there's the first tier weather stations that are classified by the world meetlogical organisations and used in the forecasting of weather and providing weather services. And second tier devices that are actually quite new based on the kinds of new technologies, new advancements that are still kind of on the probe as discussed in the working groups, not yet considered to be kind of full fledged weather stations that there should be relevant in our case.
But it is worth to mention that the cost differs between devices of so here ring coach, solar radiation stuff, data loger, this is a monitor, some other kind of stuff, that's a gateway, compared to the traditional first tier devices the cost of the second tier devices is like ten to twenty times cheaper and they are more affordable and accessible to, than the existing solutions by the existing solutions.
Secondly, one of the parameters that we tried to monitor is soil and and specifically soil moisture and soil moisture temperature and triaxial accelerometer sensors, these are vendors that we consider when we selected out of the range of the dozen existing solutions that we assumed would be suitable to the terrain of Kyrgyzstan and as well as water ultrasound distance sensors provided by, there's a kind of European company that's a new start up and mile sight.
So the next one is the tools that we have been using. It's a communication technology, communication technology relates to LoRaWAN, we used LoRaWAN data transmission technology. In the, LoRaWAN stands for long range wide daily network which collects data from the LoRaWAN enabled sensors and kind of, and sends it to the gateway to the network application through IP protocol.
So, LoRaWAN is quite, the best size of the LoRaWAN, it's low energy consumption and those devices that we actually are using, they are most of the time kind of in a sleep mode and they send data only like about once in ten minutes, this is why they consider it to be low‑energy consumption. So one device that we have been using, you would lost, it would last for ten years probably, for five to ten years as it is claimed and we tested so far, so good.
And this is the protocol that we have been using, there's a traditional protocol, architecture that have been used to consider, end node devices, the LoRaWAN sensors that we have, the LoRa connection protocol that sends data to the gateway an the gateway send data through TCP IP through the network server and server provides data to the application server, our proposed LoRaWAN architecture includes that we need like gateway, etc and it's delay tolerant which are type of the services technology that would help to collect data in a times of the, you know, when, for example, cellular based stations are not working, it collects data and sends and pushes data while there's some kind of connectivity. So that was important case and now we will demonstrate it later in our example.
There's also a disruption tolerant Milesight UG67 gateways and plus there's a telegram developed called botRF for terrain profile, we have been kind of making those pictures, location of the gateway and some the location of the end nodes, there's location of the gateway and location of the nearest cellular stations and that kind of solution was really helpful in order to do a kind of radio planning and building that network in mountainous areas. So based on the elevation we could kind of build this model and make sure it was going to be kind of, what coverage would be provided by LoRaWAN.
The software, we have been using since the topic of our research was actually OpenSource solutions, we have been using different type of ‑‑ we have been using only open solutions, such as Telegraf, influx DB and Grafana, telegraph and MQT T as well as open VPN, Telegraf stands for conversion, MQTT protocols, easy protocols that collects data and sends it and pushes the data through the IoT devices, influx DP is a database that collects the data and Grafana could be used for end users. And we make sure that this architecture is safe, secure, by using open VPN solution, by setting those keys both in the gateways as well as network etc.
Those ‑‑ the data collected here are all available and accessible to everyone, you could access that data and kind of see all the details by all the nodes that we have in locations. So there you go.
Then the pilot locations for to test our and validate our hypothesis, we had selected about five to six, five locations here we could see that they are located nearby Bishkek to make it logisticswise, if there's some kind of disruptions and changes, we need to have some kind of additional calibration of the end nodes, the changes of the location in this instance, to could be easier to access, with that in mind on the first stage we assumed that by testing and verification, we could later on scale up in other areas.
So Bishkek city is right here, the first batch we set up in the Baitik location, this is referenced based where there's a kind of first year meteor weather stations located and used by the Kyrgyzstan hydro meetlogical service and we set up here in order to validate the data, the output of the production and see how credible the output relevant compared to existing solutions. Taty r is a landslide and we have been using triaxial sensors to monitor the moment of the landslide and see how a lot of technology works in different depth of, in different locations so there's the lake, a high mountain lake which is located about 40 kilometres from the city, but if Bishkek is on the altitude of 800m, the lake is 3500 metres, over the last 30 years, there have been two cases when there was outburst lake floods happened, but it happened not to the lake but to the nearby lake and actually it reached Bishkek city in almost one hour; that means the impact of these kind of things and that sensor data time sensitivity is quite critical.
Also we had two installations in the gorge, located like about 180 kilometres from Bishkek city, 200 kilometres, we set up two locations in two spots. It's important to know it's a hollow way connecting to three districts of the country, it's a strategic economic road and we set up on a by site along this road so that because we, the case, in a case of over the last six, seven years, there have the increasing number of the mat /SROEs happening there which led to the close of the road and as well as some kind of communities required or forced to evacuate from these locations. The importance of this location was that the meteor agency had already two other stations located at the entrance to the hallway and at the exit of the hallway and based on those data that they have been collected, they have been assuring there's not going to be any kind of increase or any kind of natural disasters would happen along the road but it turned out climate change and the rise of the temperature ‑‑ due to the climate change, some kind of micro climate started appearing in these locations that we are not observed were existing weather monitoring infrastructure.
In the case of the Tatyr one, we selected one landslide because landslides are usually monitored in a traditional way by manual testing, so they can kind of digging a hole and using piece ometerses and special equipment regularly in order to test whether it's moving or not but over the recent years, we saw that the number of land slides had increased and the traditional approach is quite costly and not affordable and we have thousands of land slides over the country and some of them actually are located close to the communities so we decided to test our IoT devices in those locations.
So we did it, we installed ourselves, you can see we have been doing like digging all of stuff and install these weather stations as well as other devices and the gateway on top of it, our Italian counterparts actually taught us how to do it the proper way in order to carry all the region and based on the experience they conducted in Kyrgyzstan, there's a community of like 70, 80% who already know a lot of the architecture protocols an the way the sensors and IoT devices work and operate using LoRaWAN enabled chips.
The implementation of the Tatyr landslide, the gate located right there and this is our soil moisture sensors that actually dug in different locations, there's quite a sharp gradient and elevation between the location on the gateway and the sensors, probably a few hundred metres, in a distance of several, yeah, a few hundred metres, yeah.
In those devices were dug in a different distance, 30 centimetres, 70 centimetres, one metre below the ground level.
And this was the data that we have been selecting on ‑‑ and we set up triaxial accelerometers, whether there's there were changes in the soil or other things that could be observed. In realtime, it's important to mention this data actually sent every ten minutes, we set up like to make it more energy efficient to be like 30 minutes, once per 30 minutes and we collect this data in the realtime.
So, here's the insight. So insights relate first of all to the weather station that we set up on buy tech station, we have been using open data provided by the weather station vendor... let me... to test the temperature we have been using for the reference purposes calibrated HMP 155 probe, humidity temperature probe, and we checked whether the data that's collected by our sensors actually core rated with the sensors provided by first tier weather stations and we found out ‑‑ it is important to mention that our devices are connected to the gateway and the data transmitted using cellular connectivity while the weather station used by satellite connectivity and with some kind of slight changes in the time adjustments, we had to adjust time for like a few minutes in order to make it a consistent, the data that they have been collecting, and we found out it was the 96% confidence the data are quite like correlated and only like 3% of them, 3%, the majority of the data points are not rejected, and that means it demonstrates the sensor provides accurate reading with a small fraction of outliers.
It is important in terms of the ‑‑ the insight actually is important to ‑‑ the second one actually also proved that there's insight of the second tier, which is first tier weather stations, and you see they all correlated and were similar.
That's very important to consider. And just like ‑‑ just to provide the other distribution, it's pretty small, it's rejected is 3.8% and it is important, this slide and this insight is important in terms of the economic interpretation because, for example, the type of weather stations... the cause of 50,000 while the barane designed weather stations we have been installing or that type of sensors are cost like less than 2,000 so there's quite a gap actually in the price range, that means that price, a lot of ‑‑ an opportunity to do kind of observations in the wider audiences for and having the same data collected.
The next thing demonstrates the insights the received signal strength indicator, that's the way how LoRaWAN works, LoRaWAN actually, so this is RRSI or on the landslide and this device is our soil moisture devices and different distances and interestingly the soil moisture device which is device five, which was located in the furthest from the gateway, like 1.5 kilometres or 1.4 kilometres had actually pretty good, it was actually in the range of RRSI, LoRaWAN technology actually publishes and recognises the signals like above or minus 135 DBM, general it means the devices are quite consistent and LoRaWAN could be used to monitor some kind of underground things, observations.
So, based on the insights, so yeah, based on the insights we have come to several conclusions, we found out as part of the research that we would like to discuss and consider, there's a lot of ‑‑ provides good opportunity to monitor locations with no or low cellular connectivity, it opens a good opportunity to monitor more of the natural disasters with pretty affordable equipment.
Compared to the existing solutions.
Secondly the gateways, it is important for my Italian counterparts and I needed to read it accurately not piss them off, it says gateways built in LoRaWAN servers, local data buffer and automatic retransmission after backhaul failures implement delay tolerant networks, well suited to operate well in extreme weather conditions. It's hard to adjust, consume these kind of things, in a simple example we we could see in the Baitik pilot location there's year, the temperatures actually dropped but, dropped to minus 15 degrees and due to that reason the cellular‑based stations like in nearby locations just stopped operating.
And while the data was still collected by the gateway. And when the connectivity started working, it started sending this data again. So initially we saw that something happened with weather station or with the gateway and we started, we thought since it was like minus 15 degrees and a few days it's going to be plus two, three degrees, we will go and check what happened but the day when the temperature actually increased, it started sending data back already which indicates that that type of gateways and LoRaWAN enabled gateways are quite tolerant to the extreme weather conditions.
It is important to mention that in other areas, well in other locations, the experience similar challenges but continue operating with no disruption due to the extreme weather conditions.
Not only like harsh winter but also to higher temperature peaks that we have been observing this year.
The third point is adoption of second tier weather stations provides an opportunity for monitoring wider audiences with lower budgets. So that's a great opportunity and that's importance of IoT devices here. And fourth is mount news areas that are challenging for communication both wired and wireless, they also offer opportunities for long distance wireless by using high altitude size and leveraging defraction in sharp edges. That means the mountain peaks could be used for, like installation of the gateways an the collecting of the data and transmitting data to the nearby cellular towers could be located a distance of 40 columns terse, 50 kilometres and more.
Soil moisture and temperature sensors using resistant measuring method are not well suited for rocky mount news areas. We saw in our example, we assumed the sensors we procured actually were OK to work in multi‑soil environment but it turned out they are not, we had higher level of some kind of maintenance issues related to the batteries and meaning lots of replacements and we finally found out that the ones that actually are based on the measurement that kind of activity are not or the resistant measurement are not suitable for rocky soil and the loamy soil and should be, we should look for another type of the solutions.
So glaciated rocky loamy soils require special types of sensors, that creates an opportunity for newly customisable design and designed IoT devices. Ultrasound centres for river water level measurement are not suited for mount news highly turbulent rivers in steep gradient terrains. It's important to mention one of the solutions we have been using considered both award winning solution like widely adapted across Europe and actually it works well but when we tried to install it in our country it turned out actually it was actually using ultrasound methodology, it didn't work well because the speed of the river was like faster, it couldn't actually detect and properly register the distance level. We had many disruptions and we had to like adjust the data output to make it like comprehensible.
The last one is massive amount of generated data require machine learning algorithms to analyse and monitor natural disasters. That comes as a feedback from our local partners who well they prefer traditional approaches to monitoring disasters like going once a while or once a month and monitoring and while, when we started installing these devices and collecting data almost ten minutes from each device and they had so much of the data, they had been stuck, this is something that they didn't expect and you know, they started thinking that we had to use some kind of data science approach, data science and AI approaches in order to analyse that type of the data. So thank you. And here's our contact information. You could contact us and learn more about our project. (APPLAUSE.).
PETER STEINHAUSER: So, questions? If there are no questions from the audience here, I have one question from Eric from Cisco ETF and he is asking about the layer one communication is SCHC compression used? It's RFC 9011
AZIZ SOLTOBAEK: I am not sure. I guess. The latest was ‑‑ I am not sure exactly. I just need to check and I will respond later.
PETER STEINHAUSER: OK, that's fine. All right then. Thank you so much. And I will open the stage for Michael Richardson.
MICHAEL RICHARDSON: I have an urge to go to Kyrgyzstan now and I also think that those of you who have rock climbing ambitions need to put that on your resume because clearly that's now an important skill as an IoT internet developer, you need to be able to climb mountains.
And probably sing, I guess.
OK. So hi, I am going to report on a two‑and‑a‑half‑year‑long effort that has been occurring in Washington with about a dozen or so active companies. TR code goes to the slides and stuff like that and I will talk again next week in Dublin probably the same way.
So if you don't know what NIST is, well, there's the people that brought you AES and a lot of the quantam safe stuff lately, I don't work for them by the way. And they have a National Cyber Security Centre of Excellence, which I get wrong, pronounce it the wrong way. And as it says there, their job is basically to kind of accelerate things, make sure that companies are cooperating and communicating and collaborating and to that end in, they write documents and some of them are very detailed and kind of somewhat feel repetitive at times but the idea is to get all the details together and really kind of grill us vendors as to exactly what are you doing and how does it work together and why doesn't it do this and stuff like that.
So, these are the production documents, they are mostly all done, the link to all of them is at the bottom there and they are detailed and some of them are still taking comments I think, so if you do have some questions, if you do read them, then please feed that back to them.
So, what happened. 2020, you know, there was some discussions and rumours about this event will start soon, any day soon, the pandemic certainly stopped and slowed things down a fair bit, which from my point was probably good, in 2020 most of the vendors were not really ready and they have to go through a process where they actually put this federal registry notice, it gives a formal statement to vendors essentially that says we are going to be collaborating with people from industry, don't be surprised if your competitor shows up there and you are weren't paying attention kind of thing.
And that's a real kind of a big deal, I think, from a political point of view.
So after a bunch of calls and stuff, there was a project launch in June 2022. About 30 people showed up in north western Washington DC, you go north of Bethesda, any further out you would probably be in the mountains or something. We put some things there and we have had since then kind of twice monthly collaborator calls about what's going on and who can cooperate with this and that.
And a lot of please review this document, please review this document, these parts are blank, that's parts are still blank, please review these documents.
And in the process we wound up with four bills and I will talk about them in a little bit and we had a build 5 and build 6, build 6 is really the factory provisioning bill, it sort of isn't a build, it's more of an augmentation to all the other ones and this year we are kind of wrapping things up and they have said there's going to be another engineering day in the winter and I don't quite know what will happen there, if it's a please put your equipment day there, kind of a two and a half year long thing.
So who is involved, we had two builds that were involved with the wifi easy connect protocol which is otherwise known as DPPP, the division provisioning protocol, we had Aruba, HPE acquired Aruba awhile ago and what was interesting was that their IoT device that they were onboarding was actually a Wi‑Fi sensor so it would actually tell you as the owner of an Aruba enenabled Wi‑Fi network how well your signal was propagating into the various parts of your network.
So you can imagine that people that care about that and are willing to pay for that probably don't have the skills to actually on board IoT devices, it was kind of useful that it was effectively plug and play.
If you have been to IETF meetings and seen the little Raspberry Pis hiding underneath chairs, that's effectively doing the same thing an that's kind of neat. We had the cable labs thing which was more of a residential kind of effort. And I am going to say I don't actually know a lot about what they did and onboarded at this point, there's a lot of details that kind of get vague.
Notable is that while in theory these two efforts ought to be able to collaborate, in practice that requires engineering skills still on site such that you know, me as effort A and you as effort B, we might need to actually pull up when it doesn't work, we might actually need to pull up things and do things and that's a little bit difficult to do in the depth of a government lab in a room that is not that comfortable to work in an the people aren't necessarily in the right time zones and things like that.
Onwards. So, build 3 was me and I will talk more about that because I actually can talk about it. And so that was a based on B R SK I with the RFC 8995 as published in 2021, that was a complete build top to bottom. Some collaboration with some other things, I am going to talk about that a little bit more. Build 4 was based on the thread protocol, so there's the thread on boarding commissioning mechanism and included some other higher level application layer on boarding up to AWS, OK, so this was this I want to keep on saying Polish but I believe they are a Romanian company, Kudelsky IoT.
And then we had a second new build, build 5, which was another BRSKI bill that came out of N choiring minds and they are more interested in some ways in continuous assurance, to get there they had to build the thing and I am embarrassed to say that build 3 and build 5 have not yet inter operated but it's on the list of things to do.
Then we had this factory provisioning use case. And one of the key things that crossed all of these builds and these processes and IoT on boarding is that every device needed identity and so the question is how do you get that identity in.
If you have to go and touch the devices before you deploy them, that's annoying and it's a highly skilled thing, we really wanted identifies part that come in the device at the factory. Five or six years ago you talk to product managers and you say I want you to put this unique number or thing into your device, they were like oh, my god, that's too expensive, it will never happen and you would point out that well you put Mac addresses into every device, don't you, right, they are all unique, right, and the answer is sometimes no, they are not.
But in theory they do this. And in a couple of cases I actually had conversations with them and with, we work with line managers complaining about this. And I said, well, actually, you are already doing it in your factory and they were like what? I didn't know that. Yeah, well because it's such a normal thing I guess at this point, no one bothers to mention it to you. So it's not as hard as people think but part issue, there's a lot of NDAs around all of this process, one of the push backs and the things is that people say OK, I do the same process for like six different customers but why actually tell the customers it's a common process because and some of them like blue wires and some like green but I can't discuss the fact we'd like to unify it with you know, standard grey ethernet wires because that would violate the NDA so part of the process of this is to create a public document which is these are the publish processes and if you could just pick one of them or your process could be 97% identical to the public one and 3% different, that would make everybody happier and so that was what some of the processes was about.
Is there any questions up to here because this is the high‑level political stuff and I'm happy to stop and take questions about who, what, where, when, why, before I talk more about the technical parts, what we actually did. Anybody? No.
OK. So. This is the high‑level architecture. So the NIST people basically came up with this diagram and there's a couple of revisions back and forth, so tweak some of the wording and we were like what, OK, so for instance the concept part B, send the authorisation service information about devices that the organisation has purchased, how does the manufacturer know how to tell you as, I don't know, Kyrgyzstan, which devices I have actually shipped to you if I haven't shipped them to you because I haven't purchase them yet, they are sitting in a warehouse in Singapore or something, there's some back and forth about that, how does that work and what's going on and is it early binding or late binding for instance.
So that's kind of process, there's A, B, device manufacturer, the device manufacturer may provide information about devices that the organisation has purchased, secure boot, we would all like secure boot, on the other hand, right to repair? So measure boot and we have some back and forth and you know, if the company goes out of business and they secure boot, you are throwing it in the garbage and that's not good, we have many situations recently, anEV vehicle that barely survived, I guess some treadmills and other stuff like this, IoT devices that could have longer life times on the companies that do them and secure boot is one of those double edged swords, would really not not to have malware but to be able to produce alternate software, I think there's a lot of conversation there both within the tech community, within the regulatory community and within the public community and the public interest as to where we are going to do that and so I at least have a lot of pushback on secure boot and say can we do measured boot, specifically the difference has to do with a measured boot system could boot up malware but you would at least know it was broken and you would say ah ha, let's start again and you continue.
So some of the other things, I am not going to read all of the boxes but you can see there's a process, number four devices authorised to be onboarded to the network, that's kind of easy, you know what you purchased, you know whether it should be there but then the other side of it is does the device actually join the correct network. And in Kyrgyzstan I am sure that's pretty easy, there's one network only at the top of the network, it's probably the right one, in Manhattan 27th floor apartment, there's probably 19 Wi‑Fis from your building alone, plus the ones that are reflecting off the glass on the building across the street and the density of Wi‑Fi is extreme and which one should you join and we even had the conversation of could you write out ‑‑ run out of battery trying to join all of them and getting it wrong each time, so there's questions like that. For instance DPP has a beaconing mechanism they put a bloom filter and announced that if your Mac address fits this, I might be your mommy. OK.
So, what does it look like? This diagram you can see the relationship to the previous diagram with a little bit of artistic licence, what goes on, that's the Chirp, the configuration service, there's bloom filter and other stuff about what's going on. They understand DPP, DPP does on boarding by essentially having the provisioning service have knowledge of the devices public key while the private key is private to the device, the public keys is kind of a bearer token, if I know your public key, you will become my device. Do you think that's a bit weird. It is a bit weird but that's why the public keys are not kind of widely published.
You might find them as a QR code on the device. The recent Roomba attacks makes it clear that QR code has to not be in sight of your vacuum cleaner because the cleaner has a video camera that could, you know, look at the QR code and kind of go OK, I know the public key, I can onboard the device. But realistically, it would need an arm as well to go and poke the button that says go back to onboarding mode so probably that's not as realistic an attack as some of us imagine. On the other hand there could be devices which have never been properly onboarded, you bought a smart light bulb, you didn't know it was a smite light bulb, you just used it as a light bulb, when you turn the power on, guess what, light happens, when you turn the power off, guess what, light goes off because there's no power!
And a lot of smart light bulbs will operate this that position even though they haven't joined the network or forgotten their configuration but you could imagine if you could get the QR code off the light bulb somehow without I don't know where it would be but imagine that it's not quite a light bulb, then you may be able to on board it to some other network and control the bulb and a decade ago, we had an interesting conversation at a security workshop, what would happen to the grid if you controlled the million light bulbs and you were to turn them all on and all the gas generators went oh, more power and then three minutes later you turned them off and the gas generators went ahhh and they dump all their spare heat into the river, which is what happens when they go off, and then three minutes later you turn them all on again, OK they go on again and when you turn them off again, the river is already too hot and the generators die. So there's a realistic attack you could do if you controlled millions of light bulbs. And so that is really ‑‑ it's an issue.
Anyway, it's not specific to DPP but DPP has its QR codes but in this architecture, they are not on QR codes, they are provisioned through a supply chain process.
OK. And you see the little picture of the Aruba and they had some Raspberry pies, we struggled with them because they were unable in 2022, couldn't buy them for gold or money or whatever, and it was like, do you have one? Can I have one? Is there a spare? That kind of stuff.
So this is my take on this diagram. And one of the things that about BRSKI is that we do late binding of the device to the supplier and we do this online and it requires the vendor to be present in this device in this service called MASA, manufacturer authorised signing authority, it could be outsourced to someone else, that's how we would get around the thread million andEV vehicles being unavailable afterwards, we would have an escrow process and anyone who worked in a proprietary commercial software facility, you already know your customers insist that you put your source code on a, I don't know, it use to be a tape because that's been years and you give it to a lawyer because they are going to hold onto it in case you die or violate your contract and this would be an additional thing, you put the signing key or trust anchors in that same kind of escrow space and so if you did die, went out of business, that someone else could take over it.
So we have joint proxy, we have EST that gets essentially authorised and then we load a local DEV ID, but it requires a device identity there, if you have questions about this, I am happy to answer them and there's a BRSKI.org you can visit and we have a multitude of slides an presentations and screen casts and stuff like that explaining it all.
Yeah, there we go. OK, this is what my network looked like NCCOE had a room, there was tables and shelves and network jacks across around all of it and essentially what they said was here's your network Jack, you are on VLAN whatever, 103 because I was build number 3, and we are all separated and we are all behind this firewall that V4 and V6, and it was all really cool it did V6 but it turns out it didn't work as well as we like and you needed to ask for certain things, in the case of BRSKI, we have a pledge which is the device that's onboarding, we have a registrar NCC EO offered virtual machines, that's a good idea to help engage in the whole process so I shipped appliancesaa virtual machine rather than bringing a one U server interest and that's how it went and it worked well and then put the MASA was out in the cloud as it effectively should be.
This is a picture of what it looked like. I will tie it down to a piece of plywood literally I measured the inside of my suitcase, cut the plywood to fit, mounted it all in the lab and got on a train to Washington and there you go, on the right hand you see a multi‑port USB hub with buttons that turn power on and off so you can actually reboot machines by taking the power and as many of the machines as possible were powered by USB for that reason and so, in fact, one of the ones that had power controls so I could reach it and tweak the power on and off without going there.
So factory built 6 demo, what did we do. We don't have a factory with an assembly line available there, the question is how are we going to simulate this business where we would, in fact, provision a private public key payer with a certificate or a DPP site into ‑‑ I don't have a pointer, but the black thing you see above the Raspberry Pi is a picture of one of the secure elements. People remotely can see this? It doesn't matter. Anyway.
Anyway. This thing up here is a secure element and the idea was we wanted to be able to put it ‑‑ sorry on this side we want to be able to enroll it into a certification authority and so that was one of the other participants was WISEkey now called seal was heavily involved or a couple of other entitys that were less involved and the idea is instead of actually being able to put it in a factory and doing this work and putting it in a box and shipping it to you, the idea was we would walk the Raspberry Pi from one side of the room to the other side of the room but as part of that process, what we would do is we would put one set of firmware in the device with an SD card, that we know how to do that and might actually have some credentials to the certification authority that says you know actually this is going to be on. Credentials we wouldn't want to ship to the customer because that would be silly. He picks it up, pulls it out, walks it across the room, puts the other card in and it operates and does its thing.
And so we went through that process. Unfortunately the state of software and OpenSource integration for many the secure elements is poor. You may know open SSL went from, I will get it wrong, provider interfaces to engineed interfaces between one and three so some people produced provider interfaces for open SSL 1.00, never updated and so those are useless and didn't have engine interfaces and so you know, attempts were made to use embed TLS with the open SSL wrapper and that didn't work. Other people said, okay, I'm just going to bit bash the I2C bus myself. But then they ran into NDA around the protocol around that, so there's some more significant work to do. We need to converge on some things. PKCS is a possible answer but no one likes that spec and we hate to introduce new things. But you know, that's kind of life.
And I am of the opinion if your device is small enough that maybe you just don't need a secure element to hold the device as a secure element and that's it, the Raspberry level and above, you probably do want a level and it provides interesting opportunities because you can provision your element independently of the different device, you can do it a different factory, one you may be trust more and that was it.
Questions?
PETER STEINHAUSER: Since we have no LEDs, how is the light bulb scenario looking today?
MICHAEL RICHARDSON: Since we have no LED
PETER STEINHAUSER: We had no LEDs.
MICHAEL RICHARDSON: You just need more bulbs or you turn the oven, you know, up to 600 Farenheit, right, let it heat up and turn them all off again or electric furnace or just start the car charging, so OK so there's a whole bunch of different things. You don't even have to have all the same devices, you probably break the grid in a local neighbourhood by just turning on all the car chargers, right, at the same time.
PETER STEINHAUSER: Right.
AUDIENCE SPEAKER: I wanted to ask you about your paw supply strategy for the Rasberry Pi, I have seen the little things with the buttons where you could plug it in so you could turn it off and on, I have tried the same thing and I have ran into issues with the Raspberry Pi cloging down us it's not supplying enough power.
MICHAEL RICHARDSON: I did not power the Raspberry Pi from that device, I used the Raspberry Pi as the gateway to that device, it was plugged into whatever, three ample brick, right, that was for the other devices that were visible, some beagle bone that I happened to have in a junk box NFP, the W30 ‑‑ the what's it called? The ESP32 for that. And in some cases that thing was also the serial console and the whole point was to be able to, you know, debug and reboot it without having to get on a plane to Washington.
AUDIENCE SPEAKER: Right, that answers my question, thank you very much.
MICHAEL RICHARDSON: It turns out there's not every USB hub accurately implements the power control USB things and I brought three of them that said they did it and that was the one I concluded with, there was another one that seemed to work but it was physically just less easy, right? . And it didn't have buttons. That one had buttons, at least I could go ask a human to go, you know, did you turn it off and on, thank you.
AUDIENCE SPEAKER: Thank you.
PETER STEINHAUSER: OK. So we are running a little bit behind time so let's move forward, thank you so much, Michael, for the very interesting presentation. (APPLAUSE.).
OK, so our next speaker is Troy Martin. I tried to promote him to speaker, here we go, Troy, can you hear us.
TROY MARTIN: Yes I can.
PETER STEINHAUSER: Thank you so much for participating. You told me you have to do a hard stop at 12.30 but go ahead.
TROY MARTIN: Thank you for the invitation, yes, I do apologise, I have a flight to run to at 12.30, it starts boarding at 12.25, I will be talking about 802.11 AH ,which is a relatively new IoT standard that's starting to get heavy promotion from various manufacturers and organisations, they are trying to push it into the market place, next slide please.
PETER STEINHAUSER: You should be able to control the slides.
TROY MARTIN: I don't seem to be moving forward when I click next page.
PETER STEINHAUSER: Because I can't, I can't switch the slides. Maybe the colleagues at the back can give us a hand: OK, so we have some technical issues, Troy, that's very unfortunate. Maybe you just can go ahead and since there's not much time, and in the meantime I will try to figure out, OK, we have a video surveillance slide, is that the correct one
TROY MARTIN: It would have been a couple of slides before that.
PETER STEINHAUSER: Yes.
TROY MARTIN: There we go, OK, just a quick introduction of myself, my name is Troy Martin, if you have questions feel free to reach out to me on linked in, there's a QR code you can scan that will take you right to my page. If you happen on on Twitter you can find me there and if you move to the next slide.
PETER STEINHAUSER: Some robots
TROY MARTIN: Yes a quick overview of IoT devices that you can control in a warehouse environment, you could be sending picking information down to the robots so they know where to retrieve inventory from the shelves, a lot of warehouses are currently deployed using either Wi‑Fi for 5G based protocols, 5G is used often if they want to provide greater distance or want to reduce the latency between sending packing instructions, sometimes the systems are controlled for safety purposes to automatically stop moving equipment in case an arm or limb gets put in between some mechanical equipment, so that no humans are injured and make sure your instructions to start or top is it are sent in a timely fashion so you can avoid safety incidents.
If you move forward to the next slide. Another example where you can use IoT deployments would be in warehouse or shipping ports environments where you may be performing video surveillance where the active containers are, where trucks are moving, how boats are positioned, if any containers are been accidentally opened or damaged, you may want to take account for that.
All those IoT sensors meet to backhaul their data, some need little amounts of data, we are talking about one byte, two bytes, if we are tracking things like a door opening or closing streaming relatively high quality video could which require one, four or upwards of 25 megs of throughput for a single cam, if you deployed many cameras around your port or across your warehouses for security purposes, you may need significant bandwidth to back haul that.
We just saw a presentation that focused a lot on 802.15.4, a lot of those technologies are limited to about 250 kill bytes per second, relatively low bandwidth, one of the benefits that we'll see if we move to the next slide, Wi‑Fi halo provides a lot more bandwidth with a reasonable compromise of distance an the ways we do that is which transmitting sub 1 gigahertz. It leverages a lot of concepts that are already familiar and well used with Wi‑Fi, it's based onOF DM which gives it some immunity to noise and interference, built in IP support, it's able to use the existing stack that Wi‑Fi fits into, Wi‑Fi generally operates only layers one and two, everything above that is non‑Wi‑Fi related, if you are having trouble getting to TikTok and you received an IP address, that's not a Wi‑Fi problem, the fact that you got an IP address and received an IP address over CPE, that proves that Wi‑Fi was working, you were able to send some frames across your Wi‑Fi network. From a security perspective, Wi‑Fi halo incorporates the VPN 3, it's generally marketed as a one kilometre technology, although later in the slide deck we'll talk about some speed records that have been set but it generally lands with one kilometre change and do to its sub one gigahertz operation, it's able to penetrate through a lot of obstacles and getting further reach.
A lot of the focus around it was based on preserving energy, sensors that can operate on coincell batteries which allows them to survive with little energy, very few battery upgrades because they may only communicate once an hour or once a day. Reporting back with just several bytes of information, those devices can last for several years before we need to have a battery replaced or come up for servicing.
And because of an open standard, we don't need any propriety hubs for gateways to implement this protocol.
Moving on to the next slide please. This is an overview of the various Wi‑Fi protocols in the stack from IEEE, the Wi‑Fi alliance rebranded them with the intention of making them more simple, but if you look at the sleeve, there's a few glimpse in the numbering sequence, we started off with numbering things with the Wi‑Fi 4, moving up towards we are currently with a standard of Wi‑Fi 6, this year we expect to see the Wi‑Fi 7 fully ratified by the IEEE but there's many many products out there and at the bottom we see Wi‑Fi HaLow sitting there and its sweet spot is delivering reasonable and meaning throughput at long distance, Wi‑Fi 7 is marketed as a technology capable of delivering 46 gig bits of data so your throughput you just keep the maith easy is roughly half of that, not a lot of devices today require sustained 23 gig bits of throughput.
If you are just looking or monitoring IoT devices, having one meg, two megs or even 100 kilobits per second is reasonable for IoT deployment. To put things into relative context in terms of data range versus range, Wi‑Fi HaLow fits in the middle, if you compare it against 802.15.4 or LoRaWAN, Wi‑Fi is typically the three metre range, you compare it to with 4G/5G technologies.
The next slide, here's a relative comparison between 802.11ac and I like to compare these technologies, if you are familiar with 11ac and all the specifications around it with respect to channel width, sub channel widths, Wi‑Fi HaLow is pretty much one‑tenth of that, in Wi‑Fi 11.AC, we have 20, 80, 40, channels as and option, HaLow is one‑tenth of that, we have one, two, four and eight megahertz channels that you can operate on. With one spatial dream you are looking at data rates up to 86 meg bytes per second, very reasonable speeds when you are able to transmit successfully at a distance of one kilometre.
The sub carriers are also one tenth the size and uses very similar modulation or exact same modulation that we have experienced in Wi‑Fi, we are not reinventing anything new. Next slide please.
Here's an example of the frequency channels, the not all vendor are consistent with this, this is for of a proprietary view of different channels we have seen from the HaLow hardware out there, the next slide, this slide here all in green, this is the standard list of channels we find within the 802.11 AH standard itself, the standard and what's possible in the US, we have channel widths from 116 megahertz, there are very few manufactures or hardware available for the full 16 megahertz, which only puts us in a position for one channel but we do see that coming down in the future.
Move to the next slide. Although it looks like there's a lot of channel options in the US, if you compare that to the EU, we only have five one megahertz channels, if he we step up to two megahertz, it gives us two channels that we can use for operation and single so our channel availability globally is not quite the same.
If we go to the next slide. This will show you the perspective of some regions around the world, the size of the frequency bands that they have. You can kind of see that China and US definitely have more spectrum available and other countries have very little so may only be using one or two megahertz for real world production type deployments. Let's jump ahead two slides.
If we start thinking about the speeds and feeds that we have and support for the different channel widths ‑‑ back up, right here, perfect, the little pyramid, see the example of channel widths, if you look at channel support, one and two are mandatory to be supported across all the end devices, all gateways are required to score four megahertz and depending the region you deploy it, you may see optional support for 8 and 16 megahertz, as we go to narrow channel widths, our range increases and not surprisingly as we go to wider channel width, our throughput increases, it's always about balancing these two variables.
If we move to the next slide, this slide here, if you are more curious about the data rates, you can look at this website and there's a tab across the top that talks about theS1G, you can see all the different data rate options that are available based on the spatial streams that are deployed, a handy little reference, it has the other typical or traditional Wi‑Fi data rates you may want to look at. And let's jump ahead two slides.
Let's talk about some cool features built into it, one is the association ID, they have expanded it from traditional Wi‑Fi, if you weren't aware a traditional Wi‑Fi radio at maximum supports 2007 client connections and the reason for that is the way the association ID for unique number that identifies a client connected to access point radio, it's limited in the field to a number between 1 and 2007, right. With Wi‑Fi HaLow because the intention is they are not as chatty, they won't be transmitting as often and when they do transmit, it won't be as much data with increase that association number, all the way up to 8191 and by expanding those fields, we have also coded some of these positions that we can create groups or categories of devices based on page IDs or block indexes or even sub IDs that we can use. If you advance the next slide.
One of the really important benefits or uses of this segregation of different groups is that we can create restricted access windows and in these restricted access windows, we can dedicate time in between the beacons that we reserve for a subset or a subgroup of client devices and this allows us to minimise the contention across the wireless medium, to just a few devices that we can guarantee lower latency in our communications, right, in that little window, that gap in time between the beacons only that subset of device is allowed to communicate. And then this reduces the random access contention problem that we traditionally see in Wi‑Fi.
You just see an image of this, some devices in group one, let's call it, they are assigned to restricted access window one, other devices only will be allowed to communicate in restricted access window two and then any of the other devices they have some purely at the end between the two beacons where they can fight with all the devices to transmit their data, it helps cut down on latency.
And if we move to the next slide, another cool thing we have is target rate time, there's been many iteration was of this, it has evolved through the IEEE standards over time but originally it was proposed as individual target weight time which allowed a client device to negotiate with the access points on eight different schedules or eight different times when it could wake up so it may decide I want to wake up one an hour and give a temperature reading or maybe every 15 minutes, it'll update and let you know if the light bulb is on or off and attackers can decide if that light bulb happens to be drawing a lot of current, it may be one they want to turn off and on and so they can wreak havoc on the power generation system.
Let's move forward a couple of slides to the speed test.
So here's ‑‑ you only want to trust data you have tested yourself, it's not a good idea to trust the ‑‑ what the vendors are telling you necessarily. Here's some testing that I have done with Wi‑Fi HaLow across different channel widths and different configuration examples using a pure open network which is not ideal from a security perspective, using WPA 3 or using multiple stations, it wasn't a controlled test, more of a test in a lab‑ type environment with Raspberry Pis. If we move to the next slide.
Which has an example of packet capture, we can see different information and again because it's all based on Wi‑Fi, if you were to do a packet capture and grab in information inside wire shark, you can look at it and analyse the wire shark filters have a lot of detail built into it itself, if we scroll ahead until we get to the HaLow distance test, there should be one at that talks about 16 kilometres, the second distance test, just recently the Morse micro, the chips that manufacture for HaLow, they perform a test where they were able to run HaLow successfully at 16 kilometres, right, so earlier this year they were able to do three kilometres, recently they were able to push 16 kilometres for their distance and if you move forward a couple of slides, we should see a green and a purple blotch.
One more slide I think.
I did some of my own testing where if we see a grey background, so here's just an example, although we have great distance that we can transmit at, it's great if we talk about just one warehouse. But here's just a relative comparison if we show many warehouses clustered together, each circle represents a radius of about or sorry a diameter of about five hundred metres, with that distance when we start getting every warehouse within a small area of a city or a warehouse type environment, those signals will easily propagate, right, so traditionally what would have been a hundred Wi‑Fi access points deployed as at a way house, because of the distance we can cover, we are able toll deploy a single HaLow gateway across that warehouse that would provide connectivity and may deploy a second one for redundancy purposes if all of our neighbouring warehouses start deploying these, we will quickly exhaust the channels available in that area creating a tremendous amount of interference and noise, right, so Wi‑Fi HaLow, if it's deployed successfully across many different dense environments, may end up being a victim of its own success, we need to look at engineering deployments where we start restricting the trend for power or lining walls on the perimeter of the warehouse and building to limit propagation that egresses outside the warehouse and mitigate interference from your neighbours.
The next couple of slides talk about the available manufactures that have been certified by the Wi‑Fi alliance, there are not many devices at the moment, these are some of the big names of the chips set manufacturers, the Wi‑Fi equivalents would be the broadcoms and the qualcoms, the intel chip sets of the world, not a large number of devices at the moment.
One more slide here, just comparing some various IoT technologies across the different domains. May not be the best comparison because I am not shining a legacy Wi‑Fi in its best light showing 6 gigahertz or Wi‑Fi 7 because it compares and contrasts nicely with Wi‑Fi HaLow, but we can see how it compares against Zigbee or or LoRaWAN.
That wraps up my presentation.
On the next slide there's a QR code again that you can reach out to me via linked in, if you did have any follow‑up questions. Thank you for the invite and thank you for following along with Wi‑Fi HaLow.
PETER STEINHAUSER: Thank you so much Troy. I hope you don't miss your flight!
(APPLAUSE.)
PETER STEINHAUSER: Thank you, enjoy the conference. Thanks everybody. Thank you so much. So I think we skipped the questions for Troy, so he is making it to the flight. Use his LinkedIn contact, he is superresponsive if you have any questions, it was really great working with him.
So we came to the end of our session and I would like to hand over to my co‑chair, Peter Wehrle, who could not join in person but he was following remotely.
PETER WEHRLE: So hello also from Germany and greetings Prague, I hope my audio is properly... it was very interesting presentations and shows how wide the IoT topics and for me the only thing is now is do the closing. I joined the RIPE community as a chair in ‑‑ back in Rotterdam and so now my term ends with the next RIPE meeting. And I just want to make sure so to ask early for volunteers, it's not easy to get all this process done. So I want to encourage you to step up to join the discussion in the working group sessions so that we conveniently can find somebody who wants to step up, as I want to not longer take the term.
So it's very interesting, we'll see also that Peter is running the session perfectly as a co‑chair, just bring in further ideas and I want to really encourage you to bring in new things. And I am stepping down and being a normal member of the group.
As you see in the slides, there's in the meantime a kind of job description what you can do, and also I think Peter can also speak for you, we are always open for discussions, questions. If you have any question, please reach out to us through the mailing group or directly. And I hope we will have a good meeting in Lisbon where you will see us for RIPE 90 and find somebody to continue to do good work here. Thank you very much.
PETER STEINHAUSER: Thank you so much Peter.
(APPLAUSE.)
Before we close the session, I want to give two big thanks.
First of all, to our scribe doing hard work here following up all the different slangs, dialects, etc, it's a tough job I know.
And also for all of you joining our session, thank you so much for being here and I wish you successful RIPE meeting. Thank you so much.
(APPLAUSE.)
