Attachment_C_SCaN-NextSTEP-BAA--DRAFT-Architecture-Requirements-R11.pdf

Attachment C: Architecture Requirements

National Aeronautics and Revision Status: Initial Release

Space Administration

John H. Glenn Research Center at Lewis Field

Cleveland, OH 44135

Space Relay Partnership and Services Study

Draft Architecture Requirements

Table of Contents

Attachment C: Architecture Requirements

1. General

1.1 Scope

1.2 Reference Architecture

1.3 User Service Needs

1.4 Requirements Maturity

1.5 Requirements Validation and Verification

1.6 Security

1.7 Abbreviations and Definitions

1.7.1 Abbreviations

1.7.2 Definitions

1.7.2.1 Primary Elements of the Partnerships

1.7.2.2 Supporting Elements

2. General Requirements

2.1 Flexibility to Enhance Performance over System Lifetime

2.2 User Spacecraft-initiated Services

2.3 Standards to Achieve Interoperability

2.4 Spectrum

2.4.1 Optical Spectrum

2.4.2 RF Allocations

2.5 Internetworking Services

2.5.1 Internet Protocol Version 6

2.5.2 Delay/Disruption Tolerant Networking

2.6 System IT component supply chain risk management

3. User Service Requirements

3.1 Optical Communication Services for a Variety of Orbits

3.2 User MOC-initiated Services

3.3 NASA Data Return to U.S. Based GS Only

3.4 General Optical Communications Requirements

3.4.1 Optical Communications Service for NASA Users

3.4.2 Optical Communications Service for Non-NASA Users

3.4.3 Optical Communications ISL for Other PRSs

3.4.4 Optical Receiver Sensitivity for Mission Platforms Below 36,000 km

3.4.5 Optical Power Flux Density for User Mission Platforms Below 36,000 km

3.5 System-wide Performance Requirements

3.5.1 Number of Simultaneous Network-to-User Links

3.5.2 Number of Simultaneous User-to-Network Links

3.5.3 Network to Network Interface Data Rates

3.5.4 Network-to-User Space Interface Data Rates

3.5.5 User-to-Network Space Interface Data Rates

3.5.6 Modulation

3.5.7 Link forwarding

3.5.8 Timing, Tracking and Ranging

3.5.8.1 Clock Correlation Service

3.5.8.2 Optical Range Accuracy

3.5.8.3 Doppler Range Rate - Optical Carrier

3.5.8.4 Doppler Range Rate - Data Clock

3.5.9 Network-User Ground Interfaces for Service Management

3.5.10 Network-User Ground Interfaces on Cross Support Transfer Service

3.5.11 Service Level Agreements (SLA)

3.5.11.1 PRS-PRS (Network to Network) SLA’s

3.5.11.2 PRS-User SLA’s

3.6 Service Availability

3.6.1 Critical Service Availability

3.6.2 Service Availability

3.6.3 Restoration of Service

3.6.4 Maximum Network-to-User Ground Interface User Service Handover Service

3.6.5 Maximum Network-to-User Space Interface User Service Transfer Time

3.6.6 Maximum Network-to-User Space Interface Inter-Service Transition Time

3.6.7 Quality of Service

4. NASA Optical Payload Requirements

4.1 Optical Payload Accommodation

4.2 Optical Payload Command & Control

4.3 Optical Payload Commands and Telemetry

4.3.1 Commands to the optical payload

4.3.2 Telemetry from the optical payload

4.4 Optical payload Launch Vehicle/Site Requirement

Space Relay Partnership and Services Study – Draft Architecture Requirements

1. General

1.1 Scope

The requirements provided within this Attachment constitute an initial draft of the capabilities that NASA anticipates that all Partners including NASA should meet to achieve interoperability between Partner Relay Systems (PRS) and between a PRS and User Missions. This initial set of draft requirements represents NASA’s concept of anticipated needs to facilitate the use of commercially provided optical and radio frequency (RF) space communication services. NASA is interested in hearing recommended modifications to these draft requirements to capture: a) Changes to improve industry’s ability to meet them technically, b) Changes to better align with industry’s needs to market their capabilities and achieve their targeted return on investment with manageable risk, and c) Changes to enhance interoperability or make it easier to achieve interoperability across a set of Partners. NASA is interested in hearing recommendations on phasing the deployment of services and capabilities over time from an initial capability to full capability.

1.2 Reference Architecture

The reference architecture defines a concept for near-Earth space communications with interoperability among a set of Partners that provide standardized space communications and navigation services to User missions. Partners agree to cooperate via Partnership Agreements to define interfaces required to establish an open and interoperable architecture in which multiple entities cooperate and compete to provide services to User missions. These interfaces include:

The User Services Interface that defines the communication and navigation services that Networks provide to User Missions (Customers); and

The Internetwork Interface that defines how space communications Networks interface with each other to provide services to User missions.

Two levels of context diagrams are furnished:

Community-level context diagram: Figure 1 assumes that Partnership Agreements are established between NASA and two or more Private Sector Partners as Public-Private Partnerships (PPP) for the purpose of creating a new market for space communications services similar to the terrestrial telecommunications and Internet markets. Each Partner provides a PRS capable of providing services to a set of User missions and exchanging User-related information between PRSs to accomplish end-to-end communications. The User Services Interface and Internetwork Interface define how information is exchanged at the physical, link, and network layers as well as available services and Qualities of Service (QoS). After the Partners complete definition of these standard Interfaces and develop their PRSs, User missions must adopt the User Services Interface to enable delivery of space communications services to this new commercial market. Eventually, additional Commercial Service Providers (CSP) that are not part of the original Partnership may implement networks that could voluntarily comply with the open, international Internetwork and User Services Interfaces enabling them to interoperate and provide space communications services to User Missions. The degree of interoperation is controlled by each operating entity. This context defines a market characterized by:

o A global community of Users (consumers) and PRSs (suppliers) that agree on an architecture and concepts of operation; cooperate to build open, international standards; and develop a market for space communication services.

o A set of Public and Private Sector Entities may own and operate their own networks and/or purchase commercial services.

o CSPs own and operate their own networks and earn remuneration by providing services to government, corporate and academic Users.

o Market growth can occur through voluntary adoption of the User Services Interface by other Users as well as by expansion of networks to serve other entities such as Other Government Agencies (OGA), Private Sector entities, and international entities.

o Successful implementation and profitable operation of interoperating-yet-competing PRSs is expected to attract participation from Non-Partner Relay Systems (NPRS) and additional Users stimulating market growth.

Figure 1 – Architecture for Community of Partner Relay Systems with Standard Internetwork and User Interfaces

PRS Functional Block Diagram: Figure 2 expands the detail within the PRS to define terminology used in the requirements. A PRS consists of Partner Relay(s) connected by Inter-Satellite Links (ISL), a set of Ground Stations (GS) connected to the PRs by Space-Ground Links (SGL), a Network Operations Center (NOC), and a Customer Management (CM) segment for business functions. NASA is a Partner and has its PRS, here labeled as the NASA Network to distinguish differences between a Public Sector Partner and Private Sector Partners. The NASA Network has PRs identified as NASA Relays (NR) and a Contracts and Mission Commitment segment for business functions.

One additional distinction is the NASA-provided optical payload shown as the pink

“NASA P/L" box inside PR1. This optical payload may differ from other optical payloads on the PR by being NASA-owned but with shared operations with another Partner.

Concepts for shared operations should be explored in this study. PRS1 and the NASA Network show full interoperability to the extent that a Private Sector PR (PRS2 PR1 in the figure) can communicate with the NASA Network GS as an out-of-network SGL.

Similarly, a NASA Relay can communicate with a PRS GS as an out-of-network SGL.

Figure 2 – Partner Relay System Context Diagram

NASA intends to own and operate the minimum capacity necessary to address:

Continuing research and development of optical, RF, network, security, and other technologies;

Network testing of enhancements prior to operational rollout including coordinated testing with Partners; and

Capacity needed to support User Missions that require government ownership of the network.

Consistent with the NASA Act of 1958 that requires NASA to “seek and encourage, to the maximum extent possible, the fullest commercial use of space”1 and to “encourage and provide for Federal Government use of commercially provided space services and hardware”, NASA will not offer services to users that would constitute competition with commercial providers2. NASA expects to purchase the majority of its services from commercial providers.

1 Subsection was added by the National Aeronautics and Space Administration Authorization Act, 1985, Pub. L No.

98-361, § 110(a), 98 Stat. 422, 426 (Jul. 16, 1984) 2 As defined in the NASA Act of 1958 as amended.

1.3 User Service Needs

Table 1 provides a known list of services anticipated to be provided to support future NASA missions. The table describes current services, typically link layer services, as well as anticipated services including network layer services, radio- and optimetrics, and navigation services.

Existing services are offered by one or more of the SCaN Networks. New services are listed as becoming available through the Next Gen Architecture with initial rollout in 2025. NASA is interested in feedback on recommended services and phasing service rollout.

Table 1 - User Service Needs

Service Description Layer1 Status

Forward Data Delivery Services

Forward CLTU Service

Takes data in the form of Communication Link Transmission Units (CLTU) from the mission ground system and transmits that data to a mission platform during a pass as a series of individual data units that may be concatenated

2 Existing

Forward File Service

Accepts files from a mission ground system, either in real-time or at any point prior to the time designated for transmission, and transmits them to the mission platform

7 Existing

Forward Frame Service

Allows a mission ground system to provide the SCaN Network with frames (encoded or not) in an asynchronous manner

2 Existing

Forward IP (Over CCSDS)

Sends Internet Protocol (IP) packets from a mission ground system to a mission platform, possibly using several hops over interfaces compliant with Consultative Committee for Space

Data Systems(CCSDS) standards

3 Existing

Return Data Delivery Services

Return All Frames Service

Captures frames transmitted by the mission platform and delivers them to the mission ground system

2 Existing

Return Channel Frames Service

Captures frames transmitted by the mission platform and delivers them to the mission ground system

2 Existing

Return Packet Service

Service receives frames from the mission platform, and then extracts packets from frames

2 Existing

Return File Service

Service receives files transmitted according to the CCSDS File Delivery Protocol (CFDP)

7 Existing

Return IP (Over CCSDS) Service

Sends IP datagrams from a mission platform to a mission ground system, possibly using several hops

3 Existing

Digital Video Broadcast

(DVB)

Transmits digital motion imagery including High Definition Television (HDTV) and Motion Picture Expert Group 4

(MPEG-4) audio–video streams

2 New:

Service Description Layer1 Status

Internetworking Services

IP Service Provides Internet Protocol v6 (IPv6) routed, assured delivery service of mission data using IP Security (IPSec)

3 New:

DTN Service Provides routed, assured delivery service of mission data using Delay/Disruption Tolerant Networking (DTN) protocol suite

3 New:

Network Time Service (IP)

Provides time using Network Time Protocol (NTP) over IP 3 New:

Network Time Service (DTN)

Provides time using TBD protocol over DTN 3 New:

Broadcast Service

Provides updates of the network’s state, including service availability, relay maneuvers, relay ephemeris, and other information simultaneously without the need to schedule service

2 New:

Radio- and Optimetric Services

Ranging Service Measures the light time delay between the mission spacecraft and the tracking station using RF or optical transmission

(convertible to distance)

1 RF:

Existing

Optical:

Doppler Service Measures and time tags the phase of the transmitted forward carrier and/or the received return carrier at the asset providing the Service

1 RF:

Existing

Optical:

Navigation Services

Orbit Determination (OD) Service

Determines the ephemeris of the mission platform based on available radiometric, optimetric, inertial, celestial, and optical navigation data types

7 Note 2

Trajectory & Maneuver Planning Service

Designs trajectory and maneuver plans 7 Note 2

Celeslocation Service

Determines the surface location of the mission platform on a celestial body based on available data types

7 Note 3

Service Description Layer1 Status

Notes:

1. Layer refers to the abstraction layers of the Open Systems Interconnection (OSI) model communication systems consistent with International Organization for Standardization/ International Electrotechnical

Commission 7498-1, Information Technology (IT) – OSI – Basic Reference Model (ISO/IEC 7498-1). The layers are: Layer 7 – Application; Layer 6 – Presentation; Layer 5 – Session; Layer 4 – Transport; Layer 3 –

Network; Layer 2 - Data Link; and Layer 1 – Physical.

2. Orbit Determination and Trajectory Maneuver Planning exist today for RF measurements and are functions performed by the missions. By 2025, optimetric OD will be provided. By 2025, the SCaN Network could provide these as services at the mission’s request to reduce duplication of effort across NASA. The services should be designed for commonality between the near Earth and deep space domains. The schedule for deploying the services to a particular domain or network will be driven by mission requirements.

3. Celeslocation service will be provided for planetary networks when planetary positioning system capabilities exist, e.g., LPC or MPC in the 2040 timeframe. Celeslocation is the generic form of geolocation. There should be a single design for deep space (lunar and Mars) Celeslocation service. Commonality between the near Earth service (based on GPS and GNSS with full networks offering instant kinematic solutions) and deep space service (based on partial networks offering time-integrated location solutions) needs to be assessed. The schedule for deploying the services to a particular domain or network will be driven by mission requirements.

1.4 Requirements Maturity

This document represents a point of departure for joint discussions between NASA and BAA contractors to define the requirements that eventually will be agreed to by a set of Partners moving toward commercial space communications services under a set of Partnership Agreements. Requirements in which NASA has high confidence are stated with “shall”.

Requirements specifying performance or a performance range based on NASA analysis are stated with “shall” and To Be Reviewed (TBR). Requirements specifying performance based on incomplete analysis or on which NASA seeks industry feedback without introducing NASA bias are stated as “shall” for the function and TBD for performance. Requirements that are anticipated as necessary but lack analysis and could not be described in functional terms at this point are left with empty paragraphs as placeholders for future requirements. BAA contractors are expected to respond with proposed changes to any and all requirements herein.

1.5 Requirements Validation and Verification

Due to the nature of draft, high-level requirements, the aspect of requirement validation and verification may not be fully vetted.

1.6 Security

NASA Security requirements will be provided to award recipients.

1.7 Abbreviations and Definitions

1.7.1 Abbreviations

The following abbreviations are used in this Attachment:

AO Authorizing Official

BAA Broad Agency Announcement https://www.iso.org/standard/20269.html

CCSDS Consultative Committee for Space Data Systems

CDM Continuous Diagnostics and Mitigation

CFDP CCSDS File Delivery Protocol

CLTU Communication Link Transmission Units

CM Customer Management

CNSSP Committee on National Security Systems Policy

CP Commercial Partner

CSP Commercial Service Providers

DPSK Differential Phase Shift Keying

DLR German Aerospace Center [Deutsches Zentrum für Luft- und Raumfahrt]

DTN Delay/Disruption Tolerant Networking

EESS Earth Exploration Satellite Service [spectrum]

ESL Earth-based satellite link

FCC Federal Communications Commission

FISMA Federal Information Security Management Act

FOR Field of Regard

FY Fiscal Year

GEO Geostationary [orbit]

GRACE FO Gravity Recovery and Climate Explorer Follow-On

GS Ground Station

GSO Geosynchronous Orbits

HEO Highly Elliptical Orbit

HDLC High-level Data Link Control

HDTV High Definition Television

IETF Internet Engineering Task Force

IP Internet Protocol

ISL Inter-satellite link

ISS International Space Station

IT Information Technology

ITU International Telecommunication Union

L1/L2 Sun-Earth Lagrange orbit points L1 and L2 (~1.5M km sunward and anti-sunward, respectively)

LEO Low Earth Orbit

MEO Medium Earth Orbit

MOC Mission Operations Center

MPEG-4 Motion Picture Expert Group 4

NASA National Aeronautics and Space Administration

NEN [NASA’s] Near Earth Network

NextSTEP [NASA’s] Next Space Technologies for Exploration Partnerships

NOC Network Operations Center

NPRS Non-Partner Relay Systems

NR NASA Relay [satellite]

NRn NASA Relay [satellite] number “n”

NTP Network Time Protocol

OGA Other [non-NASA] Government Agency

OSI Open Systems Interconnection

PFD Power Flux Density

PNOC Partner Network Operations Control [center]

P/L Payload

PKI Public Key Infrastructure

PNT Positioning, Navigation and Timing

PPP Public-Private Partnership

PPM Pulse Position Modulation

PR Partner Relay [satellite]

PRS Partner Relay System

PRSn Partner Relay System number “n”

PRn Partner Relay [satellite] number “n”

QoS Qualities of Service

RF Radio frequency

RFC [IETF] Request For Comments [standard]

SCaN [NASA’s] Space Communication and Navigation Office

SFCG Space Frequency Coordination Group

SGL Space to ground link (can be uni-directional or bi-directional; see context)

SGSS [NASA’s] Space Network Ground Segment Sustainment [project]

SLA Service Level Agreement

SOS Space Operations Service [spectrum]

SN [NASA’s] Space Network

SRS Space Research Service [spectrum]

TBA To Be Announced

TBD To Be Determined

TBR To Be Reviewed

TDRS [NASA’s] Tracking and Data Relay Satellite

TDRSS [NASA’s] Tracking and Data Relay Satellite System

TT&C Telemetry, Tracking and Command

UIS User Initiated Services

1.7.2 Definitions

This section includes terminology used in this document to describe various attributes of the Partnerships.

1.7.2.1 Primary Elements of the Partnerships

User or User Mission An entity that requires space communication services from Partner(s).

Private Sector Partner Any commercial entity that enters into Partnership Agreement(s) with one or more Partners.

Public Sector Partner Any non-commercial entity such as a government agency that enters into Partnership Agreement(s) with one or more Partners.

NASA SCaN Office A Public Sector Partner in the Partnership Agreements.

Partner Any Private Sector Partner or Public Sector Partner that is working collaboratively per the terms mutually defined in a Partnership Agreement to achieve interoperable space communications services.

Partners Two or more Partners bound by the terms of one or more Partnership Agreements to achieve interoperable space communications services.

Partnership The cooperative public-private relationship between the Private Sector and Public Sector Partners that are, “characterized by resource sharing, joint planning, joint contributions, and shared risk. Purpose is to leverage resources, mobilize industry expertise and networks, and bring fresh ideas to development projects.” 3 and, “a collaborative working relationship with non-governmental partners in which the goals, structure, and governance, as well as roles and responsibilities, are mutually determined and decision-making is shared.” 4

The way Partnerships differ from many U.S.

government relationships with private sector entities is:

“the private partner is not a vendor, contractor, grantee, or government-funded implementer, but rather, ideally, an equal partner invested in every stage of the partnership activity.” 5

Partnership Agreement A contractual agreement used to define the relationship between two or more entities engaging in a Partnership. The agreement defines all in-kind resources that will be made available by each Partner to the Partnership to achieve their shared objectives and enable Joint Operations (e.g., systems, facilities, personnel, scheduling/availability, monetary and other assets) and how they will be used. The Partnership Agreement also defines how Partner priorities, risks and conflicts will be handled.

System (1) The combination of elements that function together to produce the capability to meet a need. The elements include all hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose. (2) The end product (which performs operational functions) and enabling products (which provide life-cycle support services to the operational end products) that make up a system.6

Partner Relay System The system owned and operated by a Private or Public Sector Entity that is a member of a Partnership Agreement and provides space communications services to User Missions.

3 Foreign Assistance: Public-Private Partnerships (PPPs) United States Congressional Research Service (CRS) Report for Congress. Report number R41880. October 2013. PDF Page 2. Obtained online in August 2018 from:

https://www.everycrsreport.com/files/20131028_R41880_f0f5bc6b40324daa01ebd18307820e4d27f9d0e4.pdf

4 FACT SHEET: Public Private Partnerships: Getting Started. U.S. Department of State. First authored in 2009. Obtained online in August, 2018 from: https://2009-2017.state.gov/s/partnerships/releases/or/2009/121660.htm

5 Foreign Assistance: Public-Private Partnerships (PPPs) United States Congressional Research Service (CRS) Report for Congress. Report number R41880. October 2013. PDF Page 4. Obtained online in August 2018 from:

https://www.everycrsreport.com/files/20131028_R41880_f0f5bc6b40324daa01ebd18307820e4d27f9d0e4.pdf

6 NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev 2, Glossary.

https://www.everycrsreport.com/files/20131028_R41880_f0f5bc6b40324daa01ebd18307820e4d27f9d0e4.pdf https://2009-2017.state.gov/s/partnerships/releases/or/2009/121660.htm https://www.everycrsreport.com/files/20131028_R41880_f0f5bc6b40324daa01ebd18307820e4d27f9d0e4.pdf

Non-Partner Relay System

The system owned and operated by a Private or Public Sector Entity that is a not a member of a Partnership Agreement and provides space communications services to User Missions.

User Spacecraft An in-space asset owned or operated by a User Mission.

Link An interface (Optical, RF, terrestrial telco, etc.) between any two or more defined Nodes, User S/C or ground station.

Node A defined and named electronic device (e.g., relay satellite, ) that is or can be connected to a network, and is capable of creating, receiving, or transmitting information over a communications channel

Interface(s) A shared boundary in which two or more elements of a system exchange information in a mutually agreed-upon manner, e.g., hardwired or wireless connection, software protocol, or human process.

1.7.2.2 Supporting Elements

Contracts and Mission Commitment

A function within NASA’s SCaN Office plans that: 1) makes and manages contracts with Partners, and 2) approves and manages support commitments that SCaN makes to missions or other operations that require SCaN or SCaN-contracted resources.

Ground Station A definable ground-based terrestrial entity/facility comprised of systems capable of tracking and establishing communication links with one or more spacecraft simultaneously, to facilitate the exchange of real-time and/or stored, commands, telemetry and/or other scientific information, with other terrestrial or in-space entities or facilities.

Independent Operation An operation where specific Nodes owned by any member of a Partnership are operated independently from and without coordination with other Partner(s) to execute a mission support function outside of any Partnership(s).

Inter-Satellite Link A space-to-space interface between PRS Nodes. As used herein, an ISL is limited to intra- and inter-network links as opposed to relay spacecraft-to-user spacecraft links.

Joint Operation or

Partnership Operation

One or more operations where Nodes from two or more Partner Systems interface to execute a network function within the guidelines of established Partnership Agreements.

NASA Internal Terrestrial Telecom

NASA operational interfaces present between NASA terrestrial Nodes. May be used to support Joint Partnership Operations or Independent Operations.

Network Operations Center

A physical or virtual Partner entity or facility that is identified in the Partnership Agreement and is used by a Partner to manage their network(s) in support of Joint Operations or Independent Operations.

Partner NOC A Network Operations Center that is owned and managed by a Public or Private Sector Partner and is identified in one or more Partnership Agreements as a Node used to support Joint Operations or Independent Operations.

Network-User Ground Interface

A terrestrial interface between a Partner Ground Station Node and the User Ground Segment used to exchange mission data with the User.

Network-User Space Interface

Inter-Satellite Links between Partner Relay Satellites and User Spacecraft.

Ground-Ground Interface

A terrestrial interface between Partner ground segments for data transfer, network management and CM

Space-Ground Interface A satellite to ground link between Partner Relay space and ground segments

Space-Space Interface Intra-Satellite Links between Partner Relay Systems

NASA Network A combination of all of NASA’s space communication and navigation support systems on Earth and In-space

NASA NOC A Network Operations Center that is owned and managed by NASA and identified in one or more Partnership Agreements as a Node used to support Joint Operations or Independent Operations.

2. General Requirements

2.1 Flexibility to Enhance Performance over System Lifetime

The PRS shall accommodate infusion of new and enhanced technologies.

Rationale: Legacy bent-pipe communication satellites have a design life of 15 years and have performed for 25+ years. Without software-defined radios or programmable onboard processing, infusion of upgrades is limited to Ground

Station enhancements. The PRS architecture seeks methods to enable upgrading in-space assets or rapidly replacing them to facilitate continuous evolution. Onboard programmability, e.g., via uploading software or reprogramming gate arrays, and short design life with planned replenishment facilitate Partner abilities to take advantage of technology advancements in the space communications industry.

2.2 User Spacecraft-initiated Services

The PRS shall provide user mission spacecraft with communication services in compliance with a TBD standard during mission operation.

Rationale: NASA is interested in developing new capabilities for User Initiated

Services (UIS) and demand access to reduce or eliminate the need for advance scheduling of network capacity.

2.3 Standards to Achieve Interoperability

The PRS shall comply with standards that are open and internationally viable for a diverse set of service providers and mission users.

Rationale: Open and international standards are considered necessary for interoperability among different service providers and mission users. The

Standards shown in Table 2 are examples of current standards that support interoperability. The Partners will work toward agreement on interoperable interfaces and standards resulting in an Internetwork Specification and User

Services Specification.

Table 2 - Standards to Achieve Interoperability

TITLE

ORGANI-

ZATION BOOK

CURRENT

STATUS

ESTIMATED

COMPLETION

TARGET

TYPE

TM Synchronization and Channel Coding

CCSDS 131.0-B-3 ACTIVE BLUE BOOK

Encapsulation Service

133.1-B-2 ACTIVE BLUE BOOK

Real-Time Weather and Atmospheric Characterization

Data

CCSDS 140.1-G-1 ACTIVE GREEN BOOK

Optical Communications Physical Layer

CCSDS

141.0-R-1 (revised)

WORKING

DRAFT

Target: Blue

Book Optical High Data Rate Communications (1550)

CCSDS 141.10

WORKING

DRAFT

2020 Orange

[Optical] High Data Throughput: Physical Layer

CCSDS TBA PROPOSED UNKNOWN

Target: Blue

Book [Optical] High Data

Throughput: Coding and Synchronization

CCSDS TBA PROPOSED UNKNOWN

Target: Blue

Book

Atmospheric Characterization and Forecasting for Optical

Link Operations CCSDS 141.1 PROPOSED EST 2021 Magenta

Optical Communications Coding and Synchronization for High Data Rate Communications

CCSDS

142.0-R-1-v10

WORKING

DRAFT

EST 2019

Target: Blue

Book

Next Generation Uplink CCSDS 230.2-G-1 ACTIVE GREEN BOOK

Time Code Formats CCSDS 301.0-B-4 ACTIVE BLUE BOOK

CCSDS Global Spacecraft Identification Field Code

Assignment Control Procedures

CCSDS 320.0-M-7 ACTIVE MAGENTA BOOK

Radio Frequency and Modulation Systems--Part 1:

Earth Stations and Spacecraft.

CCSDS 401.0-B-28 ACTIVE BLUE BOOK

Pseudo-Noise (PN) Ranging Systems

CCSDS 414.1-B-2 ACTIVE BLUE BOOK

Variable Code and Modulation (VCM) Systems for CCSDS

CCSDS 431.1

WORKING

DRAFT

Target: Blue

Book

Tracking Data Message CCSDS 503.0-B-1 ACTIVE BLUE BOOK

IP over CCSDS Space Links CCSDS 702.1-B-1 ACTIVE BLUE BOOK

AOS Space Data Link Protocol CCSDS 732.0-B-3 ACTIVE BLUE BOOK

Unified Space Data Link Protocol

CCSDS 732.1-R-3

WORKING

DRAFT

LATE 2018

Target: Blue

Book Licklider Transmission

Protocol (LTP) for CCSDS

CCSDS 734.1-B-1 ACTIVE BLUE BOOK

Bundle Protocol Specification CCSDS 734.2-B-1 ACTIVE BLUE BOOK https://public.ccsds.org/Pubs/131x0b3e1.pdf https://public.ccsds.org/Pubs/133x1b2c2.pdf https://public.ccsds.org/Pubs/140x1g1.pdf https://public.ccsds.org/Lists/CCSDS%201410R1/141x0r1.pdf https://public.ccsds.org/Lists/CCSDS%201410R1/141x0r1.pdf https://cwe.ccsds.org/fm/Lists/Projects/DispForm.aspx?ID=627 https://cwe.ccsds.org/fm/Lists/Projects/DispForm.aspx?ID=393 https://cwe.ccsds.org/fm/Lists/Projects/DispForm.aspx?ID=394 https://cwe.ccsds.org/fm/Lists/Projects/DispForm.aspx?ID=548 https://public.ccsds.org/Lists/CCSDS%201420R1/142x0r1.pdf https://public.ccsds.org/Lists/CCSDS%201420R1/142x0r1.pdf https://public.ccsds.org/Pubs/230x2g1.pdf https://public.ccsds.org/Pubs/301x0b4e1.pdf https://public.ccsds.org/Pubs/320x0m7.pdf https://public.ccsds.org/Pubs/401x0b28.pdf https://public.ccsds.org/Pubs/414x1b2.pdf https://cwe.ccsds.org/fm/Lists/Projects/DispForm.aspx?ID=398 https://public.ccsds.org/Pubs/503x0b1c1.pdf https://public.ccsds.org/Pubs/702x1b1c1.pdf https://public.ccsds.org/Pubs/732x0b3e1.pdf https://public.ccsds.org/Lists/CCSDS%207321R3/732x0r3.pdf https://public.ccsds.org/Pubs/734x1b1.pdf https://public.ccsds.org/Pubs/734x2b1.pdf

TITLE

ORGANI-

ZATION BOOK

CURRENT

STATUS

ESTIMATED

COMPLETION

TARGET

TYPE

Schedule Aware Bundle Routing

CCSDS 734.3-R-1

WORKING

DRAFT

Target: Blue

Book Bundle Security Protocol for

CCSDS

CCSDS 734.5-R-1

WORKING

DRAFT

Target: Blue

Book Asynchronous Message

Service (AMS)

CCSDS 735.0-G-1 ACTIVE GREEN BOOK

Asynchronous Message Service (AMS)

CCSDS 735.1-B-1 ACTIVE BLUE BOOK

Digital Motion Imagery CCSDS 766.1-B-2 ACTIVE BLUE BOOK

Voice and Audio Communications

CCSDS 766.2-B-1 ACTIVE BLUE BOOK

Space Communications Cross Support--Architecture

Requirements Document

CCSDS 901.1-M-1 ACTIVE MAGENTA BOOK

Cross Support Service Management: Simple

Schedule Format Specification

CCSDS 902.1-B-1 ACTIVE BLUE BOOK

Cross Support Service Management: Planning

Information Formats

CCSDS 902.2-R-2

WORKING

DRAFT

Target: Blue

Book

Cross Support Service Management: Service Package

Data Formats

CCSDS 902.4-R-1

WORKING

DRAFT

Target: Blue

Book

Cross Support Service Management: Service

Accounting

CCSDS 902.8 UNKNOWN 2020

Target: Blue Book

Cross Support Service Management: Service

Management Utilization Request Formats

CCSDS 902.9-R-1

WORKING

DRAFT

Target: Blue

Book

Space Link Extension--Return All Frames Service

Specification

CCSDS 911.1-B-4 ACTIVE BLUE BOOK

Space Link Extension--Return Channel Frames Service

Specification

CCSDS 911.2-B-3 ACTIVE BLUE BOOK

Space Link Extension-- Space Link Extension--Forward

CLTU Service Specification

CCSDS 912.1-B-4 ACTIVE BLUE BOOK

Cross Support Transfer Services—Specification

Framework

CCSDS 921.1-B-1 ACTIVE BLUE BOOK

Monitored Data - Cross Support Transfer Services

CCSDS 922.1-B-1 ACTIVE BLUE BOOK

Tracking Data Cross Support Transfer Service

CCSDS 922.2-R-1

WORKING

DRAFT

Target: Blue

Book Cross Support Transfer

Services: Forward Frame

CSTS

CCSDS 922.4-R-1

WORKING

DRAFT

Target: Blue

Book

Cross Support Service Management: File Transfer, CCSDS 927.1-R-1

WORKING

DRAFT

Target: Blue

Book https://public.ccsds.org/Lists/CCSDS%207343R1/734x3r1.pdf https://public.ccsds.org/Lists/CCSDS%207345R1/734x5r1.pdf https://public.ccsds.org/Pubs/735x0g1.pdf https://public.ccsds.org/Pubs/735x1b1.pdf https://public.ccsds.org/Pubs/766x1b2.pdf https://public.ccsds.org/Pubs/766x2b1.pdf https://public.ccsds.org/Pubs/901x1m1.pdf https://public.ccsds.org/Pubs/902x1b1.pdf https://cwe.ccsds.org/fm/Lists/Projects/DispForm.aspx?ID=359 https://cwe.ccsds.org/fm/Lists/Projects/DispForm.aspx?ID=363 https://cwe.ccsds.org/fm/_layouts/15/listform.aspx?PageType=4&ListId=%7ba7c4ac1f-7527-4ac8-868f-e08c28545c96%7d&ID=64&RootFolder=* https://public.ccsds.org/Lists/CCSDS%209021R2/902x1r2.pdf https://public.ccsds.org/Pubs/911x1b4.pdf https://public.ccsds.org/Pubs/911x2b3.pdf https://public.ccsds.org/Pubs/912x1b4.pdf https://public.ccsds.org/Pubs/921x1b1.pdf https://public.ccsds.org/Pubs/922x1b1.pdf https://public.ccsds.org/Lists/CCSDS%209222R1/922x2r1.pdf https://cwe.ccsds.org/fm/Lists/Projects/DispForm.aspx?ID=564 https://cwe.ccsds.org/fm/Lists/Projects/DispForm.aspx?ID=493

TITLE

ORGANI-

ZATION BOOK

CURRENT

STATUS

ESTIMATED

COMPLETION

TARGET

TYPE

Ground Segment, Recommended Profile Radio Frequency and

Modulation Systems – Part 1:

Earth Stations and Spacecraft

CCSDS 401.0-B-28 ACTIVE BLUE BOOK

AOS Space Data Link Protocol CCSDS 732.0-B-3 ACTIVE BLUE BOOK

Internet Protocol Version 6

IETF

RFC 8200 ACTIVE - UPDATED JULY 2017

Internet Official Protocol Standards

[NOTE 1]

IETF

RFC 3000 ACTIVE - UPDATED MARCH 2013

IPv6 Node Requirements

[NOTE 2]

IETF

RFC 6434 ACTIVE - UPDATED OCTOBER 2015

Delay-Tolerant Networking TCP Convergence Layer

Protocol

IETF

RFC 7242 ACTIVE - UPDATED JUNE 2014

Still and Motion Imagery Metadata Standard

NASA NASA STD-

ACTIVE –UPDATED SEPTEMBER 2013

[1] Standards in RFC 3000 are included in this specification except where superseded by IETF RFC 6434 for use with

IPv6. Standards only required to support Internet Protocol Version 4 (TBR) are excluded from this specification.

[2] RFC 6434 is the latest “roll-up” of common, base-level protocols required for Internet nodes to operate with IPv6 protocol. This RFC has noted errata, NASA is examining IPv6 best practices for inclusion in Partnership

Agreements under this BAA activity.

2.4 Spectrum

2.4.1 Optical Spectrum

The PRS shall provide optical services over the wavelength range shown in Table 3.

Rationale: This optical range is defined in CCSDS 141.0-R-1. This band is used to enable the reuse of advances and industrial investment in the fiber-optic industry, and to provide strong eye safety. Channelization will be in accordance with the 100

GHz grid defined in ITU-T G.694.1. The NASA-provided optical payload complies with this allocation. This allocation is not regulated in the U.S. by the Federal

Communications Commission (FCC); regulations vary in other countries.

Table 3 - Optical bands planned for the PRS

Wavelength (nm)

1564.68 to

1530.33

Frequency (THz)

191.6 195.9

2.4.2 RF Allocations

The PRS shall provide space communication services to federal users in an ITU approved communication band or demonstrate path to approval (e.g., government or commercial allocated frequency bands defined in Table 4).

https://public.ccsds.org/Pubs/401x0b28.pdf https://public.ccsds.org/Pubs/732x0b3e1.pdf https://tools.ietf.org/html/rfc8200 https://tools.ietf.org/html/rfc3000 https://tools.ietf.org/html/rfc6434 https://tools.ietf.org/html/rfc7242 https://standards.nasa.gov/standard/nasa/nasa-std-2822 https://standards.nasa.gov/standard/nasa/nasa-std-2822

Rationale: Table 4 provides an inventory of possible operating service bands for federal Users, including any related limitations or restrictions. Specific frequency bands to be used by the Partner will be negotiated with NASA. All bands permit both Federal and non-Federal operations except where noted.

Table 4 - RF allocations available for use by the PRS for Service to Government Users

Low (MHz)

High (MHz)

Band Allocation (Direction) Notes and Limitations

2025 2110 S

Space Operation (SOS) (Earth-to-space) (space-to-space)

Earth Exploration- Satellite (EESS) (Earth-to-space) (space-to-space)

Space Research (SRS) (Earth-to-space) (space-to-space)

Space services “shall not constrain the deployment of the Television Broadcast

Auxiliary Service”

Non-Federal “subject to such conditions as may be applied on a case-by-case basis”

U.S. Federal channel limit = 5 MHz

2200 2290 S

SOS (Earth-to-space) (space-to-space)

EESS (Earth-to-space) (space-to-space)

SRS (Earth-to-space) (space-to-space)

Exclusive Federal allocation, but band has significant non-Federal use: launch vehicles, temporary mobile systems, pre-coordinated non-Federal satellites with Federal interest (e.g., ISS commercial cargo); non-Federal space stations explicitly permitted to use

TDRSS (at 2287.5 MHz)

U.S. Federal channel limit = 5 MHz

Tech limits (e.g., power flux density (PFD))

7190 7250 C

SRS (Earth-to-space)

EESS (Earth-to-space) [ITU table]

Adding EESS allocation to U.S. table expected but in process

Emissions to deep space are prohibited

8025 8400 X EESS (space-to-Earth)

Non-Federal “subject to a case-by-case electromagnetic compatibility analysis”

Tech limits (e.g., PFD)

8450 8500 X SRS (space-to-Earth) SFCG recommended 10 MHz channel limit

Tech limits (e.g., PFD)

22550 23150 K/Ka

Inter-satellite Service

(ISS)

SRS (Earth-to-space) [ITU table]

Adding SRS allocation to U.S. table expected but in process

Tech limits (e.g., out-of-band emission limits)

Low (MHz)

High (MHz)

Band Allocation (Direction) Notes and Limitations

23150 23550 K/Ka ISS Tech limits (e.g., out-of-band emission limits)

25250 25500 K/Ka ISS ISS limited to SRS and EESS applications

24450 24750 K/Ka Inter-satellite Service

(ISS)

Example: NASA/DLR GRACE FO (ranging cross links)

25500 27000 K/Ka

ISS

EESS (space-to-Earth)

SRS (space-to-Earth)

ISS limited to SRS and EESS applications

ISS secondary for non-Federal, limited to SRS/EESS use

EESS (space-to-Earth) non-Federal “subject to a case-by-case electromagnetic compatibility analysis”

Tech limits (e.g., PFD)

2.5 Internetworking Services

The PRS shall provide IP-based space internetworking services in compliance with IETF standards end-to-end.

Rationale: Extending the capability being implemented in Near Earth Network

(NEN) and Space Network (SN)/Space Network Ground Segment Sustainment

(SGSS).

2.5.1 Internet Protocol Version 6

The PRS shall utilize the IETF IP Version 6 (RFC 8200) standard and all related and dependent standards, e.g., Internet Official Protocol Standards, RFC 3000, as network-layer protocols for IP-based space communication services.

Rationale: This ensures compliance to current and emerging internetworking communication protocols and interoperability between space and terrestrial communications networks. Limiting IP service to IPv6 is intended to enhance network security and reduce flight software overhead compared to dual IPv4/v6 compatibility. Legacy IPv4 protocols may be supported but require a waiver to provide service to federal users due to security issues.

2.5.2 Delay/Disruption Tolerant Networking

The PRS shall provide DTN space internetworking services compliant with IETF Bundle Protocol Specification, RFC 5050, CCSDS 734.2-B-1, and the IETF Licklider Transmission Protocol, RFC 5325, RFC 5325, and RFC 5327.

Rationale: The DTN Bundle Protocol is designed to run over the Licklider Transport

Protocol. The remainder of the DTN protocol suite is under development and will become applicable as they become approved standards.

https://tools.ietf.org/html/rfc8200 https://www.rfc-editor.org/info/rfc3000 https://www.rfc-editor.org/info/rfc5050 http://tools.ietf.org/html/rfc5325 http://tools.ietf.org/html/rfc5326 http://tools.ietf.org/html/rfc5327

2.6 System IT component supply chain risk management

The PRS shall be developed using components that are sourced in accordance with Federal and NASA supply chain risk management procedures.

Rationale: Federal law requires that NASA use of IT resources be sourced from trusted locations and companies. Definition of IT resources can be provided upon request.

3. User Service Requirements

3.1 Optical Communication Services for a Variety of Orbits

The PRS shall provide bidirectional relay optical communications services between users in Earth-based, LEO, MEO, GEO, HEO, cis-lunar, and L1/L2 orbits.

Rationale: Support for this capability is included in the SCaN Office FY 2019

Planning, Programming and Budget Execution Program and Resources Guidance.

PR satellites are not required to be placed in Geosynchronous Orbits (GSO). They may be located in other orbits and may have a field of regard (FOR) that includes portions of the zenith direction and/or the ability to close links beyond GEO over the limb of the Earth. This may be a growth capability.

3.2 User MOC-initiated Services

The PRS shall provide users with Mission Operations Center (MOC) support for requesting communication services in CCSDS Simple Schedule format during the mission planning process and during mission operation.

Rationale: Simple schedule format and protocol intended for cross support of missions by cooperating international space agencies is defined in CCSDS 902.1-B-

1, Simple Schedule Format Specification.

3.3 NASA Data Return to U.S. Based GS Only

The PRS shall be capable of delivering NASA mission data relayed by one or more PR satellites to a GS located in US territory without passing through a GS in foreign territory.

Rationale: This capability is needed to reduce the latency of data transport from outside the US terrestrially and to avoid issues of laws and regulations regarding data landing rights for foreign GSs. The PRS could deliver user mission data through a foreign territory if required to meet the user’s needs.

3.4 General Optical Communications Requirements

3.4.1 Optical Communications Service for NASA Users

The PRS shall provide optical communication services for NASA-owned user spacecraft and NASA-owned optical GSs.

Rationale: The PR satellite must deliver data for NASA user missions between the user’s space and ground segments. It must also be capable of interoperating with

NASA’s optical GSs.

3.4.2 Optical Communications Service for Non-NASA Users

The PRS shall provide optical communication services for non-NASA user spacecraft.

Rationale: This requires delivery of data between user (customer) spacecraft using optical communications and the PR satellite for relay via the Partner GS to the user ground segment.

3.4.3 Optical Communications ISL for Other PRSs

The PRS shall provide optical communications between the PR satellite and another Partner’s PR satellite.

Rationale: Optical communications via ISL between two Partners’ PR satellites is required for interoperability to enable additional relay coverage and routing diversity. Each PRS should support interoperability between networks for cross support and more robust end-to-end user service with appropriate accounting for the cross support between Partners.

3.4.4 Optical Receiver Sensitivity for Mission Platforms Below 36,000 km

The PRS shall provide return services for a user mission below 36,000 km with receiver sensitivity of TBD photons/bit at optical payload aperture.

Rationale: The NASA-provided optical payload will have this performance capability. For information purpose only.

3.4.5 Optical Power Flux Density for User Mission Platforms Below 36,000 km

The PRS shall provide forward services for a user mission below 36,000 km with Power Flux Density of TBD at optical payload aperture.

Rationale: This performance is necessary to meet each user mission's needs for data quality which also depends on user mission platform telescope, detector sensitivity, range from user mission platform to NASA asset, and the loading of the user mission transponder, (i.e., the modulation, coding, and frequency assignment of the various carriers within the transponder). The optical payload is expected to have 20-cm aperture, and 20W power.

3.5 System-wide Performance Requirements

3.5.1 Number of Simultaneous Network-to-User Links

The PRS shall support 2-7 (TBR) simultaneous Network-to-User space interfaces.

Rationale: Provide services equivalent to the capability currently provided by

NASA’s TDRSS constellation. The requirement is stated in terms relative to a PR in

GSO and may have to be restated to remove the orbit bias.

3.5.2 Number of Simultaneous User-to-Network Links

The PRS shall support 2-7 (TBR) simultaneous User-to-Network space interfaces.

Rationale: Provide services equivalent to the capability currently provided by

NASA’s TDRSS constellation. The requirement is stated in terms relative to a PR in

GSO and may have to be restated to remove the orbit bias.

3.5.3 Network to Network Interface Data Rates

The PRS shall interface with another PRS over space-to-space and space-to-ground interfaces at data rates of 10 Gbps and 100 Gbps.

Rationale: These data rates are essential for the Internetwork Interface. The optical payload can be used for either space-to-space ISL or space-to-ground SGL.

3.5.4 Network-to-User Space Interface Data Rates

The PRS shall support Network-to-User Space Interfaces with data rates shown in Table 5.

Rationale: User mission platforms need a variety of data rates. Not all data rates in these ranges need to be available. The data rates available may vary by modulation scheme, PRS asset being used, or characteristics of the equipment.

Table 5 - Network-to-User Space Interface Data Rates [1]

Band Minimum Maximum

Ka-band 1 ksps 50 Msps

Optical 2 Mbps [2] 2.5 Gbps

[1] The data rates available may vary by PRS asset and user link parameters.

[2] The NASA optical payload will not support data rates this low, but other PRS payloads have the option to.

3.5.5 User-to-Network Space Interface Data Rates

The PRS shall support User-to-Network Space Interfaces with symbol rates shown in Table 6.

Rationale: This performance is necessary to meet each user mission's needs for data quality which also depends on user mission platform telescope, detector sensitivity, range from user mission platform to the PR.

Table 6 - User-to-Network Space Interface Data Rates [1]

Band Minimum Maximum

Ka-band 300 ksps 1.2 Gsps

Optical C-band 2 Mbps 10Gbps

[1] The data rates available may vary by PRS asset and user link parameters.

3.5.6 Modulation

The PRS shall support Differential Phase Shift Keying (DPSK) and Pulse Position Modulation (PPM) modulations in accordance with CCSDS standards.

Rationale: DPSK is the High Data Rate capability and PPM is needed when the spacecraft receives very low signal strength, such as cis-lunar or beyond distances.

On Off Keying (OOK), as a subgroup of PPM, may also be an option.

3.5.7 Link forwarding

The PRS infrastructure systems shall provide link layer forwarding services.

Rationale: Link-layer forwarding services are needed for non-DTN users. In link forwarding service, no guarantee of delivery is provided.

3.5.8 Timing, Tracking and Ranging

The following items are essential for disadvantaged users that cannot carry a GPS module on their spacecraft

3.5.8.1 Clock Correlation Service

The PRS shall provide time transfer measurement with TBD accuracy of link data clock period.

Rationale: Based on optical data clock recovery. NASA optical payload meets the

10% performance and will try to comply with the 1% performance.

3.5.8.2 Optical Range Accuracy

The PRS shall provide optimetric tracking service with a 1-sigma range accuracy of 1-10% of the link data clock period [TBR].

Rationale: Optometric tracking requires the end user terminal to have its transmit clock tied to the recovered receive clock. NASA optical payload meets the 10% performance and will try to comply with the 1% performance.

3.5.8.3 Doppler Range Rate - Optical Carrier

The PRS shall provide optimetric Doppler range rate tracking of at least 160 mrad/sec [TBR] of the return link optical carrier.

Rationale: The performance goal is based on the optical carrier recovery at 10% of the quarter phase measurement. This service requires coherent demodulation to provide the phase tracking. Optometric tracking requires the end user terminal to have its transmit clock tied to the recovered receive clock. NASA optical payload will try to meet this objective performance.

3.5.8.4 Doppler Range Rate - Data Clock

The PRS shall provide optimetric Doppler range rate tracking of at least 16 -160 mrad/sec [TBR] of the link data clock.

Rationale: Optometric tracking requires the end user terminal to have its transmit clock tied to the recovered receive clock. NASA optical payload meets the 160 mrad/sec performance and will try to meet the 16 mrad/sec performance.

3.5.9 Network-User Ground Interfaces for Service Management

The PRS shall provide a service management interface (e.g., schedule, service configuration) in compliance with:

1) Cross Support Service Management Simple Schedule, CCSDS 902.1-B-1.

2) Service Management Specification (pending release).

3)…