キャラクタ・ベースのプロトコルでの伝送のための圧縮およびデータ符号化
メッセージを編集するためのＡＣＡＲＳのシステム２０および方法１００は、８ビット・キャラクタのストリームの８ビット・キャラクタを６ビットのマップにマッピングして、通常６ビット・キャラクタ・ストリームを生成するように構成される処理デバイス３０を含む。処理デバイス３０は、通常６ビット・キャラクタ・ストリームを８ビット・キャラクタ・ストリームに符号化するように更に構成される。オプションで、処理デバイス３０は、プロセッサで受け取った８ビット・キャラクタの存在に応じて、代替の６ビット・キャラクタを取り出すように構成されるルックアップ・テーブル３８を含む。
【発明の詳細な説明】
【技術分野】
【０００１】
キャラクタ・ベースのプロトコルでの伝送のための圧縮およびデータ符号化。
【背景技術】
【０００２】
ＡＣＡＲＳ（航空機通信アドレシングおよびレポーティング・システム（Ａｉｒｃｒａｆｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ａｄｄｒｅｓｓｉｎｇ ａｎｄ Ｒｅｐｏｒｔｉｎｇ Ｓｙｓｔｅｍ））は、無線を介して伝送が行われるデジタル・データ・リンク・システムであり、航空会社の運航部が、保有する様々な航空機と通信することを可能にする。
【０００３】
ＡＣＡＲＳは、多くの軍用機および民間機により使用されるＶＨＦデジタル伝送システムである。ＡＣＡＲＳは、「飛行機用の電子メール」と同じような物である。なぜなら、各航空機の登録が、ＡＲＩＮＣ（Ａｅｒｏｎａｕｔｉｃａｌ Ｒａｄｉｏ，Ｉｎｃ．、エアロノーティカル・レイディオ社）により開発されたシステムにおける一意アドレスであるからである。トラフィックは、ＡＲＩＮＣやＳＩＴＡのコンピュータなどのサービスを介して、適切な会社や飛行機へ送られ、会社との慣例的な音声通信で必要な幾つかの項目を取り除く。ＡＣＡＲＳを用いて、出発報告、到着報告、乗客量、燃料データ、エンジン性能データ、および他の多くの慣例的な項目が、会社により要求され、自動的な間隔で航空機から取り出されることができる。ＡＣＡＲＳの出現以前は、運航機乗務員が、音声通信を使用して、このデータを地上の運航部へ中継しなければならなかった。
【０００４】
ＡＣＡＲＳシステムは、下記のエレメントを備える。
【０００５】
１． 機上サブシステム（Ａｉｒｂｏｒｎｅ Ｓｕｂｓｙｓｔｅｍ）。これは、航空機に搭載されるものであり、
ａ）ＶＨＦ無線送受信機を介して地対空メッセージを受信し、応答を制御する管理ユニットと、
ｂ）ＡＣＡＲＳシステムとの搭乗員インタフェースであり、表示画面およびプリンタを備える制御ユニットと
から成る。
【０００６】
２． ＡＲＩＮＣ地上局システム（ＡＲＩＮＣ Ｇｒｏｕｎｄ Ｓｙｓｔｅｍ）。これは、すべてのＡＲＩＮＣ ＡＣＡＲＳリモート送信／受信局と、ＡＲＩＮＣのコンピュータおよび交換システムとから成る。
【０００７】
３． 、航空会社Ｃ２（指令および制御）ならびに管理サブシステム（Ａｉｒ Ｃａｒｒｉｅｒ Ｃ２（Ｃｏｍｍａｎｄ ａｎｄ Ｃｏｎｔｒｏｌ） ａｎｄ Ｍａｎａｇｅｍｅｎｔ Ｓｕｂｓｙｓｔｅｍ）。これは、運航管理、保守、搭乗員スケジューリングその他のような基本的にすべての航空会社地上業務であり、ＡＣＡＲＳシステムにリンクされる。
【０００８】
メッセージは、航空機に対する方向により特徴付けられる２つのタイプに分かれ、「ダウンリンク」は、航空機において発信されるＡＣＡＲＳ伝送であり、「アップリンク」は、地上局から航空機へ送られるメッセージである。
【０００９】
航空会社は、ＡＣＡＲＳシステムを介したデータの伝送に対して、送信および受信されたビット数に基づいた支払いを行う。キャラクタ・ベースのプロトコルは、伝送し得るキャラクタの組に制限がある。８ビット辞書（８−ｂｉｔ ｌｅｘｉｃｏｎ）の幾つかのキャラクタは、区切り文字として使用するものとしてキャラクタ・ベース・プロトコルにより指定される。そのような割り当てが行われた場合、指定キャラクタは、キャラクタ・ストリーム内に存在できない。データ・ストリーム内に存在し得るキャラクタの許容数は、その場合、８ビット・ストリームで表現可能な１２８キャラクタよりも少ない。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
当技術分野において、なくて不便なのは、データのより経済的なロスレスの符号化および伝送のために伝送ビットを削減するシステムおよび方法である。
【課題を解決するための手段】
【００１１】
メッセージをコンパイルするためのＡＣＡＲＳシステムおよび方法は、８ビット・キャラクタのストリームの８ビット・キャラクタを６ビットのマップにマッピングして、通常６ビット・キャラクタ・ストリーム（ｇｅｎｅｒａｌｌｙ ｓｉｘ−ｂｉｔ ｃｈａｒａｃｔｅｒ ｓｔｒｅａｍ）を生成するように構成される処理デバイスを含む。処理デバイスは、通常６ビット・キャラクタ・ストリームを８ビット・キャラクタ・ストリームに符号化するように更に構成される。オプションで、処理デバイスは、プロセッサで受け取った８ビット・キャラクタの存在に応じて、代替の６ビット・キャラクタを取り出すように構成されるルックアップ・テーブルを含む。
【００１２】
８ビット・キャラクタのマッピングは、オプションで、ルックアップ・テーブルに基づいて、第１の８ビット・キャラクタを第１の６ビット・キャラクタに代替するステップと、第２の８ビット・キャラクタをルックアップ・テーブルに含まれるキャラクタと比較して、選択されたキャラクタ（選択キャラクタ）を生成するステップと、第１の６ビット・キャラクタを選択キャラクタと連結して６ビット・キャラクタのストリームを生成するテップとを含むことができる。一つの実施形態では、選択キャラクタは、ルックアップ・テーブルにおいて第２の８ビット・キャラクタの大文字表現に対応する６ビット・キャラクタを含む。第２の実施形態では、少なくとも１つの選択キャラクタは、指定された８ビット・キャラクタを含むか、またはフラグ・ビットを含み、それにより、後続のものが選択された初期の６４個のキャラクタの範囲外のであることを示す。この実施形態では、キャラクタ・ストリームの状態は、８ビットから６ビットへのマッピングが使用されているかどうかを示すように、フラグ・ビットの存在に従って切り換わる。
【００１３】
ＡＣＡＲＳメッセージをコンパイルするためのＡＣＡＲＳ制御ユニットでは、処理デバイスは、通常６ビット・キャラクタ・ストリームを生成するために、８ビット・キャラクタを６ビットのマップへとマッピングするように構成される。プロセッサは、通常６ビット・キャラクタ・ストリームを８ビット・キャラクタのストリームへと符号化するようにも構成される。そのようにすることで、キャラクタを表現するのに必要とされるビットの数の削減がなされる。
【００１４】
処理デバイスは、暗号化された６ビット・キャラクタのストリームを生成するために、通常６ビット・キャラクタ・ストリームを暗号化し、また、その暗号化された通常６ビット・キャラクタ・ストリームを符号化するように更に構成される。そのような符号化により、処理デバイスは、圧縮された６ビット・キャラクタのストリームを生成するために、通常６ビット・キャラクタ・ストリームを圧縮し、また、その圧縮された６ビット・キャラクタのストリームを暗号化するように更に構成される。
【００１５】
８ビット・キャラクタのマッピングのために構成される処理デバイスは、オプションで、ルックアップ・テーブルに従って、８ビット・キャラクタを第１の６ビット・キャラクタで代替するように更に構成される。処理デバイスは、これを行うために、第２の８ビット・キャラクタをルックアップ・テーブルに含まれるキャラクタと比較し、第２の８ビット・キャラクタに取って代わる選択された８ビット・キャラクタ（選択８ビット・キャラクタ）を取り出す。選択８ビット・キャラクタは、選択されると、通常６ビット・キャラクタ・ストリームを生成するために、選択キャラクタとともに第１の６ビット・キャラクタに連結される。
【００１６】
幾つかの実施形態では、選択キャラクタは、ルックアップ・テーブルにおいて第２の８ビット・キャラクタの大文字表現に対応する６ビット・キャラクタである。選択キャラクタは、指定８ビット・キャラクタおよびフラグ・ビットも含む。
【００１７】
上記の要約を検討すれば容易に理解されるように、ＡＣＡＲＳシステムおよび方法は、ＡＣＡＲＳが伝送用に許容する限られた数のキャラクタを使用する新しい８ビット表現へとキャラクタを再編成することにより、データをロスレスに圧縮することができる。
【００１８】
本発明の好ましい実施形態および代替の実施形態が、添付の図面を参照して以下で詳細に説明される。
【発明を実施するための最良の形態】
【００１９】
メッセージをコンパイルするためのＡＣＡＲＳシステムおよび方法は、通常６ビット・キャラクタ・ストリームを生成するために、８ビット・キャラクタのストリームの８ビット・キャラクタを６ビットのマップにマッピングするように構成される処理デバイスを含む。処理デバイスは、通常６ビット・キャラクタ・ストリームを８ビット・キャラクタ・ストリームに符号化するように更に構成される。オプションとして、処理デバイスは、プロセッサで受け取った８ビット・キャラクタの存在に応じて、代替の６ビット・キャラクタを取り出すように構成されるルックアップ・テーブルを含む。
【００２０】
図１を参照すると、ブロック図は、航空機２０に搭載される例示的なシステム１８を示している。限定を意図するものではない例示的なシステム１８は、ＡＣＡＲＳ管理ユニット２６と処理デバイス３０とに結合されるＡＣＡＲＳ制御ユニット２８を含む。処理デバイス３０は、少なくとも１つのプロセッサ３６を含む。プロセッサ３６は、ルックアップ・テーブル３８も含むことができ、ルックアップ・テーブル３８は、入力データに応答してデータを出力するように構成されるメモリである。管理ユニット２６は、ＶＨＦ無線送受信機４０から受け取る地対空メッセージ（ground-to-air message、地上から空へのメッセージ）を受け取り、応答を制御する。例示的なシステムは、航空機内に示されているが、地対空および空対地（空から地上へ）の通信を容易にするために、地上局においても実質的に同じシステムが備えられる。
【００２１】
制御ユニット２８は、ＡＣＡＲＳシステムとの搭乗員インタフェースであり、典型的には、表示画面、ユーザ・インタフェース、およびプリンタを含む。ＡＣＡＲＳ制御ユニットは、すべての周辺装置を制御し、データの、ＡＣＡＲＳプロトコルおよびフォーマットへの必要なカプセル化を提供する。また、制御ユニット２８は、地上ベースのシステムへまたは複数の制御および表示ユニットへキャラクタ・ストリームを伝送するために、特別な状態およびイベントのメッセージを生成するのものであり、また、航空機２０の機上のポケットＰＣおよびＰＤＡデバイスへの表示が可能である。また、制御ユニット２８は、ＡＣＡＲＳ制御ユニットが通信のために使用する適切な手段を決定することにより（通信可能エリアごとに）、通信の接続性も管理する。
【００２２】
動作に際して、管理ユニット２６は、ＶＨＦ無線送受信機４０からキャラクタ・ストリームを受け取る。管理ユニット２６は、受け取ったキャラクタ・ストリームを制御ユニット２８へ渡す。制御ユニット２８は、到着するキャラクタ・ストリーム内で適切な区切りキャラクタを検出した場合、区切りキャラクタの後続のデータを、変換のためにプロセッサ３６へ送る。次に、プロセッサ３６は、キャラクタ・ストリームに含まれるビット（ｂｉｔｓ）に従って、ルックアップ・テーブル３８からキャラクタを取り出す。本質的には、プロセッサ３６は、受け取ったキャラクタ・ストリームのビット群を、ルックアップ・テーブル３８に記憶された対応するキャラクタにマッピングする。ルックアヘッド（look-ahead）・バッファ３２は、データ・ストリームの８ビット・サンプルを保持して、それをプロセッサ３６へ提供するように構成される。マッピングを行うことで、プロセッサ３６は、制御ユニット２８においてキャラクタとしてキャラクタ・ストリームを出力して、ユーザへテキストまたはキャラクタとして送られるようにする。管理ユニット２６は、第２の適切な区切りキャラクタを検出した場合、ＡＣＡＲＳプロトコルに厳格に従った型通りの制御ユニット２８への情報の伝送に戻る。
【００２３】
伝送に際して、ユーザは、キーボードなどのユーザ・インタフェースを用いて、情報を制御ユニット２８へ入力する。制御ユニット２８は、伝送用に情報をキャラクタ・ストリームへと組み立て、処理デバイス３０を使用して有利に変換され得るキャラクタ・ストリームの部分を決定する。ＡＣＡＲＳプロトコルによると、各メッセージ・フレームは、少なくとも５０個の、最大で２７２個のキャラクタ、即ちバイトから成る。メッセージ・フレームは、フレーム内の内容の先頭および末尾を確定する区切りキャラクタにより、適切に一括りにされる。フレーム内の各キャラクタの表現は、７ビットＡＣＳＩＩコードとそれに伴う付加的な第８パリティ・ビットによる。結果として得られる８ビット設計を使用すると、実施において、合計メッセージ送信時間は０．１７秒から０．９１秒の範囲となる。従って、フレーム内にあるメッセージの部分は、メッセージ・セグメントとして変換するために選択されるものであり、メッセージ・セグメントは、５０個から２７２個のキャラクタから成り、反復するストリングの多くを欠くようにして、一般にキャラクタ・ストリームの大幅な圧縮を促進する。
【００２４】
制御ユニット２８は、メッセージの区切りキャラクタを検出し、一括りにされたキャラクタをプロセッサ・デバイス３０へ渡す。ＡＣＡＲＳプロトコルでは、メッセージ・フレーム・フォーマットは、実際のメッセージ・テキストに加えて、同期キャラクタ、アドレス・キャラクタ、肯定応答（アクノレッジメント）キャラクタ、モード・キャラクタ、および誤り検査キャラクタを含むように、厳格に定義されている。しかし、各フレーム内では、フレーム内の内容に対するさらなる制約は存在しない。従って、ＡＣＡＲＳ制御ユニット２８は、フレーム内のキャラクタを処理デバイス３０へ容易にゲートする。ＡＣＡＲＳプロトコルは厳格であるので、処理デバイス３０は、キャラクタ・ストリームがフレーム内で生じるときにそのキャラクタ・ストリームを変更するように動作するだけである。
【００２５】
同様に図２を参照すると、例示的な８ビットから６ビットへのマッピング・テーブル４０が説明されている。処理デバイス３０（図１）は、キャラクタ・ベースのデータを受け取り、各８ビット・キャラクタ・データを６ビット表現にパッキングすることにより、キャラクタ・ベースのデータをビット・ストリームへと符号化する。プロセッサ３６は、６ビット表現を連結して、一つのビット・データ・ストリームにする。この「パッキング」は、ビットで表したデータのサイズを２５パーセント圧縮する。
【００２６】
例示的な一実施形態の「パッキング」は、単に、マッピング・テーブル４０に従って８ビット・キャラクタを６ビット表現にマッピングすることにより達成される。従って、例えば、「Ｐ」４２に対する８ビット・キャラクタは、値「０ｘ５０」４５を有する。対応する６ビット値は、テーブルから「０ｘ３１」４８として引き出される。結果として、厳密に６ビットのデータのストリーム（ｓｔｒｉｃｔ ６−ｂｉｔ ｄａｔａ ｓｔｒｅａｍ）が得られる。
【００２７】
「１対１」マッピングを達成するため、表現する必要のあるキャラクタの総数を２６、即ち６４まで低下させるように、或る数の許容可能キャラクタが取り除かれる。必要なキャラクタ表現を削減する１つの簡単な手段は、文字の小文字表現を捨てて、総個数から２６個のキャラクタを取り除くことである。例示的な一つの実施形態では、小文字と大文字はともに、同じ６ビット表現へとマッピングされる。
【００２８】
第２の実施形態では、総個数が９６個の伝送可能キャラクタのうち最初の６４個のキャラクタが、６ビット表現にマッピングされる。残りの３２個のキャラクタは、付加的なフラグ・ビットを伴って７ビット・キャラクタとしてマッピングされる。連結してキャラクタ・ストリームにすると、その結果は、データ・ストリームとして表される通常６ビット・キャラクタ・ストリームとなる。キャラクタの真のビット長に関係なく、そのデータ・ストリームを８ビット・バイトに分断することにより、より短いキャラクタ・ストリームをもたらす。データ・ストリームの分断（チョッピング）は、Ｂａｓｅ６４チョッピング（Ｂａｓｅ ６４ ｃｈｏｐｐｉｎｇ）として知られている。
【００２９】
Ｂａｓｅ６４チョッピングを実行して、２進データを伝送可能キャラクタに変換する場合、マッピングにより生成される６ビット・キャラクタ（６４個の一意値）は、ルックアップ・テーブル３８において、６４個の一意のキャラクタに変換される。ＡＣＡＲＳを介して伝送可能なキャラクタは９６個存在するので、６ビット表現は、残りの３２個のキャラクタを表現することができない。通常６ビット・キャラクタ・ストリームを生成する際、プロセッサ３６はルックアヘッド・バッファ３２から値を取り出すが、この際、２ビット前方を見て、完全な８ビット値が、６ビット・キャラクタとして変形され得ない３２個のキャラクタの１つであるかどうかを決定する。別の例示的な実施形態では、これらの８ビットは、拡張（ｅｘｐａｎｓｉｏｎ）を必要とせず、従って、元の形式のままである。
【００３０】
いくらかの圧縮が、Ｂａｓｅ６４チョッピングにより生じる。説明の目的で、８ビットから６ビットへのマッピングを施されるキャラクタ・ストリームはランダムであると仮定すると、１バイトに対して２５６個の可能なビット・パターンが存在するので、３２個の変形不能なキャラクタの１つと遭遇する可能性は１２．５％である。これらのキャラクタの１つと遭遇するたびに、２ビットの長さが節約される。Ｂａｓｅ６４チョッピングによるキャラクタ・ストリームの全体の平均的減少は、このランダムなデータ・ストリームの場合は３．１２５％である。平文における使用に基づいた適切な割り当てにより、圧縮効果を更に高めることができる。
【００３１】
図３を参照すると、ＡＣＡＲＳデータを伝送するための方法１００において、ＡＣＡＲＳデータのストリームが、ブロック１０２で内容についてテストされる。内容がキャラクタであることを示す適切なヘッダをデータが含む場合、本明細書で説明された８ビットから６ビットへの変換が、ブロック１０５で行われる。フレームの内容がキャラクタ・データではない場合、ブロック１０５での８ビットから６ビットへの変換は回避され、方法は、ブロック１０８のオプションのデータ圧縮へ進む。
【００３２】
ブロック１０８で、標準的な圧縮アルゴリズムがデータに適用される。任意の標準的な圧縮技法を、連結されたデータ・ストリームに対して使用してよい。そのような圧縮の例は、知られたＤＥＦＬＡＴＥまたはｖ．４２ｂｉｓアルゴリズムであり、データ・ストリームのサイズが小さいときに比較的良好な結果をもたらす。これらの標準的な圧縮技法の１つを適用することにより、データのサイズに応じて、ビット・ストリームを２５から３３パーセント低減できる。
【００３３】
一般に、データ・ストリームは、使用される圧縮技法に従って短縮される。ＡＴＮ仕様の開発中に行われた研究は、ＤＥＦＬＡＴＥアルゴリズムはデータの任意のストリームを圧縮できること、およびそのサイズを２分の１から５分の１に削減できることを、明らかにした。従って、データ・ストリームに対してＤＥＦＬＡＴＥアルゴリズムを使用すると、一般に、元のものと同じサイズまたはより良いサイズのペイロードが得られる。ユーザに対してデータの最適な構成を保証するために、ペイロード・サイズがテストされる。
【００３４】
ブロック１１１で、無圧縮データ・ストリームのサイズが、圧縮データ・ペイロードのサイズと比較される。圧縮データ・ストリームのほうが小さい場合、ブロック１１４で、圧縮データ・ストリームが、使用するために選択される。元のデータ・ストリームのほうが小さい場合、ブロック１１７で、元のデータ・ストリームが、使用するために選択される。
【００３５】
場合によっては、生成されたデータ・ストリームは、ブロック１２３での再キャラクタ化（ｒｅｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ）のために直ちに送られるが、オプションのでデータの暗号化が望まれる場合、データのそのような暗号化は、ブロック１２０で有利に行われてよい。暗号化プロセスは、圧縮ビット・ストリームのサイズの長さを追加しない。圧縮と同様、暗号化は、知られたプロセスにより容易に実行され、知られたプロセスには、ＰＧＰ暗号化を含む知られた幾つかの公開鍵暗号化手段などがある。
【００３６】
ブロック１２３で、データ・ストリームは、Ｂａｓｅ６４チョッピングにより、キャラクタ・ストリームに再変換され、従って、各６ビット・ユーザ・データを個々の結果的な８ビットＡＣＡＲＳキャラクタへと変換する。この符号化方式は、出力キャラクタが、ＡＣＡＲＳネットワークを介した伝送用に承認されたタイプであることを、保証する。通常６ビットのユーザ・データを連結して、特定のキャラクタの実際の終端とは無関係に後に８ビット・バイトに切断されるストリームにすることにより、２つの余分なビットが、総データ・ストリーム・サイズを短縮するために使用される。結果として得られる８ビット・キャラクタは、データ・ストリームに対して完全な忠実性を有するが、元のキャラクタとデータ・ストリームが生成するキャラクタとの間に１対１の対応はなく、その差が、伝送における経済性を生み出す。
【００３７】
符号化方式は、データ・ストリームのビットを３３と１／３パーセント拡張する。しかし、ビット指向のユーザ・データのサイズは、元のキャラクタ指向のユーザ・データよりも大きいことはなく、ビット・ストリームに適用される圧縮アルゴリズムの有効性に応じて、より小さくなることもある。しかし、標準的なＡＣＡＲＳのビット対キャラクタ符号化方式は、ビット指向のユーザ・データのサイズを２倍され、８ビットから６ビットへのマッピングおよび付随するＢａｓｅ６４チョッピングによりバイパスされる。
【００３８】
送信ではなく、図４に示されるように受信の場合、方法２００は、送信方法１００（図３）を逆にする。ブロック２０１で、８ビット・キャラクタのストリームが拡張され、キャラクタ・ストリームを構成する元のキャラクタに従って、ビットが再び割り当てられる。８ビット・キャラクタのストリームは、純粋な６ビット・マッピングで変形できないキャラクタの存在について、検査される。プロセッサ３６（図１）は、ルックアヘッド・バッファ３２（図１）から値を取り出すが、その際、２ビット先取りして、完全な８ビット値が、６ビット・キャラクタとして変形され得ない３２個のキャラクタの１つであるかどうかを決定する。取り出した値に基づいて、８ビット・キャラクタ・ストリームは、通常６ビット・キャラクタ・ストリームへと変形される。
【００３９】
ブロック２０４で、キャラクタ・ストリームに付随するヘッダ、またはキャラクタ・ストリーム自体が、送信方法１００（図３）によるメッセージの組み立て中に暗号化が行われたことを示している場合、暗号解除が行われる。メッセージが暗号解除を必要とする場合、それはブロック２０７で行われる。
【００４０】
ブロック２１０で、結果的な暗号解除されたデータ・ストリームについて、送信方法１００（図３）によるメッセージの組み立て中に、データ・ストリームを変更する圧縮アルゴリズムが使用されたかどうかを判定するために、検査が行われる。使用されていた場合、選択されたアルゴリズムに従った圧縮解除が、ブロック２１３で行われる。
【００４１】
ブロックで、方法２００は、続いて、結果のテストが、８ビットから６ビットへのマッピングの結果であるかをテストする。８ビットから６ビットへのマッピングが行われていた場合、ブロック２２０で、平文メッセージを生成するために、逆のマッピングが行われる。
【００４２】
本発明の好ましい実施形態が、上述のように、例示および説明されたが、本発明の主旨および範囲から逸脱することなく、多くの変更が施され得る。例えば、平文のさらなる暗号化または暗号解除は、送信方法１００（図３）または受信方法２００（図４）のどちらかに先立ちその外側で行われてもよい。従って、本発明の範囲は、好ましい実施形態の開示により限定されない。本発明は、特許請求の範囲を参照することにより完全に決定されるべきである。
【図面の簡単な説明】
【００４３】
【図１】図１は、例示的なＡＣＡＲＳシステムのブロック図である。
【図２】図２は、８ビット・キャラクタから６ビット・キャラクタへのマッピングを行うためのマッピング・テーブルである。
【図３】図３は、送信用にＡＣＡＲＳメッセージをコンパイルするためのフローチャートである。
【図４】図４は、受信したＡＣＡＲＳメッセージをデコンパイルするためのフローチャートである。
【技術分野】
【０００１】
キャラクタ・ベースのプロトコルでの伝送のための圧縮およびデータ符号化。
【背景技術】
【０００２】
ＡＣＡＲＳ（航空機通信アドレシングおよびレポーティング・システム（Ａｉｒｃｒａｆｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ａｄｄｒｅｓｓｉｎｇ ａｎｄ Ｒｅｐｏｒｔｉｎｇ Ｓｙｓｔｅｍ））は、無線を介して伝送が行われるデジタル・データ・リンク・システムであり、航空会社の運航部が、保有する様々な航空機と通信することを可能にする。
【０００３】
ＡＣＡＲＳは、多くの軍用機および民間機により使用されるＶＨＦデジタル伝送システムである。ＡＣＡＲＳは、「飛行機用の電子メール」と同じような物である。なぜなら、各航空機の登録が、ＡＲＩＮＣ（Ａｅｒｏｎａｕｔｉｃａｌ Ｒａｄｉｏ，Ｉｎｃ．、エアロノーティカル・レイディオ社）により開発されたシステムにおける一意アドレスであるからである。トラフィックは、ＡＲＩＮＣやＳＩＴＡのコンピュータなどのサービスを介して、適切な会社や飛行機へ送られ、会社との慣例的な音声通信で必要な幾つかの項目を取り除く。ＡＣＡＲＳを用いて、出発報告、到着報告、乗客量、燃料データ、エンジン性能データ、および他の多くの慣例的な項目が、会社により要求され、自動的な間隔で航空機から取り出されることができる。ＡＣＡＲＳの出現以前は、運航機乗務員が、音声通信を使用して、このデータを地上の運航部へ中継しなければならなかった。
【０００４】
ＡＣＡＲＳシステムは、下記のエレメントを備える。
【０００５】
１． 機上サブシステム（Ａｉｒｂｏｒｎｅ Ｓｕｂｓｙｓｔｅｍ）。これは、航空機に搭載されるものであり、
ａ）ＶＨＦ無線送受信機を介して地対空メッセージを受信し、応答を制御する管理ユニットと、
ｂ）ＡＣＡＲＳシステムとの搭乗員インタフェースであり、表示画面およびプリンタを備える制御ユニットと
から成る。
【０００６】
２． ＡＲＩＮＣ地上局システム（ＡＲＩＮＣ Ｇｒｏｕｎｄ Ｓｙｓｔｅｍ）。これは、すべてのＡＲＩＮＣ ＡＣＡＲＳリモート送信／受信局と、ＡＲＩＮＣのコンピュータおよび交換システムとから成る。
【０００７】
３． 、航空会社Ｃ２（指令および制御）ならびに管理サブシステム（Ａｉｒ Ｃａｒｒｉｅｒ Ｃ２（Ｃｏｍｍａｎｄ ａｎｄ Ｃｏｎｔｒｏｌ） ａｎｄ Ｍａｎａｇｅｍｅｎｔ Ｓｕｂｓｙｓｔｅｍ）。これは、運航管理、保守、搭乗員スケジューリングその他のような基本的にすべての航空会社地上業務であり、ＡＣＡＲＳシステムにリンクされる。
【０００８】
メッセージは、航空機に対する方向により特徴付けられる２つのタイプに分かれ、「ダウンリンク」は、航空機において発信されるＡＣＡＲＳ伝送であり、「アップリンク」は、地上局から航空機へ送られるメッセージである。
【０００９】
航空会社は、ＡＣＡＲＳシステムを介したデータの伝送に対して、送信および受信されたビット数に基づいた支払いを行う。キャラクタ・ベースのプロトコルは、伝送し得るキャラクタの組に制限がある。８ビット辞書（８−ｂｉｔ ｌｅｘｉｃｏｎ）の幾つかのキャラクタは、区切り文字として使用するものとしてキャラクタ・ベース・プロトコルにより指定される。そのような割り当てが行われた場合、指定キャラクタは、キャラクタ・ストリーム内に存在できない。データ・ストリーム内に存在し得るキャラクタの許容数は、その場合、８ビット・ストリームで表現可能な１２８キャラクタよりも少ない。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
当技術分野において、なくて不便なのは、データのより経済的なロスレスの符号化および伝送のために伝送ビットを削減するシステムおよび方法である。
【課題を解決するための手段】
【００１１】
メッセージをコンパイルするためのＡＣＡＲＳシステムおよび方法は、８ビット・キャラクタのストリームの８ビット・キャラクタを６ビットのマップにマッピングして、通常６ビット・キャラクタ・ストリーム（ｇｅｎｅｒａｌｌｙ ｓｉｘ−ｂｉｔ ｃｈａｒａｃｔｅｒ ｓｔｒｅａｍ）を生成するように構成される処理デバイスを含む。処理デバイスは、通常６ビット・キャラクタ・ストリームを８ビット・キャラクタ・ストリームに符号化するように更に構成される。オプションで、処理デバイスは、プロセッサで受け取った８ビット・キャラクタの存在に応じて、代替の６ビット・キャラクタを取り出すように構成されるルックアップ・テーブルを含む。
【００１２】
８ビット・キャラクタのマッピングは、オプションで、ルックアップ・テーブルに基づいて、第１の８ビット・キャラクタを第１の６ビット・キャラクタに代替するステップと、第２の８ビット・キャラクタをルックアップ・テーブルに含まれるキャラクタと比較して、選択されたキャラクタ（選択キャラクタ）を生成するステップと、第１の６ビット・キャラクタを選択キャラクタと連結して６ビット・キャラクタのストリームを生成するテップとを含むことができる。一つの実施形態では、選択キャラクタは、ルックアップ・テーブルにおいて第２の８ビット・キャラクタの大文字表現に対応する６ビット・キャラクタを含む。第２の実施形態では、少なくとも１つの選択キャラクタは、指定された８ビット・キャラクタを含むか、またはフラグ・ビットを含み、それにより、後続のものが選択された初期の６４個のキャラクタの範囲外のであることを示す。この実施形態では、キャラクタ・ストリームの状態は、８ビットから６ビットへのマッピングが使用されているかどうかを示すように、フラグ・ビットの存在に従って切り換わる。
【００１３】
ＡＣＡＲＳメッセージをコンパイルするためのＡＣＡＲＳ制御ユニットでは、処理デバイスは、通常６ビット・キャラクタ・ストリームを生成するために、８ビット・キャラクタを６ビットのマップへとマッピングするように構成される。プロセッサは、通常６ビット・キャラクタ・ストリームを８ビット・キャラクタのストリームへと符号化するようにも構成される。そのようにすることで、キャラクタを表現するのに必要とされるビットの数の削減がなされる。
【００１４】
処理デバイスは、暗号化された６ビット・キャラクタのストリームを生成するために、通常６ビット・キャラクタ・ストリームを暗号化し、また、その暗号化された通常６ビット・キャラクタ・ストリームを符号化するように更に構成される。そのような符号化により、処理デバイスは、圧縮された６ビット・キャラクタのストリームを生成するために、通常６ビット・キャラクタ・ストリームを圧縮し、また、その圧縮された６ビット・キャラクタのストリームを暗号化するように更に構成される。
【００１５】
８ビット・キャラクタのマッピングのために構成される処理デバイスは、オプションで、ルックアップ・テーブルに従って、８ビット・キャラクタを第１の６ビット・キャラクタで代替するように更に構成される。処理デバイスは、これを行うために、第２の８ビット・キャラクタをルックアップ・テーブルに含まれるキャラクタと比較し、第２の８ビット・キャラクタに取って代わる選択された８ビット・キャラクタ（選択８ビット・キャラクタ）を取り出す。選択８ビット・キャラクタは、選択されると、通常６ビット・キャラクタ・ストリームを生成するために、選択キャラクタとともに第１の６ビット・キャラクタに連結される。
【００１６】
幾つかの実施形態では、選択キャラクタは、ルックアップ・テーブルにおいて第２の８ビット・キャラクタの大文字表現に対応する６ビット・キャラクタである。選択キャラクタは、指定８ビット・キャラクタおよびフラグ・ビットも含む。
【００１７】
上記の要約を検討すれば容易に理解されるように、ＡＣＡＲＳシステムおよび方法は、ＡＣＡＲＳが伝送用に許容する限られた数のキャラクタを使用する新しい８ビット表現へとキャラクタを再編成することにより、データをロスレスに圧縮することができる。
【００１８】
本発明の好ましい実施形態および代替の実施形態が、添付の図面を参照して以下で詳細に説明される。
【発明を実施するための最良の形態】
【００１９】
メッセージをコンパイルするためのＡＣＡＲＳシステムおよび方法は、通常６ビット・キャラクタ・ストリームを生成するために、８ビット・キャラクタのストリームの８ビット・キャラクタを６ビットのマップにマッピングするように構成される処理デバイスを含む。処理デバイスは、通常６ビット・キャラクタ・ストリームを８ビット・キャラクタ・ストリームに符号化するように更に構成される。オプションとして、処理デバイスは、プロセッサで受け取った８ビット・キャラクタの存在に応じて、代替の６ビット・キャラクタを取り出すように構成されるルックアップ・テーブルを含む。
【００２０】
図１を参照すると、ブロック図は、航空機２０に搭載される例示的なシステム１８を示している。限定を意図するものではない例示的なシステム１８は、ＡＣＡＲＳ管理ユニット２６と処理デバイス３０とに結合されるＡＣＡＲＳ制御ユニット２８を含む。処理デバイス３０は、少なくとも１つのプロセッサ３６を含む。プロセッサ３６は、ルックアップ・テーブル３８も含むことができ、ルックアップ・テーブル３８は、入力データに応答してデータを出力するように構成されるメモリである。管理ユニット２６は、ＶＨＦ無線送受信機４０から受け取る地対空メッセージ（ground-to-air message、地上から空へのメッセージ）を受け取り、応答を制御する。例示的なシステムは、航空機内に示されているが、地対空および空対地（空から地上へ）の通信を容易にするために、地上局においても実質的に同じシステムが備えられる。
【００２１】
制御ユニット２８は、ＡＣＡＲＳシステムとの搭乗員インタフェースであり、典型的には、表示画面、ユーザ・インタフェース、およびプリンタを含む。ＡＣＡＲＳ制御ユニットは、すべての周辺装置を制御し、データの、ＡＣＡＲＳプロトコルおよびフォーマットへの必要なカプセル化を提供する。また、制御ユニット２８は、地上ベースのシステムへまたは複数の制御および表示ユニットへキャラクタ・ストリームを伝送するために、特別な状態およびイベントのメッセージを生成するのものであり、また、航空機２０の機上のポケットＰＣおよびＰＤＡデバイスへの表示が可能である。また、制御ユニット２８は、ＡＣＡＲＳ制御ユニットが通信のために使用する適切な手段を決定することにより（通信可能エリアごとに）、通信の接続性も管理する。
【００２２】
動作に際して、管理ユニット２６は、ＶＨＦ無線送受信機４０からキャラクタ・ストリームを受け取る。管理ユニット２６は、受け取ったキャラクタ・ストリームを制御ユニット２８へ渡す。制御ユニット２８は、到着するキャラクタ・ストリーム内で適切な区切りキャラクタを検出した場合、区切りキャラクタの後続のデータを、変換のためにプロセッサ３６へ送る。次に、プロセッサ３６は、キャラクタ・ストリームに含まれるビット（ｂｉｔｓ）に従って、ルックアップ・テーブル３８からキャラクタを取り出す。本質的には、プロセッサ３６は、受け取ったキャラクタ・ストリームのビット群を、ルックアップ・テーブル３８に記憶された対応するキャラクタにマッピングする。ルックアヘッド（look-ahead）・バッファ３２は、データ・ストリームの８ビット・サンプルを保持して、それをプロセッサ３６へ提供するように構成される。マッピングを行うことで、プロセッサ３６は、制御ユニット２８においてキャラクタとしてキャラクタ・ストリームを出力して、ユーザへテキストまたはキャラクタとして送られるようにする。管理ユニット２６は、第２の適切な区切りキャラクタを検出した場合、ＡＣＡＲＳプロトコルに厳格に従った型通りの制御ユニット２８への情報の伝送に戻る。
【００２３】
伝送に際して、ユーザは、キーボードなどのユーザ・インタフェースを用いて、情報を制御ユニット２８へ入力する。制御ユニット２８は、伝送用に情報をキャラクタ・ストリームへと組み立て、処理デバイス３０を使用して有利に変換され得るキャラクタ・ストリームの部分を決定する。ＡＣＡＲＳプロトコルによると、各メッセージ・フレームは、少なくとも５０個の、最大で２７２個のキャラクタ、即ちバイトから成る。メッセージ・フレームは、フレーム内の内容の先頭および末尾を確定する区切りキャラクタにより、適切に一括りにされる。フレーム内の各キャラクタの表現は、７ビットＡＣＳＩＩコードとそれに伴う付加的な第８パリティ・ビットによる。結果として得られる８ビット設計を使用すると、実施において、合計メッセージ送信時間は０．１７秒から０．９１秒の範囲となる。従って、フレーム内にあるメッセージの部分は、メッセージ・セグメントとして変換するために選択されるものであり、メッセージ・セグメントは、５０個から２７２個のキャラクタから成り、反復するストリングの多くを欠くようにして、一般にキャラクタ・ストリームの大幅な圧縮を促進する。
【００２４】
制御ユニット２８は、メッセージの区切りキャラクタを検出し、一括りにされたキャラクタをプロセッサ・デバイス３０へ渡す。ＡＣＡＲＳプロトコルでは、メッセージ・フレーム・フォーマットは、実際のメッセージ・テキストに加えて、同期キャラクタ、アドレス・キャラクタ、肯定応答（アクノレッジメント）キャラクタ、モード・キャラクタ、および誤り検査キャラクタを含むように、厳格に定義されている。しかし、各フレーム内では、フレーム内の内容に対するさらなる制約は存在しない。従って、ＡＣＡＲＳ制御ユニット２８は、フレーム内のキャラクタを処理デバイス３０へ容易にゲートする。ＡＣＡＲＳプロトコルは厳格であるので、処理デバイス３０は、キャラクタ・ストリームがフレーム内で生じるときにそのキャラクタ・ストリームを変更するように動作するだけである。
【００２５】
同様に図２を参照すると、例示的な８ビットから６ビットへのマッピング・テーブル４０が説明されている。処理デバイス３０（図１）は、キャラクタ・ベースのデータを受け取り、各８ビット・キャラクタ・データを６ビット表現にパッキングすることにより、キャラクタ・ベースのデータをビット・ストリームへと符号化する。プロセッサ３６は、６ビット表現を連結して、一つのビット・データ・ストリームにする。この「パッキング」は、ビットで表したデータのサイズを２５パーセント圧縮する。
【００２６】
例示的な一実施形態の「パッキング」は、単に、マッピング・テーブル４０に従って８ビット・キャラクタを６ビット表現にマッピングすることにより達成される。従って、例えば、「Ｐ」４２に対する８ビット・キャラクタは、値「０ｘ５０」４５を有する。対応する６ビット値は、テーブルから「０ｘ３１」４８として引き出される。結果として、厳密に６ビットのデータのストリーム（ｓｔｒｉｃｔ ６−ｂｉｔ ｄａｔａ ｓｔｒｅａｍ）が得られる。
【００２７】
「１対１」マッピングを達成するため、表現する必要のあるキャラクタの総数を２６、即ち６４まで低下させるように、或る数の許容可能キャラクタが取り除かれる。必要なキャラクタ表現を削減する１つの簡単な手段は、文字の小文字表現を捨てて、総個数から２６個のキャラクタを取り除くことである。例示的な一つの実施形態では、小文字と大文字はともに、同じ６ビット表現へとマッピングされる。
【００２８】
第２の実施形態では、総個数が９６個の伝送可能キャラクタのうち最初の６４個のキャラクタが、６ビット表現にマッピングされる。残りの３２個のキャラクタは、付加的なフラグ・ビットを伴って７ビット・キャラクタとしてマッピングされる。連結してキャラクタ・ストリームにすると、その結果は、データ・ストリームとして表される通常６ビット・キャラクタ・ストリームとなる。キャラクタの真のビット長に関係なく、そのデータ・ストリームを８ビット・バイトに分断することにより、より短いキャラクタ・ストリームをもたらす。データ・ストリームの分断（チョッピング）は、Ｂａｓｅ６４チョッピング（Ｂａｓｅ ６４ ｃｈｏｐｐｉｎｇ）として知られている。
【００２９】
Ｂａｓｅ６４チョッピングを実行して、２進データを伝送可能キャラクタに変換する場合、マッピングにより生成される６ビット・キャラクタ（６４個の一意値）は、ルックアップ・テーブル３８において、６４個の一意のキャラクタに変換される。ＡＣＡＲＳを介して伝送可能なキャラクタは９６個存在するので、６ビット表現は、残りの３２個のキャラクタを表現することができない。通常６ビット・キャラクタ・ストリームを生成する際、プロセッサ３６はルックアヘッド・バッファ３２から値を取り出すが、この際、２ビット前方を見て、完全な８ビット値が、６ビット・キャラクタとして変形され得ない３２個のキャラクタの１つであるかどうかを決定する。別の例示的な実施形態では、これらの８ビットは、拡張（ｅｘｐａｎｓｉｏｎ）を必要とせず、従って、元の形式のままである。
【００３０】
いくらかの圧縮が、Ｂａｓｅ６４チョッピングにより生じる。説明の目的で、８ビットから６ビットへのマッピングを施されるキャラクタ・ストリームはランダムであると仮定すると、１バイトに対して２５６個の可能なビット・パターンが存在するので、３２個の変形不能なキャラクタの１つと遭遇する可能性は１２．５％である。これらのキャラクタの１つと遭遇するたびに、２ビットの長さが節約される。Ｂａｓｅ６４チョッピングによるキャラクタ・ストリームの全体の平均的減少は、このランダムなデータ・ストリームの場合は３．１２５％である。平文における使用に基づいた適切な割り当てにより、圧縮効果を更に高めることができる。
【００３１】
図３を参照すると、ＡＣＡＲＳデータを伝送するための方法１００において、ＡＣＡＲＳデータのストリームが、ブロック１０２で内容についてテストされる。内容がキャラクタであることを示す適切なヘッダをデータが含む場合、本明細書で説明された８ビットから６ビットへの変換が、ブロック１０５で行われる。フレームの内容がキャラクタ・データではない場合、ブロック１０５での８ビットから６ビットへの変換は回避され、方法は、ブロック１０８のオプションのデータ圧縮へ進む。
【００３２】
ブロック１０８で、標準的な圧縮アルゴリズムがデータに適用される。任意の標準的な圧縮技法を、連結されたデータ・ストリームに対して使用してよい。そのような圧縮の例は、知られたＤＥＦＬＡＴＥまたはｖ．４２ｂｉｓアルゴリズムであり、データ・ストリームのサイズが小さいときに比較的良好な結果をもたらす。これらの標準的な圧縮技法の１つを適用することにより、データのサイズに応じて、ビット・ストリームを２５から３３パーセント低減できる。
【００３３】
一般に、データ・ストリームは、使用される圧縮技法に従って短縮される。ＡＴＮ仕様の開発中に行われた研究は、ＤＥＦＬＡＴＥアルゴリズムはデータの任意のストリームを圧縮できること、およびそのサイズを２分の１から５分の１に削減できることを、明らかにした。従って、データ・ストリームに対してＤＥＦＬＡＴＥアルゴリズムを使用すると、一般に、元のものと同じサイズまたはより良いサイズのペイロードが得られる。ユーザに対してデータの最適な構成を保証するために、ペイロード・サイズがテストされる。
【００３４】
ブロック１１１で、無圧縮データ・ストリームのサイズが、圧縮データ・ペイロードのサイズと比較される。圧縮データ・ストリームのほうが小さい場合、ブロック１１４で、圧縮データ・ストリームが、使用するために選択される。元のデータ・ストリームのほうが小さい場合、ブロック１１７で、元のデータ・ストリームが、使用するために選択される。
【００３５】
場合によっては、生成されたデータ・ストリームは、ブロック１２３での再キャラクタ化（ｒｅｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ）のために直ちに送られるが、オプションのでデータの暗号化が望まれる場合、データのそのような暗号化は、ブロック１２０で有利に行われてよい。暗号化プロセスは、圧縮ビット・ストリームのサイズの長さを追加しない。圧縮と同様、暗号化は、知られたプロセスにより容易に実行され、知られたプロセスには、ＰＧＰ暗号化を含む知られた幾つかの公開鍵暗号化手段などがある。
【００３６】
ブロック１２３で、データ・ストリームは、Ｂａｓｅ６４チョッピングにより、キャラクタ・ストリームに再変換され、従って、各６ビット・ユーザ・データを個々の結果的な８ビットＡＣＡＲＳキャラクタへと変換する。この符号化方式は、出力キャラクタが、ＡＣＡＲＳネットワークを介した伝送用に承認されたタイプであることを、保証する。通常６ビットのユーザ・データを連結して、特定のキャラクタの実際の終端とは無関係に後に８ビット・バイトに切断されるストリームにすることにより、２つの余分なビットが、総データ・ストリーム・サイズを短縮するために使用される。結果として得られる８ビット・キャラクタは、データ・ストリームに対して完全な忠実性を有するが、元のキャラクタとデータ・ストリームが生成するキャラクタとの間に１対１の対応はなく、その差が、伝送における経済性を生み出す。
【００３７】
符号化方式は、データ・ストリームのビットを３３と１／３パーセント拡張する。しかし、ビット指向のユーザ・データのサイズは、元のキャラクタ指向のユーザ・データよりも大きいことはなく、ビット・ストリームに適用される圧縮アルゴリズムの有効性に応じて、より小さくなることもある。しかし、標準的なＡＣＡＲＳのビット対キャラクタ符号化方式は、ビット指向のユーザ・データのサイズを２倍され、８ビットから６ビットへのマッピングおよび付随するＢａｓｅ６４チョッピングによりバイパスされる。
【００３８】
送信ではなく、図４に示されるように受信の場合、方法２００は、送信方法１００（図３）を逆にする。ブロック２０１で、８ビット・キャラクタのストリームが拡張され、キャラクタ・ストリームを構成する元のキャラクタに従って、ビットが再び割り当てられる。８ビット・キャラクタのストリームは、純粋な６ビット・マッピングで変形できないキャラクタの存在について、検査される。プロセッサ３６（図１）は、ルックアヘッド・バッファ３２（図１）から値を取り出すが、その際、２ビット先取りして、完全な８ビット値が、６ビット・キャラクタとして変形され得ない３２個のキャラクタの１つであるかどうかを決定する。取り出した値に基づいて、８ビット・キャラクタ・ストリームは、通常６ビット・キャラクタ・ストリームへと変形される。
【００３９】
ブロック２０４で、キャラクタ・ストリームに付随するヘッダ、またはキャラクタ・ストリーム自体が、送信方法１００（図３）によるメッセージの組み立て中に暗号化が行われたことを示している場合、暗号解除が行われる。メッセージが暗号解除を必要とする場合、それはブロック２０７で行われる。
【００４０】
ブロック２１０で、結果的な暗号解除されたデータ・ストリームについて、送信方法１００（図３）によるメッセージの組み立て中に、データ・ストリームを変更する圧縮アルゴリズムが使用されたかどうかを判定するために、検査が行われる。使用されていた場合、選択されたアルゴリズムに従った圧縮解除が、ブロック２１３で行われる。
【００４１】
ブロックで、方法２００は、続いて、結果のテストが、８ビットから６ビットへのマッピングの結果であるかをテストする。８ビットから６ビットへのマッピングが行われていた場合、ブロック２２０で、平文メッセージを生成するために、逆のマッピングが行われる。
【００４２】
本発明の好ましい実施形態が、上述のように、例示および説明されたが、本発明の主旨および範囲から逸脱することなく、多くの変更が施され得る。例えば、平文のさらなる暗号化または暗号解除は、送信方法１００（図３）または受信方法２００（図４）のどちらかに先立ちその外側で行われてもよい。従って、本発明の範囲は、好ましい実施形態の開示により限定されない。本発明は、特許請求の範囲を参照することにより完全に決定されるべきである。
【図面の簡単な説明】
【００４３】
【図１】図１は、例示的なＡＣＡＲＳシステムのブロック図である。
【図２】図２は、８ビット・キャラクタから６ビット・キャラクタへのマッピングを行うためのマッピング・テーブルである。
【図３】図３は、送信用にＡＣＡＲＳメッセージをコンパイルするためのフローチャートである。
【図４】図４は、受信したＡＣＡＲＳメッセージをデコンパイルするためのフローチャートである。
【特許請求の範囲】
【請求項１】
キャラクタ・ストリームのデータの符号化および伝送における伝送ビットをロスレスに低減する方法（１００）であって、
８ビット・キャラクタを６ビットのマップにマッピングして通常６ビット・キャラクタ・ストリームを生成するステップ（１０５）と、
前記通常６ビット・キャラクタ・ストリームを８ビット・キャラクタのストリームに符号化するステップ（１２３）と
を備える方法１００。
【請求項２】
請求項１に記載の方法であって、
前記通常６ビット・キャラクタ・ストリームを暗号化して、暗号化された通常６ビット・キャラクタ・ストリームを生成するステップ（１２０）を更に備え、
前記符号化するステップが、前記暗号化された通常６ビット・キャラクタ・ストリームを符号化するステップ（１２３）を含む、
方法。
【請求項３】
請求項１に記載の方法であって、
前記通常６ビット・キャラクタ・ストリームを圧縮して、圧縮された６ビット・キャラクタのストリームを生成するステップ（１０８）を更に備え、
前記符号化するステップが、前記圧縮された６ビット・キャラクタのストリームを符号化するステップ（１２３）を含む、
方法。
【請求項４】
ＡＣＡＲＳメッセージをコンパイルするためのＡＣＡＲＳ制御ユニット（２０）であって、
８ビットから６ビットへのマッピングを保存するためのメモリ（３８）と、
前記メモリ（３８）と結合され、８ビット・キャラクタを６ビットのマップにマッピングして通常６ビット・キャラクタ・ストリームを生成するように構成される処理デバイス３６であって、前記通常６ビット・キャラクタ・ストリームを８ビット・キャラクタのストリームに符号化するように更に構成される処理デバイス３６と
を備えるＡＣＡＲＳ制御ユニット（２０）。
【請求項５】
請求項４に記載のユニット（２０）であって、
前記処理デバイス（３６）は、前記通常６ビット・キャラクタ・ストリームを暗号化して、暗号化された通常６ビット・キャラクタ・ストリームを生成するように更に構成され、
前記符号化は、前記暗号化された通常６ビット・キャラクタ・ストリームを符号化することを含む、
ユニット（２０）。
【請求項６】
請求項４に記載のユニット（２０）であって、
前記処理デバイス（３６）は、前記通常６ビット・キャラクタ・ストリームを圧縮して、圧縮された６ビット・キャラクタのストリームを生成するように更に構成され、
前記符号化は、前記圧縮された６ビット・キャラクタのストリームを符号化することを含む、
ユニット（２０）。
【請求項７】
メッセージをコンパイルするためのＡＣＡＲＳシステム（２０）であって、
８ビット・キャラクタのストリームの８ビット・キャラクタを６ビットのマップにマッピングして、通常６ビット・キャラクタ・ストリームを生成するように構成される処理デバイス（３６）を含み、
前記通常６ビット・キャラクタ・ストリームを８ビット・キャラクタのストリームに符号化するように更に構成される、
ＡＣＡＲＳシステム（２０）。
【請求項８】
請求項７に記載のＡＣＡＲＳシステム（２０）であって、
前記処理デバイス（３０）はルックアップ・テーブル（３８）を含み、前記ルックアップ・テーブル（３８）は、プロセッサで受け取った前記８ビット・キャラクタの存在に応じて代替の６ビット・キャラクタを取り出すように構成される、
ＡＣＡＲＳシステム（２０）。
【請求項９】
請求項７に記載のＡＣＡＲＳシステム（２０）であって、
前記処理デバイス（３０）はルックアップ・テーブル（３８）を含み、前記ルックアップ・テーブル（３８）は、前記プロセッサで受け取った前記８ビット・キャラクタの存在に応じて、代替の８ビット・キャラクタを取り出すように構成される、
ＡＣＡＲＳシステム（２０）。
【請求項１０】
請求項７に記載のＡＣＡＲＳシステム（２０）であって、
ルックアヘッド・バッファ（３２）を更に備え、前記ルックアヘッド・バッファ（３２）は、前記８ビット・キャラクタ・ストリームをＡＣＡＲＳ制御ユニットから受け取り、プロセッサ要求に従ってキャラクタを取り出すように構成され、取り出された前記キャラクタが前記プロセッサにおいて提供される、
ＡＣＡＲＳシステム（２０）。
【請求項１】
キャラクタ・ストリームのデータの符号化および伝送における伝送ビットをロスレスに低減する方法（１００）であって、
８ビット・キャラクタを６ビットのマップにマッピングして通常６ビット・キャラクタ・ストリームを生成するステップ（１０５）と、
前記通常６ビット・キャラクタ・ストリームを８ビット・キャラクタのストリームに符号化するステップ（１２３）と
を備える方法１００。
【請求項２】
請求項１に記載の方法であって、
前記通常６ビット・キャラクタ・ストリームを暗号化して、暗号化された通常６ビット・キャラクタ・ストリームを生成するステップ（１２０）を更に備え、
前記符号化するステップが、前記暗号化された通常６ビット・キャラクタ・ストリームを符号化するステップ（１２３）を含む、
方法。
【請求項３】
請求項１に記載の方法であって、
前記通常６ビット・キャラクタ・ストリームを圧縮して、圧縮された６ビット・キャラクタのストリームを生成するステップ（１０８）を更に備え、
前記符号化するステップが、前記圧縮された６ビット・キャラクタのストリームを符号化するステップ（１２３）を含む、
方法。
【請求項４】
ＡＣＡＲＳメッセージをコンパイルするためのＡＣＡＲＳ制御ユニット（２０）であって、
８ビットから６ビットへのマッピングを保存するためのメモリ（３８）と、
前記メモリ（３８）と結合され、８ビット・キャラクタを６ビットのマップにマッピングして通常６ビット・キャラクタ・ストリームを生成するように構成される処理デバイス３６であって、前記通常６ビット・キャラクタ・ストリームを８ビット・キャラクタのストリームに符号化するように更に構成される処理デバイス３６と
を備えるＡＣＡＲＳ制御ユニット（２０）。
【請求項５】
請求項４に記載のユニット（２０）であって、
前記処理デバイス（３６）は、前記通常６ビット・キャラクタ・ストリームを暗号化して、暗号化された通常６ビット・キャラクタ・ストリームを生成するように更に構成され、
前記符号化は、前記暗号化された通常６ビット・キャラクタ・ストリームを符号化することを含む、
ユニット（２０）。
【請求項６】
請求項４に記載のユニット（２０）であって、
前記処理デバイス（３６）は、前記通常６ビット・キャラクタ・ストリームを圧縮して、圧縮された６ビット・キャラクタのストリームを生成するように更に構成され、
前記符号化は、前記圧縮された６ビット・キャラクタのストリームを符号化することを含む、
ユニット（２０）。
【請求項７】
メッセージをコンパイルするためのＡＣＡＲＳシステム（２０）であって、
８ビット・キャラクタのストリームの８ビット・キャラクタを６ビットのマップにマッピングして、通常６ビット・キャラクタ・ストリームを生成するように構成される処理デバイス（３６）を含み、
前記通常６ビット・キャラクタ・ストリームを８ビット・キャラクタのストリームに符号化するように更に構成される、
ＡＣＡＲＳシステム（２０）。
【請求項８】
請求項７に記載のＡＣＡＲＳシステム（２０）であって、
前記処理デバイス（３０）はルックアップ・テーブル（３８）を含み、前記ルックアップ・テーブル（３８）は、プロセッサで受け取った前記８ビット・キャラクタの存在に応じて代替の６ビット・キャラクタを取り出すように構成される、
ＡＣＡＲＳシステム（２０）。
【請求項９】
請求項７に記載のＡＣＡＲＳシステム（２０）であって、
前記処理デバイス（３０）はルックアップ・テーブル（３８）を含み、前記ルックアップ・テーブル（３８）は、前記プロセッサで受け取った前記８ビット・キャラクタの存在に応じて、代替の８ビット・キャラクタを取り出すように構成される、
ＡＣＡＲＳシステム（２０）。
【請求項１０】
請求項７に記載のＡＣＡＲＳシステム（２０）であって、
ルックアヘッド・バッファ（３２）を更に備え、前記ルックアヘッド・バッファ（３２）は、前記８ビット・キャラクタ・ストリームをＡＣＡＲＳ制御ユニットから受け取り、プロセッサ要求に従ってキャラクタを取り出すように構成され、取り出された前記キャラクタが前記プロセッサにおいて提供される、
ＡＣＡＲＳシステム（２０）。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００９−５２９１９４（Ｐ２００９−５２９１９４Ａ）
【公表日】平成２１年８月１３日（２００９．８．１３）
【国際特許分類】
【出願番号】特願２００８−５５８４６０（Ｐ２００８−５５８４６０）
【出願日】平成１９年３月１日（２００７．３．１）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０６３０１１
【国際公開番号】ＷＯ２００７／１０１２６５
【国際公開日】平成１９年９月７日（２００７．９．７）
【出願人】（５００５７５８２４）ハネウェル・インターナショナル・インコーポレーテッド (1,504)
【公表日】平成２１年８月１３日（２００９．８．１３）
【国際特許分類】
【出願日】平成１９年３月１日（２００７．３．１）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０６３０１１
【国際公開番号】ＷＯ２００７／１０１２６５
【国際公開日】平成１９年９月７日（２００７．９．７）
【出願人】（５００５７５８２４）ハネウェル・インターナショナル・インコーポレーテッド (1,504)
[ Back to top ]