by PHY Wireless
To achieve both data communications and positioning, an IoT wireless device might use an LTE modem for data, GPS for outdoor location, and Wi-Fi for indoor location. An IoT device with hellaPHY Location software eliminates the need for GPS and Wi-Fi (Figure 1). Instead, positioning is performed using existing LTE signals. The reduction of components reduces cost, shrinks device size, and improves battery life. hellaPHY thus brings the power and scale of 4G-LTE cellular networks to the problem of the Location of Things (LoT).
hellaPHY Location uses existing downlink 4G-LTE positioning reference signals (PRS) that were included in 3GPP Release 9 that are typically 50 dB higher in strength than satellite GPS signals, which enables a fast and efficient positioning fix indoors or outdoors. It requires minimal interaction with the network, reducing congestion and extending the battery life of the device, and performs cell time-of-arrival (TOA) estimation and position estimation on the device with algorithms designed to combat the degrading effects of multipath and interference. hellaPHY Location runs on an ARM processor and requires only 6 MHz of CPU bandwidth during a positioning session and the memory required is less than 100 kB.
Cumulative effects have a dramatic impact on battery life (Figure 2). In a geofencing application, a GPS-based device is expected to have a battery life of 14.7 days, while a device using cloud-based cellular positioning extends the battery life to 19.5 days. In contrast, the battery life of a hellaPHY device is 4 years or 100 times longer than the GPS device. For a breadcrumbing use case, the hellaPHY device has a 67 times higher gain versus a GPS device with an 8 year battery life.
The hellaPHY Location system architecture is shown in Figure 3. The mobile network operator (MNO) base station almanac (BSA) database contains the cell parameters defining the network layout. Each cell in the database is characterized by a unique cell identifier (ECGI), the latitude and longitude of the cell transmission point, a physical cell index (PCI), antenna aperture and orientation details, transmission power, and various other parameters. The hellaPHY Cloud Assist server interacts with the BSA database to provide the hellaPHY device with a small subset of the BSA. This micro-BSA can consist of several hundred cells close to the serving cell of the user equipment. The required parameters per cell can be fit into about 120 bits, so a 1000 cell micro-BSA can be expressed by:
1000 cells × 120 bits⁄cell × 1 kB⁄8000 bits = 15 kB
This 15-kB 1000-cell micro-BSA is transferred to the user device in a few seconds over the wireless link. A smaller micro BSA can be requested for shorter download times and less storage, and a larger micro BSA can be requested for greater coverage. As a point of reference, for a typical cell density of 1 cell/km², a 1000-cell micro-BSA provides coverage for a 1000 km² area. With a single micro BSA many position fixes can be obtained so once the micro-BSA is downloaded, the device requires minimal additional interaction with the network.
The host modem provides the onboard hellaPHY software with position reference signal (PRS) subframes. A typical PRS deployment is 1 ms every 160 ms, so about 6 PRS occasions per second. In a 5 s positioning event, around 30 PRS occasions are captured and fed to hellaPHY. For extended battery life, the PRS capture is performed in low-power LTE eDRX idle mode or LTE power save mode. The hellaPHY Cell Scheduler dynamically determines cells from the micro-BSA to perform measurements for optimal location accuracy with low complexity.
hellaPHY Reference Signal Time Difference (RSTD) measurements are performed using TOA and filtering algorithms that process the TOA measurements and various quality metrics to arrive at an estimate of the user’s location. These components are tightly coupled for rapid and efficient derivation of accurate position estimates.
To illustrate the capabilities of hellaPHY Location, it can be compared with two other solutions for low-power wide-area applications (Figure 4). Each of these devices employs 3GPP Category M1 (LTE-M) baseband for data connectivity on a cellular network. LTE-M low power features include power save mode and RRC and discontinuous reception (DRX). In this analysis, it is assumed the PSM draws 0.01 mA and RRC Idle DRX draws 2 mA. When connected to the LTE network, exchanging data in RRC Connected mode it is assumed that the LTE-M modem draws 150 mA.
Device A uses assisted GPS (A-GPS), Device B uses some type of cellular cloud-based solution, and Device C uses hellaPHY. Device A performs measurements on satellite transmissions, and Devices B and C perform measurements on terrestrial LTE cellular signals. Devices B and C make use of 1 ms of PRS transmitted every 160 ms and possibly common reference signals (CRS). Higher-density PRS is allowed in the 3GPP specification, but it is assumed the mobile network operator is deploying low-density PRS to prioritize data capacity.
Device A performs the position estimate in the device’s GPS receiver, which is optimized in its timing measurements, position calculation updates, and filtering. This tight coupling between algorithms results in accurate position accuracy. Device B performs measurements on the device and uploads these measurements to the cloud server where the position estimate is performed. This method has a few fundamental issues. For example, uploading the position measurements is costly in terms of power drain that reduces battery life, and separating the position measurements on the device from the position calculation in the cloud can degrade performance. The cloud may have large amounts of computing capacity, but uploading measurements at a high rate to the position calculation may not be feasible and also can limit performance.
In addition, dividing algorithm responsibility between multiple vendors can lead to suboptimal outcomes. For example, in 3GPP UE-assisted OTDOA, one vendor may be responsible for the UE RSTD algorithm passing 3GPP minimum conformance, while another vendor is responsible for the location server assistance data and position calculation. The overall position accuracy is difficult to manage for the MNO with this division of responsibilities. Finally, storing the location information of millions or even billions of devices in the cloud presents the issue of security.
Device C overcomes the issues with Device B by using hellaPHY UE-based location. The interplay between the measurements, the position calculation updates, and filtering improve location accuracy in an efficient manner. Keeping the location on the device provides a security enhancement, and in terms of expected location accuracy, A-GPS remains the gold standard for outdoor location where the device has clear visibility of the sky, so accuracy of 5 m or better can be achieved.
On the other hand, indoor coverage for A-GPS is limited and for the purpose of this analysis is assumed to be unavailable. Device B is expected to have nominal position accuracy of less than 100 m indoors and outdoors, which is not as accurate as outdoor A-GPS but useable for many IoT applications and has the benefit of indoor coverage.
Device C is expected to have performance better than Device B with a nominal accuracy of 50 m based on recent trial results from a Tier-1 MNO that compared hellaPHY on Cat-M1 with a commercial deployment of UE-assisted OTDOA/ECID on a Cat-1 device. Through on-network live testing across a diverse set of locations (indoor, outdoor, dense urban, suburban, and rural), hellaPHY on the low-end Cat-M1 device outperformed the higher-end Cat-1 device.
The nominal accuracy of 50 m on the hellaPHY device is still not as accurate as the outdoor A-GPS Device because of the higher levels of multipath and non-line-of-sight distortion present in the LTE terrestrial signals compared to the mostly light-of-sight reception of the satellite signals in the GPS receiver. However, the hellaPHY device has the advantage of indoor and outdoor coverage and offers a significant advantage in terms of battery life.
To analyze expected battery life, use cases must be defined. The first example is the application of geofencing (Figure 5) in which the user defines a bounded area (green) where an asset is to reside, and if the asset roams beyond the bounded region, the user is alerted. The asset might be a pet in a yard, a tool on a job site, or a bike in a bike-sharing system on a college campus. Suppose each device estimates the asset location once every 5 minutes and the asset roams outside of the bounded area once every two weeks. The analysis is based on the assumption that the user device operates from a single 2350-mAh AA battery.
Each device spends most of its time in PSM consuming about 0.01 mA, a small fraction of the time outside of PSM where the three devices differ and where battery life is affected. For the A-GPS device, the analysis assumes that a new position fix requires 10 s in RRC Connected mode in which the LTE modem draws 150 mA and the GPS receiver draws 50 mA. For this device, the location is estimated locally: When the asset roams beyond the bounded area, the position estimate is uploaded to a user app consuming 2 s of RRC Connected mode. The position event lasts only 3.33% of the device life but consumes 99.85% of the battery, resulting in a battery life of 14.7 days.
With Device B, every 5 minutes it enters RRC Connected mode to provide 10 s of measurements to the cloud server. The measurements may be over LPP/SUPL using OTDOA or E-CID, or some other cloud-based solution. The measurements are used by a cloud server to estimate the asset location. Since the location is estimated remotely, Device B is not tasked with reporting the asset location when it leaves the bounded area. The battery life of Device B is estimated to be 19.5 days, a 33% gain over the A-GPS device. The gain is attributed to the LTE-only operation during the positioning event with no additional drain from the GPS receiver.
Now consider Device C. Once a week, the hellaPHY device retrieves an updated 1000-cell micro-BSA, requiring 2.4 s of RRC Connected mode. Once every 5 minutes the device obtains an updated position estimate. The hellaPHY position estimate requires 5 s in 3.375 mA low-power mode. This low-power operation assumes 2 mA for the LTE modem (similar to a nominal LTE Idle DRX drain) and accounts for 6 MHz of processing in an ARM MCU with a 50% margin.
It is assumed that hellaPHY can obtain a position fix faster (5 s versus 10 s) as it has assistance from the micro-BSA. The estimated battery life for Device C extends to 1463 days, 100 times longer than the A-GPS device, resulting from the low-power mode performing a position fix. During an updated position estimate, the device requires no interaction with the network, and the accumulated impact of this feature results in a device with many-year battery life on a 2350 mAh AA battery.
Figure 6 illustrates the breadcrumbing use case. An asset location is estimated, and a log of these estimates is analyzed periodically. For example, an asset location might be estimated every 15 minutes and once a week the asset breadcrumbs are processed. This technology is used for a variety of applications. For example, at a given time a shipping company may require monitoring tens of thousands of pallets containing shipments to customers. A small, low-cost tracker is attached to each pallet, adding location intelligence to the system. A long battery life for such an application is essential because it simplifies deployment and lowers operating costs.
Breadcrumbing can also be used for contact tracing in managing an epidemic. Public health agencies in affected regions can provide small, low-cost, power-efficient trackers to residences. If a breakout occurs at a particular market at a particular time, all residents who visited the market can be notified and treated accordingly. Residents who are not impacted can maintain their normal daily routines.
The battery life analysis performed above for the geofencing application is now applied to this application of breadcrumbing. Here, the position estimate is performed less frequently—every 15 minutes. The GPS device battery is extended to 43.9 days, and the cloud-based cellular device has a battery life of 58.4 days. The hellaPHY device has a battery life of 2935.4 days, which is 70 times longer than the GPS device.