Attachment 1 - SDA Transport Statement of Work (DRAFT).pdf

HQ085020R0001 Attachment 1 SOW

Page 1 of 55 Pages

STATEMENT OF WORK (SOW)

Title: Space Transport Layer Tranche 0

26 Mar 2020

Background The National Defense Strategy (NDS) acknowledges that space is vital to the U.S. way of life, our national security, and modern warfare. In an era of renewed great power competition, main-taining our advantage in space is critical to winning these long-term strategic competitions. Po-tential adversaries seek to undermine this goal by employing strategies that exploit real or per-ceived vulnerabilities in our current and planned National Security Space systems. In addition, these potential adversaries are developing and demonstrating multi-domain threats to national security much faster than we can deploy responsive space-based capabilities. The Department of Defense (DoD) established the Space Development Agency (SDA) on 12 March 2019 as a re-sponse to this problem.

SDA is responsible for defining and monitoring the Department's future threat-driven space ar-chitecture and accelerating the development and fielding of new military space capabilities nec-essary to ensure our technological and military advantage in space for national defense. To achieve this mission, SDA will unify and integrate next-generation space capabilities to deliver the National Defense Space Architecture (NDSA), a resilient military sensing and data transport capability via a proliferated space architecture primarily in Low Earth Orbit (LEO). SDA will not necessarily develop and field all capabilities of the NDSA but rather orchestrate those efforts across DoD and fill in gaps in capabilities while providing the integrated architecture.

SDA's mission begins and ends with the warfighter. SDA recognizes that sufficient or "good enough" capabilities in the hands of warfighter sooner may be better than delivering the perfect solution too late. SDA will deliver capabilities to our joint warfighting forces in two-year tranches, starting with the Transport Layer Tranche 0 (T0).

The design, build, launch, and test of the Transport Layer T0, or the warfighter immersion tranche, will be delivered in the 4th Quarter of Government Fiscal Year (FY) 2022. The Transport Layer will serve as the backbone of the architecture by providing assured, resilient, low-latency military data and connectivity worldwide to a full range of warfighter applications.

The other layers of the NDSA have a synergistic relationship with the Transport Layer, as shown in Figure 1. These are highlighted below and are integral to the NDS architecture:

• Tracking Layer, to provide global indications, warning, tracking, and targeting of ad-vanced missile threats, including hypersonic missile systems;

• Battle Management Layer, to provide architecture tasking, mission command and control, and data dissemination to support time-sensitive kill chain closure at campaign scales;

and

• Custody Layer, to provide 24x7, all-weather custody of time-sensitive, left-of-launch sur-face mobile targets (e.g., to support targeting for advanced missiles);

• Navigation Layer, to provide alternate position, navigation, and timing (A-PNT) for GPS-denied environments;

Page 2 of 55 Pages

• Deterrence Layer, to deter hostile action in deep space (beyond Geosynchronous Earth Orbit (GEO) up to lunar distances);

• Support Layer, to enable ground and launch segments to support a responsive space ar-chitecture.

Figure 1: Objective SDA architecture

Tranche Spiral Development Approach To accelerate the development and fielding of new military space capabilities to address future threats, SDA plans on using a spiral development approach through a series of Tranches. The spiral process has, in the past, been effective in repeating development processes and reducing future risk. SDA has completed its risk analysis associated with the development of the Transport Layer. The purpose of this RFP and resulting contract award(s) is to go into a proto-typing effort leading to the development and fielding of test assets for T0. As it is currently envi-sioned, for T0, the NDSA will consists of tens of space vehicles (SVs). The T0 architecture is shown in Figure 2.

Page 3 of 55 Pages

Figure 2: Tranche 0 architecture

SDA considers T0 to be a test and training spiral. There are two major outcomes of T0. The first is to experiment and demonstrate the capability of the system to integrate and provide interopera-bility with other warfighting entities. It will be the first opportunity for the warfighter to develop the necessary tactics, techniques and procedures towards movement to a more digitally enhanced warfighting capability.

The second outcome is to serve as a baseline for future Tranche development. Once T0 is launched and operating, another risk analysis is performed to determine what modifications should be made to the next Tranche. The next Tranche is designed to address deficiencies in the first Tranche and also to integrate newer technologies to either reduce development and/or opera-tional costs or to address emerging threats. New technology, tools, and ideas emerge daily. It is critically important that these technologies and ideas get integrated as quickly as possible.

There are a number of advantages to this approach. It allows SDA to monitor and reduce current and future risks. Each spiral development, through a series of Tranches, gets a thorough review and analysis, while risk is addressed early in the development process. The Tranche approach ex-pedites the delivery of advanced warfighting capabilities to the Combatant Commanders and Ser-vices. Unlike larger acquisition systems, the Tranche approach allows for modifications to be made comparatively quickly as the threat evolves or new technology becomes available. This ap-proach also allows the government to have access to higher fidelity costing especially in terms of schedule and performance.

SDA’s goal is to launch a Tranche every two years beginning in the 4th Quarter of FY 2022. As highlighted in Figure 3, this RFP covers the period of FY20 to FY22 with the end goal of getting

Page 4 of 55 Pages tens of SVs on orbit. Inherent to this Tranche is the ability to provide periodic regional access with low-latency data connectivity. SDA plans to launch an additional 150 SVs in 4th Quarter of

FY 2024.

Figure 3 - Transport Layer Schedule

Objectives The SDA, through this RFP will support the 2018 National Security Space Strategy and the 2018 National Defense Strategy. These strategies identify the requirement to shift to more resilient space architectures (proliferated) while strengthening both deterrence and warfighting options in space. The goal of SDA is to help foster a new development environment that allows the DoD space development process to become more responsive to the needs of the future National Secu-rity Space Architecture. At the heart of this objective is the means to produce and field a prolifer-ated communications enterprise that can satisfy the new space architecture focus of increasing war fighting support from space through increased resiliency and mission responsiveness. More importantly, this RFP is designed to leverage and develop “conducive” environments for work-ing with commercial partners. Inherent to this is the capacity to streamline regulatory frame-works, policies and procedures to better leverage and support the United States (U.S.) commer-cial industry.

Both strategies are designed to address the evolving threat. This is accomplished through more resilient architectures (proliferated architectures) and disaggregated space architectures. Dis-aggregated space architectures improve mission survivability by increasing the number and di-versity of targets. Disaggregation of space architectures improves resiliency by balancing cost, schedule, and performance to increase the flexibility and survivability of our space forces. Addi-tionally, it is designed to avoid threats, ensure survivability, and expedite reconstitution when re-quired.

Transport T0 has the following major goals:

1. Demonstrate a capability for the warfighters to test, evaluate and assess the capability to pass data with very low latency from the operations centers through the constellation to the warfighters, inclusive of Optical Intersatellite Links (OISLs).

2. Demonstrate the capability for the Transport Layer to send and receive wideband data from a space-based source external to the Transport Layer and to transmit those data to the ground.

Page 5 of 55 Pages

3. Demonstrate a limited battle management command, control, and communications (BMC3) functionality which includes the ability to upload and demonstrate application software.

4. Demonstrate the ability to transport bulk Integrated Broadcast System (IBS) data from various locations, accept a transmitted IBS data feed, generate an IBS message, and de-modulate an IBS message for a specific geographic area and send these results to BMC3.

5. Demonstrate the ability to store, relay, send, and receive Link-16 messages in near real time to/from a ground station over the SV’s communications links. Demonstrate the ability of the SV to transmit Link-16 messages to various users (e.g. aircraft, missile defense, naval, and ground).

6. Demonstrate the ability to maintain a common relative time reference across the constel-lation without the use of GPS.

These goals, as envisioned, will become a significant enabler for Joint All Domain Command and Control (JADC2) which will connect distributed sensors, shooters and data from all domains (maritime, land, air, space, and cyber) to all forces. The major Functional Team elements from JADC2 map directly to the space layers of SDA. For example, the JADC2’s sensing layer maps directly to SDA’s Custody and Tracking Layers.

None of these goals can be obtained without the demonstration and maturation of Optical Inter-satellite Crosslinks (OISLs) (with radio frequency (RF) crosslinks as a backup). OISLs are one of the most critical technologies required to be demonstrated for T0. T0 Transport SVs will com-municate with in-plane nearest-neighbor or next nearest-neighbor SVs via dedicated OISLs (de-pending on slew rate and time within field of view). Interoperability between OISLs is critical. In Section 0, there is a requirement identified to ensure interoperability between OISL manufactur-ing vendors. While each Tranche is designed to incorporate better designs and technology, each succeeding SV shall be designed such that interoperability is maintained with the preceding SVs from previous Tranches.

Each Transport SV will have up to four OISLs covering forward, backward, right and left rela-tive to the orbital path. T0 Transport OISLs will connect either “in-plane” (forward and back-ward) or “cross-plane” (right and left or up and down). In-plane links will connect to the nearest or next-nearest transport SV and OISL, which maintains the same relative speed between SVs.

The “cross-plane” links will be set up to allow orbital planes to communicate with each other and share data across the Transport mesh network, as well as support external users and optical links to the ground. These links must also have the proper field of regard to connect to either the ground or an alternate orbital plane. Transport SVs will have connectivity to the ground via an optical ground terminal (OGT) and a Ka-band RF downlink.

The Government has decided that proliferation of various mission functions across the space ar-chitecture is the most cost-effective means of evolving the future NDSA. Competition across all functional aspects of these commodity space vehicles is essential to reach the expected levels of cost effectiveness. The challenge is to establish and demonstrate the ability to evolve develop-ment processes and to rapidly field new capability on a significantly faster time frame than previ-ous government space systems. Successful completion of this challenge requires a higher degree of interoperability between vendor SVs and sensors than has been previously achieved.

Page 6 of 55 Pages

SDA requires that each SV be manufactured with the ability to be compatible/interoperable with another vendor’s SV. In addition to this interoperability objective, the SVs shall demonstrate op-erations through a common ground station, and various space, ground and air terminals.

SDA also recognizes that to achieve the goals highlighted in the RFP, it will probably require some teaming between centers of excellence. While SDA is not directing teaming relationships, SDA has been following the successes in the commercial sector with respect to teaming and technology applications.

Mission Tasks This section describes the mission-level requirements for the proposer during the execution of the Transport Tranche 0 development, as opposed to the following section, which captures de-tails associated with particular aspects of the project.

Note that the Government intends to provide the Contractor with a great deal of flexibility in its approach to satisfying these requirements. The Contractor should feel free to propose alternate approaches that meet the Government needs for insight and should use its own or standard indus-try practices wherever feasible.

System Engineering The Contractor shall establish a system engineering capability responsible for integrating tech-nical efforts to ensure that performance objectives of the mission are met with acceptable risk.

This function shall:

1. Develop and maintain a System Requirements Document;

2. Articulate to the Government the plan for verification of the system;

3. Provide the Government insight into key trade studies;

4. Represent the SV to SDA ground system and mission operations development;

5. Support development of a ground-space ICD;

6. Support development of a space-space ICD that allows for interoperability across vendors;

7. Address production capacity, supply chain capacity, supply chain security, and production scalability issues

8. Maintain, report, and provide the Government insight into the technical baseline;

9. Be responsible for all necessary system-level engineering activities associated with spe-cialty disciplines (e.g., contamination control, electromagnetic interference, radiation, etc.)

Space Vehicle The Contractor shall:

1. Provide the facilities, parts, materials, services and personnel to design, fabricate, assem-ble, test, and integrate the SVs;

2. Plan, manage, document, and execute subsystem, SV-level interface, and system verifica-tion.

3. Execute an environmental test plan that includes, at a minimum, static loads, vibration, alignment, thermal vacuum (or, with rationale, balance) testing, and electromagnetic com-patibility testing (for self-compatibility);

Page 7 of 55 Pages

4. Conduct testing with the mission operations team and the Satellite Operations Center (SOC) to verify spacecraft compatibility with ground system software and hardware;

5. Document integration and testing results, including conformance and non-conformance data.

6. A minimum lifetime of four years in LEO shall be required of each Tranche 0 offering

Note that, given that the SVs are being procured in lots, the Government does not require each SV to be tested to the same levels but does anticipate that some degree of workmanship testing is performed on each one. The Contractor is expected to articulate a test approach that provides an appropriate balance between testing and cost and schedule efficiency.

Project Management

The Contractor shall:

1. Develop, monitor, and maintain an Integrated Master Schedule (IMS) and regularly report performance against it to the Government;

2. Implement and maintain a risk management system to mitigate the schedule, cost, and tech-nical risks and provide insight into the risks to the Government;

3. Conduct the following life-cycle reviews:

a. Preliminary Design Review

b. Critical Design Review

c. Pre-Environmental Review

d. Pre-Ship Review

e. Flight Readiness Review

4. Support the major life-cycle reviews for the Ground Segment and Mission Operations team

5. Participate in monthly management reviews

6. Schedule a kickoff meeting no later than thirty (30) days after contract award

If the Contractor believes that an alternate review structure (e.g., combining certain reviews) meets the needs of the Government for insight into the design and understanding of challenges and risks at appropriate stages of the development, the Contractor is free to propose it.

The Contractor has a continuing obligation to inform the Government of known problems and issues and make disclosure of known risks associated with any of the activities to be conducted under this task. Deliverables shall be provided for government review and approval.

Specific Tasks Specific tasks are general requirements for the system (e.g. spectrum, launch) or specific technol-ogy areas (e.g. optical intersatellite links) which require higher fidelity explanations. Each spe-cific task under Section 0, starting with Spectrum Management, has three subheadings: general information, technical objectives, and specific requirements.

Page 8 of 55 Pages

General information is intended to provide additional details and background information for the requirement or technology area and how those details synergize with the Concept of Operations (CONOPS). Additionally, this section serves to identify other Agency requirements. For exam-ple, under Spectrum Management, the general information section highlights how federal spec-trum is granted.

Technical objectives are designed to provide a little more fidelity into the relationship between general information and the technology required to satisfy those requirements. Technical objec-tives define the requirements on the Transport Layer system.

Specific requirements are actions that the offeror is required to perform. As such, this section specifies compliance, certifications, and/or implementation requirements.

Risk Areas SDA recognizes there are a number of risk areas associated with the development and deploy-ment of T0. These are the technology areas which SDA believes incur the most risk:

• OISLs – SDA has been following OISL development and operations in the commercial sector. While we are encouraged with the number of OISL demonstrations occurring in this calendar year, it is still considered a high-risk area. SDA will be conducting its own OISL demonstrations in later calendar year 2020 but this will be after source selection.

As such, SDA is requesting for proposers to propose radio frequency (RF) crosslinks as an onboard backup and to maintain this option at least through CDR.

• Size, Weight, and Power (SWaP) – Based on the number of OISLs, Link-16, BMC3, crypto and normal SV operations, SDA understands the design trade-offs will have to ad-dress SWaP. This is especially true as SDA would prefer operations sustained on a com-moditized bus or a design which affords commodity builds.

• SV Antenna Design – SDA has conducted several technological trades associated with SV antenna design. While there is a wide range of antennas which can perform the mis-sion, SDA recommends (but does not mandate) an active electronically scanned array (AESA) antenna. Based on the number of users in an area of responsibility (AOR), an AESA is considered to be one of the few options available to electronically steer the beams to support several customers within the AOR.

• Supply Chain – SDA’s own internal studies have suggested, based on the number of commoditized bus developers/producers in the marketplace today, that adequate supply chains cannot currently handle the number of mega-constellations under development.

Within their proposals, bidders shall address critical dependencies within their supply chains, how fragile these chains are to disruption, and mitigation plans designed to over-come potential disruptions and thereby ensure SV delivery within proposed cost and schedule.

• Networking – Based on SDA’s meetings with industry, there are several vendors who have suggested that the concept of a space mesh networking constellation has been suffi-ciently addressed. The commercial mega-constellations are all in excess of 1500 SVs, larger than what will be envisioned for the Transport Layer upon completion. This would suggest that industry has developed and matured dynamic routing. While SDA leaves this

Page 9 of 55 Pages trade space open, the minimum acceptability will be deterministic routing. This is the simplest and optimum network design based on the number of SVs envisioned for T0.

Integrated Broadcast Service (IBS)

General Information

The Integrated Broadcast Service (IBS) Enterprise disseminates near real-time (NRT) tacti-cally/operationally significant intelligence and information to the warfighter, providing situational awareness, rapid threat warning, friendly force tracking, combat search and rescue, missile defense and theater missile warning and other vital data to the decision-making processes. IBS is a theater-tailored information and intelligence dissemination architecture with global connectivity that uses a standardized common data format and a common tactical terminal family and is interoperable with current and programmed tactical and strategic warfare systems. IBS is an interactive service that provides intelligence producers the means to disseminate strategic, operational, and tactical information to the warfighter via multiple transmission paths in accordance with dynamic, user-generated dissemination priorities. This information is continually refined using data from strate-gic, operational, and tactical sensors.

IBS will be integrated on the Transport Layer to modernize current capabilities to better support the warfighters requirements for worldwide timely threat warning and situational awareness (SA) information across the range of military operations. The Transport Layer will provide long-haul IBS thus providing disseminated intelligence, surveillance and reconnaissance (ISR) derived from combat information to tactical warfighters and other data users. Warfighters and decision-makers are supported through IBS dissemination of ISR data to support SA, indications & warning (I&W), threat warning, threat avoidance, force protection, friendly force tracking, target tracking, and tar-geting/engagement.

Technical Objectives

1. Transport Layer SVs shall provide bulk IBS data transport from CONUS (or other ge-ographically designated areas) to the Joint Intelligence Operations Centers (JIOCs) and/or other designated intelligence centers (e.g. 9th MI, 24th MI, Distributed Common Ground Station (DCGS) etc.). The Transport Layer SV shall provide a bent-pipe transport capability for IBS messages through Ka-band and optical links.

2. Transport Layer SVs shall be capable of sending out an IBS message set (conforming to Common Message Format (CMF), MIL-STD-6018).

3. Transport Layer SVs shall be capable of demodulating IBS data onboard and pass it to the BMC3 module. The intent is to allow for experimentation with fusion with other multi-intelligence sources being received. All data being demodulated on the space ve-hicle will be handled at the SECRET level only.

Specific Requirements Contractor shall provide and execute an IBS development, test, and verification plan to sup-port the technical objectives outlined in Section 0.

Page 10 of 55 Pages

Link-16

General Information

Link-16 is the DoD and North Atlantic Treaty Organization (NATO) primary tactical data link for Service (e.g. Army, Navy, Air Force, Marine, Missile Defense) and Defense agency command and control, intelligence and weapon systems applications. It is a secure, jam-resistant data link pri-marily using the Joint Tactical Information Distribution System (JTIDS), Multifunctional Infor-mation Distribution System (MIDS) Low-Volume Terminal (LVT) sets, and MIDS Joint Tactical Radio System (JTRS) sets. There are also several form factor versions of Link-16 equipment that are in development with reduced volume in size to fit into missiles, small ships, helicopters, and manpacks. Link-16 supports functional mission areas including joint theater air and missile de-fense, attack operations, counter-air, interdiction, suppression of enemy air defenses, close air sup-port, and time-critical targeting prosecution.

Link-16 integration into the Transport Layer will modernize current capabilities to better support the warfighters requirements for worldwide timely threat warning and situational awareness (SA) information across the range of military operations. As envisioned for future tranches, SDA’s Tracking and Custody layers will be providing time sensitive targeting solutions. Warfighters and decision-makers are supported through Link-16 dissemination of intelligence, surveillance and re-connaissance (ISR) data to support SA, indications and warning (I&W), threat warning, threat avoidance, force protection, friendly force tracking, target tracking, and targeting/engagement.

The Link-16 payload will only be present on the Group B Transport Layer SVs. See Section L for more details on the two different groups of Transport Layer SVs.

Technical Objectives

1. Group B Transport Layer SVs shall receive and transmit ground-provided Link-16 messages (through L band Link-16 network) to various users (e.g. maritime, ground, air, missile defense).

2. Group B Transport layer SVs shall receive and transmit Link-16 messages (through L band Link-16 network) from various users to the SDA Mission Operations Center

(MOC).

3. Group B Transport Layer SVs shall send, receive, store, and relay Link-16 messages in near real time to/from a ground station over SDA’s Ka-band up to the space vehicle and then down via Link-16 waveform to multiple users (e.g. aircraft, missile defense assets, naval assets, ground assets).

4. Group B Transport Layer SVs shall synchronize with the Link-16 network and transmit (L band) with a ground coverage area of 100 nautical miles in diameter.

5. Group B Transport Layer SVs shall be able to enter, synchronize and transmit into a Link-16 network.

6. Group B Transport Layer SVs shall transition the Link-16 network from one SV to another SV to extend the maximum duration of coverage.

7. Group B Transport Layer SVs shall transmit high-throughput/low latency Link-16 data through the T0 network (through multiple space vehicles in the constellation).

Page 11 of 55 Pages

Specific Requirements

1. Contractor shall engineer, develop and deploy a Link-16 capability on each Group B SV while ensuring that no modification to user equipment will be required.

2. Contactor shall ensure that the SV has the appropriate information assurance compart-mentalization to handle SECRET level Link-16 messages while operating the neces-sary other security parameters (e.g. IBS, TT&C).

3. Contractor shall provide the ability to interface with Link-16 terminal diagnostic inter-face from a ground station to report various network status and troubleshooting fea-tures. Diagnostic information shall include connection strength with each participant, metric information (how well the link is performing), and course or fine synch network participation status.

4. Contractor shall provide technical specifications, antenna modeling, and documenta-tion to support Link-16 network interoperability verifications.

5. Contractor shall provide and execute a Link-16 development, test, and verification plan to support the technical objectives outlined in Section 0.

Optical Intersatellite Links and Radio Frequency Crosslinks

General Information As of the date of this RFP, there was no accepted industry standard to which Optical Intersatellite Links (OISLs) were being built and/or manufactured for use in space applications, other than for links over 40,000 km, i.e., greater than geosynchronous range. The Consultative Committee for Space Data Systems (CCSDS) approved the Optical Communications Physical Layer (CCSDS 141.0-B-1) and Optical Communications Coding and Synchronization (CCSDS 142.0-B-1) stand-ards in August 2019. Together, the two standards define the physical and link layers of “space-to-ground and ground-to-space photon-starved links through an atmospheric channel.” [Optical Com-munications Physical Layer (CCSDS 141.0-B-1)] Specifically, they “describe the required Phys-ical Layer characteristics of the telemetry, beacon, and optional data transmission accompanying a beacon” and the Coding and Synchronization sublayer specifying the “sequence of pulsed and non-pulsed slots” [Optical Communications Physical Layer (CCSDS 141.0-B-1)] to accomplish transmission using Pulse Position Modulation (PPM).

While the new Blue Books codify the optical link characteristics and relationship between optical communication layers, interoperability among the various vendors responding to this RFP will require additional testing, collaboration and very tight coordination. Leveraging the CCSDS is the baseline for development but SDA has identified additional specifications, parameters, and infor-mation that must be interoperable with OISLs selected by various vendors. An SDA OISL Open Standard, identified below, will help ensure interoperability, but will not suffice for strong collab-oration and cooperation among industry partners. Demonstrated interoperability with various OISL vendors is a critical milestone for SDA success. Furthermore, SDA seeks to establish best practices for optical transmitters (sources) and receivers (detectors) including beam quality, OISL beam acquisition and tracking, electrical and mechanical requirements (rise time, frequency re-sponse, operating temperatures etc.), and physical interface parameters such as standardized elec-trical/mechanical connectors.

https://public.ccsds.org/Pubs/142x0b1.pdf https://public.ccsds.org/Pubs/141x0b1.pdf

Page 12 of 55 Pages

Finally, to enable and support mission robustness of the SDA Navigation mission, the OISL must provide accurate ranging/timing information of the relative distance between SDA SVs. The OISL should be capable of making intersatellite range measurements with meter level or better precision, which translates to estimating relative timing within a few nanoseconds relative to the SV on-board clock. These measurements will include both SV-to-SV and SV-to-ground measurements.

It can be expected that the ground optical terminal will be synchronized to the DoD standard for Universal Time Coordinated (UTC), with absolute position pre-surveyed to a few centimeters in accordance with the coordinate system defined by the World Geodetic System 1984 (WGS-84) providing the absolute reference for the constellation Position, Velocity, and Time (PVT).

These raw range measurements will be combined with other sensor data to compute the SV abso-lute position and time, represented as a set of predicted ephemeris parameters and clock predic-tions. The PVT processing could be accomplished within the OISL or through use of other SV processing resources. This PVT process must be able to operate independently from the onboard GPS receiver.

As OISL systems must be interoperable with other manufacturers’ OISL systems, a common standard to exchange ranging and timing data is important. Knowledge of SV PVT will be critical to proper operations of the OISL layer and will be used to enable the SDA Alternate Position, Navigation, and Timing (A-PNT) mission. These data shall at a minimum include integrated in-tersatellite range/timing measurements, and each SV’s final PVT solution. Additional data would include status of the backup GPS receiver and its PVT estimates.

For Tranche 0, SDA will establish an open Interface Control Description for Optical Intersatellite Links (OISLs), which is referred to as the “Tranche 0 Profile,” with the intent of iteratively helping industry to collaborate to ensure interoperability between OISLs from multiple vendors. While this open Interface Control Description defines many parameters for optical communications between the physical and link layers, neither CCSDS standards nor this document is sufficient to ensure interoperability. It is absolutely critical that industry develops a robust interaction, communication and collaboration among its partners.

Table 1 presents a notional baseline for interoperable design parameters. This process is expected to be iterative to refine the set of finalized parameters. Many protocol items in

Table 1 are noted as “to be defined by PDR”. SDA expects the complete set of selected vendors to have agreed on the basic interoperability requirements by Systems Requirements Review (SRR), have defined the first draft of an over-the-air interoperability ICD by Preliminary Design Review (PDR), and have reached a second, implementable draft by Critical Design Review (CDR). SDA acknowledges that the Tranche 0 ICD will not be feature-complete regarding objec-tives for future Tranches.

Page 13 of 55 Pages

Table 1 – Draft OISL Standard

Parameter Threshold Objective Notes A Wavelength: C-band (nm)

1532.68 (tunable) The center fre-quency of the optical carrier shall be tuna-ble from 193.1 + n×0.1 THz, where n is an integer ranging from -15 to 18 corre-sponding to wave-lengths in vacuum ranging from

1538.19 nm to

1564.68 nm with 100 GHz channel spacing consistent with ITU-T G.694.1

ITU Channel 56

B Wavelength: C-band (nm)

1536.61 (tunable) ITU Channel 51

Polarization Type (LEO SV to LEO SV link)

RHCP Rx compatibility RHCP Tx If not, polariza-tion maintaining then vendors must address interoper-ability between those who are

OISL Switchable TX/RX Pairing

Yes

TX Power description Each respondent will pro-pose their min and max flux at 1000, 3000, and

5000 km

Government held link margin

3 dB

Terminal Field of Re-gard (FOR) min. & max.

TBD

Modulation Format On-Off Keying (OOK) Non-Return-to-Zero

(NRZ)

Page 14 of 55 Pages

Coding LDPC-based forward er-ror correction (FEC).

To be defined by PDR.

In-flight re-programmability to support evolution from Tranche 0 ex-perimental imple-mentations to final objective interopera-bility standards.

Prior art includes

DVB-S2

(BCH+LDPC),

DOCSIS 3.1,

400ZR / 802.3ct, and CCSDS standards but

OISLs are a dis-tinct use case from existing standards.

Bit Error Rate (BER) after Forward Error Correction (FEC)

10-6 10-9 SDA desires low BERs because time-of-flight de-lays cause high retransmission la-tencies

Modem Latency 15 ms 5 ms Defined as time from photons at aperture to bits at data interface

Link Training None required. None required. Future higher-performance in-teroperability standards may re-quire link training to enable higher data rate modes.

Physical Framing Point-to-point link. In-cludes sequence numbers and automatic repeat re-quest data. May include modulation/FEC rate sig-naling and/or manage-ment data.

re-programmability to support evolution from Tranche 0 ex-perimental imple-mentations to final objective interopera-bility standards.

Prior art includes IEEE 802.3 and

802.11, 3GPP

(LTE/LTE-

A/5G), DOCSIS

3.1, and various

ITU-T and CCSDS standards but OISLs are a distinct use case from existing standards and re-quire large (20+ bit) sequence numbers.

Page 15 of 55 Pages

Payload Datagram En-capsulation/Framing

Encapsulates/frames

802.3 Ethernet frames

and possibly link manage-ment frames. Supports payload fragmentation/re-assembly across physical transmission frames.

re-programmability to support evolution from Tranche 0 ex-perimental imple-mentations to final objective interopera-bility standards.

Prior art includes

ITU-T G.7041

Generic Framing Procedure, CCSDS Generic Framing Proce-dure, and HLDC

Link management Protocol feature / exten-sion negotiation, error rate reporting, FEC and modulation rate control, tracking data exchange, ranging and synchroniza-tion data, future extensi-bility.

re-programmability to support evolution from Tranche 0 ex-perimental imple-mentations to final objective interopera-bility standards.

Prior art includes

3GPP (LTE/LTE-

A/5G), IEEE

802.11, and

CCSDS stand-ards.

Coding and Modulation Re-programmability

Adaptive Coding and Modulation

(ACM)

TBD @ SRR

OISL terminal-to-terminal timing accuracy

10 nanosecond 1 nanosecond (rms)

OISL timestamping accuracy

10 nanosecond (rms) 1 nanosecond (rms) Path to 0.3 ns (rms)

OISL ranging accuracy 3 m (rms) 10 cm (rms) OISL range rate accu-racy

N/A 1 cm / second

Point-ahead capability TBD TBD Acquisition time (sec) 100 10 Cold start Sun Exclusion Angle (+/-deg)

5 3 Operation with other bright ob-jects (Earth, Moon, etc.) in the

FOR

User terminal orbital altitude regime (km)

750 – 1250

As an informational item, Table 2 gives sample tracking and slew rate values which suffice to meet SDA use cases.

Page 16 of 55 Pages

Table 2 - Sample performance values for Pointing, Acquisition, and Tracking

Maximum Angular Tracking Rate

1 deg/sec (TBR) 3 deg/sec (TBR)

Maximum Angular Slew Rate

5 deg/sec (TBR) 15 deg/sec (TBR)

As a risk-reduction effort, radiofrequency (RF) cross links will be carried in the design of the system through CDR. While SDA is aware of the significant accomplishments in the commercial sector in the technical development for OISLs (other CCSDS efforts, on-orbit OISL demonstra-tions, DoD and commercial sector cooperation, etc.), as of release, successful operation on orbit has been limited. SDA is sponsoring and monitoring OISL on-orbit experimentation. As mitiga-tion against continued challenges with OISLs, SDA expects vendors to carry RF crosslinks in parallel with OISLs through at least CDR. By that point, SDA will make a more informed deci-sion based on the results of the on-orbit demonstrations. The crosslink behavior described should be essentially the same, although a lower bandwidth is expected than with OISLs.

Technical Objectives

1. OISLs shall support data rates of 250 Mb/s (TBR) (Threshold; T) and 1 Gb/s (TBR) (Ob-jective; O) at ranges up to 5000 km. Terminals shall support multiple lower rates for im-provements in bit error rate (BER) at long ranges and/or power reductions. SDA notion-ally suggests a set of power-of-two reductions in baud rate, e.g. 1 Gb/s, 500 Mb/s, 250 Mb/s, 125 Mb/s, and 62.5 Mb/s.

a. Baud rate signaling protocol shall be included in the controlled interoperability interface. Rate signaling possibilities include transmission-by-transmission signal-ing (similar to IEEE 802.11) or a link management protocol which negotiates a change in baud rate.

2. The OISL terminals shall be able to support full duplex capability.

a. If there are multiple wavelengths utilized within the transceiver, the OISL chan-nels shall support switching of transmit (TX) and receive (RX) wavelengths on a communications session-by-session basis. TX and RX wavelengths shall not be fixed at launch.

3. OISL terminals shall be interoperable with OISL terminals provided by other vendors.

a. Acquisition functions are an integral part of the terminal design and concept of operations. While there is certainly space for proprietary pointing and tracking hardware, at least one acquisition sequence will be part of the controlled interface to ensure that all interoperable terminals are capable of mutual acquisition.

b. Host spacecraft state knowledge will be provided to the terminal prior-to and dur-ing each link session. Predicted remote terminal state estimates will also be pro-vided to the terminal prior to each link session.

Page 17 of 55 Pages

c. All Pointing, Acquisition, and Tracking (PAT) approaches will be considered, in-cluding dedicated beacon hardware, as long as the selected vendors remain in-teroperable. However, it is desired that the eventual OISL operations will operate without dedicated beacon hardware for Pointing, Acquisition, & Tracking (PAT).

4. OISLs shall demonstrate terminal to terminal ranging, bearing, and time transfer meas-urements. Additional consideration will be given for frequency/ wavelength measure-ments. As an Objective, T0 OISLs shall support ranging at the 30 cm level and two-way synchronization message timestamping at the 1 nanosecond level.

a. Consideration should also be given to defining an evolutionary path to achieve <10 cm level ranging and <300 ps-level synchronization message timestamping.

This level of ranging and synchronization is desirable to support future A-PNT mission requirements, without a dependency on GPS.

5. OISLs shall be point-to-point links intended to accomplish data transport that could be described as deterministic in nature. The OISLs hold no responsibility for network man-agement or routing, only to transport messages between a pair of terminals who have each separately been directed by their hosts to perform a mutual acquisition sequence.

6. OISLs shall be able to communicate with an Optical Ground Terminal (OGT) in addition to the space based OISL terminals

7. OISLs shall provide in-order message transmission. The actual terminal-to-terminal in-teroperability protocol is permitted to include message interleaving, but the receiving ter-minal is expected to provide message buffering and de-interleaving so that messages exit the receiving terminal in the same order that they were provided to the transmitting termi-nal. Significant value will be placed on solutions that are built on (and ideally compliant with) existing commercial networking standards and protocols.

8. OISLs shall use an Ethernet interface for the OISL-to-Communications Payload inter-face. Generic Framing Procedure will provide more general bus interface capability in future Tranches. OISLs shall use Gigabit Ethernet or faster. That is, the terminal shall ac-cept messages from the host for transmission and deliver received messages to the host over an Ethernet interface.

a. SDA encourages that the OISL control plane, the interface that accepts host com-munications to the terminal such as spacecraft state updates or acquisition/de-ac-quisition commands, also be Ethernet (e.g. 100BASE-T), but SDA is willing to consider alternative interfaces such as SpaceWire or RS-485.

b. In order to ease Red/Black separation, SDA requires an approvable approach to Red/Black Isolation, as discussed in Section 0

c. Ranging and synchronization data shall be considered as part of the control plane.

Page 18 of 55 Pages

9. OISLs shall be agnostic to data message security protocols. OISLs shall transport en-crypted messages unaltered. Encryption is accomplished outside of the OISL terminal and optical modem.

10. Each OISL shall support the SDA OISL Open Interface Standard

11. All technical objectives for OISLs shall also apply to RF crosslinks, where applicable

Specific Requirements

1. Contractor shall provide a technical approach for implementing the data links consistent with CCSDS standards, the SDA-developed OISL standard, and the network/routing ap-proach and requirements outlined in this document. Where the implementation is not compliant, the differences should be clearly identified with rationale provided. Modifica-tions to the standards shall be delivered as non-proprietary or unrestricted for government use. An update to the standard after receipt of feedback is planned.

2. Contractor shall provide a plan to verify that Position, Navigation, and Time (PNT), com-mand and control (C2), and mission data can be transmitted via the optical cross-links to another SV node and that bits are received, frames understood, that data can be de-crypted/unwrapped (OSI level 1 – 3 only) and reassembled for packet routing. Draft ver-sions of the plan are due at PDR and final versions at CDR.

3. Contractor shall provide support for the development and refinement of the SDA OISL Open Standard

4. Contractor shall support a compatibility test with the Optical Ground Terminal

5. Contractor shall provide a plan to carry V-band crosslinks as risk mitigation at least through CDR should on-orbit OISL demonstration reveal issues which cannot be ade-quately addressed on the T0 schedule.

Networking

General Information There are attributes which have yet to be defined for small to large pLEO constellations: physical topologies, transport (multi or single network), routing protocols, full or partial mesh networking (e.g. clustering within a large constellation). SDA recognizes that as its constellation size in-creases, a flexible and dynamically distributed architecture will be required to work together in an integrated information system to support Transport/Tracking/Custody scenarios. SDA is also aware of industry research into dynamically changing topologies and interrogation-based relay routing mechanisms (e.g. interrogation-based routing with buffers). Most importantly, SDA envi-sions that its growing constellation will need to operate in two modes: a normal mode where its topology is quite predictable for optimal routing, and a quick recovery mode where outages, whether unintentional or not, will be resilient and may require an ad-hoc scheme suitable for space networking. In addition, there is still much development work that is needed to accommodate the anticipated SV densities, orbital dynamics, traffic engineering parameters, service and network

Page 19 of 55 Pages management, and desired network behaviors. All of our eventual implementations will be looking to leverage that which other industries are spearheading so that proliferated space can be just an-other communications arena that evolves rapidly through Industry leadership.

This procurement is for T0 only and will be schedule driven. As such SDA asks that contractors propose implementations that provide the best chance of on-time delivery while achieving the primary goal of a deterministic mesh network incorporating some of the important aspects of future full constellations. T0 is fielding an initial space data transport capability to assist warfighters and military planners in understanding the utility of the Transport Layer and the necessity of migrating new terrestrial network architectures to the space layer. This Tranche-0 procurement will form a constellation limited to two or three planes with well-defined (pre-planned) ground and cross-link entry points. There are developments in industry that will provide substantial benefits to future constellations; many of these require further development and could be available for SDA Transport Tranche-1. There may be opportunities to test some of the more mature technologies on Tranche-0 after demonstration of its core capabilities.

SDA expects that its proliferated LEO constellations will leverage the Open Systems Interconnec-tion (OSI) reference model (and the seven distinct groups of related functions). All nodes within the SDA architecture (Transport, Battle Management, Custody and/or Tracking) will use one or more of these seven layers to communicate and maintain SV communications. The OSI reference model itself however is not an implementation specification, yet efforts like the Consultative Com-mittee for Space Data Systems (CCSDS) help establish more definitive standards for commercial developers to ensure interoperability within space systems.

For T0, CCSDS standards should be the start point. It is the responsibility of each respondent to evaluate CCSDS standards and protocols applied to their SV networking interface, to identify shortfalls and necessary extensions or modifications to those standards, and to explain how they would ensure interoperability between their SV and those of others. The process of establishing the revised baseline for each interface will be conducted with (and between) the SV contractors prior to CDR.

Given the nature of this “enterprise level fabric” for effective assured communications, starting with Tranche 1, each element of this enterprise has to be able to be effectively and rapidly replaced or upgraded as a heterogenous subset of capability. Therefore, it is the Government’s intent to facilitate definition of the controlling framework for the SDA network architecture and we are relying on industry to play the dominant role in formalizing guidance and standards.

Additionally, since SDA will be reliant on numerous vendors for its Proliferated LEO (pLEO) constellation components, it is critical that networking standards be defined with a level of fidelity to ensure inter-constellation interoperability.

Technical Objectives

1. The Transport Layer shall demonstrate low latency routing of data from ground entry point CONUS to ground entry point OCONUS. This could be an IBS message initiated from either a Ka-band or optical uplink and terminated as an IBS message at a Joint Intel-ligence Operation Center (JIOC) or via Link-16 message to a tactical terminal.

Page 20 of 55 Pages

2. The Transport Layer shall be able to support military exercises over various AORs. This includes exercising ISR tasking and dissemination. Requests would be routed via the Transport Layer to the appropriate entity for tasking and collection and routed back to the tactical unit during the exercise.

3. The Transport Layer shall demonstrate tactical timelines when in “normal mode”. Nor-mal Mode is when the network is functioning normally without any outages.

4. The Transport Layer shall exercise the networking infrastructure for “recovery mode” and determine necessary improvements needed. The Transport Layer shall show resili-ence to situations when parts of the network are not available due to equipment malfunc-tions, adversarial attacks, or resource exhaustion. Under these circumstances, the network will need to be resilient when network connectivity is in a degraded state. Recovery Mode would best be implemented on-board, however, the short period between contract award and launch may require that much of this autonomous detection and self-healing be accomplished via the Mission Operations Center (MOC).

5. The SVs shall implement an interoperable frame standard common to all Contractors.

The standard will be defined through the activity specified in the following section.

6. Transport Layer SVs shall implement and test a simple routing/packet switching protocol that is common to all nodes in the network. Implementation of other protocols that can be supported by the data link and network layers is allowed, but there needs to be a basic im-plementation of packet routing/switching that all…