Space engineering

Communications

Foreword

This Standard is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the purpose of developing and maintaining common standards. Requirements in this Standard are defined in terms of what shall be accomplished, rather than in terms of how to organize and perform the necessary work. This allows existing organizational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards.

This Standard has been prepared by the ECSS-E-50 Working Group, reviewed by the ECSS Executive Secretariat and approved by the ECSS Technical Authority.

Disclaimer

ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error-free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this Standard, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.

Published by:     ESA Requirements and Standards Division
    ESTEC, ,
    2200 AG Noordwijk
    The
Copyright:     2008 © by the European Space Agency for the members of ECSS

Change log

ECSS-E-50 Part 1A20 October 2003

and

ECSS-E-50 Part 2A4 July 2005

First issues

ECSS-E-ST-50B

Never issued

ECSS-E-ST-50C

31 July 2008

ECSS-E-50 was published originally in two parts: Part 1 “Principles and requirements”, and Part 2 “Documents requirement definitions”. The current version is the compilation of both parts in a single document. changes between the present version, and E-50 Part 1A and E-50 Part 2A include:

Inclusion of an “Introduction” section to present ECSS-E-HB-50A.

Updating of “Normative references” and "Bibliography".

Clause 3.1 in ECSS-E-50 Part 1 B has been split in Clauses 3.1.and 3.2.

Introduction of cross references from the requirements to the corresponding DRDs, and the updating of the back references from the DRDs to the corresponding requirements.

Requirement 5.3.2 has been reworded and its title changed accordingly.

The following statement have been reworded as descriptive: 5.6.1.1, clause 1 and 2 (formerly 5.6.15.1 and 5.6.15.2), 5.6.1.2 (formerly 5.6.14.5), NOTE to 5.6.8 (formerly 5.6.9.a), NOTE to 5.6.11.11 (formerly 5.6.13.11.b), NOTE 1 to 5.6.12.2 (formerly 5.6.14.2.c), and NOTE 2 to 5.6.12.2 (formerly 5.6.14.2.a).

The following recommendations have been transformed into requirements: 5.4.4 c (formerly 5.4.4.c), 5.4.4 d(formerly 5.4.4.d), 5.5.1 (formerly 5.5.1), 5.5.2 c (formerly 5.5.2.c), 5.5.2 d (formerly 5.5.2.d), 5.6.13.4 a (formerly 5.6.16.4.a), 5.6.13.4 c (formerly 5.6.16.4.c), 5.6.14.5 (formerly 5.6.17.6), 5.6.14.8 (formerly 5.6.17.10) and 5.7.1.2 (formerly 5.7.1.2).

The following statements in ECSS-E-50 Part 1A have been deleted: 5.6.12, 5.6.17.1, 5.6.17.9, 5.7.1.5 and 5.8.6.b.

Summary of DRDs (Annex A of ECSS-E-50 Part 2A) is now the last Annex (Annex I).

Statements not strictly limited to the content of the CSADD DRD (F.2.2 <2>.b in ECSS-E-50 Part 2A) has been moved to "Special remarks" (now E.2.2)

Statements not strictly limited to the content of the CSDDD DRD (G.2.2 <4>.b in ECSS-E-50 Part 2A) has been moved to "Special remarks" (now F.2.2)

Other minor editorial details and typo correction.

Introduction

This standard specifies requirements for the development of the end-to-end data communication system for spacecraft. Implementation aspects are defined in both ECSS-E-ST-50 Level 3 standards and CCSDS standards.

The complete set of standards to define a complete communication link is project dependent and cannot be specified here. ECSS-E-HB-50 provides some guidance on this aspect, and gives some practical examples.

Scope

This Standard specifies the requirements for the development of the endtoend data communications system for spacecraft.

Specifically, this standard specifies:

The terminology to be used for space communication systems engineering.

The activities to be performed as part of the space communication system engineering process, in accordance with the ECSS-E-ST-10 standard.

Specific requirements on space communication systems in respect of functionality and performance.

The communications links covered by this Standard are the spacetoground and spacetospace links used during spacecraft operations, and the communications links to the spacecraft used during the assembly, integration and test, and operational phases.

Spacecraft endtoend communication systems comprise components in three distinct domains, namely the ground network, the space link, and the space network. This Standard covers the components of the space link and space network in detail. However, this Standard only covers those aspects of the ground network that are necessary for the provision of the endtoend communication services.

Other aspects of the ground network are covered in ECSS-EST70.

This Standard may be tailored for the specific characteristics and constraints of a space project in conformance with ECSS-SST00.

Normative references

The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references, subsequent amendments to, or revisions of any of these publications, do not apply. However, parties to agreements based on this ECSS Standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references the latest edition of the publication referred to applies.

ECSS-S-ST-00-01

ECSS system — Glossary of terms

Terms, definitions and abbreviated terms

Terms defined in other standards

For the purpose of this Standard, the terms and definitions from ECSSSST0001 apply, in particular for the following term:

function

Terms specific to the present standard

channel
combination of protocol and medium that provides a physical layer service from endtoend

This is the transfer of the unstructured bitstream from pointtopoint.

communication service
service that provides the capability of moving data between users.

At least two users are involved when a communication service is used, one sending data and the other(s) receiving data.

cross support
use by one party of part of another party’s data system resources to complement its own system

entity
active element within a system

interface
description of the connection between real or abstract objects

isochronous service
service providing for the transfer of data with a defined maximum deviation from a nominal delay from end to end

protocol
set of rules and formats (semantic and syntactic) that determine the communication behaviour of layer entities in the performance of communication functions

service
capability of a layer, and the layers beneath it (a serviceprovider), that is provided to serviceusers at the boundary between the serviceprovider and the serviceusers

The service defines the external behaviour of the serviceprovider, independent of the mechanisms used to provide that behaviour. Layers, layer entities, and applicationserviceelements are examples of components of a serviceprovider.

service data unit
amount of information whose identity is preserved when transferred between peer entities in a given layer and which is not interpreted by the supporting entities in that layer

serviceprovider
abstract representation of the totality of those entities which provide a service to serviceusers

A service provider includes entities in the layer at which the service is provided, and in the layers beneath it.

serviceuser
entity in a single system that makes use of a service

The serviceuser makes use of the service through a collection of service primitives defined for the service.

simplex
communicating in one direction from data source to data sink

source
entity that sends servicedataunits, using a service provider

sink
entity that receives servicedataunits from a service provider

telecommand
communication link from ground to space by which a spacecraft is commanded

telemetry
housekeeping data and payload data

Housekeeping telemetry is usually transmitted at low rate, but payload data can be transmitted at a very high rate.

telemetry link
link from spacecraft to ground over which data generated on the spacecraft is provided to ground

user
serviceuser

user application
application that makes use of data handling system services

An application can be a software entity or a nonsoftware entity which is controlling an onboard system.

Abbreviated terms

For the purpose of this Standard, the abbreviated terms from ECSSST0001 and the following apply:

Abbreviation	Meaning
AIT	assembly, integration, and test
AR	acceptance review
ARQ	automatic repeat request
BER	bit error rate
CCITT	Consultative Committee for International Telegraph and Telephone
CCSDS	Consultative Committee for Space Data Systems
CDMU	central data management unit
CDR	critical design review
CSAD	communication system analysis document
CSADD	communication system architectural design document
CSBD	communication system baseline definition
CSDDD	communication system detailed design document
CSOM	communication system operations manual
CSPD	communication system profile document
CSRD	communication system requirements document
CSVP	communication system verification plan
DRD	document requirements definitions
EIRP	equivalent isotropically radiated power
EMC	electromagnetic compatibility
ISO	International Organization for Standardization
ITU	International Telecommunication
ITU-R	ITU – Radiocommunication
ITU-RR	ITU – Radio Regulations
LEOP	launch and early operations phase
MEC	mission experiment centre
OSI	open system interconnection
OCC	operational control centre
PDR	preliminary design review
PFD	power flux density
QR	qualification review
RF	radio frequency
SDU	service data unit
SRR	system requirements review
TT&C	telemetry, tracking and command

Space communications engineering principles

Context

Space communications engineering is concerned with the provision of endtoend communication services to and from spacecraft. Communication links are generally between the spacecraft and ground. However, this Standard also addresses spacecrafttospacecraft links, e.g. in spacecraft constellations, and can be applied to links between spacecraft and landed elements such as orbiterlander or orbiterlanderrover configurations.

Endtoend communication is used both to control the operation of the spacecraft, and to transfer data, such as payload data. However, the requirements on the communications system for controlling the spacecraft differ from those for payload data transfer. For control operations, the communication system objective is to provide guaranteed delivery of commands in the order of transmission. Commands can be repeated, but not lost. By contrast, the requirement for payload data transfers is to transfer as much data as possible. Some loss of data may be acceptable, and delivery order is generally unimportant, provided the data can be reconstituted.

In addition to the endtoend transfer of commands and data, some additional services are provided across space communication links, such as time correlation and ranging. Time correlation is used to accurately relate the local time maintained at each end of the communication link in order to determine the absolute time relationship between events. Ranging is used to determine the distance to the spacecraft, e.g. between a ground station antenna and the spacecraft, or between two spacecraft, and is used for orbit determination.

The goals of standardization for space communication systems are:

to ensure efficient use of the RF spectrum allocated to the space infrastructure in a noninterfering manner;

to ensure that the RF links to and from the spacecraft can be used for orbit determination and ranging;

to ensure reliable and error free endtoend communication between ground stations and the spacecraft;

to enable the use of the same ground segment infrastructure by different spacecraft;

to ensure that standard communication interfaces are provided to the spacecraft payloads and experiments in order to simplify the spacecraft development process;

to enable cross support between agencies.

Cross support can be beneficial for many reasons, including:

Technical: to attain additional network coverage or to conduct some programmatic endeavour, such as very long baseline interferometry measurements.

Economic: to avoid the expense of duplicate implementation, especially to meet some short term requirement.

Emergency: to increase mission support over that normally planned.

Research: to avoid the cost and time delay of repeating investigations or reflying an experiment and to obtain unique data acquired in the past and held by another agency.

These arguments were apparent as long ago as the early 1970s. For this reason, the Consultative Committee for Space Data Systems (CCSDS) was established to standardize space link protocols. Where appropriate, this ECSS Standard calls up CCSDS recommendations directly.

Space communication engineering involves many different disciplines. The physical layers of wireless communications links are the preserve of RF or optical specialists, and wired links are the speciality of analogue electronics engineers. The electronic components that implement the communication services are designed and implemented by analogue and digital electronics engineers, and the design of the protocols used in the provision of services is entrusted to protocol experts. In many cases, the higher level services and protocols are implemented in software by specialized software engineers. Other ECSS Standards which are applicable to this discipline are called up within this Standard.

Overall space communication

Figure 41 shows an example of a configuration for a space communication system.

This configuration includes a spacetospace link between two flight elements.

Figure 41: Example configuration of a space communication system

The overall data communication requirement is to transfer data to and from any element of the space system in accordance with the mission requirements.

The elements of a space communication system are described in the following paragraphs. In a real space communication system, the number and type of elements actually present can vary. For example, in complex missions, there can be several spacecraft, and multiple ground stations. In other missions, a single spacecraft can be controlled from a single operation control centre, without a mission experiment centre.

The space communication system elements are:

a spacecraft linked to the ground via a space link (spacetoground). This can also be linked to other spacecraft, landers, and probes via spacetospace (proximity) links;

other spacecraft, landers, and probes linked only with the main spacecraft via proximity links;

a ground station that forms the terrestrial end of the spacetoground space link, and is connected to the operational control centre via a terrestrial link;

an operational control centre (OCC), connected to the ground station via a terrestrial link. The OCC is used to control the spacecraft;

a dedicated mission experiment centre (MEC) connected to the operations control centre. payloads and experiments are operated from the MEC.

Each element includes a data handling system, which provides three main communication functions:

managing data communication interfaces internal to the element (internal links);

managing data communication interfaces with external links (i.e. space links and terrestrial links to other elements);

performing data processing for the transfer between internal and external links.

The data handling for transferring data from a sending element to a receiving element of the space communication system via an external link consists of:

For the downlink data stream:

At sender side

Acquisition of data from subsystems.

Processing and formatting of the data stream for transmission to the ground via the external link as telemetry.

Forwarding of the data stream via the external link.

At receiver side

Acquisition of the data stream from the sender via the external link.

Deformatting and processing for delivery to receiver internal elements (e.g. space system user for a link between ground station and OCC) and for transfer to the next element via an external link (e.g. transfer from ground station to OCC).

Delivery of data to receiver internal elements (e.g. space system user).

For the uplink data stream:

At sender side

Acquisition of data from space system user.

Processing and formatting of the data stream for transmission to the spacecraft via the external link as telecommand.

Forwarding of the data stream via the external link.

At receiver side

Acquisition of the data stream from the sender via the external link.

Deformatting and processing for delivery to receiver internal elements (e.g. spacecraft subsystems for a link between ground station and spacecraft) and for transfer to the next element via an external link.

Delivery of data to receiver internal elements (e.g. commands to spacecraft subsystems).

The type of data to be transmitted can be telemetry, files, video, and digital voice for the downlink, and telecommands, files, video, and digital voice for the uplink.

For each type of data transmission, protocols defined by CCSDS or other standardization bodies may be used. Figure 42 shows some of the CCSDS and internet protocols that can be used over the spacetoground space link. This figure illustrates five of the seven ISO reference model layers defined in ISO 7498 (the session and presentation are not shown).

Figure 42: CCSDS and Internet space link protocols

Space communication domains

Overview

A space communication system comprises three distinct domains that each have markedly different characteristics. The three domains are

the space network,

the space link, and

the ground network.

These domains are illustrated in Figure 43.

Space network

The space network comprises all of the nodes in the flight segment of a spacecraft mission. These nodes can all be on a single spacecraft, or can be distributed among several spacecraft, for example in a constellation. The space network therefore includes both intraspacecraft and interspacecraft links.

The type of network medium and topologies of the space network are highly varied, often being based on proprietary protocols. The emphasis of this Standard in this case is on the definition of appropriate user and transfer layer services that maintain freedom of choice in the subnetwork layers, while also moving towards harmonization and better definition of the subnet layers.

Except in very rare circumstances, the space network cannot be maintained or upgraded during a mission. Usually, the technology used to implement the space network is conservative, and reflects the stateoftheart years before launch. This severely constrains the performance available when compared with the ground network.

An increasing number of missions involve a space segment consisting of more than one element, e.g. constellations of spacecraft, or planetary missions consisting of an orbiter and lander, or orbiterlanderrover. This Standard regards all of these elements as comprising the space network. These missions change the nature of the space network by including inherently unreliable wireless links and introducing the potential for a variable network topology.

Space link

The space link is essentially a pointtopoint wireless link between a ground station and a spacecraft. This link is inherently unreliable, and the emphasis of this Standard here is on the achievement of reliable data transfer services. Users concerned only with the exchange of data, either onboard or on ground, do not generally use the space link services directly, accessing these services instead through their local ground or onboard subnets. However, users concerned with the operation and control of the spacecraft can access space link services for a number of reasons, including routine operations such as ranging, orbital position determination, and emergency operations such as low level commanding.

Equipment at the terrestrial end of the space link is essentially unconstrained in terms of power, mass, and volume requirements. By contrast, equipment at the onboard end of the space link is severely constrained in these respects. This limits the bandwidth that can be achieved, especially in the return (spacetoground) direction.

The medium through which the space link signal propagates can interfere with or distort the signal, and the very high relative velocity of some spacecraft introduces severe Doppler effects. The movement of the spacecraft relative to its ground station makes the signal propagation path characteristics highly variable. The combination of these factors imposes on the space link to be capable of operating reliably over a very wide range of conditions, and to tolerate very high bit error rates (BER).

For bidirectional communications, the space link comprises at least two physical channels, one for forward (groundtospace) and one for return (spacetoground) communications. However, one constraint exists to achieve at least limited communications for emergency control of the spacecraft, with only a unidirectional link, i.e. with only the forward or return link operational. This again imposes severe requirements on the space link protocols and services.

Ground network

The ground network comprises groundbased equipment and terrestrial links that implement the ground data handling system. The ground network is largely described by ECSS-E-ST-70.

The ground network comprises the ground data processing equipment, usually connected by a combination of local and wide area networks. Communication between nodes is achieved using a variety of reliable terrestrial links with welldefined protocols. The emphasis of this Standard in the ground network is on the transfer and user layer services and protocols used to transfer spacecraft data between nodes in the ground network and nodes in the space network.

This Standard is not concerned with ground based services and protocols used to transfer data between communication end points on the ground, or with services related to archiving and retrieval of spacecraft data.

An important aspect of the ground network is that it can be maintained and upgraded to take advantage of technological developments occurring during the lifetime of a mission. Furthermore, the performance of the ground network can be enhanced by improving the terminal equipment and by increasing the number or performance of the links in the subnet.

Communications engineering process

Introduction

Space communications engineering is carried out following the systems engineering process model defined in ECSS-E-ST-10 and ECSS-E-HB-10. This model includes the establishment of an appropriate engineering management and configuration control infrastructure, and the identification of interfaces with other engineering disciplines. The communication system engineering is then carried out as a sequence of activities managed within this infrastructure.

Communication engineering activities

Overview

Spacecraft communications engineering comprises the following activities:

communications engineering management,

requirement engineering,

analysis,

design and configuration,

implementation,

verification, and

operations.

Communications engineering management

Space communications engineering management systems and procedures are put in place to administer the activities that are performed in the implementation and operation of the space communication system. Management includes the planning, scheduling, and supervision of the activities to be performed, as well as configuration control and quality assurance of all of the products of space communications engineering.

Communications engineering management is a continuous activity that extends throughout the project.

Requirement engineering

The requirement engineering phase of space communication systems engineering involves the capture of requirements specific to the space communications system.

Communication requirements are derived from the spacecraft mission requirements and by tailoring the requirements in this Standard.

The goals and activities to be performed during the requirement engineering phase are described in ECSS-E-ST-10 and ECSS-E-HB-10.

Analysis

The analysis phase of the space communications engineering process is concerned with the analysis of the requirements and the identification of appropriate ways of implementing the communication system. The analysis takes into account the performances to meet the mission objectives, mission characteristics such as satellite orbit parameters, capabilities of available technologies, and the availability of existing ground infrastructure.

The output from the analysis phase is a recommended means of implementing the space communication system, with options if necessary, which is elaborated during the design and configuration phase.

The analysis identifies the frequencies to be used for RF communications so that an application can be made to the International Telecommunication Union – Radiocommunication (ITUR) for assignment of those frequencies.

The activities of the analysis phase are described in more detail in ECSSEST10.

Design and configuration

Design involves the derivation of the architectural and detailed design of the space communication system according to the preceding requirements and analysis phases.

Configuration is the identification and naming of the component parts that make up the space communication system in order that a proper engineering management process can be applied to the development of those parts.

The design and configuration processes are described fully in ECSS-E-ST-10 and ECSS-M-ST-40.

Implementation

The implementation is the realization of the space communication system in real hardware and software. This is essentially a manufacturing activity.

Verification

Verification is the process of proving that the space communication system meets the requirements established for it. Verification is performed incrementally, starting with the individual parts of the communication system, and finishing with the complete, fully integrated system.

The verification process is described fully described in ECSS-E-ST-10-02.

Operations

Once the space communication system is implemented and verified, it enters its operational phase. This continues throughout the operational lifetime of the spacecraft. However, the start of the operational phase of the space communication system is normally during the spacecraft integration and test phase, since the communication system is often used during the spacecraft testing.

Process milestones

A number of process milestones in the form of project reviews are associated with the space communication engineering process. Each review comprises an analysis of the outputs of preceding activities. Generally, successful completion of a review means that the next activity of the space communication engineering process can begin.

The milestone reviews for space communication engineering are:

system requirements review, SRR;

preliminary design review, PDR;

critical design review, CDR;

qualification review, QR;

acceptance review, AR.

Flight readiness review, FRR.

During the planning phase for a project, the need for additional reviews can be identified, and then documented and incorporated into the project plan. Project phasing and planning is covered by ECSS-M-ST-10.

Relationship with other standards

This Standard is primarily a process oriented standard, i.e. it is concerned with the way in which the space communication system is achieved rather than the functional and performance details of the space communication system product. As such, this Standard is related to other ECSS and external standards.

Specifically ECSS-E-ST-70 is complementary to this Standard and describes the engineering process to be used for the development of the ground system elements of a space mission.

For the product oriented definitions of the communication system elements, e.g. for the specification of functional and performance characteristics of the services to be provided, this Standard refers to appropriate ECSS standards, or other external standards such as ISO or CCSDS standards.

Communications architecture

In line with modern communication engineering practice, and to be consistent with ISO, CCITT, and CCSDS standards, this Standard is based on a layered architectural reference model, as shown in Figure 43. This model comprises three layers:

the user layer,

the transfer layer, and

the subnet layer.

The user layer in Figure 43 corresponds to the application and presentation layers of the OSI 7layer reference model defined in ISO 7498, and to the application layer shown in Figure 42 The transfer layer of Figure 43 corresponds to the session, transport, and network layers of the OSI reference model, and to the transport and network layers shown in Figure 42. The subnetwork layer in Figure 43 corresponds to the data link and physical layers of the OSI reference model and of Figure 42.

Figure 43: Space communications reference architecture

Each layer of the architecture provides services and protocols defined either in ECSS standards, or by other explicitly referenced standards such as CCSDS recommendations. Depending on their profile, users access services provided by any of the onboard or ground layers. Communications internal to the onboard and ground segments are performed via the local transfer protocols and subnets, which are not covered by this Standard. Endtoend communications between space and ground segments are via the spacelink transfer protocols and spacelink subnet, which do form part of this Standard.

The space link subnet enables access to the space link medium and provides basic services for the transmission of delimited or undelimited data across the link. The space link layers can be resident in a single data system or can be partitioned between data systems in space and on the ground. In general the space link layers reside within the onboard TT&C subsystem. On the ground they can reside completely in the earth station, or can be partitioned between earth station and control centre or customer facility.

The ground and onboard transfer layers provide common services between the space and ground segment. They operate in a peertopeer interaction with their equivalent layers in the space and ground segments. The onboard and ground transfer layers make use of the services provided by the space link transfer and subnet layers to transfer data from data system to data system.

The ground and onboard transfer layers and subnets implement the services and protocols used for the independent operation of the onboard and ground systems. Users can directly use the services provided by the space link transfer protocols, or can access them via the services provided by their own local transfer protocols. Gateway functions can exist between the local transfer protocols and those of the space link. In some cases the space link transfer protocols can use bearer services provided by the local transfer protocols.

Spacecraft control considerations

The space communications system supports the operation and control of the spacecraft under a wide range of conditions. Under normal operating conditions, all functions onboard the spacecraft behave correctly, and the attitude and stability of the spacecraft is such that the communications link characteristics are optimal. In this state the spacecraft can be operated through the exchange of telemetry and telecommands via the space communications system, and payload data can be acquired.

However, degraded operating conditions can arise through loss of functionality due to onboard failures, or through degradation of the space link characteristics due to the attitude or motion of the spacecraft. In the case of degradation due to onboard failures or incorrect operation of the onboard functions, a general requirement is the capability to achieve some minimal level of control. In the very worst case, this means the capability to command the spacecraft in the blind, i.e. without any telemetry feedback, and to have some certainty of the execution of these telecommands. This implies that in this mode, the execution of telecommands is carried out using the minimum of onboard functionality, usually by directly decoding and executing them in hardware as they are received.

In less extreme cases, some critical telemetry can be received from the spacecraft. This critical telemetry is acquired and formatted for transmission using simple and reliable onboard functions, typically not relying on software.

Certain spacecraft attitudes or motions can significantly degrade the characteristics of the space link. This can result in severely restricted bandwidth, high bit error rates, frequent dropouts, and the loss of the link in one direction. The objectives for the design of the space communications system are to tolerate this and to enable spacecraft operations under these conditions. For example, the sizes of data units transferred on the space link are selected to minimize the susceptibility to bit errors and dropouts. For critical command and control functions, it is desirable to implement feedback in the form of acknowledgements, but not preclude the possibility of open loop commanding to tolerate the loss of the return link.

Requirements

Introduction

This clause contains requirements applicable to spacecraft communication systems and to the engineering process for the development of spacecraft communication systems.

Clause 5.2 contains requirements applicable to the spacecraft communication system engineering process.

Clauses 5.3, 5.4, and 5.5 contain general requirements that are applicable to the communication system as a whole, such as bandwidth allocation, telecommanding and telemetry requirements.

Clauses 5.6, 5.7, and 5.8 contain requirements specific to the individual domains of a spacecraft communication system.

Space communication system engineering process

Requirements engineering

Overview

The objective of space communication system requirements engineering is to capture and document all of the requirements that are applicable to the communication system. Requirements engineering is normally carried out by the customer of the communication system, and the results of this activity are then communicated to the supplier of the system.

Activities

During communication system requirements engineering the customer shall perform the following activities:

analysis of top level mission requirements specifications,
identification and expression of requirements specific to the space communication system, and
formulation of new communication system requirements not derived from other mission documentation.

Outputs

As an output from the requirements engineering activity, the customer shall produce the space communication system requirements specification (CSRD) in conformance with the DRD of Annex A.

Analysis

Overview

The objective of the space communication system analysis is to confirm the feasibility of the communication system and to identify possible solutions for its implementation. Analysis is usually carried out by the communication system supplier based on the customer provided outputs from the requirements engineering activity.

Activities

During communication system analysis, the supplier shall perform the following activities:

feasibility analysis of the communication system requirements,
technical analysis of e.g. data rates, link margins, commandability, Doppler effects on carrier and data signals;
criticality analysis of the space communication system;
definition of the toplevel space communication system architecture;
definition of the system verification plan, including compatibility and interoperability testing;
identification of potential solutions for the realization of the space communication system;
identification and request for assignment of globally managed parameters such as radio frequencies and spacecraft identifiers;
identification of telemetry parameters, their criticality classification, and their need for time stamping at source;
identification of telecommand parameters;
identification of data flows between system elements;
identification of ranging requirements.

Outputs

The supplier shall provide a communication link margin analysis and Doppler margin analysis reports, in conformance with the DRD in Annex C (CSAD).
The supplier shall provide a criticality analysis report, in conformance with the DRD in Annex C (CSAD).
The supplier shall provide a system verification plan (CSVP), in conformance with Annex D.
The supplier shall provide a interoperability and compatibility test plans (CSVP), in conformance with Annex D.

Design and configuration

Overview

Space communication system design and configuration is the elaboration of potential solutions into a detailed design whose implementation can be managed through a formal configuration management process. Design and configuration is a supplier activity.

Activities

During communication system design and configuration the supplier shall perform the following activities:

partitioning of the detailed design from the analysis phase into system components that can be realized separately;
allocation of unique names or identifiers to all of the system components in accordance with the project’s configuration management methodology;
generation of requirement specifications for all system components;
definition of manual and automatic operational procedures, including link acquisition procedure, link release procedure, synchronization procedure, and data rate and frequency negotiation procedures;
review link margin analysis and update.

Outputs

The supplier shall provide a detailed design of the space communication system (CSBD, CSADD, CSDDD, CSPD) in conformance with the DRD in Annex B, Annex E, Annex F and Annex G,
The supplier shall provide a list containing all components of the space communication system that are subject to configuration control (CSDDD), in conformance with the DRD in Annex F,
The supplier shall provide the simulations and demonstrations used to verify the design, to resolve design conflicts, and to select options (CSVP), in conformance with the DRD in Annex D, and
The supplier shall provide the definitions of operational procedures (CSOM), in conformance with the DRD in Annex H.

Implementation

Overview

Space communication system implementation is the realization of the communication system according to the design and to meet all of the specified requirements. This is a supplier activity.

Activities

During space communication system implementation the supplier shall perform the following activities:

the procurement of system components (hardware and software) from subcontractors and suppliers, including the acceptance testing of those components to confirm that they meet their requirements specification;
the manufacture of system components (hardware and software) according to the design specification, and the subsequent testing of those components to confirm that they meet their requirements specification;
the integration of all components, both manufactured and procured, to produce the complete space communication system;
testing of the complete space communication system to confirm that it meets the agreed specification, including correction of any faults that prevent the completed system from meeting the agreed specification;
execution of interoperability and compatibility tests and generation of test result reports;
the management of the implementation activities according to the agreed management plan and using the approved management tools and procedures, to ensure the timely delivery of the space communication system within the allotted budget;
review of link margin analysis and updating.

Outputs

During the space communication system implementation activity the supplier shall deliver the complete communication system to the customer.
The supplier shall provide all plans and designs for the space communication system, including the designs of the system itself, as well as designs for test and checkout equipment used to verify the system (CSADD, CSDDD, CSVP), in conformance with the DRD in Annex E, Annex F and Annex D;
The supplier shall provide all test and checkout procedures used to verify the system (CSVP), in conformance with the DRD in Annex D;
The supplier shall provide all simulations and demonstrations used in the manufacture and verification of the system, including environment models used to simulate external effects on the system (CSVP), in conformance with the DRD in Annex D;
The supplier shall provide documents relating to the execution and results of verification tests, and interoperability and compatibility tests (CSVP), in conformance with the DRD in Annex D;
The supplier shall provide documents detailing any deviation from the original design, including details of changes made as a result of verification testing, and changes made to the test procedures (CSADD, CSDDD, CSVP), in conformance with the DRD in Annex E, Annex F and Annex D, respectively.

Verification

Overview

Space communication system verification is the demonstration before the customer that the system meets the agreed specification. This is usually a combined customer and supplier activity: evidence of verification is provided by the supplier, and accepted by the customer

Activities

During space communication system verification the supplier shall perform the following activities:

the execution in a fully controlled environment of all agreed verification tests and procedures;
the formal recording and subsequent analysis of all verification test results, and the completion of compliance and characterization matrices for the space communication system;
review of link margin analysis and updating.

Outputs

The supplier shall provide a verification test report produced by the supplier and detailing the results of the execution of all verification tests, and including relevant system characterization data (CSPD) in conformance with Annex G.
A declaration of acceptance shall be signed by the customer and supplier to confirm the customer acceptance of the delivered product.

Operations

Overview

Space communication system operations is the operation of the communication system during the spacecraft mission in order to achieve the aims of that mission. Depending on the contractual arrangements, this can be entirely a customer activity, entirely a supplier activity, or an activity conducted by both the customer and the supplier.

Activities

The activities performed during space communication system operations shall include:

operation of the space communication system as and when specified by the mission to achieve the objectives of the mission;
maintenance, including planned upgrades of the system and reconfiguration for different phases of the mission;
provision of additional support for spacecraft trouble shooting and contingency operations;
execution of the decommissioning procedures at endoflife, including stopping spacecraft transmissions, and notification of the ITUR of the availability of the frequencies for reuse.

Outputs

During the space communication system operation activities, the space communication system shall be operated to meet the mission’s system requirements.
During the space communication system operation activities, periodic reports on utilization and performance to assist in maintenance planning shall be produced.

Space communication system

Bandwidth allocation

The space communication system shall allocate bandwidth according to the data transmission requirements and the operational mode of the spacecraft.
During emergency operations, bandwidth allocation priority shall be given to essential commands and telemetry.

For essential telecommand see 5.4.4b. For essential telemetry, see 5.5.2b

Congestion

The space communication system shall ensure that data is not lost due to congestion.

This can be ensured by using buffering and flow control techniques.

Cessation of emission

The space communication system shall be designed so that all transmissions from a spacecraft can be stopped at any time by telecommand.

By implication, the telecommands used to stop transmission are essential telecommands, i.e. telecommands that are executed even when all other onboard equipment has failed.

Telecommanding

Commandability at all attitudes and rates

The design of the space communication system shall ensure that the spacecraft can be commanded at all spacecraft attitudes, and at all anticipated attitude rates.

Telecommand delivery service

A service shall be provided which guarantees insequence delivery of telecommands.

Erroneous telecommand rejection

The probability of accepting an erroneous telecommand shall be less than 10-2/N, where N is the number of telecommands expected to be transmitted to the spacecraft during its mission.

Essential command distribution

The design of the space communication system shall enable essential telecommands to be decoded and control signals distributed even when all other systems, including the CDMU, are nonoperational.
The list of essential commands, including their encoding and effects, shall be agreed at PDR.
The essential telecommands shall enable power to key system components to be switched on or off, and for switchover to redundant systems to be forced.
For critical operations, execution of the essential commands shall not depend on software functions.

Example of critical operations is switching the transmitters on and off.

Command authentication

The space communication system shall ensure that only telecommands from authorized sources are executed onboard the spacecraft.

This can involve the use of authentication techniques.

Command encryption

The space communication system shall provide telecommand encryption services when the security requirements cannot be met by command authentication only.
For maximum security, encryption should be provided at the user layer, but it may also be provided at the transfer layer.

Commandingintheblind

The space communication system shall enable commandingintheblind operation, i.e. the uplinking of telecommands in the absence of any feedback telemetry or command acknowledgements from the spacecraft.

Telecommand acknowledgement

The space communication system shall enable telecommand acknowledgements to be returned to the telecommand source.

Telemetry

Telemetry at all attitudes and rates

The design of the space communication system shall ensure that essential spacecraft telemetry can be transmitted at all spacecraft attitudes, and at all anticipated attitude rates.

In some missions this provision can be unachievable. Its intent is that ground controllers can always obtain telemetry from the spacecraft for contingency operations and failure recovery.

Essential telemetry acquisition

The design of the space communication system shall enable essential telemetry to be acquired from critical monitoring points and transmitted to the ground, even when all other systems, including the CDMU, are nonoperational.
The list of essential telemetry parameters, including engineering conversion rules, parameter encoding, and transmission formats, shall be agreed at PDR.
Essential telemetry shall include the information necessary on the ground to determine the overall condition of the spacecraft.

For example, the power system state, the status of critical systems including the onboard data handling system, and whether telecommands are being received.

Acquisition of these parameters should not rely on the availability of the space network, or the execution of onboard software applications.

Telemetry source identification

All spacecraft telemetry packets shall carry an identifier that indicates the source spacecraft from which it originates.

Telemetryintheblind

The space communication system shall enable telemetryintheblind operation, i.e. the downlinking of telemetry data in the absence of any uplink signal to the spacecraft.

Telemetry packet time stamping

All telemetry packets generated onboard the spacecraft shall be time stamped such that the temporal ordering of the acquired telemetry can be determined on the ground, regardless of the location of the onboard application that generated the telemetry packet.

The implication of this requirement is that the time stamp is related to a common onboard reference time.

Simultaneous support of differing source rates

The telemetry downlink shall support a range of simultaneous source data rates with a given priority and respect for maximum latency times for each data source.
The telemetry downlink shall not impose constraints upon the rates of individual telemetry data sources.

This implies that the data rates through the downlink are independent from the signalling rate on that link.

Space link

Introduction

Overview

The space link modulation scheme is selected to minimize the occupied bandwidth of the transmitted signals. Suitable modulation schemes are defined in ECSS-E-ST-50-05.

The space link channel coding scheme is selected to minimize the power to be used by the space link in order to minimize the potential for harmful interference to other users. Suitable channel coding schemes are defined in relevant ECSS-E-ST-50 Standards (e.g. ECSS-E-ST-50-01 and ECSS-E-ST-50-04).

The space link is described in clause 4.3.3.

Conformity to ITU/RR

The space link is subjected to the ITU/RR regulations, in particular:

Downlink data rates (see NOTE to requirement 5.6.11.11a).

use of the radio frequency assigned for space communication (see NOTE 1 to requirement 5.6.12.2a)

frequency bands for space communication systems (see NOTE 2 to requirement 5.6.12.2a).

Earth station RF emissions. This limits the radiated power. Specifications for the maximum equivalent isotropic radiated power (EIRP) that can be transmitted in a direction towards the horizon are described in ECSS-EST5005.

Directionality

Each space link shall be treated as a simplex communication channel.
Data integrity mechanisms, such as ARQ, on other contraflowing space links shall be supported.

Space links can be operated as pointtopoint or pointtomultipoint communication channels.

Short contact periods

The space link shall be capable of operating when the spacecraft contact period is of short duration and sporadic.

Short, sporadic contact periods can prevail during normal operation in some missions, but can occur only during emergency operations in other missions.

Interoperability

The space link shall be designed to provide interoperability for a wide range of mission types, for science, control and housekeeping data, and a similarly wide range of ground segments including control centres and customer receive only earth stations.

Orbits

The design of the space link shall enable optimization for its specific use in the orbit chosen.
For each mission the space link shall be optimized for its specific orbit in terms of, for example, power and bandwidth.

Noise sources

The design of the space link shall take account of continuous background noise (natural or manmade) sources as well as burst sources such as those due to solar events or structural interference.

phases

All mission phases shall be supported including AIT, prelaunch, launch, operations execution, and end of life.

Link setup times

To support contingency situations, the design shall enable the transfer of meaningful commands and status reports within very short acquisition periods.

Link setup times are kept to a minimum in order to cope with short contact periods with the spacecraft.

Mixed isochronous and asynchronous traffic

The design of the space link shall enable isochronous and asynchronous data traffic to be carried within a single link.

Mixed housekeeping and payload data

The design shall enable the transfer of spacecraft housekeeping telemetry and payload data on a single space link.

Space link performance

Doppler shift and Doppler rate

The space link shall be capable of operating under the worstcase Doppler shift and Doppler rate conditions expected for the mission.

Doppler shift can be highly variable and induced by high orbital velocities or by accelerating or manoeuvring spacecraft.

Operation during tumbling

The space link shall be designed to operate in the worst case tumbling conditions expected for the spacecraft.
The ability to cope with these conditions shall be demonstrated by simulation during the analysis, implementation, and verification phases.

Tolerance of run lengths and transition densities

The space link shall be designed to tolerate the worst case run lengths and transition densities that can occur in the data.

For example, runs of zeros or ones, or data patterns that result in very high or very low transition densities in the modulated signal.

The ability to operate under the worst case run length and transition densities shall be demonstrated by simulation during the analysis, implementation, and verification phases.

Failure modes

The space link shall be adaptable to a range of failure modes including:

loss of link,
reduction in link margin, and
sporadic carrier acquisition.

Uplink assumed bit error rate (BER)

Uplink budget calculations shall be based on a BER of 10-5 at the input to the telecommand decoder.

Uplink frame rejection rate

For a link BER of 10-5, the uplink frame rejection rate for a frame size of 256 octets shall be less than 10-5.

Probability of accepting corrupted uplink frames

The probability of accepting a corrupted uplink frame shall be compatible with the requirement 5.4.3a.

For the error rate defined in clause 5.6.11.5 and using the error control mechanisms defined in ECSS-EST5004 and ISO 12172, ISO 12173, and ISO 12174, the probability of undetected frame error can be made to be below 10-18 using frame error control, and below 10-8 without frame error control.

Downlink frame rejection rate

The downlink frame rejection rate should be less than 10-5.

Probability of accepting corrupted downlink frames

The probability of accepting a corrupted downlink frame for maximum sized frames should be less than 10-12.

Low delay

The space link shall be designed to minimize the endtoend delay of delivery of space link service data units.

Downlink rates

The downlink data rates shall be selected to be compatible with the data transmission requirements of all phases of the mission.

It is important to ensure that the downlink data rates are constrained in bandwidths compatible with ITURR in terms of frequency and bandwidth allocation.

Space link frequency

Space link media

The space link media shall be used to communicate between spacecraft and ground segment and between one spacecraft and another spacecraft.
The total number of frequencies used by a project should be minimized.

Frequency band selection

An application for frequency assignment shall be made to the Radio Communication Bureau of the ITU for the selected space communication frequencies prior to the SRR.

1 The use of the radio frequency assigned for space communication use is subject to the regulations of the Radio Communication Bureau of the ITU. The space communication system frequencies and selection procedures are detailed in ECSS-EST5005.
2 It is important to ensure that the frequency bands for space communication systems are selected from bands allocated for this service by the ITURR in accordance with the type of service of the spacecraft mission.

Unwanted RF emissions

Unwanted RF emissions shall be kept at a level such that they do not interfere with users of other bands.

Requirements on spurious emissions address both:

a global limitation on the level of the spurious signals over the whole frequency spectrum, and
special protection applicable to the band of the particularly interferencesensitive services: radio astronomy and deep space.

Power flux density limits

In certain frequencies of the bands allocated to space services, power flux density (PFD) limits on the Earth’s surface shall apply.

These are described in ECSS-E-ST-50-05.

The PFD limits specified in requirement 5.6.12.4a shall apply during all phases of the mission.

This can involve means of reducing the transmit power onboard the spacecraft.

Space link protocol

Spacecraft and link identification

Formatted data units used on the space link shall include a specific identification of the spacecraft and link involved in a ground to space communication.

Data unit identifier

Formatted data units used on the space link shall include an identifier that identifies the source, the destination, or both source and destination of the data unit.

The data unit identifier need only be unique to the specific spacecraft domain. Universally unique identification of the source and or destination can therefore involve reference to several identifiers in combination, such as the data unit identifier in combination with the spacecraft identifier.

Sequence identifier

Formatted data units used on the space link shall include a sequence identifier that identifies the data units position in a stream of data units on the space link in order to detect duplication or omission of data units.

Error detection

The space link protocol shall include an error detection capability.
The probability of an undetected error on the space link shall be specified as a project specific item.

The error detection performance can differ on the uplink and downlink.

For both the uplink and downlink, the error detection used should be compatible with the telecommand and telemetry performances set out in clause 5.6.11.

The error control schemes defined in ECSSEST50-01 and ECSS-E-ST-50-04 provide the means to do this at various link bit error rate operating points.

ARQ settings

ARQ settings shall be verified in endtoend simulations under all expected conditions to ensure that there is neither unnecessary loss of data nor excessive retransmission.

Space link service

Connection establishment and maintenance

The space link shall provide a connection establishment and maintenance function.

Space link connection establishment involves the acquisition of carrier and configuration of the link for data transfer at the beginning of a contact period, and the ordered disconnection at the end of a contact period. This can include negotiation of signalling rates to suit the RF characteristics of the link at establishment time. Link maintenance is the management of the connection after link establishment and can include periodic renegotiation of signalling rates as the RF characteristics of the link change during a contact period.

Guaranteed delivery

The space link shall provide a guaranteed delivery service which ensures that SDUs are delivered and preserves the ordering of SDUs.

The space link can also provide other services or grades of service that do not guarantee delivery, or do not preserve the order of space link SDUs.

Expedited delivery

The space link shall provide a service for expedited delivery of SDUs, i.e. a service that processes SDUs with priority over other SDUs already submitted for transmission.

ISO 7498 considers expedited services to be used only in connectionmode transmissions. However, in the space link this concept is applied to connectionmode and connectionlessmode transmissions. In connectionlessmode, expedited services SDUs are transmitted before any other SDUs queued for transmission on the space link.

Isochronous services

The space link shall provide isochronous duplex services when supporting time critical delivery of voice and video data.

Isochronous requirements

The isochronous services shall be specified as a nominal data rate, a maximum nominal latency and a maximum deviation characteristic from that latency.

Time correlation

The space link shall provide a time correlation capability that enables the time maintained on the spacecraft, the onboard time, to be correlated with the time maintained on the ground.

Ranging

The space link shall provide a ranging capability that enables the distance between a ground station antenna and the spacecraft antenna to be determined.

Telecommand receipt confirmation

The space link shall provide a telecommand receipt confirmation function that confirms receipt of telecommands at the space network gateway.

This function confirms that telecommands were received onboard the spacecraft, but does not necessarily imply that they were routed through the space network or delivered to the end destination.

Space link exception reporting

The space link shall provide an exception reporting function that enables the reporting of all detected errors.
Exceptions to be reported as specified in requirement 5.6.14.9a should include receipt of erroneous data units, even if corrected, receipt of undeliverable SDUs, failure to deliver SDUs, link reconfiguration, and unexpected loss of link.

Space network

General

Overview

The space network is described in clause 4.3.2.

Deterministic performance

The space network performance shall be deterministic under all loads.

Synchronous command and control

The space network shall provide the capability of synchronous command and control of onboard sensors and actuators.

Asynchronous data transfers

The space network shall provide the capability of performing asynchronous data transfers between connected nodes.

Space network medium access

The space network shall provide medium access mechanisms to enable all connected nodes to access the onboard subnetwork in order to transfer data.

Hot redundant operation of space network nodes

The space network shall enable the hot redundant operation of all connected nodes.

Environment tolerance

The space network shall be designed to operate under the worst case environmental conditions expected for the mission.

Example of worst case environmental conditions are EMC and radiation.

Space network error rates

The probability of errors occurring during the transfer of data across the space network shall be lower than that specified for the space link.

Space network services

Packet transfer service

The space network shall provide a packet transfer service that enables each application in the space network domain to exchange data packets with other applications in the space network domain and the ground network domain.

Reliable packet transfer

The space network shall provide a reliable packet transfer service that guarantees the delivery of data packets to the destination or, if the packet cannot be delivered, notifies the sender that the packet is not deliverable.

Expedited transfer services

The space network shall provide the capability of expediting data transfers.

Expedited data is transferred before any nonexpedited data.

Space network management service

The space network shall provide a network management service that maintains the space network routing and configuration tables in order to provide high reliability and availability of the space network.

Space network redundancy management

The space network shall provide services that manage the redundancy, including for example selection between underlying buses and reconfiguration of addresses and routing tables to accommodate switching to redundant units.

Space network exception reporting

The space network shall provide an exception reporting function that enables all detected errors to be reported.
Exceptions shall include receipt of erroneous data units, even if corrected, receipt of undeliverable SDUs, failure to deliver SDUs, loss of subnetwork links, and reconfiguration due to fault detection.

Telecommand delivery confirmation

The space network shall provide a telecommand delivery confirmation capability that confirms delivery of telecommands to the end destination within the space network domain.

This service confirms that telecommands were delivered to the end destination, but does not necessarily imply that they were executed. Confirmation of execution is a requirement on the application responsible for execution, and is outside the scope of this Standard.

Time distribution

The space network shall provide a time distribution capability that enables a reference time maintained onboard the spacecraft to be distributed throughout the space network.

Ground network

Overview

The ground network and many of its associated requirements are largely defined in ECSS-EST70, and described in clause 4.3.4.

Data labelling

The ground network shall ensure that all items of data acquired from the spacecraft are uniquely labelled so that the parameter name, the sampling time, and the time received on ground can be determined.

Security

The ground network shall provide security mechanisms to prevent unauthorized access to the ground facilities to command or acquire data from the spacecraft.

Error rates

Error rates on the ground network shall be significantly lower than those on both the space link and the space network.

Hot redundant operation of ground network nodes

The ground network shall enable the hot redundant operation of nodes used for the control and operation of critical mission functions.

Ground network availability

The ground network shall be available for all scheduled operations on the spacecraft.

ANNEX(normative)Communication system requirements document (CSRD) - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-50, requirement 5.2.1.3a.

Purpose and objective

The communication system requirements document (CSRD) contains the top level assumptions, constraints and communication system requirements for a given mission to enable the supplier of the communication system to elaborate a design for the communication system.

The CSRD is written by the space project customer and is the highest level requirements document defining the requirements on the space communication system. The supplier of the space communication system formally responds to the CSRD with the communication system baseline definition (CSBD, see ECSS-

E-ST-50 Annex B) where all the requirements in the CSRD can be traced to a proposed implementation.

Expected response

Scope and content

Introduction

The CSRD shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Applicable and reference documents

The CSRD shall list the applicable and reference documents in support to the generation of the document.
overview

The CSRD shall briefly describe:

the main objectives and characteristics of the space mission;
the spacecraft;
the instruments onboard the spacecraft;
the ground segment for the control and operations of the spacecraft, the instruments, and the ground segment itself;
the operations to achieve the goal of the space project. Project responsibilities

The CSRD shall briefly describe the distribution of responsibilities within the space project, including the responsibilities of the space project customer and those of the communication system supplier.
Major project milestones

The CSRD shall summarize the major project milestones relating to the space segment.
The CSRD shall summarize the major project milestones relating to the ground segment.
The CSRD shall summarize major project milestones relating to the communication system.
constraints

The CSRD shall include the following launch information

The launch vehicle, the launch site location and the ascent trajectory.
For orbital vehicles, the orbit injection characteristics. The CSRD shall describe the trajectory by summarizing the following:
The trajectory of the spacecraft.
Any significant constraints or parameters associated with each part of the trajectory.
Any notable periods arising from the trajectory during which communications with the spacecraft are difficult or impossible.
For orbital vehicles, the intended orbital period and visibility periods and characteristics during which communication can be performed. The CSRD shall describe the operational phases by summarizing the following:
Each distinct operational phase of the space mission.
Any constraints on, and expected characteristics of the communication system for each phase.

phases usually include LEOP, commissioning, routine operations, and disposal. Other phases that can be included are contingency operations, critical manoeuvres, and hibernation.

The CSRD shall describe any constraints imposed on the communication system by the spacecraft.

For example power limitations, antenna pointing constraints, and prohibited frequencies.

The CSRD shall describe any other constraints not covered in the preceding categories, and other essential mission information that impacts on the design of the communication system.
Communication system requirements

General

The CSRD shall list the high level requirements on the space communication system, at a level appropriate to enable all significant aspects of the communication system technical baseline to be elaborated.

his in turn enables:

informed decision making concerning the development and procurement of the communication system components, and
the communication system design drivers to be established.
The list specified in <7.1>a shall include the communication system requirements that address the following major system elements:
functional;
performance;
reliability;
availability;
interface;
design (implementation);
maintainability;
security. Where the requirements for a particular system element differ for different operational or mission phases, the requirements shall first be listed for the normal operational phases and then those that are different for other mission phases.
Organization of the communication system requirements

The CSRD shall list the overall system requirements on the communication system including requirements related to:

overall system availability and reliability,
endtoend performance,
communication system lifetime,
design and implementation,
interfaces to existing external entities, and
compatibility with specific communications protocols. The CSRD shall list the security requirements for the communication system.

As specified in ECSS-E-ST-50, this is based on a threat analysis of the mission.

The CSRD shall list the communication system requirements for the space network, which comprises all of the nodes of the flight segment of the mission.
For missions that involve multiple space segment elements, such as cluster missions, orbiterlander combinations, landerrover combinations, and missions with deployable probes, the CSRD shall list the requirements on the communications between those elements.
The CSRD shall list the requirements for the link between the ground station and the spacecraft including requirements regarding:

uplink and downlink performance,
RF frequencies,
contact periods and outages,
link acquisition, and
link failure modes. The CSRD shall list the communication system requirements for the ground network, which comprises all of the ground communication facilities used in the mission, including requirements for redundancy, availability, and accessibility.

Special remarks

None.

ANNEX(normative)Communication system baseline definition (CSBD) - DRD

DRD identification

B.1.1 Requirement identification and source documentThis DRD is called from ECSS-E-ST-50, requirement 5.2.3.3a.

B.1.2 Purpose and objectiveThe communication system baseline definition (CSBD) is the top level design document produced by the communication system supplier to define the communication system to be developed for the mission. The CSBD forms the basis for all other specification and design activities undertaken by the communication system supplier, as well as constituting the baseline for generating cost and schedule information.

The CSBD constitutes the formal response to the CSRD (see ECSS-E-ST-50 Annex A). All requirements in the CSRD are traced in the CSBD and appropriately apportioned into specific CSBD clauses. Furthermore, any additional requirements can be derived in the CSBD to ensure common understanding and unambiguous interpretation of the CSRD requirements.

Expected response

Scope and content

Introduction

The CSBD shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Applicable and reference documents

The CSBD shall list the applicable and reference documents in support to the generation of the document.
description and communication system overview

The CSBD shall describe the main objectives and characteristics of the space mission.
The CSBD shall describe the communication system, including:

the intended communication system implementation,
the main concepts of the proposed communication system,
the system components of the communication system, indicating where they are located and how they interrelate, and
the proposed protocols and communication frequencies to be used within the intended communication system. constraints and implementation assumptions

The CSBD shall describe all mission constraints that affect the communication system.

These can include trajectory induced constraints such as out of contact, or hibernation mode, attitude induced constraints such as tumbling mode or antenna pointing limitations, and ground induced constraints such as ground station availability.

The CSBD shall describe all of the assumptions made in establishing the communication system baseline definition.
Communication system interfaces

The CSBD shall summarize the interfaces between the space network elements of the communication system and other entities onboard the spacecraft including:

the control interfaces for the onboard elements of the communication system, indicating how the onboard data handling system manages space link communication;
the data interfaces that enable onboard entities to send data to and receive data from the ground; For missions that have multiple space segment elements, the CSBD shall summarize:
how the communication links between those elements are controlled, and
how data is transferred across them; The CSBD shall summarize the interfaces between the ground network elements of the communication system and other ground entities, including:
the control interfaces for the ground elements of the communication system, indicating how the ground system manages space link communication;
the data interfaces that enable ground entities to send data to and receive data from the spacecraft. Communication system analysis

The CSBD shall describe:

all of the communication system analysis and system studies to design a communication system that meets the objectives of the space mission, and
the justification of the analysis and studies referred to in B.2.1<6>a1. The CSBD should:
list all communication system issues to be resolved by modelling or simulation, and
describe the modelling or simulation technique to be applied. The CSBD shall list the expected performances that can be achieved by the proposed communication system and indicate whether these fully meet the mission needs.
Communication system design and implementation

The CSBD shall describe the technical approach to the design and implementation of the overall communication system and each of its components.
Communication system integration and technical verification and validation

The CSBD shall describe the technical approach to the integration and testing of the communication system elements, and the technical verification and validation of the communication system as a whole.
Communication system operations

The CSBD shall describe all of the operational procedures relating to the communication system for normal operations.
The CSBD shall describe all of the operational procedures relating to the maintenance of the communication system.
The CSBD shall describe special operational procedures to be used for contingency operation of the communication system, i.e. in case of degradation of its normal performance.

These operational procedures can include unidirectional operation of the communication system, e.g. commandintheblind and telemetryintheblind, and operation at reduced signalling rates.

The CSBD shall describe the technical approach to monitoring the health and performance of the communication system.
The CSBD shall describe any communication system specific operations not covered in items B.2.1<9>a to d.

For example, these can include procedures to support inflight communications experiments, reconfiguration of the communication system to support new mission parameters such as the addition of new flight elements, and procedures to adapt the communication system for use on other missions.

Special project facilities

The CSBD shall describe any special project facilities for the development and implementation of the communication system (e.g. the modification of existing ground facilities, or the adaptation of reused flight software).
Support to other disciplines

The CSBD shall describe the support to be provided to other spacecraft disciplines by the communication system supplier.

This can include the provision of simulation models of communication system components, and test harnesses.

Required input and output items and services

The CSBD shall list all of the deliverable items and services to be provided by the communication system supplier to support the mission.
The CSBD shall list all of the items and services to be provided by the communication system customer in order to support the development of the communication system.

These can include:

space segment design documents and information;
ground segment design documents and information;
access to testbeds, prototypes, and engineering models for integration and testing;
simulation models of the ground and space segments.
CSRD vs. CSBD traceability matrix

The CSBD shall provide a CSRD versus CSBD traceability matrix, summarized in a table, providing the following information for each entry:

requirements - containing a list of all requirements in the CSRD;
reference - providing a cross reference indicating one or more CSBD paragraphs where the requirement is fulfilled;
compliance - indicating the level of the suppliers’ compliance of the CSBD to the CSRD with one of the following values: COMPLIANT,

PARTIALLY COMPLIANT, or

NONCOMPLIANT;

notes - briefly describing the justification in those cases where column three indicates partial or noncompliance. Toberesolved items

The CSBD shall list all of the items for which a clear resolution has not yet been found.
Tobedetermined and tobeconfirmed items

The CSBD shall list all of the items for which a specific communication system implementation cannot be committed without further information.

Special remarks

None

ANNEX(normative)Communication system analysis document (CSAD) - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-50, requirements 5.2.2.3a and 5.2.2.3b.

Purpose and objective

The communication system analysis document (CSAD) is produced by the communication system supplier to capture the results of analysis and testing of the communication system. The first issue of the CSAD is produced for the PDR, but it is updated throughout the project as further communication system analysis and testing is carried out and, as specified in ECSS-E-ST-50, is reviewed at each major project milestone following the PDR.

The results of all analysis and testing carried out on the communication system are reported in the CSAD. This document is therefore critical for tracking the development of the communication system throughout the project, ensuring that the communication system continues to meet the functional and performance requirements as the design and implementation are elaborated. The CSAD is used as a reference for the identification and resolution of any design issues throughout the development of the communication system.

Expected response

Scope and content

Introduction

The CSAD shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Applicable and reference documents

The CSAD shall list the applicable and reference documents in support to the generation of the document.
description and communication system overview

The CSAD shall describe the main objectives and characteristics of the space mission.
The CSAD shall describe the intended communication system implementation.
Overview of analysis approach

The CSAD shall provide an overview of the analysis approach applied to the communication system.
The CSAD shall describe the goals and objectives of the analyses.
The CSAD shall describe the different analysis techniques used on the communication system.
The CSAD should contain a list of the communication system issues to be resolved by analysis.
Description and results of analysis

The CSAD shall describe each of the analysis techniques applied to the communication system together with the results of that analysis.
For each technique referred to in C.2.1<5>a, the CSAD shall include at least the following:

the objective of the analysis,
a detailed description of the analysis technique,
a description of any tools used to carry out the analysis,
a list of any assumptions made concerning the communication system or its environment during the analysis,
a list of starting conditions for the analysis,
copies of all inputs to the analysis,
the results of the analysis,
an appraisal of the analysis drawing conclusions and inferences with respect to the communication system, and
recommendations for the communication system based on the analysis.

The objective is that the analysis results can be reviewed offline, and the analyses can be repeated.

The conclusions referred to in C.2.1<5>b.8 should indicate whether the communication system meets its functional and performance requirements.
The recommendations referred to in C.2.1<5>b.9 should include recommendations on design changes.

Special remarks

None.

ANNEX(normative)Communication system verification plan (CSVP) - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-50, requirements 5.2.2.3c, 5.2.2.3d, 5.2.3.3c, 5.2.4.3b, 5.2.4.3c, 5.2.4.3d, 5.2.4.3e and 5.2.4.3f

Purpose and objective

The communication system verification plan (CSVP) is produced by the communication system supplier to describe the verification strategy and specific verification tests used to ensure that the communication system complies with the requirements established in the CSRD and CSBD. The first issue of the CSVP is produced for the PDR but, as specified in ECSS-E-ST-50, is updated throughout the project as more detailed tests are defined and critical issues are identified, and is reviewed at each major project milestone following the PDR.

The CSVP defines the tests to be conducted on the communication system to verify conformity to CSRD (see ECSS-E-ST-50 Annex A) and CSBD (see ECSS-E-ST-50 Annex B) requirements and therefore derives from these two documents. The results of the verification tests and any analysis to be conducted as a part of the verification process are reported in the CSAD (see ECSS-E-ST-50 Annex C).

Expected response

Scope and content

Introduction

The CSVP shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Applicable and reference documents

The CSVP shall list the applicable and reference documents in support to the generation of the document.
description and communication system overview

The CSVP shall describe the main objectives and characteristics of the space mission.
The CSVP shall describe the intended communication system implementation.
Verification approach

The CSVP shall describe the approach to the communication system verification.
The CSVP shall describe the techniques to be used for the verification.
The CSVP shall list any special tools or facilities to be used.
Verification schedule

The CSVP shall describe the communication system verification schedule explaining how the communication system verification schedule matches the development schedules for both the ground segment and flight segment of the space mission.
The CSVP shall include a list of all tools and equipment to be used for the communication system verification activities, identifying for each tool

who is responsible for supplying it,
where it is provided,
the equipment configuration to use, and
the duration for which it is used. Support to other verification activities

The CSVP shall describe the tools, equipment, and facilities associated with the communication system that can be made available to support other verification activities, such as the ground system or flight system verification.
The CSVP shall describe the nature of the tool, equipment, or facility.
The CSVP shall describe the capability of each tool.
The CSVP shall describe when and where each tool can be made available.
Verification tests

The CSVP shall describe each verification test to be performed, including the following information for each one:

a statement of the purpose of the verification test;
a detailed description of the test;
a list of the tools, equipment, or facilities to perform the test;
a definition of the configuration of the test environment and the unit under test at the start of the test (i.e. preconditions);
a description of the expected result (i.e. postconditions);
pass and fail criteria for the test.

The purpose of these test description is to ensure that the verification tests can be repeated.

Special remarks

None.

ANNEX(normative)Communication system architectural design document (CSADD) - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-50, requirements 5.2.3.3a, 5.2.4.3b and 5.2.4.3f

Purpose and objective

The communication system architectural design document (CSADD) describes the architectural design of the communication system defined in the CSBD (see ECSS-E-ST-50 Annex B).

The CSADD describes the design to the level where its functionality and operation can be understood for the purposes of the PDR. Furthermore, the CSADD enables the requirements for the individual system components, and the interfaces to those components, to be elaborated so that detailed design of the components can proceed.

The CSADD is produced by the communication system supplier to describe the architectural design of the communication system.

The CSADD is produced for the PDR, and its acceptance at the PDR by the communication system customer implies a commitment to proceed with the detailed design consistent with the architecture described. As specified in ECSSEST50, the CSADD is frozen after acceptance at the PDR.

The communication system architectural design document describes the high level architecture of the communication system and is therefore derived from the CSBD. In turn, the communication system detailed design document (CSDDD) is derived from the CSADD.

The interfaces identified within the CSADD, both between the communication system components, and to other external entities, are subject to tests defined in the CSVP. The functionality and performance of the communication system components identified in the CSADD can be the subject of specific analysis activities in the CSAD.

Expected response

Scope and content

Introduction

The CSADD shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Applicable and reference documents

The CSADD shall list the applicable and reference documents in support to the generation of the document.
description and communication system overview

The CSADD shall briefly describe:

the main objectives and characteristics of the space mission, and
the intended communication system baseline as defined in the CSBD. Communication system architectural design

The CSADD shall contain a description of the architectural design of the communication system in a human readable format, and include the justification of all critical architectural design decisions.
As a minimum, the architectural design of the communication system shall:

list each major component of the communication system,
describe the function and performance of each major component in terms of top level requirements,
list and broadly describe all of the internal interfaces (i.e. interfaces between components of the communication system), and
list and broadly describe all of the external interfaces (i.e. interfaces between external entities and components of the communication system). Requirement applicability matrix

This CSADD shall provide a requirement applicability matrix, including the following information:

requirements - containing a list of all requirements in the CSRD plus any derived requirements contained in the CSBD;
applicability - indicating the applicability of each requirement to each major communication system component. Usually, this column can be subdivided into a series of columns, one for each major system component, and completed checkbox style;
notes – providing any special information associated with a given requirement in respect of its allocation to a communication system component.

Special remarks

Although this DRD imposes no constraints on the tools used to elaborate the architectural design, the architectural design shall be viewable without the use of the design tool.

ANNEX(normative)Communication system detailed design document (CSDDD) - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-50, requirements 5.2.3.3a, 5.2.3.3b , 5.2.4.3b and 5.2.4.3f

Purpose and objective

The communication system detailed design document (CSDDD) describes the detailed design of the communication system, further elaborating the architectural design described in the CSADD (see ECSS-E-ST-50 Annex E). The CSDDD described the detailed design of each of the communication system components identified in the CSADD.

The CSDDD is produced by the communication system supplier to describe the detailed design of the communication system consistent with the architecture described in the CSADD. It describes the detailed design of each of the major communication system components identified in the CSADD.

The CSDDD is produced for the CDR, and its acceptance at the CDR by the communication system customer implies a commitment to proceed with the implementation of the system according to that detailed design.

As specified in ECSS-E-ST-50, the CSDDD is frozen after acceptance at the CDR.

The communication system detailed design document describes the detailed design of the communication system, and derives from the CSBD (see ECSS-E-ST-50 Annex B) and CSADD (see ECSS-E-ST-50 Annex E). Specific detailed tests for the components described in the communication system detailed design document are further described in the CSVP (see ECSS-E-ST-50 Annex D). Any specific analysis activities to justify the detailed design are contained in the CSAD (see ECSS-E-ST-50 Annex C).

As specified in ECSS-E-ST-50, the implementation or procurement of all of the communication system components is based on the communication system detailed design document.

Expected response

Scope and content

Introduction

The CSDDD shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Applicable and reference documents

The CSDDD shall list the applicable and reference documents in support to the generation of the document.
Mission description and communication system overview

The CSDDD shall describe the main objectives and characteristics of the space mission.
The CSDDD shall describe the architectural design contained in the CSADD.
Communication system detailed design

The CSDDD shall contain the detailed design of the communication system, with all critical detailed design decision justifications, including:

the requirements applicable to each of the major components of the communication system identified in the CSADD,
the detailed design of each major component of the communication system,
a justification of all design decisions relating to the detailed design of each component, and
a complete description of all of the interfaces to each component. ICDs of the major components

The CSDDD shall include the ICDs for each of the major components of the communication system.

Special remarks

This DRD imposes no constraints on the tools used to elaborate the detailed design, and some elements of the detailed design, that can only be viewed with the aid of the tools used in the elaboration of the design, may be accepted.

ANNEX(normative)Communication system profile document (CSPD) - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-50, requirements 5.2.3.3a and 5.2.5.3a.

Purpose and objective

The communication system profile document (CSPD) defines the frequencies, protocols and protocol options, address assignments, channel assignments, spacecraft identifier assignments, space link bandwidth allocations, and onboard bus bandwidth allocations used in the communication system, and constitutes a formal statement of compliance of the communication system to ECSS-E-ST-50.

The CSPD is produced by the communication system supplier as a formal statement of the compliance of the communication system to the ECSS-E-ST-50 requirements. The communication system profile document describes the frequencies, protocols and protocol options, address assignments, channel assignments, spacecraft identifier assignments, space link bandwidth allocations, and onboard bus bandwidth allocations used in the communication system.

As specified in ECSS-E-ST-50, the final version of the communication system profile document is available at FRR. Earlier versions can be produced for other reviews.

The communication system profile document describes the frequencies, protocols and protocol options, address assignments, channel assignments, spacecraft identifier assignments, spacelink bandwidth allocations, and onboard bus bandwidth allocations used in the communication system. This is a formal statement of compliance of the communication system to ECSSEST50 and can be used for the establishment of interoperability agreements involving the communication system.

Expected response

Scope and content

Introduction

The CSPD shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Applicable and reference documents

The CSPD shall list the applicable and reference documents in support to the generation of the document.
Mission description and communication system overview

The CSPD shall describe the main objectives and characteristics of the space mission, and
The CSPD shall describe the communication system to which this profile document relates.
Communication system profile

The CSPD shall consist of all tables, matrices, compliance statements, and compliance proformas to fully describe the characteristics of the communication system.

This DRD imposes no constraints on the way in which this information is presented. Generally, any standard protocols that are used can be defined by the compliance proforma associated with that protocol. For other, mission specific characteristics such as the spacecraft identifier values, spacelink frequencies, channel allocations, and address assignments, it is good practice that an appropriate mission proforma is defined early in the programme and populated as the values become known.

Special remarks

None.

ANNEX(normative)Communication system operations manual (CSOM) - DRD

DRD identification

Requirement identification and source document

This DRD is called from ECSS-E-ST-50, requirement 5.2.3.3d.

Purpose and objective

The communication system operations manual (CSOM) formally describes all procedures for the operation of the communication system. The operational procedures include normal and contingency operations. Normal operations include procedures for spacecraft signal acquisition, loss of signal, and handover, as well as communication system management activities such as address initialization and router configuration and maintenance. Contingency operations cover unidirectional space link (uplink only, downlink only), unexpected loss of signal, and discontinuous signal.

The CSOM is produced by the communication system supplier to describe the operations procedures for normal and contingency operation of the communication system.

As specified in ECSS-E-ST-50, the final version of the communication system operations manual is available for FRR. Earlier versions can be prepared for other reviews.

The communication system operations manual constitutes the user manual for the communication system. It is used in the development of the overall space mission operations procedures, and can be relevant to the definition of the onboard software.

Expected response

Scope and content

Introduction

The CSOM shall contain a description of the purpose, objective, content and the reason prompting its preparation.
Applicable and reference documents

The CSOM shall list the applicable and reference documents in support to the generation of the document.
Mission description and communication system overview

The CSOM shall briefly describe:

the main objectives and characteristics of the space mission, and
the communication system implementation. Communication systems operations

The CSOM shall describe the procedures used to commission the communication system during the early phases of the mission;
The CSOM shall describe the communication system test procedures used to verify the correct operation of the communication system during the mission;
The CSOM shall describe all of the routine operations procedures that are used during the mission, i.e. once the communication system is commissioned and operating normally;
The CSOM should include any procedure for the communication system reconfiguration that can be expected during the mission, such as the switchover to a redundant communication chain, or the update of onboard routing tables;
The CSOM shall describe the contingency operations procedures to be used during abnormal operating conditions, e.g. when failures occur in the communication system.
Decommissioning procedure

This CSOM shall describe the procedures used to decommission the communication system at the end of the mission.
Additional operating procedures

The CSOM shall describe any operating procedures applicable to the communication system not described in items H.2.1<4> and <5>.

For example, these can include procedures to extend the capability of the communication system during the mission, e.g. by adding spacecraft to an existing constellation.

ANNEX(informative) Documentation summary

A-A-

Table A- 1 identifies the list of the document requirements definitions (DRDs) associated with this Standard.

TableTable A- 1 ECSS-E-ST-50 DRD list

DRD Id	DRD Title	DRD summary content	Applicable to (phase)	Delivered	Remarks
ECSS-E-ST-50 Annex A	Communication system requirements document (CSRD)	Formally describes the requirements from the customer on the spacecraft communication system. Covers ground network, space link, and space network requirements, design, development, and operation.	Requirement engineering	SRR
ECSS-E-ST-50 Annex B	Communication system baseline definition (CSBD)	Formal response to the CSRD that constitutes the technical baseline for the design and implementation of the spacecraft communication system. Includes a compliance matrix with the CSRD and any derived requirements. Documents any major assumptions and constraints and noncompliances.	Analysis	PDR
ECSS-E-ST-50 Annex C	Communication system analysis document (CSAD)	Contains a full technical analysis of the communication system leading to the selection of frequencies, protocols, protocol options, redundancy strategy, and operational concept.	Analysis	PDR
ECSS-E-ST-50 Annex D	Communication system verification plan (CSVP)	Describes the verification test plan for the spacecraft communication system. Plan covers tests carried out during verification phase and tests that may be used during operations.	Analysis, verification	PDR
ECSS-E-ST-50 Annex E	Communication system architectural design document (CSADD)	Describes the architectural design of the spacecraft communication system and shows the relationships between the communication system and other mission systems.	Design and configuration	PDR
ECSS-E-ST-50 Annex F	Communication system detailed design document (CSDDD)	Describes the detailed design of the spacecraft communication system.	Design and configuration	CDR
ECSS-E-ST-50 Annex G	Communication system profile document (CSPD)	Documents the communication system profile, including frequency assignments, protocol selection, protocol options, address assignments, channel assignments, spacecraft identifier assignments, spacelink bandwidth allocations, and onboard bus bandwidth allocations for TM and TC.	Design and configuration	CDR	a. The CSPD constitutes the formal statement of compliance to ECSS-E-50. b. Level 3 ECSS standards applied to the communication system have their own profile documents.
ECSS-E-ST-50 Annex H	Communication system operations manual (CSOM)	Formally describes all procedures for the operation of the spacecraft communication system. Covers normal and contingency operations. Normal operations include procedures such as spacecraft signal acquisition, loss of signal, and handover, as well as communication system management activities such as address initialization and router configuration and maintenance. Contingency operations cover unidirectional communications (uplink only, downlink only) and unexpected loss and discontinuous signal.	Analysis	PDR

Bibliography

ECSS-S-ST-00	ECSS system – Description, implementation and general requirements
ECSS-E-ST-10	Space engineering – System engineering general requirements
ECSS-E-HB-10	Space engineering – System engineering guidelines
ECSS-E-ST-10-02	Space engineering – Verification
ECSS-E-ST-20	Space engineering – Electrical and electronic
ECSS-E-ST-40	Space engineering – Software general requirements
ECSS-E-HB-50	Space engineering – Communications guidelines
ECSS-E-ST-50-01	Space engineering – Space data links – Telemetry synchronization and channel coding
ECSS-E-ST-50-04	Space engineering – Space data links – Telecommand protocols, synchronization and channel coding
ECSS-E-ST-50-05	Space engineering – Radio frequency and modulation
ECSS-E-ST-70	Space engineering – Ground systems and operations
ECSS-M-ST-10	Space project management – Project planning and implementation
ECSS-M-ST-40	Space project management – Configuration and information management
ISO 7498:1984	ISO Information processing systems – Open systems interconnection — Basic reference model
ISO 12172:2003	Space data and information transfer systems – Telecommand - Data routing service
ISO 12173:2003	Space data and information transfer systems – Telecommand – Command operation procedures
ISO 12174:2003	Space data and information transfer systems – Telecommand – Data management service – Architectural specification

Space engineering

Communications

Change log

Introduction

Scope

Normative references

Terms, definitions and abbreviated terms

Terms defined in other standards

Terms specific to the present standard

Abbreviated terms

Space communications engineering principles

Context

Overall space communication

Space communication domains

Overview

Space network

Space link

Ground network

Communications engineering process

Introduction

Communication engineering activities

Overview

Communications engineering management

Requirement engineering

Analysis

Design and configuration

Implementation

Verification

Operations

Process milestones

Relationship with other standards

Communications architecture

Spacecraft control considerations

Requirements

Introduction

Space communication system engineering process

Requirements engineering

Overview

Activities

Outputs

Analysis

Overview

Activities

Outputs

Design and configuration

Overview

Activities

Outputs

Implementation

Overview

Activities

Outputs

Verification

Overview

Activities

Outputs

Operations

Overview

Activities

Outputs

Space communication system

Bandwidth allocation

Congestion

Cessation of emission

Telecommanding

Commandability at all attitudes and rates

Telecommand delivery service

Erroneous telecommand rejection

Essential command distribution

Command authentication

Command encryption

Commanding­in­the­blind

Telecommand acknowledgement

Telemetry

Telemetry at all attitudes and rates

Essential telemetry acquisition

Telemetry source identification

Telemetry­in­the­blind

Telemetry packet time stamping

Simultaneous support of differing source rates

Commandingintheblind

Telemetryintheblind