How do consumer IoT devices typically enable Internet connection?

Question

As far as I know there are 2 general methods for enabling remote (Internet, not LAN) access to IoT devices:

1. Via a server that the device polls periodically (e.g. MQTT)
2. Direct remote access

I'm assuming the second method is not straight forward as typically consumer devices are sitting behind a home router.

My question is this: Roughly what percentage of currently sold IoT devices use which of the following methods to connect to them remotely:

1. Via a server (device polls the server)
2. Direct remote access that requires manually configuring a home router to enable port forwarding (or other way that exposes the device)
3. Direct remote access where the device automatically configures the router via UPnP or other protocol
4. Direct remote access using a device's static IPv6 address that does not require router setup
5. Other methods

My question is related to consumer IoT devices, such as light bulbs, light switches, locks, thermometers, etc. from trusted manufacturers that are sold today and are installed in homes.

Update:

Found this answer by @Aurora0001 to another answer on this site about hole punching to enable direct communication between 2 devices residing in different internal networks (e.g. behind a home router). This solution requires a server, but only for the initial handshake.

I guess that would add another option...

Answer 1

I think you'll find a fairly high percentage of "#5, Other", because the list is missing one of the most common consumer IoT architectures: indirect communications via an in-home gateway.

All the other methods you describe have drawbacks in the home: they're hard to configure, they're not secure, or they take a lot of expensive server resources. An in-home gateway avoids those problems for the individual devices, exposing only one device to the internet.

The typical gateway serves several purposes. First, it's a protocol bridge. Wireless devices use all kinds of open and proprietary communications protocols, including Z-Wave, Zigbee, dedicated 900 MHz RF, dedicated 433 MHz RF, infrared light, Bluetooth, BLE, ANT+, Crestron, etc. These solve all kinds of niche problems, like per-device cost, battery life, self-configuring mesh networks, rapid response times, insecure communications, simple configurations using minimal storage, etc. This way most consumer IoT devices aren't using IP packets, but instead deliver their data inside much smaller frames in order to preserve battery life. The gateway will convert the proprietary protocol into something more transportable and interoperable with an IP based network.

Also, the in-home gateway is a good place to store the rules of the system. If you're going to enable rules like "if you turn on the light at the top of the stairs, also turn on the entryway light, unless the kitchen light is on," you can place the rules in the light switches, a centralized web server, or the gateway. Putting the rules in each light switch makes for a brittle configuration that's hard to set up, change, or manage. Running the rules in a centralized server introduces latency because the message has to be translated to TCP, encrypted, sent across the internet, the action has to be received, decrypted, and translated back to Zigbee. The gateway enables the vendor to solve these problems by providing a single management point to back up and restore, and local processor to run the rules quickly.

Security is a big issue: IoT devices need to be cheap, and cheap processors don't have big CPUs and storage for secure encryption functions. Not to mention the desire to avoid the massive expense of developing securely encrypted protocols. So they implement very weak (cheap) security in the consumer devices, or no security at all. They make up for this by only communicating within a very limited range - they only have to reach the in-home gateway. This way, the gateway handles the local unsecured communications, and only one device needs the processing power and storage needed to communicate to the cloud over TLS.

Finally, the gateway can provide a convenient single point of human interface to the devices. Most gateways expose a web interface, allowing for GUI-based configuration. Imagine trying to Morse-code-configure a 12 character WiFi password into a device using only one button and one LED. Worse, imagine your company's phone support staff talking each customer through that process.

Unfortunately, this still does not answer your question directly. But I expect the gateway architecture to be the most common way consumer-oriented devices connect to the internet.

EDIT: In response to your comment about in-home gateways used for IoT devices, there are a few basic kinds: dedicated single purpose, dedicated multipurpose, and general purpose. In addition to the interfaces below, all of them have an Ethernet or WiFi interface to bridge messages to and from an IP network.

A dedicated single purpose gateway speaks only to a particular manufacturer's devices. The simplest examples might be a USB dongle that receives data from a single device, like a Fitbit dongle. Other examples include the Philips Hue Bridge (which communicates only with Philips Hue light bulbs); the Liftmaster MyQ Gateway (which communicates only with Liftmaster, Chamberlain, or Craftsman garage door openers); or the Harmony Hub (which communicates with Logitech Harmony remotes and blinks IR to various home theater components.)

An example of the dedicated multipurpose hub would be Samsung's SmartThings hub. SmartThings sells a wide variety of home automation devices, but they only speak the SmartThings protocol. The SmartThings hub can also communicate to many other device controllers via IP, and has native IFTTT integration.

The general purpose gateways may have some proprietary components, but often support multiple interfaces and can serve as a primary smart home interface. Examples include the Wink Hub (which communicates to Zigbee, Z-Wave, Lutron, and Kidde RF devices); Vera Edge (which communicates to Z-Wave and Insteon devices, and extends to communicate to external devices).

Finally there are also some very active open source efforts in the general purpose home automation domain, including Domoticz and OpenHAB. These are software programs that support communication to IoT devices through dedicated bridge devices (such as a Z-Wave USB dongle or a Zigbee radio), implement rules, and offer extensive integration capabilities such as IFTTT, MQTT, and others.

Answer 2

Virtually all consumer products which operate in this way will require an external server to mediate the sending of messages from an external device to a specific device in the home. Even in the most obvious case of exposing port 22 on your Raspberry Pi, you still (generally) require a dynamic DNS service.

1. Device initiates and maintains a persistent connection with the server. This requires no router configuration, provided the router provides https access to the web...

For all the other methods, the remote handset device needs to be able to find the in-home device. Peer to peer protocols will sometimes use port-forwarding since they have a desire to avoid a client-server architecture.

It is possible that a system will, in addition, open an incoming port using UPnP, but this shouldn't be necessary for IoT applications. This might apply to legacy gaming applications, but falls apart as soon as more than one node is present on one public IP.

Although IPv6 enables a pair of devices to be associated, many networks don't support IPv6 end to end today. A server is necessary regardless to provide for firmware updates (unless the device is obsolete before it's sold).