There are two concepts of frame:
- 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”.
- 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) , 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 of time gap between MSTP frames is Tturnaround (40 bits time), it is less than Tframe_abort, so if RSM lost syhchronization of MSTP frame, it may parse wrong MSTP frame across actual MSTP frames.
There are several cause of losing synchronization:
- Program defect on sending or receiving device. It could be resolved by code review and test.
- Timer precision. BACnet MSTP standard only require 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 error space between delay and timeout (Tusage_delay to Tusage_timeout, Treply_delay to Treply_timeout), it is very likely causing collision for a slow responding devices.
- Noise on bus line. Noise cause 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 not considering malicious devices(Here is a attack example), there are still applications may send valid frame in data portion.
For example, There are lot of serial to IP gateways on market, they usually have
one or more RS485/RS232 serial port with Ethernet or Wifi, remotely
read/write raw serial data by TCP/UDP using predefined protocol. The
serial line maybe Modbus or just ASCII protocol, but the designer doesn’t
even know in advance. They are useful on monitoring remote devices or
simple protocol integration.
Is it reasonable to implement these gateway’s IP side protocol as
BACnet PrivateTransfer service? But what would happen when user attach
this gateway to a MSTP bus, and the BACnet route to remotely access it pass through
another MSTP network?
It is not only possible cause MSTP bus being blocked, but also device
malfunction if the wrong frame is a APDU or breaking whole BACnet
inter-network if the wrong frame is a I-Am-Router-To-Network frame.
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