FT8でコールサインが<>で囲まれているケースがあるのはなぜ？

みなさんがFT8をワッチしているときに、ときどき<>で囲まれたコールサインや<...>という表示が出てくることにお気づきかと思います。今日は、FT8がコールサインをどのようにエンコードして送受信しているかについて説明しながら、それら＜＞の意味を考えてみたいと思います。

6文字までの標準コールサインをアマチュア局のコールサイン割当の性質をうまく利用して28ビットのデータで表現していることをFT8のデータエンコードについて説明しました。では、6文字に収まらないコールサインはどのようにして送受信しているのでしょうか。

FT8ではコールサインを標準型、タイプ1複合型、タイプ2複合型の3通りに定義しています。

標準型コールサインとは、１文字か２文字のプリフィックス（そのうち少なくとも１つは英字）、数字、そして１文字から３文字のサフィックスで構成されるものをいいます。

タイプ1複合コールサインとは、標準型コールサインに数字のサフィックスがついたもの、たとえば、K1ABC/4 のような形です。さらに、あらかじめ定義されたプリフィックスがついたもの、たとえば、ZA/K1ABC のような形です。あらかじめ定義されたプリフィックスはWSJT-XのHelp → List of Type1 prefixes and suffixesで見ることができます。

これらのサフィックス、プリフィックスの情報は、メッセージの3番目のフィールド、すなわち、通常では、グリッドロケータやシグナルレポート、RR、73が入るフィールドを使って送信されます。したがって、

CQ ZA/K1ABC
CQ K1ABC/4
ZA/K1ABC G0XYZ
G0XYZ K1ABC/4

のようなメッセージは送ることができますが、

ZA/K1ABC G0XYZ -22
G0XYZ K1ABC/4 73 

のようなメッセージは送ることができません。-22や73が入るフィールドは、すでに、ZA/や/4で使われてしまっているからです。実際のQSOでは、どのようなメッセージが交換されるか、その例を下に示しました。

CQ ZA/K1ABC
                    ZA/K1ABC G0XYZ
G0XYZ K1ABC –19
                    K1ABC G0XYZ R–22
G0XYZ K1ABC RRR
                    K1ABC G0XYZ 73

1行目2行目では、タイプ1複合コールサインであるZA/プリフィックスがついています。したがって、グリッドロケータなどの情報は送っていません。3行目以降は、信号レポートやRRR、73を送っていますが、そのときは、プリフィックスが省かれていることがわかります。

タイプ2型複合コールサインとは、あらかじめ定義されたプリフィックス、サフィックスに無いプリフィックス、サフィックスがついたコールサインを言います。たとえば、W4/G0XYZ、K1ABC/VE6のような形です。タイプ2型複合コールサインを含む場合は、最初の語はCQか、DEか、QRZでなければなりません。下のようなメッセージになります。

CQ W4/G0XYZ FM07
QRZ K1ABC/VE6 DO33
DE W4/G0XYZ FM18
DE W4/G0XYZ -22
DE W4/G0XYZ R-22
DE W4/G0XYZ RRR
DE W4/G0XYZ 73

メッセージにはタイプ2複合コールサイン１つしか入りません。したがって、QSOはこのような感じで進むことになります。

CQ K1ABC FN42
                    DE G0XYZ/W4 FM18
G0XYZ K1ABC –19
                    K1ABC G0XYZ R–22
G0XYZ K1ABC RRR
                    DE G0XYZ/W4 73

この例で、最初にCQを出していたK1ABCから/W4を含むメッセージは返ってきていませんが、K1ABCは/W4をきちんとコピーしています。FT8では、本コールサインだけコピーして、サフィックスだけ落とすということはないからです。

他の手段として、コールサインにハッシュをかけ、圧縮して表現する方法があります。ハッシュというのは、コールサインを表すデータから別の（より短い）データを生成することです。留意すべきは、あるコールサインが与えられたとき、そのハッシュ値は必ず決まるということです。加えて、複数の別のコールサインが同一のハッシュ値を持つ可能性があるということです。言い換えると、ハッシュ値だけから元のコールサインを復元することはできません。QSO例を見てみましょう。

①　CQ PJ4/K1ABC
②                      <PJ4/K1ABC> W9XYZ
③　W9XYZ <PJ4/K1ABC> +03
④                      <PJ4/K1ABC> W9XYZ R-08
⑤　<W9XYZ> PJ4/K1ABC RRR
⑥                      PJ4/K1ABC <W9XYZ> 73

①でPJ4/K1ABCがCQを出しました。PJ4/はあらかじめ定義されたプリフィックスリストに載っていません。したがって、PJ4/K1ABCはタイプ２複合コールサインになります。それを受信したW9XYZが呼びます。しかし、上で説明したように、メッセージ内にタイプ２複合コールサインが含まれる場合、データサイズが大きくなりすぎて別のコールサインを入れることができません。そこで、W9XYZ側のWSJT-XプログラムはPJ4/K1ABCにハッシュをかけ、データを圧縮してメッセージに埋め込みます。生コールサインではなく、ハッシュ値であることは＜＞で囲まれていることでわかります。PJ4/K1ABCは自分のハッシュ値を知っていますから、自分が呼ばれたことがわかりますので、③で応答します。このとき、自分のコールサインは生のデータではなく、ハッシュ値としてメッセージに入れています。⑤⑥では、W9XYZが生データではなく、ハッシュ値としてやり取りされています。

では次に、このQSOをあたながワッチしていて、もし、①の電波が受信出来ていない場合を想定してみます。

②                      <PJ4/K1ABC> W9XYZ
③　W9XYZ <PJ4/K1ABC> +03
④                      <PJ4/K1ABC> W9XYZ R-08
⑤　<W9XYZ> PJ4/K1ABC RRR
⑥                      PJ4/K1ABC <W9XYZ> 73

②で受信されたPJ4/K1ABCのハッシュ値は受信できても、それがPJ4/K1ABCから計算されたハッシュ値であることがわかりません。したがって、WSJT-Xは<...>と表示します。

②                      <...> W9XYZ
③　W9XYZ <...> +03
④                      <...> W9XYZ R-08
⑤　<W9XYZ> PJ4/K1ABC RRR
⑥                      PJ4/K1ABC <W9XYZ> 73

⑤のW9XYZのハッシュ値はどうでしょう。②③④でW9XYZのコールサインを受信していますから、そこからハッシュ値を計算し、それと⑤の<W9XYZ>と照合することができるので、WSJT-XはW9XYZのコールサインを表示できます。

このような巧みな技を使って、少ないデータ量でQSOを成立させています。すごいですね。