SISO Tactical Datalink TDL Study GroupSG

1
SISO Tactical Datalink (TDL) Study Group(SG)

• Euro SIW SG Meeting 25 Jun 1315 1700

2
TDL SG Meeting Introductions

• Adin Burroughs
• TDL SG Chair
• Joe Sorroche
• TDL SG Vice Chair
• Dr. Rob Byers
• TDL Secretary

3
Agenda

• 1315 1330 Meeting introduction and Study
  Group background (Adin Burroughs)
• 1330 1345 Review and status update of open
  action items (Dr. Robert Byers)
• 1345 1500 Review of current draft proposal
  (Adin Burroughs, Joe Sorroche)
• -Transmitter PDU Structure
• -Signal PDU Structure
• -Synchronization Methodologies
• -Low to High Fidelity Interoperability
• 1500 1530 Tea

4
Agenda(Continued)

• 1530 1630 Open Q/A session on methodologies
  used in Draft Standard (Adin Burroughs)
• 1630 1645 Path of proposed DIS standard into
  HLA (Graham Shanks)
• 1645 1700 Assignment of action items, review
  of results of present meeting, determination
  of next meeting time and place (Adin
  Burroughs)
• 1700 ?? Continued informal technical
  discussions (over a pint??)

5
TDL SG IntroductionRules of Engagement

• Non-confrontational atmosphereall are here to
  get the job done and create a product!
• Questions/Comments are always welcomed
• -Ask questions at any time
• -Will tracked on SG AI Comment Worksheet
• Comments/Action Items reviewed at the end of each
  presentation and the end of the day

6
TDL SG KnowledgeAssumptions

• Working knowledge of JTIDS
• MIL-STD 6016A/B
• Working knowledge of TADIL-J/Datalinks
• Working knowledge of DIS
• IEEE 1278.1
• Working Knowledge of radio frequencies/propagation
  
• Working knowledge of simulators
• Working knowledge of C2

7
TDL SG Introduction Goals

• Create a standard that can be used to exchange
  datalink data!
• Submit proposals for changes to DIS EBV Document
• Formatting of data inside PDUs
• Usage of PDUs
• TDL Enumerations
• Provide HLA guidelines for FOM/SOM implementations

8
TDL SG Approach

• Draft changes to the DIS EBV document
• Submit as package of changes after SG approval
• Goal is Jan 03 Submittal to EBV document
• Avoid any changes to the IEEE Specifications, if
  at all possible
• Identify HLA methods and approaches from work in
  DIS

9
TDL SG On-Line Resources

• AFAMS Hosted Discussion Server Document
  Repository
• http//www.afams.af.mil
• Click on programs and exercises, listed on this
  page
• Discussion Server still in beta form
• SISO Reflector
• http//www.sisostds.org
• DMSO Reflector
• Currently not in use, has archives for Nov-Jan 01

10
TDL SG Terms of Reference

• TDL SG TOR

11
TDL SGSG History

• Jul 01- Began as TACCSF internal project to
  review current DIS Link-16 Implementation
• Oct 01 - Formed grass roots working group after
  community response to informal inquiries
• Nov 01- Meeting at I/ITSEC
• Initial Presentation of ideas, technical
  discussion
• Decided to pursue becoming official SISO Study
  Group
• Dec 01 - SISO EXCOM Approves TOR
• Feb 02 - SG Reflector, AFAMS webpage established
• Mar 02 - First official meeting of TDL SG

12
TDL SG _at_ Spring 02 SIW

• Monday Morning SAC Briefing
• Tuesday Night AF Night Briefing
• Wednesday All day Meeting, Flamingo Room
• Synchronization
• Transmitter PDU
• Improvements to methodologies from I/ITSEC
  meeting
• Once methodologies are agreed upon, move towards
  words for DIS EBV
• HLA inclusion RPR FOM and more
• Thursday SISC Briefing

13
TDL SG _at_ Interim Meeting(4 Jun 02)

• Covered
• A.I. 30 JTIDS Communications Modes 1, 2,4
• A.I. 31 Bandwidth restrictions for Low Fidelity
  Participants
• A.I. 11 Perceived Transmit Time
• A.I. 14 DIS timestamp as unique synchronization
  key
• A.I. 21 VMF/LET Signal PDU Structure
• A.I. 17 Timeslot Identification
• A.I. 23 DIS Voice Signal PDU Structure
• A.I. 15 FORSCOM/SPO/JITC Review
• Significant discussion on timeslot ID structure
  and JTIDS voice implementation (Minutes of SISO
  TDL SG meeting)

14
Challenges with Current Standard

• Standard lacks detail for interoperability
• Multiple implementations in the wild
• Ability to exchange TADIL-J messages, no ability
  to simulate JTIDS networks
• No standard enumeration list for TDL types

15
Goals for New Standard

• Standard, interoperable implementation
• Easy initial implementation
• Minimal impact on current users
• Ability to ease transition from old formats to
  new
• Effects level simulation of JTIDS net
• Ability to route datalink data separately from
  truth data
• Minimize bandwidth utilization
• Discrete definitions of fidelity
• Identify FOM/SOM data items for HLA JTIDS
  emulation

16
Goals for New StandardEffects to be simulated

• Timeslot allocation/metering of data with nominal
  values or from an actual NDL
• Segmenting of data into NPGs
• Segmenting of data into Nets
• Multi-netting
• Crypto-netting
• Net entry procedures
• Synchronization
• Multiple NTRs

17
Goals for New StandardEffects to be simulated

• Relnav
• Multiple JTIDS units transmitting at same time
• Waveform/RF simulation
• Antenna, propagation details

18
Goals for New StandardEffects not covered

• Individual Pulses
• Effects of conflicting pulses if hopping patterns
  coincide

19
Action Item update

• AI Comment Tracker

20
JTIDS/Link-16 Synchronization Tutuorial

• Presented by Mr. Joe Sorroche

21
Link-16 Synchronization

• System Timing and Synchronization
• TDMA Architecture requires that each participant
  know when its transmit timeslots occur
• JUs must be syncd with a common network time to
  receive and transmit on the network
• Network Time Reference (NTR)
• Any JU can be a NTR
• Relative Time
• The clock of one participant is designated as the
  Net Time Reference
• External Time Reference (ETR)
• GPS
• Other JUs are either primary or secondary users
• Primary users use the active mode for fine sync
• Secondary users use the passive mode for fine sync

22
Link-16 Synchronization

• Four steps for Synchronization
• Initial Net Entry
• Coarse Synchronization
• Fine Synchronization
• Synchronization Maintenance

23
Link-16 Synchronization

• Initial Net Entry
• Prior to entering the net, a terminal will not
  know the current time slot number
• It will know time accurately enough to know that
  a future time slot has not yet occurred
• Initial Entry Time slot blocks occur every 12
  seconds, starting with the initial slot in the
  frame.
• The NTR always transmits a J0.0 Initial Entry
  Message in these time slots.
• Initial Net Entry occurs on receipt of a valid
  net entry message

24
Initial Entry Time Slots
Initial Time Slot in Epoch
.
.
.
.
12 Seconds 1536 Time Slots
12 Seconds 1536 Time Slots
12 Seconds 1536 Time Slots
25
Coarse Synchronization

• Coarse Synchronization
• Achieved by receiving error-free Initial Entry
  Message
• JU must adjust its clock to identify time slots
• JU cannot transmit until Fine Synchronization is
  achieved
• Exception Round Trip Timing (RTT) Interrogation
  Messages

26
Fine Synchronization

• Fine Synchronization
• When Coarse Sync is achieved, a JU automatically
  begins the fine Sync process
• Actively
• Passively
• Active Mode
• Uses RTT based on RTT Interrogation and Reply
  Messages
• Interrogating JU transmits a RTT Interrogation
  message
• Time of Arrival (TOA) is determined
• Interrogating JU determines clock correction
  based on TOA

27
RTT Interrogation Message
28
RTT Interrogation Message
TOA I Time-of-Arrival of the RTT Interrogation
Message as determined by the responding
terminal. TOA R Time-of-Arrival of the RTT
Reply Message as determined by the interrogating
terminal. t d 4275 µsec, the known reply time
in the time slot t p Propagation time of the
RTT messages E Initial clock offset between the
two terminals, it is the error to be corrected by
the synchronizing terminal.
t p TOA I - E (RTT Interrogation) t p TOA R
E - Td (RTT Reply) E TOA I - TOA R t d
2
29
RTT A Interrogation Message

• Addressed Round Trip Timing message
• addressed to a specific terminal on list which
  has the highest time quality
• assigned as dedicated access time slots
• about 1 time slot per 12 seconds
• Only the terminal that has been addressed will
  reply
• if no specific RTT-A assignment is made, the
  terminal will automatically steal a dedicated
  access PPLI time slot for RTT-A

30
RTT B Interrogation Message

• Broadcast Round Trip Timing message
• messages are broadcast (not addressed to any
  specific terminal)
• Contains the interrogators Quality time, Qt
• Any terminal with a higher Qt can reply
• assigned as contention pool using nets 1 - 15
• Interrogating terminal sends RTTs on the net
  number equal to the highest Qt in its table of
  sources
• Each terminal listens for RTTs in RTT-B NPG on
  the net number equal to its own Qt and replies on
  that net number

31
Passive Mode

• Passive Mode
• Requires no transmissions (e.g., radio silent)
• Must be receiving PPLI messages directly (not
  relayed)
• Must know own position
• own position can be self-supplied (e.g., F-15
  INS)
• own position can be calculated using JTIDS
  navigation
• When Fine Sync is achieved, a JU begins
  transmitting and receiving messages
• Synchronization Maintenance
• JUs monitor clock performance
• Perform Fine Sync process, either active or
  passive
• If clock errors exceed defined limits, a JU stops
  message transmission and re-initiates fine Sync
  process
• JU does not stop RTT interrogation messages

32
DIS-J Synchronization
33
DIS-J High Fidelity Synchronization
ProceduresStep 1

• An NTR shall begin by issuing Transmitter
  PDU/Signal PDU Net Entry message pairs at a rate
  in accordance with the JTIDS terminal
  specification (In timeslot A-0-6 at a rate of
  every 12 seconds).
• A unique randomly generated key shall be filled
  into the synchronization key field of the
  transmitter PDU. The primary JTIDS duty field
  shall contain a NTR enumeration.

34
DIS-J High Fidelity Synchronization Step 1
J0.0 Net Entry Msg Every 12 Secs

• Transmitter PDU
• Synch Key 001
• Transmit Time 1200
• Primary Duty NTR

• Signal PDU
• Filled with J0.0
• Contains timeslot information

35
DIS-J High Fidelity Synchronization Step 2

• The receiving JTIDS Unit Terminal (JU) then
  updates its own terminal time by taking the
  terminal perceived time, and adding the amount of
  time for the message to traverse the distance
  between the two entities.
• It also shall fill its own synchronization key
  in the with the synchronization key received from
  the NTR.
• This key shall be used in all transmitter PDUs as
  long as the JU remains in synchronization with
  the same NTR
• The JU is now considered to be in coarse
  synchronization.

36
DIS-J High Fidelity Synchronization Step 2

• After Signal Reception checking, JU Internal DB
  updated with
• Updated Terminal TimePerceived Receive Time
• Synch Key001
• StateCoarse Synch
• Timeslots from received J0.0

37
DIS-J High Fidelity Synchronization Step 3

• The JU then transmits the appropriate Signal PDU
  RTT message (A or B) and Transmitter PDU pairs.
• The JU will use its own terminal perceived time
  in the transmitter PDU.

38
DIS-J High Fidelity Synchronization Step 3

• JU Transmits (in assigned timeslot)
• Transmitter PDU
• Synch Key 001
• Updated Terminal Perceived Time (1203)
• State Coarse Synch
• Primary Duty JU
• Signal PDU
• Contains RTT A/B

39
DIS-J High Fidelity Synchronization Step 4

• 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/transmitter PDU pair is then transmitted.
• If method is RTT-A, the addressed JU shall answer
• If method is RTT-B, All participants with a
  higher TQ shall answer
• Detailed procedures are contained in JTIDS Class
  2 Terminal Specification

40
DIS-J High Fidelity Synchronization Step 4
NTR Answers within SAME timeslot

• Transmitter PDU
• Synch Key 001
• Transmit Time 1204
• Primary Duty NTR

• Signal PDU
• Filled with RXed RTT A/B

JU updates own terminal time with received
terminal time
41
DIS-J High Fidelity Synchronization Step 4

• The JU shall then update its own terminal time
  with the received round trip time.
• After the appropriate number or RTT exchanges
  have occurred (depending whether the RTT-A or
  RTT-B method of synchronization was used), 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
• Transmitter PDUs shall be issued when
• TX any J0.x, RTT A/B (re-synchronization), PPLI
  (J2.X)

42
DIS-J Low FidelitySynchronization

• Steps 1 2 shall be the same as the High
  Fidelity Synchronization, except for
• The transmitted J0.0 message shall be filled with
  dummy timeslot information
• After reception of the J0.0 net entry message,
  the JU shall skip straight to the fine
  synchronization state.
• Steps 3 4 (RTT Synchronization) shall not be
  accomplished
• Transmitter PDUs shall then be transmitted when
• TX any J0.x,PPLI (J2.X, nominally once/12 secs)

43
DIS-J Mixed Fidelity Synchronization

• High Fidelity NTR, Low fidelity JU
• Each shall participate at their native modes
• NTR shall transmit J0.0 signal transmitter PDU
  pairs
• Receiving Low Fidelity JU shall
• Accept J0.0 data, transmission information
• Discard timeslot information
• Skip RTT synchronization and report
  synchronization state as fine synchronization
• ALL HIGH FIDELITY PARTICIPANTS WILL OPERATE AT
  NORMAL HIGH FIDELITY MODE

44
DIS-J Mixed Fidelity Synchronization

• Low Fidelity NTR, High Fidelity Participants
• Each shall participate at their native modes
• Low fidelity NTR will transmit J0.0 with zeroed
  timeslot information or user entered timeslot
  information with a correct transmitter PDU
• High Fidelity JU shall either
• Use NDL assigned timeslots or (if the mission
  requires) received timeslot information.
• RTT-As or RTT-Bs can be exchanged with other high
  fidelity participants already in fine
  synchronization.
• If there are no other high fidelity participants
  in fine synchronization to exchange RTTs with,
  the JU will skip straight to Fine Synchronization
  

45
DIS-J Synchronization Additional Notes

• To be in compliance with standard, if the
  real-world system can act as NTR, the simulator
  must be able to act at least as 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 synchronization key to zero and
  transmit the synchronization state of fine
  synchronization.
• Re-synchronization procedures must be
  re-accomplished if a unit falls out of the link
  
• 60 seconds without reception of PPLI.

46
DIS-J Synchronization Additional Notes (contd)

• If a synchronization key does not match a JUs own
  synchronization key, the data will not be
  considered to have been received. All Fs in the
  synchronization key field shall be accepted as a
  wildcard matching any network synchronization.
• Simulated terminals shall accept net entry
  messages (J0.0) from any simulated transmitting
  terminal within reception range. If a new NTR
  with a different synch key is closer than the
  original NTR, resynchronization with the new NTR
  shall occur. This may lead to re-synch battles
  and take down the net
• If crypto information is being used in the signal
  PDUs, then the crypto information must match
  before another J0.0 is accepted.
• Simulators in compliance with this standard shall
  at a minimum have the capability to identify the
  NPG and net number of transmitted data in the
  signal PDU

47
Review and Discussion of Signal and Transmitter
PDU Issues
48
SISO TDL SG

• Presentation of Draft Proposal to Study Group
• Transmitter PDU Structure
• Signal PDU Structure
• DIS-J Description

49
Open Q/A session on methodology used in Draft
Standard Proposal
50
Misc Items

• Current TACCSF Efforts for implementation
• JSB Initiative
• Review of TDL Enumerations
• TDL Type Enumerations
• HLA/RPR FOM Sub-Group?
• Group to draft official proposal for change to
  DIS EBV for Fall SIW Review approval?
• Next Year TOR for TDL Study Group?
• HLA re-write and DIS version of Link-11A or 22?

51
Path of proposed DIS standard into HLA(Graham
Shanks)
52
Wrap-Up

• Action Item Review
• Time Date for next meeting (if necessary)