CCSDS Cross Support Services Issue 0.1 October, 2008 Takahiro Yamada, JAXA/ISAS Peter Shames, NASA/JPL

Purpose of This Document Identify services that should be provided by IOAG member agencies for cross support Differentiate communications, applications, and management services Show relationships among the services Provide some thoughts on necessary / useful service views Some thoughts about generic forward / return terms

Communications Services Cross Support Service Types Basic Cross Support Services Forward Delivery Services Forward CLTU/Frame Delivery Service (these may be different svcs) Forward Packet Delivery Service (is packet relaying implied?) Forward Bundle Delivery Service (IP too, what is this service interface?) Forward File Delivery Service (what is this service interface, FTP?) Return Delivery Services Return Frame Delivery Service Return Packet Delivery Service Return Bundle Delivery Service (IP too) Return File Delivery Service Voice and Video Services Voice Service Video Service Routing/ Networking Services IP Routing/Networking Services (why are these separate from fwd / ret bundle svc, arent they just part of Bundle / IP service?) DTN Routing/Networking Service (ditto )

Application Services Cross Support Service Type Basic Cross Support Service Tracking ServicesRadio Metric Data Service Delta-DOR Service Orbit Determination Service Time ServiceSpacecraft Time Correlation Service Spacecraft Time Synchronization Service Monitor and Control Services Spacecraft Monitor and Control Service (not clear this should be a cross support service) Ground Station Monitor and Control Service (this should NOT be one) Planning Support Services (see next page) Ephemeris Access/Delivery Service Tracking Schedule Access/Delivery Service

Management Services Cross Support Service Type Basic Cross Support Service Planning ServicesCatalog Services Service Agreement Management Service Spacecraft Configuration Management Service Service Envelope Validation Service Support Commitment Service Planning Support Services Viewperiod Validation Service Mission Timeline Management Service Ephemeris Access/Delivery Service Tracking Schedule Access/Delivery Service Scheduling Services Nominal Service Request Emergency Service Request N.B. question of whether we would want to use the same planning and scheduling services for both terrestrial and space service instances. I.e. does a rover wanted service ask an orbiter for a pass?

Alternative Application Services Cross Support Service Type Basic Cross Support Service Monitor and Control Services (may be requested by users) Service Monitoring Request (monitor one or more Application or Communication Service execution instances) Service Control Request (control service production for only one Application or Communication Service execution instances, only one Svc Control at a time per service exec instance) Network Management Services (only for network operators) Manage Routing Manage Links & interfaces Manage ephemerides Manage on-board storage Mission Monitor and Control Services Spacecraft Monitor and Control Service (not clear this should be a cross support service) Ground Station Services Ground Station Monitor and Control Service (this should only be an intra- network service used by network operators)

Relationships Among Services (really need to show protocol layering here, look at ADD diagrams) Orbiter Lander Orbiter Control Center Lander Control Center Bundle Delivery U Bundle Delivery P Time Corr. P Time Corr. U GS M&C P Ground Station Bundle Delivery U Bundle Delivery P GS M&C U Bundle Delivery P

Thoughts on Different Service Views Service Interface view (per service) What service is provided to the users? How it is accessed and delivered? What is its behavior from the users point of view? What are the data objects that are transferred across the interface? Is it throughput, store & forward, or both? What security is provided / required to access & control the interface? What credentials are required? What constraints are there on the service? Check out FIPA Service definitions and ontology Service Protocol Communications view (per service) What protocols implement the service interface? What protocols support the service interface? What constraints are there on the protocols? How are end-to-end paths constructed?

Thoughts on Different Service Views, contd Mission Operations view (per related set of services) How is mission operations service provided? What mission operations service elements (and others) are involved? What are their data and control flows? How do they behave together to deliver the operations service? What constraints are there on this operations service? End-to-end View (per service) How do users request the end-to-end services (ties to service IF view)? How do users monitor and control these services? What system elements implement the service (ties to MO view)? What functions do these element perform to deliver the service (ties to svc IF view)? How do the operators of these elements monitor and control them? What constraints are there on the end-to-end service?

Thoughts on Different Service Views, contd Mission Lifecycle view (per set of services) How does this set of services support mission operations lifecycle? Are different services used during different phases, do they evolve? What are their data and control flows during / across phases? How is information managed / passed among services during the lifecycle? Are there gates to be passed to transition among phases? What constraints are there on this set of services during lifecycle? Cross Support / Enterprise view (per service) Does the service operate differently in cross support mode (vs intra-agency use)? How are contracts for services established? Are funds exchanges or is it quid pro quo or some other payment in kind? Are there constraints on what cross support users can do? How is access and security managed, how are credentials issued and managed?

Thoughts on Different Service Views, contd Questions for Infrastructure elements (per service node) What minimal set of services are required to participate? What is the full set of services provided? What is the PICS for each provided service? What service interface options are offered? What service modes are supported? Which communications links and protocols are supported? What are performance capabilities and capacities of the links and service elements? What components are used to provide service interfaces? How many simultaneous users can be serviced? What constraints on use of the element? And also what are requirements from infrastructure elements on the compliant components and sub-systems that they require?

Semi-random Thoughts on Generic Forward / Return Forward / return have been used to imply direction from / to Earth Command and Telemetry come associated with specific semantic meanings, and may still be useful but miss other data types, voice, video, software loads, OBC dumps, eng vs housekeeping Notion of request / response (/ ack / nack) is a good one too, but it is more of an interaction pattern and there are others including multi-cast Link asymmetries are likely to remain due both to physical constraints (aperture, mass, power) and different data transfer requirements FIPA uses: REQUEST, if the sender wants the receiver to perform an action, INFORM, if the sender wants the receiver to be aware of a fact, QUERY_IF, if the sender wants to know whether or not a given condition holds, CFP (call for proposal), PROPOSE, ACCEPT_PROPOSAL, REJECT_PROPOSAL, and interactions like REQUEST-WHEN, RECRUITING & BROKERING SM&C uses: SEND, SUBMIT, REQUEST, INVOKE, PROGRESS, PUB-SUB SM uses: SENDER/RECEIVER, INVOKATION, SUCCESS/FAIL RETURN, ACK RETURN CSTS uses: initiator, responder, invoker, performer, and also send, receive Maybe what we need to do is to treat the links themselves as just that, full, half, simplex, symmetric, asymmetric, uni-cast, multi-cast, broadcast as is their physical nature, and use these other semantic terms, e.g. command, telem, request, respond, upload, download to refer to the interface interactions and patterns of how the links are used