A Signalling Standard: For Trunked Private Land Mobile Radio Systems

MPT 1327
A Signalling Standard
for Trunked Private Land Mobile Radio
Systems
January 1988
Revised and reprinted October 1991
Revised and reprinted June1997
A SIGNALLING STANDARD FOR
TRUNKED PRIVATE LAND MOBILE

RADIO SYSTEMS
(C) Crown Copyright 1988
First published January 1988
Reprinted and revised October 1990
Reprinted and revised October 1991
Reprinted and revised June 1997
Amendments issued since publication 1988 edition
Amendment
Number Date of issue Text affected
1 October 1990 Incorporated in the

version of October
1990
Amendment
Amendment
FOREWORD
This standard defines the rules for communication between radio units and trunking
system controllers operating in trunked private land mobile radio systems.
Applications and test conditions for this standard, applicable to Band III, are
contained in the following specifications prepared by the Department of Trade and
Industry, Radiocommunications Agency.
MPT 1343 System interface specification for radio equipment to be used

with commercial trunked networks operating in Band III, sub-
bands 1 and 2.
MPT 1347 Radio interface specification for commercial trunked networks

operating in Bank III, sub-bands 1 and 2.
MPT 1352 Test schedule for the approval of radio units to be used with
commercial trunked networks operating in Band III, sub-bands 1
and 2.
Intellectual Property Rights
Firms intending to manufacture equipment which complies with the standard should
be aware that certain features of the standard are subject to IPR claims.
All firms are therefore advised that they should make appropriate enquiries
through their Patent Agents before proceeding.
CONTENTS
1. INTRODUCTION
2. DEFINITIONS
3. SIGNALLING FORMATS
4. ADDRESSING
5. CODEWORD STRUCTURES
6. CHANNEL DISCIPLINE
7. RANDOM ACCESS PROTOCOL
8. REGISTRATION PROCEDURES
9. BASIC CALL PROCEDURES
10. EMERGENCY CALL PROCEDURES
11. INCLUDE CALL PROCEDURES
12. CALL DIVERSION PROCEDURES
13. STATUS MESSAGE PROCEDURES
14. SHORT DATA MESSAGE PROCEDURES
15. DATA INTERROGATION PROCEDURES
16. Section reserved for additional short data procedures e.g. SAMs.
17. STANDARD DATA PROCEDURES
APPENDIX 1 Suggested values for parameters.
APPENDIX 2 The error control properties of the codewords.
APPENDIX 3. An algorithm for determining the codeword completion

sequence of a control channel system codeword.
APPENDIX 4. An algorithm for generating fields A and B of the MARK

codeword.
APPENDIX 5. BCD coding.
APPENDIX 6. Reserved for Timing of responses for standard data at a

customised rate.
APPENDIX 7. Other ideas considered during the drafting of section 17

(standard data).
1. INTRODUCTION
MPT1327 is a signalling standard for trunked private land mobile radio systems. It
defines the protocol rules for communication between a trunking system controller (TSC)
and users' radio units.
The standard can be used to implement a wide variety of systems, from small
systems with only a few radio channels (even single-channel systems), through to large
networks which may be formed by the interconnection of TSCs.
The protocol offers a broad range of user facilities and system options. However,
it is not necessary to implement all of the facilities available; an appropriate subset of the
protocol could be implemented, according to the user requirements. Also, there is scope
for customisation for special requirements, and provision has been made for further
standardised facilities to be added to the protocol in the future.
The standard defines only the over-air signalling and imposes only minimum
constraints on system design. Additional specifications will be required for specific
implementations, for example, to define:
- the facilities that must be implemented

- parameter values
- a channel plan
- for a network, criteria for when a radio unit should register.
Section 1.1 of this introduction describes the user facilities which are explicitly
provided by the protocol. (It does not describe additional facilities which may be offered
in a radio unit but which do not require any specific protocol.)
Section 1.2 describes some protocol features, indicating the options available to
system designers.
Section 1.3 provides an introduction to the operation of the protocol.
Subsequent sections of this document contain the protocol definition. In most of

these sections, the protocol rules for the TSC and for radio units are specified
separately, but with cross-referencing where convenient.
MPT1327 1997 Issue Page 1-1

1.1 User Facilities
The facilities available to users are outlined below. For a full definition of the
facilities, see the sections indicated.
1.1.1 Types of call
The standard protocol enables radio units to make the following types of call.
a. Speech call. (See section 9.)
Speech calls may be requested with normal or high priority. For group calls, the
calling party may opt for a conversational mode, where all parties are able to speak,
or for an announcement mode where only the caller may speak.
b. Data call, for the transmission of non-prescribed signalling. (See section 9.)
Parameters are available to specify either normal or high priority and, for a group call,
whether the called group members can reply.
c. Emergency call. (See section 10.)
Parameters are available to specify either a speech or a data call and, for a group
call, whether the called group members can reply. Also, a radio unit may request a
special mode of emergency service previously arranged with the system; the TSC
determines the required action by reference to the calling unit's address.
d. Include call. (See section 11.)
During a call, a unit may request that another party joins the call. This facility may be
used to implement a Conference Call or Call Transfer.
e. Status message. (See section 13.)
Thirty-two different status messages may be conveyed between units. The

meanings of two of these messages are prescribed as a "call-me-back request" and
"cancel previous call-me-back request". The remaining thirty messages have user-
defined meanings. (Status messages can also be sent between radio units and the
TSC.)
f. Short Data Message. (See section 14.)
Messages of up to 184 bits of free format data can be sent between units, or
between units and the TSC.
Page 1-2 MPT1327 1997 Issue

g) Standard Data Call (See section 17)
A standard data channel is defined which has the capacity to sustain 1023 links,
though not all need be active simultaneously. The section defines procedures for
setting up data calls and then transmitting messages in a standard manner on one or
more standard data traffic channels on a base station. Data may be transferred
between radio units, or between radio units and other data devices connected to the
base station infrastructure and other networks. Errors on the data channel are
corrected as necessary by automatic request for repitition (ARQ) before the data is
passed on to any other data link or equipment, i.e operation is "store and forward"
1.1.2 Making calls
A radio unit may request a call to any of the following called parties (except for status
messages, which cannot be addressed to PABX or PSTN destinations or to groups):
- an individual radio unit or line-connected unit

- a group, or all units in the system
- a PABX number, up to nine digits
- a PSTN number, up to 31 digits.
In addition, status messages and short data messages may be sent to the TSC.
During call set-up, the TSC may pass a wide variety of information to the caller, to
indicate the progress of the call. For example, it may indicate the reason for any delays in
call set-up or the reason for a call failure.
A call request may be cancelled at any time.
1.1.3 Receiving calls
A radio unit may receive calls from a radio unit or line unit, or (except for status
messages) from a PABX extension or the PSTN. In addition, status messages and short
data messages may be received from the TSC. For a call from a radio unit, a line unit or
the TSC, the calling address may be supplied to the called unit. For a call from a PABX
extension or from the PSTN, the calling gateway is indicated as the source of the call but
the caller's number is not conveyed to the called unit.
Incoming calls may be addressed to the unit individually or to a group to which it

belongs. A radio unit may be a member of an arbitrary number of groups; its group
addresses can be chosen independently of its individual address.
A radio unit may refuse to accept all incoming calls, for example by means of a
"busy" or "out-of-vehicle" control, or incoming calls could be refused selectively, depending
on the source of the call. If a user does not wish to proceed with an incoming call
immediately, he can indicate that he will call back later.
Systems may be configured to alert a called individual and require him to indicate
that he is ready, before a traffic channel is allocated for a call.

1.1.4 Diverting Calls
If a radio unit does not wish to receive calls, it may request that future calls
addressed to it be redirected to a specified alternative destination. A radio unit may also
request redirection on behalf of a third party, for example, for a unit which is not equipped
for call diversion. A radio unit calling a diverted party will be informed of the alternative
destination to try; it may then re-make the call automatically, or it may give the user the
option of deciding whether to call the alternative destination. See section 12 for the full
diversion facilities.

1.2 System Features and Facilities
1.2.1 System dimensions
The numbering range of the protocol accommodates:
- 1,036,800 addresses per system

- 1024 channel numbers
- 32768 system identity codes.
1.2.2 System control
The protocol uses signalling at 1200 bit/s with Fast Frequency Shift Keying (FFSK)
subcarrier modulation. It is designed for use by two-frequency half-duplex radio units and a
duplex TSC.
The signalling for setting up calls is transmitted on a "control" channel. A TSC can be
operated using either of two control channel strategies: dedicated or non-dedicated. A
dedicated system has a control channel permanently available for signalling, whereas a
non-dedicated system may assign the control channel for traffic (speech or data
communication) if all the other channels are in use. The use of a dedicated control channel
is appropriate for a TSC with many channels, whereas a non-dedicated control channel
may be more appropriate for a TSC with only a few channels. The protocol allows the use
of either strategy.
Broadcast messages are available to inform radio units of system information, such
as the channels which the system may use for control signalling.
One of the problems of mobile radio signalling systems is the clashing of messages
from different radio units transmitting at the same time. The problems of clashing are
controlled by an access protocol which offers high efficiency, stability and flexibility. (See
section 1.3.3 and section 7.)
Protection against interference is provided by labelling the signalling with a system

identity code and, in some messages, the channel number. If heavy interference is
encountered, control can be changed to a different channel.
To cope with system malfunction, a customised fall-back mode of operation may be

defined by the system designer.
1.2.3 Call handling
The protocol is designed for use by systems which queue calls that cannot be set up
immediately, for example, if no channel is currently available for traffic.
Before a traffic channel is assigned for a call to an individual radio unit, the TSC
checks that the called unit is in radio contact, in order to avoid wasted channel
assignments. It may also check that the radio unit's operator is ready for the call, to avoid a
traffic channel being assigned to an unmanned unit.

Call maintenance signalling is defined for prompt release of traffic channels at the
end of a conversation, or in case communication is lost during a call. (See section 1.3.5
and section 9.)
As a precaution against fraudulent use of a system by an unauthorised radio unit, the

TSC may at any time instruct a radio unit to transmit its unique serial number; comparison
of the received serial number with the expected value will assist in the detection of
fraudulent users. (See section 15.)
1.2.4 Multi-site systems
The standard leaves scope for various multi-site wide-area coverage techniques to
be used, for example:
- synchronous/quasi-synchronous operation
- a separate control channel at each site
- a single control channel shared by time division.
The protocol includes a registration facility to assist the implementation of multi-site

systems and networks of TSCs: a radio unit can inform the TSC of its location as it roams
between sites or systems. (The system identity code distinguishes the signalling from
different sites and systems). The standard defines signalling procedures for registration
(section 8), but the criteria for registration will be system-dependent.
A TSC can broadcast information to assist radio units hunting for a control channel
when they roam; for example, it can announce the channels which may be used for control
by itself or by TSCs on adjacent sites.

1.3 Guide to Some Key Protocol Aspects
This section provides an introduction to the operation of the protocol which, because
of its scope and flexibility, is necessarily complex. The section outlines the control channel
structure, the random access protocol and some message exchange procedures for call
set-up.
This section is intended only as a guide: it should not be regarded as a protocol

specification. Readers should refer to the main body of the standard for the complete and
precise definition.
1.3.1 Control channel signalling structure
The signalling for setting up calls is transmitted on a "control" channel. Time on the
control channel is divided into slots of duration 106.7 ms (128 bits), and one signalling
message can be sent in each slot. The basic control channel signalling structure is
illustrated in Figure 1-1.
Signalling on the forward channel (base station transmit frequency) is nominally

continuous, with each slot comprising two 64-bit codewords, usually:
i) A Control Channel System Codeword (CCSC).

The CCSC identifies the system to radio units and provides synchronisation for
the following "address" codeword.
ii) An "address" codeword.

An address codeword is the first codeword of any message, and defines the
nature of the message.
Both the CCSC and address codewords are displaced when the Trunking System
Controller (TSC) transmits longer messages, with "data" codewords appended to an
address codeword.

A radio unit can receive a message from the TSC in one slot, transmit a response in
the next slot and then retune to the forward channel in time to decode the following
message from the TSC. (In Figure 1-1, the response is shown aligned with the outbound
message; however, there are tolerances on the timing.)
1 slot
TSC to radio units ←→
CCSC address CCSC address CCSC address

codeword codeword codeword
radio unit synch address

response bits codeword
Fig. 1-1 Control channel signalling structure
1.3.2 Control channel signalling messages
The messages sent on a control channel may be classified as follows:
Aloha messages - Sent by the TSC to invite and control random

access.
Requests - Sent by radio units to request calls/transactions.
"Ahoy" messages - Sent by the TSC to demand a response from an addressed
radio unit.
Acknowledgements - Sent by the TSC and by radio units.
Go To Channel messages - Sent by the TSC to allocate traffic channels.
Single address messages - Currently sent only by radio units.
Short data messages - Sent by the TSC and by radio units.
Miscellaneous messages - Sent by the TSC for system control.
Some uses of these messages are illustrated in the following sections.
1.3.3 Random access protocol
1.3.3.1 Principle of operation
One of the problems of mobile radio signalling schemes is the clash of messages
from different radio units transmitting at the same time. In this standard, the problems of
clashing are controlled by a random access protocol which is based on slotted Aloha, with a
superimposed framing structure. The access protocol can be used to minimise access
delays, ensure stability and maintain peak throughput under heavy traffic loads.
The basic principle of the access protocol is described with reference to Figure 1-2,
which illustrates signalling on a control channel. The TSC transmits a synchronisation
message (indicated by ALH in Figure 1-2) to invite radio units to send random access
messages. The ALH message contains a parameter (N) which indicates the number of

following timeslots, constituting a frame, that are available for access. If a frame is already
in progress when a user initiates a call, the radio unit may send its random access
message in the next slot. Otherwise the unit waits for a frame to be started and then
chooses a random slot from the frame for its message. A unit wishing to send a repeat
transmission after an unsuccessful message (corrupted by fading or clashing) chooses
again from a new frame.
1 slot
←→
TSC to ALH ALH
Radio Units (4) (3)
Radio Units
to TSC
\______________________/ \________________/
frame frame
Fig. 1-2 Two random access frames, each marked by an ALH message
1.3.3.2 Features of the random access protocol
The main features of the access protocol are as follows:
a) The TSC can monitor activity on the control channel and can optimise the system
performance by varying the framelength to prevent excessive clashing and to
minimise access delays. Figure 1-3 illustrates an example of random access control.
b) The signalling overhead for random access control is kept small by allowing
Acknowledgements and Go To Channel messages to contain the framelength
parameter (N), so that frames can be marked without requiring an explicit Aloha
message. For example, see Figure 1-3.
c) During a frame, the TSC may transmit messages that demand a response from a
specified radio unit. These outbound messages inhibit random access in the
following slot, and so reserve the slot for the unit's reply.
d) The TSC may reserve frames for:
- specific types of call request, by means of specific Aloha messages (for instance,
the Aloha message ALHE invites emergency calls only);
- subsets of the radio unit population (subdivision by address).

TSC to ALH ALH ALH ALH ACKQ ACKQ
Radio Units (1) (1) (2) (0) (1) (1)
Radio Units to RQS1 RQS1 RQS2

TSC RQS2
\____/ \____/ \__________/ \____/ \____/

frame frame frame frame frame
The TSC detects the clashing of requests RQS1 and RQS2, and marks a
longer frame (with message ALH(2)). The radio units repeat their requests
and, in this example, choose different slots. Each request is acknowledged
in the following slot.
ALH(0) does not mark a frame.
ACKQ(1) acknowledges a request and also marks a new frame.
In the absence of clashing, the framelength may be reduced.
Fig. 1-3 Example of random access control
1.3.4 Addressing
A unit address is a 20-bit number comprising two fields: a 7-bit prefix and a 13-bit
ident. (Normally, all members of a fleet will be allocated the same prefix.) The division into
prefix and ident allows most messages to accommodate two addresses, the calling and
called party, by including the prefix only once. For instance, call requests and Go To
Channel messages contain two idents and only one prefix.
For a call to a unit with the same prefix, a request message contains all the
information necessary to make the call. However, for a call to a unit with a different prefix,
the call details cannot be accommodated in a single address codeword; this type of call
requires the use of "extended addressing" procedures (as do some PABX and most PSTN
calls).
1.3.5 Examples of signalling sequences
The precise signalling required for a call depends on the type of call and on the
design of the TSC; (the standard does not prescribe the TSC algorithms). This section
contains some examples of message exchange sequences. Note that, although not shown
in the examples, messages will be retransmitted in the case of corruption by propagation
errors or collision.

Examples of message exchange sequences for call set-up are presented in sections
1.3.5.1 to 1.3.5.3. These examples show control channel signalling, for:
- call requests
- instruction to send extended address information
- checking availability of radio units
- traffic channel allocation.
Signalling is also sent on an allocated traffic channel, for call maintenance and call clear-
down. For instance:
a) To assist call maintenance, a radio unit sends a "Pressel Off" message at the
end of each speech transmission. The system may also require the unit to start
each speech transmission with a "Pressel On" message and to send call
maintenance messages periodically within the transmission.
b) The calling unit in a group call, or both units in an individual call, send
"Disconnect" messages to indicate end-of-channel-use when the user goes on-
hook or equivalent.
c) The TSC sends CLEAR messages to clear down a call (after receiving a valid
Disconnect message or if a time-out has expired).
However, the examples do not cover traffic channel signalling.
The final example (section 1.3.5.4) illustrates the transmission of a short data
message. This type of transaction does not use a traffic channel: it requires control
channel signalling only.
1.3.5.1 Example: radio unit calls a group
Figure 1-4 illustrates a message sequence on a control channel to set up a group call
between radio units with the same prefix.
The sequence includes call request and channel allocation signalling. (For group
calls, an availability check on the called units is not performed.) In this example, all traffic
channels are in use when the call is requested and so the call is queued.

slot
←--→
1 3 4
TSC to RUs ALH ALH ACK GTC GTC
(1) (1) (1) (1) (1)
2
RUs to TSC RQS
\____/ \____/ \____/ \____/

frame frame frame frame
1. ALH : General Aloha invitation (one-slot frame).
2. RQS : The calling radio unit transmits its request, complying with the
random access protocol.
3. ACKQ : The TSC acknowledges the RQS message, informing the calling unit
that the call has been queued.
4. GTC : When a traffic channel is available, the TSC sends the Go To

Channel command, addressed to the calling unit and called group;
this message instructs the units to switch to the traffic channel for
their conversation. In this example the GTC is repeated, for added
reliability.
Fig. 1-4 Common-prefix group call
Alternative acknowledgements from the TSC are available if, for instance, the call
request is invalid or the system is overloaded.
If a traffic channel is available when a group call is requested then the TSC may omit
the ACKQ and send the GTC command immediately.
In this example the GTC message is repeated immediately. However, repeat

messages may be delayed for other signalling.

1.3.5.2 Example: radio unit calls a unit with the same prefix
Figure 1-5 illustrates a message sequence on a control channel to set up a call

between two radio units with the same prefix. The sequence includes call request,
availability check and channel allocation signalling.
1 3 5
TSC to RUs ALH ALH AHY ALH GTC GTC
(3) (0) (2) (0) (1)
2 4
RUs to TSC RQS ACK
\________________/ \__________/ \____/

frame frame frame
1. ALH : General Aloha invitation (three-slot frame).
2. RQS : Random access call request.
3. AHY : Availability check message

- acknowledges the RQS message
- demands a response from the called radio unit (thereby checking
whether the called unit is in radio contact)
- inhibits random access in the next slot.
4. ACK : Acknowledgement from the called radio unit, sent in the reserved slot.
5. GTC : Go To Channel message instructing both radio units to switch to the

specified traffic channel for their call. In this example the GTC is
repeated, for added reliability.
Fig. 1-5 Common-prefix individual call
In this example, the called unit is in radio contact and therefore responds to the AHY.
If the called unit cannot be contacted, the TSC may indicate the failure to the calling unit by
sending acknowledgement ACKV.
In both this and the following example, the TSC checks only that the called unit is in
radio contact before allocating a traffic channel. The TSC may also check whether the
called user is ready; if he is not, the unit responds with acknowledgement ACKI and takes
action to alert him. Then, when the user is ready to receive the call, the unit may send a
status message (RQQ) to inform the TSC.
The ALH(0) message in these examples is used as a "dummy" message, in slots

carrying no signalling relevant to the example. In practice, these slots may be used for
signalling for another call, or for broadcast messages (which contain information about
system parameters).

1.3.5.3 Example: radio unit calls a unit with a different prefix
Figure 1-6 illustrates a message sequence on a control channel to set up a call

between two radio units with different prefixes.
The sequence includes call request, availability check and channel allocation
signalling (as in the previous example). However, this sequence has an extra phase: after
receiving the RQS message, the TSC sends AHYC to invite the calling unit to transmit the
full called address. Also, separate GTC messages instruct the two units, because GTC
contains only one prefix.
1 3 5 7 8
TSC to RUs ALH ALH AHYC ALH AHY ALH GTC GTC
(4) (0) (0) (2) (0) (1)
2 4.. 6
RUs to TSC RQS SAMIS ACK
\_____________________/ \________/ \____/
frame frame frame
1. ALH : General Aloha invitation (four-slot frame).
2. RQS : Random access request for an interprefix call. (The

request contains the calling unit's address (prefix/ident),
but the called ident is set to a special "gateway" ident to
indicate that extended addressing procedures are
needed.)
3. AHYC : Short data invitation message

- instructs the calling unit to send the called address
4. SAMIS : Single Address Message from the calling radio unit, containing the
address (prefix/ident) of the called unit.
5. AHY : Availability check message demanding a response from the

called radio unit.
In this example, the availability check is a single-codeword
message i.e. the address of the calling unit is not supplied.
6. ACK : Acknowledgement from the called radio unit.
7. GTC : Go To Channel message instructing the called radio unit to

switch to the specified traffic channel for the call.
8. GTC : Go To Channel message instructing the calling radio unit to switch

to the specified channel for the call.
Fig. 1-6 Interprefix individual call

1.3.5.4 Example: radio unit sends a short data message
Figure 1-7 illustrates a message sequence on a control channel for sending a short
data message from one radio unit to another radio unit. In this example, the data message
comprises an address codeword and two appended data codewords; (each of the data
codewords contains 46 bits of free format data).
In the sequence, the radio unit sends its request; the TSC instructs the unit to send
the data message, forwards the data message to the called unit and then indicates the
success of the transaction to the calling unit.
1 3 5 5 7
TSC to RUs ALH ALH AHYQ ALH ALH HEAD data ALH ACK ACK
(1) (1) (0) (2) (1) (1) (1)
2 4 4 6
RUs to TSC RQC HEAD data ACK
\____/ \____/ \__________/ \____/ \____/

1. ALH : General Aloha invitation (one-slot frame).
2. RQC : Random access request to transmit a short data message.

(The request indicates the number of timeslots required for
the data message: in this case, two slots.)

- acknowledges the RQC message
- instructs the calling unit to send the data message in
the next two slots.
4. HEAD + data : The calling radio unit sends its short data message to the
TSC. In this example the message comprises an address
codeword (HEAD) and two appended data codewords.
5. HEAD + data : The TSC forwards the short data message to the called radio
unit.
6. ACK : Acknowledgement from the called unit - message accepted.
7. ACK : Acknowledgement sent to the calling unit to indicate that the

called unit has accepted the data message. In this example
the TSC immediately repeats the ACK message, for added
reliability.
Fig. 1-7 Short data message

2. DEFINITIONS
Note - Words appearing within asterisks within these definitions are defined terms.
(eg *defined term*)
Active on a Channel: A *radio unit* is *active on a channel* when, on that

channel, it is enabled to respond to *messages* addressed to it, or is
transmitting, or is in transition between these two states.
Note - a *radio unit* becomes active on an assigned *traffic channel* as

soon as it can receive on that channel, whereas, on a *control channel* it
shall not become active until it has received a codeword containing an
appropriate *system identity code*.
Address: A 20-bit number by which a unit or group of units is known within a

*system*. The *address* comprises two *fields*; a 7-bit *prefix* and a 13-bit
*ident*.
Address Codeword: A 64-bit codeword, conforming to the requirements of this

standard, where the first bit is set to '1'. An *address codeword* is always
the first codeword in any *message*, and defines the nature of the
*message*.
Base Station: The entirety of transmitters and receivers operated by a *trunking

system controller* at any one site.
Call: A complete information exchange between two or more *parties* which

includes one or more *transactions* and may include direct user-to-user
communication on a *traffic channel*.
Called Unit (or Group): The unit, or group of units, which a *calling unit* identifies
as the desired recipient(s) of a *call*. The *called unit (or group)* retains this
designation for the duration of a *call* and this convention is used in
*messages* relating to that particular *call*, irrespective of the origin of such
*messages*.
Calling Unit: A *radio unit* or *line unit* which request a *call*. The *calling unit*
retains this designation for the duration of a *call* and this convention is
used in *messages* relating to that particular *call* irrespective of the origins
of such *messages*.
Common Prefix Call: A *call* where the values of the *prefixes* in the calling and
called *addresses* are the same. *Common prefix calls* use the *short
addressing* procedures.
Control Channel: A *forward channel* and *return channel* being used for the
transmission of *messages* conforming to this standard with the primary
purpose of enabling the *trunking system controller* to control radio units.
Data Codeword: A 64-bit codeword, conforming to the requirements of this

standard, where the first bit is set to '0'. *Data codewords* are concatenated
to an *address codeword* and supplement the information in the *address*
codeword*.
Dataitem: The whole, or a part of, a *Tmessage*. A dataitem may not include more
than 62 data codewords.

Decodeable: A transmitted codeword shall be considered *decodeable* if, after
receipt, and after any error correction (if used) has been applied, a valid
codeword from the code defined in section 3.2.3 of this standard is formed.
Diversion: A procedure whereby a *party* may request that future *calls* to a

particular called address be redirected to an alternative destination.
Extended Addressing: A method which allows called *party* details to be

conveyed to the *trunking system controller* when the *call* details cannot
be accommodated in a single *address codeword*. These called-party
details may be an *address* or addressing information in a different form
(eg PSTN dialling digits).
Field: A number of contiguous bits in a codeword which is specified in terms of the

position within the codeword and the number of bits.
Forward Channel: A radio bearer where the direction of transmission is form the
*base station* to *radio units*.
Fragment: A message which is either the whole of a *dataitem* or those codewords

of a *dataitem* for which repetition has been requested by the receiving
station.
Free Format Data: Data within a codeword which, in this standard, is constrained
only by its position and length.
Gateway: A *special ident* which is used to identify a *message* relating to a *call*

or *transaction* to or from a communications service outside of the *system*
(eg the PSTN). For the purposes of this standard the interprefix *ident*,
IPFIXI, is also regarded as a *gateway*.
Group Address: An *address* which is common to more than one unit and which,
when nominated as the called *address*, signifies a *group call*. Units may
be assigned any practicable number of *group addresses*.
Group Call: A *call* in which a *group address* is specified as the called *party*
and, accordingly, provides a means of communication between more than
two units. The calling *party* in a *group call* may opt for a conversational
mode, where all *parties* are able to speak, or for an announcement mode
where only the caller may speak.
Ident: A 13-bit number used for identification purposes. Values of *ident* between
1 and 8100 inclusive are assigned to individual units or groups, in which
case they are associated with a *prefix* to form a 20-bit *address*. Values
of *ident* above 8100 are designated *special idents* and these are not
associated with any particular *prefix*, neither is the *ident* value 0
(DUMMMYI).
Idle State: A *radio* unit* is in the *idle state* on a *system* when it is *active on a
control channel* belonging to that *system*, is not currently within a
*message* exchange and has no current *message* transfer requirement.
Include: A procedure whereby *parties* may be introduced into a *call* in progress

at the request of an existing *party* to the *call*.
Individual Address: An *address* by which a single unit is known within a

*system*, allowing that unit to be uniquely addressed by that *system*. Units

may be assigned any practicable number of *individual addresses* provides
that at least one per *systems* is assigned to each unit.
Individual Call: A *call* between a calling *party* and a single called *party*.
Interprefix Call: A *call* where the values of the *prefixes* in the calling and called
*addresses* are different. *Interprefix calls* require *extended addressing*
procedures.
Invoking message: A message from the TSC to a radio unit which requires or
invites an immediate message from the radio unit according to the timing
rules specified in section 6 if the transmission rate is 1200 bit/sec or the
equivalent rules at any other transmission rate.
Item: A complete user transmission on a *traffic channel* by one *party* within a

*call* at the conclusion of which that *party* rests from transmission. It is
possible for a *call* to contain only one *item*.
Line Unit (LU): A user station which is allocated an *individual address*, and is
directly connected to the *trunking system controller* via a medium other
than the radio spectrum to which this standard applies.
Link: Any transmission path in the communication chain between the end users in
a Standard Data call, and particularly the radio connection between the TSC
and its dependent radio unit in such a call.
Message: A single contiguous data transmission which consists of a codeword

synchronisation sequence, an *address codeword* and (optionally) one or
more *data codewords* conforming to this standard.
Non-prescribed data: Any data traffic which does not conform to the data
protocols defined in this standard.
Party: A source and/or recipient of information within a *call*. The term includes
the totality of equipment at the user station and, where the context permits,
the equipment user. A party may be an individual or a group.
Prefix: The 7 most significant bits of an *address*. Normally units within a fleet will
be allocated the same *prefix* since *calls* between units and groups with
the same *prefix* can be made without the use of *extended addressing*
procedures. A *prefix* is only relevant to *individual addresses* and *group
addresses*.
Radio Unit (RU): A mobile or other user station contacting a *system*, by normal
land mobile radio in accordance with this standard.
Random Access Attempt: The method by which a *radio unit* transmits an

unsolicited *message* to the *trunking system controller* on a *control
channel*. The method requires that a *radio unit* repeats a random access
*message* if a response *message* is not received within a designated
waiting time. Further repeats are required, in the absence of an
appropriate acknowledgement, until a designated number of repeats is
reached. In this standard a *random access attempt* covers the period
from initiation of the *transaction* to the receipt of an appropriate
acknowledgement or the expiry of a timeout.
Ready-for-Communication Control (RFCC): A device or system to inform a unit

of the user's readiness to communicate, eg a switch-hook.

Registration: A procedure which confirms that a *radio unit* is within a *session*
on a *system*. The *registration* procedures may be initiated by a demand
from the *trunking system controller*, or at the initiative of the *radio unit*,
depending on the circumstances of the *registration*.
Requested Unit (or Group): A unit, or group of units, which takes part in a
*transaction* initiated by the *trunking system controllers* or another *party*.
Requesting Unit: A *radio unit* or *line unit* which initiates a *transaction* with the
*trunking system controller* or another *party*, via the *trunking system
controllers*.
Reserved: Codewords and *fields* which are designated as *reserved* in this

standard are intended for future phases of standardisation and shall not be
used in the interim for the conveyance of information. *Reserved fields*
must be set to the default value specified in this standard.
Return Channel: A radio bearer where the direction of transmission is from *radio
Units* to the *base station*.
Session: A *session* is a period of operation associated with one *system*. A

*session* on a *system* starts when the *radio unit* becomes *active on a
control channel* of that *system*, either after switch-on or after being
*active on a control channel* of a different *system*. A *session* ends
either when the *radio unit* is switched off or when it starts its next
*session*.
Short Addressing: The method used when the *parties* to a *call* can be
completely specified by a single *prefix* and two *idents*. This form of
addressing minimises the signalling required.
Short Data: A procedure which allows a data *message* to be exchanged between

*parties*, or between *parties* and the *trunking system controller*. This
procedure does not support *messages* which include more than four *data
codewords*.
Short-Form PSTN Destination: A called PSTN *party*, previously agreed

between the system operator and the user of the *calling unit*, which can be
specified by a *special ident*, rather than the full stream of dialling digits
representing the directory number.
Spare: Codewords and *fields* which are designated as *spare* are available for
free use by *systems* (ie *system* customisation) provided that the
conditions of this standard are not infringed. The use of spare codewords
and *fields* may vary from *system* to *system*.
Special Ident: An *ident* with a value greater than 8100. These *idents* are used
for a variety of special purposes. Some of these are specified in this
standard, others may be nominated by system operators. *Special idents*
are not associated with a *prefix* to form an *address*.
Standard Data: The procedure by which information exchange takes place using
the data protocol defined in section 17 of this standard.
System: The totality of equipment required to provide the communication facilities

associated with a single *system identity code*. *Systems* may be
combined to form larger communications facilities, but the delineation

of *systems* and methods of combination are not within the scope of this
standard.
System Identity Code: A 15-bit number which contains a unique identification of a

*system*. This code is radiated on each *forward control channel* within
the *system* (in the SYS *field*).
Tmessage: A quantity of *user data* which the correspondents by previous

bilateral agreement have mutually agreed is useful to them as a distinct
entity, and is marked as such by the originator for end-to-end transmission.
Traffic Channel: A *forward channel* and *return channel* being used primarily for
user communication.
TRANS: A 10 bit transaction number allocated to a *link* during set-up of a data call
to replace the address and port of the radio unit. The validity of a TRANS
ceases at the conclusion of the data call.
Transaction: A complete information exchange consisting of one or more

*messages* between a *party* and the *trunking system controller*, or
another *party*, via the *trunking system controller*.
Trunking System Controller (TSC): The central control intelligence necessary to

enable the trunking system to function according to this standard. The
*trunking system controller* may control one or more *basestations*.
User Data: Data from or to the user which is either to or from his correspondent, or
is concerned with call routing but is transmitted after a *TRANS* for the call
has been allocated.
User Data Message: A message headed by address codeword "SITH" and

containing user data.

3. SIGNALLING FORMATS
This section defines the basic signalling formats used by this standard. The detailed
structure of the codewords is defined in section 5, and the timing constraints for the
transmission of messages are defined in section 6.
The provisions of this section do not preclude the use of other, non-prescribed
formats on a traffic channel.
3.1 Basic Format
Signalling transmissions shall employ Fast Frequency Shift Keying (FFSK) at a bit
rate of 1200 bit/s. The basic components of the signalling formats are illustrated in
Figure 3-1.
LET Preamble Message H
Fig. 3-1. Basic format
3.1.1 LET
Signalling transmissions shall be preceded by a Link Establishment Time (LET) within

which a transmission of undefined modulation at not less than 90% of maximum power
shall take place. The duration of the LET shall be as specified in section 3.3.3.1 and
section 6.
3.1.2 Preamble
Signalling transmissions shall begin with a preamble of bit reversals 1010 . . . 10 so

that the receiver data demodulator can acquire bit synchronisation. The preamble shall
consist of a minimum of 16 bits and shall end with a binary zero.
3.1.3 Message
A message is a contiguous transmission consisting of a codeword synchronisation

sequence, an address codeword and, where appropriate, one or more data codewords
(see 3.2).
3.1.4 Hang-over Bit, H
Signalling transmissions shall be terminated by appending a "hang-over" bit of either

binary zero or binary one to the last transmitted message.

3.2 Message Format
A message consists of a codeword synchronisation sequence, an address codeword
and, where appropriate, one or more data codewords, as shown in Figure 3-2. The
address codeword defines the nature of the message, and data codewords supplement the
information in the address codeword.
Codeword Sync Address Data Codewords (where

Sequence Codeword appropriate)
Fig. 3-2. Message format
3.2.1 Codeword synchronisation sequence
The codeword synchronisation sequence shall be transmitted to enable decoders to

establish codeword framing. It consists of 16 bits.
3.2.1.1 Control channel codeword synchronisation sequence
The codeword synchronisation sequence for messages transmitted on a control

channel, SYNC, is shown in Figure 3-3. Bit number 1 shall be transmitted first.
bit no 1 16
1 1 0 0 0 1 0 0 1 1 0 1 0 1 1 1
Fig. 3-3. Control channel codeword synchronisation sequence, SYNC
3.2.1.2 Traffic and Standard Data channel codeword synchronisation

sequence
The codeword synchronisation sequence for messages transmitted on a traffic or

standard data channel, SYNT, is shown in Figure 3-4. Bit number 1 shall be transmitted
first. If a control channel is allocated for traffic, then SYNT shall be used for all messages
transmitted while the channel is assigned for traffic.
bit no 1 16
0 0 1 1 1 0 1 1 0 0 1 0 1 0 0 0
Fig. 3-4. Traffic and Standard Data channel codeword synchronisation

sequence, SYNT

3.2.2 Codewords
Messages shall be transmitted in 64-bit codewords. Each codeword shall contain 48

information bits followed by 16 check bits. There are two types of codeword, address and
data codewords, which are distinguished by the first bit (A) within the codeword; see Figure
3-5. Bit number 1 shall be transmitted first.
bit no. 1 2 48 49 64
A information field check bits

no. of bits 1 47 16
Bit 1 (A) - Binary one denotes an address codeword. Binary zero

denotes a data codeword.
Bits 2 to 48 - Information field; see section 5.
Bits 49 to 64 - Check bits; see section 3.2.3.
Fig. 3-5. Codeword structure
3.2.3 Encoding and error checking
The first 15 check bits are derived from a (63,48) cyclic code. For encoding, the
codeword bits 1 to 48 represent the coefficients of a polynomial having terms from X62
down to X15. This polynomial is divided modulo-2 by the generating polynomial:
X15 + X14 + X13 + X11 + X4 + X2 + 1
The 15 check bits correspond to the coefficients of the terms from X14 to X0 in the remainder
polynomial found at the completion of the division. The final check bit of the (63,48) cyclic
code (codeword bit 63) is then inverted. Finally, one bit is appended to the 63-bit block
(including the inverted bit number 63) to provide an even parity check of the whole 64-bit
codeword.
Decoding algorithms are not prescribed in this standard; for the error control
properties of the codeword, see Appendix 2.

3.3 Signalling Transmission Variants
3.3.1 Single message format
The format for signalling transmissions which contain a single message is shown in
Figure 3-6.
LET Preamble Message H
Fig. 3-6. Single message format
3.3.2 Multiple message format on a traffic channel
The format for standardised signalling transmissions which contain more than one
message is shown in Figure 3-7. This format shall be used only on traffic channels.
LET Preamble Message bit reversals Message
Fig. 3-7. Multiple message format
For multiple messages transmitted by a radio unit, there shall be 16 bits of bit
reversals between messages. For multiple messages transmitted by the TSC, bit reversals
may be inserted between the messages as required. The final bit of any bit reversals
(before the next message) shall be a binary zero.

3.3.3. Forward control channel format
3.3.3.1 Basic control channel format
The start-up sequence for a base station commencing transmission on a control

channel shall be as shown in Figure 3-8.
LET Preamble SYNC ADD1 CCSC ADD2 CCSC ADD3
←start-up sequence→ ←1 slot→ ←1 slot→
LET - Link establishment time of at least 6 bit periods (5 ms).
Preamble - At least 16 bits of bit reversals, ending with a binary zero.
SYN - Control channel codeword synchronisation sequence; see 3.2.1.1.
ADDn - Address codeword (any appropriate message); see section 5.
CCSC - Control Channel System Codeword; see 5.1.
Fig. 3-8. Basic control channel format
Following the start-up sequence the TSC shall divide time into slots, each comprising
two codewords. The first codeword of a slot shall be the Control Channel System
Codeword (CCSC), unless displaced by a data codeword from a previous message. The
second codeword of a slot shall be an address codeword, unless displaced by a data
codeword (see 3.3.3.2).
Every address codeword in a slot shall be preceded by a CCSC. The CCSC

identifies the system to radio units and provides control channel slot synchronisation. It is a
data codeword in which the final 32 bits form the preamble and codeword synchronisation
sequence for the following address codeword (see 5.1).
The MARK address codeword (see 5.5.4.1) may be transmitted by the TSC on a
newly designated control channel during the period allowed for radio units to locate and
identify the control channel (see 6.1.1).

3.3.3.2 Data codeword displacement
When data codewords are transmitted as part of a message, they displace CCSCs
and address codewords, as illustrated in Figure 3-9. Radio units must be capable of
satisfactory operation despite this displacement (see section 6). The TSC shall not
displace more than two CCSCs in consecutive timeslots.
CCSC ADDn DCW1 DCW2 DCW3 DCW4 CCSC ADDn+1
←-1 slot-→ ←-1 slot-→ ←-1 slot-→ ←1 slot→
CCSC - Control Channel System Codeword

ADDn - Address codeword (any appropriate message).
DCWm - Data codeword in message.
Fig. 3-9. Example of data codeword displacement
When a message includes an odd number of data codewords, a "filler" data

codeword shall be appended to the message (to maintain the slot structure); the content of
the filler data codeword is not prescribed in this standard. See also section 7.2.5.

4. ADDRESSING
The unit address enables the TSC to recognise the source of messages and/or to
direct messages to a particular unit or group of units. In addition, addresses may be used
by the TSC to regulate access to the system.
This standard permits considerable flexibility in the way that unit addresses can
be allocated, allowing each system full use of all available addresses. However system
operators shall not allocate addresses in such a way that two units, using the same
individual address, could be active on a system concurrently. Further, this standard does
not support address reuse within interconnected systems.
The protocol allows over 32000 system identity codes and over one million
addresses. A unit may be allocated different addresses for each system within which it is
required to operate, or its addresses can be common to more than one system.
Unit addresses can be used for individual units or for groups of units. A group
can be formed by allocating a common address to all members of the group. All units shall
have at least one individual address.
Individual and group addresses consist of a 7-bit prefix and a 13-bit ident.
Normally units within a fleet will share a common prefix, since this allows the short
addressing procedures to be used during call set-up. Idents allocated to units must be
equal to the binary equivalent of decimal numbers in the range 1 to 8100, inclusive.
The ident value 0 shall not be allocated to any unit and is designated the
"dummy" ident, DUMMYI; this ident may be used as a null value.
Values of ident above 8100 are designated special idents and are not available
for allocation to units. Use of these special idents allows a number of additional
procedures and facilities to be achieved within this protocol standard. Some special idents
are designated as gateways. These are used for calls which involve connection to
communication facilities external to the system.
The arrangement of idents is summarised in Table 4-1.
Ident number 0 and special idents do not have a prefix associated with them; the
prefix is only relevant to individual unit and group addresses.
The system-wide all-call ident applicable to all units (irrespective of prefix) is

denoted by ALLI. The individual ident of the Trunking System Controller (TSC) is denoted
by TSCI; this ident is the same for all TSCs.

Special idents are also employed within certain call procedures described in this
standard. These include:
SDMI: which is used in the short data message procedures;

DIVERTI: which is used during call diversion procedures;
INCI: which is used by the TSC when checking the availability of a
unit requested to be included in a call;
and REGI: which is used by the TSC in the registration procedures.
Two methods, both of which employ gateway idents, are provided for radio units
requesting calls to the PSTN, namely:
- "short-form" calls, to destinations previously nominated (eg

the radio unit's head office).
- "general" calls, to any PSTN destination.
Radio units requesting calls to prearranged PSTN or Data Network destinations

use the short addressing procedures, with the called ident set to an appropriate "short-
form" PSTN or Network ident. These short-form idents are denoted by PSTNSIj or NETSIj
respectively, for j = 1 to 15. PSTNSIj is used for all appropriate call requests except RQD,
and NETSIj is only used in RQD call requests. Each short-form ident allocated to a radio
unit shall represent a complete destination previously agreed between the system operator
and the radio user. A particular short-form ident may be reused for other radio units, each
use having a distinct meaning. Thus, when a short-form call is requested, the TSC shall
determine the meaning of the particular short-form ident by reference to the calling radio
unit's address. The same principle can be applied to incoming calls.
Radio units requesting a "general" PSTN call use the gateway ident, PSTNGI. In
this case, units are required to provide the full dialling information for the PSTN destination
using the extended addressing procedures described in this standard.
Radio units requesting a "general" data network call use the gateway ident, DNI. In
this case units will be allocated a data channel and TRANS. After this they supply the
network addressing information on the data channel in a format appropriate to that network.
Radio units can request calls to PABX extensions using the short addressing
procedures, provided that the extension number can be represented by 13 bits. A call may
be to any one of four PABX exchanges, as previously agreed between the system operator
and the radio use - the TSC shall determine the appropriate exchange by reference to the
calling radio unit's address. Calls to PABX destinations that cannot be accommodated by
the short addressing procedures use the PABX gateway ident, PABXI, and the extended
addressing procedures.
Calls between units which do not share a common prefix also require use of the
extended addressing procedures. For such calls the appropriate special ident is IPFIXI.

Meaning Notation Ident
System-wide ident ALLI 8191

Ident of TSC TSCI 8190
Interprefix ident IPFIXI 8189
Short data message ident SDMI 8188

Divert ident DIVERTI 8187
Include ident INCI 8186
Registration ident REGI 8185
Reserved for future allocation 8181 - 8184
Spare for customisation of systems 8136 - 8180
Short-form PSTN idents PSTNSIj 8121 - 8135} Note:Common

Short-form data Network idents NETSIj 8121 - 8135} range.
(j = 1 ... 15)
Reserved for future allocation 8104 - 8120
Data Network gateway ident DNI 8103

PABX gateway ident PABXI 8102
General PSTN gateway ident PSTNGI 8101
User idents 1 - 8100

(individual and group idents)
Dummy ident DUMMYI 0
Table 4-1 - Ident Numbering Scheme

5. CODEWORD STRUCTURES
This section lists the codewords used in the standardised messages and defines their
structure. A brief indication of the usage of the messages is given, but readers should refer
to the procedures sections for a full definition of usage. Readers may find it helpful to
study the procedures sections together with this section rather than consecutively.
It is not a mandatory requirement on either a TSC or a radio unit to understand the

meaning of all the standardised messages. The messages that must be used will depend
on the facilities implemented in a TSC and a radio unit; the procedures sections define
which messages are required.
Standardised fields
The codewords are shown broken down into their constituent fields, with a definition
of the meaning of each field. The fields in the codewords shall be set to appropriate
values. Machine transmission of fields is most significant bit first.
In this standard, the numerical value of a field is referred to either by the decimal
equivalent of the bit sequence concerned, with leading zeros suppressed, or in binary.
Binary values are shown enclosed in apostrophes, e.g. Type '11', except in the codeword
diagrams in this section.
When the prefix is not required to complete an address (e.g. for special ident ALLI), it
may be set to an arbitrary value and, on reception, its value shall be considered to have no
significance.
Reserved fields
Some fields are designated as "reserved". In the future development of this

standard, the whole or any part of a reserved field may be designated for a specific
purpose. Any such designation will be made in a manner that does not cause any existing
application of this standard to cease to comply with the standard or to suffer a reduction in
its functionality. Neither the existing protocol procedures nor the already designated
meanings of messages will be changed in order to bring a reserved field into service.
Therefore, equipments complying with this issue of the standard shall, on

transmission, set reserved fields to the specified default value and, on reception, shall
consider the value of reserved fields to have no significance. Equipments which
understand the designation of any previously reserved field shall, on transmission, note
that the recipient equipment may attribute no significance to that field or, on reception, shall
be prepared to accept the default value of that field.

Spare fields and codewords
There are "spare" fields and codewords available for customisation of services (see
section 5.2). Spare fields and codewords will never be used within this standard, but may
be designated for a specific purpose within any given application of this standard. In
applications where spare fields or codewords are employed, rules shall be generated
governing their use. Any designation of spare fields and codewords shall not modify the
meaning of standardised fields and codewords.
Unless a radio unit knows the meaning of spare fields and codewords on the system it is
currently using, it shall not transmit spare messages to the TSC, nor take any action on
receiving spare messages from the TSC, nor use the spare fields in standardised
messages received from the TSC.

5.1 System Codewords
5.1.1 Control Channel System Codeword (CCSC)
The Control Channel System Codeword is transmitted on a control channel by a TSC

in order to identify the system to radio units and to provide control channel slot
synchronisation (see section 3.3.3). It is a data codeword, structured as shown below.
0 SYS CCS PREAMBLE P

1010101010101010 1100010011010111
no. of bits 1 15 16 16 16
SYS - System identity code of the transmitting system.

Values of SYS which result in production of the control channel
codeword synchronisation sequence, SYNC, in any part of the 48
information bits of the CCSC are not permitted.
CCS - Codeword Completion Sequence, chosen so that the parity check

bits P always form the control channel codeword synchronisation
sequence. The bit values of the CCS will depend on the system
identity code; an algorithm for generating the CCS is given in
Appendix 3.
PREAMBLE - Preamble bit reversals, ending with a '0'.
P - Parity check bits.

These complete the codeword and also form the control channel
codeword synchronisation sequence, SYNC (section 3.2.1.1).

5.1.2 Data Channel System Codeword (DCSC)
The DCSC is transmitted on a data channel by the TSC in order to identify the system to
radio unit's and to provide data channel slot synchronisation. It is a data codeword as
shown below:
0 SYS DCS PREAMBLE P

1010101010101010 0011101100101000
no. of bits 1 15 16 16 16
SYS - System identity code of the transmitting system. Values of SYS

which result in production of the data channel codeword
synchronisation sequence, SYNT, in any part of the 48 information
bits of the DCSC are not permitted.
DCS - Data-codeword Completion Sequence, chosen such that the parity

check bits form the data channel sychronisation sequence (SYNT).
An algorithm for determining the codeword completion sequence
(DCS) of a data channel system codeword (DCSC) is given in
appendix 3.
PREAMBLE - Preamble bit reversals, ending with a '0'.

These complete the codeword and also form the Standard Data
channel codeword synchronisation sequence, SYNT (section
3.2.1.2).

5.2 General Address Codeword Structure
There is a general address codeword structure which is divided into 8 categories, and
one special structure for a "Go To Channel" message (see 5.4). The general and GTC
structures are distinguished by Bit 22 of the codeword; Bit 22 of the general structure is
always '1' whereas Bit 22 of the GTC codeword is set to '0'.
The most usual general structure is shown below.
no. of bits 1 20 1 3 23 16
0 PARAMETERS 1 CAT other fields PARITY
: : :
: : 2 : 3 : 18 :
Category '000' Messages: 000 TYPE FUNC PARAMETERS
: : : :
: 00 FUNC 8 Alohas
: 01 FUNC 8 Acknowledgments
: 10 FUNC 8 Requests/Ahoys
: 11 FUNC 8 Miscellaneous
: : :
: : 2 : 22 :
Category '001' Messages: 001 TYPE PARAMETERS
: : :
: 0 Single address messages
: 1 Short Data Message
: : :
: : 1 : 22 :
Category '010' Standard Data 010 KIND PARAMETERS
Messages: : :
: 0 Go To Transaction and General Information
: 1 Request/Ahoy
: : :
011 spare
100 spare
: :
: : 1 : 4 : 18 :
Category '101' Standard Data 101 KIND JOB PARAMETERS
Messages: : :
: 0 JOB
: : : :
: 0xxxx 6 Acknowledgements
: 1xxxx 3 Requests, 4 Ahoys
: : : :
: : 1 : 1 : 21 :
101 KIND TASK PARAMETERS
: 0 TASK
: : : :
0 1 Selective Acknowledgement
: 1 1 Fragment address codeword
: :
110 reserved
111 reserved

Categories zero, one two, and five (CAT = '000', '001', '010' and '101') contain
standardised codewords. The "reserved" codewords are intended for future expansion of
the standard message set, whereas the "spare" codewords may be used for customisation
of services.
It is anticipated that reserved categories could be used for the definition of polling
and other data communication protocols etc. in a future phase of standardisation.

5.3 List of Address Codewords
Mnemonic Meaning Section
GTC Message: GTC Go to channel command 5.4
CAT '000' Messages: 5.5

TYPE '00' Aloha invitations: 5.5.1
ALH general
ALHS standard data excluded
ALHD "Simple" calls excluded
ALHE emergency only
ALHR registration or emergency
ALHX registration excluded
ALHF fall-back mode
reserved
TYPE '01' Acknowledgements: 5.5.2

ACK general
ACKI intermediate
ACKQ call queued
ACKX message rejected
ACKV called unit unavailable
ACKE emergency
ACKT try on given address
ACKB call-back / negative ack
TYPE '10 Requests (sent by RUs): 5.5.3.1

RQS "Simple" 5.5.3.1.1
spare 5.5.3.1.2
RQX cancel/abort 5.5.3.1.3
RQT divert 5.5.3.1.4
RQE emergency 5.5.3.1.5
RQR registration 5.5.3.1.6
RQQ status 5.5.3.1.7
RQC short data 5.5.3.1.8
Ahoys (sent by TSC): 5.5.3.2

AHY general availability check 5.5.3.2.1
spare for customisation 5.5.3.2.2
AHYX cancel alert/waiting state 5.5.3.2.3
reserved 5.5.3.2.4
reserved 5.5.3.2.5
AHYP Called Unit Presence Monitoring 5.5.3.2.6
AHYQ status message 5.5.3.2.7
AHYC short data invitation 5.5.3.2.8
TYPE '11' Miscellaneous: 5.5.4

MARK control channel marker 5.5.4.1
MAINT call maintenance 5.5.4.2
CLEAR call clear-down 5.5.4.3
MOVE move control channel 5.5.4.4
BCAST broadcast 5.5.4.5
reserved
reserved
reserved
contd.

List of Address Codewords, contd.
Mnemonic Meaning Section
TYPE '0' Single address messages: 5.6.1

CAT '001' Messages: 5.6
SAMO Outbound 5.6.1.1
Inbound: 5.6.1.2
SAMIU inbound unsolicited 5.6.1.2.1
SAMIS inbound solicited 5.6.1.2.2
TYPE '1' HEAD Short data message 5.6.2
CAT '010' Messages: Codewords applicable to Standard Data 5.7
Kind '1' RQD Request for Standard Data 5.7.1

AHYD Availability check 5.7.2
Kind '0' GTT Go To Transaction 5.7.3

DRUGI Radio Unit General Information 5.7.4
CAT '011' Messages: spare
CAT '100' Messages: spare
CAT '101' Messages: Standard Data 5.8
KIND '0'
JOB FROM TSC FROM radio unit
'0000' DACK+DAL 5.8.2

'0001' DACK+DALG 5.8.2
'0010' DACK+DALN 5.8.2
'0011' DACK+GO DACK+GO 5.8.2
'0100' DACKZ DACKZ 5.8.3
'0101' DACKD DACKD 5.8.1
'0110' reserved
'0111' spare
'1000' DAHY RSVD 5.8.4
'1001' RSVD RSVD
'1010' RSVD DRQG 5.8.8
'1011' RSVD RSVD
'1100' DAHYZ DRQZ 5.8.9
'1101' RSVD RSVD
'1110' DAHYX DRQX 5.8.6/5.8.10
'1111' RLA RLA 5.8.7
KIND '1'
TASK
'0' SACK SACK 5.8.11

'1' SITH SITH 5.8.12
CAT '110' Messages: reserved
CAT '111' Messages: reserved

5.4 Go To Traffic Channel Message, GTC
This message is transmitted on a control channel from a TSC to radio units. It
directs the addressed radio units to switch to a designated channel and proceed with
communication.
This message may also be transmitted on a traffic channel to move radio units
already in communication to a replacement traffic channel. When the units have retuned to
the replacement channel, communication may continue.
1 PFIX IDENT1 0 D CHAN IDENT2 (N) P

no. of bits 1 7 13 1 1 10 13 2 16
PFIX - Unit or group prefix.

IDENT1 - Called party or gateway:
Ident - for a common-prefix call, a call from a PABX
extension or from the PSTN, or an Include call.
Ident - for an interprefix call when the message is sent to the
called party.
IPFIXI - for an interprefix call when the message is sent to the
calling party.
ALLI - for a system-wide call.
PABXI - for a call to a PABX extension.
PSTNSIj - for a call to a prearranged PSTN destination.
PSTNGI - for a call to a general PSTN destination.
DUMMYI - for an intersite call where the calling party is active on
the same timeshared control channel. (Option 1)
TSCI - for an intersite call where the calling party is active on
the same timeshared control channel. (Option 2)
D - '0' if the addressed radio units shall unmute the audio (for
speech communication).
'1' if the addressed radio units shall mute the audio (for data
communication), and need not send maintenance messages
within items unless required by the system by
prearrangement.
CHAN - Designates the allocated channel number.
IDENT2 - Calling party or gateway:
Ident - for a common-prefix call to a unit or group of units, a
system-wide call, or a call to a PABX extension or to
the PSTN.
Ident - for an interprefix call when the message is sent to the
calling party.
IPFIXI - for an interprefix call when the message is sent to the
called party.
PABXI - for a call from a PABX extension.
PSTNGI - for a call from the PSTN.
INCI - for an Include call.
DUMMYI - for an intersite call where the called party is active on
the same control channel. (Option 1)
TSCI - for an intersite call where the called party is active on
the same control channel. (Option 2)
(N) - Aloha number.
See random access protocol (section 7).

5.5 Category '000' Messages
5.5.1 Aloha Messages (Type '00')
These messages are transmitted on a control channel by a TSC - see section 7.

They invite radio units to transmit single codeword random access messages in the
designated frame of timeslots. An Aloha message may also be used to demand a
response from an individually addressed radio unit.
1 PFIX IDENT1 1 CAT TYPE FUNC CHAN4 WT RSVD (M) (N) P

000 00
1 7 13 1 3 2 3 4 3 2 5 4 16
PFIX - Prefix (see also IDENT1).
IDENT1 - PFIX/IDENT1 specifies the radio units that are invited to transmit.
Only the (M) least significant bits of the 20-bit address are used;
the remaining address bits may be set arbitrarily.
CAT - '000'.
TYPE - '00'.
FUNC - Specifies the function of the Aloha invitation:

'000' ALH Any single codeword message invited.
'001' ALHS Messages invited, except RQD.
'010' ALHD Messages invited, except RQS.
'011' ALHE Emergency requests (RQE) only invited.
'100' ALHR Registration (RQR) or emergency requests
(RQE) invited.
'101' ALHX Messages invited, except RQR.
'110' ALHF Fall-back mode; messages invited only from
radio units which know the fall-back method used
by this system.
The fall-back mode is a customised mode of
operation used only in the case of equipment
malfunction.
'111' Reserved for future use.
The rules defining the Aloha functions appropriate to customised
random access messages are system-dependent.
CHAN4 - Least significant four bits of the channel number of the control
channel on which the message is sent; (to protect against
breakthrough).
contd.

WT - Delay parameter for repeat transmissions.
RSVD - Reserved for future definition. Default value = '00'.
(M) - Address qualifier.

(N) - Aloha number.

5.5.2 Acknowledgement Messages (Type '01')
These messages may be sent by the TSC at various stages of call set-up, and by a
radio unit in response to a TSC message that demands a reply. The meanings of these
messages vary both according to the function of the messages they acknowledge, and
according to the source.
The basic structure of the acknowledgements is illustrated below but, for clarity, it is
shown separately for TSC source and radio unit source in subsections 5.5.2.1 and 5.5.2.2
respectively.
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 QUAL (N) P

000 01
1 7 13 1 3 2 3 13 1 4 16
PFIX - Prefix.
IDENT1 - Ident of the called party or gateway.

(This is the called party or gateway in the call for which the
acknowledgement is being sent.)
CAT - '000'.
TYPE - '01'.
FUNC - Specifies the function of the acknowledgement:

'000' ACK General acknowledgement
'001' ACKI Intermediate acknowledgement, more signalling
to follow
'010' ACKQ Acknowledge, call queued
'011' ACKX Acknowledge, message rejected
'100' ACKV Acknowledge, called unit unavailable
'101' ACKE Acknowledge emergency call
'110' ACKT Acknowledge, try on given address
'111' ACKB Acknowledge, call-back, or negative
acknowledgement.
IDENT2 - Ident of the calling party or gateway.

(This is the ident of the party or gateway that originated the call
for which the acknowledgement is being sent.)
QUAL - Qualifies the function (FUNC) of the acknowledgement.
(N) - Aloha number in messages transmitted by a TSC.

Reserved in messages transmitted by radio units;
default value = '0000'.

5.5.2.1 Acknowledgement messages sent by the TSC
The acknowledgement messages may be sent by the TSC at various stages of call
set-up (or during transactions), to indicate the progress of the call. Data codeword(s) may
be appended to an ACKT address codeword to convey additional information, depending
on the value of IDENT1.
Acknowledgement address codeword:

000 01
1 7 13 1 3 2 3 13 1 4 16
PFIX - Prefix of the calling radio unit.

Ident - for a common-prefix call.
IPFIXI - for an interprefix call.
ALLI - for a system-wide call.
PABXI - for a call to a PABX extension.
PSTNSIj - for a call to a prearranged PSTN destination.
TSCI - for an RQQ or RQC transaction with the TSC.
DIVERTI - for general cancellation by a recipient of
diversions.
In acknowledgements to RQR, IDENT1 = REGI.
In ACKT(QUAL=0), IDENT1 is the diversion ident or gateway; if IDENT1 =

IPFIXI, PABXI or PSTNGI, the diversion address is given in appended data
codeword(s) - see below. If a call to an individual address has been
diverted to a group address, or vice versa, IDENT1 in ACKT is set to IPFIXI
and the diversion address is given in an appended data codeword (with bit
GF set appropriately).
In acknowledgements to RQR, IDENT1 = REGI.
CAT - '000'.
TYPE - '01'.
FUNC - ACK, ACKI, ACKQ, ACKX, ACKV, ACKE, ACKT or ACKB.
IDENT2 - Ident of the calling radio unit.

See below.
(N) - Aloha number.


contd.

Data codewords following ACKT(QUAL=0) address codeword:
When ACKT(QUAL=0) is transmitted by the TSC, up to three data codewords may

be appended to convey the diversion address or dialling information. The form of these
data codewords depends on the value of IDENT1.
a. If IDENT1 = PSTNGI then up to three data codewords with the following structure
may be appended to ACKT(QUAL=0):
0 RSA FCW eleven BCD digits P
1 1 2 11 x 4 16
RSA - Return Slot Access Flag.

When transmitted by the TSC on a control channel in the
second half of a slot preceding an access slot:
'0' - radio units are not permitted random access in the
following slot on the return control channel.
'1' - radio units are permitted random access in the
following slot on the return control channel.
In all other cases of transmission, the meaning of the RSA
flag is reserved, default='0'. See also 7.2.5.
FCW - Number of data codewords appended to this data codeword (in

the same message):
'00' no data codewords follow
'01' one data codeword follows
'10' two data codewords follow
'11' reserved.
BCD - Eleven BCD groups representing the dialled digits of the diversion
PSTN destination, coded in accordance with the table in
Appendix 5. The BCD digits are transmitted in the dialled order
(i.e. the leftmost digit in the above diagram is the earliest in the
dialling order; digits in any following codeword are later in the
dialling order).
contd.

b. If IDENT1 = PABXI then a single data codeword with the following
structure is appended to ACKT(QUAL=0):
0 RSVD SP PARAMETERS P
1 10 1 36 16
RSVD - Reserved for future definition. Default value = all '0's.
SP - '0' for a "long" PABX extension number.

'1' for an extension number that can be represented by 13 bits.
PARAMETERS - See parameter formats below.
Parameter formats
If SP='0' BCD1 BCD2 BCD3 BCD4 BCD5 BCD6 BCD7 BCD8 BCD9
4 4 4 4 4 4 4 4 4
BCDn - BCD groups representing the dialled digits of the diversion PABX
destination, coded in accordance with the table in Appendix 5.
The BCD digits are transmitted in the dialled order.
If SP='1' RSVD EXCHANGE Number
21 2 13
EXCHANGE - Indicates the appropriate PABX exchange.
Number - PABX extension number.
contd.

c. If IDENT1 = IPFIXI then a single data codeword with the following structure is
appended to ACKT(QUAL=0):
0 RSVD GF PFIXT IDENTT P
1 26 1 7 13 16
GF - '0' if the diversion address is an individual address.

'1' if the diversion address is a group address.
PFIXT - Prefix of the diversion address.
IDENTT - Ident of the diversion address.
contd.

Acknowledgements sent to calling radio unit to indicate progress of Simple or
emergency call (as requested by an RQS or RQE message):
ACKI (QUAL=0) - Called unit alerting but user/ data equipment not ready.
ACKI (QUAL=1) - Intermediate acknowledgement; more signalling to follow.
ACKQ (QUAL=0) - All traffic channels in use. TSC has queued the call.
ACKQ (QUAL=1) - Conflicting call in progress (e.g. called unit engaged), or higher in
queue. TSC has queued the call.
ACKX (QUAL=0) - Invalid call; request rejected.
ACKX (QUAL=1) - System overload; request rejected.
ACKV (QUAL=0) - Called unit not in radio contact or call set-up abandoned.
ACKV (QUAL=1) - Conflicting call in progress or higher in queue (and call has not
been queued), or called user does not wish to receive this call.
ACKB (QUAL=0) - Called unit has accepted the call for call-back.
ACKT (QUAL=0) - Called party's calls have been diverted.
Acknowledgements sent to radio unit to indicate progress of Include call

(as requested by an RQS on a traffic channel):
ACK (QUAL=0) - Include request accepted; called party will be directed to the traffic
channel.
ACKI (QUAL=0) - Called party alerting but not yet ready.
ACKQ (QUAL=0) - All traffic channels in use on called site; more signalling to follow.
ACKV (QUAL=0) - Called unit not in radio contact or Include call abandoned.
ACKV (QUAL=1) - Conflicting call in progress (e.g. called party engaged), or called
user does not wish to receive this call.
Acknowledgements sent during set-up of standard data communication

(as requested by an RQD message):
These acknowledgements are defined in Sections 17.1.1.1.1, 17.1.1.1.2 and 17.1.1.1.4.

ACKQ (QUAL=0) - All data channels are busy. Wait for further signalling.
ACKQ (QUAL=1) - Called party is engaged (and calling party requires interactive
contact). Wait for further signalling.
ACKT(QUAL=0) - Called party's calls have been diverted.
ACKX (QUAL=0) - Invalid call e.g. TSC or called party does not support standard data
at least from this caller, or the radio unit is blacklisted, or called
address is unobtainable.
ACKX (QUAL=1) - System overload, or for INTER='1' the called party is engaged or
will not interact at this time and the TSC has not queued the call;
request rejected.
ACKV (QUAL=1) - Call abandoned because the called party is unable to receive a call
with the required facilities, e.g. the called radio unit does not
support HADT or interaction or cannot accept the requested PORT.

Acknowledgements to cancel/abort message RQX:
ACK (QUAL=1) - Acknowledgement of RQX.
Acknowledgements to call diversion request RQT:
ACK (QUAL=0) - Call diversion or cancellation has been accepted.

ACKV (QUAL=0) - Transaction abandoned.
Acknowledgements sent as response to emergency call request RQE:
ACKE (QUAL=0) - Acknowledgement, wait for further signalling.
Acknowledgements to registration request RQR:
ACK (QUAL=0) - Registration accepted.

ACKX (QUAL=0) - Invalid request; registration denied.
ACKX (QUAL=1) - System overload; registration failed.
Acknowledgements sent to radio unit to indicate progress of status transaction

(as requested by an RQQ message):
ACK (QUAL=0) - Transaction has been successfully completed, i.e. the called
destination has accepted the status information.
ACKQ (QUAL=0) - System is busy. Wait for further signalling.
ACKQ (QUAL=1) - Called unit engaged. Wait for further signalling.
ACKX (QUAL=0) - Invalid call; message rejected.
ACKX (QUAL=1) - System or called unit overload; message rejected.
ACKV (QUAL=0) - Called unit not in radio contact or transaction abandoned.
ACKV (QUAL=1) - Called unit engaged (and TSC will not hold the request), or called
unit does not wish to accept the information.
ACKT (QUAL=0) - Called unit's calls have been diverted.
Acknowledgements sent to radio unit to indicate progress of short data transaction

(as requested by an RQC message):
ACK (QUAL=0) -
Transaction has been successfully completed.
ACKI (QUAL=1) -
Intermediate acknowledgement; more signalling to follow.
ACKQ (QUAL=0) -
System is busy. Wait for further signalling.
ACKQ (QUAL=1) -
Called party engaged. Wait for further signalling.
ACKX (QUAL=0) -
Invalid call; message rejected.
ACKX (QUAL=1) -
System or called unit overload; message rejected.
ACKV (QUAL=0) -
Called unit not in radio contact or transaction abandoned.
ACKV (QUAL=1) -
Called party engaged (and TSC will not hold the request) or called
unit does not wish to accept the message.
ACKT (QUAL=0) - Called party's data calls have been diverted.

5.5.2.2 Acknowledgement messages sent by radio units
An acknowledgement may be sent by a radio unit in response to a TSC Ahoy or

HEAD message that demands a reply. An acknowledgement is also sent if a radio unit
receives an individually addressed Aloha message and has no suitable random access
message to send (see 7.4.1 and 8.3.2.1).

000 01
1 7 13 1 3 2 3 13 1 4 16
PFIX - Prefix of the transmitting unit.
IDENT1 - IDENT1 from the TSC's message, unless the acknowledgement is

sent in response to an individually addressed Aloha message, in
which case IDENT1 is set to TSCI.
CAT - '000'.
TYPE - '01'.
FUNC - ACK, ACKI, ACKX, ACKV or ACKB.
IDENT2 - IDENT2 from the TSC's message, unless the acknowledgement is

sent in response to an individually addressed Aloha message, in
which case IDENT2 is the transmitting unit's ident.
(N) - Reserved for future definition. Default value = '0000'.
Acknowledgements to AHY (i.e. general availability check):
i) From called unit (PFIX/IDENT1 from AHY):

ACK (QUAL=0) - General acknowledgement; unit/ user/ data equipment ready for
call.
ACKI (QUAL=0) - Unit alerting but user/ data equipment not ready.
ACKX (QUAL=0) - Call cannot be accepted (e.g. no data equipment, for a data call).
ACKV (QUAL=1) - User does not wish to receive this call
(e.g. his "Busy control" is in the busy state).
ACKB (QUAL=0) - Call accepted for call-back.
ACKB (QUAL=1) - Data codeword appended to AHY was not decodeable and unit
requires the message to be retransmitted.
ii) From requesting unit (PFIX/IDENT2 from AHY):

ACK (QUAL=0) - Unit is waiting for signalling for a call.
ACKX (QUAL=0) - Unit is not waiting for signalling for a call.
contd.

Acknowledgement from called unit to AHYX (cancel alert/waiting state):
ACK (QUAL=1) - Acknowledgement.
Acknowledgement from called unit to AHYP (called unit presence monitoring):
ACK (QUAL=1) - Acknowledgement
Acknowledgements from called unit to AHYQ (status message):
ACK (QUAL=0) - Unit has accepted the information in the AHYQ message.
ACKX (QUAL=0) - Unit is not equipped to accept the information.
ACKX (QUAL=1) - Unit cannot accept the information at this time (e.g. its queue is
full).
ACKV (QUAL=1) - Unit does not wish to accept status information from this calling
party.
ACKB (QUAL=1) - Data codeword appended to AHYQ was not decodeable and the
unit requires the message to be retransmitted.
Acknowledgements to AHYC (instruction to send short data):
i) From called unit (PFIX/IDENT1 from AHYC):

ACKX (QUAL=0) - Unit is not equipped to send the required data.
ii) From calling unit (PFIX/IDENT2 from AHYC):

ACKX (QUAL=0) - Unit is not waiting to send address information or short data
message.
Acknowledgements from called unit to HEAD message (short data):
ACK (QUAL=0) - Unit has accepted the information in the HEAD message.
ACKX (QUAL=0) - Unit is not equipped to accept the data message.
ACKX (QUAL=1) - Unit cannot accept the message at this time (e.g. its data store is
full).
ACKV (QUAL=1) - Unit does not wish to accept a data message from this calling party.
ACKB (QUAL=1) - Not all the appended data codewords were decodeable and the
Acknowledgement to an individually addressed Aloha message (if addressed radio

unit has no random access message to send):
ACKX (QUAL=0) - Acknowledgement, nothing to send.
Acknowledgement to an individually addressed AHYD message
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 QUAL RSVD MODEM P

000 01
1 7 13 1 3 2 3 13 1 3 1 16
RSVD - Reserved. Default value = all '0's

MODEM - as a response to AHYD, availability of modem for Standard Data
any other response, reserved for future definition.
Default value '0'
'0' - 1200 bits/sec FFSK only available

'1' - Both customised rate and 1200 bits/sec available
5.5.3 Type '10' Messages (Requests and Ahoys)
The Request messages sent by radio units and the Ahoy messages sent by the
TSC have the same Category and Type. For clarity, they are shown separately:
- Section 5.5.3.1 defines the Request codeword structures.

- Section 5.5.3.2 defines the Ahoy codeword structures.
5.5.3.1 Request Messages (Type '10')
These messages are transmitted to the TSC from a radio unit requesting a
function. Request messages on a control channel are sent using the random access
protocol (see 7.3).
The most usual basic structure is illustrated below but, for clarity of definition, the
message for each function is detailed separately in sections 5.5.3.1.1 to 5.5.3.1.8.
1 PFIX IDENT1 1 CAT TYPE FUNC PARAMETERS P

000 10
1 7 13 1 3 2 3 18 16
PFIX - Prefix of the requesting radio unit.
CAT - '000'.
TYPE - '10'.
FUNC - Specifies the function of the request:

'000' RQS Request Simple call
'001' Spare. Available for customisation
'010' RQX Request call cancel / abort transaction
'011' RQT Request call diversion
'100' RQE Request emergency call
'101' RQR Request to register
'110' RQQ Request status transaction
'111' RQC Request to send short data message.
PARAMETERS - See following pages.


5.5.3.1.1 Request "Simple" Call Message, RQS
This message is transmitted to the TSC on a control channel by a radio unit

requesting a non-emergency conversation or a channel over which any appropriate audio
signalling, even a non-standard modulation or format, can be sent. See section 9 for the
call procedures.
The RQS codeword contains all the information necessary to request a call to a
unit or group of units with the same prefix, to all units in the system, to a prearranged PSTN
destination or to a PABX extension that can be accommodated in the range 0-8191. In
addition, RQS may be used to request entry into the extended addressing mode for an
interprefix call, a general call to the PSTN or a call to a PABX extension with a "long"
number; in this case, after receiving the RQS message, the TSC demands the full called
party information using the AHYC message (see 5.5.3.2.8).
The RQS message may also be sent to the TSC by a radio unit on its allocated
traffic channel, to ask for another party to join the call. See section 11 for the Include call
procedures.
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 DT LEVEL EXT FLAG1 FLAG2 P
000 10 000
1 7 13 1 3 2 3 13 1 1 1 1 1 16

Ident - for a common-prefix call
IPFIXI - for an interprefix call
ALLI - for a system-wide call
number - for a short addressing call to a PABX extension
(EXT='1')
PABXI - for a call to a "long" PABX extension number
PSTNSIj - for a call to a prearranged PSTN destination
CAT - '000'.
TYPE - '10'.
FUNC - '000'.
IDENT2 - Ident of the requesting radio unit.
DT - RQS message on a control channel:

'0' if the caller is requesting speech communication.
'1' if the caller wishes to send non-prescribed data.
RQS message on a traffic channel:
This bit shall be set equal to bit D from the GTC message that
allocated the traffic channel.
contd.

LEVEL - RQS message on a control channel:
This bit specifies 2 levels of priority
(both non-emergency).
High priority is '0', non-priority call is '1'.
RQS message on a traffic channel:
This bit shall be set to '1'.
EXT - '0' if IDENT1 is not a short addressing PABX extension number.

'1' if IDENT1 is a short addressing PABX extension number.
FLAG1 - For a group call (common-prefix or interprefix):

'0' - enable called users to reply
'1' - disable called users from replying.
For a short addressing call to a PABX extension, FLAG1/FLAG2
indicates the appropriate PABX exchange.
For a general call to the PSTN:
'0' - number has up to 9 dialling digits
'1' - number has 10 to 31 dialling digits.
For all other types of call, FLAG1 is reserved for future definition.
Default value='0'.
FLAG2 - For a short addressing call to a PABX extension,

FLAG1/FLAG2 indicates the appropriate PABX exchange.
For all other types of call, FLAG2 is spare for customisation.
reserved for future definition. Default value='0'.

5.5.3.1.2 Request Codeword Spare for Customisation, Not defined
This message may be transmitted to the TSC on a control channel by a radio unit
which is requesting a customised service.

5.5.3.1.3 Call Cancel / Abort Transaction Request Message, RQX
This message is transmitted to the TSC on a control channel by a radio unit in order
to:
a. cancel a previous call request, while waiting for its requested call to be set up, or
b. abort a transaction e.g. a status transaction.
It may also be transmitted to the TSC on a traffic channel by a radio unit, in order to
cancel an Include call request, while waiting for signalling for its Include call.
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 RSVD P

000 10 010
1 7 13 1 3 2 3 13 5 16

PABXI - for a call to a PABX extension
PSTNGI - for a call to a general PSTN destination
TSCI - for an RQQ or RQC transaction with the TSC
DIVERTI - for aborting a general cancellation by a recipient
of diversions.
Note: IDENT1 is the same as IDENT1 from the request being

cancelled/aborted, except for a short addressing PABX call.
CAT - '000'.
TYPE - '10'.
FUNC - '010'.

5.5.3.1.4 Request Call Diversion Message, RQT
This message is transmitted to the TSC on a control channel by a radio unit to

request either that future calls addressed:
- to itself, or
- to another subscriber unit or group
be redirected to a specified alternative destination; the destination may be a radio or line
unit, a group, a PABX extension or a PSTN number.
This message is also used by a radio unit to request:
- cancellation of the diversion of its calls, or

- cancellation of the diversion of another party's calls, or
- cancellation of any existing diversions to it.
See section 12 for the diversion procedures.
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 SD DIV FLAG1 FLAG2 P

000 10 011
1 7 13 1 3 2 3 13 2 1 1 1 16
IDENT1 - For diversion requests:

party or gateway to which calls are to be redirected: ident,
IPFIXI, PSTNSIj, PSTNGI or PABXI (for any PABX
extension).
For "self" or "third-party" cancellation:
ident of the unit or group whose calls should be returned (or
IPFIXI for an interprefix address).
For general cancellation by a recipient of diversions: set to
DIVERTI.
SD - Specifies the types of calls to which the request to divert or

cancel divert applies:
'00' if both speech and data calls are to be
redirected.
'01' if only speech calls are to be redirected.
'10' if only data calls are to be redirected.
'11' reserved for future use.
For diversion purposes, "speech" calls are defined as calls
requested using RQS(DT=0), RQE(D=0), RQQ(STATUS='00000')
or RQQ(STATUS='11111'). "Data" calls are defined as calls
requested using RQS(DT=1), RQE(D=1), RQQ('00001'-'11110'),
RQC or RQD.
contd.

DIV - '0' for a request for call diversion.
'1' for a request for cancellation of call diversion.
FLAG1 - For IDENT1 = PSTNGI,

For IDENT1 / PSTNGI, FLAG1 is reserved; default value='0'.
FLAG2 - Specifies whether or not three addresses must be supplied:

For DIV='0', '0' for self-initiated diversion
'1' for third-party diversion.
For DIV='1', FLAG2 shall be set to '0'.

5.5.3.1.5 Request Emergency Call Message, RQE
This message is transmitted to the TSC by a radio unit requesting an emergency

call. The RQE codeword contains all the information necessary to request a call to a unit or
group of units with the same prefix, to all units in the system, to a prearranged PSTN
destination or to a PABX extension that can be accommodated in the range 0-8191. In
addition, RQE may be used to request entry into the extended addressing mode for an
interprefix call, a general call to the PSTN or a call to a PABX extension with a "long"
number. See section 10 for the emergency call procedures.
RQE may also be used to request a special mode of service previously arranged
with the system.
Usually emergency calls will take precedence over all other calls. Emergency calls
may be pre-emptive, that is, another call may be terminated prematurely to free a channel
for an emergency call.
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 D RSVD EXT FLAG1 FLAG2 P
000 10 100
1 7 13 1 3 2 3 13 1 1 1 1 1 16

(EXT='1')
Note: If EXT='0'/FLAG2='1', the meaning of IDENT1 may be redefined.
CAT - '000'.
TYPE - '10'.
FUNC - '100'.
D - '0' if the caller is requesting speech communication.

'1' if the caller is requesting data communication.
Note: If EXT='0'/FLAG2='1', the meaning of bit D may be redefined.
contd.

RSVD - Reserved for future definition. Default value='0'.

FLAG1 - For a group call (common-prefix or interprefix):

'0' - enable called users to reply
'1' - disable called users from replying.
For a short addressing call to a PABX extension,
Default value='0'.
Note: If EXT='0'/FLAG2='1', the meaning of FLAG1 may be

redefined.

For all other types of call (i.e. if EXT='0'):
'0' - caller is not requesting a special mode of service.
'1' - caller is requesting a special mode of service previously
arranged with the system. In this case, the meanings of
fields IDENT1, D and FLAG1 may be redefined. See
also section 10.

5.5.3.1.6 Request to Register Message, RQR
This message is transmitted to the TSC on a control channel by a radio unit

requesting to register. See section 8 for the registration procedures.
Registration may be required for the tracking of roamers, for wide-area systems with
multiple control channels and for polling systems.
1 PFIX IDENT1 1 CAT TYPE FUNC INFO RSVD P

000 10 101
1 7 13 1 3 2 3 15 3 16
CAT - '000'.
TYPE - '10'.
FUNC - '101'.
INFO - Available for customisation by systems, to convey additional

information to the TSC. Null value = all '0's.

5.5.3.1.7 Request Status Transaction, RQQ
This message is transmitted to the TSC on a control channel by a radio unit:
- to request that status information be relayed to the addressed line unit or radio
unit, or
- to send status information to the TSC.
The status field in an RQQ message consists of 5 bits, allowing 32 different status values.
Two of these values have been predefined (see below).
For a common-prefix status message, the RQQ message contains all the
information necessary for the transaction. For an interprefix status message, the RQQ
message is used to request entry into the extended addressing mode. See section 13 for
the status procedures.
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 STATUS P

000 10 110
1 7 13 1 3 2 3 13 5 16

Ident - for a common-prefix transaction
IPFIXI - for an interprefix transaction
TSCI - for a transaction with the TSC.
CAT - '000'.
TYPE - '10'.
FUNC - '110'.
STATUS - For a transaction with a line unit or radio unit:

'00000' requests that the addressed unit call back with
a speech call (no other status information
indicated).
'00001' to '11110' are user-defined status values.
'11111' cancels a previous speech call request (no
other status information indicated).
For a transaction with the TSC:

'00000' indicates "off-hook" or equivalent.
'00001' to '11110' are system-defined status values.
'11111' indicates "on-hook" or equivalent.

5.5.3.1.8 Request to Transmit Short Data Message, RQC
This message is sent by a radio unit to request permission to transmit a short data
message (comprising the HEAD address codeword and up to four data codewords). After
receiving the request, the TSC uses the AHYC message to instruct the requesting unit to
transmit the data message on the control channel. See section 14 for the short data
message procedures.
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 SLOTS EXT FLAG1 FLAG2 P
000 10 111
1 7 13 1 3 2 3 13 2 1 1 1 16

(EXT='1')
TSCI - for a transaction with the TSC.
CAT - '000'.
TYPE - '10'.
FUNC - '111'.
SLOTS - The number of timeslots required for the data message:

'00' reserved
'01' reserved
'10' two slots (address codeword + 1 or 2 data codewords)
'11' three slots (address codeword + 3 or 4 data codewords)


Default value='0'.

Default value='0'.

5.5.3.2 Ahoy Messages (Type '10')
These messages are transmitted by a TSC; they demand a response from an

addressed radio unit.
The basic structure is illustrated below but, for clarity of definition, the message for
each function is detailed separately in sections 5.5.3.2.1 to 5.5.3.2.8.
(Note that the request messages sent by radio units have the same Category and
Type as the Ahoy messages sent by the TSC.)
1 PFIX IDENT1 1 CAT TYPE FUNC PARAMETERS P

000 10
1 7 13 1 3 2 3 18 16
PFIX - Prefix.
CAT - '000'.
TYPE - '10'.
FUNC - Specifies the function of the Ahoy:

'000' AHY General availability check
'001' Spare Free for customisation
'010' AHYX Cancel alert/waiting state
'011' Reserved for future use
'101' AHYP Called Unit Presence Monitoring
'110' AHYQ Status message
'111' AHYC Short data invitation.

5.5.3.2.1 General Availability Check Message, AHY
This message is transmitted on a control channel by the TSC as follows.
a. It may be transmitted to a called radio unit to establish the availability of the called
unit/user prior to allocating a traffic channel for a call (see 9.1.1.5), or prior to
including a unit in an existing call (see 11.1.5).
b. It may be sent to check the availability of a called radio unit before the TSC
transmits a short data message (HEAD); see 14.1.6.
c. It may be sent to a requesting radio unit to check that it is still in radio contact and
to restart its waiting timer (see, for example, sections 8.2.1.3, 9.1.1.7 and 9.1.1.10).
AHY may also be sent by the TSC to a radio unit on a traffic channel, for example to
check that the unit has reached, or is still on, the channel (see 6.1.2.1 and 9.1.2.2), or to
restart the waiting timer of a radio unit which has requested an Include call (see 11.1.7).
One data codeword may be appended to the AHY address codeword, to convey
additional information, depending on the value of bit AD. (In this issue of the standard, this
facility is used only when the AHY is sent on a control channel to a called radio unit).
AHY demands an acknowledgement from the addressed unit:
i) For AD = '0' - On a control channel, the addressed unit responds in the slot
following the AHY.On a traffic channel, the unit times its response
from the end of the AHY address codeword.
ii) For AD = '1' - On a control channel, the addressed unit responds in the slot
following the data codeword (i.e. in the slot following the slot that
contains the data codeword). On a traffic channel, the unit times its
response from the end of the data codeword.
contd.

AHY address codeword:
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 D POINT CHECK E AD P

000 10 000
1 7 13 1 3 2 3 13 1 1 1 1 1 16
PFIX - Prefix of the radio unit.
a) For POINT='0' (i.e. availability check on called unit),

IDENT1 is the ident of the called radio unit.
b) For POINT='1' (i.e. availability check on calling unit),

IDENT1 is the called party or gateway as follows:
TSCI - for an RQQ or RQC transaction with the TSC
diversions.
For restarting the waiting timer of a radio unit that has

requested registration, IDENT1 = REGI.
CAT - '000'.
TYPE - '10'.
FUNC - '000'.

IDENT2 is the calling party or gateway as follows:
INCI - for an Include call availability check
SDMI - for a short data message availability check
DUMMYI - for a "no-call" test availability check
For all other types of call,
PABXI - for a call from a PABX extension
PSTNGI - for a call from the PSTN.
If IDENT2 = IPFIXI or INCI, the address of the calling unit may be

provided in an appended data codeword (see below).
b) For POINT='1' (i.e. availability check on calling unit),

IDENT2 is the ident of the calling radio unit.
contd.

D - If the calling party requested speech communication
(i.e. RQS(DT=0) or RQE(D=0)), then D='0'.
Otherwise, D='1'.
(For an AHY sent to restart the waiting timer of a radio unit

sending "off-hook" or "on-hook" signalling, D='1').
POINT - '0' demands an acknowledgement from the unit whose

individual address is PFIX/IDENT1.
'1' demands an acknowledgement from the unit whose
individual address is PFIX/IDENT2.
See sections 9.2.2.2, 9.2.2.3 and 9.2.3.2 for the appropriate
acknowledgement.
CHECK - AHY message on a control channel:

'0' indicates that the TSC is checking only that the unit is in
radio contact (and can accept this call).
'1' indicates that the TSC is also checking:
- for D='0', whether the unit's user is ready for a
speech call
- for D='1', whether the unit's data equipment
is ready.
b) For POINT='1' (i.e. availability check on calling unit),CHECK

is reserved for future definition. Default value='0'.
AHY message on a traffic channel:

CHECK is reserved for future definition. Default value='0'.
E - '0' if the calling party requested a non-emergency call or

transaction.
'1' if the calling party requested an emergency call.
(For an AHY sent to restart the waiting timer of a radio unit

requesting registration or an Include call, or sending "off-hook" or
"on-hook" signalling, E='0').
AD - '0' if there is no appended data codeword.

'1' if there is a data codeword appended to the AHY.
contd.

Data codeword following AHY address codeword:
For a (control channel) availability check on the called unit, if bit AD in the
AHY address codeword is set to '1', then a single data codeword with the following
structure is appended to the AHY codeword.
0 FORM PARAMETERS P
1 3 44 16
FORM - Defines the format of the PARAMETERS field (see below).

'000' - Value used to convey the address of the calling unit in an
interprefix or Include call.
'001' to '100' are reserved for future use.
'101' to '111' are spare for customisation.
PARAMETERS - See parameter formats below.
Parameter formats
PARAMETERS
FORM = '000' RSVD PFIX2 IDENT2
24 7 13
RSVD - Reserved for future use.

Default value = all '0's.
PFIX2 - Prefix of the calling unit.
IDENT2 - Ident of the calling unit.

5.5.3.2.2 This section is spare free for customisation.
5.5.3.2.3 Cancel Alert/Waiting State Message, AHYX
This message is transmitted on a control channel by the TSC, to inform a called

radio unit of cancellation of an incoming traffic channel call e.g. if the calling unit no longer
wants the call. It demands a response ACK(QUAL=1) in the next slot from the called unit
i.e. the unit whose individual address is PFIX/IDENT1 - see 9.2.2.4. (Note that this
message is used only for cancelled individual calls to radio units.)
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 POINT P

000 10 010
1 7 13 1 3 2 3 13 5 16
PFIX - Prefix of the called radio unit.
IDENT1 - Ident of the called radio unit.
CAT - '000'.
TYPE - '10'.
FUNC - '010'.

PSTNGI - for a call from the PSTN
INCI - for an Include call.

5.5.3.2.4 This section is reserved for future use.
5.5.3.2.5 This section is reserved for future use.
5.5.3.2.6 Called Unit Presence Monitoring Check Message, AHYP
This message is transmitted on a traffic channel by the TSC.
It may be transmitted to a called radio unit or group to establish if the unit is in radio
contact. A response is demanded if the PFIX/IDENT1 matches either -
a) the individual identity of the Radio Unit or

b) PFIX/IDENT matches the group address previously transmitted in the
GTC message which directed this Radio Unit to the traffic channel or
c) IDENT1=ALLI
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 RSVD P

000 10 101
1 7 13 1 3 2 3 13 5 16
PFIX - Unit or Group Prefix of the called radio unit.
IDENT1 - Called party:

Ident - Individual or Group Identity of the called radio
unit.
CAT - '000'.
TYPE - '10'.
FUNC - '101'.
IDENT2 - Calling party

Ident - TSCI

5.5.3.2.7 Status Ahoy Message, AHYQ
This message is transmitted on a control channel by a TSC to inform a called radio

unit of status information sent by a radio or line unit. For an interprefix status message,
IDENT2 in the AHYQ address codeword is set to IPFIXI and a data codeword is appended
containing the calling unit's address. AHYQ is also used to send a 5-bit status message to
a radio unit from the TSC.
AHYQ demands an response ACK, ACKX, ACKV or ACKB from the called unit (i.e.
the unit whose individual address is PFIX/IDENT1):
- in the slot following the AHYQ address codeword, for a common-prefix status
message (IDENT2 = ident) or a message from the TSC (IDENT2 = TSCI);
- in the slot following the appended data codeword, for an interprefix status
message (IDENT2 = IPFIXI).
See 13.2.1.5 and 13.2.3.1 for the Status Ahoy procedures.
AHYQ address codeword:
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 STATUS P

000 10 110
1 7 13 1 3 2 3 13 5 16
PFIX - Prefix of the called radio unit.
IDENT1 - Ident of the called radio unit.
CAT - '000'.
TYPE - '10'.
FUNC - '110'.
IDENT2 - Calling unit or gateway:

Ident - for a common-prefix transaction
IPFIXI - for an interprefix transaction
TSCI - for a message from the TSC.
If IDENT2 = IPFIXI, the address of the calling unit is provided in

an appended data codeword (see below).
STATUS - For a status message from a radio or line unit, this field contains
the status information sent by the calling unit:
'00000' requests a speech call
'00001' to '11110' are user-defined status values
'11111' cancels a previous speech call request.
For a status message from the TSC, the meaning of the STATUS
field is system-dependent.

contd.

Data codeword following AHYQ address codeword:
For an interprefix status transaction, IDENT2 in the AHYQ address codeword is set
to IPFIXI and a data codeword is appended containing the calling unit's address.
0 RSVD PFIX IDENT2 P
1 27 7 13 16
RSVD - Reserved for future use. Default value = all '0's.
PFIX2 - Prefix of the calling unit.
IDENT2 - Ident of the calling unit.

5.5.3.2.8 Short Data Invitation Message, AHYC
This message is used by the TSC to instruct a radio unit to send a short data
transmission (see sections 9.2.2.1, 11.3.1 and 15.2).
AHYC is used in two Modes:
- In Mode 1, AHYC instructs a calling radio unit to send addressing information (see
SAMIS, section 5.6.1.2.2) or RQC data (see HEAD, section 5.6.2), when a
preceding request message from the radio unit has indicated the requirement.
Mode 1 is distinguished by setting PFIX/IDENT2 to a radio unit's individual address.
- In Mode 2, AHYC demands that a radio unit transmits a data message of a

prescribed type (see section 15); for example, the TSC may demand the serial
number of a radio unit. It is an interrogation mode, not part of a call requested by
the radio unit. Mode 2 is distinguished by setting PFIX/IDENT1 to a radio unit's
individual address (with IDENT2 as a non-radio-unit ident).
The type of data to be transmitted by the radio unit is indicated by the DESC field
and the non-radio-unit ident; the meaning of DESC can be different for the two modes.
AHYC may be sent on either a control channel or a traffic channel.
1 PFIX IDENT1 1 CAT TYPE FUNC IDENT2 SLOTS DESC P

000 10 111
1 7 13 1 3 2 3 13 2 3 16
PFIX - Prefix of the radio unit.
IDENT1 - Called unit, gateway or special ident:
a. Mode 1 (instructing the unit with address PFIX/IDENT2 to send

data):
IPFIXI - for inviting extended addressing information for an
interprefix call
PSTNGI - for inviting dialled digits for a call to the PSTN
PABXI - for inviting address information for a call to a PABX
extension
DIVERTI - for inviting the blocked address for third-party call
diversion
SDMI - for inviting RQC data.
b. Mode 2 (interrogation): Ident of the radio unit.
CAT - '000'.
TYPE - '10'.
FUNC - '111'.
contd.

IDENT2 - Calling party:
a. Mode 1: Ident of the calling radio unit.
b. Mode 2 (instructing the unit with address PFIX/IDENT1 to send

data): Ident of the interrogator:
For DESC='000' (serial number check), IDENT2 = TSCI.
SLOTS - The number of slots reserved for the data message:
SLOTS No. of slots No. of codewords
'00' reserved
'01' 1 address codeword only
'10' 2 address codeword + 1 or 2 data codewords
'11' 3 address codeword + 3 or 4 data codewords
For Mode 1, SLOTS shall correspond to the request message from

the radio unit as follows:
IDENT1 in AHYC SLOTS
IPFIXI '01'
PSTNGI '01' for up to 9 digits, or
'10' for 10 to 31 digits
PABXI '01'
DIVERTI '01'
SDMI equal to SLOTS from the RQC
For Mode 2, SLOTS shall correspond to the data required from the
radio unit as follows:
DESC SLOTS
'000' '01'
contd.

DESC - Data message codeword descriptor. This field indicates the type of
data message with which the radio unit shall respond:
i) When the first codeword of the radio unit's data message is

required to be SAMIS, DESC is set to the value of the DESC field
to be used in the SAMIS as follows; (note that the meaning of the
SAMIS message may be different for Modes 1 and 2):
a. Mode 1:
'000' - for inviting extended addressing information for an

interprefix call, or the blocked address for third-party
diversion
'001' - for inviting dialled digits for a call to the PSTN
'010' - for inviting address information for a call to a PABX
extension
'011' - Reserved
'100 to 111' are spare
b. Mode 2:
'000' - for demanding the serial number of a radio unit.

'001 to 011' are reserved
'100 to 111' are spare
ii) When the first codeword of the radio unit's data message is
required to be HEAD (i.e. IDENT1=SDMI), DESC = '000'.
DESC = '001' to '011' are reserved.
DESC = '100' to '111' are spare

5.5.4 Miscellaneous Control Messages (Type '11')
These are various messages required for system control. The basic structure is
illustrated below, but the detailed structure for each message is defined separately on the
following pages.
1 PARAMS 1 CAT TYPE FUNC PARAMETERS P

000 11
1 20 1 3 2 3 18 16
PARAMS - Dependent on FUNC.

Where applicable, PARAMS is an address
(PFIX/IDENT1);otherwise bits 2-21 are used for other purposes.
See following pages.
CAT - '000'.
TYPE - '11'.
FUNC - Specifies the function of the message:

'000' MARK Control channel marker
'001' MAINT Call maintenance message
'010' CLEAR Clear down from allocated channel
'011' MOVE Move to specified control channel
'100' BCAST Broadcast message for system parameters

5.5.4.1 Control Channel Marker, MARK
This message may be transmitted on a control channel by a TSC. For example, it

may be sent as the first address codeword(s) on a newly designated control channel in
order to accelerate control channel acquisition by radio units (see 3.3.3.1). It does not
need an address PFIX/IDENT1, so bits 2-21 are reused.
The message fields A and B are chosen so that:
i) the parity check bits always form the control channel codeword synchronisation
sequence, SYNC (see section 3.2.1.1), and
ii) the number of bit transitions included between bits 33 and 49 is the maximum
achievable, taking into account condition i) above. The bit values of these fields will
depend on CHAN4 and the system identity code. An algorithm for generating these
fields is given in Appendix 4.
1 CHAN4 A SYS 1 CAT TYPE FUNC B P

000 11 000 1100010011010111
1 4 1 15 1 3 2 3 18 16
CHAN4 - Least significant four bits of the channel number of the control
channel on which the message is sent
A - See i) and ii) above and Appendix 4.
SYS - System identity code of the transmitting system.
CAT - '000'.
TYPE - '11'.
FUNC - '000'.
B - See i) and ii) above and Appendix 4.

These complete the codeword and also form the control channel
codeword synchronisation sequence.

5.5.4.2 Call Maintenance Message, MAINT
These messages are transmitted on an allocated traffic channel during a call.
A radio unit sends MAINT messages (OPER = '000', '001', '010', '011') during a call;
see 9.2.3. The TSC may send MAINT (OPER = '110') to clear down from the channel any
radio units that should not be there, and may send MAINT (OPER = '111') to disable radio
units from user transmission.
1 PFIX IDENT1 1 CAT TYPE FUNC CHAN OPER RSVD P

000 10 001
1 7 13 1 3 2 3 10 3 5 16
PFIX - Prefix.
IDENT1 - Transmitted by radio unit:

PFIX/IDENT1 is the unit's individual address if it was
individually addressed by the GTC message; otherwise
PFIX/IDENT1 is either its individual address or the group
address (PFIX/IDENT1) from the GTC, as specified by the
system - see 5.5.4.5c, 9.2.2.6 and 9.2.3.
Transmitted by TSC:
OPER = '110' PFIX/IDENT1 is the "call-labelling" address:
either address from the GTC message.
OPER = '111' Individual or group ident, or ALLI; see below.
CAT - '000'.
TYPE - '11'.
FUNC - '001'.
CHAN - Channel number of the channel on which the message is sent.
OPER - '000' Pressel On

'001' Pressel Off
'010' Periodic message within an item
'011' Disconnect message, end of channel use
'100' Spare for customisation (eg radio transmitter power control)
'110' Clear down radio units for which PFIX/IDENT1 is not a valid
call-labelling address
'111' Disable user transmission, as follows:
a) an individual radio unit, if PFIX/IDENT1 is an individual
address
b) called radio units in a group, if PFIX/IDENT1 is the
group address
c) all radio units on the channel, if IDENT1 is ALLI.
RSVD - Reserved for future use. Except for OPER = '100' when these
bits are available for synchronisation when reserved, default
value = '00000'.

5.5.4.3 Clear-Down Message, CLEAR
This message is transmitted by a TSC; it directs all radio units to clear down from a
traffic channel. It does not need an address PFIX/IDENT1, so bits 2-21 are reused.
1 CHAN CONT 1 CAT TYPE FUNC RSVD SPARE REVS P

000 11 010 101010101010
1 10 10 1 3 2 3 4 2 12 16
CHAN - Channel number of the traffic channel on which the message is

sent.
CONT - Channel number of the control channel to which radio units

should move (unless CONT = '0000000000', in which case the
channel movement is system-dependent).
CAT - '000'.
TYPE - '11'.
FUNC - '010'.
RSVD - Reserved for future use. Default value = '0000'.
SPARE - These bits are available for customisation.
REVS - Bit reversals, ending with a '0'.

5.5.4.4 Move to Control Channel, MOVE
This message is transmitted on a control channel by a TSC; it directs selected radio

units to a different control channel. (See sections 6.1.1 and 7.4.2).
1 PFIX IDENT1 1 CAT TYPE FUNC CONT (M) RSVD SPARE P

000 11 011
1 7 13 1 3 2 3 10 5 2 1 16
PFIX - Prefix.
IDENT1 - PFIX/IDENT1 specifies the radio units that should move. Only the
(M) least significant bits of the 20-bit address are used; the
remaining address bits may be set arbitrarily.
CAT - '000'.
TYPE - '11'.
FUNC - '011'.
CONT - Channel number of the control channel to which the addressed

radio units should move (unless CONT = '0000000000', in which
case the channel movement is system-dependent).
(M) - Address qualifier.
RSVD - Reserved for future use. Default value = '00'.
SPARE - This bit is available for customisation.

5.5.4.5 Broadcast Message, BCAST
This message is transmitted on a control channel by a TSC; it contains information

about system parameters for either this system or another system. It does not need an
address PFIX/IDENT1, so bits 2-21 are reused.
32 different types of information can be broadcast using BCAST messages, by

setting the SYSDEF and parameter fields appropriately. The parameter fields for each
SYSDEF are detailed on the following pages.
1 SYSDEF SYS 1 CAT TYPE FUNC PARAMETERS P

000 11 100
1 5 15 1 3 2 3 18 16
SYSDEF - Specifies which system parameters are being broadcast:
'00000' Announce control channel

'00001' Withdraw control channel
'00010' Specify call maintenance parameters
'00011' Specify registration parameters
'00100' Broadcast adjacent site control channel number
'00101' Vote now advice
'00110' )
: ) Reserved for future use
'01111' )
'10000' )
: ) Spare for customisation of services
'11111' )
SYS - System identity code of the system to which the broadcast

message refers.
CAT - '000'.
TYPE - '11'.
FUNC - '100'.
PARAMETERS - Parameter fields - see following pages.

Parameter fields in BCAST messages
a) Announce control channel (SYSDEF = '00000')
This message announces a channel that may be used for control by the named
system; radio units may then include it in their list of channels to scan.
1 SYSDEF SYS 1 CAT TYPE FUNC CHAN SPARE RSVD P

00000 000 11 100
1 5 15 1 3 2 3 10 2 6 16
CHAN - Channel number of the control channel being announced.
RSVD - Reserved for future definition. Default = all '0's.
b) Withdraw control channel (SYSDEF = '00001')
This message withdraws a channel that could previously be used for control by the
named system; radio units may then delete it from their list of channels to scan.
1 SYSDEF SYS 1 CAT TYPE FUNC CHAN SPARE RSVD P

00001 000 11 100
1 5 15 1 3 2 3 10 2 6 16
CHAN - Channel number of the control channel being withdrawn.
RSVD - Reserved for future definition. Default = all '0's.

c) Specify call maintenance parameters (SYSDEF = '00010')
This message specifies:
(i) whether this system requires radio units to send call maintenance messages
on traffic channels periodically within speech items; if so, it specifies the
maximum interval between the periodic messages;
(ii) whether this system requires radio units on traffic channels to send NPON
Pressel On messages at the start of speech items;
(iii) whether this system requires that a called unit in a group shall set
PFIX/IDENT1 in MAINT messages it sends to its individual address or to the
group address from the GTC message.
This message shall be sent only by the system to which the broadcast refers.
Default requirements are specified in section 9.2.2.6.
1 SYSDEF SYS 1 CAT TYPE FUNC PER IVAL PON ID RSVD SPARE P
00010 000 11 100
1 5 15 1 3 2 3 1 5 1 1 2 8 16
PER - '0' if radio units shall send call maintenance messages

periodically within speech items.
'1' if radio units shall not send call maintenance messages
periodically within speech items.
IVAL - If PER = 0, IVAL is the maximum interval (in seconds) between

the start of the item and the first periodic message,
and then between subsequent periodic messages.
If PER = 1, IVAL is reserved. Default value = '00000'.
PON - '0' if radio units shall send NPON Pressel On messages at the
start of speech items.
'1' if radio units shall not send any Pressel On messages at the
start of speech items.
ID - '0' if a called unit in a group shall set PFIX/IDENT1 in MAINT

messages it sends to the group address from the GTC
message.
'1' if a called unit in a group shall set PFIX/IDENT1 in MAINT
messages it sends to its individual address.

d) Specify registration parameters (SYSDEF = '00011')
This message is available for systems to specify parameters which radio units may
require for implementing registration.
1 SYSDEF SYS 1 CAT TYPE FUNC RSVD SPARE P

00011 000 11 100
1 5 15 1 3 2 3 4 14 16
e) Broadcast adjacent site control channel number (SYSDEF = '00100')
This message specifies a control channel currently being used for signalling on an
adjacent site. It gives the system identity code of the adjacent site and the channel number
of the specified control channel, and may also give the local serial number of the adjacent
site.
1 SYSDEF SYS 1 CAT TYPE FUNC CHAN SPARE RSVD ADJSITE P

00100 000 11 100
1 5 15 1 3 2 3 10 2 2 4 16
CHAN - Channel number of the control channel being specified.
ADJSITE - For ADJSITE = 0, radio units shall ignore this field.

For ADJSITE = 1 to 15, ADJSITE is the local serial number of the
adjacent site, as assigned by the transmitting site.
The use of site serial numbers is system-dependent. The

adjacent site number is useful for wide-area systems that provide
more than one control channel with the same system identity
code (SYS). (Note that the same call information should be sent
on control channels with the same SYS).

f) Vote now advice (SYSDEF = '00101')
This message gives an opportunity to idle radio units to use the next slot for signal
assessment of the control channel specified by the broadcast message. It gives the
system identity code of the adjacent site that is using the specified control channel and the
channel number of the control channel, and may also give the local serial number of the
adjacent site.
Note that the TSC should not use the next slot on the transmitting site to signal to
units that are likely to be assessing the signal strength received from the adjacent site.
1 SYSDEF SYS 1 CAT TYPE FUNC CHAN SPARE RSVD ADJSITE P

00101 000 11 100
1 5 15 1 3 2 3 10 2 2 4 16
CHAN - Channel number of the control channel being specified.
ADJSITE - For ADJSITE = 0, radio units shall ignore this field.

For ADJSITE = 1 to 15, ADJSITE is the local serial number of the
adjacent site, as assigned by the transmitting site.

5.6 Category '001' Messages
5.6.1 Single Address Messages (Type '0')
5.6.1.1 Outbound Single Address Messages, SAMO
The SAMO messages are for the transmission of short data messages from the
TSC to radio units. They are not used in this issue of the standard, but are reserved for
future definition.
1 PFIX IDENT1 1 CAT TYPE PARAMETERS P

001 0
1 7 13 1 3 1 22 16
PFIX - Prefix of the called radio unit or group.
IDENT1 - Ident of the called radio unit or group.
CAT - '001'.
TYPE - '0'.
PARAMETERS - Reserved for future definition.

5.6.1.2 Inbound Single Address Messages
5.6.1.2.1 Inbound Unsolicited Single Address Message, SAMIU
The SAMIU messages are for the transmission of random access short data
messages from radio units to the TSC. They are not used in this issue of the standard, but
are reserved for future definition.
1 PFIX IDENT1 1 CAT TYPE SOL PARAMETERS P

001 0 1
1 7 13 1 3 1 1 21 16
PFIX - Prefix of the originating unit.
IDENT1 - Ident of the originating unit.
CAT - '001'.
TYPE - '0'.
SOL - '1'.
PARAMETERS - Reserved for future definition.

5.6.1.2.2 Inbound Solicited Single Address Message, SAMIS
The SAMIS message is for the transmission of a short data message by a radio unit
in response to an AHYC message from the TSC. For example, it is used in the extended
addressing procedures, in third-party call diversion (section 12) and for data interrogation
(section 15). When appropriate, data codewords are appended to a SAMIS address
codeword.
The meaning of a SAMIS message is indicated by the DESC field. The AHYC
message which solicits a SAMIS is used in two different Modes (see 5.5.3.2.8); the
meaning of the SAMIS message is specified independently for the two Modes.
The SAMIS message may be transmitted on a control channel and on a traffic

channel.
SAMIS address codeword:
1 PARAMETERS1 1 CAT TYPE SOL DESC PARAMETERS2 P

001 0 0
1 20 1 3 1 1 3 18 16
PARAMETERS1 - See parameter formats below.
CAT - '001'.
TYPE - '0'.
SOL - '0'.
DESC - Codeword descriptor:
a. Mode 1: (AHYC with radio unit address as PFIX/IDENT2):
'000' - extended addressing information for an interprefix call,

or blocked address for third-party diversion
'001' - dialled digits for a call to the PSTN
'010' - address information for a call to a PABX extension
'011' is reserved
'100' to '111' are spare
b. Mode 2: (AHYC with radio unit address as PFIX/IDENT1):
'000' - radio unit's serial number.

'001' to '011' are reserved.
'100' to '111' are spare.
PARAMETERS2 - See parameter formats below.

contd.

Parameter formats for Mode 1
DESC PARAMETERS1 PARAMETERS2
'000' PFIX IDENT RSVD
7 13 18
'001' BCD1 BCD2 BCD3 BCD4 BCD5 L BCD6 BCD7 BCD8 BCD9
4 4 4 4 4 2 4 4 4 4
'010' BCD1 BCD2 BCD3 BCD4 BCD5 SP RSVD BCD6 BCD7 BCD8 BCD9
0
4 4 4 4 4 1 1 4 4 4 4
or
'000' RSVD EXCHANGE Number SP RSVD

1
5 2 13 1 17
PFIX - Prefix of unit or group.
IDENT - Ident of unit or group.
RSVD - Reserved. Default value = all '0's.
L - Number of data codewords appended to SAMIS:
'00' - no data codewords

'01' - one data codeword
'10' - two data codewords
'11' - reserved
BCDn - BCD groups representing the dialled digits, coded in accordance

with the table in Appendix 5. BCD digits are transmitted in the
dialled order (i.e. the leftmost digit in the above diagram is the
earliest in the dialling order; digits in any following codeword are
later in the dialling order).
EXCHANGE - Indicates the appropriate PABX exchange.
Number - PABX extension number.
SP - Indicates the format of the PABX address information:

'0' - BCD digits.
'1' - 13-bit extension number plus 2-bit exchange number.
(Note that SP='1' is used only in the call diversion procedures).
contd.

Data codewords appended to SAMIS, Mode 1:
For DESC = '001', in response to AHYC inviting PSTN digits, one or two data codewords
having the following format may be appended:
0 RSVD eleven BCD digits P
1 3 11 x 4 16
RSVD - Reserved. Default value = '000'.
BCD - Eleven BCD groups representing the dialled digits, coded in

accordance with the table in Appendix 5. BCD digits are
transmitted in the dialled order.
Parameter formats for Mode 2
DESC PARAMETERS1 PARAMETERS2
'000' 1st part of serial number 2nd part of serial number
20 18
The form of the serial number is system-dependent.
Data codewords appended to SAMIS, Mode 2:
Reserved for future definition.

5.6.2 Short Data Message Header, HEAD (Type '1')
This codeword is the address codeword in a short data message having up to four
data codewords and transmitted on a control channel. A radio unit may request to send a
short data message using the RQC message (see 5.5.3.1.8). The TSC instructs the radio
unit to send its short data message (using AHYC), and then forwards the message to the
called party (or the TSC may be the called destination). The TSC may also transmit short
data messages originated from a line unit, a PABX extension or the PSTN, or from the TSC
itself. See section 14 for the short data message procedures.
A HEAD message transmitted by the TSC to an individually addressed radio unit

demands a response from the unit, in the slot following the last data codeword of the
message.
HEAD address codeword:
1 PFIX1 IDENT1 1 CAT TYPE LEN PFIX2 IDENT2 P

001 1
1 7 13 1 3 1 2 7 13 16
PFIX1 - Prefix of the called party (if applicable).

Ident - for a common-prefix or interprefix call
TSCI - for a call to the TSC.
CAT - '001'.
TYPE - '1'.
LEN - Indicates the number of data codewords appended to the HEAD

address codeword:
'00' one data codeword
'01' two data codewords
'10' three data codewords
'11' four data codewords.
PFIX2 - Prefix of the calling party (if applicable).

Ident - for a common-prefix or interprefix call
TSCI - for a call from the TSC.

contd.

Data codeword(s) following HEAD address codeword:
0 RSA PARAMETERS P
1 1 46 16
RSA - Return Slot Access Flag.

When transmitted by the TSC on a control channel in the
second half of a slot preceding an access slot:
'0' - radio units are not permitted random access in the
following slot on the return control channel,
'1' - radio units are permitted random access in the
following slot on the return control channel. When
transmitted in the first or third data codeword
following HEAD, RSA = SPARE, default = '0'.
PARAMETERS - This field is available for free format data.

5.7 Codewords applicable to Standard Data Call Set-Up
5.7.1 Request Standard Data Communication RQD
This message is transmitted to the TSC on a control channel by a radio unit requesting to
send a data message using the Standard Data Protocol
1 PFIX IDENT1 1 CAT KIND PORT FAD IDENT2 INTER LEVEL HADT E MODEM P
010 1
1 7 13 1 3 1 3 1 13 1 1 1 1 1 16
PFIX - Prefix of the requesting radio unit
IDENT1 - Called party or gateway

ALLI - for a system wide call
NETSIj - for a call to to a pre-arranged data Network
destination
PSTNGI - for call to a general PSTN destination
DNI - for a call to a data network
CAT - '010'
KIND - '1'
PORT - Logical Port number of the called party
FAD - Flag to indicate greater than 9 dialled digits for PSTN call
'0' - 9 or fewer dialled digits
'1' - greater than 9 dialled digits
IDENT2 - Ident of the requesting radio unit
INTER - interactive contact required

'1' interactive contact with the called party is required
'0' interactive contact with the called party need not be provided
LEVEL - required priority

'1' non-priority
'0' high priority
HADT - '0' high accuracy data transfer not required

'1' high accuracy data transfer required
E - '0' if the calling party requested a non-emergency call or

transaction.
'1' if the calling party requested an emergency call.
contd

MODEM - requested data rate
'0' - standard rate 1200 b/s only

'1' - customised rate and standard rate are supported.
P - parity check bits

5.7.2 Availability Check for Standard Data AHYD
1 PFIX IDENT1 1 CAT KIND PORT RSVD IDENT2 INTER POINT HADT E AD P
010 1
1 7 13 1 3 1 3 1 13 1 1 1 1 1 16
PFIX - Prefix of the radio unit

Ident - for a common prefix call
NETSIj - for a call to a pre-arranged Data Network
PSTNSIj - for a call to a pre-arranged PSTN destination
PSTNGI - for a call to the PSTN
diversions
DNI - for a call to a Data Network
CAT - '010'
KIND - '1'
PORT - Logical port number
RSVD - Reserved. Default value = '0'
IDENT2 - Calling party or gateway as follows:

DUMMYI - for a "no-call" test availability check for standard
data
Ident - for a common prefix call
NETSIj - from a pre-arranged Data Network source
DNI - for a call from a Data Network
If IDENT2=IPFIXI, the address of the calling unit may be provided

in an appended data codeword
INTER - interactive contact required
'1' interactive contact with the called party is required

'0' interactive contact with the called party need not be provided.
POINT - '0' demands an acknowledgement from the called unit i.e the
unit whose individual address is PFIX/IDENT1
'1' demands an acknowledgement from the calling unit i.e the
unit whose individual address is PFIX/IDENT2
contd.

HADT - '0' high accuracy data transfer not required
'1' high accuracy data transfer required.
E - '0' if the calling party requested a non-emergency data call.

'1' if the calling party requested an emergency data call.
AD - '0' if there is no appended data codeword

'1' if there is a data codeword appended to the AHYD
Data codeword following AHYD address codeword
0 FORM PARAMETERS P
1 3 44 16
FORM - Defines the format of the PARAMETERS field (see below)
'000' - Value used to convey the address of the calling

unit in an interprefix call
'001' to '100' are reserved for future use

'101' to '111' are spare for customisation
PARAMETERS - see parameter formats below
Parameter formats
FORM='000' RSVD PFIX2 IDENT2
24 7 13
PFIX2 - Prefix of the calling unit
IDENT2 - Ident of the calling unit

5.7.3 Go To Transaction GTT
This message is transmitted from a TSC to radio units. It directs addressed radio
units to switch to a designated Standard Data channel in order to proceed with or continue
a data call.
The message is used :
a) On a control channel to send the RU to a data channel, and allocate its

TRANS. If TRANS='0000000000' then the TRANS will be allocated on the
data channel using an additional GTT.
b) On a data channel, with an IDENT set to a value in the range 1-8100, to

allocate an additional TRANS to the RU. In this case the channel number
MUST be set to the current data channel
c) On a data channel to move an individual RU to another data channel. This is

only possible if the radio unit already has one TRANS assigned to it. In this
case, a new TRANS will replace the current TRANS on the new channel and
the data call will continue.
d) On a data channel to move ALL radio unit's to another data channel. In this
case IDENT is set to ALLI and TRANS='0000000000'. All radio units moved
shall retain their already allocated TRANS. The O/R and the RATE fields
have no meaning and shall be set to '0'.
1 PFIX IDENT 1 CAT KIND CHAN O/R RATE TRANS P

010 0
1 7 13 1 3 1 10 1 1 10 16
PFIX - Prefix of radio unit
IDENT - Ident of the radio unit

Ident - any ident applicable to the radio unit.
CAT - '010'
KIND - '0'
CHAN - Designates the allocated channel number
O/R - Originator or Recipient

'0' - radio unit is the originator
'1' - radio unit is the recipient
RATE - Transmission rate to be used

'0' - standard rate 1200 b/s
'1' - customised rate
TRANS - Transaction number
P - parity bits

5.7.4 Standard Data Random access, Radio Unit General Information - DRUGI
This message shall be transmitted by a radio unit:
a) In response to DAHY
b) In random access when TDE or TDH has expired
c) When it wishes to resume data transfer after a pause
1 PFIX IDENT1 1 CAT KIND RNITEL TNITEL TRANS P

010 0
1 7 13 1 3 1 6 6 10 16
CAT - '010'
KIND - '0'
RNITEL - Maximum number of data codewords which could be received in

a New Fragment
TNITEL - The number of codewords proposed for the next dataitem

transmitted by the radio unit.

5.8 Codewords applicable to Standard Data Traffic Handling
5.8.1 Standard Data general purpose acknowlegement DACKD
This message may be transmitted by either a TSC or a radio unit as a general

purpose acknowledgement on the data channel.
1 PFIX IDENT 1 CAT KIND JOB RSVD REASON TRANS P

101 0 0101
1 7 13 1 3 1 4 5 3 10 16
PFIX - Prefix of the radio unit
IDEN - Ident of the radio unit
CAT - '101'
KIND - '0'
JOB - '0101'
REASON - Reason for this acknowledgement
'000' response for DAHYX

'001' as a response to a GO submessage if a pause in
user data transmission is required
'010'-'101' reserved
'110'-'111' spare
TRANS - Transaction number to be closed

5.8.2 Standard Data Codeword DACK containing Submessages
DAL, DALG or GO
This message consists of an DACK acknowlegement submessage combined with either:
Layout No1. A marker for a random access frame (codeword layout no.1) transmitted by
the TSC only, or
Layout No2. An invitation to transmit a 'GO' for a fragment (codeword layout no.2).
CODEWORD LAYOUT NUMBER 1
1 ATRANS RTRANS 1 CAT KIND JOB W/F P/N RSVD DN TNITEL ITENUM P
101 0 00XX
1 10 10 1 3 1 4 3 1 2 5 6 1 16
ATRANS - TRANS number for the submessage for which this is the
acknowledgment. If ATRANS='0000000000' then this
submessage has no significance.
RTRANS - Transaction number for random access See 17.2.1.2.1.
CAT - '101'
KIND - '0'
JOB - '0000' - DACK+DAL where DAL marks a general random

access frame
'0001' - DACK+DALG where DALG marks a frame for

requesting group message repeats
'0010' - DACK+DALN where DALN marks a frame for all

except group message repeats
WF - Delay parameter for repeat transmissions i.e number of frame

marks that must be counted before further random access of this
type may be made.
DN - the Aloha Number for the random access frame
P/N - Positive (PACK) or Negative (NACK) Acknowledgement.
(PACK) P/N = '1' indicates whole dataitem successfully received.

(NACK) P/N = '0' indicates whole dataitem to be repeated.
TNITEL - Proposed Transmitted next dataitem length in the same direction

as this message (ATRANS).

ITENUM - Dataitem number from the message to which this is the
acknowledement (ATRANS).
P - Parity check bits
------------------
CODEWORD LAYOUT NUMBER 2
1 ATRANS RTRANS 1 CAT KIND JOB RSVD P/N RSVD RNITEL TNITEL ITENUM P
101 0 0011
1 10 10 1 3 1 4 3 1 1 6 6 1 16
ATRANS - TRANS number for the submessage for which this is the
acknowledgment. If ATRANS='0000000000' then this
submessage has no significance.
RTRANS - Transaction number for the GO submessage
CAT - '101'
KIND - '0'
JOB - '0011' is for DACK+'GO'
P/N - Positive (PACK) or Negative (NACK) Acknowledgement.
(PACK) P/N = '1' indicates whole dataitem successfully received.

(NACK) P/N = '0' indicates whole dataitem to be repeated.
RNITEL - to indicate the maximum length of fragment that can be accepted

next (ATRANS).
TNITEL - Proposed Transmitted next dataitem length in the same direction

as this message (ATRANS).
ITENUM - Dataitem number from the message to which this is the

acknowledement (ATRANS).
P - Parity check bits

5.8.3 Standard Data Acknowledgement for expedited data DACKZ
Acknowledgement for expedited data, transmitted by both the TSC and Radio Unit.
1 ATRANS SPRE 1 CAT KIND JOB SX SPRE CAUSE P
1 10 10 1 3 1 4 3 7 8 16
ATRANS - Transaction number of the relevant TRANS for the

acknowledgement
SPRE - for SX = 000 to 101 - RSVD.

for SX = 110 to 111 - SPARE for customisation.
CAT - '101'
KIND - '0'
JOB - '0100'
SX - Type of expedited data.

'000' = RESET
'001' to '111' - RSVD. Default value = all '0's.
CAUSE - Reason for expedited data.

Default value = all '0's

5.8.4 Standard Data General ahoy DAHY
This message is transmitted by a TSC on a data channel to query availability

relating to a particular TRANS. It demands an immediate response.
1 TRANS RSVD 1 CAT KIND JOB RSVD SPARE P

101 0 1000
1 10 10 1 3 1 4 10 8 16
CAT - '101'
KIND - '0'
JOB - '1000'
SPARE - Spare for customisation

5.8.5 Standard Data ahoy containing expedited data DAHYZ
This message is transmitted by a TSC on a data channel to convey expedited data

relating to a particular individual TRANS. It demands an immediate response.
1 SPRE RSVD 1 CAT KIND JOB SX SPRE CAUSE P

101 0 1100
1 10 10 1 3 1 4 3 7 8 16

CAT - '101'
KIND - '0'
JOB - '1100'
SX - Type of expedited data
'000' - Reset the link to a known state
'001' to '101' - Reserved
'110' to '111' - Spare
CAUSE - Reason for expedited data.


5.8.6 Standard Data ahoy for closing a TRANS. DAHYX
This message is transmitted by a TSC to close one or all TRANS' of a particular

radio unit.
The message may also be used to clear ALL radio units from a data channel by
setting IDENT='ALLI'. In this case there will be no response and the fields PFIX, I/T, TOC,
and TRANS shall have no meaning and default to all '0's with RESP='0'.
1 PFIX IDENT 1 CAT KIND JOB I/T RESP SPRE TOC TRANS P
101 0 1110
1 7 13 1 3 1 4 1 1 3 3 10 16
PFIX - Prefix of radio unit

IDENT - Ident of the radio unit
Ident - any ident applicable to the radio unit.
ALLI - to clear ALL radio units from a data channel.
CAT - '101'
KIND - '0'
JOB - '1110'
I/T - IDENT/TRANS
I/T='0' Close all TRANS associated with that PFIX/IDENT.
See RESP. (TRANS shall be set to '0000000000')
I/T='1' Close the specified TRANS. See RESP.
RESP - '0' no response to the DAHYX is expected
- '1' An acknowledgement to the AHYX is required
SPRE - for TOC = 000 to 101 - RSVD. Default value = all '0's.
for TOC = 110 to 111 - SPARE for customisation.
TOC - Type Of Clear
'000' ALLCLR Data transfer abandoned and incomplete
'001' ALLDONE Data Transfer for this link has been completed
'010' - '101' Reserved
'110' - '111' Spare

5.8.7 Repeat last ACK - RLA
This message is transmitted on a data channel by a TSC or a radio unit to request a

repeat of the last acknowledgement.
1 TRANS RSVD 1 CAT KIND JOB RSVD SPARE P

101 0 1111
1 10 10 1 3 1 4 12 6 16
CAT - '101'
KIND - '0'
JOB - '1111'

5.8.8 Repeat group message DRQG
This codeword is transmitted by radio unit's using random access procedures to

request the retransmission of the relevant group message.
1 TRANS SPARE RSVD 1 CAT KIND JOB RSVD P

101 0 1010
1 10 7 3 1 3 1 4 18 16
CAT - '101'
KIND - '0'
JOB - '1010'

5.8.9 Request containing expedited data DRQZ
This codeword is transmitted by radio unit's using random access or 'GO'

procedures as a request for expedited data to be transmitted to the other correspondant.
1 TRANS SPRE 1 CAT KIND JOB SX SPRE CAUSE P

101 0 1100
1 10 10 1 3 1 4 3 7 8 16

CAT - '101'
KIND - '10'
JOB - '1100'
'000' Reset the link to a known state
'001' to '101 Reserved
'110' to '111' Spare
CAUSE - Reason for expedited data

5.8.10 Request to close a transaction DRQX
This codeword is transmitted by a radio unit to request the closure of one or all of its
TRANS
1 PFIX IDENT1 1 CAT KIND JOB SPRE TOC TRANS P

101 0 1110
1 7 13 1 3 1 4 5 3 10 16
CAT - '101'
KIND - '0'
JOB - '1110'
SPRE - for TOC = 000 to 101 - RSVD.

- for TOC = 110 to 111 - SPARE for customisation.
TRANS - Transaction number to be closed. If TRANS '0000000000' then

close all transactions for this radio unit.
TOC - Type Of Clear
'000' ALLCLR Data transfer abandoned and incomplete
'001' ALLDONE Data Transfer for this link has been completed
'010' - '101' Reserved
'110' - '111' Spare for customisation

5.8.11 Standard Data Selective Acknowledgement Header SACK
This message is transmitted by a TSC or radio unit on a Standard Data channel as a

selective acknowledgement to a user data message.
If there are more than 22 data codewords in the dataitem then a data codeword is
appended to the SACK address codeword.
1 ATRANS EFLAGS 1 CAT KIND TASK RSVD EFLAGS ONES AD ITEMNUM P

101 0 0
1 10 10 1 3 1 1 2 13 4 1 1 16
ATRANS - Transaction number of the original header to which this SACK

refers
EFLAGS - Error Flags. See next page for rules of use
CAT - '101'
KIND - '1'
TASK - '0'
ONES - the modulo 16 sum of all 23 EFLAG bits in this codeword
AD - '0' if there is no appended data codeword

'1' if there is an appended data codeword
ITENUM - itemnumber from the data header to which this acknowledgment

refers.
Data codeword following Standard Data Acknowledgement Header SACK
0 ONES EFLAGS RSVD P
1 4 40 3 16
EFLAGS - Error Flags (unused Error Flags='0')
ONES - the modulo 16 sum of all 40 EFLAG bits in this codeword
contd.

Rules governing the use of both EFLAG's fields
1. Every data codeword in a user dataitem shall have an EFLAG assigned to it. Each
assigned EFLAG shall be set to '1' if its corresponding codeword is required to be
repeated, otherwise it shall be set to '0'
2. Within the EFLAG fields the assigned EFLAGs shall be arranged contiguously in the
same order as their data codewords in the message to which they are assigned,
starting with the first EFLAG i.e bit 12 of the SACK address codeword.
3. The EFLAG bit following the last assigned EFLAG shall be used as a marker and set
to '1' and any remaining EFLAG bits shall be set to '0'.
4. The EFLAGs in the address codeword are assigned first and only if they are all
assigned is a data codeword appended. Thus if there are 23 assigned EFLAGs then
there will be only the marker and filler '0's in the appended data codeword.

5.8.12 Standard Data Address Codeword Dataitem SITH
This message is transmitted by a TSC or radio unit as an address codeword for a fragment.
Individual Dataitem
1 TRANS USER 1 CAT KIND TASK I/G MORE LASTBIT FRAGL TNITEL ITENUM P
DATA 101 1 1 0
1 10 10 1 3 1 1 1 1 6 6 6 1 16
Group Dataitem - TSC to Group
1 TRANS USER 1 CAT KIND TASK I/G MORE LASTBIT FRAGL RSVD ITENUM P
DATA 101 1 1 1
1 10 10 1 3 1 1 1 1 6 8 4 1 16
USERDATA - 10 bits of user data
CAT - '101'
KIND - '1'
TASK - '1'
I/G - '0' if this fragment is within an individual link

'1' if this fragment is within a group link
MORE - '0' if this dataitem is the last in the Tmessage.

'1' if more to follow
ITENUM - The number of the dataitem which includes the information in this
message.
LASTBIT - Indicates the bit number (see 17.0.2.5) of the last bit of user
information within the last data codeword holding user
information.
FRAGL - Number of data codewords appended
FRAGLG - fragment length (8 bit field for group) number of data codewords
appended
TNITEL - Proposed Transmitted next dataitem length

6. CHANNEL DISCIPLINE
This section defines basic discipline for the TSC and radio units on control, traffic and
Standard Data channels. In particular, timing constraints are specified covering:
- the transmission of standardised messages,

- change-over between transmitting and receiving, and
- channel switching.
The timings for the transmission of standardised messages on a traffic channel are
applicable to the procedures defined in this issue of the standard.
Some minimum rules are specified for radio unit control channel acquisition, but
additional specifications are likely to be necessary for a specific system implementation.
6.1 Channel Discipline for TSC
6.1.1 Control channel discipline for TSC
For as long as a suitable channel is available, the TSC shall provide at least one
control channel substantially continuously, conforming to the basic format defined in
section 3.3.3. The TSC may operate either a dedicated or a non-dedicated control
channel. If the TSC transmits from more than one base station site then a separate control
channel may be provided at each site, or a single control channel may be used with
simultaneous transmission at each site, or a single control channel may be shared by time
division.
Interruptions in the control channel signalling will occur when, for example, sites are
switched in a time-division scheme, or all channels are allocated for traffic in a system with
a non-dedicated control channel. Slot synchronisation need not be maintained across
interruptions.
If the TSC operates a non-dedicated control channel, it is recommended that the

TSC does not allocate the control channel for traffic during a random access frame (except
for emergency calls).
When the TSC commences transmission on a different control channel, it should

provide an adequate transmission period for the radio units to locate and identify the
control channel before it allocates traffic channels for calls; see 6.2.1.1 for control channel
acquisition by radio units.
It is recommended that broadcast messages (BCAST) are used to announce the

channel numbers of the channels that can be used for control by the TSC. The broadcast
messages may also be used to announce the control channels of other systems, for
example, to facilitate roaming. It is also recommended that, before a channel is taken out
of control service, another control channel shall be indicated if practicable (for example, by
sending an appropriate MOVE message).
The TSC shall be prepared to receive messages which conform to the format
specified in section 3 for radio unit transmissions on a control channel, and which conform
to the timings specified in section 6.2.1.3.

When the TSC sends a message in response to a random access message received
from a radio unit, the response may be sent in the slot following the random access
message or it may be delayed (see 7.2.4).
6.1.2 Traffic channel discipline for TSC
6.1.2.1 Monitoring
specified in section 3 for radio unit transmissions on a traffic channel.
The TSC shall monitor all traffic channels continuously while they are allocated for
traffic. If there is any reason to doubt whether communication is still taking place, the TSC
may query whether an individual radio unit is on the traffic channel by means of an AHY
message (see 9.1.2.2), and shall be prepared to receive an acknowledgement within the
timings given in 6.2.2.2.
6.1.2.2 Signal timing
The format for standardised messages transmitted on a traffic channel by the TSC is
defined in section 3. In particular, unless the TSC is already transmitting, each
transmission shall be introduced by at least 6 bit periods (5 ms) of link establishment time.
Note that the appropriate codeword synchronisation sequence (SYNT) shall be used.
When the TSC sends a response to an unsolicited message from a radio unit (e.g. a
response to an Include request), the codeword synchronisation sequence in the response
message shall not begin before the start of bit 52 nor later than the start of bit NT,
measured from the end of the last codeword transmitted by the radio unit. (For the
suggested value of NT, see Appendix 1).
6.1.3 Data channel discipline for TSC
6.1.3.1 Monitoring
specified in section 3 for radio unit transmissions on the data channel.
6.1.3.2 Signal Timing
The format for messages transmitted at the standard rate on a data channel by the
TSC is defined in section 3. In particular, unless the TSC is already transmitting, each
transmission shall be introduced by at least six bit periods (5 ms) of LET. Note that the
appropriate codeword synchronisation sequence, of SYNT, shall be used.

6.2 Channel Discipline for Radio Units
6.2.1 Control channel discipline for Radio Units
6.2.1.1 Control channel acquisition
When not assigned to a traffic channel (including immediately after switch-on), the
radio unit shall attempt to find a control channel. The search for a control channel may be
performed by a general hunt through all likely channels or by reference to memory within
the radio unit; the search strategy is likely to be system-dependent and is not included in
this standard. However, when a radio unit leaves an allocated traffic channel, it shall
commence its search on the control channel on which it was last active, unless it has been
directed to a different control channel by a CLEAR message.
The radio unit shall not make any transmissions on a control channel unless it is
active on that channel. It shall not become active until it has received an appropriate
codeword containing an appropriate system identity code; the codewords / system identity
codes which shall be considered appropriate are system-dependent.
If a radio unit is hunting over a number of channels, it should leave a candidate

channel as soon as it becomes clear that it is unlikely to become active on the channel. In
some systems it may be necessary to specify a maximum time between channel changes
for channels on which no control channel codeword synchronisation sequence is detected.
6.2.1.2 Retaining a control channel
If, while a radio unit is active on a control channel, a time TS elapses during which no
system identity code is decoded, then the unit shall cease to be active on that channel and
shall return to the control channel acquisition procedures. (For the suggested value of TS,
see Appendix 1). Some systems may impose additional rules for returning to the control
channel acquisition procedures.
If the radio unit receives an appropriate codeword containing an inapplicable system

identity code (system-dependent), or receives a CHAN4 field that does not match the least
significant four bits of the number of the channel to which the unit is tuned, then the unit
shall not transmit or act on any other received information until either:
- it has received a correct value of system identity code or CHAN4, respectively, on

that channel (whether or not a channel hunt has been made in the interim), or
- it has become active on a different control channel.
(Note that the codewords / system identity codes which cause a radio unit to temporarily
suspend activity may be different from those which enabled the radio unit to become
active).

The radio unit shall be capable of satisfactory operation when there are interruptions
of duration less than TS in the signalling (slot timing may not be maintained across
interruptions), and when CCSCs are displaced by data codewords in up to two consecutive
timeslots.
The radio unit shall not give to its user any information which is not pertinent to that
radio unit.
The radio unit shall not transmit on the return control channel at any time unless
permitted by the requirements of this standard. All transmissions shall conform to the
formats specified in section 3 and the timing requirements specified below. (If, under any
circumstances, the radio unit's timing is not sufficiently accurate then it shall refrain from
transmitting.)
For the transmission of a random access message, the radio unit shall choose a
timeslot for transmission in accordance with the requirements of the random access
protocol defined in section 7. The radio unit shall derive the timing of slots from the frame
marker message or from any other message transmitted by the TSC within the same frame.
For a radio unit response to a message received from the TSC, the radio unit shall
commence transmission of its message in the timeslot following the end of the TSC
message.
The start of slots on the return control channel shall be deemed to be coincident with
the start of the control channel system codewords on the forward channel, and timings are
specified in bit periods relative to this point in time. (Note, however, that slot delineation is
maintained even when a CCSC is displaced by a data codeword; see 3.3.) Figure 6-1
illustrates the timing for a single codeword message; the start of each slot is designated
time T0.
The radio unit shall not commence r.f. transmission before the start of bit 21 (time T2
in Figure 6-1), nor shall it reach 90% of its maximum power later than the start of bit 37
(time T4). The radio unit shall provide a link establishment time of at least 6 bit periods (5
ms). At the conclusion of the link establishment time it shall transmit a 16-bit preamble; the
16-bit preamble shall not begin before the start of bit 30 (time T3), nor later than the start of
bit 43 (time T5). Following the preamble, the radio unit shall transmit the control channel
codeword synchronisation sequence, an address codeword, any data codewords and one
"hang-over" bit of either '0' or '1'. It shall then cease transmission so that power is reduced
by at least 60 dB by the start of the next occurring bit 15 of a slot (time T1).
The radio unit shall then retune to the forward channel in time to be capable of
decoding address codewords as follows:
- For a radio unit transmission with no data codewords, the radio unit shall be capable
of decoding an address codeword in the first forward channel slot following the start
of the radio unit transmission.

- For a radio unit transmission with one or two data codewords, the radio unit shall be
capable of decoding an address codeword in the second forward channel slot
following the start of the radio unit transmission.
- For a radio unit transmission with three or four data codewords, the radio unit shall
be capable of decoding an address codeword in the third forward channel slot
following the start of the radio unit transmission.
If a radio unit receives a command to change channel (MOVE, GTC; see 7.4.2 and
9.2.2.5), it shall be capable of receiving on the new channel within 35 ms after the end of
the TSC message, unless the unit is a called unit in an interprefix call, in which case it may
delay the channel change by one slot and shall be capable of receiving on the new channel
within 142 ms after the end of the TSC message (see 9.2.2.5).
6.2.2 Traffic channel discipline for Radio Units
6.2.2.1 Monitoring
Whilst receiving on the forward traffic channel, the radio unit shall monitor the
channel continuously for messages from the TSC and shall take appropriate action; see
section 3 for the TSC signalling formats and sections 9.2.3.2, 9.2.3.3, 9.2.3.4, 9.2.3.7,
9.2.3.8, 11.3.1 and 15.2 for procedures. If the radio unit is required to transmit a response
to a message received from the TSC, its response shall conform to the timings specified in
section 6.2.2.2.
If a radio unit receives a command to change channel (see 9.2.3.4 and 9.2.3.8), it
shall be capable of receiving on the new channel within 35 ms after the end of the TSC
message.
The radio unit shall not give to its user any information which is not pertinent to that
radio unit.
The format for standardised messages transmitted on a traffic channel by the radio
unit is defined in section 3. In particular, unless the unit is already transmitting, each
transmission shall be introduced by at least 12 bit periods (10 ms) of link establishment
time. If the radio unit sends unsolicited messages (e.g. an Include request, a Pressel On
message or Disconnect messages), the link establishment time shall not exceed 24 bit
periods (20 ms). The preamble duration shall be 16 bits, and messages shall commence
with the traffic channel codeword synchronisation sequence. After the final ("hang-over")
bit of a standardised transmission, unless the radio unit is required to continue transmitting
for user communication, it shall cease transmission so that power is reduced by at least 60
dB within 6 bit periods (5 ms).
The transmission of standardised messages on a traffic channel shall conform to the

timings specified in sections 6.2.2.2.1 and 6.2.2.2.2.

6.2.2.2.1 Radio unit response
When the radio unit sends a response (e.g. an acknowledgement to an Ahoy

message from the TSC), its transmission shall conform to the following timings, which are
measured in bit periods, numbered from the end of the last codeword in the received
message.
The radio unit shall not commence r.f. transmission before the start of bit 21, nor
shall it reach 90% of its maximum power later than the start of bit 37; the 16-bit preamble
shall not begin before the start of bit 36 nor later than the start of bit 49; after sending the
"hang-over" bit and reducing power, the radio unit shall retune to the forward channel in
time to be capable of decoding another message whose codeword synchronisation
sequence may begin at the start of bit 183 + (64 x number of data codewords transmitted
by the radio unit).
6.2.2.2.2 Unsolicited transmission that requires a response
When a radio unit sends an unsolicited standardised message that requires a

response (e.g. an Include request), it shall conform to the following timings, which are
measured in bit periods, numbered from the end of the last codeword of its transmission.
After transmitting the unsolicited message, the radio unit shall retune to the forward
traffic channel in time to be capable of decoding a message which may begin (i.e. first bit of
codeword synchronisation sequence) at the start of bit 52.
If the radio unit has not received a codeword synchronisation sequence by the start
of bit NT+16, it shall either abandon its unsolicited access attempt or make another
unsolicited transmission, timing the next message to begin (i.e. first bit of codeword
synchronisation sequence) no earlier than the start of bit NT+144.
If, while waiting to transmit an unsolicited standardised message, the radio unit
receives a codeword synchronisation sequence SYNT, it shall wait to determine whether
there is a message relevant to it before making its transmission.
6.2.3 Data channel discipline for radio units
6.2.3.1 Monitoring
Whilst receiving on the forward channel, the radio unit shall monitor the channel to take
appropriate actions for all relevant received messages.
If a radio unit receives a command to change data channel (see 17.2.6.2), it shall be
capable of receiving on the new channel within 35 ms of the end of the TSC message.
6.2.3.2 Signal Timing
At the standard transmission rate, when the radio unit transmits a message the timing shall
conform to 6.2.1.3 (but using SYNT instead of SYNC).
Details of transmission timing at a customised rate must be specified elsewhere.

TSC System Codeword Address Codeword System Codeword Address
transmission Codeword
SYS CCS PRE SYNC SYS CCS PRE SYNC
limits on RU
Tx power up
bit
periods ms
earliest RU
message PRE SYNC Address Codeword T0 0 0
T1 14 11.66
min LET T2 20 16.66
T3 29 24.16
latest RU T4 36 30
message PRE SYNC Address Codeword T5 42 35
"hang over" bit
Figure 6.1
Control Channel timing

single codeword RU message
T1 T2 T3 T4 T5 T0 T1
T0
0 32 64 96 128 32 64 96
Time (bit periods relative to start of slot)

7. RANDOM ACCESS PROTOCOL
This section defines the random access protocol, which is based on slotted Aloha
with a superimposed framing structure that can be used to:
- control clashing of messages from different radio units,

- minimise access delays,
- ensure stability, and
- maintain peak throughput under heavy traffic loads.
The slotting structure of the control channel and timing constraints for the
transmission of messages are defined in sections 3 and 6.
7.1 The Principle

The basic principle of the access protocol is described with reference to the example
below, which illustrates signalling on a control channel.
The TSC transmits a synchronisation message (indicated by ALH in the example) to

establish slot timing and to invite radio units to send random access messages. The ALH
message contains a parameter (N) which indicates the number of following timeslots,
constituting a frame, that are available for access. If a frame is already in progress when a
call is initiated, the radio unit may send its random access message in the next immediate
slot. Otherwise the unit waits for a frame to be started and then chooses a random slot
from the frame for its message. A unit wishing to send a repeat transmission after an
unsuccessful message (corrupted by fading or clashing) must wait for a new frame before
choosing another slot.
The TSC can monitor activity on the control channel and can optimise the system
performance by varying the framelength to prevent excessive clashing and to minimise the
access delays. System designers should choose a control algorithm appropriate to the
type of system.
1 slot
<------>
TSC to ALH ALH

Radio Units (4) (3)
Radio Units
to TSC
\______________________/ \________________/
frame frame
Example Two random access frames, each marked by an ALH message.

(Random access frames can be marked by Aloha, Acknowledgement and Go
To Channel messages.)
Contiguous frames are shown in the example; frames may overlap. Frames
need not be contiguous.

7.2 TSC Random Access Facilities
7.2.1 Marking random access frames
The TSC shall designate sections of a return control channel as random access
frames, each containing a whole number of timeslots. Aloha messages (see 5.5.1) sent on
the forward control channel contain an Aloha number, and can be used to mark random
access frames. The Acknowledgements and Go To Channel message also contain an
Aloha number and may substitute for an Aloha message. For example, ACK(4)
acknowledges a message from a radio unit and also marks a four-slot frame.
The zero Aloha number (N=0) is a special value indicating "this is not the beginning
of a frame". Thus, for example, ACK(0) can be sent within a frame to acknowledge a
message.
All other Aloha numbers mark the beginning of a frame.
Aloha and Acknowledgement messages contain a four-bit Aloha number and the Go
To Channel message contains a two-bit Aloha number. The Aloha number is coded, so
that longer frames can be achieved than a pure binary representation would permit; the
explicit numbers of slots in a frame indicated by the four- and two-bit Aloha numbers are
given in Table 7-1 (see 7.3.3). If the required framelength is too long to be designated by a
GTC message then an Aloha message or Acknowledgement must be used.
7.2.2 Subdividing the radio unit population
The TSC may divide the radio unit population into subsets, where each subset can
be permitted random access in turn. The division is performed by using the address
qualifier (M) in Aloha messages. This parameter instructs a radio unit to compare the M
least significant bits of its individual address (prefix/ident) with the M least significant bits of
the address (PFIX/IDENT1) from the Aloha message when choosing a slot. the unit is
allowed to transmit non-emergency random access messages only if the M bits match (see
7.3.1) when the slot is chosen. The subdivision is applied to subsequent frames marked by
non-Aloha messages, until changed by the next Aloha message. (However, note that radio
units which have recently acquired the control channel or have missed Aloha messages
may be unaware of the subdivision and that the latest Aloha message received by the unit
is applied by the unit when chosing a slot.)
In this way, the radio unit population is effectively divided into 2M subsets:
- If M = 0 then no address bits are compared, so there is no subdivision. (Under

normal traffic loading, this will usually be the case.)
- If M = 1 then only units whose least significant address bit matches the Aloha
address may send non-emergency random access messages. Thus the radio unit
population has been divided into two subsets.
- This process continues up to M = 19.
- If M = 20 then all twenty bits of the address must be compared, and this indicates
that the Aloha message is applicable to only one unit or a specified group of units.

Note that M = 20 is a special case in which the radio unit compares the Aloha
address with each of its designated addresses, not just its individual address; in this
way a group of units may be invited to send random access messages. Note also
that an Aloha message with M = 20 and the Aloha address set to an individual
address demands a response from that unit, rather than just inviting a random
access message (see 7.4.1). If the TSC sends an individually addressed Aloha
message, it shall set the Aloha number (N) to 1.
7.2.3 Inviting specific types of random access message
The TSC may limit random access to particular types of message by means of
specific Aloha messages: ALH, ALHS, ALHD, ALHE, ALHR, ALHX, ALHF (see 5.5.1 and
7.3.2); for example, ALHR invites registration or emergency requests only. The limitation is
applied to subsequent frames until changed by a different Aloha message. (However, note
that radio units which have recently acquired the control channel will assume an Aloha
function of ALHX. While those that have missed Aloha messages may be unaware of the
current function and will apply the limitations of the last received Aloha function. Once a
slot is chosen the radio unit applies that Aloha function throughout the frame for the
purpose of random access.)
7.2.4 TSC responses
After receiving a random access message, the TSC shall send a response; valid
responses are specified in the sections detailing the call procedures. The response may be
sent in the slot following the random access message or it may be delayed. The TSC shall
specify, using the WT field in the Aloha messages, the time (in slots) a radio unit must wait
before deciding to retransmit and choosing another slot from a new frame (see Table 7-2 in
section 7.3.7).
7.2.5 Withdrawing slots from frames
During a frame, the TSC may transmit messages that demand a response from a
specified radio unit; the response is sent in the slot(s) following the last codeword of the
TSC's message.
The TSC's message inhibits random access in the first following return slot (see
7.3.6), and so reserves that slot for the response. For a multi-codeword response, the TSC
shall take appropriate action to reserve the subsequent return slot(s) if they are still within
the frame (e.g. by sending the AHY message with both idents set to DUMMYI). Note that:
a. All TSC address codewords that do not contain an Aloha number,

except AHY(AD=1), AHYQ(IDENT2=IPFIXI), MARK, MOVE, BCAST and HEAD,
inhibit random access in the following slot.
b. An Aloha message with M = 20 inhibits access by radio units that are not explicitly
addressed.
c. All data codewords transmitted by the TSC in the second half of a slot preceding a
designated random access slot contain a Return Slot Access flag RSA (bit number
2), which shall be set to indicate whether the following slot is reserved for a
response; for example, see section 5.6.2. Note that, for TSC messages containing
an odd number of data codewords (e.g. AHY(AD=1) and AHYQ(IDENT2=IPFIXI)), a

"filler" data codeword is appended to the message (see 3.3.3.2); if the message
demands a response from a radio unit, the RSA flag in the filler codeword shall be
set to '0', to inhibit random access.

7.3 Radio Unit Random Access Protocol
These procedures shall be obeyed by all radio units that are required to attempt
random access.
7.3.1 Checking subsets of the radio unit population
A radio unit shall note the population subdivision contained in each Aloha message
that it receives. When attempting random access the radio unit shall check if the
population subdivision is applicable to it. This is done using the 5-bit address qualifier (M)
and the address (PFIX/IDENT1) from the Aloha message. For M = 0 to 19, the message is
applicable to the unit if the M least significant bits of the Aloha address match the M least
significant bits of its individual address (prefix/ident). For M = 20, the message is
applicable to the unit if the Aloha address matches any of its designated addresses for this
system (including its group addresses).
The unit shall not choose a slot for random access in the frame designated by the
Aloha message, or frames designated by subsequent Acknowledgement or Go To Channel
messages, unless:
the Aloha message is applicable to it, for non-emergency messages,

or the Aloha message is applicable to it or M < 20, for emergency requests (ie RQE or
RQD (E = 1).
Note that slots are chosen either immediately for the first try option (see 7.3.4) or on receipt
of a frame marker when the unit needs to make a random access attempt (see 7.3.5).
When a radio unit becomes active on a control channel, including when returning
from a traffic channel, it shall either assume that the population is not subdivided (i.e. that
the last Aloha message was applicable to all radio units) or wait for an Aloha message
before attempting random access.
7.3.2 Checking the Aloha function
A radio unit shall note the function (FUNC) from each Aloha message it receives.
The requests invited by each Aloha function are as follows:
ALH Invites RQS, RQD(E=0), RQD(E=1), RQX, RQT, RQE, RQR, RQQ, RQC
ALHS Invites RQS, RQX, RQT, RQE, RQR, RQQ, RQC
ALHD Invites RQD(E=0), RQD(E=1), RQX, RQT, RQE, RQR, RQQ, RQC
ALHE Invites RQD(E=1), RQE
ALHR Invites RQD(E=1), RQE, RQR
ALHX Invites RQS, RQD(E=0), RQD(E=1), RQX, RQT, RQE, RQQ, RQC
ALHF Fall-back mode; messages invited only from radio units which know the fall-
back method used by this system.
(The rules defining the Aloha functions appropriate to customised random access
messages are system-dependent.)
The unit is not required to recognise the meaning of all these functions. However, it
shall not choose a slot for random access message in the frame designated by the Aloha
message, or frames designated by subsequent Acknowledgement or Go To Channel
messages, unless it recognised the Aloha function and its random access message is of a
type invited by the Aloha message.

When a radio unit becomes active on a control channel, including when returning
from a traffic channel, it shall assume an Aloha function of ALHX.
7.3.3 Frames defined by Aloha numbers
A radio unit shall use Table 7-1 to derive the explicit number of slots in a frame
indicated by the four-bit Aloha number within the Aloha and Acknowledgement messages
and the two-bit Aloha number within the Go To Channel message. (The zero Aloha
number indicates that the message does not mark a frame.)
Four-bit Aloha number:
Aloha Number Framelength Aloha Number Framelength
0 Not a frame marker 8 8

1 1 9 9
2 2 10 10
3 3 11 12
4 4 12 15
5 5 13 19
6 6 14 25
7 7 15 32
Two-bit Aloha number:
Aloha Number Framelength
0 Not a frame marker

1 1
2 3
3 6
Table 7-1 Number of slots in a frame indicated by Aloha numbers
The radio unit shall monitor the forward control channel and shall note which sections
of the return control channel are designated as random access frames (using the framing
Aloha numbers contained in Aloha, Acknowledgement and Go To Channel messages).
The first access slot in a frame starts at the end of the forward control channel codeword
containing the framing Aloha number and respective coincidence is maintained for
subsequent slots.
7.3.4 First try option
When a radio unit is required to transmit a new message, it is permitted to transmit in

the next immediate slot, provided that:
a. the slot is within a frame and the most recently received Aloha message
does not inhibit access.
(see 7.3.1, 7.3.2, 7.3.3),
and b. the slot is not withdrawn (see 7.3.6).

However, if it does not wish to use this option or if the slot is not within a suitable frame or if
the slot is withdrawn, then the unit shall choose a slot from a new frame (see 7.3.5).
7.3.5 Choosing a slot from a new frame
A radio unit that requires to select a slot from a new frame shall wait for a message
marking a frame available for it to use (see 7.3.1 and 7.3.2); it shall then choose a slot
randomly from the specified framelength, using a uniform distribution. The most recently
received Aloha message parameters are enforced at the moment of slot choice. The unit
shall transmit its message in the chosen slot, provided that the slot is not withdrawn (see
7.3.6); for access timing, see 6.2.1.3.
A radio unit shall not choose more than one slot from a frame. Therefore, if it has to
repeat the selection of a slot (either because a chosen slot was withdrawn or to make a
repeat transmission), it shall count to the last slot of the previous frame before using
another Aloha number. For example, if the last selection was from a frame with 8 slots,
designated by an ALH message, the unit shall not use frame marker messages received in
the 7 slots after the ALH message to choose its next slot. (Counting slots is required to
allow for multi-site systems with time division of a single control channel, in which radio
units may receive messages from several sites and frames designated by different sites
may overlap in time.)
7.3.6 Check for withdrawn slot
Before transmitting its random access message in a chosen slot, a radio unit shall check
whether the slot is still available for random access by attempting to decode the second
codeword on the forward channel in the slot immediately preceding the chosen slot. If any
of the following is received then random access is permitted:
a. Any address codeword containing an Aloha number, except an Aloha message with
M = 20 and the Aloha address (PFIX/IDENT1) not applicable to the unit (see 7.3.1).
b. The following address codewords:
- AHY with AD = 1 (unless the AHY is addressed to the unit)

- AHYQ with IDENT2 = IPFIXI (unless the AHYQ is addressed to the unit)
- MARK
- a MOVE message not applicable to the unit (see 7.4.2)
- BCAST
- HEAD (unless the HEAD is addressed to the unit).
c. A data codeword with the Return Slot Access flag RSA (bit number 2) set to '1',
(unless the codeword is part of a message addressed to the unit).
d. If permitted by the type of system, a codeword that is not decodeable (or no signal
is received).
Otherwise the unit shall refrain from transmitting and shall choose again from a new frame.
(Future enhancements of the standard protocol, and customised messages, may

result in additional messages that permit access for those radio units which can recognise
these additional messages.)

7.3.7 Noting the response delay
A radio unit shall note the delay parameter WT from each Aloha message it receives
and shall use Table 7-2 to derive from it the number of slots, WAIT, by which the TSC's
response to a random access message may be delayed. (WAIT = 0 means that the
response should be received in the slot following the random access message.) At the
start of a session, until it receives an Aloha message, the unit shall assume a value of
WAIT = NW (see Appendix 1).
WT WAIT WT WAIT
0 0 4 4
1 1 5 5
2 2 6 10
3 3 7 15
Table 7-2 Response delays indicated by the delay parameter WT
7.3.8 Retry decision and time-outs
After sending a random access message, a radio unit shall wait to receive a
response from the TSC. Various messages shall be accepted as a valid response (as
specified in the sections detailing the call procedures).
If the radio unit does not receive a response within the WAIT+1 slots after its
message, it shall assume that the message was unsuccessful. Then it shall either:
a. abandon its access attempt (see below), or
b. choose another slot, from a new frame (using a frame marker message received in
or after the WAIT+1 th slot after the unsuccessful message); however, if the unit
receives a valid response before sending a repeat message, it shall accept the
response and not retransmit.
The radio unit shall abandon its access attempt if it has sent the maximum permitted
number of transmissions and received no valid response. This number depends on the
function of the message:
- For requests RQS, RQD(E=0), RQX, RQT, RQR, RQQ and RQC, it is NR.
- For emergency requests RQE and RQD(E=1), it is NE.
The unit shall also operate a time-out TC on the maximum time it spends trying to achieve
access, and abandon the attempt if this time-out expires.
If the unit's access attempt fails, then:
i) If the message was a cancellation/abortion request RQX, the unit shall return to
waiting for signalling for the original transaction, and shall not send any further
RQX messages whilst in this state for futher signalling. (for example, see sections
9.2.1.7 and 9.2.1.6).

ii) For access attempts for other messages:
- if the unit has not sent a message, it shall return to the idle state (and may
indicate the failure to the user);
- otherwise, it shall wait for further signalling for the transaction (until the relevant
time-out TW or TJ has expired - for example, see sections 9.2.1.1 and
9.2.1.6).0.42

7.4 Related Procedures for All Radio Units on a Control Channel
7.4.1 Individually addressed Aloha message
If a radio unit on a control channel receives an Aloha message with M = 20 and

Aloha address (PFIX/IDENT1) matching its individual address for this system, then it shall
send a message in the next slot:
a. If the unit recognises the Aloha function and is currently attempting random access
with a message of a type invited by the Aloha message, it shall transmit its message
and then continue to obey the procedures in section 7.3 (regarding the transmission
as if it were a random access).
b. Otherwise, if the Aloha message is ALHR and the unit has the ability to register, it
shall send a registration request RQR and then wait until it receives a response or for
WAIT+1 slots. While waiting for a response, the unit shall not seek to transmit
messages by random access. See also section 8.3.2.
c. Otherwise, the unit shall send an acknowledgement ACKX(QUAL=0) with

PFIX/IDENT2 set to its individual address and IDENT1 set to TSCI. (It will not be
sent a response to this message.)
7.4.2 MOVE message
If a radio unit on a control channel receives a MOVE message that is applicable to it

(see below), then it shall move to the specified forward control channel and shall be able to
receive within 35 ms after the end of the MOVE address codeword; after becoming active
on the specified control channel, the unit shall retain the same state as on the old control
channel except that, if currently attempting random access, it shall choose a slot from a
new frame, using a frame marker message received on the new control channel (see
7.3.5).
The unit uses the address qualifier (M) and the address (PFIX/IDENT1) from the
MOVE message to decide whether the message is applicable to it. For M = 0 to 19, the
message is applicable to the unit if the M least significant bits of the MOVE address match
the M least significant bits of its individual address. For M = 20, the message is applicable
to the unit if the MOVE address matches any of its designated addresses for this system
(including its group addresses).
Note: If field CONT in an applicable MOVE message is equal to '0000000000', then the
channel movement is system-dependent.

8. REGISTRATION PROCEDURES
Registration enables a radio unit to inform a system that it is within a session on that
system. This section defines signalling procedures for radio units and TSCs that are
required to employ registration.
Additional specifications will be needed for a specific system implementation, for

example, to define:
- the criteria for when a radio unit should initiate registration

- the radio unit action after a registration denial or failure.
These specifications are likely to be system-dependent and therefore are not included in
this standard.
8.1 Registration Facilities

The registration procedures in this standard provide the following facilities for the
TSC:
a. The TSC shall indicate, by the value of field FUNC in Aloha messages, whether
random access registration request messages are invited from radio units. (See also
sections 7.2.3 and 7.3.2.)
i) ALH, ALHS, ALHD and ALHR invite registration requests.

ii) ALHE and ALHX do not invite registration requests.
iii) The function of ALHF will be determined by the customised fall-back mode.
b. The TSC may vary the value of the address qualifier (M) in Aloha messages to invite
registration requests from:
- the whole radio unit population (M = 0),

- a section of the radio unit population (0 < M < 20), or
- members of a selected group only
(M = 20 and PFIX/IDENT1 set to a group address).
See also sections 7.2.2 and 7.3.1.
c. The TSC may demand registration from a specific radio unit by transmitting the ALHR
message, with PFIX/IDENT1 set to the individual address of the wanted radio unit
and M set to 20.
d. The TSC may reject individual registration requests.
e. The TSC may transmit the BCAST message with SYSDEF='00011', to broadcast
registration parameters to radio units. See 5.5.4.5d.
The procedures for registration by random access and registration on demand are specified
in sections 8.2 and 8.3 respectively.
MPT1327 1997 IssueMPT1327 TSMG 1997 Issue Page 8-11

8.2 Procedures for Registration by Random Access
8.2.1 TSC Procedures
The TSC shall use the random access protocol to control the generation of
registration requests by the radio unit population, as described in section 8.1 above. If the
TSC indicates, in the manner described therein, that registration requests are invited then it
shall be prepared to receive RQR messages from radio units.
8.2.1.1 Responses to a random access RQR message
A radio unit requests to register by generating an RQR message, complying with the
random access protocol. On receiving an RQR message, the TSC shall send a response -
ACKI(QUAL=1), ACKX or ACK(QUAL=0) - with PFIX/IDENT2 as the unit's individual
address and IDENT1 set to REGI. For acceptable delay, see 7.2.4. See also 8.2.1.2.
8.2.1.2 Acknowledgements sent to indicate progress of registration
The TSC may send the following acknowledgement messages (with PFIX/IDENT2 as
the unit's individual address and IDENT1 set to REGI) to indicate to a radio unit the
progress of its registration:
ACKI (QUAL=1) - Intermediate acknowledgement; the decision to accept or reject

the registration has been postponed; more signalling to follow.
The TSC may also demand the serial number of the radio unit by sending an AHYC
message in accordance with section 15.2. This shall be considered an intermediate
acknowledgement
8.2.1.3 TSC time-out
The TSC may instruct a radio unit to restart its waiting timer TJ, by sending the AHY
message with bit POINT set to '1', PFIX/IDENT2 set to the unit's individual address and
IDENT1 set to REGI; see 9.1.1.7 and 9.2.2.3. If a time TJ (minus the tolerance on the radio
unit's timer) elapses since the last message it received for the registration, the TSC shall
not send any further signalling for the registration. See also 8.2.2.4.
Page 8-22 MPT1327 1997 IssueMPT1327 TSMG 1997 Issue

8.2.2 Radio Unit Procedures for Registration by Random Access
8.2.2.1 Criteria for registration
At the start of a session, a radio unit shall decide (by examination of the system
identity code in codewords received on the forward control channel) whether it should seek
to register with the system. The process by which the unit decides whether to seek to
register is system-dependent and is not included in this standard.
A radio unit seeking to register with a system may attempt to make calls prior to
registration (but shall be prepared to register on demand before being accepted for traffic;
see 7.4.1 and 8.3.2.1).
8.2.2.2 Registration request and valid responses
A radio unit requests to register by sending the RQR message on a control channel,
complying with the random access protocol (see 7.3). The fields in the RQR message shall
be set appropriately (see 5.5.3.1.6); however, note particularly that PFIX/IDENT1 is set to
the radio unit's individual address agreed for the system, and field INFO may contain
additional (customised) information.
The unit shall attempt access until it receives a valid response (see below) or until the
access attempt fails (i.e. the unit has sent the maximum number of transmissions NR and
received no response, or its access time-out TC has expired (see 7.3.8)). In the case of
access failure, if the unit has not sent a request, it shall return to the idle state (further
actions to be taken by the unit are system-dependent); otherwise, it shall wait for further
signalling for the registration - see 8.2.2.3 and 8.2.2.4.
The unit shall accept acknowledgements ACKI(QUAL=1), ACKX or ACK(QUAL=0),

with PFIX/IDENT2 as its individual address and IDENT1 as REGI, as a valid response to its
RQR and send no more requests. For other actions on receiving these messages, see
section 8.2.2.3.
8.2.2.3 Acknowledgement received
If a radio unit attempting access or waiting for signalling for a registration receives
ACKI(QUAL=1), with PFIX/IDENT2 as its individual address and IDENT1 as REGI, or an
AHYC serial number interrogation message (see section 15.2.1), then it shall wait for
further signalling for the registration. (For time-out, see 8.2.2.4.)
If a radio unit attempting access or waiting for signalling for a registration receives
ACKX or ACK(QUAL=0), with PFIX/IDENT2 as its individual address and IDENT1 as REGI,
then it shall return to the idle state:

Other actions to be taken by the radio unit on receiving ACKX or ACK(QUAL=0) are
system-dependent. (For example, receipt of ACKX(QUAL=0) could restrict or ban random
access on the system for the duration of the session).

8.2.2.4 Time-out after waiting
A radio unit waiting for further signalling for a registration shall return to the idle state
if a time TJ has elapsed since the last message it sent for the registration, viz.
RQR, requesting registration (see 8.2.2.2 and 8.3.2.1)

or ACK(QUAL=0), sent in response to an AHY message with bit POINT = 1 and IDENT1
set to REGI (see 9.2.2.3).
The unit shall assume that the outcome of the registration attempt is unknown. (Further
actions to be taken by the unit are system-dependent.)

8.3 Procedures for Registration on Demand
8.3.1 TSC Procedures for Demanding Registration
The TSC may demand a registration message from any radio unit which may be
within a session on the system. For example, it may use this facility after sending a
response to a call request from a radio unit that has not registered.
The TSC demands registration from a radio unit by transmitting the ALHR message
on the control channel, with:
- PFIX/IDENT1 set to the individual address of the radio unit

- the address qualifier (M) set to 20.
- the Aloha number (N) set to 1.
The ALHR message instructs the addressed radio unit to send a reply (RQE, RQR or
ACKX(QUAL=0)) in the next slot; see sections 7.4.1 and 8.3.2.1. If the TSC does not
successfully decode a reply, it may repeat the ALHR message when convenient.
If the reply is RQE, the TSC shall send a response as soon as possible (see 10.1.1
and 10.1.2).
If the reply is RQR, the TSC shall decide whether to accept the registration. Valid
responses are:

with PFIX/IDENT2 set to the radio unit's individual address and IDENT1 set to REGI. See
also section 8.3.2.2.

8.3.2 Radio Unit Procedures for Registration on Demand
8.3.2.1 Individually addressed ALHR message
If a radio unit on a control channel receives an Aloha message with M = 20 and

PFIX/IDENT1 matching its individual address for the system, then it shall send a message
in the next slot, as specified in section 7.4.1. For convenience, the procedure is repeated
here, for the specific case of FUNC = ALHR.
a1. If the unit is currently attempting random access for an emergency call, it shall send
an emergency request RQE or RQD(E=1) and then continue to obey the procedures
in sections 7.3 and 10.2 or 17.1.2.2 (regarding the transmission as if it were a
random access).
a2. Otherwise, if the unit is currently attempting random access for registration, it shall
send a registration request RQR and then continue to obey the procedures in
sections 7.3 and 8.2.2 (regarding the transmission as if it were a random access).
b. Otherwise, if the unit has the ability to register, it shall send a registration request
RQR and then wait until it receives a response or for WAIT+1 slots; see 8.3.2.2.
While waiting for a response, the unit shall not seek to transmit messages by random
access.
c. Otherwise, the unit shall send ACKX(QUAL=0) with PFIX/IDENT2 set to its individual
address and IDENT1 set to TSCI.
8.3.2.2 Responses to RQR sent on demand
After sending a demanded RQR in reply to ALHR with M=20, the radio unit shall
accept either of the following acknowledgements, with PFIX/IDENT2 as its individual
address and IDENT1 as REGI, as a valid response to its RQR:

If ACKX(QUAL=0) is received, the action to be taken by the radio unit is system-

dependent (as in 8.2.2.3).
If ACK(QUAL=0) is received, the unit shall return to the state it was in directly prior to
receiving the ALHR message (unless signalling messages received in the interim have
changed this state). After receiving ACK(QUAL=0) in response to a registration on
demand, the unit shall assume that its current registration requirements are satisfied, as if it
had successfully registered by random access (see 8.2.2.3).
If the unit receives no response within the WAIT+1 slots after its RQR, then it shall
return to the state it was in directly prior to receiving the ALHR message (unless signalling
messages received in the WAIT+1 slots have changed this state).

9. BASIC CALL PROCEDURES
This section defines the basic call procedures for non-emergency speech calls and
calls requiring a channel over which non-prescribed data may be sent. The procedures
cover both short addressing and extended addressing calls. They cater for calls between
the following parties:
radio unit → radio unit, line unit or group

radio unit → all units in system
radio unit → PABX extension (with extension number that can
be represented by 13 bits, or with a "long"
extension number)
radio unit → PSTN destination (prearranged or general)
line unit → radio unit, group or all units in system
PABX extension → radio unit, group or all units in system
PSTN telephone → radio unit, group or all units in system.
These calls from radio units are requested using the "Simple" Call Request Message
RQS; see section 5.5.3.1.1. Bit DT in the RQS message specifies whether the unit is
requesting a conversation or a channel over which any appropriate audio signalling, even a
non-standard modulation or format, may be sent to the called unit(s).
The RQS message contains all the information necessary to request a short
addressing call viz. a common-prefix call, a system-wide call, a call to a prearranged PSTN
destination or a call to a "short" PABX extension number. However, for an interprefix call, a
general call to the PSTN or a call to a "long" PABX extension number, the call details
cannot be accommodated in a single address codeword. For these types of call, the RQS
message requests entry into the extended addressing mode; the radio unit sets IDENT1 in
the RQS to the appropriate gateway ident (viz. IPFIXI, PSTNGI or PABXI), and the TSC
then demands the full called party information using the AHYC message.
The basic procedures for the TSC and radio units are specified in sections 9.1 and
9.2 respectively. These procedures cover:
a) call set-up
- call request procedures for Simple calls

- call cancellation while waiting for a call
- checking availability of radio units
- traffic channel allocation
b) call maintenance and call clear-down.
Other sections define related procedures (such as call diversion and Include call requests),
and procedures for status messages, short data messages, data interrogation and
emergency calls. Note particularly that status messages (RQQ - see section 13) are used
for:
a) the "Called Party Answer" mechanism
b) cancellation of a requested speech call after the called unit has accepted the
call for call-back.

Examples of typical message sequences to set up:
a) a short addressing call

b) an extended addressing call
between two radio units are illustrated below. Both sequences include the call request,
availability check and channel allocation signalling. (In these examples, the TSC checks
only that the called unit is in radio contact before allocating a traffic channel i.e. the called
party answer mechanism is not employed.) The extended addressing example has an
extra phase: after receiving the RQS message, the TSC sends AHYC to instruct the calling
unit to transmit the full called address information.
1 slot
<----->
1 3 5
TSC to RUs ALH ALH AHY ALH GTC GTC GTC
(3) (0) (0) (0) (1) (1)
RUs to TSC 2 4
RQS ACK
\________________/ \__________/ \____/ \____/
frame frame frame frame
Example A message sequence on a control channel to set up a common-prefix call

between two radio units on the same site.
2. RQS : Random access request for a Simple call.
3. AHY : Availability check message

- demands a response from the called radio unit
4. ACK : Acknowledgement ACK(QUAL=0) from the called radio unit.
5. GTC : Go To Channel message instructing both radio units to switch to a

designated traffic channel for their call. In this example the GTC is
repeated immediately, for added reliability. (Note that repeat
messages may be delayed for other signalling.)

1 slot
<----->
1 3 5 7 8
TSC to RUs ALH ALH AHY ALH AHY ALH GTC GTC
(4) (0) C (0) (2) (0) (1)
2 4 6
RUs to TSC RQS SAMIS ACK
\______________________/ \__________/ \____/

frame frame frame
Example A message sequence on a control channel to set up an interprefix call between

two radio units on the same site.
1. ALH : General Aloha invitation (four-slot frame).
2. RQS : Random access request for an interprefix Simple call (IDENT1 set
to IPFIXI).

- instructs the calling unit to send the called address
4. SAMIS : Single Address Message from the calling radio unit, containing the
prefix and ident of the called unit.
5. AHY : Availability check message - demands a response from the called

radio unit.
In this example, the availability check is a single-codeword
message i.e. the address of the calling unit is not supplied.
6. ACK : Acknowledgement ACK(QUAL=0) from the called radio unit.
7. GTC : Go To Channel message instructing the called radio unit to switch to

a designated traffic channel for the call.
8. GTC : Go To Channel message instructing the calling radio unit to switch

to the designated channel for the call.

9.1 Basic Call Procedures for TSC
This subsection describes the basic call facilities available for use by the TSC.
However, note that the TSC is allowed a great deal of flexibility and it need not implement
all these facilities. Also, system designers are left free to choose an appropriate strategy
for scheduling messages on the control channel.
9.1.1 Basic TSC Procedures for Setting Up Calls
9.1.1.1 Responses to a short addressing RQS message
A radio unit requests a short addressing Simple call by generating an RQS message
(with EXT = 1, or with EXT = 0 and IDENT1 set to a valid called party ident), complying with
the random access protocol. On receiving a short addressing RQS message, the TSC
shall send a response (so that the radio unit will not retransmit its message). The response
may be sent in the slot following the RQS or it may be delayed; for acceptable delay, see
7.2.4.
The following messages are valid responses to a short addressing RQS message
(though a TSC need not be able to provide all of these messages):
a. An acknowledgement ACKI, ACKQ, ACKX, ACKV or ACKB(QUAL=0), with

PFIX/IDENT2 as the calling unit's individual address and IDENT1 as the called ident
(or PABXI for a call to a PABX extension) - see 5.5.2.1.
b. An acknowledgement ACKT(QUAL=0), with PFIX/IDENT2 as the calling unit's

individual address - see 5.5.2.1 and 9.1.1.4.
c. An AHY message (i.e. availability check) for this call - see 9.1.1.5 and 9.1.1.7.
d. A Go To Channel message GTC for this call, or a call with which this call has been
amalgamated - see 9.1.1.9 and 9.1.1.12.
The response is thus a direct acknowledgement (as in a. and b.) or an indirect

acknowledgement (as in c. and d.).
The acknowledgement messages may also be sent to the calling unit at appropriate
times to indicate the progress of the call set-up - see 9.1.1.4.
9.1.1.2 Responses to an extended addressing RQS message
A radio unit requests an extended addressing Simple call by generating an RQS

message (with EXT = 0 and IDENT1 = IPFIXI, PSTNGI or PABXI), complying with the
random access protocol. On receiving an extended addressing RQS message, the TSC
shall send one of the following responses, with the same prefix and idents as the RQS:
a. An acknowledgement ACKI(QUAL=1), ACKX or ACKV(QUAL=0).
b. AHYC (i.e. an instruction to send the full called address information).
For acceptable delay, see 7.2.4. See also 9.1.1.3 and 9.1.1.4.
9.1.1.3 Instruction to send extended address information
After receiving an extended addressing RQS message, the TSC may demand the full
called address from the calling radio unit; it uses the AHYC message, with the same prefix
and idents as the RQS and field DESC set to indicate the appropriate gateway (see

5.5.3.2.8). In the AHYC message, the SLOTS parameter shall be set to correspond to the
request as follows:
For an interprefix or PABX call, SLOTS = '01'

For a general PSTN call, for up to 9 digits, SLOTS = '01'
for 10 to 31 digits, SLOTS = '10'
The AHYC message instructs the calling unit to send the called party address information in
the following SLOTS slot(s) (see 9.2.2.1). If the TSC does not successfully decode the
address information, it may repeat the AHYC message or transmit ACKV(QUAL=0) to
indicate failure of the call.
After decoding the full address information successfully, the TSC may send
appropriate acknowledgements to the calling unit (see 9.1.1.4).
The TSC may send AHYC in any slot on the forward control channel. However, note
that AHYC bars random access only in the next return slot. For SLOTS = '01', this is
sufficient for the unit's response; however, for SLOTS = '10', the TSC shall take appropriate
action to reserve the second return slot if it is within a random access frame (e.g. by
sending the AHY message, with both idents set to DUMMYI, in the slot following the
AHYC).
9.1.1.4 Acknowledgements sent to calling unit to indicate progress of

Simple call
The TSC may send acknowledgement messages at appropriate times to indicate to a

calling radio unit the progress of its Simple call - for idents in acknowledgements, see
5.5.2.1. (For extended addressing calls, only ACKI(QUAL=1), ACKX and ACKV(QUAL=0)
are appropriate until the full address information has been obtained.) Note that the criteria
for setting the maximum delay of repeats of acknowledgements ACKX, ACKV, ACKB and
ACKT should take account of time-out TB (described in 9.2.1.4).
The TSC may send ACKI or ACKQ to indicate to a calling radio unit the progress of
the signalling for its Simple call:
It may send ACKX or ACKV to indicate to the calling unit that its Simple call request
will not be complied with:
ACKX (QUAL=0) - Invalid call e.g. calling unit is blacklisted, or called address is
unobtainable, or called unit cannot accept the call.
It may send ACKB(QUAL=0) to indicate to the calling unit that its Simple call request
has been accepted for call-back by the called unit.
If the TSC has previously accepted a diversion request RQT requesting that this type
of call be redirected to another party, then it shall send ACKT(QUAL=0) with PFIX/IDENT2
as the calling unit's individual address and:

a. IDENT1 as the diversion ident, or
b. IDENT1 as a gateway (viz. IPFIXI, PSTNGI or PABXI); in this case, the diversion
address follows in concatenated data codeword(s). Note that IDENT1 is set to IPFIXI
to indicate either an interprefix diversion address or that the diversion address is of a
different type (group/individual) from the called address; see 5.5.2.1.
(On receiving ACKT, the radio unit will either return to the idle state or re-attempt access
calling the diversion address - see 9.2.1.4.)
9.1.1.5 Availability check on called radio unit
After receiving a request for an individual call to a radio unit, the TSC shall at least
check that the called unit is in radio contact before making a traffic channel allocation; (the
TSC is exempted from this requirement when operating in fall-back mode). The TSC may
check also that the called user/ data equipment is ready for the call before allocating a
channel.
The TSC checks availability of a called radio unit by sending the AHY message, with:
- bit POINT set to '0'
- bit CHECK set to indicate whether the TSC is checking:

a) only that the called unit is in radio contact (CHECK=0), or
b) that the called user/ data equipment is ready (CHECK=1)
- bits D and E set appropriately (see 5.5.3.2.1)
- PFIX/IDENT1 as the called unit's address
- IDENT2 as the calling ident (or gateway).
If IDENT2 = IPFIXI, the TSC may append a data codeword containing the calling unit's
address; if so, it shall set bit AD in the AHY to '1' (and shall set flag RSA in the "filler" data
codeword to '0' - see 7.2.5).
The AHY message demands a response from the called unit (see 9.2.2.2A). If the
response is ACKI(QUAL=0), ACKX(QUAL=0), ACKV(QUAL=1) or ACKB(QUAL=0), the
TSC may send appropriate acknowledgement(s) to a calling radio unit (see 9.1.1.4). If the
TSC does not successfully decode a response, or if the response is ACKB(QUAL=1) or
ACKI(QUAL=0), it may repeat the AHY message at intervals. If the called unit cannot be
contacted, the TSC may indicate the failure to the calling unit by sending ACKV(QUAL=0).
After sending ACKI(QUAL=0) in response to an AHY message with CHECK = 1, a

radio unit may attempt random access with RQQ(STATUS='00000') addressed to the TSC
when its user/ data equipment is ready to receive the call. After responding with
ACKI(QUAL=0) or ACK(QUAL=0), the unit may send RQQ(STATUS='11111') if its user no
longer wishes to receive the call. The TSC shall send appropriate responses to these "off-
hook" and "on-hook" RQQ messages; see 13.1.1.1.
Note that, if a radio unit is waiting for an incoming traffic channel call and receives an
AHY message checking its availability for a different incoming traffic channel call, then it
abandons any signalling for the first call and obeys the new AHY (see 9.2.2.2A, 9.2.2.4 and
13.1.2.8). Therefore, if the TSC sends an AHY message for a new call, it shall not send any
further acknowledgements for any previous "off-hook" or "on-hook" RQQ message from the
called unit. Note also that, if the TSC receives an "off-hook" or "on-hook" RQQ message
from a called radio unit before it has received a response to an AHY message for the call,
then the RQQ message could be for an old call.

9.1.1.6. Availability check for calls to PABX extensions and PSTN
destinations
For calls to PABX extensions or onto the PSTN, the TSC may check that the called
telephone has been answered before allocating a traffic channel. This check may be made
either manually or automatically.
9.1.1.7 Availability check on requesting radio unit
The TSC may check the availability of a requesting radio unit by sending the AHY
message, with:
- bit AD set to '0'

- bit CHECK set to '0'
- bits D and E set appropriately (see 5.5.3.2.1)
- PFIX/IDENT2 as the requesting unit's address
- IDENT1 as the called ident or gateway
(or REGI for a registration request; see 8.2.1.3).
The AHY message demands a response from the requesting unit (see 9.2.2.3) and also
instructs the unit to restart its waiting timer for the requested call or transaction. The
message therefore has two functions:
a. To restart the unit's timer (TW or TJ), enabling the TSC to use a variable queueing
time limit; for example, see 8.2.1.3, 9.1.1.10, 10.1.7, 12.1.7, 13.1.1.4, 13.2.1.7 and
14.1.9.
b. To check that the calling unit is still in radio contact, before a traffic channel is
allocated for a call. (If the call will not be set up, the TSC may inform the called unit;
see 9.1.1.8.)

9.1.1.8 Call cancellation
A calling radio unit may cancel a requested Simple call by generating an RQX
message (see 5.5.3.1.3), complying with the random access protocol. On receiving an RQX
message cancelling a Simple call, the TSC shall send a response. Valid responses are:
a. ACK(QUAL=1), with the same prefix and idents as the RQX.

b. AHYX, with the same prefix and idents as the RQX.
If a call is cancelled (for example, on the request of the calling unit or after an
availability check on the calling unit or if the TSC's queueing time limit is exceeded), then
the TSC may inform a called radio unit by sending the AHYX message with PFIX/IDENT1
as the called unit's address and IDENT2 as the calling ident (or gateway). The TSC may
repeat the AHYX message if it is not acknowledged by an ACK(QUAL=1) message from
the called unit (see 9.2.2.4).
If the TSC receives an RQX message on a control channel, and does not currently
hold a corresponding call or transaction request from that unit, it shall send a response:
ACK(QUAL=1), with the same prefix and idents as the RQX.
9.1.1.9 Call amalgamation

The TSC shall either amalgamate any (non-emergency) individual speech calls in its
queues which are between the same parties, or refuse to accept more than one speech call
between the same individuals. See also section 10.1.8b.
(The TSC shall not amalgamate speech calls to the same group, or data calls.)
9.1.1.10 Queue management and queue time-out
The TSC may order its queue of calls (non-priority and priority, between any parties)
in any way acceptable to the system operator.
The TSC may operate a time-out on the maximum time for which it queues a call (for
example, waiting for a traffic channel or for the called party to be free). See also 9.2.1.6
and 9.2.2.4.
The TSC may instruct a calling radio unit to restart its waiting timer, by sending the
AHY message with bit POINT set to '1'; see 9.1.1.7 and 9.2.2.3. If a time TW, minus the
tolerance on the radio unit's timer, elapses since the last message it received for a Simple
call (from the calling unit), the TSC shall not send any further signalling for the call, except
that it may send AHYX to inform a called radio unit that the call will not take place (see
9.1.1.8).

9.1.1.11 Resolving call conflicts
It is recommended that the TSC uses suitable rules to decide on priorities for
resolving call conflicts. For instance:
a. it should not send an individually addressed GTC command to a radio unit that is
known to be currently engaged in another call;
b. for a system-wide call, it may wait until all traffic channel activity has ceased before
allocating a channel (so that the system-wide call can be heard by all powered-on
units).
Similar conflicts may arise for group/subgroup calls. (Note, however, that the TSC is not
required to know the membership of groups i.e. it need not check for call conflict involving
individual called units in a group.)
9.1.1.12 Traffic channel allocation
The TSC shall allocate traffic channels using the Go To Channel message GTC (see
5.4). It shall set bit D in the GTC message to '0' when setting up a speech call or to '1'
when setting up a data call (e.g. a Simple call requested with bit DT set to '1'). It may
repeat the GTC command.
In the case of a multi-site call on a system employing time-shared control channels

where the calling and called parties are active on the same control channel, the GTC to the
calling party may contain DUMMYI or TSCI in IDENT1 and the GTC to the called party may
contain DUMMYI or TSCI in IDENT2.
In the case of an interprefix call between radio units, at least two GTC messages
must be transmitted: one to instruct the called unit (or group) and one to instruct the calling
unit. For a multi-site call, these GTC messages may be sent at different sites.
Note that a called radio unit in an interprefix call is permitted to remain on the control
channel for one timeslot after receiving GTC, to see whether the next message is a GTC
for the calling unit; see 9.2.2.5. It is recommended that the TSC schedules GTC messages
appropriately.

9.1.2 Basic TSC Procedures for Maintenance and Clear-Down of Calls
It should be noted that the transmission of standardised messages on a traffic

channel during a call requested with RQS, DT=1 could corrupt non-prescribed data
signalling. It is recommended that any use of the facilities described below takes this into
account.
9.1.2.1 Call maintenance options
All speech items transmitted by radio units on an allocated traffic channel end with at least
one Pressel Off message (see 9.2.3.1). The TSC may also require that any radio unit
which transmits a speech item shall start the item with at least one Pressel On message,
and that the unit shall interrupt the item at intervals to send a call maintenance message.
The TSC indicates activation or deactivation of these options, the maximum duration of the
interval and the required setting of PFIX/IDENT1 for call maintenance messages in group
calls, by sending the BCAST message with SYSDEF='00010' (see 5.5.4.5c) on the control
channel.
9.1.2.2 Availability check on a traffic channel

During a call, when appropriate, the TSC may query whether an individual radio unit
is on the traffic channel by sending (on the traffic channel) an AHY message with bit AD = 0
and:
POINT = 0 and PFIX/IDENT1 as the unit's individual address

or POINT = 1 and PFIX/IDENT2 as the unit's individual address.
The AHY message demands an acknowledgement from the addressed radio unit; see
9.2.3.2.
Note that the AHY message with POINT set to '1' (and IDENT1 set to the called ident
or gateway) may be sent to instruct an Including unit to restart its waiting timer TI. See
section 11.1.7.
9.1.2.3 Disabling user transmission
During a call, the TSC may send call maintenance message MAINT, OPER='111' on
the traffic channel to instruct radio units to inhibit user transmission; see 5.5.4.2 and
9.2.3.3. It can disable individually addressed units, called units in a group or all radio units.
For instance, the TSC may send this message at the start of a group call if the calling
unit requested that the called users be disabled from replying.
9.1.2.4 Allocating replacement traffic channel

During a call, the TSC may send GTC messages on the traffic channel to move radio
units already in communication to a replacement traffic channel; see 5.4 and 9.2.3.4. (For
instance, the TSC could send this message if one traffic channel has special facilities and
an emergency call requiring these facilities is requested when the channel is in use for
another call.)
Note that the TSC may send MAINT, OPER='111' during an item to disable radio
users from replying, and then send GTC at the end of the item. Receipt of the GTC
message re-enables user transmission on the replacement channel (unless IDENT1 =
ALLI); see 9.2.3.4.

9.1.2.5 Clearing down unwanted radio units during a call
During a call, the TSC may send call maintenance message MAINT, OPER='110' on
the traffic channel to clear down any radio units that should not be there. The address
(PFIX/IDENT1) in the message "labels" the ongoing call, so that only unwanted radio units
leave the channel; see 5.5.4.2 and 9.2.3.7.
Note that:
a. If radio units with different prefixes are occupying the traffic channel then
transmission of MAINT, OPER='110' would clear units with the other prefix.
b. After an Include call, the use of MAINT, OPER='110' could clear the included party.
9.1.2.6 Call clear-down
The TSC shall clear down a call in which the Include facility has not been used if any
one of the following criteria is satisfied; (after an Include call, criteria a. and b. may be
relaxed as specified in 11.1.9):
a. If it receives a valid Disconnect message (indicating the end of channel use) on

the return traffic channel, from either unit in an individual call or from the calling
unit in a group/system-wide call; see 5.5.4.2 and 9.2.3.5.
b. If either party in an individual call is a line/PABX/PSTN user, or if the calling party in a

group/system-wide call is a line/PABX/PSTN user, and the TSC detects appropriate
indication (from the line unit/PABX/PSTN) that the call has ended.
c. If the time without apparent transmission (e.g. without detected carrier, without
receiving valid call maintenance messages or without receiving a response to
availability checks) is excessive.
d. If an overall TSC call time limit is reached.
Also, if required by the type of system, the TSC may clear down a system-wide call or a
group call in which the called users have been disabled from replying, if it receives a valid
Pressel Off message from the calling unit.
The TSC shall clear down a call by sending at least two CLEAR messages on the
forward traffic channel; see also 3.3.2, 5.5.4.3 and 9.2.3.8.

9.2 Basic Call Procedures for Radio Units
It is recommended that a radio unit be equipped with a ready-for-communication
control (RFCC) e.g. a switch-hook. Optionally the unit may be equipped with a "Busy
control" which, if in the busy state, shall override an active RFCC state.
A radio unit attempting access or waiting for further signalling for a call may be sent
an availability check message AHY or Go To Channel message GTC for an incoming call
(see 9.2.2.2A and 9.2.2.5). Note that:
i) If the unit were to transmit ACKI(QUAL=0) in response to an AHY message with

CHECK = 1, then it would not be able to send the "off-hook" message until its own
call had been completed.
ii) The unit can reject an incoming individual call by sending ACKV(QUAL=1) in
response to the AHY message.
iii) A radio unit is required to obey individually addressed GTC messages and system-
wide calls (except in emergency), though it may ignore other group call GTCs if the
user does not wish to receive group calls.
However, if making a call of its own, the unit is required to ignore GTC messages for
incoming group calls (except calls to a group the unit is itself attempting to call); see
9.2.2.5. (This rule applies also to a unit that has received an AHY message for an
incoming individual call and responded with ACK(QUAL=0) or ACKI(QUAL=0).)
iv) If a unit receives and obeys a GTC message not for its own call, it returns to its
previous state at the end of the incoming call, unless the time-out (e.g. TW or TJ) on
the previous state has expired. (Note however that, if the unit was making a call of
its own, then it may attempt cancellation/abortion if the user no longer wants his call.)
9.2.1 Procedures for Radio Units Making Simple Calls
A radio unit shall make only one call attempt at a time (except in emergency); while
attempting access or waiting for further signalling for its Simple call, the unit shall not
request another non-emergency call of any type (unless the user first cancels the original
call).
Radio units can request calls to most PABX extensions using short addressing; in the
RQS message, IDENT1 is the extension number, EXT = 1 and FLAG1/FLAG2 indicates the
appropriate exchange (see sections 4 and 5.5.3.1.1). All other messages sent during the
call set-up use the PABX gateway ident, PABXI.
By prearrangement with the system, radio units may request calls to a limited number
of PSTN destinations using short addressing; IDENT1 in the RQS message is set to the
appropriate short-form PSTN ident (see section 4).
Radio units use extended addressing procedures to request interprefix calls, general
calls to the PSTN and calls to PABX extensions with "long" numbers; IDENT1 in the RQS
message is set to the appropriate gateway and the unit then sends the full called address
information in response to an AHYC message from the TSC.
9.2.1.1 Request for a Simple call
A radio unit requests a Simple call by sending an RQS message on a control

channel, complying with the random access protocol (see 7.3). The fields in the RQS
message shall be set appropriately (see 5.5.3.1.1); however, note particularly that:

a. Bit DT specifies whether the caller is requesting a speech call (DT=0) or a channel for
sending non-prescribed data (DT=1).
b. An extended addressing request is indicated by setting IDENT1 in the RQS message

to the appropriate gateway (viz. IPFIXI, PSTNGI or PABXI).
The unit shall attempt access until:

i) it receives a valid response (see 9.2.1.2/3), or
ii) its user cancels the call (see 9.2.1.7), or
iii) the access attempt fails (i.e. the unit has sent the maximum number of
transmissions NR and received no response, or its access time-out TC has
expired (see 7.3.8)). In this case:
- If the unit has not sent a request, it shall return to the idle state (and may
indicate the failure to the user).
- Otherwise, the unit shall wait for further signalling for the call; see 9.2.1.4 to
9.2.1.6. (As usual, the unit may attempt cancellation while waiting; see
9.2.1.7.)
If the user tries to initiate another non-emergency call of any type or re-initiate the
same call (without first cancelling it) while his unit is trying to access the system, the unit
shall ignore the command.
9.2.1.2 Valid responses to short addressing RQS
For a short addressing call, the calling unit shall accept the following messages as a
valid response to its RQS and send no more requests:
a. An acknowledgement ACKI, ACKQ, ACKX, ACKV or ACKB(QUAL=0), with

PFIX/IDENT2 as its individual address and IDENT1 as the called ident (or PABXI if it
is making a PABX call).
b. An acknowledgement ACKT(QUAL=0) with PFIX/IDENT2 as its individual address.

See also 9.2.1.4.
c. An AHY message with PFIX/IDENT2 as its individual address and IDENT1 as the
called ident (or PABXI for a PABX call).
d. A Go To Channel message GTC with PFIX/IDENT2 as its individual address and

IDENT1 as the called ident (or PABXI for a PABX call, or DUMMYI for a multi-site call
on a system employing time-shared control channels).
e. In response to an RQS with DT=0 and EXT=0: a GTC message with D=0,
PFIX/IDENT1 as its individual address and IDENT2 as the called ident. Note: this is
a check for call amalgamation.)
For other actions on receiving these messages, see sections 9.2.1.4, 9.2.1.5, 9.2.2.3 and
9.2.2.5.
9.2.1.3 Valid responses to extended addressing RQS

For an extended addressing call, the calling unit shall accept the following messages
(with the same prefix and idents as the RQS) as a valid response to its RQS and send no
more requests:

For other actions on receiving these messages, see 9.2.1.4 and 9.2.2.1.
If a radio unit attempting access or waiting for further signalling for a Simple call
receives an appropriate acknowledgement then it shall take action as indicated below.
Appropriate acknowledgements for a short addressing call, or for an extended addressing
call after the full address information has been sent, are:
- ACKI, ACKQ, ACKX, ACKV and ACKB(QUAL=0), with PFIX/IDENT2 as the unit's
individual address and IDENT1 as the called ident or gateway;
- ACKT(QUAL=0) with PFIX/IDENT2 as the unit's individual address.
Appropriate acknowledgements for an extended addressing call before the full address
information has been sent are ACKI(QUAL=1), ACKX and ACKV(QUAL=0), with
PFIX/IDENT2 as the unit's individual address and IDENT1 as the called gateway.
ACKB (QUAL=0) - Called unit has accepted the call for call-back.
If ACKI or ACKQ is received, the unit shall wait for further signalling for the call and
may indicate to the user the progress of the call.
If ACKX or ACKV is received, the unit shall return to the idle state and may indicate
to the user the reason for the failure of the call; it is recommended that receipt of
ACKX(QUAL=0) be indicated in a distinct manner.
If ACKB(QUAL=0) is received, the unit shall return to the idle state and may indicate
to the user that the call has been accepted by the called unit for call-back. If, after
receiving ACKB(QUAL=0), the user wishes to withdraw the request, then cancellation may
be attempted using an RQQ message with STATUS='11111' (addressed to the called unit);
see section 13.
If a complete ACKT(QUAL=0) message is received, the unit shall either:
a. return to the idle state (and may indicate to the user that the called party's calls have
been diverted), or
b. wait for a time TB (see below), and then attempt a new call to the diversion address
given in the ACKT message:
- if IDENT1 / IPFIXI, PSTNGI or PABXI, try on IDENT1;

- if IDENT1 = IPFIXI, PSTNGI or PABXI, try the alternative called party given in the
appended data codeword(s).

Note that ACKT(QUAL=0), with IDENT1 = IPFIXI and an appended data codeword,
indicates either an interprefix diversion address or that the diversion address is of a
different type from the original called address. Flag GF in the appended data codeword
specifies whether the diversion address is an individual or group address; see 5.5.2.1.
If an incomplete ACKT(QUAL=0) message is received (i.e. if not all the appended data
codewords are decodeable), then:
i) If the unit does not require the diversion address, it shall return to the idle state (and
may give an indication to the user).
ii) If the unit does require the diversion address then:
- if still attempting access for the call, it shall ignore the message and continue to
attempt access;
- otherwise it shall wait for a repeat ACKT, returning to the idle state if a time TB
elapses (in which case, it may indicate the failure to the user).
After receiving ACKX, ACKV or ACKB for its Simple call, the unit shall not request
another non-emergency call of any type to the same called ident for at least a time TB;
(note that this includes a call to the same gateway). After receiving ACKT for its Simple
call, the unit shall not request another non-emergency call of any type for at least a time
TB.
9.2.1.5 Availability check and channel allocation for own call
A calling radio unit attempting access or waiting for further signalling for a Simple call
shall obey the availability check and channel allocation procedures (see 9.2.2.2 to 9.2.2.5).
It shall decide whether a GTC message it receives is for its requested call by inspecting the
prefix and idents and bit D from the GTC message:
a. for a short addressing call, as in 9.2.1.2 d. and e.
b. for any extended addressing call, if PFIX/IDENT2 is its individual address and
IDENT1 is the called gateway
c. for an interprefix speech call, if:
- D=0, PFIX/IDENT1 is its individual address and IDENT2 is IPFIXI, and

- it receives a GTC message for the caller in the next slot (see 9.2.2.5a) and
PFIX/IDENT2 is the address the unit is calling. (Note: this is a check for call
amalgamation.)
If so, it may give an indication to the user, and shall revert to the idle state at the end of the
call.

A calling radio unit waiting for further signalling for a Simple call shall return to the
idle state if a time TW has elapsed since the last message it sent for the call, viz.
RQS, requesting the Simple call (see 9.2.1.1)

or SAMIS, providing extended address information for the call (see 9.2.2.1)
or ACK(QUAL=0), sent in response to an AHY message with bit POINT = 1
and IDENT1 as the called ident or gateway (see 9.2.2.3).
It may also indicate the failure to the user.

If the user tries to initiate another non-emergency call of any type or re-initiate the
same call (without first cancelling it) while his unit is waiting for signalling for the call, the
unit shall ignore the command.

9.2.1.7 Call cancellation
If the user wishes to cancel his Simple call and the unit has not yet sent an RQS,
then it shall return immediately to the idle state. Otherwise, if the unit has sent an RQS, it
shall attempt to send a call cancellation request RQX (see 5.5.3.1.3), complying with the
random access protocol (see 7.3). It shall attempt access until one of the following occurs:
a. It receives ACK(QUAL=1) or AHYX, with the same prefix and idents as the RQX,
confirming cancellation of the call.
b. It receives ACKX, ACKV or ACKT(QUAL=0) for the call it is attempting to cancel.

See also 9.2.1.4.
c. It receives ACKB(QUAL=0) for the call it is attempting to cancel; in this case, it may
indicate to the user that the call has been accepted for call-back and that the
cancellation was unsuccessful. (Withdrawal of the request may then be attempted
using an RQQ message with STATUS='11111', addressed to the called unit; see
section 13.)
d. It receives a GTC message for the call it is attempting to cancel; in this case, it shall
proceed to the designated traffic channel (see 9.2.2.5) and then revert to the idle
state at the end of the call.
e. It has sent the maximum number of transmissions NR and received no response, or

its access time-out TC has expired (see 7.3.8). In this case, it shall return to waiting
for signalling for the Simple call (see 9.2.1.4 to 9.2.1.6).
In cases a., b. and c., the unit shall return to the idle state.
If the user tries to "cancel" a call when his unit is not attempting access or waiting for
signalling for a call, the unit shall ignore the command.
9.2.2 Basic Procedures for All Radio Units on a Control Channel
These procedures shall be obeyed by all radio units on a control channel (including
units making calls or requesting transactions). For other procedures for all radio units on a
control channel, see sections:
6.2.1 Control channel discipline.

7.4 Individually addressed Aloha message and MOVE message.
8. Registration procedures.
13.2.3 Receiving status message (AHYQ).
14.3 Receiving short data message (HEAD).
15.2 Data interrogation procedures.
9.2.2.1 Instruction to send address information or data message

This procedure shall be obeyed by all radio units that are equipped to request
extended addressing calls, complex diversion or RQC transactions.
If a radio unit on a control channel receives an AHYC message with PFIX/IDENT2

matching its individual address then it shall either send address information or a data
message in the following SLOTS slot(s), or transmit ACKX(QUAL=0), as indicated below.
For timing, see 6.2.1.3.

If
the unit has sent an extended addressing non-emergency request, or has
received ACKE or AHY(E=1) for an extended addressing RQE
and IDENT1 matches IDENT1 from the request
and DESC is appropriate to IDENT1 (see 5.5.3.2.8)
and SLOTS corresponds to the request
(i.e. if IDENT1=PSTNGI and FLAG1=1 then SLOTS='10' else SLOTS='01')
then it shall transmit the full address information for IDENT1, conforming to the codeword
formats defined in section 5.6.1.2.2 (SAMIS, Mode 1).
Otherwise
If
the unit has sent a request for 3-address diversion (RQT, FLAG2=1)
and IDENT1 is set to DIVERTI
and DESC is set to '000'
and SLOTS is set to '01'
then it shall transmit the "blocked address", conforming to the interprefix codeword format
defined in section 5.6.1.2.2 (SAMIS, Mode 1, DESC='000').
Otherwise
If
the unit has sent an RQC message
and IDENT1 is set to SDMI
and SLOTS matches SLOTS from the RQC
then it shall transmit its short data message, conforming to the codeword formats defined in
section 5.6.2 (HEAD).
Otherwise
The unit shall transmit ACKX(QUAL=0), with the same prefix and idents as the AHYC.
9.2.2.2 Availability check on called radio unit
If a radio unit on a control channel receives an AHY message with PFIX/IDENT1

matching its individual address and bit POINT set to '0' then it shall respond with the
appropriate acknowledgement (see below), with the same prefix and idents as the AHY. If
bit AD = 0 in the AHY message, the unit shall respond in the slot following the AHY; if bit
AD = 1, a data codeword is appended (containing the calling address) and the unit shall
respond in the slot following the data codeword. For timing, see 6.2.1.3.
A) Incoming traffic channel call : IDENT2 = Ident (1 to 8100), Ident (8121 to 8180), INCI,
IPFIXI, PSTNGI or PABXI
If bit AD = 1 in the AHY message but the appended data codeword was not
decodeable and the unit requires the calling address for its operation, then it may
request a retransmission by sending ACKB(QUAL=1):
ACKB (QUAL=1) - The unit requires the message to be retransmitted.

Otherwise
The unit may reject the incoming call by sending ACKX(QUAL=0) or ACKV(QUAL=1):
ACKX (QUAL=0) - The unit cannot accept the call

e.g. D = 0 in the AHY message and the unit has no speech
equipment, or
D = 1 in the AHY message and the unit has no data
equipment.
ACKV (QUAL=1) - The user has indicated that he does not wish to receive this call
(e.g. using the "Busy control").
Otherwise
If bit D = 0 in the AHY message and IDENT2 is not set to INCI, the unit may accept
the call for call-back by sending ACKB(QUAL=0):
ACKB (QUAL=0) - The unit has accepted the call for call-back.
Otherwise
i) If bit CHECK = 0 in the AHY message, then the unit shall send ACK(QUAL=0):
ACK (QUAL=0) - Unit is available for the call.
ii) If bit CHECK = 1 in the AHY message, then the unit shall send either
ACKI(QUAL=0) or ACK(QUAL=0), to indicate its state of readiness so far as it is
able. For ACKI(QUAL=0), the unit shall alert the user or take action to prepare
the data equipment.
ACKI (QUAL=0) - Unit alerting but user/data equipment not ready

e.g. D = 0 in the AHY message and the unit's RFCC is not
currently active, or
D = 1 in the AHY message and the unit's data
equipment is not ready.
ACK (QUAL=0) - User/ data equipment is available for the call.
The unit may indicate the caller (by reference to PFIX/IDENT2 from the AHY message or
PFIX2/IDENT2 from the data codeword), and may indicate whether the incoming call is an
emergency call (by reference to bit E from the AHY).
After receiving an AHY message for an incoming traffic channel call and responding
with ACK(QUAL=0) or ACKI(QUAL=0), the unit shall ignore group call GTC messages as
specified in section 9.2.2.5 rule 2 or 3, until either:
a. it receives channel allocation signalling for the incoming call (i.e. a GTC message
with the same prefix, idents and bit D as the AHY), or
b. it assumes that the call will not take place; see 9.2.2.4.
If a radio unit receives AHY(CHECK=1) alerting it for an incoming call and responds
with ACKI(QUAL=0), it may attempt to send RQQ(STATUS='00000') to the TSC when its
user/ data equipment is ready to receive the call. After responding with ACKI(QUAL=0) or
ACK(QUAL=0), it may send RQQ(STATUS='11111') if the user no longer wishes to receive
the call; in this case, it shall respond to any repeat AHY messages (ie with matching
addresses and the same D and E bits) with ACKV(QUAL=1) until completion of the
hookswitch signalling. See also 13.1.2.1.

If, while waiting for an incoming traffic channel call, a radio unit receives a repeat
AHY message (ie with matching addresses and the same D and E bits), it shall send the
appropriate acknowledgement and continue with any "off-hook" or "on-hook" signalling in
progress; also, for ACK(QUAL=0) or ACKI(QUAL=0), it shall restart its timer TA (see
9.2.2.4). If the unit receives an AHY for a different incoming traffic channel call, it shall
abandon any signalling for the old call and obey the new AHY; see also 9.2.2.4 and
13.1.2.8.
B) Availability check for short data message : IDENT2 = SDMI
The unit may reject the short data message by sending ACKX(QUAL=0) or
ACKV(QUAL=1). Otherwise it shall send ACK(QUAL=0).
ACKX (QUAL=0) - The unit cannot accept the short data message e.g. it has no
data equipment.
ACKV (QUAL=1) - The user has indicated that he does not wish to receive short
data messages.
ACK (QUAL=0) - Unit is available to receive a short data message.
C) "No-call" test availability check : IDENT2 = DUMMYI
The unit may indicate that it is not suitably equipped by sending ACKX(QUAL=0).
Otherwise it shall send ACK(QUAL=0).
ACKX (QUAL=0) - The unit could not accept a call of this type e.g. D = 0 in the
AHY message and the unit has no speech equipment, or D = 1
in the AHY message and the unit has no data equipment.
ACK (QUAL=0) - Unit is in radio contact and is suitably equipped.
D) Invalid availability check : IDENT2 / Ident (1 to 8100), IDENT2=Ident(8121 to 8180),

INCI, IPFIXI, PSTNGI, PABXI, SDMI or DUMMYI
The unit shall send ACKX(QUAL=0), to reject the availability check.
9.2.2.3 Availability check on requesting radio unit
If a radio unit on a control channel receives an AHY message with PFIX/IDENT2

matching its individual address and bit POINT set to '1' then it shall respond with the
appropriate acknowledgement (see below), with the same prefix and idents as the AHY. If
bit AD = 0 in the AHY message, the unit shall respond in the slot following the AHY; if bit
AD = 1, a data codeword is appended and the unit shall respond in the slot following the
data codeword. For timing, see 6.2.1.3.
ACK (QUAL=0) - The unit is waiting for signalling for a call or transaction appropriate
to IDENT1 and bit E i.e.
a. IDENT1 is the called ident or gateway (or REGI for a
registration request)
b. E is '1' for an emergency call, otherwise '0'; see section
5.5.3.2.1.
See also sections 8.2.2.4, 9.2.1.6, 10.2.7, 12.2.5, 13.1.2.5,
13.2.2.5 and 14.2.6.
ACKX (QUAL=0) - The unit is not waiting for signalling for a call or transaction
appropriate to IDENT1 and bit E.

9.2.2.4 Cancelling alert/waiting state of called unit
If a radio unit on a control channel receives an AHYX message with PFIX/IDENT1

matching its individual address then it shall respond in the next slot with ACK(QUAL=1),
with the same prefix and idents as the AHYX.
A unit that has received an AHY message for an incoming traffic channel call (see
9.2.2.2A), and responded with ACK(QUAL=0) or ACKI(QUAL=0), shall assume that the call
will not take place if one of the following occurs:
a. It has not received channel allocation signalling for the call at a time TA after the last
ACK(QUAL=0) or ACKI(QUAL=0) it sent in response to an AHY for the call.
b. It receives an AHYX message with the same prefix and idents as the AHY. In this
case, if currently attempting an "off-hook" or "on-hook" RQQ transaction for the
incoming call, it shall return to the idle state - see 13.1.2.7.
c. It receives an AHY message checking its availability for a different incoming traffic
channel call (i.e. bit D and/or bit E and/or the calling address is different from the
original AHY). In this case, if currently attempting an "off-hook" or "on-hook" RQQ
transaction for the original call, it shall abandon the transaction - see 13.1.2.8.
In cases a. and b., the unit shall stop the alerting signal (if appropriate) and may indicate to
the user/ data equipment that the call will not take place; it shall also note that rule 2 or 3 of
section 9.2.2.5 (requiring it to ignore GTC messages for incoming group calls) no longer
applies. In case c., the unit shall obey the procedures in 9.2.2.2A for the new call.
9.2.2.5 Traffic channel allocation

A radio unit on a control channel shall check all GTC messages it receives to see
whether the message is addressed to it, that is, whether:
PFIX/IDENT2 from the GTC message matches its individual address

or PFIX/IDENT1 matches any of its designated addresses for this system
or IDENT1 is the system-wide all-call ident ALLI.
If the GTC message is addressed to it, the unit shall use the appropriate rule below to
decide whether to obey the command:
1. If the unit is making an emergency (RQE) call and has not received ACKE(QUAL=0)
or AHY(E=1) for its call, it shall obey the GTC message if and only if its emergency
call is a short addressing non-PABX call and the GTC message is for the requested
call (see 10.2.2 and 10.2.6).
If the unit is waiting for further signalling for its emergency call, after receiving
ACKE(QUAL=0) or AHY(E=1) for the call, it shall obey the GTC message if and only
if it is individually addressed by the GTC (i.e. its individual address is PFIX/IDENT1 or
PFIX/IDENT2).
2. Otherwise
If the unit is waiting for an incoming emergency call (see 9.2.2.2A), it shall obey the
GTC message if and only if it is individually addressed by the GTC.
3. Otherwise
If the unit is waiting for an incoming non-emergency traffic channel call (see
9.2.2.2A), it shall obey the GTC message if and only if it is individually addressed by
the GTC or IDENT1 is set to ALLI.

4. Otherwise
If the unit is attempting access or waiting for further signalling for a non-emergency
call or transaction, it shall obey the GTC message if and only if:
it is individually addressed by the GTC message,

or IDENT1 is set to ALLI,
or PFIX/IDENT1 is one of the unit's group addresses, and
the unit is attempting to call that group, and
the user wishes to receive group calls, and
the unit knows that it is not the calling unit (see below).
(Thus, if making an interprefix group call, a radio unit shall ignore GTC messages
containing the requested group address and the requested bit D unless it receives a
GTC message for the calling unit in the next slot (see a. below) and finds that it is not
the calling unit. If it is the calling unit, it obeys the individually addressed GTC
message.)
5. Otherwise (i.e. if not waiting for any call or transaction)

the unit shall obey the GTC message if:
it is individually addressed by the GTC message,

or IDENT1 is set to ALLI,
or PFIX/IDENT1 is one of the unit's group addresses
and the user wishes to receive group calls.
If the unit is required to obey the GTC command, it shall perform the following actions:
a. It shall tune to the designated forward traffic channel, obeying the following timings:
- If IDENT2 ¹ IPFIXI, the unit shall be able to receive on the traffic channel within
35 ms after the end of the GTC message.
- If IDENT2 = IPFIXI, the unit shall be able to receive on the traffic channel within
142 ms after the end of the GTC message; (this allows a called radio unit in an
interprefix call to remain on the control channel for one timeslot after receiving
GTC, to extract the caller's address if the next message is a GTC for the calling
unit).
b. It shall note PFIX, IDENT1 and IDENT2 from the GTC message and also the channel
number of the control channel (for use in obeying the procedures in sections 9.2.3.1,
9.2.3.3, 9.2.3.5, 9.2.3.6 and 9.2.3.7).
c. If bit D from the GTC message is '0', then the unit shall unmute the audio (for speech
communication). If bit D is '1', the unit shall mute the audio (for data communication)
and shall note that it need not send call maintenance messages within items (unless
required by the system by prearrangement).
d. If IDENT1 from the GTC message is ALLI and PFIX/IDENT2 from the GTC message
is not its individual address, then the unit shall inhibit user transmission on the traffic
channel. Otherwise it shall enable user transmission on the traffic channel.
It may also give an indication to the user. This may include an indication of the caller on the
called party's unit. Such an indication should be derived from any availability check
performed for the call. However if the contents of IDENT2 of the GTC message differ from
the contents of IDENT2 in the AHY availability check and are not DUMMYI or TSCI, the
indication should be derived from IDENT2 of the GTC message.

If the unit does not obey a GTC message (or, for IDENT2 = IPFIXI, a GTC message
in the next slot), and the designated traffic channel is the control channel on which the
message was received, then the unit shall return to the control channel acquisition
procedures (see 6.2.1.1).
9.2.2.6 Storing call maintenance parameters
A radio unit shall store the call maintenance parameters specified by the most recent
broadcast message BCAST, SYSDEF='00010' it has received referring to the system it is
currently using. These parameters indicate:
a. whether the system requires that a radio unit on an allocated traffic channel shall
send Pressel On messages at the start of each speech item it transmits (the number
of messages is specified in 9.2.3.1);
b. whether radio units shall send messages periodically within speech items and, if so,
the maximum interval (in seconds) between the start of the item and the first periodic
message, and then between subsequent periodic messages;
c. whether a called unit in a group shall set PFIX/IDENT1 in MAINT messages it sends
to its individual address or to the group address from the GTC message.
See also 5.5.4.2, 5.5.4.5c and 9.2.3.1. At the start of a session, until it receives a BCAST,
SYSDEF='00010' message, the unit shall:
- send Pressel On messages

- send periodic messages with a maximum interval TP
- set PFIX/IDENT1 to the group address
(when it is a called unit in a group).
9.2.3 Procedures for All Radio Units on an Allocated Traffic Channel

These procedures shall be obeyed by all radio units on an allocated traffic channel
(except when exempted by emergency call procedures agreed with the system - see
10.2.8). For other procedures for all radio units on a traffic channel, see sections:
6.2.2 Traffic channel discipline.

11.3 Instruction to send extended address information.
15.2 Data interrogation procedures.
9.2.3.1 Call maintenance messages

During a speech call (see 9.2.2.5 and 9.2.3.4), a radio unit shall send the following
call maintenance messages within speech items:
a. If required by the system (see 9.2.2.5 and 9.2.3.4), the radio unit shall send a
minimum of one Pressel On message (MAINT, OPER='000') at the start of each
speech item it transmits. If defined by the system the radio unit may send NPON
messages. When NPON is not defined it shall default to the value 1. Where more
than one message is sent the form of transmission specified in 3.3.2 shall be used.
b. If required by the system, the radio unit shall send periodic messages (MAINT,
OPER='010') within each speech item it transmits. See 9.2.2.6 for the maximum
interval between periodic messages.

c. The radio unit shall send a minimum of one Pressel Off message (MAINT,
OPER='001') at the end of each speech item it transmits, as the last signal before
retuning to the forward traffic channel. If defined by the system the radio unit may
send NPOFF messages. Where NPOFF is not defined it shall default to the value 1.
Where more than one message is sent the form of transmission specified in 3.3.2
shall be used.
PFIX/IDENT1 in MAINT messages sent by a radio unit is the unit's individual address if it
was individually addressed by the GTC message; otherwise (i.e. for a called unit in a
group), PFIX/IDENT1 shall be set to either the unit's individual address or to the group
address (PFIX/IDENT1) from the GTC message, as required by the system - see 9.2.2.5
and 9.2.2.6.
(During a data call, a radio unit needshall not send the above messages, unless
required by the system by prearrangement.)
9.2.3.2 Availability check on a traffic channel
A) If a radio unit on a traffic channel receives an AHY message with:
PFIX/IDENT1 matching its individual address and POINT = 0

or PFIX/IDENT2 matching its individual address and POINT = 1
then it shall respond with the appropriate acknowledgement (see below), with
the same prefix and idents as the AHY. If bit AD = 0 in the AHY message, the
unit shall time its response from the end of the AHY address codeword; if bit AD
= 1, a data codeword is appended and the unit shall time its response from the
end of the data codeword. For timing, see 6.2.2.2.
a. If POINT = 0, the unit shall send ACK(QUAL=0).
ACK (QUAL=0) - The unit is in radio contact.
b. If POINT = 1, the unit shall send ACK(QUAL=0) or ACKX(QUAL=0):
ACK (QUAL=0) - The unit is waiting for signalling for an Include call appropriate to
IDENT1 (i.e. IDENT1 is the called ident or gateway). See also
section 11.2.5.
ACKX (QUAL=0) - The unit is not waiting for signalling for an Include call appropriate
to IDENT1.
B) If a radio unit on a traffic channel receives an AHYP message with:

PFIX/IDENT1 matching its individual address
or PFIX/IDENT matches the group address previously transmitted in the GTC
message which directed this Radio Unit to the traffic channel
or IDENT1 = ALLI
then it shall respond with the acknowledgement ACK (QUAL=0), with the same
prefix and idents as the AHYP. For timing, see 6.2.2.2.
9.2.3.3 Disabling user transmission
If a radio unit on a traffic channel receives a call maintenance message MAINT,

OPER='111' with channel number (CHAN) equal to the number of the traffic channel and
an applicable address, then it shall inhibit user transmission while it is tuned to this traffic
channel (i.e. it shall disable the pressel for a speech call or inhibit user data for a data call).

The address (PFIX/IDENT1) from the MAINT message is applicable if:
a. PFIX/IDENT1 matches the unit's individual address, or

b. PFIX/IDENT1 is equal to PFIX/IDENT1 from the GTC message and the unit is not the
calling party, or
c. IDENT1 is equal to ALLI.
9.2.3.4 Replacement of traffic channel
If a radio unit on a traffic channel receives a GTC message with:
PFIX/IDENT2 from the GTC message matching its individual address

or PFIX/IDENT1 matching any of its designated addresses for this system
or IDENT1 set to the system-wide all-call ident ALLI
then it shall perform the following actions:
i) It shall tune to the designated forward traffic channel and shall be able to receive
within 35 ms after the end of the GTC message.
ii) If bit D from the GTC message is '0', then the unit shall unmute the audio (for speech
communication). If bit D is '1', the unit shall mute the audio (for data communication)
and shall note that it need not send call maintenance messages within items (unless
required by the system by prearrangement).
iii) If IDENT1 from the GTC message is ALLI and PFIX/IDENT2 from the GTC message
is not its individual address, then the unit shall inhibit user transmission. Otherwise it
shall enable user transmission. (See also 11.2.7c.)
When the unit has tuned to the designated traffic channel, it may continue communication.
(Note that the unit continues to use PFIX, IDENT1 and IDENT2 from the original GTC
message (see 9.2.2.5) in obeying the procedures in sections 9.2.3.1, 9.2.3.3, 9.2.3.5,
9.2.3.6 and 9.2.3.7).
9.2.3.5 Going "on-hook" on traffic channel
If a radio unit's user goes on-hook or equivalent (or if its data equipment indicates
that a data call has ended) while it is tuned to the traffic channel, and if its individual
address is either PFIX/IDENT1 or PFIX/IDENT2 from the GTC message, then the unit shall
send a number of Disconnect messages (MAINT, OPER='011') on the traffic channel. It
shall send ND1 Disconnect messages if its individual address is PFIX/IDENT1 from the
GTC, or ND2 if its individual address is PFIX/IDENT2 from the GTC. The unit shall send the
messages continuously (see 3.3.2 and 6.2.2.2) and mute the audio, and shall then return to
the control channel acquisition procedures (see 6.2.1.1).
A radio unit whose individual address is neither PFIX/IDENT1 nor PFIX/IDENT2 from
the GTC message (i.e. a called unit in a group call) may leave the call at any time when the
user goes on-hook or equivalent; it shall mute the audio and return to the control channel
acquisition procedures (without signalling). However, the calling unit sends ND2
Disconnect messages for a group call (see above), and so the caller should be advised to
remain with a group call until its completion.

9.2.3.6 Time-outs on traffic channel
A radio unit on a traffic channel shall time the length of a period during which it
detects no activity (e.g. fails to receive adequate signal strength) and shall also time the
length of each item it transmits.
If the unit detects no activity on the forward traffic channel for a time TN then it shall
assume that the call is terminated: it shall mute the audio and return to the control channel
acquisition procedures (without signalling), and may indicate to the user that the call has
ended.
If the unit transmits an item that reaches the maximum permitted duration TT then it
shall mute the audio and shall as a default:
A)
i) send NPOFF NPON Pressel Off messages (for a speech item);

ii) send ND1 or ND2 Disconnect messages if (depending on whether its individual
address is PFIX/IDENT1 or PFIX/IDENT2 in from the GTC received by the radio
unit) (as in conformance with section 9.2.3.5).
or as an alternative
B)
i) send NPOFF Pressel Off messages (for a speech item) and inhibit the user
transmission;
ii) start the inactivity timer TN;
iii) alert the user that the TT timer has expired;
iv) wait until the user releases the pressel before enabling user transmission
During the period immediately following the transmission of the Pressel Off
message, the radio unit shall be able to receive traffic channel messages (such as
CLEAR) from the TSC
It shall then cease transmission on the traffic channel and return to the control channel
acquisition procedures, and may indicate to the user that the call has ended.
9.2.3.7 "Selective" clear-down message : MAINT with OPER='110'
If a radio unit on a traffic channel receives a call maintenance message MAINT,

OPER='110' with:
channel number (CHAN) equal to the number of the traffic channel

and PFIX/IDENT1 not equal to PFIX/IDENT1 from the GTC message
and PFIX/IDENT1 not equal to PFIX/IDENT2 from the GTC message
then immediately it shall mute the audio and return to the control channel acquisition
procedures, and may indicate to the user that the call has ended.
Note:
PFIX/IDENT1 and PFIX/IDENT2 from the GTC message are used to identify the
legitimate users of that traffic channel. If the addresses of the parties engaged in
the call can be deduced by other means (e.g from the AHOY message or any
appropriate appended data codeword) then those addresses may be matched with
PFIX/IDENT from the MAINT (OPER='110) message

9.2.3.8 CLEAR message
If a radio unit on a traffic channel receives a clear-down message CLEAR with:
channel number (CHAN) equal to the number of the traffic channel

and field REVS equal to '101010101010'
then it shall immediately mute the audio and move to the forward control channel indicated
by field CONT in the CLEAR message (to be capable of receiving within 35 ms after the
end of the CLEAR address codeword), and may indicate to the user that the call has
ended.
Note: If field CONT in the CLEAR message is equal to '0000000000', then the channel
movement is system-dependent.

10. EMERGENCY CALL PROCEDURES
This section defines standardised procedures for emergency calls. (Note that
systems may have alternative emergency procedures employing customised messages,
and radio units which have suitable arrangements with the system may use these.)
Standard emergency calls from radio units may be requested to:
- a radio unit, line unit or group

- all units in the system
- a PABX extension (short or extended addressing)
- a PSTN destination (prearranged or general).
Emergency calls from radio units are requested using the Emergency Call Request
Message RQE (see 5.5.3.1.5). Bit D in the RQE message specifies whether the unit is
requesting speech or data communication. An extended addressing request is indicated by
setting IDENT1 in the RQE message to the appropriate gateway ident.
A radio unit may interrupt a non-emergency call attempt to request an emergency

call; in this case it abandons the previous call attempt. Messages ACKE(QUAL=0) and
AHY(E=1) are responses unique to RQE calls; they indicate positively that the TSC has
received the RQE and that any further signalling sent to the unit is for the emergency call.
Until it receives ACKE(QUAL=0) or AHY(E=1), the unit ignores other acknowledgements
and rejects Mode 1 AHYC messages.
Usually emergency calls will take precedence over all other calls. Emergency calls
may be pre-emptive, that is, another call may be terminated prematurely to free a channel
If bit EXT is set to '0' in the RQE message (i.e. if the RQE is not for a short
addressing PABX call) then FLAG2 may be set to '1' to indicate that the calling radio unit is
requesting a special mode of emergency service previously arranged with the system; the
TSC determines the required action by reference to the calling unit's address, and the TSC
and radio unit follow appropriate (non-standardised) procedures. In this case, the
meanings of fields IDENT1, D and FLAG1 in the RQE message may be redefined. For
example, EXT=0/FLAG2=1 could indicate that field IDENT1 contains a special 13-bit
message to be acted upon by the TSC; these special messages could have any
prearranged meaning (such as the nature of the emergency, the required service or the
unit's geographical position). See also the introductions to sections 10.1 and 10.2.

10.1 Standard Emergency Call Procedures for TSC
If the TSC offers an emergency service then it shall be prepared to accept an RQE
message in any random access slot.
The TSC procedures detailed in the following subsections are for standard
emergency calls. If, owing to incorrect operation of a radio unit, the TSC receives an RQE
message requesting a special mode of service (i.e. EXT=0/FLAG2=1) from a radio unit with
which it has no previous arrangements then it may reject the request by responding with
ACKE(QUAL=0) and then sending ACKX(QUAL=0), where both ACKE and ACKX contain
the same PFIX, IDENT1 and IDENT2 as the RQE message.
10.1.1 Responses to a short addressing standard emergency request
A radio unit requests an emergency call by generating an RQE message, complying

with the random access protocol (unless it has other arrangements with the system). On
receiving a short addressing RQE message, the TSC shall send a response as soon as
possible; for maximum permissible delay, see 7.2.4. Valid responses are:
a. ACKE(QUAL=0); see 5.5.2.1 and 10.2.2.
b. An availability check for the call (AHY with bit E set to '1'); see 9.1.1.5, 9.1.1.7 and
10.2.2.
c. For a non-PABX call (i.e. EXT=0 in the RQE message):

- A Go To Channel message GTC for the call; see 9.1.1.12 and 10.2.2.
(This is the recommended response if the TSC does not make any availability
checks for the call - see 10.1.6.)
ACKE(QUAL=0) is sent only as a response to an RQE message; it is an intermediate

acknowledgement, indicating that further signalling will follow. The TSC may then send
other acknowledgements (e.g. ACKI, ACKX) to the waiting calling unit at appropriate times
to indicate the progress of the call set-up; see section 10.1.5.
10.1.2 Response to an extended addressing standard emergency request
A radio unit requests an emergency call by generating an RQE message, complying

with the random access protocol (unless it has other arrangements with the system). On
receiving an extended addressing RQE message, the TSC shall send a response:
ACKE(QUAL=0) with the same prefix and idents as the RQE. For maximum permissible
delay, see 7.2.4.
10.1.3 Signalling for previous call
After receiving an RQE message, the TSC shall not send any further signalling
messages to the calling unit for any previous call requested by that unit (though, for a traffic
channel call, it may send AHYX to inform a called radio unit that the call will not take place).

10.1.4 Obtaining extended address information
After receiving an extended addressing RQE message and responding with

ACKE(QUAL=0), the TSC may demand the full called address information from the calling
radio unit by sending the AHYC message (as in section 9.1.1.3).
10.1.5 Acknowledgements sent to indicate progress of emergency call
After sending ACKE(QUAL=0) or an availability check AHY with E=1 as a response

to an emergency call request, the TSC may send acknowledgements ACKI, ACKQ, ACKX,
ACKV, ACKB(QUAL=0) or ACKT(QUAL=0) to the calling unit to indicate the progress of the
call (as in section 9.1.1.4).
10.1.6 Availability checks before allocating traffic channel
For emergency calls, the mandatory availability check detailed in section 9.1.1.5 may
be dispensed with. (For emergency calls, availability checks on radio units are made using
the AHY message with bit E set to '1'.)
10.1.7 TSC time-out
The TSC may instruct the calling unit to restart its waiting timer TW, by sending the
AHY message with bit POINT set to '1' (and bit E set to '1'); see 9.1.1.7 and 9.2.2.3. If a
time TW, minus the tolerance on the radio unit's timer, elapses since the last message it
received for an emergency call (from the calling unit), the TSC shall not send any further
signalling for the call, except that it may send AHYX to inform a called radio unit that the
call will not take place. See also 10.2.7.
10.1.8 Other procedures
a. A calling radio unit may send an RQX message to cancel its emergency call. The
TSC procedures are as defined in 9.1.1.8 for Simple calls.
b. It is recommended that the TSC does not amalgamate an emergency call with any
other call in its queues.
c. If all traffic channels are in use then the TSC may terminate another call prematurely
(with or without warning to the correspondents using it), in order to free the channel
d. The procedures for traffic channel allocation and call maintenance and clear-down
are as detailed in 9.1.1.12 and 9.1.2.

10.2 Standard Emergency Call Procedures for Radio Units
A radio unit shall make only one emergency call attempt at a time. While attempting
access or waiting for further signalling for an emergency request, the unit shall not request
another call of any type (unless the user first cancels the original call). It may make an
emergency call at any other time. For example, it may interrupt a non-emergency call
attempt to request an emergency call; in this case it shall abandon the previous call attempt
(without sending RQX).
The radio unit procedures detailed in the following subsections are for standard
emergency calls. If a radio unit sends an RQE message with EXT=0/FLAG2=1 then it is
requesting a special mode of emergency service previously arranged with the system and
generally follows non-standardised procedures; however, if it receives ACKE(QUAL=0) and
subsequently receives ACKX(QUAL=0) - both with the same PFIX, IDENT1 and IDENT2 as
its RQE - then it shall return to the idle state (and may indicate to the user that the call
attempt has failed).
10.2.1 Request for a standard emergency call
A radio unit requests a standard emergency call by sending an RQE message on a

control channel; the fields in the RQE message shall be set appropriately (see 5.5.3.1.5).
Some TSCs may permit more than one emergency random access transmission in a frame;
however, unless the radio unit knows the retry rate permitted by the TSC, it shall comply
with the normal random access protocol - see 7.3. (Note that a radio unit requesting an
emergency call ignores all values of the address qualifier except M=20 - see 7.3.1.)
The unit shall attempt access until it receives a valid response (see 10.2.2/3), or until
its user cancels the call (see 10.2.8), or until the access attempt fails (i.e. the unit has sent
the maximum number of transmissions NE and received no response, or its access time-
out TC has expired (see 7.3.8)). In the case of access failure, if the unit has not sent a
request, it shall return to the idle state (and may indicate the failure to the user); otherwise,
it shall wait for further signalling for the call - see 10.2.4 to 10.2.7.
10.2.2 Responses to short addressing RQE
For a short addressing call, the calling unit shall accept the following messages (with
PFIX/IDENT2 as its individual address and IDENT1 as the called ident (or PABXI for a
PABX call)) as a valid response to its RQE and send no more requests:
a. An acknowledgement ACKE(QUAL=0).
b. An AHY message with bit E set to '1'.
c. For a non-PABX call (i.e. EXT=0 in the RQE message):

- a Go To Channel message GTC with bit D equal to bit D from the RQE message.
In cases a. and b., the unit shall then wait for further signalling for the call. See also
sections 10.2.6, 9.2.2.3 and 9.2.2.5.

10.2.3 Responses to extended addressing RQE
For an extended addressing call, the calling unit shall accept an acknowledgement
ACKE(QUAL=0) or an AHY(E=1) message (with the same prefix and idents as the RQE) as
a response to its RQE and send no more requests; it shall then wait for further signalling for
the call. See also 9.2.2.3.
10.2.4 Sending extended address information
For an extended addressing emergency call, after receiving ACKE(QUAL=0) or an

AHY(E=1) message for its call, the calling unit shall send the full called address information
on receipt of an appropriate AHYC; see section 9.2.2.1. Until it receives ACKE(QUAL=0) or
AHY(E=1), the unit shall respond to Mode 1 AHYC messages with ACKX(QUAL=0).
10.2.5 Acknowledgements indicating progress of emergency call
After receiving ACKE(QUAL=0) or an AHY(E=1) message for its emergency call, the
waiting calling unit shall take appropriate action on receiving further acknowledgements -
ACKI, ACKQ, ACKX, ACKV, ACKB(QUAL=0) or ACKT(QUAL=0) - as detailed in section
9.2.1.4.
If it receives ACKE(QUAL=0) for the call then the unit shall wait for further signalling.
10.2.6 Availability check and channel allocation for own call
A calling radio unit attempting access or waiting for further signalling for an
emergency call shall obey the availability check procedures (see 9.2.2.2 to 9.2.2.4).
The unit shall also obey the traffic channel allocation procedures (see 9.2.2.5). Note
particularly that:
a. If the unit has not received ACKE(QUAL=0) or AHY(E=1) for its emergency call, it
shall obey a GTC message only if its call is a short addressing non-PABX call and
the GTC message is for the requested call (see below).
b. After receiving ACKE(QUAL=0) or AHY(E=1) for its emergency call, the unit shall
obey a GTC message only if it is individually addressed by the GTC (i.e. if its
individual address is PFIX/IDENT1 or PFIX/IDENT2).
See section 9.2.2.5, rule 1.
For a short addressing non-PABX call or after receiving ACKE(QUAL=0) or

AHY(E=1) for a short addressing PABX call or after sending the full address information for
an extended addressing call, the unit shall assume that a GTC message it receives is for its
requested call if PFIX/IDENT2 is its individual address, IDENT1 is the called ident (or
gateway) and bit D is the same as in the RQE. If so, it may give an indication to the user,
and shall revert to the idle state at the end of the call.

10.2.7 Time-out after waiting
A calling radio unit waiting for further signalling for an emergency call shall return to
the idle state if a time TW has elapsed since the last message it sent for the call, viz.
RQE, requesting the emergency call (see 10.2.1)

or ACK(QUAL=0), sent in response to an AHY message with POINT = 1, E = 1 and
IDENT1 as the called ident or gateway (see 9.2.2.3).
It may also indicate the failure to the user.
a. A calling radio unit waiting for an emergency call may attempt to cancel the call by
sending a call cancellation request RQX. The procedures are as defined in 9.2.1.7
for cancelling Simple calls.
b. The procedures on an allocated traffic channel are as defined in 9.2.3 (unless other
arrangements have been made with the system).

11. INCLUDE CALL PROCEDURES
During an RQS or RQE call, a radio unit on its allocated traffic channel may send a
request message RQS to the TSC, to ask for a party to join the call in progress. This
facility may be used to implement:
a) a Conference Call - a user on channel may ask for the call to be expanded to
include another party;
b) Call Transfer - a user may include another party in the call, and then leave
the call to proceed without him;
c) a Repeat Call - a user may ask for the channel assignment signalling for
the call to be retransmitted.
The Included party may be a radio unit, a line unit, a group of units, a PABX extension
(short or extended addressing) or a PSTN number (short-form or general).
A radio unit requests an Include call by transmitting a request message RQS on the
allocated traffic channel. (An extended addressing request is indicated by setting IDENT1
in the RQS message to the appropriate gateway ident.) The TSC responds and, for an
extended addressing request, instructs the Including unit to transmit the full called party
details. It then checks the availability of the called party (if appropriate) and directs the
called party to the traffic channel. Throughout the transaction, the TSC may send
acknowledgements to the Including unit to indicate the progress and the success/failure of
the transaction.
When a user initiates an Include call, his pressel is disabled until the radio unit
receives an acknowledgement other than ACKI(QUAL=1) or until it times out.
After a party has been included in a call, the TSC may allow units to leave the call,
without terminating the call, provided that the number of parties that will indicate the "on-
hook" condition is not reduced below the normal number for the type of call.
The timing constraints for messages transmitted on a traffic channel are specified in
sections 6.1.2.2 and 6.2.2.2.

11.1 TSC Procedures for Include Calls
This subsection defines procedures for TSCs that offer the Include facility.
11.1.1 Responses to a short addressing Include request
A radio unit requests a short addressing Include call by transmitting an RQS

message (with EXT = 1, or with EXT = 0 and IDENT1 set to a valid called party ident) on
the traffic channel. On receiving a short addressing Include RQS, the TSC shall send a
response:
ACKI, ACKQ(QUAL=0), ACKX, ACKV, ACKT(QUAL=0) or ACK(QUAL=0).
For idents, see section 5.5.2.1; for acceptable delay, see 6.1.2.2.
These acknowledgement messages may also be sent to the unit to indicate the
progress of its Include call - see section 11.1.4.
11.1.2 Responses to an extended addressing Include request
A radio unit requests an extended addressing Include call by transmitting an RQS

message (with EXT = 0 and IDENT1 = IPFIXI, PABXI or PSTNGI) on the traffic channel.
On receiving an extended addressing Include RQS, the TSC shall send one of the following
responses, with the same prefix and idents as the Include RQS:
For acceptable delay, see 6.1.2.2. See also 11.1.3 and 11.1.4.
11.1.3 Instruction to send extended address information
After receiving an extended addressing Include RQS, the TSC may demand the full
called address by sending the AHYC message, with:
- the same prefix and idents as the Include RQS

- DESC set to indicate the appropriate gateway (see 5.5.3.2.8)
- SLOTS set to correspond to the Include RQS
(i.e. if IDENT1=PSTNGI and FLAG1=1 then SLOTS='10' else SLOTS='01').
The AHYC message instructs the Including radio unit to send the called party address
information (see 11.3.1). If the TSC does not successfully decode the address information,
it may repeat the AHYC message or transmit ACKV(QUAL=0) to indicate failure of the
Include call.
appropriate acknowledgements to the Including unit (see 11.1.4).

11.1.4 Acknowledgements sent to indicate progress of Include call
The TSC may send acknowledgement messages to indicate to a radio unit the
progress of its Include call - for idents, see 5.5.2.1. (For extended addressing Include calls,
only ACKI(QUAL=1), ACKX and ACKV(QUAL=0) are appropriate until the full address
information has been obtained.)

ACKX (QUAL=1) - System overload e.g. all channels in use on called site, and call
has not been queued.
ACKV (QUAL=1) - Conflicting call in progress (e.g. called party engaged) or called
ACK (QUAL=0) - Include request accepted; availability check successful (if
performed); called party will be directed to the traffic channel.
For maximum acceptable delay of repeats of acknowledgements ACKX, ACKV, ACKT and
ACK, see time-out TB in section 11.2.4.
11.1.5 Availability check on called radio unit
If an Include request specified an individual radio unit to be Included, the TSC may
check the availability of the called unit before instructing it to join the call in progress.
The TSC checks availability of a called radio unit by sending the AHY message on a
control channel (see 5.5.3.2.1 and 9.2.2.2A). For an Include call availability check, IDENT2
in the AHY address codeword is set to INCI (to prohibit the called unit from responding with
ACKB(QUAL=0)) and a data codeword may be appended containing the Including unit's
address.
The TSC may indicate the result of the availability check to an Including radio unit by
sending appropriate acknowledgement(s) (see 11.1.4) on the traffic channel.
11.1.6 Call cancellation
A radio unit may cancel its requested Include call by transmitting an RQX message
(see 5.5.3.1.3) on the traffic channel. On receiving an RQX message cancelling an Include
call, the TSC shall respond with ACK(QUAL=0) or ACK(QUAL=1), with the same prefix and
idents as the RQX; see also 11.1.4 and 11.2.6.
If an Include call is cancelled, the TSC may inform a called radio unit by sending the
AHYX message (with IDENT2 set to INCI) on the control channel. The AHYX message
may be repeated if it is not acknowledged by an ACK(QUAL=1) message from the called
unit (see 9.2.2.4).

11.1.7 TSC time-out
The TSC may instruct an Including radio unit to restart its waiting timer TI, by sending
the AHY message with:

- PFIX/IDENT2 set to the unit's individual address
- IDENT1 set to the called ident or gateway.
See 9.1.2.2 and 9.2.3.2. If a time TI, minus the tolerance on the radio unit's timer, elapses
since the last message it received for an Include call (from the Including unit), the TSC shall
not send any further signalling for the transaction, except that it may send AHYX on the
control channel to inform a called radio unit. See also 11.2.5.
11.1.8 Traffic channel allocation
The TSC shall direct a called radio unit or group of radio units to the appropriate
traffic channel using the Go To Channel message GTC (with IDENT2 set to INCI); see
section 5.4.
11.1.9 Call clear-down
After an Include call, the TSC may allow parties to leave the call in progress, without
terminating the call, as follows:
i) For a group call or a call in which a group has been included, the TSC may allow
radio units to signal on-hook (or line/PABX/PSTN users to leave the call), without
terminating the call, provided that at least one party that will indicate end-of-channel-
use remains in the call.
ii) For a call comprising only individually addressed parties, the TSC may allow radio
units to signal on-hook (or line/PABX/PSTN users to leave the call), without
terminating the call, provided that at least two parties remain in the call.
In this way, at least the normal number of parties that will indicate end-of-channel-use
remains in a call (barring corruption of signalling messages). See also section 9.1.2.6.

11.2 Procedures for Radio Units Requesting Include
A radio unit on a traffic channel shall request only one transaction at a time; while
requesting an Include call or waiting for further signalling, the unit shall not request another
transaction of any type (unless the user first cancels the Include call).
11.2.1 Include request
When a user initiates an Include call (indicating that he wishes another party to join
the call in progress), the radio unit shall inhibit user transmission i.e.
- disable the pressel for a speech call, or
- inhibit user data for a data call.
The radio unit requests an Include call by transmitting RQS on the allocated traffic
channel. The fields in the RQS message shall be set appropriately (see 5.5.3.1.1);
however, note particularly that:
a. If the call in progress is a speech call (see 9.2.2.5 and 9.2.3.4), bit DT shall be set to
'0'; for a data call, DT shall be set to '1'.
b. Bit LEVEL shall be set to '1'.
(This constraint is imposed to prevent the RQS being interpreted
as an AHY to the called party).
c. An extended addressing request is indicated by setting IDENT1 in the RQS message
to the appropriate gateway (viz. IPFIXI, PABXI or PSTNGI).
After transmitting an Include request message on a traffic channel, the unit shall wait
to receive a response from the TSC. If a response is not received within the timing
constraints defined in section 6.2.2.2, the unit shall assume that the message was
unsuccessful and may retransmit its request. It shall repeat its Include request, each time
waiting for a response from the TSC, until:
i) it receives a valid response (see 11.2.2/3), or
ii) its user cancels the Include call (see 11.2.6), or
iii) it has sent the maximum number of transmissions NI.

In this case, it shall wait for further signalling for the Include call (see 11.2.4 and
11.2.5).
11.2.2 Responses to short addressing Include request
For a short addressing Include RQS, the radio unit shall accept the following
messages as a valid response to its RQS and send no more requests:
a. ACKI, ACKQ(QUAL=0), ACKX, ACKV or ACK(QUAL=0), with PFIX/IDENT2 as its

individual address and IDENT1 as the called ident (or PABXI for a PABX call).
b. ACKT(QUAL=0) with PFIX/IDENT2 as its individual address.
c. An AHY message with PFIX/IDENT2 as its individual address, POINT=1 and IDENT1
as the called party or gateway

For other actions on receiving these messages, see section 11.2.4.
11.2.3 Responses to extended addressing Include request
For an extended addressing Include RQS, the radio unit shall accept the following
messages (with the same prefix and idents as the RQS) as a valid response to its RQS and
send no more requests:
For other actions on receiving these messages, see 11.2.4 and 11.3.1.
11.2.4 Acknowledgement received
If a radio unit waiting for a response to an Include RQS, or for further signalling for an
Include call, receives an appropriate acknowledgement then it shall take action as indicated
below. For extended addressing Include calls, only ACKI(QUAL=1), ACKX and
ACKV(QUAL=0) are appropriate until the full address information has been sent. For
idents, see 5.5.2.1.

ACKV (QUAL=1) - Conflicting call in progress (e.g. called party engaged) or called
ACK (QUAL=0) - Include request accepted; called party will be directed to the traffic
channel.
If ACKI or ACKQ(QUAL=0) is received, the unit shall wait for further signalling.
However, for a speech call, it may re-enable the pressel on receiving ACKI(QUAL=0) or
ACKQ(QUAL=0).
If ACKX or ACKV is received, the unit shall re-enable user transmission and may
indicate to the user that the Include call has failed.
a. re-enable user transmission (and may indicate to the user that the called party's calls
have been diverted), or
b. attempt a new Include call to the diversion address.
If an incomplete ACKT(QUAL=0) message is received, then:

i) If the unit does not require the diversion address, it shall re-enable user transmission
(and may give an indication to the user).

- if it has received no previous response to its Include RQS, and has not
sent the maximum number of transmissions of the RQS (see 11.2.1), it
shall ignore the ACKT message;
- otherwise it shall wait for a repeat ACKT, re-enabling user transmission if
a time TB elapses (in which case, it may indicate the failure to the user).
If ACK(QUAL=0) is received, the unit shall re-enable user transmission and may
indicate to the user that the called party is being directed to the traffic channel.
After receiving ACKX, ACKV or ACK for its Include call, the unit shall not request on
the traffic channel another transaction of any type to the same called ident (or gateway) for
at least a time TB. After receiving ACKT for its Include call, the unit shall not request on
the traffic channel another transaction of any type for at least a time TB.
11.2.5 Time-out after waiting for Include call
A radio unit waiting for further signalling for an Include call shall re-enable user
transmission if a time TI has elapsed since the last message it sent for the transaction, viz.
RQS, requesting the Include call (see 11.2.1)

or SAMIS, providing extended address information for the call (see 11.3.1)
or ACK(QUAL=0), sent in response to an AHY message with bit POINT = 1 and IDENT1
as the called ident or gateway (see 9.2.3.2).
It may also indicate to the user that the outcome of the transaction is unknown.
11.2.6 Cancelling Include
A radio unit may cancel an Include request (after sending an RQS and while still
waiting to receive ACKX, ACKV, ACKT or ACK) by transmitting a cancellation request
RQX (see 5.5.3.1.3) on the traffic channel. The unit shall then wait for a response from
the TSC; for timing, see 6.2.2.2. The unit shall repeat its cancellation request, each time
waiting for a response from the TSC, until one of the following occurs:
a. It receives ACK(QUAL=1), with the same prefix and idents as the RQX, confirming
cancellation of the Include call.
b. It receives ACKX, ACKV, ACKT(QUAL=0) or ACK(QUAL=0) for the Include call it is

attempting to cancel. See also 11.2.4.
c. It has sent the maximum number of transmissions NI. In this case, it shall return to
waiting for signalling for the Include call (see 11.2.4 and 11.2.5).
In cases a. and b., the unit shall re-enable user transmission.

a. A radio unit shall not attempt an Include call if user transmission has been inhibited
(by the GTC message or by a MAINT(OPER='111') message; see 9.2.2.5, 9.2.3.3
and 9.2.3.4).
b. If a radio unit requesting or attempting to cancel an Include call, or waiting for further
signalling, receives a MAINT(OPER='111') message inhibiting user transmission
(see 9.2.3.3), then it shall continue with the Include call but shall not re-enable user
transmission at the end of the transaction.
c. If a radio unit requesting or attempting to cancel an Include call, or waiting for further
signalling, receives a GTC message allocating a replacement traffic channel, it shall
perform actions i) and ii) as specified in section 9.2.3.4 and shall then continue with
the Include call. At the end of the transaction, the unit shall re-enable user
transmission only if permitted by action iii) of 9.2.3.4.
d. If a radio unit's user goes on-hook (or equivalent) while it is requesting or attempting
to cancel an Include call, or waiting for further signalling, then the unit shall abandon
the Include call and shall obey the procedures specified in section 9.2.3.5.
(If the user goes on-hook (or equivalent) after an Include call, then the unit shall
obey the procedures specified in section 9.2.3.5. However, see also section 11.1.9.)
e. If a radio unit requesting or attempting to cancel an Include call, or waiting for further
signalling, receives a MAINT(OPER='110') or CLEAR message terminating the call
in progress, then it shall abandon the Include call and shall obey the procedures
specified in sections 9.2.3.7 and 9.2.3.8 respectively.

11.3 Procedures for All Radio Units on an Allocated Traffic
Channel
extended addressing Include calls.
If a radio unit on a traffic channel receives an AHYC message with PFIX/IDENT2

matching its individual address then it shall either send address information or transmit
ACKX(QUAL=0), as indicated below. For timing, see section 6.2.2.2.
If
the unit has sent an extended addressing Include RQS
and IDENT1 matches IDENT1 from the Include RQS
and SLOTS corresponds to the Include RQS
(i.e. if IDENT1=PSTNGI and FLAG1=1 then SLOTS='10', else SLOTS='01')
then it shall transmit the full called address information, conforming to the codeword
formats defined in section 5.6.1.2.2 (SAMIS, Mode 1).
Otherwise

12. CALL DIVERSION PROCEDURES
This section defines the procedures for requesting and cancelling call diversion.
Requests may apply to speech calls, data calls or both.
Two types of call diversion are provided:
i) Self-initiated diversion.
A radio unit may request that future calls addressed to it be redirected to a specified
alternative destination.
ii) Third-party diversion.

A radio unit may request that future calls addressed to another subscriber unit (or
group) be redirected to a specified alternative destination. For example, a
despatcher unit may request diversion on behalf of a radio unit in its fleet.
In general, radio unit A (the requesting unit) may divert calls for address B (the blocked
address) to alternative destination C (the diversion address); for self-initiated diversion,
B = A. The procedures permit blocked address B to be a radio unit, line unit or group
address. Destination C may be a radio unit, line unit or group address, a PABX extension
or a PSTN number (short-form or general).
Three types of call diversion cancellation are provided:
i) Self-initiated cancellation.
A radio unit may request that its calls are no longer diverted.
ii) Third-party cancellation.

A radio unit may request that another subscriber unit's (or group's) calls are no longer
diverted.
iii) General cancellation by recipient.

A radio unit may request that any existing diversions to it be cancelled. (This is a
general cancellation by the recipient of diversions; specific cancellation of diversions
by the recipient is covered by third-party cancellation.)
It is recommended that requests for third-party diversion or third-party cancellation

are accepted only from authorised units.
Call diversion is requested or cancelled using the Request Call Diversion Message
RQT (see 5.5.3.1.4). In this message:
- PFIX/IDENT2 is the address of the requesting radio unit.
- For diversion requests, IDENT1 is the diversion ident C

(or IPFIXI, PABXI or PSTNGI for an interprefix address, any PABX extension or a
general PSTN number respectively).
For "self" or "third-party" cancellation of call diversion, IDENT1 specifies the unit or
group whose calls should be returned (or IPFIXI for an interprefix address).
For general cancellation by a recipient, IDENT1 is set to DIVERTI.

- Bit DIV indicates call diversion or cancellation.
- For call diversion, FLAG2 indicates "self" or "third-party" diversion.
- Field SD specifies the types of call (i.e. speech, data or both) to which the diversion
or cancellation refers.
For diversion purposes, "speech" calls are defined as calls requested using
RQS(DT=0), RQE(D=0), RQQ(STATUS='00000') or RQQ(STATUS='11111'). "Data"
calls are defined as calls requested using RQS(DT=1), RQE(D=1), RQQ('00001' to
'11110'), RQC or RQD.
For self-initiated diversion requests or any cancellation, two addresses (plus the other
parameters) specify the requirement. However, for third-party diversion requests, address
B (the blocked address) must be supplied.
The TSC uses the AHYC message to demand:
a. extended address information for IDENT1

b. blocked address B
as appropriate. If both a. and b. are needed, the TSC obtains the full information in two
steps, each step using the AHYC message. The AHYCs are distinguished by the setting of
IDENT1 (to IPFIXI, PABXI or PSTNGI for a., or to DIVERTI for b.), and so the order in which
they are sent is not prescribed.
In the procedures, a request for call diversion or cancellation is defined as an

extended addressing request if IDENT1 is set to IPFIXI, PABXI or PSTNGI. A request is
defined as "complex" if it requires extended addressing or if three addresses must be
provided; otherwise it is "simple".
Note that extended addressing procedures are used for requesting diversion to any
PABX extension (with either a "long" or "short" extension number). The radio unit sets
IDENT1 in the RQT message to PABXI, and then sends the PABX address information in
response to an AHYC message with IDENT1 set to PABXI and DESC set to '010'. The unit
sets bit SP in the SAMIS message to indicate whether it is sending BCD digits or a 13-bit
extension number (plus 2-bit exchange number). See 5.5.3.2.8 and 5.6.1.2.2.
If the TSC accepts a diversion request and then a call to the blocked address is
requested by a radio unit, the TSC indicates the diversion address to the calling radio unit
using the ACKT(QUAL=0) acknowledgement. The unit then either retries on the diversion
address or returns to the idle state. For example, see sections 9.1.1.4 and 9.2.1.4.

12.1 TSC Procedures for Call Diversion Requests
12.1.1 Responses to a simple diversion request
A radio unit requests simple call diversion by generating an RQT message (with
FLAG2 = 0 and IDENT1 set to a valid called party ident or to DIVERTI), complying with the
random access protocol. On receiving a simple RQT message, the TSC shall send one of
the following responses, with the same prefix and idents as the RQT:
ACKI(QUAL=1), ACKX, ACKV(QUAL=0) or ACK(QUAL=0).
For acceptable delay, see 7.2.4. See also 12.1.5.
12.1.2 Responses to a complex diversion request
A radio unit requests complex call diversion by generating an RQT message (with
FLAG2 = 1 and/or IDENT1 = IPFIXI, PABXI or PSTNGI), complying with the random access
protocol. On receiving a complex RQT message, the TSC shall send one of the following
responses:
a. An acknowledgement ACKI(QUAL=1), ACKX or ACKV(QUAL=0), with the same

prefix and idents as the RQT.
b. For an extended addressing RQT:

An AHYC message instructing the unit to send the full address information for
IDENT1.
c. For a request for 3-address diversion (i.e. RQT with FLAG2=1):

An AHYC message instructing the unit to send the blocked address.
For acceptable delay, see 7.2.4. See also 12.1.3 to 12.1.5.
After receiving an extended addressing RQT message, the TSC may demand the full
address information for IDENT1 by sending the AHYC message, with:
- the same prefix and idents as the RQT

(i.e. IDENT1 set to IPFIXI, PABXI or PSTNGI as appropriate, and PFIX/IDENT2
set to the requesting unit's address)
- SLOTS set to correspond to the RQT
The AHYC message instructs the requesting radio unit to send the full address information
for IDENT1 in the following SLOTS slot(s) (see 9.2.2.1). If the TSC does not successfully
decode the address information, it may repeat the AHYC message or transmit
ACKV(QUAL=0) to indicate failure of the transaction.

12.1.4 Instruction to send the blocked address
After receiving a request for 3-address diversion (i.e. FLAG2=1), the 0TSC may
demand the blocked address by sending the AHYC message, with:
- IDENT1 set to DIVERTI

- PFIX/IDENT2 set to the requesting unit's address
- DESC set to '000'
- SLOTS set to '01'.
The AHYC message instructs the requesting radio unit to send the blocked address in the
following slot (see 9.2.2.1). If the TSC does not successfully decode the address
information, it may repeat the AHYC message or transmit ACKV(QUAL=0) to indicate
failure of the transaction.
12.1.5 Acknowledgements sent to indicate progress of RQT transaction
The TSC may send the following acknowledgement messages, with the same prefix
and idents as the RQT, to indicate to a radio unit the progress of its diversion transaction.
(For a complex diversion request, ACK(QUAL=0) is not appropriate until the full diversion

ACKX (QUAL=0) - Invalid call e.g. unauthorised diversion request, or TSC does not
provide call diversion.
For maximum acceptable delay of repeats of acknowledgements ACKX, ACKV and ACK,
see time-out TB in 12.2.4.
12.1.6 Aborting the transaction
A radio unit may abort its diversion transaction by generating an RQX message (see
5.5.3.1.3), complying with the random access protocol. On receiving an RQX message
aborting a diversion transaction, the TSC shall send a response: ACK(QUAL=1) with the
same prefix and idents as the RQX.
12.1.7 TSC time-out
message with bit POINT set to '1' (and the same prefix and idents as the RQT); see 9.1.1.7
and 9.2.2.3. If a time TJ, minus the tolerance on the radio unit's timer, elapses since the
last message it received for a diversion transaction, the TSC shall not send any further
signalling for the transaction. See also 12.2.5.

12.2 Procedures for Radio Units Requesting Call Diversion
attempting access or waiting for a terminating (i.e. end-of-transaction) acknowledgement to
a diversion request, the unit shall not request another non-emergency call of any type
(unless the user first aborts the original transaction).
12.2.1 Diversion request
A radio unit requests or cancels call diversion by transmitting an RQT message on a

control channel, complying with the random access protocol (see 7.3). The fields in the
RQT message shall be set appropriately (see 5.5.3.1.4); however, note particularly that:
a. Bit DIV specifies whether the unit is requesting call diversion or cancellation of call
diversion.
b. Bit FLAG2 specifies whether or not three addresses must be provided.
c. An extended addressing diversion request is indicated by setting IDENT1 in the RQT

message to the appropriate gateway ident viz. IPFIXI, PABXI or PSTNGI. (Note that
extended addressing procedures are used for requesting diversion to a PABX
extension with either a "short" or "long" extension number.)
its user aborts the transaction (see 12.2.6), or until the access attempt fails (i.e. the unit has
sent the maximum number of transmissions NR and received no response, or its access
time-out TC has expired (see 7.3.8)). In the case of access failure, if the unit has not sent
a request, it shall return to the idle state (and may indicate the failure to the user);
otherwise, it shall wait for further signalling for the transaction - see 12.2.4 and 12.2.5.
12.2.2 Responses to simple diversion request
For a simple diversion request, the radio unit shall accept the following messages
(with the same prefix and idents as the RQT) as a valid response to its RQT and send no
more requests:
ACKI(QUAL=1), ACKX, ACKV(QUAL=0) or ACK(QUAL=0).
For other actions on receiving these messages, see section 12.2.4.
12.2.3 Responses to complex diversion request
For a complex diversion request, the radio unit shall accept the following messages
as a valid response to its RQT and send no more requests:
a. ACKI(QUAL=1), ACKX or ACKV(QUAL=0), with the same prefix and idents as the
RQT.
b. For an extended addressing RQT:

AHYC, with the same prefix and idents as the RQT.

c. For a request for 3-address diversion (i.e. RQT with FLAG2=1):
AHYC, with PFIX/IDENT2 as its individual address and IDENT1 as DIVERTI.
For other actions on receiving these messages, see 12.2.4 and 9.2.2.1.
If a radio unit attempting access or waiting for further signalling for a diversion
transaction receives an appropriate acknowledgement (with the same prefix and idents as
the RQT) then it shall take action as indicated below. For a complex diversion request,
ACK(QUAL=0) is not appropriate until the full diversion information has been sent.

If ACKI(QUAL=1) is received, the unit shall wait for further signalling for the
transaction.
If ACKX or ACKV(QUAL=0) is received, the unit shall return to the idle state and may
indicate to the user that the transaction has failed.
If ACK(QUAL=0) is received, the unit shall return to the idle state and may indicate to
the user that the request for call diversion or cancellation has been accepted.
After receiving ACKX, ACKV or ACK for its diversion request, the unit shall not
request another non-emergency call of any type to the same called ident (or gateway) for at
least a time TB.
A radio unit waiting for further signalling for a diversion transaction shall return to the
idle state if a time TJ has elapsed since the last message it sent for the transaction, viz.
RQT, requesting the transaction (see 12.2.1)

or SAMIS, providing address information for the call (see 9.2.2.1)
or ACK(QUAL=0), sent in response to an AHY message with bit POINT = 1 and the same
prefix and idents as the RQT (see 9.2.2.3).

A radio unit may abort a diversion transaction (after sending an RQT and while still
waiting to receive ACKX, ACKV or ACK) by transmitting an abort transaction request RQX
(see 5.5.3.1.3), complying with the random access protocol. It shall attempt access until
one of the following occurs:
a. It receives ACK(QUAL=1) with the same prefix and idents as the RQX. In this case,
it may indicate to the user that the outcome of the transaction is unknown.
b. It receives ACK(QUAL=0), ACKX or ACKV(QUAL=0) for the transaction it is

attempting to abort. See also 12.2.4.
c. It has sent the maximum number of transmissions NR and received no response, or

for signalling for the diversion transaction (see 12.2.4 and 12.2.5).
In cases a. and b., the unit shall return to the idle state.

13. STATUS MESSAGE PROCEDURES
This section defines the procedures for status messages. Status messages may be
sent to the TSC or to a radio or line unit.
A radio unit sends status information using message RQQ - see 5.5.3.1.7. The
status field in an RQQ message consists of 5 bits, allowing 32 different status values. Two
of these values have been predefined.
a) For status sent to the TSC:
'00000' indicates that the unit is ready to receive a call (i.e. it indicates "off-
hook" or equivalent).
'00001' to '11110' are system-defined status values.
'11111' indicates that the unit is no longer ready to receive a call (i.e. it
indicates "on-hook" or equivalent).
RQQ('00000') and RQQ('11111') are used for the "Called Party Answer" mechanism -
see section 9.2.2.2. If a radio unit receives AHY(CHECK=1) alerting it for an
incoming call and responds with ACKI(QUAL=0), it may attempt random access with
RQQ('00000') when its user/ data equipment is ready to receive the call. Then, if the
user no longer wishes to receive the call, the unit may inform the TSC using
RQQ('11111').
The other 30 status values may be used to send status information, as previously
arranged with the system.
b) For status sent to a radio unit or line unit:
'00000' requests that the addressed unit call back with a speech call.
'00001' to '11110' are user-defined status values.
'11111' cancels a previous speech call request.
For example, RQQ('00000') may be used to request a "despatcher-queued call". In

this type of call, a radio unit sends RQQ('00000') to request that the addressed
despatcher be informed that the unit's user wishes the despatcher to call him (for a
speech call). The TSC routes the information to the despatcher unit, which keeps a
list of requested calls. The despatcher may then request each call at his
convenience in the usual way; for example, if his unit is a radio unit, it sends a Simple
call request RQS (see 5.5.3.1.1 and 9.2.1).
RQQ('11111') is used to withdraw a previously requested call from the addressed

unit's call queue. This may be used for cancellation either:
i) after the called unit has accepted an RQQ('00000') message, or

ii) after the called unit in an RQS or RQE call has accepted the call for call-
back (by sending ACKB(QUAL=0) in response to the availability check); see
9.2.1.4 and 9.2.2.2.

The other 30 status values may be used to send status information, as previously
agreed between the requesting user and the called user.
The TSC informs a called radio unit of status information using message AHYQ - see
5.5.3.2.7. The status message may have originated from the TSC itself, from another radio
unit (using RQQ etc.) or from a line unit.
The procedures for status messages addressed to the TSC are similar to a subset of
the procedures for status messages addressed to radio units or line units. However, for
clarity, they are specified separately:
- Section 13.1 specifies the procedures for status messages addressed to the TSC.
- Section 13.2 specifies the procedures for status messages addressed to radio units
or line units.
A typical message sequence for a radio unit sending a status message to another
radio unit (with the same prefix) is illustrated in the example below.
1 slot
<---->
1 3
TSC to RUs ALH ALH AHYQ ALH ACK ACK
(1) (1) (1)
2 4
RUs to TSC RQQ ACK
\____/ \____/ \____/ \____/ \____/

Example A message sequence on a control channel for a radio unit sending a status
message to a radio unit with the same prefix.
1. ALH : General Aloha invitation (single-slot frame).
2. RQQ : Random access request that status information be relayed to the

called unit.
3. AHYQ : Status Ahoy message

- acknowledges the RQQ message
- relays the information to the called radio unit and demands a
response.
4. ACK : Acknowledgement ACK(QUAL=0) from the called radio unit -

information accepted.
5. ACK : Acknowledgement ACK(QUAL=0) sent to the calling unit to indicate

that the called unit has accepted the information. In this example
the TSC immediately repeats the ACK message, for added
reliability.

13.1 Procedures for Status Messages Addressed to the TSC
13.1.1 TSC Procedures for Status Messages Addressed to It
13.1.1.1 Responses to an RQQ message addressed to the TSC
A radio unit sends status information to the TSC by generating an RQQ message
(with IDENT1 = TSCI), complying with the random access protocol. On receiving an RQQ
message addressed to it, the TSC shall send one of the following responses:
a. ACK(QUAL=0), ACKI(QUAL=1) or ACKX, with the same prefix and idents as the
RQQ.
b. For STATUS = '00000' or STATUS = '11111':

- an AHYX message with the same prefix and idents as the "alerting AHY"
- a GTC message for the original call (i.e. GTC with the same prefix, idents and bit
D as the alerting AHY).
For acceptable delay, see 7.2.4. See also 13.1.1.2, 9.1.1.8 and 9.1.1.12.
13.1.1.2 Acknowledgements sent to indicate progress of RQQ transaction
The TSC may send the following acknowledgement messages (with the same prefix
and idents as the RQQ) to indicate to a radio unit the progress of its status transaction:

ACKX (QUAL=1) - System overload; message rejected.
ACK (QUAL=0) - Transaction has been successfully completed i.e. the TSC has
accepted the status information.
For maximum acceptable delay of repeats of acknowledgements ACKX and ACK, see time-
out TB in 13.1.2.4.
13.1.1.3 Aborting the transaction
5.5.3.1.3), complying with the random access protocol. On receiving an RQX

message aborting a status transaction, the TSC shall send a response: ACK(QUAL=1) with
the same prefix and idents as the RQX.
message with bit POINT set to '1', PFIX/IDENT2 set to the unit's individual address and
IDENT1 set to TSCI; see 9.1.1.7 and 9.2.2.3. If a time TJ (minus the tolerance on the radio
unit's timer) elapses since the last message it received for the status transaction, the TSC
shall not send any further signalling for the transaction. See also 13.1.2.5.
See also sections 9.1.1.5, 13.1.2.7 and 13.1.2.8.

13.1.2 Procedures for Radio Units Sending Status Messages to the TSC
a status message addressed to the TSC, the unit shall not request another non-emergency
call of any type (unless the user first aborts the original transaction).
13.1.2.1 Criteria for sending "off-hook" or "on-hook" message
If a radio unit on a control channel has been alerted for an incoming traffic channel
call (see 9.2.2.2A), it may initiate the Called Party Answer mechanism, i.e. attempt random
access with RQQ(STATUS='00000') addressed to the TSC, if:
- Its response to the last alerting AHY was ACKI(QUAL=0), and
- Its user/ data equipment is now ready to receive the call, and
- It is still waiting for the incoming call, i.e. the call has not taken place or been
cancelled (by AHYX or by an AHY for a different call) and not more than a time
TA has elapsed since receipt of the last AHY for the call; see 9.2.2.2A and
9.2.2.4.
If a radio unit has been alerted for an incoming traffic channel call and its user then
indicates that he no longer wishes to receive the call (e.g. he wishes to initiate a call of his
own), the unit may attempt to reject the call as follows:
a. If the unit is waiting for the incoming call and has not sent an off-hook indication it
attempts random access with RQQ(STATUS='11111') addressed to the TSC.
b. If the unit is waiting for signalling for an off-hook RQQ it attempts to send RQX (see
13.1.2.6).
c. If the unit has received ACK(QUAL=0) to RQQ(STATUS='00000') and is waiting for

further signalling for the call, it attempts random access with RQQ(STATUS='11111')
addressed to the TSC.
(Throughout these procedures, the unit responds to AHY messages and obey GTCs
as specified in section 9.2.2. See also sections 13.1.2.7 and 13.1.2.8.)
13.1.2.2 Request for a status transaction to the TSC
A radio unit requests a status transaction by sending an RQQ message on a control

channel, complying with the random access protocol (see 7.3). The fields in the RQQ
message shall be set appropriately (see 5.5.3.1.7).
The unit shall attempt access until it receives a valid response (see 13.1.2.3), or until
its user aborts the transaction (see 13.1.2.6), or until the access attempt fails (i.e. the unit
has sent the maximum number of transmissions NR and received no response, or its
access time-out TC has expired (see 7.3.8)). In the case of access failure, if the unit has
not sent a request, it shall return to the idle state (and may indicate the failure to the user);

otherwise, it shall wait for further signalling for the transaction - see 13.1.2.4, 13.1.2.5 and
13.1.2.7.
13.1.2.3 Valid responses to an RQQ addressed to the TSC
A radio unit shall accept the following messages as a response to its RQQ to the
TSC, and send no more requests:
a. An acknowledgement ACK(QUAL=0), ACKI(QUAL=1) or ACKX, with the same prefix

and idents as the RQQ.
b. For STATUS = '00000' or STATUS = '11111':

- an AHYX message with the same prefix and idents as the "alerting AHY", or
- a GTC message with the same prefix, idents and bit D as the alerting AHY.
For other actions on receiving these messages, see sections 13.1.2.4 and 13.1.2.7. See
also section 13.1.2.8.
If a radio unit attempting access or waiting for further signalling for a status
transaction to the TSC receives one of the following acknowledgements (with the same
prefix and idents as the RQQ), then it shall take action as indicated below.

ACKX (QUAL=1) - System overload; message rejected.
ACK (QUAL=0) - Transaction has been successfully completed i.e. the TSC has
accepted the status information.
If ACKI(QUAL=1) is received, the unit shall wait for further signalling for the
transaction.
If ACKX is received, the unit shall return to the idle state and may indicate to the
user that the transaction has failed.
If ACK(QUAL=0) is received, the unit shall consider the transaction successfully

completed and may indicate this to the user.
After receiving ACKX or ACK for the transaction, the unit shall not request another
non-emergency call of any type to the TSC for at least a time TB.
If this response is to RQQ (STATUS='11111), on-hook signalling, the radio unit shall
return to the idle state

A radio unit waiting for further signalling for a status transaction to the TSC shall
return to the idle state if a time TJ has elapsed since the last message it sent for the
transaction, viz.
RQQ, requesting the transaction (see 13.1.2.2)

or ACK(QUAL=0), sent in response to an AHY message with bit POINT = 1 and
IDENT1 set to TSCI (see 9.2.2.3).
If the user wishes to abort the transaction after the unit has sent an RQQ and while it
is still waiting for a terminating acknowledgement, the unit shall attempt to send an abort
transaction request RQX (see 5.5.3.1.3), complying with the random access protocol. It
shall attempt access until one of the following occurs:
a. It receives ACK(QUAL=1) with the same prefix and idents as the RQX.
b. It receives ACK(QUAL=0) or ACKX for the transaction it is attempting to abort. See

also 13.1.2.4.

for signalling for the status transaction (see 13.1.2.4, 13.1.2.5 and 13.1.2.7).
d. The conditions specified in 13.1.2.7 or 13.1.2.8 occur (applicable only for STATUS =
'00000' and '11111').
13.1.2.7 Receiving AHYX or GTC for the incoming call
If a radio unit:
a. attempting access or waiting for a terminating acknowledgement to an "off-hook" or

"on-hook" RQQ message (STATUS = '00000' or '11111'), or
b. attempting to abort an "off-hook" or "on-hook" RQQ transaction
receives AHYX with the same prefix and idents as the alerting AHY, it shall respond with
ACK(QUAL=1), stop its alerting signal (if appropriate) and return to the idle state; see also
9.2.2.4. If it receives a GTC message with the same prefix, idents and bit D as the alerting
AHY, it shall obey the procedures in 9.2.2.5 and then revert to the idle state at the end of
the call.

13.1.2.8 Receiving AHY for a different incoming call
If a radio unit:
a. attempting access or waiting for a terminating acknowledgement to an "off-hook" or

"on-hook" RQQ message (STATUS = '00000' or '11111'), or
b. attempting to abort an "off-hook" or "on-hook" RQQ transaction
receives an AHY message checking its availability for a different incoming traffic channel
call (i.e. bit D and/or bit E and/or the calling address is different from the alerting AHY),
then the unit shall assume that the original call will not take place and shall abandon the
RQQ transaction (without sending RQX). It shall also obey the procedures in 9.2.2.2A for
the new call.
13.2 Procedures for Status Messages Addressed to Radio or

Line Units
13.2.1 TSC Procedures for Status Messages to Radio or Line

Units
13.2.1.1 Responses to a short addressing RQQ message
A radio unit requests that status information be relayed to a unit with the same prefix
by generating an RQQ message, complying with the random access protocol. On
receiving a common-prefix RQQ message, the TSC shall send one of the following
responses:
a. ACK(QUAL=0), ACKI(QUAL=1), ACKQ, ACKX or ACKV, with the same prefix and
idents as the RQQ.
b. ACKT(QUAL=0), with PFIX/IDENT2 as the calling unit's individual address.
c. An AHYQ message for this transaction.
13.2.1.2 Responses to an extended addressing RQQ message
A radio unit requests that status information be relayed to a unit with a different
prefix by generating an RQQ message (with IDENT1 = IPFIXI), complying with the random
access protocol. On receiving an interprefix RQQ message, the TSC shall send one of the
following responses, with the same prefix and idents as the RQQ:

b. AHYC (i.e. an instruction to send the called unit's address).
13.2.1.3 Instruction to send extended address information
After receiving an interprefix RQQ message, the TSC may demand the called unit's
address from the calling radio unit by sending the AHYC message (with the same prefix
and idents as the RQQ, field DESC set to '000' and field SLOTS set to '01').
The AHYC message instructs the calling unit to send the called address in the
following slot (see 9.2.2.1). If the TSC does not successfully decode the address
information, it may repeat the AHYC message or transmit ACKV(QUAL=0) to indicate
13.2.1.4 Acknowledgements sent to indicate progress of RQQ transaction
The TSC may send acknowledgement messages to indicate to a calling radio unit the
progress of its status message - for idents, see 5.5.2.1. (For interprefix RQQs, only
ACKI(QUAL=1), ACKX and ACKV(QUAL=0) are appropriate until the full address

ACKX (QUAL=0) - Invalid call e.g. TSC does not support status messages, or called
address is a group address, or called unit is not equipped to
accept the information.
ACK (QUAL=0) - Transaction has been successfully completed i.e. the called unit
has accepted the status information.
ACK, see time-out TB in 13.2.2.4.
13.2.1.5 Informing a called radio unit
The TSC informs a called radio unit of status information by sending the AHYQ
message (see 5.5.3.2.7). The status message may have originated from the TSC itself, or
from a radio unit (using RQQ etc.) or a line unit.
For an interprefix status message, IDENT2 in the AHYQ address codeword is set to
IPFIXI and a data codeword is appended containing the calling unit's address.
The AHYQ message demands a response from the called unit (see 13.2.3). If the
response is ACK(QUAL=0), ACKX or ACKV(QUAL=1), the TSC may send appropriate

acknowledgement(s) to a calling radio unit (see 13.2.1.4). If the TSC does not successfully
decode a response, or if the response is ACKB(QUAL=1), it may repeat the AHYQ
message. If the called unit cannot be contacted, the TSC may indicate the failure to the
calling unit by sending ACKV(QUAL=0).
A calling radio unit may abort its status transaction by generating an RQX message
(see 5.5.3.1.3), complying with the random access protocol. On receiving an RQX message
aborting a status transaction, the TSC shall send a response: ACK(QUAL=1) with the same
prefix and idents as the RQX.
If the RQX is aborting a speech call request (i.e. RQQ(STATUS='00000')) and the
TSC has already informed the called unit of the call request, it may inform the called unit of
the abortion by sending AHYQ with STATUS='11111'.
The TSC may operate a time-out on the maximum time for which it holds a status
message request (for example, waiting for the called unit to be free).
The TSC may instruct a calling radio unit to restart its waiting timer TW, by sending
the AHY message with bit POINT set to '1'; see 9.1.1.7 and 9.2.2.3. If a time TW, minus
the tolerance on the radio unit's timer, elapses since the last message it received for the
status transaction (from the calling unit), the TSC shall not send any further signalling for
the transaction. See also 13.2.2.5.
13.2.2 Procedures for Radio Units Sending Status Messages to

Radio or Line Units
a status message request, the unit shall not request another non-emergency call of any
type (unless the user first aborts the original transaction).
13.2.2.1 Request for a status transaction to a radio or line unit
A radio unit requests a status transaction by sending an RQQ message on a control

channel, complying with the random access protocol (see 7.3). The fields in the RQQ
message shall be set appropriately (see 5.5.3.1.7); however, note particularly that an
interprefix request is indicated by setting IDENT1 to IPFIXI. (Note also that status
messages cannot be sent to a group.)
The unit shall attempt access until it receives a valid response (see 13.2.2.2/3), or
until its user aborts the transaction (see 13.2.2.6), or until the access attempt fails (i.e. the
unit has sent the maximum number of transmissions NR and received no response, or its
access time-out TC has expired (see 7.3.8)). In the case of access failure, if the unit has
not sent a request, it shall return to the idle state (and may indicate the failure to the user);
otherwise, it shall wait for further signalling for the transaction - see 13.2.2.4 and 13.2.2.5.

13.2.2.2 Valid responses to a short addressing RQQ
For a common-prefix RQQ, the calling unit shall accept the following messages as a
response to its RQQ and send no more requests:
a. An acknowledgement ACK(QUAL=0), ACKI(QUAL=1), ACKQ, ACKX or ACKV, with

the same prefix and idents as the RQQ message.

See also 13.2.2.4.
c. An AHYQ message with the same prefix, idents and STATUS field as the RQQ
message.
For other actions on receiving these messages, see section 13.2.2.4.
13.2.2.3 Valid responses to an extended addressing RQQ
For an interprefix RQQ, the calling unit shall accept the following messages (with the
same prefix and idents as the RQQ) as a response to its RQQ and send no more requests:
b. AHYC (i.e. an instruction to send the called unit's address).
For other actions on receiving these messages, see 13.2.2.4 and 9.2.2.1.
If a radio unit attempting access or waiting for further signalling for a status
transaction receives an appropriate acknowledgement then it shall take action as indicated
below. For interprefix RQQs, only ACKI(QUAL=1), ACKX and ACKV(QUAL=0) are
appropriate until the full address information has been sent. For idents, see 5.5.2.1.

ACK (QUAL=0) - Transaction has been successfully completed i.e. the called unit
has accepted the status information.
If ACKI(QUAL=1) or ACKQ is received, the unit shall wait for further signalling and
may indicate to the user the progress of the transaction.

to the user the reason for the failure of the transaction; it is recommended that receipt of
a. return to the idle state (and may indicate to the user that the called unit's calls have
been diverted), or
b. attempt a new status transaction to the diversion address given in the ACKT
message.
Note that, if IDENT1 = IPFIXI in the ACKT address codeword and bit GF = 1 in the
appended data codeword, then the diversion address is a group address; in this
case, a status transaction to the diversion address would be an invalid call.

- if still attempting access for the transaction, it shall ignore the message and
continue to attempt access;
- otherwise it shall wait for a repeat ACKT, returning to the idle state if a time TB
elapses (in which case, it may indicate the failure to the user).
the user that the transaction has been successfully completed i.e. that the called unit has
accepted the information. (Note that this does not imply user acceptance.)
After receiving ACKX, ACKV or ACK for the transaction, the unit shall not request
another non-emergency call of any type to the same called ident (or gateway) for at least a
time TB. After receiving ACKT for the transaction, the unit shall not request another non-
emergency call of any type for at least a time TB.
A calling radio unit waiting for further signalling for a status transaction to a radio or
line unit shall return to the idle state if a time TW has elapsed since the last message it sent
for the transaction, viz.
RQQ, requesting the transaction (see 13.2.2.1)

If the user wishes to abort the transaction after the unit has sent an RQQ and while it
is still waiting for a terminating acknowledgement, the unit shall attempt to send an abort

transaction request RQX (see 5.5.3.1.3), complying with the random access protocol. It
shall attempt access until one of the following occurs:
b. It receives ACK(QUAL=0), ACKX, ACKV or ACKT(QUAL=0) for the transaction it is

attempting to abort. See also 13.2.2.4.

for signalling for the status transaction (see 13.2.2.4 and 13.2.2.5).
13.2.3 Procedures for All Radio Units on a Control Channel
The procedures in this section shall be obeyed by all radio units that are equipped to
recognise a received AHYQ address codeword. (The requirement to recognise AHYQ will
be system-dependent.)
13.2.3.1 Receiving status message (AHYQ)
If a radio unit on a control channel receives an AHYQ message with PFIX/IDENT1

matching its individual address then it shall respond with the appropriate acknowledgement
(see below), with the same prefix and idents as the AHYQ. If IDENT2 / IPFIXI in the AHYQ
message, the unit shall respond in the slot following the AHYQ; if IDENT2 = IPFIXI, a data
codeword is appended (containing the calling address) and the unit shall respond in the slot
following the data codeword. For timing, see 6.2.1.3.
a. If the unit is not equipped to accept the information then it shall send ACKX
(QUAL=0).
b. Otherwise, the unit shall send one of the following acknowledgements:
ACKB (QUAL=1) if IDENT2 = IPFIXI in the AHYQ message but the

appended data codeword was not decodeable and the
or ACKX (QUAL=1) if it cannot accept the information at this time (e.g.

STATUS = '00000' in the AHYQ message and the unit's
call queue is full)
or ACKV (QUAL=1) if it does not wish to accept status information from this
calling party
or ACK (QUAL=0) if it has accepted the information in the AHYQ message.

14. SHORT DATA MESSAGE PROCEDURES
This section defines the procedures for short data messages of up to 184 bits of free-
format data, transmitted on a control channel. The data is contained in up to four data
codewords, appended to an address codeword (HEAD).
A radio unit requests to send a short data message using the RQC message (see
5.5.3.1.8). The TSC then:
- instructs the unit to send the short data message (and extended address
information if appropriate)
- forwards the message to the called party
- indicates the outcome of the transaction to the calling unit.
A radio unit may send a short data message to the TSC or to a radio unit, a line unit, a
group of units, all units in the system, a PABX extension (short or extended addressing) or
a PSTN number (short-form or general).
The TSC may also transmit short data messages (addressed to a radio unit, a group
or all units in the system), originated from the TSC itself or from a line unit, a PABX
extension or the PSTN.
For calls from radio units, the TSC uses the AHYC message to demand:
a. the called address information, for calls to:
- interprefix addresses
(if appropriate: see below)
- general PSTN destinations
- "long" PABX extension numbers
b. the short data message.
If both a. and b. are needed, the TSC obtains the full information in two steps, each step
using the AHYC message. The AHYCs are distinguished by the setting of IDENT1 (to
IPFIXI, PSTNGI or PABXI for a., or to SDMI for b.), and so the order in which they are sent
is not prescribed.
Note that, when a radio unit sends its short data message, it supplies the address
(prefix/ident) of the called party in the data message header. Therefore, for an interprefix
call, the TSC need not demand the called address separately unless it is required for
operational convenience.
The format for data within a short data message is not prescribed. Also, further
(system-dependent) specifications may be required to define:
- timings for repeat messages, and/or

- enumeration of data messages
to prevent duplicate messages (when a recipient accepts the repeat of a message as a

new message).

A typical message sequence for a radio unit sending a short data message to
another radio unit is illustrated in the example below.
1 slot
<--->
1 3 5 |5 7
TSC to RUs ALH ALH AHYC ALH ALH HEAD data ALH ACK ACK
(3) (0) (0) (4) | (0) (1) (1)
2 4 |4 6
RUs to TSC RQC HEAD data ACK
|
\____________________/ \___________________________/ \____/
frame frame frame
Example A message sequence on a control channel for sending a short data

message from one radio unit to another radio unit on the same site. In this
example, the data message comprises an address codeword and two
appended data codewords.
2. RQC : Random access request to transmit a short data message. (The

request indicates the number of timeslots required for the data
message: in this case, two slots.)

- acknowledges the RQC message
- instructs the calling unit to send the data message in
the next two slots
4. HEAD + data :The calling radio unit sends its short data message to the
TSC. In this example the message comprises an address
codeword (HEAD) and two appended data codewords.
5. HEAD + data : The TSC forwards the short data message to the called radio
unit.
The second data codeword contains a flag (RSA) which is set
to '0' to inhibit random access in the following slot, thus
reserving the slot for a response from the called unit.
6. ACK : Acknowledgement ACK(QUAL=0) from the called radio unit -

data message accepted.
7. ACK : Acknowledgement ACK(QUAL=0) sent to the calling unit to

indicate that the called unit has accepted the data message.
In this example the TSC immediately repeats the ACK
message, for added reliability.

14.1 TSC Procedures for Short Data Messages
14.1.1 Responses to a short addressing RQC message
A radio unit requests to send a short data message by generating an RQC message,
complying with the random access protocol. On receiving a short addressing RQC
message (with EXT = 1, or with EXT = 0 and IDENT1 set to a valid called party ident), the
TSC shall send one of the following responses:
a. ACKI(QUAL=1), ACKQ(QUAL=1), ACKX or ACKV, with PFIX/IDENT2 as the calling

unit's individual address and IDENT1 as the called ident (or PABXI for a call to a
PABX extension).
c. An AHYC message instructing the calling unit to send its data message.
For acceptable delay, see 7.2.4. See also 14.1.4 and 14.1.5.
14.1.2 Responses to an extended addressing RQC message
A radio unit requests to send a short data message by generating an RQC message,
complying with the random access protocol. On receiving an extended addressing RQC
message (with EXT = 0 and IDENT1 = IPFIXI, PSTNGI or PABXI), the TSC shall send one
of the following responses:
RQC.
b. An AHYC message instructing the calling unit to send the full called address
information.
c. An AHYC message instructing the calling unit to send its data message.
For acceptable delay, see 7.2.4. See also 14.1.3 to 14.1.5.
After receiving an extended addressing RQC message, the TSC may demand the full
called address (if appropriate), by sending the AHYC message with:
- the same prefix and idents as the RQC

(i.e. IDENT1 set to IPFIXI, PSTNGI or PABXI as appropriate, and
PFIX/IDENT2 set to the calling unit's address)
- SLOTS set to correspond to the RQC
The AHYC message instructs the calling unit to send the called party address information in
the following SLOTS slot(s) (see 9.2.2.1). If the TSC does not successfully decode the

address information, it may repeat the AHYC message or transmit ACKV(QUAL=0) to
indicate failure of the transaction.
Note that, when the radio unit sends its short data message, it supplies the called
address (prefix/ident) in the data message header. Therefore, for an interprefix call, the
TSC need not demand the called address separately unless it is required for operational
convenience.
14.1.4 Instruction to send the short data message
After receiving an RQC message, the TSC may demand the short data message
from the calling radio unit by sending the AHYC message, with:
- IDENT1 set to SDMI

- PFIX/IDENT2 set to the calling unit's address
- DESC set to '000'
- SLOTS equal to SLOTS from the RQC.
The AHYC message instructs the calling unit to send its short data message in the
following SLOTS slots (see 9.2.2.1). If the TSC does not successfully decode the short
data message, it may repeat the AHYC message or transmit ACKV(QUAL=0) to indicate
Note that AHYC bars random access only in the first following return slot. When
demanding a short data message, the TSC shall take appropriate action to reserve the
subsequent return slot(s) if they are within a frame (e.g. by sending the AHY message with
both idents set to DUMMYI).
14.1.5 Acknowledgements sent to indicate progress of RQC transaction
The TSC may send acknowledgement messages to indicate to a calling radio unit the
progress of its short data transaction - for idents, see 5.5.2.1. (For an extended addressing
call, acknowledgements ACKQ, ACKV(QUAL=1), ACKT(QUAL=0) and ACK(QUAL=0) are
not appropriate until the called address has been obtained. Acknowledgements
ACKQ(QUAL=0) and ACK(QUAL=0) are not appropriate until the short data message has
been obtained.)

ACKQ (QUAL=1) - Called party engaged. Wait for further signalling.
ACKX (QUAL=0) - Invalid call e.g. TSC does not support short data messages, or
called party is not equipped to accept the message.
ACKV (QUAL=1) - Called party engaged (and TSC will not hold the request) or
called unit does not wish to accept the message.
ACK (QUAL=0) - Transaction has been successfully completed.

ACK, see time-out TB in 14.2.4.
14.1.6 Availability check on called radio unit
Before transmitting a short data message to a radio unit, the TSC may check that the
unit is in radio contact (and suitably equipped). It uses the AHY message, with:

- bit CHECK set to '0'
- bit D set to '1'
- bit E set to '0'
- bit AD set to '0'
- PFIX/IDENT1 as the called unit's address
- IDENT2 set to SDMI.
The AHY message demands a response in the following slot from the called unit (see
9.2.2.2B).
The TSC may indicate the result of the availability check to a calling radio unit by
sending appropriate acknowledgement(s) (see 14.1.5).
14.1.7 Informing called party
The TSC transmits a short data message to a radio unit, a group or all units in the
system by sending the HEAD message on a control channel (see 5.6.2). The data
message may have originated from the TSC itself, or from a radio unit (using RQC etc.), a
line unit, a PABX extension or the PSTN.
The HEAD address codeword indicates the number of appended data codewords (up
to four), and contains two 20-bit addresses: the called address and calling address (or
gateway). The user data is contained in the data codewords. For an individually
addressed short data message sent within a frame, the TSC shall set the RSA flag in the
last data codeword (or in the "filler" data codeword) to '0', to inhibit random access in the
next slot.
For an individually addressed short data message, the HEAD message demands a
response from the called unit (see 14.3.1.1). If the response is ACK(QUAL=0), ACKX or
ACKV(QUAL=1), the TSC may send appropriate acknowledgement(s) to a calling radio unit
(see 14.1.5). If the TSC does not successfully decode a response, or if the response is
ACKB(QUAL=1), it may repeat the HEAD message. If the called unit cannot be contacted,
the TSC may indicate the failure to the calling unit by sending ACKV(QUAL=0).
For a short data message addressed to a group (or system-wide), the called units do
not respond; the TSC may repeat the data message, to increase the probability of
successful receipt. After transmitting the short data message, the TSC may send
ACK(QUAL=0) to a calling radio unit.

A calling radio unit may abort its short data transaction by generating an RQX
message (see 5.5.3.1.3), complying with the random access protocol. On receiving an RQX
message aborting a short data transaction, the TSC shall send a response: ACK(QUAL=1)
with the same prefix and idents as the RQX.
14.1.9 TSC time-out
The TSC may operate a time-out on the maximum time for which it holds a short data
message (for example, waiting for the called party to be free).
The TSC may instruct a calling radio unit to restart its waiting timer TJ or TW, by
sending the AHY message with bit POINT set to '1'; see 9.1.1.7 and 9.2.2.3. If a time TJ or
TW, minus the tolerance on the radio unit's timer, elapses since the last message it
received for a short data transaction (from the calling unit), the TSC shall not send any
further signalling for the transaction. See also 14.2.6.
14.2 Procedures for Radio Units Sending Short Data Messages

a short data message request, the unit shall not request another non-emergency call of any
type (unless the user first aborts the original transaction).
14.2.1 Request for a short data transaction
A radio unit requests to transmit a short data message by sending an RQC message
on a control channel, complying with the random access protocol (see 7.3). The fields in
the RQC message shall be set appropriately (see 5.5.3.1.8); however, note particularly that:
a. Field SLOTS specifies the number of timeslots required for the data message
(minimum two slots, maximum three slots).
b. An extended addressing request is indicated by setting IDENT1 in the RQC
message to the appropriate gateway (viz. IPFIXI, PSTNGI or PABXI).
its user aborts the transaction (see 14.2.7), or until the access attempt fails (i.e. the unit has
sent the maximum number of transmissions NR and received no response, or its access
time-out TC has expired (see 7.3.8)). In the case of access failure, if the unit has not sent
a request, it shall return to the idle state (and may indicate the failure to the user);
otherwise, it shall wait for further signalling for the transaction - see 14.2.4 to 14.2.6.
14.2.2 Valid responses to a short addressing RQC
For a short addressing RQC, the calling unit shall accept the following messages as
a response to its RQC and send no more requests:
a. ACKI(QUAL=1), ACKQ(QUAL=1), ACKX or ACKV, with PFIX/IDENT2 as its

individual address and IDENT1 as the called ident (or PABXI for a PABX call).

b. ACKT(QUAL=0) with PFIX/IDENT2 as its individual address.
c. AHYC, with PFIX/IDENT2 as its individual address and IDENT1 as SDMI.
14.2.3 Valid responses to an extended addressing RQC
For an extended addressing RQC, the calling unit shall accept the following
messages as a response to its RQC and send no more requests:
RQC.
b. AHYC, with the same prefix and idents as the RQC.
c. AHYC, with PFIX/IDENT2 as its individual address and IDENT1 as SDMI.
If a radio unit attempting access or waiting for further signalling for a short data
transaction receives an appropriate acknowledgement then it shall take action as indicated
below. (ACKQ, ACKV(QUAL=1), ACKT(QUAL=0) and ACK(QUAL=0) are not appropriate
until the called address information has been sent - in the RQC, as extended address
information or in the short data message. ACKQ(QUAL=0) and ACK(QUAL=0) are not
appropriate until the short data message has been sent.) For idents, see 5.5.2.1.

ACKV (QUAL=1) - Called party engaged (and TSC will not hold the request) or
called unit does not wish to accept the message.
ACK (QUAL=0) - Transaction has been successfully completed.
may indicate to the user the progress of the transaction.
to the user the reason for the failure of the transaction; it is recommended that receipt of
a. return to the idle state (and may indicate to the user that the called party's data calls
have been diverted), or

b. attempt a new short data transaction to the diversion address given in the ACKT
message.
- if still attempting access for the transaction, it shall ignore the message and
continue to attempt access;
- otherwise it shall wait for a repeat ACKT, returning to the idle state if a time
TB elapses (in which case, it may indicate the failure to the user).
the user that the transaction has been successfully completed i.e. that:
- for an individual call, the called unit has accepted the short data message;
(note that this does not imply user acceptance);
- for a group (or system-wide) call, the short data message has been sent to
the group.
After receiving ACKX, ACKV or ACK for the transaction, the unit shall not request
another non-emergency call of any type to the same called ident (or gateway) for at least a
time TB. After receiving ACKT for the transaction, the unit shall not request another non-
emergency call of any type for at least a time TB.
14.2.5 Sending the short data message
The calling unit shall transmit its short data message (a HEAD address codeword and
appended data codeword(s) - see 5.6.2) on receipt of an appropriate AHYC from the TSC;
see section 9.2.2.1.
A calling radio unit waiting for further signalling for a short data transaction shall
return to the idle state if a time TJ (for a data message addressed to the TSC) or TW (for
other destinations) has elapsed since the last signalling message it sent for the transaction,
viz.
RQC, requesting the transaction (see 14.2.1)

or HEAD, containing the short data message (see 14.2.5 and 9.2.2.1)

A radio unit may abort a short data transaction (after sending an RQC and while still
waiting to receive ACKX, ACKV, ACKT or ACK) by transmitting an abort transaction request
RQX (see 5.5.3.1.3), complying with the random access protocol. It shall attempt access
until one of the following occurs:
b. It receives ACK(QUAL=0), ACKX, ACKV or ACKT(QUAL=0) for the transaction it is

attempting to abort. See also 14.2.4.

for signalling for the short data transaction (see 14.2.4 to 14.2.6).
14.3 Procedures for All Radio Units on a Control Channel
recognise a received HEAD address codeword. (The requirement to recognise HEAD will
be system-dependent.)
14.3.1 Receiving short data message (HEAD)
14.3.1.1 Individually addressed HEAD message
If a radio unit on a control channel receives a HEAD message with PFIX1/IDENT1

(see below), with PFIX/IDENT1 as its individual address and IDENT2 set to IDENT2 from
the HEAD. The HEAD address codeword contains a field (LEN) which indicates the
number of appended data codewords; the unit shall respond in the slot following the last
data codeword. For timing, see 6.2.1.3.
a. If the unit is not equipped to accept the data message then it shall send ACKX
(QUAL=0).
b. Otherwise, the unit shall send one of the following acknowledgements:
ACKB (QUAL=1) if not all the appended data codewords were decodeable
and the unit requires the message to be retransmitted
or ACKX (QUAL=1) if it cannot accept the message at this time e.g. its data
store is full)
or ACKV (QUAL=1) if it does not wish to accept a data message from this
calling party
or ACK (QUAL=0) if it has accepted the data message.

14.3.1.2 HEAD message addressed to a group
If a radio unit on a control channel receives a HEAD message with PFIX2/IDENT2

not matching its individual address, and
PFIX1/IDENT1 matching one of its group addresses for this system or

IDENT1 set to the system-wide all-call ident ALLI,
then it may accept the information contained in the HEAD address codeword and the
appended data codewords, but shall transmit no response.

15. DATA INTERROGATION PROCEDURES
This section defines data interrogation procedures, which allow the TSC to demand
that an addressed radio unit transmits a data message of a prescribed type. This demand
is an interrogation by the TSC, not part of the signalling for a call requested by the radio
unit. It may be sent on either a control channel or an allocated traffic channel.
The TSC interrogates the radio unit by sending message AHYC, Mode 2 (see
5.5.3.2.8). In this message, PFIX/IDENT1 is set to the radio unit's individual address and
IDENT2 is the ident of the interrogator (a non-radio-unit ident). The type of data to be
transmitted by the radio unit is indicated by the descriptor field DESC and the non-radio-
unit ident.
The TSC does not acknowledge receipt of the radio unit's data message (though it
may take appropriate action as a result of the received data).
Currently, for data interrogation, only one value of the data message descriptor field
DESC has been assigned. This value is used for implementing serial number checks: the
TSC may at any time, on a control channel or traffic channel, instruct a radio unit to send its
38-bit serial number. Comparison of the received serial number with the expected value
(held in store at the TSC) will assist in the detection of fraudulent users.

15.1 Data Interrogation Procedures for TSC
15.1.1 Data interrogation on a control channel
The TSC may demand that a radio unit on a control channel transmits a data
message of a prescribed type, by sending the AHYC message with:
- IDENT2 set to the ident of the interrogator

(for example, for a serial number check, IDENT2 = TSCI)
- DESC set to indicate the type of data message required; see 5.5.3.2.8
(for example, for a serial number check, DESC = '000')
- SLOTS set appropriately; see 5.5.3.2.8

(for example, for a serial number check, SLOTS = '01').
The AHYC message instructs the addressed radio unit to transmit a data message in
the following SLOTS slot(s) (see 15.2.1). If the TSC does not successfully decode a reply,
it may repeat the AHYC message when convenient. (The TSC does not acknowledge
receipt of the data message).
Note that AHYC bars random access only in the first following return slot. When
demanding a multi-codeword data message, the TSC shall take appropriate action to
reserve the subsequent return slot(s) if they are within a frame (e.g. by sending the AHY
message with both idents set to DUMMYI).
15.1.2 Data interrogation on a traffic channel
The TSC may demand that a radio unit on an allocated traffic channel transmits a
data message of a prescribed type, by sending the AHYC message with:

- IDENT2 set to the ident of the interrogator
- DESC set to indicate the type of data message required; see 5.5.3.2.8
- SLOTS set appropriately; see 5.5.3.2.8.
The AHYC message instructs the addressed radio unit to transmit a data message
(see 15.2.2). If the TSC does not successfully decode a reply, it may repeat the AHYC
message.

15.2 Procedures for All Radio Units
recognise a received Mode 2 AHYC message. (The requirement to recognise AHYC, Mode
2 will be system-dependent.)
15.2.1 Data interrogation message (AHYC, Mode 2) on a control channel
If a radio unit on a control channel receives an AHYC message with PFIX/IDENT1

matching its individual address then it shall either send a data message in the following
SLOTS slot(s), or transmit ACKX(QUAL=0), as indicated below. For timing, see section
6.2.1.3.
If
IDENT2 is set to TSCI
and the unit is equipped to transmit its serial number on interrogation
then it shall transmit its serial number, conforming to the codeword format defined in
section 5.6.1.2.2 (SAMIS, Mode 2, DESC='000'). (The form of the serial number is system-
dependent.)
Otherwise
15.2.2 Data interrogation message (AHYC, Mode 2) on an

allocated traffic channel
If a radio unit on a traffic channel receives an AHYC message with PFIX/IDENT1

matching its individual address then it shall either send a data message or transmit
ACKX(QUAL=0), as indicated below. For timing, see section 6.2.2.2.
If
IDENT2 is set to TSCI
and the unit is equipped to transmit its serial number on interrogation
then it shall transmit its serial number, conforming to the codeword format defined in
section 5.6.1.2.2 (SAMIS, Mode 2, DESC='000').
Otherwise

16. ADDITIONAL SHORT DATA PROCEDURES
e.g. SAMs
Additional short data procedures are not included in this issue.

17 STANDARD DATA PROCEDURES
17.0 Introduction
This section defines the procedures for setting up data calls and then transmitting
Tmessages (see 2) in a standard manner on a standard data traffic channel (the data
channel). A base station may include several data channels.
Data may be transferred between the following parties:
radio unit → TSC, line unit, radio unit or group

radio unit → all standard data equipped (SDE) units in system
radio unit → PABX extension (short or long extension number)
radio unit → PSTN destination (prearranged or general)
radio unit → Public Data Network (PDN) subscriber
TSC → radio unit, group or all SDE units in system
line unit → radio unit, group or all SDE units in system
PABX extn. → radio unit, group or all SDE units in system
PSTN terminal → radio unit, group or all SDE units in system
PDN user → radio unit, group or all SDE units in system
Set-up of a new data call is initiated by the RQD request transmitted on either the
control or data channel. For this and other purposes the data channel has random access
frames interspersed with the user data being conveyed.
The data channel provides a link between the TSC and radio unit for the purposes
of a data call. For an individual link with the TSC, errors on the data channel are corrected
as necessary by automatic request for repetition (ARQ) before the data is passed on to any
other data link or equipment, i.e. operation is "store and forward". The TSC may limit the
time for which it will store a call if it finds difficulty in forwarding it. For a call between radio
units at least two links are necessary.
One data channel at a base station may be shared at one time by up to 1023 links,
several of which may be concurrently active, although the mean data transfer rate
experienced by each active radio unit is liable to reduce as the total activity increases. The
TSC is the master station and controls all transmissions on the data channel so as to avoid
any simultaneous transmissions (except random access ones) from radio units on the
return channel.

17.0.1 Facilities offered by the Standard Data Procedures
Facilities offered by these procedures are:
a) radio units operate in a half-duplex mode with bidirectional Tmessage transmission

facility,
b) for group calls the data in the link from the TSC to the group is not corrected by
automatic request for repetition but may be repeated up to a prearranged number of
times to increase the probability of successful reception by all group members,
c) a data call may be conducted with an individual radio unit or transmitted to a group
of radio units, and in the latter case responses may be obtained either by separate
polling of each radio unit in the group or by inviting random access from group
members,
d) the calling party may request that a call shall be directed to any one of 8
sub-addresses (PORTs), e.g. to call a particular receiving terminal configuration,
e) an end-to-end high accuracy data transfer (HADT) mode may be invoked,
f) a calling radio unit may request priority for resources for a data call,
g) a calling radio unit may make a request for an interactive data exchange with the
called party so that the TSC will test whether a suitable radio channel is available
and the called party is ready to exchange data,
h) urgent calls may be requested,
j) a suitably equipped radio unit may engage in more than one data call concurrently,
k) any called party can be informed of the identity of the calling party,
l) the calling party is given a reason for any call set-up failure,
m) a data call may consist of a single Tmessage (see NOTE 1), or may include a
response or a number of data interchanges with pauses between the various
Tmessages,
n) each link provided via a data channel is bit-transparent (see NOTE 2),
p) the standard data signalling rate is 1200 bit/s, with provision for a customised rate
(see NOTE 3), and
q) radio units may be transferred individually or in groups from one data channel to
another so that relief data channels may be created and brought into use when a
data traffic overload occurs and can be taken out of use when the overload
subsides. Also a radio unit on a data channel may be transferred collectively to
another data channel.

NOTE 1. No specific "mail-box" facility is listed but all the ingredients necessary to
provide that facility are available.
NOTE 2. Users concerned about unauthorised reception may wish to take advantage
of this facility by encrypting their data.
NOTE 3. The individual links of a call may transmit at different rates because of the
storage provided by the TSC. No customised rate is prescribed by this
standard.

17.0.2 Guide to Some Key Protocol Aspects
17.0.2.1 Data Channel Addressing
On the data channel it would be wasteful of time always to use address codewords
including the full identity of both the sender and recipient of a transmission dataitem.
Moreover, if two radio units are involved they each have their own link with the TSC(s), and
these links often act at different times because of the store and forward nature of the
facility. Therefore on the data channel, instead of Prefixes and Identities, each radio unit
uses a 10-bit transaction number termed a "TRANS" which identifies that link during that
call and is assigned by the TSC in a "Go-to-TRANS" (GTT) message sent during the call
set-up phase. The TRANS validity ceases when the link closes, and the TRANS value may
then be reused for a new link. A dummy TRANS value '0000000000' is reserved for use in
messages whenever no allocated value is appropriate.
Apart from the use of TRANS, the use of certain addresswords containing a PFIX
and IDENT(s) also is valid on a data channel in appropriate circumstances.
17.0.2.2 Data channel format
All messages on the data channel conform to the traffic channel format described in
section 3. On the forward channel preamble and SYNT are found in the last half of a Data
Channel System Codeword (DCSC), equivalent to the CCSC of a control channel but with
SYNC replaced by SYNT, see 5.1.
The standard allows for two possible transmission rates, viz 1200 bit/s and a
customised one. Only one rate is used on any one channel. All stations must be able to
utilize the 1200 bit/s rate, but use of the customised one is optional. A calling or individually
called radio unit states whether it could operate at the customised rate in its respective
RQD or acknowledgement message. The TSC specifies the rate for each TRANS in the
relevant GTT message, but must not specify the customised rate unless both TSC and
radio unit can use it. At 1200 bit/s the timing of a radio unit message relative to the TSC
"invoking message" is as described in 6.2.1.3, but for any customised rate this timing is
specified elsewhere. Some timing criteria are outlined in Appendix 6.
The data channel format is similar to a control channel in some ways, consisting of
random and non-random transactions with radio units. However, because the transactions
are often lengthy, differences between data and control channel are:
a) because of the long messages a TSC may transmit, on the forward channel DCSCs
are infrequent compared to CCSCs,
b) the concept of time-slots only applies within random access frames,
c) the Aloha function which introduces a random access frame does not require a
whole codeword and frequently shares a codeword with another function,
d) the list of codewords on the forward channel which withdraw slots from a random
access frame is different,

e) the WAIT parameter is replaced by a 3-bit frame count parameter, WF. If a random
access attempt has not been acknowledged before WF frames have been received
then the access attempt may be repeated,
f) in the Aloha function there is a frame length (slots) field ND which has 5 bits to give
a wide range of frame lengths,
g) a 10-bit TRANS field replaces the PFIX and IDENT fields found in frame marking
codewords, and
h) there is no equivalent of the modifier M field in frame marking codewords (a TRANS

value of '0000000000' permits any radio unit to attempt access, otherwise only the
radio unit(s) assigned to the specified TRANS can attempt access).
17.0.2.3 Access on the data channel
Random access opportunities are provided on the data channel for radio units to
make various data service requests. A frame marking function states the number of slots in
an access frame, and radio units attempt access by transmitting a one-codeword message
in a random slot within that frame. At 1200 bit/s each slot consists of two codewords, but
slots at the customised rate may differ. The access frame has a maximum length of 31
slots. The frame marking function occupies half a codeword, the other half often being
used for an acknowledgement.
Three types of frame marking function are provided, viz:
- DAL, a general Aloha,
- DALG, which limits requests to urgent calls or those for repeat of a group Tmessage,
and
- DALN, which invites any requests except those for a repeat of a non-urgent group
Tmessage.
Five types of request may be sent by radio units, viz:
- RQD to request a data call (which may be a concurrent call), (RQD with urgency bit E
set to '1' is sent in any random access frame)
- DRUGI to request resumption of data transmission or reception in a given TRANS

after a period of inactivity,
- DRQG to request repeat of the whole of a group Tmessage,
- DRQZ to request transmission of expedited data, and
- DRQX to request that a TRANS be closed. If the TRANS value in DRQX is the
dummy, '0000000000', then it requests that all TRANS assigned to that radio unit be
closed.
Permitted responses to these requests are detailed in 17.2.2.

A parameter, NDR, limits the number of random access tries in any one access
attempt, and a time-out, TDC, limits the duration of a random access attempt. These
parameters are pre-set. If either is exceeded then the random access attempt is
abandoned.
The AHYD message contains bit E to signal an urgent call. As well as the AHYD
message, the TSC may send other data ahoy type messages to addressed radio units, viz:
- DAHY to check whether a particular TRANS is still active,
- DAHYZ to inform a radio unit of expedited data, e.g. to reset the link to a known state,
and
- DAHYX to demand that a specific (or all) TRANS are closed.
17.0.2.4 Call Set-up
The call set-up procedures are similar whether initiated on the control or data
channel.
To make a data call the radio unit transmits an RQD message. This includes PFIX
and IDENT information and the called PORT, priority or urgency required, whether real-time
data exchange with the recipient is required, whether high accuracy data transfer (HADT) is
required, and whether the customised transmission rate can be used. The TSC grants the
Request by sending a GTT message which includes the calling identity, the designation of
the data channel to be used, the TRANS to be used for that call (or TRANS can be
allocated on the data channel), and the designated link transmission rate.
To call a radio unit(s) the TSC sends an AHYD (POINT=0) message containing
calling and called identities, whether HADT will be used, and the called PORT. In an
individual call, if the radio unit can satisfy the call requirements it acknowledges this with a
message which includes an indication of whether the customised rate can be used. A GTT
message from the TSC, including the called identity, channel number, TRANS for that link
(usually), and transmission rate, then instructs the radio unit to go to the data channel.
A call to or from a prearranged destination on any network can be set up using a

special Ident, e.g. NETSIj or one of the spare Ident's. Calls to general PSTN and PABX
destinations require extended addressing which is achieved in the normal manner. General
calls to or from a PDN destination use the gateway "DNI", and then are switched to the data
channel so that the addressing can be completed in gateway dependent format.
For a group call no response is made to the AHYD message. The group link then is
announced by a GTT message. Usually the group transmission rate is prearranged. Any
unit which cannot cope with the announced transmission rate or HADT, or accept the
PORT ignores that message (but radio units may use a fall-back PORT). Although no reply
to the Tmessage is possible within the call, a radio unit may note the caller's address in the
AHYD, and, after the call, if it wishes to respond it sets up (e.g. on the data channel) a new
call to the noted originator's address. The amount of data which can be conveyed in one
group call is limited to a maximum of 11994 bits.

17.0.2.5 The ARQ scheme and related matters
Apart from the above, as well as the forward error correction possibilities offered by
each codeword, an ARQ scheme is included in links with individual radio units. The
descriptions given in this subsection apply only to individual links.
ARQ is not provided for a transmission to a group but, by prearrangement, the

Tmessage may be transmitted automatically more than once, and individual radio units can
request a repeat.
On any link no dataitem may contain more user data than that found in the address
word plus 62 data codewords. Tmessages needing more than this are sent by dividing
them into a number of dataitems. The maximum number of data codewords in any dataitem
is controlled by the receiving station (or the TSC for a first dataitem) and in no case
exceeds 62. Initially a dataitem is sent in one user data message but a fragment of a
dataitem can also constitute a user data message.
The number of data codewords in any user data message is stated in a FRAGL field
in its address codeword (SITH, see 5.8.12), and the position of the last bit of user data in
the final codeword is given in the LASTBIT field of SITH. In a dataitem, user data starts in
the 10-bit USER DATA field of SITH and continues with 47 bits of user data in every
appended data codeword until the final codeword in the dataitem. In the user data field of
that codeword (including SITH if it has no appended data codeword) the end of the user
data is followed by a '1' to confirm the end of the user data. Any space left in the field is
filled with '0's (unless HADT is used, see below). If it happens that the last user data bit
occupies the final bit in the user data field of a codeword the end of user data is still
confirmed, which gives rise to an appended data codeword containing a '1' and 46 '0's in its
information field.
If HADT is invoked, the last 15 information bits in the message are a checksum on
the data in the dataitem, and may replace 15 filler '0's. See 17.2.3.1.4.2.
In response to a faulty user data message the receiver may send a selective
acknowledgement (SACK) to request retransmission of a fragment of a dataitem.
Alternatively the receiver may request complete retransmission of the dataitem by sending
a negative acknowledgement (NACK).
If HADT is invoked, when an apparently entire dataitem has been received the
checksum is used to decide whether the dataitem is incorrect, and if so a NACK message
is sent.
When the entire dataitem has been correctly received, a positive acknowledgement
(PACK) is sent. Only then may the next dataitem be embarked upon. PACK and NACK only
differ in 1 bit, and are known collectively as DACK.
As a precaution against lost or duplicated messages every header and

acknowledgement contain the TRANS and a 1-bit dataitem number (ITENUM). The
dataitem number remains constant for one dataitem and any repeat fragments but differs
between any two adjacent dataitems.
DACK occupies only about half a codeword (a submessage) and the remaining
submessage is used for data channel access (see 17.0.2.3 and 17.0.2.6). In contrast a
SACK message includes one assigned EFLAG bit for every dataword in the dataitem. An

assigned EFLAG which is set to '1' indicates that the relevant data codeword must be
repeated. The leading EFLAG represents the leading data codeword in the dataitem, and
so on (see 5.8.11 for rules governing the use of the EFLAGS' field).
In order to mark the last assigned data codeword in the SACK message the first
non-assigned EFLAG is set to '1' and any remaining non-assigned EFLAGs are set to '0'.
There are 23 EFLAGs in the SACK addressword. If the dataitem has more than 22
datawords the SACK has an appended data codeword with a 40-bit EFLAG field, as
confirmed by an address codeword flag "AD". Security of the EFLAG information is
enhanced by a 4-bit 'ONES' field in each SACK codeword. The value of ONES is set to the
modulo-16 number of EFLAGs set to 1 in that codeword.
In response to a SACK message containing assigned EFLAGs which are set to '1'
the data transmitter sends a fragment of the dataitem which consists of a new header and
only the repeated relevant data codewords in the same order as in the dataitem. A radio
unit sends this response immediately (see Figure 17.1 below). For procedures for the data
sending station (DSS) see 17.2.3.1.
FIGURE 17.1 Use of EFLAGS in Selective Repeat of a user data message
PRE SYNT SITH 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 16 Data codeword, user

message, sent by DSS.
(Dataitem)
4 data codewords fail (3,4,9

and 11)
_________________SACK__________________
/ (not to scale) \
TYPE Selective Acknowledgement from DRS
PRE SYN 0011000010 100000100000 PARITY
↑
| | ÄÄÄÄÄÄÄÄ End of EFLAGS marker
ÀÄÄÄÄÄÄÄ
\__EFLAGS__/ \____EFLAGS___/
SITH 3 4 9 11 4 Data codeword repeat message (Fragment)

2 data codewords fail (4 and 9)
_________________SACK__________________
/ (not to scale) \
TYPE Selective Acknowledgement from DRS
PRE SYN 0001000010 000000100000 PARITY
↑
| | ÀÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄ End of EFLAGS marker
\__EFLAGS__/ \____EFLAGS___/
SITH 4 9 2 Data codeword repeat message (Fragment) No Failures.
DACK Message received by DRS. No Failures.
After sending a user data message, if, within a set time limit, the sender does not
recognize an acknowledgement then it may infer that either the recipient failed to decode
the SITH (and hence any appended datawords) or that an acknowledgement was sent but
not decoded. If only the addressword of a two-word SACK is decoded then clearly the user

data message was received but the SACK cannot be acted upon. The acknowledgement
loss situation can be rectified by repeating the message, but this is wasteful if the message
is a long one and only acknowledgement information has been lost. To reduce waste a
Repeat Last Acknowledgement (RLA) message is specified so that a sending station can
demand acknowledgement repetition instead of sending a message repetition. The sending
station acts upon the information in the repeated acknowledgement.
An acknowledgement from a radio unit follows substantially immediately after the

end of the message transmitted by the TSC but the acknowledgement sent by the TSC in
response to a message from a radio unit may be delayed by up to a pre-set time limit after
the end of the message. If the time limit is exceeded the radio unit may use random access
to send a query to the TSC.
17.0.2.6 Data Traffic and Flow Control
The TSC controls all data traffic on the data channel either by using a GO
submessage to grant a dataitem transmission to the addressed radio unit or by using an
aloha marker submessage to give a random access opportunity to radio units (see 5.8.2). A
radio unit may indicate to the TSC in a GO submessage the length of the next dataitem it
proposes to send. The TSC may grant a shorter dataitem length.
A field found both in SITH and DACK is "TNITEL" which informs the receiver of the
proposed number of data codewords (0 to 62) in the next dataitem. The GO submessage
(sent by a data receiving station) includes a 6-bit field, RNITEL, which defines the
maximum number of data codewords that can be accepted in the next user data message.
Flow control at a link level is achieved by using the TNITEL and RNITEL fields. A
data sending station must not send more data than is acceptable to the receiving station,
as expressed in RNITEL. The TNITEL value found in SITH is advisory so that the receiver
can check that it has sufficient storage.
When transmitted in a DACK submessage, if TNITEL has any value except the null
value, '111111', that means the the acknowledging station intends or wishes to send user
data, and hence bidirectional transmission is implied. If sent by a radio unit, TNITEL <
'111111' can be acted upon by the TSC to invite user data. For example, bidirectional data
flow in a TRANS may occur in the following recurrent order:
F'w'd Chan DACK+TNITEL+GO Message DACK+TNITEL+GO

Ret'n Chan Message DACK+TNITEL+GO
etc.
A radio unit which finds it necessary to stop data reception completely for some time
may cease to be offered more data by the TSC. In that case, when it is ready the radio unit
may request resumption of data flow by using a random access opportunity.

17.0.2.7 RESET
The RESET function is employed by a receiving or sending station or by the TSC to

reset the data to a known state. The RESET operated by the end users is usually combined
with synchronisation points so that after a RESET operation data communication can
restart from a known synchronisation mark. The synchronisation marking techniques of the
network service user are not specified in this standard. Generally this involves more than
one link but of course comprises a single link if the radio unit and TSC happen to be the
two end parties.
The RESET operation discards all that data transmitted before initiation of the
RESET but not yet delivered to the network service user.
If the TSC receives the RESET message (which may be sent in a random access
frame or in place of an acknowledgement or instead of invited data) it firstly acknowledges
the message and also transmits RESET to the other correspondent at the earliest
opportunity, e.g. before sending a 'GO' message or other which would permit the
correspondent to send or repeat data. If necessary the TSC repeats the RESET until it is
acknowledged by the radio unit. The TSC sends no more data to the originator of the
RESET until this acknowledgement has been received.
A data receiving or sending radio unit which receives a RESET message firstly
removes all data from its receiving and sending buffers and acknowledges the (received)
RESET and then sends a RESET to (its) data terminal equipment (DTE) and waits for DTE
acknowledgement before resuming any data sending or receiving.
17.0.2.8 Demarcation of a Tmessage
A "MORE" bit is found in each SITH, "MORE" is used to indicate the conclusion of
each Tmessage. It is the duty of each node in the communication chain to interpret the
"MORE" bit in this protocol or its equivalent in any other protocol and pass its meaning on
to the dependant link in the appropriate format and position within the data stream.
17.0.2.9 Closing a TRANS and Moving to another channel
A TRANS may be closed either by TSC demand (which may or may not also
demand an acknowledgement) or by radio unit request or by expiry of the radio unit
inactivity timer TDX or TDN for an individual or group call respectively. When all TRANS of
a radio unit have been closed it returns to the control channel.
If a TSC finds it desirable to move a radio unit to another data channel, e.g.
because the data channel it is on has become overloaded, it may do so without breaking
down a data call. To do this the TSC first demands closure of any calls concurrent with the
one to be preserved. Then, at a time when neither radio unit nor TSC are attempting to
send a message it sends the radio unit a GTT message including a new channel and a new
TRANS. The radio unit moves to the new channel and notes that the new TRANS replaces
the preserved one for the continued call.
The TSC may simultaneously move all the radio units to a new data channel by
addressing them with the ALLI ident.

17.1 Procedures for Setting Up Standard Data Calls
This section contains the procedures for setting up standard data call links on either
a control channel or a data channel. The procedures cover the following aspects:
a) Link with calling party
- call request procedures for standard data calls

- call cancellation while waiting for a call
- establishment of calling party data link.
b) Link with called party
- availability/rate check on called radio units

- establishment of called party data link.
Standard data calls from radio units are requested using the Standard Data
Communication Request Message RQD (see 5.7.1). For an emergency standard data call,
bit E in the RQD is set to '1'.
The RQD message contains all the information necessary to request a

common-prefix call, a system-wide call or a call to a prearranged PSTN or PDN destination.
For an interprefix call, a general call to the PSTN or a call to any PABX extension,
the call details cannot be accommodated in a single address codeword. For these calls,
the RQD message requests entry into the extended addressing mode; the radio unit sets
IDENT1 in the RQD to the appropriate gateway ident (viz. IPFIXI, DNI, PSTNGI or PABXI),
and the TSC then demands the full called party information using the AHYC message.
Usually, if the TSC has a direct entry point to a data network then for a general call
to a data network destination, the radio unit sets IDENT1 in the RQD message to DNI. After
setting up the link, the radio unit is invited to supply the full destination address on the data
channel using network layer procedures. Alternatively a radio unit may contact a distant
data network entry point via the PSTN or a PABX, and when that contact has been
established the full destination address is provided on the data channel as described
above.
Note that extended addressing procedures are used for requesting a standard data
call to any PABX extension (with either a long or short extension number). The unit sets
IDENT1 in the RQD message to PABXI, and then sends the PABX address information in
response to an AHYC message with IDENT1 set to PABXI and DESC set to '010'. The unit
sets bit SP in the SAMIS message to indicate whether it is sending BCD digits or a 13-bit
extension number (plus 2-bit exchange number). See 5.5.3.2.8 and 5.6.1.2.2.
Radio units requesting a 'general' PSTN call use the gateway ident, PSTNGI. In this
case, units are requested to provide the full dialling information for the PSTN destination
using extended addressing procedures. The FAD field in the RQD message performs the
same function as FLAG1 in an RQC message.
The call set-up procedures are outlined in section 17.0.2, and typical message
sequences for establishing standard data links are illustrated in the example below. The
call shown is a common-prefix non-emergency call between two radio units, both of which

are currently tuned to controlchannels. In this example, the calling unit is queued (to wait
for a data channel or for the called party in an interactive call) - otherwise the TSC could
have sent the Go To Transaction message directly.
1 slot
<----->
1 3 4
TSC to RUs ALH ALH ACKQ ALH GTT GTT
(3) (0) (2) (3)
RUs to TSC 2
RQD
\_________________/ \________________/
frame frame
Example 1A A message sequence on a control channel for a calling radio unit

requesting a common-prefix standard data call.
2. RQD : Random access request for a Standard Data call.
3. ACKQ : The TSC acknowledges the RQD message, informing the calling
unit that the call has been queued.
4. GTT : Go To Transaction message instructing the calling unit to switch

to a designated data channel for the transaction. In this example,
the GTT message is repeated, for added reliability.
(Note that the GTT message cannot mark an Aloha frame, but does not
withdraw slots from an ongoing frame.)
1 3
TSC to RUs AHYD ALH GTT GTT
(3)
RUs to TSC 2
ACK
\________________/
frame
Example 1B A message sequence on a control channel for a called radio unit in a

common-prefix standard data call.

1. AHYD : Availability/rate check message sent to called unit. Demands a
response from the called unit.
2. ACK : Acknowledgement that the radio unit is available and indicates

whether it can operate at the customised rate.
3. GTT : Go To Transaction message instructing the called unit to switch to

a designated data channel for the transaction. In this example,
the GTT message is repeated, for added reliability.
As shown in the example, data links are established using the Go To Transaction
message GTT. Note that the GTT message instructs only one radio unit or group. GTT
messages are sent independently to establish links, for a particular call, between:
a) calling radio unit and TSC,

b) TSC and called radio unit (or group), as required. Note that:
- these GTT messages may be sent on different sites;
- they may designate different data channels;
- the specified transmission rates may be different;
- there is no relationship between the transaction numbers (which will be

different if both parties are directed to use the same data channel).
Also, since all data is transferred via the TSC, it may not be necessary for the two
parties to be on their data channels at the same time. Bit INTER in RQD indicates whether
the calling party requires that the called party should be available to receive the data
immediately (enabling a call where the parties appear to have interactive contact, achieved
via the TSC's store-and-forward mechanism).
In the example, both radio units started the exchange tuned to control channels.
More generally:
a) The call request (and following message sequence) may be sent on either a control
or data channel, as appropriate.
b) The message sequence with the called party may take place on either a control or
data channel, depending on where the called party is currently tuned.
The message sequences are similar whether they take place on a control or data
channel. Where there are differences (for example, in the random access method) these
are indicated in the procedures.
Note that high accuracy data transfer (HADT) may be invoked by setting the HADT
bit of an RQD or AHYD message to '1'. When HADT is used in a call, it shall be applied to
all links within the call which conform to this standard and, in an individual call, to both
possible user data transmission directions. Parts of the call chain which do not conform to
this standard are assumed here to be of adequate data transfer accuracy and are excluded
from the rules laid down here. It is the user's responsibility to assure himself of the data
transfer accuracy of these non-MPT 1327 parts of the chain.

17.1.1 TSC Procedures for Setting Up Standard Data Calls
This section describes facilities available for use by the TSC. However, note that the
TSC is allowed a great deal of flexibility and it need not implement all these facilities.
Section 17.1.1.1 defines the basic procedures for setting up non-emergency

standard data call links. Section 17.1.1.2 defines the procedures for emergency standard
data calls.
17.1.1.1 TSC Procedures for Setting Up Non-Emergency

Standard Data Call Links
17.1.1.1.1 Responses to a short addressing RQD(E=0) message
A radio unit requests a short addressing non-emergency standard data call by

generating an RQD message (with E = 0 and IDENT1 set to a valid called party ident or
short-form ident), on a control channel or data channel, complying with the appropriate
random access protocol. On receiving a short addressing RQD(E=0) message, the TSC
shall send one of the following responses (on the channel on which the RQD was
received): (For acceptable delay, see 7.2.4 or 17.1.4.)
a. ACKI(QUAL=1), ACKQ, ACKX or ACKV, with the same prefix and idents as the
RQD.
c. A Go To Transaction message GTT for the calling unit - see 17.1.1.1.7.
The response is thus a direct acknowledgement (as in a. and b.) or an indirect

acknowledgement (as in c.). The acknowledgement messages may also be sent to the
calling unit at appropriate times to indicate the progress of the call - see 17.1.1.1.4.
(Note that the above list of responses applies both to the first request received for a
call and to any repeat requests that the radio unit may send if it fails to receive a response.)
17.1.1.1.2 Responses to an extended addressing RQD(E=0)

message
A radio unit requests an extended addressing non-emergency standard data call by

generating an RQD message (with E = 0 and IDENT1 = IPFIXI, PSTNGI or PABXI), on a
control channel or data channel, complying with the appropriate random access protocol.
On receiving an extended addressing RQD(E=0) message, the TSC shall send one of the
following responses, with the same prefix and idents as the RQD:
a. An acknowledgement ACKI(QUAL=1), ACKV(QUAL=0) or ACKX.
For acceptable delay, see 7.2.4 or 17.2.1.1.4. For the usage of these messages,
see 17.1.1.1.3 and 17.1.1.1.4.

17.1.1.1.3 Instruction to send extended address information
After receiving an extended addressing RQD message, the TSC may demand the
full called address by sending the AHYC message, with:
- The same prefix and idents as the RQD.

- DESC set to indicate the appropriate gateway (see 5.5.3.2.8).
- SLOTS set to correspond to the request as follows:
For an interprefix or PABX call, SLOTS = '01' or

For a general PSTN call, SLOTS = '01' or '10'
(The FAD field in the RQD message indicates if the number of dialled digits
exceeds 9).
The AHYC message instructs the calling radio unit to send the called party address
information in the following SLOTS slot(s) (see 17.1.2.1.5). If the TSC does not
successfully decode the address information, it may repeat the AHYC message or transmit
ACKV(QUAL=0) to indicate failure of the call.
appropriate acknowledgements to the calling unit (see 17.1.1.1.4).
Note that AHYC bars random access only in the first following return slot. For
SLOTS = '01', this is sufficient for the radio unit's response; however, for SLOTS = '10', the
TSC shall take appropriate action to reserve the second return slot if it is within a random
access frame (e.g. by sending the AHY message with both idents set to DUMMYI in the slot
following the AHYC).
17.1.1.1.4 Acknowledgements sent to indicate progress of a

call set-up attempt
The TSC may send acknowledgement messages at appropriate times to indicate to

a calling radio unit the progress of its standard data call. For idents, see 5.5.2.1. (For
extended addressing calls, only ACKI(QUAL=1), ACKV(QUAL=0) and ACKX are
appropriate until the full address information has been obtained.) Note that the criteria for
setting the maximum delay of repeats of acknowledgements ACKX, ACKV and ACKT
should take account of time-out TDB (described in 17.1.2.1.4).
The TSC may send ACKI(QUAL=1) or ACKQ to indicate to a calling radio unit the
progress of the signalling for its data call:
ACKQ (QUAL=1) - Called party is engaged (and calling party requires interactive
contact). Wait for further signalling.

It may send ACKX or ACKV to indicate to the calling unit that its data call request
will not be complied with:
ACKX (QUAL=0) - Invalid call e.g. TSC or called party does not support standard
data at least from this caller, or the radio unit is blacklisted, or
called address is unobtainable.
ACKX (QUAL=1) - System overload, or for INTER='1' the called party is engaged
or will not interact at this time and the TSC has not queued
the call; request rejected.
ACKV (QUAL=1) - Call not queued because the called party is unable to receive
a call with the required facilities, e.g. the called radio unit does
not support HADT or interaction or cannot accept the
requested PORT.
If the TSC has previously accepted a diversion request RQT requesting that this
type of call be redirected to another party, then it shall send ACKT(QUAL=0) with
PFIX/IDENT2 as the calling unit's individual address and:
a. IDENT1 as the diversion ident, or
b. IDENT1 as a gateway (viz. IPFIXI, PSTNGI, or PABXI); in this case, the diversion
address follows in concatenated data codeword(s); see 5.5.2.1.
(On receiving ACKT, the radio unit will either return to the idle state or re-attempt
access by calling the diversion address - see 17.1.2.1.4.)
17.1.1.1.5 Call cancellation by calling party
A calling radio unit may cancel a requested standard data call by generating an
RQX message (see 5.5.3.1.3), complying with the appropriate random access protocol. On
receiving an RQX message cancelling a standard data call, the TSC shall send a response:
ACK(QUAL=1), with the same prefix and idents as the RQX.
17.1.1.1.6 Queue time-out
The TSC may order its queue of standard data calls (non-priority and priority,
between any parties) in any way acceptable to the system operator.
The TSC may operate a time-out on the maximum time for which it queues a
standard data call. See also 17.1.2.1.7.
The TSC may instruct a calling radio unit to restart its waiting timer, by sending the
AHY message with bit POINT set to '1'. If a time TW,(control channel) or TDW (data
channel), minus the tolerance on the radio unit's timer, elapses since the last call set-up
message it received for a standard data call (from the calling unit), the TSC shall not send
on this channel any further call set-up messages to the calling unit for this call. (It may send
AHYX to inform a called radio unit that the call will not take place - see 17.1.1.1.9.)

17.1.1.1.7 Establishing a data link with a calling party
A calling radio unit's request message indicates whether it is able to operate at the
customised transmission rate. If the customised rate is not acceptable to both the calling
unit and the TSC, then the TSC shall default to the standard rate. The TSC shall not
specify a rate which is different from one in current use on the allocated channel.
For an interactive call, the TSC may establish the data link with the calling party only
when it has ascertained that the called party or network gateway can accept the call (see
17.1.1.1.8 for checking call acceptance by a radio unit).
The TSC sends the Go To Transaction message GTT (on the channel on which the
RQD was received). The TSC may repeat the GTT command.
The GTT message specifies:
i) The data channel number for the transaction.
For a call set-up GTT sent on a data channel, this shall be the number of that same
data channel. (Whereas the TSC procedures for in-call transfer are specified in section
17.2.5.1.)
ii) The transmission rate to be used.
For a call set-up GTT sent on data channel, this shall specify the rate currently used
on that channel.
iii) A transaction number TRANS for use on that data channel.
For GTT sent on a control channel, the TSC may set TRANS to a dummy value
'0000000000'. In this case, it shall send further GTT message(s) on the specified data
channel to designate a valid transaction number. The calling party will wait for a time TDG
for a data channel GTT - see 17.1.2.3.4c. Accordingly, it is recommended that the TSC
sends any data channel GTTs for the call within a period TDG (minus the tolerance on the
radio unit's timer) following the first control channel GTT.
When establishing a data link with a calling radio unit, the TSC shall set bit O/R in
the GTT message to '1'.
17.1.1.1.8 Availability/rate check on individually called radio unit
A TSC which wishes to set up a standard data call to a radio unit shall, before
establishing the called party link, check whether the called unit can accept the call.
The TSC checks availability of a called radio unit for standard data, and asks
whether the unit can accept the customised transmission rate, by sending the AHYD
message. This message may be sent on either a control channel or data channel as
appropriate. In the AHYD message:
- INTER indicates whether interactive contact is required,

- bit E indicates whether the call is urgent,
- PORT is the called port,
- PFIX/IDENT1 is the called unit's individual address,
- IDENT2 is the calling ident or short-form ident appropriate to the calling

terminal or gateway, and
- HADT is set as appropriate.
If IDENT2 = IPFIXI, the TSC may append a data codeword containing the calling
unit's address; if so, it shall set bit AD in the AHYD to '1'.
The AHYD message demands a response from the called unit (see 17.1.2.3.1 or
17.1.2.4.3). If the response is ACKX or ACKV(QUAL=1), the TSC may send appropriate
acknowledgement(s) to a calling radio unit (if the calling unit is still in the state of waiting for
call set-up signalling for this call). If the TSC does not successfully decode a response, or if
the response is ACKB(QUAL=1), it may repeat the AHYD message. If the called unit cannot
be contacted, the TSC may indicate the failure to a waiting calling unit by sending
ACKV(QUAL=0).
Acknowledgement ACK(QUAL=0) contains a bit, MODEM, which indicates whether

the customised transmission rate is acceptable to the unit (see 5.5.2.2).
17.1.1.1.9 Informing called party of call cancellation
If an individual call is cancelled then the TSC may inform a called radio unit by
sending the AHYX message with PFIX/IDENT1 as the called unit's address and IDENT2 as
the calling ident or gateway. The TSC may repeat the AHYX message if it is not
acknowledged by an ACK(QUAL=1) message from the called unit (see 17.1.2.3.2 or
17.1.2.4.4).
17.1.1.1.10 Sending AHYD to a group or ALLI
After receiving a request for a standard data call to a group (or to all units in the
system), the TSC may send the AHYD message to announce:
- whether it is an emergency call (bit E),
- the called PORT,
- the calling or short-form ident or gateway (IDENT2), and
- whether HADT will be used.
For a request for a group call with INTER set to '1', or if PORT information is needed
by called radio units, use of this message is recommended.

The AHYD message may be sent on either a control channel or data channel as
appropriate. It may be repeated.
For an interprefix call, the TSC may append a data codeword containing the calling
unit's address; if so, it shall set bit AD in the AHYD to '1'.
On receipt of the AHYD message, group members do not respond but may wait for
a time TA (on a control channel) or TDA (on a data channel) for the corresponding GTT
message (see 17.1.2.3.3 or 17.1.2.4.5). Accordingly, it is recommended that, on this
channel:
a) The TSC sends any GTT messages for the call within a period TA/TDA (less the
tolerance on the radio unit's timer) following the first transmitted AHYD message.
b) The TSC does not send any GTT messages for a different call to the same group
address within a period TA/TDA (plus tolerance) following the last AHYD for this call.
(Note that some radio units may miss the GTT messages for this call.)
17.1.1.1.11 Establishing data link with called party
The TSC establishes a data call link with a called radio unit or group by sending the
Go To Transaction message GTT with bit O/R set to '0'. It may repeat the GTT command.
The GTT message specifies:
i) The data channel number for the transaction.
For a call set-up GTT sent on a data channel, this shall be the number of that same
data channel.
ii) The transmission rate to be used.
For a call set-up GTT sent on a data channel, this shall specify the rate currently
used on that channel.
For GTT sent on a control channel to a group, the method for the TSC to choose
an appropriate transmission rate is system-dependent.
iii) A transaction number TRANS for use on the data channel.
For GTT sent on a control channel, the TSC may set TRANS to a dummy value
'0000000000'. In this case, it shall send further GTT message(s) on the specified data
channel to designate a valid transaction number. Called party(ies) will wait for a time TDG
for a data channel GTT (or for an AHYD for another call) - see 17.1.2.3.4c. Accordingly, it is
recommended that the TSC sends any data channel GTTs for the call within a period TDG
(minus tolerance) following the first control channel GTT; and does not send any data
channel GTT messages for a different call to the same group address within a period TDG
(plus tolerance) following the last control channel GTT.

17.1.1.2 TSC Procedures for Setting Up Emergency Standard
DataCall Links
17.1.1.2.1 Response to an emergency standard data request
A radio unit requests an emergency standard data call by generating an RQD(E=1)

message, on a control channel or data channel, complying with the appropriate normal
random access protocol (unless it has other arrangements with the system). On receiving
an RQD(E=1) message, the TSC shall send a response: ACKE(QUAL=0) with the same
prefix and idents as the RQD. For maximum permissible delay, see 7.2.4 or 17.2.1.1.4.
ACKE(QUAL=0) is sent only as a response to an RQE or RQD(E=1) message; it is

an intermediate acknowledgement, indicating that further signalling will follow.
17.1.1.2.2 Signalling for previous call
After receiving an RQD(E=1) message, the TSC shall not send any further call
set-up messages to the calling unit for any previous call requested by that unit (though, for
a traffic channel or standard data call, it may send AHYX to inform a called radio unit that
the call will not take place).
17.1.1.2.3 Obtaining extended address information
After receiving and responding to an extended addressing RQD(E=1) message, the

TSC may demand the full called address information from the calling radio unit by sending
the AHYC message (as in 17.1.1.1.3).
17.1.1.2.4 Acknowledgements sent to indicate progress of call
After receiving and responding to an RQD(E=1) message, the TSC may send
acknowledgements ACKI(QUAL=1), ACKQ, ACKX, ACKV or ACKT(QUAL=0) to the waiting
calling unit to indicate the progress of the call (as in 17.1.1.1.4).
17.1.1.2.5 Call cancellation by calling party
A calling radio unit may send an RQX message to cancel its emergency standard
data call. The TSC procedures are as defined in 17.1.1.1.5.
17.1.1.2.6 TSC time-out
The TSC may instruct a calling radio unit to restart its waiting timer by sending the
AHY message with bit POINT set to '1' (and bit E set to '1'). If a time TW/TDW, minus the
tolerance on the radio unit's timer, elapses since the last call set-up message it received for
an emergency data call (from the calling unit), the TSC shall not send on this channel any
further call set-up messages to the calling unit for this call. (It may send AHYX to inform a
called radio unit that the call will not take place.) See also 17.1.2.2.6.

17.1.1.2.7 Availability/rate check on individually called radio unit
This check shall be made as specified in 17.1.1.1.8.
17.1.1.2.8 Establishing data links
If all standard data channels (or transaction numbers) are fully occupied then the
TSC may terminate another data call prematurely in order to establish an emergency call.
The procedures for establishing data links are as detailed in sections 17.1.1.1.7 and
17.1.1.1.11.
17.1.2 Radio Unit Procedures for Establishing Standard Data Calls
Section 17.1.2.1 defines the procedures for requesting non-emergency standard

data calls and section 17.1.2.2 defines the procedures for emergency standard data calls.
Sections 17.1.2.3 and 17.1.2.4 define related procedures for all radio units on control and
data channels.
17.1.2.1 Procedures for Radio Units Requesting Standard Data Calls
A radio unit shall use short addressing for calls to other radio units with the same
prefix, or, by prearrangement with the system, to a limited number of PSTN and PDN
destinations. A radio unit also shall use short addressing for general calls via any PDN
gateway offered by the TSC, in which case the full addressing is then accomplished on the
allotted data channel in the format appropriate to that gateway.
A radio unit shall make only one call set-up attempt at a time (except in emergency);
while attempting access or waiting for further call set-up signalling for its standard data call,
Unless the user first cancels the original call the unit shall not request another
non-emergency call of any type.
17.1.2.1.1 Request for a non-emergency standard data call
A radio unit requests a non-emergency standard data call by sending an RQD(E=0)

message, on a control channel or data channel, complying with the appropriate random
access protocol (see 7.3 or 17.2.1.2). The fields in the RQD message shall be set
appropriately (see 5.7.1); however, note particularly that:
a. An extended addressing request is indicated by setting IDENT1 in the RQD

message to the appropriate gateway viz. IPFIXI, PSTNGI, and PABXI.
Note that:
extended addressing procedures are used for a call to a PABX extension. 'Short'
PABX procedures are not supported for standard data calls, and if a PDN entry
point is to be reached via an intermediate network then the appropriate intermediate
gateway is set in IDENT1 and further addressing is accomplished on the data
channel in the format appropriate to that gateway.

b. The FAD field shall be set to 'O' unless the PABX/PSTN destination address
contains more than 9 digits.
c. Field PORT indicates the required called port.
d. Bit INTER is set to '1' if the calling party requires interactive contact with the called
party.
e. Bit LEVEL indicates whether the calling party is requesting high priority for
resources. For INTER = '1', this requests high priority for the complete path to the
called party; for INTER = '0', it requests high priority only for the calling unit's link to
the TSC.
f. Bit MODEM indicates whether the unit is able to operate at the customised
transmission rate.
g. Bit HADT shall be set to '1' if high accuracy data transfer is thought to be supported
by the TSC and is required.
The radio unit shall attempt access until:
i) it receives a valid response (see 17.1.2.1.2/3), or
ii) its user cancels the call (see 17.1.2.1.8), or
iii) the access attempt fails (i.e. the unit has sent the maximum number of
transmissions NR/NDR and received no response, or its access time-out
TC/TDC has expired (see 7.3.8 or 17.2.1.2.7)).
In this case:
- If the unit has not sent a request, it shall return to the state previous to the
access attempt (and may indicate the failure to the service user).
- Otherwise, the unit shall wait for further call set-up signalling for the call; see
17.1.2.1.4 to 17.1.2.1.7.
17.1.2.1.2 Valid responses to short addressing RQD(E=0)
For a short addressing call, the calling unit shall accept the following messages as a
valid response to its RQD and send no more requests:
a. An acknowledgement ACKI(QUAL=1), ACKQ, ACKX or ACKV, with the same prefix

and idents as the RQD.
c. A Go To Transaction message GTT with PFIX/IDENT as its individual address, bit

O/R set to '1', an acceptable RATE and, for a request on a data channel, CHAN set
to the number of that data channel.

For other actions on receiving these messages, see sections 17.1.2.1.4 and
17.1.2.1.6, and 17.1.2.3.4 or 17.1.2.4.6.
17.1.2.1.3 Valid responses to extended addressing RQD(E=0)
For an extended addressing call, the calling unit shall accept the following
messages (with the same prefix and idents as the RQD) as a valid response to its RQD and
send no more requests:
a. An acknowledgement ACKI(QUAL=1), ACKV(QUAL=0) or ACKX.
For other actions on receiving these messages, see sections 17.1.2.1.4 and
17.1.2.1.5.
17.1.2.1.4 Acknowledgement received
If a radio unit attempting access or waiting for further call set-up signalling for a
standard data call receives an appropriate acknowledgement then it shall take action as
indicated below. (For extended addressing calls, only ACKI(QUAL=1), ACKV(QUAL=0)
and ACKX are appropriate until the full address information has been sent.) For idents,
see 5.5.2.1.
ACKX (QUAL=0) - Call adjudged to be invalid by TSC or called party; request

rejected.
ACKX (QUAL=1) - System overload, or for INTER='1' the called party is engaged
or will not interact at this time, and the TSC has not queued
the call; request rejected.
ACKV (QUAL=1) - Call not queued because the called party is unable to receive
a call with the required facilities, e.g. the radio unit does not
support HADT or interaction or cannot accept the requested
PORT.
may indicate to the service user the progress of the call.

If ACKX or ACKV is received, the unit shall return to the state previous to the call
request and may indicate to the service user the reason for the failure of the call; it is
recommended that receipt of ACKV(QUAL=0), ACKV(QUAL=1), ACKX(QUAL=0), and
ACKX(QUAL=1) each be indicated in its own distinct manner.
a. return to the state previous to the call request (and may indicate to the service user
that the called party's calls have been diverted), or
b. wait for a time (TB on the control channel, TDB on the data channel) (see below),
and then attempt a new call to the diversion address given in the ACKT message:
- if IDENT1 does not equal IPFIXI or PSTNGI or PABXI, try on IDENT1;
- if IDENT1 = IPFIXI or PSTNGI or PABXI, try the alternative called party given
in the appended data codeword(s).
Note that ACKT(QUAL=0), with IDENT1 = IPFIXI and an appended data codeword,
indicates either an interprefix diversion address or that the diversion address is of a
different type from the original called address. Flag GF in the appended data codeword
specifies whether the diversion address is an individual or group address; see 5.5.2.1.
If an incomplete ACKT(QUAL=0) message is received (i.e. if not all the appended

data codewords are decodeable), then:
i) If the unit does not require the diversion address, it shall return to the previous state
(and may give an indication to the service user).
- if still attempting access for the call, it shall ignore the message and continue
to attempt access;
- otherwise it shall wait for a repeat ACKT, returning to the previous state if a
time TB/TDB elapses (in which case, it may indicate the failure to the service
user).
After receiving ACKX or ACKV for the call, the unit shall not request another
non-emergency call of any type to the same called ident (or gateway) for at least a time
TB/TDB. After receiving ACKT for the call, the unit shall not request another
non-emergency call of any type for at least a time TB/TDB.

17.1.2.1.5 Instruction to send address information
A radio unit that is requesting an extended addressing standard data call on a

control channel shall follow the procedure in 9.2.2.1 for sending the full address
information, but with a revised check on the SLOTS field from the AHYC. The check that
"SLOTS corresponds to the request", for an extended addressing data call, shall be taken
as:
If IDENT1 = PSTNGI and unit's call requires > 9 PSTN digits

then SLOTS = '10'.
If IDENT1 = PSTNGI and unit's call requires < 10 PSTN digits
then SLOTS = '01' or '10'.
If IDENT1 not equal to PSTNGI
then SLOTS = '01'.
The procedure for sending extended addressing information for a data call
requested on a data channel is specified in section 17.1.2.4.1.
17.1.2.1.6 Availability check and channel command for own call
A calling radio unit attempting access or waiting for further call set-up signalling for a
standard data call shall obey the appropriate availability check and channel command
procedures (see 9.2.2.2 to 9.2.2.5 and 17.1.2.3.1 to 17.1.2.3.4, or 17.1.2.4.2 to 17.1.2.4.6).
It shall assume that a GTT message it receives is for its requested standard data
call if PFIX/IDENT is its individual address, bit O/R is set to '1', RATE is acceptable and, for
a GTT on a data channel, CHAN is set to the number of that data channel. If also TRANS >
'0000000000' then the unit shall regard the call link as established and may give an
indication to the service user.
17.1.2.1.7 Time-out after waiting
A calling radio unit waiting for further call set-up signalling on the channel on which
it attempted access for a standard data call shall return to the previous state if a time
TW/TDW has elapsed since the last message it sent for the call, viz.
RQD, requesting the standard data call (see 17.1.2.1.1)
or SAMIS, providing extended address information for the call (see 17.1.2.1.5)
or ACK(QUAL=0), sent in response to an AHY message with bit POINT = 1 and IDENT1 as
the called ident or gateway (see 9.2.2.3 or 17.1.2.4.2).
It may also indicate the failure to the service user.

17.1.2.1.8 Call cancellation
If the service user wishes to cancel the call, and the unit has not yet sent an RQD,
then it shall return immediately to the previous state. Otherwise, if the unit has sent an
RQD, it shall attempt to send a call cancellation request RQX (see 5.5.3.1.3), complying
with the appropriate random access protocol. It shall attempt access until one of the
following occurs:
a. It receives ACK(QUAL=1), with the same prefix and idents as the RQX, confirming
cancellation of the call.
b. It receives ACKX, ACKV or ACKT(QUAL=0) for the call it is attempting to cancel.

See also 17.1.2.1.4.
c. It receives a GTT message for the call it is attempting to cancel; in this case, it shall
obey the GTT procedure (see 17.1.2.3.4 or 17.1.2.4.6), though it may then
terminate the transaction.
d. It has sent the maximum number of transmissions NR/NDR and received no

response, or it's access time-out TC/TDC has expired. In this case, it shall return to
waiting for signalling for the standard data call (see 17.1.2.1.4 to 17.1.2.1.7).
In cases a. and b., the unit shall return to the previous state.
17.1.2.2 Procedures for Radio Units Requesting

Emergency Standard Data Calls
A radio unit shall make only one emergency call set-up attempt at a time. While
attempting access or waiting for further call set-up signalling for an emergency request, the
unit shall not request another call of any type (unless the user first cancels the original call).
It may make an emergency call at any other time. For example, it may interrupt a
non-emergency call set-up attempt to request an emergency call; in this case it shall
abandon the previous call attempt (without sending RQX).
17.1.2.2.1 Request for an emergency standard data call
A radio unit requests an emergency standard data call by sending an RQD(E=1)

message on a control channel or data channel. The fields in the RQD message shall be set
appropriately (see 5.7.1). Some TSCs may permit more than one emergency random
access transmission in a frame; however, unless the radio unit knows the retry rate
permitted by the TSC, it shall comply with the appropriate normal random access protocol -
see 7.3 or 17.2.1.2.
The unit shall attempt access until it receives a valid response (see 17.1.2.2.2), or
until its user cancels the call (see 17.1.2.2.7), or until the access attempt fails (i.e. the unit
has sent the maximum number of transmissions (NE for the control channel, NDE for the
data channel) and received no response, or its access time-out TC/TDC has expired). In
the case of access failure, if the unit has not sent a request, it shall return to the previous
state (and may indicate the failure to the service user); otherwise, it shall wait for further call
set-up signalling for the call - see 17.1.2.2.3 to 17.1.2.2.6.

17.1.2.2.2 Responses to RQD(E=1)
The calling unit shall accept the following messages (with the same prefix and
idents as the RQD) as a valid response to its emergency RQD and send no more requests:
a. An acknowledgement ACKE(QUAL=0).
b. An AHYD message with bits POINT and E set to '1'.
It shall then wait for further signalling for the call. See also section 9.2.2.3
or 17.1.2.4.2.
17.1.2.2.3 Sending extended address information
For an extended addressing emergency standard data call, after receiving

ACKE(QUAL=0) or AHY(POINT=1,E=1) for its call, the calling unit shall send the full called
address information on receipt of an appropriate AHYC; see section 17.1.2.1.5.
Until it receives ACKE(QUAL=0) or AHY(POINT=1,E=1), the unit shall respond to

Mode 1 AHYC messages with ACKX(QUAL=0).
17.1.2.2.4 Acknowledgements indicating progress of call
After receiving ACKE(QUAL=0) or AHY(POINT=1,E=1) for its emergency standard

data call, the waiting calling unit shall take appropriate action on receiving further
acknowledgements -ACKI(QUAL=1), ACKQ, ACKX, ACKV or ACKT(QUAL=0) - as detailed
in section 17.1.2.1.4.
Until it receives ACKE(QUAL=0) or AHY(POINT=1,E=1), the unit shall ignore other

acknowledgements.
If it receives ACKE(QUAL=0) for the call then the unit shall wait for further signalling.
17.1.2.2.5 Availability check and channel command for own call
A calling radio unit attempting access or waiting for further call set-up signalling for
an emergency standard data call shall obey the availability check procedures (see 9.2.2.2
to 9.2.2.4, 17.1.2.3.1 and 17.1.2.3.2, or 17.1.2.4.2 to 17.1.2.4.4).
The unit shall also obey the channel allocation procedures (see 9.2.2.5 and
17.1.2.3.4 or 17.1.2.4.6). Note particularly that:
i) On a control channel:
a. If the unit has not received ACKE(QUAL=0) or AHY(POINT=1,E=1) for its

emergency call, it shall ignore all GTT and GTC messages.
b. After receiving ACKE(QUAL=0) or AHY(POINT=1,E=1) for its emergency call,

the unit shall obey a GTT or GTC message only if it is individually addressed
by the GTT or GTC.

ii) On a data channel:
If the unit has not received ACKE(QUAL=0) or AHY(POINT=1,E=1) for its

emergency call, it shall ignore individually addressed GTT messages with bit O/R
set to '1'.
See rule 1 of sections 9.2.2.5 and 17.1.2.3.4, or section 17.1.2.4.6b.
After receiving ACKE(QUAL=0) or AHY(POINT=1,E=1) for a short addressing call or

after sending the full address information for an extended addressing call, the unit shall
assume that a GTT message it receives is for its requested call if PFIX/IDENT is its
individual address, bit O/R is set to '1', RATE is acceptable and, for a GTT on a data
channel, CHAN is set to the number of that data channel. If also TRANS > '0000000000'
then the unit shall regard the call link as established and may give an indication to the
service user.
17.1.2.2.6 Time-out after waiting
A calling radio unit waiting for further call set-up signalling on the channel on which
it attempted access for an emergency standard data call shall return to the previous state if
a time TW/TDW has elapsed since the last message it sent for the call, viz.
RQD(E=1), requesting the emergency call (see 17.1.2.2.1)

or SAMIS, providing extended address information for the call
or ACK(QUAL=0), sent in response to an AHY message with POINT = 1, E = 1 and
IDENT1 as the called ident or gateway. It may also indicate the failure to the
service user.
17.1.2.2.7 Other procedures
a. A calling radio unit waiting for an emergency standard data call may attempt to
cancel the call by sending a call cancellation request RQX. The procedures are as
defined in 17.1.2.1.8 for cancelling non-emergency data calls.
b. The procedures on the data channel are as defined in 17.2.
17.1.2.3 Related Procedures for All Radio Units on a Control

Channel
These procedures shall be obeyed by all radio units that are equipped to send or
receive standard data.
A radio unit attempting access or waiting for further signalling for a call may be sent
a data availability check message AHYD or Go To Transaction message GTT for an
incoming call (see 17.1.2.3.1A and 17.1.2.3.4). Note that:
i) The unit can reject an incoming individual standard data call by sending
ACKV(QUAL=1) in response to the AHYD message.

ii) A radio unit is required to obey individually addressed GTT messages and
system-wide calls (except in emergency), though it may ignore group call GTTs.
However, if making a call of its own, the unit is required to ignore GTT messages for
incoming group calls; see 17.1.2.3.4. This rule applies also to a unit that has
received an AHY or AHYD message for an incoming individual traffic channel or
data call and responded with ACK(QUAL=0) or ACKI(QUAL=0).
iii) If a unit receives and obeys a GTT message not for its own call, it returns to its
previous state at the end of the incoming call, unless the time-out (e.g. TW or TDW)
on the previous state has expired.
17.1.2.3.1 Data availability/rate check on individually

called radio unit
If a radio unit on a control channel receives an AHYD message with PFIX/IDENT1

(see below), with the same prefix and idents as the AHYD. If bit AD = 0 in the AHYD
message, the unit shall respond in the slot following the AHYD address codeword; if bit AD
= 1, a data codeword is appended (containing the calling address) and the unit shall
respond in the slot following the data codeword. For timing, see 6.2.1.3.
A) Incoming standard data call : IDENT2 not equal to DUMMYI
The unit shall send one of the following acknowledgements:
ACKX (QUAL=0) if it is not equipped to accept standard data calls at least from this
calling party.
ACKX (QUAL=1) if it cannot accept this standard data call at this time (e.g. its data
store is full or interaction has been requested but is not immediately possible).
ACKV (QUAL=1) if it does not support one or more of the requested facilities, i.e.
does not support HADT or interaction or cannot accept the wanted PORT.
ACKB (QUAL=1) if AD = 1 in the AHYD message but the appended data codeword
was not decodeable and the unit requires the message to be retransmitted.
ACK (QUAL=0) if it is available for a standard data call of this type; in this case, the
unit shall set bit MODEM to indicate whether it is able to operate at the customised
transmission rate; see 5.5.2.2.
The unit may indicate to its user the caller (by reference to PFIX/IDENT2 from the
AHYD message or PFIX2/IDENT2 from the data codeword) and whether interaction is
required, and whether the incoming call is an emergency call (by reference to bit E from the
AHYD).
Note that, unlike AHY for traffic channel calls, there is no option for the radio unit to
respond to AHYD with an intermediate acknowledgement ACKI(QUAL=0), followed by use
of a called party answer mechanism; the unit must either accept or reject the data call. (If
the data equipment is not ready immediately, the radio unit could receive and buffer the
first data transmission(s), and then introduce a pause using the Flow Control mechanisms
on the data channel.)

After receiving an AHYD message for an incoming individual standard data call and
responding with ACK(QUAL=0), the unit shall ignore:
- group call GTC messages as specified in section 9.2.2.5 rule 2 or 3,
- group call GTT messages as specified in section 17.1.2.3.4 rule 2 or 4,
until either:
a. it receives a channel command for the incoming data call (i.e. a GTT message with
PFIX/IDENT as its individual address, bit O/R set to '0' and an acceptable RATE),
or
b. it assumes that the call will not take place; see 17.1.2.3.2.
If, while waiting for an incoming individual standard data call, a radio unit receives a
repeat AHYD then it shall send the appropriate acknowledgement; also, for
ACK(QUAL=0), it shall restart its timer TA/TDA (see 17.1.2.3.2).
If, while waiting for an incoming traffic channel call (having sent ACK(QUAL=0) or
ACKI(QUAL=0) in response to an AHY message), a radio unit receives an AHYD for an
incoming individual standard data call, the unit shall abandon the old call and obey the
AHYD; also, if currently attempting an "off-hook" or "on-hook" RQQ transaction for the
original call, it shall abandon the RQQ transaction - see 13.1.2.
B) "No-call" test availability check : IDENT2 = DUMMYI
ACKX (QUAL=0) - The unit could not at any time accept a standard data call with
all the specified facilities.
ACK (QUAL=0) - Unit is in radio contact and is suitably equipped to support the
particular parameter settings in the AHYD. Bit MODEM
indicates whether it is able to operate at the customised
transmission rate.
17.1.2.3.2 Cancelling waiting state of individually called

radio unit
A radio unit that has received an AHYD message for an incoming individual
standard data call (see 17.1.2.3.1A), and responded with ACK(QUAL=0), shall assume that
the call will not take place if one of the following occurs:
a. It has not received a GTT message for the call at a time TA/TDA after the last
ACK(QUAL=0) it sent in response to an AHYD for the call.
b. It receives an AHYX message with the same prefix and idents as the AHYD. (The
unit shall respond in the next slot with ACK(QUAL=1), as required by section
9.2.2.4.)

c. It receives an AHYD message checking its availability for a different incoming
individual standard data call (i.e. bit E and/or the calling address and/or the PORT is
different from the original AHYD).
d. It receives an AHY message checking its availability for an incoming traffic channel
call.
The unit may indicate to the service user that the expected data call will not take
place. In cases a. and b., the unit shall note that:
- rule 2 or 3 of section 9.2.2.5, and
- rule 2 or 4 of section 17.1.2.3.4
(requiring the unit to ignore GTC/GTT messages for incoming group calls) no longer apply.
In case c., the unit shall obey the procedures in 17.1.2.3.1A for the new call. In case d., the
unit shall obey the procedures in 9.2.2.2A for the new call.
17.1.2.3.3 Receiving AHYD message addressed to a group

or ALLI
If a radio unit on a control channel receives an AHYD message with:
- PFIX/IDENT1 matching any of its group addresses for this system or
- IDENT1 set to the system-wide all-call ident ALLI
then it may accept the call information contained in the AHYD codeword, but shall transmit
no response. The unit may then assume that the next GTT(O/R=0) message for this
respective group or ALLI address received on this channel within the following time TA/TDA
corresponds to the:
i) calling address
(PFIX/IDENT2 or PFIX2/IDENT2 from an appended data codeword)
ii) E bit
iii) PORT
announced by the AHYD message.
If the unit has not received a GTT(O/R=0) message at a time TA/TDA after the last
received AHYD for the call, or if it receives an AHYD message for different call to this
address, then it may assume that the expected call will not take place.
17.1.2.3.4 Data channel assignment
A radio unit on a control channel shall check all GTT messages it receives to see

PFIX/IDENT from the GTT message matches its individual address or
PFIX/IDENT matches any of its group addresses for this system or
IDENT is the system-wide all-call ident ALLI.
If the GTT message is addressed to it, and it is able to receive standard data at the
transmission rate specified by field RATE, the unit shall use the appropriate rule below to
decide whether to obey the command:
1. If the unit is making an emergency call (RQE or RQD(E=1)) and has not received
ACKE(QUAL=0) or AHY(E=1) for its call, it shall ignore the GTT message.
If the unit is waiting for further signalling for its emergency call, after receiving
ACKE(QUAL=0) or AHY(E=1) for the call, it shall obey the GTT message if and only
if it is individually addressed by the GTT (i.e. its individual address is PFIX/IDENT).
2. Otherwise:
If the unit is waiting for an incoming individual emergency call (see 9.2.2.2A and
17.1.2.3.1A), it shall obey the GTT message if and only if it is individually addressed
by the GTT.
3. Otherwise:
If the unit is attempting access or waiting for further signalling for a non-emergency
call or transaction, it shall obey the GTT message if and only if:
- it is individually addressed by the GTT,
or IDENT is set to ALLI and the unit knows that it is not the calling unit (i.e. it is
not making a system-wide standard data call or has received an AHYD
message indicating another caller - see 17.1.2.3.3).
4. Otherwise:
If the unit is waiting for an incoming non-emergency individual traffic channel or data
call (see 9.2.2.2A and 17.1.2.3.1A), it shall obey the GTT message if and only if:
- it is individually addressed by the GTT,
or IDENT is set to ALLI (unless the unit has received an AHYD message
indicating that it was the calling party in the call).
5. Otherwise (i.e. if not waiting for any call or transaction):
The unit shall obey the GTT message, unless:
IDENT is set to ALLI and the unit has received an AHYD message indicating that it
was the calling party in the call
or PFIX/IDENT is one of the unit's group addresses and the unit cannot or does
not wish to accept this call, for example:
- the service user does not wish to receive group calls, or

- the unit has received an AHYD message for this group address
indicating that it was the calling party in the call, or
- the unit has received an AHYD message for this group address
indicating an unacceptable calling party or PORT, or
- the unit has not received an AHYD message for this group address
and it needs the AHYD information for reliable operation (e.g. some
calls to this address are of normal accuracy whilst others employ
HADT).
If the unit is required to obey the GTT command, it shall perform the following
actions:
a. The unit shall tune to the designated forward channel and shall be able to receive
on the data channel within 35 ms after the end of the GTT message.
It shall be prepared to receive signalling at the transmission rate specified by field

RATE in the GTT message.
b. If bit O/R from the GTT message is set to '1', the unit shall note that it is the calling
party. Otherwise it is a called party.
Note that, if the unit is a called party and is waiting for an incoming standard data
call for this address (see 17.1.2.3.1 and 17.1.2.3.3), then it may take the PORT and
the calling address (if fully supplied) from the AHYD message.
c. The unit shall note PFIX, IDENT and TRANS from the GTT message.
i) For TRANS > '0000000000', the unit shall expect to receive signalling on the
data channel for this transaction number.
ii) For TRANS = '0000000000', the unit shall expect to receive a further GTT
message on the data channel to assign a transaction number for the link.
The unit shall assume that the next GTT message, containing this address, bit
O/R and bit RATE, and with CHAN equal to the number of the data channel,
received within the following time TDG, corresponds to this call - see
17.1.2.4.6a.
If a calling unit has not received the expected GTT(O/R=1) message on the
data channel at a time TDG after the control channel GTT, then it shall return
to the idle state on the control channel and may indicate the call failure to the
service user.
If a called unit has not received the expected GTT(O/R=0) message on the
data channel at a time TDG after the control channel GTT, or if it receives an
individually addressed AHYD message for a different call to this address, then
it shall assume that the expected call will not be received and may give an
indication to the service user.
d. The unit shall note the channel number of the control channel.
It may also give an indication of the event to the service user.

If the unit does not obey a GTT message, and the designated data channel is the control
channel on which the message was received, then the unit shall enter the control channel
acquisition procedures.
17.1.2.4 Related Procedures for All Radio Units on a Data

Channel
These procedures shall be obeyed by all radio units which are equipped to request
or receive calls on a data channel. (Other procedures for radio units on a data channel are
included in sections 17.2.)
17.1.2.4.1 Instruction to send extended address information
extended addressing standard data calls.
If a radio unit on a data channel receives an AHYC message with PFIX/IDENT2

matching its individual address then it shall either send address information or transmit
ACKX(QUAL=0), as indicated below. For timing on a 1200 bit/s data channel, see section
6.2.1.3.
If the unit has sent an extended addressing RQD(E=0) request, or has received
ACKE or AHY(E=1) for an extended addressing RQD(E=1)
and IDENT1 matches IDENT1 from the request
and SLOTS corresponds to the request
(i.e. if IDENT1 = PSTNGI and unit's call requires > 9 PSTN digits then SLOTS = '10'
if IDENT1 = PSTNGI and unit's call requires < 10 PSTN digits then SLOTS =
'01' or '10'
if IDENT1 is not equal to PSTNGI then SLOTS = '01')
then it shall transmit the full called address information, conforming to the
codeword formats defined in section 5.6.1.2.2 (SAMIS, Mode 1).
Otherwise
the unit shall transmit ACKX(QUAL=0), with the same prefix and idents as the
AHYC.

17.1.2.4.2 Data availability/rate check on individually
called radio unit
If a radio unit on a data channel receives an AHYD message with PFIX/IDENT1

(see below), with the same prefix and idents as the AHYD. If bit AD = 0 in the AHYD
message, the unit shall respond in the slot following the AHYD address codeword; if bit AD
= 1, a data codeword is appended (containing the calling address) and the unit shall
respond in the slot following the data codeword. For timing on a 1200 bit/s data channel,
see 6.2.1.3.
A) Incoming standard data call : IDENT2 not equal to DUMMYI
The unit shall send one of the following acknowledgements:
ACKX (QUAL=0) if it is not equipped to accept standard data calls from this calling
party.
ACKX (QUAL=1) if it cannot accept this standard data call at this time (e.g. it cannot
process concurrent calls or its data store is full or interaction has been requested
but is not immediately possible).
ACKV (QUAL=1) if it does not support one or more of the requested facilities, i.e.
does not support HADT or interaction or cannot accept the wanted PORT.
ACKB (QUAL=1) if AD = 1 in the AHYD message but the appended data codeword
was not decodeable and the unit requires the message to be retransmitted.
ACK (QUAL=0) if it is available for a standard data call of this type; i.e. it can
support the particular parameter settings of the AHYD. In this case, the unit shall set
bit MODEM to the value appropriate for that channel; see 5.5.2.2.
The unit may indicate to its user the caller (by reference to PFIX/IDENT2 from the AHYD
message or PFIX2/IDENT2 from the data codeword) and whether interaction is required,
and whether the incoming call is an emergency call (by reference to bit E from the AHYD).
After receiving an AHYD message for an incoming individual standard data call and
responding with ACK(QUAL=0), the unit shall wait for a GTT message for the call (i.e. a
GTT message with PFIX/IDENT as its individual address, bit O/R set to '0', an acceptable
RATE and CHAN set to the number of this data channel), or until it assumes that the call
will not take place (see 17.1.2.4.4).
If, while waiting for an incoming individual standard data call, a radio unit receives a repeat
AHYD then it shall send the appropriate acknowledgement; also, for ACK(QUAL=0), it
shall restart its timer TA/TDA.
B) "No-call" test availability check : IDENT2 = DUMMYI

ACKX (QUAL=0) - The unit could not at any time accept a standard data call with
the parameter settings of the AHYD.
ACK (QUAL=0) - Unit is in radio contact and could at times accept a data call
with the parameter settings of the AHYD.
This availability check does not start or restart any timer.
17.1.2.4.3 Cancelling waiting state of individually called radio unit
If a radio unit on a data channel receives an AHYX message with PFIX/IDENT1

matching its individual address then it shall respond in the next slot with ACK(QUAL=1),
with the same prefix and idents as the AHYX.
A radio unit that has received an AHYD message for an incoming individual
standard data call (see 17.1.2.4.2A), and responded with ACK(QUAL=0), shall assume that
the call will not take place if one of the following occurs:
a. It has not received a GTT message for the call at a time TDA after the last
ACK(QUAL=0) it sent in response to an AHYD for the call.
b. It receives an AHYX message with the same prefix and idents as AHYD.
c. It receives an AHYD message checking its availability for a different incoming

individual standard data call (i.e. bit E and/or the calling address and/or the PORT is
different from the original AHYD).
The unit may indicate to the service user that the expected data call will not take place. In
case c., the unit shall obey the procedures in 17.1.2.4.2A for the new call.
17.1.2.4.4 Receiving AHYD message addressed to a group or ALLI
If a radio unit on a data channel receives an AHYD message with
PFIX/IDENT1 matching any of its group addresses for this system
or IDENT1 set to the system-wide all-call ident ALLI
then it may accept the call information contained in the AHYD codeword and indicate it, but
shall transmit no response. The unit may then assume that the next GTT(O/R=0) message,
for this group or ALLI address and with CHAN equal to the number of this data channel,
received within the following time TDA corresponds to the:
i) calling address
(PFIX/IDENT2 or PFIX2/IDENT2 from an appended data codeword)
ii) E bit
iii) PORT
announced by the AHYD message.

If the unit has not received a GTT(O/R=0) message at a time TDA after the last
received AHYD for the call, or if it receives an AHYD message for a different call to this
address, then it may assume that the expected call will not take place.
17.1.2.4.5 Receiving GTT message for same data channel
If a radio unit on a data channel receives a GTT message with channel number
CHAN equal to the number of the data channel then it shall obey the procedure in this
section. The procedure if CHAN is not equal to the number of the data channel is specified
in section 17.2.6.2 (In-call transfer).
A radio unit on a data channel shall check all GTT messages it receives to see
whether the channel number CHAN is equal to the number of this data channel and
PFIX/IDENT from the GTT message matches its individual address
or PFIX/IDENT matches any of its group addresses for this system
or IDENT is the system-wide all-call ident ALLI.
If the GTT message is addressed to it, and TRANS >'0000000000', and it is able to
receive on this data channel at the specified RATE, then the unit shall use the appropriate
rule below to decide whether to accept the GTT:
a. If the unit is currently waiting for a transaction number for this address and bit O/R,
having received a GTT message on a control channel with TRANS = '0000000000'
(see 17.1.2.3.4c.), then it shall accept the GTT message as applying to that call.
b. If bit O/R is set to '1' and PFIX/IDENT from the GTT message matches its individual
address, then:
- If the unit is making an emergency call RQD(E=1) and has not received
ACKE(QUAL=0) or AHY(E=1), then it shall ignore the GTT.
- Otherwise, a unit making a data call RQD(E=0/1) shall accept the GTT
message.
c. If bit O/R is set to '0' and PFIX/IDENT from the GTT message matches its individual
address, and the unit is waiting for an incoming individual data call, having received
an AHYD message and responded with ACK(QUAL=0), then it shall accept the GTT
message.
d. Otherwise, the unit may accept the GTT message.
If the unit accepts the GTT message, it shall perform the following actions:
i) It shall be prepared to receive signalling for this transaction number.
ii) If bit O/R from the GTT message is set to '1', the unit shall note that it is the
calling party. Otherwise it is a called party.

If the unit is a called party and is waiting for an incoming standard data call for this
address (see 17.1.2.4.3 and 17.1.2.4.5) then it may take the PORT and the calling address
(if fully supplied) from the AHYD message.
It may also give an indication to the service user.

17.2 Behaviour on the Data Channel
17.2.0 General
These procedures shall be obeyed by all stations on an allocated data channel.

More than one data channel may be operated at a base station and radio units may be
transferred between channels, for example to provide an even load sharing.
17.2.0.1 Signalling Formats
The signalling format shall conform to Sections 3.1 and 3.2 (but see transmission
rate below).
The Data Channel codeword synchronisation sequence shall always be SYNT.
In addition to the 1200 bit/s standard transmission rate a network may offer or a
radio unit may be equipped for a customised rate.
17.2.0.2 General behaviour of a TSC on a data channel
Every message transmitted by a TSC shall start with SYNT. Except for the first
message in a transmission, SYNT shall be contained in a DCSC codeword.
The TSC shall monitor the return channel and shall be prepared to receive
messages with timing according to 17.2.0.3 below.
Many messages require or invite individual response transmissions from radio units
with timing according to 17.2.0.3. The TSC shall not transmit any combination of messages
which could result in any of these required responses coinciding to produce channel
interference.
It is not necessary to provide synchronisation between the Control Channel and the
Data Channel.
17.2.0.3 General behaviour of a radio unit on a data channel
Whilst on a data channel a radio unit shall not indicate to its user or any attached
equipment any information relating to the address or data codewords of any message
except those pertinent to that radio unit. However, the radio unit itself may use the
information in non-pertinent address codewords to enhance its performance, e.g. to save
energy or optimise random access.
A radio unit may support more than one concurrent standard data call.
A radio unit shall start a system dependant timer, TDX or TDN, for an individual or
group call respectively, for the TRANS when it receives the GTT message. Timer TDX shall
be restarted whenever the radio unit receives any message relevant to the TRANS except
DAHYX. If timer TDX or TDN expires the radio unit shall deem the TRANS to be closed.

If at any time a radio unit deems that it no longer has any open TRANS it shall leave
the data channel and return to control channel acquisition procedures.
A radio unit shall attempt to decode DCSC codewords whilst receiving on the
forward data channel. If a time TDL elapses without being able to decode any DCSC
codeword the radio unit shall assume that it is out of range and shall enter channel
acquisition procedures.
A radio unit shall not transmit on the return channel unless it is either to make
random access within an appropriate random access frame in an unwithdrawn slot or is
invited to transmit on an individual basis, which latter opportunity may be specified by either
the radio unit's individual address or an individual TRANS (see below).
Every message transmitted by a radio unit shall start with SYNT. Radio unit
transmission timing shall conform either to the requirements of 6.2.1.3 but with timing
starting from the end of the last codeword of any invoking message from the TSC or to the
timing rules specified for the particular customised transmission rate for that data call (see
Appendix 6).
17.2.1 Random Access Protocol for the Data Channel
A Random Access protocol is used on the data channel which is based on that
found on the control channel but differing considerably in detail.
Random access on a data channel is used by radio units to:
a) query an unexpected delay in user data transfer, or
b) send expedited data such as RESET, or
c) close one or all of its TRANS, or
d) attempt to set up a concurrent call.
17.2.1.1 TSC Random Access Facilities
17.2.1.1.1 Marking Random Access Frames
The TSC shall designate sections of a return data channel as random access
frames, each containing a whole number of timeslots. Every frame is marked by a
codeword which contains an Aloha submessage and an ND parameter indicating the frame
size.
The zero aloha number (ND=0) is a special value indicating "this is not the
beginning of a frame". Filler messages each consisting of a DCSC codeword and a
codeword containing an aloha submessage with ND='0' may be used.

17.2.1.1.2 Addressing the radio unit population
The TSC may invite random access responses from all radio units, or may restrict
access to a specific individual or group of units using the TRANS parameter in the
data-aloha codeword.
For TRANS='0000000000', there is no restriction, i.e. all radio units may attempt
access subject to the other random access rules specified in this section. For all other
values of TRANS, access is restricted to the one or more units corresponding to that
TRANS. This will typically be used for a group TRANS to restrict a frame for use by one
particular group only. Note that unlike the control channel random access mechanism, a
response is never demanded, even when an individual TRANS is specified.
17.2.1.1.3 Inviting specific types of random access message
The TSC may limit random access to particular types of message by means of
specific data-aloha submessages: DAL, DALG, DALN (see 5.8.2.).
17.2.1.1.4 TSC responses
After receiving a random access message, the TSC shall send a response; valid
responses are specified in the sections detailing the call procedures. The response may be
sent in the slot following the random access message or it may be delayed. The TSC shall
specify, using the WF field in the data-aloha submessage, the number of frames that a
radio unit must wait for before attempting a further random access transmission of the
message (see 17.2.1.2.6).
17.2.1.1.5 Withdrawing slots from frames
The TSC shall ensure that slot synchronism is maintained within any random access
frame, e.g. at 1200 bit/s if an AHYD message within the frame contains an appended data
codeword the TSC shall add an appropriate filler data codeword.
The only invoking messages the TSC may transmit within the random access
frames are:
- DAHYX, DAHYZ, DAHY, AHYD, and AHYC
(Random access is inhibited in the first following return slot after the messages.)
- SITH (individual or group) such that the user data message extends at least to the
end of the return channel random access frame.
17.2.1.2 Radio Unit Random Access Protocol
These procedures shall be obeyed by all radio units that are required to attempt
random access on the data channel.

The various criteria given below must all be satisfied before a random access
transmission is made.
17.2.1.2.1 Checking for TRANS restriction
A radio unit is permitted to transmit a non-emergency random access message only

if the related transaction is invited by the TSC, by means of the TRANS parameter in the
data-aloha submessage. Thus access is permitted by the radio unit if either
- RTRANS = '0000000000', or
- The specified RTRANS in the data-aloha submessage matches any of the

radio unit's currently active TRANS' to be transmitted.
An emergency request, RQD(E=1), can be transmitted regardless of any TRANS

restrictions.
17.2.1.2.2 Checking the Aloha function
A radio unit shall note the function from each data-aloha submessage it receives.
The requests invited (subject to other restrictions) by each function are as follows:
DAL invites DRQX, DRQZ, DRUGI, DRQG, RQD(E=1), RQD(E=0), RQX
DALG invites DRQG, RQD(E=1)
DALN invites DRQX, DRQZ, DRUGI, RQD(E=1), RQD(E=0), RQX
17.2.1.2.3 Frames defined by Aloha numbers
The number of slots in a frame is equal to the aloha number within the frame
marking data-aloha submessage, and can take any value in the range 1-31.
The radio unit shall monitor the forward data channel and shall note which sections
of the return data channel are designated as random access frames. The first access slot
in a frame starts at the end of a codeword containing a data aloha submessage with a
non-zero aloha number, and respective coincidence is maintained for subsequent slots.
17.2.1.2.4 Choosing a slot from a new frame
A radio unit that requires to select a slot from a new frame shall wait for a message
marking a frame available for it to use; it shall then choose a slot randomly from the
specified frame length, using a uniform distribution. The unit shall transmit its message in
the chosen slot, provided that the slot is not withdrawn (see 17.2.1.2.5). For access timing
see section 6.2.1.3 or as specified for the customised rate in use.
A radio unit shall not chose more than one slot from a frame.

17.2.1.2.5 Check for withdrawn slot
Before transmitting its random access message in a chosen slot, except for case (a)
below, a radio unit shall check whether the slot is still available for random access by
attempting to decode the final codeword in the slot immediately preceding the chosen slot.
If any of the following is received then random access is permitted:
a) reception of a SITH address codeword as the last codeword in any slot of that frame
before the chosen access slot, and
b) any address codeword containing an Aloha number DN, and RTRANS =

'0000000000' or any currently active TRANS for this RU, and
c) the following address codewords:
AHYD or AHYC, either only with AD = '1'

(unless the AHYD or AHYC is addressed to the unit)
GTT
Note that, unless covered by rule (a), all received codewords which are spare,
reserved or undecodeable do not permit random access in the next slot.
17.2.1.2.6 Noting the response delay
A radio unit shall note the delay parameter WF from each data-aloha submessage it
receives.
If a random access attempt has not been acknowledged (see 17.2.2 for listed
acknowledgements) before WF frames have been received, then the random access
attempt may be repeated if the time-out or allowable number of tries permits.
17.2.1.2.7 Retry decision and time-outs
After sending a random access message, a radio unit shall wait to receive a
response from the TSC. Various messages shall be accepted as a valid response (as
specified in the sections detailing the call procedures and summarised in 17.2.2).
If the radio unit does not receive a response before WF subsequent frames have
been received, it shall assume that the message was unsuccessful.
Then it shall either:
a. abandon its access attempt (see below), or
b. attempt a further random access transmission. However, if the unit receives a valid
response before sending a repeat message, it shall accept the response and not
retransmit.
The radio unit shall abandon its access attempt if it has sent the maximum permitted
number of transmissions, NDR, and received no valid response.

The unit shall also operate a time-out, TDC, on the maximum time it spends trying to
achieve access, and abandon the attempt if this time-out expires.
If the unit's access attempt to close all its TRANS fails then it shall deem them all to
be closed and shall relinquish the data channel and attempt to return to the control
channel. If the unit's access attempt to progress or close one TRANS {see 17.2.1 (a, b, or
c)} fails then it shall deem the TRANS to be closed. If the attempt to set up a concurrent call
fails then it shall abandon the attempt.
17.2.2. Messages, Submessages, and Responses on the data

channel
Data channel procedures are ranked from highest to lowest as:

a) closure of all or one TRANS,
b) transfer to another data channel,
c) transfer of expedited data, and
d) transfer of user data and call set-up.
A current procedure of one rank may be interrupted or aborted by the TSC or radio
unit at any opportunity by using an appropriate message to enter a procedure of a higher
rank.
This subsection lists all the various messages and submessages that can be
transmitted on a data channel, together with the appropriate responses in their ranking
order. Descriptions of the messages are found in section 5, and their uses follow from this.
A Submessage is preceded by "(S)".
All random access attempts are subject to the time-outs and re-try limits given in
17.2.1.2.7. Additionally some random access attempts are prohibited before time-outs have
expired; and these accesses are marked "(L)"
All messages from the TSC are to individual radio units except those specifically
indicated for groups.

LIST OF MESSAGES, SUBMESSAGES AND RESPONSES
Message Receiver Response(s)
CLEAR RU None, but deem all TRANS closed.
RQD TSC See 17.1

AHYD RU See 17.1
AHYC RU SAMIS Extended address message
GTT RU No transmitted response. See 17.1 and 17.2.6
DRUGI (TNITEL < 63) TSC DAHYX, DAHYZ, (S)GO
DRUGI (RNITEL < 63) TSC DAHYX, DAHYZ, DACKD(REASON='001'), SITH
DRUGI(T'L =R'L = 63) TSC DAHYX, DAHYZ, None (await developments)
DRQG TSC Ignore, DAHYX (GROUP), SITH group
DRQZ TSC DAHYX, DACKZ
DRQX TSC DACKD(REASON='000)
DAHY RU DRQX, DRQZ(REASON='000), DRUGI

DAHYZ RU DRQX, DACKZ
DAHYX (TRANS > 0) RU DACKD(REASON = '000')
(S)DAL RU DRQX, DRQZ, RQD, DRQG, DRUGI, RLA (L)

(S)DALG RU DRQX, DRQG, RQD(E='1')
(S)DALN RU DRQX, DRQZ, RQD, DRUGI, RLA (L)
(S)GO after (S)DACK RU DRQX, DRQZ, DACKD(REASON = '001'), SITH

(S)GO (no (S)DACK) RU DRQX, DRQZ, RLA
(S)GO (+ (S)DACK) TSC DAHYX, DAHYZ, DACKD(REASON = 001'), SITH
SACK Either DAHYX or DRQX, DAHYZ or DRQZ, SITH

SACK (incomplete) Either DAHYX or DRQX, DAHYZ or DRQZ, RLA
RLA Either DAHYX or DRQX, DAHYZ or DRQZ, (S)DACK(P/N),
and SACK
SITH Either DAHYX or DRQX, DAHYZ or DRQZ, (S)DACK(P/N),
and SACK

17.2.3 Transmission and correction of user's data
In this sub-section there are major differences between the actions required of a
station sending user data and one receiving it. These stations are referred to as data
sending and data receiving stations (DSS and DRS) respectively. There are only minor
differences between the actions to be taken by TSCs and radio units. For this reason,
except where noted the procedures described here apply to both TSCs and radio units,
although each shall always conform to the appropriate transmission timing requirements.
Due to the bidirectional facilities provided by this standard a data sending station
may also be a data receiving station at the same time. Such a station shall conform to the
appropriate procedures according to the particular direction of data transmission under
immediate consideration at any instant.
All the procedures specified here shall be understood to refer only to the one
TRANS under consideration. Every message not bearing that TRANS in its appropriate
field(s) shall be deemed irrelevant. Every TRANS being processed by any station shall be
treated as a separate entity, and interleaving of messages relevant to various radio units
and TRANS may take place. Such interleaving is not mentioned further in this section.
17.2.3.1 Procedures for Data Sending Stations (DSS)
17.2.3.1.0 Tmessages and dataitems
User data consists of one or more Tmessages. A Tmessage consists of one or more
dataitems. No dataitem shall contain data from more than one Tmessage. The last
dataitem of one Tmessage may be adjacent to the first dataitem of a following Tmessage.
See 17.2.3.1.4.1 for use of the MORE bit for marking the end of a Tmessage.
17.2.3.1.1 Sending a User Data Message to a Group
A group link may convey only one Tmessage in a single dataitem which may not
include more user data (including any HADT checksum) than that which can be
accommodated in the user data field of its address codeword plus NG data codewords,
where NG = 1, 3, 7, 15, 31, 63, 127, or 255 as prearranged.
Within the link the group dataitem may be repeated a prearranged number of times.
It is permitted to transmit other messages between these dataitems providing the total time
between the GTT message and the end of the last codeword of the final transmission of
the dataitem does not exceed TDN seconds. For example, a message with DALG
submessage bearing the group TRANS to mark a random access frame could be sent after
transmission of a group message. Lack of any random access attempt in that frame might
then be taken by the TSC to mean that no following repeat of the dataitem is required.

17.2.3.1.2 Maximum Length of a dataitem in an Individual Link
For an individual link no dataitem may include more data than that which can be
accommodated in the user data field of its address codeword plus 62 data codewords. The
RNITEL field in the GO submessage indicates to a DSS how much data the data receiving
station (DRS) can receive. A DSS shall not transmit any quantity of user data unless the
DRS has previously indicated that it can accept at least that quantity, but a lesser quantity
may be sent.
17.2.3.1.3 Responding to a GO Submessage in an individual link
Upon receiving a data acknowledgement (DACK) submessage followed by a GO

submessage (which may be in the same message) a DSS shall decide whether a higher
ranking message (see 17.2.2) or an old or new dataitem should be sent, and if the last,
what user data will compose the new dataitem (if any) which will be sent. Once a dataitem
has been sent then all or parts of that data shall be repeated as required by the DRS but
no other user data shall be sent until the DRS indicates by a positive submessage (PACK)
that the dataitem has been completely received. If a DSS receives a data
acknowledgement and GO submessage and the limit of response time is reached before it
is able to send a dataitem it shall transmit a DACKD(REASON='001') message.
17.2.3.1.4 Sending Fragments in an individual link
Transmission of each dataitem shall be achieved in one or more fragments. The first
fragment shall include the entire dataitem. Other fragments shall only include those parts of
the dataitem for which the DRS demands repetition. The DRS may demand that the entire
dataitem be repeated.
After receiving a SACK message or GO submessage, the DSS shall decide whether
to send a fragment or a higher ranking message, see 17.2.2.
17.2.3.1.4.1 Setting the fields in SITH
The control fields in the fragment address codeword, SITH, shall be set as follows:
ITENUM - For each direction of user data transmission the first dataitem in a TRANS or
after a reset operation shall have ITENUM = '0'. Any further dataitems in that
TRANS shall have ITENUM values which alternate '1' and '0'.
MORE - shall have the value '1' for all dataitems except for the last dataitem of each
Tmessage, or TRANS if the user does not divide the data into Tmessages.
MORE shall be set to '0' in a group dataitem.
FRAGL - shall be set to the number of data codewords, if any, which follow SITH.
TNITEL - shall be set to indicate the maximum number of data codewords proposed for
the next dataitem. Its null value is '111111' and is used if no further dataitem
is immediately proposed.

LASTBIT - shall be set to indicate the codeword bit number, see 17.0.2.5, of the last bit
of user data in the dataitem unless modified by the HADT coding rules, see
17.2.3.1.4.2.
In a dataitem (i.e. the initial fragment) user data shall start in the first bit of the
USER DATA field and continue in bit order through this field and through any appended
data codewords until all user data in the dataitem have been included. A further information
bit following the last user data in the dataitem shall be a marker bit, '1'. The marker bit shall
always be provided even if that requires addition of an extra data codeword. All remaining
bits in the user data field of the last codeword shall be '0's unless subsequently altered by
HADT coding, see below.
17.2.3.1.4.2 HADT Coding
The SITH codeword and the user data in it is not included in HADT coding.
If HADT is invoked then the last 15 bits of appended data in each dataitem shall
consist of a dataitem checksum of all the other user information bits in appended data
codewords in the dataitem (see Figure 17.2). The 15 bits of the checksum are calculated as
follows:
The information field of each appended data codeword containing user data or the
end of data marker shall be considered to be the co-efficients of a polynomial having terms
x61 down to x15. This polynomial shall be divided modulo-2 by the generating polynomial;
x15 + x14 + x11 + x10 + x9 + x6 + x5 + x4 + x + 1.
The co-efficients of the terms x14 down to x0 found at the completion of the division are
termed the HADT remainder.
All the HADT remainders for the dataitem shall be modulo-2 added to form a 15-bit
dataitem checksum. If bit positions 34-48 in the final user data codeword are all '0's then
the dataitem checksum shall replace these '0's; otherwise a further data codeword shall be
appended with bits 1-33 = '0' and the dataitem checksum shall occupy the bits 34-48 and
16 shall be added to the value of the LASTBIT field in SITH. The value in the FRAGL field
of SITH shall include the added codeword.
FIG 17.2. SITH plus 4 Additional Data Codewords (ADC)
------------------Expanded ADC no.4------------------
SITH ADC1 ADC2 ADC3 1 USER DATA HADT PARITY

111101001--00 FIELD
(Bit no.) 1 2 ↑ 33 34 48 49 64
---- End of user data marker
17.2.3.1.5 Actions after sending a Fragment or RLA Message
Within subsection 17.2.3.1.5 and dependant subsections the specified actions only
apply if the DSS decides not to close the TRANS or send expedited data.

After sending a fragment or a "Repeat Last Acknowledgement" (RLA) message,
- a radio unit shall immediately restart its timer TDH. If no acknowledgement is

received before timer TDH expires and a suitable random access frame occurs the
radio unit may attempt random access with a RLA message.
- if a TSC receives a partial or no acknowledgement from the radio unit it shall either
repeat the fragment or send an RLA message. The TSC shall only repeat that
fragment to which it was expecting an acknowledgement.
- if a radio unit receives no acknowledgement from the TSC but receives a GO

submessage it shall send an RLA message,
- if a radio unit receives a partial acknowledgement it shall send an RLA message.
17.2.3.1.5.1 After sending an RLA message
- if the acknowledgement received is the same as the last complete acknowledgement

received then the DSS shall, at the next GO submessage, repeat the last fragment sent,
- if the acknowledgement received is appropriate to the last fragment sent then the DSS
shall act on that acknowledgement according to the rules specified below.
17.2.3.1.5.2 After sending a fragment
- if a DSS receives a NACK submessage in acknowledgement it shall repeat the whole

dataitem when it receives an appropriate GO submessage.
- if the DSS receives a SACK message in acknowledgement it shall send a fragment

consisting of a SITH address codeword and ONLY the data codewords corresponding to
the assigned EFLAGs set to '1' in the SACK message. This is irrespective of the setting of
EFLAGs in any previous SACK message relevant to that dataitem. (If no assigned EFLAGs
are set in a SACK message the DSS shall repeat the whole fragment or send an RLA
message). Note that in a dataitem the user data in the SITH is repeated in all fragments of
that dataitem,
- if the DSS receives a PACK submessage, it shall proceed to the next dataitem, if any. If it
receives a relevant GO submessage before it has a complete Tmessage ready for
transmission then it shall transmit a DACKD(REASON = '001') message.
If a DSS sends a fragment with more than 22 included data codewords or an RLA
message after having last sent such a fragment it shall prepare to receive an
acknowledgement with appended codeword.

17.2.3.2 Procedures for Data Receiving Stations (DRS)
17.2.3.2.1 Minimum Reception Storage when Starting a Call
A DRS shall indicate to the DSS how much data it can receive initially. Compliance
with a GTT message is one method of giving this indication. Otherwise a DRS shall give the
indication in the RNITEL field of a GO submessage.
For an individual link a radio unit shall disregard a GTT message unless it can
receive a message with at least 22 fully used data codewords. For a group link a radio unit
shall disregard a GTT message unless it can receive a message with at least a preset
number, NG, of data codewords,see 17.2.3.1.1.
17.2.3.2.2 Receiving a Group Message
A radio unit which receives a SITH codeword of a group message shall count the
number of times that SITH has been received within the group link, and shall also attempt
to decode the message. If the group message has been repeated then amalgamation of
the various decoding attempts is permitted. HADT decoding shall be used when
appropriate. The radio unit shall then decide whether to accept the message, and if so it
may consider the call to be complete and the TRANS to be closed. If it does not accept the
message and timer TDN has not expired and the relevant SITH count is less than NDN and
an appropriate random access frame is marked then the RU may attempt random access
with the DRQG(TRANS=group) message to request a message repetition. If either timer
TDN expires or the SITH count equals NDN then the RU shall consider the call to be
complete and its TRANS closed.
17.2.3.2.3 Decoding an Individual Fragment
After decoding a SITH address codeword and attempting to decode every following
data codeword in a fragment as determined by the received value of FRAGL, a DRS in an
individual TRANS shall decide whether to send a higher ranking message or shall choose
the appropiate acknowledgement to send. A radio unit shall also restart its timer TDE:
- if the DRS finds any inconsistency in a fragment when compared to prior states,
fragments or acknowledgements, e.g. FRAGL exceeding the previous RNITEL
value or an unexpected ITENUM value, etc., according to the severity or persistence
of the condition it may demand closure of the TRANS or send a RESET request or
request repeat of the dataitem or fragment,
- if the DRS decides to ask for the entire dataitem to be repeated it shall send a
NACK submessage,
- if the DRS decides to ask for any selection of data codewords to be repeated, it
shall send a SACK message.
- if the HADT mode was invoked by the call set up procedures and the entire
dataitem has been decoded the DRS shall modulo-2 divide the data in each data
codeword by the generator polynomial given in 17.2.3.1 above to yield HADT
remainders and shall modulo-2 add these HADT remainders together to form a

dataitem checksum. If this checksum does not equal the final 15 data bits of the
received dataitem then the DRS shall send a NACK message.
- if the HADT mode was invoked and LASTBIT value is larger than 48 then the last
codeword contains only HADT check sum and the user data ends in the previous
codeword at the point of LASTBIT-16 (see 17.2.3.1.4.2)
- if the LASTBIT value is 48 then the last additional data codeword does not contain
any user data (see 17.2.3.1.4.1).
- if the DRS is satisfied that the entire dataitem can be accepted then it shall send a
PACK submessage. The RNITEL field shall be set either to the value of the TNITEL
field in the SITH codeword heading the accepted dataitem or to a lower value if the
DRS is unable to accept that amount of data.
If the DRS receives an RLA message instead of a fragment then it shall repeat the
last acknowledgement sent.
If a radio unit, after sending a GO submessage with RNITEL not equal to '111111',
does not receive another relevant message before timer TDE expires and then a suitable
random access frame occurs the radio unit may attempt random access with a DRUGI
message.
The above-mentioned acknowledgements shall conform to the following rules:
- In a message which includes a NACK submessage, the GO submessage shall set

RTRANS = ATRANS, and RNITEL to the value that was in the GO submessage
which permitted that dataitem.
- A SACK message indicates that a selected codeword(s) of the dataitem is(are)

required to be repeated.
[NOTE that security can be improved by ensuring that the number of EFLAGs set to
'1' differs in successive SACK messages relevant to the same dataitem. Thus the value of
FRAGL in the requested fragment can be related unambiguously to the number of EFLAGs
set. This inequality can then be used as a further consistency test.]
- A PACK submessage informs the DSS that the dataitem has been successfully
received.
In the HADT mode a DRS shall pass on only the user information to any other link or
equipment.
- The GO submessage which accompanies a PACK submessage may be for any

TRANS relevant to the DRS.
[Note that transmission security may be improved if this GO submessage refers to

the same TRANS as that in the PACK submessage]
- A TSC may combine PACK and a Data Aloha type submessage into a single
message

17.2.4 Procedures involving expedited data
17.2.4.1 DSS procedures
If a DSS receives expedited data from a preceding link or decides of its own volition
to send expedited data it is preferred that it shall place that data at the head of any queue
of data awaiting transmission.
If a DSS receives expedited data instead of an acknowledgement to one of its

fragments it shall pass that data back to any preceding link or equipment and shall send no
more data until a further message is received indicating that transmission may be resumed.
A TSC may send expedited data at any time. A radio unit may send expedited data
upon receipt of a GO submessage or may send a DRQZ message in a random access
frame.
If the expedited data is a RESET message then the DSS shall discard all other data
queued for transmission and shall send no more data until the RESET message has been
acknowledged.
17.2.4.2 DRS procedures
If a DRS receives expedited data it shall acknowledge that data and also shall pass
that data on to any further link or equipment, preferably ahead of any other data.
A DRS may decide to originate expedited data for return to its corresponding DSS.
A TSC may send such expedited data at any time.
A radio unit may send expedited data in place of an acknowledgement providing

that the expedited data message is not longer than the replaced acknowledgement.
Alternatively it may indicate by the TNITEL value in the GO part of an acknowledgement
that it wishes to send data and send the expedited data when invited by a GO message.
Alternatively it may send a DRQZ message in a random access frame.
If the expedited data is a RESET message then the DRS shall discard any data not
yet passed on to a further link or equipment.
17.2.5 Closing a TRANS
17.2.5.1 TRANS closing procedures for a TSC
By sending a CLEAR message, a TSC may demand that all radio units close all
TRANS and leave the data channel.
A TSC may close a group or System Wide link TRANS by sending a DAHYX
message with IDENT = the group address or ALLI, the TRANS value to be closed, and
RESP = '0'.

If a TSC receives a DRQX message for an individual TRANS with correct address
then it shall send a DACKD(REASON='000') message as acknowledgement. If the address
is incorrect the TSC may use DAHY to query either or both the TRANS and address.
A TSC may close all TRANS for a particular radio unit by sending a DAHYX
message with PFIX and IDENT equal to the individual address of the radio unit, I/T set to
'0' and the value '0000000000' in the TRANS field.
A TSC may close a particular TRANS for a radio unit by sending a DAHYX
message with the TRANS value to be closed and I/T set to '1'.
A TSC may check whether a radio unit is still receiving a particular TRANS by
sending the DAHY message. The acknowledgement to this message is DRUGI.
If the TSC receives no relevant messages from a radio unit for at least TDX then it
shall assume that the TRANS is no longer active, and shall send a DAHYX message to
close the TRANS.
A TSC may reuse the TRANS value of a closed TRANS after a period which
accounts for the TRANS timer (TDX or TDN) of the radio unit(s) involved.
After closing a TRANS a TSC shall forward any data queued for transmission to any
associated links.
If a TSC receives a DRQX message for a group TRANS it shall ignore it.
17.2.5.2 TRANS closing procedures for a radio unit
If its relevant timer TDX or TDN expires, a radio unit shall assume that the TRANS is
closed.
By sending a DRQX message in an appropriate random access frame a radio unit

may request, e.g. as a result of user action, that an individual TRANS be closed.
In response to a GO submessage or a message headed by SITH a radio unit may,

by sending a DRQX message, request that an individual TRANS be closed.
If a radio unit receives a CLEAR message, or a DAHYX message with its individual
address and TRANS = '0000000000', it shall close all its TRANS and leave the channel. In
the case of the DAHYX message with RESP='1', it shall send a DACKD (REASON='000')
acknowledgement before it leaves the data channel.
If a radio unit receives a DAHYX message with its individual address and a relevant
TRANS value it shall note that the TRANS is closed. In the case of the DAHYX message
with RESP='1', it shall send a DACKD (REASON='000') acknowledgement.
If a radio unit receives a DAHYX message with a group or ALLI TRANS the radio
unit shall close the TRANS but not send an acknowledgement.
If a radio unit closes its last remaining TRANS then it shall leave the channel (after
sending any required acknowledgement).

17.2.6 Moving a radio unit in call to another data channel
17.2.6.1 Procedures for the TSC
A TSC may NOT move radio units by using a TRANS allocated to a group link
because of the risk of one or more of the radio units being engaged in a concurrent call.
17.2.6.1.1 Moving an individual radio unit
A TSC may move an individual radio unit in call to another data channel if that radio
unit has only one individual TRANS. The TSC may close all but one individual TRANS for
that unit to ensure this. If the TSC is a DSS it shall accomplish the move after fully receiving
an acknowledgement for a fragment and before it sends the next fragment.
If the TSC is a DRS it shall accomplish the move after acknowledging a (good
quality) fragment and before it sends a GO submessage for another fragment.
To accomplish an individual move a TSC shall send a GTT message with the
individual address of the radio unit and the new channel designation and TRANS value to
be used in the link and appropriate settings of RNITEL and TNITEL and values of O/R and
RATE fields equal to those used in the original GTT for that call.
The TSC may check that the channel movement has been successful by sending a
DAHY message with the new TRANS value on the new channel.
Data exchange with the radio unit shall resume at the point at which the channel
change occurred.
17.2.6.1.2 Moving ALL radio units from one data channel to another
A TSC may move ALL radio units from one data channel to another. The TSC shall
not attempt to do this unless all demanded or invited responses on the return channel have
had time to be completed.
To accomplish this move a TSC shall send a GTT message with IDENT = ALLI,
TRANS = '0000000000', O/R='0', and RATE as originally given.
17.2.6.2 Radio unit procedures
If a radio unit on a data channel receives a GTT message nominating another

channel and also containing any group address it shall ignore it.
17.2.6.2.1 An Individual move
If a radio unit having only one TRANS receives an individually addressed GTT
message with a new channel and a new TRANS value and all other parameters in the GTT
message matching those present in the original individual GTT message it shall move to
the new channel and replace the old TRANS value with the new one. The timers TDX,

TDA and TDD shall continue without being reset. Data exchange shall be expected to
resume at the point at which the channel change was made.
17.2.6.2.2 An ALLI move
If a radio unit receives a GTT message with the IDENT = ALLI and
TRANS = '0000000000', O/R=0 and RATE as originally given then it shall move to the
designated channel and maintain its TRANS number(s) and ALL other parameters and
states that existed immediately before the move message. Data exchange shall be
expected to resume at the point at which the channel change was made.

APPENDIX 1
SUGGESTED VALUES FOR PARAMETERS
Parameters such as radio unit time-outs and numbers of retries are represented by
symbols in this standard; for example, the maximum item duration is referred to as TT.
This Appendix contains suggested values for these parameters. However, note that a
radio unit must use the values required by the system on which it is currently operating.
A brief indication of the usage of each parameter is given, but readers should refer to
the procedures sections for the precise definitions of usage. The table below lists the
sections which refer to each parameter.
The maximum permissible tolerance for radio units implementing the times given is
10%.
Meaning Symbol Suggested Refs.

Value
Number of Disconnect messages sent ND1 2 9.2.3.5

by individually-called radio unit. 9.2.3.6
Number of Disconnect messages sent ND2 4 9.2.3.5

by calling radio unit. 9.2.3.6
Maximum number of random access NE 16 7.3.8

transmissions of RQE. 10.2.1
Maximum number of traffic channel NI 4 11.2.1

transmissions of RQS or RQX. 11.2.6
Number of Pressel On messages NPON 2 9.2.3.1
Number of Pressel Off messages NPOFF 3 9.2.3.1
Maximum number of random access NR 8 7.3.8

transmissions of RQS, RQD, RQX, 8.2.2.2
RQT, RQR, RQQ or RQC. 9.2.1.1
9.2.1.7
12.2.1
12.2.6
13.1.2.2
13.1.2.6
13.2.2.1
13.2.2.6
14.2.1
14.2.7
contd.
MPT1327 1997 Issue Page A1-1

Meaning Symbol Suggested Refs
Value
Maximum delay of TSC's response to NT 103 6.1.2.2

an unsolicited message from a radio 6.2.2.2.2
unit on a traffic channel. (The
response SYNT begins not later than
the start of bit NT, measured from the
end of the radio unit's message.)
Value of WAIT assumed at the start of NW 4 7.3.7

a session. (WAIT is a number of
slots.)
Time-out for called radio unit after TA 60 9.2.2.2

receiving AHY. seconds 9.2.2.4
13.1.2.1
Time barred from calling same ident TB 2 seconds 9.1.1.4

after receiving ACK(QUAL=0), ACKX, 9.2.1.4
ACKV or ACKB(QUAL=0), or any 11.1.4
ident after receiving ACKT(QUAL=0). 11.2.4
12.1.5
12.2.4
13.1.1.2
13.1.2.4
13.2.1.4
13.2.2.4
14.1.5
14.2.4
Time-out for requesting radio unit TC 60 7.3.8

attempting random access seconds 8.2.2.2
9.2.1.1
9.2.1.7
10.2.1
12.2.1
12.2.6
13.1.2.2
13.1.2.6
13.2.2.1
13.2.2.6
14.2.1
14.2.7
Time-out for requesting radio unit TI 2 seconds 9.1.2.2

waiting for further signalling for an 11.1.7
Include call. 11.2.5
contd.
Page A1-2 MPT1327 1997 Issue

Meaning Symbol Suggested Refs.
Value
Time-out for requesting radio unit TJ 20 7.3.8

waiting for further signalling for control seconds 8.2.1.3a
channel transaction with the TSC (viz. 8.2.2.4
registration, diversion request, or 9.1.1.7
status message or short data 9.2
message to the TSC). 12.1.7
12.2.5
13.1.1.4
13.1.2.5
14.1.9
14.2.6
Radio unit's inactivity time-out on a TN 7 seconds 9.2.3.6

traffic channel.
Maximum interval between periodic TP 5 seconds 9.2.2.6

messages (within speech items) at the
start of a session.
Time when radio unit returns to the TS 5 seconds 6.2.1.2

control channel acquisition procedures
if no system identity code is decoded.
Maximum item duration. TT 60 9.2.3.6

seconds
Time-out for calling radio unit waiting TW 60 7.3.8

for further signalling for a call or seconds 9.1.1.10
transaction that may require queueing 9.1.1.7
(for a traffic channel or for a called 9.2
party). 9.2.1.6
10.1.7
10.2.7
13.2.1.7
13.2.2.5
14.1.9
14.2.6

List of Timers and Counters used for standard Data (see Section 17)
The foregoing parameters are also used for Standard Data.
Timeouts
No. Meaning Symbol Range Held By
1. Time that a TSC may hold an TDF System dependent TSC

undelivered Tmessage before
destroying it.
2. Inactivity time before a TRANS TDX 1, 2, 4, 8, 16,32, 64 TSC & RU

is abandoned by an RU. minutes indefinite
3. Time that a radio unit waits waits TDG

to be allocated a TRANS after
obeying GTT(TRANS=0), before
returning to the control channel.
4. Time-out for requesting radio TDC 1 - 120 s RU

attempting random access on a
data channel.
5. Time-out for requesting radio TDW 1 - 120 s RU

unit waiting for further signalling
for a random access transaction
on a data channel.
6. Time-out for called radio unit TDA 1 - 120 s RU

after receiving AHYD on a data
channel.
7. Time-out for radio unit waiting TDE 1 - 120 s RU

for further data from TSC before
impatiently trying DRQT.
8. Time-out for radio unit waiting TDH 1 - 120 s RU

for acknowledgement from TSC
to data it sent before using
DRQT.
9. Time barred from calling same TDB 1 - 60 s RU

ident on a data channel after
receiving ACKV or ACKX in
response to an RQD request.
10. Lack of signal timer on a TDL 2 - 10 mins. RU

standard data channel (see
17.2.0.3).
11. Time that a radio unit waits for TDN 1 - 120 s

received group data (including
prearranged repeats). Started
when a group GTT is received.
contd.

Retry Parameters
No. Meaning Symbol Range Held By
1. Maximum number of (non- NDR 1 - 16 RU

emergency) random access
transmissions on the data
channel.
2. Maximum number of NDE 1 - 16 RU

emergency i.e. RQD(E=1)
random access transmissions
on the data channel.
3. Maximum number of times NDG 1 - 16 TSC &

that a group message will be RU
repeated by a TSC.

APPENDIX 2
THE ERROR CONTROL PROPERTIES OF THE CODEWORDS
The error control properties of the codewords are at least the following.
With "hard decision" decoding:
a. Detect all odd numbers of errors, any 5 random errors, and any error-burst up to
length 16, or
b. correct any 1 error and detect any 4 errors and any error-burst up to length 11, or
c. correct up to any 2 errors, and detect any 3 errors and any error-burst up to length 4,
or
d. correct any single error-burst up to length 5.
With "soft decision" decoding:
Correct any 5 dubious bits and any single burst of dubious bits up to length 16, according
to examination of the pattern of dubious bits.
Note. The higher the degree of error correction applied, the more likely is false decoding.
The application of signal quality measurement on a bit-by-bit basis may help to
guard against falsing if hard decision decoding is used, and is essential if soft
decision decoding is used.

APPENDIX 3
AN ALGORITHM FOR DETERMINING THE CODEWORD

COMPLETION SEQUENCE
OF A CONTROL CHANNEL SYSTEM CODEWORD
1. Create a codeword starting with a 16-bit preamble followed by the bit sequence
'1100010011010100' and the 15-bit system identity code, thus filling bits 1 to 47.
2. Assume bit 48 = '0'. Calculate the check bits (see section 3.2.3).
3. If the parity bit = '0', then the assumption in 2 was wrong. In this case, set bit 48 = '1'
and recalculate the check bits. (See also Note 1).
4. The wanted Codeword Completion Sequence is bits 48 to 63 inclusive with bit 63

inverted.
Note 1. A quick way to reverse the assumed bit and recalculate the check bits is to add
modulo-2 the generator polynomial '1110100000010101' to bits 47 to 63, and
then calculate the parity bit.
Note 2. The algorithm works because bits 1 to 63 are completely cyclic, except for the
inversion of bit 63, and there are an odd number of '1's in the generator
polynomial. The parity bit remains unaltered by any cycling process.

APPENDIX 4
AN ALGORITHM FOR GENERATING FIELDS A AND B OF THE

MARK CODEWORD
1. Bits 1, 22 to 30 and 49 to 64 of the MARK address codeword are fixed (see section
5.5.4.1). Bits 2 to 5 (CHAN4) and 7 to 21 (SYS) are system-dependent. Bit 6
(field A) and bits 31 to 48 (field B) are chosen to maximise the number of bit
transitions between bits 33 and 49 of the codeword.
2. In order to calculate an initial candidate MARK codeword, assume that bits 6, 31 and
32 of the MARK codeword will be '0'.
3. Obtain a 16-bit sequence to insert in bits 33 to 48 by a method similar to that in

Appendix 3, i.e.
a. Create an intermediate codeword starting with the sequence

'1100010011010101', followed by CHAN4, '0' (bit 6 of MARK), SYS,
'100011000' and '00' (bits 31 and 32 of MARK).
b. Assume bit 48 of the intermediate codeword = '0'. Calculate the check bits
(see section 3.2.3).
c. If the parity bit = '0', then the assumption in b. was wrong. In this case, set
bit 48 = '1' and recalculate the check bits. (See also Note 1 of Appendix 3).
d. The 16-bit sequence to insert in bits 33 to 48 of the candidate MARK

codeword is bits 48 to 63 of the intermediate codeword, with bit 63 inverted.
4. Derive seven other candidate MARK codewords having the alternative combinations
of bits 6, 31 and 32. This may be performed by adding modulo-2 the following
sequences to bits 33 to 48 of the initial candidate MARK codeword:
If bit 6 = '1' add '0100000000101110'

If bit 31 = '1' add '0111000001111110'
If bit 32 = '1' add '0011100000111111'
5. For each candidate MARK codeword, count the number of bit transitions occurring
between bits 33 and 49.
6. The required MARK codeword is a candidate which provides the greatest number of
counted transitions.

APPENDIX 5
BCD CODING
Where BCD coding is specified in this standard, the following representation shall be
used:
Binary Character
value represented
'0000' 0
'0001' 1
'0010' 2
'0011' 3
'0100' 4
'0101' 5
'0110' 6
'0111' 7
'1000' 8
'1001' 9
'1010' reserved
'1011' *
'1100' #
'1101' reserved
'1110' reserved
'1111' NULL
Note: These BCD groups shall be arranged in codewords so that the most significant bit of
the binary value is transmitted first (i.e. the leftmost bit in the above table shall be
transmitted first).

APPENDIX 6
Reserved for Timing of responses for Standard Data at a customised rate

APPENDIX 7
OTHER IDEAS CONSIDERED DURING THE DRAFTING OF SECTION

17 (STANDARD DATA)
1. As explained in section 17, the Standard Data protocol is an optional feature of
MPT 1327. In considering whether to implement it, firms might therefore like to be
aware of other ideas which arose in the drafting discussions but were not specifically
used in the protocol.
2. The ideas set out below are believed by their originators to be already in the public
domain or, with their agreement, are hereby offered to it. Before proceeding,
however, firms are advised to make appropriate enquiries through their Patent
Agents so as to ensure that any relevant IPR claims not compromised.
3. The ideas are:
a) An "ackvitation", ie a message sent by a TSC to a radio unit, the ackvitation

message being a combination of an acknowledgement to a user data
message sent by the radio unit and an invitation to the same unit to send
more data or repeat the data previously sent according to the requirements
of the acknowledgement, see STDWP CP 623. This latter part of the
message can include a parameter stating the maximum amount of data
which may be transmitted next. An essential point of an ackviatation is that
it needs only one address label because only one radio unit is being
addressed. An example of an ackvitation is the selective acknowledgement
message, "SACK".
The "DACK" acknowledgement messages included in the standard are not

ackvitations because they contain two addresses, one for the
acknowledgement submessage and one for the GO submessage. If both
addresses are the same then the function of the DACK message is
indistinguishable from that of an ackvitation.
b) Inclusion of repeated data and new data in a single message

STDWP CP 629. Each user data message is responded to in the manner
described in the text. Whereas in the text, if selective repeats are required
only the repeated data is then sent by DSS in a new message, in this idea
the repeated data occupies the front part of the new message and new data
then is appended to the repeated data. The DRS can distinguish the
repeated data from the new data by referring to the last acknowledgement it
sent which, of necessity, includes the number of codewords to be repeated.
The DRS has to keep a running record of the position or order of every
codeword it requires to be repeated until that codeword has been
successfully received.
c) Inclusion of the SYStem identity code in each message header as a means

of combatting radio over-reach. The idea was extended to include either the
SYS or radio unit address modulo-2 added into every user data codeword.
However, it was judged that the incidence of the problem is too low to
warrant inclusion of the idea.

d) Distinguishing Dataitems by length rather than by label.
STDWP CP 650
The idea here is not to use a separate label for each segment, but instead to
differentiate between them by their lengths. For example the length might
alternate between adjacent segments or might progressively increase or
decrease over the whole Tmessage. Thus each header only need include
the name of the Tmessage (or TRANS). The message length could be
indicated in any known manner, eg by a FRAGL field or a continuation bit in
each codeword. The only requirement is that adjacent messages have
different lengths unless the whole message is repeated. This serves to
distinguish new messages from repeated ones, which is the only absolute
necessity.
The method in the standard is to use a separate segment label but restrict
this to only one bit (ITENUM). However, the length differentiation method is
noted in 17.2.3.2.3 as a means of increasing security, although in this case
the length is controlled by the DRS varying the number of assigned EFLAGs
set.
e) To include both a message header and a message tail codeword.
A problem with reception is that if the header cannot be decoded then the
whole of the user data message is lost. If a tail codeword containing
substantially the same information as the header is added to the message
then a DRS could record any data codewords received without a decodeable
header in the hope that the tail codeword might then be decoded and hence
perhaps make the received data codewords usable.
A multipath fading simulation study indicated that there could be an increase

in air-time efficiency in very poor reception conditions but a decrease in
efficiency in most other conditions. The latter outweighed the advantage
given by the former.

A Signalling Standard: For Trunked Private Land Mobile Radio Systems

Uploaded by

Copyright:

Available Formats

A Signalling Standard: For Trunked Private Land Mobile Radio Systems

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Signalling Standard: For Trunked Private Land Mobile Radio Systems

Uploaded by

Copyright:

Available Formats

MPT 1327

TRUNKED PRIVATE LAND MOBILE

Amendments issued since publication 1988 edition

1 October 1990 Incorporated in the

Amendments issued since publication 1991 edition

Amendments issued since publication 1996 edition

MPT 1343 System interface specification for radio equipment to be used

MPT 1347 Radio interface specification for commercial trunked networks

Intellectual Property Rights

7. RANDOM ACCESS PROTOCOL

9. BASIC CALL PROCEDURES

10. EMERGENCY CALL PROCEDURES

11. INCLUDE CALL PROCEDURES

12. CALL DIVERSION PROCEDURES

13. STATUS MESSAGE PROCEDURES

14. SHORT DATA MESSAGE PROCEDURES

15. DATA INTERROGATION PROCEDURES

17. STANDARD DATA PROCEDURES

APPENDIX 1 Suggested values for parameters.

APPENDIX 2 The error control properties of the codewords.

APPENDIX 3. An algorithm for determining the codeword completion

APPENDIX 4. An algorithm for generating fields A and B of the MARK

APPENDIX 5. BCD coding.

APPENDIX 6. Reserved for Timing of responses for standard data at a

APPENDIX 7. Other ideas considered during the drafting of section 17

- the facilities that must be implemented

Section 1.3 provides an introduction to the operation of the protocol.

Subsequent sections of this document contain the protocol definition. In most of

MPT1327 1997 Issue Page 1-1

1.1.1 Types of call

a. Speech call. (See section 9.)

c. Emergency call. (See section 10.)

d. Include call. (See section 11.)

e. Status message. (See section 13.)

Thirty-two different status messages may be conveyed between units. The

f. Short Data Message. (See section 14.)

Page 1-2 MPT1327 1997 Issue

1.1.2 Making calls

- an individual radio unit or line-connected unit

A call request may be cancelled at any time.

1.1.3 Receiving calls

Incoming calls may be addressed to the unit individually or to a group to which it

MPT1327 1997 Issue Page 1-3

Page 1-4 MPT1327 1997 Issue

1.2.1 System dimensions

The numbering range of the protocol accommodates:

- 1,036,800 addresses per system

1.2.2 System control

Protection against interference is provided by labelling the signalling with a system

To cope with system malfunction, a customised fall-back mode of operation may be

1.2.3 Call handling

MPT1327 1997 Issue Page 1-5

As a precaution against fraudulent use of a system by an unauthorised radio unit, the

1.2.4 Multi-site systems

The protocol includes a registration facility to assist the implementation of multi-site

Page 1-6 MPT1327 1997 Issue

This section is intended only as a guide: it should not be regarded as a protocol

1.3.1 Control channel signalling structure

Signalling on the forward channel (base station transmit frequency) is nominally

\/ \/ \__/ \/ \/

\/ \/ \/ \/

\__________/ \/ \/

\/ \/ \__/ \/ \/

Active on a Channel: A radio unit is active on a channel when, on that

Note - a radio unit becomes active on an assigned traffic channel as

Call: A complete information exchange between two or more parties which