The Internet of Thing (IoT) has forced embedded developers to change the way they develop and create embedded products. Previously developers only needed to the focus on integrating sensors and electronic peripherals with a microcontroller. With IoT, developers now need to deal with establishing an internet connection which requires selecting between various connectivity options such as Ethernet, Wi-Fi, and cellular whilst also managing the various protocol stacks required to support those options.
While Wi-Fi and Ethernet are relatively mature connectivity technologies, cellular represents a new frontier for embedded developers and IoT. Prior to a few years ago, cellular was a nonstarter for many IoT applications as the power consumption and implementation costs made cellular unusable except for limited applications. Part of the limitations of cellular were due to the fact that originally cellular networks were designed to be able to seamlessly transmit voice calls from a phone where the call needed to be passed from cell tower to cell tower. This architecture required constant communication between the cell tower and the phone in order to ensure this level of call quality. The constant communication meant high power consumption on the part of the cellular application. Also, the requirement for high-quality communication for voice meant that the cellular networks and data plans were priced to ensure that those voice calls could go through seamlessly.
With IoT, the use case for cellular has shifted. Rather than humans making voice calls over the airwaves, now devices are transmitting small amounts of sensor data. IoT devices do not require the same quality of connection as a voice call and many IoT applications are stationary versus moving as in the case of voice calls from a phone. In response to this changing use case for cellular, many of the cellular standards organizations and mobile carriers rolled out new cellular technologies targeted for IoT applications. Two new networks are CAT-M and NB-IoT which are two different types of 4G LTE technology. CAT-M and NB-IoT reduce the power consumption of cellular by allowing IoT devices to remain in sleep mode for extended periods of time and reconnecting to the cellular network within seconds versus minutes. These new networks accomplish this optimization by using unlicensed and unused guard band frequencies between channels of licensed cellular spectrum that allow high priced voice calls to coexist with data being sent by IoT devices.
CAT-M1 and LTE CAT-NB1(NB-IoT) are well suited for remote or mobile applications such as those not near a fixed internet connection such as Ethernet or Wi-Fi such as asset tracking, wearables, parking meters, agriculture monitors, and city infrastructure. CAT-M1 is best suited for IoT applications requiring high reliability and low latency. CAT-M1 supports authentication, credentialing, and encryption and most North American carriers have worked to deploy CAT-M1 first. NB-IoT does not support handoff between cell towers while the device is in the connected state, instead, devices can only select and connect to a cell tower when device connection is idle. With this mobility restriction, NB IoT is better suited for devices and sensors that transmit data infrequently such as those that remain in a sleep or idle mode and only periodically connect to a cell tower. Unlike CAT-M1, NB-IoT does not support voice calls. Cellular carriers in Europe have primarily deployed NB-IoT networks first.
In an effort to help embedded developers quickly and easily evaluate cellular technologies like CAT-M1 and NB-IoT, Renesas has created the AE-CLOUD2 kit. AE-CLOUD2 can be used by embedded developers to rapidly build IoT applications using built-in sensors for temperature, microphone, humidity, GPS, magnetometer, as well as the ability to connect using cellular, Ethernet, or Wi-Fi. AE-CLOUD2 comes with a BG96 cellular shield that supports CAT-M1 and NB-IoT frequencies as well as 2G and GPS. The cellular integration of AE-CLOUD2 allows embedded developers to quickly evaluate cellular connectivity options. Also, AE-CLOUD2 comes with global certification so that the cellular connectivity can be used anywhere in the world as part of an embedded evaluation or even as an initial prototype board. Depending on the firmware image loaded, AE-Cloud2 can either connect to the Synergy Enterprise Cloud Toolbox or the IoT cloud of your choice. The Synergy Enterprise Cloud Toolbox is a reference design that allows connection to Amazon Web Services, Microsoft Azure, or Google Cloud Platform in as little as ten minutes. The Synergy Enterprise Cloud Toolbox from Renesas connects to a web dashboard to visualize the sensor data.
- Rapid evaluation, prototyping, and development of cloud connection application
- Quickly and seamless evaluate emerging cellular technologies of CAT-M and NB-IoT
- Software support for connecting to cloud services from Amazon, Microsoft, and Google
- Certified and configured cellular development tool with cellular frequency support and certification for use anywhere in the world
- Cellular, Wi-Fi and Ethernet connections included
- Comes with a host of sensors including GPS
For AE-CLOUD2 when we looked to integrate cellular we were faced with many of the same challenges that embedded developers encounter as they create cellular IoT devices. The first decision was the type of cellular embedded solution to use. For adding cellular to AE-CLOUD2 we had the typical options before us of using an embedded cellular chipset, an embedded module, or an embedded device board.
As background, all embedded applications that incorporate cellular start with a chip that provides the RF radio in order to be able to connect to a cellular network. While it is certainly possible for an embedded designer to integrate a cellular chip into an embedded design, starting with a chip requires a larger investment of engineering time and effort as well as the cost of certification of the device. Rather than using an embedded chipset, an embedded engineer can use a module which is well suited for lower volumes due to the lower complexity and overall cost of the embedded solution. Modules are often commercially available and often the network certification has already been performed by the module manufacturer. When we created the AE-CLOUD2 kit we could have integrated a modem chip into the design, but we chose to use a preconfigured cellular module to speed up our development time.
Even though we had selected a cellular module to speed up the embedded development, we still ran into issues with integration that embedded cellular applications often encounter. Integrating the cellular module required us to negotiate the technical troubleshooting between the module manufacturer, cellular chip company, mobile carrier supplying the data plan, and the IoT cloud that the embedded device was connecting to. For example, an issue we ran into is that the embedded device could not connect to the IoT Cloud. As the first troubleshooting step, we had to ensure that the correct AT command sequence was being sent to the cellular chipset. Problems with the AT command set can be related to the firmware version of the cellular chipset which needs to support the cellular frequencies that will be used. In the course of developing cellular kits, we have had problems where the cellular chipset had to update the firmware in order to correct issues with the supported AT command set or to add support for an additional cellular carrier. Assuming the correct AT command set is being sent, then the next step is to work with the cellular carrier to ensure that the cellular modem, as well as the data plan from the carrier, are working correctly. For connecting to the cellular network issues that can arise include ensuring adequate network coverage and signal strength in your local area. While we were developing AE-CLOUD2 we encountered an issue with lack of cellular reception in the lab. To address the lack of reception we needed our IT department to augment the cellular reception in the building in order to be able to test the cellular connection. Lastly, like most cellular embedded developers, we had to be the managing party in order to coordinate the various technical stakeholders in order to troubleshoot and root cause the issues we were seeing.
Another issue we encountered was getting the AE-CLOUD2 kit certified for global use. In order to achieve RF certifications globally, we had to go through multiple rounds of RF testing and design. For RF certification a prescan is done prior to submitting a device for certification. For AE-CLOUD2 we had to go through rounds of testing and debugging in order to pinpoint to specific boards issues that were preventing the kit from passing the RF certification testing. The emitted RF noise from the kit was exceeding the allowable threshold in order to pass the certification testing. While this extra testing certainly added delay and cost to AE-CLOUD2, the benefit of having a kit that could be used globally was worth the effort for us since we have a global customer base.
For the cellular embedded software development, AE-CLOUD2 uses the Renesas Synergy™ Platform, which provides professional grade tools for building IoT products. The embedded software code for AE-CLOUD2 is built using the Synergy Software Package (SSP) which includes TLS, MQTT, and Wireless Application Frameworks. The Wireless Application Frameworks provide for easy implementation for technologies like Wi-Fi, cellular and Bluetooth Low Energy. The NetX Secure TLS secures and authenticates communication between devices and cloud, while the MQTT for NetX Duo enables communication for devices that only send smaller amounts of data. These components provide SSP the means to connect to any major cloud service provider with little to no barriers to getting started.
AE-CLOUD2 also uses the SSP Cellular Framework module as a high-level application layer interface for the cellular modem integration on the SSP Application Framework and provides sets of APIs to provision, configure and to communicate with the cellular network for data communication. Cellular Framework uses the SSP Application Framework (console framework) to communicate with the Cellular modems with serial interface by using AT commands internally. SSP Application framework also creates the serial data pipe over serial interface for the data communication, leveraging the PPP WAN protocol provided by NetX™. Any TCP/IP communication can be established over this Wide Area Network (WAN) link using the sockets, NetX Application protocols, and IoT protocols such as MQTT or COAP. The Cellular Framework also provides the framework level Socket APIs to communicate with the TCP/IP stack present on-chip (inside cellular hardware module) in certain cellular hardware modules and thereby communicating with the internet network, using the socket APIs.
With the advances in cellular for IoT, embedded developers will always need better tools to help them quickly adapt and incorporate new technologies. The AE-CLOUD2 kit can do just that and help developers stay on top of the ever-changing landscape of IoT and cellular.
To find out more about the Renesas AE-CLOUD2 kit go to www.renesassynergy.com/ae-cloud2