Summary of IOAG-11 Adrian Hooke NASA and Nestor

Summary of IOAG-11 Adrian Hooke (NASA) and Nestor Peccia (ESA) CCSDS Technical Liaisons IOAG-11 June 18, 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_home. htm http: //www. ioag. org/IOAG-11_presentations_&_%20 briefings. htm 3

IOAG-11 HIGHLIGHTS • Manfred Warhaut will relinquish the IOAG Chairmanship; Klaus-Juergen Schulz replaces him ISRO (S. K. Shivakumar) admitted as the 7 th. 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) (Res 8. 1. 1) (Res 8. 4. 1) (Res 8. 3. 1) (Res 8. 7. 1) REQUEST FOR A FRAMEWORK FOR CROSSSUPPORT SERVICE ARCHITECTURE REQUEST FOR A FRAMEWORK FOR A CROSSSUPPORT SERVICES CATALOG 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 Red 2 Conceptual Analysis Concept of Operations (Green Book) June 07 Intermediate Meeting (Red-2 production check, adjustments) Specific Analysis of Ranging & Radiometric SM Date Updated, completed Conceptual Analyses for committed Red-2 production, updates Document Production Track June 07 Detailed analysis for management of Ranging, Radiometric Services Operations Concept Green Book Interoperations/Demo Track Jan 08 Prototype Interoperations (Red-1 Compliant) Red 2 Agency review Dec 07 XML Schema Update (Red-2 Compliance) Red 2 XML schema Oct 07 Red-2 (Submission to Secretariat) SLE SM Red 2 Production Oct 07 Apr 07– Apr 08 Red-2 DSN Red-1 Compliant Prototype JAXA Red-1 Compliant 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 1 st 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 W 3 C Xml. Schema 2 nd Priority OK; Schema updates to be sequenced after Red 2 updates At least two independently developed interoperable prototypes 2 nd Priority Prototype activities are underway Green (Concept) Book 3 rd 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 4 th 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. 17 A and 2. 4. 17 B 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 • 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 2 nd. half of 2007 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 • • 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 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 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 no current consensus as to how to achieve this evolution. The major issues include: • • • There is general agreement that the Internet Protocol (IP) suite will work in shortdelay, 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. 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

Cross Support Service Architecture JAXA • 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

Simple Configuration JAXA • 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 S 1 Ground side interface of CSSE 1 20

Cascaded Configuration • • JAXA 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 CSSE 1 (a data relay satellite) and CSSE 2 (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

Examples of Service View JAXA 22

Service Management JAXA 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 25

An Example of Communications View JAXA 26

An Example of Enterprise View JAXA 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: First. Name Sur. Name E-mail: address@suporting. agency Supported Agency Point of Contact: Name: First. Name Sur. Name E-mail: address@suported. agency 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 October. December 2007 Using the CSSA document, IOAG members generate service catalogues that describe services they can provide. 30

Space Communications and Navigation Office 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 June 19, 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 NASA Space Mission User Standard Services Standard Services International Space Communications and Navigation Service Infrastructure Source: Mario Merri/Mike Kearney 36 3/19/2018

There are multiple phases involved with providing space communications and navigation services Discover Capabilities Mission Formulation Phase Negotiate Support Mission Design Phase Provide Services NASA Mission Operations Phase Mission User 37

User/provider negotiations involve the selection and refinement of service options Options Service Provider NASA Select Provide Mission User 38

Activities across all Phases should follow a principle of successive refinement Service Catalog Service Capability Provider Service Agreements Service Package Provider Configuration Profiles Service Provider NASA Select Provide Mission User Discover Capabilities Mission Formulation Negotiate Support Mission Design Provide Services Mission Operations 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 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 M 23, SN will support Mission “M” with one S-band forward link at 8 kbps 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 Functions Service Negotiation Activities (Background administrative negotiation) Network Integration Manager SM I/F Service Catalog Network Engineering example: Service Management Interface SM I/F Mission Formulation Manager Service Agreement DB Config Profile DB “Service Package M 23, Configuration Profile C 23. 761: provide Mission “M” with S-band forward link at 8 kbps, 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 Raw Radiometric data acquisition pass for Mission “M”, per Service Package M 23 and using configuration profile C 23. 761 with Station “S 67”, between 15: 00 and 15: 45 Z on 2007 -06 -19” Mission User Service Provider Scheduling and Execution Functions Network scheduling Mission Planning, Scheduling and Execution Functions Service Agreement DB Config Profile DB Equipment configuration, control, monitoring Mission scheduling SM I/F Mission Planning Manager SM I/F Service Management Interface Mission planning Service Utilization Interface 1 2 3 Station S 67 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 NASA Mission Operations Phase But no process for negotiating that content 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 • • 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 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 – • • Discover Capabilities NASA 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 • 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 • NASA 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 Service Production File Space Packet Internetworking Packet Channel Frames Network Link Physical RN All Frames Transport TU Physical Application RE AR D Unframed Telemetry RW Bit-stream Link Raw Radiometric CLTU Network FO Delta-DOR Validated Radiometric Transport Radiometric Bit-stream Application Internetworking Packet Space Packet File Service Provision 49

NASA Initial Service Set - service data unit view: Earth-Based Return and Forward Service Production File Space Packet Internetworking Packet Channel Frames Transport Network Physical RN Link TU All Frames Validated Radiometric Delta-DOR Application RE Physical Unframed Telemetry AR D Bit-stream RW Raw Radiometric Link FO Radiometric CLTU Network Bit-stream Transport Pos & Time Internetworking Packet Application Time Position Space Packet File Service Provision 50

• • • 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) * Deprecated DSN services; provided only to legacy missions ** “GN” has been renamed “NEN” Source: Mike Kearney L L L L GN • DSN ** NASA SN Current Standard Service Set mapping to NASA Networks: Earth-Based Return and Forward L L L Current capability Planned Upgrade Proposed addition No planned service Deprecated Local standard L 51

• 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* • L L L Radiometric services: • Raw radio metric data • Validated radio metric • Delta-DOR • L GN • DSN ** SN NASA Anticipated Service Set mapping to NASA Networks: Earth-Based Return and Forward 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 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 June 20, 2007 Cebreros, Spain

IOAG-11 DRAFT RESOLUTIONS (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 CY 2008 Action: Provide IOAG with interim status reports relative to the IOAG goal of a Service Management Blue Book by the end of CY 2008. 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. 17 A and 2. 4. 17 B. IOAG further resolves to ask CCSDS to report progress with a view towards finalizing CCSDS 401 (2. 4. 17 A/B) as Recommended Standards (“Blue Books”) by the Spring of CY 2008 Action: Provide IOAG with interim status reports relative to IOAG goal of finalizing the simplification of CCSDS RF & Modulation Recommendations CCSDS 2. 4. 17 A/B by the Spring of CY 2008. 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. --- 63