IoT – Gonzology

Today’s electrical infrastructure is brittle. Points of failure abound, a consequence of centralized generation mated with an antiquated and chronically underfunded network of sub-stations, transmission and distribution lines delivering electrons to market. Combine this brittleness with more frequent and severe weather events like the 2017 hurricane season and power outages will become more frequent and longer lasting. In fact, they already have. This comes as no surprise to anyone. Venture capital dollars are pouring into innovative startups tackling this problem from all sides while the brightest minds in energy host conferences to gain mind share on the right technical road maps and organizations like Rocky Mountain Institute wrestle with policy implications and gyrations. However, this will take time, a lot of time. What if long-term owners of critical infrastructure like cities, municipalities, departments of transportation, utility companies, Distribution System Operators (DSO), cellular carriers and the like want or need to improve the resiliency of their assets sooner?

Resiliency fulfills a “what if” scenario, like insurance does. What if a city’s electrical grid goes down for hours or days or longer like Puerto Rico? Traffic lights stop working, making getting around challenging and dangerous. Roadway, pathway and parking lot lights stop working affecting the safety and security of neighborhoods at night. Cellular towers stop working causing communications to grind to a halt. Fuel-powered generators are a common fallback, but reciprocating engines do not do well sitting unused for long periods of time, so failure rates are high and refueling becomes an issue for longer outages. Additionally, ownership of ubiquitous generators is a costly endeavor, both upfront as well as the maintenance costs required to ensure infrequent yet infallible operations over time.

Resiliency as a Service (RaaS) takes a different approach. Leveraging innovations in solar generation, battery storage and financing, RaaS delivers resiliency as an insurance policy. A family of resiliency appliances for different classes of critical infrastructure with different coverage duration options are combined with a risk-based pricing model and then offered to owners of critical infrastructure using a pay-as-you-go model to maintain continuity. An appropriately sized, cloud-connected resiliency appliance provides backup power to critical infrastructure assets using energy stored in lightweight, long-life batteries. This appliance, in turn, may be charged by the electrical grid during off-peak hours or by a solar panel during the day or both, depending upon the risk profile of the asset and the asset’s energy requirements. Batteries are expensive compared to solar panels or even micro-wind generation, but by themselves they are easier to deploy. So, the default appliance utilizes batteries without generation when the modeled outage duration is short. When the modeled outage duration is long and local conditions are favorable, generation is added for improved economics. Regardless, the customer need not know anything about these appliance configuration details. Instead, customers pay a monthly premium commensurate with the risk of their infrastructure assets being without power for some duration.

The Mission: Improve the resiliency of critical infrastructure assets by ensuring they are always on even if the electrical grid is not.

Goals:

Capitalize on innovations in distributed energy storage and generation
Enable retrofitting of existing critical infrastructure with sustainable backup power
Simplify the buying process with a risk-based, pay-as-you-go service model

Solution Components:

Resiliency Appliance: Each appliance is visually “cool”, cloud-connected, implements blockchain for secure and trusted usage records and employs a smart grid-connected charge controller with battery manager to ensure batteries are always charged and ready for service. Families of appliances for specific classes of critical infrastructure are optimized for deployment including form-factor, grid interconnection, size/capacity and accommodations for generation.
Appliance Cloud: Data is at the core of the risk-based value proposition, so each appliance posts granular operational information on the battery system including environmental details like battery and ambient temperatures and humidity, as well as on the generation system when present and the asset. Blockchain transacted records for usage also get aggregated in the cloud – e.g., watt-hours delivered to the asset, watt-hours consumed from the local electric utility, watt-hours from solar or micro-wind generation, etc. Analytics overlaid on this data very quickly enable further optimization of the risk-based pricing and solution per asset class.
Risk & Price Modeling: Risk modeling is a function of the infrastructure asset class and the location. Some asset classes are inherently more likely to lose power than others, some are more critical than others when power is lost, and some are both. Location dictates environmental conditions like extreme weather but also the age and condition of the existing electrical infrastructure. Price modeling is a function of solution cost, which depends on the energy requirements for the asset class, the average duration of power outages and the customer’s risk tolerance. Together, risk and price modeling yield monthly premiums and renewal periods for a specific customer, asset class and location. Data aggregation in the cloud helps risk and price modeling improve over time.
Maintenance Network: Operational data aggregated in the cloud drives a proactive maintenance model that ensures every resiliency appliance is ready to fully meet its service level agreement at all times. A network of trained field workers provides this function with the help of a mobile app tied to analytics in the appliance cloud and a simple provisioning and maintenance model leveraging Quick Response or QR codes and nearfield communications on the appliance.

Classes of Critical Infrastructure Assets:

Traffic Signals: Modern intersections integrate vehicle and pedestrian signals into one or more stainless-steel control cabinets that route power and implement programmable flow algorithms. Resiliency appliances for traffic signals integrate with these control cabinets upstream, so they can provide downstream power when the electrical grid is down, and may leverage existing Internet connectivity required for the traffic signal system.
Outdoor Lighting: Roadway, pathway and parking lot lighting can be addressed individually with a per-light appliance or at the circuit level with a high-capacity multi-light appliance, depending upon the topology at the customer site.
Wired Communications: Twisted pair, cable and fiber communication nodes are either mounted on poles or pads, depending upon whether power at the location runs above or below ground. Resiliency appliances for both pole and pad mounting are provided for integration upstream so they can provide downstream power to these nodes.
Wireless/Cellular Communications: Cell towers employ their own backup power strategy, but the topology throughout a city and within larger buildings within a city have no such strategy. Plus, as wireless wavelengths get shorter to accommodate 4G/LTE and the upcoming 5G wave, more local repeaters and small cells (e.g., femtocell, microcell, metrocell) are required to meet coverage and capacity requirements. Resiliency appliances for these repeaters and small cells match the various mounting options including pole, pad and building mountings.

Possible Ancillary Services:

Harmonics, Sags & Swells: Several are out there installing appliances on poles and pads to help clean up electricity at the circuit level. Some of these same capabilities can be accomplished using a small capacity battery. As the cost of batteries comes down relative to the power electronics required for managing harmonics, sags and swells, or the cost is paid elsewhere, an 80% solution may be delivered using resiliency appliances.
Voltage and Current Regulation: A similar situation to harmonics, sags and swells exists with voltage and current regulation. A small capacity battery can improve matters, offering a potential and very economical solution to 80% of the problem.
Wide-Area Battery Data: Wide area, long-term performance data for different battery chemistries remains nearly impossible to find. As networks of cloud-connected resiliency appliances begin pouring data into the cloud over time, these data can be monetized.
Wide-Area Environmental Data: Mobile devices have driven down the cost of all kinds of sensors, making them economical to include with distributed outdoor networks – e.g., temperature, humidity, ambient light level, movement (accelerometer), etc. Aggregating date and time-stamped values for these sensors across wide areas and over time should also be monetized.

The Internet of Things, or IoT, is vast, consisting of nearly 50 billion “things” by 2020 according to Philip Howard. The IoT is also nebulous. Defined as a network of physical objects or “things” embedded with electronics, software, sensors and connectivity, this IoT as we know it today includes devices as diverse as heart monitoring implants, biochip transponders on farm animals, automobiles with built-in sensors, refrigerators providing online status, bio-hazardous particulate sensors, centrally scheduled and monitored outdoor lighting, distributed net-energy meters, and many more. Plus who knows what kinds of things are on the drawing board.

Connecting all these things to the Internet is a certainty. Economics insure it. Publicly traded companies making data center hardware and software, delivering connectivity plumbing like fiber, providing cloud services, offering mobile services like smart phone connectivity, are all looking for that next hundred million in revenue offered by an emerging market of 50 billion things. Plus like those bulls in Pamplona, startups are running toward this bullring of opportunity too, hoping to create the killer app or uncover the dominant business model for all these things. How, though, will all these things get connected? Why wirelessly of course.

Cellular

The edge of the Internet is hard to get to, because it is either remote or always moving or both. If it were easy, it would already be part of the Internet! Imagine an IoT application that utilizes RFID tags to track tools and equipment assigned to a truck and used by a field service worker. Depending upon the job and the day, this field service truck and worker may be in town where connectivity is easy, or way out of town at a remote, high-value asset like a pipeline pump station. Only a wireless connection works in both situations. One glimpse of a typical cellular provider’s mobile data coverage map and it’s easy to see that cellular coverage is prodigious. Ever increasing ARPU powering a never ending rollout of data connection speeds (… 2G, 3G, 4G/LTE …) has insured that cellular is very nearly everywhere. This fact lies in stark contrast to the many failures of Municipal Wi-Fi, doomed by technical, economic and business model shortcomings, foreshadowing a future bathed in cellular.

Cellular, however, is not the Internet per se because it does not operate using the Internet Protocol known as TCP/IP. Yet cellular routers and mobile applications with their cloud services have become quite adept at marshaling TCP/IP payloads across cellular networks, so cellular is perfectly capable of being used to extend the edge of the Internet as far and wide as cellular networks reach today, and tomorrow.

Spanning Networks

At the Internet’s edge, IoT application developers are hard at work building businesses on devices connected to the Internet via a spanning network. First, a spanning network extends the reach of the Internet using cellular, from a cell tower outward, as far as a cell tower can reach – the so-called last mile of connectivity. Then from the edge of a cell tower’s reach, a spanning network extends the Internet even further. Wired protocols like PLC for gas, water and power meters or RS-485 for fieldbus devices have been used in the past, but the ease and economics of wireless mesh networks like Zigbee and its many variants are rendering wired protocols obsolete. So more commonly, the last foot of connectivity is provided by wireless mesh protocols.

Each IoT application needs a spanning network. The nuts and bolts of this network are built from standard, off-the-shelf components like cellular routers and RF radios, but the performance characteristics of a spanning network are very application specific. How big are the payloads? How far and wide must payloads be distributed and through what routes? With what frequency must payloads be uploaded and downloaded? These application details along with the economics involved in operating a spanning network at scale drive the success of an IoT application, perhaps even more than its functionality.

Designing, testing and then operationalizing a spanning network at scale is nontrivial. Delicately balancing throughput requirements against cellular data plan requirements and costs is just one of the key drivers, but one that has an oversized effect on operational costs. How many wireless mesh nodes worth of payloads can a single cellular edge router manage? How many cellular edge routers are required to cover an IoT application’s service area? How big a machine-to-machine data plan does each cellular edge router need and what will the costs be in full operation?

Early investigations on these topics during the IoT application design phase can be dramatically simplified by a cellular edge router with the right functionality. The same is true during testing, operational scaling and even maintenance over a service agreement’s term. A cellular edge router designed for IoT application developers would support these features and functions:

Application Agnostic
Cloud Connected
Virtualization
Wireless Mesh NAT and DHCP
Bandwidth Modeling
Energy Management
Differential Monitoring

Application Agnostic

Attempting to be the Ginsu Knife of cellular edge routers for IoT developers is folly. There is no way to predict how a customer in a particular vertical market segment will wish to integrate IoT devices with a spanning network, and even if you could, satisfying such a disparate set would bloat a cellular edge router and render performance for any specific customer lame. Companies have struggled for years trying to be just such a solution.

Instead, the paradigm needs to change. The interface between a specific IoT application and the cellular edge router becomes Ethernet only, with the app developer encapsulating their app logic into an Ethernet push device like Synapse Wireless’ SNAP Connect E10 and E20 or EKM Metering’s EKM Push. This push device has intimate knowledge of the payloads being exchanged between the wireless mesh and the cloud as well as message semantics, recovery strategies and the like, which frees the cellular edge router to focus solely on optimized TCP/IP payload exchange.

Cloud Connected

Public IP addresses are too valuable a resource to dole out willy-nilly so instead, carriers dole out private IP addresses to cellular edge routers, which require a VPN connection into the carrier’s network for direct access to a cellular edge router’s configuration. These private IP addresses are used to configure, troubleshoot and optimize the performance of a cellular edge router. For initial configuration a VPN client and configuration may not be necessary because the router can be connected locally to a computer via an Ethernet cable, but once the router heads into the R&D lab or out into the wild it’s a different story. VPN client licensing and configuration across multiple roles within an organization is an unwieldy proposition at best, and one that gets disproportionately worse as the number of routers grows. Edge router support, troubleshooting and optimizations over time to maintain an IoT application’s spanning network must be simple and low-cost.

The solution is for a cellular edge router targeting IoT application developers to be “cloud connected”. Instead of connecting directly to an edge router’s configuration webpage through a VPN pipe, the IoT app developer securely logs into a cloud service provided by the edge router manufacturer in order to manage the edge router’s configuration initially as well as over time. Once provisioned into the carrier’s network, the edge router receives all of its configuration parameters from this manufacturer cloud service while pushing router monitoring and status information to the cloud service as well. No VPN client is required. No direct connection to the edge router’s webpage is needed either. The IoT app developer can then manage roles, authentication and authorization to specific edge routers in a way that is consistent with other managed devices. What’s more, a cloud service enables a stickier, longer-lasting relationship between the edge router manufacturer and the IoT app developer that improves monetization over time and can help fund cloud service development for the cellular edge router manufacturer.

Virtualization

Virtualization has been an economic boon for corporate IT and datacenters because of its dramatic improvement in utilization. Shared connectivity was the enabling technology, lower operating costs the benefit.

A similar benefit occurs when all of the edge routers in a spanning network share connectivity as they do when cloud connected. Cellular data plan utilization improves. In fact, the IoT application developer can optimize this part of their business, which can have a huge impact on the bottom line when considered across many customer installations.

Additionally, spanning network reliability improves. Each cellular edge router’s configuration for a particular IoT application resides in the cloud, simplifying failover and reducing downtime. A cellular edge router can be re-flashed in minutes. Or the router can be swapped in the field by lower cost field resources that know nothing about the IoT application, and then flashed and spun up remotely by the application developer. A spanning network can even be designed with overlapping meshes and overhead bandwidth so that a single cellular edge router can temporarily backhaul multiple meshes should an edge router fail in the field. This temporary releveling can be done remotely to preserve uptime at the expense of throughput, but then returned once the edge router gets replaced, all without rolling a truck.

Wireless Mesh NAT and DHCP

Low power, low throughput wireless meshes are the norm for IoT applications because the operating expenses are more favorable. Unfortunately, these meshes do not use the Internet Protocol. Neither IP addresses nor protocols like DHCP are supported, but a cellular edge router designed for IoT application developers could deliver these capabilities. Using IPv6, a cellular edge router could individually address each node in an 802.15.4 mesh, and provide NAT as well as DHCP to simplify management from the cloud. These edge router features would further simplify the application design process for IoT developers, adding even more value.

Bandwidth Modeling

Many, possibly even most, IoT applications will be delivered as financed services so that the “customer” pays over time, often in the context of a performance contract. Financing adds a time dimension to the economics of a solution, and heightens the importance of operational expenses like cellular backhaul data plans to the overall value proposition of an IoT application. Initially identifying the optimal data plans becomes crucial. Maintaining the optimal data plans over time as carriers change plans also becomes essential.

A cellular edge router will not know the dollars per megabyte for its backhaul pipe, but it will know the megabytes moved through the gateway per month, which obviously drives data plan economics. Early on in the design of an IoT application, the megabytes per month for each class of IoT device must be determined and then used to model the throughput of each router in the IoT application’s spanning network. Making this analysis and optimization easy and then simplifying verification in the lab as well as out in the wild during a performance contract has huge value to the IoT application developer.

A set of bandwidth modeling steps might unfold like this:

Connect an IoT device to the router using a wireless mesh and enable real time throughput monitoring, then run the device through its usage scenarios, keeping track of payload size and frequency (i.e., data usage) per scenario.
Assemble a collection of IoT devices sharing a single wireless mesh along with a single router into a scaled down spanning network, then put the IoT devices through their combined usage scenarios to determine the maximum number of IoT devices a single router can effectively backhaul.
Operate the scaled down spanning network beyond the router’s capacity to understand throughput failure modes and how to set alert thresholds for managing to a performance contract.
Expand to a multi-router, multi-wireless mesh spanning network to fine tune the IoT application’s operational parameters and alerts, all the while using the router’s bandwidth modeling tools as the design feedback loop.

Throughout, easily accessible bandwidth information provided by the cellular edge router enables the IoT developer to economically deliver optimized spanning networks for the IoT application.

Energy Management

Remote IoT applications may be battery powered, so understanding the energy characteristics of a cellular edge router across a broad set of scenarios, as well as being able to affect the router’s energy profile programmatically and in real time, is crucial. However, even when the IoT application is not remote, energy matters. The cost of energy comes out of the IoT application developer’s top line revenue when providing a service. Nowhere is this truer than in IoT applications targeting the energy sector, where every kilowatt generated or saved gets monetized.

The solution involves insuring the IoT application developer has access to rich energy usage data for the cellular edge router as well as a programmatic way to affect the router’s energy profile over time. Like bandwidth data, energy usage data provided by the router helps during the design and test phase and then rolls into differential monitoring to help the IoT application developer craft, then meet, a customer performance contract.

Differential Monitoring

A typical wide area IoT application requires a spanning network with numerous cellular edge routers for backhaul. A successful IoT application developer will have many customers, each with an instance of a wide area IoT application spanning network. Therefore, a successful IoT application developer must manage a large number of routers. Proactively assessing each router’s ongoing performance is untenable at scale, even if doing so can be accomplished using a cloud service. Instead, differential monitoring hosted at the cellular edge router’s cloud service is the key. Granular, side-by-side, near real time graphs of many routers performing similar functions is the simplest way to identify anomalies at scale. Once identified, troubleshooting can begin.

Exceptions to normal behavior, surfaced as alerts, are another form of differential monitoring. Performance thresholds that trigger alerts can be configured to proactively manage a spanning network’s performance to a service level agreement, a competitive advantage in the IoT space. Facilitating the performance analysis of an IoT application’s spanning network in order to craft the terms and conditions of a service level agreement, and then creating the associated alerts, enables the IoT developer to over deliver in the eyes of the customer.

Three Examples

A cellular edge router with these features could be used to design IoT applications where the spanning network provides stateless connectivity only as well as where the spanning network is state-full and provides unique capabilities to the application. A few examples should help illustrate.

Remember the tool tracking and utilization service for truck fleets from above? This application is primarily a monitoring application, so no algorithms need to reside and run at the edge and the spanning network simply passes data from RFID tags on tools through the truck’s cellular edge router and up to the cloud. No app aggregator would be needed in the wireless mesh because no state or semantics reside there. However, IPv6 addressing and DHCP from the wireless mesh all the way through to the cloud would be very beneficial and easily delivered by this cellular edge router.

Similar to the tool tracking example, imagine a service for tracking a department’s fleet of police cars. This application is also primarily a monitoring application without algorithms at the edge, but there are additional store and forward semantics that would improve data collection and bandwidth utilization. Desired data might include location of the vehicle, of course, but also identifiers for the officers in or near the vehicle as well as gun access and stow events. An application aggregator, in this case, would be needed in the wireless mesh and would include a GPS chip for location, an RFID receiver for officer and gun identification plus a holster detector. These monitoring payloads would be packaged up by the aggregator and then passed through the Ethernet interface of the cellular edge router to the cloud. The cellular edge router would know nothing of the application beyond throughput requirements.

At the other end of the spectrum, imagine a mesh of off-grid solar lights that coordinate a shared dusk and dawn demarcation for a cloud-based lighting schedule. Each solar light has a solar collector and can detect dawn and dusk, but these detections will vary from light to light causing a rolling turn on across the entire mesh. For a single on and off across all lights, a coordinated on/off can be determined by majority. Once a majority of the lights within the mesh detect dusk, for example, all lights turn on simultaneously. Ditto for dawn, except that the lights turn off. These semantics are handled within the mesh rather than in the cloud to eliminate the data throughput requirements and connectivity latency. Here an application aggregator would be required, with the algorithm to determine “majority” and then broadcast the turn on or turn off message to the mesh. This aggregator would include a wireless mesh radio so that it can communicate with all the solar light nodes in the mesh, as well as a processor to execute the coordinated on/off algorithm and an Ethernet chip for communications with the cellular edge router. Though more functionality resides at the edge in this example, the cellular edge router still knows nothing about these semantics because they are encapsulated in the application aggregator.

A Missed Opportunity

Nobody seems to be targeting IoT application developers and building this cellular edge router, which seems like a missed opportunity. Fifty billion reasons seems like plenty of motivation, I wonder where the takers are.

Tag: IoT

Resiliency as a Service – Concept

Things