How BACnet/SC Actually Works: Hubs, Nodes, Certificates and the Connection Sequence

Most techs meet BACnet/SC as a checkbox on a spec and a set of fields nobody has filled in yet: a hub URI, a failover URI, a certificate file. Fill them in wrong and the device just sits there. To fix that with any confidence, you need a working picture of what the device is trying to do.

If you haven't read the BACnet/SC introduction, start there for the why. This article is the how: the parts, the order things happen in, and the messages that go back and forth once a connection is up. None of it changes the BACnet you already know. Objects, properties, priority arrays and COV all work exactly as before. What changes is the datalink underneath them.

The parts: hub function, hub connector, nodes

BACnet/IP is a party line. Every device on the subnet hears every broadcast, and BBMDs stitch subnets together. BACnet/SC throws that away and replaces it with hub and spoke.

The outbound direction matters more than it sounds. Nodes call the hub; the hub never calls the nodes. That means IT only has to allow one TCP port inbound to the hub and one to the failover hub. Nodes can sit behind DHCP, because nobody needs to know their address in advance. No UDP broadcasts, no BBMDs, no foreign device registration.

Primary and failover

A node tries its primary hub. If it can't reach it, it connects to the failover hub. That's the whole redundancy model, and it only works if the failover hub doesn't share a failure with the primary. Put it on a different device, on a different power circuit, behind a different switch. Two hub functions on the same supervisor, or two supervisors on the same UPS and switch, is a failover plan on paper only. The rollout planning article covers placement in detail.

Direct connections

The standard also allows optional direct connections node to node, bypassing the hub, where both ends support it. Think of a supervisor pulling a lot of trend data from one controller. It's optional, it's not universal, and on most sites I'd expect nearly all traffic to go through the hub. Know it exists so the term doesn't throw you on a data sheet.

Addressing: VMAC and Device UUID

There are no IP addresses in BACnet/SC addressing and no MS/TP-style MACs. Each node has two identifiers:

• VMAC — a 6-octet random virtual MAC address. This is the node's address on the SC network, the thing that goes in the source and destination fields of each message. X'FFFFFFFFFFFF' is the broadcast VMAC.
• Device UUID — an RFC 4122 UUID, generated before deployment, persistent, and never changes. It identifies the physical device across reboots and reconnections.

Both are meant to be unique by construction. The place they stop being unique is the field: someone builds one controller, exports the configuration, and loads it into five more. If that copy carries the VMAC or UUID with it, you now have duplicates, and the hub will refuse the second one to arrive. I cover what that looks like in the troubleshooting article. For now: when you clone a config, check that the SC identity was regenerated.

The connection sequence, step by step

This is the part worth memorising, because every SC fault is a failure at one of these steps, and each step fails differently.

The BVLC-SC messages

Once the WebSocket is up, everything is a BVLC-SC message. There are thirteen function codes. You'll only see them decoded in Wireshark (dissector bscvlc) when you have the TLS keys, but the names show up in device logs and status pages, so it's worth knowing what they are.

The Advertisement is the one I find most useful day to day. It tells you, from the node's point of view, whether it's on the primary hub, the failover hub or nothing. If every node on a site is advertising “failover”, your primary hub has a problem, even if the building looks fine from the front end.

How a Who-Is gets anywhere

Discovery still works the way you expect from the BACnet side: a workstation sends Who-Is, devices answer I-Am. The difference is the path.

• The workstation wraps the Who-Is in an Encapsulated-NPDU with the destination VMAC set to broadcast, X'FFFFFFFFFFFF', and sends it up its one connection to the hub.
• The hub function sees the broadcast address and copies the message to every other connection it holds.
• Each device that matches the Who-Is range answers with an I-Am. That reply goes back to the hub addressed to the workstation's VMAC, or as a broadcast, and the hub forwards it on.

So a “broadcast” on SC is really a fan-out done by the hub over individual encrypted connections. There's no UDP broadcast on the wire, no subnet boundary to worry about, and nothing for a BBMD to do. A device that isn't connected to the hub simply doesn't hear it. That's why “it doesn't show up in discovery” on SC almost always means “it isn't connected”, and you go back to the connection sequence.

How legacy BACnet/IP and MS/TP join

BACnet/SC is a datalink, so the normal BACnet network layer still sits on top of it. That means ordinary BACnet routing works. A router with an SC port on one side and a BACnet/IP or MS/TP port on the other joins the two as separate BACnet networks with their own network numbers, exactly like an IP-to-MS/TP router does today.

In practice that's how almost every site will look for years: an SC network across the IP backbone, with routers bringing in MS/TP trunks and pockets of older BACnet/IP devices that don't have SC firmware. Two things to keep straight:

• SC doesn't secure what's behind the router. The MS/TP trunk is exactly as open as it was. The BACnet/IP segment behind an SC router still uses UDP 47808 with no authentication. Segmentation still matters — see segmentation and talking to IT and why BACnet and Modbus have no security.
• Network numbers still have to be unique. The SC network gets its own number. Treat it like any other network when you plan routing.

A device that's been moved to SC but is still sending BACnet/IP broadcasts is a common migration leftover: the SC port is enabled, but so is the old IP port. It'll usually work, which is exactly why nobody notices it until someone looks at a capture.

Where all this lives in the device

Every setting I've mentioned is configured through the SC Network Port object: primary and failover hub URIs, minimum and maximum reconnect times, connect and disconnect wait timeouts, the heartbeat timeout, whether the hub function is enabled, and references to the certificate files. The Network Port object also reports status — whether the hub connector is connected, to which hub, and on many devices a record of failed connection attempts. When you're on a site, that status is often the first thing I read, before any capture. Your front end or the device's own configuration tool will present these differently; the underlying properties are the same.

If you want to see the port numbers side by side with the rest of the building protocols, the BAS Port Reference has them, including why SC's port depends on the URI rather than a fixed number.

What to take away

• Nodes connect out to a hub. One TCP port inbound to each hub, and that's the firewall conversation.
• Six steps: DNS, TCP, TLS with both certificates, WebSocket upgrade, Connect-Request/Accept, then traffic and heartbeats. Every fault sits at one of them.
• VMAC and UUID are the identity. Don't clone them.
• Broadcasts are a hub fan-out, not a UDP broadcast. Not connected means not discovered.
• Legacy networks join through routers, and stay exactly as secure as they were.

Found a wrong number or a broken link? Tell me and I’ll fix it.