Upgrading IoT Devices with Cellular Connectivity - Part 2
Author: Manu Kemppainen, Bittium Fellow
In part 1 of this blog post series, we described the principle of how to take data transmission of medical devices, or any other IoT device, to the next level – by integrating cellular connectivity directly into the device. This approach enhances ease of use by removing the need for user configuration and enables remote control from the cloud, which make patient care more efficient.
In part 1 we also introduced a number of challenges involved in the design of a medical device with cellular connectivity. These challenges we needed to address in our evaluation phase.
This part 2 of the blog post series goes through the highlights of that evaluation phase.
Evaluation Aspects
Device Size
Device size is a critical consideration for any wearable medical device. The device should ideally be unnoticeable and lightweight not to complicate its use. A very compact device size can however create a number of challenges for product development. The key challenges we addressed include:
Antenna performance/Antenna design: Since medical devices are carried all the time, the device is mainly used indoors. In this case we used 4G low power wide area (LPWA) network technology, LTE-M1, which is targeted for low data rate Internet of Things (IoT) type of use cases.
LTE-M1 network coverage was evaluated with different frequency bands. There are higher bands available and used for the LTE-M1, but coverage of those bands is limited. We focused on getting good performance also on lower LTE-M1 frequencies (typically 700/800 Mhz). The low frequency antenna requires more room within the device than the higher frequency antennas. The actual antenna design is a challenge with these small devices due to limited space for antenna radiators and limited length of the ground plane. Ground plane (PCB board size) plays a significant role in the performance of the device antenna. Small antennas operate at quarter wavelength which requires a certain ground plane length to perform optimally. The antenna of a wearable device is in close proximity to the body and causes attenuation to the antenna signal. Antenna design must be taken into consideration in hardware and mechanical design – especially with wearable devices – due to the fragility of the antenna performance caused by body, hardware, mechanics, and materials.
Our antenna experts were able solve the challenges by designing a custom antenna integrated with the product. We also utilized antenna tuning to improve performance and fulfill operator TRP/TIS requirements.
Temperature/Thermal design: The surface temperature of a wearable medical device always needs to stay below 43 °C. Small devices with cellular modems transmit RF energy which may produce excessive heat. We needed to manage the device power consumption, surface temperature and overall thermal characteristics of the device.
For optimal thermal design, we utilized thermal simulations when designing the mechanics. We made preparations to control the temperature also with software in case the temperature rises due to user behavior (i.e. device covered up, sauna, etc.).
Battery size/Power consumption: When the space inside the device is limited, also the battery must be small. Typically, very small capacity batteries do not produce enough discharge current to cope with the needs of the cellular modem. We needed to solve how to fit in a battery that is big enough and how to maximize the battery life.
Our solution was to introduce a layered mechanical design where we have a separate compartment for the battery.
Data Transfer Capacity
Data transfer capacity requirements create several different challenges for product development. During the evaluation phase we addressed these key aspects:
Simulated network throughput: Prior to live network throughput tests, we needed to address the bottlenecks in the communication link. To understand the capabilities of the modems, we tested modem throughput and behavior in Bittium´s internal RF laboratory with a simulated network connection. Testing revealed some differences between the modem module candidates to be used in the product.
Live network throughput: In the live network, the maximum cellular speeds are rarely reached. We needed to know what is the minimum, typical average, and maximum LTE-M1 cellular network speed in the live network with different target operators.
Since we were looking at designing medical devices that measure biosignals and send the data for analysis, we concentrated on the uplink data throughput – i.e. the speed at which data is transferred from the device to the cloud. Network speed depends highly on the cellular RF signal reception and core network capacity and configuration. It is possible that server-side bottlenecks also cause some fluctuation in network speeds, but that is a rare case with LTE-M1 transfers.
We executed heavy field testing, including over 2000 km drive tests, and collected 15000 measurements from the devices on the field for evaluation.
Subscription/Operator agreement: Typical LTE-M1 subscription models go up to 30 MB/ month rates. Since live measurement of a patient creates a lot of data, we needed a subscription model with up to 1 GB/month data rate and affordable cost.
We started negotiations with the operators and found a case-specific solution for the subscription.
LTE-M1 network monitoring: To maintain good battery life, the device needs to be aware of and sensitive to what is happening with the network. The device needs to evaluate if the current network connection causes too much additional power consumption or other problems.
An analysis of the capabilities of the LTE-M1 modem and its recovery procedures were evaluated and implemented.
Battery Life
Maximizing the battery life in typical use cases for medical devices created challenges with regard to the modem power consumption
Theoretical battery life/Target battery life: Similarly to our typical product development projects, we needed to carry out power consumption calculations to find out the actual theoretical battery life of the device. In addition, calculations are always needed to define the target battery life and take into account the budget, schedule, response time, and other aspects of the device that affect the battery life. The device power consumption is rarely so critical that all power saving techniques would be applied.
We calculated the theoretical maximum power consumption and actual battery life estimations.
Simulated modem power consumption: We modelled the modem power consumption in different use case scenarios with the modem module candidates to evaluate the power consumption of each one.
We tested the power consumption with a simulated network connection in Bittium´s internal RF laboratory.
Modem power consumption in a live network: Since the laboratory tests do not directly mirror the results in a live network, we needed to extend the modem power consumption testing to a live operator network with mobility.
We tested the power consumption in a live network and partly combined it with the Live network throughput field testing mentioned earlier.
Software Architecture
As a final step, we focused on the reusability of the existing device software and hardware for the newly designed device.
Multi-MCU/Run code inside the modem: Medical devices without cellular connectivity rarely contain TCP/IP stack or additional resources to fully control all the procedures required by the modem. We used this as a requirement for our approach.
We developed a new software architecture which is based on the capability to run software code inside the modem module. This means we are running a multi-MCU software architecture, where one part is responsible for the patient biosignal measurement, and the other part (modem) is responsible for all the communication to the cloud.
We implemented the preliminary modem code already in the field testing phase where we utilized the code for testing the modem capabilities.
Work split/Code split: The biggest challenge in the multi-MCU environment is the work split between the “actors´. In our design we have re-used host MCU software, and we are adding the modem module to the design. The location of the TCP/IP stack for the cloud communication, data processing work split, process bookkeeping work split, storage work split, and others needed to be addressed.
We defined a work split where changes to the existing device and its functionality are minimized.
Modem control: Current LTE-M1 modems are mostly controlled using the AT-commands that are defined either by 3GPP or are proprietary to the device vendor. As an example, LTE band lock is one of the features that are not defined by 3GPP and are always vendor specific. In this case, vendor dependent control modules needed to be defined, designed, and added to the software on top of the basic 3GPP control modules.
We defined and implemented a Modem Manager to execute the main modem control.
Security: A device and its connections always require security. There are several options from external security chips to secure solutions integrated in the modem. Since our communication software is already running inside the modem, we utilized security solutions from the modem vendor on top of the existing security features of the medical device itself.
This study on how to build re-usable software architecture ended up being something that can be groundbreaking for any device that needs cellular connectivity.
In the third and last part of this blog post series, we will take closer a look at the re-usable software solution we developed and how we can apply it to any IoT device.
Want to know how we could help with your product? Visit Bittium Cellular IoT Solution, Engineering Services for Healthcare & Medical, and Engineering Services for Industrial IoT and contact us!
Manu Kemppainen, Bittium Fellow
Manu Kemppainen has over 30 years of experience in embedded software design and device development. He works as a Fellow at Bittium and has been with the company since 1999.
