Security & Sensor Reliability

LCS Operations over IR

As for security, the security is implied by having

  1. A proprietary OR Dongle

  2. Secure access level restriction and approval mechanism

IR message length < 40 bits, with limited message set and bandwidth, makes it impossible to access the network through IR. The Infrared messages that can be accepted by the system have specific string length with CRC checks. Any extra messages are neither accepted nor understood thus can't be acted upon. The messages that change the configuration parameters or can define the new automatic method of operations is only injected in the system through OR app or when the gateway comes into picture which has their own security measures in place.

In general, we categorise the modes of attack into: 

  1. Stealing data

    • There is no possibility of stealing data as we don't store any data. All communications are in real-time and the control happening is also based upon peer-to-peer communication of occupancy if not detected by it's own sensor.

  2. Controlling lights

    • Controlling lights is possible only if someone has access to the site, the dongle, and the app with approved credentials to have the correct access levels. In case all these conditions are met then to reduce the impact of this outcome, the feature, Emergency Mode, available in firmware v162 and above, can be initiated from the app locally by users or the gateway by ORT, and will cause all lights to go to their maximum light output for 90 minutes. Once in emergency mode there is no way to exit it, meaning an attacker, even with full access, will not be able to control the lights and the users have time to take the necessary steps to resolve the problem.

  3. Corrupting configuration

    • Possible with configurator access, the dongle, and physical access to the site. The access level is approved only by OR Technologies or managers approved by OR Technologies. The access from a user to the app is logged with time and can be revoked if reported upon authentication.

Connectivity over Wireless Mesh RF

  • Wirepas Mesh Protocol - use end to end encryption and each network of wirepas has 2 128-bit AES keys. Sensor nodes themselves are tamper-resistant. A network of wirepas is made automatically for only those sensor nodes with correct security keys.

  • Connection to the Cloud - Gateways send and receive data to and from Amazon Web Services' (AWS) IoT service (portal for example). Each gateway ships with a unique ID that is used to establish an AES-128 encrypted SSL connection with the cloud. The management of authorization is handled by AWS as each gateway is shipped configured to a unique ID.

  • The Cloud - All data is stored in the AWS cloud, which complies with the relevant regulations and is used in finance, healthcare, and government applications. Our database servers are completely isolated from the Internet within a 'Virtual Private Cloud' and may only be accessed via our web servers. Any request that is made to our servers is authenticated through LinkedIn OAuth and can only be performed if the user has been given permission to make such requests on that building.

  • Access Control - As a Portal customer, you have the ability to manage the list of users who have access to your buildings using a fine-grained permission scheme that lets you authorize users for only the actions that they are required to do, such as doing analytics or managing schedules

Solution and Protocol

Lighting control and operations are driven independently as well as collectively using IR communication between sensor nodes. All connected solutions and arising developments thereof make use of RF Wirepas Mesh an industry grade protocol.

  • The operational layer of IR is independent of Wirepas mesh and can work autonomously.

  • BACnet is localized solution and doesn't require cloud access for it's operation while the deployment requires initial cloud access for IoT gateways.

  • The Portal utilizes Wirepas Mesh to establish network and is followed with connection to the cloud and further access control restriction which are available in the portal.

  • An API which allows third party integrations is built upon portal. The API access is reliant upon Wirepas Mesh, connection to the cloud for IoT gateways and further managed through tokens.

RF and IR Signal Frequencies & Strength

The table below gives RF (Radio Frequency) and IR (Infrared) signal information.

RF signal Frequency

Organic Response use 2.4GHz just like other systems and we can co-exist with other 2.4GHz networks. The exact Radio Frequency used is 2400 to 2483 MHz

RF signal Strength

Max. Output power: +4dBm

IR signal Frequency

IR Centroid wavelength: 940 nm (318928GHz)

IR signal Strength

Radiant intensity, 760 mW/sr (typ), 1120 mW/sr (max)

For more details please refer to relevant data sheet for the product.

Sensor Node Reliability

  • Sensor Nodes Failure Rate
    Note that as the SN3 is a new product in the field, We can refer to the previous generation of Organic Response Sensor on which the SN3 is heavily based. For that generation of sensors (SN2.2), we have not had a single sensor fall-out. Most of the fall-outs we have had from the past are due to the older version of the controllers (P1 or earlier) which were damaged due to surges/transients from the mains. Not to mention the current versions at most installations or even in partner manufacturers' stock is P2 which has had no failures. The new SN3 sensor represents an integrated version of the SN2 and Controller P2 plus an RF interface. This effectively designs out the controller to remove the interface with the mains and to avoid having the same fall-outs we saw from the previous generation.

  • Regarding the fail rate for the controller units for the previous generation - we previously saw a fail rate of about 0.367% (P1 versions), with all of these failures due to surges/transients. As noted above, by removing the Controller in the latest SN3 generation of Organic Response, this exposure of risk has been significantly reduced.