JP4579421B2 - Ａｒｑプロトコルにおけるフィードバック応答を最小化する方法 - Google Patents
Ａｒｑプロトコルにおけるフィードバック応答を最小化する方法 Download PDFInfo
- Publication number
- JP4579421B2 JP4579421B2 JP2000611424A JP2000611424A JP4579421B2 JP 4579421 B2 JP4579421 B2 JP 4579421B2 JP 2000611424 A JP2000611424 A JP 2000611424A JP 2000611424 A JP2000611424 A JP 2000611424A JP 4579421 B2 JP4579421 B2 JP 4579421B2
- Authority
- JP
- Japan
- Prior art keywords
- pdu
- field
- bitmap
- message
- length
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims description 58
- 230000004044 response Effects 0.000 title claims description 11
- 238000004891 communication Methods 0.000 claims description 6
- 238000010586 diagram Methods 0.000 description 14
- 230000005540 biological transmission Effects 0.000 description 7
- 230000007246 mechanism Effects 0.000 description 7
- 230000008901 benefit Effects 0.000 description 6
- 238000011084 recovery Methods 0.000 description 4
- 230000010267 cellular communication Effects 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1628—List acknowledgements, i.e. the acknowledgement message consisting of a list of identifiers, e.g. of sequence numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1614—Details of the supervisory signal using bitmaps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1621—Group acknowledgement, i.e. the acknowledgement message defining a range of identifiers, e.g. of sequence numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1809—Selective-repeat protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
関連出願の相互参照
本特許出願は１９９９年４月９日出願の係属中の米国特許仮出願シリアル番号第６０／１２８，５１７号の優先権を主張しており、ここで、その開示全体を参照によって組み込む。
【０００２】
本発明の背景
発明の技術分野
本発明は一般的には通信の分野に関し、特に、例えば、選択的繰り返しＡＲＱプロトコルのような自動再送要求（ＡＲＱ）プロトコルにおけるフィードバック応答を最小化する方法に関する。
【０００３】
関連分野の説明
データが通信ネットワークのノード間で搬送されるとき、一定のアルゴリズムが用いられてエラーデータの伝送やノード間での伝送リンクにおけるデータ損失からの回復を行なう。エラーデータの伝送からの回復に一般に用いられているアルゴリズムは、ＡＲＱプロトコルとして言及される。
【０００４】
現存するＡＲＱプロトコル（即ち、アルゴリズム）は伝送リンクによって互いに通信を行なう２つのピアエンティティを含む。そのようなエンティティ各々は受信側と送信側とを含む。ピアエンティティ間で搬送されるデータユニットは一般にプロトコルデータユニット（ＰＤＵ）として言及される。ＡＲＱプロトコルはＰＤＵを送受信するための一定の規則と共に、ＰＤＵ構造のための規則をも含んでいる。そのようなものとして、“自動再送要求”という名称は、そのプロトコルの基本的な機能を示している。受信側は送信側に伝送中に失われた、或いはエラーが含まれるそれらＰＤＵを再送するように要求する。
【０００５】
受信側は、どのＰＤＵが正しく受信されたのか（即ち、受信側は正しく受信されたＰＤＵを確認応答する）と、どのＰＤＵが正しく受信されなかったのかとの少なくとも１つについて送信側に通知することができる。送信側はこの情報を受信するとき、その“失われた（lost）”ＰＤＵを再送する。言い換えると、ＡＲＱプロトコルは、通信システムにおける送信側と受信側との間の効率的な再送機構の利用を許している規則のセットである。これらの規則は、例えば、ＰＤＵがどのように、またどんな形式で構築されて受信側が搬送されたＰＤＵを正しく解釈してそれらに応答するのかを規定している。
【０００６】
主に３つのタイプの情報要素、ユーザデータ、エラー回復制御データ、及び共通制御データが２つのＡＲＱピアエンティティ間で転送される。これら３つのタイプのＰＤＵが全ての現存するＡＲＱプロトコルにおいて見出される。ユーザデータＰＤＵは少なくともユーザデータとシーケンス番号とを含む。エラー回復制御データＰＤＵは、エラー回復のために必要な種々の制御情報と、肯定及び否定確認応答のような制御機能とを含む。共通制御データＰＤＵは共通制御データを含む。
【０００７】
多くの現存するＡＲＱプロトコルに対する基礎を形造る知られたハイレベルデータリンク制御（ＨＤＬＣ）プロトコルにおいて、３つのタイプのＰＤＵは夫々、情報フレーム（Ｉ−フレーム）、監視フレーム（Ｓ−フレーム）、及び非番号フレーム（Ｕ−フレーム）と呼ばれる。ＨＤＬＣに由来するＡＲＱプロトコルの例は、汎欧州デジタル移動電話方式（ＧＳＭ）で用いられている無線リンクプロトコル（ＲＬＰ）、汎用パケット無線サービス（ＧＰＲＳ）で用いられている無線リンク制御（ＲＬＣ）及び論理リンク制御（ＬＬＣ）、ＩｒＤＡシステムで用いられている赤外線リンクアクセスプロトコル（ＩｒＬＡＰ）、及びＸ．２５システムで用いられているＬＡＰ−Ｂプロトコルである。とりわけ、ユーザデータと少なくともシーケンス番号を含むＰＤＵはここでデータ−ＰＤＵ（Ｄ−ＰＤＵ）として示され、エラー制御／回復のために必要な制御データを含むＰＤＵはここでステータス−ＰＤＵ（Ｓ−ＰＤＵ）として示される。
【０００８】
たいていの通信システムにおいて、ユーザデータ情報がピアエンティティ間で両方向に搬送される。ＡＲＱプロトコルに含まれる共通の特徴は、ユーザデータＰＤＵにエラー制御情報を含むという可能性である。この能力は、“ピギーバックキング（piggybacking）”として知られている。例えば、ＨＤＬＣに由来するプロトコルの全てのＩ−フレーム（即ち、Ｄ−ＰＤＵ）には確認応答が含まれる。その確認応答は最後に（順番に並んで）正しく受信されたＰＤＵのシーケンス番号についてピアエンティティに通知する。
【０００９】
最も一般的な現存するＡＲＱプロトコルは１つ以上の機構、例えば、ストップ−アンド−ウェイト（Stop-and-Wait）ＡＲＱ、ゴー−バック−Ｎ（Go-back-N）ＡＲＱ、及び選択的繰り返しＡＲＱを実施して伝送リンクにおけるエラーからの回復を行なう。これらの機構とＡＲＱの利用は一般によく知られている。
【００１０】
図１はＡＲＱプロトコルの使用を図示したシーケンス図である。図示されているように、２つのＡＲＱピアエンティティ１０、１２は互いに通信している。図１における矢は２つのエンティティ間のＰＤＵの送信を示し、各ＰＤＵの内容は各矢の上に直接説明されている。図１において、送信されるＤ−ＰＤＵとＳ−ＰＤＵとのシーケンスが示されている。Ｄ−ＰＤＵは、ユーザデータと、シーケンス番号（ＳＮ）と、おそらくピギーバック（付加）されたエラー制御情報とを含む。Ｓ−ＰＤＵはステータス情報を含むがユーザ情報は含まない。シーケンス番号（ＳＮ＝ｘ）はＤ−ＰＤＵと関連しておりその特定のＤ−ＰＤＵを識別する。確認応答（ＡＣＫ＝ｘ）はＳＮ＜ｘであるいずれかのＰＤＵを確認応答するために用いられる。否定確認応答（ＮＡＫ＝ｘ）は正しく受信されなかった（ＳＮ＝ｘである）ＰＤＵを確認応答するために用いられる。
【００１１】
２つのタイプのエラー制御フィードバック応答が図１に示されている。フィードバック応答の１つ（例えば、Ｓ−ＰＤＵ、ＡＣＫ＝２）１４について、第２のＡＲＱピアエンティティ１２は、それがＳＮ＝０とＳＮ＝１のＰＤＵを受信したことを確認応答する。第２のタイプのフィードバック応答（例えば、Ｓ−ＰＤＵ、ＮＡＫ＝３）１６について、第２のピアエンティティ１２はＳＮ＝３であるＰＤＵが改悪されており、第１のピアエンティティ１０によって再送されるべきであることを示す。
【００１２】
上述のように、Ｓ−ＰＤＵはピアエンティティ間で送信される特別なＰＤＵである。Ｓ−ＰＤＵは改悪されたＰＤＵのＳＮについての情報を含む。２つの主要な方法が現在、Ｓ−ＰＤＵ内のＳＮを符号化するのに用いられている。１つのそのような方法は、再送されるＳＮのリストを用いることである。２番目の方法は、再送されるＳＮを表現するビットマップを用いることである。そのようなものとして、ＳＮを表現することとは別に、Ｓ−ＰＤＵはまた、異なるＰＤＵフォーマット間（例えば、Ｄ−ＰＤＵとＳ−ＰＤＵ）を区別するために受信側によって用いられるフォーマット識別子を含んでいる。
【００１３】
ＳＮを符号化するために用いられるリストによる方法は、Ｓ−ＰＤＵにおけるエラーのＰＤＵのＳＮを含んでいる。もし、そのリストの長さが前もって定義されておらず、それによって知られるのであれば、この長さ情報はＳ−ＰＤＵにおいて示される。例えば、長さフィールドはＳ−ＰＤＵに含まれる。図２はＳＮを符号化するためのリストによる方法を用いて受信側によって創成されるそのようなＳ−ＰＤＵを示している。
【００１４】
図２において、もし、送信側がＳＮ＝０〜１５のＤ−ＰＤＵのシーケンスを送信し、ＳＮ＝３，５，６，７，８のＰＤＵが（正しく受信されず）損失したなら、受信側は示された内容をもつＳ−ＰＤＵを創成できる。例えば、リスト（長さフィールドの後の）にある最初の２つの要素がＳＮ＝３のＤ−ＰＤＵがエラーであったことを示す。そのリストにある３番目と４番目の要素は、ＳＮ＝５〜８のＤ−ＰＤＵがエラーであったことを示す。最後の要素は残りのＰＤＵ（最大で１５のＳＮ）を確認応答するために含まれている。
【００１５】
Ｓ−ＰＤＵのサイズは、ＰＤＵフォーマット識別子フィールド、長さフィールド、及びＳＮフィールドを表現するために用いられるビット数に依存している。そのようなものとして、Ｓ−ＰＤＵのサイズは以下の式によって計算される。
例えば、このリストによる方法は、ＳＳＣＯＰプロトコルで用いられており、そこでは、２つのＳ−ＰＤＵフォーマットが存在し、可変リスト長については“ＳＴＡＴ”、そして限定された数の要素（例えば、２つの要素）をもつリストについては“ＵＳＴＡＴ”という項によって示される。
【００１６】
図３はＳＮを符号化するためのビットマップによる方法を用いた送信側によって創成されるＳ−ＰＤＵを示している。ＳＮを示すためにビットマップが用いられるとき、受信側は順番に正しく受信した最後のＤ−ＰＤＵのＳＮとビットマップからＳ−ＰＤＵを創成する。このＳＮはスタートＳＮ（ＳＳＮ）として言及される。その結果、このＳ−ＰＤＵは暗に最大でＳＳＮの数までの全ての受信したＤ−ＰＤＵに確認応答している。ビットマップでの各ロケーションは、ＳＳＮに相対的に特定のＳ−ＰＤＵをアドレスするために用いられる。通常、ビットマップのサイズはＡＲＱ受信側のウィンドウのサイズに固定され、明示的に示されねばならないことはない。もし、そのビットマップが固定されないなら、その長さは示されねばならない。
【００１７】
図３に示されるビットマップは、図２に関して上述された例から創成されたＳ−ＰＤＵとウィンドウサイズが１６であることを示している。そのようなものとして、ビットマップの各ロケーションは２つの値、即ち、０或いは１のいずれか１つをもつことができる。“１”はＳＮ＝（ＳＳＮ＋bit_position）が正しく受信されたことを意味し、“０”はＳＮ＝（ＳＳＮ＋bit_position）が正しく受信されなかったことを意味する。もちろん、“０”と“１”の意味は互いに交換可能である。そのようなビットマップを用いるときＳ−ＰＤＵのサイズは次の式から生じる。
ＧＰＲＳシーケンスにおけるＲＬＣとＬＬＣの両方のプロトコルは、そのような式を用い、エラー制御の目的のためにピアエンティティ間でビットマップを搬送する。
【００１８】
現存するＡＲＱプロトコルのもつ重大な問題は、そのプロトコルが構成において静的（例えば、固定長メッセージが用いられる）である点である。ある状態の場合、このやり方はバンド幅資源の浪費につながる。なぜなら、多大な量のオーバヘッド情報が不必要に送信されるからである。例えば、そのような状態は２つのＡＲＱピアエンティティ間で送信される多くの数のＤ−ＰＤＵをもつシステムにおいて発生し、これらＤ−ＰＤＵは確認応答され、再送のために選択的に要求されねばならない。あるエラー制御の場合には、現存する解決策は多大な量の不必要なオーバヘッドを導き込むことになる。次の例はそのような状態を表している。
【００１９】
現在、所謂第３世代のセルラ通信システムのために標準化されている広帯域符号分割多元接続（ＷＣＤＭＡ）システムにおいて、用いられる１つのＡＲＱプロトコルは、ＲＬＣプロトコルである。そのＳＮセットは０〜４０９５の値を含み、それは各ＳＮが１２ビットで符号化されることを意味している。高速データ伝送では、相対的に大きなセットのＳＮがいくつかのＳ−ＰＤＵにおいてアドレスされねばならないという仮定がなされる。また、１００個のＤ−ＰＤＵ（ＳＮ＝１〜１００）のステータスが、Ｓ−ＰＤＵにおけるＲＬＣピアエンティティ間で通信される必要があることを仮定する。
【００２０】
以下の表１は、上述したリストによる、また、ビットマップによる方法を用いてＳ−ＰＤＵを符号化するために必要なビット数を示している。異なるエラー環境が備えられて、２つの方法について必要なビット数の大きな違いを強調している。次の要素サイズが用いられることを仮定する。即ち、ビットマップ＝１２８ビット、長さ＝５ビット、１ＰＤＵフォーマット識別子＝１ビット（Ｄ−ＰＤＵとＳ−ＰＤＵとを区別するために）である。そのようなものとして、表１に示される異なるＳ−ＰＤＵサイズが、上述した式（１）と（２）とに従って、夫々計算される。表１の第２〜５行で図示されているように、現存する解決策の両方とも、示されたエラー環境に対して効率的に小さなＳ−ＰＤＵを構築する点で問題をもっている。リスト（ＬＩＳＴ）の長さはエラーのＤ−ＰＤＵの数にはそれほど依存してはいないが、むしろ、用いられるウィンドウ内のエラーの分布に依存している。この事実は表１の第１行と第２行とを比較することにより明白になる。
【００２１】
【表１】
【００２２】
解決されるべき問題を一般的な言い方をすれば、メッセージにおいて、任意の量のステータスとｍの数のセットからｎの数の分布とを効率的に表現する（符号化する）仕方を決定することである。そのようなものとして、ＡＲＱプロトコルにおいてＳ−ＰＤＵのサイズを最小化するために用いられる方法について、大きな必要がある。また、もし、全ての可能性のあるＳＮを単一のＳ−ＰＤＵへと合わせることが可能でないなら、限定されたサイズをもつＳ−ＰＤＵにおいてＳＮの数を最大化するために用いられる方法についても、大きな必要がある。以下に詳細に説明するように、本発明は首尾よく上述した問題と他の関連する問題とを解決している。
【００２３】
発 明 の 要 約
本発明の実施形態に従えば、ＡＲＱプロトコルにおけるフィードバック応答を最小化する方法が備えられ、そこでは異なる機構が用いられてエラーのＤ−ＰＤＵを示し、Ｓ−ＰＤＵを構築する。特に、これらの異なる機構が単一のＳ−ＰＤＵへと組み合わせられる。Ｓ−ＰＤＵはある基準に従ってシステム性能を最適化するために構築される。そのような用いられる基準の１つはＳ−ＰＤＵのサイズを最小化することである。そのような用いられる基準の２つ目は制限されたＳ−ＰＤＵに含まれるＳＮの数を最大化することである。
【００２４】
本発明の重要な技術的利点は、無線インタフェースのバンド幅の資源が節約されることである。
【００２５】
本発明の重要な別の技術的利点は、プロトコルのオーバヘッドが最小化されることである。
【００２６】
本発明の重要なさらに別の技術的利点は、システム能力が向上することである。
【００２７】
本発明の重要なさらに別の技術的利点は、選択的繰り返しＡＲＱプロトコルにおけるフィードバック応答の数が最小化されることである。
【００２８】
図 面 の 詳 細 な 説 明
本発明の好適な実施形態とその利点は、図面の図１〜１３を参照することによって最善の理解が得られる。種々の図面で同様のまた対応する部分については同じ番号が用いられている。
【００２９】
本質的には、本発明の第１実施形態に従って、ＡＲＱプロトコルにおけるフィードバック応答を最小化する方法が備えられ、そこでは異なる機構が用いられてエラーのＤ−ＰＤＵを示し、Ｓ−ＰＤＵを構築する。特に、これらの異なる機構が単一のＳ−ＰＤＵへと組み合わせられる。Ｓ−ＰＤＵはある基準に従ってシステム性能を最適化するために構築される。そのような用いられる基準の１つはＳ−ＰＤＵのサイズを最小化することである。そのような用いられる基準の２つ目は制限されたＳ−ＰＤＵに含まれるＳＮの数を最大化することである。
【００３０】
これ以後具体的に、説明される基本的な構成要素はメッセージである。この実施形態では、そのようなメッセージは、タイプ（Type）、長さ（Length）、値（Value）（ＴＬＶ）シンタックスを用いて説明される。言い換えると、そのようなメッセージは３つのフィールドを含む。１つのフィールドはタイプの情報を含み、２番目のフィールドは長さの情報を含み、３番目のフィールドは値の情報を含む。タイプのフィールドのサイズはゼロでないことが好ましいが、他の２つのフィールドのサイズはゼロでも良い。
【００３１】
とりわけ、前述したように、全ての現存するビットマップの解は、構築されたＳ−ＰＤＵにおける順番に並ぶＤ−ＰＤＵの最後に受信されたもののシーケンス番号（ここでは、ＳＳＮと呼ばれる）についての情報を含んでいる。そのＳＳＮはそのシーケンス番号に前にはエラーが存在しないことを示している。言い換えると、ＳＳＮは最大でそのＳＳＮのＳＮまでのＳＮを有する全てのＤ−ＰＤＵを確認応答するために用いられる。
【００３２】
この代表的な実施形態について、ＡＲＱプロトコルにおけるフィードバック応答を最小化するために用いられる基本的なメッセージが次のように構築される。この実施形態ではビットマップ（ＢＩＴＭＡＰ）による方法を用いて、構築されたＳ−ＰＤＵに含まれるＳＮは、ＳＮのセットの中のいずれかの（必ずしも第１である必要はない）エラーのＤ−ＰＤＵのＳＮを示している。これに続くＳＮのステータスはビットマップにおいて示される。最初のエラーのＤ−ＰＤＵのＳＮがこの代表的な実施形態において用いられているが、ビットマップによる方法では、その代わりにいずれかのＤ−ＰＤＵ（ＳＮセットから）が用いられても良いことを理解すべきである。その場合、ビットマップはまた、構築されたＳ−ＰＤＵに含まれるＳＮのステータス（０或いは１）を含まねばならない。そのようなものとして、“ビットマップ（ＢＩＴＭＡＰ）”メッセージは、タイプ識別子フィールド、第１のＳＮ（ＦＳＮ）フィールド、ビットマップ長フィールド、及びビットマップフィールドを備えて創成される。図４は、本発明の第１実施形態に従ってＳ−ＰＤＵで用いられるそのようなフィールドを備えたビットマップメッセージを図示している。
【００３３】
図４に示されるビットマップメッセージにおいて、多くの数の方法が用いられてビットマップの長さ（長さ（ＬＥＮＧＴＨ）フィールド）を表現する。１つの方法では、前もって定義された数のビットが用いられて基本的なデータユニットにおけるビットマップのサイズを表現する。そのようなデータユニットは均一的なものである必要はなく、例えば、１つ以上のビット、バイト、ワードなどを含むことができる。例えば、バイトが基本データユニットとして用いられるなら、長さ（ＬＥＮＧＴＨ）フィールドにおける値ｘは、８*ｘＳＮｓがビットマップによってカバーされることを意味している。この結果得られた値はまた、ビットマップのサイズをビットで表現している。
【００３４】
ビットマップの長さを表現するのに用いられる第２の方法では、異なるＳＮが用いられてビットマップによってカバーされる最後のＳＮを示すことができる。その時、長さ（ＬＥＮＧＴＨ）フィールドのサイズはＦＳＮフィールドのサイズに等しい。そのようなものとして、ビットマップのサイズはＦＳＮ値を長さ（ＬＥＮＧＴＨ）値から差し引くことにより計算される。
【００３５】
ビットマップの長さを表現するのに用いられる第３の方法は、ビットマップのサイズを固定して、長さ（ＬＥＮＧＴＨ）フィールドがＳ−ＰＤＵにおいて必要とされないようにすることである。或いは、長さ（ＬＥＮＧＴＨ）フィールドのサイズがゼロにセットされても良い。また、ビットマップがカバーするＳＮに遠隔的に信号を発信するなら、ＦＳＮフィールドのサイズもゼロにセットされても良い。そのような方法を以下に、より詳細に説明する。
【００３６】
とりわけ、従来のデータ圧縮方法が用いられてビットマップフィールドにおける情報を圧縮する。そのようなものとして、通常及び圧縮されたビットマップが１つのＳ−ＰＤＵに含まれる。この場合、圧縮ビットマップについてのタイプフィールドの値は、通常のビットマップに関するものとは異なるであろう。
【００３７】
前述したように、現存するリスト（ＬＩＳＴ）による方法の重大な欠点は、２つのＳＮが各エラーグループに関して必要とされる点である。エラーグループは、Ｄ−ＰＤＵの単一のエラー或いはいくつかの連続するエラーを有している。この代表的な実施形態に従ってリスト（ＬＩＳＴ）による方法を用いてそのような問題を解決するために、ただエラーのＳＮだけがリストされる。言い換えると、新しいリスト（ＬＩＳＴ）タイプが定義され、そこでは単一のエラーだけがリストされる。その結果、結果として得られるＳ−ＰＤＵのサイズは、現存するリストによる解決策と比較して、あるエラーの場合には非常に小さくされる。
【００３８】
この実施形態に従って、Ｓ−ＰＤＵのサイズを小さくするために用いられる別の方法は、現存するリスト（ＬＩＳＴ）による方法（エラーグループ当り２つのＳＮ）と上述した単一のエラーＳＮ リスト（ＬＩＳＴ）方法とを組み合わせてそのリストメッセージを創成することである。例えば、現存するリスト（ＬＩＳＴ）による方法は、長さ（ＬＥＮＧＴＨ）フィールド値を創成する次のような規則を導入することにより大きく改善される。
【００３９】
（１）ゼロ値は単一のエラーＳＮ リスト（ＬＩＳＴ）方法が適用されることを意味する。第２の（新しい）長さフィールドは元々の長さ（ＬＥＮＧＴＨ）フィールドの後に直接に含まれて第２のフィールドの後に直接続く単一のエラーＳＮの数を示す。全てのリスト要素は単一のエラーのＳＮを表現し、確認応答は備えられないが、このリストによる方法を用いる。
【００４０】
（２）奇数の値は、最後のリスト要素が確認応答であることを示唆する。
【００４１】
（３）偶数（ゼロを含む）の値は、最後の要素が確認応答ではないことを示唆する。
その結果、この実施形態に従う上述した規則に続いて、今や、表１の第２行についての（ＬＩＳＴ）Ｓ−ＰＤＵは図５に示されるフィールドと内容とを含む。そのようなものとして、表１に図示された例の第２行に示されるフィールドサイズが、図５によって図示される実施形態に関して用いられるものであるなら、Ｓ−ＰＤＵの全サイズは５９ビットである。その結果、本発明に従えば、結果として得られるＳ−ＰＤＵに必要なビット数は現存するリスト（ＬＩＳＴ）による解決策に必要なビット数（１１４）よりもかなり小さいものである。
【００４２】
図６はリスト（ＬＩＳＴ）による方法を用いてＳ−ＰＤＵのサイズを小さくするために用いられる別の方法を図示する図である。この実施形態に従って用いられる方法は、“最後の”ＳＮでエラーの長さを示す代わりに、各リスト要素の後にエラーの長さを決定するフィールドを含ませることである。たいていのシステムにおいて、長さフィールドのサイズは実質的にＳＮフィールドのサイズよりも小さいであろう。さらにその上、通常はＳ−ＰＤＵにおいて、非常に大きな連続するエラーのＤ−ＰＤＵ（即ち、大きなエラーグループ）を表現する必要はない。
【００４３】
図６において、Ｓ−ＰＤＵにおいて（ＬＩＳＴ’として記されている）新しいメッセージのフィールドが示されている。各ＳＮiの後に導入される新しい長さフィールドは、１≦Ｉ≦ＬＥＮＧＴＨについてＬiと記される。とりわけ、ゼロの値がＬiについて用いられ、さらに結果として得られるＬＩＳＴ’メッセージの機能性を改善している。そのようなものとして、次の代替案が用いられても良い。
【００４４】
（１）Ｌiについてのゼロの値はＳＮiが確認応答である（即ち、Ｌiはエラーを指摘していない）ことを意味する。
【００４５】
（２）ゼロの値はＬＩＳＴ’メッセージの最後を表現する。最初の長さ（ＬＥＮＧＴＨ）フィールドは、もし最後のＳＮの解釈が前もって定義されているならば省略されても良い。例えば、最後のＳＮはつねに確認応答であるように（例えば、第１の代替案として）限定されるか、或いは、（例えば、単一のエラーを指摘するために）その長さは前もって定義される。
【００４６】
本発明の第２の実施形態に従えば、多くの数の異なるメッセージタイプが組み合わされてＳ−ＰＤＵを創成する。これらのメッセージタイプはＳ−ＰＤＵに任意の順序で付加され、Ｓ−ＰＤＵに含まれるメッセージの数や、或いはメッセージのタイプについては規則はない。この代表的な実施形態の場合、そのようなメッセージ各々はタイプ識別子を含み、その長さは固定されるか、或いは各特定のメッセージについて長さフィールドによって示される。第１のタイプの識別子は、結果として得られるＳ−ＰＤＵにおいて前もって定義された位置をもつことが好ましい。そのタイプ識別子の残りは含まれるメッセージのサイズに依存して任意のロケーションに位置する。例えば、メッセージ、ＬＩＳＴ’、ＢＩＴＭＡＰ’及びＡＣＫはＳ−ＰＤＵに含まれても良い。
【００４７】
おそらくＳ−ＰＤＵに含まれるそのようなメッセージの数は、Ｓ−ＰＤＵにおいて用いられるタイプ識別子フィールドのサイズ（ビット）を決定する。例えば、そのようなタイプ識別子フィールドのサイズは次の式によって決定される。
ここで、演算子［ ］はその引数を次に最も大きい整数値に丸める。その引数の“＋１”の部分は、タイプ識別子が用いられＳ−ＰＤＵには他のメッセージが含まれていないことを示すために用いられる。この特別な識別子はここで、“ＮＯ＿ＭＯＲＥ”メッセージとして記されている。そのようなものとして、式（３）に従えば、タイプフィールドのサイズは３つの異なるメッセージに関して２ビットである。なぜなら、［ｌｏｇ2（４）］＝２であるからである。
【００４８】
この実施形態に従って構築される“ＡＣＫ”メッセージの内容は図７に示されている。図示されたＡＣＫメッセージはタイプ識別子とＳＮとを含んでいる。このＡＣＫメッセージはＳ−ＰＤＵの終わりを印しづけ、そして、このＳ−ＰＤＵ内でエラーであることが示されていない全ての前にあるＤ−ＰＤＵはＳＮによって確認応答される。その結果、そのようなＡＣＫメッセージがＳ−ＰＤＵに含まれているとき、組み合わされたＳ−ＰＤＵを終了させるために、ＮＯ＿ＭＯＲＥメッセージを含める必要はない。
【００４９】
確認応答の機能（即ち、Ｌiについてゼロの値をもつことはＳＮiが確認応答であることを意味する）をもったＬＩＳＴ’メッセージが（長さ（ＬＥＮＧＴＨ）フィールドを伴って）用いられることを仮定する。リスト（ＬＩＳＴ’）メッセージの後にビットマップ（ＢＩＴＭＡＰ’）メッセージが直接に含まれるとき、ＦＳＮフィールドのサイズはゼロである。そのようなものとして、ビットマップにおいて表現される最初のＳＮはＳＮLENGTH＋ＬLENGTHである。さらにその上、リスト（ＬＩＳＴ’）メッセージの長さ（ＬＥＮＧＴＨ）フィールドにおけるゼロは付加的な長さ（ＬＥＮＧＴＨ）フィールドが含まれることを意味し、そして、そのメッセージはＬSNiフィールドを伴わずに図５に示されているように構築される。
【００５０】
上述したリスト（ＬＩＳＴ）の特徴を得るための別の方法は、（例えば、“ＬＩＳＴ”と記される）新しいタイプを定義することである。しかしながら、そのタイプフィールドのサイズは影響を受け、その結果、より大きなＳ−ＰＤＵとなる。いずれにしても、上述した組み合わせによる方法のためには従うべき正確な規則を選択することにおいて考慮するトレードオフ（これはシステムに依存するが）がある。
【００５１】
図８は上述した組み合わせによる方法に従ってＳ−ＰＤＵがどのように構築されるのかを図示した図である。示されているように、結果的に生み出されるＳ−ＰＤＵは２つのビットマップ（ＢＩＴＭＡＰ’）メッセージと１つのリスト（ＬＩＳＴ’）とを含む。２番目のビットマップ（ＢＩＴＭＡＰ’）メッセージはＦＳＮフィールドを含まない（或いは、ＦＳＮフィールドのサイズがゼロである）。その結果、ビットマップの最初の要素はＳＮLENGTH＋ＬLENGTHという値をもつＳＮを表現している。
【００５２】
上述した組み合わせによる方法の利点を示すために、表１に関して上述した例にその方法が適用される。そのようなものとして、表２は本発明の第２実施形態に従って、Ｓ−ＰＤＵに含まれる異なるメッセージを（その対応するビット値とともに）示している。この実施形態では、各Ｓ−ＰＤＵは示されているタイプ識別子の１つで始まる。また、長さ（ＬＥＮＧＴＨ）とＬSNiフィールドのサイズは５ビットに固定される。その結果、これらのフィールドは夫々０〜３２（２5）の値を保持できる。とりわけ、そのフィールドのサイズは固定されているが、それらのサイズは、この例のように必ずしも等しくなくとも良い（即ち、ビットマップ（ＢＩＴＭＡＰ’）メッセージにおける長さ（ＬＥＮＧＴＨ）フィールド）のサイズはリスト（ＬＩＳＴ’）メッセージにおける長さ（ＬＥＮＧＴＨ）フィールドのサイズとは異なり得る）。ビットマップ（ＢＩＴＭＡＰ’）メッセージにおける長さ（ＬＥＮＧＴＨ）フィールドの値は、バイト単位でビットマップのサイズに対応している（即ち、最大値で８＊３２＝２５６個のＳＮが単一のＳ−ＰＤＵにおいてアドレス可能である）。ＳＮ値を含む全てのフィールドは１２ビットのサイズをもつ（即ち、ＦＳＮ、ＳＮ、及びＳＳＮフィールド）。
【００５３】
【表２】
【００５４】
図９〜１３は夫々、上述した例について表１に示された各列についてのＳ−ＰＤＵの内容を示す図である。この実施形態では、組み合わせが選択されてＳ−ＰＤＵの全サイズを最小にしている。
【００５５】
表１に関して上述された例によって図示されているように、図９は結果として得られる（組み合わせの）Ｓ−ＰＤＵにおける第１行の内容を示し、図１０は第２行の内容を示し、図１１は第３行の内容を示す。なお、図１１におけるリスト要素ＳＮiの代わりにＡＣＫタイプを含めることによって、Ｓ−ＰＤＵの全サイズに関して付加的な５ビットが節約される。図１２は結果として得られるＳ−ＰＤＵにおける第４行の内容を示し、図１３は第５行の内容を示す。そのようなものとして、全ての符号化されたＳ−ＰＤＵの内容は、“ビット”列からの全ての値を連結することにより得られる。例えば、Ｓ−ＰＤＵ（図９）の第１行の内容は、次のように表される。
【００５６】
“01000010000001100111101111000001100101”。
【００５７】
表３は現存するリスト（ＬＩＳＴ）による方法とビットマップ（ＢＩＴＭＡＰ）による方法と、また、第２実施形態に従う上述した組み合わせによる方法とに従って構築されたＳ−ＰＤＵのサイズを示している。Ｓ−ＰＤＵのサイズは、図９〜１３における“フィールドサイズ”列を加算することによって計算される。表３に図示されているように、本発明の組み合わせによる方法から得られるＳ−ＰＤＵのサイズは、現存する解決策から得られるＳ−ＰＤＵよりもかなり小さい。
【００５８】
【表３】
【００５９】
多くのＡＲＱプロトコルにおいて、Ｄ−ＰＤＵのサイズは前もって定義され、限定されたセットの異なる値をもつことができる。もし、送信側ＡＲＱエンティティに備えられるユーザデータ量がＤ−ＰＤＵのサイズよりも小さいなら、パディングが用いられる。パディングは無意味なデータが用いられてＤ−ＰＤＵの残りの空きロケーションを埋めてしまう技術である。例えば、Ｄ−ＰＤＵが２０バイトのユーザデータでいっぱいになり、送信側のＡＲＱエンティティが１４バイトのユーザデータをもつだけであるなら、Ｄ−ＰＤＵの残りの部分は６バイトのパディングデータで埋められるか、或いはパディングされる。そのユーザデータ部の長さはＤ−ＰＤＵで示される。ＧＰＲＳとＷ−ＣＤＭＡシステムにおけるＲＬＣプロトコルはこの種のパディング機能を用いている。
【００６０】
第２実施形態の組み合わせによる方法はまた、ピギーバッキングとともに効率的に用いられる。例えば、十分な空間がステータスメッセージとともにパディングフィールドを埋めるために存在するならば、ＡＲＱエンティティが最後のユーザデータバイトの終わりの後にステータス情報をピギーバッグ（付加）できる。パディングバイトを含むＤ−ＰＤＵに含まれるステータス情報がないときにはいつでも、ＮＯ＿ＭＯＲＥタイプの識別子が用いられる。このピギーバッキング（付加）方式は、２つのＡＲＱエンティティ間で交換される数多くのパケットをうまく低減させ、その結果、システム容量を節約している。ピギーバッキング（付加）を用いる現存するＡＲＱプロトコルについての場合であるが、ピギーバッキング（付加）方式のためにＤ−ＰＤＵにおいて予約されるフィールドはないので、そのようなピギーバッキング（付加）方式のコストは相対的に小さい。
【００６１】
本発明の方法と装置の実施形態が添付図面において図示され、前述の詳細な説明で説明されたが、本発明はその開示された実施形態に限定されるものではなく、数多くの再構成、変形例、代用が、請求の範囲によって説明され定義されるような本発明の精神を逸脱することなく可能であることが理解されるべきである。
【図面の簡単な説明】
本発明の方法と装置のより完全な理解には添付図面に関連してとられた詳細な説明への参照がなされねばならないが、その図面は以下の通りである。
【図１】 ＡＲＱプロトコルの使用を図示するシーケンス図である。
【図２】 ＳＮを符号化する現存するリストによる方法を用いて受信側によって創成されるＳ−ＰＤＵを示す図である。
【図３】 ＳＮを符号化する現存するビットマップによる方法を用いて受信側によって創成されるＳ−ＰＤＵを示す図である。
【図４】 本発明の第１実施形態に従って構築されたＳ−ＰＤＵに用いられるビットマップメッセージである。
【図５】 本発明の第１実施形態に従って構築された、表１の第２行に関し、ＬＩＳＴ Ｓ−ＰＤＵのフィールドと内容とをもつメッセージの図である。
【図６】 本発明の第１実施形態に従って構築された、Ｓ−ＰＤＵにおけるＬＩＳＴ’メッセージのフィールドの図である。
【図７】 本発明の第２実施形態に従って構築された、“ＡＣＫ”メッセージの内容を示す図である。
【図８】 第２実施形態の組み合わせによる方法に従ってどのようにＳ−ＰＤＵが構築されるのかを描いた図である。
【図９】 本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第１行の内容を示す図である。
【図１０】 本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第２行の内容を示す図である。
【図１１】 本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第３行の内容を示す図である。
【図１２】 本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第４行の内容を示す図である。
【図１３】 本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第５行の内容を示す図である。
関連出願の相互参照
本特許出願は１９９９年４月９日出願の係属中の米国特許仮出願シリアル番号第６０／１２８，５１７号の優先権を主張しており、ここで、その開示全体を参照によって組み込む。
【０００２】
本発明の背景
発明の技術分野
本発明は一般的には通信の分野に関し、特に、例えば、選択的繰り返しＡＲＱプロトコルのような自動再送要求（ＡＲＱ）プロトコルにおけるフィードバック応答を最小化する方法に関する。
【０００３】
関連分野の説明
データが通信ネットワークのノード間で搬送されるとき、一定のアルゴリズムが用いられてエラーデータの伝送やノード間での伝送リンクにおけるデータ損失からの回復を行なう。エラーデータの伝送からの回復に一般に用いられているアルゴリズムは、ＡＲＱプロトコルとして言及される。
【０００４】
現存するＡＲＱプロトコル（即ち、アルゴリズム）は伝送リンクによって互いに通信を行なう２つのピアエンティティを含む。そのようなエンティティ各々は受信側と送信側とを含む。ピアエンティティ間で搬送されるデータユニットは一般にプロトコルデータユニット（ＰＤＵ）として言及される。ＡＲＱプロトコルはＰＤＵを送受信するための一定の規則と共に、ＰＤＵ構造のための規則をも含んでいる。そのようなものとして、“自動再送要求”という名称は、そのプロトコルの基本的な機能を示している。受信側は送信側に伝送中に失われた、或いはエラーが含まれるそれらＰＤＵを再送するように要求する。
【０００５】
受信側は、どのＰＤＵが正しく受信されたのか（即ち、受信側は正しく受信されたＰＤＵを確認応答する）と、どのＰＤＵが正しく受信されなかったのかとの少なくとも１つについて送信側に通知することができる。送信側はこの情報を受信するとき、その“失われた（lost）”ＰＤＵを再送する。言い換えると、ＡＲＱプロトコルは、通信システムにおける送信側と受信側との間の効率的な再送機構の利用を許している規則のセットである。これらの規則は、例えば、ＰＤＵがどのように、またどんな形式で構築されて受信側が搬送されたＰＤＵを正しく解釈してそれらに応答するのかを規定している。
【０００６】
主に３つのタイプの情報要素、ユーザデータ、エラー回復制御データ、及び共通制御データが２つのＡＲＱピアエンティティ間で転送される。これら３つのタイプのＰＤＵが全ての現存するＡＲＱプロトコルにおいて見出される。ユーザデータＰＤＵは少なくともユーザデータとシーケンス番号とを含む。エラー回復制御データＰＤＵは、エラー回復のために必要な種々の制御情報と、肯定及び否定確認応答のような制御機能とを含む。共通制御データＰＤＵは共通制御データを含む。
【０００７】
多くの現存するＡＲＱプロトコルに対する基礎を形造る知られたハイレベルデータリンク制御（ＨＤＬＣ）プロトコルにおいて、３つのタイプのＰＤＵは夫々、情報フレーム（Ｉ−フレーム）、監視フレーム（Ｓ−フレーム）、及び非番号フレーム（Ｕ−フレーム）と呼ばれる。ＨＤＬＣに由来するＡＲＱプロトコルの例は、汎欧州デジタル移動電話方式（ＧＳＭ）で用いられている無線リンクプロトコル（ＲＬＰ）、汎用パケット無線サービス（ＧＰＲＳ）で用いられている無線リンク制御（ＲＬＣ）及び論理リンク制御（ＬＬＣ）、ＩｒＤＡシステムで用いられている赤外線リンクアクセスプロトコル（ＩｒＬＡＰ）、及びＸ．２５システムで用いられているＬＡＰ−Ｂプロトコルである。とりわけ、ユーザデータと少なくともシーケンス番号を含むＰＤＵはここでデータ−ＰＤＵ（Ｄ−ＰＤＵ）として示され、エラー制御／回復のために必要な制御データを含むＰＤＵはここでステータス−ＰＤＵ（Ｓ−ＰＤＵ）として示される。
【０００８】
たいていの通信システムにおいて、ユーザデータ情報がピアエンティティ間で両方向に搬送される。ＡＲＱプロトコルに含まれる共通の特徴は、ユーザデータＰＤＵにエラー制御情報を含むという可能性である。この能力は、“ピギーバックキング（piggybacking）”として知られている。例えば、ＨＤＬＣに由来するプロトコルの全てのＩ−フレーム（即ち、Ｄ−ＰＤＵ）には確認応答が含まれる。その確認応答は最後に（順番に並んで）正しく受信されたＰＤＵのシーケンス番号についてピアエンティティに通知する。
【０００９】
最も一般的な現存するＡＲＱプロトコルは１つ以上の機構、例えば、ストップ−アンド−ウェイト（Stop-and-Wait）ＡＲＱ、ゴー−バック−Ｎ（Go-back-N）ＡＲＱ、及び選択的繰り返しＡＲＱを実施して伝送リンクにおけるエラーからの回復を行なう。これらの機構とＡＲＱの利用は一般によく知られている。
【００１０】
図１はＡＲＱプロトコルの使用を図示したシーケンス図である。図示されているように、２つのＡＲＱピアエンティティ１０、１２は互いに通信している。図１における矢は２つのエンティティ間のＰＤＵの送信を示し、各ＰＤＵの内容は各矢の上に直接説明されている。図１において、送信されるＤ−ＰＤＵとＳ−ＰＤＵとのシーケンスが示されている。Ｄ−ＰＤＵは、ユーザデータと、シーケンス番号（ＳＮ）と、おそらくピギーバック（付加）されたエラー制御情報とを含む。Ｓ−ＰＤＵはステータス情報を含むがユーザ情報は含まない。シーケンス番号（ＳＮ＝ｘ）はＤ−ＰＤＵと関連しておりその特定のＤ−ＰＤＵを識別する。確認応答（ＡＣＫ＝ｘ）はＳＮ＜ｘであるいずれかのＰＤＵを確認応答するために用いられる。否定確認応答（ＮＡＫ＝ｘ）は正しく受信されなかった（ＳＮ＝ｘである）ＰＤＵを確認応答するために用いられる。
【００１１】
２つのタイプのエラー制御フィードバック応答が図１に示されている。フィードバック応答の１つ（例えば、Ｓ−ＰＤＵ、ＡＣＫ＝２）１４について、第２のＡＲＱピアエンティティ１２は、それがＳＮ＝０とＳＮ＝１のＰＤＵを受信したことを確認応答する。第２のタイプのフィードバック応答（例えば、Ｓ−ＰＤＵ、ＮＡＫ＝３）１６について、第２のピアエンティティ１２はＳＮ＝３であるＰＤＵが改悪されており、第１のピアエンティティ１０によって再送されるべきであることを示す。
【００１２】
上述のように、Ｓ−ＰＤＵはピアエンティティ間で送信される特別なＰＤＵである。Ｓ−ＰＤＵは改悪されたＰＤＵのＳＮについての情報を含む。２つの主要な方法が現在、Ｓ−ＰＤＵ内のＳＮを符号化するのに用いられている。１つのそのような方法は、再送されるＳＮのリストを用いることである。２番目の方法は、再送されるＳＮを表現するビットマップを用いることである。そのようなものとして、ＳＮを表現することとは別に、Ｓ−ＰＤＵはまた、異なるＰＤＵフォーマット間（例えば、Ｄ−ＰＤＵとＳ−ＰＤＵ）を区別するために受信側によって用いられるフォーマット識別子を含んでいる。
【００１３】
ＳＮを符号化するために用いられるリストによる方法は、Ｓ−ＰＤＵにおけるエラーのＰＤＵのＳＮを含んでいる。もし、そのリストの長さが前もって定義されておらず、それによって知られるのであれば、この長さ情報はＳ−ＰＤＵにおいて示される。例えば、長さフィールドはＳ−ＰＤＵに含まれる。図２はＳＮを符号化するためのリストによる方法を用いて受信側によって創成されるそのようなＳ−ＰＤＵを示している。
【００１４】
図２において、もし、送信側がＳＮ＝０〜１５のＤ−ＰＤＵのシーケンスを送信し、ＳＮ＝３，５，６，７，８のＰＤＵが（正しく受信されず）損失したなら、受信側は示された内容をもつＳ−ＰＤＵを創成できる。例えば、リスト（長さフィールドの後の）にある最初の２つの要素がＳＮ＝３のＤ−ＰＤＵがエラーであったことを示す。そのリストにある３番目と４番目の要素は、ＳＮ＝５〜８のＤ−ＰＤＵがエラーであったことを示す。最後の要素は残りのＰＤＵ（最大で１５のＳＮ）を確認応答するために含まれている。
【００１５】
Ｓ−ＰＤＵのサイズは、ＰＤＵフォーマット識別子フィールド、長さフィールド、及びＳＮフィールドを表現するために用いられるビット数に依存している。そのようなものとして、Ｓ−ＰＤＵのサイズは以下の式によって計算される。
【００１６】
図３はＳＮを符号化するためのビットマップによる方法を用いた送信側によって創成されるＳ−ＰＤＵを示している。ＳＮを示すためにビットマップが用いられるとき、受信側は順番に正しく受信した最後のＤ−ＰＤＵのＳＮとビットマップからＳ−ＰＤＵを創成する。このＳＮはスタートＳＮ（ＳＳＮ）として言及される。その結果、このＳ−ＰＤＵは暗に最大でＳＳＮの数までの全ての受信したＤ−ＰＤＵに確認応答している。ビットマップでの各ロケーションは、ＳＳＮに相対的に特定のＳ−ＰＤＵをアドレスするために用いられる。通常、ビットマップのサイズはＡＲＱ受信側のウィンドウのサイズに固定され、明示的に示されねばならないことはない。もし、そのビットマップが固定されないなら、その長さは示されねばならない。
【００１７】
図３に示されるビットマップは、図２に関して上述された例から創成されたＳ−ＰＤＵとウィンドウサイズが１６であることを示している。そのようなものとして、ビットマップの各ロケーションは２つの値、即ち、０或いは１のいずれか１つをもつことができる。“１”はＳＮ＝（ＳＳＮ＋bit_position）が正しく受信されたことを意味し、“０”はＳＮ＝（ＳＳＮ＋bit_position）が正しく受信されなかったことを意味する。もちろん、“０”と“１”の意味は互いに交換可能である。そのようなビットマップを用いるときＳ−ＰＤＵのサイズは次の式から生じる。
【００１８】
現存するＡＲＱプロトコルのもつ重大な問題は、そのプロトコルが構成において静的（例えば、固定長メッセージが用いられる）である点である。ある状態の場合、このやり方はバンド幅資源の浪費につながる。なぜなら、多大な量のオーバヘッド情報が不必要に送信されるからである。例えば、そのような状態は２つのＡＲＱピアエンティティ間で送信される多くの数のＤ−ＰＤＵをもつシステムにおいて発生し、これらＤ−ＰＤＵは確認応答され、再送のために選択的に要求されねばならない。あるエラー制御の場合には、現存する解決策は多大な量の不必要なオーバヘッドを導き込むことになる。次の例はそのような状態を表している。
【００１９】
現在、所謂第３世代のセルラ通信システムのために標準化されている広帯域符号分割多元接続（ＷＣＤＭＡ）システムにおいて、用いられる１つのＡＲＱプロトコルは、ＲＬＣプロトコルである。そのＳＮセットは０〜４０９５の値を含み、それは各ＳＮが１２ビットで符号化されることを意味している。高速データ伝送では、相対的に大きなセットのＳＮがいくつかのＳ−ＰＤＵにおいてアドレスされねばならないという仮定がなされる。また、１００個のＤ−ＰＤＵ（ＳＮ＝１〜１００）のステータスが、Ｓ−ＰＤＵにおけるＲＬＣピアエンティティ間で通信される必要があることを仮定する。
【００２０】
以下の表１は、上述したリストによる、また、ビットマップによる方法を用いてＳ−ＰＤＵを符号化するために必要なビット数を示している。異なるエラー環境が備えられて、２つの方法について必要なビット数の大きな違いを強調している。次の要素サイズが用いられることを仮定する。即ち、ビットマップ＝１２８ビット、長さ＝５ビット、１ＰＤＵフォーマット識別子＝１ビット（Ｄ−ＰＤＵとＳ−ＰＤＵとを区別するために）である。そのようなものとして、表１に示される異なるＳ−ＰＤＵサイズが、上述した式（１）と（２）とに従って、夫々計算される。表１の第２〜５行で図示されているように、現存する解決策の両方とも、示されたエラー環境に対して効率的に小さなＳ−ＰＤＵを構築する点で問題をもっている。リスト（ＬＩＳＴ）の長さはエラーのＤ−ＰＤＵの数にはそれほど依存してはいないが、むしろ、用いられるウィンドウ内のエラーの分布に依存している。この事実は表１の第１行と第２行とを比較することにより明白になる。
【００２１】
【表１】
解決されるべき問題を一般的な言い方をすれば、メッセージにおいて、任意の量のステータスとｍの数のセットからｎの数の分布とを効率的に表現する（符号化する）仕方を決定することである。そのようなものとして、ＡＲＱプロトコルにおいてＳ−ＰＤＵのサイズを最小化するために用いられる方法について、大きな必要がある。また、もし、全ての可能性のあるＳＮを単一のＳ−ＰＤＵへと合わせることが可能でないなら、限定されたサイズをもつＳ−ＰＤＵにおいてＳＮの数を最大化するために用いられる方法についても、大きな必要がある。以下に詳細に説明するように、本発明は首尾よく上述した問題と他の関連する問題とを解決している。
【００２３】
発 明 の 要 約
本発明の実施形態に従えば、ＡＲＱプロトコルにおけるフィードバック応答を最小化する方法が備えられ、そこでは異なる機構が用いられてエラーのＤ−ＰＤＵを示し、Ｓ−ＰＤＵを構築する。特に、これらの異なる機構が単一のＳ−ＰＤＵへと組み合わせられる。Ｓ−ＰＤＵはある基準に従ってシステム性能を最適化するために構築される。そのような用いられる基準の１つはＳ−ＰＤＵのサイズを最小化することである。そのような用いられる基準の２つ目は制限されたＳ−ＰＤＵに含まれるＳＮの数を最大化することである。
【００２４】
本発明の重要な技術的利点は、無線インタフェースのバンド幅の資源が節約されることである。
【００２５】
本発明の重要な別の技術的利点は、プロトコルのオーバヘッドが最小化されることである。
【００２６】
本発明の重要なさらに別の技術的利点は、システム能力が向上することである。
【００２７】
本発明の重要なさらに別の技術的利点は、選択的繰り返しＡＲＱプロトコルにおけるフィードバック応答の数が最小化されることである。
【００２８】
図 面 の 詳 細 な 説 明
本発明の好適な実施形態とその利点は、図面の図１〜１３を参照することによって最善の理解が得られる。種々の図面で同様のまた対応する部分については同じ番号が用いられている。
【００２９】
本質的には、本発明の第１実施形態に従って、ＡＲＱプロトコルにおけるフィードバック応答を最小化する方法が備えられ、そこでは異なる機構が用いられてエラーのＤ−ＰＤＵを示し、Ｓ−ＰＤＵを構築する。特に、これらの異なる機構が単一のＳ−ＰＤＵへと組み合わせられる。Ｓ−ＰＤＵはある基準に従ってシステム性能を最適化するために構築される。そのような用いられる基準の１つはＳ−ＰＤＵのサイズを最小化することである。そのような用いられる基準の２つ目は制限されたＳ−ＰＤＵに含まれるＳＮの数を最大化することである。
【００３０】
これ以後具体的に、説明される基本的な構成要素はメッセージである。この実施形態では、そのようなメッセージは、タイプ（Type）、長さ（Length）、値（Value）（ＴＬＶ）シンタックスを用いて説明される。言い換えると、そのようなメッセージは３つのフィールドを含む。１つのフィールドはタイプの情報を含み、２番目のフィールドは長さの情報を含み、３番目のフィールドは値の情報を含む。タイプのフィールドのサイズはゼロでないことが好ましいが、他の２つのフィールドのサイズはゼロでも良い。
【００３１】
とりわけ、前述したように、全ての現存するビットマップの解は、構築されたＳ−ＰＤＵにおける順番に並ぶＤ−ＰＤＵの最後に受信されたもののシーケンス番号（ここでは、ＳＳＮと呼ばれる）についての情報を含んでいる。そのＳＳＮはそのシーケンス番号に前にはエラーが存在しないことを示している。言い換えると、ＳＳＮは最大でそのＳＳＮのＳＮまでのＳＮを有する全てのＤ−ＰＤＵを確認応答するために用いられる。
【００３２】
この代表的な実施形態について、ＡＲＱプロトコルにおけるフィードバック応答を最小化するために用いられる基本的なメッセージが次のように構築される。この実施形態ではビットマップ（ＢＩＴＭＡＰ）による方法を用いて、構築されたＳ−ＰＤＵに含まれるＳＮは、ＳＮのセットの中のいずれかの（必ずしも第１である必要はない）エラーのＤ−ＰＤＵのＳＮを示している。これに続くＳＮのステータスはビットマップにおいて示される。最初のエラーのＤ−ＰＤＵのＳＮがこの代表的な実施形態において用いられているが、ビットマップによる方法では、その代わりにいずれかのＤ−ＰＤＵ（ＳＮセットから）が用いられても良いことを理解すべきである。その場合、ビットマップはまた、構築されたＳ−ＰＤＵに含まれるＳＮのステータス（０或いは１）を含まねばならない。そのようなものとして、“ビットマップ（ＢＩＴＭＡＰ）”メッセージは、タイプ識別子フィールド、第１のＳＮ（ＦＳＮ）フィールド、ビットマップ長フィールド、及びビットマップフィールドを備えて創成される。図４は、本発明の第１実施形態に従ってＳ−ＰＤＵで用いられるそのようなフィールドを備えたビットマップメッセージを図示している。
【００３３】
図４に示されるビットマップメッセージにおいて、多くの数の方法が用いられてビットマップの長さ（長さ（ＬＥＮＧＴＨ）フィールド）を表現する。１つの方法では、前もって定義された数のビットが用いられて基本的なデータユニットにおけるビットマップのサイズを表現する。そのようなデータユニットは均一的なものである必要はなく、例えば、１つ以上のビット、バイト、ワードなどを含むことができる。例えば、バイトが基本データユニットとして用いられるなら、長さ（ＬＥＮＧＴＨ）フィールドにおける値ｘは、８*ｘＳＮｓがビットマップによってカバーされることを意味している。この結果得られた値はまた、ビットマップのサイズをビットで表現している。
【００３４】
ビットマップの長さを表現するのに用いられる第２の方法では、異なるＳＮが用いられてビットマップによってカバーされる最後のＳＮを示すことができる。その時、長さ（ＬＥＮＧＴＨ）フィールドのサイズはＦＳＮフィールドのサイズに等しい。そのようなものとして、ビットマップのサイズはＦＳＮ値を長さ（ＬＥＮＧＴＨ）値から差し引くことにより計算される。
【００３５】
ビットマップの長さを表現するのに用いられる第３の方法は、ビットマップのサイズを固定して、長さ（ＬＥＮＧＴＨ）フィールドがＳ−ＰＤＵにおいて必要とされないようにすることである。或いは、長さ（ＬＥＮＧＴＨ）フィールドのサイズがゼロにセットされても良い。また、ビットマップがカバーするＳＮに遠隔的に信号を発信するなら、ＦＳＮフィールドのサイズもゼロにセットされても良い。そのような方法を以下に、より詳細に説明する。
【００３６】
とりわけ、従来のデータ圧縮方法が用いられてビットマップフィールドにおける情報を圧縮する。そのようなものとして、通常及び圧縮されたビットマップが１つのＳ−ＰＤＵに含まれる。この場合、圧縮ビットマップについてのタイプフィールドの値は、通常のビットマップに関するものとは異なるであろう。
【００３７】
前述したように、現存するリスト（ＬＩＳＴ）による方法の重大な欠点は、２つのＳＮが各エラーグループに関して必要とされる点である。エラーグループは、Ｄ−ＰＤＵの単一のエラー或いはいくつかの連続するエラーを有している。この代表的な実施形態に従ってリスト（ＬＩＳＴ）による方法を用いてそのような問題を解決するために、ただエラーのＳＮだけがリストされる。言い換えると、新しいリスト（ＬＩＳＴ）タイプが定義され、そこでは単一のエラーだけがリストされる。その結果、結果として得られるＳ−ＰＤＵのサイズは、現存するリストによる解決策と比較して、あるエラーの場合には非常に小さくされる。
【００３８】
この実施形態に従って、Ｓ−ＰＤＵのサイズを小さくするために用いられる別の方法は、現存するリスト（ＬＩＳＴ）による方法（エラーグループ当り２つのＳＮ）と上述した単一のエラーＳＮ リスト（ＬＩＳＴ）方法とを組み合わせてそのリストメッセージを創成することである。例えば、現存するリスト（ＬＩＳＴ）による方法は、長さ（ＬＥＮＧＴＨ）フィールド値を創成する次のような規則を導入することにより大きく改善される。
【００３９】
（１）ゼロ値は単一のエラーＳＮ リスト（ＬＩＳＴ）方法が適用されることを意味する。第２の（新しい）長さフィールドは元々の長さ（ＬＥＮＧＴＨ）フィールドの後に直接に含まれて第２のフィールドの後に直接続く単一のエラーＳＮの数を示す。全てのリスト要素は単一のエラーのＳＮを表現し、確認応答は備えられないが、このリストによる方法を用いる。
【００４０】
（２）奇数の値は、最後のリスト要素が確認応答であることを示唆する。
【００４１】
（３）偶数（ゼロを含む）の値は、最後の要素が確認応答ではないことを示唆する。
その結果、この実施形態に従う上述した規則に続いて、今や、表１の第２行についての（ＬＩＳＴ）Ｓ−ＰＤＵは図５に示されるフィールドと内容とを含む。そのようなものとして、表１に図示された例の第２行に示されるフィールドサイズが、図５によって図示される実施形態に関して用いられるものであるなら、Ｓ−ＰＤＵの全サイズは５９ビットである。その結果、本発明に従えば、結果として得られるＳ−ＰＤＵに必要なビット数は現存するリスト（ＬＩＳＴ）による解決策に必要なビット数（１１４）よりもかなり小さいものである。
【００４２】
図６はリスト（ＬＩＳＴ）による方法を用いてＳ−ＰＤＵのサイズを小さくするために用いられる別の方法を図示する図である。この実施形態に従って用いられる方法は、“最後の”ＳＮでエラーの長さを示す代わりに、各リスト要素の後にエラーの長さを決定するフィールドを含ませることである。たいていのシステムにおいて、長さフィールドのサイズは実質的にＳＮフィールドのサイズよりも小さいであろう。さらにその上、通常はＳ−ＰＤＵにおいて、非常に大きな連続するエラーのＤ−ＰＤＵ（即ち、大きなエラーグループ）を表現する必要はない。
【００４３】
図６において、Ｓ−ＰＤＵにおいて（ＬＩＳＴ’として記されている）新しいメッセージのフィールドが示されている。各ＳＮiの後に導入される新しい長さフィールドは、１≦Ｉ≦ＬＥＮＧＴＨについてＬiと記される。とりわけ、ゼロの値がＬiについて用いられ、さらに結果として得られるＬＩＳＴ’メッセージの機能性を改善している。そのようなものとして、次の代替案が用いられても良い。
【００４４】
（１）Ｌiについてのゼロの値はＳＮiが確認応答である（即ち、Ｌiはエラーを指摘していない）ことを意味する。
【００４５】
（２）ゼロの値はＬＩＳＴ’メッセージの最後を表現する。最初の長さ（ＬＥＮＧＴＨ）フィールドは、もし最後のＳＮの解釈が前もって定義されているならば省略されても良い。例えば、最後のＳＮはつねに確認応答であるように（例えば、第１の代替案として）限定されるか、或いは、（例えば、単一のエラーを指摘するために）その長さは前もって定義される。
【００４６】
本発明の第２の実施形態に従えば、多くの数の異なるメッセージタイプが組み合わされてＳ−ＰＤＵを創成する。これらのメッセージタイプはＳ−ＰＤＵに任意の順序で付加され、Ｓ−ＰＤＵに含まれるメッセージの数や、或いはメッセージのタイプについては規則はない。この代表的な実施形態の場合、そのようなメッセージ各々はタイプ識別子を含み、その長さは固定されるか、或いは各特定のメッセージについて長さフィールドによって示される。第１のタイプの識別子は、結果として得られるＳ−ＰＤＵにおいて前もって定義された位置をもつことが好ましい。そのタイプ識別子の残りは含まれるメッセージのサイズに依存して任意のロケーションに位置する。例えば、メッセージ、ＬＩＳＴ’、ＢＩＴＭＡＰ’及びＡＣＫはＳ−ＰＤＵに含まれても良い。
【００４７】
おそらくＳ−ＰＤＵに含まれるそのようなメッセージの数は、Ｓ−ＰＤＵにおいて用いられるタイプ識別子フィールドのサイズ（ビット）を決定する。例えば、そのようなタイプ識別子フィールドのサイズは次の式によって決定される。
【００４８】
この実施形態に従って構築される“ＡＣＫ”メッセージの内容は図７に示されている。図示されたＡＣＫメッセージはタイプ識別子とＳＮとを含んでいる。このＡＣＫメッセージはＳ−ＰＤＵの終わりを印しづけ、そして、このＳ−ＰＤＵ内でエラーであることが示されていない全ての前にあるＤ−ＰＤＵはＳＮによって確認応答される。その結果、そのようなＡＣＫメッセージがＳ−ＰＤＵに含まれているとき、組み合わされたＳ−ＰＤＵを終了させるために、ＮＯ＿ＭＯＲＥメッセージを含める必要はない。
【００４９】
確認応答の機能（即ち、Ｌiについてゼロの値をもつことはＳＮiが確認応答であることを意味する）をもったＬＩＳＴ’メッセージが（長さ（ＬＥＮＧＴＨ）フィールドを伴って）用いられることを仮定する。リスト（ＬＩＳＴ’）メッセージの後にビットマップ（ＢＩＴＭＡＰ’）メッセージが直接に含まれるとき、ＦＳＮフィールドのサイズはゼロである。そのようなものとして、ビットマップにおいて表現される最初のＳＮはＳＮLENGTH＋ＬLENGTHである。さらにその上、リスト（ＬＩＳＴ’）メッセージの長さ（ＬＥＮＧＴＨ）フィールドにおけるゼロは付加的な長さ（ＬＥＮＧＴＨ）フィールドが含まれることを意味し、そして、そのメッセージはＬSNiフィールドを伴わずに図５に示されているように構築される。
【００５０】
上述したリスト（ＬＩＳＴ）の特徴を得るための別の方法は、（例えば、“ＬＩＳＴ”と記される）新しいタイプを定義することである。しかしながら、そのタイプフィールドのサイズは影響を受け、その結果、より大きなＳ−ＰＤＵとなる。いずれにしても、上述した組み合わせによる方法のためには従うべき正確な規則を選択することにおいて考慮するトレードオフ（これはシステムに依存するが）がある。
【００５１】
図８は上述した組み合わせによる方法に従ってＳ−ＰＤＵがどのように構築されるのかを図示した図である。示されているように、結果的に生み出されるＳ−ＰＤＵは２つのビットマップ（ＢＩＴＭＡＰ’）メッセージと１つのリスト（ＬＩＳＴ’）とを含む。２番目のビットマップ（ＢＩＴＭＡＰ’）メッセージはＦＳＮフィールドを含まない（或いは、ＦＳＮフィールドのサイズがゼロである）。その結果、ビットマップの最初の要素はＳＮLENGTH＋ＬLENGTHという値をもつＳＮを表現している。
【００５２】
上述した組み合わせによる方法の利点を示すために、表１に関して上述した例にその方法が適用される。そのようなものとして、表２は本発明の第２実施形態に従って、Ｓ−ＰＤＵに含まれる異なるメッセージを（その対応するビット値とともに）示している。この実施形態では、各Ｓ−ＰＤＵは示されているタイプ識別子の１つで始まる。また、長さ（ＬＥＮＧＴＨ）とＬSNiフィールドのサイズは５ビットに固定される。その結果、これらのフィールドは夫々０〜３２（２5）の値を保持できる。とりわけ、そのフィールドのサイズは固定されているが、それらのサイズは、この例のように必ずしも等しくなくとも良い（即ち、ビットマップ（ＢＩＴＭＡＰ’）メッセージにおける長さ（ＬＥＮＧＴＨ）フィールド）のサイズはリスト（ＬＩＳＴ’）メッセージにおける長さ（ＬＥＮＧＴＨ）フィールドのサイズとは異なり得る）。ビットマップ（ＢＩＴＭＡＰ’）メッセージにおける長さ（ＬＥＮＧＴＨ）フィールドの値は、バイト単位でビットマップのサイズに対応している（即ち、最大値で８＊３２＝２５６個のＳＮが単一のＳ−ＰＤＵにおいてアドレス可能である）。ＳＮ値を含む全てのフィールドは１２ビットのサイズをもつ（即ち、ＦＳＮ、ＳＮ、及びＳＳＮフィールド）。
【００５３】
【表２】
図９〜１３は夫々、上述した例について表１に示された各列についてのＳ−ＰＤＵの内容を示す図である。この実施形態では、組み合わせが選択されてＳ−ＰＤＵの全サイズを最小にしている。
【００５５】
表１に関して上述された例によって図示されているように、図９は結果として得られる（組み合わせの）Ｓ−ＰＤＵにおける第１行の内容を示し、図１０は第２行の内容を示し、図１１は第３行の内容を示す。なお、図１１におけるリスト要素ＳＮiの代わりにＡＣＫタイプを含めることによって、Ｓ−ＰＤＵの全サイズに関して付加的な５ビットが節約される。図１２は結果として得られるＳ−ＰＤＵにおける第４行の内容を示し、図１３は第５行の内容を示す。そのようなものとして、全ての符号化されたＳ−ＰＤＵの内容は、“ビット”列からの全ての値を連結することにより得られる。例えば、Ｓ−ＰＤＵ（図９）の第１行の内容は、次のように表される。
【００５６】
“01000010000001100111101111000001100101”。
【００５７】
表３は現存するリスト（ＬＩＳＴ）による方法とビットマップ（ＢＩＴＭＡＰ）による方法と、また、第２実施形態に従う上述した組み合わせによる方法とに従って構築されたＳ−ＰＤＵのサイズを示している。Ｓ−ＰＤＵのサイズは、図９〜１３における“フィールドサイズ”列を加算することによって計算される。表３に図示されているように、本発明の組み合わせによる方法から得られるＳ−ＰＤＵのサイズは、現存する解決策から得られるＳ−ＰＤＵよりもかなり小さい。
【００５８】
【表３】
多くのＡＲＱプロトコルにおいて、Ｄ−ＰＤＵのサイズは前もって定義され、限定されたセットの異なる値をもつことができる。もし、送信側ＡＲＱエンティティに備えられるユーザデータ量がＤ−ＰＤＵのサイズよりも小さいなら、パディングが用いられる。パディングは無意味なデータが用いられてＤ−ＰＤＵの残りの空きロケーションを埋めてしまう技術である。例えば、Ｄ−ＰＤＵが２０バイトのユーザデータでいっぱいになり、送信側のＡＲＱエンティティが１４バイトのユーザデータをもつだけであるなら、Ｄ−ＰＤＵの残りの部分は６バイトのパディングデータで埋められるか、或いはパディングされる。そのユーザデータ部の長さはＤ−ＰＤＵで示される。ＧＰＲＳとＷ−ＣＤＭＡシステムにおけるＲＬＣプロトコルはこの種のパディング機能を用いている。
【００６０】
第２実施形態の組み合わせによる方法はまた、ピギーバッキングとともに効率的に用いられる。例えば、十分な空間がステータスメッセージとともにパディングフィールドを埋めるために存在するならば、ＡＲＱエンティティが最後のユーザデータバイトの終わりの後にステータス情報をピギーバッグ（付加）できる。パディングバイトを含むＤ−ＰＤＵに含まれるステータス情報がないときにはいつでも、ＮＯ＿ＭＯＲＥタイプの識別子が用いられる。このピギーバッキング（付加）方式は、２つのＡＲＱエンティティ間で交換される数多くのパケットをうまく低減させ、その結果、システム容量を節約している。ピギーバッキング（付加）を用いる現存するＡＲＱプロトコルについての場合であるが、ピギーバッキング（付加）方式のためにＤ−ＰＤＵにおいて予約されるフィールドはないので、そのようなピギーバッキング（付加）方式のコストは相対的に小さい。
【００６１】
本発明の方法と装置の実施形態が添付図面において図示され、前述の詳細な説明で説明されたが、本発明はその開示された実施形態に限定されるものではなく、数多くの再構成、変形例、代用が、請求の範囲によって説明され定義されるような本発明の精神を逸脱することなく可能であることが理解されるべきである。
【図面の簡単な説明】
本発明の方法と装置のより完全な理解には添付図面に関連してとられた詳細な説明への参照がなされねばならないが、その図面は以下の通りである。
【図１】 ＡＲＱプロトコルの使用を図示するシーケンス図である。
【図２】 ＳＮを符号化する現存するリストによる方法を用いて受信側によって創成されるＳ−ＰＤＵを示す図である。
【図３】 ＳＮを符号化する現存するビットマップによる方法を用いて受信側によって創成されるＳ−ＰＤＵを示す図である。
【図４】 本発明の第１実施形態に従って構築されたＳ−ＰＤＵに用いられるビットマップメッセージである。
【図５】 本発明の第１実施形態に従って構築された、表１の第２行に関し、ＬＩＳＴ Ｓ−ＰＤＵのフィールドと内容とをもつメッセージの図である。
【図６】 本発明の第１実施形態に従って構築された、Ｓ−ＰＤＵにおけるＬＩＳＴ’メッセージのフィールドの図である。
【図７】 本発明の第２実施形態に従って構築された、“ＡＣＫ”メッセージの内容を示す図である。
【図８】 第２実施形態の組み合わせによる方法に従ってどのようにＳ−ＰＤＵが構築されるのかを描いた図である。
【図９】 本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第１行の内容を示す図である。
【図１０】 本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第２行の内容を示す図である。
【図１１】 本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第３行の内容を示す図である。
【図１２】 本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第４行の内容を示す図である。
【図１３】 本発明の第２実施形態に従って構築された、Ｓ−ＰＤＵの組み合わせにおける表１の第５行の内容を示す図である。
Claims (8)
- ＡＲＱプロトコルにおけるフィードバック応答を最小化する方法であって、
通信リンクによって複数の第１のデータユニットを送信する工程と、
前記複数の第１のデータユニットを受信する工程と、
前記受信する工程に応答して、データ送信側に返信される第２のデータユニットについてのメッセージフィールドを構築する工程とを有し、
前記メッセージフィールドはタイプ識別子フィールドと、そして、シーケンス番号フィールド、長さフィールド、及び内容フィールドの内の少なくとも１つとを含み、
ビットマップが前記タイプ識別子フィールドにセットされるなら、前記内容フィールドは前記受信された複数の第１のデータユニットの内のエラーがあるデータユニットのシーケンス番号を示すビットマップを含み、前記長さフィールドは前記ビットマップのサイズを示し、
リストが前記タイプ識別子フィールドにセットされるなら、前記シーケンス番号フィールドの値と前記長さフィールドの値との組み合わせが前記受信された複数の第１のデータユニットの内のエラーがあるデータユニットのシーケンス番号を示し、
少なくとも１つのビットマップタイプのメッセージと少なくとも１つのリストタイプのメッセージとを含む異なったタイプのメッセージフィールドが組み合わされて前記第２のデータユニットを形成するとき、前記異なったタイプのメッセージフィールドは任意の順序で付加されることを特徴とする方法。 - 前記複数の第１のデータユニットは、ユーザデータを含む複数のＡＲＱプロトコルユニットを有することを特徴とする請求項１に記載の方法。
- 前記長さフィールドのサイズはゼロであり、前もって定義されるビットマップサイズが用いられることを特徴とする請求項１に記載の方法。
- 前記長さフィールドは、前記ビットマップにおける最後のシーケンス番号を示すことを特徴とする請求項１に記載の方法。
- 前記長さフィールドは、ゼロの値を有することを特徴とする請求項１に記載の方法。
- 前記シーケンス番号フィールドのサイズは、ゼロに等しいことを特徴とする請求項１に記載の方法。
- 前記複数の第１のデータユニットの少なくとも１つは、前記メッセージフィールドを付加するために用いられることを特徴とする請求項１に記載の方法。
- 前記ＡＲＱプロトコルは、選択的繰り返しＡＲＱプロトコルを有することを特徴とする請求項１に記載の方法。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US12851799P | 1999-04-09 | 1999-04-09 | |
| US60/128,517 | 1999-04-09 | ||
| US09/537,146 US6772215B1 (en) | 1999-04-09 | 2000-03-29 | Method for minimizing feedback responses in ARQ protocols |
| US09/537,146 | 2000-03-29 | ||
| PCT/SE2000/000677 WO2000062466A2 (en) | 1999-04-09 | 2000-04-07 | Method for minimizing feedback responses in arq protocols |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002542661A JP2002542661A (ja) | 2002-12-10 |
| JP4579421B2 true JP4579421B2 (ja) | 2010-11-10 |
Family
ID=26826665
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000611424A Expired - Lifetime JP4579421B2 (ja) | 1999-04-09 | 2000-04-07 | Ａｒｑプロトコルにおけるフィードバック応答を最小化する方法 |
Country Status (11)
| Country | Link |
|---|---|
| US (1) | US6772215B1 (ja) |
| EP (1) | EP1169803A2 (ja) |
| JP (1) | JP4579421B2 (ja) |
| KR (1) | KR20020013845A (ja) |
| CN (1) | CN100359839C (ja) |
| AR (1) | AR025836A1 (ja) |
| AU (1) | AU764613B2 (ja) |
| BR (1) | BRPI0009680B1 (ja) |
| CA (1) | CA2369642C (ja) |
| MY (1) | MY125271A (ja) |
| WO (1) | WO2000062466A2 (ja) |
Families Citing this family (58)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6131047A (en) | 1997-12-30 | 2000-10-10 | Ericsson Inc. | Radiotelephones having contact-sensitive user interfaces and methods of operating same |
| KR100424654B1 (ko) * | 1999-08-02 | 2004-03-24 | 삼성전자주식회사 | 이동 통신시스템에서 라디오링크프로토콜에 따른 데이터 재전송 장치 및 방법 |
| US6996100B1 (en) * | 2000-02-03 | 2006-02-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system for medium access on a radio channel |
| US7050402B2 (en) * | 2000-06-09 | 2006-05-23 | Texas Instruments Incorporated | Wireless communications with frequency band selection |
| DE10054473A1 (de) * | 2000-11-03 | 2002-05-08 | Siemens Ag | Verfahren zum Austausch von Datenpaketen zwischen zwei Diensteerbringern eines Funkübertragungssystems |
| RU2292656C2 (ru) * | 2001-08-21 | 2007-01-27 | Роук Мэнор Рисерч Лимитед | Способ подтверждения приема данных |
| GB2384145A (en) * | 2002-01-12 | 2003-07-16 | Ubinetics Ltd | Adaptive signalling technique for repeat transmission requests |
| KR100934650B1 (ko) * | 2002-10-02 | 2009-12-31 | 엘지전자 주식회사 | 하이브리드 자동재송요구 시스템에서 패킷 송/수신 방법 |
| JP2004187099A (ja) * | 2002-12-04 | 2004-07-02 | Shinko Electric Ind Co Ltd | 通信制御方法、通信システム及び通信装置 |
| US7443845B2 (en) * | 2002-12-06 | 2008-10-28 | Cisco Technology, Inc. | Apparatus and method for a lightweight, reliable, packet-based transport protocol |
| US7475142B2 (en) * | 2002-12-06 | 2009-01-06 | Cisco Technology, Inc. | CIFS for scalable NAS architecture |
| KR100542090B1 (ko) | 2002-12-16 | 2006-01-11 | 한국전자통신연구원 | 무선 통신 시스템에서의 오류 제어 방법, 매체 접속 제어프레임 설계 방법 및 단말기 등록 방법과 기록 매체 |
| US8036200B2 (en) * | 2003-01-21 | 2011-10-11 | Avaya Inc. | Efficient polled frame exchange on a shared-communications channel |
| FR2852751B1 (fr) * | 2003-03-21 | 2005-05-27 | Canon Kk | Procede d'acquittement de la transmission de donnees entre deux machines sur une ligne de transmission serie full-duplex, machine et programme d'ordinateur correspondants. |
| JP4244159B2 (ja) | 2003-05-16 | 2009-03-25 | 株式会社エヌ・ティ・ティ・ドコモ | 受信装置、通信システムおよびプログラム |
| US7296204B2 (en) * | 2003-05-30 | 2007-11-13 | Wegener Communications, Inc. | Error correction apparatus and method |
| AU2003904170A0 (en) * | 2003-08-08 | 2003-08-21 | Clipsal Intergrated Systems Pty Ltd | Radio network communication system and protocol |
| JP2006050519A (ja) * | 2003-10-24 | 2006-02-16 | Sony Corp | 無線通信システム、無線通信装置及び無線通信方法、並びにコンピュータ・プログラム |
| WO2005064839A1 (en) * | 2003-12-29 | 2005-07-14 | Electronics And Telecommunications Research Institute | Method for creating feedback message for arq in mobile communication system |
| EP1721405B1 (en) | 2003-12-29 | 2014-04-02 | Electronics and Telecommunications Research Institute | Method for retransmitting packet in mobile communication system and computer-readable medium recorded program thereof |
| FI116114B (fi) * | 2004-01-27 | 2005-09-15 | Nokia Corp | Kuittausviestien käsittely päätelaitteessa |
| KR100714675B1 (ko) * | 2004-01-30 | 2007-05-07 | 삼성전자주식회사 | 데이터 프레임 재전송 방법 및 상기 방법을 사용하는네트워크 장치 |
| US20050278197A1 (en) * | 2004-06-10 | 2005-12-15 | Podczerwinski Dana M | Biometric information reader and system |
| JP4499489B2 (ja) * | 2004-06-18 | 2010-07-07 | 株式会社エヌ・ティ・ティ・ドコモ | 送信装置、受信装置、通信システム及び通信方法 |
| US8223647B2 (en) | 2004-07-21 | 2012-07-17 | Nokia Corporation | System and method for increasing data throughout using a block acknowledgement |
| JP4440037B2 (ja) * | 2004-08-11 | 2010-03-24 | 株式会社東芝 | 通信装置及び通信方法 |
| US7599363B2 (en) * | 2004-08-13 | 2009-10-06 | Samsung Electronics Co. Ltd | Method for reporting reception result of packets in mobile communication system |
| CN100459483C (zh) * | 2004-08-26 | 2009-02-04 | 华为技术有限公司 | 一种控制状态报告发送频率的方法 |
| US20060093815A1 (en) * | 2004-11-04 | 2006-05-04 | Wilkins Rodney R | Glass fiber filtration media with at least two different fiber diameters |
| WO2006126960A1 (en) * | 2005-05-23 | 2006-11-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Automatic repeat request (arq) protocol having multiple complementary feedback mechanisms |
| KR100708190B1 (ko) * | 2005-11-03 | 2007-04-16 | 삼성전자주식회사 | 무선 네트워크를 통하여 데이터를 효율적으로 송/수신하는방법 및 그 방법을 이용한 무선 디바이스 |
| JP2007053588A (ja) * | 2005-08-18 | 2007-03-01 | Nec Corp | パケット再送方式、パケット再送システム、パケット再送プログラム及びプログラム記録媒体 |
| WO2007032649A1 (en) | 2005-09-15 | 2007-03-22 | Samsung Electronics Co., Ltd. | Method and apparatus for transmitting and receiving status report comprising received status of packet data in a mobile communication system |
| US7729665B2 (en) | 2005-09-28 | 2010-06-01 | Samsung Electronics Co., Ltd. | Down-link data transmission and receiving system and method of ARQ in wireless communication system |
| EP1780926B1 (en) * | 2005-10-28 | 2021-01-20 | Nokia Technologies Oy | Method for ACK/NACK signalling |
| ES2380787T3 (es) * | 2006-05-16 | 2012-05-18 | Nokia Siemens Networks Gmbh & Co. Kg | Método para transmitir de manera segura mapas de bits ACK/NACK cortos en un proceso ARQ dentro de sistemas compatibles con EDGE |
| RU2419826C2 (ru) * | 2006-08-08 | 2011-05-27 | Сименс Энерджи Энд Отомейшн, Инк. | Устройства, системы и способы, относящиеся к plc |
| US8204895B2 (en) * | 2006-09-29 | 2012-06-19 | Business Objects Software Ltd. | Apparatus and method for receiving a report |
| CN101174929A (zh) * | 2006-11-02 | 2008-05-07 | 华为技术有限公司 | 数据压缩方法、装置及自动请求重发反馈系统 |
| WO2008096086A2 (fr) * | 2006-12-08 | 2008-08-14 | France Telecom | Procede de traitement de perte de paquets |
| TWI521927B (zh) * | 2007-01-09 | 2016-02-11 | 皇家飛利浦電子股份有限公司 | 無線通信系統 |
| CA2687064C (en) * | 2007-05-08 | 2012-12-04 | Interdigital Technology Corporation | Method and apparatus for providing piggybacked positive acknowledgement/negative acknowledgement field indicator and a polling indicator |
| US8169992B2 (en) | 2007-08-08 | 2012-05-01 | Telefonaktiebolaget Lm Ericsson (Publ) | Uplink scrambling during random access |
| KR100907978B1 (ko) | 2007-09-11 | 2009-07-15 | 엘지전자 주식회사 | 이동통신 시스템에서 ｐｄｃｐ 계층의 상태보고 전송 방법 및 수신장치 |
| US8401017B2 (en) * | 2008-01-03 | 2013-03-19 | Sunplus Mmobile Inc. | Wireless communication network using an enhanced RLC status PDU format |
| ES2376612T3 (es) * | 2008-02-08 | 2012-03-15 | Telefonaktiebolaget L M Ericsson (Publ) | Método y disposición en un sistema de telecomunicación. |
| KR20100021957A (ko) * | 2008-08-18 | 2010-02-26 | 삼성전자주식회사 | 무선통신시스템에서 자동 재전송 요청 피드백 메시지 생성 장치 및 방법 |
| KR101635433B1 (ko) * | 2008-11-04 | 2016-07-01 | 삼성전자 주식회사 | 재전송 요청을 위한 제어 메시지를 처리하는 방법 및 장치 |
| US20110069669A1 (en) * | 2009-09-11 | 2011-03-24 | Research In Motion Limited | System and methods for sending and receiving pan (piggy-backed ack/nack) so as to avoid decoding confusion |
| JP5232115B2 (ja) * | 2009-09-25 | 2013-07-10 | 日本放送協会 | ファイル送受信システム、ファイル受信装置、ファイル送信装置、ファイル中継装置、ファイル差替え装置、ファイル合成装置及びプログラム |
| JP5676626B2 (ja) * | 2009-10-30 | 2015-02-25 | サムスン エレクトロニクス カンパニー リミテッド | 無線通信システムにおける自動再送要求フィードバックメッセージ生成装置及び方法 |
| CN103874157B (zh) | 2012-12-12 | 2017-07-07 | 华为技术有限公司 | 路由转发、建立路由表、和获取内容的方法及其装置 |
| CN104579573B (zh) * | 2015-01-19 | 2017-12-26 | 北京华力创通科技股份有限公司 | 数据传输的反馈信息的编码、解码方法及发送端和接收端 |
| WO2017034510A1 (en) * | 2015-08-21 | 2017-03-02 | Intel IP Corporation | Pdcp status reports using sequence numbers or sequence number offsets |
| WO2020076380A1 (en) * | 2018-10-11 | 2020-04-16 | Futurewei Technologies, Inc. | System and method for retransmission of individual codewords |
| CN113906700B (zh) * | 2020-05-05 | 2023-09-12 | 华为技术有限公司 | 在网络传输协议中传递确认的设备和方法 |
| EP4297306A4 (en) * | 2021-03-15 | 2024-04-03 | Huawei Technologies Co., Ltd. | TRANSMISSION INDICATION METHOD AND DEVICE, AND SYSTEM |
| WO2024018966A1 (ja) * | 2022-07-22 | 2024-01-25 | 国立大学法人横浜国立大学 | 通信システム、通信装置、通信方法およびプログラム |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE3069762D1 (en) | 1980-08-26 | 1985-01-17 | Ibm | System for the retransmission of incorrectly received numbered frames in a data transmission system |
| US5673252A (en) * | 1990-02-15 | 1997-09-30 | Itron, Inc. | Communications protocol for remote data generating stations |
| JPH0522556A (ja) * | 1991-07-11 | 1993-01-29 | Canon Inc | 複数の表示装置における同報表示方法 |
| US5477550A (en) * | 1993-03-08 | 1995-12-19 | Crisler; Kenneth J. | Method for communicating data using a modified SR-ARQ protocol |
| US5566170A (en) * | 1994-12-29 | 1996-10-15 | Storage Technology Corporation | Method and apparatus for accelerated packet forwarding |
| US5752078A (en) * | 1995-07-10 | 1998-05-12 | International Business Machines Corporation | System for minimizing latency data reception and handling data packet error if detected while transferring data packet from adapter memory to host memory |
| US5754754A (en) | 1995-07-26 | 1998-05-19 | International Business Machines Corporation | Transmission order based selective repeat data transmission error recovery system and method |
| US5799012A (en) * | 1995-08-11 | 1998-08-25 | Motorola, Inc. | System controlled asymmetrical automatic repeat request protocol method |
| US5717689A (en) | 1995-10-10 | 1998-02-10 | Lucent Technologies Inc. | Data link layer protocol for transport of ATM cells over a wireless link |
| TW313734B (en) * | 1996-01-05 | 1997-08-21 | Motorola Inc | System controlled asymmetrical automatic repeat request protocol method |
| US5968197A (en) * | 1996-04-01 | 1999-10-19 | Ericsson Inc. | Method and apparatus for data recovery |
| US6034963A (en) * | 1996-10-31 | 2000-03-07 | Iready Corporation | Multiple network protocol encoder/decoder and data processor |
| US5991299A (en) * | 1997-09-11 | 1999-11-23 | 3Com Corporation | High speed header translation processing |
| US6317430B1 (en) * | 1998-02-19 | 2001-11-13 | Lucent Technologies Inc. | ARQ protocol support for variable size transmission data unit sizes using a hierarchically structured sequence number approach |
| US6359877B1 (en) * | 1998-07-21 | 2002-03-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for minimizing overhead in a communication system |
| US6473399B1 (en) * | 1998-11-30 | 2002-10-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for determining an optimum timeout under varying data rates in an RLC wireless system which uses a PDU counter |
| US6542490B1 (en) * | 1999-01-29 | 2003-04-01 | Nortel Networks Limited | Data link control proctocol for 3G wireless system |
-
2000
- 2000-03-29 US US09/537,146 patent/US6772215B1/en not_active Expired - Lifetime
- 2000-04-07 JP JP2000611424A patent/JP4579421B2/ja not_active Expired - Lifetime
- 2000-04-07 AR ARP000101623A patent/AR025836A1/es active IP Right Grant
- 2000-04-07 WO PCT/SE2000/000677 patent/WO2000062466A2/en not_active Application Discontinuation
- 2000-04-07 BR BRPI0009680A patent/BRPI0009680B1/pt active IP Right Grant
- 2000-04-07 CA CA2369642A patent/CA2369642C/en not_active Expired - Lifetime
- 2000-04-07 EP EP00923044A patent/EP1169803A2/en not_active Ceased
- 2000-04-07 KR KR1020017012783A patent/KR20020013845A/ko not_active Application Discontinuation
- 2000-04-07 CN CNB008087067A patent/CN100359839C/zh not_active Ceased
- 2000-04-07 AU AU43228/00A patent/AU764613B2/en not_active Expired
- 2000-04-07 MY MYPI20001435A patent/MY125271A/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| US6772215B1 (en) | 2004-08-03 |
| CA2369642A1 (en) | 2000-10-19 |
| CN1354931A (zh) | 2002-06-19 |
| BRPI0009680B1 (pt) | 2016-11-01 |
| WO2000062466A3 (en) | 2001-02-15 |
| AR025836A1 (es) | 2002-12-18 |
| BR0009680A (pt) | 2002-01-08 |
| MY125271A (en) | 2006-07-31 |
| CN100359839C (zh) | 2008-01-02 |
| EP1169803A2 (en) | 2002-01-09 |
| WO2000062466A2 (en) | 2000-10-19 |
| AU764613B2 (en) | 2003-08-28 |
| CA2369642C (en) | 2012-02-14 |
| AU4322800A (en) | 2000-11-14 |
| JP2002542661A (ja) | 2002-12-10 |
| KR20020013845A (ko) | 2002-02-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4579421B2 (ja) | Ａｒｑプロトコルにおけるフィードバック応答を最小化する方法 | |
| EP1695462B1 (en) | Transmitting and receiving control protocol data unit having processing time information | |
| EP1662690B1 (en) | Apparatus and method for retransmitting data in mobile communication system | |
| US7849376B2 (en) | Data acknowledgement | |
| US6301249B1 (en) | Efficient error control for wireless packet transmissions | |
| US7801142B2 (en) | Method to avoid potential deadlocks in a SDU discard function | |
| US20030174662A1 (en) | Control information signaling method and network element | |
| JP4232978B2 (ja) | Ａｒｑシステムにおける送信制御方法 | |
| KR100334802B1 (ko) | 유-엠-티-에스 시스템에서 비트맵을 사용하여 오류를통보하는 방법 | |
| KR100662250B1 (ko) | 서비스데이터유닛의 가변적 분할 송신 방법 및 그를이용한 송신 장치 | |
| TW513877B (en) | Method for minimizing feedback responses in ARQ protocols |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070315 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20091124 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20100222 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20100301 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100415 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100820 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100826 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130903 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4579421 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |