SDA Tranche 0 Communications Protocol (DRAFT).docx

Tranche 0 (T0) Optical Communications Protocol

Developed by the

Space Development Agency

Office of the Under Secretary of Defense Research and Engineering (USD(R&E)) 3030 Defense Pentagon Washington, D.C. 20301

Email: OSD.SDA.Outreach@mail.mil

DISTRIBUTION A: Approved for Public Release: Distribution Unlimited

Revision History

Table of Contents

Introduction The purpose of this document is to define the SDA Tranche 0 Protocol. This protocol was developed as an interoperability specification in SDA’s Tranche 0 program. SDA has since expanded the interface specifications. The SDA Optical Communications Standard (OCS) is intended to provide the specifications for optical communications systems employed by the Space Development Agency (SDA) and its partners. The scope of optical communication links supported includes space-to-space (S2S, a.k.a. Optical Intersatellite Links or OISLs), space-to-air (S2A), space-to-maritime (S2M), and space-to-ground (S2G) optical communications.

The initial OISL Standard was published in early 2020 in preparation for the first iteration of the SDA spiral development process: Tranche 0. SDA’s Tranche 0 (T0) program added sufficient detail to the initial OISL Standard as to enable demonstration of multi-vendor interoperability. Since early 2020, significant advancements have been made across the OCT market.

These advancements have prompted the addition of several protocols to the OISL Standard. The change in this document’s scope prompted the document’s renaming as S2G, S2M, and S2A do not fit into the moniker “Optical Intersatellite Link.” The Optical Communications Standard is intended to provide a framework for the engineering of systems that will provide optical communications where at least one endpoint is a space-based terminal. This document provides the interface specification required to implement an OCT that will be interoperable with SDA Tranche 0.

Normative Text The following conventions apply for the normative specifications in this Specification:

a. the words ‘shall’ and ‘must’ imply a binding and verifiable specification

b. the word ‘should’ implies an optional, but desirable, specification

c. the word ‘may’ implies an optional specification

d. the words ‘is’, ‘are’, and ‘will’ imply statements of fact

Protocol Modulation The data modulation shall be On-Off-Keying Non-Return-to-Zero (OOK-NRZ).

OISLs shall implement a communications channel with a baud rate of 312.5 MHz which shall be frequency locked to an external 10 MHz reference clock to be provided by the bus. Additional baud rates of 625 MHz and 1,250 MHz should be supported. Further communications channels with baud rates of 2,500MHz, 5,000MHz, and 10,000MHz may be supported.

Prior to application of the AM tracking tone, the data modulation shall have an Extinction Ratio greater than 9 dB.

Tracking Tone Each TX data sequence shall be further modulated with an AM Tracking Tone. The AM Tracking Tone’s modulation frequency shall be 40 kHz when the OISL is configured for transmitting wavelength A and shall be 50 kHz when the OISL is configured for transmitting wavelength B.

The nominal AM Tracking Tone Modulation Index (MI) should be 10%, where the MI is defined as:

as shown in Figure 1 below. The AM Tracking Tone:

· Shall be either sinusoidal or a square wave

· Shall have a modulation frequency accuracy of at least 500 PPM

· The AM Tracking Tone shall be remotely controllable

· The tone shall be controllable (turned on and off) through remote software command

· The tone’s definition shall be controllable through remote software including:

· Pmax

· Modulation Index

· Tone Frequency

Figure 1: AM Tone Tracking Modulation Framing, Coding, Encapsulation Framing Structure Transmitted frames used by the OISL modem shall adhere to the structure shown in Table 1.

All transmitted frames in the OISL modem shall be constructed identically: a preamble sequence concatenated with a fixed-length header followed by a fixed-length payload carrying information bits.

After framing and coding, the constituent bits shall be serialized and encoded with line product code (LPC), of rate R=16/24, which actively manages the disparity between the transmitted number of logical ones and zeros.

A frame construction and encoding summary is shown in Figure 6.

Table 1: Modern Frame Summary

The MSB (72nd) bit is transmitted first followed in order down to the LSB (1st)

Transmission of modem frames shall be synchronous with no pauses between frames and no pauses between any of the bits comprising the frame components in Table 1. From the values in Table 1, the total frame size shall be 72+384+24480=24936 bits.

Preamble Sequence Every frame shall begin with a Preamble Sequence (PS), which shall be used by the receiving modem for frame synchronization. The preamble sequence shall be identical for all OISL modem frames and shall take the value shown in Table 1.

Header A modem header shall be present in every modem frame immediately following the preamble sequence. The OISL modem frame header shall have these characteristics:

· Modem headers shall be a fixed size (i.e., number of coded bits) for all configurations

· Modem headers shall be protected by a Forward Error Correction (FEC) scheme with a fixed code rate (Section 2.2.1.3.2)

· The payload of the modem header shall be protected by a CRC-16 (Section 2.2.1.3.1).

· The modem header shall implement the signaling required for the modem features in Table 1.

Header Fields The frame Header fields are listed in Table 2. Exactly one Header shall be present in every modem frame.

Table 2: Frame Header Fields

01: DATA

10: MGMT

11: reserved

reserved

Total

Frame Sequence Numbers The TX frame sequence number (TXFN, Table 2) shall be incremented on every transmitted frame in link session without regard to the FRAME_TYPE. The RX frame sequence number (RXFN) is valid only if pared with an ACK. If ACK valid is zero, then RXFN shall be set to zero.

Automatic Repeat Request (ARQ) Header fields supporting implementation of the Automatic Repeat Request modem feature are grouped as the “ARQ” fields in Table 2. The ARQ configuration parameters shall remain static for the duration of a session. The ARQ configuration shall only be changed prior to the onset of acquisition. ARQ operation shall be applied to the space-to-ground links.

Only DATA and MGMT frames shall be subject to ARQ. The receive terminal is only required to ACK frames received correctly. Successful reception of a frame is defined as the payload CRC-32 passing. The receive terminal shall treat frames for which an ACK is not explicitly received as NAK’d.

For terminals that support ARQ, the receive terminal shall support configurable ARQ parameters including holdoff time between re-transmissions of 0-20 milliseconds and maximum number of re-transmission attempts of 0-5. Holdoff time and the number of re-transmission attempts shall be controllable with software.

ARQ shall be disabled by setting the number of re-transmission attempts to zero.

Timestamps The TX PHY shall apply a timestamp in the header of every modem frame (TX_TS field, TOD_SECONDS Table 2). The implementation shall reference the applied timestamp to the egress point of the rising edge of the first bit of the modem frame (exiting the aperture). The TS-applies header bit indicates if the TS applies to current frame (0) or preceding frames (1-7).

Fast Control Channel (FCCH) The OISL modem frame shall provide an embedded fast control channel (FCCH). The FCCH is a low- rate channel with reserved bandwidth for robust, low-latency transport of short messages between OISL terminals. The FCCH enjoys the benefit of both error detection (via the Header CRC) and error correction (via the Header FEC) by virtue of residing in the frame Header. No ARQ is provided for the FCCH channel.

The FCCH physical channel shall be time-multiplexed:

· FCCH_OPCODE (4 bits): opcode which determines the format of the FCCH payload

· FCCH_PL (16 bits): payload bits A single FCCH shall be transmitted and received in every frame and can be valid for every FRAME_TYPE (Table 3 and Section 1.1.1.2).

The higher layers of the modem divide the capacity of the FCCH physical channel into multiple logical channels through time-multiplexing. The effective average data rate of these logical channels is a function of the payload FEC, baud rate, and the frequency of which the logical channel is scheduled by the modem higher layers. The FCCH logical channels are defined in Table 3. If no data is waiting for transport, the FCCH opcode 1111 shall be specified. In this case the FCCH payload bits shall be all logical ones. Payload values for Reserved opcodes shall be all logical zeros.

Table 3: FCCH Logical Channels

The payload for each FCCH message shall be 16 bits. Payloads for each of the FCCH_TYPES are defined in Table 7.

Table 4: FCCH Payloads

(trailing 1 sec from 1 PPS)

(average, trailing 1 sec from 1 PPS, step size=-0.25 dBm)

(average, trailing 1 sec from 1 PPS, step size=-0.25 dBm)

(trailing 1 sec from 1 PPS)

00: not locked

01: locked

10-11: reserved

(dBm, at 312.5 Mbaud rate, step size=-0.25)

(dBm with no damage to APD, step size=-0.25)

The frequency at which the FCCH messages are sent is application dependent subject to these requirements:

· LAPC_RSSI_REPORT shall be sent at rate at least 100 Hz.

· LAPC_BLER_REPORT and LAPC_SYNC_REPORT shall be sent at rate at least 1 Hz.

OISL_SENSITIVITY shall be sent once after link acquisition and is used by the receiving terminal to control transmit optical power based on LAPC_RSSI_REPORT messages.

The OISL_CAPABILITIES is for future use for autonomous OISL Link configuration.

The OISL implementation shall be designed to tolerate loss of any FCCH messages.

Payload Data Bytes All modem frames shall carry a payload of 239×8-4=1908 application data bytes with 8 bits per byte. The source of data bytes for data frames (FRAME_TYPE=00, Error! Reference source not found.) shall be encapsulated Ethernet traffic.

CRC-32

All modem frames shall protect the integrity of the payload information bits with an attached 32-bit CRC (Section 2.2.1.3.1).

Parity Bytes The OISL modem features payload FEC. The payload FEC shall be implemented as detailed in Section 2.2.1.3.3 and shall adhere to (1). Section 4.1.4. The number of parity bytes is (255-239)×8=128.

1.1.1.1 Special Frames

The field frame Header shall contain a FRAME_TYPE field. The FRAME_TYPE field of the frame Header (Table 2) shall signal the type of modem frame. This section defines the frame types and their intended usage on the optical interface. Features signaled through the frame header are available in all frame types.

IDLE Frames By design the modem always transmits frames with no gap between adjacent frames. In the case that data is not available for transmission the modem shall insert consecutive IDLE frames into the transmitted stream until other types of traffic frames become available. There shall not be a gap between frames under any circumstance.

Header Construction Modem IDLE frames shall be signaled in the frame header by field FRAME_TYPE=00 (Table 2) Modem IDLE frame headers shall be otherwise identical to normal data frame headers with the exception that the TXFN field in an IDLE frame header is always equal to the master TXFN counter.

1.1.1.1.1.1 Payload Construction

Modem IDLE frames shall be subject to the same payload FEC and shall be protected by the same CRC-32 as the data frames.

The information payload in IDLE frames shall be constructed as a pseudo-random binary sequence (PRBS) using the same generator as the frame scrambler (Section 2.2.1.3.4) except with its initial seed equal to the value of the frame header TXFN field (Table 2) plus one.

The size of the IDLE information payload shall be the same as for data frames.

MGMT/PNT Frames The MGMT frame type is provided for management frames. These frames shall be used for inter-OISL communications.

Header Construction Modem MGMT frames shall be signaled in the frame header by field FRAME_TYPE=10 Table 1).

1.1.1.1.1.2 Payload Construction

Modem MGMT frames shall be subject to the same payload FEC and are protected by the same CRC-32 as the data frames. The size of the MGMT information payload shall be the same as for data frames.

Error Control Coding The bit error rate (BER) requirements are as follows:

· OISLs shall achieve a decoded bit error rate (BER) after Forward Error Correction (FEC) of 10-6

· OISLs should achieve a decoded bit error rate (BER) after Forward Error Correction (FEC) of 10-9 These error rates are to be achieved through OISL modem frames with forward error control coding:

· Information bits shall be protected by CRC’s (Section 2.2.1.3.1, header: 16 bits, payload: 32 bits)

· Fixed-rate (shortened) Reed-Solomon code shall be used for the frame Header (Section 2.2.1.3.2)

· Fixed-rate Reed-Solomon code shall be used for the frame Payload (Section 2.2.1.3.3)

CRC

Two CRC’s are required to generate the modem frame: a CRC-16 protects the frame header bits while a CRC-32 protects the payload bits. A functional description of a generic 𝐿-bit CRC encoder circuit is shown in Figure 2. The circuit consists of an 𝐿-bit register (𝐿 = 16 for CRC-16 and 𝐿 = 32 for CRC-32). The connection polynomials (i.e., values 𝑔𝑘) are defined in Table 5 for each of the two CRC’s required to create the modem frame.

Calculation of the CRC for a block of 𝑘 payload bits shall be performed as follows:

· Initialize the 𝐿-bit encoder register state to zero at the start of each new CRC calculation

· Clock in the 𝑘 payload bits with switches 𝑆1 and 𝑆2 both in the down position

· After the last payload bit has been loaded the encoder register contains the 𝐿-bit CRC value. It can be clocked-out with switches 𝑆1 and 𝑆2 in the up position

Figure 2: 𝑳-bit CRC Calculation Circuit

Table 5: CRC Polynomials

+ 𝑥12 + 𝑥11 + 𝑥10 + 𝑥8 + 𝑥7 + 𝑥5 + 𝑥4 + 𝑥2 + 𝑥 + 1

Header FEC The modem header payload shall be encoded by a shortened Reed-Solomon code. The shortened Reed-Solomon code shall be constructed by zero-valued virtual fill based on the same RS(255, 239) code as used for the payload FEC described in Section 2.2.1.3.3.

The header RS code parameters are provided in Table 6.

Table 6: Shortened Reed-Solomon Code for Frame Header

N

Number of codeword bytes

The virtual fill bytes (zero-valued) shall be appended to the 16-byte header when computing the parity bytes. Virtual fill bytes shall be padded at the beginning of the Reed-Solomon codeword but shall not be transmitted. After shortening, the header is effectively encoded by an RS(32,16) code. The encoding process for the frame header is presented in Figure 3.

Figure 3: Header FEC Encoding Payload FEC and Interleaving The OISL payload FEC shall be adapted from the Reed-Solomon code specified in (8).

The Reed-Solomon (RS) encoding of the payload FEC shall follow the recommendations in (8). with these specifications:

· In the event that the payload has fewer than 1908 bytes to transmit, the higher layer shall pad the data block with zeros to fill the entire 1908 bytes

· A CRC-32 check value shall be appended to the block of 1908 source bytes prior to encoding

· The payload RS FEC shall encode blocks of 239×8=1912 bytes of source data across 8 RS(255,239) codewords

· The RS code shall be 8 bits per RS symbol ((8), Section 4.3.1) with an encoded block size (per codeword) of 255 symbols

· The number of parity digits shall be 16, producing an RS(255,239) code, corresponding to in ((8), Section 4.3.2)

· The Galois Field generator polynomial shall be

· The RS code generator polynomial shall be

· The RS codewords shall be in systematic form with data symbols preceding parity symbols

· The RS codewords shall be defined on the conventional (powers of α) basis. This is a departure from ((8), Section 4.3.9) which specifies the Berlekamp Dual basis The interleaving depth for the payload FEC shall be 8 RS(255,239) codewords, as illustrated notionally in Figure 4. This diagram, abstracted from ((8) Section 4.2), illustrates notionally how source bytes are encoded.

· Source bytes are written in column-major order, spreading contiguous input bytes across all 8 Reed-Solomon codewords

· Source bytes are written in systematic form with the block of data bytes followed by a block of parity bytes

· After encoding, bytes are transmitted in the same order as they entered the encoder (column major, per Figure 4) with the block of data bytes followed sequentially by the block of parity bytes

Figure 4: Payload FEC Interleaving

The transmit order of each 8-bit Reed-Solomon encoded interleaved symbol (an 8-bit byte) is shown in Figure 5.

Figure 5: Bit Ordering of Reed-Solomon Encoded Bytes

These following adaptations are made from the payload FEC framing as specified by (3):

· The SDA OCT shall only implement the “LIA Framing” section of (3), meaning that all incoming payloads to the FEC are fixed sized. Therefore, the 8 bytes allocated by (3), for the LIAU superframe headers are subsumed into the payload section of the FEC encoder. This increased the “data” section in Figure 4 from 238 to 239 bytes and conforms to a standard Reed-Solomon codeword as defined in ((3) Section 4).

· All OISL modem frames carry a 15264 information bit payload per frame which is protected by a CRC-32. The inclusion of the CRC-32 in Figure 4 is an extension of the CCSDS framing specification.

The SysChanDat* bit of the LPC(25,16) code (as described in CCSDS 141.11-O-1, Section 3.3.2.3.4) is not used in this standard. Here, this standard uses the same LPC code as the referenced CCSDS standard except without the SysChanDat* bit, producing an LPC(24,16) code. The LPC code is applied synchronously during frame generation (see Figure 6) beginning with the first bit of the header and continuing through the last bit of the payload. The LPC code is not applied to the preamble.

· The OCTs may be synchronized by simple cross-correlation with the frame preamble.

Scrambling and Line Product Code The scrambler and Line Product Code (LPC) shall be implemented and shall be adopted from (3). The scrambler follows ((3) Section 3.3.2.3.3) with details of its initial seed provided in Section 2.2.1.3.5 of this Standard.

· The scrambler shall reset to a fixed value (Table 7) at the start of every modem headers

· The scrambler shall advance naturally after scrambling the header to also scramble the payload bits

· The preamble bits shall not be scrambled Scrambler Reset State The scrambler shall initialize the PRBS generator stages with the values defined in Table 7.

Table 7: Scrambler Reset Definition

X[0:1]=1 X[2]=1 X[24:3]=0 Initialization Pattern

Scrambler Initialization After a system reset, the PRBS generator shall start with the initialization pattern as defined in Table 7.

Scrambler parallel implementation overview The scrambler defined in (3) refers to the bit-serial implementation of the scrambler. The implementer may use a bit-serial representation or unroll it in a parallel implementation that can process up to 16 bits per clock cycle.

Line Product Code The LPC(24,16) code and running disparity manager is adopted from ((3) Section 3.3.2.3.4) with optional SysChanDat* bit punctured.

The LPC(24,16) code is applied synchronously with frame generation (see Figure 6):

· The frame preamble has zero disparity (by design) and is not subject to the LPC code

· The frame header is synchronous to the frame preamble with the header size exactly a multiple of 16 bits, meaning that the header exactly fits in an integer number of LPC code blocks

· The frame payload (information bits, CRC, and parity bits) is synchronous to the frame header and is also dimensioned to produce an integer number of LPC codewords Frame Generation Summary Construction of the OISL frame and its integration with the line product code is summarized in Figure 6.

Figure 6: Frame Encoding Summary Ethernet Packet Encapsulation Overview of Ethernet Packet Encapsulation The OCT data plane encapsulates Ethernet packets as Free Space Optical (FSO) frames for transport across the optical link. The processing steps are illustrated functionally in Figure 7.

Figure 7: Ethernet Encapsulation

This scheme permits the OISL to carry virtually any form of Ethernet traffic transparently between a pair of optical terminals. The presence of the OISL is largely transparent to the endpoints.

Ethernet Packet Handling On ingress to the modem, the Ethernet frame shall be extracted from every Ethernet packet by stripping the Preamble and the Start Frame Delimiter (SFD) from the packet. The Ethernet frames shall be queued to the Packing and Segmentation block for encapsulation as FSO frames.

On egress from the modem, the TX Ethernet PHY shall construct Ethernet packets from the received (reconstructed) Ethernet frames by pre-pending for each frame the Preamble, Start Frame Delimiter (SFD), and Frame Check Sequence (FCS). The reconstructed Ethernet packet shall be emitted by the Ethernet PHY.

Packing and Segmentation The Packing and Segmentation operation (Figure 7) shall perform the following functions in the TX PHY of the optical terminal:

· Segments large Ethernet frames into one or more FSO frames (as needed)

· Packs small Ethernet frames into FSO frames The implementation of the Packing and Segmentation operation shall preserve the ingress order of Ethernet packets.

FSO Frame Payload Format This section defines how the output of the Packing and Segmentation operation is formatted in the payload section of an FSO DATA Frame. The structure is illustrated logically in Figure 8. The bytes shall be written into the payload FEC physical frame in the byte order specified in Figure 4. The bytes shall be consecutive, per word in Figure 8, with the lower 8 bits (0 to 7) denoting the first byte, followed by the next grouping of bytes up to the upper set of 8 bits (24 to 31) denoting the third byte. The numbering of bytes for the purpose of defining their ordering entering the payload FEC shall count up naturally for each 32-bit word in Figure 8.

Figure 8: FSO Payload Frame Format

The FSO Payload and FSO Frame headers split Ethernet frame payloads across multiple frames, enabling efficient packing of Ethernet frames into FSO frames.

Note that the CRC-32 described in Figure 8 is the same CRC-32 previously described in Figure 4 and is repeated here for clarity.

FSO Payload and Packet Headers Every FSO frame shall start with an FSO Payload Header. There shall be exactly one FSO Payload Header (32 bits) per FSO frame. The contents of the FSO frame and packet headers shall follow the definition presented in Table 8.

Table 8: FSO Payload and Packet Headers

FSO Payload Header:

The FSO Payload Header shall be constructed as an 8-bit magic number (0xAB) followed by a 10-bit sequence number and a 14-bit length field. Sequence numbers shall increment sequentially for every DATA frame and wrap naturally around zero. The sequence number referenced in Table 8 is unrelated to the modem’s ARQ signaling in Figure 8.

The system shall be capable of splitting an encapsulated Ethernet frame payload across multiple FSO frames. The FSO Payload Header length field shall have a non-zero value only when an Ethernet frame is segmented across the preceding and current FSO frames, signaling the length of the preceding encapsulated packet remaining. Otherwise, the length field shall be zero.

FSO Packet Header:

The FSO packet header (Table 8) shall signal encapsulation of an Ethernet frame. The header shall be constructed as a 16-bit magic number (0xCDEF) followed by two reserved bits (0b00) and a 14-bit length field. The length field shall signal the number of payload bytes to follow where the length field excludes the length of the packet header. If the encapsulated Ethernet frame is segmented into the subsequent FSO frame, the length field shall signal the number of bytes remaining in the payload.

Padding and CRC FSO packet headers shall be aligned to a 32-bit boundary. If the encapsulated Ethernet frame length is not a multiple of 4 bytes, the implementation shall pad the unused space in the FSO frame with zeros. Ethernet frame payloads shall be written into the FSO frame (Figure 8) in row-major order, starting with bit 31 (MSB) down to bit 0 (LSB).

The implementation shall be capable of emitting partially packed FSO frames. Unused bytes in the FSO frame shall be padded with zeros.

Every FSO frame shall end with a 32-bit CRC as illustrated in Figure 8. In all cases, the CRC shall cover the entire frame, including any portions of the frame padded with zeros.

Reassembly of Ethernet Frames The implementation’s optical RX PHY shall reconstruct the sequence of ingress Ethernet packets from the (packed) FSO frames received from the far-end terminal. The frames shall be transmitted on its egress Ethernet in the same order and with the same packet sizes as received by the Ethernet RX PHY on its ingress Ethernet.

The Reassembly process (the Reassembly Block in Figure 7) shall implement the following:

· If an FSO frame is received with a sequence number skip, any Ethernet packet whose payload was not complete shall be discarded. The received FSO frame with the skipped sequence number shall be retained only if the length field of its FSO frame header is zero. Any FSO packet headers following the end of the first partial packet in the FSO frame are valid

· Any FSO frame whose magic number in its FSO Frame Header (Table 8) is incorrect shall be discarded entirely

· Any FSO Packet Header within any FSO frame (Table 8) whose magic number is incorrect shall be discarded

· Any FSO Packet Header whose length field is inconsistent shall be discarded Ranging and Position, Navigation, and Timing (PNT) Time Stamping The TX PHY shall timestamp each FSO frame consistent with the technique described in Section 2.2.1.2.1. The timestamp shall reference the rising edge of the first bit of the optical frame. The timestamp shall be accurate to within 10 nanoseconds relative to the OISL timing interface. The timestamp should be accurate to within 1 nanosecond RMS relative to the OISL timing interface.

The RX PHY shall record a timestamp and sequence number of the incoming frame at a frequency of at least one Hz. The rate of time stamp recording shall be remotely controllable.

The implementation shall reference the recorded timestamp to the ingress time of the rising edge of the first bit of the modem frame. The implementation shall compensate timestamps (as required) for systematic time delays due to propagation paths outside the over-the-air connection between a pair of terminals. The means for calibrating path delays and compensating timestamps shall be implementation dependent.

Ranging Data: Two-way Frame Timestamps and Range The receiving OCT shall, at a frequency of at least one hertz but no greater than the rate specified in Section 2.2.1.4.8.1, provide timestamp data back to the transmitting OCT. This data shall be sent in a MGMT frame. The Timestamp Frequency shall be commanded by the requesting OCT and shall be communicated as a positive number corresponding to the Timestamp Frequency.

The payload of a ranging response frame shall contain the following data:

· The egress timestamp of the frame which was measured on receipt

· The ingress timestamp of the measured frame

· Time-tagged ranging measurements accurate to < 3 meters In addition to these data, the egress timestamp of the management frame shall be collected by the terminal receiving the management frame. This timestamp shall occur either in the MGMT frame or in the subsequent frame as indicated by the timestamp location flag.

The OCT shall provide the above time-tagged ranging measurements to <10 ns relative to the SV clock to the ground, to the onboard processing (e.g. BMC3), and to the bus to be provided to TT&C subscribers. See (11) for time and frequency terms including range.

References The following publications contain provisions which, through reference in this text, constitute provisions of this document. At the time of publication, the editions indicated were valid. All publications are subject to revision, and users of this document are encouraged to investigate the possibility of applying the most recent editions of the publications indicated below.

Spectral Grids for WDM Applications: DWDM Frequency Grid. ITU-T Recommendation G.694.1. Geneva: ITU, February 2012.

ANSI/IEEE Standard 149-1979, “IEEE Standard Test Procedures for Antennas”, IEEE Standard 149-1979, New York: IEEE, 1979.

Optical High Data Rate (HDR) Communication-1064NM. Issue 1. Research and Development for Space Data System Standards. (Orange Book), CCSDS 141.11-O-1. Washington, D.C.: CCSDS, December 2018.

(1) Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit. ITU-T Recommendation X.25. Geneva: ITU, October 1996.

(2) Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion. ITU-T Recommendation V.42. Geneva: ITU, March 2002.

(3) Information Technology—Open Systems Interconnection—Basic Reference Model: The Basic Model. 2nd ed. International Standard, ISO/IEC 7498-1:1994. Geneva: ISO, 1994.

(4) Information Technology—Open Systems Interconnection—Basic Reference Model— Conventions for the Definition of OSI Services. International Standard, ISO/IEC 10731:1994. Geneva: ISO, 1994.

(5) TM Synchronization and Channel Coding. Issue 3. Recommendation for Space Data System Standards (Blue Book), CCSDS 131.0-B-3. Washington, D.C.: CCSDS, September 2017.

(6) Optical Communications Physical Layer. Issue 1. Recommendation for Space Data System Standards (Blue Book), CCSDS 141.0-B-1. Washington, D.C.: CCSDS, August 2019

20210414-001-02 Page 4 of 21 image3.png image4.png image5.png image6.png image7.emf

Microsoft_Visio_Drawing.vsdx image8.emf

Microsoft_Visio_Drawing1.vsdx image9.emf

Microsoft_Visio_Drawing2.vsdx image10.png image11.emf

Microsoft_Visio_Drawing3.vsdx image1.png image2.png