1. 1 CROSS SUPPORT SERVICE ARCHITECTURE Takahiro Yamada (JAXA/ISAS) CCSDS Meeting, Heppenheim, Germany 2 October 2007

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

3. 3 BASIC CONCEPTS

4. 4 Cross Support  Cross support is an activity of using resources of one space Agency to support operations of a space mission of another space Agency.  To facilitate cross support, CCSDS developed standard protocols to transfer telecommand and telemetry over space links, which can ensure interoperability between space elements and ground elements belonging to different Agencies.  CCSDS also developed standard services called SLE services to transfer telecommand and telemetry on the ground.  By using these CCSDS protocols and services, interoperability between elements of different Agencies can be guaranteed to some extent, but coordination and negotiation for cross support is still done in mission-specific, labor-intensive ways.

5. 5 Cross Support Service Architecture (1/2)  The Cross Support Service Architecture establishes a common basis for cross support services through the definition of a set of common concepts and terms. It also defines basic cross support service types.  It will facilitate development of cross support systems, description of characteristics of cross support services, documentation of requirements and agreements for cross support.  This will provide guidance to:  Service providers Ground assets (e.g. GN, ESTRACK, DSN) Space assets (e.g. DRS, Lunar relay, Mars relay)  Service users (flight missions) Space assets (e.g. Spacecraft, landed vehicles) Ground assets (e.g. Mission Operations Center)

6. 6 Cross Support Service Architecture (2/2)  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) Space Services Ground Services Space Service Users Ground Service Users

7. 7 Cross Support Service Systems/Elements  A cross support service system (CSSS) is defined as a set of cross support service elements that are managed by a single authority with a single set of management policies.  A cross support service element (CSSE) is defined as a physical element that can provide one or more cross support services to any space mission element of any space agency provided that the customer element conforms to the technical interface specifications and management policies specified for the CSSE.  A cross support service element can be an element on the surface of a heavenly body (e.g., Earth, the Moon, and Mars), an element orbiting around a heavenly body, or an element in cruise through space.

8. 8 Examples of Cross Support Service Systems  The following are some examples of Cross Support Service Systems and Cross Support Service Elements. Cross Support Service System (Examples) Cross Support Service Elements (Examples) Deep Space NetworkDeep space stations A network control center Space NetworkTracking and data relay satellites A network control center Lunar NetworkLunar relay orbiters Mars NetworkMars relay orbiters Ground NetworkTracking stations on the ground

9. 9 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 CSSE S1 Ground User Element Space User Element Space side interface of CSSE 1 Ground side interface of CSSE 1

10. 10 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). CSSE 2 CSSE 1 Ground User Element Space User 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

11. 11 SERVICE VIEW

12. 12 Service View  The Service View is used to describe services provided by CSSSs/CSSEs and their functional characteristics, separately from  Physical locations where the services are provided (which are treated in the Physical View),  Communications protocols used to access the services (which are treated in the Communications View), and  Organizational or administrational issues involved in using the services (which are treated in the Enterprise View).

13. 13 Examples of Service View

14. 14 Service Management

15. 15 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 Service Return Frame Delivery Service Return Packet Delivery Service Return File Delivery Service Cross Support Service Type Basic Cross Support Service Tracking ServicesRadio Metric Data Service Delta-DOR Service Orbit Determination Service Time ServiceSpacecraft 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.

16. 16 Service Attributes  Each service provided by a CSSS/CSSE is characterized by a set of standard service attributes.  Service attributes for Forward CLTU Delivery Service (example).

17. 17 PHYSICAL VIEW

18. 18 Physical View  The Physical View is used to describe  The physical configuration of CSSSs/CSSEs and their physical characteristics, and  The topology and connectivity of the physical elements (including user elements) to support specific space missions.

19. 19 An Example of Physical View

20. 20 Physical Attributes  The physical characteristics of each CSSE is characterized by a set of standard physical attributes.  Physical attributes for flight based CSSEs (example).

21. 21 COMMUNICATIONS VIEW

22. 22 Communications View  The Communications View is used to describe communications protocols used for accessing cross support services (including service provision management) provided by a CSSS/CSSE.  Its focus, different from that of the Service View, is on the communications interfaces between CSSEs and user elements.

23. 23 An Example of Communications View

24. 24 Communications Attributes  For each of the basic communications protocols, a standard attribute set is provided.  Communications attributes for TC Space Data Link Protocol (example).

25. 25 Combined Tables  In some cases, it is easier to understand the characteristics of the service if the attributes of the communications protocols used to support the service are listed together with the attributes of that service.  The following page contains an example of a table which lists the attributes of the Return Packet Delivery Service together with the attributes of the communications protocols used to support the service.

26. 26 Example of Combined Table

27. 27 ENTERPRISE VIEW

28. 28 Enterprise View  The Enterprise View is used to describe processes and rules governing the initiation, negotiation, and agreement between the supported and supporting Agencies for the provision of cross support services.  Differing from the other architecture Views which are technical in nature, it addresses the administrative and contractual aspects of the architecture.

29. 29 An Example of Enterprise View

30. 30 Procedure for Cross 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.

31. 31 Template for Service Agreement Documents (1) 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: address@suporting.agency Supported Agency Point of Contact: Name: FirstName SurName E-mail: address@suported.agency

32. 32 Template for Service Agreement Documents (2) 1. Project Information Supporting Agency NameAgnecy_X Supported Agency NameAgnecy_Y Supported Project NameProject_Z Supported Project DescriptionPlanet A Orbiter 2. Support Information Start of Support PeriodYYYY-MM-DD End of Support PeriodYYYY-MM-DD Supporting CSSS Name(s)Network_L Supporting CSSE Name(s)Station_M, Center_N Supporting CSSE Type(s)Ground Station, Network Control Center Provided Service Name(s)Forward P Delivery, Return Q Delivery Space User Element NameABC Orbiter Space User Element TypePlanet A Orbiter Ground User Element NameX Space Operations Center Ground User Element TypeSpacecraft Control Facility Number of Contacts1/day (nominal), 2/day (contingency), Contact duration4-6 hours/contact

33. 33 Template for Service Agreement Documents (3) 3. Document Information Agency-Agency AgreementMemorandum of Understanding (No. nnn) High Level Service AgreementThis document Detailed Service AgreementDetailed Mission Requirements (No. ooo) Space to Ground InterfaceRFICD (No. ppp) Ground to Ground InterfaceGGICD (No. qqq) 4. Testing Information Interface Test Between Space User Element and CSSE Required Interface Test Between Ground User Element and CSSE Not Required (Already performed for Project W) End-to-End Data System Test Required Operations Readiness Test Required 5. Pricing Information Aperture hourly fee: $X.00 Other service fees: $Y.00 Method of service fee attribution: Reimbursable cash transaction or Quid-pro-quo arrangement

34. 34 NEXT STEPS

35. 35 Next Steps Cross Support Service Architecture June 2007JAXA 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.