IAP Creates a Better LoRaWAN Solution for Smart Buildings

Commercial building occupants expect some level of intelligence and automation in their facilities, and real estate owners are racing to deliver via IoT. Maybe that explains why the compound annual growth rate for the building automation and control market is expected to grow more than 21 percent through 2028. After all, facilities IoT is how you reach the promised office of the future—and recent trends are making smart buildings more of a requirement than a perk. 

Companies have energy goals; IoT helps meet them with automated control over HVAC, lighting, and more. The rise of remote work has led to lots of unused facility space; IoT can identify these spaces, personalize them for temporary users, and provide data on how to optimize every square foot.  

Given these market forces, the question isn’t whether to invest in smart building technology—it’s how to do so in a way that provides a strong return on that investment and supports devices using both wired and wireless communication. The Long Range Wide Area Network (LoRaWAN) protocol is a promising solution for wireless devices that require less power than WIFI devices, but have longer range than Bluetooth devices. Administered by the open, nonprofit LoRa Alliance, LoRaWAN creates low-cost, low-power, long-range wireless connections between smart building devices and the platforms they work with. 

The trouble is, integrators struggle to connect LoRaWAN devices to legacy wired building automation and control systems (BACS). The new IoT Access Protocol (IAP) solves the problem. Here’s how.    

The Struggle to Connect LoRaWAN Devices to Legacy BACS

Any mid-sized or larger building most likely has a BACS with devices using wired communication—and that BACS is not designed to keep up with pace of innovation in IoT. For decades, operators have used these legacy BACS platforms to manage all the technologies within the building: HVAC, lighting, access control, security, elevators—all systems that gain considerable utility with the addition of IoT. 

If you want to expand building automation, you have to transmit data from each discrete IoT device to the BACS. But there’s a mismatch between the LoRaWAN standard and common BACS network protocols. The connectivity protocols your BACS understands—BACnet and LON, just to name a few—are very rich standards. They have rich data models, specify network services, and provide command-and-control capabilities —and these are all strictly defined within the BACS architecture. 

LoRaWAN doesn’t line up natively with all these BACS definitions, so it’s hard to create a strong integration. Until recently, smart building integrators connected LoRaWAN devices to legacy BACS using one of two approaches, neither of which is ideal: 

• Manual data-point mapping. First you connect a LoRaWAN device to a LoRa network server. Then you map each data point in the server to a corresponding point in the BACS. The difficulty arises on the BACS side, where you must manually configure automation algorithms—including the definition and configuration of the basic meanings of data points. You must tell the BACS that a temperature reading is an indoor space temperature reading, for instance, and create an algorithm that tells the system what to do with that data point. It’s a lot of resource-intensive and time-consuming manual configuration by the building system integrators. 
• The Static Context Header Compression (SCHC) protocol. If you’d rather not hard-code data mapping on the BACS  side, SCHC may be able to help. This compression framework stuffs an entire BACnet message inside a LoRa packet. That transfers a full end-to-end BACnet object property from the device to the BACS. The definition of the data point is built in. There’s just one problem: Integrators can’t implement SCHC on their own. The protocol has to be built into the device, which means only the device manufacturer can make it happen. Worse still, SCHC smart building devices are more complex, and therefore more expensive, than simple LoRaWAN sensors—assuming someone’s manufacturing them in the first place. If there are a few manufacturers, with today’s supply chain disruptions it is very likely that such scarce devices will have 6-to-12-month lead times.

Neither of these approaches supports intelligence in IoT edge devices; all the data operations take place at the BACS level. They also only support BACnet, the dominant communications protocol in building automation and control. If some of your IoT infrastructure relies on LON, or Modbus, or DALI for lighting controls, or industrial Ethernet protocols for factories—you’re out of luck. Luckily, a third option is now available, and it’s poised to make the job much simpler for smart building integrators.  

Meet the IoT Access Protocol (IAP) for LoRaWAN Integration with BACS

IAP, recently standardized through ANSI and CTA, is a platform-agnostic data and services access protocol that generalizes definitions of information, data models, and services for industrial IoT devices. More simply, it creates a data and services fabric that connects all the elements in your smart building infrastructure—including a common model for the information and services provided by the edge devices in the building automation and control network. Install an edge server with IAP to translate and normalize data from LoRaWAN devices into a system with BACnet, LON, Modbus, or virtually any other BACS protocol, and access the data and services from all the devices from workstations using BACnet, LON, or OPC UA. 

IAP creates a digital twin of your devices. Each twin is accessed by the BACS via any BACS protocol of choice, translating LoRa into a language the BACS can understand. If you set an IAP server to include a BACnet server, your BACS will recognize a LoRaWAN device as a BACnet device; it’s that simple. No more clunky manual integrations, hard coding, or begging device manufacturers to support SCHC. With some of today’s IAP edge servers, integrators can even create LoRaWAN-to-BACS integrations in a low-code environment, with a simple user interface and drag-and-drop tools. 

Even better, IAP is intensely scalable. If you install it in one of your facilities, you can use the same device and data point configurations in all of your facilities, just by installing the IAP edge server. And edge servers with IAP get results. Just ask UK furniture retailer DFS, who used IAP edge servers to connect environmental sensors (and more) to BACS platforms in multiple facilities. The open, multi-protocol system helped to reduce DFS’ energy use, saving around 33 percent of electricity costs and 26 percent on gas for a typical retail store with the system. If you’re looking for similar results—and you don’t feel like manually configuring and hard-coding a legacy BACS—look into IAP. It could be the LoRaWAN/BACS integration tool you’ve been waiting for.