PARAGRAPH PAGE
C.1 GENERAL. 278C.1.1 Scope. 278C.1.2 Applicability. 278C.2 APPLICABLE DOCUMENTS. 278C.2.1 General. 278C.2.2 Government documents. 279C.2.2.1 Specifications, standards, and handbooks. 279C.2.2.2 Other Government documents, drawings, and publications. 279C.2.3 Non-Government publications. 279C.2.4 Order of precedence. 280C.3 DEFINITIONS. 280C.3.1 Standard definitions and acronyms. 280C.3.2 Abbreviations and acronyms. 280C.3.3 Operating parameters. 281C.4 GENERAL REQUIREMENTS. 282C.4.1 Overview. 282C.4.2 Frequency management. 283C.4.2.1 Calling and traffic channels. 283C.4.2.2 Reserved channel number. 283C.4.2.3 External frequency management. 283C.4.3 Network synchronization. 283C.4.3.1 External synchronization. 284C.4.3.2 Over-the-air synchronization. 284C.4.4 Scanning. 284C.4.4.1 Synchronous mode. 284C.4.4.2 Asynchronous mode. 284C.4.5 3G addresses. 284C.4.5.1 Synchronous mode address structure. 285C.4.5.2 Net entry addresses. 285C.4.5.3 Multicast addresses. 285C.4.5.4 Node address assignments. 285C.4.5.5 Multicast address assignments. 285C.4.6 ALE. 285C.4.6.1 System performance requirements. 286C.4.6.1.1 Linking probability. 286C.4.6.1.1.1 Linking probability for synchronous operation. 287C.4.6.1.1.2 Linking probability for asynchronous operation. 287C.4.6.1.2 Occupancy detection. 287C.4.6.1.2.1 Occupancy detection for synchronous operation. 287C.4.6.1.2.2 Occupancy detection for asynchronous operation. 287C.4.6.2 Calling channel selection. 288TABLE OF CONTENTS(continued)PARAGRAPH PAGEC.4.6.3 Interoperability with 2G systems. 288C.4.6.4 MIL-STD-188-148A functionality. 288C.4.7 Data link protocol. 288C.4.8 Automatic link maintenance. 289C.4.9 Network management interface. 289C.4.10 Order of transmission. 289C.4.11 3G ALE data structures. 289C.4.11.1 Station self address. 289C.4.11.2 Station table. 289C.4.11.3 Channel table. 290C.4.12 Cyclic Redundancy Check (CRC) computation procedure. 290C.5 DETAILED REQUIREMENTS. 291C.5.1 Constituent waveforms. 291C.5.1.1 Service primitives. 292C.5.1.2 Burst waveform interleaving. 295C.5.1.3 Burst Waveform 0 (BW0). 297C.5.1.3.1 TLC/AGC guard sequence. 298C.5.1.3.2 Acquisition preamble. 298C.5.1.3.3 Forward error correction. 299C.5.1.3.4 Interleaving. 300C.5.1.3.5 Orthogonal symbol formation. 301C.5.1.3.6 PN spreading sequence generation and application. 302C.5.1.3.7 Modulation. 302C.5.1.4 Burst Waveform 1 (BW1). 303C.5.1.4.1 TLC/AGC guard sequence. 304C.5.1.4.2 Acquisition preamble. 304C.5.1.4.3 Forward error correction. 305C.5.1.4.4 Interleaving. 306C.5.1.4.5 Orthogonal symbol formation. 307C.5.1.4.6 PN spreading sequence generation and application. 307C.5.1.4.7 Modulation. 308C.5.1.5 Burst Waveform 2 (BW2). 308C.5.1.5.1 TLC/AGC guard sequence. 311C.5.1.5.2 Acquisition preamble. 311C.5.1.5.3 CRC computation. 311C.5.1.5.4 Data packet extension. 311C.5.1.5.5 Forward error correction. 312C.5.1.5.6 Modulation Symbol formation. 313C.5.1.5.7 Frame formation. 314C.5.1.5.8 PN spreading sequence generation and application. 314C.5.1.5.9 Modulation. 315C.5.1.6 Burst Waveform 3 (BW3). 316TABLE OF CONTENTS(continued)PARAGRAPH PAGEC.5.1.6.1 Preamble. 317C.5.1.6.2 CRC computation. 317C.5.1.6.3 Forward error correction. 318C.5.1.6.4 Interleaving. 319C.5.1.6.5 Orthogonal symbol formation. 319C.5.1.6.6. PN spreading sequence generation and application. 319C.5.1.6.7 Modulation. 320C.5.1.7 Burst Waveform 4 (BW4). 320C.5.1.7.1 TLC/AGC guard sequence. 321C.5.1.7.2 Orthogonal symbol formation. 321C.5.1.7.3 PN spreading sequence generation and application. 322C.5.1.7.4 Modulation. 323C.5.1.8 Burst waveform modulation. 323C.5.2 3G-ALE protocol definition. 324C.5.2.1 3G-ALE service primitives. 324C.5.2.2 3G-ALE PDUs. 326C.5.2.2.1 LE_Call PDU. 327C.5.2.2.2 LE_Handshake PDU. 328C.5.2.2.3 LE_Notification PDU. 329C.5.2.2.4 LE_Broadcast PDU. 330C.5.2.2.5 Scanning call PDU. 330C.5.2.2.6 CRC computation for 3G-ALE PDUs. 330C.5.2.3 Synchronous dwell structure. 330C.5.2.4 3G-ALE protocol behavior. 331C.5.2.4.1 3G-ALE protocol data. 331C.5.2.4.2 3G-ALE protocol events. 332C.5.2.4.3 3G-ALE protocol actions. 333C.5.2.4.4 3G-ALE synchronous mode protocol. 335C.5.2.4.4.1 3G-ALE synchronous mode slot selection. 335C.5.2.4.4.2 3G-ALE synchronous mode individual calling overview. 336C.5.2.4.4.3 3G-ALE synchronous mode unicast calling. 336C.5.2.4.4.4 3G-ALE synchronous mode multicast calling. 337C.5.2.4.4.5 3G-ALE synchronous mode broadcast calling - not tested (NT) 337C.5.2.4.4.6 3G-ALE synchronous mode link release. 338C.5.2.4.4.7 3G-ALE synchronous mode protocol behavior. 338C.5.2.4.4.8 3G-ALE synchronous mode protocol examples. 343C.5.2.4.4.9 3G-ALE synchronous mode timing characteristics. 343C.5.2.4.5 3G-ALE asynchronous mode protocol. 345C.5.2.4.5.1 3G-ALE asynchronous mode listen before transmit. 345C.5.2.4.5.2 3G-ALE asynchronous mode scanning call. 345C.5.2.4.5.3 3G-ALE asynchronous mode handshake. 346C.5.2.4.5.4 3G-ALE asynchronous mode unicast call. 346TABLE OF CONTENTS(continued)PARAGRAPH PAGEC.5.2.4.5.5 3G-ALE asynchronous mode multicast call. 346C.5.2.4.5.6 3G-ALE asynchronous mode broadcast call. 347C.5.2.4.5.7 3G-ALE asynchronous mode link release. 347C.5.2.4.5.8 3G-ALE asynchronous mode entry to synchronous networks. 348C.5.2.4.5.9 3G-ALE asynchronous mode protocol behavior. 348C.5.2.4.5.10 3G-ALE asynchronous mode protocol example. 352C.5.2.4.5.11 3G-ALE asynchronous mode timing characteristics. 352C.5.2.5 Notification protocol behavior. 353C.5.2.5.1 Station status notification. 353C.5.2.5.2 Sounding. 353C.5.2.5.3 Synchronous mode notifications. 354C.5.2.5.4 Asynchronous mode notifications. 354C.5.2.6 Calling into a 3G network. 354C.5.2.6.1 Net entry addresses. 354C.5.2.6.2 Link establishment for net entry. 354C.5.2.6.3 Acquisition of operating data. 355C.5.2.7 Synchronization management protocol (not tested). 355C.5.2.7.1 Synchronization data. 355C.5.2.7.2 Time quality. 356C.5.2.7.3 Synchronization management PDUs. 356C.5.2.7.3.1 Group time broadcast PDU. 357C.5.2.7.3.2 Sync check PDU. 357C.5.2.7.3.3 Sync offset PDU. 357C.5.2.7.4 Sync check handshake. 358C.5.2.7.5 Synchronization maintenance. 358C.5.2.7.6 Synchronization for late net entry. 359C.5.2.7.7 Initial time distribution. 359C.5.3 TM protocol. 361C.5.3.1 Overview. 361C.5.3.2 Data object types. 362C.5.3.3 Service primitives. 363C.5.3.4 PDUs. 367C.5.3.5 Protocol behavior. 370C.5.3.5.1 Events. 370C.5.3.5.2 Actions. 373C.5.3.5.3 Data. 377C.5.3.5.4 Behavior definition. 378C.5.3.5.5 Timing characteristics. 391C.5.3.5.5.1 Point-to-point packet link. 394C.5.3.5.5.2 Point-to-point circuit links. 403C.5.3.5.5.3 Multicast circuit link. 405C.5.4 HDL protocol. 408TABLE OF CONTENTS(continued)PARAGRAPH PAGEC.5.4.1 Overview. 408C.5.4.2 Data object types. 408C.5.4.3 Service primitives. 409C.5.4.4 PDUs. 409C.5.4.4.1 HDL_DATA. 409C.5.4.4.2 HDL_ACK. 411C.5.4.4.3 HDL_EOM. 412C.5.4.5 Protocol behavior. 413C.5.4.5.1 Events. 414C.5.4.5.2 Actions. 415C.5.4.5.3 Data. 415C.5.4.5.4 Behavior definition. 419C.5.4.5.5 Timing characteristics. 420C.5.5 LDL protocol . 420C.5.5.1 Overview. 420C.5.5.2 Data object types. 421C.5.5.3 Service primitives. 421C.5.5.4 PDUs. 423C.5.5.4.1 LDL_DATA. 423C.5.5.4.2 LDL_ACK. 424C.5.5.4.3 LDL_EOM. 424C.5.5.5 Protocol behavior. 425C.5.5.5.1 Events. 427C.5.5.5.2 Actions. 427C.5.5.5.3 Data. 429C.5.5.5.4 Behavior definition. 429C.5.5.5.5 Timing characteristics. 432C.5.6 CLC. 432C.5.6.1 Overview. 432C.5.6.2 Service primitives. 433C.5.6.3 PDUs. 435C.5.6.4 Protocol behavior. 435C.5.6.4.1 Events. 435C.5.6.4.2 Actions. 435C.5.6.4.3 Data. 437C.5.6.4.4 Behavior definition. 439C.5.7 Examples. 441
TABLE C-I. Linking probability requirements (3 kiloHertz (kHz) signal to noise ratio (SNR) decibels (dB)). 286TABLE C-II. Synchronous-mode occupancy detection requirements (3 kHz SNR dB). 288TABLE OF CONTENTS(continued)PARAGRAPH PAGETABLE C-III. Burst waveform characteristics. 292TABLE C-IV. Burst Waveform (BWn) service primitives. 293TABLE C-V. TLC/AGC guard sequence symbol values. 298TABLE C-VI. BW0 acquisition preamble symbol values. 299TABLE C-VII. BW0 interleaver paramenters. 301TABLE C-VIII. Walsh modulation of coded bits to tribit sequences. 301TABLE C-IX. BW0 PN spreading sequence. 302TABLE C-X. TLC/AGC guard sequence symbol values. 304TABLE C-XI. BW1 acquisition preamble symbol values. 305TABLE C-XII. Interleaver parameters for BW1. 307TABLE C-XIII. BW1 PN spreading sequence. 307TABLE C-XIV. Gray coding table. 314TABLE C-XV. Interleaver parameters for BW3. 319TABLE C-XVI. BW3 PN spreading sequence. 319TABLE C-XVII. Walsh modulation of BW4 payload bits to tribit sequences. 322TABLE C-XVIII. BW4 PN spreading sequence. 322TABLE C-XIX. 8-ary PSK signal space. 323TABLE C-XX. 3G-ALE service primitives. 325TABLE C-XXI. Call type field encodings. 328TABLE C-XXII. Command field encodings. 329TABLE C-XXIII. Reason field encodings. 329TABLE C-XXIV. Caller status field encodings. 330TABLE C-XXV. 3G-ALE protocol data. 332TABLE C-XXVI. 3G-ALE protocol events. 333TABLE C-XXVII. 3G-ALE protocol actions. 334TABLE C-XXVIIIa. (Probability of slot selection) for LE_call PDUs. 335TABLE C-XXVIIIb. Probability of slot selection for LE_broadcast and LE_notification PDUs. 335TABLE C-XXIX. 3G-ALE synchronous mode protocol behavior. 339TABLE C-XXX. 3G-ALE asynchronous mode protocol behavior. 349TABLE C-XXXI. 3G-ALE synchronization management time quality codes. 356TABLE C-XXXII. 3G-ALE synchronization management sync offset codes. 358TABLE C-XXXIII. TM data object types. 362TABLE C-XXXIV. TM service primitives. 363TABLE C-XXXV. TM PDU format. 368TABLE XXXVI. Argument field values. 369TABLE C-XXXVII. TM events. 371TABLE C-XXXVIII. TM actions. 374TABLE C-XXXIX. TM data items. 378TABLE C-XL. TM state transition table. 385TABLE C-XLI. Protocol time-intervals. 392TABLE C-XLI. Protocol time-intervals. 394TABLE C-XLII. HDL data object types. 408TABLE OF CONTENTS(continued)PARAGRAPH PAGETABLE C-XLIII. HDL service primitives. 410TABLE C-XLIV. Data packet format. 411TABLE C-XLV. Sequence number field definition. 411TABLE C-XLVI. HDL_ACK PDU format. 412TABLE C-XLVII. HDL_EOM PDU. 412TABLE C-XLVIII. HDL events. 415TABLE C-IL. HDL actions. 416TABLE C-L. HDL data items. 418TABLE C-LI. HDL state transition table. 420TABLE C-LII. LDL data object types. 421TABLE C-LIII. LDL service primitives. 422TABLE C-LIV. Data packet format. 423TABLE C-LV. Sequence number field definition. 424TABLE C-LVI. LDL_ACK PDU format. 424TABLE C-LVII. LDL_EOM PDU format. 425TABLE C-LVIII. LDL events. 427TABLE C-LIX. LDL actions. 428TABLE C-LX. LDL data items. 430TABLE C-LXI. LDL state transition table. 432TABLE C-LXII. CLC service primitives. 433TABLE C-LXIII. CLC events. 436TABLE C-LXIV. CLC actions. 437TABLE C-LXV. CLC data items. 438TABLE C-LXVI. Backoff interval duration probabilities. 438
FIGURE C-1. Scope of 3G technology. 278FIGURE C-2. 3G HF protocol suite. 282FIGURE C-3. Synchronous mode address structure. 285FIGURE C-4. CRC computation structure. 291FIGURE C-5. BW0 timing. 297FIGURE C-6. Rate 1/2, constraint length 7 convolutional encoder. 300FIGURE C-7. BW1 timing. 303FIGURE C-8. Rate 1/3, constraint length 9 convolutional encoder. 306FIGURE C-9. BW2 waveform structure and timing characteristics. 310FIGURE C-10. Data packet extension with encoder flush bits. 311FIGURE C-11. Rate 1/4, constraint length 8 convolutional encoder. 313FIGURE C-12. 2 16 - 1 maximum-length sequence generator. 315FIGURE C-13. BW3 timing. 316FIGURE C-14. BW3 rate 1/2, k=7 convolutional encoder. 318FIGURE C-15. BW4 timing. 321FIGURE C-16. Carrier modulation. 324TABLE OF CONTENTS(continued)PARAGRAPH PAGEFIGURE C-17. 3G-ALE PDUs. 327FIGURE C-18. Synchronous dwell structure. 331FIGURE C-19. Example 3G-ALE synchronous link establishment. 344FIGURE C-20. 3G-ALE asynchronous mode link establishment. 352FIGURE C-21. TM state diagram: packet. 380FIGURE C-22. TM state diagram: point-to-point circuit. 381FIGURE C-23. TM state diagram: multicast circuit (master). 382FIGURE C-24. TM state diagram: multicast circuit (slave). 383FIGURE C-25. TM state diagram: broadcast circuit. 384FIGURE C-26. Point-to-point packet link timing example for TdeltaTOD =0, Tprop = Tprop,max.. 398FIGURE C-27. Point-to-point packet link timing example for TdeltaTOD = -Tsug, Tprop = Tprop,max. 399FIGURE C-28. Point-to-point packet link timing example for TdeltaTOD = Tsug, Tprop = Tprop,max. 400FIGURE C-29. Point-to-point packet link timing example for TdeltaTOD = -Tsug, Tprop = 0. 401FIGURE C-30. Point-to-point packet link timing example for TdeltaTOD = Tsug, Tprop = 0. 402FIGURE C-31. Point-to-point circuit link timing example. 404FIGURE C-32. Multicast circuit link timing example. 407FIGURE C-33. HDL data transfer overview. 414FIGURE C-34. HDL link termination scenario overview. 414FIGURE C-35. HDL state diagram. 419FIGURE C-36. LDL data transfer overview. 426FIGURE C-37. LDL link termination scenario overview. 426FIGURE C-38. LDL state diagram. 431FIGURE C-39. CLC state diagram. 440FIGURE C-40. ALE/TSU scenarios: packet and point-to-point circuit links. 441FIGURE C-41. ALE/TSU scenario: multicast circuit links. 442FIGURE C-42. Packet traffic link termination scenarios. 443FIGURE C-43. Two-way packet link scenarios. 443FIGURE C-44. Link termination scenarios: multicast circuit links. 444FIGURE C-45. Packet linking and traffic exchange: on-air signalling overview. 445
This appendix contains the requirements for the prescribed protocols
and directions for the implementation and use of third generation
(3G) high frequency (HF) radio technology including advanced automatic
link establishment (ALE), automatic link maintenance, and high-performance
data link protocols. The inter-relationship of the technology
specified in this appendix to other HF automation standards is
shown in figure C-1.
3G technology provides advanced technical capabilities for automated
HF radio systems. This advanced technology improves on the performance
of similar techniques described elsewhere in this standard. Thus,
3G technology may not be required by some users of HF radio systems.
However, if the user has a requirement for the features and functions
described herein, they shall be implemented in accordance with
the technical parameters specified in this appendix.
The documents listed in this section are specified in C.4 and
C.5 of this appendix. This section does not include documents
cited in other sections of this standard or recommended for additional
information or as examples. While every effort has been made
to ensure the completeness of this list, document users are cautioned
that they must meet all specified requirements documents cited
in C.4 and C.5 of this appendix, whether or not they are listed
here.
The following specifications, standards, and handbooks form a
part of this document to the extent specified herein. Unless
otherwise specified, the issues of these documents are those listed
in the issue of the Department of Defense Index of Specifications
and Standards (DODISS) and supplement thereto, cited in the solicitation.
STANDARDS
FEDERAL
FED-STD-1037 Telecommunications: Glossary of Telecommunication Terms
MILITARY
MIL-STD-188-110 Interoperability and Performance Standards
for HF Data Modems
Unless otherwise indicated, copies of federal and military specifications,
standards, and handbooks are available from the Naval Publications
and Forms Center, ATTN: NPODS, 5801 Tabor Avenue, Philadelphia,
PA 19120-5099.
The following other Government documents, drawings, and publications form a part of this document to the extent specified herein. Unless otherwise specified, the issues are those cited in the solicitation.
None.
The following documents form a part of this document to the extent
specified herein. Unless otherwise specified, the issues of the
documents which are DoD adopted are those listed in the issues
of the DODISS cited in the solicitation. Unless otherwise specified,
the issues of the documents not listed in the DODISS are the issues
of the documents cited in the solicitation (see 6.3).
INTERNATIONAL STANDARDIZATION DOCUMENTS
North Atlantic Treaty Organization (NATO) Standardization Agreements (STANAGs)
STANAG 4285 Characteristics of 1200/2400/3600 bits per second
Single Tone modulators/demodulators for HF
Radio Links
STANAG 4197 Modulation and Coding Characteristics that Must
be Common to Assure Interoperability of 2400 BPS
Linear Predictive Encoded Digital Speech
Transmitted Over HF Radio Facilities
STANAG 4198 Parameters and Coding Characteristics That Must
be Common to Assure Interoperability of 2400 BPS
Linear Predictive Encoded Digital Speech
International Telecommunications Union (ITU)
Radio Regulations Recommendtion for Fixed Service, Use of High
ITU-R F.520-2 Frequency Ionospheric Chanel Simulators
In the event of a conflict between the text of this document and the references cited herein, the text of this document takes precedence. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption has been obtained.
The abbreviations and acronyms used in this document are defined
below. Those listed in the current edition of FED-STD-1037 have
been included for the convenience of the reader.
| 2G | second generation | |
| 2G ALE | second generation automatic link establishment |
| 3G | third generation | ||
| 3G ALE | third generation automatic link establishment | ||
| ACK | acknowledgment | ||
| ACQ-ALE | alternative quick call -automatic link establishment | ||
| AGC | automatic gain control | ||
| ALE | automatic link establishment | ||
| ALM | automatic link maintenance | ||
| ARQ | automatic repeat request | ||
| ASCII | American Standard Code for Information Interchange | ||
| AWGN | additive white gaussian noise | ||
| bps | bits per second | ||
| BW0 | Burst Waveform 0 | ||
| BW1 | Burst Waveform 1 | ||
| BW2 | Burst Waveform 2 | ||
| BW3 | Burst Waveform 3 | ||
| BW4 | Burst Waveform 4 | ||
| CLC | circuit link controller | ||
| CM | Connection Manager | ||
| CMD | ALE preamble word COMMAND | ||
| CONF | confirm | ||
| CRC | cyclic redundancy check | ||
| CSU | Call SetUp | ||
| dB | decibel | ||
| DO | design objective | ||
| EMCON | Emission Control | ||
| EOM | End of Message | ||
| FEC | forward error correction | ||
| FSK | frequency shift keying | ||
| GPS | Global Positioning System | ||
| HF | high frequency | ||
| HDL | high-rate data link protocol | ||
| HNMP | HF Network Management Protocol | ||
| Hz | Hertz | ||
| LDL | low-rate data link protocol | ||
| lsb | least-significant bit | ||
| kHz | kiloHertz | ||
| MHZ | megahertz | ||
| ms | millisecond | ||
| msb | most-significant bit | ||
| NAK | negative acknowledgment | ||
| PDU | protocol data unit | ||
| PN | pseudo noise | ||
| REQ | request | ||
| rx | receive | ||
| s | second | ||
| SDU | service data unit | ||
| SNMP | simple network management protocol | ||
| SSB | Single SideBand | ||
| TERM | Terminate | ||
| TLC | Transmit Level Control | ||
| TM | traffic management | ||
| TOD | time of day | ||
| TRF | Traffic | ||
| TSU | Traffic SetUp | ||
| TWAS | ALE preamble word THIS WAS | ||
| tx | transmit | |
| UNL | unlink |
The operating parameters used in this appendix are collected here for the convenience of the reader.
Symbol Parameter Name Default Value
Tsym PSK symbol time 1/2400 s _ 417 µsTslot
Slot time 800 milliseconds (ms)C Number of scanned channelsM
Number of repetitions of protocol data units (PDUs)
per channel in asynchronous networks 1.3Tsc Time for
an asynchronous mode scanning callTtlc Time for transmit
level control settling 256/2400 s _ 106.7 msTBW0 pre
Time for Burst Waveform 0 preamble 384/2400 s = 160.0 msTBW0
data Time for Burst Waveform 0 data 832/2400 s _ 346.7 msD
Current dwell channelT Seconds since midnight (network time)G
Dwell group number
Also see table C-XXV 3G-ALE Protocol Data
for additional operating parameters.
The third-generation automatic link establishment (3G-ALE) protocol, the Traffic Management (TM) protocol, the High-Rate Data Link (HDL) and Low-Rate Data Link (LDL) protocols, and the circuit link management (CLC) protocol form a mutually-dependent protocol suite (see figure C-2). Compliance with this appendix requires compliant implementations of all of the protocols defined in this appendix (shown in shaded box in figure C-2).
Frequencies assigned for use in 3G networks will be designated for use in calling, traffic, or both. Network managers should observe the following principles in assigning channels in these networks:
Calling channels shall be assigned to the lowest-numbered channels,
starting with channel 0. When C calling channels are scanned,
the highest-numbered calling channel shall be C-1.
Channel 127 shall be understood to refer to the current channel
(calling channel in ALE, traffic channel in ALM).
Systems shall provide for management of frequency use via SNMP
or HNMP. This capability shall include at least the following:
NOTE: The network manager must assign the first three items uniformly
network-wide.
3G systems shall include mechanisms to maintain synchronization
among all local time bases in a network. When 3G-ALE is operating
in synchronous mode, the difference between the earliest time
and the latest time among the stations must not exceed 50 ms.
In asynchronous networks, the permissible range of network times
is determined by the current level of linking protection, if any.
A means shall be provided to set the local time from a source
such as a Global Positioning System (GPS) receiver. The internal
time base shall differ by no more than 1 ms from the external
source immediately after such a time update. Time base drift
shall not exceed 1 part per million.
When an external source of synchronization is not available, 3G
systems shall maintain synchronization using the synchronization
management protocol of C.5.2.7.
When not engaged in any of the 2G or 3G protocols, 3G systems shall continuously scan assigned channels, listening for 2G and 3G calls. They shall leave the scanning state when called or when placing a call, in accordance with the protocol behaviors specified in C.5.2.4 and
C.5.2.5.
3G ALE synchronous-mode receivers shall scan at a synchronized
rate of 4 seconds per channel. Stations shall be assigned to
dwell groups by the network manager. Each dwell group shall listen
on a different channel during each 4-second dwell period, in accordance
with the following formula:
D = ((T / 4) + G) mod C
where D = Dwell channel
T = Seconds since midnight (network time)
G = Dwell group number
C = Number of channels in scan list
Note that this yields channel numbers in the range 0 to C-1 in
accordance with C.4.2.1.
3G systems using asynchronous mode 3G ALE shall scan assigned
calling channels at a rate of at least 1.5 channels per second.
(design objective (DO): scan at 10 channels per second, in which
case the corresponding dwell period of 100 ms may be extended
to up to 667 ms as required when evaluating received signals.
If a BW0 preamble has not been detected within 667 ms, the
system shall resume scanning.)
3G systems use 11-bit binary addresses in the over-the-air protocols.
These addresses shall be translated to and from second-generation
addresses (call signs of up to 15 American Standard Code for Information
Interchange (ASCII)-36 characters) for operator use.
The synchronous mode 3G-ALE protocol defines further structure
within the 11-bit address space: the 5 least-significant bits
(LSBs) of the address shall contain the dwell group number of
the node, and the 6 most-significant bits (MSBs) shall contain
the node's member number within that group (see figure C-3).
The member numbers from 111100 through 111111 (addresses 11110000000
through 11111111111) are reserved for temporary use by stations
calling into a network, and shall not be assigned to any network
member.
Multicast addresses form a distinct 6-bit address space, and shall
be distinguished from individual addresses by their use only in
multicast calls. When computing link IDs for use in multicast
calls, the multicast address shall be placed in the most-significant
six bits (member number portion in figure C-1), and the group
number bit positions shall be filled with five bits set to 1.
Each node in a network shall be assigned a single 11-bit address
that is distinct from all other node addresses in the network.
This address shall be recognized by that node in individual and
unicast calls.
NOTE: When it is desired to be able to reach all network members
with a single call, and network traffic is expected to be light,
up to 60 network member stations may be assigned to one dwell
group. However, this arrangement is subject to calling channel
congestion. To support heavier call volume than the single-group
scheme will support, the network members should be distributed
into multiple dwell groups.
A 3G system shall be programmable to subscribe to (recognize)
at least 10 multicast addresses in addition to its individual
node address. Multicast addresses have network-wide scope.
3G ALE provides functionality similar to second-generation ALE
(2G ALE) as described in Appendix A, but with improved ability
to link in stressed channels, to link more quickly, and to operate
efficiently in large, data-oriented networks.
3G ALE systems shall be capable of operation in both asynchronous
and synchronous modes in accordance with C.5.2.4 and C.5.2.5.
A system operating in synchronous mode shall recognize asynchronous-mode
scanning calls addressed to it and respond to such calls in accordance
with the asynchronous-mode protocol.
After a link is established using 3G-ALE, the system shall wait
no more than a programmable time, (Ttraf_wait Time
or trafWaitTimeMcast as appropriate), for traffic setup to begin,
and shall return to scanning if traffic setup has not begun within
that time.
Requirements for linking probability and occupancy detection are
specified in the following paragraphs.
3G ALE systems shall meet or exceed the linking probability requirements
of table C-I while operating in synchronous or asynchronous mode.
The test procedure of A.4.2.3 shall be employed, with the following
modifications:
Additional requirements are listed in the following paragraphs
that are specific to operation in synchronous or asynchronous
mode.
3G ALE systems operating in synchronous mode shall meet or exceed
the linking probability requirements of table C-I with a 12-second
time limit for each successful call.
NOTE: Synchronous-mode systems will normally link within 4 seconds
if the call is placed on the first channel scanned, but may defer
calling until a later dwell if the current channel has been recorded
as non-propagating.
3G ALE systems operating in asynchronous mode shall meet or exceed
the linking probability requirements of table C-I with a 6-second
time limit for each successful call.
3G ALE systems shall detect occupied channels as specified below
for synchronous or asynchronous operation, and shall not send
ALE PDUs on channels that appear to be occupied without operator
intervention. The probability of declaring a channel occupied
when it carries only additive white gaussian noise (AWGN) shall
be less than 1percent.
3G ALE systems operating in synchronous mode shall correctly recognize
that a channel is occupied at least as reliably as indicated in
table C-II during the Listen portion of Slot 0 (see C.5.2.3, Synchronous
dwell structure). The test procedure of A.4.2.2 shall
be used. Systems shall also meet or exceed the requirements of
table C-II for detecting calling channels in use while listening
before calling during Slots 1 through 3.
3G ALE systems operating in asynchronous mode shall meet the occupancy
detection requirements of A.4.2.2, using the test procedure specified
in A.4.2.2. Such systems shall also meet the 3G-ALE and 3G-HDL
occupancy detection requirements of table C-II.
| 2G-ALE | ||
| 3G-ALE (BW0) | ||
| 3G-HDL (BW2) | ||
| single sideband (SSB) Voice | ||
| MIL-STD-188-110 or | ||
| FED-STD-1052 PSK modem | ||
| STANAG 4285 or | ||
| STANAG 4529 PSK modem |
The 3G ALE calling protocols inherently evaluate channels during
link establishment. However, informed selection of the initial
calling channel can reduce calling overhead (in both synchronous
and asynchronous modes) and result in faster linking (in asynchronous
mode). 3G ALE systems should use all available channel quality
data to select the initial channel for calling:
A 3G ALE system shall always listen for 2G signalling when it
is listening for 3G calls. 2G sounds shall be evaluated, and
the results shall be stored for use in placing 2G calls.
When establishing a link while operating in MIL-STD-188-148A frequency-hopping
mode, a 3G ALE system shall spread each PDU over multiple hops
in accordance with Appendix F. Linking performance when linking
while hopping shall meet or exceed the requirements of Appendix
F.
When a link has been established for packet data transfer, using
3G-ALE or other means, the TM protocol in accordance with C.5.4
shall be used to coordinate use of the HDLand LDL protocols in
accordance with C.5.5 and C.5.6 to transfer data messages. When
a link has been established for data virtual circuit operation,
the CLC protocol (C.5.7) shall be used.
The Relink and Restart commands of C.5.3 shall be used to initiate
changes in frequency or data link operating mode when such changes
would result in higher performance.
3G systems should provide a network management interface in accordance
with Appendix D to facilitate interoperability with common network
management systems.
Unless otherwise specified, all PDUs shall be serialized as follows:
NOTE: The MSB of each field is shown as the leftmost bit in each
figure in this appendix.
3G systems shall implement the following data structures at the
network management interface (if provided).
The "self address" of each 3G ALE station table shall
be an index into the station table (see below).
The 3G ALE station table shall be capable of storing at least
128 entries. Each entry shall contain at least the following
fields:
Entries for all network members shall be locked in the table.
Other table entries shall store data obtained from received PDUs,
with the oldest such entry replaced when new data is available
and the table is full.
The channel table shall provide storage for at least 128 channel
entries. Individual flags for each channel shall indicate whether
that channel may be used for 3G link establishment, for 2G link
establishment, and for traffic. Each entry shall also include
transmit and receive frequencies, antenna selection and settings,
power limits, and modulation type.
A CRC (Cyclic Redundancy Check) is a sequence of bits computed
in a specific manner from a sequence of input bits. The CRC is
concatenated with the string of input bits and the entire sequence
is transmitted over a channel. At the receive side of the channel,
the CRC is used to attempt to determine whether the channel caused
there to be any errors in the concatenated sequence. The input
sequence of bits is said to be covered by the CRC. A suitably
chosen method for generating the CRC sequence can reduce the probability
of undetected random channel errors to approximately (½)K
where K is the number of bits comprising the CRC. All of the
CRCs used in the protocols defined in this Appendix shall be computed
using the procedure defined below.
When a CRC is to be computed from the non-CRC bits of a given PDU, the following must be known:
U0, U1, … UN-1 the N non-CRC
bits contained in the PDU, in the order in which they will be
coded, modulated, and transmitted, so that U0
will be the first bit input to the PDU coding and modulation processing.
g(X) A Kth order polynomial with binary coefficients
of form:
NOTE: 1. The order K of this polynomial indicates the number of bits comprising the CRC.
NOTE: 2. The zeroth and Kth coefficients,
g0 and gk, are equal to one.
The following diagram indicates the operations necessary to compute
the CRC. The addition operation pictured is binary addition (exclusive-or).
The multipliers pictured represent binary multiplication (or binary
and); specifically, each circle containing the name of one of
the polynomial coefficients multiplies its input by the coefficient
value (0 or 1) to produce its output.
The above structure is used by the transmitter to produce a CRC sequence from the N user bits U0 through UN-1 via the following procedure:
NOTE: The structure can be viewed as a feedback shift register
with feedback connections corresponding to the coefficients of
the polynomial: the feedback connection labeled 'gi'
is present if and only if the coefficient gi
is equal to one.
This section defines the constituent waveforms used by the Third Generation HF Automation protocols. Burst waveforms are defined for the various kinds of signalling required in the system, so as to meet their distinctive requirements as to payload, duration, time synchronization, and acquisition and demodulation performance in the presence of noise, fading, and multipath. All of the burst waveforms use the basic 8-ary PSK serial tone modulation of an 1800 hertz (Hz) carrier at 2400 symbols per second that is also used in the MIL-STD-188-110 serial tone modem waveform. Table C-III summarizes the characteristics of the waveforms and their uses within this standard.
| ||||||||
| BW0 | 3G-ALE PDUs | 613.33 ms
1472 PSK symbols | 26 bits | 160.00 ms
384 PSK symbols | rate = 1/2,
k = 7 convolutional (no flush bits) | 4x13 block | 16-ary orthogonal Walsh function | |
| BW1 | Traffic Manage-ment PDUs; HDLacknow-ledgement PDUs | 1.30667 seconds
3136 PSK symbols | 48 bits | 240.00 ms
576 PSK symbols | rate = 1/3,
k = 9 convolutional (no flush bits) | 16x9 block | 16-ary orthogonal Walsh function | |
| BW2 | HDLtraffic data PDUs | 640 + (n*400) ms
1536 + (n*960) PSK symbols, n = 3, 6, 12, or 24 | n*1881 bits | 26.67 ms
64 PSK symbols (for equalizer training) | rate = 1/4,
k = 8 convolutional (7 flush bits) | none | 32 unknown/
16 known |
|
| BW3 | LDL traffic data PDUs | 373.33 + (n*13.33) ms
32n + 896 PSK symbols, n = 64, 128, 256, or 512 | 8n+25 bits | 266.67 ms
640 PSK symbols | rate = 1/2,
k = 7 convolutional (7 flush bits)2 | 24x24, 32x34, 44x48, or 64x65 convol-utional block | 16-ary orthogonal Walsh function |
|
| BW4 | LDL acknow-ledgement PDUs | 640.00 ms
1536 PSK symbols | 2 bits | none | none | none | 4-ary orthogonal Walsh function | |
| Notes:
1. Reflects Forward Error Correction (FEC) and Walsh-function coding only; does not include known data or convolutional encoder flush bits. 2. In this case, the number of flush bits exceeds by one the minimum number required to flush the convolutional encoder; this makes the number of coded bits a multiple of four as is required for the Walsh-function modulation format. | ||||||||
Other waveforms, including the MIL-STD-188-110 serial tone modem
waveform, can be used to deliver data and digitized voice signalling
on circuit links established using the 3G-ALE and TM protocols.
Table C-IV defines the service primitives exchanged between the
Burst Waveform (physical layer) entities and the higher-layer
user processes that use Burst Waveform services. Note that there
is no requirement that implementations of the waveforms and protocols
defined in this Appendix contain precisely these service primitives;
nor are the services primitives defined below necessarily all
of the service primitives that would be required in an implementation
of these waveforms and protocols.
| BW0_Send | Overview | Invoked by a user process to send a 26-bit data payload using the BW0 robust burst signalling format | |
| Parameters | payload | an ordered sequence of 26 bits of data to be modulated and transmitted using the BW0 signalling format | |
| Originator | Connection Management (CM) | ||
| Preconditions | |||
| BW0_Receive | Overview | Issued by BW0 Receiver when it has received a BW0 transmission. | |
| Parameters | payload | the 26 bits of payload data received in the incoming BW0 transmission. The payload value can contain undetected errors due to channel noise, fading, multipath, etc.; however, on a perfect channel, the payload value would be identical to the payload parameter-value of the original BW0_Send primitive at the remote station. | |
| Originator | BW0 Receiver | ||
| Preconditions | BW0 Receiver is active. | ||
| BW0_Pre_Detect | Overview | Issued by BW0 Receiver when it has detected a BW0 acquisition preamble. | |
| Parameters | none | ||
| Originator | BW0 Receiver | ||
| Preconditions | BW0 Receiver is active. | ||
| BW1_Send | Overview | Invoked by a user process to send a 48-bit data payload using the BW1 robust burst signalling format | |
| Parameters | payload | an ordered sequence of 48 bits of data to be modulated and transmitted using the BW1 signalling format | |
| Originator |
| ||
| Preconditions | |||
| BW1_Receive | Overview | Issued by BW1 Receiver when it has received a BW1 transmission. | |
| Parameters | payload | the 48 bits of payload data received in the incoming BW1 transmission. The payload value can contain undetected errors due to channel noise, fading, multipath, etc.; however, on a perfect channel, the payload value would be identical to the payload parameter-value of the original BW1_Send primitive at the remote station. | |
| Originator | BW1 Receiver | ||
| Preconditions | BW1 Receiver is active. | ||
| BW1_Pre_Detect | Overview | Issued by BW1 Receiver when it has detected a BW1acquisition preamble. | |
| Parameters | none | ||
| Originator | BW1 Receiver | ||
| Preconditions | BW1 Receiver is active. | ||
| BW2_Send | Overview | Invoked by a user process to send a sequence of data packets to a remote station, using the BW2 high-rate burst signalling format | |
| Parameters | tx frame | a BW2 tx frame, consisting of an ordered sequence of NumPkts data packets to be modulated and transmitted using the BW2 signalling format, where NumPkts = 3, 6, 12, or 24. Each data packet contains an ordered sequence of 1881 bits of payload data. | |
| reset | boolean value; reset = TRUE indicates to the BW2 transmitter that it should reset its Forward Transmission counter, FTcount. | ||
| Originator | HDL protocol | ||
| Preconditions | A previous signalling exchange has established the time at which transmission of the current BW2 burst is to start, and the time at which the receiver should expect it to arrive. | ||
| If reset = FALSE, the value of NumPkts for the current invocation of BW2_Send (i.e., the number of data packets in the forward transmission frame, payload) must be equal to the value of NumPkts in the preceding invocation of BW2_Send. (reset = TRUE in the first invocation of BW2_Send for a new datagram, at which time the value of NumPkts for all invocations of BW2_Send throughout the duration of the datagram transfer is determined.) | |||
| BW2_Receive | Overview | Issued by the BW2 Receiver when it has received a BW2 transmission. | |
| Parameters | rx frame | a BW2 rx frame containing NumRcvd indexed data packets, where 0 < NumRcvd < NumPkts. An indexed data packet contains
Only data packets received with no errors (as indicated by checking the 32-bit CRC added to each packet by BW2) are passed to the user process in a BW2 rx frame. | |
| Originator | BW2 Receiver | ||
| Preconditions | BW2 Receiver is active. | ||
| The arrival time of the incoming BW2 burst has been estimated, based on the observed arrival time of previous received signalling from the remote station. | |||
| BW3_Send | Overview | Invoked by a user process to send a data packet to a remote station, using the BW3 low-rate burst signalling format. | |
| Parameters | payload | an ordered sequence of 537, 1049, 2073, or 4121 bits of data to be modulated and transmitted using the BW3 signalling format. (Note: these payload lengths are chosen so as to accommodate the four possible forward transmission lengths of the LDL; see section C.5.5.) | |
| reset | boolean value; reset = TRUE indicates to the BW3 modulator that it should reset its Forward Transmission counter, FTcount. | ||
| Originator | LDL protocol | ||
| Preconditions | A previous signalling exchange has established the time at which transmission of the current BW3 burst is to start, and the time at which the receiver should expect it to arrive. | ||
| BW3_Receive | Overview | Issued by the BW3 Receiver when it has successfully received a BW3 transmission without errors. | |
| Parameters | payload | 537, 1049, 2073, or 4121 bits of BW3 data demodulated and received without errors by the Burst Waveform Modem, as determined by the CRC check performed by the BW3 receiver; identical to the payload parameter-value of the original BW3_Send primitive at the remote station. | |
| Originator | BW3 Receiver | ||
| Preconditions | BW3 Receiver is active. | ||
| The arrival time of the incoming BW3 burst has been estimated, based on the observed arrival time of previous received signalling from the remote station. | |||
| BW4_Send | Overview | Invoked by a user process to send two bits of payload data using the BW4 robust burst signalling format. | |
| Parameters | payload | two bits of data to be modulated and transmitted using the BW4 signalling format. | |
| Originator | LDL protocol | ||
| Preconditions | A previous signalling exchange has established the time at which transmission of the current BW4 burst is to start, and the time at which the receiver should expect it to arrive. | ||
| BW4_Receive | Overview | Issued by the BW4 Receiver when it has received a BW4 transmission. | |
| Parameters | payload | two bits of BW4 data received and demodulated by the Burst Waveform Modem. The payload value can contain undetected errors due to channel noise, fading, multipath, etc.; however, on a perfect channel, the payload value would be identical to the payload parameter-value of the original BW4_Send primitive at the remote station. | |
| Originator | BW4 Receiver | ||
| Preconditions | BW4 Receiver is active. | ||
| The arrival time of the incoming BW4 burst has been estimated, based on the observed arrival time of previous received signalling from the remote station. | |||
A block interleaver is used to improve FEC performance for certain
of the burst waveforms described below. This interleaver is based
on a single interleave matrix having R rows and C columns, and
hence accommodating up to (R * C) bits.
The particular interleaver used in each burst waveform is defined by the values assigned to the following set of interleaver parameters:
| R |
|
| C |
|
| irs |
|
| ics |
|
| irs |
|
| ics |
|
| irf |
|
| icf |
|
| irf |
|
| icf |
|
The parameter-values for each burst waveform are given in the
sections of this document describing the individual burst waveforms.
Irrespective of the particular values assigned to these parameters, each of the interleavers is operated in the following way. Starting with the matrix empty, (R * C) input bits are stuffed one by one into the matrix using the algorithm:
initialize s (stuff count), rs, and cs to zero
while s < (R * C)
matrix[rs,cs] = input bit
increment s
if (s mod R) == 0
cs = (cs + ics + ics) mod C
else
cs = (cs + ics) mod C
end if
if (s mod C) == 0
rs = (rs + irs + irs) mod R
else
rs = (rs + irs) mod R
end if
end while
NOTE: using '=' to denote assignment, and ' ==' to denote the
equality predicate.
Once the matrix has been filled, the (R * C) output bits are fetched one by one from the matrix in interleaved order, using the algorithm:
initialize f (fetch count), rf, and cf to zero
while f < (R * C)
output bit = matrix[rf,cf]
increment f
if (f mod R) == 0
cf = (cf + icf + icf) mod C
else
cf = (cf + icf) mod C
end if
if (f mod C) == 0
rf = (rf + irf + irf) mod R
else
rf = (rf + irf) mod R
end if
end while
Burst Waveform 0 (BW0) is used to convey all 3G-ALE (connection management) PDUs. Figure C-5 summarizes the structure and timing characteristics of the BW0 waveform.
Higher layer protocols cause the generation of a BW0 burst by invoking the BW0_Send primitive. The BW0_Send primitive has one parameter:
Ttlc = 106.667 milliseconds: 256 PSK symbols at 2400 symbols/second
Tpre = 160.0 milliseconds: 384 PSK symbols at 2400 symbols/second
Tdata = 346.667 milliseconds: 832 PSK symbols at 2400 symbols/second
TBW1_tx = total duration = 613.333 milliseconds
C.5.2 describes the manner in which the user process assigns values
to the payload parameter.
The description of the BW0 waveform generation will proceed as
follows:
NOTE: A tribit number can take on the values 0,1,…,7.
The TLC/AGC guard sequence portion of the BW0 waveform provides
an opportunity for both the transmitting radio's Transmit Level
Control process (TLC) and the receiving radio's Automatic Gain
Control process (AGC) to reach steady states before the BW0 preamble
appears at their respective inputs, minimizing the distortion
to which the preamble can be subjected by these processes. The
TLC/AGC guard sequence is a sequence of 256 pseudo-random tribit
symbols having the values shown in table C-V.
The tribit symbols are transmitted in the order shown in table
C-V, starting at the top left and moving from left to right across
each row, and from top to bottom through successive rows.
5,4,7,4, 4,7,6,1, 0,6,0,4, 0,2,3,4, 6,5,7,5, 4,7,2,3, 4,2,7,5, 4,3,3,1,
4,2,0,0, 3,4,4,1, 3,5,3,3,
2,2,1,0, 0,0,5,5, 6,1,6,2, 1,6,4,3, 2,5,2,7,
5,2,3,4, 0,4,2,7, 7,0,4,2, 6,2,6,4, 6,5,0,1, 2,7,6,5, 5,2,7,3, 3,3,2,1,
2,5,6,1, 3,4,2,1, 0,1,2,3,
6,4,7,5, 2,2,6,2, 7,6,5,2, 4,6,5,4, 7,2,5,1,
0,0,7,7, 3,5,4,2, 1,4,2,7, 0,3,4,0, 1,0,5,2, 6,0,3,5, 1,0,5,1, 5,2,5,6,
3,2,3,7, 1,2,2,0, 7,1,3,6,
4,2,6,2, 7,4,3,7, 6,7,2,3, 1,7,4,1, 5,1,5,4,
7,1,1,2, 3,6,7,7, 6,6,1,2, 2,4,1,7, 7,5,5,4, 7,7,5,0, 7,3,7,5, 7,7,5,0,
6,6,6,1, 3,4,4,4, 0,3,3,2, 1,4,5,4, 5,3,1,1, 1,2,5,1, 7,1,5,7, 2,0,0,6
The TLC/AGC guard sequence symbols are modulated directly as described
in C.5.1.3.7, without undergoing PN spreading as described in
C.5.1.3.6.
The BW0 acquisition preamble provides an opportunity for the receiver
to detect the presence of the waveform and to estimate various
parameters for use in data demodulation. The preamble component
of BW0 is the sequence of 384 tribit symbols shown in C-VI. The
preamble symbols are modulated directly as described in C.5.1.3.7,
without undergoing PN spreading as described in C.5.1.3.6. The
preamble symbols are transmitted in the order shown in table C-VI,
starting at the top left and moving from left to right across
each row, and from top to bottom through successive rows.
When it detects a BW0 acquisition preamble, the BW0 receiver issues
a BW0_Pre_Detect service primitive, as described in table C-IV.
7,7,7,7, 5,4,3,1, 1,2,0,2, 7,2,2,0, 1,3,4,7, 5,3,7,7, 4,3,1,0, 1,1,5,2,
1,6,0,0, 4,7,6,2, 2,3,6,0, 5,1,7,6, 1,6,1,7, 6,6,6,1, 7,3,0,4, 7,1,2,2,
3,3,6,7, 7,1,7,3, 1,5,0,3, 3,4,5,2, 5,2,5,3, 1,7,2,1, 5,7,6,1, 2,5,3,5,
3,6,2,0, 7,5,6,6, 0,1,4,2,
5,4,1,1, 7,0,0,6, 6,7,5,6, 3,7,4,0, 2,6,3,6,
4,5,1,0, 0,4,5,5, 4,7,1,5, 1,5,6,7, 3,3,5,2, 2,2,7,2, 3,3,0,4, 1,4,1,3,
6,0,7,2, 6,1,5,0, 1,4,1,1, 7,0,7,4, 0,2,4,5, 3,0,0,3, 1,2,6,4, 6,5,2,6,
0,0,7,3, 5,3,4,0, 6,2,7,2, 3,3,7,6, 7,1,0,0, 6,7,3,1, 5,5,0,2, 3,4,2,7,
7,4,5,2, 1,6,1,0, 4,7,1,6,
1,2,4,0, 3,6,5,4, 5,4,4,6, 1,2,5,1, 3,6,2,7,
2,6,7,4, 7,3,0,1, 5,0,5,3, 4,5,0,7, 3,2,7,0, 3,2,7,0, 6,1,6,7, 7,1,4,2,
6,7,7,4, 2,7,2,7, 3,7,6,3, 2,6,5,6, 6,3,6,6, 4,1,0,6, 2,6,4,1, 5,5,4,3,
3,4,6,3, 5,2,4,1, 1,7,5,3, 7,1,6,5, 4,6,6,2, 3,4,2,3, 3,7,4,1, 4,4,5,4,
6,1,3,4, 6,1,7,4, 1,3,5,2, 6,5,5,4, 2,1,5,1, 6,1,2,7, 1,4,4,2, 3,4,7,3
BW0 carries a payload of 26 protocol bits. The 26 protocol bits are encoded using the r = 1/2, k = 7 convolutional encoder shown in figure C-6, creating 52 coded bits. A 'tail-biting' convolutional encoding approach is used as follows:
No flush bits are necessary for the encoding process.
The polynomials used are:
where x6 corresponds to the most recent encoder input
bit.
BW0 utilizes a simple block interleaver structure which can be
viewed as a 4 by 13 element rectangular array. See C.5.1.2 for
a description of the interleaving process. The interleaver parameters
for BW0 are as follows:
| R | 4 |
| C | 13 |
| irs | 0 |
| ics | 1 |
| irs | 1 |
| ics | 0 |
| irf | 1 |
| icf | 0 |
| irf | 0 |
| icf | 1 |
The interleaver fetch process removes 4 coded bits at a time from
the interleaver matrix. These four coded bits are mapped into
a 16-tribit sequence using the mapping given in table C-VIII.
Note that each of the four-bit sequences in the Coded Bits
column of the table is of the form b3b2b1b0,
where b3 is the first
bit fetched from the interleaver matrix. The 16-tribit sequence
thus obtained is repeated 4 times to obtain a 64-tribit sequence.
The tribit values are placed in the output tribit sequence in
the order in which they appear in the corresponding row of table
C-VIII, moving from left to right across the row.
| |
This process repeats for a total of 13 iterations (one for each
group of four coded bits) to produce 832 raw tribit values.
A sequence of 832 pseudo-random tribit values si
is generated by extracting 64-tribit sequences from table C-IX,
832/64 = 13 times. The tribit values are extracted in the order
shown in
table C-IX, starting at the top left and moving from left to right
across each row, and from top to bottom through successive rows.
The table contains 256 values; therefore, the PN spreading sequence
is repeated every 4 blocks of 64 tribit sequences.
0,2,4,3, 3,6,4,5, 7,6,7,0, 5,5,4,3, 5,4,3,7, 0,7,6,2, 6,2,4,6, 7,2,4,7,
5,5,7,0, 7,3,3,3, 7,3,3,1,
4,2,3,7, 0,2,7,7, 3,5,1,0, 1,4,0,5, 0,0,0,0,
6,5,0,1, 2,7,6,5, 5,2,7,3, 3,3,2,1, 2,5,6,1, 3,4,2,1, 0,1,2,3, 6,4,7,5,
2,2,6,2, 7,6,5,2, 4,6,5,4,
7,2,5,1, 0,0,7,7, 3,5,4,2, 1,4,2,7, 0,3,4,0,
0,0,7,7, 3,5,4,2, 1,4,2,7, 0,3,4,0, 1,0,5,2, 6,0,3,5, 1,0,5,1, 5,2,5,6,
3,2,3,7, 1,2,2,0, 7,1,3,6,
4,2,6,2, 7,4,3,7, 6,7,2,3, 1,7,4,1, 5,1,5,4,
7,1,1,2, 3,6,7,7, 6,6,1,2, 2,4,1,7, 7,5,5,4, 7,7,5,0, 7,3,7,5, 7,7,5,0,
6,6,6,1, 3,4,4,4, 0,3,3,2, 1,4,5,4, 5,3,1,1, 1,2,5,1, 7,1,5,7, 2,0,0,6
The 832 tribit values si of the PN sequence
are then combined with the 832 raw tribit values ri
produced by the orthogonal symbol formation process described
in the previous section. Each symbol of the PN sequence si
is combined with the corresponding symbol ri
of the raw tribit sequence to form a channel symbol ci,
by adding si to ri
modulo 8. For instance, if si
= 7, ri = 4, then ci = 7 
4
= 3, where the symbol 
represents modulo-8
addition.
The process can be summarized:
where r is the vector of data raw tribit values, s
is the vector of PN sequence tribit values, c is the resulting
vector of combined tribit values, and the symbol 
represents component-wise modulo-8 addition.
The sequence of channel symbols consisting of
is used to PSK modulate an 1800 Hz carrier signal at 2400 channel
symbols/sec.
See C.5.1.8 for a description of how the channel symbol values
are mapped to carrier phases and the subsequent carrier modulation
process.
Burst Waveform 1 (BW1) is used to convey all TM PDUs and the HDL protocol's HDL_ACK PDU. Figure C-7 summarizes the structure and timing characteristics of the BW1 waveform.
Higher layer protocols cause the generation of a BW1 waveform
by invoking the BW1_Send primitive. The BW1_Send primitive has
one parameter:
Sections C.5.2 and C.5.3 describe the manner in which the user processes assign values to the payload parameter.
Ttlc = 106.667 milliseconds: 256 symbols at 2400 symbols/second
Tpre = 240.0 milliseconds: 576 symbols at 2400 symbols/second
Tdata = 960.0 milliseconds: 2304 symbols at 2400 symbols/second
TBW1_tx = total duration = 1.30667 seconds
The description of the BW1 waveform generation will proceed as
follows:
NOTE: A tribit number can take on the values 0,1,…,7.
The TLC/AGC guard sequence portion of the BW1 waveform provides
an opportunity for both the transmitting radio's Transmit Level
Control process (TLC) and the receiving radio's Automatic Gain
Control process (AGC) to reach steady states before the BW1 preamble
appears at their respective inputs, minimizing the distortion
to which the preamble can be subjected by these processes. The
TLC/AGC guard sequence is a sequence of 256 pseudo-random tribit
symbols having the values shown in table C-X. The tribit symbols
are transmitted in the order shown in table C-X, starting at the
top left and moving from left to right across each row, and from
top to bottom through successive rows. For convenience of implementation,
the length of the TLC/AGC guard sequence (256 PSK symbols) has
been chosen so as to be an integral multiple of the length (64
PSK symbols) of the Walsh-function modulated orthogonal symbols
described in C.5.1.4.5.
5,4,7,4, 4,7,6,1, 0,6,0,4, 0,2,3,4, 6,5,7,5, 4,7,2,3, 4,2,7,5, 4,3,3,1,
4,2,0,0, 3,4,4,1, 3,5,3,3,
2,2,1,0, 0,0,5,5, 6,1,6,2, 1,6,4,3, 2,5,2,7,
5,2,3,4, 0,4,2,7, 7,0,4,2, 6,2,6,4, 6,5,0,1, 2,7,6,5, 5,2,7,3, 3,3,2,1,
2,5,6,1, 3,4,2,1, 0,1,2,3,
6,4,7,5, 2,2,6,2, 7,6,5,2, 4,6,5,4, 7,2,5,1,
0,0,7,7, 3,5,4,2, 1,4,2,7, 0,3,4,0, 1,0,5,2, 6,0,3,5, 1,0,5,1, 5,2,5,6,
3,2,3,7, 1,2,2,0, 7,1,3,6,
4,2,6,2, 7,4,3,7, 6,7,2,3, 1,7,4,1, 5,1,5,4,
7,1,1,2, 3,6,7,7, 6,6,1,2, 2,4,1,7, 7,5,5,4, 7,7,5,0, 7,3,7,5, 7,7,5,0,
6,6,6,1, 3,4,4,4, 0,3,3,2,
1,4,5,4, 5,3,1,1, 1,2,5,1, 7,1,5,7, 2,0,0,6
The TLC/AGC guard sequence symbols are modulated directly as described
in C.5.1.4.7, without undergoing PN spreading as described in
C.5.1.4.6.
The BW1 acquisition preamble provides an opportunity for the receiver
to detect the presence of the waveform and to estimate various
parameters for use in data demodulation. The preamble component
of BW1 is a sequence of 576 tribit symbols composed of the 288
symbol values shown in table C-XI, repeated once (two occurrences
in all) for a total of 2 * 288 = 576 tribits. The preamble symbols
are transmitted in the order shown in table C-XI, starting at
the top left and moving from left to right across each row, and
from top to bottom through successive rows. The preamble symbols
are modulated directly as described in C.5.1.4.7, without undergoing
PN spreading as described in C.5.1.4.6.
When it detects a BW1 acquisition preamble, the BW1 receiver issues
a BW1_Pre_Detect service primitive, as described in table C-IV.
BW1 carries a payload of 48 protocol bits. The 48 protocol bits
are coded using the r = 1/3, k = 9 convolutional encoder shown
in figure C-8, creating 144 coded bits. A 'tail-biting' convolutional
encoding approach is used as follows:
No flush bits are necessary for the encoding process. The polynomials
used are:
where x8 corresponds to the most recent encoder input bit.
The order of output to the interleaving process is Bitout0
then Bitout1 then Bitout2.
See C.5.1.2 for a description of the interleaving process. The
interleaver parameters for BW1 are as follows:
| R | 16 |
| C | 9 |
| irs | 0 |
| ics | 1 |
| irs | 1 |
| ics | 0 |
| irf | 1 |
| icf | 0 |
| irf | 0 |
| icf | 1 |
See C.5.1.2 for a complete description of the block interleaving
process used by the various burst waveforms.
The interleaver fetch process removes 4 coded bits at a time from
the interleaver matrix. These 4 coded bits are mapped into a 16-tribit
sequence using the mapping given in table C-VIII. Note that each
of the four-bit sequences in the Coded Bits column of the
table is of the form b3b2b1b0,
where b3 is the first
bit fetched from the interleaver matrix. The tribit values are
placed in the output tribit sequence in the order in which they
appear in the corresponding row of table C-VIII, moving from left
to right across the row. The 16-tribit sequence thus obtained
is repeated 4 times to obtain a 64-tribit sequence. This process
repeats for a total of 36 iterations to produce 2304 raw tribit
values.
A sequence of 2304 pseudo-random tribit values si is generated by repeating the 64-tribit sequence presented in table C-XIII, 2304 / 64 = 36 times. The tribit values are used in the order shown in table C-XIII, starting at the top left and moving from left to right across each row, and from top to bottom through successive rows.
0,2,4,3, 3,6,4,5, 7,6,7,0, 5,5,4,3, 5,4,3,7, 0,7,6,2, 6,2,4,6, 7,2,4,7,
5,5,7,0, 7,3,3,3, 7,3,3,1, 4,2,3,7, 0,2,7,7, 3,5,1,0, 1,4,0,5, 0,0,0,0
The 2304 tribit values si of the PN sequence
are then combined with the 2304 raw tribit values ri
produced by the orthogonal symbol formation process described
in the previous section. Each symbol of the PN sequence si
is combined with the corresponding symbol ri
of the raw tribit sequence to form a channel symbol ci,
by adding si to ri
modulo 8. For instance, if si
= 7, ri = 4, then ci = 7 
4
= 3, where the symbol 
represents modulo-8
addition.
The process can be summarized:
where r is the vector of data raw tribit values, s
is the vector of PN sequence tribit values, c is the resulting
vector of combined tribit values, and the symbol 
represents component-wise modulo-8 addition.
The sequence of channel symbols consisting of
is used to PSK modulate an 1800 Hz carrier signal at 2400 channel symbols/sec.
See C.5.1.8 for a description of how the channel symbol values
are mapped to carrier phases and the subsequent carrier modulation
process.
Burst Waveform 2 (BW2) is used for transfers of traffic data by
the HDL protocol. Figure C-9 summarizes the structure and timing
characteristics of the BW2 waveform.
BW2 is used to transmit a sequence of data packets from a transmitting
station to a receiving station, where a data packet is defined
as a fixed-length sequence of precisely 1913 data bits. The HDL
protocol process (described in C.5.2) causes BW2 to modulate a
Forward Transmission containing a sequence of data packets by
invoking the BW2_Send primitive. The BW2_Send primitive has two
parameters:
C.5.2 describes the manner in which the HDL protocol determines
the values assigned to these parameters.
The total duration of the Forward Transmission phase of the HDL
protocol is 0.64 + (0.40 * NumPKTs) seconds, and includes a constant-length
portion and a variable-length portion. The constant-length portion
has a fixed duration of 0.64 seconds (TFORWARD - TDATA),
which includes:
The variable-length portion has a duration (TDATA)
of 400 * NumPKTs milliseconds (equal to 960 * NumPKTs PSK symbol
times).
The BW2 modulation process uses a count variable, FTcount, to
keep track of how many Forward Transmissions have occurred in
transmitting the current datagram. At the start of each Forward
Transmission, FTcount is initialized to zero if and only if the
reset parameter of the current invocation of BW2_Send is TRUE.
At the end of each Forward Transmission, FTcount is incremented.
The value of FTcount is used in FEC encoding (as described in
C.5.1.5.5), in rotating the modulation symbols containing FEC-coded
data (as described in C.5.1.5.8), and in generating the spreading
symbol sequence used to PN-spread the BW2 gray-coded modulation
symbols (as described in C.5.1.5.8).
The subsections of this describe the manner in which the values
of the symbols in the TLC/AGC guard sequence, the preamble sequence,
and the variable-length data portion of each Forward Transmission
are determined, and then describe the manner in which the resulting
symbol sequence is PN-spread and modulated.
The TLC/AGC guard sequence portion of the BW2 waveform provides
an opportunity for both the transmitting radio's Transmit Level
Control process (TLC) and the receiving radio's Automatic Gain
Control process (AGC) to reach steady states before the BW2 preamble
appears at their respective inputs, minimizing the distortion
to which the preamble can be subjected by these processes. The
BW2 TLC/AGC guard sequence is composed of the first 240 of the
pseudo-random tribit symbol values shown in table C-X. The tribit
symbols are transmitted in the order shown in table C-X, starting
at the top left and moving from left to right across each row,
and from top to bottom through successive rows.
For convenience of implementation, the length of the TLC/AGC guard
sequence (240 PSK symbols) has been chosen so as to be an integral
multiple of the length of an unknown/known symbol frame as described
in C.5.1.5.7.
The TLC/AGC guard sequence symbols are modulated directly as described
in C.5.1.5.9, without undergoing PN spreading as described in
C.5.1.5.8.
The BW2 acquisition preamble is a sequence of 64 tribit symbols
all having values of zero (000). The BW2 acquisition preamble
symbols undergo PN spreading as described in C.5.1.5.8; the PN-spread
preamble symbols are then modulated as described in C.5.1.5.9.
A 32-bit Cyclic Redundancy Check (CRC) value is computed across
the 1881 payload data bits in each data packet, and is then appended
to the data packet. The generator polynomial used in computing
the CRC is:
Other details of the CRC computation procedure are as defined
in C.4.1.
As is shown in figure C-10, seven encoder flush bits with values
of zero are appended to the 1913 payload and CRC bits of each
data packet to produce an extended data packet, known henceforth
as an 'EDataPkt' (i.e., an "Extended Data Packet").
Note that the further processing (FEC, symbol formation, and
frame formation) of each EDataPKT is not affected by the presence
of the CRC and flush bits in the EDataPKT; in these processes,
each EDataPKT is treated as an arbitrary sequence of 1920 bits.
As described below, each 1920-bit EDataPKT is transformed into
20 frames of 48 PSK symbols each. Each of the 32 known 8-PSK
symbols in a frame carries three data bits, so that each frame
carries 96 of the 1920 bits in an EDataPKT.
The 1920 bits in each EDataPkt are convolutionally encoded using
the rate 1/4, constraint length 8, non-systematic convolutional
encoder shown in figure C-11. The encoder produces 4 encoded
bits: Bitout0, Bitout1, Bitout2,
and Bitout3, for each single input bit. As each EDataPkt
is encoded, the coded bits from each of the four coded bit streams
are accumulated into a block of 1920 coded bits. This produces
a total of four Encoded Blocks of 1920 bits each (EBlk0
through EBlk3, where each EBlkk is composed
solely of output bits from Bitoutk.). Only one of
the four Encoded Blocks resulting from the encoding of each EDataPkt
is transmitted in each Forward Transmission. Which of the four
Encoded Blocks is transmitted is determined by the value of the
BW2 modulation process's FTcount variable: the Encoded Block transmitted
is EBlkn (containing coded data bits from Bitoutn),
where n = FTcount mod 4. For instance, the sixth Forward Transmission
of a datagram contains EBlk1 (since FTcount = 5 and
5 mod 4 = 1) for every EDataPkt in the Forward Transmission.
Each successive retransmission of a EDataPkt contains a different
Encoded Block derived from the EDataPkt contents, providing the
decoder at the remote station with additional information as to
the contents of the EDataPkt.
The seven zeroes in the Encoder Flush field at the end of each
EDataPkt return the convolutional encoder to its initial (all-zero)
state before it starts to encode the contents of the next EDataPkt.
Once the NumPKTs encoded blocks for each forward transmission
have been produced, the contents of the encoded blocks are formed
into three-bit modulation symbols. Each modulation symbol is
formed by taking three bits one at a time from the current Encoded
Block, starting with the first bit of the first Encoded Block,
and shifting them successively into the modulation symbol's least
significant bit-position (so that the first bit of the three is
eventually placed in the most significant bit-position). This
continues until 1920/3 = 640 modulation symbols have been formed
for each Encoded Block.
The modulation symbols for all Encoded Blocks are then rotated
toward the least significant bit-position (so that M2M1M0
becomes M0M2M1), FTcount mod
3 times. This causes each successive transmission of an Encoded
Block to have its data contents mapped onto different modulation
symbol values. After this rotation has been performed, the rotated
modulation symbols are gray-coded as shown in table C-XIV, yielding
a sequence of gray-coded modulation symbols.
|
|
Once the NumPKTs Encoded Blocks have been formed into modulation
symbols, rotated, and gray-coded, the resulting gray-coded modulation
symbols are formed into Frames. Each Frame (as shown on figure
C-9) is formed by taking the next 32 consecutive gray-coded modulation
symbols (known as "unknown symbols" because they contain
coded payload data not known a priori) from the sequence produced
as described in the previous section, and appending to them 16
known symbols having symbol values equal to zero (000). The 640
gray-coded modulation symbols for each Encoded Block are incorporated
into the unknown sections of 20 Frames (since 640/32 = 20). For
a Forward Transmission containing NumPKTs EDataPkts, there will
therefore be (20 * NumPKTs) Frames, each containing 32 gray-coded
modulation symbols (unknown symbols) derived from encoded payload
data, followed by 16 known symbols having values of zero.
The length 216-1 Maximum-Length Sequence Generator
shown in figure C-12 is used to PN-spread the sequence of modulation
symbols (tribits) consisting of the 64 symbols of the BW2 acquisition
preamble described by C.5.1.5.2, followed by the (960 * NumPKTs)
gray-coded modulation symbols generated as described in sections
C.5.1.5.3 through C.5.1.5.7.
The Forward Transmission count variable FTcount (described in
C.5.1.5) is used in initializing the state of the sequence generator:
at the start of each Forward Transmission, the state of the generator
is initialized to (0xAB91 + FTcount) mod 0x 10000.
The outputs of the sequence generator are used to PN-spread the modulation symbols as follows:
This is performed for each of the 64 preamble symbols and each
of the (960 * NumPKTs) gray-coded modulation symbols. Note that
since all of the preamble symbols and the known modulation symbols
were filled with zero values (000), and the Gray-coding of zero
yields zero, the preamble channel symbols and the known channel
symbols actually contain the spreading symbols.
The sequence of channel symbols consisting of:
is used to PSK modulate an 1800 Hz carrier signal at 2400 channel symbols/sec.
See C.5.1.8 for a description of how the channel symbol values
are mapped to carrier phases and the subsequent carrier modulation
process.
Burst Waveform 3 (BW3) is used for transfers of traffic data by
the LDL protocol. Figure C-13 summarizes the structure and timing
characteristics of the BW3 waveform.
BW3 is used to transmit a single data packet from a transmitting station to a receiving station, where a data packet is defined as a fixed-length sequence of 537, 1049, 2073, or 4121 bits. The number of bits in a BW3 data packet is of the form 8n+25, where n = 64, 128, 256, or 512. The value 'n' used throughout this section refers to the number of payload data bytes (or octets) carried by each LDL protocol forward transmission; the additional 25 bits of payload in each BW3 transmission are LDL overhead. BW3 is used only to
deliver forward transmissions of the LDL protocol described in
C.5.5.
The LDL protocol process causes the generation of a BW3 waveform by invoking the BW3_Send primitive. The BW3_Send primitive has two parameters:
C.5.5 describes the manner in which the LDL protocol determines
the values assigned to these parameters.
Tp = 266.67 milliseconds: 640 PSK symbols at 2400 symbols/second
Td = 106.67 + (n*13.33) milliseconds: 32n + 256 PSK symbols at 2400 symbols/second, where
n = 64, 128, 256, or 512.
TBW3_tx = 373.33 + (n*13.33) milliseconds; i.e., approximately 1.227, 2.080, 3.787, or 7.200 seconds
The BW3 modulation process maintains a count variable, FTcount,
to keep track of how many forward transmissions have occurred
in transmitting the current datagram. FTcount is initialized
to zero upon reception of a BW3_Send PDU having its reset parameter
set to TRUE. At the end of each BW3 forward transmission, FTcount
is incremented by one. The value of FTcount is used in FEC encoding
as described in C.5.1.6.3.
The description of BW3 waveform generation will proceed as follows:
This portion of the burst waveform provides an opportunity for
both the transmitting radio's Transmit Level Control process (TLC)
and the receiving radio's Automatic Gain Control process (AGC)
to reach steady states, and provides an opportunity for the receiver
to detect the presence of the waveform and to estimate various
channel parameters for use in data demodulation. The preamble
component of BW3 consists of 640 tribit values each having the
value 0.
A TLC/AGC guard sequence is not provided as an explicit part of
the BW3 waveform, since the correlation-based receive processing
of the BW3 waveform is relatively insensitive to such signal perturbations
as are likely to be introduced by the TLC and AGC processes.
The duration of the BW3 preamble includes sufficient time for
preamble acquisition to be performed after the TLC and AGC processes
have settled.
A 32-bit Cyclic Redundancy Check (CRC) value is computed across
the payload data bits in the data packet, and is then appended
to the data packet. The generator polynomial used in computing
the CRC is:
Other details of the CRC computation procedure are as defined
in C.4.1.
7 flush bits having the value 0 are appended to the (8n+57) bits
of the data packet with CRC to ensure that the encoder is in the
all-zero state upon encoding the last flush bit. The data and
CRC bits and the 7 flush bits are coded using the r = 1/2, k =
7 convolutional encoder shown in C-14.
NOTE 1. Since BW3 uses a k=7 convolutional code, only 6 bits
are literally needed to flush the encoder. The seventh 'flush
bit' is added purely for convenience -- to make the number of
coded bits per BW3 transmission a multiple of four, so that each
group of four bits can then be mapped to an orthogonal symbol
as described below.
NOTE 2. The generator polynomials corresponding to Bitout0 and
Bitout1 are:
where X6 corresponds to the most recent input bit.
This encoder produces two encoded bits, Bitout0 and
Bitout1, for each single
input bit. Encoding an entire sequence of (8n+57) data and CRC
bits followed by 7 flush bits results in two encoded blocks of
(8n+64) coded bits each, EBlk0 and EBlk1,
where each EBlkk is made up solely of output bits from
Bitoutk. In each forward transmission, only coded
bits from EBlk(FTcount mod 2) are passed forward
to the interleaving process, where FTcount is the forward transmission
count variable described in C.5.1.6; the encoded bits from the
other encoded block are retained to possibly be transmitted in
one or more subsequent forward transmissions. For instance, the
fourth forward transmission of a data packet contains the coded
bits from EBlk1 (since FTcount = 3 and 3 mod 2 = 1).
See C.5.1.2 for a description of the interleaving process. The
interleaver parameters for BW3 depend on the value n (which
determines the BW3 payload size), as shown in table C-XV.
The interleaver fetch process removes 4 coded bits at a time from
the interleaver matrix. These 4 coded bits are mapped into a 16-tribit
sequence using the mapping given in tabel C-VIII. Note that each
of the four-bit sequences in the Coded Bits column of the
table is of the form b3b2b1b0,
where b3 is the first
bit fetched from the interleaver matrix. The tribit values are
placed in the output tribit sequence in the order in which they
appear in the corresponding row of table C-VIII, moving from left
to right across the row. This process repeats for a total of
2n+16 iterations to produce the 32n+256 raw tribit values of the
data portion of BW3.
A sequence of 32n+896 pseudo-random tribit values si
is generated by repeating the 32-tribit sequence presented in
table C-XVI, (32n+896) / 32 = n+28 times. The tribit values are
used in the order shown in table C-XVI, starting at the top left
and moving from left to right across each row, and from top to
bottom through successive rows.
0,0,0,0, 0,2,4,6, 0,4,0,4, 0,6,4,2,
0,0,0,0, 1,3,5,7, 2,6,2,6,
3,1,7,5
A sequence of 32n+896 raw tribit values ri is
then composed by concatenating the 640 tribit values of the preamble
(described in C.5.1.6.1) with the 32n+256 tribit values of the
data portion of the BW3 waveform.
The 32n+896 tribit values of the PN sequence are then combined
with the raw tribit values. Each symbol of the PN sequence si
is combined with the corresponding symbol ri
of the raw tribit (preamble+data) sequence to form a channel symbol
ci, by adding si to ri
modulo 8. For instance, if si
= 7, ri = 4, then ci = 7 
4
= 3, where the symbol 
represents modulo-8
addition.
The process can be summarized:
where rp is the vector of preamble raw tribit
values, rd is the vector of data raw tribit
values, s is the vector of PN sequence tribit values, c
is the resulting vector of combined tribit values, and the symbol
represents component-wise modulo-8 addition.
See C.5.1.8 for a description of how combined tribit values are
mapped to carrier phases and the subsequent carrier modulation
process.
Burst Waveform 4 (BW4) is used to convey the LDL protocol's LDL_ACK
PDU. Figure C-15 summarizes the structure and timing characteristics
of the BW4 waveform.
A user process (the LDL protocol) causes the generation of a BW4
waveform by issuing a BW4_Send primitive. The BW4_Send primitive
has one parameter:
C.5.5 describes the manner in which values are assigned to the
payload parameter.
Ttlc = 106.666 milliseconds: 256 PSK symbols at 2400 symbols/second
Tdata = 533.333 milliseconds: 1280 PSK symbols at 2400 symbols/second
TBW4_tx = 640.0 milliseconds
The description of the BW4 waveform generation will proceed as follows:
The TLC/AGC guard sequence portion of the BW4 waveform provides
an opportunity for both the transmitting radio's Transmit Level
Control process (TLC) and the receiving radio's Automatic Gain
Control process (AGC) to reach steady states before the BW4 preamble
appears at their respective inputs, minimizing the distortion
to which the preamble can be subjected by these processes. The
TLC/AGC guard sequence is a sequence of 256 pseudo-random tribit
symbols having the values shown in table C-X. The tribit symbols
are transmitted in the order shown in table C-X, starting at the
top left and moving from left to right across each row, and from
top to bottom through successive rows.
The TLC/AGC guard sequence symbols are modulated directly as described
in C.5.1.7.4, without undergoing PN spreading as described in
C.5.1.7.3.
BW4 carries a payload of two protocol bits. The two protocol bits
are mapped into a 16-tribit sequence using the mapping given in
C-XVII. Note that each of the two-bit sequences in the Payload
Bits column of the table is of the form b1b0,
where b1 is the first
payload bit. The tribit values are placed in the output tribit
sequence in the order in which they appear in the corresponding
row of table C-XVII, moving from left to right across the row.
The 16-tribit sequence thus obtained is repeated 80 times to
produce 1280 tribit values.
| Payload Bits
(shown as b1b0) | Tribit Sequence |
| 00 | 0000 0000 0000 0000 |
| 01 | 0404 0404 0404 0404 |
| 10 | 0044 0044 0044 0044 |
| 11 | 0440 0440 0440 0440 |
A sequence of 1280 pseudo-random tribit values si
is generated by repeating the 256-tribit sequence presented in
table C-XVIII, 1280 / 256 = 5 times. The tribit values are used
in the order shown in table C-XVIII, starting at the top left
and moving from left to right across each row, and from top to
bottom through successive rows.
0,2,4,3, 3,6,4,5, 7,6,7,0, 5,5,4,3, 5,4,3,7, 0,7,6,2, 6,2,4,6, 7,2,4,7,
5,5,7,0, 7,3,3,3, 7,3,3,1,
4,2,3,7, 0,2,7,7, 3,5,1,0, 1,4,0,5, 0,0,0,0,
7,5,1,4, 5,4,2,0, 6,1,4,7, 5,0,1,0, 3,0,3,1, 3,5,1,2, 5,0,1,7, 1,4,6,0,
2,3,3,4, 2,5,2,5, 4,5,7,3,
1,0,1,6, 4,1,1,2, 1,4,1,5, 4,2,7,4, 5,1,6,4,
6,3,6,4, 5,0,3,6, 4,0,1,6, 3,3,5,7, 0,5,7,7, 2,5,2,7, 7,4,7,5, 5,0,5,6,
0,2,4,3, 3,6,4,5, 7,6,7,0,
5,5,4,3, 5,4,3,7, 0,7,6,2, 6,2,4,6, 7,2,4,7,
5,5,7,0, 7,3,3,3, 7,3,3,1, 4,2,3,7, 0,2,7,7, 3,5,1,0, 1,4,0,5, 0,0,0,0,
7,5,1,4, 5,4,2,0, 6,1,4,7,
5,0,1,0, 3,0,3,1, 3,5,1,2, 5,0,1,7, 1,4,6,0
The 1280 tribit values si of the PN sequence
are then combined with the 1280 raw tribit values ri
produced by the orthogonal symbol formation process described
in the previous section. Each symbol of the PN sequence si
is combined with the corresponding symbol ri
of the raw tribit sequence to form a channel symbol ci,
by adding si to ri
modulo 8. For instance, if si
= 7, ri = 4, then ci = 7 
4
= 3, where the symbol 
represents modulo-8
addition.
The process can be summarized:
where r is the vector of data raw tribit values, s
is the vector of PN sequence tribit values, c is the resulting
vector of combined tribit values, and the symbol 
represents component-wise modulo-8 addition.
The sequence of channel symbols consisting of:
is used to PSK modulate an 1800 Hz carrier signal at 2400 channel symbols/sec.
See C.5.1.8 for a description of how combined tribit values are
mapped to carrier phases and the subsequent carrier modulation
process.
The burst waveform descriptions have thus far only discussed the
mapping of protocol bits to tribit values. This section will describe
the process by which the tribit values are used to create the
transmitted signal.
The transmitted signal consists of a 8-ary phase-shift-keyed 1800Hz
single-tone carrier modulated at a constant 2400 symbols per second.
The phase shift of the signal relative to that of the unmodulated
carrier is a function of the tribit values as given in the tribit-value-to-carrier-phase
mapping of table C-XIX:
|
|
| |
 1.0 | |||
 /4 |    |    | |
 /2 | |||
 /4 |    |    | |
 | |||
 /4 |    |    | |
 /2 | |||
 /4 |    |    |
The transmitted waveform is generated as illustrated in C-16.
The tribit values are converted to the complex 8-PSK resulting
in separate In-Phase [I] and Quadrature [Q] waveforms as given
in C-XIX. These waveforms are interpolated and independently
filtered by equivalent low pass filters to provide spectral containment
and image rejection. Finally the interpolated and filtered In-phase
and Quadrature waveforms are used to modulate the 1800 Hz sub-carrier.
The accuracy of the clock linked with the generation of the sub-carrier
frequency is 1 part in 105.
3G-ALE shall be implemented as defined in the following paragraphs.
Table C-XX describes an example set of service primitives exchanged
between the 3G-ALE entity and a user process at the 3G-ALE entity
upper interface. Note that there is no requirement that implementations
of 3G-ALE contain precisely these service primitives; nor are
the service primitives defined below necessarily all of the service
primitives that would be required in an implementation of this
protocol.
| LE_Link_Req | Overview | LE_Link_Req: issued by ALE user process (usually connection manager) to request establishment of a link | |
| Parameters | destAddr | 11-bit 3G address of the station to be called | |
| callType | one of INDIVIDUAL, UNICAST, MULTICAST, BROADCAST | ||
| trafType | Identifies the type of traffic for which the link is requested; one of: Packet Data, Modem Circuit (for HF data modems only), Voice Circuit (for analog voice or non-HF modems), High-Quality Circuit | ||
| pri | Priority of the traffic for which the link is requested; one of Highest, High, Routine, Low | ||
| callChan | Optional calling channel number (for override) | ||
| trafChan | Optional traffic channel number (for override) | ||
| Originator | user process | ||
| Preconditions | none | ||
| LE_Link_Ind | Overview | LE_Link_Ind: issued by ALE process to indicate the establishment of link as responder | |
| Parameters | addr | 11-bit 3G address of the station or multicast to which link has been established | |
| callType | Identifies the type of link that has been established; same values as above | ||
| Originator | ALE entity | ||
| Preconditions | none | ||
| LE_Link_Confirm | Overview | LE_Link_Confirm: issued by ALE process to indicate establishment of link as caller | |
| Parameters | addr | 11-bit 3G address of the station or multicast to which link has been established | |
| Originator | ALE entity | ||
| Preconditions | link has been requested or established | ||
| LE_Status_Ind | Overview | LE_Status_Ind: issued by ALE process to indicate its current status | |
| Parameters | status | Current ALE status; one of: SCANNING, CALLING, LINKED | |
| Originator | ALE entity | ||
| Preconditions | none | ||
| LE_Link_Det_Ind | Overview | LE_Link_Det_Ind: issued by ALE process to report detection of the establishment or termination of a link between remote stations | |
| Parameters | status | One of LINKED, AVAILABLE | |
| trafChan | Traffic channel used by link |
| caller | 11-bit 3G address of the calling station | ||
| responder | 11-bit 3G address of the responding station | ||
| Originator | ALE entity | ||
| Preconditions | none | ||
| LE_Link_Fail_Ind | Overview | LE_Link_Fail_Ind: issued by ALE process to indicate the failure of a link | |
| Parameters | reason | Reason for link failure; one of: NO_RESPONSE, REJECTED, NO_TRAF_CHAN, LOW_QUALITY | |
| Originator | ALE entity | ||
| Preconditions | link has been requested or established | ||
| LE_ReturnToScan | Overview | LE_ReturnToScan: issued by user process to request termination of link and return to scanning operation; also used to reject an incoming link | |
| Parameters | none | ||
| Originator | user process | ||
| Preconditions | link has been requested or established | ||
| LE_McastUpdate | Overview | LE_McastUpdate: issued by user process to add or delete a dwell group from a multicast | |
| Parameters | multicast | affected multicast address (same address used as member number in calls to all dwell groups) | |
| group | affected dwell group number | ||
| status | one of: INCLUDED, EXCLUDED | ||
| Originator | user process | ||
| Preconditions | none | ||
The link establishment protocol data units (LE-PDUs) are shown
in figure C-17. Unused encodings are reserved, and shall not
be used until standardized. Order of transmission shall be as
specified in C.4.10 Order of transmission. For
example, the LE_Broadcast PDU shall begin 0, 1, 1, 1 , 0.
The LE_Call PDU shall be formatted as shown in figure C-17. It
conveys necessary information to the responder so that that station
will know whether to respond, and what quality of traffic channel
will be needed.
The Call Type field in the LE_Call PDU shall be encoded as specified in table C-XXI.
| 3G ARQ Packet Data | Responder | |
| HF Modem Circuit | Responder | |
| Analog Voice Circuit | Responder | |
| High-Quality Circuit | Responder | |
| Unicast ARQ Packet | Caller | |
| Unicast Circuit | Caller | |
| Multicast Circuit | Caller | |
| Control | Caller |
The LE_Handshake PDU shall be formatted as shown in figure C-17.
The link ID shall be computed as follows from the 11-bit addresses
of the caller (node sending LE_Call PDU) and responder (node addressed
in LE_Call PDU):
where '*' indicates 32-bit unsigned multiplication, '>>
n' indicates right shift by n bits, and '&' indicates bitwise
AND. Example LinkID computations are shown below.
The Command field shall be encoded as shown in table C-XXII.
Unused encodings are reserved, and shall not be used until standardized.
| Continue Handshake | The handshake will continue for at least another two-way handshake (on the next assigned called station dwell frequency when operating in synchronous mode). | ||
| Commence Traffic Setup | This is the final command sent on a calling channel. The argument is the channel number on which the responding station will (or should) listen for traffic setup. Following this command, all stations proceed to that traffic channel. | ||
| Voice Traffic | This command directs called station(s) to tune to a traffic channel and commence voice traffic. The argument is the channel number. Following this command, the calling station will be first to speak. (Uni- and multicast only) | ||
| Link Release | This command informs all listening stations that the specified traffic channel is no longer in use by the sending station. | ||
| Sync Check | This command directs the called station to measure and report synchronization offset back to the calling station. Used in synchronization management protocol (C.5.2.7). | ||
| Data | This command is reserved for special-purpose protocols. The argument carries previously requested data. | ||
| Abort Handshake | This command immediately terminates the handshake and needs no response. It is analogous to the TWAS preamble in 2G ALE. |
The Argument field shall contain a channel number, a reason code,
or 7 bits of data, as indicated in table C-XXII. Reasons shall
be encoded as 7-bit integers with values selected from table
C-XXIII. Unused encodings are reserved, and shall not be used
until standardized.
| NO_RESPONSE | |
| REJECTED | |
| NO_TRAF_CHAN | |
| LOW_QUALITY |
The LE_Notification PDU shall be formatted as shown in figure
C-17, and shall be used as specified in C.5.2.5 Notification
Protocol Behavior. The Caller Member Number and Caller
Group Number fields shall contain the address of the station sending
the PDU. The Caller Status field shall be encoded as shown in
table C-XXIV. Unused encodings are reserved, and shall not be
used until standardized.
| Nominal | |
| Time server | |
| Commencing EMCON | |
| Leaving network |
The LE_Broadcast PDU shall be formatted as shown in figure C-17, and shall be used as specified in C.5.2.4.4.5 3G-ALE synchronous mode broadcast calling.
The Call Type field shall describe the traffic to be sent:
The Countdown field shall be used as specified in C.5.2.4.4.5
3G-ALE synchronous mode broadcast
calling and in C.5.2.4.5.6 3G-ALE asynchronous
mode broadcast call.
The LE_Scanning_Call PDU shall be formatted as shown in figure
C-17, and shall be used as specified in C.5.2.4.5.2 3G-ALE
asynchronous mode scanning call.
Each LE_PDU contains either a 4-bit or an 8-bit CRC. The 4-bit
CRC shall be computed in accordance with C.4.12 using the polynomial
x4 + x3 + x + 1. The 8-bit CRC shall be
computed in accordance with C.4.12 using the polynomial x8
+ x7 + x4 + x3 + x + 1.
When scanning in synchronous mode, 3G systems shall dwell on each
assigned channel for 4 seconds. Each synchronous dwell time is
divided into five slots of 800 ms each, which shall be used as
follows (see figure C-18).
Slot 0: Tune and Listen Time. During Slot 0, radio frequency (RF) components shall be retuned to the frequency on which the node may transmit during that dwell.
Following tuning, every receiver shall sample a traffic frequency
in the vicinity of the new calling channel, attempting to detect
traffic. (This provides recent traffic channel status before stations
get involved in a handshake.)
Calling Slots. The remainder of the dwell time is divided
into four 800 ms calling slots. These slots shall be used for
the synchronous exchange of PDUs on calling channels. A two-way
handshake shall not begin in the last slot of a dwell. The last
slot of every dwell is reserved for LE_Handshake, LE_Notification,
and LE_Broadcast PDUs.
The behavior of the 3G-ALE protocol is specified in the following
paragraphs in terms of data structures, states, events, actions,
and state transitions. Note that these data structures, states,
events, actions, and state transitions are not requirements of
a compliant implementation, but only serve to illustrate the required
over-the-air behavior of compliant systems. The data structures,
events, and actions are listed in a single set of tables, which
are used by both the synchronous-mode and asynchronous-mode protocol
definitions. Separate behavior tables are specified for the two
modes.
The internal variables used in the description of the 3G-ALE protocol
are defined in table
C-XXV. These are for illustrative use only, and are not mandatory
in implementations of 3G-ALE except as required elsewhere.
| myIndivAddr | 11-bit address of this station |
| myMulticastAddresses | list of 11-bit addresses for multicasts to which this station subscribes |
| networkTime | coordinated network time (may be synchronized to UTC or GPS) |
| myCurrentDwellChannel | calling channel on which this station listens for calls |
| myCurrentTrafficChannel | traffic channel on which this station monitors occupancy |
| channelOccupancy | array of channel occupancy records: result, time measured |
| callingChannel | current dwell channel of destination station |
| destStation | ID of destination station (indiv, mcast, or bcast) |
| linkID | Link ID value computed for current handshake |
| linkQualityTable | array of link quality records for all stations and channels |
| prefTrafChan | preferred traffic channel for current handshake partner |
| myCallingSlot | slot in which call will be sent |
| bcastCount | LE_Broadcast PDU countdown (use varies between sync and async modes) |
| announcedBroadcastChannel | channel specified in LE_Broadcast PDU |
| numScanChan | number of calling channels in scan list |
| scanCallCountdown | number of times LE_Scanning_Call PDU is sent |
| scanSoundCountdown | number of times LE_Notification PDU is sent when sounding |
| trafWaitTime | time called station will wait for traffic to start after link is established |
| trafWaitTimeMcast | time called station will wait for traffic to start after link is established
(longer time allowed for multicasts) |
Table C-XXVI defines the events to which the 3G-ALE entity responds.
The event names are used in the state transition tables in C.5.2.4.4.7
and C.5.2.4.5.9 which define the behavior of the 3G-ALE protocol.
| End of dwell | A boundary between dwells has occurred |
| TuningComplete | Tuning has been completed in all RF components |
| FinishedListening | The occupancy check of a channel has been completed |
| D: LE_Link_Req(destAddr,
callType, pri, [chan]) | An LE_Link_Req primitive was received from the user process (Connection Manager); chan is optional |
| D: LE_ReturnToScan | An LE_ReturnToScan primitive was received from the user process
(Connection Manager) |
| R: LE_Call(destAddr, srcAddr, callType) | received an LE_Call PDU |
| R: LE_ScanCall(destAddr) | received an LE_Scanning_Call PDU for indicated destination address |
| R: LE_Hshake(ID, CMD, ARG) | received an LE_Handshake PDU |
| R: LE_Bcast(countdown,
callType, chan) | received an LE_Broadcast PDU |
| FinishedSendingPDU | occurs at end of slot (synchronous mode) or end of PDU (asynchronous mode) |
| SlotAvailable | Occupancy check of preceding slot(s) and analysis of any received PDUs
indicates that no handshake in progress will extend into the slot now beginning |
| SlotOccupied | Occupancy check of preceding slot(s) and analysis of any received PDUs
indicates that a handshake in progress will extend into the slot now beginning |
| ResponseTimeout | No response arrived within the timeout previously set |
| ScanCallTimeout | End of scanning call did not occur within allowed timeout |
| ScanCallDropout | Unable to identify BW0 preamble for three consecutive PDUs during scanning
call timeout period |
| TrafWaitTimout | Traffic did not begin within the timeout previously set |
| TimeToSound(channel) | Time to sound on indicated channel |
Table C-XXVII defines the actions which the 3G-ALE entity can
perform. The action name is used in the state transition tables
used below to define the behavior of the 3G-ALE protocol.
| ComputeDwellChannel(addr) | Computes the current dwell channel for specified station at current
networkTime |
| SelectCallingChannel(addr) | Selects calling channel for best estimated connectivity to individual station
using linkQualityTable (async mode only) |
| SelectMulticastChannels(addr) | Selects calling and traffic channels for best estimated connectivity to
multicast subscribers using linkQualityTable |
| SelectBroadcastChannels | Selects calling and traffic channels for best estimated connectivity to network
members using linkQualityTable |
| InitBroadcastCount | Initializes broadcastCount to number of times LE_Broadcast PDU will be sent |
| InitBcastCountdown(number) | Sets broadcastCount to number |
| TuneToNewChannel(chan) | Retune transceiver, PA, coupler, etc to specified channel; TuningComplete
event when done |
| SelectTrafficChannel(chan) | Selects a traffic channel "near" specified channel, considering age of channel
measurements |
| ListenOnChannel(chan) | Listen for occupancy on specified channel; FinishedListening event after
preset interval |
| RecordOccupancy(chan) | store results of listening on chan in channelOccupancy array |
| ListenForCalls(chan) | Listen for 2G and 3G calls on specified channel; EndOfDwell event at end of
current dwell |
| SelectSlot(pri) | Compute myCallingSlot using pri |
| WaitForSlot(slot) | Listens on myCurrentTrafficChannel until end of slot-1; SlotAvailable event if channel believed vacant, otherwise SlotOccupied (or R: xxx) event |
| U: LE_Link_Ind(callerAddr,
callType) | Inform user process (Connection Manager) that a link has been established by a calling station |
| U: LE_Link_Confirm(destAddr) | Inform user process that link has been established to destAddr |
| U: LE_Status_Ind(status) | Inform user process (Connection Manager) of ALE status |
| U: LE_Link_Det_Ind(status,
trafChan, caller, dest) | Inform user process that a change in link status between caller and dest has been detected (link established or terminated) |
| U: LE_Link_Fail_Ind(reason) | Inform user process (Connection Manager) that link has failed |
| S: LE_Call(destAddr, srcAddr,
trafType, pri) | Send an LE_Call PDU |
| S: LE_Bcast(countdown, trafType,
pri, chan) | Send an LE_Broadcast PDU |
| S: LE_Hshake(ID, CMD, ARG) | Send an LE_Handshake PDU |
| InitResponseTimeout | Set timeout for end of next slot |
| InitScanCallTimeout | Set timeout for maximum allowed scanning call duration |
| RestartSoundingTimer(chan, time) | Set timer to prompt next sound on channel |
| InitAsyncCount | Initialize asynchronous-mode broadcast countdown |
| InitTrafWaitTimeout(time) | Set timeout (trafWaitTime or trafWaitTimeMcast) to bound time waiting for
traffic to start |
The synchronous-mode link establishment protocol shall comply
with the following requirements as observed over the air. Precise
definitions of the protocols are presented following overviews
of the individual, multicast, and broadcast calling protocols.
The probability of selecting a slot for sending an LE_Call, LE_Broadcast,
or LE_Notification PDU shall randomized over all usable slots,
but the probabilities for higher-priority calls shall be skewed
toward the early slots while lower-priority calls are skewed toward
the later slots. (Such a scheme will operate reasonably well in
all situations, while hard partitioning of early slots for high
and late slots for low priorities would exhibit inordinate congestion
in crisis and/or routine times.) Suggested sets of probabilities
are shown in table C-XXVIIIa for LE_Call PDUs and table C-XXVIIIb
for LE_Broadcast and LE_Notification PDUs.
| Highest | |||
| High | |||
| Routine | |||
| Low |
| Highest | ||||
| High | ||||
| Routine | ||||
| Low | ||||
A new random slot shall be selected for each dwell in which a
call will be placed. Random number generation for slot selection
shall be essentially independent from one dwell to the next, and
among different stations, so that systems that select the same
slot in one dwell will not have a higher than expected probability
of continuing to select identical slots in subsequent dwells.
The one-to-one linking protocol identifies a frequency for traffic
use relatively quickly (i.e., within a few seconds), and minimizes
channel occupancy during this link establishment process. A station
shall commence the link establishment protocol immediately upon
receiving a request to establish a link with another station,
unless it defers the start of calling until the called station
will be listening on a channel believed to be propagating. The
latter option serves to reduce channel occupancy, and does not
preclude calling on the bypassed channels later if the link cannot
be established on the favored channel.
When a station needs to establish a link with another station, it shall send LE_Call PDUs on the frequencies monitored by the called station until it receives a response, or until it has called on all calling channels at least once. The Call Type in the LE_Call PDU shall not be Unicast or Multicast in the individual calling protocol. In each dwell, the calling station shall do the following:
A station that receives an LE_Call PDU addressed to its node address
shall respond in the immediately following slot with an LE_Handshake
PDU that either aborts the call, names a traffic channel, or defers
naming a channel but continues the handshake. When a suitable
frequency for traffic to the responding station has been found,
the stations shall enter the Traffic state. If additional negotiation
is required (e.g., to set up a full duplex circuit using a second
frequency), the ALM protocol shall be employed on the traffic
channel.
A unicast call is used to contact an individual station and direct it to a traffic channel selected by the calling station.
Note that a unicast call may be used to set up a link for bidirectional
traffic.
A multicast call is used to contact selected stations concurrently
and direct them to a traffic channel selected by the calling station.
An LE_Broadcast PDU directs every station that receives it to
a particular traffic channel, where another protocol (possibly
voice) will be used. A means shall be provided for operators
to disable execution of the broadcast protocol.
Slot selection for LE_Broadcast PDUs shall uses the same probabilistic
approach as for LE_Call PDUs. However, a station may send an LE_Broadcast
PDU in every slot in a dwell starting with the randomly selected
slot. It may also change frequencies every slot to reach a new
dwell group. The calling station shall check occupancy on the
new calling channel before transmitting on that channel. A split-site
station with a fast tuner may be able to send an LE_Broadcast
PDU on a new channel in every slot by listening on the next channel
each time and tuning at the start of the slot. A means shall
be provided to override listen-before-transmit for highest-priority
broadcasts that will permit transmission of an LE_Broadcast PDU
on a new channel in every slot.
Stations that receive an LE_Broadcast PDU and tune to the indicated
traffic channel shall return to scan if the announced traffic
does not begin within the traffic wait timeout period after the
announced starting time of the broadcast.
At the conclusion of an individual or unicast link, the caller
shall send a link release. The link release shall be an LE_Call
PDU containing the original called station address, with a type
of Control, followed by an LE_Handshake PDU that identifies the
traffic channel and contains a link release command.
The link release shall be sent on the calling channel on which
the handshake that set up the link occurred. The calling station
shall attempt to send the link release during the first dwell
after the link is terminated during which the called dwell group
is listening on that calling channel. The calling station need
not attempt to send a link release later if calling channel occupancy
during that dwell prevents transmission of the link release.
Implementations of 3G-ALE operating in synchronous mode shall
exhibit the same over-the-air behavior as that described in table
C-XXIX.
| Scanning | End of dwell | ComputeDwellChannel(myIndivAddr) + TuneToNewChannel(myCurrentDwellChannel) | S_Tune | |||||
| D: LE_Link_Req(dest, INDIV or UCAST, trafType, pri) | ComputeDwellChannel(dest) + TuneToNewChannel(callingChannel) + SelectSlot(pri) | C_Slot_Wait | ||||||
| D: LE_Link_Req(dest, MCAST, trafType, pri) | SelectMulticastChannel(dest) + TuneToNewChannel(callingChannel) + SelectSlot(pri) | C_Slot_Wait | ||||||
| D: LE_Link_Req(dest, BCAST, trafType, pri) | SelectBroadcastChannel + InitBroadcastCount + TuneToNewChannel(callingChannel) + SelectSlot(pri) | C_Slot_Wait | ||||||
| R: LE_Call(myIndivAddr, srcAddr, callType is packet or circuit) | willing to link w/srcAddr & good traffic channel known | ComputeLinkID(srcAddr, myIndivAddr) + S:LE_Hshake(linkID, COMMENCE, prefTrafChan) | R_Commence | |||||
| not willing to link with srcAddr | ComputeLinkID(srcAddr, myIndivAddr) + S:LE_Hshake(linkID, ABORT, UNAVAILABLE) | R_Abort | ||||||
| willing to link w/srcAddr but no traffic channel known | ComputeLinkID(srcAddr, myIndivAddr) + S:LE_Hshake(linkID, CONTINUE, NO_CHANNEL) | R_Continue | ||||||
| R: LE_Call(myIndivAddr, srcAddr, UNICAST) | InitResponseTimeout | R_Unicast | ||||||
| R: LE_Call(dest, srcAddr, MULTICAST) | dest addr is in myMulticastAddresses | InitResponseTimeout | R_Multicast | |||||
| R: LE_Call(dest, srcAddr, LinkRelease) | InitResponseTimeout | R_Release | ||||||
| R: LE_Bcast(countdown, trafType, pri, chan) | broadcasts accepted | InitBcastCountdown(countdown) + broadcastPriority=pri + announcedBroadcastChannel = chan + ListenForCalls(myCurrentDwellChannel) | R_Bcast | |||||
| others | none | Scanning | ||||||
| S_Tune | TuningComplete | SelectTrafficChannel(myCurrentDwellChannel) + ListenOnChannel(myCurrentTrafficChannel) | S_Listen | |||||
| others | queue or ignore | S_Tune | ||||||
| S_Listen | FinishedListening | RecordOccupancy(myCurrentTrafficChannel) + ListenForCalls(myCurrentDwellChannel) | Scanning | |||||
| others | queue or ignore | S_Listen | ||||||
| R_Release | R: LE_Hshake(id, cmd, arg) | id is correct, cmd=LinkRelease | U: LE_Link_Det_Ind(Available, arg, srcAddr, dest) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||
| wrong id or other command | ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||
| ResponseTimeout | ListenForCalls(myCurrentDwellChannel) | Scanning | |||||||||||||||
| others | none | R_Release | |||||||||||||||
| C_Slot_Wait | TuningComplete | ListenOnChannel(myCurrentTrafficChannel) | C_Slot_Wait | ||||||||||||||
| FinishedListening | WaitForSlot(myCallingSlot) | C_Slot_Wait | |||||||||||||||
| SlotAvailable | individual call | S: LE_Call(destAddr, myIndivAddr, callType) | SEND_CALL | ||||||||||||||
| unicast or multicast call | S: LE_Call(destAddr, myIndivAddr, callType) | SEND_CALL | |||||||||||||||
| broadcast call | S: LE_Bcast(myCurrentTrafficChannel, callType) | SEND_BCAST | |||||||||||||||
| SlotOccupied | myCallingSlot < 4 | increment myCallingSlot + WaitForSlot(myCallingSlot) | C_Slot_Wait | ||||||||||||||
| myCallingSlot >= 4 | compute/select next channel + TuneToNewChannel(callingChannel) + SelectSlot(pri) | C_Slot_Wait | |||||||||||||||
| R: 2G_Call | 2G calls accepted | U: 2G_Call_Ind | Offline | ||||||||||||||
| others | queue or ignore | S_Listen | |||||||||||||||
| unicast or multicast call | ComputeLinkID(myIndivAddr, destAddr) + S:LE_Hshake(linkID, COMMENCE or VOICE, myCurrentTrafficChannel) | N_Commence | |||||||||||||||
| others | none | SEND_CALL | |||||||||||||||
| ListenFor Response | R: LE_Hshake(id, cmd, arg) | id is correct, cmd=Commence | myCurrentTrafficChannel = arg + TuneToNewChannel(myCurrentTrafficChannel) | T_Tune | |||||||||||||
| id is correct, cmd = Abort | U: LE_Link_Fail_Ind(reason = arg) | Scanning | |||||||||||||||
| wrong id or other command | ComputeNextDwellChannel(indivDest) + TuneToNewChannel(callingChannel) + SelectSlot(pri) | C_Slot_Wait | |||||||||||||||
| ResponseTimeout | ComputeNextDwellChannel(indivDest) + TuneToNewChannel(callingChannel) + SelectSlot(pri) | C_Slot_Wait | |||||||||||||||
| others | none | ListenFor Response | |||||||||||||||
| T_Tune | TuningComplete | U: LE_Link_Ind(CALLER, indivDest, trafType, pri) | LinkedAsCaller | ||||||||||||||
| others | none | T_Tune | |||||||||||||||
| N_Commence | FinishedSendingPDU | TuneToNewChannel(myCurrentTrafficChannel) | N_Tune | ||||||||||||||
| others | none | N_Commence | |||||||||||||||
| N_Tune | TuningComplete | U: LE_Link_Ind(NCS, mcastDest, trafType, pri) | LinkedOneToMany | |||||
| others | none | N_Tune | ||||||
| SEND_BCAST | FinishedSendingPDU | broadcastCount = 1 | TuneToNewChannel(myCurrentTrafficChannel) | A_Tune | ||||
| broadcastCount > 1, currentSlot<4 | TuneToNewChannel(nextCallingChannel) + decrementbroadcastCount | B_Tune | ||||||
| broadcastCount > 1, currentSlot>=4 | TuneToNewChannel(nextCallingChannel) + SelectSlot(pri) + decrement broadcastCount | C_Slot_Wait | ||||||
| others | none | SEND_BCAST | ||||||
| A_Tune | TuningComplete | U: LE_Link_Ind(NCS, Broadcast, callType) | LinkedOneToMany | |||||
| others | none | A_Tune | ||||||
| B_Tune | TuningComplete | S: LE_Bcast(myCurrentTrafficChannel, callType) | SEND_BCAST | |||||
| others | none | B_Tune | ||||||
| R_Commence | FinishedSendingPDU | TuneToNewChannel(myCurrentTrafficChannel) | R_Tune | |||||
| others | none | R_Commence | ||||||
| R_Abort | FinishedSendingPDU | none | Scanning | |||||
| others | none | R_Abort | ||||||
| R_Continue | FinishedSendingPDU | none | Scanning | |||||
| others | none | R_Continue | ||||||
| R_Unicast | R: LE_Hshake(id, cmd, arg) | id is correct, cmd = Commence or Voice | myCurrentTrafficChannel = arg + TuneToNewChannel(myCurrentTrafficChannel) | R_Tune | ||||
| wrong id or other command | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||
| ResponseTimeout | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||
| others | none | R_Unicast | ||||||
| R_Multicast | R: LE_Hshake(id, cmd, arg) | id is correct, cmd = Commence or Voice | myCurrentTrafficChannel = arg + TuneToNewChannel(myCurrentTrafficChannel) | M_Tune | ||||
| wrong id or other command | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||
| ResponseTimeout | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||
| others | none | R_Multicast | |||||||||
| R_Bcast | EndOfDwell | broadcastCount = 1 | TuneToNewChannel( announcedBroadcastChannel) | M_Tune | |||||||
| broadcastCount > 1 | ComputeDwellChannel(myIndivAddr) + TuneToNewChannel(myCurrentDwellChannel) + decrementbroadcastCount | R_Bcast | |||||||||
| TuningComplete | SelectTrafficChannel(myCurrentDwellChannel) + ListenOnChannel(myCurrentTrafficChannel) | R_Bcast | |||||||||
| FinishedListening | RecordOccupancy(myCurrentTrafficChannel) | R_Bcast | |||||||||
| R: 2G_Call | 2G calls accepted | U: 2G_Call_Ind | Offline | ||||||||
| others | none | R_Bcast | |||||||||
| R_Tune | TuningComplete | U: LE_Link_Ind(RESPONDER, srcAddr, callType) + InitTrafWaitTimeout(trafWaitTime) | LinkedAsResponder | ||||||||
| others | none | R_Tune | |||||||||
| M_Tune | TuningComplete | U: LE_Link_Ind(MEMBER, srcAddr, callType) + InitTrafWaitTimeout(trafWaitTimeMcast) | LinkedOneOfMany | ||||||||
| others | none | M_Tune | |||||||||
| LinkedAsCaller | D: LE_ReturnToScan | TuneToNewChannel(callingChannel) + SelectSlot(pri) | LinkReleaseWait | ||||||||
| others | none | LinkedAsCaller | |||||||||
| LinkedOneTo Many | D: LE_ReturnToScan | TuneToNewChannel(callingChannel) + SelectSlot(pri) | LinkReleaseWait | ||||||||
| others | none | LinkedOneTo Many | |||||||||
| LinkReleaseWait | EndOfDwell | dest group will dwell on callingChannel | WaitForSlot(myCallingSlot) | LinkReleaseWait | |||||||
| dest group will dwell on another channel | none | LinkReleaseWait | |||||||||
| SlotAvailable | S: LE_Call(destAddr, myIndivAddr, LinkRelease) | LinkRelease1 | |||||||||
| SlotOccupied | myCallingSlot < 4 | increment myCallingSlot + WaitForSlot(myCallingSlot) | LinkReleaseWait | ||||||||
| myCallingSlot >= 4 | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | |||||||||
| others | queue or ignore | S_Listen | |||||||||
| LinkRelease1 | FinishedSendingPDU | ComputeLinkID(myIndivAddr, destAddr) + S:LE_Hshake(linkID, LinkRelease, myCurrentTrafficChannel) | LinkRelease2 | ||||||||||||||||
| others | none | LinkRelease1 | |||||||||||||||||
| LinkRelease2 | FinishedSendingPDU | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||||||||||||
| others | none | LinkRelease2 | |||||||||||||||||
| LinkedAs Responder | D: LE_ReturnToScan | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||||||||||||
| TrafWaitTimout | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) + U:LE_Link_Fail_Ind(NORESPONSE)) | Scanning | |||||||||||||||||
| others | none | LinkedAsResponder | |||||||||||||||||
| LinkedOneOf Many | D: LE_ReturnToScan | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||||||||||||
| TrafWaitTimout | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) + U:LE_Link_Fail_Ind(NORESPONSE)) | Scanning | |||||||||||||||||
| others | none | LinkedOneOf Many | |||||||||||||||||
| Offline | D: LE_ReturnToScan | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||||||||||||
| others | none | Offline | |||||||||||||||||
An example of synchronous mode 3G-ALE protocol behavior is shown
in figure C-19. The first call occurs in Slot 2. The responder
receives the call, but has not identified a suitable traffic channel
for the requested traffic, and therefore sends an LE_Handshake
PDU containing a Continue Handshake command.
In the next dwell, both stations tune during Slot 0, then listen
for occupancy on a nearby traffic frequency. The caller selects
Slot 1 this time, and the responder has determined that the traffic
channel was available. When the LE_Call PDU is received by the
responder, the measured channel quality is sufficient for the
offered traffic, and the responder sends an LE_Handshake PDU containing
a Commence Traffic Setup command that indicates the traffic channel
to be used. Both stations tune to that channel in the following
slot, and the caller initiates the traffic setup protocol.
Synchronous-mode 3G-ALE timing is specified in terms of Tsym,
where 2400 Tsym = 1 s. The time at which each type
of 3G-ALE_PDU shall be sent is specified in the following paragraphs.
In each case of sending a PDU, the transmitter shall have reached
90 percent of steady-state power at the time that the PDU begins.
Unless otherwise stated, deviation from specified timing shall
not exceed ±10 percent.
All emanations for tuning the RF components in a synchronous-mode
3G-ALE system shall occur only during the first 256 Tsym
(approximately 106.7 ms) of Slot 0, or between the start of a
calling slot and the beginning of a PDU sent by that station in
that slot. (Emanations required for the initial or learning tuning
of a coupler with presets may occur at any time.)
Synchronous-mode 3G-ALE systems shall listen for occupancy of
a traffic channel during most of the remainder of Slot 0 during
each scanning dwell , and shall meet the requirements of C.4.6.1.2
Occupancy detection. Normally, at least 640 ms should
be available for this function, but no minimum time is required.
The receiver shall be re-tuned to the calling channel in time
to receive a PDU that begins coincident with the start of Slot
1. (NOTE: a PDU may arrive this early due to differences in local
time bases.)
LE_Call, LE_Broadcast, and LE_Notification PDUs shall be sent
during slots selected in accordance with C.5.2.4.4.1 3G-ALE
synchronous mode slot selection. The
PDU shall begin at the later of the following two instants:
A responding station shall commence transmission of an LE_Handshake
PDU at the later of the two following instants:
When a 3G-ALE system is sending a unicast or multicast call, or
a link release, the LE_Handshake PDU that designates the traffic
channel shall be sent in the slot that immediately follows the
LE_Call PDU. The transmitter shall be keyed when 128 Tsym
(approximately 53.3 ms) has elapsed since the start of that slot.
When a 3G-ALE network is operating in asynchronous mode, calls
shall be extended to capture scanning receivers (similar to 2G-ALE)
as described in C.5.2.4.5.2 3G-ALE asynchronous
mode scanning call. The remainder of the handshake
shall be self-timed as described in C.5.2.4.5.3 3G-ALE
asynchronous mode handshake.
Systems operating in 3G-ALE asynchronous mode shall listen on
the calling channel before sending a scanning call or a sound.
The duration of this listen before transmit period shall be programmable,
with a default value of 2 s.
The LE_Scanning_Call PDU shall be sent repeatedly to capture scanning
receivers, followed by an LE_Call PDU. The number of times the
LE_Scanning_Call PDU is sent shall be a programmable multiple
of the number of channels scanned (denoted C). By default, the
multiplier M shall be 1.3. The number of LE_Scanning_Call PDUs
sent shall be the smallest integer that is at least equal to the
product of C and M.
During a scanning call, only the first LE_Scanning_Call PDU shall
include Ttlc (used for transmitter level control and
receiver AGC settling). All succeeding LE_Scanning_Call PDUs
and the LE_Call PDU shall omit Ttlc, and include only
the BW0 preamble (Tpre) and data (Tdata)
portions.
The asynchronous mode 3G-ALE handshake is self-timed. The responding
station shall
1. Decode an LE_Call PDU when it is received,
2. Tune its RF components (if necessary),
3. Listen on a traffic channel for approximately 640 ms to determine occupancy, and
4. Key its transmitter for its response, in accordance with C.5.2.4.5.11.2
3G-ALE asynchronous mode handshake
timing.
The use of LE_Handshake PDU commands shall be the same as in the
synchronous mode.
If the calling station receives a Commence Traffic Setup command
in the responding LE_Handshake PDU, it shall commence the data
link protocol (or ALM protocol, if required) starting 4 Tslot
= 3.2 s after the beginning of its LE_Call PDU.
A unicast call is used to contact an individual station and direct
it to a traffic channel selected by the calling
station. An asynchronous-mode unicast call shall consist
of a scanning call in accordance with C.5.2.4.5.2 3G-ALE
asynchronous mode scanning call, with
a Call Type of Unicast ARQ Packet, Unicast Circuit, or Control
in the LE_Call PDU, followed immediately by an LE_Handshake PDU
that contains the following:
This LE_Handshake PDU shall not include Ttlc, but only
the BW0 preamble (Tpre) and data (Tdata)
portions.
A multicast call is used to contact selected stations concurrently
and direct them to a traffic channel selected by the calling station.
An asynchronous-mode multicast call shall consist of a scanning
call in accordance with C.5.2.4.5.2 3G-ALE asynchronous
mode scanning call, with a Call Type
of Multicast in the LE_Call PDU, followed immediately by an LE_Handshake
PDU that contains the following:
This LE_Handshake PDU shall not include Ttlc, but only
the BW0 preamble (Tpre) and data (Tdata)
portions.
The asynchronous-mode broadcast call shall consist of at least
M C + 1 repetitions of an LE_Broadcast PDU, where C is the number
of calling channels scanned by the stations being called, and
M is the multiplier defined in C.5.2.4.5.2 3G-ALE asynchronous
mode scanning call. The Call Type and Channel
fields shall be used as specified in C.5.2.4.4.5 3G-ALE
synchronous mode broadcast calling.
The Countdown field shall be used as follows:
During an asynchronous-mode broadcast call, only the first LE_Broadcast PDU shall include Ttlc (used for transmitter level control settling). All succeeding LE_Broadcast PDUs shall omit Ttlc, and include only the BW0 preamble (Tpre) and data (Tdata) portions.
A means shall be provided for operators to disable execution of
the asynchronous-mode broadcast protocol.
Transmission of link releases is optional when operating in asynchronous
mode. When used, an asynchronous-mode link release shall be sent
after termination of a link on the calling channel that was used
in establishing the link. Asynchronous-mode link releases shall
begin with a scanning call addressed to the called station in
accordance with C.5.2.4.5.2 3G-ALE asynchronous
mode scanning call, with a Call Type of Link
Release in the LE_Call PDU, followed immediately by an LE_Handshake
PDU that contains the following:
This LE_Handshake PDU shall not include Ttlc, but only
the BW0 preamble (Tpre) and data (Tdata)
portions.
Stations not synchronized to network time may link with synchronous
mode stations by sending either normal (C.5.2.4.5.2) or extended
scanning calls addressed to those stations. The duration of an
extended scanning call is 4 C seconds, which ensures that the
destination station will dwell on the calling channel during the
call.
Implementations of 3G-ALE operating in asynchronous mode shall
exhibit the same over-the-air behavior as that described in table
C-XXX.
| Scanning | End of dwell | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | |
| D: LE_Link_Req( indivDest, trafType, pri) | SelectCallingChannel(indivDest) + ListenOnChannel(callingChannel) | C_Listen | ||
| D: LE_Link_Req( mcastDest, trafType, pri) | SelectMulticastChannels(mcastDest) + ListenOnChannel(callingChannel) | C_Listen | ||
| D: LE_Link_Req( Broadcast, trafType, pri) | SelectBroadcastChannels + InitBroadcastCount + ListenOnChannel(callingChannel) | C_Listen | ||
| R: LE_Scan_Call(addr) | addr is myIndivAddr or is subscribed multicast or listening for LinkReleases | InitScanCallTimeout | ListenToCall | |
| R: LE_Bcast(countdown, trafType, pri, chan) | broadcasts accepted | InitBcastCountdown(countdown) + broadcastPriority=pri + announcedBroadcastChannel = chan | R_Bcast | |
| TimeToSound(channel) | sounding enabled | callingChannel = channel + ListenOnChannel(myCurrentTrafficChannel) | S_Listen | |
| others | none | Scanning | ||
| S_Listen | FinishedListening | channel occupied | RecordOccupancy(callingChannel) + RestartSoundingTimer(callingChannel, soundRetryDelay) + ListenForCalls(myCurrentDwellChannel) | Scanning |
| channel vacant | TuneToNewChannel(callingChannel) + RestartSoundingTimer(callingChannel, soundingInterval) | S_Tune | ||
| others | queue or ignore | S_Listen | ||
| S_Tune | TuningComplete | S: LE_Notification(myIndivAddr, NOMINAL) + scanSoundCountdown = 1.2 * numScanChan | SendSound | |
| others | queue or ignore | S_Tune | ||
| Send Sound | FinishedSendingPDU | scanSoundCountdown > 1 | S: LE_Notification(myIndivAddr, NOMINAL) + scanSoundCountdown = scanSoundCountdown - 1 | SendSound |
| scanSoundCountdown <= 1 | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||
| others | queue or ignore | SendSound | ||
| ListenTo Call | R: LE_Call(myIndivAddr, srcAddr, pkt or ckt call) | TuneToNewChannel(myCurrentDwellChannel) | L_Tune | |
| R: LE_Call(myIndivAddr, srcAddr, UNICAST) | InitResponseTimeout | R_Unicast | ||
| R: LE_Call(destAddr, srcAddr, MULTICAST) | destAddr is in myMulticastAddresses | InitResponseTimeout | R_Multicast | |
| R: LE_Call(dest, srcAddr, LinkRelease) | InitResponseTimeout | R_Release | ||
| ScanCallTimeout | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||
| ScanCallDropout | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||
| others | queue or ignore | ListenToCall | ||
| L_Tune | TuningComplete | willing to link w/srcAddr | SelectTrafficChannel(myCurrentDwellChannel) + ListenOnChannel(myCurrentTrafficChannel) | R_Listen | ||||||||
| not willing to link with srcAddr | ComputeLinkID(srcAddr, myIndivAddr) + S:LE_Hshake(linkID, ABORT, REJECTED) | R_Abort | ||||||||||
| others | queue or ignore | L_Tune | ||||||||||
| R_Release | R: LE_Hshake(id, cmd, arg) | id is correct, cmd=LinkRelease | U: LE_Link_Det_Ind(Available, arg, srcAddr, dest) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||||
| wrong id or other command | ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||||||
| ResponseTimeout | ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||||||
| others | none | R_Release | ||||||||||
| R_Listen | FinishedListening | trafic channel occupied | ComputeLinkID(srcAddr, myIndivAddr) + S:LE_Hshake(linkID, CONTINUE, NO_CHANNEL) | R_Continue | ||||||||
| traffic channel vacant | ComputeLinkID(srcAddr, myIndivAddr) + S:LE_Hshake(linkID, COMMENCE, prefTrafChan) | R_Commence | ||||||||||
| others | queue or ignore | R_Listen | ||||||||||
| R_Commence | FinishedSendingPDU | TuneToNewChannel(myCurrentTrafficChannel) | R_Tune | |||||||||
| others | none | R_Commence | ||||||||||
| R_Abort | FinishedSendingPDU | none | Scanning | |||||||||
| others | none | R_Abort | ||||||||||
| R_Continue | FinishedSendingPDU | none | Scanning | |||||||||
| others | none | R_Continue | ||||||||||
| R_Unicast | R: LE_Hshake(id, cmd, arg) | id is correct, cmd = Commence or Voice | myCurrentTrafficChannel = arg + TuneToNewChannel(myCurrentTrafficChannel) | R_Tune | ||||||||
| wrong id or other command | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||||||
| ResponseTimeout | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||||||
| others | none | R_Multicast | ||||||||||
| R_Multicast | R: LE_Hshake(id, cmd, arg) | id is correct, cmd = Commence or Voice | myCurrentTrafficChannel = arg + TuneToNewChannel(myCurrentTrafficChannel) | M_Tune | ||||||||
| wrong id or other command | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||||||
| ResponseTimeout | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | ||||||||||
| others | none | R_Multicast | ||||||||||
| R_Bcast | R: LE_Bcast(countdown, trafType, pri, chan) | countdown = 0 | TuneToNewChannel(chan) | M_Tune | ||||||||
| countdown > 0 | none | R_Bcast | ||||||||||
| others | none | R_Bcast | ||||||||||
| R_Tune | TuningComplete | U: LE_Link_Ind(RESPONDER, srcAddr, trafType, pri) | LinkedAsResponder | |||||||||
| others | none | R_Tune | ||||||
| M_Tune | TuningComplete | U: LE_Link_Ind(MEMBER, srcAddr, trafType, pri) | LinkedOneOfMany | |||||
| others | none | M_Tune | ||||||
| LinkedAs Caller | D: LE_ReturnToScan | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | |||||
| others | none | LinkedAs Caller | ||||||
| LinkedOneTo Many | D: LE_ReturnToScan | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | |||||
| others | none | LinkedOneTo Many | ||||||
| LinkedAs Responder | D: LE_ReturnToScan | ComputeDwellChannel(myIndivAddr) + ListenForCalls(myCurrentDwellChannel) | Scanning | |||||
| others | none | LinkedAs Responder | ||||||
| C_Listen | FinishedListening | channel vacant | TuneToNewChannel(callingChannel) | C_Tune | ||||
| channel occupied | RecordOccupancy(callingChannel) + SelectCallingChannel(indivDest) + ListenOnChannel(callingChannel) | C_Listen | ||||||
| others | queue or ignore | C_Listen | ||||||
| C_Tune | TuningComplete | individual call | S: LE_Scan_Call(destAddr) | SendScanCall | ||||
| multicast call | S: LE_Scan_Call(mcastAddr) | SendScanCall | ||||||
| broadcast call | InitAsyncCount + S: LE_Bcast(bcastCount, trafType, pri, myCurrentTrafficChannel) | BroadcastCall | ||||||
| others | queue or ignore | S_Listen | ||||||
| SendScanCall | FinishedSendingPDU | individual call | ComputeLinkID(myIndivAddr, indivDest) + InitResponseTimeout | ListenForResponse | ||||
| multicast call | ComputeLinkID(myIndivAddr, mcastDest) + S:LE_Hshake(linkID, COMMENCE or VOICE, myCurrentTrafficChannel) | N_Commence | ||||||
| others | none | SendScanCall | ||||||
| ListenFor Response | R: LE_Hshake(id, cmd, arg) | id is correct, cmd=Commence | myCurrentTrafficChannel = arg + TuneToNewChannel(myCurrentTrafficChannel) | T_Tune | ||||
| id is correct, cmd=Abort | U: LE_Link_Rejected(reason = arg) | Scanning | ||||||
| wrong id or other command | RecordCallFailure(indivDest, callingChannel) + SelectCallingChannel(indivDest) + ListenOnChannel(callingChannel) | C_Listen | ||||||
| ResponseTimeout | RecordCallFailure(indivDest, callingChannel) + SelectCallingChannel(indivDest) + ListenOnChannel(callingChannel) | C_Listen | ||||||
| others | none | ListenFor Response | ||||||
| T_Tune | TuningComplete | U: LE_Link_Ind(Caller, indivDest, trafType, pri) | LinkedAsCaller | |||||
| others | none | T_Tune | ||||||
| N_Commence | FinishedSendingPDU | TuneToNewChannel(myCurrentTrafficChannel) | N_Tune | |||||
| others | none | N_Commence | ||||||
| N_Tune | TuningComplete | U: LE_Link_Ind(NCS, mcastDest, trafType, pri) | LinkedOneToMany | |||||
| others | none | N_Tune | ||||||
| BroadcastCall | FinishedSendingPDU | countdown = 0 | TuneToNewChannel(myCurrentTrafficChannel) | A_Tune | ||||
| countdown > 0 | update bcastCount + S: LE_Bcast(bcastCount, trafType, pri, myCurrentTrafficChannel) | BroadcastCall | ||||||
| others | none | BroadcastCall | ||||||
| A_Tune | TuningComplete | U: LE_Link_Ind(NCS, Broadcast, trafType, pri) | LinkedOneToMany | |||||
| others | none | A_Tune | ||||||
The asynchronous mode 3G-ALE protocol is illustrated in figure
C-20. The called station ("Responder") receives a scanning
call and evaluates the channel quality of the calling channel
using the received LE_Scanning_Call and LE_Call PDUs. Having
determined that the channel quality is sufficient for the type
of traffic announced in the LE_Call PDU, the Responder tunes on
the calling channel for sending a response, listens on a nearby
traffic channel, finds the traffic channel unoccupied, and therefore
sends a Commence Traffic Setup command in an LE_Handshake PDU.
Asynchronous mode timings are referenced only to the start of
the scanning call, not to any global timing system. Unless otherwise
stated, deviation from specified timing shall not exceed ±10
percent.
The duration of a 3G-ALE asynchronous-mode scanning call (including
LE_Scanning_Call PDUs and the LE_Call PDU) shall be as follows,
where C is the number of scanned channels, and M is the multiplier
of C.5.2.4.5.2 3G-ALE asynchronous mode
scanning call.
Tsc = Ttlc + (M C + 1) (TBW0 pre
+ TBW0 data)
= 2.640 s when C = 3 calling channels, and M = 1.3
When an LE_Handshake PDU is appended to the LE_Call PDU, Tsc
is increased by TBW0 pre + TBW0 data
or approximately 506.7 ms.
When an LE_Handshake PDU is sent by a responding station, it shall
begin 32 Tsym (approximately 13.3 ms) after the transmitter
is keyed. Total elapsed time from end of LE_Call PDU until start
of LE_Handshake PDU shall be 2208 Tsym (920 ms), measured
at the responding station.
The duration of a 3G-ALE asynchronous-mode handshake, from the
start of the scanning call through the start of traffic setup
on the traffic channel is as follows:
Thandshake = Ttlc + M C (TBW0 pre
+ TBW0 data) + 4 Tslot
= 5.333 s when C = 3 calling channels, and M = 1.3
Sending LE_Notification PDUs is optional. Network managers may
wish to enable the notification protocol when the use of channel
time for this overhead function provides a worthwhile return in
tracking station and channel status.
When station status notification is enabled, stations shall broadcast
an LE_Notification PDU when one of the following occurs:
A notification shall be sent on one or more channels selected
to efficiently inform other network members of station status.
Sounding will normally be unnecessary in 3G-ALE systems. Knowledge
of propagating channels can be used in synchronous networks to
delay the start of calling and thereby reduce calling channel
occupancy. However, with synchronous scanning, knowledge of propagating
channels will have only slight effect on linking latency unless
non-propagating channels are removed from the scan list (see Calling
Channel Management, above).
In asynchronous 3G-ALE networks, sounding may be desired if propagation
data is unobtainable by other means. In this case, periodic transmissions
of a repeated LE_Notification PDU indicating Nominal station status
may be employed.
In networks operating in synchronous mode, LE_Notification PDUs
shall be sent singly in randomly selected slots using the same
procedure as for LE_Call PDUs, including slot selection and listening
before transmitting.
In networks operating in asynchronous mode, LE_Notification PDUs
shall be sent M C + 1 times, after listening before transmitting,
where C is the number of scanned channels, and M is the multiplier
of C.5.2.4.5.2 3G-ALE asynchronous mode
scanning call.
Stations that have not been assigned an address in a network may
call into that network by randomly selecting a Net Entry address
(C.5.2.6.1) and placing a call using that address in accordance
with an appropriate calling protocol. The call may be placed
on any frequency known to be monitored by the network to be entered.
Networks that support net entry by non-member stations should
assign a well-known address (e.g., all 0's) to field such calls.
Linking protection should be employed when spoofing is a concern.
Net entry calling and acceptance of net entry calls shall be supported
by all 3G systems. A means shall be provided for operators to
disable acceptance of net entry calls.
Net Entry addresses are of the form 1111xxxxxxx. A station placing
a net entry call shall randomly select one of these 128 addresses
for use in a 3G-ALE calling protocol and subsequent protocols
until it is assigned a member address.
A station calling into a network operating in synchronous or asynchronous
mode shall place an asynchronous-mode unicast call to a well-known
address in accordance with C.5.2.4.5.4 3G-ALE asynchronous
mode unicast call. When the calling station
does not know the channel assignments in the foreign network,
it should specify channel 127 which results in linking for traffic
on the calling channel. When more than one of the frequencies
scanned by the destination network are known, calling attempts
should be placed on each channel in rotation until a link is established.
If the calling station seeks only a one-time analog voice link,
the Call Type should be "Unicast Circuit" and the LE_Handshake
PDU should carry a Commence Voice command. Otherwise, the TM
protocol will normally be engaged after linking, so the Call Type
should be "Unicast ARQ Packet" and the LE_Handshake
PDU should carry a Commence Traffic Setup command.
When a station calling into a network is to begin regular operation as a network member, the 3G packet protocol and the network management protocol of Appendix D should be used to transfer the following network operating data to the entering station:
This transfer may be accomplished during the traffic phase of
the initial net entry call, using the net entry address.
Synchronization of the entering station with network time shall
comply with C.4.3 Network synchronization. If over-the-air
synchronization will be required, it is recommended that operating
data be set up in the new network member before the net entry
synchronization protocol of C.5.2.7.6 is executed.
3G networks operating in synchronous mode are intended to maintain
synchronization using external means such as GPS receivers. This
section describes a synchronization management protocol that is
intended to serve as a fallback mechanism for use when external
time references are unavailable or their use is otherwise impractical.
Network managers should avoid use of this protocol when other
alternatives are available because it requires use of the HF channels
for this overhead function.
The synchronization management protocol supports the following
tasks:
This is an optional protocol. However, all 3G networks that must
operate without external synchronization available to every station
should implement these functions.
For successful operation in synchronous mode, third generation
systems must maintain time base accuracy in accordance with C.4.3.
The formula used by synchronous-mode stations to compute their
current dwell channels in C.4.4.1 includes the time since midnight
(network time). Network time is conceptually stored as a GPS
week counter (week 0 was the week beginning 00:00 6 January 1980),
a day of the week, elapsed seconds in the current day, and elapsed
Tsym within the current second. A dwell counter is extracted
from the seconds counter by dropping the two least-significant
bits. Note that GPS time runs at the same rate as coordinated
universal time (UTC), but GPS time does not add leap seconds and
therefore differs by a small number of seconds from UTC.
In addition to a local estimate of network time, each station
shall maintain a bound on the uncertainty (loss of accuracy) of
this time base. This uncertainty value shall be set when the
time base is adjusted, as described later, and shall increase
steadily until the next time base update at a rate determined
by the accuracy of the time base oscillator. When the oscillator
has an accuracy of 1 part per million, the time base may drift
by +/- 3.6 ms per hour, so the total width of time base uncertainty
shall be increased by 7.2 ms per hour.
When one station sends a time update to another station, the uncertainty
at the sending station shall be encoded as a Time Quality code
in accordance with table C-XXXI. Note that only UTC sites may
claim Time Quality 0. Stations that receive regular updates from
a local GPS receiver or other stable time base that maintains
their uncertainty below 1 ms shall report Time Quality 1. Other
stations shall use the smallest code whose corresponding uncertainty
value is greater than or equal to the local total uncertainty
width.
| none: UTC station | |
| 1 ms: local GPS receiver or equiv. | |
| 2 ms or stand-alone master station | |
| 5 ms | |
| 10 ms | |
| 20 ms | |
| 50 ms | |
| unbounded or unknown |
NOTE: When a network is operating in stand-alone mode (i.e.,
no network member has access to UTC, GPS, or equivalent time),
one network member station should be designated as the master
time reference, and that station should always use Time Quality
2. Of all station that have suitably stable oscillators, the
designated station may be selected as the one with the lowest
3G-ALE address (e.g., a designated net entry server, with address
zero).
The LE_PDUs (see figure C-17) used in synchronization management
are described in the following paragraphs.
The group time broadcast PDU (LE_GTB PDU) conveys limited-precision
time to any station that receives it. It is sent singly as described
later in this section. The Server Group Number shall contain
the dwell group number portion of the sending station address.
The Dwell Number field shall contain the four least-significant
bits of the counter of dwell periods since midnight network time.
The Slot Number field shall indicate the slot in which the PDU
is sent. (The Slot Number field is set to 7 during initial time
distribution, as described in C.5.2.7.5.)
An LE_GTB PDU shall always be sent starting 128 Tsym after the
beginning of the indicated slot at the sender. However, receiving
stations may not know the propagation delay from sender to receiver,
so this PDU by itself is insufficient to synchronize stations
to meet the requirements of C.4.3.
NOTE: each day contains an even multiple of 16 dwells so the
four Dwell Number bits sent in this PDU increment naturally from
1111 to 0000 at midnight. The time indicated by this PDU should
never be ambiguous unless (and only when) network time adds a
leap second. For this reason, GPS time may be preferred over
UTC.
The Sync Check PDU is an LE_Handshake PDU containing a Sync Check
command. It is sent following a Control-type LE_Call PDU during
a sync check handshake, and shall always be sent 128 Tsym after
the beginning of its slot at the sending station.
The most-significant bit of the Argument field shall be 0. The
next three bits shall contain the time quality code from table
C-XXXI corresponding to the total time uncertainty at the station
sending the PDU. The three least-significant bits shall contain
the number of the slot in which the PDU is sent: 001, 010, 011,
or 100.
The Argument field may be set to all 1's when used in Late Net
Entry Sync Acquisition (see C.5.2.7.6).
The LE_Sync Offset PDU is used to compensate for time base drift
and propagation delay among stations during a Sync Check Handshake.
It shall be sent by the responding station 256 Tsym (+/- 1 ms)
after the end of a Sync Check PDU. The Quality field shall contain
the time quality of the responding station in accordance with
C.5.2.7.2. The Offset field shall indicate the magnitude of the
difference between the time when the end of the Sync Check PDU
arrives at the responding station and the "ideal time"
when a PDU sent by the responding station in that same slot would
have ended (i.e., beginning of the slot plus 128 Tsym plus 613
ms, which is 1600 Tsym or 666.7 ms into the slot). The Offset
field shall be encoded in accordance with table
C-XXXII. The Sign bit shall be 1 if the PDU arrived early (before
the ideal time), 0 if it arrived after the ideal time.
The sync check handshake is used to update the time base at the
station that initiates the handshake. It consists of a Control-type
LE_Call PDU, followed by an LE_ Sync Check PDU from the initiator.
The called station then responds with an LE_Sync Offset PDU.
The initiating station shall compute its new local time and total
time uncertainty as follows after receiving the LE_Sync Offset
PDU:
A sync check handshake shall begin with equal probability in slot
1 or slot 2, and shall not begin in later slots.
Stations operating in synchronous mode should request a time base
update whenever their total time uncertainty will increase past
the maximum allowed tolerance (C.4.3) within 60 minutes. A sync
check handshake should then be initiated with the time server
in its group. If no response (or a garbled response) is received,
the initiating station should try again C + 1 dwells later on
the next channel, and so on.
If a station's time uncertainty grows past the limit of C.4.3,
it must cease synchronous operation and attempt to reacquire network
synchronization using the Late Net Entry procedure specified in
C.5.2.7.6.
A station that is not synchronized to a network but whose time
base is within +/- 30 s of network time may request and synchronize
to network time using the following protocol. The protocol is
more robust if the unsynchronized station knows the channel assignments
of the network (see step 3), but may be used by a station that
knows only one frequency that is monitored by the network stations.
An entering station shall not place any other synchronous call
to the network until this synchronization is completed.
Before a network is synchronized, stations should be scanning
in asynchronous mode. Initial time distribution to a network
begins with an asynchronous mode notification sequence, followed
by an LE_GTB PDU from the master time station for the network
(e.g., station 0). The repeated LE_Notification PDU shall contain
the master time station address and a status of Time Server.
The LE_GTB PDU shall contain a Slot Number value of seven, which
indicates that the initial time distribution protocol is commencing.
The PDU sequence that ends in this LE_GTB PDU shall be timed
such that the LE_GTB PDU occurs the final slot of a dwell (according
to what will be network time), and the call shall be sent on the
channel that the master time station would be monitoring during
that dwell in synchronous mode.
Following receipt of this transmission, each station in the network
shall compute the limited-precision time implied by the LE_GTB
PDU, temporarily set its time base to this time, set its total
time uncertainty to 70 ms and commence scanning its assigned channels
in synchronous mode. In the following dwells, each dwell group
will in turn monitor the channel that carried the time distribution
transmission. During that dwell, the time server in each dwell
group shall execute a Sync Check handshake with the network master
time station to refine its time and set its time uncertainty.
After 32 dwells have elapsed since the end of the initial LE_GTB
transmission, all stations shall stop scanning and remain on their
current calling channel. Each dwell group will be on a distinct
channel, and the time server in each group should have completed
a Sync Check handshake with the master time station. Each such
dwell group time server shall then transmit identical LE_Notification
PDUs in slots 1, 2, and 3 of the dwell, followed by an LE_GTB
PDU in slot 4. The Slot Number field in this LE_GTB PDU shall
be 4. Dwell group members shall perform Sync Check handshakes
with their respective group time servers in the following 60 dwells,
starting with member number 0 in the first dwell after this normal
LE_GTB PDU, member number 1 in the next dwell and so on. After
60 dwells, all stations shall resume scanning on their assigned
channels.
Breakdowns in this protocol are handled as follows:
As each station achieves synchronization, it commences synchronous
operation.
The TM protocol is used to coordinate traffic exchanges on connections
established using the Third Generation ALE (3G-ALE) protocol.
Following the end of the ALE phase in which a connection is established,
the stations participating in the connection enter the Traffic
Set-Up (TSU) phase in which the TM protocol is used to establish
a traffic link on which traffic can be delivered.
Once a connection has been established, the stations participating
in it have determined:
In addition, each participating station knows whether or not it initiated the connection (even though stations other than the initiator do not always know which station originated the connection, as in broadcast connections), so that the initiating station knows it can transmit a TM PDU in the first transmit time-slot of the TSU phase.
During the TSU phase, the participating stations exchange TM PDUs
in order to determine:
If the traffic link is a multicast circuit link (has a multicast
topology), the participating stations initially conduct a roll-call
procedure to determine which of the stations in the multicast
group received the 3G-ALE signalling and are now present on the
traffic frequency. A second roll-call can be conducted on the
traffic link just before the traffic link is torn-down and the
participating stations resume scanning. This allows a station
sending information on a Multicast circuit link to know whether
the intended recipients of the information were on the traffic
frequency to receive it, and allows the station initiating the
traffic link to drop the current link and attempt to re-establish
it if desired stations are absent from the link.
When traffic exchanges have been completed on a traffic link,
the TM protocol is used to coordinate the participating stations'
departure from the traffic link.
The terms defined in table C-XXXIII are used to refer to specific
types of data objects in defining the TM protocol.
| Data object type | Definition | |
| traffic type | identifies a kind of traffic that can be delivered on a traffic link established using the TM protocol. The defined traffic types and their meanings are as follows: | |
| value | description | |
| HDL_n | HDL (HDL), n data packets per forward transmission (n = 24, 12, 6, or 3) | |
| LDL_n | LDL , n payload data bytes per LDL forward transmission (n = 512, 256, 128, or 64) | |
| ANDVT | Digitized voice using the ANDVT digitized voice coding method and modem waveforms defined by STANAG 4197 and STANAG 4198. | |
| DGTL_VOICE | Digitized voice using a non-ANDVT digitized voice coding method and/or modem waveform. The receiving station is assumed to be able to detect the voice coding and modem waveform and apply the appropriate receive processing. | |
| ANLG_VOICE | Analog voice traffic. | |
| SER_110 | Bit-pipe data traffic delivered using the MIL-STD-188-110 serial tone modem signalling format. | |
| HQ_n | Bit-pipe data traffic delivered using a high-rate data modem signalling format at n bits per second (n = 9600, 6400, 4800, or 3200). | |
| SER_4285 | Bit-pipe data traffic delivered using the STANAG 4285 serial tone modem signalling format. | |
| PKT | packet traffic: refers to any traffic type that can be delivered on a packet traffic link: i.e., any of the HDL_n or LDL_n traffic types. Is used in contexts in which a station knows that a packet link is required, but not the specific type of packet traffic to be delivered on the link. | |
| CKT | circuit traffic: refers to any traffic type that can be delivered on a circuit traffic link, including all of the defined traffic types except HDL_n and LDL_n (which are delivered only on packet traffic links). Is used in contexts in which a station knows that a circuit link is required, but not the specific type of traffic to be delivered on the circuit link. | |
| NO_TR | no traffic: the sender has no traffic to deliver, and will await traffic from the other participant(s) in the traffic link. | |
| Note: In the TM behavior definitions, 'pktTraf' is used as an abbreviation for a traffic type of either HDL_n or LDL_n, which can be delivered only on a packet traffic link, or for 'NO_TR' (no traffic). 'cktTraf' is used as an abbreviation for any traffic type other than HDL_n or LDL_n -- i.e., any traffic type that can be delivered on a circuit traffic link - or for 'NO_TR' (no traffic). | ||
Table C-XXXIV describes the service primitives exchanged between
the TM entity and a user process at TM's upper interface. Note
that there is no requirement that implementations of the waveforms
and protocols defined in this Appendix contain precisely these
service primitives; nor are the services primitives defined below
necessarily all of the service primitives that would be required
in an implementation of these waveforms and protocols.
| TM_Connect_Req | Overview | TM Connect Request: issued to TM by the user process to request establishment of a traffic link. | |
| Parameters | topology | Identifies the topology of the traffic link being established; one of:
The topology value must be 'P2P' if trafficType is any of the 3G data link traffic types HDL_n or LDL_n. | |
| trafficType | Identifies the type of traffic for which the traffic link is being established; value can be any of the traffic type values defined in table C-XXXIII. | ||
| role | role of the local station in the established traffic link: MASTER (initiator of the link) or SLAVE. | ||
| priority | priority level of the traffic (at the initiating station) for which the traffic link is being requested: HIGHEST, HIGH, ROUTINE, or LOW. | ||
| addr | address of the station or group of stations to be included with the local station in the requested traffic link: an individual or multicast address, or a null (ignored) address for broadcast traffic links. | ||
| reqIntvl | the duration of the time-interval through which TM should wait to receive a TM_REQ PDU from the initiating station before timing-out. The reqIntvl parameter-value is used only by slave stations in broadcast circuit links; it is ignored in all other cases. | ||
| Originator | user process | ||
| Preconditions |
| ||
| TM_Connect_Ind | Overview | TM Connect Indication: issued to the user process to indicate that a traffic link has been established at the request of a remote station, with the local station as a participant. | |
| Parameters | trafficType | Identifies the type of traffic for which the traffic link is being established; value can be any of the traffic type values defined in table C-XXXIII. Obtained from the Argument (Traffic type) field of the TM_REQ PDU sent by the initiating station. | |
| priority | priority level of the traffic for which the traffic link has been established: HIGHEST, HIGH, ROUTINE, or LOW. This value is obtained from the Priority field-value of the TM_REQ PDU sent by the link master station to initiate the establishment of the link. | ||
| srcAddr | station address of the station that initiated establishment of the link (the link master). Obtained from the Source Addr field-value of the TM_REQ PDU sent by the initiating station. | ||
| responses | list of addresses of the members of the multicast group (for multicast links) from which a valid roll-call response was received; null (ignored) for point-to-point and broadcast links (on which no roll-call is performed). | ||
| Originator | TM | ||
| Preconditions |
| ||
| TM_Connect_Conf | Overview | TM Connect Confirm: issued to the user process by TM, to confirm that a traffic link has been established as requested by a preceding TM_Connect_Req service primitive. | |
| Parameters | responses | list of addresses of the members of the multicast group (for multicast links) from which a valid roll-call response was received; null (ignored) for point-to-point and broadcast links (on which no roll-call is performed). | |
| Originator | TM | ||
| Preconditions |
| ||
| TM_Disconnect_Req | Overview | TM Disconnect Request: issued to TM by the user process, to request that the local station cease to participate in the current traffic link, and if the local station is the link master, that the traffic link be terminated entirely, with all of the remaining participants leaving the traffic frequency (or frequencies). | |
| Parameters | reason | reason for disconnection. Value is one of:
| |
| period | on point-to-point circuit and multicast circuit links, the maximum amount of time that TM can wait for the link to become available so that the TM_TERM PDU sent as the station departs from the link does not collide with other traffic. After TM waits this amount of time, if the CLC still indicates that the link is busy, TM sends a TM_TERM PDU and drops the link regardless of any ongoing link activity. The period parameter-value is ignored (not used) on packet and broadcast circuit links. | ||
| Originator | user process | ||
| Preconditions |
| ||
| TM_Disconnect_Ind | Overview | TM Disconnect Indication: issued to the user process to indicate that the local station has ended its participation in a traffic link for a reason other than the user process' having issued a TM_Disconnect_Req primitive. | |
| Parameters | reason | reason for disconnection. Value is one of:
| |
| Originator | TM | ||
| Preconditions |
| ||
| TM_Disconnect_Resp | Overview | TM Disconnect Response: issued to TM by the user process to acknowledge that a currently-active multicast circuit is being "unlinked": i.e., dropped after a final roll call is performed. | |
| Parameters | ackNak | Positive or negative acknowledgement of having received the traffic delivered on the multicast circuit. Possible values are
| |
| watch | Boolean: if TRUE, TM will wait on the traffic channel to hear the unlink roll call responses from the other circuit participants. Otherwise, the station will wait only long enough to transmit its own roll call response in its unlink roll call time slot, and will immediately afterward return to 3G-ALE scanning. | ||
| Originator | TM | ||
| Preconditions |
| ||
| TM_Disconnect_Conf | Overview | TM Disconnect Confirm: issued to the user process by TM to acknowledge that a currently-active traffic link is being dropped as a result of a TM_Disconnect_Req service primitive. | |
| Parameters | reason | The reason for which the traffic link is being dropped. Possible values and their meanings are the same as for the reason parameter of the TM_Disconnect_Req service primitive, as described above. | |
| responses | list of responses to an optional unlink roll-call performed at the conclusion of a multicast circuit connection, in which each response is in the form of an ordered pair (indAddr, ackNak), where indAddr is the address of a station whose roll call response was heard, and ackNak is the Reason field-value of the TM_TERM PDU sent as the station's response: UNL_ACK or UNL_NAK. The responses parameter has a value only when a multicast circuit link has been concluded with an unlink roll call. The list of responses can be incomplete for either of two reasons:
The responses parameter is shown in the state diagrams only where it is used: where a multicast circuit link is being dropped with a concluding unlink roll call operation. | ||
| Originator | TM | ||
| Preconditions |
| ||
| TM_Suspend_Req | Overview | TM Suspend Request: issued to TM by the user process, to suspend the current multicast circuit link. This primitive can be issued by the user process at the station which has initiated a multicast circuit link, when the responses to a just-completed roll call indicate that not all members of the multicast group are present in the circuit link. In response to the TM_Suspend_Req service primitive, the TM entity sends a TM_TERM PDU with reason = SUSPEND to hold the stations that answered the roll call on the traffic channel, then repeats the 3G-ALE multicast calling process in order to bring as many as possible of the remaining stations into the multicast circuit link. | |
| Parameters | (none) | ||
| Originator | user process | ||
| Preconditions |
| ||
| TM_Resume_Req | Overview | TM Resume Request: issued to TM by the user process, to cause the current multicast circuit link to be resumed after it has been suspended by means of a TM_Suspend_Req service primitive. In response to the TM_Resume_Req, TM sends a TM_REQUEST PDU on the traffic channel, to initiate an additional roll call and determine which of the multicast group members are now present on the traffic channel. | |
| Parameters | (none) | ||
| Originator | user process | ||
| Preconditions |
| ||
The sub-sections of this section describe the PDUs exchanged between a TM entity and its remote peer entities. All TM PDUs have the common format and contents shown in table C-XXXV.
Behavioral descriptions of the TM protocol refer to three kinds of PDUs: TM_REQ, TM_CONF, and TM_TERM. These PDUs all have the format shown in table XXXV, and are distinguished from one another by the values of their Type fields:
The field-values of each TM PDU are transmitted in order of their
occurrence in table XXXV, starting with the protocol field. The
bits of each field-value are transmitted in order of significance,
starting with the most significant bit.
All of the TM PDUs are sent and received using the burst waveform
BW1 described in section C.5.1.4. Each outgoing PDU is used as
the Payload parameter value for a BW1_Send service primitive as
described in table C-IV; each incoming PDU is received as the
value of the Payload parameter of a BW1_Receive service primitive
(see table C-XXXVI).
The TM entity at each station remains active while the station
is exchanging voice or data traffic with other stations on an
established traffic link, so as to be ready to drop the link on
request. On traffic links established for packet traffic delivered
using the HDL protocol (C.5.2) or the LDL protocol (C.5.5), the
user process can terminate the data link transfer and use the
next data link transmission time slot in either direction - i.e.,
the time slot for the xDL_DATA or the xDL_ACK PDU - to instead
send a TM_TERM PDU (by issuing a TM_Disconnect_Req primitive)
as many times as will fit within the data link PDU time-slot.
This means that while a data link transfer is in progress, each
station must be simultaneously attempting to demodulate TM_TERM
PDUs conveyed by the BW1 waveform as it is attempting to demodulate
and receive data link signalling conveyed by BW2, BW3, or BW4.
Similarly, on a circuit link, each station must attempt to detect
and demodulate TM_TERM PDUs conveyed by the BW1 waveform at all
times when the station is not transmitting.
| Protocol | 0012 (fixed) | distinguishes TM PDUs from HDL_ACK and HDL_EOM PDUs | |
| Priority | In all TM_REQ and some TM_CONF PDUs (i.e., TM PDUs having Type = TM_REQUEST or TM_CONFIRM), indicates the priority level of the traffic (if any) that the sender of the PDU intends to send on the traffic link once it is established. In TM_CONF PDUs, this field is used only when the Argument field value refers to one of the High-Rate ('HDL_n') or LDL ('LDL_n') traffic types as shown in Table C-XXXVI. The field-value is set to 3 (LOW) in all other TM_CONF PDUs and in all TM_TERM PDUs, and must be ignored by the receiver. | ||
| 0 | HIGHEST: highest priority | ||
| 1 | HIGH | ||
| 2 | ROUTINE | ||
| 3 | LOW: lowest priority | ||
| Dest Addr | any | address of the station to which this PDU is being sent. Dest Addr can be the individual address of a single intended recipient station (abbreviated 'indAddr' below), a multicast address designating a multicast group ('MCaddr'), or all ones on a broadcast traffic link ('BCaddr') (see note). When the destination address is a multicast address, the lowest-order five bits of the address (corresponding to the dwell group number in an individual address) shall be all ones. | |
| Source Addr | any | address of the station that is sending this PDU. Is always the station address of a single station - never a multicast or broadcast address. | |
| Type | Type of PDU, indicating its role in the TM protocol. Note that the state diagrams and other materials refer to, for instance, a "TM_REQ PDU"; this is a TM PDU whose Type field value is 0 (TM_REQUEST). | ||
| 0 | TM_REQUEST: A PDU with Type = TM_REQUEST is sent in order to request that a traffic link be established between the station sending the TM_REQUEST and the other stations specified by the PDU's destination address. | ||
| 1 | TM_CONFIRM: A PDU with Type = TM_CONFIRM is sent in response to a received TM_REQUEST PDU, to confirm the sender's readiness to participate in a traffic link. | ||
| 2 | TM_TERM: a PDU with Type = TM_TERM is sent in order to terminate the station's participation in a traffic link (during or after link establishment), and when sent by the link master, to terminate the link as a whole. | ||
| 3..7 | reserved | ||
| Argument | variant field whose usage and meaning depend on the value of the Type field; see TABLE XXXVI. | ||
| CRC | any | 12-bit Cyclic Redundancy Check (CRC) computed across the remaining 36 bits of each TM PDU, using the generator polynomial
X12 + X11 + X9 + X8 + X7 + X6 + X3 + X2 + X1 + 1, and the procedure described in C.4.1. | |
| NOTE: The destination address has no significance on broadcast links; this field is set to all-ones purely by convention. The all-ones address vaule is not a reserved broadcast address, and hence can also be used as an individual or multicast address. | |||
| TM_REQUEST or TM_CONFIRM | Traffic Type | Indicates the type of traffic that the sender expects to send or receive on the traffic link once it is established. Each argument field-value represents one of the traffic type values defined in TABLE C-XXXIII. In a TM_REQUEST PDU, the Traffic Type field-value serves to stipulate the type of traffic that will be delivered on the traffic link. The sender of a TM_CONFIRM PDU places in this field the value of the Traffic Type field in the TM_REQUEST PDU it has recently received; in this case, the field-value serves as an acknowledgement of the traffic type specified in the TM_REQUEST. | |
| 0 | HDL_24 | ||
| 1 | HDL_12 | ||
| 2 | HDL_6 | ||
| 3 | HDL_3 | ||
| 4 | LDL_512 | ||
| 5 | LDL_256 | ||
| 6 | LDL_128 | ||
| 7 | LDL_64 | ||
| 8 | ANDVT | ||
| 9 | DGTL_VOICE | ||
| 10 | ANLG_VOICE | ||
| 11 | SER_110 | ||
| 12 | HQ_9600 | ||
| 13 | HQ_6400 | ||
| 14 | HQ_4800 | ||
| 15 | HQ_3200 | ||
| 16 | SER_4285 | ||
| 17-60 | reserved | ||
| 61 | PKT | ||
| 62 | CKT | ||
| 63 | NO_TR | ||
| TM_TERM | Reason | Indicates the reason why the sending station is terminating its participation in the traffic link, and the intended result of its doing so. | |
| 0 ("ABORT") | Immediately terminate the traffic link, with all participating stations leaving the traffic frequency (-ies) assigned to the link. Reason = ABORT indicates nothing about any measures that may be taken to resume any data transfer that may have been in progress. | ||
| 1 ("RELINK") | Immediately terminate the traffic link, with all participating stations leaving the traffic frequency (-ies) assigned to the link. Reason = RELINK indicates that the user process will attempt to resume the data transfer, possibly on a different frequency or frequencies. | ||
| 2 ("SIGN_OFF") | The station sending the TM_TERM PDU is departing the multicast circuit link, of which it is not the master. If two or more stations remain on the link, they may continue to exchange traffic. | ||
| 3 ("UNLINK") | Is sent by the initiator of a multicast circuit link, to cause the link to be torn-down after a final roll call is performed. | ||
| 4 ("UNL_ACK") | Is sent by a participant in a multicast circuit link in response to a TM_TERM PDU with Reason = UNLINK, to indicate that the station has successfully received all traffic sent on the multicast circuit (see note). | ||
| 5 ("UNL_NAK") | Is sent by a participant in a multicast circuit link in response to a TM_TERM PDU with Reason = UNLINK, to indicate that the station is still present in the multicast circuit, but has not received all traffic sent on the multicast circuit successfully. | ||
| 6 ("SUSPEND") | Suspends the current multicast circuit link while the link initiator repeats the 3G-ALE multicast call in order to retrieve as many as possible of the multicast group members that were found to be absent in the most recent roll call. Stations receiving the TM_TERM PDU with Reason = SUSPEND are expected to remain on the traffic channel for a time period sufficient to allow the link initiator to complete the 3G-ALE multicast call, return to the traffic channel, and send a TM_REQ PDU to start another roll call. | ||
| 7 - 63 | reserved | ||
| NOTE: Whether the traffic has been received successfully, and what this means, are determined by the user process and not by TM. | |||
The following sections define the behavior of the TM protocol:
Table C-XXXVII defines the events to which the TM entity responds.
The event names are used in the state diagrams or state transition
tables in C.5.3.5, which define the behavior of the TM protocol.
Some event names refer to the receipt of PDUs from the TM entity
at a remote station; in these cases, either the PDU definition
in C.5.3.4 or the 'description' field of the table entry describes
the manner in which the arrival of a PDU is accomplished through
TM's accepting one or more service primitives from lower-layer
entities at the local station. The prefix 'R:' in the name of
an event indicates that the event is the receipt of a PDU from
the remote station. The prefix 'D:' indicates that the event
is the TM entity's accepting a service primitive from a higher-layer
entity (the primitive is passed 'downward'), while the prefix
'U:' indicates that the event is the TM entity's accepting a service
primitive from a lower-layer entity (the primitive is passed 'upward').
Event names are used in the state diagrams and the transition
table precisely as shown here, with the following exception: italicized
words in the event names shown here are substitution variables
for which explicit parameter- or field-values are substituted
when these event names are used in the state diagrams and the
transition table.
| ConfirmTimeout | A TM_CONF PDU was not received in the time period in which it was expected, in the two-way handshake performed to establish a point-to-point traffic link for packet or circuit traffic, as indicated by a timeout of ConfirmTimer. |
| D:TM_Connect_Req (topology, trafficType, role, addr, reqIntvl) | A TM_Connect_Req service primitive was received from the user process, with the indicated values for the topology, trafficType, role, addr, and reqIntvl parameters. In the state diagrams and state transition table,
|
| D:TM_Disconnect_Req (reason)
D:TM_Disconnect_Req (reason, period) | A TM_Disconnect_Req service primitive was received from the user process, having the indicated value, or one of the provided list of values, as its reason parameter. 'reason' may be either a single parameter value (e.g., "ABORT") or a list of two or more possible reason values separated by 'pipe' characters ('|') (e.g., "ABORT|RELINK"). An event name containing the word 'reason' instead of a specific parameter-value applies to any TM_Disconnect_Req service primitive containing any value for the reason parameter. The value of the period parameter determines the maximum length of time that TM will wait for the link to become available before sending a TM_TERM PDU, if the link is busy (as determined by CLC) at the time the TM_Disconnect_Req service primitive is accepted from the user process. The period parameter is shown on the state diagrams only in those situations in which it is used: i.e., on circuit traffic links after the link has been established (and hence could be busy). In all other contexts, the period parameter-value is ignored. |
| D:TM_Suspend_Req | A TM_Suspend_Req service primitive was received from the user process. |
| D:TM_Resume_Req | A TM_Resume_Req service primitive was received from the user process. |
| DropTimeout | The time limit limiting the period through which TM can wait for the traffic link to become idle before sending a TM_TERM PDU in response to a TM_Disconnect_Req has been exceeded, as indicated by a timeout of DropTimer. |
| EndOfMCRollCall | Indicates that the time period in which stations participating in a multicast circuit link are expected to transmit their roll-call responses has ended, as indicated by the RollCallTimer. |
| EndOfUnlink | Indicates that the time period in which stations participating in a multicast circuit link are expected to transmit their unlink roll-call responses has ended, as indicated by the UnlinkRollCallTimer. |
| MyRCSlot | Indicates that the time-slot allocated to the local station for transmission of its roll call response has arrived, as indicated by the RollCallTimer. See C.5.3.5.5 for a specification of the timing of the multicast roll-call operation. Roll call time slots are assigned to multicast group member stations in the following manner:
|
| other | Refers to any event not corresponding to any of the explicit event labels on transitions leaving the current state. |
| R:other | Refers to the receipt of any PDU not described explicitly by any of the event labels on transitions leaving the current state. |
| R:TM_CONF (pktTraf, srcAddr)
R:TM_CONF (cktTraf, srcAddr) | A TM_CONF PDU was received from the station with individual address srcAddr, confirming establishment of the traffic link requested by a preceding TM_REQ PDU. The Traffic Type field value (represented by 'pktTraf' or 'cktTraf') should be identical to that of the TM_REQ PDU sent most recently by the local station; received TM_CONF PDUs in which this is not the case shall be ignored. If the requested traffic link is a multicast circuit link, then the TM_CONF PDU is a roll call response, which should be received in the correct roll call time-slot of the station having srcAddr as its individual address; any TM_CONF PDU having an incorrect source address for the roll call time slot in which it was received shall be ignored. On point-to-point links, the TM_CONF PDU should be received immediately following the transmission of the TM_REQ PDU to which it is a response; otherwise, a ConfirmTimeout occurs. |
| R:TM_REQ (pktTraf, srcAddr)
R:TM_REQ (cktTraf, srcAddr) | A TM_REQ PDU was received from the station with individual address srcAddr, requesting establishment of a traffic link for delivery of the traffic type represented by 'pktTraf' (HDL_n or LDL_n traffic) or 'cktTraf' (circuit traffic: i.e., neither HDL_n nor LDL_n). |
| R:TM_REQ (cktTraf, srcAddr, MCaddr) | A TM_REQ PDU was received from the station with individual address srcAddr, requesting establishment of a multicast circuit link containing members of the multicast group having address MCaddr, for delivery of the traffic type represented by 'cktTraf' (circuit traffic). |
| R:TM_TERM (reason) | A TM_TERM PDU, having RELINK, ABORT, or SIGN_OFF as the value of its reason parameter, was received from the remote station participating in a point-to-point link. |
| R:TM_TERM (ABORT, srcAddr) | A TM_TERM PDU was received from the station with address 'srcAddr', with reason = ABORT: the sending station is dropping a currently-established circuit link of which it was the master participant. |
| R:TM_TERM (SIGN_OFF, srcAddr) | A TM_TERM PDU was received from the station with address 'srcAddr', with reason = SIGN_OFF: the sending station is signing-off a currently-established circuit link in which it was a slave participant. |
| R:TM_TERM (SUSPEND, srcAddr) | A TM_TERM PDU was received from the station with address 'srcAddr', with reason = SUSPEND: the sending station is suspending a currently-established multicast circuit link of which it was the master participant, while it repeats the multicast call so as to attempt to include additional stations in the circuit link. |
| R:TM_TERM (UNLINK, srcAddr) | A TM_TERM PDU was received from the station with address 'srcAddr', with reason = UNLINK: the sending station is dropping a currently-established multicast circuit link in which it was the master station, and requesting that the stations present in the circuit respond to an unlink roll-call as they leave the circuit. |
| R:TM_TERM (ackNak, srcAddr) | A TM_TERM PDU was received from the station with address 'srcAddr', with reason = UNL_ACK or UNL_NAK: the sending station is leaving the current multicast circuit link, and indicating that it did (if reason = UNL_ACK) or did not (if reason = UNL_NAK) successfully receive the traffic transmitted on the circuit. |
| RequestTimeout | A TM_REQ PDU was not received in the time period in which it was expected, in the course of an attempt to establish a traffic link, as indicated by a timeout of RequestTimer. |
| ReversalTimeout | A TM_REQ PDU was not received in the time period in which it was expected, in the course of an potential packet traffic link reversal, as indicated by a timeout of ReversalTimer. |
| U:CLC_Avail_Ind | A CLC_Avail_Ind service primitive was received from the CLC, indicating that the traffic link is available for new traffic (i.e., not busy). |
| U:CLC_Busy_Ind | A CLC_Busy_Ind service primitive was received from the CLC, indicating that the traffic link is busy (i.e., not available for new traffic). |
| U:CLC_Idle_Ind | A CLC_Idle_Ind service primitive was received from the CLC, indicating that a traffic timeout occurred: no outgoing or incoming traffic was detected on the circuit link over a time period equal to the traffic timeout interval. |
| U:xDL_Rcv_Ind | An HDL_Rcv_Ind or LDL_Rcv_Ind service primitive was received from, respectively, the High-Rate or LDL, indicating that the data link has just successfully completed an incoming datagram transfer. |
| U:xDL_Send_Conf | An HDL_ Send_Conf or LDL_ Send_Conf service primitive was received from, respectively, the High-Rate or LDL, indicating that the data link has just successfully completed an outgoing datagram transfer. |
| NOTE: It is considered unnecessary for the link master to respond to the roll call, since it has indicated its presence by sending the original TM_REQUEST. No roll call response time slot is assigned to the link master at all, since assigning one and leaving it unused could cause a listening station to erroneously declare the channel unused (and hence available) if it were to listen on the channel during the unused time slot. | |
Table C-XXXVIII defines the actions which the TM entity can perform. The action name is used in the state diagrams and/or state transition tables used below to define the behavior of the TM protocol. Some action names refer to sending PDUs to the TM entity at a remote station; in these cases, the PDU definition in C.5.3.4 or the 'description' field of the table entry describes the manner in which sending of the PDU is accomplished by issuing one or more service primitives to subordinate entities at the local station. Action names are used in the state diagrams and the transition table precisely as shown here, with the following exception: italicized words in the action names shown here are substitution variables for which explicit parameter- or field-values are substituted when these action names are used in the state diagrams and the transition table.
| D:CLC_Active_Req | Issue a CLC_Active_Req service primitive to the CLC, requesting that it begin monitoring and arbitrating access to the newly-established circuit link. |
| D:CLC_Idle_Req | Issue a CLC_Idle_Req service primitive to the CLC, requesting that it cease monitoring and arbitrating access to the circuit link. |
| D:CLC_Set_Priority (prio) | Issue a CLC_Set_Priority service primitive, giving it a new priority value for pending outgoing traffic (if any) for the current circuit link. Where the word 'prio' occurs in place of an explicit value for the prio parameter, this indicates that the prio parameter has assigned to it the value of the priority parameter of the TM_Connect_Req primitive that caused the current traffic link to be established. |
| InitRollCall | Initialize (empty) RollCallResponses; initialize and start RollCallTimer. |
| InitUnlink | Initialize (empty) UnlinkResponses; initialize and start UnlinkRollCallTimer. |
| InitWaitForConfirm | Initialize ConfirmTimer to start timing the time-interval in which an incoming TM_CONFIRM PDU is expected in the establishment of a packet or point-to-point circuit link. The timeout interval duration is TBW1 + 2Tprop,max + TBW1enc + 2TBW1proc following the emission of the last sample of an outgoing TM_REQUEST PDU, where the 'Tx' duration constants are as defined in C.5.3.5.5. |
| InitWaitForRequest | Initialize RequestTimer to start timing the time-interval in which an incoming TM_REQUEST PDU is expected in the establishment of a packet or point-to-point circuit traffic link. The timeout interval duration is Ttune + 2Tsug + Tprop,max + TBW1 + TBW1proc following the end of the 3G-ALE time slot in which the LE_HANDSHAKE PDU was transmitted or received, where the 'Tx' duration constants are as defined in C.5.3.5.5. |
| InitWaitForRequest (MC) | Initialize RequestTimer to start timing the time-interval in which an incoming TM_REQUEST PDU is expected in the establishment of a multicast circuit traffic link. The timeout interval duration is Ttraf_wait_mcast + Ttune + 2Tsug + Tprop,max + TBW1 + TBW1proc following the end of the 3G-ALE slot in which the LE_HANDSHAKE PDU specifying the traffic channel for the circuit link was received, where Ttraf_wait_mcast is an initial set-up parameter, and the remaining 'Tx' duration constants are as defined in C.5.3.5.5. |
| InitWaitForRequest (SUSPEND) | Initialize RequestTimer to start timing the time-interval in which an incoming TM_REQUEST PDU is expected after an established multicast circuit traffic link has been suspended. The timeout interval duration is 2TBW1 + TBW1proc + Ttraf_wait_mcast + 2Tdwell + Ttune + 2Tsug + Tprop,max + TBW1 + TBW1proc following the instant in which the last sample of the TM_TERM(SUSPEND) PDU was received, where Ttraf_wait_mcast is an initial set-up parameter, and the remaining 'Tx' duration constants are as defined in C.5.3.5.5. |
| InitWaitForRequest (reqIntvl) | Initialize RequestTimer to start timing the time-interval in which an incoming TM_REQUEST PDU is expected in the establishment of a broadcast traffic link. The value of reqIntvl is supplied by the user process as the reqIntvl parameter-value of the TM_Connect_Req service primitive, and is based on the countdown field-value of the received LE_BROADCAST PDU. |
| InitWaitForReversal | Initialize ReversalTimer to start timing the time-interval in which an incoming TM_REQUEST PDU is expected at the former sending station in a packet traffic link reversal. The timeout interval duration is TBW1 + TBW1proc following the instant at which the arrival of the first sample of an xDL_ACK PDU would have been expected if the preceding data link transfer had not been already completed. In this case, if a request timeout occurs, TM assumes that the remote station did not attempt to reverse the packet traffic link; it is up to the user process at the remote station to set-up a new traffic link (via 3G-ALE and TM) to deliver any packet traffic it has, if an attempted packet link reversal fails. |
| MarkAbsent (srcAddr) | Record in RollCallResponses the fact that no roll call response was received from the station with address srcAddr. |
| MarkLinkAvail | Set LinkBusy to FALSE (since the link is "available"). |
| MarkLinkBusy | Set LinkBusy to TRUE. |
| MarkPresent (srcAddr) | Record in RollCallResponses the fact that a roll call response was received from the station with address srcAddr. |
| MarkReverseTrafficPending | Set ReverseTrafficPending to TRUE. |
| none | No action. |
| RecordUnlinkResponse (ackNak, srcAddr) | Add an entry to UnlinkResponses representing a received unlink roll call response from the station whose individual address is srcAddr, and ackNak is the Reason field value of the response (TM_TERM) PDU: UNL_ACK or UNL_NAK. |
| S:TM_CONF (pktTraf, srcAddr) S:TM_CONF (cktTraf, srcaddr) | Send a TM_CONF ("Confirm") PDU with destAddr = the individual address of the station that initiated the traffic link being established by sending a TM_REQ PDU, and trafficType = the traffic type announced in the TM_REQ PDU. 'pktTraf' represents an announced packet traffic type (HDL_n or LDL_n); 'cktTraf' represents an announced circuit traffic type (neither HDL_n nor LDL_n). |
| S:TM_CONF (cktTraf, MCaddr) | Send a TM_CONF PDU in the local station's roll call time slot., with destAddr = the multicast address of the multicast group for which the circuit link is being established, and trafficType equal to the circuit traffic type value announced in the TM_REQ PDU sent by the link master to initiate the roll call operation. |
| S:TM_REQ (trafficType, destAddr) | Send a TM_REQ PDU requesting establishment of a traffic link, with trafficType = the type of traffic to be delivered on the requested link, and destAddr identifying the stations intended to participate in the link. In the state diagrams and transition table, 'pktTraf' is used to refer to any form of packet traffic delivered by either the High-Rate ('HDL_n') or the LDL ('LDL_n'); 'cktTraf' is used to refer to any traffic type that can be delivered on a circuit link: i.e., any type other than HDL_n or LDL_n. For circuit links, the type of destination address depends on whether the requested link is a point-to-point, multicast, or broadcast link; this is signified in the state diagrams and transition table by the use of the abbreviations 'indAddr', 'MCaddr', and 'BCaddr'. |
| S:TM_TERM (reason, addr, howMany) | Send one or more TM_TERM PDUs having the indicated values for the Reason and Dest Addr fields. addr is the station address of the remote participant in a point-to-point link (circuit or packet), the multicast address of the multicast group participating in a multicast circuit link, or the all-ones broadcast address. The howMany term (which does not refer to a PDU field) indicates how many times the TM_TERM PDU is to be sent:
When 'reason' occurs in the state diagrams or transition table in place of an explicit Reason field-value, this indicates that this field is to be given the value of the Reason parameter of the TM_Disconnect_Req service primitive most recently received from the user process. When 'ackNak' is shown in the reason position, this indicates that the Reason field-value is to be either UNL_ACK or UNL_NAK, depending on whether the station successfully received the traffic transmitted on the multicast circuit which is now being dropped. In this case, the Reason field-value should be the same as the ackNak parameter-value of the TM_Disconnect_Resp service primitive just accepted from the user process. |
| ScheduleAbort | Set ScheduledAbort to TRUE. |
| ScheduleSignoff | Set ScheduledSignoff to TRUE. |
| SetDropTimeout (period) | Set DropTimer to time out and generate a DropTimeout event after an interval of duration period has elapsed. |
| SetupUnlink (ackNak, watch) | Record whether the traffic transmitted on the multicast circuit now being dropped was received successfully, as indicated by the ackNak parameter-value of the TM_Disconnect_Resp service primitive just accepted from the user process. Also record whether the local station is to remain on the traffic channel long enough to hear all of the unlink roll call responses from the participants in the multicast circuit. |
| U:TM_Connect_Conf
U:TM_Connect_Conf (responses) | Issue a TM_Connect_Conf service primitive to the user process, confirming establishment of the requested traffic link, of which the local station is now link master. If the established link is a multicast circuit link, the 'responses' parameter identifies the stations from which roll call responses were received; this parameter is omitted when the link is a point-to-point or broadcast link. |
| U:TM_Connect_Ind (trafficType, srcAddr, responses) | Issue a TM_Connect_Ind service primitive to the user process, indicating that a traffic link has been established of which the local station is a non-master participant. The trafficType parameter identifies the type of traffic for which the traffic link is being established, and should habe the same value as the Argument (Traffic Type) field of the TM_REQ PDU that was sent by the station initiating the traffic link. The srcAddr parameter is the individual address of the station that initiated the traffic link. If the established link is a multicast circuit link, the responses parameter identifies the stations from which roll call responses were received; this parameter is omitted when the link is a point-to-point or broadcast link. |
| U:TM_Disconnect_Conf (reason)
U:TM_Disconnect_Conf (reason, responses) | Issue a TM_Disconnect_Conf service primitive with its reason parameter having the indicated value to the user process. Where the word 'reason' occurs in place of an explicit value for the reason parameter, this indicates that the reason parameter has assigned to it the value of the reason parameter of the TM_Disconnect_Req primitive to which the TM_Disconnect_Conf primitive is a response. The responses parameter is present only if the link being dropped is a multicast circuit link and if an unlink roll call has been performed; in this case, the value of the responses parameter is a list of the unlink roll call responses received by the local station. |
| U:TM_Disconnect_Ind (reason) | Issue a TM_Disconnect_Ind service primitive with its reason parameter having the indicated value to the user process. Where the word 'reason' occurs in place of an explicit value for the reason parameter, this indicates that the reason parameter has assigned to it the value of the 'reason' field of a just-received TM_TERM PDU. |
Table C-XXXIX defines the data items used and maintained by the
TM entity, including buffers, counters, timers, configuration
parameters, and so forth. These data items are referred to by
the names assigned to them here, in the definitions of TM events
and actions presented in the preceding sections. These data items
are used in this specification only as expository devices; it
is not required for compliance that an implementation contain
these data items in the forms described here.
| ConfirmTimer | Timer timing the period in which receipt of a TM_CONF PDU is expected in response to a TM_REQ PDU just sent. |
| DropTimer | Timer timing the interval TM waits for the traffic link to become available (no longer busy) as indicated by CLC, so that TM can send a TM_TERM PDU in response to a TM_Disconnect_Req. |
| LinkBusy | Boolean condition variable: is TRUE if and only if CLC has declared the current circuit link to be busy (without since then having declared it to be non-busy - i.e., available for new traffic). |
| RequestTimer | Timer timing the period in which receipt of a TM_REQ PDU is expected, when the local station is a slave participant in a connection which has just been established by 3G-ALE. The timeout period varies depending on the traffic link topology; see the descriptions of the InitWaitForRequest() actions for further details. |
| ReversalTimer | Timer timing the period in which receipt of a TM_REQ PDU is expected, when the local station has just completed an outgoing data link transfer on a packet traffic link, and is waiting for an indication that the remote station has data link traffic to send on the traffic link. |
| ReverseTrafficPending | Boolean condition variable; when TRUE, indicates that the non-master participant in a packet traffic link has packet traffic to send to the link initiator, and hence that the link direction will be reversed once delivery of the link initiator's packet traffic has been completed. |
| RollCallResponses | List of the system addresses of stations intended to participate in the current multicast circuit link (multicast group members) from which valid roll call responses have been received. |
| RollCallTimer | Timer timing each station's participation in the roll call performed in establishing a multicast circuit link. Provides two time signals (interrupts) to the local station: one when it is time for the local station to send its own roll call response, the other when the time interval for all roll call responses by all participating stations has expired. |
| ScheduledSignoff | Boolean condition variable; when TRUE, causes the local station (non-master participant in a multicast circuit link) to send a TM_TERM PDU signing-off from the circuit link as soon as the roll call currently in progress is completed. |
| ScheduledAbort | Boolean condition variable; when TRUE, causes the local station (master of a multicast circuit link) to send a TM_TERM PDU dropping the circuit link as soon as the roll call currently in progress is completed. |
| UnlinkResponses | List of responses to the optional unlink roll-call performed at the conclusion of a multicast circuit connection, in which each response is in the form of an ordered pair (indAddr, ackNak), where indAddr is the address of a station whose roll call response was heard, and ackNak is the Reason field-value of the TM_TERM PDU sent as the station's response: UNL_ACK or UNL_NAK. |
| UnlinkRollCallTimer | Timer timing each station's participation in the optional roll call that can be performed just before a multicast circuit linkis dropped. Provides two time signals (interrupts) to the local station: one when it is time for the local station to send its own unlink roll call response (if any), the other when the time interval for all unlink roll call responses by all participating stations has expired. |
For the reader's convenience, two equivalent representations of
the behavior of the TM protocol are provided in this section:
the state transition table in table C-XL, and the state diagrams
figures C-21 through C-25. Due to the complexity of the state-machine
behavior, it has been found necessary to represent this behavior
on four different state diagrams. Note that the Idle state shown
on all four diagrams is the same single state: each diagram depicts
only a subset of the transitions entering and leaving the Idle
state.
Both the state diagrams and the transition table specify the behavior
of the TM entity in terms of the events defined in C.5.3.5.1 and
the actions defined in C.5.3.5.2. The conditions gating certain
transitions are specified in terms of the data items defined in
C.5.3.5.3.
In the state diagrams, each state transition is labeled with an
event, an optional condition, and zero or more actions. This
indicates that the state transition occurs whenever the event
occurs and the condition obtains (is TRUE), causing the associated
actions to be performed. In the diagram,
Where a transition is labeled with two or more events, this indicates
that the transition occurs whenever any of the events occurs.
In the state diagrams and the state transition table, text within
text boxes or braces ("{}") is commentary and not part
of the formal state machine definition.
| State | Event | Condition | Action | Next State |
| Idle | D:TM_Connect_Req (P2P, pktTraf, MASTER, indAddr) | S:TM_REQ (pktTraf, indAddr)+ InitWaitForConfirm | Wait for Packet Confirm | |
| D:TM_Connect_Req (P2P, PKT, SLAVE, indAddr) | InitWaitForRequest | Wait for Packet Request | ||
| D:TM_Connect_Req (P2P, cktTraf, MASTER, indAddr) | S:TM_REQ (cktTraf, indAddr)+ InitWaitForConfirm | Wait for P2P Circuit Confirm | ||
| D:TM_Connect_Req (P2P, CKT, SLAVE, indAddr) | InitWaitForRequest | Wait for P2P Circuit Request | ||
| D:TM_Connect_Req (MC, cktTraf, MASTER, MCaddr) | S:TM_REQ (cktTraf, MCaddr)+ InitRollCall | Wait for MC Roll Call Responses | ||
| D:TM_Connect_Req (MC, CKT, SLAVE, MCaddr) | InitWaitForRequest(MC) | Wait for MC Request | ||
| D:TM_Connect_Req (BC, cktTraf, MASTER) | S:TM_REQ (cktTraf, BCaddr)+ U:TM_Connect_Conf | Linked as BC Master | ||
| D:TM_Connect_Req (BC, CKT, SLAVE, BCaddr reqIntvl) | InitWaitForRequest (reqIntvl) | Wait for BC Request | ||
| other | none | Idle | ||
| Wait for Packet Confirm | R:TM_CONF (pktTraf, srcAddr) | U:TM_Connect_Conf | Linked as Packet Master | |
| ConfirmTimeout
R:other | S:TM_TERM (RELINK, indAddr, nx)+
U:TM_Disconnect_Ind (CONF_TIMEOUT) | Idle | ||
| D:TM_Disconnect_Req (ABORT | RELINK) | S:TM_TERM (reason, indAddr, nx)+
U:TM_Disconnect_Conf (reason) | Idle | ||
| R:TM_TERM (reason) | U:TM_Disconnect_Ind (reason) | Idle | ||
| other | none | Wait for Packet Confirm | ||
| Linked as Packet Master | U:xDL_Send_Conf | InitWaitForReversal | Wait for Packet Request | |
| D:TM_Disconnect_Req (ABORT | RELINK) | S:TM_TERM (reason, indAddr, nx)+
U:TM_Disconnect_Conf (reason) | Idle | ||
| R:TM_TERM (reason) | U:TM_Disconnect_Ind (reason) | Idle | ||
| other | none | Linked as Packet Master | ||
| Wait for Packet Request | R:TM_REQ (pktTraf, srcAddr) | S:TM_CONF (pktTraf, srcAddr)+ U:TM_Connect_Ind (pktTraf, srcAddr) | Linked as Packet Slave | |
| D:TM_Disconnect_Req (SIGN_OFF | RELINK) | S:TM_TERM (reason, indAddr)+
U:TM_Disconnect_Conf (reason) | Idle | ||
| R:TM_TERM (reason) | U:TM_Disconnect_Ind (reason) | Idle | ||
| RequestTimeout | S:TM_TERM (RELINK, indAddr)+ U:TM_Disconnect_Ind (REQ_TIMEOUT) | Idle | ||
| ReversalTimeout | U:TM_Disconnect_Ind (EOM) | Idle |
| State | Event | Condition | Action | Next State |
| other | none | Wait for Packet Request | ||
| Linked as Packet Slave | U:xDL_Rcv_Ind | NOT Reverse Traffic Pending | U:TM_Disconnect_Ind (EOM) | Idle |
| U:xDL_Rcv_Ind | Reverse Traffic Pending | S:TM_REQ (pktTraf, srcAddr)+ InitWaitForConfirm | Wait for Packet Confirm | |
| D:TM_Disconnect_Req (SIGN_OFF | RELINK) | S:TM_TERM (reason, indAddr)+
U:TM_Disconnect_Conf (reason) | Idle | ||
| R:TM_TERM (reason) | U:TM_Disconnect_Ind (reason) | Idle | ||
| D:TM_Connect_Req (P2P, pktTraf, MASTER, srcAddr) | MarkReverseTrafficPending | Linked as Packet Slave | ||
| other | none | Linked as Packet Slave | ||
| Wait for P2P Circuit Confirm | R:TM_CONF (cktTraf, srcAddr) | U:TM_Connect_Conf+
D:CLC_Active_Req (P2P) | Linked as P2P Circuit Master | |
| D:TM_Disconnect_Req (ABORT) | S:TM_TERM (ABORT, indAddr, 3x)+
U:TM_Disconnect_Conf (ABORT) | Idle | ||
| R:TM_TERM (reason) | U:TM_Disconnect_Ind (reason) | Idle | ||
| ConfirmTimeout
R:other | S:TM_TERM (RELINK, indAddr, 3x)+
U:TM_Disconnect_Ind (CONF_TIMEOUT) | Idle | ||
| other | none | Wait for P2P Circuit Confirm | ||
| Linked as P2P Circuit Master | R:TM_TERM (reason) | U:TM_Disconnect_Ind (reason)+ D:CLC_Idle_Req | Idle | |
| D:TM_Disconnect_Req (ABORT | RELINK) | NOT LinkBusy | S:TM_TERM (reason, indAddr)+
D:CLC_Idle_Req+ U:TM_Disconnect_Conf (reason) | Idle | |
| D:TM_Disconnect_Req (ABORT | RELINK, period) | LinkBusy | D:CLC_Set_Priority (TM)+
SetDropTimeout (period) | Wait to Drop P2P Circuit, Master | |
| U:CLC_Idle_Ind {traffic timeout} | S:TM_TERM (ABORT, indAddr)+
U:TM_Disconnect_Ind (TRF_TIMEOUT) | Idle | ||
| U:CLC_Busy_Ind | MarkLinkBusy | Linked as P2P Circuit Master | ||
| U:CLC_Avail_Ind | MarkLinkAvail | Linked as P2P Circuit Master | ||
| other | none | Linked as P2P Circuit Master | ||
| State | Event | Condition | Action | Next State |
| Wait to Drop P2P Circuit, Master | U:CLC_Avail_Ind
DropTimeout | S:TM_TERM (reason, indAddr)+
D:CLC_Idle_Req+ U:TM_Disconnect_Conf (reason) | Idle | |
| other | none | Wait to Drop P2P Circuit, Master | ||
| Wait for P2P Circuit Request | R:TM_REQ (cktTraf, srcAddr) | S:TM_CONF (cktTraf, srcAddr)+ U:TM_Connect_Ind (cktTraf, srcAddr)+
D:CLC_Active_Req (P2P) | Linked as P2P Circuit Slave | |
| RequestTimeout
R:other | S:TM_TERM (RELINK, indAddr)+ U:TM_Disconnect_Ind (REQ_TIMEOUT) | Idle | ||
| D:TM_Disconnect_Req (SIGN_OFF | RELINK) | S:TM_TERM (reason, indAddr)+
U:TM_Disconnect_Conf (reason) | Idle | ||
| R:TM_TERM (reason) | U:TM_Disconnect_Ind (reason) | Idle | ||
| other | none | Wait for P2P Circuit Request | ||
| Linked as P2P Circuit Slave | D:TM_Disconnect_Req (SIGN_OFF | RELINK) | NOT LinkBusy | S:TM_TERM (reason, indAddr)+
D:CLC_Idle_Req+ U:TM_Disconnect_Conf (reason) | Idle |
| R:TM_TERM (reason) | U:TM_Disconnect_Ind (reason)+ D:CLC_Idle_Req | Idle | ||
| U:CLC_Idle_Ind {traffic timeout} | S:TM_TERM (SIGN_OFF, indAddr)+
U:TM_Disconnect_Ind (TRF_TIMEOUT) | Idle | ||
| D:TM_Disconnect_Req (SIGN_OFF | RELINK, period) | LinkBusy | D:CLC_Set_Priority (TM)+
SetDropTimeout (period) | Wait to Drop P2P Circuit, Slave | |
| U:CLC_Busy_Ind | MarkLinkBusy | Linked as P2P Circuit Slave | ||
| U:CLC_Avail_Ind | MarkLinkAvail | Linked as P2P Circuit Slave | ||
| other | none | Linked as P2P Circuit Slave | ||
| Wait to Drop P2P Circuit, Slave | U:CLC_Avail_Ind
DropTimeout | S:TM_TERM (reason, indAddr)+
D:CLC_Idle_Req+ U:TM_Disconnect_Conf (reason) | Idle | |
| other | none | Wait to Drop P2P Circuit, Slave | ||
| Wait for MC Roll Call Responses | EndOfMCRollCall | NOT Scheduled Abort | U:TM_Connect_Conf (responses)+
D:CLC_Active_Req (prio) | Linked as MC Master |
| R:TM_CONF (cktTraf, srcAddr) | MarkPresent (srcAddr) | Wait for MC Roll Call Responses |
| State | Event | Condition | Action | Next State |
| D:TM_Disconnect_Req (ABORT) | ScheduleAbort | Wait for MC Roll Call Responses | ||
| other | none | Wait for MC Roll Call Responses | ||
| EndOfMCRollCall | Scheduled Abort | U:TM_Disconnect_Conf (ABORT)+
S:TM_TERM (ABORT, MCaddr, 3x) | Idle | |
| Linked as MC Master | R:TM_TERM (SIGN_OFF, srcAddr) | other stations present | MarkAbsent (srcAddr) | Linked as MC Master |
| R:TM_TERM (SIGN_OFF, srcAddr) | NOT other stations present | MarkAbsent (srcAddr)+ U:TM_Disconnect_Ind (SIGN_OFF)+
S:TM_TERM (ABORT, MCaddr)+ D:CLC_Idle_Req | Idle | |
| D:TM_Disconnect_Req (ABORT, period) | NOT LinkBusy | S:TM_TERM (ABORT, MCaddr)+ D:CLC_Idle_Req+
U:TM_Disconnect_Conf (ABORT) | Idle | |
| D:TM_Disconnect_Req (ABORT, period) | LinkBusy | D:CLC_Set_Priority (TM)+ SetDropTimeout(period) | Wait to Drop MC Circuit, Master | |
| U:CLC_Idle_Ind {traffic timeout} | U:TM_Disconnect_Ind (TRF_TIMEOUT)+
S:TM_TERM (ABORT, MCaddr) | Idle | ||
| U:CLC_Busy_Ind | MarkLinkBusy | Linked as MC Master | ||
| U:CLC_Avail_Ind | MarkLinkAvail | Linked as MC Master | ||
| D:TM_Suspend_Req | S:TM_TERM (SUSPEND, MCaddr, 3x) | Retrieving Absent Members | ||
| D:TM_Disconnect_Req (UNLINK, period) | NOT LinkBusy | S:TM_TERM (UNLINK, MCaddr)+ D:CLC_Idle_Req+
InitUnlink | Unlink MC Circuit, Master | |
| D:TM_Disconnect_Req (UNLINK, period) | LinkBusy | D:CLC_Set_Priority (TM)+ SetDropTimeout (period) | Wait to Unlink, Master | |
| other | none | Linked as MC Master | ||
| Retrieve Absent Members | D:TM_Resume_Req | S:TM_REQ (cktTraf, MCaddr)+ InitRollCall | Wait for MC Roll Call Responses | |
| D:TM_Disconnect_Req (ABORT) | S:TM_TERM (ABORT, MCaddr, 3x)+ U:TM_Disconnect_Conf (ABORT) | Idle | ||
| other | none | Retrieve Absent Members | ||
| Wait to Drop MC Circuit, Master | U:CLC_Avail_Ind
DropTimeout | S:TM_TERM (ABORT, MCaddr)+
D:CLC_Idle_Req+ U:TM_Disconnect_Conf (ABORT) | Idle | |
| other | none | Wait to Drop MC Circuit, Master | ||
| Unlink MC Circuit, Master | R:TM_TERM (ackNak, srcAddr) | RecordUnlinkResponse (ackNak, srcAddr) | Unlink MC Circuit, Master |
| State | Event | Condition | Action | Next State |
| EndOfUnlink
D:TM_Disconnect_Req (ABORT) | U:TM_Disconnect_Conf (reason, responses) | Idle | ||
| other | none | Unlink MC Circuit, Master | ||
| Wait to Unlink, Master | U:CLC_Avail_Ind
DropTimeout | S:TM_TERM (UNLINK, MCaddr)+ D:CLC_Idle_Req+
InitUnlink | Unlink MC Circuit, Master | |
| other | none | Wait to Unlink, Master | ||
| Wait for MC Request | R:TM_REQ (cktTraf, srcAddr, MCaddr) | InitRollCall | Wait for MC Roll Call Responses, Slave | |
| RequestTimeout
R:other | U:TM_Disconnect_Ind (REQ_TIMEOUT) | Idle | ||
| D:TM_Disconnect_Req (SIGN_OFF) | U:TM_Disconnect_Conf (SIGN_OFF) | Idle | ||
| other | none | Wait for MC Request | ||
| Wait for MC Roll Call Responses, Slave | EndOfMCRollCall | NOT Scheduled Signoff | U:TM_Connect_Ind (cktTraf, srcAddr, responses)+
D:CLC_Active_Req (ROUTINE) | Linked as MC Slave |
| R:TM_CONF (cktTraf, srcAddr) | MarkPresent (srcAddr) | Wait for MC Roll Call Responses, Slave | ||
| MyRCSlot | S:TM_CONF (cktTraf, MCaddr) | Wait for MC Roll Call Responses, Slave | ||
| D:TM_Disconnect_Req (SIGN_OFF) | ScheduleSignoff | Wait for MC Roll Call Responses, Slave | ||
| other | none | Wait for MC Roll Call Responses, Slave | ||
| EndOfMCRollCall | Scheduled Signoff | U:TM_Disconnect_Conf (SIGN_OFF)+
S:TM_TERM (SIGN_OFF, MCaddr) | Idle | |
| Linked as MC Slave | R:TM_TERM (SIGN_OFF, srcAddr) | MarkAbsent (srcAddr) | Linked as MC Slave | |
| D:TM_Disconnect_Req (SIGN_OFF, period) | NOT LinkBusy | S:TM_TERM (SIGN_OFF, MCaddr)+
D:CLC_Idle_Req+ U:TM_Disconnect_Conf (SIGN_OFF) | Idle | |
| D:TM_Disconnect_Req (SIGN_OFF, period) | LinkBusy | D:CLC_Set_Priority (TM)+ SetDropTimeout (period) | Wait to Drop MC Circuit, Slave | |
| R:TM_TERM (ABORT, srcAddr) | srcAddr is link master's address | U:TM_Disconnect_Ind (ABORT)+
D:CLC_Idle_Req | Idle |
| State | Event | Condition | Action | Next State |
| U:CLC_Idle_Ind {traffic timeout} | U:TM_Disconnect_Ind (TRF_TIMEOUT) +
S:TM_TERM (SIGN_OFF, MCaddr) | Idle | ||
| U:CLC_Busy_Ind | MarkLinkBusy | Linked as MC Slave | ||
| U:CLC_Avail_Ind | MarkLinkAvail | Linked as MC Slave | ||
| R:TM_TERM (SUSPEND, srcAddr) | InitWaitForRequest(SUSPEND) | Wait for MC Request | ||
| R:TM_TERM (UNLINK, srcAddr) | U:TM_Disconnect_Ind (UNLINK)+ InitSlaveUnlink | Unlink MC Circuit, Slave | ||
| other | none | Linked as MC Slave | ||
| Wait to Drop MC Circuit, Slave | U:CLC_Avail_Ind
DropTimeout | S:TM_TERM (SIGN_OFF, MCaddr)+
D:CLC_Idle_Req+ U:TM_Disconnect_Conf (SIGN_OFF) | Idle | |
| other | none | Wait to Drop MC Circuit, Slave | ||
| Unlink MC Circuit, Slave | D:TM_Disconnect_Resp (ackNak, watch) | SetupUnlink (ackNak, watch) | Unlink MC Circuit, Slave | |
| R:TM_TERM (ackNak, srcAddr) | RecordUnlinkResponse (ackNak, srcAddr) | Unlink MC Circuit, Slave | ||
| MyUnlinkSlot | WatchUnlink Resps | S:TM_TERM (ackNak, MCaddr) | Unlink MC Circuit, Slave | |
| MyUnlinkSlot | NOT Watch UnlinkResps | S:TM_TERM (ackNak, MCaddr)+ U:TM_Disconnect_Conf (UNLINK, responses) | Idle | |
| EndOfUnlink
D:TM_Disconnect_Req (SIGN_OFF) | U:TM_Disconnect_Conf (reason, responses) | Idle | ||
| other | none | Unlink MC Circuit, Slave | ||
| Linked as BC Master | D:TM_Disconnect_Req (ABORT) | S:TM_TERM (ABORT, BCaddr)+
U:TM_Disconnect_Conf (ABORT) | Idle | |
| other | none | Linked as BC Master | ||
| Wait for BC Request | R:TM_REQ (cktTraf, srcAddr) | U:TM_Connect_Ind (cktTraf, srcAddr)+
D:CLC_Active_Req (ROUTINE) {CLC used only for traffic timeout} | Linked as BC Slave |
| State | Event | Condition | Action | Next State |
| RequestTimeout
R:other | U:TM_Disconnect_Ind (REQ_TIMEOUT) | Idle | ||
| D:TM_Disconnect_Req (SIGN_OFF) | U:TM_Disconnect_Conf (SIGN_OFF) | Idle | ||
| other | none | Wait for BC Request | ||
| Linked as BC Slave | D:TM_Disconnect_Req (SIGN_OFF) | D:CLC_Idle_Req+
U:TM_Disconnect_Conf (SIGN_OFF) | Idle | |
| R:TM_TERM (ABORT, srcAddr) | srcAddr is link master's address | U:TM_Disconnect_Ind (ABORT)+
D:CLC_Idle_Req | Idle | |
| U:CLC_Idle_Ind (traffic timeout} | U:TM_Disconnect_Ind (TRF_TIMEOUT) | Idle | ||
| other | none | Linked as BC Slave | ||
The protocol timing characteristics vary depending on which kind
of traffic link is being established. The sub-sections of this
section describe the timing characteristics applying to establishment
and execution of, respectively, point-to-point packet traffic
links, point-to-point circuit links, and multicast circuit links.
Table C-XLI gives definitions of time intervals used in presenting
the protocol timing characteristics.
|
|
| |||
| Tslot | 60 | 1920 | 800 | Duration of 3G-ALE slot. | |
| Tdwell | 300 | 9600 | 4000 | Duration of 3G-ALE dwell. | |
| Tsug | 4 | 128 | 53.33 | LE sync uncertainty guard interval | |
| Ttune | 45 | 1600 | 666.67 | TM coupler tune allowance | |
| Tprop,max | 6 | 192 | 80.00 | maximum propagation delay | |
| TBW0proc | 8 | 128 | 53.33 | BW0 processing time (after last sample is received) | |
| TBW1enc | 5 | 160 | 66.67 | BW1 encoding time (prior to emission of first sample) | |
| TBW1 | 98 | 3136 | 1306.67 | BW1 transmission duration (TLC+preamble+data) | |
| TBW1proc | 10 | 320 | 133.33 | BW1 processing time (after last sample is received) | |
| TBW2enc | 22 | 704 | 293.33 | BW2 encoding time (prior to emission of first sample) | |
| TBW2 | 2 | 5+20n | 304+960n | 126.67+ (n*400.00) | BW2 transmission duration -- n packets per transmission (n = 3, 6, 12, or 24) |
| TBW2(3) | 2 | 65 | 3184 | 1326.67 | BW2 transmission duration (3 packets per transmission) |
| TBW2(6) | 2 | 125 | 6064 | 2526.67 | BW2 transmission duration (6 packets per transmission) |
| TBW2(12) | 2 | 245 | 11824 | 4926.67 | BW2 transmission duration (12 packets per transmission) |
| TBW2(24) | 2 | 485 | 23344 | 9726.67 | BW2 transmission duration (24 packets per transmission) |
| TBW2proc | 11 | 528 | 220.00 | BW2 processing time (after last sample is received) | |
| TBW3enc | 5 | 160 | 66.67 | BW3 encoding time (prior to emission of first sample) | |
| TBW3 | 28+n | 896+32n | 373.33+ (n*13.33) | BW3 transmission duration (preamble+data) - n payload bytes per transmission (n = 64, 128, 256, or 512) | |
| TBW3(64) | 92 | 2944 | 1226.67 | BW3 transmission duration (preamble+data) - 64 payload bytes per transmission | |
| TBW3(128) | 156 | 4992 | 2080.00 | BW3 transmission duration (preamble+data) - 128 payload bytes per transmission | |
| TBW3(256) | 284 | 9088 | 3786.67 | BW3 transmission duration (preamble+data) - 256 payload bytes per transmission | |
| TBW3(512) | 540 | 17280 | 7200.00 | BW3 transmission duration (preamble+data) - 512 payload bytes per transmission | |
| TBW3proc | 5 | 160 | 66.67 | BW3 processing time (after last sample is received) | |
| TBW4enc | 5 | 160 | 66.67 | BW4 encoding time (prior to emission of first sample) | |
| TBW4 | 48 | 1536 | 640.00 | BW4 transmission duration (TLC+data) |
|
|
| |||
| TBW4proc | 5 | 160 | 66.67 | BW4 processing time (after last sample is received) | |
| TTM,Master | Duration of the initial TM handshake at the link master station. TTM,Master = Tsug + 2TBW1 + 2Tprop,max + 2TBW1proc + TBW1enc. | ||||
| TRTFD, HDL | Time from start of TM_REQUEST PDU to start of first HDL_DATA PDU. TRTFD, HDL = 2TBW1 + 2Tprop,max + 2TBW1proc + TBW1enc + TBW2enc. | ||||
| TCTFA(n), HDL | Time from start of TM_CONFIRM PDU to start of first HDL_ACK PDU. TCTFA, HDL = TBW1 + TBW1proc + 2Tprop,max +TBW2enc + TBW2(n) +T BW2proc + TBW1enc. | ||||
| THDL(n) | Period of HDL protocol. THDL(n) = TBW2enc + TBW2(n) +2Tprop,max + TBW2proc + TBW1enc + TBW1 + TBW1proc. | ||||
| TRTFD, LDL | Time from start of TM_REQUEST PDU to start of first LDL_DATA PDU. TRTFD, LDL = 2TBW1 + 2Tprop,max + 2TBW1proc + TBW1enc + TBW3enc. | ||||
| TCTFA(n), LDL | Time from start of TM_CONFIRM PDU to start of first LDL_ACK PDU. TCTFA, LDL(n) = TBW1 + TBW1proc + 2Tprop,max +TBW3enc + TBW3(n) + T BW3proc + TBW4enc. | ||||
| TLDL(n) | Period of LDL protocol. TLDL(n) = TBW3enc + TBW3(n) + 2Tprop,max + TBW3proc + TBW4enc + TBW4 + TBW4proc. | ||||
| Trc slot,TM | Duration of TM roll call slot. Trc slot,TM = TBW1enc + TBW1 + 2*Tprop,max + TBW1proc | ||||
| TCLenc | 15 | 2400 | 1000.00 | MIL-STD-188-110 serial tone (see note) modem transmit startup delay: the permitted time interval between presentation of the first bit of data to the modem for modulation (when RTS is asserted), and emission of the first time-sample of the modem preamble. Note that this delay is not required for encoding per se, since MIL-STD-188-110 modems typically start emitting the modem preamble simultaneously with encoding the first bit of traffic data. The modem startup delay defined here is a characteristic of modem implementations rather than of the MIL-STD-188-110 standard. |
|
|
| |||
| TCLpre | 15 | 480 | 200.00 | Duration of a single period of the Mil-Std-188-110A serial tone modem preamble: the minimum portion of the modem preamble that must be received and processed to successfully detect and acquire sync with an incoming modem transmission. | |
| TCLproc | 15 | 480 | 200.00 | Mil-Std-188-110A serial tone modem acquisition processing delay: the processing time required following receipt of the last sample of a 200 ms. Preamble period, before the receiving modem can declare modem signal presence based on having acquired the preamble. | |
| NOTE: Timing analyses for circuit links assume that these links are used for bit-pipe delivery of data using
MIL-STD-188-110 serial tone modems; the timings used for delivery of other kinds of traffic on circuit links are the same. | |||||
This section will first provide a description of point-to-point
packet link timing. Following this, point-to-point packet link
timing requirements will be given.
The contents of this section are for informational purposes only.
The TM phase of the point-to-point packet link is considered to
begin at the end of the 3G-ALE time-slot in which the LE_COMMENCE
PDU (see note) is transmitted. Since only a two-way TM handshake
is performed, it is not possible for both stations to estimate
the propagation delay between them. Instead, in each direction,
the TM handshake signalling is used to establish the timing for
all subsequent signalling in that direction. In the forward direction,
the first xDL_DATA PDU (High-Rate or Low-Rate) is sent at a fixed
time interval known a priori to both stations, following
the transmission of the TM_REQUEST PDU. Likewise, in the reverse
direction, the first xDL_ACK PDU is sent at a fixed time interval
known a priori to both stations, following the transmission
of the TM_CONFIRM PDU. The entire process is depicted on figure
C-26 through figure C-30, and analyzed in further detail below,
using the HDL protocol for the purpose of illustration.
Note: I.e., an LE_HANDSHAKE PDU in which the Command field's
value is "Commence Traffic".
The linking activity proceeds as follows:
A similar analysis defines the timing structure for point-to-point
packet traffic links using the LDL protocol, with the following
substitutions:
The following requirements apply to point-to-point packet link
timing:
This section will first provide a description of point-to-point
circuit link timing. Following this, point-to-point circuit link
timing requirements will be given.
The contents of this section are for informational purposes only.
Figure C-31 provides an example point-to-point circuit link. The
linking activity proceeds as follows:
The following requirements apply to point-to-point circuit link
timing:
This section will first provide a description of multicast circuit
link timing. Following this, multicast circuit link timing requirements
will be given.
The contents of this section are for informational purposes only.
Figure C-32 shows an example multicast circuit link involving
a Master and 3 Slaves. The linking activity for this example proceeds
as follows:
The following requirements apply to multicast circuit link timing:
The HDL is used to provide acknowledged point-to-point delivery
of datagrams from a transmitting station to a receiving station
across an already-established HF link, with selective retransmission
(ARQ) of data received in error. The datagram passed to the HDL
for delivery is a finite-length ordered sequence of 8-bit data
bytes (octets). The HDL protocol is best suited to delivering
relatively large datagrams under good to fair HF channel conditions.
By contrast, the LDL protocol described in section C.5.5 provides
better performance for all datagram lengths under fair to very
poor HF channel conditions, and under all channel conditions for
short datagrams.
The terms defined in table C-XLII are used to refer to specific
types of data objects in defining the HDL protocol.
| datagram | an ordered sequence of 8-bit data bytes (octets) of length dl, where 1 < dl < 7,634,944 (equal to (233 * 32,768) - 233 payload data bytes per data packet, and 32,768 data packets per datagram). |
| data segment | an ordered sequence of 8-bit data bytes (octets) that occur consecutively within a datagram, of length sl where 1 < sl < 233. |
| sequence number | a 17-bit data object having the format defined in table C-XLV, which indicates the position occupied by a data segment within a datagram, and, when the data segment includes the last data byte of the datagram, the number of bytes of payload data from the datagram in the data segment. |
| data packet | the combination of a data segment with the sequence number indicating its position within a datagram. If the data segment is of length less than 233 bytes (because it includes the last data byte of the datagram), a sequence of null data bytes (of value zero) is appended to the data segment so as to extend it to length 233 in constructing the data packet, and the value of the sequence number indicates how many of the 233 bytes in the extended data segment contain payload data from the datagram. |
| tx frame | a sequence of np data packets, where np = 24, 12, 6, or 3, and the value of np is determined by the numPkts parameter of the most recent HDL_Send_Req or HDL_Rcv_Req service primitive. Same as an HDL_DATA PDU as defined in C.5.4.4.1. |
| packet index | a number indicating the ordinal position of a data packet within a tx frame, such that packet index = 0 indicates that the data packet occupies the first position in the tx frame. |
| indexed packet | the combination of a data packet with the packet index indicating the data packet's ordinal position within a specific tx frame. |
| rx frame | a sequence of np indexed packets, where 0 < np < 24, which includes an indexed packet containing each data packet that was received without errors (as determined by checking its CRC) in an incoming tx frame. np is never greater than the value of the numPkts parameter of the most recent HDL_Rcv_Req service primitive, but may be less due to packets' having been omitted from the rx frame (by the BW2 receiver) due to their having been received containing errors. |
Table C-XLIII describes the service primitives exchanged between
the HDL protocol entity HDL and one or more user processes at
HDL's upper interface. These service primitives are used in this
specification only as expository devices, and are not required
to be present in any compliant implementation of the protocol.
Note that there is no requirement that implementations of the
waveforms and protocols defined in this Appendix contain precisely
these service primitives; nor are the services primitives defined
below necessarily all of the service primitives that would be
required in an implementation of these waveforms and protocols.
The sub-sections of this section describe the PDUs exchanged between
a HDL protocol HDL entity and its remote peer entities.
An HDL_DATA PDU is a tx frame as defined in table C-XLII, in which
the format and contents of each data packet are as shown in table
C-XLIV. Table C-XLVspecifies the format and contents of the Sequence
Number field of each data packet.
| HDL_Send_Req | Overview | HDL Send Request: generated by the user process when it has a datagram to send on an already-established HF link. | ||
| Parameters | datagram | datagram to be delivered, as described in table C-XLII. | ||
| numPkts | the number np of data packets to be transmitted in each forward transmission by BW2 (i.e., each tx frame), where np = 24, 12, 6, or 3. | |||
| Originator | User process | |||
| Preconditions | TM has just completed a successful point-to-point HF link establishment with the intended datagram recipient. | |||
| HDL_Rcv_Req | Overview | HDL Receive Request: generated by the user process to request that HDL perform the processing required to receive an expected incoming datagram. | ||
| Parameters | numPkts | the number np of data packets that will be received in each incoming transmission by BW2, where np = 24, 12, 6, or 3. | ||
| Originator | User process | |||
| Preconditions | TM has just completed a successful point-to-point HF link establishment with the expected datagram sender. | |||
| HDL_Rcv_Ind | Overview | HDL Receive Indication: issued by HDL when HDL has a successfully-received datagram to give to the local user process. | ||
| Parameters | datagram | datagram just received, as described in table C-XLII; identical to the original datagram parameter-value of the HDL_Send_Req primitive at the remote station. | ||
| Originator | HDL | |||
| Preconditions | HDL has received an HDL_Rcv_Req since the last outgoing or incoming datagram transfer. | |||
| HDL_Send_Conf | Overview | HDL Send Confirm: Issued by HDL when HDL has completed successful delivery of a datagram to the remote station. | ||
| Parameters | (none) | |||
| Originator | HDL | |||
| Preconditions | HDL was requested to deliver the datagram by the user process by means of an HDL_Send_Req service primitive. | |||
| HDL_Abort_Req | Overview | HDL Abort Request: used by the user process to terminate a HDL protocol data transfer that is currently in progress. The purpose of this service primitive is only to cause the HDL entity to cease attempting to send or receive the current datagram; coordinating the data transfer termination with the remote station is the responsibility of TM. | ||
| Parameters | (none) | |||
| Originator | User process | |||
| Preconditions | Either an outgoing or an incoming data transfer is in progress, using the HDL protocol. | |||
| HDL_Failure_Ind | Overview | HDL Failure Indication: Issued by HDL when HDL is unable to complete delivery of an outgoing or incoming datagram. | ||
| Parameters | (none) | |||
| Originator | HDL | |||
| Preconditions | Either an outgoing or an incoming data transfer is in progress, using the HDL protocol. | |||
| Payload | 1864 (fixed) | any | Contains a data segment as defined in table C-XLII, followed by however many zero bytes are needed to fill the Payload field to length 233 bytes. Whenever the field contains fewer than 233 bytes of payload data (from the outgoing datagram), the value of the Sequence Number field indicates how many bytes of payload data are present. |
| Sequence Number | 17 (fixed) | As defined by table C-XLV. | |
The bytes of the Payload field are transmitted in the order of
their occurrence in the datagram; the bits of each byte are transmitted
in order of significance, starting with the most significant bit.
|
| |||
| only packet in datagram | Payload field byte count: the number of bytes (octets) of datagram data present in the Payload field of the packet. | |||
| last packet in datagram | Payload field byte count (see above) | |||
| first packet in datagram | number of packets required to convey the data contents of the datagram, minus one: equal to (the least integer greater than or equal to (datagram length in bytes / 233)) - 1. | |||
| packet in interior of datagram | down-counting packet sequence number: the number of packets in the current datagram, following the current packet. | |||
Following the last bit of the Payload field-value, the bits of
the Sequence Number field are transmitted in order of significance
within the 17-bit field-value, starting with the most significant
bit (bit 16).
The HDL_ACK PDU is used to transfer selective acknowledgements,
in the form of an ack bit-mask containing a single bit for each
data packet in an HDL_DATA PDU, from the receiving station to
the sending station in a HDL transfer. Table C-XLVI specifies
the format and contents of the HDL_ACK PDU.
| |||
| Protocol | 3 | 0002 = HDL | identifies this PDU as an HDL PDU |
| Type | 1 | 02 = ACK | Identifies this PDU as an HDL_ACK PDU |
| Ack Bit-Mask | 24 | any | Contains one ack bit for each of the data packets that can be received in an HDL_DATA PDU. Each bit indicates whether the corresponding data packet was received without errors; 1 = ACK (was received successfully); 0 = NAK (not received successfully). |
| Reserved | 4 | 00002 (fixed) | Reserved for future use. |
| CRC | 16 | any | 16-bit Cyclic Redundancy Check (CRC) computed across the values of the Type and Ack Bit-Mask fields, using the generator polynomial
X16 + X15 + X11 + X8 + X6 + X5 + X4 + X3 + X1 + 1, and the procedure described in C.4.1. |
The fields of the HDL_ACK PDU are transmitted in the order of
their occurrence in table C-XLVI, protocol field first. Bits
of the Ack Bit-Mask field are transmitted in the order in which
the corresponding data packets were transmitted in the HDL_DATA
PDU that is being acknowledged; for instance, the first ack bit
acknowledges the first data packet.
The HDL_EOM PDU is sent from the sending station to the receiving
station in a HDL transfer, to indicate that the sending station
has received acknowledgements from the receiving station of every
data packet in the datagram being transferred, and hence will
send no more HDL_DATA PDUs for the current datagram. The HDL_EOM
PDU is sent as many times as possible within the time interval
defined for a forward transmission (based on the value of numPkts),
to maximize the probability of its being received without errors.
Table C-XLVII specifies the format and contents of the HDL_EOM
PDU.
| |||
| Protocol | 3 | 0002 = HDL | identifies this PDU as an HDL PDU |
| Type | 1 | 12 = EOM | Identifies this PDU as an HDL_EOM PDU. |
| Check | 44 | 0xA5A5A5A5A5A | Unused, but should be inspected by the recipient to verify that it contains the correct bit-pattern specified here. |
On traffic links established for packet traffic delivered using
the HDL protocol, the user process can terminate the data link
transfer and use the next data link transmission time slot in
either direction - i.e., the time slot for the HDL_DATA or the
HDL_ACK PDU - to instead send one or more TM PDUs (described in
C.5.3.4) within the data link PDU time-slot. This means that
while a HDL transfer is in progress, the receiving station must
be simultaneously attempting to demodulate TM PDUs conveyed by
the BW1 waveform as it is attempting to demodulate and receive
HDL_DATA PDUs conveyed by BW2. The sending station may receive
a TM PDU conveyed by BW1 in place of an HDL_ACK PDU (also BW1),
and must ensure that this PDU is received and processed by its
TM sublayer.
This section provides an informal overview of the behavior of
the HDL protocol. The following sections define this behavior
precisely:
Data transfer by HDL begins after the TM sublayer has already
established the data link connection, in so doing negotiating
the fact that HDL will be used (as opposed to LDL or some other
mechanism), the number of data packets to be sent in each HDL_DATA
PDU, and the precise time synchronization of data link transmissions.
In an HDL data transfer, the sending station and the receiving
station alternate transmissions in the manner depicted in figure
C-33, the sending station transmitting HDL_DATA PDUs containing
payload data packets, and the receiving station transmitting HDL_ACK
PDUs containing acknowledgements of the data packets received
without errors in the preceding HDL_DATA PDU. If either station
fails to receive a PDU at the expected time, it sends its own
next outgoing PDU at the same time as if the incoming PDU had
been received successfully. The times at which the burst waveforms
conveying HDL_DATA, HDL_ACK, and HDL_EOM PDUs may be emitted are
precisely stipulated; see C.5.4.5.5 for details.
The end of a data transfer is reached when the sending station
has transmitted HDL_DATA PDUs containing all of the payload data
in the delivered datagram, and the receiving station has received
these data without errors and has acknowledged their successful
delivery. When the sending station receives an HDL_ACK PDU indicating
that the entire contents of the datagram have been delivered successfully,
it sends an HDL_EOM PDU repeated as many times as possible within
the duration of an HDL_DATA PDU, starting at the time at which
it would have otherwise transmitted the next HDL_DATA PDU, to
indicate to the receiving station that the data transfer will
be terminated. This link termination scenario is depicted in
figure C-34.
The definition of HDL behavior presented in the following sections
includes mechanisms for dealing appropriately with the following
occurrences:
Table C-XLVIII defines the events to which the HDL entity responds.
The event names are used in the state diagram and the state transition
table in C.5.4.5.4, which define the behavior of the HDL protocol.
Some event names refer to the receipt of PDUs from the HDL entity
at a remote station; in these cases, the 'description' field of
the table entry describes the manner in which the arrival of a
PDU is accomplished through HDL's accepting one or more service
primitives from lower-layer entities at the local station. The
prefix 'R:' in the name of an event indicates that the event is
the receipt of a PDU from the remote station. 'D:' indicates that
the event is an HDL service primitive passed down to HDL from
a higher-layer entity; 'U:' indicates a lower-layer service primitive
passed up to HDL from a lower-layer entity.
| R:HDL_DATA PDU | A BW2_Receive primitive containing an HDL_DATA PDU was accepted. |
| R:HDL_ACK PDU | A BW1_Receive primitive containing an HDL_ACK PDU was accepted, and the HDL_ACK PDU was found to be free of errors by checking its CRC. |
| R:HDL_EOM PDU | A BW1_Receive primitive containing a HDL_EOM PDU was accepted, and the HDL_EOM PDU was found to be free of errors by comparing the received PDU against the known HDL_EOM bit pattern specified in table C-XLVII. |
| D:HDL_Send_Req | An HDL_Send_Req primitive was accepted from the user process. |
| D:HDL_Abort_Req | An HDL_Abort_Req primitive was accepted from the user process. |
| AckTimeout | A valid HDL_ACK PDU was not received within the time period in which it was expected. |
| DataTimeout | An HDL_DATA PDU was not received within the time period in which it was expected. |
Table C-XLIX defines the actions which the HDL entity can perform.
The action name is used in the state diagrams and/or state transition
tables used below to define the behavior of the HDL protocol.
Some action names refer to sending PDUs to the HDL entity at
a remote station; in these cases, the 'description' field of the
table entry describes the manner in which sending of the PDU is
accomplished by issuing one or more service primitives to lower-layer
entities at the local station.
Table C-L defines the data items used and maintained by HDL, including
buffers, counters, timers, configuration parameters, and so forth.
These data items are referred to by the names assigned to them
here, in the definitions of HDL events and actions presented in
the preceding sections. These data items are used in this specification
only as expository devices, and are not required to be present
in any compliant implementation of the protocol.
| TxInit | Set NumPktsTx to the value of the numPkts parameter of the HDL_Send_Req primitive. Insert the outgoing datagram into TxDatagramBuf. Clear TxFrameBuf. Reset MissedAckCount to zero. |
| S:HDL_DATA | For each of the first NumPktsTx data packet positions in TxFrameBuf, if the data packet position is empty, construct a new outgoing data packet (as described by table C-XLIV) in this position:
If TxDatagramBuf is completely emptied of payload data before all packet positions in TxFrameBuf have been filled with new packets, fill the remaining packet positions with repetitions of packets already residing in other positions of TxFrameBuf. Note: The HDL transmitter is at liberty to select packets from the current datagram to repeat as it pleases; the HDL receiver must inspect the sequence number of each packet received without errors, and use this information to discard duplicate packets. Send an HDL_DATA PDU containing the tx frame in TxFrameBuf, using a BW2_Send primitive. Set the primitive's reset parameter to TRUE if this is the first tx frame transmitted for the current datagram, and to FALSE otherwise. Reset the AckTimeout timer. If an AckTimeout has occurred, increment MissedAckCount. |
| ProcessAck | Check the HDL_ACK PDU's CRC. If the CRC is valid:
|
| S:HDL_EOM | Send an HDL_EOM PDU to the remote station using BW1_Send, as many times as possible within the duration of an HDL_DATA PDU. The number of times the HDL_EOM PDU is sent depends on the value of NumPktsTx as follows:
Disable AckTimeout timer. |
| U:HDL_Send_Conf | Issue an HDL_Send_Conf primitive to the user process that requested the outgoing data transfer. |
| AbortTransmit | Disable AckTimeout timer; reset MissedAckCount to zero. |
| RxInit | Set NumPktsRx to the value of the numPkts parameter of the HDL_Rcv_Req primitive.
Clear RxDatagramBuf, and RxFrameBuf. Reset MissedTxFrameCount to zero. Set CompleteDatagramRcvd to FALSE. |
| S:HDL_ACK(ack/nak) | Clear TxAck to all zeroes.
Reset MissedTxFrameCount to zero. if CompleteDatagramRcvd is FALSE then For each indexed packet received from the BW2 receiver,
else (CompleteDatagramRcvd is TRUE) Set the first NumPktsRx bits of TxAck to 1. end if Send an HDL_ACK PDU containing TxAck, using BW1_Send. Reset the DataTimeout timer. Note: An implementation of HDL can, without impairing compliance to this standard, provide segments of a partially-received datagram to the user process, in order of their occurrence in the original datagram at the sending station, before the entire datagram has been received. Doing so would allow a higher-layer protocol to abort an ongoing data transfer, then resume it at a later time, without having to retransmit the entire portion of the current datagram that was already delivered successfully. Note: The HDL transmitter can send duplicate packets either as a result of missing an HDL_ACK PDU, or at the end of a datagram, in order to fill the (otherwise unused) packet positions of an HDL_DATA PDU. The HDL receiver is required to inspect the sequence number of each data packet received without errors, and to use the sequence numbers to identify and discard duplicate packets. |
| S:HDL_ACK(naks) | Reset the DataTimeout timer.
Clear TxAck to all zeroes. Send an HDL_ACK PDU containing TxAck using BW1_Send. If a DataTimeout has occurred, increment MissedTxFrameCount. |
| U:HDL_Rcv_Ind | Issue an HDL_Rcv_Ind primitive containing the received datagram to the user process. |
| AbortReceive | Disable DataTimeout timer; reset MissedTxFrameCount to zero. |
| NumPktsTx | the number of data packets in each tx frame, as negotiated during the Traffic Set-Up (TSU) phase. |
| TxDatagramBuf | buffer storing the data contents of an outgoing datagram which have not yet been inserted into a tx frame for transmission. |
| TxFrameBuf | buffer storing the sequence of NumPkts data packets contained in an outgoing tx frame (an HDL_DATA PDU). |
| NumPktsRx | the maximum number of data packets in each incoming rx frame, as negotiated during the Traffic Set-Up (TSU) phase. |
| RxDatagramBuf | buffer storing the data contents of an incoming datagram which have been received thus far, in which the complete incoming datagram is re-assembled in correct order. |
| RxFrameBuf | buffer storing those incoming data packets of an rx frame which were received without errors (as determined by the CRC check performed by the BW2 receiver). |
| TxAck | ack flag sequence to be transmitted to the remote station. Contains one bit-flag for each data packet in a maximum-length tx frame; TxAck[i] = 1 indicates that the ith data packet in the most recently received rx frame was received without errors. |
| RxAck | ack flag sequence received in an HDL_ACK PDU from the remote station. Contains one bit-flag for each data packet in a maximum-length tx frame; RxAck[i] = 1 indicates that the remote station received the ith data packet in the previously-transmitted rx frame without errors. |
| MissedAckCount | count of consecutive failures to receive an HDL_ACK PDU in the time period in which one was expected. |
| MissedTxFrameCount | count of consecutive failures to receive an HDL_DATA PDU (a tx frame) in the time period in which one was expected. |
| AckTimeout | timer used to time the duration of the interval in which receipt of an HDL_ACK PDU is expected; fires when the interval expires. |
| DataTimeout | timer used to time the duration of the interval in which receipt of an HDL_DATA PDU is expected; fires when the interval expires. |
| MAX_MISSED_ACKS | HDL configuration parameter specifying the maximum number of consecutive missed HDL_ACK PDUs that can occur without causing the HDL transmitter to terminate the data link transfer. The value of this parameter is not stipulated by this specification, since it is not required for interoperability that this parameter have identical values in both the sending and receiving stations. |
| MAX_MISSED_TX_FRAMES | HDL configuration parameter specifying the maximum number of consecutive missed HDL_DATA PDUs that can occur without causing the HDL receiver to terminate the data link transfer. The value of this parameter is not stipulated by this specification, since it is not required for interoperability that this parameter have identical values in both the sending and receiving stations. |
| MoreToSend | Boolean condition variable: is TRUE if and only if an outgoing datagram transfer is in progress, and there are one or more data packets in the datagram for which the local station has not yet received an acknowledgement of their receipt without errors by the remote station. |
| CompleteDatagramRcvd | Boolean condition variable: is TRUE if and only if an incoming datagram transfer has been successfully completed (all contents of the datagram received without errors), but an HDL_Rcv_Ind primitive has not yet been issued to the user process. |
For the reader's convenience, two equivalent representations of
the behavior of the HDL protocol are provided in this section:
the state transition table in table C-LI, and the state diagram
in figure C-35.
Both table C-LI and figure C-35 specify the behavior of HDL in
terms of the events defined in C.5.4.5.1 and the actions defined
in C.5.4.5.2. The conditions gating certain transitions are specified
in terms of the data items defined in C.5.4.5.3.
In the state diagram, each state transition is labeled with an
event, an optional condition, and zero or more actions. This
indicates that the state transition occurs whenever the event
occurs and the condition obtains (is TRUE), causing the associated
actions to be performed. In the diagram,
Where a transition is labeled with two or more events, this indicates
that the transition occurs whenever any of the events occurs.
| Idle | D:HDL_Send_Req | TxInit + S:HDL_DATA | Send | |
| D:HDL_Rcv_Req | RxInit | Receive | ||
| other | none | Idle | ||
| Send | R:HDL_ACK | MoreToSend | ProcessAck + S:HDL_DATA | Send |
| R:HDL_ACK | NOT MoreToSend | ProcessAck + S:HDL_EOM + U:HDL_Send_Conf | Idle | |
| AckTimeout | MissedAckCount < MAX_MISSED_ACKS | S:HDL_DATA | Send | |
| AckTimeout | MissedAckCount == MAX_MISSED_ACKS | AbortTransmit + U:HDL_Failure_Ind | Idle | |
| D:HDL_Abort_Req | AbortTransmit | Idle | ||
| other | none | Send | ||
| Receive | R:HDL_DATA | S:HDL_ACK(ack/nak) | Receive | |
| R:HDL_EOM | U:HDL_Rcv_Ind | Idle | ||
| DataTimeout | MissedTxFrameCount < MAX_MISSED_TX_FRAMES | S:HDL_ACK(naks) | Receive | |
| DataTimeout | (MissedTxFrameCount == MAX_MISSED_TX_FRAMES)
AND NOT CompleteDatagramRcvd | AbortReceive + U:HDL_Failure_Ind | Idle | |
| DataTimeout | (MissedTxFrameCount == MAX_MISSED_TX_FRAMES) AND CompleteDatagramRcvd | AbortReceive + U:HDL_Rcv_Ind | Idle | |
| D:HDL_Abort_Req | AbortReceive | Idle | ||
| other | none | Receive | ||
See C.5.3.5.5, which includes an analysis of the timing of the
HDL protocol in conjunction with TM protocol timing.
The LDL protocol is used to provide reliable acknowledged point-to-point
delivery of datagrams from a transmitting station to a receiving
station across an already-established HF link. The datagram passed
to the LDL protocol entity for delivery is a finite-length ordered
sequence of 8-bit data bytes (octets). The LDL protocol provides
improved performance for all datagram lengths under fair to very
poor HF channel conditions, and under all channel conditions for
short datagram lengths.
The terms defined in table C-LII are used to refer to specific
types of data objects in defining the LDL protocol.
| datagram | an arbitrary sequence of 8-bit data bytes (octets) of length dl, where 1 < dl < 16,777,216 (equal to (512 * 32,768): i.e., 512 payload data bytes per data packet times a maximum of 32,768 data packets per datagram). |
| data segment | a sequence of 8-bit data bytes (octets) that occur consecutively within a datagram, of length sl where 1 < sl < 512. |
| filled segment | a data segment of length sl < pl bytes, followed by a sequence of pl - sl fill bytes having value 0, where pl is the packet length established for the current LDL transfer (64, 128, 256, or 512). |
| sequence number | a 17-bit data object having the format defined in table C-LV, which indicates the position occupied by a data segment within a datagram, and, when the data segment includes the last data byte of the datagram, the number of bytes of payload data from the datagram in the data segment. |
| control field | an 8-bit data object reserved for future use. |
| data packet | the combination of a filled segment with a corresponding sequence number and control field. If the data segment contained in the filled segment is of length less than pl bytes (because it includes the last data byte of the datagram), the value of the sequence number indicates how many of the pl bytes in the extended data segment contain payload data from the datagram - i.e., the value of sl for the data segment contained in the filled segment. |
| tx frame | a single data packet. Same as an LDL_DATA PDU as defined in table C-LIV. |
| rx frame | a single data packet that was received without errors, as determined by the CRC check performed by the BW3 receiver. |
Table C-LIII describes the service primitives exchanged between
the LDL protocol entity and one or more user processes at LDL's
upper interface. Note that there is no requirement that implementations
of the waveforms and protocols defined in this Appendix contain
precisely these service primitives; nor are the services primitives
defined below necessarily all of the service primitives that would
be required in an implementation of these waveforms and protocols.
| LDL_Send_Req | Overview | LDL Send Request: generated by the user process when it has a datagram to send on an already-established HF link using the LDL protocol. | |
| Parameters | datagram | datagram to be delivered, as described in table C-LII. | |
| pktLength | the number pl of payload data bytes and fill bytes to be transmitted in each data packet transmitted using BW3, where pl = 64, 128, 256, or 512. The value of pktLength should correspond to the TrafficType field-value of the TM_REQUEST PDU sent in establishing the packet traffic link: e.g., pktLength should be 64 if and only if the TrafficType field of the TM_REQUEST PDU had the value LDL_64. (See C.5.3.4.1.) | ||
| Originator | User process | ||
| Preconditions | TM has just completed a successful point-to-point HF link establishment with the intended datagram recipient. | ||
| LDL_Rcv_Req | Overview | LDL Receive Request: generated by the user process to request that LDL perform the processing required to receive an expected incoming datagram. | |
| Parameters | pktLength | the number pl of payload data bytes or fill bytes expected to be present in each incoming data packet received by the BW3 receiver, where pl = 64, 128, 256, or 512. The value of pktLength should correspond to the TrafficType field-value of the TM_REQUEST PDU received when the packet traffic link was established: e.g., pktLength should be 512 if and only if the TrafficType field of the TM_REQUEST PDU had the value LDL_512. (See C.5.3.4.1.) | |
| Originator | User process | ||
| Preconditions | TM has just completed a successful point-to-point HF link establishment with the expected datagram sender. | ||
| LDL_Rcv_Ind | Overview | LDL Receive Indication: issued by LDL when LDL has a successfully-received datagram to give to the local user process. | |
| Parameters | datagram | datagram just received, as described in table C-LII; identical to the datagram parameter-value of the original LDL_Send_Req primitive at the remote station. | |
| Originator | LDL | ||
| Preconditions | LDL has accepted an LDL_Rcv_Req service primitive from a higher-layer entity since the last outgoing or incoming datagram transfer. | ||
| LDL_Send_Conf | Overview | LDL Send Confirm: Issued by LDL when LDL has completed successful delivery of a datagram to the remote station. | |
| Parameters | (none) | ||
| Originator | LDL | ||
| Preconditions | LDL was requested to deliver the datagram by the user process by means of an LDL_Send_Req service primitive. | ||
| LDL_Abort_Req | Overview | LDL Abort Request: used by the user process to terminate a LDL protocol data transfer that is currently in progress. The purpose of this service primitive is only to cause the LDL entity to cease attempting to send or receive the current datagram; coordinating the data transfer termination with the remote station is the responsibility of TM. | |
| Parameters | (none) | ||
| Originator | User process | ||
| Preconditions | Either an outgoing or an incoming data transfer is in progress, using the LDL protocol. | ||
| LDL_Failure_Ind | Overview | LDL Failure Indication: Issued by LDL when LDL is unable to complete delivery of an outgoing or incoming datagram. | |
| Parameters | (none) | ||
| Originator | LDL | ||
| Preconditions | Either an outgoing or an incoming data transfer is in progress, using the LDL protocol. | ||
The sub-sections of this section describe the PDUs exchanged between
a LDL protocol entity and its remote peer entities.
The LDL_ACK and LDL_EOM PDUs are conveyed using BW4 and thus require no special distinction from TM PDUs which are conveyed using BW1. The LDL_ACK and LDL_EOM PDUs are distinguished from one another by context: any PDU sent using BW4 in the forward direction is an LDL_EOM PDU, while any PDU sent using BW4 in the reverse direction is an LDL_ACK PDU.
An LDL_DATA PDU is a tx frame as defined in table C-LII, in which
the format and contents of each data packet are as shown in table
C-LIV. Table C-LV specifies the format and contents of the Sequence
Number field of each data packet.
| Payload | 512, 1024, 2048, or 4096 (fixed for each datagram transfer) | any | Contains a filled segment as defined in table C-LII: i.e., a data segment followed by however many zero bytes are needed to fill the Payload field to the length given by PacketLength as defined in table C-LX. Whenever the field contains fewer than PacketLength bytes of payload data from the datagram being delivered (the remainder being fill bytes with value 0), the value of the Sequence Number field indicates how many bytes of payload data are present. |
| Sequence Number | 17 (fixed) | As defined by table C-LXV. | |
| Control | 8 (fixed) | Reserved (set to zero); must be ignored by the receiving station. | |
The fields of the LDL_DATA PDU are transmitted in order of their
occurrence in table C-LIV, Payload field first. The bytes of
the Payload field are transmitted in the order of their occurrence
in the datagram; the bits of each byte are transmitted in order
of significance, starting with the most significant bit. Following
the last bit of the Payload field-value, the bits of the Sequence
Number field are transmitted in order of significance within the
17-bit field-value, starting with the most significant bit (bit
16). Finally, the bits of the Control field are transmitted in
order of significance, most significant bit first.
|
|
| ||
| only packet in datagram | Payload field byte count: the number of bytes (octets) of datagram data present in the Payload field of the packet. | |||
| last packet in datagram | Payload field byte count (see above) | |||
| first packet in datagram | number of packets required to convey the data contents of the datagram, minus one: equal to (the least integer greater than or equal to (datagram length in bytes / PacketLength (as defined in table C-LX) ) - 1. | |||
| packet in interior of datagram | down-counting packet sequence number: the number of packets in the current datagram, following the current packet. | |||
The LDL_ACK PDU is used to transfer acknowledgement, in the form
of an ack bit for the data packet in the immediately preceding
LDL_DATA PDU, from the receiving station to the sending station
in a LDL transfer. Table C-LVI specifies the format and contents
of the LDL_ACK PDU.
| Ack Bit | 1 | any | Contains one ack bit for the data packet received in an LDL_DATA PDU. The bit indicates whether the corresponding data packet was received without errors; 1 = ACK (was received successfully); 0 = NAK (not received successfully). |
| CompleteDatagramRcvd | 1 | any | Contains one bit to indicate that the data packet received in the immediately previous LDL_DATA PDU is understood by the receiving station to be the last data packet of the datagram; 1 = complete datagram received; 0 = complete datagram not received. |
Of the two bits of the LDL_ACK PDU, the
Ack Bit is transmitted first.
The LDL_EOM PDU is sent from the sending station to the receiving
station in a LDL transfer, to indicate that the sending station
has received acknowledgements from the receiving station of every
data packet in the datagram being transferred, and hence will
send no more LDL_DATA PDUs for the current datagram. The LDL_EOM
PDU is sent as many times as possible within the time interval
defined for a forward transmission, to maximize the probability
of its being received without errors. Table C-LVII specifies
the format and contents of the LDL_EOM PDU.
| Unused | 1 | 1 (fixed) | Must be set to 1. |
| EOM | 1 | 1 (fixed) | Must be set to 1. |
Of the two bits of the LDL_EOM PDU, the Unused bit is transmitted
first.
On traffic links established for packet traffic delivered using
the LDL protocol, the user process can terminate the data link
transfer and use the next data link transmission time slot in
either direction - i.e., the time slot for the LDL_DATA or the
LDL_ACK PDU - to instead send one or more TM PDUs (described in
C.5.3.4) within the data link PDU time-slot. This means that
while a LDL transfer is in progress, the receiving station must
be simultaneously attempting to demodulate TM PDUs conveyed by
the BW1 waveform as it is attempting to demodulate and receive
LDL_DATA PDUs conveyed by BW3. The sending station must likewise
simultaneously attempt to demodulate and receive TM PDUs conveyed
by the BW1 waveform as it is attempting to demodulate and receive
LDL_ACK PDUs conveyed by BW4. Since the duration of the BW1 burst
is longer than that of the BW4 burst, if the sending station detects
a BW1 preamble during the LDL_ACK time-slot, it must skip the
transmission of the next LDL_DATA PDU in order to be able to receive
the remainder of the BW1 burst. If the received BW1 burst is
a TM PDU, then the sending station must ensure that this PDU is
received and processed by its TM sublayer.
This section provides an informal overview of the behavior of
the LDL protocol. The following paragraphs define this behavior
precisely:
Data transfer by LDL begins after the TM sublayer has already
established the data link connection, in so doing negotiating
the fact that LDL will be used (as opposed to HDL or some other
mechanism), and the precise time synchronization of data link
transmissions.
In an LDL data transfer, the sending station and the receiving
station alternate transmissions in the manner depicted in figure
C-36, the sending station transmitting LDL_DATA PDUs containing
payload data packets, and the receiving station transmitting LDL_ACK
PDUs containing acknowledgement of whether or not the data packet
in the preceding LDL_DATA PDU was received without error. If
either station fails to receive a PDU at the expected time, it
sends its own next outgoing PDU at the same time as if the incoming
PDU had been received successfully. The times at which the burst
waveforms conveying LDL_DATA, LDL_ACK, and LDL_EOM PDUs may be
emitted are precisely stipulated. See C.5.5.5.5 for details.
The end of a data transfer is reached when the sending station
has transmitted LDL_DATA PDUs containing all of the payload data
in the delivered datagram, and the receiving station has received
these data without errors and has acknowledged their successful
delivery. When the sending station receives an LDL_ACK PDU indicating
that the entire contents of the datagram have been delivered successfully,
it sends an LDL_EOM PDU repeated as many times as possible within
the duration of an LDL_DATA PDU, starting at the time at which
it would have otherwise transmitted the next LDL_DATA PDU, to
indicate to the receiving station that the data transfer will
be terminated. This link termination scenario is depicted in
figure C-37. See C.5.5.5.5 for timing details.
The definition of LDL behavior presented in the following sections
includes mechanisms for dealing appropriately with the following
occurrences:
Table C-LVIII defines the events to which the LDL entity responds.
The event names are used in the state diagram and the state transition
table in C.5.5.5.4, which define the behavior of the LDL protocol.
Some event names refer to the receipt of PDUs from the LDL entity
at a remote station; in these cases, the 'description' field of
the table entry describes the manner in which the arrival of a
PDU is accomplished through LDL's accepting one or more service
primitives from lower-layer entities at the local station. The
prefix 'R:' in the name of an event indicates that the event is
the receipt of a PDU from the remote station. 'D:' indicates that
the event is an LDL service primitive passed down to LDL from
a higher-layer entity; 'U:' indicates a lower-layer service primitive
passed up to LDL from a lower-layer entity.
Table C-LIX defines the actions which the LDL entity can perform.
The action name is used in the state diagrams and/or state transition
tables used below to define the behavior of the LDL protocol.
Some action names refer to sending PDUs to the LDL entity at
a remote station; in these cases, the 'description' field of the
table entry describes the manner in which sending of the PDU is
accomplished by issuing one or more service primitives to lower-layer
entities at the local station.
| R:LDL_DATA PDU | A BW3_Receive primitive containing an LDL_DATA PDU was accepted. |
| R:LDL_ACK PDU | A BW4_Receive primitive containing an LDL_ACK PDU was accepted. |
| R:LDL_EOM PDU | A BW4_Receive primitive containing a LDL_EOM PDU was accepted, and the LDL_EOM PDU was found to be free of errors by comparing the received PDU against the known LDL_EOM bit pattern specified in C.5.5.4.3. |
| D:LDL_Send_Req | An LDL_Send_Req primitive was accepted from the user process. |
| D:LDL_Abort_Req | An LDL_Abort_Req primitive was accepted from the user process. |
| U:BW1_Pre_Detect | A BW1_Pre_Detect primitive was received, indicating that the BW1 Receiver has detected the BW1 acquisition preamble, with the likely implications that the remote station has sent a TM PDU in the current LDL_ACK time slot. |
| AckTimeout | A valid LDL_ACK PDU was not received within the time period in which it was expected. |
| DataTimeout | An LDL_DATA PDU was not received within the time period in which it was expected. |
| TxInit | Insert the outgoing datagram into TxDatagramBuf.
Clear TxFrameBuf. Reset MissedAckCount to zero. Set PacketLength to the value of the pktLength parameter of the LDL_Send_Req service primitive just accepted by LDL. |
| S:LDL_DATA | If the TxFrameBuf is clear, construct a new outgoing data packet (as described by table C-LIV) in the following manner:
Send an LDL_DATA PDU containing the tx frame in TxFrameBuf, using a BW3_Send primitive. Set the primitive's reset parameter to TRUE if this is the first transmission of a tx frame for the current datagram, and to FALSE otherwise. If an AckTimeout has occurred, increment MissedAckCount. Reset AckTimeout timer. |
| ProcessAck | Copy the Ack Bit-Mask field value to RxAck.
If RxAck is 1, clear the TxFrameBuf. If TxDatagramBuf is not empty, set the condition MoreToSend to TRUE; otherwise set it to FALSE. |
| S:LDL_EOM | Send an LDL_EOM PDU to the remote station using BW4_Send, as many times as possible within the duration of an LDL_DATA PDU. The number of times the LDL_EOM PDU is sent depends on the value of PacketLength as follows:
Disable AckTimeout timer. |
| Skip LDL_DATA slot | Do not send an LDL_DATA PDU in the next LDL_DATA time slot, so that an incoming BW1 burst can be received. However, continue the LDL slot timing, and be prepared to send an LDL_DATA PDU in the slot after the next one. |
| U:LDL_Send_Conf | Issue an LDL_Send_Conf primitive to the user process that requested the outgoing data transfer. |
| AbortTransmit | Disable AckTimeout timer; reset MissedAckCount to zero. |
| RxInit | Clear RxDatagramBuf, and RxFrameBuf.
Reset MissedTxFrameCount to zero. Reset CompleteDatagramRcvd. Reset DataTimeout timer. Set PacketLength to the value of the pktLength parameter of the LDL_Rcv_Req service primitive just accepted by LDL. |
| S:LDL_ACK(ack) | Reset MissedTxFrameCount to zero.
Insert the received data packet containing the Payload and Sequence Number field into RxFrameBuf. Set TxAck to 1. Move the Payload field contents of RxFrameBuf to the position in RxDatagramBuf indicated by the Sequence Number field-value. In doing this, move only payload data bytes into RxDatagramBuf; discard any fill bytes. Use the Sequence Number field-value to determine which bytes contain payload data and which are fill bytes. If the entire datagram has been received, set CompleteDatagramRcvd. Reset DataTimeout timer. Send an LDL_ACK PDU containing the TxAck and CompleteDatagramRcvd values, using BW4_Send. Note: An implementation of LDL can, without impairing compliance to this standard, provide segments of a partially-received datagram to the user process, in order of their occurrence in the original datagram at the sending station, before the entire datagram has been received. Doing so would allow a higher-layer protocol to abort an ongoing data transfer, then resume it at a later time, without having to retransmit the entire portion of the current datagram that was already delivered successfully. Note: The LDL transmitter can send duplicate packets either as a result of missing an LDL_ACK PDU, or at the end of a datagram, in order to fill the (otherwise unused) packet positions of an LDL_DATA PDU. The LDL receiver is required to inspect the sequence number of each data packet received without errors, and to use the sequence numbers to identify and discard duplicate packets. |
| S:LDL_ACK(nak) | Clear TxAck.
Send an LDL_ACK PDU containing the TxAck and CompleteDatagramRcvd values, using BW4_Send. If a DataTimeout has occurred, increment MissedTxFrameCount. Reset the DataTimeout timer. |
| U:LDL_Rcv_Ind | Send an LDL_Rcv_Ind service primitive to the user process. |
| AbortReceive | Disable DataTimeout timer; reset MissedTxFrameCount to zero. |
Table C-LX defines the data items used and maintained by LDL,
including buffers, counters, timers, configuration parameters,
and so forth. These data items are referred to by the names assigned
to them here, in the definitions of LDL events and actions presented
in the preceding sections.
For the reader's convenience, two equivalent representations of
the behavior of the LDL protocol are provided in this section:
the state transition table in table C-LXI, and the state diagram
in figure C-38.
Both table C-LXI and figure C-38 specify the behavior of LDL in
terms of the events defined in C.5.5.5.1 and the actions defined
in C.5.5.5.2. The conditions gating certain transitions are specified
in terms of the data items defined in C.5.5.5.3.
| TxDatagramBuf | buffer storing the data contents of an outgoing datagram which have not yet been inserted into a tx frame for transmission. |
| TxFrameBuf | buffer storing the outgoing tx frame (an LDL_DATA PDU). |
| RxDatagramBuf | buffer storing the data contents of an incoming datagram which have been received thus far, in which the complete incoming datagram is re-assembled in correct order. |
| RxFrameBuf | buffer storing the most recent rx frame that was received without errors (as determined by the CRC check performed by the BW3 receiver). |
| TxAck | ack flag to be transmitted to the remote station. TxAck = 1 indicates that the data packet in the most recently received rx frame was received without errors. |
| RxAck | ack flag received in an LDL_ACK PDU from the remote station. RxAck = 1 indicates that the remote station received the data packet in the previously-transmitted frame without errors. |
| MissedAckCount | count of consecutive failures to receive an LDL_ACK PDU in the time period in which one was expected. |
| MissedTxFrameCount | count of consecutive failures to receive an LDL_DATA PDU (a tx frame) in the time period in which one was expected. |
| AckTimeout | timer used to time the duration of the interval in which receipt of an LDL_ACK PDU is expected; fires when the interval expires. |
| DataTimeout | timer used to time the duration of the interval in which receipt of an LDL_DATA PDU is expected; fires when the interval expires. |
| MAX_MISSED_ACKS | LDL configuration parameter specifying the maximum number of consecutive missed LDL_ACK PDUs that can occur without causing the LDL transmitter to terminate the data link transfer. The value of this parameter is not stipulated by this specification, since it is not required for interoperability that this parameter have identical values in both the sending and receiving stations. |
| MAX_MISSED_TX_FRAMES | LDL configuration parameter specifying the maximum number of consecutive missed LDL_DATA PDUs that can occur without causing the LDL receiver to terminate the data link transfer. The value of this parameter is not stipulated by this specification, since it is not required for interoperability that this parameter have identical values in both the sending and receiving stations. |
| CompleteDatagramRcvd | flag maintained by the receiving station indicating whether or not the entire datagram has been successfully received. |
| MoreToSend | Boolean condition variable: is TRUE if and only if an outgoing datagram transfer is in progress, and there are one or more data packets in the datagram for which the local station has not yet received an acknowledgement of their receipt without errors by the remote station. |
| PacketLength | number of payload data bytes and fill bytes (if any) carried within each LDL forward transmission in the current datagram transfer; possible values are 64, 128, 256, and 512. The value of PacketLength is determined by the pktLength parameter of the LDL_Send_Req or LDL_Rcv_Req service primitive that was accepted by LDL just prior to the start of the datagram transfer. |
In the state diagram, each state transition is labeled with an event, an optional condition, and zero or more actions. This indicates that the state transition occurs whenever the event occurs and the condition obtains (is TRUE), causing the associated actions to be performed. On figure C-38,
Where a transition is labeled with two or more events, this indicates
that the transition occurs whenever any of the events occurs.
| Idle | D:LDL_Send_Req | TxInit + S:LDL_DATA | Send | |
| D:LDL_Rcv_Req | RxInit | Receive | ||
| other | none | Idle | ||
| Send | R:LDL_ACK | MoreToSend | ProcessAck + S:LDL_DATA | Send |
| R:LDL_ACK | NOT MoreToSend | ProcessAck + S:LDL_EOM + U:LDL_Send_Conf | Idle | |
| U:BW1_Pre_Detect | Skip LDL_Data slot | Send | ||
| AckTimeout | MissedAckCount < MAX_MISSED_ACKS | S:LDL_DATA | Send | |
| AckTimeout | MissedAckCount == MAX_MISSED_ACKS | AbortTransmit + U:LDL_Failure_Ind | Idle | |
| D:LDL_Abort_Req | AbortTransmit | Idle | ||
| other | none | Send | ||
| Receive | R:LDL_DATA | S:LDL_ACK(ack) | Receive | |
| R:LDL_EOM | U:LDL_Rcv_Ind | Idle | ||
| DataTimeout | MissedTxFrameCount < MAX_MISSED_TX_FRAMES | S:LDL_ACK(nak) | Receive | |
| DataTimeout | (MissedTxFrameCount == MAX_MISSED_TX_FRAMES)
AND NOT CompleteDatagramRcvd | AbortReceive + U:LDL_Failure_Ind | Idle | |
| DataTimeout | (MissedTxFrameCount == MAX_MISSED_TX_FRAMES)
AND CompleteDatagramRcvd | AbortReceive + U:LDL_Rcv_Ind | Idle | |
| D:LDL_Abort_Req | AbortReceive | Idle | ||
| other | none | Receive |
See C.5.3.5.5, which includes an analysis of the timing of the
LDL protocol in conjunction with TM protocol timing.
The CLC monitors and coordinates traffic on an established circuit
link. It provides a simple listen-before-transmit access control
mechanism:
In addition, the CLC provides a traffic timeout indication when
an interval of a specified duration elapses in which no outgoing
or incoming traffic is detected on the circuit link, allowing
the traffic link to be terminated when no longer required.
The CLC is employed only on circuit links.
Table C-LXII describes the service primitives exchanged between the CLC and one or more user processes at the CLC's upper interface. Note that there is no requirement that implementations of the waveforms and protocols defined in this Appendix contain precisely these service primitives; nor are the services primitives defined below necessarily all of the service primitives that would be required in an implementation of these waveforms and protocols.
| CLC_Active_Req | Overview | CLC Active Request: issued to CLC by the user process to request that CLC begin monitoring and arbitration of access to the currently-established circuit link, using the indicated priority level in its backoff mechanism. CLC sets its data item TrafficPriority to the value of the prio parameter. | |
| Parameters | prio | priority level of waiting outgoing traffic (if any); value is one of
| |
| Originator | user process | ||
| Preconditions | CLC is Idle; a circuit link was just established by the Traffic Manager. | ||
| CLC_Idle_Req | Overview | CLC Idle Request: issued to CLC by the user process to request that CLC cease to monitor and arbitrate access to the current circuit link. | |
| Parameters | none | ||
| Originator | user process | ||
| Preconditions | CLC is presently active: i.e., not presently residing in its Idle state. | ||
| CLC_Set_Priority | Overview | issued to CLC by the user process to request that CLC use the indicated outgoing traffic priority level in its backoff mechanism. CLC sets its data item TrafficPriority to the value of the prio parameter. | |
| Parameters | prio | priority level of waiting outgoing traffic (if any); value is one of
| |
| Originator | user process | ||
| Preconditions | none: can be accepted by CLC in any state. | ||
| CLC_Idle_Ind | Overview | CLC Idle Indication: issued to the user process by CLC, to indicate that CLC is ceasing to monitor and arbitrate access to the current circuit link due to occurrence of a traffic timeout (no link traffic detected over a time interval of a specific duration). | |
| Parameters | none | ||
| Originator | CLC | ||
| Preconditions | CLC is presently active: i.e., not presently residing in its Idle state. | ||
| CLC_Busy_Ind | Overview | CLC Busy Indication: issued to the user process by CLC, to indicate that CLC considers the circuit link to be busy - i.e., unavailable for new traffic because of a traffic exchange currently in progress, or because a backoff period following a traffic exchange has not yet expired. | |
| Parameters | none | ||
| Originator | CLC | ||
| Preconditions | CLC is either
| ||
| CLC_Avail_Ind | Overview | CLC Available Indication: issued to the user process by CLC, to indicate that CLC considers the circuit link to be available for new traffic. | |
| Parameters | none | ||
| Originator | CLC | ||
| Preconditions | CLC is indicating that the traffic link is busy: i.e., the most recent service primitive passed between CLC and the user process was a CLC_Busy_Ind primitive. | ||
The CLC does not exchange PDUs with a remote peer entity.
The following paragraphs define the behavior of the CLC:
Table C-LXIII defines the events to which the CLC responds. The
event names are used in the state diagram in C.5.6.4.4, which
defines the behavior of the CLC.
Table C-LXIV defines the actions which the CLC can perform. The
action name is used in the state diagram used below to define
the behavior of the CLC.
| event name | description |
| D:CLC_Active_Req (prio) | CLC_Active_Req primitive issued by user process, with the indicated value for its prio parameter. |
| D:CLC_Idle_Req | CLC_Idle_Req primitive issued by user process. |
| D:CLC_Set_Priority (prio) | CLC_Set_Priority primitive issued by user process, with the indicated value for its prio parameter. CLC sets its data item TrafficPriority to the value of the prio parameter. |
| ModemRTS | signal indicating that the local station's modem is starting to modulate data to be transmitted the current circuit link. |
| AudioRTS | signal indicating presence of an outgoing audio signal to be transmitted on the current circuit link, such as a handset keyline assertion. |
| ModemEOTx | signal indicating that a transmission of modem data by the local station has been completed. |
| AudioEOTx | signal indicating that transmission of an outgoing audio signal has ended due to, for instance, de-assertion of the handset keyline. |
| ModemDetect | signal indicating that the local station's modem has detected incoming data signalling; equivalent to a signal presence indication. As a minimum requirement for compliance with this standard, the CLC shall employ a signal detector capable of detecting MIL-STD-188-110 serial tone modem signalling, including both the preamble and data portions of the modem waveform. As a design objective, it is also desirable that the signal detector be able to detect as many as possible of the signalling types corresponding to the traffic types enumerated in table C-XXXIII, as well as the following:
|
| AudioDetect | signal indicating that the local station has detected incoming audio (typically voice) signalling on the circuit link. The capability to detect SSB analog voice is a requirement for compliance with this standard. |
| ModemEORx | signal indicating that the local station's modem has detected the MIL-STD-188-110 serial tone End-Of-Message (EOM) sequence. |
| ModemSigLoss | signal indicating that the local station's modem has declared signal absence after previously having acquired an incoming modem transmission, without having detected the modem's EOM sequence. |
| AudioSigLoss | signal indicating that the local station has determined that an incoming audio signal on the circuit link has ceased to be present. |
| TrafficTimeout | timeout event generated by TrafficTimer when the local station has not detected incoming or outgoing traffic on the current circuit link within an interval of duration > TRAFFIC_TIMEOUT_INTVL |
| BackoffTimeout | timeout event generated by BackoffTimer when the backoff interval following the most recent detected incoming or outgoing traffic transmission has expired. |
| ReacqTimeout | timeout event generated by ReacqTimer when the local station has not detected resumption of reception of an interrupted incoming modem or audio signal within an interval of duration > REACQ_TIMEOUT_INTVL. |
| SetPriority | Set TrafficPriority to the value of the prio parameter of a CLC_Active_Req or CLC_Set_Priority service primitive. |
| StartTrafficTimer | Set TrafficTimer to TRAFFIC_TIMEOUT_INTVL. |
| StopTrafficTimer | Disable TrafficTimer. |
| StartBackoffTimer | Set BackoffTimer to BACKOFF_TIMEOUT_INTVL. |
| StopBackoffTimer | Disable BackoffTimer. |
| StartReacqTimer | Set ReacqTimer to REACQ_TIMEOUT_INTVL. |
| StopReacqTimer | Disable ReacqTimer. |
| U:CLC_Idle_Ind | Issue a CLC_Idle_Ind service primitive to the user process. |
| U:CLC_Avail_Ind | Issue a CLC_Avail_Ind service primitive to the user process. |
| U:CLC_Busy_Ind | Issue a CLC_Busy_Ind service primitive to the user process. |
Table C-LXV defines the data items used and maintained by CLC,
including buffers, counters, timers, configuration parameters,
and so forth. These data items are referred to by the names assigned
to them here, in the definitions of CLC events and actions presented
in the preceding sections. These data items are used in this
specification only as expository devices; it is not required for
compliance that an implementation contain these data items in
the form described here.
| BackoffTimer | down-counting timer used to time BackoffTimeouts. Is set with a duration value and, unless reset before the timeout interval expires, counts down to zero, then generates a BackoffTimeout event. |
| ReacqTimer | down-counting timer used to time ReacqTimeouts. Is set with a duration value and, unless reset before the timeout interval expires, counts down to zero, then generates a ReacqTimeout event. |
| TrafficTimer | down-counting timer used to time TrafficTimeouts. Is set with a duration value and, unless reset before the timeout interval expires, counts down to zero, then generates a TrafficTimeout event. |
| TrafficPriority | the priority level of the pending outgoing traffic, if any. |
| TRAFFIC_TIMEOUT_INTVL | constant configuration parameter: duration of the time interval after which a traffic timeout will occur if no incoming or outgoing traffic is detected on the current circuit link. The value of this parameter is not stipulated as a requirement for interoperability. |
| BACKOFF_TIMEOUT_INTVL | duration of the time interval after which a backoff timeout will occur if no incoming traffic is detected on the current circuit link. Determines the interval following each outgoing or incoming transmission on the circuit link during which the local station will listen for traffic on the circuit before transmitting. The interval duration is always zero for pending analog or digital voice traffic (preventing annoying delays in voice answer-back operation). For data traffic, the interval duration is selected randomly from one of five values; the relative probabilities of the possible duration values are determined by the priority level of the pending outgoing data traffic (if any), as specified in table C-LXVI. If no traffic is pending, the interval duration is set to zero. |
| REACQ_TIMEOUT_INTVL | constant configuration parameter: duration of the time interval after which a reacquisition timeout will occur if an incoming modem or audio traffic signal is not detected on the traffic circuit. The value of this parameter is not stipulated as a requirement for interoperability; a suggested default value is 800 milliseconds. |
| P2P (after transmit or on start of link if not initiator) | |||||
| P2P (after receive or on start of link if initiator) | |||||
| TM | |||||
| HIGHEST | |||||
| HIGH | |||||
| ROUTINE | |||||
| LOW |
The backoff scheme using these interval durations is intended to accomplish the following:
The state diagram in figure C-39 specifies the behavior of the
CLC in terms of the events defined in C.5.6.4.1 and the actions
defined in C.5.6.4.2.
In the state diagram, each state transition is labeled with an event, an optional condition, and zero or more actions. This indicates that the state transition occurs whenever the event occurs and the condition obtains (is TRUE), causing the associated actions to be performed. In the diagram,
Where a transition is labeled with two or more events, this indicates
that the transition occurs whenever any of the events occurs.
In its Idle state, the CLC does not monitor link traffic or control
access to the link. When a circuit link is established, the CLC
of the station that initiated the link is placed in its Ready
state and begins to monitor traffic on the circuit link. From
Ready it proceeds to its Transmit or its Receive state, respectively,
when outgoing or incoming traffic is detected. When the traffic
ends, the CLC proceeds into its Backoff state where it waits for
the duration of a backoff interval before returning to its ready
state. If incoming signal presence is lost during reception of
incoming modem signalling, the CLC enters its Signal Reacq state,
where it remains until either incoming signal presence is reacquired,
or a ReacqTimeout event occurs causing the CLC to decide that
the incoming traffic has ended and proceed to its Backoff state.
When a circuit link is established, the CLC of each station that
did not initiate the link enters its Backoff state, giving the
link initiator the first opportunity to transmit on the circuit
link.
Note that on the occurrence of any event not shown here, the CLC
will take no action and remain in its current state.
Figure C-40 through figure C-45 illustrate the operation of the
protocols described in this appendix.
