Home
The BACnet Masquerade Router (BMR) application is a BACnet router between one or more BACnet/IPv4 networks and Virtual Local Area Networks (VLAN) of virtual BACnet devices (VDB). The virtual devices masquerade as a "digital twin" of real devices, masking some objects and properties and making others available.
The principle use of this application is to help collect together into one unified BACnet network a collection of other BACnet intranetworks that have overlappng BACnet device identifiers and network numbers and therefore cannot be directly connected.
In some cases these other networks, referred to in this project as "sites", have developed independantly of each other with no cooperative administration or they are "clones" of each other where their was no guidence on making non-overlapping device identifiers and network numbers.
In its simplest form, a Virtual BACnet Device (VBD) is just a reference to a BACnet device on a network. Application layer traffic that is sent to a VBD is forwarded to the referenced address and the cooresponding responses are returned to the source of the request.
A Virtual Local Area Network (VLAN) is a collection of Virtual BACnet Devices that are in a BACnet network which implies they can communicate directly with each other (there are no interveining routers) and they are all in the same broadcast domain (a local broadcast by one device reaches all of the other devices).
To participate in a VLAN, a VBD must have an address that is distinct from the other VBDs on the same VLAN. The addresses are 1-octet, reflecting MS/TP and ARCNET networks.
To associate a VBD with a VLAN, the VDB is configured in a Virtual Device Group (VDG). The VDG creates a BACnet network context for the VBDs to appear on a BACnet network via a router. The BACnet router for the group filters the traffic coming into the BMR to just those addresses that are mapped to VBDs, and similarly filters the traffic from the VLAN to mapped devices.
This section shows an application of the BMR starting from an initial condition of disconnected BACnet networks, showing how they are integrated, and some ways that communication flows between the components.
Slide 1
The two sites in this drawing have been developed separately, Site A is considered a supervisory site and Site B is one of the possibly many sites that are being supervised. This collection of applications allows a workstation at Site A to issue requests to site B as if it was a locally connected device.
Slide 2
The two sites are "connected" by sharing an MQTT broker that is accessable to both. There is no requirement that the broker is hosted at any particular site, it could be one of the free MQTT brokers running in a virtual machine on a hosting service or an IoT hub provided by a cloud service.
Secure communications between the sites requires encrypted connections to the broker.
Slide 3
This suite of applications uses the MQTT publish/subscribe protocol to emulate a local area network. This is an evolving standard being developed with the BACnet IT Working Group along with the previously announced BACnet Secure Connection (BACnet/SC) which uses web sockets. The messages going to and from the broker are wrapped in a BACnet Virtual Link Layer header similar to BACnet/IPv4 and BACnet/IPv6.
There is a special MQTT client "sniffer" application which understands the publish/subscribe patterns used by BACnet/MQTT and can also decode the network and application layer messages inside.
$ python3 sniffer.py --help
usage: sniffer.py [-h] [--buggers] [--debug [DEBUG [DEBUG ...]]] [--color]
[--lan LAN] [--host HOST] [--port PORT]
[--keepalive KEEPALIVE]
The --host parameter is the IP address or DNS name of broker and defaults
to "test.mosquitto.org" which may not be running continuously and may
occasionally have performance problems and should only be used for testing.
The lan, --port and --keepalive parameters are used to identify the
network topic name for the network (it is possible to have multiple virtual
networks on the same broker) and the TCP connection parameters.
Slide 4
This suite of applications comes with a BACnet/IPv4 to BACnet/MQTT router. This is very similar to other BACnet routers, it simply repackages BACnet traffic from one network to another.
$ python3 mqtt2ip.py --help
usage: mqtt2ip.py [-h] [--buggers] [--debug [DEBUG [DEBUG ...]]] [--color]
[--host HOST] [--port PORT] [--keepalive KEEPALIVE]
lan addr1 net1 addr2 net2
The lan, --host, --port and --keepalive parameters are identical to the
sniffer application.
The addr1 and net are the local BACnet network parameters such as
10.0.1.15/24 and 1 for the drawing. The addr2 and net2 parameters are
for the virtual MAC address and network number, for example 0x010203 for the
address and 2 for the network.
The BACnet/MQTT proposal uses 3-octet addresses and will probably change before publication.
Slide 5
The BACnet Masquerade Router (BMR) application is introduced at Site B and has a large number of configuration parameters. It is divided into "inside" and "outside" parameters, the inside settings govern the way the application works with BACnet devices in the site, the outside settings contain information that is presented to the broker.
In this slide, the BMR application has a connection to the broker and is a router to a virtual network number 3. This network topology, the "outside topology" is relative to Site A and is presumably managed by the Site A network administrator. The virtual network for each subsequent site must be unique.
Slide 6
On the virtual network there is a Virtual BACnet Device (VBD) that represents a "digital twin" of an actual BACnet device on the inside network. It is configured with an address on the virtual network (a number in the range 2..253) like an MS/TP or ARCNET address and the BACnet address of the real device.
Slide 7
There can be a large number of VBDs on the network and the mapping to site specific devices is independant of the inside network topology.
Slide 8
The BMR has an additional device which appears as a local device on inside network and is configured with a device instance number and address that are appropriate for communicating with peer devices. It has no objects (other than a device object required by BACnet) and strictly acts as a client.
Requests received by the BMR from the broker for virtual devices will be re-issued as requests from this local device. There is no information about the virtual device, the MQTT traffic, or the configuration or source of the original request in the local traffic.
Slide 9
The Who-Is BACnet service is to associate a device with an known identity to a network address. The device identifier is a 22-bit unsigned integer that is unique to the entire BACnet intranet and usually does not change in the lifetime of the device. As BACnet networks grow the topology is occasionally updated to reflect changes in performance and security requirements.
The Who-Is is a broadcast service, sent out to all devices on a local network or to all devices in the BACnet intranet. In this scenerio, it is being sent as a "global broadcast." The request goes from the workstation to the IPv4/MQTT router.
Slide 10
The router receives the broadcast and by looking in the network layer header, also called the Network Protocol Control Information or NPCI, see that the request should be forwarded to the MQTT network. It takes the message, wraps it in a specific BVLL envelope and sends it to the broadcast topic on the broker.
The broker receives the publication request and sends it to all of the connect clients that hae subscribed to the topic, in this case the sniffer application and the BMR.
Note that the router also receives a copy of the message because it also subscribes to the broadcast topic and it recognizes that it is a reflection and drops the packet.
Slide 11
The BMR receives the broadcast Who-Is request, and like all other BACnet routers, also forwards it to all of the virtual devices in its internal virtual network.
Slide 12
If one or more of the virtual devices match the request because its device identifier is within the range of the request, it constructs an I-Am response and sends it back to the requestor.
First the packet travels along the internal virtual network back to the BMR router function.
Slide 13
The BMR sees that the response should go back to a device on network 1, so it wraps the response in a BVLL envelope and publishes on the topic specific to the IPv4/MQTT router.
The broker receives the request and forwards it to the router. In this case, the sniffer application also receives the message because it has subscribed to all of the topics in the BACnet network, but it doesn't process the packet other than decoding it for display and/or logging.
Slide 14
The router receives the request and sends it to the workstation as a unicast message. There are some older BACnet devices that broadcast their I-Am messages in response to a broadcast Who-Is but those are falling out of favor as networks grow larger and broadcast traffic should be kept to a minimum.
The I-Am response is from the virtual device and not the real device.
Slide 15
This scenerio is a Read Property request for some information from the real device, perhaps the current value of an analog or binary value object. The workstation knows the network address of the virtual device but does not know the address of the device inside Site A.
The workstation sends the request to the virtual device by simple BACnet protocols, in this case BACnet/IPv4 to the router, BACnet/MQTT from the router to the BMR, and internally the BMR sends it to the virtual device.
If this request was for the Object Identifier of the Device Object in the virtual device, the response would be provided immediately.
Slide 16
The virtual device stores a reference to the request in its internal table, then re-issues the request to the real BACnet device by giving it to the internal device application.
Slide 17
The internal device application sends the request to the real device and as far as the real device is concerned, the BMR is just a simple BACnet client. The request travels through the BACnet network of Site A as all other BACnet traffic.
Slide 18
The real BACnet device satisfies the request by sending back to the BMR a Read Property Ack. The response path is the same as the request path like all BACnet traffic.
Slide 19
The inside application in the BMR lines up the response with the request and the virtual device that issued it and sends it to the virtual device for more processing.
Slide 20
The virtual device updates the response with the appropriate workstation request identifier and address and sends the reponse back through the MQTT network to the router, where it is then forwarded to the workstation.
Slide 21
All BACnet traffic to the BMR that is not initiated by the BMR, for example device-address-binding and Read Property requests for information from the inside device application, will be returned directly to the requesting device. There is no BACnet traffic that can exit Site A through the BMR as a request.
For Change-of-Value subscriptions and notifications, and Alarm/Event reporting, there will be special filtering to allow those messages back out to the MQTT network.
Slide 22
This collection of applications can accommodate multiple supervisory sites such as network 4 in Figure 22 above. All of the devices on network 1 and 4 are available to each other as peers.
There can be multiple instances of the BMR application on different sites (or even on the same site which can become difficult to manage) and each will get its own network number as network 5 in the figure.