During Sigfox Connect 2019 we had different announcement like ultra-low power devices and ultra-low-cost IoT devices with a BOM under a single $. There are the main announcement in my point of view but we have also had much more coming with updates on previously seen technologies.

At first Sigfox announced the ability to deploy a private network, we are going to see what it could means as the details have not yet been given. Next I’ve got update on satellites connectivity and bubble service announced last year.

Sigfox growth

We were waiting for a string signal on network use growth and in my point of view this was a major announcement at connect that year. This did not buzz a lot but it sounds important to notice it first: Sigfox registered device growth has been 457% from last year. They have announced 16.000.000 registered devices end of  2019, this must be compared to 3.500.000 on 2018 end and 2.200.000 on 2017. Remember the June 2019 IHS prediction at 12.000.000… that 25% error, well done. That’s also the first time Sigfox is giving connection number instead of deal signed quantities.

Sigfox is now processing 22.000.000 messages per day with a 10% growth per month.

During the event, Unabiz & Soracom have announced a big deal with NiciGas a Japan gaz company to deploy in the next 6 month 850.000 connected gaz counter. Congratulation guys ! 

I would say Summer is coming on IoT !

Sigfox as a private network

This as been the most relayed announcement by press even if in my point of view this is a non interesting information. By the way, it buzz because it’s an opposite direction than the one previously taken by the network operator.

By making this now possible, Sigfox is looking at LoRaWan market, breaking the existing boundaries between networks. This is an offensive market approach and, in my opinion, the first time they are offensive against LoRaWan. They were more defensive against the traditional operator attacks running this kind of network.

What is the interest of a private network in a customer point of view still seems mysterious to me as I’ve already been detailed it. It’s like expecting to get from the national electricity company to get its own production unit… so 1900’th. By-the-way, LoRaWan shown there is a market for this. It’s a market of integrated solution provider.

Solution provider are proposing a global solution in their business problem. It is including devices, network gateways, kernel network and back-end/front-end service. Thank to this integrated approach the are able to get value from any of the chain element and getting a higher value for themself with a price globally lower until you count on a public operator. They are eliminating the service sandwich.

This market rely on LoRaWan as this technology has been made for having numerous private networks (even if not exclusively).

That’s something I do not understand, but private company or even public administration really loves to own their network. I assume it’s a question of maturity and even if you don’t know why you do it, you can say “I made my own trendy IoT network” (aka I’m an innovator).

So that’s a fact and Sigfox was pushed back from some maket due to its public operator position.

That time is now over and the IoT Network operator is now looking for new horizons.

What will be the private offering is still not detailed but basically it means sigfox will deploy base-station dedicated to certain companies or specific areas. The client will pay on basestation deployment for a given device volume range. These basestations may not relay public devices and private devices may not be relayed by public base-stations based on option you have choosen.

So, what seems so bad to me is this is the limitation created instead of getting better things. In a conventional approach, when you add a new base-station on a private site, it serves any objects on the network, it is a plus for all.  With a private base-station, you are just filtering and trashing valid messages because you do not want to share your infrastructure. That’s also so 1980’th. I don’t blame Sigfox for this, I just blame market & customers.

Once you get your own filtered gateways, you signal will go to a network kernel. For Sigfox, like for LoRaWan, you generally not implement and manage. A network kernel, is generally an instance located on a cloud operated by specialists. I don’t know currently how this part will be managed. Currently the backend is already secured and customer isolated environment. At SaaS age you may not have a dedicated instance of this.

The way it will be implemented is also important: if mutualized with public devices you will be to easily access to any sigfox devices. If the instance is dedicated, accessing vertical services could be more complicated as the service provider do not expect customer to control the communication layer and the integration with service provider back/front could be more complex. So let’s see the details when precised.

To conclude, my hope on this offering is the following: by having the ability to make private network, new market will be open to Sigfox. During deployment customers and solution integrators will have a deeper look on different cost model and finally retain the public option and, may-be, the discussion will be more on bundle based communication price instead of per device fee… like in a private network cost model approach.

Point I did not mention… we do not do private network for security or confidentiality, that’s radio protocol and SaaS hosted network kernel, in 2020, another approach makes no-sense. So you rely on encryption for confidentiality, not on private stuff.

ELO Satellite coverage

Announced a year ago, the Sigfox satellite launch was planed this winter but it has been postponed due to satellite launching planning congestion. We will need to wait a new year before knowing what we can expect from a satellite coverage. That said, new things are known about the future devices ability to communicate over Sigfox. The first satellite will cover the whole hearth about 1 time every 2 days. It will emit a beacon at 4xxMHz. So devices will wait on that beacon to identify the satellite approach.

The tricky part will be to wait for the sat to be on top of the device to made the transmission. The objective is to be in a better position than any other devices. With a vertical position, the satellite may receives this signal a bit higher than the environment noise generated by the large number of devices around. A fleet of 30 satellites could later offer a global coverage with a possible 1:30 transmission period. This could be the right balance but it will depends on future use-cases.

Satellites really make sense for covering oceans and deserts where the noise is low, emitting from a city could be a challenge but the previously defined method could work for outdoor messages. An indoor message will have a too important loss to pass over the noise in a such environment.

The good news is: you will not need specific antenna design or specific transmission. Any Sigfox device could be captured by a satellite. The use of patch antenna (directional) directed to space can be interesting at condition the device is correctly oriented at anytime. Otherwise it could be a handicap. So a omni directional antenna could be the best choice for most of the use-cases.

There will be a lot of learning once the first Sigfox base-station will be on orbit, so, let’s follow it first semester 2020.

Bubble are soon ready for production

The bubble service announced last Connect in Berlin has been industrialized. They are industrial product and work as defined last year (see previous link). During the show we had a nice demonstration: any visitor has a connected badge listening for bubble beacon and reporting its position. That way we could find any attendee, looking for its “real time” position. On top of this feature, this could allow to get analytics on booth frequentation, people interests… nice use-case.

The bubble is easy to deploy and ready for it. Its life duration depends on beacon period but count on years (4-5). It uses monarch to automatically switch in the right radio configuration and reports its status on regular basis thanks to Sigfox network. This radio configuration is also transferred to the devices, so they do not especially need Monarch for this. It have a tear detection system to manage this case correctly.

The bubble can be used with any devices able to decode Monarch type of modulation. But if you want to make low power (long life) devices, working with bubble, you need to have a specific radio front. This last is waked up by the bubble signal and avoid MCU to listen and wait for beacon signal. The reference design for low-power bubble devices is not yet published so you will need to wait a bit to make your own. This feature saves a lot of energy but also reduce the sensibility of the device and limit the bubble coverage zone.

The protocol is evolving and the bubble beacon will soon transmit information like the bubble GPS position. It should be soon equipped with a GPS. This is allowing in-movement bubble (like in a truck). That way, a group of devices with no GPS, in movement, will be able to report a real-time, precise position, captured from the bubble message. Other informations like temperature could also be reported to be used the same way. This is an interesting usage where  the bubble handle the expensive hardware in it and share it to “bumb” devices, low costs.

Bubble is today available as a demo-kit, it contains 15 bubbles, 50 low-power tags, plus dedicated consulting for a total cost around 40k€. This let you run your POC and is not related to products price but global project costs.

Bubble are still managed devices operated by a bubble operation center and still deployable as private, public or semi-public with reduced position precision.