Looking for information on specific technology topics, or just curious to learn more about recent IoT trends? We welcome you to explore our IoT wiki and research what drives the industry.
The integrated SIM card referred to as nuSIM has been developed especially for Internet of Things applications where the cost factor, battery efficiency, and simplicity along the value chain are decisive. This makes a perfect sense for Mobile IoT technologies, such as NB-IoT or LTE-M, among others. In the IoT Solution Optimizer, you can use the Hardware, Module and Chipset Selection Guides to quickly identify which IoT devices and components have built-in connectivity using nuSIM technology.
Figure: nuSIM Logo
Typical Massive IoT applications such as smart parking, networked street lamps, and garbage cans, or environmental sensors in buildings and cities, use devices on a massive scale. As a deployment of large volumes of hardware may be associated with significant cost, nuSIM was created to reduce this factor, thus better suiting these cost-sensitive IoT applications. The nuSIM dispenses therefore with the functions found in eSIM that are superfluous for many IoT scenarios which result in an increase to the cost per SIM. Features such OTA profile download, multiple profile support, profile switching, etc. are not supported. A smart meter, such as a networked water or electricity meter, for example, might send a tiny data packet into the network once a day and would not require such functions like voice or SMS. Also, nuSIM profiles are much smaller, below 500 Bytes. This all makes the nuSIM extremely slim and cost-effective. In addition, it requires less energy than a conventional eSIM, thus extending the battery life of IoT devices.
The nuSIM is designed as part of a chipset and is therefore less sensitive to shocks or large temperature fluctuations than the SIM in a card slot. That’s an advantage when used in Industry 4.0, for example, in a factory or on a construction site. The absence of a SIM card slot also makes the closed design of a device possible, protected from moisture and dust. The nuSIM thus achieves a service life of at least 10 years, in other words it usually lasts as long as the component itself. In addition, it’s almost impossible to access a nuSIM soldered into a device in order to manipulate it. The security level corresponds to that of a changeable SIM. The login information stored in encrypted form on the SIM card enables secure and private access to mobile networks and guarantees the integrity of billing – which is particularly important for roaming, for example when a truck with a tracking module is driving across Europe. The operator profile is programmed by module and device manufacturers directly onto chip during the production process. As a result, the nuSIM offers the end user out-of-the box mobile Internet access.
Figure: nuSIM vs. eSIM
Figure: nuSIM and eSIM Address Different Segments
Since its commercial launch of IoT services, Deutsche Telekom has invested to scale up its M2M and IoT business by certifying the world's largest portfolio of wireless communication radio chipsets and modules. To-date, over 50 NB-IoT and LTE-M modules have successfully passed interoperability testing on numerous Deutsche Telekom networks, securing a best-in-class quality of connectivity, faster time-to-market, and the widest range of implementation choices for our customers. This complements a rapidly-growing segment of 100 certified modules for 2G, 3G, 4G and 5G radio access bearers.
Figure: Certification Reduces Testing & Costs for IoT Devices
Our current certification lists include numerous single-mode (NB-IoT) and multi-mode (NB-IoT, LTE-M, 2G) solutions from suppliers worldwide. By collaborating closely with the industry, Deutsche Telekom aims to scale-up the IoT business for itself and a whole ecosystem of partners. We work with chipset suppliers to identify interoperability issues in their protocol stacks early on; this ensures that the connectivity "DNA" of many OEM and ODM modules can be improved well in advance. Each product in our portfolio is assessed for performance (power consumption, throughput, latency) as well as interoperability against key features of our networks. Not only do we certify an initial commercial firmware, but we track each product during its lifecycle to regularly assess potential design improvements. It is our commitment to ensure the best connectivity platform possible with our partners for your M2M and IoT solutions.
Figure: Certification Follows the Product Lifecycle
For the latest list certified wireless communication modules, please refer to the Certification documentation on the IoT Digital Shelf: https://tsi.iotsolutionoptimizer.com/Learn/UserGuides.
Please note that most of the NB-IoT and LTE-M components have been characterized for power consumption and integrated into the IoT Solution Optimizer service for virtual twin modeling.
The "Cloud of Things" is a cloud-based Software as a Service (SaaS) offering for remote device monitoring and data management. It enables you to manage and control remote assets and allows real-time data analytics through secure data transfer. Thanks to this highly scalable solution, you can easily build your own device network that is perfectly suited to your business.
The Cloud of Things platform is offered as a fully managed service and can be accessed through common browsers on
personal computers, tablets or smart phones. The Cloud of Things web portal enables you to view all your registered devices and manage them remotely. The portal provides a dashboard for the graphical display of collected data, alarms or defined parameters (KPIs). The Cloud of Things web portal provides three main functionalities:
To learn more about the Cloud of Things, please vist our webpage: https://iot.telekom.com/iot-en/platforms/cloud-of-things
Deutsche Telekom pursues an IoT device strategy that accelerates integration of solutions into its service platform, the Cloud of Things. Please refer to the attached process document ("IoT Device Strategy_HW.pdf").
To trigger the onboarding process, suppliers should fill out the application document ("Application Hardware Partnering.docx") and send it to the E-mail address mentioned within the document. Following that, Telekom representatives will set-up a cloud account for your development teams so that they can conduct their tests against our cloud. The attached NB-IoT API description ("20170802-NBIOT-Protocol-Developerguide.pdf") is provided to help partners implement the required APIs properly. The test case catalog ("TestCaseCatalog_NB-IoTConnector_final_v1-0.docx") for the cloud connector for NB-IoT focuses on the MQTT-SN API interface. By selecting those test cases in the catalog which are relevant for your device, it is possible to self-declare compliance and proper implementation by filling out the results template ("SelfTestReport_NB-IoT_v2-5.docx").
Figure: Benefits of a Hardware Partner Co-operation
The following documents are provided:
Naturally, the best way is to integrate the APIs into a whole family of products is to do it on chipset- or module-level. As such, Deutsche Telekom works closely with industry partners to scale-up cloud integration. Please contact your module vendor to inquire as to the native integration of our Cloud of Things MQTT-SN APIs.
We look forward to reviewing your results and integrating your device into our partner catalog!
Machine-to-Machine (M2M) refers to vertical, purpose-built solutions allowing communication between devices of the same type and a specific application, all via wired or wireless communication networks. Most M2M solutions are business-to-business (B2B)-focused, although business-to-consumer (B2C) applications also exist:
Figure: M2M Applications are Independent Vertical Silos
M2M solutions share several characteristics:
Figure: M2M Solution Characteristics
M2M is not a new set of technologies, as it's been around for almost a decade. What makes it more and more relevant is the growing pressure across multiple industries to optimize their operations, to do more with less resources. Requirements are driven by efficiency improvements, sustainability goals or improved health and safety. There is also demand to better understand the physical environment and improve enterprise, consumer, governmental and societal value chains. In today's world, we have entered the crucial moment when the shooting demand starts converging with the availability of enabling technologies, available at the right cost. This is due to:
Application areas where M2M is rapidly rapidly growing include:
The components of M2M system solutions always consist of several key elements:
Figure: M2M System Solution Architecture
The Internet of Things (IoT) refers to a horizontal set of enabler technologies, systems and design principles which integrate multiple vertical M2M application and device solutions. Unlike M2M, IoT is:
Whereas M2M is predominantly implemented for B2B, IoT facilitates the emergence of B2C segments and new ecosystems, leveraging cloud-based models (open web- and “as-a-Service”-enabled). For IoT there is a shift away from device and connectivity-centricity towards services, data and intelligence. The current M2M model of disconnected silos with own stakeholders, ownership, information, processes and services, is integrated into a “common fabric” of services and data. The promise of IoT is that the Internet will no longer be about people, media and content, but shall include all real-world assets, as intelligent nodes, exchanging information, interacting with people, supporting business processes of enterprises and creating knowledge.
Figure: IoT brings a Cloud Service-Based Society
The opportunities of IoT are cross-value chain, with value system integration across ecosystems. This helps maximize the efficiency in operations, and many existing and new actors may assume diverse roles providing new services. That said, new challenges also emerge, particularly centered around the increasing complexity in information and service management. There is clearly a need for more powerful analytics tools, visualization software and decision support systems. It is not surprising that advocates of proprietary IoT are heavily investing to build up these capabilities. Furthermore, a real-time control of complex operations and autonomous control systems will likely require distributed application software architectures, and real-time capability in networks. Numerous mobile network operators invest heavily in edge computing technologies to enable this new paradigm.
Common IoT use cases are ecosystem-centric. This means that in comparison with the M2M verticals, there are numerous new capabilities which in today's world have yet to become reality:
So how is IoT actually implemented?
IoT introduces a common framework so that M2M applications can share M2M infrastructures, environments and networks:
Figure: IoT breaks down the M2M Silos
The horizontal application enablement allows the IoT system integration, acting as an connectivity layer-agnostic middleware, connecting producers and consumers securely, and transparently. It supports diversity across:
The oneM2M standard introduces mandatory or optional sub-functions called Common Service Functions (CSF) under the Common Services Entity (CSE) component. This represents an instance of a set of CSFs in M2M environments.
Figure: Common Service Functions (CSF) in IoT
oneM2M standard employs a simple horizontal, platform architecture fitting within a 3-layer model of applications, middleware services and network services. The "Application-Network-Device"s Model of M2M vertical silos is replaced in IoT with a horizontal "IoT Device-Gateway-Server Model." The application logic of M2M solutions sits as an Application Layer on top of the common Service Layer enabler, and a Network Layer below it handles device management, location services, device triggering, etc. For the latter, oneM2M standardization specifies the Network Service Entity (NSE), which provides the Service Layer with network services supported by the underlying network.
Figure: IoT Device-Gateway-Server Model
oneM2M standardization also defines the Application Entity (AE), which contains the application logic of M2M solutions. Underlying networks provide data transport services between entities in the oneM2M System. Such data transport services are not included in the NSE.
Figure: Building a Common API for IoT
The IoT Solution Optimizer is fully compatible with the oneM2M standard. oneM2M protocol overhead is to be considered in your design as part of the application payload, which is wrapped in a messaging, management, and/or transport protocol - or sent over Non-IP Data Delivery to/from the IoT Device.
An IoT device is the remotely-deployed equipment (also traditionally referred to as "User Equipment", UE) that is used in M2M and IoT applications to monitor assets via sensing and actuation capabilities. Different realizations are possible, from low-end sensor nodes to high-end complex devices with multimodal sensing. Such IoT devices are used to capture data about events and assets, for example: inventory levels, climate, etc. The collected data is usually sent over a Wide Area Network (WAN), such as the 3GPP™ mobile operator network; rarely, they are connected directly to the Internet. In many cases, the IoT Device also supports Local Area Network (LAN) access technologies for exchanging data with other IoT devices or a collecting node with WAN-capability, referred to as a "gateway." The IoT device may itself act as such a gateway, referred to thereby as an "advanced IoT device," communicating with multiple "basic IoT devices" over its capillary network, or "M2M Area Network."
The need to support diverse use cases, or applications (ranging from asset control, remote monitoring and Smart Home, to PoS and vending machines) means that the hardware is typically purpose-built for the tasks at hand. Needless to say, most IoT devices do share common components and architectures. Specifically for NarrowBand IoT, it is critical to carefully select these components in order to achieve a highly-optimized, power-efficient design which delivers on the business case.
Figure: Common IoT Device Components
When assessing implementation aspects of an IoT device, it is necessary to consider its three solution layers:
The application logic running on the IoT device’s Microcontroller (MCU) and exchanging data with the IoT service platform runs on the microcontroller (MCU) represents the Application Layer. It sends AT commands to the IoT device’s integrated communication module/chipset in order to make use of mobile network bearers over the Connectivity Layer. Please note that the IoT device application usually sits on top of the IoT service provider’s Service Layer client.
Figure: Solution Layers of IoT Services
The term "IoT application" may refer to three different things:
Within the context of the IoT Solution Optimizer service's configuration screens, the last definition is what is being referenced.
Smart agriculture also known as smart farming is a concept to improve the crop by integrating newest technologies like sensor networks in agriculture. Those solutions should help to transform and reorient agricultural processes to ensure efficiency gains react on climate changes and secure food for upcoming population grows. Also predicted rain falls should help farmers by planning their crop calendars. With sensor networks it is possible to monitor the conditions of the agricultural areas regarding soil moisture, temperature, nutrient deficiency and helps to reduce bad harvests and costs and increase yields.
The tracking of assets empowers your business to perform constant monitoring of your valuable goods. Questions about where a company's valuable mobile devices and machines are currently located are a thing of the past. Asset Tracking lets you localize important assets and machines at any time, avoiding delays and unnecessary, expensive replacements of misplaced assets. In case of theft, Asset Tracking can trigger an alert quickly and expedite the resolution of the case. After all, the theft of working tools and supplies, machinery, and materials from companies and construction sites, for example, causes heavy losses every year.
Just some examples where asset tracking can save money and time:
Imagine a world where manufacturers and service providers can know in advance when something will go wrong with their machines.
In industry, every machine failure or production downtime causes companies great expense. With condition monitoring, companies can easily check the status of their machines and intervene whenever necessary. Many sensors within the machines produce huge volumes of data that can be analyzed. A particular threshold is specified that the data stream's values must not exceed. As soon as this particular threshold is reached, the system sounds the alarm.
Predictive maintenance brings an early warning system on top of this data. Through the use of artificial intelligence, technicians can intervene remotely or on the spot, before the thresholds are met. Possible anomalies are identified, and a comparison is made with previous incidents that have already happened. This allows business to assess the entire stock of deployed machines for the risk of possible future failure.
The smart energy grid digitizes native electricity networks, improving the reliability and transparency of the whole energy supply chain. Two-way digital communication supplies electricity towards customer with benefits. The focus of Smart Grid is the autonomous communication between electricity producer, power storing components and consumer. Advanced analysis tools, monitoring and control features makes it possible to maximize efficiency and reduce power losses and costs in the whole electricity supply chain.
In case of renewable energy technologies, Smart Grid is a must because electricity production depends on weather conditions (e.g. solar energy needs sun). Smart Grid responds on conditional changes and chooses the most efficient source. The included energy management applications help to reduce cost by automatically changing the criteria for selecting power sources (e.g. consumption during higher costs).
The key features of Smart Grid are:
The applications of IoT in environmental monitoring are broad − environmental protection, extreme weather monitoring, water safety, endangered species protection, commercial farming, and more. In these applications, sensors detect and measure every type of environmental change.
Air and Water Pollution
Current monitoring technology for air and water safety primarily uses manual labor along with advanced instruments, and lab processing. IoT improves on this technology by reducing the need for human labor, allowing frequent sampling, increasing the range of sampling and monitoring, allowing sophisticated testing on-site, and binding response efforts to detection systems. This allows us to prevent substantial contamination and related disasters.
Though powerful, advanced systems currently in use allow deep monitoring, they suffer from using broad instruments, such as radar and satellites, rather than more granular solutions. Their instruments for smaller details lack the same accurate targeting of stronger technology. New IoT advances promise more fine-grained data, better accuracy, and flexibility. Effective forecasting requires high detail and flexibility in range, instrument type, and deployment. This allows early detection and early responses to prevent loss of life and property.
Today's sophisticated commercial farms have exploited advanced technology and biotechnology for quite some time, however, IoT introduces more access to deeper automation and analysis.
For example, the sensors measure moisture at different levels, and send data to a central system. The system analyzes this data and waters only the crops in need. Much of commercial farming, like weather monitoring, suffers from a lack of precision and requires human labor in the area of monitoring. Its automation also remains limited. IoT allows operations to remove much of the human intervention in system function, farming analysis, and monitoring. Systems detect changes to crops, soil, environment, and more. They optimize standard processes through analysis of large, rich data collections. They also prevent health hazards (e.g., E.Coli bacteria) from happening and allow better control.
Health-related issues can directly impact the quality of life of a person and development of a nation, and as the world population rises and healthcare costs continue to skyrocket, more individuals and organizations across the healthcare industry are looking for ways to reduce costs and improve patient care. The Internet of Things (IoT) has numerous applications in healthcare, from remote monitoring to smart sensors and medical device integration. It increases both the accuracy and size of medical data through diverse data collection from large sets of real-world cases. It has the potential to enhance existing technology, and the general practice of medicine by improving how physicians deliver care, as well as keep patients safe and healthy and reduce costs.
Real-time Health Monitoring
IoT health monitoring traces patient's health with the assistance of sensors and Internet. The health observation system can keep track of patient's pulse rate, eco rate of heart, pressure level rate, temperature etc. If the system detects any abrupt changes in patient heartbeat or temperature, the system mechanically alerts the user concerning the patients standing over IoT and additionally shows details of heartbeat and temperature of patient live over the Internet. One of the better ways is where the doctors are able to certainly and quickly use the relevant patient information through the help of IoT to take suitable actions. This tremendously improves the quality of information and the patient care in the Medical field. Making use of embedded wearable sensors, the system monitors the health parameters dynamically.
Remote Health Monitoring
The Internet of Things improves patient safety and provides better customer experiences through remote health condition monitoring. Healthcare providers can access real-time patient data frequently, giving them better visibility into patient health and allowing them to provide timely support and treatment. Physicians can serve more patients by allowing some individuals to return home to finish treatment while medical staff continues to monitor their condition remotely, thus reducing costs associated with lengthy hospitals stays and improving the patients satisfaction. Healthcare companies are expanding their in-home services by using remote condition monitoring to offer new independent living solutions designed for aging and disabled populations. IoT has been widely used to interconnect the available medical resources and offer smart, reliable, and effective healthcare service to the elderly people. Health monitoring for active and assisted living is one of the paradigms that can use the IoT advantages to improve the elderly lifestyle. In this paper, we present an IoT architecture customized for healthcare applications. The proposed architecture collects the data and relays it to the cloud where it is processed and analyzed. Feedback actions based on the analyzed data can be sent back to the user.
Mobile medical equipment (e.g. a portable ultra-sound machine), in hospitals, is used by different patients and sometimes it might be difficult to locate where the equipment was last used. IoT helps tracking medical equipment. It can also provide predictive maintenance of the equipment to ensure that the equipment does work when needed.
Perhaps the greatest improvement IoT brings to healthcare is in the actual practice of medicine because it empowers healthcare professionals to better use their training and knowledge to solve problems. They utilize far better data and equipment, which gives them a window into blind spots and supports more swift, precise actions. Their decision-making is no longer limited by the disconnects of current systems, and bad data. IoT also improves their professional development because they actually exercise their talent rather than spending too much time on administrative or manual tasks. Their organizational decisions also improve because technology provides a better vantage point.
Medical Information Distribution
One of the challenges of medical care is the distribution of accurate and current information to patients. Healthcare also struggles with guidance given the complexity of following guidance. IoT devices not only improve facilities and professional practice, but also health in the daily lives of individuals.
The advanced automation and analytics of IoT allows more powerful emergency support services, which typically suffer from their limited resources and disconnect with the base facility. It provides a way to analyze an emergency in a more complete way from miles away. It also gives more providers access to the patient prior to their arrival. IoT gives providers critical information for delivering essential care on arrival. It also raises the level of care available to a patient received by emergency professionals. This reduces the associated losses, and improves emergency healthcare.
Much of current medical research relies on resources lacking critical real-world information. It uses controlled environments, volunteers, and essentially leftovers for medical examination. IoT opens the door to a wealth of valuable information through real-time field data, analysis, and testing. IoT can deliver relevant data superior to standard analytics through integrated instruments capable of performing viable research. It also integrates into actual practice to provide more key information. This aids in healthcare by providing more reliable and practical data, and better leads; which yields better solutions and discovery of previously unknown issues. It also allows researchers to avoid risks by gathering data without manufactured scenarios and human testing.
Better resource management, optimized processes, enhanced customer experiences and minimized costs: the transport and logistics sector is far ahead of other sectors and large parts of industry when it comes to digitization.
Image Transport and Logistics
The transport and logistics sector benefits from digitization and gives it impetus. Thanks to new digital technologies, this comparatively labor-intensive sector has been able to coordinate its considerable organizational efforts more efficiently and improve customer and partner contacts, use digital technologies to further develop its business models and thus attract new customers and open new markets.
Growing Transport Volumes
Companies show that the market is changing and shifting. Since the carrier started making deliveries to consumers its volumes have risen dramatically, forcing them to confront significant challenges. Because consumers expect delivery in 24 hours. And they want to be able to trace their delivery at all times.
Transparency is Key
Speed and transparency are absolute musts. Freight carriers wanting to offer their customers seamless shipment tracking must start by digitally connecting their drivers and vehicles and synchronizing the resulting data at their head office. This makes it possible to keep customers informed about their delivery's location and status at all times and provides a complete overview of the transport chain.
Information and communication technologies are essential components of the digital transformation: Thanks to optimal connectivity, cloud computing, big data and security, in the interconnected world of the Internet of Things machines, devices and sensors can realize their full potential and provide optimal solutions for air and cargo ports, passenger transport, rail and road freight traffic and fast growing parcel delivery services. Connected processes help optimize storage facilities and devise new transport routes and options, for example. Moreover, shipments and vans can be monitored remotely and downtime avoided through predictive maintenance.
Smart meter devices provide real-time data on electricity, gas or water consumption of the customers back to the supplier itself. Consumers can receive more specific statements about their energy consumption. Detailed feedback on energy consumption with accurate real-time data from smart meters is available and power outages can be reduced by more precise forecasting. Smart metering is part of the smart grid concept.
What is the Smart Parking business about?
The number of vehicles on the road is rapidly outpacing the supply of available parking spots. Searching for a parking spot in the city often means wasted time and extra fuel costs for drivers, as well as unnecessary air and noise pollution for residents. Parking has become a widespread issue in urban development. This problem can be mitigated by introduction of smart parking. Smart parking aims to help individually match drivers to parking spots, improve parking space utilization, reduce management cots, and alleviate traffic congestion.
What are the key benefits of Smart Parking?
Smart Parking solutions collect parking data (such as occupancy and duration), and relay this information to service providers. This improves fee collection and reduces economic losses. Drivers can obtain the real-time parking space information. For example, when only few parking spots are available, drivers can be directed to the next vacant spot. This eases traffic congestion cause by frustrated drivers searching for potential spots. Furthermore, self-help payment saves manpower and allows parking service providers to reallocate labor from toll collection to parking supervision.
Pet tracking solutions have been designed to allow a quick and reliable identification of pets’ location. These devices are often regarded as tags due to their small form-factor, adjusted to fit even small pets like cats, and offering an extended durability for harsh outdoor conditions. Pet trackers which rely on the Mobile IoT network provide high tracking accuracy on a pet’s whereabout over long distances and in remote locations. In this way, pet owners can track on demand, in near real-time. Furthermore, an alert or notification can be automatically triggered based on a particular cat or dog’s behavior, e.g. leaving a geo-fenced area, such as the backyard. This allows one to quickly identify potential dangers. By using solutions for pet localization, owners can significantly increase the chances of finding a lost pet again.
Revolutionizing Public Transportation with IoT
Connected cities are the future, and the capabilities for public transportation are incredible. Cities can upgrade buses and trains by incorporating the Internet of Things (IoT) into public transportation, making the passenger experience better and safer, as well as reduce costs.
IoT allows the real-time tracking of buses and trains, which benefits both the rider and management. The rider knows when and where the transport will arrive and the manager can alert the public to any schedule delays. New connected technologies will not only tell a rider when the train will arrive, but it will also alert them to which cars are full and which have room to spare. The organizations can track the vehicle movement, trace the location, monitor the activities, and develop measure to ensure safety.
Through IoT enabled devices, public transport vehicles can offer Wi-Fi connectivity to enhance customer experience and improve consumer journey. Being able to work while on public transportation in the morning or finalize emails in the evening while on the way home has been a much-desired addition to daily commutes.
Optimize city transport dimensioning
The occupancy level could be measured in real-time and that data reported to transportation systems. If there is a huge sporting event ending, the transportation agents can deploy more trains or buses to ensure there is enough transport for all event-goers. Connected platforms can make this a reality for cities. The cost and operational savings could be enormous.
IoT will help cities manage unexpected events much more efficiently. District managers can send alerts to citizen’s phones, offering alternative routes home if there is a problem with trains or a specific public transportation method. Transit agents can spread the word ahead of rush hour to avoid massive delays. Agents can also develop strategic contingency plans for emergency events, becoming prepared for anything.
Instead of waiting for a train or bus to break down, IoT enables predictive maintenance techniques, which means employees will know when a part might fail. They can then fix the part ahead of time, instead of waiting for it to break down, causing delays. Imagine not having a train break down, completely stopping and backing up passenger movement; predictive maintenance can make that happen. IoT in public transportation willl also mean less downtime. Unexpected downtime of buses and trains can be expensive, which means cities could see drastic savings from IoT.
Accidents in the workplace are a well-documented problem, with potentially devastating consequences for employees and employers alike. Despite clear safety regulations and procedures, risk management remains a huge challenge for employers in many industries, but by using emerging technologies such as the Internet of Things (IoT) and pervasive cloud connectivity, organizations can now pull in work environment data, analyze it, and respond in ways to help keep workers safe and healthy.
IoT excels at keeping an eye on things; collecting data by means of connected sensors that help us understand our working environments. They can monitor everything from factory equipment to the location and well being of human beings. This makes them a great tool for monitoring potentially hazardous environments when it’s impossible to do so manually with any consistency.
When it comes to monitoring both internal and external factors, sensors make perfect sense. For example, you can collect IoT data from wearables (like helmets, jackets and watches, for instance) and combine that with environmental sensors to monitor both workers’ wellbeing and the state of their working environment. By tracking indicators of physical fitness like heartbeat and skin temperature, sensors can help watch out for employees who are starting to show strain or other signs of potential problems, and preventative action can be taken.
The use of an IoT solution also enables companies to monitor potential hazards within the working environment. For example, sensors can capture carbon monoxide levels, weather events, temperature and vibration, plus many others."
The power of IoT in the workplace lies in its ability to:
Safety at Home
Our homes are rapidly being filled with IoT devices that promise to increase convenience, improve energy savings and strengthen safety. Here are examples:
IoT home security systems keep one safe and promise to strengthen personal security at home, by providing remote control and surveillance through Internet-connected devices in the home. They can monitor the security status in real-time and send alerts to the owner in case of any trespassing and raise an alarm optionally. Security cameras, video doorbells, and other security devices could be used to notify the home when someone approaches or enters the house. These devices might also gather evidence to document violations of a protection order or other criminal behavior.
Personal security is also important when you are out, on the go. When we talk about the personal security, classic stun guns and pepper sprays come to mind. But many helpful smart personal security devices may help you on the spot as well as they inform your beloved ones and official authorities about your current status along with your GPS location. Some IoT devices can predefine the following alarm functionalities:
Service buttons are smart solutions for logistics, production plants, workshops, construction sites or hospitals in the Internet of Things. Pickup, ordering and maintenance processes can be initiated by pressing the device's button. For example, spare parts can be ordered at the touch of a button. It avoids unnecessary routes and additional manual operations.
Easy integration based on the stand-alone format makes service buttons independent from the power supply and corporate networks. The device is powered by a standard battery and communicates via the mobile network (e.g. via NarrowBand IoT).
What is smart street lighting?
Smart street lighting refers to public street lighting that adapts to movement by pedestrians, cyclists and cars. It is an adaptive street illumination that dims when no activity is detected, but brightens when movement is detected. This type of lighting is different from traditional, stationary illumination or dimmable street lighting that dims at pre-determined times.
How is it implemented?
Street lights can be made intelligent by placing cameras or other sensors on them, which enables them to detect movement. Additional technology enables the street lights to communicate with one another. Different companies have different variations to this technology. When a passerby is detected by a camera or sensor, it will communicate this to neighboring street lights, which will brighten so that people are always surrounded by a safe circle of light. Street lights illuminate at a longer distance ahead of the pedestrian than behind the pedestrian in the Smart Lighting concept.
What is Waste Management?
The industry referred to as "Smart Waste" includes the activities and actions required to manage waste from its inception to its final disposal. This includes the collection, transport, treatment and disposal of waste, together with monitoring and regulation of the waste management process. Efficient waste management is fundamental for so-called "Smart Cities."
IoT provides waste monitoring, leading to cost-reduction and operational efficiency through improved energy management and reduced personnel costs, but there are other far-reaching benefits from using IoT devices (e.g. sensors on smart bins) and data. Observing an IoT-connected waste or recycling bin offers a clue. A smart bin is a waste or recycling bin outfitted with a sensor that can detect bin fill level, collection events, fire, tilt and temperature. There are a variety of sensors on the market that use ultrasonic sensors, laser measurement and image recognition to collect data.
What are the benefits of Waste Management?
Data from smart bins offers immediate and obvious benefits; however, when examining the data generated from a broader perspective, there is much more value than a trip saved to see if waste has been/should be collected:
Smart Waste solutions help one identify patterns and trends on how bins fill up:
Comparing similar buildings is also possible, as some buildings generate more or less waste/recycling. Tenants in these buildings have different services based on waste output; for example, a restaurant tenant requires more frequent collection than an office tenant. Understanding these trends allows managers to properly forecast and plan waste services when new tenants move into a property.
Finally, Smart Waste helps cities combat illegal dumping. Through image-based camera systems that can visually assess waste types, managers are able to identify the bins where illegal dumping occurs and can take appropriate actions, such as locking bins and installing video surveillance if required.
Waste Management is essential for sustainable Smart Cities:
Ultimately, the goals of Waste Management can be defined as such:
Wearable technology is a hallmark of the Internet of Things and the most ubiquitous of its implementations to date. The efficiency of data processing achieved by various smart wristwear, smart clothes, and medical wearables is getting to the point where this consumer-oriented side of the IoT technology will bring exceptional value to our lives and become a new fashion along the way.
Some of the first functions that wearable devices are already delivering are related to identification and security. Maybe you don't consider the badge you wear at work a wearable device, but it does provide identification and security features useful within the work environment. Some advanced badges even include some biometric capabilities (such as fingerprint activation, so only the badge's owner can use it to open a locked door) to improve security. Badges can also include capabilities for location sensing, useful in emergencies to make sure everyone has successfully evacuated the building. A wearable bracelet provides a more reliable indication of location since it is less likely to be left in a jacket on the back of a chair.
Health- and fitness-oriented wearable devices that offer biometric measurements such as heart rate, perspiration levels, and even complex measurements like oxygen levels in the bloodstream are also becoming available. Technology advancements may even allow alcohol levels or other similar measurements to be made via a wearable device. The ability to sense, store, and track biometric measurements over time and then analyze the results, is just one interesting possibility. Tracking body temperature, for example, might provide an early indication of whether a cold or the flu is on the way.
Some additional capabilities of wearable devices are more mundane, but might also provide information that could be useful in adjusting environmental controls. Wearable devices could tell if you have your jacket on in the car or if it's just in the back seat (perhaps by placing a few stress measurement device threads within the fabric of the jacket). This could be helpful in keeping the car temperature at a comfortable level. If your wristband can measure perspiration levels that could also be used as a data point for adjusting both temperature and humidity.
The promise of the IoT is based on pervasive connectivity and when associated with large collections of connected devices, significant benefits can accrue. Your wearable devices could interact with the devices of others in a crowd. Of course, privacy issues will continue to be a big concern for years to come. For example, would you want to know if someone sitting near you on the train had a high fever? Clearly you might want to know this, but the person with the fever might not want to broadcast it. If you both used the same healthcare provider; however, maybe that information would be shared, perhaps controlled via a smartphone filter.
What are white goods?
There's a revolution in modern white goods as the industry moves from its electromechanical roots to electronic control, using sensors to boost the intelligence of these appliances. Home appliances are getting smarter connected and more efficient with the Internet of Things (IoT). IoT brings power efficiency and automation for today and tomorrow's smart appliances. It increases effectiveness and can bring the following advantages:
The best is yet to come...
Many appliance makers may soon become content providers in their own right, by developing intelligent variants of their product. For example, appliance makers may build washing machines that can determine which RFID-tagged clothes can be washed together and how much detergent can be used on a load. Future refrigerators will be able to propose nutritious meals and recipes using RFID-tagged food while warning consumers which foods are about to expire, etc.
The sharing economy is the most prominent term for collaborative consumption or collaborative economy like car sharing, bike sharing or peer-to-peer property rental. With the use of digital technology including modern radio technologies companies can easily track leased goods, control them remotely, monitor the conditions and duration of usage. One major benefit of sharing goods for customers, is to borrow the good at one location and return the good on another location. The sharing company can track in real time and controls always their assets.
In case of car sharing many information can be read out, distributed and used for business purposes
For shared bike solutions low power consumption, better coverage and low latency is needed. Narrow Band IoT solves the problems of high power consumption and short battery lifetime. NB-IoT chipsets and modules do not require chargers for the bicycles and reducing the overall costs of such a bicycle. The focus area for bike sharing are:
A variety of information can be accessed by offering sharing solutions, including usage rankings, cycling group statistics, general usage trends, usage trends by region or time, data connection issues, and location changes.
IoT development kits are hardware platforms designed for the rapid prototyping of IoT applications. IoT developer kits combine microcontrollers and processors with wireless chips and other components in a pre-built, ready-to-program package that can be used to prototype IoT devices. APIs are usually provided for quick development of applications on top of the supplied platform.
IoT gateways (also referred to as "advanced M2M devices" - as opposed to "basic M2M devices," such as sensors and actuators) are important components in the IoT ecosystem, acting as a bridge between endpoints (e.g. sensors, actuators etc.) and the cloud. This connection point exchanges data between the local area network (LAN) of devices performing sensing and actuation capabilities and the gateway, and the wide area network (WAN) between gateway and mobile operator network. The LAN is often referred to as the "capillary network" or "M2M area network." It therefore must support multiple communication technologies and protocols (e.g. 3GPP™, WiFi, LAN, CAN-Bus, Zigbee etc.).
Not only does the gateway transfer data between the sensors, actuators and the cloud, it is an aggregator for data, analyzing, merging and consolidating data to minimize the amount of messages and volume of data that needs to be forwarded to the cloud. This has positive impacts on latency, response time and network delivery costs.
It is also necessary to differentiate between routers and gateways because routers regulate the traffic between similar networks (e.g. fixed line). An IoT gateway can regulate the traffic of completely different network technologies.
IoT network monitoring provides an opportunity for service providers to be more relevant and better meet the needs of connected consumers with a growing number of devices in their lives. Network monitoring allows to:
Actuators (also referred to as "movers") are component within an IoT device that can move, manipulate, or activate an asset. The asset in question may be another component, a coupled mechanism, or a system. In order to perform its tasks, the actuator requires a source of energy (typically the device's battery or a power supply) and a low-energy control signal. In the context of IoT devices, this energy source and control signal are electric voltage or current. Actuators convert the energy source into a mechanical motion to act upon its environment. The control system is usually the application running on the IoT device's microcontroller (MCU).
There are numerous types of actuators, but most can be classified as hydraulic, pneumatic, electric, thermal, magnetic, twisted and coiled polymer (TCP), supercoiled polymer (SCP), or mechanical actuators. Some common examples of actuators used in IoT devices include:
Global Navigation Satellite Systems (GNSS) are satellite-based positioning systems that allow assets to be located with high precision. There are several GNSS technologies available today:
Three “segments” are defined for each GNSS system:
GNSS receivers usually offer multiple modes of operation:
The IoT Solution Optimizer models the power consumption of processes required to execute these modes of operation.
Global Positioning System (GPS) is one of several Global Navigation Satellite Systems (GNSS) in existence today. It was launched in the late 1970s, and uses a constellation of 27 satellites to provides for global coverage. GPS satellites orbit at a height of 20,000 km above the earth.
GPS signals, for instance, are transmitted on the L1, L2 and L5 frequencies, and modulated using CDMA-based techniques. This allows the UE receiver to accurately identify the time-shift in the repeated code sequence (and hence distance), as well as recover the highly attenuated satellite signal from the noise floor. The UE receiver calculates the range to each satellite and predicts its coordinates on earth. It is also programmed to advance or delay its clock until the pseudo-ranges of all four satellites converge at a single point, for high accuracy. Note that GPS UE receivers will only consider the earliest-arriving signals, ignoring multipath signals caused by reflections in the atmosphere. The effects of temperature, pressure, and relative humidity in the troposphere may also delay the propagation of the signals to sub-light speed velocities. Finally, the ionosphere higher above typically interferes with GPS signals in a frequency-dependent manner. By calculating the range to each satellite by using both L1 and L2, the UE receiver can virtually eliminate the effect of the ionosphere. Note that other satellite systems use different modulation schemes; although BeiDou and GPS use CDMA schemes, GLONASS uses FDMA-based modulation.
GPS satellites’ L1 signal includes a navigation message, the publicly available Coarse Acquisition C/A code, and an encrypted precision P(Y) code (restricted to the public). The low bit-rate navigation message includes the following:
The ephemerides and almanac information are also available online. IoT devices supporting Assisted-GPS (A-GPS) use data connectivity over the 3GPPTM network to download the latest files, thereby saving much time and avoiding a download from the satellite.
The P(Y) code provides for better interference rejection than the C/A code. It is therefore reserved for military use, making military GPS more robust than civilian GPS.
The L2 signal transmits the P(Y) code as well as the L2C C/A code – a second, publicly available code for civilian use.
Many of the commercially available GNSS solutions have a multi-constellation receiver. This means it can access signals from several systems, GPS, GLONASS, BeiDou, and Galileo for instance. By complementing GPS with additional constellations, a larger number of satellites are in the field of view, resulting in many benefits:
GNSS UE which utilize signals from a variety of constellations have built-in redundancy. If signals from one constellation are not possible to demodulate, the receiver can switch to an alternate constellation—ensuring continuity of positioning. While it is in multi-constellation mode, the receiver tracks at least five satellites, one of which must be from the second constellation. The receiver is therefore able to determine the time-offset between constellations.
Global Navigation Satellite Systems transmit navigation message data from each satellite. Each navigation message consists of 5 subframes, which form one page. The first 3 subframes of the page contain the ephemerides. Approximately 30 seconds (6 seconds/subframe) are required to download these 5 subframes. Ephemeris data is used for real time satellite coordinate computation which is required in position computation.
The ephemeris data is unique to each satellite and contains information on week number, satellite accuracy, and healthiness, age of data, satellite clock correction coefficients, and orbital parameters. It is valid for two hours before and two hours after the “time of ephemeris.”
Unlike the almanac, which is optional and assists with fixing the satellites for the first time, the ephemeris data is critical to maintain up to date for the accurate computation of position.
Ephemeris information is also available online. IoT devices supporting Assisted-GPS use data connectivity over the 3GPPTM network to download the latest satellite ephemerides, thereby saving much time and avoiding a download from the satellite.
Global Navigation Satellite Systems transmit navigation message data from each satellite. Each navigation message consists of 5 subframes, which form one page. The last 2 subframes of the page contain almanac data. Approximately 30 seconds (6 seconds/subframe) are required to download the 5 subframes.
The almanac is optional and assists with fixing the satellites for the first time. A full almanac download consists of 25 pages, which requires 12.5 minutes to fully download. The almanac data is the same for all satellites and contains less accurate orbital information than ephemerides. It is valid for a period of up to 90 days and can be used to shorten the time-to-first-fix (TTFF) fix by up to 15 seconds vs. not having the almanac stored.
Almanac information is also available online. IoT devices supporting Assisted-GPS use data connectivity over the 3GPPTM network to download the latest Almanac file, thereby saving much time and avoiding a download from the satellite.
Standard GPS receivers (also referred to as "standalone GPS") need to download the ephemerides and the almanac information from satellites in order to calculate their own position. Retrieving this data can take approximately 30–40 seconds, as the satellites' signals are transmitted at 50 bps. Furthermore, if satellite signals are lost during the acquisition of this information, the data is discarded, and the standalone system must reinitialize the download.
In Assisted GPS (A-GPS), also referred to as "Augmented GPS," the mobile network operator deploys a cache server for GPS data called the A-GPS server. The independently download the orbital information from the satellite constellation and store it in their database. A-GPS-capable IoT device can then connect to these servers using the mobile network to download the stored content. As the data rate of these radio bearers is high, the download of orbital information can be done faster. Cell tower (eNodeB) data is furthermore used to enhance the quality and precision when satellite signal conditions are inadequate. Using this system however can incur additional data charges for the IoT device's service, depending on the tariff.
There are two types of Assisted GPS available:
Time-to-first-fix (TTFF) refers to the time needed by the GNSS user equipment (UE) receiver to perform the first position fix, starting from the moment it is booted ON. There are three different TTFF scenarios, depending on the receiver’s status when the acquisition cycle is started, as well as the availability and validity of satellite almanac and ephemeris data required for computing position:
Figure: Acquisition with cold start
Figure: Acquisition with hot start
As the name implies, GNSS solutions operating in “Continuous Tracing” mode track satellites for prolonged periods of time. After a brief boot and acquisition cycle, the GNSS chip enters its tracking sequence which consumes typically anywhere between 10 and 100 mWh of energy. In the figure below, the x-axis (time) has been compressed to show the current consumption during cold start acquisition, as well as during the GNSS’ continuous tracking over many seconds.
The GNSS chip may be deactivated for a certain period and rebooted in order to obtain positioning information. In such an event, the new boot triggers an acquisition cycle. The IoT Solution Optimizer allows one to model duty cycle periods of continuous operation by specifying the duration of each tracking window (time powered ON) and the average period between each booting event (time powered ON + time powered OFF).
Note: The IoT Solution Optimizer considers an acquisition with cold start if the duration between boots exceeds the validity period of the current satellite Ephemeris data. Otherwise, a hot start if modeled.
Figure: GNSS component in “Continuous Tracing” mode
If placed into Automatic Tracing mode, the GNSS chip tracks satellites during regularly scheduled time windows, separately by periods of stand-by.
The operation begins with a brief boot and acquisition cycle. The IoT Solution Optimizer models the acquisition as a cold start if the duration since the last GNSS boot exceeds the validity period of the satellite Ephemeris data; otherwise, a hot start acquisition cycle is used. Whereas hot starts require between 1 to 2 mWh, a cold start acquisition cycle may consume up to 35 mWh of energy. Actual measurements from the selected component are used to precisely model the energy consumed by each cycle.
Post-acquisition, the GNSS may enter a tracking sequence consisting of stand-by periods and satellite-scanning windows. The energy consumed during tracking may vary significantly; usually, it is below 100 mWh. The stand-by windows, in turn, typically consume anywhere between 2 to 10 mWh of energy. As seen in the figure below, a GNSS component enters stand-by immediately after its boot and acquisition.
To configure Automatic Tracing in the IoT Solution Optimizer, please specify the average duration of the GNSS tracking events (time scanning for satellites) and their period (time scanning for satellites + in stand-by).
To conserve energy during IoT device “dormancy states”, the GNSS chip may be shut down and booted whenever positioning information is needed, especially within specific time windows. At each boot event, a new acquisition cycle with cold start is required. The IoT Solution Optimizer allows one to model such a behavior by specifying the duration of each tracking window (time powered ON, i.e. scanning for satellites + in stand-by) and the average period between each booting event (time powered ON + time powered OFF). The duty cycle is the percentage of the time powered ON over the total time between boots.
Figure: GNSS component in “Automatic Tracing” mode
GNSS solutions placed into Host CPU Tracing mode operate with windows of alternating satellite-tracking and stand-by (like Automatic Tracing mode), separated by longer periods of hibernation, a GNSS power saving mode where the RF section of the GNSS chip is shut down and the and signal processing thread is suspended. Typical energy consumption in hibernation may range from 0.1 to 1 mWh. During hibernation mode, the receiver stores the current ephemeris data. The hibernation mode usually lasts less than 2 hours, thereby ensuring that the stored satellite orbit information remains valid for updating satellite positions whenever a hot start is triggered. Alternatively, suppliers may implement a procedure whereby the GNSS periodically turns ON its RF section and take a “snapshot” of the satellite constellation, shutting down its RF section thereafter, and processing the signal to obtain each visible satellite’s range.
Host CPU Tracing begins with a brief boot and acquisition cycle. The IoT Solution Optimizer models an acquisition with cold start if the duration since the last GNSS boot exceeds the validity period of the current satellite Ephemeris data; otherwise, a hot start acquisition cycle is used. Whereas hot starts require between 1 to 2 mWh, a cold start acquisition cycle may consume up to 35 mWh of energy.
Post-acquisition, the GNSS may enter a tracking sequence consisting of stand-by periods and satellite-scanning windows. The energy consumed during tracking may vary significantly; usually, it is below 100 mWh. The stand-by windows, in turn, typically consume anywhere between 2 to 10 mWh of energy.
To configure Host CPU Tracing in the IoT Solution Optimizer, please specify the average duration of the GNSS tracking events (time scanning for satellites) and their period (time scanning for satellites + in stand-by). It also necessary to specify the duration of time that the device is in hibernation. An example of Host CPU Tracing is shown in the picture below. The GNSS component leaves hibernation by booting, followed by an acquisition and prolonged period in stand-by.
The GNSS chip may also be deactivated for certain periods and rebooted in order to obtain positioning information during a specific time window. At each boot event, a new acquisition cycle with cold start is required. The IoT Solution Optimizer allows one to model such a behavior by specifying the duration of each tracking window (time powered ON: scanning for satellites + in stand-by) and the average period between each booting event (time powered ON + time powered OFF). The duty cycle is the percentage of the time powered ON over the total time between boots.
Figure: GNSS component exiting hibernation
Please note that Host CPU Tracing is steered by the IoT device application. Developers must configure the exact algorithm that is used to trigger scanning windows and hibernation periods. As the figure below illustrates, these can be non-periodic in nature, highly optimized to specific use cases.
Figure: GNSS component in “Host CPU Tracing” mode
Most manufacturers have a highly optimized “Default” mode that can be activated. In this state, the GNSS operates according to an algorithm creating windows of alternating satellite-tracking and stand-by (like Automatic Tracing mode), separated by longer periods of hibernation (similar to Host CPU Tracing mode). Unlike Host CPU Tracing, however, the IoT device application does not steer the algorithm. This reduces implementation complexities for suppliers, which can rely on a generic, best-practice algorithm.
Manufacturers intending to build location solutions traditionally integrate GNSS components, increasing the cost of their IoT and mobile devices. A new alternative that saves costs and improves power usage for battery-operated, constrained devices is to use innovative, cloud-based "Location as a Service" platforms that are software-only.
Polte's Cloud Location over Cellular (C-LoC) is one such solution, leveraging cellular signals to provide indoor and outdoor positioning for IoT devices. This approach can help transform the IoT market, allowing LTE and 5G cellular-connected IoT devices to have longer battery lives and lower cost at the smallest size possible. The technology behind this IoT location services platform is an alternative to traditional GPS and patented by Polte. It leverages ubiquitous 3GPPTM cellular network signals, as well as the Polte IoT Cloud, to enable highly accurate indoor and outdoor location insights across geographies. If you make things, sell things, or own things – Polte makes asset, inventory and logistics management easy. Automotive, appliances, energy, food and beverage cold chain, government, healthcare, manufacturing, and sharing economy sectors all save time and money leveraging location data to improve supply chain visibility, reduce shrinkage, and improve customer self-service experiences.
The solution consists of the Polte Location API, the Cloud Location Engine (LE), and the Location Mapping app. These provide location insights for Industry 4.0, Supply Chain Excellence, and Digital Transformation initiatives:
As Polte’s firmware is directly built into many of the industry's leading cellular chipsets, many IoT devices are Polte-enabled out-of-the-box. Polte also builds-in security from the beginning. Location is not determined on the device itself, but in the Polte IoT Cloud. This makes the device’s location safer by reducing device-based spoofing risks posed by traditional GNSS implementations. The initial version of Polte's C-LoC is focused on the LTE and 5G cellular loT market, supporting all modes of Cellular loT, including LTE Cat-1 (Full Band), Cat-M1 (LTE-M / eMTC), and NarrowBand IoT (NB-loT).
For more information, please visit: https://www.polte.com/.
Location with Wi-Fi, Cell, and GNSS
Device makers, component manufacturers, application developers, and network operators looking to provide accurate location to IoT devices and systems have traditionally been burdened by battery drain, technical integration challenges, and sub-par accuracy results. With Skyhook’s Hybrid Positioning Technology, IoT platforms and devices of any shape and size can benefit from a solution that uses Wi-Fi, Cell Signals, and GNSS to provide location in any environment around the world. Hybrid Positioning Technology uses signals from any of these methods alone, or intelligently combines them with each other to provide the highest degree of accuracy, with minimal battery usage.
Skyhook is a leading independent provider of location technology. With over 17 years of experience, Skyhook has leveraged a global network of over 5.4 billion Wi-Fi access points and over 200 million cell towers to provide clients across all IoT industries with a solution to reliably track their most valuable assets, optimize management of fleets, develop applications with incredible user experiences, and so much more.
Today, Skyhook partners with the world’s leading chipset manufacturers, device makers, and network operators to enable location-ready devices and solutions using one of several flexible integration options:
Skyhook understands that each use case is unique. That’s why the Sales Engineering Team takes the time to understand individual needs and partners with customers to find the best integration option, build out custom features, and provide always-on support throughout the entire relationship. To learn more about Skyhook technology, please visit https://www.skyhook.com/.
Microcontroller Units (MCU) are highly-integrated small-form factor computers, usually implemented on a single Metal-Oxide-Semiconductor (MOS) integrated circuit (IC). Although similar to "Systems on a Chip" (SoC), SoCs usually include additional components alongside an MCU. One or more CPUs (Central Processor Unit cores), memory, and programmable input/output peripherals are packaged into an MCU. Their memory comes in the form of ferroelectric RAM, NOR flash, or OTP ROM may also be included, as well as a small quantity of RAM.
Microcontrollers are designed for use on embedded devices and automatically-controlled products and devices, such as constrained IoT devices. This is different than more powerful microprocessors used in PCs.
With its reduced size and cost, sufficient memory, and input/output ports, MCUs are economical platforms to run IoT device applications managing assets on small IoT devices. While the term "IoT device application" may be used to the refer to the entire IoT service, including IoT device and server, with the connectivity over a WAN network, such as 3GPPTM, the application running on the IoT device itself is usually located in the MCU. Some advanced wireless communication modules include an entire SoC, meaning that the MCU is integrated into the module's package. MCUs can also commonly handle analog or fixed-signal inputs/outputs, allowing for the management of analog systems on the device. In order to conserve power and run at single-digit milliwatts or microwatts, microcontrollers may use 4-bit words, and operate at frequencies as low 4 kHz. While sleeping, the MCU turns its CPU clock and most peripherals OFF, resulting in a nanowatt power consumption. While waiting for specific triggered events from a sensor or actuator, they are able to retain specific functionalities. In other cases, the MCU may need to play a performance-critical role, acting like a Digital Signal Processor (DSP), with higher clock speed and power consumption.
Sensors (also known as "detector") are the subsystem within the IoT device whose purpose is to detect events or changes in the asset being monitored and send the information to application running in the microcontroller (MCU). In a broader context, as the IoT device provides for "sensory" functionality, the name of this critical subsystem component is often used to generically describe the far more complex IoT device that hosts it. Traditional fields where sensors are deployed is in the monitoring of temperature, pressure, or flow measurement. For industrial and scientific purposes, there also sensors that can measure chemical and physical properties of materials. Optical sensors measure Refractive index, vibrational sensors are used to determine fluid viscosity, and electro-chemical sensor can monitor fluid pH. Alongside the ever-growing spectrum of digital sensors, analog sensors are still in widespread use, common examples being potentiometers and force-sensing resistors.
A sensor's sensitivity indicates how much the sensor's output changes when the input measured quantity changes. Sensors are generally designed to have negligible effects on the asset which is measured. Parallel to the advances in microelectronics, an increasing number of sensors can be manufactured on a microscopic scale. Known as "microsensors," they have an ability to detect minute and state changes in the asset and alert the IoT application.
An exhaustive, yet incomplete, list of sensors used in IoT devices is provided below:
Electronic circuits can maintain a steady voltage by employing linear regulators in their circuitry. Two forms of voltage regulation are available: linear regulators and switching regulators.
A linear regulator maintains its constant output voltage in consideration of both the input voltage and its load, by acting like a variable resistor, varying its internal resistance and continually dissipating the difference between the input and regulated voltages in the form of heat. Single-chip regulators Integrated Circuits (ICs) are quite common and can be used in IoT devices to manage the voltage requirements of the circuitry.
Linear regulators typically have a maximum rated output current. This is generally limited by either its ability to dissipate power, or by the output transistor’s capacity to carry current. Furthermore, linear regulators can be implemented in two configurations:
Low-dropout regulators (LDO) are commonly found linear regulators implemented in IoT devices. Advantages of an LDO include low noise, a simple circuit configuration, and few external parts. Disadvantages are its relatively poor efficiency, potential heat generation, and ability to only step-down (buck) voltage.
Switching regulators work on a different priniciple. They switch an active device ON and OFF to maintain an average value of output over time. Because the input voltage to the linear regulator is higher than the regulated voltage, there is a drop-out voltage (Vdrop) and the efficiency is limited.
A high-frequency switch with varying duty cycle maintains the output voltage. All voltage variations caused by the switching mechanism are then filtered out with an LC filter. Common examples of switched mode voltage regulators are DC/DC converters in power supplies. Advantages of DC/DC converters are their high efficiency, low heat generation, and ability to boost and/or buck voltage, and even provide negative voltage operation. Unfortunately, they may require more external parts and have a complicated design which increases noise in the circuit.
Low-dropout Regulators (LDO) are linear voltage regulators that support a small (= low) voltage drop between the input voltage (Vi) and output voltage (Vo), generally below 500mV. Unlike standard linear voltage regulators, which require typically a 2-Volt differential voltage between input and output to work properly, LDOs work well even when the dfference between the two is very small, being able to regulate down to less than 100mV. That said, the ability to reject noise and ripple from the input supply significantly reduces below ca. 500mV, which may become an issue with many LDOs. A key benefit of using an LDO is that it protects more expensive, connected loads from voltage transients, current surges, reverse voltage, power supply noise, etc.
For most applications, using an LDO regulator makes sense if the input voltage is no more than a few volts above the output voltage; otherwise, the regulator will consume too much power, and a more efficient switching regulator (DC/DC Converter, for instance) could become a better implementation option. In the figure below, dropout voltage (Vdrop) is shown as the voltage differential between the input voltage (Vi) and output voltage (Vo). When no load is applied and the circuit is resting, a minute quiescent current (Iq) is drawn.
Figure: Low-dropout Regulator Circuit
Dropout voltage (Vdrop) is defined as the minimum input voltage-to-output voltage differential at which the voltage regulator can no longer maintain regulation and supply the specified current. Any further reduction in the input voltage may result in a reduced output voltage. This value is highly-dependent on the load current and junction temperature. In the figure below, the dropout voltage is the the measured potential difference between input voltage (Vi) and output voltage (Vo) with a load applied.
Figure: Vdrop in an LDO Circuit
Quiescent current (Iq) in a voltage regulation Integrated Circuit (IC) is the current drawn internally within the regulator, and not available to the load. It is thus relevant in either a no-load or "non-switching," but "enabled" condition. “Nonswitching” implies that no power switch in the IC is ON (closed), resulting in a high-impedance condition where the power stage is completely disconnected from the output. “Enabled” refers to the fact that the IC is turned ON via its EN pin and is not in a UVLO (or other deactivated) state.
Iq is measured as the input current during such conditions, and is therefore often referred to as "resting current." A commonly used name for the ICs condition under which quiescent current can be measured is its "quiescent state."
Quiescent currents constitute a source of inefficiency in linear regulators intended for use in battery-powered devices. As many Mobile IoT devices may be for prolonged periods in Power Saving Mode, quiescent currents may become a major concern in terms of the battery life. The LDO may even actually be more effiient whenever a very low-current load is applied! In the figure below, quiescent current is the leaked current Iq detected when the circuit is resting, i.e. when no load is applied. The Iq travels inside of the IC to ground.
Figure: Iq in an LDO Circuit
A commonly-used type of switching voltage regulator is the DC/DC converter (often written as "DC-DC" or "DC-to-DC" converter). These circuits for power conversion use high-frequency switching and inductors, transformers, and capacitors to filter out switching noise, producing a smooth, regulated DC voltage. Closed feedback loops maintain constant voltage output even input voltages and output currents are changed.
With their 90% efficiency, they may outperform their linear regulators cousins in specific scenarios. Among the disadvantages of the DC/DC converter are its noise and complexity. Isolated varieties of DC/DC converters have their input ground connected to the output ground. There are four topologies available:
Figure: DC/DC Converter Circuit
One of the most important parameters to consider when selecting a DC/DC converter is its efficiency, the fraction of input power which reaches the load, defined as the fraction: (Vout • Iout) / (Vin • Iin). Some DC/DC converters are more than 90% efficient. The source providing power to the DC/DC converter must be able to provide enough power to account for the converter's inefficiency. Efficiency is typically specified by manufacturers using curves on the product specification, with peak efficiency achieved under a certain load current. At lower power outputs, where the amount of power required to power the circuit is similar to the load power, the DC/DC converter's efficiency is usually the lowest.
3GPPTM wireless communication chipsets are the key element in IoT devices that allow for communication with the MNO’s radio access network (eNodeB). The protocol stack and baseband elements of a radio transmitter and receiver (transceiver) are implemented within this component. It usually includes processors for the different supported WAN and LAN radio protocol interfaces, internal memory, GPIOs, resource and power management, connectivity interfaces (e.g. I2C, SPI, UART), receive Analog-to-Digital Converter (ADC), and transmitter Digital-to-Analog Converter (DAC).
Figure: 3GPPTM Wireless Communication Chipset
Examples of 3GPPTM wireless communication chipset components:
3GPPTM wireless communication modules are small electronic embedded systems packaging the radio chipset together with radio front-end and peripherals. Integrators widely use radio modules to avoid the difficulty of a direct integration of the radio chipset. The sensitivity of radio circuits, as well as the accuracy of layouts and components required to achieve operation on a specific frequency, mean that only large enterprises with significant investment opt to integrate chipsets directly. Furthermore, due to the legal regulations imposed on radiated emissions, radio circuits are usually subject to conformance testing and certification by a standardization bodies such as ETSI or the Federal Communications Commission (FCC). Radio modules are steered via an AT Command interface.
Figure: Radio Chipset and Module Functionalities
Examples of 3GPPTM wireless communication module components:
As shown in the figure below, modules support all
3GPPTM and Transport Layer protocols required to communicate with the Mobile Network Operator's infrastructure. That said, the support for specific Messaging/Management IoT protocols are usually not available natively in the communication module. In such cases, the application developer needs to implement their own stack to communicate with the IoT service platforms.
Figure: Protocol Support in Different Solution Layers
A battery is a system which stores chemical energy and converts it into electrical energy thanks to an electro-chemical reaction. It serves as the primary source of energy for powering an IoT device. There are two fundamental types of batteries, each of which can be further divided into sub-groups based on their chemistry:
Batteries are often referred to as "electrochemical cells." When one connects the battery to an external circuit, a reduction–oxidation reaction is triggered, releasing energy in the form of an electrical current. When a battery supplies electrical power, its positive pole is called the "cathode" (an electron taker / oxidizing agent) and its negative pole is referred to as the "anode" (an electron provider / reducing agent). The stronger the oxidation or reduction power of the chemistry used, the greater the difference of potential, or voltage, between both poles of the battery. In this sense, the cell supplies current to the IoT device by transferring electrons from the negative pole over an external electrical circuit to its positive pole. Ions are transferred within the battery from anode to cathode through a porous separator, which is inserted between both electrodes. This internal component mainly acts as an electronic insulator. The entire system is furthermore immersed in an ionically conductive electrolyte transporting ions formed at the anode to the cathode side, within a sealed can.
Figure: Function of Battery in Electrical Circuit
Battery chemistries are selected based on the electric potential between the different elements or compounds therein. As seen in the figure below, the voltage between cathode and anode can vary extensively.
Figure: Electric Potential of Different Battery Chemistries
These batteries are intended for single use (or "disposable") and cannot be re-charged. During their discharge, the electron provider (the anode) is irreversibly consumed. The most common example of primary batteries are alkaline type; however, in Mobile IoT, where one usually tries to achieve very long battery lifetimes and reduce maintenance cycles for IoT applications, it is recommended to use primary Lithium chemistries, e.g.:
Depending on the chemistry used, one can leverage different performance characteristics, such as the cell's nominal voltage. In addition to the battery chemistry, one should also consider the different internal construction of the cell:
These batteries can be re-charged during their lifetime, restoring the original, depleted composition by applying a reverse electric current. For small devices, the most commonly employed battery type is the lithium-ion battery; however, there are also other types of rechargeable batteries such as the lead acid, which is used in vehicles, for example.
In battery-powered Mobile IoT devices, there are several challenges to overcome especially if one targets to employ primary batteries in a product that should have a long battery life. On the one hand, the Mobile IoTwireless communication chipset or module, as well as other hardware components, usually draw bursts of current for a short time, also called pulse currents. That said, such pulses are typically up to several hundreds of milliamperes. A battery needs to be dimensioned to deliver such currents also in potentially extreme temperature conditions (very cold or hot environments). On the other hand, one has to consider the battery self-discharge and the capacity loss during storage. For a battery lifetime estimation, several other factors should be considered (e.g. cut-off voltages, cell efficiency, leakage currents, temperature effects etc.).
A precise and reliable modeling of battery lifetime is complex and can be best performed by the battery suppliers. In the IoT Solution Optimizer, a basic battery modeling system is implemented, taking several aspects into account. That said, for a more precise calculation considering all of the aspects of your product's life, such as manufacturing, storage, usage and deployment environment, it is recommended to contact your battery supplier.
It is important to select a trustworthy battery supplier who can provide the necessary technical consultancy for your product design. The lithium battery-modeling features within the IoT Solution Optimizer have been developed in close cooperation with Saft S.A., one of the world's foremost battery suppliers.
Saft in brief:
For nearly 100 years, Saft’s longer-lasting batteries and systems have provided critical safety applications, back-up power and propulsion for our customers. Their innovative, safe and reliable technology deliver high performance in space, at sea, in the air and on land.
Figure: Saft in Figures
Saft is the producer of choice for some of the world's most demanding customers, and its batteries, systems and solutions make a difference across a broad range of market sectors. Saft is a wholly-owned subsidiary of Total S.A.
For further information please visit us at www.saftbatteries.com.
Lithium Thionyl Chloride (Li-SOCl2) technology has been created and developed in the mid-1960s, primarily for military devices (radios). Its processability and performances repeatability have been improved since that time, so it can be considered a mature technology.
Chemical Reaction: 4 Li + 2 SOCl2 → 4 LiCl + SO2 + S
Lithium Thionyl Chloride primary (non-rechargeable) electrochemistry offers the best choice for long duration applications, since it combines high energy density, wide operating temperature range (from -60°C up to +85°C), low self-discharge (from less than 1% up to 3% in storage at 20°C). The technology has been widely adopted for powering electronic devices, particularly communicating devices, thanks to its high operating voltage (3.6 V vs 1.5 V for alkaline systems), which remains very stable during the discharge, thus the battery use.
Lithium Thionyl Chloride cells exist with two different construction types: bobbin and spiral designs. Whilst the bobbin design is suited for low drain currents, limited pulses and several years lifetime, spiral designs are ideal for powering medium- to high-pulse applications, such as IoT devices with Low Power Wide Area (LPWA) communications.
Figure: Lithium Thionyl Chloride Battery
Lithium Manganese Dioxide technology Li-MnO2 technology is mature, thanks to its more than 30 year-history of deployment. Ithas been widely used both in military and consumer applications such as cameras. On the market, most Lithium Manganese Dioxide cells have a spiral design, but prismatic and pouch form factors also exist. In its spiral form, which allows more electrodes surface, Li-MnO2 technology is compatible with high continuous or pulsed currents consumption profiles. Compliant to a wide range of temperatures (from -40°C up to +80°C for some cells), the Lithium Manganese Dioxide technology differentiates by its absence of significant passivation effect, which reduces greatly the voltage drop that may occur during pulsed discharges with other primary cells technologies.
This chemistry is already widely adopted for high power applications, but its lower nominal voltage (3 V against 3.6 V for Li-SOCl2) had always presented a barrier as it was close to the cut-off voltage (normally 2.5 V to 2.8 V) for IoT devices electronics. This situation has changed with the recent introduction of low-consumption electronic components. Lithium Manganese dioxide cells can be successfully selected for IoT devices communicating with Low Power Wide Area (LPWA) technologies, if the cut-off voltage of the components and the operating temperature range are compatible with the operating voltage of this technology.
There are different ways to design and build battery cells, each of which has a direct impact on the performance of the cell. Proprietary production techniques are used in conjunction to further enhance aspects of the design. One of the oldest ways to construct a battery is to use the prismatic “Flat Plate” architecture often found in lead-acid batteries or nickel-based electronchemistries. Typically, primary cells employed in the IoT Industry, often produced in a hermetically-sealed cylindrical casing. For these, we can basically distinguish two main construction types:
Figure: Spiral Battery Construction
Source: SAFT Battery Training
Spiral architectures usually leverage a construction consisting of anode and cathode sheets with a separation layer in between, rolled and fitted into a can with electrolyte. As the need for higher currents in IoT devices increases with Mobile IoT communication networks – take a Power Class 3 (23dBm) LPWA device – battery technologies need to deliver the necessary peak currents during active time. A spiral construction offers significantly more surface area between the electrodes which reduces the internal resistance and increases the current capability, while showing a lower energy density compared to bobbin cells. This greater contact surface between electrodes, however, may lead to an increased self-discharge.
There are different ways to design and build battery cells, each of which has a direct impact on the performance of the cell. Proprietary production techniques are used in conjunction to further enhance aspects of the design. One of the oldest ways to construct a battery is to use the prismatic “Flat Plate” architecture often found in lead-acid batteries or nickel-based electrochemistries. Typically, primary cells employed in the IoT industry, batteries are often produced in a sealed cylindrical casing. For these, we can basically distinguish two main construction types:
Figure: Bobbin Battery Construction
Bobbin architectures consist of a straightforward cylindrical construction in form of a can with an electrode pole through the center, electrically isolated from the can and connected to the positive battery terminal (cathode). A Lithium-metal layer on the can itself forms the negative battery terminal (anode). The design is then completed by a liquid electrolyte filling available volume inside the can.
Bobbin cells provide higher energy density and lower self-discharge than spirally-designed cells, because of the relatively smaller contact surface between the electrodes. That said, the drawback is in the cell limited current and pulse current capability, which is often required in Mobile IoT applications (23dBm transmit power in Power Class 3 devices). Thus, these cells might be used together in parallel with a pulse sustaining device, such as a capacitor, EDLC or Hybrid Layer Capacitor, to achieve higher pulse currents profiles.
For many battery-powered IoT applications, peak currents are an important aspect of the design. Particularly in Mobile IoT designs, the current peaks of the wireless communication chipset or module (the modem) should not be underestimated. The IoT Solution Optimizer considers the peak currents of the selected Mobile IoT wireless modem to help users in selecting the best-fit battery from a list of integrated products its product shelf.
In addition the modem’s behavior, microcontrollers (MCU), linear converters, sensors and/or actuators may need peak currents as well, which often happen simultaneously with those of the Mobile IoT wireless modem. For this reason, the IoT Solution Optimizer combines the peak currents of these remaining hardware components to those of the selected Mobile IoT wireless modem. Your project’s composite value can therefore be compared to the integrated batteries’ ratings when using the Battery Selection Guide. If you are not sure what value to set for this field, please set to 0 mA; in this case, the peak currents of the remaining hardware components will not be considered at all.
Generically when reading battery data sheets, it is important to understand that one cannot simply compare the peak currents of an Mobile IoT modem and other hardware components with the peak current (also referred to as the “pulse capability”) of a given battery. The maximum peak currents for batteries are determined for very specific test conditions. For example, maximum peak currents are often specified for a certain maximum time duration (e.g. 100ms), with a certain frequency (e.g. every 2 minutes), and at a certain temperature (usually room temperature, e.g. 20°C). Especially in the case of Mobile IoT wireless modems it is very unlikely that such conditions are met; therefore, the IoT application’s peak currents should not be directly compared with the battery peak currents taken from the product datasheets. Moreover, consider the significant impacts of aging and temperature on the battery’s pulse capabilities. As such, it is recommended to contact your battery supplier for further questions and accurate lifetime calculation.
The nominal voltage of a cell or battery represents its rated value in normal operating conditions. In the datasheet of a selected cell, precise information regarding operating conditions corresponding to nominal voltage ratings is given. For example, a nominal voltage can be rated at +20°C and 2mA continuous current. The majority of Mobile IoT applications are however very different and usually cannot be replaced by a constant load model. Apart from nominal voltage, many suppliers may instead indicate the “open circuit voltage,” rated at a given temperature or temperature range. Cell datasheets typically show the graph of voltage versus current at different temperatures; however, for a more accurate model of the relation between temperature and voltage, it is usually necessary to contact your battery supplier.
If configured in the Battery Selection Guide, the IoT Solution Optimizer can compare the cut-off voltage of components in the IoT device, the IoT device’s specific peak current and the temperature extremes of the operating environment against the battery’s voltage ratings at peak current.
The nominal battery capacity is the rated capacity value in Ampere-hours (Ah) measured in defined operating conditions such as discharge rate, environment temperature and cut-off voltage. The capacity is calculated by multiplying the discharge current times the time until the defined cut-off voltage threshold is met. Likewise, a cell or battery capacity can be represented in terms of Watt-hours (Wh), calculated by multiplying the discharge current times the time until the defined cut-off voltage threshold, times the nominal voltage of the battery.
For everyday IoT applications the available battery capacity varies based on real life conditions. There are many parameters affecting the available capacity such as temperature, peak currents and consumption profile, minimal application voltage. Therefore, an accurate calculation of the expected battery capacity for your IoT application can be quite complex, as it must consider both intrinsic properties of the battery cell and typical parameters of use cases and environmental conditions.
Batteries additionally have a certain self-discharge rate which is an important factor for battery-powered devices operating for several years on the same battery. Within the IoT Solution Optimizer, key aspects are considered for the nominal capacity of a given battery; however, due to the complexity of modeling, we are limited by the available capacity for a given average temperature range which is always considered at 20°C (room temperature), unless specified otherwise.
Please find additional information on the available capacity under specific conditions in the datasheet of your selected battery or cell. For a more accurate calculation, please contact your battery supplier.
Battery pack configurations allow you to connect multiple batteries in serial (S) and/or parallel (P). Depending on the configuration, a battery-protection circuit may be required.
Figure: Battery pack with two batteries in serial (2S)
Cells in Series:
Figure: Series Configuration
Cells in Parallel:
Figure: Parallel Configuration
Cells in Series and in Parallel:
Figure: Series and Parallel Configuration
The cut-off voltage of an IoT device is the minimum voltage required by its hardware to operate:
Apart from the hardware requirements, it is important to understand that the minimum voltage of a battery depends on many factors such as temperature, peak currents, aging effects, etc.
In the IoT Solution Optimizer we give a general guidance and batteries can be further analyzed for your use case. That said, for a commercial rollout of your product, it is necessary to do mmore accurate calculation considering aspects of both environmental conditions and hardware requirements.
Battery cell self-discharge is an important factor to consider for IoT applications which must operate several years with a given battery. One should distinguish between the following two self-discharge phenomena:
Please note that the self-discharge under typical operating conditions can be very complex to model and depends on several parameters, such as peak currents and consumption profile, temperature, cell's age, etc. In the IoT Solution optimizer, a fixed percentage of yearly self-discharge is considered. This provides a good indication of the expected performance, but should be studied deeper for careful design of a commercial product. In fact, the actual self-discharge will depend on both intrinsic characteristics of the battery technology and real-life conditions. It is highly recommended to contact your battery supplier for a more detailed modeling and consulting.
For a more precise calculation of the overall power consumption of your product it is necessary to indicate the average current consumption between data transaction events for non-modem hardware components. This ensures that the IoT Solution Optimizer considers the entire power consumption of the hardware that is caused outside of the Mobile IoT wireless communication chipset or module (modem). If not sure of the value, it is possible to leave the field with a value of zero; this aspect is thereafter not considered in the analysis results.
Please note that the average current consumption includes not only the consumption of the microcontroller, sensors and/or actuators, but also any other components in your IoT application, as well as any leakage currents which may occur throughout the operating lifetime.
Please note that modeling is performed only at one specific temperature in the IoT Solution Optimizer. In reality, temperature variations may have a significant impact and would need to be considered as well. There are two possibilities to specify the average current power consumption:
You can specify the voltage range of your hardware to help select the proper battery from a list of pre-integrated solutions. Apart from the nominal voltage, many IoT applications require a well-defined voltage range for safe operations. This includes:
Especially for battery-powered devices, the supply voltage may not always be stable depending on different boundary conditions such as battery chemistry, peak currents, operating temperature, aging effects, etc. The minimal voltage of your IoT device is the minimum voltage threshold which is required by your hardware to operate correctly. Often, this cut-off voltage is determined by specific components such as the wireless communication chipset or module. These may have a certain specified operating voltage range (e.g. min 3.1V to max 4.0V). Please check the datasheets of your components for further details.
The IoT Solution Optimizer calculates power consumption for Mobile IoT wireless communication chipset or module based on your use case, configured 3GPPTM power saving features, your application payload and protocol settings, data transmission frequency, etc. That said, it is important to also specify the additional hardware power consumption of additional hardware components in the IoT device besides this modem. For this purpose, it is possible to specify an additional power consumption so that it is considered in our calculations.
Additional hardware power consumption can be caused by a number of components, for example:
In future releases of the IoT Solution Optimizer, we will be integrating additional features to model some of these aspects in more detail.
The 3rd Generation Partnership Project (3GPPTM) is an alliance of seven telecommunications standardization organizations, or Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC), providing a platform to develop reports and specifications defining international 3GPPTM telecommunications technologies. 3GPPTM was originally created in 1998 with the signing of the "The 3rd Generation Partnership Project Agreement." Its initial mission was to develop the Technical Specifications and Technical Reports for a global 3G Mobile System based on the deployed, evolved GSM core networks and the radio access technologies that they supported (i.e., Universal Terrestrial Radio Access (UTRA), with both Frequency Division Duplex (FDD) and Time Division Duplex (TDD) modes).
During the subsequent years, 3GPPTM activities have been responsible for various generations of cellular telecommunications network technologies, from radio access, core transport network, to service capabilities. The latter includes detailed specifications for codecs, security and quality of service implementation. Interworking hooks are also in scope for non-radio access, core network, and WiFi Local Area Networks. By maintaining and ensuring backwards compatibility across the technologies, 3GPPTM safeguards the continuous evolution of the industry in a way that does not interrupt operation of user equipment. This means that even the legacy 2G Global System for Mobile communication (GSM) predating 3GPPTM are managed through Technical Specifications and Technical Reports. This also includes the 2G extensions for General Packet Radio Service (GPRS) and Enhanced Data rates for GSM Evolution (EDGE). Today, billions of customers worldwide use 3GPP™ technologies for their communication needs, and with its 2G, 3G, 4G (LTE) and Mobile IoT (NarrowBand IoT, LTE-M) releases, 3GPPTM forms a solid foundation for enabling a Wide Area Network (WAN) connectivity layer in the emerging Internet of Things (IoT).
Critical IoT is a term that refers to use-cases, applications, and devices for Internet of Things where high availability, ultra reliability, as well as low latency are critical. Such high-end applications are characterised by the transfer of data at high rates, usually in the milliseconds, as well as high mobility, and use of services like SMS or voice. They require maximum performance; hence it’s essential to base them on robust and stable technologies which ensure an availability of service close to 100%.
Smart vehicales, video surveillance, smart grid, and remote device control are only a few examples of IoT applications applicable to Critical IoT use cases. Critical IoT applications are currently supported via LTE technology and will further be enabled by the upcoming introduction of 5G networking. This will enable newer, even more complex communication scenarios for both consumer and business sectors.
The need for high availability and frequent operations impose higher requirements on the device side, especially with regards to its battery life. The battery longetivity of a typical Critical IoT use case, when compared to Massive IoT, is relatively short. Although 3GPPTM cellular technology would be the most suitable for realization of Critical IoT use cases over wide area networks, secured Wi-Fi networks may be a good option for local area networks.
Figure: Critical IoT vs. Massive IoT
Massive IoT describes use-cases or applications for the Internet of Things (IoT) that deploy sensors, devices or machines at large scales, in which either a communication at a high frequencies is not required, or the low-latency is not critical. Unlike Critical IoT, high performance for such applications is not required; an efficient handling of mass devices throughout their lifecycle is rather more important. Typical Massive IoT verticals include among others smart cities, smart metering, condition monitoring, etc. Any low-mobility use cases relying upon an infrequent, simple communication at low rates, where the hardware battery is expected to serve up to 10 years of life. Often a good coverage in wide areas as well as deep indoor penetration is required for realization of certain use cases, whenever the devices or sensors are located in basements or more remote areas. The emergence of Massive IoT has lead to the development of LPWA technologies such as e.g. 3GPPTM standardized Mobile IoT technologies, NarrowBand IoT (NB-IoT) or LTE-M (eMTC), which were specially designed to fulfill the requirements of such applications. Many classical use cases will still likely rely on tradtional LTE (Category 1+) due to bandwidth and higher data rate requirements.
When comparing the various use cases of M2M and Internet of Things solutions requiring deployments on a wide scale, several key characteristics and needs are shared among the diverse industries, ranging from a need for low-cost devices, best-effort data transmissions, and throughputs in the lower bit rate ranges. Solutions fitting into this pattern can leverage Machine Type Communications (MTC) wide area network connectivity technologies classified as Low Power Wide Area (LPWA). 3GPPTM standardizes these technologies under the designation "Mobile IoT."
Figure: Mobile IoT Application Characteristics and Types
Figure: Mobile IoT Technologies in the M2M / IoT Business
NarrowBand IoT (NB-IoT) and LTE-M are the two standardized Mobile IoT solutions available to the industry. Several targets were defined by the specifications body in order to ensure efficiency, robustness, and both compatibility and interoperability with existing mobile network operator deployments worldwide:
The benefits of NB-IoT and LTE-M, as compared to Sigfox and LoRA, include:
Networked objects are the foundation of an intelligent world. But what will the basis of this Internet of Things (IoT) be? The right network with the right technology.
NarrowBand IoT (NB-IoT) is one of the two Low Power Wide Area (LPWA) technologies defined by 3GPPTM under the category "Mobile IoT." These technologies cater to the fact that many IoT applications only send small payloads data occasionally, at low data rates, and can tolerate Latency. Simplified wireless modules providing stripped-down and focused functionality make NarrowBand IoT affordable and energy-efficient. This, in turn, enables deployment of IoT applications in many areas where networking was previously too expensive and difficult. NB-IoT coverage is currently offered via dozens of Mobile Operator Networks across the globe.
Figure: Comparison on NB-IoT and LTE-M
Among the various benefits of this technology, three clear differentiations stand out:
Deep Indoor Penetration:
Low Energy Consumption:
Lower Module Costs:
Suitable use cases for NarrowBand IoT include:
The protocol stack of NB-IoT is optimized for minimizing signaling overhead, especially over the radio interface. 3GPPTM has specified the following elements:
These specifications have been designed with the classical LTE physical layer in mind in order to ensure compatibility between the two radio access technologies (RAT).
Figure: NarrowBand IoT Protocol Stack (Blue)
Due to its efficient design, it is recommended to use MQTT-SN or CoAP as the protocol for managing devices connected to the server / cloud over a NB-IoT network. MQTT-SN has the additional benefit that it can also be used in Non-IP transport, i.e. IoT device application payload can be sent directly over Control Plane NAS messages to the network, where wrapping of the data on an IP bearer for outbound Internet traffic is done.
LTE Category NB1 refers to a Long-Term Evolution (LTE)-technology protocol class defined in 3GPPTM Release 13. This category was designed specifically to address the needs of Massive IoT use cases by:
IoT devices using LTE Cat-NB1 communicate using half-duplex mode and offer data rates of up to 250 kbps in the Downlink and up to 230 Kbps in Uplink. They can therefore address numerous and diverse IoT use cases for Mobile IoT requiring lower throughput, tolerating higher latencies, and less communication than LTE-M (eMTC). Devices enabled with NB-IoT also have up to 20dB coverage extension (CE) versus GSM using so-called "CE Level 2". A narrow spectral bandwidth of 180 kHz is used to communicate over standard LTE spectrum bands. IoT devices supporting Rel.13 NB-IoT can transmit using Power Class 3 (23 dBm) or Power Class 5 (20 dBm) maximum power.
Most NB-IoT mobile networks worldwide support the NB1 standard. IoT devices with either NB1- or NB2-capable wireless communication chipsets/modules can operate on these networks.
Category NB2 refers to a Long-Term Evolution (LTE)-technology protocol class defined in 3GPPTM Release 14. Among the key enhancements brought to IoT devices and networks supporting LTE Category NB2, are the following features:
Data Rate Improvements
Introduction of Non-anchor NB-IoT Carrier
New Power Class
Group Messaging & Updates (Multicast)
Connected Mode Mobility
Please note that most NB-IoT mobile networks currently do not support Category NB2 features. Local implementations should be treated as "feature islands" in the global NB-IoT coverage footprint in case of roaming agreements. All IoT devices with chipset/modules using this release of the NB-IoT standard are backwards-compatible with Rel.13 NB-IoT networks.
An important feature of NarrowBand IoT is that it shares the same numerology as LTE. This allows spectrum to be shared between the two systems without causing mutual interference. NB-IoT carriers are specified to be 180 kHz, allow them to be inserted into LTE carriers, in the so-called "In-Band" deployment, in lieu of an LTE Physical Resource Block (PRB), which is simply decomissioned. This is fully aligned with the LTE channel structure with 12 tones of 15 kHz per physical resource block (PRB), thus a NB-IoT carrier and a LTE PRB are equal in bandwidth structure. The orthogonality between the NB-IoT PRB and all the other LTE PRBs can thus be preserved. Alternatively, the 180 kHz carrier may inserted in the spectrum adjacent to the first or last PRB, in "Guardband" deployment. Naturally, the option exists to deploy NB-IoT independently from LTE spectrum, e.g. in GSM-dedicated spectrum; this is referred to as "Stand-Alone" mode.
Figure: NB-IoT Operation Modes
Figure: NB-IoT In-Band Deployment of Four Carriers (PRB)
The 180 kHz bandwidth of a single NB-IoT carrier in the downlink (DL), used for communication originated by the eNodeB to the IoT device, is comprised of 12 sub-carriers (tones) of 15 kHz bandwidth, each. Orthogonal Frequency Division Multiplex (OFDM) with legacy QPSK and tail-biting convolutional coding are used for modulation and forward error correction.
On the uplink (UL) communication originated by the IoT Device to the eNodeB, NB-IoT requires IoT device support for subcarriers (tones) of 48 Single Tones within 180 kHz of UL spectrum. These can use pi/4 QPSK or pi/2 BPSK, with turbo-coding. Optionally, some mobile network operators may support 3, 6 or 12 Multi Tones of 15 kHz or 3.75 kHz bandwidth, with QPSK modulation.
The same frequency bands as in LTE are used for NarrowBand IoT, with a subset defined in 3GPPTM Release 13.
Most frequencies are in the lower range of the existing LTE bands, reflecting that for MTC, poor coverage conditions is a concern. Most operators deploy NB-IoT in Europe on Band 3, Band 8, and 20. The technology is deployed using FDD Half-Duplex, in a carrier structure compatible with LTE.
Figure: NB-IoT Frequency Bands
In NarrowBand IoT, both up- und downlink transmissions are possible in series. In the 3GPPTM Release 13 specification, Frequency Division Duplex (FDD) Half-duplex Type-B has been adopted:
Figure: FDD Frequencies for Transmission and Reception
Given the carrier and channel structure of NarrowBand IoT, it is possible to determine the maximum theoretical bit rates and throughputs, whereby the industry intent is not to offer ever increasing throughputs; for the latter, LTE-M (eMTC) and LTE Cat.1 are best suited options.
Peak data rates are achieved using multitone transmission. NB-IoT networks that only support single tone transmission offer peak data rates of ca. 20 kbps.
The term “latency” relates to one-way, downlink or uplink communication. It does not include the time needed to establish a connection between the server and the IoT device. If the device is in Power Saving Mode, it will only receive or send data after it wakes up.
In NarrowBand IoT, applications are designed to be latency-tolerant. 3GPPTM has not specified this radio access technology to cater delay-sensitive or real-time services.
That said, NB-IoT technology is continuously being enhanced, so current figures are expected to evolve with successive releases of the specification.
Although NarrowBand IoT does not have handover functionality like 2G/3G/LTE, it still supports mobility for applications. NB-IoT is designed for infrequent and short messages between the UE and the network. It is assumed that the IoT device can exchange these messages while being served from one cell.
Figure: State Model for IoT Devices in NarrowBand IoT
The NB-IoT state model is simplified, as there are no transitions to associated LTE, UTRA and GSM states. To make NB-IoT more efficient and cost-effective for Mobile IoT communication, the LTE protocols have been reduced to a minimum and enhanced, avoiding overhead from unused LTE features. Consequently, the NB-IoT technology can be regarded as a new air interface also from the protocol stack point of view.
As illustrated by the NB-IoT protocol stack, devices having an active RRC radio bearer to the mobile network operator's radio access network eNodeB (eNB) are considered to be in Connected state (RRC_CONNECTED). When the RRC bearer is torn down, the IoT device is considered to be in Idle state (RRC_IDLE). In both states, the device maintains registered on the mobile network operator's core network.
While the IoT device finds itself in RRC_CONNECTED state, handover procedures are neither needed, nor supported. If a cell change is required, the IoT device first goes to the RRC_IDLE and re-selects another cell, intra-frequency or inter-frequency. This process is referred to as "cell reselection." Type types of cell reselection are possible:
Figure: Two Types of Cell Reselection in NB-IoT
Based on the M2M or IoT mobility use case, it can be determined whether NB-IoT is suitable or not, i.e. it does not support voice or streaming; Nevertheless, most of the use cases rely on data transmission consisting of separate message packets, thus latency is not critical.
Here two scenarios exist:
Providing "Deep Indoor" coverage is an important aspect of NB-IoT, which is essential for IoT application requiring devices to be positioned in areas not readily accessible by 2G, 3G, or LTE coverage, such as in the basements of buildings, parking garages, etc. This is achieved by repeating Layer 3 (RRC, NAS) messages a predefined number of times, thereby increasing the probability of receivers to correctly receive and demodulate the message.
To optimally cope with different radio conditions, 3GPPTM Release 13 has defined three Coverage Enhancement (CE) Levels: CE-Levels 0, 1 and 2. The number of repetitions in each CE-Level is predefined by the network. The CE feature essentially increases maximum coupling loss from 144dB to 164 dB:
The different CE-Levels determine the number of times downlink and uplink messages are repeated to reach devices in poor coverage. Data transmissions and signaling can be repeated either 1, 2, 4, 8, 16, 32, 64, or 128 times, depending on the network's configuration. A higher power density (of 23 dBm) is also used in CE-Level 1 and CE-Level 2 instead of power control. The use of a higher transmit power and retransmissions of messages naturally comes at a cost to the IoT device, namely, a significant reduction in expected battery life.
Figure: Power Consumption Comparison, CE0 vs. CE2
In order to govern the usage of CE-Levels, the mobile operator network may broadcast the boundary conditions for each CE-Level in the System Information Block (SIB). For example, CE-Level 0 may be used when the received signal strength at the IoT device's radio module is better than -114 dBm, CE-Level 1 whenever the signal strength lies between -114 dBm and -124 dBm, and CE-Level 2 when it is worse than -124 dBm. Through direct RF measurements, the device will compare its received signal strength against these boundary conditions and selects the corresponding CE-Level. Please note that some chipset suppliers may implement proprietary extensions in their protocol stack modifying the CE-Level selection criteria.
Figure: Coverage Enhancement in a NB-IoT Network
Coverage Enhancement (CE)-Level 0 corresponds to the normal mode of operation, without repetitions and no coverage gain vs. GSM. This CE-Levelis typically used by devices which are outdoor, or in good coverage areas. The IoT devices can also use the advantage of power control in this CE-Level to dynamically adapt their average transmit power, based upon received signal RSRP measurements. The result is a significant drop in battery consumption.
It is expected that devices used in IoT applications such as fleet management, e-bikes, smart street lighting, smart bins, etc., are likely most of the time in CE-Level 0 conditions due to the good coverage outdoors. CE-Level 0 corresponds to received RSRP values better than -114 dBm.
Figure: Coverage Extension Levels in Buildings
Coverage Enhancement (CE)-Level 1 typically gives a 10 dB gain by repeating the messages a few number of times. This CE Level will be used by devices which are indoor where the coverage is poor. IoT applications deployed indoors, such as smoke detectors and other smart home applications would likely be in CE-Level 1 due to relatively poor coverage found in these environments. CE-Level 1 corresponds to received RSRP values between -114 dBm and -124 dBm.
Coverage Enhancement (CE)-Level 2 typically gives a 20 dB gain by repeating the message multiple times (much higher than that of CE-Level 1). This Coverage Enhancement Level is used by devices which are in deep indoor areas like basements, underground garages, etc., or at the edge of network coverage outdoors. IoT Devices used in parking, meter applications buried into the ground, as well as energy or water meters in the basement of buildings, are but a few examples where CE-Level 2 would probably be used. Received RSRP values worse than -124 dBm are considered to be Deep Indoor.
LTE-M (eMTC) is one of the two Low Power Wide Area (LPWA) technologies defined by 3GPPTM. LTE-M coverage is offered by numerous Mobile Network Operators around the globe. These technologies cater to the fact that many IoT applications only send small payloads data occasionally, at relatively low data rates, and some tolerance for latency. LTE-M is an integral part of the LTE specification. Its name refers to its placement as a proper LTE category (Category M), specifically designed to address the needs of IoT by stripping down unnecessary LTE features, optimizing power consumption and reducing complexity of the UE's (i.e. just one antenna for LTE-M as opposed to two antennas as for higher LTE categories). Its focused functionality makes LTE-M both affordable and energy-efficient. Its standardized character means that it inherits the security features offered by LTE in its other categories, and it can be deployed in licensed spectrum, ensuring Quality of Service. These facts, in combination, enable deployment of IoT applications in many areas where networking was previously too expensive and difficult.
Common IoT applications which may leverage LTE-M include:
Lower Module Costs
Deep Indoor Coverage
Low Enegery Consumption
Figure: Comparison of LTE-M with NarrowBand IoT
How does LTE-M compare to other technologies?
LTE-M offers higher bandwidth and data rates and decreased latency, as compared to NarrowBand IoT. Likewise, LTE-M offers a longer battery life-time and better indoor coverage versus LTE Category 1. For mission-critical applications, LTE-M is the LPWA technology of choice. It supports devices that need to communicate in real time to ensure the application meets user-experience requirements. Some examples of real-time communication include voice, emergency data and precision tracking data. The latency of LTE-M (< 50 msec without Coverage Enhancement, < 1 sec with Coverage Enhancement) is much better when compared to NB-IoT (< 10 sec). LTE-M additionally supports cell handover for true mobility during prolonged data transfers. Both IP and Non-IP Data Delivery are supported. The battery lifetime is better for LTE-M as compared to the higher LTE categories, yet it is expected to be a bit lower than for NB-IoT. Generally, it is a function of the power saving features that applications activate (Power Saving Mode, Enhanced DRX, Long Periodic TAU), the amount of data which needs to be transferred, and the number of messages that are sent. Likewise, Deep Indoor coverage penetration is enabled by robust modulation techniques and repetitions of transmission. Depending on the coverage situation of the device, up to four different Coverage Extension levels (CE0, CE1, CE2, CE3) may be used:
Generally speaking, whenever a customer needs higher data rates, higher data volumes, and lower latency, as compared to NarrowBand IoT, LTE-M is the technology of choice for their LPWA service. Mobile use cases are also better covered due to cell handover functionality within the LTE-M framework.
LTE Category M1 refers to a Long-Term Evolution (LTE)-technology protocol class defined in 3GPPTM Release 13. This category was designed specifically to address the needs of IoT by:
IoT devices using LTE Cat-M1 communicate using half-duplex mode and offer data rates of up to 375 kbps in the Downlink and up to 300 kbps in Uplink. They can therefore address numerous and diverse IoT use cases for Mobile IoT requiring higher throughput and more frequent communication than NarrowBand IoT (NB-IoT). Devices enabled with LTE-M also have up to 15dB coverage extension (CE) using so-called "CE Mode B" and 5dB in "CE Mode A." A narrow spectral bandwidth of 1.4 MHz is used to communicate over standard LTE spectrum bands.
All operator networks worldwide offering LTE-M are currently deployed to support Rel.13 LTE-M. Accordingly, there are no wireless communication chipsets/modules on the market supporting Rel.14 (Category M2).
LTE Category M2 refers to a Long-Term Evolution (LTE)-technology protocol class defined in 3GPPTM Release 14. The Cat-M2 protocol additionally supports full-duplex FDD, thereby delivering higher data rates as compared to Cat-M1, with up to around 2.5Mbps on Downlink and Uplink (as compared to 375 kbps in Downlink and up to 300 kbps in Uplink for Cat-M1). This ensures faster data transfers and lower battery consumption in good network coverage. Devices enabled with LTE Cat-M2 also support higher peak rates using 2 HARQ-processes for Upload and Download, as opposed to LTE Cat-M1's single HARQ-process.
Currently, there are no operator networks or wireless communication chipsets/modules supporting the Cat-M2 specification.
LTE-M is based on the LTE 3GPPTM standard, which allows it to re-use licensed, deployed LTE frequency bands. Compared to a higher-category LTE carriers, LTE-M only requires 1.4 MHz of spectrum (including guard bands). I thereby consumes a maximum of six Physical Resource Blocks (PRBs), or 1.08 MHz.
A powerful aspect of LTE-M technology is that its traffic can be multiplexed within a normal LTE wideband carrier. This means that a Mobile Network Operator deploying both technologies can share the available cell capacity between standard LTE and LTE-M communication.
LTE-M uses the same frequency bands as defined for standard LTE. This ensures that licensed spectrum is used and that maximum spectral efficiency in the network's handling of multiple radio access technologies is achieved.
In Europe, most operators deploy LTE-M on Band 3, 8, and/or 20. Generally speaking, the following bands must be covered in global modules in order to cover North America, Latin America, Europe and parts of Asia:
LTE-M technology is currently deployed using Frequency Division Duplex (FDD) Half-duplex, in a carrier structure compatible with co-located LTE deployments. By using Half-duplex mode, LTE-M devices can offer data rates of up to 375Kbps in the Downlink and up to 300Kbps in Uplink.
In Half-duplex, Uplink and Downlink traffic are separated in frequency and the IoT device either receives or transmits at any specific time, however, not both simultaneously. Between every switch from Uplink to Downlink, or vice versa, there is at least one guard subframe (SF) in between, so that the IoT device's chipset has time to switch between its transmitter and receiver chains.
Figure: Frequency Division Duplex - Half-duplex
As LTE-M can provide similar Quality of Service as LTE under standard coverage conditions (with respect to latency), Voice over an LTE (VoLTE) can in principle be supported over an LTE-M bearer. This voice capability may indeed be useful for example with smart watches or for security solutions where emergency calls in elevators or cars must be triggered. From a standardization perspective, voice support capability may be provided in Coverage Enhancement Mode A (i.e. CE Levels 0 and 1) only. A higher latency must be expected when LTE-M devices are under bad coverage conditions (CE Level 1), which may have a significant impact on the voice quality. For this reasons, Voice over LTE will initially not be supported on numerous LTE-M networks during their early deployment.
Many Mobile Network Operators (MNO) plan to perform performance and quality assessments shortly after launch to ensure quality assurance and issue recommendations in terms of technical prerequisites (e.g. CE Mode configuration and interoperability on LTE-M radio communication modules).
LTE-M is optimized for data mobility use cases, where handovers between serving cell towers are required during prolonged data transfers (much like high speed LTE). This is a key differentiator as compared to NarrowBand IoT. Two main mobility modes are supported:
In this context, 3GPPTM Release 14 supports both intra-frequency and inter-frequency handovers. Intra-frequency refers to switching serving cells, but remaining on the same frequency, whereas inter-frequency requires a switch of frequencies, either within the same cell, or to another.
Indoor coverage penetration is enabled with LTE-M by using robust modulation techniques and redundancy (repetitions of transmissions). Depending on the coverage situation that the device finds itself in, up to four different Coverage Extension (CE) levels can be used (CE Level 0, CE Level 1, CE Level 2, CE Level 3). The higher the CE Level is, the following applies:
CE Level 0 and CE Level 1 are grouped under the term Coverage Enhancement "Mode A," with up to 32 repetitions in CE Level 1. CE Level 2 & CE Level 3 are referred instead as CE "Mode B," with up to 2048 repetitions in CE Level 3. CE Mode A provides a coverage enhancement of 5dB as compared to standard LTE (e.g. using LTE Category 1). CE Mode B is being phased in gradually across LTE-M networks, providing for a coverage enhancement of up to 15dB, as compared to standard LTE.
The 3GPPTM specification has defined various power saving features which can be used in Mobile IoT solutions to conserve battery power:
It is critical to note though that these power saving features must be used according to the specific IoT application use-case. More is certainly NOT better, as they may lead in specific cases to a waste of battery life, or even a failing product design. The table below indicates what combinations of power saving features can be used in different scenarios. Naturally, may of these can be combined, as illustrated in the figure further below.
Figure: Summary of Mobile IoT Power Saving Features
Figure: PSM and eDRX Features Activated Simultaneously
The IoT Solution Optimizer only presents those power saving features for configuration that meet the project criteria. Not only must the mobile operator network support the feature, but also the selected radio chipset or module must also allow for configuration and usage of the functionality. The "AT Command Guide" list generated for each project under "My Projects" elaborates on how each feature can be activated and used by the IoT application.
The 3GPP™ Release 13 Early Release Assistance Indication feature (TS24.301) helps IoT applications further reduce device power consumption and reduces Improves control plane latency. This is achieved by allowing the IoT device to prematurely tear down the Layer 3 Radio Resource Control (RRC) bearer between itself and the eNodeB on the mobile network operator's radio access network. This is done by including a Release Assistance Indicator IE when sending data to inform network if no subsequent uplink or downlink data transmission (e.g. an acknowledgement or response from the application server) is expected. Without this feature, the IoT device is forced to remain in RRC_CONNECTED mode until the expiration of the eNodeB's RRC Activity Timer, which is typically 20-30 seconds.
Figure: Normal Transition from Connected Mode to Idle Mode
By activating the Early Release Indication, the IoT device is able to go straight into the Idle Mode after data transmission and/or reception. Depending on the chipset solution being used, this means that up to 50mA of current may be saved by the IoT device. This quickly adds up over time to form a significant component of reduced battery lifetimes. In order to support application developers with usage of the Early Release Indication, the IoT Solution Optimizer only presents this feature if the selected chipset or module supports it. Furthermore, the AT Command Guide in the corresponding project folder under "MyProjects" indicates how to activate and use this feature.
Figure: Activation of Early Release Assistance Indicator
As a word of caution, Early Release Assistance should only be triggered by IoT application when no additional uplink or downlink traffic is expected in the near-term. Any premature release of the RRC bearer would mean that the IoT device would need to waste additional power to transmit the Random Access Channel and reestablish RRC bearer! This generally costs more power than simply remaining in the RRC_CONNECTED for the duration of the RRC Activity Timer. Please ensure that you trigger this feature only after it safe to assume that no additional communication should happen to/from the application server within the next 10-20 minutes.
Figure: Proper Usage of the Early Release Assistance Feature
Most Mobile IoT networks offer the Connected Mode Discontinuous Reception (cDRX) feature to reduce power consumption on the IoT device. Unlike Power Saving Mode, Idle Mode DRX, and Enhanced DRX, all of which improve power efficiency during the Idle Mode (when there is no active radio connection in place between the IoT device and network), cDRX (often referred to as "RRC Mode DRX") optimizes power consumption at the device during the Connected Mode, the state during and immediately after the transmission and/or reception of messages. During this period, a Radio Resource Control (RRC) logical connection is maintained with the eNodeB for the duration of a network-configured Activity Timer, allowing for quick transfer of data between the device and the eNodeB (cell site). Depending the timer's duration, it may become mission-critical to support power saving features optimizing Connected Mode, such as the Rel.13 Early Release Assistance Indicator or cDRX. The IoT device and application cannot control this feature; essentially, support is fully-depending on whether the network offers it or not.
Without cDRX, the IoT device's chipset is forced to monitor the Physical Control Channel (PDCCH) in every subframe to check if there is downlink data available. This tends to drain the battery fast. The solution introduced in LTE standardization involves monitoring the PDCCH channel discontinuously; in other words, the IoT device enters sleep and wake cycles. By momentarily switching off the receive section of the radio chipset for a fraction of a second (the interval being controlled by the network-defined DRX Timer parameter, TDRX), IoT devices are able to save power. When the device wakes up, the receiver will listen for the PDCCH. The IoT devicecannot be contacted by the network during the period that it is not listening, but if the period of time is kept rather short, the IoT application will not experience a noticeable degradation of service. Connected Mode DRX is configured by the network in RRC Connection Setup request and RRC connection reconfiguration request.
Figure: cDRX Activated (top) and Deactivated (bottom)
Note: cDRX is not drawn to scale in the figure above.
Extended Discontinuous Reception (eDRX) is an extension of an existing LTE feature which can be used by IoT devices to reduce power consumption. It was specified in 3GPPTM TS23.682 and TS24.301. eDRX can be used without PSM or in conjunction with PSM to obtain additional power savings. Today, millions of smartphones use Discontinuous Reception (DRX) to extend battery life between recharges. By momentarily switching off the receive section of the radio chipset for a fraction of a second (the interval being controlled by the network-defined DRX Timer parameter, TDRX), these smartphones are able to save power. When the device wakes up, the receiver will listen for the Physical Control Channel. The smartphone cannot be contacted by the network during the period that it is not listening, but if the period of time is kept rather short, the smartphone user will not experience a noticeable degradation of service.
In a similar way, the Extended DRX feature allows the time interval during which a device is not listening to the network to be greatly increased. IoT devices perform the DRX procedure during fixed time windows, called Paging Transmission Windows (PTW), as configured by the IoT application. Between 4-16 paging reception slots can be accommodated with each Paging Transmission Window. The subsequent PTWs are furthermore offset from each other by a second timer, TeDRX, which represents the eDRX Cycle; this timer can also be defined by the IoT application. In between, the receive path of the radio chipset is deactivated. For M2M or IoT applications, it might be quite acceptable for the device to not be reachable for a many seconds, or even hours. Although it does not provide the same levels of power reduction as PSM, eDRX may provide a good compromise for many use cases between device reachability and power consumption.
In summary, there are three features which control how eDRX is configured:
Figure: eDRX Mechanisms and Power Consumption Values
The IoT Solution Optimizer allows users to configure the TPTW and TeDRX values, wherever the selected mobile operator network supports the eDRX functionality.
Tracking Area Updates (TAU) chipset protocol stack at regular intervals to keep the network updated about its location. This is in conformance to 3GPPTM Layer 3 procedures. If the IoT devices fails to send the TAU before the expiration of the TAU timer, the network considers that the device is no longer within its footprint. It is subsequently de-registered from the core network. As long as the device does send the TAU, the data context is kept active and there is no need to perform an ATTACH to the network. With each message sent or received by a device, the TAU timer is reset; the communication from the device is considered to be an implicit tracking area update, thus reducing signaling. NarrowBand IoT devices with an active context can easily access the network and transmit or receive messages over the Control Place, better known as Data over NAS (DoNAS).
The Tracking Area has two main identities:
The Tracking Area Code identifies the tracking area within a particular network. Combining the TAC with PLMN-ID gives the globally unique Tracking Area Identity, TAI (= PLMN + TAC = MCC + MNC +TAC).
Please note that the IoT device's chipset protocol stack will trigger a TAU in any of the following cases:
A major reason for moving IoT applications from legacy technologies, such as 2G or 3G, onto NarrowBand IoT is the availability of a long-periodic timer. This feature allows the interval between TAU events to be extended.
The 3GPPTM feature Long-Periodic Tracking Area Updates (TAU), as defined in TS24.301, is used to periodically notify the availability of the IoT device to the network. The procedure is controlled in the device's chipset via a periodic tracking area update timer (T3412), which has an extended version (IE) for NarrowBand IoT.
The benefit of the Long-Periodic TAU is that chipset protocol stack can remain longer in deep sleep mode (refer to Power Saving Mode) before it must wake up to send a TAU message.
Figure: Long-Periodic TAU Activated
The value of Long Periodic TAU timer (T3412) is sent by the network to the IoT device in the ATTACH ACCEPT message and can be sent in the TRACKING AREA UPDATE ACCEPT message. The device's chipset uses the received value within all tracking areas in the list of tracking areas it's assigned to, or until a new value is received.
Depending on the network infrastructure capabilities of the mobile network operator, its core network may or may not accept the IoT device's requested value. The IoT Solution Optimizer allows users to configure the parameter only in those cases where the network default value of T3412 can be overwritten.
NarrowBand IoT supports the use of the T3412 Extended Value IE. This feature allows the T3324 timer to last for approximately 413 days. Depending on the feature support of the chipset and/or network infrastructure, T3324 may be limited to 310 hours. The IoT Solution Optimizer only allows configuration of this time when the network supports overriding its default value with an IoT device-requested value. It also allows the configuration of the timer to the maximum value supported by the selected network(s).
Figure: Using T3412 Timer to Extend Period Between TAUs
Power Saving Mode (PSM) is specified in 3GPPTM Release 12 to help LTE devices conserve battery power and potentially achieve longer battery lives. The feature was subsequently inherited by the NarrowBand IoT specification in Release 13. Although it is possible for a device’s application to shut-down its radio module or chipset to conserve battery power, the device would subsequently need to reattach to the network when the radio is turned back on. This reattach procedure consumes energy that can become significant over time, and generates unnecessary signaling. As such, this procedure should be avoided if it would need to occur too frequently. The alternative is to use PSM to disable parts of the chipset protocol stack and drop power consumption into the micro-Ampere range.
Figure: Using PSM to Conserve Battery Power
When a device initiates PSM with the network, it provides two preferred timers (T3324 and T3412). The time during which the IoT device module or chipset is in so-called "Deep Sleep Mode" is the difference between these timers (T3412-T3324). The network may accept these values or set different ones. The IoT Solution Optimizer indicates to users if the network allows IoT application overwriting of the network defaults. The network then retains the state information and the IoT device remains registered with the network during its hibernation. If a device awakes before the expiration of the time interval to sends data, a reattach procedure is not required.
The drawback of using PSM is that the IoT device cannot be contacted by the network while its module or chipset is asleep. The inability to be contacted may preclude the use of PSM for downlink-centric applications requiring frequent or unscheduled communication to IoT devices (e.g. tracking solutions).
The IoT device may request the use of Power Saving Mode (PSM) simply by including a timer with the desired value in an ATTACH, TAU or Routing Area Update Message. The maximum time a device may be reachable after sending this message is 186 minutes; this is the maximum value of the PSM Activity Timer, T3324. By default many mobile network operators set T3324 values between 20 and 30 seconds. Setting the timer to a value lower than 10 seconds may be risky due to the higher latencies and turn-around times that may be experienced by devices in CE-Level 2 (Deep Indoor) coverage conditions. If the device prematurely enters PSM mode, a Downlink message may not be able to be delivered to it.
Upon expiration of the T3324 timer, the chipset or module in the IoT device powers down many of its subsystems to enter "Deep Sleep Mode," where micro-Ampère currents are consumed. The maximum time a device may stay in this hibernation is approximately 413 days (as governed by the 3GPPTM Release 13 T3412 timer). Please note that some operator core networks support shorter T3412 timer values, for example, 310 hours.
The shutting-down of a module or chipset is non-standardized approach that may be used to conserve the power of the IoT device. The problem with using Power Saving Mode (PSM) is that this feature only puts the module to an ultra-low power dormant state; the rest of the hardware continues consuming power, including the sensors, actuators, microcontroller, etc. There are specific use cases, where a hard-cut of voltage to the entire device may be the most preferred course of action.
That said, please note that some chipsets are not able to store the list of recently camped-on networks in permanent memory. As a consequence of this limitation:
IoT application designers must therefore weigh the pros and cons of switching off the IoT device, and then doing a full network scan, versus keeping the device powered with the module or chipset in deep sleep mode. Finally, if devices are regularly powered OFF and ON, the amount of signaling to the mobile network operator's network will increase, as chipset or module must perform a full ATTACH to network to re-register.
The ability to both locate an object and to communicate with it is a combination enabling a wide range of location-based services. The most straightforward method by which a device can know its location is to use a GPS or GLONASS receiver operating completely independent of the cellular network; however, these widely-used Global Navigation Satellite System (GNSS) positioning methods are not suitable for Massive IoT due to the power consumption and cost of GNSS chips. Furthermore, IoT devices may be in locations without satellite coverage (e.g. indoors, encapsulated, or underground), thus not serviceable with GNSS solutions. Indoor environments and dense urban areas are examples where GNSS solutions often fail. As such, the 3GPPTM has invested a significant effort during its Release 14 to enhance positioning support for multiple IoT technologies. What all location-based services have in common is finding where the mobile device is actually located. The Release 14 specification provides support for the following location technologies:
Positioning based on Cell-Identification (Cell-ID or CID) is a network-based technique which can be used to estimate the position of an IoT device quickly, but with very low accuracy. It uses the geographical knowledge of a device’s serving cell to estimate its position. In the simplest case, the position is estimated using only the coordinates of its serving network eNodeB or cell with an uncertainty area in the size of the cell coverage. That said, the size of a cell can be very large (up to 35 km), hence the resulting very low accuracy.
To improve the accuracy of Cell-ID positioning, certain network attribute measurements made by the IoT device and/or the serving mobile network base station (eNodeB) can be utilized in addition to the geographical knowledge of a device’s serving cell. This technique is called Enhanced Cell ID (ECID, for short). In ECID, the Round Trip Time (RTT) between the eNodeB and the device is used to estimate the distance to the between both, giving a much butter estimate of the device’s location compared to simply taking the whole cell radius. The RTT is determined by analyzing Timing Advance (TA) measurements, either from the eNodeB or by directly querying the device. With this technique, ECID is able to provide better accuracy in comparison to CID, typically around 150 meters, or coarser.
Figure: Enhanced Cell-ID
The principle behind Observed Time Difference of Arrival (OTDOA) positioning is similar to GPS a multilateration positioning method. OTDOA is based on the IoT device's wireless communication chipset or module measuring the Time Different Of Arrival (TDOA) between so called Positioning Reference Signals (PRS) of a neighbour cell and those of the serving cell. The PRS Signals are transmitted from a set of time-synchronized base station surrounding the device. Each measurement allows a mobile network positioning server (the E-SMLC) to determine the position of the device to a hyperbola centered around the base stations transmitting the downlink signals. If measurments between three or more base stations are reported, the positioning server will be able to determine multiple hyperbolas and fix the position of the device to the intersection of the hyperbolas. In order to be able to calculate the UE’s location, the network needs to know accurately the locations of the eNodeB transmit antennas and the transmission timing of each cell. Although it is very similar to GPS, OTDOA positioning does not suffer from long time-to-first-fix (TTFF) like GPS, and delivers accuracies in the range of 50-200 meters in typical cases.
Figure: Observed Time Difference of Arrival
Roaming refers to a service provided by a mobile network operator that allows its customer’s 3GPPTM-capable IoT devices to connect to an alternative cellular network beyond the range of the "home" network. In that way the devices are able to send and receive data, as well as access other services through the "visited" network as if they were using their home operator’s network. This helps ensuring a seamless coverage and service continuity for the customers especially in applications of high mobility or global deployment. Roaming among the different operators is only possible when the corresponding roaming agreements that conclude the legal aspects of mutual network usage were signed between the parties. If there is no roaming agreement in place, the customer SIM will be rejected by the visited network. The guidelines on roaming agreements are defined by GSMA for its members and may differ depending on radio access technology (RAT) type.
Different types of roaming can be differentiated, among others:
Roaming is particularly important to manufacturers deploying Mobile IoT devices on a global basis and looking to benefit from economies of scale. It is also critical for use cases such as logistics tracking, which may involve containers crossing numerous international borders on a single trip, as well as for devices that may be manufactured in one country but deployed in another, such as smart meters.
Not only lack of commercial agreements of mobile operators may create limitations in realization of some use cases. It can be restricted by the technological disparity in network implementation, as per country’s use of different frequencies, network configuration, implementation of certain features (e.g PSM or eDRX), or support of particular services like voice or SMS. Such aspects must be considered when designing an IoT application and choosing a suitable hardware for the use case.
Single-mode chipsets and modules support only one radio access technology (RAT), for instance, NB-IoT or LTE-M. As such, they cannot be used on mobile networks where the supported RAT is not implemented. The advantage of using a single-mode chipsets and module are their optimized power consumption, smaller size, lower cost, and ease of use. Typically IoT uses cases which are static in nature (neither moving nor roaming) can be conveniently implemented with single-mode modems. Although single-mode module usually do not need any pre-configuration, they can programmed via AT commands for specific frequency bands in a particular geographic region in order to improve their network scanning times.
"Multi-mode" operation is the configuration of a wireless communication module or chipset so that it actively supports more than one LPWA technology in the same SKU, bringing the flexibility to deploy devices in different networks with the same product variant, as well as seamless international coverage wherever one of the supported radio access technologies (RAT) are not available. Modules and chipset that offer multi-mode coverage support dynamic reselection of RAT types to either LTE-M, NB-IoT or EGPRS as a preferred connection.
Multi-mode modules are beneficial when specific operations are more efficiently carried out in a specific RAT, whereas other operations may perform better in another RAT. Take firmware updates, for instance. Due to their large sizes, firmware updates may be transmitted more efficiently using LTE-M rather than NB-IoT. For the standard, hourly transmission of small sensor readings, NB-IoT may be more suitable. The application logic can be designed such that standard sensor measurements are transmitted over NB-IoT, whereas the bi-annual FOTA update is sent via LTE-M. Wherever LPWA coverage is not available, 2G Fallback can be used to guarantee coverage.
New RAT types are selected based on the pre-configured network setting on devices. Alternatively, the new RAT can be selected dynamically by requesting it from the network, or when a network connection drops and a new network is acquired. Finally, multi-mode modules and chipsets typically allow for the configuration of higher priority RAT and network scanning: As there is no specific standard, generally the RAT setting and network scan settings can be pre-configured by applications by using vendor proprietary AT commands.
2G fallback is a feature supported by a subset of multimode Mobile IoT modules, supporting NB-IoT and/or LTE-M in additional to EGPRS. The switch of radio access technology (RAT) transpires when either NB-IoT and/or LTE-M coverage is not available, or their received signal strength is very low.
With regards to mobility, NB-IoT is a separate RAT from E-UTRAN. As per 3GPPTM specification 36.304 and 36.331, inter-RAT cell selection and reselection in Idle and connected Modes is not supported, including handover and measurement reporting. In short, NB-IoT does not have network-controlled mobility between UTRAN, E-UTRAN, GERAN, and CDMA2000.
The module's behavior can be configured via AT commands generally. Proprietary AT commands provided by module vendors allow for the customization of the RAT scan sequence, RAT scan mode, RAT band configuration, etc. When roaming, the module will also automatically search for a new network; the behavior in this scenario can also be affected via AT commands and SIM card properties.
2G fallbacks may occur during the following scenarios:
Currently deployed NB-IoT and LTE-M networks are designed with the assumption in mind that devices operate in either of two power classes of 3GPPTM Release 13 – Power Class 3 (which can transmit with a power level of 23dBm) and Power Class 5 (20dBm). Reducing power transmission by 50% can lead to a reduction in coverage when using Power Class 5. The Signal-to-Noise Ratio (SNR) detected at the serving eNodeB (network cell) becomes lower; therefore, the device will need to perform more repetitions to enhance coverage. Power Class 5 devices may be out of coverage in places where Power Class 3 devices can still connect to the network in Coverage Enhancement Level 2 (CE-Level 2).
3GPPTM Release 14 introduced a further improvement in power and coverage performance with its Power Class 6. This reduces the UE’s maximum output power further to 14 dBm. Although the Uplink coverage is reduced by 9 dB, with a corresponding 155 dB Maximum Coupling Loss (MCL) vs. Power Class 3’s 164 dB MCL, it has the positive effect of reducing battery consumption on the device. Release 14 compensates the reduced output power by increasing transmission time, maintaining the same energy per bit as seen in Release 13. The specification also defines the mechanism permitting the serving eNodeB to detect the device power class during the connection establishment. This new power class ushers in the possibility to use small coin-cell batteries, which are ideal for limited-size devices and applications, such as wearables.
Link budgets are an accounting of all power gains and losses experienced by communication signal in a certain telecommunication system. This includes all gains and losses experienced at a transmitter, propagation through a medium (free space), as well as all power gains and losses at the receiver.
Traditionally, network planning has used "Maximum Allowable Path Loss," MAPL for short, to define the geographic region in proximity to the transmitter where reception and demodulation of its transmitted signal was still possible by a specific receiver. The MAPL is the difference between the transmitting end's total radiated power (TRP) and the receiving end's total isotropic sensitivity (TIS), in decibels (dB). When propagating signals experience less attenuation than the MAPL, the receiver is still able to detect them. As soon as a path loss greater to the MAPL, the receiving end can no longer detect and demodulate the transmitted information. MAPL can be described as such:
MAPL (dB) = P Tx - (Noise Figure + SINR + Noise Floor)
+ Antenna Gain Tx + Antenna Gain Rx
That said, in the case of NB-IoT and LTE-M, most low-cost IoT devices do not integrate optimized antennas with high gains. This means that the ability of devices to close the link budget with these technologies is highly dependent on the implementation of individual device antennas. To normalize the terminal-related aspects, the standardization bodies opted to use Maximum Coupling Loss (MCL), which is the maximum propagation loss possible in the conducted power level (= without antenna gain) which the radio link can tolerate and still demodulate a signal at the receiving end. MCL has therefore established itself as an industry term referring to the coverage performance of Mobile IoT radio access technologies from a link budget perspective. MCL essentially the difference in power (in dB) between the conducted transmit power (in dBm) minus the receiver sensitivity (in dBm). Another way to express this is given by the following formula:
MAPL (dB) = MCL + Antenna Gain Tx + Antenna Gain Rx
In the figures below, standard link budgets for NB-IoT are graphically depicted. Please note that the MAPL in the Downlink and Uplink are approximately the same. The secures link balancing, i.e. that the user equipment's "receiving" footprint is approximate to the serving cell's (eNodeB) "receiving" footprint. As most 3GPPTM procedures are bi-directional, a balanced link is critical to ensure an optimized network operation with minimal access failures, packet loss, and power efficiency.
Figure: NB-IoT Link Budget to "Close" the Downlink
Figure: NB-IoT Link Budget to "Close" the Uplink
In the broadest sense, the term "device management" (DM) refers to tools, processes or capabilities that allow managing different types of devices or machines. In context of IoT, it usually refers to a software or an application that provides functionalities to remotely administer, maintain and operate devices. It provides an immense simplification of handling especially large volumes of devices, in which most of operations can be automated, and on-site activities can be reduced to minimum. Device management therefore has become one of the key aspects of deploying successful IoT applications. The main functionalties of a device management software can be clustered in the following key categories:
The rapid growth of Mobile IoT creates the need for even more sophisticated device management functionalities that enable the more efficient control and management of multiple types of devices. Driven by the search for further efficiency and simplification in IoT applications, a new set of standards have emerged with specifications addressing the complexity and variety of device management deployments. These include the 3GPPTM Release 13 Service Capability Exposure Function (SCEF), as well as the Open Mobile Alliance's (OMA) Lightweight Machine to Machine (LwM2M). The latter uses efficient header and payload encoding, blockwise transfer fragmentation handling, built-in congestion control, and utilization of the more power-efficient CoAP protocol over Non-IP or UDP/IP, to make it ideal for NarrowBand IoT and LTE-M deployments.
Firmware Over-the-Air (FOTA) refers to the wireless download from a server of an operating firmware package for wireless communication modules. This is different from the downloaded updates of MCU-flashed application code running on an IoT device, referred to as "Software Over-the-Air" (SOTA). Once received, the FOTA client installs the new code. With this technology the code on an embedded device that contains new features, bug fixes, or security patches, can be conveniently and reliably updated without having to physically connect a device to any other source.
FOTA is a fast and a cost-efficient method for dealing with the mass of devices in the field and ensures more security in the Internet of Things. One of the common FOTA implementations has been defined in the architecture for Mobile Device Management (MDM) systems, standardized by OMA. Four states are defined: Idle (State=0), Downloading (State=1), Downloaded (State=2), and Updating (State=3). FOTA as it is defined by OMA includes the following features:
Lightweight M2M (LwM2M) protocol is an open-industry messaging protocol defined by the Open Mobile Alliance (OMA) for device management of in-field, fixed or mobile M2M/IoT devices, currently in its version 1.1 release. As the successor to the OMA Device Management (OMA-DM) specification, this REST-based protocol is used to communicate between the LwM2M client software (on an IoT device) and LwM2M server software (on an IoT management platform). LwM2M's simple resource model includes a set of Objects and corresponding Resources that can be created, updated, deleted, and retrieved asynchronously. It covers device management actions - such as bootstrapping, device configuration, firmware updates, fault management/diagnostics, and connection management, as well as data plane actuations - control, data reporting, and lock and wipe, for instance. Diagnostics include the ability to query the battery level of a device, consult the device's settings, assess the memory status, identify the firmware, software and hardware version of the device and its components, as well as identify its capabilities. Connection Management entails the management of basic parameters for the device's cellular connectivity on the operator network, such as APN, WEP keys, bearer selection, etc. The control functionalities of LwM2M include the ability to set-up access control on LwM2M Objects for various servers, reboot the device, disable the device for a specific amount of time, or force devices to perform a registration procedure.
The LwM2M standard was created as a response to the demands of the expanding M2M/IoT market to overcome certain limitations, such as cost-effective remote management of battery-powered, constrained devices (<20kB RAM), cross-standard interoperability, and security issues. The client and server communication is done over CoAP. Furthermore, IPSO V1.0-defined LwM2M Objects may sit atop, providing data models for different industries - connected car, smart cities, transport, and industry, among others.
LwM2M is commonly used in Mobile IoT use cases for Device Management and Service Enablement, as it supports numerous key aspects that are critical for M2M/IoT devices having low-power microcontrollers and small amounts of Flash and RAM, transmitting over 3GPPTM networks requiring efficient bandwidth usage:
The following four logical interfaces are defined on both LwM2M server and client:
Figure: LwM2M Interfaces and Flows
Although CoAP may be used over MQTT/TLS/TCP, the IoT Solution Optimizer does not offer this option due it is unsuitability for Mobile IoT use cases.
LwM2M resource model defines each piece of information made available by the LwM2M Client as a "Resource." These are further logically organized and grouped into Objects. The Firmware Update Object, for example contains all Resources used for firmware updating purposes. The body OMASpecWorks is responsible define these optional Objects, which extend the capabilities of the LwM2M standard. Objects sit atop the LwM2M protocol, and just below the application itself. For a full list of defined Objects, please refer to the: LwM2M Registry. A partial list of available LwM2M Objects is presented below:
The IoT Solution Optimizer currently models IoT application communication between the server and IoT device client as an “average reporting event.” This transaction may represent a regular payload exchange that is either device-initiated (uplink payload is initially sent to the server after a random access procedure and set-up of an RRC bearer) or server-initiated (downlink payload is sent to the device after a successful paging of the device and set-up of an RRC bearer). Naturally, handshake exchanges of messages are also possible, e.g. and uplink message is closely followed by a downlink and/or uplink messages, or vice-versa. Each transmission to/from the IoT device cannot exceed the maximum transmission unit (MTU) size. For most wireless communication modules, this is either 512 Bytes. Larger messages by broken up into multiple transactions, each maximally 512 Bytes in size.
Figure: Example Application Reporting Event
IoT applications may require different types of messages to be scheduled and exchanged. Consider, for instance, an application that sends hourly temperature reports, weekly maintenance logs, and yearly firmware updates. In order to properly model such complex communication patterns, the IoT Solution Optimizer will soon implement capabilities allowing such scheduled interactions to be properly configured and considered in a performance analysis. If you have specific needs which are currently not supported by our service, please contact Tool Support to provide feedback which may be considered to develop this service further. Our goal is to address your design and optimization needs as best as possible.
Users may send their data between the IoT device and the mobile network using Internet Protocol (IP). As the MNO's system is a private network, it is actually technically possible to avoid using IP to send datagrams between endpoints. This type of Non-IP transport, also known as Non-IP Data Delivery (NIDD), may be available for specific technologies that benefit from its use - such as NB-IoT and LTE-M. Please note that this option is only available if it is supported by both the chipset protocol stack in the device's wireless communication module, and the mobile network.
Less critical for the decision of whether to use IP or NIDD is the overhead protocol that is intended to be used. CoAP and MQTT-SN are the most efficient messaging/management protocols available for bandwidth- and power-optimized, constrained Mobile IoT devices. They may be sent over a NIDD bearer between the IoT device and the operator network. TCP-based protocols, such as MQTT and HTTP, as well as and UDP transport require to be sent over IPv4/IPv6. The intended protocol therefore influences the decision of whether to use Non-IP Data Delivery, or not.
Figure: Internet Protocol Options
There are many benefits to transporting your IoT application data over Non-IP. This capability, known as Non-IP Data Delivery (NIDD) is supported by certain NarrowBand IoT networks, wireless communication chipsets and modules which are commercially available. With NIDD it is possible to improve communication efficiency and reduce operative costs, as little to no protocol overhead needs to be sent over the air:
Figure: Non-IP Data Delivery vs. IP-based Data Delivery
Do you want to learn how Non-IP works on some mobile operator networks?
Non-IP Data Delivery (NIDD) is often used by enterprises wanting to optimize their payloads and IoT application efficiency. IApplication payload can be directly sent over the Non-IP bearer, or encapsulated in MQTT-SN or CoAP. In the case that the application data wrapped in HTTP and MQTT, it is necessary to use the TCP/IP protocol underneath, which thus precludes the usage of NIDD in your M2M or IoT solution. Mobile network operators can implement NIDD in two different ways:
Figure: How Non-IP Data Delivery Works (Uplink)
Figure: How Non-IP Data Delivery Works (Downlink)
The Internet Protocol Version 4 (IPv4) is the network layer protocol forming the technical foundation of the Internet of today. It provides addressing and routing of packages in, and between, IP networks as a service to higher (transport layer) protocols, such as TCP and UDP.
Figure: IPv4 20-Byte Header
IPv4 was introduced in 1981, before the Internet became the household commodity it is today. It operates with an address length of 32 Bits, which allows addressing of 232, or ca. 4.3 billion hosts. Due to inefficiencies in address assignment, far less hosts can addressed in practice. Although mitigating measures, such as Network Address Translation (NAT), have been put in place over the past decades, IPv4 is no longer able to support the growing Internet with a sufficient number of addresses. IPv4 will therefore be gradually replaced by IPv6 over the coming decades. IPv6 offers a far larger address space of 2128 addresses, among other optimizations.
Using IPv4 on a device requires an implementation of the lower and higher layers of the OSI model, including a transport protocol like UDP or TCP. This can render IP-based data transfers less suitable for applications requiring low cost devices or low energy consumption in devices intended to operate over many years on a battery. For NarrowBand IoT devices, Non-IP Data Delivery (NIDD) can be an option with lower energy consumption and complexity than IP-based protocols.
Figure: Comparisons of Protocols - IPv4
The Internet Protocol Version 6 (IPv6) is the designated successor IPv4, the protocol that forms the technical foundation of the Internet of today. As a network layer protocol, it provides addressing and routing of packages in, and between, IP networks as a service to higher (transport layer) protocols, such as TCP and UDP.
With a 128-bit address length, it removes the main limitation of IPv4 by increasing the address space from approximately 4.3 billion in IPv4 to around 3.4 x 1038 addressable hosts. IPv6 will gradually replace IPv4 over the coming decades because the IPv4 address space is already insufficient tp address the exponentially growing demand of today's Internet traffic - requiring mitigating measures like Network Address Translation (NAT), let alone that of the developing Internet of Things.
Similar to IPv4, IPv6 requires an implementation of the lower and higher layers of the OSI model, including a transport protocol (TCP or UDP). This can render IP-based data transfer less suitable for applications requiring low cost devices or low energy consumption in devices. For NarrowBand IoT devices, Non-IP Data Delivery (NIDD) can be an option with lower energy consumption and complexity than IP-based protocols.
Figure: Comparison of Protocols for IoT
3GPPTM specifies three types of PDP/PDN to describe connections: PDP/PDN Type IPv4, PDP/PDN Type IPv6, and PDP/PDN Type IPv4v6. Each time the wireless communication module establishes a data session, a particular PDP/PDN Type is requested from the supported types communicated by the network during the Attach sequence. This request triggers the MME to initiate a PDP/PDN request via the Serving Gateway (SGW) to Packet Data Network Gateway (PGW) modulo subscription grants.
PDP/PDN Type IPv4v6 was introduced with LTE's Evolved Packet System (EPS) core network architecture. It allows the IoT device to get an IPv4 address and an IPv6 prefix within a single PDP/PDN bearer. This option is stored in the HSS as a part of the IoT device SIM's subscription data. Although mobile network operator 4G infrastructure should have no issues in handling this PDN Type, the level of support varies in GSM/UMTS networks depends on the Serving-GPRS Serving Node (SGSN) release firmware. In order to avoid Attach problems at a visited SGSN, operator roaming agreement supporting IPv6 must account for IPv4v6 and ensure that the implementations align with GSMA requirements.
The choice of transport protocol will define which messaging or management protocol can be used on top:
At the end, the choice of transport mechanism impacts the number of IoT device-originated messages needed to perform a handshake with the server, the supported feature capabilities (including optional headers), as well as the interoperability with cloud connectors.
Figure: Transport Protocol Options
The Transmission Control Protocol (TCP) is a connection-oriented, end-to-end reliable protocol designed to fit into a layered hierarchy of protocols which support multi-network applications. TCP implements the OSI model's Transport Layer and typically uses IP (IPv4 or IPv6) as the protocol bearer for communication over the Internet. That said, it can also be used with other lower-layer protocols. TCP requires only a basic datagram service from its lower-layer protocol and makes little assumption as to the reliability of the lower layer. It takes care of sequence-numbering of data segments and repetition of missed segments to provide the data in the correct order and without missing segments.
Figure: TCP Protocol Header
Within a TCP connection, data can be transferred in both directions between the connected network nodes. To provide this service, TCP must add a relatively large amount of overhead to the transferred data, e.g. for acknowledgement of successfully transferred segments, repetition of lost segments and connection management. Both the set-up and tear-down of a TCP connection requires an exchange of at least three packets, each. Because of the need for the sender of data to repeat missing segments, these segments must be stored until they are acknowledged, thereby requiring a relatively large amount of memory on the side of the sender. As such, TCP is most suitable for the transfer of large amounts of data with no real-time requirements. It is less suited for low cost devices requiring low energy consumption. Usually, TCP/IP is used in conjunction with MQTT or HTTP protocols in M2M or IoT services.
Figure: TCP Transmissions with(out) Keep-alive Messages
Another important feature of TCP is that the sessions are prone to be closed by Mobile Network Operator firewall timers. To prevent this, a "keep-alive" message must be periodically sent. This results in three possible scenarios for TCP transmissions over 3GPPTM mobile networks, as shown above:
Figure: Comparison of Transport Protocols - TCP
Transport Control Protocol (TCP) allows for a session-based communication. Sessions must be started between peers, maintained, and eventually terminated. As network NAT proxy or firewalls do not allow inactive data sessions to remain active over longer periods of time, they may teardown the TCP pipe in-between without either of the peers being aware. This unfortunate situation may even lead to exception scenarios where improperly-designed IoT devices are unable to recover the data communication, or a device reboot is required.
TCP "keep alive" messages are available to prevent the premature tear-down of an active TCP session. When setting up a TCP connection, timers related to the "keep alive" procedure are negotiated. When the respective timer reaches zero, the TCP client sends its peer a "keep alive" probe packet with no payload data within it; TCP permits the handling of zero-length data packets. Additionally, the acknowledgement ACK flag is also enabled in the probe packet. The remote host will also reply with no data with an ACK set. Once the reply to the "keep alive" probe is received back at the client, it has essentially confirmed that the connection-based data pipe is still available for application traffic to the host. The same "keep alive" probe resets the network-side firewall timer to avoid premature disconnection. Depending on the network and/or remote host endpoint configuration, "keep alive" probe packets may need to be sent every few minutes. This has a considerable impact on the battery life of the IoT device; hence, it is strongly discouraged to use this feature for Mobile IoT technologies such as NB-IoT and LTE-M, unless it is absolutely necessary. Connectionless protocols such as CoAP and MQTT-SN do not require TCP "keep alive" messages.
Figure: "Keep Alive" Probe Packets include Acknowledgement
Figure: TCP "Keep Alive" Probe Packets are sent periodically
The TCP "keep alive" procedure can be used to identify if peers have lost their connection (e.g. by rebooting or moving out of coverage), advise one end when the peer dies (e.g. by drained battery, tampering, or malfunction), or when the network connection in-between goes down. As stated earlier, "keep alive" can also be used to prevent disconnection of the channel due to inactivity. This is caused by the connection tracking procedures implemented in proxies and firewalls, which track all connections passing through them. Because they are only able to keep a limited number of connections in their memory, older, inactive connections are regularly purged. Periodically sending "keep alive" probe packets over the network is a simple method to always be in an optimal position in the firwall's queue, with limited risk of sesson deletion. Operator networks usually have NAT proxy timers of 27 to 30 minutes. Some public clouds require regular "pings" to their connectors; Microsoft Azure IoT Hub, for instance, recommends an "keep alive" probe every 15 minutes. This has a negative impact on device performance due to excessive battery drain, just for maintaining the active date session between both end-points open.
The User Datagram Protocol (UDP) is a connection-less transport-layer protocol using IP (IPv4 or IPv6) as the underlaying protocol for communication over the Internet. UDP provides for addressing and the basic transfer of datagrams over IP networks. In contrast to TCP, UDP provides no protection against loss of data segments or segments arriving in an incorrect order. UDP is therefore best suited for applications where protection against loss of data is implemented in higher layers, or not required at all.
Figure: UDP Protocol Header
Due to the less complex nature of UDP as compared to TCP, it can be implemented on simpler hardware. Given its reduced overhead, UDP lends itself to applications mandating low energy consumption and data efficiency, such as Mobile IoT use cases. The UDP transport protocol is generally used in conjunction with MQTT-SN or CoAP in the case of M2M and IoT services. Additional key features of UDP:
Figure: Comparisons of Transport Protocols - UDP
A key aspect to consider in the dimensioning of application message is the Maximum Transport Unit (MTU) size of the Uplink TCP/UDP payload; this is represented in the figure below as "UDP Payload." The Downlink TCP/UDP payload is not affeted by this limit. The MTU controls how large the payload and protocol can be which sits on top of the TCP or UDP Transport bearer. This "TCP payload" or "UDP payload" includes the application payload, the messaging/management protocol and the MAC TAG from TLS/DTLS/HTTPS transport encryption, if used.
Figure: Maximum MTU Size
There are different maximum TCP/UDP payload sizes supported per chipset/module based on the underlying transport/IP protocol that is used (TCP/IPv4, TCP/IPv6, UDP/IPv4, UDP/IPv6, Non-IP). Based on the selection chipset / module, and selected transport/ Internet protocol, users will be limited in how large their individual TCP/UDP payloads can be.
Figure: Uplink MTU Sizes, Select Modules
Currently, the IoT Solution Optimizer does not model the impact of security cryptographic protocols for data encryption on the power performance of Mobile IoT devices. Such protocols ensure data integrity and privacy between IoT devices and their application servers over the Application Layer. In general, the following applies as guidance:
In the coming months, support for TLS, DTLS and HTTPS will be included in the IoT Solution Optimizer.
Figure: Transport Encryption Options
Transport Layer Security (TLS) is a cryptographic security protocol for a secure communication between a server (e.g. cloud) and a client (e.g. a device). It is regarded as the successor to SSL (Secure Socket Layer), an older protocol for data encryption. TLS ensures a secure data exchange as it deploys mechanism for encryption, authentication and integrity, which serve as a foundation for secure communication over the Internet.
TLS is designed to work over a reliable transport channel, such as the Transmission Control Protocol (TCP) on Transport Layer. It is stream-oriented, which means that it requires a data record in a particular sequence for correct data decryption. TLS is often being used for encryption of MQTT messages.
Using TLS is not mandatory, however when designing TCP-based IoT applications it is always recommended to use TLS for communication between a device and a remote server to avoid security risks, such as eavesdropping, tampering, or message forgery. Currently, TLS Versions 1.0 - 1.2 have been in use, whereas version 1.3 will bring further improvements for IoT applications. It is always recommended to use the latest version of the TLS for more security.
Datagram Transport Layer Security (DTLS) is a security protocol for secure data transfer which ensures communication privacy for IoT applications. It was based on the extisting structure of TLS protocol, adding additional features to support datagram-based communication. It provides security guarantees equal to TLS for encryption, authentication, and integrity, preventing from potential security risks (e.g. eavesdropping, tampering, or message forgery). DTLS is designed to be working over an unreliable transport channel. Typically, the User Datagram Protocol (UDP) protocol on transport layer is used to handle a packet loss in case of connection break. The implemented mechanism allows therefore the protocol to reorder or resume the transfer of packets for transfer efficiency without compromising on security measures, for example, authentication or E2E encryption. CoAP messages are often encrypted using DTLS.
Currently, DTLS Version 1.0 - 1.2 are in use, whereas version 1.3 shall brings further improvements for the IoT applications. It is always recommended to use the latest version of the DTLS to ensure more security.
Hypertext Transfer Protocol Secure (HTTPS) is a communication method using TLS (or formerly SSL) encryption over the standard application layer HTTP protocol to secure the data transfer over the Internet. HTTPS therefore utlizes the security mechanisms of TLS such as encryption, authentication and integrity to safeguard the data transfer. It was primarly introduced to add a layer of security over HTTP to protect against possible leakage of sensitive information (e.g. e-mails, login data, financial transactions over the Internet, etc.); however, it becomes relevant also when browsing the web, as all information on the content searched can remain private.
When implementing an IoT application for Mobile IoT deployments, it is necessary to carefully select the protocol that will be used for messaging and management of deployed devices. Among the various options that exist, the following two are based on TCP transport protocol on top of IP-based Internet protocol:
Likewise, the following two protocols may be used, based on either Non-IP Data Delivery or on UDP transport protocol on top of IP-based Internet protocol:
As seen in this simple comparison, the most efficient IoT protocols for NarrowBand IoT would be MQTT-SN or CoAP, preferably transmitted without UDP/IP encapsulation. This helps to reduce the power consumption at the IoT device to a minimum.
Figure: Messaging/Management Protocol Options
Message Queuing Telemetry Transport (MQTT) is a publish/subscribe messaging protocol and telemetry technology used to interconnect M2M and IoT applications in constrained environments. It is optimized for embedded systems with limited processing power and memory. It was invented in 1999, and the latest version 3.1.1 is an OASIS standard since 2014.
Summary of Key Qualities:
MQTT uses a publishing/subscribing model, instead of a point-to-point approach. The data carried by the MQTT protocol across the network for the application has an associated Quality of Service and Topic Name. Clients are referred to as “publishers” and “subscribers” instead of senders and receivers:
Figure: Example MQTT Parking Sensor Application
As MQTT is transported over a TCP/IP bearer, there are three possible TCP transmission scenarios, as shown below:
Figure: MQTT over TCP Transport Protocol
As MQTT is a transport protocol focusing on message transmission, IoT solution developers have the responsibility to implement appropriate security features separately. MQTT is used by numerous cloud-based platforms and services, including Amazon Web Services (AWS), Microsoft Azure, OpenStack, and Facebook Messenger.
Figure: Comparison of IoT Protocols - MQTT
How do clients establish a connection to the MQTT broker?
1. The client sends Connect Command to broker, containing:
2. The broker sends a CONNACK command back to the client in acknowledgement.
3. The connection is established.
How does the subscription process for topics work?
1. The SUBSCRIBE command can have one or more topics, each with maximum QoSlevels for server messages to the client. The command that the client sends to the broker contains:
2. The broker sends SUBACK command to the client in acknowledgement.
3. The broker updates its subscriptions database, containing:
How does the client publish updates?
1. The client sends a PUBLISH command to the broker, containing:
2. The broker sends a PUBLISH to every client subscribed to this topic.
3. The broker updates its message database if the retain flag is set with latest message for this topic. The next time that a new client subscribes to this topic it will receive the last retained messagedirectly.
Message Queuing Telemetry Transport - Sensor Networks (MQTT-SN) is based on the MQTT standard and makes the protocol more lightweight for use with sensor and actuator solutions. It is aimed at embedded devices using Non-IP Data Delivery (NIDD), UDP/IP or ZigBee networks.
Gateways are used as a bridge to translate between MQTT and MQTT-SN commands. An MQTT-SN gateway functionality can also be directly integrated into the broker, or be implemented as a separate entity. Clients can find these gateways automatically by using a DISCOVERY command; that is, clients do not need to be preconfigured with a gateway or broker address.
Multiple Gateways may be present at the same time within a single wireless network, for example, for load sharing or outage backup. Two possibilities exist for their implementation:
Figure: MQTT-SN Session Protocol & Overhead
Unlike MQTT, the Topic Name is replaced with 16-bit TopicID integers to shorten the amount of transmitted data. These TopicIDs can be preconfigured for individual clients in a known network to avoid sending REGISTER commands; this can be done either from client to broker, or vice-versa. Short Topic Names (2 characters) can be used instead.
As clients can be in sleep state to save power, gateways, in turn, buffer messages for sleeping devices.
Finally, QoS Level -1 allows simple clients to send messages directly to known gateways, even without having the initial connection set-up, registration or subscription necessary.
Due to these enhancements, several mobile network operators promote the usage of MQTT-SN for NarrowBand IoT networks.
Figure: Comparison of IoT Protcols - MQTT-SN
How is the client registration of topic done, to receive a TopicID?
1. The client sends register command to Gateway, containing a Long Topic Name.
2. The gateway sends REGACK command back as acknowledgement, containing:
3. The gateway updates internal database for this client, including:
How do clients discover a Gateway?
1. The gateway broadcasts the ADVERTISE command.
2. Clients searching with SEARCHGW command as broadcast with a radius measured in hops.
3. A gateway responds to the client with GWINFO command.
4. The client can then connect to the gateway.
How are clients assigned QoS Level -1?
(Preconditions: The gateway address is preconfigured in client)
The client sends a message with predefined TopicID, and does not care if either the gateway is reachable, or if message was received.
Compared to QoSLevel 0 with known gateway:
How is the sleep procedure managed?
1. When the client connects to a gateway, the gateway saves client state as “active."
2. In the event that a client sends a Disconnect command with a sleep duration time (a Disconnect command without sleep duration is considered as a regular client disconnect), the gateway saves the client state as “asleep.”
3. When the client wakes up to send a message, the gateway saves the client state as “awake” (If no ping is sent after sleep duration, the state is lost).
4. The gateway thereafter sends all buffered pending messages to client. The gateway sends a ping response and client goes to in the state “asleep.”
The Constrained Application Protocol (CoAP), as defined in RFC 7252, is a specialized Messaging Protocol that is optimized for use on memory- and power-constrained devices, such as M2M and IoT devices with 8-bit microcontrollers with small amounts of ROM and RAM. The integration of IoT services with existing web services is facilitated with CoAP, which interfaces server-side to HTTP via proxies. The protocol thus meets the needs of mass-deployed, resource-limited devices which must communicate with each other with a request/response interaction model across the LPWA network or Internet, with moderate QoS. This is different from MQTT, which uses a publish/subscribe model and offers higher QoS support. Apart from multicast support, CoAP supports smaller overhead, built-in discovery of services and resources, and Web features such as URIs and Internet media types. Architecturally, IoT devices install a CoAP server; the CoAP client is installed on the controller that manages multiple IoT devices.
Figure: CoAP Protocol Header
CoAP typically runs on devices supporting UDP/IP or Non-IP Data Delivery. Depending on the usage of option features, it typically adds 20-30 Bytes of overhead on top of the application payload. The specification has optimized CoAP to ensure:
Figure: Comparison of IoT Protocols - CoAP
The Hypertext Transfer Protocol (HTTP) is the REST-based application layer protocol most commonly used for the transfer of hypertext documents from servers on the World Wide Web to client computers, which can display the content in a web browser. Besides this application, HTTP is also commonly used in Machine-to-Machine (M2M) communication and for file transfers.
HTTP consists of a collection of request methods which provide and control the transfer of data between a server and a client in a synchronous way. The most prominent request methods are GET, which retrieves a hypertext document from a server, PUT and POST, both of which upload data from a client to a server. It was introduced in 1996 as HTTP/1.0 and since then has seen a number of updates and extensions improving efficiency (HTTP/1.1 and HTTP/2.0) and both security and privacy (HTTPS).
Because HTTP is a plain text protocol based on the TCP transport layer protocol, it creates a relatively large overhead compared to binary protocols and protocols based on UDP instead of TCP. This makes it less suitable for M2M or Internet of Things (IoT) type communication when low cost of devices and low energy consumption are prime concerns. The most prominent HTTP request methods are:
Figure: HTTP over TCP/IP Transport
As MQTT is transported over a TCP/IP bearer, there are three possible TCP transmission scenarios, as shown above:
Figure: Comparison of Protocols for IoT - HTTP
Mobile IoT technologies are highly optimized for maximum power efficiency. IoT applications that try to send data with very large payloads, low latency requirements, and/or with a high frequency of messages are not suitable for either NarrowBand IoT or LTE-M. Furthermore, Mobile IoT is not designed for use in real-time and streaming services, such as those of Critical IoT. Service providers should not attempt to use this more economical bit pipe as an alternative for conventional 2G / 3G / LTE applications. Failing to adapt IoT application behavior to the NB-IoT and LTE-M paradigms may not only prematurely drain a battery in an IoT device, but it may congest or damage the mobile operator's network. A few devices transmitting large payloads every minute, in close proximity to each other, may even congest a cell, taking service away from other paying customers. Keeping this in mind, it is troublesome to consider the quality of service that one should expect on the networks of those service providers not creating governance models to ensure No Harm to Network (NHTN), or even entering into marketing-driven "megabyte offering" competitions.
To enforce communication efficiency, the IoT Solution Optimizer compares your proposed IoT application traffic (application payload plus protocol overhead) to the market-specific rules bound to your selected tariff market. These limits determine the maximum allowed monthly data volume and the maximum number of events per day on the selected tariff network, whereby one “event” is considered to be the IoT application traffic configured in the “Payload and Protocols” screen.
If your IoT application is required to transfer more frequently or larger monthly payloads than allowed on a specific Mobile IoT network, please consider a more efficient communication implementation. There are several options available:
Please keep in mind that trying to force a use-case into a technology for which it was not designed for, may lead to costly operational and quality problems.
Mobile network operators takes service quality seriously. In order to secure the Service Level Agreements (SLAs) which we offer our customers, we must ensure that there is No Harm to Network (NHTN) from IoT Devices. The risks are quite high, and the consequences are well known: many things can happen - from unrecoverable devices out on the field, to signaling storms threatening the radio and core networks, back-end business and operations infrastructure and cloud. There are numerous reasons for this greatest of IoT challenges:
With all of these aspects considered, it becomes necessary to implement a governance model for doing business. Mobile network operators approach the problem from several angles. They actively engage in the definition of the GSMA TS.34 "IoT Device Connection Efficiency Guidelines," the industry's only specification for NHTN. Features have been defined in this forum for industry implementation, namely, the Radio Policy Manager and Network Friendly Mode. Furthermore, they actively encourage the specification's adoption and observance among suppliers and the customer base. Whenever deployed volumes of a specific IoT device exceed a tariff-defined number of SIM cards, both the customer's IoT service platform and the IoT device application may be required to be compliant with GSMA TS.34. The number of SIM card units is set at the level where network-impacting devices may become statistically relevant in pockets of the operator's network. Improper implementation of the IoT application may cause network-side damage either locally or generically.
Many mobile network operators require the implementation and activation of the Radio Policy Manager (RPM), a GSMA TS.34 feature which, when implemented within the 3GPPTM chipset, helps protect the network from the signaling overload caused by improperly-designed IoT applications. To-date, RPM is the sole industry solution deployed worldwide, which optimizes how IoT devices communicate. This chipset feature limits the number of mobility management (MM) and session management (SM) signaling events allowed per IoT device during a configurable time-window, for example:
As per several mobile network operators' No Harm to Network governance models, availability and activation of RPM is a requirement whenever the number of devices a customer wants to bring onto their networks exceeds a certain number of units. For this reason, there is close collaboration with radio chipset suppliers to integrate this feature into the chipset's protocol stack for NarrowBand IoT and LTE-M devices. RPM is defined in Chapter 8 of the TS.34 specification.
Key objectives can be summarized as such:
The following OEM modules already support the GSMA TS.34 Radio Policy Manager:
Network Friendly Mode (NFM) is a non-standardized feature of the 3GPPTM communication module whose objectives include:
Network Friendly Mode is composed of two features: a Start Timer and Back-Off Timer. The latter is activated by specific back-off triggers, and configured via a back-off iteration counter and back-off base intervals.
All functionalities of NFM were previously described in Chapter 7 of the GSMA TS.34 specification. In the latest releases of the specification, however, the NFM feature was completely deprecated. No additional industry support for NFM is currently planned as most operators prefer instead the implementation of the chipset-based Radio Policy Manager over the OEM module-based NFM feature. Furthermore, very few OEM module suppliers actually implemented this feature for the M2M / IoT business.
The horizontal architecture standardized by oneM2M defines an IoT Service Layer, a "middleware" sitting between processing and communication hardware, and IoT applications, providing a rich set of functions needed by many IoT applications. It solves many common problems found in the world of M2M and brings numerous benefits. oneM2M supports among others:
oneM2M’s Service Layer is typically implemented as a software layer and sits between IoT applications and processing or communication hardware and operating system elements that provide data storage, processing and transport, normally riding on top of IP. However, Non-IP transports are also supported via interworking proxies. The oneM2M Service Layer provides commonly needed functions for IoT applications across different industry segments.
Figure: IoT Service Layer
The IoT Service Layer is like an Operating System (OS) for the Internet of Things, sitting on field devices/sensors, gateways and in servers, and providing for Common Service Functions:
For example, the following “vertical” domains are isolated silos which makes it difficult to exchange data between each other. Using a “horizontal” architecture allows the provision of a seamless interaction between applications and devices, even of different manufacturers. In the below use case, a security application detects that when no personnel is in the building, it shall switch off the light and stops the air conditioning unit.
Figure: Interconnected M2M Silos make a true IoT
Without oneM2M, the market remains highly fragmented with limited vendor-specific applications. As the same services are developed again and again, the industry focuses on reinventing the wheel instead of on service innovations. Each M2M silo contains its own technologies without interoperability.
Figure: IoT Protcol Options
With oneM2M, an end-to-end platform is implemented that offers a common service capabilities layer to an ecosystem of compatible M2M silos. Interoperability at the level of data and control exchanges are done via uniform APIs. This provides for seamless interaction between heterogeneous applications and devices. And, most importantly, oneM2M is a global ETSI standard – not a proprietary framework controlled by a single private company.
oneM2M solves numerous problems present in M2M, enabling for a true IoT to emerge:
There are numerous benefits in using oneM2M in your IoT deployment:
Easy interworking and integration with existing and evolving deployments paves the way to long term evolution and sustainable economy.
A Service Layer on top of the transport network supporting a choice of transport protocols and serializations of data/message.
Horizontal platform provides common service functions that enable multiple IoT domains.
Data sharing and semantic interoperability brings the real value.
Open standards to avoid lock-in to a platform or a cloud provider.
Several open source implementations available (for CSE or AE).
oneM2M is the international standard for IoT.
oneM2M defines a horizontal architecture providing common services functions that enable applications in multiple domains, using a common framework and uniform APIs.
Using these standardized APIs make it much simpler for M2M/IoT solution providers to cope with complex and heterogeneous connectivity choices by abstracting out the details of using underlying network technologies, underlying transport protocols and data serialization. This is all handled by the oneM2M Service Layer without a need for the programmer to become an expert in each of these layers. Therefore, the application developer can focus on the process/business logic of the use case to be implemented and does not need to worry about how exactly the underlying layers work. This is very much like writing a file to a file system without worrying how hard disks and their interfaces actually work.
The IoT Service Layer specified in oneM2M can be understood as a distributed operating system for IoT providing uniform APIs to IoT applications in a similar way as a mobile OS does for the smartphone ecosystem. oneM2M decouples device, cloud, and application using open interfaces. This ensures that cloud- and network-specific M2M services can transcend into an open IoT framework which is cloud and network agnostic.
Figure: oneM2M is Cloud Provider-independent
The oneM2M Layered Model comprises three layers:
The Application Entity is an element in the Application Layer that implements an M2M application service logic. Each application service logic can be resident in a number of M2M nodes and/or more than once on a single M2M node. Each execution instance of an application service logic is termed an "Application Entity" (AE) and is identified with a unique AE-ID. AEs are typically part of oneM2M Nodes. Examples of the AEs include an instance of a fleet tracking application, a remote blood sugar measuring application, a power metering application, or a pump controlling application.
Figure: oneM2M Layered Model
A Common Service Entity represents an instantiation of a set of "common service functions" of the oneM2M Service Layer. A CSE is actually the entity that contains the collection of oneM2M-specified common service functions that AEs are able to use. Such service functions are exposed to other entities through the Mca (exposure to AEs) and Mcc (exposure to other CSEs) reference points. Reference point Mcn is used for accessing services provided by the underlying Network Service Entities such as waking up a sleeping device. Each CSE is identified with a unique CSE-ID. CSEs are typically part of oneM2M Nodes. Examples of service functions offered by the CSE include: data storage & sharing with access control and authorization, event detection and notification, group communication, scheduling of data exchanges, device management, and location services.
A Network Services Entity provides services from the underlying network to the CSEs. Examples of such services include location services, device triggering, certain sleep modes like PSM in 3GPPTM based networks or long sleep cycles.
The oneM2M functional architecture defines the following reference points:
Additional reference points are defined in oneM2M for specific purposes such as enrolment functions, etc. These are not detailed in this overview.
Figure: oneM2M Reference Points
oneM2M has defined a set of "Nodes" that are logical entities identifiable in the oneM2M System. oneM2M Nodes typically contain CSEs and/or AEs. For the definition of Node types, oneM2M distinguishes between Nodes in the “Field Domain” – i.e. the domain in which sensors / actors / aggregators / gateways are deployed – and the “Infrastructure Domain” – i.e. the domain in which servers and applications on larger computers reside.
Nodes can be of the following types:
Figure: oneM2M Node Topology
As a horizontal architecture providing a common framework for IoT, oneM2M went through a large number of IoT use cases and identified a set of common requirements which resulted in the design of this set of tools termed Common Service Functions. Think of these functions as a large toolbox with special tools to solve a number of IoT problems across many different domains. Very much like a screw driver can be used to fasten screws in a car as well as in a plane, the oneM2M Common Service Functions (CSFs) are applicable to different IoT use cases. Furthermore, oneM2M has standardized how these functions are being executed, i.e. is has defined uniform APIs to access these functions.
Figure: Common Service Functions
The services above reside within a CSE and are referred to as CSFs. They provide services to the AEs via the Mca reference point and to other CSEs via the Mcc reference point.
All these services are not specific to any IoT domain in particular. It enables each domain to build on the top of this service layer and really focus on its specific industrial needs. This is similar to functions of a generic operating system (OS) exposed to applications running on that OS. For instance, many applications read and write to files. File I/O is typically provided by the OS. oneM2M’s Service Layer provides similar functions in a generic way to many different IoT applications.
Representational State Transfer is a software architectural style that defines a set of constraints to be used for creating web services.
RESTful services allow the requesting systems to access and manipulate textual representations of resources by using a uniform and predefined set of stateless operations. A stateless protocol operation does not require the server to retain session information or status about each communicating partner for the duration of multiple requests.
REST is not a protocol. It is about manipulating resources, uniquely identified by URIs. A resource is stateful and contains a link pointing to another resource. All the actions on resources are done through a Uniform Interface. As REST is an architecture style, it can be mapped to multiple protocols such as HTTP, CoAP, etc.
There are six guiding constraints that define a RESTful system. These constraints restrict the ways in which the server can process and respond to client requests:
Client-server: separation of concerns is the principle behind the client-server constraints.
oneM2M REST APIs are used to manipulate data generated by the Application Entity (AE) to the oneM2M Service platform (CSE) as well as data retrieve services.
oneM2M REST APIs are used by CSEs and AEs to communicate with one another. The communication can be originated from an AE or CSE depending on the operation. Communication is done via the exchange of oneM2M primitives across the oneM2M defined reference points (Mca/Mcc/Mcc’).
The APIs are developed for handling CRUD+N (Create, Retrieve, Update, Delete and Notification) operations for oneM2M resources specified in oneM2M standards. Each oneM2M API includes the following components:
Primitives are used to perform CRUD+N operations on resources hosted by CSEs or to send notifications to AEs. Each CRUD+N operation is comprised of a pair of Request and Response primitives. Access and manipulation of the resources is subject to access control privileges.
Primitives are service layer messages transmitted over the Mca/Mcc/Mcc’ reference points. Originators send requests to Receivers via primitives. Originator and Receiver can be an AE or a CSE. Each CRUD+N operation consists of one request and one response primitive.
Figure: General Primitives Flow
Primitives are bound to underlying transport layer protocols such as HTTP, CoAP, MQTT or WebSocket. Primitives are generic with respect to underlying network transport protocols. Each primitive is also bound to zero or more messages in the Transport Layer.
Figure: oneM2M Communications
A primitive consists of two parts; control and content:
Figure: oneM2M Primitive
Figure: Example of Control Part bound to HTTP
Figure: Example of <container> Resource Representation (JSON)
Figure: Example of <container> Resource Representation (XML)
All entities in the oneM2M system, such as AEs, CSEs, application data representing sensors, commands, etc., are represented as resources in the CSE. Each resource has its own specific type with a defined set of mandatory and optional attributes, as well as child resources. Each resource is addressable and can be the target of CRUD operations specified in oneM2M primitives.
Figure: oneM2M Resource Template
The root of the oneM2M resource structure is <CSEBase>, which is assigned an absolute address. All other child resources are addressed relative to <CSEBase>. Dpending on the type of child resource, it can be instantiated 0...n times.
Figure: <CSEBase> Resource Structure
Each resource contains attributes that store information pertaining to the resource itself. The attributes are :
Figure: oneM2M Attributes
oneM2M defines XML, JSON, and CBOR schemas which define the attributes of each resource type. These schemas bind oneM2M attributes to well-known data types defined by XML schema definitions (e.g. xs:string, xs:anyURI, etc.). Schemas also bind oneM2M attributes to oneM2M-defined data types (e.g. m2m:id, m2m:stringList, etc.).
Figure: Example oneM2M Schema
The oneM2M standard defines several procedures and operations:
With the IoT Solution Optimizer, you can model each of the operations listed above while building your "virtual twin" IoT device.
Accessing resources on a local CSE is one of the supported oneM2M procedures.
Figure: Access Resources in Local CSE
Accessing resources on a remote CSE is one of the supported oneM2M procedures.
Figure: Access Resources in Remote CSE
CREATE is one of the defined oneM2M operations. The following document details the contents of CREATE Requests and CREATE Responses: oneM2M CREATE Operation.
Figure: CREATE Operation
UPDATE is one of the defined oneM2M operations. The following document details the contents of UPDATE Requests and UPDATE Responses: oneM2M UPDATE Operation.
Figure: UPDATE Operation
RETRIEVE is one of the defined oneM2M operations. The following document details the contents of RETRIEVE Requests and RETRIEVE Responses: oneM2M RETRIEVE Operation.
Figure: RETRIEVE Operation
NOTIFY is one of the defined oneM2M operations. The following document details the contents of NOTIFY Requests and NOTIFY Responses: oneM2M NOTIFY Operation.
Figure: NOTIFY Operation
DELETE is one of the defined oneM2M operations. The following document details the contents of DELETE Requests and DELETE Responses: oneM2M DELETE Operation.
Figure: DELETE Operation
The container for data instances is represented by the <container> resource. It is a data storage used to share information with other entities and track data. Two possibilities exist:
Figure: Example Resource Tree with Containers
Access Control Policies (ACPs) are used by the CSE to control access to the resources. The resources are always linked to Access Control Policies. Furthermore, these ACPs are shared between several resources. Finally, Subscription and Notification, as well as resource Discovery capabilities are required to share information.
Access Control Policies contain the rules (Privileges) defining:
ACPs are represented by <accessControlPolicy> resources. They are comprised of attribute privileges and selfPrivileges representing a set of access control rules for entities. Common attribute accessControlPolicyIDs link resources that are not <accessControlPolicy> resources to <accessControlPolicy> resources:
Figure: <accessControlPolicy> Resource Content
Figure: <accessControlPolicy> Example
Whereby, the listed attribute are:
Under the RESTful architecture, resource Discovery can be accomplished using RETRIEVE operation by an Originator. The use of the "filterCriteria" parameter allows limiting the scope of the results. Type, Labels, Content Size, etc., can be configured in the parameter.
Figures: Discovery Example
Events generated by resources can be received using the <subscription> resource. The <subscription> resource contains subscription information for its "subscribed-to" resource and is a child resource of the "subscribed-to" resource. The originator (resource subscriber) has RETRIEVE privileges to the "subscribed-to" resource in order to create the <subscription> resource.
Notification policies specified in the attributes can be applied to the <subscription>. These specify which, when, and how notifications are sent. For example, "batchNotify" receives batches of notification rather than one message at a time.
Figure: Example of Subscription and Notification
There is a growing set of open source libraries available online to help developers build powerful, oneM2M-based IoT solutions. Below are a few examples:
A collection of operating system and software projects using oneM2M can also be found here:
Please not that the ETSI oneM2M website will soon publish online content where hand-on information, including runtime code will be exposed for developers and makers of IoT devices. Preliminary information can be found at the following pages, managed by the contributing author at oneM2M:
The Global Certification Forum (GCF) is a global, non-profit organization that promotes mobile and IoT device certification programs for conformity to agreed interoperability standards. Shaping the industry since 1999 with mobile technology at its core, the GCF today has well over 300 members, including major Mobile Network Operators and MVNOs, device and IoT manufacturers, as well as companies in the testing industry. Together, they collaboratively in association with key partners to ensure that GCF certification programs fit the industry's needs today and tomorrow.
With certification programs continually evolving - recent additions include 5G, oneM2M, automotive C-V2X, RSP and mission critical services MCPTT, GCF provides the confidence in connectivity wherever you are. Products incorporating cellular mobile & IoT connectivity can be certified, such as:
The GCF scheme evolves in sync with developments in mobile technologies and the changing needs of the industry. GCF is a Market Representation Partner of 3GPP and liaises with standards and industry associations to support the successful development and deployment of 5G. It is the only wireless product certification scheme covering all these technologies:
M2M is a fast-moving and dynamic environment where multinational customers require easy-to deploy, international solutions, with a high quality of service and consistent customer experience across networks. In such a fragmented and complex business ecosystem, alliances and partnerships are vital to develop the M2M market and seize growth opportunities. The Global M2M Association (GMA) is an association of leading mobile operators with world-class networks, including Bell, Deutsche Telekom, Orange, Softbank, Swisscom, Telia Company, and TIM. Its mission is to deploy and manage enhanced and seamless M2M services worldwide. GMA members have proven experience and know-how in supporting business-critical M2M services and collectively connect tens of millions of M2M devices. As established mobile operators with a long history in M2M, they offer outstanding levels of support and customer care, and develop global solutions that meet the demands of emerging M2M applications. By joining GMA, operators are able to respond to global business requirements, fostering innovation by co-building M2M solutions and building a thriving M2M ecosystem with leading partners. They can leverage the GMA footprint of enhanced M2M connectivity services throughout 42 countries in Europe and in key markets in North America, South America and Asia, to efficiently deploy M2M services.
All GMA members are represented in all committees and work streams. A Steering Committee defines a shared vision, and mission, in order to reach the goals and objectives of the GMA. In parallel, the Program Management Office translates strategic directives into operational objectives by coordinating all projects and work streams.
There are currently four work streams running in GMA:
For more information regarding the benefits of GMA Membership, download an overview about us, or visit our website: http://globalm2massociation.com.
The GMA Certification Program ensures optimized interoperability between hardware and networks, leading to a far quicker and greatly improved integration of your M2M devices. All of our approved modules are certified to work across the GMA footprint, so that enterprises can be assured their devices will work seamlessly although roaming in different GMA countries. Key benefits of a GMA certification include an accelerated time-to-market, reduced business risk, optimized inventory, and an improved experience for end-users. The following modules are GMA-certified:
The GSM Association (GSMA) represents the interests of mobile network operators worldwide, uniting more than 750 operators with almost 400 companies in the broader mobile ecosystem, including handset and device makers, software companies, equipment providers and internet companies, as well as organizations in adjacent industry sectors. The GSMA also produces the industry-leading MWC events held annually in Barcelona, Los Angeles and Shanghai, as well as the Mobile 360 Series of regional conferences. GSMA's unrivalled global services encompass improved message delivery for ported fixed and mobile numbers, enhanced network services through unique device analytics, device crime reduction through data sharing, and an intelligence unit which houses extensive industry statistics and forecasts.
The GSMA drives three key industry programs - for Future Networks, Identity, and IoT. The Internet of Things program is an initiative to help operators add value and accelerate the delivery of new connected devices and services in the IoT. This is to be achieved by industry collaboration, appropriate regulation, optimizing networks as well as developing key enablers to support the growth of the IoT in the longer term. GSMA's vision is to enable the IoT, a world in which consumers and businesses enjoy rich new services, connected by an intelligent and secure mobile network.
Advocacy initiatives are also part of GSMA's mission, including:
GSMA members are at the center of the discussions, decisions, and initiatives that shape the future of mobile communications and expand opportunities for the whole industry. Membership in the GSMA keeps your business in touch, forward-thinking and competitive.
For more information, please visit the GSMA corporate website at https://www.gsma.com, or follow the GSMA on Twitter: @GSMA.
PTCRB has been the certification forum for select North American mobile network operators since 1997. It is a pseudo-acronym, no longer standing for its original meaning "Personal Communication Systems (PCS) Type Certification Review Board". The PTCRB organization offers its members a certification program for GERAN, UTRAN, and E-UTRAN device certifications, including definition and publication of all related test specifications and methods. PTCRB's certification program covers devices operating in the following technologies and bands:
PTCRB has no relevance outside of North America, e.g. in fast-growing European and Asian IoT markets.
PTCRB certification is based on standards published by 3GPPTM, Open Mobile Alliance (OMA), and other standards-developing organizations (SDOs). In numerous cases, PTCRB certification accommodates North American standards and requirements of the United States Federal Communications Commission (FCC), as well as the Canadian Innovation, Science and Economic Development (ISED). By obtaining "PTCRB Certification" on an IoT device, compliance is ensured with cellular network standards within North American mobile operator networks. Accordingly, operators that require PTCRB certification may elect to block any devices from their network that are not PTCRB-certified. CTIA – The Wireless Association is the administrator of the PTCRB Certification process and is responsible to administer PTCRB-issued IMEIs. Additionally, a community of test laboratory organizations working in the field of PTCRB-associated technologies form the PTCRB Validation Group (PVG). The PVG group holds regular meetings to discuss technical issues and resolve problems jointly. Full and Observer membership categories in the PVG reflect the status and scopes of its member organizations. Mobile Network Operators typically require a PTCRB certification as an lab-entry criteria before initiating own operator certification activities. PTCRB Certification is therefore not sufficient for a device to be allowed to be placed on these operators' networks.
For more information on the PTCRB certification process and requirements, please visit their website: https://www.ptcrb.com/
The Bridge Alliance (originally the Bridge Mobile Alliance) is a business alliance of 34 major mobile network operators in Asia, Australia, Africa, and the Middle East. The alliance provides for seamless service connectivity and a unified experience for its members' customers. This includes a suite of integrated value-added, managed services for all subscribers roaming across the alliance's footprint. These allow enterprises to procure, manage, operate, and optimize mobile services with simplicity and transparency.
The Bridge Alliance extends in collaboration to other areas of the world by forming partnerships with other alliances, such as the Global M2M Association (GMA) in Europe, Japan, USA, and Canada. These strategic partners extend the Bridge Alliance's coverage.
For more information, please visit the Bridge Alliance's website: https://www.bridgealliance.com/