Once you have found the great idea of the year and you want to start implementing your first prototype it is time to choose the right technology. Some would say you should not choose at this step and implement both at end but in my point of view it looks like and economical mistake to do this way. Prototype is to demonstrate and final product. It can request another technology, for sure. But in my point of view the best is to take the right one at the beginning. For most LoRa and Sigfox are both equivalent or for some others one is over the other one, best depends who you ask. In my point of view, if I consider my 2-3 years sigfox experience and my starting experience on LoRa with 1 year background research on it, there is no magic answer. Context of your idea is the keypoint then you have some technical elements to take into account to finalize your decision.

This post will try to illustrate where each of the technology is the best and give you some decision keypoints.

Object localization and mobility

Sound like one of the most important parameter to consider : where your object will be deployed. In case your object is subject to be deployed in many countries, in case your object is supposed to be in mobility and go outside the big cities, in case your object is supposed to move more than 60 km around, you need to have a public network to support your communications.

Public Network

 As of today, the only one, really existing network for IoT is owned by SigFox and its affiliated.  LoRa exists in some cities in test, will be deployed in France in 17 cities according to Orange at SiDo 2016, but the list is really short, the planning is not yet given and the commercial conditions still unknown. That said, I do not trust public announcement and looking for facts. LoRa operators in France have all rejected in different way my requests for experiment so I assume nothing is really dry for being used. What is valid for France sounds not so different in other countries.

Sigfox is far away from competitors having a nice European network coming in the USA, Australia and many more soon when the LoRa roaming standard is not yet published and implemented in the network stack.

By-the-way, you can tell me things are going to change during time you need to develop your product and this will be true… or not. Announcement has been made more than a year ago and the deployment is still pending. I do not know how many time you will need to have a global coverage working seamless between operators. Considering LTE-M arriving everywhere in the world in the next 1-3 year, I do not see why operators should accelerate LoRa. LTE-M will have expensive modem for a couple of year but price will decrease and as certifications are much more simple on LTE-M than on LoRa/SigFox you will save time & money that way.

Half Public Network

You can have object to deploy in many places, when these objects are not moving you can take benefit of a public network. This public network can be extended fo your own usage by adding gateways / basestations rented from the public operators. This is true for SigFox and LoRa ; It seems, according to the different discussions I had it sounds more easy to do with LoRa operators than with Sigfox. For sure you have many more chance to have to manage this extension in a LoRa usecase. This way you have to support cost of basestation renting + cost per device to use the public network. It is not the most efficient solution if you have to install/power and pay many network extension. The positive point is you do not have to manage the network backend and operate it. In a such situation you must make many TCO projection and make a good per device deal with your operator.

Private network

For object you all have in a given area you can cover with 1-10 gateway it is really interesting to consider private network. Private network is not possible with SigFox but can be done with LoRa. The advantage of this mode is to change your cost price from device based to gateway one. The cost for a gateway is about 1k€ but don’t forget to consider the installation and operation costs. This type of deployment is good for industrial parc, farming but also for city applications as you can cover average city with only 1-4 gateways.

Concerning  objects in movement, Doppler effect is affecting SigFox device more than LoRa one. I made a lot of test with SigFox in movement and it worked well (like in this post). In fact if the antenna is moving straight it works well. It start to be a problem when the antenna is turning around (like if you put it on the harm of a runner). So SigFox in movement is not a big issue but a thing to take into account during design. You could prefer LoRa for such application, it would make sense, as soon as you have a network coverage.

Communication requirement

When making objects for IoT, communication is the purpose. Low power networks are based on public frequencies and subject to communication restriction. For this reason you have to consider these restriction before starting to design and make sure what you are looking for will be possible. Basically the restriction is to use the shared media less than 1% of time per hour. In SigFox case as everything is defined and not configurable it means 140 message a day. This is not fully true as in SigFox you can change the message size from 12 bytes to 8,6 or 4 bytes. So basically you should be able to transmit about 250-300 message a day with 4 bytes but this is not allowed by SigFox (I hope it will become possible later). So you should have in mind if your system need less than 6 messages per hour SigFox will be ok if more is needed, Sigfox won’t be the solution.

For more message per hour LoRa may help you. The 1% duty cycle rule still valid but the technology have many more lever. The first one is the transmission speed. SigFox is 100bits/s when LoRa offers from 300bits/s to 6000bits/s in the standard transmission mode. This impacts the distance your message will reach, so it is related to the type of network you are connected to and also if you are mobile or not mobile and looking for best radio conditions. So basically for a radio quality not so far from SigFox you can expect 2x message per day. The second lever is the message repetition : SigFox messages are repeated 3 times on different frequencies to avoid collisions so 1 message count for 3. LoRa does not have this function so you can expect to transmis 3x messages based on this. Then you can choose to transfert messages the size you want and as said if you transfer 6 bytes messages you can be about 2x the number of messages. Mixing all of this you can transfert +12x message a day compared to a SigFox network. It can become +240x if you have a 6000b/s communication. Instead of having a limit of 1 message per 10 minutes you have something like 1 message per 50s to 1 message per 3 seconds. Limitation has been broken !

The main problem is we are talking theoretically because your message is never sure to be received and faster you are, less repetition you do, less chance you have to success in your communication. More over, as the number of channel on LoRa is really low, you have many chance to have different devices emitting in the same period of time making communication unsuccessful. In your LoRa design you will have to manage re-emission if your message is important. LoRa allows acknowledgment to manage re-emission in an efficient way. So in your design you need to consider variable number of re-transmission as part of your duty-cycle equation.

LoRa implements duty-cycle after each transmission in most of the firmware, so it means once you have transmitted a frame you need to wait for the next 99% of time before sending a second message. As a consequence if you need to transmit the message again because it has not been ack you will have to wait. Depends on your time in the air, it can reach a minute. As a consequence the time to delivery you message can grow really larger than SigFox. SigFox ensure about 99.9..9% of messages received thanks to the repetition schema in the 7 seconds of transmission duration. With LoRa if you need 3 transmissions it will be slower, even at 6000bps ( about 10s ) and really slower at 300bps ( up to 3 minutes ). 3 transmission is a worst case but possible case. This point have to be taken into account if you have a time delivery critical application. For exemple alarm system have a risk to be unplug by intruder before the transmission completion if a 3 minute delay is reached.  Eventually, the way your device is managing the duty-cycle could be redesigned to manage a such case by adding some work of engineering.

Security

Both technologies are offering some security functions : Sigfox is using encryption mechanism for authenticating tye device but is not encrypting communications. So you have to do it at firmware level. LoRa is encrypting data at 3 level.  Sigfox is based on a network authentification plus a frequency hopping algorithm and sequence number avoiding a third party device to emit with original device identity. LoRa is using 3 different keys to encrypt at device, application and network level. This ensure, when you have multiple network, public and private, operating the same frequencies to not process data from other one. That is for the ability of a third party to listen on your device data.

The other side of security is for an attacker to switch off you device communications. For a such attack, as you can’t avoid a device to transmit, the more easy is to avoid reception (only reception can be noised with a strong emitter near the receiver). For network like GPRS needing a two-side communication, if you generate noise near the object you can stop any communications by canceling network orders reception to the device. In networks like SigFox or LoRa the device is able to emit without any network authorization, the only way to cancel communication would be to generate noise at every network antenna… so forget it ! SigFox and LoRa are not fully equivalent on this point as LoRaWAN requires the object to receive the network channel configuration in the connect sequence. Once it received these information it can communicate on its own. The connection sequence is initiated on the first communication and we can assume it has already be done when the attacker start is attack when the device is not mobile. When a device is mobile, we can assume it will have to reconnect when changing from a cell to another, in this scenario we can cancel later communication of the object ; for this reason valuable goods tracking is not a good application for LoRaWan.

Hardware Design

868MHz is generally a mess for antenna design and this is a recurrent discussion we have with device designer about the good deal between antenna size and radio performance. LoRa and SigFox have the same frequency and the same problem to manage. We also have to consider different frequencies in the different part of the world making a worldwide operating device a big challenge. The main difference between technologies is SigFox is open to many chip provider when LoRa chip are delivered by Semtech and Licensed (actually one Chinese provider) I won’t argue on this as actually the consequences are not totally clear and it is not making a big difference. SigFox offer a lot of hardware solutions but at end, actually, not all of them are ready for industrialization and CE certifications. The LoRa module have to integrate the LoRaWan stack. Actually this one is still in progress and we have seen many firmware updates on the existing modules in the past year. We know we will have some more in the current year to support roaming as an exemple. It means you have to consider LoRaWAN stack upgrade in your device design.

The second point to take into consideration is configuration : SigFox is really a plug & play technology, you have no device configuration to perform : just kick a message and it works. On LoRa you must set all the encryption key. As one of them is related to the network, you will have to change it depends on the network operator you choose. In some cases it is not a problem but in most of the case you must design a way to configure your device on site. It means BLE or Wifi or USB connectivity to allow the end user to make this final configuration. This is an hardware complexity to consider it also impacts the industrial process. For private network, I assume you can simplify this step.

Certifications

Following hardware design, your system have to be certified for reason that sounds different. You firstly have to use a SigFox / LoRaWAN certified chip or module, usually this certification is managed by the module/chip provider and make sense to certificate the devices will use the right communication protocol. Then you have a device certification. Concerning SigFox, my point of view is they don’t want to have bad communication on the network quality as they are just starting. So they require a device qualification depending on the radio quality. It costs about 2.5K€ and is done really fast, nothing is really blocking at this point, you can choose to have a U2 device (with a poor radio quality). LoRa have its own certification managed by the LoRa Alliance. This sounds in my point of view like a good way to make money at LoRa alliance level. I do not know the price yet and required time. I just know they are making the certification through specialists usually considered as expensive but I may wrong. The surprise of last week was to discover that operators like Orange also want to do another certification. This one sounds free but takes time and gives me a bad feeling like « we do not trust you » As your device could be deployed on many country and different public networks, does it mean one certification per operators ? how many will be free vs billable ? In my point of view all of this make no sense. If you create a GPRS device no-one will ask you for a certification ! your module is certified it is good enough … It should be the same for IoT network : if your device quality is bad, you will be the first impacted, not the network operators : they will just no receive your messages, not more.

Then your object must be certified for CEM, this is valid and equivalent whatever the technology is.

Firmware and Software Design

This is were the difference start to be huge between technologies. SigFox is a plug & play solution and regarding my experience your code between your prototype and your final product is not really different, for sure you add a lot of extra functions in the final product but the radio part is globally unchanged. SigFox implementation is fast as you have no setup, no parameters, just a transmit function including a potential callback function for downling. Concerning LoRa, you can design a prototype as fast as with SigFox, you just don’t care about settings, connection failure/success aven duty-cycle. But, as soon as you start thinking about production, connection/disconnection, duty-cycle management, link quality vs speed are not mandatory anymore. Your firmware will be more and more complicated and testability will start to be complex. I do not say impossible, I just think you will need many more time and you have many more chance to make a malfunctioning device on LoRaWan. You also have to manage encryption key setup, you have to manage communication parameters coming from the WAN and you are not managing (what about your message frequency and duty-cycle management if you plan to have SF7 and your network operator in an area only accept SF12?). It is actually hard to say exactly how difficult it will be to manage as we have no public offer available and I can just think about hypothesis and risk management. But my opinion is SigFox is like an apple product : it is closed but play&play when LoRa is like Androïd : you have many way to tune it and at this point it start to be a mess, you may have access to a functionality but as it is buggy until the next release you will have to find another way…

GPRS was really simple : based on TCP/IP you had a direct connection from the device to your own backend. IoT world is really different : to limit the amount of data to transmit and simplify the communication protocol, the communication have to pass through an operator backend before reaching your own backend. On the software side, the mechanism are similar : data are received by the network operator. This one stores the data on its cloud and propose some callback solution to transfer them to your own backend. For SigFox, the backend they are proposing is a global one. Whatever the country your object is, the way you gather the data is exactly the same. For having deployed objects in different European countries, this is a really killing feature in my point of view. Considering LoRaWan is really different : if you do not manage your own network, you will have to manage the different backend of your different network provider. Each of them will have it’s own API to manage device and gather data. At end you will have to implement all this complexity in your own backend or pay a future third party to manage this complexity for you. Eventually you will have to follow backend upgrade of the different operators to stay compatible. For managing private LoRa network you will have to build you own backend, or to let some company manage it for you. Another solution to take a look to in TheThingsNetwork a kind of open-source global LoRa network.

Device Localization

When you are managing a large number of devices the device location is an important information. GPS solution is costly in term of price and energy consumption. IoT network are proposing some help for this feature. SigFox is actually providing a 1° latitude/longitude location. This not sufficient in most of the case but it still a valid information you are getting for free. LoRa network are actually looking for a really better information with current technology standard developments (kerlink as an example is working on this capacity). Based on propagation time of LoRa messages it will allow to have a precision near a GPS for « free » Actually this solution does not exist yet and I hope SigFox will also work on it as it is really promising. For sure it looks like a killer feature for the one providing it first.

Conclusion

To conclude my feeling is SigFox is the best solution for public network when LoRaWan is a really great solution every-time you will operate your own private network (eventually you can delegate it, even to a public operator, but I mean you are controlling and limiting the extension of this network). Sigfox is simple when LoRaWan is customizable. SigFox exists when LoRaWan is a promise for futur.

I’ve tried to summarized most a the question related to my previous paragraph and give you an estimate of the complexity of your project depends on the technology you can use. I hope this grid will help you.

This post is subject to future modifications and precision as my experience on LoRaWAN is still limited and my knowledge about LTE-M is really limited.

                                          SigFox        LoRa       Future-LTE-M
My object is deployed in many countries   Easy          Complex    Easy
My object is moving more than 60km around Easy          Complex    Easy
My object is moving less than 60km around Easy          Average    Easy
My object is not moving, > 100 same area  Easy          Easy       Easy
My object is not moving < 10 same area    Easy    Expensive/Easy*  Easy
My object is not moving > 1000 same area  Expensive     Easy       Expensive
My object is communicating 
     less than 6 time per hour            Easy          Easy       Easy
     up to 1 time per min                 Impossible    Easy       Easy
     more than 1 time per min             Impossible    Complex    Easy
My object message are time is critical    Easy          Complex    Easy
My object com. have to be secured         Easy        Easy when    At risk
                                                     not moving
My Object have to be plug & play          Easy          Average    As GPRS
Firmware Prototyping Complexity           Easy          Easy       Unknown
Firmware Production Complexity            Easy    Average-Complex  Unknown
Backend Prototyping Complexity            Easy         Average     Unknown
Backend Production Complexity             Easy         Complex     Unknown
Device Certification process              SigFox    LoRaAlliance   None
                                                     +Operators
Part of communication chip in Object price 2$-10$      2$-10$      10$-20$
My object can be deployed since           2014        2016/17      2017/18