The use of Space Link Extension services require the exchange of information that will allow a space flight mission to acquire those services from SLE service providers. The current ad hoc mechanisms for arranging, scheduling, control, and monitoring of SLE services are fragile and manually intensive. Production of the currently-specified suite of SLE services is coupled to the underlying radio frequency, modulation, coding, and link characteristics. There are no current standards for arranging, scheduling, control, and monitoring of TT&C services. The potential user base for a service management standard for arranging, scheduling, control, and monitoring of SLE and TT&C services is larger than the space Agencies that constitute the CCSDS membership.

The goals of this Working Group include:

1) Develop a conceptual service management framework that identifies the categories of interactions between a spaceflight mission and a provider of TT&C and SLE services that are carried out for the purposes of arranging, scheduling, monitoring, and possibly controlling the provision of TT&C and SLE services.

2) Within the scope of the conceptual service management framework, develop a unified standard for the exchange of information by which a spacecraft mission requests SLE and TT&C services from a provider of such services, and ancillary information necessary to make such service requests realizable.

3) The service management standard is to have the following characteristics:
a) it will support the request for provider services conforming to CCSDS RF, modulation, coding, space link, SLE transfer service, and orbit and trajectory data Recommendations;
b) it can be implemented at multiple levels of automation, up to and including the fully automated exchange of all service management service request information between space flight mission and TT&C/SLE service provider;
c) it will be developed using widely-used, commercially-supported standard methodologies and technologies;
d) it will be organized in a way that will permit future addition of standard interchanges of other categories of information identified in the conceptual service management framework;
e) it will be possible to extend the standard to support the interoperable management of additional services, or refinements to the management of the baseline set of TT&C and SLE services;
f) it will be organized in a way that allows for incremental adoption, implementation in conjunction with existing ad-hoc mechanisms such that an incremental migration path from legacy ad-hoc methods to standardized service management can be accommodated.

The risk that the technology needed to implement the standard will not be available (or too expensive) has been significantly reduced by the adoption of XML as the representation language. XML is the de facto standard data structure specification language, and there is a large and growing number of commercial and free development tools and support by data system products such as DBMSs. The risk that specifications will be incorrect or not feasible for implementation is reduced by concurrent development of multiple prototypes. SLE Service Management prototypes are under way for the JPL Deep Space Network (DSN), in a service provider role, , the European Space Agency (ESA) in a service user role, and the US Air Force Satellite Control Network Interoperability Project in a service user role.. Plans are to have at least the service user prototypes interoperate with the service provider in support of Red Book validation and review.

Lack of resources or reassignment of previously-committed personnel is a constant risk to all standards-making processes. The approach to mitigating this risk is to define the minimal set of capabilities that constitute a ‘SLE Service Management Service Request’ capability, and then adjust the deployment of available resources to ensure that those capabilities are addressed at a minimum. Of course, if the available resources fall below even that minimally-required level, a schedule slip may be required.

A CCSDS standard has two audiences: the eventual users of the systems that are built in conformance to the standard, and the implementers of those systems. If the standards are aimed exclusively at the eventual users, there is a risk that the standard will lack many of the low-level details required for true interoperability of independent implementations. If the standard attempts to address these myriad low-level details (which system implementers will need), there is the risk that the user reviewers will judge the result too complicated. The approach to mitigating these risks is to develop the standard via a two-tiered set of specifications: a ‘service specification’ of the functional and performance capabilities as viewed from the users' perspective; and an ‘XML Schema specification’ that defines the data representation and protocol for the interactions between the interoperating systems necessary to provide those functional and performance capabilities.

The service request standard is being developed as a consolidation and evolutionary refinement of best practices of SLE and TT&C service providers. As such, it will define ‘standard’ versions of capabilities that in many cases already exist in at least some of the CCSDS member agency networks. If the standard is interpreted to be an ‘all or nothing’ proposition, there is a risk that it will be judged as requiring unnecessary costs to replace those legacy capabilities, resulting in the rejection of the standard. The approach to mitigating this risk is to identify legacy capability interoperability points, and structure the specifications so that legacy capabilities can be used in place of their standardized counterparts. This will allow an SLE/TT&C service provider to substitute existing capabilities where they are functionally equivalent to the standard-based ones, allowing an evolutionary adoption of the standard. (Of course, use of such legacy capabilities will come at the loss of standardized interoperability in those functional areas, and this will be a trade-off that any service provider must make in deciding which legacy capabilities to retain vice replace with the standardized versions).