I want to start a new category of posts about IoT, not focus on the technology itself but on the use-cases. That said, for sure my words will be on the technological aspects of this use-case. The objective is to let you understand what are the solution but also what are the challenges behind that use-case. To start I’ve selected the Tracking use-case, reviewing all the GPS, WiFi and operator technics.

Regarding my experience in IoT from the past 5 years, one of the biggest market for LPWAn is actually assets tracking. In number I assume alarm backup is a little bit behind but thanks to one uniq actor. Tracking is far away first regarding the number of actors already having implemented a solution in production. This is also where we find the largest number of objects on the market for a single use-case.

That’s why I decided to start with this use case. I also know it really well for being the founder of one of these solution : Foxtrackr and I’ve already implemented all the technics described below.

From what you get with your smartphone to the different technologies

What’s magic with a smartphone is you get your actual precision, with a really good precision (15-30 meters) usually in a time of 5-10 seconds… You may think this experience is just normal ? For your smartphone in 2018, you right, but never forget to get a such result you have a $500 device in the hand, connected to a high speed network costing you $20 / month with a battery autonomy lower than 2 days…

That’s important to understand IoT experience can be slightly different regarding the fact you usually wants to have a $50 device, connected to low speed network costing $1 / month with a battery autonomy higher than 1 year…

So let’s start understanding how a smartphone allows such magic in fast and precise positioning whatever the condition are. Location is relaying on different technologies all coupled for giving you the best experience:

• The first information you get is usually the position obtained by cell-phone network : thanks the identification of the antenna the smartphone is connected to you can get a position. This is easily obtain with an API call to a service like Google. This position is really not precise (0,5-10 km) depending of the density of antenna in the area you are and the signal.
• The second information comes from the GNSS (GPS-Galileo) satellites, it generally needs 5-10 seconds to be obtained. This is really fast and only possible thanks to the ephemeris downloaded from Internet to know the exact position, direction of the satellites. This position is really precise but it is only working outdoor.
• The third method is based on WiFi access point: the smart phone scan the WiFi and ask an API sending the Mac addresses to a service (like Google or Here) and get as a response a position. This is working well for indoor and dense urban zone.
• The last approach is to extrapolate the position from the last known position using the accelerometer to calculate speed and direction change. I don’t think it works well with smartphone but it is more common for car GPS.

A modern smartphone is using all these methods all-together to report a position as fast as possible. You see behind this different electronic components used: GPS, WiFi, Accelerometer, operator network. And also different services: GPS ephemeris download, WiFi and Operator positioning APIs.

Regarding the IoT limitations, obtaining the same result is quite challenging and we will review for each of the technics what is the complex part and what are the possible solutions.

GPS Positioning challenge

I already made a long post about GPS positioning you can consult for details but to focus on our current topic, we just need to consider what is needed to get a GPS position:

• Ephemeris: they are information transmitted by each of the satellites to be able to calculate the position of the satellite to be able to determine the current position of the receiver.
• A signal from at least 3 satellites to calculate the position.

The main challenge is about the Ephemeris because it needs about 30-90 seconds to get the ephemeris, outdoor, and being ready for positioning. This is the Time To First Fix (FTFF) These ephemeris are for each of the satellites and valid for 4h. So you have to listen and listen again for ephemeris. This is about 90% of the power consumption of your device at end. Once you have them  a fix is only a question of seconds.

Here you see one of the main differences between a smartphone getting the ephemeris immediately from its Internet access and an IoT device having to sync them. For developers the challenge is to wait for ephemeris but managing bad reception conditions and manage refresh in variable reception conditions. Basically when the device is always outdoor exposed the challenge is not big but as soon as the device moves from outdoor and indoor it starts to be a complex question.

Ubiscale proposes a good solution for this by removing the need of Ephemeris sync but for using it you need to have a specific hardware configuration and you need to pay an additional service.

WiFi positioning challenge

The WiFi positioning rely on listening the WiFi access point all around you and report them to a central server knowing the location of each of them. The central server returns a position. These databases are owned by service providers like Google or Here and others. The quality of the service depends on the size of the database and the way they collect the data. Google collected some with the Google car going everywhere but I assume they are also improving the database with all the android smartphone acting as collectors. That’s the way the information are alway up-to-date.

This service works really well as soon as you have multiple access points around you. the problem with WiFi is the limited coverage, usually around 30-50 meters. As soon as you are at 100 meters of any building you are quite sure to not get any positioning.

The advantage is you need about 5-6 seconds to scan the WiFi around and get information to report for positioning. WiFi in reception is consuming not much power than a GPS so you basically saves energy with this method if you succeed to get some data.

The developper challenge is to identify the right access point to be used: a smartphone can listen to all the access point around and report all of them to the location service because it has no network limit. IoT must manage this differently as it can usually report only 2 to 4 listen access points. When you get 10 of them you need to decide what are the most relevant for getting a position. As an exemple if you report a phone Id (sharing its connection) or if you report a mobile hotspot you will get no result ; if you report always the same ids from a given place you have a risk to always report an Id the service does not know yet… As a consequence, with a limited amount of memory you need to manage these questions and found a working solution… working in most of the case. The quality of the tracker will really depends on the implementation the device maker have realized, it’s strong engineering.

Even if WiFi positioning looks like a free technology, the truth is different: Google is charging $5 for 1000 positions. Imagine your device reports 48 positions per day (one every 30 minutes) it’s about 1.5k positions per month costing $7.5. Compared to a network cost of $1 per month it’s a strong cost to add in your economical equation. We can notice Sigfox is now including a such service for a really accessible price, the limitation in my point of view is the way to implement it, constraints on the object protocol are too strong.

As a consequence you have engineering on the device and also on the backend to optimize your API use, to support different service provider and be in a position to make them in competition.

WiFi sounds simple to implement and that’s true to get your first success with it. But as soon a you dig a little with it and use it on the field you discover all the related complexity to manage. I can tell you it is really larger than GPS.

Above you can see the result of the same trip, one covered by a GPS based tracker and the second one base on a WiFi based tracker:

GPS based tracking, we have a valid positioning in most of the situations: urban, country side…	WiFi positioning: we have a valid position only in the urban zone where the WiFi networks are dense.

 

Network positioning challenge

Network positioning is finally the easiest way to position an object. It is also what is the more efficient in terms of energy: you need to make a transmission and you don’t need to send data, you just need a signal captured by different antennas to get a position returned by the network. That’s for IoT and LPWAn.

The problem is that position is precise from 0,5km to 30km… if LPWAn takes an advantage of really large cells as a consequence it gives them a really bad precision in positioning. A good precision will come from a strong signal (you are really near an antenna) or the antenna density allowing a better triangulation. A non moving device will be positioned in hundreds of different places around the same location due to signal variation on every transmission.

The device maker will also have to deal with some glitch, I already experienced really long distance communication (over 400km) over the ocean (usually it happens when you are on the coast), my device has been located on the distant position instead on the local one. You can see one of the rare example I saw. For sure this device has never been in the South of Nantes at this moment: It was 400km on the south where the other points are located near St Jean de Luz.

 

 

That said, this solution can be really good, it’s a question of scale, if you look at a position at the city level, this information is really relevant, if you want to find something precisely it will not work. The two images below are exactly the same data corresponding to the same, non moving, object: the first one is zoomed at a street scale and the information is not relevant. The second one is zoom at the city scale at that way the information is really relevant.

At street scale we have a large zone with many different point for a given location. We know it’s North-Est of the city eventually ; this information is precise but unclear.	At the city scale we clearly see all the point are related to Clermont-Ferrand. This information is clear.

 

Network fine grain positioning

This last technic could be a revolution for IoT: instead of looking for the position of a device based on the signal level received by the antennas, you base the calculation on the time made by the communication to reach all the antennas. And you get a satellite style positioning working on the ground. This is what LoRaWAn has promised 3 years ago. For real I did not see yet implemented on a public network (neither in private). I hope it will arrived a day ; it could be implemented on any network for real, Sigfox, 3GPP, if relevant.

That said there are different challenges, the first one is to synchronize the gateway with a precision related to the expected position precision. We are talking about  0,1 micro second to get something good (30m) at light speed. Precision the gateway must kept with varying weather conditions. This is not the strongest challenge.  The main issue is about the path taken by waves to reach the antennas: if you are in a flat and empty area the wave directly goes to the antennas the distance will be straight forward and easy to calculate. But in the real use case like in urban zone the signal will hit many building before reaching the antenna making the wave path longer than the distance to reach the antenna. As a consequence the time will not correspond to the flight distance and the position will be wrong. With many antenna you may be able to fix this.

This is the best solution we could imagine as the complexity is on the operator side, the energy cost is the lower and the precision could be good. The last problem is; you need to be covered by 3 antennas at least, worldwide to get a position in any situation… so like for other solution this solution alone actually not working.

What to conclude ?

As a conclusion, I would say that there is no magic and the reason why we have a such long list of trackers on the market is because each of them have tried to find a good balance with the different complexity points to manage in a given situation.

This means an IoT tracker fits a certain need and is not general purpose like a smartphone can be, so when designing one you need to clearly identify the conditions of the object tracked and select the right solution for these conditions. It means when you want to choose a tracker for your own use-case you need to identify also these conditions (indoor, outdoor, moving, mostly stopped, scale of location, frequency of update…) to select the right solution.

If you do not do this exercise correctly, as for device maker as for a final customer you will design/search for a smartphone… back to my introduction, smartphone have non of the characteristics we apply to IoT.