Enabling the Internet of Wireless Things

Enabling the Internet of Wireless Things

Almost all electronic devices now have the ability to be part of a network, and beyond that a network of networks. This is the vision for the IoT, and wireless connectivity is making it a reality.

Control and automation are key features of the Internet of Things (IoT), features that are realized using sensors and actuators. While it’s likely that most large automation equipment will now (or soon) be connected to a local network, the IoT will mostly be made up from smaller devices located in relatively remote locations. These “endpoints,” as they’re now generally known, could be as simple as a temperature sensor or as complex as a weather station. As such, endpoints in the IoT could contain both sensors and actuators, along with power, processing, and connectivity.

Part of the value proposition of an IoT endpoint is that it will be easily deployed and maintained, meaning it should be a self-contained unit that can be commissioned remotely, operate for hundreds of hours without power failure, and form part of a largely self-healing network. These requirements point to a high level of integration supported by robust and industry-ratified standards.

Wireless SoCs for the IoT

The availability of single-chip solutions for wireless connectivity targeting IoT endpoints has been increasing for several years (see figure). Semiconductor manufacturers now offer a wide range of devices that conform to this basic design in variants that comply with the most commonly used wireless protocols, as defined by industry standards.

Generic RF SoC solution

This is a typical block diagram for a generic RF SoC solution.

Choosing the right wireless protocol and SoC for a given IoT application depends on many things, which are covered in this article. The most relevant are range, power, and the data rate. While the data rate is largely defined by the protocol, and wireless SoCs must be designed to meet the constraints set by the standards, SoC manufacturers still have significant control over these three main parameters and will trade one off against another to deliver standard parts that meet the “sweet spot” of the emerging market.

Wireless protocols fall within three general categories: personal area, local area, and wide area. The area, in this case, refers to the physical distance between at least two network nodes, which is necessary to form a network. Table 1 shows a comparison of the most popular wireless personal-area-network (PAN) protocols used in the IoT, in terms of data rate, range, and power.

Comparison of Wirless PAN Protocols

Range is important, because it not only defines the maximum physical distance between two endpoints, but depending on the protocol, it can correlate to the power needed to achieve that distance. The physical layer, or PHY, of the wireless SoC must be able to handle enough power to achieve the range defined in the standard, and the efficiency of that PHY will partly determine the overall power requirements of the SoC. This can have significant implications when designing the endpoint, as it may be necessary for the endpoint to operate for several years from a single primary cell, for example.

There’s also a physical limitation to how powerful the amplifier in the SoC can be, in terms of the process node used. Wireless SoCs are designed to deliver the best link budget for the available power—some of that will be determined by the receiver sensitivity, while another portion will be defined by how efficiently the RF part of the SoC has been designed and implemented. Mixing RF with sensitive digital and analog CMOS functionality has always been difficult and often leads to the tradeoffs mentioned earlier, such as reducing the total transmit power, sacrificing receiver sensitivity, or restricting the amount of transmissions per hour/day/week.

Network Topology vs. Range

While those wireless technologies classified as “personal area” have a range measured in tens of meters, their network topologies have evolved to address the limitations of a short range. Most all PANs now employ a mesh network topology, which allows endpoints to operate as waypoints for passing messages from one side of the network to another. In effect, this means that a PAN is no longer limited to the longest span between two endpoints or, therefore, its local proximity.

However, this also means that for a message to travel over tens of kilometers, there needs to be an endpoint every few meters and the message must make multiple hops. The power per bit per kilometer, therefore, should be evaluated, particularly if the network is intended to operate as a low-power wireless sensor network (WSN), which is becoming a typical use-case in the IoT.

On the other hand, wide-area networks, or WANs, are designed to cover large distances in a single hop. Instead of a mesh network, they more commonly use a star network topology. These are essentially direct links between an endpoint and a gateway (although some endpoints can also act as gateways). WANs designed for the IoT are now generally referred to as LPWANs, meaning low-power WANs, and they can cover tens of kilometers with a single connection. As such, they’re becoming popular for connecting large urban areas, such as smart cities.

The most prevalent LPWANs today include LoRa, Sigfox, Ingenu RPMA, and Weightless. Table 2 compares the key features of all four.

Comparison of Key Features of LWPANs in Use Today

Cellular networks now also support an LPWAN use-case, covered by Release 13 of the 3GPP specification. These include LTE Cat-M1 and NB-IoT (also known as Cat-M2). Unlike other LPWANs, the network is managed by the incumbent cellular network providers, and its use will be subject to fees. Fees may also apply to using other LPWANs, but the infrastructure can conceivably be proprietary and managed by the user, too.

Optimized for WSNs

Potential single-chip solutions for WSNs are now relatively commonplace. Most of the larger general semiconductor vendors, as well as some smaller specialists, offer highly integrated devices that combine RF transceivers with microcontrollers, power management, analog and digital peripherals, memory, and other interfaces. Developing an endpoint for WSNs based on almost any standard wireless PAN, LAN, or WAN can be achieved with a single device or a two-chip solution.

However, the fact that so many vendors are now offering very similar SoCs indicates that subtle differences exist between them; tradeoffs that each semiconductor vendor has deemed necessary for its own target application areas. One size does not fit all.

Also, some manufacturers may wish to implement multiple protocols; for example, combining a PAN with an LPWAN. This would allow the benefits of both network topologies to be exploited, such as high data rates for short-range communication coupled with low data rates for longer ranges. Every application is different, so it may not be possible to find the perfect SoC. For many reasons, choosing a custom solution may be the right option.

For instance, the SmartEdge Platform developed by ASIC & IP Division of Adesto Technologies brings together a library of proven IP covering RF, digital, analog, and power functions that can be optimized for a given application, covering all forms of wireless networking. The value of an ASIC solution can be measured in many ways, but it ultimately means the right solution for the job, with few or no compromises.

Conclusion

Of the billions of devices expected to form the IoT in the near future, many will be endpoints in wireless sensor networks. Using an SoC to develop an endpoint makes sense for many reasons, but finding the optimum solution isn’t necessarily easy.

Choosing a custom ASIC provides manufacturers with the option to optimize the solution based on their own requirements, giving them a competitive edge over those using standard parts.

Edel Griffith is Technical Marketing Manager in the ASIC & IP Division of Adesto Technologies.

SourceESB banner with caps

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish