summary of ioag-11 ioag-11 june18, 2007 cebreros, spain adrian hooke (nasa) and nestor peccia (esa)...

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

http://www.ioag.org/IOAG-11/IOAG-11_presentations_&_%20briefings.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





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


Utilization Management

Element


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


Ground User Element

Space User Element


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


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

https://www.spacecomm.nasa.gov/spacecomm/

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




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


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


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




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




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*


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


• 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


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.


58

(Res 8.3.1) ADVICE FOR SIMPLIFICATION OF RF & MOD. RECOMMENDATIONS


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.


59

(Res 8.7.1) REQUEST FOR A HIGH RATE COMMANDING RECOMMENDATION


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.


60

(Res 8.8.1) REQUEST FOR A DELTA DOR RECOMMENDATION


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.


61

(Res 8.2.1) CCSDS STRATEGIC PLAN: SUGGESTED MODIFICATIONS


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.


62

DRAFT IOAG-11 RESOLUTION


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


summary of ioag-11 ioag-11 june18, 2007 cebreros, spain adrian hooke (nasa) and nestor peccia (esa)...

Documents

summary of ioag

radiometric service

ioag resolution

limited ioag

production of red

compliant prototypeesa

compliant prototypejaxa

suggested modifications