What is IoT?

Understanding IoT Protocols, Clients, and Management.

The purpose of this webinar is to put some basic IoT and Device Management concepts and terms in order. The webinar explains what technologies are available in the world of IoT and defines when each protocol should be used, providing an overview of the advantages and disadvantages of each one from the perspective of Device Management and IoT.

After watching this webinar, you should have a deeper understanding of what IoT is, have greater familiarity with standard IoT protocols and clients, and be able to choose the appropriate type of client for specific IoT scenarios.

This webinar should provide an added value to the following types of companies: device manufacturers (OEMs), carriers, CSPs, IoT companies and system integrators, and IoT platform providers

Among the topics covered in this webinar are:

1. Standard protocols – LWM2M, MQTT, OMA-DM, and TR-069.
2. When to use which protocol.
3. The process of deploying embedded clients on the devices
4. How to manage constrained devices.
5. How to manage large-scale deployments of IoT devices
6. Managing Data collection and Analytics
7. Friendly’s One-IoT™ Management platform and embedded clients.

Learn more about the fundamentals of the Internet of Things by checking out our What is IoT whitepaper.

Webinar Transcript:

Hello everybody! We’re going to start the webinar today. The topic of the webinar today is the Internet of Things and Device Management, we’re going to talk about various protocols for the Internet of Things for clients and servers. My name is Ohad Oman, I’m VP of products of Friendly Technologies.

The agenda for today is I’m going to give you a very brief introduction of who we are at Friendly. And then we’re going to talk about the differences, a little bit of introduction, a little bit of background about IoT and Device Management because basically everybody has different notions of what IoT is. So just so we can be on the same level and talk with the same terms we’re going to discuss IoT- Internet of Things and Device Management, then we’re going to delve a little bit into the various protocols that are available. Talk about the differences between them, what each of the protocols is good for, when should you use each of the protocols, the advantages and disadvantages of each one, both for Device Management and for IoT. And then I’m going to show you what an ideal IoT platform should probably look like due to the needs of device management and IoT. And then we’re going to end up with a little summary. Let’s start.

So starting with the introduction, Friendly technologies, to those of you unfamiliar with us is quite a veteran company. We were established in 1997, which makes us in our 21st year already. Our legacy, our core business for years now, for more than 11 years, was device management for the telecommunication industry. We were doing the device management platforms and servers for major and less major telecoms around the world, allowing them to manage the end devices at the customer’s premises in the network devices. Which means that for a while now, we’ve been talking to things, really over the internet, which makes us IoT experts; only it wasn’t called IoT until a couple of years ago, where everybody started to talk about IoT. For the device management part, we have over 200 global installations. When we’re talking about global installations, we’re talking about normally an ISP, XSP, a Telco company, so some of them are running millions of devices on the same network. So we come from that world and we know what we’re talking about when communicating things over the internet.

As I mentioned, over the last two or three years, everybody started to talk about the buzzword called IoT. And when it comes to IoT, there are some slight differences between Device Management and IoT. And we ramped up our technology and our knowledge and our capabilities to a complete IoT solution, and I’m going to talk about the differences between what was classic device management and IoT in the upcoming slides. Again, my name is Ohad, I’m the VP of Product Management at Friendly. This is my email if you have any further questions because there are going to be a lot of people on the webinar today, and I don’t think we’ll be able to address every specific question. I am going to leave some time for questions in the end. But if you have any specific concerns or questions, feel free to contact me at this email, and I promise to get back to you.

Okay, this is just a partial list of some of our customers, you can see some major tier-one customers, they’re both in Telco and in IoT. I’m not going to go through this but just as a reference.

So let’s talk about IoT and Device Management. When people say IoT, you will find out that a lot of people are talking about a lot of different things. And I think I can put everything into the three categories really, about what is the Internet of Things, or what are the things that are controlled by an IoT network. So the big thing is the world that we’re coming from. When I say big things, I don’t mean big physically, I mean big in complexity. So this is the world of device management for Telco’s, for example. So you have the routers, and you have the more complex stuff, but also industrial IoT and connected cars, things like that. These are things that have no problem with power, they’re always connected to the internet, or most of the time connected to the internet. They’re not really concerned about bandwidth. And their data model is very complex. It might contain thousands of different parameters to be controlled. So this is the big challenge. This is really closer to the world of classic device management. Now, when IoT came along, there’s a lot of simpler, smaller things that are connected to the internet, mostly sensors and smaller devices. And these things have a lot of things in common that are different than the big things because they are smaller, they have smaller memory, running memory, and program memory, they have smaller bandwidth because a lot of times they are connected over a SIM card and bandwidth is expensive, and they have low power. Most of the time they are operated on battery, and they need to go to sleep. So these are the small things that are connected directly to the internet. In these things, most of the functionalities, the set and get functionality, which makes the data model less complex. So a light bulb, for example, doesn’t have thousands of parameters to control. There’s on, there’s off, there’s dimming, maybe it can tell you what the power consumption through it is, but that’s about it. So a smart light. So this is the example of the small things, and then this is the more interesting scenario, I believe, and this is the scenario that’s probably going to dominate the IoT world, we’re already seeing it happening. These are the things that are called IoT, but they’re not really IoT because they don’t have the I part in them. They’re not internet-connected things. There are things like ZigBee, like Z-wave like LoRa, like Sigfox, like BLE, all of these protocols that I just mentioned, that are considered to be IoT protocols are not IoT because they don’t have an internet connection. In order to make them an internet-capable device, you need a gateway in the middle. Now, most people view the gateway just as a means of transferring between a non-IP protocol and an IP protocol. So this is just like a pipe. You take a device, it doesn’t have internet, you give it internet capabilities, you bring it up online. This is true, in a lot of cases it is true. So for example, if you have a very, very small installation or just a device that is connected to your smartphone, then you don’t really need to consider the smartphone. Anything else other than taking this device online. I’m going to show you in the next slide why this is a little bit more complex than this. But all of these non-IoT devices that are working through a gateway, what you need to consider is their data model is just as simple as the small things, there’s not a lot of things to control over there. But then when you take the gateway into consideration, things get a little bit more complex. And especially when you’re talking about scale installations, because when you’re a service provider, when you want to deploy an IoT network, when you want to give an IoT infrastructure, there’s going to be a lot of these gateways in the middle. So let’s concentrate a little bit on the gateway architecture and its complexities.

So in this kind of installation, there’s the basic IoT platform. Everybody that will come and tell you they have an IoT platform, normally what they mean is they have the capability to do set and get on the end devices, so to collect data from them and to control them. And from the IoT platform end, there are portals maybe sometimes where you can see inventory, you can most of the time do big data or BI analysis, rules and automation and connect applications to it. And sometimes, most of the time, you can do some basic firmware updates. Again, not necessarily to the end devices, because a lot of them don’t have the firmware update capabilities.

When we’re talking about IoT and device management it gets a little bit more interesting. So an IoT device management platform, first of all, there’s the gateway device management in the middle. So don’t forget that these things are quite big, quite complex. They’re collecting data from sometimes thousands of tens of thousands of devices. Their data model, the amount of data that they’re holding is both complex and dynamic because there’s always the add and remove components. You need to be able to do diagnostics and repair because these things might be millions of them across a state or a country, where some of them might be far away. You don’t want to need to send a technician, you do an IoT installation, this thing should hold for tens if not, you know more than that of years. And you need to be able to configure things from a central location. This is not simply like when you have a simple, smart building installation and you’re the owner of the building, you’re the one that is managing it, you can just log in to the gateway embedded webpage, configure whatever you need to configure, and that’s it, you’re done. But when you get millions of those, you’re not going to log into the webserver each and every individual gateway. So you need to be able to get diagnostics and repair functionality, you need to get alarms and alerts, you need to be able to configure them, do a mass firmware update, for example, I’m going to show you examples of this later on.

Security is a very, very big concern. Because now with the cyber world, and the cyber-attacks, you need to be able to monitor the configuration of this gateway. Don’t forget that the end devices don’t have really a data model or anything to configure. And they’re not the ones that are going to be hacked into, your gateway is where the hackers are going to target because this is your first point of entry that has an internet connection. And if you’re just viewing this as a pipe, if you’re not monitoring what goes through the gateway, then you have no way of preventing or predicting that there’s a cyber-attack on these gateways, for example, and of course, provisioning and everything else. Even with a firmware update in this kind of functionality, you need more advanced firmware updates, you need group operations, you need scripts, you need things like that, and you need service provider tools.

Now that we’re set about what is device management and what is pure IoT, let’s talk a little bit about the protocols that are involved in it. So before we start, I’m just going to give you the bottom line of everything. The bottom line is that there are four main protocols that are being used now, for both IoT and Device Management. There are some variations of this. Some of these are being used in proprietary ways, but in general, there’s MQTT which is the most prominent IoT protocol. This is a very fast, very light, it’s a messaging protocol. It’s a pub-subscribe, I’m going to explain in the next slide what I’m talking about when I’m saying a messaging protocol, but this is a very fast thing. This is very similar to what you have in your WhatsApp or chat applications. This is sending a message being received on the other end, very, very fast. But this is an IoT data protocol. It’s not device management. So you can turn your lights on, turn your lights off, even do dimming because it’s very, very fast. So you press the dimming button, and you see it happening in real-time. But this is not a way to manage IoT devices. Lightweight M2M is a fast, it’s a lightweight protocol. It’s by the OMA board, the Open Mobile Alliance. It’s a lightweight protocol, so it’s fast, it’s light, but it’s a structured protocol. So it’s a session-based protocol, I’m going to explain that too in a second. So this is a protocol that allows you to do a lot of the IoT functionality, but it also gives you light device management functionality. OMA-DM again is from the Open Mobile Alliance. This is a Device Management Protocol devised for the mobile applications. So it’s for things that are on the move, things that are not over a fixed IP or dynamic IP, but stationary. It’s more complex, it’s more structured, it has a lot of functionality. Again, I’m going to show the difference between all of these in detail in a second. But this is a device management protocol for the mobile world and device management for IoT as well. So these would be used for telematics, for mobile gateways, for things like that. TR-069 is the world that Friendly Technologies is coming from. This is probably the most mature and the most complex device management protocol. It was devised by the broadband forum. It’s being ruled by it, it’s very, very widely accepted worldwide. There are hundreds of millions, if not even billions of devices around the world that are TR-069 capable, but it’s a heavy protocol. It’s very structured. And it’s meant for fixed devices, devices that are stationary. So this is just the bottom line of what we’re going to talk about. Keep this in mind when we go through the details.

Before that, I promise to talk about what is the difference between a messaging protocol and a session-based protocol. A messaging protocol is a protocol that basically does pub-subscribe. Pub-subscribe is that there is a broker, you can view it as a bulletin board, message board, where somebody, anybody in the network can publish a topic to the board. Anybody else can subscribe to that topic. So what you’re really doing is you’re associating the thing that sends from the thing that receives, and both of them can send and receive. So they don’t need to know about each other, they just need to know about the messaging board. And it’s very fast because the messages are short, there is no session being opened. So somebody just publishes and that’s it; It’s kind of set and forget, there is a little bit more complexity to it because there can be the quality of service, and it can get assurance that things were actually sent, but you have no visibility about who reads them at the other end. So the object is a topic, so the topic can be the power on for the light bulb that is in room number three in house number four, this can be a topic, and then you can say on or off. This is just an example of what an IoT message would be in an environment like this. But you need to keep in mind that even though it’s very, very light, it’s fitting for battery-operated, low bandwidth applications, it doesn’t take a lot of footprint. The messaging protocol is just a language. Out of this language, you need to build words, you need to build sentences, you need to build stories. If you want to do firmware upgrades, for example, using a messaging protocol it gets quite complicated because you really have to reinvent a whole protocol out of these building blocks.

Some of the common messaging protocols that you might be familiar with are XMPP, CoAp, and MQTT. MQTT in the current day IoT world is the most mature and most widely used. So companies like Amazon Web Services, for example, they’re using MTT, but they’ve built the whole proprietary non-standardized language out of these building blocks of MQTT. MQTT is a standard, but the way MQTT is being used is non-standardized. A session-based protocol, on the other hand, is normally very, very standardized, at least the ones we are discussing, which are LWM2M, the OMA-DM, and TR-069. So the downside of this is that every transaction is a session, which means that normally the client is the one that initiates a session to the server, it goes to the server, it asks for a start of a session, then there is some keys, some information exchange, some verification and you close the session. So you open a session, you do the transaction, and you close the session. This has some load on the server. So this takes a little bit more time than just sending your message and forgetting about this. But this gives you a lot more reliability. In this case, the payload, normally the payload is like what is being sent, the actual data that is sent during the transaction, depending on the protocol its either an XML or SOAP message, as opposed to MQTT, where you can send pictures, you can send files, you can send whatever, or you can send just like one bit of data. But the advantage is that it’s an established protocol. So the business logic is set, it’s known, it’s being used for functionalities, like firmware updates, you don’t need to reinvent them. You just say, update the firmware and everybody knows what to do, everybody knows what it means, everybody knows what is being handled. The data model is of a known structure. It’s very standardized, every client and every server can negotiate between them. Common objects are predefined. So you don’t need to invent, this is already a language. Sorry, this is already language, word sentences, stories, everything is already set and predefined. There’s a lot of flexibility within that, but the basic things are, you know, writing is set, doing a reboot functionality, for example, is the same across the board. It does have, as I mentioned, some load, and it’s a little bit slower. But mature platforms, like the TR-069 platform, or the One-IoT platform that friendly is offering or is already proven to manage like 20 million devices or even more than that on the same platform. So it’s hand-able. There are ways to achieving this. So there is a load but professional systems know how to handle them well.

One thing I’m going to discuss a little bit later is that in order to achieve this the client is the one that initiates every transaction but the server can do a push. So the server can say to the client, I get something to tell you please approach me. So this is a bi-directional initiation. But in general, the initiation is always from the client-side.

So this is a quite complex table. I’m going to go through this in detail and you’ll see it’s not so intimidating as it looks like. But this is a basic comparison between the different protocols. As I mentioned, MQTT is a messaging protocol, while the other three are session-based protocols. This means that the messaging doesn’t have any overhead. LWM2M has a lighter overhead than the other protocols. So initiating a session might, if you need to, on a case by case need but it can be lighter. You can send something without doing all the heavy transactions. The OMA-DM and the TR-069 are a little bit heavier on the transaction, on the overhead. The footprint for MQTT is very, very light, very light. I think you can fit it in 10 or 20K even if needed. LWM2M is a little bit heavier but again, it’s lighter, it’s less than 100K in code. The OMA-DM and the TR-069 need some memory resources. Again, because they’re designed to handle more complex tasks. The server load MQTT is a very light server load, actually, there’s also almost zero server load because there’s no real server, it’s more of a broker. You get a message and that’s it, you don’t do anything with it. There’s a server that sits on top of this that is a subscriber to these messages. And it’s putting messages that it’s receiving into a structured database. LWM2M again, it’s a lighter server load. It’s not a lot because the transactions are small, the data model that is being handled is smaller. And OMA-DM and TR-069 are heavier server loads.

As far as the data model MQTT, as I mentioned, it’s just a language, so it doesn’t really have a data model. You need to build the data model on the fly while you’re structuring it. So you can’t really — well, you can but you need to reinvent it. Basically, an MQTT is just a messaging protocol, so there’s no real data model. LWM2M, OMA-DM, and TR-069 are structured data models. So it looks like a tree, there’s a topic, there’s a sub-topic, there’s a sub-topic, each one of them have their own parameters that can be set or get, you can perform set or get on them. TR-069 is even a little bit more structured than the rest. I’m not going to go into the details here. This is not within the scope of this session. But the complexity of the data model is, again, with the LWM2M you can handle hundreds of tens of hundreds of items per data model. In OMA-DM and TR-069 you can do thousands of them or even more. Dynamic means that if something changes, if the server requires a change in the data model, the server cannot really affect the data model of an MQTT. So let’s say you want to open another instance, open another room. In TR-069, LWM2M, and OMA-DM you can do this, the server can expand or reduce or modify the data model. MQTT, because there’s no real data model, it’s not something you can do.

Firmware upgrade with MQTT, you need to reinvent your firmware model, you need to do something proprietary, firmware upgrade sorry. In LWM2M, OMA-DM and TR-069 firmware upgrade are one of the basic functionalities of the protocol. It’s all an object or an instance or whatever it’s called per protocol. But it’s all set and predefined, including what happens during a firmware update. So the message is that if let’s say, firmware update failed, and it failed because it didn’t find the file, or there was not enough memory, all of these things are set as part of the protocol. Whereas in the non-structured protocol, you can do this, but you need to write it in code. So really the bottom line is MQTT is not really a device management protocol, even though some people are building the proprietary device management functionalities out of it. But LWM2M and OMA-DM can be used for device management or are used for device management and TR-069 is the most mature one for device management out there. As far as response time though, this is where MQTT takes the lead. Response time for MQTT is very, very fast. So you can do like volume up and stop when you get to the right volume, for example, whereas in session-based you wouldn’t be able to do this, because I mean LWM2M is quite fast it can take under a second for a command to get to the other side. But with OMA-DM and TR-069, it can take even up to 10 seconds sometimes for a transaction. So you’re trying to do dimming, you do dim down, press it once and then you press it 10 times and you’re not going to be able to see the response, so you might overshoot. So these for these types of functionalities, when you need something very, very fast response or real-time response, it is real-time but real-time within a few seconds and not within sub-seconds. So the bottom line of this that the common use for MQTT is for sensors, and for small and constrained devices, this is what it’s trading for. LWM2M again, the same thing as MQTT, but LWM2M can also manage small gateways or collectors. Gateways that you have a few devices that are connected to it. OMA-DM is for mobile gateways, for telematics; and TR-069 is for fixed gateways or for complex gateways.

As far as protocol comparison, as far as the basic functionality for those a little bit more tech-savvy among you. So all of them have the push functionality. So all of them, the server can ask or somebody can ask a device to give it the messages. All of them have an option to be discovered, or provisioned. But MQTT, again, it’s unstructured; you need to write the provisioning protocol on your own, whereas provisioning is a very, very basic skill of the more structured protocols. All of them can do get, all of them can do set because this is IoT. For boot and reset again, this is a structured thing for the structured protocols and you need to do it on your own in MQTT.

Diagnostics TR-069 is a highly diagnostic protocol with a lot of subprotocols that are contained within it. Change notification is if something changed, let’s say you’re doing a water meter system, but you’re seeing that there’s a leakage. You’re detecting that there’s a higher rate of water consumption, you want to notify about this. All of them can have the capability of doing this. Again, with MQTT, you need to be a little bit proactive about it. Application Management because OMA-DM was designed for mobile phones, this is the highest application management, skilled protocol. TR-069, you can do some level of application management, while LWM2M and MQTT are just simply too light, too basic to do that kind of thing. And with the protocols that are from the Open Mobile Alliance, the lock and the wipe is a very basic skill of them, where TR-069 and MQTT are not designed to do that type of functionality. But I think TR-069 there’s some way to work around it. As far as security, all of them are somewhat secured or more or less secured. TR-069 is a very high highly secured protocol because it was designed for Telco’s, so is the OMA-DM. LWM2M is also supporting certificates. So you can send the certificate and you can verify who’s on the other side. With MQTT, you got all the security about the encryption of the transaction and you can run it over VPN, and you can make it secure. The most secured by the way you make MQTT you lose a lot of the fastness and the functionality of it. So you can build a very secure protocol over MQTT but then it would just be as slow as some of the other protocols.

As far as reliability of communication, which is called sometimes quality of service or making sure that the message that you sent actually got to the other end was understood and was acted upon. So TR-069 and OMA-DM are designed for that. LWM2M you can set the level. So for example, LWM2M, there are several levels, I think three levels of use mode in LWM2M. By the way, also in MQTT, where some of them are less reliable just to take advantage of the best effort that you get over, for example, when you’re working over a SIM card. So you don’t want to bother about making sure you’re saying I’ve sent the command if you got to the other side, fine, if not, no. Or you can set it to a more highly reliable level; so it’s configurable.

So we said I’m talking now about the more structured protocols, the session-based protocols. We said there are standards. They are regulated by governing bodies. They’re widely accepted, everybody is using them, which means that every client or every device that is employing them can connect basically to any server without too much of a modification. There are some advanced functionalities and proprietary functionalities in all of them. But the basic set, the set, the get, the provision, the firmware update, reboot, the basic functionality is common to all of them. So obviously, there are some open-source clients for device manufacturers that they can use out there. And these open-source clients comply with a regulation. So why not use these open-source clients? Well, the basic answer is you can if you want to do some experimentation if you’re some home users, some maker, some hacker, or some, you know, something like this. If you’re a device manufacturer, these things are simply too basic so they comply with the rules, but they’re not optimized and they’re not meant for mass production. There are carrier-grade clients, friendly offers, I think for these three, also a carrier-grade client for device manufacturers, this is not our main business, this is not where you’re coming from. But we found out that because we know how to build a server, we know what is needed on the other end. And some of our customers came to us asking for these clients, so we devise them when we made the carrier-grade client.

So a carrier-grade client has more features than the basic ones. Each of these protocols has a basic set of features and a more advanced, again, regulated, but set of features. And then there’s some unregulated set of features that just gives you more functionality when both the server and the client support it. So there are advanced features that are in carrier-grade clients. They’re optimized for footprints. So they’re smaller in size because we have more experience. They’re optimized for transaction time. So you know, there’s a session, if it takes the client more time to respond, then it takes more resources more load out of the server. And it’s less fitting for deploying hundreds or thousands, or tens of thousands, or even millions of devices on the same server, because each one, will even a fraction of a second more means fewer devices and more problems on the server-side. You get upgrades when you’re buying a client, you get the upgrades when the standards change or get more features, you get service and support and you get also server access for your R&D team to deploy it> Professional server access for bringing it up on your device.

So here’s a sample architecture of how an IoT installation would look like. And just to give an example of each of the topics that we’ve discussed so far. So this is the main server, this is the IoT platform. Everything in orange is part of the IoT platform. A very basic thing is a lot of these devices that you need to integrate already have some sort of IoT. A lot of times they would have an MQTT protocol connected to their own cloud. So let’s say this is our agriculture, and this is some ground humidity sensor that is already installed in the field or that you want to buy from an external source. So a good IoT platform would have a cloud-to-cloud interface. So they have their own cloud, their cloud has an API, and the server should know how to do it through Web Sockets, through REST API, or RESTful API should integrate to a third-party cloud, then just get the data. Obviously, you’re not going to do the device management, but you can still get the ground humidity data out of it or you can turn it on or off. If it’s your own if it’s something that has a protocol like LWM2M you can integrate directly into your system and control it. Again, get the set and get and also if it has any device management functionality. But this is LWM2M for a sensor, it’s probably not going to have too much to control here.

Now it gets more interesting because a lot of these installations work through a gateway in agriculture. And specifically, because these are large areas, a lot of times what they do is that they have sensors that are talking through some RF protocol. Let’s say BLE is getting to be a more common one. And a farmer can drive using his gateway, or even a tablet or a phone and collect the data when he’s going through the fields, he’ll just collect the data off the various sensors that are out there. So it’s not a fixed sensor, this is a mobile sensor. In this case, you probably use an OMA-DM protocol to manage the gateway and the sensors would be through some sort of RF. But the most common thing and the thing we’re seeing most from agriculture companies is this scenario. This is actually an interesting one because it starts with a collector. A collector is a device, let’s say in this case, LoRa, but it can be Sigfox, it can be lightweight, narrowband IoT, any of these protocols, but the collector is something that you can connect devices directly to it. So it supports a lot of legacy agricultural devices, devices pre-IoT era that they might have I2CSPI, some Canvas, some other type of wired bus to the collector. So this collector can be connected to a few sensors, maybe to an irrigation system, something like this, it would communicate over some non-IP IoT protocol. So like LoRa for example, is a very, very common one for this gateway. And the gateway would be managed, probably by a TR-060. We’re seeing this more and more, a lot of gateway manufacturers are coming to us asking for TR-069 capabilities for their gateways. It’s something new because LoRa is not about gateway connectivity. It’s more about collecting the data, and we’re adding the gateway. And from this, once everything is on a server, then you can do a — I’m going to show you all these other capabilities of an IoT platform next.

So let’s talk about IoT platforms. This is a typical IoT platform, a fully ended IoT platform managing both data and device manufacturers. On one hand, you have all the sensors and the devices, and the gateways. You might have third-party connectivity. So an interface through some sort of a smart layer to other third-party devices. And here on the server-side, there’s the big data, there’s the monitoring, there’s the support portal, I’m going to show you what I’m talking about, there’s administrator portal that you can manage the assets. And on the other end, there’s a smart API. Now, dealing with something like this, you don’t need to write a different application for every single protocol that’s on this side. So using a smart API, you’re really doing an abstraction layer, or sorry, not an abstraction, normalization of all the APIs. And when you’re writing an application, when you’re doing some sort of interface from the applications or from the back end to any of the devices, you really want to be agnostic of what’s going on this side. This is how we’re doing this on Friendly, this is the Friendly server, the Friendly IoT platform, for example. So on the devices on the south end, you got an interface through a smart layer where you can have one of these protocols that we discussed or proprietary protocols when you do abstraction. And on the northbound you got a smart API. So when writing, let’s say a smart city application, when you say turn on the lights, all you do is you write turn on the lights on this end and this decides if the light is LoRa connected light or a specific proprietary, connected light, it doesn’t matter. You can switch.

Also, we have an application generator, which is a required thing when you’re doing large-scale installations, because let’s say you’re doing a smart city and you’ve got a variety of gardens. Every garden you have to write its own specific application if you’re trying to code it. But if you’ve got an application builder, an application-generated platform, then you can make changes on the fly. You can do a basic drag and drop or wizard to create specific applications and use them either on a mobile device or on a fixed device. So this is just general architecture.

This is Friendly’s device management and IoT platform where you can see all of these things. So you need the self-support portal, if somebody is trying to see if he can reconfigure his own gateway, do some basic reset or re-provisioning. You got a provisioning portal, so new devices don’t need to be entered manually. You got a call center because a lot of the IoT installations are IoT as a service. You have an administrator console because you need to manage all of these devices, do group actions. I’m going to show you in a second. QoE’s like big data type of devices, finding what is the quality of the connectivity to the devices, or getting some business intelligence, event management. This is where the applications are built into the functionality, the automation. NBI for CRMs, for back-office devices, also for external applications, BI report generator and cybersecurity, which is a new edition and very, very important function that allows you to monitor because you’re monitoring the configuration of the devices. This allows you to monitor and detect cyber-attacks long before they happen. This all goes through the smart layer. And then on the other side, by the way, there’s also back functionality for SNMP or HTTP, which is file-based devices, device management, and some other ones that you can add; and on the other end is the vertical applications like IoT devices, Smart Home, also, our legacy which is managing CPEs (customer premise equipment), devices like this.

So this is the admin console, this is just a sample of what an admin console should be like. You see all of the devices that are on your network, there can be millions of these, and it lets you either go into each one specifically. So go into the specific CPE. Or you can manage them in groups, or you can define KPIs for monitoring, or you can divide events or generate reports or manage the files of any of these. So just a little highlight, you know, this is for managing specific CP, you can get the device info, you can get all of the data models of the device, with collapse, expand. So you can see every single parameter that every single specific device on a network is doing on one hand, or you can go to update group and do group functionality on it. I’m going to explain this in a second. For a specific device, you can get all the skills that it can do. And you can even use them from buttons. So you can trace the device, you can reboot the device, you can set a device to factory reset just by clicking a button because again, you don’t care what the device is. If it’s using a standardized protocol, then it’s very easy to do any of these functionalities because it’s supporting them by definition. Even with provisioning, replacing a device. You can do big data collection through reports. You specify a KPI. So you can say, for example, I want to monitor one of these parameters every one hour across all of the devices in my network, or across all the devices on a specific street or in a specific installation.

This is actually an interesting device just as an example, this is a smart home gateway that you’re seeing here. That is working over actually over TR-069, and it has both device management and IoT data all in its data model. So everything you see here is diagnostic, is the device manager and functionalities. It has a Wi-Fi access point, you can specify firewall functionality, you can specify what the IP is, all the things that don’t have to do with the data, but with the gateway itself. And everything here is actually the data, the key knob, the meter, the multi-switch sensor, all these data you can see as data points and collect them. So these types of things can be managed by an MQTT. And together you get a full picture of the functionality of the device and the devices of the gateway and the devices that are connected to the gateway. So let me give you an example of what an advanced group update would be. So in the case of no device management, let’s say just a normal IoT, a firmware update would be sent via FTP or where the firmware file is, and ask the device to report to you once it’s finished. Again, a lot of times they don’t even do this. But ask the device will tell you if it was successful or not. With advanced device management, you can specify a group of devices to be updated together based on the model, the geography, the firmware version, any filter that you want to add, and define a group. You select a script for the firmware update. So you can ask it, every device in this group can do a reset, backup its configuration file, do the firmware update, do another factory reset, and do restore of the configuration file, for example, for each and every one of these devices, while letting you know what is the progress of the script of this group update, what are the reasons for failure if there are reasons for failure. You can specify only to do this between 1 am and 2 am on every Tuesday because these devices are not used. You can do it on 100 devices or 1000 devices at a time. You can say do this every two hours, every one month. Let’s say you want to do a reset, just a simple reset once a month. So you can specify the repetition conditions. How many devices fail that you want to raise an alert and stop the process because something is wrong? You can say only do this on online devices. Do you repeat if it failed, things like that, and again, reports and statistics. So this is a mature IoT platform functionality.

Don’t forget that IoT most of these times are going to be IoT as a service and not IoT as a project. So IoT as a project is more like M2M. You go to a factory, you do some automation functionalities and that’s it or if you buy your own Smart Home out of the store, then you get a smart home as a product not as a service. But if you get a smart home from the service provider, or when you’re doing the lower network, you need to provide service. So if you provide a service, you need the support center, you need the call center. Where the call center can go and look into every specific device and try to help you with it, change the password, do a reset, find out what are the immediate suspects for — basically provide tier one support on this, and events a little bit more than that, because you can do firmware upgrades for individual devices, you can change the parameters, you can basically see all of the data models. So whatever is exposed on that device, the customer service representative can see it. Of course, there are different levels and different skills of CSRs of customer service or technicians, so as you can specify, you know that some of the technicians are not going to be able to do all of the functionality, just basic ones, and the experts will be able to get access to more devices like this. Again, a good IoT platform should have a portal for customer service, or at least an API for customer service.

Big Data is, of course, BI and monitoring is a major part of every IoT platform because IoT is mostly, don’t forget, were discussing a lot of the device management functionality. But at IoT, the bottom line of an IoT platform is about the data. IoT is about data. So big data and analytics, for example, we implemented SciScens BI and reporting into our platform. Didn’t reinvent the wheel, we’re just using a very high professional one in our platform. But again, there’s also an API and KPIs that you can produce for external, more advanced, or more proprietary or something that you are already using, you can just get the data straight out of the system. But the reporting system, the monitoring system is very, very advanced. So you can get every data of every parameter in our system on every frequency that you want, up to millions and millions of devices and data points. We even add in our own IoT builder. This is an example of our IoT builder and how it looks like. So you can build your own applications using a very simple wizard without having to write code without having to outsource this function to an external or having engineers and designers do it. So it’s just a drag and drops, you got basic functionalities like mapping, or if this then that; if you see this sensor– Let’s say if the temperature drops below a certain thing, give me an alarm or automatically turn the air conditioner off or do any of these functionalities, of course with clicks and it goes on mobile devices and it goes on desktops or on dashboards. So you can build dashboards, you can build applications for specific streets in your smart city or for a specific branch in your supermarket change or anything like that. You can modify just with the drag and drop, so you don’t need to recompile and resend. It’s an html5 application that are running on every device.

So we’re down to the summary part of our discussion. Just IoT and device management platforms, what are the benefits of it? So we mentioned, don’t just manage the data of your IoT, also manage the devices of your IoT network. Have functionality of alarms and notifications not just from the sensors and devices, but also from the gateways. So you know when something is going wrong, or about to go wrong, or you’re under a cyber attack or a device is going to run out of battery or things like that. Use standardized protocols and servers. Because there’s a lot of experience and common knowledge and maturity behind it. Use carrier-class devices, because God forbid, you become successful and you don’t just do 500 devices, installations, but you do 5000 or 50,000 and then you’re going to run into problems if you’re using something that is not carrier-grade, and you don’t, you want to be backward compatible from the beginning. And end-to-end platform should have at mean and service portals should have big data should have BI, should have applications, API’s to external professional services like a CRM, or other SAS applications. You need to be, again, depending on your need, but everything now is on the cloud. But a lot of times for security, for costs, for other purposes, you want to be on Prem or you want to be on a private cloud, and not just on a public cloud. Public clouds are definitely an option, it’s becoming very, very popular. But then Amazon is taking a big chunk of Microsoft or whoever is running your public cloud is taking a big chunk out of your profits. And if you’re a service provider, you want to get service provider-oriented platforms that know your needs and your specific requirements as mentioned.

This is more or less the basic presentation that I have prepared. I think — Do we have time, what time is it? Yeah, we’re just about running out of time. Even exceeded it by five minutes. If you want I can stick around for another 10 minutes if you want to write questions if I find out how to open this thing. If not, my email again is ohad.oman@friendly-tech.com. You can send me questions or you can send questions through your contacts. Thank you very much. I’m here.