0% found this document useful (0 votes)

548 views562 pages

Mil STD 188 220D - CHG - Notice 1

This document provides standards for digital message transfer devices (DMTDs) within the Department of Defense. It specifies requirements for the physical layer and data link layer protocols to enable interoperability of command, control, communications and intelligence systems over combat net radio networks. The standard defines the physical layer protocol data unit structure, including fields for communications security, transmission synchronization, and bit synchronization. It also specifies the requirements for the data link layer transmission header and network access control. The purpose is to mandate system standards for planning, engineering and using DMTDs to pass digital data over battlefield radio networks.

Uploaded by

japaoli

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

548 views562 pages

Mil STD 188 220D - CHG - Notice 1

Uploaded by

japaoli

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 562

Downloaded from http://www.everyspec.

com

NOT MEASUREMENT
SENSITIVE
MIL-STD-188-220D
w/CHANGE 1
23 June 2008
SUPERSEDING
MIL-STD-188-220D
29 September 2005

DEPARTMENT OF DEFENSE
INTERFACE STANDARD

DIGITAL MESSAGE TRANSFER DEVICE

SUBSYSTEMS

AMSC N/A AREA TCSS

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited

Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

FOREWORD

This military standard (MIL-STD) is approved for use by all Departments and Agencies of the
Department of Defense (DoD). It applies to all inter- and intra-Department of Defense (DoD)
Digital Message Transfer Devices (DMTDs) and Command, Control, Communications,
Computers and Intelligence (C4I) systems that exchange information with DMTDs.

This standard contains technical parameters for the data communications protocols that support
DMTD interoperability. It provides mandatory system standards for planning, engineering,
procuring, and using DMTDs in tactical digital communications systems. This standard
specifies the lower layer (Physical through Intranet) protocol for interoperability of C4I systems
over combat net radio (CNR) on the battlefield. This standard provides the information required
to pass digital data via CNR on the battlefield.

The Preparing Activity (PA) for this standard is USA CECOM LCMC, ATTN: AMSEL-SE-CD
(Chairman, CNRWG), Fort Monmouth, NJ 07703. The custodians for the document are
identified in the Defense Standardization Program, “Standardization Directory (SD1)” under
Standardization Area Telecommunications Systems Standards (TCSS).

Beneficial comments (recommendations, additions, deletions) and any pertinent data that may be
of use in improving this MIL-STD should be addressed to the PA at the above address by letter.

Comments, suggestions, or questions on this document should be addressed to CDR, USA

CECOM LCMC, ATTN: AMSEL-SE-CD (Chairman, CNRWG), Building 1209, Fort
Monmouth, NJ 07703 or emailed to [email protected]. Since contact information can
change, you may want to verify the currency of this address information using the ASSIST
Online database at http://assist.daps.dla.mil.

ii
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

CONTENTS

PARAGRAPH PAGE

FOREWORD .................................................................................................................... .ii

1 SCOPE .................................................................................................................................1
1.1 Purpose. .....................................................................................................................1
1.2 Scope. ........................................................................................................................1
1.3 Application guidance.................................................................................................1
1.4 Version interoperability.............................................................................................1
1.5 Clarification of examples. .........................................................................................1

2 APPLICABLE DOCUMENTS ...........................................................................................2

2.1 General. .....................................................................................................................2
2.2 Government documents.............................................................................................2
2.2.1 Specifications, standards, and handbooks. ................................................................2
2.2.2 Other Government documents, drawings, and publications......................................2
2.3 Non-Government publications. .................................................................................3
2.3.1 International Organization for Standardization (ISO)...............................................3
2.3.2 International Telecommunications Union (ITU).......................................................3
2.3.3 Internet Engineering Task Force (IETF) standards...................................................3
2.3.4 Other..........................................................................................................................4
2.4 Order of precedence. .................................................................................................4

3 DEFINITIONS.....................................................................................................................5
3.1 Definitions of terms...................................................................................................5
3.2 Abbreviations and acronyms. ....................................................................................8

4 GENERAL REQUIREMENTS .........................................................................................14

4.1 Digital message transfer device (DTMD). ..............................................................14
4.2 Interoperability. .......................................................................................................14
4.3 Framework...............................................................................................................15
4.4 DMTD capabilities. .................................................................................................16
4.5 System standards and design...................................................................................17

5 DETAILED REQUIREMENTS ........................................................................................18

5.1 Physical layer. .........................................................................................................18
5.1.1 Transmission channel interfaces. ............................................................................18
5.2 Physical-layer protocol............................................................................................18
5.2.1 Physical-layer Protocol Data Unit (PDU). ..............................................................18
5.2.1.1 Communications security preamble and postamble................................................19
5.2.1.2 Phasing. .................................................................................................................19
5.2.1.3 Transmission synchronization field.........................................................................19
5.2.1.4 Data field. ................................................................................................................24

iii
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

CONTENTS

PARAGRAPH PAGE

5.2.1.5 Bit synchronization field. ........................................................................................25

5.2.2 Network Access Control (NAC) related indications...............................................25
5.2.3 Physical-layer to upper-layer interactions...............................................................25
5.3 Data Link layer........................................................................................................27
5.3.1 Transmission Header...............................................................................................27
5.3.1.1 Selection bits. ..........................................................................................................27
5.3.1.2 MIL-STD-188-220 Version. ...................................................................................28
5.3.1.3 Transmission Queue field........................................................................................28
5.3.2 Network access control. ..........................................................................................30
5.3.2.1 Scheduler. ................................................................................................................31
5.3.3 Types of operation...................................................................................................31
5.3.3.1 Type 1 operation......................................................................................................31
5.3.3.2 Type 2 operation......................................................................................................31
5.3.3.3 Type 3 operation......................................................................................................32
5.3.3.4 Type 4 operation......................................................................................................32
5.3.3.5 Station class.............................................................................................................32
5.3.4 Data Link frame.......................................................................................................32
5.3.4.1 Types of frames. ......................................................................................................32
5.3.4.2 Data Link frame structure........................................................................................32
5.3.4.3 Data Link PDU construction. ..................................................................................50
5.3.5 Operational parameters............................................................................................51
5.3.5.1 Type 1 operational parameters. ...............................................................................51
5.3.5.2 Type 2 operational parameters. ...............................................................................51
5.3.5.3 Type 3 operational parameters. ...............................................................................53
5.3.5.4 Type 4 operational parameters. ...............................................................................54
5.3.6 Commands and responses. ......................................................................................54
5.3.6.1 Type 1 operation commands and indications. .........................................................55
5.3.6.2 Type 2 operation commands and responses. ...........................................................56
5.3.6.3 Type 3 operation commands and responses. ...........................................................62
5.3.6.4 Type 4 operation commands and responses. ...........................................................63
5.3.7 Description of procedures by type...........................................................................65
5.3.7.1 Description of Type 1 procedures. ..........................................................................65
5.3.7.2 Description of Type 2 procedures. ..........................................................................67
5.3.7.3 Description of Type 3 procedures. ..........................................................................77
5.3.7.4 Description of Type 4 procedures. ..........................................................................79
5.3.8 Data Link initialization............................................................................................81
5.3.8.1 List of Data Link parameters...................................................................................82
5.3.9 Frame transfer..........................................................................................................85
5.3.9.1 PDU transmission....................................................................................................85
5.3.9.2 Data Link concatenation..........................................................................................86
5.3.9.3 Physical Layer (PL) concatenation. ........................................................................86

iv
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

CONTENTS

PARAGRAPH PAGE

5.3.9.4 PDU transmissions. .................................................................................................88

5.3.10 Flow control. ...........................................................................................................88
5.3.10.1 Type 1 flow control. ................................................................................................88
5.3.10.2 Type 2 flow control. ................................................................................................88
5.3.10.3 Type 3 flow control. ................................................................................................88
5.3.10.4 Type 4 flow control. ................................................................................................88
5.3.11 Acknowledgment and response...............................................................................89
5.3.11.1 Acknowledgment.....................................................................................................89
5.3.11.2 Quiet Mode..............................................................................................................89
5.3.11.3 Immediate retransmission........................................................................................90
5.3.12 Invalid frame. ..........................................................................................................90
5.3.13 Retransmission. .......................................................................................................90
5.3.14 Error Detection and Correction (EDC). ..................................................................91
5.3.14.1 Forward-Error-Correction (FEC) coding. ...............................................................91
5.3.14.2 Forward-Error-Correction preprocessing................................................................91
5.3.14.3 Time-Dispersive Coding (TDC)..............................................................................91
5.3.15 Data scrambling.......................................................................................................93
5.3.16 Data Link Layer interactions...................................................................................96
5.4 Network Layer.......................................................................................................100
5.4.1 Intranet Protocol. ...................................................................................................100
5.4.1.1 Intranet Header. .....................................................................................................100
5.4.1.2 Topology Update...................................................................................................110
5.4.1.3 Topology Update Request message. .....................................................................113
5.4.1.4 Forwarding of group multicast packets. ................................................................113
5.4.1.5 Intranet Layer (IL) interactions. ............................................................................116
5.4.2 Subnetwork Dependent Convergence Function (SNDCF). ..................................119
5.4.2.1 Determine Destination function. ...........................................................................120
5.4.2.2 Address Mapping function. ...................................................................................120
5.4.2.3 Type of Service function. ......................................................................................121
5.4.2.4 Intranet send request..............................................................................................121
5.4.3 Implementation directions.....................................................................................121
5.5 Lower layer protocol network settings..................................................................121
5.5.1 Reason for table.....................................................................................................121
5.5.2 Table description. ..................................................................................................122
5.5.2.1 Table map. .............................................................................................................122
5.5.3 Table use................................................................................................................123
5.5.4 Changing from OPS parameters............................................................................123
5.5.5 Custom OPS. .........................................................................................................123
5.5.6 Requirements prior to new OPS code insertions...................................................123
5.5.6.1 Values. ...............................................................................................................125

v
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

CONTENTS

PARAGRAPH PAGE

6 NOTES.............................................................................................................................133
6.1 Subject term (key word) listing. ............................................................................133
6.2 Issue of the DoD index of specifications and standards........................................133
6.3 Interoperability considerations..............................................................................133
6.3.1 Transmission channel. ...........................................................................................134
6.3.2 Physical interface. .................................................................................................134
6.3.2.1 SINCGARS System Improvement Program (SIP) Receiver/Transmitter (R/T)
interface. ...............................................................................................................134
6.3.2.2 SINCGARS Integrated COMSEC (ICOM) R/T interface. ...................................136
6.3.2.3 HAVEQUICK II R/T interface. ............................................................................137
6.3.2.4 COMSEC interoperability.....................................................................................137
6.3.3 Data Link Layer.....................................................................................................138
6.3.3.1 Frequency of Access Ranking (FOAR).................................................................138
6.3.3.2 Generation of unique six octet Data Link Layer address for IPv6........................139
6.3.4 Intranet Layer. .......................................................................................................140
6.3.4.1 Allocation of memory required for reassembly. ...................................................142
6.3.4.2 Deallocation of memory used for reassembly. ......................................................142
6.3.5 CNR Management process using XNP. ................................................................142
6.3.6 Interoperation with Internet Protocols...................................................................142
6.4 Changes from previous issue.................................................................................143

APPENDIX A ABBREVIATIONS AND ACRONYMS ...............................................144

A.1 General. .................................................................................................................144
A.1.1 Scope. ....................................................................................................................144

APPENDIX B DOD STANDARDIZED PROFILE IMPLEMENTATION

CONFORMANCE STATEMENTS (DSPICS) REQUIREMENTS LIST (DPRL)........145
B.1 General. .................................................................................................................145
B.1.1 Scope. ....................................................................................................................146
B.1.2 Application. ...........................................................................................................146
B.2 Applicable documents. ..........................................................................................147
B.3 Notation. ................................................................................................................147
B.4 Implementation requirements................................................................................148
B.5 Detailed requirements............................................................................................148

TABLE I. Robust frame format. ..............................................................................22

TABLE II. Multi-dwell transmission format. ...........................................................22
TABLE III. Convolutional coding constraint length codes........................................23
TABLE IV. Type 1 PDU formats. ..............................................................................40
TABLE V. Type 2 PDU formats. ..............................................................................42
TABLE VI. Type 3 PDU Formats. .............................................................................44
TABLE VII. Type 4 PDU formats. ..............................................................................45
TABLE VIII, Intranet sublayer to Data Link Layer precedence mapping....................98
TABLE IX. Mapping intranet TOS field to data link TOS. .....................................100
TABLE X. Intranet message types. .........................................................................104
TABLE XI. Relay Types. .........................................................................................108
TABLE XII. Topology Link Quality values. .............................................................112
TABLE XIII. Hop Length values. ...............................................................................113
TABLE XIV. Standard Network Settings. ..................................................................126
TABLE XV. SINCGARS ICOM receive states.........................................................137

TABLE C-I. Calculation of the Load Factor. ............................................................343

TABLE C-II. Calculation of the Load Factor -- example 1. .......................................345
TABLE C-III. Calculation of the Load Factor -- example 2. .......................................346
TABLE C-IV. FSN Increment Numbers for DAV-NAD .............................................359

TABLE E-I. XNP messages. .....................................................................................378

TABLE E-II. XNP data blocks. ..................................................................................379
TABLE E-III. Terminator block...................................................................................380
TABLE E-IV. Join Request message. ..........................................................................381
TABLE E-V. Blocks included in the Join Request in OPS mode...............................382
TABLE E-VI. Blocks included in the Join Request in Explicit mode .........................382
TABLE E-VII. Join accept message. .............................................................................383
TABLE E-VIII. Blocks Returned in the Join Accept in OPS mode ...............................384

xiv
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

CONTENTS

TABLE PAGE

TABLE E-IX. Blocks Returned in the Join Accept in Explicit Mode..........................384

TABLE E-X. Join reject message. ..............................................................................385
TABLE E-XI. Blocks Returned in the Reject in OPS mode ........................................385
TABLE E-XII. Blocks Returned in the Join Reject in Explicit mode ...........................386
TABLE E-XIII. Hello message. ......................................................................................386
TABLE E-XIV. Goodbye message. ................................................................................387
TABLE E-XV. Parameter update request message. ......................................................388
TABLE E-XVI. Parameter update message. ...................................................................389
TABLE E-XVII Blocks sent in the Parameter Update message in OPS mode ...............390
TABLE E-XVIII Blocks sent in the Parameter Update message in Explicit mode ..........390
TABLE E-XIX. Status notification message...................................................................392
TABLE E-XX Blocks sent in the Status notification message in OPS mode...............392
TABLE E-XXI Blocks sent in the Status notification message in Explicit mode .........393
TABLE E-XXII. NCS Handover Request message..........................................................393
TABLE E-XXIII. NCS Accept/Reject message.................................................................394
TABLE E-XXIV. Optional Services..................................................................................395
TABLE E- XXV. Basic NAD Configuration parameters ..................................................397
TABLE E- XXVI. Type 3 parameters.................................................................................399
TABLE E- XXVII. Number of NAD Priorities...................................................................400
TABLE E- XXVIII. H-NAD parameters. ..............................................................................401
TABLE E-XXIX. RE-NAD parameters.............................................................................402
TABLE E-XXX. Wait time...............................................................................................403
TABLE E-XXXI. Type 2 parameters.................................................................................404
TABLE E-XXXII. Type 4 parameters.................................................................................405
TABLE E-XXXIII. NAD ranking.........................................................................................406
TABLE E-XXXIV. Intranet parameters. ..............................................................................407
TABLE E-XXXV. Error. .....................................................................................................409
TABLE E-XXXVI. Address designation parameters. ..........................................................410
TABLE E-XXXVII. Digital Signature ...................................................................................411
TABLE E-XXXVIII. Link Address Extension........................................................................412
TABLE E-XXXIX. XNP Parameters....................................................................................413
TABLE E-XL. Robust parameters.................................................................................414
TABLE E-XLI. IPv6 Top level/site level address ..........................................................414
TABLE E-XLII. Predefined OPS.....................................................................................416
TABLE E-XLIII. S/R basic ...............................................................................................417
TABLE E-XLIV. XNP Join Request message. .................................................................426
TABLE E-XLV. XNP Join Accept message. ...................................................................428

TABLE G-I. Example of K15.99 VMF message like data construction. ..................445
TABLE G-II. Example construction of the Application Header.................................448
TABLE G-III. Example of a unit name as originator. ..................................................453

xv
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

CONTENTS

TABLE PAGE

TABLE G-IV. Example construction of S/R Data Segment.........................................457

TABLE G-V. Octet representation of S/R header. ......................................................458
TABLE G-VI. Example construction of UDP header...................................................460
TABLE G-VII. Octet representation of UDP header. ....................................................460
TABLE G-VIII. Example construction of IP header. ......................................................463
TABLE G-IX. Example construction of Intranet header (minimum)...........................465
TABLE G-X. Example construction of Data Link frame header. ...............................469
TABLE G-XI. Example construction of Data Link frame trailer. ................................469
TABLE G-XII. Octets comprising Data Link frame......................................................470
TABLE G-XIII. Example construction of Data Link transmission header. ....................474

TABLE H-I. Topology table for node A....................................................................480

TABLE H-II. Sparse routing tree for node A..............................................................481
TABLE H-III. Final routing tree for node A. ...............................................................482

TABLE I-I. Sample node addresses. ........................................................................489

TABLE I-II. Paths used in example 3........................................................................492

TABLE J-I. Convolutional coding generator polynomials (octal). ..........................499

TABLE J-II. Maximum supported BER. ...................................................................505
TABLE J-III. Multi-dwell overhead............................................................................506
TABLE J-IV. Multi-dwell acknowledgment times for Hop_All assumption. ............508
TABLE J-V. Robust Protocol example with multi-dwell flag set..............................514
TABLE J-VI. Robust Protocol example with multi-dwell flag not set. ......................524

TABLE L-I. Characteristic frequencies of FSK interface for

voice frequency channels......................................................................539
TABLE L-II. Characteristic frequencies of FSK interface for single-channel radio..540

FIGURE PAGE

FIGURE 1. Standard interface for DMTD subsystems..............................................14

FIGURE 2. DMTD functional reference model.........................................................15
FIGURE 3. Basic structure of DMTD protocol data units at the standard interface. 16
FIGURE 4. Transmission frame structure..................................................................19
FIGURE 5. Transmission synchronization field. .......................................................20
FIGURE 6. Frame synchronization subfield..............................................................21
FIGURE 7. Robust frame synchronization subfield. .................................................22
FIGURE 8. Packet mode transmission synchronization field....................................24
FIGURE 9. Transmission header. ..............................................................................27
FIGURE 10. MIL-STD-188-220 Version. ...................................................................28

xvi
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

CONTENTS

FIGURE PAGE

FIGURE 11. Transmission queue field formats...........................................................29

FIGURE 12. Data Link frame structure and placement...............................................33
FIGURE 13. Extended address field format. ...............................................................37
FIGURE 14. Address allocation...................................................................................38
FIGURE 15. Data link PDU control field formats.......................................................47
FIGURE 16. Type 1 operation control-field bit assignments. .....................................55
FIGURE 17. Information-transfer-format control field bits. .......................................57
FIGURE 18. Supervisory-format control field bits......................................................58
FIGURE 19. Unnumbered-format control field bits. ...................................................59
FIGURE 20. FRMR information field format..............................................................62
FIGURE 21. Type 3 operation control-field bit assignments. .....................................62
FIGURE 22. Type 4 DIA PDU control field bit assignments......................................64
FIGURE 23. Type 4 S PDU control field bit assignments...........................................65
FIGURE 24. Data Link concatenation. ........................................................................87
FIGURE 25. Physical Layer concatenation. ................................................................87
FIGURE 26. Transmitter’s 16 x 24 matrix before interleaving. ..................................93
FIGURE 27. Transmitter’s 24 x 16 matrix after interleaving. .....................................93
FIGURE 28. Required CCITT V.36 scrambling/descrambling operation...................94
FIGURE 29. Example implementation of CCITT V.36. .............................................95
FIGURE 30. Intranet Header. ....................................................................................102
FIGURE 31. Destination/Relay status byte................................................................108
FIGURE 32. Topology update data structure.............................................................111
FIGURE 33. Node status byte....................................................................................112
FIGURE 34. TABLE XIV map..................................................................................123

FIGURE C-1. Network Timing Model. .......................................................................329

FIGURE C-2. Turnaround Time (TURN) calculation. ................................................332
FIGURE C-3. Example of FSN and NP operation.......................................................350
FIGURE C-4. DAP-NAD example key. ......................................................................352
FIGURE C-5. DAP-NAD example. .............................................................................353
FIGURE C-6. DAV-NAD example key.......................................................................360
FIGURE C-7. DAV-NAD example. ............................................................................361

FIGURE D-1. Traditional COMSEC transmission frame structure.............................367

FIGURE D-2. COMSEC frame synchronization pattern for Phi encoding. ................368
FIGURE D-3. Embedded COMSEC transmission frame structure. ............................370

FIGURE E-1. XNP message format. ...........................................................................375

FIGURE E-2. Example 4-octet XNP data field. ..........................................................376
FIGURE E-3. Forwarding header. ...............................................................................376
FIGURE E-4. Message and Block structure. ...............................................................377

xvii
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

CONTENTS

FIGURE PAGE

FIGURE E-5. UI frame containing XNP message.......................................................417

FIGURE E-6. Joining concept. ....................................................................................420
FIGURE E-7. Joining a network..................................................................................420
FIGURE E-8. Joining a fully connected network. .......................................................420
FIGURE E-9. Joining a disconnected network............................................................420

FIGURE F-1. Shift register encoding for the (23,12) Golay code. .............................435
FIGURE F-2. Kasami error-trapping decoder for the (24,12) Golay code..................436
FIGURE F-3. Generator matrix G. ..............................................................................438
FIGURE F-4. Matrix T. ...............................................................................................439

FIGURE G-1. PDU construction..................................................................................441

FIGURE G-2. VMF message services interaction with other communication layers. 442
FIGURE G-3. Exchange of message data between communication layers. ................443
FIGURE G-4. Serial representation of PDU. ...............................................................445
FIGURE G-5. Application Layer interaction with other communication layers. ........446
FIGURE G-6. Exchange of application layer PDU between communication layers...447
FIGURE G-7. Application Header (octets). .................................................................452
FIGURE G-8. Transport layer interaction with other communication layers. .............454
FIGURE G-9. Exchange of transport layer PDU between communication layers. .....455
FIGURE G-10. S/R Data Segment .................................................................................455
FIGURE G-11. Octet representation of S/R Data Segment. ..........................................456
FIGURE G-12. Serial representation of S/R Data Segment...........................................458
FIGURE G-13. UDP header...........................................................................................458
FIGURE G-14. Octet representation of UDP header. ....................................................459
FIGURE G-15. Serial representation of UDP header. ...................................................460
FIGURE G-16. Network layer interaction with other communication layers................461
FIGURE G-17. Exchange of network layer PDU between communication layers........462
FIGURE G-18. P header.................................................................................................462
FIGURE G-19. Octet representation of IP header..........................................................464
FIGURE G-20. Intranet header. .....................................................................................465
FIGURE G-21. Serial representation of network layer PDU. ........................................466
FIGURE G-22. Data link layer interaction with other communication layers...............467
FIGURE G-23. Exchange of data link layer PDU between communication layers.......468
FIGURE G-24. Data Link Layer PDU. ..........................................................................468
FIGURE G-25. Serial representation of Data Link Layer PDU.....................................472
FIGURE G-26. Data before zero bit insertion in transmission order.............................473
FIGURE G-27. Serial representation of Physical Layer transmission unit....................476

FIGURE H-1. Sample intranet. ....................................................................................478

FIGURE H-2. Link diagram of sample network. .........................................................479

xviii
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

CONTENTS

FIGURE PAGE

FIGURE H-3. Routing tree for nodes A and C. ...........................................................479

FIGURE H-4. Concatenated routing tree for node A...................................................480
FIGURE H-5. Sparse routing tree for node A..............................................................481
FIGURE H-6. Final routing tree for node A. ...............................................................482

FIGURE I-1. Link diagram of a sample network. ......................................................488

FIGURE I-2. Final routing tree for node A. ...............................................................488
FIGURE I-3. Example 1 Intranet Header. ..................................................................490
FIGURE I-4. Example 2 Intranet header. ...................................................................491
FIGURE I-5. Example 3 Intranet Header created by node A (originator)..................494
FIGURE I-6. Example 3 Intranet Header for node C (relay node).............................496
FIGURE I-7. Example 3 Intranet Header created by node F
(relay and destination nodes). ...............................................................497

FIGURE J-1. Convolutional encoder with inverted G2 K=3......................................499

FIGURE J-2. Rate 1/3 convolutional coding performance for constraint
lengths 3, 5, and 7. ................................................................................500
FIGURE J-3. Data scrambler structure. ......................................................................501
FIGURE J-4. Multi-dwell packet................................................................................502
FIGURE J-5. Multi-dwell 64-bit SOP pattern. ...........................................................502
FIGURE J-6. Multi-dwell 32-bit SOP pattern. ...........................................................502
FIGURE J-7. Two transmission examples..................................................................504
FIGURE J-8. HAVEQUICK II external crypto acknowledgment transmission. .......510
FIGURE J-9. Link data rate as a function of message size.........................................511
FIGURE J-10. Robust PDU Construction. ...................................................................526
FIGURE J-11. Robust PDU Construction (Top Part)...................................................527
FIGURE J-12. Robust PDU Construction (Bottom Part). ............................................528

FIGURE K-1. Shift register encoder for the BCH (15,7) code. ...................................530
FIGURE K-2. Encoding example.................................................................................531
FIGURE K-3. Robust Frame format encoding example. .............................................532
FIGURE K-4. BCH (15,7) majority logic decoding. ...................................................534
FIGURE K-5. BCH (15,7) parity check matrix. ..........................................................535
FIGURE K-6. BCH (15,7) generator matrix. ...............................................................535

PARAGRAPH PAGE

CONCLUDING MATERIAL .........................................................................................543

xix
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

1 SCOPE

1.1 Purpose.
This document promulgates the minimum essential technical parameters in the form of
mandatory system standards and optional design objectives for interoperability and compatibility
among DMTDs, and between DMTDs and applicable C4I systems. These technical parameters
are based on the data communications protocol standards specified herein to ensure
interoperability.

1.2 Scope.
This document identifies the procedures, protocols, and parameters to be applied in
specifications for DMTDs and C4I systems that exchange information with DMTDs. This
document addresses the communications protocols and procedures for the exchange of
information among DMTDs, among C4I systems, and between DMTDs and C4I systems
participating in inter- and intra-Service tactical networks.

1.3 Application guidance.

This document applies to the design and development of new equipment and systems, and to the
retrofit of existing equipment and systems.

1.4 Version interoperability.

MIL-STD-188-220D w/CHANGE 1 is backwards compatible with MIL-STD-188-220D
mandatory requirements, except for the version field values. Some optional requirements may
not be fully interoperable. MIL-STD-188-220D is not fully interoperable with MIL-STD-188-
220C, as they can not be used on the same network simultaneously in all cases. This is due to
MIL-STD-188-220D supporting IPv6, Intranet Fragmentation, Six Octets Link Layer
Addressing, the MIL-STD-188-220 Version subfield replacing the Topology Update ID in the
Transmission Information field subfield, as well as some other implementation details. Systems
requiring interoperability between multiple versions of the standard must require their supplier to
implement as a dual stack.

1.5 Clarification of examples.

Throughout this standard, many examples are provided as guidance only. In the event that an
example is inconsistent with the text and DSPICS of the standard, the text description/DSPICS
takes precedence over the example. Should a user detect any inconsistent examples, they should
notify the CNRWG so that the example can be updated for a future release of the standard. It
should also be noted that while all examples should be accurate in relation to the feature they are
explaining, some of the examples provided may not reflect changes made to unrelated sections of
the standard (e.g. examples to illustrate the use of XNP reflect the current version of XNP, but
may not reflect the current version of the Intranet Header).

1
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

2 APPLICABLE DOCUMENTS

2.1 General.
The documents listed in this section are specified in sections 3, 4, and 5 of this standard. This
section does not include documents cited in other sections of this standard or recommended for
additional information 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 sections 3, 4, and 5 of this standard, whether or not they are
listed.

2.2 Government documents.

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 current issue of the DoD Index of Specifications and Standards (DoDISS) and
supplement thereto, cited in the solicitation (see 6.2).

DEPARTMENT OF DEFENSE STANDARDS

FEDERAL

FED-STD-1037 Glossary of Telecommunication Terms

MILITARY

MIL-STD-2045-47001 DoD Interface Standard, Connectionless

Data Transfer -- Application Layer Standard

[Unless otherwise indicated, copies of federal and MIL-STDs are available from the
Standardization Document Order Desk, 700 Robbins Avenue, Building 4D, Philadelphia, PA
19111-5094.] Department of Defense Standards documents are available at the ASSIST website:
http://assist.daps.dla.mil.

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.

JIEO Specification 9120A Technical Interface Specification for UHF

SATURN/HAVEQUICK Waveforms (U)

2
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Standard Change Catalogs (SCCs) and Interface Change Proposals (ICPs) based on this
document, approved or otherwise, shall not be implemented in or by any platform or
system. Approved SCC/ICPs shall be incorporated in the next release of this document.

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 that are DoD- adopted are those listed in the
issue of the DoDISS cited in the solicitation. Unless otherwise specified, the issues of
documents not listed in the DoDISS are the issues of the documents cited in the solicitation (see
6.2).

2.3.1 International Organization for Standardization (ISO).

ISO 3309 Information Processing Systems -- Data Communication -- High-

level Data Link Control Procedures -- Frame Structure

ISO 7498-1 Information Processing Systems -- Open Systems Interconnection -

- Basic Reference Model

ISO 8802-2 Information Processing Systems -- Local Area Networks -- Part 2:

Logical Link Control

[ISO standards are available from the American National Standards Institute, Inc., 25 West 43rd
Street, Fourth Floor, New York, NY 10036.] The ISO website is http://www.iso.org

2.3.2 International Telecommunications Union (ITU).

Formerly known as International Telephone and Telegraph Consultative Committee (CCITT)

CCITT V.33 14,400 Bits Per Second Modem Standardized for Use on Point-to-
Point 4-wire Leased Telephone-Type Circuits.

CCITT V.36 Modems for Synchronous Data Transmission Using 60-108 KHz
Group Band Circuits.

[ITU-T/CCITT standards are available from Omnicom, 115 Park Street, South East, Vienna, VA
22180]

The ITU website is http://www.itu.int

2.3.3 Internet Engineering Task Force (IETF) standards.

RFC 768 User Datagram Protocol (UDP)

RFC 793 Transmission Control Protocol (TCP)

3
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

RFC 826 An Ethernet Address Resolution Protocol (ARP) -- or --

Converting Network Protocol Addresses to 48-bit Ethernet
Addresses for Transmission on Ethernet Hardware

RFC 791 Internet Protocol DARPA Internet Program Protocol Specification

RFC 1770 IPv4 Option for Sender Directed Multi-Destination Delivery

RFC 2328 OSPF Version 2

RFC 2460 Internet Protocol Version 6 (IPv6)

RFC 2461 Neighbor Discovery for IP Version 6 (IPv6)

RFC 2463 Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification

RFC 2474 Definition of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers

RFC 2475 An Architecture for Differentiated Services

RFCs can be obtained at the IETF website: http://www.ietf.org/rfc.html.

2.3.4 Other.
Parameters and parameter values for the data link and the Network Timing Model, described in
APPENDIX C, are provided in a separate document entitled “MIL-STD-188-220 Parameter
Table”. It is important, to insure interoperability, that all systems participating in a network use
the same parameter values. These parameters and values should be utilized by all systems.
Project Managers and implementers should note that the MIL-STD-188-220 Parameter Table is
likely to change more frequently than the parent document. As these values should be used by
all systems, it is advisable that systems are built in such a way that they can be easily updated.
The actual parameter values will determine the efficiency and effectiveness of the network. A
bad choice of parameter values can degrade the network performance and can lead to a
breakdown of the network precluding interoperability. The parameters and parameter values are
available via the CNR Implementation Working Group World Wide Web page:
https://www.us.army.mil/suite/page/495338.
.
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.

4
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

3 DEFINITIONS

3.1 Definitions of terms.

This section defines the terms and definitions used in this military standard.

Acknowledge The act of notifying a unit transmitting data that the data has been
received as a valid data.
Are “Are” is used to introduce background information provided to
enhance understanding of requirements. “Are” is not a directive.
Bit A binary digit. In the binary system of numbering, each digit can only
have one of two values (0 or 1). (Derived from ACP 167E)
Compatibility The capability of two or more items or components of equipment or
materiel to exist or function in the same system or environment
without mutual interference. (Joint Pub 1-02)
Data Element A basic unit (class) of information having a unique meaning and
subcategories (data items) of distinct units or values. Examples of
data elements are military personnel grade, sex, race, geographic
location, and military unit. (Joint Pub 1-02) The VMF data element is
the Data Use Identifier (DUI).
Data Item A subunit of descriptive information or value classified under a data
element. For example, the data element "military personnel grade"
contains data items such as sergeant, captain, and colonel. (Joint Pub
1-02).
Disused A DI value that was previously named but is no longer valid. A
DISUSED value cannot be renamed without determining if
coordinated implementation is required.
Illegal A term used to describe a bit code that is not a permissible entry into
the tactical data system(s) supporting interface. (For example, a 9-bit
DUI called HEADING that has legal values of 0-359 that represents
degrees has illegal values of 360-511.)
No A data item that indicates that no information on this DUI is being
Statement transmitted. (This does not necessarily indicate that the originator
does not have the information.) The procedure to transmit a no
statement value is to set the presence indicator to zero. Receipt of a
presence indicator set to zero shall be interpreted as no statement.
Reserved A data item that indicates it cannot be used because it is intended for a
planned future use.
To Be This indicates that the data item design is incomplete. (DI names and
Determined bit codes will be specified at a later time.)
Undefined A term used to describe a bit code that has no currently assigned value
but may have a value assigned in the future. (This occurs in logically
coded items in which all the DIs in the field do not have assigned
values.)

5
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Unknown A data item that indicates that other values available for this field have
not been determined by the originator.
Data Link The means of connecting one location to another for the purpose of
transmitting and receiving data. (Joint Pub 1-02)
Default Condition The state automatically assumed by a terminal's hardware or software
in the absence of an input directing otherwise.
Digital Message Transfer A portable data terminal device with limited message generation and
Device (DMTD) processing capability. DMTDs are used for remote access to
automated C4I systems and to other DMTDs. The environment
encompasses point-to-point, point-to-multipoint, relay and broadcast
transfer of information over data communications links. (MIL-STD-
188-220)
Directive (1) A military communication in which policy is established or a
specific action is ordered. (Joint Pub 1-02)
(2) A plan issued with a view to putting it in effect when so directed,
or in the event that a stated contingency arises. (Joint Pub 1-02)
(3) Broadly speaking, any communication that initiates or governs
action, conduct, or procedure. (Joint Pub 1-02)
Global Multicast Global multicast addressing, used when broadcasting messages to all
systems on a broadcast subnetwork.
Group Multicast Group multicast addressing, used when broadcasting messages to
multiple (but not all) stations on a broadcast subnetwork.
Interoperability (1) The ability of systems, units or forces to provide services to and
accept services from other systems, units or forces and to use the
services so exchanged to enable them to operate effectively together.
(Joint Pub 1-02)
(2) The condition achieved among communications-electronics
systems or items of communications-electronics equipment when
information or services can be exchanged directly and satisfactorily
between them and/or their users. The degree of interoperability should
be defined when referring to specific cases. (Joint Pub 1-02)
(3) The ability to exchange data in a prescribed manner and the
processing of such data to extract intelligible information which can be
used to control/coordinate operations.
Is “Is” is used to introduce background information provided to enhance
understanding of requirements. “Is” is not a directive.
Joint Connotes activities, operations, organization, etc., in which elements
of more than one Service of the same nation participate. (Joint Pub 1-
02)
Link 16 A secure, jam-resistant, nodeless data link which utilizes the Joint
Tactical Information Distribution System, and the protocols,
conventions and fixed word message formats defined by the MIL-
STD-6016.

6
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Mandatory Field A field which shall contain data with each transmission of the
message.
May The word “may” in the text expresses a permissible practice or action,
not a mandatory requirement.
Message Any thought or idea expressed briefly in a plain, coded, or secret
language, prepared in a form suitable for transmission by any means of
communications. (Joint Pub 1-02)
Message Standard A set of protocols consisting of rules, procedures, formats, data
element definitions, or other conventions for information exchange
and related interactions agreed upon between cooperating systems to
ensure interoperability.
Minimum The statement of minimum data exchange requirements that must be
Implementation implemented by Service/Agency systems participating on a Variable
Message Format (VMF) Interface to ensure the continued flow of
information.
Multicast Multicast is the delivery of information to a group of destinations
simultaneously using the most efficient strategy to deliver the
messages over each link of the network only once, creating copies
only when the links to the destinations split.
Must The word “must” in the text is used in legislative or regulatory
requirements with which both the customer and the vendor shall
comply.
Network In information technology, a network is a series of points or nodes
interconnected by communication paths. Networks can interconnect
with other networks and contain subnetworks.
Operator “Operator” is the person entering and receiving tactical information
within a TDS, as appropriate to the capability to which a particular
requirement applies. No attempt is made to specify the operator
position or title expected to carry out specified actions or use specified
capabilities, because these vary among systems and platforms.
Optional Field A field which is not designated as a mandatory field. An optional field
shall be preceded by an FPI or be nested within a group which
includes a GPI.
Receipt/Compliance The acknowledgment of a message and/or an indication of intent to
respond to a message, either by machine acknowledgment or operator
action.
Shall “Shall” is directive, indicating a mandatory capability or requirement
that must be implemented, and that is testable.
Should The word “should” in the text expresses a recommendation or advice
on implementing such a requirement, not a mandatory requirement.
Subnetwork A subnetwork is a separately identifiable part of a larger network that
typically represents a certain limited number of host computers, the
hosts in a building or geographic area, or the hosts on an individual

7
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

local area network.

Tactical Data Link A JCS approved standardized communications link suitable for
(TDL) transmission of digital information. A TDL is characterized by its
standardized message formats and transmission characteristics.
Testable The ability to be verified with one of the standard verification methods
(i.e., Inspection, Analysis, Demonstration, or Test).
Will “Will” is used to introduce background information provided to
enhance understanding of requirements. “Will” is not a directive.

3.2 Abbreviations and acronyms.

Abbreviations and acronyms used in this MIL-STD are defined below. In addition, those listed
in the current edition of FED-STD-1037 have been included for the convenience of the reader.

ABM Asynchronous Balanced Mode

ACK Acknowledgment
ADM Asynchronous Disconnected Mode
ADMC_N Analog Data Mode Control_Not
ARP Address Resolution Protocol
ASD Adverse State Detector
ASIP Advanced System Improvement Program
ASK Amplitude Shift Keying
B Network Busy Sensing Time
BCH Bose-Chaudhuri-Hocquenghem
BER Bit Error Rate
bps bit(s) per second
C/R command/response
C/S/A Combatant Command/Service/Agency
C4I Command, Control, Communications, Computers, and Intelligence
CCITT International Telephone and Telegraph Consultative Committee
CDP Conditioned Diphase
CECOM Communications-Electronics Command
CIDR Classless Inter-Domain Routing
CNR Combat Net Radio
CNRWG Combat Net Radio Working Group
COMSEC Communications Security
CSMA Carrier Sense Multiple Access
DAP-NAD Deterministic Adaptive Prioritized - Network Access Delay
DARPA Defense Advanced Research Projects Agency
DATA Data Transmission Time
DAV-NAD Data and Voice - Network Access Delay
dB decibel

8
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

DC Direct Current
DCE Data Circuit-terminating Equipment
DDCO Digital Data Clock Out
Dec Decimal
DES Destination
DHCP Dynamic Host Configuration Protocol
DI Data Item
DIA Decoupled Information Acknowledgment
DISC Disconnect
DL Data Link Layer
DM Disconnect Mode
DMTD Digital Message Transfer Device
DNS Domain Name System
DoD Department Of Defense
DoDISS Department Of Defense Index Of Specifications and Standards
DPRL DSPICS Requirements List
DPSK Differential Phase-Shift Keying
DPTT Delayed Push-to-Talk
DRA Data Rate Adapter
DRNR Decoupled Receive Not Ready
DRR Decoupled Receive Ready
DS Differentiated Services
DSPICS DoD Standard Profile Implementation Conformance Statements
DTE Data Terminal Equipment
DTEACK DTE ACK preparation time
DTEPROC DTE Processing time
DTETURN DTE Turnaround time
DTR Delay, Throughput, and Reliability
ECP Emergency Command Precedence
EDC Error Detection and Correction
EDM Enhanced Data Mode
ELAG Equipment Lag time
EPRE Equipment Preamble time
ETE End-to-End
EUI Extended Unique Identifier
FCS Frame Check Sequence
FEC Forward Error Correction
FED-STD Federal Standard
FH Frequency Hopping
FIFO First-In First-Out
FLOAD Load Factor
FOAR Frequency of Access Ranking
FPI Field Presence Indicator

9
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

FRMR Frame Reject

FSK Frequency-Shift Keying
FSN First Station Number
FSNIN First Station Number Increment Number
GPI Group Presence Indicator
GRI Group Repeat Indicator
H-NAD Hybrid - Network Access Delay
HDLC High-level Data Link Control
Hex Hexadecimal
HF High Frequency
HLEN Header Length
HRT Hop Recovery Time
Hz Hertz
I PDU Information frame PDU
IAB Internet Architecture Board
ICD Interface Control Document
ICMP Internet Control Message Protocol
ICOM Integrated COMSEC
ICP Interface Change Proposal
IEEE Institute of Electrical and Electronic Engineers
IGMP Internet Group Multicast Protocol
IHL Internet Header Length
IL Intranet Layer
INAD Initial condition state Network Access Delay
IP Internet Protocol
ip Intranet Protocol
IPv4 Internet Protocol Version 4
IPV6 Internet Protocol Version 6
IS Initial/Subsequent Factor
ISO International Organization for Standardization
ITU International Telecommunications Union
JIEO Joint Information Engineering Organization
JRT Join Response Timer
JRTTL Join Request Time To Live
kbps kilobit(s) per second
KG Key Generator
KHz Kilohertz
LCMC Life Cycle Management Command
LOS Line-of-Sight
LSB Least Significant Bit
MDLTU Maximum Data Link Transmission Unit
MI Message Indicator
MIL-STD Military Standard

10
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

MLD Multicast Listener Discovery

MP Message Precedence
MSB Most Significant Bit
MTT Maximum Transmit Time
MTU Maximum Transmission Unit
N(R) Receive sequence number
N(S) Send sequence number
NA Not Applicable
NAC Network Access Control
NAD Network Access Delay
NATO North Atlantic Treaty Organization
NBDT Network Busy Detect Time
NBT Net Busy Timeout
NCS Network Control Station
net network
NETCON Network Control
NIC Network Information Center
NP Network Precedence
NR Not a Relayer
NRZ Non-Return-to-Zero
NS Number of Stations
OPS Operational Parameter Sets
OSI Open Systems Interconnection
OSPF Open Shortest Path First
OTAR Over-The-Air rekeying
OUI Organizational Unique Identifier
P/F Poll/Final
P-NAD Priority - Network Access Delay
PDU Protocol Data Unit
PHB Per Hop Behavior
PHASING PHASING transmission time
PL Physical Layer
PN Pseudo-Noise
PSK Phase-Shift Keying
PTT Push to Talk
R-NAD Random Network Access Delay
RAND Pseudorandom Number
RCP Robust Communications Protocol
RE-NAD Radio Embedded - Network Access Delay
REJ Reject
REL Relay
RF Radio Frequency
RFC Request For Comments

11
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

RHD Response Hold Delay

RNR Receive Not Ready
RPF Reverse Path Forwarding
RR Receive Ready
RSET Reset
RTURN Receiver Turnaround Time
R/T Receiver/Transmitter
S Coupled Acknowledgment transmission time
S/N Signal-to-Noise ratio
S/R Segmentation and Reassembly
S PDU Supervisory frame PDU
SABME Set Asynchronous Balanced Mode Extended
SALT Smallest Actual Lag Time
SATCOM Satellite Communications
SC Single Channel
SCC Standard Change Catalog
SDM Standard Data Mode
SINCGARS Single Channel Ground and Airborne Radio System
SIP System Improvement Program
SN Station Number
SNDCF Subnetwork Dependent Convergence Function
SOM Start Of Message
SOP Start Of Packet
SP Station Precedence
SREJ Selective Reject
subnet subnetwork
TBD To Be Determined
Tc Continuous Scheduler Inteval Timer
TCP Transmission Control Protocol
TCSS Telecommunications System Standards
TDC Time-Dispersive Coding
TOD Time of Day
TOL Tolerance time
TOS Type Of Service
TP Timeout Period
TRANSEC Transmission Security
TTTL TEST Time To Live
TTURN Transmitter Turnaround time
TURN Turnaround time
TWC Transmission Word Count
U PDU Unnumbered frame PDU
UA Unnumbered Acknowledgment
UDP User Datagram Protocol

12
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

UI Unnumbered Information
URN Unit Reference Number
URNR Unnumbered Receive Not Ready
URR Unnumbered Receive Ready
V(R) Receive-state Variable
V(S) Send-state Variable
VMF Variable Message Format
XNP Exchange Network Parameters

13
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

4 GENERAL REQUIREMENTS

4.1 Digital message transfer device (DTMD).

A DMTD is a portable data terminal device with limited message generation and processing
capability. DMTDs are used for remote access to automated C4I systems and to other DMTDs.
The environment encompasses point-to-point, point-to-multipoint, relay and broadcast transfer
of information over data communications links.

4.2 Interoperability.
Interoperability of DMTDs and associated C4I systems shall be achieved by implementing the
standard interface for DMTD subsystems (see FIGURE 1) specified in this document. This
standard defines the layered protocols for the transmission of single or multiple segment
messages over broadcast radio subnetworks and point-to-point links. It provides the minimum
essential data communications parameters and protocol stack required to communicate with
other data terminal devices. These communications parameters and protocols will facilitate
functional interoperability among DMTDs, and between DMTDs and applicable C4I systems
within the layered framework described below. Electrical and mechanical design parameters are
design-dependent and are outside the scope of this document. Interoperability considerations for
terminal designers and systems engineers are addressed in 6.3 and APPENDIX B.

SYSTEM B TRANSMISSION SYSTEM A

CHANNEL

STANDARD INTERFACE

NOTES:

1. System A and System B (where either system, or both, can be a DMTD or a C4I system) may include
modems, line drivers, error control algorithms, encryption devices, control units, and other devices as
required to comply with this standard.

2. The transmission channel may include single and multichannel transmission equipment.

FIGURE 1. Standard interface for DMTD subsystems.

14
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

4.3 Framework.
The communications and procedural protocols used in DMTD equipment shall support the layers
of the functional reference model depicted in FIGURE 2. The DMTD functional reference
model in FIGURE 2 is based on the ISO 7498 OSI seven-layer model and is for reference only.
FIGURE 2 contains the framework that is used in this document for defining the protocols
required to exchange information among DMTD subsystems, and between DMTD subsystems
and applicable C4I systems. FIGURE 3 illustrates a representative time epoch of the basic frame
structure supported by the DMTD subsystem. This standard describes the protocols at the
following OSI layers:

a. Physical Layer

b. Data Link Layer

1. Network Access Control
2. Link Level Control

c. Network Layer (Intranet Layer)

Application Layer *
Presentation Layer *
Session Layer *
Transport Layer *
Network Layer
Data Link Layer
Physical Layer

* NOTE: These layers are not defined in this standard.

FIGURE 2. DMTD functional reference model

15
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

~
~
COMSEC INTERIOR BIT INTERIOR COMSEC PHYSICAL LAYER
PHASING
PREAMBLE TRANS. UNIT SYNC. TRANS. UNIT POSTAMBLE CONCATENATION

~
~
~
~
TRANSMISSION TRANSMISSION DATA LINK DATA LINK INTERIOR TRANSMISSION UNIT
SYNC. HEADER FRAME FRAME (DATA LINK CONCATENATION)

~
~
FLAG ADDRESS CONTROL INFORMATION FRAME CHECK FLAG DATA LINK FRAME STRUCTURE
SEQUENCE FIELD FIELD FIELD SEQUENCE SEQUENCE (LINK LAYER)

INTRANET INTERNET NETWORK PROTOCOL DATA UNIT

DATA
HEADER HEADER (NETWORK LAYER)

NOTES: Phasing if required, is applied before the first Interior Transmission Unit.

Bit Synchronization is applied between physically concatenated Interior Transmission Units.

The Network Protocol Data Unit may include an Internet header in addition to the required Intranet
header.

This standard does not specify requirements for the Internet header.

FIGURE 3. Basic structure of DMTD protocol data units at the standard interface.

4.4 DMTD capabilities.

The waveform and the protocols necessary to ensure End-to-End (ETE) interoperability at the
interface may support the following capabilities:

a. Transmission in a half-duplex mode over radio, wireline, and satellite links.

b. Link encryption.

c. Point-to-point, multipoint, relay or broadcast connectivity between stations.

d. Asynchronous Balanced Mode (ABM) of operation between two or more stations.

e. Network access control for network access management and collision avoidance.

f. Transport of any application data over the link.

g. User data exchange using single or multiple frame packets.

h. Addressing conventions that support unicast and multicast (One-hop stations, all
stations, or special groups [e.g., all commanders]) station addressing, as well as routing and
relay.

16
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

i. Error control, for maintaining data integrity over the link, including Frame Check
Sequence, Forward Error Correction, and Time-Dispersal Coding.

j. Data scrambling to combat radio Direct Current (DC) bias.

k. Data link frame acknowledgment, intranet frame acknowledgment and ETE, segment
acknowledgment at the transport layer.

l. Intranet relay at the network layer.

m. Topology update capability for the intranet.

4.5 System standards and design.

The parameters and other requirements specified in this document are mandatory system
standards if the word shall is used in connection with the parameter value or requirement under
consideration. Non-mandatory design objectives are indicated in parentheses after a
standardized parameter value or by the words should, can or may in connection with the
parameter value or requirement under consideration. APPENDIX B also indicates whether
specific parameters or other requirements are mandatory or optional. All users of this document
shall take into consideration all parts of the document before making decisions to define, procure
or implement systems. In the event that there is an apparent conflict between the main volume
and APPENDIX B, then one of the following actions shall be taken:

a. The “mandatory” option shall be selected over the “optional” one.

b. The matter shall be referred to the Combat Network Radio Working Group (CNRWG)
for adjudication.

This document contains numerous essential technical parameters in the form of mandatory and
optional design objectives in which, in some situations, the parent capability is optional but the
value is mandatory if the optional capability is elected. Even though the child value is
mandatory, it does not mean the parent capability is mandatory.

Example: The Synchronous capability is a mandatory requirement that all systems must
implement. The Asynchronous capability is an optional requirement, but if elected then the
Frame Synchronization field is mandatory. The fact that the Frame Synchronization field is
mandatory if the Asynchronous process is selected does not mean that the Asynchronous process
is a mandatory requirement.

Unless stated otherwise, the following convention is used in the figures of MIL-STD-188-220:
Least Significant Bit (LSB) is always shown to the RIGHT, and Most Significant Bit (MSB) is
always shown to the LEFT.

17
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5 DETAILED REQUIREMENTS

5.1 Physical layer.

The physical layer (PL) shall provide the control functions required to activate, maintain, and
deactivate the connections between communications systems. This standard does not address the
electrical or mechanical functions normally associated with PL protocols.

5.1.1 Transmission channel interfaces.

Transmission channel interfaces should be implemented as dictated by the communication
device (e.g., radio) to which the system will be connected. The transmission channel interfaces,
specified in APPENDIX L, define the transmission envelope characteristics (signal waveform,
transmission rates, and operating mode) authorized at the standard interface between a DMTD
and the transmission channel. The transmission channel may consist of wireline, satellite, or
radio links. The specific details of the physical interface for connecting DMTDs to the
equipment that implements the transmission channel are beyond the scope of this document. The
actual physical connections will depend on the interface characteristics required by the particular
transmission equipment. These unique physical interface characteristics may be defined in the
equipment specifications or in technical interface specifications. Therefore, the requirements for
the electrical features (such as data, clock, and control) and mechanical features (such as
connectors, pin assignments, and cable) of the connection between the DMTD and the associated
transmission channel equipment are left to the equipment designer.

5.2 Physical-layer protocol.

5.2.1 Physical-layer Protocol Data Unit (PDU).

The transmission frame shall be the basic PDU of the PL and shall be as shown in FIGURE 4.
FIGURE 4a presents the transmission frame structure for traditional communication security
(COMSEC) (backward-compatible mode). Traditional COMSEC is used in this document to
denote systems with the COMSEC equipment placed external to the C4I system. FIGURE 4b
presents the transmission frame structure with COMSEC embedded in the C4I system
(embedded mode). FIGURE 4c presents the transmission frame structure without COMSEC.
This standard defines the following modes of transmission:

a. Synchronous Mode
b. Asynchronous Mode
c. Packet Mode

DMTD subsystems or applicable C4I systems shall support the Synchronous Mode of
transmission as a minimum for joint interoperability purposes. DMTD subsystems or applicable
C4I systems may support the Asynchronous Mode of transmission and/or Packet Mode of
transmission. Note that the Synchronous mode includes both Standard Data Mode (SDM) and
Enhanced Data Mode (EDM). For EDM, available in some radios, FEC and TDC are provided
by the radio. SDM typically requires FEC and TDC to be applied by the Data Terminal
Equipment (DTE).

18
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Notes:
Synchronous mode is used with Data Circuit-terminating Equipment (DCE) that present a clock
and data interface. Packet mode is used with DCEs that require no frame synchronization.
Asynchronous mode is used with DCEs that present modulated data without a clock.

COMSEC TRANSMISSION DATA COMSEC

PHASING
PREAMBLE SYNCHRONIZATION FIELD POSTAMBLE

Figure 4a. Transmission frame structure with external COMSEC.

TRANSMISSION SYNCHRONIZATION DATA COMSEC

PHASING
WITH COMSEC MESSAGE INDICATOR FIELD POSTAMBLE

Figure 4b. Transmission frame structure with embedded COMSEC.

TRANSMISSION DATA
PHASING
SYNCHRONIZATION FIELD

Figure 4c. Transmission frame structure with no COMSEC.

FIGURE 4. Transmission frame structure.

5.2.1.1 Communications security preamble and postamble.

These fields are present when link encryption is used. The COMSEC preamble field shall be
used to achieve cryptographic synchronization over the link. The COMSEC postamble field
shall be used to provide an end-of-transmission flag to the COMSEC equipment at the receiving
station. These fields and the COMSEC synchronization process are described in APPENDIX D
(D.5.1.1 and D.5.1.5, respectively).

5.2.1.2 Phasing.
Phasing shall be a string of alternating ones and zeros, beginning with a one, sent by the DTE.
For Synchronous mode interfaces, the length of this field may be 0. For Packet Mode interfaces,
the length of this field shall be 0. Phasing is optional for Synchronous mode. Phasing shall be
used with Asynchronous mode. Phasing is described in C.3.2.2.

5.2.1.3 Transmission synchronization field.

The structure of the transmission synchronization field is dependent on the mode of
transmission. The structures for Asynchronous and Synchronous modes are shown in FIGURE 5.
FIGURE 5a presents the transmission synchronization field with either external or no
COMSEC. FIGURE 5b presents the transmission synchronization field with embedded
COMSEC. The structure for the Packet Mode is described in 5.2.1.3.3. The Asynchronous and
Synchronous modes include both Standard Frame Synchronization (SFS) and Robust Frame

19
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Synchronization (RFS). The SFS shall be used to achieve synchronization when implementing
the mandatory Synchronous Mode of Transmission and the optional Asynchronous Mode of
Transmission. The RFS is used only when implementing the Robust Communication Protocol
(RCP) described in APPENDIX J for both the Asynchronous and Synchronous modes. The RCP,
available in some radios, is optional for both the Asynchronous and Synchronous modes.

Selectable:
3 FEC 1
4 4
FEC
BCH 2 TDC
TDC Scrambling
Standard Robust
Frame Frame Robust Frame Transmission Transmission Data Link
Sync Sync Format Word Count Header Frame(s)
Frame Sync

Transmission Synchronization Data Field

Figure 5a. With external COMSEC or No COMSEC.

3 1
4 4 1 Selectable:
FEC FEC
BCH FEC 2 TDC
TDC Scrambling

Standard Robust
Frame Frame Robust
Message Transmission Transmission Data Link
Sync Sync Frame
Indicator Word Count Header Frame(s)
Format
Frame Sync

Transmission Synchronization Data Field

Figure 5b. With Embedded COMSEC.

Notes:
n Golay FEC is applied to the Transmission Word Count, message Indicator and Transmission
Header fields in Asynchronous and Synchronous Modes. (The Transmission Header is the
leading portion of the Data Field as described in 5.3.1.)
o TDC is applied to the Transmission Word Count and Transmission Header fields in
Asynchronous and Synchronous Modes. (The Transmission header is the leading portion of
the Data Field as described in 5.3.1.)
p The Robust Frame Format (RFF) subfield is used only when implementing the RCP described
in APPENDIX J. BCH is applied to the RFF in Asynchronous and Synchronous Modes.
q The Standard Frame Synchronization and Robust Frame Synchronization are mutually
exclusive.

FIGURE 5. Transmission synchronization field.

20
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

(Synchronous and Asynchronous Mode)

5.2.1.3.1 Synchronous mode transmission synchronization field.

The Synchronous ModeTransmission Synchronization field shall be composed of the following:

a. Frame Synchronization
- Standard Frame Synchronization
- Robust Frame Synchronization

b. Robust Frame Format (RCP only)

c. Message Indicator (MI) (embedded COMSEC only)

d. Transmission Word Count

5.2.1.3.1.1 Frame synchronization subfield.

This subfield shall consist of the fixed 64-bit synchronization pattern shown in FIGURE 6 for
Standard Frame Synchronization or FIGURE 7 for Robust Frame Synchronization. The receiver
shall correlate for the frame synchronization pattern. A pattern shall be detected if 13 or fewer
bits are in error with non-inverted or inverted data. If the correlation detects an inverted
synchronization pattern, all received data shall be inverted before any other receive processing is
performed. If the Synchronization Pattern for Standard Frame Synchronization subfield shown
in FIGURE 6 is detected, the receiver shall assume the processing of optional Robust
Communication Protocol (RCP) is not requested for this transmission.

MSB LSB
1001101110110101011110100000100101101001010011110100111100100110

FIGURE 6. Synchronization pattern for standard frame synchronization.

If the robust frame synchronization pattern shown in FIGURE 7 is detected, the receiver shall
assume the processing of optional Robust Communication Protocol (RCP) described in 5.2.1.3.4
is requested for this transmission. The Robust Frame Format subfield shall be used to determine
what physical level processing is required for data reception. If the robust frame synchronization
pattern shown in FIGURE 7 is used, the frame synchronization pattern shown in FIGURE 6 shall
not be used.

21
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

MSB LSB

0001110001111010101101100100000011111101101101110011001110010010

FIGURE 7. Synchronization pattern for robust frame synchronization.

5.2.1.3.1.2 Robust frame format subfield.

The robust frame format subfield shall be used only with the robust frame synchronization
subfield shown in FIGURE 7 for RCP processing. The robust frame format subfield is a seven-
bit field, which specifies the format of the transmitted frame. Three selectable processes:
convolutional coding, data scrambling and packetizing shall be used to construct the
transmission frame. The bits are defined in TABLE I and TABLE II. Note that the packetizing
scheme is the Multi-Dwell Protocol (MDP) as defined in APPENDIX J. TABLE III is applied
only when Multi-Dwell Flag is set to one (1). The robust frame format subfield shall be
formatted with multi-dwell majority vote 3 out of 5 Bose-Chaudhuri-Hocquenghem (BCH)
(15,7) coding with no scrambling and no convolutional encoding.

TABLE I. Robust frame format.

Bit(s) Fields
0 (LSB) Multi-Dwell Flag
1 Scrambling Flag
2, 3, 4 Multi-Dwell Transmission Format
5,6 Convolutional Coding Constraint Length

TABLE II. Multi-dwell transmission format.

(The Most Significant Bit is shown on the Left)

000 Single BCH(15,7) word

32 Bit SOP, 11 64-bit segments per packet
001 Majority Vote 2 out of 3 BCH(15,7) word
64 Bit SOP, 13 64-bit segments per packet
010 Majority Vote 3 out of 5 BCH(15,7) word
64 Bit SOP, 13 64-bit segments per packet
011 Majority Vote 3 out of 5 BCH(15,7) word
64 Bit SOP, 6 64-bit segments per packet

22
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

TABLE III. Convolutional coding constraint length codes.

(The Most Significant Bit is shown on the Left)

00 Constraint Length 3
01 Constraint Length 5
10 Constraint Length 7
11 Convolutional Coding Disabled

5.2.1.3.1.3 Message Indicator (MI).

The MI field is contained within the transmission synchronization field only when COMSEC is
embedded in the host. The MI field is defined in APPENDIX D (D.5.1.1.3 and D.5.2.4). Golay
FEC is applied to the Transmission Word Count (TWC), MI (with embedded COMSEC) and
Transmission Header in Asynchronous and Synchronous Modes.

5.2.1.3.1.4 Transmission Word Count (TWC) subfield.

The TWC is a 12-bit value calculated by the transmitting station to inform the receiving station
of the number of 16-bit words (after any appropriate FEC encoding, TDC fill or zero bit
insertion) contained in the transmission. The TWC calculation shall include the length of the
TWC and data field (see 5.2.1.4). The maximum TWC is 4095 (212-1). The value provided by
the 12 information bits is binary-encoded. The maximum number of words is dependent on the
maximum number of bits allowed in the data field of a transmission frame. It is possible that the
number of bits in the data field will not be evenly divisible by 16. In that case, the word count
shall be rounded to the next higher integer and a variable number of zeros, 0 to 15, shall be
appended after the final link layer frame in order to make the Transmission Unit an integral
number of 16-bit words. These zeros shall not be subject to FEC or TDC (see G.3.7.1.3). TDC
is applied to the TWC and Transmission Header in Asynchronous and Synchronous Modes.
Golay FEC is applied to the TWC, MI (with embedded COMSEC) and Transmission Header in
Asynchronous and Synchronous Modes.

5.2.1.3.2 Asynchronous mode Transmission Synchronization field.

The Asynchronous Transmission Synchronization field shall be composed of the following:

a. Frame Synchronization

- Standard Frame Synchronization

- Robust Frame Synchronization

b. Robust Frame Format (RCP only)

c. Message Indicator (MI) (embedded COMSEC only)

d. Word Count

23
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.2.1.3.2.1 Frame synchronization subfield.

The Asynchronous Mode Synchronization Pattern for Standard Frame Synchronization subfield
is the same as the Synchronous Mode Synchronization Pattern for Standard Frame
Synchronization subfield defined in 5.2.1.3.1.1 and shown in FIGURE 6.

5.2.1.3.2.2 Robust Frame Synchronization subfield.

The Asynchronous Mode Synchronization Pattern for Robust Frame synchronization subfield is
the same as the Synchronous Mode Synchronization Pattern for Robust Frame synchronization
subfield defined in 5.2.1.3.1.2 and shown in FIGURE 7.

5.2.1.3.2.3 Message Indicator.

The format of the Asynchronous Mode MI field is the same as for the Synchronous Mode MI
field defined in 5.2.1.3.1.3.

5.2.1.3.2.4 Transmission Word Count subfield.

The Aynchronous Mode TWC format is the same as the Synchronous Mode TWC defined in
5.2.1.3.1.4.

5.2.1.3.3 Packet mode transmission synchronization field.

This field consists of at least one HDLC flag corresponding to the flag bit pattern shown in
FIGURE 8. When a DTE has data to send to the radio (DCE) it shall transmit flags on the ‘T’
lead until flags are received from the radio (DCE) on the ‘R’ lead, then data shall be sent to the
radio (DCE) on the ‘T’ lead. A variable number (at least one) of lead flags shall be transmitted
prior to the actual data. On the receive side, the radio (DCE) shall send at least one flag prior to
the data it sends to the DTE.

MSB LSB
01111110

FIGURE 8. Packet mode transmission synchronization field.

5.2.1.3.4 Robust Communications Protocol (RCP).

The RCP provides the additional processing to aid the transfer of secure and non-secure digital
data when combined with the link processing of the MIL-STD-188-220 protocol. The RCP and
its sub components are described in detail in APPENDIX J.

5.2.1.4 Data field.

The data field shall contain the string of bits, comprising the Transmission Header and
concatenated data link frames, created by the data link layer following the procedures for
framing, zero bit insertion, concatenation, FEC, TDC, and scrambling. FEC, TDC and
Scrambling are not applied when Packet Mode is used.

24
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.2.1.5 Bit synchronization field.

This field shall be used to provide the receiver a signal for re-establishing bit synchronization.
Bit synchronization is used only between physically concatenated frames in Asynchronous
Mode. The bit synchronization field shall be a 64-bit pattern that consists of alternating ones and
zeros, beginning with a one.

5.2.2 Network Access Control (NAC) related indications.

a. The net busy information is conveyed to the upper layer protocol (data link) through a
status indication. Upon detection of a net busy, the net busy indicator shall be set. The net busy
sensing indicator shall be reset when neither digital data nor voice is detected by the net busy
sensing function. APPENDIX C (C.4.1) describes the net busy sensing function.

b. The NAC algorithm described in APPENDIX C needs the transmitter to know when the
last bit of data is transmitted, and the receiver to know when the last bit of data is received.

5.2.3 Physical-layer to upper-layer interactions.

At least three primitives are used to pass information for the sending and receiving of data across
the upper layer boundary.

a. Requests for transmission of data are sent by the upper layer, using the PL Unitdata
Request primitive with the following parameter:

PL-Unitdata Request
Data/Data length
FEC/TDC/Scrambling
No FEC, No TDC, No Scrambling
No FEC, No TDC, Scrambling
FEC, No TDC, No Scrambling
FEC, No TDC, Scrambling
FEC, TDC, No Scrambling
FEC, TDC, Scrambling
Multi-dwell transmission format segment count
6 segments per packet
11 segments per packet
13 segments per packet
PL Scrambling
No PL Scrambling
PL Scrambling

25
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Convolutional coding constraint length

Constraint length 3
Constraint length 5
Constraint length 7

b. Indication of data received is provided to the upper layer through the Unitdata Indication
primitive with the following parameter:

PL-Unitdata Indication
Data/Data length
FEC/TDC/Scrambling
No FEC, No TDC, No Scrambling
No FEC, No TDC, Scrambling
FEC, No TDC, No Scrambling
FEC, No TDC, Scrambling
FEC, TDC, No Scrambling
FEC, TDC, Scrambling
Multi-dwell transmission format segment count
6 segments per packet
11 segments per packet
13 segments per packet
PL Scrambling
No PL Scrambling
PL Scrambling
Convolutional coding constraint length
Constraint length 3
Constraint length 5
Constraint length 7

c. Net activity status information is provided to the upper layer through a Status Indication
with the following parameters:

PL-Status Indication
Net activity
net clear
net busy
busy with/data
busy with/voice
Transmission Status
transmit complete/idle
in-process
transmit aborted

26
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3 Data Link layer.

The Data Link layer shall provide the control functions to ensure the transfer of information over
established physical paths, to provide framing requirements for data, and to provide for error
control. Zero bit insertion is applied to the Transmission Header and Data Link Frame.

5.3.1 Transmission Header.

The Transmission Header is the leading portion of the Data Field transmission (see 5.2.1.4). The
Transmission Header consists of a two-octet Transmission Information field, a 32-bit FCS, in
accordance with 5.3.4.2.5, and is bounded by Flags in accordance with 5.3.4.2.1. The
Transmission Information field contains Selection bits, MIL-STD-188-220 Version and a
Transmission Queue field which indicates the transmitting station queue length. The
Transmission Header format is shown in FIGURE 9. Golay FEC and TDC are applied to the
entire Transmission Header (except when the Packet Mode Interface described in L.4.1.6 is used
at the PL), including leading and trailing flags, MI (with embedded COMSEC) and TWC. The
TWC, MI and Transmission Header shall have Golay FEC applied when operating in the
Asynchronous and Synchronous modes. TDC (7x24) bit interleaving shall be applied in unison
with the FEC on the TWC and Transmission Header. The data shall be formatted into a TDC
block composed of seven (7) 24-bit Golay (24,12) codewords in a manner analogous to 5.3.14.3.
There are 168 FEC-encoded bits with this TDC. The MIL-STD-188-220 Version subfield
indicates the lower layer protocol version, refer to 5.3.1.2.

LSB MSB MSB LSB

TRANSMISSION
FLAG FRAME CHECK SEQUENCE FLAG
INFORMATION
(8 bits) (32 bits) (8 bits)
(16 bits)

FEC TDC Scramble MIL-STD-188-220 Version Transmission Queue (10 bits)

0 = Not Selected
1 = Selected

FIGURE 9. Transmission header.

5.3.1.1 Selection bits.

The first three bits of the Transmission Information field selects FEC, TDC and Scrambling,
respectively, on or off for the remainder of the PL data field. A zero indicates “off” and a one
indicates “on” in these bit positions. Regardless of the setting of these three bits, Golay
FEC/TDC is applied and Scrambling is not applied to the entire Transmission Header.
Scrambling, if used, shall be applied before any FEC and TDC is applied. FEC, TDC and
scrambling are not applied when the Packet Mode Interface described in L.4.1.6 is used at the
PL. In addition, FEC/TDC is not applied when the SINCGARS Synchronous mode is selected
utilizing the EDM available in the SIP and ASIP radio.

27
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.1.2 MIL-STD-188-220 Version.

This subfield shall identify the MIL-STD-188-220 Version used to generate this message.

Value MIL-STD-188-220 Version

0 Reserved
1 MIL-STD-188-220D
2 MIL-STD-188-220D w/CHANGE 1
3-7 Undefined

FIGURE 10. MIL-STD-188-220 Version

MIL-STD-188-220D w/CHANGE 1 compliant systems shall use the value “2” for all transmitted
messages. If a station supporting only MIL-STD-188-220D w/CHANGE 1 is connected to a
network containing stations supporting a different version (an earlier or later version) of the
MIL-STD it is possible that a DL PDU with a MIL-STD-188-220 Version field value other than
2 will be received by the station supporting MIL-STD-188-220D w/CHANGE 1. Received DL
PDUs with a MIL-STD-188-220 Version field value that is not equal to 2 shall be discarded by
stations that implement only MIL-STD-188-220D w/CHANGE 1 and a DL-Error Indication
shall be generated indicating that an unsupported MIL-STD-188-220 Version field value was
received.

5.3.1.3 Transmission Queue field.

This field is used to support the Radio Embedded - Network Access Delay (RE-NAD) process
and the Deterministic Adaptable Priority - Network Access Delay (DAP-NAD) process and the
Data and Voice - Network Access Delay (DAV-NAD) process. The entire field is 10-bits long
with the first two bits (‘T’-bits) indicating how the rest of the 8-bits long subfield is interpreted.
The format of the transmission queue field is shown in FIGURE 11.

5.3.1.3.1 T-bits.
The two left-most bits in the transmission queue field are the T-bits. The bit sequence
interpretations are indicated in FIGURE 11. The transmission queue subfield has a variable
format depending on which of the following uses are intended:

28
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

T-bits
LSB MSB
a. 0 0 The transmission queue subfield does not contain information and is
ignored.
b. 0 1 The transmission queue subfield is used in conjunction with RE-NAD. This
subfield contains queue precedence (in bit positions 2-3) and queue length
(bit positions 4-7). Bit positions 8 and 9 are spare and ignored.
c. 1 0 The transmission queue subfield is used in conjunction with DAP-NAD and
DAV-NAD. This subfield contains Data Link Precedence (in bit positions 2
and 3) and First Station Number (FSN) (in bit positions 4-9).
d. 1 1 This bit sequence is INVALID and shall be ignored. Data link frame(s)
after this header shall be processed normally.

LSB MSB
T-Bits
0 1 2 3 4 5 6 7 8 9
0 0 Transmission Queue Subfield Ignored
0 1 Queue Prec. Queue Length Spare
1 0 Data Link Prec. First Station Number
1 1 Invalid/Ignored

FIGURE 11. Transmission queue field formats.

5.3.1.3.2 Queue precedence.

The queue precedence component indicates the highest precedence level of information type
frames in the queue.

The precedence levels and bit sequences are:

Precedence Bit 2 Bit 3 Value

Urgent 0 0 0
Priority 1 0 1
Routine 0 1 2
Reserved 1 1 3

5.3.1.3.3 Queue Length.

The Queue Length component indicates the number of concatenated frame sequences required to
transmit all of the highest precedence messages in the transmission queue at the time the
transmission was created. This number may be used by receiving station to calculate the average
network member’s queue length. This average is used in calculation of the continuous scheduler
for the Radio Embedded channel access procedure (C.4.4.4).

29
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.1.3.4 Data Link Precedence.

This subfield consists of two bits and contains a value that indicates the highest precedence of
any message that is contained in the physical frame. It shall contain the value 0 if an urgent
message is in the frame, 1 if a priority but no urgent message is in the frame and 2 if neither an
urgent nor priority message is in the frame. The variable NP in the equations defined in
APPENDIX C (C.4.4.5.2) is set equal to the contents of the highest precedence Data Link
Precedence field in any (possibly concatenated) physical frame contained in the most recent
reception.

The precedence levels and bit sequences for the Data Link Precedence field are:

Precedence Bit 2 Bit 3 Value

Urgent 0 0 0
Priority 1 0 1
Routine 0 1 2
Undefined 1 1 3

Undefined precedence values shall be handled as routine.

5.3.1.3.5 First Station Number (FSN).

This subfield consists of 6 bits and designates the number of the station that is to have the first
net access opportunity at the next net access period (the one immediately following this
transmission). The number of the station that has the first net access opportunity is the variable
FSN in the equations defined in APPENDIX C (C.4.4.5.2).

Bit coding for FSN is:

1st Station # Bit: 4--->9

Illegal 000000
1 100000
2 010000
. ..
. ..
. ..
63 111111

5.3.2 Network access control.

The presence of multiple stations on a single communications net requires a method of
controlling the transmission opportunities for each station. To minimize conflicts, the net busy
sensing function and NAC procedures regulate transmission opportunities for all participants on
the net. Random - Network Access Delay (R-NAD), Hybrid - Network Access Delay (H-NAD),
Prioritized - Network Access Delay (P-NAD), Radio Embedded - Network Access Delay (RE-
NAD), Data and Voice – Network Access Delay (DAV-NAD) and Deterministic Adaptable
Priority - Network Access Delay (DAP-NAD) are the authorized NAC procedures at this

30
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

interface. APPENDIX C defines the NAC parameters for R-NAD, H-NAD, P-NAD, DAP-
NAD, DAV-NAD, and RE-NAD. As a minimum, DAP-NAD and R-NAD shall be available to
regulate transmission opportunities for all participants when the network is operating in
Synchronous Mode.

5.3.2.1 Scheduler.
When the net access is embedded in the radio, a scheduler may be implemented in the DTE or
communications processor to organize radio access throughout the network. The scheduler is
used to provide a random distribution of timing for channel requests. When a station has data to
transmit, it shall calculate the scheduler timer as indicated in APPENDIX C (C.4.4.4.1). When
this timer expires, the link layer shall first determine that the previous frame concatenation was
transmitted by the PL. If the frame concatenation was not transmitted, the link layer shall
request its transmission. If a higher precedence individual frame becomes available for
transmission, the concatenated frames shall be re-built to include the higher precedence frame.
If the previous frame concatenation was transmitted, the link layer shall build a new frame
concatenation. This frame concatenation shall then be passed to the PL for transmission. Both
randomized and immediate scheduler modes are specified in APPENDIX C (C.4.4.4.1.1,
C.4.4.4.1.5, and C.4.4.4.1.6, respectively).

5.3.3 Types of operation.

Four types of operation for data communication between systems are defined to provide basic
connectionless and connection mode operations:

Type 1 - Unacknowledged Connectionless Operation

Type 2 - Connection-mode Operation
Type 3 - Acknowledged Connectionless Operation
Type 4 - Decoupled Acknowledged Connectionless Operation

Types and services 1 through 3 are based on ISO 8802-2. The Type 1 and Type 3 connectionless
operations are mandatory for implementation in all systems. The Type 2 connection mode and
the Type 4 connectionless mode (decoupled ACK) are optional.

5.3.3.1 Type 1 operation.

For the purpose of this protocol, Type 1 operation will designate the ISO 8802-2
unacknowledged connectionless operation.

5.3.3.2 Type 2 operation.

With Type 2 operation, a data link connection shall be established between two systems prior to
any exchange of information bearing PDUs. For efficiency at system startup, connections may
be assumed to exist with all other stations in the network; and the system may depend on
information transfer phase procedures to resolve error conditions. To guarantee a reliable (i.e.,
no loss) service, connections should be explicitly established, not assumed to exist. The
connection normally shall remain open until a station leaves the net.

31
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.3.3 Type 3 operation.

For the purpose of this protocol, Type 3 operation will designate the ISO 8802-2 acknowledged
connectionless operation.

5.3.3.4 Type 4 operation.

With Type 4 operation, acknowledgments are decoupled from the original Decoupled
Information Acknowledgment (DIA) PDU, and DIA PDUs contain a non-modulus identification
number assigned by the originator.

5.3.3.5 Station class.

Four station classes define the data link procedures supported by a system:

Station Class A - Supports Types 1 and 3; not Types 2 and 4

Station Class B - Supports Types 1, 2 and 3; not Type 4
Station Class C - Supports Types 1, 3 and 4; not Type 2
Station Class D - Supports Types 1, 2, 3 and 4.

5.3.4 Data Link frame.

The Data Link frame shall be the basic PDU of the link layer. The Transmission Header is not a
PDU.

5.3.4.1 Types of frames.

Three types of frames convey data over the Data Link: an unnumbered frame (U PDUs), an
information frame (I PDUs) and a supervisory frame (S PDUs).

5.3.4.1.1 Unnumbered frame.

The U PDUs shall be used for Type 1, Type 2, Type 3, and Type 4 operations. They provide
connectionless information transfer for Types 1,3 and 4 operations. U PDUs provide
acknowledgment for Type 3, and station identification/status information for Types 1 and 3
operations. They also provide data link control functions for Type 1 through 4 operations.

5.3.4.1.2 Information frame.

The I PDUs are used for information transfer in Type 2 operations only. They convey user data
or message traffic across a link. The I PDUs are not used in Type 1, Type 3, or Type 4
operations.

5.3.4.1.3 Supervisory frame.

The S PDUs are used for data link supervisory control functions and to acknowledge received I
PDUs in Type 2 operations. Additionally, the Type 4 Decoupled Receive Ready (DRR)
response S PDU is used to acknowledge Type 4 DIA PDUs. The S PDUs are not used in Type 1
or Type 3 operations.

5.3.4.2 Data Link frame structure.

The basic elements of the Data Link frame shall be the opening flag sequence, the address field,
the control field, the information field, the FCS, and the closing flag sequence. Each Type 1,

32
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Type 2, Type 3, and Type 4 Data Link frame shall be structured as shown in the Data Link frame
portion of FIGURE 12.

Transmission Header One or More Data Link Frame

Transmission
Flag FCS Flag Flag Address Control Information FCS Flag
Information
8 bits 2 octets 32 bits 1-32 Up to 3345
8 bits 8 bits Variable 32 bits 8 bits
octets octets

see see see see

see 5.3.1 see 5.3.4.2.4
5.3.4.2.1 5.3.4.2.5 5.3.4.2.2 5.3.4.2.3

FIGURE 12. Data Link frame structure and placement

5.3.4.2.1 Flag sequence.

All frames shall start and end with the 8-bit flag sequence of one 0 bit, six 1 bits, and one 0 bit
(01111110). The flag shall be used for Data Link frame synchronization.

5.3.4.2.2 Address fields.

These fields shall identify the data link layer addresses of the source and destinations. The data
link destination address in the data link header is the address of the next hop to reach the final
destination which may be different than the Destination/Relay Address field(s) in the intranet
header. The intranet address in the intranet header is the data link address of the final destination
of the intranet packet, which is indicated by setting the Destination bit to ”1” corresponding to
the Destination/Relay Address field of the final destination. The syntax of the data link address
and intranet address (Destination/Relay Address field or Originator Address field) are the same
(i.e. use the same bit field representations). Address types are: unicast, multicast (One-hop
multicast, or group multicast), special, or reserved addresses. The size of this field will vary
depending on the size of addresses (single octet, four octet, or six octet), used for the
transmission:

Single Octet Addressing range (includes source and destination address): 2-17 octets
Four Octet Addressing range (includes source and destination address): 6-85 octets
Six Octet Addressing range (includes source and destination address): 8-119 octets

5.3.4.2.2.1 Address format.

5.3.4.2.2.2.5 Reserved address.

Address ”0” is labeled a reserved address. A station receiving a value of 0 in the destination
address field shall ignore the address and continue processing any remaining addresses. The
Reserved address is not valid as a source address.

36
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.4.2.2.3 Addressing convention.

The following addressing conventions shall be implemented in the 7 address bits of each address
octet, 32-bit marker octet, or 48-bit marker octet. Address allocations, as shown in FIGURE 14,
are divided among seven address types: unicast, One-hop Multicast, group multicast, 32-bit
marker, 48-bit marker, special, and reserved.

NOTE: Data link addresses are assigned by an administrative authority or via NETCON as
defined in APPENDIX E.

5.3.4.2.2.3.1 Source and destination.

5.3.4.2.2.3.1.1 Source address.

The source address is either a unicast or special (Net Control or Net Entry) address and is always
the first address. Either single octet, four octets, or six octets unicast address formatting may be
used. Its legal values range from 1 to 95, excluding 3 for single octet format. In four octets
format legal values range from 0 to 232-1 (0.0.0.0 – 255.255.255.255 in dot notation). In six
octets format legal values range from 0 to 248-1 (00-00-00-00-00-00 to FF-FF-FF-FF-FF-FF in
hex notation as per RFC 2464). If IPv6 is used at the Network Layer, the Source Address shall
be six octets. The first octet of the source address has two parts: the C/R designation bit (bit 1,
LSB) and the actual 7-bit address value. The C/R designation bit shall be set to “0” for
commands and “1” for responses.

MSB LSB
8 7 6 5 4 3 2 1
X X X X X X X 0/1 SOURCE Octet (1 = response; 0 = command)

X X X X X X X 0 DESTINATION 1 Octet

.. .
.. .
.. .
X X X X X X X 1 DESTINATION M Octet where M < 16

Note: In four octets addressing the 32-bit marker octet is followed by the actual four octet
address. In six octets addressing the 48-bit marker octet is followed by the actual six octet
address.

FIGURE 13. Extended address field format.

37
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

MSB LSB
1 1 1 1 1 1 1 1 127 Multicast (One-hop or Global) Address
1 1 1 1 1 1 0 X 126 32-bit Marker (4 octet addressing)
1 1 1 1 1 0 1 X 125 48-bit Marker (6 octet addressing)
1 1 X X X X X X 96-124 Group Multicast Addresses (Single
Octet)
X X X X X X X X 4-95 Unicast Addresses (Single Octet)
0 0 0 0 0 1 1 X 3 Special (Immediate Retransmission)
0 0 0 0 0 1 0 X 2 Special (Net Control) Address
0 0 0 0 0 0 1 X 1 Special (Net Entry) Address
0 0 0 0 0 0 0 X 0 Reserved Address

FIGURE 14. Address allocation.

5.3.4.2.2.3.1.2 Destination address(es).

In FIGURE 14 Destination 1 through Destination N are labeled destination addresses, which
may be unicast, group or multicast (group or One-hop) or special addresses. Each destination
address may be formatted as a single octet, four octets, or six octets. The first octet of each
destination address (an actual address or the 32-bit or 48-bit marker) has two parts: the extension
bit (bit 1, LSB) and the actual 7-bit value. An extension bit set to 0 indicates that 1 or more
addresses (of either single octet, four octets, or six octets formats) follow. An extension bit set to
1 indicates the last address of the address string has been reached. Stations shall be capable of
sending and receiving 1 to 16 individual destination addresses in a single data link frame.
Sending stations shall use any address just once in a data link frame. A receiving station shall
receive all addresses, search for its unique unicast address or multicast group for which it is a
member, and follow the media access procedures described in APPENDIX C.

5.3.4.2.2.3.1.3 Unicast, special and multicast addresses mixed.

All stations shall be capable of sending and receiving One-hop multicast, unicast, and optionally
group multicast addresses. The unicast, special and group multicast addresses may be “mixed”
in a destination address subfield. The reception and acknowledgment procedures stated in this
paragraph shall be for all stations even those that do not implement group multicast addressing
procedures.

a. The total number of destination addresses shall not exceed 16.

b. All unicast and special addresses shall precede multicast addresses.

38
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

c. The special address 3, if used, shall follow all unicast, reserved, and other special
addresses but shall precede multicast addresses.

d. Unicast addresses occurring after the special address 3 shall be ignored by receiving
stations. Specifically, the receiving stations whose unicast address is listed after special address
3 shall not generate a Type 3 acknowledgment in response to receipt of the Type 3 frame, and
other receiving stations shall not reserve an acknowledgment time slot for stations matching
these unicast addresses to send acknowledgments.

e. Only one type of multicast address (group or One-hop) shall be mixed in a destination
address subfield.

f. If multicast, special and unicast addresses are mixed, only the unicast and special
addresses shall be acknowledged when indicated.

g. Multicast addresses shall not be acknowledged but a data link response (using a TEST
Response PDU) is allowed in the case where a TEST message is received with a multicast
address in the destination field and the poll bit is set to 0.

h. A station that implements multicast addressing shall also be capable of sending and
receiving multicast, special and unicast addresses “mixed” in a destination subfield.

i. Stations shall treat single, four, and six octet addresses as separate and distinct
addresses, e.g., address “3” with no 32-bit or 48-bit marker preceding it is different than address
“0.0.0.3” preceded by the 32-bit marker “126”, which is different than address “0-0-0-0-0-3”
preceded by the 48-bit marker “125”.

j. Reserved, Special, Group and Multicast Addresses, and the 32-bit and 48-bit Markers
shall always be single octet addresses. Only single octet addresses shall represent Reserved,
Special, Group and Multicast Addresses, and the 32-bit and 48-bit Markers.

k. The address types enumerated in “5.3.4.2.2.3.1.3.j” above can be mixed with four or six
octet Addresses. Therefore, a station could receive the following in the Destination Address
field:

126 0 0 0 3 3

Indicating that the message has one four octet destination address (‘0.0.0.3’) and is using
Immediate Retransmission (Special Address ‘3’).

5.3.4.2.3 Control field.

The control field indicates the type of PDU and the response requirements and connection
information about the PDU being transmitted over the data link. A summary of the formats and
bit patterns (showing MSB as the left most bit) for Types 1, 2, 3 and 4 is shown in TABLE IV,

RESPONSES FIELD The left-most bit is FIELD
the most significant
bit.
S PDUs
REJECT (REJ) Contains the source address Bit pattern = No information
COMMAND and up to 16 unicast RRRRRRRX000010 field allowed.
addresses of stations to 01 indicating reject
receive this PDU. command.
REJECT (REJ) Contains the source address Bit pattern = No information
RESPONSE and up to 16 unicast RRRRRRRX000010 field allowed.
addresses of stations to 01 indicating reject
receive this PDU. response.

(X represents the P/F bit setting, S represents send sequence number, and R represents receive sequence number.)

TABLE VI. Type 3 PDU Formats.

COMMANDS/ ADDRESS CONTROL FIELD INFORMATION

44
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

TABLE VI. Type 3 PDU Formats-Continued

COMMANDS/ ADDRESS CONTROL FIELD INFORMATION

RESPONSES FIELD The left-most bit is FIELD
the most significant
bit.
U PDUs
TEST COMMAND Contains the source address Bit pattern = Information field
and up to 16 unicast or 11110011 indicating optional.
multicast addresses that are test command.
to respond.
TEST RESPONSE Contains the source address Bit pattern = Information field
and the destination address to 11110011 indicating optional.
which this response is being test command.
sent.

TABLE VII. Type 4 PDU formats.

COMMANDS/ ADDRESS CONTROL FIELD INFORMATION

RESPONSES FIELD The left-most bit is the FIELD
most significant bit.
U PDU
DECOUPLED Contains the source address and Bit pattern = Contains data from
INFORMATION up to 16 unicast or multicast <ID #->LL101011 the upper protocol
ACKNOWLEDGMENT addresses for which the message L-bits are used to layer.
(DIA) is intended. indicate PDU
precedence.
S PDUs
DECOUPLED RECEIVE Contains the source address and Bit pattern = No information
READY (DRR) up to 16 unicast or multicast 00000000LL010001 field allowed.
COMMAND addresses. indicates a station is
ready to receive DIA
PDUs.
DECOUPLED RECEIVE Contains the source address and Bit pattern = No information
READY (DRR) unicast address for the <ID #->LL010001 field allowed.
RESPONSE originator of the DIA PDU L-bits are used to
which this PDU ACKs. indicate precedence of
PDU being
acknowledged. The ID
no. is that of the DIA
PDU being
acknowledged.

45
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

TABLE VII. Type 4 PDU formats-Continued

COMMANDS/ ADDRESS CONTROL FIELD INFORMATION

RESPONSES FIELD The left-most bit is the FIELD
most significant bit.
S PDUs
DECOUPLED RECEIVE Contains the source address and Bit pattern = No information
NOT READY (DRNR) up to 16 unicast or multicast 00000000LL010101 field allowed.
COMMAND addresses. indicates a station is
not ready to receive
DIA PDUs due to a
busy condition.
DECOUPLED RECEIVE Contains the source address and Bit pattern = No information
NOT READY (DRNR) unicast address for the <ID #->LL010101 field allowed.
RESPONSE originator of the DIA PDU L-bits used to indicate
which this PDU ACKs. precedence of PDU
being acknowledged.
The ID no. is that of
the DIA PDU being
acknowledged. PDU
indicates a station is
not ready to receive
DIA PDUs due to a
busy condition.

46
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

MSB LSB
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

INFORMATION TRANSFER
N(R) P/F N(S) 0
Type 2
SUPERVISORY
COMMANDS/RESPONSES Type 2 N(R) P/F Z Z Z Z S S 0 1
(S PDUs)

Type 4 ID Number L L 0 1 S S 0 1

UNNUMBERED
COMMANDS/RESPONSES Types M M M P/F M M 1 1
(U PDUs) 1, 2 & 3

Type 4 ID Number L L 1 0 1 0 1 1

Type 1 Topology Update ID

Topology Update ID 1 0 0 0 0 0 1 1
Indication

Type 1 CANTPRO Indication 0 C C C 0 P P P 1 1 0 0 0 0 1 1

FIGURE 15. Data link PDU control field formats.

47
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Notes:

The LSB is the first bit delivered to and received from the physical layer.

N(S) = Transmitter send sequence number (Bit 2 = LSB)

N(R) = Transmitter receive sequence number (Bit 10 = LSB)
S = Supervisory Function bit
M = Modifier function bit
Z = Reserved and set to zero
P/F = Poll bit - command PDU transmissions
Final bit - response PDU transmissions
(1 = Poll/Final)
L = Level of precedence (LSB on right)
1 1 = reserved (value = 3)
1 0 = routine (value = 2)
0 1 = priority (value = 1)
0 0 = urgent (value = 0)
C = Version received that this station cannot process (LSB on right).
Obtained from the MIL-STD-188-220 Version field in the received Transmission
Information header.
P = Preferred Version for future communications (LSB on right).
This is the same value used to populate the MIL-STD-188-220 Version field
in the Transmission Information header.
T = Topology Update ID used in the most recent Topology Update.

FIGURE 15. Data link PDU control field formats-Continued

5.3.4.2.3.1 Type 1 operations.

For Type 1 operations, the control field is either an 8-bit or 16-bit pattern designating 1 of 7
types of U PDUs. The following PDUs have an 8-bit control field: UI Command, URR
Command, URNR Command, TEST Command, and TEST Response. The URR and URNR
PDUs are used to indicate overall station status for Types 1, 2, 3 and 4. The Type 1 U PDUs that
have a 16-bit pattern are: Topology Update Indication and Version CANTPRO Indication..
Type 1 URR and URNR PDUs shall use only unicast addresses or multicast (One-hop or group)
addresses.

5.3.4.2.3.2 Type 2 operations.

The Type 2 control field is a 16-bit pattern for I PDUs and S PDUs and includes sequence
numbers. The Type 2 U PDUs have an 8-bit pattern. The Type 2 control field shall be repeated
if more than one destination address is present. Each destination address field shall have a
corresponding control field. Each of the corresponding control fields (when repeated) shall be
identical except for the P/F bit and sequence numbers. The Type 1 Unnumbered Receive Ready
(URR) and Unnumbered Receive Not Ready (URNR) PDUs are used to indicate overall station
status. The RR and RNR are used to indicate station status for Type 2 operations only.

48
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.4.2.3.3 Type 3 operations.

For Type 3 operations, the control field is an 8-bit pattern designating 1 of 5 types of U PDUs:
UI Command Acknowledgment Required, URR Response (used to acknowledge a Type 3 UI
Command), URNR Response, TEST Command, and TEST Response. The URR and URNR
PDUs are used to indicate overall stations status, but only to the single addressed station. To set
to a busy or clear status to all stations, the Type 1 URR/URNR command is utilized.

5.3.4.2.3.4 Type 4 operations.

The Type 4 control field is a 16-bit pattern for U PDUs and S PDUs, and includes identification
numbers. The control field distinguishes between a DIA PDU with a frame identification
number and four S PDUs used in a connectionless environment with decoupled
acknowledgments. The Type 1 URR and URNR are used to indicate overall station status. The
DRR and Decoupled Receive Not Ready (DRNR) PDUs are used to indicate station status for
Type 4 operations only.

5.3.4.2.3.5 Poll/Final (P/F) bit.

The P/F bit serves a function in both command and response PDUs. In command PDUs, the P/F
bit is referred to as the P-bit. In response PDUs, it is referred to as the F-bit. The P-bit set to 1
shall be used to solicit a response PDU, with the F-bit set to 1. On a data link, at most one PDU
with P-bit set to 1 shall be outstanding in a given direction at a given time. Before a station
issues another PDU with the P-bit set to 1 to a particular destination, it shall have received a
response PDU from that remote station with the F-bit set to 1 or have timed out waiting for that
response PDU. The P/F bit is not implemented in Type 4 operations.

5.3.4.2.3.6 Sequence numbers.

Sequence numbers are used only with Type 2 I and S PDUs. The Type 2 I and S PDUs shall
contain sequence numbers. The sequence numbers shall be in the range of 0-127.

5.3.4.2.3.7 Identification numbers.

Identification numbers are used only with Type 4 DIA PDUs and DRR/DRNR S PDUs. The
Type 4 DIA and DRR/DRNR response S PDUs shall contain an identification number. The
identification number is used to identify each DIA PDU and permit decoupled acknowledgments
in a connectionless environment. The identification numbers shall be in the range of 1-255. The
identification number of an S PDU command (bits 9-16) shall be filled with zeroes.

5.3.4.2.3.8 Precedence.
The two level-of-precedence bits (L-bits) are used only in the control field of Type 4 PDUs. In
the DIA PDU, the L-bits indicate the precedence of the data in the information field. In the DRR
response S PDU, the L-bits are used to indicate the precedence of the DIA PDU information
being acknowledged. The data link precedence values and their appropriate mappings to
network layer precedence levels are indicated in 5.3.16.

49
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.4.2.4 Information field.

The information field may be present in either the I, UI, DIA, FRMR or TEST PDU. The length
of the information field shall be a multiple of 8 bits, not to exceed 3345 octets. If the data is not
a multiple of 8 bits, 1 to 7 fill bits (0) shall be added to meet this requirement. The maximum
information field size defaults to 3345 octets. A smaller size may be established at initialization
through local system information or using the exchange network parameters (XNP) messages
(see APPENDIX E). Contents of the information fields of the FRMR, TEST command and
TEST response PDUs are described in 5.3.6.2.3.6, 5.3.6.1.6, and 5.3.6.1.7, respectively.

5.3.4.2.5 Frame Check Sequence (FCS).

For error detection, all frames shall include a 32-bit FCS prior to the closing flag sequence. The
contents of the address, control, and information fields are included in the FCS calculation.
Excluded from the FCS calculation are the 0’s inserted by the 0-bit insertion algorithm. The
formula for calculating the FCS, which is the 1’s complement (inversion) of the remainder of a
modulo-2 division process, employs the generator polynomial, P(X), having the form

P(x) = x32 +x26 +x23 +x22 +x16 +x12 +x11 +x10 +x8 +x7 +x5 +x4 +x2 +x +1

FCS generation shall be in accordance with the paragraph entitled “32-bit Frame Checking
Sequence” in ISO 3309, and implemented in a manner that provides a unique remainder when a
frame is received without bit errors incurred during transmission. (Note: When the FCS is
implemented via a 32-bit shift register, the shift register shall be initialized to all ones before
checking or calculation of the FCS). If the FCS of a received frame proves the frame to be
invalid, the frame shall be discarded.

5.3.4.3 Data Link PDU construction.

The data link procedures that affect data link PDU construction include (a) order-of-bit
transmission and 0-bit insertion, discussed below; and (b) FEC and TDC, discussed in 5.3.14.

5.3.4.3.1 Order-of-bit-transmission.
The order-of-bit-transmission function specifies the sequence in which bits are ordered by the
data link layer for transmission by the PL. The Information Field and control field(s) shall be
transmitted LSB of each octet first. The flag shall be transmitted LSB first. For the FCS, the
most significant bit (MSB) shall be transmitted first.

For the address field, the source address octet is transmitted first and the destination address
octet(s) are transmitted in order. For four octets addressing, the single octet 32-bit marker shall
be transmitted first and the actual four octets link layer address shall be transmitted in the most
significant to least significant octet order (Example: dot notation address 111.122.133.144, the
most significant octet 111 is transmitted first, then 122, 133, 144 order). The LSB of each
address octet is transmitted first. The information field octets shall be transmitted in the same
order as received from the upper layers, LSB of each octet first.

50
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.4.3.2 Zero-bit insertion algorithm.

The occurrence of a spurious flag sequence within a frame or Transmission Header shall be
prevented by employing a 0-bit insertion algorithm. After the entire frame has been constructed,
the transmitter shall always insert a 0 bit after the appearance of five 1’s in the frame (with the
exception of the flag fields). After detection of an opening flag sequence, the receiver shall
search for a pattern of five 1’s. When the pattern of five 1’s appears, the sixth bit shall be
examined. If the sixth bit is a 0, the 5 bits shall be passed as data, and the 0 shall be deleted. If
the sixth bit is a 1, the receiver shall inspect the seventh bit. If the seventh bit is a 0, a flag
sequence has been received. If the seventh bit is a 1, an invalid message has been received and
shall be discarded.

5.3.5 Operational parameters.

The various parameters associated with the control field formats are described in the following
sections.

5.3.5.1 Type 1 operational parameters.

5.3.6.1 Type 1 operation commands and indications.

Type 1 commands and indications are all U PDUs. The U PDU encodings for Type 1 operations
are listed in FIGURE 16.

FIRST CONTROL FIELD BIT DELIVERED TO/RECEIVED FROM THE PHYSICAL LAYER
↓
LSB MSB
1 2 3 4 5 6 7 8 Bit Position
1 1 0 0 0 0 0 0 UI Command
1 1 0 0 0 1 0 0 URR Command

1 1 0 1 0 0 0 0 URNR Command
1 1 0 0 0 0 0 1 Topology Update ID Indication
1 1 0 0 0 0 1 1 Version CANTPRO Indication

1 1 0 0 0 1 1 1 Test Command/Response

FIGURE 16. Type 1 operation control-field bit assignments.

5.3.6.1.1 Unnumbered Information (UI) command.

The UI PDU shall be used to send information to one or more stations. The P-bit of the control
field of the UI PDU shall be set to 0 by the transmitter to specify that an acknowledgment is not
required. The UI PDU shall be addressed to unicast, special or multicast (One-hop or group)
addresses. The source address shall be the unicast address of the transmitting station.

5.3.6.1.2 Unnumbered Receive-Ready (URR) command.

The Type 1 URR command PDU, with P-bit set to 0, shall be transmitted to one or more stations
to indicate that the sending station is ready to receive I, DIA and UI PDUs. The URR PDU shall
be addressed to unicast or multicast (One-hop or group) addresses. The source address shall be
the unicast address of the transmitting station. The use of this command clears the busy status of
the transmitting station for Type 1, Type 2, Type 3 and Type 4 operations.

5.3.6.1.3 Unnumbered Receive-Not-Ready (URNR) command.

The Type 1 URNR command PDU, with P-bit set to 0, shall be transmitted to one or more
stations to indicate that the sending station is busy and cannot receive I, DIA or UI PDUs. The
URNR PDU shall be addressed to unicast or multicast (One-hop or group) addresses. The
source address shall be the unicast address of the transmitting station. The use of this command
indicates that the transmitting station is busy and can not receive Type 1, Type 2, Type 3 or Type
4 PDUs.

55
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.6.1.4 Topology Update ID indication.

The Type 1 Topology Update ID indication PDU, with P-bit set to 0, shall be periodically
transmitted to the One-hop multicast address (single octet 127) to indicate the most recent
Topology Update ID in accordance with APPENDIX H (see H.4.4.3), if and only if Topology
Updates are used (see 5.4.1.2). If no Topology Updates have been issued on the current
network, this PDU shall not be transmitted.

5.3.6.1.5 Version CANTPRO indication.

The Type 1 Version CANTPRO indication PDU, with P-bit set to 0, shall be transmitted to a
single station upon receipt of an incoming PDU with an unsupported MIL-STD-188-220 Version
indicated in the subfield of the received Transmission Information header field. The PDU shall
be transmitted to the station indicated in the originator address of the received PDU with the
unsupported Version subfield. The “C” bits of the PDU Control field (see FIGURE 15) shall
contain the received unsupported Version subfield. The “P” bits of the PDU Control field (see
FIGURE 15) shall contain the Preferred Version for future communications. The Preferred
Version should be consistent with the Version used to populate the MIL-STD-188-220 Version
subfield of the Transmission Information header for transmitted messages (see 5.3.1.2). The
action taken upon receiving a Version CANTPRO indication PDU will be determined by each
individual system.

5.3.6.1.6 Test (TEST) command.

The TEST command shall be used to cause the destination station to respond with the TEST
response at the earliest opportunity, thus performing a basic test of the transmission path. An
information field is optional with the TEST command PDU. It may contain any bit pattern, but
is limited to a maximum length of 128 octets. If present, however, the received information field
shall be returned, if possible, by the addressed station in the TEST response PDU. The Type 1
TEST command, with the P-bit set to 0, shall cause each destination station (including members
of multicast (One-hop or group) addresses) to respond with a TEST response (with information
field) with the F-bit set to 0 at the earliest opportunity. The TEST command PDU shall be
addressed to a unicast and/or multicast (One-hop or group) destination addresses. The source
address shall be an unicast address.

5.3.6.1.7 Test (TEST) response.

The Type 1 TEST response, with F-bit set to 0, shall be used by all addressees (unicast, group
multicast and One-hop multicast) to reply to the TEST command with the P-bit set to 0 at the
earliest opportunity. If an information field was present in the TEST command PDU that had the
P-bit set to 0, the TEST response PDU shall contain the same information field contents. If the
station cannot accept the information field of the TEST command, a TEST response without an
information field may be returned. The source and destination addresses shall be a unicast
address.

5.3.6.2 Type 2 operation commands and responses.

Type 2 commands and responses consist of I, S, and U PDUs.

56
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.6.2.1 Information-transfer-format command and response.

The function of the information (I) command and response shall be to transfer sequentially
numbered PDUs that contain an information field across a data link connection. N(S) and N(R)
associated with multicast (One-hop or group) addresses shall be set to zero by the transmitter and
ignored by the receiver and are not acknowledged. The encoding of the I PDU control field for
Type 2 operation shall be as listed in FIGURE 17.

The I PDU control field shall contain two sequence number subfields: N(S), which shall indicate
the sequence number associated with the I PDU; and N(R), which shall indicate the sequence
number (as of the time the PDU is sent) of the next expected I PDU to be received, and,
consequently, shall indicate that the I PDUs numbered up through N(R)-1 have been received
correctly.

FIRST CONTROL FIELD BIT DELIVERED TO/RECEIVED FROM THE PHYSICAL LAYER
↓
LSB MSB
1 2345678 9 10 11 12 13 14 15 16
0 N(S) P/F N(R)
INFORMATION SEND SEQUENCE COMMAND (POLL) RECEIVE SEQUENCE
TRANSFER NUMBER (0-127) RESPONSE (FINAL) NUMBER (0-127)
FORMAT

FIGURE 17. Information-transfer-format control field bits.

5.3.6.2.2 Supervisory-format commands and responses.

Supervisory PDUs (S-PDU) shall be used to perform numbered supervisory functions such as
acknowledgments, temporary suspension of information transfer, or error recovery. S PDUs
shall not contain an information field and, therefore, shall not increment the V(S) at the sender or
the V(R) at the receiver. Encoding of the S PDU control field for Type 2 operation shall be as
shown in FIGURE 18. An S PDU shall contain an N(R), which shall indicate, at the time of
sending, the sequence number of the next expected I PDU to be received. This shall
acknowledge that all I PDUs numbered up through N(R)-1 have been received correctly, except
in the case of the selective reject (SREJ) PDU. The use of N(R) in the SREJ PDU is explained in
5.3.6.2.2.4 and 5.3.7.2.5.4.2.

FIRST CONTROL FIELD BIT DELIVERED TO/RECEIVED FROM THE PHYSICAL LAYER
↓
LSB MSB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1 0 S S X X X X P/F N(R)
\-----------------------/ \------------------------/
↓ ↓ ↓ ↓ ↓
SUPER- RESERVED COMMAND (POLL) RECEIVE SEQUENCE
VISORY SET TO 0 RESPONSE (FINAL) NUMBER (0-127)

57
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

FORMAT

S S COMMANDS/RESPONSES
00 (value 0) RECEIVE READY (RR)
10 (value 1) RECEIVE NOT READY (RNR)
01 (value 2) REJECT (REJ)
11 (value 3) SELECTIVE REJECT (SREJ)

FIGURE 18. Supervisory-format control field bits.

5.3.6.2.2.1 Receive-Ready (RR) command and response.

The RR PDU shall be used by a station to indicate it is ready to receive I PDUs and only I PDUs.
It does not clear busy conditions associated with URNR or DRNR. I PDUs numbered up
through N(R)-1 shall be considered as acknowledged. When the RR command or response is
transmitted using the multicast (One-hop or group) address, the receive sequence number in the
control field associated with that multicast (One-hop or group) address shall be set to “0”; and
the P/F bit shall be set to “0”. If the RR PDU is mixed with unicast and multicast (One-hop or
group) addresses, each destination address (unicast and multicast (One-hop or group)) shall have
a control field associated with that address (e.g., if the destination address consists of 3 unicast
addresses and the multicast (One-hop or group) address, there will be 4 control fields).

5.3.6.2.2.2 Reject (REJ) command and response.

The REJ PDU shall be used by a station to request the resending of I PDUs, starting with the
PDU numbered N(R). I PDUs numbered up through N(R)-1 shall be considered as
acknowledged. It shall be possible to send additional I PDUs awaiting initial sending after the
resent I PDUs. With respect to each direction of sending on a data link connection, only one
“sent REJ” condition shall be established at any given time. The “sent REJ” condition shall be
cleared upon receipt of an I PDU with an N(S) equal to the N(R) of the REJ PDU. The “sent
REJ” condition may be reset in accordance with procedures described in 5.3.7.2.5.4. Receipt of
a REJ PDU shall indicate the clearance of a busy condition except as noted in 5.3.7.2.5.8.

5.3.6.2.2.3 Receive-Not-Ready (RNR) command and response.

The RNR PDU shall be used by a station to indicate a busy condition (a temporary inability to
accept subsequent Type 2 I PDUs). I PDUs numbered up through N(R)-1 shall be considered as
acknowledged. I PDUs numbered N(R) and any subsequent I PDUs received shall not be
considered as acknowledged; the acceptance status of these PDUs shall be indicated in
subsequent exchanges. When the RNR command or response is transmitted using the multicast
(One-hop or group) address, the receive sequence number in the control field associated with
that multicast (One-hop or group) address shall be set to “0”; and the P/F bit shall be set to “0”.
If the RNR PDU is mixed with unicast and multicast (One-hop or group) each destination
address (individual, group and global) shall have a separate control field associated with that
address.

58
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.6.2.2.4 Selective-Reject (SREJ) command and response.

The SREJ PDU is used by a station to request retransmission of the single I PDU numbered
N(R). If the P/F-bit in the SREJ PDU is set to 1, then I PDUs numbered up to N(R)-1 shall be
considered acknowledged. If the P/F-bit is set to 0, then the N(R) of the SREJ PDU does not
indicate acknowledgment of any I PDUs. Each SREJ exception condition shall be cleared (reset)
upon receipt of an I PDU with an N(S) equal to the N(R) of the SREJ PDU. A data station may
transmit one or more SREJ PDUs, each containing a different N(R) with the P/F-bit set to 0,
before one or more earlier SREJ exception conditions have been cleared. I PDUs that have been
transmitted following the I PDU designated by the SREJ PDU shall not be retransmitted as the
result of receiving the SREJ PDU. Additional I PDUs awaiting initial transmission may be
transmitted following the retransmission of the specific I PDU requested by the SREJ PDU. The
SREJ is used to recover from receipt of frames with various types of errors, including sequence
number errors due to lost frames and FCS errors.

5.3.6.2.3 Unnumbered-format commands and responses.

Unnumbered PDUs (U-PDU) shall be used in Type 2 operations to extend the number of data
link connection control functions. The U PDUs shall not increment the state variables on the data
link connection at either the sending or the receiving station. Encoding of the U PDU control
field shall be as in FIGURE 19.

FIRST CONTROL FIELD BIT DELIVERED TO/RECEIVED FROM THE PHYSICAL LAYER
↓
LSB MSB
1 2 3 4 5 6 7 8
1 1 1 1 P 1 0 0 SABME Command
1 1 0 0 P 0 1 0 DISC Command
1 1 1 1 P 0 0 1 RSET Command
1 1 0 0 F 1 1 0 UA Response
1 1 1 1 F 0 0 0 DM Response
1 1 1 0 F 0 0 1 FRMR Response

FIGURE 19. Unnumbered-format control field bits.

5.3.6.2.3.1 Set Asynchronous Balanced Mode Extended (SABME) command.

The SABME command PDU shall be used to establish a data link connection to the destination
station in the ABM. No information shall be permitted with the SABME command PDU. The
destination station shall confirm receipt of the SABME command PDU by sending a UA
response PDU on that data link connection at the earliest opportunity. Upon acceptance of the
SABME command PDU, the destination station V(S)s and V(R)s shall be set to 0. If the UA
response PDU is received correctly, then the initiating station shall also assume the ABM with
its corresponding V(S)s and V(R)s set to 0. Previously sent I PDUs that are unacknowledged
when this command is executed shall remain unacknowledged. A station may resend the

59
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

contents of the information field of unacknowledged outstanding I PDUs. The term

“asynchronous” in this command does not necessarily imply the use of “asynchronous mode” as
described in 5.2.1 Physical-layer Protocol Data Unit (PDU).

5.3.6.2.3.2 Disconnect (DISC) command.

The DISC command PDU shall be used to terminate an ABM previously set by a SABME
command PDU. It shall be used to inform the destination station that the source station is
suspending operation of the data link connection and the destination station should assume the
logically disconnected mode. No information field shall be permitted with the DISC command
PDU. Prior to executing the command, the destination station shall confirm the acceptance of
the DISC command PDU by sending a UA response PDU on that data link connection.
Previously sent I PDUs that are unacknowledged when this command is executed shall remain
unacknowledged.

5.3.6.2.3.3 Reset (RSET) command.

The RSET command PDU shall be used by a station in an operational mode to reset the V(R) in
the addressed station. No information field shall be permitted with the RSET command PDU.
The addressed station shall confirm acceptance of the RSET command by transmitting a UA
response PDU at the earliest opportunity. Upon acceptance of this command, the V(R) of the
addressed station shall be set to 0. If the UA response PDU is received correctly, the initializing
station shall reset its V(S) to 0.

5.3.6.2.3.4 Unnumbered Acknowledgment (UA) response.

The UA response PDU shall be used by a station on a data link connection to acknowledge
receipt and acceptance of the SABME, DISC, and RSET command PDUs. These received
command PDUs shall not be executed until the UA response PDU is sent. No information field
shall be permitted with the UA response PDU.

5.3.6.2.3.5 Disconnect Mode (DM) response.

The DM response PDU shall be used to report status indicating that the station is logically
disconnected from the data link connection and is in asynchronous disconnected mode (ADM).
No information field shall be permitted with the DM response PDU.

5.3.6.2.3.6 Frame Reject (FRMR) response.

The FRMR response PDU shall be used by the station in the ABM to report that one of the
following conditions, which is not correctable by resending the identical PDU, resulted from the
receipt of a PDU from the remote station:

a. The receipt of a command PDU or a response PDU that is invalid or not implemented.
Below are three examples of invalid PDUs:

(1) the receipt of an S or U PDU with an information field that is not permitted,

(2) the receipt of an unsolicited F-bit set to 1, and

60
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

(3) the receipt of an unexpected UA response PDU.

b. The receipt of an I PDU with an information field that exceeded the established
maximum information field length that can be accommodated by the receiving station for that
data link connection.

c. The receipt of an invalid N(R) from the remote station. An invalid N(R) shall be
defined as one that signifies an I PDU that has previously been sent and acknowledged, or one
that signifies an I PDU that has not been sent and is not the next sequential I PDU waiting to be
sent.

d. The receipt of an invalid N(S) from the remote station. An invalid N(S) shall be defined
as an N(S) that is greater than or equal to the last sent N(R)+ k, where k is the maximum number
of outstanding I PDUs. The parameter k is the window size indicated in the XNP message (see
APPENDIX E).

The responding station shall send the FRMR response PDU at the earliest opportunity. An
information field shall be returned with the FRMR response PDU to provide the reason for the
PDU rejection. The information field shall contain the fields shown in FIGURE 20. The station
receiving the FRMR response PDU shall be responsible for initiating the appropriate mode
setting or resetting corrective action by initializing one or both directions of transmission on the
data link connection, using the SABME, RSET or DISC command PDUs, as applicable.

FIRST CONTROL BIT DELIVERED TO/RECEIVED FROM THE PHYSICAL LAYER

↓
LSB MSB
1--------------16 17 18-----24 25 26-----32 33--36 37--40
REJECTED PDU 0 V(S) C/R V(R) WXYZ V000
CONTROL FIELD

Notes to FIGURE 20:

a. Rejected PDU control field shall be the control field of the received PDU that caused the FRMR
exception condition on the data link connection. When the rejected PDU is a U PDU, the control
field of the rejected PDU shall be positioned in bit positions 1-8, with 9-16 set to 0.
b. V(S) shall be the current send-state variable value for this data link connection at the rejecting
station (bit 18 = low-order bit).
c. C/R set to 1 shall indicate that the PDU causing the FRMR was a response PDU, and C/R set to 0
shall indicate that the PDU causing the FRMR was a command PDU.
d. V(R) shall be the current receive-state variable value for this data link connection at the rejecting
station (bit 26 = low-order bit).
e. W set to 1 shall indicate that the control field received and returned in bits 1 through 16 was invalid
or not implemented. Examples of invalid PDU are defined as:

61
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

i. the receipt of an S or U PDU with an information field that is not permitted,

ii. the receipt of an unsolicited F-bit set to 1, and
iii. the receipt of an unexpected UA response PDU.
f. X set to 1 shall indicate that the control field received and returned in bits 1 through 16 was
considered invalid because the PDU contained an information field that is not permitted with this
command or response. Bit W shall be set to 1 in conjunction with this bit.
g. Y set to 1 shall indicate that the information field received exceeded the established maximum
information field length which can be accommodated by the rejecting station on that data link
connection.
h. Z set to 1 shall indicate that the control field received and returned in bits 1 through 16 contained an
invalid N(R).
i. V set to 1 shall indicate that the control field received and returned in bits 1 through 16 contained an
invalid N(S). Bit W shall be set to 1 in conjunction with this bit.

FIGURE 20. FRMR information field format.

5.3.6.3 Type 3 operation commands and responses.

Type 3 commands and responses are all U PDUs. The U PDU encodings for Type 3 operations
are listed in FIGURE 21.

FIRST CONTROL FIELD BIT DELIVERED TO/RECEIVED FROM THE PHYSICAL LAYER
↓
LSB MSB
1 2 3 4 5 6 7 8 Bit Position
1 1 0 0 1 0 0 0 UI Command
1 1 0 0 1 1 0 0 URR Response
1 1 0 1 1 0 0 0 URNR Response
1 1 0 0 1 1 1 1 Test Command/Response

FIGURE 21. Type 3 operation control-field bit assignments.

5.3.6.3.1 Unnumbered Information (UI) command.

The UI PDU shall be used to send information to one or more stations. The P-bit of the control
field of the UI PDU is used by the transmitter to request that the unicast addressed receiver(s)
acknowledge receipt of the transmitted UI PDU. The UI PDU shall be addressed to unicast,
special or multicast (One-hop or group) addresses. The source address shall be the unicast
address of the transmitting station.

5.3.6.3.2 Unnumbered Receive-Ready (URR) response.

The URR response shall be used to acknowledge a Type 3 UI command. The URR response
shall be the first PDU sent by the receiving station upon receiving a UI command after the
appropriate RHD period (see C.4.2). The source and destination shall be unicast addresses.

62
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.6.3.3 Unnumbered receive-not-ready (URNR) response.

The URNR response PDU shall be used to reply to a Type 3 UI command if the UI command
cannot be processed due to a busy condition. The URNR response PDU does not contain any
acknowledgment information. If used, the URNR response shall be the first PDU transmitted by
the receiving station, upon receiving a UI command, after the appropriate RHD period (see
C.4.2). The URNR response shall have the F-bit set to 1 and shall be addressed to the source of
the UI command.

5.3.6.3.4 Test (TEST) command.

The TEST command shall be used to cause the destination station to respond with the TEST
response at the earliest opportunity, thus performing a basic test of the transmission path. An
information field is optional with the TEST command PDU. It may contain any bit pattern, but
is limited to a maximum length of 128 octets. If present, however, the received information field
shall be returned, if possible, by the addressed station in the TEST response PDU. The Type 3
TEST command, with the P-bit set to 1, shall cause the unicast addressed destination station(s) to
respond with a TEST response PDU (with no information field), with the F-bit set to 1, after the
appropriate RHD period (see C.4.2). Multicast (One-hop or group) addressees do not reply to a
TEST command with the P-bit set to 1. The TEST command PDU shall be addressed to a
unicast and/or multicast (One-hop or group) destination addresses. The source address shall be a
unicast address.

5.3.6.3.5 Test (TEST) response.

The TEST response, with F-bit set to 1, without an information field shall be used by unicast
addressees to reply to the TEST command with the P-bit set to 1. The TEST response shall be
the first PDU sent by the receiving station upon receiving a TEST command PDU, after the
appropriate RHD period (see C.4.2). Multicast (One-hop or group) addressees do not reply to
TEST command with P-bit set to 1. If the station cannot accept the information field of the
TEST command, a TEST response without an information field may be returned. The source
and destination addresses shall be a unicast address.

5.3.6.4 Type 4 operation commands and responses.

The Type 4 commands and responses consist of U and S PDUs.

5.3.6.4.1 Unnumbered Information transfer format command.

The function of the Type 4 DIA commands shall be to transfer PDUs that contain an
identification number and an information field across a connectionless link. The encoding of the
PDU control field for Type 4 operation shall be as listed in FIGURE 22.

63
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

FIRST CONTROL BIT DELIVERED TO/RECEIVED FROM THE PHYSICAL LAYER

↓
LSB MSB
PDU Identifier L-bits PDU Identification No.
123456 78 9 10 11 12 13 14 15 16
110101 LL <---ID Number--->

FIGURE 22. Type 4 DIA PDU control field bit assignments.

5.3.6.4.1.1 DIA PDU acknowledgment.

Transmitted DIA PDUs are acknowledged by a Type 4 DRR response S PDU with the same
precedence from the receiving stations, except for the following cases:

a. The receiving station is a multicast (One-hop or group) addressee only.

b. The receiving station’s link address is not in the destination address field.

c. The response mode parameter is set to no.

5.3.6.4.2 Supervisory-format commands and responses.

Supervisory PDUs (S PDU) shall be used to convey link acknowledgment of a DIA PDU and
whether or not a station is ready to receive Type 4 PDUs. The S PDU command has 1-16
destination addresses. The S PDU response has a single destination address. The command
DRR and DRNR S PDUs do not acknowledge DIA PDUs. These S PDUs are used to indicate
Type 4 receive status. The response DRR S PDU contains a single destination address, that of
the originator of the DIA PDU being acknowledged. The command S PDU level of precedence
shall be set to the highest precedence while response S PDUs shall use the precedence of the
DIA PDU which they are acknowledging. The encoding of the S PDU control field for Type 4
operation shall be as listed in FIGURE 23. The Type 4 DRR command PDU shall be transmitted
to one or more stations to indicate that the sending station is ready to receive DIA PDUs. The
DRR PDU shall be addressed to unicast or multicast (One-hop or group) addresses. The source
address shall be the unicast address of the transmitting station. The use of this command clears
the busy status of the transmitting station for Type 4 operations only.

64
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

FIRST CONTROL BIT DELIVERED TO/RECEIVED FROM THE PHYSICAL LAYER

↓
LSB MSB
PDU Identifier L-bits PDU Identification No.
123456 78 9 10 11 12 13 14 15 16
100010 00 0 0 0 0 0 0 0 0
DRR Command
100010 LL <---ID Number--->
DRR Response
101010 00 0 0 0 0 0 0 0 0
DRNR Command
101010 LL <---ID Number--->
DRNR Response

FIGURE 23. Type 4 S PDU control field bit assignments.

5.3.7 Description of procedures by type.

The procedures for each operation type are described in 5.3.7.1, 5.3.7.2, 5.3.7.3, and 5.3.7.4 (and
their subparagraphs). The four types of procedures can coexist on the same network.

5.3.7.1 Description of Type 1 procedures.

The procedures associated with Type 1 operation are described in 5.3.7.1 and all subparagraphs.

Note: All stations must implement both Type 1 and Type 3 communications. Status of stations
on the network, maintained by sending and receiving URR and URNR PDUs, shall be
collaborated between Type 1 and Type 3 operations. For example, if a platform receives a Type
3 URNR Response from a station, that station should be considered busy for both Type 1 and
Type 3 communications until a Type 1 URR Command is received by the platform. This applies
to all URR Commands, URNR Commands, and URNR Responses.

5.3.7.1.1 Modes of operation.

In Type 1 operation, no modes of operation are defined. A station using Type 1 procedures shall
support the entire procedure set described in the following paragraphs, whenever it is operational
on the network.

5.3.7.1.2 Procedure for addressing.

65
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

shall be supported for destination addresses in command PDUs. The source address field shall
contain a unicast or special address.

5.3.7.1.3 Procedure for using the P/F bit.

For Type 1 operation, the transmitting station shall always set the P-bit equal to 0.

5.3.7.1.4 Procedures for logical data link set-up and disconnection.

Type 1 operation does not require any prior data link connection establishment (set-up), and
hence no data link disconnection. Once the service access point has been enabled within the
station, information may be sent to, or received from, a remote station also participating in Type
1 operation.

5.3.7.1.5 Procedures for information transfer.

5.3.7.1.5.1 Sending UI command PDUs.

Information transfer from an initiating station to a responding station shall be accomplished by
sending the UI command PDU with the P-bit set to 0. Transmission of UI commands to stations
detected as busy (due to receipt of a URNR Command or Response) shall be discontinued until
the busy state is cleared. UI PDUs that have the P-bit set to 0 are not acknowledged nor
retransmitted.

5.3.7.1.5.2 Receiving UI command PDUs.

Reception of the UI command PDU with P-bit set to 0 shall not be acknowledged.

5.3.7.1.5.3 Sending URNR command PDUs.

A URNR command PDU, with the P-bit set to 0, may be sent at any time to indicate a busy
condition.

5.3.7.1.5.4 Receiving URNR command PDUs.

Receipt of the URNR indicates that the sending station is busy and, with one exception described
below, no additional I, UI or DIA PDUs should be sent until the sending station regains its
ability to receive messages. The URNR command PDU does not contain any acknowledgment
information.

Exception: A Station may include a busy destination in a PDU that is addressed to multiple
destination addresses if at least one of the multiple destinations is not busy.

5.3.7.1.5.5 Sending URR command PDUs.

A URR command PDU, with the P-bit set to 0, may be sent by a station at any time to indicate
the regaining of its ability to receive messages.

5.3.7.1.5.6 Receiving URR command PDUs.

The receipt of the URR command PDU cancels the prior receipt of a URNR and indicates that
the sending station is now operational.

66
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.7.1.5.7 Using TEST command and response PDUs.

The TEST function provides a facility to conduct loop-back tests of the station-to-station
transmission path. The TEST function may be initiated within the data link layer by any
authorized station within the data link layer. Successful completion of a test started by sending a
TEST command PDU with the P-bit set to 0 consists of receiving a TEST response PDU with the
F-bit set to 0 and containing the identical data from each unicast or multicast (One-hop or group)
addressee. The length of the information field is variable from 0 to 128 octets. Any TEST
command PDU received in error shall be discarded and no response PDU sent. In the event of a
test failure, it shall be the responsibility of the TEST function initiator to determine any future
actions.

5.3.7.2 Description of Type 2 procedures.

The procedures associated with Type 2 operation are described in 5.3.7.2.1 through 5.3.7.2.8.

5.3.7.2.1 Modes of operation.

Two modes of operation are defined for Type 2 operation: an operational mode and a non-
operational mode.

5.3.7.2.1.1 Operational mode.

The operational mode shall be the ABM. ABM is a balanced operational mode in which a data
link connection has been established between two stations. Either station shall be able to send
commands at any time and initiate response transmissions without receiving explicit permission
from the other station. Such a transmission shall contain one or more PDUs that shall be used
for information transfer and to indicate status changes in the station (for example, the number of
the next expected I PDU; transition from a ready to a busy condition, or vice versa; occurrence
of an exception condition). A station in ABM receiving a DISC command PDU shall respond
with the UA response PDU if it is capable of executing the command. ABM consists of a data
link connection phase, an information transfer phase, a data link resetting phase, and a data link
disconnection phase.

5.3.7.2.1.2 Non-operational mode.

The non-operational mode shall be the ADM. ADM differs from ABM in that the data link
connection is logically disconnected from the physical medium such that no information (user
data) shall be sent or accepted. ADM is defined to prevent a data link connection from
appearing on the physical medium in a fully operational mode during unusual situations or
exception conditions. Such operation could cause a sequence number mismatch between stations
or a station’s uncertainty of the status of the other station. A data link connection shall be
system-predefined as to the conditions that cause it to assume ADM. Below are three examples
of possible conditions, in addition to receiving a DISC command PDU, that may cause a data
link connection to enter ADM:

a. The power is turned on,

b. The data link layer logic is manually reset, or

67
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

c. The data link connection is manually switched from a local (home) condition to the
connected-on-the-data-link (on-line) condition.

A station on a data link connection in ADM shall be required to monitor transmissions received
from its PL to accept and respond to one of the mode-setting command PDUs (SABME, DISC),
or to send a DM response PDU at a medium access opportunity, when required. In addition,
since the station has the ability to send command PDUs at any time, the station may send an
appropriate mode-setting command PDU. A station in ADM receiving a DISC command PDU
or any I or S PDU shall respond with the DM response PDU. A station in ADM shall not
establish a FRMR exception condition. ADM consists of a data link disconnected phase.

5.3.7.2.2 Procedure for addressing.

The address fields for a PDU shall be used to indicate the unicast source and up to 16
destinations. The first bit in the source address field shall be used to identify whether a
command or response is contained in the PDU. A single data link connection can be established
between any two stations on the network.

5.3.7.2.3 Procedures for using the P/F bit.

A unicast addressed station receiving a command PDU (SABME, DISC, RR, RNR, REJ, or I)
with the P-bit set to 1 shall send a response PDU with the F-bit set to 1. The response PDU
returned by a station to a RSET, SABME or DISC command PDU with the P-bit set to 1 shall be
a UA or DM response PDU with the F-bit set to 1. The response PDU returned by a station to an
I, RR, or REJ command PDU with the P-bit set to 1 shall be an I, RR, REJ, RNR, DM, or FRMR
response PDU with the F-bit set to 1. The response PDU returned by a station to an RNR
command PDU with the P-bit set to 1 shall be an RR, REJ, RNR, DM, or FRMR response PDU
with the F-bit set to 1. The response PDU returned by a station to a SREJ with the P-bit set to
one shall be the requested I PDU (response) with the F-bit set to one.

NOTE: The P-bit is usable by the station in conjunction with the timer recovery condition. (See
5.3.7.2.5.11)

5.3.7.2.4 Procedures for logical data link set-up and disconnection.

5.3.7.2.4.1 Data Link connection phase.

Either station shall be able to take the initiative to initialize the data link connection.

5.3.7.2.4.1.1 Initiator action.

When the station wishes to initialize the link, it shall send the SABME command PDU to one or
more unicast addresses and start the acknowledgment timer(s). Upon receipt of the UA response
PDU, the station shall reset both the V(S) and V(R) to 0 for the corresponding data link
connection, shall stop the acknowledgment timer and shall enter the information transfer phase.
When receiving the DM response PDU, the station that originated the SABME command PDU
shall stop the acknowledgment timers for that link, shall not enter the information transfer phase
for that station, and shall report to the higher layer for appropriate action. Should any

68
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

acknowledgment timer run out before receiving all UA or DM response PDUs, the station shall
resend the SABME command PDU, after deleting the address and control fields corresponding
to the received UAs or DMs, and restart the acknowledgment timers. After resending the
SABME command PDU N2 times, the station shall stop sending the SABME command PDU,
may report to the higher layer protocol and may initiate other error recovery action. The value of
N2 is defined in 5.3.8.1.3.d. Other Type 2 PDUs received (commands and responses) while
attempting to connect shall be ignored by the station.

5.3.7.2.4.1.2 Respondent action.

When a SABME command PDU is received, and the connection is desired, the station shall
return a UA response PDU to the remote station, set both the V(S) and V(R) to 0 for the
corresponding data link connection, and enter the information transfer phase. The return of the
UA response PDU shall take precedence over any other response PDU that may be pending at
the station for that data link connection. It shall be possible to follow the UA response PDU
with additional PDUs, if pending. If the connection is not desired, the station shall return a DM
response PDU to the remote station and remain in the link disconnected mode. For a description
of the actions to be followed upon receipt of a SABME or DISC command PDU, see 5.3.7.2.4.4.

5.3.7.2.4.2 Information transfer phase.

After having sent the UA response PDU to an SABME command PDU or having received the
UA response PDU to a sent SABME command PDU, the station shall accept and send I and S
PDUs according to the procedures described in 5.3.7.2.5. Any time a station has established a
connection and enters the information transfer phase, it should also send a DL-Status Indication
to its local upper layer indicating a Type 2 connection has been established. When receiving an
SABME command PDU while in the information transfer phase, the station shall conform to the
resetting procedure described in 5.3.7.2.6. When receiving an RSET command PDU while in the
information transfer phase, the station shall conform to the resetting procedure described in
5.3.7.2.7.

5.3.7.2.4.3 Data Link disconnection phase.

During the information transfer phase, either station shall be able to initiate disconnecting of the
data link connection by sending a DISC command PDU and starting the acknowledgment
timer(see 5.3.8.1.3.a). When receiving a DISC command PDU, the station shall return a UA
response PDU and enter the Data Link disconnected phase. The return of the UA response PDU
shall take precedence over any other response PDU that may be pending at the station for that
data link connection. Upon receipt of the UA or DM response PDU from a remote station, the
station shall stop its acknowledgment timer for that link, and enter the link disconnected mode.
Should the acknowledgment timer run out before receiving the UA or DM response PDU for a
particular link, the station shall send another DISC command PDU and restart the
acknowledgment timer. After sending the DISC command PDU N2 times, the sending station
shall stop sending the DISC command PDU, shall enter the data link disconnected phase, and
shall report to the higher layer for the appropriate error recovery action. The value of N2 is
defined in 5.3.8.1.3.d.

69
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.7.2.4.4 Data Link disconnected phase.

After having received a DISC command PDU from the remote station and returned a UA
response PDU, or having received the UA response PDU to a sent DISC command PDU, the
station shall enter the Data Link disconnected phase. In the disconnected phase, the station shall
react to the receipt of an SABME command PDU, as described in 5.3.7.2.4.1, and shall send a
DM response PDU in answer to a received DISC command PDU. When receiving any other
Type 2 command, I or S PDU, the station in the disconnected phase shall send a DM response
PDU. In the disconnected phase, the station shall be able to initiate a Data Link connection.
Any time a station enters the disconnected phase, it should send a DL-Status Indication to its
local upper layer indicating a Type 2 connection has been disconnected.

5.3.7.2.4.5 Contention of unnumbered mode-setting command PDUs.

A contention situation on a data link connection shall be resolved in the following way: If the
sent and received mode- setting command PDUs are the same, each station shall send the UA
response PDU at the earliest opportunity. Each station shall enter the indicated phase either after
receiving the UA response PDU, or after its acknowledgment timer expires. If the sent and
received mode-setting command PDUs are different, each station shall enter the data link
disconnected phase and shall issue a DM response PDU at the earliest opportunity.

5.3.7.2.5 Procedures for information transfer.

The procedures that apply to the transfer of I PDUs in each direction on a data link connection
during the information transfer phase are described in 5.3.7.2.5.1 through 5.3.7.2.5.11. When
used, the term number one higher is in reference to a continuously repeated sequence series, that
is, 127 is 1 higher than 126, and 0 is 1 higher than 127 for the modulo-128 series.

5.3.7.2.5.1 Sending I PDUs.

When the station has an I PDU to send (that is, an I PDU not already sent), it shall send the I
PDU with an N(S) equal to its current V(S) and an N(R) equal to its current V(R) for that data
link connection. At the end of sending the I PDU, the station shall increment its V(S) by 1. If
the acknowledgment timer is not running at the time that an I PDU is sent, the acknowledgment
timer shall be started. If the data link connection V(S) is equal to the last value of N(R) received
plus k (where k is the maximum number of outstanding I PDUs; see 5.3.8.1.3.e), the station shall
not send any new I PDUs on that data link connection, but shall be able to resend an I PDU as
described in 5.3.7.2.5.6 or 5.3.7.2.5.9. Upon sending an I PDU that causes the number of
outstanding I PDUs to be equal to the k2 value for that connection, the station shall send an RR
(or RNR) command to the destination station. The destination station shall respond with a RR
Response with the N(R) indicating the last received I PDU. When a local station on a data link
connection is in the busy condition, the station shall still be able to send I PDUs, provided that
the remote station on this data link connection is not also busy. When the station is in the FRMR
exception condition for a particular data link connection, it shall stop transmitting I PDUs on that
data link connection. When a station is in the timer recovery condition, it shall not send any new
I PDUs on that data link connection as per 5.3.7.2.5.11.

70
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.7.2.5.2 Receiving I PDUs.

When the station is not in a busy condition and receives an I PDU whose N(S) is equal to its
V(R), the station shall accept the information field of this PDU, increment by 1 its V(R), and act
as follows:

a. If an I PDU is available to be sent, the station shall be able to act as in 5.3.7.2.5.1 and
acknowledge the received I PDU by setting N(R) in the control field of the next sent I PDU to
the value of its V(R). The station shall also be able to acknowledge the received I PDU by
sending an RR PDU with the N(R) equal to the value of its V(R).

b. If no I PDU is available to be sent by the station, then the station shall either:

(1) If the received I PDU is a command PDU with the P-bit set to 1, then send an S
PDU with its F-bit set to 1 and its N(R) equal to the current value of V(R) at the first possible
opportunity (this transmission is time critical to maintaining the connection), and stop the
Response Delay Timer; or

(2) If the received I PDU is not a command PDU with the P-bit set to 1, then the station
shall:

(a) If the number of outstanding I PDUs received since the last I PDU for which an
acknowledgment was sent is equal to or greater than k3, then send an S PDU with its N(R) equal
to the current value of V(R) at the earliest opportunity, and stop the Response Delay Timer; else

(b) If the number of outstanding I PDUs received since the last I PDU for which an
acknowledgment was sent is less than k3, and if the Response Delay Timer is not already
running, then start the Response Delay Timer. When the Response Delay Timer is running then
the station shall:

(i) If an I PDU is sent back to the originator of the recently received I PDU
before the Response Delay Timer expires, then stop the Response Delay Timer. The N(R) in the
outgoing I frame will acknowledge any recently received correct in sequence I PDU frames as
described in 5.3.7.2.5.1 (No S PDU needs to be sent); else

(ii) If another PDU of any type that can be concatenated is transmitted to any
destination and adequate space exists to concatenate additional frames, then concatenate onto
this PDU an S PDU with its N(R) equal to the current value of V(R) addressed to the originator
of the recently received I PDU, and stop the Response Delay Timer; else

(iii) If the Response Delay Timer expires, then at the earliest opportunity, send
an S PDU with its N(R) equal to the current value of V(R). (Note that S PDUs to other
destinations may be concatenated with this frame as described in the preceding paragraph.)

c. If receipt of the I PDU caused the station to go into the busy condition with regard to
any subsequent I PDUs, the station shall send an RNR PDU with the N(R) equal to the value of

71
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

its V(R). If I PDUs are available to send, the station shall be able to send them (as in 5.3.7.2.5.1)
prior to or following the sending of the RNR PDU.

When the station is in a busy condition, the station shall be able to ignore the information field
contained in any received I PDU on that data link connection (See 5.3.7.2.5.10.).

5.3.7.2.5.3 Receiving incorrect PDUs.

When the station receives an invalid PDU or a PDU with an incorrect source address, the entire
PDU shall be discarded. If an incorrect destination address is received, disregard that address
field and continue processing the PDU.

5.3.7.2.5.4 Receiving out-of-sequence PDUs.

When the station receives one or more I PDUs whose N(S)s are not in the expected sequence,
that is, not equal to the current V(R) but is within the receive window, the station shall respond
by sending a REJ or a SREJ PDU as described in either 5.3.7.2.5.4.1 or 5.3.7.2.5.4.2. Use of the
SREJ is the preferred method of indicating missing frames since it allows the receiving station to
request the retransmission of only those frames that are actually missing. Use of REJ to indicate
missing frames results in the unnecessary retransmission of frames that were received correctly
since the procedure requires that frames received out of sequence be discarded until the missing
frame is received. Use of REJ to indicate missing frames is intended for use by an
implementation in the case that it is providing ordered delivery of I PDUs to the next layer and
adequate storage is not available (on a static or dynamic basis) within the implementation to
retain out-of-sequence frames until the missing frames are received.

5.3.7.2.5.4.1 Reject (REJ) response.

When an I PDU has been received out-of-sequence and more than one frame is missing, the
station may discard the information field of the I PDU and send a REJ PDU with the N(R) set to
the value of V(R). The station shall then discard the information field of all I PDUs until the
expected I PDU is correctly received. When receiving the expected I PDU, the station shall
acknowledge the PDU, as described in 5.3.7.2.5.2. The station shall use the N(R) and P-bit
indications in the discarded I PDU. On a given data link connection, only one “sent REJ”
exception condition from a given station to another given station shall be established at a time.
A REJ and SREJ exception condition cannot be active at the same time. A “sent REJ” condition
shall be cleared when the requested I PDU is received. The “sent REJ” condition shall be able to
be reset when a REJ timer time-out function runs out. When the station perceives by REJ timer
time-out that the requested I PDU will not be received, because either the requested I PDU or the
REJ PDU was in error or lost, the station shall be able to resend the REJ PDU up to N2 times to
reestablish the “sent REJ” condition. The value of N2 is defined in 5.3.8.1.2.b.

5.3.7.2.5.4.2 Selective Reject (SREJ) response.

When an I PDU has been received and at least one frame is missing, the station may retain the
information field of the out-of-sequence I PDUs and send SREJ PDUs for the missing I PDUs.
A station may transmit one or more SREJ PDUs, each containing a different N(R) with the F-bit
set to 0. However, a SREJ PDU shall not be transmitted if an earlier REJ condition has not been

72
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

cleared. When the station perceives by the REJ timer time-out that the requested I PDU will not
be received, because either the requested I PDU or the SREJ PDU was in error or lost, the station
shall be able to resend all outstanding SREJ PDUs in order to reestablish the “sent SREJ”
condition up to N2 times.

5.3.7.2.5.5 Receiving acknowledgment.

When correctly receiving an I or S PDU, even in the busy condition (see 5.3.7.2.5.10), the
receiving station shall consider the N(R) contained in this PDU as an acknowledgment for all the
I PDUs it has sent on this data link connection with an N(S) up to and including the received
N(R) minus one. The station shall reset the acknowledgment timer when it correctly receives an
I or Type 2 S PDU with the N(R) higher than the last received N(R) (actually acknowledging
some I PDUs). If High Reliability was requested for any of the acknowledged PDU(s), a DL-
Status.Indication should be sent to the upper layer indicating acknowledgment success for those
PDUs. If the timer has been reset and there are outstanding I PDUs still unacknowledged on this
data link connection, the station shall restart the acknowledgment timer. If the timer then runs
out, the station shall follow the procedures in 5.3.7.2.5.11 with respect to the unacknowledged I
PDUs.

5.3.7.2.5.6 Receiving SREJ PDU.

If the received transmission is an SREJ command or response PDU, the I PDU corresponding to
the N(R) being rejected shall be retransmitted.

5.3.7.2.5.7 Receiving RSET PDU.

Upon receipt of the RSET command PDU, the receiving station shall reply with a UA response
PDU and shall then set its V(R) to 0 for the initiating station.

5.3.7.2.5.8 Receiving REJ PDU.

When receiving an REJ PDU, the station shall set its V(S) to the N(R) received in the REJ PDU
control field. The station shall resend the corresponding I PDU as soon as it is available. If
other unacknowledged I PDUs had already been sent on that data link connection following the
one indicated in the REJ PDU, then those I PDUs shall be resent by the station following the
resending of the requested I PDU. If retransmission beginning with a particular PDU occurs
while waiting acknowledgment (see 5.3.7.2.5.11) and a REJ PDU is received, which would also
start retransmission with the same I PDU [as identified by the N(R) in the REJ PDU], the
retransmission resulting from the REJ PDU shall be inhibited.

5.3.7.2.5.9 Receiving RNR PDU.

A station receiving an RNR PDU shall, with one exception described below, stop sending I
PDUs on the indicated data link connection at the earliest possible time and shall start the busy-
state timer, if not already running. When the busy-state timer runs out, the station shall follow
the procedure described in 5.3.7.2.5.11. In any case, the station shall not send any other I PDUs
on that data link connection before receiving an RR or REJ PDU, or before receiving an I
response PDU with the F-bit set to 1, or before the completion of a resetting procedure on that
data link connection.

73
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Exception: A Station may include a busy destination in a PDU that is addressed to multiple
destination addresses if at least one of the multiple destinations is not busy.

5.3.7.2.5.10 Station-Busy condition.

A station shall enter the busy condition on a data link connection when it is temporarily unable
to receive or continue to receive I PDUs due to internal constraints; for example, receive
buffering limitations. When the station enters the busy condition, it shall send an RNR PDU at
the first possible opportunity. It shall be possible to send I PDUs waiting to be sent on that data
link connection prior to or following the sending of the RNR PDU. The station may send a
URNR command PDU to the One-hop multicast address after the RNR PDU. While in the busy
condition, the station shall accept and process supervisory PDUs and return an RNR response
PDU with the F-bit set to 1 if it receives an S or I command PDU with the P-bit set to 1 on the
affected data link connection. To indicate the clearance of a busy condition on a data link
connection, the station shall send an I response PDU with the F-bit set to 1 if a P-bit set to 1 is
outstanding, an REJ response PDU, or an RR response PDU on the data link connection with
N(R) set to the current V(R), depending on whether or not the station discarded information
fields of correctly received I PDUs. The station may then send a URR command PDU to the
One-hop multicast address. Additionally, the sending of a SABME command PDU or a UA
response PDU shall indicate the clearance of a busy condition at the sending station on a data
link connection.

5.3.7.2.5.11 Waiting acknowledgment.

The station maintains an internal retransmission count variable for each data link connection,
which shall be set to 0 when the station receives or sends a UA response PDU to a SABME
command PDU, when the station receives an RNR PDU, or when the station correctly receives
an I or S PDU with the N(R) higher than the last received N(R) (actually acknowledging some
outstanding I PDUs). If the acknowledgment timer, busy-state timer, or the P-bit timer runs out,
the station on this data link connection shall enter the timer recovery condition and add 1 to its
retransmission count variable. When a station is in the timer recovery condition, the station shall
not send any new I PDUs to the destination station. The station shall then start the P-bit timer
and send an S command PDU with the P-bit set to 1. The timer recovery condition shall be
cleared on the data link connection when the station receives a valid I or S PDU from the remote
station with the F-bit set to 1. If, while in the timer recovery condition, the station correctly
receives a valid I or S PDU with:

a. The F-bit set to 1 and the N(R) within the range from the last value of N(R) received to
the current V(S) inclusive, the station shall clear the timer recovery condition, set its V(S) to the
received N(R), stop the P-bit timer, and resend any unacknowledged PDUs; or

b. The P/F bit set to 0 and the N(R) within the range from the last value of N(R) received
to the current V(S) inclusive, the station shall not clear the timer recovery condition but shall
treat the N(R) value received as an acknowledgment for the indicated previously transmitted I
PDUs. (See 5.3.7.2.5.5.)

74
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

If the P-bit timer runs out in the timer recovery condition, the station shall add 1 to its
retransmission count variable. If the retransmission count variable is less than N2, the station
shall resend an S PDU with the P-bit set to 1 and restart its P-bit timer. If the retransmission
count variable is equal to N2, the station shall initiate a resetting procedure, by sending a
SABME command PDU, as described in 5.3.7.2.6. N2 is a system parameter defined in
5.3.8.1.2.b.

5.3.7.2.6 Procedures for mode resetting.

The resetting phase is used to initialize both directions of information transfer according to the
procedure described in 5.3.7.2.6.1 through 5.3.7.2.6.3. The resetting phase shall apply only
during ABM. Either station shall be able to initiate a resetting of both directions by sending a
SABME command PDU and starting its acknowledgment timer. Any time a station resets its
connection with a remote station, it should also send a DL-Status Indication to its local upper
layer indicating a Type 2 connection has been reset.

5.3.7.2.6.1 Receiver action.

After receiving a SABME command PDU, the station shall return one of two types of responses,
at the earliest opportunity:

a. A UA response PDU and reset its V(S) and V(R) to 0 to reset the data link connection,
or

b. A DM response PDU if the data link connection is to be terminated.

The return of the UA or DM response PDU shall take precedence over any other response PDU
for that data link connection that may be pending at the station. It shall be possible to follow the
UA PDU with additional PDUs, if pending.

5.3.7.2.6.2 Initiator action.

If the UA PDU is received correctly by the initiating station, it shall reset its V(S) and V(R) to 0
and stop its acknowledgment timer. This shall also clear all exception conditions that might be
present at either of the stations involved in the reset. The exchange shall also indicate clearance
of any busy condition that may have been present at either station involved in the reset. If a DM
response PDU is received, the station shall enter the data link disconnected phase, shall stop its
acknowledgment timer, and shall report to the higher layer for appropriate action. If the
acknowledgment timer runs out before a UA or DM response PDU is received, the SABME
command PDU shall be resent and the acknowledgment timer shall be started. After the timer
runs out N2 times, the sending station shall stop sending the SABME command PDU, and shall
enter the ADM, may report to the higher layer protocol and may initiate other error recovery
actions. The value of N2 is defined in 5.3.8.1.2.b. Other Type 2 PDUs, with the exception of the
SABME and DISC command PDUs, received by the station before completion of the reset
procedure shall be discarded.

75
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.7.2.6.3 Resetting with the FRMR PDU.

Under certain FRMR exception conditions (listed in 5.3.7.2.8), it shall be possible for the
initiating station, by sending an FRMR response PDU, to ask the remote station to reset the data
link connection. Upon receiving the FRMR response PDU (even during a FRMR exception
condition), the remote station shall either initiate a resetting procedure, by sending a SABME or
RSET command PDU, or initiate a disconnect procedure, by sending a DISC command PDU.
After sending an FRMR response PDU, the initiating station shall enter the FRMR exception
condition. The FRMR exception condition shall be cleared when the station receives or sends a
SABME or DISC command PDU, DM response PDU or RSET command PDU. Any other Type
2 command PDU received while in the FRMR exception condition shall cause the station to
resend the FRMR response PDU with the same information field as originally sent. In the
FRMR exception condition, additional I PDUs shall not be sent, and received I and S PDUs shall
be discarded by the station. It shall be possible for the station to start its acknowledgment timer
on the sending of the FRMR response PDU. If the timer runs out before the reception of a
SABME or DISC command PDU from the remote station, it shall be possible for the station to
resend the FRMR response PDU and restart its acknowledgment timer. After the
acknowledgment timer has run out N2 times, the station shall reset the data link connection by
sending a SABME command PDU. The value of N2 is defined in 5.3.8.1.2.b. When an
additional FRMR response PDU is sent while the acknowledgment timer is running, the timer
shall not be reset or restarted.

5.3.7.2.7 Procedures for sequence number resetting.

This resetting procedure, employing the RSET command, is used to reinitialize the V(R) in the
addressed station and the V(S) in the local station. The addressed station shall confirm
acceptance of the RSET command by transmission of a UA response at the earliest opportunity.
Upon acceptance of this command, the addressed station V(R) shall be set to 0. If the UA
response is received correctly, the initializing station shall reset its V(S) to 0. The RSET
command shall reset all PDU rejection conditions in the addressed station, except for an invalid
N(R) sequence number condition which the addressed station has reported by a FRMR. The
RSET command may be sent by the station that detects an invalid N(R) to clear such a frame
rejection condition in place of sending a FRMR frame. To clear an invalid N(R) frame rejection
condition with an RSET command, the RSET command shall be transmitted by the station that
detects the invalid N(R). A station may resend the contents of the information field of
unacknowledged outstanding I PDUs. Any time a station resets its connection with a remote
station, it should also send a DL-Status Indication to its local upper layer indicating a Type 2
connection has been reset.

5.3.7.2.8 FRMR exception conditions.

The station shall request a resetting procedure by sending an FRMR response PDU, as described
in 5.3.7.2.6.3, after receiving, during the information transfer phase, a PDU with one of the
conditions identified in 5.3.6.2.3.6. The coding of the information field of the FRMR response
PDU that is sent is given in 5.3.6.2.3.6. The other station shall initiate a resetting procedure by
sending a SABME or RSET command PDU, as described in 5.3.7.2.6, after receiving the FRMR
response PDU.

76
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.7.3 Description of Type 3 procedures.

The procedures associated with Type 3 operation are described in 5.3.7.3 and all subparagraphs.

Note: All stations must implement both Type 1 and Type 3 communications. Status of stations
on the network, maintained by sending and receiving URR and URNR PDUs, shall be correlated
between Type 1 and Type 3 operations. For example, if a platform receives a Type 3 URNR
Response from a station, that station should be considered busy for both Type 1 and Type 3
communications until a Type 1 URR Command is received by the platform. This applies to all
URR Commands, URNR Commands, and URNR Responses.

5.3.7.3.1 Modes of operation.

In Type 3 operation, no modes of operation are defined. A station using Type 3 procedures shall
support the entire procedure set whenever it is operational on the network.

5.3.7.3.2 Procedure for addressing.

The address fields shall be used to indicate the source and destinations of the transmitted PDU.
The first bit in the source address field shall be used to identify whether a command or a
response is contained in the PDU. Unicast, special and multicast (One-hop or group) addressing
shall be supported for destination addresses in command PDUs. The source address field shall
contain a unicast or special address.

5.3.7.3.3 Procedure for using the P/F bit.

For Type 3 operation, the transmitting station shall always set the P-bit equal to 1. The station
receiving a UI or TEST command PDU with the P-bit set to 1 shall send an appropriate response
PDU with the F-bit set to 1.

5.3.7.3.4 Procedures for logical data link set-up and disconnection.

Type 3 operation does not require any prior data link connection establishment (set-up), and
hence no data link disconnection. Once the service access point has been enabled within the
station, information may be sent to, or received from, a remote station also participating in Type
3 operation.

5.3.7.3.5 Procedures for information transfer.

5.3.7.3.5.1 Sending UI command PDUs.

Information transfer from an initiating station to a responding station shall be accomplished by
sending the UI Command Acknowledgment Required PDU. When a sending station sends a UI
command PDU with the P-bit set to 1, it shall start an acknowledgment timer for that
transmission and initialize the internal transmission count variable to zero. If all expected URR
or URNR response PDUs are not received before the timer runs out, the sending station shall
resend the UI command PDU, increment the internal transmission count variable, and restart the
acknowledgment timer. Prior to resending the UI command PDU, the multicast (One-hop or
group) addresses shall be removed as well as unicast and special addresses from which a
response (URR or URNR) was received. The special address 3, if used, shall not be removed

77
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

prior to retransmission unless it is the only address remaining. No retransmission shall be

attempted unless a unicast or special address other than 3 remains. If a URR response PDU is
still not received, this resending procedure shall be repeated until the value of the internal
transmission count variable is equal to the value of the logical link parameter N4, as described in
5.3.8.1.4.c, at which time a DL-Status-Indication shall be reported to the upper layer indicating
an acknowledgment failure. An internal transmission count shall be maintained for each UI
information exchange (where P-bit = 1) between a pair of sending and receiving stations. Both
the acknowledgment timer and the internal transmission count, for that exchange, shall not affect
the information exchange with other receiving stations. If a URNR response PDU is received in
response to a UI command with the P-bit set to 1, the receiving station shall designate the
sending station as busy. The retransmission of the UI command shall follow the rules for the
busy condition. Transmission of UI commands to that station shall be discontinued until the
busy state is cleared.

5.3.7.3.5.2 Receiving UI command PDUs.

A station shall acknowledge the receipt of a valid UI command PDU, which has the P-bit set to 1
and contains the station unicast address, by sending a URR response PDU to the originator of the
command UI PDU. If the receiving station is unable to accept UI PDUs due to a busy condition,
it may respond with a URNR response PDU, with the F-bit set to 1.

5.3.7.3.5.3 Sending URR response PDUs.

A URR response PDU, with the F-bit set to 1, shall be sent only upon receipt of a UI command
PDU, with the P-bit set to 1. The URR response PDU shall be sent to the originator of the
associated UI command PDU.

5.3.7.3.5.4 Sending URNR response PDUs.

A URNR response PDU, with the F-bit set to 1, may be sent by the remote station to advise the
originator of the associated UI command PDU that it is experiencing a busy condition and is
unable to accept UI PDUs.

5.3.7.3.5.5 Receiving UI acknowledgment.

After sending a UI command PDU with the P-bit set to 1, the sending station shall expect to
receive an acknowledgment in the form of a URR response PDU from the station to which the
command PDU was sent. No acknowledgment shall be expected from multicast (One-hop or
group) addresses or from the special address 3. Upon receiving such a response PDU, the station
shall stop the acknowledgment timer associated with the transmission for which the
acknowledgment was received and reset the associated internal transmission count to zero. If the
response was a URNR response PDU, the sending station shall stop sending UI, I, and DIA
PDUs to that remote station until a URR command PDU is received or the busy-state timer
expires, indicating termination of the busy condition. If High Reliability was requested for the
command PDU, a DL-Status-Indication should be sent to the upper layer indicating
acknowledgment success.

78
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.7.3.5.6 Using TEST command and response PDUs.

The TEST function provides a facility to conduct loop-back tests of the station-to-station
transmission path. The TEST function may be initiated within the data link layer by any
authorized station within the data link layer. Successful completion of a test started by sending a
TEST command PDU with the P-bit set to 1 consists of receiving a TEST response PDU with the
F-bit set to 1 and containing no data from each unicast addressee. Any TEST command PDU
received in error shall be discarded and no response PDU sent. In the event of a test failure, it
shall be the responsibility of the TEST function initiator to determine any future actions.

5.3.7.4 Description of Type 4 procedures.

The procedures associated with Type 4 operation are described in 5.3.7.4.1 through 5.3.7.4.5.3.

5.3.7.4.1 Modes of operation.

In Type 4 operation, no modes of operation are defined. A station using Type 4 procedures shall
support the entire set whenever it is operational on the network.

5.3.7.4.2 Procedure for addressing.

The address field shall be used to indicate the source and destinations of the transmitted PDU.
The first bit in the source address shall be used to identify whether a command or a response is
contained in the PDU. Unicast and multicast (One-hop or group) addressing shall be supported
for the destination addresses in command PDUs. The source address shall contain a unicast
address.

5.3.7.4.3 Procedure for using the P/F bit.

The P/F bit is not implemented in Type 4 operation.

5.3.7.4.4 Procedures for logical Data Link set-up and disconnection.

Type 4 operation does not require any prior data link set-up and disconnection. Data link set-up
and disconnection procedures are not required for Type 4 operation. All stations shall advance
to the information transfer state.

5.3.7.4.5 Procedures for information transfer.

5.3.7.4.5.1 Sending DIA command frames.

The DIA PDU may either be a new PDU from the local user, or a retransmission of a DIA PDU
which was not acknowledged within the period determined by the T1 parameter. DIA PDUs are
retransmitted up to N2 times, where N2 is as specified by the station parameters. If a DIA PDU
is not acknowledged after N2 retransmissions, an indication should be sent to the upper layer
indicating an acknowledgment failure.

5.3.7.4.5.2 Decoupled Receive Not Ready (DRNR) procedures.

79
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.7.4.5.2.1 Sending a DRNR command PDU.

A station may generate and transmit a DRNR command PDU if its Quiet Mode is disabled and it
receives a DIA PDU which it cannot accept because its receive buffers are full. A station may
generate a DRNR command PDU when directed by the management function (e.g., operator).
The DRNR command S PDU does not acknowledge a DIA PDU. The station may send a URNR
command PDU to the One-hop multicast address after the DRNR PDU.

5.3.7.4.5.2.2 Receiving a DRNR command PDU.

Upon receipt of a DRNR PDU a station shall, with one exception described below, inhibit
transmission of DIA PDUs to the station which originated the DRNR command by updating the
station status table to reflect this busy condition. The DRNR PDU shall not change the Quiet
Mode status of a station. Any PDUs in the retransmission queue addressed to the busy station
shall be modified to delete (null) the busy station from the destination address list. Normal
transmissions of DIA PDUs to that station shall resume upon receipt of a DRR command from
the station.

Exception: A Station may include a busy destination in a PDU that is addressed to multiple
destination addresses if at least one of the multiple destinations is not busy.

5.3.7.4.5.2.3 Sending a DRNR response PDU.

A station shall generate and transmit a DRNR response PDU after it has sent a DRNR command
PDU (if its Quiet Mode is disabled) while it is processing frames in its receive queues in the
busy condition. A DRNR response acknowledges the DIA PDU indicated in the PDU
identification number field while reinforcing the station’s busy condition.

5.3.7.4.5.2.4 Receiving a DRNR response PDU.

Upon receipt of a DRNR response PDU, a station shall search the destination addresses
associated with the identification number in the DRNR response PDU. The response PDU
originator’s address shall be deleted from the destination address field (if it is still there) of the
DIA being acknowledged.

5.3.7.4.5.3 Decoupled Receive Ready (DRR) procedures.

5.3.7.4.5.3.1 Sending a DRR PDU.

A station shall generate and transmit a DRR PDU if its Quiet Mode is disabled and one of the
following conditions exist.

a. The station is no longer busy and had previously sent a DRNR command PDU.

80
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

b. The station is not busy and the station received a DIA PDU from a transmitting station
which requires acknowledgment.

c. If directed by the user interface.

5.3.7.4.5.3.1.1 Sending a DRR command PDU.

The DRR command PDU is generated and transmitted by a station to indicate the end of a Type
4 busy/buffer full condition. The DRR command S PDU does not acknowledge DIA PDUs. The
DRR command PDU only changes the status from busy to receive ready. This frame does not
change the Quiet Mode status. The station may send a URR command PDU to the One-hop
multicast address after the DRR PDU.

5.3.7.4.5.3.1.2 Sending a DRR response PDU.

The DRR response PDU is generated and transmitted by a station whose Quiet Mode is disabled
to acknowledge the acceptance of a DIA PDU, and is addressed to the originator of the DIA
PDU. The DIA PDU which is being acknowledged is indicated by the PDU identification
number.

5.3.7.4.5.3.2 Receiving a DRR response PDU.

Upon receipt of a DRR response PDU a station shall search the destination addresses associated
with the identification number in the DRR response PDU. The DRR response PDU originator’s
address shall be deleted from the destination address field of the DIA being acknowledged. If
High Reliability was requested for the DIA, an indication should be sent to the upper layer
indicating acknowledgment success.

5.3.8 Data Link initialization.

The XNP messages, described in APPENDIX E, are used to establish and control Data Link
parameters. The Join Request message contains the link operating parameters such as net busy
detect time, station rank, and net access method. Initialization is caused by an operator or
system request. The Join Request is sent to the default NETCON destination address, which
shall be the station assigned to perform NETCON station responsibilities. The NETCON station
verifies Data Link parameters and provides values for missing or incorrect parameters to ensure
that the new station will not disrupt the net. The NETCON station will reply with either a Join
Reject or Join Accept PDU. If the initializing station receives a Join Reject PDU, it should not
attempt any link activity until the correct parameters have been obtained.

NOTE: Link initialization may also occur without an XNP message exchange. Prearrangement
by timing, voice, written plans, or orders provides the operator with the necessary frequency,
link address, data rate, and other parameters to enter a net and establish a link. With the
prearranged information, an operator may begin link activity on the net and initialization is
assumed when the new station senses the net and transmits its first message.

81
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.8.1 List of Data Link parameters.

This document defines a number of Data Link parameters for which the system-by-system range
of values is determined at network establishment. The actual parameter values selected play an
important role in determining the efficiency and effectiveness of the network configuration. It is
therefore important to select proper values. Even more important is the need to insure that all
participants on a subnetwork use the same parameter values. A bad choice of parameter values
can significantly degrade the network performance. Using different values, even if the values
are reasonable, can lead to a breakdown of the network precluding interoperability. A list of the
parameters and their recommended values is provided in a separate document entitled “MIL-
STD-188-220 Parameter Table”. All systems should utilize these values. The definitions of the
parameters for the four types of operation are summarized in 5.3.8.1.1 through 5.3.8.1.5.

5.3.8.1.1 Logical Data Link parameters for all types.

The logical Data Link parameters that do not depend upon the Type of operation in use are as
follows:

a. Maximum number of octets. The maximum number of octets in the information field of
a UI, I or DIA PDU is an adjustable data link parameter in the range of 708 – 3345.

b. Maximum Transmit Time (MTT). MTT represents the maximum time allowed on the
network for a single transmission. It is the time from when the Radio’s Push To Talk (PTT) is
activated until the PTT is deactivated. It is used to limit physical and data link frame
concatenation only.

5.3.8.1.2 Type 1 logical Data Link parameters.

The logical data link parameters for Type 1 operation shall be as follows:

a. Busy-state timer. The busy-state timer is a data link parameter that defines the time
interval following receipt of the URNR command PDU during which the station shall wait for
the other station to clear the busy condition. Default value is 120 seconds.

b. Minimum number of octets in a PDU. The minimum-length valid data link PDU shall
contain 2 flags, 2 addresses, one 8-bit control field, and the FCS. The minimum number of
octets in a valid data link PDU shall be 9.

c. TEST Time to Live (TTTL). TTTL represents the maximum time to wait to transmit a
TEST Response frame. If the TTTL time expires and the TEST Response frame has not been
transmitted then the TEST Response frame shall be deleted from the queue. The values are
established at protocol initialization and are in the range of 0.000 to 65.535 seconds. A value of
0 indicates that the message shall not time out (see E.4.3.3).

5.3.8.1.3 Type 2 logical Data Link parameters.

The logical data link connection parameters for Type 2 operation shall be as follows:

82
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

a. Acknowledgment timer. The acknowledgment timer is a data link connection parameter

that shall define the time interval during which the station shall expect to receive
acknowledgment to one or more outstanding I PDUs or an expected response to a sent U
command PDU. The acknowledgment timer should not be activated until the corresponding
PDU has been transmitted. Time values are established at protocol initialization and are in the
range of 10 to 1800 seconds in one-second increments. Default is 120 seconds.

b. P-bit timer. The P-bit timer is a data link connection parameter that defines the time
interval during which the station shall expect to receive a frame with the F-bit set to 1 in
response to a sent Type 2 command with the P-bit set to 1. The P-bit timer should not be
activated until the corresponding PDU has been transmitted. Time values are established at
protocol initialization and are in the range of 10 to 60 seconds in increments of 1 second.
Default is 10 seconds.

c. Reject (REJ) timer. The REJ timer is a data link connection parameter that defines the
time interval during which the station shall expect to receive a reply to a sent REJ or SREJ PDU.
The REJ timer value shall be equal to or less than twice the acknowledgment timer. The REJ
timer should not be activated until the corresponding PDU has been transmitted.

d. Maximum number of retransmissions, N2. N2 is a data link connection parameter that

indicates the maximum number of times that a PDU (including the S command PDU that is sent
as a result of the acknowledgment P-bit or REJ timer expiring) is sent, following the running out
of the acknowledgment timer, the P-bit timer, or the REJ timer. The maximum number of times
that a PDU is retransmitted following the expiration of the timers is established at protocol
initialization. This value is in the range of 0 through 5 and defaults to 2. The retransmission of
PDUs may be overridden by the Quiet Mode parameter, which is described in 5.3.11.2.

e. Maximum number of outstanding I PDUs, k. The maximum number (k) of sequentially

numbered I PDUs that the sending station may have outstanding (i.e. unacknowledged) on a
single data link connection simultaneously. The value of this parameter is in the range 1 through
127. (This value of this parameter may be established through the use of the Type 2 k Window
field of an XNP message as described in APPENDIX E, “Type 2 Parameters”.)

f. Maximum number of outstanding I PDUs at which an acknowledgment is requested, k2.

The maximum number (k2) of outstanding (i.e. unacknowledged) I PDUs that can be sent by a
source station on a data link connection before the station requests acknowledgment. When this
threshold is reached the sending station sends an S PDU that both acknowledges received I
frames and causes an S PDU to be sent in return to acknowledge outstanding I PDUs. The value
of this parameter is in the range 1 through 127, but would normally be less than or equal to the
value of parameter k.

g. Maximum number of outstanding received I PDUs threshold, k3. The maximum number
(k3) of correct in sequence I PDUs received on a data link connection since the last I PDU
received on the data link connection was acknowledged. When this threshold is reached the

83
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

receiving station generates an S PDU to acknowledge received frames. The value of this
parameter is in the range 1 through 127, but would normally be less than or equal to the value of
parameter k.

h. Response delay timer, percent. The amount of time, as a percent of Type 2

Acknowledgment Timer seconds, that a station waits after an I PDU Response or an I PDU
Command with its P-bit set to 0 is received until it is acknowledged by transmission of an S
PDU in the case that no other frames are available for transmission. The value of this parameter
is in the range of 0 - 99%. (The value of this parameter may be established by the Type 2
Acknowledgment Timer and Response Timer fields of an XNP Parameter Update message as
described in APPENDIX E, “Type 2 Parameters” or from the Protocol Parameters Table.)

i. Minimum number of octets in a PDU. A minimum-length valid data link PDU shall
contain exactly 2 flags, 2 address fields, 1 control field, and the FCS. Thus, the minimum
number of octets in a valid data link PDU shall be 9 or 10, depending on whether the PDU is a U
PDU, or an I or S PDU, respectively.

5.3.8.1.4 Type 3 logical Data Link parameters.

The logical Data Link parameters for Type 3 operation shall be as follows:

a. Acknowledgment timer. The acknowledgment timer is a Data Link parameter that shall
define the timeout period (TP) during which the sending station shall expect an acknowledgment
from a specific destination station. The acknowledgment timer should not be activated until the
corresponding PDU has been transmitted. TP shall take into account any delay introduced by the
physical sublayer. The value of TP is described in APPENDIX C (C.4.3).

b. Busy-state timer. The busy-state timer is a data link parameter that defines the time
interval following receipt of the URNR Response PDU during which the station shall wait for
the other station to clear the busy condition. Default value is 120 seconds.

c. Maximum number of retransmissions, N4. N4 is a data link parameter that indicates the
maximum number of times that an UI or TEST command PDU is retransmitted by a station
trying to accomplish a successful information exchange. Normally, N4 is set large enough to
overcome the loss of a PDU due to link error conditions. The maximum number of times that a
PDU is retransmitted following the expiration of the acknowledgment timer is established at
protocol initialization. This value is in the range of 0 through 5 and defaults to 2. The
retransmission of PDUs may be overridden by the Quiet Mode parameter, which is described in
5.3.11.2.

d. Minimum number of octets in a PDU. The minimum-length valid data link PDU shall
contain 2 flags, 2 addresses, one 8-bit control field, and the FCS. The minimum number of
octets in a valid data link PDU shall be 9.

5.3.8.1.5 Type 4 logical Data Link parameters.

The logical Data Link parameters for Type 4 operation shall be as follows:

84
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

a. Acknowledgment (T1) timer. The T1 timer is the maximum time a station shall wait for
an acknowledgment of a transmitted DIA PDU before that PDU is retransmitted. The value of
T1 shall be in the range of 5-120 seconds in increments of 0.2 seconds. Each DIA PDU
transmitted shall be assigned a T1 timer. When the T1 timer expires for DIA PDU, that DIA
PDU shall be retransmitted in the next transmission opportunity for that precedence, assuming
the N2 count has not been reached. DIA PDUs with only one destination shall be discarded if
the destination replied with a DRNR or DRR response PDU. If the DIA PDU is multi-
addressed, the receive station is removed (nulled) from the destination address field. This timer
shall be paused whenever the net is busy with voice. This timer is resumed when voice
transmission has completed.

b. Maximum number of retransmission attempts, N2. The N2 parameter shall indicate the
maximum number of retransmission attempts to complete the successful transmission of a DIA
PDU. The value of N2 shall be the maximum retransmit value (range = 0-5).

c. k maximum number of outstanding DIA frames. The value of k indicates the maximum
number of DIA PDUs that a station may have outstanding (awaiting acknowledgment) to all
stations at any given time. The value of k ranges from 5 - 40 DIA PDUs.

d. Minimum number of octets in a PDU. A minimum-length valid data link PDU shall
contain exactly 2 flags, 2 address fields, one (1) 16-bit control field, and the FCS. Thus, the
minimum number of octets in a valid data link PDU shall be 10.

e. ACK list length. The number of Type 4 DIA frames remembered in the list used to
detect and discard duplicates. The number in the list can range from 0 - 255. The value of “0” is
used to turn off this detect capability.

5.3.9 Frame transfer.

After a station has joined the net, it can begin to send frames. The data link layer shall request
the transmission of a frame by the PL.

5.3.9.1 PDU transmission.

The data link layer initiates transmission by building a transmission unit and passing it to the PL.
The elements of a transmission unit include one Transmission Header (see 5.3.1), one or more
PDUs (see data link concatenation, below), the additional bits resulting from the operations of
zero-bit-insertion, optional FEC encoding, optional TDC and optional scrambling. To request
transmission, a PL-Unitdata-Request is issued by the data link layer protocol after a transmission
unit has been constructed. PDUs shall be queued for transmission in such a manner that the
highest precedence PDUs are transmitted before lower precedence PDUs. If a prioritized net
access scheme is active, the precedence access level used shall be the precedence of the PDU
that is to be transmitted next. Transmission units of the same precedence shall be in first-in first-
out (FIFO) order. Type 2 I PDUs for a particular connection shall be transmitted in the order of
their sequence numbers. Only Type 1, Type 2 and Type 4 PDUs may be concatenated at the data
link layer or PL, and these Type 1, Type 2 and Type 4 PDUs can be mixed together into a single

85
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

concatenated transmission unit. Type 3 response PDUs may be data link concatenated, but only
with duplicates of themselves, i.e. not with other PDU Types 1, 2 or 4).

5.3.9.2 Data Link concatenation.

The sending station may only concatenate Type 1,Type 2 or Type 4 PDUs and Type 3 response
PDUs (which may be concatenated only with duplicates of themselves [see 5.3.14.2 for details of
the duplication process]). Type 3 response PDUs may be data link concatenated, but only with
duplicates of themselves, i.e. not with other PDU Types 1, 2 or 4). This is done by using one or
two flags to separate each PDU. All receiving stations shall be able to de-concatenate the
reception into separate PDUs. The combined length of the concatenated PDUs, before 0-bit
insertion, may not exceed the established maximum PDU size for a single PDU (see 5.3.8.1).
The PDUs are concatenated after the 0-bit insertion algorithm is applied. FEC, with or without
TDC, and scrambling are optionally applied before the transmission unit is passed to the PL in a
PL-Unitdata-Request. Data Link concatenation to add another interior data frame shall not be
performed if the resulting frame would take longer to transmit than the maximum transmit time
allowed for the network. Data link concatenation is shown in FIGURE 24.

5.3.9.3 Physical Layer (PL) concatenation.

PL concatenation does not apply when Packet Mode is used. More than one PDU may be passed
to the PL without waiting for an intervening NAD period. The time to transmit the combined
length of the transmission frame, shall not exceed the maximum transmit time allowed for the
network. The PL shall transmit each transmission unit following the complete PL procedures
with no additional bits between Interior Transmission Units (except for bit synchronization when
used in Asynchronous Mode). PL concatenation is shown in FIGURE 25. Note that the Phasing
field described in 5.2.1.2 shall precede the first Interior Transmission Unit only.

86
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

“Interior” [Repeat Interior Data “Interior”

FLAG Transmission Frames with flags (as
(1 Octet) FLAG(s) Data FLAG(s) required) Data FLAG
Information Frame * * * * * Frame (1 Octet)
(See & FCS and within total length
5.3.4.2.1) (See 5.3.1) (See 5.3.4.2.1) (See below) restrictions]

“INTERIOR" DATA FRAME

LSB MSB LSB MSB LSB MSB MSB LSB

Address Control Information FCS

(Variable) (1-32 octets) (4 octets)
(See 5.3.4.2.2) (See 5.3.4.2.3) (See 5.3.4.2.4) (See 5.3.4.2.5)

FIGURE 24. Data Link concatenation.

TRANSMISSION FRAME

[Repeat Bit Sync and

“Interior” “Interior” Interior Transmission Units “Interior”
Bit Bit
Phasing Transmission Transmission * * * * * Transmission
Sync as needed, within total
Sync
Unit Unit Unit
length restrictions]

NOTE: Bit Synchronization is used only

in Asynchronous Mode.

“INTERIOR” TRANSMISSION UNIT

Transmission Header Data Link Frame

Transmission
Synchronizatio Transmissio Informatio
n Flag n n
Information FCS Flag Flag Address Control FCS Flag
(up to 3345
(variable length)
(8 bits) (2 octets) (32 bits) (8 bits) (8 bits) (variable) (1-32 octets) octets) (32 bits) (8 bits)
5.2.1.3 5.3.4.2.1 5.3.1 5.3.4.2.5 5.3.4.2.2 5.3.4.2.3 5.3.4.2.4

FIGURE 25. Physical Layer concatenation.

87
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.9.4 PDU transmissions.

Both Data Link Layer (DL) and PL concatenation may be used to build a single transmission
frame. All types of operation PDUs, except Type 3 PDUs may be concatenated within the same
single transmission frame. PDUs are placed in the appropriate precedence-level queue, with
each level queue using a single FIFO order. If the first PDU in the highest precedence level
queue (or only queue) may be concatenated, then other PDUs may be concatenated with that
PDU even if a PDU that does not allow concatenation is queued ahead of them. The PDU that
did not allow concatenation shall be at the head of its appropriate queue for the next net access
period. If the first PDU in the highest precedence level queue (or only queue) does not allow
concatenation, it shall be the only PDU transmitted in that net access period.

5.3.10 Flow control.

Flow control provides the capability of reducing the allowed input rate of information to prevent
congestion to the point where normal operation may become impossible. The control-field
sequence numbers are available for this service.

5.3.10.1 Type 1 flow control.

Type 1 transmissions are unacknowledged. Unacknowledged operations can perform flow
control using URR and URNR messages. The URR message announces the station’s ability to
accept incoming frames for any mode of service (Types 1, 2, 3 and 4) whereas the URNR
announces the station’s inability to accept incoming frames for any mode of service.

5.3.10.2 Type 2 flow control.

The N(S) and N(R) are used in conjunction with the V(S) and V(R) to control data flow. Flow
control is implemented by the window method. The window defines the maximum number of
undelivered frames a given user may have outstanding. The maximum number (k) of
sequentially numbered I PDUs that may be outstanding (that is, unacknowledged) at any given
time is a data link connection parameter, which shall never exceed 127. The incremental
updating of N(R) acts as the positive acknowledgment of transmitted frames up to, but not
including, that frame number. The window flow-control mechanism requires that the highest
sequence number transmitted by the user be less than the sum of the last received N(R) plus k
mod MODULUS (see 5.3.5.2.1). Window size (k) is a feature that is agreed upon by the users at
initialization. The larger the window, the greater the traffic loading a given user places on a
single channel (SC).

5.3.10.3 Type 3 flow control.

Type 3 transmissions can perform flow control using URR and URNR response messages.
These messages announce the station’s ability or inability to accept incoming frames for any
mode of service. Type 3 responses are only addressed to a unicast destination. Therefore, if
additional stations are to be notified, the URR/URNR command would be sent in a Type 1 PDU.

5.3.10.4 Type 4 flow control.

Type 4 flow control is performed using DRR and DRNR messages. These messages indicate a
station’s ability to accept incoming DIA frames. In addition, a window method is used to define

88
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

the maximum number of frames a given station may have outstanding. The maximum number of
DIA PDUs that may be outstanding (unacknowledged) at any given time is the Type 4 k
parameter.

5.3.11 Acknowledgment and response.

All UI, DIA or I PDUs that require an acknowledgment shall be acknowledged except for the
following cases:

a. The control field of the received PDU specifies that no acknowledgment is required.

b. The Quiet Mode (described in 5.3.11.2), has been set to ON.

c. The receiving station is a multicast (One-hop or group) addressee only.

d. The receiving station’s unicast address is not in the address field.

e. The PDU is invalid.

5.3.11.1 Acknowledgment.
Acknowledgments are applicable for Type 3, Type 2 and Type 4 operations.

5.3.11.1.1 Type 3 acknowledgment.

Each Type 3 PDU shall be responded to before another PDU is transmitted. This is defined as a
coupled acknowledgment. All Type 3 UI and TEST command PDUs shall be acknowledged.
The RHD procedures (see C.4.2) shall be followed by all stations on the network to allow each
responding station an interval in which they can transmit their response.

5.3.11.1.2 Type 2 acknowledgment.

Type 2 PDUs that require acknowledgment shall activate the acknowledgment timer. Type 2
also uses P and F-bit procedures for acknowledgments, but these P and F-bit procedures do not
involve coupled acknowledgments. The Type 2 operation does not use the RHD timer, which
allows receiving stations to send their acknowledgments during the current net access period.
All acknowledgments are transmitted in another net access period. An I PDU acknowledgment
does not necessarily correspond on a one-to-one basis with the I PDU and does not necessarily
apply to the immediately preceding I PDU.

5.3.11.1.3 Type 4 acknowledgment.

The DIA PDU shall activate the acknowledgment timer. The Type 4 operation does not use the
RHD timer. All acknowledgments are sent in another channel access period. All DIA PDUs are
independently acknowledged.

5.3.11.2 Quiet Mode.

The protocol shall allow an operator to initiate Quiet Mode as an override feature that, when
invoked, prevents any transmission (including retransmission) without explicit permission from
the operator. As a security feature, the operator shall be able to turn off automatic transmissions

89
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

but still continue to receive. Normal protocol exchanges shall occur when the Quiet Mode is
OFF. Only the operator can initiate a transmission when the Quiet Mode is ON. The Quiet
Mode shall override the Maximum Number of Retransmissions data link parameters. The
default value of the Quiet Mode is OFF. If the Quiet Mode is ON during Type 2 operations, the
flow control mechanism and retransmission timers in the remote system will eventually cause the
connection to be lost. UI, I, or DIA PDUs received by a station with Quiet Mode ON shall be
serviced in the normal way except nothing is returned nor queued for later transmission.

5.3.11.3 Immediate retransmission.

Certain time critical exchanges require immediate retransmission of a Type 3 message if all
expected acknowledgments are not received in the allocated response interval. Immediate
retransmission involves the sending station retransmitting the message while the receiving
stations are still in their Timeout Period, rather than allowing a new NAD period to begin. This
is accomplished by the sending station using the special address of 3 in the destination address
field with the Type 3 operation. All receiving stations calculate their TP based upon the total
number of individual and special addresses (including special address 3). The sending station
does not include the special address 3 in its TP calculation and schedules any necessary
retransmissions during the longer TP experienced by other stations if immediate retransmission
is required. When all acknowledgments to the message have been received, either after the first
transmission or subsequent transmission, or the Maximum Number of Transmission data link
parameter limit has been reached, the sending station no longer requires immediate
retransmission for that exchange. TP calculations are described in C.4.3.

5.3.12 Invalid frame.

A frame is invalid if it has one or more of the following characteristics:

a. Not bounded by a beginning and ending flag.

b. Too short.
c. Too long.
d. Has an invalid address or control field.
e. Has an FCS error.

A frame is too short if it contains less than 9 bytes. A frame is too long if it exceeds the
maximum PDU length as described in 5.3.8.1.1.a. Any invalid frame shall be discarded.

5.3.13 Retransmission.
The data link layer shall retransmit a command frame waiting for a response. The default
number of retransmissions is 2, but the data link layer protocol may be initialized to
automatically retransmit 0 to 5 times. If the Quiet Mode is ON, no automatic retransmissions
shall be made.

90
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.14 Error Detection and Correction (EDC).

FEC coding alone, or FEC coding in unison with TDC, may be used to provide EDC capabilities
to compensate for errors induced during transmission. If selected, the FEC process shall be used
to encode the data link frame of 5.3.4. If selected, the TDC process shall be applied to the FEC-
encoded data link frame and to the fill bits. Three modes of EDC shall be supported: FEC OFF,
FEC ON with TDC, and FEC ON without TDC (NOTE: FEC ON without TDC may be used
when the transmission channel provides the TDC capability). The EDC modes are selectable.

5.3.14.1 Forward-Error-Correction (FEC) coding.

When FEC is selected, the Golay (24,12) cyclic block code, described in detail in APPENDIX F,
shall be used for FEC. The generator polynomial to obtain the 11 check bits shall be

g(x) = x11 + x10 + x6 + x5 + x4 + x2 + 1

where g(x) is a factor of x23 +1.

5.3.14.2 Forward-Error-Correction preprocessing.

When either FEC only or FEC/TDC is selected, data bits shall be divided into a sequence of 12-
bit segments prior to Golay encoding. The total number of 12-bit segments shall be an integral
number. If FEC/TDC is selected and a coupled acknowledgment (i.e., a Type 3 URR, URNR or
TEST Response frame with the F-bits set to 1) is being transmitted, the coupled acknowledgment
frame shall be duplicated and then data link concatenated to the end of the original coupled
acknowledgment frame. This provides a receiving station two opportunities for capturing an
error-free frame without increasing the size of the transmission. This shall not be applied when
the four octets addressing, described in 5.3.4.2.2.1.2, or the six octet addressing described in
5.3.4.2.2.1.3 is used. If the data bits do not divide into an integral number of 12-bit segments,
after coupled acknowledgment duplication (as appropriate), then from 1 to 11 zeros (0’s) shall be
added at the end to form an integral number of 12-bit segments.

5.3.14.3 Time-Dispersive Coding (TDC).

TDC bit interleaving may be selected in unison with FEC. When TDC is selected, data shall be
formatted into a sequence of TDC blocks composed of sixteen 24-bit Golay (24, 12) codewords
(that is, there are 384 FEC-encoded bits per TDC block). Each TDC block shall contain a total
of 16 FEC codewords. If the last TDC block of a message contains less than 16 FEC codewords,
fill codewords shall be added to complete the TDC block. These 24-bit fill codewords shall be
created by Golay-encoding an alternating sequence of 12-bit data words, with the first word
composed of 12 ones followed by a word composed of 12 zeros. The fill codewords shall
alternate until the TDC block is filled. The TDC block shall be structured into a 16 x 24 matrix
(the Golay codewords appear as rows), as shown in FIGURE 26.

A1 through A24 are the bits of the first Golay codeword. A25 is the first bit of the second Golay
codeword. Each TDC block matrix shall be rotated to form a 24 x 16 matrix. The Golay
codewords now appear as columns, as shown in FIGURE 27. The TDC block is transmitted row
by row with the LSB (A1) of the first row first. At the receiver, the TDC-encoded bit stream

91
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

shall be structured into a 24 x 16 matrix. Each received TDC block matrix shall be rotated to
form the original 16 x 24 matrix, as shown in FIGURE 26. The TDC decoder at the receiver
shall perform the inverse of the TDC encoding process.

92
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

A1 A2 A3 A22 A23 A24

A25 A26 A27 A46 A47 A48
A49 A50 A51 A70 A71 A72

A361 A362 A363 A382 A383 A384

Golay Codeword in each row

A1, A2 , ... , A23, A24

FIGURE 26. Transmitter’s 16 x 24 matrix before interleaving.

A1 A25 A49 A313 A337 A361

A2 A26 A50 A314 A338 A362
A3 A27 A51 A315 A339 A363

A24 A48 A72 A336 A360 A384

Golay Codeword in each row

A1, A25 , .... A337, A361

FIGURE 27. Transmitter’s 24 x 16 matrix after interleaving.

5.3.15 Data scrambling.

Data scrambling shall be performed if the transmission medium does not have a DC response
and there is the possibility that “long” strings of NRZ ones or zeros are transmitted. Long is a
relative term that is dependent on the data rate, the low frequency channel cutoff frequency, and
the channel S/N, since at low S/N there is less margin for DC drift.

a. At the Data Link layer, the Transmission Header selects a CCITT V.36 scrambler,
which includes a randomizer function as well as a pseudo-noise (PN) generator. It is applied
inside the FEC (that is, before FEC is applied).

b. CCITT V.36 scrambling shall not be applied outside the FEC because bit errors at the
receiver will be extended. In a high BER environment this extension will become catastrophic.
For that reason a modified CCITT V.33 scrambler defined in section J.3.3, which uses a PN
generator but not a randomizer, is specified for use at the PL (as part of the multi-dwell protocol;
see J.3.3). In both cases, there is a very small probability that the interleaving for the Data Link
layer scrambler and the fixed PN sequence for the PL scrambler may do more harm than good.

93
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Therefore, they are individually selectable. Both scramblers should not be used at the same time.
If CCITT V.36 scrambling/descrambling is used, the contents of the 20-state shift register shall
be initialized to all ones prior to scrambling or descrambling data link frames in each interior
transmission unit. The Adverse State Detector (ASD) counter shall be initialized such that at
least 32-bits are counted, starting from the first bit input to the 20-state shift register, when the
first adverse state is detected. The operation of the scrambling/descrambling shall be as shown
in FIGURE 28. FIGURE 29 illustrates an example implementation for the CCITT V.36
scrambling/descrambling.

ALL CCITT V.36

0’s Scrambler

Transmitted Data output from Scrambler

0xFF, 0xFF, 0xFF, 0x7F, 0xDB, 0xB6, 0x65,

0x59, 0x16, 0x61…
ALL CCITT V.36
0’s Descrambler

FIGURE 28. Required CCITT V.36 scrambling/descrambling operation.

94
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

* 5 BIT COUNTER IF (COUNT == 30)

* INCREMENTS AFTER THEN
EACH NEW BIT OUTPUT = ‘1’
* ROLLS FROM 31 TO 0 ELSE
OUTPUT = ‘0’
IF (‘1’)
THEN
SET COUNTER TO 31
ELSE
INCREMENT COUNT
XOR

XNOR
XNOR

STAGE STAGE STAGE STAGE STAGE

1 2 3 9 20

20 BIT SHIFT REGISTER

Scrambled data/
Data Output Data/Scrambled
Scrambler
Data Input
XNOR
Descrambler

A A
C C
B B
NOTES:
1. SHIFT REGISTER SHIFTS AND COUNTER
XNOR XOR
IS SET OR INCREMENTS AFTER EACH
A B C A B C INPUT/OUTPUT
0 0 1 0 0 0
0 1 0 0 1 1 2. SHIFT REGISTER INITIALIZED TO ALL ‘1s’
1 0 0 1 0 1 AND COUNTER INITIALIZED TO ‘31’ BEFORE
1 1 1 1 1 0 FIRST INPUT/OUTPUT

FIGURE 29. Example implementation of CCITT V.36.

95
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.3.16 Data Link Layer interactions.

The data link layer interacts with both the next higher and next lower layer to pass or receive
information regarding services requested or performed. The following primitives are used to
pass information for the sending and receiving of data across the upper layer boundary.

a. Requests for transmission of data are sent by the upper layer, using the Data Link Layer
(DL) Unitdata Request primitive, with the following parameters:

DL-Unitdata Request
Message ID
Destination(s)
Source
Topology Update ID
Quality of Service
Precedence
Throughput Requested (Normal/High)
Delay Requested (Normal/Low)
Reliability Requested (Normal/High)
Data/Data Length

b. Indications are provided to the upper layer through the DL-Unitdata Indication, DL-
Unitdata Status Indication, DL-Maximum Data Link Transmission Unit Indication, and DL-
Address Indication primitives with the following parameters:

DL-Unitdata Indication
Destination(s)
Source
Topology Update ID
Data/Data Length

DL-Status Indication
Message ID
Destination(s)
Acknowledgment Success/Failure
Connection Status
Neighbor detection

DL-Maximum Data Link Transmission Unit Indication

Maximum Data Link Transmission Unit

DL-Address Indication
Local Data Link Layer Address

96
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

DL-Error Indication
Description of Error

c. Descriptions of the above parameters follow:

(1) Message ID is an indicator established by the upper layer in the DL-

Unitdata Request and used to associate a subsequent DL-Status Indication
acknowledgment status with that request.

(2) The destination(s) can be 1 to 16 unicast, special or multicast (One-hop or

group) addresses.

(3) The source address is the unicast address of the outgoing link.

(4) Topology Update ID, in a DL-Unitdata Request, shall contain the most
recent Topology Update ID sent from the upper layer. Topology Update
ID, in a DL-Unitdata Indication, shall contain the Topology Update
Identifier field from the Transmission Header.

(5) Quality of Service parameters are used to determine the service provided
by the data link layer.

(a) Precedence parameters are used by the prioritized transmission

scheme and are used to order outgoing queues. The precedence
levels available to the network shall be mapped into three separate
levels (urgent, priority, and routine), two levels (urgent and
priority) or a single level (urgent) in the data link layer. DL
Precedence levels shall be mapped from the Intranet Sublayer of
the Network Layer as shown in TABLE VIII. The mapping into
three separate levels is the default but all three shall be available in
all systems. Whenever there are multiple Network Precedence
levels for a single Data Link Precedence, the higher Network
Precedence PDU shall be queued for transmission ahead of lower
Network Precedence PDUs (i.e., a PDU with a Network
Precedence of Flash shall be transmitted prior to a PDU with a
Network Precedence of Priority). The order of precedence levels
for Network Precedence is as shown in the Intranet Precedence
column in TABLE VIII (higher precedence shown first).

(b) Precedence and the other Quality of Service parameters are used to
select a preferred data link type of procedure. The recommended
mapping shown in TABLE IX is provided for guidance.

97
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

(c) The data link type of procedure may be predetermined regardless

of the Quality of Service parameters used.

(6) Data/Data Length is the block of data exchanged between the data link layer
and its upper layer user, and an indication of the data’s length.

(7) Acknowledgment Success/Failure is an indicator to inform the upper layer

whether a data link acknowledgment was received from the remote station
when high reliability was requested in a Unitdata Request.

(8) Connection Status is an indicator to inform the upper layer if a Type 2

connection has been established, reset or disconnected.

(9) Neighbor detection is an indicator to inform the upper layer when a data
link transmission is detected from a previously unknown station.

(10) Maximum Data Link Transmission Unit (MDLTU) parameter indicates the
largest value, in octets, that is permitted for the Data Length parameter in
the DL-Unitdata Request. Data Length parameter values that are larger
than MDLTU shall be failed with the corresponding DL-Status Indication
reflecting whether or not the message was transmitted as appropriate. The
default value for the MDLTU shall be 3345 octets. MDLTU values
contained in the MIL-STD-188-220D and MIL-STD-188-220D
w/CHANGE 1 Parameter Table shall be used when applicable for a specific
net configuration.

TABLE VIII, Intranet sublayer to Data Link Layer precedence mapping

98
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Mapping to use for three (3) separate access levels (Urgent, Priority and Routine)
TABLE VIII. Intranet sublayer to Data Link Layer precedence mapping - Continued

Mapping to use for two (2) access levels (Urgent and Priority/Routine mixed)

Mapping to use for one (1) access level (No distinction between Urgent, Priority and Routine)

99
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

TABLE IX. Mapping intranet TOS field to data link TOS.

TOS STATION CLASS (see 5.3.3.5)

D T R Precedence A B C D
0 0 0 Urgent 3 3 3 3
(& other) Priority 3 2 3 2
Routine 1 2 4 2
1 0 0 Urgent 3 3 3 3
Priority 3 2 3 2
Routine 1 1 1 1
0 1 0 Urgent 3 2 3 2
Priority 3 2 3 2
Routine 1 2 4 2
0 0 1 Urgent 3 2 3 2
Priority 3 2 3 2
Routine 3 2 4 2
NOTE: Type 3 Immediate Retransmission is invoked for Urgent precedence messages when
Delay, Throughput and Reliability (DTR) is 000 or 100.

5.4 Network Layer.

5.4.1 Intranet Protocol.

The Intranet Layer (IL), layer 3a, routes data packets between a source and possibly multiple
destinations within the same broadcast network. Intranet relaying may be used to transmit these
data packets via intermediate nodes. The IL also accommodates the exchange of topology and
connectivity information packets to support Intranet relaying path discovery. When necessary,
to maintain a high speed of service for small high precedence messages, the IL will break a
larger IL-Unitdata Request into multiple smaller IL Data Packet fragments prior to transmission
via the data link layer. The destination IL transparently reassembles the IL PDU fragments
received via the data link layer to recreate the original data prior to generating an IL-Unitdata
Indication.

5.4.1.1 Intranet Header.

FIGURE 30 defines the Intranet Header for all Intranet Message Types except Topology Update
(Intranet Message Type Field Value = 2). FIGURE 32 defines the Intranet Header when the
Intranet Message Type is Topology Update. The Version Number, Message Type, Intranet
Header Length (HLEN) and Type of Service (TOS) fields compose the mandatory fields of the
Intranet Header and shall be present in the Intranet Header of all Intranet Data Packets. When
Intranet Fragmentation/Reassembly is invoked per the requirements of 5.4.1.1.7, the optional
Message Identification Number, Total Number of Fragments, and Fragment Number fields shall
be present in addition to the mandatory fields, and any other optional fields in use. When
Intranet Relaying is being utilized the optional Message Identification Number, Maximum Hop
Count, Originator Address, and one to many Destination/Relay Status and Destination/Relay
Address fields shall be present in the Intranet Header as appropriate based on the topology of the
network in addition to the mandatory fields, and any other optional fields in use. The Intranet

100
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Header and any associated data contained in the IL Data Packet shall be exchanged using Data
Link Layer UI, I and/or DIA PDUs.

101
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

MSB LSB
7 6 5 4 3 2 1 0
MESSAGE TYPE VERSION NUMBER
INTRANET HEADER LENGTH
TYPE OF SERVICE
MESSAGE IDENTIFICATION NUMBER
FRAGMENT NUMBER TOTAL NUMBER OF
FRAGMENTS
SPARE MAX. HOP COUNT
ORIGINATOR ADDRESS
(Single Octet, Four Octets plus Marker, or Six Octets plus Marker)
.
.
.
DESTINATION/RELAY STATUS BYTE 1
DESTINATION/RELAY ADDRESS 1
(Single Octet, Four Octets plus Marker, or Six Octets plus Marker)
.
.
.
DESTINATION/RELAY STATUS BYTE 2
DESTINATION/RELAY ADDRESS 2
(Single Octet, Four Octets plus Marker, or Six Octets plus Marker)
.
.
.
DESTINATION/RELAYS 3 through N-1
.
.
.
DESTINATION/RELAY STATUS BYTE N
DESTINATION/RELAY ADDRESS N
(Single Octet, Four Octets plus Marker, or Six Octets plus Marker)
.
.
.
DESTINATION/RELAY ADDRESS N
(Single Octet or Four Octets plus Marker)
.
.
.

Note: N is the total number of Destination / Relay Address(es) required for the transmission. It is
limited to the size of the HLEN and the type of Data Link address format supported.

FIGURE 30. Intranet Header.

102
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.4.1.1.1 Version Number.

The Version Number shall indicate which version of the intranet protocol is being used. The
value of the Version Number is 2.

MIL-STD Version Version Number

MIL-STD-188-220A 0
MIL-STD-188-220B 0
MIL-STD-188-220C 0
MIL-STD-188-220D 1
MIL-STD-188-220D w/CHANGE 1 2
Undefined 3-15

If a station supporting MIL-STD-188-220D w/CHANGE 1 is connected to a network containing

stations supporting a different version of the MIL-STD it is possible that an IL PDU with a
Version field value other than 2 will be received by the station supporting MIL-STD-188-220D
w/CHANGE 1. Received IL PDUs with a Version field value that is not equal to 2 shall be
discarded by stations that implement only MIL-STD-188-220D w/CHANGE 1 and an IL-Error
Indication shall be generated indicating that an invalid Version field value was received, IL PDU
source/originator, the Message Type, and the unsupported Version field value.

5.4.1.1.2 Message Type.

The Message Type field is a number from 0 to 15 which indicates the type of data in the data
field of the IL packet. TABLE X lists all the valid Message Type field values. Since the
Message Type field in the Intranet Header is always present in information frames of any Data
Link Layer type, it is used to determine what type of data is borne by the Data Link information
frame. The transmission and reception of all valid message types indicated by the Message Type
field values shall be supported such that systems using MIL-STD-188-220 compliant
implementations can support any of the upper layer protocols corresponding to the valid message
types. MIL-STD-188-220 compliant systems shall support the upper layer interactions indicated
in the message type field for transmit and receive as indicated in TABLE X.

5.4.1.1.2.1 Interoperability with Internet Protocols (IP Packets).

Systems implementing the IP protocol at the Internet Sub-Layer of the Network Layer shall
implement Intranet message type 4 (IPv4 Packets) and type 11 (IPv6 Packets) as defined in
TABLE X at the Intranet Sub-Layer of the Network Layer. Systems implementing the IP
protocol shall implement both IPv4 and IPv6 protocols as a dual stack. For each network
attachment point, the system shall be able to configure that point to use either IPv4 or IPv6.
IPv4 and IPv6 are defined in RFC 791 and RFC 2460, respectively.

103
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

TABLE X. Intranet message types.

Field Value Transmit Receive Message Type

0 X X Reserved
1 C C Intranet Acknowledgment
2 C C Topology Update
3 C C Topology Update Request
4 M M IPv4 Packets (RFC 791)
5 M M ARP
6 O O XNP
7 M M MIL-STD-2045-47001 Header
(N-Layer Pass Through)
8 R R Reserved
9 R R Reserved
10 M M Segmentation/Reassembly (S/R) Protocol
(N-Layer Pass Through)
11 M M IPv6 Packets (RFC 2460)
12 to 15 X X Spare

Note for TABLE X: M indicates Mandatory for compliant systems, O indicates optional for
compliant systems, C indicates Conditionally Mandatory for compliant systems implementing
Intranet Relaying, X indicates that compliant systems should neither transmit nor accept IL
packets with this field value. The Message Types with a value of R are reserved for Situational
Awareness data internal to the FBCB2 system.

5.4.1.1.2.2 Address Resolution Protocol (ARP).

ARP is defined in Request For Comment (RFC) 826. All systems implementing IPv4 or N-
Layer Pass-Through shall be able to respond to an ARP request in accordance with RFC 826.
For hardware type (ar$hrd) = 22 (CNR), the source hardware address (ar$sha) field shall contain
the data link address (see 5.3.4.2.2). The hardware address length (ar$hln) field value
(specifying the number of octets in the hardware address field) shall be set to one octet when the
net is configured for 7-bit addressing or to four octets when the net is configured for 32-bit
addressing, or six octets when the net is configured for 48-bit addressing.

ARP is replaced by Neighbor Discovery and ICMPv6 in IPv6. Neighbor Discovery is defined in
RFC 2461 and ICMPv6 is defined in RFC 2463. Any system implementing IPv6 shall
implement both ICMPv6 and Neighbor Discovery. Systems shall not use ARP messages on
IPv6 networks.

5.4.1.1.2.3 Exchange Network Parameter (XNP).

XNP messages may be used for CNR management (see APPENDIX E).

104
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.4.1.1.2.4 MIL-STD-2045-47001 header.

When set to 7, the Intranet message type field specifies a direct connection from the IL to the
MIL-STD-2045-47001 Application header. This allows messages using N-layer pass through to
utilize the upper layer services provided by the MIL-STD-2045-47001 header.

5.4.1.1.2.5 Segmentation/Reassembly (S/R) Protocol.

When the Intranet Message type is set to 10, it specifies a direct connection from the Intranet
Header to the Segmentation/Reassembly Protocol header defined in MIL-STD-2045-47001.
This allows messages using N-layer pass through to utilize the upper layer services provided by
the Segmentation/Reassembly Protocol including segmentation, reassembly, ETE recovery, and
delivery to any application as specified within the S/R header destination port number.

5.4.1.1.3 Intranet Header length.

The HLEN field value shall indicate the number of octets in the Intranet Header only. The
HLEN field value shall be interpreted as follows:

HLEN Description
3 Minimum HLEN value. Basic 3-octet header. No Intranet
Fragmentation/Reassembly. No Intranet Relaying. Only the
mandatory fields will be present.
5 Intranet Fragmentation/Reassembly utilized. No Intranet Relaying.
Mandatory and Fragmentation/Reassembly fields will be present.
>= 9 Intranet Fragmentation/Reassembly optionally utilized. Intranet
Relaying utilized. Mandatory, Fragmentation/Reassembly, and
Relaying fields will be present.

When Intranet Relaying is utilized, the HLEN field value will vary based on the relay path
dictated by the intranet topology, number of destinations, and the size for the addresses being
utilized.

5.4.1.1.4 Type of Service (TOS).

The TOS field in the Intranet header is modeled exactly upon the Type of Service field in the
Internet header as described in RFC 791 paragraph 3.1.

5.4.1.1.5 Message identification number.

The message identification number shall be a number, 0-255, assigned by the originating host for
messages that require Intranet Fragmentation/Reassembly and/or that require Intranet Relaying.
For messages that require Intranet Fragmentation/Reassembly without Intranet Relaying, the
source address contained in the DL-Unitdata Indication combined with the Message
Identification Number field value shall uniquely identify fragments of the same message. For
messages that require Intranet Relay, the Originator Address field value combined with the
Message Identification Number field value shall uniquely identify relayed fragments of the same
message. Sending/Originating stations shall insure that the Message Identification Number field

105
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

value assigned to each pending message transmission is unique. After all 256 of the Message
Identification field values have been associated with a message transmission for the first time,
the least recently used Message identification field value associated with a message transmission
that is no longer pending shall be used for the next new message transmission.

5.4.1.1.6 Fragment Number.

The Fragment Number field shall have a numeric value, from 1 to 15, that indicates the position
of an intranet fragment relative to other intranet fragments generated by a source/originator for a
single Message Identification Number. The Fragment Number field value shall be less than or
equal to the Total Number of Fragments field value. The sending station shall number the
fragments contiguously starting with 1. When Intranet Fragmentation is not required and
Intranet Relaying is required, the Fragment Number field value shall be set to 1.

5.4.1.1.7 Total number of fragments.

The Total Number of Fragments field shall have a numeric value, from 1 to 15, that indicates the
total number of intranet fragments generated by an originator for a specific Message
Identification Number field value. All intranet fragments associated with the same Message
Identification Number field value shall have the same Total Number of Fragments field value.
The Total Number of Fragments field value shall be greater than or equal to the Fragment
Number field value. When Intranet Fragmentation is not required and Intranet Relaying is
required, the Total Number of Fragments field value shall be set to 1, indicating that Intranet
Fragmentation is not used.

5.4.1.1.7.1 Sending IL fragments.

When the number of octets contained in the Intranet Header combined with the number of data
related octets needed to be sent exceeds the MDLTU, the Intranet Layer of the sending station
shall break the data packet into fragments. The number of octets in each data fragment, when
combined with the size of the Intranet Header, shall be less than or equal to the MDLTU. An
identical Intranet Header, except for the Fragment Number field value, shall be pre-appended to
each data fragment to form an IL PDU fragment. The amount of data contained in each IL PDU
fragment shall be the same, except possibly for the last fragment, which may be smaller. The
Fragment Number field of the Intranet Header of each IL PDU fragment shall indicate the unique
position of each data fragment relative to the other fragments associated with the same Message
Identification Number field value.

5.4.1.1.7.1.1 Sending IL fragments requiring ETE Intranet Acknowledgments.

When an IL-Data Request requiring IL ETE Intranet Acknowledgment requires fragmentation,
special consideration is required with regard to selecting the size of the data fragments because
the size of the Intranet Header can be different when the message is retried subsequent to ETE
Intranet Acknowledgment timer expiration. The maximum size of the Intranet Header for the
initial and any subsequent retries shall be determined based on the current topology and then be
subtracted from the MDLTU in order to determine the size of the data fragments. For a given
topology the maximum Intranet Header size shall be bounded based on the maximum number of
Intranet hops permitted and the ultimate number of destinations of the message.

106
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.4.1.1.7.2 Receiving IL fragments.

When an IL fragment is received, a destination station shall attempt to reassemble it with any
other previously received fragments from the same source/originator having the same Message
Identification Number and Total Number of Segments field values. If Intranet Fragmentation is
used without Intranet Relaying, the source/originator is determined by using the DL-Unitdata
Indication Source address of the received fragment. If Intranet Fragmentation is used in
conjunction with Intranet Relaying, the source/originator is determined by using the Originator
Address field in the Intranet Header. Related fragments received over time at the destination
stations shall be reassembled back into the original data packet. The fragments shall be
reassembled at the proper location based on their relative positions as indicated by the Fragment
Number field value, Total Number of Fragments field value, and the fact that all fragments
except possibly the last fragment contain the same amount of data.

5.4.1.1.7.2.1 Reassembly logic.

The reassembly logic shall be able to handle segments received in an order different from the
order they were offered for transmission by the source/originator to its local Data Link Layer.
For example, segment 4 of 4 received prior to 1 of 4, 2 of 4, and 3 of 4 (all with the same
Message Identification Number from the same source/originator). The reassembly logic shall be
able to handle the receipt of duplicate fragments, e.g. 2 of 15 is received a second time before 3
of 15 through 15 of 15 are received. When all of the related data fragments are received (e.g.
segment 2 of 4 could be the last of the four segments received) and the message has been
successfully reassembled by the destination, an IL-Data Indication shall be generated by the
destination Intranet Layer. If an ETE Intranet Acknowledgment was requested by the
source/originator, it shall be generated as described below in 5.4.1.1.9.5 when the final segment
is received.

5.4.1.1.7.2.2 Reassembly inactivity timer.

The Reassembly Inactivity Timer value is an Intranet parameter that defines the timer period
measured from when the last fragment of a partially reassembled message was received until the
given message may be discarded due to the failure to receive another (possibly duplicate)
fragment related to the given message. In cases where no additional fragments are received
within a reasonable time period, partially reassembled messages may be discarded. Each time a
fragment is received that is associated with a partially reassembled message, the Reassembly
Inactivity Timer shall be started/restarted for the given message. The default value of the
Reassembly Inactivity Timer shall be two times the ETE Intranet Acknowledgment Timer.
There shall be one Reassembly Inactivity Timer for each partially reassembled message. When
the Reassembly Inactivity Timer expires, the partially reassembled message may be discarded.

5.4.1.1.8 Maximum hop count.

The maximum hop count shall be the maximum number of times this intranet packet can be
relayed on the radio net. A hop is defined as a single link between two adjacent nodes. This
number is set by the source host and is decremented each time a device receives the intranet
header. If the maximum hop count is decremented to 0, the intranet packet shall not be
forwarded any further, however it shall be processed locally if applicable.

107
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.4.1.1.9 Destination/Relay Status Byte.

The Destination/Relay Status Byte (see FIGURE 31) shall provide Intranet routing information
for each destination and/or relay address. In addition, this octet also selects ETE Intranet
Acknowledgments.

MSB LSB
7 6 5 4 3 2 1 0
ACK DES Relay Type REL Distance

FIGURE 31. Destination/Relay status byte.

5.4.1.1.9.1 Distance.
The distance subfield specifies how many hops a relay address is away from the originator node.
For final destination addresses which are not relayers, the distance field gives the number hops
from the originator node to the destination node.

5.4.1.1.9.2 REL.
The REL bit when set indicates that the given node will participate in relaying.

5.4.1.1.9.3 Relay Type.

The Relay Type bits indicate the type of relaying to be performed. The relay types are defined in
TABLE XI. The value of 0 indicates source directed relay defined in APPENDIX I.

TABLE XI. Relay Types.

0 Source Directed Relay

1 Spare
2 Spare
3 Spare

5.4.1.1.9.4 DES.
When the DES bit is set, the following address is at least one of the destinations for the packet.
The following address may also be a next hop relay for another destination.

5.4.1.1.9.5 ACK.
The ACK bit when set requests ETE Intranet Acknowledgments for the associated node only.
The procedure for ETE Intranet Acknowledgment follows.

108
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.4.1.1.9.5.1 Receiver generation of ETE Intranet Acknowledgment.

When a node has received all of the IL fragment(s) associated with the same source/originator
and Message Identification Number and the ACK bit is set in the IL fragment(s), it shall return
an Intranet Acknowledgment packet at the first possible opportunity. The Intranet
Acknowledgment packet shall have the same Message Identification Number as the received
Intranet fragment(s). The path specified in the Intranet Acknowledgment packet shall be the
reverse path specified in the most recently received Intranet fragment. The Intranet
Acknowledgment packet shall specify exactly one destination, namely the originator of the
received Intranet fragment(s).

5.4.1.1.9.5.2 ETE Intranet Acknowledgment Timer.

When an originator node sends an intranet fragment(s) with the ACK bit set, it shall start its ETE
acknowledgment timer after the last fragment is sent. The ETE acknowledgment timer is an
intranet parameter that defines the period within which a sending station shall expect to receive
an ETE acknowledgment for the associated IL fragment(s) from the destination(s). The value of
the ETE acknowledgment timer shall be a fixed factor plus a factor proportional to the number of
hops required for all destinations to receive the last fragment. The default value for the fixed
factor shall be 20 seconds. The default value for the proportional factor shall be twice the value
of the DL acknowledgment timer, multiplied by the number of hops to the furthest destination.
The maximum value for the ETE Intranet Acknowledgment Timer shall be 10 minutes (600
seconds).

5.4.1.1.9.5.3 Receiving an ETE Intranet Acknowledgment.

When an ETE Intranet Acknowledgment Packet is received, that destination shall be removed
from the list of destinations from which an acknowledgment is required. If no destinations
remain on the list, the ETE Intranet Acknowledgment Timer shall be stopped and an IL-Status
Indication shall be generated indicating that all destinations did acknowledge. When all
destinations have acknowledged, no further action is taken at the IL.

5.4.1.1.9.5.4 Expiration of the ETE Intranet Acknowledgment timer.

When the ETE Intranet Acknowledgment timer expires and the maximum number of Intranet
retransmissions has not been reached, the sending station shall retry the transmission of all of the
associated IL fragment(s) to any destinations that have not yet acknowledged the receipt of the
fragment(s). The number of retries shall be a value between 1 and 4, with a default of 2. Each
retransmission may use a new path to each destination that has not acknowledged. If only one
path exists to a destination, that path shall be used until either the acknowledgment is received or
the maximum number of Intranet retransmissions is exhausted. The size of the data contained in
each IL fragment shall be the same for the initial and each subsequent retransmission for the
same Message Identification Number. As a result of this approach, an acknowledgment may be
received from the destination(s) as soon as any missing fragments are retransmitted/received (i.e.
as soon as all the segments have been received). If an acknowledgment is not received from
every destination after the maximum number of Intranet retransmissions, an IL-Status-Indication
shall be sent to the upper layer specifying which destination(s) did and did not acknowledge the
IL PDU.

109
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Each retransmitted fragment shall have a recreated Intranet Header with the same Version,
Message Type, TOS, Message Identification Number, Fragment Number, and Total Number of
Fragments field values as the previous transmission. The Intranet Header shall be recreated to
specify an alternative path to the remaining destination(s) (if an alternate path exists) and the
Intranet Header Length field value shall be updated correspondingly. This recreated Intranet
Header shall specify paths only to nodes that have not already acknowledged the message. This
recreated Intranet Header shall only specify paths to nodes from which an acknowledgment is
required. This recreated Intranet Header shall include paths to all nodes from which an
acknowledgment is required, but from which an acknowledgment has not yet been received.

5.4.1.1.10 Originator address.

The originator address shall be the link layer address of the originating node. Single octet, four
octets, and six octets addressing may be used following the link layer addressing rules in
5.3.4.2.2. The four octets or six octets of address space shall be preceded by a single octet 32-bit
marker or 48-bit marker subfield, as per 5.3.4.2.2.2.

5.4.1.1.11 Destination/Relay address.

The intranet destination/relay address shall be the link layer address. It is either the destination
address for an intranet packet or the relay address. The extension bit (LSB) is available for use
by relaying procedures. Single octet, four octets, and six octets addressing may be used
following the link layer addressing rules in 5.3.4.2.2. The four octets or six octets of address
space shall be preceded by a single octet 32-bit marker or 48-bit marker subfield, as per
5.3.4.2.2.2.

5.4.1.2 Topology Update.

Connectivity and topology information of the intranet is essential for a node to initiate and/or
perform intranet relay. Each node on the radio network needs to determine what nodes are on
the network and whether they are 1 or more hops away. This information can be partially
determined passively by listening to a node’s traffic at layers 3a and 2 and/or actively by
exchanging topology information. The Topology Update data structure, defined in FIGURE 32,
has been provided for nodes in the Intranet to exchange topology and connectivity information.
FIGURE 32 supersedes FIGURE 30 when the Intranet Message Type is Topology Update.
APPENDIX H specifies the procedure for exchanging topology information between nodes.

5.4.1.2.1 Topology Update Length.

The Topology Update Length field is the length in octets of Topology Update data. This length
does not include the three octets for the Basic 3-Octet Intranet Header. Topology Update Length
shall be less than the MDLTU minus 3 octets.

5.4.1.2.2 Topology Update ID.

The Topology Update ID is a number from 1 to 255. Together with the originator’s link layer
address, the Topology Update ID uniquely identifies each Topology Update generated by the
originating node. This number shall be incremented by 1 every time a topology update is
generated. The Topology Update ID for the first Topology Update generated shall be 1.

110
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

MSB LSB
7 6 5 4 3 2 1 0
MESSAGE TYPE = 2 (Topology Update) VERSION NUMBER
INTRANET HEADER LENGTH = 3
TYPE OF SERVICE
Topology Update Length
Topology Update ID
Node 1 Address
(Single Octet, Four Octets plus Marker, or Six Octets plus Marker)
.
.
.
Node 1 Status Byte
Node 1 Predecessor Address
(Single Octet, Four Octets plus Marker, or Six Octets plus Marker)
.
.
.
Node 2 Address
(Single Octet, Four Octets plus Marker, or Six Octets plus Marker)
.
.
.
Node 2 Status Byte
Node 2 Predecessor Address
(Single Octet, Four Octets plus Marker, or Six Octets plus Marker)
.
.
.
Nodes 3 through N-1
.
.
.
Node N Address
(Single Octet, Four Octets plus Marker, or Six Octets plus Marker)
.
.
.
Node N Status Byte
Node N Predecessor Address
(Single Octet, Four Octets plus Marker, or Six Octets plus Marker)
.
.
.

FIGURE 32. Topology Update data structure.

5.4.1.2.3 Node Address.

The Node Address is the Data Link Layer address of node in the intranet.

111
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.4.1.2.4 Node Status Byte.

The ith Node Status Byte characterizes the link between originator host (the host whose address
appears in the originator address of the intranet header) and the ith node predecessor whose
address immediately follows the Node Status Byte as defined in FIGURE 33.

MSB LSB
7 6 5 4 3 2 1 0
QUIET NR HOP LENGTH LINK QUALITY

FIGURE 33. Node status byte.

5.4.1.2.4.1 Link Quality.

The Link Quality subfield for the ith node provides an assessment of the link quality between the
ith node predecessor and the ith node. The Link Quality is set to 0 if the quality of a link is
unknown. Increasing Link Quality value infers a poorer link. Link Quality is set to 7 to indicate
that the node is static. Static nodes do not trigger Intranet Topology Updates as they enter and
leave the network. TABLE XII lists the Link Quality values.

TABLE XII. Topology Link Quality values.

5.4.1.2.4.2 Hop Length.

The Hop Length subfield defined in TABLE XIII indicates the distance in hops from the source
to the given node. Hop Length = 1 means the node can be reached directly by the source - no
relays are required. A hop length of 0 indicates the source node itself or that the source may
know that node should be on the network but does not know where it is.

5.4.1.2.4.3 NR.
The NR bit when set to 1 indicates that the node is not participating as a relayer.

112
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.4.1.2.4.4 Quiet.
The Quiet bit, when set, indicates the node is either in Quiet Mode or going into Quiet Mode and
cannot transmit any traffic.

TABLE XIII. Hop Length values.

Hops Description
0 Unknown
1 0 relays required
2 1 relay required
3 2 relays required
4 3 relays required
5 4 relays required
6 5 relays required
7 6 or more relays required

5.4.1.2.5 Node predecessor address.

Each node maintains intranet topology as routing tree rooted at itself. For the ith node in the
routing tree, the Node Predecessor Address is the link layer address of the node one branch up
from the ith node in the routing tree. The predecessor for all nodes within 1 hop of the originator
node, which is the root of the routing tree is the originator node. The predecessor for all nodes n
hops away is a node which is n-1 hops away from the originator and that can talk directly with
the node n hops away. If the ith node has not been integrated into the source node’s routing tree,
the Node Predecessor Address for the ith node should be set to 0.

5.4.1.3 Topology Update Request message.

The Topology Update Request message, Intranet Relay Message Type 3, consists of the Intranet
Header with one originator and possibly multiple destination addresses. No Information field is
permitted. The maximum hop count and distance field shall be set to 1. The Relay, Relay Type,
and ACK bit shall be always zero. The DES bit shall be always 1. The destination address in
the Intranet Header shall be the link layer address to which this request has been made. The
addressing at the link layer may be either the One-hop multicast or the unicast link layer
addresses.

5.4.1.4 Forwarding of group multicast packets.

Forwarding of group multicast packets is an optional feature of MIL-STD-188-220D. When an
Intranet packet is received and a Group Multicast Address is present as a destination addresses in
the intranet header the packet shall be forwarded based the amount of topology information
available. If topology of the MIL-STD-188-220 subnetwork is not available (e.g., no optional
intranet topology update as defined in APPENDIX H) the packet shall be forwarded via the
limited flooding algorithm. If the topology is available, the packet shall be forwarded via
Reverse Path Forwarding algorithm. FIGURE 34 is an example of when multicast forwarding

113
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

would be needed. In FIGURE 34 if node 4 initiates a datagram addressed to the Global group
multicast address (e.g., ARP request to determine station 7 link layer address) Node 5 would
need to forward the intranet packet addressed to the group multicast address.

RF range

Intranet source =4 5 11
Intranet destination = M-cast 9
Link source address = is different on each
hop 6
Link Destination = M-cast 8

FIGURE 34. An example of Intranet forwarding

5.4.1.4.1 Limited flooding forwarding algorithm.

When a packet has a Group multicast address as a destination address in the intranet header, it
shall be forwarded via limited flooding when the topology is not known (e.g., intranet topology
update as described in APPENDIX H is not being used). A received packet addressed to a group
multicast address shall be forwarded only when the packet has been received for the first time.
In order to determine if this is the first time the packet has been received, each node should keep
a FIFO queue of the received multicast packets. Also the oldest entry in the queue should be
time stamped, aged and purged. The entries of the queue should contain Originator Address
field value, Message Identification Number field, and fragment ID if the packet is a fragment;
When an intranet packet is addressed to a group multicast address is received, it should be
checked for duplication at the intranet layer using the Originator Address field value, Message
Identification Number field, and fragment ID – if the packet is a fragment; therefore, when a
message is addressed to a Group multicast address, the Message Identification Number shall

114
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

always be included. If a received message is addressed to a group multicast address and it is not
a duplicate, it shall be forwarded, and if this node is a member of the group it shall be passed up
to the N+1 protocol layer. If the intranet packet is a duplicate it shall be discarded; assuming
there are not any unicast addresses included that need an acknowledgment.

115
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.4.1.4.2 Reverse Path Forwarding algorithm.

Intranet datagrams addressed to Group multicast shall be forwarded via Reverse Path
Forwarding (RPF) when the topology is known (e.g., intranet topology update as described in
APPENDIX H is being used). RPF uses the Originator address and the unicast routing table to
determine if the packet is on the shortest path back to the source (i.e., Intranet header’s
Originator Address). If the source link address of the multicast packet is on the shortest path
back to the source, then the packet shall be forwarded; however, if the receiving station is at the
end of the spanning tree the packet should not be forwarded. This essentially forms a separate
spanning tree from each source to every station in the subnetwork.

5.4.1.4.3 Mapping of an Intranet Group Multicast address to Link layer address(es).

When the N+1 layer (i.e., Subnetwork Dependent Convergence Function (SNDCF)) determines
that the IL-Unitdata Request-Destination address (i.e., the Intranet Destination address) is a
group multicast address, this address shall be mapped to a link layer destination address. A
packet may be addressed to a mulitcast address in the intranet header and unicast address(es) in
the data link header (e.g., the packet requires a high reliability). If the IL-Unitdata Request-
Quality of Service indicates a High Reliability is required, and if the topology is known, the link
layer should use reliable mechanism (e.g., type 3 unicast addressing) to transmit the packet to its
one hop neighbors hop(s): when using RPF the link layer frame would be addressed to the
unicast address of all one-hop neighbors with exception of the neighbor that is shortest path back
to the source, when using limited flooding it would be addressed to all one hop neighbors. If the
Unitdata Request-Quality of Service indicates a Normal Reliability, the IL-Unitdata Request-
Destination can be used as the Intranet and Link destination addresses.

5.4.1.5 Intranet Layer (IL) interactions.

The IL (Layer 3A) interacts with both the next higher layer (i.e., SNDCF) and next lower layer
to pass or receive information regarding services requested or performed. Three primitives are
used to pass information for the sending and receiving of data across the upper layer boundary.

a. Requests for transmission of data are sent by the upper layer, using the IL Unitdata
Request primitive, with the following parameters:

IL-Unitdata Request
Destination(s)
Source
Quality of Service
Precedence
Throughput (Normal/High)
Delay (Normal/Low)
Reliability (Normal/High)
Data/Data Length
Intranet Message Type
IL-Unitdata-ID

116
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

IL-Hopcount Limit

b. Indications are provided to the upper layer when data is received through the IL-
Unitdata Indication, IL-Status Indication, IL-Data Length Indication, and IL-Error Indication
primitive, with the following parameters:

IL-Unitdata Indication
Destination(s)
Source
Data/Data Length

IL-Status Indication
Acknowledgment success/failure
Intranet Path Status
IL-Unitdata-ID

IL-Data Length Indication

MTU
MTU without IL Fragmentation

IL-Error Indication
Description of Error

c. Descriptions of the above parameters follow:

(1) The destination can be 1 to 16 unicast or DL multicast (One-hop or group) addresses.

(2) The source address is the DL unicast address of the outgoing link.

(3) Quality of Service parameters are used in determining the service provided by the IL.
Quality of Service parameters are identical to those at the DL, described in 5.3.16.c(5).

(a) For IPv4, precedence shall be mapped from the TOS field (see 5.4.1.1.4) as
shown below. For IPv6 with Class Selector Codepoints (see RFC 2474), precedence shall be
mapped from the Differentiated Services (DS) field as shown below. For IPv6 with other DS
Codepoints, the IL precedence shall be selected to match the Per Hop Behavior (PHB) defined
by the DS Codepoint.

P0P1P2 Precedence
111 Network Control
110 Internet Control
101 CRITIC/Emergency Command Precedence (ECP)
100 Flash Override
011 Flash

117
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

010 Immediate
001 Priority
000 Routine

where the MSB is P0 and the LSB is P2.

(b) For IPv4, the other Quality of Service parameters shall be mapped from the TOS
field (see 5.4.1.1.4) as shown below. For IPv6, the DTR bits shown below shall be set to match
the PHB defined by the DS Codepoint in the DS field. For IPv6 with Class Selector Codepoints
(see RFC 2474), the D, T, and R bits shall be set to 0.

D=0 Normal Delay

D=1 Low Delay
T=0 Normal Throughput
T=1 High Throughput
R=0 Normal Reliability
R=1 High Reliability

(c) The ETE intranet acknowledgment procedures described in 5.4.1.1.9.5 shall be

used when R=1, and relaying is used to deliver the message to any destination of the packet.

(4) Data/Data Length is the block of data exchanged between the IL and its upper layer
(i.e. IP) user, and an indication of the data’s length.

(5) Acknowledgment Failure is an indicator to inform the upper layer if an Intranet

acknowledgment was not received from the remote station when high reliability was requested in
an IL-Unitdata Request.

(6) Whenever a node becomes reachable or unreachable, an Intranet Path Status

indication is sent to the upper layer identifying the destination link address.

(7) Intranet Message Type is defined in 5.4.1.1.2.

(8) IL-Unitdata-ID is an indicator established by the upper layer in the IL-Unitdata

Request and used to associate a subsequent IL-Status Indication acknowledgment status with that
request.

(9) Description of Error is provided with an IL-Error Indication. This should provide as
many details about the error as such that a communications knowledgeable operator reading the
description would likely be able to correct the condition that is causing the error.

118
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

(10) MTU is a numeric parameter provided with an IL-Data Length Indication. This
parameter indicates the maximum value permitted for the Data Length parameter in the IL-Unit
Data Request. IL-Unit Data Request with Data Length parameter values that are greater than the
MTU shall be failed by the IL resulting in no attempt to send the data. Systems shall default the
MTU to a value of 3090 bytes.

(11) MTU Without IL Fragmentation is a numeric parameter provided with an IL-Data

Length Indication. This parameter indicates the maximum value permitted for the Data Length
parameter in the IL-Unit Data Request such that IL fragmentation will not occur. IL-Unit Data
Request with the Data Length parameter value that are greater than the MTU Without IL
Fragmentation and less than or equal to MTU shall be honored using IL Fragmentation. IL-Unit
Data Request with a Data Length parameter value that is less than or equal to the MTU Without
IL Fragmentation shall be honored without the use of IL Fragmentation. Systems shall default
the MTU Without IL Fragmentation value to 3090 bytes.

(12) A Hopcount Limit set to “1” indicates that only the minimum Intranet Header is
required. Hopcount Limits greater than “1” indicate that the destination addresses need to be
included in the Intranet Header.

5.4.2 Subnetwork Dependent Convergence Function (SNDCF).

The ISO description of the network layer defines a subnetwork dependent convergence layer,
between the intranet and Internet layers. The layer shall assure that expected services are
provided within a particular subnetwork type for both IP datagram exchanges and n-layer pass
through exchanges. Note that the ISO description does not include n-layer pass through
exchanges. Implementers shall insure that n-layer pass through is supported. The functions
required to converge services within a MIL-STD-188-220 subnetwork (layers 3a and below)
services are: (1) determine the complete list of IP final destinations within the subnetwork; (2)
determine the associated subnetwork address(es) for each address; and (3) determine the
subnetwork Type of Service requirements (reliability, throughput, delay, immediate
retransmission and precedence) specified by the TOS field for IPv4 or the Differentiated
Services (DS) field for IPv6.

The Differentiated Service Working Group has defined a Differentiated Services architecture
(RFC 2475) for implementing service differentiation at the IP layer. As such, IPv4 TOS and
IPv6 Traffic Class have been re-named the DS field, when interpreted in accordance with RFC
2474. However, for the purpose of this standard, IPv4 TOS will remain as identified in RFC
791. Within the DS field, DS Codepoint values are used to select specific PHBs. Class Selector
Codepoints have been standardized to allow for compatibility with IPv4 legacy nodes, and have
the following structure: bits ”0 – 2” correspond to RFC 791 TOS Precedence bits, bits ”3 – 5”
are set to ”0”, and bits “6” and “7” must be set to ”0”. The RFC 791 TOS DTR bits are not
carried forth in the DS field.

The preceding information is contained in the IP header (for IP datagram exchanges) or in the
application interface (for n-layer pass through exchanges). If the IP protocol implementation

119
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

does not provide the required information, the SNDCF must query the upper layer to “learn” the
destinations and Type of Service. The SNDCF is only active for an IL-Unitdata request from the
upper layer. The convergence functions for a MIL-STD-188-220 subnetwork using n-layer pass
through exchanges or the Selective Directive Broadcast protocol described in RFC 1770 for IP
datagram exchanges are described below. Selective Directive Broadcast for IPv6 will be defined
in a future RFC.

5.4.2.1 Determine Destination function.

The Determine Destination function obtains final destination or the next hop to reach the final
destination information from the upper layer protocol (1) IP header for IP datagram exchanges or
(2) MIL-STD-2045-47001 application interface for n-layer pass through or (3) the application
associated with the Segmentation/Reassembly protocol for n-layer pass through). For IP
datagram exchanges, the next hop IP destination address which may be the IP destination
address field of the IP header is examined first. When the IP protocol (classful or classless [IPv4
or IPv6]) is used, IP forwarding determines which subnetwork provides a path to the next hop or
final destination using the IP destination address and a subnetwork mask (e.g.,192.168.0.1/24
[called slash notation or CIDR notation meaning there are 24 bits in the MASK] or
255.255.255.0 [Dotted decimal notation]). The IP address is divided into two parts: the network
portion of the IP address (NET ID) and the host portion of the IP address (HOSTID). In the
above address (192.168.0.1/24) the first 3 octets would be the NETID (i.e., 192.168.0) and the
last octet would be the HOSTID which is determined by the 24 bit mask. If the next hop IP
address is a unicast address, broadcast address (all 1’s), or multicast address (Class D IP
address), the Determine Destination function is complete and it passes the single IP address to
the Address Mapping Function. If the IP destination address is a directed broadcast address, (all
ones in the HOSTID portion of the IP address only) the network portion of the IP address (NET
ID) is compared to the local NET ID. If the NET ID portion of the directed broadcast address is
not the same as the local NET ID (logical and the next hop IP address with IP address assigned
to this station/MIL-STD-188-220 subnetwork), the single IP directed broadcast address is passed
to the Address Mapping function. If the NET ID portion of the directed broadcast IP address is
the same as the local NET ID, the Determine Destination function examines the IP option field
for the presence of the multi-address IP option (selective directed broadcast). If the option is
present, the list of IP addresses contained in the option is passed to the Address Mapping
function. If the option is not present, the single IP directed broadcast address is passed to the
Address Mapping function. For n-layer pass through exchanges, (MIL-STD-2045-47001 with or
without S/R) the interface shall provide the necessary addresses using the IL Unitdata Request
primitive.

5.4.2.2 Address Mapping function.

The SNDCF Address Mapping function is provided one or more addresses from the Determine
Destinations function. The Address Mapping function determines the Intranet address(es) and
link address(es) associated with an IP next hop address or with the addresses provided in the IL
Unitdata Request primitive. The upper-layer protocol is responsible for determining peer point
of attachment (e.g., IPv4 or IPv6 next hop address to reach the final destination in the IP
destination address field of the IP datagram). Application broadcast address(es), IP broadcast

120
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

(all 1’s) addresses and directed broadcast address for the local subnetwork are mapped to the
Intranet Global group multicast address or the One-hop broadcast address. The Intranet address
is a point of attachment to the subnetwork. If all nodes are one hop neighbors, the IP broadcast
address can be mapped to the One-hop neighbors; however, if there is a potential that all stations
in the MIL-STD-188-220 subnetwork are not One-hop away, the IP broadcast address should be
mapped to Global group multicast address and included in the Intranet header. When using the
four octet address mode (5.3.4.2.2), IPv4 unicast and multicast addresses do not require an
address mapping since the IP next hop address and the Intranet/data link address can be the
same. When using six octet address mode, IPv6 unicast and multicast addresses do not require
an address mapping since the Intranet/datalink destination address is extracted from the last 6
octets of the IPv6 next hop address. When the previous specified configurations are not used
(IPv4/four octet addressing or IPv6/six octet addressing) a mapping is required (e.g., single octet
addressing or N-layer pass through [mapping via ARP or a static mapping via a preloaded
database]).

5.4.2.3 Type of Service function.

The SNDCF TOS function obtains the requirements from the IPv4 Type of Service or IPv6
Differentiated Services header field or the IL Unitdata Request primitive. The values in the field
are provided to the IL protocol.

5.4.2.4 Intranet send request.

After the SNDCF layer performs all of its functions, it issues an IL-Unitdata Request that
includes the list of data link addresses and the Type of Service data.

5.4.3 Implementation directions.

Systems implementing this version of MIL-STD-188-220 shall be able to utilize/support UDP/IP
for transmission and receipt of upper layer protocols, i.e. MIL-STD-2045-47001 and
Segmentation/Reassembly (S/R) over MIL-STD-188-220 networks. Systems implementing this
version of MIL-STD-188-220 shall be able to utilize/support MIL-STD-188-220 N-Layer pass
through for the transmission and receipt of upper layer protocols, i.e. MIL-STD-2045-47001 and
S/R over the MIL-STD-188-220 networks. N-Layer pass through is used as a means of
improving net performance (by eliminating UDP/IP overhead) when communicating directly
with any destination over a MIL-STD-188-220 net.

5.5 Lower layer protocol network settings.

5.5.1 Reason for table.

MIL-STD-188-220 has a large number of parameters that makes it difficult to achieve
interoperability between operational systems. A table providing a list of pre-defined parameters
will reduce interoperability problems.

121
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

5.5.2 Table description.

TABLE XIV describes a standard set of lower layer protocols that may be used by all systems to
enhance interoperability. The table is a listing of typical numbered low level Operational
Parameter Sets (OPS). The table is constructed as follows:

a. Column 1 specifies the OPS number.

b. Column 2 describes the name of the DMTD typically used for the OPS.

c. Columns 3 to 20 define the RF and protocol parameters that shall be used by a DMTD to
comply with the OPS serial number.

d. Column 21 specifies the DMTD variants/models.

e. Column 22 provides additional comments where appropriate.

f. Additional numbered notes are provided after the table that refer to specific fields in the
table.

5.5.2.1 Table map.

TABLE XIV is too large (too many columns) to be viewed on one sheet. FIGURE 35 depicts the
overall configuration of TABLE XIV. For example, OPS code 1 on sheet 1 of 7 Operational
Parameter Settings stretches from the left panel crosses over to the right panel. Each OPS setting
identifies a different set of parameters extending down to sheets 5 and 6 of 7. The final sheet
contains all the notes.

MIL-STD-188-220D w/ Change 1

OPS 26 – 31 (Left Panel) OPS 26 – 31 (Right Panel)

TABLE XIV. Standard Network Settings.

(Sheet 7 of 7)

Comments

FIGURE 35. TABLE XIV map.

5.5.3 Table use.

Network managers may select a pre-defined OPS and promulgate its OPS number to all intended
users. Users may look up that OPS number and set the defined parameters in their system. A
system option may be used to automate the process so that when the system is initialized with an
OPS number, the parameters are automatically implemented. A new system wishing to join an
established network can be provided with the OPS number for that network. This process
reduces the probably of errors when given a long string of parameters. The use of the table is
optional but strongly recommended. If an OPS is selected from the table then the parameters in
columns 3 to 20 are mandatory.

5.5.4 Changing from OPS parameters.

A network may change parameters from an OPS at any time. However, if this is done then that
network can no longer be said to be using that OPS. If only a minor change is made to an OPS
(e.g. OPS 1 but using R-NAD rather than DAP-NAD) then a joining system may be told to
“…use OPS 1 with R-NAD”.

5.5.5 Custom OPS.

If a Custom OPS is chosen then this shall be referred to as OPS number “0”. This number shall
be associated with parameter settings other than those with OPS serial numbers, it shall simply
mean that custom settings are in use. Details of those settings shall be obtained by other means
as determined by the local procedures.

5.5.6 Requirements prior to new OPS code insertions.

In order for MIL-STD-188-220 to actually work properly and perform to high expectations for a
mix of radios when a standard configuration is selected, all of the stations on the MIL-STD-188-
220 net must use a common set of timing and protocol parameter values that are associated with
the standard configuration. Adding new radios to an existing standard configuration in the table
without doing the testing required to determine the parameters required to support these new
radios will only lead to more problems for developers trying to make the MIL-STD-188-220
standard configurations work properly. Therefore, prior to inclusion of a new OPS code the
C/S/A or nation sponsoring the required ICP shall provide DCE/Radio and DTE/System protocol
parameter data. The protocol parameters associated with the OPS code are:

123
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

DCE/Radio Parameters
o Equipment Preamble Time (EPRE)
o Phasing Time
o DCE_Tx-delay
o DCE_Rx-delay
o DCE TTURN
o DCE RTURN
o Hop Recovery Time

DTE/System Parameters
o Net Busy Sensing Time (B)
o ELAG
o DTE Processing Time (DTEPROC)
o DTE Turnaround Time (DTETURN)
o Tolerance Time (TOL)
o TURN
o TEST Time To Live (TTTL)
o Maximum Transmit Time (MTT)
o Type 2 ACK Timer
o Type 2 P-Bit Timer
o Type 2 Reject Timer
o Type 2 K Window
o Type 2 K2 Threshold
o Type 2 K3 Threshold
o Type 2 Response Delay Timer Percent
o Type 2 Maximum Number of Retransmissions, (N2)
o Type 3 Maximum Number of Retransmissions (N4)
o Type 3 DTE Acknowledgment Time (DTEACK)
o Type 4 ACK Timer
o Type 4 K Window
o Type 4 ACK List Length
o Type 4 Maximum Number of Retransmissions Attempts
o NAD Mechanism
o HNAD Urgent Percent
o HNAD Priority Percent
o HNAD Traffic Load
o RENAD Maximum Voice Factor
o RENAD Minimum Voice Factor
o RENAD Voice Factor Increment
o RENAD Voice Factor Decrement
o RENAD Maximum Scheduler Interval
o RENAD Minimum Scheduler Interval

124
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

o Topology Min Update Period

o Topology Update Precedence
o Topology Maximum Number of Subnetwork Hops
o Intranet Acknowledgment Timer (Fixed Factor)
o Intranet ACK Timer (Proportional Factor)
o Intranet Retransmit Count
o Intranet MTU without IL Fragmentation
o Intranet MTU with IL Fragmentation
o Initial Default Number of Stations
o XNP Join Request Time to Live
o XNP Joint Response Timer

Note: (1) Parameter Tables NBDT = EPRE + ELAG + B + TOL

5.5.6.1 Values.
Values for protocol parameters need only be provided for the relevant OPS fields, for example if
a new OPS line specifies DAP-NAD as the “MIL-STD-188-220 NAD Mechanism” then
parameters relating to other NAD schemes are not relevant. Parameters that are not relevant will
be indicated by “NA”.

125
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

TABLE XIV. Standard Network Settings.

Enable Data Link Layer

220 NAD Mechanism
LayerScrambling
Channel Spacing

Net Traffic Type

220 EDC Mode

220 Data Link

Concatenation
Crypto Mode
OPS Number

Crypto Type

On Transmit
Modulation
OPS Name

Hop Mode
Rate

0 CUSTOM Any Any Any Any Any Any Any Any Any Any Any
1 SINCGARS 4800 PT SC 4800 NRZ PT None SC N/A FEC/TDC Off DAPNAD Data Only True

2 SINCGARS 4800 CT SC 4800 NRZ CT Vinson SC N/A FEC/TDC Off DAPNAD Data Only True

3 SINCGARS 4800 CT FH 4800 NRZ CT Vinson FH N/A FEC/TDC Off DAPNAD Data Only True

4 SINCGARS 1200N PT SC 1200N NRZ PT None SC N/A None Off DAPNAD Data Only True
5 SINCGARS 1200N CT SC 1200N NRZ CT Vinson SC N/A None Off DAPNAD Data Only True
6 SINCGARS 1200N CT FH 1200N NRZ CT Vinson FH N/A None Off DAPNAD Data Only True
7 SINCGARS 2400N CT FH 2400N NRZ CT Vinson FH N/A None Off DAPNAD Data Only True
8 SINCGARS 4800N CT FH 4800N NRZ CT Vinson FH N/A None Off DAPNAD Data Only True
9 Two Wire 1200 PT SC 1200 FSK PT None SC N/A FEC/TDC Off DAPNAD Data Only True
1300
2100 Hz
10 Two Wire 32000 PT SC 32000 CDP PT None SC N/A FEC/TDC Off DAPNAD Data Only True
11 HF CONFIG 1200 CT SC 1200 NRZ CT ANDVT SC N/A FEC/TDC Off DAPNAD Data Only True

12 HF CONFIG 2400 CT SC 2400 NRZ CT ANDVT SC N/A FEC/TDC Off DAPNAD Data Only True

13 SATCOM 5KHZ 2400 2400 NRZ CT 3KG84 SC 5KHZ FEC/TDC Off DAPNAD Data Only True
3KG84

126
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

TABLE XIV. Standard Network Settings - Continued

Initial Default for Number Of

Initial Default for Enable Use
Topology Updates And Intra-

Of Net Busy Indication From

Supported By This Standard

Net Relay (can be changed)

Standard Parameter Tables)

Concatenation On Transmit

Configuration for new 220

Radio Equipment /Model

Configuration (Using 220

Stations (can be changed)
Initial Default for Enable

Row Specific Comments

Device (can be changed)

Initial Default Standard

Enable Physical Layer

nets (can be changed)

Local Station Class
OPS Number

OPS Name

Amplitude

0 CUSTOM Any Any Any Any Any Any No Any Note 1

1 SINCGARS 4800 PT SC False N/A D (1,2,3,4) False False 10 No RT-1439 (non ICOM), RT-1523 (ICOM), RT-
1523C (SIP), RT-1523E (ASIP)
2 SINCGARS 4800 CT SC False N/A D (1,2,3,4) False False 10 No RT-1439 (non ICOM), RT-1523 (ICOM), RT-
1523C (SIP), RT-1523E (ASIP)
3 SINCGARS 4800 CT FH False N/A D (1,2,3,4) False False 10 No RT-1439 (non ICOM), RT-1523 (ICOM), RT-
1523C (SIP), RT-1523E (ASIP)
4 SINCGARS 1200N PT SC False N/A D (1,2,3,4) False False 10 No RT-1523C (SIP), RT-1523E (ASIP)
5 SINCGARS 1200N CT SC False N/A D (1,2,3,4) False False 10 No RT-1523C (SIP), RT-1523E (ASIP)
6 SINCGARS 1200N CT FH False N/A D (1,2,3,4) False False 10 No RT-1523C (SIP), RT-1523E (ASIP)
7 SINCGARS 2400N CT FH False N/A D (1,2,3,4) False False 10 No RT-1523C (SIP), RT-1523E (ASIP)
8 SINCGARS 4800N CT FH False N/A D (1,2,3,4) False False 10 Yes RT-1523C (SIP), RT-1523E (ASIP)
9 Two Wire 1200 PT SC False Zero D (1,2,3,4) False N/A 10 No Field Wire
Dbm
10 Two Wire 32000 PT SC False N/A D (1,2,3,4) False N/A 10 No Field Wire
11 HF CONFIG 1200 CT SC False N/A D (1,2,3,4) False N/A 2 No PRC-150, KY99A/PRC-104, KY-99A/PRC-
138, ANDVT(AN/USC-43)/HFRG (URC-
131), ANDVT(AN/USC-43)/URC-109
12 HF CONFIG 2400 CT SC False N/A D (1,2,3,4) False N/A 2 No PRC-150, KY99A/PRC-104, KY-99A/PRC-
138, ANDVT(AN/USC-43)/HFRG (URC-
131), ANDVT(AN/USC-43)/URC-109

127
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

13 SATCOM 5KHZ 2400 False N/A D (1,2,3,4) N/A N/A 5 No PSC-5A (RT-1672/U(c)), PSC-5C (RT- Note 2
3KG84 1672C(c)/U), PSC-5D (RT-1672D(c)/U)
TABLE XIV. Standard Network Settings - Continued

Enable Data Link Layer

220 NAD Mechanism
220 Data Link Layer
Channel Spacing

Net Traffic Type

220 EDC Mode

Concatenation
Crypto Mode
OPS Number

Crypto Type

On Transmit
Modulation

Scrambling
OPS Name

Hop Mode
Rate

14 SATCOM 5KHZ 2400 2400 NRZ CT ANDVT SC 5KHZ FEC/TDC Off DAPNAD Data Only True
ANDVT

15 SATCOM 25KHZ 9600 9600 NRZ CT 3KG84 SC 25K FEC/TDC Off DAPNAD Data Only True
3KG84 HZ
16 SATCOM 25KHZ 16000 16000 NRZ CT Vinson SC 25K FEC/TDC Off DAPNAD Data Only True
VINSON HZ

17 UHF 16000 PT SC 16000 ASK PT None SC 25 FEC/TDC On DAPNAD Data Only False
kHZ
18 UHF 16000 CT SC 16000 NRZ CT Vinson SC N/A FEC/TDC On DAPNAD Data Only False
19 SINCGARS 16000 PT SC 16000 NRZ PT None SC N/A FEC/TDC On DAPNAD Data Only False
20 SINCGARS 16000 CT SC 16000 NRZ CT Vinson SC N/A FEC/TDC On DAPNAD Data Only False
21 RESERVED
22 HAVEQUICK 16000 CT FH 16000 NRZ CT Vinson FH N/A FEC/TDC On DAPNAD Data Only False
23 SINCGARS 16000 PT FH 16000 NRZ PT None FH N/A FEC/TDC On DAPNAD Data Only False
24 SINCGARS 16000 CT FH 16000 NRZ CT Vinson FH N/A FEC/TDC On DAPNAD Data Only False
25 SINCGARS 2400N PT SC 2400N NRZ PT NONE SC N/A None Off DAPNAD Data Only True

128
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

TABLE XIV. Standard Network Settings - Continued

Configuration for new 220 nets

Initial Default for Number Of
Initial Default for Enable Use
Topology Updates And Intra-

Of Net Busy Indication From

Supported By This Standard

Concatenation On Transmit

Net Relay (can be changed)

Standard Parameter Tables)

Radio Equipment /Model

Configuration (Using 220

Stations (can be changed)
Initial Default for Enable

Row Specific Comments

Device (can be changed)

Initial Default Standard

Enable Physical Layer

Local Station Class

(can be changed)
OPS Number

OPS Name

Amplitude
14 SATCOM 5KHZ 2400 False N/A D (1,2,3,4) N/A N/A 5 No PSC-5A (RT-1672/U(c)), PSC-5C (RT- Note 2
ANDVT 1672C(c)/U), PSC-5D (RT-1672D(c)/U),
ANDVT(AN/USC-43)/MD1324/WSC-3
15 SATCOM 25KHZ 9600 False N/A D (1,2,3,4) N/A N/A 5 No PSC-5A (RT-1672/U(c)), PSC-5C (RT- Note 3
3KG84 1672C(c)/U), PSC-5D (RT-1672D(c)/U)
16 SATCOM 25KHZ 16000 False N/A D (1,2,3,4) N/A N/A 5 No PSC-5A (RT-1672/U(c)), PSC-5C (RT- Note 3
VINSON 1672C(c)/U), PSC-5D (RT-1672D(c)/U), KY-
58A/WSC-3
17 UHF 16000 PT SC False N/A A (1,3) False N/A 6 No RT-1824(C), PRC-113
18 UHF 16000 CT SC False N/A A (1,3) False N/A 6 No RT-1824(C), PRC-113
19 SINCGARS 16000 PT SC False N/A A (1,3) False False 6 No RT-1824(C), RT-1439 (non-ICOM), RT-1523
(ICOM), RT-1523C (SIP), RT-1523E (ASIP)
20 SINCGARS 16000 CT SC False N/A A (1,3) False False 6 No RT-1824(C), RT-1439 (non-ICOM), RT-1523 Note 4
(ICOM), RT-1523C (SIP), RT-1523E (ASIP)
21 RESERVED
22 HAVEQUICK 16000 CT False N/A A (1,3) False N/A 6 No RT-1824(C), PRC-113
FH
23 SINCGARS 16000 PT FH False N/A A (1,3) False False 6 No RT-1824(C), RT-1439 (non-ICOM), RT-1523 Note 4
(ICOM), RT-1523C (SIP), RT-1523E (ASIP)
24 SINCGARS 16000 CT FH False N/A A (1,3) False False 6 No RT-1824(C), RT-1439 (non-ICOM), RT-1523 Note 4
(ICOM), RT-1523C (SIP), RT-1523E (ASIP)
25 SINCGARS 2400N PT SC False N/A D(1,2,3,4) False False 10 No RT-1439 (non ICOM), RT-1523 (ICOM), RT-
1523C (SIP), RT-1523E (ASIP)

129
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

TABLE XIV. Standard Network Settings - Continued

Enable Data Link Layer

220 NAD Mechanism
220 Data Link Layer
Channel Spacing

Net Traffic Type

220 EDC Mode

Concatenation
Crypto Mode
OPS Number

Crypto Type

On Transmit
Modulation

Scrambling
OPS Name

Hop Mode
Rate

26 SINCGARS 2400N CT SC 2400N NRZ CT VINSON SC N/A None Off DAPNAD Data Only True
27 SINCGARS 4800N PT SC 4800N NRZ PT NONE SC N/A None Off DAPNAD Data Only True
28 SINCGARS 4800N CT SC 4800N NRZ CT VINSON SC N/A None Off DAPNAD Data Only True
29 SINCGARS 9600N PT SC 9600N NRZ PT NONE SC N/A None Off DAPNAD Data Only True
30 SINCGARS 9600N CT SC 9600N NRZ CT VINSON SC N/A None Off DAPNAD Data Only True
31 SINCGARS 9600N CT FH 9600N NRZ CT VINSON FH N/A None Off DAPNAD Data Only True

Column Specific Comments

130
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

TABLE XIV. Standard Network Settings - Continued

Configuration for new 220 nets

Initial Default for Number Of
Initial Default for Enable Use
Topology Updates And Intra-

Of Net Busy Indication From

Supported By This Standard

Concatenation On Transmit

Standard Parameter Tables)

Net Relay (can be changed)

Radio Equipment /Model

Configuration (Using 220

Stations (can be changed)
Initial Default for Enable

Row Specific Comments

Device (can be changed)

Initial Default Standard

Enable Physical Layer

Local Station Class

(can be changed)
OPS Number

OPS Name

Amplitude
26 SINCGARS 2400N CT SC False N/A D (1,2,3,4) False False 10 No RT-1439 (non ICOM), RT-1523 (ICOM),
RT-1523C (SIP), RT-1523E (ASIP)
27 SINCGARS 4800N PT SC False N/A D (1,2,3,4) False False 10 No RT-1439 (non ICOM), RT-1523 (ICOM),
RT-1523C (SIP), RT-1523E (ASIP)
28 SINCGARS 4800N CT SC False N/A D (1,2,3,4) False False 10 No RT-1439 (non ICOM), RT-1523 (ICOM),
RT-1523C (SIP), RT-1523E (ASIP)
29 SINCGARS 9600N PT SC False N/A D (1,2,3,4) False False 10 No RT-1439 (non ICOM), RT-1523 (ICOM),
RT-1523C (SIP), RT-1523E (ASIP)
30 SINCGARS 9600N CT SC False N/A D (1,2,3,4) False False 10 No RT-1439 (non ICOM), RT-1523 (ICOM),
RT-1523C (SIP), RT-1523E (ASIP)
31 SINCGARS 9600N CT FH False N/A D (1,2,3,4) False False 10 No RT-1439 (non ICOM), RT-1523 (ICOM),
RT-1523C (SIP), RT-1523E (ASIP)

Column Specific Comments Note 5 Note 6 Note 7 Note 8 Note 9

131
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

TABLE XIV. Standard Network Settings - Continued

Notes:
1 When the operator changes from a Standard Configuration to Custom “0” Configuration, parameter values initially remain unchanged, and then
parameters that are normally not editable as part of a standard configuration, e.g. rate, can be changed to any value that results in a supportable
combination of parameter values.
2 Requires a dedicated 5KHZ Satellite Channel whose bandwidth will then be shared among MIL-STD-188-220 capable stations. The DAMA method of
sharing a SATCOM channel is not yet supported using MIL-STD-188-220.
3 Requires a dedicated 25KHZ Satellite Channel whose bandwidth will then be shared among MIL-STD-188-220 capable stations. The DAMA method of
sharing a SATCOM channel is not yet supported using MIL-STD-188-220.
4 Improved network throughput may be realized by turning the Scrambling feature OFF.
5 The amplitude parameter only applies for nets that use FSK encoding. The Zero Dbm value for FSK over wireline provides maximum power for longer
wire lengths.
6 SINCGARS provides an early net busy indication on the Squelch Pin. When this SINCGARS net busy indication is used, the shorter net busy detect time
in the MIL-STD-188-220 parameter table should be used. Because not all MIL-STD-188-220 capable stations, e.g. those equipped with older TCIM 1
models, the default configuration is to Disable the use of the net busy indication from SINCGARS such that net busy detect time will be set consistently
at all MIL-STD-188-220 stations. The setting of this parameter is not a mandatory part of the standard configuration (even though it is critical that all
stations on a SINCGARS net use the same Net Busy Detect Time).
7 This is just a recommended default parameter setting for when a standard configuration is initially selected. The number of stations is not a mandatory
part of the standard configuration.
8 This is just the recommended default standard configuration setting for when a new MIL-STD-188-220 net is created. This default is not a mandatory part
of the standard configuration.
9 The timing parameters that are used with these standard configuration and are a part of the MIL-STD-188-220 standard were only tested against the
indicated radio equipment (in the indicated modes) and may not be compatible with other equipment/models (and/or equipment modes).

132
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

6 NOTES
(This section contains information of a general or explanatory nature that may be helpful, but is
not mandatory.)

6.1 Subject term (key word) listing.

The follow key words and phrases apply to this document.

Asynchronous Mode
Combat Network Radio (CNR)
Data Communications Protocol
Data Link Layer
Error Detection and Correction
Golay
HAVEQUICK
Interoperability
Intranet
Logical Link Control
Media Access Control
MIL-STD-188-220
MIL-STD-2045-47001
Network Access Delay (NAD)
Packet Mode
Packets
Radio
Relay
Robust Communications Protocol (RCP)
SINCGARS
Synchronous Mode
Tactical Internet
Topology Update
Type of Service (TOS)
VMF
XNP

6.2 Issue of the DoD index of specifications and standards.

When this document is used in procurement, the applicable issue of the DoDISS will be cited in
the solicitation.

6.3 Interoperability considerations.

This section addresses some of the aspects that terminal designers and systems engineers should
consider when applying MIL-STD-188-220 in their communications system designs. The proper
integration of MIL-STD-188-220 into the total system design will help to ensure the
interoperability of stations that exchange information over a data communications link consisting
of a DMTD, a transmission channel, and a DMTD or C4I system.

133
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

6.3.1 Transmission channel.

For the purpose of this document, the transmission channel (from the transmitter to the receiver)
is considered transparent to the DMTD subsystem. However, the transmission channel will be
interoperable within itself. The transmission channel may be secured or non-secured, using such
media as line-of-sight (LOS) radio, high frequency (HF) radio, wireline, and satellite
communications (SATCOM).

6.3.2 Physical interface.

The specific details of the physical interface for connecting DMTDs to the equipment that
implements the transmission channel are beyond the scope of this document. The actual physical
connections will depend on the interface characteristics required by the particular transmission
equipment. These unique physical interface characteristics may be defined in the equipment
specifications or in technical interface specifications. Therefore, the requirements for the
electrical features (such as data, clock, and control) and mechanical features (such as connectors,
pin assignments, and cable) of the connection between the DMTD and the associated
transmission channel equipment are left to the equipment designer. The design philosophy is
that what appears at the input end of the transmission channel should be the same at the output
end. Implementation notes for effecting a working interface to specific radios are provided in
the following subparagraphs.

6.3.2.1 SINCGARS System Improvement Program (SIP) Receiver/Transmitter (R/T) interface.

The DTE (DMTD or C4I system) interacts with the DCE via an X.21 data interface and an
External Control Interface. When the precedence level of the transmission changes, the DTE
will set the precedence level for the new transmission via the External Control interface. This
precedence level will correspond to the frame with the highest precedence value within the series
of concatenated frames.

Information on interfaces for SINCGARS ASIP radios can be found in the following reference:

Interface Control Document (ICD) Title

A3266178 SINCGARS ASIP – RT1523E Advanced

SINCGARS SIP Interface Control
Document

6.3.2.1.1 Carrier Sense Multiple Access (CSMA) network access.

Although all SINCGARS SIP R/Ts in a given network are not required to use the same CSMA
slot offsets and limits for voice and/or precedence levels, it is highly recommended that the same
slot settings be used within a network. All SINCGARS SIP R/Ts in a network will be using the
same slot width (18ms - FH; 54ms - SC) and the same mode of operation (plain text or cipher
text).

134
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

6.3.2.1.2 Network Busy Sensing and receive status.

The presence of multiple stations on a single random access communications network requires
voice/data Network Busy Sensing and the use of NAC to reduce the possibility of data collisions
on the net. The combined Data and Voice Networks require cooperation between the DTE
(DMTD or C4I system) and the DCE.

The DCE indicates the presence of receive data and voice via the X.21 Indication line “I” signal.
A precise determination of the network status is obtained via the X.21 DTE Receive line “R”
signal in combination with the “I” signal:

I = OFF and R = 1’s -> Idle/Transmission Completed

I = OFF and R = Flags -> Data being transmitted

I = ON and R = Flags -> Data being received

I = ON and R = 1’s -> Voice operation if this condition persists for more than 750
msec. From 0 to 750 msec the radio is busy, but voice or
data reception can’t be determined until either the presence
of flags on the R-line for data or the expiration of 750 msec
when voice reception is assumed.

The transmission of data takes effect by driving the X.21 Control line “C” (push-to-talk) and
DTE Transmit line “T”, as follows:

Verify I = OFF and R = 1’s, then assert C = ON and send flags T = Flags

Verify I = OFF and R = Flags, then transmit data T = Data

Upon transmit completion, assert C = OFF and send T = 1’s

The time between the SINCGARS SIP R/T detection of network busy and the determination of
network busy with voice is added to any suspended timers. The timers are suspended in the INC
only after network busy with voice is indicated. Therefore, adding the time period in which the
radio detects network busy with “something” until network busy with voice is determined
accounts for the period of time voice was actually present.

6.3.2.1.3 Network Timing Model parameters.

The Network Timing Model is described in APPENDIX C. The model defines parameters
necessary to ensure interoperability. It is important to ensure that all systems participating in a
network use the same parameter values. Parameter values are provided in a separate document
entitled “MIL-STD-188-220 Parameter Table”, which is available on the CNRWG website
specified at 2.3.4. This table should be utilized by all systems.

135
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

6.3.2.1.4 Other SINCGARS SIP implementation details.

a. The RE-NAD slot assignment for Type 3 PDUs is offset=0, limit=0. The “offset” is the
number of the first slot while the “limit” is the number of slots associated with the particular
parameter (e.g., a precedence level). Offset=0, limit=0 means there is no randomized delay
associated with the Type 3 PDUs or the returned Type 3 acknowledgments in the SIP R/T due to
the RE-NAD process. The 0-second Immediate Mode scheduler is used with these PDUs and
returned acknowledgments so that no additional randomized delay is incurred from the INC
(where the scheduler is implemented).

b. The SINCGARS SIP R/T does not manipulate any trailing flags included in the data
stream presented to it. These flags are transmitted over the air.

c. From the SINCGARS SIP R/T perspective, any trailing flags are part of the data stream
and should be calculated into DATA.

d. The DTE (e.g. INC) will achieve synchronization with the SINCGARS SIP R/T within
four flag sequences. Data may be sent upon detection of a valid flag sequence.

6.3.2.2 SINCGARS Integrated COMSEC (ICOM) R/T interface.

Information on interfaces for SINCGARS ICOM radios can be found in the following reference:

Interface Control Document (ICD) Title

A3017864 SINCGARS ICOM – Receiver-Transmitter

Radio RT-1523

6.3.2.2.1 NRZ physical interface between DTE and R/T.

The SINCGARS ICOM digital data interface to a DTE is a synchronous, unbalanced, half-
duplex serial interface.

a. The signaling format is NRZ, at voltage levels compatible with those specified in MIL-
STD-188-114A for a single receiver load termination.

b. Digital data rates of 600, 1200, 2400, 4800 and 16000 bps are supported by the ICOM
R/T. When a data rate below 16000 bps is selected at a transmitter, a Data Rate Adapter (DRA)
internal to the ICOM converts the data to 16000 bps, using majority logic FEC techniques.

c. The ICOM R/T also provides a receive squelch indication to the DTE when channel
activity is sensed.

6.3.2.2.2 Network Busy Sensing and receive status.

Network Busy Sensing provides a mechanism to manage channel access among members of a
common network. Without managed channel access, multiple stations attempting simultaneous

136
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

transmissions will collide, degrading network performance. Managing channel access also
minimizes the network performance loss due to mixing both voice and data in a common net.

a. For both voice and digital data receptions, the DCE provides a receive squelch
indication via the Analog Data Mode Control_Not (ADMC_N) line. This ADMC_N squelch
indication is a composite signal from several internal sources. Using this signal, the worst-case
network busy detect times are 350 msec for FH and 100 msec for SC.

b. For digital data receptions, the DCE presents a synchronous clock on the Digital Data
Clock Out (DDCO) line. ADMC_N will typically precede DDCO for all digital data receptions.
The exception is for PT 16000 bps data, when both ADMC_N and DDCO will be coincident.

c. For voice receptions, the DCE will provide a receive squelch indication via ADMC_N,
but will not present DDCO.

d. If both ADMC_N and DDCO are considered as binary signals, there are four possible
indications which a DTE can use to infer network status. TABLE XV summarizes the four
possible receive states and their interpretation.

TABLE XV. SINCGARS ICOM receive states.

ADMC_N Active ADMC_N Inactive

DDCO Active Digital data reception Not Applicable
DDCO Inactive Voice reception R/T idle

6.3.2.2.3 Network Timing Model parameters.

The Network Timing Model is described in APPENDIX C. Parameter values are provided in a
separate document entitled “MIL-STD-188-220 Parameter Table”. This table should be utilized
by all systems.

6.3.2.3 HAVEQUICK II R/T interface.

6.3.2.3.1 Network Timing Model parameters.

The Network Timing Model is described in APPENDIX C. Parameter values are provided in a
separate document entitled “MIL-STD-188-220 Parameter Table”. This table should be utilized
by all systems.

6.3.2.4 COMSEC interoperability.

The COMSEC function provides a link encryption capability. In the traditional COMSEC mode
of operation, the COMSEC function (normally implemented in ancillary equipment) is
considered part of the transmission channel. In the embedded COMSEC mode, the COMSEC
function is an integral part of the DMTD subsystem.

137
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

6.3.3 Data Link Layer.

The following implementation details should be considered when implementing the DL of MIL-
STD-188-220:

a. The first bit of the Transmission Header that is transmitted (after the flag) will be the
FEC selection bit and the last bit transmitted will be bit 9 of FIGURE 11.

b. The last 2 sentences of 5.3.1 says that the TDC block for the 12-bit TWC and 64-bit
Transmission Header contains seven 24-bit codewords, encoded as a 168-bit TDC block.
5.3.14.2 says that if the (12+64=76, plus a few inserted zeros) data bits do not divide into an
integral number of 12-bit segments, fill bits of zeros are added to the end. Note that this does
NOT require the PL to parse the Transmission Header, since the length of the Transmission
Header is fixed at 64 bits (see FIGURE 9).

c. Reliable broadcast involves the need for stations to return an acknowledgment to the
originator of messages that are received with only the multicast data link address (see
5.3.4.2.2.2.1 and 5.3.4.2.2.2.2 -- the broadcast address is used at higher protocol layers) -- and
the receiving station is not individually addressed in the message. There is no requirement for
reliable broadcast at the Intranet or Data Link layer.

d. Type 4 acknowledgments (DRR and DRNR are discussed in 5.3.7.4.5.3.1.2 and

5.3.7.4.5.2.3, respectively) may be transmitted twice. The second transmission of the
DRR/DRNR should be concatenated with other data link frame transmissions. The DTE should
not access the network merely to transmit the second DRR/DRNR.

e. When a station receives an out-of-sequence I frame (see 5.3.7.2.5.4) it may send either
an REJ or SREJ, depending upon whether the station can perform resequencing. A station
should send SREJ when it can resequence received I frames and should send REJ otherwise.

f. N4 (see 5.3.8.1.4.c) is the number of permitted re-transmissions. The number of times

that a message may be transmitted is N4+1.

g. The following definition of Quiet Mode (see 5.3.11.2) will be used: When a station can
not determine whether another station is in Quiet Mode, it should assume that the station is not in
Quiet Mode. The fact that a station has entered Quiet Mode will be known globally over the
Internet. While there is a possibility that some stations will not get the information, or will
ignore the information; the protocol will not try to fix the problem. Specifically, there is no
requirement for the last relayer to issue a proxy acknowledgment for stations that are operating
in Quiet Mode.

6.3.3.1 Frequency of Access Ranking (FOAR).

FOAR is intended to increase the fairness of network access in DAP-NAD and DAV-NAD.
This paragraph describes a network management tool that may be used as a stand alone
mechanism or integrated into the system. It is recommended that systems implementing DAP-
NAD or DAV-NAD utilize the FOAR algorithm to designate Station Number (SN). The

138
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

algorithm requires that stations be numbered sequentially from 1 to NS where NS represents the
total number of stations participating in the subnetwork. The number 1 should be provided to
the station expected to require the most accesses (busiest station) and the highest number (NS)
provided to the least busy station. The algorithm for this scheme is shown below.

SN = ((FOAR + 1) / 2): if FOAR is odd

SN = FOAR/2 + (INT (NS + 1) / 2): if FOAR is even, where INT (NS +1)/2 is a number
truncated to the nearest integer.

Example: Using a network with 8 nodes (A-H). H is busiest, A is next busiest, B is next, D is
next and G is least. The ordering for FOAR would be H, A, B, D, C, E, F, G which are assigned
sequential numbers 1-8 respectively.

Station Station FOAR Station Number for DAP-NAD

Name

H 1 1=(1+1)/2
A 2 5=2/2 + INT ((8+1)/2)
B 3 2=(3+1)/2
D 4 6=4/2 + INT ((8+1)/2)
C 5 3=(5+1)/2
E 6 7=6/2 + INT ((8+1)/2)
F 7 4=(7+1)/2
G 8 8=8/2 + INT ((8+1)/2)

A network manager would provide each participating system in the network with a unique
Station Number based on the above algorithm.

6.3.3.2 Generation of unique six octet Data Link Layer address for IPv6.
Section 5.3.4.2.2.1.3.2 requires any system using IPv6 at the Network Layer to have a static and
universally unique six octet Data Link Layer address. This is a condition that must be met in the
commercial world for Ethernet cards, which serve as the primary means of participation on the
internet. This is achieved through the use of 48-bit Extended Unique Identifiers (EUI-48), which
are regulated by the Institute of Electrical and Electronics Engineers (IEEE). EUI-48 values are
formed by concatenating a 24-bit Organizational Unique Identifier (OUI) administered by the
IEEE Registration Authority and a 24-bit extension identifier assigned by the organization with
that OUI assignment. This allows the assignee to generate approximately 16 million unique
EUI-48 values.

The recommended implementation for guaranteeing a static and universally unique six octet
Data Link Layer address in MIL-STD-188-220 applications is to follow the commercial
standards as closely as possible. This presents the advantages of capitalizing on commercial
practices and reducing government overhead. Equipment using IPv6 for the Network Layer will

139
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

obtain its six octet Data Link Layer address in one of two ways, depending on the status of the
hardware.

6.3.3.2.1 Pre-fielded equipment.

This method for assigning six octet Data Link Layer addresses applies to equipment that have
not yet been fielded (i.e. delivered equipment in spares status, laboratory equipment, and
commercial equipment).

a. The equipment Vendor must register for an OUI with the IEEE Registration Authority.

b. The equipment Vendor must serialize their equipment produced that uses IPv6 at the
Network Layer with a MIL-STD-188-220 protocol stack using 24-bit serial numbers, which
serves as a 24-bit extension identifier.

c. The equipment Vendor assigns the static six octet Data Link Layer address to the
equipment by concatenating their Vendor OUI with the equipment serial number.

d. The Vendor must store this six octet address in the equipment in non-volatile memory.

e. The Vendor must provide a utility for changing this stored address.

6.3.3.2.2 Fielded equipment.

This method for assigning static and universally unique six octet Data Link Layer addresses
applies to equipment that is actively fielded.

a. The fielding Service must register for an OUI with the IEEE Registration Authority.

b. The fielding Service must assign the equipment a 24-bit Unit Reference Number (URN),
which serves as a 24-bit extension identifier.

c. The fielding Service uses the Vendor-supplied utility for changing the stored six octet
Data Link Layer address to assign the static and universally unique address, formed by
concatenating their Service OUI with the equipment URN.

Additional information concerning the commercial standard (EUI-48) can be found here:
http://standards.ieee.org/regauth/oui/tutorials/EUI48.html .

6.3.4 Intranet Layer.

The following implementation details should be considered when implementing the DL of MIL-
STD-188-220:

a. Relayers optionally may collapse the Intranet Header to remove addresses that are not
on the path to or from the relaying node (see 5.4.1.1.9.5.1). The destination node would still
have sufficient information to return an acknowledgment. Interoperability is not affected
because the complete path between originator and destination is not corrupted. Collapsing the

140
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

Intranet Header would minimize bandwidth utilization but would probably increase processing
time at each relayer and could destroy information that might be useful to network management
functions.

b. The source node will be included as the first entry in every Topology Update (see
5.4.1.2) sent by the INC. The Node Address and Node Predecessor will be set to the station ID
(link address) of the source node. The Quiet and Non-relay Status bits will be set to that
station’s current status. The hop length field will be set to 0. The remaining entries in the
Topology Update have no implied ordering. A node aware only of itself will generate an initial
update containing just its own entry.

c. Topology Update messages (see 5.4.1.2) are broadcast unreliably.

d. In the Topology Update Data Structure (FIGURE 32), the “node address” and “node
predecessor address” (see 5.4.1.2.3 and 5.4.1.2.5, respectively) have been implemented in the
INC and some IDMs in the following manner, for single octet addressing only:

Both of these addresses are “the link address of the node in the Intranet”. The link
address is seven bits long (see 5.3.4.2.2.1). As such, bits 0 through 6 contain the “link
address” used in the node address and node predecessor address. Bit 7 will be zero.
Note: The C/R bit and the extension bit associated with the link address will not be used
in the Topology Update Data Structure.

e. Topology Update (see 5.4.1.2) and Topology Update Request messages (see 5.4.1.3) use
Data Link Type 1, unacknowledged, procedures.

f. The precedence of Topology Update (see 5.4.1.2) and Topology Update Request
messages (see 5.4.1.3) is user defined.

g. Receiving a Topology Update Request (see 5.4.1.3) indicates an operational two-way

(bi-directional) link.

h. It is possible for the Min_Update_Per parameter (see H.4.4.2) to take different values on
a node-by-node basis within a net. There is essentially no problem unless one of the nodes takes
the value 0. Assume node A has this value set to 0. Node A is not permitted to respond to
topology requests. Nodes without traffic for this node issue topology update requests to try to
set up links. Node A does not respond. Once a node (e.g. B) sets up a valid link with a link
layer acknowledgment, a topology update listing this connection is advertised. All other nodes
without a link will switch to a 2-hop path using node B as a relayer to node A. Therefore, it is
logical that the Min_Update_Per value should be set on a network-wide basis. An alternative
solution is available: The non-participant can announce this fact in a Topology Update message
that identifies itself in the Node 1 Address field and the Node 1 Predecessor Address field and by
setting the NR bit in the Node 1 Destination/Status Byte.

141
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

i. I.5.3 presents the solution to Source Directed Relay Example 3 as C-E-F-G-H-D. An

equally valid solution is D-C-E-F-G-H.

6.3.4.1 Allocation of memory required for reassembly.

The allocation of finite memory resources used for reassembling fragments must be considered.
When available, implementations should allocate the total amount of memory required to
reassemble the original data based on the Total Number of Fragments field value and the amount
of data contained in the first complete fragment (i.e. not the fragment with Fragment Number
equal to Total Number of Fragments) received. Once all of the memory required for reassembly
is allocated, received fragments can be copied directly to the proper location within memory,
even in the case that a fragment is received out of order. In the event that adequate memory is
not available to reassemble a higher precedence message, the reassembly of one or more lower
precedence messages with the smallest number of received fragments should be aborted such
that the memory space required to begin reassembling the higher precedence message can be
allocated.

6.3.4.2 Deallocation of memory used for reassembly.

The deallocation of finite memory resources used for reassembling fragments must be
considered. After a IL-Data Indication has been generated (subsequent to the reassembly of all
fragments associated with a source/originator and Message Identification Number) and the upper
layer protocol has finished processing the received message, or if the Reassembly Inactivity
Timer has expired, storage for that message can be deallocated and reused for the reassembly of
subsequent packets.

6.3.5 CNR Management process using XNP.

a. The CNR Management process is recommended to reduce operator burden by providing

automated support for the management function.

b. There is no requirement to respond to an XNP Join Request message (see E.4.2.1). If

operational conditions permit, an interval timer may be used to schedule the retransmission of an
XNP Join Request message (see E.6.2).

6.3.6 Interoperation with Internet Protocols.

a. Figure 4 of RFC 791 (Internet Protocol) is interpreted as having the LSB on the RIGHT.
This means that the Internet Header Length (IHL) field will be transmitted before the Version
Number by the MIL-STD-188-220 lower layers.

b. Message exchanges using this standard over CNR should be accomplished using User
Datagram Protocol (UDP), as described in RFC 768. Transmission Control Protocol (TCP),
described in RFC 793, should be reserved for upper layer services that require Transport layer
reliability.

142
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

c. The Internet Address Numbering Authority has assigned Open Shortest Path First
Version 2 (OSPF2) (see RFC 2328) interface Type Value 85 for CNR.

6.4 Changes from previous issue.

Marginal notations are used in this revision to identify changes with respect to the previous
issue.

143
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX A

ABBREVIATIONS AND ACRONYMS

A.1 General.

A.1.1 Scope.
This appendix used to contain a list of abbreviations and acronyms pertinent to
MIL-STD-188-220. The acronyms are in section 3 of this standard. This appendix is left blank
to maintain appendix conformity.

144
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

DOD STANDARDIZED PROFILE IMPLEMENTATION CONFORMANCE

STATEMENTS (DSPICS) REQUIREMENTS LIST (DPRL)

B.1 General.
This appendix has two functions:

a. It provides the DoD Standardized Profile Implementation Conformance Statements

(DSPICS) Requirements List (DPRL) for implementations of Combat Net Radios. An
implementation’s completed DPRL is called the DSPICS. The DSPICS states which features,
capabilities and options have been implemented by any system built using this standard.

b. It provides a summary of which MIL-STD-188-220 features and capabilities are

mandatory or optional. In the event that there is an apparent conflict between this appendix and
the main volume, one of the following actions shall be taken:

1. The “mandatory” option shall be selected in preference to the “optional” option.

2. The matter shall be referred to the CNRWG for adjudication.

The main part of this appendix is a fixed-format questionnaire divided into a number of major
sections; these can be divided into subsections each containing a group of individual items.
Answers to the questionnaire items shall be provided in the Support column by simply marking
an answer (i.e., by checking the applicable entry) to indicate a restricted choice (Yes or No) or
by entering a value or a set of range of values.

145
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

The structure of the DSPICS questionnaire consists of 3 main sections:

(1) Physical Layer

(2) Data Link Layer
(3) Network Layer [Intranet and Subnetwork Dependent Convergence
Function (SNDCF)]
An item identification number in the first column identifies each item. The second column
contains the statement of function or the question to be answered. The third column contains the
reference to the material that specifies the item in the main body of the standard. The next two
columns record the status of the item – whether support is mandatory, optional, prohibited or
conditional – and provide the space for answers. The last column is used to list comments by
their numerical endnote designator.

Implementers shall show the extent of compliance by completing the DPRL. That is,
compliance to all mandatory requirements and the options that are not supported are shown. The
resulting completed DPRL is called a DSPICS. If a conditional requirement is inapplicable, the
“No” choice shall be used. If a mandatory requirement is not satisfied, exception information
must be supplied by entering a reference Xi in the Notes column, where i is a unique identifier,
to an accompanying rationale for the noncompliance.

B.1.1 Scope.
This appendix contains the minimum set of MIL-STD-188-220 features required for joint
interoperability. It is intended to be used by a variety of personnel including system designers,
procurers, implementers, developers and users. The following shall use the DSPICS:

a. The protocol implementer, as a checklist to reduce the risk of failure to conform to the
standard through oversight and to inform any interested parties of the system implementation.

b. The supplier and acquirer or potential acquirer of the implementation, as a detailed

indication of the capabilities of the implementation, stated relative to the common basis for
understanding provided by the standard DSPICS proforma.

c. The user or potential user of the implementation, as a basis for initially checking the
level of interoperability with another implementation. (Note that, while interoperability can
never be guaranteed, failure to interoperate can often be predicted from incompatible DSPICSs).

d. A protocol tester, as the basis for selecting appropriate tests against which to assess the
claim for conformance of the implementation.

B.1.2 Application.
The content of this appendix is a mandatory part of MIL-STD-188-220. The information
contained herein is intended for compliance.

146
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

B.2 Applicable documents.

None.

B.3 Notation.
The following notations and symbols are used in the DPRL to indicate the status of features:

Status Symbols
M - mandatory
M.<n> - support of every item of the group labeled by the same numeral <n> required,
but only one is active at a time
O - optional
O.<n> - optional, <n> is the number of optional selections
P - item number
P:O.<n> - parent item number of this option and number of options related to the parent
when there is more than one
C - conditional
NA - non-applicable (i.e., logically impossible in the scope of the profile)
X - excluded or prohibited
i - out of scope of profile (left as an implementation choice)

In addition, the symbol “•” is used to indicate an option whose status is not constrained by the
profile (status in the base standard). The O.<n> notation is used to show a set of selectable
options (i.e., one or more of the set must be implemented) with the same identifier <n>.

Notations for Conditional Status

The following predicate notations are used:

<predicate>:: This notation introduces a group of items, all of which are conditional on
<predicate>.
<predicate>: This notation introduces a single item, which is conditional on <predicate>.

In each case, the predicate may identify a profile feature, or a Boolean combination of
predicates. (“^” is the symbol for logical negation.)

<index>: This predicate symbol means that the status following it applies only when the
DSPICS states that the features identified by the index are supported. In the
simplest case, <index> is the identifying tag of a single DSPICS item. The
symbol <index> also may be a Boolean expression composed of several indices.
<index>:: When this group predicate is true, the associated clause should be completed.

147
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

Support Column Symbols

The support of every item as claimed by the implementer is stated by checking the appropriate
answer (Yes or No) in the support column:

Yes Supported by the implementation

No Not supported by the implementation
- Not applicable

B.4 Implementation requirements.

MIL-STD-188-220 requirements are described in Section 5 and APPENDIX B, APPENDIX C,
APPENDIX D, APPENDIX E, APPENDIX F, APPENDIX G, APPENDIX H, APPENDIX I,
APPENDIX J, APPENDIX K, and APPENDIX L. This appendix categorizes requirements,
identified by MIL-STD-188-220 paragraph numbers, as Mandatory, Conditional or Optional.
Unless otherwise specified, the category assigned to a requirement applies to all subordinate
subparagraphs for the requirement. Fully compliant systems shall implement all mandatory and
conditional requirements. Minimally compliant systems shall implement all mandatory
requirements and some conditional requirements as described in this appendix.

B.5 Detailed requirements.

For detailed requirements see ANNEX A.

148
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

A.1 MIL-STD-188-220D Profile Protocol Stack.

MIL-STD-188-220D Layers Base Standard

NETWORK LAYER 5.4
INTRANET LAYER 5.4.1
DATA LINK LAYER 5.3
PHYSICAL LAYER 5.1 & 5.2

A.2 Implementation Identification.

Supplier
Contact point for queries about the DSPICS
Implementation Name(s) and Version(s)
Other information necessary for full identification
(e.g. name(s) and version(s) of machines and/or
operating systems, system name(s))

A.2.1 Protocol Summary.

Identification of Protocol Military Standard, Interoperability Standard for Digital

Specification Message Transfer Device Subsystems, MIL-STD-188-220D.
Military Standard, Interoperability Standard for Digital
Message Transfer Device Subsystems, MIL-STD-188-220D.
Am.: Corr.:

Am.: Corr.:
Identification of amendments and
corrigenda to the DSPICS
Am.: Corr.:
Proforma
Am.: Corr.:

Am.: Corr.:

Protocol Version(s) supported

Date of Statement

149
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

A.3 CNR Requirements List.

The following tables give the DPRL for the MIL-STD-188-220 Intranet Layer, Data Link Layer and Physical Layer.
The support column describes the implementation.

A.3.1 Basic Requirements.

Item
Protocol Feature Reference Status Support Notes
(series)
5.1
100 Physical Layer M Yes__ No__
5.2
200 Data Link Layer 5.3 M Yes__ No__
300 Network Layer 5.4 M Yes__ No__
301 Intranet Layer Protocol 5.4.1 M Yes__ No__
Subnetwork Dependent
302 5.4.2 M Yes__ No__
Convergence Function (SNDCF)
Lower layer protocol network
303 5.5 O Yes__ No__
settings

A.4 Physical Layer DPRL.

Item Protocol Feature Reference Status Support Notes

100 Physical Layer 5.1 M Yes__ No__
The physical layer (PL) shall
provide the control functions
100.a required to activate, maintain, and 5.1 M Yes__ No__
deactivate the connections
between communications systems
5.1.1
101 Transmission Channel Interfaces M Yes__ No__
APPENDIX L
102 Physical Layer Protocol 5.2 M Yes__ No__

A.4.1 Transmission Channel Interfaces.

Item Protocol Feature Reference Status Support Notes

5.1.1
101 Transmission Channel Interfaces M Yes__ No__
APPENDIX L

Item Protocol Feature Reference Status Support Notes

200 Data Link Layer 5.3 M Yes__ No__
The data link layer shall provide
the control functions to ensure the
transfer of information over
200.a established physical paths, to 5.3 M Yes__ No__
provide framing requirements for
data, and to provide for error
control
201 Transmission Header 5.3.1 M Yes__ No__
202 Network Access Control (NAC) 5.3.2 M Yes__ No__
203 Types of Procedures 5.3.3 M Yes__ No__
204 Data Link Frame 5.3.4 M Yes__ No__
205 Operational Parameters 5.3.5 M Yes__ No__
206 Commands and Responses 5.3.6 M Yes__ No__
207 Description of Procedures by Type 5.3.7 M Yes__ No__
208 Data Link Initialization 5.3.8 M Yes__ No__
209 Frame Transfer 5.3.9 M Yes__ No__
210 Flow Control 5.3.10 M Yes__ No__
211 Acknowledgment and Response 5.3.11 M Yes__ No__
212 Invalid Frame 5.3.12 M Yes__ No__
213 Retransmission 5.3.13 M Yes__ No__
102.1.3.1:M Yes__ No__
Error Detection and Correction (not
214 5.3.14 102.1.3.2:M Yes__ No__
used in packet mode)
102.1.3.3:X No
Data Scrambling (not used in
215 5.3.15 O Yes__ No__
packet mode)
216 Data Link Layer Interactions 5.3.16 O Yes__ No__

Item Protocol Feature Reference Status Support Notes

202 NAC 5.3.2 M Yes__ No__
As a minimum, DAP-NAD and R-
NAD shall be available to regulate
202.a transmission opportunities for all 5.3.2 M Yes__ No__
participants when the network is
operating in Synchronous Mode.
202.1 Network Busy Sensing Function APPENDIX C M Yes__ No__
202.2 Response Hold Delay (RHD) APPENDIX C M Yes__ No__
202.3 Timeout Period (TP) APPENDIX C M Yes__ No__
202.4 NAD APPENDIX C M Yes__ No__
202.4.1 R-NAD APPENDIX C M Yes__ No__
202.4.2 P-NAD APPENDIX C O Yes__ No__
202.4.3 H-NAD APPENDIX C O Yes__ No__
202.4.4 RE-NAD APPENDIX C O Yes__ No__
202.4.5 DAP-NAD APPENDIX C 102.1.3.2:M Yes__ No__
202.4.6 DAV-NAD APPENDIX C O Yes__ No__
5.3.2.1,
C.4.4.4.1.1
202.5 Scheduler 202.4.4:M Yes__ No__
C.4.4.4.1.5
C.4.4.4.1.6
When a station has data to
transmit, it shall calculate the 5.3.2.1
202.5.a 202.5:M Yes__ No__
scheduler timer as indicated in C.4.4.4.1
APPENDIX C
When this timer expires, the link
layer shall first determine that the
202.5.b 5.3.2.1 202.5:M Yes__ No__
previous frame concatenation was
transmitted by the PL
If the frame concatenation was not
202.5.c transmitted, the link layer shall 5.3.2.1 202.5:M Yes__ No__
request its transmission

159
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

If a higher precedence individual
frame becomes available for
202.5.d transmission, the concatenated 5.3.2.1 202.5:M Yes__ No__
frames shall be re-built to include
the higher precedence frame
If the previous frame
concatenation was transmitted, the
link layer shall build a new frame
202.5.e 5.3.2.1 202.5:M Yes__ No__
concatenation. This frame
concatenation shall then be passed
to the PL for transmission

A.5.3 Types of Procedures.

Item Protocol Feature Reference Status Support Notes

203 Types of Procedures 5.3.3 M Yes__ No__
Type 1 Operation (unacknowledged
203.1 5.3.3.1 M Yes__ No__
connectionless)
Type 2 Operation (connection-
203.2 5.3.3.2 O Yes__ No__
mode)
With Type 2 operation, a data link
connection shall be established
203.2.a between two systems prior to any 5.3.3.2 203.2:M Yes__ No__
exchange of information bearing
PDUs
The connection normally shall
203.2.b remain open until a station leaves 5.3.3.2 203.2:M Yes__ No__
the net
Type 3 Operation (acknowledged
203.3 5.3.3.3 M Yes__ No__
connectionless)
Type 4 Operation (decoupled
203.4 5.3.3.4 O Yes__ No__
acknowledged connectionless)
203.5 Station Class 5.3.3.5 M Yes__ No__
203.5.a Class A 5.3.3.5 203.5:O.<4> Yes__ No__
203.5.b Class B 5.3.3.5 203.5:O.<4> Yes__ No__
203.5.c Class C 5.3.3.5 203.5:O.<4> Yes__ No__
203.5.d Class D 5.3.3.5 203.5:O.<4> Yes__ No__

160
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

A.5.4 Data Link Frame.

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

The value of k indicates the
maximum number of DIA PDUs
that a station may have
208.1.4.a.
outstanding (awaiting 5.3.8.1.5.c 203.4:M Yes__ No__
10
acknowledgment) to all stations at
any given time. The value of k
ranges from 5 - 40 DIA PDUs.
A minimum-length valid data link
208.1.4.a. PDU shall contain exactly 2 flags,
5.3.8.1.5.d 203.4:M Yes__ No__
11 2 address fields, one (1) 16-bit
control field, and the FCS
208.1.4.a. The minimum number of octets in
5.3.8.1.5.d 203.4:M Yes__ No__
12 a valid data link PDU shall be 10
The number of Type 4 DIA frames
remembered in the list used to
208.1.4.a. detect and discard duplicates. The
5.3.8.1.5.e 203.4:M Yes__ No__
13 number in the list can range from 0
- 255. The value of “0” is used to
turn off this detect capability.

A.5.9 Frame Transfer.

Item Protocol Feature Reference Status Support Notes

209 Frame Transfer 5.3.9 M Yes__ No__
The data link layer shall request
209.a the transmission of a frame by the 5.3.9 M Yes__ No__
PL
209.1 PDU Transmission 5.3.9.1 M Yes__ No__
PDUs shall be queued for
transmission in such a manner that
209.1.a the highest precedence PDUs are 5.3.9.1 M Yes__ No__
transmitted before lower
precedence PDUs
If a prioritized net access scheme
is active, the precedence access
209.1.b level used shall be the precedence 5.3.9.1 M Yes__ No__
of the PDU that is to be
transmitted next
Transmission units of the same
209.1.c 5.3.9.1 M Yes__ No__
precedence shall be in FIFO order

231
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

Type 2 I PDUs for a particular
connection shall be transmitted in
209.1.d 5.3.9.1 203.2:M Yes__ No__
the order of their sequence
numbers
209.2 Data Link Concatenation 5.3.9.2 M Yes__ No__
All receiving stations shall be able 5.3.9.2
209.2.a to de-concatenate the reception M Yes__ No__
into separate PDUs
Data link concatenation to add 5.3.9.2
another interior data frame shall
not be performed if the resulting
209.2.b frame would take longer to M Yes__ No__
transmit than the maximum
transmit time allowed for the
network
209.3 Physical Layer Concatenation 5.3.9.3 O Yes__ No__
The time to transmit the combined 5.3.9.3
length of the transmission frame,
209.3.a shall not exceed the maximum O Yes__ No__
transmit time allowed for the
network
The PL shall transmit each 5.3.9.3
transmission unit following the
complete PL procedures with no
209.3.b additional bits between Interior O Yes__ No__
Transmission Units (except for bit
synchronization when used in
Asynchronous Mode)
Note that the Phasing field shall
5.3.9.3
209.3.c precede the first Interior O Yes__ No__
5.2.1.2
Transmission Unit only
209.4 PDU Transmissions 5.3.9.4 M Yes__ No__
The PDU that did not allow
concatenation shall be at the head
209.4.a 5.3.9.4 M Yes__ No__
of its appropriate queue for the
next net access period

232
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

If the first PDU in the highest
precedence level queue (or only
queue) does not allow
209.4.b 5.3.9.4 M Yes__ No__
concatenation, it shall be the only
PDU transmitted in that net access
period

A.5.10 Flow Control.

Item Protocol Feature Reference Status Support Notes

210 Flow Control 5.3.10 M Yes__ No__
210.1 Type 1 Flow Control 5.3.10.1 M Yes__ No__
Stations shall correlate Flow
210.1.a Control information for Type 1 5.3.10.1 M Yes__ No__
and Type 3 communications
210.2 Type 2 Flow Control 5.3.10.2 203.2:M Yes__ No__
The maximum number (k) of
sequentially numbered I PDUs that
may be outstanding (that is,
210.2.a unacknowledged) at any given 5.3.10.2 203.2:M Yes__ No__
time is a data link connection
parameter, which shall never
exceed 127
210.3 Type 3 Flow Control 5.3.10.3 M Yes__ No__
Stations shall correlate Flow
210.3.a Control information for Type 1 5.3.10.3 M Yes__ No__
and Type 3 communications
210.4 Type 4 Flow Control 5.3.10.4 203.4:M Yes__ No__

A.5.11 Acknowledgment and Response.

Item Protocol Feature Reference Status Support Notes

211 Acknowledgment and Response 5.3.11 M Yes__ No__
All UI, DIA or I PDUs that require
203.3:M Yes__ No__
an acknowledgment shall be
211.a 5.3.11 203.2:M Yes__ No__
acknowledged except for the
203.4:M Yes__ No__
following cases:

233
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

The control field of the received 203.3:M Yes__ No__
211.a.1 PDU specifies that no 5.3.11.a 203.2:M Yes__ No__
acknowledgment is required 203.4:M Yes__ No__
203.3:M Yes__ No__
The Quiet Mode (described in 5.3.11.b
211.a.2 203.2:M Yes__ No__
5.3.11.2), has been set to ON 5.3.11.2
203.4:M Yes__ No__
203.3:M Yes__ No__
The receiving station is a multicast
211.a.3 5.3.11.c 203.2:M Yes__ No__
(One-hop or group) addressee only
203.4:M Yes__ No__
203.3:M Yes__ No__
The receiving station's unicast
211.a.4 5.3.11.d 203.2:M Yes__ No__
address is not in the address field
203.4:M Yes__ No__
203.3:M Yes__ No__
211.a.5 The PDU is invalid 5.3.11.e 203.2:M Yes__ No__
203.4:M Yes__ No__
211.1 Acknowledgment 5.3.11.1 M Yes__ No__
211.1.1 Type 3 Acknowledgment 5.3.11.1.1 M Yes__ No__
Each Type 3 PDU, shall be
211.1.1.a responded to before another PDU 5.3.11.1.1 M Yes__ No__
is transmitted
All Type 3 UI and TEST
211.1.1.b command PDUs shall be 5.3.11.1.1 M Yes__ No__
acknowledged
The RHD procedures shall be
followed by all stations on the
5.3.11.1.1
211.1.1.c network to allow each responding M Yes__ No__
C.4.2
station an interval in which they
can transmit their response
211.1.2 Type 2 Acknowledgment 5.3.11.1.2 203.2:M Yes__ No__
Type 2 PDUs that require
211.1.2.a acknowledgment shall activate the 5.3.11.1.2 203.2:M Yes__ No__
acknowledgment timer
211.1.3 Type 4 Acknowledgment 5.3.11.1.3 203.4:M Yes__ No__
The DIA PDU shall activate the
211.1.3.a 5.3.11.1.3 203.4:M Yes__ No__
acknowledgment timer
211.2 Quiet Mode 5.3.11.2 M Yes__ No__

234
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

The protocol shall allow an
operator to initiate Quite Mode as
an override feature that, when
211.2.a invoked, prevents any transmission 5.3.11.2 M Yes__ No__
(including retransmission) without
explicit permission from the
operator
As a security feature, the operator
shall be able to turn off automatic
211.2.b 5.3.11.2 M Yes__ No__
transmission but still continue to
receive
Normal protocol exchange shall
211.2.c occur when the Quiet Mode is 5.3.11.2 M Yes__ No__
OFF
The Quiet Mode shall override the
Maximum Number of
211.2.d 5.3.11.2 M Yes__ No__
Retransmissions data link
parameters
UI, I or DIA PDUs received by a
station with Quiet Mode ON shall
211.2.e be serviced in the normal way 5.3.11.2 M Yes__ No__
except nothing is returned nor
queued for later transmission
211.3 Immediate Retransmission 5.3.11.3 O Yes__ No__

A.5.12 Invalid Frame.

Item Protocol Feature Reference Status Support Notes

212 Invalid Frame 5.3.12 M Yes__ No__
A frame is invalid if it has one or
212.a more of the following 5.3.12 M Yes__ No__
characteristics:
Frame not bounded by a beginning
212.a.1 5.3.12.a M Yes__ No__
and ending flag
212.a.2 Frame is too short if it is < 9 bytes 5.3.12.b M Yes__ No__
Frame is too long if it is > the 5.3.12.c
212.a.3 M Yes__ No__
maximum PDU length 5.3.8.1.1.a
Frame has an invalid address or
212.a.4 5.3.12.d M Yes__ No__
control field

235
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

212.a.5 Frame has an FCS error 5.3.12.e M Yes__ No__
Any invalid frame shall be
212.b 5.3.12 M Yes__ No__
discarded

A.5.13 Retransmission.

Item Protocol Feature Reference Status Support Notes

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

Each received TDC block matrix Recv: Send: Recv:
Send:
214.3.i shall be rotated to form the 5.3.14.3 214: Yes__ Yes__
214:O
original 16 x 24 matrix M No__ No__
The TDC decoder at the receiver Recv: Send: Recv:
Send:
214.3.j shall perform the inverse of the 5.3.14.3 214: Yes__ Yes__
214:O
TDC encoding process M No__ No__

A.5.15 Data Scrambling.

Item Protocol Feature Reference Status Support Notes

102.1.3.1:O Yes__ No__
215 Data Scrambling 5.3.15 102.1.3.2:O Yes__ No__
102.1.3.3:X No
Data scrambling shall be
performed if the transmission
medium does not have a DC
215.a response and there is the 5.3.15 215:M Yes__ No__
possibility that “long” strings of
the NRZ ones and zeros are
transmitted
CCITT V.36 scrambling shall not
be applied outside the FEC
215.b 5.3.15.b 215:M Yes__ No__
because bit errors at the receiver
will be extended
If CCITT V.36
scrambling/descrambling is used,
the contents of the 20-state shift
215.c register shall be initialized to all 5.3.15.b O Yes__ No__
ones prior to scrambling or
descrambling data link frames in
each interior transmission unit
The adverse state detector (ASD)
counter shall be initialized such
that at least 32-bits are counted,
215.d 5.3.15.b O Yes__ No__
starting from the first bit input to
the 20-state shift register, when the
first adverse state is detected
The operation of the
215.e scrambling/descrambling shall be 5.3.15.b O Yes__ No__
as shown

239
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

A.5.16 Data Link Layer Interactions.

Item Protocol Feature Reference Status Support Notes

216 Data Link Layer Interactions 5.3.16 O Yes__ No__
216.a DL Unitdata Request parameters 5.3.16.a O Yes__ No__
216.b.1 DL-Unitdata Indication parameters 5.3.16.b O Yes__ No__
216.b.2 DL-Status Indication parameters 5.3.16.b O Yes__ No__
DL-Maximum Data Link
216.b.3 5.3.16.b O Yes__ No__
Transmission Unit Indication
216.b.4 DL-Address Indication 5.3.16.b O Yes__ No__
216.b.5 DL-Error Indication 5.3.16.b O Yes__ No__
Topology Update ID, in a DL-
Unitdata Request, shall contain
216.c.1 5.3.16.c(4) O Yes__ No__
the most recent Topology Update
ID sent from the upper layer
Topology Update ID, in a DL-
Unitdata Indication, shall contain
216.c.2 the Topology Update Identifier 5.3.16.c(4) O Yes__ No__
field from the Transmission
Header
The precedence levels available
to the network shall be mapped
into three separate levels (urgent,
216.c.3 5.3.16.c(5)(a) M Yes__ No__
priority, and routine), two levels
(urgent and priority or a single
level (urgent).
Precedence levels shall be
mapped from the Intranet
216.c.4 5.3.16.c(5)(a) M Yes__ No__
Sublayer of the Network Layer as
shown in TABLE VIII
The mapping into three separate
216.c.5 levels is the default but all three 5.3.16.c(5)(a) M Yes__ No__
shall be available in all systems

240
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

Whenever there are multiple
Network Precedence levels for a
single Data Link Precedence, the
higher Network Precedence PDU
shall be queued for transmission
216.c.6 ahead of lower Network 5.3.16.c(5)(a) 216.c.3:M Yes__ No__
Precedence PDUs (i.e., a PDU
with a Network Precedence of
Flash shall be transmitted prior to
a PDU with a Network
Precedence of Priority).
Data Length parameter values
that are larger than MDLTU shall
be failed with the corresponding
216.c.7 5.3.16.c(10) O Yes__ No__
DL-Status Indication reflecting
whether or not the message was
transmitted as appropriate.
The default value for the MDLTU
216.c.8 5.3.16.c(10) O Yes__ No__
shall be 3345 octets.
MDLTU values contained in the
MIL-STD-188-220D and MIL-
STD-188-220D w/CHANGE 1
216.c.9 5.3.16.c(10) O Yes__ No__
Parameter Table shall be used
when applicable for a specific net
configuration.

A.6 Network Layer DPRL.

Item Protocol Feature Reference Status Support Notes

APPENDIX B

ANNEX A

A.6.2 Subnetwork Dependent Convergence Function (SNDCF).

Item Protocol Feature Reference Status Support Notes

Subnetwork Dependent
302 5.4.2 M Yes__ No__
Convergence Function (SNDCF)
The layer shall assure that expected
services are provided within a
302.a particular subnetwork type for both 5.4.2 302:M Yes__ No__
IP datagram exchanges and n-layer
pass through exchanges
Implementer’s shall insure that n-
302.b 5.4.2 302:M Yes__ No__
layer pass through is supported
Send: Recv:
Selective Directed Broadcast for Send: Recv:
302.c 5.4.2 Yes__ Yes__
IPv4 O M
No__ No__
Send: Recv:
Selective Directed Broadcast for Send: Recv:
302.d 5.4.2 Yes__ Yes__
IPv6 O O
No__ No__
302.1 Determine Destination Function 5.4.2.1 M Yes__ No__
For n-layer pass through exchanges,
(MIL-STD-2045-47001 with or
without S/R) the interface shall
302.1.a 5.4.2.1 302.1:M Yes__ No__
provide the necessary addresses
using the IL Unit data Request
primitive
302.2 Address Mapping Function 5.4.2.2 M Yes__ No__
302.3 TOS Function 5.4.2.3 M Yes__ No__
302.4 Intranet Send Request 5.4.2.4 M Yes__ No__
302.5 Implementation Directions 5.4.3 M Yes__ No__
Shall utilize/support UDP/IP for
302.5.a transmit and receive of upper layer 5.4.3 M Yes__ No__
protocols
Shall be able to utilize/support
MIL-STD-188-220 N-Layer pass
302.5.b 5.4.3 M Yes__ No__
through for the transmission and
receipt of upper layer protocols

259
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

A.6.3 Standard network settings.

Item Protocol Feature Reference Status Support Notes

Lower layer protocol network
303 5.5 O Yes__ No__
settings
TABLE XIV describes a standard
set of lower layer protocols that
303.1 5.5.2 O Yes__ No__
may be used by all systems to
enhance interoperability.
Prior to inclusion of a new OPS
code the C/S/A or nation
sponsoring the required ICP shall
303.2 5.5.6 303:M Yes__ No__
provide DCE/Radio and
DTE/System protocol parameter
data.

A.7 Appendixes.

Item Protocol Feature Reference Status Support Notes

401 Abbreviations and Acronyms APPENDIX A NA ---
402 Profile APPENDIX B M Yes__ No__
Network Access Control Algorithm
403 APPENDIX C M Yes__ No__
(NAC)
Communications Security
404 APPENDIX D O Yes__ No__
Standards
405 CNR Management Process APPENDIX E O Yes__ No__
102.1.3.1:M Yes__ No__
406 Golay Coding Algorithm APPENDIX F 102.1.3.2:M Yes__ No__
102.1.3.3:X No
Packet Construction and Bit
407 APPENDIX G M Yes__ No__
Ordering
408 Intranet Topology Update APPENDIX H 301.2:M Yes__ No__
301.1.a:O Yes__ No__
409 Source Directed Relay APPENDIX I
301.1.c:M Yes__ No__
410 Robust Communications Protocol APPENDIX J 102.1.3.4:M Yes__ No__
Bose-Chaudhuri-Hocquenghem
411 APPENDIX K 102.1.3.4:M Yes__ No__
(15, 7) Coding Algorithm
412 Transmission Channel Interfaces APPENDIX L M Yes__ No__

260
Downloaded from http://www.everyspec.com

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

A.7.5 Golay Coding Algorithm.

Item Protocol Feature Reference Status Support Notes

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

The resulting set of source directed
routes to reach every desired
destination shall be optimally
409.2.1.b I.4.1 409:M Yes__ No__
pruned during encoding into the
intranet header such that they
define an associated routing “tree”
409.2.1.c If the routes for two or more
destinations, as they are to be
encoded into the intranet header,
I.4.1 409:M Yes__ No__
share common links along their
paths, those routes shall be merged
together.
409.2.1.d As a result of this merging process,
the resulting subset of paths shall
be encoded into the intranet header
such that any common nodes along
shared links do not appear I.4.1 409:M Yes__ No__
redundantly in the final routing tree
encoded in the intranet header (as
described in the following
paragraphs)
End-to-end intranet
409.2.2 I.4.2 409:M Yes__ No__
Acknowledgments
Each intermediate node in the
reverse path between the originator
node and the ith destination shall be
409.2.2.a designated as a “relayer only”, I.4.2 409:M Yes__ No__
regardless of its possible
disposition as a destination in the
original intranet header received
The resulting reverse path for the
intranet acknowledgment shall
409.2.2.b I.4.2 409:M Yes__ No__
contain one originator, one
destination, and all of the relayers.
409.3 Examples I.5 NA ---
409.3.1 Example 1 I.5.1 NA ---
409.3.2 Example 2 I.5.2 NA ---
409.3.3 Example 3 I.5.3 NA ---
409.3.4 Relay Processing I.5.4 NA ---

310
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

APPENDIX B

ANNEX A

Item Protocol Feature Reference Status Support Notes

BCH [15,7] shall be applied to the
segment counter prior to appending.
The number of BCH [15, 7] copies,
410.2.3.c 32-bit or 64-bit SOP pattern, and J.4.3 410.2.3:M Yes__ No__
the number of segments per packet
are determined by the MDTF
setting
410.2.4 Multi-Dwell Flag Not Set J.4.4 410.2:M Yes__ No__
When the multi-dwell flag is zero
410.2.4.a the data shall not be put into J.4.4 410.2.4:M Yes__ No__
packets
Only the robust frame
synchronization field and robust
frame format shall be inserted and
410.2.4.b J.4.4 410.2.4:M Yes__ No__
PL scrambling and/or
convolutional coding can be
applied to the user data

A.7.10 Bose-Chaudhuri-Hocquenghem (15, 7) Coding Algorithm.

Item Protocol Feature Reference Status Support Notes

APPENDIX C

NETWORK ACCESS CONTROL ALGORITHM

C.1 General.

C.1.1 Scope.
This appendix describes the network access control (NAC) algorithm to be used in the DMTD
and interfacing C4I systems.

C.1.2 Application.
This appendix is a mandatory part of MIL-STD-188-220. The information contained herein is
intended for compliance.

C.2 Applicable documents.

A list of data link parameters and their values as well as parameter values for the Network
Timing Model, described in APPENDIX C, are provided in a separate document entitled “MIL-
STD-188-220 Parameter Table”. This table is available via the CNR Implementation Working
Group World Wide Web page: https://www.us.army.mil/suite/page/495338.

C.3 Network Timing Model.

The network access control protocol shall be used to detect the presence of active transmissions
on a multiple-station-access communications network. The network access control protocol
shall provide a means to preclude data transmissions from conflicting on the network. The
network access control protocol is based on a generic network-timing model. All stations on a
network must use the same network access control protocol and timing parameter values in order
to maintain network discipline.

C.3.1 Network Timing Model definitions.

A network station consists of a DCE and a DTE. The DTE is the data device that performs the
MIL-STD-188-220 protocol. The DCE includes all equipment external to the DTE (e.g., a radio
with or without external COMSEC) that is used to provide a communications channel for the
DTE. The interface between the DTE and DCE can operate in synchronous, asynchronous, or
packet mode. The interface is synchronous if the DCE provides all required clocks to the DTE.
The packet mode interface is a synchronous interface that conforms to CCITT X.21. For
synchronous mode, the bit rate (n) is the rate of the transmit clock supplied by the DCE. If the
DCE does not provide clocks to the DTE, the interface is asynchronous. For asynchronous
mode, the bit rate (n) is the rate at which the DTE transmits. The data link bit rate is defined as
the effective bit rate at which the physical layer transmits the data bits. The data link bit rate is
usually the same as the bit rate (n) at the physical layer, except for the PSK/DPSK modems
(refer to MIL-STD-188-110). The robust protocol case is separately described in APPENDIX J.

327
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

C.3.2 Network Timing Model parameters.

The parameters of the network timing model are general enough to model interactions with a
wide variety of DCEs. All parameters are specified at the DTE to DCE interface and are in units
of seconds with a resolution of one millisecond. Parameters may have a value of zero if they are
not applicable to the DCE being used. Network timing model parameters are shown in FIGURE
C-1. Actual network timing model parameter values are provided in a separate document
entitled “MIL-STD-188-220 Parameter Table”. The use of identical values is crucial to
interoperability, even more important than the values themselves. All stations participating in a
network should utilize the values stated in the same version of this table.

C.3.2.1 Equipment Preamble Time (EPRE).

EPRE is the time from when the DTE initiates a transmission, often by asserting Push-to-Talk
(PTT), until the transmitting DTE sends to its DCE the first bit of information that will be
delivered to the receiving DTE. EPRE is a characteristic of the DCE. It accounts for DCE start
up time, including time required for radio power up and transmission of COMSEC and other
DCE preambles. EPRE can have a value between 0.000 and 30.000 seconds.

a. For Synchronous Mode, EPRE is measured from PTT until the DCE provides a clock to
the DTE for its first bit of information. For the purposes of the Network Timing Model, it is
assumed that the DTE will begin sending information to the DCE with the first clock edge
provided by the DCE. During this time, the DTE sends nothing.

b. For Asynchronous Mode, EPRE is measured from PTT until the first signal transmitted
by the sending DTE is also transmitted by the sending DCE to receiving DCEs. This accounts
for time that the transmitting DCE is not listening to signals sent by the transmitting DTE.
During this time, the transmitting DTE may send an alternating sequence of one and zero bits.

c. For Packet Mode, EPRE is measured from the time the DTE indicates it is ready to
transmit (by asserting the C-lead and transmitting flags on the T-lead as described in 6.3.2.1.2)
until the DCE indicates it is ready to accept information from the DTE (by transmitting flags to
the DTE on the R-lead as described in 6.3.2.1.2).

328
PTT Off EOT SYNC T
MTT Point O
PTT On DTE ACK L
Transmitting Station
T
EPRE PHAS- DATA TTURN PHAS- S RTURN O
ING ING L

TURN ELAG
ELAG Start NAD or
Receiving Station Scheduler
T
PHAS- DATA RTURN EPRE PHAS- S TTURN O
ING ING L

RHD i=1 RHD0

TP
Type 3 Network Timing

329
APPENDIX C

MTT
EOT SYNC
PTT Off
Downloaded from http://www.everyspec.com

Point
MIL-STD-188-220D w/ Change 1

Transmitting Station
PTT On

FIGURE C-1. Network Timing Model.

EPRE PHAS- DATA TTURN T
ING O
DTE Proc L

Receiving Station ELAG TURN

Start NAD or
Scheduler
PHAS- DATA RTURN
ING

TP
Type 1, 2 & 4 Network Timing
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

C.3.2.2 Phasing Transmission Time (PHASING).

Phasing is the time the DTE sends an alternating sequence of one and zero bits after the
completion of EPRE and prior to sending the first bit of data. PHASING can be needed due to
characteristics of the DCE, DTE, or both. PHASING shall have a value between 0.000 and
10.000 seconds. The DTE shall use the DCE bit rate to compute the number of phasing bits to
transmit.

a. For Synchronous Mode, phasing shall be used if the DCE delivers extraneous clock
edges to the DTE prior to the start of a valid, continuous transmit clock or if the DCE provides a
transmit clock to the DTE before it is ready to reliably deliver bits from the DTE to receiving
DCEs.

b. For Asynchronous Mode, phasing may be used by the receiving DTE to achieve bit
synchronization.

c. For Packet Mode, phasing shall be zero.

CAUTION. The terms PHASING and “phasing” are not interchangeable. PHASING refers to
the Phasing Transmission Time. Phasing is bit stream of alternating “1” and ”0”, as defined in
paragraph 5.2.1.2.

C.3.2.3 Data Transmission Time (DATA).

DATA is the time during which the transmitting DTE sends transmit data to its DCE. Transmit
data includes all fields shown in FIGURE 5. This includes embedded COMSEC information
shown in FIGURE 5b. It also includes transmission of concatenated frames (including bit
synchronization between physically concatenated frames) as shown in FIGURE 3. DATA shall
begin immediately after the end of PHASING. The transmitting DTE shall indicate end of
transmission immediately after the last bit of data is sent to the DCE. CAUTION. The terms
DATA and “data” are not interchangeable. DATA refers to the Data Transmission Time. Data
is the information bit stream.

C.3.2.4 Coupled Acknowledgment Transmission Time (S).

S is a special case of DATA, where the Data Field shown in FIGURE 5 contains only one Type
3 URR, URNR or TEST response frame with the F-bit set to 1 and no information field. For
these frames, the length of the fields in FIGURE 5 (including zero bit insertion) used in network
timing equations when the Multi-Dwell protocol and convolutional coding are not used shall be:

a. The 64-bit message synchronization field.

b. An optional embedded COMSEC MI field.

c. The 168-bit Transmission Word Count and Transmission Header TDC block.

330
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

d. 80 bits if neither the FEC nor TDC function is selected, 168 bits if only FEC is selected,
and 384 bits if both FEC and TDC are selected.

The sum of these components is transmitted at the data link bit rate.

C.3.2.5 Equipment Lag Time (ELAG).

ELAG is equal to or greater than the worst-case time from when the last bit of data is sent by the
transmitting DTE until the time when the same last bit of data is delivered to the receiving DTE
by the receiving DCE. ELAG is a characteristic of the DCEs and the propagation delay. It
accounts for frequency hopping throughput delays, satellite transmission delays, Packet Mode
radio-embedded FEC delays and other related delays. The end of ELAG is the synchronization
point for the Timeout Period (TP) and Response Hold Delay (RHD) Timers.

ELAG >= MAX(DCE_Tx_Delay) + MAX propagation delay + MAX(DCE_Rx_Delay)

DCE_Tx_Delay is the time when a bit is sent to the Transmitting DCE until that bit is
transmitted. DCE_Rx_Delay is the time from when a bit arrives at the receiving DCE until that
bit is delivered to the DTE.

C.3.2.6 Turnaround Time (TURN).

TURN is the time from the end of ELAG until the end of TTURN or RTURN, whichever is later.
TURN is computed using the equation:

TURN = Maximum((TTURN - ELAG), (RTURN - ELAG))

where:

a. TTURN is the time from when the transmitting DTE indicates end of transmission at the
end of DATA until the transmitting DCE is ready to begin a new transmit or receive operation.
TTURN is a characteristic of the DCE. It includes time when the transmitting DCE sends
COMSEC or other postambles after transmitting all data.

b. RTURN is the time from when the transmitting DTE indicates end of transmission at the
end of DATA until the receiving DCE is ready to begin a new transmit or receive operation.
RTURN is a characteristic of the DCE.

c. ELAG may be either larger or smaller than TTURN, but is always less than or equal to
RTURN, as shown in FIGURE C-2.

331
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

PTT Off
TTURN - ELAG

TTURN

ELAG MAX = TURN

RTURN

RTURN - ELAG

FIGURE C-2. Turnaround Time (TURN) calculation.

C.3.2.7 DTE ACK Preparation Time (DTEACK).

DTEACK is the time from the end of ELAG until the slowest DTE on the network can process
any possible Type 3 frame requiring a coupled acknowledgment, prepare the coupled Type 3
acknowledgment frame, and begin sending its coupled acknowledgment frame to its DCE
(including time for transmit relays for PTT to close). DTEACK is a characteristic of the DTE.
Unless a larger value is known, use the value TURN for the particular radio and operating
environment as the default value for DTEACK.

C.3.2.8 DTE Processing Time (DTEPROC).

DTEPROC is the time from the end of ELAG until the slowest DTE on the network can prepare
a worst case size frame for transmission and to start transmitting (including time for transmit
relays for PTT to close) after receiving data not requiring a coupled, Type 3 acknowledgment.
DTEPROC is a characteristic of the DTE. Unless a larger value is known, use the value TURN
for the particular radio and operating environment as the default value for DTEPROC.

332
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

C.3.2.9 DTE Turnaround Time (DTETURN).

DTETURN is the time required for the DTE or modem to stop listening for received data or
squelch detect and to activate the radio’s PTT. DTETURN shall be a variable parameter where
the range shall be from 0.000 to 0.100 seconds in one (1) millisecond resolution steps. Varying
the DTETURN parameter could allow different modems on the same radio net to match their
network access delay slots.

C.3.2.10 Tolerance Time (TOL).

TOL is a time value used to compensate for variances in the actual realized lag times from a
transmitting DTE to a receiving DTE. If the Smallest Actual Lag Time (SALT) is known, the
tolerance time required for the network can be optimized. SALT shall be less than or equal to
the receiving DCE and transmitting DCE pair with the smallest delay in the network. If SALT is
not known, then zero (0) shall be assumed. TOL is calculated by the following equation:

TOL >= ELAG – SALT

TOL may be greater to allow for other variances (e.g., different radios of the same make and
model).

C.3.2.11 Maximum Transmit Time (MTT).

MTT represents the maximum amount of time allowed on a net for a single transmission. It is
used to limit concatenation and has no effect on an individual message. It represents the duration
of time from PTT on until PTT off as shown in FIGURE C-1.

C.4 Network Access Control.

The stations shall implement the following four basic NAC subfunctions:

a. Network Busy Sensing.

b. Response Hold Delay (RHD).

c. Timeout Period (TP).

d. Network Access Delay (NAD).

C.4.1 Network Busy Sensing function.

The network busy function is used to establish the presence of a data or voice signal at the
receiving station due to activity on the net. Network busy sensing for a data signal shall be
provided. Network busy sensing for a voice signal may be provided. Network busy may be
provided by data network busy sensing or may utilize other more efficient network sensing
capabilities, such as, a DCE notification.

C.4.1.1 Data Network Busy Sensing.

When receiving a data transmission, network busy shall be detected within a fixed time.
Parameter B shall be used to compute this fixed time. For synchronous mode B shall be less

333
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

than or equal to (32/n) seconds. For asynchronous mode B shall be less than or equal to (64/n)
seconds. For packet mode B shall be less than or equal to 0.250 seconds. Upon detection of data
network busy, the data link network busy indicator shall be set. Setting a data link network busy
indicator shall inhibit all message transmissions, including coupled response messages. The data
link network busy indicator shall be reset upon indication from the physical layer that neither
voice nor digital data is being detected by the station.

C.4.1.2 Voice Network Busy Sensing.

Network busy due to a voice transmission may be detected. If voice transmissions are not
detected, this function shall report that the network is never busy due to a voice transmission.
Upon detection of voice network busy, a data link network busy indicator shall be set. Setting
the data link network busy indicator shall inhibit all message transmissions, including coupled
response messages. The data link network busy indicator shall be reset upon indication from the
physical layer that neither voice nor digital data is being detected by the station.

C.4.1.3 Network Busy Detect Time.

The time allowed to detect data network busy should be the same (within 1 msec) for all stations
on the network. This Net_Busy_Detect_Time is a key factor in achieving both throughput and
speed of service. The Net_Busy_Detect_Time values, as specified in the parameter table, should
be used per indicated Radio/System. All stations participating in a network should utilize the
values stated in the “MIL-STD-188-220 Parameter Table”, which is available on the CNRWG
website specified at 2.3.4. The equation below shall be used as a default in cases where the
parameter table has not been updated to reflect actual measurements for specific device. Where
a communications device provides a signal to detect network busy earlier than the calculated
parameter B value, the DTE shall interface to that signal. The parameter table lists the device
specific signals that should be supported in order to use the timing values specified. Where a
communication media provides capabilities to detect data network busy more quickly, the use of
these capabilities has been reflected in the parameter table Net_Busy_Detect_Time values. In
these cases, Net_Busy_Detect_Time can be set to reflect the capabilities of the media. Where
the communication media does not provide special capabilities or these capabilities cannot be
used by all stations on the network, the station shall examine received data to detect data
network busy. In these cases, the time allowed to detect data network busy shall be given by the
formula:

Net_Busy_Detect_Time = EPRE + ELAG + B + TOL

NOTE: Parameters EPRE and ELAG are initialized locally or learned using the XNP messages
described in APPENDIX E. Net_Busy_Detect_Time can also be learned using the XNP
messages described in APPENDIX E or from the parameter table.

C.4.2 Response Hold Delay.

An RHD0 period and an individual RHD value are calculated to determine the time that an
addressed receiving station delays before sending a Type 3 response PDU upon receiving a Type
3 command PDU (UI and TEST). The RHD controls network access and the NAD algorithm is

334
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

suspended during this period. An RHD0 period is the worst-case amount of time that a single
response takes. The individual RHD is the time at which a particular station waits before
accessing the network. If the scheduler is running, immediate scheduling should be used for
Type 3 Acknowledgment. The individual RHD value to be used shall be determined by the
position of the receiving station's individual or special address in the PDU destination portion of
the address field. The Reserved Address (0) in the destination portion of the address field shall
be ignored. That is, when calculating an individual RHD value, the Reserved Address shall not
be considered to occupy a position in the destination portion of the address field. The calculated
values for RHDi, TP, and NAD are computed to the nearest millisecond. The RHD time shall
start within 1 msec of the end of ELAG. All stations on a subnetwork should use the same
values in calculating RHD. These values can be initialized locally or learned, using the XNP
messages described in APPENDIX E.

a. The RHD0 period shall be calculated by the following formula:

RHD0 = EPRE + PHASING + S + ELAG + TURN + TOL

b. The TP shall be calculated by all stations on the network/link as follows:

TP = (j * RHD0) + TOL + Maximum(DTEACK, TURN)

where j = The total number of destination link addresses - to include special and
individual but not group or One-hop addresses - for this transmitted frame. The
transmitting station shall not include special address 3 in the total for j, and the
value of all non-integer variables (that is, RHD0, TOL, and TURN) in the TP
equation are rounded to the nearest one thousandth.

c. The individual addressed station’s response hold delay (RHDi) shall be calculated by

RHDi = (i - 1) * RHD0 + Maximum(DTEACK, TURN) + TOL

The variable i (where 1 < i < 16) is the individual station's position in the
destination portion of the address field.

C.4.3 Timeout Period.

TP is the time this station shall wait before it can schedule the NAD. During this window of
time, the transmitting station shall wait to receive the anticipated Type 3 coupled
acknowledgment response frame(s), from all applicable addressed stations. The parameter
values used to compute TP must be the same for all stations on a subnetwork and, unless
immediate retransmission is required per 5.3.11.3, all stations shall compute TP using only the
individual addresses and special addresses 1, 2, and 3. When immediate retransmission is
required, the sending station shall compute TP using only individual addresses and special
addresses 1 and 2 (all other stations include Special Address 3 as usual). The calculated value of
TP is computed to the nearest millisecond. The TP time shall start precisely at the end of ELAG.

335
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

A retransmission of a Type 3 frame shall be executed whenever TP has been exceeded without
expected acknowledgments having been received from all Type 3 individual and special
destinations. Prior to retransmission, the address field of the frame shall be modified to delete
the destination station(s) that previously acknowledged the frame. Operationally, TP shall be
used as follows:

a. Upon termination of a message transmission that requires a Type 3 coupled

acknowledgment, the transmitting station shall start the TP timer. If the transmitting station does
not receive all the expected responses (TEST, URR, or URNR) within the TP, and if Immediate
Retransmission is not required, the station shall retransmit the frame when it is the highest
precedence frame to send according to normal NAD procedures, only if the number of
transmissions of this PDU is less than the Maximum Number of Transmissions data link
parameter. If Immediate Retransmission is required, (i.e., the sending station used Special
Address 3 as one of the destinations, all of the expected acknowledgments are not received prior
to the end of TP, and the number of transmission of this PDU is less than the Maximum Number
of Transmissions data link parameter), the sending station shall retransmit the message upon the
expiration of TP. This transmission will occur during the longer TP experienced by other
stations. If Immediate Retransmission was required and all expected acknowledgements to the
message are received prior to the expiration of TP, or the number of transmission of this PDU
equals the Maximum Number of Transmissions data link parameter, upon the expiration of TP
the sending station shall wait an additional RHD0 period prior to starting its NAD timer in order
to stay synchronized with the other stations on the network (reference FIGURE C-1). For all
stations, if a Type 1, Type 2 or Type 4 frame is received when a response-type frame is expected,
the newly received frame shall be processed. The RHD and TP timers shall not be suspended
and the TP procedures in use for the Type 3 frame shall be continued. Response procedures, if
any, for the newly received frame shall commence after the conclusion of the ongoing TP
procedures. If the unexpected frame is a Type 3 frame the current TP procedure is aborted and
the newly received Type 3 TP procedure shall be started.

b. After a station transmits or receives data that does not require a Type 3 coupled
acknowledgment, and is not itself a Type 3 coupled acknowledgment, all stations except those
using RE-NAD shall compute TP as:

TP = Maximum(DTEPROC, TURN) + TOL

c. Upon receiving a Type 3 coupled acknowledgment, a station shall determine whether a

timeout period is already in progress. If no timeout period is in progress, or if the
acknowledgment contains an unexpected destination or source address, the receiving station
shall compute TP using the following equation and shall start a timeout period within 1 msec of
the time the last bit of data for the Type 3 coupled acknowledgment was received.

TP = (15 * RHD0) + TOL + TURN

NOTE: RHD0 is as defined in C.4.2.

336
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

C.4.4 Network Access Delay (NAD).

NAD is defined as the time a station with a message to send waits to send a frame after the TP
timer has expired. NAD discipline is based on an infinite sequence of “slots” that begin when
the TP timer has expired. Slots are defined to be long enough so that all stations on the network
will detect a station transmitting at the beginning of a slot prior to the beginning of the next slot.
The duration of the NAD shall take the Net_Busy_Detect_Time into account as specified by the
equation at the end of this paragraph. All transmissions, except the coupled acknowledgments,
shall begin at the start of the next NAD slot.

There are six schemes for calculating NAD. The six schemes are defined below. DAP-NAD
and R-NAD, shall be available to a network participant using Synchronous Mode. Five schemes
(R-NAD, P-NAD, H-NAD, DAV-NAD and DAP-NAD) compute a value F for each station on
the net. The F value is the number of NAD slots that each station shall wait before transmitting,
if it has any information to send.

The R-NAD scheme provides all stations with an equal chance to access the network. The P-
NAD scheme ensures the highest precedence station with the highest priority message will
access the network first. In the case of RE-NAD, network access delay is computed by the radio.
With RE-NAD the DTE (DMTD or C4I system) does not compute network access delay but
does schedule channel access opportunities at which an access attempt can be initiated by the
DTE. DAP-NAD and DAV-NAD, like P-NAD, ensure the highest priority message will access
the network first. They do not ensure first access by highest precedence station however. The
H-NAD scheme combines random access with the preferential access by frame priority. The
random and hybrid schemes might result in a collision (the same NAD value for two stations).
The P-NAD, DAV-NAD and DAP-NAD schemes always produce a unique NAD value for each
station. In all of the NAD schemes, if the TP timer is active, the stations with frames to transmit
shall wait for the TP timer to expire before the NAD is started. If the TP timer is not active, the
station shall calculate its NAD using the proper NAD scheme for the network. Each NAD
scheme produces a set of allowed access periods. The network may be accessed only at the
beginning of one of those periods. If a station using P-NAD, DAP-NAD, DAV-NAD or H-NAD
is waiting for its NAD time and a higher priority frame becomes available for transmission, the
station may shorten its NAD time to a time it would have computed if it had computed its
original NAD time using the new, higher frame priority. Below are the frame reception and
transmission procedures:

a. Upon receipt of a frame a TP delay timer shall be started. The transmission of additional
frames shall be suspended until expiration of the TP delay timer. (All pending frames shall await
expiration of the TP delay timer). After the frame check sequence has been verified, the address
and control fields are analyzed. If the received frame is either a UI or TEST frame and the poll
bit is set to 1, the TP timer allows for receipt of the requested coupled acknowledgments. For
receptions other than the UI or TEST with poll bit set, the TP timer provides sufficient delay to
allow all systems to compete equally for access. Regardless of what was received, a NAD value

337
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

shall be recomputed and initiated after the TP timer expires. The calculated value of the NAD is
rounded to the nearest millisecond.

b. If a station does not have a frame to transmit, it shall compute a NAD time using
routine priority for its calculations. If the NAD time arrives before a frame becomes available to
transmit or frame(s) are not yet encoded for transmission, the station shall compute and use a
new NAD time. The starting time for the new NAD shall be the same as the starting time for the
NAD that was just completed. The F value used in computing the NAD shall be the sum of the F
value used in the NAD just completed plus a value dependent on the NAD in effect.

1) For P-NAD the additional F value shall be (NS + 1). This creates another
group of NAD slots for all stations on the network. Adding this value at
all stations preserves the algorithmic collision prevention property of P-
NAD.

2) For R-NAD the additional F value shall be [(3/4) * NS + 1]. Adding the
same constant value at all stations preserves the random property of R-
NAD.

3) For H-NAD the additional F value shall be 1 if the station has an urgent or
priority frame to transmit and (Routine_MAX + 1 - Routine_MIN) if a
station has only a routine frame(s) or no frame(s) to transmit. The value 1
preserves the intent of H-NAD that is to grant preferential network access
to stations with urgent or priority frames to send. The value
(Routine_MAX + 1 - Routine_MIN) preserves the random property of H-
NAD for stations with only routine frames to send.

4) For RE-NAD, F is not used.

5) For both DAP-NAD and DAV-NAD the additional F value shall be (NS).
This creates another group of NAD slots for all stations on the network.
Adding this value to all stations preserves the algorithmic collision
prevention properties of DAP-NAD and DAV-NAD even when messages
become available for transmission at the same time at different stations
after a long idle period.

c. All stations on the network shall continue to sense the link for data or voice network
busy and shall withhold transmission until the appropriate NAD period has expired. NAD shall
be calculated using the formula:

NAD = F * Net_Busy_Detect_Time + MAX(0, F-1) * DTETURN

where Net_Busy_Detect_Time is as defined in C.4.1.3 and DTETURN is as

defined in C.3.2.9.

338
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

C.4.4.1 Random - Network Access Delay (R-NAD).

The R-NAD calculation method ensures that each station has an equal chance of accessing the
network. The random nature also may provide a resolution if an access conflict occurs. Each
attempt to access the network potentially can use a NAD value different from the station's
previous value. The integer value of F shall be obtained from a pseudorandom number
generator. The range of the pseudorandom number depends on the number of stations (NS) in
the network. F shall be an integer value (truncated) in a range between 0 and (3/4)NS. NS can
be learned through the XNP join exchange, or fixed by a system parameter established at
initialization.

C.4.4.2 Prioritized - Network Access Delay (P-NAD).

P-NAD ensures that the network access precedence order assigned to stations is preserved. Each
station shall calculate three unique P-NAD values, one for each of the three frame precedence
levels. The integer value of F shall be calculated as:

F = SP + MP + IS
where:

SP = the station precedence:

SP = (station rank -1) for the initial transmission; and
SP = 0 for subsequent transmissions.

MP = the message precedence:

MP = 0 for all urgent messages;
MP = (NS + 1) for all priority messages;
MP = 2 * (NS + 1) for all routine messages,
where NS is the number of stations on the network.

IS = the initial/subsequent factor:

IS = 0 for the initial transmission, and
IS = NS for subsequent transmissions.

Only one station on the network uses the subsequent factor. That is the station that transmitted
last on the net. However, transmissions of coupled Type 3 acknowledgments do not count as
transmissions for the purpose of determining which station transmitted last.

C.4.4.3 Hybrid - Network Access Delay (H-NAD).

The H-NAD calculation method ensures that network access delay times are shorter for higher
priority frames, while maintaining equal access chances for all stations. Each priority level has a
distinct range of pseudorandom F values determined by the NS in the subnetwork, the network
percentage of the particular priority level frames, and the traffic load. The integer value of F
shall be calculated as

F = MIN + RAND * (MAX - MIN)

339
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

where:

RAND = pseudorandom number in the range 0.0 to 1.0

MAX and MIN are integer values defining the ranges:

Urgent_MIN = 0, for urgent frames

Urgent_MAX = USIZE + 1, for urgent frames

Priority_MIN = Urgent_MAX + 1, for priority frames

Priority_MAX = Priority_MIN + PSIZE + 1, for priority frames

Routine_MIN = Priority_MAX + 1, for routine frames

Routine_MAX = Routine_MIN + RSIZE + 1, for routine frames

USIZE = the additional number of random numbers generated for urgent frames

PSIZE = the additional number of random numbers generated for priority frames

RSIZE = the additional number of random numbers generated for routine frames

where the minimum MIN/MAX range size is 2.

The additional range sizes (xSIZE) are integers based on the percent of frames expected at a
specific priority level (%priority_level) and the NS adjusted (ADJ_NS) by the expected traffic
load (TL). NS, %priority_level, and traffic load, may be input using the XNP messages or by
initialization input. xSIZE is rounded to the nearest non-negative integer.

USIZE = %U * ADJ_NS, %U = percentage of urgent frames (default 25%)

PSIZE = %P * ADJ_NS, %P = percentage of priority frames (default 25%)

RSIZE = %R * ADJ_NS, %R = percentage of routine frames or 100% - (%U + %P)

(default 50%)

where the adjusted NS increases if the expected traffic load is heavy and decreases if the traffic
load is light. The minimum random number range at each of the three priority levels is 2, so 6
stations are subtracted from the adjusted NS.

340
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

ADJ_NS = INTEGER (NS * TL) -6 or = 1 (whichever is greater)

where:

TL = 1.2 Heavy Traffic Load

= 1.0 Normal Traffic Load
= 0.8 Light Traffic Load

C.4.4.4 Radio Embedded - Network Access Delay (RE-NAD).

C.4.4.4.1 RE-NAD media access.

The RE-NAD DTE data link layer uses a channel access protocol between the DTE (DMTD or
C4I system) and DCE which is influenced by radio net voice activity. When the continuous
scheduler (Tc) interval timer expires and the previous series of concatenated frames was
successfully transmitted, a new series of frames is sent to the physical layer. If there is a pending
series of concatenated frames, its transmission is requested again. It should be noted that the
physical layer holds the series of concatenated frames when channel access has been denied. If
channel access was denied a new Tc interval is calculated and channel access for transmission of
the pending series of concatenated frames is requested when the new Tc interval timer expires.
If a higher precedence individual frame becomes available for transmission, the concatenated
frames shall be re-built to include the higher precedence frame.

For the Type 3 acknowledgment, the RE-NAD portions in both DTE and DCE are suspended
and channel access is controlled by the RHD and TP processes. The RE-NAD algorithm is
resumed following expiration of the TP timer.

C.4.4.4.1.1 Random schedule interval.

In order to achieve high performance radio network communication, efficient channel access and
multi-level precedence, a fast attack slow decay RE-NAD algorithm is implemented in the DTE.
This algorithm uses the “continuous scheduler” concept to provide a random distribution of
timing for channel access via the Tc interval timer. The Tc interval timer is the sum of a voice
component and a data component. The voice component is a fast attack slow decay function
permitting voice to immediately slow down the scheduler (fast attack) while gradually speeding
the scheduler back up to normal as long as there isn’t any voice on the radio net (slow decay). It
is described more fully in C.4.4.4.1.2. The DATA component is a randomization around net size
and the Fload algorithm. It is discussed in C.4.4.4.1.3 and C.4.4.4.1.4.

The value of Tc interval is recalculated after every local transmission attempt from the
expression:

Tc interval = voice factor + uniform_random(SchedulerInterval)

where uniform_random (SchedulerInterval) is a uniform random number function using the

range 0 - SchedulerInterval. Uniform_random returns an integer value.

341
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

C.4.4.4.1.2 Voice component.

The voice factor in C.4.4.4.1.1 is a value bound by its minimum and maximum limits. The
maximum voice factor (range = 0.3 to 10.0 sec) is the upper bound on the value of the voice
factor. The minimum voice factor (range = 0.3 to 10.0 sec) is the lower bound on the value of
the voice factor. The initial voice factor shall be the minimum voice factor value. Detection of
voice on the radio net increments the voice factor value while the absence of voice decrements
the voice factor value.

C.4.4.4.1.2.1 Fast attack.

Voice detection shall increment the voice factor by the voice factor increment value (range = 0.0
sec to 10.0 sec) as indicated below:

a. If the voice factor is at the minimum voice factor value (see C.4.4.4.1.2), the scheduler
is incremented immediately to protect the next voice hit.

b. Otherwise, the increment occurs at the next scheduler expiration

The voice factor value is upper bounded by the maximum voice factor (see C.4.4.4.1.2).

C.4.4.4.1.2.2 Slow decay.

The voice factor shall be decremented every time the NAD expires by the voice decrement value
(range = 0.0 sec to 10.0 sec). The voice factor value is lower bounded by the minimum voice
factor.

C.4.4.4.1.3 Calculation of the scheduler random parameter.

The parameter SchedulerInterval depends on queue lengths and the number of net members
transmitting data as follows:

SchedulerInterval = [NADScaleTime * (NumActiveMembers / 16)] * Fload

minimum=(settable range = 0.1 to 3.0 sec)
maximum=(settable range = 1.0 to 50 sec)

where:

NADScaleTime = adjustment factor (range = 0.1 – 5.0 sec).

NumActiveMembers = number of net members actively transmitting data on the net. All
net members are within two intranet hops of the node determining this value. Continuous
calculation of this value shall be performed based on the number of known active data
transmitters on the net. A station’s own status is included in this count.

Neighbor agent timer = this timer (range = 1 – 600 sec) is used to age out net member
active status. When this timer expires and a data transmission has not been received from

342
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

a net member, that net member is marked inactive. This timer should be greater than the
topology update timer to assure net members are not aged out between topology updates
in fragmented nets.

SchedulerInterval shall be recomputed after every transmission by the DTE.

C.4.4.4.1.4 Calculation of the Load Factor (Fload).

The Fload is computed in a fully distributed manner by every node in the net. In the
transmission header, the six least significant bits of the second octet (as indicated in the Queue
Precedence and Queue Length subfields of FIGURE 10, see 5.3.1) are dedicated to transmitting
the number of messages at the highest priority level remaining in the information frame queue;
the remaining two bits are spare. The two least significant bits (LSB) indicate the level of the
highest priority message. The four most significant bits (MSB) indicate the number of frame
concatenations required to transmit all of the messages at the above priority level. The four
MSB are quantified as shown in TABLE C-I.

TABLE C-I. Calculation of the Load Factor.

Number of Concatenated Frames Required Bit Pattern

7654
0.0 0000
0.0 (exclusive) - 0.5 (inclusive) 0001
0.5 (exclusive) - 1.0 (inclusive) 0010
1.0 (exclusive) - 2.0 (inclusive) 0011
2.0 (exclusive) - 3.0 (inclusive) 0100
3.0 (exclusive) - 4.0 (inclusive) 0101
4.0 (exclusive) - 5.0 (inclusive) 0110
> 5.0 0111

The Load Factor takes on values such that 1.0 < Fload < 18.0. The minimum value of 1.0 places
an upper limit on the speed of the scheduler per the Fload description. The value of 18.0
provides a useful range for adaptation of the scheduler due to differing traffic loads, and is
divisible by 2 and 3, resulting in integer ranges for the three different precedence values. Higher
values of the Load Factor indicate that the node has shorter queues of equal or lesser priority. In
cases of high Load Factor, it is desirable to increase the scheduling interval to give neighboring
nodes with higher priority or longer queues of equal priority more opportunities to transmit. The

343
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

Load Factor is calculated after every expiration of the scheduler, prior to calculation of the next
expiration.

ALGORITHM: Calculation of the Load Factor, Fload.

1. Determine the number of unique neighboring node priority levels broadcast by all the
nodes including this one. This data is taken from the last transmission received from each
neighboring node.

2. Divide the interval 0.0 to 18.0 into equal segments, one per unique announced
priority level. The first segment (0.0 to 9.0 for two levels) is allocated to the highest priority
traffic. Define the Segment Offset as the lower bound of the chosen segment. For two
precedence levels, the Segment Offset is 0.0 for the highest precedence and 9.0 for the Lowest
Precedence. Define the Segment width equal to 18.0/Number of precedence levels. For all three
precedence levels, each precedence level has a segment width of 6.0.

3. Each segment is subdivided into n unique levels where n is the number of unique
quantified concatenated frame lengths reported by the neighboring nodes and the node doing the
computation. In the case of only one length, all nodes use the midpoint of the segment. In the
case of multiple lengths, these lengths are ordered from longest to shortest (1 -> n). In the
following computation of Load Factor (see TABLE C-II), a node would use a value of m
determined by its position in that ordering. All nodes with the longest quantified length use the
value 1, while those with the shortest use the value n for variable m in the following equation:

Fload = Segment offset + (Segment width*m)/(n+1)

where

Segment Offset is the Lower bound of the segment chosen by precedence

level from step 2.

Segment Width is the maximum Load Factor (18) divided by the number
of unique precedence levels

n is the number of unique quantified queue lengths.

m is this nodes positioning within the ordering of quantified queue

lengths.

344
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

TABLE C-II. Calculation of the Load Factor -- example 1.

Node Number Highest Precedence Quantified Queue Load Factor

Length
7654
1 Routine 0001 12.0
2 Routine 0001 12.0
3 Routine 0011 6.0
4 Routine 0011 6.0

All nodes compute the Load Factor in the following manner.

1. There is only 1 unique priority level (Routine).

2. The Segment is determined to encompass the whole range 0->18.

3. The Segment Offset is the lower bound (0).

4. The Segment Width is the entire range (18).

5. Two unique Quantified Queue Lengths are noted. The value of n is set to 2.

6. The unique Quantified Queue Lengths are ordered from longest to shortest (3,1).

7a. Nodes 1 and 2 note that their positioning in this sequence is 2 and set m to 2.

7b. Nodes 3 and 4 note that their positioning in this sequence is first and set m to 1.

8a. Nodes 1 and 2 compute their Load Factor from the equation.

Fload = Segment Offset + (Segment Width*m)/(n+1)

= 0 + (18 * 2) / (2+1) = 12

8b. Likewise, Nodes 3 and 4 do the Load Factor computation.

Fload = 0 + (18 * 1) / (2+1) = 6

345
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

TABLE C-III. Calculation of the Load Factor -- example 2.

Node Number Highest Precedence Quantified Queue Load Factor

Length
7654
1 Routine 0001 13.5
2 Routine 0001 13.5
3 Urgent 0010 6.0
4 Urgent 0011 3.0

All nodes compute the Load Factor in the following manner.

1. There are two unique precedence levels (Urgent and Routine).

2. The Load Factor Range is divided into two segments 0-9, 9-18. The segment 0-9
is reserved for Urgent, while the segment 9-18 is reserved for Routine.

3. The Segment Offset is the lower bound of the segment. The Segment Offset is 0
for Urgent and 9 for Routine.

4. The Segment Width for both precedence levels is the entire range (0->18) divided
by the number of precedence levels. Segment Width = 18/2 = 9.

Nodes 1, 2 perform the following computations:

5. There is only one Quantified Queue Length. Thus, n is equal to 1 and since there
is only 1 length both nodes use the first position in the sequence and set m to 1.

6. Fload = Segment Offset + (Segment Width*m)/(N+1)

= 9 + (9 * 1) / (1+1) = 13.5

Nodes 3,4 perform the following computations.

7. The unique Quantified Queue Lengths are ordered from longest to shortest (3,2).
There are two unique lengths which sets the value of n to 2.

346
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

8. Node 3 has a length of 2, which occupies position 2 in the ordering of step 7.

Because it occupies position 2, the value of m is set to 2.

Fload = Segment Offset + (Segment Width*m)/(n+1)

= 0 + (9 * 2) / (2+1) = 6

Node 4 has length of 3, which occupies position 1 in the ordering of step 7. Node
4 sets its value of m to 1.

Fload = Segment Offset + (Segment Width*m)/(N+1)

= 0 + (9 * 1) / (2+1) = 3

C.4.4.4.1.5 100 msec Immediate Mode scheduling.

In lightly loaded nets quicker access to the radio net medium is provided through the “100 msec
immediate mode” scheduling all types except Type 3 ACK PDUs as follows:

a. If the scheduler expires and the following conditions are met: (1) there are no
concatenated frames awaiting transmission, (2) the RE-NAD voice factor is at its
minimum value, and (3) all other members of the net reported transmission queue
lengths of zero; set Immediate Mode to READY. Compute and start the next
random interval of the continuous scheduler (Tc).

b. When an information PDU arrives for transmission and Immediate Mode is

READY, cancel the previously scheduled Tc and assign a scheduling interval as
follows:

Tc = 100 msec

c. When this is done, Immediate Mode is set to ON. The 100 msec allows an
opportunity for messages which have been segmented/fragmented/received to be
piggy-backed into the same series of concatenated frames. This increases
efficiency without imposing delay.

d. When the scheduler expires due either to the Tc scheduled as a result of the
immediate mode operation or due to normal continuous operation, and I-frame(s),
S-frame(s), U-frame(s) or a frame concatenation are pending, perform
concatenated frame processing as normally is done. Compute and start the next
random interval of the continuous scheduler (Tc) in the normal manner.

e. Any traffic, voice or data, detected during the immediate mode operation shall
abort the 100 msec Immediate Mode and set it to OFF. The scheduler is then
computed in the normal manner.

347
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

C.4.4.4.1.6 Immediate Mode scheduling.

If the PDU is Type 1or Type 3, the Tc is set to 0.0 seconds which permits net access to be
controlled without a randomized scheduler influence.

C.4.4.4.2 RE-NAD network access.

When the precedence level of the transmission changes, the DTE shall set the precedence level
of the new transmission. This precedence level shall correspond to the frame with the highest
precedence value within the series of concatenated frames.

C.4.4.4.3 Network Busy Sensing and receive status.

The presence of multiple stations on a single random access communications network requires
voice/data Network Busy Sensing and the use of network access control to reduce the possibility
of data collisions on the net. The combined Data and Voice Nets require cooperation between
the DTE (DMTD or C4I system) and the DCE.

The DCE indicates the presence of receive data and voice by signaling the following conditions:

a. Data being received.

b. Voice operation.

c. Idle/Transmission completed.

d. Data being transmitted.

The transmission of data by the DTE is allowed only in the Idle/Transmission completed state.

C.4.4.5 Deterministic Adaptable Priority - Network Access Delay (DAP-NAD).

DAP-NAD is a method of generating Network Access Delays to control network accesses which
provides every station with an opportunity to use a radio/wireline net. It is deterministic in that
every station has a unique opportunity to access the network and given the device, network, and
protocol parameter settings, the maximum delay for network access can be calculated.

The mechanism for providing network access is to give the first “access opportunity” (the time at
which a station may transmit a message if one is available) to a different station at each “network
access period” (the time between message transmissions when all stations are determining when
to transmit) and to give later access opportunities to all other stations in sequence. Each station
is assigned a unique Station Number that is in the range of 1 to the Number of Stations (NS in
the equations that follow). It is recommended that the Frequency of Access Ranking (FOAR)
algorithm described in Section 6 (paragraph 6.3.3.1) be utilized to determine Station Number
whenever DAP-NAD is to be used. This algorithm increases fairness whenever DAP-NAD is
the mechanism used to access the network. During the first network access period, station
number 1 is given the first access opportunity, station number 2 is given the second access
opportunity, station number 3 the third access opportunity, etc. After the last station has been

348
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

given an access opportunity, station number 1 is again given an access opportunity, followed by
station number 2, etc. This continues until a station transmits a message. The station that
transmits the message shall increment by one (1) the First Station Number (FSN) subfield
contained in the last message it received and places the resulting number in the FSN subfield of
the Transmission Header. If the increment of FSN causes FSN to equal NS+1, then the station
shall set FSN = 1 prior to placing the value in the FSN subfield of the Transmission Header. The
very next access period (the first DAP-NAD time slot following the message transmission) is
referred to as the “bump slot” and is reserved, such that any node can interrupt the network in
case they have an urgent message to transmit, provided the Network Precedence (NP) is not
already Urgent. Stations shall not transmit in the bump slot while the NP is Urgent. (Note that
stations may not always agree on the NP value since not all stations may have received the
transmission raising the NP to Urgent. A station that transmits in the bump slot shall not
increment the FSN in the Transmission Header. All nodes having messages to transmit with an
urgent precedence would transmit either a short Urgent control frame (Transmission Header) or
the actual urgent message in the reserved slot using only Type 1, Type 2 or Type 4 (Type 3 shall
not be utilized in the bump slot). Upon receipt of this Urgent frame or detection of a network
busy condition during the reserved slot, all receiving nodes would assume that the network
precedence had gone to Urgent and act accordingly. In this manner, transmissions in the bump
slot would serve to interrupt the operation of a network operating at Priority or Routine causing
it to elevate to Urgent mode. The next station authorized to access the network is the First
Station Number specified in the Transmission Header of the transmission that occurred before
reverting to Urgent mode. Each station calculates different NAD times for each network access
period. Note that a station with an Urgent message ready for transmission shall not utilize the
bump slot if the FSN indicates that this station is the very next one authorized to access the
network. The station that utilized the bump slot shall retransmit its Urgent message in its
authorized access opportunity. This is necessary for the rare instance of a collision in the bump
slot. Type 3 is authorized in this retransmission. There are three Network Precedence (NP)
modes: urgent, priority and routine. Regardless of the NP mode in use, every station shall be
provided at least one opportunity to access the network before NP is reduced to next lower level.
If no station accesses the network, at any specific NP, each station will obtain exactly one access
opportunity. If a station does access the network during any specific NP, the network shall
remain at that NP for another NS access opportunities. This is demonstrated by two examples in
FIGURE C-3.

349
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

* This example assumes that NP = U, FSN =1, Station 4 has just completed an urgent
transmission and no stations require access to network. The first access slot following the
transmission by Station 4 is a bump slot. Note that this bump slot may not be utilized by any
station (N for Station # represents “No” Station) because the NP is already at Urgent.

Access B 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Station # N 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3
FSN 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
NP U U U U U P P P P R R R R R R R R R R R R R R R

* This example assumes that NP = U, FSN =1, Station 4 has just completed an urgent
transmission and Station 3 has a priority message to transmit. Once again, the first access slot
following the transmission by Station 4 is a bump slot. In addition, there is a bump slot
immediately following the Priority transmission by Station 3. (This bump slot may be utilized
by any station (A for Station # represents “Any” Station).

Access B 1 2 3 4 5 6 7 B 8 9 10 11 12 13 14 15 16 17 18 19 20
Station # N 1 2 3 4 1 2 Tx by 3 A 2 3 4 1 2 3 41 1 2 3 4 1 2
FSN 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2
NP U U U U U P P P P P P P P R R R R R R R R R

FIGURE C-3. Example of FSN and NP operation.

The first NS number of access opportunities of a network access period are reserved for stations
that have an urgent message awaiting transmission. Those stations that do not have any urgent
messages awaiting transmission shall wait for at least the NS+1 access opportunity before they
can transmit. The next NS number of access opportunities of the network access period are
reserved for stations that have a priority (or an urgent if one has become available since the
previous access opportunity) message awaiting transmission. Those stations that have only
routine messages awaiting transmission shall wait for at least the 2NS+1 access opportunity
before transmitting. Those stations that have any messages awaiting transmission, regardless of
priority, by the 2NS+1 access opportunity can transmit when their calculated access opportunity
arrives. The calculations of the NAD times are discussed in the following paragraphs.

a. Network in Urgent Mode. The first NS number of access opportunities of a network

access period are reserved for stations that have an urgent message awaiting transmission. If no
Urgent messages are transmitted during this time frame, the NP drops to Priority Mode. If an
Urgent message is transmitted, the network will remain in Urgent Mode for another NS access
opportunities. The very first network access period following completion of the transmission
while in Urgent mode is a bump slot, but this bump slot shall not be utilized by any station (The
bump slot when NP = Urgent is only provided for stations that may not have received a
transmission raising the NP to Urgent). Those stations that do not have any urgent messages
awaiting transmission shall wait for at least another NS access opportunities before they can
transmit.

350
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

b. Network in Priority Mode. The first NS access opportunities are reserved for stations
that have an urgent or priority message awaiting transmission. If no Urgent or Priority messages
are transmitted during this time frame, the NP drops to Routine Mode. If an Urgent message is
transmitted, the NP shall elevate to Urgent. If a Priority message is transmitted, the NP shall
remain at Priority for another NS access opportunities. Those stations that only have routine
messages awaiting transmission shall wait for at least another NS access opportunities before
they can transmit. The very first network access period following completion of the transmission
while in Priority mode shall be reserved for any station with an Urgent message to send. When
the interrupting station obtains access and transmits the Urgent message, the NP shall remain at
NP = Urgent for at least another NS access opportunities.

c. Network in Routine Mode. In Routine Mode, any station that has a message, regardless
of priority, can transmit when their calculated access opportunity arrives. If no messages are
transmitted, or if a Routine Message is transmitted, the NP remains at Routine. If a Priority
Message is transmitted, the NP shall elevate to Priority. If an Urgent Message is transmitted, the
NP shall elevate to Urgent. The very first network access period following completion of a
transmission while in Routine mode shall be reserved for any station with an Urgent message to
cause the network to go to Urgent mode.

FIGURE C-4 shows an example of the DAP-NAD key. And FIGURE C-5 shows an example of
DAP-NAD using the key.

351
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

NP = Network Precedence, highest MAC precedence of any frame in the last transmission (NP = URGENT this
example)
NS = Number of Stations (NS = 4 this example) the net is configured to support
NAD = Net Access Delay, time after TP that a station must listen for a busy net before starting to transmit
Net Busy Detect, time from when a station begins transmitting until it can be detected by other stations
A = Any Station Number, used to indicate that any station may transmit during the bump slot to quickly transmit an
urgent message and set NP to urgent
N = No Transmission, used to indicate that no station may transmit during the bump slot because NP is Urgent.

EOT = End Of Transmission, time at which stations perceive a transmission ending

FSN = First Station Number, station number having the first opportunity to transmit (FSN = 2 this example)
at the current NP.
Increasing NAD time per station number with each listen time slot equal to the Net Busy Detect time

…4U2 TP N 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1R3…
B U U U U P P P P R R R R R R R R R R R R R R R R
Station 1 transmits
routine message,
FSN=3
R = Routine slot, third through N precedence groups of NS
NAD times for stations having urgent, priority or routine
messages for transmission
P = Priority slot, second precedence group of NS NAD times reserved for
stations having urgent or priority precedence messages for transmission
U = Urgent slot, first precedence group of NS NAD times reserved for stations having
urgent precedence messages for transmission
B = Bump slot, slot that is present immediately following any transmission (NP=U, NP = P or NP=R).
Any station may transmit an urgent message in this slot provided NP is not Urgent.
TP = Timeout Period, period of time (as calculated by each station) to wait from the EOT until subsequent
messages could start being transmitted (NAD=0)
= Station 4 transmits urgent message, FSN=2

FIGURE C-4. DAP-NAD example key.

352
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

Initial State: NP = U; FSN = 3 (See Note 1)

Event 1: Routine message ready at Station 1
Event 2: Station 1 transmits a R message, FSN=4

…4U3 TP N 3 4 1 2 3 4 1 2 3 4 1R4…
B U U U U P P P P R R R

State: NP = R; FSN = 4
Event 3: Priority message ready at Station 3
Event 4: Station 3 transmits a P message, FSN=1
Event 5: Priority message ready at Station 2

…1R4 TP A 4 1 2 3P1…
B R R R R

State: NP = P; FSN = 1
Event 6: Priority message ready at Station 3
Event 7: Station 2 transmits a P message, FSN=2
Event 8: Urgent message ready at Station 4
Event 9: Urgent message ready at Station 1.

…3P1 TP A 1 2P2…
B P P

State: NP = P; FSN = 2
Event 10: Station 1& 4 transmit their short U message (Type 1, 2 or 4), FSN=2 (FSN not
incremented) in bump slot. Messages collide, but activity in Bump Slot raises NP to
Urgent.

…2P2 TP 1U2/4U2…
B
Note 1: Example assumes initially that station 4 has just finished transmitting a frame with an FSN=3 and NP=U, that no
messages are pending transmission from any station at the end of this transmission, and that the net is configured for 4 stations

FIGURE C-5. DAP-NAD example.

353
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

State: NP = U; FSN = 2
Event 11: Station 4 retransmits its U message, FSN = 3

…1U2/4U2 TP N 2 3 4U3…
B U U U

State: NP = P; FSN = 3
Event 12: Station 1 retransmits its U message (Type 3); FSN = 4
Event 13: Routine message ready at Station 1

…4U3 TP N 3 4 1U4…
B U U U

State: NP = P; FSN = 4
Event 14: Station 3 transmits a P message, FSN= 1

…1U4 TP N 4 1 2 3 4 1 2 3P1…

B U U U U P P P P
State: NP = P; FSN = 1
Event 15: Routine message ready at Station 2
Event 16: Station 1 transmits a R message, FSN=2
Event 17 Priority message ready at Station 3

…3P1 TP A 1 2 3 4 1R2…
B P P P P R

State: NP = R; FSN = 2
Event 18: Station 2 transmits a Routine message, FSN=3 .

…1R2 TP A 2R3…
B R

FIGURE C-5. DAP-NAD example - Continued.

354
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

State: NP = P; FSN = 3
Event 19: Station 3 transmits a P message, FSN = 4
Event 20: Urgent message ready at Station 4

…2R3 TP A 3P4…
B R

State: NP = R; FSN = 4
Event 21: Station 4 transmits a U message, FSN = 1 (bumping would have provided no
advantage for station 4 in this instance)

…3P4 TP A 4U1…
B P

State: NP = U; FSN = 1
Event 22: Routine message ready at Station 1,
idle net
Event 23: Station 1 transmits a R
message, FSN = 2

…4U1 TP N 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1R2…
B U U U U P P P P R R R R R R R R R

State: NP = R; FSN = 2
Event 24: Urgent message ready at Station 2, idle net
Event 25: Station 2 transmits a U message, FSN = 3

…1R2 TP A 2 3 4 1 2 3 4 1 2 3 4 1 2U3…
B R R R R R R R R R R R R R

State: NP = U; FSN = 3

…2U3 TP N 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 …
B U U U U P P P P R R R R R R R R R R R R R R R R R…
(Net goes idle for indefinite time period and NADs continue to be calculated by each station during the idle period in order
to avoid collisions when a message of any precedence is ready for transmission at more than one station at the same time in
the future.)
FIGURE C-5. DAP-NAD example - Continued.

355
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

C.4.4.5.1 NAD information field.

To allow for rapid recovery (resynchronization) to the NAD mechanism when messages are not
received correctly due to noise, etc., and to provide stations information about the priority of a
message, an Information Field has been added to the Transmission Header. This field defines
the next access opportunity. This field is present in all physical frames. This field contains the
First Station Number subfield which contains the number of the station that is to have the first
network access opportunity at the next network access period (the one immediately following
this transmission). The number of the station that has the first network access opportunity is the
variable FSN in the equations below. This Information Field also contains the Data Link
Precedence subfield which indicates the highest priority of any message that is contained in the
physical frame. It shall contain the value “0” if an urgent message is in the frame, “1” if a
priority but no urgent message is in the frame and “2” if neither an urgent or priority message is
in the frame. The Type 3 acknowledgment sent in response to a transmission shall use the same
Data Link Precedence and First Station Number as used in the original message to which the
acknowledgment applies. The variable NP in the equations below shall be set equal to the
content of this subfield for the next network access period. If the transmission contained
multiple frames, the variable NP is set equal to the highest value in any of the frames. If network
busy is detected in the reserved network access period, the network reverts to the Urgent mode
regardless of the setting in the Data Link Precedence subfield.

C.4.4.5.2 NAD equations.

A sequence of NADs for each network access period is generated. A station may transmit a
message(s) when the time following the Timeout Period equals any one of the terms (NAD
values) in the sequence. Equation 1 is used by each station to calculate its NADs.

Equation 1: NADn = Fn * Net_Busy_Detect_Time + Max(0, Fn-1) * DTETURN

for n=1 to ∞

NADn is the nth term in the sequence of NADs that are associated with a station during a
network access period. Each term (NAD1, NAD2, NAD3, etc.) is a point in time (a delay
following the Timeout Period) at which a station may begin transmitting. If a station does not
begin transmitting at one term (e.g., NAD2), it shall wait until at least the next term (e.g., NAD3)
before it can begin transmitting. The values of the terms calculated by a station will be different
than the values of the terms that are calculated by all of the other stations (no two stations will
have terms with the same values). Also, the values of the terms calculated by a station for one
network access period will be different than the values of the terms calculated by that station for
the next network access period. Fn is nth term in a sequence of factors that, when used in
conjunction with DTETURN and Net_Busy_Detect_Time, yields the nth NAD term. Fn is an
integer calculated per equation 2.

356
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

Equation 2: Fn = F1 + (n-1)NS for n=1 to ∞

Fn is the nth term in a sequence of factors. F1 is the first term in the sequence and is the base
from which all the other terms are calculated. It is calculated per equation 3. NS is the number
of stations on the network and is the common difference between the terms of the sequence. The
variable n is an integer and has a range of 1 to infinity.

Equation 3: F1 = Fmin + I + P * NS

F1 is the first term in the sequence of factors. The first term that a station can have is the
minimum factor (Fmin) plus the interrupt factor (I) plus an offset determined by priority of
messages awaiting transmission. Fmin is calculated using equation 4. P is the factor that
accounts for message priority. It is calculated using equation 5. Interrupt factor I is computed
using equation 6.

Equation 4: Fmin = SN - FSN if SN > FSN, else Fmin = NS + SN - FSN

Fmin is the minimum possible factor that a station could have if message priority and network
precedence mode were ignored. SN is the number of the station. It is an integer, has a range of
1 to NS, and is assigned at communications initialization. FSN is the number of the station that
has the first network access opportunity for the present network access period. It is set equal to
the value received in the NAD information field of the Transmission Header of the last
transmission on the net.

Equation 5: P = MP - NP if MP > NP, else P = 0

P is the factor that accounts for priority of messages awaiting transmission. It is used to generate
the offset to add to Fmin to generate F1. MP is a variable indicating the highest priority of any
messages awaiting transmission. It shall have a value of “0” if there are any urgent messages
awaiting transmission, the value “1” if there are any priority messages and no urgent messages
awaiting transmission, and the value “2” if there are no urgent or priority messages awaiting
transmission. NP is a variable indicating the highest priority of any messages contained in the
last transmission on the network. It shall have the value “0” if an urgent message was in the last
transmission, “1” if a priority but no urgent message was in the last transmission, and “2” if
neither an urgent or priority message was in the last transmission.

Equation 6: I =1

I is a factor that provides a slot for stations to interrupt the network whenever a station has an
urgent message for transmission.

357
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

C.4.4.5.3 Initial condition state.

The above operations and equations only apply to stations after they are on-line and have
received a message. A station that has just come on line and has not yet received a message is
not in synchronism with other stations (this station has not yet started any timers and if it had,
they would not have been started at the same time as other stations = timers). These stations
shall be considered to be in the initial condition state. Regardless of what causes a station to be
in the initial condition state, transmissions shall be delayed by at least the time specified by
equation 7 while in that state.

Equation 7: INAD = TP + ((3 * NS) + 1) * Net_Busy_Detect_Time + (3 * NS) * DTETURN

INAD (Initial condition state Network Access Delay) is the minimum time that a station shall
delay transmission of a message after it has become capable of receiving and transmitting
messages, but no more than 20 seconds. The TP in the equation shall be a worst case TP, i.e., as
if there had just been a Type 3 message on the network that was addressed to 16 stations on the
net. The FSN in this instance shall be set to the station’s own assigned Station Number (SN).
See paragraph 6.3.3.1 for more information about assigning Station Numbers.

C.4.4.6 Data and Voice - Network Access Delay (DAV-NAD).

DAV-NAD is almost identical to DAP-NAD defined in C.4.4.5. Implementers of DAV-NAD
should refer to paragraph C.4.4.5 for a description of the Network in the three precedence modes,
C.4.4.5.1 for a description of the NAD information field, C.4.4.5.2 for NAD equations and
C.4.4.5.3 for Initial condition state.

The only difference is the way the FSN is incremented. For DAV-NAD, the station that transmits
the message shall increment the First Station Number subfield contained in the last message it
received by a fixed constant called the FSN Increment Number (FSNIN) and place the result in
the First Station Number subfield of the Transmission Header. If the increment of FSN causes
FSN to be greater than NS (i.e., FSN + FSNIN > NS), then the station shall set FSN = FSN +
FSNIN - NS prior to placing the value in the FSN subfield of the Transmission Header (e.g., if
NS = 8, the current FSN = 7, and FSNIN = 3, then the new FSN = 2). This fixed constant is
provided in TABLE C-IV.

DAV-NAD uses the parameters specified for DAP-NAD in the MIL-STD-188-220 Parameter
Table, which is available on the CNRWG website specified at 2.3.4.

358
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

TABLE C-IV. FSN Increment Numbers for DAV-NAD

Number of Stations FSNIN

(NS)
2 1
3 2
4 3
5 2
6 5
7-8 3
9 4
10 3
11 4
12-14 5
15-20 7
21 8
22-23 9
24-32 11
33-38 13
39-51 17
52-56 19
57-64 23

FIGURE C-6 shows an example of the DAV-NAD (FSNIN from TABLE C-IV) key and
FIGURE C-7 shows an example of using the key.

359
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

NP = Network Precedence, highest MAC precedence of any frame in the last transmission (NP = URGENT this
example)
NS = Number of Stations (NS = 4 this example) the net is configured to support
FSNIN = First Station Number Increment Number (FSNIN = 3 this example)
NAD = Net Access Delay, time after TP that a station must listen for a busy net before starting to transmit
Net Busy Detect, time from when a station begins transmitting until it can be detected by other stations
A = Any Station Number, used to indicate that any station may transmit during the bump slot to quickly transmit an
urgent message and set NP to urgent
N = No Station Number, used to indicate that no station may transmit during this bump slot because NP is Urgent.

EOT = End Of Transmission, time at which stations perceive a transmission ending

FSN = First Station Number, station number having the first opportunity to transmit (FSN = 2 this example) at
the current NP
Increasing NAD time per station number with each listen time slot equal to the Net Busy Detect
time

…4U2 TP N 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1R1…
B U U U U P P P P R R R R R R R R R R R R R R R R
Station 1 transmits
routine message,
FSN=1 (2 + FSNIN)
R = Routine slot, third through N precedence groups of NS NAD times
for stations having urgent, priority or routine messages for transmission
P = Priority slot, second precedence group of NS NAD times reserved for
stations having urgent or priority precedence messages for transmission
U = Urgent slot, first precedence group of NS NAD times reserved for stations having urgent
precedence messages for transmission
B = Bump slot, slot that is present immediately following any transmission (NP = U, NP = P or NP=R).
Any station may transmit an urgent message in this slot provided NP is not Urgent.
TP = Timeout Period, period of time (as calculated by each station) to wait from the EOT until subsequent
messages could start being transmitted (NAD=0)
= Station 4 transmits urgent message, FSN=2

FIGURE C-6. DAV-NAD example key

360
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

Initial State: NP = U; FSN = 3 (See Note 1)

Event 1: Routine message ready at Station 1
Event 2: Station 1 transmits a R message, FSN=2

…4U3 TP N 3 4 1 2 3 4 1 2 3 4 1R2…
B U U U U P P P P R R R R

State: NP = R; FSN = 2
Event 3: Priority message ready at Station 3
Event 4: Station 3 transmits a P message, FSN=1
Event 5: Priority message ready at Station 2

…1R2 TP A 2 3P1…
B R R P

State: NP = P; FSN = 1
Event 6: Priority message ready at Station 3
Event 7. Station 2 transmits a P message, FSN=4
Event 8: Urgent message ready at Station 4
Event 9: Urgent message ready at Station 1.

…3P1 TP A 1 2P4…
B P P P

State: NP = P; FSN = 4
Event 10: Station 1 transmits its short U message (Type 1), FSN=4 (FSN not incremented) in
bump slot. Station 4 does not utilize bump slot because FSN is 4. Activity in Bump Slot
raises NP to Urgent.

…2P4 TP 1U4…
B U

*Note 1: Example assumes initially that station 4 has just finished transmitting a frame with an FSN=3 and NP=U, that no messages are pending
transmission from any station at the end of this transmission, and that the net is configured for 4 stations

FIGURE C-7. DAV-NAD example

361
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

State: NP = U; FSN = 4
Event 11: Station 4 transmits its U message (Type 3), NP remains at U, FSN = 3

…1U4 TP N 4U3…
B U U

State: NP = U; FSN = 3
Event 12: Station 1 retransmits its U message (Type 3), NP at U, FSN = 2

…4U3 TP N 3 4 1U2…
B U U U U

State: NP = U; FSN = 2
Event 13: Routine message ready at Station 1, NP at U, FSN = 2
Event 14: Station 3 transmits its P message, NP at P, FSN = 1

…1U2 TP N 2 3 4 1 2 3P1…
B U U U U P P P

State: NP = P; FSN = 1
Event 15: Routine message ready at Station 2, NP at R, FSN = 1
Event 16: Station 1 transmits its R message, NP at R, FSN = 4

…3P1 TP A 1 2 3 4 1R4…
B P P P P R R

FIGURE C-7. DAV-NAD example-Continued

362
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

State: NP = R, FSN = 4

Event 17: Priority message ready at Station 3, NP at R, FSN = 4

Event 18: Station 3 transmits its P message, NP raised to P, FSN = 3

…1R4 TP A 4 1 2 3P3…
B R R R R P

State: NP = P; FSN = 3
Event 19: Station 2 transmits its R message, NP at R, FSN = 2

…3P3 TP A 3 4 1 2 3 4 1 2R2…
B P P P P R R R R R

State: NP = R; FSN = 2
Event 20: Urgent message ready at Station 4, NP at R, FSN = 2
Event 21: Station 4 transmits its U message, NP raised to U, FSN = 1

…2R2 TP A 2 3 4U1…
B R R R U

State: NP = U; FSN = 1
Event 22: Routine message ready at Station 1, NP at U, FSN = 1
Event 23: Station 1 transmits its R message, NP at R,
FSN = 4
Event 24: Urgent message ready at
Station 2, NP at R, FSN = 4

…4U1 TP N 1 2 3 4 1 2 3 4 1R4 …
B U U U U P P P P R R

FIGURE C-7. DAV-NAD example-Continued

363
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

State: NP = R; FSN = 4
Event 25: Station 2 transmits its U message (Type 1) in Bump Slot, NP at U, FSN = 4
(FSN not incremented)
Event 26: Station 2 retransmits its U message (Type 3), NP at U,
FSN = 3

…1R4 TP 2U4…
B

State: NP = U; FSN = 4

Event 26: Station 2 retransmits its U message (Type 3), NP at U,

FSN = 3

…2U4 TP N 4 1 2U3…
B U U U U

State: NP = U; FSN = 3

…2U3 TP N 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 …
B U U U U P P P P R R R R R R R R R R …
(Net goes idle for indefinite time period and NADs continue to be calculated by each station during the idle period in order
to avoid collisions when a message of any precedence is ready for transmission at more than one station at the same time in
the future.)

FIGURE C-7. DAV-NAD example-Continued

C.4.5 Voice/data network sharing.

A station may support this protocol on a network where both voice and data transmissions are
allowed to occur. When operating in a mixed voice and data network, voice and data network
sharing shall operate in the following manner:

a. A receive operation shall be considered a voice reception unless a valid synchronization

pattern is identified. A receive operation that is less than 0.75 seconds in length shall be
considered a noise burst instead of a voice reception. See Section 6, Notes, (6.3.2.2.2) for
additional information.

364
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX C

b. The network shall be synchronized based on RHD and TP timers, which are driven only
by data transmissions and receptions. Voice receptions and noise bursts shall not be used for
resynchronizing network timers.

c. A station shall not transmit during a noise burst or a voice reception. After completion
of a voice reception, a station shall wait at least TURN seconds before initiating transmission.
When voice/noise reception begins and ends during a Type 3 acknowledgment sequence, an
acknowledging station shall begin transmission only at the beginning of its individual RHD and
shall not begin transmission after the start of its RHD period.

d. After completion of a voice reception, operation of the P-NAD network access scheme
shall be reinitiated if P-NAD is being used. P-NAD consists of a sequence of NAD slot groups.
Within each NAD slot group there is one NAD slot assigned to each station and one slot
assigned to the station that transmitted last. After a voice reception is completed, the current,
partially-completed NAD slot group and the next complete NAD slot group shall be used only by
stations with urgent-precedence data transmissions. The NAD slot group after these groups shall
be used only by stations with urgent-precedence or priority-precedence data transmissions.
Subsequent NAD slot groups may be used by any station. This preserves the intent of P-NAD,
which is to deterministically avoid collisions and to ensure that high-precedence traffic is always
transmitted first.

e. RHD and TP timers shall not be suspended or resumed as a result of voice receptions.

f. Data link protocol timers shall be suspended and resumed as a result of voice receptions.

g. The Intranet layer timers shall not be suspended and resumed as a result of voice
receptions.

h. Relative priorities of voice and data on the network shall be adjusted by selectively
enabling or disabling physical and/or data link concatenation for a station. Concatenation may
be disabled to give priority to voice and may be enabled to give priority to data.

365
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX D

COMMUNICATIONS SECURITY STANDARDS

D.1 General.

D.1.1 Scope.
This appendix describes the COMSEC interoperability parameters for DMTD and interfacing
C4I systems.

D.1.2 Application.
This appendix is a mandatory part of MIL-STD-188-220 for systems using COMSEC. The
information contained herein is intended for compliance.

D.1.3 Interoperability.
This appendix cannot guarantee the user end-to-end interoperability. The selection of COMSEC
and signaling is a function of communications media. Traditional COMSEC equipment is
specific to communications media and may not be compatible due to signaling differences. The
systems integrators and systems planners shall ensure that compatible media and signaling are
chosen if interoperability is desired. This COMSEC specification will provide for
interoperability of the underlying encryption algorithm.

D.2 Applicable Documents.

a. 0N431125 WINDSTER Cryptographic Standards (U)

b. DS-68 INDICTOR Cryptographic Standards (U)

Information regarding 0N431125 WINDSTER and DS-68 Cryptgraphic Standards can be

obtained from Director, National Security Agency NSA/CSS Enterprise Standards Program
(NESP), 9800 Savage Road, STE (DE), Fort George G. Meade, MD 20755-6997 Telephone:
(301) 688-6194.

D.3 Definitions.
Refer to APPENDIX A.

D.4 General requirements.

The backward-compatible mode applies when link encryption is provided by external COMSEC
devices. These external COMSEC devices may be standalone equipment (such as the VINSON
and KG-84) or communications equipment with built-in COMSEC. The forward-compatible
mode shall apply for all DTE subsystems with embedded COMSEC. The backward-compatible
mode may also be emulated using embedded COMSEC devices.

366
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX D

D.5 Detailed requirements.

D.5.1 Traditional COMSEC transmission frame.

The traditional COMSEC transmission frame shall be composed of the following components, as
shown in FIGURE D-1. FIGURE D-1 provides additional detail to FIGURE 4.

a. COMSEC Bit Synchronization

b. COMSEC Frame Synchronization

c. Message Indicator

d. Phasing

e. Transmission Synchronization (see 5.2.1.3).

f. Data Field (including Transmission Header)

g. COMSEC Postamble

Encrypted

COMSEC COMSEC
Message Data Field
Bit Frame
Indicator Transmission Including COMSEC
Sync (encoded) Phasing Synchronization Transmission
Sync Postamble
COMSEC PREAMBLE Header

External
External COMSEC COMSEC

FIGURE D-1. Traditional COMSEC transmission frame structure.

D.5.1.1 COMSEC preamble field.

The COMSEC preamble field shall consist of three components: a COMSEC bit synchronization
subfield, a COMSEC frame synchronization subfield, and a Message Indicator (MI) subfield.
This field is used to achieve cryptographic synchronization over the link.

D.5.1.1.1 COMSEC bit synchronization subfield.

This subfield shall be used to provide a signal for achieving bit synchronization and for
indicating activity on a data link to the receiver. The duration of the COMSEC bit
synchronization subfield shall be selectable from 0.065 to 1.5 seconds. The COMSEC bit
synchronization subfield shall consist of the data-rate clock signal for the duration of the
subfield.

367
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX D

D.5.1.1.2 COMSEC frame synchronization subfield.

This subfield shall be used to provide a framing signal indicating the start of the encoded MI to
the receiving station. This subfield shall be 465 bits long, consisting of 31 Phi-encoded bits, as
shown in FIGURE D-2a. The Phi patterns are a method of redundantly encoding data bits. A
logical 1 data bit shall be encoded as shown in FIGURE D-2b, and logical 0 data bit shall be
encoded as shown in FIGURE D-2c. A simple majority voting process may be performed at the
receiver to decode the Phi-encoded frame pattern to its original format.

MSB LSB
0111111111111111111111111111111

FIGURE D-2a. Phi encoding.

MSB LSB
000100110101111

FIGURE D-2b. Phi encoding for logical 1 data bit.

MSB LSB
111011001010000

FIGURE D-2c. Phi encoding for logical 0 data bit.

FIGURE D-2. COMSEC frame synchronization pattern for Phi encoding.

D.5.1.1.3 Message Indicator subfield.

This subfield shall contain the COMSEC-provided MI, a stream of random bits that are
redundantly encoded using Phi patterns. Cryptographic synchronization is achieved when the
receiver acquires the correct MI.

D.5.1.2 Phasing.
This field shall be a string of alternating ones and zeros, beginning with a one, sent by the DTE.
The length of this field is between 0.000 and 10.000 seconds. Phasing is further described in
C.3.2.2.

368
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX D

D.5.1.3 Transmission synchronization field.

This field, consisting of the frame synchronization subfield, optional robust frame format
subfield, and the TWC subfield is defined in 5.2.1.3.

D.5.1.4 Data field.

The Data Field is defined in 5.3.1 and defined in 5.2.1.4.

D.5.1.5 COMSEC postamble field.

This field shall be used to provide an end-of-transmission flag to the COMSEC function. This
will be automatically performed by the COMSEC key generator (KG). Refer to 0N431125,
WINDSTER Cryptographic Standards, or DS-68, INDICTOR Cryptographic Standards, as
appropriate.

D.5.1.6 COMSEC algorithm.

The COMSEC algorithm shall be backward-compatible with VINSON equipment. Refer to
0N431125, WINDSTER Cryptographic Standards.

D.5.1.7 COMSEC modes of operation.

The COMSEC shall be operated in Mode A. The rekey functions shall be performed through the
use of KY-57 rekeys for backward compatibility. Refer to 0N431125, WINDSTER
Cryptographic Standards.

D.5.2 Embedded COMSEC transmission frame.

The embedded COMSEC transmission frame shall be composed of the following components, as
shown in FIGURE D-3:

a. Phasing

b. Frame Synchronization
- Standard Frame Synchronization
- Robust Frame Synchronization

c. Robust Frame Format (RCP only)

d. Message Indicator

e. Transmission Word Count

f. Data Field

g. COMSEC Postamble

369
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX D

Encrypted
Standard
Frame Robust Frame Robust Message Data Field
Transmission
Sync Sync Frame Indicator Including COMSEC
Phasing Word Count
Frame Format (encoded) Transmission Postamble
Sync Header
Transmission Synchronization

FIGURE D-3. Embedded COMSEC transmission frame structure.

D.5.2.1 Phasing.
This field shall be a string of alternating ones and zeros, beginning with a one, sent by the DTE.
The length of this field is between 0 and 10 seconds. Phasing is further described in C.3.2.2.

D.5.2.2 Frame Synchronization subfield.

This subfield shall be either the Robust Frame Synchronization subfield defined in 5.2.1.3.1.2 or
the Frame Synchronization subfield defined in 5.2.1.3.1.1. In either case frame synchronization
is to be provided for both the message frame and the COMSEC.

D.5.2.3 Robust Frame Format subfield.

When the Robust Frame Synchronization subfield is used, the Robust Frame Format subfield
defined in 5.2.1.3.1.2 also shall be used. The Robust Frame Format subfield shall not be used
when the Robust Frame Synchronization subfield is not used.

D.5.2.4 Message Indicator field.

This field shall contain the MI, a stream of random data that shall be encoded using Golay, as
defined in 5.3.14.1 and 5.3.14.2. Cryptographic synchronization is achieved when the receiver
acquires the correct MI. The COMSEC shall provide the MI bits. For backward compatibility,
these MI bits shall be redundantly encoded using Phi patterns, as described in D.5.1.1.2.

D.5.2.5 Transmission Word Count subfield.

This Transmission Word Count subfield is defined in 5.2.1.3.1.4.

D.5.2.6 Data Field.

The Data Field is defined in 5.3.1 and 5.2.1.4.

D.5.2.7 COMSEC Postamble field.

This field shall be used to provide an end-of-transmission flag to the COMSEC function. The
COMSEC Postamble field may be used by the receiving data terminal as an end-of-message flag
as well.

D.5.2.8 COMSEC algorithm.

Refer to 0N431125, WINDSTER Cryptographic Standards.

370
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX D

D.5.2.9 COMSEC modes of operation.

COMSEC shall be operated in Mode A for all applications. The rekey functions shall be
performed through the use of KY-57 rekeys for backward-compatibility and shall be performed
through over-the-air-rekeying (OTAR) techniques for forward compatibility. Rekey signaling
for OTAR shall be supplied by the host equipment. Refer to 0N431125, WINDSTER
Cryptographic Standards.

371
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

CNR MANAGEMENT PROCESSES USING XNP

E.1 General.

E.1.1 Scope.
This appendix describes the XNP management processes associated with the data link and
subnetwork layer. Since the tactical subnetwork using CNR may not be fully connected and
since it is critical that all stations are provided compatible operating parameters, an Exchange
Network Parameters (XNP) message has been defined. XNP messages can be forwarded which
allows disconnected stations to participate fully in the subnetwork, and can be used to change
subnetwork parameters dynamically.

E.1.2 Application.
This appendix is not a mandatory part of MIL-STD-188-220. The information contained herein
is intended for guidance only. If XNP is implemented, the information contained herein is
mandatory and is intended for compliance.

E.1.3 Clarification of examples

Throughout this standard, many examples are provided as guidance only. In the event that an
example is inconsistent with the text and DSPICS of the standard, the text description/DSPICS
takes precedence over the example. Should a user detect any inconsistent examples, they should
notify the CNRWG so that the example can be updated for a future release of the standard. It
should also be noted that while all examples should be accurate in relation to the feature they are
explaining, some of the examples provided may not reflect changes made to unrelated sections of
the standard (e.g., examples to illustrate the use of XNP reflect the current version of XNP, but
may not reflect the current version of the Intranet Header)..

E.2 Applicable documents.

RFC1321 The MD5 Message-Digest Algorithm April 1992
RFC3174 US Secure Hash Algorithm 1 (SHA1) September 2001
RFC2313 PKCS #1: RSA Encryption Version 1.5 March 1998
MIL-STD-2045-47001D 29 September 2005

372
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

E.3 Network configuration.

The CNR management process defined herein covers the subnetwork management operations for
a MIL-STD-188-220 subnetwork. If a station moves into or through different subnetworks, the
Data Link addresses and operating parameters may change in each subnetwork, and XNP will
automate the change of parameters and address from one subnetwork to another.

E.3.1 Network Control Station.

The Network Control Station (NCS): (1) maintains a common set of network parameters for the
subnetwork, (2) allocates addresses and updates the parameters based on the number of stations
in the subnetwork, (3) provides a join service to assign an address to a station and to provide
network parameters for entering the subnetwork, (4) provides a leave process for stations exiting
the subnetwork, (5) provides an address resolution service and (6) provides multicast address
assignment. It is desirable that all stations be capable of performing the functions of NCS. The
NCS may be appointed by a network authority (i.e., manual election of NCS) or negotiated via
the automatic election processes as described in E.6.3 and E.4.2.8 (i.e., automatic election of
NCS). Only one station is designated as the active NCS at any one time in a subnetwork, and
one or more stations may act as a backup NCS. For the manual selection process, it is the
responsibility of the network authority to manage NCS assignment (i.e. the XNP protocol does
not provide for NCS deconfliction or handover for this method). When the automatic election
process is used to select a NCS, the election process shall designate the active NCS. A
configuration parameter or an operator command either at initialization or during normal
operation, may inform the station of its NCS responsibility. Many stations may have the
capability to become the NCS and the automatic election process will elect the active NCS
independent of the number of stations capable of being the active NCS. The active NCS and any
backup NCSs shall bind to the special address 2. Both the active and any backup NCS will
receive all Join Messages which are addressed to Special address 2; however, only the active
NCS shall respond. Also any backup NCS will receive the messages sent to the Global Group
Multicast address: Join Accept, Status Notification, Reject, Goodbye and Hello message.
Therefore any backup NCSs shall have the required database to assume the active NCS role if
the active NCS fails or hands over control.

E.3.1.1 NCS mode.

A NCS may specify in the Status Notification message that the subnetwork supports Standard
Network Settings (see 5.5.2.1 Table map/TABLE XIV Standard Network Settings) which is
indexed by an Operational Parameter Sets (OPS) number. The subnetwork is either configured
to be in OPS mode or Explicit mode.

Explicit mode is the default mode, and is the most general. It requires less preplanning; however,
it requires more blocks to be sent. In Explicit mode all parameters are specified in the blocks
attached to the XNP messages.

In OPS mode a single number is used to represent the subnetwork parameters which are
independent of the number of stations in the subnetwork. When a subnetwork supports OPS
mode, NCS assignments should match one of the OPS numbers in as described in Standard

373
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

Network Settings table. When using OPS mode, all stations should be preloaded with the same
version of the Standard Network Settings table. If a station that has not been preloaded with the
correct version of the Standard Network Settings table, it will not be able to join a subnetwork in
OPS mode.

If a station has been preloaded with an OPS number and it attempts to join an Explicit mode
subnetwork, it will receive a reject; however, in the reject the correct explicit parameters will be
included which will provide the parameters for the station to join. The NCS can be in Explicit
mode or OPS mode independent of how the NCS is elected (manual or automatic).

E.3.2 Dynamic and Static stations.

Stations may enter the subnetwork as a static station or a dynamic station. Static stations are
stations that are preplanned to enter the subnetwork. Static stations are associated with an NCS
that has been preloaded with addresses of the static stations. The static station has been
preloaded with a valid address and may have a complete set of subnetwork parameters
preloaded. In this condition no modification of the subnetwork parameters is required when the
station enters the subnetwork; therefore, the station does not need to send a Join Request
message. The station can just send a Hello message when it enters the subnetwork and a
Goodbye when it leaves the subnetwork. However a static station may enter a subnetwork where
the number of stations and the subnetwork parameters are changing due to dynamic stations
joining and leaving the subnetwork; therefore, a static station may enter the subnetwork by
sending a Join Request to learn the current parameters (e.g., number of stations for NAD
calculation). When a static station enters a subnetwork and sends a Join Request to learn the
current parameters, it specifies its static address in the Join Request. Static stations are not
automatically removed and a NAD slot shall always be allocated for the static station.

Dynamic stations provide the most effective use of bandwidth and the most flexibility. The
dynamic station enters the subnetwork by sending a Join Request message to learn its address
and the subnetwork parameters. While the station is in the subnetwork a NAD slot and link
address is allocated to the station, and when the station leaves the subnetwork it is removed and
its NAD slot and address are recycled. The NAD slot and address is leased for a period of time.
The length of the lease is configurable, and the setting of the length of the lease should be based
on mobility. If stations in the subnetwork rarely leave the subnetwork, the time of the lease can
be a large number; however, a subnetwork that has stations that join/leave the subnetwork often,
the length of the lease should be shorter. The lease is refreshed by sending a periodic Parameter
Update message. If the lease time is shorter more messages are sent to maintain the lease; and if
lease times are too long, bandwidth may be lost due to NAD slots being allocated to stations that
have left the subnetwork.

E.3.3 IPv4/v6 address assignment and resolution.

The NCS can also provide IPv4/v6 address and subnet mask assignment. Stations may request
an IP address assignment and register their URN or Unit Name (see MIL-STD-2045-47001).
XNP provides a scaled down version of Domain Name System (DNS) and Dynamic Host
Configuration Protocol (DHCP) in a mobile environment. Normally in the commercial networks

374
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

DHCP and DNS servers are statically assigned, and are not designed to operate in a mobile
environment. The XNP’s IPv4/v6 address assignment and resolution service, allows the users to
address peer stations in the subnetwork by Unit Name or URN, and to send messages to peer
stations without the knowledge of assigned IP or link address.

E.3.4 Multicast address assignment.

The NCS can assign multicast group addresses to specific nodes. A multicast address is used to
send a datagram to multiple stations using a single destination address. When using a multicast
address as a destination address, the originator does not need to know the stations that are
members of the group. Any node can address a message to a multicast address; however, only
members of the multicast group shall receive and pass the payload to the N+1 layer (e.g., IP
layer). The XNP multicast address assignment makes the receiving node a member of a multicast
group by assigning a multicast address.

E.4 Exchange Network Parameters (XNP) messages.

XNP messages have been designed to provide the network/subnetwork management capabilities.

E.4.1 XNP message structure.

XNP messages are composed of a one-octet Version Number field (set to “1”for MIL-STD-188-
220D w/CHANGE 1), followed by the actual XNP message and one or more data blocks as
shown in FIGURE E-1.

Most Significant Octet<——————————————————>Least Significant Octet

Version One or More

Number XNP Message XNP Data Blocks
(Identification plus
basic information fields)

FIGURE E-1. XNP message format.

Detailed formatting of XNP Messages and each Data Block is described in the following
paragraphs and tables. Each XNP Message and each Data Block consists of data fields. The
data fields may be one or more octets in length and may be value coded or bit mapped. When
the data field size exceeds one octet, octets are transmitted from the most significant octet (low
number) to the least significant octet (high number). Bit mapping uses each bit individually in
an on/off representation such that multiple values may be represented by each octet. Bit ”0”
always represents the least significant bit (20). FIGURE E-2 depicts an example 4-octet data
field.

375
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

Most Significant Octet<———————————>Least Significant Octet

Octet 1 2 3 4
Bit 7 0 7 0 7 0 7 0
Bit 31 24 23 16 15 8 7 0
Most Significant Bit<———————————————>Least Significant Bit

FIGURE E-2. Example 4-octet XNP data field.

Undefined bits shall be set to zero on transmission and ignored on receipt. Undefined values are
invalid. The processing of XNP messages containing undefined/invalid values are:

a. Undefined bits in a bit map shall be ignored.

b. If the Version Number is invalid or unsupported, the XNP message shall be discarded.

c. If the Message Number field is invalid, the XNP message shall be discarded.

d. If the Length field is invalid in any Message Block (i.e., the value indicates that there
are more octets than actually exist in the XNP message), the rest of the XNP message shall be
discarded and processing of the XNP message shall continue.

e. If the Block Number field is invalid in any XNP message, the block shall be discarded
and processing of the XNP message shall continue.

f. If the Length field is invalid in any Data Block (i.e., the value indicates that there are
more octets than actually exist in the XNP message), the rest of the XNP message shall be
discarded but the preceding blocks shall be processed if possible.

g. If any other field is invalid in any Data Block, that data block shall be discarded and
processing of the XNP message shall be continued.

h. If any other field is invalid in an XNP message, the XNP message shall be discarded.

E.4.1.1 Forwarding.
A station joining a network might not have knowledge of the network topology and might be
unable to contact all stations in the network being joined (e.g., stations might be behind obstacles
or out of range). In a multi-hop environment (all stations in the network may not be within one-
hop of each other) participating stations shall support multicast forwarding (5.4.1.4), and intranet
relay as described in Appendix I. If all stations are guaranteed to be within one-hop of each
other, the stations do not need to support the multicast forwarding or the intranet relay. When
stations are guaranteed to be within one-hop of each other, the special address can be specified
as the Data Link address and no addresses are required in the intranet header. When stations are
not guaranteed to be within one hop of the NCS, the special addresses (5.3.4.2.2.2.4) should be

376
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

used in the intranet header and the data link destination address should be set to the One-hop
multicast address. Also in this document when a message is specified as being addressed to the
Global Group multicast, the message is address to the Global Group multicast address in the
Intranet header Destination/Relay address field; however, if all stations are guaranteed to be
within one-hop of the NCS, no intranet address is required, and the message may be addressed to
the One-hop multicast address in the link layer address. The station that is the NCS shall have
two addresses: its normal address and the special address 2. However the special address does
not give the NCS an extra NAD slot. The address of active NCS may be preplanned or learned
by receiving a Status notification message which includes the address of the active NCS. The
use of the active address of the NCS, instead of special address 2, may save some forwarding
overhead; however, it limits flexibility (i.e., automatic handover to a backup NCS). In a multi-
hop environment the Intranet header’s final destination address may be set to the active address
of the NCS, the path (see appendix I) should be included in the Intranet header. When stations
are guaranteed to be within one-hop of each other, the active NCS address can be specified as the
Data Link address and no addresses are required in the intranet header. The active NCS address
should only be used by stations when subnetwork has a manually elected NCS.

E.4.1.2 Message and data block structure.

XNP messages and data blocks each have the structure shown in FIGURE E-3. Each message
and data block starts with a one-octet identifier (message or block number) and a one-octet
length field. These are followed by n data fields. Some data fields consist of multiple octets.

XNP messages are listed in TABLE E-I. Each of these messages may be combined with one or
more of the XNP Data Blocks listed in TABLE E-II, depending upon the level of detailed
information required. Super script numbers in Message and Block tables identify notes at the
end of this appendix.

A Terminator Block (TABLE E-III) designates the end of the XNP message and all associated
data blocks. The Terminator Block is required at the end of all XNP messages. Any blocks or
messages appearing after the Terminator Block shall be ignored

Octet Number Field Identification

1 Identifier octet (message or block number)
2 Message or block length
3 Data field 1
• •
• •
• •
n+2 Data field n

BLOCK
NUMBER TITLE DESCRIPTION
17 XNP Parameters Provides the XNP timers necessary to join and leave
the subnetwork.
18 Robust Parameters The Robust Parameters (see Appendix J).
19 IPv6 Top Level/Site Used for IPv6 Addresses.
level address
20 OPS Identifies the OPS (5.5.3) value which specifies:188-
220 optional services and the NAD parameters
21 S/R Basic Segmentation/Reassembly Basic Parameters
22-254 Undefined
255 Terminator Block Notification of end of block transmissions.
NOTE: S/R Basic block belongs in the MIL-STD-2045-47001 specification; however, to
simplify configuration, all configuration parameters are being provided by XNP.

TABLE E-III. Terminator block.

OCTET FIELD IDENTIFICATION VALUE
1 End of message designator: Identifies the end of the 255
XNP message and associated data blocks.

E.4.2 XNP message formats.

These XNP messages may be combined with one or more data blocks to provide detailed
subnetwork operating parameters. These messages are described in the following paragraphs
and are depicted in TABLE E-IV through TABLE E-XIX.

E.4.2.1 Join Request.

The Join Request message (TABLE E-IV) shall be sent by a station attempting to join a
subnetwork. The joiner is expected to provide a unique identifier and indicate all implemented
capabilities in order to lessen the probability of rejection by the NCS. The unique identifier may
be used to resolve ambiguities during the joining procedure. The unique identifier may be the
24-bit Unit Reference Number (URN) with zeros in the eight most significant bits. If there is no
URN a unique identifier shall be assigned to each potential user by a mechanism outside the
scope of this appendix.

In a multi-hop subnetwork the Intranet header’s final destination address, which is indicated by
setting the Destination bit to “1” corresponding to the Destination/Relay Address field of the

380
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

final destination, shall be set to the special address 2 or the address of the active NCS. The
address of the active NCS may be learned by receiving a Status Notification message which has
the address of the active NCS. If the Intranet header’s final destination address is set to the
address of the active NCS, the path (see APPENDIX I) shall be included in the Intranet header.

TABLE E-IV. Join Request message.

OCTET FIELD IDENTIFICATION VALUE
1 Message Number: Identifies specific message content. 20
2 Message Length: Indicates the length of the Join 7
Request Message block in octets
3-6 Station Identifier: Identifies the station trying to join Unique identifier for the
the network station
7 Link Address or marker subfield: Data Link address 0 = not specified
(see 5.3.4.2.2) which has been assigned to the joining 4 - 95 = Data Link address
station by other means (e.g., statically). When the 32 or 32-bit marker subfield
48 bit marker is used the Link Address Extension Block 48-bit marker subfield
(Block 16) must be appended to the end of this Block.

TABLE E-V and TABLE E-VI provide a detail listing of what blocks should be included in the
Join Request. The joining station fills in the applicable data blocks with the parameters
supported by the joiner.

Some fields within the Join Request data blocks allow the joiner to set all bits, indicating that all
capabilities of that field are supported by the joining station, and the NCS is expected to provide
the desired subnetwork operating parameters.

381
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

TABLE E-V. Blocks included in the Join Request in OPS mode

Station Blocks included in the Join Request Optional

Configuration blocks
Static station with all 141 or 2, 164 , 199, 20, 255 13
13 ,15
capabilities (link
address included in
Join Request)
Dynamic station 141 or 2, 20, 255 1313,15
with all capabilities
Static station limited 141 or 2, 164 , 199, 20, 255 1313,15
capabilities (link
address included in
Join Request)
Dynamic station 141 or 2, 20, 255 1313,15
with limited
capabilities

TABLE E-VI. Blocks included in the Join Request in Explicit mode

Station Blocks included in the Join Request Optional

Configuration blocks
Static station with all 33, 141 or 2 ,164 ,199 ,255 13
13 ,15
capabilities
Dynamic station 33, 141 or 2 , 255 1313,15
with all capabilities
Static station limited 2, 33, 164 141 or 2,199, 255 1313,15
capabilities
Dynamic station 2, 33, 164 141 or 2, 255 1313,15
with limited
capabilities

E.4.2.2 Join Accept.

The Join Accept message (TABLE E-VII) shall be sent by a NCS in response to the Join Request
message, provided entry to the subnetwork has been approved. In a multi-hop subnetwork the
Intranet header’s final destination address shall be set to the Global Group multicast address.
The data link destination address shall be set to the requesting station’s unicast address as well as

382
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

to the One-hop multicast address. Actual subnetwork operating parameters shall be provided in
the appropriate data blocks combined with the Join Accept message. The appropriate data
blocks appended to the Join Accept message depends upon the subnetwork configuration and the
capabilities of the joining station. TABLE E-VIII and TABLE E-IX provides a listing of what
blocks should be included in the Join Accept. The Parameter Update Identifier uniquely
identifies the current configuration, and shall be incremented when a dynamic station joins or
leaves the subnetwork, or the subnetwork parameters have changed (see TABLE E-VIII and
TABLE E-IX). After the Join Accept is sent the Status_Notification_ After_Change_Timer ( 1-
255 seconds [default 10 seconds]) is started. When the
Status_Notification_After_Change_Timer expires a Status Notification message shall be sent.
The Status Notification message is sent to ensure the all stations have the correct parameters
after any change of the network parameters (e.g., Join Accept or Join Reject). The
Status_Notification_After_Join_Timer is singleton timer, which is restarted after each change.
Therefore many stations may join in a short period of time and only one Status Notification
message will be sent (i.e., only one Status_Notification_After_Join_Timer will expire).
If a station receives a Join Accept message or any other message which indicates there is an
address conflict (i.e., another station with the same link address assigned to this station) it shall
compare the Station Identifiers. The station with the lower Station Identifier shall keep the
address and the station with the higher Station Identifier shall reinitiate the join process, and
optionally include the Error block in the Join Request.

TABLE E-VII. Join accept message.

OCTET FIELD IDENTIFICATION VALUE

1 Message Number: Identifies specific message content. 21
2 Message Length: Indicates the length of the Join 8
Accept Message block in octets.
3 Parameter Update Identifier: A number to uniquely 0 = Unknown
identify the latest parameter values distributed for use 1 - 255 in increments of 1
in the subnetwork.
4-7 Station Identifier: Identifies the station trying to join Unique identifier for the
the subnetwork. station
8 Link Address or marker subfield: Data Link address 4 - 95 = Data Link address
(see 5.3.4.2.2) assigned to joining station or the size of 32-bit marker subfield
the data link address in the Link Address Extension 48-bit marker subfield
Field. When the 32 or 48 bit marker is used the Link
Address Extension Block (Block 16) must be
appended to the end of this message.

383
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

TABLE E-VIII. Blocks Returned in the Join Accept in OPS mode

Blocks returned Optional

blocks
519, 1110 | 12 ,141 | 18,164, 17, 191 & 6, 20, 255 8,15

TABLE E-IX. Blocks Returned in the Join Accept in Explicit Mode

Blocks returned Optional

blocks
2, 3, 4, 519, 616, 717, 97,108,1110 | 12,12,141 | 18 164 ,17,185 ,191 & 6, 21, 255 8,15

E.4.2.3 Join Reject.

The Join Reject message (TABLE E-X) shall be sent by the NCS to indicate the rejection of a
received Join Request message. Also the Join Reject shall be sent by the NCS when a dynamic
station has been removed from the subnetwork by the NCS (see Parameter Update Refresh
Timer) or reception of a Goodbye message from a dynamic station. When a Join Reject is sent
which changes the Parameter Update Identifier, the Status_Notification_After_Change_Timer
shall be started.

In a multi-hop subnetwork the Intranet header’s final destination address shall be set to the
Global Group multicast address. The data link destination address shall be the One-hop
multicast. The Join Reject shall be interpreted as being applied to the station identified in the
Station Identifier or the Link Address field.

When the Join Reject message is sent in response to the Join Request message and the reason for
rejection is that the parameters provided are not presently acceptable in this subnetwork, the
Error Block may be provided with the Join Reject to identify the reason for the reject. This error
indication shall be specified in data block 13, which specifies the error reason. When the Join
Reject is sent in response to a Join Request it shall include the acceptable subnetwork parameters
(e.g., blocks 2 and 3 or block 20). Unless the joining station can correct the error(s), entry via
XNP is not possible. The Parameter Update Identifier field is incremented when a dynamic
station has been rejected that has completed the Join process (i.e., the number of stations in
subnetwork has changed). When a Join Reject is sent which has modified the Parameter Update
Identifier a complete set of network parameters shall be included, and the Block 2 or Block 20
Individual/Network Capability shall be set to indicate that this Join Reject includes all
subnetwork parameters (Individual and Subnetwork bits are set in the Individual/Network

384
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

Capability field). When a station receives a Join Reject message, the topology update function
should be notified of the station that has been removed from the network.

TABLE E-X. Join reject message.

OCTET FIELD IDENTIFICATION VALUE

1 Message Number: Identifies specific message content. 22
2 Message Length: Indicates the length of the Join 8
Reject Message block in octets.
3 Parameter Update Identifier: A number to uniquely 0 = Unknown
identify the latest parameter values distributed for use 1 - 255 in increments of 1
in the network.
4-7 Station Identifier: Identifies the station trying to join Unique identifier for the
the network. station
8 Link Address or marker subfield: Data link address 0 = Unknown
(see 5.3.4.2.2) that is being rejected or the size of the 4 - 95 = Data Link address
Data Link address in the Link Address Extension 32-bit marker subfield
Field. When the 32 or 48 bit marker is used the Link 48-bit marker subfield
Address Extension Block (Block 16) must be
appended to the end of this message.

TABLE E-XI. Blocks Returned in the Reject in OPS mode

Reason for Blocks returned Optional

Reject blocks
Dynamic station 519, 1110 | 12, 164, 17, 20, 255 8,13,15
left subnetwork --
Parameter Update
Identifier change
Reject of Joining 255 13,15
station --
Parameter Update
Identifier not
changed

385
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

TABLE E-XII. Blocks Returned in the Join Reject in Explicit mode

Reason for Blocks returned Optional

Rejection blocks
Dynamic station 2, 3, 4, 519, 616, 717,97,108,1110 | 12 ,12, 164, 17, 185, 21, 255 8,13,15,1415,
left subnetwork -- 196 & 15
Parameter Update
Identifier change
Reject of Joining 214, 314, 255 13,15
station --
Parameter Update
Identifier not
changed

E.4.2.4 Hello message.

The Hello message (TABLE E-XIII) may be sent by a station after the subnetwork operating
parameters are known (e.g., known prior) to notify the other stations of its presence in the
subnetwork. The message contains the Data Link address of the station entering the subnetwork.
Address tables within receiving stations are updated, if necessary, with the new address
information. In a multi-hop subnetwork the Intranet header’s final destination address shall be
set to the Global Group multicast address. The data link destination address shall be the One-
hop multicast. When a station receives a Hello message, it should update its topology tables.

TABLE E-XIII. Hello message.

OCTET FIELD IDENTIFICATION VALUE

1 Message Number: Identifies specific message content. 23
2 Message Length: Indicates the length of the Hello 7
Message block in octets.
3-6 Station Identifier: Identifies the station trying to join Unique identifier for the
the network. station.
7 Link Address or marker subfield: The Data Link 4 - 95 = Data Link address
address (see 5.3.4.2.2) of the station that has joined the 32-bit marker subfield
network, or the size of the Data Link address in the 48-bit marker subfield
Link Address Extension Field. When the 32 or 48 bit
marker is used the Link Address Extension Block
(Block 16) must appended to the end of this message.

386
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

E.4.2.5 Goodbye message.

The Goodbye message (TABLE E-XIV) is sent by a station to notify the NCS and other stations
that it is leaving the network. In a multi-hop subnetwork the Intranet header’s final destination
address shall be set to the Global Group multicast address. The data link destination address
shall be set to the One-hop multicast address. The Data Link address used by a leaving dynamic
station is made available for reuse by another station.

Before a station sends a Goodbye message, it should disconnect all Type 2 connections and send
a URNR to indicate it will no longer receive frames. When a station receives a Goodbye
message, the topology update function should be notified of the station that has been removed
from the network

TABLE E-XIV. Goodbye message.

OCTET FIELD IDENTIFICATION VALUE

1 Message Number: Identifies specific message content. 24
2 Message Length: Indicates the length of the Goodbye 7
Message block in octets.
3-6 Station Identifier: Identifies the station leaving the Unique identifier for this
network. station.
7 Link Address or marker subfield: The Data Link 4 - 95 = Data Link address
address (see 5.3.4.2.2) of the station leaving the 32-bit marker subfield
network, or the size of the Data Link address in the 48-bit marker subfield
Link Address Extension Field. When the 32 or 48 bit
marker is used the Link Address Extension Block
(Block 16) must appended to the end of this message.

E.4.2.6 Parameter Update Request message.

A station that is out of operation for some period of time or experiences a system failure may be
unaware of changes to the network operating procedures/parameters or may have lost all record
of the operating parameters. Once the outage or failure is corrected, the station may send this
Parameter Update Request message (TABLE E-XV) to obtain new/changed parameters. If a
station receives a Status Notification message and the Parameter Update Identifier field in the
message does not match the locally stored Parameter Update Identifier and the Status
Notification message does not include the network parameters (block 2 or block 20 is included
and the Individual/Network Capability field is set to “Subnetwork values”), the station shall send
a Parameter Update Request message to the NCS. In a multi-hop subnetwork the Intranet
header’s final destination address shall be set to the special address 2 or the address of the NCS.
If the Intranet header’s final destination address is set to the actual address of the NCS, the

387
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

intranet relay path shall be included in the Intranet header. The data link destination address
shall be the assigned address of the NCS (see Status Notification Message: NCS Link Address
field) or the special address 2.

For all dynamic stations the Parameter Update Request message shall be sent periodically
(Parameter_Update_Refresh_Timer specified in Block 17) as a keep-alive. If the NCS
determines that a dynamic station has had three Parameter_Update_Refresh_Timer expirations
without the NCS receiving a Parameter Update Request, the station shall be deleted by the NCS
by sending a Join Reject message. If the NCS receives a Parameter Update Request the
Parameter_Update_Refresh_Timer should be restarted for that station. If the NCS receives a
Parameter Update Request and the Parameter Update Identifier is different than the current NCS
Parameter Identifier, it shall send out a Parameter Update Message including the entire current
subnetwork Parameters. If the NCS receives a Parameter Update Request from a dynamic
station that is not in its list of active stations, it shall respond with a Join Reject including the
Error Block (i.e., Reason code indicating “Timeout/Rejoin”).

TABLE E-XV. Parameter update request message.

OCTET FIELD IDENTIFICATION VALUE

1 Message Number: Identifies specific message content. 25
2 Message Length: Indicates the length of the Parameter 8
Update Request Message block in octets.
3 Parameter Update Identifier: A number to uniquely 0 = Request all subnetwork
identify the latest parameters this station is using. parameters.
1 – 255 in increments of 1
4-7 Station Identifier: Identifies this station. Unique identifier for the
station
8 Link Address or marker subfield: The Data Link 4 – 95 = Data Link address
address (see 5.3.4.2.2) of the station being updated, or 32-bit marker subfield
the size of the Data Link address in the Link Address 48-bit marker subfield
Extension Field. When the 32 or 48 bit marker is used
the Link Address Extension Block (Block 16) must
appended to the end of this message.

E.4.2.7 Parameter Update message.

The Parameter Update message (TABLE E-XVI) shall be sent by the NCS in response to the
Parameter Update Request message when the sending station Parameter Update Identifier is not
current or if the sending station appends a block with the Parameter Update request. If the
Parameter Update Identifier in the Parameter Update Request Message does not match the
current Parameter Update Identifier, the Parameter Update Message shall include the same basic

388
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

blocks as the Join Accept; however, some blocks may have to be repeated to provide a complete
set of subnetwork parameters (i.e., TABLE E-XVII and TABLE E-XVIII ). If the Parameter
Update Request Message does have the current Parameter Update Identifier only the blocks
attached (e.g., Block 14 requesting an address resolution) shall be included to the Parameter
Update Message. If the Parameter Update Request Message which contains no Blocks is
received from a dynamic station and it does have the current Parameter Update Identifier, a
response is not transmitted. Also the Parameter Update message should be reliably delivered via
unicast addressing. If multiple stations are requesting a Parameter Update, then a single message
may be addressed to multiple stations. It may be advantageous to cache the Parameter Update
Request messages for a period of time (e.g., ½ Parameter_Update_Refresh_Timer or until 16
messages are received) to decrease the number of transmissions.

TABLE E-XVI. Parameter update message.

OCTET FIELD IDENTIFICATION VALUE

1 Message Number: Identifies specific message content. 26
2 Message Length: Indicates the length of the Parameter 8
Update Message block in octets.
3 Parameter Update Identifier: A number to uniquely 1 – 255 in increments of 1
identify the latest parameter values distributed for use
in the network.
4-7 Station Identifier: Identifies a station. Unique identifier for the
station
8 Link Addressor marker subfield: Data link address 4 - 95 = Data Link address
(see 5.3.4.2.2) assigned to identify station being 32-bit marker subfield
updated. When the 32 or 48 bit marker subfield is 48-bit marker subfield
used the Link Address Extension Block (Block 16)
must be appended to the end of this Block. (see
5.3.4.2.2 Address fields)

389
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

TABLE E-XVII Blocks sent in the Parameter Update message in OPS mode

Reason for Blocks sent Optional

sending Message blocks
Response to 1411, 164 ,1911, 255 15
Parameter Update
Request –
Parameter Update
Identifier current
Response to 519, 1110 , 164, 17, 20, 255 8,15
Parameter Update
Request –
Parameter Update
Identifier different

TABLE E-XVIII Blocks sent in the Parameter Update message in Explicit mode

Reason for Blocks sent Optional

sending blocks
Parameter
Update Message
Response to 141, 164,191&6, 255 15
Parameter Update
Request –
Parameter Update
Identifier current
Response to 2, 3, 4, 519, 616 ,717 97,108,1110 ,12, 141, 164, 17, 185, 21, 8,15
Parameter Update 191, 255
Request –
Parameter Update
Identifier not
current

E.4.2.8 Status Notification message.

The Status Notification message (TABLE E-XIX) is sent by the NCS on a one time basis (i.e.,
when the Status_Notification_After_Change_Timer expires) and/or periodically (Block17:
Status_Notification_Refresh_Timer). It provides all stations with the identification of the latest

390
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

subnetwork parameters via the Parameter Update Identifier and identifies the active NCS. In a
multi-hop subnetwork the Intranet header’s final destination address shall be set to the Global
Group multicast address. The data link destination address shall be the One-hop multicast. The
NCS shall start the Status_Notification_After_Change_Timer after every event that changes the
current Parameter Update Identifier (e.g., Join Accept, Join Reject), and after this timer expires it
shall send out a Status Notification message indicating the Parameter Update Identifier. The
Data Link destination address shall be set to the One-hop multicast address. If a receiving
station is using a different set of parameter values (different Parameter Update Identifier) that
station shall notify the NCS via the Parameter Update Request message to request the latest
update

The Status Notification message is also used to determine if the NCS is available. If a NCS is
not available in network and the NCS is automatically elected, a new NCS is elected. If
automatic NCS election option is specified in (Block 17: Status_Notification_Refresh_Timer)
and a station fails to receive a Status Notification message for three Status Notification Refresh
Timer period expirations, the station, if capable (e.g., mission dependent), shall declare itself the
active NCS and transmit a Status Notification message. When the NCS transmits the Status
Notification Message for the first time it should include all Blocks necessary to specify the
subnetwork parameters (i.e., TABLE E-XX and TABLE E-XXI ). If a station receives a Status
Notification message, the Status_Notification_Refresh_Timer should be restarted. If more than
one station reports it is the active NCS, the station with the lowest value in the NCS Link
Address field becomes the active NCS (i.e., if an NCS receives a Status Notification Message
with a lower link address in the NCS Link Address field it stops sending out the Status
Notification Messages).

391
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

TABLE E-XIX. Status notification message.

OCTET FIELD IDENTIFICATION VALUE

1 Message Number: Identifies specific message content. 28
2 Message Length: Indicates the length of the Status 5
Notification Message block in octets.
3 Parameter Update Identifier: A number to uniquely 1 – 255 in increments of 1
identify the latest parameter values distributed for use
in the subnetwork.
4 NCS Link Address or marker subfield: Data link
address (see 5.3.4.2.2) of the station performing NCS 4 - 95 = Data Link address
duties. When the 32 or 48 bit marker is used the Link 32-bit marker subfield
Address Extension Block (Block 16) must be 48-bit marker subfield
appended to the end of this Block.
5 NCS Network Services Supported: The subnetwork Bit Map:
layer services supported by the NCS. 0 = IPv4
1 = IPv6
2 = N-Layer Pass-Through
3 = VMF URN/UNIT Name
address resolution
4 = OPS mode
5 = IPv6 address
assignment
6 = IPv4 address
assignment

TABLE E-XX Blocks sent in the Status notification message in OPS mode

Reason for Blocks sent Optional

sending message blocks
Status_Notificatio 164 ,255 15
n_Refresh_Timer
Received 519, 1110 , 164, 17, 20, 255 8,15
Goodbye --
Parameter Update
Identifier change
NCS sends Status 519, 1110 , 164, 17, 20, 255 8,15
notification for
the first time

392
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

TABLE E-XXI Blocks sent in the Status notification message in Explicit mode

Reason for Blocks sent Optional

sending Status blocks
notification
message
Status_Notificatio 164 ,255 15
n_Refresh_Timer
Received 2, 3, 4, 519, 616, 717, 97,108,1110 ,12, 141, 164, 17, 185, 196, 8,15
Goodbye -- 21, 255
Parameter Update
Identifier change
NCS sends Status 2, 3, 4, 519, 616, 717, 97,108,1110 ,12, 141, 164, 17, 185, 196, 8,15
notification for 21, 255
the first time

E.4.2.9 NCS Handover Request.

The NCS Handover Request message (TABLE E-XXII) is sent either by the NCS to the station
that the present NCS believes is a better candidate, or to the NCS from a station that is
requesting NCS capabilities because of better capabilities. This message is not used for the NCS
manual selection process.

TABLE E-XXII. NCS Handover Request message.

OCTET FIELD IDENTIFICATION VALUE

1 Message Number: Identifies specific message content. 29
2 Message Length: Indicates the length of the NCS 10
Handover Request Message in octets.
3-6 Station Identifier of present NCS. Identifies the Unique identifier for the
station presently acting as the active NCS. present NCS.
0 = Unknown
7-10 Station Identifier of proposed NCS. Identifies the Unique identifier for the
station being requested to assume NCS authority or station.
requesting NCS authority

393
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

E.4.2.10 NCS Handover Accept/Reject.

The NCS Handover Accept/Reject message (TABLE E-XXIII) is sent by the station addressed in
the NCS Handover Request message to indicate whether the station accepts the proposed change
or rejects the proposed change. The operator may make this decision. If the handover request is
accepted, the new NCS shall transmit the Status Notification Message. When the NCS transmits
the Status Notification Message for the first time it should include all Blocks necessary to
specify the subnetwork parameters (i.e., TABLE E-XX and TABLE E-XXI ). If the handover
request is rejected, the current NCS will continue to transmit the Status Notification Message as
previously scheduled with the Parameter Update Identifier increment as before.

TABLE E-XXIII. NCS Accept/Reject message.

OCTET FIELD IDENTIFICATION VALUE

1 Message Number: Identifies specific message content. 30
2 Message Length: Indicates the length of the NCS 3
Accept/Reject message in octets.
3 Accept/Reject 0 = Accept the request
1 = Reject the request

E.4.3 XNP data block formats.

One or more additional XNP Data Blocks may appear before the Terminator Block in each XNP
message to either provide specific subnetwork operating parameters or to request specific
parameters. The additional XNP Data Blocks are described in the following paragraphs and are
depicted in TABLE E-XXIV through TABLE E-XLII.

E.4.3.1 Block 2, Optional Services.

This block (TABLE E-XXIV) is used to define capabilities of a joining station, or the
capabilities in use in the subnetwork when sent by the NCS. When the subnetwork is in Explicit
mode, block 2 shall be sent in the Join Request message to identify capabilities of the joining
station, unless the joining station has all possible capabilities listed. When the subnetwork is in
Explicit mode, block 2 shall be included with the Join Accept message. When the Parameter
Update Identifier has changed and the subnetwork is in Explicit mode, block 2 shall be included
with the next Join Accept, Join Reject or Status notification message transmitted by the NCS,
and it shall include all subnetwork parameters. When all subnetwork parameters are included
with block 2, the Individual/Network Capability shall be set to indicate that this XNP message
includes all subnetwork parameters (Subnetwork bit is set in the Individual/Network Capability
field). When a Parameter Update Request message is received by the NCS and the Parameter
Update Identifier does not match the NCS’s current parameter identifier and the subnetwork is in

394
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

Explicit mode, block 2 shall be included in the Parameter Update message. When the NCS
changes or/and the NCS sends the Status Notification message for the first time and the
subnetwork is in Explicit mode, block 2 shall be included.

TABLE E-XXIV. Optional Services.

OCTET FIELD IDENTIFICATION VALUE

1 Block Number: Identifies specific data block. 2
2 Length: Indicates the length of the Optional Services 11
block in octets.
3 Individual/Network Capability: Indicates whether the Bit Map
parameter values provided in this block are those of an 0 = Individual station
individual station or/and the specific values being used 1 = Subnetwork values
in the subnetwork.
4 Station Class: The types of data link services 0 = Class A
available (See 5.3.3.5). 1 = Class B
2 = Class C
3 = Class D
5 NAD Methods: Identifies either the NAD methods Bit Map:
available by a station or the specific NAD method 0 = R-NAD
being used in a subnetwork. Multiple bits may be set 1 = H-NAD
when defining the NAD methods available by a 2 = P-NAD
station. (APPENDIX C) 3 = DAP-NAD
4 = RE-NAD
5= DAV-NAD
6 Network Services Supported: The subnetwork layer Bit Map:
services supported. In the Bit Map, bits 0-3 should be 0 = IPv4
set to services supported by both the joining stations 1 = IPv6
and the NCS. Bits greater than 2 should only be set by 2 = N-Layer Pass-Through
the NCS. 3 = NCS supports VMF
URN/UNIT Name address
resolution
4=NCS supports OPS mode
5= NCS supports IPv6
address assignment
6 = NCS supports IPv4
address assignment

395
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

TABLE E-XXIV. Optional Services. - Continued

OCTET FIELD IDENTIFICATION VALUE

7 Addressing support: the size and types of addresses Bit Map:
supported (5.3.4.2.2). 0 = Multicast supported
1 = 1 octet
4 = 4 octet
6 = 6 octet
8 Concatenation Capability: Indicates the types of Bit Map:
concatenation supported by the subnetwork or the 0 = No concatenation
reporting station.(5.3.9.2) allowed
1 = Physical layer
2 = Data link layer
9 FEC/TDC/Scrambling Mode: Bit map which Bit Map:
identifies the FEC, TDC and Scrambling capabilities 0 = Half-rate Golay FEC
(5.2.1.4). 1 = TDC
2 = PL Data Scrambling
3 = V.36 Scrambling
10-11 Max. UI, DIA and I Info. Octets: Indicates the largest 708 – 3345 octets
information field size that can be handled by the 65535 = requested
reporting station or that is allowed on the subnetwork.
(5.3.4.2.4)

OCTET FIELD IDENTIFICATION VALUE

31 Number Of Stations (NS): Indicates the number of 0 = Unknown
stations participating on the subnetwork. Used in 1 – 255
NAD calculations (C.4.4) (Note: Only the NCS sets
this value. All non-NCS stations set this value to 0).

E.4.3.3 Block 4, Type 3 parameters.

These parameters (TABLE E- XXVI) are required for data link Type 3 operations. When the
subnetwork is in Explicit mode, block 4 shall be included with the Join Accept message. When
the Parameter Update Identifier has changed and the subnetwork is in Explicit mode, block 4
shall be included with the next Join Reject or Status notification message transmitted by the
NCS. When a Parameter Update Request message is received by the NCS and the Parameter
Update Identifier does not match the NCS’s current parameter identifier and the subnetwork is in
Explicit mode, block 4 shall be included in the Parameter Update message. When the NCS
changes or/and the NCS sends the Status Notification message for the first time and the
subnetwork is in Explicit mode, block 4 shall be included.

TABLE E- XXVI. Type 3 parameters.

OCTET FIELD IDENTIFICATION VALUE

1 Block Number: Identifies specific data block. 4
2 Length: Indicates the length of the Type 3 Parameters 5
block in octets.
3 Type 3 Maximum number of Retransmissions (N4): 0 to 5
The maximum number of times to retransmit an
unacknowledged DL frame.(5.3.8.1.4)
4-5 DTE Acknowledgment Time (DTEACK): Network 0 – 65.534 sec in 1 msec
Access Control parameter defined in (C.3.2.7). increments
65535 = Unknown

E.4.3.4 Block 5, Number of NAD Priorities.

E.4.3.8 Block 9, Type 2 parameters.

409
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

Services Supported field indicates it will support this service. Block 2 can be used to assign a
Group Multicast address to a specific station.

When Block 2 is included in the Parameter Update or Join Accept message and the Bits in
Subnet Mask field is set to Multicast address, the station is being assigned a Multicast address.
The Multicast address may be a Data Link Group Multicast address only, an IP address and Data
Link Group Multicast address pair, or a complete address set (e.g., URN, IP address and Data
Link Group Multicast address).

TABLE E-XXXVI. Address designation parameters.

OCTET FIELD IDENTIFICATION VALUE

1 Block Number: Identifies specific data block. 14
2 Length: Indicates the length of the Address Variable length:12 + size of Unit
Designation Parameters block in octets. Name field
2 = request all known addresses
3-6 Station Identifier: Identifies the station. 0 = Unknown or not applicable
1 – 16777215 = Unique identifier
for the station
7 Link Address: Identifies the Data Link address 0 = No link address
(see 5.3.4.2.2) of the station. When the 32 or 48 1 - 3 = Not used (Special)
bit marker is used the Link Address Extension 4 - 95 = Data Link address
Block (Block 16) must appended to the end of 125 = 48-bit marker subfield
this Block. 126 = 32-bit marker subfield
8-11 IPv4 Address: The IPv4 address for the 0 = Unknown or not
identified station or a marker that an IPv6 address Applicable
being appended. When the FFFFFFFF bit marker FFFFFFFF = IPv6 bit marker.
is used the IPv4, IPv6 Top Level/Site level
address (Block 19) must be appended at the end
of Block 16 which is the link address.
12 Bits in Subnet Mask 0 – 32 IPv4
0 - 128 IPv6
129-- Multicast address
130-- Not specified
131-255 invalid
(i.e., 24 = 255.255.255.0)
13- Unit Name (see MIL-STD-2045-47001) 7 bit ASCII stored one character
Length per octet with the most
field significant bit set to zero (0)

410
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

E.4.3.14 Block 15, Digital Signature.

Block 15 (TABLE E-XXXVII) provides for Digital Signature to be attached as the last block
before the Terminator block. The digital signature covers the XNP message header and all XNP
bocks with exception of the last two blocks which are the Digital Signature and the terminator
block. Block 15 is optional with any message. The Digital Signature should be created via the
following steps:

1. The sender creates a XNP message.

2. The sending software generates a hash code (MD5 or SHA1) of the XNP message
without the Digital Signature block or the Terminator Block.

3. The sending software generates a signature by encrypting the hash from step 2 with the
Crypto Algorithm using the sender's private key.

4. The binary signature is inserted in Digital Signature field of this message.

5. The Digital Signature and Terminator block are appended to the XNP message

TABLE E-XXXVII. Digital Signature

OCTET FIELD IDENTIFICATION VALUE

1 Block Number: Identifies specific data block. 15
2 Length: Indicates the length of the Address Variable length: 13+ size of
Designation Parameters block in octets. Digital Signature field
3 Hash Algorithm used to produce the hash. 0 = MD5 [RFC 1321]
1 = SHA1 [RFC 3174]
4 Crypto Algorithm Identification of the crypto 0 = Not encrypted
algorithm used to encrypt the hash to produce the 1 = RSA [RFC 2313]
digital signature. 3 - 255 User defined
5-13 Key ID of signer’s public key. 8 octet binary field
14- Digital Signature Authentication of the sender of the
Length message.
field

E.4.3.15 Block 16, Link Address Extension.

E.4.3.18 Block 19, IPv6 top level/site level address.

Block 19, (TABLE E-XLI) the IPv6 Top Level/Site level address provides the first 10 octets of
the IPv6 address. The complete IPv6 address is formed by appending the 6 octet link address to
the end of the Top Level/Site level portion in this Block 16. Therefore, the order of the blocks
shall be block 16 and then block 19. Block 14, block 16 and block 19 should be included in the
Join Request when a static station has a preloaded IPv6 and 6 octet link address to register.
When the subnetwork supports IPv6 and block 14 is included in the Join Request and the IPv4
Address field of block 14 is set to FFFFFFFF, the Join Accept shall include block 19. When the
subnetwork supports IPv6 and block 14 is included in the Update Request and the IPv4 Address
field of block 14 is set to FFFFFFFF, the Parameter Update shall include block 19.

TABLE E-XLI. IPv6 Top level/site level address

OCTET FIELD IDENTIFICATION VALUE

1 Block Number: Identifies specific message content. 19
2 Length: Indicates the length of message in octets. 13
3-13 IPv6 address: The most significant octets of the IPv6 0 = Illegal
address. 1 – 280

E.4.3.19 Block 20, Predefined OPS.

This block 20 (TABLE E-XLII) is used by a joining station to notify the NCS of an OPS
number(s) supported and request an OPS number assignment. Block 20 specifies the OPS
number to use when sent by the NCS. When the joining station has been assigned OPS
number(s) or the joining station has determined that the subnetwork is in OPS mode, Block 20
shall be included with the Join Request message. When the subnetwork is in OPS mode, block
20 shall be included in the Join Accept message. When the Parameter Update Identifier has

414
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

changed and the subnetwork is in OPS mode, block 20 shall be included with the next Join
Accept, Join Reject or Status notification message transmitted by the NCS, and it shall include
all subnetwork parameters. When all subnetwork parameters are included with block 20, the
Individual/Network Capability shall be set to indicate that this XNP message includes all
subnetwork parameters (Subnetwork bit is set in the Individual/Network Capability field). When
the NCS changes or/and the NCS sends the Status Notification message for the first time and the
subnetwork is in OPS mode, block 20 shall be included. Predefined OPS shall be set as
identified in TABLE E-XLII.

415
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

TABLE E-XLII. Predefined OPS.

OCTET FIELD IDENTIFICATION VALUE

1 Block Number: Identifies specific message content. 20
2 Length: Indicates the length of message in octets. Variable length:5+ size of
Predefined OPS number
field

A station which has not

been assigned a OPS value
sets the Length field = 2
3 Version of the table/Page# 0-255
The number represents a table version and page
number. The format is operational determined.
However the binary value stored in the stations must
match the value stored in the NCS.
4 Number Of Stations (NS): Indicates the number of 0 = Unknown
stations participating on the subnetwork. Used in 1 – 255
NAD calculations (C.4.4) (Note: Only the NCS sets
this value. All non-NCS stations set this value to 0).

5 Individual/Network Capability: Indicates whether the Bit Map

parameter values provided in this block are those of an 0 = Individual station
individual station or/and the specific values being used 1 = Subnetwork values
in the subnetwork.
6- Predefined OPS number: A bit map showing which Bit Map:
Length OPS numbers the joining station supports or which 0 = OPS number 0
field OPS number is being used by the subnetwork when set 1 = OPS number 1
by the NCS. (see 5.5.2.1 Table map/TABLE XIV
Standard Network Settings)

The NCS sets only one bit in the bit map to indicate
the OPS number being used in the subnetwork.

E.4.3.20 Block 21, S/R basic.

This block 21 (TABLE E-XLIII) is used by the NCS to notify the stations of the
Segmentation/Reassembly (S/R) Basic parameters as described in MIL-STD-2045-47001. When
the subnetwork is in Explicit mode, block 21 shall be included in the Join Accept message.
When the Parameter Update Identifier has changed and the subnetwork is in Explicit mode block
21 shall be included in the next Join Reject, Parameter Update Request, and Status notification

416
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

message that is transmitted. When the NCS changes or/and the NCS sends the Status
Notification message for the first time and the subnetwork is in Explicit mode, block 21 shall be
included.

TABLE E-XLIII. S/R basic

OCTET FIELD IDENTIFICATION VALUE

1 Block Number: Identifies specific message content. 21
2 Length: Indicates the length of message in octets. 5
3 Segment Credit Limit (SCL): The maximum number 1 – 228
of Data Segments that the Originator may have
outstanding (i.e., sent and unacknowledged) for a
single Application PDU simultaneously.
4 Segment Retry Count Limit (SRCL): The number of 0 -5
times that an Originator shall retransmit a Data
Segment based on a received Partial Acknowledgment
indicating a missing segment before aborting the
transfer of the Application PDU
5 Request For Acknowledgement Retry Limit (RFARL): 1-10
The number of consecutive times that an Originator
shall re-transmit a request for acknowledgment
without receiving an acknowledgment from the
Destination before aborting the transfer of the
Application PDU

E.5 XNP message exchange.

XNP messages shall be exchanged using a UI command frame as shown in FIGURE E-4.

FLAG Source Destination Control Intranet XNP FCS FLAG

Address Address Field Header Information

FIGURE E-4. UI frame containing XNP message.

E.5.1 Data Link addressing.

Data Link address 1 is a special address for a station to use while joining the subnetwork if it has
not been pre-assigned a Data Link address. If a station has not been assigned a Data Link
address, it shall use this special Data Link address for subnetwork entry until an individual Data
Link address has been assigned. Since multiple stations may be attempting to join the

417
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

subnetwork at the same time, the Station Identifier field in each XNP message is used to
uniquely identify the station.

Special address 2 is reserved for the NCS. Joining stations, forwarders and relayers may use the
Special address 2 to address the NCS if they do not know the actual address. The receiver shall
be able to identify the response via the unique Station identifier in the Join Request/Join
Response. The Station Identifier field in the XNP messages is used to uniquely identify stations
during the joining process. In a multi-hop subnetwork the Intranet header’s final destination
address, which is indicated by setting the Destination bit to “1” corresponding to the
Destination/Relay Address field of the final destination, shall be set to the special address 2 or
the address of the NCS. The address of the NCS may be learned by receiving a Status
Notification message which has the address of the NCS. If the Intranet header’s final destination
address is set to the actual address of the NCS, the path shall be included in the Intranet header.
When special address 2 is used as the Intranet header’s final destination address, the One-hop
multicast address shall be used as the link layer address. If all stations are guaranteed to be
within one-hop of each other, the special address 2 should be used as the data link address. If a
station is unsure of the network configuration it should use special address 2 as the Intranet
header’s final destination address and the One-hop multicast as the Data Link destination
address.

E.5.2 Poll/Final bit.

Use of UI poll/final bits is allowed but not recommended for use with XNP Join Request, Join
Accept and Join Reject messages because subnetwork timing parameters for Type 3 final-bit
responses are either unknown or subject to change during the subnetwork joining process.

E.5.3 Network Access.

MIL-STD-188-220 allows a subnetwork to choose among the subnetwork access delay methods
defined in APPENDIX C. Each station that operates on the subnetwork shall use the same
method. If the station does not know this information before joining the subnetwork, the Join
Request message allows a station to learn the subnetwork access method. In the case that the
subnetwork access method is unknown, a random method (R-NAD or RE-NAD) shall be used
for the Join Request method. When R-NAD is used, the default number of stations shall be 7
unless another number is known.

E.6 Network joining procedures.

Joining procedures consist of providing operating parameters to the joining station by the active
NCS.

E.6.1 Basic joining

In general, the basic subnetwork joining sequence is depicted in FIGURE E-5 and the following
text describes the steps:

1. The joining station sends a Join Request message that contains its MIL-STD-188-220
capabilities and unique identifier. The NCS compares the joiner's capabilities with

418
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

current subnetwork operating parameters. If an error is found which precludes

acceptance into the subnetwork, the NCS returns a Join Reject message to the joiner
included with the Join Reject are the subnetwork parameters (e.g., Blocks 2, and 3). If
the joiner can correct the errors, a new Join Request message with corrected parameters
can be sent. If the errors are not correctable, automatic joining using XNP is not
possible. (Note: A subnetwork controller may send a Join Reject to remove any station
from the subnetwork at any time.)

2. If there are no errors in the parameters contained in the Join Request message, a Join
Accept message is sent by the NCS. The NCS may have to update the data fields filled in
by the joiner since it is possible that the joining station has capabilities above and beyond
those being used within the subnetwork. The Join Accept message contains the address
assigned to the joining station, all the Network parameters (e.g., Blocks 2, 3, 4, 12, 17,
and 21). The blocks sent in the Join Accept are the subnetwork parameters. The Join
Accept is transmitted to all stations (Global Group multicast). If the Parameter Update
Identifier has changed all stations will update their subnetwork parameters. The joined
station should notify the topology update function of the changes, if topology protocol is
being used. Optionally the Block 8 may be added to delay the joining station from
transmitting. This delay allows all stations to adapt to the new timing parameters when a
deterministic NAD is being used. If Block 8 is not included there may be a few
collisions due to transit delays of the Join Accept messages; however, this will be a
temporary condition. It should be a operational decision whether to have a few collisions
rather than holding off the joining station by including Block 8 in the Join Accept.

3. When the NCS has sent out a Join Accept it will start a timer
(Status_Notification_After_Change_Timer) which is started for every event that changes
the Parameter Update Identifier (e.g., Join Accept, Join Reject), and after this timer
expires it will send out a Status Notification message indicating the Parameter Update
Identifier. If a station is out of date that station will send a Parameter Update request.
The Status_Notification_After_Change_Timer is restarted after every Join Accept or Join
Reject is sent out that modifies the Parameter Update Identifier which prevents the
flooding of the subnetwork with Status Notification messages when many stations join or
leave in a short period of time.

419
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

Joining NCS
Other
Station Link address
Stations
(10)

#1 Join Request (sr

c = 1,dst = 2])

): B13, B2, B3
= Global Group multicast
Join Reject (src=10,dst
ast):
st = Global Group multic Legend:
#2 Join Accept (src=10,d B2,B3,B4,B12,B17,B21

=10,dst = Global Group

multicast)
} Status_
Notification _
B13 = Block 13
B2 = Block 2
#3 Status Notification (src After_Change_ B3 = Block 3
Timer B4 = Block 4
B12= Block 12
B17 = Block 17
B21 = Block 21

FIGURE E-5. Basic joining sequence diagram.

E.6.2 Basic join using unicast addressing.

In order to decrease overhead of multicasting the Join Request message, a station may wait to
learn the address of the NCS. The Join Request message will be addressed to the NCS using the
Data Link address of the NCS. The only difference between the basic join and the basic join
using unicast address is a joining station has the address of the NCS when it sends the Join
Request. It also assumes there is a known unicast route to the NCS. For example as in FIGURE
E-6, a joining station waits for a XNP message which will have the address of the NCS and uses
that address to send the Join Request. Otherwise the sequences of events are the same as the
basic join. If the joining station is unable to contact the subnetwork controller because of
distance or topology, there will be no response to the Join Request message. When this occurs
the Join Request should be retried with the Special address 2.

420
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

NCS
Joining Other
Link Address
Station Stations
10

lticast)
,dst = Global Group mu
#1 Network Status (src=10

#2 Join Request (sr

c = 1,dst = 10)

st)
st = Global Group multica
#3 Join Accept (src=10,d
B2,B3,B4,B12,B17,B21

multicast)
} Status_
Notification _
=10,dst = Global Group After_Change_
#4 Status Notification (src Timer

FIGURE E-6. Basic joining using unicast addressing sequence diagram

E.6.3 Join and election of a NCS.

When the NCS does not respond, the joining station will retransmit the Join Request message.
When the Status_Notification_Refresh_Timer expires three times and the joining station does
not receive a XNP Status Notification message, the joining station, if capable, may become the
NCS. The follow sequence in FIGURE E-7 provides an example NCS election:

1. The station is powered on and initiates a Join Request.

2. The Join Request Timer expires and the Join Request is retransmitted. (The Join Request
may be sent many times before the Status_Notification_Refresh_Timer expires.)

3. The Join Request Timer expires and the Join Request is retransmitted.

4. The Status_Notification_Refresh_Timer expires 3 times and the station declares itself to

be the NCS and assigns itself a Link Address (e.g., 4). The NCS (joining station)
transmits a Status Notification message indicating that station 4 is the NCS.

421
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

Joining Other
Station NCS
Stations
#1 Join Request (sr
c = 1,dst = 2)

3*Status {#2 Join Request (src = 1,dst = 2)

Notification
Refresh {#3 Join Request (sr
c = 1,dst = 2)
Timer
{ #4 Status Notificatio
n (src = 4,dst = Glob
al Group multicast)

FIGURE E-7. Join and election of a NCS

E.6.4 Basic Leaving.

In general, the basic leave procedure depicted in FIGURE E-8 as follows:

1. When a station leaves a subnetwork, it should send a Goodbye message. Members of the
subnetwork should notify their topology function of the station that has left the
subnetwork.

2. If the station is a static station the procedure is done because the parameters are not
changed when a static station leaves the subnetwork. If the station is a dynamic station
the NCS will send out a Reject message with the updated parameters, and starts the
Status_Notification_After_Change_Timer.

3. After the Status_Notification_After_Change_Timer expires the Status Notification

message will be transmitted to verify that all stations received the current parameters.

422
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

leaving
Station NCS
Other
Link address Link address
Stations
(12) (10)

#1 Goodbye (src =
12,dst = Global Gr
oup multicast)
st = Global Gro up multicast)
#2 Reject Join (src=10,d

#3 Status Notification (src

B2,B3,B4,B12,B17,B21
=10,dst = Global Group
multicast)
} Status_
Notification _
After_Change_
Timer

FIGURE E-8. Basic Leaving sequence diagram

E.6.5 Leaving without sending Goodbye.

Many times a station may leave the subnetwork without sending a goodbye (traveled out of
range or loss of power). In this condition the NCS will detect this condition and notify the other
stations by sending a Join Reject message for a dynamic station that has left the subnetwork. In
general, the Leaving without sending Goodbye procedure depicted in FIGURE E-9 is as follows:

1. The NCS maintains a Parameter_Update_Refresh_Timer, and if the NCS does not

receive a Parameter Update Request from a dynamic station within three
Parameter_Update_Refresh_Timer expirations the station will be deleted from the
subnetwork by sending a Reject Message. Included in the Reject Message will be
network parameters to notify the stations of the Number of Station in the subnetwork.
Also since there has been a change in the network parameters the Status_Notification
_After_Change_Timer is started. Each station should notify the topology function of the
deleted station.

2. After the Status_Notification_After_Change_Timer expires the Network Status message

will be transmitted to verify that all stations received the current parameters.

423
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

leaving
NCS
Station
Link Address Other
Link address
(12) Stations
(10)
Parameter
{ Update Refresh Timer expires
Parameter
{ Update Refresh Timer expires
Parameter

{ Update Refresh Timer expires

#1 Join Reject (src

= 12,dst = Global Gr
Network_ oup multicast)
B2,B3,B4,B12,B1
Status_ 7,B21
After_Change_{ #3 Status Notificatio
Timer n (src=10,dst =
Global Group mult
icast)

FIGURE E-9. Basic Leaving without sending Goodbye sequence diagram

E.7 Example Messages

E.7.1 Join Request Message

a. Transmission Header (see Figure 9 Transmission header):

Selection Bits:
FEC 1 (Yes)
TDC 1 (Yes)
Scrambling 0 (No)
MIL-STD-188-220 Version 1 (MIL-STD-188-220 Version D)
Transmission Queue:
T-bits 0 (No Info)
Trans Queue Subfield 0 (Ignored)

b. Link Layer Header

Source Address:
C/R Bit 0 (Command)
Address 1 (Net Entry)
Destination Address:
Extension Bit 1 (Last one.)
Address 127 (One-hop multicast)
Control Field 3 (UI, ACK not required)

424
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

c. Intranet Header:
Version # 1 (Current Version)
Message Type 6 (XNP)
Header Length 9
Type of Service 48 (Priority, low delay)
Message Id. Number 1
Fragment Number 1 (not fragmented)
Total # of Fragments 1 (not fragmented)
Max Hop Count 5 (max # stations to the edge of the net)
Originator address 1 (Special address 1 for net entry address)
Destination/Relay status byte
ACK 0 (no acknowledgment requrested)
DES 1 (this is the final destination)
Relay Type 0 (source directed relay)
Rel 1 (station is expected to relay the packet)
Dist 1 (next hop relay [multicast relay])
Destination/Relay Address 1 2 (Special address 2 for the NCS)

d. XNP Message :
Version # 1 (Current Version)
Message Number 20 (Join Request Message)
Message Length 7 (Join Request Message Length)
Station Identifier 1234 (Number identifying the Joiner)
Link Address 0 (link address not specified – dynamic station)
Terminator Block 255

425
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

TABLE E-XLIV illustrates the construction of the XNP Join Request Message. Station
Identifier 1234 is used for illustration.

TABLE E-XLIV. XNP Join Request message.

Field Name Length Value Value Field Octet Octet Octet

(bits) (Dec) (Binary) Fragments Value Value Number
(Binary) (Hex)
MSB LSB MSB LSB MSB LSB
2n 20 2n 20 2n 20
XNP Message
Version Number 8 0 00000001 00000001 00000001 0x01 0
Join Request
Message
Message Number 8 20 00010100 00010100 00010100 0x14 1
Message Length 8 6 00000111 00000111 00000111 0x07 2
Station Identifier 32 1234 00000000 00000000 00000000 0x00 3
00000000 00000000 00000000 0x00 4
00000100 00000100 00000100 0x04 5
11010010 11010010 11010010 0xD2 6
Link Address or 8 0 00000000 000000000 00000000 0x00
marker subfield
Terminator block 8 255 11111111 11111111 11111111 0xFF 7

E.7.2 Join Accept message.

TABLE E-XLV, XNP Join Accept message. - Continued

Field Name Length Value Value Field Octet Octet Octet

(bits) (Dec) (Binary) Fragments Value Value Number
(Binary) (Hex)
Concatenation 8 4 00000100 00000100 00000100 0x04 16
Capability
(data link)
FEC/TDC/Scram 8 1 00000001 00000001 00000001 0x01 17
bling Mode
(Golay FEC)
Max. UI, DIA and 16 3345 00001101 00001101 00001101 0x0D 18
I Info. Octets 00010001 00010001 00010001 0x11 19
Block 3, Basic
NAD
Configuration
Parameters
Block Number 8 3 00000011 00000011 00000011 0x03 20
Block Length 8 31 00001111 00011011 00011011 0x1B 21
EPRE 16 256 00000001 00000001 00000001 0x01 22
(256 ms) 00000000 00000000 00000000 0x00 23
Phasing Time 16 32 00000000 00000000 00000000 0x00 24
(32 ms) 00100000 00100000 00100000 0x20 25
DCE_Tx-delay 16 8 11111111 11111111 11111111 0xFF 26
(unknown) 11111111 11111111 11111111 0xFF 27

DCE_Rx-delay 16 1 11111111 11111111 11111111 0xFF 28

(unknown) 11111111 11111111 11111111 0xFF 29

ELAG 16 256 00000001 00000001 00000001 0x01 30

(256 ms) 00000000 00000000 00000000 0x00 31
MAX 16 65535 11111111 11111111 11111111 0xFF 32
propagation 11111111 11111111 11111111 0xFF 33
delay (unknown)
DCE TTURN 16 65535 11111111 11111111 11111111 0xFF 34
(unknown) 11111111 11111111 11111111 0xFF 35

DCE RTURN 16 65535 11111111 11111111 11111111 0xFF 36

unknown 11111111 11111111 11111111 0xFF 37

TURN 16 64 00000000 00000000 00000000 0x00 38

(64 ms) 01000000 01000000 01000000 0x40 39

429
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

TABLE E-XLV, XNP Join Accept message. - Continued

Field Name Length Value Value Field Octet Octet Octet

(bits) (Dec) (Binary) Fragments Value Value Number
(Binary) (Hex)
Tolerance Time 16 64 00000000 00000000 00000000 0x00 40
(64 ms) 01000000 01000000 01000000 0x40 41
DTE Processing 16 32 00000000 00000000 00000000 0x00 42
Time (32 ms) 00100000 00100000 00100000 0x20 43
DTE turnaround 8 16 00010000 00010000 00010000 0x10 44
time (16 ms):
Net Busy 8 16 00000000 00000000 00000000 0x00 45
Sensing Time, B 00000010 00000010 00000010 0x02 46
(2 ms)
TEST Time To 16 0 00000000 00000000 00000000 0x00 47
Live ( 0) 00000000 00000000 00000000 0x00 48
Maximum 8 32 00000000 00000000 00000000 0x00 49
Transmit Time 00100000 00100000 00100000 0x20 50
(32 seconds)
Number Of 8 2 00000010 00000010 00000010 0x02 51
Stations (NS)
Block 4, Type 3
Parameters
Block Number 8 4 00000100 00000100 00000100 0x04 52
Length 8 5 00000101 00000101 00000101 0x05 53
Type 3 Max. 8 3 00000011 00000011 00000011 0x03 54
Retransmissions
(3)
DTE 16 64 00000000 00000000 00000000 0x00 55
Acknowledgment 01000000 01000000 01000000 0x40 56
Time (64 ms)
Block 11 NAD
ranking
Block Number 8 11 00001011 00001011 00001011 0x0B 57

Block Length 8 8 00000010 00000010 00000010 0x10 58

Station Rank 8 2 00000010 00000010 00000010 0x02 59
Station Number 8 3 00000011 00000011 00000011 0x03 60
Station Identifer 32 1234 00000000 00000000 00000000 0x00 61
00000000 00000000 00000000 0x00 62
00000100 00000100 00000100 0x04 63
11010010 11010010 11010010 0xD2 64

430
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

TABLE E-XLV, XNP Join Accept message. - Continued

Field Name Length Value Value Field Octet Octet Octet

(bits) (Dec) (Binary) Fragments Value Value Number
(Binary) (Hex)
Block 12 Intranet
parameters
Block number 8 12 00001100 00001100 00001100 0x0C 65
Block Length 8 15 00001111 00001111 00001111 0x0F 66
Min Update Per 8 16 00010000 00010000 00010000 0x10 67
Topology Update 8 0 00000000 00000000 00000000 0x00 68
Precedence
Maximum 8 0 00000000 00000000 00000000 0x00 69
number of
subnetwork hops
FixedACK Timer 16 32 00000000 00000000 00000000 0x00 70
00100000 00100000 00100000 0x20
Prop Ack Timer 16 32 00000000 00000000 00000000 0x00 71
00100000 00100000 00100000 0x20 72
Retransmit Count 8 2 00000010 00000010 00000010 0x02 73
Link Failure 8 7 00000111 00000111 00000111 0x07 74
Threshold
MTU with out 16 705 00000010 00000010 00000010 0x02 75
Frag 11000001 11000001 11000001 0xC1 76
MTU with Frag. 16 705 00000010 00000010 00000010 0x02 77
11000001 11000001 11000001 0xC1 78
Block 17, XNP
Parameters
Block Number 8 17 00010001 00010001 00010001 0x11 79
Block Length 8 5 00000101 00000101 00000101 0x05 80
Parameter 8 2 00000010 00000010 00000010 0x02 81
Update Refresh
Timer
Status 8 4 00000100 00000100 00000100 0x04 82
Notification
Refresh Timer
Join Response 8 16 00010000 00010000 00010000 0x10 83
Timer
Block 21 S/R
Basic
Message Number 8 21 00010101 00010101 00010101 0x15 84
Length 8 5 00000101 00000101 00000101 0x05 85

431
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

TABLE E-XLV, XNP Join Accept message. - Continued

Field Name Length Value Value Field Octet Octet Octet

(bits) (Dec) (Binary) Fragments Value Value Number
(Binary) (Hex)
Segment Credit 8 8 00001000 00001000 00001000 0x08 86
Limit
Segment Retry 8 2 00000010 00000010 00000010 0x02 87
Count Limit
RFARL 8 2 00000010 00000010 00000010 0x02 88
Terminator block 8 255 11111111 11111111 11111111 0xFF 89

Notes

1 Included when a station needs an IP address and/or an IP mask

2 Included when the station has a preloaded URN and/or IP address to register.

3 Included when the station knows its hardware parameters.

4 Included when 4 or 6 octet addressing is being used in the subnetwork

5 Included when the subnetwork is using Robust

6 Included when the subnetwork is using IPv6 and assigning IPv6 addresses

7 Included for a subnetwork that supports type 2

8 Included for a subnetwork that supports type 4

9 Included when the station has a preloaded IPv6 address to register.

10 Included for all stations in the subnetwork when the ranking has changed and P-NAD, DAP-
NAD or DAV-NAD is being used.

11 If the same block is included in the Parameter Update Request Message

12 Included when P-NAD, DAP-NAD, or DAV-NAD is being used in the subnetwork

13 Included to indicate the error condition that caused a rejoin.

14 Recommend parameters to use to retry a join.

15 Specifing the URN and/or IP address that has left the subnetwork

432
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX E

16 Included when H-NAD is being used in the subnetwork

17 Included when RE-NAD is being used in the subnetwork

18 Included to assign a multicast address to a station

19 Included to assign the number of NAD Priorities and/or NBDT is not included or not in
accordance with the Parameter Table.

433
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX F

GOLAY CODING ALGORITHM

F.1 General.

F.1.1 Scope.
This appendix contains amplifying information in support of MIL-STD-188-220.

F.1.2 Application.
This appendix is not a mandatory part of MIL-STD-188-220. The information contained herein
is intended for guidance only.

F.2 Applicable documents.

None.

F.3 Forward Error Correction.

The FEC method requires the receiver to detect and automatically correct errors in a received
block of information. The number of errors the receiver can detect and correct depends on the
coding method. The information bits (k) are separated into blocks that contain both information
bits and code bits. The length of the block, including the information and code bits, is (n). The
code is described as (n, k), where n is the length of the block and k is the number of information
bits in the block.

F.4 Golay code.

The Golay code is a linear, block, perfect, and cyclic (23,12) code capable of correcting any
combination of three or fewer errors in a block of 23 digits. The generator polynomial for this
code is

g(x) = x11 + x10 + x6 + x5 + x4 + x2 + 1

where g(x) is a factor of x23 + 1

F.4.1 Half-rate Golay code.

The half-rate Golay code (24,12) is formed by adding a fill bit to the Golay (23,12) code. The fill
bit is not checked on reception. The (24,12) code is preferable to the (23,12) because it has a
code rate of exactly one-half. This code rate simplifies system timing.

F.4.2 Golay code implementation.

The Golay code may be implemented in either hardware or software. The hardware
implementation uses shift-registers for encoding and decoding, as described in F.4.2.1 and
F.4.2.2, respectively. The software implementation uses a generator matrix and conversion
table, as described in F.4.2.3.

434
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX F

F.4.2.1 Hardware implementation.

Golay code encoding can be performed with an 11-stage feedback shift register with feedback
connections selected according to the coefficients of g(x). A shift register corresponding to the
coefficients of g(x) is shown in FIGURE F-1. The k information bits are located at the
beginning of the n symbol block code. With the gate open, the information bits are loaded into
the shift register stages and simultaneously into the output channel. At this time the shift register
contains the check symbols. With the gate closed, register contents are then shifted onto the
output channel. The last n - k symbols are the check symbols that form the whole codeword.

INPUT

OR OUTPUT

+ + + + + +

GATE

2 4 5 6 10 11
Encoder for g(x) = 1 + x + x + x + x + x +x

FIGURE F-1. Shift register encoding for the (23,12) Golay code.
F.4.2.2 Hardware decoding.
The Golay code is decoded using a number of techniques such as the error-trapping process
developed by T. Kasami. The Kasami error-trapping decoder for the Golay code is shown in
FIGURE F-2. It works as follows:

a. Gates 1, 3, and 5 are opened, and gates 2 and 4 are closed. The received codeword r(x)
is then shifted into both the 23-stage shift register and the syndrome register. At the same time,
the previously corrected codeword is shifted out to the user. The syndrome

S(x) = S0 + S1x + . . . + S10x10

is then formed and subjected to threshold tests.

435
INPUT

GATE
1 GATE
3

SYNDROMIC
SHIFT
REGISTER
OR OR

+
+
+
+
+
+
+

Q S0 S1 S2 S3 S4 S5 S6 S7 S8 S9 S10

436
Q = C0 C1 C2 THRESHOLD TESTS
OR
Z0 = 1 IFF (S0 + S1 + S2 + S3 + S4 + S5 + S6 + S7 + S8 + S9 + S10) <= 3
APPENDIX F

Q = C0 C1 C2 Z1 = 1 IFF (S0 + S1 + S2 + S3 + S4 + S5 + S6 + S7 + S8 + S9 + S10) <= 2

Z2 = 1 IFF (S0 + S1 + S2 + S3 + S4 + S5 + S6 + S7 + S8 + S9 + S10) <= 2
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

C0 C1 C2 C3

Z0 Z1 Z2

GATE
+

23-STAGE SHIFT REGISTER 4

FIGURE F-2. Kasami error-trapping decoder for the (24,12) Golay code.
GATE GATE OUTPUT
2 5
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX F

b. Gates 1, 4, and 5 are closed and gate 2 is opened. Gate 3 remains open. The
threshold tests occur in the following order:

1. If Z0 is unity, then all the errors are confined to the 11 high-order positions
of r(x), and S(x) matches the errors. Z0 opens gate 4 and closes gate 3.
Contents of both the 23-stage shift register and the syndrome shift register
are then shifted 11 times, and the errors are corrected. Then gate 4 is
closed and the contents of the 23-stage shift register are shifted until the
received codeword is in its original position. The decoder then goes to
step 3 below.

2. If Z1 is unity, the error pattern in S(x) is the same as the errors in the 11
high-order bits of the codeword r(x), and a single error exists at location
x5. Gate 4 is opened and gate 3 is closed. The counter is preloaded with a
count of 2, and both the syndrome shift register and the 23-stage shift
register are shifted until the error in x5 is corrected. Then gate 4 is closed,
and the contents of the 23-stage shift register are shifted until the received
codeword is in its original position. The decoder then goes to step 3.

3. If Z2 is unity, the error pattern in S(x) is the same as the errors in the 11
high-order bits of the codeword r(x), and there is a single error in location
x6. The same steps are followed as in b (above) except that the counter is
preloaded with a count of 3. The decoder then goes to step 3.

4. If neither of the three thresholds is unity, the decoder goes directly to step
3.

c. Gates 1, 4, and 5 are closed, and gates 2 and 3 are opened. Contents of both the
23-stage shift register and the syndrome shift register are then shifted once to the right. The
decoder then goes to step 2.

d. This action continues until step 3 has been executed 46 times. Then the decoder
returns to step 1 to process the next received codeword.

The decoder always yields an output. The output is correct if there were 3 or fewer errors in the
received codeword, and erroneous if there were more than 3 errors in the codeword.

F.4.2.3 Software implementation.

The transmitting DMTD shall generate the check bits using the following generator polynomial:

g(x) = x11 + x10 + x6 + x5 + x4 + x2 + 1

437
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX F

Note that using modulo 2 addition,

x23+1=(x11+x10+x6+x5+x4+x2+1)(x11+x9+x7+x6+x5+x+1)(x+1)

The 11 check bits shall be as derived from the generator matrix G, shown in FIGURE F-3, where
the matrix contains the coefficients of the polynomials on the left.

2 2 2 1 1 1 1 1 1 1 1 1 1
2 1 0 9 8 7 6 5 4 3 2 1 09 8 7 6 5 4 3 2 1 0
X X
11
x * g(x) = 1 1 0 0 0 1 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0
10
x * g(x) = 0 1 1 0 0 0 1 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0
9 11
x * g(x) + x * g(x) = 1 1 1 1 0 1 1 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0
8 10
x * g(x) + x * g(x) = 0 1 1 1 1 0 1 1 0 1 0 0 0 0 1 0 0 0 0 0 0 0 0
7 9
x * g(x) + x * g(x) = 0 0 1 1 1 1 0 1 1 0 1 0 0 0 0 1 0 0 0 0 0 0 0
6 8 11
(x + x + x ) * g(x) = 1 1 0 1 1 0 0 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 =G
5 7 10
(x + x + x ) * g(x) = 0 1 1 0 1 1 0 0 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0
4 6 9
(x + x + x ) * g(x) = 0 0 1 1 0 1 1 0 0 1 1 0 0 0 0 0 0 0 1 0 0 0 0
3 5 8 11
(x + x + x + x ) * g(x) = 1 1 0 1 1 1 0 0 0 1 1 0 0 0 0 0 0 0 0 1 0 0 0
2 4 7 10 11
(x + x + x + x + x ) * g(x) = 1 0 1 0 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 1 0 0
3 6 9 10 11
(x + x + x + x + x + x ) * g(x) = 1 0 0 1 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0
2 5 8
(1 + x + x + x + x
9 10
+ x
11
+ x ) * g(x) = 1 0 0 0 1 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 1

Parity Identity

FIGURE F-3. Generator matrix G.

By interchanging the I and P columns to obtain matrix T, shown in FIGURE F-4, that is,

G=[P,I](12 x 23) = >[I,P](12 x 23) = T

the transmission order and value of the code word bits can be obtained by matrix multiplication
(modulo 2 addition without carry) as follows:

438
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX F

Ib1 INFO BITS Ib12 * I,P = INFO BITS, CHECK BITS

(1x12) (12x23) (1x23)

FIRST BIT TRANSMITTED FIRST BIT TRANSMITTED

1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 1 1 0 1 0
0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 1 1 0 1
0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 1 1 0 1 0 0
0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 1 1 0 1 0
0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 1 0 1 1 0 1
0 0 0 0 0 1 0 0 0 0 0 0 1 1 0 1 1 0 0 1 1 0 0
T=
0 0 0 0 0 0 1 0 0 0 0 0 0 1 1 0 1 1 0 0 1 1 0
0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 1 0 1 1 0 0 1 1
0 0 0 0 0 0 0 0 1 0 0 0 1 1 0 1 1 1 0 0 0 1 1
0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 0 1 0 0 1 0 1 1
0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 0 1 1 1 1 1
0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 1 1 0 1 0 1

I P
FIGURE F-4. Matrix T.

439
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

PACKET CONSTRUCTION AND BIT ORDERING

G.1 General.

G.1.1 Scope.
This appendix illustrates the construction of packets starting with the Application Layer Protocol
Data Unit (PDU) and VMF Message data buffers and ending with the data link bit order of
transmission and physical layer PDU. However this example excludes the S/R protocol. The
focus of this example is to show correct formatting of the MIL-STD-188-220 subnetwork.

G.1.2 Application.
This appendix is a mandatory part of this document. The bit ordering defined herein shall be
utilized by all implementers.

G.1.3 Clarification of examples

G.2 Applicable documents.

a. RFC 768: User Datagram Protocol

b. RFC 791: Internet Protocol -- DARPA Internet Program Protocol Specification

c. MIL-STD-2045-47001D: Interoperability Standard for Connectionless Data Transfer --

Application Standard

G.3 PDU construction.

This section provides examples illustrating the construction and bit ordering of a VMF message
through the Application Layer, the Transport Layer, the Network Layer, Link Layer and Physical
Layer. For clarity, each layer will be discussed separately and then combined for actual
transmission. The same representations will be utilized for each layer:

• the MSB (2n bit) is represented with an italicized font and

• the LSB (20 bit) is shown to the RIGHT in the Value (binary) column.

440
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

This representation is carried into the other columns to identify the beginning and end of each of
the fields as the bits are moved into individual octets. Note that the bit markings for MSB and
LSB are on a field basis, not on an octet basis. Single bit fields are treated as LSB. In addition,
since some layers (e.g. transport) are based on commercial standards, the representation from the
appropriate RFC will also be included. In all cases, we will start with a figure which illustrates
the interaction with upper/lower communication layers, followed by a figure showing the
exchange between communication layers. There will be a table showing the construction of the
PDU. This will be followed by a table showing the construction of each octet and a figure
showing the serial representation of this particular PDU as it would appear at physical layer.

Each layer typically adds value and its own header to an outgoing message. This process is
illustrated in FIGURE G-1.

User
VMF MESSAGE Data

Layer 7: Application Application

Header
Layer 6: Presentation – No Presentation Header (Null Layer) (Includes Presentation
and Session features)
Layer 5: Session – No Session Header (Null Layer)
Layer 4: Transport UDP

MIL-STD-188-220 Intranet Internet

Layer 3: Network Protocol Protocol
Functions (iP) (IP)
Address &
Layer 2: Data Link Control
FCS

Transmission
Header
(Includes FCS)

Layer 1: Physical Preamble Postamble

Trans.
Bit Sync Flag & UDP & FCS
Header Intranet (iP) VMF
Char Sync Address Segmen- Application Header &
& FCS & Internet (IP) Message
TWC & Control tation Flags
& Flag

FIGURE G-1. PDU construction.

An application header is added to the VMF message at application layer. For this protocol,
layers 5 and 6 are null layers, and no processing or headers are present. The Application Layer
handles these functions. The transport layer adds its header. Although the standard calls out
TCP, UDP and segmentation/reassembly, only UDP is illustrated in this appendix. Next, the
network layer adds the IP header and the Intranet header. The message is now passed to the data
link layer which adds both a header and a trailer. Finally, the physical layer adds its header
resulting in the final PDU for transmission. Note that this example does not include TCP,
segmentation & reassembly, or COMSEC.

441
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

G.3.1 VMF message data exchange.

The relationship of the VMF Messaging Services to other communication layers is shown in
FIGURE G-2. A layered communication model is used in this example for consistency with the
principles of the ISO OSI reference model. The model discussed here is tailored to focus
attention specifically on VMF Messaging Services, and the data it produces. A user of VMF
Messaging Services exchanges Message Content with its peer at another node by sending and
receiving the Message Content via the VMF Messaging Services. VMF Messaging Services
sends and receives the Message Content by converting the Message Content to Message Data
and exchanging the Message Data with its peer at another node. The VMF Message Data is sent
and received via lower communication layers. The lower communication layers send and
receive the VMF Message Data transparently over a variety of communications media. Note that
VMF Messaging Services would ordinarily use Application Layer services from the lower
communication layers to send and receive Message Data. The Message Data would then appear
in the Application Layer PDU’s VMF message.

Outgoing Frame Incoming Frame

Construction Decomposition

User of VMF User of VMF

Messaging Message Content Messaging
Services Services

VMF VMF
Message Data
Messaging Messaging
Services Services

Lower Lower
Communication Lower Communication
Layers Layer
Message Data Trailers Layers
Headers

Communications Path

FIGURE G-2. VMF message services interaction with other communication layers.

The format of the Message Data is defined in terms of the actual data buffer or data stream used
to exchange the Message Data between the VMF Messaging Services and the lower
communication layers. The rationale for using the Message Data’s data buffer/stream to define
the format is: 1) for consistency with industry standard commercial communications hardware
and software (e.g., UNIX implementations of TCP/IP), which exchange data with other software
when sending or receiving as a buffer or stream of octets; 2) to provide a definition independent

442
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

of the specifics of any other communication layer, consistent with the OSI ISO model principle
of making communication layers independent; and 3) to avoid differences in the bit
representations used to implement communications on different media. For example, on
Ethernet LAN media each octet is sent LSB first, but on FDDI media each octet is sent MSB
first. To achieve a universal definition of the Message Data format, its representation is defined
independent of the other communication layers. The relationship of the Message Data’s data
buffer/stream to the VMF Messaging Services is depicted in FIGURE G-3.

User of VMF
Messaging
Services

Message Content

Data Buffer
or
VMF Messaging Data Stream
Services (octets)

Message
Data

Lower
Communication
Layers

FIGURE G-3. Exchange of message data between communication layers.

G.3.1.1 Example of VMF message data construction.

The construction of VMF Message Data is illustrated by the example in TABLE G-I. The first
four columns of the table provide a description of each field in the example, the field length in
bits, and the value of the field in both decimal (Dec) and binary representations. The last three
columns show the physical encoding of the VMF Message Data. In the fifth column, Field
Fragments, the bits of each field are placed in octets. The bit(s) of each field are positioned in an
octet such that the LSB of the field is positioned in the least significant unencoded bit of the
octet, the next LSB of the field is placed in the next least significant unencoded bit of the octet,
and repeated until all of the bits of the field have been encoded. When an octet is filled before
all the bits of a field are encoded, the process is continued encoding the next octet with the
remaining bits of the field. This field/octet encoding procedure is performed starting with the
first field and octet, and repeated for each successive field and individual octet, in order, until the
encoding is completed. When a field has groups, the field encoding procedure is performed
starting with the first group, and repeated for each successive group and individual octet, in
order, until the encoding of the field is completed. The Target Number field illustrates the
encoding of a field with groups. Note the LSB of a field or octet is defined as the bit having the

443
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

weight of 20 when the field or octet is represented as a numeric value. X’s are used to identify
bits that are not associated with the field being encoded. The sixth column, Octet Value -
Binary, assembles the bits contributed by successive fields into complete octets, represented in
binary. The seventh column, Octet Value – Hex, represents the octet value in hexadecimal
(Hex). The last column, Octet Number, numbers the octets from first to last starting with 0.

When all fields have been encoded, any remaining unencoded bits in the last octet are filled with
zeroes (zero padded). Each VMF Message is individually encoded and zero padded. This
example is a factitious VMF message – K15.99.

444
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

TABLE G-I. Example of K15.99 VMF message like data construction

Field Name Length Value Value Field Octet Octet Octet

(bits) (Dec) (Binary) Fragments Value Value Number
(Binary) (Hex)
MSB LSB MSB LSB MSB LSB
2n 20 27 20 27 20
Field1 5 0 00000 xxx00000

FPI (Field2) 1 1 1 XX1XXXXX

Field2 (ASCII 7 66(B) 1000010 10XXXXXX 10100000 A0 1
CHAR)
XXX10000
FPI (Field3) 1 1 1 XX1XXXXX
Field3 (A1234) 21
Subfield 1 (ASCII 7 65 (A) 1000001 01XXXXXX 01111000 78 2
CHAR)
XXX10000
Subfield 2 (Dec) 14 1234 00010011010010 010XXXXX 01010000 50 3
10011010 10011010 9A 4
XXXXX000
FPI (Field4) 1 0 0 XXXX0XXX
Field4 21 NA
GPI (Group1) 1 0 0 XXX0XXXX
Field5 5 NA
Field6 6 NA
Field7 6 NA
FPI (Field8) 1 0 0 XX0XXXXX
Field8 7 NA
GPI (Group2) 1 0 0 X0XXXXXX
Field9 24 NA
Field10 32 NA
Field11 5 NA
Field12 5 NA
Field13 6 NA
Field14 6 NA
(Zero Padding) 1 0 0 0XXXXXXX 00000000 00 5

FIGURE G-4 illustrates the octets arranged in a serial format as they would appear at the
physical layer, with LSB first.

Octet 0 Octet 1 Octet 2 Octet 3 Octet 4

0 7 0 7 0 7 0 7 0
2 2 2 2 2 2 2 2 2 27
00000101 00011110 00001010 01011001 00000000

FIGURE G-4. Serial representation of PDU.

445
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

G.3.2 Application Layer data exchange.

The relationship of the Application Layer to other communication layers is shown in FIGURE
G-5. A layered communication model is used in this example for consistency with the principles
of the ISO OSI reference model. The model discussed here is tailored to focus attention
specifically on the Application Layer, and the data it produces. A user of the Application Layer
exchanges a VMF message with its peer at another node by sending and receiving the VMF
message via the Application Layer. The Application Layer sends and receives the VMF message
transparently by producing and exchanging an Application Layer Protocol Data Unit (PDU) with
its peer at another node. The Application Layer PDU consists of the Application Header
concatenated with the VMF message, and is sent and received via lower communication layers.
The lower communication layers send and receive the VMF message transparently over a variety
of communications media.

Outgoing Frame Incoming Frame

Construction Decomposition

User of User of
Application User Data Application
Layer Layer
Services Services

Application Application
App. User Data
Layer Layer
Header

Lower Lower
Communication Lower Application Communication
Layers Layer Layer Trailers Layers
Header PDU

Communications Path

FIGURE G-5. Application Layer interaction with other communication layers.

The format of the Application Layer PDU is defined in terms of the actual data buffer or data
stream used to exchange the PDU between the Application Layer and the lower communication
layers. The rationale for using the PDU’s data buffer/stream to define the format is 1) for
consistency with industry standard commercial communications hardware and software (e.g.,
UNIX implementations of TCP/IP), which exchange data with other software when sending or

446
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

receiving as a buffer or stream of octets; 2) to provide a definition independent of the specifics of

any other communication layer, consistent with the OSI ISO model principle of making
communication layers independent; and 3) to avoid differences in the bit representations used to
implement communications on different media. For example, on Ethernet LAN media each octet
is sent LSB first, but on FDDI media each octet is sent MSB first. To achieve a universal
definition of the PDU format, its representation is defined independent of the other
communication layers. The relationship of the Application Layer PDU’s data buffer/stream to
the Application Layer is depicted in FIGURE G-6.

User of
Application
Layer Services

User Data

Data Buffer
Application
or
Layer
Data Stream
(octets)

Application Layer
PDU
(App. Header
& User Data)

Lower
Communication
Layers

FIGURE G-6. Exchange of application layer PDU between communication layers.

G.3.2.1 Example of Application Layer PDU.

The construction of an Application Layer PDU is illustrated by the example in TABLE G-II.
The first four columns of the table provide a description of each field in the example, the field
length in bits, and the value of the field in both Dec and binary representations. The last four
columns show the physical encoding of the Application Layer PDU. In the fifth column, Field
Fragments, the bits of each field are placed in octets. The bit(s) of each field are positioned in an
octet such that the LSB of the field is positioned in the least significant unencoded bit of the
octet, the next LSB of the field is placed in the next least significant unencoded bit of the octet,
and repeated until all of the bits of the field have been encoded. When an octet is filled before
all the bits of a field are encoded, the process is continued encoding the next octet with the
remaining bits of the field. This field/octet encoding procedure is performed starting with the
first field and octet, and repeated for each successive field and individual octet, in order, until the
encoding is completed. When a field has groups, the field encoding procedure is performed
starting with the first group, and repeated for each successive group and individual octet, in

447
Downloaded from http://www.everyspec.com

(bits) (Dec) (Binary) Fragments Value Number
(Binary)
MSB LSB MSB LSB MSB LSB
2n 20 2n 20 2n 20
GPI GPI for 1 0 0 xx0xxxxx
Security
Parameters
Information
GPI Group Presence 1 0 0 x0xxxxxx
Indicator
(FUTURE
USE 11)
GPI Group Presence 1 0 0 0xxxxxxx 00000000 17
Indicator
(FUTURE
USE 12)
GPI Group Presence 1 0 0 xxxxxxx0
Indicator
(FUTURE
USE 13)
GPI Group Presence 1 0 0 xxxxxx0x
Indicator
(FUTURE
USE 14)
GPI Group Presence 1 0 0 xxxxx0xx
Indicator
(FUTURE
USE 15)
(Zero 5 0 000000 00000xxx 00000000 18
Padding)

The Application Header is followed by the VMF message. The VMF message is shown as a
single 10-octet message to complete the Application Layer PDU. FIGURE G-7 provides an
illustration of the Application Header, as it would appear in serial form at the lower layers.

Octet 0 Octet 1 Octet 2 Octet 13 Octet 14 Octet 15 Octet 16 Octet 17 Octet 18

20 27 20 27 20 27 20 27 20 27 20 27 20 27 20 27 20 27
11000111 11010000 00000000 00100011 10000100 00001000 01000000 00000000 00000000

FIGURE G-7. Application Header (octets).

452
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

Any of the ASCII fields (e.g. Unit Name) in the application header can be terminated by either
an end of text marker, or by using the maximum number of bits. TABLE G-III shows how to
format the Unit Name when the Unit Name is used as part of the originator address group. The
Unit Name and URN are mutually exclusive inside the address group – never send both, Unit
Name and URN, in an address group. However if the address group has a Group Repeat
Indicator (GRI) each of the repeatable address groups can be different address types (e.g. Unit
Name or URN).

TABLE G-III. Example of a unit name as originator.

Syntax Field Name Length Value Value Field Octet Octet

(bits) (Dec) (Binary) Fragments Value Number
(Binary)
MSB LSB MSB LSB MSB LSB
2n 20 2n 20 2n 20
Version 4 3 0011 xxxx0011
FPI Compression 1 0 0 xxx0xxxx
Type
GPI Presence 1 1 1 xx1xxxxx
Indicator
(Originator)
FPI Presence 1 0 0 x0xxxxxx
Indicator
(URN)
FPI Presence 1 1 1 1xxxxxxx 10000011 0
Indicator (Unit
Name)
Unit Name 448 Max “UNITA”
(Originator)
“U” 7 85 1010101 x1010101
“N” 7 78 1001110 0xxxxxxx 01010101 1
xx100111
“I” 7 73 1001001 01xxxxxx 01100111 2
xxx10010
“T” 7 84 1010100 100xxxxx 10010010 3
xxxx1010
“A” 7 65 1000001 0001xxxx 00011010 4
xxxxx100
End of text 7 127 1111111 11111xxx 11111100 5
marker (ANSI xxxxxx11
ASCII DEL)
GPI Presence 1 1 1 xxxxx1xx
Indicator
(Recipient)
encode rest of the message

453
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

G.3.3 Transport Layer data exchange.

The relationship of the Transport Layer to other communication layers is shown in FIGURE G-8.
A user of the Transport Layer exchanges data with its peer at another node by sending and
receiving the Application Layer PDU via the Transport Layer. The Transport Layer sends and
receives the Application Layer PDU transparently by producing and exchanging a Transport
Layer Protocol Data Unit (PDU) with its peer at another node. The Transport Layer PDU
consists of the Transport Header concatenated with the Application Layer PDU, and is sent and
received via lower layer communication layers. The lower communication layers send and
receive the Transport PDU transparently over a variety of communications media.

Outgoing Frame Incoming Frame

Construction Decomposition

User of User of
Transport Application Transport
Layer Layer PDU Layer
Services Services

Transport Transport Application Transport

Layer Header Layer PDU Layer

Lower Lower
Communication Communication
Layers Lower Transport Layers
Trailers
Layer Layer
Headers PDU

Communications Path

FIGURE G-8 Transport layer interaction with other communication layers.

The relationship of the Transport Layer PDU’s data buffer/stream to the Application Layer is
depicted in FIGURE G-9. The Transport Layer PDU is defined as a buffer or stream of octets
consisting of the VMF message, Application Header and Transport Header.

G.3.3.1 An example of Segmentation / Reassembly (S/R) Data Segment construction.

S/R is described by MIL-STD-2045-47001, APPENDIX C. The S/R Data Segment from MIL-
STD-2045-47001, APPENDIX C, consists of 12 octets as shown in FIGURE G-10 with the
example values to be used for this appendix. Since MIL-STD-2045-47001, APPENDIX C,
treats bit 0 as MSB, FIGURE G-10 and FIGURE G-11 show B0 as MSB. For this example, the
Source Port has a value of 5000, Destination Port has a value of 1581, the Type (3 bits) equals 2,
HLEN (12 bits) equals 3, P/F (1 bit) equals 1, the Serial Number has a value of 16000, the

454
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

Segment Number equals 260, and the Last Segment Number equals 300. MIL-STD-188-220
typically treats the LSB as bit 0.

Application
Layer

Application Layer PDU

(Application Header
& User Data)

Data Buffer
Transport or
Layer Data Stream
(octets)

Transport Layer PDU

(Application Header
& User Data &
Transport Header)

Lower
Communication
Layers

FIGURE G-9. Exchange of transport layer PDU between communication layers.

MSB LSB MSB LSB MSB LSB MSB LSB

0 7 8 15 16 23 24 31
Source Port Destination Port
Type HLEN P/F Serial Number
Segment Number Last Segment Number
Data Portion

FIGURE G-10. S/R Data Segment

FIGURE G-11 illustrates the twelve octets comprising S/R with the binary bit patterns. Each
octet is marked to show both the MSB and LSB of each octet. It demonstrates how each of the
octets are arranged and passed in order to next layer.

455
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

Octet 0 Octet 1 Octet 2 Octet 3

B0 B7 B8 B15 B16 B23 B24 B31
27 20 27 20 27 20 27 20
00010011 10001000 00000110 00101101
Source Port (5000) Destination Port (1581)

Octet 4 Octet 5 Octet 6 Octet 7

B0 B7 B8 B15 B16 B23 B24 B31
27 20 27 20 27 20 27 20
01000000 00000111 00111110 10000000
Type (2) HLEN (3) P/F (1) Serial Number (16000)

Octet 8 Octet 9 Octet 10 Octet 11

B0 B7 B8 B15 B16 B23 B24 B31
27 20 27 20 27 20 27 20
00000001 00000100 00000001 00101100
Segment Number (260) Last Segment Number (300)

FIGURE G-11. Octet representation of S/R Data Segment.

The construction of a S/R Data Segment is illustrated by the example in TABLE G-IV. The first
four columns of the table provide a description of each field in both decimal and binary
representations. The last two columns show the physical encoding of the S/R Layer PDU. In the
fifth column, Field Fragments, the bits of each field are placed in octets. The bits(s) of each field
are positioned in an octet such that the MSB of the field is positioned in the most significant
unencoded bit of the octet, the next MSB of the field is placed in the next most significant
unencoded bit of the octet, and repeated until all of the bits of the field have been encoded.
When an octet is filled before all the bits of a field are encoded, the process is continued
encoding the next octet with the remaining bits of the field. This field/octet encoding procedure
is performed starting with the first field and octet, and repeated for each successive field and
individual octet, in order, until the encoding is completed. X’s are used to identify bits that are
not associated with the field being encoded. The sixth column, Octet Value - Binary, assembles
the bits contributed by successive fields into complete octets, represented in binary. The last
column, Octet Number, numbers the octets from first to last starting with 0.

456
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

TABLE G-IV. Example construction of S/R Data Segment.

Field Name Length Value Value Field Octet Value Octet

(bits) (Dec) (Binary) Fragments (Binary) Number
MSB LSB MSB LSB MSB LSB
2n 20 27 20 27 20
Source Port 16 5000 0001001110001000 0 0 0 1 0 0 1 1 0 0 0 1 0 0 1 1 0
10001000 10001000 1
Destination 16 1581 0000011000101101 0 0 0 0 0 1 1 0 0 0 0 0 0 1 1 0 2
Port 00101101 00101101 3
Type 3 2 010 010xxxxx

HLEN 12 3 000000000011 xxx00000 01000000 4

0000011x
xxxxxxx1
P/F 1 1 1 00000111 5
Serial 16 16000 0011111010000000 00111110 00111110 6
Number 10000000 10000000 7
Segment 16 260 0000000100000100 00000001 00000001 8
Number 00000100 00000100 9
Last 16 300 0000000100101100 00000001 00000001 10
Segment 00101100 00101100 11
Number
TABLE G-V illustrates the twelve octets of the S/R Data Segment showing the binary value of
the octet, the octet number (0-11) and the field represented by each octet. Note that the bit with
the bold italicized font identifies the MSB (2n) of the field, not the octet.

457
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

TABLE G-V. Octet representation of S/R header.

Octet Value Octet Field Name
(Binary) Number
27 20
00010011 0 Source Port
10001000 1 Source Port
00000110 2 Destination Port
00101101 3 Destination Port
01000000 4 Type & HLEN
00111110 6 Serial Number
10000000 7 Serial Number
00000001 8 Segment Number
00000100 9 Segment Number
00000001 10 Last Segment Number
00101100 11 Last Segment Number

FIGURE G-12 provides a serial representation of the S/R header, as it would appear at the
physical layer.

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

20 27 20 27 20 27 20 27 20 27 20 27 20 27 20 27
11001000 00010001 01100000 10110100 00000010 11100000 01111100 00000001

Octet 8 Octet 9 Octet 10 Octet 11

0 7 0
2 2 2 2 20
7
27 20 27
10000000 00100000 10000000 00110100

FIGURE G-12. Serial representation of S/R Data Segment.

G.3.3.2 An example of UDP header construction.

UDP is described by RFC 768. The UDP header from RFC 768 consists of 8 octets as shown in
FIGURE G-14 with the example values to be used for this appendix. Since the RFC treats bit 0
as MSB, FIGURE G-13 and FIGURE G-14 show B0 as MSB. For this example, the source has a
value of 1581, destination of 1581, length of 32 and the checksum equals 12427. MIL-STD-
188-220 typically treats the LSB as bit 0.

0 7 8 15 16 23 24 31
UDP Source (1581) UDP Destination (1581)
UDP Length (32) UDP Checksum (12427)

FIGURE G-13. UDP header.

458
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

FIGURE G-14 illustrates the eight octets comprising UDP with the binary bit patterns. Each
octet is marked to show both the MSB and LSB of each octet. It demonstrates how each of the
octets are arranged and passed in order to next layer.

Octet 0 Octet 1 Octet 2 Octet 3

B0 B7 B8 B15 B16 B23 B24 B31
27 20 27 20 27 20 27 20
00000110 00101101 00000110 00101101
UDP Source (1581) UDP Destination (1581)

Octet 4 Octet 5 Octet 6 Octet 7

B0 B7 B8 B15 B16 B23 B24 B31
27 20 27 20 27 20 27 20
00000000 00100000 00110000 10001011
UDP Length (32) UDP Checksum (12427)

FIGURE G-14. Octet representation of UDP header.

The construction of a Transport Layer Header is illustrated by the example in TABLE G-VI.
The first four columns of the table provide a description of each field in both Dec and binary
representations. The last two columns show the physical encoding of the Transport Layer PDU.
In the fifth column, Field Fragments, the bits of each field are placed in octets. The bits(s) of
each field are positioned in an octet such that the MSB of the field is positioned in the most
significant unencoded bit of the octet, the next MSB of the field is placed in the next most
significant unencoded bit of the octet, and repeated until all of the bits of the field have been
encoded. When an octet is filled before all the bits of a field are encoded, the process is
continued encoding the next octet with the remaining bits of the field. This field/octet encoding
procedure is performed starting with the first field and octet, and repeated for each successive
field and individual octet, in order, until the encoding is completed. The sixth column, Octet
Value - Binary, assembles the bits contributed by successive fields into complete octets,
represented in binary. The last column, Octet Number, numbers the octets from first to last
starting with 0.

459
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

TABLE G-VI. Example construction of UDP header.

Field Name Length Value Value Field Octet Value Octet

(bits) (Dec) (Binary) Fragments (Binary) Number
MSB LSB MSB LSB MSB LSB
215 20 27 20 27 20
UDP Source 16 1581 0000011000101101 00000110 00000110 0
00101101 00101101 1
UDP 16 1581 0000011000101101 00000110 00000110 2
Destination 00101101 00101101 3
UDP Length 16 32 0000000000100000 00000000 00000000 4
0 0 100000 0 0 100000 5
UDP 16 12427 001100010001011 00110000 00110000 6
Checksum 10001011 10001011 7

TABLE G-VII illustrates the eight octets of the Transport Header showing the binary value of
the octet, the octet number (0-7) and the field represented by each octet. Note that the bit with
the bold italicized font identifies the MSB (2n) of the field, not the octet.

TABLE G-VII. Octet representation of UDP header.

Octet Value Octet Field Name

(Binary) Number
27 20
00000110 0 Source
00101101 1 Source
00000110 2 Destination
00101101 3 Destination
00000000 4 Length
0 0 100000 5 Length
00110000 6 Checksum
10001011 7 Checksum

FIGURE G-15 provides a serial representation of the UDP header, as it would appear at the
physical layer.

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

20 27 20 27 20 27 20 27 20 27 20 27 20 27 20 27
01100000 10110100 01100000 10110100 00000000 00000100 0001100 11010001

FIGURE G-15. Serial representation of UDP header.

460
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

G.3.4 Network Layer data exchange.

The relationship of the Network Layer to other communication layers is shown in FIGURE G-
16. A user of the Network Layer exchanges data with its peer at another node by sending and
receiving the Transport Layer PDUs via the Network Layer. The Network Layer sends and
receives the Transport Layer PDUs transparently by producing and exchanging a Network Layer
PDU. The Network Layer PDU consists of the Network Headers concatenated with the
Transport Layer PDU, and is sent and received via lower layer communication layers. The lower
communication layers send and receive the Network Layer PDU transparently over a variety of
communications media.

Outgoing Frame Incoming Frame

Construction Decomposition

User of User of
Network Transport Network
Layer PDU
Layer Layer
Services Services

Network Network Transport Network

Layer Header Layer PDU Layer

Lower Lower
Communication Communication
Layers Lower Network Layers
Trailers
Layer Layer
Headers PDU

Communications Path

FIGURE G-16. Network layer interaction with other communication layers.

The relationship of the Network Layer PDU’s data buffer/stream to the Transport Layer is
depicted in FIGURE G-17. The Network Layer PDU is defined as a buffer or stream of octets
consisting of the VMF message, Application Header, Transport Header and Network Headers.
There are two Network Headers in the Network Layer PDU when using MIL-STD-188-220.

461
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

Transport
Layer

Transport Layer PDU

(Transport Header &
Application PDU)

Data Buffer
Network or
Layer Data Stream
(octets)
Network Layer PDU
(Application PDU &
Transport Header &
Network Headers)

Lower
Communication
Layers

FIGURE G-17. Exchange of network layer PDU between communication layers.

The Internet Protocol (IP) is described by RFC 791. The IP header from RFC 791 is shown in
FIGURE G-18 with the example values, in parentheses, to be used for this appendix.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Ver (4) IHL (5) Type of Service (0) Total Length (52)
Identification (1) Flag (0) Fragment Offset (0)
Time to Live (50) Protocol (17) Header Checksum (4091)
Source Address (192.31.124.65)
Destination Address (192.31.124.61)

FIGURE G-18. IP header.

G.3.4.1 Example of Internet Layer header.

The construction of an Internet Layer Header is illustrated by the example in TABLE G-VIII.
The first four columns of the table provide a description of each field in the example, the field
length in bits, and the value of the field in both decimal and binary representations. The last
three columns show the physical encoding of the Internet Layer Header. In the fifth column,
Field Fragments, the bits of each field are placed in octets. The bit(s) of each field are positioned
in an octet such that the MSB of the field is positioned in the most significant unencoded bit of
the octet, the next MSB of the field is placed in the next most significant unencoded bit of the
octet, and repeated until all of the bits of the field have been encoded. When an octet is filled
before all the bits of a field are encoded, the process is continued encoding the next octet with
the remaining bits of the field. This field/octet encoding procedure is performed starting with the
first field and octet, and repeated for each successive field and individual octet, in order, until the

462
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

encoding is completed. X’s are used to identify bits that are not associated with the field being
encoded. The sixth column, Octet Value - Binary, assembles the bits contributed by successive
fields into complete octets, represented in binary. The last column, Octet Number, numbers the
octets from first to last starting with 0.

TABLE G-VIII. Example construction of IP header.

Field Name Length Value Value Field Octet Octet

(bits) (Dec) (Binary) Fragments Value Number
(Binary)
2n 20 2n 20 2n 20
Version 4 4 0100 0100xxxx
Internet 4 5 0101 xxxx0101 01000101 0
Header Length
Type of Service 8 0 00000000 00000000 00000000 1
Length 16 52 0000000000110100 00000000 00000000 2
00110100 00110100 3
Identification 16 1 0000000000000001 00000000 00000000 4
00000001 00000001 5
Flags 3 0 000 000xxxxx
Fragmentation 13 0 0000000000000 xxx00000 00000000 6
Offset 00000000 00000000 7
Time to Live 8 50 00110010 00110010 00110010 8
Protocol 8 17 00010001 00010001 00010001 9
Header 16 4091 0000111111111011 00001111 00001111 10
Checksum 11111011 11111011 11
Source Address 32 192.31.124.65 1100000000011111 11000000 11000000 12
0111110001000001 00011111 00011111 13
01111100 01111100 14
01000001 01000001 15
Destination 32 192.31.124.61 1100000000011111 11000000 11000000 16
Address 0111110000111101 00011111 00011111 17
01111100 01111100 18
00111101 00111101 19

FIGURE G-19 illustrates the Internet Header demonstrating the relationship between the
individual bits (B0 - B7), the bit weighting (27 - 20), the individual fields and the example bit
patterns associated with each field.

463
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

Octet 0 Octet 1 Octet 2 Octet 3

B0 B7 B0 B7 B0 B7 B0 B7
27 20 27 20 27 20 27 20
01000101 00000000 00000000 0 0 1 1 0 10 0
Ver (4) IHL (5) Type of Service (0) Total Length (52)

Octet 4 Octet 5 Octet 6 Octet 7

B0 B7 B0 B7 B0 B7 B0 B7
27 20 27 20 27 20 27 20
00000000 0000001 000 00000 00000000
Identification (1) Flag (0) Fragment Offset (0)

Octet 8 Octet 9 Octet 10 Octet 11

B0 B7 B0 B7 B0 B7 B0 B7
27 20 27 20 27 20 27 20
00110010 00010001 00001111 1 1 1 1 1 01 1
Time (50) Protocol (17) Header Checksum (4091)

Octet 12 Octet 13 Octet 14 Octet 15

B0 B7 B0 B7 B0 B7 B0 B7
27 20 27 20 27 20 27 20
11000000 00011111 01111100 01000001
Source Address (192.31.124.65)

Octet 16 Octet 17 Octet 18 Octet 19

B0 B7 B0 B7 B0 B7 B0 B7
27 20 27 20 27 20 27 20
11000000 00011111 01111100 00111101
Destination Address (192.31.124.61)

FIGURE G-19. Octet representation of IP header.

G.3.4.2 Example of Intranet Layer header.

The construction of an Intranet Layer Header is illustrated by the example in TABLE G-IX. The
first four columns of the table provide a description of each field in the example, the field length
in bits, and the value of the field in both decimal and binary representations. The last three
columns show the physical encoding of the Intranet Layer Header. In the fifth column, Field
Fragments, the bits of each field are placed in octets. The bit(s) of each field are positioned in an
octet such that the LSB of the field is positioned in the least significant unencoded bit of the
octet, the next LSB of the field is placed in the next least significant unencoded bit of the octet,
and repeated until all of the bits of the field have been encoded. When an octet is filled before
all the bits of a field are encoded, the process is continued encoding the next octet with the
remaining bits of the field. This field/octet encoding procedure is performed starting with the

464
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

first field and octet, and repeated for each successive field and individual octet, in order, until the
encoding is completed. X’s are used to identify bits that are not associated with the field being
encoded. The sixth column, Octet Value - Binary, assembles the bits contributed by successive
fields into complete octets, represented in binary. The last column, Octet Number, numbers the
octets from first to last starting with 0. This example only illustrates the Intranet Header fields
that are be transmitted as a minimum.

TABLE G-IX. Example construction of Intranet header (minimum).

Field Name Length Value Value Field Octet Octet

(bits) (Dec) (Binary) Fragments Value Number
(Binary)
2n 20 27 20 27 20
Version Number 4 0 0000 xxxx0000
Message Type 4 4 0100 0100xxxx 01000000 0
Intranet Header Length 8 3 00000011 00000011 00000011 1
Type of Service 8 0 00000000 00000000 00000000 2

The Intranet Layer is defined in 5.4.1 and is shown in FIGURE G-20 with the example values
used in this appendix.

Octet 0 Octet 1 Octet 2

0 7 0 7 0
2 2 2 2 2 27
0000 0010 11000000 00000000
Version (0) Message Type (4) Intranet Header Length (3) Type of Service
(0)

FIGURE G-20. Intranet header.

FIGURE G-21 provides a serial representation of the Network Layer PDU as it would appear at
the physical layer.

465
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

Intranet header IP header

Octet 0 Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 Octet 7
20 27 20 27 20 27 20 27 20 27 20 27 20 27 20 27
00000010 11000000 00000000 10100010 00000000 00000000 00101100 00000000

IP header (continued)
Octet 8 Octet 9 Octet 10 Octet 11 Octet 12 Octet 13 Octet 14 Octet 15
20 27 20 27 20 27 20 27 20 27 20 27 20 27 20 27
10000000 00000000 00000000 01001100 10001000 11110000 11011111 00000011

IP header (continued) IP header

(end)
Octet 16 Octet 17 Octet 18 Octet 19 Octet 20 Octet 21 Octet 22
20 27 20 27 20 27 20 27 20 27 20 27 20 27
11111000 00111110 10000010 00000011 11111000 00111110 10111100

FIGURE G-21. Serial representation of network layer PDU.

G.3.5 This paragraph was intentionally deleted and left blank for paragraph conformity.

G.3.6 Data Link Layer data exchange.

The relationship of the Data Link Layer to other communication layers is shown in FIGURE G-
22. A user of the Data Link Layer exchanges the Network Layer PDU with its peer at another
node by sending and receiving the Network PDU via the Data Link Layer. The Data Link Layer
sends and receives the VMF message transparently by producing and exchanging a Data Link
Layer PDU with its peer at another node. The Data Link Layer PDU consists of the
Transmission Header, and Data Link Frame Header, Network PDU, and the Data Link Frame
Trailer, and is sent and received via the Physical layer. The Physical layer sends and receives
the VMF message transparently over a variety of communications media.

466
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

Outgoing Frame Incoming Frame

Construction Construction

User of User of
Data Link Network Data Link
Layer Layer Layer
PDU
Services Services

Data Link Transmis Data Link Network Data Data Link

Frame Link
Layer -sion Header
Layer Layer
Trailer
Header PDU

Physical Physical
Layer Layer
Physical Data LinkLayer Physical
Layer PDU Layer
Header Trailer

Communications Path

FIGURE G-22. Data link layer interaction with other communication layers.

The format of the Data Link Layer PDU is defined in terms of the actual data buffer or data
stream used to exchange the PDU between the Network Layer and the Physical Layer. The
relationship of the Data Link Layer PDU’s data buffer/stream to the Intranet Layer is depicted in
FIGURE G-23. The Data Link Layer PDU is defined as a buffer or stream of octets consisting
of the Transmission Header, Data Link Frame Header, Network PDU and Data Link Layer
trailer.

467
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

Network
Layer

Network Layer PDU

(Application PDU &
Transport Header &
Network Headers)
Data Buffer
or
Data Link Data Stream
Layer (octets)

Data Link Layer PDU

(Application PDU
& Transport Header
& Network Headers
& Data Link Header & Trailer

Physical
Layer

FIGURE G-23. Exchange of data link layer PDU between communication layers.

G.3.6.1 Example of Data Link Layer PDU.

The Data Link Layer PDU consists of the Transmission Header, Data Link Frame Header,
followed by the information field and Data Link Frame Trailer as shown in FIGURE G-24. The
information field consists of the Network PDU described previously (VMF message, Application
Header, Transport Header, IP Header and Intranet Header).

Trans- Data
mission Link Information Field Data Link Frame
Header Frame Trailer
Header

FIGURE G-24. Data Link Layer PDU.

TABLE G-X illustrates the Data Link Frame Header, and TABLE G-XI illustrates the Data Link
Frame Trailer. The first four columns of the tables provide a description of each field in the
example, the field length in bits, and the value of the field in both decimal and binary
representations. The last three columns show the bit serial physical Transmission order of the
Data Link Frame as a sequence of octets with the bits of each octet transmitted LSB first. In the
fifth column, Field Fragments, the bits of each field are placed in octets, in accordance with
5.3.4.3.1. The bit(s) of each field, other than the FCS field, are positioned in an octet such that
the LSB of the field is positioned in the least significant unencoded bit of the octet, the next LSB
of the field is placed in the next least significant unencoded bit of the octet, and repeated until all

468
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

of the bits of the field have been encoded. The bit(s) of FCS fields are positioned in an octet
such that the MSB of the field is positioned in the least significant unencoded bit of the octet, the
next MSB of the FCS field is placed in the next least significant unencoded bit of the octet, and
repeated until all of the bits of the FCS field have been encoded. When an octet is filled before
all the bits of a field are encoded, the process is continued encoding the next octet with the
remaining bits of the field. This field/octet encoding procedure is performed starting with the
first field and octet, and repeated for each successive field and individual octet, in order, until the
encoding is completed. The sixth column, Octet Value - Binary, assembles the bits contributed
by successive fields into complete octets, represented in binary and transmitted LSB first. The
last column, Octet Number, numbers the octets in the order in which they will be transmitted,
from first to last starting with 0.

TABLE G-X. Example construction of Data Link frame header.

Field Name Length Value Value Field

Octet Octet
(bits) (Dec) (Binary) Fragments
Value Number
(Binary)
2n 20 27 20 27 20
Flag 8 126 01111110 01111110 01111110 0
Command/Response 1 0 0 xxxxxxxx0
Bit
Source Address 7 7 0000111 0000111x 00001110 1
Extension Bit 1 1 1 xxxxxxx1
Destination Address 7 4 0000100 0000100x 00001001 2
Control Field 8 19 00010011 00010011 00010011 3

TABLE G-XI. Example construction of Data Link frame trailer.

Field Name Length Value Value Field

Octet Octet
(bits) (Dec) (Binary) Fragments
Value Number
(Binary)
2n 20 27 20 27 20
Frame Check 32 340406525 1100101011100101 01010011 01010011 0
Sequence 8 1110100111101010 10100111 10100111 1
(transmitted MSB 2
first) 3
10010111 10010111
01010111 01010111
Flag 8 126 01111110 01111110 01111110 4

IP (cont.)
8 9 10 11 12 13 14
0 7 0 7 0 7 0 7 0 7 0 7 0
2 2 2 2 2 2 2 2 2 2 2 2 2 27
TOS Total Length Identification Offset Flag Offset
00000000 00000000 00101100 00000000 10000000 00000 000 00000000

IP (cont.) UDP
25 26 27 28 29 30

20 27 20 27 20 27 20 27 20 27 20 27
DESTINATION SOURCE DESTINATION
00111110 10111100 01100000 10110100 01100000 10110100

APP. HEADER APP. HEADER

34 35 36 45 46 47 48

20 27 20 27 20 27 20 27 20 27 20 27 20 27
CHKSM GPI-FPI-ORIG Message Number, Subtype, Size- etc. GPI-DTG
00001000 11000111 11010000 00011000 00011100 01001000 00100011

APP. HEADER VMF MESSAGE

52 53 54 55 56 57

20 27 20 27 20 27 20 27 20 27 20 27
Security & Future group-etc. CF-etc. GROUP-etc
00000000 00000000 00000101 00011110 00001010 01011001

LINK FRAME TRAILER

58 59 60 61 62 63

20 27 20 27 20 27 20 27 20 27 20 27
Pad FCS FLAG
00000000 11001010 11100101 11101001 11101010 01111110

FIGURE G-25. Serial representation of Data Link Layer PDU.

472
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

G.3.6.1.1 Zero bit insert/v36 scramble/FEC/TDC of the data link frame.

The Data Link Frame is zero filled to prevent any part of the data accidentally being interpreted
as a Frame Flag. Also in our example scrambling, FEC and TDC are being used. FIGURE G-26
shows some of the example data before applying zero-bit insertion, scrambling, FEC or TDC.
After zero-bit insertion, scrambling, FEC and TDC, the fields are not easy to identify; therefore
field names are not shown.

Octet 0 Octet 1 Octet 2 Octet 3 Octet 4 Octet 5

20 27 20 27 20 27 20 27 20 27 20 27
0x7E 0x70 0x90 0xC8 0x02 0xC0

Octet 58 Octet 59 Octet 60 Octet 61 Octet 62 Octet 63

20 27 20 27 20 27 20 27 20 27 20 27
0x00 0xCA 0xE5 0xE9 0xEA 0x7E

FIGURE G-26. Data before zero bit insertion in transmission order.

The following is a Hex dump of the data link frame in the different stages: (a) zero-bit inserted,
(b) scrambled, (c) FEC, and (d) TDC:

Note: In the following dumps the 16 bit values are in transmission order (LSB first). The TWC
in the physical layer is defined in words and fields are no longer easily distinguishable.

a. Data after zero bit insertion (520 bits plus 8 padding bits)
0x7e70 0x90c8 0x02c0 0x00a2 0x0000 0x4c00 0x8000 0x004c 0x88f0 0xdf01 0xf60f
0x9040 0x7d83 0xe5e3 0x05a3 0x05a0 0x0026 0x9526 0x3e40 0x0002 0x9f00 0x0000
0x08fb 0x181c 0x4823 0x8408 0x4000 0x0005 0x1e0a 0x5900 0xcae5 0xe9ea 7e00

b. Data after V.36 scrambling (520 bits plus 8 padding bits)

0x8f80 0x872a 0xa161 0x7a0a 0xbfaa 0x3ffa 0x8db6 0x879b 0x715d 0x31d1 0xe628
0x7e1e 0xde57 0x1553 0xf5be 0x05b2 0x5520 0xa903 0xbcb80xdfcf 0x0c91 0x2a79
0xde6e 0xaffa 0x1efc 0x501b 0x19c60x9ddd 0x2d9b 0x16f9 0xb233 0xf35d 0x0000

473
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

c. Data after FEC(Golay 24,12) (1056 bits)

Golay (24,12) is derived from Golay (23,12): See F 4.1 for details.
0x8f8a 0x5a08 0x7898 0x2aae 0x8616 0x140a 0x7a0b 0xf0ab 0xf3e8 0xaa37 0xdeff
0xad82 0x8dbd 0x4268 0x71ca 0x9b76 0xf215 0xd6f0 0x31d4 0x001e 0x6c92 0x2877
0xf0e1 0xe82e 0xde57 0x0871 0x5ffc 0x53f2 0xa05b 0xe990 0x05b2 0xec25 0x53ea
0x20ab 0x9090 0x3a14 0xbcb6 0xf88d 0xf7d4 0xcf01 0xa6c9 0x1218 0x2a71 0x3c9d
0xe88a 0x6ea5 0x42ff 0xad82 0x1ef9 0xbec5 0x04b0 0x1b19 0x2e9c 0x 662a 0x9dd9
0x5ed2 0xd48c 0x9b150x5a6f 0x9796 0xb233 0x0b3f 0x32e0 0x5d0c 0xaa00 0x0000

d. Data after TDC(16,24) (1152 bits)

0x87a1 0x0941 0x2f4b 0x193c 0xefe6 0x9194 0xbf24 0x85b9 0xa599 0x447f 0x67e7
0x56fa 0xe985 0x33be 0xae32 0x0fc2 0x6f76 0x8ef2 0x0c33 0xca36 0xd641 0x2201
0xb3e5 0x0000 0x81f5 0xf033 0x468b 0xf185 0x90ff 0x8ce7 0xb02b 0x7c75 0x3ac7
0xf44c 0x3bcf 0xedd8 0x5305 0xc0c3 0xefd0 0xd66b 0x7ee5 0x4cc0 0x6caa 0x53d8
0xcc9c 0x496a 0x0425 0x0000 0x5e8a 0x452a 0x01ca 0xbeea 0xbb6a 0xd96a 0xa7ca
0x6b6a 0x8d0a 0x9c0a 0x90ca 0xafca 0xa82a 0x572a 0x11ca 0xab8a 0xc5ea 0x0a4a
0xf0ea 0xcb8a 0xbe2a 0xad0a 0xbb2a 0x0000

G.3.6.1.2 Construction of the transmission header.

The Transmission Header precedes the data link frame and formatted as defined in TABLE G-
XIII.

TABLE G-XIII. Example construction of Data Link transmission header.

Field Name Length Value Value Field

Octet Octet
(bits) (Dec) (Binary) Fragments
Value Number
(Binary)
2n 20 27 20 27 20
Flag 8 126 01111110 01111110 01111110 0
FEC 1 1 1 xxxxxxx1
TDC 1 1 1 xxxxxx1x
Scramble 1 1 1 xxxxx1xx
MIL-STD-188-220 3 0 000 xx000xxx
Version
Transmit Queue 10 0 0000000000 00xxxxxx 00000111 1
00000000 00000000 2

474
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

TABLE G-XIII. Example construction of Data Link transmission header-Continued

Field Name Length Value Value Field Octet Octet

(bits) (Dec) (Binary) Fragments Value Number
(Binary)
2n 20 27 20 27 20
FCS 32 471931248 0001110000100001 00011100 00111000 3
0001100101110000 00100001 10000100 4
00011001 10011000 5
01110000 00001110 6
Flag 8 126 01111110 01111110 01111110 7

G.3.6.1.3 Zero bit insert/v36 scramble/FEC of the transmission header.

The Transmission Header is zero inserted to prevent any part of the data accidentally being
interpreted as a Frame Flag. After zero-bit insertion, the fields are not easy to identify; therefore
field names are not shown. The following is a Hex dump of the Transmission Header of zero-bit
inserted:

Transmission Header after zero bit insertion (64 bits)

0x7ee0 0x001c 0x2119 0x707e

G.3.6.1.4 Completed Data Link Layer PDU to be passed to the Physical Layer.
The data link layer passes the Data Link Layer PDU to the Physical Layer. The elements of a
Data Link Layer PDU include one transmission header and one or more PDUs. The following
complete data link PDU (consisting of transmission header and Data Link frame) will be passed
to the Physical Layer:

Complete Data Link Layer PDU

a. Transmission Header (64 bits):

0x7ee0 0x001c 0x2119 0x707e

b. Data Link Layer Frame (1152 bits):

475
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

G.3.7 Physical Layer data exchange.

The relationship of the Physical Layer to other communication layers is shown in FIGURE G-27.
A user of the Physical Layer exchanges the Data Link Layer PDU with its peer at another node
by sending and receiving the Data Link PDU via the Physical Layer. Note that one byte of 00 (8
bits of 0s) was appended after the final data link layer frame.

1 2 3 85 86 87
0x64f2 0xf296 0x905e 0x0abb 0x2a00 0x0000
0110010011110010 1111001010010110 1001000001011110 0000101010111011 0010101000000000 0000000000000000

FIGURE G-27. Serial representation of Physical Layer transmission unit.

G.3.7.1 Physical Layer processing example.

The Physical Layer encodes data submitted by the data link layer in a format to meet the
physical media’s requirements. This example does not address the electrical or mechanical
functions normally associated with the physical layer protocols. At the Physical Layer the
transmission header is extracted and the TWC is calculated, the Transmission header is FEC &
TDC encoded except when packet mode is used. Note the other Physical Layer functions
(COMSEC, DMTD, etc) are not shown in this example.

TWC Transmission Header Data Link Frame

G.3.7.1.1 Transmit Word Count (TWC).

TWC is calculated across the Data Link frame plus the size of the encoded Transmission Header
& TWC size (encoded Transmission Header & TWC [10.5 16-bit words]). Therefore this
Physical Layer PDU’s TWC would be calculated as follows:

TWC = encoded Data Link frame + encoded Transmission Header and TWC
TWC = 72 words + 10.5 words (rounded up to nearest word)
TWC = 83 words

TWC (83) Transmission Header Data Link Frame

Transmission header including TWC (76 bits plus 4 padding bits)

0xca07 0xee00 0x01c2 0x1197 0x07e0

G.3.7.1.2 FEC & TDC of Transmission Header.

The Transmission Header has FEC & TDC encoding applied. Below is the Transmission Header
in the different stages of FEC & TDC:

476
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX G

a. Transmission header/with TWC after FEC (Golay 24,12) (168 bits plus 8 padding bits)
Golay (24,12) is derived form Golay (23,12): See F 4.1 for details.
0xca0f 0x587e 0xe806 0x0000 0x001c 0x20c8 0x1191 0xfe70 0x75a4 0xe005 0x2600

b. Transmission header with TWC after TDC (7,24) (168 bits plus 8 padding bits)
0x838d 0x1aed 0x0a30 0x0448 0x8950 0x6c10 0xe047 0x1d30 0x3c49 0x89d2 0x8000

G.3.7.1.3 The Physical Layer PDU.

Complete message including 64-bit frame synchronization, TWC, transmission header, and Data
Link frame. (Total: 1392 bits including 8 padded trailer bits):

0x64f2 0xf296 0x905e 0xadd9 0x838d 0x1aed 0x0a30 0x0448 0x8950 0x6c10 0xe047
0x1d30 0x3c49 0x89d2 0x8087 0xa109 0x412f 0x4b19 0x3cef 0xe691 0x94bf 0x2485
0xb9a5 0x9944 0x7f67 0xe756 0xfae9 0x8533 0xbeae 0x320f 0xc26f 0x768e 0xf20c
0x33ca 0x36d4 0x4122 0x01b3 0xe500 0x00810xf5f0 0x3346 0x8bf1 0x8590
0xff8c0xe7b0 0x2b7c 0x753a 0xc7f4 0x4c3b 0xcfed 0xd853 0x05c0 0xc3ef 0xd0d6
0x6b7e 0xe54c 0xc06c 0xaa53 0xd8cc 0x9c49 0x6a04 0x2500 0x005e 0x8a45 0x2a01
0xcabe 0xeabb 0x6ad9 0x6aa7 0xca6b 0x6a8d 0x0a9c 0x0a90 0xcaaf 0xcaa8 0x2a57
0x2a11 0xcaab 0x8ac5 0xea0a 0x4af0 0xeacb 0x8abe 0x2aad 0x0abb 0x2a00 0x0000

477
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX H

INTRANET TOPOLOGY UPDATE

H.1 General.

H.1.1 Scope.
This appendix describes a procedure for active intranet topology updates. The intranet is defined
as all processors and CNRs within a single transmission channel.

H.1.2 Application.
This appendix is a mandatory part of MIL-STD-188-220 for systems implementing Intranet
message type 2, Topology Update. The information contained herein is intended for compliance.

H.2 Applicable documents.

This section is not applicable to this appendix.

H.3 Problem overview.

FIGURE H-1 shows a sample extended CNR network. Each node labeled A through H is
considered to be a radio with an associated communication processor. The dotted ovals indicate
subsets of connectivity. FIGURE H-2 is a link diagram of the sample network. Assuming the
nodes know nothing about neighbor nodes that are more than 1 hop away, they need to exchange
connectivity information. The topology update packet is used to exchange topology information
to build up a more complete view of the intranet's topology at every node.

E G

A C

F H

FIGURE H-1. Sample intranet.

478
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX H

E G

A C

F H

FIGURE H-2. Link diagram of sample network.

H.3.1 Routing trees.

Each node should store topology information as a routing tree graph. Considering the network in
FIGURE H-3, FIGURE H-4 shows the routing tree for nodes A and C prior to the exchange of
any topology information. The routing trees for A and C contain only their nearest neighbors -
those nodes which they can talk to directly. Similar graphs would exist for all other nodes.

A C

B C D A B D E F

FIGURE H-3. Routing tree for nodes A and C.

H.4 Topology Updates.

H.4.1 Exchanging routing trees.

Nodes in the network gain more topology information by One-hop multicasting their individual
routing trees to their nearest neighbor nodes. This exchange of routing trees will percolate more
complete topology information through the network. For example, assume the routing trees for
all nodes in FIGURE H-4 initially contain only nearest neighbors (nodes who are in direct
communication with the given node). If node C multicasts its topology information to all nodes

479
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX H

one hop away (those which are nearest neighbors), all neighbor nodes integrate C's routing tree
into their own. Node A would integrate the graph for Node C into its routing tree as shown in
FIGURE H-4.

B C D

A B D E F

FIGURE H-4. Concatenated routing tree for node A.

Before the routing tree is saved, Node A prunes any successive instances of itself. For instance,
in FIGURE H-4, the link from A to C is the same as the link from C to A; therefore, the link
from C to A is removed. All redundant identical links are also pruned. These are links with the
order of the end points reversed.

H.4.2 Topology tables.

The topology table for A is shown in TABLE H-I. It assumes no nodes are in quiet mode, all
nodes can participate in relay, and all links have a cost of 1. The actual link layer addresses for
the nodes would be placed into the table in place of the symbols A, B, C, etc. The extension bit
in the address octet would always be set to 0 for topology updates.

TABLE H-I. Topology table for node A.

Node Node Hops Cost NR Quiet

Address Predecessor
B A 1 1 0 0
C A 1 1 0 0
D A 1 1 0 0
B C 2 1 0 0
D C 2 1 0 0
E C 2 1 0 0
F C 2 1 0 0

There are two entries for node B indicating that there are two paths from A to B. This table
could be immediately copied to the respective fields of a topology update packet. The

480
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX H

predecessor address is not included in the topology update packet for nearest neighbor nodes
because the predecessor is, by definition, the originator node.

H.4.3 Sparse routing trees.

Exchanging full routing tree tables provides full topology information; however, the amount of
data in the routing tree gets very large, especially for fully connected nets. The number of links
in a fully connected net with n nodes is n(n-1)/2. Although full routing trees should be stored by
a node, exchanging these routing trees may consume too much bandwidth. A smaller copy of
the full routing tree (called a sparse routing tree) should be prepared for transmission to neighbor
nodes. To reduce the number of branches in the routing tree, some of the paths to duplicate
nodes on the tree are pruned according to following rules:

a. Only the shortest paths from the root node to another node are retained.

b. For redundant paths from a root node to another node which are the same length (same
number of links in the routing tree), at most 2 are retained. Some redundancy in paths is
necessary for volatile networks.

For the previous example, the path from C to B and C to D would be pruned, since there are
already shorter paths from A to C and A to D. The pruning yields the sparse routing tree in
FIGURE H-5 and TABLE H-II.

B C D

E F

FIGURE H-5. Sparse routing tree for node A.

TABLE H-II. Sparse routing tree for node A.

Node Node Hops Cost NR Quiet

Address Predecessor
B A 1 1 0 0
C A 1 1 0 0
D A 1 1 0 0
E C 2 1 0 0
F C 2 1 0 0

481
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX H

The final routing tree for Node A, after all the nodes exchange their sparse routing trees, is
shown in FIGURE H-6 and TABLE H-III. Note that FIGURE H-6 shows more than 2 paths
between nodes G and A and H and A; however, the sparse routing tree table, which is the
information actually transmitted, shows only two entries for nodes G and H. The pruning rules
stated above have not been violated. They have been applied to the entries in the sparse routing
table. The sparse routing graph is deduced from the table. Thus, quite a few redundant paths
can be derived from the structure of the sparse routing table.

B C D

E F E F

G H G H G H G H

FIGURE H-6. Final routing tree for node A.

TABLE H-III. Final routing tree for node A.

Node Node Hops Cost NR Quiet

Address Predecessor
B A 1 1 0 0
C A 1 1 0 0
D A 1 1 0 0
E B 2 1 0 0
F B 2 1 0 0
E C 2 1 0 0
F C 2 1 0 0
G E 3 1 0 0
H E 3 1 0 0
G F 3 1 0 0
H F 3 1 0 0

H.4.4 Rules for exchanging Topology Updates.

Topology update packets are transmitted exclusively using a One-hop multicast address. The
Topology Update ID is a number from 1 to 255. Together with the originator’s link layer

482
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX H

address, the Topology Update ID uniquely identifies each topology update generated by an
originating node. This number is incremented by 1 every time a topology update is generated.
Thus, each topology update contains a Unique Topology Identifier (Topology Update ID and
Source Intranet address) which enables the receiving node to distinguish old and new
information. New information is forward via the following algorithm:

a. Compare the Unique Topology Identifier of the received topology update message with
the one stored in the topology table.

b. If the record is not present, add it to the database, prune the database (see H.4.3 Sparse
routing trees). If the change is included in the sparse routing tree, forward the Topology
Update Message to all one hop neighbors via One-hop multicast address.

c. Else if the topology information contained topology database is lower than the Topology
ID in the Topology Update message, replace the record in the topology database (modulo
rollover from 255 in database to 0 in Topology Update is considered a higher value), and
recalculate the Sparse routing tree. If the received Topology Update has caused a change
in the pruned topology table, forward the topology update via the One-hop Multicast
address.

d. Else if the Topology ID in the database is higher, transmit the database value in a new
message addressed to the source link address of the receive Topology update.

e. Else if the topology ID matches the topology ID in the database do nothing.

H.4.4.1 Topology Update triggers.

Topology updates are triggered for node I by the following:

a. Node I detects a failed link and the link is to a node that is not a static node (link quality
= 7)

b. Node I detects a new or recovered link and the link is to a node that is not a static node
(link quality = 7)

c. Node I detects a change in the quality of a link - applicable only if link costs are used.

d. Node I receives a topology update from another node which modifies its sparse routing
tree.

e. Node I changes its Quiet Mode status and wishes to announce this change.

f. Node I changes its relay capability status.

g. Node I receives a topology update request.

483
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX H

H.4.4.2 Sending Topology Update messages.

Optimally, topology updates should be concatenated with other traffic for queuing by the link
layer. Topology Update Messages are sent to the One-hop multicast address using Type 1
Unnumbered Information Frames which are not acknowledged. The precedence of the Topology
Update Message is user configurable.

The updates should be transmitted no more often than once every MIN_UPDATE_PER.
MIN_UPDATE_PER is measured in minutes and is set by the network administrator when the
nodes are configured. The network administrator can disable topology update transmission by
setting MIN_UPDATE_PER to zero (e.g. via XNP [see TABLE E-XXXIV. Intranet
parameters]), or the MIN_UPDATE_PER may be set manually (e.g., CNRWG parameter tables).
Update packets are superseded by newer packets if they have not been queued at the link layer

H.4.4.3 Sending Topology Update ID indication PDUs.

If a network is using Topology Updates (e.g., MIN_UPDATE_PER is not equal to zero), the
station shall transmit a Topology Update ID indication PDU indicating the most recent Topology
Update ID once every MIN_UPDATE_PER/2 minutes. Optimally the Topology Update ID
indication PDU should be concatenated with other traffic for queuing by the Data Link layer and
should not initiate a transmission. However, if there are no other transmissions awaiting
transmission, the Topology Update ID indication PDU may be transmitted as a single un-
concatenated PDU.

H.4.5 Non-relayers.
In the Topology Update broadcast by non-relayers, the non-relayer indicates its status by setting
the NR bit to one in its entry of the Topology Update message. Additionally, the non-relayer
includes all One-hop, and only One-hop, neighbors (because relaying by this node is not
permitted). Non-relayer nodes remain in the sparse routing trees; however, they shall not have
any subsequent branches. Their entries in the routing table shall have the NR bit set to 1.

H.4.6 Quiet nodes.

Nodes in the quiet state may appear in the sparse routing tables and in update packets with the
QUIET bit set to 1; however, they shall not have any subsequent branches in the routing tree.
Nodes wishing to announce that they are entering quiet mode shall add a separate entry into the
sparse routing table and update packets with NODE ADDRESS and NODE PREDECESSOR set
to their own address and the QUIET bit set to 1.

H.4.7 Topology Update Request messages.

The Topology Update Request Message is triggered whenever there is a mismatch between the
topology update ID received from a station and the value that had been stored previously. The
Topology Update Request message shall be sent whenever a data link transmission is detected
from a previously unknown neighbor. The Topology Update Request message uses a Type 1
Unnumbered Information frame which is not acknowledged and is addressed according to
5.4.1.1.7, 5.4.1.1.9 and 5.4.1.3. The Topology Update Request message is addressed to specific
stations at the Intranet layer and may be sent to the One-hop multicast address at the data link

484
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX H

layer. The precedence of the Topology Update Request Message is user-configurable. The
Topology Update Request Message may be sent no more often than MIN_UPDATE_PER/2.
This constant allows up to two requests to be sent to a node while the node is waiting for the
MIN_UPDATE_PER timer to expire.

485
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX I

SOURCE DIRECTED RELAY

I.1 General.

I.1.1 Scope.
This appendix describes a procedure for relaying packets across a CNR intranet using source
directed routes. The intranet is defined as all processors and CNRs within a single transmission
channel.

I.1.2 Application.
This appendix is a mandatory part of MIL-STD-188-220. The information contained herein is
intended for compliance.

I.1.3 Clarification of examples

I.2 Applicable documents.

None.

I.3 Problem overview.

Intranet relaying is required when nodes in an intranet need to communicate, but are not nearest
neighbors capable of hearing one another’s radio transmissions.

I.4 Procedure.

I.4.1 Forward routing.

Source Directed Relay provides a simple non-dynamic procedure for relaying a packet from an
originator to one or more destinations. The source shall calculate the optimal path through the
intranet network to one or more destinations. The resulting set of source directed routes to reach
every desired destination shall be optimally pruned during encoding into the intranet header such
that they define an associated routing “tree”. If the routes for two or more destinations, as they
are to be encoded into the intranet header, share common links along their paths, those routes
shall be merged together. As a result of this merging process, the resulting subset of paths shall
be encoded into the intranet header such that any common nodes along shared links do not
appear redundantly in the final routing tree encoded in the intranet header (as described in the
following paragraphs).

486
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX I

The address of successive relayers, destinations and their associated status bytes are placed in the
intranet header in order of progressing through the routing tree. Nodes which are one hop away
and destinations only are placed into the Intranet Header first with their DES bit set to 1. The
next entries into the Intranet Header are the relay paths which may include nodes which are
relayers and destinations. Each relay path starting at the source is completed before another
relay path with its origin at the source is begun. Within the status byte for each relayer the REL
bit is set to 1 and S/D is set to 0. If the relayer is also a destination in addition to being a relayer,
the DES bit is set to 1. If there are multiple destinations that are not relayers following a relayer,
each of these destination addresses and their status bytes should be listed in the header after the
relay node sequentially in the order of their appearance in the path. Within this group the
extension bit within the destination/relay address field is not used. The last address can be
determined from the Intranet header length. The last address in a group can be determined from
the DIS field of the Destination/Relay Status Byte defined in 5.4.1.1.7

All destinations in the relay path that are required to provide end-to-end intranet
acknowledgments have set the ACK bit in their status bytes to 1. For all destinations, the
DISTANCE field is set to the number of hops between the originator and the ultimate destination
host for the relay.

I.4.2 End-to-End intranet acknowledgments.

End-to-End intranet acknowledgments are formed by the ith final destination nodes upon receipt
of an intranet header with ACK bit set in DESTINATION STATUS BYTE for the ith
destination. The MESSAGE ID for the packet to be acknowledged is retained. The message
type is set to 1. The path between the originator node and the ith destination is reversed exactly.
Each intermediate node in the reverse path between the originator node and the ith destination
shall be designated as a “relayer only”, regardless of its possible disposition as a destination in
the original intranet header received. The DES bit in the status bytes for all such relayers is set
to 0, indicating they perform relay only. The resulting reverse path for the intranet
acknowledgment shall contain one originator, one destination, and all of the relayers. No data is
carried with an end-to-end acknowledgement packet, just the intranet header.

I.5 Examples.
To illustrate Source Directed Relay procedures consider the sample network link diagram in
FIGURE I-1 and final routing tree in FIGURE I-2. TABLE I-I gives specific addresses for the
nodes labeled A, B, C, D, E, F, G and H. To maintain consistency with other sections of MIL-
STD-188-220, the most significant bit (MSB) is presented to the left of the figures in this
appendix.

487
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX I

E G

A C

F H

Note: Links B-F, D-E and E-H do not exist, due

D to distance or physical obstruction to line-of-sight.

FIGURE I-1. Link diagram of a sample network.

B C D

E E F F

G G G H G H

FIGURE I-2. Final routing tree for node A.

488
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX I

TABLE I-I. Sample node addresses.

Node MSB LSB Address

A 0 0 0 1 1 1 1 x 15
B 0 0 0 0 1 0 0 x 4
C 0 0 0 0 1 0 1 x 5
D 0 0 0 0 1 1 0 x 6
E 0 0 0 0 1 1 1 x 7
F 0 0 0 1 0 0 0 x 8
G 0 0 0 1 0 0 1 x 9
H 0 0 0 1 0 1 0 x 10

I.5.1 Example 1.
Assume that node A has a packet bound for node G alone. Node A’s Sparse Routing Tree
provides the following potential paths to Node G: A-B-E-G, A-C-E-G, A-C-F-G and A-D-F-G.
Assuming that all paths have the same quality and cost, any path may be selected by Node A. In
this example, path A-B-E-G is selected.

The following values are assigned to the Intranet Header in example 1:

MESSAGE TYPE = 4 (IPv4 Packet)

TYPE_OF_SERVICE = 00000000
MESSAGE ID = 1
MAX_HOP_COUNT = 3 (Distance from node A to node G)
ORIGINATOR ADDRESS = 15 (node A)
STATUS BYTE 1 = 00001001 (ACK=No, DES=No, REL=Yes, DIS=1)
DESTINATION 1 = 4 (node B)
STATUS BYTE 2 = 00001010 (ACK=No, DES=No, REL=Yes, DIS=2)
DESTINATION 2 = 7 (node E)
STATUS BYTE 3 = 01000011 (ACK=No, DES=Yes, REL=No, DIS=3)
DESTINATION 3 = 9 (node G)
HEADER LENGTH = 12 octets

FIGURE I-3 shows the complete Intranet Header for example 1. Note that the LSB in all
destination addresses is 0 except for the last destination address (node G).

489
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX I

7 6 5 4 3 2 1 0
MSB LSB
MESSAGE TYPE VERSION NUMBER
0 1 0 0 0 0 0 0
INTRANET HEADER LENGTH
0 0 0 0 1 1 0 0
TYPE OF SERVICE
0 0 0 0 0 0 0 0
MESSAGE IDENTIFICATION NUMBER
0 0 0 0 0 0 0 1
SPARE MAX HOP COUNT
0 0 0 0 0 0 1 1
ORIGINATOR ADDRESS
0 0 0 1 1 1 1 0
DESTINATION/RELAY STATUS BYTE 1
0 0 0 0 1 0 0 1
DESTINATION/RELAY ADDRESS 1
0 0 0 0 1 0 0 0
DESTINATION/RELAY STATUS BYTE 2
0 0 0 0 1 0 1 0
DESTINATION/RELAY ADDRESS 2
0 0 0 0 1 1 1 0
DESTINATION/RELAY STATUS BYTE 3
0 1 0 0 0 0 1 1
DESTINATION/RELAY ADDRESS 3
0 0 0 1 0 0 1 1

FIGURE I-3. Example 1 Intranet Header.

I.5.2 Example 2.
Assume that node A has a packet bound for nodes G and H. Node A’s Sparse Routing Tree
provides the following potential paths to nodes G and H: A-B-E-G, A-C-E-G, A-C-F-G, A-C-F-
H, A-D-F-G and A-D-F-H. Of these potential paths, the most economical choices are those that
use node F for relaying: A-C-F-G, A-D-F-G, A-C-F-H and A-D-F-H. Although paths A-B-E-G
and A-C-E-G are viable paths to node G, they would unnecessarily increase processing at nodes
B and E, and would increase the size of the Intranet Header in this example. In this example the
selected paths are A-C-F-G and A-C-F-H.

The following values are assigned to the Intranet Header in example 2:

MESSAGE TYPE = 4 (IPv4 Packet)

TYPE_OF_SERVICE = 00000000
MESSAGE ID = 2
MAX_HOP_COUNT = 3 (Distance from node A to nodes G and H)
ORIGINATOR ADDRESS = 15 (node A)
STATUS BYTE 1 = 00001001 (ACK=No, DES=No, REL=Yes, DIS=1)

490
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX I

DESTINATION 1 = 4 (node C)
STATUS BYTE 2 = 00001010 (ACK=No, DES=No, REL=Yes, DIS=2)
DESTINATION 2 = 8 (node F)
STATUS BYTE 3 = 01000011 (ACK=No, DES=Yes, REL=No, DIS=3)
DESTINATION 3 = 9 (node G)
STATUS BYTE 4 = 01000011 (ACK=No, DES=Yes, REL=No, DIS=3)
DESTINATION 4 = 10 (node H)
HEADER LENGTH = 14 octets

FIGURE I-4 shows the complete Intranet Header for example 2. Note that the LSB in all
destination addresses is 0 except for the last destination address (node H).

7 6 5 4 3 2 1 0
MSB LSB
MESSAGE TYPE VERSION NUMBER
0 1 0 0 0 0 0 0
INTRANET HEADER LENGTH
0 0 0 0 1 1 1 0
TYPE OF SERVICE
0 0 0 0 0 0 0 0
MESSAGE IDENTIFICATION NUMBER
0 0 0 0 0 0 1 0
SPARE MAX HOP COUNT
0 0 0 0 0 0 1 1
ORIGINATOR ADDRESS
0 0 0 1 1 1 1 0
DESTINATION/RELAY STATUS BYTE 1
0 0 0 0 1 0 0 1
DESTINATION/RELAY ADDRESS 1
0 0 0 0 1 0 0 0
DESTINATION/RELAY STATUS BYTE 2
0 0 0 0 1 0 1 0
DESTINATION/RELAY ADDRESS 2
0 0 0 1 0 0 0 0
DESTINATION/RELAY STATUS BYTE 3
0 1 0 0 0 0 1 1
DESTINATION/RELAY ADDRESS 3
0 0 0 1 0 0 1 0
DESTINATION/RELAY STATUS BYTE 4
0 1 0 0 0 0 1 1
DESTINATION/RELAY ADDRESS 4
0 0 0 1 0 1 0 1

FIGURE I-4. Example 2 Intranet Header.

491
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX I

I.5.3 Example 3.
In the third example, node A wishes to deliver a packet to nodes D, E, F, G and H. In this case
node A again would select the most economical path to each destination, taking into
consideration the impacts on network traffic and Intranet header size. TABLE I-II lists the
potential and selected paths from node A to each of the intended destinations.

A similar process would be used to select economical paths to relay nodes, such as node C. The
shortest path to the most distant nodes G and H are reviewed to determine whether the relay
nodes C and F are also destinations. Note that node F is both a destination and a relay while
node C is a relay node only.

TABLE I-II. Paths used in example 3.

Destination Node Potential Paths Selected Path

D A-D A-D
E A-B-E A-C-E
A-C-E
F A-C-F A-C-F
A-D-F
G A-B-E-G A-C-F-G
A-C-E-G
A-C-F-G
A-D-F-G
H A-C-F-H A-C-F-H
A-D-F-H

The following values are assigned to the Intranet Header in example 3:

MESSAGE TYPE = 4 (IPv4 Packet)

TYPE_OF_SERVICE = 00000000
MESSAGE ID = 3
MAX_HOP_COUNT = 3 (Distance from node A to nodes G and H)
ORIGINATOR ADDRESS = 15 (node A)
STATUS BYTE 1 = 01000001 (ACK=No, DES=Yes, REL=No, DIS=1)
DESTINATION 1 = 6 (node D)
STATUS BYTE 2 = 00001001 (ACK=No, DES=No, REL=Yes, DIS=1)
DESTINATION 2 = 5 (node C)
STATUS BYTE 3 = 01000010 (ACK=No, DES=Yes, REL=No, DIS=2)
DESTINATION 3 = 7 (node E)
STATUS BYTE 4 = 01001010 (ACK=No, DES=Yes, REL=Yes, DIS=2)

492
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX I

DESTINATION 4 = 8 (node F)
STATUS BYTE 5 = 01000011 (ACK=No, DES=Yes, REL=No, DIS=3)
DESTINATION 5 = 9 (node G)
STATUS BYTE 6 = 01000011 (ACK=No, DES=Yes, REL=No, DIS=3)
DESTINATION 6 = 10 (node H)
HEADER LENGTH = 18 octets

FIGURE I-5 shows the complete Intranet Header for example 3. Note that the LSB in all
destination addresses is 0 except for the last destination address (node H).

I.5.4 Relay processing.

Although the separate examples 1, 2, 3 all have diverse paths, they would all require the same
number data link information frames for delivery (one). The UI, I or DIA frame would be
transmitted to each destination simultaneously. Addressed destinations would perform the
required data link layer processing described in 5.3 and pass the information field of the frame to
the Intranet layer for further processing.

The Intranet header is scanned for the node’s data link layer address. When found, the previous
octet - the Destination/Relay Status byte - is inspected. If the Relay bit is not set and the
destination bit is set, the data portion following the Intranet header is passed to the next higher
protocol layer for further processing. If the Relay bit is set, Relay processing is required. If both
the Relay bit and the Destination bit are set, Relay processing is performed before the passing
data portion of the frame to the next higher protocol layer for further processing. Relay
processing shall use the following steps:

a. Scan forward until the relayer node sees its own address. If found continue relay
processing otherwise stop relay processing.

b. Scan toward the end of the header looking for all nodes whose DES bit is set and whose
Distance is one hop greater than your own. Terminate the scan when a distance less than or
equal to your own or the end of the header is found. Save the addresses.

c. While scanning forward until a hop distance less than or equal to your own is found,
find all relay addresses that are one hop away from your address and save these addresses.

d. Remove all duplicate saved addresses and pass the remaining addresses to the data link
layer to form a multi-addressed information frame containing the Intranet header and data.

493
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX I

7 6 5 4 3 2 1 0
MSB LSB
MESSAGE TYPE VERSION NUMBER
0 1 0 0 0 0 0 0
INTRANET HEADER LENGTH
0 0 0 1 0 0 1 0
TYPE OF SERVICE
0 0 0 0 0 0 0 0
MESSAGE IDENTIFICATION NUMBER
0 0 0 0 0 0 1 1
SPARE MAX HOP COUNT
0 0 0 0 0 0 1 1
ORIGINATOR ADDRESS
0 0 0 1 1 1 1 0
DESTINATION/RELAY STATUS BYTE 1
0 1 0 0 0 0 0 1
DESTINATION/RELAY ADDRESS 1
0 0 0 0 1 1 0 0
DESTINATION/RELAY STATUS BYTE 2
0 0 0 0 1 0 0 1
DESTINATION/RELAY ADDRESS 2
0 0 0 0 1 0 1 0
DESTINATION/RELAY STATUS BYTE 3
0 1 0 0 0 0 1 0
DESTINATION/RELAY ADDRESS 3
0 0 0 0 1 1 1 0
DESTINATION/RELAY STATUS BYTE 4
0 1 0 0 1 0 1 0
DESTINATION/RELAY ADDRESS 4
0 0 0 1 0 0 0 0
DESTINATION/RELAY STATUS BYTE 5
0 1 0 0 0 0 1 1
DESTINATION/RELAY ADDRESS 5
0 0 0 1 0 0 1 0
DESTINATION/RELAY STATUS BYTE 6
0 1 0 0 0 0 1 1
DESTINATION/RELAY ADDRESS 6
0 0 0 1 0 1 0 1

FIGURE I-5. Example 3 Intranet Header created by node A (originator).

The following sections discuss the relay processing at each of the downstream relayers in
Example 3. There are two options when filling out the Intranet Header Address Field at the relay
nodes. The relay nodes may copy the Address Field and place it into the relay packet intact or
they may delete the addresses which have no impact on forwarding or return of a network layer
acknowledgment. If the implementer chooses to leave the address field intact, the address field
in FIGURE I-2 is used at every relayer. If the implementer chooses to compress the address

494
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX I

field to save transmitted bytes, the following paragraphs dictate the method for compression.
There is no interoperability problem regardless of which of these two methods are implemented.

I.5.4.1 Relay processing at node C.

Node C is a relay node, but not a destination node. Node C is responsible for relaying the
information to nodes E, F, G and H. Node C assigns the following values to the Intranet Header
in example 3:

MESSAGE TYPE = 4 (IPv4 Packet)

TYPE_OF_SERVICE = 00000000
MESSAGE ID = 3
MAX_HOP_COUNT = 2 (Original MAX_HOP_COUNT - 1)
ORIGINATOR ADDRESS = 15 (node A)
STATUS BYTE 1 = 00001001 (ACK=No, DES=No, REL=Yes, DIS=1)
DESTINATION 1 = 5 (node C)
STATUS BYTE 2 = 01000010 (ACK=No, DES=Yes, REL=No, DIS=2)
DESTINATION 2 = 7 (node E)
STATUS BYTE 3 = 01001010 (ACK=No, DES=Yes, REL=Yes, DIS=2)
DESTINATION 3 = 8 (node F)
STATUS BYTE 4 = 01000011 (ACK=No, DES=Yes, REL=No, DIS=3)
DESTINATION 4 = 9 (node G)
STATUS BYTE 5 = 01000011 (ACK=No, DES=Yes, REL=No, DIS=3)
DESTINATION 5 = 10 (node H)
HEADER LENGTH = 16 octets

FIGURE I-6 shows the complete Intranet Header created by Node C.

I.5.4.2 Relay processing at node F.

Node F is both a destination and a relayer with relay responsibilities to nodes G and H. Node F
assigns the following values to the Intranet Header in example 3:

MESSAGE TYPE = 4 (IPv4 Packet)

TYPE_OF_SERVICE = 00000000
MESSAGE ID = 3
MAX_HOP_COUNT = 1 (Received MAX_HOP_COUNT - 1)
ORIGINATOR ADDRESS = 15 (node A)
STATUS BYTE 1 = 00001001 (ACK=No, DES=No, REL=Yes, DIS=1)
DESTINATION 1 = 5 (node C)
STATUS BYTE 2 = 01001010 (ACK=No, DES=Yes, REL=Yes, DIS=2)
DESTINATION 2 = 8 (node F)
STATUS BYTE 3 = 01000011 (ACK=No, DES=Yes, REL=No, DIS=3)
DESTINATION 3 = 9 (node G)
STATUS BYTE 4 = 01000011 (ACK=No, DES=Yes, REL=No, DIS=3)
DESTINATION 4 = 10 (node H)

495
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX I

HEADER LENGTH = 14 octets

FIGURE I-7 shows the complete Intranet Header created by Node F.

7 6 5 4 3 2 1 0
MSB LSB
MESSAGE TYPE VERSION NUMBER
0 1 0 0 0 0 0 0
INTRANET HEADER LENGTH
0 0 0 1 0 0 0 0
TYPE OF SERVICE
0 0 0 0 0 0 0 0
MESSAGE IDENTIFICATION NUMBER
0 0 0 0 0 0 1 1
SPARE MAX HOP COUNT
0 0 0 0 0 0 1 0
ORIGINATOR ADDRESS
0 0 0 1 1 1 1 0
DESTINATION/RELAY STATUS BYTE 1
0 0 0 0 1 0 0 1
DESTINATION/RELAY ADDRESS 1
0 0 0 0 1 0 1 0
DESTINATION/RELAY STATUS BYTE 2
0 1 0 0 0 0 1 0
DESTINATION/RELAY ADDRESS 2
0 0 0 0 1 1 1 0
DESTINATION/RELAY STATUS BYTE 3
0 1 0 0 1 0 1 0
DESTINATION/RELAY ADDRESS 3
0 0 0 1 0 0 0 0
DESTINATION/RELAY STATUS BYTE 4
0 1 0 0 0 0 1 1
DESTINATION/RELAY ADDRESS 4
0 0 0 1 0 0 1 0
DESTINATION/RELAY STATUS BYTE 5
0 1 0 0 0 0 1 1
DESTINATION/RELAY ADDRESS 5
0 0 0 1 0 1 0 1

FIGURE I-6. Example 3 Intranet Header for node C (relay node).

496
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX I

7 6 5 4 3 2 1 0
MSB LSB
MESSAGE TYPE VERSION NUMBER
0 1 0 0 0 0 0 0
INTRANET HEADER LENGTH
0 0 0 0 1 0 1 0
TYPE OF SERVICE
0 0 0 0 0 0 0 0
MESSAGE IDENTIFICATION NUMBER
0 0 0 0 0 0 1 1
SPARE MAX HOP COUNT
0 0 0 0 0 0 0 1
ORIGINATOR ADDRESS
0 0 0 1 1 1 1 0
DESTINATION/RELAY STATUS BYTE 1
0 0 0 0 1 0 0 1
DESTINATION/RELAY ADDRESS 1
0 0 0 0 1 0 1 0
DESTINATION/RELAY STATUS BYTE 2
0 1 0 0 1 0 1 0
DESTINATION/RELAY ADDRESS 2
0 0 0 1 0 0 0 0
DESTINATION/RELAY STATUS BYTE 3
0 1 0 0 0 0 1 1
DESTINATION/RELAY ADDRESS 3
0 0 0 1 0 0 1 0
DESTINATION/RELAY STATUS BYTE 4
0 1 0 0 0 0 1 1
DESTINATION/RELAY ADDRESS 4
0 0 0 1 0 1 0 1

FIGURE I-7. Example 3 Intranet Header created by node F (relay and destination nodes).

497
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

ROBUST COMMUNICATIONS PROTOCOL

J.1 General.

J.1.1 Scope.
This appendix describes the interoperability and technical requirements for the Robust
Communications Protocol (RCP) for DMTD and interfacing C4I systems (DTEs). This appendix
applies only to HAVEQUICK II compatible systems that require interoperability with radios that
do not have data buffering or synchronization capability.

J.1.2 Application.
This appendix is a mandatory part of MIL-STD-188-220. The information contained herein is
intended for compliance.

J.2 Applicable documents.

JIEO Specification 9120A.

J.3 Introduction.
This physical layer protocol provides the additional processing to aid the transfer of secure and
non-secure digital data when concatenated with the link processing of the MIL-STD-188-220
protocol. The additional processing of this protocol allows for a higher level protocol with an
error correcting capability equal to rate 1/2 Golay to transfer a burst of data containing up to
67,200 data symbols with better than 90% probability of success in a single transmission, this
being over an active HAVEQUICK II compatible link with a random bit error rate of 0.1 or less.
The second goal of this physical protocol is for the required performance to be achieved entirely
in software using current systems with modest processing capability.

J.3.1 Physical protocol components.

Three individually selectable processes are used to meet the performance requirement. The first
is the application of rate 1/3 convolutional coding to combat high random bit error rates. The
second is a provision for data scrambling. Scrambling at the physical layer is implemented
simply as the multiplication of the transmit data with a pseudorandom bit pattern. The third is a
packetizing scheme that allows for the re-transmission of the data that was lost due to an
HAVEQUICK II compatible frequency hop. The re-transmission is performed, and data
recovered within the data burst and the data interruption is transparent to the higher-level
protocol. This packetizing scheme has been dubbed the multi-dwell protocol because it was
formulated to allow a message to be transmitted over multiple HAVEQUICK II compatible hop
dwells.

498
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

J.3.2 Optional rate 1/3 convolutional coding.

The transmitting convolutional encoder generates three output bits for each input information bit.
FIGURE J-1 shows an example of the encoding process for a constraint length (K) of 3. The
encoder consists of a shift register equal in length to the constraint length. The data to encode is
shifted from left to right one bit at a time. After each shift, three output bits are generated using
the G1, G2, and G3 polynomials. The three encoded output bits are generated in the G1, G2, and
G3 order. The G2 output shall be inverted to provide some data scrambling capability. The
convolutional encoding shift register is initialized to a state of zero when a transmission is
requested. The first output bits are generated when the shift register contains the first upper
layer bit to transmit, followed by all zeros. Upon detection of the robust synchronization pattern,
the Viterbi decoder is initialized to make use of the knowledge of the initial encoder shift register
state.

G1 (101) +

Input
1
2 Output

G2 (111) + 3
G3 (111) +

FIGURE J-1. Convolutional encoder with inverted G2 K=3.

TABLE J-I lists the generator polynomials used for the three specified constraint lengths. The
MSBs of the octal representation of each polynomial are used for each polynomial.

TABLE J-I. Convolutional coding generator polynomials (octal).

Constraint Length G1 G2 G3
3 5 7 7
5 52 66 76
7 554 624 764

499
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

FIGURE J-2 shows the relative error correcting capability of rate 1/3 convolutional coding in a
random error environment using the Viterbi decoding algorithm with hard decisions. The
performance was achieved using a trace back buffer length of 16, 32, and 64 for constraint
lengths 3, 5, and 7 respectively. If the demodulator and decoder are components of the same
subsystem, soft decision information from the demodulator can be used to further enhance the
performance.

RATE 1/3 VITERBI DECODE HARD DECISIONS

0.1
BER OUT

K=3

K=5
0.01
K=7

0.001
0.2

0.18

0.16

0.14

0.12

0.1

0.08

0.06

0.04

0.02

CHANNEL BER

FIGURE J-2. Rate 1/3 convolutional coding performance for constraint lengths 3, 5, and 7.

J.3.3 Optional data scrambling.

Physical layer data scrambling shall use the scrambler and descrambler described in FIGURE J-
3. Physical layer data scrambling shall use the pseudo-noise (PN) generator specified in CCITT
V.33 Annex A. Although the generating polynomial used is as specified in CCITT V.33 Annex
A, the process is different. The generating polynomial is 1 + X-18 + X-23. FIGURE J-3 shows the
structure of the data scrambler and descrambler.

500
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

X-1 X-1 …. X-1 X-1 …. X-1

-18
DsX

-23
DsX

Output Data

Input Data

FIGURE J-3. Data scrambler structure.

The data sequence to be transmitted, Dout is formed as follows:

_________________________
Dout = ( Din ) ⊕ ( ( Ds X-18 ) ⊕ ( Ds X-23 ) )

|<---- pseudo noise (PN)----->|

Where Din is the input data. The shift register Ds shall be initialized to zero before the first bit of
data is scrambled on transmission. On data reception, the descrambler shift register Ds shall be
initialized to zero before the first received data bit is descrambled.

Note: symbol ⊕ is XOR operand.

A ⊕ B is A XOR B.

A ⊕ B is A XNOR B.

J.3.4 Optional robust multi-dwell.

J.3.4.1 Multi-dwell packet format.

When the HAVEQUICK II compatible radio is in active mode, multi-dwell packetizing shall be
enabled. The multi-dwell packetizing described in this appendix assumes a physical level bit
rate of 16 kbps. The format of each multi-dwell packet is shown in FIGURE J-4. Each packet
consists of a start of packet (SOP) pattern and a segment counter followed by 6, 11 or 13 64-bit
data segments.

501
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

32 / 64 BIT 15 TO 75 BIT SEG SEG SEG SEGMENT

SOP SEGMENT COUNTER N N+1 N+2 (N+SEG_CNT-1)

BCH (15, 7) *BCH (15, 7) *BCH (15, 7) †BCH (15, 7) †BCH (15, 7)
COPY 1 COPY 2 COPY 3 COPY 4 COPY 5

* - 2:3 and 3:5 Majority Voting

† - 3:5 Majority Voting Only

FIGURE J-4 Multi-dwell packet.

J.3.4.2 Multi-dwell SOP field.

The SOP pattern is a 64-bit (FIGURE J-5) or 32-bit (FIGURE J-6) pattern used for multi-dwell
packet detection. The maximum number of bits in error should be set to match the bit error rate
environment. For normal operation, it is recommended that the maximum number of bits in
error be set to 13 for a 64-bit pattern, and to 3 for a 32-bit pattern. The length of the SOP pattern
shall be determined by bits 2, 3 and 4 of the robust frame format.

MSB LSB
1011101100110101011111100000100101100001010011110100011100100101

FIGURE J-5. Multi-dwell 64-bit SOP pattern.

MSB LSB
01110101110010010000100111000000

FIGURE J-6. Multi-dwell 32-bit SOP pattern.

J.3.4.3 Multi-dwell segment count field.

The segment counter is a modulo 64 count of the first segment in the packet. The six required
bits shall be encoded as 1, 3, or 5 BCH (15,7) codewords depending on bits 2, 3 and 4 of the
robust frame format. The six-bit segment counter shall occupy the 6 LSBs of the seven-bit BCH
data field. The MSB of the data field shall be used as an end-of-frame flag which, when set,
indicates that data transmission is complete. A multi-dwell packet marked with an end-of-frame
flag shall contain only the SOP pattern and the segment count field used to make the segment

502
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

number of the first fill data segment transmitted in the previous packet. If no fill data is included
in the previous segment, the segment count field shall point to the last data segment plus one.

J.3.4.4 Multi-dwell data segments.

Each multi-dwell packet shall contain 6, 11 or 13 consecutive 64-bit data segments. Unless a
channel interruption is detected during the transmission of the packet, each data segment shall
contain the next 64 bits supplied by the data link layer for transmission. The last multi-dwell
packet shall contain pad bits and segments as necessary to complete the packet. The transmitted
pad data shall be an alternating one/zero sequence.

J.3.4.5 Multi-dwell hop detection.

The physical layer shall have the means of detecting or predicting communications link outages.

J.3.4.6 Multi-dwell transmit processing.

Data received from the data link layer for transmission shall be broken into 64 bit segments for
transmission. The data shall be packetized as stated in J.3.4.1. Packets shall be transmitted
consecutively with the segment count field containing the count, modulo 64, of the first segment
in the packet until a communications link outage is detected, at which time, the remainder of the
data segments in the currently transmitted packet shall be filled with an alternating one/zero
pattern. The alternating one/zero pattern shall start soon enough to prevent a receiver from
detecting a SOP header and segment count that would prematurely release segments that have
been corrupted by a frequency hop. If the configurable hop recovery time (HRT), is greater than
the time remaining to complete the transmission of the current packet, the alternating one/zero
sequence shall be extended to the end of the HRT period. If a hop is detected during the multi-
dwell SOP field, multi-dwell segment count field, or during the transmission of the first two
segments, the entire multi-dwell packet shall be retransmitted. The first multi-dwell packet
transmitted in a frame shall not contain the multi-dwell SOP field or multi-dwell segment count
field. It is assumed that the segment count of the first packet is zero. The SOP and the segment
count field shall not be transmitted during a possible frequency hop. The implementation shall
develop an algorithm to establish when possible frequency hops may occur and adjust the timing
of the data transmission to avoid transmitting a header during any possible hop. Refer to 3.3.4.6
(Code Generator) of JIEO Specification 9120A for guidance on developing a frequency hopping
prediction algorithm.

J.3.4.6.1 Hop data recovery time period.

A configurable variable called the HRT shall be used to determine if the fill data transmitted
following a hop shall be extended to ensure that the following multi-dwell synchronization field
can be received. The HRT is defined as the time period from the beginning of the transmitting
radio frequency (RF) synthesizer frequency hop to the time that the bit synchronizer connected
to the receiving radio can reliably demodulate data. Because different hop detection/prediction
methods flag the hop at different times relative to the beginning of the transmitting RF
synthesizer frequency slew, the configured HRT shall be internally adjusted to insure that
different DTEs in a network can all use the same configurable HRT.

503
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

J.3.4.6.2 Data transmitted after a hop.

The multi-dwell packet transmitted directly following a communications link outage shall
retransmit data starting with the 64-bit segment preceding the segment that was being
transmitted when the hop was detected plus sufficient segments to account for the transmitter
pipeline delay if appropriate. If the radios are allowed to drift without being resynchronized by
Time of Day (TOD) transfer or GPS reference it may also be necessary to repeat additional
segments assuming that the transmitter is running slower than the receiver(s). Assuming a
worst-case drift of 1 ppm in opposite directions, the transmitter may have to repeat an additional
segment for each additional 30 minutes (3.6 msec) of drift.

J.3.4.6.3 Termination of transmission.

After the final packet of the frame is transmitted, without a hop detected during a data segment
containing actual data (not fill data), data transmission shall be terminated. To prevent receive
delays caused by the receiver not being able to determine that the last data segment has been
received, a truncated multi-dwell packet shall be sent with the end-of-frame flag set. The
segment count associated with the end-of-frame flag shall mark the first fill data segment
transmitted. If no fill data is included in the previous segment, the segment count field shall
point to the last segment data plus one. FIGURE J-7 depicts two examples of the last packet
transmitted. In the first case, only three segments are included in the last frame of data
(segments 100, 101, and 102) with the first segment being segment number 100. In this
scenario, the segment header following the last frame to contain data will have the “last frame
flag” bit set, and the segment counter will point to segment 103. In the second example, all the
segments in the frame contain data (segment 100 through 105). The segment header following
the last frame containing data will have the “last frame flag” bit set and the segment counter will
point to segment 106. Note: In both examples, the TP timer shall be recalculated based upon
reception of the last bit of the segment counter of the truncated multi-dwell packet.
End of Frame
Flag
Segment Segment
Seg Seg Seg
SOP Counter FILL FILL … FILL SOP Counter 1
100 101 102
(100) (103)
LSB MSBLSB MSBLSB MSBLSB MSBLSB MSB LSB MSBLSB MSB

End of Frame
Flag
Segment Segment
Seg Seg Seg Seg Seg Seg
SOP Counter SOP Counter 1
100 101 102 103 104 105
(100) (106)
LSB MSBLSB MSBLSB MSBLSB MSBLSB MSBLSB MSBLSB MSBLSB MSBLSB MSBLSB MSB

FIGURE J-7. Two transmission examples.

504
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

J.3.4.7 Multi-dwell receive processing.

If the multi-dwell flag was set in the robust synchronization field, the receiver shall buffer the
multi-dwell data packet. The segment count for the first multi-dwell packet in a frame shall be
assumed to be zero. After the last packet bit is received, the receiver shall open the SOP
correlation window. When the SOP pattern is recognized, the segment count shall be decoded
using the combination of majority and BCH decoding specified in the robust synchronization
field. After each new segment count is decoded, the buffered data for data segments lower in
count than the new segment count are passed on to the next higher layer as received bits. The
segments of the newly received packet are then buffered and held until it is verified that the
buffered segments will not be re-transmitted.

J.3.4.7.1 Receive end-of-frame detection.

The data remaining in the multi-dwell receive data buffer shall be provided to the higher-level
protocol when an end-of-frame condition is detected. The end-of-frame condition shall be
determined by the multi-dwell end-of-frame flag. If the end-of-frame flag is not detected before
bit synchronization is lost then all buffered packets shall be released to the upper level protocol
for receive processing.

J.3.4.7.2 Optional soft decision information.

When there is a very high link BER, a SOP pattern may not be recognized or the segment count
may not be correctable. If fewer than three consecutive segment counts cannot be corrected the
correct number of bits shall be supplied to the upper level protocol as to not cause a bit slip, and
consequently, the loss of the remaining data in the frame. If additional forward error correction
is used with multi-dwell, it is suggested that soft decision information is supplied indicating the
low quality of the received data resulting from a missed SOP pattern or an unrecoverable
segment count.

J.3.4.8 Multi-dwell majority logic overhead choice.

The choice of the amount of multi-dwell majority voting (MV) overhead is dependent on the
expected link BER. TABLE J-II gives an estimate of the maximum random BER supported for a
90% probability of passing a single frame of length 1536 bits, 7680 bits, and 67,200 bits with no
errors introduced due to multi-dwell processing.

TABLE J-II. Maximum supported BER.

Segment Count MV 1536 7680 67,200
1 out of 1 0.055 0.03 0.016
2 out of 3 0.14 0.11 0.07
3 out of 5 0.2 0.14 0.12

505
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

J.3.4.9 Multi-dwell overhead.

The multi-dwell protocol introduces an overhead that shall be considered in the network timing
calculations. The overhead is a function of the radio hop rate, the multi-dwell segment count
majority voting choice, and the message length. TABLE J-III gives the equation to calculate the
actual worst-case realized data rate for each hop rate and majority logic combination. The
numbers in TABLE J-III were run with a HRT of 15.625 msec, a maximum radio timing drift
over a 1/2 hour period, an instantaneous data rate of 16000 bits/second. The actual efficiency
will depend upon the exact implementation, therefore the numbers in TABLE J-III should be
used as a guide only. The six-segment multi-dwell packet shall be used for protocol
acknowledgments and other single TDC block messages. The calculated realized data rate shall
be used for the bit rate of all data encapsulated by the multi-dwell protocol.

HOP TABLE-J-III. Multi-dwell overhead

RATE MV 1:1, 11 segments MV 2:3, 13 segments MV 3:5, 13 segments MV 3:5, 6 segments
0 R/((0.3*10(-L*.00003))+1.06) R/((0.3*10(-L*.00003))+1.16) R/((0.2*10(-L*.00003))+1.17) R/((0.1*10(-L*.00003))+1.36)
1 R/((0.6*10(-L*.00003))+1.10) R/((0.6*10(-L*.00003))+1.21) R/((.55*10(-L*.00003))+1.23) R/((0.3*10(-L*.00003))+1.40)
2 R/((0.5*10(-L*.00003))+1.15) R/((0.5*10(-L*.00003))+1.27) R/((0.7*10(-L*.00003))+1.30) R/((0.4*10(-L*.00005))+1.48)
3 R/((0.5*10(-L*.00003))+1.20) R/((0.4*10(-L*.00002))+1.36) R/((0.8*10(-L*.00003))+1.29) R/((0.2*10(-L*.00003))+1.56)
4 R/(1.45) R/(1.51) R/((0.7*10(-L*.00002))+1.46) R/((.07*10(-L*.00002))+1.85)
ALL R/(1.72) R/(1.72) R/(1.96) R/(2.27)

R = the instantaneous data rate

L = the number of bits to be transmitted

J.3.4.9.1 Terminals lacking hop detection.

The ALL case in TABLE J-III is to show the efficiency of the multi-dwell protocol in systems
where the hop cannot be detected due to hardware or software limitations. Since there is no hop
timing information available, the DTE shall assume that the radio will hop at every possible time
slot. In these systems, it is assumed that timing synchronization with the radio will be made by
the detection of the falling edge of the radio delayed push to talk (DPTT) signal provided by the
HAVEQUICK II compatible radio. However, the efficiency of systems that cannot detect and
predict hops in HAVEQUICK II networks will severely limit the data throughput of those
networks. Therefore, all DMTDs shall implement the capabilities to detect radio hops by
monitoring the hop synch output signal from the HAVEQUICK II radio.

J.3.5 Robust Communications Protocol network timing.

The use of the Robust Communications Protocol requires modification to some of the
APPENDIX C Type 3 network timing equations. The bit rate, transmit delays, and receive
processing delays are modified by the robust protocol. For purposes of robust network timing,

506
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

two system bit rates are defined. The first is the channel bit rate which is represented as nc. The
second is the data link bit rate which is represented as nl. As an example, if rate 1/3
convolutional coding is applied at the physical layer and the channel bit rate is 16 kbps, the link
bit rate would be 5.33 kbps. In this example, an external cryptographic device would transmit
the MI field at nc Hz and an internal cryptographic device would transmit the MI field at nl Hz.
The multi-dwell reduction of nl is not deterministic but is bounded. The average multi-dwell nl
is a function of the multi-dwell packet format, the timing of the DTE transmit request in relation
to the radio transmission security (TRANSEC) timing, and the number of bits to be transmitted.
The following Type 3 network access control subfunctions are specified in APPENDIX C:

a. Network busy sensing

b. Response Hold Delay (RHD)

c. Timeout Period (TP)

d. Network Access Delay (NAD)

The following subparagraphs address required modifications to network timing equations

associated with these subfunctions as a result of using the robust communications protocol.

J.3.5.1 Net Busy Sensing.

Because net busy sensing is performed at the physical level, there are no modifications to the net
busy sensing timing or methods when using the robust communications protocol. However,
users should be aware that equipment preamble times (EPRE) are much longer for COMSEC
operation to account for the COMSEC delays when using HAVEQUICK II. The longer
equipment preamble time will result in a significantly longer net busy detect time for COMSEC
operation with HAVEQUICK II than for plain text operation with HAVEQUICK II.

J.3.5.2 Response hold delay.

The additional transmission time required for the Type 3 coupled acknowledgment due to the
robust protocol and the TRANSEC delays are accounted for by inflating the response
transmission time parameter (S) and the EPRE delay, contained in the RHD timing equation for
RHD0. Normally, a receiver is able to determine the length of a received message by decoding
the robust frame format and message headers to determine the robust frame format and whether
the message is using FEC or TDC and adjusting the transmit word count accordingly. For
coupled responses, this information will be known ahead of time in order to reserve sufficient
time for each response. Therefore, if it cannot be guaranteed that the entire acknowledgment can
be transmitted on a single hop dwell all robust Type 3 coupled acknowledgments shall use the
robust frame format 3 (MV 3:5, 6 segments). It should be noted that a multi-dwell format shall
be used unless it is known that the current dwell is “long” because it cannot be assumed that
network ELAG and HRT will allow a non multi-dwell acknowledgment on the shortest
HAVEQUICK II dwell. All other characteristics of the response that will affect its length (e.g.
FEC, TDC) are determined by the network configuration and shall be the same for all users. In

507
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

cases where the dwell length is not know, additional TRANSEC delays shall be accounted for by
assuming the worst-case frequency hopping (Hop_All). In this case, each hop incurs a HRT
delay plus a penalty for backing up and retransmitting two segments of data. From APPENDIX
C, the RHD0 is calculated as follows:

RHD0 = EPRE + PHASING + S + ELAG + TURN + TOL

The actual value of S for acknowledgments is heavily dependent on the network HRT and the
ability of the transmitting node to detect or predict hops. Worst-case S times for HRT values up
to 25 msec for the six acknowledgment cases assuming the Hop_All case are given in TABLE J-
IV. These approximate times, rounded to the nearest 5 msec, can be made much shorter in more
optimum implementations.

TABLE J-IV. Multi-dwell acknowledgment times for Hop_All

assumption.
ACK TYPE S Value
80 bit no convolutional coding 100 msec
168 bit no convolutional coding 100 msec
384 bit no convolutional coding 160 msec
80 bit convolutional coding 225 msec
168 bit convolutional coding 225 msec
384 bit convolutional coding 350 msec

The maximum wait time before beginning any transmission is the maximum initial wait (one
Hop_All interval) plus one hop recovery time for a final S time of:

S = S + (Hop_All period) + HRT

J.3.5.2.1 Multi-dwell response.

Where multi-dwell is used to send the original message at a channel bit rate, nc, of 16 Kbps, all
responses (Type 3 acknowledgments) will be forced to use the robust frame format 3 (MV 3:5, 6
segments) as noted above unless the DTE knows that a single hop dwell will hold the entire
acknowledgment. All nodes in a network shall use the configured EPRE value to determine if
there will be a “long” dwell in which to transmit acknowledgments to determine which
acknowledgment method to use for that network. A multi-dwell acknowledgment is always
required when using an external crypto device.

508
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

J.3.5.2.2 Response transmission example.

FIGURE J-8 shows an example of the timing of an acknowledgment when an external
cryptographic device is used with the HAVEQUICK II radio. The falling edge of the DPTT
signal marks the beginning of a long hop dwell that is long enough to contain the crypto
preamble time.

After the crypto has finished transmitting the MI field, the transmitting DTE begins to supply
data for transmission. Typically, the COMSEC bit synchronization time is not very accurate and
may be long enough to push the MI field to the end of the guaranteed “long” dwell time. For this
reason, the DTE shall wait to start data transmission on the first hop dwell following the long
guaranteed dwell. The end of the guaranteed hop dwell is marked by the first possible hop
following the DPTT. The first bit of the robust start of message (SOM) pattern is transmitted
after the configured HRT. During the transmission of the response, one or more hops may occur.
When the response transmission is complete, the DTE de-asserts the transmit request signal.
The radio will de-assert DPTT after a variable delay (ET1) at a time synchronized with the hop
sequence. After DPTT is de-asserted, the radio RF output remains active and a radio hop will
not occur. This allows for the transmission of the crypto postamble. The radio RF output
remains active for longer than is required for the transmission of the crypto postamble, which is
shown as the ET2 time period in FIGURE J-8. For HAVEQUICK II radios, ET1, crypto
postamble PLUS ET2 equals the transmitter turnaround time, (TTURN = ET1 + ET2), as defined
in APPENDIX C.

509
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

DMTD TRANSMIT
REQUEST

RADIO DPTT
SIGNAL

ENCRYP-
CHANNEL COMSEC COMSEC COMSEC ENCRYPTED FILL ENCRYPTED TED COMSEC RF
TRANSMIT DATA BIT SYNC FRAME SYNC MI DATA RESPONSE ZEROS/
ONES
POSTAMBLE ACTIVE

POSSIBLE
FREQUENCY HOP

CRYPTO TO DMTD
CLOCK ACTIVE
TRANSMIT CLOCK

DMTD TRANSMIT ACKNOWLEDGMENT

FILL DATA
DATA DATA

ACTUAL
KEYTIME WASTED
DELAY C TIME
CRYPTO PREAMBLE TIME
ET1 ET2

HOP SYNCHRONIZATION POSSIBLE CHANNEL HOP ET1 + ET2 ADDITIONAL HAVEQUICK

TIMING REFERENCE HOP RECOVERY TIME TURN AROUND TIME

**NOTE: TIME PERIODS

ARE NOT TO SCALE

FIGURE J-8. HAVEQUICK II external crypto acknowledgment transmission.

J.3.5.2.3 Estimation of multi-dwell nl.

FIGURE J-9 shows an example of the nl data rate for a multi-dwell transmission with a channel
data rate of 16 kbps. This is the worst case data rate reduction which would be experienced with
rate 1/3 convolutional coding, a 64 bit SOP pattern length, and 3 out of 5 majority logic
decoding of the segment count field for the specified HRT. The data rate shown FIGURE J-9 is
the number of link bits to transmit divided by the number of channel bits transmitted times the
nc. Since rate 1/3 convolutional encoding is used in this example, the maximum link data rate
achievable would be 5.33 kbps. For short messages, the radio hop timing at the beginning of the

510
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

transmission has a significant impact on the transmission efficiency. This example uses 13
segments per packet which is the recommended segment per packet count for long transmissions
using 3 out of 5 majority logic. This figure and the equations given in TABLE J-III are given as
an aid for network throughput estimation and should not be used for network timing. The bit
rate estimating equation used in FIGURE J-3 is:

link rate = nc / (0.510(-link bits .00003) + 1.301)

Data Link to Physical Layer bit rate 3/5 MV, Multi-Dwell hop rate 3, with
rate 1/3 convolutional coding. The equation is 0.5 * 10(-L*.00003) + 1.301

4600

4400

4200
x x
4000 x
Link bit rate

x max rate
3800 x avg rate
min rate
3600 x equation
xx
3400 xx
xx
3200 xx
xx
3000
0 50 100 150 200

Link Message Size in 384 bit (TDC blocks)

FIGURE J-9. Link data rate as a function of message size.

J.3.5.2.4 Receive processing delays.

In order to calculate the reference point for the RHD and TP timers, the receiving DTE shall
know the time of arrival of the last bit of the transmission. In order to do this, the data link layer
normally determines the last bit of the transmission after decoding the word count and tags the
arrival of the last data bit from the physical layer. The physical layer receive delays are
dependent on the DTE hardware and software implementation. The two delay components are
processing delays and data pipeline delays. The processing delays are independent of the
received data rate and the pipeline delays are dependent on the data rate. The data rate of all
non-multi-dwell transmissions is known to be either nc or nc/3 dependent on the use of rate 1/3
convolutional coding. The received data rate of a multi-dwell transmission is not known. For
this reason, when a multi-dwell transmission is received, the physical layer shall tag the time of
arrival of the final multi-dwell bit. The physical layer can determine the time of arrival of the
last bit by using the end-of-frame flag which is the MSB in the final multi-dwell segment count
field. A logical signal from the physical layer to the data link layer indicating the message

511
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

completion time is required to insure that the transmitter and receiver(s) use the same reference
point for the calculation of RHD and TP.

The trace back buffer length of the Viterbi decoder introduces a known pipeline delay in the
received data that will be accounted for in the network ELAG. The length of the trace back
buffer is an implementation choice which is dependent on the Viterbi decoder architecture.
Pipeline delay is the time needed to flush the trace back buffer.

J.3.5.3 Timeout Period (TP).

The timeout period is derived from the same equations as described in APPENDIX C.
Modifications to the timeout period are the result of changes to RHD0 and DTE receive
processing delays, which have been addressed in J.3.5.2 and its subparagraphs.

J.3.5.4 NAD.
There are no modifications to the network timing equations associated network access delay.
The network access delay is always an integer number times the Net_Busy_Detect_Time which,
as previously discussed, has not been modified but could be significantly longer due to extended
equipment preamble times, especially for COMSEC operation with HAVEQUICK II.

J.3.6 Application guidance for the HAVEQUICK II link.

J.3.6.1 Frequency hop synchronization.

The HAVEQUICK II TRANSEC timing and the DTE network timing are not synchronized. To
avoid the loss of critical data, such as the cryptographic synchronization and/or the protocol
SOM patterns, the DTE transmission timing shall be synchronized to the frequency hops through
use of hop detection and prediction.

J.3.7 Summary.
The physical layer robust protocol introduces additional transmit and receive delays due to the
robust header and the convolutional decoding pipeline delays. Multi-dwell packetizing
introduces a data rate reduction which varies widely for short transmissions. The HAVEQUICK
II radio introduces variable delays in the keytime delay and the equipment turn-around time. To
maintain network timing using the Type 3 timing equations, the RHD shall be extended by
inflating the S time for a fixed Type 3 acknowledgment transmit frame format for multi-dwell
operation assuming the worst case hop rate (Hop_All). Since the message transmission time is
variable, the time-out period (TP) sync point shall be figured from the final frame flag at the end
of the transmission.

512
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

J.4 PDU construction.

The following examples shall be used to clarify robust PDU transmission order and processing
order (i.e. scrambling, convolutional coding, and formation of packets). The robust protocol
consists of three parts: (1) robust PDU header – robust frame synchronization and setting of the
robust frame format, (2) the PL scrambled or unscrambled and/or convolutional coded user data
and (3) SOPs and segment counters to form packets in accordance with the setting of the multi-
dwell transmission format when the multi-dwell protocol is implemented. In this example, the
MSB (2n bit) of each octet of user data and the MSB of each field is represented with an
italicized font. FIGURE J-10 shows the processing order with convolutional code disabled, no
multi-dwell hope detection and no link outage. The main figure is shown as FIGURE J-10. For
clarity purpose FIGURE J-10 is broken in two parts at the dotted line and shown as FIGURE J-
11 and FIGURE J-12. The connection points are shown as A, B, C and D in FIGURE J-11 and
FIGURE J-12 at the broken section in FIGURE J-10.

J.4.1 Robust PDU header.

The robust PDU header consists of two parts: (1) robust frame synchronization pattern (see
FIGURE 7) and (2) setting of the robust frame format (RFF) (see TABLE I, TABLE II and
TABLE III.). The robust PDU header shall be inserted first when implementing Robust
Communications Protocol. The robust frame format shall be formatted with multi-dwell majority
vote 3 out of 5 BCH [15, 7] coding. The examples show the differences based on the multi-dwell
flag settings to append the rest of the data.

J.4.2 User Data.

The input to the robust protocol is a MIL-STD-188-220 DL PDU. The DL PDU is user data to
the N-1 layer (i.e. robust protocol). PL scrambling and convolutional coding shall be applied to
the user data if selected in the robust frame format. When the robust frame format selects both
scrambling and convolutional coding, the user data is scrambled before the user data is
convolutional coded. The LSB of each octet passed from the data shall be transmitted first.
However, in the following examples, PL scrambling and convolutional coding are not selected,
the user data is not a real DL PDU which reduces coupling between changes in the MIL-STD-
188-220 frame and this example. The example user data is an array of octets counting down 49
– 0.

APPENDIX J

DL Frame DL Frame 1. DL

V.36 Scrambling 2. If Scramble bit set in the Fig.

FEC/TDC FEC/TDC FEC/TDC

Data Block Data Block Data Block 3. If FEC/TDC bits set in the Fig.
(384 bits) (384 bits) (384 bits)

TWC
+
TH

FEC/TDC
HDR
Block
(168 bits)

FEC/TDC
FEC/TDC FEC/TDC FEC/TDC HDR
Data Block Data Block Data Block Block 4. TWC & Data
(384 bits) (384 bits) (384 bits) (168 bits)

5a. PL Scrambling and V.36 Scrambling (item 2.) are

PL Scrambling 5. If Scrambling Flag set in the Table I RFF.
mutual exclusive.

Packet n Packet 3 Packet 2 Packet 1 6. If Multi-Dwell Flag (MDF) set in the Table I RFF.
7. 11/13/6 64-bit segments per packet based on the setting of Muti-dwell
(11/13/6 64-bit (11/13/6 64-bit (11/13/6 64-bit (11/13/6 64-bit transmission format (MDTF) from the Table II.

Packet 2 Seg
RFF
Ctr 10. Segment Counter 8. Robust frame format (RFF) setting from the
(7bit setting (7 Table I.
bits)
s) Packet 1
Last
Packet 4 - Packet (n-
Packet 3
Seg Seg Seg Seg Seg RFF RFF RFF RFF RFF
Ctr & Ctr & Ctr & Ctr & Ctr & + + + + +
11. 1/3/5 copies based on the setting of
BCH BCH BCH BCH BCH BCH BCH BCH BCH BCH 9. RFF formatted with majority vote 3 out of 5 BCH word
MDTF from the Table II.
(15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits)
cp5 cp4 cp3 cp2 cp1 cp5 cp4 cp3 cp2 cp1

L Seg L Seg L Seg L Seg L Seg Seg Seg Seg Seg Seg RFF RFF RFF RFF RFF
Ctr & Ctr & Ctr & Ctr & Ctr & Ctr 1 & Ctr 1 & Ctr 1 & Ctr 1 & Ctr 1 & + + + + +
Last Packet 2 Packet 1 RCP Frame
BCH BCH BCH BCH BCH SOP (64 BCH BCH BCH BCH BCH SOP (64 BCH BCH BCH BCH BCH 12.MDTF=3
(15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (6 64-bit (6 64-bit (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (6 64-bit (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (64 bits)
cp5 cp4 cp3 cp2 cp1 cp5 cp4 cp3 cp2 cp1 cp5 cp4 cp3 cp2 cp1

L Seg L Seg L Seg L Seg L Seg Seg Seg Seg Seg Seg RFF RFF RFF RFF RFF
Ctr & Ctr & Ctr & Ctr & Ctr & Ctr 1 & Ctr 1 & Ctr 1 & Ctr 1 & Ctr 1 & + + + + +
Last Packet 2 Packet 1 RCP Frame
BCH BCH BCH BCH BCH SOP (64 BCH BCH BCH BCH BCH SOP (64 BCH BCH BCH BCH BCH 13. MDTF=2
(15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (13 64-bit (13 64-bit (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (13 64-bit (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (64 bits)
cp5 cp4 cp3 cp2 cp1 cp5 cp4 cp3 cp2 cp1 cp5 cp4 cp3 cp2 cp1

L Seg L Seg L Seg Seg Seg Seg RFF RFF RFF RFF RFF
Ctr & Ctr & Ctr & Ctr 1 & Ctr 1 & Ctr 1 & + + + + +
Last Packet 2 Packet 1 RCP Frame
BCH BCH BCH SOP (64 BCH BCH BCH SOP (64 BCH BCH BCH BCH BCH 14. MDTF=1
(15 bits) (15 bits) (15 bits) (13 64-bit (13 64-bit (15 bits) (15 bits) (15 bits) (13 64-bit (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (64 bits)
cp3 cp2 cp1 cp3 cp2 cp1 cp5 cp4 cp3 cp2 cp1

L Seg Seg RFF RFF RFF RFF RFF

Ctr & Ctr 1 & + + + + +
SOP (32 Last Packet 2 Packet 1 RCP Frame
BCH BCH SOP (32 BCH BCH BCH BCH BCH 15. MDTF=0
(15 bits) bits) (11 64-bit (11 64-bit (15 bits) (11 64-bit (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (64 bits)
cp1 cp1 cp5 cp4 cp3 cp2 cp1

RFF RFF RFF RFF RFF

+ + + + +
All PL Scrambled BCH BCH BCH BCH BCH
RCP Frame 16. MDF
Unscrambled set. in
(15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (64 bits)
cp5 cp4 cp3 cp2 cp1

FIGURE J-10. Robust PDU Construction

526
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

DL Frame DL Frame
1. DL Frames
2 1

V.36 Scrambling Data 2. If Scramble bit set in the Fig. 9.

FEC/TDC FEC/TDC FEC/TDC

Data Block 3 Data Block 2 Data Block 1 3. If FEC/TDC bits set in the Fig. 9.
(384 bits) (384 bits) (384 bits)
TWC
+
TH
FEC/TDC
HDR Block
(168 bits)

FEC/TDC FEC/TDC FEC/TDC FEC/TDC

Data Block 3 Data Block 2 Data Block 1 HDR Block 4. TWC & Data Field
(384 bits) (384 bits) (384 bits) (168 bits)

5. If Scrambling Flag set in the 5a. PL Scrambling and V.36 Scrambling (item 2.) are
PL Scrambling Data
Table I RFF. mutual exclusive.

Packet n (last) Packet 3 Packet 2 Packet 1 7. 11/13/6 64-bit segments per packet based on the
6. If Multi-Dwell Flag (MDF) set in
(11/13/6 64-bit (11/13/6 64-bit (11/13/6 64-bit (11/13/6 64-bit setting of Muti-dwell transmission format (MDTF) from
the Table I RFF.
Segments) Segments) Segments) Segments) the Table II.

Packet 4 - Packet (n-1)

Packet 1
Last Packet Packet 3 Packet 2

FIGURE J-11. Robust PDU Construction (Top Part).

527
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX J

Seg RFF 8. Robust frame format (RFF) setting

10. Segment Counter (7 bits) from the Table I.
Ctr
setting
(7bits)

Packet 2
RFF RFF RFF RFF RFF
Packet 1 + + + + +
9. RFF formatted with majority vote
Seg Seg Seg Seg Seg BCH BCH BCH BCH BCH
(15 bits) (15 bits) (15 bits) (15 bits) (15 bits)
3 out of 5 BCH word
Packet 3 - Packet (n-1) Ctr & Ctr & Ctr & Ctr & Ctr &
Last Packet 11. 1/3/5 copies based on the setting of cp5 cp4 cp3 cp2 cp1
BCH BCH BCH BCH BCH
MDTF from the Table II.
(15 bits) (15 bits) (15 bits) (15 bits) (15 bits)
cp5 cp4 cp3 cp2 cp1

L Seg L Seg L Seg L Seg L Seg Seg Seg Seg Seg Seg RFF RFF RFF RFF RFF RCP
Ctr & Ctr & Ctr & Ctr & Ctr & Last Packet Packet 2 Ctr 1 & Ctr 1 & Ctr 1 & Ctr 1 & Ctr 1 & + + + + +
SOP SOP Packet 1 Frame
BCH BCH BCH BCH BCH (6 64-bit (6 64-bit BCH BCH BCH BCH BCH BCH BCH BCH BCH BCH 12.MDTF=3
(64 bits) (64 bits) (6 64-bit Segments) Sync
(15 bits) (15 bits) (15 bits) (15 bits) (15 bits) Segments) Segments) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits)
cp5 cp4 cp3 cp2 cp1 cp5 cp4 cp3 cp2 cp1 cp5 cp4 cp3 cp2 cp1 (64 bits)

L Seg L Seg L Seg L Seg L Seg Seg Seg Seg Seg Seg RFF RFF RFF RFF RFF RCP
Ctr & Ctr & Ctr & Ctr & Ctr & Last Packet Packet 2 Ctr 1 & Ctr 1 & Ctr 1 & Ctr 1 & Ctr 1 & Packet 1 + + + + +
SOP SOP Frame
BCH BCH BCH BCH BCH (13 64-bit (13 64-bit BCH BCH BCH BCH BCH (13 64-bit BCH BCH BCH BCH BCH 13.MDTF=2
(15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (64 bits) Segments) Segments) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (64 bits) Segments) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) Sync
cp5 cp4 cp3 cp2 cp1 cp5 cp4 cp3 cp2 cp1 cp5 cp4 cp3 cp2 cp1 (64 bits)

L Seg L Seg L Seg Seg Seg Seg RFF RFF RFF RFF RFF RCP
Ctr & Ctr & Ctr & Ctr 1 & Ctr 1 & Ctr 1 & Packet 1 + + + + +
SOP Last Packet Packet 2 SOP Frame
BCH BCH BCH BCH BCH BCH (13 64-bit BCH BCH BCH BCH BCH 14.MDTF=1
(64 bits) (13 64-bit Segments) (13 64-bit Segments) (64 bits) Sync
(15 bits) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits) Segments) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits)
cp3 cp2 cp1 cp3 cp2 cp1 cp5 cp4 cp3 cp2 cp1 (64 bits)

L Seg Seg RFF RFF RFF RFF RFF RCP

Ctr & Ctr 1 & Packet 1 + + + + +
SOP Last Packet Packet 2 SOP Frame
BCH BCH (11 64-bit BCH BCH BCH BCH BCH 15.MDTF=0
(32 bits) (11 64-bit Segments) (11 64-bit Segments) (32 bits) Sync
(15 bits) (15 bits) Segments) (15 bits) (15 bits) (15 bits) (15 bits) (15 bits)
cp1 cp1 cp5 cp4 cp3 cp2 cp1 (64 bits)

RFF RFF RFF RFF RFF RCP

+ + + + +
All PL Scrambled or Frame 16. MDF not
BCH BCH BCH BCH BCH
Unscrambled Data Sync set in RFF
(15 bits) (15 bits) (15 bits) (15 bits) (15 bits)
cp5 cp4 cp3 cp2 cp1 (64 bits)

FIGURE J-12. Robust PDU Construction (Bottom Part).

528
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX K

BOSE - CHAUDHURI - HOCQUENGHEM (15,7) CODING ALGORITHM

K.1 General.

K.1.1 Scope.
This appendix describes a linear block cyclic code capable of correcting any combination of two
or fewer errors in a block of 15 bits.

K.1.2 Application.
This appendix is a conditionally mandatory part of MIL-STD-188-220. It is mandatory for
implementing the Robust Communications Protocol described in APPENDIX J.

K.2 Applicable documents.

This section is not applicable to this appendix.

K.3 BCH (15,7) code.

The BCH (15,7) code is a linear, block, cyclic, BCH code capable of correcting any combination
of two or fewer errors in a block of 15 bits. The generator polynomial for this code is

g(x) = 1 + X4 + X6 + X7 + X8

where g(x) is a factor of X15 + 1

K.3.1 Hardware encoding.

BCH (15, 7) encoding can be performed with an 8 stage feedback shift register with feedback
connections selected according to the coefficients of g(x). A shift register corresponding to the
coefficients of g(x) and containing the shifted information digits is shown in FIGURE K-1.
Suppose that a 7-bit message is to be encoded:

Information vector m = (m0 m1 m2 m3 m4 m5 m6)

Information polynomial m(x) = m0 + m1 x + m2 x2 + m3 x3 + m4 x4 + m5 x5 + m6 x6

m6 is the first digit to be shifted into the register. The horizontal right arrow illustrates its
shifting direction to the right. And the vertical down arrows illustrate their positions of the
feedback connections. The m6 near the horizontal right arrow on the right illustrates the shifted
out digit and feedback digit. The eight (8) parity check digits:

r(x) = r0 + r1x + r2x2 + r3x3 + r4x4 + r5x5 + r6x6 + r7x7

With the seven (7) information digits, x8 m(x) makes a complete code word:

v(x) = r(x) + x8 m(x)

Therefore, the m6 bit is used as LSB and the first bit to be transmitted.

529
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX K

0123456 7 8 9 10 11 12 13 14

0000000 0 m0 m1 m2 m3 m4 m5 m6

Notes:
1. The label 0 to 14 are intentionally set from the left in order to match the order of the polynomial.

FIGURE K-1. Shift register encoder for the BCH (15,7) code.

FIGURE K-2 illustrates its operation by showing the encoding of the information vector
(1000010) to form the code vector (10100101 | 1000010), where the parity check sequence is
shown before the partition and the information sequence after. The information sequence, bits 8
to 14, with eight zeros, bits 0 to 7, after it (place holders for the parity bits to be calculated) is
shifted into the register initially (it is really a 15-bit shift register but only the last eight positions,
bits 7 to 14, correspond to the coefficients of g(x) and contain feedback connections). The
operation of the shift register consists of seven rounds of shift, feedback, and sum operations.
The parity portion of the code vector, bits 7 to 14, can then be read out of the shift register as
shown.

530
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX K

0123456 7 8 9 10 11 12 13 14

0000000 m0 m1 m2 m3 m4 m5 m6
0 1 0 0 0 0 1 0
Shift 000000 0 0 1 0 0 0 0 1 0
Feedback 0 0 0 0
Sum 000000 0 0 1 0 0 0 0 1
Shift 00000 0 0 0 1 0 0 0 0 1
Feedback 1 1 1 1
Sum 00000 1 0 0 1 1 0 1 1
Shift 0000 0 1 0 0 1 1 0 1 1
Feedback 1 1 1 1
Sum 0000 1 1 0 0 0 1 1 0
Shift 000 0 1 1 0 0 0 1 1 0
Feedback 0 0 0 0
Sum 000 0 1 1 0 0 0 1 1
Shift 00 0 0 1 1 0 0 0 1 1
Feedback 1 1 1 1
Sum 00 1 0 1 1 1 0 1 0
Shift 0 0 1 0 1 1 1 0 1 0
Feedback 0 0 0 0
Sum 0 0 1 0 1 1 1 0 1
Shift 0 0 1 0 1 1 1 0 1
Feedback 1 1 1 1
Sum (final) 1 0 1 0 0 1 0 1
r0 r1 r2 r3 r4 r5 r6 r7

FIGURE K-2. Encoding example.

531
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX K

Thus, the code polynomial is:

v(x) = r0 + r1x + r2x2 + r3x3 + r4x4 + r5x5 + r6x6 + r7x7

+ x8 (m0 + m1 x + m2 x2 + m3 x3 + m4 x4 + m5 x5 + m6 x6 )

= 1 + x2 + x5 + x7 + x8 + x13

And the complete code word is:

(r0 r1 r2 r3 r4 r5 r6 r7 m0 m1 m2 m3 m4 m5 m6)

i.e. (101001011000010)
the first bit transmitted

Again, FIGURE K-3 illustrates its operation by showing the BCH (15,7) encoding of the robust
frame format subfield. The setting of robust frame format for the example is with multi-dwell
majority vote 3 out of 5 BCH (15,7) encoding (6 64-bit segments per packet) and no scrambling
or convolutional encoding. The robust frame format information vector is (1101101) to form the
robust frame format code vector (10110110 | 1101101), where the parity check sequence is
shown before the partition and the information sequence after.

0123456 7 8 9 10 11 12 13 14

0000000 m0 m1 m2 m3 m4 m5 m6
0 1 1 0 1 1 0 1
Shift 000000 0 0 1 1 0 1 1 0 1
Feedback 1 1 1 1
Sum 000000 1 0 1 1 1 1 0 1
Shift 00000 0 1 0 1 1 1 1 0 1
Feedback 1 1 1 1
Sum 00000 1 1 0 1 0 1 0 1
Shift 0000 0 1 1 0 1 0 1 0 1
Feedback 1 1 1 1
Sum 0000 1 1 1 0 0 0 0 1

FIGURE K-3. Robust Frame format encoding example.

532
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX K

0123456 7 8 9 10 11 12 13 14

Shift 000 0 1 1 1 0 0 0 0 1
Feedback 1 1 1 1
Sum 000 1 1 1 1 1 0 1 1
Shift 00 0 1 1 1 1 1 0 1 1
Feedback 1 1 1 1
Sum 00 1 1 1 1 0 1 1 0
Shift 0 0 1 1 1 1 0 1 1 0
Feedback 0 0 0 0
Sum 0 0 1 1 1 1 0 1 1
Shift 0 0 1 1 1 1 0 1 1
Feedback 1 1 1 1
Sum (final) 1 0 1 1 0 1 1 0
r0 r1 r2 r3 r4 r5 r6 r7

FIGURE K-3. Robust Frame format encoding example-continued

Thus, the code polynomial is:

v(x) = r0 + r1x + r2x2 + r3x3 + r4x4 + r5x5 + r6x6 + r7x7

+ x8 (m0 + m1 x + m2 x2 + m3 x3 + m4 x4 + m5 x5 + m6 x6)

= 1 + x2 + x3 + x5 + x6 + x8 + x9 + x11 + x12 + x14

And the complete code word is:

(r0 r1 r2 r3 r4 r5 r6 r7 m0 m1 m2 m3 m4 m5 m6)

i.e. (101101101101101)
the first bit transmitted

533
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX K

K.3.2 Hardware/Software decoding.

Because of its special structure (it is completely orthogonalizable in one step), the BCH (15,7)
code can be decoded very efficiently with a majority logic scheme which can be directly
implemented in software or hardware. It is most easily described in terms of the shift register
implementation shown in FIGURE K-4. With gate 2 open and gate 1 closed, the received block
is read into the shift register. The output of the four modulo 2 summers is sampled by the
majority gate and processed as follows: if a clear majority of the inputs are ones (three or more)
then the output is one, otherwise (if two or fewer inputs are ones) the output is zero. This output
is used to correct the last bit of the shift register. The corrected bit is output to the receiver and
feedback through gate 2 as the register is right shifted. The process is now repeated thirteen
times until the last bit is corrected.

GATE 2

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

GATE 1 +

A1 + A2 + A3 + A4 +

4 INPUT MAJORITY GATE

A1 3 11 12 14

A2 1 5 13 14

A3 0 2 6 14

A4 7 8 10 14

FIGURE K-4. BCH (15,7) majority logic decoding.

The parity check matrix H of the BCH (15,7) code as shown in FIGURE K-2 can also be
obtained in systematic form from the generator matrix as shown in FIGURE K-3. The BCH
(15,7) majority logic decoding is derived from the matrix H, FIGURE K-5.

534
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX K

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

1 0 0 0 0 0 0 0 1 1 0 1 0 0 0
0 1 0 0 0 0 0 0 0 1 1 0 1 0 0
0 0 1 0 0 0 0 0 0 0 1 1 0 1 0
H= 0 0 0 1 0 0 0 0 0 0 0 1 1 0 1
0 0 0 0 1 0 0 0 1 1 0 1 1 1 0
0 0 0 0 0 1 0 0 0 1 1 0 1 1 1
0 0 0 0 0 0 1 0 1 1 1 0 0 1 1
0 0 0 0 0 0 0 1 1 0 1 0 0 0 1

FIGURE K-5. BCH (15,7) parity check matrix.

K.3.3 Software encoding.

The BCH (15,7) code is most efficiently encoded in systematic form from the generator matrix
shown in FIGURE K-6.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

1 0 0 0 1 0 1 1 1 0 0 0 0 0 0
1 1 0 0 1 1 1 0 0 1 0 0 0 0 0
0 1 1 0 0 1 1 1 0 0 1 0 0 0 0
G= 1 0 1 1 1 0 0 0 0 0 0 1 0 0 0
0 1 0 1 1 1 0 0 0 0 0 0 1 0 0
0 0 1 0 1 1 1 0 0 0 0 0 0 1 0
0 0 0 1 0 1 1 1 0 0 0 0 0 0 1
Parity Identity

FIGURE K-6. BCH (15,7) generator matrix.

The BCH(15,7) encoding of the robust frame format subfield as specified in the example of
FIGURE K-2 is shown below.

535
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX K

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
g1 1 0 0 0 1 0 1 1 1 0 0 0 0 0 0
g2 1 1 0 0 1 1 1 0 0 1 0 0 0 0 0
g3 0 1 1 0 0 1 1 1 0 0 1 0 0 0 0
G= g4 1 0 1 1 1 0 0 0 0 0 0 1 0 0 0
g5 0 1 0 1 1 1 0 0 0 0 0 0 1 0 0
g6 0 0 1 0 1 1 1 0 0 0 0 0 0 1 0
g7 0 0 0 1 0 1 1 1 0 0 0 0 0 0 1

The BCH(15,7) code vector:

v = m (dot product) G

g1
g2
g3
= (m0 m1 m2 m3 m4 m5 m6) (dot product) g4
g5
g6
g7

Thus, the robust frame format code vector for robust frame format subfield m (1101101) is:

1 (dot product) (1 0 0 0 1 0 1 1 1 0 0 0 0 0 0)
+ 1 (dot product) (1 1 0 0 1 1 1 0 0 1 0 0 0 0 0)
+ 0 (dot product) (0 1 1 0 0 1 1 1 0 0 1 0 0 0 0)
v= + 1 (dot product) (1 0 1 1 1 0 0 0 0 0 0 1 0 0 0)
+ 1 (dot product) (0 1 0 1 1 1 0 0 0 0 0 0 1 0 0)
+ 0 (dot product) (0 0 1 0 1 1 1 0 0 0 0 0 0 1 0)
+ 1 (dot product) (0 0 0 1 0 1 1 1 0 0 0 0 0 0 1)

i.e. v= (1 0 1 1 0 1 1 0 1 1 0 1 1 0 1)

536
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX K

Then, the complete robust frame format BCH(15,7) code word is:

(101101101101101)
the first bit transmitted

This is the same code vector obtained in the robust frame format encoding example, FIGURE K-
2.

537
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX L

TRANSMISSION CHANNEL INTERFACES

L.1 General.

L.1.1 Scope.
This appendix describes transmission channel interfaces for DMTD and interfacing C4I systems.

L.1.2 Application.
This appendix is a mandatory part of MIL-STD-188-220. The information contained herein is
intended for compliance.

L.2 Applicable documents.

a. MIL-STD-188-110 Equipment Technical Design Standards for

Common Long Haul/Tactical Data Modems

b. MIL-STD-188-114A Electrical Characteristics of Digital Interface

Circuits

c. MIL-STD-188-200 System Design and Engineering Standards

for Tactical Communications

d. CCITT V.10 Electrical Characteristics for Unbalanced

Double-Current Interchange Circuits for
General Use with Integrated Circuit
Equipment in the Field of Data
Communications

e. CCITT X.21 Interface Between Data Terminal Equipment

(DTE) and Data Circuit-Terminating
Equipment (DCE) for Synchronous
Operation on Public Data Networks
L.3 Definitions.
Refer to Section 3 of the main document.

L.4 Detailed requirements.

L.4.1 Transmission Channel Interfaces.

The transmission channel interfaces specified below define the transmission envelope
characteristics (signal waveform, transmission rates, and operating mode) authorized at the
standard interface between a DMTD and the transmission channel. The transmission channel
may consist of wireline, satellite, or radio links.

538
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX L

L.4.1.1 Non-Return-to-Zero (NRZ) interface.

A NRZ signal waveform shall be used for this interface. This interface is used primarily with
digital transmission equipment.

L.4.1.1.1 Waveform.
The NRZ unbalanced and balanced waveforms shall conform to 5.1.1.7 and 5.2.1.7, respectively,
of MIL-STD-188-114A.

L.4.1.1.2 Transmission rates.

The output transmission rates of the NRZ interface shall be the following bit rates: 75, 150, 300,
600, 1200, 2400, 4800, 9600, and 16000 bits per second (bps).

L.4.1.1.3 Operating mode.

The NRZ interface shall support half-duplex transmission.

L.4.1.2 Frequency-Shift Keying (FSK) interface for voice frequency channels.

This interface may be used. It is primarily associated with analog single-channel [3-kilohertz
(KHz)] radio equipment. The FSK data modem characteristics shall conform to 5.2.2 of MIL-
STD-188-110.

L.4.1.2.1 Waveform.
The FSK modulation waveform shall conform to 5.2.2.1 of MIL-STD-188-110. The
characteristic frequencies, in hertz (Hz), for transmission rates of 600 bps or less, and 1200 bps,
shall be as shown in TABLE L-I.

TABLE L-I. Characteristic frequencies of FSK interface for voice frequency channels.

CHARACTERISTIC FREQUENCY (Hz)

PARAMETER 600 bps or less 1200 bps
Mark Frequency 1300 1300
Space Frequency 1700 2100

L.4.1.2.2 Transmission rates.

Output transmission rates of the FSK interface shall be the following bit rates: 75, 150, 300, 600,
and 1200 bps.

L.4.1.2.3 Operating mode.

The FSK interface shall support half-duplex transmission.

539
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX L

L.4.1.3 Frequency-Shift Keying (FSK) interface for single-channel radio.

This interface, used within DoD, may also be used for North Atlantic Treaty Organization
(NATO) single-channel radio applications. The FSK interface data modem characteristics shall
conform to 5.1 of MIL-STD-188-110.

L.4.1.3.1 Waveform.
The FSK modulation waveform shall conform to 5.1.1 and 5.1.2 of MIL-STD-188-110. The
characteristic frequencies shall be as specified in TABLE L-II.

TABLE L-II. Characteristic frequencies of FSK interface for single-channel radio.

PARAMETER CHARACTERISTIC
FREQUENCY (Hz)
Mark Frequency 1575
Space Frequency 2425

L.4.1.3.2 Transmission rates.

Output transmission rates of the single-channel FSK interface shall be the following bit rates: 75,
150, 300, 600, and 1200 bps.

L.4.1.3.3 Operating mode.

The single-channel FSK interface shall support half-duplex transmission.

L.4.1.4 Conditioned Diphase (CDP) interface.

This interface may be used. It is primarily associated with wideband wireline equipment.

L.4.1.4.1 Waveform.
The CDP modulation waveform shall conform to 5.4.1.4 of MIL-STD-188-200. The unbalanced
and balanced signal waveform shall conform to 5.1.1.7 and 5.2.1.7, respectively, of MIL-STD-
188-114A.

L.4.1.4.2 Transmission rates.

The output transmission rate of the CDP interface shall be 16 and 32 kilobits per second (kbps).

L.4.1.4.3 Operating mode.

The CDP interface shall support half-duplex transmission.

L.4.1.5 Differential Phase-Shift Keying (DPSK) interface for voice frequency channels.
This interface may be used. It is primarily associated with analog (nominal 4-KHz voice
frequency) wireline and radio equipment. DPSK modulation data modem (2400 bps) and phase-
shift keying (PSK) modulation data modem (1200 bps) characteristics shall conform to the
applicable requirements of MIL-STD-188-110.

540
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX L

L.4.1.5.1 Waveform.
The DPSK modulation waveform shall conform to APPENDIX A of MIL-STD-188-110. The
PSK modulation waveform shall conform to 5.3 of MIL-STD-188-110.

L.4.1.5.2 Transmission rates.

The output transmission rate of the DPSK and PSK interfaces shall be 2400 and 1200 bps,
respectively.

L.4.1.5.3 Operating mode.

The DPSK and PSK interfaces shall support half-duplex transmission.

L.4.1.6 Packet mode interface.

This interface may be used. If present, this interface shall use a modified CCITT X.21 half-
duplex synchronous interface, with a CCITT V.10 electrical circuit, for transferring data across
the interface between data terminal equipment (DTE) (i.e. the DMTD or C4I system) and data
circuit-terminating equipment (DCE).

L.4.1.6.1 Waveform.
The electrical characteristics of the packet mode interface shall be identical to CCITT V.10 for
interfaces to voice band modems.

L.4.1.6.2 Transmission rates.

The DTE device shall be required to accept signal timing from the DCE (radio) at 16 kbps. The
DTE shall be required to synchronize to the DCE signal timing and accept data at the supplied
signaling timing rate. In the packet mode, the radio provides signal timing to support 16 kbps
data transfers between the radio and the DTE.

L.4.1.6.3 Operating mode.

The packet mode interface shall support half-duplex transmission.

L.4.1.7 Amplitude Shift Keying (ASK) interface.

This interface is used primarily with analog voice grade radios to transmit digital data.

L.4.1.7.1 Waveform.
The ASK waveform is a band limited NRZ waveform with average white Gaussian noise added
to it. The ASK signal shall be a bipolar signal nominally centered around ground. However due
to the radio automatic gain control performance, the ASK signal may have a direct current (DC)
component. The ASK signal-to-noise ratio (S/N) shall be in the range of 0 to 12 decibels (dB).
The ASK signal shall be demodulated using an optimal bit synchronizer with a bit error rate
(BER) performance of 1.5 dB from theoretical.

541
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

APPENDIX L

L.4.1.7.2 Transmission rates.

The output transmission rates of the ASK interface shall be the following bit rates: 2400, 4800,
9600 and 16000 bps.

L.4.1.7.3 Operating mode.

The ASK interfaces shall support half-duplex transmission.

542
Downloaded from http://www.everyspec.com

MIL-STD-188-220D w/ Change 1

CONCLUDING MATERIAL

a. Preparing activity:
US Army CECOM Life Cycle Management Command (USA CECOM LCMC):
CR1

b. Custodians:
Army: CR1
Navy: OM
Air Force: 02
DISA: DC1

c. Review activities:
OSD: IR, SE
Army: AC, CR, MI, PT
Navy: CG, EC, MC, NC
Air Force: 11, 13, 93, 99
DCMA: CM
DISA: DC5
NIMA: MP
DIA: DI
NSA: NS
NORAD &
USSPACECOM: US

d. Project number:
TCSS-2007-006

e. NOTE:
The activities listed above were interested in this document as of the date of this document.
Since organizations and responsibilities can change, you should verify the currency of the
information above using the ASSIST Online database at http://assist.daps.dla.mil.

543

HF Radio Systems Interoperability Standards
No ratings yet
HF Radio Systems Interoperability Standards
370 pages
Mil STD 2045 - 47001D
No ratings yet
Mil STD 2045 - 47001D
319 pages
Mil STD 188 - 165B
No ratings yet
Mil STD 188 - 165B
43 pages
Mil STD 188 220
No ratings yet
Mil STD 188 220
190 pages
Mil STD 188 141D
0% (1)
Mil STD 188 141D
370 pages
MIL-STD-188-141B Overview and Standards
No ratings yet
MIL-STD-188-141B Overview and Standards
584 pages
Mil STD 188 181a
No ratings yet
Mil STD 188 181a
61 pages
DoD Radio Standards Update
No ratings yet
DoD Radio Standards Update
240 pages
Military Data Modem Standards
No ratings yet
Military Data Modem Standards
135 pages
Stanag 5066TP
100% (1)
Stanag 5066TP
833 pages
Tactical Communications Protocol 2
100% (2)
Tactical Communications Protocol 2
111 pages
Mil STD 188 110D
No ratings yet
Mil STD 188 110D
270 pages
Mil STD 188 164C
No ratings yet
Mil STD 188 164C
37 pages
02 Standards Rev Process
No ratings yet
02 Standards Rev Process
23 pages
MIL 416 F
No ratings yet
MIL 416 F
269 pages
Mil STD 461F
No ratings yet
Mil STD 461F
269 pages
Mil STD 461g
No ratings yet
Mil STD 461g
280 pages
DoD Data Modem Standards
No ratings yet
DoD Data Modem Standards
137 pages
Data Modems
No ratings yet
Data Modems
137 pages
MIL-STD-31000B Technical Data Package
No ratings yet
MIL-STD-31000B Technical Data Package
35 pages
Mil STD 461F
No ratings yet
Mil STD 461F
269 pages
MIL-STD-461F: EMI Control Standards
No ratings yet
MIL-STD-461F: EMI Control Standards
269 pages
Standard Overview: Object Model
No ratings yet
Standard Overview: Object Model
11 pages
Mil HDBK 1553
100% (1)
Mil HDBK 1553
678 pages
Mil STD 1553c - Dokuman
No ratings yet
Mil STD 1553c - Dokuman
52 pages
Ida Ts cm2 I1
No ratings yet
Ida Ts cm2 I1
28 pages
Protocolo CD-2
No ratings yet
Protocolo CD-2
36 pages
Mil-Std 11991B
No ratings yet
Mil-Std 11991B
221 pages
AD1172798
No ratings yet
AD1172798
19 pages
Department of Defense Interface Standard
No ratings yet
Department of Defense Interface Standard
272 pages
Cjcsi 6241.04D
No ratings yet
Cjcsi 6241.04D
20 pages
Mil-Std-461g (11dec15)
No ratings yet
Mil-Std-461g (11dec15)
280 pages
AU680 - AU480 Online LAN Specification - Ver.1
100% (1)
AU680 - AU480 Online LAN Specification - Ver.1
94 pages
C.S0002 A 1 PDF
No ratings yet
C.S0002 A 1 PDF
454 pages
International Organization For Standardization (Iso) Standards
No ratings yet
International Organization For Standardization (Iso) Standards
8 pages
MIL-STD-461F: EMI Control Standards
No ratings yet
MIL-STD-461F: EMI Control Standards
269 pages
Mil STD 1553B
No ratings yet
Mil STD 1553B
44 pages
Unit-3 Iot
No ratings yet
Unit-3 Iot
17 pages
Doc9705 Ed2 1999
No ratings yet
Doc9705 Ed2 1999
1,204 pages
IOT Unit 3
No ratings yet
IOT Unit 3
67 pages
Mil STD 462D
No ratings yet
Mil STD 462D
203 pages
Military vs. Commercial EMC Standards
100% (1)
Military vs. Commercial EMC Standards
218 pages
MIL-STD-461E vs. Commercial Standards
No ratings yet
MIL-STD-461E vs. Commercial Standards
218 pages
DoD Electromagnetic Interference Guide
No ratings yet
DoD Electromagnetic Interference Guide
253 pages
Mil-Std-461e
No ratings yet
Mil-Std-461e
253 pages
JANUS Underwater Comm Protocol
No ratings yet
JANUS Underwater Comm Protocol
4 pages
Tesis Doctoral Antenas Fractales
No ratings yet
Tesis Doctoral Antenas Fractales
218 pages
LPC Vocoder Speech Processing in MATLAB
No ratings yet
LPC Vocoder Speech Processing in MATLAB
16 pages
Vishay N-Channel MOSFETs Specifications
No ratings yet
Vishay N-Channel MOSFETs Specifications
5 pages
MANUAL USUARIO STM32cubeMX
No ratings yet
MANUAL USUARIO STM32cubeMX
345 pages
Mini Project2
No ratings yet
Mini Project2
35 pages
(Ebook) Introduction To Modern Cryptography by Jonathan Katz, Yehuda Lindell ISBN 9781466570269, 1466570261 Download
100% (1)
(Ebook) Introduction To Modern Cryptography by Jonathan Katz, Yehuda Lindell ISBN 9781466570269, 1466570261 Download
48 pages
PHD Dissertation Electrical Engineering
100% (2)
PHD Dissertation Electrical Engineering
7 pages
PQ167 Quick Start: Using The Pq100 Immediately
No ratings yet
PQ167 Quick Start: Using The Pq100 Immediately
16 pages
WhatsApp Media Access Denied Error
No ratings yet
WhatsApp Media Access Denied Error
1 page
R08791 Modelingandsimulat Objec VE:: L TP C 3 3 To
No ratings yet
R08791 Modelingandsimulat Objec VE:: L TP C 3 3 To
1 page
Restore Drawings After Bad Numbering - Tekla User Assistance
No ratings yet
Restore Drawings After Bad Numbering - Tekla User Assistance
7 pages
ANSI-C12.22-2008 Protocol Specification For Interfacing To Data Communication Networks
100% (1)
ANSI-C12.22-2008 Protocol Specification For Interfacing To Data Communication Networks
218 pages
Classical Fortran 1st Edition Michael Kupferschmid PDF Download
100% (3)
Classical Fortran 1st Edition Michael Kupferschmid PDF Download
57 pages
Mlops Syllabus
No ratings yet
Mlops Syllabus
2 pages
Java Backend Development Course Overview
0% (1)
Java Backend Development Course Overview
15 pages
Unite 200 PTZ Camera
No ratings yet
Unite 200 PTZ Camera
2 pages
Datasheet-DDR3L 1600 U-DIMM - R-DIMM - SO-DIMM-20160923
No ratings yet
Datasheet-DDR3L 1600 U-DIMM - R-DIMM - SO-DIMM-20160923
2 pages
Course File IoT Applications 4 1 IoT 20CS41006
No ratings yet
Course File IoT Applications 4 1 IoT 20CS41006
87 pages
AD182v@SAP TechEd 2023 Final RAP Extensibility JS
No ratings yet
AD182v@SAP TechEd 2023 Final RAP Extensibility JS
27 pages
Question Paper Bit2034 Object-Oriented Analysis Design - Prof Adnan
No ratings yet
Question Paper Bit2034 Object-Oriented Analysis Design - Prof Adnan
5 pages
Gauri STC Report
No ratings yet
Gauri STC Report
20 pages
Free PowerPoint Business Model Presentation Slide Template
No ratings yet
Free PowerPoint Business Model Presentation Slide Template
15 pages
32W Hi-Fi Audio Power Amplifier: Description
No ratings yet
32W Hi-Fi Audio Power Amplifier: Description
13 pages
HDC 3200
No ratings yet
HDC 3200
8 pages
MODULE-4 RM Vipul 2
No ratings yet
MODULE-4 RM Vipul 2
18 pages
Promozione Banca Dati Uk
No ratings yet
Promozione Banca Dati Uk
3 pages
w01 LectureSlices MA4550
No ratings yet
w01 LectureSlices MA4550
36 pages
Net Framework
No ratings yet
Net Framework
18 pages
ETABS Floor Seismic and Wind Acceleration - Computers and Structures - ETABS - Eng-Tips
No ratings yet
ETABS Floor Seismic and Wind Acceleration - Computers and Structures - ETABS - Eng-Tips
3 pages
Ministry Roster Management and Correction System 240308 122908
No ratings yet
Ministry Roster Management and Correction System 240308 122908
35 pages
0a595f08a83beba7bc3b6987606a2507
No ratings yet
0a595f08a83beba7bc3b6987606a2507
4 pages
Linear Programming (Graph Method)
No ratings yet
Linear Programming (Graph Method)
16 pages
How To Install Android 6.0.1 Marshmallow CM13 (Haida) LegacyXperia ROM On Sony Ericsson Xperia Neo V MT11i (Simple Steps) - Android Biits
No ratings yet
How To Install Android 6.0.1 Marshmallow CM13 (Haida) LegacyXperia ROM On Sony Ericsson Xperia Neo V MT11i (Simple Steps) - Android Biits
3 pages
RCBC Deposit Slip Sample Form
No ratings yet
RCBC Deposit Slip Sample Form
1 page