Constellation ProgramCommand, Control, Communications and Information C3I Overview of the Preliminar

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 SEI 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,
  SRQA, TV, 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 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
• 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.

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
C3I Overview

• 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).

• 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.

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
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.
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 tole
rant networking NASA missions as National Ass
ets Network layer encryption and mix of open and
closed networks Data protection in motion and at
rest Multiple, survivable, frameworks with co
mmon 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-D
AS) and IP/SLE connections will comprise the bulk
of the S-band community LDPC FEC codes will be ad
ded 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

• C3Is 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
  
• C3Is data link uses international standards (RFC
  2427 and ITU-T Q.922)
  
• C3Is 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
  
• C3Is 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 C3Is 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
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
• 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

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
GS1
GS2
GSN
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
  

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.

17
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 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 dont 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 Were 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 laye
r, where appropriate
C2
Payload
22
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 conversatio
ns NOT for public release
Flow allowed
Ground Station
Data Archive
Recon. Data
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
C3I Security CONOPS - Cryptography

• Authentication and encryption capabilities at
  network layer for all IP based inter-System data
  exchanges (when not directly attached)
  
• Double authentication/encryption is avoided
  through policy mgmt
  

25
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
  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

26
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

27
C3I General Outreach Vendor Interaction

• There is a lot of interest throughout the
  commercial products industry to either be
  directly involved with NASAs 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