Guide to Wireless Connectivity Options for the Internet of Things (IoT)

In the quest to connect and add business intelligence to a product, one can quickly become overwhelmed with all the connectivity choices. While many technologies play a role in the IoT ecosystem (e.g. components, infrastructure, applications, services, and analytics), this article will summarize some of the most relevant wireless technologies and give food for thought on when to consider each.

Before diving into attributes of specific wireless technologies, one needs to step back and consider the application from a business and technical perspective. How is the product implemented currently? What improvements are sought? What is the competition doing? Can further efficiencies be obtained?

BUSINESS REQUIREMENTS

The business requirements of the product/service need to be vetted early in the development cycle and certainly well before hardware is designed. If there is a limited niche market or the period to achieve the desired return on investment (ROI) is too long, no matter how clever the product idea, sound financial success may not be achievable.

Here are some points to consider prior to an IoT development kickoff:

• What market segments will the product be sold to?

• What level of market penetration needs to be achieved to reach the desired ROI?

• Does the launch date need to occur within a certain window (e.g. season products)?

• What is the business model?

o Hardware Only (up front, onetime cost for purchase of hardware/service)
o Subscription Based (hardware provided free with a reoccurring subscription fee) o Mix of Hardware + Subscription (hardware provided at cost or reduced price in addition to a reoccurring subscription fee)

• Demographics of target market?

• Competitive landscape? 

APPLICATION REQUIREMENTS

From a technical perspective, parameters that can influence connectivity choices for a particular application are:

• Size: How much space can the wireless solution occupy?

• Host Processor Requirements: Can an application run on the wireless device itself? If a host processor is required, are drivers readily available?

• Power: Is minimizing power consumption an important factor? If so, does the solution support multiple sleep mode options? What is the power consumption when associated with a wireless network – ready to receive data but idling (important for cloud connected battery powered devices)?

• Data bandwidth / throughput: What are the data rates needed to support the application?

• Distance: Would the application be positively/negatively affected by a wireless signal transmission limit?

• Data Security: Must the module itself provide full end-to-end encryption or is the innate wireless security sufficient to fulfill application requirements?

• Quality of Service (QoS) – Does the application include any latency sensitive data exchanges that would benefit from prioritized media access?

• Infrastructure: Is it known that a wireless network access point or network is readily available?

• Regulatory Certification: Is PTCRB, FCC, IC, CE, or industry dependent certifications required?

• Industry Standards: Is conformation required for interoperability with like products?

  DEVELOPMENT EFFORT/TIME/COST

  While a company may have appropriate engineering expertise in house to develop their current products, they may not have the skill set to implement a solution integrating one or several radio technologies. In some cases a make verses buy trade off analysis will determine that a higher cost more fully integrated subsystem such as a module should be acquired – especially if time to market is a critical factor.

  IMPLEMENTATION CONSIDERATIONS

  The beauty of many IoT implementations is that an existing product can be reworked to add wireless connectivity. The obvious benefit is that relatively little investment is required, yet often results in what seems to the end customer to be a completely new/current product with innovative features and benefits. The challenge of working with an existing product however is one must work within confines of an existing enclosure and other factors such as power supply. Following are some of the major areas to consider before selecting a specific wireless technology.

  TECHNICAL

  ELECTROMECHANICAL INTERNAL/EXTERNAL

  A key decision is whether the radio solution will be embedded in the product or connected through an external interface. An external interface provides a greater level of decoupling between the wireless subsystem and the device. This can have a favorable impact on EMC, regulatory approvals, RF performance and future migration path. Additionally this implementation choice allows for legacy field deployed devices to get a field upgrade, allowing for additional hardware sales as well as enabling device connectivity and business intelligence services. An embedded solution has the advantages of size, power, cost and permits a tighter coupling between the wireless subsystem and the host application.

  PHYSICAL INTERFACE

  Some of the most commonly supported data interfaces for wireless modules are: SDIO, SPI, UART, USB and mini-PCI-e.

  SIZE

  The circuitry needed to implement wireless connectivity is available in a wide range of form factors – from tiny System-On-Chip (SoC) to Land-Grid-Array (LGA) packages. There are a number of packaging levels that are supported by multiple vendors to address various end device requirements. Often suppliers of module solutions provide footprint compatible devices, allowing easy migration from device to device with varying features and performance options.

  POWER BUDGET

  While IoT products are often thought of being battery powered, many are wall powered as well. For battery powered applications the wireless solution can represent a significant percentage of the overall power consumption of a device. The energy used by the wireless subsystem is typically spec’d according the power used in each of the operating modes: transmit, receive, standby. 

  The power used by the host processor to manage the wireless subsystem should be accounted for. The total power used depends on the connectivity model and data rates required by the end application. Care should be taken that the power subsystem is able to deliver the required peak currents during transmit.

  Standby operation should be considered. Does the wireless device need to receive data from the network? If so, does it have to be immediate (for example in a control application) or can an acceptable wake-up polling interval be determined (for example in a sensing application)?

  Many IoT applications have the luxury of lengthy standby periods, where a pre-determined event occurring (such as sensor data crossing a threshold) wakes the wireless device for transmit. It is therefore critical to consider how quickly the wireless subsystem can wake up and re-connect to the network. This is very important in ultra-low power mesh networks where batteries are expected to last from 10 years to the lifetime of the product. 

  ANTENNA

  The antenna is a critical element to the performance of a wireless subsystem. The antenna’s characteristics and radiated efficiency will greatly influence the RF link budget of the overall solution. For this reason, the regulatory agencies that approve module solutions provide specific dependencies on the type of antenna that can be used. The most commonly used antennas are monopoles, dipoles, and chip antennas. In some designs the antenna is implemented using traces on the PCB. While external antennas are generally more effective, they can introduce challenges.

  Another decision to be made is whether or not to implement antenna diversity (so that multiple wireless technologies can be supported).

  Wireless products must conform to international standards for both unintentional and intentional radiation. It is highly recommended to evaluate your product design and develop an antenna strategy early in the design cycle to avoid difficulties with product approvals later on. It is often prudent to get a third party lab (e.g. Satimo) involved to impartially test antenna performance. Such third parties are well equipped with expensive lab equipment to evaluate performance within a close replication of the end-use environment. One of the most tricky use cases to replicate is a body worn product.

  EMC

  The performance of the radios in a product can be degraded by noise that is generated by nearby circuitry. The lower the level of integration the more attention will be needed to utilize good RF practices for trace routes, bypass and shielding.

  COEXISTENCE

  The performance of the radios in a product can be degraded by other RF circuitry in close proximity. Especially when combining several RF standards into the same product (such as Bluetooth and Wi-Fi). Special attention has to be made to ensure the technology provides mechanisms to handle interference. Often a pre-approved modular solution is the easiest path. 

  HOST ENVIRONMENT

  Selection of a wireless solution will further be influenced by properties of the (potentially) existing host environment.

  A wireless solution usually requires firmware (FW) which can be stored internally in Read Only Memory (ROM), flash, or Random Access Memory (RAM). The FW itself is typically closed source and not available for modification. Most wireless suppliers will offer drivers for multiple Operating System (OS) options.

  There may be adjustments needed to the vendor’s board support package (BSP) for a particular host processor. Alternatively, a module can be selected that requires no external host MCU (host- independent), therefore allowing one to avoid driver compliance issues. 

  APPLICATION REQUIREMENTS

  The specific requirements of the end application will dictate the features and capabilities that should be supported by the wireless solution. Next to power consumption, throughput and range are top priority requirements to consider. Unlike wired networking, the transmission medium for some wireless technologies, such as 802.11 Wi-Fi, is a shared medium. Concurrent use of the medium is only possible when no more than one device is using the same channel (frequency), in the same location at the same time. For example, Wi-Fi media access protocols rely on Carrier Sense Multiple Access / Collision Avoidance to take turns communicating on the channel in use in a particular cell. This is a contention based approach that works well in most circumstances but can become inefficient when there is high device density. In order to avoid the congestion that often exists in the 2.4GHz band (caused by 802.11 b/g/n, cellular, BT, ANT, ZigBee, RF4CE, and Wireless HART), devices transmitting mission critical data should be deployed in other frequency bands such as 5 GHz (e.g. 802.11a/h) or sub-GHz (e.g. Z-wave). 

  COSTS

  Just like most things in life, you get what you pay for (sorry still applies in the wireless realm). In addition to the hardware cost, there are development and potentially service costs as well. 

  PRODUCT COST

  Making a wireless solution selection purely based on production cost may not be the most prudent approach. Tradeoffs need to be carefully considered. If time to market or engineering resources is a

  concern, a module solution may be the best approach. The alternative would be procuring chip level components and investing heavily in development and test.

  As an example, a 802.11 Wi-Fi module could potentially cost $15, while an individual 802.11 radio chip may only cost $4, however, the module solution includes substantial value that is not easy to come by (a trusted software stack that has been honed and developed over months or years over multiple end applications and customers; pre-certified design; technical support; starter application code; and development tools). 

  DEVELOPMENT COST

  The development costs for implementing an embedded wireless solution fall primarily into three categories:

  • Engineering effort and expense to integrate wireless functionality into a product

  • Cost for authorized test houses to produce test reports for world-wide regulatory/industry certifications

  • Engineering effort and expense to build the associated back-end systems, applications, and device management

    The Level of Integration will significantly impact the development costs associated with both categories. Often modular solutions with proven solution ecosystems are selected to save costs. 

  ONGOING (SUBSCRIPTION) COST

  Of the various wireless technologies, cellular requires an ongoing monthly subscription cost. If such an ongoing expense is hard to bear due to the end customer business model, other technologies should be considered.

  • Another potentially ongoing cost is a cloud solution. Some PaaS/SaaS cloud solution providers charge on a periodic basis (such as monthly) while others charge on a per transaction basis.

• WIRELESS 101

  There are many wireless connectivity options out there and each can potentially be the ideal solution... It just depends on the system’s true requirements.

  • The prevalent technologies will now be summarized and typical use cases provided. The shorter range wireless technologies will be covered first, ending with ubiquitous Wi-Fi and cellular. 

  RFID

  Radio-frequency identification (RFID) uses electromagnetic fields to transfer data for the purpose of identification and tracking tags attached to an object. Some (passive) tags can only be read at short ranges (a few meters) via electromagnetic induction, while some (active) tags including a battery can be read up to hundreds of meters away. A passive tag is cheaper and smaller since no battery is required. 

  A RFID system requires a reader in addition to the tags. The reader transmits an encoded radio signal to interrogate the tag. The tag responds with its identification and potentially other info such as a stock skew. Data rate is not critical since such a minimal amount of data is being transmitted, so 400kbps is quite adequate. 

  A positive attribute of RFID is that its frequency is out of the congested 2.4GHz space that many wireless technology options inhabit. RFID is typically in one of the following bands: 120-150kHz (LF), 13.56MHz (HF), 433MHz (UHF), or 3.1-10GHz (microwave).

  One interesting use case for RFID is tracking equipment usage by individuals wearing a RFID tag (for example use of a hand washing station by staff at a hospital). 

  NFC

  Near Field Communication (NFC) is a short-range wireless technology that enables two-way communication between devices over a distance of less than 10 cm. The NFC standard is defined in ISO/IEC 18092 and operates at 13.56MHz.

  NFC has a fairly low data rate of 400kbps, but offers an extremely simple set up.

  One common application for NFC is in contactless payment systems, allowing mobile payment to replace credit card transactions. NFC is also becoming more prevalent in social networking, by providing a means to share contact info or pictures between proximal devices. 

  Per Apple’s recent announcement of the iPhone 6 and Apple Watch including NFC technology, NFC may begin to gain more rapid acceptance. However, Apple NFC currently only supports ApplePay, not interfacing with speakers or other NFC enabled accessories.

  As a side note, Apple intends to bolster the sometimes questioned security of NFC by requiring an extra thumbprint scan authentication step and creation of a temporary Apple Pay cryptogram. The 16-digit token will subsequently be sent to a retailer’s NFC card reader for payment processing. The token will be good for only a certain period of time and location thus making theft for future use irrelevant. 

  BLUETOOTH & BLE

  Classic Bluetooth (BT) and Bluetooth Low Energy (BLE) could almost be listed in separate sections because they were developed for completely different uses and in fact are not even compatible with each other.

  Bluetooth (BT) also exchanges data over a relatively short distance of up to 100 meters. Bluetooth operates in the range of 2400-2483.5MHz. Depending on the version of Bluetooth, the data rate is typically up to 3Mbps. To use (Classic) Bluetooth, one of 30+ profiles (based on application) needs to be followed. Examples include:

  • -  Advanced Audio Distribution Profile (A2DP): defines how audio can be streamed between devices over a BT connection

  • -  Basic Imaging Profile (BIP): designed for sending images between devices

  • -  Hands-Free Profile (HFP): allows car hands-free kits to communicate with mobile phones in the vehicle

  • -  Headset Profile (HSP): support for BT headsets to be used with mobile phones

    Bluetooth Low Energy (BLE) is also known as Bluetooth v4.0 and was developed for low power, low latency, low throughput (1Mbps) applications. The BLE range of 50 meters is shorter than that of BT. 

  BLE is a completely different protocol than BT and is not compatible with legacy Bluetooth protocols. It uses a different channel scheme (40 2MHz channels verses Classic BT’s 79 1MHz channels). 

  BLE is a great choice for health and fitness monitoring such as a heart monitor.

  Note that for a device to marketable as a Bluetooth device, the product must be qualified to standards defined by the Bluetooth Special Interests Group (SIG). The SIG owns the Bluetooth trademark, which can be licensed to companies that are incorporating the technology into a product. To become a licensee, a company must become a member and have the product certified.

  One additionally has to keep in mind which smart-phone will be in the mix. For example, Apple iOS devices like the iPhone can connect freely with Bluetooth hands-free and headset accessories, however, a BT data connection requires an encrypted connection (and an Apple authentication chip) – basically a unique discovery/paring sequence and negotiation with the Apple authentication co- processor. The Apple authentication chip is not required for BLE communication.

  Not to worry, there are many third parties that can assist with all that is required. Both semiconductor and OEM companies alike often rely on Bluetooth stack developers such as Stonestreet One. Module solutions are also readily available. 

  ANT / ANT+

  The ANT protocol also operates in the 2.4GHz band and was developed for ultra-low power, low bit rate (1Mbps) periodic transfer of small amounts of data between several to many interconnected sensor nodes (50m range, like BLE). Any node can transmit or receive, so the channels are bi- directional. Like BLE, ANT can support point-to-point (P2P) and star topologies, but additionally can handle a tree or mesh configuration.

  ANT excels in interference immunity (in the crowded 2.4GHz space) since it uses an adaptive isochronous network technology to ensure coexistence with other ANT devices. The short message transmissions allow a single channel to be divided into hundreds of time slots. Thus the technology is ideal for implementing personal-area networks in fitness/health monitoring.

  ANT+ can be added to the base ANT protocol and allows for networking of nearby ANT+ devices. For example, ANT+ enabled fitness monitoring devices (e.g. pedometers, cadence meter, heart rate monitors) can work together to assemble and track performance metrics. 

  ZIGBEE

  ZigBee is based on the IEEE 802.15.4 standard and like many options already covered, operates in the 2.4GHz band. While the data rate is fairly low at 250kbps, its low power and variety of topologies makes it a popular choice for many ultra-low power sensor based industrial applications.

  Even though the radio range is 10-100m line-of-sight, the ability to be configured as star, cluster tree, or mesh network allows any node to communicate with any other and an almost unlimited network reach. As such, ZigBee has been accepted as the de facto standard for industrial control and building automation. An example of an ideal use case is industrial HVAC where sensor nodes (e.g. monitoring environment conditions or vent position) are expected to run on a battery for 10+ years. The data from a distant sensor node can be sent to a remote building controller via hops across an extensive mesh network. 

  WI-FI

  Wi-Fi, aka 802.11, operates at either 2.4GHz or 5GHz. Wi-Fi is an ideal choice for many applications since a network is generally available – therefore saving the cost of an additional gateway to exchange data over the internet.

  There is a wide array of options depending upon what sub-standard is selected (e.g. up to 150Mbps data rate and 250m range with 802.11n).

  Wi-Fi is often pegged as a power hog; however throughput can be traded off to achieve a relatively low power option. For example some Wi-Fi modules are able to achieve < 1mA average power consumption if the data throughput is reduced to something like 2Mbps. Still not as low power as ANT+, BLE, or ZigBee, however, offers a relatively higher data rate.

  An ideal low power use case for Wi-Fi is a cloud connected weight scale (where batteries could last up to 4 years if weight is measured approximately 10 times per day).

  An ideal higher throughput use case is a portable security camera. 

  CELLULAR

  Cellular (700MHz-2.7GHz) is saved for last because it takes advantage of the most prevalently available network, minimizing deployment use case challenges. Cellular range is basically unlimited, depending on carrier network availability. Throughput is fairly high at 7.2Mbps (2.5-4G network).

  Vehicle tracking/monitoring is a great example of an ideal cellular use case. Of course cellular does come with a monthly price tag to consider.