What would a "fog node" consist of in OpenFog?

Question

The OpenFog Consortium, a group that is working on an open fog computing specification, has published a white paper about their architecture.

They define a fog node as:

The physical and logical network element that implements fog computing services. It is somewhat analogous to a server in cloud computing.

However, I'm having a bit of trouble intuitively understanding what a fog node would be. Would it just be a server or hub device hosted locally on your own network, rather than in a massive server farm? Would a smart home hub (like a SmartThings Hub) be a very simple example of a fog node under the OpenFog definition?

Answer 1

What it looks like they're trying to do is establish semantic definitions for messages and rules that can be interpreted or processed at any layer, and that the layers can be migrated up or down. So yes, a home hub could be a fog node, but only if it supports the fog behaviors and messages.

Think of a typical home automation architecture:

Remote -<Z-wave>- light switch -<Z-wave>- home hub -<Ethernet>- cloud server -<GSM>- phone

You trigger the remote and it sends a Z-wave message to the switch, which turns on the light. You can configure your home hub to send a message to the switch based on other rules (the garage door is opened.) And your watch can talk to your phone which can contact the company's cloud, which sends the message to your home hub, which sends it to your light switch.

Today, you can do the first part of this by setting up a scene in your light switch that is triggered by a paired remote. Using Z-wave, no home hub is needed. You can add a home hub and set up a new scene to trigger the light switch if the remote's button is pressed, but you better delete the scene in the light switch first. You can use a cloud interface to configure your hub's behavior, perhaps triggering your hub via IFTTT. And you can also use your phone to contact a web interface on the cloud and have it turn on the switch.

What OpenFog is aiming to do is to have those device definitions be universal, the rules be platform independent, and the messages be transport independent. They'll share common security and authentication methods. That means you set it up once, no matter where you are, and the definitions and rules are migrated up and down the architecture.

From your phone you could view your devices, which would include the light switch and remote control, and say "I want button 1 on the remote to toggle the light switch". The rules might be created right there in your phone, then transported to the cloud server. The cloud server could examine the inputs and decide "All the responsibility for lights and remotes belongs at a lower level", and push the rules down to the home hub. The home hub could say "hey, Z-wave knows how to run a scene in this model of light switch, so I will push these rules to the light switch and remote." Next time you push the button on the remote, the signal will be caught by the light switch and the light will turn on. This would provide the fastest possible response time (no hub needed). And by having the rules backed up at a cloud level, if you have to replace a defective light switch, none of the rules need to change. They'd just be pushed back down to the replacement switch.

OpenFog also will provide for elastic scale. Let's say you place 1000 light switches in an office building, using a network technology that has a latency that goes up exponentially based on the number of nodes. It could scale communications such that the 1000 nodes are split into 10 networks, so that no network ever has a latency longer than 200 milliseconds.

It also specifies scalability of control. If you've ever worked with systems built for GUI control you get used to instructions like these: "right click on the node, pick 'settings', then set intensity to '75%', then 'OK'". Such instructions are worse than useless when it comes to managing 60,000 nodes. OpenFog should enable automated groupings of nodes allowing scalable control. "For all nodes in Eastern Standard Time zone, set intensity to 75%," or "For all nodes in profit center 12, set intensity to 65%."

It also specifies autonomy where possible. If the Peoria, Illinois branch replaces a furnace vent duct control, it shouldn't require an HQ person to delete the old control unit ID, then add the replacement ID. The local maintenance person should be able to do that herself. The security still has to ensure that the furnace repair person doesn't have the authority to disable the burglar alarm sensors on the back door.

Now, place all of this behind open standards so that a Honeywell burglar alarm and a Trane heating system all interoperate in the same logical network as your Philips light bulbs, Leviton Z-wave switches, and your Fitbit scale.

So, is your SmartThings hub an OpenFog node? Not today, and it won't be unless and until it implements and interoperates with these standards. But a future home hub certainly could be an OpenFog node.

Answer 2

I'll make an attempt at answering this, but want to clarify that this is my inference, not an expert's view.

A "fog node" is potentially anything between a smart endpoint (for example a security camera with image recognition), and an enhanced router node located potentially at a GSM cell-site.

For a node to qualify as a fog node, it needs to perform some of the functions that might be performed at a server under a different architecture. So, in the Alexa model, audio could be streamed continuously to a server in the cloud, or all of the audio processing (not just the hot-word detection) can be performed at the node.

The important distinction of a fog node seems to be that the upstream bandwidth is reduced compared with the local bandwidth, so it is likely that audio or image processing is being performed.

Based on this definition, I think even an intelligent protocol bridge is not quite a fog-node (but the hardware which is used may well be capable of performing fog-node functions) - thinking of my lightwave-rf WiFi link...