What Is a Communication Protocol? Rules, Types, Examples

A communication protocol is a set of rules and formats — both syntactic and semantic — that determines how two peer entities behave when they exchange data. Two devices that follow the same protocol can work together. Two devices that don’t follow the same protocol cannot communicate reliably, even if the physical connection is perfect.

That definition sounds abstract. It stops being abstract the moment you have a PLC on one end of a link and a gateway on the other, and nothing comes back.

Service and protocol are two different things

This is the distinction most explanations skip, and it’s the one that clears up the most confusion.

A service is what a layer offers to the layer above it. It’s the user’s view. It says what you can ask for: send this data, open this connection, tell me when it arrives.

A protocol is how peer entities at the same level cooperate to deliver that service. It’s the implementer’s view. It says what bytes go on the wire, in what order, and what each side does when it receives them.

Same layer, two viewpoints. The service description covers models, data types, and what each operation does. The protocol specification covers encoding, syntax, and the state machines that run the exchange.

Why it matters in practice: when a vendor says a device “supports” a protocol, they may mean it implements a subset of the services. The protocol can be identical and the device still won’t do what you need, because the service you’re calling was never implemented.

The boundary between two layers is where a service is defined. The behavior inside a layer is where a protocol is defined.

What every protocol has to specify

Three things. Miss any one and interoperability fails.

Syntax — the format. Field order, field width, byte order, encoding, how a frame starts and ends. Two devices can agree that a value is a 32-bit float and still fail because one sends it big-endian and the other reads little-endian.

Semantics — the meaning. What each field represents, and what the receiver is supposed to do about it. A function code isn’t just a number; it commits both sides to a defined behavior.

Timing — when. How fast a sender may transmit, how long a receiver waits before it gives up, what the retry interval is. Timing is where most field problems actually live. The syntax is fine, the semantics are fine, and the master times out because the slave needed 40 ms and the timeout was set to 20.

A protocol that specifies nothing is not allowed to exist inside a layered architecture. Every layer has to add something.

How a message actually moves

Here’s the part that’s usually hand-waved.

Two peer entities never touch each other directly. They cooperate by using the service of the layer below. So an exchange has two axes: horizontal, between peers running the same protocol, and vertical, between adjacent layers in the same device.

The four primitives

A confirmed exchange has four steps:

1. Request — the upper-layer user asks its local protocol entity to do something. The entity creates a transaction state machine, assigns it an instance identifier and a timeout, builds the message, and sends it.
2. Indication — the receiving entity decodes the message. If there’s no protocol error, it creates its own transaction state machine with its own instance identifier, and hands the request up to its user.
3. Response — the remote user processes the request and returns a positive response, or a negative one carrying a reason for failure.
4. Confirmation — the originating entity matches the returned message to its state machine using the original instance identifier, delivers success or failure to the requesting user, and cancels the transaction.

If the timer expires before anything comes back, the originating entity delivers a negative confirmation on its own and cancels the transaction. That’s a timeout. From the requester’s point of view it looks the same as a rejection, which is why timeouts and protocol errors get confused so often in the field.

An unconfirmed exchange has two steps: request and indication. There’s no response path and no state machine waiting on the far end. Broadcasts and most publish operations work this way.

Encapsulation

Data doesn’t just pass down the stack. Each layer wraps it.

A layer takes the block handed to it from above — the service data unit, whose contents it does not interpret — and adds its own protocol control information, the fields its peer needs to coordinate. The result is a protocol data unit.

That protocol data unit is then handed down and becomes the service data unit of the next layer, which adds its own control information. And so on, down to the physical medium.

At the receiver, the same thing runs in reverse. Each layer strips its own control information and passes the payload up.

Three variations on the basic mapping are worth knowing:

• Segmenting — one service data unit is split across several protocol data units, because the block from above is bigger than the layer can carry. Each fragment needs enough control information for the peer to reassemble it.
• Blocking — several service data units are packed into one protocol data unit.
• Concatenation — several protocol data units are packed into one service data unit of the layer below. This is how an acknowledgment gets to ride along with a data message instead of costing a separate transmission.

Fragmentation problems in the field almost always trace back to segmenting: one layer’s maximum size doesn’t match another’s, and the mismatch only shows up when a payload crosses the threshold.

Layers, and why there are seven of them

The seven-layer reference model exists because splitting a hard problem into independent pieces lets each piece change without breaking the others.

The layer boundaries weren’t arbitrary. They were placed where the description of the service could stay small and the number of interactions across the boundary stayed low. Where functions were clearly different in nature or technology, they went into separate layers. Where a layer might need a total redesign later without disturbing its neighbors, that was a reason to make it a layer.

One correction worth making, because it comes up constantly: RS-232 and RS-485 are not protocols. They are physical layer specifications — voltage levels, connector pinouts, driver characteristics. Modbus RTU is a protocol that commonly runs over RS-485. The two are often named in the same breath and they sit at different levels entirely.

Connection-mode and connectionless-mode

Every protocol works in one of two modes, and the difference drives almost everything else about its behavior.

Connection-mode runs in three phases: establishment, data transfer, and release. Before any data moves, the two ends negotiate. They agree on parameters and options. They get a connection identifier, which means the addressing overhead doesn’t have to be repeated on every transfer. And because there’s a context, successive data units are logically related — the protocol can maintain sequence and apply flow control.

Connectionless-mode sends a single self-contained unit of data with no setup. Everything needed to deliver it — destination address, options, quality of service — is presented in one shot along with the data itself. Each unit is routed independently. There’s no requirement to preserve order between units, and no peer flow control.

Connection-mode suits long-lived, stream-oriented exchanges. Connectionless-mode suits short, independent messages where setup cost would dominate.

Both modes still need a pre-arranged association: each side has to know the other’s address, know which protocol to use, know the peer is available, and know what quality of service to expect. Connectionless-mode doesn’t skip this — it just doesn’t negotiate it dynamically.

Version negotiation

Version negotiation is only possible in connection-mode. The calling entity announces the versions it supports; the called entity picks the latest version they have in common. No common version means the connection is refused.

Connectionless-mode has no negotiation. The version is either known in advance or carried explicitly in each message. This is one reason connectionless protocols age awkwardly — there’s no handshake in which to sort out a mismatch.

Common communication protocols

How data gets exchanged: the four models

Beyond the mode, protocols differ in how they schedule traffic.

Client/server, continuous cyclic. A predefined sequence of exchanges repeats without stopping. Predictable load, predictable worst case. This is classic polling.

Client/server, time-based schedule. Exchanges happen at defined points in a schedule rather than in a free-running loop. Better when several data flows have to be coordinated.

Publisher/subscriber, time-based. A publisher sends on a schedule; every subscriber receives. One transmission serves many consumers instead of one poll per consumer.

Publisher/subscriber, event-driven. Nothing is sent until something changes. Very efficient when data is mostly static, but the worst-case load is harder to bound, because a burst of events can arrive together.

The rule when configuring any of these: the repetition interval for an important action has to be shorter than the sampling interval the application needs. Get that backwards and the control loop is reading stale data no matter how healthy the network looks.

Quality of service

Quality of service is the collective name for the parameters attached to a data transfer. In connection-mode they’re negotiated at establishment. In connectionless-mode they’re defined by the behavior of each single transmission.

Parameters that apply to both modes:

• Expected transmission delay
• Probability of corruption
• Probability of loss or duplication
• Probability of wrong delivery
• Cost
• Protection from unauthorized access
• Priority
• Expected throughput
• Probability of out-of-sequence delivery

Connection-mode adds a few of its own: connection establishment delay, establishment failure probability, release delay, release failure probability, and connection resilience.

Worth noting that protection from unauthorized access appears in that list. Security was treated as a quality of service parameter from the beginning, not as something bolted on afterward.

Communication protocols in industrial networks

Industrial networks change the priorities. On an office network, the goal is throughput. On a control network, the goal is a bounded, repeatable response time.

An industrial control network has to be deterministic, reliable, and dependable. Response times have to stay inside the time constants of the application being controlled. The spread is wide:

• Motor and motion control — microseconds
• Flow and pressure control — milliseconds
• Liquid level — seconds

Devices on such a network share two properties: they take part in one common user application controlling a process or machine, and network resources are allocated by a single access schedule, or a set of coordinated access controls sized to meet the required control performance.

The consequence is that industrial protocol stacks are often shorter than the seven-layer model. In fieldbus specifications, the functions of layers 3 through 6 are folded into either the data-link layer or the application layer, or handled by a separate layer entirely. Fewer layers, less per-hop processing, tighter timing.

Two more differences matter:

Protocol and profile are not the same thing. Most industrial protocol types include a large range of selectable and configurable options, and only certain restricted combinations actually interwork. A profile is a specific, tested combination of those options. Two devices can both claim the same protocol and still fail to communicate, because they implement different option sets. When you specify equipment, the profile is the thing to check, not just the protocol name.

Outputs act on the physical world. A control network drives actuators. A wrong output can hurt people, damage equipment, or damage the environment. That’s why industrial networks are designed to hold their target performance across the whole life cycle, and why external connections go through a gateway or proxy that filters and manages requests rather than a straight bridge.

Industrial control networks either run closed, or include a controlled mechanism for exchanging data with other networks. Security measures belong on every external connection.

FAQ

Is a communication protocol the same as a standard? No. A standard is a published document. A protocol is the set of rules the document describes. One standard can specify several protocols, and a widely used protocol can exist without a formal standard behind it.

What’s the difference between a protocol and a profile? A protocol defines the rules and formats. A profile selects a specific, tested combination of that protocol’s options so devices actually interoperate. Two devices running the same protocol with different option sets will not necessarily work together.

Is RS-485 a communication protocol? No. RS-485 is a physical layer specification covering electrical characteristics and signaling. Modbus RTU and other protocols run over it.

What does connectionless mean? Each message is sent as a single self-contained unit with no setup and no teardown. Delivery order is not guaranteed and there’s no peer flow control. UDP and IP are connectionless.

Why do protocols have version numbers? Because functions get added, removed, or changed. A new version becomes necessary when the change is significant enough that a device using the new specification could no longer communicate with a device using the old one. In connection-mode, the two ends negotiate and settle on the latest version they share.

How many communication protocols are there? Hundreds in common use, and thousands if you count proprietary and legacy ones. The number is less useful than knowing which layer each one sits at and which mode it works in.

Why do industrial protocols use fewer layers? To reduce processing time per message. Fieldbus stacks typically consolidate the functions of layers 3 through 6 into the data-link or application layer, which shortens and stabilizes the response time.