(57)【要約】  本発明は、ＡＲＱサービスデータユニット（ＳＤＵ）から少なくとも１つのＡＲＱ  ＰＤＵを形成する方法を提供する。ＡＲＱ  ＰＤＵはヘッダ部とデータ部とを備える。当該方法は、ＡＲＱ  ＳＤＵの最後のビットがＰＤＵに存在するとの判断に応じて、レングスインディケータフィールドをヘッダ部に選択的に追加することを含む。ＨＡＲＱ  ＰＤＵが複数のＡＲＱ  ＰＤＵから形成されている場合には、ＡＲＱ  ＰＤＵの最後のものは、ＡＲＱ  ＳＤＵの最後のビットを搬送していないことが分かったとき、そのヘッダ内にＬＩを含まないように構成され、他のすべてのＡＲＱ  ＰＤＵがＡＲＱ  ＳＤＵの最後のビットを搬送していなくても、ＬＩは、それらの他のすべてのＡＲＱ  ＰＤＵに追加される。
2009532920.tif 000002
【特許請求の範囲】
【請求項１】
ＡＲＱ  ＳＤＵから少なくとも１つのＡＲＱ  ＰＤＵを形成する方法であって、該ＡＲＱ  ＰＤＵはヘッダ部とデータ部とを備え、該方法は、ＡＲＱ  ＳＤＵの最後のビットが前記ＰＤＵに存在するとの判断に応じて、レングスインディケータ（ＬＩ）フィールドを前記ヘッダ部に選択的に追加するステップを含むことを特徴とする方法。
【請求項２】
前記ＰＤＵが前記ＡＲＱ  ＳＤＵの最後のビットを搬送していることが分かった場合にのみ、前記ＬＩフィールドは、前記ＡＲＱヘッダの一部として含まれる、請求項１に記載の方法。
【請求項３】
異なるＳＤＵからの複数のＡＲＱ  ＰＤＵが１つのＨＡＲＱ  ＰＤＵに形成される状況において、最後のＡＲＱ  ＰＤＵが前記ＡＲＱ  ＳＤＵの最後のビットを搬送していないことが分かった場合に、前記ＬＩフィールドは前記最後のＡＲＱ  ＰＤＵに含まれず、他のすべてのＡＲＱ  ＰＤＵが前記ＡＲＱ  ＳＤＵの最後のビットを搬送していなくても、前記ＬＩフィールドは、前記他のすべてのＡＲＱ  ＰＤＵに追加される、請求項１に記載の方法。
【請求項４】
前記ＡＲＱ  ＰＤＵが前記ＡＲＱ  ＳＤＵの最後のビットを搬送していないと判断された場合に、前記方法は、異なるＳＤＵからの複数のＰＤＵが、共通のＨＡＲＱ  ＰＤＵに形成されるか否かを判断するステップを含む、請求項１又は３に記載の方法。
【請求項５】
前記ＬＩフィールドの存在は、前記ＡＲＱヘッダのセグメント及びレングスフィールドによって示される、請求項１〜４のいずれか１項に記載の方法。
【請求項６】
１つのＡＲＱ  ＰＤＵ当たり１つの最後セグメント指示子のみを設けるステップを含む、請求項１〜５のいずれか１項に記載の方法。
【請求項７】
ヘッダ部及びデータ部を備えるＡＲＱ  ＰＤＵフレーム構造であって、前記ヘッダ部は、前記ＡＲＱ  ＰＤＵが形成される元となるＡＲＱ  ＳＤＵの最後のビットが前記ＡＲＱ  ＰＤＵに存在するとの判断に応じる形で、レングスインディケータ（ＬＩ）フィールドを選択的に含めるように構成されている、ＡＲＱ  ＰＤＵフレーム構造。
【請求項８】
前記ＰＤＵが前記ＡＲＱ  ＳＤＵの最後のビットを搬送していることが分かった場合に、前記ＬＩフィールドの追加を可能にするように構成されている、請求項７に記載のＡＲＱ  ＰＤＵフレーム構造。
【請求項９】
複数のＡＲＱ  ＰＤＵから形成されるＨＡＲＱ  ＰＤＵを備え、前記ＡＲＱ  ＰＤＵの最後のものは、前記ＡＲＱ  ＳＤＵの最後のビットを搬送していないことが分かった場合に、そのヘッダ内にＬＩを含まないように構成され、他のすべてのＡＲＱ  ＰＤＵが前記ＡＲＱ  ＳＤＵの最後のビットを搬送していなくても、前記ＬＩは、前記他のすべてのＡＲＱ  ＰＤＵに追加される、請求項７に記載のＡＲＱ  ＰＤＵフレーム構造。
【請求項１０】
前記ＬＩフィールドの存在は、セグメント及びレングスフィールドによって示される、請求項７、８、又は９に記載のＡＲＱ  ＰＤＵフレーム構造。
【請求項１１】
実質的に添付図面に関して記述し且つ添付図面に示したように、ＡＲＱ  ＳＤＵから少なくとも１つのＡＲＱ  ＰＤＵを形成する方法。
【請求項１２】
ＡＲＱ  ＳＤＵから形成され、且つ、実質的に図２Ａ、図２Ｂ；図４Ａ、図４Ｂ；並びに図５Ａ、図５Ｂ、及び図６に関して記述し且つそれらの図に示したようなＡＲＱ  ＰＤＵフレーム構造。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＡＲＱプロトコルデータユニット及びＨＡＲＱプロトコルデータユニット並びにＡＲＱプロトコルデータユニット及びＨＡＲＱプロトコルデータユニットの形成方法に関する。
【背景技術】
【０００２】
自動再送要求(automated repeat request)（ＡＲＱ）は、受信機が、送信メッセージのエラーを検出すると共に、その後、メッセージの再送を要求するように構成されている、既知のエラー訂正方法である。ハイブリッド自動再送要求(Hybrid Automated Repeat Request)（ＨＡＲＱ）は既知であり、１つ又は複数のＡＲＱプロトコルデータユニット（ＰＤＵ）から形成することができ、また同様に、エラー訂正目的を果たすことができる。
【０００３】
ユニバーサル・モバイル・テレコムニケーション・システム（ＵＭＴＳ）用に第３世代・パートナシップ・プロジェクト（３ＧＰＰ）内で提案された仕様から、ＡＲＱプロトコル及びＨＡＲＱプロトコルのそれぞれが、異なる物理エンティティに存在することが分かっている。すなわち、ＡＲＱの場合には無線ネットワークコントローラ（ＲＮＣ）に存在し、ＨＡＲＱプロトコルの場合には論理的なNode-Bに存在することが分かっている。
【０００４】
データ転送遅延の低減は、ＡＲＱプロトコル及びＨＡＲＱプロトコルを共に、E-Node-B等の単一の物理エンティティに入れることによって達成することができることが確認されており、現在の３ＧＰＰのロング・ターム・エボルーション(Long Term Evolution)（ＬＴＥ）プロジェクトは、このようなプロセスを対象としている。ＡＲＱプロセス及びＨＡＲＱプロトコルを共に単一の物理エンティティ上に入れることを成功させるために、より高速なデータスループットを提供し、且つ、利用可能な無線資源をより効率的に使用するＡＲＱ  ＰＤＵ及びＨＡＲＱ  ＰＤＵの新しいフォーマットをＬＴＥが必要とすることが注目されてきた。
【０００５】
このようないずれのＰＤＵフォーマットも、単一の物理エンティティに共に存在するＡＲＱプロトコル及びＨＡＲＱプロトコルを発揮するすべてのシステムに都合よく適用可能である。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
３ＧＰＰ標準規格の提案に従って、適切なＡＲＱ／ＨＡＲＱ  ＰＤＵフォーマットの可用性に関して、さまざまな提案が存在するが、本発明は、Ｔｄｏｃ（Ｒ２−０６００７６）に記載されたような既知の提案のデータスループットを高める働きをするＡＲＱ／ＨＡＲＱ  ＰＤＵフォーマットを提供しようとするものである。
【課題を解決するための手段】
【０００７】
本発明の一態様によれば、ＡＲＱサービスデータユニット（ＳＤＵ）から少なくとも１つのＡＲＱ  ＰＤＵを形成する方法であって、ＡＲＱ  ＰＤＵはヘッダ部及びデータ部を備え、当該方法は、ＡＲＱ  ＳＤＵの最後のビットがＰＤＵに存在するとの判断に応じて、レングスインディケータ(Length Indicator：ＬＩ)フィールドを上記ヘッダ部に選択的に追加することを含む、方法が提供される。
【０００８】
本発明は、ＡＲＱ  ＳＤＵの最後のビットがＰＤＵ内に存在するか否かの判断に応じて、ヘッダ部内のＬＩフィールドの存在を示すことを通じて、適宜、ヘッダからＬＩフィールドを省くことが実際に可能になり、それによってヘッダのオーバーヘッドを低減することが実際に可能になり、それによってＰＤＵ内のデータペイロード用により多くのスペースが残されるという点で、特に利点がある。
【０００９】
したがって、本発明は利点として、必要なときにのみ、上述したように、ＰＤＵがＡＲＱ  ＳＤＵの最後のビットを搬送していることが分かった場合にのみ、ＬＩフィールドをヘッダ内に組み込むことによってヘッダのオーバーヘッドを有効に低減する。
【００１０】
異なるＳＤＵからの複数のＡＲＱ  ＰＤＵが１つのＨＡＲＱ  ＰＤＵに形成される場合において、最後のＡＲＱ  ＰＤＵがＡＲＱ  ＳＤＵの最後のビットを搬送していないことが分かったとき、ＬＩは最後のＡＲＱ  ＰＤＵに含まれず、他のすべてのＡＲＱ  ＰＤＵがＡＲＱ  ＳＤＵの最後のビットを搬送していなくても、ＬＩは、他のすべてのＡＲＱ  ＰＤＵに追加される。すなわち、これは、先のパラグラフのルールに対する１つの例外である。
【００１１】
ラストセグメントインディケータフィールド（ＬＳＩ）と共にＡＲＱ  ＰＤＵにＬＩフィールドが存在することによって、受信機がＡＲＱ  ＳＤＵを再組み立てすることを容易にする。
【００１２】
もちろん、本発明は、ＡＲＱ  ＰＤＵがＡＲＱ  ＳＤＵの最後のビットを搬送していないと判断された場合に、異なるＳＤＵからの複数のＰＤＵが、共通のＨＡＲＱ  ＰＤＵに形成されるか否かを判断するステップを含む、方法を含むことができることが十分理解されるであろう。
【００１３】
利点として、ＬＩフィールドの存在は、ＡＲＱヘッダのセグメント及びレングスフィールドによって示される。
【００１４】
さらなる特徴として、当該方法は、１つのＡＲＱ  ＰＤＵ当たり１つのラストセグメントインディケータ（ＬＳＩ）のみを設けるステップを含むことができる。
【００１５】
これは、必要とされるＬＳＩフィールドの個数が、１つのＡＲＱ  ＰＤＵ当たり見られるセグメンテーションのレベルの個数に対応する現在のＡＲＱフォーマットと比較すると、さらに有利であることが分かる。
【００１６】
したがって、上記から十分理解されるように、モディファイドフレームフォーマットが、本発明によって提案され、利点として、ヘッダフィールドに必要なビット数を削減する働きをする。
【００１７】
本発明に従って占有される帯域幅は、現在の技術と比較して２６％の削減を表すことが予想される。
【００１８】
本発明の別の態様によれば、ヘッダ部及びデータ部を備えるＡＲＱ  ＰＤＵフレーム構造であって、ヘッダ部は、ＡＲＱ  ＰＤＵが形成される元となるＡＲＱ  ＳＤＵの最後のビットがＡＲＱ  ＰＤＵに存在するとの判断に応じる形で、セグメントインディケータフィールドを選択的に含めるように構成されている、ＡＲＱ  ＰＤＵフレーム構造が提供される。
【００１９】
上記から分かるように、ＡＲＱ  ＰＤＵフレーム構造は、利点として、ＰＤＵがＡＲＱ  ＳＤＵの最後のビットを搬送していることが分かった場合に、ＬＩの追加を可能にするように構成されている。
【００２０】
一代替的なものとして、複数のＡＲＱ  ＰＤＵから形成されるＨＡＲＱ  ＰＤＵであって、ＡＲＱ  ＰＤＵの最後のものは、ＡＲＱ  ＳＤＵの最後のビットを搬送していないことが分かった場合に、そのヘッダ内にＬＩを含まないように構成され、他のすべてのＡＲＱ  ＰＤＵがＡＲＱ  ＳＤＵの最後のビットを搬送していなくても、ＬＩは、他のすべてのＡＲＱ  ＰＤＵに追加される、ＨＡＲＱ  ＰＤＵが提供される。
【００２１】
ラストセグメントインディケータフィールド（ＬＳＩ）と共にＡＲＱ  ＰＤＵにＬＩフィールドが存在することによって、受信機がＡＲＱ  ＳＤＵを再組み立てすることを容易にする。
【００２２】
以下では、例示としてのみ、本発明を添付図面に関してさらに説明する。
【発明を実施するための最良の形態】
【００２３】
ＬＴＥプロジェクトの３ＧＰＰ標準化においては、ＡＲＱフレームフォーマット及びＨＡＲＱフレームフォーマットへの検討がされてきた。しかしながら、このような検討は、それらのフレームフォーマットのデータスループットの取り扱いにおいて制限されている。
【００２４】
本発明は、データスループットを改善することによってこのような制限に対処しようとすると共に、このような改善を達成しようとするものであり、本発明は、各ＰＤＵ内のデータペイロード用のスペースの量をより多く残すために、ヘッダ情報が必要とするスペースを削減しようとするものである。
【００２５】
本発明の範囲内の主要な概念は、対象となっているＰＤＵ内でのＡＲＱ  ＳＤＵの最後のビットが存在するとの判断に応じて、ＬＩヘッダフィールドの包含を制御することである。
【００２６】
このようにしてＬＩヘッダフィールドの存在を利用可能にすることを通じて、次に、ＬＩヘッダフィールドは、すべてのヘッダ内に包括的に含まれるのではなく、必要なときにのみヘッダに含まれることが分かる。
【００２７】
次に図１を参照して、ＡＲＱプロトコル及びＨＡＲＱプロトコルが、たとえばＭＡＣ  E-node B 又はＭＡＣ  ＵＥ内で共に機能する方法の概略図が提供されている。
【００２８】
図示するように、複数の論理チャネル１０を含むＭＡＣアーキテクチャ１０が提供されている。複数の論理チャネル１０は、優先度／スケジューリングコントローラ１６によって制御され、その後、マルチプレクサ１８に配信される複数のＡＲＱ  ＰＤＵ１２、１４を提供する。
【００２９】
ＡＲＱ  ＰＤＵは、マルチプレクサ１８によって結合されると、ＨＡＲＱ  ＰＤＵ２０を形成する働きをする。ＨＡＲＱ  ＰＤＵ２０は、トランスポートチャネル２２上へ配信される。
【００３０】
次に図２Ａ及び図２Ｂを参照して、ＡＲＱ  ＰＤＵ及びＨＡＲＱ  ＰＤＵの構造が示されている。
【００３１】
図２Ａに関しては、ＡＲＱ  ＰＤＵ２４が示されている。ＡＲＱ  ＰＤＵ２４は、さまざまなフィールドを有するヘッダ２６と、データペイロード２８を備える第２の部分とを含む。さまざまなフィールドに関しては、以下でさらに解説する。
【００３２】
図２Ｂに関して、ＨＡＲＱ  ＰＤＵ構造は、もちろん、1つ又は複数のＡＲＱ  ＰＤＵから形成され、したがって、複数のＡＲＱ  ＰＤＵの各ヘッダフィールド３２を備えるＨＡＲＱ  ＰＤＵ構造３０を含む。各ヘッダフィールド３２において、第１のヘッダフィールド３４は第１のＡＲＱ  ＰＤＵに関係し、第２のヘッダフィールド３６は第２のＡＲＱ  ＰＤＵフィールドに関係し、第３のヘッダフィールド３８は第３のＡＲＱ  ＰＤＵフィールドに関係している。
【００３３】
ヘッダフィールドの後には、複数のＡＲＱ  ＰＤＵデータペイロード４０が設けられている。このデータペイロード４０は、ヘッダ３２、３６、及び３８にそれぞれ関係する別個のペイロード４２、４４、及び４６を備える。図２Ｂ内のヘッダ３６、３８のそれぞれは、より詳細に示された第１のヘッダ３４の構造を共有する。図２Ａのヘッダ２６及び図２Ｂのヘッダ３２の異なるフィールドを以下でさらに解説する。
【００３４】
ＭＩＤフィールドは、ＬＴＥが、ＡＲＱ  ＰＤＵの２つ以上のＩＰフローを１つのＨＡＲＱ  ＰＤＵに多重化することを可能にする場合にのみ必要とされる。このフィールドは、一般に、４ビットの長さを有する。
【００３５】
ＳＮ（シーケンス番号）：暗号化（これを行うレイヤは、現在，ＬＴＥに関して定義されていない）中に使用される同じＳＮが、ＡＲＱ及びＨＡＲＱにおいて抽出及び再利用される。ＳＮフィールドは１２ビットの長さを有する。
【００３６】
ＳＬ（セグメント及びレングスインディケータ）：第１ビットは、セグメント情報（ＳＩ、ＬｏＳ、ＬＳＩ、及びＳＳＩ）の存在を示し、第２ビットはＬＩフィールドの存在を示す。ＳＬフィールドは２ビットの長さを有する。
【００３７】
ＳＩ（セグメントインデックス）：これは、ＡＲＱ  ＳＤＵのセグメント番号の表示を提供し、４ビットの長さを有する。
【００３８】
ＬｏＳ（レベル・オブ・セグメンテーション）：レベル・オブ・セグメンテーションは、常にＳＩ又はＳＳＩに関連付けられている。ＬｏＳは、１ビットの長さを有し、送信される実際のセグメントが前のＳＩ／ＳＳＩフィールドによって示されるときは「０」に設定され、送信される実際のセグメントが前のＳＩ／ＳＳＩの部分セグメントであるときは「１」に設定される。実際のセグメントのＳＳＩは、この場合、次のフィールドにあるべきである。
【００３９】
ＳＳＩ（サブセグメントインディケータ）：再送が、前に送信された（ＡＲＱ  ＳＤＵのセグメントである）ＡＲＱ  ＰＤＵのセグメンテーションを必要とする場合、ＳＳＩはセグメント番号を示し、４ビットの長さを有する。
【００４０】
ＬＳＩ（ラストセグメントインディケータ）：このフィールドは、（「０」に設定されている）ＬｏＳフィールドの次にくる。また、このフィールドは、受信機が、ＰＤＵをＳＤＵに再組み立てするのを容易にすることができ、１ビットの長さを有する。セグメントが最後のセグメントである場合には、ＬＳＩは「１」に設定され、そうでない場合には、ＬＳＩは「０」に設定される。
【００４１】
ＬＩ（レングスインディケータ）：ＡＲＱ  ＰＤＵの長さを示す。
【００４２】
もちろん、本発明に従って十分理解されるように、ＡＲＱ  ＰＤＵがＡＲＱ  ＳＤＵの最後のビットを搬送している場合に、ＬＩはそのＡＲＱ  ＰＤＵに追加される。
【００４３】
さらに、異なるＡＲＱ  ＳＤＵからのＡＲＱ  ＰＤＵを１つのＨＡＲＱ  ＰＤＵに連結する場合において、最後のＡＲＱ  ＰＤＵがＡＲＱ  ＳＤＵの最後のビットを搬送していないときは、ＬＩは、最後のＡＲＱ  ＰＤＵを除くすべてのＡＲＱ  ＰＤＵに追加される。もちろん、ＰＤＵが上述したいずれのカテゴリーにも入らない場合には、そのＰＤＵは、ＬＩフィールドを必要としない。ＬＩフィールドは、通常、１５ビット又は７ビットの長さを有する。
【００４４】
実際のＰＤＵのビット長＝（（ＬＩ＊８）−４）であり、これは、オクテット整列されていない１２ビットのＳＮがＳＤＵから抽出されて、ＳＮ、又はＡＲＱ  ＰＤＵ及びＨＡＲＱ  ＰＤＵとして使用されるためである。
【００４５】
Ｅ：１ビットの長さを有し、さらなるヘッダが存在する場合には「１」に設定され、そうでない場合には「０」に設定される拡張ビット。
【００４６】
本発明をさらに示すために、ヘッダの構成を以下に示す。この構成は、ＳＬフィールドの４つの値のそれぞれに関してのＳＩフィールド、ＬｏＳフィールド、ＳＳＩフィールド、ＬＳＩフィールド、及びＬＩフィールドの使用を示す働きをする。ＭＩＤビット、ＳＮビット、ＳＬビット、及びＥビットは、ヘッダのそれぞれに常に存在することが十分理解されるべきである。
【００４７】
ＳＬ：００
−ＳＩフィールド、ＬｏＳフィールド、ＳＳＩフィールド、ＬＳＩフィールド、及びＬＩフィールドは存在しない。
【００４８】
ＳＬ：０１
−ＬＩは存在する。  
−ＳＩ、ＳＳＩ、ＬｏＳ、及びＬＳＩは存在しない。
【００４９】
ＳＬ：１０
−Ｌ１は存在しない
−以下のＡ及びＢを参照されたい。
【００５０】
ＳＬ：１１
−ＬＩは存在する。  
−以下のＡ及びＢを参照されたい。
【００５１】
Ａ．ＡＲＱ  ＳＤＵのセグメントであるＡＲＱ  ＰＤＵの最初の送信である場合
−ＳＩは存在する
−ＬｏＳ＝０
−ＬＳＩはＬｏＳフィールドの次にくる
−セグメントレベル＝１
Ｂ．再送である場合
−前に送信されたＡＲＱ  ＰＤＵがこの送信でさらにセグメント化されている場合
−セグメントレベル＝セグメントレベル＋１
−前に送信されたＡＲＱ  ＰＤＵがセグメント化されていない場合
−セグメントレベル＝セグメントレベル
−ＳＩは存在する
−ＬｏＳの個数＝セグメントレベル、ＬｏＳ（１）からＬｏＳ（セグメントレベル−１）＝１、且つ、ＬｏＳ（セグメントレベル）＝０
−ＳＳＩの個数＝セグメントレベル−１
−ＬＳＩはＬｏＳ（セグメントレベル）の次にくる
【００５２】
本発明の方法の一実施形態を、図３を参照して以下でさらに示す。図３は、ＬＩフィールドがヘッダにいつどのように追加されるのかを示す働きをするフローチャートを含む。
【００５３】
各ＡＲＱ  ＰＤＵ４８に関して、図３を参照して、５０において、そのＡＲＱ  ＰＤＵがＡＲＱ  ＳＤＵの最後のビットを搬送しているか否かが判断される。
【００５４】
上述したように、ＡＲＱ  ＳＤＵを表すのに複数のＡＲＱ  ＰＤＵを設けることもできるし、単一のＡＲＱ  ＰＤＵが単一のＡＲＱ  ＳＤＵを表すこともできる。
【００５５】
ステップ５０において、ＡＲＱ  ＰＤＵがＡＲＱ  ＳＤＵの最後のビットを搬送していると判断された場合には、この方法はステップ５２に進み、ステップ５２において、ＬＩがヘッダ内に含まれるべきであると判断される。
【００５６】
一方、ステップ５０において、ＡＲＱ  ＰＤＵが、ＡＲＱ  ＳＤＵの最後のビットを搬送していないと判断された場合には、この方法はステップ５４に進み、ステップ５４において、対象となっているＡＲＱ  ＰＤＵが、ＨＡＲＱ  ＰＤＵ内の複数の連結されているＡＲＱ  ＰＤＵうちのの１つであるか否かが判断される。
【００５７】
ステップ５４において、ＡＲＱ  ＰＤＵが、ＨＡＲＱ  ＰＤＵ内のこのような複数の連結されているＡＲＱ  ＰＤＵのうちの１つであると判断された場合には、この方法はステップ５６に進み、ステップ５６において、対象となっているＡＲＱ  ＰＤＵが、ＨＡＲＱ  ＰＤＵ内の最後のものであるか否かが判断される。
【００５８】
ステップ５６において、ＡＲＱ  ＰＤＵが、ＨＡＲＱ  ＰＤＵの最後のものでないと判断された場合には、この方法はステップ５２に進み、ステップ５２において、ＬＩがヘッダ内に含まれるべきであると判断される。
【００５９】
ステップ５４において、ＡＲＱ  ＰＤＵが、ＨＡＲＱ  ＰＤＵ内で他のＡＲＱ  ＰＤＵと連結されていないと判断された場合、又は、ステップ５６において、ＡＲＱ  ＰＤＵがＨＡＲＱ  ＰＤＵ内の最後のものであると判断された場合には、この方法はステップ５８に進み、ステップ５８において、ＬＩがヘッダ内に含まれる必要がないと判断される。
【００６０】
さらなる説明として、次に、異なるシナリオを以下で解説する。これらの異なるシナリオは、本発明に従って生じるフレームフォーマットを使用することができる方法を示す働きをする。
【００６１】
第１のシナリオは、おそらく最も一般的な場合を含み、メッセージヘッダをどのように削減することができるのかに関しての明確な表示を提供する。
【００６２】
ＡＲＱ  ＳＤＵ（１つの音声フレームを含むＲＯＨＣ圧縮されたＩＰｖ６）サイズ＝６
（ＲＯＨＣヘッダ）＋３２（ＡＭＲ  ＲＴＰペイロード）＝３８バイト＝３０４ビット
時間間隔：２０ｍｓごとに１つのＳＤＵ
ＡＲＱ  ＢＬＥＲ＝０％
ＨＡＲＱＢＬＥＲ＝１０％
ＨＡＲＱ  ＰＤＵサイズ＝１０４ビット
送信されるＡＲＱデータ＝ＡＲＱ  ＳＤＵ−ＡＲＱ  ＳＮ＝２９２ビット
第１のＨＡＲＱ  ＰＤＵ、第２のＨＡＲＱ  ＰＤＵ、及び第３のＨＡＲＱ  ＰＤＵのヘッダサイズ＝２４及び送信される実際のＡＲＱデータ＝８０ビット
第４のＨＡＲＱ  ＰＤＵのヘッダサイズ＝３２ビット及び送信される実際のＡＲＱデータ＝５２ビット
ＳＤＵは、４つのＨＡＲＱ  ＰＤＵにセグメント化される必要がある。
【００６３】
図４Ａ及び図４Ｂを参照して、この第１のシナリオに従って生じる４つのＨＡＲＱ  ＰＤＵの構造の説明図が提供されている。
【００６４】
図４Ａは、ＬＩフィールドが必要とされないことが十分理解される第１のＨＡＲＱ  ＰＤＵから第３のＨＡＲＱ  ＰＤＵのフォーマットを示している。
【００６５】
一方、図４Ｂに関しては、第４のＨＡＲＱ  ＰＤＵが示されている。この第４のＨＡＲＱ  ＰＤＵは、そのヘッダ内にＬＩフィールドを含む。
【００６６】
以下の比較を通じて、本発明が、ＡＲＱの現在の状態と比較して有利な性能をどのように提供することができるのかを容易に理解することができる。
【００６７】
１つのＡＲＱ  ＰＤＵ当たりのヘッダのビット数に関して、現在の技術では３２ビットが必要とされるのに対して、本発明では、第１のＨＡＲＱ  ＰＤＵ、第２のＨＡＲＱ  ＰＤＵ、及び第３のＨＡＲＱ  ＰＤＵに関しては２４ビットが必要とされ、第４のＨＡＲＱ  ＰＤＵに関しては３２ビットが必要とされる。
【００６８】
１つのＡＲＱ  ＳＤＵを送信するのに必要なＰＤＵの総数は、現在の技術では５つであるのに対して、本発明に関して計算した場合には４つのみである。
【００６９】
現在の技術では、ヘッダの全オーバーヘッドは、約１６０であるのに対して、本発明では、この数字は、ほぼ１０４ビット程度に削減される。
【００７０】
現在の技術では、全データとＨＡＲＱヘッダとの組み合わせから生じる全ビット数は４５２（２９２＋１６０）であり、本発明では３９６（２９２＋１０４）である。
【００７１】
帯域幅の値に関して、現在の技術は、２６．２６ｋｂｐｓの帯域幅を占有するのが分かるのに対して、本発明では、ほぼ２１．００８ｋｂｐｓ程度の帯域幅が占有される。
【００７２】
次に図５Ａ及び図５Ｂを参照して、これらの図は、ＡＲＱ  ＳＤＵセグメントの再送を伴うさらなるシナリオのＨＡＲＱ  ＰＤＵ構造を示している。このＨＡＲＱ  ＰＤＵ構造では、ＨＡＲＱ  ＰＤＵサイズは、さらなるセグメント化を必要とするために、元のＡＲＱ  ＰＤＵを単一のＨＡＲＱ  ＰＤＵ内でもはや送信することができないように変更されている。すなわち、ＨＡＲＱ  ＰＤＵサイズは、ほぼ８０ビット程度であり、このサイズは元のＰＤＵを収容することができないため、セグメンテーションが必要とされる。
【００７３】
このようにして、ＡＲＱ  ＰＤＵ−１は、４８ビットのデータを有する３２ビットのヘッダの部分セグメントを備えるのに対して、ＡＲＱ  ＰＤＵ−２は、サイズが４０ビットのヘッダを有する第２の部分セグメントを備える一方、送信される実際のデータは２８ビットを備える。
【００７４】
図５Ａは、第１の部分セグメントのＨＡＲＱ  ＰＤＵを示している。このＨＡＲＱ  ＰＤＵは、上述した寸法のヘッダ部６８及びデータペイロード部７０を含む。これに対して、図５Ｂは、特にＬＩを含むヘッダ７２を有し、また、データペイロード７４も含み、且つ、上述したようなビット数を備える第２の部分セグメントのＨＡＲＱ  ＰＤＵを示している。十分に理解されるように、ＨＡＲＱ  ＰＤＵは、第２のセグメントによって完全に満たされず、送信するデータがそれ以上ないため、いくらかの追加が必要とされる可能性があり、このような理由から、ＬＩは実際のデータが終了する箇所を示す目的を果たし、パディングが開始する。
【００７５】
もちろん、上述したパディングを使用する代わりに、ＨＡＲＱは、利用可能な空きスペースを他の任意の目的で使用することができることが十分理解される。
【００７６】
この第２のシナリオでは、占有された帯域幅は、現在の技術で経験したものと同じであることが十分理解されるべきである。
【００７７】
第３のシナリオに関して、異なるＡＲＱエンティティからのデータを単一のＨＡＲＱ  ＰＤＵに多重化することが示されている。しかしながら、簡単にするために、関連のあるビット数は、図には示されていない。
【００７８】
したがって、図６に関しては、第１のＡＲＱ  ＰＤＵ８２及び第２のＡＲＱ  ＰＤＵ８４にセグメント化されたＡＲＱ  ＳＤＵ８０を備える第１のデータフロー７８と、単一のＡＲＱ  ＰＤＵ９０になるＡＲＱ  ＳＤＵ８８を備える第２のフロー８６との多重化が示されている。
【００７９】
ＨＡＲＱ  ＰＤＵは多重化されると、ヘッダ領域９２及びＰＤＵペイロードデータ９４で示されるように、２つのＡＲＱ  ＳＤＵ８０、８８を収容する。
【００８０】
第４のシナリオに関して、ＨＡＲＱ  ＰＤＵサイズは、第３のＨＡＲＱ  ＰＤＵの時点で変化するように構成される。この第３のＨＡＲＱ  ＰＤＵは、ＳＤＵ送信の中間で起こる。
【００８１】
ここで図７を参照する。図７は、ＡＲＱ  ＳＤＵ９６、ＡＲＱ  ＰＤＵ９８、及びＨＡＲＱ  ＰＤＵ１００を示している。
【００８２】
第１のシナリオで生じた値のような対応する値がここで使用され、主要な相違は、１つのＡＲＱ  ＳＤＵ及び５つのＨＡＲＱ  ＰＤＵを送信するために、ＨＡＲＱＰＤＵサイズが第３のＨＡＲＱ  ＰＤＵで変更されるということであることが十分理解されるべきである。
【００８３】
ＡＲＱ  ＰＤＵ内に示すように、ＡＲＱヘッダ及びＳＤＵデータのサイズは、第３のＨＡＲＱ  ＰＤＵまで９５ビットであり、第３のＨＡＲＱ  ＰＤＵの時点で、サイズは７５ビットに変化する。
【００８４】
それに対して、ＨＡＲＱ  ＰＤＵ１００に関しては、ここでのサイズは、第３のＨＡＲＱ  ＰＤＵの時点で８０ビットに削減するまで、１００ビットである。
【００８５】
このように、上述した４つのシナリオから、送信速度及びネットワーク資源の効率的な使用に関して、本発明が現在の技術と比較してどれだけ好ましいかを十分理解することができ、さらに、ＡＲＱ  ＳＤＵ送信の完了前にＨＡＲＱ  ＰＤＵサイズに変更がある場合に、再セグメント化又は連結の必要性をどのようになくすことができるのかを十分理解することができる。
【００８６】
より高速且つより効率的なデータスループットを提供するＡＲＱ  ＰＤＵ及びＨＡＲＱ  ＰＤＵのフォーマットの提供を通じて、ＡＲＱプロトコル及びＨＡＲＱプロトコルを共に単一の物理エンティティ内に入れる可能性が、３ＧＰＰ  ＬＴＥ送信の全体的な遅延を削減するために、好都合に実現される。
【図面の簡単な説明】
【００８７】
【図１】ＡＲＱプロトコル及びＨＡＲＱプロトコルを有するＭＡＣアーキテクチャの概略図である。
【図２Ａ】ＡＲＱ  ＰＤＵのＰＤＵフレーム構造フォーマットを示す図である。
【図２Ｂ】ＨＡＲＱ  ＰＤＵのＰＤＵフレーム構造フォーマットを示す図である。
【図３】本発明の一実施形態による長さ指示子フィールドの追加又は省略の方法を示すフロー図である。
【図４Ａ】本発明の一実施形態に従って生じるＨＡＲＱ  ＰＤＵの構造を示す図である。
【図４Ｂ】本発明の一実施形態に従って生じるＨＡＲＱ  ＰＤＵの構造を示す図である。
【図５Ａ】本発明の別の実施形態に従って生じるＨＡＲＱ  ＰＤＵの構造を示す図である。
【図５Ｂ】本発明の別の実施形態に従って生じるＨＡＲＱ  ＰＤＵの構造を示す図である。
【図６】異なるＡＲＱエンティティからのＡＲＱ  ＰＤＵの多重化によるＨＡＲＱ  ＰＤＵの構造及び形成を示す図である。
【図７】ＡＲＱ  ＳＤＵからのＨＡＲＱ  ＰＤＵ及びＡＲＱ  ＰＤＵの形成の説明図である。
【図１】
2009532920.tif 000003
【図２Ａ】
2009532920.tif 000004
【図２Ｂ】
2009532920.tif 000005
【図３】
2009532920.tif 000006
【図４Ａ】
2009532920.tif 000007
【図４Ｂ】
2009532920.tif 000008
【図５Ａ】
2009532920.tif 000009
【図５Ｂ】
2009532920.tif 000010
【図６】
2009532920.tif 000011
【図７】
2009532920.tif 000012
【国際調査報告】
2009532920.tif 000013
2009532920.tif 000014