The thing that goes wrong
Almost every nurse call hands off to a messaging platform to reach DECT handsets and smartphones, and the link between them runs one of two protocols: TAP, the decades-old paging protocol, or MQTT, the modern publish/subscribe one. Both can work for years. Both can also stop delivering while every log, every status light and every network tool still says the link is up — which is exactly what happened at a Victorian hospital, nurse calls and fire-pump alarms alike, until a nurse wondered why the phone never rang.
The failure isn't the protocol. It's the difference between a message left here and a message arrived there — and whether anyone is watching the path when no calls are happening.
TAP: an acknowledgement that doesn't mean what you'd hope
TAP (Telocator Alphanumeric Protocol) is a plain, line-based protocol: the nurse call opens a connection, logs on, sends a block of message text, and the paging side answers with an ACK or a NAK. That ACK feels like proof of delivery. It isn't. It means the receiving process read the bytes — not that a pager, a handset or a human ever got the page.
Three gaps do the damage, and we have watched all three on the bench against real paging software:
- No heartbeat. Classic TAP links only talk when there's a call. Go a quiet hour with no calls and nothing tests the path — so a receiver that has silently stopped forwarding pages looks identical to one that's simply having a quiet hour. The first test of the link is a real emergency.
- Half-open sockets. If the far end restarts or a firewall drops the flow, TCP can leave the sender holding a socket it believes is open. Writes succeed into a buffer that goes nowhere; no error is raised. Many TAP senders only reconnect when the OS hands them an explicit socket error — which a half-open connection never does.
- Logs before it sends. Paging software commonly records "page sent" at the moment it queues the page, before the wire write and well before any ACK. The log then proves intent, not arrival — so the audit trail agrees the page went out even when it didn't.
None of this makes TAP unusable. It makes unsupervised TAP dangerous: the protocol has an ACK, but on its own nothing exercises the path between calls, nothing confirms end to end, and nothing fails loudly.
MQTT: better primitives, same trap if you ignore them
MQTT replaces "dial and dump" with a broker everyone connects to and a set of tools built for exactly this problem — if they're switched on:
- Keepalive. Each client agrees an interval and sends a
PINGREQwithin it; miss it and the broker declares the client dead. A half-open socket is detected in seconds, not at the next emergency. - Last Will & Testament. A subscriber registers a "will" when it connects; if it drops without saying goodbye, the broker publishes that message for it. The messaging platform going away becomes an event the nurse call can see, not a silence it has to guess at.
- QoS 1 and 2. At QoS 1 the broker must
PUBACKa message or the sender resends it; QoS 2 adds a four-step handshake for exactly-once. Delivery to the broker is confirmed and retried, not assumed. - Retained messages. The current state of a point can be held by the broker so a handset that reconnects is told the latest immediately, instead of waiting for the next change.
But MQTT is not magic, and two honest caveats matter. First, QoS confirms delivery to the broker, and then from the broker to a subscriber — it still does not prove a human saw the page; that needs an acknowledgement from the app, not the transport. Second, every one of those features is optional: an MQTT link run at QoS 0 with a long keepalive and no will is no better supervised than bare TAP. The protocol gives you the primitives; using them is a design choice.
What actually makes a page trustworthy
The protocol matters less than three properties on top of it. A paging link you can trust has all three, whichever protocol carries it:
- Per-page confirmation. Every page is acknowledged by the receiver, resent if it isn't, and a page that still won't land raises a fault within seconds — never logged as sent and forgotten.
- End-to-end supervision when nothing is happening. A heartbeat travels the whole path — ideally a page to a test ID that must come back — every minute, so a broken link shows as a fault at 3am on a quiet ward, not when the next real call is missed.
- Fail loud, fail to a known state. A lost link is an alarm, not a silence. A restart at either end starts a clean session rather than inheriting a dead one.
How Southerly does it
Supervised either way, and honest about the limit
The Enterprise Gateway speaks native TAP to Olinqua and Ascom and publishes MQTT for platforms that prefer it — and supervises both the same way: every page acknowledged and retried, a heartbeat proving the path end to end every minute, a fresh session per connection, and a fault raised to maintenance within seconds when the path can't be proven. Paging Link PL-01 is this supervision as a drop-in box for a hospital's existing paging, confirmed delivery without replacing the call system. The honest limit: supervision proves the page reached the messaging platform and came back — the last hop to a human still belongs to that platform and the handset in a pocket.
The short version
TAP's ACK proves bytes were read, not that a call arrived; MQTT has the tools to do better but only if keepalive, wills and QoS are actually used; and neither protocol, on its own, tells you the path is healthy when no calls are flowing. Confirmed delivery and end-to-end supervision are what turn "we sent it" into "we know it arrived" — and on a nurse call, that is the whole job.