Annex J BACnet/IP devices are designed to provide the way for BACnet systems to grow beyond building-wide or campus-wide internetworks. The author discusses how these new devices can help create systems that cover entire regions and even continents.
EDITOR'S NOTE: Last month the author provided
a look at the need and means for constructing wide-area building networks.
Discussed were Annex H.3 PAD devices, which can connect distant BACnet
building networks together over wide-area Internet Protocol (IP) internetworks
by enclosing BACnet messages within IP frames for transport across the
IP internetworks. Introduced was the concept of virtual networks, formed
when PAD devices communicate across IP internetworks. In this second and
final installment, the author examines Annex J BACnet/IP devices.
Annex H.3 PAD devices are the simplest way to connect BACnet networks over Internet Protocol (IP) internetworks, but they have a few limitations. One is that devices are not easily added or removed; the table of peer PAD devices must be changed in every PAD when the configuration changes.
For this reason and others, the IP Working Group of ASHRAE's BACnet Standing Committee (SSPC 135) developed a more extensive protocol, called "BACnet/IP," for connecting BACnet networks over IP internets. Devices incorporating this protocol are known as "Annex J" devices because this protocol has been added to the BACnet standard as Annex J.1
BACnet/IP is able to handle the transport of BACnet broadcasts over IP more efficiently than PAD devices; it allows devices to enter into the system from anywhere in the IP internetwork, and it supports "native IP" BACnet devices - devices such as unitary controllers which send and receive BACnet messages within IP frames instead of BACnet frames, effectively using IP internetworks, even wide-area internetworks, as BACnet local area networks (LANs).
Annex J defines a virtual network, called a "BACnet/IP network," similar to the virtual network used by PAD devices. This virtual network is comprised of a group of devices that communicate among themselves using the BACnet/IP protocol.
BACnet/IP devices may reside on different physical networks that are part of a larger IP internetwork, connected only by IP routers. Unlike PAD devices, BACnet/IP devices in the same virtual network may also be connected to the same physical network.
An aspect of IP used by Annex J is the combination of IP with other protocols to convey messages from one device to another across the internetwork. TCP/IP is the best known, though somewhat complex, combination. It works much like a telephone call: a connection is requested, established, and then bi-directional communications follows.
The simpler - but not as well known - protocol UDP/IP is used by both Annex H.3 PADs and Annex J BACnet/IP devices. It works like mail (or e-mail): a single message is sent off to a destination address without verification of delivery (at this) level).
UDP is an extremely simple protocol. It does little more than provide a 2-byte number, called a "UDP port," that informs the receiving system what message or protocol follows within the UDP/IP frame. The UDP port number 47808 (in hexadecimal, X'BAC0') identifies BACnet messages and is the UDP port used by PAD devices. BACnet/IP devices use this UDP port by default but may be configured to use a different number if necessary. Figure 1 shows the structure of a BACnet/IP message.
BACnet/IP devices scattered around an IP internetwork communicate directly with each other when reading data values, transferring files, or other direct device-to-device communications. They need some assistance, though, in sending BACnet broadcast messages, such as the BACnet "Who-Is" request2, over IP internetworks because IP networks do not as a rule allow BACnet-style "global broadcasts" (that is, broadcasts received by every device everywhere on the internetwork).
Broadcasting is an effective means for getting messages to many devices at once. However, experience has shown that in large internetworks, broadcasts can overwhelm devices because every broadcast message is processed by every device that receives it. For this reason, network administrators normally disallow global broadcasts.
Broadcasts are allowed, but as a rule are restricted to "IP subnets3." (Note: Discussion of IP subnets is beyond the scope of this article, but it is helpful and fairly accurate to consider a broadcast as being restricted to an individual network.) The problem to be solved is how to deliver the global broadcast BACnet messages to all BACnet/IP devices on all subnets in the virtual network.
The IP Working Group developed two solutions to this problem and defined them in Annex J. The first is called "multicasting," and the second is called a "BACnet/IP Broadcast Management Device" (BBMD).
FIGURE 1: Structure of a BACnet/IP message.
Multicasting uses a special kind of broadcast that only designated devices will receive, thus avoiding the burden placed by normal broadcasts on all the rest of devices on the internetwork. A multicast message has a special form of destination address called a "multicast address." IP multicast addresses are in the range from 184.108.40.206 through 220.127.116.11.
A multicast message is transmitted throughout the internetwork but it is only received and processed by devices configured to receive messages sent to that particular multicast address. (Of course, they also receive messages sent to their own individual IP addresses.)
Multicasting has its disadvantages, though. Network administrators sometimes prohibit its use, IP routers usually need to be configured to forward the multicast messages, and support for multicasting is optional for BACnet/IP devices. There should also be consideration for the time when new and different devices are added to a system because BACnet/IP devices that use multicasting cannot be on the same subnet with devices that do not use multicasting.
FIGURE 2: BACnet/IP router.
The BBMD directly forwards a BACnet broadcast message initiated by a BACnet/IP device on its subnet to the other subnets with BACnet/IP devices. Upon arrival at a destination subnet, the message is then broadcast on that subnet.
There are two methods available to the BBMD to broadcast a message on a remote subnet. In the "directed broadcast" or "one-hop" method, the message has a destination address which causes the IP router to the destination subnet to broadcast the message on that subnet. If the router will not perform that broadcast, the "two-hop" method must be used. Here the message to be broadcast is sent to the peer BBMD on the destination subnet. The peer BBMD then broadcasts the message on its subnet. Figure 2 shows both methods in Virtual Network #2.
Every subnet with BACnet/IP devices must have a BBMD in order for broadcasts from devices on that subnet to reach the rest of the BACnet/IP devices in the virtual network.
The BBMD keeps a table, called a "Broadcast Distribution Table," which lists all the BBMDs, including itself, in the virtual network. This table, identical in all the BBMDs of a virtual network, also tells which broadcast method, one-hop or two-hop, is to be used in each destination subnet.
The BBMD does not need to be a physically distinct device. Like the PAD, it can be integrated into a device that performs other operations, such as a building controller.
FIGURE 3: Routing between BACnet/IP networks with BBMDs.
BBMDs also solve the problem of forwarding BACnet broadcasts to devices, such as an operators' laptop workstation, that might attach to the IP internetwork on subnets that do not have BBMDs or multicast routing. The means by which these devices arrange to receive the broadcasts is called "foreign registration."
In foreign registration, the "foreign device" (which is the device that wishes to receive BACnet broadcasts) sends a request to a BBMD. It will then receive copies of the forwarded BACnet broadcasts for a specified time, extending that time by periodic (automatic) renewal requests.
Non-broadcast communications (such as file transfers or reading and writing data values) between the foreign device and BACnet/IP devices are conducted directly, without BBMD assistance.
A BBMD may even be necessary in a multicasting installation. If a remote device that does not support multicasting is to connect to the system, or if it is to connect from a part of the internetwork where multicast messages are not routed, in order to receive broadcasts it must register with a BBMD that supports multicasting and that is located somewhere in the internetwork where multicast messages are routed.
FIGURE 4: Mixing BACnet and BACnet/IP devices.
MULTIPLE NETWORKS AND BACNET/IP
It is possible to build a single, very large virtual BACnet network over an IP internetwork. Annex J observes that this may be undesirable for several reasons, including overall traffic volume and system security. In such cases, it is preferable to create multiple BACnet/IP virtual networks and interconnect them into a larger "BACnet/IP internetwork."
To interconnect the BACnet/IP networks, a device called a "BACnet/IP router" is required, as shown in Figure 2. This device has all the capabilities of a standard BACnet router4, but it communicates using BACnet/IP frames. In an installation, the BACnet/IP router must also support the broadcast management method in use in the installation, whether multicasting or BBMD forwarding.
If multicasting is being used, each BACnet/IP network should use a different multicast address to carry its BACnet broadcasts.
If BBMD forwarding is being used, the BACnet/IP router has two options for operation. If it incorporates BBMD capabilities as well as routing, it can be included into the Broadcast Distribution Table for each BACnet/IP network. (The BACnet/IP router needs a separate table for each BACnet/IP network to which it is connected.) Otherwise, it must register as a foreign device with a BBMD on each of the BACnet/IP networks. Both configurations are shown in Figure 3.
If the BACnet/IP Router is capable of both BACnet and BACnet/IP communications, and is able to communicate using both BACnet frames and IP frames, it is called a "BACnet-to-BACnet/IP router." It may also be used to route messages between a network of normal BACnet devices and the BACnet/IP internetwork.
MIXING BACNET AND BACNET/IP DEVICES
BACnet, BACnet/IP, and PAD devices can all operate together in a BACnet/IP network but three rules must be observed.
The first rule is that BACnet and BACnet/IP devices cannot communicate directly with each other. Their messages must be routed through a BACnet-to-BACnet/IP router, as shown on the bottom network in Figure 4. If both BACnet and BACnet/IP devices exist on the same physical network, such as an Ethernet, that network has two BACnet network numbers: one for the BACnet devices and another for the BACnet/IP devices.
The second rule is that BACnet/IP devices cannot communicate directly with PAD devices. To join BACnet/IP devices to a system using PADs and BACnet devices, a BACnet-to-BACnet/IP router must be on the same directly-connected BACnet internetwork as one of the PADs, as shown in the middle network of Figure 4.
The third rule is that the BACnet requirement of a single path between any two devices is met if the BACnet message does not have more than one path through BACnet and BACnet/IP routers between any two BACnet and BACnet/IP devices.
The rapidly increasing use of wide-area IP internets provides an excellent opportunity to expand the reach of BACnet systems. Annex H.3 PAD devices and Annex J BACnet/IP devices provide the way for BACnet systems to grow beyond building-wide or campus-wide internetworks, to create systems that cover entire cities, regions, countries, and even continents.
1 Annex J, approved as Addendum 135a to the BACnet standard, may be found on the BACnet website at www.bacnet.org.
2 See "The Language of BACnet," Engineered Systems, July 1996. "Internetworking with BACnet", Engineered Systems, January 1997.
3 A full explanation of IP addressing ande dsubnets can be found in books on TCP/IP. Another reference is on the Internet at www.3com./nsc/501302.html.
4 "Internetworking with BACnet", Engineered Systems, January 1997.
Swan is BACnet specialist at Alerton Technologies, Inc. (Redmond, WA). He can be reached at email@example.com. Swan is secretary of the ASHRAE BACnet Standing Committee, SSPC 135, and serves on an ISO Technical Committee (ISO/TC 205/WG 3) developing an international building automation communications protocol.