Partnerships:

Developer Resources Center - TAP

Introduction

In order to decrease holding times on input lines to alphanumeric systems, it is desirable to promote input devices which will allow off-line entry of paging information and dump this data quickly after connection to the central paging terminal. A recommended protocol is contained in this specification. This was know as the Motorola/IXO alphanumeric protocol until it was adopted by Telocator in September 1988, as an industry standard protocol for the input of paging requests. It is now referred to as the Telocator Alphanumeric Protocol (TAP).

This protocol is compatible with special versions of small input devices available from numerous sources. It is also suitable for automatic input from a remote computer and has been distributed to numerous manufacturers of paperless TAS systems. Note that there are several options within the protocol:

  1. It may be used for paging with 2 fields per transaction or other services with a different number of fields per transaction.
  2. The use of manual input devices is provided in the logon procedure. Such provision is optional with the system operator. (Note that SkyTel does NOT support manual TAP operations.)
  3. Optional messages to the remote entry device may be added to control responses from the central terminal. For paging, these will probably be used for a message acceptance or rejection summary at the end of a message.

For initial implementation of the protocol, it is recommended that Bell 103 compatible modems be used to receive at 300 baud. Additional speeds or modem types may be used if desired.


Dial-Up Access Numbers

  • 1-way TAP: 800.759.6366
  • 2-way TAP: 800.679.2778

Note: If you're sending messages to 1-way pagers only, use the 1-way dial-up number. If you're sending to a mixture of 1-way and 2-way pagers, or to only 2-way pagers, use the 2-way dial-up number.


Protocol

Recommended Sequence of Call Delivery From a Small Entry Device
(all quotation marks or the symbols < > shown in this document are used for notation purposes only and are not transmitted)

Remote Entry Device Does Paging Terminal Does Comments
  1. Off Hook-Access DDD Line. Await dial tone. Dial stored Access number.

Ring Answer

 
  1. Carrier up

Carrier up

 
  1. "<CR>"

 

<CR> is repeated at intervals of t1 seconds until paging terminal responds with "ID=" at the correct baud rate or until n1 transmissions have been completed. (This step exists to allow for possible baud rate recognition.)

  1.  

"ID="

Request for ID returned within t2 seconds of receipt of <CR>. NOTE: Paging terminal may send either <CR> or <CR><LF> after "ID=". Paging Terminal shall wait up to t5 seconds for a response to "ID=" up to n3 times, if a proper response is not received.

  1. A. (For automatic remote entry devices only)
    "<ESC>SST"

 

"<ESC>" signifies entry device intends to talk in automatic mode. "SS" is a set of two alphanumeric characters signifying a type of service to be accessed.

(For a paging service where: Field 1 = "Pager ID" and Field 2 = "Message", if any, SS will be sent as "PG").

"T" is a single alphanumeric character relating to the type of terminal or device attempting to send the message.

T = 1 is a category of entry devices using the same protocol. At the present time, all entry devices and computer programs utilize T = 1. The values T + 7, 8, 9 are reserved for devices which may releate to a specific user's system.

PPPPPP"<CR>"

 

6 alphanumeric character password (PPPPPP). Password is optional and is, in general, reserved for future services. Password may be interpreted as either a caller ID or a system entry key. Length of password, when used, may be different in some systems.

When an incorrect logon sequence beginning with <ESC> is received, the paging terminal may respond with an "ID=" if it requires a retransmission.

  1.  
 "<Message Sequence>
<CR><ACK><CR>"
or
"<Message Sequence>
<CR><NAK><CR>"
or
"<Message Sequence>
<CR><ESC><EOT><CR>" 		Logon Accepted
or
Requested Again
or
Forced disconnect

This response shall arrive within t3 seconds of step 5.

A message sequence is defined as a series of short messages separated by <CR>'s. A <CR> always follows a message sequence. Message sequences are optional.
  1. A.

"Optional Message Sequence <CR>"

Paging Terminal may insert a message sequence between steps 6 & 7.
  1.  

"<ESC>[p<CR>"

Message go ahead is sent when Paging Terminal is prepared to receive the first transaction. NOTE: p is lower case.
  1. Transaction #1
    Block #1

    "<STX>
    Field #1<CR>
    Field #2<CR>...
    Field #N<CR>
    <ETX><CHKSUM><CR>"
    A transaction should be sent within 14 seconds of a response from the paging terminal.

A "block" is up to 256 characters in length, with up to 250 characters of info, plus 3 control characters and a 3 character checksum. The block carries one transaction (one set of all fields 1 through N) or a portion of one transaction. A block may be less than 256 characters to accommodate short transactions.

A field may be any length and where necessary may be continued in succeeding blocks. A field always ends with a <CR>. The <CR> field delimeter suggests <CR> may not be used within a field.

A block always begins with an <STX> and ends with a checksum followed by a <CR>. The characters preceding the checksum depend on what if anything, is continued beyond the block boundary.

The <ETX> is used as a block termination indicator if a given transaction (Fields 1 through N) ends within the block currently being transmitted.
  1. continued...

    Transaction #2
    Block #2

    "<STX>
    Field #1<CR>
    Field #2<CR>...
    Field #J<CR>
    <ETB><CHKSUM><CR>"

    Block #3

    "<STX>
    Field #J + 1<CR>
    Field #L<CR>
    <US><CHKSUM><CR>"

    Block #4

    "<STX>
    Field #L<CR>
    <ETX><CHKSUM><CR>"
  The <ETB> is used as a block terminator if the transaction is continued into the next block, but the last field in the current block is complete.

If the last field within the current block is to be continued in the next block, no <CR> is inserted at the end of the first portion of the field and the <US> character is used as a block termination character. The <CR> terminating the broken field is sent at the end of the field in whatever block the field actually terminates.

No limit is established within the protocol itself regarding the number of transactions, the number of fields, or the number of blocks per field; however, a particular user system may have limits on any of these items.

Some systems may be limited to one block per transaction and one transaction per phone connection.

Each checksum is computed by perfoming the simple arithmetic sum of the 7-bit values of all characters preceding it in the block. (This means that STX and ETB/ETX are included in the sum).

The checksum is transmitted as 3 printable ASCII characters having values from Hex 30 to Hex3F (the characters 0123456789:;<=>?). The most significant 4 bits of the sum are encoded in the 4 LSB of the first character and the least significant 4 bits of the sum are encoded as the 4 LSB of the third character.
  1. continued...

    Last Transaction
    Last Block

    "<STX>
    Field <CR>
    Field #N <CR>
    <ETX><CHKSUM><CR>"
   Typically, a paging system transaction will have 2 fields only:

Field 1 = Pager ID (normally up to 8 digits. May include function and check digit).
Field 2 = Message.

Field 1 or Field 2 may be empty. For example, when a page is Tone Only, Field 2 will be empty. Even when empty, a field is followed by a <CR< Note that some systems will reject transactions which have an empty Field 2 for a display page or transactions which have an empty Field 1. Other systems are less restrictive.

The response to each block, to be sent within t3 seconds, is one of four:
  1. continued...
1) "<Message sequence>
<CR><ACK><CR>"

or

2) "<Message sequence>
<CR><NAK><CR>"

or

3) "<Message sequence>
<CR><RS><CR>"

or

4) "<Message sequence>
<CR><ESC><EOT><CR>" 		1) OK, Send next block

2) Checksum or transmission error, send last block again.

3) Abandon current transaction and go to next. RS may occur when the checksum is OK, but the current transaction violates a system rule. At the option of the system, it may occur in other cases.

4) Begin disconnect. Any response may be preceded by an optional message sequence.

The next transaction must be initiated by the remote entry device within t4 seconds of the paging terminal's last response. If no repsonse is received from the paging terminal within t3 seconds, the transaction may be resent. The remote entry device may resend up to n2 times before considering the connection as failed. The disconnect sequence may then be executed.
  1. "<EOT><CR>"

 

After reception of an <ACK> or <RS> for the last transaction in a given service, the entry device sends the protocol disconnect sequence, <EOT><CR>, meaning there are no more transactions remaining in this service.

  1. A.

"<Message sequence><CR>"

An optional message sequence may be sent at this point to indicate degree of acceptability of information in all transactions received during the current interchange. Although optional, this message is highly desirable.

  1. B.

"<RS><CR>"

An <RS><CR> should be sent at this point if the paging terminal finds any data <ACK>'d in step 8 by the system to be unacceptable because of content (e.g. an invalid pager number or a message field inappropriate for the type of page, etc.). NOTE: It is most desirable to catch all types of errors in step 8, but practically, some systems will be too slow to catch content errors as they happen.

  1. C.

"<ESC><EOT><CR>" followed by dropping of carrier and hanging up.

Paging terminal disconnect sequence.

  1. Drops carrier and hangs up.

 

 

The standard protocol will be ASCII, with X ON, X OFF either direction, using a 10 bit code (1 start, 7 data, even parity, 1 stop).

The paging terminal may, at its option, send <CR><LF> in place of <CR> at the end of any sequence.

The paging terminal shall be equipped to receive full duplex using a Bell 103 compatible modem at 300 baud. Optionally, certain inputs may be capable of receiving 110 baud Bell 103 full duplex, or 300/1200 baud Bell 212 full duplex or higher speeds. No echo shall be employed in full duplex mode. Any attempts at automatic baud rate determination shall be within the restraints of the specified protocol.

Checksum Example

STX

 

000

0010

1

 

011

0001

2

 

011

0010

3

 

011

0011

CR

 

000

1101

A

 

100

0001

B

 

100

0010

C

 

100

0011

CR

+

000

1101

 

=

10111

1011

 

1

0111

1011

 

3

3

3

 

1

7

;

Checksum = 17;


Therefore, an example of a complete block containing a correct checksum is:

"<STX>123<CR>ABC<CR><ETX>17;<CR>"


Character Sets
Alphanumeric Paging - The message field of a page request to an alphanumeric pager may contain any printable ASCII character. Printable ASCII characters range from Hex 20 to Hex 7E.

Numeric Paging - in addition to the digits 0-9, the characters "E", "U", " "(space), "-"(hyphen), "]", and "[" may be specified in the message field. The POCSAG translation of these values is as follows:

Character

POCSAG Bit Pattern

E

1010

U

1011

(Space)

1100

-

1101

]

1110

[

1111


Some paging terminals optionally allow the special characters ":", ";", "<", "=", ">", and "?" to be used in lieu of "E", "U", " ", "-", "]", and "[" respectively.


Timing and Retry Parameters
The initial release of the TAP specification defined fixed values for various time-outs and retry parameters. These values have been designated as parameters as of revision 1.1 of the specification. The default values of these parameters are those designated in revision 1.0 of the specification. It is recommended that implementations of TAP allow for the on-line modification of the various parameters to adjust the operation of the protocol for systems which have not strictly adhered to the specification.

Timing Parameters

Retry Parameters

t1 - 2 seconds
t2 - 1 second
t3 - 10 seconds
t4 - 4 seconds
t5 - 8 seconds

n1 -3
n2 -3 (unrefined in rev. 1.0)
n3 -3 (unrefined in rev. 1.0)



ASCII Table

MS
BITS
LS

0

000

1

001

2

010

3

011

4

100

5

101

6

110

7

111

0 - 0000

NUL

DLE

SP

0

@

P

`

p

1 - 0001

SOH

DC1

!

1

A

Q

a

q

2 - 0010

STX

DC2

"

2

B

R

b

r

3 - 0011

ETX

DC3

#

3

C

S

c

s

4 - 0100

EOT

DC4

$

4

D

T

d

t

5 - 0101

ENQ

NAK

%

5

E

U

e

u

6 - 0110

ACK

SYN

&

6

F

V

f

v

7 - 0111

BEL

ETB

'

7

G

W

g

w

8 - 1000

BS

CAN

(

8

H

X

h

x

9 - 1001

HT

EM

)

9

I

Y

i

y

A - 1010

LF

SUB

*

:

J

Z

j

z

B - 1011

VT

ESC

+

;

K

[

k

{

C - 1100

FF

FS

,

<

L

\

l

|

D - 1101

CR

GS

-

=

M

]

m

}

E - 1110

SO

RS

.

>

N

^

n

~

F - 1111

SI

US

/

?

O

_

o

DEL

Sample Trace

The following is a trace of a TAP conversation sending the message "TAP Message" to PIN 1272975. This data was captured by a protocol analyzer connected between the modem and the host computer on the remote (sender) side. The DCE trace line is data sent from the modem to the host. The DTE trace is data sent from the host to the modem.

DCE=   
DTE=   A   T   D   T   9   ,   1   8   0   0   6   7   9   2   7   7   8  CR 

DCE=  CR  LF   C   O   N   N   E   C   T  SP   9   6   0   0   /   A   R   Q 
DTE=                                                                         

DCE=   /   V   3   4   /   L   A   P   M  CR  LF       I   D   =  CR  LF     
DTE=                                              CR                      EC 

DCE=                  CR  AK  CR  EC   [   p  CR  
DTE=   P   G   1  CR                              SX   1   2   7   2   9   7 

DCE=      
DTE=   5  CR   T   A   P  SP   m   e   s   s   a   g   e  CR  EX   5   7   : 

DCE=      CR  AK  CR          EC  ET  CR   +   +   +                
DTE=  CR              ET  CR                                                  

Control character abbreviations:

CR - Carriage-return (0x0d)
LF - Line-feed (0x0a)
SP - space (0x20)
EC - escape (0x1b)
AK - ACK (0x06)
SX - STX (0x02)
EX - ETX (0x03)
ET - EOT (0x04)


TAP Links

The Personal Communications Industry Association's web site. Check PCIA's Resource Center first for the latest TAP protocol specifications. Currently version 1.8.