What NM-SCH-B Is
NM-SCH-B (Network Management-Secure Connect Hub-B) is the BACnet Interoperability Building Block (BIBB) for the hub role in a BACnet Secure Connect network. A device claiming NM-SCH-B accepts WebSocket connections from BACnet SC nodes and fans messages out to the rest of the network. The hub is the BACnet SC replacement for the broadcast domain that BACnet/IP and the BACnet BBMD provided.
The hub is a function a node enables, not a separate class of device: a hub is itself a node, and a device can run the hub function while carrying on as an ordinary BACnet device.
Hub redundancy is configured on the nodes, not on the hub. In Annex AB, a node’s hub connector holds two URIs, SC_Primary_Hub_URI and SC_Failover_Hub_URI, and connects to one at a time, falling back to the failover when the primary is unreachable. The node makes that choice: a device claiming NM-SCH-B accepts connections and does not know or care whether the nodes reaching it named it primary or failover. (On the CAS BACnet Stack, automating that fallback is a 6.x item; see what ships today.)
The BACnet SC BVLC Message Set
Annex AB defines thirteen BVLC (BACnet Virtual Link Control) message types, carried by the BACnet SC virtual link layer. These are the exchanges that make the hub-and-spoke topology work.
| BVLC Message | Purpose |
|---|---|
| BVLC-Result | Carries the result or error for a preceding message |
| Encapsulated-NPDU | Carries the actual BACnet network-layer messages |
| Address-Resolution / Address-Resolution-ACK | Resolves a peer’s VMAC to its WebSocket URI; the basis of direct connect |
| Advertisement / Advertisement-Solicitation | Announces hub connection state and node capabilities, and requests that announcement |
| Connect-Request / Connect-Accept | Node joins the hub after mutual TLS authentication |
| Heartbeat-Request / Heartbeat-ACK | Keeps long-lived WSS connections alive and detects dead peers |
| Disconnect-Request / Disconnect-ACK | Orderly teardown of a node connection |
| Proprietary-Message | Vendor-defined extension carried in the BVLC envelope |
Where You Meet It in the Field
Whoever runs the hub owns the availability of the whole BACnet SC network. On small sites, the hub function often lands on the supervisory controller or gateway. On multi-site and cloud-managed deployments, the hub runs centrally and every remote device connects outbound to it.
[!NOTE] A failed hub with no configured failover takes down message flow for every node at once. Specify both a primary and a failover hub in any production BACnet SC design, and confirm that the nodes’ stack automates the fallback (on the CAS BACnet Stack that is a 6.x item).
What Chipkin Provides
The CAS BACnet Stack supports the NM-SCH-B hub function today: a device on the shipping stack accepts node connections and fans messages out. What is not yet in place is the evidence behind that claim. Per-function BTL conformance is unverified, and a BTL Listing is granted to a finished product rather than to a stack. The CAS BACnet Stack 6.x release exercises the BACnet SC BIBBs against the BACnet Testing Laboratory’s published test plans and adds hub-connector failover on the node side. A device can claim the B-SCHUB hub profile alongside its control or gateway profile today; what 6.x adds is the test evidence behind that claim.