[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jamsat-bb:11134] Re: How to ISS Packet QSO
JF6BCC 今石です。
At 2002/03/20 00:56:31 大谷 芳充 wrote:
> パケット通信本来の運用スタイルとは違った、この交信方法が本当にベストなの
> かっていう素朴な疑問が沸いてきました。(^^;
了解、そういうことですね。
このあたりは、ISS の TNC を経由する通信を「パケット通信」とみなすの
か、それとも「パケット通信システムを利用したデジタルモードの通信」と
みなすのか、解釈の問題があると思います。前者であれば、コネクションを
張らないで、順序・誤り制御も行わないパケットを投げ合うだけ (=UI チャ
ット) と言うのは奇異に思えるでしょうが、後者での立場なら RTTY や PSK31
などと同様に、デジタル信号を送る手段として 1200bps の AFSK 信号による
パケット通信の仕組みを利用しているだけだ、ってことになります。
無論、RTTY なら多少の化け字があっても意味は通じますが、パケットでは
パケットが一部でも破損するとデコードできませんし、それを避けて Passall
ON にしていたのでは化け化けになります (--;) ので、非常に通信が難しく
なります。が、市販の TNC があれば特殊な機材が要らないことと、TNC の持
つ中継機能を利用できると言うメリットがありますよね。
JA や欧米の現状では、ISS 経由の交信は前述の後者の解釈を取るべきだと
思います。あくまで、パケット通信の機材と仕組みを利用しているだけで、
パロットレピータ経由の RTTY だと考える、と言うことですね。
UI チャットがパケットを節約できると言うのは、みなさんも十分ご承知だ
と思いますが、例で比較してみます。等幅フォントで見てください。
<<コネクトする場合>> <<UIチャットの場合>>
A局 ISS B局 A局 ISS B局
(1) ←<UI> "CQ" (1) ←<UI> "CQ"
(2) ←<UI>* "CQ" (2) ←<UI>* "CQ"
(3) <C>→ (3) <UI>→ "B de A ur 599"
(4) <C>*→ (4) <UI>*→ "B de A ur 599"
(5) ←<UA> (5) ←<UI> "Tnx ur 599 TU"
(6) ←<UA>* (6) ←<UI>* "Tnx ur 599 TU"
(7) <I>→ "B de A ur 599"
(8) <I>*→ "B de A ur 599"
(9) ←<RR>
(10) ←<RR>*
(11) ←<I> "Tnx ur 599 TU"
(12) ←<I>* "Tnx ur 599 TU"
(13) <RR>→
(14) <RR>*→
(15) <D>→
(16) <D>*→
(17) ←<UA>
(18) ←<UA>*
交信終了の挨拶も省いたごく短い交信スタイルですが、全くパケットの消
失や受信不能が無くても、コネクトした場合には 18 個ものパケットの往復
が必要となります。現実には、パケットの消失により確認パケットや再送パ
ケットが多数、しかも短い間隔で自動送信されてしまいますから、結果とし
て送出されるパケット数は非常に多くなってしまいます。
これが UI チャットなら、最善の状態で６個しか必要としません。パケッ
ト消失による再送判断に難点を残しますが、それは人間がやるのですから、
混雑状況にあわせて断念したり間隔を調整したり、あるいは２回送って届か
なければあきらめる、などのスタイルを取ることも可能です。人間が送ろう
としない限りパケットも出て行きませんから、トラフィックを調整しやすく
なります。
それに、通常の TNC の設定だと、コネクト中には他の局のパケットをモニ
タすることができませんしね (^^;)。逆に UI チャットなら、１つのパケッ
トで複数局に同時応答してしまうことも可能ですが。
ISS のパスは最大 10 分です。交信相手との共通ウィンドゥが仮に７分程
度しか無いとして、１つのパケットが占める時間を２秒と仮定すれば、交換
可能なパケット数は最大 210 個です。うち、パケットの衝突や地上の混信
などで５割が失われる、と言うかなり甘い予測をすれば、交信に使えるパケ
ットは 105 個しかありません。もし運用局が５局いれば、１局あたりの割り
当ては 20 個足らずです。実際は、皆さんかげ経験している通り、もっと少
ない数のパケットしか通らないでしょう。
この「わずかな割り当てパケット数」で、できるだけ効率の良い交信をし
ようと考える以上、UI チャットは必然になると思うのです。
それと、何がベストな運用方法か、と言うのは、目的と状況によって変わ
ってきます。
現時点では、ISS の TNC は端末に接続されていないので、クルーと会話し
たりメッセージを PMB に送ることはできません（推奨されていません）ので、
地上の局同士が互いに交信することが目的です。それも、２局だけが長々と
ラグチューをチャットでやるのではなくて、多数の局が互いにコールサイン
とレポートを交換しようと、必至にがんばっているような状況です。こうい
う場合、１局あたりの送出パケット数を減らすことのできる UI チャットが
「ベスト」と言えるでしょう。
ただ、運用人口の少ない地域だと、ISS 経由で交信するのはいつも決まっ
た２局だけ、と言うことがあるでしょう。そうなれば UI で RST の交換をす
るようなことは滅多に無くて、近況とか簡単なメッセージを交換するのがメ
インの運用スタイルになるかも知れません。そうなれば、通常のパケット通
信のような、コネクションを張って誤り制御つきでデータを交換する方が適
切だ、と言うことになりますよね。
> ふと思った次第です。取り立てて議論することもないのですが、あえてそのこと
> を、「議論しておく＝確認しておく」のも意味があることではないかと思います。
略
と言う訳で、これが再確認の一助になれば幸いです (^^;)。
> それから、指摘のあったレポート交換の件ですが・・・
中略
> 例えば、今年のニューイヤーパーティでは、RSレポートに名前を付加して交換
> してましたよね。この他にも私の知るかぎりでは、天気とかグリッドロケータ、
> また、自局のQTHを特定するものとして郵便番号の交換なんていうのも候補の
> 一つに挙げられるのではないでしょうか？但し、実際に交換するのかどうかは
> 別の問題ですがね・・HW?
まあ、少なくとも現状で交換している RST レポートは、実質的には無意
味なものですから (^^;)、何かもっと有意義なものに変えたほうがいいかな、
と思います。ISS の視界に同時に入るのは JA だけではありませんから、そ
う考えると GL が一番でしょうね。６字以内ですから Unproto のあて先に
入れることもできますし。
ひょっとしたら、アワードによっては RS/RST の交換を交信成立の要件
としているかも知れませんので、RST と GL と両方送って欲しい、と言わ
れる方もいらっしゃるかも知れませんね。…でも、私としては、そんな無意
味な RST 交換を要求するアワードの方が間違っているのであって、RST 以
外の交換でもＯＫだとルールを改正しないなら、そんなアワードは申請なん
かしない、って考えれば済む個とだと思ってますけど (^^;)。
> 限られた短いパスの間に効率良く通信しなければならないというのは、理屈の
> 上では良く分るのですが、ついつい熱くなってしまっているようです。(^^;
よ〜くわかります (^^;)。送ったパケットが返ってこなかったら、続い
て送りたくなるものです。…でも、そうやって皆が短い間隔で送り続けれ
ば、結局その殆どが衝突してしまうのです。それに、ログにはデジに成功
したパケットしか現れませんが、実際には衝突で消えたパケットがもっと
多数あるはずです。
この「20 秒ルール」は、デジに成功したら 20 秒待て、ということば
かりでなく、デジに成功しなくても 20 秒待つことを要求している、と私
は解釈します。デジの成否に関わらず、パケットが衝突する確率は同じな
のですから、デジに成功しなければ短間隔で送って構わない、と解釈して
よい理由はありませんよね (^^;)。
皆さん、できますか？ (^^;)。Enter キーは 20 秒以上に１回しか押し
ちゃいけないんですよ〜。
# …自分でも、ちょっと自信がないなあ…。
それに、皆がかっきり 20 秒間隔を守ったら、全部のパケットが衝突し
ます (^^;)。ある程度ランダムにしないといけません。
# だから Beacon 機能を利用するのは禁止！。パケットは手動で送りまし
# ょう。
それはそうと、今朝の ISS は色々と面白かったみたいですね (^^;)。
長距離電車通勤の身にはつらいものがあります、とほほ。
では。
- -
Yoshihiro Imaishi 今石良寛 - 福岡県北九州市
JF6BCC/KH2GR
mailto:jf6bcc@jarl.com
http://plaza16.mbn.or.jp/~palau/
- -
-------------
JAMSAT BB Mailing List
http://www.jamsat.or.jp/infoserv/mlist.html