(57)【特許請求の範囲】
【請求項１】
ＡＲＱプロトコルにおけるフィードバック応答を最小化する方法であって、
通信リンクによって複数の第１のデータユニットを送信する工程と、
前記複数の第１のデータユニットを受信する工程と、
前記受信する工程に応答して、データ送信側に返信される第２のデータユニットについてのメッセージフィールドを構築する工程とを有し、
前記メッセージフィールドはタイプ識別子フィールドと、そして、シーケンス番号フィールド、長さフィールド、及び内容フィールドの内の少なくとも１つとを含み、
ビットマップが前記タイプ識別子フィールドにセットされるなら、前記内容フィールドは前記受信された複数の第１のデータユニットの内のエラーがあるデータユニットのシーケンス番号を示すビットマップを含み、前記長さフィールドは前記ビットマップのサイズを示し、
リストが前記タイプ識別子フィールドにセットされるなら、前記シーケンス番号フィールドの値と前記長さフィールドの値との組み合わせが前記受信された複数の第１のデータユニットの内のエラーがあるデータユニットのシーケンス番号を示し、
少なくとも１つのビットマップタイプのメッセージと少なくとも１つのリストタイプのメッセージとを含む異なったタイプのメッセージフィールドが組み合わされて前記第２のデータユニットを形成するとき、前記異なったタイプのメッセージフィールドは任意の順序で付加されることを特徴とする方法。
【請求項２】
前記複数の第１のデータユニットは、ユーザデータを含む複数のＡＲＱプロトコルユニットを有することを特徴とする請求項１に記載の方法。
【請求項３】
前記長さフィールドのサイズはゼロであり、前もって定義されるビットマップサイズが用いられることを特徴とする請求項１に記載の方法。
【請求項４】
前記長さフィールドは、前記ビットマップにおける最後のシーケンス番号を示すことを特徴とする請求項１に記載の方法。
【請求項５】
前記長さフィールドは、ゼロの値を有することを特徴とする請求項１に記載の方法。
【請求項６】
前記シーケンス番号フィールドのサイズは、ゼロに等しいことを特徴とする請求項１に記載の方法。
【請求項７】
前記複数の第１のデータユニットの少なくとも１つは、前記メッセージフィールドを付加するために用いられることを特徴とする請求項１に記載の方法。
【請求項８】
前記ＡＲＱプロトコルは、選択的繰り返しＡＲＱプロトコルを有することを特徴とする請求項１に記載の方法。
【発明の詳細な説明】
【０００１】
関連出願の相互参照
本特許出願は１９９９年４月９日出願の係属中の米国特許仮出願シリアル番号第６０／１２８，５１７号の優先権を主張しており、ここで、その開示全体を参照によって組み込む。
【０００２】
本発明の背景
発明の技術分野
本発明は一般的には通信の分野に関し、特に、例えば、選択的繰り返しＡＲＱプロトコルのような自動再送要求（ＡＲＱ）プロトコルにおけるフィードバック応答を最小化する方法に関する。
【０００３】
関連分野の説明
データが通信ネットワークのノード間で搬送されるとき、一定のアルゴリズムが用いられてエラーデータの伝送やノード間での伝送リンクにおけるデータ損失からの回復を行なう。エラーデータの伝送からの回復に一般に用いられているアルゴリズムは、ＡＲＱプロトコルとして言及される。
【０００４】
現存するＡＲＱプロトコル（即ち、アルゴリズム）は伝送リンクによって互いに通信を行なう２つのピアエンティティを含む。そのようなエンティティ各々は受信側と送信側とを含む。ピアエンティティ間で搬送されるデータユニットは一般にプロトコルデータユニット（ＰＤＵ）として言及される。ＡＲＱプロトコルはＰＤＵを送受信するための一定の規則と共に、ＰＤＵ構造のための規則をも含んでいる。そのようなものとして、“自動再送要求”という名称は、そのプロトコルの基本的な機能を示している。受信側は送信側に伝送中に失われた、或いはエラーが含まれるそれらＰＤＵを再送するように要求する。
【０００５】
受信側は、どのＰＤＵが正しく受信されたのか（即ち、受信側は正しく受信されたＰＤＵを確認応答する）と、どのＰＤＵが正しく受信されなかったのかとの少なくとも１つについて送信側に通知することができる。送信側はこの情報を受信するとき、その“失われた（lost）”ＰＤＵを再送する。言い換えると、ＡＲＱプロトコルは、通信システムにおける送信側と受信側との間の効率的な再送機構の利用を許している規則のセットである。これらの規則は、例えば、ＰＤＵがどのように、またどんな形式で構築されて受信側が搬送されたＰＤＵを正しく解釈してそれらに応答するのかを規定している。
【０００６】
主に３つのタイプの情報要素、ユーザデータ、エラー回復制御データ、及び共通制御データが２つのＡＲＱピアエンティティ間で転送される。これら３つのタイプのＰＤＵが全ての現存するＡＲＱプロトコルにおいて見出される。ユーザデータＰＤＵは少なくともユーザデータとシーケンス番号とを含む。エラー回復制御データＰＤＵは、エラー回復のために必要な種々の制御情報と、肯定及び否定確認応答のような制御機能とを含む。共通制御データＰＤＵは共通制御データを含む。
【０００７】
多くの現存するＡＲＱプロトコルに対する基礎を形造る知られたハイレベルデータリンク制御（ＨＤＬＣ）プロトコルにおいて、３つのタイプのＰＤＵは夫々、情報フレーム（Ｉ−フレーム）、監視フレーム（Ｓ−フレーム）、及び非番号フレーム（Ｕ−フレーム）と呼ばれる。ＨＤＬＣに由来するＡＲＱプロトコルの例は、汎欧州デジタル移動電話方式（ＧＳＭ）で用いられている無線リンクプロトコル（ＲＬＰ）、汎用パケット無線サービス（ＧＰＲＳ）で用いられている無線リンク制御（ＲＬＣ）及び論理リンク制御（ＬＬＣ）、ＩｒＤＡシステムで用いられている赤外線リンクアクセスプロトコル（ＩｒＬＡＰ）、及びＸ．２５システムで用いられているＬＡＰ−Ｂプロトコルである。とりわけ、ユーザデータと少なくともシーケンス番号を含むＰＤＵはここでデータ−ＰＤＵ（Ｄ−ＰＤＵ）として示され、エラー制御／回復のために必要な制御データを含むＰＤＵはここでステータス−ＰＤＵ（Ｓ−ＰＤＵ）として示される。
【０００８】
たいていの通信システムにおいて、ユーザデータ情報がピアエンティティ間で両方向に搬送される。ＡＲＱプロトコルに含まれる共通の特徴は、ユーザデータＰＤＵにエラー制御情報を含むという可能性である。この能力は、“ピギーバックキング（piggybacking）”として知られている。例えば、ＨＤＬＣに由来するプロトコルの全てのＩ−フレーム（即ち、Ｄ−ＰＤＵ）には確認応答が含まれる。その確認応答は最後に（順番に並んで）正しく受信されたＰＤＵのシーケンス番号についてピアエンティティに通知する。
【０００９】
最も一般的な現存するＡＲＱプロトコルは１つ以上の機構、例えば、ストップ−アンド−ウェイト（Stop-and-Wait）ＡＲＱ、ゴー−バック−Ｎ（Go-back-N）ＡＲＱ、及び選択的繰り返しＡＲＱを実施して伝送リンクにおけるエラーからの回復を行なう。これらの機構とＡＲＱの利用は一般によく知られている。
【００１０】
図１はＡＲＱプロトコルの使用を図示したシーケンス図である。図示されているように、２つのＡＲＱピアエンティティ１０、１２は互いに通信している。図１における矢は２つのエンティティ間のＰＤＵの送信を示し、各ＰＤＵの内容は各矢の上に直接説明されている。図１において、送信されるＤ−ＰＤＵとＳ−ＰＤＵとのシーケンスが示されている。Ｄ−ＰＤＵは、ユーザデータと、シーケンス番号（ＳＮ）と、おそらくピギーバック（付加）されたエラー制御情報とを含む。Ｓ−ＰＤＵはステータス情報を含むがユーザ情報は含まない。シーケンス番号（ＳＮ＝ｘ）はＤ−ＰＤＵと関連しておりその特定のＤ−ＰＤＵを識別する。確認応答（ＡＣＫ＝ｘ）はＳＮ＜ｘであるいずれかのＰＤＵを確認応答するために用いられる。否定確認応答（ＮＡＫ＝ｘ）は正しく受信されなかった（ＳＮ＝ｘである）ＰＤＵを確認応答するために用いられる。
【００１１】
２つのタイプのエラー制御フィードバック応答が図１に示されている。フィードバック応答の１つ（例えば、Ｓ−ＰＤＵ、ＡＣＫ＝２）１４について、第２のＡＲＱピアエンティティ１２は、それがＳＮ＝０とＳＮ＝１のＰＤＵを受信したことを確認応答する。第２のタイプのフィードバック応答（例えば、Ｓ−ＰＤＵ、ＮＡＫ＝３）１６について、第２のピアエンティティ１２はＳＮ＝３であるＰＤＵが改悪されており、第１のピアエンティティ１０によって再送されるべきであることを示す。
【００１２】
上述のように、Ｓ−ＰＤＵはピアエンティティ間で送信される特別なＰＤＵである。Ｓ−ＰＤＵは改悪されたＰＤＵのＳＮについての情報を含む。２つの主要な方法が現在、Ｓ−ＰＤＵ内のＳＮを符号化するのに用いられている。１つのそのような方法は、再送されるＳＮのリストを用いることである。２番目の方法は、再送されるＳＮを表現するビットマップを用いることである。そのようなものとして、ＳＮを表現することとは別に、Ｓ−ＰＤＵはまた、異なるＰＤＵフォーマット間（例えば、Ｄ−ＰＤＵとＳ−ＰＤＵ）を区別するために受信側によって用いられるフォーマット識別子を含んでいる。
【００１３】
ＳＮを符号化するために用いられるリストによる方法は、Ｓ−ＰＤＵにおけるエラーのＰＤＵのＳＮを含んでいる。もし、そのリストの長さが前もって定義されておらず、それによって知られるのであれば、この長さ情報はＳ−ＰＤＵにおいて示される。例えば、長さフィールドはＳ−ＰＤＵに含まれる。図２はＳＮを符号化するためのリストによる方法を用いて受信側によって創成されるそのようなＳ−ＰＤＵを示している。
【００１４】
図２において、もし、送信側がＳＮ＝０〜１５のＤ−ＰＤＵのシーケンスを送信し、ＳＮ＝３，５，６，７，８のＰＤＵが（正しく受信されず）損失したなら、受信側は示された内容をもつＳ−ＰＤＵを創成できる。例えば、リスト（長さフィールドの後の）にある最初の２つの要素がＳＮ＝３のＤ−ＰＤＵがエラーであったことを示す。そのリストにある３番目と４番目の要素は、ＳＮ＝５〜８のＤ−ＰＤＵがエラーであったことを示す。最後の要素は残りのＰＤＵ（最大で１５のＳＮ）を確認応答するために含まれている。
【００１５】
Ｓ−ＰＤＵのサイズは、ＰＤＵフォーマット識別子フィールド、長さフィールド、及びＳＮフィールドを表現するために用いられるビット数に依存している。そのようなものとして、Ｓ−ＰＤＵのサイズは以下の式によって計算される。
0004579421.tif 000002
例えば、このリストによる方法は、ＳＳＣＯＰプロトコルで用いられており、そこでは、２つのＳ−ＰＤＵフォーマットが存在し、可変リスト長については“ＳＴＡＴ”、そして限定された数の要素（例えば、２つの要素）をもつリストについては“ＵＳＴＡＴ”という項によって示される。
【００１６】
図３はＳＮを符号化するためのビットマップによる方法を用いた送信側によって創成されるＳ−ＰＤＵを示している。ＳＮを示すためにビットマップが用いられるとき、受信側は順番に正しく受信した最後のＤ−ＰＤＵのＳＮとビットマップからＳ−ＰＤＵを創成する。このＳＮはスタートＳＮ（ＳＳＮ）として言及される。その結果、このＳ−ＰＤＵは暗に最大でＳＳＮの数までの全ての受信したＤ−ＰＤＵに確認応答している。ビットマップでの各ロケーションは、ＳＳＮに相対的に特定のＳ−ＰＤＵをアドレスするために用いられる。通常、ビットマップのサイズはＡＲＱ受信側のウィンドウのサイズに固定され、明示的に示されねばならないことはない。もし、そのビットマップが固定されないなら、その長さは示されねばならない。
【００１７】
図３に示されるビットマップは、図２に関して上述された例から創成されたＳ−ＰＤＵとウィンドウサイズが１６であることを示している。そのようなものとして、ビットマップの各ロケーションは２つの値、即ち、０或いは１のいずれか１つをもつことができる。“１”はＳＮ＝（ＳＳＮ＋bit_position）が正しく受信されたことを意味し、“０”はＳＮ＝（ＳＳＮ＋bit_position）が正しく受信されなかったことを意味する。もちろん、“０”と“１”の意味は互いに交換可能である。そのようなビットマップを用いるときＳ−ＰＤＵのサイズは次の式から生じる。
0004579421.tif 000003
ＧＰＲＳシーケンスにおけるＲＬＣとＬＬＣの両方のプロトコルは、そのような式を用い、エラー制御の目的のためにピアエンティティ間でビットマップを搬送する。
【００１８】
現存するＡＲＱプロトコルのもつ重大な問題は、そのプロトコルが構成において静的（例えば、固定長メッセージが用いられる）である点である。ある状態の場合、このやり方はバンド幅資源の浪費につながる。なぜなら、多大な量のオーバヘッド情報が不必要に送信されるからである。例えば、そのような状態は２つのＡＲＱピアエンティティ間で送信される多くの数のＤ−ＰＤＵをもつシステムにおいて発生し、これらＤ−ＰＤＵは確認応答され、再送のために選択的に要求されねばならない。あるエラー制御の場合には、現存する解決策は多大な量の不必要なオーバヘッドを導き込むことになる。次の例はそのような状態を表している。
【００１９】
現在、所謂第３世代のセルラ通信システムのために標準化されている広帯域符号分割多元接続（ＷＣＤＭＡ）システムにおいて、用いられる１つのＡＲＱプロトコルは、ＲＬＣプロトコルである。そのＳＮセットは０〜４０９５の値を含み、それは各ＳＮが１２ビットで符号化されることを意味している。高速データ伝送では、相対的に大きなセットのＳＮがいくつかのＳ−ＰＤＵにおいてアドレスされねばならないという仮定がなされる。また、１００個のＤ−ＰＤＵ（ＳＮ＝１〜１００）のステータスが、Ｓ−ＰＤＵにおけるＲＬＣピアエンティティ間で通信される必要があることを仮定する。
【００２０】
以下の表１は、上述したリストによる、また、ビットマップによる方法を用いてＳ−ＰＤＵを符号化するために必要なビット数を示している。異なるエラー環境が備えられて、２つの方法について必要なビット数の大きな違いを強調している。次の要素サイズが用いられることを仮定する。即ち、ビットマップ＝１２８ビット、長さ＝５ビット、１ＰＤＵフォーマット識別子＝１ビット（Ｄ−ＰＤＵとＳ−ＰＤＵとを区別するために）である。そのようなものとして、表１に示される異なるＳ−ＰＤＵサイズが、上述した式（１）と（２）とに従って、夫々計算される。表１の第２〜５行で図示されているように、現存する解決策の両方とも、示されたエラー環境に対して効率的に小さなＳ−ＰＤＵを構築する点で問題をもっている。リスト（ＬＩＳＴ）の長さはエラーのＤ−ＰＤＵの数にはそれほど依存してはいないが、むしろ、用いられるウィンドウ内のエラーの分布に依存している。この事実は表１の第１行と第２行とを比較することにより明白になる。
【００２１】
【表１】
0004579421.tif 000004
【００２２】
解決されるべき問題を一般的な言い方をすれば、メッセージにおいて、任意の量のステータスとｍの数のセットからｎの数の分布とを効率的に表現する（符号化する）仕方を決定することである。そのようなものとして、ＡＲＱプロトコルにおいてＳ−ＰＤＵのサイズを最小化するために用いられる方法について、大きな必要がある。また、もし、全ての可能性のあるＳＮを単一のＳ−ＰＤＵへと合わせることが可能でないなら、限定されたサイズをもつＳ−ＰＤＵにおいてＳＮの数を最大化するために用いられる方法についても、大きな必要がある。以下に詳細に説明するように、本発明は首尾よく上述した問題と他の関連する問題とを解決している。
【００２３】
発  明  の  要  約
本発明の実施形態に従えば、ＡＲＱプロトコルにおけるフィードバック応答を最小化する方法が備えられ、そこでは異なる機構が用いられてエラーのＤ−ＰＤＵを示し、Ｓ−ＰＤＵを構築する。特に、これらの異なる機構が単一のＳ−ＰＤＵへと組み合わせられる。Ｓ−ＰＤＵはある基準に従ってシステム性能を最適化するために構築される。そのような用いられる基準の１つはＳ−ＰＤＵのサイズを最小化することである。そのような用いられる基準の２つ目は制限されたＳ−ＰＤＵに含まれるＳＮの数を最大化することである。
【００２４】
本発明の重要な技術的利点は、無線インタフェースのバンド幅の資源が節約されることである。
【００２５】
本発明の重要な別の技術的利点は、プロトコルのオーバヘッドが最小化されることである。
【００２６】
本発明の重要なさらに別の技術的利点は、システム能力が向上することである。
【００２７】
本発明の重要なさらに別の技術的利点は、選択的繰り返しＡＲＱプロトコルにおけるフィードバック応答の数が最小化されることである。
【００２８】
図  面  の  詳  細  な  説  明
本発明の好適な実施形態とその利点は、図面の図１〜１３を参照することによって最善の理解が得られる。種々の図面で同様のまた対応する部分については同じ番号が用いられている。
【００２９】
本質的には、本発明の第１実施形態に従って、ＡＲＱプロトコルにおけるフィードバック応答を最小化する方法が備えられ、そこでは異なる機構が用いられてエラーのＤ−ＰＤＵを示し、Ｓ−ＰＤＵを構築する。特に、これらの異なる機構が単一のＳ−ＰＤＵへと組み合わせられる。Ｓ−ＰＤＵはある基準に従ってシステム性能を最適化するために構築される。そのような用いられる基準の１つはＳ−ＰＤＵのサイズを最小化することである。そのような用いられる基準の２つ目は制限されたＳ−ＰＤＵに含まれるＳＮの数を最大化することである。
【００３０】
これ以後具体的に、説明される基本的な構成要素はメッセージである。この実施形態では、そのようなメッセージは、タイプ（Type）、長さ（Length）、値（Value）（ＴＬＶ）シンタックスを用いて説明される。言い換えると、そのようなメッセージは３つのフィールドを含む。１つのフィールドはタイプの情報を含み、２番目のフィールドは長さの情報を含み、３番目のフィールドは値の情報を含む。タイプのフィールドのサイズはゼロでないことが好ましいが、他の２つのフィールドのサイズはゼロでも良い。
【００３１】
とりわけ、前述したように、全ての現存するビットマップの解は、構築されたＳ−ＰＤＵにおける順番に並ぶＤ−ＰＤＵの最後に受信されたもののシーケンス番号（ここでは、ＳＳＮと呼ばれる）についての情報を含んでいる。そのＳＳＮはそのシーケンス番号に前にはエラーが存在しないことを示している。言い換えると、ＳＳＮは最大でそのＳＳＮのＳＮまでのＳＮを有する全てのＤ−ＰＤＵを確認応答するために用いられる。
【００３２】
この代表的な実施形態について、ＡＲＱプロトコルにおけるフィードバック応答を最小化するために用いられる基本的なメッセージが次のように構築される。この実施形態ではビットマップ（ＢＩＴＭＡＰ）による方法を用いて、構築されたＳ−ＰＤＵに含まれるＳＮは、ＳＮのセットの中のいずれかの（必ずしも第１である必要はない）エラーのＤ−ＰＤＵのＳＮを示している。これに続くＳＮのステータスはビットマップにおいて示される。最初のエラーのＤ−ＰＤＵのＳＮがこの代表的な実施形態において用いられているが、ビットマップによる方法では、その代わりにいずれかのＤ−ＰＤＵ（ＳＮセットから）が用いられても良いことを理解すべきである。その場合、ビットマップはまた、構築されたＳ−ＰＤＵに含まれるＳＮのステータス（０或いは１）を含まねばならない。そのようなものとして、“ビットマップ（ＢＩＴＭＡＰ）”メッセージは、タイプ識別子フィールド、第１のＳＮ（ＦＳＮ）フィールド、ビットマップ長フィールド、及びビットマップフィールドを備えて創成される。図４は、本発明の第１実施形態に従ってＳ−ＰＤＵで用いられるそのようなフィールドを備えたビットマップメッセージを図示している。
【００３３】
図４に示されるビットマップメッセージにおいて、多くの数の方法が用いられてビットマップの長さ（長さ（ＬＥＮＧＴＨ）フィールド）を表現する。１つの方法では、前もって定義された数のビットが用いられて基本的なデータユニットにおけるビットマップのサイズを表現する。そのようなデータユニットは均一的なものである必要はなく、例えば、１つ以上のビット、バイト、ワードなどを含むことができる。例えば、バイトが基本データユニットとして用いられるなら、長さ（ＬＥＮＧＴＨ）フィールドにおける値ｘは、８*ｘＳＮｓがビットマップによってカバーされることを意味している。この結果得られた値はまた、ビットマップのサイズをビットで表現している。
【００３４】
ビットマップの長さを表現するのに用いられる第２の方法では、異なるＳＮが用いられてビットマップによってカバーされる最後のＳＮを示すことができる。その時、長さ（ＬＥＮＧＴＨ）フィールドのサイズはＦＳＮフィールドのサイズに等しい。そのようなものとして、ビットマップのサイズはＦＳＮ値を長さ（ＬＥＮＧＴＨ）値から差し引くことにより計算される。
【００３５】
ビットマップの長さを表現するのに用いられる第３の方法は、ビットマップのサイズを固定して、長さ（ＬＥＮＧＴＨ）フィールドがＳ−ＰＤＵにおいて必要とされないようにすることである。或いは、長さ（ＬＥＮＧＴＨ）フィールドのサイズがゼロにセットされても良い。また、ビットマップがカバーするＳＮに遠隔的に信号を発信するなら、ＦＳＮフィールドのサイズもゼロにセットされても良い。そのような方法を以下に、より詳細に説明する。
【００３６】
とりわけ、従来のデータ圧縮方法が用いられてビットマップフィールドにおける情報を圧縮する。そのようなものとして、通常及び圧縮されたビットマップが１つのＳ−ＰＤＵに含まれる。この場合、圧縮ビットマップについてのタイプフィールドの値は、通常のビットマップに関するものとは異なるであろう。
【００３７】
前述したように、現存するリスト（ＬＩＳＴ）による方法の重大な欠点は、２つのＳＮが各エラーグループに関して必要とされる点である。エラーグループは、Ｄ−ＰＤＵの単一のエラー或いはいくつかの連続するエラーを有している。この代表的な実施形態に従ってリスト（ＬＩＳＴ）による方法を用いてそのような問題を解決するために、ただエラーのＳＮだけがリストされる。言い換えると、新しいリスト（ＬＩＳＴ）タイプが定義され、そこでは単一のエラーだけがリストされる。その結果、結果として得られるＳ−ＰＤＵのサイズは、現存するリストによる解決策と比較して、あるエラーの場合には非常に小さくされる。
【００３８】
この実施形態に従って、Ｓ−ＰＤＵのサイズを小さくするために用いられる別の方法は、現存するリスト（ＬＩＳＴ）による方法（エラーグループ当り２つのＳＮ）と上述した単一のエラーＳＮ  リスト（ＬＩＳＴ）方法とを組み合わせてそのリストメッセージを創成することである。例えば、現存するリスト（ＬＩＳＴ）による方法は、長さ（ＬＥＮＧＴＨ）フィールド値を創成する次のような規則を導入することにより大きく改善される。
【００３９】
（１）ゼロ値は単一のエラーＳＮ  リスト（ＬＩＳＴ）方法が適用されることを意味する。第２の（新しい）長さフィールドは元々の長さ（ＬＥＮＧＴＨ）フィールドの後に直接に含まれて第２のフィールドの後に直接続く単一のエラーＳＮの数を示す。全てのリスト要素は単一のエラーのＳＮを表現し、確認応答は備えられないが、このリストによる方法を用いる。
【００４０】
（２）奇数の値は、最後のリスト要素が確認応答であることを示唆する。
【００４１】
（３）偶数（ゼロを含む）の値は、最後の要素が確認応答ではないことを示唆する。
その結果、この実施形態に従う上述した規則に続いて、今や、表１の第２行についての（ＬＩＳＴ）Ｓ−ＰＤＵは図５に示されるフィールドと内容とを含む。そのようなものとして、表１に図示された例の第２行に示されるフィールドサイズが、図５によって図示される実施形態に関して用いられるものであるなら、Ｓ−ＰＤＵの全サイズは５９ビットである。その結果、本発明に従えば、結果として得られるＳ−ＰＤＵに必要なビット数は現存するリスト（ＬＩＳＴ）による解決策に必要なビット数（１１４）よりもかなり小さいものである。
【００４２】
図６はリスト（ＬＩＳＴ）による方法を用いてＳ−ＰＤＵのサイズを小さくするために用いられる別の方法を図示する図である。この実施形態に従って用いられる方法は、“最後の”ＳＮでエラーの長さを示す代わりに、各リスト要素の後にエラーの長さを決定するフィールドを含ませることである。たいていのシステムにおいて、長さフィールドのサイズは実質的にＳＮフィールドのサイズよりも小さいであろう。さらにその上、通常はＳ−ＰＤＵにおいて、非常に大きな連続するエラーのＤ−ＰＤＵ（即ち、大きなエラーグループ）を表現する必要はない。
【００４３】
図６において、Ｓ−ＰＤＵにおいて（ＬＩＳＴ’として記されている）新しいメッセージのフィールドが示されている。各ＳＮiの後に導入される新しい長さフィールドは、１≦Ｉ≦ＬＥＮＧＴＨについてＬiと記される。とりわけ、ゼロの値がＬiについて用いられ、さらに結果として得られるＬＩＳＴ’メッセージの機能性を改善している。そのようなものとして、次の代替案が用いられても良い。
【００４４】
（１）Ｌiについてのゼロの値はＳＮiが確認応答である（即ち、Ｌiはエラーを指摘していない）ことを意味する。
【００４５】
（２）ゼロの値はＬＩＳＴ’メッセージの最後を表現する。最初の長さ（ＬＥＮＧＴＨ）フィールドは、もし最後のＳＮの解釈が前もって定義されているならば省略されても良い。例えば、最後のＳＮはつねに確認応答であるように（例えば、第１の代替案として）限定されるか、或いは、（例えば、単一のエラーを指摘するために）その長さは前もって定義される。
【００４６】
本発明の第２の実施形態に従えば、多くの数の異なるメッセージタイプが組み合わされてＳ−ＰＤＵを創成する。これらのメッセージタイプはＳ−ＰＤＵに任意の順序で付加され、Ｓ−ＰＤＵに含まれるメッセージの数や、或いはメッセージのタイプについては規則はない。この代表的な実施形態の場合、そのようなメッセージ各々はタイプ識別子を含み、その長さは固定されるか、或いは各特定のメッセージについて長さフィールドによって示される。第１のタイプの識別子は、結果として得られるＳ−ＰＤＵにおいて前もって定義された位置をもつことが好ましい。そのタイプ識別子の残りは含まれるメッセージのサイズに依存して任意のロケーションに位置する。例えば、メッセージ、ＬＩＳＴ’、ＢＩＴＭＡＰ’及びＡＣＫはＳ−ＰＤＵに含まれても良い。
【００４７】
おそらくＳ−ＰＤＵに含まれるそのようなメッセージの数は、Ｓ−ＰＤＵにおいて用いられるタイプ識別子フィールドのサイズ（ビット）を決定する。例えば、そのようなタイプ識別子フィールドのサイズは次の式によって決定される。
0004579421.tif 000005
ここで、演算子［  ］はその引数を次に最も大きい整数値に丸める。その引数の“＋１”の部分は、タイプ識別子が用いられＳ−ＰＤＵには他のメッセージが含まれていないことを示すために用いられる。この特別な識別子はここで、“ＮＯ＿ＭＯＲＥ”メッセージとして記されている。そのようなものとして、式（３）に従えば、タイプフィールドのサイズは３つの異なるメッセージに関して２ビットである。なぜなら、［ｌｏｇ2（４）］＝２であるからである。
【００４８】
この実施形態に従って構築される“ＡＣＫ”メッセージの内容は図７に示されている。図示されたＡＣＫメッセージはタイプ識別子とＳＮとを含んでいる。このＡＣＫメッセージはＳ−ＰＤＵの終わりを印しづけ、そして、このＳ−ＰＤＵ内でエラーであることが示されていない全ての前にあるＤ−ＰＤＵはＳＮによって確認応答される。その結果、そのようなＡＣＫメッセージがＳ−ＰＤＵに含まれているとき、組み合わされたＳ−ＰＤＵを終了させるために、ＮＯ＿ＭＯＲＥメッセージを含める必要はない。
【００４９】
確認応答の機能（即ち、Ｌiについてゼロの値をもつことはＳＮiが確認応答であることを意味する）をもったＬＩＳＴ’メッセージが（長さ（ＬＥＮＧＴＨ）フィールドを伴って）用いられることを仮定する。リスト（ＬＩＳＴ’）メッセージの後にビットマップ（ＢＩＴＭＡＰ’）メッセージが直接に含まれるとき、ＦＳＮフィールドのサイズはゼロである。そのようなものとして、ビットマップにおいて表現される最初のＳＮはＳＮLENGTH＋ＬLENGTHである。さらにその上、リスト（ＬＩＳＴ’）メッセージの長さ（ＬＥＮＧＴＨ）フィールドにおけるゼロは付加的な長さ（ＬＥＮＧＴＨ）フィールドが含まれることを意味し、そして、そのメッセージはＬSNiフィールドを伴わずに図５に示されているように構築される。
【００５０】
上述したリスト（ＬＩＳＴ）の特徴を得るための別の方法は、（例えば、“ＬＩＳＴ”と記される）新しいタイプを定義することである。しかしながら、そのタイプフィールドのサイズは影響を受け、その結果、より大きなＳ−ＰＤＵとなる。いずれにしても、上述した組み合わせによる方法のためには従うべき正確な規則を選択することにおいて考慮するトレードオフ（これはシステムに依存するが）がある。
【００５１】
図８は上述した組み合わせによる方法に従ってＳ−ＰＤＵがどのように構築されるのかを図示した図である。示されているように、結果的に生み出されるＳ−ＰＤＵは２つのビットマップ（ＢＩＴＭＡＰ’）メッセージと１つのリスト（ＬＩＳＴ’）とを含む。２番目のビットマップ（ＢＩＴＭＡＰ’）メッセージはＦＳＮフィールドを含まない（或いは、ＦＳＮフィールドのサイズがゼロである）。その結果、ビットマップの最初の要素はＳＮLENGTH＋ＬLENGTHという値をもつＳＮを表現している。
【００５２】
上述した組み合わせによる方法の利点を示すために、表１に関して上述した例にその方法が適用される。そのようなものとして、表２は本発明の第２実施形態に従って、Ｓ−ＰＤＵに含まれる異なるメッセージを（その対応するビット値とともに）示している。この実施形態では、各Ｓ−ＰＤＵは示されているタイプ識別子の１つで始まる。また、長さ（ＬＥＮＧＴＨ）とＬSNiフィールドのサイズは５ビットに固定される。その結果、これらのフィールドは夫々０〜３２（２5）の値を保持できる。とりわけ、そのフィールドのサイズは固定されているが、それらのサイズは、この例のように必ずしも等しくなくとも良い（即ち、ビットマップ（ＢＩＴＭＡＰ’）メッセージにおける長さ（ＬＥＮＧＴＨ）フィールド）のサイズはリスト（ＬＩＳＴ’）メッセージにおける長さ（ＬＥＮＧＴＨ）フィールドのサイズとは異なり得る）。ビットマップ（ＢＩＴＭＡＰ’）メッセージにおける長さ（ＬＥＮＧＴＨ）フィールドの値は、バイト単位でビットマップのサイズに対応している（即ち、最大値で８＊３２＝２５６個のＳＮが単一のＳ−ＰＤＵにおいてアドレス可能である）。ＳＮ値を含む全てのフィールドは１２ビットのサイズをもつ（即ち、ＦＳＮ、ＳＮ、及びＳＳＮフィールド）。
【００５３】
【表２】
0004579421.tif 000006
【００５４】
図９〜１３は夫々、上述した例について表１に示された各列についてのＳ−ＰＤＵの内容を示す図である。この実施形態では、組み合わせが選択されてＳ−ＰＤＵの全サイズを最小にしている。
【００５５】
表１に関して上述された例によって図示されているように、図９は結果として得られる（組み合わせの）Ｓ−ＰＤＵにおける第１行の内容を示し、図１０は第２行の内容を示し、図１１は第３行の内容を示す。なお、図１１におけるリスト要素ＳＮiの代わりにＡＣＫタイプを含めることによって、Ｓ−ＰＤＵの全サイズに関して付加的な５ビットが節約される。図１２は結果として得られるＳ−ＰＤＵにおける第４行の内容を示し、図１３は第５行の内容を示す。そのようなものとして、全ての符号化されたＳ−ＰＤＵの内容は、“ビット”列からの全ての値を連結することにより得られる。例えば、Ｓ−ＰＤＵ（図９）の第１行の内容は、次のように表される。
【００５６】
“01000010000001100111101111000001100101”。
【００５７】
表３は現存するリスト（ＬＩＳＴ）による方法とビットマップ（ＢＩＴＭＡＰ）による方法と、また、第２実施形態に従う上述した組み合わせによる方法とに従って構築されたＳ−ＰＤＵのサイズを示している。Ｓ−ＰＤＵのサイズは、図９〜１３における“フィールドサイズ”列を加算することによって計算される。表３に図示されているように、本発明の組み合わせによる方法から得られるＳ−ＰＤＵのサイズは、現存する解決策から得られるＳ−ＰＤＵよりもかなり小さい。
【００５８】
【表３】
0004579421.tif 000007
【００５９】
多くのＡＲＱプロトコルにおいて、Ｄ−ＰＤＵのサイズは前もって定義され、限定されたセットの異なる値をもつことができる。もし、送信側ＡＲＱエンティティに備えられるユーザデータ量がＤ−ＰＤＵのサイズよりも小さいなら、パディングが用いられる。パディングは無意味なデータが用いられてＤ−ＰＤＵの残りの空きロケーションを埋めてしまう技術である。例えば、Ｄ−ＰＤＵが２０バイトのユーザデータでいっぱいになり、送信側のＡＲＱエンティティが１４バイトのユーザデータをもつだけであるなら、Ｄ−ＰＤＵの残りの部分は６バイトのパディングデータで埋められるか、或いはパディングされる。そのユーザデータ部の長さはＤ−ＰＤＵで示される。ＧＰＲＳとＷ−ＣＤＭＡシステムにおけるＲＬＣプロトコルはこの種のパディング機能を用いている。
【００６０】
第２実施形態の組み合わせによる方法はまた、ピギーバッキングとともに効率的に用いられる。例えば、十分な空間がステータスメッセージとともにパディングフィールドを埋めるために存在するならば、ＡＲＱエンティティが最後のユーザデータバイトの終わりの後にステータス情報をピギーバッグ（付加）できる。パディングバイトを含むＤ−ＰＤＵに含まれるステータス情報がないときにはいつでも、ＮＯ＿ＭＯＲＥタイプの識別子が用いられる。このピギーバッキング（付加）方式は、２つのＡＲＱエンティティ間で交換される数多くのパケットをうまく低減させ、その結果、システム容量を節約している。ピギーバッキング（付加）を用いる現存するＡＲＱプロトコルについての場合であるが、ピギーバッキング（付加）方式のためにＤ−ＰＤＵにおいて予約されるフィールドはないので、そのようなピギーバッキング（付加）方式のコストは相対的に小さい。
【００６１】
本発明の方法と装置の実施形態が添付図面において図示され、前述の詳細な説明で説明されたが、本発明はその開示された実施形態に限定されるものではなく、数多くの再構成、変形例、代用が、請求の範囲によって説明され定義されるような本発明の精神を逸脱することなく可能であることが理解されるべきである。
【図面の簡単な説明】
本発明の方法と装置のより完全な理解には添付図面に関連してとられた詳細な説明への参照がなされねばならないが、その図面は以下の通りである。
【図１】  ＡＲＱプロトコルの使用を図示するシーケンス図である。
【図２】  ＳＮを符号化する現存するリストによる方法を用いて受信側によって創成されるＳ−ＰＤＵを示す図である。
【図３】  ＳＮを符号化する現存するビットマップによる方法を用いて受信側によって創成されるＳ−ＰＤＵを示す図である。
【図４】  本発明の第１実施形態に従って構築されたＳ−ＰＤＵに用いられるビットマップメッセージである。
【図５】  本発明の第１実施形態に従って構築された、表１の第２行に関し、ＬＩＳＴ  Ｓ−ＰＤＵのフィールドと内容とをもつメッセージの図である。
【図６】  本発明の第１実施形態に従って構築された、Ｓ−ＰＤＵにおけるＬＩＳＴ’メッセージのフィールドの図である。
【図７】  本発明の第２実施形態に従って構築された、“ＡＣＫ”メッセージの内容を示す図である。
【図８】  第２実施形態の組み合わせによる方法に従ってどのようにＳ−ＰＤＵが構築されるのかを描いた図である。
【図９】  本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第１行の内容を示す図である。
【図１０】  本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第２行の内容を示す図である。
【図１１】  本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第３行の内容を示す図である。
【図１２】  本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第４行の内容を示す図である。
【図１３】  本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第５行の内容を示す図である。
【図１】
0004579421.tif 000008
【図２】
0004579421.tif 000009
【図３】
0004579421.tif 000010
【図４】
0004579421.tif 000011
【図５】
0004579421.tif 000012
【図６】
0004579421.tif 000013
【図７】
0004579421.tif 000014
【図８】
0004579421.tif 000015
【図９】
0004579421.tif 000016
【図１０】
0004579421.tif 000017
【図１１】
0004579421.tif 000018
【図１２】
0004579421.tif 000019
【図１３】
0004579421.tif 000020