Edge Computing and Fog Computing; or, on the Benefits of Fogging

Edge Computing and Fog Computing; or, on the Benefits of Fogging
21/01/2016 Patrick Zandl
In energomonitor, News

These days, many ways of speeding up the operation of wireless networks arose. It comes as no surprise, one would say, since we expect that the operation of wireless networks will have increased three thousand times by 2025 compared to 2000. In my today’s post, I would like to discuss one of these ways in a more detailed way. I have picked the one that I deal with on a daily basis at Energomonitor. Let’s speak about the Edge, or, to put it differently, about Fog Computing.

On the Edge of a Network, or in the Fog Inside

Why is it called so? The name refers to the fact that, unlike cloud solutions, which imply storing of the content (data, apps, etc.) in a data centre, the points of contact in the Fog are shifted to the edge of a network (therefore it is called edge computing), or, in other words, they are spread out amongst their users just like fog (and now you get the fog thing). Both of the metaphors describe the very same thing. The cloud is up, while the fog comes down amongst us, the users, as fog computing fans like to say.

Let’s take a closer look at fogging. What is this all about? As already mentioned, fog computing involves moving data interface as close to the user as possible. The data is not forwarded in several network hops, to the central cloud located on the other side of the globe, but in just one hop, directly to the closest network component. The component is in charge of processing and assessing the data, answering to it, if possible, or getting back to the cloud. It resembles of CDN networks a bit, except the fact that a CDN merely stores prearranged data and sends it to the customer who picked a particular piece of it, from the closest repository. Unlike CDNs, the fog is able not only to store but also to process the data, plus it creates and sends its own that may be asynchronously updated via cloud.

How Edge / Fog computing works…

Why is the Internet of Things so Close to the Edge?

What is the main advantage of the fog is speeding up feedback coming from a remote data centre. It is crucial for 5G mobile networks in particular, since the quicker the response the lower the latency and jitter. Are the fog and the cloud comparable at all?

Let me put this in practical terms. The context I deal with the Edge mostly, are smart cities and the business we do at Energomonitor.

Every time we do some measuring at Energomonitor (temperature, consumption, or any other readings), our meter sensors must be directly connected to the Internet, or, to be more precise, to the “homebase”. If we take it from the perspective of a network structure, the homebase means the edge. We went for this soultion for practical as well as economical reasons in the first place; it would be really expensive to connect every single sensor to the Internet. It would be also hard to maintain and manage, not to mention the problems with power supply, battery lifespan, and, last but not least, with complex installation. However, then it turned out that a HAN star network (Home Area Network), which is concentrated around a homebase, brings a lot of further benefits.

Homebase Functions

Homebase as an edge device does all the stuff that a sensor is not able to do, since it is fitted with a simple (which means: cheap) processor. The homebase counts up meter sensor readings, multiplies them by the price of a particular unit, downloaded via cloud, so that it shows energy consumption and expenses on a local screen. It is also able to react to measure value exceeding, if needed. This feature is used by the latest generation of homebase devices, fitted with red illuminated displays that indicate excessive energy consumption.

Homebase for Energomonitor energy consumption monitoring

Native cloud devices were not able to provide the calculation by themselves, they needed to be connected to the cloud server, which was not that useful though, in standalone emergency operations for instance. Semi-standalone operations, provided by a homebase, i.e. by an edge device, turned out to be crucial for autonomous thermostats. Another advantage of the edge solutions form the perspective of an end user is that a homebase device might stay tucked away somewhere on the wall, while the user makes do with an access to a thermostat regulator, equipped with a display and a keyboard. The user controls the heating via the regulator, as simple as it is. The data is forwarded to the homebase device and further, if needed. The user can also control the heating online, via an app. The data is forwarded to the homebase device via the cloud, and to the display then, so the user is kept updated about the temperature on a regular basis. The device may also operate in an automatic mode, which means that the temperature curve is generated partly by the cloud, partly by the homebase, on the basis of current weather conditions as well as the regulator requirements. What is crucial here is the fact that he heating works, even if the Internet does not, since the homebase “knows” what to do. The only problem is that, in case it is not provided with the latest readings on weather conditions, it keeps heating, regardless of the fact that the temperature outside has been rising for the last half an hour or so. The device is not fully dependent on working Internet connection but still it needs to be updated with the data to stay “smart”. I hope that this example has been clear enough to explain what the fog and the edge device are, and what are the benefits of the concept. It is obvious that, in the world of the IoT, they have been discovered in the course of many years by many different developers, on the trial-and-error basis.

Why are that many IT companies, such as Dell, so optimistic when it comes to the edge computing? Why do they support it so actively? And why do they expect it to be profitable? Speaking of Dell, as we will see, it would be happy to sell its own servers as edge devices.

Dell Edge Gateway

The Holy Grail of the Universal Homebase

The edge device might be provided with an API, able to register many different IoT devices that would share their profiles with the edge device. The profiles downloaded from the cloud would contain data necessary to set up and provide services via API, which translates into all the operations an edge device should be able to perform, i.e. what to forward to the cloud, what to get back to the sensor or another IoT device. The main pracitcal benefit of this solution is clear: it would be enough to have only one device operating numerous systems. The very same device would control Energomonitor, Hue, NetAtmo, etc. That would involve more transparent structure, easier to control and to be networked, as well as much faster wireless network, and lower prices of course. Last but not least, it would translate into a secured market for the edge hardware providers, such as Dell. Now the dots are connected!

Everything has its pros and cons though. First off, it seems really hard to create and provide an environment to the third parties, which would be safe, stable and automated enough for the turbulent world of the Internet of Things. That is the reason why all the IoT companies make edge devices by their own (such as we do) and why there are tons of various smart “boxes” in your house, instead of just one. It makes sense, if we take that it is significantly cheaper to build a single-purpose hardware device than a multi-purpose, both SW and HW-compatible, versatile one. Anyway, we are in a fair way to versatility, it is going to take some time though. Plus it involves politics. Companies do not want to give up on a chance to be a kind of an “edge hub” in the future. At other times, they are not ready or technologically advanced enough to meet the challenge. This year, some of the companies, such as Samsung, LG, or Google, will be trying to change it. They already have presented first home router-connected “edge hubs” on trade fairs but all of them have their cons, for instance, Google stubbornly insists on their own Thread radio protocol, plus they keep staying incompatible with the Nest thermostat, which aims for the same position. Actually, what cause the most of the problems with building a truly versatile edge box, are those various radio protocols and a really wide range of functions IoT covers nowadays.

Truly “versatile” edge devices find their use in complex industry installations nowadays, rather than in households, as there are more predictable scenarios and technological procedures involved. However, there is an unwritten rule that most of the solutions well-tried in industry come down to the mass market. One of few examples from the local market is Turris Omnia, a multi-tasking home router supporting various IoT devices. Those guys set really high goals and we keep our fingers crossed for them.

How Much Does it Pay?

The importance of edge devices and fog networks will be increasing hand in glove with an increasing number of IoT devices, more and more available, smarter and smarter. Their smooth operation will be interfered by many heterogenic and incompatible transfer protocols, such as HTTP/S, MQTT, STOMP, AMQP Zigbee, Zwave, BTSmart, wmbus, and many more (our proprietary ChiRP included). It will take much time to harmonize it, since each radio protocol is used for different purposes, just as each message transfer protocol finds its own use.

For now, it appears that the importance of API in edge devices will be increasing, and it is a perfect time to catch the wave and start building the environment for embedded devices. In fact, there are still a lot of unknowns in the game played by many bigwigs, such as Google/Nest, Apple, Samsung, LG, or router manufacturers, D-Link, Netgear Ubiquit, Cisco/Linksys, or Synology, who notice increasing demand for smart routers and will not let the chance to slip by for sure. What we definitely can expect in the nearest future is an overcrowded edge device market hard to deal with.

Comments (0)

Leave a reply

Your email address will not be published. Required fields are marked *

*