ISO 23104:2020

INTERNATIONAL ISO
STANDARD 23104
First edition
2020-01
Space link extension — Cross
support transfer service —
Monitored data service
Reference number
©
ISO 2020
© ISO 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on
the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html.
This document was prepared by Consultative Committee for Space Data Systems (CCSDS) (as CCSDS
922.1-B-1, April 2017) and drafted in accordance with its editorial rules. It was assigned to Technical
Committee ISO/TC 20, Space vehicles, Subcommittee SC 13, Space data and information transfer systems
and adopted under the “fast-track procedure”.
Any feedback or questions on this document should be directed to the user’s national standards body.
A complete listing of these bodies can be found at www.iso.org/members.html.
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
CONTENTS
Section Page
1 INTRODUCTION . 1-1
1.1 PURPOSE OF THIS RECOMMENDED STANDARD . 1-1
1.2 SCOPE . 1-1
1.3 APPLICABILITY . 1-2
1.4 RATIONALE . 1-2
1.5 DOCUMENT ORGANIZATION . 1-2
1.6 CROSS SUPPORT TRANSFER SERVICES DOCUMENTATION . 1-4
1.7 DEFINITIONS . 1-6
1.8 NOMENCLATURE . 1-7
1.9 CONVENTIONS . 1-8
1.10 REFERENCES . 1-12
2 OVERVIEW OF THE MONITORED DATA SERVICE . 2-1
2.1 SERVICE SUMMARY . 2-1
2.2 FUNCTIONAL DESCRIPTION . 2-2
2.3 SERVICE MANAGEMENT . 2-9
2.4 CROSS SUPPORT VIEW . 2-10
2.5 OPERATIONAL SCENARIO . 2-12
3 COMPOSITION OF THE MONITORED DATA CROSS
SUPPORT TRANSFER SERVICE . 3-1
3.1 OVERVIEW . 3-1
3.2 PROCEDURES OF THE MONITORED DATA CROSS
SUPPORT TRANSFER SERVICE . 3-1
3.3 MONITORED DATA CROSS SUPPORT TRANSFER
SERVICE STATE MACHINE . 3-3
4 ON-CHANGE-OPTION CYCLIC REPORT PROCEDURE . 4-1
4.1 DISCUSSION . 4-1
4.2 PROCEDURE TYPE IDENTIFIER . 4-2
4.3 EXTENSION . 4-2
4.4 BEHAVIOR . 4-2
4.5 REQUIRED OPERATIONS . 4-5
4.6 CONFIGURATION PARAMETERS . 4-6
4.7 PROCEDURE STATE TABLE . 4-6
CCSDS 922.1-B-1 Page vi April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
CONTENTS (continued)
Section Page
5 INFORMATION QUERY PROCEDURE . 5-1
5.1 DISCUSSION . 5-1
5.2 PROCEDURE TYPE IDENTIFIER . 5-1
5.3 REFINEMENT . 5-1
5.4 BEHAVIOR . 5-2
5.5 REQUIRED OPERATIONS . 5-3
5.6 CONFIGURATION PARAMETERS . 5-3
5.7 PROCEDURE STATE TABLE . 5-3
6 NOTIFICATION PROCEDURE . 6-1
6.1 DISCUSSION . 6-1
6.2 PROCEDURE TYPE IDENTIFIER . 6-1
6.3 REFINEMENT . 6-1
6.4 BEHAVIOR . 6-2
6.5 REQUIRED OPERATIONS . 6-3
6.6 CONFIGURATION PARAMETERS . 6-3
6.7 PROCEDURE STATE TABLE . 6-3
7 SETTING OF SERVICE MANAGEMENT AND CONFIGURATION
PARAMETERS INHERITED FROM FRAMEWORK OPERATIONS
AND PROCEDURES . 7-1
7.1 OVERVIEW . 7-1
7.2 responder-port-identifier SERVICE
MANAGEMENT PARAMETER . 7-1
7.3 ASSOCIATION CONTROL PROCEDURE CONFIGURATION
PARAMETERS . 7-1
7.4 ON-CHANGE-OPTION CYCLIC REPORT PROCEDURE
CONFIGURATION PARAMETERS . 7-2
7.5 NOTIFICATION PROCEDURE CONFIGURATION PARAMETERS . 7-2
7.6 INFORMATION QUERY PROCEDURE CONFIGURATION
PARAMETERS . 7-3
8 MONITORED DATA SERVICE-SPECIFIC VERSIONS OF
SERVICE-GENERIC PARAMETER AND EVENTS . 8-1
8.1 OVERVIEW . 8-1
8.2 mdSvcProductionStatus PARAMETER . 8-1
CCSDS 922.1-B-1 Page vii April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
CONTENTS (continued)
Section Page
8.3 mdSvcProductionStatusChange EVENT. 8-1
9 REFINEMENT OF DEFINITIONS OF FRAMEWORK PARAMETERS,
EVENTS, DIRECTIVES, AND DIAGNOSTIC VALUES USED BY THE
MONITORED DATA SERVICE . 9-1
9.1 OVERVIEW . 9-1
9.2 mdSvcProductionStatus PARAMETER
DEFINITION REFINEMENT . 9-1
9.3 mdSvcProductionStatusChange EVENT
DEFINITION REFINEMENT . 9-2
9.4 DIAGNOSTIC VALUE DEFINITION REFINEMENT . 9-2
ANNEX A IMPLEMENTATION CONFORMANCE STATEMENT
PROFORMA (NORMATIVE) . A-1
ANNEX B SERVICE OBJECT IDENTIFIERS MODULE (NORMATIVE) .B-1
ANNEX C PROCEDURE – ON-CHANGE-OPTION CYCLIC
REPORT PDUS (NORMATIVE) . C-1
ANNEX D MONITORED DATA PRODUCTION (NORMATIVE) . D-1
ANNEX E SECURITY, SANA, AND PATENT CONSIDERATIONS
(INFORMATIVE) .E-1
ANNEX F EXAMPLE FUNCTIONAL RESOURCE TYPE OBJECT
IDENTIFIER REGISTRY  (INFORMATIVE) . F-1
ANNEX G INFORMATIVE REFERENCES (INFORMATIVE) . G-1
ANNEX H ACRONYMS (INFORMATIVE) . H-1
ANNEX I CROSS REFERENCES TO CROSS SUPPORT TRANSFER
SERVICE SPECIFICATION FRAMEWORK (INFORMATIVE) . I-1
Figure
1-1 Cross Support Services Documentation . 1-4
2-1 Production and Provision of Monitored Data Services (Notional) . 2-3
2-2 Example of the Management and Provision of Monitored Data
Service Instances for a Service Package . 2-11
Table
3-1 Monitored Data Transfer Service Procedures . 3-3
4-1 On-Change-Option Cyclic Report Procedure Required Operations . 4-5
4-2 START Extension Parameter. 4-5
CCSDS 922.1-B-1 Page viii April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
CONTENTS (continued)
Tables Page
5-1 Information Query Procedure Required Operations . 5-3
6-1 Notification Procedure Required Operations . 6-3
A-1 Identification of PICS . A-3
A-2 Identification of Implementation under Test . A-4
A-3 Identification of Supplier . A-4
A-4 Identification of Specification . A-4
A-5 Required Procedures . A-5
A-6 Required PDUs . A-6
A-7 BIND Invocation Parameters . A-7
A-8 BIND Return Parameters . A-8
A-9 PEER-ABORT Invocation Parameters . A-9
A-10 UNBIND Invocation Parameters . A-9
A-11 UNBIND Return Parameters . A-10
A-12 GET Invocation Parameters . A-11
A-13 GET Return Parameters . A-12
A-14 START Invocation Parameters . A-13
A-15 START Return Parameters . A-15
A-16 STOP Invocation Parameters . A-16
A-17 STOP Return Parameters . A-17
A-18 NOTIFY Invocation Parameters . A-18
A-19 TRANSFER-DATA Invocation Parameters . A-19
F-1 Antenna Functional Resource Type Parameters . F-4
F-2 Forward 401 Space Link Carrier Transmission Functional Resource Type
Parameters . F-5
F-3 Forward CLTU TS Provider Functional Resource Type Parameters . F-7
F-4 Forward CLTU TS Provider Functional Resource Type Events . F-8
F-5 Return 401 Space Link Carrier Reception Functional Resource Type Parameters . F-9
F-6 Return TM Synchronization and Channel Decoding Functional Resource Type
Events . F-11
F-7 Return All Frames TS Provider Functional Resource Type Parameters . F-12
F-8 Return All Frames TS Provider Functional Resource Type Events . F-13
F-9 MD-CSTS Provider Functional Resource Type Parameters . F-13
F-10 MD-CSTS Provider Functional Resource Type Events . F-14
I-1 Cross Reference to Reference-[1] Sections and Paragraphs . I-1
CCSDS 922.1-B-1 Page ix April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
1 INTRODUCTION
1.1 PURPOSE OF THIS RECOMMENDED STANDARD
This Recommended Standard defines the Monitored Data Cross Support Transfer Service
(CSTS), in conformance with the Cross Support Transfer Services Specification Framework
Recommended Standard (reference [1]). The Monitored Data CSTS (MD-CSTS) is a service
that allows a spaceflight mission to receive cyclic reports on, and to query the current values
of, the parameters that are pertinent to Cross Support Services being provided by a Cross
Support Complex. The Monitored Data service also allows a spaceflight mission to receive
notifications of the occurrence of events of interest associated with the services that are being
provided by a Cross Support Complex.
NOTE – The term ‘Cross Support Complex’, as used throughout this document,
corresponds to the Earth Space Link Terminal (ESLT) defined in the Space
Communications Cross Support Architecture Description Document
(reference [G9]).
1.2 SCOPE
This Recommended Standard defines the Monitored Data service in terms of:
a) the CSTS procedures that constitute the service;
b) the extensions and refinements of the behavior of those CSTS procedures necessary
to provide the transfer service;
c) the extensions and refinements of standard CSTS operations associated with each of
the procedures;
d) the relationships among the procedures that constitute the service.
It does not specify:
a) individual implementations or products;
b) the implementation of entities or interfaces within real systems;
c) the methods or technologies required to measure the values of monitored parameters
and to detect the occurrence of events of interest;
d) the methods or technologies required for communication;
e) the management activities necessary to schedule, configure, and control the MD-
CSTS;
f) the specific parameters that are to be reported and events that are to be notified by the
MD-CSTS.
CCSDS 922.1-B-1 Page 1-1 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
1.3 APPLICABILITY
1.3.1 GENERAL
The applicability and limits of applicability of Cross Support Transfer Services in general, as
described in reference [1], pertain to the Monitored Data service, with the addition of the
conditions described in 1.3.2, below.
1.3.2 APPLICABILITY OF THIS RECOMMENDED STANDARD
This Recommended Standard is applicable to the implementation of real systems that
monitor provision and production of space communication Cross Support Services for the
purposes of generating cyclic status reports, generating notifications of changes in status in
real time, and responding to queries of current values of operational parameters.
1.4 RATIONALE
The goal of this Recommended Standard is to create a standard for interoperability for the
exchange of cross support service-related status information between the cross support
elements of various space Agencies and the users of the Cross Support Services that they
provide.
1.5 DOCUMENT ORGANIZATION
Section 2 describes the Monitored Data Cross Support Transfer Service in terms of:
– the role of Service Management with respect to the MD-CSTS;
– the allocation of production and provision of the MD-CSTS to Functional Resources;
– the cross support view of the MD-CSTS;
– the functional description of the production and provision of the service; and
– an operational scenario that illustrates some of the more significant aspects of the
service.
Section 3 specifies the composition of the MD-CSTS. The service type identifier is declared,
the procedures that constitute the service are identified, and the CSTS state machine that
applies to the MD-CSTS is specified. Because the MD-CSTS is composed of procedures that
are directly adopted from the CSTS Framework without extension, no further specification of
the MD-CSTS is required.
Section 4 specifies the On-Change-Option Cyclic Report procedure, which is an extension
and refinement of the Framework Cyclic Report Procedure.
Section 5 specifies the refinements of the Information Query procedure.
CCSDS 922.1-B-1 Page 1-2 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
Section 6 specifies the refinements of the Notification procedure.
Section 7 specifies how the procedure configuration parameters are to be set for the MD-
CSTS.
Section 8 specifies the Monitored Data Service-specific versions of the service-generic
parameter and events that are defined in Cross Support Transfer Service—Specification
Framework (reference [1]).
Section 9 specifies the refinements of the definitions of Framework parameters, events, and
directives for the purposes of making them applicable to the MD-CSTS.
Annex A is the Implementation Conformance Statement Proforma for the MD-CSTS.
Annex B provides the formal specification of the ASN.1 Object Identifiers module for the
Monitored Data transfer service.
Annex C provides the formal specification of the ASN.1 Protocol Data Unit module for the
On-Change-Option Cyclic Report procedure of the Monitored Data transfer service.
Annex D defines the monitored data production process. In particular, it specifies how
monitored data values are to be labeled so that, when transferred by MD-CSTS instances, the
sources of the measurements are unambiguous.
Annex E addresses the security, Space Assigned Numbers Authority (SANA), and patent
considerations associated with the MD-CSTS.
Annex F describes an example set of monitored parameters, notifiable events, and their
associated Functional Resource Types. These examples are modeled on the contents of the
SANA Functional Resource Registry (reference [3]).
NOTE – The SANA Functional Resource Registry is the normative repository of all such
definitions. The example entries in annex F are included to illustrate the concepts
of the use of Functional Resources by the MD service. Any real implementation
of the MD service must use the Functional Resource specifications found in the
SANA Functional Resource Registry.
Annex G provides the list of informative references.
Annex H lists the acronyms used in this document.
Annex I identifies the specific reference-[1] sections that are cross referenced by the MD-
CSTS Recommended Standard, and the sections of the MD-CSTS Recommended Standard
that reference each of those sections or subsections in reference [1]. This annex is included
for maintainability of this Recommended Standard through future changes in reference [1].
CCSDS 922.1-B-1 Page 1-3 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
1.6 CROSS SUPPORT TRANSFER SERVICES DOCUMENTATION
The basic organization of the Cross Support Services documentation and the relationship to
the CSTS documentation is shown in figure 1-1.
Cross Support Services
Space
Cross Support
Cross Support Concept Communication Cross
Reference Model
Part 1: SLE Services Support Service
Part 1: SLE Services
Management
Cross Support Transfer Services
Cross Support Transfer
Service Specification
Cross Support Transfer
Framework Concept
Service Specification Suite
Cross Support Transfer
Service Specification
SLE Transfer Services
Framework
SLE Transfer Service
Guidelines for Specification
Specification Suite
of Cross Support Transfer
Services
SLE Internet Protocol for
Transfer Services
Key:
Recommended Practice (Magenta)
Recommended Standard (Blue)
Report (Green)
Figure 1-1: Cross Support Services Documentation
The CSTS Documentation is:
a) Cross Support Concept—Part 1: Space Link Extension Services (reference [G1]): a
Report introducing the concepts of cross support and the Space Link Extension (SLE)
services. Many of the concepts for the SLE transfer services have been adopted for
the CSTSes (see h) below);
b) Cross Support Reference Model—Part 1: Space Link Extension Services
(reference [2]): a Recommended Standard that defines the framework and
CCSDS 922.1-B-1 Page 1-4 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
terminology for the specification of SLE services. Much of the framework and
terminology of this reference model has been adopted or adapted for CSTSes (see
1.7.2 and 2.2).
c) Space Communication Cross Support Service Management suite (informative
references [G6], [G7], and [G8]): Recommended Standards that specify the Service
Management Information Entities that are used to configure and schedule CSTSes;
d) The SLE Transfer Services suite: The SLE Transfer Services comprise a set of Cross
Support Transfer Services that are used to transfer specific telecommand and
telemetry protocol data units. The SLE Transfer Services are closely related to the
CSTS suite in that they collectively define the set of operations that are the basis for
the CSTS Specification Framework. However, because of history (the SLE Transfer
Services were already specified and implemented prior to development of the CSTS
Framework) the SLE Transfer Services are separated from CSTSes;
e) Space Link Extension - Internet Protocol for Transfer Services (reference [G2]): a
Recommended Standard that defines a protocol for transfer of Protocol Data Units
(PDUs) defined in the Cross Support Transfer Services. This Recommended Standard
was originally developed to support SLE transfer services (hence the title), but it is
also applicable to (and specified for) use by Cross Support Transfer Services.
The documents specific to Cross Support Transfer Services are:
f) Cross Support Transfer Services Specification Framework (reference [1]): a
Recommended Standard that defines basic building blocks for the specification of
Cross Support Transfer Service procedures;
g) Guideline for Specification of Cross-Support Transfer Services: a Recommended
Practice that, when published, will define the guidelines for construction of a Cross
Support Transfer Service based on the CSTS Specification Framework;
NOTE – As of the publication of this Recommended Standard, the Guidelines
Magenta Book is in-progress. It is not required to understand this
Recommended Standard.
h) Cross Support Transfer Services Specification Framework Concepts (reference [G3]):
A Report that provides tutorial material on the objectives and concepts of the CSTS
Specification Framework;
i) Cross Support Transfer Services Suite: The set of specifications for actual CSTSes
built from the procedures in the CSTS Specification Framework and in accordance
with the CSTS Guidelines.
CCSDS 922.1-B-1 Page 1-5 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
1.7 DEFINITIONS
1.7.1 TERMS DEFINED IN THE CROSS SUPPORT TRANSFER SERVICES
SPECIFICATION FRAMEWORK RECOMMENDED STANDARD
(REFERENCE [1])
a) Association Control procedure;
b) Buffered Data Delivery procedure;
c) complete data delivery mode;
d) Cross Support Complex;
e) Cross Support Service production;
f) Cross Support Transfer Service;
g) Event Identifier;
h) Event Label;
i) Event Name;
j) Functional Resource instance;
k) Functional Resource Instance Number;
l) Functional Resource Name;
m) Functional Resource Type;
n) Label List;
o) Label List Set;
p) non-blocking (operation);
q) Parameter Identifier;
r) Parameter Label;
s) Parameter Name;
t) prime procedure instance;
u) procedure configuration parameter;
v) procedure type;
w) procedure instance identifier;
x) Published Identifier;
y) qualified parameter;
CCSDS 922.1-B-1 Page 1-6 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
z) secondary procedure instance;
aa) service management parameter;
bb) service-user-responding-timer;
cc) subscription.
1.7.2 TERMS DEFINED IN THE CROSS SUPPORT REFERENCE MODEL
(REFERENCE [2])
a) Complex Management (CM) (called SLE Complex Management in reference [2]);
b) Mission User Entity (MUE);
c) service agreement (called SLE Service Agreement in reference [2]);
d) service package (called SLE Service Package in reference [2]);
e) space link session;
f) transfer service production;
g) transfer service provision;
h) Utilization Management (UM);
i) utilization phase (called SLE Service Package Utilization phase in reference [2]).
1.8 NOMENCLATURE
1.8.1 NORMATIVE TEXT
The following conventions apply for the normative specifications in this Recommended
Standard:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
NOTE – These conventions do not imply constraints on diction in text that is clearly
informative in nature.
CCSDS 922.1-B-1 Page 1-7 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
1.8.2 INFORMATIVE TEXT
In the normative sections of this document, informative text is set off from the normative
specifications either in notes or under one of the following subsection headings:
– Overview;
– Background;
– Rationale;
– Discussion.
1.9 CONVENTIONS
1.9.1 OVERVIEW
The conventions defined in the CSTS Specification Framework Recommended Standard
(reference [1]) are applicable to this Monitored Data service specification, with the exception
of the representation of Object Identifiers. The conventions for the representation of Object
Identifiers in this Recommended Standard are described in 1.9.2.
1.9.2 OBJECT IDENTIFIER REPRESENTATION
1.9.2.1 General
The MD service involves extensive use of Functional Resource Types, procedure types,
Functional Resource Names, procedure instance identifiers, Parameter Names, Parameter
Identifiers, Event Names, and Event Labels. As specified in reference [1], all of these names
are based on Published Identifiers, which are International Organization for Standardization
(ISO) Object Identifiers (OIDs). OIDs have the syntax of strings of integers. For purposes of
readability, rather than using actual OIDs in the descriptions and examples in this
Recommended Standard, the OIDs in these names and identifiers are represented using the
following textual notation to represent the OIDs.
1.9.2.2 Functional Resource Type
As specified in reference [1], a Functional Resource Type is a Published Identifier (i.e., an
ISO OID). In the descriptions and examples in this Recommended Standard, a Functional
Resource Type is represented using the notation {published identifier descriptor}, which is a
textual description of the Published Identifier. Thus {Antenna} represents the Published
Identifier for the Antenna Functional Resource Type.
CCSDS 922.1-B-1 Page 1-8 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
1.9.2.3 Procedure Type
As specified in reference [1], a procedure type is an ISO OID that is assigned to a CSTS
procedure. In the descriptions and examples in this Recommended Standard, a procedure
type is represented using the notation {object identifier descriptor}, which is a textual
description of the Object Identifier. Thus {Cyclic Report} represents the Object Identifier for
the Cyclic Report procedure type.
1.9.2.4 Functional Resource Name
As specified in reference [1], a Functional Resource Name is composed of a Functional
Resource Type Published Identifier and an integer Functional Resource Instance Number
(FRIN). In the descriptions and examples in this Recommended Standard, a Functional
Resource Name is represented using the notation [{functional resource type published
identifier descriptor}: FRIN]. [{Antenna}: 1] represents the name of the Antenna Functional
Resource Type that is assigned FRIN = 1 in the scheduled service package.
1.9.2.5 Procedure Instance Identifier
As specified in reference [1], a procedure instance identifier identifies the specific instance of
a procedure in a CSTS. It is composed of a procedure type Published Identifier and a
procedure role, which can have one of three values: ‘association control’ if it is the
Association Control procedure of the CSTS; ‘prime procedure instance’ if it is the prime
instance of the procedure of the CSTS; or a positive integer Secondary Procedure Instance
Number (SPIN) if it is a secondary procedure instance of the CSTS.
In the descriptions and examples in this Recommended Standard, a procedure instance
identifier for an Association Control procedure is represented using the notation [{procedure
type object identifier descriptor}: ‘association control’]. [{Association Control}:
‘association control’] represents the Procedure Instance Identifier of the Association Control
instance of a CSTS.
NOTE – In the case of the Framework Association Control procedure, the Procedure Role
appears to be redundant with the procedure type. However, it is possible for a
CSTS to extend the Association Control procedure, in which case it would get a
separate procedure type, in which case the Procedure Role explicitly identifies
the OID as that belonging to an Association Control procedure.
A procedure instance identifier for a prime procedure instance is represented using the
notation [{procedure type object identifier descriptor}: ‘prime procedure instance’].
[{Cyclic Report}: ‘prime procedure instance’] represents the procedure instance identifier of
the Cyclic Report instance that serves as the prime procedure instance of a CSTS.
A procedure instance identifier for a secondary procedure instance is represented using the
notation [{procedure type object identifier descriptor}: SPIN]. [{Notification}: 1] represents
CCSDS 922.1-B-1 Page 1-9 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
the procedure instance identifier of the Notification instance that serves as the first
Notification secondary procedure instance of a CSTS.
1.9.2.6 Parameter Name
As specified in reference [1], a Parameter Name can be either the name of a Functional
Resource parameter or the name of a CSTS procedure parameter. A Functional Resource
Parameter Name is composed of (1) the Functional Resource Name of the Functional
Resource instance that reports the parameter, and (2) the Parameter Identifier for the
parameter. In the descriptions and examples in this Recommended Standard, a Parameter
Name is represented using the notation [[{functional resource type published identifier
descriptor}: FRIN]: {parameter published identifier descriptor}]. Thus [[{Antenna}: 1]:
{actualAzimuth}] represents the actual-azimuth parameter of the Antenna
Functional Resource Type that is assigned FRIN = 1 in the scheduled service package.
A CSTS procedure Parameter Name is composed of (1) the procedure instance identifier of
the procedure instance that reports the parameter, and (2) the Parameter Identifier for the
parameter. In the descriptions and examples in this Recommended Standard, a CSTS
Parameter Name is represented using the notation [[{procedure type object identifier
descriptor}: ‘association control’ | ‘prime procedure instance’ | SPIN]: {parameter
published identifier descriptor}]. Thus [[{Cyclic Report}: ‘prime procedure instance’]:
{pCRnamedLabelLists}] represents the named-label-lists parameter of the
prime instance of the Cyclic Report procedure of the CSTS.
1.9.2.7 Event Name
As specified in reference [1], an Event Name can be either the name of a Functional
Resource event or the name of a CSTS procedure event. A Functional Resource Event Name
is composed of (1) the Functional Resource Name of the Functional Resource instance that
reports the event, and (2) the Event Identifier for the event. In the descriptions and examples
in this Recommended Standard, an Event Name is represented using the notation
[[{functional resource type published identifier descriptor}: FRIN]: {event published
identifier descriptor}].
NOTE – As of the publication of this Recommended Standard, there are no procedure
events for the three procedures used in the Monitored Data service (Cyclic
Report, Information Query, and Notification).
1.9.2.8 Parameter Label
As specified in reference [1], a Parameter Label is composed of (1) the Functional Resource
Type that reports the parameter and (2) the Parameter Identifier for the parameter. In the
descriptions and examples in this Recommended Standard, a Parameter Label is represented
using the notation [{functional resource type published identifier descriptor}: {parameter
CCSDS 922.1-B-1 Page 1-10 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
published identifier descriptor}]. Thus [{Antenna}: {actualAzimuth}] represents the
actual-azimuth parameter of the Antenna Functional Resource Type.
1.9.2.9 Event Label
As specified in reference [1], an Event Label is composed of (1) the Functional Resource
Type that reports the parameter and (2) the Event Identifier for the event. In the descriptions
and examples in this Recommended Standard, an Event Label is represented using the
notation [{functional resource type published identifier descriptor}: {event published
identifier descriptor}].
1.9.2.10 Label List
As specified in reference [1], a Label List is a data structure that specifies the name of a list
of Parameter Labels or Events Labels, indicates if the list is the default list, and contains all
Parameter Labels or Event Labels represented by that Label List name. In the descriptions
and examples in this Recommended Standard, a Label List is represented using the notation:
{ labelListName;
defaultFlag;
;
.
.
.

}
where is as described in 1.9.2.8 or 1.9.2.9.
1.9.2.11 Label List Set
As specified in reference [1], a Label List Set is the set of Label Lists accessible by the user
of the given service instance. In the descriptions and examples in this Recommended
Standard, a Label List Set is represented using the notation:
{ ;
.
.
.

}
where is as described in 1.9.2.10.
CCSDS 922.1-B-1 Page 1-11 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
1.10 REFERENCES
[1] Cross Support Transfer Service—Specification Framework. Issue 1. Recommendation
for Space Data System Standards (Blue Book), CCSDS 921.1-B-1. Washington, D.C.:
CCSDS, April 2017.
[2] Cross Support Reference Model—Part 1: Space Link Extension Services. Issue 2.
Recommendation for Space Data System Standards (Blue Book), CCSDS 910.4-B-2.
Washington, D.C.: CCSDS, October 2005.
[3] “Functional Resources.” Space Assigned Numbers Authority.
http://sanaregistry.org/r/functional_resources/.
CCSDS 922.1-B-1 Page 1-12 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
2 OVERVIEW OF THE MONITORED DATA SERVICE
2.1 SERVICE SUMMARY
The Monitored Data CSTS is a CCSDS Cross Support Transfer Service that during the MD-
CSTS service instance provision period provides a user with the capability to:
a) obtain cyclic or on-change reports of the values of monitored parameters of interest;
b) obtain notification of the occurrence of events of interest;
c) query the current values of monitored parameters of interest.
An instance of the Monitored Data service progresses through the following activities:
a) the user binds to the provider to establish a service association;
b) the user selects which monitored parameters are to be reported on-change or
cyclically and at which reporting periods, and starts (enables) the reporting of those
parameters;
c) the user selects which events are to be notified and enables the transmission of those
event notifications (optional);
d) the service provider reports the selected monitored parameter values when they
change or at the specified periodicity;
e) the service provider transmits the selected notifications upon occurrence of their
associated events (if optional event notification (item c), above) has been invoked by
the user),
f) the user queries the current values of monitored parameters (optional);
g) the user stops (disables) periodic reporting and event notification (if optional event
notification has been invoked); and
h) the user unbinds from the provider to release the association.
The Monitored Data service delivers only current parameter values: there is no capability in
this service to deliver parameter values stored from previous times.
CCSDS 922.1-B-1 Page 2-1 April 2017
CROSS SUPPORT TRANSFER SERVICES—MONITORED DATA SERVICE
2.2 FUNCTIONAL DESCRIPTION
2.2.1 GENERAL
As defined in the Cross Support Reference Model: Part 1 (reference [2]), related Cross
Support Services are bundled into service packages for the purposes of ensuring that the
required relationships among those Cross Support Services are preserved during their
production and provision. For example, multiple Cross Support Transfer Services may be
related to the operation of the same radio frequency (RF) link, and the return RF link may be
related to the forward RF link; all of those transfer services, as well as the RF links
themselves, constitute a single service package for the purposes of scheduling. The content
and structure of service packages that are compatible with the MD-CSTS will be defined in a
future Service Management Recommended Standard (reference [G6]).
A service package may contain multiple instances of the Monitored Data service. Each
instance of the Monitored Data service in a service package is capable of reporting all
monitored parameters and event notifications for that service package. The example service
package used in this section is comprising a forward RF link, two return RF links, multiple
SLE transfer service instances, and an instance of the Monitored Data service. The
Monitored Data service instance has access to the monitored parameters and event
notifications for those RF links and SLE transfer service instances (in addition to the
Monitored Data service instance’s own monitored parameters and event notifications).
In accordance with reference [2], the functionality associated with a transfer service is
partitioned into pro
...