What Is a DNP3 Fragment?

Back to Blog

One Message, Sometimes Several Fragments

A fragment is the application layer's unit of work, distinct from the link frame below it. Each device advertises a maximum fragment size in its configuration. When a response would exceed that size - say a large integrity poll that returns every point in the device - the outstation breaks the response into several fragments and sends them in sequence.

The FIR and FIN bits in the application control byte mark the boundaries: FIR on the first fragment, FIN on the last, and neither on the middle ones. The application sequence number increments across them so the master can detect a lost or duplicated fragment. This is a different mechanism from the transport function below, which segments a single fragment across link frames; fragments are an application-layer concept, transport segments are one layer down.

Fragments, Confirmation, and Event Delivery

Multi-fragment responses interact directly with confirmation. When a fragment carries events and the outstation sets the confirm-requested bit, the master must return an application confirmation before those events are considered delivered and cleared. On a multi-fragment response the master typically confirms each fragment, which paces the transfer and guarantees no events are lost mid-stream.

This coupling is why fragment size is a tuning parameter, not just a limit. A larger maximum fragment size means fewer round trips for a big poll but a bigger loss if one fragment fails; a smaller size means more confirmations but finer recovery. On slow links this trade-off is felt directly, which is one reason a well-planned DNP3 outstation weighs fragment size alongside deadbands and integrity poll frequency.

Fragment, Segment, Frame: Keeping the Layers Straight

Three different words describe three different units of chunking, and DNP3 confusingly uses the names FIR and FIN at two of the layers. A fragment is the application layer's unit: one function code plus object data. The transport function splits a fragment into segments, each prefixed with its own one-byte header. The data link layer then wraps each segment in a frame with addressing and CRC protection. When you decode traffic, keep asking which layer's boundary you are looking at.

A compact reference:

Unit	Layer	Boundary markers
Fragment	Application	FIR and FIN bits in the application control byte, plus an application sequence number
Segment	Transport function	FIR and FIN bits in the transport header byte, plus a 6-bit sequence
Frame	Data link	Start octets, length field, and CRCs on each data block

The two sets of FIR and FIN bits are independent. A single-fragment response can still span many transport segments, and each segment's FIR and FIN say nothing about where the application fragment begins or ends.

Setting the Maximum Fragment Size

Both the master and the outstation declare a maximum fragment size they can transmit and receive, and those limits are documented in each device's device profile. The values are configuration, not negotiation: nothing at runtime discovers a mismatch for you. If an outstation is configured to build larger fragments than the master can reassemble, the symptom is a master that discards or errors on big responses while small ones work fine - a classic commissioning trap that only appears the first time an integrity poll returns a full point database.

The standard also requires a request to fit within a single fragment, so in practice fragmentation is a response phenomenon. When choosing a size, think about the channel underneath. On a constrained or lossy serial path, smaller fragments mean a lost exchange costs less to repeat; on a healthy TCP link the trade matters much less. Fragment size also interacts with how many events the outstation accumulates between polls, so it is worth reviewing alongside the event buffer configuration rather than in isolation. An outstation that buffers a large number of events but is only allowed small fragments will need many exchanges to drain after an outage, stretching out recovery time exactly when the master is trying to catch up on everything at once.

What a Multi-Fragment Exchange Looks Like on the Wire

Walk through it symbolically. The outstation sends the first fragment with FIR set, FIN clear, application sequence n, and, if events are aboard, the confirm-requested bit set. The master returns its confirmation, and only then does the next fragment arrive carrying sequence n plus one with neither FIR nor FIN. The final fragment arrives with FIN set. Watching the application sequence numbers tells you whether you are seeing forward progress or a retry: a repeated sequence number is the same fragment again, not a new one.

Stalls have a recognizable shape too. If the outstation is waiting on a confirmation that never comes, the exchange simply stops mid-response until a timeout expires, after which the master must start over. And because the application layer has no selective retransmission, losing one middle fragment means the master re-requests the whole response - there is no way to ask for just the missing piece. That is why a multi-fragment transfer on a marginal link can fail repeatedly at the same point, and why shrinking the maximum fragment size is sometimes the fix that finally lets a large poll complete.

Frequently Asked Questions