Summary of IOAG-11Summary of IOAG-11
IOAG-11June18, 2007
Cebreros, Spain
Adrian Hooke (NASA) and Nestor Peccia (ESA)CCSDS Technical Liaisons
2
Contents
1.Summary of highlights of IOAG-11
2.CCSDS Liaison Report to IOAG-11
3.JAXA, NASA, ESA Service Architecture Proposals
3
IOAG-11 AGENDA
http://www.ioag.org/IOAG-11/IOAG-11_presentations_&_%20briefings.htm
http://www.ioag.org/IOAG-11/IOAG-11_home.htm
4
• 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:• JAXA, ESA and NASA presentations
• IOAG will maintain a core Cross Support Service Catalog
• Agreement to establish new “IOAG Space Internetworking Strategy Group” (2-year horizon)
• Co-chairs: Paolo Maldari/ESA and John Rush/NASA
• Strong opinions from ESA, CNES, BNSC and JAXA about non-standard IP encapsulation using serial HDLC stream
• Need for supplementary information re: NASA Coding, Modulation and Link Protocols (CMLP) study
IOAG-11 HIGHLIGHTS
5
2. CCSDS Liaison2. CCSDS LiaisonReport to IOAGReport to IOAG
6
(Res 8.5.1) REQUEST FOR A FRAMEWORK FOR CROSS-SUPPORT SERVICE ARCHITECTURE
(Res 8.5.1) REQUEST FOR A FRAMEWORK FOR A CROSS-SUPPORT SERVICES CATALOG
(Res 8.1.1) URGENT NEED FOR A SLE MANAGEMENT SERVICES RECOMMENDATION
(Res 8.4.1) ADVICE ON CROSS-SUPPORT TRANSFER SERVICES WORKING GROUP CHARTER
(Res 8.3.1) ADVICE FOR SIMPLIFICATION OF RF & MOD. RECOMMENDATIONS
(Res 8.7.1) 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
IOAG-08 RESOLUTIONS
7
(8.1.1 and 8.4.1)CCSDS Cross Support Services Area
CSS Area Overview
Service Management Working Group (SMWG)
Leadership
Chair: Erik Barkley, JPL/NASA
Deputy Chair: John Pietras, GST/GSFC/NASA
Deliverables
Service Management Concept Book (Green Book)
Service Management Recommendation (Blue Book)
XML Schema (Virtual Annex to Blue Book)
Prototype Inter-operations, Validation
ESA <--> JPL/NASA
JAXA <--> JPL/NASA
Best Practices Book (Magenta Book)
Cross Support Transfer Service Working Group (CSTSWG)
Leadership
Chair: Yves Doat, ESA
Deputy Chair: (Vacant)
Deliverables
Generic Core Toolkit Concept Book (Green Book)
Generic Core Toolkit Book Recommendation (Blue Book)
Ground Domain Transfer Services (Based on Toolkit)
Return Unframed Telemetry (Blue Book)
Ranging, Radiometric (Blue Book)
Service Production Monitoring (Blue Book)
Prototype Inter-Operations, Validation
ESA <--> JPL/NASA
8Jan 2007 Jul 2007 Jan 2008
Concept of Operations (Green Book)
Jul 2008
Interoperations/Demo Track
Document Production Track
(8.1.1) Service Management Working Group (SMWG):Current Plan of Major Activities
SMWG Intermediate
SLE SM Red 2 Production
Red2 XML schema
CCSDS Fall
DSN Red-1 Compliant Prototype
JAXA Red-1Compliant Prototype
ESA Red-1 Compliant Prototype
Red2 Agencyreview
CCSDS Spring
CCSDS Winter
Red 2Conceptual Analysis
Red-2
Red-1
Specific Analysisof Ranging &
Radiometric SM
Key Activity Date
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
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.
9
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 •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
Green (Concept) Book
3rd Priority
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
(8.1.1) Service Management Working Group (SMWG):Summary Status
10
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
(8.3.1) RF & Modulation Simplifications
11
(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.
12
(8.8.1) Delta DOR
• The revised Delta-DOR Operations (draft Green Book) is ready for review by the CESG.
• The plan is to publish the Green Book in the 2nd. half of 2007
I/F Data Priority Availability Covered by Allocated to1 DOR Tones High Medium Term Partially covered by existing standard
(CCSDS 401 (2.5.6B)B-2)It will be discussed in the next BB update
SLS Ranging WG
2 Raw Data Low Long term Not covered tbd BOF3 Service to tranfer
dataHigh Long term Partially in CSS. Transfer implies
Raw data, ODM, Reduced DataCSS Area
4 ODM High Available NAV ODM Standard (BB) MOIMS NAV WG5 Reduced Data High Medium Term
Available end 07NAV TDM Standard to be checked MOIMS NAV WG
6 Quasar Catalogue (Radio Signals)
Low Long term JPL Quasar catalogue available tbd BOF
Antenna 1 StorageRx
Ground Station 1
Antenna 2 StorageRx
Ground Station 2
Quasar
Correlator
ODM
Reduced Data
Operational Control Centre
1
2
3
4
5
26
13
(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 well4. Member agencies are not engaged in the infusion of each new
recommendation5. 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)
14
(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. 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
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
15
An Emerging Issue: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.
16
3. Service Architecture Proposals:3. Service Architecture Proposals:JAXAJAXANASANASAESAESA
CROSS SUPPORT SERVICE ARCHITECTURE
Takahiro Yamada (JAXA/ISAS)
19 June 2007
JAXA
18
Purpose of This Presentation
• 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
cross-support architecture containing organizational, administrative, and functional features of services for cross-support 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.
JAXA
19
Cross Support Service Architecture
• The cross support service architecture expands the conventional “service-provider/service-user” model to include both space and ground users.
• The scope of the architecture is limited to four views:• Service View • Physical View• Communications View• Enterprise View
Cross Support Service System
(Service provider)
SpaceServices
GroundServicesSpace
ServiceUsers
GroundServiceUsers
JAXA
20
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
CSSES1
GroundUser
Element
SpaceUser
Element
Space side interface of CSSE 1
Ground side interface of CSSE 1
JAXA
21
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).
CSSE2
CSSE1
GroundUser
Element
SpaceUser
Element
Space side interface of CSSE 1
Space side interface of CSSE 2
Ground side interface of CSSE 1
Ground side interface of CSSE 2
JAXA
22
Examples of Service View
Cross Support Service Element
Ground User Element
Space User Element
Cross Support Service
Provision
Ground Service
Utilization
Space Service
Utilization
Space User Element
Space Service
Utilization
Cross Support Service Element 1
Cross
Support Service
Provision 1
Ground User Element
Ground Service
Utilization
Cross Support Service Element 2
Cross
Support Service
Provision 2
JAXA
23
Service Management
Cross Support Service Element
Utilization Management
Element
Cross Support Service
Provision
Service
Utilization Mngmnt Service
Provision Mngmnt
JAXA
24
JAXA View: Basic Cross Support Services
Cross Support Service Type
Basic Cross Support Service
Forward Delivery Services
Forward Bitstream Delivery Service
Forward CLTU Delivery Service
Forward Packet Delivery Service
Forward File Delivery Service
Return Delivery Services
Return Bitstream Delivery ServiceReturn Frame Delivery Service
Return Packet Delivery Service
Return File Delivery Service
Cross Support Service Type
Basic Cross Support Service
Tracking Services
Radio Metric Data Service
Delta-DOR Service
Orbit Determination Service
Time Service Spacecraft Time Correlation Service
Voice and Video Services
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.
JAXA
25
An Example of Physical View
CSSE1 (Mars Relay
Satellite)
Space User Element (Mars Lander)
Ground
User Element (Lander Control
Center)
CSSE2 (Ground Station)
CSSE3 (Ground Station)
JAXA
26
An Example of Communications View
Cross Support Service Element
Ground User Element
Space User Element
Cross Support Service
Provision
Ground Service
Utilization
Space Protocol 2
Space Protocol 1
Space Protocol 2
Space Protocol 1
Ground Protocol 2
Ground Protocol 1
Ground Protocol 2
Ground Protocol 1
Space Service
Utilization
JAXA
27
An Example of Enterprise View
CSSE 1
Space User
Element
Ground User
Element
CSSE 2
CSSE 3
CSSS
Supporting Agency
Cross Support Service
Agreement
Supported Agency
JAXA
28
Procedure forCross Support Service Agreement
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.
JAXA
29
Template for Service Agreement
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]
JAXA
30
Next Steps
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 2007
JAXA distributes the final document.
Cross Support Service Catalogues
October-December 2007
Using the CSSA document, IOAG members generate service catalogues that describe services they can provide.
JAXA
Space Communications and Navigation Office
NASA’s Concept:NASA’s Concept:““International Space Communications International Space Communications
and Navigation Networkand Navigation NetworkService Architecture”Service Architecture”
IOAG-11June19, 2007
Cebreros, Spain
NASA Consolidated Network Services TeamSpace Communications and Navigation Office
NASA Headquarters
NASA
32
BackgroundBackground
• 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/
NASA
33
NASA Space Communications Architecture:NASA Space Communications Architecture:where next?where next?
What concept unites all of these views into a cohesive,consolidated “network of networks”?
NASA
34
MissionUser
MissionUser
Space CommunicationSpace Communicationand and
Navigation ServicesNavigation Services
NASA’s Concept:NASA’s Concept:provide “any-to-any” services …provide “any-to-any” services … NASA
35
MissionUser
MissionUser
International SpaceInternational SpaceCommunicationsCommunicationsand Navigationand Navigation
Service InfrastructureService Infrastructure
… … via an via an InternationalInternational Service Infrastructure … Service Infrastructure … NASA
36April 20, 2023
International Space Communications and Navigation Service Infrastructure
SpaceMission
UserSpaceMission
User SpaceMission
User
SpaceMission
User
… … offering standard service interfacesoffering standard service interfaces
Source: Mario Merri/Mike Kearney
StandardServices
StandardServices
StandardServices
StandardServices
StandardServices
NASA
37
There are multiple phases involved withThere are multiple phases involved withproviding space communications and navigation servicesproviding space communications and navigation services
MissionUser
DiscoverDiscoverCapabilitiesCapabilities
NegotiateNegotiateSupportSupport
ProvideProvideServicesServices
MissionFormulation
Phase
MissionDesignPhase
MissionOperations
Phase
NASA
38
Options
Provide
Select
ServiceServiceProviderProvider
MissionUser
User/provider negotiations involveUser/provider negotiations involvethe selection and refinement of the selection and refinement of service optionsservice options NASA
39
MissionUser
DiscoverDiscoverCapabilitiesCapabilities
NegotiateNegotiateSupportSupport
ProvideProvideServicesServices
MissionFormulation
MissionDesign
MissionOperations
ServiceCatalog
Provide
Select
ServiceCapabilityProvider
MissionUser
ServiceAgreements
Provide
Select
ServicePackageProvider
MissionUser
ConfigurationProfiles
Provide
Select
ServiceProvider
MissionUser
Activities across all PhasesActivities across all Phasesshould follow a principle of should follow a principle of successive successive refinementrefinement NASA
40
Mission UserService Provider
Mission Formulation Phase:Mission Formulation Phase:ddiscover available services; certify and register authorized usersiscover available services; certify and register authorized users
SMI/F
ServiceManagement
Interface
Service Discovery Functions Service Discovery Activities
Mission Formulation
Manager
SMI/FService
Catalog
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
example:
Mission “M” user requests authority to enter exploratory support discussions.Users x, y and z are validated and authorized to negotiate during formulation phase
example:
(Backgroundadministrativenegotiation)
NASA
41
Mission UserService Provider
Service Negotiation Activities
ConfigProfile
DB
Service Negotiation Functions
ConfigProfile
DB
ServiceAgreement
DB
ServiceAgreement
DB
Mission Formulation
Manager
Network Engineering
NetworkIntegrationManager
Mission Design Phase:Mission Design Phase:negotiate service agreement; create configuration profilesnegotiate service agreement; create configuration profiles
SMI/F
SMI/F
ServiceCatalog
ServiceManagement
Interface
(Backgroundadministrativenegotiation)
“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”
example:
“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”
example:
NASA
42
Mission UserService Provider
Service Providing Resources
Service Users
Provider Scheduling andExecution Functions
Networkscheduling
SMI/F
SMI/F
Missionscheduling
Mission planningEquipment configuration,
control, monitoring
ConfigProfile
DB
ServiceAgreement
DBConfigProfile
DB
ServiceAgreement
DB
Service UtilizationInterface
Mission Planning, Scheduling and Execution Functions
Mission Operations Phase:Mission Operations Phase:Provide ServicesProvide Services
“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”
1. Raw Radiometric service 2. Forward CLTU telecommand service3. Return All Frames telemetry service
FDF1
2
3
example:
example:
ServiceManagement
Interface
MissionPlanningManager
MissionUser
StationS67
NASA
43
NASA’s Proposed ApproachNASA’s Proposed Approach
• 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
NASA
44
NASA’s NASA’s InitialInitial Scope Scope
PrimaryInitialScope
• 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
NASA
45
Current state of the art forCurrent state of the art forstandard capabilitiesstandard capabilities
DiscoverDiscoverCapabilitiesCapabilities
NegotiateNegotiateSupportSupport
ProvideProvideServicesServices
MissionFormulation
Phase
MissionDesignPhase
MissionOperations
Phase
MissionUser
• Full specification of basic “SLE” data transfer servicesFull specification of basic “SLE” data transfer services• Growing deployment communityGrowing deployment community
• Service Management nearing initial StandardService Management nearing initial Standard• Prototypes under testPrototypes under test
• Generalization and expansion intoGeneralization and expansion into “Cross Support “Cross Support Transfer Services”, including Radiometric and MonitoringTransfer Services”, including Radiometric and Monitoring
• Service Management defines Configuration Profiles Service Management defines Configuration Profiles to specify fixed or alternative mission parameters to specify fixed or alternative mission parameters
• Service Management defines some content of Service Management defines some content of Service AgreementsService Agreements• But no process for negotiating that contentBut no process for negotiating that content
• No uniform way to:No uniform way to:• obtain knowledge of network capabilitiesobtain knowledge of network capabilities• describe network services.describe network services.• negotiate or document mission supportnegotiate or document mission support
Key: ExistsExistsEmergingEmergingDoes not existDoes not exist
NASA
46
DiscoverDiscoverCapabilitiesCapabilities
NegotiateNegotiateSupportSupport
ProvideProvideServicesServices
MissionFormulation
Phase
MissionDesignPhase
MissionOperations
Phase
MissionUser
• Cross Support Transfer Services (CSTS) and Cross Cross Support Transfer Services (CSTS) and Cross Support Service Management (CSSM) standards complete –Support Service Management (CSSM) standards complete –
• Ready for widespread deployment and operational use across Ready for widespread deployment and operational use across international networksinternational networks
• Expansion to Lunar and Mars Relays and Expansion to Lunar and Mars Relays and internetworked operationsinternetworked operations
• Fully standardized process defined for negotiating Fully standardized process defined for negotiating network support via Service Agreementsnetwork support via Service Agreements
• XML-based Service Agreements and Configuration XML-based Service Agreements and Configuration Profiles defined and ready for operational useProfiles defined and ready for operational use
• Expansion to Lunar and Mars Relays and Expansion to Lunar and Mars Relays and internetworked operationsinternetworked operations
• Fully standardized process defined for initial negotiation of Fully standardized process defined for initial negotiation of network supportnetwork support
• Internationally agreed Cross support Service Catalog defined Internationally agreed Cross support Service Catalog defined and ready for operational use, providing access to uniformly-and ready for operational use, providing access to uniformly-described service offerings of Agency networksdescribed service offerings of Agency networks
• Expansion to Lunar and Mars Relays and internetworked Expansion to Lunar and Mars Relays and internetworked operationsoperations
Goal forGoal forstandard capabilitiesstandard capabilities
Key: ExistsExistsEmergingEmergingDoes not existDoes not exist
NASA
47
Service Provider
Service P
rovis
ion
Mission User
Service Users
First Step - Mission Operations Phase:First Step - Mission Operations Phase:initial Earth-Based “initial Earth-Based “Service SetService Set””
MissionUserService
UtilizationInterface
SUI/F
SUI/F
SMI/F
SMI/FService
ManagementInterface
Service Production
Positioning& TimingServices
RadiometricServices
ReturnData Delivery
Services
ForwardData Delivery
Services
NASA
48
Initial Service Set:Initial Service Set:Earth-Based Return and ForwardEarth-Based Return and Forward
• 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)
NASA
49
Initial Service Set - service data unit view:Initial Service Set - service data unit view:Earth-Based Return and ForwardEarth-Based Return and Forward
Physical
Sp
ace
Pac
ket
Link
Network
CL
TU
Application
File
Inte
rnet
wo
rkin
g P
acke
t
Transport
FORWAR
D
Sp
ace
Pac
ket
All
Fra
mes
Ch
ann
el F
ram
es
Link
Inte
rnet
wo
rkin
g P
acke
t
Network
Transport
File
Application
Un
fram
ed T
elem
etry
RET
URN
Raw
Rad
iom
etri
c
Bit
-str
eam
Bit
-str
eam
Del
ta-D
OR
Physical
Val
idat
edR
adio
met
ric
Service Provision
Service Production
Radiometric
NASA
50
Physical
Sp
ace
Pac
ket
Link
Network
CL
TU
Application
File
Inte
rnet
wo
rkin
g P
acke
t
Transport
FORWAR
D
Sp
ace
Pac
ket
All
Fra
mes
Ch
ann
el F
ram
es
Link
Inte
rnet
wo
rkin
g P
acke
t
Network
Transport
File
Application
Un
fram
ed T
elem
etry
RET
URN
Raw
Rad
iom
etri
c
Bit
-str
eam
Bit
-str
eam
Del
ta-D
OR
Physical
Val
idat
edR
adio
met
ric
Po
sit
ion
Tim
e
Pos&
Time
Service Provision
Service Production
Radiometric
Initial Service Set - service data unit view:Initial Service Set - service data unit view:Earth-Based Return and ForwardEarth-Based Return and Forward
NASA
51
Current capabilityPlanned UpgradeProposed additionNo planned serviceDeprecatedLocal standard
Current Standard Service Set mapping to NASA Networks:Current Standard Service Set mapping to NASA Networks:Earth-Based Return and ForwardEarth-Based Return and Forward
• Forward data delivery services:• Forward File (CFDP)• Forward Space Packet• Internetworking• Forward CLTU (TC 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
• Positioning &Timing services:• Position Determination• Time Determination (Clock Correlation, Time distribution)
Source: Mike Kearney
* Deprecated DSN services; provided only to legacy missions** “GN” has been renamed “NEN”
L
L L
L LL
L
L LL
L
L
L
L LL
L LL
**
NASA
52
Anticipated Service Set mapping to NASA Networks:Anticipated Service Set mapping to NASA Networks:Earth-Based Return and ForwardEarth-Based Return and Forward
• 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
• Positioning &Timing services:• Position Determination• Time Determination (Clock Correlation, Time distribution)
Source: Mike Kearney
L
L
LL
L L
Current capabilityPlanned UpgradeProposed additionNo planned serviceDeprecatedLocal standard L
**
* Deprecated DSN services; provided only to legacy missions** “GN” has been renamed “NEN”
NASA
53
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
Proposed Next StepsProposed Next Steps NASA
54
ESA Service ArchitectureESA Service ArchitectureESA
IOAG-11:IOAG-11:
Draft ResolutionsDraft Resolutions
affecting CCSDSaffecting CCSDS
IOAG-11June20, 2007
Cebreros, Spain
56
(Res 8.5.1) REQUEST FOR A FRAMEWORK FOR CROSS- SUPPORT SERVICE ARCHITECTURE
(Res 8.5.1) 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. 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
2. 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
IOAG-11 DRAFT RESOLUTIONS
57
(Res 8.1.1) URGENT NEED FOR A SLE MANAGEMENT SERVICES RECOMMENDATION
(Res 8.4.1) 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.
IOAG-11 DRAFT RESOLUTIONS
58
(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.
IOAG-11 DRAFT RESOLUTIONS
59
(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.
IOAG-11 DRAFT RESOLUTIONS
60
(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.
IOAG-11 DRAFT RESOLUTIONS
61
(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). Due dates: June 2007; October 2007; May 2008.
IOAG-11 DRAFT RESOLUTIONS
62
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 cross-supported. Such an implementation is a private Agency matter and should not be documented by CCSDS. For future cross-support purposes, IP should be implemented using the existing CCSDS mechanisms of encapsulation or direct IP multiplexing.
63
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
IOAG-11 RESOLUTION
New Resolution IOAG-11.---