What Is DNP3 Broadcast Addressing?

Back to Blog

The Reserved Broadcast Addresses

Every DNP3 outstation has a unique link address, and a master normally puts that specific address in the destination field of a frame. Broadcast addressing uses reserved addresses instead. The all-stations broadcast is 0xFFFF, with 0xFFFD and 0xFFFE reserved as broadcast variants that differ in whether an application-level confirmation is requested. When an outstation sees a broadcast destination, it recognizes the frame as addressed to every device, not just itself.

This is a different mechanism from the ordinary unicast addressing covered under DNP3 master and outstation addresses. Those addresses identify one device; the broadcast addresses identify all of them at once. It parallels how Modbus broadcast at address 0 reaches every slave, though DNP3 uses reserved high addresses rather than address zero.

Why Broadcasts Get No Reply

A broadcast frame is deliberately unconfirmed. If every outstation replied to the same frame, their responses would all transmit at once and collide on a shared serial or radio link, garbling each other. So the rule is that outstations perform the requested action but do not send a response to a broadcast. The master gains simultaneity at the cost of acknowledgement.

That trade-off shapes what broadcast is good for. It suits fire-and-forget, whole-site operations where doing the action at the same instant matters more than confirming each device did it - the classic case being a simultaneous counter freeze so all totals share one timestamp, or a broadcast time-set. It is not used for critical control of a single output, where you need the confirmation of a directed command. When simultaneity is the goal, broadcast is the tool; when acknowledgement is the goal, a unicast request to each outstation is.

Broadcast and Unicast Side by Side

Behavior	Unicast request	Broadcast request
Destination field	The outstation's unique link address	A reserved address: 0xFFFD, 0xFFFE, or 0xFFFF
Who acts on it	One outstation	Every outstation that hears the frame
Reply	A solicited response comes back	No response frames; confirmation behavior follows which reserved address was used
Best suited for	Polls, reads, and confirmed controls	Simultaneous whole-site actions such as freezes and time-sets

The table is worth internalizing because the failure modes differ. A unicast request that goes unanswered is visible immediately: the master times out and retries. A broadcast that an outstation missed is invisible by design - nothing in the exchange tells you a station slept through it. Whatever you use broadcast for must either tolerate an occasional miss or be followed by a check, which is what the follow-up pattern below is for.

What Changes on Serial, TCP, and UDP

Broadcast is a link-address concept, so how it physically fans out depends on the transport underneath. On a multidrop serial or radio channel the picture matches the intuition: one frame goes out, every outstation on the channel hears the same bits at the same moment, and the simultaneity is genuinely physical. That is the environment the mechanism was designed for.

Over TCP the situation differs, because TCP connections are point to point. A master that wants to broadcast sends a frame carrying the broadcast destination address down each outstation's connection in turn, so every station still recognizes and acts on a broadcast frame, but the copies arrive separately and the actions are only approximately simultaneous. UDP can carry a single datagram toward multiple stations where the network supports it. If tight simultaneity across stations is the whole point of the operation, the transport matters as much as the addressing - the trade-offs are covered in more depth under DNP3 over serial vs TCP.

A Follow-Up Pattern That Confirms the Unconfirmed

Because broadcasts get no reply, disciplined masters pair them with a verification pass. Take the classic case, a simultaneous counter freeze across a site. The sequence: the master sends one broadcast immediate-freeze request; every outstation copies its running counters into its frozen counters at that shared instant; then the master polls each outstation one by one over unicast to read the frozen values back. The simultaneity came from the broadcast, and the confirmation comes from the follow-up reads - any outstation whose frozen values are absent or visibly stale did not act, and can be frozen and read individually.

Time-set broadcasts have their own indirect confirmation. An outstation whose clock still needs setting raises an internal indication flag in its subsequent responses, so the master learns which stations remain unsynchronized the next time it talks to them. How that fits into the wider clock discipline of a system is covered under DNP3 time synchronization.

Cautions Before You Reach for Broadcast

1. Confirm from device documentation that every outstation on the link supports the function you plan to broadcast - stations that do not will silently ignore it.
2. Remember the frame reaches every station on the link, including ones you forgot were there; broadcast has the widest blast radius of any request a master can send.
3. Do not use broadcast for output controls; controls belong on confirmed unicast exchanges to a named station.
4. If the system runs secure authentication, review how your implementation handles broadcast before relying on it.
5. Coordinate whole-site actions like time-sets with site procedures, since every log and event timestamp downstream will feel them.

None of these are reasons to avoid broadcast - a whole-site freeze remains the cleanest way to get totals that share one instant. They are reasons to treat it as a deliberate, occasional operation rather than a routine one, and to keep the follow-up reads in place so that silence never gets mistaken for success.

Frequently Asked Questions