Inter-System and Intra-System Protocols

But with inter-city, inter-state and national travel commonplace, it is easy for a paging subscriber to move beyond the coverage area of a single paging terminal. Communication protocols specific to the paging industry have been developed that allow page requests originating in one paging terminal to be forwarded to one or more other paging terminals. Ultimately, these page requests are transmitted in remote areas not directly controlled by the paging terminal that received the original call.

With these communication protocols, paging terminals now can be connected to each other to form paging terminal networks. Each terminal controls its particular geographical coverage area but allows subscribers to be paged if they move into geographical areas that are not covered by their "home" system.

Over the years, several manufacturers developed their own proprietary protocols for communicating between their own paging terminals. Motorola employs a proprietary mechanism known as CP/IOP protocol, BBL Industries developed the Data Link Module (DLM) protocol and Spectrum Communications & Electronics developed the Data Link Handler (DLH) protocol. All of these protocols, although different in architecture and incompatible with each other, allowed each of the manufacturers to create cohesive networks of their own paging terminals. Each of these networks would allow pages to be forwarded to any subset of paging terminal nodes in a paging terminal network. Information in the customer database entry for each subscriber would indicate if page requests were to be transmitted to multiple nodes.

As the paging industry matured, company growth, mergers and acquisitions allowed paging companies to become multi-city operations. This expansion would allow multi-city, regional, statewide and nationwide paging services to be provided. But if the paging terminals were from different manufacturers, the incompatible protocols did not allow for the creation of these networks. Because of the capital investment in paging terminal equipment, it is not practical to replace existing equipment with a single manufacturer's terminal equipment to create these networks.

Two solutions exist to allow for the interconnection of different manufacturers equipment into paging networks. Several companies, among them Glenayre, Real Time Strategies, Ericsson Messaging and Unipage (a division of Motorola), developed "protocol conversion" equipment that create "gateways" between networks of different manufacturers' equipment. These gateways speak the protocol of one network and convert page requests to the protocol of the other network. Hundreds of different types of gateway devices are in use around the world, creating paths between sub-networks so as to create larger-scale paging terminal networks.

The second solution to the networking problem was to create an industry standard for communicating between equipment made by different companies. The Telocator Network Paging Protocol (TNPP) became the industry standard protocol. More recently, another protocol was adopted as a superset of TNPP. It is expected to be utilized in paging environments having requirements of throughput, message sizes, and features which are beyond that provided by TNPP.

The Data Link Module (DLM) Protocol
The Data Link Module (DLM) is a device that can be connected to various paging terminals manufactured by BBL Industries (now part of Glenayre Electronics). When these modules physically are connected to each other, a digital data communications protocol known as the DLM protocol operates to move page requests between each of the paging terminals. Pages may be sent from any terminal to any number of other terminals in the network. A value known as the Group ID (GID) is placed into the customer database entry of each subscriber's account that is to be paged at multiple locations and is used by the DLM to "drop off" pages at each paging terminal that should transmit pages for this GID.

The DLM protocol is known as a token passing protocol. Each DLM in the network is assigned a specific sequential number that represents its "node identification number". When the network is idle, one of the DLMs in the network sends a short sequence of bytes, known as the "token," to the next higher numbered DLM. Only the DLM that has just received the token is allowed to transfer its page requests to the network, if there are any network pages pending. If there are no pages to transmit, the token merely is passed on to the next-higher-numbered DLM. The highest-numbered DLM passes its token to the lowest-numbered DLM. In a completely idle system, one would observe the token passing from DLM to DLM. The token contains the address of the next DLM that is responsible for passing it further along the network.

The paging terminal that has pages to transmit hands these pages to the DLM. When the token "comes around," that DLM not only passes the token to the next DLM but also transmits some of its page request data. This paging data contains the GID information that is used to define that DLMs are supposed to process this request. Because of the architecture of the DLM, all of the DLMs may "listen" while any other one is transmitting. Therefore, all DLMs that must process this GID can immediately hand over the page request to its paging terminal for local transmission. Each page request that is passed over a DLM network, contains binary data that indicates all of the information that is required to alert a particular pager. Among all of the information forwarded is the cap code (address) of the individual pager, the type of service being provided (tone only, numeric or alphanumeric display), the protocol to be used to communicate with this particular pager, the beep pattern that should be heard by the subscriber and the message to be displayed.

The DLM is protected under a patent, and its protocol is more complex than the simplistic description that is stated. Thousands of nodes are operational around the world under this proprietary protocol.

DLH Protocol
The Data Link Handler (DLH) protocol is a communications protocol that operates over the data communication ports of the Spectrum Ericsson PX series paging terminals. The DLH protocol is known as a point to point protocol. This is a digital protocol that defines how to format data correctly so that it is received accurately by a remote paging terminal over a single communications link. Although the protocol strictly defines how to move data from one end of a "wire" (communications path) to the other, the protocol forwards information, known as the ZSID value, that is used by the remote paging terminal to determine how the received paging data is to be processed. On proper reception of paging information, the ZSID is converted into a "service area" that defines where the page is to be transmitted.

In some cases, the service area that is defined by the ZSID value forwarded may be interpreted to mean that this page request is to only be paged at the paging terminal that directly received the request. In other cases, the service area may be interpreted to indicate that the page is to be sent out of the receiving node over DLH links that connect it directly to one or more additional nodes. The DLH protocol, in association with the service area tables of the paging terminal, allows paging terminals to be connected into any topology (geographical configuration). In a DLH network, pages essentially are moved from paging terminal to paging terminal, with copies of the page requests dropped off at each of the intermediate nodes that are to transmit the pages.

The DLH protocol allows paging by access number as well as by cap code information. With paging by cap code, pager-specific information (as in DLM networks) is sent with the page requests. Paging by access number means that the telephone number of an account at a remote paging terminal is sent over the network. Network paging by access number allows the radio carrier to allow callers to dial into a paging terminal in order to page accounts whose subscriber database entries are located on a different terminal within the network. Access number paging avoids having to program all the pager-specific information at several different paging terminals. Attempting to maintain the same information at multiple terminals with in a network easily can become an administrative nightmare. The DLH protocol is similar in its general architecture to the TNPP protocol.

TNPP Protocol
The Telocator Network Paging Protocol (TNPP) was created by a committee of paging terminal manufacturers to become the accepted industry standard mechanism to move paging and other information between paging terminals regardless of manufacturer. Although it initially was conceived of as a standard means of moving information between dissimilar paging terminals, it is used widely to create networks of similar paging terminals. TNPP is a point-to-point digital communications protocol. It is used basically to ensure reliable delivery of information from one paging terminal to another directly connected paging terminal. The primary purpose of TNPP is to move radio page requests within networks and between different carriers networks, but the protocol also allows non-paging information to be transferred.

The TNPP specification only reviews the operation of the protocol in the point-to-point communications environment, but each "packet" of information that is transmitted under TNPP contains a destination address. This is an address value that represents which node or nodes are to process the page requests that are contained within this packet. If the paging terminal that receives a TNPP packet is not the destination address, this terminal may immediately send the packet over an outbound TNPP link over the "best" path to get closer to the destination. The specification does not define how TNPP can create networks or how network routing may be accomplished, but all the major TNPP implementations provide the ability to move packets between one or more nodes in a TNPP network.

TNPP can also be used in a satellite network environment. In this type of architecture, page requests can be broadcast over a satellite for receipt by a large number of paging terminals spread across a large terrain. Satellite-based TNPP networks operate in a one-way transmission mode; the remote paging terminals do not have the ability to acknowledge proper receipt of information. The protocol supports this type of network by allowing data to be transmitted multiple times from the source node without creating duplicate information at the destination node. In satellite-based networks, the source paging terminal broadcasts page requests several times within a small time window with the expectation that one of the multiple transmissions will be received without error.

TNPP supports paging by cap code as well as paging by access number as explained in the prior sections. Although it is not part of the standard features of TNPP, the protocol does allow manufacturer-specific packets to flow within a TNPP network in order to provide valued-added service offerings. TNPP is being used to provide such features as electronic mail (E-mail) communications, remote terminal control, shared database access and remote status monitoring.

The Operation of TNPP
TNPP is an ASCII-oriented protocol that operates normally over full duplex communications links. The control characters noted as <name> refer to ASCII control characters of the specified name. Full duplex communications support the simultaneous transmission of data and responses from each of the paging terminals connected together over a link. Any operational speed may be supported. Networks consisting of links that have different speeds specified according to the amount of traffic being handled can be implemented.

Link Test Phase
The TNPP protocol has two major operational phases: the link test phase and the data transfer phase. Link test ensures that the computers on each end of the link are capable of communicating with each other by having each machine send a request that solicits an immediate response from the remote device. The handshake proceeds as follows:

Data Transfer Phase
The data transfer phase of the protocol consists of the transmission of a data packet that may contain zero, one or more transactions within the packet. Each data packet contains a set of data that is meant for a common destination. If the packet is received properly, the receiving paging terminal acknowledges the proper receipt. Other responses solicit specific error actions to be taken.

TNPP data transfers take the following form:

Data Format
A TNPP packet consists of a packet header and transactions. The packet header contains:

• TNPP Source Address: A number between 1 and 65,535 that indicates that node originated this packet.
  
• TNPP Destination Address: A number between 1 and 65,535 that indicates that node is to process the transactions within this packet.
  
• Message Sequence Number: A number between 1 and 255 used to distinguish new packets from retransmitted packets.
  
• Inertia: This is a value that represents the maximum number of nodes a packet is allowed to traverse before it must reach its destination. This value is decremented on each forwarding of a packet to the next node along the path to a destination and causes the packet to be discarded if the value of zero is reached. The inertia value ensures that packets do not hop forever within a network if the destination node is disconnected from the rest of the network.

Transaction Types
The transaction types that are supported under TNPP are as follows:

Figure 2

Telocator Interswitch Paging Protocol (TIPP)
The TIPP protocol was developed in response to the anticipation of paging network requirements which could exceed the existing capabilities of TNPP. Rather than undergoing a significant modification to TNPP to adapt it for higher throughput and the support of longer messages, the paging committees of the PCIA decided to adopt a protocol which, like TDP, follows an ISO layered protocol design philosophy. In this way, the protocol designers could concentrate on the application layer of the protocol which is specific to the requirements of the paging industry and adopt a well proven, computer industry standard lower layer protocols to perform data transport, networking, and link layer requirements of any networking protocol. TIPP was developed to utilize the Internet TCP/IP protocol for the movement of paging data through networks. The paging data being moved through the network, using the capabilities of the TCP/IP protocol, is defined by the Telocator Inter-Switch (TIS) applications protocol.

TIS, as described in the TIPP specifications, defines the structure of various types of control blocks which send paging messages and control information to remote paging terminals. Each of these control blocks follow a standardized form for representing data. This form, known as ASN.1, is also utilized to build the control blocks which are specific to the TDP protocol. The data defined by TIS provides for all of the paging capabilities originally available within TNPP. TIS is expandable to provide for the movement of additional types of information which is required in support of data paging and two-way paging networks, as well as the addition of new features and services in traditional paging networks. Through the utilization of TCP/IP, the designers of TIS do not need to be concerned with network routing, increased throughput, message transport reliability, the movement of large messages and many other networking issues which are already addressed through the use of these Internet protocols.

Unlike TNPP, in which the paging terminals also provide the message routing functions which move paging information between cities, many TIPP based networks may be utilizing external network routing equipment. Although this equipment adds cost to the paging network, some service providers are expected to overlay administrative data on top of the same circuits, further amortizing the cost of the inter city data circuits. In addition, by eliminating some of the message passing requirements from the paging terminal, the processing time related to these functions can be made available to other paging terminal features and functions.