 So, it's time to start, I think. I don't think anybody else will come, or will. Today I will tell you about IoT solutions for life safety applications, obviously, yes. And I'm not a life safety expert. I'm currently not an embedded engineer. I'm somewhat in between. So, at the moment, I'm Chief Technology Officer at TowerAQ. I've been in development for four years in embedded development, and three years in life safety industry. I'll tell you about fire ground communications inside the high-rise buildings. It's a particular part of this industry. I'll explain you complications a little bit later. At TowerAQ, it's a company based in New York, and its main business is making first responders communication systems inside the high-rise buildings. On the top of that, we figured a way of reusing existing infrastructure for IoT applications. It becomes a life safety IoT-grade network. And as an additional service, we offer signal propagation calculations for our integrators that eliminate the need of hiring RF engineers, RF experts for them. And because of that, we call ourselves Radio Back Office. I'd also like to explain my personal motivation speaking on this topic. I started as an embedded engineer in telecom industry, and I was young, proud. I was inspired by the technology, and I was a geek. I liked IoT protocols, edge processing, all the different networking tricks. And when I entered the radio communication industry, especially radio communication for first responders, I was shocked by the inertness of the industry. And this made me curious about the following. If I can push this life safety communication industry towards the latest, well-tested wireless technologies, I believe I will. Here from the other end of the problem, from the embedded world, I like to underline specific features of modern IoT technologies that make them not very well suitable for life safety applications, and I hope these efforts will push two strangers to each other. I would also like to point out what this presentation is not. This is not a guide of reinforcing existing IoT infrastructure. You have to plan before you deploy. And this is obviously not a complete list of technologies that can be used to reinforce or make your infrastructure more resilient. So agenda for the following 30 minutes is on the screen. First of all, I will explain you main challenges that we face in our daily routine deploying radio communication systems. Then I will do a brief overview of modern IoT technologies, not all of them, but the most popular ones. Just as that, I will explain you some reinforcement techniques. We'll sum everything up, and you will have a chance to ask me a question, I believe. I don't have a very long presentation. So starting from the industry's features, this may be obvious, but safety first, and this is not just a slogan. It's a real way of doing business in the industry, serving the first responders. It has very strict rules, and we have to follow. And going a little bit deeper about the industry in earthness. We face in earthness in communication industry, and this is because fire ground communications are required for firefighters during the incident. They use it during the fire, and they need it to be robust and reliable. In high-rise buildings, there are too many obstacles on the way from one portable radio firefighter to another portable radio. Concrete walls, metal compartments, anything. It prevents radio communication waves to go from one portable radio to another. All the fire alarm initiating devices. They are almost always wired. All those fire buttons, smoke detectors, sprinkler heads, it's almost always wired. And there is a reason for that. Application requires an extra layer of heat, physical, humidity, and especially improper use protection. So basically resilience is required. On the other hand, from the functional point of view, following needs to have to be fulfilled. Here I will describe the essential needs of a particular building, not the whole city as a system. So each building has to support fire ground communication during the emergency incident. And this is very essential for firefighters' efficiency and their personal safety. In case of lack of coverage, they have to use one team member or several team members as a relay. So they do a mesh networking. Don't even know about that. Emergency light circuits installed along the emergency exit routes have to be monitored as well as their malfunction have to be immediately reported to prevent panic during the accident and to prevent deaths. The same thing happened with the evacuation guidance. All those arrows, floor plans, etc. They have to be operational all the time. Facilities also have to be monitored for proper fire extinguisher placement and timely service of them. It's not a life safety, but I have to say about power management. It's not critical but affects costs. And for most of the time, when there is no accident, it's very important for building owners. Now I will briefly go through the modern IoT technologies and data delivery methods to specify their features, making them vulnerable to external impact so we can understand better what we are going to improve. I should start with the most popular one, with Laura. It has lots of advantages over the mobile connection. It was used previously. And it also has advantages over the competing technologies. Its main feature is operation in long distances between terminal and hub. So Laura says it stands for long range. And typical in field range outdoors is 15 kilometers. But there are examples of getting stable connectivity over 200 kilometers in a line of sight. And recently I've seen and used about having a stable connection between satellite and ground station. So it was long distance. The other very important feature is operating in ISM band or in other words license free band. It differs from country to country, but in general stays the same within a continent. This feature allows every individual to roll down his own Laura network in the same way you run your own Wi-Fi access point. Laura gateways. They can handle signals below noise floor. This is being achieved using the chirp spread spectrum modulation which is not very efficient way of using the spectrum. As you can see there is a wide hill. But this modulation skill is a reason of low power consumption and higher resistance to the noise. So this feature is derived from the modulation scheme used in the physical layer which is proprietary and owned by SEMTEC. This is not a big issue. Unless you want to do some tricky things with this IoT protocol. But Laura Allianz offers Laura one. It's a media access layer for the IoT devices which is open and anybody can dig down. But there are also some obvious limitations. As you can see on the drawings there, there are too many obstacles on the way down to the basement from the base station and considering the fact that Laura hubs are commonly being installed on the rooftops. It makes a lot of blind spots under them which is unacceptable for our life safety equipment management or monitoring. However, Laura performs well in horizontal plane but works way worse in high towers and underground. All these features make Laura very well suited for utility metering and any other general data collection or sorts of that. Moving to the next slide, we are getting to the SIGFox which is a French company based somewhere here which is a technology and a service two in one. SIGFox claims nationwide coverage in 17 countries across the world at the end of 2018 and continues to grow through its partners. According to their business model, I would say it's a network as a service, NAS. Base stations are proprietary and operated by their partners. Because of that, you cannot improve coverage near you by deploying another gateway because it's owned by the SIGFox's partners. But this also provides the simplicity of deploying a fleet of terminals because network is already there. You don't need to worry about that. SIGFox also provides more uplink, downlink, bandwidth imbalance than Laura but this is negligible for most of the applications so you don't need to worry about that. Just for the comparison, there is also an option with higher bandwidth and higher power consumption but offering a mesh networking capabilities. I mean, SIGB. I'm not going to go deep this way. I'll just underline its main features. It still operates an ISM band, consumes more power, especially router nodes that can relay messages from the endpoints to the concentrator. It has lower resistance to the noise comparing to Laura but considering the fact that it's used generally indoors and has higher output, it's not a problem. It's very well suitable for indoor data collection and tracking. Who of you are aware of YSUN protocol? Any of you? Just raise your hand. Nobody? Okay, this is a dark horse of IoT industry. It's very similar to Laura. It has a long-range operation, same 15 kilometers or about the same. It has similar bandwidth but it has some key advantages over the Laura. It can operate in star, mesh or hybrid star mesh topology in the same way that SIGB does. It has open standard for file layer so you have a choice of your hardware vendors or you can create your own if you're cool enough. Public infrastructure is already embedded into the protocol and it's based on X509 certificates and already implemented there so device authorization and data encryption is already there. This technology is being widely used in Asia. I know big networks being deployed in Japan, South Korea, China and Taiwan. You may think that Internet of Things is always something about wireless infrastructure but this is not actually. There are a lot of examples of wired infrastructures used for IoT and it's very widespread in car industry. All car communication lines are wired, almost. In oil and gas industry, it's almost always wired. Fire alarm panels and their sensors, initiating devices, they are wired as well. It's super reliable infrastructure under almost all conditions but it's also prone to a physical damage. Wiring joints are not always water and temper proof which is not acceptable during the fire suppression procedures. If it's sprayed out of the fire hose, it will be damaged. And the most important, wiring requires a lot of labor to install and maintain which affects costs and sustainability of such systems. Sometimes wiring is especially complicated if you deploy in landmark buildings because of regulatory requirements. All solutions, either wired or wireless, require some kind of gateway or local processing on site. This is another point of failure. 3G and LTE gateways without local processing are, I would not say useless but they are too much dependent on the backhaul network capacity and quality so they cannot be considered to be used in any responsible applications at all. Wired gateways is usually even more prone to errors because of the backhaul network of whatever kind. Fiber, phone line, coaxial cable, they'll fail right after a few minutes after the major leakage or fire accident in the building. Most of the data concentrators have no backup power which leads to absolute uselessness during the power outages which is often the company's major life threatening accidents. Even though those gateways are certified for industrial use, they are not meant to be used under fire conditions or big leakage. Considering all these issues, we had to look for reinforcement techniques. Here I will reuse some techniques that can be used inside the buildings. Not all the applications where safety is major decision making factor. So other industries may apply another techniques. I believe that construction and in buildings it's what can be used. So let us take a look on the systems that are already installed into the building and comply with the most strict industry standards. And then we can study what aspects of their operation makes them suitable for handling the emergency. So the first thing is the fire alarm is being installed for fire detection reporting. There is no obvious fire alarm to show you. It's for fire detection reporting to central monitoring station and the most important for local sound initiation. If there is a fire when you sleep you have to wake up and go away. The louder fire alarm is, the more life it saves. So it's all wired. Connection to central monitoring station is dedicated wiring and central monitoring station periodically checks the system for its operational health. So in case of any trouble in communication building owner have to call a service personnel or building separation permit can be temporarily revoked. There is another very important system that is being installed into the building taller than 20 meters in New York and in all buildings that lack external coverage in all jurisdictions outside of New York. I'm talking about United States. This is an auxiliary radio communication system. It's required for all buildings to provide complete radio coverage for first responders and in jurisdictions where systems are integrated it can be achieved naturally. Because of building is close to the base station or has thin outer core. But in dense urban areas integrated systems can be ineffective. In this case, isolated radio system is being deployed inside each building. It consists of radio base station and antennas. Both systems, fire alarm and auxiliary radio communication system have their own backup power and battery capacity monitoring. This radio communication system needs to have antennas and this is a separate system referred as DAS distributed antenna system. Physically, this is a tree built of connection cable and tuppers. The idea is to make system distributed enough to provide complete coverage over the building. But at the same time do not produce excessive RF power to the outside. Just not to pollute the RF spectrum. This system is prone to a physical damage. This is why it's required for cabling to have a two hour fire rating and being periodically inspected. Two hour fire rating is a huge pain for the installers because in order to achieve that, they have to break that up, all the cable break up into the walls or use special conduits or provide a two hour fire rated cable. But the joke is there is no two hour fire rated coaxial cable. Because it has inner core and outer shielding and outer shielding always heats up faster than the inner core and it changes its resistance. So we wanted to make this distributed antenna system to collect the data for us using one of the IOT protocols. In order to achieve so, we had to invent something called the active DAS. This is the way of substituting the radio base station and antenna system, the antenna tree. With a network of small radio stations operating synchronously, we called the system tower link. And on the drawing, on the drawing, you can see the tower link nodes as the gray rectangles. Using the active nodes has several major advantages. The most important is the usage of a single pair of fire alarm cable for backhaul network. Those cables are available in two hour fire rated insulation and this makes system deployment way easier because they don't need to break it up. They can just expose it on the wall anywhere. The other advantage is the control over the individual nodes so we can monitor for antenna integrity, received and transmitted power. This makes system service up to 10 times less expensive comparing to the passive systems. And the most interesting part, we put lower hub into each node. Don't worry, we're not going to pollute the spectrum with dozens of lower hubs in single block. Coverage is being tested upon the first run and redundant lower hubs are turned off. So, on the previous slide, you've seen the tower links node are connected with this red line. It's a fire alarm cable. And you may wonder how those joints are made. They are easier as pie. I believe you already heard about power line communication, do you? Okay. It's easier as pie. We use G.HN technology that allows to run AP traffic over a single twisted pair. It's very similar to Wi-Fi but uses copper cable as a media instead of air. So, on the drawing behind me, you can see two networks that are equivalent from the topology point of view. On the left side, we can see six Linux hosts connected to the network using the G.HN models. And it's like a bus. So, they can be connected to a single bus and there can be up to 24 devices on a single pair of cable. It's equivalent to connecting those Linux hosts to a single network switch but obviously it's not as fast as Ethernet. Total length of a carrier cable can be up to 1,000 meters and maximum speed is 1.7 gigabits per second up to specification. We've got stable 140 megabits over 900 meters cable which is more than enough for these applications that we have and you can consider this is a good alternative to Ethernet connection in your applications if you need to go further 100 meters. Here is a brief overview of each particular node. I also had to say about fiberglass. Have anybody of you thought about fiberglass? Why don't we use a fiberglass? It melts in fire. Okay, that's why we had to use a copper cable. So, there is an overview of a single node. Red lines on the right are the communication line and each node has two independent domains. One for emergency communication on top and one for IoT data at the bottom. They have common communication line. They also have common synchronization line going out of GDTCHN modem because the GDTCHN communication it's a TDMA based communication and it has a very precise synchronization clock. So, we use it for class B lower operation and also it's used for simultaneous transmission from several nodes to provide constructive interference between nodes on the radio channel. Radio communication traffic has a priority over IoT traffic and if network is overloaded, IoT subsystem go into a sleep mode to allow communication for firefighter. I will also explain you later what we had to do with this system to get certified. Using this approach that I just explained, we utilize core-required infrastructure so every building owner have to install that in order to open the building. We utilize core-required infrastructure to provide back-hole medium for lower hubs throughout the building and these installations are being tested against the fire and water spray from the fire hose. The other benefit of that is these installation are being installed at the time of construction or major renovation and at building owner's cost. So, they have to pay for that in order to open their building and we call that foot in a door or train horse approach. So, we try to squeeze maximum out of the infrastructure that building owners already forced to deploy and we added a second function to a system that's inactive most of the time but still needs to be maintained for some money. So, it's a stay in standby mode more than 99% of the time and we applied some kind of commercial operation for that. So, we did a twisted pair trick we utilized or rather say reutilized the fire alarm cable as a communication line because it's already used everywhere in the industry. I mean, fire alarm industry. It's super durable. It can withstand two hours in direct exposure to fire but last but not the least, it's easy to maintain and in field technicians will be happy. Speaking on the open source summit, I have a chance to go a little deeper and explain some issues caused by the using third party open source software and how we overcome that. The whole system needs to be certified against two standards. UL2524, it's auxiliary radio communication systems to provide complete radio coverage for first responders and blah, blah, blah, blah, blah. And NFPA 1221, it's more about hardware and same about fire protection. They both have very aggressive and strict rules about system responsiveness and failure protection. Updates are also regulated and they have to be supervised. So there have to be a certified person at the time of update so there is no way of over there updates unattended. And they conduct all on-site supervision and functional tests after the update. So it's very strict, it's very annoying. And in order to certify all these tools, it's not a complete software stack. It's just to give you an overview how many different systems needs to be certified. Linux itself, it's a huge problem. Docker, Python, LoRa server, PostgreSQL server, it all becomes pain, really painful. So we did a smart workaround. Somebody may say we gave up, but we used a free toss hypervisor or better say watchdog in the system. And it turns down the IoT communication in case of any threat to the system's operation. So radio communications has a priority. We hope this will happen really rarely, rarely. And, but this is the only way we found to, found suitable for us to pass the certification. This is an option. Here I should give a reference to the last year's speech of Lukash Pulvan from BMW. So he explained certification problems with Linux way more detailed. So we have a stack. He explained Linux certification issues for 45 minutes. Okay, considering the life safety application, edge processing becomes essential in the system that decision making affects the safety of personnel or inhabitants. And it needs to be built around the resilient hardware and even better, it should be duplicated inside the facility. Business requirement is to make wiring logic for edge processing as easy as possible. We utilize Docker containers with restrictions to offer running arbitrary code in response to data received from LoRa sensors. For some applications, it's also required that we offload data, I mean raw data, receive from sensors locally. So we just provide it through Ethernet port into their facility room, something like that. So we just toss it into the network. I'll finish my speech with some conclusions. They are obvious and just repeating. So there is a need in technology change in building construction industry. And there is a demand for a reliable IoT network for the commercial applications. And while life safety experts are scared by wireless technologies, there is a big gap between what is allowed and what we need. And considering the fact that building owners already forced to deploy costly infrastructure, why not to get something useful out of it? And there is a measure that can be taken to reinforce your solutions. You can use something more reliable than regular CAT5 Ethernet cable like we did with Twisted Payor and GDTCHN technology. Backup power is as important as connectivity. If system stays operational during power outage, it's another feature to sell. And such systems should offer flexible edge processing, including local raw data offload because it's required for some applications by local jurisdictions. I can give you an example for what it was used. It also was used for entry log, so it logs who was entering the building. And that's it, I believe, for today. I really hope this speech will give you another topic to think about. And please feel free to ask your questions. I believe we have some time here. Do we? Any questions? How many buildings you have implemented or installed this solution? How much, how many? How many buildings you implemented this solution? Actually, this is a brand new solution. We have one test building in New York and two warehouses in Ukraine next to Kiev. We have 16 nodes in New York, deployed in New York in the single building, and it's two warehouses of five nodes in next to the Kiev. Anything else? Can you explain the hypervisor argumentation that you use for the safety certification? That's easy. If you have a system prone to a failure, it's easier to restrict it into the bounds where it cannot be failed, or if it fails, it won't affect the whole system functionality, the system health. So we used free RTOS. It detects a load onto the agitation line, and if it's overloaded more than 90%, it just sleeps. It sends a whole IoT data processing subsystem to a sleep mode. That's it. Not actually shut off. It collects data, it gathers it in a buffer, and then it sends if a network becomes free. So it's independent. They share adjusting closure. Anybody else? No? Thank you. You mentioned that Laura, the right technology, does not work well in the basement. I can get that. But you also mentioned it doesn't work well with higher levels. How come? Laura Hubs are generally installed on the rooftops. And in order to cover a whole building, imagine a 45-story building with a Laura Hub on the rooftop. And on lower floors, there is no Laura coverage at all. It's too much attenuation because of concrete floors, and that's it. Neighborhoods, they are covered. Yes. That's it. Any more? So I'm curious, using the twisted pairs, how sensitive are you to noise? How much noise can there be without problems? We are as sensitive as GDHN technology are. So it's resilient to power frequency, so 50, 60 hertz. It also can withstand being deployed next to the communication lines like Ethernet. So we're not tested that well. So it is as it is. It works well. We like that. And it wasn't ever a consideration for a life safety application. That's it. Hi, thank you. Do you also use the twisted pair cable to supply the nodes with power or is that an independent system? We wanted to do so. We wanted to use the same twisted pair for power delivery, but we had to use separate fire alarm power supplies that are provided each third floor. It's more efficient, and we have to monitor that fire alarm power supplies. So that's why we don't use the same cable for that. If nobody else wants to ask me a question, so thank you very much for an opportunity to speaking to you. It was really fun. Thank you. Thank you. Thank you.