Transcript (25Jun)hooke-IOAG-Summary-Jun07

Summary of IOAG-11
Adrian Hooke (NASA) and Nestor Peccia (ESA)
CCSDS Technical Liaisons
IOAG-11
June18, 2007
Cebreros, Spain
Contents
1. Summary of highlights of IOAG-11
2. CCSDS Liaison Report to IOAG-11
3. JAXA, NASA, ESA Service Architecture
Proposals
2
IOAG-11 AGENDA
http://www.ioag.org/IOAG-11/IOAG-11_home.htm
http://www.ioag.org/IOAG-11/IOAG-11_presentations_&_%20briefings.htm
3
IOAG-11 HIGHLIGHTS
•
Manfred Warhaut will relinquish the IOAG Chairmanship;
Klaus-Juergen Schulz replaces him
ISRO (S.K. Shivakumar) admitted as the 7th. Member of the
IOAG
Continued progress on Agency deployment of SLE
Closed-out all IOAG-8 Resolutions to CCSDS and opened a
more limited IOAG-11 set to move forward
Resonance on approach towards Service Architecture:
•
•
•
•
•
•
•
Agreement to establish new “IOAG Space Internetworking
Strategy Group” (2-year horizon)
•
•
•
JAXA, ESA and NASA presentations
IOAG will maintain a core Cross Support Service Catalog
Co-chairs: Paolo Maldari/ESA and John Rush/NASA
Strong opinions from ESA, CNES, BNSC and JAXA about nonstandard IP encapsulation using serial HDLC stream
Need for supplementary information re: NASA Coding,
Modulation and Link Protocols (CMLP) study
4
2. CCSDS Liaison
Report to IOAG
5
IOAG-08 RESOLUTIONS
(Res 8.5.1)
REQUEST FOR A FRAMEWORK FOR CROSSSUPPORT SERVICE ARCHITECTURE
(Res 8.5.1)
REQUEST FOR A FRAMEWORK FOR A CROSSSUPPORT SERVICES CATALOG
(Res 8.1.1)
(Res 8.4.1)
(Res 8.3.1)
(Res 8.7.1)
URGENT NEED FOR A SLE MANAGEMENT SERVICES
RECOMMENDATION
ADVICE ON CROSS-SUPPORT TRANSFER SERVICES
WORKING GROUP CHARTER
ADVICE FOR SIMPLIFICATION OF RF & MOD.
RECOMMENDATIONS
REQUEST FOR A HIGH RATE COMMANDING
RECOMMENDATION
(Res 8.8.1)
REQUEST FOR A DELTA DOR RECOMMENDATION
(Res 8.2.1)
CCSDS STRATEGIC PLAN: SUGGESTED
MODIFICATIONS
6
(8.1.1 and 8.4.1)
CCSDS Cross Support Services Area
7
(8.1.1) Service Management Working Group (SMWG):
Current Plan of Major Activities
Key Activity
Date
Document Production Track
Red 2
Conceptual Analysis
Specific Analysis
of Ranging &
Radiometric SM
Concept of Operations (Green Book)
SLE SM Red 2 Production
Red2 XML
schema
Red2 Agency
review
Interoperations/Demo Track
Updated, completed
Conceptual Analyses for
committed Red-2
production, updates
June 07
Intermediate Meeting (Red-2
production check,
adjustments)
June 07
Detailed analysis for
management of Ranging,
Radiometric Services
Oct 07
Operations Concept Green
Book
Oct 07
Red-2 (Submission to
Secretariat)
Dec 07
XML Schema Update (Red-2
Compliance)
Jan 08
Prototype Interoperations
(Red-1 Compliant)
Apr 07–
Apr 08
Red-2
DSN Red-1 Compliant Prototype
JAXA Red-1Compliant Prototype
Red-1
ESA Red-1 Compliant Prototype
CCSDS
Winter
Jan 2007
SMWG
Intermediate
Jul 2007
CCSDS Fall
Jan 2008
CCSDS
Spring
Jul 2008
Inclusion of management of ranging and radiometric
service is unlikely for Red-2.
Per IOAG resolution 8.1.1, deferment of the inclusion
of management of this service is preferred over a
delay in production of Red-2..
Current targeted Red-2 book does provide support for
management of these services via its allowance for
bilaterally defined service configuration profiles and
bilaterally defined event sequences.
8
(8.1.1) Service Management Working Group (SMWG):
Summary Status
Service
Management
Recommendation
Red-2
1st
Priority
Current projection for submission of Red-2 to
secretariat is now December 2007 (was
September 2007)
• ~40% of overall work required
for Red-2
completed
-Excluding ranging, radiometric service management
• Marginal resources: production mostly being
done by NASA
W3C XmlSchema
2nd
Priority
OK; Schema updates to be sequenced after
Red-2 updates
At least two
independently
developed
interoperable
prototypes
2nd
Priority
Prototype activities are underway
Green (Concept)
Book
3rd
Priority
•JPL: prototype ready to support inter-
operations as of April 2007
•ESA: current status indicates interoperations
starting ~October
•JAXA: current status indicates
interoperations starting ~September
Current projection is that basic Green Book will
be available in time for Red-2 Review
•Very slim production resources from BNSC
•Insufficient resources for producing advance
use cases in document
Best Practices Book 4th
Priority
No resources available
9
(8.3.1) RF & Modulation Simplifications
Work is in progress in the SLS RFM Working Group:
• CCSDS (401) recommendations 2.4.17A and 2.4.17B
are both being reworked:
Pink sheets will be available for CCSDS Agency review
in November 2007
• Simultaneously, an update of the Green Book (413) is
in progress to reflect the changes in 401:
The Green Book will be submitted to CESG/CMC for
approval in November 2007
10
(8.7.1) High Rate Uplink
• The HRU Working Group met in Colorado Spring in January 2007 but could not identify any
substantive mission requirements:
• Neither ESA (Aurora) nor NASA (Constellation) were able to share their mission scenarios associated with high rate
uplinks
• Accordingly, the HRU Working Group sent a request (April 2007) to the IOAG agencies asking for
assistance in the assembly of a set of definitive requirements:
• Until such mission scenarios and requirements are assembled, the CCSDS HRU Working Group
cannot move forward. IOAG assistance is urgently solicited.
11
(8.8.1) Delta DOR
•
•
Operational Control Centre
The revised DeltaDOR Operations
(draft Green Book)
is ready for review
by the CESG.
Ground Station 1
1
Antenna 1
Rx
ODM
Storage
4
2
Correlator
The plan is to
publish the Green
Book in the 2nd. half
of 2007
Ground Station 2
Antenna 2
6
Rx
Storage
2
5
Reduced Data
Quasar
I/F
Data
1 DOR Tones
2 Raw Data
3 Service to tranfer
data
4 ODM
5 Reduced Data
6 Quasar Catalogue
(Radio Signals)
3
Priority
High
Availability
Medium Term
Low
High
Long term
Long term
High
High
Low
Covered by
Allocated to
Partially covered by existing standard SLS Ranging WG
(CCSDS 401 (2.5.6B)B-2)
It will be discussed in the next BB
update
Not covered
Partially in CSS. Transfer implies
Raw data, ODM, Reduced Data
NAV ODM Standard (BB)
NAV TDM Standard to be checked
Available
Medium Term
Available end 07
Long term
JPL Quasar catalogue available
tbd BOF
CSS Area
MOIMS NAV WG
MOIMS NAV WG
tbd BOF
12
(8.2.1) CCSDS Strategic Plan
•
The main comments of the IOAG are paraphrased as follows:
1. The Plan should be more than just a vision: a major driver is the
development of a long term architecture for cross support
services.
2. There are no clear connections to the forward-looking plans of
the various space agencies
3. Planning for standards infusion is not covered well
4. Member agencies are not engaged in the infusion of each new
recommendation
5. It is unclear how CCSDS Area objectives and goals are
ascertained
•
The CCSDS Strategic and Operating Plans have to be read
together. Both have to be reworked (not only considering
IOAG comments, but also internal CCSDS discussions)
13
(8.2.1) CCSDS Strategic Plan
• CCSDS agrees that the Strategic Plan should be updated
according to Comment 1
• Comment 2 should be discussed with the IOAG.
1.
2.
3.
4.
5.
The Plan should be more than just
a vision: a major driver is the
development of a long term
architecture for cross support
services.
There are no clear connections to
the forward-looking plans of the
various space agencies
Planning for standards infusion is
not covered well
Member agencies are not engaged
in the infusion of each new
recommendation
It is unclear how CCSDS Area
objectives and goals are
ascertained
Sometimes the forward looking future of the Agencies is
vague, or concentrates in only one domain (e.g.,
Exploration but not Earth Observation)
• CCSDS agrees that the Strategic Plan should be updated
to reflect Comment 3. However, the IOAG needs to engage
in the infusion process and needs to provide regular input
to CCSDS.
• CCSDS feels that no Strategic Plan will guarantee the
infusion of a new recommendation within an Agency
(consider, for example, the CFDP). Comment 4 should be
considered in the response to Comment 3.
• CCSDS agrees that the Strategic and Operating Plans
should be updated to reflect Comment 5: however, the
IOAG needs to supply a user input
14
An Emerging Issue:
Evolution towards Space Internetworking
•
There is an emerging consensus that space missions will desire to evolve towards
a networked (multi-hop) model of operations:
• There is general agreement that the Internet Protocol (IP) suite will work in short•
•
delay, richly connected space communications environments.
There is general agreement that the emerging Disruption Tolerant Networking (DTN)
protocol suite is needed for many space communications environments where the IP
suite will not work well, or will not work at all.
There is no current consensus as to how to achieve this evolution. The major
issues include:
• Where to terminate the space link protocol (i.e., where on the ground the routed IP or
•
•
•
•
DTN operations begin)
Whether IP is the ubiquitous long-term choice of networking protocol.
How IP will be transferred over the space link using current CCSDS standards (DTN
is not an issue as it is being designed-into the CCSDS suite).
How to provide the most general cross-support solution. The current IP proposals
focus on “IP-over-AOS”. ESA spacecraft do not support AOS and therefore ESA
spacecraft running IP will require cross-support of CCSDS-standard IP packet
insertion in conventional TM/TC.
These issues involve implementation choices in ground infrastructure. They are
therefore issues that the IOAG will soon need to address.
15
3. Service Architecture Proposals:
JAXA
NASA
ESA
16
JAXA
CROSS SUPPORT
SERVICE ARCHITECTURE
Takahiro Yamada (JAXA/ISAS)
19 June 2007
Purpose of This Presentation
•
•
•
JAXA
Review the contents of the Cross Support Service
Architecture document developed as the response to the
following action item assigned to JAXA at IOAG-10.
• Action Item 6: Develop a framework showing high level crosssupport architecture containing organizational,
administrative, and functional features of services for crosssupport services.
As the response to action item 6, we distributed to the IOAG
members a document that described a framework of cross
support service architecture at the end of December 2006.
Since we did not receive any negative comments on the
framework document, we proceeded to develop a document
that defines the cross support service architecture (IOAG
XXX.0-W-1.0), and distributed it to the IOAG members at the
beginning of June 2007.
18
JAXA
Cross Support Service Architecture
• The cross support service architecture expands the
conventional “service-provider/service-user”
model to include both space and ground users.
Space
Service
Users
Space
Services
Cross Support
Service System
(Service provider)
Ground
Services
Ground
Service
Users
• The scope of the architecture is limited to four
views:
• Service View
• Physical View
• Communications View
• Enterprise View
19
JAXA
Simple Configuration
• A cross support service element has two interfaces
(or two sets of interfaces).
• The interface (or the set of interfaces) closer to the
•
space user element is called the space side interface
The interface (or the set of interfaces) closer to the
ground user element is called the ground side interface
Space side interface
of CSSE 1
Space
User
Element
Ground
User
Element
CSSE
S1
Ground side interface
of CSSE 1
20
JAXA
Cascaded Configuration
•
•
There are cases in which a space user element and a ground
user element are supported by two or more CSSEs.
This figure shows such an example, in which a space user
element (a spacecraft) and a ground user element (a
spacecraft control center) are supported by CSSE1 (a data
relay satellite) and CSSE2 (a ground terminal for the data
relay satellite).
Space side interface
of CSSE 1
Space
User
Element
Space side interface
of CSSE 2
CSSE
1
CSSE
2
Ground side interface
of CSSE 1
Ground
User
Element
Ground side interface
of CSSE 2
21
JAXA
Examples of Service View
Space
Service
Utili zation
Cross
Support
Service
Provision
Ground
Service
Utili zation
Space
User Element
Cross Support
Service E lement
Ground
User Element
Space
Service
Utili zation
Cross
Support
Service
Provisio n 1
Cross
Support
Service
Provisio n 2
Ground
Service
Utili zation
Space
User Element
Cross Support
Service E lement 1
Cross Support
Service E lement 2
Ground
User Element
22
JAXA
Service Management
Cross
Support
Service
Provision
Service
Provision
Mngmnt
Cross Support
Service Element
Service
Utili zation
Mngmnt
Utili zation
Management
Element
23
JAXA View: Basic Cross Support Services
JAXA
Cross Support
Service Type
Forward
Delivery
Services
Return
Delivery
Services
Basic Cross
Support Service
Forward Bitstream
Delivery Service
Cross Support
Service Type
Tracking
Services
Forward CLTU
Delivery Service
Forward Packet
Delivery Service
Forward File
Delivery Service
Return Bitstream
Delivery Service
Return Frame
Delivery Service
Return Packet
Delivery Service
Return File
Delivery Service
Time Service
Voice and
Video Services
Basic Cross
Support Service
Radio Metric Data
Service
Delta-DOR Service
Orbit Determination
Service
Spacecraft Time
Correlation Service
Voice Service
Video Service
Note:
1. IP service is not viewed necessary for the
IOAG cross support purposes other than that
for communications in close proximity.
2. The method of “bit stream encapsulation” of
the IP over HDLC frame over AOS frame, as
suggested by NASA, is not recommended for
IOAG cross support purpose.
24
An Example of Physical View
JAXA
Space
User Element
(Mars Lander)
CSSE2
(Ground
Station)
CSSE1
(Mars Relay
Satellite)
CSSE3
(Ground
Station)
Ground
User Element
(Lander Control
Center)
25
An Example of Communications View
Space
Service
Utilization
Cross
Support
Service
Provision
Ground
Service
Utilization
Space
Protocol 2
Space
Protocol 2
Ground
Protocol 2
Ground
Protocol 2
Space
Protocol 1
Space
Protocol 1
Ground
Protocol 1
Ground
Protocol 1
Space
User Element
Cross Support
Service E lement
JAXA
Ground
User Element
26
An Example of Enterprise View
Supporting Agency
JAXA
Supported Agency
Space
User
Element
CSSE 1
CSSE 2
CSSE 3
CSSS
Cross
Support
Service
Agreement
Ground
User
Element
27
Procedure for
Cross Support Service Agreement
JAXA
1. Each member Agency must specify (1) policies and
conditions for providing cross support services, (2)
documents used for agreement on cross support services
and establishment of cross support interfaces, and (3)
pricing information. This information should be
documented in a Service Catalogue.
2. If the supported Agency can meet the policies and
conditions specified by the supporting Agency, the
supported Agency submits necessary documents to
request services to the supporting Agency.
3. Both Agencies jointly generate documents specified by the
supporting Agency, which must be completed and signed
off by the dates agreed upon by both Agencies. (A template
for service agreement documents is given on the next
pages.)
4. Both Agencies must agree on the types of tests necessary
for verifying the cross support interfaces and conduct the
tests according to the schedule agreed upon by both
Agencies.
28
Template for Service Agreement
JAXA
Document Number : mmmm
SERVICE AGREEMENT
BETWEEN AGENCY_X AND AGENC_Y
FOR PROJECT_Z
Date: YYYY-MM-DD
Version: n.m
Supporting Agency Point of Contact:
Name: FirstName SurName
E-mail: [email protected]
Supported Agency Point of Contact:
Name: FirstName SurName
E-mail: [email protected]
29
Next Steps
JAXA
Cross Support Service Architecture
June 2007
JAXA distributed the draft document.
July-August
2007
IOAG members review the document and
provide agency specific attribute tables.
September
JAXA distributes the final document.
2007
Cross Support Service Catalogues
OctoberDecember
2007
Using the CSSA document, IOAG
members generate service catalogues
that describe services they can provide.
30
Space Communications and Navigation Office
NASA
NASA’s Concept:
“International Space Communications
and Navigation Network
Service Architecture”
NASA Consolidated Network Services Team
Space Communications and Navigation Office
NASA Headquarters
IOAG-11
June19, 2007
Cebreros, Spain
Background
•
NASA
2005-2006: NASA’s Space Communications Architecture Working Group
(SCAWG)
•
Fresh look at NASA’s overall space communications and navigation infrastructure
•
Created the “NASA Space Communications and Navigation Architecture Recommendations for 2005-2030”:
https://www.spacecomm.nasa.gov/spacecomm/
32
NASA Space Communications Architecture:
where next?
NASA
What concept unites all of these views into a cohesive,
consolidated “network of networks”?
33
NASA’s Concept:
provide “any-to-any” services …
Mission
User
Space Communication
and
Navigation Services
NASA
Mission
User
34
… via an International Service Infrastructure …
Mission
User
International Space
Communications
and Navigation
Service Infrastructure
NASA
Mission
User
35
… offering standard service interfaces
Space
Mission
User
Space
Mission
User
NASA
Space
Mission
User
Space
Mission
User
Standard
Services
Standard
Services
Standard
Services
Standard
Services
Standard
Services
International Space Communications and
Navigation Service Infrastructure
Source: Mario Merri/Mike Kearney
36
11 April 2016
There are multiple phases involved with
providing space communications and navigation services
Discover
Capabilities
Mission
Formulation
Phase
Negotiate
Support
Mission
Design
Phase
Provide
Services
Mission
Operations
Phase
NASA
Mission
User
37
User/provider negotiations involve
the selection and refinement of service options NASA
Options
Service
Provider
Select
Provide
Mission
User
38
Activities across all Phases
should follow a principle of successive refinement NASA
Service
Catalog
Service
Capability
Provider
Service
Agreements
Service
Package
Provider
Configuration
Profiles
Service
Provider
Select
Provide
Mission
User
Discover
Capabilities
Mission
Formulation
Negotiate
Support
Mission
Design
Provide
Services
Mission
Operations
Select
Provide
Mission
User
Mission
User
Select
Provide
Mission
User
39
NASA
Mission Formulation Phase:
discover available services; certify and register authorized users
example:
Mission “M” user browses the service catalog to determine which
available network providers may potentially be available to support.
User decides to explore potential support arrangements
Mission User
Service Provider
Service Discovery Activities
Service Discovery Functions
(Background
administrative
negotiation)
Service
Catalog
example:
SM
I/F
SM
I/F
Service
Management
Interface
Mission
Formulation
Manager
Mission “M” user requests authority to enter exploratory support
discussions.
Users x, y and z are validated and authorized to negotiate during
formulation phase
40
NASA
Mission Design Phase:
negotiate service agreement; create configuration profiles
example:
“Service Agreement: per Service Package M23, SN will support
Mission “M” with one S-band forward link at 8kbps or 16 kbps;
one S-band return link with data rate in the 10 kbps – 2 Mbps
range; and one-way or two-way Doppler tracking”
Mission User
Service Provider
Service Negotiation
Activities
(Background
administrative
negotiation)
Service Negotiation
Functions
Network
Integration
Manager
SM
I/F
SM
I/F
Service
Management
Interface
Service
Catalog
Network
Engineering
example:
Mission
Formulation
Manager
Service
Agreement
DB
Config
Profile
DB
Service
Agreement
DB
Config
Profile
DB
“Service Package M23, Configuration Profile C23.761: provide
Mission “M” with S-band forward link at 8kbps, S-band return link
with data rate = 1 Mbps, and one-way Doppler tracking service”
41
NASA
Mission Operations Phase:
Provide Services
example:
“Provide a contiguous Telemetry, Telecommand and Raw
Radiometric data acquisition pass for Mission “M”, per Service
Package M23 and using configuration profile C23.761 with Station
“S67”, between 15:00 and 15:45 Z on 2007-06-19”
Mission User
Service Provider
Provider Scheduling and
Execution Functions
Network
scheduling
Mission Planning, Scheduling
and Execution
Functions
Service
Agreement
DB
Config
Profile
DB
Mission
scheduling
SM
I/F
Equipment configuration,
control, monitoring
Mission
Planning
Manager
SM
I/F
Service
Management
Interface
Mission planning
Service Utilization
Interface
1
2
3
Station
S67
Service
Agreement
DB
Config
Profile
DB
FDF
Service
Users
Mission
User
Service Providing Resources
example:
1. Raw Radiometric service
2. Forward CLTU telecommand service
3. Return All Frames telemetry service
42
NASA’s Proposed Approach
NASA
• Consolidate NASA’s three current mission support networks around
the organizing principle of a service-based architecture, that builds
upon significant current international investment in “SLE”
• Coordinate the development of that service-based architecture with
other IOAG agencies to ensure future interoperability -
•
NASA proposes that its networks should be a component of an
international space communications and navigation service infrastructure
• Evolve this international infrastructure by progressively exposing
increasingly richer suites of services for cross support -
•
Participating Agencies will agree to implement a common, evolving catalog
of agreed Cross Support Transfer Services
-
Supported by common, evolving Cross Support Service Management systems
• Expand the scope of the international infrastructure to embrace new
capabilities as needs emerge -
•
•
Support of the Mission Design and Mission Formulation phases
Provision of new network capabilities, e.g.,
-
Lunar and Mars relays
Space internetworking
43
NASA’s Initial Scope
NASA
• Initially focus on expanding
NASA’s service infrastructure
based on what we have today –
• Earth-based networks
• Basic communications and tracking
•
services
Consolidation of services in the
Mission Operations Phase
Primary
Initial
Scope
44
Current state of the art for
standard capabilities
•
No uniform way to:
•
Service Management defines
Configuration Profiles to specify fixed or
alternative mission parameters
Service Management defines some
content of Service Agreements
•
• obtain knowledge of network capabilities
• describe network services.
• negotiate or document mission support
Discover
Capabilities
Mission
Formulation
Phase
Negotiate
Support
Mission
Design
Phase
Provide
Services
Mission
Operations
Phase
• But no process for negotiating that content
•
•
•
NASA
Mission
User
Full specification of basic “SLE” data
transfer services
• Growing deployment community
Service Management nearing initial
Standard
• Prototypes under test
Generalization and expansion into “Cross
Support Transfer Services”, including
Radiometric and Monitoring
Key: Exists
Emerging
Does not exist
45
Goal for
standard capabilities
NASA
• Fully standardized process defined for initial
•
negotiation of network support
Internationally agreed Cross support Service
Catalog defined and ready for operational use,
providing access to uniformly-described
service offerings of Agency networks
Discover
Capabilities
Mission
Formulation
Phase
Negotiate
Support
Mission
Design
Phase
Provide
Services
Mission
Operations
Phase
• Expansion to Lunar and Mars Relays and
internetworked operations
• Fully standardized process defined for
•
negotiating network support via Service
Agreements
XML-based Service Agreements and
Configuration Profiles defined and ready for
operational use
Mission
User
• Expansion to Lunar and Mars Relays and
internetworked operations
• Cross Support Transfer Services (CSTS) and
Cross Support Service Management (CSSM)
standards complete –
•
Ready for widespread deployment and operational
use across international networks
• Expansion to Lunar and Mars Relays and
internetworked operations
Key: Exists
Emerging
Does not exist
46
NASA
First Step - Mission Operations Phase:
initial Earth-Based “Service Set”
Mission User
Service Provider
SM
I/F
Forward
Data Delivery
Services
Radiometric
Services
Positioning
& Timing
Services
Service Provision
Return
Data Delivery
Services
SU
I/F
SM
I/F
Service
Management
Interface
Service
Utilization
Interface
SU
I/F
Mission
User
Service
Users
Service Production
47
Initial Service Set:
Earth-Based Return and Forward
NASA
• Forward data delivery services:
•
•
•
•
•
Forward File (CFDP)
Forward Space Packet
Internetworking
Forward CLTU (TC Frame, AOS Frame,octet-stream)
Forward Bitstream
• Return data delivery services:
•
•
•
•
•
•
Return File (CFDP)
Return Space Packet
Internetworking
Return All Frames; Return Channel Frames
Return Unframed Telemetry
Return Bitstream
• Radiometric services:
•
•
•
Raw radio metric data
Validated radio metric
Delta-DOR
• Position &Timing services:
•
•
Position Determination
Time Determination (Clock Correlation, Time distribution)
48
NASA
Initial Service Set - service data unit view:
Earth-Based Return and Forward
Physical
Channel Frames
All Frames
Unframed Telemetry
Bit-stream
Link
Raw Radiometric
CLTU
Network
Internetworking Packet
File
Space
Packet
Delta-DOR
Validated
Radiometric
Transport
Radiometric
Bit-stream
Application
Internetworking Packet
Space
Packet
File
Service Provision
Application
Transport
Network
Link
Physical
Service Production
49
NASA
Initial Service Set - service data unit view:
Earth-Based Return and Forward
Physical
Channel Frames
All Frames
Unframed Telemetry
Bit-stream
Link
Internetworking Packet
File
Space
Packet
Delta-DOR
Validated
Radiometric
Time
CLTU
Network
Radiometric
Raw Radiometric
Transport
Pos
&
Time
Bit-stream
Application
Internetworking Packet
Position
Space
Packet
File
Service Provision
Application
Transport
Network
Link
Physical
Service Production
50
Current Standard Service Set mapping to NASA Networks:
Earth-Based Return and Forward
NASA
Forward File (CFDP)
Forward Space Packet
Internetworking
Forward CLTU (TC Frame, octet stream)
Forward Bitstream*
GN
•
•
•
•
•
SN
• Forward data delivery services:
DSN
**
L
L
L
L
L
L
L
L
L
L
L
L
L
L
L
• Return data delivery services:
•
•
•
•
•
•
Return File (CFDP)
Return Space Packet
Internetworking
Return All Frames; Return Channel Frames
Return Unframed Telemetry
Return Bitstream*
L
• Radiometric services:
•
•
•
Raw radio metric data
Validated radio metric
Delta-DOR
L
L
• Positioning &Timing services:
•
•
Position Determination
Time Determination (Clock Correlation, Time distribution)
* Deprecated DSN services; provided only to legacy missions
** “GN” has been renamed “NEN”
Source: Mike Kearney
Current capability
Planned Upgrade
Proposed addition
No planned service
Deprecated
Local standard
L
51
Anticipated Service Set mapping to NASA Networks:
Earth-Based Return and Forward
NASA
Forward File (CFDP)
Forward Space Packet
Internetworking
Forward CLTU (TC Frame, AOS Frame, octet-stream)
Forward Bitstream*
GN
•
•
•
•
•
SN
• Forward data delivery services:
DSN
**
L
L
L
L
L
L
• Return data delivery services:
•
•
•
•
•
•
Return File (CFDP)
Return Space Packet
Internetworking
Return All Frames; Return Channel Frames
Return Unframed Telemetry
Return Bitstream*
• Radiometric services:
•
•
•
Raw radio metric data
Validated radio metric
Delta-DOR
• Positioning &Timing services:
•
•
Position Determination
Time Determination (Clock Correlation, Time distribution)
* Deprecated DSN services; provided only to legacy missions
** “GN” has been renamed “NEN”
Source: Mike Kearney
Current capability
Planned Upgrade
Proposed addition
No planned service
Deprecated
Local standard
L
52
Proposed Next Steps
NASA
NASA recommends that:
•
•
IOAG/CCSDS should jointly focus on accelerated development of the Cross
Support Service Architecture, with a view towards creating three new CCSDS
Recommendations:
• CCSDS Recommended Practice: Cross Support Service Architecture
• CCSDS Recommended Standard: Cross Support Service Catalogs
• CCSDS Recommended Standard: Cross Support Service Agreements
IOAG/CCSDS should continue to push towards rapid completion of the current SLE
Service Management Blue Book, and towards accelerated development of the
generic Cross Support Transfer Services and Cross Support Service Management
standards
•
CCSDS should be asked to issue a communiqué to IOAG, detailing progress made
on the Cross Support Service Architecture, and related standards, at the
completion of the CCSDS Fall 2007 technical meeting
•
IOAG should consider forming a working committee to:
• Explore how to create and maintain the international IOAG Cross Support Service Catalog:
-
Provide a guide to services exposed for inter-agency use within CCSDS-compliant agencies
Indicate to CCSDS-compliant agencies where infrastructure development is needed
• Coordinate the international prototyping and interoperability testing of specific services and
their associated service management capabilities
53
ESA Service Architecture
ESA
54
IOAG-11:
Draft Resolutions
affecting CCSDS
IOAG-11
June20, 2007
Cebreros, Spain
IOAG-11 DRAFT RESOLUTIONS
(Res 8.5.1)
(Res 8.5.1)
REQUEST FOR A FRAMEWORK FOR CROSS- SUPPORT SERVICE
ARCHITECTURE
REQUEST FOR A FRAMEWORK FOR A CROSS-SUPPORT
SERVICES CATALOG
New Resolution IOAG-11.--IOAG resolves to retire Resolution 8.5.1 and agrees to provide future guidance to
CCSDS with respect to the desired Cross Support Service Architecture and Cross
Support Service Catalog. IOAG thanks JAXA for assuming leadership of this work
and resolves to ask JAXA to work with CCSDS to continue to develop the
architecture. IOAG also resolves to create and maintain an agreed inter-Agency
cross support catalog.
Actions:
1.
2.
Update the Cross Support Service Architecture to reflect presentations made by
ESA and NASA at IOAG-11 and circulate to the IOAG and CCSDS for review and
comment. Assigned to: JAXA (Yamada). Due date: Issue-1 by 01 December 2007
Create a baseline IOAG service catalog, indicating the “core” services that all
Agencies agree to cross support and a phasing plan that indicates when cross
support new services will be added by Agencies in the future, and obtain IOAG
and CCSDS review and comment. ESA (Hell). Due date: Issue-1 by 14 September
56
IOAG-11 DRAFT RESOLUTIONS
(Res 8.1.1)
(Res 8.4.1)
URGENT NEED FOR A SLE MANAGEMENT SERVICES
RECOMMENDATION
ADVICE ON CROSS-SUPPORT TRANSFER SERVICES
WORKING GROUP CHARTER
New Resolution IOAG-11.--IOAG resolves to retire Resolutions 8.1.1 and 8.4.1 and notes its
satisfaction with current CCSDS progress in developing standards for
Cross Support Service Management and Cross Support Transfer Services.
IOAG further resolves to ask CCSDS to report progress with a view
towards finalizing a CCSDS Recommended Standard (“Blue Book”) for
Service Management by the end of CY2008
Action: Provide IOAG with interim status reports relative to the IOAG goal
of a Service Management Blue Book by the end of CY2008. Assigned to:
CCSDS Liaison (Hooke). Due dates: October 2007; May 2008; October
2008.
57
IOAG-11 DRAFT RESOLUTIONS
(Res 8.3.1)
ADVICE FOR SIMPLIFICATION OF RF & MOD.
RECOMMENDATIONS
New Resolution IOAG-11.--IOAG resolves to retire Resolution 8.3.1 and notes its satisfaction with
current CCSDS progress in simplification of CCSDS (401)
recommendations 2.4.17A and 2.4.17B . IOAG further resolves to ask
CCSDS to report progress with a view towards finalizing CCSDS 401
(2.4.17A/B) as Recommended Standards (“Blue Books”) by the Spring of
CY2008
Action: Provide IOAG with interim status reports relative to IOAG goal of
finalizing the simplification of CCSDS RF & Modulation Recommendations
CCSDS 2.4.17A/B by the Spring of CY2008. Assigned to: CCSDS Liaison
(Hooke). Due dates: October 2007; May 2008.
58
IOAG-11 DRAFT RESOLUTIONS
(Res 8.7.1)
REQUEST FOR A HIGH RATE COMMANDING
RECOMMENDATION
New Resolution IOAG-11.--IOAG resolves that no requirements for future high rate uplinks are
currently foreseen and therefore resolves to withdraw Resolution 8.7.1
Action: notify CCSDS of IOAG decision to withdraw Resolution 8.7.1.
Assigned to: CCSDS Liaison (Hooke). Due dates: June 2007.
59
IOAG-11 DRAFT RESOLUTIONS
(Res 8.8.1)
REQUEST FOR A DELTA DOR RECOMMENDATION
New Resolution IOAG-11.--IOAG notes its satisfaction with current CCSDS progress in
standardization of Delta-DOR and therefore resolves to retire Resolution
8.3.1. IOAG further resolves to ask CCSDS to report progress on a regular
basis.
Action:
Provide IOAG with interim status reports relative to status of Delta-DOR
standardization. Assigned to: CCSDS Liaison (Peccia). Due dates: June
2007; October 2007; May 2008.
60
IOAG-11 DRAFT RESOLUTIONS
(Res 8.2.1)
CCSDS STRATEGIC PLAN: SUGGESTED
MODIFICATIONS
New Resolution IOAG-11.--IOAG notes that CCSDS intends to update its Strategic Plan and
resolves to supply CCSDS with the new IOAG Cross Support Services
Catalog and IOAG Standards Infusion Matrix as a contribution towards
that update. IOAG further resolves to retire Resolution 8.2.1 and asks
CCSDS to report progress on the new CCSDS Strategic Plan on a
regular basis.
Action:
1. Provide CCSDS with the IOAG Cross Support Services Catalog and
IOAG Standards Infusion Matrix. Assigned to: Hell. Due date: 01 Dec
2007
2. Provide IOAG with interim status reports relative to status of the
CCSDS Strategic Plan update Assigned to: CCSDS Liaison (Peccia).
61
Due dates: June 2007; October 2007; May 2008.
DRAFT IOAG-11 RESOLUTION
New Resolution IOAG-11.--The IOAG takes note of indications from NASA that the
transmission of IP datagrams across CCSDS space links has
been proposed in a mode whereby the IP datagrams are
encapsulated within a private serial bitstream. This operational
mode is also currently being considered as an implementation
option in the "IP-over-CCSDS Links" Draft Recommended
Practice (CCSDS 702.1-R-2 IP).
The IOAG does not endorse this option and it will not be crosssupported. Such an implementation is a private Agency matter
and should not be documented by CCSDS. For future crosssupport purposes, IP should be implemented using the existing
CCSDS mechanisms of encapsulation or direct IP multiplexing.
62
IOAG-11 RESOLUTION
New Resolution IOAG-11.--Charter:
IOAG SPACE INTERNETWORKING STRATEGY GROUP
Co-Chairs:
Paolo Maldari/ESA
John Rush/NASA
The IOAG resolves to form a Space Internetworking Strategy Group to reach
international consensus on a recommended approach for transitioning the
participating agencies towards a future “network centric” era of space mission
operations. The group will focus on the extension of internetworked services
across the Solar System, including multi-hop data transfer to and from remote
space locations and local networked data interchange within and among the
space end systems.
In developing this strategy, the group will consider future mission requirements,
projected technology trends and the current installed base of inter-Agency cross
support capabilities. The final deliverable, which is due by the Spring of 2009, is
a report that:
a. Identifies a concept of internetworking operations and associated user
scenarios;
b. Analyzes and recommends potential profile(s) of existing CCSDS standards
necessary to implement future space internetworking;
c. Provides a roadmap for how Agencies will evolve to support the new
capabilities
63