PAS 0001-13-6 V1.1.5 - 02mars2006
PAS 0001-13-6 V1.1.5 - 02mars2006
PAS 0001-13-6 V1.1.5 - 02mars2006
TETRAPOL Specifications;
TETRAPOL FORUM
TETRAPOL Secretariat
Postal address: BP 40 78392 Bois d'Arcy CEDEX - FRANCE
Tel.: +33 1 34 60 55 88 - Fax: +33 1 30 45 28 35
Copyright Notification: This is an unpublished work. The copyright vests in TETRAPOL Forum. All rights
reserved.©
The information contained herein is the property of TETRAPOL Forum and no part may be reproduced or used
except as authorised by contract or other written permission. The copyright and the foregoing restriction on
reproduction and use extend to all media in which the information may be embodied.
Tetrapol Forum reserves the right to bring modifications to this document.
Page 2
PAS 0001-13-6: Version 1.1.4
Contents
FOREWORD 4
1. SCOPE 5
2. NORMATIVE REFERENCES 5
3.1. Definitions 6
3.2. Abbreviations 6
5. PHYSICAL LEVEL 10
7.1. Presentation 11
7.1.1. Signalling stream 12
7.1.1.1. Overview 12
7.1.1.2. Description of the messages 12
7.1.1.2.1. STU_CONNECT 12
7.1.1.2.2. UTS_CONNECT_ACK 14
7.1.1.2.3. STU_ST_PRESENCE 15
7.1.1.2.4. UTS_ST_PRESENCE_ACK 15
7.1.1.2.5. STU_NETWORK_INFORMATION 16
7.1.1.2.6. UTS_ST_CONTROL 18
7.1.1.2.7. STU_SERVICE_MESSAGE 19
7.1.1.2.8. UTS_PERIODIC_ACCESS_SUBSCRIPTION 19
7.1.1.2.9. UTS_POLLING_SUBSCRIPTION 21
7.1.1.2.10. STU_PERIODIC_ACCESS_SUBSCRIPTION_ACK 23
7.1.1.2.11. STU_POLLING_SUBSCRIPTION_ACK 24
7.1.1.2.12. UTS_DEDICATED_ACCESS_SUBSCRIPTION 25
7.1.1.2.13. UTS_UDT_APPLICATION_STATUS 29
7.1.1.2.14. STU_ST_DATA_U_WINDOW_CHANGE 29
7.1.1.2.15. UTS_ST_DATA_U_WINDOW_CHANGE_ACK 30
7.1.2. Data message exchange stream 30
7.1.2.1. Overview 30
©1998-TETRAPOL Forum 07/11/98
This document is the property of TETRAPOL Forum and may not be copied or circulated without permission.
Page 3
PAS 0001-13-6: Version 1.1.4
HISTORY 59
Foreword
This document is the Publicly Available Specification (PAS) of the TETRAPOL land mobile radio system,
which shall provide digital narrow band voice, messaging, and data services. Its main objective is to
provide specifications dedicated to the more demanding PMR segment: the public safety. These
specifications are also applicable to most PMR networks.
Part 7 Codec
Part 16 Security
1. Scope
The purpose of this part is to describe the protocols which are used at the ST-UDT R2 reference
connection point when a "type 2" UDT is connected: the "UDT-ST open interface".
2. Normative references
This PAS incorporates by dated and undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications
apply to this PAS only when incorporated in it by amendment or revision. For undated references the
latest edition of the publication referred to applies.
[10] Microsoft Development Network Library (July 96): "Win NT DDK Network
Drivers".
3.1. Definitions
3.2. Abbreviations
At reference point R2, the TETRAPOL system provides several levels of interfaces in relation with UDT
architectures:
- the second type of UDT is built in a Windows architecture including a NDIS low layer driver,
various NDIS protocol drivers and Windows applications.
This type of UDT architecture is described in PAS 0001-13-2 [4] which describes the SDP protocol and in
PAS 0001-13-3 [5] which describes the STUTEL Profile for the UDT.
Application
R2bis: UDT-ST
applicative interface
DLL Winsock
API
Win3
Standard
Control
TCP-UDP/IP
Supervision
Driver
Driver
UDT-ST
standard interface
NDIS Interface
UDT-ST
DTAP System
MIB Terminal
MPAP
R2: UDT-ST
Part of the TETRAPOL open interface
This scheme shows three levels for the external data interface in the UDT:
- UDT-ST open interface: the interface on the link between UDT and ST. This interface enables to
connect to the ST a dedicated UDT (for example an on-board computer);
- UDT-ST standard interface: the interface on the NDIS layer. This interface is compliant with the
NDIS 4.0 standard;
- UDT-ST applicative interface: For TCP-UDP/IP protocol, the most usual interface is a Socket
type Interface, supplied by a Winsock DLL. For the proprietary Control and Supervision protocol,
the applicative interface is a set of primitives, grouped in a Win32 DLL.
The UDT-ST Driver is implemented as a Miniport NIC driver (in respect with Microsoft terminology). The
NIC is defined as the physical link between UDT and ST, the ST and the access to the radio link. The
NIC is in fact, a "wireless" adapter.
- physical level;
- link level: MPAP protocol;
- application level: DTAP protocol.
A terminal is able to work both with a "type 1" UDT and with a "type 2" UDT. It identifies at the physical
connection the type of connected UDT and adjusts itself to the supported protocols.
As described in [5], the physical connection is made on the initiative of the ST, which periodically sends
a polling signal on the asynchronous link (T_N1 = 4s period), until the UDT acknowledges this signal.
Note: when the ST is switched on, T_N1 is reduced to 120ms for the five first attempts of physical
connections (to speed up the connection between the ST and UDT when they are approximately
simultaneously switched on).
The ST's polling signal is formed of two ENQ characters (ASCII code = 0x05).
The UDT's presence signal is formed of a succession of ACK characters (ASCII code = 0x06) when a
"type 1" UDT is connected (STUTEL connection), of a succession of BEL characters (ASCII code =
0x07) when a "type 2" UDT is connected (MPAP connection).
The UDT shall guarantee it sends its presence signal in less than 80ms (after this delay, the ST idles and
consequently ignores the signals from the UDT; it will transmit the polling signal 4s later).
On receipt of the UDT’s presence signal, the ST sends a single XOFF character (ASCII code = 0x13) to
stop the UDT's presence signal emission.
Each side then reinitializes the link according to the mode of the upper protocol.
In the case of the Stutel protocol, the terminal starts an "association" transaction, then establishes an
"access regime" in which it plays the master role.
In the case of the MPAP protocol, each side opens a link level service in normal mode. Yet, the link level
connection will be completed only after the first request to transmit data (whatever the side).
ST UDT
5. Physical level
The physical level is enabled by a serial line in asynchronous mode according to V28 / V24 ITU
specification. The only signals handled are "send data" (SD) and "receive data" (RD).
The dedicated access service is not available for this version (all items concerning this service are
greyed)
7.1. Presentation
The application level uses the link level MPAP services to exchange applicative information between
UDT and ST.
- the application identifier, on one byte: 0x01 for the "DTAP" application;
- the DTAP header with, in this version, four fields:
EXT: this field is used to indicate if the header goes on the next byte; so this field is set to 1 for all
the bytes of the header except for the last one;
SEG: this field is used to indicate an applicative segmentation of a message; this field is set to 1
for all segments except for the last one where the field is set to 0;
RESERVED: this field is reserved for a future usage and is set to 0;
STATUS BIT FIELD: this field gives the status vector of the sending side: this field is not used in
this interface version and is set to 0; it will be used in a future version to transmit the main states
of the terminal;
- the message type on 2 bytes (least significant, most significant, therefore Intel format). The
message type is only present in the first segment of a segmented message;
- information elements depending on the message type.
APPLI_ID 1
EXT SEG RESERVED 2
EXT STATUS BIT FIELD 3
(MESSAGE TYPE) 4
5
6
INFORMATION ELEMENTS
n
Figure 3: format of an applicative message
In this interface version, the DTAP header includes two bytes (byte 2 and 3): EXT = 1 for the byte 2 and
EXT = 0 for the byte 3. However, the status vector is optional for the messages UDT towards ST. In this
case, the byte 3 is absent and EXT = 0 for the byte 2.
The maximum length n of a message is conveyed in the connection opening phase by the ST.
The message exchanged in the different streams are defined in the following chapters. The messages
are named in the following way to indicate the direction in which they are sent:
A message may be bigger than expected: in this case, all unknown fields in a message are ignored upon
receiving.
All the messages including several bytes are coded with the least significant bytes first (therefore Intel
format).
7.1.1.1. Overview
This stream is used to establish the DTAP connection, to manage its supervision and the transmission of
different signalling and control information between the ST and the UDT.
In case of detection of a problem on the DTAP connection, the detecting side closes its link level service
(MPAP service). When the MPAP protocol is only used by the DTAP application, this closing involves
the return to the physical connection described in 4.3. When the MPAP protocol is used by several
applications, the return to the physical connection only happens when all the opened services by the
different applications are closed.
7.1.1.2.1. STU_CONNECT
Parameters:
- RFSI address
- ST's country
- ST's network
- N_stum_max: maximum number of uplink messages which may be simultaneously managed by the ST
(see also 7.1.1.2.11, 7.1.2.2.1 and 7.1.2.2.2). This number does not apply to the “polling” service
described in 7.1.2.2.4 and 7.1.2.2.5 nor to the periodic service and nor to the “dedicated access” service
described in 7.1.2.2.6 and 7.1.2.2.7.
- N_stum: number of uplink messages currently managed by the ST. Therefore, the UDT is allowed after
this applicative connection to send (N_stum_max - N_stum) uplink messages without having received
any radio acknowledgements. This number does not apply to the “polling” service described in 7.1.2.2.4
and 7.1.2.2.5 nor to the periodic service and nor to the “dedicated access” service described in 7.1.2.2.6
and 7.1.2.2.7.
Notes:
- the notion of DTAP interface version was created to solve interface compatibility problems. It is
increased each time the interface is modified; the value corresponding to this document is given in
chapter 7.1.4. With the knowledge of the ST supported interface version, the UDT can use with an
optimal way the ST messages and not undertake services which would be unknown by the ST. The ST
and UDT versions nevertheless may be sometimes incompatible (for instance, if the ST's version is
lower than the lowest version supported by the UDT): if it happens, the UDT closes its link level service.
- if the ST's country and/or network are different from those owned by the UDT, the UDT closes its link
level service.
- after the transmission of this message, the ST is waiting (duration T1) for the acknowledgement
message UTS_CONNECT_ACK from the UDT. If the ST does not receive this message within T1, the
ST closes its link level service.
Encoding:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
VERSION 1
RFSI 4
ADDRESS
5
COUNTRY CODE 7
NETWORK CODE 8
10
MAXIMUM MESSAGE LENGTH
11
The field K means: kind of information element: (M) Mandatory, (C) Conditional
7.1.1.2.2. UTS_CONNECT_ACK
Short description: acknowledgement for a DTAP connection request from the ST.
Parameters:
- UDT's country
- UDT's network
Notes:
- after the receipt of this message, the ST is authorised to send the messages described below.
- with the knowledge of the UDT supported interface version, the ST can use with an optimal way the
UDT messages and not undertake services which would be unknown by the UDT. The ST and UDT
versions nevertheless may be sometimes incompatible (for instance, if the UDT's version is lower than
the lowest version supported by the ST): if it happens, the ST closes its link level service.
- if the UDT's country and/or network are different from those owned by the ST, the ST closes its link
level service.
- when no SDP application is opened on the UDT, the ST denies all SDP messages from the air
interface, which allows the SDP "secured delivery service".
Encoding:
VERSION 1
COUNTRY CODE 2
NETWORK CODE 3
7.1.1.2.3. STU_ST_PRESENCE
Parameters:
- none
Notes:
- after the transmission of this message, the ST is waiting (duration T5) for the acknowledgement
message UTS_ST_PRESENCE_ACK from the UDT. If the ST does not receive this message within T5,
the ST considers the UDT absent and closes its link level service. Note: the ST can also detect the
absence of the UDT because of the link level deconnection (indication of closing for the link level
service).
- the UDT is waiting for this message and detects the absence of the ST either because of its own timer
expiry, either because of the link level deconnection (indication of closing for the link level service).
- the ST sends this polling message when its timer T_Presence expires (its duration is sent to the UDT in
the message STU_CONNECT -polling timer duration-). The UDT expects such a polling message within
a duration of 2*T_Presence. if its timer expires, the UDT closes its link level service.
- any other DTAP message sent by the ST is also considered as a polling message and involves the
reset of the two timers.
Encoding:
7.1.1.2.4. UTS_ST_PRESENCE_ACK
Parameters:
©1998-TETRAPOL Forum 07/11/98
This document is the property of TETRAPOL Forum and may not be copied or circulated without permission.
Page 16
PAS 0001-13-6: Version 1.1.4
- none
Notes:
Encoding:
7.1.1.2.5. STU_NETWORK_INFORMATION
Short description: "network" information indication: location of the ST in the network (registration cell
-switch and base station-, registration base network), system operating mode, R field of the registration
base network, registration state of the ST.
Parameters:
- system operating mode: normal mode, BN disconnected mode (fall back mode 1), MSW disconnected
mode (fall back mode 2), RSW disconnected mode (fall back mode 3.1), BSC disconnected mode (fall
back mode 3.2) or unknown mode (the terminal is not registered)
- R field of the registration base network; this parameter is set to "unknown" when the terminal is not
registered.
- cell registration parameters of the terminal: switch, base station and base network; when the terminal is
not registered, these parameters may be absent or may be set to "unknown"
- registration state of the terminal : not registered terminal, registered terminal, differed registration ; this
field is allowed to be sent only if the ST's DTAP interface version is equal or higher than 4.
Notes:
- every parameter of this message is sent in TLV format (type, length, value). All the parameters are not
always present.
- each change in one parameter initiates a new emission of the message including, at least, the modified
parameter.
Encoding:
CONDITIONAL 3
MESSAGES
...
END_NETWORK_INFO
LENGTH = 2
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
TYPE +1
LENGTH +2
+3
BASE_NETWORK_R_FIELD
+4
LENGTH = 1
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
TYPE +1
LENGTH +2
SYSTEM_MODE +3
Values:
LENGTH = 3
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
TYPE +1
LENGTH +2
SW +3
+4
BS
+5
BN
0xFF = Unknown SW
0xFF = Unknown BS
0xFF = Unknown BN
LENGTH = 1
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
TYPE +1
LENGTH +2
REGISTRATION_STATE +3
7.1.1.2.6. UTS_ST_CONTROL
Parameters:
Encoding:
ACTION 1
7.1.1.2.7. STU_SERVICE_MESSAGE
Parameters:
- service message
Notes:
- the service message function is not present on all projects. According to the project, the switch
prevents or not from sending service messages to the terminals. No control is done by the terminal.
Encoding:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
LENGTH 1
SERVICE
MESSAGE
x+1
7.1.1.2.8. UTS_PERIODIC_ACCESS_SUBSCRIPTION
Short description: request to ask for a subscription to the "periodic access" service or to cancel it
Parameters:
- Data length: this length defines the number of byte (only applicative byte) which is allocated to the
terminal. In this version, maximum length is 9 bytes.
- Access profile on air interface: this profile determines the period, which is used to send messages on
Air interface.
- Access class: this class is used to define the right to have a withdrawn service and to manage the
DDCH congestion
Notes:
- The “ access class ” defines the mode of the “periodic access” service; the service can take values
between 0 and 7:
1: meaning that all the radio characteristics of the “periodic access” are given in the message with the
class 1.
2: meaning that all the radio characteristics of the “periodic access” are given in the message with the
class 2.
3: meaning that all the radio characteristics of the “periodic access” are given in the message with the
class 3.
The other values are not used in this version (ST control).
- After the transmission of this message, the UDT is waiting (duration T2) for the acknowledgement
message STU_PERIODIC_ACCESS_SUBSCRIPTION_ACK from the ST. If the UDT does not receive
this message within T2, it locally considers that its request has failed.
- The application can request a subscription to the "periodic access" service or cancel it;
- The application can ask a modification of the parameter subscription after a subscription
request
- in case of ST-UDT link failure (receipt of an indication of closing for the link level service) while the
UDT is waiting for a subscription or a cancellation acknowledgement, the UDT has to consider locally
that its request has failed: the ST will not send the acknowledgement message
STU_PERIODIC_ACCESS_ SUBSCRIPTION_ACK.
- in case of ST-UDT link failure, the periodic subscription is erased from the ST, that implies that the
subscription has to be done at each DTAP connection opening.
- For a given UDP source port (MSB), the UDT is not allowed to modify its subscription to the "periodic
access" service or to cancel it while its previous request is not acknowledged (unless T2 expires).
- in this version, the ST does not accept a second subscription to the "periodic access" service (for
another UDP source port than the first one) but the interface has to authorise another subscription
- The UDT is allowed to send this request only if the ST's DTAP interface version is equal or higher than
5.
Encoding:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
ACCESS PROFILE 3
DATA_LENGTH PERIOD 4
7.1.1.2.9. UTS_POLLING_SUBSCRIPTION
Short description: request to take out a subscription to the “polling” service or to cancel it
Parameters:
Notes:
- the “polling” service profile defines both the polling frequency and the polling message format on the air
interface; the profile can take values between 0 and 7, 0 meaning "polling service stop". The number of
the authorised profiles varies according to the project and therefore some values between 1 and 7 may
not be allowed (ST control).
- after the transmission of this message, the UDT is waiting (duration T2) for the acknowledgement
message STU_POLLING_SUBSCRIPTION_ACK from the ST. If the UDT does not receive this message
within T2, it locally considers that its request has failed.
- the application can take out a subscription to the “polling” service or can cancel it; it can dynamically
modify its “polling” service profile as well: in this case, it does not need to cancel at first the subscription.
- in case of ST-UDT link failure (receipt of an indication of closing for the link level service) while the
UDT is waiting for a subscription or a cancellation acknowledgement, the UDT has to consider locally
that its request has failed: the ST will not send the acknowledgement message STU_POLLING_
SUBSCRIPTION_ACK.
- the UDT is not allowed to take out a subscription to the “polling” service or to cancel it while its previous
request is not acknowledged (unless T2 expires).
- the UDT is allowed to send this request only if the ST's DTAP interface version is equal or higher than
2.
Encoding:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
PROFILE 2
7.1.1.2.10. STU_PERIODIC_ACCESS_SUBSCRIPTION_ACK
Short description: acknowledgement for a subscription to the "periodic access" service or cancellation
request from the UDT
Parameters:
Encoding:
Result ok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
UDP SOURCE PORT MSB
1
+1
RESULT 2
+1
Result nok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
RESULT 2
FAILURE FAMILY 3
FAILURE CAUSE 5
7.1.1.2.11. STU_POLLING_SUBSCRIPTION_ACK
Short description: acknowledgement for a subscription to the “polling” service or cancellation request
from the UDT
Parameters:
Encoding:
result ok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
RESULT 1
result nok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
RESULT +1
FAILURE FAMILY +2
FAILURE CAUSE +4
7.1.1.2.12. UTS_DEDICATED_ACCESS_SUBSCRIPTION
Short description: request to take out a subscription to the "dedicated access" service or to cancel it
Parameters:
- cell parameters : switch, base station and base network for the dedicated access
- channel number : radio channel number (corresponding to a pair of radio frequencies) for the
dedicated access
- first super frame : first super frame number in the hyper frame for the dedicated access
- first radio slot : first radio slot number in the first super frame for the dedicated access
- access size : this size defines the number of slots (synchronization slot included) which are
allocated to the terminal. In this version, the only allowed size is three slots (one synchronization
slot and two data slots)
- access period on air interface : the unit is 20 ms. In this version, all the allowed periods are
multiple of 60 ms in accordance with the access size. The minimal period is 2 seconds. Moreover
some values between 2 and 10 seconds are forbidden to guarantee the ST mobility function
efficiency. The maximal period varies according to the project (is linked to the air interface hyper
frame size which is a project parameter).
Notes:
- the “dedicated access” service profile defines the mode of the “dedicated access” service; the profile
can take values between 0 and 7, 0 meaning "dedicated access service stop" and 1 meaning that all the
radio characteristics of the “dedicated access” are given in the message. The other values are not used
in this version (ST control).
- after the transmission of this message, the UDT is waiting (duration T2) for the acknowledgement
message STU_DEDICATED_ACCESS_SUBSCRIPTION_ACK from the ST. If the UDT does not receive
this message within T2, it locally considers that its request has failed.
- the application can take out a subscription to the "dedicated access" service or can cancel it; it can
dynamically modify its characteristics as well (on the same port and same profile): in this case, it does
not need to cancel at first the subscription.
- the application can take out a subscription regardless of the ST state registration and location but a
data transmission request (UTS_DEDICATED_ACCESS_DATA_U message) will nevertheless be
accepted only when the ST becomes registered under the indicated cell.
- in case of ST-UDT link failure (receipt of an indication of closing for the link level service) while the
UDT is waiting for a subscription or a cancellation acknowledgement, the UDT has to consider locally
that its request has failed: the ST will not send the acknowledgement message
STU_DEDICATED_ACCESS_ SUBSCRIPTION_ACK.
- in case of ST-UDT link failure, the subscription is erased from the ST, that implies that the subscription
has to be done at each DTAP connection opening.
- for a given UDP source port (MSB), the UDT is not allowed to modify its subscription to the "dedicated
access" service or to cancel it while its previous request is not acknowledged (unless T2 expires).
- in this version, the ST does not accept a second subscription to the "dedicated access" service (for
another UDP source port than the first one)
- the UDT is allowed to send this request only if the ST's DTAP interface version is equal or higher than
4.
Encoding:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
PROFILE 2
SW 3
BS 4
BN 5
CHANNEL NUMBER 6
FIRST SUPERFRAME
SW 7
ACCESS SIZE 9
10
ACCESS PERIOD
11
BS C 1 byte
BN C 1 byte
7.1.1.2.12.1. STU_DEDICATED_ACCESS_SUBSCRIPTION_ACK
Short description: acknowledgement for a subscription to the "dedicated access" service or cancellation
request from the UDT
Parameters:
Encoding:
result ok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
UDP SOURCE PORT MSB
1
+1
RESULT 2
+1
result nok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
RESULT 2
FAILURE FAMILY 3
FAILURE CAUSE 5
7.1.1.2.13. UTS_UDT_APPLICATION_STATUS
Parameters:
Notes:
- when no SDP application is opened on the UDT, the ST denies all SDP messages from the air
interface, which allows the SDP "secured delivery service".
Encoding:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
SDP_APPLICATION_STATUS 1
7.1.1.2.14. STU_ST_DATA_U_WINDOW_CHANGE
Short description: modification of the maximum number of uplink messages which may be
simultaneously managed by the ST.
Parameters:
- N_stum_max: maximum number of uplink messages which may be simultaneously managed by the ST
(see also 7.1.1.2.1, 7.1.2.2.1 and 7.1.2.2.2). This number does not apply to the “polling” service
described in 7.1.2.2.4 and 7.1.2.2.5, nor to the periodic service and nor to the “dedicated access” service
described in 7.1.2.2.6 and 7.1.2.2.7.
Notes:
- the ST is allowed to send this request only if the UDT's DTAP interface version is equal or higher than
3.
Encoding:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
7.1.1.2.15. UTS_ST_DATA_U_WINDOW_CHANGE_ACK
Short description: acknowledgement for the modification of the maximum number of uplink messages
which may be simultaneously managed by the ST.
Parameters:
- none
Notes:
Encoding:
7.1.2.1. Overview
This stream allows to exchange the necessary information for a data message uplink transmission (UDT
towards ST) or for a data message downlink transmission (ST towards UDT).
The data messages are referenced by an internal identifier of two bytes. Each end has its own internal
identifier managed in its sending direction. This identifier is increased by 1 whenever a new message is
transmitted.
There are three different streams for the uplink data messages:
- data transmission with the “polling” service: this stream, generally used to transmit short and
periodic (or quasi-periodic) messages, allows to transmit data on the air interface with the “polling” radio
service (data transmission after network polling).
- data transmission with the “dedicated access” service : this stream, generally used to transmit
short and periodic (or quasi-periodic) messages, allows to transmit data on the air interface with the
“dedicated access” radio service (data transmission on dedicated slots located on a dedicated radio
frequency).
- data transmission with the “periodic service” : this stream, generally used to transmit short and
periodic (or quasi-periodic) messages, allows to transmit data on the air interface with the “dedicated
access” radio service (data transmission on dedicated slots located on a dedicated radio frequency).
These streams are completely independent (acknowledgement messages, management rules ...).
7.1.2.2.1. UTS_DATA_U
Parameters:
- internal identifier
- length of data
Notes:
- The length of data is limited to 1472 bytes plus the length of header : 1486 bytes.
- The ST analyses several fields of the headers 1 and 2: to get the transmission mode of the message on
the air interface (connected mode or datagram mode, ...), the transmission priority on the air interface.
- After the transmission of this message, the UDT is waiting (duration T3) for the radio acknowledgement
(message STU_RADIO_TRANSMISSION_ACK) from the ST. This radio acknowledgement may be
positive or negative. If the UDT does not receive this message within T3, it has to consider that the data
transmission on the air interface has failed (same behaviour as on a negative radio acknowledgement).
In case of ST-UDT link failure (receipt of an indication of closing for the link level service) while the UDT
is waiting for the radio acknowledgement, the UDT has to consider in the same way that the data
transmission on the air interface has failed (same behaviour as on a negative radio acknowledgement).
- After the transmission of this message, the number of uplink messages currently managed by the ST
(N_stum) is increased by 1. The UDT is then allowed to send (N_stum_max - N_stum) other uplink data
transfer request before receiving any radio acknowledgement (message STU_RADIO_TRANSMISSION
_ACK) for a previous request, unless the ST-UDT link fails (receipt of an indication of closing for the link
level service) or T3 expires.
- In case of mistake on a field of the headers 1 or 2 or on the length of data (greater than 1486 bytes),
the ST sends a negative acknowledgement for the request.
Encoding:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
1
IDENTIFIER
2
3
DATA LENGTH
4
...
DATA
x+4
7.1.2.2.2. STU_RADIO_TRANSMISSION_ACK
Short description: positive or negative radio acknowledgement for an uplink data transfer request from
the UDT
Parameters:
- internal identifier
Notes:
- the radio acknowledgement is a radio transmission acknowledgement: it means, when it is positive, that
the base station has received the data. It is not a radio emission acknowledgement like the
messages STU_POLLING_EMISSION_ACK or STU_PERIODIC_ACCESS_EMISSION_ACK or
STU_DEDICATED_ACCESS_EMISSION_ACK which mean, when they are positive, that the
terminal has sent the data.
- the UDT uses the fields "failure family", "failure type of cause" and "failure cause" to report through the
Control and Supervision Driver (see chapter 4.2 and [7]) the transmission failures of the uplink data
messages.
- After the transmission of this message, the number of uplink messages currently managed by the ST
(N_stum) is decreased by 1. The UDT is then allowed to send (N_stum_max - N_stum) other uplink data
transfer request.
- If the ST receives a new uplink data transfer request while it already currently manages (N_stum =
N_stum_max) uplink messages, it sends a negative radio acknowledgement for this new message.
- in case of ST-UDT link failure (receipt of an indication of closing for the link level service) while the
UDT is waiting for the radio acknowledgement, the UDT has to consider that the data transmission on the
air interface has failed (see note on the message UTS_DATA_U). On the terminal side, the link failure
does not affect the radio transmission of the data over the air interface. The radio transmission
acknowledgement is either forgotten if the ST-UDT link is still cut when the terminal wants to send it,
either sent if the ST and UDT are linked again.
- because of the previously mentioned reason, the UDT may receive a radio acknowledgement message
with a wrong internal identifier: if it happens, the UDT ignores the message.
Encoding:
result ok:
1
IDENTIFIER
2
RESULT 3
result nok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
1
IDENTIFIER
2
RESULT 3
FAILURE FAMILY 4
5
FAILURE TYPE OF CAUSE
FAILURE CAUSE 6
7.1.2.2.3. STU_DATA_D
Parameters:
- internal identifier
- data length
Notes:
- the data length is limited to 1472 bytes plus length of header: 1486 bytes.
- the internal identifier allows the UDT to handle cleverly a second transmission of a downlink message
after a ST-UDT link failure: if the message has already been received, it is not taken again into account.
- on receipt of the link level acknowledgement (the last one if the message is segmented), the ST erases
the data in its saved memory M2 and is able to accept again a downlink data transfer on the air interface.
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
1
IDENTIFIER
2
3
DATA LENGTH
4
...
DATA
x+4
7.1.2.2.4. UTS_POLLING_DATA_U
Short description: request for an uplink data transfer with the “polling” service
Parameters:
- internal identifier
- data length
Notes:
- the data length is limited to 255 bytes however it has to be consistent with the “polling” service profile.
- the ST analyses several fields of the headers 1 and 2: to get the transmission mode of the message on
the air interface (datagram mode -compulsory for the “polling” service-, ...), the transmission priority on
the air interface ...
- after the transmission of this message, the UDT is waiting (duration T4) for the acknowledgement
(message STU_POLLING_EMISSION_ACK) from the ST. This radio emission acknowledgement may
be positive or negative. If the UDT does not receive this message within T4, it has to consider that the
data emission on the air interface has failed (same behaviour as on a negative radio emission
acknowledgement). In case of ST-UDT link failure (receipt of an indication of closing for the link level
service) while the UDT is waiting for the radio emission acknowledgement, the UDT has to consider in
the same way that the data emission on the air interface has failed (same behaviour as on a negative
radio emission acknowledgement).
©1998-TETRAPOL Forum 07/11/98
This document is the property of TETRAPOL Forum and may not be copied or circulated without permission.
Page 35
PAS 0001-13-6: Version 1.1.4
- the UDT is allowed to send another uplink data transfer request to the ST before receiving the radio
emission acknowledgement (message STU_POLLING_EMISSION_ACK) for its previous request.
Nevertheless, as the ST owns only one emission buffer, this new message replaces the previous one.
- in case of mistake on a field of the headers 1 or 2 or on the length of the transmitted data, the ST sends
a negative radio emission acknowledgement to the request.
- the UDT is allowed to send this request only if the ST's DTAP interface version is equal or higher than
2.
Encoding:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
PROFILE 1
2
IDENTIFIER
3
DATA LENGTH 4
DATA
5+x
7.1.2.2.5. STU_POLLING_EMISSION_ACK
Short description: positive or negative radio emission acknowledgement for an uplink data transfer
request with the “polling” service from the UDT
Parameters:
- internal identifier
Notes:
- this acknowledgement is a radio emission acknowledgement: it means, when it is positive, that the
terminal has sent the data on the air interface. It is not a radio transmission acknowledgement like the
message STU_RADIO_TRANSMISSION_ACK which means, when it is positive, that the base station
has received the data.
- the UDT uses the fields "failure family", "failure type of cause" and "failure cause" to report through the
Control and Supervision Driver (see chapter 4.2 and [7]) the transmission failures of the uplink data
messages with the “polling” service.
- in case of ST-UDT link failure (receipt of an indication of closing for the link level service) while the
UDT is waiting for the acknowledgement, the UDT has to consider that the data emission on the air
interface has failed (see note on the message UTS_POLLING_DATA_U). If the ST receives a new uplink
data transfer request with the “polling” service while an uplink data transfer with the “polling” service is
not yet completed, it sends a negative acknowledgement for the old message.
Encoding:
result ok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
1
IDENTIFIER
2
RESULT 3
result nok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
1
IDENTIFIER
2
RESULT 3
FAILURE FAMILY 4
5
FAILURE TYPE OF CAUSE
FAILURE CAUSE 6
7.1.2.2.6. UTS_DEDICATED_ACCESS_DATA_U
Short description: request for an uplink data transfer with the “dedicated access” service
Parameters:
- internal identifier
- data length
Notes:
- the data length is limited to 255 bytes however it has to be consistent with the parameter “access size”
specified at the subscription of service.
- the ST analyses several fields of the headers 1 and 2: to get the transmission mode of the message on
the air interface (datagram mode -compulsory for the “dedicated access” service-, ...), the MSB byte of
UDP source port, the transmission priority on the air interface...
- after the transmission of this message, the UDT is waiting (duration T4) for the acknowledgement
(message STU_DEDICATED_ACCESS_EMISSION_ACK) from the ST. This radio emission
acknowledgement may be positive or negative. If the UDT does not receive this message within T4, it
has to consider that the data emission on the air interface has failed (same behaviour as on a negative
radio emission acknowledgement). In case of ST-UDT link failure (receipt of an indication of closing for
the link level service) while the UDT is waiting for the radio emission acknowledgement, the UDT has to
consider in the same way that the data emission on the air interface has failed (same behaviour as on a
negative radio emission acknowledgement).
- the UDT is allowed to send another uplink data transfer (on dedicated access) request to the ST before
receiving the radio emission acknowledgement (message STU_DEDICATED_ACCESS_
EMISSION_ACK) for its previous request. Nevertheless, as the ST owns only one emission buffer, this
new message replaces the previous one.
- in case of mistake on a field of the headers 1 or 2 or on the length of the transmitted data, the ST sends
a negative radio emission acknowledgement to the request.
- in case of inconsistency between the ST cell registration capabilities and the parameters defined for the
dedicated service (if the ST registration cell parameters are different from the cell parameters defined for
the dedicated access radio service or if the channel number defined for the dedicated access radio
service doesn’t exist under the cell or if the data size is not compatible with the requested access size),
the ST sends a negative radio emission acknowledgement to the request.
- the UDT is allowed to send this request only if the ST's DTAP interface version is equal or higher than
4.
Encoding:
2
IDENTIFIER
3
DATA LENGTH 4
DATA
5+x
7.1.2.2.7. STU_DEDICATED_ACCESS_EMISSION_ACK
Short description: positive or negative radio emission acknowledgement for an uplink data transfer
request with the “dedicated access” service from the UDT
Parameters:
- internal identifier
Notes:
- this acknowledgement is a radio emission acknowledgement: it means, when it is positive, that the
terminal has sent the data on the air interface. It is not a radio transmission acknowledgement like the
message STU_RADIO_TRANSMISSION_ACK which means, when it is positive, that the base station
has received the data.
- the UDT uses the fields "failure family", "failure type of cause" and "failure cause" to report through the
Control and Supervision Driver (see chapter 4.2 and [7]) the transmission failures of the uplink data
messages with the “dedicated access” service.
- in case of ST-UDT link failure (receipt of an indication of closing for the link level service) while the
UDT is waiting for the acknowledgement, the UDT has to consider that the data emission on the air
interface has failed (see note on the message UTS_DEDICATED_ACCESS_DATA_U). If the ST
receives a new uplink data transfer request with sending on dedicated access service while an uplink
data transfer with sending on dedicated access service is not yet completed, it sends a negative
acknowledgement for the old message.
Encoding:
result ok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
1
IDENTIFIER
2
RESULT 3
result nok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
1
IDENTIFIER
2
RESULT 3
FAILURE FAMILY 4
5
FAILURE TYPE OF CAUSE
FAILURE CAUSE 6
7.1.2.2.8. UTS_PERIODIC_ACCESS_DATA_U
Short description: request for an uplink data transfer with the “periodic access” service
Parameters:
- Internal identifier
- Data length
Notes:
- The data length is limited to 255 bytes however it has to be consistent with the maximum length
determined at the subscription of service - The ST analyses several fields of the headers 1 and 2: to get
the transmission mode of the message on the air interface (datagram mode -compulsory for the
“dedicated access” service-...), the MSB byte of UDP source port, the transmission priority on the air
interface...
- After the transmission of this message, the UDT is waiting (duration T4) for the
acknowledgement (message STU_PERIODIC_ACCESS_EMISSION_ACK) from the ST.
This radio emission acknowledgement may be positive or negative. If the UDT does not
receive this message within T4, it has to consider that the data emission on the air interface
has failed (same behaviour as on a negative radio emission acknowledgement).
- in case of ST-UDT link failure (receipt of an indication of closing for the link level service)
while the UDT is waiting for the radio emission acknowledgement, the UDT has to consider
in the same way that the data emission on the air interface has failed (same behaviour as
on a negative radio emission acknowledgement).
- The UDT is allowed to send another uplink data transfer request to the ST before receiving the radio
emission acknowledgement (message STU_PERIODIC_ACCESS_ EMISSION_ACK) for its previous
request. Nevertheless, as the ST owns only one emission buffer, this new message replaces the
previous one for the same application. In case of different application, RT memorises one message for
each subscribed application.
- In case of mistake on a field of the headers 1 or 2 or on the length of the transmitted data, the ST
sends a negative radio emission acknowledgement to the request.
- The UDT is allowed to send this request only if the ST's DTAP interface version is equal or higher than
5.
Encoding:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
IDENTIFIER 1
DATA LENGTH 3
DATA
4+x
7.1.2.2.9. STU_PERIODIC_ACCESS_EMISSION_ACK
Short description: positive or negative radio emission acknowledgement for an uplink data transfer
request with the “periodic access” service from the UDT
Parameters:
- Internal identifier
Notes:
- This acknowledgement is a radio emission acknowledgement: it means, when it is positive, that the
terminal has sent the data on the air interface. It is not a radio transmission acknowledgement like the
message STU_RADIO_TRANSMISSION_ACK which means, when it is positive, that the base station
has received the data.
- The UDT uses the fields "failure family", "failure type of cause" and "failure cause" to report through the
Control and Supervision Driver (see chapter 4.2 and [7]) the transmission failures of the uplink data
messages with the “dedicated access” service.
- In case of ST-UDT link failure (receipt of an indication of closing for the link level service) while the
UDT is waiting for the acknowledgement, the UDT has to consider that the data emission on the air
interface has failed (see note on the message UTS_PERIODIC_ACCESS_DATA_U). If the ST receives
a new uplink data transfer request with sending on dedicated access service while an uplink data transfer
with sending on dedicated access service is not yet completed, it sends a negative acknowledgement for
the old message.
Encoding:
Result ok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
1
IDENTIFIER
2
RESULT 3
Result nok:
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
1
IDENTIFIER
2
RESULT 3
FAILURE FAMILY 4
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
ENC_ST RAD_HEADER_LG 1
PRIO PROT 2
CNA CNA_EXT 3
5
SOURCE_ADDRESS
6
Data radio header
7
8
DESTINATION_PORT
9
10
SOURCE_PORT
11
RAD_HEADER_EXT_LG 12
INFO_1
INFO_P
N
DATA_LG
N+1
N+2
DATA
IE K Condition F Length
ENC_ST M Shall define the encryption request V 2 bits
01 mandatory encryption
10 facultative encryption
RAD_HEADER_LG M indicates the length of the radio V 6 bits
header starting at the following
octet
0x0A
PRIO M Shall define the external priority V 4 bits
0011 Routine
0111 Urgent
1011 Flash
PROT M Shall define the supported V 4 bits
protocols
1000 UDP
CNA M Shall define the address type V 4 bits
0111 Extension value
CNA_EXT M 0001 IP V4 formatting V 4 bits
0010 MC9600 binary formatting
SOURCE_ADDRESS M V 4 octets
DESTINATION_PORT M V 2 octets
SOURCE_PORT M V 2 octets
RADIO_HEADER_EXT_LG M indicates the length of the radio V 1 octet
header extension starting at the
following octet
0x00
INFO_1 to INFO_P O Not used TLV variable
DATA_LG M indicates the length of the data field V 2 octets
starting at the following octet
DATA O V variable
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1 .
ENC_RQ RAD_HEADER_LG 1
PRIO PROT 2
CNA CNA_EXT 3
5
DESTINATION_ADDRESS
6
Data radio header
7
8
DESTINATION_PORT
9
10
SOURCE_PORT
11
RAD_HEADER_EXT_LG 12
INFO_1
INFO_P
N
DATA_LG
N+1
N+2
DATA
IE K Condition F Length
ENC_RQ M Shall define the encryption request V 2 bits
01 mandatory encryption
10 facultative encryption
RAD_HEADER_LG M indicates the length of the radio V 6 bits
header starting at the following
octet
0x0A
PRIO M Shall define the external priority V 4 bits
0011 Routine
0111 Urgent
1011 Flash
PROT M Shall define the supported V 4 bits
protocols
1000 UDP
CNA M Shall define the address type V 4 bits
0111 Extension value
CNA_EXT M 0001 IP V4 formatting V 4 bits
0010 MC9600 binary formatting
DESTINATION_ADDRESS M V 4 octets
DESTINATION_PORT M V 2 octets
SOURCE_PORT M V 2 octets
RADIO_HEADER_EXT_LG M indicates the length of the radio V 1 octet
header extension starting at the
following octet
0x00
INFO_1 to INFO_P O Not used TLV variable
DATA_LG M indicates the length of the data field V 2 octets
starting at the following octet
DATA O V variable
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1
net field
station field
R_NUMBER 1
3
FSI_NUMBER
4
CNA/CNA_EXT = "IP V4 formatting"
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1
NETWORK_ID 1
SUBNETWORK_ID 2
3
FSI_NUMBER
4
R_NUMBER Field of 12 bits
R part of the RFSI number. Binary coding, from 0 to 999.
R_NUMBER 1
GROUP_PREFIX 2
GROUP_PREFIX 3
GROUP_ID 4
CNA/CNA_EXT = "IP V4 formatting"
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1
NETWORK_ID 1
SUBNETWORK_ID GROUP_PREFIX 2
GROUP_PREFIX 3
GROUP_ID 4
GROUP_PREFIX Field of 8 bits
11110110 Group address
0 0 0 0 0 0 0 1 1
0 0 0 0 ST_FUNCT_PREFIX 2
ST_FUNCT_PREFIX FUNCT_TYPE 3
0 0 0 FUNCT_NUMBER 4
ST_FUNCT_PREFIX Field of 8 bits
11110101 ST dedicated functional address
0 0 0 0 0 0 0 1 1
0 0 0 0 <--------DP_FUNCT_PREFIX- 2
----------> 0 0 FUNCT_NUMBER 3
DP dedicated IP functional
ORGANIZATION 4
address
DP_FUNCT_PREFIX Field of 5 bits
11111 DP dedicated functional address
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1
net field
station field
R_NUMBER 1
3
FSI_NUMBER
4
CNA/CNA_EXT = "IP V4 formatting"
. 8 . 7 . 6 . 5 . 4 . 3 . 2 . 1
NETWORK_ID 1
SUBNETWORK_ID 2
3
FSI_NUMBER
4
R_NUMBER Field of 12 bits
R part of the RFSI number. Binary coding, from 0 to 999.
0 0 0 0 0 0 0 1 1
0 0 0 0 GENERIC_FUNCT_PREFIX 2
GENERIC_FUNCT_PREFIX 3
GENERIC_FUNCT_NUMBER 4
GENERIC_FUNCT_PREFIX Field of 8 bits
11110101 generic functional address
The purpose of this chapter is to highlight some significant data flows diagrams between the ST and the
UDT.
In the first diagram (7.1.3.1.), the three levels (physical, link -MPAP- and applicative -DTAP-) undertaken
on the UDT-ST link are shown with the associated timers.
In the next diagrams, we show only the applicative DTAP exchanges and the link level
acknowledgements of these DTAP messages. Timers are not shown any more.
Note: the link level exchanges (MPAP) are shown with a dotted line:
UTS_X
level 2 ack
T xyz
STU_Y
*
ST UDT
Asynchronous line
reinitialization
T_N2 CNX
MPAP
connection
ACK_CNX
*
T_Presence x2
T_N2 DATA: STU_CONNECT
* ACK_DATA
DTAP T_Presence
connection
DATA : UTS_CONNECT_ACK T_N2
ACK_DATA *
DATA: STU_ST_PRESENCE * x2
T_Presence
T_N2
ACK_DATA
*
T_Presence
DATA : UTS_ST_PRESENCE_
ACK
T_N2
ACK_DATA
*
Note: in order not to overload the diagram, timers T1 et T5 are not shown.
T_N2: link level timer for frame acknowledgement: see [8] chapter 7.3.2.
ST UDT
DATA : UTS_DATA_U
Uplink message
radio emission ACK_DATA
DATA : STU_RADIO
_TRANSMISSION_ACK
ACK_DATA
Note: the UTS_DATA_U message may be segmented. The different segments are not
shown on the diagram.
ST UDT
DATA : STU_DATA_D
ACK_DATA
Data erasure in
memory M2
Note: The STU_DATA_D message may be segmented. The different segments are not
shown on the diagram. In case of segmentation, the erasure of the message in saved
memory M2 happens only on receipt of the last link level acknowledgement (MPAP).
ST UDT
DATA : UTS_
POLLING_SUBSCRIPTION
Polling service
subscription radio ACK_DATA
emission
DATA : STU_POLLING_
SUBSCRIPTION_ACK
ACK_DATA
ST UDT
DATA :
UTS_POLLING_DATA_U
Polling message
ACK_DATA
radio emission
DATA : STU_
POLLING_EMISSION_ACK
ACK_DATA
ST UDT
DATA : UTS_DEDICATED_
ACCESS_SUBSCRIPTION
ACK_DATA
DATA : STU_DEDICATED_
ACCESS_SUBSCRIPTION_ACK
ACK_DATA
ST UDT
DATA : UTS_DEDICATED_
Dedicated acces ACCESS_DATA_U
message radio
emission
ACK_DATA
DATA : STU_DEDICATED_
ACCESS_EMISSION_ACK
ACK_DATA
ST UDT
DATA : UTS_PERIODIC_
ACCESS_SUBSCRIPTION
ACK_DATA
DATA : STU_PERIODIC_
ACCESS_SUBSCRIPTION_ACK
ACK_DATA
ST UDT
DATA : UTS_PERIODIC_
periodic acces message ACCESS_DATA_U
radio emission
ACK_DATA
DATA : STU_PERIODIC_
ACCESS_EMISSION_ACK
ACK_DATA
♦ value : 0x01
♦ value : 0x06
Timer durations
♦ T1 (ST): 10s
♦ T2 (UDT): 20s
♦ T3 (UDT): 300s
♦ T4 (UDT): 420s
♦ T5 (ST): 10s
Messages types
♦ STU_CONNECT 0x0000
♦ STU_NETWORK_INFORMATION 0x0001
♦ STU_ST_PRESENCE 0x0002
♦ STU_SERVICE_MESSAGE 0x0003
♦ STU_RADIO_TRANSMISSION_ACK 0x0004
♦ STU_DATA_D 0x0005
♦ STU_POLLING_SUBSCRIPTION_ACK 0x0006
♦ STU_POLLING_EMISSION_ACK 0x0007
♦ STU_ST_DATA_U_WINDOW_CHANGE 0x0008
♦ STU_DEDICATED_ACCESS_SUBSCRIPTION_ACK 0x0009
♦ STU_DEDICATED_ACCESS_EMISSION_ACK 0x000A
♦ STU_PERIODIC_ACCESS_SUBSCRIPTION_ACK 0x000B
♦ STU_PERIODIC_ACCESS_EMISSION_ACK 0x000C
♦ UTS_CONNECT_ACK 0x0050
♦ UTS_ST_CONTROL 0x0051
♦ UTS_DATA_U 0x0052
♦ UTS_POLLING_SUBSCRIPTION 0x0053
♦ UTS_POLLING_DATA_U 0x0054
♦ UTS_ST_PRESENCE_ACK 0x0055
♦ UTS_SDP_APPLICATION_STATUS 0x0056
♦ UTS_ST_DATA_U_WINDOW_CHANGE_ACK 0x0057
♦ UTS_DEDICATED_ACCESS_SUBSCRIPTION 0x0058
♦ UTS_DEDICATED_ACCESS_DATA_U 0x0059
♦ UTS_PERIODIC_ACCESS_SUBSCRIPTION 0x005A
♦ UTS_PERIODIC_ACCESS_DATA_U 0x005B
♦ reserved 0x005C
♦ reserved 0x005D
History
Document history
Date Status Comment
30 September 1997 Version 0.0.1 First version