Paging all pagers: the many methods of alphanumeric paging

  tech telecom

7 min read | 1921 words | 11 views | 0 comments

As time went on, provisions were added to carry additional information with the "page", such as a numeric message (or in a more eccentric implementation, actual voice). This allowed communicating information as part of the page, rather than simply informing the recipient that a message was waiting somewhere, and was also easier on the person sending the page, since the two steps of leaving a message and then separately paging someone were combined. This gave way to "numeric paging", a method of paging that has endured for decades now. Call somebody's pager numer and enter your callback number (or some other numeric message), and a tiny screen on the recipient's pager would display this information. For a time, this capability was particularly reviled by drug dealers (so much so that in the 1990s, rotary payphones were reinstalled in New York City to foil drug dealers).

The most recent evolution of paging has been the proliferation of alphanumeric paging, a now standard capability supported by most pagers and commercial paging providers. Two-way paging is another development, but support and coverage for this service tends to be quite poor, so as a matter of practice, one-way alphanumeric paging is the dominant form of paging that remains in use today.

This begs the question: how does one send an alphanumeric page to a pager? The conventional method of dialing the pager number and entering a message using the TouchTone keypad doesn't afford a way to send alphabetic characters. Nonetheless, this concept has been inaccurately portrayed in popular media, most notably (to me) in the all-time popular TV show Columbo, in later episodes of which pagers were featured on multiple occasions.

Take the quintessential Columbo paging scene from Columbo Cries Wolf (1990). In this famous scene (spoiler alert), Columbo dials the victim's pager number, dials a few digits, and hangs up, then reveals the alphanumeric message "GOTCHA".

This seems like the perfect ending to another great episode of Columbo — except for the fact that what Columbo did was impossible. There is no way, by dialing a pager's telephone number, that you can send an alphanumeric message by simply pressing a few buttons. Even mobile devices that allow sending text messages using a numeric keypad generally require multiple key presses per letter (and also provide visual feedback so the user can see what he's typing). Thus, the idea that Columbo could have sent this message from a standard telephone is completely absurd.

Pagers made another notable appearance in the very last episode of Columbo, Columbo Likes The Nightlife (2003). An alphanumeric message is again being shown received by someone, although in this episode, the act of sending the page is not shown, so I can't say for sure that its portrayal was inaccurate.

Columbo couldn't have sent such a message using a standard telephone, but clearly, if alphanumeric pagers existed, there must have been some way to send alphanumeric messages to them. Indeed, there was. The protocol for doing so was known as TAP/IXO, or usually just TAP, which stands for the Telocator Alphanumeric Protocol. TAP is a modem-based protocol that allows the transmission of alphanumeric pages, typically at 300 baud (although 1200 bps transmission is theoretically supported). Unlike conventional modem communications, 7E1 (7 data bits, even parity, 1 stop bit) is used for TAP.

The protocol that became TAP was first standardized in the late 1980s, and the latest version of TAP was specified in 1997. The protocol has remained essentially unchanged for three decades now. So have the devices that were designed to send pages using TAP, most notably the Motorola AlphaMate series of paging access terminals, first introduced in the early 1990s. In conjunction with this post, I have recorded a video demonstrating how an AlphaMate terminal would be used to deliver a page (as well as a companion video demonstrating sending a page from a TDD).

Effectively, the AlphaMates are "TAP clients", which dial in to the paging provider's "TAP server" and transmit the pages to deliver using the TAP protocol. The AlphaMate can be set up to operate in batch mode to operate more efficiently, reducing the time the phone line would be in use for paging purposes. The AlphaMate II is what is featured in the demo, but the AlphaMate 250, a slightly newer model from the late 1990s, is still supported and serviced by a company today. By extension, yes, that means there are still businesses out there using these terminals to send pages. When these were new, they were very convenient for sending pages to multiple recipients at once, managing a paging queue and retrying pages, and handling support for multiple paging providers. And it's not surprising — their simplicity and ease of use has aided their longevity. It's likely that AlphaMates, where still in use, have probably been in use to transmit pages to individual or groups of pagers for decades.

That said, pages today are typically sent by other methods besides TAP. RFC 1861 in 1995 specified the "Simple Network Paging Protocol", a protocol similar to SMTP as used for email, but optimized for the unique requirements and features of paging. SNPP retained many of the concepts first introduced with TAP and extended them further, including with extensions for 2-way paging. And today, commercial paging providers often allow you to send pages to their users by email, SMS, or even online web forms. Nonetheless, TAP allows pages to be sent without an Internet connection, and to this day, most paging providers continue to support it. Spok supports essentially every paging method you can think of: TAP/IXO, SNPP, SMTP (email), SMS, web form, and of course, simply dialing the telephone number and leaving a numeric message.

That being said, TAP and SNPP are generally the canonical methods of paging typically supported by the paging terminals in use at commercial paging providers, often directly adjacent to (or part of) the equipment that queues the pages to go out on RF to the pager. Later methods like email are generally a bolt-on to an existing system, and ironically, don't always work as well as the older methods. To test this, I ran an experiment in which I sent identical pages to Spok via TAP/IXO, SNPP, and SMTP and timed how long it took from the moment the protocol "accepted" the page for delivery and the time the page actually arrived at my physical pager. Pages have to be queued to go out on RF, since this is a shared resource, so queueing naturally adds some variability to the time. To accomodate for this, I did 10 trials for each method and compared the results. Here are some aggregate stats on how long delivery took, in seconds:

A clear trend emerges from this data. SMTP generally takes noticably longer than either SNPP or TAP. This may be somewhat surprising at first, given that SMTP is an Internet based protocol, rather than a modem-based protocol like TAP. But remember that the timing here is from the time that the message is fully received by the protocol, so this actually excludes the "time on the wire" to receive the message, which in the case of TAP, is non-neglible, particularly for longer messages. Still, in practice, this time is rarely longer than a couple seconds.

One likely explanation for the "SMTP penalty" shown here is that email is significantly more complicated than either TAP or SNPP. Additional post-processing is also performed; Spok, for instance, will include the name of the email sender and the email subject as part of the page, something that isn't applicable to TAP or SNPP (SNPP technically does support the ability to provide this metadata, but Spok's implementation of it does not). Spam filtering, if performed, will likely add further delay to message processing. Finally, email is likely received by a separate system, then sent to the paging terminal via another method (most likely SNPP, which should be instantaneous).

(There is another paging protocol as well, TNPP (Terminal Network Paging Protocol), although this is generally only used for certain communications within a paging provider's infrastructure — it's not for consumers or businesses to "submit" pages to the paging provider for delivery.)

Given the data above, it would appear that SNPP would be a clear winner compared to SMTP. I would generally agree, although there are some edge cases to consider. SNPP as specified in RFC 1861 does not support encryption, which was still fairly nascent in 1995. This means if you are sending sensitive data, SNPP may not be ideal (and although many pages are still sent in cleartext over the air, many providers, including Spok, do support encrypted paging, and my own pager is encrypted). For these use cases, SMTP has the advantage of supporting STARTTLS. In my own SNPP implementation, I have also added STARTTLS support, which will be used whenever possible; however, commercial paging providers don't support it and aren't likely to, so for sensitive pages, SNPP for final delivery to the paging provider might be better avoided. In an ideal world, SNPP would be revised to formally include encryption support, though given the level of stasis in the paging business day, I don't foresee this as being all that likely to happen.

Thus, as with many things, there are pros and cons of the various paging protocols. SNPP is the most "efficient" and optimized for paging, but as implemented by commercial providers like Spok, encryption in transit is not supported. SMTP supports encryption but suffers the "email processing penalty". And TAP has the virtue of not being an Internet protocol at all and thus being viable for sending pages without an Internet connection, but page transmission is considerably slower than either SNPP or SMTP since it runs at 300 baud, though ironically, TAP could still end up being faster than SMTP in some cases, particularly for short messages, if call setup and transmission take less than the ~5 second penalty incurred, on average, by pages sent via SMTP.

In my own paging plans, I make use of all three protocols as appropriate. My own preference is to use SNPP between my own systems (which support my custom STARTTLS extension for SNPP), SNPP when sending pages to Spok in general, SMTP to submit sensitive pages, and TAP/IXO as delivery method when or where a broadband connection is unavailable (or as a fallback method). The LBBS bulletin board system package now includes modules to support SNPP, SMTP, and TAP/IXO for both sending and receiving pages, and users can create simple paging plans to process receive messages or relay them to another protocol. As a bonus, I've also paired with this the ability to submit pages via a simple protocol from TDDs, which I've dubbed the TDD Message Protocol, or TMP. TDDs are often available by courtesy phones in airports or other public places, and this provides a simple and quick way to send a page to a single user, as compared to an AlphaMate using TAP, which is a bit more heavyweight.