Tag Archives: preamble

BACnet MSTP frame lost synchronization

Posted on by

There are two concepts of frame:

  1. BACnet MSTP datalink layer frame, it has at least 8 octet bytes, including: 2 preamble bytes of 0x55 and 0xff, frame_type, destination_mac, source_mac, 2 data_len bytes, crc, and omissible data portion.  We call this type of frame as “MSTP frame”.
  2. EIA-485 frame, it is consisted of bits, including start bit, data bit, parity bit, stop bit. BACnet MSTP using non-return to zero (NRZ) encoding with one start bit, eight data bits, no parity, and one stop bit. The start bit shall have a value of zero, while the stop bit shall have a value of one. The data bits shall be transmitted with the
    least significant bit first. We call this type of frame as “byte frame”.

BACnet MSTP Receive Frame Finite State Machine (hereafter refer to RSM) distinguish starting of frame by preamble bytes. If there is no DataAvailable or ReceiveError within a frame for Tframe_abort (60 bits time, but Implementations may use larger values for this timeout, not to exceed 100 milliseconds) , the frame is aborted, RSM search for next frame again.

Because preamble bytes is allowed on other portions of MSTP frame (Extended frame introduced by Addendum 135-2012an is an exception, it use COBS encoding to avoid 0x55 existing in data portion), so RSM may parse MSTP frame beginning from data portion of previous MSTP frame.

The minimum time gap between MSTP frames is Tturnaround (40 bits time), it is less than Tframe_abort, so if RSM lost sychronization of MSTP frame, it may parse the wrong MSTP frame across actual MSTP frames.

There are several cause of losing synchronization:

  1. Program defect on sending or receiving device. It could be eleminated by code review and test.
  2. Timer precision. BACnet MSTP standard only requires a 1% precise timer with a resolution of 5 ms or less. So it is hard to check out Tframe_abort. Because there is only 5 ms of error space between delay and timeout (Tusage_delay to Tusage_timeout, Treply_delay to Treply_timeout), it is very likely causing collisions for slow responding devices.
  3. Noise on bus line. Noise causes byte frame error and crc error, RSM will abort previous MSTP frame in both situations.

Some may argue that MSTP frame integrity is protected by header crc8 and data crc16. Even without considering malicious devices(Here is a attack example) and random data collision, there are still applications may send valid frame in data portion.

(Updated 25 June 2021) For example, There are some products that have implemented a packet capture function on MSTP bus, then the captured data may be transferred by BACnet service (PrivateTransfer or AtomicReadFile?). What would happen if there is electronic noise on the bus when the data is passing through a MSTP network?

It is not only possible to cause MSTP bus being blocked, but also device
malfunction if the wrong frame is a APDU or break whole BACnet
inter-network if the wrong frame is a I-Am-Router-To-Network.

Byte Frame Desynchronization

For the byte frame, losing synchronization usually is caused by noise, no termination or absence of biasing. The symptoms include regarding data bit of 1 as idle line, regarding data bit of 0 as start bit of new byte. In addition to data error, the losing synchronization of last byte in a MSTP frame will introduce measure error of idle time between MSTP frames.

Read more on Solution to mstp frame desynchronization