10th International Command and Control Research and Technology Symposium

The Future of C2

Paper 41

Tactical Digital Information Link-Technical Advice and Lexicon for Enabling

Simulation (TADIL-TALES)

Topic: C4ISR/C2 Architecture

Joe Sorroche
ASRC Communications, Ltd.
Distributed Mission Operations Center
4500 Aberdeen Dr., SE, Building 942
Kirtland Air Force Base, New Mexico 87117
505-853-0372, DSN 263-0372
Fax 505-846-9971
[email protected]

A-1
Copyright (c) 2005 SISO Inc. All rights reserved.
This is an unapproved SISO draft document, subject to change.
 Form Approved
Report Documentation Page OMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it
does not display a currently valid OMB control number.

1. REPORT DATE 3. DATES COVERED

2. REPORT TYPE
JUN 2005 00-00-2005 to 00-00-2005
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
Tactical Digital Information Link-Technical Advice and Lexicon for 5b. GRANT NUMBER
Enabling Simulation (TADIL-TALES)
5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION

REPORT NUMBER
ASRC Communications Ltd,Distributed Mission Operations Center,4500
Aberdeen Dr., SE BG 942,Kirtland AFB,NM,87117
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT

NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT

Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
The original document contains color images.
14. ABSTRACT

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF
ABSTRACT OF PAGES RESPONSIBLE PERSON
a. REPORT b. ABSTRACT c. THIS PAGE
21
unclassified unclassified unclassified

Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std Z39-18
ABSTRACT: Link 16 is a Communications, Navigation, and Identification (CNI) system, intended to exchange
surveillance and Command and Control (C2) information among various C2 and weapons platforms, which enhance the
missions of each service. Links 16 provides multiple access, high capacity, jam resistant, digital data, and secure voice
CNI information to a variety of platforms. Link 16 is the primary NATO standard for the tactical datalink. NATO
STANAG 5516/MIL-STD-6016 describes the TADIL J message formats and Link 16 network instructions.

There are immediate operational requirements for existing military simulations to exchange TADIL J/Link 16 data using a
single interoperable standard. Several protocols have evolved to satisfy specific needs. The NATO STANAG 5602
“SIMPLE” Link 16 Standard is one such protocol. The standard is designed to be complementary to the SIMPLE Standard.
As C2 distributed simulation expands in mission scale and complexity, tactical datalink implementations need to
interoperate. Currently, there are five different Link 16 simulation protocols, and none interoperate. Recently, the
Simulation Interoperability Standards Organization (SISO) has developed a Link 16 Simulation Standard. The objective of
the simulation standard is to establish a single format to exchange TADIL J messages, and emulate a Link 16 radio
frequency network that supports Distributed Missions Operations (DMO) training for the warfighter. The Air Force
Distributed Mission Operations Center of Excellence (DMOC) located at Kirtland AFB, New Mexico, has sponsored these
efforts to ensure interoperability between C2 systems in the DMO training environment.

In developing a standard for simulating Link 16 in Distributive Interactive Simulation (DIS) and High Level Architecture
(HLA), it is recognized that there are widely varying requirements for achieving fidelity among different users. The
standard attempts to establish procedures that may be used by the vast majority of users, by establishing discrete, scalable,
interoperable levels of fidelity for different users. The standard also defines how each level of fidelity interoperates;
consequently, allowing a low cost initial implementation with a path toward upgrading to higher Link 16 simulation as
requirements evolve.

The IEEE 1278.1a-1998 Standard describes established DIS Transmitter and Signal Protocol Data Units (PDUs), but they
are not specifically defined for Link 16 simulation. The SISO Link 16 Standard does not change the IEEE 1278.1a-1998
Standard fields for the Transmitter or Signal PDUs, but exploits the fact that both PDUs are variable length. For
Transmitter PDUs, the standard defines how the variable length modulation parameter fields must be populated. For Signal
PDUs, Link 16 specific information is relegated to the variable length data fields. In addition, Link 16 specific
enumerations have been created to populate the standard fields.

The HLA instructions are formatted in compliance with the IEEE 1516 Standard for HLA. The instructions are presented
in the form of a Base Object Model (BOM) that may be incorporated into a system FOM. RPR-FOM based simulations
should be able to easily integrate the Link 16 BOM into their FOMs. Furthermore, there is a straightforward mapping
between the DIS PDU implementations and the corresponding BOM components.

This paper presents the Link 16 DIS Transmitter and Signal PDU structures, HLA HLA BOM Object Model Templates
(OMTs), general requirements, and implementation guidelines that provide interoperability among C2 systems.
1. Scope

This paper describes the protocol that establishes a standard for TADIL-J message exchange and JTIDS network
simulation in the DIS and HLA interoperability frameworks. The intent is to describe the content of the standard fields of
the Transmitter and Signal PDUs and establish procedures for their use. Compliance with these procedures will ensure
interoperability amongst JTIDS simulation systems. Additional detail can be found in Reference 1.

2. References

1. SISO-STD-002-V2.9.6 DRAFT, version 2.9.6, 7 March 2005

2. IEEE 1278.1 – 1995 IEEE Standard for Distributed Interactive Simulation – Application Protocols
3. MIL-STD-6016B, Tactical Digital Information Link (TADIL) J Message Standard (DRAFT) 15 March 2002
4. NATO STANAG 5602, edition 1, Standard Interface for Multiple Platform Link Evaluation (SIMPLE) 20 Feb
2001
5. System Segment Specification for Joint Tactical Information Distribution System Class 2 Terminal, 15 April 1999
6. STANAG 5516, Edition 1, Tactical Data Exchange - LINK 16, Ratified 15 January 1997.
7. LINK-16 Enhanced Throughput Standard, August 11, 1998 Doc # VSD-618255-97-339-02
8. Joint Interoperability of Tactical Command and Control Systems Variable Message Format (VMF) Technical
Interface Design Plan (Test Edition) Reissue 2, August 1996.

3. JTIDS Operating Characteristics

JTIDS uses the principle of frequency hopping Time Division Multiple Access (TDMA) to divide network time, and
capacity, into divisions called time slots. Each time slot is 7.8125 milliseconds long with 128 time slots per second. Time
slots are organized into three interleaved sets (A, B, and C). An epoch is 12.8 minutes long comprised of 32K time slots.
There are 112.5 epochs in a 24-hour day. Therefore, the current epoch, set and time slot number can be calculated from the
current time. Operationally, groups of time slots are assigned to a common function known as a Network Participation
Group (NPG). Time slot assignments are published in a network data load (by a central net design agency), with
participation groups identified by the time slot set, the “offset” of the time slot, and the time slot repetition rate. The
repetition rate is expressed as an exponential power of 2, representing how often the time slot assigned to the NPG occurs
within the set.
TDMA architecture requires that each JTIDS participant, known as a JTIDS Unit (JU), must know when its transmit time
slots occur. JUs must be synchronized with a common network time to receive and transmit on the network. In JTIDS, one
JU in a network is designated as the Network Time Reference (NTR).

4. General Requirements

This section describes general requirements for simulation of Link 16 independent of the simulation protocol used. The
specific implementation under DIS is described in section 5. The specific requirements for implementation under HLA are
described in section 6.
1. Simulators in compliance with this standard shall at a minimum have the capability to identify the NPG and net
number of transmitted data to allow them to operate at TSA mode level 0 and 1.
2. All TADIL J messages shall be bit encoded in accordance with the MIL-STD-6016 TADIL J specification. In the
specification, each time slot contains one 35-bit header, padded to 48 bits, and a varying number of 75 bit messages,
padded to 80 bits, unless the message type indicator specifies otherwise.
3. Regardless of level of fidelity, all transmission modulation parameter fields shall be filled with meaningful data
4. When the header indicates Reed-Solomon encoding, the data area shall still be comprised of non Reed-Solomon
encoded TADIL J messages.
5. Any simulator that is not emulating JTIDS network data load throughput shall have the ability to configure the
maximum number of JTIDS words transmitted per second, but shall not exceed the JTIDS maximum of 1536 J-words
 per second (twelve J-words per Pack-4 Single Pulse time slot multiplied by 128 time slots per second). This upper limit
shall not apply to JTIDS LET (Enhanced Throughput) packets.
6. If the packing mode from the JTIDS header and the number of messages contained in the Signal message do not agree,
(i.e. the header states that the packing mode is Pack-2 Double Pulse and there are 12 J-words contained with the
message) extra messages shall be dropped by the receiving simulator—as would happen in a live JTIDS datalink.
Simulators should be able to determine if the number of messages in the header matches the actual number of TADIL J
messages. If there are fewer messages in the data area than prescribed by the packing mode, the receiver shall treat the
missing messages as J31.7 “No statement” messages and parse the message stream accordingly.
7. Systems shall wait until the time slot occurs to transmit data in order to receive the latest update to data (i.e. time slots
shall not be “pre-sent”). Receiving systems shall buffer messages after the time slot has occurred to account for
network delays. The amount of time to buffer messages for a time slot shall be a runtime configuration item. The
amount of time entered shall be the same for all participants in the same network and will cause the simulations to all
“retire” a particular time slot at the same time. This effect is not important for lower levels of fidelity (Time Slot
Allocation (TSA) modes 0, 1) but is critical for all fidelity levels that tie a message to a particular time slot along with a
Network Data Load (NDL). If the effects of messages arriving later than the time slot are not important (multiple JUs
transmitting in the same time slot, contention access, or data arriving while the receiving JU is transmitting), or the
physical network infrastructure has low delays (less than 3 msec), the buffer time can be set to a low number or to zero.
8. All systems set at TSA level 2 or higher shall have their system times synchronized to a common time reference. Any
error in the clock synchronization times (e.g. average NTP error) must be added to the network delays (the buffer time)
before retiring a time slot. For real-time DIS or HLA simulation applications, NTP (or equivalent) is recommended. For
non-real-time simulation applications, HLA time management is recommended.
9. All systems should have some representation of a terminal clock time. If medium fidelity synchronization is to be
accomplished, the system shall model a terminal clock (and its associated drift).
10. At TSA level 2 or greater, if multiple messages are received with identical TSEC, net number and timeslot number,
receivers shall not process messages except from the closest transmitting entity (in the simulation space).
11. There are three communication modes for a real JTIDS/MIDS network: modes 1, 2 and 4 (See Table 1). The selected
communication mode determines whether or not the network can operate on multiple nets (by employing frequency
hopping) and the transmitted data are encrypted. All JUs in a JTIDS/MIDS network must operate in the same
communication mode.

Table 1. JTIDS Communication Modes

Frequency
Communication Mode Data Encrypted
Hopping
1 Yes Yes
2 No Yes
3 Not Used Not Used
4 No No

12. The normal JTIDS communication mode is mode 1. Frequency hopping and crypto variables are simulated appropriate
to the specified level of fidelity.
13. When operating with JTIDS communication mode 2, there will be no frequency hopping, but encryption shall still be
used, depending on the level of fidelity. The explicit frequency of 969 MHz shall be set in the transmission message
frequency field and the bandwidth will be 3MHz. The net number in the signal message shall be zero for all
transmissions (no multi-netting).
14. Mode 4 eliminates communications security in addition to the features of communications mode. The encryption fields
shall be set to 0 when in communications mode 4 in addition to specifying the explicit transmit frequency as in
communications mode 2.
15. Time slots shall be numbered sequentially, such that time slot 0 represents time slot A-1, time slot 98303 represents C-
32767. When the epoch is 112, the last valid time slot is 45151 (end of the day).
16. Generated machine receipts shall use time slots as assigned in the network description. There is no special
consideration given to machine receipts; they are treated as any other TADIL J fixed format message.
17. Relay is accomplished by transmitting relay information in assigned time slots. There is no special mechanism
necessary to simulate relay transmissions.
18. Transmission messages shall only be sent with signal messages in conjunction with the following events: entering the
Link 16 network, exiting the Link 16 network, during synchronization state changes, with PPLI messages, and with
initial net entry messages.

4.1 Levels of Fidelity

This protocol allows simulations to achieve different levels of fidelity by assigning one of five Time Slot Allocation (TSA)
levels. If the simulator allows for a settable level of fidelity, the level of fidelity shall be set at runtime. The TSA level
shall be set in Modulation Parameter #1 of the transmission packet with an enumeration of 0-4 as described in Table 2.

Table 2: JTIDS Levels of Fidelity

TSA Synchronization
Fidelity Issues Recommended Usage
Level Fidelity
0 Low Low Does not emulate JTIDS Experiments and/or training concerned with
network characteristics. Data message format and/or message content
rates are not constrained. only.
Intended for legacy use.

1 Low Low Does not emulate JTIDS Allows for bandwidth throttling to emulate
network characteristics. JTIDS network throughputs without
assigning messages to specific time slots.
Net Data Loads can be loaded into terminal
simulation equipment to simulate data rates
in NPGs on the Link 16 network.
2 Medium Low Network delay must be Experiments and/or training concerned with
sufficiently small if time slot throughput limits of the Link 16 network.
sensitive conversations are Also suitable for experiments/training
required to duplicate live emulating message traffic and timing of
Link 16 networks (e.g. relay JTIDS networks without emulating effects
emulation, RELNAV, of RTTs, RELNAV, or stacked/multi-nets.
messages requiring
responses).
3 Medium Low Same as TSA Level 2. Experiments and/or training concerned with
emulating stacked-, multi-, and crypto- net
emulation.
4 High Medium Extremely sensitive to Experiments and/or training concerned with
network latency. effects deriving from emulation of network
entry and synchronization maintenance.

TSA level 0 is the lowest level of fidelity. The NPG and net fields are filled in the signal message, but all other data in the
JTIDS transmission header is set to the default value. Multiple messages are permitted in a single Signal message. All
messages within the signal message are assumed to be for the same NPG and Net with the same assumed packing. There is
no TSA or metering with up to the maximum number of messages (as specified in the DIS standard) packed into the data
area of a single signal message.
TSA Level 1 is similar to TSA Level 0 except that there is minimal metered data. When the TSA level is set to one, one
time slot worth of information shall be in one Signal message. As in TSA level 0, the NPG and net fields are filled in, and
the rest of the transmission information is set to default.

TSA Level 2 allows for metered data with no encryption. When the TSA level is set to 2, messages shall be assigned to
individual time slots. The NPG, net, and time slot identification fields are filled in. The TSEC and MSEC are set to
default. This level enables full TSA to include Encryption. When TSA mode is set to 3, stacked nets, multi-nets, and
crypto-nets can be emulated. All transmission information fields are filled in. Low fidelity synchronization is achieved in
accordance with paragraph 5.3.1.

TSA Level 4, everything from TSA 3 is emulated, with the addition of the medium fidelity synchronization procedures. All
JTIDS header fields in the signal message shall be filled with non-default meaningful values. Medium fidelity
synchronization is achieved in accordance with paragraph 5.3.2.
4.2 Communication between JUs with different fidelity levels
In the event that participants in a simulated JTIDS network cannot set their respective simulations to operate at a common
level of fidelity (i.e. TSA Level) the following procedures apply:
If a low fidelity network participant is in a simulated JTIDS network with a higher fidelity NTR, the network participant
shall follow the low fidelity synchronization procedures in paragraph 5.3.1 by skipping the RTT synchronization process
and changing directly to the fine synchronization state once it receives a J0.0 Initial Entry message from the NTR or any
IEJU.
If a higher fidelity network participant is in a simulated JTIDS network with a lower fidelity NTR, the higher fidelity
participant shall either follow the low fidelity synchronization procedures in paragraph 5.3 or achieve fine sync with other
high fidelity simulators. This can be accomplished by exchanging RTT B messages or by passively synchronizing with
other available high fidelity simulators. If no other high fidelity simulators are available to synchronize with, the high
fidelity participant shall skip the RTT exchange, and directly enter fine synchronization once the J0.0 is received.
If the NTR is a lower fidelity simulation and unable to simulate full NTR duties, the NTR shall still have the ability to
transmit net entry messages. The signal message shall be filled in with a J0.0 with zeroed time slot information. RTT
emulation will not be required of low fidelity NTRs.
A lower fidelity JU entering the net shall use the network synchronization ID received from the NTR/IEJU in its
Transmitter messages. It will then issue PPLIs at the assigned rate. This is nominally once every 12 seconds (equivalent to
the A-0-6 time slot block), though this can occur at times of up to 24 seconds. All simulators, regardless of fidelity, shall
accept another terminal’s statement of synchronization capability if the network synchronization ID matches its own
network synchronization ID.
In a lower fidelity synchronization simulation, non-reception of a PPLI message pair for 60 seconds shall indicate that the
unit has fallen out of the datalink. Synchronization procedures shall be re-accomplished—reception of a PPLI message
stating fine synchronization must occur before data from the JU will be accepted.
4.3 Time Synchronization
For TSA Level 0-2, the Network Synchronization shall be set to zero. For TSA Level 3-4, the Network Synchronization
IDs shall be a 32 bit unsigned integer uniquely generated by the NTR. The NTR shall use either a non-deterministic
random number generator or a pseudo-random number generator using the timestamp of the time they begin to simulate a
NTR as the random key seed. If using a seed based pseudo-random number generator, use the NTR selection time with
precision equivalent to Network Time Protocol (NTP) as the seed. Seedless random number generators are encouraged; the
goal is to make sure that all NTRs have unique synchronization IDs in the transmitter PDU.
If a system in the real world is capable of acting as NTR, any corresponding simulator shall also be capable, at a minimum,
of acting as a low fidelity NTR.
If no simulators in a simulated JTIDS net are capable of acting as a NTR, participants shall be able to set the network
synchronization ID to zero and transmit the synchronization state of fine synchronization. A zero in the network
synchronization ID field shall be accepted as a wildcard matching any network synchronization ID.
If a network synchronization ID accompanying received data does not match a JU’s own network synchronization ID, the
data shall be considered as having not been received.
Simulated terminals shall accept net entry messages (J0.0) from any simulated transmitting terminal within reception
range. When medium fidelity synchronization is applicable (TSA Mode level 4), and the net entry message has a network
synchronization ID different than the local network synchronization ID, the JU shall revert back to coarse synchronization,
use the new network synchronization ID, cease sending TADIL J data and attempt re-synchronization with the new
network in accordance with the JTIDS terminal specification. If the network synchronization ID (i.e. during changeover of
NTR or multiple IEJUs) is the same as the locally held key, the JU will not revert to coarse synchronization status and will
not stop transmitting TADIL J data.
If an initial net entry message is received from a unit that does not have a Transmitting Terminal Primary Mode of IEJU or
NTR, it shall still be accepted. Depending upon implementation, the simulation operator may be notified so that the
sending simulator can correct this error condition.
All simulators shall have at least a low fidelity simulation of a terminal clock, potentially independent of the simulator’s
(or live equipment’s) clock. Since whatever time an NTR has set is considered correct, an NTR may transmit a time that
significantly varies from the actual simulated wall clock. In high fidelity simulation systems the terminal clock may model
the clock drift of an actual JTIDS terminal. It is not expected that terminal clocks will be modeled at a high level of fidelity
and the actual level of emulation is left to the implementer.
4.3.1 Low Fidelity Synchronization
Low fidelity synchronization is applicable to simulation systems interested primarily in providing tactical datalink
information as part of an operational scenario. The low fidelity synchronization procedure allows such systems to exchange
Link 16 messages without being encumbered by actual JTIDS transmission and message security requirements.
The NTR shall begin by issuing Net Entry message pairs at a rate in accordance with the JTIDS terminal specification
(typically in time slot A-0-6 at a rate of every 12 seconds). A unique randomly generated key shall be filled into the
network synchronization ID field. The primary JTIDS duty field shall contain a NTR enumeration.
Modulation Parameter 4 (Synchronization State) in the transmission message shall be set to “fine synchronization” after
reception of the J0.0 Initial Net Entry message from the IEJU or NTR. The first data message that will be sent by a JU
entering the network shall be the JU’s PPLI.
4.3.2 Medium Fidelity Synchronization
Medium Fidelity Synchronization corresponds to only the high fidelity TSA level 4. It is applicable to those systems for
which simulation of the fine synchronization methodology is paramount, potentially for high fidelity training, network
testing and network experimentation. Because the latency of WANs (latencies up to hundreds of milliseconds) is orders of
magnitude higher than in a real Link 16 network (latencies up to 3ms), this methodology will not meet the needs of sub-
millisecond accuracy.

Communities with the need for sub-millisecond accuracy will need to use a centralized server on a real-time operating
system to simulate the microsecond intricacies of the JTIDS network. The term “High Fidelity Synchronization” will be
reserved for synchronization mechanisms that are able to model the sub-millisecond accuracy of the Link 16 network.
The accuracy of the synchronization mechanism shall have an error less than the simulated time of propagation. The
accuracy of the synchronization mechanism must be taken into account when modeling fine synchronization.
The Medium Fidelity Synchronization procedure is as follows: First, the NTR shall begin by issuing Net Entry message
pairs at a rate in accordance with the JTIDS terminal specification (typically in time slot A-0-6 at a rate of every 12
seconds). A unique randomly generated key shall be filled into the network synchronization ID field. The primary JTIDS
duty field shall contain a NTR enumeration. At this point, the JU is considered to have achieved “coarse synchronization.”
The JU shall then transmit the appropriate RTT message (A or B). The synchronization state shall be set to “coarse
synchronization.” The JU shall use its own terminal perceived time in the perceived transmit time field. The appropriate
NTR/JU will answer (in accordance with the JTIDS terminal specification), using the JU perceived time and the entity
distance to calculate the perceived receive time. The RTT is then transmitted. The transmitting JU shall fill its own
terminal perceived time with the received transmit time field. The formula for filling in the receive time in the RTT reply
is: RTTreply = RTter min al − t delay + t propagate

i. The tdelay is computed by: t delay = RTtime − TTtime

b. Where
RTtime is the actual time held by the receiving/replying participant (Derived from NTP, GPS, etc)
RT terminal is the value of the simulated Link 16 terminal clock at the receiving/replying participant
TTtime is the actual time held of transmitting participant (Derived from NTP, GPS, etc)
tdelay is the difference between the receiver’s real-time clock at the time of receipt and the sender’s real-
time clock at the time of transmission (i.e. it approximates the emulation network latency), and
tpropagate is the propagation time of the radio frequency message in the simulated environment.
This formula computes the perceived time of receipt by the receiving simulator with respect to the simulated terminal clock
of the sender.
The originating JU shall then update its own terminal time in accordance with the simulator model and the Link 16 fine
synchronization procedures. After the appropriate number of RTT exchanges have occurred (depending whether the RTT
A or RTT B method of synchronization was used and the internal terminal simulation model), the JU shall consider itself to
be in fine synchronization and shall continually issue RTT message pairs to maintain synchronization at rates specified
within the JTIDS terminal specification. Once the terminal emulator model has met the requirements for fine
synchronization, normal message transmissions occur in accordance with Ref. 7 and Ref. 10.
5 JTIDS implementation under DIS

This section contains the requirements for simulation of JTIDS using the DIS Signal and Transmitter PDU. For the DIS
Protocol Profiles, transmission and receipt of PDUs, and general service requirements, refer to Reference 1. In
implementing the Signal PDU, perceived data should be able to be sent on a configurable port separate from all other DIS
data. This allows datalinks to be selectively routed without additional hardware. This also allows for gateways to forward
data between legacy DIS datalink formats and the new standardized format.
5.1 Transmitter PDU Description
Table 3 shows the format for the Transmitter PDU for JTIDS simulation.

Table 3: Transmitter PDU for TADIL J

Field Size
Transmitter PDU Fields Description*
(bits)
Protocol Version 8 bit enumeration
8 bit unsigned
Exercise ID
96 PDU Header integer
PDU Type 8 bit enumeration
Protocol Family 8 bit enumeration
32 bit unsigned
Timestamp
integer
 Table 3: Transmitter PDU for TADIL J

Field Size
Transmitter PDU Fields Description*
(bits)
16 bit unsigned
Length
integer
Padding 16 bits unused
16 bit unsigned
Site
integer
16 bit unsigned
48 Entity ID Application
integer
16 bit unsigned
Entity
integer
16 bit unsigned Shall contain the ID of the radio
16 Radio ID
integer transmitting the signal.
Entity Kind 8 bit enumeration
Domain 8 bit enumeration
Country 16 bit enumeration
Radio Entity 21 - Link 16 terminal IAW Ref. 4
64 Category 8 bit enumeration
Type para 4.2.3.7
Nomenclature
8 bit enumeration
Version
Nomenclature 16 bit enumeration
8 Transmit State 8 bit enumeration
8 Input Source 8 bit enumeration 8 - Digital Data Device
16 Padding 16 bits unused
X component 64 bit floating point
Antenna
192 Y component 64 bit floating point
Location
Z component 64 bit floating point
Relative x component 32 bit floating point
96 Antenna y component 32 bit floating point
Location z component 32 bit floating point
Antenna
16 16 bit enumeration
Pattern Type
Antenna
16 bit unsigned
16 Pattern
integer
Length
Mode 1 = 1131000000 (center
64 bit unsigned
64 Frequency frequency). For Mode 2 or 4, set
integer
to 969000000
Transmit 240000000 unless in
32 Frequency 32 bit floating point Communications mode 2 or 4,
Bandwidth then 3000000
32 Power 32 bit floating point Power in dBm
Bit 1 set to 1: Frequency
Hopping for JTIDS
Modulation
64 Spread Spectrum 16 bit Boolean array communications mode 1.
Type
All bits set to 0: For JTIDS
communications modes 2 or 4
 Table 3: Transmitter PDU for TADIL J

Field Size
Transmitter PDU Fields Description*
(bits)
7 - Carrier Phase Shift
Major 16 bit enumeration
Modulation (CPSM)
Detail 16 bit enumeration 0 - Other
System 16 bit enumeration 8 - JTIDS/MIDS
Crypto
16 16 bit enumeration 0 - Other
System
Crypto Key 16 bit unsigned
16
ID integer
Length of
8 bit unsigned
8 Modulation 8= 8 octets
integer
Parameters
24 Padding 24 bits unused
Modulation Time Slot
8 8 bit enumeration Integer enumeration 0-4
Parameter #1 Allocation Mode
Transmitting Integer Enumeration:
Modulation
8 Terminal Primary 8 bit enumeration 1 - NTR
Parameter #2
Mode 2 - JTIDS Unit Participant
Integer Enumeration:
0 - None
Transmitting 1 - Net Position Reference
Modulation
8 Terminal 8 bit enumeration 2 - Primary Navigation
Parameter #3
Secondary Mode Controller
3 - Secondary Navigation
Controller
Integer Enumeration:
Modulation Synchronization
8 8 bit enumeration 2 - Coarse Synchronization
Parameter #4 State
3 - Fine Synchronization
Network TSA Level 0-2, set to 0
Modulation 32 bit unsigned
32 Synchronization TSA Level 3,4, set to 32 bit
Parameter #5 integer
ID random number

Transmitter PDUs used in Link 16 simulation shall include all of the standard information, as well as the information
described in the modulation fields. The Transmitter PDU shall contain the following fields:
1. The Radio Entity Type Category field shall be set to 21 for Link 16 terminal.
2. The Input Source field shall be set to 8 for Digital Data Device.
3. Frequency. This field shall specify the JTIDS center frequency of 1131000000 for communications mode 1. For
communications mode 2 or 4, a frequency of 969000000 shall be used.
4. Transmit Frequency Bandwidth. This field shall contain the bandwidth of the JTIDS signal, simulating the use of the
entire frequency band as an average over time. The field shall be represented by a 32-bit float value of 240000000,
unless operating in communications mode 2 or 4, and then a value of 3000000 shall be used.
5. Modulation Type. The Modulation Type fields contain enumerations for the major and detail modulation fields:
a. The Spread Spectrum field is a 16-bit Boolean array, and shall be set to 1 for frequency hopping only for
JTIDS communications mode 1. For modes 2 or 4, the Spread Spectrum field shall be set to 0.
 b. The Major modulation field is a 16-bit enumeration, and shall be set to 7 for Carrier Phase Shift Modulation.
c. The Detail modulation field is a 16-bit enumeration, and shall contain a 0.
d. The System field is a 16-bit enumeration, and shall be set to 8 for JTIDS/MIDS

6. Crypto System. For Link 16 simulation under this standard this field shall be set to zero.
7. Crypto Key ID. For Link 16 simulation under this standard this field shall be set to zero.
8. Length of Modulation Parameters. These fields shall specify the length in octets of the modulation parameters that
follow this field. This length shall be set to 8, representing 8 octets for the DIS J Transmitter PDU.
9. Modulation Parameters. These fields shall specify the modulation type specific characteristics of the Transmitter PDU.
a. Modulation Parameter 1 shall contain the TSA mode with an enumeration of 0-4 for TSA level 0-4 as
described in section 4.1.
b. Modulation Parameter 2 shall contain the transmitting terminal’s primary mode. Setting the enumeration to 1
shall indicate that the entity is the NTR. Setting it to 2 shall indicate that the entity is a JU participant.
c. Modulation Parameter 3 shall contain the transmitting terminal’s secondary mode, with the following
enumerations: 0=None, 1=Net Position Reference, 2=Primary Navigation Controller, 3=Secondary
Navigation Controller.
d. Modulation Parameter 4 shall contain the synchronization state. For TSA mode level 0-3 this shall be set to 3
for “fine” synchronization. For TSA level 4, it is initially set to 2 for “coarse” synchronization and the
procedures in section 4.3.2 for medium-level synchronization are followed.
e. Modulation Parameter 5 shall contain the Network Synchronization ID. For TSA modes 0-2, it shall be set to
default. For TSA modes 3-4, it shall be a 32-bit random integer. Only an NTR can generate a Network
Synchronization ID; all other participants shall use the ID obtained from the NTR to which they are
synchronized.
5.2 Signal PDU Description
The Signal PDU includes all standard fields as described in Reference 2. Examples of the Signal PDU for TSA Levels 0-3
are found in Reference 1, Annex B.
When used for Link 16 simulation the following specific information is required:
1. Entity and Radio ID. These fields shall contain the ID of the entity and radio transmitting the signal. Radios are
numbered sequentially starting with 1.
2. Encoding scheme. Bits 0-13 shall contain the number of J-words not including the JTIDS header. Bits 14-15 shall
contain the value 1 to indicate an encoding class raw binary data.
3. TDL Type. This field shall specify the TDL type as a 16-bit enumeration field, and shall be set to 100 for Link 16
JTIDS/MIDS/TADIL J.
4. Sample Rate. The sample rate shall be set to zero.
5. Data Length. This field shall contain the length of data in bits beginning after the samples field.
6. Samples. This field shall be set to zero.
7. Data Field. The JTIDS Network header portion of the Data Fields of the Signal PDU shall be set as follows:
8. Net Number. This field is an 8-bit unsigned integer, and is used to create virtual sub-circuits within NPG for stacked
nets or between NPGs for multi-net.
9. Network/Needline Participation Group (NPG) Number. This field is a 16-bit unsigned integer (0-511) used to
segregate information within a JTIDS/MIDS network. It creates virtual networks of participants.
 10. TSEC CVLL. This field is an 8-bit unsigned integer, and is used for transmission security, and allows for simulated
crypto netting. For TSA Mode 0-2 this record is not required and the field is set to “all F’s” indicating a no
statement/wildcard.
11. MSEC CVLL. This field is an 8-bit unsigned integer, and is used for message security, is used in conjunction with
the TSEC CVLL, and allows for simulated crypto netting. For TSA Mode 0-2 this record is not required and the
field is set to “all F’s” indicating a no statement/wildcard.
12. Message Type Identifier. This field specifies the format for the type of Link 16 message in the PDU. This field shall
be set with an enumeration in accordance with Table 4.

Table 4: Message Type Identifiers

Message Type Enumeration

JTIDS Header/Messages 0
RTT A/B 1
RTT Reply 2
JTIDS Voice CVSD 3
JTIDS Voice LPC10 4
JTIDS Voice LPC12 5
JTIDS LET 6
VMF 7

13. Time Slot ID. For TSA level 0-1, this field is set to zero. This field is a 32-bit unsigned integer, and shall contain
time slot information for time slot and epoch number in accordance with REF. 5. Time Slot number is bits 0 – 16.
Time Slot 0 represents time slot A-1, time slot 98303 represents C-32767. When the epoch is 112, the last valid time
slot is 45151. Bits 17 – 23 are padding and set to 1 for level 3. Bits 24 – 31 are the epoch number. An epoch is 12.8
minutes long, and there are 112.5 epochs in a 24-hour day.
Table 5 shows the format for the Signal PDU for JTIDS simulation.

Table 5: SIGNAL PDU for TADIL J

Field
Valid
Size Signal PDU Fields Description
Range
(bits)
8 bit
Protocol Version enumeration
8 bit unsigned
Exercise ID integer
8 bit
PDU Type enumeration
PDU
96 8 bit
Header
Protocol Family enumeration
32 bit unsigned
Timestamp integer
16 bit unsigned
Length integer
Padding 16 bits unused
16 bit unsigned
48 Entity ID
Site integer
 Table 5: SIGNAL PDU for TADIL J

Field
Valid
Size Signal PDU Fields Description
Range
(bits)
16 bit unsigned
Application integer
16 bit unsigned
Entity integer
16 bit unsigned Shall contain the ID of the radio
16 Radio ID integer transmitting the signal.
Bits 0-13 shall contain the number
of J-words not including the JTIDS
header. Bits 14-15 shall contain the
Encoding 16 bit value 1 to indicate an encoding
16 Scheme enumeration class raw binary data
16 bit This field shall be set to 100 for
16 TDL Type enumeration Link 16 JTIDS/MIDS/TADIL J
Sample
32 Rate 32 bit integer This field shall be set to 0
This field shall contain the length
Data of data in bits beginning after the
16 Length 16 bit integer samples field.
16 Samples 16 bit integer This field shall be set to 0
Network/Needline Participation
Group (NPG) Number. Used to
16 bit unsigned
NPG Number 0-511 segregate information within a
integer
JTIDS/MIDS network. Creates
virtual networks of participants.
Network Number. Used to create
8 bit unsigned virtual sub-circuits within NPG for
Net Number 0-127
integer stacked nets or between NPGs for
multi-net.
Transmission Security, an integer
identification of the crypto variable
used for JTIDS transmission
JTIDS 8 bit unsigned
TSEC CVLL 0-127, FF encryption. This variable allows for
160 Network integer
simulated crypto netting. All F’s in
Header this field shall indicate a no
statement/wildcard.
Message Security, an integer
identification of the crypto variable
used to encode the JTIDS message.
8 bit unsigned
MSEC CVLL 0-127, FF This variable allows for simulated
integer
crypto netting. All F’s in this field
shall indicate a no
statement/wildcard.
 Table 5: SIGNAL PDU for TADIL J

Field
Valid
Size Signal PDU Fields Description
Range
(bits)
Determines whether normal JTIDS
header and message, RTT A/B,
Message Type 8 bit RTT Reply, JTIDS Voice, LET
Identifier enumeration JTIDS, or VMF follows. See table
5.2.2 for message type identifier
enumerations
Padding 16 bits 0 Set to 0
Time Slot number; Time Slot 0
Time represents time slot A-1, time slot
Slot Bits 0-16 0-98303 98303 represents C-32767. When
Number the epoch is 112, the last valid time
slot is 45151 (end of the day)
Time
Slot ID Padding Bits 17-23 0 Set to 0

JTIDS Network
Header (Con’t) An epoch is 12.8 minutes long,
Epoch
Bits 24-31 0-112 112.5 Epochs in a 24 hour day. Part
Number
of time slot identification
NTP timestamp format-- NTP
timestamps are represented as a 64-
bit unsigned fixed-point number, in
seconds relative to 0h on 1 January
1900. The integer part is in the first
32 bits and the fraction part in the
Perceived 64 bit unsigned last 32 bits. The precision of this
Transmit Time integer representation is about 200
picoseconds, which should be
adequate for even the most exotic
requirements. See RFC1305 for
detailed format. All F’s in this field
shall indicate a no
statement/wildcard.
The message data, corresponding to
TADIL J Message Data the appropriate message type and
described in Reference 1.

6 Implementation of Link 16 under the HLA

Link 16 TDL simulations are almost always part of a wider simulation - such simulations are used for many purposes
including system development, test & evaluation and training. It is therefore almost certain that the HLA implementation of
the Link 16 protocol will form part of a larger Federation Object Model (FOM). The HLA implementation of Link 16 is
therefore defined as a Base Object Model (BOM), as described in BOM Study Group Final Report: (SISO-REF-005-2001).
A BOM is defined as "a single aspect of simulation interplay that can be used as a building block" within a FOM.
The Link 16 BOM is described in the Object Model Template (OMT). The standard for HLA is IEEE 1516—2000
(Reference 2) in which the OMT is put forth in extensible Markup Language (XML). However, at the time of writing,
many federations still use the older HLA 1.3 (Reference 3) pre-XML OMT format. In order to facilitate implementation,
two versions of the BOM have been created. The file Link16-BOM.omd contains the HLA 1.3 OMT tables. These tables
are reproduced in Annex A of this standard. A second file, link16bom.xml, complies with the OMT XML format found in
Ref. 2. Both files, as well as the complete OMT tables may be found at the SISO web site (http://www.sisostds.org).
6.1 The Link 16 BOM

The Link 16 BOM is intended to describe how to implement a simulation of the Link 16 Tactical Data Link (TDL) and its
associated message set, TADIL J, within a High Level Architecture (HLA) simulation. The Link 16 BOM is designed for
integration within the Federation Object Model (FOM) of the HLA federation.
6.1.1 Assumptions

The Link 16 BOM assumes that:

1. The parent FOM contains all current DIS Transmitter PDU parameters as part of its object class hierarchy.
2. The parent FOM contains all current DIS Signal PDU parameters as part of its interaction class hierarchy.
6.1.2 Naming Convention

Conventions within the Link 16 BOM in OMT 1.3 format follow those adopted by the RPR FOM. These conventions are
intended to address some of the OMT 1.3 format shortcomings, which have been addressed in the IEEE 1516.2
specification. These include:
1. All names have the initial letter of each word capitalized.
2. All enumeration names end in the text "Enum" followed by a number. The number indicates the number of bits in
the enumerated value.
3. All complex data type names end in the text "Struct".
6.1.3 Levels of Fidelity

The HLA levels of fidelity are directly equivalent to the corresponding DIS levels of fidelity as defined in section 5.1.2.
6.1.4 Time Synchronization

The HLA time synchronization mechanism is directly equivalent to the corresponding mechanism for DIS as defined in
section 5.1.
6.1.5 Protocol Implementation Details
This section defines how Link 16 BOM compliant federates are to implement the Link 16 protocol. The HLA protocol
implementation details are directly equivalent to the corresponding details for DIS as defined in section 5.2.
6.1.6 Object Class Data

The Link 16 BOM defines no new object classes. Instead the BOM defines a single complex data type
(JTIDSTransmitterStruct) that corresponds to the modulation parameters in the DIS Transmitter PDU defined in
section 5.2.1. An attribute of this complex data type should be added to the object class in the parent FOM corresponding
to the DIS Transmitter PDU. Modulation parameters of the Transmitter PDU shown in section 5.1, Table 3, map to the
fields of the JTIDSTransmitterStruct complex data type attribute, shown in Annex A.5. Parent object class fields
are also modified such that they refer to the corresponding Transmitter PDU fields.
NOTE: For a RPR FOM implementation, an attribute of the JTIDSTransmitterStruct complex data type should be
added to the RadioTransmitter object class.
6.1.7 Interaction Class Data

The Link 16 BOM adds a family of interactions that will support future TDL implementation of other datalinks. The
family of interactions is a hierarchy in which the BOM’s base class for this interaction is a generic class - the
TDLBinaryRadioSignal interaction. This class is an empty class, contains no parameters, and is neither publishable
nor subscribable. The specific parameters are properties of the various subclasses of this generic base class, and it is these
subclasses that are published and subscribed to.
The Link16RadioSignal interaction, shown in Annex A.3, which is a subclass of the TDLBinaryRadioSignal
interaction, contains the JTIDS Network Header Parameters as shown in table 5. The JTIDSMessageRadioSignal
interaction contains the Link 16 message data. Additional interactions shown in Annex A.3 define the other types of Link
16 messages. Parent object class fields are also modified such that they refer to the corresponding Signal PDU fields.
The Link 16 BOM design is such that the TDLBinaryRadioSignal interaction becomes a subclass of the parent
FOM's equivalent of the DIS Signal PDU.Modulation parameters of the Signal PDU map to the fields of the
JTIDSTransmitterStruct complex data type attribute (see section 5.4). Parent object class fields are also modified
such that they refer to the corresponding Signal PDU fields.
NOTE: For a RPR FOM implementation, the TDLBinaryRadioSignal class becomes a subclass of the RPR FOM
RawBinaryRadioSignal interaction class; this is done in order to allow access to the HostRadioIndex parameter
in the RawBinaryRadioSignal interaction class. The HostRadioIndex parameter ties the Link 16 message to a
specific Host and Radio Transmitter.
6.1.8 BOM Implementation

The BOM implementation, in OMT 1.3 format, is described in annex A. For RPR FOM 1.0 (Reference 5),
SpreadSpectrumStruct complex data type and TDLBinaryRadioSignal should be added to the Radio
Transmitter Object Class. For RPR FOM 2.0 (Reference 6), the SpreadSpectrumStruct complex data type already
exits. Therefore, the field TDLBinaryRadioSignal shall be added to the SpreadSpectrumStruct complex data
type, as shown in Annex A.5.
An attribute (JTIDSTransmitterData) of complex data type JTIDSTransmitterStruct is added to the RPR
FOM Radio Transmitter object class. The Link16RadioSignal interaction class is added as a subclass of a new
interaction class, the TDLBinaryRadioSignal interaction, which itself is a subclass of the RPR FOM's
RawBinaryRadioSignal interaction class.

Table 6: Link 16 BOM Interactions in the RPR-FOM

RadioSignal ApplicationSpecifcRadioSignal
DatabaseIndexRadioSignal
EncodedAudioRadioSignal
RawBinaryRadioSignal TDLBinaryRadioSignal Link16RadioSignal JTIDSMessageRadioSignal
RTTABRadioSignal
RTTReplyRadioSignal
JTIDSVoiceCVSDRadioSignal
JTIDSVoiceLPC10RadioSignal
JTIDSVoiceLPC12RadioSignal
JTIDSLETRadioSignal
VMFRadioSignal

NOTES:
1. The addition of the TDLBinaryRadioSignal interaction class and its associated subclasses was necessary
because of the RPR FOM implementation limitations of the DIS Signal PDU. Section 5.2.2 defines the DIS Signal PDU
used for all Link 16 messages in a Raw Binary Signal PDU. The RPR FOM equivalent of this PDU type (the
RawBinaryRadioSignal interaction class) contains a parameter, called SignalData, containing one or more
octets containing the signal data. If the SignalData octet based storage scheme to store Link 16 messages was used the
Link 16 message would be lost during byte swapping. The implementation is defined such that the Link 16 interaction
becomes a subclass of the RawBinaryRadioSignal interaction to ensure the SignalData storage is not used. Data
integrity is achieved by moving the Link 16 message storage into the lowest level classes (i.e the
JTIDSMessageRadioSignal ).
2. DIS to HLA gateways will require modification, but the modifications are well defined. DIS Raw Binary Signal
PDUs need to be split into a RawBinaryRadioSignal interaction or the appropriate Link 16 interaction class,
depending on the TDL type. Conversely, a HLA to DIS gateway must merge both interaction types into a single DIS
Signal PDU.
ANNEX A: LINK 16 BASE OBJECT MODEL (BOM) OMT 1.3 TABLES

A.1 OBJECT MODEL IDENTIFICATION TABLE

Category Information
Name Link 16 BOM
Version v1.0 Draft 2
Date 9/9/2002
Purpose Link 16 Base Object Model (BOM)
Application Domain C4ISR & C2 platform simulations
Sponsor SISO
POC (Title, First, Last) Mr Graham C Shanks
POC Organization AMS
POC Telephone +44 1383 828062
POC Email [email protected]

A.2 OBJECT INTERACTION TABLE

Interaction1 Interaction2 Interaction3 Interaction4

Parent (N) TDLBinaryRadioSignal Link16RadioSignal (R) JTIDSMessageRadioSignal (IR)
(N) RTTABRadioSignal (IR)
RTTReplyRadioSignal (IR)
JTIDSVoiceCVSDRadioSignal (IR)
JTIDSVoiceLPC10RadioSignal (IR)
JTIDSVoiceLPC12RadioSignal (IR)
JTIDSLETradioSignal (IR)
VMFRadioSignal (IR)
 DRAFT
SISO-STD-002-V2.9.6
7 March 2005

A.3 PARAMETER TABLE

Cardinalit Accuracy Routing

Interaction Parameter Datatype Units Resolution Accuracy
y Condition Space
JTIDSLETradioSignal LETHeader LETHeaderStruct 1 N/A N/A N/A N/A N/A
TADILJMessage TADILJWordStruct 1+ N/A N/A N/A N/A
JTIDSMessageRadioSignal JTIDSHeader JTIDSHeaderStruct 1 N/A N/A N/A N/A N/A
TADILJMessage TADILJWordStruct 1+ N/A N/A N/A N/A
JTIDSVoiceCVSDRadioSignal JTIDSHeader JTIDSHeaderStruct 1 N/A N/A N/A N/A N/A
Data octet 29+ N/A N/A perfect always
JTIDSVoiceLPC10RadioSignal JTIDSHeader JTIDSHeaderStruct 1 N/A N/A N/A N/A N/A
Data octet 29+ N/A N/A perfect always
JTIDSVoiceLPC12RadioSignal JTIDSHeader JTIDSHeaderStruct 1 N/A N/A N/A N/A N/A
Data octet 29+ N/A N/A perfect always
Link16RadioSignal NPGNumber unsigned short 1 N/A N/A perfect always N/A
NetNumber octet 1 N/A N/A perfect always
TSEC_CVLL octet 1 N/A N/A perfect always
MSEC_CVLL octet 1 N/A N/A perfect always
TimeSlotID [3] unsigned long 1 N/A N/A perfect always
PerceivedTransmitTime [2] long long 1 N/A N/A perfect always
RTTABRadioSignal RTTAB RTTABStruct 1 N/A N/A N/A N/A N/A
RTTReplySignal RTTReply RTTReplyStruct 1 N/A N/A N/A N/A N/A
VMFRadioSignal JTIDSHeader JTIDSHeaderStruct 1 N/A N/A N/A N/A N/A
TADILJMessage TADILJWordStruct 1+ N/A N/A N/A N/A

A-19
Copyright (c) 2005 SISO Inc. All rights reserved.
This is an unapproved SISO draft document, subject to change.
 A.4 ENUMERATED DATATYPES TABLE

Identifier Enumerator Representation

JTIDSPrimaryModeEnum8 [1] NTR 1
JTIDSUnitParticipant 2
JTIDSSecondaryModeEnum8 [1] None 0
NetPositionReference 1
PrimaryNavigationController 2
SecondaryNavigationController 3
JTIDSSynchronizationStateEnum8 [1] CourseSynchronization 2
FineSynchronization 3
TSALevelEnum8 [1] LowFidelityLevel0 0
LowFidelityLevel1 1
MediumFidelityLevel2 2
MediumFidelityLevel3 3
HighFidelityLevel4 4

A.5 COMPLEX DATATYPES TABLE

Accuracy
Complex Datatype Field Name Datatype Cardinality Units Resolution Accuracy
Condition
JTIDSHeaderStruct Data octet 6 N/A N/A perfect always
JTIDSTransmitterStruct TimeSlotAlocationMode TSALevelEnum8 1 N/A N/A N/A N/A
N/A
TransmittingTerminalPrimaryMode JTIDSPrimaryModeEnum8 1 N/A N/A N/A
TransmittingTerminalSecondaryMode JTIDSSecondaryModeEnum8 1 N/A N/A N/A N/A
SynchronizationState JTIDSSynchronizationStateEnum8 1 N/A N/A N/A N/A
NetworkSynchronizationID unsigned long 1 N/A N/A perfect always
LETHeaderStruct [4] Data octet 6 N/A N/A perfect always
RTTABStruct [5] Data octet 6 N/A N/A perfect always
RTTReplyStruct [6] Data octet 6 N/A N/A perfect always
TADILJWordStruct [7] Data octet 10 N/A N/A perfect always
SpreadSpectrumStruct TDLBinaryRadioSignalFlag octet 1 N/A N/A perfect always

A-20
Copyright (c) 2005 SISO Inc. All rights reserved.
This is an unapproved SISO draft document, subject to change.
 A.6 NOTES TABLE

ID Text
1 This is an 8-bit enumeration
NTP timestamp format-- NTP timestamps are represented as a 64-bit unsigned fixed-point number, in
seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the
2
last 32 bits. The precision of this representation is about 200 picoseconds, which should be adequate for even
the most exotic requirements. See RFC1305 for detailed format. All F's in this field shall indicate a no
statement/wildcard
3 See TimeSlot ID structure in Table 5.2.4
4 See LET Message Header structure in Table 5.2.11
5 See RTT A/B Message structure in Table 5.2.6
6 See RTT Reply Message structure in Table 5.2.7
7 See TADIL J Message Bit Orientation in Table 5.2.3

Page 21 of 21