1. 1 A Proposal for a Cross Support Service Architecture Takahiro Yamada (JAXA/ISAS) Narita Kaneaki [JAXA] January, 2007 (Issue b) Editorial comment Peter Shames, 3 April 2007

2. 2 BASIC CONCEPTS

3. 3 Purposes of the Cross Support Service Architecture  A common architectural framework for cross support services is needed, with which  Requirements for cross support can be stated in a common way;  Core services and interfaces (which are common to many agencies) can be specified.  Agency-specific extensions can be accommodated.  Priority of the architecture core elements can be assessed.  Inter-agency collaborative development can be on a solid basis.  With this framework, coordination and negotiation for inter- agency cross support can be more efficient.  It will facilitate better planning and interface development for collaborative missions between agencies.

4. 4 An example: ESA-JAXA/ISAS BepiColombo Mission JAXA/UsudaESA/Cebreros MPOMMO ESA ESOC JAXA/ISAS SSOC MPO+MMO data BepiColombo MOC MMO Ops System SLE Gateway MMO Ops System  ESA provides JAXA/ISAS with space and ground services.  JAXA/ISAS provides ESA with ground services.

5. 5 Cross Support Service Architecture (1/2)  The cross support service architecture (CSSA) is a standard architecture for cross support service systems.  It is the framework that defines standard services, interfaces, and their relationships, providing 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 employs 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 Definitions: 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

9. 9 Cross Support Service Element - Basic 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 2 CSSE S1 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 Modified from IOAG / JAXA CSSA, Jan 2007, rev b

10. 10 SERVICE VIEW

11. 11 Service View  The Service View of this architecture is used to describe functional characteristics of the services provided by cross support service systems and cross support service elements.  Specifically, it describes:  Functional/performance characteristics of services,  Methods and/or standards for using services,  Methods and/or standards for managing services,  Etc. Service Provision Management Service Provision Service Utilization Management Service Utilization Service Management Interface Service Interface User Element CSSE

12. 12 Types of Cross-Support Services

13. 13 Example of Service View (CSSE Providing Delivery Services) Space User Element Cross Support Service Element Online Forward Delivery Service Offline Forward Delivery Service Online Return Delivery Service Offline Return Delivery Service Ground User Element Service Interfaces Modified from IOAG / JAXA CSSA, Jan 2007, rev b

14. 14 Service Attributes of CSSS/CSSE  Each Service provided by a Cross Support Service System/Element has the following service attributes. AttributeTypical values DirectionForward, Return Delivery Mode (Latency)Online, Offline (Store & forward) Quality of serviceTimely, Complete, … Data units deliveredFrames, Packets, Files, … Online data selection criteriaSCID, VCID, APID, IP address, … Offline data selection criteriaReception times, Service Instance ID, … Ground side service protocolSLE, NASCOM, None, …

15. 15 Cross Support Service Element for Provision Management Example of Service View (Service Management) Cross Support Service Element Online Forward Delivery Service Offline Forward Delivery Service Online Return Delivery Service Offline Return Delivery Service Service Provision Management Service Utilization Management Service Management Interface Internal Service Control Interfaces Modified from IOAG / JAXA CSSA, Jan 2007, rev b

16. 16 Service Management Attributes of CSSS/CSSE AttributeTypical values Location of Service Provision Management Location, Network address, … Service Management Interactions Online protocol, File transfer, E- mail exchange, … Service Management ProtocolSLE SM, SNMP, FTP, SMTP, …  Each Cross Support Service System/Element has the following service management attributes.

17. 17 Example: Service View of Deep Space Network Space User Element DSCC Online Forward Delivery Service Online Return Delivery Service Offline Return Delivery Service Ground User Element Other services were omitted from this diagram. Modified from IOAG / JAXA CSSA, Jan 2007, rev b

18. 18 Example: Service Attributes of Deep Space Network Online Forward Delivery Service Forward or ReturnForward Online or OfflineOnline Quality of ServiceComplete Data units deliveredCLTUs Online Data selection criteriaNone Ground Side Service ProtocolSLE FCLTU Offline Return Delivery Service Forward or ReturnReturn Online or OfflineOffline Quality of ServiceComplete Data units deliveredFrames Offline Data selection criteriaVCID, Reception Time Ground Side Service ProtocolSLE RAF, RCF Online Return Delivery Service Forward or ReturnReturn Online or OfflineOnline Quality of ServiceComplete or Timely Data units deliveredFrames Online Data selection criteriaVCID Ground Side Service ProtocolSLE RAF, RCF

19. 19 Example: Service View of Mars Network Space User Element Mars Odyssey/MRO Online Forward Delivery Service Offline Forward Delivery Service Online Return Delivery Service Offline Return Delivery Service Ground User Element Modified from IOAG / JAXA CSSA, Jan 2007, rev b

20. 20 Example: Service Attributes of Mars Network Online Forward Delivery Service Forward or ReturnForward Online or OfflineOnline Quality of ServiceComplete Data units deliveredBits Online Data selection criteriaNone Offline Return Delivery Service Forward or ReturnReturn Online or OfflineOffline Quality of ServiceComplete Data units deliveredBits Offline Data selection criteriaNone Online Return Delivery Service Forward or ReturnReturn Online or OfflineOnline Quality of ServiceComplete Data units deliveredBits Online Data selection criteriaNone Offline Forward Delivery Service Forward or ReturnForward Online or OfflineOffline Quality of ServiceComplete Data units deliveredBits Offline Data selection criteriaNone

21. 21 PHYSICAL VIEW

22. 22 Physical View  The Physical View of this architecture is used to describe the physical configuration and physical characteristics of cross support service systems and cross support service elements.  Specifically, it describes:  Physical location,  Topology (connectivity),  Physical medium for accessing,  Etc.

23. 23 An Example of Physical View CSSE D1 CSSE D2 CSSE S3 CSSE S1 CSSE S2 Ground User Element Space User Element CSSS D CSSS S Modified from IOAG / JAXA CSSA, Jan 2007, rev b

24. 24 Physical Attributes of CSSS/CSSE  Each Cross Support Service Element in a Cross Support Service System has the following physical attributes. AttributeTypical values Element typeOn the surface of xx, Orbiting around yy Location or TrajectoryGeographical location, Orbital elements Space side access mediumRF at Z-band, modulation, viewperiods, pointing params Dedicated wired line Ground side access mediumRF at Z-band, modulation, viewperiods, pointing params Dedicated wired line Modified from IOAG / JAXA CSSA, Jan 2007, rev b

25. 25 Example: Physical Attributes of Deep Space Network Goldstone DSCC Element typeOn the surface of the Earth LocationGoldstone, California, USA Canberra DSCC Element typeOn the surface of the Earth LocationCanberra, Australia Madrid DSCC Element typeOn the surface of the Earth LocationMadrid, Spain There are attributes for each station (DSS) at each DSCC but they are omitted here.

26. 26 COMMUNICATIONS VIEW

27. 27 Communications View  The Communications View of this architecture is used to describe communications protocols used for accessing services provided by cross support service systems and cross support service elements.  Specifically, it describes:  Protocol stacks for accessing services,  Parameters of protocols used for accessing services,  Etc.

28. 28 An Example of Communications View Cross Support Service Element Online Forward Delivery Service Network Protocol Transport Protocol Data Link Protocol Physical Protocol Network Protocol Transport Protocol Data Link Protocol Physical Protocol Modified from IOAG / JAXA CSSA, Jan 2007, rev b Ground User Element Space User Element User Element User Element Network Protocol Transport Protocol Data Link Protocol Physical Protocol Network Protocol Transport Protocol Data Link Protocol Physical Protocol

29. 29 Communications Attributes of CSSS/CSSE AttributeTypical values Ground side service protocolSLE RAF, CLTU, … Ground side transport protocolTCP, UDP, … Ground side network protocolIP, … Ground side data link protocolPPP, … Ground side physical protocolISDN, … Space side transport protocolNone, TCP, SCPS-TP, … Space side network protocolSpace packet protocol, IP, … Space side data link protocolSpace data link protocol, … Space side codingTurbo, Reed-Solomon, Convolutional, BCH, … Space side carrier frequencyxxxxMHz Space side modulationQPSK, PSK-PM, BiPh-PM, …  Each Cross Support Service Element has the following communications attributes.

30. 30 Communications View of Deep Space Network DSS Any Delivery Service ISDN or dedicated Space Pkt Protocol Space Data Link Protocol CCSDS RF&Mod. IP TCP Space Pkt Protocol Modified from IOAG / JAXA CSSA, Jan 2007, rev b Ground User Element Space User Element ISDN or dedicated IP TCP Space Pkt Protocol User Element Space Pkt Protocol Space Data Link Protocol CCSDS RF&Mod. User Element SLE

31. 31 ENTERPRISE VIEW

32. 32 Enterprise View  The Enterprise View of this architecture is used to describe organizational and administrational features of the services provided by cross support service systems and cross support service elements.  Specifically, it describes:  Organizations that provide services,  Facilities that deliver services,  Policies to provide services,  Contracts to use services,  Activity for testing the service interface, e.g. compatibility tests and end-to-end tests  Documents to use services,  Pricing information, e.g. reimbursable, quid-pro-quo  Etc.

33. 33 An Example of Enterprise View CSSE S3 CSSE S1 CSSE S2 Ground User Element Space User Element Service Utilization EnterpriseService Provision Enterprise Modified from IOAG / JAXA CSSA, Jan 2007, rev b

34. 34 Enterprise Attributes of CSSS/CSSE  Each Cross Support Service System (and its Cross Support Service Elements) has the following enterprise attributes. AttributeTypical values Agency (or organization) that owns the CSSS NASA, ESA, ABC Space Communications Company, … Policies for providing servicesAvailable for any science mission, … Types of contracts to use the services Reimbursable, Cooperative, … Activity for testing the service interface Level of testing support, e.g. nominal and special tests Types of documents to use the services Service Agreement Document, Interface Control Document, … Pricing Information$xxx/hour + $yyy (fixed) (Others)

35. 35 Analysis of JAXA Position Paper  The JAXA CSSA approach provides a very useful framework for describing cross support architectures  Definitions of terminology  Viewpoints and representational methods  Initial set of attributes  Permits description of cross support architecture from several viewpoints  Starting with enterprise level  Arriving at a deep enough technical level  Should support presentation of concepts to management and also allow adequate representation of interface details to define how they are to be actually implemented  As presented (with mods) it adheres to the RASDS methodology  The Service Catalog and attribute sets for interfaces in various views is a valuable extension, especially for this use  Enterprise view with facility “cartoons”, ala DODAF OV-1 or SV-1 may be useful as top level view Provided by Peter Shames 3 April 2007

36. 36 SPACE NETWORK MISSIONS GROUND NETWORK MISSIONS DEEP SPACE NETWORK MISSIONS SN SERVICES, INTERFACES, SPECTRUM DSN SERVICES, INTERFACES, SPECTRUM Educational Users National & DoD Space Telescope Space Station Space Transportation Radio Astronomy Planetary Explorations Earth Observing Airborne Experiments GN SERVICES, INTERFACES, SPECTRUM NASA Integrated Services Network (NISN) Today ’ s NASA Network Architecture Operational View Graphic (OV-1) NASA Network Architecture Task DSN Status, Chuck Tang, Aerospace 23 September 2004

37. 37 Reference: DSMS Telecomm Link Design Handbook (810-005) Deep Space Missions USER SPACE LINK INTERFACES Radio Astronomy Goldstone Solar System Radar VLBI DSN Resource Allocation DSN Scheduling DSN Predicts DSN SOEs Remote Operations Support Area (ROSA) (Contractor Facility - 1400 S. Shamrock Ave. Monrovia, CA) Deep Space Operations Control Center (DSOCC) Central Communications Terminal (CCT) Advanced Multi-Mission Operations System (AMMOS) Network Operations Control Team (NOCT) JPL Navigation Services 3 Commercial T-1 Circuits Inside JPL Firewall JPL Institutional Flight Projects Radio Metric Data Conditioning (RMDC) AMMOS LAN Inside JPL Firewall NISN/Commercial Carriers Foreign & Domestic NISN/Commercial Carrier 70 m L-Band S-Band X-Band 34 m HEF BWG X-Band 34 m BWG S-Band X-Band Ka-Band 34 m HS BWG S-Band 26 m S-Band Flight Projects JPL Institutional Communications Building 171 Commercial Circuits Inside JPL Firewall JPL Institutional LAN Australian Commercial Carrier JPL Institutional LAN GSFC Flight Dynamics Facility GDSCC MDSCC CDSCC Parkes Radio Observatory, Australia Deep Space Network – Interfaces System Interface Description (SV-1) NASA Network Architecture Task DSN Status, Chuck Tang, Aerospace 23 September 2004

38. 38 Backup Materials

39. 39 ISSUES AND NEXT STEPS

40. 40 Technical Issues (1/3)  There are space and ground users for the same service. We should consider how to specify these two users. (C. Sunshine)  I think, for a service provided by a CSSE, we should define space user, ground user, and service utilization manager, and space side interface, ground side interface, and service management interface.  What is the CSSE? Is it the whole ground station or the equipment that provides the service? (J. Pietras)  In my opinion, a CSSE is any physical element that has cross support service interfaces. The user element only needs to know how to use the services through the service interfaces without any knowledge of the physical configuration of the element.

41. 41 Technical Issues (2/3)  There is dependency among views. That is, there are some attributes that depend on the values of attributes defined in other views. We need to consider how to describe relationships and dependency among views. We may also need to reconsider the definition and number of views. (W. Tai)  I don’t have any clear response at the moment but will provide one in one month.

42. 42 Technical Issues (3/3)  We need to categorize services (e.g., layering and/or composition of services). (J. Pietras)  I haven’t done this due to lack of time but will provide a draft material in a month.  We need to define the function and a standard set of attributes for each of the services. (W. Tai)  I haven’t done this due to lack of time but will provide a draft material in a couple of months.  The policy and types of agency-to agency agreements should be elaborated so that they can be used in any MOU. (W. Tai)  I agree that we need to define a standard set of attributes that can characterize any type of agency-to-agency agreement. I will prepare a draft material in one month.

43. 43 Procedural Issues  IOAG does not have any experience in developing standards, a procedure to develop them, or technical writers who can write good technical specifications.  For the Cross Support Service Architecture, there is only an action item, but I do not believe that a high-quality standard can be generated only as a response to an action item.

44. 44 PROPOSAL TO CREATE A JOINT IOAG-CCSDS WG  We need to establish a special WG consisting of experts on cross support and standardization from both IOAG and CCSDS that will review the Cross Support Service Architecture document generated by IOAG and add any missing contents.  The WG will then be transformed to develop the architecture standard specification to be published by CCSDS as a standard.  JAXA/ISAS will lead the WG to review the IOAG cross support service architecture, in the form of an IOAG guidance document, and later develop the CCSDS cross support service architecture standard.  This approach ensures continuity of the activity from the IOAG focus to the CCSDS focus while meeting the need of the IOAG stakeholders.

45. 45 Tentative Schedule Milestone DateActivity and Milestone Mid 2-2007Conduct 2 or 3-day working session between Yamada, Narita, and Tai to complete the key technical areas of the document. End of 2-2007Complete the draft version. Issue the draft version to the IOAG members and the special WG for review. End of 2-2007Distribute the template for the agency asset-specific service attribute table for the IOAG members to fill it out. End of 4-2007IOAG members provide completed agency asset-specific service attribute tables End of 4-2007Review completed by the IOAG members and the special WG. By IOAG-11 meeting 6-2007 date Complete the “final” version of the IOAG Cross Support Service Architecture document with accepted comments incorporated. IOAG-11 meetingPresent the key features of the architecture and issues disposition. Obtain endorsement from the IOAG members.

46. 46 Example: Physical View of Mars Network Ground User Element Space User Element Mars Network Mars Odyssey MRO

47. 47 Example: Physical Attributes of Mars Network Mars Odyssey Element typeOrbiting around Mars OrbitOrbital elements = xxxxxx MRO Element typeOrbiting around Mars OrbitOrbital elements = yyyyyy

48. 48 Communications Attributes of Deep Space Network Deep Space Station Ground side transport protocolTCP Ground side network protocolIP Ground side data link protocolPPP Ground side physical protocolISDN, Dedicated Circuit Space side transport protocolNone Space side network protocolSpace packet protocol Space side data link protocolSpace data link protocol (TM/TC/AOS) Space side coding (forward)BCH Space side coding (return)Turbo, R-S, Convolutional Space side carrier frequency (forward) 2025-2120MHz, 7145-7190MHz Space side carrier modulation (forward) PM

49. 49 Communications View of Mars Odyssey Space User Element Mars Odyssey Any Delivery Service Ground User Element Prox-1 Data Link Protocol Prox-1 Physical Space Packet Protocol Space Data Link Protocol CCSDS RF&Mod.

50. 50 Communications Attributes of Mars Odyssey Mars Odyssey Ground side transport protocolNone Ground side network protocolSpace packet protocol Ground side data link protocolSpace data link protocol (TM/TC/AOS) Ground side coding (forward)BCH …. Space side transport protocolNone Space side network protocolNone Space side data link protocolProx-1 data link protocol Space side coding (forward)BCH ….

51. 51 Communications View of MRO Space User Element MRO Any Delivery Service Ground User Element Prox-1 Data Link Protocol Prox-1 Physical Space Packet Protocol Space Data Link Protocol CCSDS RF&Mod. CFDP

52. 52 Communications Attributes of MRO MRO Ground side transport protocolCFDP Ground side network protocolSpace packet protocol Ground side data link protocolSpace data link protocol (TM/TC/AOS) Ground side coding (forward)BCH …. Space side transport protocolNone Space side network protocolNone Space side data link protocolProx-1 data link protocol Space side coding (forward)BCH ….