Detailed explanation of BACnet protocol - application layer description 2

written in front

It's delayed again, sorry for the judges. It is really a lot of things after the year, and the family members are on business trips, so I can only busy myself with other things first.

3 Transmission of BACnet APDU

3.1 Request message transmission that needs to be confirmed

After the client sends the request message to be confirmed, the client will start the timer. When receiving an error APDU, a rejection APDU, an abort APDU, a simple confirmation APDU or a complex confirmation APDU about a request message to be confirmed, stop timing and notify the client application. If the timer time exceeds the APDU timeout in the client device object ( that is, the APDU_TimeOut attribute in the device object, the value must be initialized and set before the client starts BACnet ), then resend the message, and the timer Retime. The number of overtime sending of all request messages that need to be confirmed reaches the APDU retransmission times of the client device object ( that is, the Number_Of_APDU_Retries attribute in the client device object, this attribute also needs to be set before starting BACnet ), at this time the message will be discarded and the client's application notified. The two attribute values ​​in the red letter also need to be set in some debugging tools, such as yabe. After reading this, you will know why these values ​​are set and what these values ​​represent.
The data transfer process is as follows

3.2 Transmission of Segmented Acknowledgment Request Messages

The difference between a fragmented request message and a non-segmented request message is:

• Needless to say, the biggest difference is segmentation. A segmented request message needs to be sent multiple times to complete the transmission of a request message.

• The segmented request message will use the first packet of data to perform a data transmission size (1~127) per packet between the client (that is, the device that sends the request) and the server (that is, the device that responds to the request). Negotiation, that is, there will be such a dialogue:

  • The client will say in the first packet of data: I can transmit so much data in one packet, can you do it?
  • The server will say in the reply of the first packet of data:
    • (An answer) I'm a man, of course, I can accept more than you, but you can send so much data, just take the most you can send! ( That is, if you are in man on the server side, you can receive it, and you cannot tell the client to send a value exceeding its maximum sending value )
    • (Another reply) Obviously, the server is not man enough this time, and only replied a value that is less than the length of the data that the client can send, but it must be greater than or equal to 1

The same point between the two is that each send and reply must also meet the mechanism of timeout and retransmission times.
One point that needs to be emphasized is that the transmission of all segmented messages belonging to a request message requiring confirmation must ensure continuity, that is, the time between two segmented messages cannot exceed Tseg. Tseg is the APDU_Segment_Timeout attribute in the Device Object at the sending end.
The transmission process is shown in the figure below

3.3 Transmission of Segmented Complex Acknowledgments

The difference between this and 3.2 can be seen by comparing the two message transmission diagrams, that is: 3.2 is that the sent data needs to be segmented, and 3.3 is that the reply data needs to be segmented.
The difference between the transmission process and 3.2 is: the process of negotiating the size of the data packet starts when the server responds to the first packet of data requested, and the negotiation process is the same as 3.2. Other points that need attention also refer to 3.2 and 3.1.
The transmission process is shown in the figure below:

3.4 Segmentation confirms the transmission of APDU

The segment acknowledgment APDU is the information used by the segment receiver device to confirm the sender. In the following four situations, the device shall transmit a segment confirmation message:

1. The device receives the first fragment of a fragmented packet. In this case, the parameter 'negative-ACK' in the segment acknowledgment message used for acknowledgment shall be set to FALSE to indicate that this is a positive acknowledgment; the parameter 'serial number' shall be set to 0 to indicate Once the first segment has been acknowledged, the sender of the segment can continue sending subsequent segments.
2. The device receives an unacknowledged, ordered sequence of multiple message segments equal to the actual window size. In this case, the parameter 'negative acknowledgment' in the segment acknowledgment message used for confirmation should be set to FALSE to indicate that this is a positive acknowledgment; the parameter 'serial number' should be set to the last segment received this time. The 'sequence number' value of the segment, to indicate that the segment including the 'serial number' has been confirmed, and the sender of the segment can continue to send subsequent segments.
3. The device received a fragmented message out of order (possibly indicating a fragment was lost). In this case, the segment receiver will discard the out-of-order segment. The word "out of order" here means that the 'sequence number' of the received segment is not equal to the expected 'sequence number'. The parameter 'negative acknowledgment' in the segment acknowledgment message for confirmation should be set to TRUE to indicate that this is a negative acknowledgment; the parameter 'serial number' should be set to the 'serial number' value of the last correctly received segment to Indicates that all segments up to this 'sequence number' value have been confirmed, and the sender of the segment can continue to send subsequent segments.
4. The device received the last segment of the message. In this case, the parameter 'negative acknowledgment' in the segment acknowledgment message used for acknowledgment should be set to FALSE to indicate that this is a positive acknowledgment; the parameter 'serial number' should be set to the 'serial number' of the last message segment value to indicate that all segments are confirmed.

3.5 Repeated APDU and message segmentation

3.5.1 Abort of Client Transaction State Machine

When using the error retransmission mechanism defined by the BACnet standard, in the interactive processing of message transmission, there must be the possibility of receiving duplicate messages or segments. On the client side, after sending the confirmed request APDU message (or the first segment of the message), a transaction processing state machine will be created for transaction processing. When one of the following four situations occurs, the transaction processing of the client is suspended, and the transaction processing state machine is ended at the same time.

1. When receiving five messages from the server-side device that contain the call identifier (invokeID) of this transaction. The five types of messages are: simple confirmation APDU, complex confirmation APDU without segmentation, error APDU, rejection APDU and abort APDU.
2. After receiving the last segment of the segmented complex acknowledgment APDU from the server and sending the corresponding segmented acknowledgment APDU.
3. When the number of timeout retransmissions is exhausted.
4. After sending an Abort APDU to the server containing the call identifier for the transaction (eg client aborts the transaction).

3.5.2 Suspension of server-side transaction processing state machine

On the server side, after receiving the confirmation request APDU message (or the first segment of the message), a transaction processing state machine will be created for transaction processing. When one of the following four situations occurs, the transaction processing at the server end is suspended, and the transaction processing state machine is ended at the same time.

1. When sending to the client device the completion of the five messages containing the call identifier for this transaction. The five types of messages are: simple confirmation APDU, complex confirmation APDU without segmentation, error APDU, rejection APDU and abort APDU.
2. After receiving the segmented complex acknowledgment APDU from the client device for the last segmented segmented acknowledgment APDU.
3. After receiving the abort APDU containing the transaction call identifier sent by the client.
4. In the process of transmitting a segmented complex acknowledgment APDU, when the number of timeout retransmissions reaches the specified value but still fails.

3.5.3 Processing of repeated messages

The processing process of repeated messages or repeated message segments is as follows: here we need to pay a little attention, because when the mstp device communicates across the network through the BACnet router, due to the processing capability of the BACnet router, we have encountered repeated messages Case. So we need to understand it here, but we can also wait for this situation to study and analyze in depth. But you must also know which part of the document you need to read when you encounter this kind of problem!

1. When the server receives a repeated confirmation request message, if the server has the ability to identify repeated confirmation request messages, the repeated message will be discarded by the server. Otherwise, the server still responds to this repeated request message with confirmation. In this case, the client will discard it according to the fact that the invocation identifier in the server response message is not bound to any current transaction processing state machine. This response message.
2. When the server receives a duplicate Confirmed Request segment, that is, it has received and sent a segment acknowledgment for the segment, the server will discard the duplicate segment and return an appropriate segment Confirm APDUs. Any segment can be uniquely identified by the peer address, call identifier, and segment sequence number.
3. When a client receives a duplicate complex acknowledgment segment, that is, a segment acknowledgment message has been received and sent for the segment, the client will discard the duplicate segment and return an appropriate segment acknowledgment APDUs. Any segment can be uniquely identified by the peer address, the call identifier, and the segment's sequence number.
4. When a device receives a duplicate Segment Ack APDU, the device shall discard the duplicate Segment Ack APDU.

3.6 Handling of invalid resources

The specific implementation of the above-mentioned error retransmission process of BACnet requires certain resources provided by both ends of the client and the server. These resources are usually various details of transaction processing, including transaction processing state machines, timers, and APDU or APDU segmentation buffers. When the error retransmission process fails, these associated resources also become invalid and should be released. The exact details of resource release depend on the exact design of the system. As a design suggestion, this agreement gives the basis for resource failure and should be released:

1. On the client side, when a complete response to a Confirmed Request APDU is received.
2. On the client side, when a confirmed request APDU message is retransmitted for the number of times specified in the APDU retransmission times attribute, but still fails.
3. On the client side, when a confirmed request APDU segment has been retransmitted the number of times specified in the APDU retransmission times attribute, but still unsuccessful.
4. On the server side, when a response to a Confirmed Request APDU is sent and the corresponding segmented acknowledgment is received.

4 Application layer protocol state machine

Personal understanding, this part does not require in-depth understanding. At present, I have not encountered problems in these aspects of the state machine, and I need to understand the content of this part in depth. But there are some parameters in this part that can be explained

4.1 Variables and parameters

1. Variables include: retransmission count, segmented retransmission count, etc. These are variables that need to be defined in the BACnet protocol stack for counting and other functions. ( If you want to have a deeper understanding of the code of the protocol stack, reading this part of the content is also helpful, but if you don’t read it, you should be able to understand most of the meaning of the variables by looking at the code directly )

2. parameter

   • Twait_for_seg: This parameter is the length of time a node waits for subsequent message segments after sending the segment confirmation PDU. This time length value is 4 times of the APDU segmentation timeout attribute value in the node's device object.
   • Tout: This parameter represents the APDU timeout attribute value in the device object of the node.
   • Nretry: This parameter indicates the APDU retransmission times attribute value in the device object of the node.

5 Application layer protocol time chart

The timing diagrams of this part are basically hung behind the third part

application layer epilogue

In fact, you don't need to put too much energy into the application layer, you just need to understand the part I marked in red. Or browse the entire application layer without spending too much energy to understand it, because when you apply the BACnet protocol stack for development, this part of knowledge is not the most critical. The explanation of the BACnet protocol must be from the bottom up, but with BACnet, it must be from the top to the bottom or only the upper part is used. Only when you understand the application of the upper layer, and you slowly come back to read this part of the explanation, you will have your own understanding. So for this part, my suggestion is, take a look if you have time, at least browse it, there is no need to understand it word by word.