Low power GPS: The power of LPWAN harnessed for location and tracking

The power of LPWAN harnessed for location and tracking

The Actility Blog

Actility’s IoT geolocation helps to protect workers and assets

The power of LPWAN harnessed for location and tracking

The energy consumption factor

In 2015, the Abeeway founders observed that there were no tracking and location devices in the market offering decent autonomy without oversized batteries or infringed precision of location.

We have to remember that GPS works with a constellation of satellites continuously broadcasting a radio signal that a receiver intercepts to determine the ephemeris as well as the distance to each visible satellite, allowing to calculate the receiver’s position. Translated to an IoT sensor, it means that all the processing is made by the chipset, which requires a lot of processing time and therefore energy.

It became clear that reducing the sensors’ energy consumption would be instrumental to enable large-scale IoT location and tracking.

“When I joined as CTO, I committed with my team to improving GPS efficiency to overcome this technical hurdle.” Stéphane Boudaud, Actility

Focus on GPS processing and connectivity 

Based on extensive field tests starting in 2016, we decided to tackle the power consumption of the GPS positioning – knowing that it is the most energy-consuming element of a tracker.

The second reason for optimizing the GPS processing and connectivity was to accommodate the emerging LoRaWAN standard with specific data transfer requirements such as low data rate and limiting downlink packets. In addition, since low-cost IoT endpoints have limited processing power, GPS calculations had to take place outside the device, in the cloud.

“The technical challenge was to find the right way to transmit minimum information via LoRaWAN while enabling maximum results on the server.”

After half a year of intense development, we had a functional solution up and running! Abeeway registered a patent for Low Power GPS in July 2016, an optimized GPS location process, designed for LPWA networks, and more specifically for LoRaWAN.  In the meantime, the team continued to improve the precision of location, power consumption and time to first fix.

A-GPS optimized for LPWA networks

The satellite data collected by the GPS device (the ephemeris and the almanac) are already preloaded on the server. In that case, the GPS receiver only collects raw data from satellites, then transmits it to Abeeway location assistance server via the LoRaWAN network.

The server combines this information with known satellites trajectories and calculates the final position. The whole process is made in the cloud, which is much faster than inside the device and does not waste its energy for calculation.

“As a result, Low Power GPS allows reducing energy consumption up to 10 times while maintaining high location accuracy.”

High speed, power-efficiency, and precision

When a standalone GPS receiver has to get its first position (its “first fix”), it needs a signal strong enough to do it. LP GPS allows overturning this acquisition sensitivity constraint with the ability to extract raw data and calculate a position on the cloud.

  • In good conditions, a Low Power GPS device can have a first fix under 10 seconds instead of 1 minute for a standard GPS device. The latter has no clue about the time, the location nor the satellite position; it has to start from scratch. The former saves time and status of the satellite constellation allowing a fast Time to First Fix (TTFF).
  • Under poor signal, a regular GPS receiver spends a lot of energy struggling to collect the ephemeris. As these data are already available on the server, LP GPS works.

“Where GPS fails, LP GPS will still provide a position, with an accuracy depending on a number of satellites in reach.”  

In a nutshell, Low Power GPS devices offer:

  • Higher speed: Time To First Fix in 10 seconds vs 1 minute for a regular GPS
  • Energy-efficiency: battery life increased up to 10 times
  • Higher precision in extreme conditions

Test packages for Low Power Location are soon available, book yours!

New LoRaWAN specs straight from the LoRa Alliance’s oven to your plate

Passive roaming bakery metaphor small

The Actility Blog

Actility’s IoT geolocation helps to protect workers and assets

Passive roaming bakery metaphor

There’s excellent news coming from the LoRa Alliance: the core LoRaWAN specifications enabling passive roaming are coming out of the oven! As a co-chair of the LoRa Alliance Technical Committee, it’s my pleasure to present you our latest treats on roaming, security, Class B, and standalone Join Server.

The Technical Committee has been working on these specs for over a year now… We knew that they were highly anticipated by the whole LoRaWAN ecosystem. As a matter of fact, Actility customers have been able to preview the passive roaming feature since last summer.

Handover roaming

First delivery from the LoRa Alliance is a new version of the LoRaWAN spec LoRaWAN 1.1 offering:

  • Support for handover roaming, which allows transferring control of the end-device from one LoRaWAN network to another. Earlier versions of this specification can already be used for passive roaming, which is transparent to the end-device.
  • Enhancements on bidirectional end-devices with scheduled receive slots (so-called Class B, an enabler of energy-efficient actuators) which is now officially supported. Remember, in the earlier spec it was marked as “experimental.”
  • Enhancements for additional security hardening.

In order to support heterogeneous deployments and not force a globally-coordinated upgrade, both LoRaWAN 1.1 end-devices and networks will support backward compatibility to interoperate with their LoRaWAN 1.0.x legacy peers.

Separation of backend servers

The second delivery is the brand new LoRaWAN Backend Interfaces 1.0 Specification allowing to:

  • Split the core network into interoperable servers: Network Server (NS), Join Server (JS) and Application Server (AS)
  • Roaming for both LoRaWAN 1.0.x (passive roaming only) and LoRaWAN 1.1 networks (both passive and handover roaming)
  • A standalone server that stores end-device credentials (including root keys) as JS. It can be separated and administered by an entity independent from the networks that the end-device may be using. This allows networks to offload the authentication procedure to a dedicated system, which can also be operated by a third party. This third-party JS also enables an end-device to be manufactured without having to be personalized for the networks it may eventually be connecting to.

Regional Parameters

And final delivery in the package is the LoRaWAN 1.1 Regional Parameters rev. A, which describes a region-specific radio parameter for LoRaWAN 1.1 end-devices — a companion document for the LoRaWAN 1.1 spec.

In the spirit of fostering open standards, these spec delicacies are shared with you to build and deploy amazing products and services… Enjoy! Bon Appetit!

LoRa Alliance Security White Paper

LoRa fire alarm

The Actility Blog

LoRa Alliance Security White Paper

LoRa fire alarm

The main objective of LoRaWAN, being an LPWAN technology, is obviously to provide IoT connectivity… BUT – because there is always a “but” – we are now all aware that unless IoT connectivity is fully secured, it can create more problems than it solves… Who would want to connect their smoke alarm to the Internet when hackers could easily mess with it?

If your neighbor’s kid can wake you up to a deafening alarm sound at 4am, you are sure to regret you ever connected that thing to the Internet.That is why security has been a top priority of the LoRa Alliance members and part of the specification for LoRaWAN from the very beginning. 

Even though wireless security standards and implementations have gone a long way through the industry experience built around WiFi and 3G development, LPWAN presents a very fresh and unique set of requirements.

Constraints on the frame size, amount of traffic, as well as uplink and downlink asymmetry due to ISM regulations and battery preservation are so unprecedented, none of the state-of-art wireless security solutions work out-of-the-box on LPWAN technologies.

And that is why a lot of technology design cycles go into security aspects. 

Also noteworthy is that a typical LPWAN design has a tradeoff between two dimensions: security and efficiency. Efficiency is essential for LPWAN by definition,so it is not something that can be easily given up.

Some design decisions can be easily tracked back to this tradeoff;and some not, for which we owe the community a rationale whitepaper (promise :-))

So, it is not surprising that at Actility, we do care a lot about security. We have been part of the original LoRaWAN specification design, currently chairing the Security WG in the LoRa Alliance, and proudly presenting a full LoRaWAN security product portfolio including Join Server, Secure Elements, and HSM through our in-house development and partners.

For more about LoRaWAN security, please read the LoRa Alliance white paper and the FAQ on this subject that we have co-authored with our fellow members in the Alliance.

A Revolution in Passive Roaming

Mobile World Congress Actility booth picture small

The Actility Blog

A Revolution in Passive Roaming

Mobile World Congress Actility booth picture

At the Mobile World Congress a few months ago, Actility announced that it was offering LoRaWAN Network Operators a chance to test their passive roaming capabilities. Today, we are glad to offer this labs platform available before the LoRa Alliance standard specification release due this September.

While we are highly involved in this effort through the Alliance’s Technical Committee, we wanted to enable LoRaWAN Network Operators early availability for testing their passive roaming capabilities. Here are the five reasons why:

1. It’s a critical feature in many use cases

Since LoRaWAN is an open standard that benefits from a large ecosystem / 500+ companies in the LoRa Alliance, LoRaWAN networks do not form yet a universal coverage everywhere.

While roaming allows a rapid growth of the ecosystem and many local use cases, it is critical for devices in the following use cases:

  • International tracking: track shipments across borders not only in routing hubs but throughout their journey up to the last mile (now RFID) supply chain & logistics (track containers throughout their journey);
  • MNO network sharing through extensions or densification or National Solution Provider deployments with extension in multiple national networks;
  • Managed Customer Networks with fall-back on national networks outside of local facilities.

2. Standardization is work in progress

The LoRa Alliance targets to release official LoRaWAN Backend Interface (BEI) specification (v1.0) in September 2017. Standardization work is completed and in BoD approval.

For two years now, Actility has been heavily involved in that effort:

  • Actility is leading the Alliance Working Group on Roaming, and co-chairing the Technical Committe.
  • Actility has demonstrated Passive Roaming at MWC in February 2017.
  • Actility is starting interoperability tests with first vendors during summer, other vendors to follow.
  • End of May, Actility announced availability of the Passive Roaming feature on “Actility labs” testing platforms: our customers can test the service with their own gateways and devices.

3. Passive roaming is the killer feature for telcos

IoT standards like LTE-M and NB-IoT are maturing, and the roaming ability is a must-have for LoRaWAN to be competitive.

While both LoRaBEI 1.0 and LoRaWAN1.1 (new Mac layer) are expected to be finalized around September, industry expects new MAC layer LoRaWAN1.1 rollout to be much slower.

Because it involves updates on the device side, the adoption will only be done gradually for newer devices. 

However, by implementing LoRaBEI1.0, it is possible to deploy Passive Roaming for both LoRaWAN1.0 and LoRaWAN1.1 devices, without any change on device side

4. Actility Labs Platform is an innovation booster

Before ThingPark platform latest features are fully released commercially  this Lab offers operators early access and ability to test these features on live networks including with other Actility customers. The passive Roaming feature is delivered through accounts on two test operators powered by Actility Network Servers.

After interoperability tests have been completed, the platform may be extended with other vendors’ Network Servers. This should demonstrate in real life how provisioning Roaming Agreement between operator works.

Until the platform is launched, Actility will be constantly upgrading it with new features such as Handover Roaming on the same platform.

This Lab Platform maximizes Actility customers’ competitiveness by testing innovative roaming features ahead of the other, enabling them to communicate or demonstrate first.

5. Still some challenges to tackle

While setting up commercial Roaming agreements between operators will take time, there are other challenges to be considered for global roaming use cases.

Operators must agree on common channels in their channel plans so that devices can roam from one network to another. LoRaWAN regional parameters cover 9 ISM bands today, in accordance to local regulations. Mobile devices will need to discover in which region they are located and adapt accordingly, to avoid device emissions that violate local regulations.