General

JERG-2-400 A

DESIGN STANDARD
COMMUNICATIONSMar 29, 2013

RevA

Japan Aerospace Exploration Agency

JERG-2-400 A

This is an English translation of JERG-2-400A.

Whenever there is anything ambiguous inthis document, the original document (the Japanese version) shall be used to clarify theintent of the requirement.

Disclaimer
The information contained herein is for general informational purposes only.

JAXA makes

no warranty, express or implied, including as to the accuracy, usefulness or timeliness of any
information herein.

JAXA will not be liable for any losses relating to the use of theinformation.

Published by
Japan Aerospace Exploration Agency
Safety and Mission Assurance Department
2-1-1 Sengen Tsukuba-shi,Ibaraki 305-8505, Japani

JERG-2-400 A

Contents
1.

SCOPE ............................................................................................................................ 1

2.

RELATED DOCUMENTS ................................................................................................. 2
2.1

Applicable documents ........................................................................................... 2
2.1.1

CCSDS Recommendations ........................................................................... 2

2.1.2 JAXA documents ........................................................................................... 3
2.2
3.

4.

References .......................................................................................................... 3

DEFINITIONS OF TERMS AND ABBREVIATIONS .......................................................... 4
3.1

Definitions of terms .............................................................................................. 4

3.2

Abbreviations ....................................................................................................... 8

COMMUNICATIONS OVERVIEW .................................................................................... 9
4.1

Background .......................................................................................................... 9

4.2

Architecture ......................................................................................................... 11
4.2.1 Space communication system ...................................................................... 11
4.2.2

Ground subnetwork ..................................................................................... 12

4.2.3 Space link subnetwork ................................................................................. 12
4.2.4 Onboard subnetwork ................................................................................... 13
4.2.5 Protocol architecture .................................................................................... 13
5.

REQUIREWMENTS ....................................................................................................... 16
5.1

General requirements .......................................................................................... 16

5.2Standard protocol ................................................................................................ 16

5.3

Ground subnetwork protocol ................................................................................ 17

5.4

Space link subnetwork protocol ............................................................................ 18
5.4.1 Physical layer .............................................................................................. 19
5.4.2 Telecommand synchronization and channel coding sublayer ....................... 19
5.4.3

Telecommand data link protocol sublayer .................................................... 19

5.4.4 Telemetry synchronization and channel coding sublayer ............................. 20
5.4.5 Telemetry data link protocol sublayer ........................................................... 20
5.5

Onboard subnetwork protocol .............................................................................. 21
5.5.1 Protocol architecture .................................................................................... 21
5.5.2 Data link ...................................................................................................... 22
5.5.3 Service ........................................................................................................ 22

5.6

End-to-end protocol ............................................................................................. 23ii

JERG-2-400 A

1 6. VERIFICATION REQUIREMENTS ................................................................................. 24
6.1

Verification types and purpose ............................................................................. 24

6.2

Subsystem/payload compatibility test ................................................................... 24
6.3

6.4

RF compatibility test ....................................................................................... 25

End-to-end test ................................................................................................... 26iii

JERG-2-400 A

1.

SCOPE
This Communications Design Standard (called the “Design Standard” hereinafter)

specifies the basic requirements for communications design for remote informationtransmission by an end-to-end space communication system.
Information-related requirements are specified by other standards (JERG-2-700
Operation Design Standard) and are not treated in this standard.

1

JERG-2-400 A

2. RELATED DOCUMENTS
2.1

Applicable documents
The documents below are applied within the scope referred to in this Design Standard and,if there is a discrepancy, this Design Standard has priority unless otherwise specified.
2.1.1 CCSDS Recommendations(1)

CCSDS 131.0-B-2 (Issue 2. August 2011)
TM Synchronization and Channel Coding(2)

CCSDS 133.0-B-1 (Issue 1. September 2003)
Space Packet Protocol(3)

CCSDS 135.0-B-4 (Issue 4. October 2009)
Space Link Identifiers(4)

CCSDS 231.0-B-2 (Issue 2. September 2010)
TC Synchronization and Channel Coding(5)

CCSDS 232.0-B-2 (Issue 2. September 2010)
TC Space Data Link Protocol(6)

CCSDS 232.1-B-2 (Issue 2. September 2010)
Communications Operation Procedure-1(7)

CCSDS 401.0-B-21 (Issue 21. July 2011)
Radio Frequency and Modulation Systems – Part 1: Earth Stations and Spacecraft(8)

CCSDS 732.0-B-2 (Issue 2. July 2006)
AOS Space Data Link Protocol(9)

CCSDS 910.4-B-2 (Issue 2. October 2005)
Cross Support Reference Model – Part 1: Space Link Extension Service(10) CCSDS 911.1-B-3 (Issue 3. January 2010)
Space Link Extension – Return All Frames Service Specification(11) CCSDS 911.5-B-2 (Issue 2. January 2010)
Space Link Extension – Return Operational Control Fields Service Specification(12) CCSDS 912.1-B-3 (Issue 3. July 2010)
Space Link Extension – Forward and CLTU Service Specification

2

JERG-2-400 A

2.1.2
(1)

JAXA documents
JERG-2-420
RF Telecommunications Link Design Standard(2)

MAS-120001 NC
Tracking Control System Telemetry and Telecommand Interface Conditions(3)

OSO 500-1.1
DIOSA Interface Specification: Space Data Transfer Protocol (SDTP) (Common
specifications)(4)

OSO 501-3.1
DIOSA Interface Specification: Space Data Transfer Protocol (SDTP) (Individual

specifications)

2.2

References(1)

JERG-2-700
Spacecraft Operation Design Standard

3

JERG-2-400 A

3.

DEFINITIONS OF TERMS AND ABBREVIATIONS

3.1 Definitions of terms
The definitions of terms related to this Design Standard are shown below.
(1) ARQ (Automatic Repeat reQuest)
A mechanism that, when the receiving side detects a transmission error, automaticallyrequests the sender to retransmit.
(2) HK (housekeeping) data
Data indicating the condition or status of onboard equipment (payload andsubsystem).
(3) Architecture
The term architecture used in this Design Standard refers to the design concept or
configuration of space communication systems.
(4) Internet protocol
At present, the protocol to connect multiple networks is the TCP/IP protocol suite as ade facto standard. As such, the term “Internet protocol” is generally referred to as IPof the TCP/IP protocol suite.
In this Design Standard, the Internet protocol means IP (Internet Protocol) of the
TCP/IP protocol suite.
(5) End-to-end protocol
The protocol, used for space communications, to connect multiple networks (onboard
subnetwork, space link subnetwork, and ground subnetwork) including the spacecraft
network.
The ground subnetwork takes a configuration in which an end-to-end protocol exists
on top of IP of the TCP/IP protocol suite.
In this Design Standard, the protocol applied as an end-to-end protocol is the CCSDS
space packet protocol.
(6) Octet
A unit of data length. A data set separated by 8 bits is called “octet” (8 bits × N data
is N data octets). The minimum data transmission unit in this Design Standard is 1
octet.
(7) Onboard data link
The interface used in onboard subnetworks and serving the functions of the bottom
two layers of the OSI reference model. Includes MIL-STD-1553B, SpaceWire, etc.

4

JERG-2-400 A(8) Command
The instruction to a spacecraft.
(9) Service
The functionality of a certain layer (N layer) and the layers below it, provided to the(N+1) layer at the boundary between that layer (N layer) and the (N+1) layer.
(10) Subnetwork
An open system that has the relay function and can establish a network connection.
A space communication system consists of the three subnetworks of onboard
subnetwork, space link subnetwork and ground subnetwork.
(11) Simplex
One-way communication from a data source (data transmission source) to data
destination (data transmission target).
(12) Time stamp
Time data added to the information to indicate the time of occurrence of theinformation. A telemetry packet adds the time of occurrence of the packet in thesecondary header.
(13) Channel coding
Refers to the data sending side adding an error detection code or an error correction
code to the information and the receiving side doing transmission error detection andcorrection in order to ensure data transmission quality against the noise on thetransmission line
(14) Telecommandtele (telecommunication) + command. Telecommunication of commands (from theground to a spacecraft)(15) Telemetry
tele (telecommunication + metry (measurement). Telecommunication (from aspacecraft to the ground) of metry. Metry means measurement and refers to HK dataand payload data.
(16) Network
Refers to a computer network.
(17) Node
Refers to the node making up a network. In a space communication system, thiscorresponds to the payload, subsystems, onboard communications and dataprocessing system, ground station facilities, and ground users.
(18) Packet
The Packet used in this Design Standard refers to Space Packet defined by theapplicable document CCSDS Recommendation (2). It is not an ISO packet. Space
Packet is the minimum transmission data unit (variable length) flowing through thespace communication system. This Design Standard uses Packet and Space Packet
as synonyms.

5

JERG-2-400 A(19) Protocol
Refers to a set of procedures, conventions, etc. to transmit data on a network.
(20) Payload
Refers to the equipment on board the spacecraft that is necessary for a specificpurpose (observation instrument, space experiment apparatus, communicationequipment, etc.).
(21) Payload data
Refers to the measurement data, experiment data, etc. acquired by the payload.
(22) Point-to-point
Refers to communications from one sender to one recipient.
(23) Point-to-multipoint
Refers to communications from one sender to N recipients.
(24) Randomization
For the data receiving side to surely acquire and keep bit synchronization, the data ismodulated by a PN (Pseudo Noise) code (spread spectrum code having the nature ofnoise) to ensure the necessary Bit Transition Density (a sequence of alternating ones
and zeros gives the maximum transition density).
(25) Spacecraft operation control
Refers to the function of monitoring and controlling a spacecraft (Spacecraft Monitor &Control)(26) Space communication system
Refers to the network made up of multiple subnetworks present between thespacecraft end-user and ground end-user (apparently one network).
(27) Error detection
Refers to the sending side adding an error detection code to the information and thereceiving side detecting a transmission error occurring on the transmission line. If atransmission error is detected, a request for re-transmission is made to the sending
side. Used for telecommand.
(28) Error correction
Refers to the sending side adding an error correction code to the information and thereceiving side correcting transmission errors occurring on the transmission line. Usedfor telemetry.
(29) Mutual support (cross support)
Refers to the interconnection between different space agencies. Refer to theapplicable document CCSDS (9).
(30) Ground node
Refers to the computer and hardware entities present on the ground and mutually

6

JERG-2-400 A

connected by standard communications protocols.
(31) Communications
Communications used in this Design Standard refers to the mechanism to transmit
telemetries and telecommands.
(32) Onboard node
Refers to the computer and hardware entities present in a spacecraft and mutuallyconnected by standard communications protocols.
(33) Logical data path
Refers to the logical path for space packets from one application source to one or
multiple application destinations via one or multiple subnetworks. Refer to theapplicable document CCSDS Recommendation (2).

7

JERG-2-400 A

3.2

Abbreviations
The abbreviations related to this Design Standard are shown below.
AOS
ARQ
CCSDS
CLCW
CLTU
COP
CPU
CRC
DIOSA
EMC
HK
ID
IETF
ISO
JAXA
LAN
LDPC
MOD
OCF
OSI
PLOP
RAF
RF
RFC
SDTP
SDU
SEC
SLE
SM&C
SOIS
TC
TCP/IP
TED
TM
VCID
WAN

Advanced Orbiting Systems
Automatic Repeat Request
Consultative Committee for Space Data Systems
Communications Link Control Word
Communications Link Transmission Unit
Communications Operation Procedure
Central Processing Unit
Cyclic Redundancy Check
Distributed Operations System Architecture
Electro-Magnetic Compatibility
House Keeping
Identification
Internet Engineering Task Force
International Organization for Standardization
Japan Aerospace Exploration Agency
Local Area Network
Low Density Parity Check
Moduration
Operationnal Control Field
Open System Interconnection
Physical Layer Operations Procedure
Return All Frames
Radio Frequency
Request for Comment
Space Data Transfer Protocol
Service Data Unit
Single Error Correction
Space Link Extension
Spacecraft Monitor and Control Protocol
Spacecraft Onboard Interface Services
Telecommand
Transmission Control Protocol/Internet Protocol
Triple Error Detection
Telemetry
Virtual Channel Identification
Wide Area Network

8

JERG-2-400 A

4.

COMMUNICATIONS OVERVIEW

4.1

Background
Communications means remote transmission of information between a ground end-userand spacecraft end-user (end-to-end).
Information is the commands and HK data for spacecraft operation control, and payload
dada obtained by the payload. Remote transmission of a command is called “Telecommand”
and remote transmission of HK data and payload data is called “Telemetry”.
Besides these, spacecraft time calibration information for the ground side to exactly know
the spacecraft time is also transmitted. This is classified as a Telecommand or Telemetry
from the viewpoint of transmission.
Requirements for Telecommand and for Telemetry are different.
For Telecommand, no transmission error is basically allowed for the purpose oftransmitting a command. Therefore, it is general practice that the receiving side (spacecraft)
does error detection and makes a repeat request to the sending side (ground side) if an error
is detected. In addition, it is also required to surely keep the transmission sequence.
Because Telemetry involves transmission of HK data and payload data, it is given priority
to transmit a large amount of data. Therefore, it is general practice that the receiving side
(ground side) does error correction only.

Telecommand and Telemetry formerly used the multiplex method of TDM (Time Division
Multiplex); however, technical limitations and increases in time and cost of development,
operation, maintenance, etc. gave rise to an issue common to the space agencies of theworld. At present, the packet method recommended by CCSDS (Consultative Committee forSpace Data Systems) inaugurated in 1982 is used by space agencies, etc. of the world. The
CCSDS recommendations are all the international standards established as an ISO(International Organization for Standardization) standard.
The space communications according to the CCSDS recommendations is an extension toouter space of the OSI (Open System Interconnection) reference model which makes thebase of the protocol established in 1977 by ISO to connect multiple networks. Figure 4.1-1
shows the layers of the OSI reference model and the layers of CCSDS spacecommunications. JAXA uses only space packets for end-to-end communications and does
not use the application layer and transport layer. The recommendation defines the services ofeach layer and specifies their protocol.
The CCSDS Space Communications Recommendation consists of the three subnetworks(onboard subnetwork, space link subnetwork, and ground subnetwork) between the ground9

JERG-2-400 A

and a spacecraft and the end-to-end protocol to connect them each other.
Layers of OSI reference model

Layers of CCSDS

7th layer

Application Layer

6th layer

Presentation Layer

5th layer

Session Layer

4th layer

Transport Layer

3rd layer

Network Layer

Network Layer

2nd layer

Data Link Layer

Data Link Layer

1st layer

Physical Layer

Physical Layer

Application Layer

Transport Layer

Data Link Protocol Sublayer

Figure 4.1-1

Sync.
and
Sublayer

ChannelCodingLayers of OSI Reference Model and CCSDS Recommendation for Space Communications

Besides this, there are the SLE (Space Link Extension) recommendation for mutually
supporting and connecting ground facilities and the SOIS (Spacecraft Onboard Interface
Services) specifying the services of onboard subnetworks.
JAXA has so far developed spacecraft according to the CCSDS recommendations.

Including the above, communications standardization takes place to realize the following.
 For the communications user, onboard equipment, test equipment, written procedures,
ground facilities, etc. can be used in the same way even for a different spacecraft (costand time saving).
 By forming a logical data path between the ground end-user and spacecraft end-user,
the user of the communications can transmit data whenever he wants without being
affected by other users.
 Mutual support (cross support) is possible (expansion of the network, support at an
emergency of the spacecraft, etc., and cost and time saving in coordination work).
 Ensuring availability, ensuring reliability and safety, and considering costeffectiveness.

10

JERG-2-400 A

4.2

Architecture

4.2.1 Space communication system
The general configuration (major communication nodes and connections) of a spacecommunication system is shown in Figures 4.2.1-1 and 4.2.1-2. Figure 4.2.1-1 is aconfiguration diagram focusing on the physical configuration and Figure 4.2.1-2 is aconfiguration diagram focusing on the network.

Space communication system
PayloadSubsystem

Payload data processing, analysis,storage, delivery, etc

Onboardcommunications
and data
handling system

Groundstation facility
Onboardsubnetwork

Spacecraft
operation
control

Spacecraft-acquired
data

Payloadoperation
control

Space link
subnetwork

Ground subnetwork: Major communication node

Figure 4.2.1-1

General configuration focusing on physical configuration

Note 1

Space communication system
Space segment

Ground segment
Note 2

Onboardsubnetwork

RepeaterSpace link
subnetwork

Repeater

Ground subnetwork(Ground station facility)

Onboard communications
and data handling system

Ground network

Note 1: One network formed by multiple subnetworks connected by an end-to-end protocol.
Note 2: The ground subnetwork is an Internet network formed by multiple ground networks connected by an Internet
protocol.

Figure 4.2.1-2General configuration focusing on network

Space communications consist of many different networks which can be classified into
ground network, ground-spacecraft network and spacecraft network as shown in Figure
4.2.1-1. Each network classified is a subnetwork.

11

JERG-2-400 A(1) Ground subnetwork:

Connection between ground nodes such as a ground station
facility, spacecraft operation control, payload operation control,
payload data processing, user institute, etc.

(2) Space link subnetwork: Connection between ground node and spacecraft node.
(3) Onboard subnetwork: Connection between onboard nodes such as an onboard
communications and data processing system, payload, andsubsystem.
These three different subnetworks are connected by an end-to-end protocol to make one
network. This network is called a space communication system.

4.2.2

Ground subnetwork

The ground subnetwork is a network with nodes of communications for operation controlof the spacecraft, operation control of the payload, processing of data acquired by the
payload (data processing, analysis, archiving, delivery, etc.) and the user institute. One nodeon this network is a ground station (repeater).
A ground subnetwork generally consists of multiple different networks. These multiple
different networks are generally connected by IP of the TCP/IP protocol suite.
On this ground subnetwork, an end-to-end protocol functions.
In addition, a ground subnetwork needs a standard protocol (SLE, etc.) for efficienttransmission and reception of packets, etc. between nodes in the ground subnetwork.

4.2.3 Space link subnetwork
The link to connect a repeater (ground station facility) of the ground subnetwork and anode repeater (onboard communications and data processing system) of the onboard
subnetwork.
This link is a radio link made of two simplexes (transmission from spacecraft to groundand transmission from ground to spacecraft). The radio link from a spacecraft to the ground iscalled a downlink (or a return link), and the radio link from the ground to a spacecraft is called
an uplink (or a forward link). A downlink transmits telemetries and an uplink transmits
telecommands. The reason for taking simplexes is there is the need to monitor the satellite
even if there is no uplink and there is the need to transmit commands even if there is no12

JERG-2-400 A

downlink.
Telecommand transmission has ARQ (automatic repeat request) or another mechanism tomaintain data integrity; however, a repeat request is transmitted through another simplex(downlink). In preparation for spacecraft or link abnormalities, the telecommand transmission
must be able to take place even if there is no downlink (ARQ not available), and this is arequirement.
Connection takes place in the form of point-to-point or point to multipoint.
There are cases where a relay satellite intervenes between the ground station facility andthe onboard communications and data processing system. In such a case, the relay satellite
functions as a repeater (signal regeneration or relay supported only by the physical layer).
Because the space link subnetwork is a radio link of great distance, its link quality is
inferior to a ground subnetwork or onboard subnetwork. Therefore, it needs a special channel
coding or transmission procedure.

4.2.4 Onboard subnetwork
The onboard subnetwork is a network within the spacecraft with its subsystems andpayload being nodes of communications. One node on this network is the onboard
communications and data processing system (repeater).
The number of onboard subnetworks is not limited to one either, and there are cases
where a subnetwork is in turn made up of multiple subnetworks. If there are multiple
subnetworks, they are connected by repeaters.

4.2.5 Protocol architecture
As shown in Figure 4.2.6-1, a space communication system is made up nodes connectedby a standard protocol.

13

JERG-2-400 A

Grou ndSpacecraft

Ground node

Onboard nodeStandard
communications
protocolOnboardsubnetwork

Standard
communications
protocol

Relay

Relay
Onboardcommunications anddata handling system

Groundstation facility
Space link
subnetwork Standard

Standard
communications
sprotocol

Groundsubnetwork

communications
protocolGround node
Onboard nodeStandard
communications
protocolStandard
communications
protocolGround nodeStandard
communications
protocolFigure 4.2.6-1

Space Communication System Architecture

If modeled, Figure 4.2.6-1 can be represented by four nodes as shown in Figure 4.2.6-2.

Space segment

Onboardend system(Payload/system)

Onboardsubnetwork

GroundOnboardrelay system

Groundrelay system

Groundsubnetwork

Space link
subnetwork(Ground station facility)(Onboard communications
and data handling system)

Figure 4.2.6-2

Groundend system(Ground user)

Model of Space Communication System

Figure 4.2.6-2, if described based on communications protocols according to the OSI
reference model, becomes a diagram as shown in Figure 4.2.6-3.
In Figure 4.2.6-3, the higher protocol is for operation (Spacecraft Monitor and Control
Protocol: SM&C), and it is specified in reference document (1).
This Communications Design Standard provides the following four standard protocols asshown in Figure 4.2.6-3.
 Ground subnetwork protocol
 Space link subnetwork protocol
 Onboard subnetwork protocol
 End-to-end protocol

14

JERG-2-400 A

Payload/subsystem(Onboard node)

Onboardcommunications anddata handling system(Onboard node)

Groundstation facility(Ground node)

Ground user
(Ground node)User
application

User
application
CCSDS Layer

Network
Layer
Data
Link
Physical
Layer

Onboardsubnetwork
protocolEnd-to-end
protocol(Relay)End-to-end
protocol(Relay)End-to-end
protocolOnboardsubnetwork
protocolSpace link
subnetwork
protocolSpace link
subnetwork
protocolGroundsubnetwork
protocolEnd-to-end
protocolGroundsubnetwork
protocolScope of Communications Design Standard: Communication node

Figure 4.2.6-3: Protocol entity

Communications Protocol Architecture of Space Communication System

15

JERG-2-400 A

5.

REQUIREWMENTS

5.1 General requirements(1) Considering a spacecraft attitude abnormality and other kind of abnormality, thetelemetry and telecommand transmission shall be ensured the required transmission
link quality.
(2) Transmitted data includes the event trigger type (command, upload/download data,etc.) and the time trigger type (HK data, etc.). It shall be transmitted these data withhigh efficiency.
(3) A telemetry packet generated in the spacecraft shall have a time stamp of the dataacquisition time.
(4) A telemetry link and command link are not always established. At an occurrence of aspacecraft abnormality, etc., the communications shall take place even with either linkalone.
(5) If so required, it shall be possible to change over the type or frequency of occurrenceof telemetry to be transmitted or accumulate telemetry data and transmit such data
afterwards according to the operation mode or communications link condition.

5.2

Standard protocol
The protocols to be applied in this Communications Design Standard are shown in
Table 5.2-1.

16

JERG-2-400 A

Table 5.2-1 Standard Protocol
ProtocolSpecification name
TCP/IP protocol suite
H-II Protocol

Groundsubnetwork
protocolSpace Data Transfer Protocol (SDTP)

Specification number
RFC of IETF.
Note 1
MAS-120001
Note
DIOSA OSO500-1.1
2

Space link
subnetwork
protocolOnboardsubnetwork
protocolEnd-to-end

DIOSA OSO501-3.1

Note

3

CCSDS910.4-B
CCSDS 911.1-B
Space Link Extension (SLE)CCSDS 911.5-B
CCSDS 912.1-B
TC Space Data Link Protocol
CCSDS 232.0-B
TC Communications Operation Procedure-1 (COP-1) CCSDS 232.1-B
TC Sync. and Channel Coding
CCSDS 231.0-B
AOS Space Data Link Protocol
CCSDS 732.0-B
TM
TM Sync. and Channel Coding
CCSDS 131.0-B
RF and Modulation
CCSDS 401.0-B
RF RF Communication System Design Standard
JERG-2-410
RF Link Design Standard
JERG-2-420

TBD

JERG-2-430s

Space Packet Protocol

CCSDS 133.0-B

IETF: Internet Engineering Task Force. RFC: Request for Comment
Note 1: Applicable document 2.1.2(3)Note 2: Applicable document 2.1.2(4)Note 3: Applicable document 2.1.2(5)5.3Ground subnetwork protocol(1) The standard protocols used in a ground subnetwork are shown in Figure 5.3-1. To the
networks on the ground, an end-to-end protocol for end-to-end connection between
the ground and a spacecraft is applied on the Internet protocols (TCP/IP protocol
suite) for connection between ground networks. In addition to these two protocols, theSLE (Space Link Extension) recommendations of CCSDS (applicable documents:
CCSDS recommendations (9) to (12)) are applied as a protocol for mutual support(cross support) when sending and receiving packets or frames between groundinstitutes.
(2) In regard to application of the SLE recommendation: Before SLE recommendation wasestablished, JAXA had developed and used JAXA-specific H-II protocol (applicable
document: JAXA document (3)) and SDTP (Space Data Transfer Protocol) (applicable
document: JAXA documents (4) and (5)). To the connection with other institutes, theSLE recommendation is applied as standard; however, between pieces of equipment

17

JERG-2-400 A

within JAXA, the H-II protocol and SDTP are also JAXA standard.
(3) When applying the SLE recommendation of CCSD, it shall be applied the RAF service
to the telemetry transfer service and the CLTU service to the TeleCommand transfer
service.
Ground end-user(Ground node)
Ground station facility(Ground node)Higher protocol

CCSDS Layer
Network
Layer
Data Link
Layer
andPhysical
Layer

End-to-end protocol

End-to-end protocol
Ground subnetwork• Space Data Transfer Protocol (SDTP) or• H-II Protocol or• Space Link Extension (SLE)

Ground subnetwork• Space Data Transfer Protocol (SDTP) or• H-IIProtocol or• Space Link Extension (SLE)

TCP/IP protocol suite

TCP/IP protocol suite

LAN, WAN, etc. (out of the scope of
this Design Standard)

LAN, WAN, etc. (out of the scope of
this Design Standard): Protocol entity: Communication node

Figure 5.3-1 Architecture and Standard Protocols of Ground Subnetwork

5.4

Space link subnetwork protocol
The standard protocols used on the space link subnetwork are shown in Figure 5.4-1.
Onboard communications anddata handling system(Onboard node)

Ground station
facility(Ground node)End-to-end protocol (relay)

End-to-end protocol (relay)

CCSDS Layer
Network
Layer

Data
Link
Layer

Data Link
Sublayer

Sync &
ChannelCodingSublayer

Physical
LayerSpace link subnetwork protocol

Space link subnetwork protocol•TC Space Data Link
Protocol (CCSDS)•COP-1 (CCSDS)•AOS Space Data Link
Protocol (CCSDS)•AOS Space Data Link
Protocol (CCSDS)•TC Sync. and Channel
Coding (CCSDS)•TM Sync. andChannel Coding

RF & MOD (CCSDS) or•TM Sync. and Channel
Coding (CCSDS)

RF Communications System
Design Standard (JAXA)
RF Link Design Standard (JAXA)

Telecommand: Communication node

•TC Space Data Link
Protocol (CCSDS)•COP-1 (CCSDS)•TC Sync. andChannel Coding

RF Communications System
RF & MOD (CCSDS) or Design Standard (JAXA)
RF Link Design Standard (JAXA)

Telemetry: Protocol entity

Figure 5.4-1 Architecture and Standard Protocols of Space Link Subnetwork

18

JERG-2-400 A

5.4.1 Physical layer(1) RF & Modulation (applicable document: CCSDS Recommendation (7)) of CCSDS, the
RF Communications System Design Standard (applicable document: JAXA document(1)) and the RF Link Design Standard (applicable document: JAXA document (1)) shallbe applied.

5.4.2 Telecommand synchronization and channel coding sublayer(1) CCSDS TC Sync. and Channel Coding (applicable document: CCSDS
Recommendation (4)) shall be applied.
(2) Multiple packets can be transmitted in one CLTU; however, note that the throughput
can lower when transmitting multiple packets per CLTU.
(3) As the decoding mode, the two modes shown in Table 5.4.2-1 are available. These
two modes differ in transmission quality (CLTU discard rate, undetected error rate andthroughput). For each spacecraft, it shall be made a selection based on the required
transmission quality.
Table 5.4.2-1 Decoding mode
Start sequence detection
BCH decoding
mode
mode
Decoding modeAll bit
1-bit error
TED
SEC
agreement
allowed
Error-Detecting----
Error Correcting----TED: Triple Error Detection SEC: Single Error Correction

Frame error control
(CRC)
No
Yes

(4) Whether or not to apply randomization depends on the bit synchronization
characteristics of the command receiver. In general, it is desirable to apply it.
(5) PLOP (Physical Layer Operations Procedure) includes PLOP1 and PLOP2. PLOP2
shall be used.

5.4.3

Telecommand data link protocol sublayer(1) The TC Space Data Link Protocol (applicable document: CCSDS Recommendation(5)) shall be applied.
(2) There are seven services. Apply them with an understanding of their use. Commonlyused services are the Virtual Channel Packet (VCP) service and COP Management
service.
(3) In case of the Error Correcting mode (Table 5.4.2.2-1), the frame error control (CRC)
shall be used (otherwise, undetected errors increase).
(4) VCID shall use 0 or 0 and 1 (in case of changing over the main and subordinate

19

JERG-2-400 A

systems) only.
(5) For the operation procedure, CCSDS Communications Operation Procedure-1(COP-1) (applicable document: CCSDS Recommendation (6)) shall be applied.

5.4.4

Telemetry synchronization and channel coding sublayer(1) TM Sync. and Channel Coding (applicable document: CCSDS Recommendation (1))
shall be applied.
(2) The transmission control code is generally used in the combinations shown in Figure
5.4.4-1. Different combinations differ in coding gain. For each spacecraft, make aselection based on the required coding gain.
(3) Whether or not to apply randomization depends on the bit synchronization
characteristics of the telemetry receiver. In general, it is desirable to apply it.
Outer code

Inner code

Reed-Solomon(E=16, I=1,2,3,4,5,8)

Pseudo-Random

Attached Sync Marker

For deep space(Link quality poor)

Turbo/LDPC

Pseudo-Random

Attached Sync Marker(for Turbo/LDPC)For near
communications(Link quality good)

Reed-Solomon(E=8, I=1,2,3,4,5,8)

Pseudo-Random

Attached Sync Marker

For generalspacecraft

Figure 5.4.4-1

5.4.5

Convolution

Punctured
Convolution

General code usage

Telemetry data link protocol sublayer(1) The AOS Space Data Link Protocol (applicable document: CCSDS Recommendation(8)) shall be applied.
(2) There are seven services. Apply them with an understanding of their use. Commonlyused services are the Packet service and Virtual Channel Operational Control Field(VC_OCF) service.
(3) When transmitting CLCW, CLCW shall be transmitted in VC_OCF (Presence ofOperational Control Field).

20

JERG-2-400 A

5.5

Onboard subnetwork protocol

5.5.1

Protocol architecture

The protocol architecture and the protocols of an onboard subnetwork are shown in
Figure 5.5-1.
Payload/subsystem

User application

CCSDS Layer
Network
Layer
Data Link
Layer

End-to-end protocol

Onboard subnetwork protocol
Packetservice

Memory accessservice

Synchronization
service

Device recovery
service

Test
serviceandData link convergence protocol

Physical
Layer

Data link (MIL-STD-1553B, SpaceWire, etc.): Communication node

: Protocol entity

Figure 5.5-1 Architecture of Onboard Subnetwork

A data link of an onboard subnetwork uses the protocol (for example, MIL-STD-1883B,
SpaceWire, etc.) with functions corresponding to the bottom two layers of the OSI reference
model.
An onboard subnetwork interfaces with an upper application with five standardized
services. (Note 1)
The data convergence protocol of an onboard subnetwork is the function for standardizing
the services for various data links. A data link is required of the six functions shown in Section
5.5.2; however, all protocols used for a data link do not necessarily provide these six
functions. If the protocol used lacks these functions, these are made up for by the data
convergence protocol. (Note 2)
Note 1: When an upper application is interfaced with a data link, it is influenced by the
protocol used for the data link. Therefore, a standard service independent of the
protocol used for the data link has been established.
Note 2: When implementing, the three independent standard protocols (service,21

JERG-2-400 A

convergence and data link) are not generally used in combination. A protocol forthe service (including the convergence function) exists corresponding to the data
link. The interface with an upper applicationis the same even for a different

data link.

5.5.2 Data link
The requirements for a data link are the following six functions. It is desirable that all data
links satisfy these six requirements.
(1) Redundant function: The function to transmit data from a source end point to a
destination end point in one network through a redundant transmission line. The
transmission lines in the main system shall be independent of the transmission lines inthe subordinate system.
(2) Retransmission function: The function of resending data if the transmitted data could
not reach the destination because of loss or a transmission error.
(3) Segmentation function: The function of the sending side dividing and transmitting thedata from an upper application and the receiving side joining and the divided data andtransmitting the joined data to the upper application. This function is used in thefollowing cases. (a) In the case where the data length of an upper application exceeds
the maximum data length that can be transmitted on the data link, and (b) in the casewhere long data transmission of an upper application causes an unnecessary delay inshort data transmission of another upper application.
(4) Traffic management: In general, one of the following. (a) without transmission bandassignment and with the retransmission function, (b) without transmission bandassignment and without the retransmission function, (c) with transmission bandassignment and without the retransmission function, and (d) with transmission bandassignment and with the retransmission function.
(5) Priority control: The function of transmitting high-priority data preferentially.
(6) Protocol multiplexing function: The function of multiple networks or an upper layer toaccess a service of a subnetwork layer by the protocol identification capability uniqueto the subnetwork.

5.5.3

Service

The services interfacing with an upper application are shown below.

22

JERG-2-400 A(1) Packet service: The packet service of an onboard subnetwork transfers packets (octet
data (data of a variable length of an integer multiple of 8 bits)) from an end point of theonboard subnetwork to another end point of the same onboard subnetwork.
(2) Memory access service: The memory access service of an onboard subnetwork reads
or writes data from or to a memory in a node of the onboard subnetwork.
(3) Synchronization service: The synchronization service of an onboard subnetwork
synchronizes the time commonly used in subnetworks.
(4) Device service: The device service of an onboard subnetwork notifies the users in the
onboard subnetwork of the presence of a device.
(5) Test service: The test service of an onboard subnetwork tests the functionality orconnectivity of the subnetwork.

5.6

End-to-end protocol(1) Apply the Space Packet Protocol (applicable document: CCSDS Recommendation(2)).
(2) Be sure to enter a time stamp indicating the data acquisition time in the secondary
header of the telemetry packet.
[For reference] Outline of Space Packet Service
The space packet protocol transmits space packets from one source user application to
one or more destination user applications by unidirectional data transmission through one
or more subnetworks. The path of this transmission is called “Logical Data Path (LDP)”
and the identifier of this path (Path ID) is called APID (Application Process Identifier).
(Figure 5.6-1)
SourceUser Application
Note 1

Destination
User Application

Logical Data Path
(LDP)

Contents
of packet

Note 2

Contents
of packet

Packet Extraction

Packet Assembly

End-to-End Protocol (Space Packet Protocol)
Network Layer

Data Link Layer
Physical Layer

Packet Transfer

Packet Relay

Onboard Subnetwork

Space Link Subnetwork

Note 1: Primary headed addition to packet
Note 2: Primary header removal from packet

1

Packet Relay

Ground Subnetwork

Packet Transfer Function: Multiplexing, Routing
Packet Relay Function: Storage, Routing
Packet Recovery Function: Demultiplexing

Figure 5.6-1 Space Packet Service

23

Packet Recovery

JERG-2-400 A

6. VERIFICATION REQUIREMENTS
6.1

Verification types and purpose
It is a matter of course to verify that the fabricated product conforms to the required

specifications (quality verification); here, a compatibility test to verify as a communication
system is specified.
As shown in Table 6.1-1, the compatibility test includes three types.

Table 6.1-1 Verification of Communication System
Test nameSubsystem/Payload
Compatibility Test
RF Compatibility Test
End-to-end Test

6.2

PurposeIn addition to verifying the onboard data bus
protocol, verify the compatibility of thesubsystems/payload with the various databasesof the operation control system.
Verify the compatibility of the physical interfaces
between the ground and spacecraft.
Data through test

Remarks

Subsystem/payload compatibility test
(1) The test system is shown in Figure 6.2-1.
(2) Verify the compatibility of the subsystem/payload with the onboard subnetwork
protocol and the upper protocol (for operation) of the spacecraft operation control
system (shown by the arrows in Figure 6.2-1(a)), according to the test configuration
example in Figure 6.2-1(b).
(3) As a general rule, this test shall be done before mounting the subsystem or payload on
the spacecraft.

24

JERG-2-400 A

Onboardcommunications and data
handling system(Onboard node)

Subsystem/Payload(Onboard node)

Ground station
facility(Ground node)

Logical data path

User application

User application

End-to-end
protocolEnd-to-end protocol(Relay)End-to-end protocol(Relay)Onboardsubnetwork
protocolOnboardsubnetwork
protocolSpace link
subnetwork
protocolSpacecraft operation
control system(Ground node)Space link
subnetwork
protocolGroundsubnetwork
protocolEnd-to-end
protocolGroundsubnetwork
protocol: Shows an object (physical connection) of the subsystem/payload compatibility test.
: Shows an object (logical connection) of the subsystem/payload compatibility test.
: Shows a physical connection.

(a) Protocol Configuration and Object of Subsystem/Payload Compatibility Test
Device under test
(Subsytem/Payload)

Test equipment (compatibility test simulator)

Onboard data handlingsystem simulator(repeater)Spacecraft
operation control
simulator

Example: Ethernet, TCP/IP
Node

Onboard
Data Link(b) Test Configuration Example
Figure 6.2-1 Subsystem/Payload Compatibility Test

6.3

RF compatibility test
(1) The test system is shown in Figure 6.3-1.
(2) The object of the test is the physical layer (solid arrow in Figure 6.3-1) of the spacelink subnetwork protocol. Include the data link layer if necessary (dashed arrow in
Figure 6.3-1).
(3) Coordinate the test method and test schedule with the groung station which uses thecommunications.

25

JERG-2-400 A

Subsystem/Payload(Onboard node)

Ground station facility(Ground node)

Onboard communications
and data handling system(Onboard node)Spacecraft operation
control system(Ground node)

User application

User application

End-to-end
protocolEnd-to-end protocol(Relay)End-to-end protocol(Relay)Onboardsubnetwork
protocolSpace link
subnetwork
protocolSpace link
subnetwork
protocolOnboardsubnetwork
protocolGroundsubnetwork
protocolEnd-to-end
protocolGroundsubnetwork
protocol: Shows an object (physical connection) of the RF compatibility test.
: Shows an object (logical connection) of the RF compatibility test.
: Shows a physical connection.
Note: If relay satellites are used, they are included in the space link subnet. Their function is merely signal
regeneration or relay supported only by the physical layer.

Figure 6.3-1 Protocol configuration and object of RF compatibility test

6.4

End-to-end test
(1) The test system is shown in 6.4-1.
(2) This is a data through test (physical connection confirmation test) between thespacecraft and spacecraft operation control system. (Figure 6.4-1)(3) This test shall be conducted before the launch of the spacecraft.
Subsystem/Payload

Ground station facility(Ground node)

Onboard communication anddata processing system(Onboard node)

Logical data path

User application

End-to-end protocol

Onboard subnetwork
protocolUser application

End-to-end protocol(Relay)End-to-end protocol(Relay)Onboard subnetwork
protocolSpace link
subnetwork
protocolSpace link
subnetwork
protocolGround subnetwork
protocol: Shows an object (physical connection) of the end-to-end test.
: Shows an object (logical connection) of the end-to-end test.
: Shows a physical connection.

Figure 6.4-1 Protocol Configuration and End-to-end Test

26

Spacecraft operation
control system(Ground node)End-to-end protocol

Ground subnetwork
protocol