Constellation Program Command Control Communications and Information C

Constellation Program Command, Control, Communications and Information (C 3 I) Overview of the Preliminary Concepts Summarized by Will Ivancic NASA GRC

C 3 I Team Background C 3 I Architecture evaluation team formulated as CEV tasker in July 2004. Multi-center team assembled to assess interoperability and architecture approaches to address Cx needs. Participation from JSC, KSC, MSFC, GSFC, & JPL (including operations and engineering communities). Detailed supporting white papers were generated drawing on over 50 of NASA “experts” on various architecture areas (see attached list). Assessment results documented in “C 3 I Architecture Report”, Nov. 2004. In 2005, C 3 I team worked as part of the Exploration Communications & Navigation Systems (ECANS) Supported SE&I Integrated Discipline Teams (IDT) analysis and trades. Supported ERTT assessments & requirements development efforts Directed to begin development of “interoperability specification” Worked with Space Communications Architecture Working Group (SCAWG) on selection of RF link definitions. In 2006, C 3 I team moved to Cx. PO and became the C 3 I Systems Integration Group (SIG). 6/14/2021 SIG includes membership from all level 3 projects, ECANS, ISS, APO, Ops Integration, SR&QA, T&V, Mission Operations. From May-Sept ’ 06, included 100+ engineers from around NASA. Currently, ~60+ engineers. C 3 I SIG leadership/team staffed heavily with matrix engineers from engineering and operations organizations (from almost all NASA centers). C 3 I SIG is working to develop the correct set of requirements and architecture based on trades/analysis and continual technical exchange w/ L 3 (as systems become more defined). 2

Needs/Trends/Challenges Systems engineering needs and trends Increasing focus on capability-based acquisition Increasing focus on maximizing user value Increasing reliance on “systems of systems” Disproportional increase in complexity and interdependency Disproportional increase in needs for interoperability Increasing COTS, open source, reuse, and legacy integration New challenges in systems engineering and program management Integrated end-to-end emphasis, rather than individual System Long term evolutionary development, rather than short term, revolutionary Capability (ability to perform many, loosely coupled tasks), rather than functionality (ability to perform a few, very specific tasks) Lifecycle perspective, rather than acquisition focused Negotiation, rather than mandate C 3 I architecture is intended to address these trends 6/14/2021 3

C 3 I Overview Network-Centric Architecture IP based network throughout. Leverage wide range of tools, software, hardware, protocols. Open standards & established interfaces. Very flexible & extensible. Enables open architecture that can evolve. Requires architecture be established across all Cx elements. C 3 I Approach Wide area network connections can be via terrestrial infrastructure, umbilical hard-lines, or wireless (RF) links. Elements act as network nodes that route and relay traffic (as in a mesh network). 6/14/2021 C 3 I fundamentally cuts across all elements and must function as a “single system” (different from most systems which partition more along physical lines). Historically, communications, networks, command control, security, and information systems were designed and developed separately. Legacy systems optimized for given vehicle/mission vs. Cx systems which must accommodate multiple elements/vehicles AND be flexible to exploration style operations. 4

C 3 I Overview C 3 I Layers Applications Framework ISO Layers Application Presentation Session Transport Protocols Network Link Interfaces Data Link Layered approach Isolates change impacts (enabling evolution) Based on industry standards. Includes publish & subscribe messaging framework (enabling plug-n-play applications by establishing well defined data interfaces). Physical Interoperability Focus on standards and approaches that enable interoperability between elements. Establish small set of interface standards & reduce possible number of interface combinations. Requires interoperability at all layers: communications, networks, security, C 2, and information. 6/14/2021 Publish & subscribe based framework abstracts communications and inter-application interfaces. It also enforces a consistent data model, any required security, and limited application interfaces. 5

C 3 I Interoperability Specification Scope Interoperability Specification only deals with the interfaces and protocols at the element interface, NOT the internal (application, API) interfaces. Note: For future Cx configurations, the C 3 I architecture will evolve to include increased C 2 interoperability. 6/14/2021 6

State-of-the-Art Comparison Future Current Communications Link planning and scheduling Manual configuration Fixed resources allocations Autonomous link negotiation Autonomous configuration Flexible resource allocations Seamless interoperability between ground and space networks Dynamic configurations Delay tolerant networking Networks Non-routable systems in space requiring gateway functions Fully routable ground networks Static configurations Security NASA Missions as civilian assets Link layer encryption and closed networks Data protection from point to point NASA missions as “National Assets” Network layer encryption and mix of open and closed networks Data protection in motion and at rest Multiple, survivable, frameworks with common APIs Dynamic operations models Dynamic, cross-linked knowledge repositories Command Control Large, complex, single purpose facilities Static operations models Information Model 6/14/2021 Ad hoc data repositories 7

Current Architecture 6/14/2021 8

NASA Network Architecture Evolution From SCAWG Architecture Report (3/06): DSN complexes will be replaced with large arrays of small aperture antennas (~12 m) Multi-mission support will be provided to near-Earth and deep-space users Lunar is in between these cases S, X and Ka-band support Low-Density Parity Check (LDPC) FEC codes will be standard Automated, integrated scheduling systems CCSDS compliant data interfaces (AOS, SLE) Non-CCSDS implementations will require additional upgrades – but this is a new system 6/14/2021 Near Earth Relay (TDRSS) will be replenished with advanced capability space segment Ku-band will be discontinued IP-based users (MA-DAS) and IP/SLE connections will comprise the bulk of the Sband community LDPC FEC codes will be added to the standard ground processing Integrated scheduling and service management across networks (integrated with GN, DSN) 9

Conceptual Lunar Communications Architecture 6/14/2021 10

Structure of Communication Protocols Point-to-Point Links Operational – provides highly available command / telemetry path for normal operational voice, data, situational awareness. Provides radiometrics for orbit / trajectory determination and rendezvous / docking operations. High Rate – provides high volume data transfer for video, science, recorder dumps, large file transfer. Contingency Voice – provides high availability, low complexity voice communications to protect options in the event that the prime communication systems are unavailable. Recovery RF – provides communication and location capability to permit recovery of crew and vehicle post-landing. Multipoint Provides multiple user, simultaneous communications capability for EVA, proximity operations, and surface area networks. Internal Wireless Provides communication between systems and portable equipment (laptops, PDAs) Provides communication between sensors and wireless devices for location, inventory, crew biomedical data, headsets, etc… 6/14/2021 11

Constellation Communications “Urban Legends” C 3 I’s communications are not compatible with international partners. All layers of the C 3 I communications stack are mapped to CCSDS standards. SNUG references provide complete specifications for use of TDRSS. SN compatible flight hardware is readily available from European manufacturers C 3 I’s data link uses international standards (RFC 2427 and ITU-T Q. 922) C 3 I’s implementation of IP communications follows “IP over CCSDS Space Links” recommendation (CCSDS 702. 0 -R-1). C 3 I Comm team is working with CCSDS groups to ensure future CCSDS standards and recommendations meet Constellation communication needs C 3 I’s modulations are not compatible with existing ground stations. Space Network modulations are BPSK and QPSK. PN direct-sequence spread spectrum is used to provide ranging data and spectrum reuse. Data Group 2 modulations are un-spread, BPSK uplink, QPSK downlink. Commercial and international ground stations support BPSK and QPSK CCSDS RF standards call for BPSK and QPSK suppressed carrier modes Note: C 3 I’s FEC code will require addition of new decoders at ground stations. White Sands and DSN are implementing the selected code in their baselines. Ranging will require addition of SN PN ranging systems – commercially available INSNEC receiver – Made in France 6/14/2021 12

Point-to-Point Communication Protocols Supports current and planned NASA networks Follows CCSDS recommendation for “IP over CCSDS Space Links” Space Network (TDRSS) Signal Formats S-Band DG 1 (Modes 1 -3), DG 2 (SSAF/R, SMAF/R) modulations Ka-Band (Ka. SAR/F) modulation SN signal formats are supported by US, international and commercial CCSDS “compliant” in non-Spread modes Link Layer Formatting – CCSDS symbol randomization & frame synch CCSDS FEC (Rate ½ LDPC) CCSDS AOS Transfer Frame w/ VCA service Data Link Layer – Provide support to IPv 4 and extensibility to IPv 6 6/14/2021 Multiprotocol Interconnect over Frame Relay (MPo. FR) Permits native use of both IPv 4 and IPv 6 Use of Q. 922 framing per RFC 2427 allows bridging between MPo. FR and CCSDS AOS in a manner compliant with CCSDS recommendations 13

Network Discipline Requirements Highlights C 3 I Interoperability Standards Book Vol. 1, Interoperability Standards Section 3. 3. 1 IP Connectivity – Describes basic requirements for a System to be connected to a Cx IP network: Network (IPv 4, IPv 6) and transport Protocols (udp, tcp), addressing, routing, multicast, manipulation of network tables and configuration, basic device management Other subsections of 3. 3. 1 additional capability and as such are not necessarily required by all systems, for example 3. 3. 2 Dynamic Routing Between Systems – The use of routing protocols 3. 3. 4 Domain Name Service – Automation of name to address resolution 3. 3. 5 DTN (Disruption Tolerance Networking) 3. 3. 6 and 3. 3. 7 DHCP (automated addressing) support for small System 3. 3. 10 Network Management: Increased information and management capability Other Vol. 1 sections of concern Legacy Element CEV 2 10. 2. 0. 0/16 CEV 1 LAN WAN 10. 1. 0. 22 Net Relay L 1/L 2 Relay 10. 1 GS 2 GSN 10. 0. 0. 1 Ground Network 3. 2 Hardline requirements for deterministic and high volume intersystem connectivity MOC 1394 b has been selected for both 3. 5. 1 Voice Exchange: Sets codec, operations, and voice quality standards 3. 5. 2 Motion Imagery Exchange: Sets codec and operations standards 3. 5. 4 Time Exchange: Currently NTP is specified 6/14/2021 Custom Interface Tunneled Data Legacy Formats 14

Space Routing PROPOSED Network Architecture Equipment Routers Cisco 2501 Cisco 2505 2 Cisco 2621 Cisco 3640 Ethernet interfaces Issues Can hosts communicate if they are not on the same subnet? If hosts are on the same subnet, is dynamic routing possible? Can IPv 6 solve these problems? Cannot configure Net_relay interfaces w/ IPs addresses in same subnet 6/14/2021 15

Space Routing Testbed Setup Findings: In IPv 4 hosts in different subnets cannot route. In IPv 6, routing is valid across different subnets due to link local addressing. As shown in the GS_1 to GS_2 link. 6/14/2021 16

Link Layer Protocol: IP over HDLC or AOS UDP H P IP H P H P P FR HDLC/FR H P H UDP H P P (1) IP over HDLC/FR (if using FEC, then the HDLC/FR stream is fed to coding equipment) H P IP H AOS H coding AOS H P coding P P H P coding (3) IP over AOS (2) IP over FR over AOS Two studies were conducted in order to try to determine the best method of encapsulating IP for transmission over Cx RF links First study – “There is insufficient technical discriminator between the FR/HDLC and FR/HDLC/AOS options. ” Second study – Supports Frame Relay, based upon the availability of commercial products and commercial code and the separation of the link layer from the error correction code. The Frame Relay specification includes a modified form of HDLC. AOS octet stream service is included to provide regular blocks for the error correction code without the need for additional development. 6/14/2021 17

IP Routing in Space Concerns with the expected time required to propogate and age out a dynamic routes Evaluate the suitability of the dynamic routing protocols for the first two phases of the program. Current C 3 I Spec calls for three interior routing protocols: RIP (C 3 I-82), OSPF (C 3 I-83), OLSR (C 3 I-295). Conclusions: “The goal of <= 20 seconds appears achievable for both the LEO and lunar scenario. ” for both RIP and OSPF OLSR was not sufficiently developed to be evaluated, but is designed to converge faster than OSPF RIP appears weak, but was not eliminated Recommendations: Recommended follow-on work is to develop an end-to-end concept for telemetry and command flows. This concept will weave a path through a large swath of Cx and C 3 I and will likely expose a number of areas that don’t quite mesh today. Recommended additional study to specifically include contingency routing 6/14/2021 18

Networking Challenges Develop Ops Concepts: Stakeholders do not understand how IP will be used for Cx communications. Solidify Bandwidth and Data System Requirements: Work with Systems to identify and further refine resource requirements Allay fears: Vo. IP fears: Much skepticism about voice communications over IP. Service quality fears: We’re developing a traffic prioritization model, proof of concept. Routing fears: Alter the vision of widely used routing and mobility protocols as “advanced” via education and demonstration. Current thinking is to use static routes initially Many believe “static routing” is easier than dynamic routing! Time Synchronization: Time reference used for networking and navigation have dramatically different requirements 6/14/2021 19

Networking Issues Address assignment and management Name to address resolution Multicast name and address assignment Network device management Security Key Management Policy Management 6/14/2021 20

C 3 I Security Architecture: Traffic Partitioning IPsec gateways (e. g. , edge routers) ensure separation of traffic Traffic flow rules allow only authorized traffic between nodes C 2 Payload IPsec Security Gateway Note – Additional separation at application layer, where appropriate C 2 6/14/2021 IPsec Security Gateway C 2 Payload Separate VPNs ensure no payload traffic enters C 2 function (just one example of concept) Payload 21

Secure Internal-External Network Connectivity CLV CEV Downlinked data: -Science data for public release -Video for public release Flow allowed Recon. Data Ground Station -Medical data NOT for public release Data Archive Ground Station -Private email or voice conversations NOT for public release WAN High assurance controlled interface (CI) Flow prohibited to external network by CI X External (open) networks 6/14/2021 22

C 3 I Security vs. Shuttle/ISS Security Complex information distribution patterns C 3 I solution supports automated/electronic mgmt of info distribution Support for partnering & long-term exploration objectives C 3 I security architecture enables: Secure use of partner-owned, networking-capable, & DTN-capable relays Secure use of partner-owned vehicles (e. g. , for refueling) Secure interaction with partner facilities, including those in orbit & on the Moon Current manned space systems mainly secured at communications layer Lack of routable security solutions for space will hamper ability to network space assets, particularly with external partners Lack of application layer security prevents fine-grained control Key management C 3 I solution supports electronic mgmt and updating of keys 6/14/2021 23

Cx will be a Paradigm Shift NASA missions have developed their own IT infrastructures to support communications, command, control and information management, which proved to be a satisfactory solution in many cases The Constellation presents a different challenge by its increased complexity induced by the large number of simultaneously interoperating elements The highly distributed environment of the Constellation requires co -operation of many different parties, including NASA and its contractors. The accurate dissemination of information among these players will enable them to interact more effectively Numerous NASA C 3 I-enabled systems with different functionality, handling different kinds of information and made by different manufacturers should be able to take part in an overall information network and seamlessly interchange operational information 6/14/2021 25

C 3 I External Interactions Overall Efforts to date have been very limited due to the SBU nature of most C 3 I work Standards Organizations Have had an ongoing awareness-level interaction with numerous standards groups for communications and information system standards. Now working to be more involved CCSDS – multiple working groups ESA is pushing the development of a new set of interoperability and commonality standards. NASA has not been engaged in the effort for the past two years NASA, with support from C 3 I and Level III (MCC), will participate in the week-long technical meetings in January in Colorado Springs and we plan to seriously evaluate their efforts and look for areas of common need and continued interaction Object Management Group (OMG) – Space Domain Task Force XTCE is the master telemetry and command list standard now being widely accepted in industry One of the XTCE authors now on the C 3 I Info team and will present the OMG with any recommended changes, if needed, to accommodate Cx XTCE will be the first joint OMG-CCSDS standard NCOIC – Net-Centric Operations Industry Consortium – Satellite Ground Systems Working Group C 3 I has periodic discussions, but C 3 I and other NASA initiatives are somewhat ahead of where the NCOIC working group is currently 6/14/2021 26

C 3 I General Outreach – Vendor Interaction There is a lot of interest throughout the commercial products industry to either be directly involved with NASA’s Cx work or to follow the leads of Cx, as any new ideas will probably spread beyond Exploration C 3 I has had limited meetings and demonstrations from vendors, but generally only to understand their products – not to discuss C 3 I Ready to now expand to discuss C 3 I concepts with both space-domain-specific companies and general product organizations (Google? , Business Process companies, framework companies, etc. ) GSFC operates a lab of commercial vendor products and has regular interaction with most of the command control COTS vendors C 3 I is planning a command control COTS vendor day About 10 COTS vendors to be invited to a tailored industry interaction day Not related to any ongoing procurements Will be repeated at up to 5 NASA Centers Chance for Centers to better understand state of the industry and for industry to see where we are headed and to establish contacts February-March 2007 timeframe 6/14/2021 27