Understanding the Internet of Things

Key Takeaways

• Describing the Internet of Things and its central components.

• A more detailed look into connection protocol.

• A look at some of the protocols playing a role in IoT - including HTTP.

Industry adoption of the Internet of Things is set to increase in the coming years

Interest in developing greater automation has been an important undercurrent of business following the computer revolution. As impressive as computing has been in improving the speed and accuracy of monotonous or otherwise highly technical tasks, the tendency of system design has been more predictive than truly reactive. Without constant system updates and communication, it is unlikely a computer network is able to accurately assess the changing conditions to maximize performance.

The Internet of Things (IoT) is turning this paradigm on its head, and its role in industry and consumer use is only set to increase in the coming years. IoT will touch all areas of design and manufacturing, but considering the wide amount of protocol involved in developing and running an IoT system, it’s important to discuss the overarching goals of a network.

Defining the Internet of Things

In any industry, automation holds the promise of realizing what would be formerly unattainable levels of efficiency. In terms of methodology, IoT looks to harness latent data streams and improve communication lines, especially between machines. Machine-machine communication is not a groundbreaking development on its own, but IoT attempts to make these communications more proactive. 

Differentiating IoT-based network solutions from standard computing hierarchies may appear difficult at first. While IoT aims to take advantage of new technological developments and improvements to existing practices, the system is a disruption of traditional dataflow architectures. Pre-IoT dataflows have used computers to act as the data hub and decision-maker simultaneously; IoT aims to break away from this format through decentralization. As components shrink in size and energy expenditure, it is more possible than ever to tie the polling of sensors to locally embedded processors. Systems can better react and anticipate performance needs by responding to, or at the very least analyzing, changes at a much more granular level.

While IoT has been defined somewhat broadly, take a moment to consider some of its defining characteristics:

• Sensors - There’s no way around it: sensing, whether internal or external, forms the core approach to evaluation and actionability for an IoT system. Tracking system parameters provides a baseline for operational efficiency and can be referenced against fluctuations to form a rapid equilibria reaction. In the long-term, these measurements can also act as a diagnostic tool to accurately predict wear and the need for maintenance.
• Communicability - Another central tenet of IoT is further furnishing intra- and inter-system discussion – this allows changes at one end of an integrated system to be accounted for and implemented without the need for downtime or operator adjustment. Importantly, it also provides the infrastructure for the wireless communication protocol, granting greater automatization and remote access points.
• Identifiers - Every item in the network meant to be accessed or addressed needs a unique code to differentiate it from others. This includes “passive” devices (these are not passive in the classic circuit sense, but rather as it relates to memory storage, communication formats, etc.) which can be read and have their data contents synchronized to a network for dissemination and action.

The Two-Part Process of Communication

To be sure, IoT will require a mix of current and new communication protocols. Communication generally falls into two complementary categories: telemetry and telecommand. 

Telemetry combines the basic elements of data recording – a sensor and transmitter – alongside display and control elements to form the backbone of the collection. 

Telecommand, meanwhile, is built around acting upon the sensor data collected in telemetry. While these two branches must successfully interact to produce meaningful performance from an IoT system, they have vastly different requirements to capitalize on the data successfully.

Telemetry requires a network design that is suited to fast transfer rates and low overhead on sending and receiving due to the large amount of data that needs to be transmitted. Due to its large-scale adoption well before the onset of IoT, SMS possesses the requisite characteristics and an advantage in infrastructure. Notably, smartphones represent an important interfacing method for users to exert control over IoT systems, and SMS represents a universal protocol for access. SMS also extends legacy protocols like Hayes for simple dial-up commands and is itself extended by GRPS for added messaging volume, a necessary feature considering the staggering amount of data generated in moments by IoT. 

However, SMS has some significant drawbacks, primarily its message delivery accuracy. SMS is denoted as a best-effort protocol, meaning the network offers no certification that a message sent will be received by the recipient. This failure rate occurs somewhere between 1~5% of the time; though some data loss may be acceptable in more informal applications, this rate coupled with the massive amount of data inherent to IoT is far from ideal. There are some additional security concerns as well, an issue already sensitive to the long-term development of IoT.

Telecommands are in general the less demanding of the two sides of the communication avenue due to the reduction in data packets sent, yet accuracy and speed still remain driving factors. The division of labor can be further described in terms of uplinking and downlinking. Uplinking, the telecommand half, data handling disseminates the information sent from the telemetry portion of the system. The reverse operation, downlinking, occurs during data collection, which collects the various data points and multiplexes these into transmission frames.

Telecommunications are central to the success of the IoT model

Is IoT Synonymous With HTTP?

Thus far, there’s been no discussion of the application of internet protocol (IP)  to IoT, which one might presume would fit like a hand and glove. Internet connectivity is abundant and TCP/IP allows for extreme flexibility in its deployment. Not only can networked devices communicate within the network and out-of-network via an internet connection, but data exchange can also be specified at either the host or process level. The encapsulation of TCP/IP from greatest to least specificity flows like this:

1. The application layer synchronizes communication between processes of the host and other hosts on the network.

2. The transport layer provides multiple functions, acting as constant-stream communication as opposed to sending/receiving requests, checking for acknowledgment of reception, and controlling rates of data transfer to avoid overwhelming nodes.

3. The internet layer uses IP addresses to send and receive packets to or from out-of-network hosts that are transferred to the transport layer or link level, depending on the origin.

4. The link layer defines the protocols only for the section of the network the host is connected to.

TCP/IP provides the framework for IoT communication, but there are a variety of standards that represent both current and future usage. Protocol usage reflects a mixture of a particular system’s attributes:

• HTTP - The posterchild for IoT, as it is the dominant protocol for the computer-centric internet. It performs well when publishing large data packets, much as most users are familiar with in its more well-known implementation. HTTP, however, is highly inefficient, both in power consumption and data overhead, which harms its viability for IoT on a per-message basis. Additional knocks against HTTP include:
  • ○ Request-response model is a poor fit for IoT, as it hinders the ability with which data can be transmitted. This also causes poor performance, as the telemetry and telecommand aspects of communication can only be performed one at a time, hindering the robustness of the system’s reaction speed to evolving datasets.
  • HTTP is a one-to-one connection; when sensors are pushing data, there may be a need to disseminate multiple data streams simultaneously. This cannot be achieved with HTTP.
  • ○ The synchronous request between the server and client requires additional handshakes before data can successfully transfer, further slowing down the transfer speed, as both ends of the connection need to pass through the necessary CPU cycles.
  • HTTP is built on TCP cycles, which means additional resources are required for every connection compared to a leaner protocol.
  • ○ IoT functions best as an event-driven system – when data value reaches, exceeds, or falls below a certain threshold, perform a certain action – but HTTP’s native request-response mechanism cannot function at the same speed. While HTTP can be utilized as an event-driven model, it performs much worse than a network protocol specially designed around this communication mode.
• Bluetooth - Bluetooth is low-energy, low-cost, and links wirelessly over a short physical distance. While the last point may sound detrimental, this enhances the security of the system. Bluetooth is an excellent low-overhead solution for data transfer associated with IoT.
• Near Field Communication - Similar to Bluetooth with its restriction on distance, NFC is highly efficient, albeit an overall slow method of data transfer. This makes the technology excellent for short-range communication for things like authenticators.
• RFID - RFID is a crucial element of the identification portion of IoT. The system is split into three aspects: the tags which serve as unique identifiers and data storage, the reader that powers and accesses data, and the software that acts as a go-between for the tag and reader. Tags can be denoted for a variety of uses, from read-only to full read/write, and the technology’s usage cuts across a wide swath of industries.
• Long Range Wide Area Network (LoRaWAN) - Almost exclusively used for low-power functionality on networks that have a large population of devices, this protocol links with networks to adjust power consumption based on ambient settings.
• Other - Common network protocols like Wi-Fi can be simulated using nodes in new topologies for better structuring of data hierarchies. This includes a mesh network, which distributes the connectivity of a router across multiple access points within the network. This increases network reliability by providing multiple permutations of routing from point to point in the case of connection loss. Overall performance also increases for network nodes that are proximally distant to the router point. Mesh networks have seen deployment in both industrial and home settings, with Zigbee a particularly popular choice for short-distance communication.

Linking data and network protocols to IoT

The Internet of Things will only grow with new system rollouts and further levels of integration. Designers need toolsets that are able to meet the rising demand for signal speed, low power consumption, and other constraints with comprehensive PCB Design and Analysis Software. For any board, OrCAD PCB Designer offers a robust system that offers easy and powerful solutions for layout.