Engineering

Sizing a protocol gateway: points, southbound legs and CPU budget

2026-10-29 · 7 min read

Gateway specifications are usually written as a point count, which is the least useful number available. What decides whether a gateway works is the event rate, the number of southbound legs, and how much of the traffic requires translation rather than forwarding — and those three interact in ways a point count cannot express.

Why the point count misleads

A gateway with 20,000 points changing once an hour is idle. A gateway with 2,000 points changing 50 times a second is saturated. Both are described as "20,000 points" in a specification, and one of them will not work.

Start from events per second per leg, and from the worst case rather than the average: the moment a bay trips, dozens of points change within milliseconds.

The three budgets

• CPU: every event costs parsing, translation and building the northbound message. Translation usually costs more than parsing, because it involves lookups in the mapping table and quality conversion.
• Network: southbound traffic plus northbound traffic plus retransmissions. A 61850 southbound leg with reporting is not symmetric with a 104 northbound leg with its own retransmission behaviour.
• Memory: one association per southbound leg, each with its own buffers, plus the mapping table per point, plus per-client state on the northbound side.

Southbound legs are not additive

Ten devices with 500 points each is not the same as one device with 5,000 points. Each leg means an association with its own timing, its own failure and recovery, and its own model to parse and keep in memory. Gateways typically saturate on leg count and event rate long before they run out of points.

Measuring instead of guessing

Before committing to a specification, measure four things on realistic data:

• Events per second sustained, with the northbound client actually consuming them — not with a null sink.
• Latency from southbound change to northbound transmission, as a percentile, under that load.
• Recovery time after a southbound leg drops and returns, including the general interrogation that follows.
• Memory slope over 24 hours at constant load, which is where per-event leaks show up.

Headroom is a feature

Specify a gateway at no more than half of its measured capacity. The remaining half is what absorbs the data storm on the day something trips, the extra points a customer adds in year two, and the firmware update that makes reporting slightly chattier. A gateway sold at 95% of measured capacity will be blamed for every latency complaint in the station, and the complaints will be justified.

Questions that come up

How many northbound clients should a gateway support?

Count them as a real cost: each client may enable its own reporting, so three clients can triple the reporting load. Two is common, and anything beyond three needs to be measured rather than assumed.

Does protocol translation cost more than protocol encoding?

Usually yes. Building the message is mechanical; deciding what the value means in the other model — quality mapping, scaling, timestamp handling — is where the CPU and the defects are.

What is the first sign of an undersized gateway?

Growing latency under peak load with no packet loss, followed by report buffer overflows. By the time packets are being lost, the box has been saturated for a while.

Keep reading