ここでは第３章の結論を受け、将来コスパス・サーサットの会合に貢献することを目標 にして、周波数の有効利用を図るためのビーコン制御信号が提供すべき新機能案について 検討し、提案をまとめる。
ここで取り上げる各種信号の関係について図4.1-1に示す。
図4.1-1 第4章で取り上げる信号 COSPAS-SARSAT
ビーコン部
Galileo受信部
フォワードリンク 周波数：406MHz帯 内容：遭難警報 仕様：C/S T.001 リターンリンク
周波数：1.5GHz帯 E1信号：リターンリンク L1信号：位置データ 仕様：OS SIS ICD
Galileo衛星
リターンリンク機能付きビーコン
リターンリンクデータ
＋ 位置データ 仕様：IEC61162-1
４．１ リターンリンク新機能案
第３章の検討結果から、ガリレオリターンリンクで提案されているShortフォーマット 案に従ったビーコンの制御信号について検討し、周波数有効利用にために必要な新機能を 実現するコマンド案を取りまとめる。
ガリレオリターンリンクについては、第７章にある海外動向調査にあるようにまだ細か な点については詰められていない。そこで、第３章での検討結果をもとに、ARGOS シス テムの例を参考として日本の関係機関のご意見も取り入れてコマンド案を作成した。
今回まとめた制御コマンド案は以下のとおりである。
(１) 406MHzの送信停止／送信開始
救助活動後、不要になったビーコンが回収出来ずそのまま電池が消耗するま で送信を続けるのを停止する。あるいは、明らかに誤報であることがわかっ た場合に、強制的に送信を停止する。一方、送信を遠隔で開始させるのは特 殊な場合に限られると考えられる。受信部を絶えず活かしておく必要がある ため、外部電源のある車両などのに取り付けられたビーコンなどに限られる。
連絡を絶った車両の位置の特定などトラッキング的な応用が考えられるが、
今回の個人目的には不要な機能と考えられる。
(２) 121.5MHzビーコン信号の送信停止／送信開始
121.5MHz のビーコン信号は送信出力も小さく到達距離が短いため、捜索隊
が近くまで接近しないと有効ではなく、遭難通報時から送信し続けるのは電 力消費上得策ではない。このため、遠隔で 121.5MHz信号の On/Offを行い 電力消費を押さえると共に、無駄な121.5MHzの送信を押さえ周波数の有効 利用にもなる。
(３) 406MHzの送信時間間隔の変更
406MHzの遭難信号を１度受信すれば、その後は受信時間間隔が開いても捜
索位置の特定は可能なので、電池の消耗を減らすため、送信時間間隔を遠隔 で増減する。
(４) 遭難通報に対する確認
この機能には2つの機能が想定されている。
・緊急通報を陸のRCCが受信した時点で送信されるリターンリンクであり、
緊急通報の受信（ACK）の役目をする。
・遭難の事実の確認あるいは安否の確認を行う。リターンリンクの受信を警 報音やランプの点灯等で確実にビーコン所有者に知らせ、ビーコン側にて応 答手段（既存の押しボタンの操作、あるいは新たなボタン）を要求する。
(５) 位置情報精度切り替え
現在のビーコンプロトコルによるGPSデータの扱い方では、入力可能なビッ ト数に限度があるため通常位置精度４秒（約 120m）の精度までしか入力で きない。しかしながら、リターンリンクによって一度４秒精度の位置を受信 した後、更なる高精度の位置情報の送信の要求ができれば、下位ビットをシ フトさせることなどにより、更なる高精度な位置を得ることが可能になる。
(６) 定型メッセージの表示
ビーコンに小型のディスプレイをつけて、予め用意した定型のメッセージを 選択して表示させることなどが可能と考えられる。
(７) 送信周波数の変更
コスパス・サーサットに許可されている周波数帯の中で、送信周波数チャネ ルをリターンリンクからのコマンドにより変更する。ビーコンが接近してい るような場合に信号を分離する目的で使用するものと考えられる。現時点で は規則上の問題があると考えられる。
以上のことを考慮し、ガリレオ リターンリンク未定義の部分を補足すると表4.1-1の ようになる。
表4.1-1 Short Message提案
No.（HEX) Command Parameter(15bit) 備考 ０(0000) ACK without Parameter None 規定済み １(0001) ACK with Parameter (必須) 規定済み ２(0010) 406MHz TX Control Start /Stop
３(0011) Change Interval 406MHz TX Long / Normal ４(0100) 121.5MHz TX Control Start / Stop
５(0101) Shift location Data High Res./ Normal ６(0110) Confirm Alert
７(0111) Show Fixed Message on Display Message Pattern No.
８(1000) Simple Question on Display Question Pattern No.
９(1001) Change Frequency CH CH assignment in Hex A(1010) Reserved for Future Use
B(1011) Reserved for Future Use C(1100) Reserved for Future Use D(1101) Reserved for Future Use E(1110) Reserved for Future Use F(1111) Reserved for Future Use
４．２ リターンリンク受信機よりのリターンリンク送出フォーマット案
空間をリターンリンクが伝搬してくる際のフォーマットなどについては規定されている が、最終的にメッセージをリターンリンク受信機からビーコンの制御部に渡すときどのよ うな形態で渡されるかが一番問題となる。可能ならば統一を取っておく必要があると考え られる。
今回ガリレオ衛星システムのE1信号について考えると
• E1周波数は測位データが送られてくる L1 と周波数は同じであり、測位データと 拡散コードが異なるだけなため、測位データと受信機は共有可能と考えられる。
• 現 在 の GPS (GNSS) 受 信 用 IC か ら の 測 位 デ ー タ は 標 準 的 に は IEC61162-1(NMEA0183相当)で出力されている。
これらのことから、リターンリンクもIEC61162-1のフォーマットで測位データと共に 出力されることを想定することが適当と考えられる。
IEC61162-1の規定に沿ってデータセンテンスを作ると表4.2-1のようなものとなる。そ
のセンテンスがシリアルラインで8bit Non-parityの4800bps(標準)で送り出される。通信 は単向通信でそれを受信側で受け取るのみの簡単なプロトコルとなっている。
同一ラインに位置情報を示す既存のデータも載るものと考えられ、ヘッダによりデータ の内容の区別をつけることになる。
表4.2-1 IEC61162-1(NMEA0183)相当センテンス例 ヘッダ 機 器
コード
データ
種 別 ビーコンID コマ ンド
パラメ
ータ 受信時間 受信 状態
受 信
モード チェックサム 終了符号 総バイト数 (Max.82) Galileo TBD HEX 15桁 HEX
１桁
HEX:
4桁 UTC A/V 機器コード～*
前までのEOR 48
$ GA BCS ,hhhhhhhhhhhhhhh ,h ,hhhh ,hhmmss.ss ,A ,a *hh <CR><LF>
・ “$”はユニークコードでASCIIコード型センテンスの始まりを表す。
・ “GA”はガリレオ受信機からのデータであることを示す（既規定ずみ）
・ データ種別”BCS”は今回の新提案”Beacon Control Sentence”であり、NMEA又はIECでの承認が必要
・ ビーコンIDはHEX（16進数：1～F）で４bitのデータを表し、15個で60bitのビーコンアドレスを表す。
・ コマンドおよびパラメータはバイナリデータとして扱い、4bitずつ切りHEXデータで表す。
・ 受信時間～受信モードまではデータの信頼性を示すためのもので、GNSS受信機からのデータには必ずつける。
・ チェックサムはデータのエラーチェックのため
・ <CR><LF>はセンテンスのデリミタ
・ 一般的にGNSS受信機からはGGA, GGL, GSA, GSV, RMC, VTG, ZDAなどのセンテンスが出力される。
― 33 ―
４．３ リターンリンク応答用フォワードリンクビーコンプロトコル案 ４．３．１ リターンリンク試験用フォワードリンクビーコンプロトコル
コスパス・サーサットではビーコンから衛星に向けて、緊急通報を送るためのフォワー ドリンクのデータフォーマットならびにそれに関わる規定をビーコンプロトコルと呼び、
ビーコンの種別、使用ID、位置データの有無などにより決められている。
まだ、リターンリンク自体が実験段階のものであることから、リターンリンクを考慮し た、正規のビーコンプロトコルは規定するに至っていない。その代わりに当面、機能試験 を行うため試験用プロトコルの使用を推奨し、その中のビット配列について必要な機能を 割り当て図4.3.1-1のように規定している。
図4.3.1-1 リターンリンク用テストプロトコルフォーマット
本年度の実証試験では、この試験用プロトコルを使用して行うことにしたが、さらに実 証実験をすすめるには、位置情報の扱える正式なリターンリンク用プロトコルが規定され、
それを使用することが望ましい。しかしそれがかなわない場合は、現行のプリトコルから 代用出来るものを用いて実証をすすめる必要が出ると考えられる。
４．３．２ リターンリンク応答用新フォワードリンクビーコンプロトコルの可能性 リターンリンクの正式に運用時に使用するプロトコルについて、ガリレオサイドからコ スパス・サーサットに対して、2008年3月のEWG-1(Expert Working Group：技術専門 家会合)で提案が行われた。基本的に現在のNational Location Protocolを使用することを 提案している。（図4.3.1-2参照）
ガリレオサイドからの提案の趣旨は、
• ガリレオのリターンリンクを用いるビーコンは、必ず衛星測位(GNSS)受信機を搭 載しているので、その位置データを載せられるプロトコルになる。、
• National Location Protocol内にある127～132bitをリターンリンクへの応答など として使用することを提案している。それは、ビーコンが、リターンリンク機能を
搭載していることを示すRBF(Return Link Beacon Flag)として、127bitをあて、
それを“1”とすることにより残りの5bitがリターンリンクの関連で使用されるこ とを示すことを提案した。
図4.3.1-2 National Location Protocolデータフレーム構造
この提案に対して、
• 問題の 6bitの使用方法については各国の主管庁が決めるところであり、すでにそ こを割り付けている国がある可能性があるので、それに新たな機能を割り付けるの は問題ではないか。
従って新たな専用プロトコルが必要なのではないかとの意見となった。
ガリレオサイドからリターンリンク機能のあるビーコン用プロトコルとして、National
Location Protocolを提案したのは、位置データを送るためのプロトコル中もっとも高い位
置精度（4 秒＝約 120m）が送れ、かつ自由に使えるビットがあることから、妥当なもの で有ると考えられる。しかし一方では問題の127～132bitを位置データに割り付け、約30m
（1秒）の精度まで送れるようにしている例もある。
コスパス・サーサットでは2008年にEWG-1の開催の後、JC-22（Joint Committee：
合同委員会)が6月に開催された。その会合で、米国からGPS測位データの扱い方、なら びに測位データを送るプロトコルについての改訂が提案(JC-22/5/17)された。その一部は 2008年の規格改定の際、反映された。
米国の提案内容は：
• Standard Location Protocol/National Location Protocolにおいて、ビーコンの種 別ならびにID の種別を表すための4bit コード(37～40bit)の割付に予備の“1101”
以外に衛星軌道計算(orbitography)用に割り付けている”0000”と”0001”は使用さ れていない。それらを予備として使用出来るのではないか。
• GPS測位データの更新周期を20分としているのは、静止衛星で受け取ったデータ を積分し、エラーを除くためであったが、最近の衛星は性能が上がり、4バースト