C3I Architecture for Interoperability and Information Exchange

1. Constellation ProgramCommand, Control, Communications and Information (C3I) Overview of the Preliminary Concepts Summarized by Will Ivancic NASA GRC

2. C3I Team Background • C3I 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 “C3I Architecture Report”, Nov. 2004. • In 2005, C3I 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, C3I team moved to CxPO and became the C3I Systems Integration Group (SIG). • 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. • C3I SIG leadership/team staffed heavily with matrix engineers from engineering and operations organizations (from almost all NASA centers). • C3I SIG is working to develop the correct set of requirements and architecture based on trades/analysis and continual technical exchange w/ L3 (as systems become more defined).

3. 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 C3I architecture is intended to address these trends

4. C3I Approach C3I 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 and 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. 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. C3I Overview 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).

5. 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, C2, and information. 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). ISO Layers C3I Layers Application Applications Presentation Framework Session Transport Protocols Network Data Link Link Interfaces Physical C3I Overview Publish & subscribe based framework abstracts communications and inter-application interfaces. It also enforces a consistent data model, any required security, and limited application interfaces.

6. Interoperability Specification only deals with the interfaces and protocols at the element interface, NOT the internal (application, API) interfaces. C3I Interoperability Specification Scope Note: For future Cx configurations, the C3I architecture will evolve to include increased C2 interoperability.

7. State-of-the-Art Comparison Future • Autonomous link negotiation • Autonomous configuration • Flexible resource allocations • Seamless interoperability between ground and space networks • Dynamic configurations • Delay tolerant networking • 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 Current • Communications • Link planning and scheduling • Manual configuration • Fixed resources allocations • 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 • Command and Control • Large, complex, single purpose facilities • Static operations models • Information Model • Ad hoc data repositories

8. Current Architecture

9. NASA Network Architecture Evolution From SCAWG Architecture Report (3/06): • DSN complexes will be replaced with large arrays of small aperture antennas (~12m) • 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 • 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 S-band community • LDPC FEC codes will be added to the standard ground processing • Integrated scheduling and service management across networks (integrated with GN, DSN)

10. Conceptual Lunar Communications Architecture

11. 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…

12. Constellation Communications “Urban Legends” • C3I’s communications are not compatible with international partners. • All layers of the C3I 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 • C3I’s data link uses international standards (RFC 2427 and ITU-T Q.922) • C3I’s implementation of IP communications follows “IP over CCSDS Space Links” recommendation (CCSDS 702.0-R-1). • C3I Comm team is working with CCSDS groups to ensure future CCSDS standards and recommendations meet Constellation communication needs • C3I’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 re-use. • 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: C3I’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

13. 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 DG1 (Modes 1-3), DG2 (SSAF/R, SMAF/R) modulations • Ka-Band (KaSAR/F) modulation • SN signal formats are supported by US, international and commercial • CCSDS “compliant” in non-Spread modes • Link Layer Formatting – CCSDS • CCSDS symbol randomization & frame synch • CCSDS FEC (Rate ½ LDPC) • CCSDS AOS Transfer Frame w/ VCA service • Data Link Layer – Provide support to IPv4 and extensibility to IPv6 • Multiprotocol Interconnect over Frame Relay (MPoFR) • Permits native use of both IPv4 and IPv6 • Use of Q.922 framing per RFC 2427 allows bridging between MPoFR and CCSDS AOS in a manner compliant with CCSDS recommendations

14. C3I 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 (IPv4, IPv6) and transport Protocols (udp, tcp), addressing, routing, multicast, manipulation of network tables and configuration, basic device management Other subsections of 3.3.1 add 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 3.2 Hardline requirements for deterministic and high volume intersystem connectivity 1394b 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 Tunneled Data Legacy Formats Network Discipline Requirements Highlights Custom Interface CEV2 Legacy 10.2.0.0/16 Element CEV1 LAN WAN 10.1.0.22 Net L1/L2 Relay Relay 10.1.0.1 GSN GS1 GS2 10.0.0.1 Ground Network MOC

15. 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 IPv6 solve these problems? • Cannot configure Net_relay interfaces w/ IPs addresses in same subnet Preliminary Work Need Validation

16. Space Routing Testbed Setup Findings: • In IPv4 hosts in different subnets cannot route. • In IPv6, routing is valid across different subnets due to link local addressing. As shown in the GS_1 to GS_2 link. Preliminary Work Need Validation

17. H P UDP H P H P UDP UDP H P H P IP H P H P H P H P IP IP FR H P H P AOS coding H P H P HDLC/FR coding H P H P (3) IP over AOS coding AOS H P H P (1) IP over HDLC/FR (if using FEC, then the HDLC/FR stream is fed to coding equipment) (2) IP over FR over AOS Link Layer Protocol: IP over HDLC or 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.

18. 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 C3I Spec calls for three interior routing protocols: RIP (C3I-82), OSPF (C3I-83), OLSR (C3I-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 C3I and will likely expose a number of areas that don’t quite mesh today. • Recommended additional study to specifically include contingency routing

19. 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: • VoIP 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

20. Networking Issues • Address assignment and management • Name to address resolution • Multicast name and address assignment • Network device management • Security • Key Management • Policy Management

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

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

23. C3I Security vs. Shuttle/ISS Security • Complex information distribution patterns • C3I solution supports automated/electronic mgmt of info distribution • Support for partnering & long-term exploration objectives • C3I 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 • C3I solution supports electronic mgmt and updating of keys

24. 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 inter-operating elements • The highly distributed environment of the Constellationrequires 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 C3I-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

25. C3I External Interactions • Overall • Efforts to date have been very limited due to the SBU nature of most C3I 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 C3I 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 C3I 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 • C3I has periodic discussions, but C3I and other NASA initiatives are somewhat ahead of where the NCOIC working group is currently

26. C3I 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 • C3I has had limited meetings and demonstrations from vendors, but generally only to understand their products – not to discuss C3I • Ready to now expand to discuss C3I 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 and control COTS vendors • C3I is planning a command and 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