Transcript Constellation Program Command, Control, Communications and Information (C3I) Overview of the Preliminary Concepts

Constellation Program
Command, Control, Communications and
Information (C3I)
Overview of the Preliminary Concepts
Summarized by Will Ivancic
NASA GRC
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).




5/19/2016
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).
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
C3I architecture is intended to address these trends
5/19/2016
3
C3I 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.
 C3I 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).
5/19/2016
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.
4
C3I Overview
C3I 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, C2, and
information.
5/19/2016
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
C3I 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 C3I architecture
will evolve to include increased C2 interoperability.
5/19/2016
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 and Control


Large, complex, single purpose facilities
Static operations models
 Information Model

5/19/2016
Ad hoc data repositories
7
Current Architecture
5/19/2016
8
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





5/19/2016
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
5/19/2016
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…
5/19/2016
11
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 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: 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
5/19/2016
12
Point-to-Point Communication Protocols
 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



5/19/2016
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
IPv6
Multiprotocol Interconnect over Frame Relay (RFC 2427)
MPoFR (Frame Relay) Framing (ITU-T Q.922)
Space Link Layer
AOS VCA (CCSDS 732.0-B-2)
(Uncoded)
LDPC FEC (CCSDS 131.1-O-1)
ASM (CCSDS 131.0-B-1)
Symbol Randomization (CCSDS 131.0-B-1)
NRZ-M Symbol Coding
(LDPC does not use NRZ-M)
SN Modulations
DG 1 Mode 1
(SpreadSpectrum)
S-Band

Data Link Layer
DG 2 (Unspread)
DG1 Mode 3
(SpreadSpectrum, High
Rate
Unbalanced)
Ka-Band
 Follows CCSDS recommendation for “IP over
CCSDS Space Links”
IPv4
 Supports current and planned NASA networks
13
Network Discipline Requirements Highlights
 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
Legacy
Element
CEV2
10.2.0.0/16
CEV1
LAN
WAN
10.1.0.22
Net
Relay
L1/L2
Relay
10.1.0.1
GS1
GS2
GSN
10.0.0.1
Ground
Network
 3.2 Hardline requirements for deterministic and high
volume intersystem connectivity

MOC
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
5/19/2016
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 IPv6 solve
these problems?
 Cannot configure
Net_relay
interfaces w/ IPs
addresses in same
subnet
5/19/2016
15
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.
5/19/2016
16
Link Layer Protocol: IP over HDLC or AOS
UDP H P
UDP H P
UDP H P
IP H P H P
IP H
P
H
IP H
P
FR
HDLC/FR H
P
H
P
(1) IP over HDLC/FR (if
using FEC, then the
HDLC/FR stream is fed
to coding equipment)
H
P
P
H
AOS H
coding
AOS H
P
H
P
coding
P
P
H
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.
5/19/2016
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 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
5/19/2016
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:
 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
5/19/2016
19
Networking Issues





Address assignment and management
Name to address resolution
Multicast name and address assignment
Network device management
Security
 Key Management
 Policy Management
5/19/2016
20
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
Payload
IPsec
Security
Gateway
IPsec
Security
Gateway
Note – Additional
separation at application
layer, where appropriate
C2
5/19/2016
IPsec
Security
Gateway
C2
Payload
Separate VPNs ensure
no payload traffic enters
C2 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
-Medical data NOT for public
release
Recon.
Data
Ground
Station
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
5/19/2016
22
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
5/19/2016
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 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
5/19/2016
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
5/19/2016
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
5/19/2016
27