TNPP History

Part 1 — Version 3.0

By John F. Nagel — August 18, 2011

Protocols often have an interesting story behind how they came into existence; the Telocator Network Paging Protocol (TNPP) is one of those. This article discusses the events that took place to bring version 3.0 of the TNPP specification into existence and as a paging industry standard.

It’s been “a while” so I will apologize in advance if I leave someone out who was involved or get a date and/or name incorrect. The information in this article is from Quintron Corporation’s view point.

The current release of the TNPP specification is version 3.8.1. Does anyone remember an earlier version than 3.0? The answer to that question would be “no”, because the protocol was not named TNPP until version 3.0. Version 2.5 was the second version of the protocol that was submitted to the Telocator Protocol Committee, whose charter was to develop/standardize a protocol that would allow paging terminals from different manufacturers to exchange paging data traffic as well as control and alarming information.

In mid 1984 a group of Quintron Corporation Sales, Marketing and Engineering people got together for a meeting to review and discuss a customer’s Request For Proposal (RFP). The company that submitted the RFP was National Satellite Paging (NSP – later became Mtel and then SkyTel). NSP was interested in purchasing paging base stations and control system equipment to construct a nationwide paging system, which would be the first of its kind. As a company that sold paging infrastructure, we knew that this RFP was significant, not only to Quintron, but to the paging industry as most systems operating at that time were city wide and regional systems. NSP’s system designed was to have a single-message-input computer whose output would be fed over a satellite link to multiple remote paging encoder sites that would feed a local link system to the paging base stations. (I believe that the single computer system was developed by Paul Keegan of Houston based SAE.) NSP’s plan was to start off small and build the system out over time. The main focus for the first phase of the system was to cover the top 50 major city airports.

As you might know or guess, I worked for Quintron Corporation at that time and was one of the Engineers that attended the RFP review meeting. The Director of Marketing, Dennis Cameron, headed up the meeting with Sales Engineer, Ken Knapp who was the Sales Rep responsible for the NSP account. Steve Maddy, a Quintron Engineer, and I were assigned the task of developing a plan that would allow us to utilize Quintron’s existing control system and base station equipment such that it would meet the requirements described in NSP’s RFP. And, as usual, the Marketing and Sales people were anxious to make the sale, so they didn’t give us much time to produce a plan.

Steve and I contacted the head System Engineers at NSP, Bill Hays and Jim Dombrouski, to discuss questions that we had and to get more detail about this “Nationwide Paging System” that they were planning to implement. We received the answers to our questions and then some. There were several significant comments given during that call, which turned out to have a significant influence on the development of the protocol that would be used for their nationwide system. Those comments are described as follows:

• The system needed to be designed such that it could start out simple with low to moderate system throughput and then be easily expanded to accommodate higher throughput. The model given was, for the first phase of their implementation, a system that would consist of multiple single-local-coverage paging systems that would receive their paging traffic from a one-way satellite link.
• The system would use Equatorial’s one-way satellite system for a link to the multiple system locations.
• The system should be designed so that RF paging field technicians could work on the system, including the link system, with current paging system test equipment.
• They indicated that this was the first nationwide system, a startup business and that it might or might not be successful. Therefore, cost was a big factor. They didn’t want — or need — to purchase standard paging terminals for each location, but were looking for small encoders that could be placed at each satellite downlink.

Loaded with all the requisite requirements we went off to the chalk boards (we didn’t have high tech white boards in those days).

The Quintron product line only included paging base stations and paging control systems, which meant that we had to either develop a paging encoder/terminal or partner with an existing paging terminal manufacturer, which at that time there were many to choose from. It was determined that a partnership with an existing paging terminal manufacturer would be the most economical solution. We contacted Tim Minter of Unipage, who was located in the Dallas area, and scheduled a technical review meeting. Prior to our departure to Dallas, Steve and I worked on designing the framework for a communications protocol that could be used to transmit the paging data over the satellite link to the remote paging encoders/terminals. Keeping in mind the above 4 points, system expansion, one-way satellite link, simplicity and cost, we decided to focus on using the ASCII standard over an RS-232 serial link. Using these two standards would fit with the satellite input and would allow the field technicians to use dumb terminals (For those that were not around then these were CRTs with a serial RS-232 interface, typically with an amber or green screen.) as protocol analyzers to test and troubleshoot the link/protocol system. In those days we were aware of the Seven layer OSI Reference Model, though certainly not experts in that field, we believed that it was a little over complicated for the task at hand. Armed with the RFP, the beginnings of a protocol design and some other ideas, we headed to Dallas for our meeting with Tim.

The meeting in Dallas went very well. As it turned out Unipage was also working on a simple protocol that would allow paging terminals from different manufacture’s to share or exchange paging traffic and also had a single board paging encoder. After several hours of technical discussions we decided that we would build a couple of option PCB cards that would plug into the Quintron Omega DCU II paging system controller. These option cards would provide pager output encoding and data message routing. The agreement was that Quintron would develop the hardware and Unipage would develop the software. We also determined that the first draft of the protocol design would require more CPU capacity than we had available to us for the option cards and it needed to be simplified. During the meeting we re-worked the structure of the protocol and came up with what is now listed in the TNPP spec, a simple header with multiple data block types, ending with a CRC. At this meeting, we discussed the possibility that the new protocol could meet the requirements of an industry standard and agreed to add features beyond what was required for NSP. In fact, NSP only required one-way data as the data was to be delivered over a 1-way satellite link. This is why the TNPP one-way mode with options of repeats was part of the protocol. During the meeting, Tim took notes on a small laptop computer (NEC8201), of all of our design ideas and changes. After we left, Tim transferred this document to his desktop computer, cleaned it up and sent it to Steve and I. I don’t recall the date, however, I would say, this was the actual birth of the protocol that eventually became TNPP.

Meanwhile, as we knew, the smaller paging terminal manufactures were pushing to have a standard protocol developed that would allow them to connect to each others terminals and exchange paging data. This was mainly supported because the larger terminal manufactures had proprietary protocols that locked the smaller terminal manufacturer out. This presented a problem for the small paging carrier who didn’t need a larger terminal, but wanted to connect their systems to larger systems that had these larger paging terminals.

The larger terminal manufacturers, BBL and Glenayre, were pushing to have their existing protocols used as a standard. With all the buzz about a standard protocol, Telocator stepped up and formed a committee to look into creating/adopting a standard. The Telocator Protocol Committee was formed and a Chairman was appointed, I believe his name was Chris. Each manufacturer of paging equipment was given a committee seat with one vote. Over the next year or so we would have many meetings; we met at all of the Telocator shows, there were two per year at that time, and also scheduled a few in between. BBL of course was pushing their DLM and Glenayre had developed a binary protocol that followed the ISO standard, both went head to head in many of the meetings with no clear outcome or direction.

After Steve and I returned from our Unipage meeting, Steve had decided to move on and turned in his resignation, which left Tim and I to develop the new hardware and the protocol.

We immediately began our work. I put together the technical plan to meet the NSP requirements; we determined cost to develop the new hardware boards for the Omega DCU II. Then the development of this new protocol began. Since it was being used with the Omega Control system, we of course gave it a fitting name; we called it the “Omega II Protocol” (obviously we weren't real creative).

The Quintron engineering team had just bought an Apple Lisa computer with a 5MB hard drive and the fancy documentation tools (a word processor). I put those tools to work, by generating the beginnings of the protocol spec. The data structure and ladder diagrams that are in the TNPP specifications today were all originally done on that Apple Lisa computer. I recall struggling a bit with describing the details of the protocol. Then one day Tim and I were on the phone, which seemed to be an every day occurrence, and one of us came up with the idea that we should add a state table. Hence, the state table was generated and added to the document. This made the job of documenting the protocol design much easier as any time we would have debate about how something should work, we went back to the state table.

We had a number of significant NSP mile stones that we had to meet. We had also suggested and submitted an early version of our protocol to the Telocator Protocol Committee, hoping that it would be considered or possibly adopted for the standard. Initially it was rejected because it didn’t follow the ISO model and was missing other needed functionality. We were also open to using whatever standard that the Telocator Committee came up with. However, we had real product deliverables to provide, so we marched on with the “Omega II protocol”.

After many months of development and testing, I believe sometime in early 1985, we were finally ready to install the “beta” system. It was time to show NSP that our proposed system would work. We wrote a “Basic” program for an NEC 8201 computer that output the Omega II protocol” in what we called the one-way mode of operation. This would be used for testing. It sent a test message with an incrementing number in the message.

We packed up our gear and met in San Francisco where we had decided to test NSP’s first paging site. The next morning we showed up at the Equatorial uplink to install our computer. The guy that greeted us, told us that they had a dock area around back where we could unload our equipment, I smiled and said, “that won’t be necessary”, I pulled the little NEC computer out of my bag and explained that this was all that was required. In less than an hour we had the NEC installed and connected to the satellite uplink.

We then went to a building top with the NSP guys where we began installing the first nationwide paging transmitter. Obviously, it took much more time to install the transmitter, antenna etc. than the uplink equipment. By the end of the day we had a test pager in hand beeping with our test message. That day the first NSP nationwide pager went beep. This was a major mile stone for the NSP project and, unknown to all of us at that time; it would be the first commercial implementation of what would become TNPP.

By this time Quintron and Unipage had both sold and deployed several systems which used the Omega II Protocol. NSP also had the first phase of their nationwide system up and running. I recall that Tim developed a small PCB card that fit into a BBL terminal card slot that used the protocol to receive traffic and allowed the Unipage terminal to send paging traffic via the protocol to the BBL terminal. We were all pretty excited about the progress we had made. In fact, we had thought that the protocol might just become the de-facto standard as it was already installed and working in many systems.

During this time, the Telocator Protocol Committee was stalled on deciding upon a standard. I recall that in 1986, at the spring Teclocator Show, we had a Telocator Protocol Committee meeting. At this meeting we all agreed that we had to make progress. The committee decided that we needed a committee chair that would be impartial, someone who did not have any affiliation with any paging equipment manufacturer. We then appointed Arthur Peters, an independent consultant, who was a neutral person with no affiliation to any one paging equipment manufacturer, to the chair position. We agreed to meet in Seattle (which was close for Glenayre). We also agreed that we would not adjourn until some significant decisions or progress was made toward accepting a standard. Everyone was to bring in their best and be prepared to present their case for a standard. As I recall, the meeting took place about 60 days later.

We (Quintron & Unipage) polished up the Omega II Protocol specification document and headed to Seattle. I believe, BBL presented their DLM solution first, and then Glenayre presented their solution. We were up last; our presentation demonstrated that our protocol met many common needs of not only the small-terminal manufacturers, but also BBL and Glenayre. Our submission was version 2.5 of the “Omega II Protocol.” Over the next several hours there were several heated discussions about which protocol should be used. This was mostly driven by the marketing guys. Then an engineer—I believe from Glenayre—spoke up. He indicated that the Omega Protocol actually solved a couple of issues that they had within their protocol (which I’m sure that the Glenayre Marketing guy did not want to hear). This initiated a more technical discussion and others brought up a few of the Omega II protocols deficiencies. One being that it was very inefficient from a data use perspective as it was ASCII based. This was quickly put to rest as we discussed the advantage of being able to use inexpensive equipment to troubleshoot networks. Next, they discussed a couple of functions that were not supported in the Omega II Protocol, “Header Extensions” and “End-to-End Acknowledgements.” There were a few other small odds and ends that the committee members wanted as well. Toward the end of the day the meeting ended, and would resume the next morning. Tim and I headed back to the hotel room to work on solutions for the missing functionality.

The next morning we presented our solution. If I recall correctly, there were a few modifications made to our changes. The committee then choose the name ”TNPP” for the protocol. They asked if we could make all the changes, give it the new name, a new release number and have the document ready to turn over to a new Chairman. We agreed, and the committee took a vote on the adoption of the proposed Omega protocol, with the changes that had been discussed. We had a majority vote in favor of accepting the protocol as an industry standard.

The first official TNPP specification was accepted on April 25, 1986 as version 3.0. I produced several hard copies, and a softcopy, and then shipped them off to the new Telocator Committee Chairman, Jay Moskowitz. After this point, Jay and the Telocator Protocol Committee members all worked together and voted on any changes that were made to the protocol specifications.

One immediate change that I recall and I’m not sure if it was the first change in the new spec or not, but there were 2 ways listed in the spec to implement the CRC check bytes. The first way was a brute force calculation, which was a bit processor intensive for what hardware we had available in those days. The second way was to do what we called a table lookup. As the name implies, there is a table associated with this method and it was part of the specification. It is quite lengthy with lots of numbers and even though we checked it several times there was one number that was typed incorrectly. This typo caused an issue. If both implementations used the same table it would work, not correctly, but would not cause an error/failure. However, if one used the correct table and connected with an implementation that used the incorrect table, then it would cause an issue. Needless to say, when this bug was discovered there was a lot of finger pointing. I believe this issue was discovered between Glenayre and Unipage. Since Unipage had been one of the original developers and involved in the original table generation, they had it right. However, Glenayre had used the protocol specification document and copied the typo into their code. It took a little debugging and digging, but it was eventually figured out and the table was corrected. I was teased about this for quite some time and some said I did it on purpose because Glenayre, at that time, was our (Quintron’s) competition. However, this was one part of the spec that I didn’t type into the (Apple Lisa) document, since I wasn't that great of a typist, I had a secretary from the sales department assist with entering this table.

Below is a list, in alphabetical order by last name, of individuals that made significant contributions to the design, development and testing of version 2.5 of the “Omega II Protocol”, which, with a few changes from a single Telocator Protocol Committee meeting, became known as the Telocator Network Paging Protocol (TNPP) Version 3.0.

About the author: In 1980, after graduating from Bradley University with an engineering degree, John began his career at Quintron Corporation where he studied and researched simulcasting techniques for paging, designed and developed RF and paging control systems. In 1990, after leaving Quintron, he co-founded Complex Systems, Inc., where he was a key technical contributor and system architect for the C-NET paging control system. After Motorola acquired Complex Systems, he continued his career in paging at Motorola where he worked on the FLEX/ReFLEX protocol suite, supported the transition of the C-NET Control system to Motorola’s line of paging products, which included the development of a Nucleus transmitter version of the C-NET NIU and design work on the Core M (RFC). After leaving Motorola he co-founded Enhanced Messaging Systems, Inc., where he was a key system architect and hardware developer for a steerable satellite dish receiver system for paging. After Enhanced Messaging Systems he worked for a number of paging carriers and is now the Director of IT for American Messaging Services.