<p>Delta DOR Analysis – Paul’s Notes Date: May 6, 2018</p><p>Purpose The purpose of this document is to describe an analysis of Delta DOR activities with respect to the CCSDS Service Management Blue book and the later re-factored red books for Blue 2. Of particular emphasis is to develop proper models that 1) describe, at a high level, the problem space of incorporating Delta DOR into service management, and later, to 2) describe possible solutions for updating the constituents parts of the service management specification including but not limited to message content, operations, service management roles and participants, and the reference framework. This document is a work in progress.</p><p>Procedure 1. Study Delta DOR concept – including scheduling, sequencing, configuration, tracking and accountability 2. Build a model of activities to represent data flow or major entities involved in a Delta DOR activity. Use CCSDS Reference model entities as much as possible. 3. Identify informational entities that are deemed necessary for requesting Delta DOR service.</p><p>Results</p><p>Context The problem being addressed here is for Delta DOR activities involving participants of different agencies. Typically, Delta DOR involves two antennas. This study does not address the configuration of two antennas being requested at a single provider based on the assumption that the multi-agency approach will also work for single- agency.</p><p>The general service management environment: The above diagram represents the CCSDS SCCS environment as it exists and is accepted today. As we start to analyze Delta DOR activities, we will document how the environment is used and/or changed to handle those activities.</p><p>Based on a basic study of Delta DOR, the following use case diagram describes, at a high-level, the functionality needed in service management to handle Delta DOR: Concepts Revisiting the SCCS environment, here is what a multi-agency Delta DOR activity could look like: The state model for event sequencing: The state model for a conceptual service package:</p><p>Key points: The life-cycle has to address both agencies; you can’t have an established Delta DOR service instance without both agencies being “established” or in other words committed to the service.</p><p>Reference framework: (Placeholder)</p><p>Considerations 1. Two agencies participating. Both will collect DOR tones and radio signal from the same spacecraft and quasar, respectively. What is the container of artifacts, comparable to a service package, at the CM? At the UM? a. Approaches i. A “super” package that contains an ID and can provide scenarios that translate to agency-specific scenarios ii. Adding to reference framework ie. Cross-referencing service packages 2. Cardinality changes a. UM to two CM’s – translates to multiple provider ports b. Service Package to Transfer Services – the assumption is that Delta DOR data must be collected from both CM’s to a UM 3. Incorporating Tracking Data Message (TDM) – do we need to manage them?</p><p>Approach using a “super” service package:</p><p>The MultiAgencyServicePackage could be a UM-only entity that references its major inter-agency parts, the ServicePackage (as we know it today). </p><p>Scenarios (placeholder)</p><p>Impact to the book (placeholder) Adding a Delta DOR Service, comparable to Telemetry and/or Ranging (if defined). Specifying bounds of service Specifying recording periods Specifying processing and transfer</p><p>References:</p>