{
	"id": "a83a3106-b62b-4ce8-a950-34f0b71cf07c",
	"created_at": "2026-04-29T02:20:54.196007Z",
	"updated_at": "2026-04-29T08:21:15.886802Z",
	"deleted_at": null,
	"sha1_hash": "384feeeb1c161862c51b75df5b1fae8056ecdc69",
	"title": "",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "2010-10-20T15:07:02Z",
	"file_modification_date": "2010-10-21T07:55:21Z",
	"file_size": 717160,
	"plain_text": "B 8 \t \t B A C n et ® To d a y | A Su p p l em e nt to AS H R A E Jo u r n a l \t \t N o v em b e r 20 1 0\r\nAbout the Author\r\nH. Michael Newman is manager of the Building\r\nAutomation and Control Systems Integration group\r\nin the Facilities Operations department at Cornell\r\nUniversity in Ithaca, N.Y. He was chair of the BACnet\r\nCommittee from 1987 until 2000 and is chair of the\r\nASHRAE Standards Committee.\r\nBy H. Michael Newman, Fellow ASHRAE\r\nBroadcasting is not evil. The concept of sending messages to all\r\npossible recipients on a network is a normal and extremely useful\r\ntechnique that is used by many different protocols, not just BACnet. Some\r\nof the most common network architectures, for example, the Internet Pro-tocol (IP) on an Ethernet Local Area Network (LAN), would be incredibly\r\nhard to set up if it were not for the availability of broadcast messaging.\r\nsage intended for a particular group of\r\nmachines is called a “multicast” mes-sage. Each machine must be given its\r\nunicast address but knows, by virtue of\r\nits LAN type, what its broadcast address\r\nis. If a machine is also a member of a\r\nmulticast group, that too must be con-figured into the device by some means\r\nor other. For the purpose of this article,\r\nwe’ll focus on unicast and broadcast\r\nmessages.\r\n So how do LANs actually work? On a\r\nLAN, all devices are physically “within\r\nearshot” of each other, i.e., they all share\r\na physical communication medium and\r\ncan hear all the traffic on the network. At\r\nleast that is the traditional notion. Today,\r\nwith intelligent switches (that “learn” the\r\naddresses of the devices attached to them),\r\na device may only hear traffic with its\r\nunicast address and broadcast messages.\r\nIn any case, a device on a LAN can only\r\ndirectly communicate with other devices\r\non the same LAN. For Device A to send\r\na message to Device B, it must know the\r\nLAN address of Device B.\r\nBut how does Device A find out the\r\nLAN address of Device B? There are\r\nonly a few ways to do it. One is to have\r\na local database that contains a list of all\r\nthe devices and their addresses, a kind of\r\n“phone book.” Since most devices have a\r\nsymbolic name, the table would really be\r\nlike a phone book. Another way would be\r\nto send a message to the preprogrammed\r\naddress of an address server, like call-ing directory assistance by dialing 411.\r\nIt would be up to the address server to\r\nmaintain the table of names and addresses.\r\nBoth of these techniques require that the\r\ntable be created by someone, somehow.\r\nThe last technique, and the one most\r\ncommonly used, is to broadcast a request\r\nasking for the desired address. All the\r\ndevices hear the request but only the one\r\nthat is being requested answers, sending\r\na unicast message to the requester with its\r\nown LAN address in the sender field. At\r\nthat point, the two machines can converse\r\nat will. The beauty of this technique is that\r\nno address tables or databases need to be\r\nestablished and maintained.\r\nBut wait! I hear you saying “What do\r\nyou mean my computer can only talk to\r\nBroadcasting BACnet®\r\nIt is true that broadcasting, if not prop-erly managed, can cause problems. But\r\nthis is also true for many other network\r\ncharacteristics (address assignments,\r\nnumber of shared data points, point\r\nnames, and so on). Still, broadcasting is\r\noften singled out as “problematic” even\r\nthough, properly managed, it is not. This\r\narticle will explain how broadcasting is\r\nused in BACnet and how to solve prob-lems should they occur.\r\nSome Networking Basics\r\nBefore we begin, a brief review of some\r\nfundamental network concepts may be\r\nhelpful.\r\nFirst, for computers to communicate\r\nthey must know each other’s “address,”\r\na numerical value assigned to each ma-chine which must be unique on a given\r\nLAN. A message sent from one machine\r\nto another is called a “unicast” message.\r\nA message intended for all machines is\r\ncalled a “broadcast” message. A mes-This article was published in ASHRAE Journal, November 2010. Copyright 2010 American Society of Heating,\r\nRefrigerating and Air-Conditioning Engineers, Inc. Posted at www.ashrae.org. This article may not be copied\r\nand/or distributed electronically or in paper form without permission of ASHRAE. For more information about\r\nASHRAE Journal, visit www.ashrae.org.\n\nN o v em b e r 20 1 0 \t B A C n et ® To d a y | A Su p p l em e nt to AS H R A E Jo u r n a l \t B 9\r\nother devices on the same LAN? My computer is on an Eth-ernet LAN, and I can communicate with devices all over the\r\nworld!” That may be true but to do so, it sends its messages\r\ndestined for computers not on your LAN to a special computer\r\nthat is connected to both your LAN and some other network.\r\nAlso, your message has to contain some kind of address for the\r\ndestination machine that the special computer can use to send\r\nyour message. If the address is an IP address, then the “special\r\ncomputer” on your LAN is called an “IP Gateway.” Note that to\r\ncommunicate with the IP gateway, its IP address has to be known\r\nand added to your IP protocol information at configuration time.\r\nTo find the LAN or “Medium Access Control” (MAC) address\r\nof the IP gateway, your computer uses the broadcast mechanism\r\nmentioned previously, which in the case of an IP device on an\r\nEthernet network, is called the “Address Resolution Protocol”\r\n(ARP). This protocol is also known as RFC 826 (sidebar on\r\nCreation of the Internet Protocol).\r\nIncreasingly, for mobile computers such as laptops, another\r\nwell-known broadcast method is used called the “Dynamic Host\r\nConfiguration Protocol” (DHCP). In this case, the initiating\r\ndevice does not know its own IP address or IP gateway address.\r\nIt broadcasts a message saying, essentially, send me my IP con-figuration details and, if there is a DHCP server that hears the\r\nrequest, a message is sent to the requesting device that allows\r\nit to configure itself.\r\n BACnet Networks\r\nNow, let’s talk about BACnet. At the BACnet committee’s\r\nearly meetings in the late ’80s we had intentionally deferred\r\nthe question of how BACnet messages would be conveyed. We\r\nfocused, rather, on the content and format of the messages since\r\nwe knew that networking technology was changing rapidly.\r\nThe discussions on message transport continued up until the\r\nlast moment. When BACnet was finally published in 1995, it\r\nincluded clauses on how to use four different LANs: Ethernet,\r\nARCNET, LonTalk and Master-Slave/Token-Passing (MS/TP).\r\nThe use of IP as a “virtual LAN” was not completely specified\r\nuntil Addendum a, which was also published in 1995, shortly\r\nafter BACnet itself. The important thing to understand is that a\r\nBACnet “internetwork” is a collection of two or more of these\r\nLANs, which may consist of different LAN types, each of which\r\nis called a BACnet “network.”\r\nEach LAN type has its own address format and protocol con-trol information (PCI), the latter being items such as message\r\nlength, error check digits, and so on. On Ethernet LANs, for\r\ninstance, each device has a 48-bit unicast address that ranges\r\nfrom 0 to approximately 2.8 × 1014. The address, made up of 48\r\n1-bits, is the broadcast address for Ethernet. On an ARCNET\r\nLAN, a unicast address is an 8-bit number between 1 and 255.\r\nAddress 0 is interpreted to be the broadcast address and messages\r\nwith 0 in the destination field must be processed by all machines\r\non the LAN. LonTalk and MS/TP also use 8-bit addressing with\r\nthe broadcast address being 0 and 255, respectively.\r\nIf a BACnet system consists of only a single network, life\r\nis simple. Device-to-device communication uses the unicast\r\naddress and broadcasts use the broadcast address. But what\r\nif there is a need to interconnect multiple networks? How do\r\nThe Internet was created in the late ’70s and early ’80s\r\nby a group of engineers and computer technicians who were\r\nworking on projects for the government’s Defense Advanced\r\nResearch Projects Agency. They needed to collaborate and,\r\nalthough they had computers, they had no established way\r\nof networking them.\r\nSo this early work to establish networking standards took\r\nthe form of discussions by mail, telephone, fax and face-to-face meetings that led to varying degrees of consensus on\r\nhow to solve the problems. This, in turn, led to someone taking\r\non the task of writing up the various possible solutions in the\r\nform of specifications known as a “Request for Comment” or\r\nRFC. The RFCs were then circulated within the community and,\r\neventually, became the law of the Internet land.\r\nThe Internet Protocol itself, for example, is also known as\r\nRFC 791 and was adopted in 1981. Other protocols men-tioned in this article are also RFCs: the Address Resolution\r\nProtocol (ARP) is RFC 826; the Dynamic Host Configuration\r\nProtocol (DHCP) was originally RFC 1531 but has been su-perseded twice. The latest version is RFC 2131. All of these\r\ncan be found on the web by entering “RFC” into any browser\r\nor at www.faqs.org.\r\nBut RFCs are not exclusively about 1’s and 0’s. Every so\r\noften one encounters a philosophical insight worth pondering.\r\nFor example, the problem statement in RFC 826 contains this\r\ngem: “The world is a jungle in general, and the networking\r\ngame contributes many animals.” No wonder networking can\r\nbe confusing at times!\r\nCreation of the Internet Protocol\n\nB 1 0\t \t B A C n et ® To d a y | A Su p p l em e nt to AS H R A E Jo u r n a l \t \t N o v em b e r 20 1 0\r\nmessages, whether unicast or broadcast,\r\nget from one to the other? Given that\r\nARCNET and MS/TP networks only\r\nhave 254 unicast addresses available,\r\nwhat if there is more than one device\r\nwith a particular address? This is like a\r\nhouse with a street address of “100 Main\r\nStreet,” of which there are many in the\r\nU.S. The answer, both for sending mail\r\nand for sending computer messages, is\r\nthe same: add some additional piece of\r\ninformation that makes the address of the\r\nhouse or the computer unique. For the\r\nhouse, we can use a “zip code;” for the\r\ncomputer, we use a “network number.”\r\nThe network number and MAC address\r\npair uniquely specifies the address of a\r\nBACnet device.\r\nSo every BACnet network has a net-work number that must be unique within\r\nthe internetwork. To get from Network 1\r\nto Network 2, there needs to be a device\r\nthat is connected to both. These devices\r\nare called “routers” and their functional\r\ndetails are defined in Clause 6, The Network Layer, of BACnet\r\n(Figure 1). Whereas the BACnet application layer protocol\r\ncontains information about building automation and control\r\nfunctions (the subject of other discussions), the BACnet net-work layer protocol contains information about routing from\r\none network to another.\r\nThe most significant elements of the network layer PCI are the\r\nsource and destination network numbers, known as the “SNET”\r\nand “DNET,” respectively, and the source and destination device\r\nMAC addresses, known as the “SADR” and “DADR.” Clause\r\n6 also defines the three types of BACnet broadcasts: “local,”\r\n“remote” and “global.” A local broadcast is received by all de-vices on the local network. A remote broadcast is received by\r\nall devices on a single remote network. A global broadcast is\r\nreceived by all devices on all networks comprising the BACnet\r\ninternetwork.\r\nBACnet Routing\r\nTo send a unicast message to a device on its own LAN, the\r\nsender simply omits the network layer address information\r\nand sends the message to the MAC address of the intended\r\nreceiver. To send to a device “x” on a remote network “y,” the\r\nnetwork layer DADR is set to “x,” the DNET is set to “y” and\r\nthe message is sent to the router to network “y” on the sender’s\r\nLAN. To send a local broadcast, the sender just uses the LAN\r\nbroadcast address. To send a remote broadcast, the sender sets\r\nthe DNET to the network number of the desired remote LAN,\r\nomits the DADR and sends the message to the router to the\r\nremote network. To send a global broadcast, the DNET is set\r\nto all 1’s, the DADR is omitted and the message is broadcast\r\non the local network.\r\nHow BACnet Uses Broadcasts\r\nThere are two main uses of broadcasts in BACnet: 1) transmis-sion of “unconfirmed” application layer service requests; and 2)\r\ndynamic binding. Unconfirmed services are broadcast if they are\r\nintended for processing by multiple recipients. Such messages\r\ninclude routine change-of-value and event notifications, time\r\nsynchronization messages, and Who-Is, I-Am, Who-Has, and\r\nI-Have. Unlike “confirmed” application layer service requests\r\nthat are always sent to a single recipient and must always be\r\nexplicitly acknowledged via a BACnet “ACK” message, un-confirmed messages are often sent to multiple recipients but\r\nare designed such that, if a response is desired, only a single\r\nrecipient responds. Rather than sending a BACnet ACK, whose\r\nuse is limited to confirmed services, the recipient responds by\r\nsending its own unconfirmed service request.\r\nHere is an example drawn from a dynamic binding situation.\r\nDevice A wants to communicate with Device B but does not\r\nknow B’s address. A global unconfirmed “Who-Is” message\r\ncontaining the “Device Instance Number” (DIN) of B is sent\r\nand received by all BACnet devices in the system. Since DINs\r\nare required to be unique Internet-wide, only one device (hope-fully) will respond to the message by sending an “I-Am” mes-sage indicating that it is Device B. From the MAC address and,\r\npossibly, network layer DNET and DADR parameters, Device\r\nA now has all the address information needed to communicate\r\nwith Device B.\r\nNetwork layer messages are also used for dynamic binding.\r\nThe most common is the Who-Is-Router-To-Network message.\r\nAs its name suggests, this message is used to find the address\r\nof the router to a specific DNET (or, if the DNET parameter is\r\nomitted, all routers to all networks). It is usually broadcast using\r\nFigure 1: Different BACnet LANs are interconnected by routers that repackage BACnet\r\nmessages and retransmit them unchanged.\r\nVendor A\r\nVendor B\r\nVendor B\r\nVendor C\r\nVendor C\r\nBACnet\r\nWorkstation\r\nSensors and Actuators\r\nBACnet\r\nField\r\nPanels\r\nSensors and Actuators Sensors and Actuators\r\nBACnet\r\nField Panel Ethernet to\r\nARCNET\r\nRouter\r\nEthernet\r\nto MS/TP\r\nRouter\r\nBACnet LAN–ARCNET BACnet LAN–MS/TP\r\nNetwork 2 Network 3\r\nBACnet\r\nField\r\nPanels\r\nBACnet LAN–Ethernet Network 1\n\nN o v em b e r 20 1 0 \t B A C n et ® To d a y | A Su p p l em e nt to AS H R A E Jo u r n a l \t B 1 1\r\nthe local LAN broadcast address but may be directed to a known\r\nrouter to learn the contents of its routing table.\r\nBroadcasting in BACnet/IP (B/IP)\r\nWhen it came time to take advantage of the wide-area routing\r\ncapability of the Internet, we decided to implement the use of\r\nIP as if it were just a fifth kind of LAN so as to preserve all of\r\nthe existing BACnet application and network layer mechanisms,\r\nincluding local, remote and global broadcasting. See BACnet\r\nAnnex J. The combination of the 32-bit IP address and the 16-bit\r\n“User Datagram Protocol” (UDP) port number uniquely specify\r\na device’s B/IP address, just like the MAC address of a true LAN.\r\nSince, in reality, there is still a true LAN involved (usually Eth-ernet) on which the IP traffic is carried, B/IP is referred to as a\r\n“BACnet Virtual Link Layer” (BVLL) and the functions needed\r\nby the BVLL to carry out unicast and broadcast messaging are\r\ncalled “BACnet Virtual Link Control” (BVLC) functions. While\r\nthere are 11 BVLC message types in all, three are of particular\r\nimportance here: Original-Unicast-NPDU; Original-Broadcast-NPDU; and Forwarded-NPDU. (NPDU stands for “Network\r\nProtocol Data Unit” and is just a fancy way to indicate the entire\r\nBACnet message that is being communicated by the LAN, in\r\nthis case the virtual LAN.)\r\nSo how does B/IP work? For unicast messages, the data is just\r\nsent via UDP, using the BACnet port number, to the IP address\r\nof the recipient device as an Original-Unicast-NPDU using\r\nthe usual IP mechanisms (Figure 2). To determine whether\r\nthe destination device is on the local subnet or on a remote\r\none, i.e., whether the message may be sent to the destination\r\ndevice directly or must be sent to the IP gateway, the originat-ing device uses a configuration parameter called the “subnet\r\nmask,” AND’s it with the source and destination IP addresses,\r\nand compares the results. If they match, the destination is local;\r\nif not it is remote. Any text on IP will explain this process in\r\nmore detail (or, if you are a glutton for punishment, you could\r\nrefer to RFC 791).\r\nA challenge arises when a message is to be broadcast. Even\r\nthough, for unicast messages, the entire Internet appears as\r\none humongous LAN, it does not for broadcasts. Broadcasts\r\nare not allowed to pass through IP gateways since they could\r\npotentially reach every device on the Internet worldwide, caus-ing untold congestion. The solution is to intercept the broadcast\r\nmessage and send it as a unicast message to a compatriot that\r\nthen broadcasts it on the remote subnet. A broadcast intercep-tor of this sort is called a “BACnet Broadcast Management\r\nDevice” (BBMD).\r\nBBMD operation is actually quite simple. Each BBMD has\r\na “Broadcast Distribution Table” (BDT) containing a list of its\r\npeers. When the BBMD sees an Original-Broadcast-NPDU, it\r\nsends it as a Forwarded-NPDU to its peers that then broadcast\r\nthe message on their local subnet using the IP broadcast address\r\nfor that subnet (Figure 3).\r\nFigure 2 (left): Unicast messages, from Device A to Device B, are sent through the Internet using the IP address (and BACnet UDP port\r\nnumber) of the destination. The term gateway is in quotes because in BACnet terminology gateways translate to or from BACnet into\r\nsome other protocol format. Using the BACnet terminology of today, IP gateways would properly be called IP routers. Figure 3 (right):\r\nBBMDs intercept Original-Broadcast-NPDUs and send them as Forwarded-NPDUs to the peer(s) in their Broadcast Distribution Tables.\r\nThe remote BBMD sends the messages as Forwarded-NPDUs on its local network using the IP broadcast address appropriate for its IP\r\nsubnet. The message appears twice on the source and destination networks—once as a broadcast and once as a BBMD-to-BBMD unicast.\r\nBBMD BACnet\r\nDevice\r\nBBMD\r\nInternet\r\nIP\r\n“Gateway”\r\nBACnet\r\nDevice A\r\nBACnet\r\nDevice\r\nBACnet\r\nDevice\r\nBACnet\r\nDevice\r\nBACnet\r\nDevice B\r\nIP\r\n“Gateway”\r\nBBMD BACnet\r\nDevice\r\nBBMD\r\nInternet\r\nIP\r\n“Gateway”\r\nBACnet\r\nDevice A\r\nBACnet\r\nDevice\r\nBACnet\r\nDevice\r\nBACnet\r\nDevice\r\nBACnet\r\nDevice B\r\nIP\r\n“Gateway”\n\nwww.info.hotims.com/30921-92\r\nB 1 2\t \t B A C n et ® To d a y | A Su p p l em e nt to AS H R A E Jo u r n a l \t \t N o v em b e r 20 1 0\r\nHow to Solve Problems with BACnet Broadcasting\r\nYou might suspect that you have such problems if your BACnet\r\nnetwork seems to be getting sluggish or devices seem to ran-domly go offline for awhile and then come back. These issues\r\ncan be caused by excessive broadcast traffic sometimes rising\r\nto the level of a “broadcast storm” of hundreds of packets per\r\nsecond and, in every case I know of, arise because of erroneous\r\ndevice configuration.\r\nMost of the problems I have seen manifest themselves on B/IP\r\nnetworks, so let’s focus on these. To find out why the excessive\r\ntraffic is occurring, it is essential to find out what the nature of\r\nthe broadcasts is and where they are coming from. For this, you\r\nneed a tool called a “protocol analyzer” that lets you inspect\r\nand interpret the actual messages on the network. Several\r\ncommercial ones are available, and you can also download an\r\nopen source analyzer called Wireshark, which has very good\r\nBACnet filtering and decoding capabilities (www.bacnet.org/\r\nDeveloper#wireshark for details).1\r\nFirst, capture all the packets on the network for a few minutes. I\r\ngenerally turn off any capture filters because I don’t want to miss\r\nanything. Also note that if you connect to the network through\r\na switch (as opposed to a hub), you will only see the broadcast\r\ntraffic and any traffic specifically targeted to any devices also on\r\nthe same switch port. Here are some broadcasts you might see:\r\n1. UnconfirmedCOVNotification broadcasts. If you see a\r\nstorm of these, it usually means that the Change-of-Value\r\n(COV) increment is set to 0 or other ridiculously low value\r\nfor the quantity being measured. I have seen cases where\r\nthe COV increment was so small that every scan of the\r\nquantity in question, e.g., an airflow of thousands of cfm\r\nthat could easily change by tens of cfm between scans,\r\nproduced an UnconfirmedCOVNotification. Since such\r\nscans often occur dozens of times per second, this can be a\r\nproblem. Besides adjusting the COV increment, it may also\r\nbe possible to use unicast messaging since there is noth-ing that requires unconfirmed messages to be broadcast.\r\n2.Who-Is broadcasts. Who-Is messages should be rare.\r\nDevices are supposed to figure out how to communicate\r\nwith their peers and store the address. But if a device can’t\r\nlocate its peer, then it may continue to seek it out, hour\r\nafter hour after hour. Usually this means that the sending\r\ndevice has an erroneous DIN for the peer or that the peer\r\nsimply isn’t there. This can easily happen if a program\r\nis cut-and-pasted from one controller to another and the\r\nprogrammer has not updated network variable references.\r\nFind the references in the device’s program and fix them.\r\n3.Who-Is-Router-to-Network broadcasts. These can occur\r\nfor similar reasons to those cited in the previous item: the\r\nnetwork number reference is invalid, or there is no router\r\nto the requested network. Again, cut-and-paste errors are\r\nfrequently the cause.\r\n4. Forwarded-NPDU broadcasts from more than one address.\r\nThis means that more than one device is acting as a BBMD\r\nsince forwarded NPDUs are only broadcast by BBMDs.\r\nOriginally, only one BBMD was allowed per IP subnet\r\nand although this constraint was relaxed in Addendum\r\no to BACnet-2008, most IP subnets still only have one.\r\nThe problem can occur when a particular manufacturer’s\r\nsystem decides “to be helpful” and automatically instructs\r\none or more of its devices to be a BBMD without the au-thorization of a human. This can create complete havoc\r\nsince now broadcasts can have multiple paths between\r\nsubnets, and loops can be set up whereby a broadcast on\r\none subnet appears on another, is forwarded back to the\r\noriginal subnet by the rogue BBMD, ad infinitum. The\r\nmost serious broadcast problem I personally have ever\r\nexperienced was due to this cause. Track down the of-fending device(s) and turn off their BBMD functionality\r\nor fix their BDTs.\r\nConclusion\r\nThe use of broadcast messaging is an important and time-honored technique, not just in BACnet but in many other com-mon network technologies, but, like any powerful capability,\r\nmust be carefully configured and managed.\r\nReferences\r\n1. Karg, S. 2008. “Analyzing BACnet.” BACnet Today supplement\r\nto ASHRAE Journal 50(11): B24\r\n–29.",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"pdf"
	],
	"references": [
		"https://bacnet.org/wp-content/uploads/sites/4/2022/06/Newman_2010.pdf"
	],
	"report_names": [
		"Newman_2010.pdf"
	],
	"threat_actors": [],
	"ts_created_at": 1777429254,
	"ts_updated_at": 1777450875,
	"ts_creation_date": 1287587222,
	"ts_modification_date": 1287647721,
	"files": {
		"pdf": "https://archive.orkl.eu/384feeeb1c161862c51b75df5b1fae8056ecdc69.pdf",
		"text": "https://archive.orkl.eu/384feeeb1c161862c51b75df5b1fae8056ecdc69.txt",
		"img": "https://archive.orkl.eu/384feeeb1c161862c51b75df5b1fae8056ecdc69.jpg"
	}
}