Successful European Engagement in the IETF: A French early bird (or early fox) in IoT
Interview with Juan Carlos Zuniga, Sigfox - Sigfox was an early bird in IoT, offering sensor networking for agriculture or logistic methods, luring customers with a full-service package – from the sensors to the network. The French company embraced standardisation for data formats early on and found a place in the Internet Engineering Task Force (IETF). Sigfox helped establish the Low Power Wide Area Networks (LPWAN) working group (WG), which is now a very European sphere in the IETF. We speak to Juan Carlos Zuniga, who is responsible for the standardisation efforts at Sigfox.
What is your experience in the IETF? How does it compare to other standards bodies?
At first Sigfox was active in the European Technical Standards Institute (ETSI). There was value there in getting things done, but despite the fact that it is a good, well-known standards organisation, it is very Europe oriented. The idea for Sigfox was to go beyond Europe.
When I joined Sigfox I brought in the IETF and IEEE experience. I was in the IEEE 802 Executive Committee and had been running the IEEE privacy group. IEEE 802 focusses on the silicon layer and technologies like Ethernet and WLAN. Since a number of silicon vendors, including big ones like STMicroelectronics, Silicon Labs or ON Semiconductor, had adopted Sigfox, the ecosystem was there already.
We decided to focus on the IETF, because that is where you are going to standardise the protocol for data going from A to B. We already had interfaces in our cloud that were IETF compatible, such as HTTPS, but we wanted to go one level deeper to allow customers to get more interesting services. IETF is the place for us to get standards for data connectivity.
You and your colleagues recently filed a new IETF draft for a Sigfox profile for the Static Header Compression Protocol [SCHC – pronounced “chic”, author’s remark], tell us what the draft aims to achieve?
Low Power Wide Area Networks (LPWAN) is a new category of IoT. It relates to what is called “massive IoT” in 5G, and means connecting millions and millions of small devices. They do not generate a lot of data and do not generate data consistently, but they are internet connected. That led to a need for RFC 8724 - SCHC.
Talking about IoT we sometimes forget that there are multiple IoTs in the world. At one extreme you have smart cars, you have augmented reality devices and new developments included in high speed 5G. Massive IoT is the other end of the spectrum.
We have tiny packets and there are big delays getting the packets into the internet, and most of the common protocols of the internet do not support this type of communication. Basically, the first thing we did was to elaborate RFC 8376, which defines the LPWAN characteristics and which technologies they apply to. RFC 8376 defines four types of networks that fall into this category. One is our type of network at Sigfox; the second one is LoRaWAN; the third one is NB-IoT, which is cellular and then there is also IoT 802.15.4w of the IEEE.
These networks or radio technologies qualified as candidates for what we wanted to do, ultimately to connect these tiny types of devices to the internet. Our draft specifies our type of network.
The overview in RFC 8376 states that there is no direct connection to the internet, can you explain?
These networks produce information that will eventually make traffic to the internet. So hacking is a common concern with IoT, that you can make these machines do what you want or what you don’t want. Our sensors on the other hand produce information that is received by a base station or a radio gateway and from there it is sent back to a server that collects the information and sends it on to the internet. But it is not a direct connection.
So then you need SCHC to allow for this connection?
So far everyone has been working according to their own recipe, and we thought that if we did it in a standardised way, it would be better for everyone. People that produce services in the cloud and that connect to our networks won’t have to make on version for each technology, so we can increase market adoption through interoperability.
RFC 8724 SCHC describes two functionalities. One is to make sure that one single IP packet can be passed through small chunks. And small chunks, to give you an idea, in our network means a mere 12 bytes. When we talk about sending an IP packet of hundreds of bytes under such constraints, it is a big thing. It is not compression the way we used to think, like ‘let’s make it smaller’. Instead we really have to disassemble the whole thing, make an index, and tell the other side how to reconstruct.
We can then make sure we can pass internet protocols like CoAP [a special format HTTP-like header with fewer elements, designed for constrained environments, author’s remark].
The other functionality is fragmentation. SCHC fragmentation ensures that data is not just dissected into smaller pieces, but also that missing fragments can be opportunistically repeated. That saves you from repeating the whole thing.
We are seeing interest in that mechanism not only to pass internet packets, but also other IoT services like software updates, provisioning the device or reconfiguring it. These are things we have to deal with in real life. Say you have a million devices, and you want to reconfigure half of them. Now you have to communicate with half a million devices spread out in the field and that is not easy. The SCHC protocol lets us achieve those things.
How do you position yourself in the market with the different candidates you described? Are you afraid that other competitors, like LoRaWAN, will take over your early bird advantage?
Not afraid. Indeed, the LoRa community is very active and it is a big community. For instance, LoRA have been using SCHC to pass another protocol, DLMS (Device Language Message Specification) - a protocol for smart meters.
These initiatives are good for the whole LWPAN market. It opens new avenues for Sigfox technology and for the Sigfox network. We will have the flexibility to offer new services from our own cloud. Today these tiny devices often have multi-mode radios, because we operate on the same frequency. Because of SCHC, you can use the same application to connect to a LoRa network or the Sigfox network, depending on where you are, what your use case is, your contract, and if a network exists or the customer decides he wants to use his own network.
Would you say the IETF is still a US dominated body, or is it global?
The IETF has changed over time. What’s good is that the IETF has a very open process. It is run by a community that makes the decisions. Depending on who participates, the decision can shift one way or the other. I think today it has the right balance.
There are more participants from North America, yes, but lately we have seen a huge growth in Asian companies, mainly from China. And then there is the European participation which has always been there. It is a big standards body working on networks, cloud services, applications or platforms. Of course, there are going to be some groups that are dominated by Google and the likes. There are some groups that are dominated by Nokia, Ericsson etc. And in other groups you see more like silicon-oriented companies. Right now it is very mixed, and we try to make sure that it keeps that mix.
There is a Nominations Committee that ensures there is a balance. Officers are nominated so that we can keep a balance between the different regions of the world and the different companies.
How about the balance in LPWAN?
Interestingly in the LPWAN world there is a dominance of European companies. For some reason this whole LPWAN concept was generated mainly in Europe, actually starting in France. Both LoRa and Sigfox come from small French companies, and in addition to Sigfox there is another French start-up, Acklio, which is very active.
Universities in France, Spain and Chile are also participating in LPWAN’s work. After many years in the IETF, in LPWAN it is the first time that I have found myself in a WG that feels dominated by Europeans.
Looking beyond LPWAN, RIOT comes from German universities. These developments probably result from the different private and public-private IoT initiatives in Europe that pushed research in the 5G world.
Research projects in the EU might have given Europe a headstart in IoT. Could this be a blueprint for other areas?
I guess so. My personal view is that we should make use of complementarity. All the top research in networking is taking place in Europe or Asia. As for cloud services, the bigger names certainly are in the US.
But we need both to provide the service, the cloud and the network, so complementarity is one of the big things. Instead to trying to grab the whole cake and compete, we should try to see how we can complement each other. Sigfox has a global cloud, but we are realising that if we have hooks to connect our cloud to Microsoft Azure, Google Cloud or AWS, then customers will have more flexibility. We can still offer GDPR advantages or maybe broadcast advantages. On the other hand, the Googles and Facebooks will know that our network connects well, it has no backdoors (laughs), and that we look like a good partner to work with. For me, it is a matter of ‘what are my strengths’; I should make good use of those and collaborate with people in areas where I am not as efficient.
Should we bring more Europe into the IETF and how?
That would be ideal. We collaborate with a lot with different universities. That is a very good way because often, besides contributing their work to the IETF, universities produce good engineers who will be working in or driving companies.
The academic side is very important. Often universities have incubators for new start-up companies. The start-ups are more agile and can go to new technology faster than bigger, more established companies. The number of European universities that are participating in the IETF in IoT is way higher than from the US. That has a positive effect by raising awareness for IETF standards and bringing more people in. These research initiatives hugely benefit the European market, the IETF and the internet worldwide.