JERG-2-403
限定なし

スペースコミュニケーション・
エンドツーエンドプロトコル設計標準2019 年 5 月 30 日 初版

宇宙航空研究開発機構

免責条項
ここに含まれる情報は、一般的な情報提供のみを目的としています。JAXA は、かかる情報の正確性、有用性又は適時性を含め、明示又は黙示に何ら保証するものではありません。また、
JAXA は、かかる情報の利用に関連する損害について、何ら責任を負いません。
Disclaimer
The information contained herein is for general informational purposes only. JAXA makes nowarranty, 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 the information.

発行〒305-8505 茨城県つくば市千現 2-1-1
宇宙航空研究開発機構 安全・信頼性推進部
JAXA（Japan Aerospace Exploration Agency）

JERG-2-403

目次

1 はじめに ................................................................................................... 1
1.1 目的 .............................................................................................................................. 1
1.2 構成 .............................................................................................................................. 1
1.3 関連文書 ....................................................................................................................... 1
1.4 略語 .............................................................................................................................. 3
1.5 用語の定義 ................................................................................................................... 3

2 ネットワーク、インターネットの基礎 ..............................................4
2.1 ネットワーク................................................................................................................ 4
2.1.1 信号インタフェースとネットワークの形態 ......................................................... 4
2.1.2 インターネット ..................................................................................................... 6
2.2 インターネットの仕組み-通信プロトコル................................................................... 6
2.2.1 経緯 ....................................................................................................................... 6
2.2.2 OSI 参照モデル ...................................................................................................... 7
2.2.3 中継器 .................................................................................................................... 9
2.2.4 インターネットの標準プロトコル ........................................................................ 93 宇宙通信システムの構成と適用する標準プロトコル .................... 12
3.1 システム構成.............................................................................................................. 12
3.1.1 オンボードサブネットワーク ............................................................................. 13
3.1.2 スペースリンクサブネットワーク ...................................................................... 13
3.1.3 地上サブネットワーク ........................................................................................ 14
3.1.4 構成サブネットワークの特徴 ............................................................................. 15
3.1.5 サブネットワークの接続..................................................................................... 15
3.2 宇宙通信プロトコル................................................................................................... 18
3.2.1 エンドツーエンドプロトコル ............................................................................. 19
3.2.2 スペースリンクサブネットワークプロトコル .................................................... 19
3.2.3 オンボードサブネットワークプロトコル ........................................................... 21
3.2.4 地上サブネットワークプロトコル ...................................................................... 21
3.3 スペースパケットプロトコルの特徴 ......................................................................... 22
3.3.1 プロトコルデータユニット ................................................................................. 22
3.3.2 スペースパケットの伝送..................................................................................... 22
3.3.3 スペースパケットの生成..................................................................................... 23ii

JERG-2-403

3.3.4 スペースパケットの伝送制御 ............................................................................. 24
3.3.5 スペースパケットの発生..................................................................................... 26

4 スペースパケットプロトコルの適用標準 ....................................... 27
4.1 スペースパケットプロトコルのコンセプトとアドレッシングの定義 ...................... 27
4.1.1 CCSDS 勧告の標準規格 ...................................................................................... 27
4.1.2 JAXA の設計標準 ................................................................................................. 28
4.2 スペースパケットプロトコルのサービス .................................................................. 30
4.2.1 CCSDS 勧告の標準規格 ...................................................................................... 30
4.2.2 JAXA の設計標準 ................................................................................................. 34
4.3 プロトコルデータユニット........................................................................................ 35
4.3.1 CCSDS 勧告の標準規格 ...................................................................................... 35
4.3.2 JAXA の設計標準 ................................................................................................. 40
4.4 パケット伝送の仕組み ............................................................................................... 47
4.4.1 CCSDS 勧告の標準規格 ...................................................................................... 47
4.4.2 JAXA の設計標準 ................................................................................................. 49
4.5 管理パラメータ .......................................................................................................... 49
4.5.1 CCSDS 勧告の標準規格 ...................................................................................... 49
4.5.2 JAXA の設計標準 ................................................................................................. 50
付録 1 宇宙機プロジェクトが規定する仕様 ..................................................................... 51
付録 2 宇宙機プロジェクトの User Application が規定する仕様 ..................................... 51iii

JERG-2-403

1 はじめに
1.1 目的
本文書は、、宇宙通信システムの構成とエンドツーエンドに使用するスペースパケットプ
ロトコルの標準である。なお、スペースコミュニケーションエンドツーエンドプロトコルに適用する CCSDS 標準は JERG-2-400：通信設計標準に規定してある。以下、宇宙通信シス
テムとシステムを構成するネットワークは次のようなものである。
宇宙通信システムは、オンボードサブネットワーク、スペースリンクサブネットワーク、
地上サブネットワークをエンドツーエンドプロトコルで接続したインターネットである。
オンボードサブネットワークは地上の技術または宇宙用に変えた技術を使用する。地上
サブネットワークは、
地上の技術をそのまま使用する(一部、CCSDS の SLE 勧告を併用する)。
スペースリンクサブネットワークとエンドツーエンドで使用するプロトコルは CCSDS 勧
告のプロトコルである。スペースリンクサブネットワークで使用する CCSDS データリンク
層プロトコルは、関連文書[2]および[3]である。

1.2 構成この文書の構成を以下に示す。
第 2 章：第 3,4 章を記載する前に宇宙通信システムを理解する上でのネットワーク、
インターネットの基礎を示す。
第 3 章：宇宙通信システムの構成と適用する標準プロトコルおよびエンドツーエン
ドの特徴を示す。
第 4 章：エンドツーエンドに使用するスペースパケットプロトコルの適用標準を示す。

1.3 関連文書
以下に、参考文書を示す。版（バージョン）の指定の無い文書は最新版を適用すること。
[1] JERG-2-400：通信設計標準[2] JERG-2-401：テレコマンドデータリンクプロトコル設計標準[3] JERG-2-402：AOS データリンクプロトコル設計標準[4] Information Technology – Open Systems Interconnection – Basin Reference Model:
The Basic Model. International Standard, ISO/IEC 7498-1. 2nd ed. Geneva: ISO,
1994.

1

JERG-2-403[5] Information Technology – Open Systems Interconnection – Basic Reference Model– Conventions for the Definition of OSI Services, International Standard.
ISO/IEC 10731:1994. Geneva: ISO, 1994.
[6] JIS X5003-1987：開放型システム間相互接続の基本モデル.
[7] JERG-2-200-TM001A：信号インタフェース例.
[8] CCSDS 130.0-G-3：Overview of Space Communications Protocols.
[9] CCSDS 133.0-B-1：Space Packet Protocol.
[10] CCSDS 311.0-M-1：Reference Architecture for Space Data Systems.
[11] CCSDS 301.0-B-4：Time Code Format.
[12] CCSDS 727.0-B-4：CCSDS File Delivery Protocol (CFDP).
[13] Information Technology – Protocol for Providing the Connectionless – Mode
Network Service: Protocol Specification. International Standard, ISO/IEC
8473-1:1998. 2nd ed. Geneva: ISO,1998.
[14] CCSDS 133.1-B-2：Encapsulation Service[15] "Registries." Space Assigned Nummber Authority(SANA).
Http://sanaregistry.org/r/2

JERG-2-403

1.4 略語以下に、この標準書で使用する略語を示す。
AOS
APID
ARQ
BCH
CCSDS
CFDP
CLCW
COP-1
CRC
FARM
FOP
HDLC
HDR
HK
IETF
IP
ISO
ITU
LAN
LDP
MCID
MOC
M_PDU
OSI
PDU
POC
PVN
QoS
SCID
SDU
SLE
SOIS
TC
TCP/IP
TFVN
WAN

Advanced Orbiting Systems
Application Process Identifier
Automatic Repeat Request
Bose-Chaudhuri-Hocquenghem
Consultative Committee for Space Data Systems
CCSDS File Delivery Protocol
Communications Link Control Word
Communications Operation Procedure-1
Cyclic Redundancy Code (巡回冗長符号)
Frame Acceptance and Reporting Mechanism
Frame Operation Procedure
High-Level Data Link Control (ハイレベルデータリンク制御手順)
HeaderHouse Keeping
Internet Engineering Task Force
Internet Protocol
International Organization for Standardization (国際標準化機構)
International Telecommunication Union (国際電気通信連合)
Local Area Network (構内情報通信網)
Logical Data Path (論理データパス)
Master Channel Identifier
Mission Operation Control (宇宙機運用管制)
Multiplexing Protocol Data Unit (AOS Data Link Sublayer の PDU)Open System Interconnection (開放型システム間相互接続)
Protocol Data Unit (プロトコルデータ単位)
Payload Operation Control (ペイロード運用管制)
Packet Version Number
Quality of Service (サービス品質)
Spacecraft Identifier
Service Data Unit (サービスデータ単位)
Space Link Extension
Spacecraft Onboard Interface Services
Telecommand
Transmission Control Protocol/ Internet Protocol
Transfer Frame Version Number
Wide Area Network (広域情報通信網)

1.5 用語の定義
この文書で使用する用語は、関連文書[1]で定義した用語と同じである。

3

JERG-2-403

2 ネットワーク、インターネットの基礎
宇宙通信(Space Communication)システムは、地上で使用しているネットワークの技術を宇宙へ拡張したものであり、その基本技術は OSI 参照モデルである。そのため、OSI 参照モ
デルの知識がないと宇宙通信は理解しにくい。
そこで、この章では OSI 参照モデルの概要を示す。詳細は、多くの書物や規格(関連文書[4]、 [5]、[6]など)を参照されたい。
なお、この章の記述は、宇宙通信の基本技術を理解するための記載である。

2.1 ネットワーク
ネットワーク(Network)とは、通信の分野では、コンピュータネットワーク(Computer
Network)の略である。
この節では、ネットワークの形態を示す。また、ネットワークと単なる信号インタフェースの違いを示す。

2.1.1 信号インタフェースとネットワークの形態
2.1.1.1 信号インタフェース
コンピュータが使用できない時代(またはコンピュータが使用できない場合)、機器 A から機器 B への情報伝送は、例えば、次に示すように行われる(図 2.1.1.1-1 参照)。
(1) 情報を’1’/’0’のデータに変換する。
(2) ’1’/’0’のデータを’H’/’L’等の信号に変換する。
(3) 伝送速度、伝送距離を満足するラインドライバ・レシーバで信号を伝送する。
(4) (1)の(2)の変換方法、データ伝送速度、データ長、データ送信タイミング、誤り制
御、ラインドライバ・レシーバの形式などは、機器 A と機器 B 間で調整して決定す
る。

情報

機器 A

機器 B

情報

データ変換

データ変換

信号変換

信号変換
D

送信制御

D
D

D: Line Driver
R: Line Receiver

Data
Enable
Clock

R
R

受信制御

R

Enable: 一塊のデータ領域を示す。
Clock: Data Read 用。

図 2.1.1.1-1 信号インタフェースの代表例

このようなインタフェースは、ネットワークとは呼ばない。

4

JERG-2-403

宇宙機内において、このようなインタフェースはノード内機器の接続に使用される(図2.1.1.1-2)。宇宙機のノードは一つのプロセッサと一つまたは複数のトランスジューサでモデル化される。プロセッサとトランスジューサ間は、このようなインタフェース(ディスクリート インタフェースということもある)である場合が多い。
Discrete Interface
Node:
一般に、一つの Payload や Subsystem が一つの Node になる。
Transducer:
一般に、Sensor や Actuator のようなエネルギー変換機器である。
Processor:
一般に、信号処理、データ処理、監視制御(Monitor & Control)、通信を行う機器である。

Node
Transducer
Processor
Transducer
Onboard Data Bus
図 2.1.1.1-2

宇宙機のディスクリート インタフェースの例

このディスクリート インタフェースは関連文書[7]で例が示されている(参考：ESA は
ECSS-E-ST-50-14: Spacecraft Discrete Interface で標準化している)。

2.1.1.2 ネットワーク
一般に、ネットワークとは、通信の分野では、コンピュータネットワークの略である。
コンピュータが出現すると、標準化された汎用ハードウェアを使用してアプリケーショ
ンはソフトウェアで実現することになる。
そうすると、コンピュータ間のインタフェースは、前節(2.1.1.1 節)のように情報を伝送するコンピュータ間で、その都度、調整・決定したのでは汎用性が無くなるため、標準化される。このようにして、LAN(Local Area Network：構内情報通信網)が登場する。LAN の形態を図 2.1.1.2-1 に、LAN の例を表 2.1.1.2-1 に示す。

HUB(a) バス型(b) リング型
図 2.1.1.2-1 LAN の形態（Topology）
表 2.1.1.2-1 LAN の例
LAN 形態
バス型
リング型
スター型

LAN 規格10BASE-5 (Ethernet)
MIL-STD-1553B
CAN
トークンリング
FDDI
10BASE-T (Ethernet)
SpaceWire

5

通信ケーブル
同軸ケーブルツイストペアケーブル
ツイストペアケーブル
ツイストペアケーブル
光ケーブル
ツイストペアケーブル
ツイストペアケーブル(c) スター型

JERG-2-403

LAN が登場すると、離れた場所にある LAN 同士の接続が行われて WAN(Wide Area Network：
広域情報通信網)を形成する。
一般に、LAN は一つの建物や敷地内(半径数百メートル程度)での利用であり、WAN は建物
間や敷地間(例：本社と支社)の離れた場所にある LAN 同士の接続である。
離れた場所にある LAN 同士の接続は、一般的に、通信業者が提供する通信回線を使用する(図 2.1.1.2-2)。
WAN

Relay

NTT 等

Relay

HUB

通信回線(ISDN 等)
LAN

LAN

通信業者が提供する通信回線
公衆回線：電話回線、ISDN、パケット交換網(DDX-P 等)、
フレームリレー網、セルリレー網、OCN 等。
専用回線：通信業者からリースしたプライベート回線。
図 2.1.1.2-2 離れた場所にある LAN 同士の接続（一般的にいう WAN）の例

2.1.2 インターネット
インターネットとは、複数のネットワーク(LAN や WAN)を接続したものを言う。インター
ネットはネットワークのネットワークであり、地球規模の WAN と言える。
構造的には、インターネットと WAN は同じである。ただし、インターネットは世界中のコンピュータと接続できるのに対し、WAN は特定の関係者による LAN 同士の接続である。

2.2 インターネットの仕組み-通信プロトコル
この節は、インターネットの仕組み、すなわちインターネットプロトコル(通信プロトコ
ルである)を示す。
現在、世界中で標準的に使用しているインターネットプロトコルは、TCP/IP プロトコル群である。TCP/IP プロトコル群は、ISO ではないが、ISO の OSI 参照モデルの考え方と一致している。

2.2.1 経緯通信プロトコル(以下、プロトコルという)とは、送信側と受信側で通信を行うための規約である。2.1.1.1 節の信号インタフェースで示したように、送信側と受信側だけで規約を決めれば通信はできる。

6

JERG-2-403

コンピュータ間通信も同様で、初期のコンピュータ間プロトコルはコンピュータメーカ
毎に作られた。自社同士のコンピュータは接続できるが、他社のコンピュータは接続できないという事態が発生し、汎用性にかけると共に非効率であった。
そこで、ITU 1や ISO 2などの国際標準機関が中心になり、コンピュータの機種に依存しない
標準プロトコルの開発を行った。そのモデルが、OSI 3参照モデルと呼ばれる標準モデルである。OSI 参照モデルはプロトコルそのものではなく、考え方を示したモデルである。このOSI 参照モデルの考え方は現在も広く利用されている。宇宙通信もこの OSI 参照モデルの基本的な考え方に従っている。

2.2.2 OSI 参照モデル
OSI 参照モデルの重要な基本的な考え方を以下に示す(図 2.2.2-1 参照)。
(1) 通信に必要な機能をいくつかの独立した機能に分けた。この分けた機能を層(Layer)という。
(2) 送信側の N 層は N+1 層から送られるデータは見ない。N 層の機能を実行するために必要な情報をヘッダ(Header)に付加して N-1 層へ転送する。
(3) 受信側の N 層は N-1 層から転送されたデータのヘッダを見て N 層機能を実行する。
実行を終えたらヘッダを除去して N+1 層へデータを転送する。
(4) 上記(1)から(3)項により、N 層の機能は送信側 N 層と受信側 N 層だけで決めればよい。N 層機能は他の層へ影響しないと共に、他の層の影響も受けない。
(5) 上記(1)から(3)項により、N 層の機能に変更が生じても、N 層のみの変更であり、変更は他の層へ影響しない。
受信側

送信側

N+1 層

N層

N-1 層

N 層の Service Data Unit (SDU)

見ない

見ない

見ない

N 層 Header
N 層機能を実行するのに必要な情報を付加して下位層へ転送する。

N 層の Protocol Data Unit (PDU)

見ない

N 層 Header
Header を見て N 層機能を実行する。
実行したら Header を除去して上位層へ転送する。
図 2.2.2-1 OSI 参照モデルの基本的な考え

International Telecommunication Union：国際電気通信連合
International Organization for Standardization：国際標準化機構
3Open System Interconnection：開放型システム間相互接続
127JERG-2-403

OSI 参照モデルは、プロトコルに必要な層を 7 つに分けている。層の名称、層の機能を表
2.2.2-1 に示す。

表 2.2.2-1 OSI 参照モデルの 7 層

上
位
層

下
位
層

OSI 参照モデル情の分類
層
層名称
アプリケーション層
第 7 層 Application Layer
プレゼンテーション層
第 6 層 Presentation Layer
セッション層
第 5 層 Session Layer
トランスポート層
第 4 層 Transport Layer
ネットワーク層
第 3 層 Network Layer
データリンク層
第 2 層 Data Link Layer
物理層
第 1 層 Physical Layer

機能概要
ファイル転送やメッセージ通信(E-mail)など、ユーザが実行する多くのサービス間プロトコルを制御。
文字コードや画像データの表現形式を制御し、プロセス間におけるデータ形式などを確認する
アプリケーションプロセス間の情報の流れなど、通信モードの管理や情報転送に関する通信制御。
通信情報の質を高めるための通信制御などを行う。データに抜けがあった場合、相手に通知する。
複数のネットワークにまたがったコンピュータ間のデータ転送やデータの中継機能など。
ノード間で信頼性の高いデータ伝送を保証、中継局間のデータ伝送を確実に行う 。
データを電気信号に変換し、実際の伝送を行う。

谷口功、“通信プロトコルの仕組み”、日本実業出版社

宇宙通信では、下位 3 層が特に重要である。下位 3 層の主要機能は次のようにもいえる。
第 3 層(Network Layer)・エンドツーエンド間の通信である。送信、中継、受信機能がある。
・第 3 層の PDU のヘッダは、送端(Sending End)と受端(Receiving End)が分かる情報を含む。
第 2 層(Data Link Layer)
・隣のノードとの通信(ノード間)である。
・第 2 層の PDU のヘッダは、送信ノード(Sending Node)と次のノード(Next
ReceivingNode)が分かる情報 を含む。
第 1 層(Physical Layer)
・データと電気信号の伝送媒体変換を行う。
【注記】：PDU(Protocol Data Unit)とは、「N 層プロトコル中で指定するデータの単位であり、N 層プロトコル制御情報または N 層プロトコル制御情報と N 層利用者データからなる」(関連文書[6])である。N 層プロトコル制御情報とは、N 層機能を実行するための情報(ヘッダ)であり、N 層利用者データとは N-1 層との 転 送
データ である。

8

JERG-2-403

2.2.3 中継器
LAN と LAN を接続する場合、中継器(Relay)を使用する(図 2.2.3-1)。

中継器

図 2.2.3-1 LAN の接続例 － 中継器を使用する --中継器の基本的な種類とその特徴を図 2.2.3-2 に示す。
Application
Presentation
SessionTransport
Network
Data Link
PhysicalPhysicalApplication
Presentation
SessionTransport
Network
Data Link
Physical

中継器

送受端

Repeater

送受端・電気信号を中継するのみで、データはそのまま通過。

Application
Presentation
SessionTransport
Network
Data Link
Physical

BridgePhysical

中継器

送受端

送受端

RouterData Link
PhysicalNetwork

Data Link
Physical

送受端・Data Link Header が見えるので、データを通貨させる／させな
い(フィルタリング)ができる。

(b) ブリッジ(a) リピータ

Application
Presentation
SessionTransport
Network
Data Link
Physical

Data Link
PhysicalApplication
Presentation
SessionTransport
Network
Data Link
Physical

Gateway

Application
Presentation
SessionTransport
Network
Data Link
PhysicalApplication
Presentation
SessionTransport
Network
Data Link
PhysicalApplication
Presentation
Presentation
SessionSessionTransport
Transport
Network
Network
Data Link
Data Link
PhysicalPhysicalApplication
Presentation
SessionTransport
Network
Data Link
Physical

送受端

送受端

中継器

送受端

中継器

・Network Header がみえるので、データを転送する方向を決定(ルーティング)できる。

・全階層の Protocol 変換ができる。

(d) ゲートウェイ(c) ルータ
図 2.2.3-2 中継器(Relay)の種類と特徴

2.2.4 インターネットの標準プロトコル
2.2.4.1 経緯
ITU や ISO などの国際標準機関が中心になり OSI 参照モデルに従ったプロトコルを開発したが、そのプロトコルは汎用性を重視し過ぎたため複雑になり、広く普及しなかった。

9JERG-2-403

一方、米国防省(DOD)が ARPANET 4(アーパネット)というコンピュータネットワークを開発
し、この通信プロトコルとして TCP/IP が開発された。TCP/IP は、結果として OSI 参照モデ
ルと考え方が一致していたことと、実際に即していて複雑でなかったことにより世界中に広く普及した。
現在、TCP/IP の技術仕様は IETF 5で RFC 6として公表される。国際的標準機関の規格ではな
いが、デファクトスタンダード(事実上の標準)である。

2.2.4.2 TCP/IP プロトコル群
TCP/IP の TCP は Transmission Control Protocol の略で OSI 参照モデルの第 4 層に相当するプロトコルであり、IP は Internet Protocol の略で OSI 参照モデルの第 3 層に相当す
るプロトコルである。
TCP/IP は単独で使用されることはなく、通信サービスのいずれかのサービスと組み合わせて使用されるので、TCP/IP プロトコル群と呼ばれる。通信サービスは OSI 参照モデルの第 5 層から第 7 層の機能に相当する。
OSI 参照モデルの下位 2 層相当は規定しない。
図 2.2.4.2-1 に TCP/IP プロトコル群を OSI 参照モデルと共に示す。
SMTP : Simple Mail Transfer Protocol
FTP: File Transfer Protocol
TELNET : TELecommunication NETwork
NNTP : Network News Transfer Protocol

OSI
Reference Model

TCP/IP
プロトコル群SNMP : Simple Network Management Protocol
HTTP : Hyper Text Transfer Protocol
POP3 : Post Office Protocol 3
DNS : Domain Name System

TCP/IP プロトコル群の PDU

7 Application Layer
通信サービス

6 Presentation Layer

通信サービスが生成したデータ。

5 Session Layer

データ

通信サービス ID 等

4 Transport Layer

TCP

UDP

3 Network Layer

IP

RIP
OSPF

H

送信元 IP アドレス、
宛先 IP アドレス等
送信元 MAC アドレス、
宛先 MAC アドレス等

2 Data Link Layer

HH

1 Physical Layer
Ethernet, Token Ring, FDDI, IEEE1394, USB, CAN, FlexRay, IEEE355 …
TCP: Transmission Control Protocol
IP: Internet Protocol
UDP: User Datagram Protocol
RIP: Routing Information Protocol
図 2.2.4.2-1.

OSPF: Open Shortest Path First
MAC: Media Access Control
PDU: Protocol Data Unit

OSI 参照モデルと TCP/IP プロトコル群

DARPA(Defense Advanced Research Project Agency)の前身である ARPA(Advanced Research Project Agency)が各地に分散していた UNIX の Computer を接続するために開発した Network。
5
Internet Engineering Task Force
6
Request for Comment
410

JERG-2-403

IP(Internet Protocol)という用語は、一般名詞ではネットワークを接続するプロトコルを意味する。TCP/IP は IP を固有名詞で使用している。よって、TCP/IP プロトコル群で接続したネットワークは The Internet という。
The Internet の例を図 2.2.4.2-2 に示す。
OSI 参照モデル
7. Application
6. Presentation
5. Session
4. Transport
3. Network
2. Data Link
1. Physical

Destination

Source通信サービス

通信サービス

TCP
IP
LAN 1

Relay

Relay

IP

IP

LAN 1

LAN 2

Local
Subnetwork
(1)
(2)
(3)

LAN m
Intermediate
Subnetwork

TCP
IP

LAN n

LAN n

Local
Subnetwork

Source、Relay、Destination とも第 3 層と第 4 層に TCP/IP を使用する。
Source、Relay、Destination とも第 2 層以下は、原則、OSI 参照モデル下位 2 層に適合したLAN でよい。
Source と Destination は TCP/IP プロトコル群の通信サービスを使用して情報の伝送を行う。
図 2.4.2.2-2 The Internet の例

11

JERG-2-403

3 宇宙通信システムの構成と適用する標準プロトコル
データハンドリングシステム(Data Handling System)の主要機能は、宇宙機の監視制御(Spacecraft Monitor and Control)とそのための通信である。この通信は宇宙機が取得した観測データ等の伝送を含む。
宇宙通信システムとは、このように宇宙-地上間における宇宙機の監視制御に必要なデー
タの伝送および宇宙機が取得した観測データ等の伝送を行うシステムである。宇宙機から地上系へは Metry(観測、計測データ)を伝送し、地上系から宇宙機へは Command(コマンド)を伝送する。伝送は遠隔なので、Telemetry(テレメトリ)および Telecommand(テレコマンド)という。
現在の宇宙通信システムは、宇宙機にコンピュータが搭載されるようになったことにより、コンピュータネットワークである。このコンピュータネットワークは、地上のネット
ワークを宇宙へ拡張したものであり、CCSDS により開発されたプロトコルが世界標準になっている。
この章は、宇宙通信システムの構成と JAXA が使用する標準プロトコルを示す。また、宇宙通信システムでエンドツーエンドプロトコル(End-to-End Protocol)に使用するスペース
パケットプロトコル(Space Packet Protocol)の特徴を示す。

3.1 システム構成
宇宙通信(Space Communication)システムは、特性の異なった以下に示す 3 つのサブネッ
トワーク(Subnetwork)から構成される(図 3.1-1)。
・オンボードサブネットワーク(Onboard Subnetwork)・スペースリンクサブネットワーク(Space Link Subnetwork)
・地上サブネットワーク(Ground Subnetwork)

Space Segment
OnboardSubnetwork

Space Link
Subnetwork

図 3.1-1 宇宙通信システムの構成

以下、3 つのサブネットワークについて示す。

12

Ground Segment
GroundSubnetworkJERG-2-403

3.1.1 オンボードサブネットワーク
オンボードサブネットワーク(Onboard Subnetwork)は、スペースセグメント(Space
Segment)のすべてのノード(Node)と接続したネットワークである。
スペースセグメントのノードはペイロードやサブシステムである。これらのノードは、一つの宇宙機内にすべてがある場合と複数の宇宙機内にすべてがある場合がある。
多くの宇宙機(地球周回衛星など)は、一つに宇宙機内にすべてのスペースセグメントのノードがある例である(図 3.1.1-1)。

(e.g. Satellite)

OnboardSubnetwork：Node
Space Link Subnetwork(Space-to-Ground)

図 3.1.1-1 宇宙ネットワークの構成例

3.1.2 スペースリンクサブネットワーク
宇宙リンクサブネットワーク(Space Link Subnetwork)は、宇宙機(Spacecraft)と地上局(Ground Station)間のポイントツーポイント(Point-to-Point)の無線回線(RF Link)である(図3.1.2-1)。
Data Relay Satellite
TM
TC
Spacecraft
TM

TC

Ground Station

TMor
Ground Station

Space Link
Subnetwork

TM: Telemetry
TC: Telecommand

Ground Station
図 3.1.2-1 宇宙リンクの構成例

13: Simplex RF Link

JERG-2-403

RF Link はデータ中継衛星(Data Relay Satellite)を経由する場合もある。データ中継衛星の機能はリピータ(Repeater) (図 2.2.3-2(a)参照)である。
宇宙機から地上局への伝送はテレメトリ(Telemetry)回線であり、地上局から宇宙機への伝送はテレコマンド(Telecommand)回線である(非対称通信である)。
RF Link は、宇宙機から地上局への伝送と地上局から宇宙機への伝送を行うが、伝送路は双方向通信(Duplex)ではない。方向の異なる 2 つの単方向通信(Simplex)である。
これは、テレコマンド回線に障害が発生した場合でもメトリ(Metry; HK Data や Payload
Data)の伝送は可能とする、逆にテレメトリ回線に障害が発生した場合でもコマンドの伝送は可能とするためである。

3.1.3 地上サブネットワーク
地上サブネットワーク(Ground Subnetwork)は、地上セグメント(Ground Segment)のすべてのノード(Node)と接続したネットワークである(図 3.1.3-1)。
地上ネットワークは、通常、LAN(Local Area Network)や WAN(Wide Area Network)の集合体である。複数のネットワークの集合であり、これらのネットワークにインターネット
プロトコル(一般に、TCP/IP プロトコル群)を使用して複数のネットワークを接続している。
地上セグメントのノードは、地上のデータハンドリングリンク(Data Handling)の設備であり、宇宙機運用管制(MOC: Mission Operation Control)、ペイロード運用管制(POC: Payload
Operation Control)、ペイロードデータの処理、解析、保管、配信等の設備である。

MOC

Space Link
Subnetwork

POC

Ground Subnetwork

Processing

Archive

Analysis

Distribution

Payload Data

図 3.1.3-1 地上ネットワークの構成例

14

MOC: Mission Operation Control
POC: Payload Operation Control

JERG-2-403

3.1.4 構成サブネットワークの特徴
宇宙通信システムを構成する 3 つのサブネットワーク(オンボードサブネットワーク、ス
ペースリンクサブネットワーク、地上サブネットワーク)の特性の違いについて、主に環境の違いを表 3.1.4-1 に示す。
また、伝送するデータの特徴を表 3.1.4-2 に示す。
表 3.1.4-1 宇宙通信を構成する 3 領域の環境の違い
環境(1) 有線で信号遅延がない恵まれた環境である。伝送品質は良い。
(2) 修理・保守は出来ない環境である（注 1）。
(3) 地上に比べてリソース(伝送容量、Storage 容量等)は少ない。
(1) 宇宙空間を伝播する無線である。信号遅延は大きく、伝送品質は悪い厳しい環境である。ドップラシフト(Doppler Shift)などによる信号劣化もある。
(2) 回線が接続される時間は非常に短い環境である（注 2）。
(3) 伝送路は単方向(Simplex)である。双方向(Duplex)ではない。
地上サブネットワーク(1) 有線で信号遅延がほとんどない恵まれた環境である。伝送品質は良い。
Ground Subnetwork(2) 複数の Network を Internet Protocol で接続している。
(3) 修理・保守は可能であり、最新技術を適用できる。
(4)通信途絶を前提に設計(再送信)されてはいるが、回線は接続されている環境である。
注 1：地上の最新技術は使用不可。Implementation するための技術はコンサバティブ。
注 2：一般的な地球観測衛星の場合、衛星周期約 90 分に対し、1 局あたりの通信可能時間(可視時間)は長くて 10 分程度。
サブネットワーク
オンボード
サブネットワーク
Onboard Subnetwork
スペースリンク
サブネットワーク
Space Link Subnetwork

伝送データ
テレメトリ
Telemetry

テレコマンドTelecommand

表 3.1.4-2 宇宙機データ伝送の特徴
環境(1) 連続データの伝送である。
(2) 伝送誤りによる宇宙機の損傷は無く、再送よりはどんどん伝送することを優先する。
誤り制御は、誤り訂正を行う。
(3) Up Link/Forward Link 障害時にも Telemetry は伝送する(要求)。
(1) バーストデータの伝送である。
(2) 伝送誤りは宇宙機を損傷させることがあるため、伝送誤りは許容できない。
誤り制御は、誤り検出・再送を行う。
(3) Down Link/Return Link 障害時にも Telecommand は伝送する(要求)。

3.1.5 サブネットワークの接続
宇宙通信システムは、オンボードサブネットワークとスペースリンクサブネットワークと地上サブネットワークの 3 つを接続したものである。これは、図 2.1.1.2-2 で示した離れた LAN 同士の接続に似ている。
図 2.1.1.2-2 は離れた LAN 同士の接続であるが、離れた LAN は同じ環境下の LAN 同士の接続ある。しかし、宇宙通信システムでは、表 3.1.4-1 に示したように、特性や環境の異なった領域のネットワークやリンクを接続する。さらに、宇宙機が伝送するデータの特徴は、
表 3.1.4-2 に示すように宇宙機から地上局、地上局から宇宙機で大きく異なる。
したがって、地上サブネットワークで使用している複数のネットワークを接続するプロトコル(TCP/IP プロトコル群)をそのままオンボードサブネットワークと宇宙リンクスペー
スリンクサブネットワークに適用することは困難である。

15

JERG-2-403

ただし、地上サブネットワークの基本概念である OSI 参照モデルの考え方は適用できる
ので、OSI 参照モデルの考え方に従った宇宙用のプロトコルが必要になる。この宇宙用プロ
トコルが CCSDS の宇宙通信プロトコル(Space Communication Protocols)である。
宇宙通信システムは、物理的には図 3.1.5-1(a)に示すように、宇宙機と地上の複数の LANや WAN をインターネットプロトコルで接続した地上のネットワークを無線回線で接続するものである。
【注記】：Space Segment は一つの宇宙機とは限らないが、通常は一つなので一つであらわす。
宇宙機の LAN、宇宙機-地上局間の無線回線、地上のインターネット(The Internet) 7はプ
ロトコルが異なるので中継器が必要になる(図 3.1.5-1(b))。
図 3.1.5-1(b)を単純化したモデルであらわした図が図 3.1.5-1(c)である。ここでは、地上のインターネット(The Internet)を一つのサブネットワークとして扱う。
図 3.1.5-1(d) に 宇 宙 用 イ ン タ ー ネ ッ ト プ ロ ト コ ル ( エ ン ド ツ ー エ ン ド プ ロ ト コ ル ;End-to-End Protocol と呼ぶ)を適用することにより、宇宙機内のネットワークと地上のネッ
トワークがつながる。
これを宇宙インターネットスペースコミュニケーション(Space Communication)と呼ぶ。
地上のネットワークは、複数の LAN や WAN をインターネットプロトコルで接続したうえに更に宇宙用インターネットプロトコルで接続したものになる(インターネットの二重構造
になる).

7

TCP/IP プロトコル群で接続されたネットワークなので、The Internet である。

16

JERG-2-403

PayloadUser

Spacecraft

Telemetry

MOC

POC

Internet Protocol で接続された Internet。

Telecommand
RF Link(a) 宇宙通信システムの物理的構成

Space Segment

Ground Segment
Space Link
Subnetwork

Onboard Subnetwork

PLD

PayloadUser

RF LinkTelemetry

PLD

Onboard LAN

SS

Ground Subnetwork
POC

Internet Protocol で接続された Internet。

Relay
Relay
Telecommand <専用回線>SS

MOC(b) 宇宙機内 LAN と地上ネットワークの接続

Ground Segment

Space Segment
Onboard Subnetwork

Space Link
Subnetwork

Ground Subnetwork
GroundEnd UserOnboardEnd UserOnboardSubnetwork

Relay

Space Link
Subnetwork

Relay

GroundSubnetwork(c) 単純化した宇宙通信システムのモデル

GroundEnd UserOnboardEnd UserSpace Communication(d) 3 つの Subnetwork を a Internet Protocol で接続。
PLD: Payload
SS: Subsystem

MOC: Mission Operation Control
POC: Payload Operation Control

図 3.1.5-1 Space Communication System

17

JERG-2-403

3.2 宇宙通信プロトコル
図 3.1.5-1(c)に示した宇宙通信システムのモデルをプロトコルであらわした図を図 3.2-1に示す。
地上サブネットワークプロトコル(Ground Subnetwork)は、宇宙通信システムにおいては
データリンク層と物理層であるが、地上サブネットワークプロトコル自体は OSI 参照モデルの全階層を有する(TCP/IP プロトコル群を適用した The Internet である)。
Space Segment
OnboardEnd User

GroundEnd User

Application
User

Application
User

Space Communication
Layer
Network Layer

Data Link Layer
Physical Layer

Ground Segment

Relay (Onboard)

End-to-End
Protocol(Relay)End-to-End
Protocol(Relay)End-to-End
ProtocolOnboardSubnetwork
ProtocolRelay (Ground)

OnboardSubnetwork
Protocol(e.g. Payload/
Subsystem)

Space Link
Subnetwork
Protocol(e.g. Central Data
Handling System
of Spacecraft)

Space Link
Subnetwork
ProtocolEnd-to-End
ProtocolGroundSubnetwork
ProtocolGroundSubnetwork
Protocol(e.g. Ground Station)(e.g. Mission Control/
Payload User): CCSDS Recommended Standard Protocols
Ground Subnetwork Protocol: CCSDS Recommended Standard Protocols(SLE)を含む。
Onboard Subnetwork Protocol: CCSDS Informational Report(SOIS)を含む。
Icons: Node: Protocol Entity: Object

参考文書[8]

図 3.2-1 宇宙通信のプロトコル

図 3.2-1 において、エンドツーエンドプロトコル(End-to-End Protocol)と宇宙リンクサブ
ネットワークプロトコル(Space Link Subnetwork)は、CCSDS が宇宙通信用に開発した
CCSDS 勧告の標準プロトコル(CCSDS Recommended Standard Protocol)である。
搭載サブネットワークプロトコル(Onboard Subnetwork Protocol)は、地上で使用しているもの、宇宙用にモディファイしたもの等が適用できるので CCSDS 勧告は特にない 8。ただし、標準サービスを示した SOIS(Spacecraft Onboard Interface Service)というレポートがある。
Ground Subnetwork は地上用のプロトコルをそのまま使用するが、インターネットの二重構造であること等により CCSDS SLE(Space Link Extension)勧告を併用する。
8

CCSDS の目的の一つは標準化により可能となるクロスサポートによる開発費や維持費の低減である。そのため、地上で使用している技術は可能な限り宇宙に適用する。

18

JERG-2-403

3.2.1 エンドツーエンドプロトコル
End-to-End Protocol は CCSDS の Space Packet Protocol を適用する。
注記：CCSDS は、Space Packet を End-to-End Protocol とすることから開発した。その後、RF 回線接続が間欠的である環境下において多量データを伝送する Protocol として CFDP(CCSDS File Delivery Protocol)が開発され(NASA/JPL 火星ミッションで使用)、この Protocol も End-to-End Protocol として使用することは可能である。さらに、
TCP/IP Protocol Suite の一部をそのまま、あるいはカプセル化して End-to-End
Protocol とする勧告もあるが無人衛星では使用されていない。
従って、現状では、JAXA 標準は基本である Space Packet Protocol のみを標準とする。
なお、Space Packet Protocol 以外の End-to-End Protocol については、関連文書[8]を参照。

3.2.2 スペースリンクサブネットワークプロトコル
Space Link は方向の異なる 2 つの単方向通信(Simplex)である(3.1.2 節参照)。一つはTelemetry Link で、他方は Telecommand Link である。
Space Link Subnetwork は OSI 参照モデルの下位 2 層に相当する。CCSDS は Data Link
Layer を Data Link Sublayer と Sync. and Channel Coding Sublayer の 2 つの Sublayer で構成する(図 3.2.2-1)。
OSI Layer

CCSDS Layer

Data Link Layer

Data Link Layer

Physical Layer

Physical Layer

Data Link Sublayer
Sync and Channel Coding Sublayer

図 3.2.2-1 Space Link の Layer

Space Link Subnetwork に適用する設計標準の Protocol を図 3.2.2-2 に示す 9。Telemetry
Link と Telecommand Link は、非対称通信である。

9

Telemetry の Data Link Layer は CCSDS の TM Data Link Protocol も適用できるが、AOS Data Link Protocol は TM Data
Link Protocol を包含しているので AOS Data Link Protocol を標準とする。

19

JERG-2-403

Telemetry
Space Link
Subnetwork
ProtocolTelecommand

CCSDS AOS DLPCCSDS TC DLP

Data Link Sublayer

CCSDS TM SCCCCSDS TC SCC

Sync. and Channel Coding Sublayer

CCSDS RF & MOD

CCSDS RF & MOD

Physical Layer

Simplex

Simplex

AOS: Advanced Orbiting Systems
DLP: Data Link Protocol
SCC: Sync. and Channel Coding

TM: Telemetry
TC: Telecommand
RF: Radio Frequency
MOD: Modulation

図 3.2.2-2 Space Link Subnetwork に適用する Protocols

これらの Protocol は、表 3.1.4-2(宇宙機データ伝送の特徴)に対応したものである。
Data Link Sublayer は、Telemetry および Telecommand とも上位層の Space Packet をTransfer Frame で伝送する。
Telemetry の Data Link Sublayer は、可変長の Space Packet を多重化したパケット列を固定長の Transfer Frame で伝送する(図 3.2.2-3)。
Telecommand の Data Link Sublayer は、可変長の Space Packet を可変長の Transfer
Frame で伝送する(図 3.2.2-4)。
可変長

可変長
Space Packet

Space Packet

Space Packet

Space Packet

Transfer Frame

Transfer Frame

固定長

可変長

図 3.2.2-3 Telemetry Space Packet の伝送

図 3.2.2-4 Telecommand Space Packet の伝送

Telemetry は伝送誤りのない完全なデータを伝送するよりは伝送することを優先するので、Sync. and Channel Coding Sublayer で誤り訂正符号(Reed-Solomon と Convolutional 連接)を使用して伝送誤りを訂正し、再送は行わない(図 3.2.2-5)。
Telecommand は伝送誤りのない完全なデータを伝送することを優先するので、ARQ10機能を持つ。Sync. and Channel Coding Sublayer で誤り検出符号(BCH と CRC)を使用し、Data Link Sublayer で HDLC 11を宇宙用に Modify した COP-1(Communication Operation
Procedure-1)勧告を適用する。受信側で伝送誤りを検出した場合、受信側は送信側に再送を要求する(図 3.2.2-6)。
10
11

Automatic Repeat Request：受信側で誤りを検出したとき、自動的に送信側に再送を要求すること。
High-Level Data Link Control

20

JERG-2-403

送信側 (Space)

送信側 (Ground)

受信側 (Space)

受信側 (Ground)

Transfer Frame

Transfer Frame
FARM
Transfer Frame
Encoding

再送要求注

FOP

COP-1

Transfer Frame
Decoding

Decoding

Encoding

Coding: Error Detection Code
(BCH + CRC)

Coding: Error Correction Code
(Reed-Solomon + Convolutional)

注: 再送要求は Telemetry で伝送する。

図 3.2.2-5 Telemetry の Channel Coding

図 3.2.2-6 Telecommand の Channel Coding と ARQ

3.2.3 オンボードサブネットワークプロトコル
Onboard Subnetwork Protocol は、既存のものを Modify して使用できるので、CCSDS
は標準を定めない 12。
現在、MIL-STD-1553B や SpaceWire などが使用されている。
なお、適用するものが OSI 参照モデルの下位 2 層のものでなくても CCSDS Layer では
下位 2 層とみなす。
CCSDS は Onboard Subnetwork の Service を標準化した SOIS(Spacecraft Onboard
Interface Service) 12がある。SOIS を適用する場合、Onboard Subnetwork Protocol は図3.2.3-1 に示すようになる。Convergence Sublayer は、複数の Data Link Protocol を使用する場合に Data Link Protocol の違いを上位の Subnetwork Service Sublayer へ影響させないための機能である。

OnboardSubnetwork
ProtocolSubnetwork Service Sublayer

Application User に対する標準サービス。

Convergence Sublayer

MIL-STD-1553B, SpaceWire etc.の Protocol の違いを上位へ波及させない。

Data Link Layer

MIL-STD-1553B, SpaceWire etc.

Physical Layer

図 3.2.3-1 Onboard Subnetwork Protocol の構成例

3.2.4 地上サブネットワークプロトコル
Ground Subnetwork は地上のインターネットをそのまま適用する。ただし、地上のイン

12

CCSDS Recommended Standard ではない。Informational Report である。

21

JERG-2-403

ターネットプロトコルのみでは使いにくいところがある。そのため、CCSDS の SLE(Space
Link Extension)勧告を併用する(図 3.2.4-1)。
Ground Subnetwork は、Space Segment または異なる宇宙機関の Ground Segment より送受信する CCSDS プロトコルの PDU(Protocol Data Unit)をそのまま転送可能とする
CCSDS SLE 勧告を地上のインターネットプロトコルと合わせて、適用する場合がある。
SLE 勧告は、例えば、宇宙機関をまたがる地上局と運用センター間のインタフェースのサービスを規定しており、データユニットは Telecommand が CLTU であり Telemetry がReceived All Frame である。
なお、JAXA では SLE 勧告以前に開発された SLE と主旨を同じくするプロトコル(Space
Data Transfer Protocol；SDTP(ISAS))や H-ⅡProtocol も機関内では使用する。
CCSDS SLE
(SDTP or H-ⅡProtocol)

GroundSubnetwork
ProtocolTCP/IP プロトコル群
LAN, WAN 等

図 3.2.4-1 Ground Subnetwork に適用する Protocol

3.3 スペースパケットプロトコルの特徴
スペースパケットプロトコル (Space Packet Protocol) は、宇宙通信のエンドツーエンド
プロトコル(End-to-End Protocol)に適用する CCSDS 勧告のプロトコルである。
以下に、Space Packet Protocol の大きな特徴を示す 13。

3.3.1 プロトコルデータユニット
Space Packet Protocol の PDU(Protocol Data Unit) 14は Space Packet である。PDU のデータ構造(図 3.3.1-1)は Telecommand、Telemetry とも共通である。
Space Packet は固定長の Space Packet Header と可変長の User Data Field からなる。
Metry 15や Command は Space Packet の User Data Field に入れて伝送する。
Metry または Command
PacketHeader
固定長

User Data Field
可変長

図 3.3.1-1 Space Packet

3.3.2 スペースパケットの伝送
Space Packet は、
一つの Source User Application から一つまたは複数の Destination User
詳細は関連文書[9]の 2.2.1 節を参照のこと。
2.2.2 節の【注記】参照。
15
計測、観測データのこと。Telemetry は Metry の遠隔伝送を意味する。
13
14

22

JERG-2-403

Application へ、
一つまたは複数の Subnetwork を介しての単方向データ伝送で Space Packetを伝送する。すなわち Space Packet の伝送は、1:N の単方向伝送である 16。
Space Packet は、Source User Application と Destination User Application の Path でア
ドレッシングする 17 。この Path を Logical Data Path(LDP)とよび、この Path ID を
APID(Application Process Identifier)という。APID は、物理アドレスではなく Application を識別する識別子てあり、ソフトウェアのタスクであっても良い。
Space Packet は APID で定義された Logical Data Path のみを伝送する。すなわち、Space
Packet は予め管理により設定(事前設定)された LDP のみを伝送する 18。Space Packet は事前設定(Pre-configured)サービスである。
Space Packet の伝送は、単方向(一方向)サービス)( Unidirectional (one way) Services)である。 LDP の片端は、受信はできるが送信はできない。他端は、送信はできる が 受 信 はできない。

3.3.3 スペースパケットの生成
Space Packet は、User Application が生成する。
User Application が Space Packet を生成する(Packet Assembly)ことにより、User
Application 間に Logical Data Path が形成される。このことは、Network Layer 以下は隠されて、User Application 間のやり取りは Space Packet のみが伝送されると考えて良いということになる(図 3.3.3-1)。
これは、Space Packet Service という Space Packet Protocol のサービスである。
SourceUser Application
Packet
注1の中身
PacketA
bl

Network Layer

Data Link Layer
Physical Layer

Logical Data Path
(LDP)

Destination
User Application
Packet
注2の中身
Packet Extraction

End-to-End Protocol (Space Packet
P tl)

Packet Relay

Packet Transfer

Onboard Subnetwork

Packet Relay

Space Link Subnetwork

Packet Recovery

Ground Subnetwork

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

注 1:Packet Primary Header 付加
注 2: Packet Primary Header 除去

図 3.3.3-1 Space Packet Service

地上の IP(Internet Protocol)の伝送は、N:N の双方向伝送である。
TCP/IP プロトコル群の IP は、送信 IP アドレスと受信 IP アドレスでアドレッシングする。ともに物理アドレスである。また、データを送信するときに送信 IP アドレスと受信 IP アドレスを設定できる。事前設定ではない。
18
地上の IP(Internet Protocol)の伝送は事前設定ではない。送信するときに Destination を指定できる。
16
17

23

JERG-2-403【注記】：Implementation では、図 3.3.3-1 に示した Source または Destinationの Space Packet Protocol 機能は User Application 自体で実行することがある。
このような場合でも、Space Packet Protocol 機能を実行する User Applicationの部分は Space Packet Protocol とみなす(これは CCSDS 勧告である)。
なお、Space Packet Protocol は、他に Octet String Service というサービスがある(図 3.3.3-2)。このサービスは、もともと、User Application が Space Packet を生成できない既存機器用である。
開発機器には、原則、適用しないこと。

SourceUser Application
Packetの中身

Destination
User Application
Packetの中身

注1
Packet Assembly

End-to-End Protocol (Space Packet Protocol)

注2

Packet Extraction

Network Layer

Packet Relay

Packet Transfer
Data Link Layer
Physical Layer

Onboard Subnetwork

Packet Relay

Space Link Subnetwork

Packet Recovery

Ground Subnetwork

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

注 1:Packet Primary Header 付加
注 2: Packet Primary Header 除去

図 3.3.3-2 Octet String Service
Octet String Service の場合、Source User Application は Network Layer へ Packet の中身のほかに Packet Assembly を行うための情報(Packet Primary Header 生成情報)を送る必要があり、また、Packet Primary Header の Packet Sequence Flag を使用できない制約がある。

3.3.4 スペースパケットの伝送制御
Space Packet Protocol は、一方向サービス(Unidirectional Service)、アンコンファームサービス(Unconfirmed Service)、インコンプリートサービス (Incomplete Service)である。
● 一方向サービス(Unidirectional Service)● アンコンファームサービス(Unconfirmed Service)● インコンプリートサービス(Incomplete Service)：LDP の片端は、受信はできるが送信はできない。
他端は送信ができるが受信はできない。
(すなわち、単方向(Simplex)である)：送端は、データを受信した受端からの確認情報を受け取らない。

：データ送達の完全性を保証しない。また、再送メカニズムも持たない。

24

JERG-2-403

これらのサービスは、表 3.1.4-1 や 3.2.2 節に示したように Telemetry と Telecommand は方向の異なる 2 つの単方向通信(Simplex)であること、表 3.1.4-2 に示した宇宙機データ伝送(Telemetry, Telecommand)の特徴および宇宙機監視制御からの要求である。
Metry Space Packet(以降、Telemetry Packet という)19の伝送は、多少の伝送誤りがあっても訂正すればよく、万一、見逃し誤りが発生しても宇宙機に支障を与えることが少ない。
むしろ、ARQ を行い再送に時間を費やすよりは、どんどん伝送することを優先する。
そのため、Telemetry Packet を伝送する Logical Data Path を構成する 3 つの Subnetworkのうち、Space Link Subnetwork は誤り訂正を行う。Onboard Subnetwork と Ground
Subnetwork は適用する Subnetwork によるが、基本要求は誤り訂正である(ARQ を行う場
合、再送に多くに時間を使わず、また伝送を停止させないことが重要である)。そして、
Telemetry Packet は送達確認を行わず、再送メカニズムも持たない。
図 3.3.4-1 に Telemetry Packet の End-to-End の伝送を示す。
Space Segment

Ground Segment

OnboardEnd User

GroundEnd User

SourceUser
Application

Destination
User
Application

Logical Data Path (PDU: Space Packet)
Unidirectional Service, Unconfirmed Service, Incomplete Service)
Telemetry Packet
Relay (Onboard)

End-to-End
ProtocolOnboardSubnetwork
ProtocolRelay (Ground)End-to-End
Protocol(Relay)OnboardSubnetwork
ProtocolSpace Link
Subnetwork
ProtocolTelemetry Packet

End-to-End
Protocol(Relay)

誤り訂正Space Link
Subnetwork
ProtocolGroundSubnetwork
ProtocolEnd-to-End
ProtocolGroundSubnetwork
Protocol※Space Link Subnetwork は誤り訂正を行う。
※Onboard および Ground Subnetwork の基本要求は誤り訂正である。

図 3.3.4-1 Telemetry Packet の End-to-End 伝送

なお、Onboard Subnetwork と Ground Subnetwork においては、適用する Subnetwork
により伝送順番が保証されない場合がある。伝送順番を知るには、Destination User
Application において、Space Packet Primary Header の Packet Sequence Counter 情報で確認できる。また、万一、伝送中に Space Packet が欠落した場合も Packet Sequence Counter
情報で確認できる。
Command Packet は、Telemetry Packet の伝送とは異なり、伝送誤りや伝送順番の違いが許容できない。誤り Command の実行は宇宙機を損傷させることがある。
そのため、Command Packet を伝送する Logical Data Path を構成する 3 つの Subnetwork
一般に Metry(HK Data, Payload Data) のことも Telemetry と呼ぶことが多い。

19

25

JERG-2-403

は伝送誤りが無く伝送順番も保証されることが必要である。Space Link Subnetwork は、
CCSDS COP-1 勧告の Sequence Control Service(誤り検出、再送メカニズムを持つ)で伝送
誤りが無く伝送順番を保証する。Onboard Subnetwork と Ground Subnetwork は適用する
Subnetwork によるが、伝送誤りが無く伝送順番も保証されることが基本要求である。
Command Packet は Destination End User で正しく伝送されたことを確認する必要がある。そのため、地上側が行う宇宙機の監視制御は、地上側が Command 送信後に宇宙機から伝送される HK Data でコマンド実行の確認を行う。この機能を Command Success
Verify(コマンド実行検証)という。このコマンド実行検証により、Space Packet の送達確認が行われるので、Command Space Packet は送達確認を行わず、再送メカニズムも持たない。なお、コマンド実行検証は宇宙機監視制御(Spacecraft Monitor and Control: SM&C)の範疇のため、本標準では規定しない。
図 3.3.4-2 に Command Packet の End-to-End の伝送を示す。

Space Segment

Ground Segment

OnboardEnd User

GroundEnd User

Destination
User
Application

SourceUser
Application

Logical Data Path (PDU: Space Packet)
Unidirectional Service, Unconfirmed Service, Incomplete Service)
Command Packet
Relay (Onboard)

End-to-End
ProtocolOnboardSubnetwork
ProtocolRelay (Ground)End-to-End
Protocol(Relay)OnboardSubnetwork
ProtocolSpace Link
Subnetwork
ProtocolCommand Packet

End-to-End
Protocol(Relay)

再送要求
誤り検出

Space Link
Subnetwork
ProtocolGroundSubnetwork
ProtocolEnd-to-End
ProtocolGroundSubnetwork
Protocol※Space Link Subnetwork は ARQ(誤り検出、再送):COP-1 を行う。再送要求は Telemetry で伝送する。
※Onboard および Ground Subnetwork の基本要求は伝送誤りが無く伝送順番を変えないことである。

図 3.3.4-2 Command Packet の End-to-End 伝送

3.3.5 スペースパケットの発生
Space Packet Protocol は、非同期サービス(Asynchronous Service)である。User は Space
Packet をいつ発生しても良い。発生タイミング、発生頻度の制約はない。
ただし、Space Packet の発生は、下位の Subnetwork の特性の影響を受ける。例えば、
Onboard Subnetwork が MIL-STD-1553B のように Time Slot でデータ伝送を行う場合、発生タイミング、発生頻度が制約される。また、Space Link の回線速度が非常に遅いと発生頻度は制約される。

26

JERG-2-403

4 スペースパケットプロトコルの適用標準
CCSDS 勧 告 (Recommended Standard Specification) は 、 Software や Hardware のImplementation を規定したものではなく、要求(Requirement)を標準化した規格である。規格は、選択肢やオプションを含むものもある。
この章は、Space Communication の End-to-End Protocol に使用する Space Packet
Protocol 勧告(CCSDS 133.0-B)の規格のうち、選択肢やオプションを含む規格に対する利用上の標準を示すものである。
この標準を説明するうえで関連した規格を各項目の本文中に記載する。規格文中、イタリック体部は標準があることを示す。この規格は CCSDS 133.0-B の要約であり、全ての規格を記載しているわけではないので、設計は CCSDS 133.0-B によること。なお、自明であり、CCSDS 133.0-B では記載されていない規格(例：Primary Header の Sequence Countは APID ごと)も、ここでは念のため記載した。
ここで示す標準は、CCSDS 133.0-B で汎用的に記載された規格を現在の JAXA 設計用に具体化したものであると共に用例を示すものであり、CCSDS 133.0-B の規格を変更するものではない。

4.1 スペースパケットプロトコルのコンセプトとアドレッシングの定義
4.1.1 CCSDS 勧告の標準規格
以下に、Space Packet Protocol の Concept と Space Packet の Addressing の定義を示す(図 4.1.1-1 参照)。
(1) Space Packet Protocol は、OSI 参照モデルの Network Layer に相当する。Space
Packet Protocol の Protocol Data Unit(PDU)は Space Packet という。
(2) Space Packet Protocol は、一つの Source User Application から一つまたは複数のDestination User Application へ、一つまたは複数の Subnetwork を介しての単方向
データ伝送で Space Packet を伝送する。
(3) Source User Application か ら Subnetwork(s) を 介 し て の Destination User
Application(s)への Path を Logical Data Path(LDP)と呼ぶ。

Layer
Network Layer

Data Link Layer
Physical Layer

Source User
Application
Space Packet
Protocol(Sending End)

Logical Data Path (LDP)

Space Packet
Protocol(Intermediate)

Local
Subnetwork

Destination User
Application

Space Packet
Protocol(Intermediate)
Intermediate
Subnetwork

Space Packet
Protocol(Receiving End)
Local
Subnetwork

CCSDS 133.0-B-1 Figure 2-1, Figure 2-2

図 4.1.1-1

Protocol Configuration と Logical Data Path (LDP)の例

27

JERG-2-403【注記 1】：Implementation では、図 4.1.1-1 に示した Source または Destinationの Space Packet Protocol 機能は User Application で実行する ことがある。このような場合、Space Packet Protocol の規格を実行する User
Application の部分は、Space Packet Protocol とみなす。
【注記 2】： User Application A と User Application B 間で、A から B と B から A の伝送を行う場合は伝送方向の異なる 2 つの LDP を必要とする。
(4) すべての LDP は、
Path Identifier(Path ID)によりユニークに識別(重複しない)される。
(5) 一つの Path ID は、一つの Application Process Identifier(APID)とその APID 修飾子(Qualifier)で定義する。
(6) APID 修飾子は APID の Domain Name であり、APID 達は一つの Domain Name 内
でユニーク(唯一)である。
(7) APID 修飾子は Space Packet プロトコルで定義されたデータ構造にはない。下位層の Subnetwork の一つまたは複数の Protocol によって伝送される。
(8) System または Subnetwork が一つの Naming Domain 内の APID 達を扱う場合、
APID

修飾子は使用する必要が無い。
(9) 宇宙-宇宙間または宇宙－地上間の通信リンクに TC Data Link Protocol、TM Data
Link Protocol または AOS Data Link Protocol を使用する場合の APID 修飾子はMaster Channel Identifier(MCID)である。MCID=Transfer Frame Version(TFVN) +Spacecraft Identifier(SCID)である。

4.1.2 JAXA の設計標準
4.1.2.1 User Application
以下に、User Application に関する標準を示す。
(1) User Application とは物理的機器を示すのではない。宇宙機システムの個々のApplication を示すものであり、ソフトウェアやハードウェアの個々のタスクとして良い。
(2) 従って、一つの機器には一つまたは複数の User Application が存在することもある。
また、複数の Computer(=複数機器)上で動作するソフトウェア(機能がハードウェアに依存しない)の場合の User Application は機器とは独立である。

4.1.2.2

Logical Data Path

以下に、Logical Data Path(LDP)に関する標準を示す。
(1) 現在の JAXA 宇宙機システムにおける Logical Data Path は、特殊な場合を除き、宇宙機の User Application から地上の User Application 間、地上の User Application から宇宙機の User Application 間,宇宙機の User Application から宇宙機の User

28

JERG-2-403

Application 間がある(図 4.1.2.2-1)。

Ground Segment

Space Segment (Spacecraft)
Logical Data Path (LDP)

Source User
Application

Layer

Space Packet
Protocol(Sending End)

Network Layer

Data Link Layer

Space Packet
Protocol(Intermediate)

Space Packet
Protocol(Intermediate)

OnboardSubnetwork

Physical Layer

Destination User
Application

Space Link
Subnetwork

Space Packet
Protocol(Receiving End)
GroundSubnetwork(a) 宇宙機 User Application から地上 User Application への LDP
Ground Segment

Space Segment (Spacecraft)
Logical Data Path (LDP)

Source User
Application

Layer

Space Packet
Protocol(Receiving End)

Network Layer

Data Link Layer

Space Packet
Protocol(Intermediate)

Space Packet
Protocol(Intermediate)

OnboardSubnetwork

Physical Layer

Destination User
Application

Space Link
Subnetwork

Space Packet
Protocol(Sending End)
GroundSubnetwork(b) 地上 User Application から宇宙機 User Application への LDP
Space Segment (Spacecraft)
Source User
Application

Layer
Network Layer

Logical Data Path (LDP)

Space Packet
Protocol(Sending End)

Data Link Layer

Destination User
Application
Space Packet
Protocol(Receiving End)

OnboardSubnetwork

Physical Layer(c) 宇宙機 User Application 間の LDP

図 4.1.2.2-1

代表的な Logical Data Path (LDP)(2) Logical Data Path は、
物理的には一つまたは複数の Subnetwork を経由する。
SourceUser Application A から Destination User Application B への Subnetwork の系が複数ある場合でも Logical Data Path は一つである。Logical Data Path は Source User
Application から Destination User Application への Path であり、経路には影響されない。
【注記】：Source User Application A から Destination User Application B へ S-Bandの RF 回線を経由する場合と X-Band の RF 回線を経由する場合があっても Path ID は一つである。

29

JERG-2-403

4.1.2.3 APID
以下に、APID に関する標準を示す。
(1) Telemetry Packet は、AOS Transfer Frame Version Number (‘01’) + SCID (8 bits)内で重複しなければ良い。ただし、CCSDS Reserved APID を除く。
(2) Telecommand Packet は、TC Transfer Frame Version Number (‘00’) + SCID (10 bits)
内で重複しなければ良い。ただし、CCSDS Reserved APID を除く。
(3) 使用できる APID 値は、4.3.2.1.2 節に記載する。

4.1.2.4 APID 修飾子
以下に、APID 修飾子(Qualifier)に関する標準を示す(1) 設計標準は、Space Link Subnetwork の Data Link Layer に AOS Data Link Protocolと TC Data Link Protocol を使用する。従って、APID 修飾子は MCID である。
(2) MCID=TFVN(Transfer Frame Version Number) + SCID(Spacecraft Identifier)である。
AOS Data Link Protocol の TFVN は 2(‘01’)、
TC Data Link Protocol の TFVN は 1(‘00’)
である。
【注記】
：Transfer Frame Version Number の定義を表 4.1.2.4-1 に示す。
表 4.1.2.4-1 Transfer Frame Version Number の定義
VersionBinary Encoded
Transfer Frame
NumberVersion Number
1‘00’
TM Transfer Frame
1‘00’
TC Transfer Frame
2‘01’
AOS Transfer Frame
3‘10’
Version 3 Transfer Frame

SANA[15]の TFVN

(3) したがって、テレメトリの APID は AOS Data Link の SCID(8 bits)内で重複しなければ良い。テレコマンドの APID は TC Data Link の SCID(10 bits)内で重複しなければ良い。

4.2 スペースパケットプロトコルのサービス
4.2.1 CCSDS 勧告の標準規格
4.2.1.1 サービスの特徴
Space Packet Protocol の Service の特徴を以下に示す。
(1) 事前設定サービス(Pre-configuration Services)
User は予め管理により設定された LDP を介してのみデータを送受する ことができる。

30

JERG-2-403(2) 単方向(一方向)サービス)( Unidirectional (one way) Services)
LDP の片端は、受信はできるが送信はできない。他端は、送信はできる が 受信はできない。
(3) 非同期サービス(Asynchronous Services)
User が伝送する Service Data Unit のタイミングの規定はない。
User は、Service Data Unit を伝送したいときに伝送できる。ただし、 Provider
によっては、Service Data Unit の発生頻度に制約をつける場合がある。
(4) 送達未確認サービス(Unconfirmed Services )送端は、データを受信した受端からの確認情報を受け取らない。
【注記】：CCSDS は Service User と Service Provider(Subnetwork)間のフロー制御
を推奨しない。
(5) 不完全サービス(Incomplete Services)
データ送達の完全性を保証しない。また、再送メカニズムも持たない。
(6) 伝送順番を保持しないサービス(Non–sequence Preserving Services)
送信ユーザが出力した Service Data Unit 列の順番は、LDP を通過することにより、保証されないことがある。
【注記】：Space Packet Protocol は品質サービスを保証するメカニズムを 持たない。
伝送品質は、Subnetwork の伝送品質に依存する。

4.2.1.2 サービスの要約
以下に、Space Packet Protocol の Service の種類とその要約を示す。
(1) Space Packet Protocol は、Packet Service と Octet String Service という 2 つのService がある(表 4.2.1.2-1)。
表 4.2.1.2-1 Space Packet Service と Octet String Service
Space Packet Service
Octet String Service
Packet Service は、Service User が生成した Space
Octet Service は、Service User が生成した 8
Packet を、LDP を介してそのまま伝送する。
ビットの整数倍のデータ(Octet String)を、LDPを介してそのまま伝送する。
Service User は、Space Packet を生成する。
Service User が出力した Space Packet は、Service
Service Provider は、Octet String に Packet
Herder を付加して(Space Packet の Format にな
Provider によりそのまま伝送される。
る)伝送する。

(2) 一つの LDP の Source と Destination は同じ Service である必要はない。例えば、
Source が Octet String Service で、一つまたは複数の Destination が Packet Service
でもよい。
(3) 2 つの Service とも Protocol Data Unit(PDU)は Space Packet である。
Packet Serviceの場合は、Service Data Unit も Space Packet である(表 4.2.1.2-2 参照)。

31

JERG-2-403

Service
PacketOctet String

表 4.2.1.2-2 サービスの概要
Service Data Unit
Protocol Data Unit
Space Packet
Space Packet
Octet String
Space Packet

CCSDS 133.0-B-1 Table 2-1, 2.2.2.1 Note

(4) Space Packet のデータ構造は 4.3 節に記載する。
Octet String のデータ構造は Space
Packet から Packet Primary Header を除いた Data、すなわち Packet Data Field のData である。

4.2.1.3 サービスの定義
表 4.2.1.3-1 に Packet Service と Octet String Service の定義を示す。
表 4.2.1.3-1 Packet Service と Octet String Service の定義
概説

Service の Parameters
・APID
・APID Qualifier・2nd Header Indicator

・QoS Requirement

・Data Loss Indicator

Packet Service
Packet Service は、Service User が生成した
Space Packet をそのまま LDP で伝送する。
Service User は 3.3 節に記載した規格とおりに Space Packet を生成すること。
Service User が生成した Space Packet は、Service Provider がそのまま伝送する(Shall)。

Octet String Service
Octet String Service は、Service User の一塊の Octet String(8 ビットの整数倍のデータ)を
LDP で伝送する。
Service Provider は、Octet String を Space
Packet の形(すなわち Packet Header を付加)にして伝送する(shall)。

APID は必須 Parameter である。LDP をユニークに識別するために APID Qualifier(必要な場合)と共に使用すること。
APID Qualifier は、Space Packet の APID に
APID Qualifier は、Octet String から生成した
関連した Optional Parameter である。APID Space Packet の APID に関連した Optional
Qualifier は、APID の Naming Domain の識別に Parameter である。APID Qualifier は、APID の使用する情報である。
Naming Domain の識別に使用するものである。
APID Qualifier を使用する場合、その情報はAPID Qualifier を使用する場合、その情報は下位層の Subnetwork が使用する
下位層の Subnetwork が使用する。
Secondary Header がある場合、Secondary
Header は Octet String の先頭に位置する。
Secondary Header の有無は Packet Primary
Header の Secondary Header Flag が示す。が、Octet String Service では、Packet Primary
NA
Header は Service Provider が付加する。
よって、Service Provider は Service User から送られる Secondary Header Indication
Parameter で Secondary Header Flag を生成する。
QoS(quality-of-service) Requirement は、各 Service が要求する Service の品質をあらわす
Optional Parameter である。
一つの Subnetwork が複数の QoS を持つ場合、QoS Requirement Parameter は QoS のレベルを選択するのに使用する。
（注記）
Telecommand (TC) Space Data Link Protocol を下位層の Subnetwork で使用する場合、QoS
Requirement は Type-A Service または Type-B Service である。Type-A Service/ Type-B Service
は個々の Space Packet に適用される。
Parameter である Data Loss Indicator は、
Destination に対して一つまたは複数の Octet
String が伝送中に損失したことを示す警告であNAる。
Packet の連続性は Packet Primary Headerの Packet Sequence Count で検証できるが、

32

JERG-2-403

Packet Service

Primitive Parameters
・Service Primitive・

Octet String Service
Octet String Service は Packet Primary Header
を User に伝送しない。そのため、Service
Provider が Packet Sequence Count で連続性を検証し、結果を Data Loss Indicator で User
へ通報する。
この Parameter：Data Loss Indicator はOptional Parameter であり、使用するか否かは
Implementation の仕様である。
Data Loss Indicator を Implementation する場
合は、設計時に宣言すると共に全 Octet String
User が使用できるようにする必要がある。

a) Packet. request,b) Packet. indicationa) OCTET_STRING.request;b) OCTET_STRING.indication

Sending End(送端)において、Packet Serviceの User は、規定された LDP を介して Receiving
End(受端)に Space Packet の伝送を要求するた
めに、Service Provider に PACKET. request
primitive を出力する。

Sending End の Octet String User は、Octet
String を定義された LDP で Receiving End のUser へ伝送するために、Service Provider に対して OCTET_STRING.request primitive を発行する(shall)。

（注記）
PACKET. request primitive は、Packet
Service における、Service Request Primitive
である。
PACKET. request(Space Packet,
APID,
APID Qualifier (optional),
QoS Requirement (optional))（注記）
OCTET_STRING.request primitive は Octet
String Service の Service Request Primitive である。
OCTET_STRING. request(Octet String,
APID,
APID Qualifier (optional),
Secondary Header Indicator,
QoS Requirement (optional))> When Generated

PACKET. request primitive は、Space Packet
伝送要求が発生したときに、Service Provider
へ出力する。

OCTET_STRING. request primitive は、Octet
String の伝送要求が発生したときに、Service
Provider へ出力する。

> Effect On Receipt

PACKET.request primitive の受理応答は、Space Packet を伝送する Service Provider が発
生する
Ｐａｃｋｅｔ.request primitive は、Space
Packets を APID と Optional APID Qualifier で識別された LDP で伝送するために使用する(shall)。

Service Provider は、
OCTET_STRING .request primitive を受理すると Octet String を伝送する(shall)。
OCTET_STRING. request primitive は、APIDと APID Qualifier と識別された LDP を通して
Octet Strings を伝送するために使用する(shall)。

Receiving End において、Service Provider
は、Packet Service User に Packet の着信を示す PACKET. indication を出力する(shall)。

Receiving End において、Service Provider
は Octet String Service User に Octet String が着信したことを示す
OCTET_STRING .indication を出力する(shall)。

・request> Function> Semantics> Comments

・indication> Function（注記）
PACKET. indication primitive は、Packet
Service における Service Indication Primitive である。

> Semantics

PACKET. indication (Space Packet,
APID,
APID Qualifier (optional))> When Generated

PACKET. indication primitive は、Service
Provider から Packet Service User へ Receiving
End において Packet が着信したときに通知す

33

（注記）
OCTET_STRING. indication primitive はOctet String Service における、Service
Indication Primitive である。
OCTET_STRING. indication(Octet String,
APID,
APID Qualifier (optional),
Secondary Header Indicator,
Data Loss Indicator (optional))
OCTET_STRING. indication primitive は、Receiving End において、Service Provider からOctet Service User へ Octet String を受信した

JERG-2-403> Effect On Receipt> Comments

Packet Service
る(shall)。
受信した PACKET. indication primitive に対する処理は定義しない。
PACKET. indication primitive は、APID とAPID Qualifier で識別された Packet Service
User に Packet の着信を通知するために使用する。

Octet String Service
ときに出力する(shall)。
受信した OCTET_STRING. indication
primitive に対する処理は定義しない。
OCTET_STRING. indication は、APID とAPID Qualifier で識別された Octet String
Service User に Octet String の着信を通知するために使用する。

4.2.2 JAXA の設計標準
4.2.2.1 サービス
以下に、Service に関する標準を示す。
(1) Packet Service を適用することを原則とする。理由を以下に示す。
(2) Packet Service と Octet String Service の違いは、Packet Primary Header を Service
User が付加するか/Service Provider が付加するかの違いである(図 4.2.2.1-1)。
なお、Implementation では、Source (Sending User)または Destination(ReceivingEnd)の Space Packet Protocol 機能は User Application で実行する ことがある。このような場合、Space Packet Protocol の機能を実行する User Application の部分は、Space Packet Protocol とみなす(CCSDS 勧告)。

①

Sending End

Receiving End

Octet String 出力

Octet String 入力

Packet Data
Field

②

Packet Primary
Header 付加

Packet Data
Field

Packet Primary
Header 除去

Space Packet

Packet Transfer③

Service
User

Sending End

Receiving End

Octet String 出力

Octet String 入力

Packet Data
Field

Packet Primary
Header 付加

Space Packet

Packet Transfer

Subnetwork(s)Service
ProviderPacket Data
Field

Packet Primary
Header 除去

Space Packet

Packet Transfer

Space Packet(b) Octet String Service①：User Application②：Space Packet Protocol、Network Layer③：Subnetwork(s)、Data Link Layer & Physical Layer (MIL-STD-1553B、SpaceWire, etc)

図 4.2.2.1-1 Packet Service と Octet String Service(3) Space Packet Protocol の Concept は、一つの Source User Application から一つまたは複数の Destination User Application へ、一つまたは複数の Subnetwork を介しての単方向データ伝送で Space Packet を伝送することである。従って、Packet
Service を適用することを原則とする。

34②

Packet Transfer

Subnetwork(s)(a) Packet Service①③

JERG-2-403【注記 1】： Space Communication は Space Packet が伝送最小単 位 ある。
【注記 2】：Octet String Service は、Packet を生成しない古い機器を搭載するような場合に適用する Service である。

4.2.2.2 QoS.request
以下に、Quality of Service(品質サービス)に関する標準を示す。
(1) Space Packet Protocol は伝送品質のサービスを持たない。
(2) QoS .request は、下位の Subnetwork が複数の伝送品質サービスを持つ場合、伝送を要求する Packet ごとに伝送品質サービスを指定する。
(3) Space Link Subnetwork について、Telemetry (AOS Data Link Protocol 適用)の伝送
品質サービスは一つである(指定の必要は無い)。Telecommand (TC Data Link
Protocol 適 用 ) の 伝 送 品 質 サ ー ビ ス は 、 Type-A(Sequence Control Service) とType-B(Expedited Service)の 2 つがある(指定を要する)。

4.3 プロトコルデータユニット
Space Communication の End to End Protocol に適用する Space Packet Protocol のProtocol Data Unit (PDU)を Space Packet と呼ぶ。
一般に PDU に付加される Header は Protocol 情報であるが、Space Packet の Header
は Protocol 情報以外の情報も含んでいる。また、Header の Protocol 情報は固定値のほかに、User Application や宇宙機プロジェクトがある制約の下で決定する値がある(付録 1 および付
録 2)。

4.3.1

CCSDS 勧告の標準規格

4.3.1.1 スペースパケット(1) 図 4.3.1.1-1 に Space Packet の構造を示す。
(2) Space Packet は Packet Primary Header と Packet Data Field で構成する。
(3) Packet Data Field は Packet Secondary Header と User Data Field で構成する。
[注記]：Packet Data Field は Packet Secondary Header + User Data Field のほかに、
Packet Secondary Header のみ、User Data Field のみでも良い。
(4) Packet Primary Header 長は、6 octets(固定長)である。
(5) Packet Secondary Header 長と User Data Field 長は共に可変長であり、(Packet
Secondary Header + User Data Field)長は 1 octet から 65,536 octets である。
[注記]：Packet Data Field の最大長は、下位の Subnetwork の制約等を考慮して、宇宙機プロジェクト毎に 1 octet から 65,536 octets の範囲内で規定すること。

35

JERG-2-403

Space Packet
Packet Data Field

PacketPrimary
HeaderPacketSecondaryHeaderFixed
6 octets

User Data Field

Variable

Variable
1 to 65536 octets

CCSDS 133.0-B-1 Figure 4-1: Space Packet Structure Components

図 4.3.1.1-1

Space Packet の構造

4.3.1.2 パケットプライマリヘッダ
図 4.3.1.2-1 に Packet Primary Header の構造を示す。
Packet Primary Header
PacketPacket Sequence
Identification
Control
PacketSec.
Application Sequence
PacketType
HDR
Process
Flags
Sequence
Flag
Identifier
Count or
Packet
Name
1 bit
1 bit
11 bits
2 bits
14 bits
2 octets
2 octets

PacketVersionNumber3 bitsPacket
Data
Length16 bits
2 octets

CCSDS 133.0-B-1 Figure 4-2: Packet Primary Header

図 4.3.1.2-1

Packet Primary Header の構造

以下に、Packet Primary Header の規格を示す。

4.3.1.2.1 Packet Version Number(1) Packet Version Number は Packet の種類を識別する識別子である。
(2) Packet Version Number 値は全 Space Packet とも同じ値である。
(3) Space Packet の Packet Version Number は 1 であり、値は ’000’ 固定である(必須)。
【注記】：Packet Version Number は CCSDS SANA[15]で規定される。この規定を
表 4.3.1.2.1-1 に示す。
表 4.3.1.2.1-1 Defined Packet Version Number

VersionNumber1
2
8

Binary Encoded
Version Number
‘000’
‘001’
‘111’

PacketSpace Packet
SCPS-NP
Encapsulation Packet

SANA[15] の Packet Version Number

4.3.1.2.2 Packet Type
(1) Space Packet の伝送方向は 1 方向である。Packet Type は Packet の伝送方向を示

36

JERG-2-403

す。
(2) Packet Type 値は APID ごとの固定値である。
(3) Telemetry (or Reporting) Packet の Packet Type 値 は ‘0’ 、 Telecommand (orRequesting) Packet の Packet Type 値は ‘1’ とする(必須)。
【注記】：Telemetry (or Reporting) Packet および Telecommand (or Requesting)の厳密な定義は宇宙機プロジェクトが定義してよい。

4.3.1.2.3 Secondary Header Flag
(1) その Packet が Secondary Header を含むか含まないかの識別子である。
(2) Secondary Header Flag 値は APID ごとの固定値である。
(3) Secondary Header Flag が有る場合の Secondary Header Flag 値は ‘1’ であり、無い場合は ‘0’ である(必須)。

4.3.1.2.4 Application Process Identifier (APID)(1) APID は Packet の Path ID(4.1.1 項参照)の一部である。
(2) APID 値範囲は、0 から 2039 (Decimal)である(必須)。
(3) APID 値 2040 から 2047 は CCSDS が定めた識別子であり、CCSDS が定めた目的以外に使用しないこと(必須)。
(4) APID 値 2047 は、CCSDS が定めた Idle Packet 識別子である(必須)。
【注記】：CCSDS が定めた識別子は SANA[15]で規定される。この規定を
表 4.3.1.2.4-1 に示す。
表 4.3.1.2.4-1 Reserved Application Process Identifiers
APID(decimal)
2040-2046
2047

Utilization
CCSDS Reserved
Idle Packet（SANA[15]の APID）

4.3.1.2.5 Sequence Flag
(1) Sequence Flag は Space Packet Protocol 情報ではない。
(2) Sequence Flag は、Space Packet の User Data に更に上位の意味がある場合、その関連を示すものであり、Packet Service の User が使用する。
【注記】：Octet String User は、Sequence Flag を使用できない。値は ’11’ 固定である(必須)。
(3) Sequence Flag の定義を表 4.3.1.2.5-1 に示す(必須)。

Sequence Flag 値
‘00’
‘01’
‘10’
‘11’

表 4.3.1.2.5-1 Sequence Flag の定義(必須)定義
Packet User Data が上位 Application Data の中間であることを示す。
Packet User Data が上位 Application Data の先頭であることを示す。
Packet User Data37が上位 Application Data の後尾であることを示す。
上位 Application Data が無いことを示す。

JERG-2-403

4.3.1.2.6 Packet Sequence Counter or Packet Name
(1) Packet Name は特定の Packet が同じ Communication Session 中に発生する Packet
に関して特定される場合に使用することが Telecommand Packet のみに許容されているもの である。
(2) Packet Sequence Counter は、APID ごとに、Packet の伝送順番を示す Binary
Counter である(必須)。
(3) Packet Sequence Counter 値は、modulo-16384 の Binary Counter であり、Packetを出力するたびに+1 Count Up する(必須)。
(4) Packet Sequence Counter 値は、0 から 16,383 まで Count し、16,383 の次は 0 となる連続値である(必須)。
(5) やむを得ない場合を除き、16,383 に達する前に’0’にしないこと(必須)。
【注記 1】：Packet Sequence Counter は、受信側で Packet の伝送順番を確認するために使用される。16,383 に達する前に’0’になるとパケットの伝送順
番が分からなくなる。受信側は、16,383 に達する前(例えば n) に’0’になると、n+1 か ら 16.383 の Packet は欠落したと認識する。
【注記 2】：一回の伝送(例えば一回の可視)において、Packet Sequence Counter
値が一巡してしまう場合がある。受信側は同一 Packet Sequence
Counter 値の Packet を複数受信するので、伝送順番が分からなくなる。
このような場合は、Packet Secondary Header の Spacecraft Time を参照する。Spacecraft Time の分解能(LSB 値)は、Packet 発生間隔より短い必要がある。

4.3.1.2.7 Packet Data Length(1) Packet Data Length は、
Packet Primary Header に続く Packet Data Field 長を示す。
【注記】：Packet Length は、一つの APID 内で変化してよい。
(2) Packet Data Length の値は、Packet Data Field 長(単位：octet)-1 の Binary Data である(必須)。
【注記】：Packet Data Length 値=0 は、Packet Data Field 長が 1 octet であることを 表す。
Packet Data Length 値= ‘all 1’ は、Packet Data Field 長が 65,535+1=65,536 octets(最大パケット長)であることを示す。
【 例 】：Packet Data Field 長が 512 octets の場合。Packet Data Length の値は、512-1=511 の Binary Data = ‘ 0 0000 0001 1111 1111’ である。
(3) 一般的に、Subnetwork の Protocol の制約(伝送容量等を含む)等により、各宇宙機プ
ロジェクトがプロジェクトごとに最大 Packet 長を規定する。

38

JERG-2-403

4.3.1.3 パケットセカンダリヘッダ
図 4.3.1.3-1 に Packet Secondary Header の構造を示す。
Packet Secondary Header
Time Code
Field

Ancillary Data
Field

Variable

Variable

CCSDS 133.0-B-1 Figure 4-3: Packet Secondary Header

図 4.3.1.3-1 Packet Secondary Header の構造

以下に、Packet Secondary Header の規格を示す。
(1) User Data が無い Space Packet の場合、Packet Secondary Header は必須である。
(2) User Data がある Space Packet の場合、Packet Secondary Header はオプションである。
(3) Packet Secondary Header の有無は、ミッション期間中に変更してはいけない(必須)。
(4) Packet Secondary Header は Time Code と Ancillary Data で構成する(必須)。
(5) Packet Secondary Header の構成は、Time Code のみ、Ancillary Data のみ、またはTime Code と Ancillary Data である(必須)。
【注記】：Packet Secondary Header は、Packet 中に Time Code と Ancillary Data
(Ancillary Data は宇宙機の位置や姿勢情報等)のデータ領域を標準化するために CCSD が定義したものである。Protocol に必要な要求ではない。

4.3.1.3.1 Time Code Field(1) Time Code Format は、CCSDS 301.0-B: Time Code Format の CCSDS Segmented
または Unsegmented Binary Code である(必須)。
(2) 特定の Path ID において、Time Code Format が固定の場合、P-Field は省略してもよい(伝送しなくてもよい)。特定の Path ID において、Time Code Format を変更する場合、P-Field は使用する(必須)。
(3) P-Field の有無に関わらず、Time Code Format は、ミッション期間中変更しない (必須)。

4.3.1.3.2 Ancillary Data
(1) Ancillary Data は、Space Packet の User Data Field の情報を解釈するので必要な補助的情報である(必須ではないが使用することが好ましい)。
(2) CCSDS は、Ancillary Data Field のデータ内容やフォーマットを規定しない。

39

JERG-2-403

4.3.1.4 User Data Field(1) Packet Secondary Header が無い場合、User Data Field は必須である。
(2) Packet Secondary Header がある場合、User Data Field はオプションである。
(3) User Data Field の Data は、Sending User が伝送する Application Data である(必須)。

4.3.1.5 アイドルパケット
Idle Packet とは Application Data を持たない Packet である。発生するのは送信側 Space
Data Link Protocol であり、受信側 Space Data Link Protocol で廃棄する。
Idle Packet の規格を以下に示す。
(1) Idle Packet のデータ構造を図 4.3.1.5-1 に示す。

PacketVersionNumber‘000’
3 bitsPacket Primary Header
PacketPacket Sequence
Identification
Control
Packet Sec.
Application
Sequence
PacketType
HDR
Process
Flags
Sequence
Flag
Identifier
Count or
Packet Name
‘1’ /”0’‘0’‘all 1’
‘11’
固定値
1 bit
1 bit
11 bits
2 bits
14 bits
2 octets
2 octets

Packet
Data
LengthC-1
16 bits
2 octets

Packet Data
Field
User Data
Field
Idle Data
1 to 65536 octets
C octet(s)図 4.3.1.5-1 Idle Packet の構造(2) Packet Version Number は’000’である(必須)。
(3) Packet Type は’1’でも’0’でも良い。
(4) Secondary Header Flag は’0’ ある(必須)。Secondary Header は付加できない。
(5) APID 値は ‘all 1’ (111 1111 1111 )である(必須)。
(6) Sequence Flag は’11’である。
(7) Packet Sequence Counter は Count Up しない(必須)。
(8) User Data Field の Data は Idle Data である(必須)。
CCSDS は Idle Data の Bit Patternを規定しない。

4.3.2 JAXA の設計標準
4.3.2.1 プライマリヘッダ
4.3.2.1.1 Packet Type
以下に、 Packet Type に関する標準を示す。
(1) Telemetry( or Report) Packet は Space Segment から Ground Segment へ伝送する
Packet とし、Packet Type=’0’とする。

40

JERG-2-403(2) Telecommand ( or Request) Packet は Ground Segment から Space Segment へ伝送する Packet とし、Packet Type=’1’とする。
(3) Source と Destination が Onboard Subnet 内である Packet は、宇宙機プロジェクト毎に規定する。ただし、Time Code Packet と Ancillary Data Packet は Packet
Type=’0’とする。

4.3.2.1.2 APID 値
以下に、APID 値に関する標準を示す。
(1) APID は User Application の識別であり、物理的機器の物理アドレスではない。宇宙機システムの個々の Application を示すものであり、ソフトウェアやハードウェアの個々のタスクに割り振って良い。
(2) APID の値は、0 から 2039 (Decimal)である。Idle Packet は，APID 値 2047 を使用する。
(3) Packet Type=’0’の Packet の APID 値は、AOS Transfer Version Number(‘01’) +SCID(8bits)内で重複しなければ良い。
(4) Packet Type=’1’の Telecommand(or Request) Packet の APID 値は、TC Transfer
Version Number(‘00’) + SCID(10bits)内で重複しなければ良い。
(5) APID の付与方法に規定はない。宇宙機プロジェクト毎に定義してよい。一般的に、データ種別識別、Payload/Subsystem 識別、データ識別にセグメント化する場合が多い(例：表 4.3.2.1.2-2)。

上位 3bits
データ種別識別

表 4.3.2.1.2-2

Packet の APID 付与例

中位 4bits

下位 4bits

Payload、Subsystem ID

データ識別

宇宙機プロジェクト 宇宙機プロジェクトが Payload、
各 Payload、Subsystem
Subsystem ごとに定義して付与する。
が定義する。
が定義する。
上位 3bits の例：
Telecommand の場合 ‘111’：リアルタイムコマンド、‘110’：絶対時刻指定コマンド 等
Telemetry の場合‘000：ＨＫデータ、‘011’：ダンプデータ、‘101’：観測データ 等

4.3.2.1.3 Sequence Flags
以下に、Sequence Flag に関する標準を示す。
(1) 一つの Packet の User Data はある意味の一塊のデータである。
(2) ある APID の Packet が連続した複数 Packet で、更に上位の意味があるとき(Packet
列がある区切りで意味を持つ)に Sequence Flag を使用する。
【注記】：Sequence Flag を使用できるのは Packet Service のみである。Octet String
Service は’11’固定である。

41

JERG-2-403(3) Sequence Flag の使用例を図 4.3.2.1.3-1 に示す。
例 1：ある APID の Packet が連続した複数 Packet により更に上位の意味を持たない場合である。Sequence Flag は’11’である。
例 2：伝送したい User Data 長が、最大 Packet 長で伝送できない場合である。
【注記】：最大 Packet 長は、宇宙機プロジェクトごとに最大 Packet 長を規定する(最大長は CCSDS 勧告の標準規格である)。
User Data 長をいくつかに区切り、先頭データの Packet の Sequence
Flag=’01’、一つまたは複数の中間データの Packet の Sequence Flag=’00’、後尾データの Packet の Sequence Flag=’10’とする。
例 3：観測対象が異なった Packet 列である。
観測対象ごとに、先頭 Packet の Sequence Flag=’01’、一つまたは複数の中間 Packet の Sequence Flag=’00’、後尾 Packet の Sequence Flag=’10’とする。
例 4：複数ラインでフィールドを形成する画像で、1 Packet=1 ラインデータで伝送する場合である。
フィールド先頭ラインの Packet の Sequence Flag=’01’、 一つまたは複数のフィールド中間ラインの Packet の Sequence Flag=’00’、 フィールド後尾ラインの Packet の Sequence Flag=’10’とする。
【注記】：Sequence Flag=’01’の Packet の Packet Sequence Counter を 0 にしない(Reset しない)こと。Packet Sequence Counter は Sequence Flag とは独立の連番で ある。

42

JERG-2-403

User DataPH
APID
Seq. CNT
Seq. Flag

UD

A
n
‘11’
<単独>

(a) 例 1：上位の意味が無い場合(単独 Packet)

User Data

APID
Seq. CNT
Seq. Flag

PH UD

PH

UD

PH

A
n-1

A
n
‘01’
<先頭データ>An+1‘11’or ‘10’

PH

UD

UD

PH

A
n+m

‘00’
<中間データ>

PH

UD

A
n+m+1

‘00’
<中間データ>

UD

A
n+m+2
‘11’or ‘01’

‘10’
<後尾データ>(b) 例 2：User Data 長が最大パケット長超える場合の User Data の伝送

観測 A

観測 X

APID
Seq. CNT
Seq. Flag

PH UD

PH

UD

PH

A
n-1

A
n
‘01’
<観測 A 先頭>An+1

‘11’or ‘10’

観測 Y
PH

UD

UD

PH

A
n+m

‘00’
<観測 A 中間>‘00’
<観測 A 中間>

UD

UD

PH

A
n+m+1

A
n+m+2

‘10’
<観測 A 後尾>

‘11’or ‘01’(c) 例 3：観測モード、観測領域等の識別

User Data

画像のライン データ。
画像のフィールド。

t

APID
Seq. CNT
Seq. Flag

PH UD

PH

A
n-1

A
A
n+1
n
‘01’
‘00’
<フィールド先頭 <フィールド中間>

‘10’

UD

PH

PH

UD

UD

PH

A
n+m
‘00’
<フィールド中間

UD

A
n+m+1

PH

UD

A
n+m+2

‘01’
‘10’
<フィールド後尾>(d) 例 4：画像のフィールド識別

UD: User Data
PH: Packet Primary Header

図 4.3.2.1.3-1

Seq. CNT: Sequence Counter
Seq. Flag: Sequence Flag

Sequence Flag の使用例

43

JERG-2-403

4.3.2.1.4 Packet Sequence Count or Packet Name
以下に、Packet Name に関する標準を示す。
(1) Packet Name は特定の Packet が同じ Communication Session 中に発生する Packet
に関して特定される場合に使用することが Telecommand Packet のみに許容されているもの (CCSDS 勧告)であるが、設計標準では Packet Sequence Counter のみの使用に統一する。

4.3.2.2 セカンダリヘッダ
以下に、Secondary Header に関する標準を示す。
(1) すべての Telemetry( or Report) Packet は、必ず Secondary Header の Time Codeを使用して、Packet 生成時刻(Time Stamp)を伝送すること。時刻は Onboard DH
が配信する宇宙機時刻であること。
(2) Telemetry( or Report) Packet に付加する Secondary Header の Time Code の分解能
(LSB 値)は、1 回の可視で伝送する Packet の Packet Sequence Counter が一巡する
時間より短いこと。
(3) 絶対時刻指定 Telecommand Packet は、必ず Secondary Header の Time Code を使用して、Command 実行時刻を伝送すること。時刻は Onboard DH の宇宙機時刻であること。
(4) 観測データ等の Packet で、宇宙機の位置、姿勢等の補助データ(Ancillary Data)を必要とする場合は、Secondary Header の Ancillary Data 領域で伝送する。
(5) Secondary Header のデータ構造は、宇宙機プロジェクトごとに定める。

4.3.2.2.1 Time Code Format
以下に、Time Code Format に関する標準を示す。
(1) CCSDS 勧告の標準規格は、CCSDS 勧告の Segmented Binary Time Code または
CCSDS Unsegmented Binary Time Code である(関連文書[11])。
(2) CCSDS Unsegmented Binary Time Code の CUC(CCSDS Unsegmented TimeCode)を標準とする。
(3) CUC のデータ構造を図 4.3.2.2.1-1 に示す。

44

JERG-2-403

P-Field

Extension
Flag
‘0’
1 bit

Detail bits forTime CodeInformation on the Code
ID
(A)
(B)
‘001’ or ‘010’‘11’‘00’～’11’
3bits
2bits
2bits
1 octeta. Extension Flagb. Time Code IDc. (A)

d. (B)

T-Field
Basic Time(旧 Coarse Time)
231s・・・20ｓ

Fractional Time(旧 Fine Time)
2-1s・・・

4 octets

0～3 octets
CCSDS 301.0-B-4 Section 3.2：‘0’固定 (Extension Data が無いことを示す)：‘001’は 1958 January 1 Epoch (国際原子時 TAI の Epoch) を示す、’010’
は Agency-Defined Epoch を示す。
どちらを適用するかは、各宇宙機プロジェクトが決定する。
：Basic Time(LSB=1s)長を示す。
(Number of Octets of Basic Time) - 1 であらわす。
CCSDS 勧告の標準規格は、1 octets～4octets であるが、標準は 4 octets とする( (A)=’11’ )。
：Fractional Time(MSB=0.5s)長を示す。
(Number of Octets of Fractional Time) であらわす。
CCSDS 勧告の標準規格は、0 octets～3 octets である。この長さは各宇
宙機プロジェクトが決定する（一般に、HK Data Packet や Command Packet
は 0 octet、観測データ Packet は観測精度等に適合した有限長である)。
図 4.3.2.2.1-1 Secondary Header の Time Code Format

4.3.2.2.2 Ancillary Data
以下に、Ancillary Data に関する標準を示す。
(1) Ancillary Data は、Payload 取得した観測データの解析などに必要な宇宙機の位置や姿勢情報等の補助データとする。
(2) Ancillary Data の情報や Data Format は、宇宙機プロジェクトごとに決定する。

4.3.2.3 アイドルパケット
以下にアイドルパケットに関する標準を示す。
(1) アイドルパケットの Packet Type 値は'0'とする。
(2) アイドルパケットの Packet Sequence Counter 値は、all '0'とする。
(3) アイドルパケットの User Data Field 値は、all '0'とする。

4.3.2.3.1 アイドルパケットの使い方
Idle Packet (APID=’all 1’)は Space Packet Protocol で使用するものではなく、Space Linkの Data Link Protocol で使用するものである。
Idle Packet は End-to-End Protocol に関与しないが、Idle Packet の PDU は Space Packet
Protocol で規定されるので、以下に使い方の例を示す。

45

JERG-2-403

Idle Packet は、一般に、Telemetry で使用する。一般的な使い方は、Telemetry Packet 待ちの状態における M_PDU の完成【使い方-1】と伝送する Telemetry Packet が無いときの
CLCW の伝送【使い方-2】である。
【使い方-1】(1) M_PDU 生成中に、次の Telemetry Packet 待ちの状態において、その M_PDU を完成させて伝送したい場合、
Idle Packet を挿入して M_PDU を完成させる(図 4.3.2.3-1)。

Packet

A

B
t

M_PDU

M_PDU
HeaderA

Idle Packet
・Idle Packet を挿入して M_PDU を完成させる。
・Packet A は Packet B を待たずに伝送できる。

図 4.3.2.3-1 Idle Packet 挿入による N_PDU の完成(2) このような使い方は、Packet 処理遅延を短くしたい場合や、Storage した Packetの再生において最後の再生 Packet で M_PDU が完成しなかった場合に使用する。
【使い方-2】(1) 伝送する Telemetry Packet がないときに CLCW は伝送したい場合に、Idle Packet
のみで生成した M_PDU を伝送する(図 4.3.2.3-2)。
(2) Idle Frame を伝送すると、CLCW は伝送されない(図 4.3.2.3-2)。
VC_OCF Service User

Packet Service User

CLCW

PacketIdle Packet
Construction of M_PDU andGeneration First Header Pointer
M PDU
Transfer Frame Generation
VC Frame

Idle Frame

Multiplexing

AOS Data Link Protocol
CCSDS 732.0-B
Figure 4-6, 4-8 & 4-9.

MC Frame(この図は Sending End である)

: Multiplexing (Sending End) or Demultiplexing (Receiving End)
: Commutate (Sending End) or Decommutation (Receiving End)
: Data Flow Sending End↓、Receiving End⇒↑図 4.3.2.3-2 Idle Packet と Idle Frame

46

JERG-2-403

4.4 パケット伝送の仕組み
4.4.1 CCSDS 勧告の標準規格
4.4.1.1 プロトコルの内部構造(1) 図 4.4.1.1-1 に、Space Packet Protocol の内部構造を示す。
【注記】：図 4.4.1.1-1 は、Hardware や Software の Implementation を示すものではない。
Sending End
Octet String Packet
Service
Service

Intermediate System

Octet
StringPacketService

Octet
StringSpace Packet Protocol

PacketAssembly
PacketReceiving End
Octet String
Service

PacketExtraction

PacketPacketPacket Transfer

Path Recovery

Packet Relay

PacketPacketSubnetwork

PacketPacketPacketSubnetwork

Subnetwork
注：矢印はデータが流れる方向を示す。

図 4.4.1.1-1 Space Packet Protocol の内部構造

4.4.1.2 Sending End
4.4.1.2.1 Packet Assembly Function(1) Packet Assembly Function は、Octet String Service に使用する。
(2) Octet String Service の User Application から Octet String を入力して、Packet
Primary Header を付加して Space Packet を生成する。
(3) Packet Primary Header の Secondary Header 値は、Octet String Service の User
Application から通知される Secondary Header indicator 値をそのまま入れる。
(4) Packet Primary Header の Packet Sequence Count は、この Packet Assembly
Function で生成する。

4.4.1.2.2 Packet Transfer Function(1) Packet Transfer Function は、下位層の Subnetwork で使用する Service の Protocol
へ Packet を転送する。
(2) Packet Transfer Function は、必要に応じて、Packet Service User 達と Packet
Assembly からの Space Packet を Management で設定された順で待ち行列に入れて多重化する。
CCSDS は Space Packet 多重化の Algorithm を規定しない。
Algorithm
は、各宇宙機プロジェクトが優先度やパケット発生頻度等を考慮して定義する。

47

JERG-2-403(3) Packet Transfer Function は、待ち行列にいる Packet の Path ID をみて次の伝送先
Protocol を識別し、下位層の Subnetwork において使用する Service へ Packet を転送する。
(4) Packet Transfer Function は複数の Protocol に Packet を伝送することもできる。なお、この複数の Protocol は、すべて同じ Subnetwork であるとは限らない。すなわ
ち Multicast(同報) Function を持つこともある。

4.4.1.3 Intermediate System(1) Packet Relay(中継) Function は、下位層の Subnetwork の Service を利用する LDP
において、次の Protocol に Space Packet の Relay に使用する。
(2) Packet Relay Function は下位層の Subnetwork から Space Packet を受理し、Management によって設定される待ち行列に入力する。CCSDS はこの Algorithmを規定しない。Algorithm は、各宇宙機プロジェクトが優先度やパケット発生頻度等を考慮して定義する。
(3) Packet Relay Function は、待ち行列にいる Packet の Path ID をみて次の伝送先
Protocol を識別し、下位層の Subnetwork において使用する Service へ Packet を転送する。
(4) APID Qualifier(Optional)が使われる場合、受理した Packet の APID Qualifier は、
Packet を伝送した Subnetwork の Service で検索する。APID Qualifier(Optional)が使われない場合、Path ID はその Packet の APID から直接得られる。
(5) Packet Relay Function は複数の Protocol に Packet を伝送する(may)。なお、この複数の Protocol は、すべて同じ Subnetwork であるとは限らない。すなわちMulticast(同報) Function を持つこともある。
(6) Packet Relay Function は、Packet の一時蓄積(Store)を行う。
(7) 次の伝送先 Protocol へ Packet を伝送する際に、ある理由により即座に転送することが不可能である場合または非実現的である場合に、Intermediate System のStorage Service を使用する。なお、CCSDS は Packet の Temporary Storage の手順は規定しない。

4.4.1.4 Receiving End
4.4.1.4.1 Packet Extraction Function(1) Packet Extraction Function は、Octet String Service に使用する。
(2) Packet Extraction Function は、Path Recovery Function から Space Packets を受けて、Packet Primary Header を除去ことによって、Octet Strings を抽出する。
(3) Extraction Function は 、 Octet Strings 先 頭 領 域 に Packet Secondary Header
Secondary が存在することを示すために Header Indicator parameter を発生する。

48

JERG-2-403(4) Extraction Function は、Packet Sequence Count で Packet 伝送の連続性を検証し、欠落があった場合は Data Loss Indicator parameter を発生する。この Function はOptional である。

4.4.1.4.2 Path Recovery Function(1) Path Recovery Function は下位層の Subnetwork から転送される Space Packet を入力し、必要に応じて、各 Packet の Path ID に基づき、 Demultiplexing する。
(2) APID Qualifier(Optional)が使われる場合、受理した Packet の APID Qualifier は、
Packet を伝送した Subnetwork の Service で検索する。
(3) APID Qualifier(Optional)が使われない場合、Path ID はその Packet の APID から直接得られる。
(4) ある Path ID の Receiving User が Packet Service である場合、受理した Space
Packet は Path ID で識別された User へそのまま伝送する。
(5) ある Path ID の Receiving User が Octet String Service である場合、受理した Space
Packet は Packet Extraction Function を介して User へ伝送する。

4.4.2 JAXA の設計標準
以下に、プロトコル内部構造に関する標準を示す。
(1) Packet Service を標準とするので、Packet Assembly Function および Packet
Extraction Function は使用しない。
(2) 設計標準は、APID Qualifier を使用しない(APID Qualifier は一つなので省略される)
ので、Path ID=APID である。

4.5 管理パラメータ
4.5.1 CCSDS 勧告の標準規格
4.5.1.1 概説(1) Space Packet Protocol の Parameter は、In-Line メカニズムではなく、Managementとして扱う。
(2) 一般に、Managed Parameter の変更は、大きな Protocol Configuration の変更になるため、行わない。
(3) Space Packet Protocol で使用する Managed Parameter は、Protocol Configuration
Parameter と Routing Parameter の 2 つのカテゴリに分類できる。
【注記】ここで規定する Parameter は、Hardware や Software の Implementation を示
すものではない。

49

JERG-2-403

4.5.1.2 Protocol Configuration に関する Parameter(1) 表 4.5.1.2-1 に、Space Packet Protocol Configuration に関する Parameter を示
す。
表 4.5.1.2-1 Protocol Configuration Parameters
Managed Parameter
Allowed Values
Maximum Packet Length
Integer
Packet Type of Outgoing Packets
0, 1(Used only by sending systems)
Packet Multiplexing Scheme
Mission Specific(used only sending and Intermediate systems)
Service Type
Packet Service, Octet String Service(This Parameter is specified for each Path ID at
the sending and receiving ends of the LDP)CCSDS 133.0-B-1 Table 5-1

4.5.1.3 Routing に関する Parameter(1) 表 4.5.1.3-1 に、Routing に関する Parameter を示す。
(2) これらの Parameter は、各 Path ID の一つの Sending End System と LDP 中の一つ
または複数の中間 system において規定する。
表 4.5.1.3-1 Routing Parameters
Managed Parameter
Allowed Values
Subnetwork Identifier of the next Space Packet
Mission SpecificProtocol entity in the LDP
Subnetwork Address on the next Space Packet
Subnetwork SpecificProtocol entity in the LDP
APID Qualifier of the LDP (if used)
Mission Specific

CCSDS 133.0-B-1 Table 5-2

4.5.2 JAXA の設計標準
以下に、Managed Parameter に関する標準を示す。
(1) Managed Parameter は通信を行う前に、予め定めておくものである。
(2) Managed Parameter 値は、一つの宇宙機プロジェクトのミッションライフ中に変更
しないこと。
(3) Service は Packet Service を標準とする。APID Qualifier は使用しない。
(4) 付録 1 に Managed Parameter を含み宇宙機プロジェクト毎に設定する仕様(宇宙機プロジェクト毎に異なってよい仕様)、付録 2 に User Application が設定する仕様(User Application 毎に異なってよい仕様)示す。

50

JERG-2-403

付録 1 宇宙機プロジェクトが規定する仕様
この付録は、End-to-End Protocol(Space Packet Protocol を適用)において、宇宙機プロジ
ェクトごとに規定する項目(付表 1-1)を示す。
付表 1-1 宇宙機プロジェクトが規定する仕様
許容値

備考

01

最大パケット長Maximum Packet Length

項目

7 から 65,542 octets とする・一種類である必要は無い。
・HK DATA、Command、観測データごと等に最大長を規定してよい。

02
03

APID の付与
Packet Secondary Header
Time Code Fine Time 長

0 から 2039 (Decimal)
0～8 octets

・宇宙機監視制御用・HK Data Time Stamp(Telemetry)用およびコマンド実行絶対時刻指定(Telecommand)用。

04

Packet Secondary Header
Mission SpecificAncillary Data Format
05
Packet Type of Outgoing Packets
0, 1
06
Packet Multiplexing Scheme
Mission Specific07
Subnetwork Identifier of the next
Mission SpecificSpace Packet Protocol entity in the
LDP
08
Subnetwork Address on the next
Subnetwork SpecificSpace Packet Protocol entity in the
LDP
注：01, 05,06 は Managed Parameter(Protocol Configuration Parameter)、07-08 は Managed Parameter (Routing Parameter)である。

付録 2 宇宙機プロジェクトの User Application が規定する仕様
この付録は、End-to-End Protocol(Space Packet Protocol を適用)において、宇宙機プロジ
ェクトの各 Application User が規定してよい項目(付表 2-1)を示す。詳細は宇宙機プロジェ
クトの指示による。
付表 2-1 User Application が規定する仕様
項目
01

各 Packet の長さ

02
03

Packet Sequence Flag
Packet Secondary Header
Time Code Fine Time 長

許容値
プロジェクト規定の最大長以下‘11’, ‘01’, ‘00’, ‘01’
0～8 octets51

備考
最小長は 1 octet である。
観測データ等の Payload Data Time Stamp(Telemetry)用