1. SMWG Closing Report Erik Barkley Chair, SMWG Interim Meeting Greenbelt, MD, USA 06 -- 08 June 2007 Draft 1

2. eb-2 Contents 1.Interim Meeting Agenda, Attendees 2.Summary of notes/achievement/decisions 3.Updated Plans 4.WG Summary Status at Close of Interim Meeting

3. eb-3 Interim Meetings Agenda, Attendees

4. eb-4 Review of Section 4 (Service Package) Updates (1/2) Issue: Proposal for inclusion of off-line data retrieval service packages in the same definition as that for an active Spacelink session service package –Original intention was to allow for off-line transfer services and online transfer services to be scheduled more or less contemporaneously via the same service package –Further analysis indicated potential issues as the off-line retrieval could be completely unrelated to an ongoing active Spacelink session Formal state modeling (in conjunction with state table discussion -- see later slides) indicates difficulty in proper modeling of states with respect to “hybrid” service package which in turn implies potential issues with clearly identifying activities in an operational setting E.g, the the service package start time has different semantics with respect to a service package in relation to a Spacelink session versus a data retrieval session E.g., selection of alternate scenario has no significance for a service package with respect to a data retrieval session –More or less contemporaneous off-line and online transfer service packages can be expressed by using start times configured accordingly in the separate service packages Conclusion –Data set composition/class diagram will allow for a service package to be stated for either a data retrieval request or a Spacelink session request (but not both). –Service package states will be essentially modeled separately for these cases (although they may share the same initial state).

5. eb-5 Review of Section 4 (Service Package) Updates (2/2) Issue: The revised service package definition allows for CM to unilaterally return multiple Spacelink sessions, resulting in a “handover” situation with respect to CM’s network. Although potentially a desirable feature, as currently presented, may result in services that are not friendly toward UM. Conclusion –Addition of a parameter for indicating whether or not UM will allow for this outcome in a service package result to the definition of the service package invocation stereotype Rationale was that UM may have a critical situation which cannot tolerate the possibility of a disruption in connectivity to the spacecraft due to the handover from the multiply scheduled Spacelink sessions See Also –Notes on Concept Book review –J. Pietras’ e-mail of 23 April 2007, subject “Updated CSP material on CWE” Other Notes –Agreed to state requirements, where applicable, relative to state tables (for example, CSPU-4, service package with deferred transfer services) –Noted that “indexing” of off-line data via antennaRef, transferServiceProfileRef is in conformance with off-line operations specified by the SLE transfer serivces; also noted that SerivcePackageId may be useful, but not to be included in Red-2 (a RID may be issued upon further review)

6. eb-6 Concept (Green) Book Review Need to better illustrate usage of recommendation –During the course of the meeting several concepts identified that need to eventually be folded into the Green book Examples: “Handovers” for continue tracking: Handovers expresed via return of multiple scheduled Spacelink sessions in a service package Transfer services that may continue to be bound even though the Spacelink is being “reconnected” during a handover situation UM has option to control whether or not handovers are allowed Proposed Service Package operation as the result of prior (not covered in the recommendation) rule negotiation between CM + UM and placement of rules at CM A general action is to provide this type of information to Hugh Kelliher To constitute section(s) 3+ of the Green book –Agreed that the use case approach taken with the previous version of the Green book was too formal Agreed that conceptual writeups more in keeping with those produced for the SpaceOps 2006 paper should be provided More definition of terms to be added –Concept book is to introduce terms such as “document” where they indicate a sufficiently different semantic definition than that normally used (In this case “document” meaning a collection of messages or message set). Updated Overview of recommendation –Agreed on names of new operations for Red-2, and their underlying message exchange implementation. (See E. Barkley’s e-mail of 6-June-2007 for updated diagram) See Also –H. Kelliher’s e-mail of 23-May-2007

7. eb-7 State Table Discussion Inclusion of State Tables in Recommendation –Consensus is that state tables produced so far are of sufficient value that they will be included in the Red-2 recommendation Message Exchange Protocol State Diagrams –Agreed to various modifications Addition of timeouts for the invoker state view Addition of a validating and performing state for a two-phase messaging pattern Addition of separate validating and performing states on three-phase messaging pattern Addition of transition out of validating state via the failed/successful return messages (two-phase messaging pattern Removal of exception response transistion for three-phase transition from the performing state (invoker view; exception response can only occur during earlier validation state by definition) Service Package State Diagrams –State machines for online versus off-line data retrieval service packages are to be modeled separately (See also information on formal state modeling on service package updates review slide)service package updates review slide State Tables To Be Included for all Major Information Objects – Recognized that all of the major information objects within the recommendation have identifiable states E.g., a configuration profile that is referenced by service package is in a different state than a configuration profile that is not referenced by service package (it cannot be deleted in the former case, but can be deleted in the latter case) Applicable to service agreements, trajectory predictions, Spacelink session profiles, transfer service profiles, and event sequences Simplified Activity Diagram –Simplified activity diagrams resulted as a discussion of the state tables –The idea presented will be captured via formal UML for the next version of the Red Book (See A. Crowson’s presentation, in E. Barkley’s 08 June 2007 e-mail: “Simplified message exchange diagrams from Anthony” )

8. eb-8 Review of ProposeServicePackage Operation Single Scenario Definition –Agreed to revise the composition of the messages for the operation so that it is composed with respect to a single service scenario (vs. the scenario definition being excluded in the work so far) –Rationale: The services scenario is a core concept of the service package Even though only a single scenario is likely to be possible in a CM rule-based generation of propose service packages, maintaining the definition across the board is consistent and may have implementation benefits Operation Ownership –Per the Colorado Springs meetings it was agreed that ownership of operations is stated on a per operation basis –Work done to date still needs to incorporate this notion “Subset” acceptance of proposed service package disallowed –Per the Colorado Springs meeting it was agreed that the semantics of the propose service operation should be kept as simple as possible by disallowing modifications by UM in its acceptance of the proposed service package ( IE in response to the proposed service package invocation message) –Work done to date will be revised to incorporate this notion Note: The recommendation offers the RSP operation to accommodate this use case Broader accommodation of usage scenarios –“provisional scheduling flag” (exact name TBD) to be added to service agreement parameters for this operation Governs whether or not the operation represents a committed service package on the network schedule or not –Rationale: Near Earth operations tend to prefer the notion of committing relatively rapidly Deep space operations tend to require more negotiation back and forth and the notion of being provisionally scheduled offers better support in the domain

9. eb-9 Review of Section 5 (Configuration Profile) Proper Name –Agreed that the name of the SpaceLinkServiceProfile is more properly stated as the SpaceLinkSessionProfile (to indicate the on-line nature of the services, vs. other services and their profiles that may eventually be included in the recommendation) Further review deferred due to lack of time –To be addressed during telecon See Also –J. Pietras’ e-mail of 15-May-2007, “New Add Space Link Service Profile operation section”

10. eb-10 Prototype Coordination ESA Prototype –Statement of work issued –Prototype development to start ~August –Projection for readiness for inter-operation is early 2008 –ICD development has started To be circulated in late July JAXA/JPL-DSN Prototype Coordination –JPL prototype server needs to have its TZ set to GMT/UTC –Agreed to examine/attempt usage of XmlEncryption, WS-Signature to secure SM messages Use of separate subject lines for implementation over SMTP to allow separation of secured message traffic from non-secured message traffic (to help with testing activities) –JPL prototype needs to put proper protocol version Id in its messages –JAXA ALOS mission using PCM/PSK-PM modulation scheme not currently included in Red-1 Agreed to provide and note minor schema extension to enable exchange of message for purposes of prototype inter-operation –Usage of SOAP/HTTP or JAVA REST (vs SMTP) seen as a worthy goal, but not likely given available (lack of) resources –JAXA/ALOS and DSN SLE Transfer services for shadow track demonstration issue resolution approach JAXA/JPl to attempt inter-operation of JAXA’s Blue-1 (as opposed to Blue-2) compliant SLE implementation with JPL’s Red book implementation Back up plan is to record shadow track data for non SLE transfer to JAXA

11. eb-11 Canceling Operations Already In Progress Applicable to Service Package Creation/Replacement for Red-2 –CSP and RSP operations identified as being the prime use case for cancellation of operations already in progress –Will be addressed in the recommendation via the use of already defined delete service package (DSP) operation –Does not require revision of the message exchange protocol –Will be stated in reference to service package state diagrams –General idea Once CSP or RSP operation has achieved the validated state, the delete operation is possible Note: this implies that UM can not issue the DSP operations before receiving the xSP-AR message Note: if the underlying communication service fails, there is currently no acknowledgment timeout defined, meaning that UM may not always be able to “cleanly” determine when the CSP/RSP may be cancelled via a DSP operation Invocation of a DSP operation while a previous CSP or RSP operation for the same service packages in progress, results in DSP-SR and CSP-FR messages being produced by CM

12. eb-12 Update on Event Sequence Remodeling Optional bi-lateral data set for xSP-SR messages –Remodeled event sequences to date removes inability to state bilaterally defined event sequence information for sequences that are stated on a per service package basis –Current service package return message definitions do not allow for expression of resolved/scheduled event times –Addition of nullable data set to allow for this information to be expressed in a bilateral fashion agreed to Rationale As this is nullable it does not detract from the notion of standardized service packages as minimum recommendation compliance Provides better support for incremental adoption of the recommendation by those agencies with sequenced spacecraft carrierProfileRef information to be included –Spacelink session profile allows for multiple carriers to be defined –Event sequencing information allows for sequences for multiple carriers to be stated –Proper linkage required to indicate that a particular event sequence applies to a particular carrier definition See Also –E. Barkley + S. Zendejas’ presentation “Event Sequence Remodeling for Red-2”

13. eb-13 Multiple Reference Center Trajectory Predictions Multiple trajectory prediction references approach choosen –See E. Barkley’s e-mail of 02 June 2007, “Multi reference center trajectories” –Service package definition to be modified to allow for multiple trajectory references to be stated Applicable to service package invocation and result stereotypes as well as the proposed service package definition –Service agreement to be augmented to include valid CENTER_NAME parameters for validation of OEM trajectory predictions

14. eb-14 Inclusion of Ranging and Radiometric Service Management for Red-2 Ranging, Radiometric inclusion unlikely for Red-2 –In general, insufficient information available to accurately, confidentially state what needs to be included in Red-2 –No analysis done yet for radiometric service management –Results for preliminary analysis for management of DSN sequential tone ranging presented Tone Ranging parameters vary over the life of a mission (ie belong in the configuration profile section) Number of ranging tones to be utilized (Ambiguity that can be tolerated in ranging determination) Integration Time Preliminary information on DSN PN ranging implementation (not operationally available yet) indicates Indication of regenerative spacecraft transponder needed (probably in service agreement) Spread spectrum pattern fixed for all missions Integration time likely to be on a per configuration profile basis –NASA/JPL to continue work to allow for inclusion of sequential tone ranging management –Other agencies strongly encouraged to supply information about ranging and radiometric services See Also –E. Barkley’s e-mail of 14 May 2007, “Process overview for DSN sequential ranging service”

15. eb-15 Jan 2007 Jul 2007Jan 2008 Concept of Operations (Green Book) Jul 2008 Interoperations/Demo Track Document Production Track Updated Plans for Near-Term Deliverables SMWG Intermediate SLE SM Red 2 Production Red2 XML schema CCSDS Fall DSN Red-1 Compliant Prototype JAXA Red-1Compliant Prototype ESA Red-1 Compliant Prototype Red2 Agency review CCSDS Spring CCSDS Winter Red 2 Conceptual Analysis Red-2 Red-1 Specific Analysis of Ranging & Radiometric SM Key ActivityDate Updated, completed Conceptual Analyses for committed Red-2 production, updates June 07 Intermediate Meeting (Red-2 production check, adjustments) June 07 Detailed analysis for management of Ranging, Radiometric Services Oct 07 Operations Concept Green BookOct 07 Red-2 (Submission to Secretariat) Dec 07 XML Schema Update (Red-2 Compliance) Jan 08 Prototype Interoperations (Red- 1 Compliant) Apr 07– Apr 08 Inclusion of management of ranging and radiometric service is unlikely for Red-2.

16. eb-16 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 W3C XmlSchema2 nd PriorityOK; Schema updates to be sequenced after Red-2 updates At least two independently developed interoperable prototypes 2 nd PriorityPrototype activities are underway –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 Green (Concept) Book3 rd Priority Current projection is that basic Green Book will be available in time for Red-2 Review –Very slim production resources –Insufficient resources for producing advance use cases in document Best Practices Book4 th PriorityNo resources available WG Summary Status