Before discussing in detail how unicast and broadcast messages work in the BACnet/IP environment, we need to introduce another new and essential concept, that of the "BACnet Virtual Link Layer" (BVLL).
The fundamental concept behind a virtual link layer (VLL) is to present a view of some network topology and function to the existing BACnet network layer, taking advantage of whatever functionality is built into the new protocol and adding functions as necessary to maintain the BACnet network viewpoint in the existing standard.
The current presentation is limited to IPv4, but a VLL could easily be developed for any other type of network. The concept is to use not only the data link layers of other protocols but rather to build a cooperation between nodes and/or processes so they are structured as a data link when viewed by higher layer protocols. As long as the devices or processes can be uniquely identified and there is a way to distribute messages to all of the devices or processes in the cooperating group, they can be addressed using a new virtual link layer.
In the drawing above, the control information for the BACnet Virtual Link Layer (BVLL) is designated BACnet Virtual Link Control Information (BVLCI). Each BVLCI field has a minimum of three fields: BVLC Type, BVLC Function, and BVLC Length. Notice that the BVLCI Type field has the value X'81'. This is used to indicate that this is BVLC information for BACnet/IP and to distinguish a virtual link message from the NPCI version field (currently X'01'). [Messages sent by BACnet tunneling routers, as described in Annex H, are differentiated from BACnet/IP messages by this initial octet. Both are sent over UDP and could, in principle, both be received by the same device at the same UDP port of X'BAC0'.]
Each of the various BACnet/IP messages is associated with a particular BVLC function.
The addition of a new layer in BACnet allows us to take advantage of new software paradigms. Just as BACnet began with an "object oriented" model for managing objects, the same flexibility can be used to manage the virtual link layer.
The pure layered approach as described in Figure 5-2 (page 16) of the standard is the collapsed view of the ISO model, well suited to procedural programming and nested function calls. There is one and only one path 'up' and 'down' the protocol stack, the path through the stack is static.
There is a new paradigm developed in project HORUS which is specifically designed to advance the state of the art in distributed applications. At its core is the concept of microprotocols which are used to coordinate the path of a message up and down the protocol stack. Each software layer is described as an object and the microprotocols are used to pass messages from object to object.
One important concept in HORUS is that these objects that manage the functionality of a specific layer can change their orientation at run time. This means that some security or quality-of-service layer can be made available and placed before or after other layers as necessary.
A second important concept is that new technology for managing group communications (including but not limited to security, fault tolerance, coherent caching, etc.) can be added to the available 'library' of functionality, without affecting their implementation or their relationship in the protocol stack. This is similar to mapping one presentation layer to another, so each new microprotocol is designed for a specific set of functionality.
For example, with security only implemented at the APDU layer, information about the topology of a BACnet network can be easily determined. It might be necessary to define a secure tunnel between devices or networks of devices so all communications is private.
In addition, as new security functionality is developed and adopted, one "secure virtual link layer" can be substituted for another without requiring new APDU services to be defined. What differentiates a mircoprotocol message from a traditional protocol stack is that some layers can be excluded, without becoming non-conformant.