災害対策

本記述は、当方がブログにアップしたものを加筆したものです。

今回の震災でIP電話やSkypeが有効であったとの記事が多く見受けられますが、事実としては間違っているわけでは ないのですが、この記述には大きな落とし穴を含んでいます。今回の震災で、IP電話やSkype間の通話ががスムーズ にできたのは、他の通信手段(固定電話や携帯電話)に比べてほとんど普及していないことが最大の理由で、回線容 量に比較して通信量が増大すれば、これまでの通信手段と同様、繋がりにくくなります。また、音声がと切れることな く通話できるためには、回線でのパケットの損失、遅延のばらつきがないことが必須です。これらの対策として、通信 各社は、音声通話をデータ通信の回線とは別の回線にするなどしています。これに対して、D-STARのレピータでは ゲート超え通信には、インターネットの通常のデータ回線を使用しているため、回線の輻輳の影響をもろに受けること になります。つまり、被災時にパケット量が増大し輻輳が起これば、音声通信が行えないことになります。特に、UDP と呼ばれるプロトコルを使用している関係で、輻輳時にはパケットロスが起こることにより、通信が途絶えることになり ます。(海外とSkypeで通信したことのある方は、この現象を経験しておられる方が、多くおられると思います。)つまり、 被災時には、被災地域だけでなく他の地域でも、D-STARのゲート超えの通信が途絶える可能性があります。また、 ゲート超えだけでなく、制御用のPCがダウンすれば、レピーター自身が、機能しないことになります。このような事態を 避けるために、少なくともPCがダウンした場合でも「山かけ」通信が可能な対策が必要です。

また、アマチュアはアマチュアとして、例えば現在のJARLが管理するレピータ網とは別の災害に強い独自の草の根 D−STAR網の構築を考えてみませんか。


管理サーバーに震災対策を
ご存じの通り、現在国内のD-STARのレピータ網は、JARLが管理する管理サーバーのもと、一元管理されています。 このサーバーが被災すれば、現在のままでは各レピータが山掛けとしては機能しますが、レピータ間の交信(ゲート越え)が 出来ないことになります。レピータ間の交信は、管理サーバーを介して交信しているのでなく、直接交信相手のレピータと交信 する方法が採用されています。このため、管理サーバーを介することなく、相手レピータのIPアドレスが分かれば交信は可能です。 サーバーソフトの改修が必要ですが、少なくともレピータのIPアドレスをローカルに管理できれば、被災時でもレピータ指定の 交信は、確保出来ます。この改修ができれば良いのですが。
注  ・被災時にゲート越えの交信が正常に行える為には、インターネットの回線が輻輳を起こしていないこと。そしてUDPのパケットが ロス無く遅延が発生していないことが、最低限必要です。 ・管理サーバーは、レピータや各登録されている局がどのレピータのもとに居るのかを管理しているだけです。管理サーバーは、 各レピータからの問い合わせに対して、そもレピータのIPアドレスを返すだけです。

管理サーバーの分散を
上記書き込みの「管理サーバーに震災対策を」と一部内容が重複します。現在のD-STAR網の音声通信(DV)はは、JARLが管理し ている管理ーザーバーにどのレピータのもとにいるか確認し、相手のレピータのIPアドレス(グローバルアドレス)を得、そのIPアドレ スに対して直接UDPパケットを使用してで音声パケットを送ることによって通信を確保しています。つまり、この通信経路が確定すれ ば、以後通信が終了するまで管理サーバーは、必要ないことになります。
このことに注目すれば、大規模震災対策として、
・管理サーバーを分散する(海外で導入されているG2による各ゲートに、管理サーバー機能を持たせる)
・最低限、各レピータのIPアドレスを各ゲートで管理する
・インターネット回線が使用できない場合は、レピータの制御用PCがなくても山かけ運用が可能にする
などの対策が必要です。
また、これ以外にも、電源の確保が必要です。

RF多段中継による自律型ネットワーク
DVモードの無線部ヘッダーには、送信元、送信先そして中継点の情報を持っています。これを利用して自律的な多段中継が 可能なネットワークの構築が可能です。(使用周波数に関しては、別途考慮する必要があります。)
現在のD-STARのインターネットを利用した中継方法は、レピータ間でP2Pの手法が使用されています。このため通信相手の IPアドレスを管理サーバーから得る必要がありました。これが、災害時にネックになる可能性が大きく、この管理サーバーの 分散が急務であることはご存じの通りです。これに対して、インターネットを利用するのでなく、多少の遅延は目をつむるとして、 無線での多段中継を実現する方が、災害時には威力を発揮するのではないかと思います。
例えば受信周波数と送信周波数を変え送受信が同時に行えるようにし A→B→C→D の様に中継していけば何処までも中継 が可能です。この例は、固定先への中継ですが、Aから到達可能な中継局が複数ある場合、またその先でも複数ある場合、特 定の中継先に居る局に対しての中継は、各中継局から中継可能な局(隣の中継局)の内、どの中継先に居るのか分かれば、該 当中継局だけを経由して中継ができます。
例えば、 A からは B1,B2、B3へ、B1からはC11,C12,C13へ、 B2からはC21、C22、C23へ中継が可能な場合、C22局に位置するZ局へA局から中継するには、A→B2→C22へと中継することになります。Aからの信号をB2だけが中継してB1やB3が中継しないようにするためにD-STARの無線部ヘッダーの機能が役に立ちます。この場合、A局は、Z局がC22に位置しているという情報は必要なく、単にB2へ中継するという情報が必要なだけです。またB2は、C22へ中継するという情報が必要なだけです。このような管理方法は、インターネットのルーター等で経路を決定する方法と同じです。このことに注目すれば、インターネットのARPに類似した方法を利用すれば、これらの経路を自律的に管理することができます。この経路情報の管理には、PIC等の簡単なコントローラーで対応が可能です。 この様な機能を備えた中継局を、複数配置することで広範囲な交信のサポートが可能で、災害時には、威力を発揮するとことが期待できます。

簡易データ通信は、使用できるか
D-STARのDVモード(音声通信)には、音声だけでなく簡易データ通信が行える機能が備わっています。音声通話をしながら、少量のデータを同時に 転送することが可能です。スピードは、約960bpsです。この機能を使用してGPSの位置情報を転送するDPRSが普及しているのは皆さんご存知の とおりです。この機能を利用してチャットができるようにしたプログラムも各種公開されています。しかし、このフィールドは、誤り訂正機能を持ってお らず、またチェック機能も持っていません。正確な電文を伝えるためには、これらの機能を転送プログラムに自前で組み込む必要があります。 これは、本来音声通話の間に少量のデータを送ることを意図した機能ですので、このデータの確認の為にハンドシエイクを行うのはシンプレックスで あれば問題ありませんが、レピータ経由となると少し問題があります。メッセージ機能を使用されている方は、ご存知ですが、移動の場合 かなりの頻度で文字化けをすることが知られています。(GMSKで変調している関係で、避けて通れない点です。)このようなことから、この機能を 過度に信用して重要な情報を伝達するのは、注意が必要です。

同報通信を
現在のD−STARのレピータは、相互に通信しているレピータだけしか通信ができないシステムになっています。今回の震災でWiRESのルームが非常に 役に立ったとの報告が多くなされています。(WiRESだけでなく、広域レピータが、そのサービスエリア内に居る複数の局に対して、同時に伝達ができると いう機能が、災害時には役に立つという報告がされています。)今後予想される東南海地震等の場合、被害地域が広範におよぶことが予想されています。 このような場合、例えばD−STARの全レピータから同報通信ができれば、初期の非難情報等の伝達がスムースに行えることが期待できます。このような 同報通信機能を完備することは、今後の震災対策に有効であると考えられます。

ノードを
D−STARは、レピータそしてネットワーク(インターネット)が、正常に働けば、広範囲なサービスリアが確保でき、上記の同報伝達がスムースに行えることが 期待できます。しかし、一方でレピータが停止すれば、そのサービスエリアに空白地帯ができることになります。また、電波法上、レピータを開設できるのは JARLに限られていますので、代わりのレピータをすぐ用意することは難しいのが現状です。これに対してWiRESは、個人が開設している アクセスポイントをつなぐ事によってサービスエリアを確保しています。つまり、設置に関しては自由度が非常に高く、緊急時には非常に有効に働きます。 D−STARにもこのような、アクセスポイント(ノードでレピータではありません)の開設を認めることで、非常時にWiRES以上の威力を発揮することが期待 できます。早急に、ノードを管理サーバーに繋ぐ方法の確立を・・・・

コンファレンスルーム(Dスクエアー)サーバーを
レピータのような大掛かりな設備がなくても、WindowsのPC一台でWiRESのような、ルームを開設できるサーバーとクライアントのプログラムを作成して みました。このクライアントプログラムは、ノードアダプターを必要としますが、無線機に関しては、9600bpsのパケットの端子があるものであれば、機種を 選びません。(一部、設定が難しい機種もあります。)ノードアダプターを接続したPCがインタネットに接続されていれば、どこでもアクセスポイント(クライ アント)を開設でき、同一PCにサーバーも開設することができます。D-STARのレピータやWiRESのように管理サーバーを必要としませんので、緊急時 には威力を発揮します。電波法に関しては、付属装置としてノードアダプターが登録してあれば問題ありませんので、設置場所を選ばないなど、災害時 には威力を発揮するもとの思います。
2011年09月26日更新
CopyRight © 2011 All Rights Reserved. D-STAR™ JARL
安田 聖(やすだ さとし)7M3TJZ
E-mail: 7m3tjz@jk1zrw.org