BACnet MS/TP Timing explained

BACnet MS/TP is a token passing protocol. It is one of the data links supported by the BACnet standard. MS/TP is a master/slave token-passing protocol which uses standard serial ports on microcontrollers and EIA-485 transceivers. This network offers the lowest possible hardware cost for BACnet integration and is used by many companies for their device level network.

Token Passing
Token passing is a well-known networking access control mechanism. MS/TP uses this "token passing" system to control access to the network. A master node may initiate the transmission of a data frame only when it holds the token. Both master and slave nodes may transmit data frames in response to requests from master nodes. After the master node with the token sends several frames (defined by the Nmax_info_frames setting) the node then passes the token to the next master node.
Token frames are not acknowledged.

So, what are the BACnet MS/TP timing requirements?

There are two "levels" of responses in MS/TP:

• The low-level "response" is part of the token-pass machinery. An MS/TP master node (a BACnet device) should start using the Token or reply to a Poll For Master frame in 15 milliseconds. The requesting node should wait for the "response" for at most 20 milliseconds. In the documentation this requirement is referred to as "the time frame for sending a message is 10 to 15ms". The lower part of a BACnet datalink communicates with the hardware network interface and is platform specific. In the case of the MS/TP datalink, the code is time critical and requires guaranteed response in 5-10 ms time frame. 
• The "high-level" response is the BACnet application-level response to a Confirmed Request, as defined in the Application Layer of BACnet.

When an MS/TP node receives a frame, which contains an application layer Confirmed-Request, it should respond in 250ms. It can either send the frame with the application-layer Confirmed-Response, or notify the sender that the Response will be sent later, by sending Reply-Postponed frame. In documentation this case is referred to as "responses to requests should be sent in 250ms".

Good to know! Though BACnet Standard defines the maximum timeout as 250ms, it is better to keep this timeout smaller. There was even a proposal to limit it to 225ms. By default, uBACstac uses 225ms as the timeout.

There is also a special case of creating a new TOKEN.

If the Token is lost, the node with the smallest MAC generates the new Token. The time slot for a node to start sending the new Token is 10ms. If other devices on the network need a few milliseconds to notice the presence of the new token, the token should better be generated in the first half of the time slot. That is: the transmission should be started with 5-10ms accuracy. This is mentioned in the documentation as a general requirement for the low-level MS/TP code to be capable of starting transmission in 5-10ms. (The wording is probably confusing, however: "requires guaranteed response in 5-10 ms time frame").

Finally, when a node transmits a frame, there should be no gaps in the transmission. The idle time between two octets should not exceed 20 bit times. At 9600 bps this amounts to 20ms, but for 115200 bps this timeout is less than 2ms. This is usually not a problem for an RS-485 software driver, so it is not specifically mentioned in the documentation.

For developing an application using Cimetrics uBACstac keep in mind that the application logic (and timing) in BACnet is completely decoupled from the low-level MS/TP FSM.

Basically, when an MS/TP device gets a Confirmed-Request it has two choices:

1. Answer immediately, re-using the "time-slot" granted to it by the node which sent the Request.
2. Postpone reply for later by sending "Reply-Postponed" message, and send the Response later, when the device obtains the Token.

In the first case, the Application should encode the Response and pass it on to the Datalink so that the frame transmission starts in 225ms. The shorter this time is the better, because the whole MS/TP network stalls and waits. Formally, BACnet standard allows for 250ms. delay, but uBACstac by default uses a shorter timeout of 225ms.

In the second case, the application should notify the MS/TP Datalink that it is going to send Response later (the application creates a "reply postponed" message with the uBACstac function BACstacCreateReplyPostponed() and SENDs it to the Datalink), and then the device has a few seconds to prepare the Response and send it. In this case, the allowed time is determined by the value of "Apdu_Timeout" property of the Device Object of the device which initiated the Request. Usually it is in the range of 3-10 seconds.

The bottom line:

If an application can prepare the Response in a few milliseconds, then it should answer immediately. If it takes more than 100ms, then it is better postponing the reply in order to not slow down communication on the MS/TP network.

Also in Cimetrics News