JP5240455B2

JP5240455B2 - 形成方法

Info

Publication number: JP5240455B2
Application number: JP2008546015A
Authority: JP
Inventors: ゴラプディ，スリーラクシュミ
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2006-04-04
Filing date: 2007-04-02
Publication date: 2013-07-17
Anticipated expiration: 2027-04-02
Also published as: WO2007116985A1; EP2002587A4; CN101411111B; GB2436912A; JP2009532920A; EP2002587A1; CN101411111A; US20090259908A1; GB2436912B; GB0606801D0; US8352820B2

Description

本発明は、ＡＲＱプロトコルデータユニット及びＨＡＲＱプロトコルデータユニット並びにＡＲＱプロトコルデータユニット及びＨＡＲＱプロトコルデータユニットの形成方法に関する。

自動再送要求(automated repeat request)（ＡＲＱ）は、受信機が、送信メッセージのエラーを検出すると共に、その後、メッセージの再送を要求するように構成されている、既知のエラー訂正方法である。ハイブリッド自動再送要求(Hybrid Automated Repeat Request)（ＨＡＲＱ）は既知であり、１つ又は複数のＡＲＱプロトコルデータユニット（ＰＤＵ）から形成することができ、また同様に、エラー訂正目的を果たすことができる。

ユニバーサル・モバイル・テレコムニケーション・システム（ＵＭＴＳ）用に第３世代・パートナシップ・プロジェクト（３ＧＰＰ）内で提案された仕様から、ＡＲＱプロトコル及びＨＡＲＱプロトコルのそれぞれが、異なる物理エンティティに存在することが分かっている。すなわち、ＡＲＱの場合には無線ネットワークコントローラ（ＲＮＣ）に存在し、ＨＡＲＱプロトコルの場合には論理的なNode-Bに存在することが分かっている。

データ転送遅延の低減は、ＡＲＱプロトコル及びＨＡＲＱプロトコルを共に、E-Node-B等の単一の物理エンティティに入れることによって達成することができることが確認されており、現在の３ＧＰＰのロング・ターム・エボルーション(Long Term Evolution)（ＬＴＥ）プロジェクトは、このようなプロセスを対象としている。ＡＲＱプロセス及びＨＡＲＱプロトコルを共に単一の物理エンティティ上に入れることを成功させるために、より高速なデータスループットを提供し、且つ、利用可能な無線資源をより効率的に使用するＡＲＱＰＤＵ及びＨＡＲＱＰＤＵの新しいフォーマットをＬＴＥが必要とすることが注目されてきた。

このようないずれのＰＤＵフォーマットも、単一の物理エンティティに共に存在するＡＲＱプロトコル及びＨＡＲＱプロトコルを発揮するすべてのシステムに都合よく適用可能である。

３ＧＰＰ標準規格の提案に従って、適切なＡＲＱ／ＨＡＲＱＰＤＵフォーマットの可用性に関して、さまざまな提案が存在するが、本発明は、Ｔｄｏｃ（Ｒ２−０６００７６）に記載されたような既知の提案のデータスループットを高める働きをするＡＲＱ／ＨＡＲＱＰＤＵフォーマットを提供しようとするものである。

本発明の一態様によれば、ＡＲＱサービスデータユニット（ＳＤＵ）から少なくとも１つのＡＲＱＰＤＵを形成する方法であって、ＡＲＱＰＤＵはヘッダ部及びデータ部を備え、当該方法は、ＡＲＱＳＤＵの最後のビットがＰＤＵに存在するとの判断に応じて、レングスインディケータ(Length Indicator：ＬＩ)フィールドを上記ヘッダ部に選択的に追加することを含む、方法が提供される。

本発明は、ＡＲＱＳＤＵの最後のビットがＰＤＵ内に存在するか否かの判断に応じて、ヘッダ部内のＬＩフィールドの存在を示すことを通じて、適宜、ヘッダからＬＩフィールドを省くことが実際に可能になり、それによってヘッダのオーバーヘッドを低減することが実際に可能になり、それによってＰＤＵ内のデータペイロード用により多くのスペースが残されるという点で、特に利点がある。

したがって、本発明は利点として、必要なときにのみ、上述したように、ＰＤＵがＡＲＱＳＤＵの最後のビットを搬送していることが分かった場合にのみ、ＬＩフィールドをヘッダ内に組み込むことによってヘッダのオーバーヘッドを有効に低減する。

異なるＳＤＵからの複数のＡＲＱＰＤＵが１つのＨＡＲＱＰＤＵに形成される場合において、最後のＡＲＱＰＤＵがＡＲＱＳＤＵの最後のビットを搬送していないことが分かったとき、ＬＩは最後のＡＲＱＰＤＵに含まれず、他のすべてのＡＲＱＰＤＵがＡＲＱＳＤＵの最後のビットを搬送していなくても、ＬＩは、他のすべてのＡＲＱＰＤＵに追加される。すなわち、これは、先のパラグラフのルールに対する１つの例外である。

ラストセグメントインディケータフィールド（ＬＳＩ）と共にＡＲＱＰＤＵにＬＩフィールドが存在することによって、受信機がＡＲＱＳＤＵを再組み立てすることを容易にする。

もちろん、本発明は、ＡＲＱＰＤＵがＡＲＱＳＤＵの最後のビットを搬送していないと判断された場合に、異なるＳＤＵからの複数のＰＤＵが、共通のＨＡＲＱＰＤＵに形成されるか否かを判断するステップを含む、方法を含むことができることが十分理解されるであろう。

利点として、ＬＩフィールドの存在は、ＡＲＱヘッダのセグメント及びレングスフィールドによって示される。

さらなる特徴として、当該方法は、１つのＡＲＱＰＤＵ当たり１つのラストセグメントインディケータ（ＬＳＩ）のみを設けるステップを含むことができる。

これは、必要とされるＬＳＩフィールドの個数が、１つのＡＲＱＰＤＵ当たり見られるセグメンテーションのレベルの個数に対応する現在のＡＲＱフォーマットと比較すると、さらに有利であることが分かる。

したがって、上記から十分理解されるように、モディファイドフレームフォーマットが、本発明によって提案され、利点として、ヘッダフィールドに必要なビット数を削減する働きをする。

本発明に従って占有される帯域幅は、現在の技術と比較して２６％の削減を表すことが予想される。

本発明の別の態様によれば、ヘッダ部及びデータ部を備えるＡＲＱＰＤＵフレーム構造であって、ヘッダ部は、ＡＲＱＰＤＵが形成される元となるＡＲＱＳＤＵの最後のビットがＡＲＱＰＤＵに存在するとの判断に応じる形で、セグメントインディケータフィールドを選択的に含めるように構成されている、ＡＲＱＰＤＵフレーム構造が提供される。

上記から分かるように、ＡＲＱＰＤＵフレーム構造は、利点として、ＰＤＵがＡＲＱＳＤＵの最後のビットを搬送していることが分かった場合に、ＬＩの追加を可能にするように構成されている。

一代替的なものとして、複数のＡＲＱＰＤＵから形成されるＨＡＲＱＰＤＵであって、ＡＲＱＰＤＵの最後のものは、ＡＲＱＳＤＵの最後のビットを搬送していないことが分かった場合に、そのヘッダ内にＬＩを含まないように構成され、他のすべてのＡＲＱＰＤＵがＡＲＱＳＤＵの最後のビットを搬送していなくても、ＬＩは、他のすべてのＡＲＱＰＤＵに追加される、ＨＡＲＱＰＤＵが提供される。

以下では、例示としてのみ、本発明を添付図面に関してさらに説明する。

ＬＴＥプロジェクトの３ＧＰＰ標準化においては、ＡＲＱフレームフォーマット及びＨＡＲＱフレームフォーマットへの検討がされてきた。しかしながら、このような検討は、それらのフレームフォーマットのデータスループットの取り扱いにおいて制限されている。

本発明は、データスループットを改善することによってこのような制限に対処しようとすると共に、このような改善を達成しようとするものであり、本発明は、各ＰＤＵ内のデータペイロード用のスペースの量をより多く残すために、ヘッダ情報が必要とするスペースを削減しようとするものである。

本発明の範囲内の主要な概念は、対象となっているＰＤＵ内でのＡＲＱＳＤＵの最後のビットが存在するとの判断に応じて、ＬＩヘッダフィールドの包含を制御することである。

このようにしてＬＩヘッダフィールドの存在を利用可能にすることを通じて、次に、ＬＩヘッダフィールドは、すべてのヘッダ内に包括的に含まれるのではなく、必要なときにのみヘッダに含まれることが分かる。

次に図１を参照して、ＡＲＱプロトコル及びＨＡＲＱプロトコルが、たとえばＭＡＣ E-node B 又はＭＡＣＵＥ内で共に機能する方法の概略図が提供されている。

図示するように、複数の論理チャネル１０を含むＭＡＣアーキテクチャ１０が提供されている。複数の論理チャネル１０は、優先度／スケジューリングコントローラ１６によって制御され、その後、マルチプレクサ１８に配信される複数のＡＲＱＰＤＵ１２、１４を提供する。

ＡＲＱＰＤＵは、マルチプレクサ１８によって結合されると、ＨＡＲＱＰＤＵ２０を形成する働きをする。ＨＡＲＱＰＤＵ２０は、トランスポートチャネル２２上へ配信される。

次に図２Ａ及び図２Ｂを参照して、ＡＲＱＰＤＵ及びＨＡＲＱＰＤＵの構造が示されている。

図２Ａに関しては、ＡＲＱＰＤＵ２４が示されている。ＡＲＱＰＤＵ２４は、さまざまなフィールドを有するヘッダ２６と、データペイロード２８を備える第２の部分とを含む。さまざまなフィールドに関しては、以下でさらに解説する。

図２Ｂに関して、ＨＡＲＱＰＤＵ構造は、もちろん、1つ又は複数のＡＲＱＰＤＵから形成され、したがって、複数のＡＲＱＰＤＵの各ヘッダフィールド３２を備えるＨＡＲＱＰＤＵ構造３０を含む。各ヘッダフィールド３２において、第１のヘッダフィールド３４は第１のＡＲＱＰＤＵに関係し、第２のヘッダフィールド３６は第２のＡＲＱＰＤＵフィールドに関係し、第３のヘッダフィールド３８は第３のＡＲＱＰＤＵフィールドに関係している。

ヘッダフィールドの後には、複数のＡＲＱＰＤＵデータペイロード４０が設けられている。このデータペイロード４０は、ヘッダ３２、３６、及び３８にそれぞれ関係する別個のペイロード４２、４４、及び４６を備える。図２Ｂ内のヘッダ３６、３８のそれぞれは、より詳細に示された第１のヘッダ３４の構造を共有する。図２Ａのヘッダ２６及び図２Ｂのヘッダ３２の異なるフィールドを以下でさらに解説する。

ＭＩＤフィールドは、ＬＴＥが、ＡＲＱＰＤＵの２つ以上のＩＰフローを１つのＨＡＲＱＰＤＵに多重化することを可能にする場合にのみ必要とされる。このフィールドは、一般に、４ビットの長さを有する。

ＳＮ（シーケンス番号）：暗号化（これを行うレイヤは、現在，ＬＴＥに関して定義されていない）中に使用される同じＳＮが、ＡＲＱ及びＨＡＲＱにおいて抽出及び再利用される。ＳＮフィールドは１２ビットの長さを有する。

ＳＬ（セグメント及びレングスインディケータ）：第１ビットは、セグメント情報（ＳＩ、ＬｏＳ、ＬＳＩ、及びＳＳＩ）の存在を示し、第２ビットはＬＩフィールドの存在を示す。ＳＬフィールドは２ビットの長さを有する。

ＳＩ（セグメントインデックス）：これは、ＡＲＱＳＤＵのセグメント番号の表示を提供し、４ビットの長さを有する。

ＬｏＳ（レベル・オブ・セグメンテーション）：レベル・オブ・セグメンテーションは、常にＳＩ又はＳＳＩに関連付けられている。ＬｏＳは、１ビットの長さを有し、送信される実際のセグメントが前のＳＩ／ＳＳＩフィールドによって示されるときは「０」に設定され、送信される実際のセグメントが前のＳＩ／ＳＳＩの部分セグメントであるときは「１」に設定される。実際のセグメントのＳＳＩは、この場合、次のフィールドにあるべきである。

ＳＳＩ（サブセグメントインディケータ）：再送が、前に送信された（ＡＲＱＳＤＵのセグメントである）ＡＲＱＰＤＵのセグメンテーションを必要とする場合、ＳＳＩはセグメント番号を示し、４ビットの長さを有する。

ＬＳＩ（ラストセグメントインディケータ）：このフィールドは、（「０」に設定されている）ＬｏＳフィールドの次にくる。また、このフィールドは、受信機が、ＰＤＵをＳＤＵに再組み立てするのを容易にすることができ、１ビットの長さを有する。セグメントが最後のセグメントである場合には、ＬＳＩは「１」に設定され、そうでない場合には、ＬＳＩは「０」に設定される。

ＬＩ（レングスインディケータ）：ＡＲＱＰＤＵの長さを示す。

もちろん、本発明に従って十分理解されるように、ＡＲＱＰＤＵがＡＲＱＳＤＵの最後のビットを搬送している場合に、ＬＩはそのＡＲＱＰＤＵに追加される。

さらに、異なるＡＲＱＳＤＵからのＡＲＱＰＤＵを１つのＨＡＲＱＰＤＵに連結する場合において、最後のＡＲＱＰＤＵがＡＲＱＳＤＵの最後のビットを搬送していないときは、ＬＩは、最後のＡＲＱＰＤＵを除くすべてのＡＲＱＰＤＵに追加される。もちろん、ＰＤＵが上述したいずれのカテゴリーにも入らない場合には、そのＰＤＵは、ＬＩフィールドを必要としない。ＬＩフィールドは、通常、１５ビット又は７ビットの長さを有する。

実際のＰＤＵのビット長＝（（ＬＩ＊８）−４）であり、これは、オクテット整列されていない１２ビットのＳＮがＳＤＵから抽出されて、ＳＮ、又はＡＲＱＰＤＵ及びＨＡＲＱＰＤＵとして使用されるためである。

Ｅ：１ビットの長さを有し、さらなるヘッダが存在する場合には「１」に設定され、そうでない場合には「０」に設定される拡張ビット。

本発明をさらに示すために、ヘッダの構成を以下に示す。この構成は、ＳＬフィールドの４つの値のそれぞれに関してのＳＩフィールド、ＬｏＳフィールド、ＳＳＩフィールド、ＬＳＩフィールド、及びＬＩフィールドの使用を示す働きをする。ＭＩＤビット、ＳＮビット、ＳＬビット、及びＥビットは、ヘッダのそれぞれに常に存在することが十分理解されるべきである。

ＳＬ：００
−ＳＩフィールド、ＬｏＳフィールド、ＳＳＩフィールド、ＬＳＩフィールド、及びＬＩフィールドは存在しない。

ＳＬ：０１
−ＬＩは存在する。
−ＳＩ、ＳＳＩ、ＬｏＳ、及びＬＳＩは存在しない。

ＳＬ：１０
−Ｌ１は存在しない
−以下のＡ及びＢを参照されたい。

ＳＬ：１１
−ＬＩは存在する。
−以下のＡ及びＢを参照されたい。

Ａ．ＡＲＱＳＤＵのセグメントであるＡＲＱＰＤＵの最初の送信である場合
−ＳＩは存在する
−ＬｏＳ＝０
−ＬＳＩはＬｏＳフィールドの次にくる
−セグメントレベル＝１
Ｂ．再送である場合
−前に送信されたＡＲＱＰＤＵがこの送信でさらにセグメント化されている場合
−セグメントレベル＝セグメントレベル＋１
−前に送信されたＡＲＱＰＤＵがセグメント化されていない場合
−セグメントレベル＝セグメントレベル
−ＳＩは存在する
−ＬｏＳの個数＝セグメントレベル、ＬｏＳ（１）からＬｏＳ（セグメントレベル−１）＝１、且つ、ＬｏＳ（セグメントレベル）＝０
−ＳＳＩの個数＝セグメントレベル−１
−ＬＳＩはＬｏＳ（セグメントレベル）の次にくる

本発明の方法の一実施形態を、図３を参照して以下でさらに示す。図３は、ＬＩフィールドがヘッダにいつどのように追加されるのかを示す働きをするフローチャートを含む。

各ＡＲＱＰＤＵ４８に関して、図３を参照して、５０において、そのＡＲＱＰＤＵがＡＲＱＳＤＵの最後のビットを搬送しているか否かが判断される。

上述したように、ＡＲＱＳＤＵを表すのに複数のＡＲＱＰＤＵを設けることもできるし、単一のＡＲＱＰＤＵが単一のＡＲＱＳＤＵを表すこともできる。

ステップ５０において、ＡＲＱＰＤＵがＡＲＱＳＤＵの最後のビットを搬送していると判断された場合には、この方法はステップ５２に進み、ステップ５２において、ＬＩがヘッダ内に含まれるべきであると判断される。

一方、ステップ５０において、ＡＲＱＰＤＵが、ＡＲＱＳＤＵの最後のビットを搬送していないと判断された場合には、この方法はステップ５４に進み、ステップ５４において、対象となっているＡＲＱＰＤＵが、ＨＡＲＱＰＤＵ内の複数の連結されているＡＲＱＰＤＵうちのの１つであるか否かが判断される。

ステップ５４において、ＡＲＱＰＤＵが、ＨＡＲＱＰＤＵ内のこのような複数の連結されているＡＲＱＰＤＵのうちの１つであると判断された場合には、この方法はステップ５６に進み、ステップ５６において、対象となっているＡＲＱＰＤＵが、ＨＡＲＱＰＤＵ内の最後のものであるか否かが判断される。

ステップ５６において、ＡＲＱＰＤＵが、ＨＡＲＱＰＤＵの最後のものでないと判断された場合には、この方法はステップ５２に進み、ステップ５２において、ＬＩがヘッダ内に含まれるべきであると判断される。

ステップ５４において、ＡＲＱＰＤＵが、ＨＡＲＱＰＤＵ内で他のＡＲＱＰＤＵと連結されていないと判断された場合、又は、ステップ５６において、ＡＲＱＰＤＵがＨＡＲＱＰＤＵ内の最後のものであると判断された場合には、この方法はステップ５８に進み、ステップ５８において、ＬＩがヘッダ内に含まれる必要がないと判断される。

さらなる説明として、次に、異なるシナリオを以下で解説する。これらの異なるシナリオは、本発明に従って生じるフレームフォーマットを使用することができる方法を示す働きをする。

第１のシナリオは、おそらく最も一般的な場合を含み、メッセージヘッダをどのように削減することができるのかに関しての明確な表示を提供する。

ＡＲＱＳＤＵ（１つの音声フレームを含むＲＯＨＣ圧縮されたＩＰｖ６）サイズ＝６
（ＲＯＨＣヘッダ）＋３２（ＡＭＲＲＴＰペイロード）＝３８バイト＝３０４ビット
時間間隔：２０ｍｓごとに１つのＳＤＵ
ＡＲＱＢＬＥＲ＝０％
ＨＡＲＱＢＬＥＲ＝１０％
ＨＡＲＱＰＤＵサイズ＝１０４ビット

送信されるＡＲＱデータ＝ＡＲＱＳＤＵ−ＡＲＱＳＮ＝２９２ビット
第１のＨＡＲＱＰＤＵ、第２のＨＡＲＱＰＤＵ、及び第３のＨＡＲＱＰＤＵのヘッダサイズ＝２４及び送信される実際のＡＲＱデータ＝８０ビット
第４のＨＡＲＱＰＤＵのヘッダサイズ＝３２ビット及び送信される実際のＡＲＱデータ＝５２ビット
ＳＤＵは、４つのＨＡＲＱＰＤＵにセグメント化される必要がある。

図４Ａ及び図４Ｂを参照して、この第１のシナリオに従って生じる４つのＨＡＲＱＰＤＵの構造の説明図が提供されている。

図４Ａは、ＬＩフィールドが必要とされないことが十分理解される第１のＨＡＲＱＰＤＵから第３のＨＡＲＱＰＤＵのフォーマットを示している。

一方、図４Ｂに関しては、第４のＨＡＲＱＰＤＵが示されている。この第４のＨＡＲＱＰＤＵは、そのヘッダ内にＬＩフィールドを含む。

以下の比較を通じて、本発明が、ＡＲＱの現在の状態と比較して有利な性能をどのように提供することができるのかを容易に理解することができる。

１つのＡＲＱＰＤＵ当たりのヘッダのビット数に関して、現在の技術では３２ビットが必要とされるのに対して、本発明では、第１のＨＡＲＱＰＤＵ、第２のＨＡＲＱＰＤＵ、及び第３のＨＡＲＱＰＤＵに関しては２４ビットが必要とされ、第４のＨＡＲＱＰＤＵに関しては３２ビットが必要とされる。

１つのＡＲＱＳＤＵを送信するのに必要なＰＤＵの総数は、現在の技術では５つであるのに対して、本発明に関して計算した場合には４つのみである。

現在の技術では、ヘッダの全オーバーヘッドは、約１６０であるのに対して、本発明では、この数字は、ほぼ１０４ビット程度に削減される。

現在の技術では、全データとＨＡＲＱヘッダとの組み合わせから生じる全ビット数は４５２（２９２＋１６０）であり、本発明では３９６（２９２＋１０４）である。

帯域幅の値に関して、現在の技術は、２６．２６ｋｂｐｓの帯域幅を占有するのが分かるのに対して、本発明では、ほぼ２１．００８ｋｂｐｓ程度の帯域幅が占有される。

次に図５Ａ及び図５Ｂを参照して、これらの図は、ＡＲＱＳＤＵセグメントの再送を伴うさらなるシナリオのＨＡＲＱＰＤＵ構造を示している。このＨＡＲＱＰＤＵ構造では、ＨＡＲＱＰＤＵサイズは、さらなるセグメント化を必要とするために、元のＡＲＱＰＤＵを単一のＨＡＲＱＰＤＵ内でもはや送信することができないように変更されている。すなわち、ＨＡＲＱＰＤＵサイズは、ほぼ８０ビット程度であり、このサイズは元のＰＤＵを収容することができないため、セグメンテーションが必要とされる。

このようにして、ＡＲＱＰＤＵ−１は、４８ビットのデータを有する３２ビットのヘッダの部分セグメントを備えるのに対して、ＡＲＱＰＤＵ−２は、サイズが４０ビットのヘッダを有する第２の部分セグメントを備える一方、送信される実際のデータは２８ビットを備える。

図５Ａは、第１の部分セグメントのＨＡＲＱＰＤＵを示している。このＨＡＲＱＰＤＵは、上述した寸法のヘッダ部６８及びデータペイロード部７０を含む。これに対して、図５Ｂは、特にＬＩを含むヘッダ７２を有し、また、データペイロード７４も含み、且つ、上述したようなビット数を備える第２の部分セグメントのＨＡＲＱＰＤＵを示している。十分に理解されるように、ＨＡＲＱＰＤＵは、第２のセグメントによって完全に満たされず、送信するデータがそれ以上ないため、いくらかの追加が必要とされる可能性があり、このような理由から、ＬＩは実際のデータが終了する箇所を示す目的を果たし、パディングが開始する。

もちろん、上述したパディングを使用する代わりに、ＨＡＲＱは、利用可能な空きスペースを他の任意の目的で使用することができることが十分理解される。

この第２のシナリオでは、占有された帯域幅は、現在の技術で経験したものと同じであることが十分理解されるべきである。

第３のシナリオに関して、異なるＡＲＱエンティティからのデータを単一のＨＡＲＱＰＤＵに多重化することが示されている。しかしながら、簡単にするために、関連のあるビット数は、図には示されていない。

したがって、図６に関しては、第１のＡＲＱＰＤＵ８２及び第２のＡＲＱＰＤＵ８４にセグメント化されたＡＲＱＳＤＵ８０を備える第１のデータフロー７８と、単一のＡＲＱＰＤＵ９０になるＡＲＱＳＤＵ８８を備える第２のフロー８６との多重化が示されている。

ＨＡＲＱＰＤＵは多重化されると、ヘッダ領域９２及びＰＤＵペイロードデータ９４で示されるように、２つのＡＲＱＳＤＵ８０、８８を収容する。

第４のシナリオに関して、ＨＡＲＱＰＤＵサイズは、第３のＨＡＲＱＰＤＵの時点で変化するように構成される。この第３のＨＡＲＱＰＤＵは、ＳＤＵ送信の中間で起こる。

ここで図７を参照する。図７は、ＡＲＱＳＤＵ９６、ＡＲＱＰＤＵ９８、及びＨＡＲＱＰＤＵ１００を示している。

第１のシナリオで生じた値のような対応する値がここで使用され、主要な相違は、１つのＡＲＱＳＤＵ及び５つのＨＡＲＱＰＤＵを送信するために、ＨＡＲＱＰＤＵサイズが第３のＨＡＲＱＰＤＵで変更されるということであることが十分理解されるべきである。

ＡＲＱＰＤＵ内に示すように、ＡＲＱヘッダ及びＳＤＵデータのサイズは、第３のＨＡＲＱＰＤＵまで９５ビットであり、第３のＨＡＲＱＰＤＵの時点で、サイズは７５ビットに変化する。

それに対して、ＨＡＲＱＰＤＵ１００に関しては、ここでのサイズは、第３のＨＡＲＱＰＤＵの時点で８０ビットに削減するまで、１００ビットである。

このように、上述した４つのシナリオから、送信速度及びネットワーク資源の効率的な使用に関して、本発明が現在の技術と比較してどれだけ好ましいかを十分理解することができ、さらに、ＡＲＱＳＤＵ送信の完了前にＨＡＲＱＰＤＵサイズに変更がある場合に、再セグメント化又は連結の必要性をどのようになくすことができるのかを十分理解することができる。

より高速且つより効率的なデータスループットを提供するＡＲＱＰＤＵ及びＨＡＲＱＰＤＵのフォーマットの提供を通じて、ＡＲＱプロトコル及びＨＡＲＱプロトコルを共に単一の物理エンティティ内に入れる可能性が、３ＧＰＰＬＴＥ送信の全体的な遅延を削減するために、好都合に実現される。

ＡＲＱプロトコル及びＨＡＲＱプロトコルを有するＭＡＣアーキテクチャの概略図である。ＡＲＱＰＤＵのＰＤＵフレーム構造フォーマットを示す図である。ＨＡＲＱＰＤＵのＰＤＵフレーム構造フォーマットを示す図である。本発明の一実施形態による長さ指示子フィールドの追加又は省略の方法を示すフロー図である。本発明の一実施形態に従って生じるＨＡＲＱＰＤＵの構造を示す図である。本発明の一実施形態に従って生じるＨＡＲＱＰＤＵの構造を示す図である。本発明の別の実施形態に従って生じるＨＡＲＱＰＤＵの構造を示す図である。本発明の別の実施形態に従って生じるＨＡＲＱＰＤＵの構造を示す図である。異なるＡＲＱエンティティからのＡＲＱＰＤＵの多重化によるＨＡＲＱＰＤＵの構造及び形成を示す図である。ＡＲＱＳＤＵからのＨＡＲＱＰＤＵ及びＡＲＱＰＤＵの形成の説明図である。

Claims

ＡＲＱＳＤＵから少なくとも１つのＡＲＱＰＤＵを形成する方法であって、該ＡＲＱＰＤＵはＡＲＱヘッダとデータ部とを備え、該方法は、ＡＲＱＳＤＵの最後のビットが前記ＰＤＵに存在するとの判断に応じて、レングスインディケータ（ＬＩ）フィールドを前記ＡＲＱヘッダに選択的に追加するステップを含む方法であって、
異なるＳＤＵからの複数のＡＲＱＰＤＵが１つのＨＡＲＱＰＤＵに形成される場合において、最後のＡＲＱＰＤＵが前記ＡＲＱＳＤＵの最後のビットを搬送していないことが分かった場合に、前記ＬＩフィールドは前記最後のＡＲＱＰＤＵに含まれず、他のすべてのＡＲＱＰＤＵが前記ＡＲＱＳＤＵの最後のビットを搬送していなくても、前記ＬＩフィールドは、前記他のすべてのＡＲＱＰＤＵに追加されることを特徴とする方法。
前記ＡＲＱＰＤＵが前記ＡＲＱＳＤＵの最後のビットを搬送していないと判断された場合に、前記方法は、異なるＳＤＵからの複数のＰＤＵが、共通のＨＡＲＱＰＤＵに形成されるか否かを判断するステップを含む、請求項１に記載の方法。
前記ＬＩフィールドの存在は、前記ＡＲＱヘッダのセグメント及びレングスフィールドによって示される、請求項１又は２に記載の方法。
１つのＡＲＱＰＤＵ当たり１つの最後セグメント指示子のみを設けるステップを含む、請求項１〜３のいずれか１項に記載の方法。