APPENDIX C

THIRD-GENERATION HF LINK AUTOMATION


TABLE OF CONTENTS

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

TABLES

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

FIGURES

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



C.1 GENERAL.

C.1.1 Scope.

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.


FIGURE C-1. Scope of 3G technology.

C.1.2 Applicability.

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.

C.2 APPLICABLE DOCUMENTS.

C.2.1 General.

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.

C.2.2 Government documents.

C.2.2.1 Specifications, standards, and handbooks.

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.

C.2.2.2 Other Government documents, drawings, and publications.

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.

C.2.3 Non-Government publications.

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

C.2.4 Order of precedence.

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.

C.3 DEFINITIONS.

C.3.1 Standard definitions and acronyms.

C.3.2 Abbreviations and acronyms.

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.
2Gsecond generation
2G ALEsecond generation automatic link establishment
3Gthird generation
3G ALEthird generation automatic link establishment
ACKacknowledgment
ACQ-ALEalternative quick call -automatic link establishment
AGCautomatic gain control
ALEautomatic link establishment
ALMautomatic link maintenance
ARQautomatic repeat request
ASCIIAmerican Standard Code for Information Interchange
AWGNadditive white gaussian noise
bpsbits per second
BW0Burst Waveform 0
BW1Burst Waveform 1
BW2Burst Waveform 2
BW3Burst Waveform 3
BW4Burst Waveform 4
CLCcircuit link controller
CMConnection Manager
CMDALE preamble word COMMAND
CONFconfirm
CRCcyclic redundancy check
CSUCall SetUp
dBdecibel
DOdesign objective
EMCONEmission Control
EOMEnd of Message
FECforward error correction
FSKfrequency shift keying
GPSGlobal Positioning System
HFhigh frequency
HDLhigh-rate data link protocol
HNMPHF Network Management Protocol
HzHertz
LDLlow-rate data link protocol
lsbleast-significant bit
kHzkiloHertz
MHZmegahertz
msmillisecond
msbmost-significant bit
NAKnegative acknowledgment
PDUprotocol data unit
PNpseudo noise
REQrequest
rxreceive
ssecond
SDUservice data unit
SNMPsimple network management protocol
SSBSingle SideBand
TERMTerminate
TLCTransmit Level Control
TMtraffic management
TODtime of day
TRFTraffic
TSUTraffic SetUp
TWASALE preamble word THIS WAS
txtransmit
UNLunlink

C.3.3 Operating parameters.

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.

C.4 GENERAL REQUIREMENTS.

C.4.1 Overview.

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).

FIGURE C-2. 3G HF protocol suite.

C.4.2 Frequency management.

C.4.2.1 Calling and traffic channels.

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.

C.4.2.2 Reserved channel number.

Channel 127 shall be understood to refer to the current channel (calling channel in ALE, traffic channel in ALM).

C.4.2.3 External frequency management.

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.

C.4.3 Network synchronization.

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.

C.4.3.1 External synchronization.

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.

C.4.3.2 Over-the-air synchronization.

When an external source of synchronization is not available, 3G systems shall maintain synchronization using the synchronization management protocol of C.5.2.7.

C.4.4 Scanning.

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.

C.4.4.1 Synchronous mode.

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.

C.4.4.2 Asynchronous mode.

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.)

C.4.5 3G addresses.

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.

C.4.5.1 Synchronous mode address structure.

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).

FIGURE C-3. Synchronous mode address structure.

C.4.5.2 Net entry addresses.

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.

C.4.5.3 Multicast addresses.

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.

C.4.5.4 Node address assignments.

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.

C.4.5.5 Multicast address assignments.

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.

C.4.6 ALE.

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.

C.4.6.1 System performance requirements.

Requirements for linking probability and occupancy detection are specified in the following paragraphs.

C.4.6.1.1 Linking probability.

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.

TABLE C-I. Linking probability requirements (3 kiloHertz (kHz) signal to noise ratio (SNR) decibels (dB)).
Prob Link Success
Gaussian
ITU-RF.250-2 Good
ITU-RF.250-2 Poor
25%
-10
-8
-6
50%
-9
-6
-3
85%
-8
-3
0
95%
-7
1
3

C.4.6.1.1.1 Linking probability for synchronous operation.

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.

C.4.6.1.1.2 Linking probability for asynchronous operation.

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.

C.4.6.1.2 Occupancy detection.

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.

C.4.6.1.2.1 Occupancy detection for synchronous operation.

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.

C.4.6.1.2.2 Occupancy detection for asynchronous operation.

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.

TABLE C-II. Synchronous-mode occupancy detection requirements (3 kHz SNR dB).
Waveform
AWGN 3 kHz SNR (dB)
Minimum Required Detection Probability
2G-ALE
0
50%
6
90%
3G-ALE (BW0)
-9
50%
-6
95%
3G-HDL (BW2)
0
30%
6
70%
single sideband (SSB) Voice
6
50%
9
75%
MIL-STD-188-110 or
0
30%
FED-STD-1052 PSK modem
6
70%
STANAG 4285 or
0
30%
STANAG 4529 PSK modem
6
70%


C.4.6.2 Calling channel selection.

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:

C.4.6.3 Interoperability with 2G systems.

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.

C.4.6.4 MIL-STD-188-148A functionality.

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.

C.4.7 Data link protocol.

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.

C.4.8 Automatic link maintenance.

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.

C.4.9 Network management interface.

3G systems should provide a network management interface in accordance with Appendix D to facilitate interoperability with common network management systems.

C.4.10 Order of transmission.

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.

C.4.11 3G ALE data structures.

3G systems shall implement the following data structures at the network management interface (if provided).

C.4.11.1 Station self address.

The "self address" of each 3G ALE station table shall be an index into the station table (see below).

C.4.11.2 Station table.

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.

C.4.11.3 Channel table.

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.

C.4.12 Cyclic Redundancy Check (CRC) computation procedure.

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:

1 + g1*X + g2*X2 + … + gK-2*XK-2 + gK-1*XK-1 + XK

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.

FIGURE C-4. CRC computation structure.

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:

  1. Initialize binary memory elements C0 through CK-1 with 0.
  2. Apply each of the N user bits in order, starting with U0, to the binary adder at the far right of the diagram, and perform the other indicated binary additions and multiplications.
  3. After each of the N user bits has been applied to the indicated adder, the memory elements C0 through CK-1 contain the CRC.
  4. The K bit CRC is read out and appended to bits U0 through UN-1 of the PDU in right-to-left order, starting with CK-1 and finishing with C0, so that the entire PDU with CRC is the bit-sequence (U0, …, UN-1, CK-1, …, C0), with U0 being the first bit and C0 the last.

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.

C.5 DETAILED REQUIREMENTS.

C.5.1 Constituent waveforms.

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.

TABLE C-III. Burst waveform characteristics.
Wave Form
used for
burst duration
payload
preamble
FEC coding
inter-

leaving
data format
effectrive code rate1
BW03G-ALE PDUs 613.33 ms

1472 PSK symbols

26 bits160.00 ms

384 PSK symbols

rate = 1/2,

k = 7 convolutional (no flush bits)

4x13 block16-ary orthogonal Walsh function
1 / 96
BW1Traffic Manage-ment PDUs; HDLacknow-ledgement PDUs 1.30667 seconds

3136 PSK symbols

48 bits240.00 ms

576 PSK symbols

rate = 1/3,

k = 9 convolutional (no flush bits)

16x9 block16-ary orthogonal Walsh function
1 / 144
BW2HDLtraffic data PDUs 640 + (n*400) ms

1536 + (n*960) PSK symbols,

n = 3, 6, 12, or 24

n*1881 bits26.67 ms

64 PSK symbols (for equalizer training)

rate = 1/4,

k = 8 convolutional (7 flush bits)

none32 unknown/

16 known

variable:

1 / 1 to

1 / 4
BW3LDL traffic data PDUs 373.33 + (n*13.33) ms

32n + 896 PSK symbols,

n = 64, 128, 256, or 512

8n+25 bits266.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
variable:

1 / 12 to

1 / 24
BW4LDL acknow-ledgement PDUs 640.00 ms

1536 PSK symbols

2 bitsnone nonenone 4-ary orthogonal Walsh function
1 / 1920
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.

C.5.1.1 Service primitives.

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.

TABLE C-IV. Burst Waveform (BWn) service primitives.
Primative name
Attribute
Values
Description
BW0_SendOverview Invoked by a user process to send a 26-bit data payload using the BW0 robust burst signalling format
Parameters payloadan ordered sequence of 26 bits of data to be modulated and transmitted using the BW0 signalling format
Originator Connection Management (CM)
Preconditions
BW0_ReceiveOverview Issued by BW0 Receiver when it has received a BW0 transmission.
Parameters payloadthe 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_DetectOverview Issued by BW0 Receiver when it has detected a BW0 acquisition preamble.
Parameters none
Originator BW0 Receiver
Preconditions BW0 Receiver is active.
BW1_SendOverview Invoked by a user process to send a 48-bit data payload using the BW1 robust burst signalling format
Parameters payloadan ordered sequence of 48 bits of data to be modulated and transmitted using the BW1 signalling format
Originator
  • HDL protocol
  • TM
Preconditions
BW1_ReceiveOverview Issued by BW1 Receiver when it has received a BW1 transmission.
Parameters payloadthe 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_DetectOverview Issued by BW1 Receiver when it has detected a BW1acquisition preamble.
Parameters none
Originator BW1 Receiver
Preconditions BW1 Receiver is active.
BW2_SendOverview 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 framea 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.

TABLE C-IV. Burst Waveform (BWn) service primitives (continued).
Primative name
Attribute
Values
Description
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_ReceiveOverview Issued by the BW2 Receiver when it has received a BW2 transmission.
Parameters rx framea BW2 rx frame containing NumRcvd indexed data packets, where 0 < NumRcvd < NumPkts. An indexed data packet contains
  • payload: a data packet containing 1881 bits of payload data; identical to the corresponding data packet in the transmitted tx frame.
  • index: the position at which the indexed data packet occurred in the forward transmission (BW2 tx frame) in which it was received, where 0 < index < NumPkts. index = 0 indicates that the packet was in the first packet-slot in the forward transmission.

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_SendOverview Invoked by a user process to send a data packet to a remote station, using the BW3 low-rate burst signalling format.
Parameters payloadan 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_ReceiveOverview Issued by the BW3 Receiver when it has successfully received a BW3 transmission without errors.

TABLE C-IV. Burst Waveform (BWn) service primitives (continued).
Primative name
Attribute
Values
Description
Parameters payload537, 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_SendOverview Invoked by a user process to send two bits of payload data using the BW4 robust burst signalling format.
Parameters payloadtwo 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_ReceiveOverview Issued by the BW4 Receiver when it has received a BW4 transmission.
Parameters payloadtwo 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.

C.5.1.2 Burst waveform interleaving.

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
  • Number of rows
C
  • Number of columns
irs
  • Row increment, stuff
ics
  • Column increment, stuff
irs
  • Delta row increment, stuff. Applied only when stuff count is an integer multiple of the number of columns.
ics
  • Delta column increment, stuff. Applied only when stuff count is an integer multiple of the number of rows.
irf
  • Row increment, fetch
icf
  • Column increment, fetch
irf
  • Delta row increment, fetch. Applied only when fetch count is an integer multiple of the number of columns.
icf
  • Delta column increment, fetch. Applied only when fetch count is an integer multiple of the number of rows.

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

C.5.1.3 Burst Waveform 0 (BW0).

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.

FIGURE C-5. BW0 timing.

The description of the BW0 waveform generation will proceed as follows:

NOTE: A tribit number can take on the values 0,1,…,7.

C.5.1.3.1 TLC/AGC guard sequence.

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.

TABLE C-V. TLC/AGC guard sequence symbol values.


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.

C.5.1.3.2 Acquisition preamble.

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


TABLE C-VI. BW0 acquisition preamble symbol values.

C.5.1.3.3 Forward error correction.

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:

  1. Initialize the six memory cells x1 .. x6 of the encoder with the last six bits of the payload sequence, p20 .. p25, so that cell x1 contains p20 and cell x6 contains p25.
  2. Shift the first bit of the payload sequence, p0, into cell x6.
  3. Extract the two coded output bits b0 and b1, in that order, as shown in figure C-6.
  4. Shift the next payload bit into cell x6, then extract the two coded output bits b0 and b1.
  5. Repeat step 4 until a total of 52 coded bits have been produced.

No flush bits are necessary for the encoding process.


FIGURE C-6. Rate 1/2, constraint length 7 convolutional encoder.

The polynomials used are:

where x6 corresponds to the most recent encoder input bit.

C.5.1.3.4 Interleaving.

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:

TABLE C-VII. BW0 interleaver paramenters.
R4
C13
irs0
ics1
irs1
ics0
irf1
icf0
irf0
icf1

C.5.1.3.5 Orthogonal symbol formation.

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.


TABLE C-VIII. Walsh modulation of coded bits to tribit sequences.
Coded Bits

(shown as b3b2b1b0)
Tribit Sequence
0000
0000 0000 0000 0000
0001
0404 0404 0404 0404
0010
0044 0044 0044 0044
0011
0440 0440 0440 0440
0100
0000 4444 0000 4444
0101
0404 4040 0404 4040
0110
0044 4400 0044 4400
0111
0440 4004 0440 4004
1000
0000 0000 4444 4444
1001
0404 0404 4040 4040
1010
0044 0044 4400 4400
1011
0440 0440 4004 4004
1100
0000 4444 4444 0000
1101
0404 4040 4040 0404
1110
0044 4400 4400 0044
1111
0440 4004 4004 0440

This process repeats for a total of 13 iterations (one for each group of four coded bits) to produce 832 raw tribit values.

C.5.1.3.6 Psuedo noise (PN) spreading sequence generation and application.

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.

TABLE C-IX. BW0 PN spreading sequence.


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.

C.5.1.3.7 Modulation.

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.

C.5.1.4 Burst Waveform 1 (BW1).

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


FIGURE C-7. BW1 timing.

The description of the BW1 waveform generation will proceed as follows:

NOTE: A tribit number can take on the values 0,1,…,7.

C.5.1.4.1 TLC/AGC guard sequence.

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

TABLE C-X. TLC/AGC guard sequence symbol values.

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.

C.5.1.4.2 Acquisition preamble.

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.

TABLE C-XI. BW1 acquisition preamble symbol values.


3,6,6,7, 7,2,1,4, 4,3,2,3, 7,4,3,4, 7,4,3,3, 7,6,7,2, 3,3,6,7, 4,0,6,5,

6,0,0,2, 7,5,1,7, 1,5,2,1, 1,1,3,5, 4,5,4,1, 2,3,3,0, 4,4,4,3, 1,6,6,6,

0,5,7,7, 5,7,3,7, 0,5,7,7, 4,5,5,7, 7,1,4,2, 2,1,6,6, 7,7,6,3, 2,1,1,7,

4,5,1,5, 1,4,7,1, 3,2,7,6, 7,3,4,7, 2,6,2,4, 6,3,1,7, 0,2,2,1, 7,3,2,3,

6,5,2,5, 1,5,0,1, 5,3,0,6, 2,5,0,1, 0,4,3,0, 7,2,4,1, 2,4,5,3, 7,7,0,0,

1,5,2,7, 4,5,6,4, 2,5,6,7, 2,6,2,2, 5,7,4,6, 3,2,1,0, 1,2,4,3, 1,6,5,2,

1,2,3,3, 3,7,2,5, 5,6,7,2, 1,0,5,6, 4,6,2,6, 2,4,0,7, 7,2,4,0, 4,3,2,5,

7,2,5,2, 3,4,6,1, 2,6,1,6, 5,5,0,0, 0,1,2,2, 3,3,5,3, 1,4,4,3, 0,0,2,4,

1,3,3,4, 5,7,2,4, 3,2,7,4, 5,7,5,6, 4,3,2,0, 4,0,6,0, 1,6,7,4, 4,7,4,5

C.5.1.4.3 Forward error correction.

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:

  1. Initialize the eight memory cells x1 .. x8 of the encoder with the last eight bits of the payload sequence, p40 .. p47, so that cell x1 contains p40 and cell x8 contains p47.
  2. Shift the first bit of the payload sequence, p0, into cell x8.
  3. Extract the first three coded output bits bitout0, bitout1, and bitout2, in that order, as shown in figure C-8.
  4. Shift the next payload bit into cell x8, then extract the three coded output bits bitout0, bitout1, and bitout2.
  5. Repeat step 4 until a total of 144 coded bits have been produced.

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.

FIGURE C-8. Rate 1/3, constraint length 9 convolutional encoder.

C.5.1.4.4 Interleaving.

See C.5.1.2 for a description of the interleaving process. The interleaver parameters for BW1 are as follows:

TABLE C-XII. Interleaver parameters for BW1.
R16
C9
irs0
ics1
irs1
ics0
irf1
icf0
irf0
icf1

See C.5.1.2 for a complete description of the block interleaving process used by the various burst waveforms.

C.5.1.4.5 Orthogonal symbol formation.

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.

C.5.1.4.6 PN spreading sequence generation and application.

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


TABLE C-XIII. BW1 PN spreading sequence.

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.

C.5.1.4.7 Modulation.

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.

C.5.1.5 Burst Waveform 2 (BW2).

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.

FIGURE C-9. BW2 waveform structure and timing characteristics.

C.5.1.5.1 TLC/AGC guard sequence.

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.

C.5.1.5.2 Acquisition preamble.

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.

C.5.1.5.3 CRC computation.

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:

X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 + X8 + X7 + X5 + X4 + X2 + X1 + 1.

Other details of the CRC computation procedure are as defined in C.4.1.

C.5.1.5.4 Data packet extension.

FIGURE C-10. Data packet extension with encoder flush bits.

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.

C.5.1.5.5 Forward error correction.

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.


FIGURE C-11. Rate 1/4, constraint length 8 convolutional encoder.

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.

C.5.1.5.6 Modulation Symbol formation.

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.

TABLE C-XIV. Gray coding table.
Input Data

(Modulation Symbol)
Output Data

(Gray-Coded Modulation Symbol)
000
000
001
001
010
011
011
010
100
111
101
110
110
100
111
101

C.5.1.5.7 Frame formation.

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.

C.5.1.5.8 PN spreading sequence generation and application.

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.

FIGURE C-12. 2 16 - 1 maximum-length sequence generator.

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:

  1. For each input symbol (preamble symbol or gray-coded modulation symbol), a three-bit spreading symbol is formed by cycling the PN generator three times, and then taking the three least significant bits B2, B1, and B0 (as shown in figure C-12) from the shift register, with B2 becoming the most significant bit of the spreading symbol.
  2. The spreading symbol is then summed modulo 8 with the input symbol to form a three-bit channel symbol.

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.

C.5.1.5.9 Modulation.

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.

C.5.1.6 Burst Waveform 3 (BW3).

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

FIGURE C-13. BW3 timing.

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:

C.5.1.6.1 Preamble.

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.

C.5.1.6.2 CRC computation.

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:

X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 + X8 + X7 + X5 + X4 + X2 + X1 + 1.

Other details of the CRC computation procedure are as defined in C.4.1.

C.5.1.6.3 Forward error correction.

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.

FIGURE C-14. BW3 rate 1/2, k=7 convolutional encoder.

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).

C.5.1.6.4 Interleaving.

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.
n
64
128
256
512
R
24
32
44
64
C
24
34
48
65
irs
7
7
7
7
ics
0
0
0
0
irs
0
0
0
0
ics
1
1
1
1
irf
1
1
1
1
icf
-7
-7
-7
-7
irf
0
0
0
0
icf
-7
-7
-7
-7


TABLE C-XV. Interleaver parameters for BW3.

C.5.1.6.5 Orthogonal symbol formation.

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.

C.5.1.6.6. PN spreading sequence generation and application.

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

TABLE C-XVI. BW3 PN spreading sequence.

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.

C.5.1.6.7 Modulation.

See C.5.1.8 for a description of how combined tribit values are mapped to carrier phases and the subsequent carrier modulation process.

C.5.1.7 Burst Waveform 4 (BW4).

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


FIGURE C-15. BW4 timing.

The description of the BW4 waveform generation will proceed as follows:

C.5.1.7.1 TLC/AGC guard sequence.

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.

C.5.1.7.2 Orthogonal symbol formation.

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.

TABLE C-XVII. Walsh modulation of BW4 payload bits to tribit sequences.
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

C.5.1.7.3 PN spreading sequence generation and application.

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.

TABLE C-XVIII. BW4 PN spreading sequence.

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.

C.5.1.7.4 Modulation.

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.

C.5.1.8 Burst waveform modulation.

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:

Tribit Value
Phase

Shift
In-Phase

(I)
Quadrature

(Q)
0
0
1.0
0.0
1
/4
1 /
1 /
2
/2
0.0
1.0
3
3/4
-1 /
1 /
4
-1.0
0.0
5
5/4
-1 /
-1 /
6
3/2
0.0
-1.0
7
7/4
1 /
-1 /

TABLE C-XIX. 8-ary PSK signal space.

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.

FIGURE C-16. Carrier modulation.

C.5.2 3G-ALE protocol definition.

3G-ALE shall be implemented as defined in the following paragraphs.

C.5.2.1 3G-ALE service primitives.

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.

TABLE C-XX. 3G-ALE service primitives.
Name
Attribute
Values
Description
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
priPriority 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

TABLE C-XX. 3G-ALE service primitives (continued).
Name
Attribute
Values
Description
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

C.5.2.2 3G-ALE PDUs.

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.



FIGURE C-17. 3G-ALE PDUs.

C.5.2.2.1 LE_Call PDU.

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.


TABLE C-XXI. Call type field encodings.
Code
Call Type
Second PDU From
0
3G ARQ Packet Data Responder
1
HF Modem Circuit Responder
2
Analog Voice Circuit Responder
3
High-Quality Circuit Responder
4
Unicast ARQ Packet Caller
5
Unicast Circuit Caller
6
Multicast Circuit Caller
7
ControlCaller

C.5.2.2.2 LE_Handshake PDU.

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):

  1. temp1 = <caller address> * 0x13C6EF
  2. temp2 = <responder address> * 0x13C6EF
  3. LinkID = ( (temp1 >> 4) + (temp2 >> 15) ) & 0x3f

where '*' indicates 32-bit unsigned multiplication, '>> n' indicates right shift by n bits, and '&' indicates bitwise AND. Example LinkID computations are shown below.

Caller
Responder
temp1
temp2
result
result
1
2
0013c6ef
00278dde
3D
61
1
3
0013c6ef
003b54cd
24
36
2
1
00278dde
0013c6ef
4
4
3
1
003b54cd
0013c6ef
33
51
1951
1
96b91771
0013c6ef
1E
30
(decimal)
(decimal)
(hexadecimal)
(hexadecimal)
(hexadecimal)
(decimal)

The Command field shall be encoded as shown in table C-XXII. Unused encodings are reserved, and shall not be used until standardized.

TABLE C-XXII. Command field encodings.
Code
Command
Description
Argument
0
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).
Reason
1
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.
Channel
2
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)
Channel
3
Link Release This command informs all listening stations that the specified traffic channel is no longer in use by the sending station.
Channel
4
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).
Quality | Slot
6
DataThis command is reserved for special-purpose protocols. The argument carries previously requested data.
Data
7
Abort Handshake This command immediately terminates the handshake and needs no response. It is analogous to the TWAS preamble in 2G ALE.
Reason

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.

TABLE C-XXIII. Reason field encodings.
Code
Reason
0
NO_RESPONSE
1
REJECTED
2
NO_TRAF_CHAN
3
LOW_QUALITY

C.5.2.2.3 LE_Notification PDU.

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.

TABLE C-XXIV. Caller status field encodings.
Code
Station Status
0
Nominal
1
Time server
6
Commencing EMCON
7
Leaving network

C.5.2.2.4 LE_Broadcast PDU.

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.

C.5.2.2.5 Scanning call PDU.

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.

C.5.2.2.6 CRC computation for 3G-ALE PDUs.

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.

C.5.2.3 Synchronous dwell structure.

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.

FIGURE C-18. Synchronous dwell structure.

C.5.2.4 3G-ALE protocol behavior.

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.

C.5.2.4.1 3G-ALE protocol data.

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.

TABLE C-XXV. 3G-ALE protocol data.
Data item
Description
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)

C.5.2.4.2 3G-ALE protocol events.

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.

TABLE C-XXVI. 3G-ALE protocol events.
Event name
Description
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

C.5.2.4.3 3G-ALE protocol actions.

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.

TABLE C-XXVII. 3G-ALE protocol actions.
Action name
Description
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

TABLE C-XXVII. 3G-ALE protocol actions (continued).
Action name
Description
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

C.5.2.4.4 3G-ALE synchronous mode protocol.

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.

C.5.2.4.4.1 3G-ALE synchronous mode slot selection.

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.

TABLE C-XXVIIIa. (Probability of slot selection) for LE_call PDUs.
Call Priority
Slot 1
Slot 2
Slot 3
Highest
65%
30%
5%
High
40%
35%
25%
Routine
25%
35%
40%
Low
5%
30%
65%

TABLE C-XXVIIIb. Probability of slot selection for LE_broadcast and LE_notification PDUs.
Probability of Slot Selection for LE Broadcast and LE Notification PDUs.
Call Priority
Slot 1
Slot 2
Slot 3
Slot 4
Highest
50%
30%
15%
5%
High
30%
50%
15%
5%
Routine
5%
15%
50%
30%
Low
5%
15%
30%
50%

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.

C.5.2.4.4.2 3G-ALE synchronous mode individual calling overview.

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.

C.5.2.4.4.3 3G-ALE synchronous mode unicast calling.

A unicast call is used to contact an individual station and direct it to a traffic channel selected by the calling station.

  1. An LE_Call PDU shall be sent as usual, containing the individual responding-station address. The Call Type field shall be Unicast. No station shall respond to a Unicast-type LE_Call PDU.
  2. The caller shall send an LE_Handshake PDU in the immediately following response slot that directs the called station to a traffic channel.
  3. The called station shall tune to that channel and listen for modem traffic if the command in the LE_Handshake PDU is Commence Traffic Setup. If the command is Voice Traffic, the called station shall tune to the channel and prepare for voice traffic (e.g., unmute the speaker). If the announced traffic does not begin to arrive within the traffic wait timeout, the called station shall return to scan.
  4. After sending the LE_Handshake PDU, the caller shall tune to the specified channel and initiate the type of traffic indicated in the LE_Handshake PDU.

Note that a unicast call may be used to set up a link for bidirectional traffic.

C.5.2.4.4.4 3G-ALE synchronous mode multicast calling.

A multicast call is used to contact selected stations concurrently and direct them to a traffic channel selected by the calling station.

  1. An LE_Call PDU shall be sent as usual, but it shall contain a multicast responding-station address. The Call Type field shall be Multicast. No station shall respond to a Multicast-type LE_Call PDU.
  2. The caller shall send an LE_Handshake PDU in the immediately following response slot that directs the called stations to a traffic channel. The link ID field shall be computed in accordance with C.4.5.3 Multicast addresses.
  3. The called stations shall tune to that channel and listen for modem traffic if the command in the LE_Handshake PDU is Commence Traffic Setup. If the command is Voice Traffic, the called stations shall tune to the channel and prepare for voice traffic (e.g., unmute the speaker). If the announced traffic does not begin to arrive within the multicast traffic wait timeout, the called stations shall return to scan. (This timeout should be set to accommodate calls to the maximum number of dwell groups whose members may subscribe to the multicast.)
  4. When the stations subscribing to a multicast are assigned to more than one dwell group, the multicast call (both PDUs) shall be sent repeatedly by the caller. The caller should select the timing (and possible redundancy) of its transmissions to minimize calling channel occupancy while maximizing the probability of reaching called stations.
  5. After sending the (final) LE_Handshake PDU, the caller shall tune to the specified channel and initiate the type of traffic indicated in the LE_Handshake PDU.

C.5.2.4.4.5 3G-ALE synchronous mode broadcast calling - not tested (NT)

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.

C.5.2.4.4.6 3G-ALE synchronous mode link release.

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.

C.5.2.4.4.7 3G-ALE synchronous mode protocol behavior.

Implementations of 3G-ALE operating in synchronous mode shall exhibit the same over-the-air behavior as that described in table C-XXIX.

TABLE C-XXIX. 3G-ALE synchronous mode protocol behavior.
State
Event
Condition
Action
Next State
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

TABLE C-XXIX. 3G-ALE synchronous mode protocol behavior (continued).
State
Event
Condition
Action
Next State
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

TABLE C-XXIX. 3G-ALE synchronous mode protocol behavior (continued).
State
Event
Condition
Action
Next State
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

TABLE C-XXIX. 3G-ALE synchronous mode protocol behavior (continued).
State
Event
Condition
Action
Next State
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

TABLE C-XXIX. 3G-ALE synchronous mode protocol behavior (continued).
State
Event
Condition
Action
Next State
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

C.5.2.4.4.8 3G-ALE synchronous mode protocol examples.

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.

C.5.2.4.4.9 3G-ALE synchronous mode timing characteristics.

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.

FIGURE C-19. Example 3G-ALE synchronous link establishment.
C.5.2.4.4.9.1 3G-ALE synchronous mode tuning time.

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.)

C.5.2.4.4.9.2 3G-ALE synchronous mode traffic channel evaluation timing.

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.)

C.5.2.4.4.9.3 3G-ALE synchronous mode call, broadcast, and notification timing.

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:

  1. 128 Tsym (approximately 53.3 ms) has elapsed since the start of the selected slot.
  2. If and only if a PDU was received in the preceding slot, 256 Tsym (approximately 106.7 ms) has elapsed since the end of that PDU. C.5.2.4.4.9.4 3G-ALE synchronous mode response timing

A responding station shall commence transmission of an LE_Handshake PDU at the later of the two following instants:

  1. 128 Tsym (approximately 53.3 ms) has elapsed since the start of the response slot at the responding station.
  2. 256 Tsym (approximately 106.7 ms) has elapsed since the end of the received LE_Call PDU. C.5.2.4.4.9.5 3G-ALE synchronous mode unicast, multicast, and link release command timing

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.

C.5.2.4.5 3G-ALE asynchronous mode protocol.

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.

C.5.2.4.5.1 3G-ALE asynchronous mode listen before transmit.

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.

C.5.2.4.5.2 3G-ALE asynchronous mode scanning call.

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.

C.5.2.4.5.3 3G-ALE asynchronous mode handshake.

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.

C.5.2.4.5.4 3G-ALE asynchronous mode unicast call.

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.

C.5.2.4.5.5 3G-ALE asynchronous mode multicast call.

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.

C.5.2.4.5.6 3G-ALE asynchronous mode broadcast call.

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:

  1. A repetition factor R shall be computed as the smallest integer that is greater than or equal to M C / 7. For example, if M = 1.2 and C = 10, R shall be 2.
  2. The initial value of the Countdown field shall be the smallest integer that is greater than or equal to M C / R. For example if M = 1.2 and C = 10, the initial Countdown value shall be 6.
  3. R identical repetitions of the LE_Broadcast PDU shall be sent, after which the Countdown field shall be decremented.
  4. Step 3 shall be repeated until the decremented value of the Countdown field is 0. A single instance of the LE_Broadcast PDU with Countdown = 0 shall be sent.
  5. The broadcast shall commence on the indicated channel 2 Tslot after the end of the final LE_Broadcast PDU.

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.

C.5.2.4.5.7 3G-ALE asynchronous mode link release.

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.

C.5.2.4.5.8 3G-ALE asynchronous mode entry to synchronous networks.

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.

C.5.2.4.5.9 3G-ALE asynchronous mode protocol behavior.

Implementations of 3G-ALE operating in asynchronous mode shall exhibit the same over-the-air behavior as that described in table C-XXX.

TABLE C-XXX. 3G-ALE asynchronous mode protocol behavior.
State
Event
Condition
Action
Next State
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

TABLE C-XXX. 3G-ALE asynchronous mode protocol behavior (continued).
State
Event
Condition
Action
Next State
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

TABLE C-XXX. 3G-ALE asynchronous mode protocol behavior (continued).
State
Event
Condition
Action
Next State
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

TABLE C-XXX. 3G-ALE asynchronous mode protocol behavior (continued).
State
Event
Condition
Action
Next State
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

C.5.2.4.5.10 3G-ALE asynchronous mode protocol example.

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.

FIGURE C-20. 3G-ALE asynchronous mode link establishment.
C.5.2.4.5.11 3G-ALE asynchronous mode timing characteristics.

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.

C.5.2.4.5.11.1 3G-ALE asynchronous mode scanning call timing.

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.

C.5.2.4.5.11.2 3G-ALE asynchronous mode handshake timing.

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

C.5.2.5 Notification protocol behavior.

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.

C.5.2.5.1 Station status notification.

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.

C.5.2.5.2 Sounding.

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.

C.5.2.5.3 Synchronous mode notifications.

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.

C.5.2.5.4 Asynchronous mode notifications.

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.

C.5.2.6 Calling into a 3G network.

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.

C.5.2.6.1 Net entry addresses.

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.

C.5.2.6.2 Link establishment for net entry.

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.

C.5.2.6.3 Acquisition of operating data.

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.

C.5.2.7 Synchronization management protocol (not tested).

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.

C.5.2.7.1 Synchronization data.

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.

C.5.2.7.2 Time quality.

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.

TABLE C-XXXI. 3G-ALE synchronization management time quality codes.
SM Time Quality Code
Total Time Uncertainty
0 (000)
none: UTC station
1 (001)
1 ms: local GPS receiver or equiv.
2 (010)
2 ms or stand-alone master station
3 (011)
5 ms
4 (100)
10 ms
5 (101)
20 ms
6 (110)
50 ms
7 (111)
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).

C.5.2.7.3 Synchronization management PDUs.

The LE_PDUs (see figure C-17) used in synchronization management are described in the following paragraphs.

C.5.2.7.3.1 Group time broadcast PDU.

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.

C.5.2.7.3.2 Sync check PDU.

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).

C.5.2.7.3.3 Sync offset PDU.

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.


TABLE C-XXXII. 3G-ALE synchronization management sync offset codes.
Sync Offset Code
Magnitude of Offset (ms)
  0 - 400
2 x Code
401 - 420
(reserved; do not use)
421 - 511
40 x (Code - 400)

C.5.2.7.4 Sync check handshake.

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:

  1. The initiator shall measure the elapsed time between the end of its Sync Check PDU and the time of arrival of the end of the LE_Sync Offset PDU. The propagation delay Tpd shall be computed as Tpd = (Elapsed time - 720 ms) / 2.
  2. If the LE_Sync Offset PDU Sign field is 0 (initiator is behind), the initiator shall subtract Tpd from the Offset field and add the result to its local time. Otherwise (Sign field = 1), the initiator shall add Tpd to the Offset field and subtract the result from its local time.
  3. The initiator shall set its time base uncertainty to the value corresponding to the Quality code in the LE_Sync Offset PDU plus 5 ms to allow for unmeasured fluctuations in time of PDU release and in propagation delay.

A sync check handshake shall begin with equal probability in slot 1 or slot 2, and shall not begin in later slots.

C.5.2.7.5 Synchronization maintenance.

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.

C.5.2.7.6 Synchronization for late net entry.

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.

  1. The unsynchronized station (caller) initiates the protocol by sending an asynchronous Control call to a time server or other known address. The caller may use either a Net Entry address (C.5.2.6.1) or a network member address assigned as described in C.5.2.6.3. The call shall consist of LE_Scanning Call PDUs addressed to the called station (responder), a Control type LE_Call PDU addressed to the responder, and an LE_Sync Check PDU with the Argument field set to all 1's. This special value in the Argument field indicates that the call is a time request rather than a sync maintenance request.
  2. In response to an LE_Sync Check PDU with the Argument field set to all 1's, the responder will return an LE_GTB PDU rather than a Sync Offset PDU. The LE_GTB PDU shall be sent 128 Tsym after the slot boundary the follows the end of the received LE_Sync Check PDU, and shall report the slot number of the slot it occupies (which may be slot 0). The LE_GTB PDU shall be sent on the frequency that carried the call. After sending the LE_GTB PDU, the responder shall remain on the same frequency, ignore the next slot and check the slot after that for an LE_Call PDU.
  3. The caller should correct its local time using the time contained in the LE_GTB PDU, with the assumption that propagation time from the responder was zero, and set its time uncertainty to 70 ms. It should then initiate the synchronization maintenance protocol described above (C.5.2.7.4) in the second slot after the LE_GTB PDU. If no response (or a garbled response) is received, the station may continue to attempt Sync Check handshakes with the responder on the responder's assigned dwell channels using the formula in C.4.4.1 if it knows the calling channels in use in the network. Otherwise it must restart this protocol at step 1.
  4. If the responder receives error-free LE_Call and LE_Handshake PDUs containing the expected fields for a Sync Check handshake from the entering station, it shall complete the handshake by sending an LE_Sync Offset PDU as described in C.5.2.7.3.3. After sending this PDU, or after failing to receive the appropriate PDUs, the responder shall return to the Scanning state on its then-current assigned dwell channel.

An entering station shall not place any other synchronous call to the network until this synchronization is completed.

C.5.2.7.7 Initial time distribution.

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:

  1. Any dwell group time server that has not received the expected LE_Notification/LE_GTB sequence from the master time station within 8 minutes after the expected startup of the time distribution protocol should initiate the late net entry synchronization protocol from C.5.2.7.6, calling the master time station and, if it receives no response after calling on all channels, calling designated alternate master time station(s) and other group time servers.
  2. Any dwell group member that received the initial LE_Notification/LE_GTB sequence from the master time station, but does not receive the expected LE_Notification/LE_GTB sequence from the group time server after listening for 60 dwells should attempt late net entry synchronization calling its dwell group time server first, followed by calls to the master and alternate master time stations.
  3. Any dwell group member that does not receive the initial LE_Notification/LE_GTB sequence from the master time station within 10 minutes after the expected startup of the time distribution protocol should initiate the late net entry synchronization protocol from C.5.2.7.6, calling its group time server first, followed by calls to the master and alternate master time stations.

As each station achieves synchronization, it commences synchronous operation.

C.5.3 TM protocol.

C.5.3.1 Overview.

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:

  1. the identities of the stations intended to participate in the connection;
  2. the connection topology: point-to-point, multicast, or broadcast;
  3. the link mode: packet or circuit ("hard link");
  4. the HF frequency (or "traffic channel") that will be used for signalling within the connection.

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:

  1. whether the connection will be used to deliver data or voice traffic, if it is a circuit connection;
  2. which data link protocol(s), waveform(s), and/or baseband modulation formats will be used to deliver traffic on the connection;
  3. the priority of the traffic to be delivered;
  4. the fine time synchronization required for the HDL and LDL protocols, on traffic links established for packet traffic.

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.

C.5.3.2 Data object types.

The terms defined in table C-XXXIII are used to refer to specific types of data objects in defining the TM protocol.

TABLE C-XXXIII. TM data object types.
Data object type Definition
traffic typeidentifies 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).

C.5.3.3 Service primitives.

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.

TABLE C-XXXIV. TM service primitives.
Name
Attribute
Value
Description
TM_Connect_ReqOverview TM Connect Request: issued to TM by the user process to request establishment of a traffic link.
Parameters topologyIdentifies the topology of the traffic link being established; one of:
  • P2P (point-to-point): the traffic link will contain the initiating station and a single called station.
  • MC (multicast): the traffic link will contain the initiating station together with all members (or as many as possible) of a defined multicast group.
  • BC (broadcast): the traffic link will contain the initiating station together with all other stations in the net that receive the ALE Broadcast PDUs used to place the broadcast call.

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
  1. A connection has just been established by 3G-ALE, with this station as a participant.
  2. No traffic link is established. I.e., the most recent service primitive (if any) passed between TM and the user process was a TM_Disconnect_Req, a TM_Disconnect_Ind, or a TM_Disconnect_Conf.
TM_Connect_IndOverview 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 trafficTypeIdentifies 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.

TABLE C-XXXIV. TM service primitives (continued).
Name
Attribute
Value
Description
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
  1. No traffic link is established. I.e., the most recent service primitive (if any) passed between TM and the user process was a TM_Disconnect_Req, a TM_Disconnect_Ind, or a TM_Disconnect_Conf.
TM_Connect_ConfOverview 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 responseslist 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
  1. Either
    1. A traffic link is being established at the request of the local user process; i.e., the most recent service primitive passed between TM and the user process was a TM_Connect_Req; or
    2. An established traffic link is being reversed after successful delivery of packet data; i.e., the most recent service primitive passed between TM and the user process was a TM_Connect_Ind.
TM_Disconnect_ReqOverview 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 reasonreason for disconnection. Value is one of:
  • RELINK: requests that the traffic link be re-established on a different channel. Used only on point-to-point traffic links.
  • SIGN_OFF: requests that the local station sign-off a multicast or broadcast circuit link, without necessarily causing the link to be terminated: other stations may stay linked. Used only at slave stations on multicast and broadcast circuit links.
  • ABORT: requests that the traffic link be immediately terminated. In broadcast or multicast circuit connections, can be issued only by the user process of the circuit master: the station that initiated the circuit.
  • UNLINK: requests that a multicast traffic link be terminated with a final roll call occurring just before the link is dropped. Used only on multicast circuit links; can be issued only at the master station: the station that initiated the circuit.
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
  1. A traffic link is currently established or is being established. I.e., TM has accepted a TM_Connect_Req service primitive since the most recent time at which it issued a TM_Disconnect_Ind or a TM_Disconnect_Conf, or accepted a TM_Disconnect_Req.

TABLE C-XXXIV. TM service primitives (continued).
Name
Attribute
Value
Description
TM_Disconnect_IndOverview 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 reasonreason for disconnection. Value is one of:
  • SIGN_OFF: indicates that the local station has left a traffic link due to another station's having signed-off the link - the other station in a unicast link, or the last remaining station in a multicast or broadcast circuit of which the local station was master.
  • ABORT: the local station has left a traffic link due to the link master station's having aborted the link.
  • EOM: the local station has left a packet traffic link due to successful completion of the packet data transfer and the absence of any packet traffic pending in the reverse direction.
  • RELINK: the remote station has initiated a re-link operation in which the participating stations will attempt to re-establish the traffic link on a different channel, by sending a TM_TERM PDU to the local station with Reason = RELINK. Used only on point-to-point traffic links.
  • REQ_TIMEOUT: the local station has left a traffic link due to failure to receive a TM_REQ PDU in the time period in which one was expected. If the traffic link being established was a unicast link, the two stations will attempt to re-link.
  • CONF_TIMEOUT: the local station has left a traffic link due to failure to receive a TM_CONF PDU in the time period in which one was expected. If the traffic link being established was a unicast link, the two stations will attempt to re-link.
  • TRF_TIMEOUT: the local station has left a circuit traffic link, due to the CLC's (CLC's) having detected no traffic on the circuit link over a time interval equal to its traffic timeout period.
  • UNLINK: the remote master station of the currently-established multicast circuit has requested that the circuit link be dropped after a final roll call ("unlink") is performed. A TM_Disconnect_Ind service primitive with reason = UNLINK requests that the user process respond with a TM_Disconnect_Resp service primitive indicating whether the local station has succeeded or failed in receiving the traffic delivered on the circuit link.
Originator TM
Preconditions
  1. A traffic link is currently established or is being established. I.e., TM has accepted a TM_Connect_Req service primitive since the most recent time at which it issued a TM_Disconnect_Ind or a TM_Disconnect_Conf, or accepted a TM_Disconnect_Req.
TM_Disconnect_Resp OverviewTM 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 ackNakPositive or negative acknowledgement of having received the traffic delivered on the multicast circuit. Possible values are
  • ACK: the traffic delivered on the multicast circuit was received successfully (with the user process determining what counts as "success")
  • NAK: the traffic delivered on the multicast circuit was not detected or received containing (an excessive quantity of) errors.
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

TABLE C-XXXIV. TM service primitives (continued).
Name
Attribute
Value
Description
Preconditions
  1. A multicast circuit link is presently active.
  2. TM has just issued a TM_Disconnect_Ind service primitive to the user process with reason = UNLINK.
TM_Disconnect_Conf OverviewTM 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 reasonThe 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:
  1. at a slave station, the user process has requested that the station remain in the circuit link only long enough to transmit its own roll call response, by setting the watch parameter of its TM_Disconnect_Resp primitive to FALSE. In this case, the reason parameter has the value UNLINK; and responses are not included in the list from those stations whose roll call time slots fall after the local station's time slot.
  2. at either the master station or a slave station, the user process may have cut short the station's participation in the roll call, by issuing a TM_Disconnect_Req service primitive while the roll call is in progress. In this case, the reason parameter-value will be ABORT at the master station, or SIGN_OFF at a slave station; the response list will include only responses received before the TM_Disconnect_Req was accepted.

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_ReqOverview 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
  1. A multicast circuit link initiated by the local station is currently active. I.e., since any other exchange of TM service primitives, TM has issued a TM_Connect_Conf service primitive to the user process whose responses parameter identifies those multicast group member stations which responded to the most recent multicast circuit roll call.

TABLE C-XXXIV. TM service primitives (continued).
Name
Attribute
Value
Description
TM_Resume_ReqOverview 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
  1. A multicast circuit link is currently suspended.
  2. Since the multicast circuit link was suspended by means of a TM_Suspend_Req PDU, an additional 3G-ALE multicast call has been completed.

C.5.3.4 PDUs.

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.

TABLE C-XXXV. TM PDU format.
Field name
Size (bits)
Values
Description
Protocol
3
0012 (fixed) distinguishes TM PDUs from HDL_ACK and HDL_EOM PDUs
Priority
2
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
11
anyaddress 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
11
anyaddress of the station that is sending this PDU. Is always the station address of a single station - never a multicast or broadcast address.
Type
3
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
6
variant field whose usage and meaning depend on the value of the Type field; see TABLE XXXVI.
CRC
12
any12-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.


TABLE XXXVI. Argument field values.
Type field Value
Field name
Values
Description
TM_REQUEST or TM_CONFIRM Traffic TypeIndicates 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.

C.5.3.5 Protocol behavior.

The following sections define the behavior of the TM protocol:

C.5.3.5.1 Events.

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.

TABLE C-XXXVII. TM events.
Event name
Description
ConfirmTimeoutA 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,
  • 'topology' is replaced by 'P2P' (point-to-point), 'MC' (multicast), or 'BC' (broadcast), indicating the topology of the traffic link being established
  • 'role' is replaced by 'MASTER' or 'SLAVE', where the link master is the station initiating the traffic link
  • 'trafficType' is replaced by one of the traffic type values defined in table C-XXXIII. The values 'PKT' and 'CKT' are used whenever role = SLAVE, since the slave station does not yet know the specific type of traffic that is to be delivered on the traffic link (as this information is not conveyed by 3G-ALE). 'pktTraf' is used as an abbreviation for any of the HDL_n or LDL_n traffic types which can be delivered on a packet traffic link; 'cktTraf' is used for any traffic type other than HDL_n or LDL_n, which can be delivered on a circuit traffic link.
  • 'addr' is replaced by either 'indAddr' (the remote station participating in a packet or point-to-point circuit link), 'MCaddr' (the address of the called multicast group), or 'BCaddr' (the all-ones broadcast address). Note that addr is ignored whenever topology = BC; although an all-ones broadcast value is transmitted in TM PDUs, this address value has no significance.
  • 'reqIntvl'' is used only at slave stations participating in broadcast circuit links. The value of reqIntvl is based on the Countdown field-value of the received LE_BROADCAST PDU.
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_ReqA TM_Suspend_Req service primitive was received from the user process.
D:TM_Resume_ReqA TM_Resume_Req service primitive was received from the user process.
DropTimeoutThe 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.

TABLE C-XXXVII. TM events (continued).
Event name
Description
EndOfMCRollCallIndicates 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.
EndOfUnlinkIndicates 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.
MyRCSlotIndicates 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:
  1. The individual addresses of the multicast group member stations are placed in a list.
  2. If the link master (the station that initiated the link) is a member of the multicast group, its individual address is removed from the list (see note).
  3. The list of addresses is sorted by increasing dwell group number, and, for stations in the same dwell group, by increasing member number (so that, for instance, {group #4, member#5} precedes {group #5, member #2}, and {group #5, member #2} precedes {group #5, member #4}).
  4. The station whose address is first in the list is assigned the first roll call slot (the slot immediately following the transmission of the TM_REQUEST PDU that initiated the roll call), the one whose address is second gets the second slot, and so forth.
otherRefers to any event not corresponding to any of the explicit event labels on transitions leaving the current state.
R:otherRefers 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.

TABLE C-XXXVII. TM events (continued).
Event name
Description
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.
RequestTimeoutA 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.
ReversalTimeoutA 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_IndA 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_IndA 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_IndA 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_IndAn 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_ConfAn 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.

C.5.3.5.2 Actions.

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.

TABLE C-XXXVIII. TM actions.
Action name
Description
D:CLC_Active_ReqIssue 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_ReqIssue 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.
InitRollCallInitialize (empty) RollCallResponses; initialize and start RollCallTimer.
InitUnlinkInitialize (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.

TABLE C-XXXVIII. TM actions (continued).
Action name
Description
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.
MarkLinkAvailSet LinkBusy to FALSE (since the link is "available").
MarkLinkBusySet 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.
noneNo 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'.

TABLE C-XXXVIII. TM actions (continued).
Action name
Description
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:
  1. once, if no explicit howMany value is provided;
  2. three times, if howMany = '3x'; and
  3. as many times as possible within a High-Rate or LDL forward transmission interval, if howMany = 'nx':
    1. once, for traffic type HDL_3 or HDL_6;
    2. three times, for traffic type HDL_12;
    3. seven times, for traffic type HDL_24;
    4. once, for traffic type LDL_64 or LDL_128;
    5. two times, for traffic type LDL_256; and
    6. five times, for traffic type LDL_512.

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.

ScheduleAbortSet ScheduledAbort to TRUE.
ScheduleSignoffSet 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.

TABLE C-XXXVIII. TM actions (continued).
Action name
Description
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.

C.5.3.5.3 Data.

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.

TABLE C-XXXIX. TM data items.
Data item
Description
ConfirmTimerTimer timing the period in which receipt of a TM_CONF PDU is expected in response to a TM_REQ PDU just sent.
DropTimerTimer 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.
LinkBusyBoolean 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).
RequestTimerTimer 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.
ReversalTimerTimer 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.
RollCallResponsesList 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.
RollCallTimerTimer 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.
ScheduledSignoffBoolean 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.
ScheduledAbortBoolean 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.
UnlinkResponsesList 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.

C.5.3.5.4 Behavior definition.

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.

FIGURE C-21. TM state diagram: packet.

FIGURE C-22. TM state diagram: point-to-point circuit.


FIGURE C-23. TM state diagram: multicast circuit (master).

FIGURE C-24. TM state diagram: multicast circuit (slave).


FIGURE C-25. TM state diagram: broadcast circuit.

TABLE C-XL. TM state transition table.
StateEvent ConditionAction Next State
IdleD: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

TABLE C-XL. TM state transition table (continued).
StateEvent ConditionAction Next State
other none Wait for Packet Request
Linked as Packet Slave U:xDL_Rcv_IndNOT 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 LinkBusyS:TM_TERM (reason, indAddr)+

D:CLC_Idle_Req+

U:TM_Disconnect_Conf (reason)

Idle
D:TM_Disconnect_Req (ABORT | RELINK, period) LinkBusyD: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

TABLE C-XL. TM state transition table (continued).
StateEvent ConditionAction 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 LinkBusyS: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) LinkBusyD: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 EndOfMCRollCallNOT 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

TABLE C-XL. TM state transition table (continued).
StateEvent ConditionAction Next State
D:TM_Disconnect_Req (ABORT) ScheduleAbort Wait for MC Roll Call Responses
other none Wait for MC Roll Call Responses
EndOfMCRollCall Scheduled AbortU: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 LinkBusyS:TM_TERM (ABORT, MCaddr)+ D:CLC_Idle_Req+

U:TM_Disconnect_Conf (ABORT)

Idle
D:TM_Disconnect_Req (ABORT, period) LinkBusyD: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 LinkBusyS:TM_TERM (UNLINK, MCaddr)+ D:CLC_Idle_Req+

InitUnlink

Unlink MC Circuit, Master
D:TM_Disconnect_Req (UNLINK, period) LinkBusyD: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

TABLE C-XL. TM state transition table (continued).
StateEvent ConditionAction 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 EndOfMCRollCallNOT 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 SignoffU:TM_Disconnect_Conf (SIGN_OFF)+

S:TM_TERM (SIGN_OFF, MCaddr)

Idle
Linked as MC SlaveR:TM_TERM (SIGN_OFF, srcAddr) MarkAbsent (srcAddr) Linked as MC Slave
D:TM_Disconnect_Req (SIGN_OFF, period) NOT LinkBusyS:TM_TERM (SIGN_OFF, MCaddr)+

D:CLC_Idle_Req+

U:TM_Disconnect_Conf (SIGN_OFF)

Idle
D:TM_Disconnect_Req (SIGN_OFF, period) LinkBusyD: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

TABLE C-XL. TM state transition table (continued).
StateEvent ConditionAction 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 RespsS: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

TABLE C-XL. TM state transition table (continued).
StateEvent ConditionAction 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 SlaveD: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

C.5.3.5.5 Timing characteristics.

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.

TABLE C-XLI. Protocol time-intervals.
Interval
# 32

Frames
# 48 Frames
# PSK

Symbol times
Duration

(ms., approx.)
Description
Tslot60 1920 800Duration of 3G-ALE slot.
Tdwell300 9600 4000Duration of 3G-ALE dwell.
Tsug4 128 53.33LE sync uncertainty guard interval
Ttune45 1600 666.67TM coupler tune allowance
Tprop,max 6192 80.00maximum propagation delay
TBW0proc 8128 53.33BW0 processing time (after last sample is received)
TBW1enc5 160 66.67BW1 encoding time (prior to emission of first sample)
TBW198 3136 1306.67BW1 transmission duration (TLC+preamble+data)
TBW1proc 10320 133.33BW1 processing time (after last sample is received)
TBW2enc22 704 293.33BW2 encoding time (prior to emission of first sample)
TBW22 5+20n304+960n 126.67+ (n*400.00) BW2 transmission duration -- n packets per transmission (n = 3, 6, 12, or 24)
TBW2(3)2 653184 1326.67BW2 transmission duration (3 packets per transmission)
TBW2(6)2 1256064 2526.67BW2 transmission duration (6 packets per transmission)
TBW2(12) 2245 118244926.67 BW2 transmission duration (12 packets per transmission)
TBW2(24) 2485 233449726.67 BW2 transmission duration (24 packets per transmission)
TBW2proc 11528 220.00BW2 processing time (after last sample is received)
TBW3enc5 160 66.67BW3 encoding time (prior to emission of first sample)
TBW328+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) 922944 1226.67BW3 transmission duration (preamble+data) - 64 payload bytes per transmission
TBW3(128) 1564992 2080.00BW3 transmission duration (preamble+data) - 128 payload bytes per transmission
TBW3(256) 2849088 3786.67BW3 transmission duration (preamble+data) - 256 payload bytes per transmission
TBW3(512) 54017280 7200.00BW3 transmission duration (preamble+data) - 512 payload bytes per transmission
TBW3proc 5160 66.67BW3 processing time (after last sample is received)
TBW4enc5 160 66.67BW4 encoding time (prior to emission of first sample)
TBW448 1536 640.00BW4 transmission duration (TLC+data)

TABLE C-XLI. Protocol time-intervals (continued).
Interval
# 32

Frames
# 48 Frames
# PSK

Symbol times
Duration

(ms., approx.)
Description
TBW4proc 5160 66.67BW4 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
TCLenc15 2400 1000.00MIL-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.

TABLE C-XLI. Protocol time-intervals.
Interval
# 32

Frames
# 48 Frames
# PSK

Symbol times
Duration

(ms., approx.)
Description
TCLpre15 480 200.00Duration 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.
TCLproc15 480 200.00Mil-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.

C.5.3.5.5.1 Point-to-point packet link.

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.

C.5.3.5.5.1.1 Point-to-point packet link timing description.

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:

C.5.3.5.5.1.2 Point-to-point packet link timing requirements.

The following requirements apply to point-to-point packet link timing:

  1. Stations shall reckon the start of a link as the start of the 3G-ALE slot immediately following the slot in which the LE_COMMENCE PDU was transmitted.
  2. For Ttune seconds after the start of the link, stations shall change to the traffic channel, if necessary, and tune, if necessary.
  3. The Master shall begin emission of the TM_REQUEST PDU Ttune + Tsug seconds after the start of the link.
  4. The Slave shall begin emission of its response TM PDU TBW1proc + TBW1enc seconds after the end of the TM_REQUEST PDU as observed by the Slave.
  5. The Master shall begin emission of the first data link protocol HDL_DATA PDU TRTFD, HDL seconds after emission of the TM_REQUEST PDU began. Thereafter, the Master shall begin emissions of HDL_DATA PDUs THDL(n) seconds after the emission of the previous HDL_DATA PDU began.
  6. The Slave shall begin emission of the first data link protocol HDL_ACK PDU TCTFA(n), HDL seconds after emission of its response TM PDU began. Thereafter, the Slave shall begin emissions of HDL_ACK PDUs THDL(n) seconds after the emission of the previous HDL_ACK PDU began.
  7. The Master shall begin emission of the first HDL_EOM PDU THDL(n) seconds after the emission of the previous HDL_DATA PDU began.
  8. If reverse traffic is pending, the Slave shall begin emission of the TM_REQUEST PDU THDL(n) seconds after the emission of the previous HDL_ACK PDU began. At this point the roles of Master and Slave reverse, and point-to-point packet link timing requirements 4-7 apply.
  9. The Master shall begin emission of the first data link protocol LDL_DATA PDU TRTFD, LDL seconds after emission of the TM_REQUEST PDU began. Thereafter, the Master shall begin emissions of LDL_DATA PDUs TLDL(n) seconds after the emission of the previous LDL_DATA PDU began.
  10. The Slave shall begin emission of the first data link protocol LDL_ACK PDU TCTFA(n), LDL seconds after emission of its response TM PDU began. Thereafter, the Slave shall begin emissions of LDL_ACK PDUs TLDL(n) seconds after the emission of the previous LDL_ACK PDU began.
  11. The Master shall begin emission of the first LDL_EOM PDU TLDL(n) seconds after the emission of the previous LDL_DATA PDU began.
  12. If reverse traffic is pending, the Slave shall begin emission of the TM_REQUEST PDU TLDL(n) seconds after the emission of the previous LDL_ACK PDU began. At this point the roles of Master and Slave reverse, and point-to-point packet link timing requirements 4 and 9-11 apply.







FIGURE C-26. Point-to-point packet link timing example for TdeltaTOD =0, Tprop = Tprop,max..

FIGURE C-27. Point-to-point packet link timing example for TdeltaTOD = -Tsug, Tprop = Tprop,max.

FIGURE C-28. Point-to-point packet link timing example for TdeltaTOD = Tsug, Tprop = Tprop,max.

FIGURE C-29. Point-to-point packet link timing example for TdeltaTOD = -Tsug, Tprop = 0.

FIGURE C-30. Point-to-point packet link timing example for TdeltaTOD = Tsug, Tprop = 0.
C.5.3.5.5.2 Point-to-point circuit links.

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.

C.5.3.5.5.2.1 Point-to-point circuit link timing description.

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:

C.5.3.5.5.2.2 Point-to-point circuit link timing requirements.

The following requirements apply to point-to-point circuit link timing:

  1. Stations shall reckon the start of a link as the start of the 3G-ALE slot immediately following the slot in which the LE_COMMENCE PDU was transmitted.
  2. For Ttune seconds after the start of the link, stations shall change to the traffic channel, if necessary, and tune, if necessary.
  3. The Master shall begin emission of the TM_REQUEST PDU Ttune + Tsug seconds after the start of the link.
  4. The Slave shall begin emission of its response TM PDU TBW1proc + TBW1enc seconds after the end of the TM_REQUEST PDU as observed by the Slave.
  5. The Master shall begin transmission of its message Ttune + TTM,Master + TCLenc seconds after the start of the link.

FIGURE C-31. Point-to-point circuit link timing example.
C.5.3.5.5.3 Multicast circuit link.

This section will first provide a description of multicast circuit link timing. Following this, multicast circuit link timing requirements will be given.

C.5.3.5.5.3.1 Multicast circuit link timing description.

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:

C.5.3.5.5.3.2 Multicast circuit link timing requirements.

The following requirements apply to multicast circuit link timing:

  1. Stations shall reckon the start of a link as the start of the 3G-ALE slot immediately following the slot in which the LE_COMMENCE PDU was transmitted.
  2. For Ttune seconds after the start of the link, stations shall change to the traffic channel, if necessary, and tune, if necessary.
  3. The Master shall begin emission of the TM_REQUEST PDU Ttune + Tsug seconds after the start of the link.
  4. Slave 1 shall begin emission of its response TM PDU TBW1proc + TBW1enc seconds after the end of the TM_REQUEST PDU as observed by Slave 1.
  5. Slaves 2 through n, where n is the number of members of the multicast group, shall begin emission of their respective response PDUs 2*TBW1proc + 2*TBW1enc + TBW1 + 2*Tprop,max + (m-2)*Trc slot,TM seconds after the end of the TM_REQUEST PDU as observed by the Slave, where m is the position of the Slave in the multicast group (e.g. m = 2 for Slave 2).
  6. If, following the roll call, the Master elects to proceed with the multicast, the Master shall begin the multicast Ttune + TTM,Master + (n-1)*Trc slot,TM + TCLenc seconds after the start of the link. Otherwise, if the Master elects to transmit TM protocol PDU(s), the Master shall begin emission of such PDUs Ttune + TTM,Master + (n-1)*Trc slot,TM + TBW1enc seconds after the start of the link. Again, n is the number of members in the multicast group.



FIGURE C-32. Multicast circuit link timing example.

C.5.4 HDL protocol.

C.5.4.1 Overview.

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.

C.5.4.2 Data object types.

The terms defined in table C-XLII are used to refer to specific types of data objects in defining the HDL protocol.

TABLE C-XLII. HDL data object types.
Data object type
Definition
datagraman 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 segmentan ordered sequence of 8-bit data bytes (octets) that occur consecutively within a datagram, of length sl where 1 < sl < 233.
sequence numbera 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 packetthe 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 framea 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 indexa 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 packetthe combination of a data packet with the packet index indicating the data packet's ordinal position within a specific tx frame.
rx framea 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.

C.5.4.3 Service primitives.

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.

C.5.4.4 PDUs.

The sub-sections of this section describe the PDUs exchanged between a HDL protocol HDL entity and its remote peer entities.

C.5.4.4.1 HDL_DATA.

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.

TABLE C-XLIII. HDL service primitives.
Name
Attribute
Values
Description
HDL_Send_ReqOverview HDL Send Request: generated by the user process when it has a datagram to send on an already-established HF link.
Parameters datagramdatagram 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_ReqOverview HDL Receive Request: generated by the user process to request that HDL perform the processing required to receive an expected incoming datagram.
Parameters numPktsthe 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_IndOverview HDL Receive Indication: issued by HDL when HDL has a successfully-received datagram to give to the local user process.
Parameters datagramdatagram 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_ConfOverview 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_ReqOverview 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_IndOverview 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.

TABLE C-XLIV. Data packet format.
Field name
Size (bits)
Values
Description
Payload1864 (fixed) anyContains 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 Number17 (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.

TABLE C-XLV. Sequence number field definition.
Case
bit 16

(EOM)
bit 15

(SOM)
bits 14-9
bits 8 - 0
only packet in datagram
1
1
0
Payload field byte count: the number of bytes (octets) of datagram data present in the Payload field of the packet.
last packet in datagram
1
0
0
Payload field byte count (see above)
first packet in datagram
0
1
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
0
0
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).

C.5.4.4.2 HDL_ACK.

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.

TABLE C-XLVI. HDL_ACK PDU format.
Field name
Size

(bits)
Values
Description
Protocol3 0002 = HDL identifies this PDU as an HDL PDU
Type1 02 = ACK Identifies this PDU as an HDL_ACK PDU
Ack Bit-Mask24 anyContains 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).
Reserved4 00002 (fixed) Reserved for future use.
CRC16 any16-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.

C.5.4.4.3 HDL_EOM.

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.

TABLE C-XLVII. HDL_EOM PDU.
Field name
size

(bits)
Values
Description
Protocol3 0002 = HDL identifies this PDU as an HDL PDU
Type1 12 = EOM Identifies this PDU as an HDL_EOM PDU.
Check44 0xA5A5A5A5A5AUnused, but should be inspected by the recipient to verify that it contains the correct bit-pattern specified here.

The fields of the HDL_EOM PDU are transmitted in the order of their occurrence in table
C-XLVII, protocol field first. The bits of the Check field are transmitted following the single bit of the Type field in order of significance, most significant bit first, so that the first four bits transmitted from the Check field are 1, 0, 1, 0.

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.

C.5.4.5 Protocol behavior.

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.

FIGURE C-33. HDL data transfer overview.

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.

FIGURE C-34. HDL link termination scenario overview.

The definition of HDL behavior presented in the following sections includes mechanisms for dealing appropriately with the following occurrences:

C.5.4.5.1 Events.

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.

TABLE C-XLVIII. HDL events.
Event name
Description
R:HDL_DATA PDUA BW2_Receive primitive containing an HDL_DATA PDU was accepted.
R:HDL_ACK PDUA 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 PDUA 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_ReqAn HDL_Send_Req primitive was accepted from the user process.
D:HDL_Abort_ReqAn HDL_Abort_Req primitive was accepted from the user process.
AckTimeoutA valid HDL_ACK PDU was not received within the time period in which it was expected.
DataTimeoutAn HDL_DATA PDU was not received within the time period in which it was expected.

C.5.4.5.2 Actions.

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.

C.5.4.5.3 Data.

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.

TABLE C-IL. HDL actions.
Action name
Description
TxInitSet 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_DATAFor 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:
  1. Get the next data segment (the next 233 consecutive data bytes to be transmitted) from TxDatagramBuf; place these in the Payload field of the data packet. If fewer than 233 data bytes remain to be transmitted, place these bytes at the beginning of the Payload field; fill the remainder of the field with zero bytes.
  2. Construct a sequence number value as specified in table C-XLV; write this value into the packet's Sequence Number field.

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.

ProcessAckCheck the HDL_ACK PDU's CRC. If the CRC is valid:
  1. Copy the Ack Bit-Mask field value to RxAck.
  2. For each i, 0 < i < (NumPktsTx - 1), if RxAck[i] is 1, clear the ith position of TxFrameBuf.
  3. If TxDatagramBuf is not empty, set the condition MoreToSend to TRUE; otherwise set it to FALSE.
S:HDL_EOMSend 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:
  • if NumPktsTx = 3, the HDL_EOM PDU is transmitted once
  • if NumPktsTx = 6, the HDL_EOM PDU is transmitted once
  • if NumPktsTx = 12, the HDL_EOM PDU is transmitted three times
  • if NumPktsTx = 24, the HDL_EOM PDU is transmitted seven times.

Disable AckTimeout timer.

U:HDL_Send_ConfIssue an HDL_Send_Conf primitive to the user process that requested the outgoing data transfer.
AbortTransmitDisable AckTimeout timer; reset MissedAckCount to zero.
RxInitSet 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.

TABLE C-IL. HDL actions (continued).
Action name
Description
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,

  1. Insert a data packet containing the Payload and Sequence Number field values from the indexed packet into RxFrameBuf[i], where i = the Index value from the indexed packet (the packet's position in the transmitted HDL_DATA PDU).
  2. Set TxAck[i] to 1.
  3. Move the Payload field contents of RxFrameBuf[i] to the position in RxDatagramBuf indicated by the Sequence Number field-value.
  4. If all packets for the current datagram have been received without errors, set CompleteDatagramRcvd to TRUE.

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_IndIssue an HDL_Rcv_Ind primitive containing the received datagram to the user process.
AbortReceiveDisable DataTimeout timer; reset MissedTxFrameCount to zero.

TABLE C-L. HDL data items.
Data item
Description
NumPktsTxthe number of data packets in each tx frame, as negotiated during the Traffic Set-Up (TSU) phase.
TxDatagramBufbuffer storing the data contents of an outgoing datagram which have not yet been inserted into a tx frame for transmission.
TxFrameBufbuffer storing the sequence of NumPkts data packets contained in an outgoing tx frame (an HDL_DATA PDU).
NumPktsRxthe maximum number of data packets in each incoming rx frame, as negotiated during the Traffic Set-Up (TSU) phase.
RxDatagramBufbuffer 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.
RxFrameBufbuffer 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).
TxAckack 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.
RxAckack 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.
MissedAckCountcount 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.
AckTimeouttimer used to time the duration of the interval in which receipt of an HDL_ACK PDU is expected; fires when the interval expires.
DataTimeouttimer 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_ACKSHDL 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.
MoreToSendBoolean 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.

C.5.4.5.4 Behavior definition.

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.

FIGURE C-35. HDL state diagram.

TABLE C-LI. HDL state transition table.
State
Event
Condition
Action
Next State
IdleD:HDL_Send_Req TxInit + S:HDL_DATA Send
D:HDL_Rcv_Req RxInit Receive
other none Idle
SendR:HDL_ACK MoreToSendProcessAck + S:HDL_DATA Send
R:HDL_ACK NOT MoreToSendProcessAck + S:HDL_EOM + U:HDL_Send_Conf Idle
AckTimeout MissedAckCount < MAX_MISSED_ACKS S:HDL_DATASend
AckTimeout MissedAckCount == MAX_MISSED_ACKS AbortTransmit + U:HDL_Failure_Ind Idle
D:HDL_Abort_Req AbortTransmit Idle
other none Send
ReceiveR: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

C.5.4.5.5 Timing characteristics.

See C.5.3.5.5, which includes an analysis of the timing of the HDL protocol in conjunction with TM protocol timing.

C.5.5 LDL protocol .

C.5.5.1 Overview.

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.

C.5.5.2 Data object types.

The terms defined in table C-LII are used to refer to specific types of data objects in defining the LDL protocol.

TABLE C-LII. LDL data object types.
Data object type
Definition
datagraman 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 segmenta sequence of 8-bit data bytes (octets) that occur consecutively within a datagram, of length sl where 1 < sl < 512.
filled segmenta 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 numbera 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 fieldan 8-bit data object reserved for future use.
data packetthe 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 framea single data packet. Same as an LDL_DATA PDU as defined in table C-LIV.
rx framea single data packet that was received without errors, as determined by the CRC check performed by the BW3 receiver.

C.5.5.3 Service primitives.

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.

TABLE C-LIII. LDL service primitives.
Name
Attribute
Values
Description
LDL_Send_ReqOverview 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 datagramdatagram 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_ReqOverview LDL Receive Request: generated by the user process to request that LDL perform the processing required to receive an expected incoming datagram.
Parameters pktLengththe 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_IndOverview LDL Receive Indication: issued by LDL when LDL has a successfully-received datagram to give to the local user process.
Parameters datagramdatagram 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_ConfOverview 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.

TABLE C-LIII. LDL service primitives (continued).
Name
Attribute
Values
Description
LDL_Abort_ReqOverview 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_IndOverview 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.

C.5.5.4 PDUs.

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.

C.5.5.4.1 LDL_DATA.

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.

TABLE C-LIV. Data packet format.
Field name
Size (bits)
Values
Description
Payload512, 1024, 2048, or 4096 (fixed for each datagram transfer) anyContains 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 Number17 (fixed) As defined by table C-LXV.
Control8 (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.

TABLE C-LV. Sequence number field definition.
Case
Bit 16

(EOM)
Bit 15

(SOM)
Bits

14 - 10
Bits 9 - 0
only packet in datagram
1
1
0
Payload field byte count: the number of bytes (octets) of datagram data present in the Payload field of the packet.
last packet in datagram
1
0
0
Payload field byte count (see above)
first packet in datagram
0
1
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
0
0
down-counting packet sequence number: the number of packets in the current datagram, following the current packet.

C.5.5.4.2 LDL_ACK.

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.

TABLE C-LVI. LDL_ACK PDU format.
Field name
Size (bits)
Values
Description
Ack Bit1 anyContains 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 1any 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.

C.5.5.4.3 LDL_EOM.

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.

TABLE C-LVII. LDL_EOM PDU format.
Field name
Size (bits)
Values
Description
Unused1 1 (fixed)Must be set to 1.
EOM1 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.

C.5.5.5 Protocol behavior.

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.

FIGURE C-36. LDL data transfer overview.

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.

FIGURE C-37. LDL link termination scenario overview.

The definition of LDL behavior presented in the following sections includes mechanisms for dealing appropriately with the following occurrences:

C.5.5.5.1 Events.

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.

C.5.5.5.2 Actions.

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.

TABLE C-LVIII. LDL events.
Event name
Description
R:LDL_DATA PDUA BW3_Receive primitive containing an LDL_DATA PDU was accepted.
R:LDL_ACK PDUA BW4_Receive primitive containing an LDL_ACK PDU was accepted.
R:LDL_EOM PDUA 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_ReqAn LDL_Send_Req primitive was accepted from the user process.
D:LDL_Abort_ReqAn LDL_Abort_Req primitive was accepted from the user process.
U:BW1_Pre_DetectA 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.
AckTimeoutA valid LDL_ACK PDU was not received within the time period in which it was expected.
DataTimeoutAn LDL_DATA PDU was not received within the time period in which it was expected.

TABLE C-LIX. LDL actions.
Action name
Description
TxInitInsert 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_DATAIf the TxFrameBuf is clear, construct a new outgoing data packet (as described by table C-LIV) in the following manner:
  1. Get the next data segment (the next PacketLength consecutive data bytes to be transmitted) from TxDatagramBuf; place these in the Payload field of the data packet. If fewer than PacketLength data bytes remain to be transmitted, place these bytes at the beginning of the Payload field; fill the remainder of the field with zero-valued bytes so that the Payload field contains a filled segment.
  2. Construct a sequence number value as specified in table C-LV; write this value into the packet's Sequence Number field.
  3. Construct a control field with all 8 bits set to zero.
  4. Place the data packet generated in steps 1-3 into the TxFrameBuf.

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.

ProcessAckCopy 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_EOMSend 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:
  • if PacketLength = 64, the LDL_EOM PDU is transmitted once
  • if PacketLength = 128, the LDL_EOM PDU is transmitted three times
  • if PacketLength = 256, the LDL_EOM PDU is transmitted five times
  • if PacketLength = 512, the LDL_EOM PDU is transmitted eleven times.

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_ConfIssue an LDL_Send_Conf primitive to the user process that requested the outgoing data transfer.
AbortTransmitDisable AckTimeout timer; reset MissedAckCount to zero.
RxInitClear 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.

TABLE C-LIX. LDL actions (continued).
Action name
Description
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.

C.5.5.5.3 Data.

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.

C.5.5.5.4 Behavior definition.

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.

TABLE C-LX. LDL data items.
Data item
Description
TxDatagramBufbuffer storing the data contents of an outgoing datagram which have not yet been inserted into a tx frame for transmission.
TxFrameBufbuffer storing the outgoing tx frame (an LDL_DATA PDU).
RxDatagramBufbuffer 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.
RxFrameBufbuffer storing the most recent rx frame that was received without errors (as determined by the CRC check performed by the BW3 receiver).
TxAckack 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.
RxAckack 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.
MissedAckCountcount 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.
AckTimeouttimer used to time the duration of the interval in which receipt of an LDL_ACK PDU is expected; fires when the interval expires.
DataTimeouttimer 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_ACKSLDL 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.
MoreToSendBoolean 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.
PacketLengthnumber 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,

FIGURE C-38. LDL state diagram.

Where a transition is labeled with two or more events, this indicates that the transition occurs whenever any of the events occurs.

TABLE C-LXI. LDL state transition table.
State
Event
Condition
Action
Next State
IdleD:LDL_Send_Req TxInit + S:LDL_DATA Send
D:LDL_Rcv_Req RxInit Receive
other none Idle
SendR:LDL_ACK MoreToSendProcessAck + S:LDL_DATA Send
R:LDL_ACK NOT MoreToSendProcessAck + S:LDL_EOM + U:LDL_Send_Conf Idle
U:BW1_Pre_Detect Skip LDL_Data slot Send
AckTimeout MissedAckCount < MAX_MISSED_ACKS S:LDL_DATASend
AckTimeout MissedAckCount == MAX_MISSED_ACKS AbortTransmit + U:LDL_Failure_Ind Idle
D:LDL_Abort_Req AbortTransmit Idle
other none Send
ReceiveR: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

C.5.5.5.5 Timing characteristics.

See C.5.3.5.5, which includes an analysis of the timing of the LDL protocol in conjunction with TM protocol timing.

C.5.6 CLC.

C.5.6.1 Overview.

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.

C.5.6.2 Service primitives.

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.

TABLE C-LXII. CLC service primitives.
Name
Attribute
Values
Description
CLC_Active_ReqOverview 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 priopriority level of waiting outgoing traffic (if any); value is one of
  • P2P: a point-to-point circuit link is being established, which is treated as a special case by CLC: the backoff delay depends on which station has just transmitted, rather than on traffic priority
  • TM: TM is waiting to send a TM-PDU
  • HIGHEST: highest priority level for user traffic
  • HIGH
  • ROUTINE
  • LOW: lowest priority level for user traffic; also serves as default value when no outgoing traffic is pending.
Originator user process
Preconditions CLC is Idle; a circuit link was just established by the Traffic Manager.
CLC_Idle_ReqOverview 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.

TABLE C-LXII. CLC service primitives (continued).
Name
Attribute
Values
Description
CLC_Set_PriorityOverview 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 priopriority level of waiting outgoing traffic (if any); value is one of
  • P2P: a point-to-point circuit link is being established, which is treated as a special case by CLC: the backoff delay depends on which station has just transmitted, rather than on traffic priority
  • TM: TM is waiting to send a TM-PDU
  • HIGHEST: highest priority level for user traffic
  • HIGH
  • ROUTINE
  • LOW: lowest priority level for user traffic; also serves as default value when no outgoing traffic is pending.
Originator user process
Preconditions none: can be accepted by CLC in any state.
CLC_Idle_IndOverview 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_IndOverview 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
  • newly-activated: i.e., the most recent service primitive passed between CLC and the user process was a CLC_Active_Req primitive; or
  • indicating that the traffic link is available: i.e., the most recent service primitive passed between CLC and the user process was a CLC_Avail_Ind primitive.
CLC_Avail_IndOverview 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.

C.5.6.3 PDUs.

The CLC does not exchange PDUs with a remote peer entity.

C.5.6.4 Protocol behavior.

The following paragraphs define the behavior of the CLC:

C.5.6.4.1 Events.

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.

C.5.6.4.2 Actions.

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.

TABLE C-LXIII. CLC events.
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_ReqCLC_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.
ModemRTSsignal indicating that the local station's modem is starting to modulate data to be transmitted the current circuit link.
AudioRTSsignal indicating presence of an outgoing audio signal to be transmitted on the current circuit link, such as a handset keyline assertion.
ModemEOTxsignal indicating that a transmission of modem data by the local station has been completed.
AudioEOTxsignal indicating that transmission of an outgoing audio signal has ended due to, for instance, de-assertion of the handset keyline.
ModemDetectsignal 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:
  • CW signalling
  • frequency shift keying (FSK) signalling.
AudioDetectsignal 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.
ModemEORxsignal indicating that the local station's modem has detected the MIL-STD-188-110 serial tone End-Of-Message (EOM) sequence.
ModemSigLosssignal 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.
AudioSigLosssignal indicating that the local station has determined that an incoming audio signal on the circuit link has ceased to be present.
TrafficTimeouttimeout 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
BackoffTimeouttimeout event generated by BackoffTimer when the backoff interval following the most recent detected incoming or outgoing traffic transmission has expired.
ReacqTimeouttimeout 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.

TABLE C-LXIV. CLC actions.
Action name
Description
SetPrioritySet TrafficPriority to the value of the prio parameter of a CLC_Active_Req or CLC_Set_Priority service primitive.
StartTrafficTimerSet TrafficTimer to TRAFFIC_TIMEOUT_INTVL.
StopTrafficTimerDisable TrafficTimer.
StartBackoffTimerSet BackoffTimer to BACKOFF_TIMEOUT_INTVL.
StopBackoffTimerDisable BackoffTimer.
StartReacqTimerSet ReacqTimer to REACQ_TIMEOUT_INTVL.
StopReacqTimerDisable ReacqTimer.
U:CLC_Idle_IndIssue a CLC_Idle_Ind service primitive to the user process.
U:CLC_Avail_IndIssue a CLC_Avail_Ind service primitive to the user process.
U:CLC_Busy_IndIssue a CLC_Busy_Ind service primitive to the user process.

C.5.6.4.3 Data.

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.

TABLE C-LXV. CLC data items.
Data item
Description
BackoffTimerdown-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.
ReacqTimerdown-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.
TrafficTimerdown-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.
TrafficPrioritythe 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.

TABLE C-LXVI. Backoff interval duration probabilities.
Priority
0 ms
250 ms
450 ms
650 ms
850 ms
P2P (after transmit or on start of link if not initiator)
100%
P2P (after receive or on start of link if initiator)
100%
TM
50%
50%
HIGHEST
50%
50%
HIGH
50%
50%
ROUTINE
50%
50%
LOW
50%
50%

The backoff scheme using these interval durations is intended to accomplish the following:

C.5.6.4.4 Behavior definition.

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.

FIGURE C-39. CLC state diagram.

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.

C.5.7 Examples.

Figure C-40 through figure C-45 illustrate the operation of the protocols described in this appendix.

FIGURE C-40. ALE/TSU scenarios: packet and point-to-point circuit links.

FIGURE C-41. ALE/TSU scenario: multicast circuit links.

FIGURE C-42. Packet traffic link termination scenarios.

FIGURE C-43. Two-way packet link scenarios.

FIGURE C-44. Link termination scenarios: multicast circuit links.

FIGURE C-45. Packet linking and traffic exchange: on-air signalling overview.