SDA OISL Standard v2.1.2.pdf

Space Development Agency Optical Intersatellite Link (OISL) Standard Version 2.1.2

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

Publication Date: 3 January, 2022

Document ID: SDA-9100-0001-03

DISTRIBUTION STATEMENT A. Approved for public release: distribution unlimited.

Optical Intersatellite Standard Version 2.1.2 Space Development Agency

Prepared by:

Michael Butterfield Optical Communications Lead, Space Development Agency Email: OSD.SDA.Outreach@mail.mil

Optical Intersatellite Standard Version 2.1.2 Space Development Agency

DISTRIBUTION STATEMENT A. Approved for public release: distribution unlimited.

Revision History

Date Version Description of Change June 5, 2020 NA Draft as issued for Transport Layer T0 RFP HQ085020R0001 June 5, 2020 1.0 Editorial changes only Feb 5, 2021 2.0 Final version October 15, 2021 2.1 This version incorporates errors, omissions, and clarifying information in support of Tranche 0.

November 24, 2021 2.1.1 DRAFT Patch update - Provided clarifying information and incorporated fixes for errata December 13, 2021 2.1.2 Updated Patch version based on comments received on DRAFT 2.1.1 patch

Optical Intersatellite Standard Version 2.1.2 Space Development Agency

DISTRIBUTION STATEMENT A. Approved for public release: distribution unlimited.

Table of Contents List of Figures .............................................................................................................................. vii 1 Introduction

1.1 Purpose and Scope

1.2 Assumptions

1.3 Nomenclature and Definitions

Normative Text Definitions from the Open Systems Interconnection (OSI) Basic Reference

Model 2 Standard Definition

2.1 Pointing, Acquisition, and Tracking

PAT Introduction Example Spiral Scan T0 Interoperable Pointing, Acquisition, and Tracking

2.1.3.1 State Machine

2.1.3.2 Configuration Parameters and Telemetry

Acquisition Scheme

2.2 Latency

2.3 Re-Programming

2.4 Effective Data Rate

2.5 Physical Layer

Channel Definition

2.5.1.1 Center Frequency Tolerance

2.5.1.2 Laser Line-Width

2.5.1.3 In-Band and Spillover Emissions

2.5.1.4 Timing Jitter

Transmit and Receive Wavelength Selection Polarization Power and Link Margin

2.6 Modulation

Modulation Tracking Tone Framing, Coding, Encapsulation

2.6.3.1 Framing Structure

2.6.3.2 Preamble Sequence

2.6.3.3 Header

2.6.3.4 Payload

2.6.3.5 Special Frames

2.6.3.6 Error Control Coding

2.6.3.7 Ethernet Packet Encapsulation

3 Glossary

Optical Intersatellite Standard Version 2.1.2 Space Development Agency

DISTRIBUTION STATEMENT A. Approved for public release: distribution unlimited.

4 References

Optical Intersatellite Standard Version 2.1.2 Space Development Agency

DISTRIBUTION STATEMENT A. Approved for public release: distribution unlimited.

List of Tables Table 2-1. State Machine Description Table 2-2. State Machine Configuration Parameters Table 2-3. State Machine Telemetry Table 2-4: Maximum Effective Data Rates for Frame Configurations Table 2-5: Wavelength Channel Definition Table 2-6: Minimum Irradiance Table 2-7: Required Margin at Range Table 2-8: Modem Frame Summary Table 2-9: Frame Header Fields Table 2-10: Mapping of Header Fields to Byte and Bit-locations in the Transmitted Header Table 2-11: ARQ Parameters Table 2-12: FCCH Logical Channels Table 2-13: FCCH Payloads Table 2-14: MGMT/PNT Frame Payload Definition for Ranging Timestamps Table 2-15: CRC Polynomials Table 2-16: Shortened Reed-Solomon Code for Frame Header Table 2-17: Scrambler Reset Definition Table 2-18: FSO Payload and Packet Headers Table 2-19: Ethernet Frame Byte Ordering into FSO Logical Frame

Optical Intersatellite Standard Version 2.1.2 Space Development Agency

DISTRIBUTION STATEMENT A. Approved for public release: distribution unlimited.

List of Figures Figure 2-1. Spiral Scan Pattern Figure 2-2. T0 Interoperable PAT State Machine Figure 2-3 PAT Geometric Reference Figure 2-4. PAT Notional OPSCON Figure 2-5: AM Tone Tracking Modulation Figure 2-6: Multiplexing Frame Types Figure 2-7: Payload Byte Ordering Figure 2-8: 𝑳𝑳-bit CRC Calculation Circuit Figure 2-9: Header FEC Encoding Figure 2-10: Payload FEC Interleaving Figure 2-11: Bit Ordering of Reed-Solomon Encoded Bytes Figure 2-12: Application of the Scrambler Figure 2-13: Differentially Encoding in LPC Encoder Figure 2-14: LPC Codeword Figure 2-15: Frame Encoding Summary Figure 2-16: Ethernet Encapsulation Figure 2-17: FSO Payload Frame Format

1 Introduction The Optical Intersatellite Link (OISL) standard establishes the interoperability requirements for all Optical Links that wish to communicate with the Space Development Agency (SDA) Tranche 0 system, including space-to-space and space-to-ground links.

1.1 Purpose and Scope

The purpose of this document is to define an interface specification for space-to-space and space-to-ground optical communications for SDA Tranche 0. The scope of this document is limited to the physical and data link layers of the optical communication links.

1.2 Assumptions

The development of this standard has focused on the optical communications requirements to be demonstrated in the SDA Tranche 0 (T0) constellation.

The following items set this document’s scope:

1. Only spacecraft in Low Earth Orbit (LEO) are part of the T0 constellation.

Interoperability with spacecraft in other orbital regimes is not in scope.

a. Three Classes of Links have been assumed

i. In-Plane

ii. Cross-Plane

iii. Space-to-Terrestrial

2. The later (T1+) constellation OISLs are not required to be backward compatible with the T0 system. This document is applicable to the SDA T0 Constellation.

3. The optical link ranges in T0 will span from a nearest allowable distance to a maximum of 6500 km.

a. No analysis of the implications of this interface specification has been performed on links beyond 6500 km

b. The nearest allowable distance is the minimum safe operating distance, with appropriate margin, for which the transmitter is capable of delivering a signal to the remote receiver below its safe irradiance limit

4. The OISL terminals:

a. Operate in the Optical C-Band

b. Operate between 100 Mbps and 1 Gbps data rates with nominal operations at

312.5 Mbps

c. Employ direct detection optical receivers

5. While this document does not levy requirements on size, weight, power, and cost (SWAP-C), the SDA T0 spacecraft and optical terminal SWAP-C and mission CONOPS have influenced the range, data rate, and other assumptions and decisions contained herein.

1.3 Nomenclature and Definitions

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

Definitions from the Open Systems Interconnection (OSI) Basic Reference Model This standard makes use of a number of terms from the OSI model as defined in [1]. The definitions of those terms in this standard conform to the definitions contained in [1].

2 Standard Definition

2.1 Pointing, Acquisition, and Tracking

PAT Introduction Acquisition time shall be less than 100 seconds after bus offset calibration. Acquisition time should be less than 10 seconds after bus offset calibration. A transmitted amplitude modulation (AM) tracking tone shall be provided as defined in Section 2.6.2.

The PAT spatial acquisition shall be referred to as a lead and follow strategy (referred to as master-slave in [2]).

The PAT approach below provides the state machine and parameters for a common Pointing, Acquisition and Tracking approach for optical intersatellite links and optical communications terminals (OCTs), generally, employed by the Space Development Agency (SDA) T0 programs.

The scope of this PAT approach is limited to Space-to-Space and Space-to-Ground optical connections. Space-to-Space optical connections between terminals produced by the same vendor may offer, in addition to the PAT approach defined herein, additional PAT modes selectable upon command by the ground.

The details below clarify the framework described in Section 2.3 of [2] and provide details not otherwise provided in [2] necessary to ensure PAT interoperability between multiple vendors. This PAT approach employs a lead/follow strategy with time-constrained state changes and synchronized acquisition/re-acquisition attempt start times to ensure PAT interoperability under large uncertainty cone conditions.

Example Spiral Scan

Figure 2-1. Spiral Scan Pattern

-5 -4 -3 -2 -1 0 1 2 3 4 5 -5

-4

-3

-2

-1

X Search / TxBeamAngle

Y Se ar ch

Tx

B ea m A ng le

Tx Beam Traversing Spiral Acquisition Search Path

Spiral Path Gaussian Beam Angle

CScan

Figure 2-1 is the baseline Constant Velocity Archimedes spiral scan approach and is the minimal amount of time necessary for a scan. The spiral scan approach may vary between T0 Optical Vendors, but different scan approaches can increase scan time.

The time to spiral to the search radius 𝐶𝐶𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆ℎ is given by the following equation:

𝑇𝑇𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆

𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 = 𝜋𝜋𝑇𝑇𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 �

𝐶𝐶𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆ℎ

𝐶𝐶𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆

The 𝐶𝐶𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 parameter must be selected based on the minimum required receive flux 𝑃𝑃𝑅𝑅𝑅𝑅_𝑀𝑀𝑆𝑆𝑆𝑆 for the specific OCT. Simplistically, this is illustrated in the following link equation:

𝑃𝑃𝑇𝑇𝑅𝑅 − 𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 − 𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝑃𝑃𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 − 𝑀𝑀𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 − 𝑂𝑂𝐵𝐵𝐵𝐵𝐵𝐵𝑂𝑂𝐵𝐵𝑂𝑂𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 > 𝑃𝑃𝑅𝑅𝑅𝑅_𝑀𝑀𝑆𝑆𝑆𝑆

The overlap loss term is related to the ratio of 𝐶𝐶𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆to the transmit beam divergence 𝜃𝜃𝑇𝑇𝑇𝑇. If 𝐶𝐶𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 = 𝜃𝜃𝑇𝑇𝑇𝑇, then the OverlapLoss = 8.64 dB. If, on the other hand, 𝐶𝐶𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 = 𝜃𝜃𝑇𝑇𝑇𝑇/1.7 (which is the FWHM diameter), then the OverlapLoss = 3 dB, however, the spiral scan will take 1.72 = 2.9x longer.

T0 Interoperable Pointing, Acquisition, and Tracking Modeling the pointing, acquisition, and tracking (PAT) sequence as an event-driven finite-state-machine provides a common model for all T0 OISL Standard Terminals. The purpose of this model is to communicate the current status of the OCT’s PAT channel, provide a sequence of events in a geometric construct, and standardize the required parameters.

2.1.3.1 State Machine

Figure 2-2. T0 Interoperable PAT State Machine

Table 2-1. State Machine Description ID Name Description Entry Criteria Exit Criteria 1 Standby OCT waits for further commanding. Command Received: Initiate

Link OperationSetup

2 Setup After a new link command is received, the OCT is configured according to the link parameters and the coarse pointer starts to move towards the target trajectory.

Command Received:

Initiate Link Operation

OCT has slewed into position and terminal has been configured ahead of 𝐵𝐵𝑆𝑆𝑇𝑇𝑆𝑆𝑅𝑅𝑇𝑇 being reached

Starting time 𝐵𝐵𝑆𝑆𝑇𝑇𝑆𝑆𝑅𝑅𝑇𝑇 is reached Acquisition Phase 1A

3 Acquisition Phase 1A

During acquisition phase 1A the lead OCT scans the starting cone of uncertainty.

The follow OCT detects hits and performs pointing adjustments, reducing the level of starting uncertainty.

Configuration Parameter Phase 1A duration reached (𝛿𝛿𝑆𝑆𝑆𝑆𝐴𝐴1𝑆𝑆) Acquisition Phase 1B

4 Acquisition Phase 1B

During acquisition phase 1B the follow OCT scans the remaining cone of uncertainty.

The lead OCT detects hits and performs pointing adjustments, reducing the level of starting uncertainty.

Configuration Parameter Phase 1B duration reached (𝛿𝛿𝑆𝑆𝑆𝑆𝐴𝐴1𝐵𝐵) Acquisition Phase 2

5 Acquisition Phase 2

During acquisition phase 2 either one or both of the two OCT scans the remaining cone of uncertainty.

The OCT(s) detects hits and performs pointing adjustments, further reducing the level of uncertainty.

Uncertainty reduced such, that target is within FOV of the fine acquisition sensor (if applicable) Fine Acquisition

Timeout waiting for further hits Prepare

6 Fine Acquisition During fine acquisition both OCTs are scanning the remaining cone of uncertainty and both OCTs detect hits and perform pointing adjustments to further reduce the level of uncertainty further.

Stable tracking established, continuous receive signal Communication.

Timeout waiting to establish tracking Prepare

7 Communication Bidirectional data link is established Command Received:

𝛿𝛿𝐿𝐿𝐿𝐿𝑆𝑆𝐿𝐿𝐿𝐿𝑆𝑆𝑆𝑆𝐿𝐿𝑆𝑆 Stop

Tracking signal lost Fine Acquisition

8 Stop The link is terminated by command or due to a failure condition. The OCT goes back to standby

Laser and all mechanism stopped and goes back to standby

9 Prepare Prepare for reestablishing the link Complete acquisition sequence is repeated using the configuration according to the latest Initiate Link Command with the next acquisition start time defined by:

𝑇𝑇𝑆𝑆𝑆𝑆𝑅𝑅𝑆𝑆𝑆𝑆𝑆𝑆𝐴𝐴𝑛𝑛𝑆𝑆𝑛𝑛𝑆𝑆𝑆𝑆𝑆𝑆𝐿𝐿𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆

= 𝐵𝐵𝑆𝑆𝑇𝑇𝑆𝑆𝑅𝑅𝑇𝑇 + Ω𝑆𝑆𝑆𝑆𝐴𝐴𝐴𝐴𝑆𝑆𝑆𝑆𝑆𝑆𝐿𝐿𝐴𝐴

∙ 𝐵𝐵𝐵𝐵𝐵𝐵𝑂𝑂𝐵𝐵𝐵𝐵𝐵𝐵 �

𝐵𝐵 − 𝐵𝐵𝑆𝑆𝑇𝑇𝑆𝑆𝑅𝑅𝑇𝑇 + 𝛿𝛿𝑆𝑆𝑆𝑆𝐴𝐴𝐴𝐴𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝐿𝐿𝑆𝑆

Ω𝑆𝑆𝑆𝑆𝐴𝐴𝐴𝐴𝑆𝑆𝑆𝑆𝑆𝑆𝐿𝐿𝐴𝐴

where t is the current time.

If Ω𝑆𝑆𝑆𝑆𝐴𝐴𝐴𝐴𝑆𝑆𝑆𝑆𝑆𝑆𝐿𝐿𝐴𝐴 = 0, this state is passed through

OCT has slewed into position based on latest ephemeris prediction and terminal configuration and then 𝐵𝐵𝑆𝑆𝑇𝑇𝑆𝑆𝑅𝑅𝑇𝑇 is reached

2.1.3.2 Configuration Parameters and Telemetry

Table 2-2. State Machine Configuration Parameters

Parameter Parameter Shorthand Range of Values

Parameter Definition

Start Time 𝐵𝐵𝑆𝑆𝑇𝑇𝑆𝑆𝑅𝑅𝑇𝑇 The absolute time at which the PAT sequence begins

Acquisition Type [Optional]

Synchronous or Asynchronous

Synchronous – Start at specified tSTART

Asynchronous – Start immediately [Optional behavior]

Starting Uncertainty Cone (𝜇𝜇𝐵𝐵𝐵𝐵𝜇𝜇)

TUC 500-vendor

FOV

This is the starting cone of uncertainty and is reported as a circular cone radius.

This is the search cone.

Starting uncertainty may be larger than the system FOV which may require manual intervention

Phase 1A duration (seconds) 𝛿𝛿𝑆𝑆𝑆𝑆𝐴𝐴1𝑆𝑆 0-65535 Duration of first spiral scanning phase (1A).

Nominally symmetric across terminals, but terminal shall act as commanded.

Phase 1B duration (seconds) 𝛿𝛿𝑆𝑆𝑆𝑆𝐴𝐴1𝐵𝐵 0-65535 Duration of second spiral scanning phase (1B).

Nominally symmetric across terminals, but terminal shall act as commanded.

Lead or Follow Lead or Follow

Determines if the terminal shall act as Acquisition Lead or Follow

TX wavelength A or B TX wavelength selection TX Tracking tone modulation

On or off Determines if TX laser amplitude modulation used

Spiral-Velocity (urad/msec)

0-1000 Spiral velocity compatible with receiver bandwidth of counter terminal. Set per-vendor

Spiral Separation (urad) 0-1000 Spiral velocity compatible with receiver bandwidth of counter terminal. Set per-vendor

Phase 2 Maximum Duration (sec) 𝛿𝛿𝑀𝑀𝑆𝑆𝑅𝑅𝐴𝐴ℎ𝑆𝑆𝑛𝑛𝑆𝑆2 0-255 Max duration in Acquisition Phase 2 without establishing target is within FOV of the fine acquisition sensor (if applicable)

Fine Acquisition Maximum Duration (seconds) 𝛿𝛿𝑀𝑀𝑆𝑆𝑅𝑅𝑀𝑀𝑆𝑆𝑆𝑆𝑆𝑆 0-255 Max duration in Fine Acquisition without establishing stable tracking

Acquisition Period (seconds)

Ω𝑆𝑆𝑆𝑆𝐴𝐴𝐴𝐴𝑆𝑆𝑆𝑆𝑆𝑆𝐿𝐿𝐴𝐴 0-65535 Periodicity of acquisition restart times. This is a parameter specified by the ground.

Acquisition Preparation Duration (seconds) 𝛿𝛿𝑆𝑆𝑆𝑆𝐴𝐴𝐴𝐴𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝐿𝐿𝑆𝑆 0-255 The amount of time required for the overall system (comprised of both OISL A and B) to be ready for the next acquisition (which is an exit criteria for the “Prepare” state) is 𝛿𝛿𝐴𝐴𝐵𝐵𝐴𝐴𝑃𝑃𝐵𝐵𝐵𝐵𝑂𝑂𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵. This is a parameter set by the ground.

Table 2-3. State Machine Telemetry

Parameter Parameter Shorthand Parameter Definition State S This is the current state of the top-level state machine.

Acquisition Scheme

Figure 2-3 PAT Geometric Reference

Figure 2-3 shows the T0 PAT geometric acquisition scheme. The Red arrows denote an active TX beam, the cone around the arrow depicts the size of the uncertainty cone (outer scan radius).

Green arrows denote pointing adjustment and reduction of uncertainty cone.

Figure 2-4 provides a notional timeline for each phase and notional uncertainty cone for Phase 1a entry criteria and the transition from Phase 2 to Fine acquisition. Time and uncertainty will be specific for each vendor pairing based on uncertainty determined on orbit after calibration. The leader is on the left column while the follower is on the right column.

Pointing Acquisition 1a Acquisition 1b Acquisition 2 Fine Acquisition Tracking

Pointing Acquisition Tracking

Starting Point Error

Starting Point Error

Figure 2-4. PAT Notional OPSCON. Time progresses from top to bottom. The transition from Acquisition 2 to Fine and Fine to Track is triggered by successful tracking. The definition of success for tracking is implementation-dependent. In this diagram, the Leader is depicted as having only a single field size. For this reason, the wide- and narrow-field scan are combined.

2.2 Latency

Latency is defined as the duration of time from arrival of the rising edge of the first bit at the receiver’s detector to egress of the complete Ethernet packet from the OISL terminal via the data interface. The T0 data interface is the connection from the OISL modem to the router and typically implemented as a 1 Gbps Ethernet link.

For a given Ethernet packet, the latency is calculated as Egress Time-Ingress Time, where:

• Ingress Time = earliest arrival time of any bit from the packet

• Egress Time = time of egress completion of the entire Ethernet packet

The following latency requirements apply to an Ethernet payload size up to a maximum transmission unit (MTU) of 1500 octets:

• The receive (RX) modem latency shall be less than 15 ms

• The receive (RX) modem latency should be less than 5 ms

• The transmit (TX) modem latency shall be less than 15 ms

• The transmit (TX) modem latency should be less than 5 ms

2.3 Re-Programming

Physical Framing (Section 2.6.3.1), Coding and Scrambling (Section 2.6.3.6 and Section 2.6.3.6.4) and Encapsulation (Section 2.6.3.7) shall be re-programmable on orbit. During reprogramming, the transmission of data may be interrupted.

LEADER START

t = 𝐵𝐵0

VERY LARGE

SCAN

WIDE FIELD

DETECTION

NARROW SCAN

NARROW FIELD

DETECTION

𝐵𝐵𝑆𝑆𝑇𝑇𝑆𝑆𝑅𝑅𝑇𝑇

𝛿𝛿𝑆𝑆𝐶𝑄 1𝑆𝑆

𝛿𝛿𝑆𝑆𝐶𝑄 1𝐵𝐵

𝛿𝛿𝑆𝑆𝐶𝑄 2

𝛿𝛿𝑀𝑀𝑆𝑆𝑅𝑅𝑆𝑆𝐿𝐿𝑛𝑛𝐿𝐿 < 100𝐵𝐵

1A

1B

FINE

TRACK

FOLLOWER START

t = 𝐵𝐵0

WIDE FIELD

DETECTION

LARGE SCAN

WIDE FIELD

DETECTION

NARROW SCAN

NARROW FIELD

DETECTION

READY

TRACKING TRACKING

COMMANDED

START TIME

COMMANDED

MAXIMUM

TIME 1A

COMMANDED

MAXIMUM

TIME 1B

EXIT TO TRACKING

ON SUCCESS

OR

TO PREPARE AT

MAXIMUM TIME

TI

M

E

2.4 Effective Data Rate

The effective data rates for the primary OISL modem frame configurations are summarized in Table 2-4 as a function of the OISL baud rate. The last column of the table indicates the required support for each baud rate.

Table 2-4: Maximum Effective Data Rates for Frame Configurations Baud Rate (Mbaud)

Frame Duration (microseconds)

Effective Data Rate (Mbps)

Frame Rate (kHz)

Fast Control Channel (Mbps)

Require ment

312.5 79.795 191.290 12.532 0.201 Shall be supported

625 39.898 382.579 25.064 0.401 Should be supported

1250 19.949 765.159 50.128 0.802 Should be supported

2500 9.974 1530.318 100.257 1.604 May be supported

5000 4.987 3060.635 200.513 3.208 May be supported

10000 2.494 6121.270 401.027 6.416 May be supported

Frame duration and frame rate are a function of the frame size defined in Section 2.6.3.1. The effective data rates account for all systematic sources of overhead including preamble, header, CRC’s, FEC, and the LPC code. Note that overhead for Ethernet framing is dependent on the distribution of packet sizes and generally does not significantly impact the values in Table 2-4.

The maximum data rates tabulated in Table 2-4 are best-case, excluding any retransmissions and assuming an absence of MGMT frames.

2.5 Physical Layer

Channel Definition Each OISL shall provide an A and B channel operating at the carrier wavelengths as specified in Table 2-5. Center frequency for the channels is defined as 193.1+n×0.1 THz, consistent with ITU- T G.694.1 [3].

Table 2-5: Wavelength Channel Definition Channel Wavelength Channel Number

A 1536.61 nm n = +20

B 1553.33 nm n = -1

2.5.1.1 Center Frequency Tolerance

The transmitter center frequency shall be accurate to within a tolerance of ± 10 GHz.

2.5.1.2 Laser Line-Width

The modulated laser linewidth shall be less than 10 GHz, measured at full width at half-maximum (FWHM) over a time scale of 100 ms.

2.5.1.3 In-Band and Spillover Emissions

The laser shall transmit 95 percent of its energy within ± 20 GHz of its center frequency.

2.5.1.4 Timing Jitter

The Root Mean Square (RMS) pulse timing jitter shall be less than 10 percent of the slot width.

Transmit and Receive Wavelength Selection The transmit and receive wavelengths shall be switchable through software.

Polarization Transmitter and receiver pairs should limit polarization mismatch loss to 3 dB. This polarization mismatch loss shall be referenced to an ideal LHCP transmitter and ideal LHCP receiver.

The polarization requirements for T0 are separated into Transmitter and Receiver requirements.

Transmitter Requirements

• Transmitters should transmit signals compatible with LHCP receivers

• Transmitters should transmit LHCP signals

Receiver Requirements

• Receivers should be compatible with LHCP signals

The communications and PAT channel links shall meet the power and link budget requirements as defined in Section 2.5.4 after the permitted losses.

Power and Link Margin OISL links shall achieve the BER specified in Section 2.6.3.6 with a received irradiance summarized in Table 2-6, below, for each supported baud rate.

Table 2-6: Minimum Irradiance Baud Rate (Mbaud) Minimum Irradiance 𝜇𝜇𝜇𝜇/𝐵𝐵2

Default Maximum Irradiance 𝜇𝜇𝜇𝜇/𝐵𝐵2

312.5 30 300

625 42 420

1250 60 600

Baud Rate (Mbaud) Minimum Irradiance 𝜇𝜇𝜇𝜇/𝐵𝐵2

Default Maximum Irradiance 𝜇𝜇𝜇𝜇/𝐵𝐵2

2500 85 850

5000 120 1200

10000 170 1700

OISL transmitters shall be capable of delivering a minimum irradiance at the receiver’s aperture of 30 𝜇𝜇𝜇𝜇/𝐵𝐵2. Note that while specific OISL combinations may result in a reduction in the irradiance at the receiver’s aperture required to close the link, each transmitter shall be capable of delivering the specified minimum to ensure the ability to close the link with all receivers.

The maximum irradiance provided by the transmitter shall not exceed the remote receiver’s safety threshold. The default maximum safety threshold irradiance is defined in Table 2-6. Each receiver shall be designed to not be damaged by the irradiance values listed.

OISL links shall provide the BER specified in Section 2.6.3.6 with link margin and range as defined by Table 2-7.

Table 2-7: Required Margin at Range Link Description Range Required Margin

Space-to-space > 5000km and < = 6500 km 1 dB

Space-to-space Up to 5000 km 3 dB

Space-to-ground Up to 2800 km 3 dB

2.6 Modulation

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 the local bus 10 MHz reference clock. 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:

MI =

(Pmax − Pmin) (Pmax + Pmin) (1) as shown in Figure 2-5 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 o The tone shall be controllable (turned on and off) through remote ground command o The tone’s definition shall be controllable through remote ground command including:

Pmax Modulation Index Tone Frequency

Figure 2-5: AM Tone Tracking Modulation

Framing, Coding, Encapsulation

2.6.3.1 Framing Structure

Transmitted frames used by the OISL modem shall adhere to the structure shown in Table 2-8. 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.

Table 2-8: Modem Frame Summary Field Number of bits Number of LPC

Code Words Total Number of bits Comments

Preamble 72 N/A 72 Preamble:

7 2 ’ 77AD5B584364

1E2E26.

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

Header 256 256/16 = 16 384 See Section 2.6.3.3 Payload 16320 16320/16 = 1020 24480 See Section 2.6.3.4

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 2-8. From the values in Table 2-8, the total frame size shall be 72+384+24480=24936 bits.

2.6.3.2 Preamble Sequence

Every frame shall begin with a Preamble Sequence (PS), which is 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 2-8.

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

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

• The modem header shall implement the signaling required for the modem features described in the sections below (Table 2-9).

2.6.3.3.1 Header Fields

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

Table 2-9: Frame Header Fields Function Field Bits Description

ARQ TXFN 16 Sequence number of this (outgoing) TX frame RXFN 16 Sequence number of ACK ACK 1 ACK (1) or NAK (0) for RXFN ACK-valid 1 ACK field is only valid if ACK-valid=1

MAC FRAME_TYPE 2 00: IDLE

01: DATA

10: MGMT

11: reserved pseudo-range

TX_TS 40 TX time-stamp (frame egress)

TOD_SECONDS 6 number of seconds in time-of-day epoch : 0-

TS-applies 3 TX_ TS applies to current frame (0), preceding frames (1-7)

Fast Control Channel

FCCH_OPCODE 4 time-multiplexed control signaling

FCCH_PL 16 Payload contents depends on FCCH_TYPE reserved 7 header size divisible by 16

CRC CRC-16 16 See Section 2.6.3.6.1.

Total 128

The mapping of the fields in Table 2-9 to physical locations in the modem frame is shown in Table 2-10. Here, the column headers indicate the bit number of the byte (MSB: 𝑏𝑏7, LSB: 𝑏𝑏0) and the row labels indicate the byte number in the header Reed-Solomon codeword. The value 1 shall be assigned to all bits indicated as reserved. A CRC-16 shall be attached to the end of the header with the bits entering the CRC circuit in natural order (byte 𝜇𝜇0 to byte 𝜇𝜇13, MSB first on each byte) and attached to the header in natural order (bytes 𝜇𝜇14 and 𝜇𝜇15) as illustrated in Table 2-10.

Table 2-10: Mapping of Header Fields to Byte and Bit-locations in the Transmitted Header

2.6.3.3.2 Frame Sequence Numbers

The TX frame sequence number (TXFN, Table 2-9) 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.

2.6.3.3.3 Automatic Repeat Request (ARQ)

Header fields supporting implementation of the Automatic Repeat Request modem feature are grouped as the “ARQ” fields in Table 2-9. 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 commanded from the ground. ARQ is expected to be used for Space-to-Ground links and may be used for other links.

Only DATA and MGMT frames are be subject to ARQ. IDLE frames shall not 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. Terminals shall treat frames for which an ACK is not explicitly received as NAK’d.

The automatic repeat request scheme shall be configured with the set of parameters in Table 2-11. When operating with ARQ “on,” the receive terminal shall support these configurable ARQ parameters.

b7 b6 b5 b4 b3 b2 b1 b0 d0 TXFN[7] TXFN[6] TXFN[5] TXFN[4] TXFN[3] TXFN[2] TXFN[1] TXFN[0] d1 TXFN[15] TXFN[14] TXFN[13] TXFN[12] TXFN[11] TXFN[10] TXFN[9] TXFN[8] d2 RXFN[7] RXFN[6] RXFN[5] RXFN[4] RXFN[3] RXFN[2] RXFN[1] RXFN[0] d3 RXFN[15] RXFN[14] RXFN[13] RXFN[12] RXFN[11] RXFN[10] RXFN[9] RXFN[8] d4 1 1 1 1 ACK ACK-valid FRAME_TYPE[1] FRAME_TYPE[0] d5 TX_TS[7] TX_TS[6] TX_TS[5] TX_TS[4] TX_TS[3] TX_TS[2] TX_TS[1] TX_TS[0] d6 TX_TS[15] TX_TS[14] TX_TS[13] TX_TS[12] TX_TS[11] TX_TS[10] TX_TS[9] TX_TS[8] d7 TX_TS[23] TX_TS[22] TX_TS[21] TX_TS[20] TX_TS[19] TX_TS[18] TX_TS[17] TX_TS[16] d8 TX_TS[31] TX_TS[30] TX_TS[29] TX_TS[28] TX_TS[27] TX_TS[26] TX_TS[25] TX_TS[24] d9 TX_TS[39] TX_TS[38] TX_TS[37] TX_TS[36] TX_TS[35] TX_TS[34] TX_TS[33] TX_TS[32] d10 1 1 TOD_SECONDS[5] TOD_SECONDS[4] TOD_SECONDS[3] TOD_SECONDS[2] TOD_SECONDS[1] TOD_SECONDS[0] d11 1 TS-applies[2] TS-applies[1] TS-applies[0] FCCH_OPCODE[3] FCCH_OPCODE[2] FCCH_OPCODE[1] FCCH_OPCODE[0] d12 FCCH_PL[7] FCCH_PL[6] FCCH_PL[5] FCCH_PL[4] FCCH_PL[3] FCCH_PL[2] FCCH_PL[1] FCCH_PL[0] d13 FCCH_PL[15] FCCH_PL[14] FCCH_PL[13] FCCH_PL[12] FCCH_PL[11] FCCH_PL[10] FCCH_PL[9] FCCH_PL[8] d14 CRC-16[15] CRC-16[14] CRC-16[13] CRC-16[12] CRC-16[11] CRC-16[10] CRC-16[9] CRC-16[8] d15 CRC-16[7] CRC-16[6] CRC-16[5] CRC-16[4] CRC-16[3] CRC-16[2] CRC-16[1] CRC-16[0]

Table 2-11: ARQ Parameters Parameter Valid Range Number of bits Description

ARQ_HOLDOFF_NFRAMES 0,16,32,...4080

N=16 *(0...28-1)

8 Window size of ARQ shall be from 0 to (2^8)-1. The maximum value is 16 times 28-1=4080.

The value of

ARQ_HOLDOFF_NFRAM

ES determines the hold off time:

e.g. 256 × 80 𝜇𝜇𝐵𝐵 = 20 ms ARQ HOLDOFF TIME for

312.5 Mbps.

Window size and hold-off time are not set independently.

ARQ_MAX_RETX 0-5 3 Maximum number of retransmission attempts.

For ARQ_HOLDOFF_NFRAMES, the range of values is the range required by the interface and does not represent the range of values required to be implemented.

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

The ACK field in the Frame Header (Table 2-9) shall be ignored unless ACK-valid is set to one.

When ACK-valid is one, the ACK shall apply to the frame with sequence number RXFN.

The implementation shall buffer received frames such that, after the maximum number of retransmission attempts has been exhausted or all frames have been ACK’d, correctly received FSO frames shall be released to the Ethernet reassembly block (Section 2.6.3.7.7) in order. FSO frames for which an ACK was never received shall be dropped. This scheme produces in-order delivery of Ethernet packets to the space vehicle for all values of ARQ (including settings where ARQ is disabled).

2.6.3.3.4 Timestamps

The TX PHY shall apply a timestamp in the header of every modem frame (TX_TS field, TOD_SECONDS, Table 2-9). 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).

2.6.3.3.5 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 2-9 and Section 2.6.3.5).

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 2-12. 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 2-12: FCCH Logical Channels Description FCCH _TYPE Opcode

(4 bits) Message Rate

Link Quality Reports

LAPC_CRC_ERROR_REPORT 0000 1 Hz LAPC_RSSI_FAST 0001 100 Hz LAPC_RSSI_SLOW 0010 1 Hz LAPC_SYNC_REPORT 0011 1 Hz

LAPC_FEC_CORRECTED_ER

ROR_REPORT

0110 1 Hz

OISL

Reports

OISL_SENSITIVITY 0100 1 Hz

OISL_CAPABILITIES 0101 1 Hz

Reserved RESERVED 0111-1110 Not Present N/A 1111

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

Table 2-13: FCCH Payloads FCCH_TYPE Field Bi ts Bit Positi ons

Description

LAPC_CRC_ERROR_

REPORT

(Opcode = 0000)

LAPC_RPT_CRC_ER

ROR

16 15-0 Number of frame CRC errors in the last second.

Note: Where a CRC error bit is defined as an error in either the header or payload CRC

LAPC_RSSI_FAST

(Opcode = 0001)

LAPC_RPT_RSSI_FA

ST

14 15-2 Received Signal Power at aperture LSB = 75 nW/m² The reported value shall only cover the last 10 ms and shall not be integrated over a longer time period.

LAPC_RPT_FS_FAST 2 1-0 Frame sync status, last 10 msec.

00: not locked (experienced one or more sync losses during the period)

01: locked (for full period)

10: reserved 11: reserved

LAPC_RSSI_SLOW

(Opcode = 0010)

LAPC_RPT_RSSI_ME

AN

8 15-8 Received power at aperture mean (average, trailing 1 sec from 1 PPS, step size = -0.25086 dBm/m2)

LAPC_RPT_RSSI_SD

EV

8 7-0 Received Power at aperture standard deviation (average, trailing 1 sec from 1 PPS, step size = -0.25086 dBm/m2)

LAPC_SYNC_REPOR

T (Opcode = 0011)

LAPC_RPT_FS_LOSS 14 15-2 Number of times frame sync lost (trailing 1 sec from 1

PPS)

LAPC_RPT_FS_STAT

E

2 1-0 Frame sync status (at 1 sec sample time)

00: not locked (experienced one or more sync losses during the period)

01: locked (for full period)

10-11: reserved; reserved values shall be set to all zeros.

OISL_SENSITIVITY

(Opcode = 0100)

OISL_PMIN 8 15-8 Required optical power at aperture (step size = -0.25086 dBm/m2)

OISL_PMAX 8 7-0 Maximum RX optical power at aperture permitted (step size = -0.25086 dBm/m2)

OISL_CAPABILITIES

(Opcode 0101)

MAJOR_VERSION 5 15-11 The SDA Standard Version is specified as three integers separated by periods in the format

MAJOR_VERSION.MI

NOR_VERSION.PATC

H_VERSION. For example:

SDA Standard revision (here 2.1.2):

Major=00010;

Minor=00001;

Patch=00010

MINOR_VERSION 5 10-6

PATCH_VERSION 6 5-0

LAPC_FEC_CORREC

TED_ERROR_REPOR

T (Opcode = 0110)

LAPC_RPT_FEC_ER

RORS_CORRECTED

16 15-0 Number of frames that require FEC correction per second.

Note: Frames where an FEC correction is performed in either the header or payload

To ensure standardization of implementation for LAPC_RSSI_SLOW, the equations are shown below. The statistical measurement shall be performed on linear power readings In.

LAPC_RPT_RSSI_MEAN =

𝑁𝑁

∙ �𝐼𝐼𝑆𝑆

𝑁𝑁

LAPC_RPT_RSSI_SDEV = �

𝑁𝑁

∙ �(𝐼𝐼𝑆𝑆 − 𝐵𝐵𝐴𝐴𝑃𝑃𝐶𝐶_𝑅𝑅𝑇𝑇𝑃𝑃_𝑅𝑅𝑅𝑅𝑅𝑅𝐼𝐼_𝑀𝑀𝑀𝑀𝐴𝐴𝑁𝑁) 2

𝑁𝑁

The LAPC_RSSI_SLOW power figures inside the FCCH shall represent the received power at aperture expressed in logarithmic scale with a LSB of -0.25086 dBm/m2. This is expressed by the following formula using the LSB x:

𝐵𝐵𝐴𝐴𝑃𝑃𝐶𝐶_𝑅𝑅𝑃𝑃𝑇𝑇_𝑅𝑅𝑅𝑅𝑅𝑅𝐼𝐼_𝑀𝑀𝑀𝑀𝐴𝐴𝑁𝑁 = (𝑥𝑥 ∗ −0.25086) 𝜇𝜇𝐵𝐵𝐵𝐵

𝐵𝐵2

𝐵𝐵𝐴𝐴𝑃𝑃𝐶𝐶_𝑅𝑅𝑃𝑃𝑇𝑇_𝑅𝑅𝑅𝑅𝑅𝑅𝐼𝐼_𝑅𝑅𝐵𝐵𝑀𝑀𝑆𝑆 = (𝑥𝑥 ∗ −0.25086) 𝜇𝜇𝐵𝐵𝐵𝐵

𝐵𝐵2

Example: The mean value of 1mW (0 dBm) and 0.01mW (-20 dBm) is 0.505 mW = -2.97 dBm and not (0 dBm + -20dBm)/2 = -10 dBm

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

• LAPC_RSSI_FAST_REPORT shall be sent at rate at least 100 Hz.

• LAPC_CRC_ERROR_REPORT, LAPC_RSSS _REPORT, and LAPC_SYNC_REPORT

• LAPC_FEC_ERROR REPORT is a recommended, but optional report. If utilized, it will be sent at rate of at least 1 Hz OISL_SENSITIVITY shall be sent at 1 Hz 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.

2.6.3.4 Payload

2.6.3.4.1 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=01, Table 2-9) shall be encapsulated Ethernet traffic.

2.6.3.4.2 CRC-32

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

2.6.3.4.3 Parity Bytes

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

2.6.3.5 Special Frames

The field frame Header shall contain a FRAME_TYPE field. The FRAME_TYPE field of the frame Header (Table 2-9) 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.

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

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.6.3.6.4) except with its initial seed equal to the value of the frame header TXFN field (Table 2-9) plus one.

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

The bits from the pseudo-random binary sequence shall be written into the modem frame in the (common) order described in Section 2.6.3.5.3.2 and illustrated in Figure 2-7.

2.6.3.5.2 MGMT/PNT Frames

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

MGMT frames shall be sent at 1Hz, each holding 1 time-stamp measurement set.

Header Construction

Modem MGMT frames shall be signaled in the frame header by field FRAME_TYPE=10 (Table 2-9).

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.

The bytes comprising the MGMT frame payload shall be written into the modem frame in the (common) order described in Section 2.6.3.5.3.2 and illustrated in Figure 2-7.

Payload Frame Definition

The MGMT/PNT Frames are used to communicate OISL frame timestamps and calculated range and range timestamp between the OISLs. Table 2-14 defines the MGMT/PNT payload.

Table 2-14: MGMT/PNT Frame Payload Definition for Ranging Timestamps.

Field Bits Bit Positions Description

RX_PHY_Timestamp_sec 6 0-5 RX PHY timestamp for frame receipt Seconds of the whole GPS minute (0 Hour, January 6, 1980)

RX_PHY_Timestamp_picosec 40 6-45 RX PHY timestamp for frame receipt Picoseconds of the whole second

TX_PHY_Timestamp_sec 6 46-51 TX PHY timestamp for the same frame associated with the RX PHY Timestamp Seconds of the whole GPS minute (0 Hour, January 6, 1980)

Field Bits Bit Positions Description TX_PHY_Timestamp_picosec 40 52-91 TX PHY timestamp for the same frame associated with the RX PHY Timestamp Picoseconds of the whole second

Range_Meters

64 92-155 Computed and provided TX OISL aperture to RX OISL aperture range in meters, IEEE 754 double precision floating point format. This field must be populated.

Calculation of this field is optional - If not calculated, this field shall be set to 0 (zero).

Range_TimeStamp_sec 32 156-187 Computed range timestamp:

whole seconds of GPS time from epoch 0hour, Jan 6, 1980.

Calculation of this field is optional - If not calculated, this field shall be set to 0 (zero).

Range_TimeStamp_picosec 40 188-227 Computed range timestamp:

picoseconds of the whole second of GPS time

Calculation of this field is optional - If not calculated, this field shall be set to 0 (zero).

Timestamp_Valid 1

228 1 = range estimate is valid; 0 = range estimate is not valid.

Note: The average value of the first and last timestamp used for the range calculation shall be associated to the range measurement and reflected as Range_TimeStamp.

2.6.3.5.3 DATA/IDLE/MGMT Frame Handling

Multiplexing

The modem shall multiplex the modem frame types (FRAME_TYPE, Table 2-9) for transmission as illustrated in Figure 2-6.

Ethernet IP Core FramerEthernet

Packets

TXFN

MGMT

Payload

FIFO

FIFOIDLE Payload Generation

FIFO

Payload

FEC

FRAME_TYPE

Ethernet Frames 1912

Bytes

Bytes

Bytes

TX

PHY

Figure 2-6: Multiplexing Frame Types

Ethernet traffic shall be encapsulated (Section 2.6.3.7) and carried solely in DATA frames (FRAME_TYPE=01, per Table 2-9). If neither a DATA frame nor a MGMT frame (FRAME_TYPE=10) is ready for transmission, the modem shall continuously transmit IDLE frames (FRAME_TYPE=00). Arbitration between DATA and MGMT frames for transmission shall be implementation dependent. The offered traffic load of MGMT frames should be sparse, on the order of 0 -10 Hz, depending on the application’s PNT configuration (Section 2.6.3.7.8).

Byte Ordering and CRC-32 computation

Payload data shall be written into the modem frame in the logical order shown in Figure 2-7 for all values of FRAME_TYPE (Table 2-9). The mapping from logical order (Figure 2-7) to physical order (Figure 2-10) shall be identical for all payload types and is described in Section 2.6.3.6.3.

The payload CRC-32 shall be computed with bytes entering the CRC-32 circuit in this order (Figure 2-7): word 0: bits[7:0], bits[15:8], bits [23:16], then bits[24:31], followed by the same ordering for word 1, counting naturally through the bytes comprising the payload up through the end of word 476. The bits of each byte shall enter the CRC computer in a manner that’s equivalent to the bit-serial reference implementation of the CRC-32 (Figure 2-8) with bytes entering MSB first and LSB last.

The computed checksum shall be written into the frame (logical order, Figure 2-7) with the 32 bits exiting the CRC reference circuit written naturally into word 477 starting at bit 31 down to bit 0.

payload word 0 payload word 1 Payload word 2 payload word N pad to zero

CRC-32

One FSO Frame (1912 bytes)

CRC covering the full FSO Frame

Unused space (if any) padded to zero

Bit 0Bit 31 word 0 word 1 word 477

Always begin writing the payload at word 0

Figure 2-7: Payload Byte Ordering

After staging, the 1912 bytes shall be subject to payload FEC encoding and interleaving (Section 2.6.3.6.3). Note that for IDLE frames the number of zero-pad bytes shall be zero. The number of zero-value pad bytes for MGMT will depend on the application’s definition of the MGMT frame payload format. The MGMT frame payload shall never exceed 1908 bytes.

2.6.3.6 Error Control Coding

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

• OISLs shall achieve a decoded BER after FEC of 10-6

• OISLs should achieve a decoded BER after 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.6.3.6.1., header: 16 bits, payload:

32 bits)

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

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

2.6.3.6.1 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-8. 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 2-15 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-8: 𝑳𝑳-bit CRC Calculation Circuit

Table 2-15: CRC Polynomials Location Length Polynomial Source

Frame Header

16 bits 𝐵𝐵(𝑥𝑥) = 𝑥𝑥16 + 𝑥𝑥12 + 𝑥𝑥5 + 1 1

Frame Payload

32 bits 𝐵𝐵(𝑥𝑥) = 𝑥𝑥32 + 𝑥𝑥26 + 𝑥𝑥23 + 𝑥𝑥22 + 𝑥𝑥16 + 𝑥𝑥12 + 𝑥𝑥11 + 𝑥𝑥10 + 𝑥𝑥8 + 𝑥𝑥7 + 𝑥𝑥5 + 𝑥𝑥4 + 𝑥𝑥2 + 𝑥𝑥 + 1

2.6.3.6.2 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.6.3.6.3.

The header RS code parameters are provided in Table 2-16.

Table 2-16: Shortened Reed-Solomon Code for Frame Header Parameter Value (bytes) Comments

N 255 Number of codeword bytes K 239 Number of data bytes (including vfill bytes) vfill 223 Number of zero-valued virtual fill 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 2-9.

Figure 2-9: Header FEC Encoding

2.6.3.6.3 Payload FEC and Interleaving

The OISL payload FEC shall be adapted from the Reed-Solomon code specified in [4].

The Reed-Solomon (RS) encoding of the payload FEC shall follow the recommendations in [4] 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 ([4], 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 ([4], Section 4.3.2)

• The Galois Field generator polynomial shall be 𝐹𝐹(𝑥𝑥) = 𝑥𝑥8 + 𝑥𝑥7 + 𝑥𝑥2 + 𝑥𝑥 + 1

• The RS code generator polynomial shall be 𝐵𝐵(𝑥𝑥) = ∏ (𝑥𝑥 − 𝛼𝛼11𝑗𝑗127+𝐸𝐸 𝑗𝑗=128−𝐸𝐸 )

• 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 ([4], 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 2-10. This diagram, abstracted from ([4], 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 2-10) with the block of data bytes followed sequentially by the block of parity bytes cw0 cw1 cw2 cw3 cw4 cw5 cw6 cw7 d0 d238 p0 p15

8 bits

Data Bytes Written Column-Major

Parity Bytes Written Column-Major

8 bits d1 p1

C R C

Figure 2-10: Payload FEC Interleaving

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

Bit 7

(MSB)

Bit 0

(LSB)

First bit Transmitted Last bit Transmitted α7 α0α6 α5 α4 α3 α2 α1

Figure 2-11: Bit Ordering of Reed-Solomon Encoded Bytes

These following adaptations are made from the payload FEC framing as specified by [2]:

• The SDA OISL shall only implement the “LIA Framing” section of the [2], meaning that all incoming payloads to the FEC are fixed sized. Therefore, the 8 bytes allocated by [2], for the LIAU superframe headers are subsumed into the payload section of the FEC encoder. This increased the “data” section in Figure 2-10 from 238 to 239 bytes and conforms to a standard Reed-Solomon codeword as defined in ( [2] 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 2-10 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, we use the same LPC code as the referenced CCSDS standard except without the SysChanDat* bit, producing an LPC(24,16) code.