JP5172957B2 - ユニキャスト送信およびマルチキャスト送信のための再送プロトコルの軟バッファ管理 - Google Patents

Description

本発明は、軟合成（soft-combining）を用いる再送プロトコルを使用するときに、無線制御エンティティと移動局との間でデータパケットを送信する方法に関する。詳細には、本発明は、ユニキャスト送信およびマルチキャスト送信において、軟合成を用いる再送プロトコルを同時に使用できるようにするためのさまざまな方法ステップを提供する。さらに、本発明は、本発明に関与する無線制御エンティティおよび移動ノードに関する。

Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access：広帯域符号分割多元接続）は、第３世代のワイヤレス移動通信システムとして使用する目的で標準化されたＩＭＴ−２０００システム（International Mobile Telecommunication system：国際移動通信システム）の無線インタフェースである。Ｗ−ＣＤＭＡは、音声サービスやマルチメディア移動通信サービスといったさまざまなサービスをフレキシブルかつ効率的に提供する。日本、欧州、米国、およびその他の国における標準化機関は、Ｗ−ＣＤＭＡの共通の無線インタフェース仕様を策定する目的で、３ＧＰＰ（第３世代パートナーシッププロジェクト）と呼ばれるプロジェクトを共同して組織した。

ＩＭＴ−２０００の欧州における標準化バージョンは、一般にＵＭＴＳ（Universal Mobile Telecommunication System：ユニバーサル移動通信システム）と呼ばれている。ＵＭＴＳ仕様の最初のリリースは、１９９９年に公開された（リリース９９）。その後、３ＧＰＰにより、リリース４、リリース５、リリース６において、この標準に対するいくつかの改良が標準化された。

この技術を機能強化あるいは進化・発展させるうえでの最初のステップは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）と、エンハンストアップリンク（高速アップリンクパケットアクセス（ＨＳＵＰＡ）とも称する）とを導入することであり、これにより、極めて競争力の高い無線アクセス技術が提供される。

しかしながら、３ＧＰＰは、ユーザおよび事業者からの要求条件や期待がますます増大していることを認識し、３Ｇの長期にわたる競争力を確保するため、３Ｇ標準規格の次の大きなステップまたは進化・発展を考慮し始めている。

３ＧＰＰは、最近、「Evolved UTRA and UTRAN（Ｅ−ＵＴＲＡおよびＵＴＲＡＮ）」という研究項目（一般には「ロングタームエボリューション（ＬＴＥ：Long Term Evolution）」として公知である）に着手した。この研究では、サービスの提供を向上させることと、ユーザおよび事業者側のコストを低減することとを目的として、パフォーマンスの大幅な向上を達成する手段が検討される。一般には、移動制御にはインターネットプロトコル（ＩＰ）を使用し、将来的なサービスすべてがＩＰベースであるものと想定している。したがって、進化の中心的な課題は、従来のＵＭＴＳシステムのパケット交換（ＰＳ）ドメインの機能強化である。

今回の進化の主たる目的は、前述したように、サービスの提供をさらに向上させることと、ユーザおよび事業者側のコストを低減することである。より具体的には、ロングタームエボリューション（ＬＴＥ）における、いくつかの重要なパフォーマンス、能力、および配備上の要求条件は、特に、以下のとおりである。
・ ＨＳＤＰＡおよびＨＳＵＰＡと比較して、データレートが大幅に高いこと（想定されている目標のピークデータレートは、ダウンリンクが１００Ｍｂｐｓ以上、アップリンクが５０Ｍｂｐｓ以上である）
・ 平均ユーザスループットが、アップリンク（ＵＬ）において２倍、ダウンリンク（ＤＬ）において３倍に向上すること
・ データレートが高く、エリアカバレッジが広いこと
・ セル周縁部のユーザスループットが、アップリンクおよびダウンリンクにおいて２倍に向上すること
・ スペクトル効率が、アップリンクにおいて２倍、ダウンリンクにおいて３倍に向上すること
・ 上位層プロトコル（例えばＴＣＰ）のパフォーマンスを向上させることと、制御プレーン手順（例えばセッションの確立）に関連付けられる遅延を低減することとを目的として、ユーザプレーンにおけるレイテンシーを大幅に低減すること
・ １．２５ＭＨｚ〜２０ＭＨｚの範囲のさまざまなサイズのスペクトル割り当てにおいてスタンドアロンシステムとして動作すること

ロングタームエボリューションの検討において、配備に関連するさらなる１つの要求条件は、これらの技術になめらかに移行できることである。

高いビットレートを提供できる能力は、ＬＴＥの重要な条件である。そのための１つの重要な要素は、多入力多出力（ＭＩＭＯ）技術を使用して複数の並列するデータストリームを１つの端末に送信することである。使用する無線アクセス技術を決定するときに考慮すべき別の要素は、より大きな送信帯域幅と、それと同時に柔軟なスペクトル割り当てである。適応的な多層ＯＦＤＭ（Orthogonal Frequency Division Multiplexing：直交周波数分割多重）、すなわち適応多層（ＡＭＬ）−ＯＦＤＭをダウンリンクに選択すると、一般的には、異なる帯域幅における動作のみならず、特に高いデータレートのための大きな帯域幅における動作も容易になる。スペクトル割り当てを１．２５ＭＨｚ〜２０ＭＨｚの範囲内で変化させることが、対応する数のＡＭＬ−ＯＦＤＭサブキャリアを割り当てることによってサポートされる。時分割複信および周波数分割複信の両方がＡＭＬ−ＯＦＤＭによってサポートされるため、ペアスペクトルおよび非ペアスペクトル（paired and unpaired spectrum）の両方における動作が可能である。

周波数領域の適合化を備えたＯＦＤＭ
ＡＭＬ−ＯＦＤＭベースのダウンリンクは、１５ｋＨｚ間隔の多数の個々のサブキャリアに基づく周波数構造を有する。この周波数間隔では、ＵＴＲＡ／Ｅ−ＵＴＲＡのデュアルモード端末を容易に実施することができる。高いビットレートに達する能力は、システムにおける遅延が短いことに大きく依存し、そのための必要条件は、サブフレームの持続時間が短いことである。結果として、ＬＴＥのサブフレームの持続時間は、無線インタフェースのレイテンシを最小にする目的で、１ｍｓという短い値に設定されている。適度なオーバーヘッドを伴う異なる遅延拡散および対応するセルサイズを扱う目的で、ＯＦＤＭのサイクリックプレフィックス長は２つの異なる値をとることができる。ユニキャストのほとんどのシナリオにおいては、遅延拡散を扱うのに、短い方のサイクリックプレフィックスである４．７ｍｓで十分である。長い方のサイクリックプレフィックスである１６．７ｍｓを使用すると、大きな時間分散を伴う極めて大きなセル（セル半径１２０ｋｍまで、またはそれ以上）を扱うことができる。この場合、長さは、サブフレームにおけるＯＦＤＭシンボルの数を低減することによって延ばされる。

直交周波数分割多重（ＯＦＤＭ）の基本的な原理は、周波数帯域を複数の狭帯域チャネルに分割することである。したがって、ＯＦＤＭにおいては、マルチパス環境に起因して周波数帯域全体のチャネルが周波数選択性である場合にも、比較的フラットな並列チャネル（サブキャリア）においてデータを送信することができる。サブキャリアごとにチャネル状態が異なるため、サブキャリアの容量は変化し、サブキャリアごとに異なるデータレートにおいて送信することができる。したがって、適応変調符号化（ＡＭＣ：Adaptive Modulation and Coding）を用いての、サブキャリアごとの（周波数領域）リンクアダプテーション（ＬＡ：Link Adaptation）によって、サブキャリアを通じてさまざまなデータレートで送信することにより無線効率が高まる。

ＯＦＤＭＡでは、複数のユーザがＯＦＤＭシンボルあたり複数の異なるサブキャリア上で同時に送信することができる。特定のサブキャリアについて、すべてのユーザにおいて深いフェージングが発生する確率は極めて低いため、あるサブキャリアに対応するチャネル利得が良好であるユーザに、そのサブキャリアを割り当てるようにすることができる。スケジューラは、ダウンリンクのリソースをセル内の複数の異なるユーザに割り当てるとき、サブキャリアに対するユーザ側のチャネル状態に関する情報を考慮する。スケジューラは、ユーザによってシグナリングされる制御情報（すなわちＣＱＩ）によってマルチユーザダイバーシチを利用することができ、これによってスペクトル効率が高まる。

ＯＦＤＭＡにおけるように利用可能な周波数スペクトルを複数の異なるユーザの間で分配する無線アクセス方式を考慮するときには、２つの異なるリソース割り当て方法を区別することができる。第１の割り当てモードまたは「局在型」モード（localized mode）では、ＵＥには、そのＵＥまでの無線チャネル条件が最良であるサブキャリアを割り当てることによって、周波数スケジューリングの利得の恩恵を完全に受けることをめざす。このスケジューリングモードでは、関連するシグナリング（リソース割り当てシグナリング、アップリンクにおけるＣＱＩ）が要求されるため、このモードは、高いデータレートが重要である非リアルタイムのサービスに最も適している。この局在型リソース割り当てモードにおいては、サブキャリアの連続するブロックがユーザに割り当てられる。

第２のリソース割り当てモードまたは「分散型モード」は、時間・周波数グリッド上に散在するリソースを割り当てることによって、周波数ダイバーシチ効果に依存して送信の堅牢性を達成する。局在型モードとの基本的な違いとして、このリソース割り当てアルゴリズムは、受信側における受信品質に関する何らかの情報に基づいて物理リソースを割り当てることを試みるのではなく、特定のＵＥに割り当てるリソースを多かれ少なかれランダムに選択する。この分散型リソース割り当て方法は、要求される関連するシグナリングが「局在型モード」よりも少ないため（迅速なＣＱＩが不要、迅速な割り当てシグナリングが不要）、リアルタイムのサービスに最も適していると考えられる。

図１は、ＯＦＤＭＡベースの無線アクセス方式のための２つの異なるリソース割り当て方法を示している。この図の左側の部分（局在型送信モードを示している）から理解できるように、局在型モードは、送信される信号が、利用可能な全スペクトルの一部を占有する連続的なスペクトルを有することを特徴としている。送信される信号のシンボルレートが異なる（すなわちデータレートが異なる）ことは、局在化された信号の帯域幅（時間ビン／周波数ビン）が異なることを意味する。その一方で、この図の右側の部分から理解できるように、分散型モードは、送信される信号が、システムの帯域幅（時間ビン／周波数ビン）全体に多かれ少なかれ分散している不連続なスペクトルを有することを特徴としている。

Ｅ−ＭＢＭＳ
以下では、本発明の実施形態を適用することのできる例示的なマルチキャストサービスについて簡潔に説明する。前述したように、このようなマルチキャストサービスは、マルチキャストブロードキャストマルチメディアサービス（ＭＢＭＳ）とすることができる。

ＭＢＭＳは、ＬＴＥ仕様の最初のバージョンからサポートされる。しかしながら、Ｅ−ＭＢＭＳの仕様は初期段階にある。Ｅ−ＭＢＭＳに関して２つの重要なシナリオが認識されている。１つのシナリオは単一セルブロードキャストであり、もう１つのシナリオは、ＭＢＭＳ単一周波数ネットワーク（ＭＢＳＦＮ）である。

ＭＢＳＦＮは、ＬＴＥの仕様において導入された新しい機能である。ＭＢＳＦＮは、移動体テレビなどのサービスをＬＴＥのインフラストラクチャを使用して配信するように想定されており、ＤＶＢ−Ｈベースのテレビ放送の競合相手になるものと予測されている。ＭＢＳＦＮにおいては、時刻同期している一連のｅＮＢから、同じリソースブロックを使用して送信が行われる。これにより、Ｏｖｅｒ−ｔｈｅ−Ａｉｒ（ＯＴＡ）合成が可能となり、したがって、非ＳＦＮ動作と比較して信号対干渉雑音比（ＳＩＮＲ）が大幅に改善される。ＭＢＳＦＮにおいて使用されるサイクリックプレフィックス（ＣＰ）はわずかに長く、これにより、ＵＥは複数の異なるｅＮＢからの送信を合成することができ、したがって、ＳＦＮ動作のいくつかの利点はいくらか打ち消される。ＭＢＳＦＮ動作においては０．５ｍｓのスロットに６個のシンボルが存在するのに対して、非ＳＦＮ動作においては０．５ｍｓのスロットに７個のシンボルが存在する。

図８は、ＭＢＳＦＮ動作における全体的なユーザプレーンアーキテクチャを示している。すべてのｅＮＢから同じ情報内容がＯｖｅｒ−ｔｈｅ−Ａｉｒ送信されるようにするため、３ＧＰＰによって、Ｅ−ＭＢＭＳゲートウェイとｅＮＢとの間にＳＹＮＣプロトコルが定義された。図８に示したように、ｅＢＭ−ＳＣはＭＢＭＳトラフィックの送信元であり、Ｅ−ＭＢＭＳゲートウェイは、ＭＢＳＦＮエリアの複数の異なるｅＮＢにトラフィックを配信する役割を担う。Ｅ−ＭＢＭＳゲートウェイから複数の異なるｅＮＢにトラフィックを配信するには、ＩＰマルチキャストを使用することができる。１つのサービスに対して、１つのＭＢＳＦＮエリアのすべてのｅＮＢに同じリソースブロックが割り当てられるようにする、ＭＢＭＳコーディネーションエンティティ（ＭＣＥ：MBMS Coordination Entity）として知られる制御プレーンエンティティが、３ＧＰＰによって定義された。ＭＣＥの役割は、ｅＮＢにおけるＲＬＣ／ＭＡＣ層がＭＢＳＦＮ動作用に適切に構成・設定されるようにすることである。現在のところ３ＧＰＰでは、ＭＢＭＳサービスのヘッダー圧縮をＥ−ＭＢＭＳゲートウェイによって実行することを想定している。単一セルＭＢＭＳおよびＭＢＳＦＮのいずれも、一般にはポイントツーマルチポイント送信モードを使用する。

しかしながら、ＨＡＲＱ動作がサポートされるのは、おそらくは単一セルＭＢＭＳ送信の場合のみとなるであろう。

Ｅ−ＭＢＭＳについては、以下の定義が導入されている。図９は、新しいＭＢＭＳの定義を示している。
− ＭＢＳＦＮ同期エリア（MBSFN Synchronization Area）：すべてのＮｏｄｅＢ／ｅＮｏｄｅＢを同期させてＭＢＳＦＮ送信を実行することのできるネットワークエリア。ＭＢＳＦＮ同期エリアは、１つまたは複数のＭＢＳＦＮエリアをサポートすることができる。特定の周波数層において、ＮｏｄｅＢ／ｅＮｏｄｅＢは１つのＭＢＳＦＮ同期エリアのみに属することができる。ＭＢＳＦＮ同期エリアは、ＭＢＭＳサービスエリアの定義とは独立している。
− ＭＢＳＦＮ送信またはＭＢＳＦＮモードにおける送信（MBSFN Transmission or a transmission in MBSFN mode）：複数のセルから同じ波形を同時に送信することによって実現される同時送信技術。ＭＢＳＦＮエリア内の複数のセルからのＭＢＳＦＮ送信は、ＵＥからは１回の送信として認識される。
− ＭＢＳＦＮエリア（MBSFN Area）：ＭＢＳＦＮエリアは、ＭＢＳＦＮ送信を達成するように協働する、ネットワークのＭＢＳＦＮ同期エリア内のセルのグループから成る。ＭＢＳＦＮ同期エリア内の１つのセルは、複数のＭＢＳＦＮエリア（それぞれが異なる送信コンテンツおよび関与するセルのグループによって特徴付けられる）に属することができる。
− ＭＢＳＦＮエリア送信・アドバタイジングセル（MBSFN Area Transmitting and Advertising Cell）：ＭＢＳＦＮエリア内のセルのうち、ＭＢＳＦＮ送信に参加しており、ＭＢＳＦＮ送信が利用可能であることをセル内でアドバタイズするセル。
− ＭＢＳＦＮエリア送信専用セル（MBSFN Area Transmitting-Only Cell）：ＭＢＳＦＮエリア内のセルのうち、ＭＢＳＦＮ送信に参加しているが、ＭＢＳＦＮ送信が利用可能であることをセル内でアドバタイズしないセル。このタイプのセルが要求されるのはＦＦＳである。
− ＭＢＳＦＮエリア予備セル（MBSFN Area Reserved Cell）：ＭＢＳＦＮエリア内のセルのうち、ＭＢＳＦＮ送信に参加しないセル。このセルは、別のサービスのための送信を行えるようにできるが、出力が制限され、セルの中心におけるユーザに対するＭＢＳＦＮ送信（例：ポイントツーポイント）のためのリソースがユーザに割り当てられる。

ＬＴＥのアーキテクチャ
図２は、全体的なアーキテクチャを示しており、図３は、Ｅ−ＵＴＲＡＮアーキテクチャをさらに詳しく示している。Ｅ−ＵＴＲＡＮは、ｅＮｏｄｅＢ（ｅＮＢ）によって構成され、このｅＮＢは、移動ノード（以下ではＵＥまたはＭＮと称する）へのＥ−ＵＴＲＡユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）プロトコルおよび制御プレーン（ＲＲＣ）プロトコルの終端を提供する。

ｅＮＢは、物理（ＰＨＹ）層、媒体アクセス制御（ＭＡＣ）層、無線リンク制御（ＲＬＣ）層、およびパケットデータ制御プロトコル（ＰＤＣＰ）層（ユーザプレーンのヘッダー圧縮および暗号化の機能を含んでいる）をホストする。さらに、ｅＮＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ）機能も提供する。さらに、ｅＮＢは、無線リソース管理、アドミッション制御、スケジューリング、交渉されたＵＬ−ＱｏＳ（サービス品質）の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化／復号、ＤＬ／ＵＬユーザプレーンパケットヘッダーの圧縮／復元といった多数の機能を実行する。ｅＮＢは、Ｘ２インタフェースによって互いに相互接続されている。また、ｅＮＢは、Ｓ１インタフェースによってＥＰＣ（Evolved Packet Core）に接続されており、より具体的には、Ｓ１−ＭＭＥによってＭＭＥ（移動管理エンティティ：Mobility Management Entity）に接続されており、Ｓ１−Ｕによってサービングゲートウェイ（Ｓ−ＧＷ：Serving Gateway）に接続されている。Ｓ１インタフェースは、ＭＭＥ／サービングゲートウェイとｅＮＢとの間の多対多関係をサポートする。

Ｓ−ＧＷは、ユーザデータパケットのルーティングおよび転送を行う一方で、ｅＮＢ間ハンドオーバー時にユーザプレーンのモビリティアンカー（mobility anchor）としての役割と、ＬＴＥとそれ以外の３ＧＰＰ技術との間のモビリティのためのアンカーとしての役割も果たす（Ｓ４インタフェースを終端し、２Ｇ／３Ｇシステムとパケットデータネットワークゲートウェイとの間でトラフィックを中継する）。Ｓ−ＧＷは、アイドル状態のＵＥに対しては、そのＵＥへのＤＬデータが到着したときＤＬデータ経路の終端となりページングをトリガーする。Ｓ−ＧＷは、ＵＥコンテキスト（例えば、ＩＰベアラサービスのパラメータ、ネットワーク内部ルーティング情報）を管理および格納する。さらに、Ｓ−ＧＷは、合法傍受（lawful interception）の場合におけるユーザトラフィックの複製も実行する。

ＭＭＥは、ＬＴＥのアクセスネットワークの主要な制御ノードである。ＭＭＥは、アイドルモードのＵＥの追跡・ページング手順（再送信を含む）の役割を担う。ＭＭＥは、ベアラの有効化／無効化プロセスに関与し、さらには、最初のアタッチ時と、コアネットワーク（ＣＮ）ノードの再配置を伴うＬＴＥ内ハンドオーバー時とに、ＵＥのＳ−ＧＷを選択する役割も担う。ＭＭＥは、（ホーム加入者サーバ（ＨＳＳ：Home Subscriber Server）と対話することによって）ユーザを認証する役割を担う。非アクセス階層（ＮＡＳ：Non-Access Stratum）シグナリングはＭＭＥを終端とし、ＭＭＥは、一時的なＩＤを生成してＵＥに割り当てる役割も担う。ＭＭＥは、サービスプロバイダの公衆陸上移動網（ＰＬＭＮ：Public Land Mobile Network）に入るためのＵＥの認証をチェックし、ＵＥのローミング制限を実施する。ＭＭＥは、ＮＡＳシグナリングの暗号化／整合性保護においてネットワーク内の終端点であり、セキュリティキー管理を処理する。シグナリングの合法傍受も、ＭＭＥによってサポートされる。さらに、ＭＭＥは、ＬＴＥのアクセスネットワークと２Ｇ／３Ｇのアクセスネットワークとの間のモビリティのための制御プレーン機能と、ＳＧＳＮからＭＭＥを終端とするＳ３インタフェースとを提供する。さらに、ＭＭＥは、ローミングするＵＥのためのホームＨＳＳへのＳ６ａインタフェースを終端する。

第１層／第２層制御シグナリング
スケジューリングされたユーザに、その割り当てステータス、トランスポートフォーマット、およびその他のデータ関連情報（例：ＨＡＲＱ）を知らせる目的で、第１層／第２層制御シグナリングをデータと一緒にダウンリンク上で送信する必要がある。制御シグナリングは、サブフレームにおいてダウンリンクデータと一緒に多重化する必要がある（ユーザ割り当てがサブフレーム単位で変化しうるものと想定する）。ここで留意すべき点として、ユーザ割り当てはＴＴＩ（送信時間間隔）ベースで実行されることもあり、その場合、ＴＴＩ長はサブフレームの倍数である。ＴＴＩ長は、サービスエリアにおいてすべてのユーザについて一定とする、ユーザごとに異なる長さをとりうる、あるいは、ユーザごとに動的な長さとすることもできる。一般的には、第１層／第２層制御シグナリングをＴＴＩごとに１回送信するのみでよい。しかしながら、場合によっては、信頼性を高める目的でＴＴＩ内で第１層／第２層制御シグナリングを繰り返すことが適切なことがある。

一般的には、第１層／第２層制御シグナリングにおいて送られる情報は、以下の２つのカテゴリに分けることができる。
． カテゴリ１の情報を伝える共有制御情報（ＳＣＩ：Shared Control Information）。第１層／第２層制御シグナリングのＳＣＩ部分は、リソース割り当て（指示）に関連する情報を含んでいる。ＳＣＩは、一般には以下の情報を含んでいる。
− ユーザＩＤ：割り当てる対象のユーザを示している。
− ＲＢ割り当て情報：ユーザに割り当てられるリソース（リソースブロック：ＲＢ）を示している。なお、ユーザに割り当てられるＲＢの数は動的とすることができる。
− 割り当ての持続時間（オプション）：複数のサブフレーム（またはＴＴＩ）にわたる割り当てが可能である場合。

他のチャネルの設定および個別制御情報（ＤＣＩ：Dedicated Control Information）の設定に応じて、ＳＣＩは、アップリンク送信に対するＡＣＫ／ＮＡＣＫ、アップリングスケジューリング情報、ＤＣＩに関する情報（例：リソース、ＭＣＳ）などの情報を、さらに含んでいることができる。

・ カテゴリ２／カテゴリ３の情報を伝える個別制御情報（ＤＣＩ）：第１層／第２層制御シグナリングのＤＣＩ部分は、カテゴリ１によって示されるスケジューリングされたユーザに送信されるデータの送信フォーマットに関連する（カテゴリ２）情報を含んでいる。さらに、（ハイブリッド）ＡＲＱを適用する場合、ＤＣＩ部分はＨＡＲＱ（カテゴリ３）情報を伝える。ＤＣＩは、カテゴリ１によるスケジューリング対象ユーザによって復号されるのみでよい。ＤＣＩは、一般には以下に関する情報を含んでいる。
− カテゴリ２：変調方式、トランスポートブロック（ペイロード）サイズ（または符号化レート）、ＭＩＭＯ関連情報など
− カテゴリ３：ＨＡＲＱ関連情報（例えば、ハイブリッドＡＲＱプロセス番号、冗長性バージョン、再送連続番号

ハイブリッドＡＲＱ方式
信頼できないチャネルを通じてのパケット送信システムにおける誤り検出・訂正のための一般的な手法は、ハイブリッド自動再送要求（ＨＡＲＱ：Hybrid Automatic Repeat reQuest）と称される。ハイブリッドＡＲＱは、順方向誤り訂正（ＦＥＣ）とＡＲＱの組合せである。

自動再送要求（ＡＲＱ）は、データ送信のための誤り制御方法であり、ＡＣＫおよびタイムアウトを使用して信頼性のあるデータ送信を達成する。ＡＣＫは、受信側によって送信側に送られるメッセージであり、受信側がデータパケットを正しく受信したことを示している。送信側が、タイムアウト（ＡＣＫを受信するための適度な時間間隔）より前にＡＣＫを受信しない場合、通常では、送信側は、自身がＡＣＫを受信するまで、または所定の再送回数を超えるまで、フレームを再送信する。

順方向誤り訂正は、データ送信における誤りを制御するために採用され、送信側が自身のメッセージに冗長データを追加する。これにより、受信側は、誤りが発生したかを検出することができ、さらに、送信側からの追加のデータを要求することなくいくつかの誤りを訂正することができる。結果として、順方向誤り訂正により、特定の制限内において誤りのいくつかを訂正できるため、データパケットの再送信をしばしば回避することができる。しかしながら、各データパケットに付加される追加のデータに起因して、この方策では広い帯域幅が要求される。

ＦＥＣ符号化されたパケットが送信され、受信側がそのパケットを正しく復号できない場合（誤りは通常ではＣＲＣ（巡回冗長検査）によってチェックされる）、受信側はそのパケットの再送信を要求する。

送信を構成している情報（一般的には符号ビット／符号シンボル）に応じてと、受信側が情報を処理する方法に応じて、以下のハイブリッドＡＲＱ方式が定義されている。

タイプＩ：誤り検出情報（例えばＣＲＣ）をデータパケットに追加し、このデータパケットを順方向誤り訂正符号（例えば、リードソロモン符号、ターボ符号）によって符号化する。受信側においては、ＦＥＣ符号を復号し、パケットの品質を判定する。チャネルの品質が十分に良好であるならば、すべての送信誤りが訂正可能なはずであり、受信側は実際のデータパケットを正しく復号することができる。チャネルの品質が不良であり、いくつかの送信誤りを訂正できない場合、受信された符号化されているデータパケットを破棄し、そのデータパケットの再送信を受信側によって要求する。このタイプのＨＡＲＱにおいては、再送信では最初の送信時と同じＦＥＣ符号を使用する。さらには、再送データパケットは、最初の送信と同じ情報（符号ビット／符号シンボル）を含んでいる。これらの結果として、受信される送信は、受信側においてすべて個別に復号される。

タイプＩＩ：第２のタイプのＨＡＲＱによると、受信側がパケットを正しく復号できない場合、受信側は、（正しく受信されなかった）符号化されているパケットの情報を軟情報（軟ビット／軟シンボル）として格納し、送信側からの再送信を要求する。このことは、受信側に軟バッファが要求されることを意味する。再送信は、最初に送信されたデータパケットと比較して同じ情報、部分的に同じ情報、または同じではない情報（符号ビット／符号シンボル）から構成することができる。受信側は、再送信を受信すると、軟バッファからの格納されている情報と、その時点で受信した情報とを合成し、合成された情報に基づいてパケットの復号を試みる。送信の合成とは、いわゆる軟合成を意味し、この場合、複数受信された（multiple received）符号ビット／符号シンボルを尤度合成し（likelihood combined）、単独に受信された（solely received）符号ビット／符号シンボルを符号合成する（code combined）。軟合成の一般的な方法は、受信された変調シンボルの最大比合成（ＭＲＣ）と、対数尤度比（ＬＬＲ）合成である（ＬＬＲ合成は符号ビットに対してのみ機能する）。タイプＩＩのＨＡＲＱ方式は、タイプＩのＨＡＲＱ方式よりも高度であり、なぜなら、データパケットが正しく受信される確率が、再送信を受信するたびに増大するためである。この確率増大は、受信側におけるＨＡＲＱ軟バッファの代償として達成される。

タイプＩＩのＨＡＲＱ方式を使用すると、再送信する情報量を制御することにより動的なリンクアダプテーションを実行することができる。例えば、受信側は、復号の大部分が成功したことを検出した場合、次の再送信において少量の情報（前の送信におけるよりも少ない数の符号ビット／符号シンボル）のみを送信するように要求することができる。このタイプの場合、再送信パケットを独力で正しく復号することが理論的には不可能であることが発生することもあり、これを自己復号不能な再送（non-self-decodable re-transmissions）と称する。

タイプＩＩＩ：このタイプは、タイプＩＩのＨＡＲＱのうち、各送信（最初の送信または再送信）が自己復号可能でなければならないという制約下のＨＡＲＱである。

ＨＡＲＱメカニズムは、ユニキャストデータ送信に対して定義されており、この場合、信頼性を提供するための２つの再送レベル、すなわち、ＭＡＣ層におけるハイブリッド自動再送要求（ＨＡＲＱ）とＲＬＣ層における外部ＡＲＱ（outer ARQ）が存在する。

しかしながら、最近になって、ＭＢＭＳ（マルチキャストブロードキャストマルチメディアサービス）などのマルチキャスト送信のためのＬＴＥにおいて、軟合成を用いるＨＡＲＱをサポートすることが合意された。ＵＭＴＳでは、マルチキャスト送信においてこのような機能はサポートされない。したがって、対処する必要のあるいくつかの技術的課題が発生している。課題の１つは、ユニキャスト送信およびマルチキャスト送信に対して、軟合成を用いるＨＡＲＱ動作を同時にサポートする場合における、軟バッファの管理である。

比較的単純なソリューションとしては、通常のユニキャストＨＡＲＱプロトコルの動作のために使用される軟バッファメモリ以外に、ＵＥにおけるＭＢＭＳ ＨＡＲＱ動作のためにいくらか余分な軟バッファメモリを追加することである。この方法においては、ＨＡＲＱプロトコルに関してＵＥおよびｅＮＢのいずれについても何らの変更も要求されない。しかしながら、移動端末における軟バッファメモリは非常に高価であるため、このソリューションはさほど実用的ではない。

したがって、最先端技術における上記の問題に鑑み、本発明の１つの目的は、バッファを用いて軟合成を行う再送プロトコルを使用して、ユニキャストおよびマルチキャストによってデータパケットを交換する方法を提供することである。

本発明のより具体的な目的は、ユニキャスト送信およびマルチキャスト送信を同時に行うための軟バッファ管理方式であって、軟バッファを用いて軟合成を行う再送プロトコルをサポートし、かつ移動ノードにおける余分な軟バッファメモリの必要性を回避する管理方式、を提供することである。

上記の目的の少なくとも１つは、独立請求項の主題によって解決される。本発明の有利な実施形態は、従属請求項の主題である。

本発明によるＨＡＲＱプロトコルの動作では、ユニキャスト送信およびマルチキャスト送信の両方がサポートされ、これによって、移動ノードにおけるマルチキャスト送信のための余分な軟バッファが不要になる。この点において、本発明は、ユニキャスト送信およびマルチキャスト送信に対して共通の軟バッファ管理を使用し、ユニキャストデータパケットの処理時およびマルチキャストデータパケットの処理時に軟バッファが共有される。ユニキャストデータパケットを送信するときには、無線制御エンティティは、移動ノードにおいてそのユニキャストデータパケットを正しく復号できない場合に移動ノードが再送プロトコルのどのプロセスを使用するべきかを指定することができる。無線制御エンティティにおいて決定されるこのプロセスが移動ノードにシグナリングされ、したがって、移動ノードは、入ってくるユニキャストデータパケットを割り当てるべきプロセスを認識している。これとは異なり、マルチキャストデータパケットのためのプロセスを無線制御エンティティが指定することはできず、なぜなら、マルチキャストデータパケットを受信する複数の移動ノードのそれぞれにおいて、送信誤りの場合にマルチキャストデータパケットを処理するために利用可能なプロセスが異なりうるためである。したがって、マルチキャストデータパケットを再送プロトコルの特定のプロセスに割り当てる役割を移動ノードが担い、その一方で、無線制御エンティティは、マルチキャストによって送信されるデータパケットを移動ノードが識別できるようにすることができる。

結果として、無線制御エンティティは、送信されるマルチキャストデータパケットに対して移動ノードによってどのプロセスが選択されるかを認識しない。しかしながら、無線制御エンティティは、空の軟バッファ領域が関連付けられているプロセスにユニキャストデータパケットを正しく割り当てるため、利用可能なプロセスおよび利用可能ではないプロセスのすべてを認識しておく必要がある。したがって、無線制御エンティティが再送プロトコルのプロセスのステータスをいつでも認識できるようにする必要がある。

本発明の一態様によると、移動ノードにおける再送プロトコルの軟バッファ管理は、それぞれユニキャスト送信およびマルチキャスト送信をサポートする２つの部分に厳密に分割される。再送プロトコルはいくつかのプロセスを使用し、各プロセスは、軟合成を実施するための軟バッファ領域に関連付けられ、これらのプロセスは２つの部分の間で分配されている。したがって、ユニキャスト送信のための軟バッファ管理によるＨＡＲＱプロトコルの動作は変更されず、利用可能な軟バッファのサイズと利用可能なプロセスとが減少する。すなわち、特定のユニキャストサービスに属する特定のデータパケットに対して移動ノードが使用するべきプロセスについては、依然として無線制御エンティティが明示的に指定することができる。さらに、無線制御エンティティは、以降のデータパケットを正しく割り当てることができるように、現時点で使用されていないプロセスを追跡することができ、なぜなら、無線制御エンティティは、ユニキャストセクション内のプロセスの使用についてを決定する唯一のエンティティであるためである。すなわち、ユニキャストセクションに属するプロセスを有する再送プロトコルは、マルチキャストセクションに属するプロセスを有する再送プロトコルとは独立して動作する。したがって、無線制御エンティティは、ユニキャストセクションに属しているプロセスのステータスをいつでも正確に認識していることができる。

これとは対照的に、マルチキャスト送信のための再送プロトコルのプロセスについては、無線制御エンティティが明示的に指定することはできず、なぜなら、いくつかの移動ノードが同じマルチキャストデータパケットを受信する一方で、それら移動ノードそれぞれにおけるプロセスのステータスがその時点において異なりうるためである。例えば、ある移動ノードにおいて空いている唯一のプロセスが、別の移動ノードにおいてすでに使用されていることがある。これを解決する目的で、前述したように、マルチキャストデータパケットのための再送プロトコルの軟バッファを移動ノードが管理する。すなわち、移動ノードは、マルチキャストデータパケットを受信して識別したとき、そのマルチキャストデータパケットを割り当てるマルチキャストセクションのプロセスを、自身のみで決定する。無線制御エンティティは、マルチキャストセクションの複数の異なるプロセスの実際のステータスを認識していないが、認識している必要はなく、なぜなら、移動ノードがデータパケットをマルチキャストによって送信されたデータパケットとして識別することが、無線制御エンティティによって可能にされているならば、マルチキャストデータパケットのためのプロセスの割り当てが移動ノードのみによって制御されるためである。さらには、無線制御エンティティはマルチキャストプロセスの実際のステータスを認識していないが、ユニキャストプロトコルの動作とマルチキャストプロトコルの動作とが厳密に分かれているため、再送プロトコルの動作のうちユニキャストの部分が動作するうえでこの認識は必要ない。

要約すれば、本発明の第１の態様では、軟バッファをユニキャストセクションとマルチキャストセクションとに厳密に分け、これによって、再送プロトコルの動作もユニキャストデータ送信とマルチキャストデータ送信とに対して互いに分けることによって、ユニキャストデータパケットに対する、軟合成を用いる再送の使用に関して、移動ノードと無線制御エンティティの間で同期が確保される。

本発明の別の態様によると、本発明の第１の態様と比較したとき、移動ノードにおける軟バッファを分けない。代わりに、ユニキャスト送信のみならずマルチキャスト送信に対しても軟バッファ全体を使用する、すなわち、ユニキャストデータパケットおよびマルチキャストデータパケットを処理するのに同じプロセスを使用することができる。すでに上述したように、無線制御エンティティは、特定のユニキャスト送信に対する移動ノードにおける再送プロトコルのプロセスを明示的に指定できるが、マルチキャスト送信に対する再送プロトコルのプロセスについては、この態様においても指定することができず、なぜなら、与えられた時点においていくつかの移動ノードにおけるプロセスステータス（利用可能または利用不可）が異なるためである。そうではあっても、無線制御エンティティは、ユニキャスト送信のための再送プロトコルのプロセスを正しく割り当てることができるべきである。したがって、無線制御エンティティは、ユニキャストデータパケットのまもなくの送信をプロセスに割り当てるうえで、どのプロセスが利用可能であるかを認識している必要がある。

上述した第１の態様によると、この認識は相当に単純であり、なぜなら、再送プロトコルがユニキャスト送信とマルチキャスト送信とにおいて個別に実行されるためである。対照的に、本発明の第２の態様による再送プロトコルの動作においては、ユニキャストデータパケットのためのプロセスであって、正しく受信されなかったマルチキャストデータパケットを格納する目的にまだ使用されていないプロセス、を無線制御エンティティが正しく選択することができるように、プロセスの現在のステータスを無線制御エンティティが認識できるようにする必要がある。しかしながら、マルチキャストデータパケットが正しく復号されない場合、そのマルチキャストデータパケットを再送プロトコルのプロセスに分配する役割は、移動ノードが担っているため、移動ノードがマルチキャストデータパケットをプロセスに割り当てるための規則であって、無線制御エンティティにも認識されている規則を定義する。したがって、無線制御エンティティは、移動ノードに送信されるマルチキャストデータパケットが移動ノードによって割り当てられるであろうプロセスを、この規則から推測することができる。結果として、無線制御エンティティは、移動ノードにおけるすべてのプロセスのステータスを認識しており、ユニキャストデータパケットをプロセスに正しく割り当てることができる。

本発明の一実施形態は、ユニキャスト送信モードおよびマルチキャスト送信モードにおいて無線制御エンティティから移動ノードにデータパケットを送信する方法を提供する。再送プロトコルは、ユニキャストデータパケットおよびマルチキャストデータパケットを送信するために複数のプロセスを使用する。さらには、再送プロトコルは、それぞれが再送プロトコルの複数のプロセスの１つに関連付けられる複数の領域、から成る、移動ノードにおける受信バッファ、を使用する。

受信バッファは、移動ノードによって正しく復号できなかった受信されたデータパケットを、対応する再送データパケットと一緒に後から使用できるように、中に格納しておくために使用される。移動ノードにおける再送プロトコルの受信バッファを、ユニキャスト送信モードおよびマルチキャスト送信モードにおいて使用できるように構成設定する。より詳細には、受信バッファを、ユニキャストセクションとマルチキャストセクションとに分割する。次に、複数のプロセスが関連付けられている受信バッファの複数の領域を、ユニキャストセクションおよびマルチキャストセクションの間で分配する。ユニキャストセクションおよびマルチキャストセクションの間での領域および関連付けられているプロセスの分配についてを、無線制御エンティティに知らせる。無線制御エンティティは、ユニキャストデータパケットを移動ノードに送信し、この場合、このユニキャストデータパケットは、受信バッファのユニキャストセクションに属しているプロセスに割り当てられる。さらに、無線制御エンティティは、マルチキャストデータパケットを移動ノードに送信し、この場合、このマルチキャストデータパケットは、受信バッファのマルチキャストセクションに割り当てられる。

本発明の有利な実施形態によると、移動ノードは、無線制御エンティティからマルチキャストデータパケットを受信した時点で、そのマルチキャストデータパケットを正しく復号できない場合に、そのマルチキャストデータパケットをマルチキャストセクションに属しているプロセスに割り当てる。この実施形態の１つの利点として、プロセスへのマルチキャストデータパケットの割り当てが移動ノードによって制御され、したがって、ｅＮＢはこの割り当ての役割をもはや担わない。

本発明のさらなる実施形態においては、移動ノードは、ユニキャストセクションおよびマルチキャストセクションに割り当てられるプロセスの数を決定することができる。さらに、ユニキャストセクションおよびマルチキャストセクションに割り当てられるプロセスのそれぞれに関連付けられる、受信バッファの対応する領域、を構成する受信バッファの量について決定する。次に、プロセスの数と、ユニキャストセクションおよびマルチキャストセクションに割り当てられるプロセスに関連付けられる領域それぞれの受信バッファの量とを、無線制御エンティティに知らせる。したがって、無線制御エンティティは、ユニキャストデータパケットをユニキャストプロセスに正しく割り当てることができる。

本発明の別の実施形態によると、構成設定情報メッセージを移動ノードから無線制御エンティティに送信する。構成設定情報メッセージはビットマップを備えており、ビットマップの各ビットが再送プロトコルの複数のプロセスのうちの１つのプロセスに対応している。さらには、ビットマップの各ビットは、対応するプロセスが、受信バッファのユニキャストセクションに属しているのか、またはマルチキャストセクションに属しているのかを示している。これによって、無線制御エンティティが、ユニキャストセクションおよびマルチキャストセクションに属しているプロセスを識別できる状況を容易に達成することができる。

本発明のより有利な実施形態によると、受信されたマルチキャストデータパケットを格納している、マルチキャストセクションの領域を、タイマーが経過した時点で空にする。このタイマーは、再送プロトコルによってマルチキャストセクションのその領域にマルチキャストデータパケットが格納されるとき、開始される。１つの利点として、再送信が行われない場合にマルチキャストセクションの領域が長時間にわたり確保されることが回避される。

本発明の別の異なる実施形態は、移動ノードにおいてマルチキャストデータパケットを受信できるようにする第２の制御情報に関する。この第２の制御情報は、無線制御エンティティから移動ノードに送信される。第２の制御情報は、対応するデータパケットがマルチキャスト送信モードにおいて移動ノードに送信されることを示す所定のインジケータを備えている。そのマルチキャストデータパケットを無線制御エンティティから移動ノードに送信する。データパケットと一緒に所定のインジケータを移動ノードに送信することによって、そのデータパケットのタイプ（すなわち、マルチキャストデータパケットが受信されたことについて、ＭＮに効果的に知らされる。

本発明の別の実施形態は、ユニキャスト送信モードおよびマルチキャスト送信モードにおいて無線制御エンティティから移動ノードにデータパケットを送信する方法を提供する。再送プロトコルは、ユニキャストデータパケットおよびマルチキャストデータパケットを送信するために複数のプロセスを使用する。さらに、再送プロトコルは、複数の領域から成る、移動ノードにおける受信バッファ、を使用する。領域のそれぞれは、再送プロトコルの複数のプロセスの１つに関連付けられておりかつ移動ノードによって正しく復号できなかった受信されたデータパケット、を格納する。

データパケットは、対応する再送データパケットと一緒に後から使用できるように、格納される。無線制御エンティティは、ユニキャストデータパケットを移動ノードに送信し、この場合、このユニキャストデータパケットは、再送プロトコルの複数のプロセスの１つに割り当てられる。無線制御エンティティは、マルチキャストデータパケットを移動ノードに送信し、この場合、このマルチキャストデータパケットは、移動ノードおよび無線制御エンティティに既知である規則に応じて、再送プロトコルの複数のプロセスの１つに移動ノードによって割り当てられる。

本発明の有利な実施形態においては、再送プロトコルのプロセスのうち、移動ノードにおける受信バッファの関連付けられている領域が空であるプロセスは、前のユニキャストデータパケットを再送プロトコルのプロセスに割り当てるための無線制御エンティティによる前の決定、に基づいて決定する。この決定は、前のマルチキャストデータパケットを再送プロトコルのプロセスに割り当てるために移動ノードによって使用される規則との組合せにおける、移動ノードへの前のマルチキャストデータパケットの送信、にも基づく。

本発明の別の実施形態によると、移動ノードは、第２の制御情報とマルチキャストデータパケットとを受信する。これにより、移動ノードにおいてマルチキャストデータパケットが受信された時点で、そのマルチキャストデータパケットは、第２の制御情報における所定のインジケータに基づいて、マルチキャスト送信モードにおいて送信されたデータパケットとして識別される。マルチキャストデータパケットを移動ノードによって正しく復号できない場合には、移動ノードが、マルチキャストデータパケットを規則に応じて受信バッファの領域に格納する。

本発明のさらなる実施形態に関連して、再送プロトコルの複数のプロセスは、昇順または降順の複数の識別子によってそれぞれ識別される。移動ノードは、受信バッファ内の関連付けられている空の領域を有し、かつ最も低い識別子または最も高い識別子を有するプロセス、にマルチキャストデータパケットを割り当てるように、規則によって指示される。

本発明のさらに有利な実施形態においては、移動ノードは、移動ノードによって正しく復号できなかったマルチキャストデータパケットを受信バッファの関連付けられる領域に格納するために使用される、再送プロトコルのプロセスの数を決定する。この決定されたプロセス数についてを、無線制御エンティティに知らせる。無線制御エンティティは、プロセスの最大数を認識している場合、利用可能なリソースをより効率的に使用することができる。

本発明の別の実施形態は、ユニキャスト送信モードおよびマルチキャスト送信モードにおいてデータパケットを移動ノードに送信する無線制御エンティティを提供する。再送プロトコルは、ユニキャストデータパケットおよびマルチキャストデータパケットを送信するために複数のプロセスを使用する。さらに、再送プロトコルは、複数の領域から成る、移動ノードにおける受信バッファを使用する。領域のそれぞれは、再送プロトコルの複数のプロセスの１つに関連付けられておりかつ移動ノードによって正しく復号できなかった受信されたデータパケット、を格納する。データパケットは、対応する再送データパケットと一緒に後から使用できるように、格納される。無線制御エンティティにおける受信器は、ユニキャストセクションおよびマルチキャストセクションへの受信バッファの分割に関する情報と、ユニキャストセクションおよびマルチキャストセクションの間での領域および関連付けられているプロセスの分配に関する情報とを、移動ノードから受信する。無線制御エンティティの送信器は、ユニキャストデータパケットを移動ノードに送信する。このユニキャストデータパケットは、受信バッファのユニキャストセクションに属しているプロセスに割り当てられる。送信器は、マルチキャストデータパケットを移動ノードにさらに送信し、このマルチキャストデータパケットは、受信バッファのマルチキャストセクションに割り当てられる。

本発明の別の実施形態は、ユニキャスト送信モードおよびマルチキャスト送信モードにおいて送信される無線制御エンティティからのデータパケットを受信する移動ノードを提供する。再送プロトコルは、ユニキャストデータパケットおよびマルチキャストデータパケットを送信するために複数のプロセスを使用する。さらに、再送プロトコルは、複数の領域から成る、移動ノードにおける受信バッファ、を使用する。領域のそれぞれは、再送プロトコルの複数のプロセスの１つに関連付けられておりかつ移動ノードによって正しく復号できなかった受信されたデータパケット、を格納する。データパケットは、対応する再送データパケットと一緒に後から使用できるように、格納される。移動ノードにおけるプロセッサは、再送プロトコルの受信バッファを、ユニキャスト送信モードおよびマルチキャスト送信モードにおいて使用できるように構成設定する。この構成設定は、受信バッファをユニキャストセクションとマルチキャストセクションとに分割することによってと、受信バッファの複数の領域と関連付けられている複数のプロセスとを、ユニキャストセクションおよびマルチキャストセクションの間で分配することによって、行われる。

移動ノードの受信器は、受信バッファのユニキャストセクションに属しているプロセスに割り当てられているユニキャストデータパケットを、無線制御エンティティから受信する。さらに、受信器は、受信バッファのマルチキャストセクションに割り当てられているマルチキャストデータパケットを、無線制御エンティティから受信する。

本発明の別の実施形態は、ユニキャスト送信モードおよびマルチキャスト送信モードにおいてデータパケットを移動ノードに送信する無線制御エンティティを提供する。再送プロトコルは、ユニキャストデータパケットおよびマルチキャストデータパケットを送信するために複数のプロセスを使用する。さらに、再送プロトコルは、複数の領域から成る、移動ノードにおける受信バッファ、を使用する。領域のそれぞれは、再送プロトコルの複数のプロセスの１つに関連付けられておりかつ移動ノードによって正しく復号できなかった受信されたデータパケット、を格納する。データパケットは、対応する再送データパケットと一緒に後から使用できるように、格納される。無線制御エンティティの送信器は、再送プロトコルの複数のプロセスの１つに割り当てられているユニキャストデータパケットを、移動ノードに送信する。さらに、送信器は、マルチキャストデータパケットを移動ノードに送信する。無線制御エンティティのメモリは、規則を格納しており、マルチキャストデータパケットは、移動ノードによってこの規則に応じて再送プロトコルの複数のプロセスの１つに割り当てられる。

本発明の別の実施形態は、ユニキャスト送信モードおよびマルチキャスト送信モードにおいて送信されるデータパケットを無線制御エンティティから受信する移動ノードを提供する。再送プロトコルは、ユニキャストデータパケットおよびマルチキャストデータパケットを送信するために複数のプロセスを使用する。再送プロトコルは、複数の領域から成る、移動ノードにおける受信バッファ、を使用する。領域のそれぞれは、再送プロトコルの複数のプロセスの１つに関連付けられておりかつ移動ノードによって正しく復号できなかった受信されたデータパケット、を格納する。データパケットは、対応する再送データパケットと一緒に後から使用できるように、格納される。移動ノードにおける受信器は、再送プロトコルの複数のプロセスの１つに割り当てられているユニキャストデータパケットを、無線制御エンティティから受信する。さらに、受信器は、無線制御エンティティからマルチキャストデータパケットを受信する。プロセッサは、移動ノードおよび無線制御エンティティに既知である規則に応じて、受信されたマルチキャストデータパケットを再送プロトコルの複数のプロセスの１つに割り当てる。

以下では、本発明について、添付の図面を参照しながらさらに詳しく説明する。図面において、類似または対応する細部は同じ参照数字によって表してある。

ＯＦＤＭベースの通信システムにおける、局在型リソース割り当て方法と分散型リソース割り当て方法の間の違いを示している。 ＬＴＥシステムの高レベルアーキテクチャを示している。 Ｅ−ＵＴＲＡＮの全体的なアーキテクチャを示している。 本発明の特定の実施形態による、軟バッファを構成設定するために実行される、ユニキャスト送信およびマルチキャスト送信をサポートする一連のステップ、を示している流れ図である。 ＭＮとｅＮＢとの間での構成設定情報の交換を示しているシグナリング図である。 本発明の特定の実施形態に従って、ユニキャスト動作とマルチキャスト動作とが分離されているときの、いくつかのＨＡＲＱプロセスの例示的な構成設定を示している。 本発明の別の実施形態に従って、ユニキャスト動作とマルチキャスト動作とが同じ軟バッファを共有しているときの、いくつかのＨＡＲＱプロセスの例示的な構成設定を示している。 マルチキャストコンテンツを同期させるように構築されているユーザプレーンアーキテクチャ全体を示している。 ＬＴＥにおいて導入されているＥ−ＭＢＭＳの定義を示している。

定義
以下に、本文書において頻繁に使用しているいくつかの用語の定義を示しておく。

移動ノードは、通信ネットワーク内の物理エンティティである。１つのノードが、いくつかの機能エンティティを有することができる。機能エンティティとは、所定の一連の機能を実施する、もしくは、ノードまたはネットワークの別の機能エンティティに、所定の一連の機能を提供する、またはその両方であるソフトウェアモジュールまたはハードウェアモジュールを意味する。ノードは、自身を通信設備または通信媒体にアタッチする１つまたは複数のインタフェースを有することができ、ノードは、これら通信設備または通信媒体を通じて通信することができる。同様に、ネットワークエンティティは、機能エンティティを通信設備または通信媒体にアタッチする論理インタフェースを有することができ、ネットワークエンティティは、これら通信設備または通信媒体を通じて別の機能エンティティまたは対応するノードと通信することができる。

軟合成をサポートする再送プロトコルでは、データパケットを送信するためと、正しく復号できなかったデータパケットを、移動ノードにおける軟バッファの関連付けられている領域に格納するために、いくつかのプロセスを使用する。各プロセスはプロセスＩＤによって識別され、ユニキャストデータパケットは、無線制御エンティティによって再送プロトコルの特定のプロセスに明示的に割り当てられる。したがって、ユニキャストデータパケットを正しく復号できない場合、そのユニキャストデータパケットが、移動ノードにおけるプロセスによって、関連付けられている軟バッファ領域に格納される。

以下の段落では、本発明のさまざまな実施形態について説明する。いくつかの実施形態は３ＧＰＰ／ＬＴＥ通信システムに関連して概説してあるが、これは例示を目的としているにすぎない。本発明は、例えば、３ＧＰＰ／ＬＴＥ通信システムなどの移動通信システムに関連して有利に使用できるが、本発明は、この特定の例示的な通信ネットワークにおける使用に限定されないことに留意されたい。

上の背景技術のセクションに示した説明は、本明細書に説明されている特定の例示的な実施形態を深く理解することを目的としており、移動通信ネットワークにおけるプロセスおよび機能の、説明した特定の実施形態に、本発明を制限するものではないことを理解されたい。しかしながら、本文書に提案されている改良・改善は、［背景技術］のセクションに説明されているアーキテクチャ／システムにただちに適用することができ、本発明のいくつかの実施形態においては、これらのアーキテクチャ／システムの標準の手順と、改良された手順とを利用することもできる。

本発明のさまざまな実施形態についてさらに詳しく説明する前に、上に定義した再送プロトコルの例として、ハイブリッドＡＲＱプロトコルについて以下に説明しておく。さらには、本発明の実施形態は、図３に示したような、ｅＮＢがユニキャスト送信モードおよびマルチキャスト送信モードにおいてＭＮにデータパケットを送信するＬＴＥシステムの例示的なシナリオの場合において説明してある。したがって、ここまでに説明してきた無線制御エンティティは、この例示的なシナリオにおいてはｅＮＢである。しかしながら、当業者には明らかであるように、無線制御エンティティは、通信システムおよびその実施方式に応じて、ＮｏｄｅＢ、ＲＮＣ、あるいはアクセスルータとすることもできる。

すでに前述したように、ＨＡＲＱプロトコルは、通常ではユニキャストデータを送信する場合にのみ実行され、この場合、信頼性を提供するため２つの再送レベル、すなわち、ＭＡＣ層におけるＨＡＲＱとＲＬＣ層における外部ＡＲＱが存在する。外部ＡＲＱは、ＨＡＲＱによって訂正されずに残った誤りを扱うために必要であり、ＨＡＲＱ自体は、１ビットの誤りフィードバックメカニズム、すなわちＡＣＫ／ＮＡＣＫを使用することによって、単純なままにしておくことができる。ＨＡＲＱプロトコルでは、データパケットを送信および受信するためにｅＮＢおよび移動ノードにおいていくつかのＨＡＲＱプロセスを使用する。具体的には、最初に、特定のユニキャストデータパケットを送信するのにどのＨＡＲＱプロセスを使用するかを決定する。次に、ｅＮＢが、決定されたＨＡＲＱプロセスを使用して、そのユニキャストデータパケットをＭＮに送信する。それに相応して、ｅＮＢは、そのプロセスに関連付けられる送信バッファ領域を有し、この領域には、送信するデータパケットに対応するＡＣＫがＭＮから受信されるまで、その送信するデータパケットが格納される。このＡＣＫを受信すると、送信バッファ領域をフラッシュし、格納されているデータパケットを削除する。

これに対して、移動ノードは、無線制御エンティティと同じ量の、ＨＡＲＱプロトコルのプロセスを有し、ｅＮＢがユニキャストデータパケットを送信するために使用したものと同じ特定のプロセスを使用してそのユニキャストデータパケットを受信する。移動ノードにおいてこのユニキャストデータパケットが正しく復号された場合、ＡＣＫを送り返し、この場合、そのユニキャストデータパケットを移動ノードに送信するために使用されたプロセスに関連付けられている、ｅＮＢにおける送信バッファ領域が、フラッシュされる。

しかしながら、ユニキャストデータパケットを正しく復号することができず、かつ移動ノードが軟合成をサポートしている場合には、そのユニキャストデータパケットに割り当てられているプロセスに関連付けられるＭＮの軟バッファ領域に、そのユニキャストデータパケットを格納する。これとほぼ同時に、ＮＡＣＫをｅＮＢに送信する。無線制御エンティティは、ＮＡＣＫまたはＡＣＫが指しているＨＡＲＱプロセスを一義に識別できなければならない。このことは、例えば、データパケットを受信したときから所定の時間後にＨＡＲＱフィードバックメッセージ（ＡＣＫ／ＮＡＣＫ）を送信することによって、達成できる。無線制御エンティティは、ＡＣＫ／ＮＡＣＫシグナリングのタイミングに基づいて、対応するＨＡＲＱプロセスを識別し、ＮＡＣＫが受信された場合にはデータパケットの再送信を開始することができる。そして、取得されたユニキャストデータパケットに対して、同じＨＡＲＱプロセスを使用して移動ノードへの再送信を実行する。

一方で、移動ノードは再送データパケットを受信し、割り当てられているＨＡＲＱプロセスＩＤから、最初のデータパケットが位置している領域を認識する。さらに、移動ノードは、再送信されたユニキャストデータパケットに割り当てられているＨＡＲＱプロセスＩＤによって示されるバッファ領域から、最初のユニキャストデータパケットを取得する。次に、移動ノードは、両方の（最初の、および再送信された）ユニキャストデータパケットを合成して、そのユニキャストデータパケットを正しく復号することを試みることができ、正しく復号された場合、ＡＣＫをｅＮＢに送り返す。

この再送プロセスは、ユニキャストデータパケットが正しく復号されるまで繰り返すことができるが、通常では、最大可能な再送回数に制限される。

ダウンリンクにおける非同期再送信と、アップリンクにおける同期再送信とを有する、Ｎプロセス・ストップアンドウェイトＨＡＲＱプロトコル（N-process stop-and-wait HARQ protocol）を採用することができる。同期ＨＡＲＱとは、ＨＡＲＱブロックの再送信が所定の周期間隔において行われることを意味する。したがって、再送スケジュールを受信側に示すための明示的なシグナリングが要求されない。逆に、非同期ＨＡＲＱでは、エアインタフェースの条件に基づいて再送をスケジューリングする柔軟性が提供される。この場合、正しい合成およびプロトコル動作が可能であるように、ＨＡＲＱプロセスの何らかの識別情報をシグナリングする必要がある。

ＨＡＲＱプロセスの正確な数は、３ＧＰＰにおいてまだ決定されていないが、ＬＴＥの場合には８つのＨＡＲＱプロセスが定義される可能性が高く、したがって、本発明の以下の実施形態については、このプロセス数を使用して説明する。しかしながら、当業者は、本発明の一般的な原理をＨＡＲＱプロセスの任意の数に容易に適用できるであろう。

ダウンリンクデータを送信するためのＨＡＲＱプロトコルの動作は、ＨＳＤＰＡに類似する、もしくは同じであるのに対し、アップリンクにおけるＨＡＲＱプロトコルの動作は、ＨＳＵＰＡに類似する。

最近、３ＧＰＰでは、マルチキャスト送信（例えばＭＢＭＳ）において、軟合成を用いるＨＡＲＱをサポートすることが合意された。ＲＲＣ＿ＩＤＬＥ状態およびＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥは、ＭＢＭＳ再送信を受信して、これらをＨＡＲＱレベルにおいて元のマルチキャスト送信と合成することができるべきである。しかしながら、マルチキャスト（再）送信の軟合成のサポートは、移動局においてはオプションである。さらには、ＭＢＭＳフィードバックメカニズム（例えば、ＨＡＲＱ ＡＣＫ／ＮＡＣＫシグナリング）について構成設定できるのは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態のＵＥのみである。ｅＮＢは、どのＭＮがマルチキャスト送信に対するＨＡＲＱ ＡＣＫ／ＮＡＣＫフィードバックを送るべきであるかを構成設定する。さらには、ｅＮＢは、ユニキャスト送信に使用されるものと同じ個別アップリンクフィードバックチャネルを割り当て、これによりＭＮがＨＡＲＱ ＡＣＫ／ＮＡＣＫを報告できるようにする。このようなフィードバックメカニズムが構成設定される場合、ＡＭＣ（適応変調符号化）が適用され、ＭＢＭＳにおけるＨＡＲＱ再送信はＤＬ−ＳＣＨ（ダウンリンク共有チャネル）上で行われる。

ｅＮＢは、マルチキャスト再送信を行うべきであるかを、複数のＵＥからのＨＡＲＱフィードバックに基づいて決定する。ユニキャスト送信の場合とは異なり、１つの移動局からのＮＡＣＫによって、マルチキャストデータの再送信が必ずトリガーされるわけではない。前述したように、マルチキャスト再送信を行うべきであるかを決定するのはｅＮＢのスケジューラである。

軟合成を用いるＨＡＲＱプロトコルが正しく動作できるようにするためには、マルチキャストデータパケットの再送信が行われるタイミングを移動局が認識している必要がある。さらには、最初のマルチキャストデータパケットと正しく軟合成できるようにするためには、移動局は、発生しうる再送信が属しているマルチキャストサービスを一義に識別できなければならない。これを達成するための方法はいくつか存在する。１つのオプションは、最初の送信後、一定のタイミングにおいて必ずマルチキャスト再送信を送る、すなわち同期再送信である。この場合、マルチキャスト再送信も、所定の時間・周波数リソース上で行われる。あるいは、マルチキャストデータパケットの対応する許可シグナリングによって、マルチキャスト再送信および対応するマルチキャストサービスＩＤを識別することもできる。

以下では、本発明の第１の実施形態について説明する。

受信端（ＵＥ）における軟バッファメモリの量は限られているため、軟合成を用いるＨＡＲＱ動作をマルチキャスト送信に対してサポートする目的で余分な軟バッファメモリが要求されることは避けることが重要である。移動ノードには１つの軟バッファメモリが存在し、通常ではユニキャストＨＡＲＱ動作のみに使用され、そのためのサイズを備えている。移動局がユニキャスト送信およびマルチキャスト送信の両方に対して軟合成を用いるＨＡＲＱ動作を同時にサポートしている場合、軟バッファメモリは、ユニキャストデータおよびマルチキャストデータの間で共有される。この実施形態において提示する、共通の軟バッファ管理手順の特徴は、ユニキャスト送信とマルチキャスト送信とにおいてＨＡＲＱプロトコルの動作が完全に分かれている、すなわち、ユニキャスト送信のＨＡＲＱ動作とマルチキャスト送信のＨＡＲＱ動作との間に依存関係が存在しないことである。これにより、ＵＥおよびｅＮＢが複雑になることが回避される。

図４は、ユニキャスト送信およびマルチキャスト送信の受信をサポートするために、ＭＮの軟バッファを構成設定する一連のステップを示している流れ図である。最初のステップとして、ＭＮは、ユニキャスト送信およびマルチキャスト送信の間で軟バッファを共有するかを決定する。すなわち、上述したように、軟合成を用いるＨＡＲＱ動作をマルチキャストに対してサポートすることは、ＭＮにおいて単なるオプションである。したがって、ＭＮは、マルチキャストに対しても合成機能をサポートするかを、自身の能力に従って最初に決定するべきである。ＭＮがマルチキャスト送信に対して軟合成機能をサポートする場合、そのＭＮは、マルチキャストに使用する予定のＨＡＲＱプロセスの数を決定する必要がある。マルチキャスト送信に使用するＨＡＲＱプロセス数の決定は、例えば、ＭＮが受信するものと予測されるマルチキャストサービスの数に基づくことができる。言い換えれば、自身がサブスクライブしているすべてのマルチキャストサービスをＭＮが受信できるようにするためには、ＭＮから利用可能である十分なＨＡＲＱプロセスが存在しているべきである。例えば、ＭＮが２つのマルチキャストサービスをサブスクライブしている場合、マルチキャストデータの送信に使用できる少なくとも２つのＨＡＲＱプロセスが存在しているべきである。

マルチキャスト送信のためにＭＮがサポートすることのできるＨＡＲＱプロセスの数を決定した後、ＭＮは、マルチキャストのためのＨＡＲＱプロセスのそれぞれに関連付けられる軟バッファの量を決定する必要がある。マルチキャスト送信のピークデータレートは、たいていの場合、ダウンリンクユニキャスト送信のピークデータレートよりも十分に低い（例えば１／８）ため、マルチキャスト送信用に確保されるＨＡＲＱプロセスには、より少ない軟バッファを割り当てればよい。残りの軟バッファは、ユニキャスト送信に確保されるＨＡＲＱプロセスの間で分配する。この場合も、ＭＮは、関連付ける軟バッファの量をユニキャストＨＡＲＱプロセスそれぞれについて個別に決定することができる。あるいは、軟バッファの残りの量を、すべてのユニキャストＨＡＲＱプロセスの間で均等に分けることができる。

ユニキャストおよびマルチキャストをサポートするための軟バッファの構成設定をＭＮが完全に終了したとき、ＨＡＲＱプロトコルが正しく動作できるようにする目的で、正確な構成設定をｅＮＢに知らせる必要がある。ｅＮＢのスケジューラは、この情報に基づいて、ＤＬユニキャスト送信に使用できるＨＡＲＱプロセスを認識し、すなわち、スケジューラは、ＤＬ許可シグナリングにおいて正しいＨＡＲＱプロセスＩＤセットを使用することができる。この情報は極めて高い信頼性とするべきであるため、ＲＲＣシグナリングを使用することができる。図５には、対応するシグナリングフローを示してあり、この場合、ＭＮは「ＨＡＲＱ ＰＲＯＣＥＳＳ ＵＴＩＬＩＺＡＴＩＯＮ ＩＮＦＯ（ＨＡＲＱプロセス利用情報）」メッセージの中で構成設定情報をｅＮＢに送る。前述したように、このメッセージは、ユニキャスト送信およびマルチキャスト送信のための軟バッファメモリの分割に関する情報と、マルチキャスト専用に使用されるＨＡＲＱプロセスに関する情報とを含んでいる。

「ＨＡＲＱ ＰＲＯＣＥＳＳ ＵＴＩＬＩＺＡＴＩＯＮ ＩＮＦＯ」メッセージの中の、ＨＡＲＱプロセスの利用状況に関する情報は、例えばビットマップによってシグナリングすることができる。このビットマップ内の各ビットが、１つのＨＡＲＱプロセスに対応する。ビットが０に設定されているかまたは１に設定されているかに応じて、対応するＨＡＲＱプロセスを、それぞれ、ユニキャストデータの送信のみに、またはマルチキャストデータの送信のみに使用することができる。例えば、ビットマップ「１１００００００」は、プロセス１およびプロセス２をマルチキャスト送信に使用することができるのに対して、残りのプロセス３〜プロセス８がユニキャスト送信用に確保されることを意味する。

あるいは、マルチキャストのみ、もしくはユニキャストのみ、またはマルチキャストおよびユニキャストに使用するべきＨＡＲＱプロセスの数および識別情報を、ＭＮが明示的にシグナリングすることができる。例えば、ＭＮは、ＨＡＲＱプロセス１およびＨＡＲＱプロセス２がマルチキャストに使用されることをｅＮＢにシグナリングする。結果として、ｅＮＢは、ＨＡＲＱプロセス３〜ＨＡＲＱプロセス８がユニキャストに使用されることを推測することができる。別の例によると、ＨＡＲＱプロセス１から、「利用可能なすべてのＨＡＲＱプロセスから、確保されるマルチキャストＨＡＲＱプロセスの数を減じた番号」までが、ＤＬユニキャスト送信に使用されることを、ＭＮがシグナリングすることができる。したがって、ＨＡＲＱプロセスの総数が８つ、マルチキャストＨＡＲＱプロセスが２つであると想定すると、ＨＡＲＱプロセス１〜ＨＡＲＱプロセス６がユニキャスト送信に使用され、ＨＡＲＱプロセス７およびＨＡＲＱプロセス８がマルチキャスト送信に使用される。

しかしながら、当業者には容易に理解できるように、「ＨＡＲＱ ＰＲＯＣＥＳＳ ＵＴＩＬＩＺＡＴＩＯＮ ＩＮＦＯ」メッセージにおいて送信される、ＨＡＲＱプロセスの利用状況に関する構成設定情報を符号化するための可能な方法は、いくつか存在する。同様に、「ＨＡＲＱ ＰＲＯＣＥＳＳ ＵＴＩＬＩＺＡＴＩＯＮ ＩＮＦＯ」メッセージに含まれる、ＨＡＲＱプロセスの間での軟バッファメモリの分割の情報を符号化するための可能な方法も、いくつか存在する。

図５に示したように、ｅＮＢは、「ＨＡＲＱ ＰＲＯＣＥＳＳ ＵＴＩＬＩＺＡＴＩＯＮ ＣＯＮＦＩＲＭ（ＨＡＲＱプロセス利用確認）」メッセージをＭＮに送ることによって、「ＨＡＲＱ ＰＲＯＣＥＳＳ ＵＴＩＬＩＺＡＴＩＯＮ ＩＮＦＯ」メッセージを正しく受信したことを通知する。ＭＮは、この確認メッセージを受信した時点で、ユニキャスト送信およびマルチキャスト送信によってデータを受信する準備が整う。

図６は、本発明の第１の実施形態による、ユニキャスト送信およびマルチキャスト送信のためのＨＡＲＱプロセスの例示的な構成設定を示している。３ＧＰＰの最新の状況によると、ＨＡＲＱプロトコルのための８つのＨＡＲＱプロセスが定義される予定である。ＭＮは、８つのＨＡＲＱプロセスのうち、マルチキャストデータのみのＨＡＲＱ動作専用の２つのＨＡＲＱプロセス（ＨＡＲＱプロセスＩＤ７およびＩＤ８を有する）を確保している。したがって、ｅＮＢは、ＤＬユニキャスト送信においては最初の６つのＨＡＲＱプロセス（ＨＡＲＱプロセスＩＤ１〜ＩＤ６を有する）のみを割り当てることができる。

ここまで、ユニキャスト送信およびマルチキャスト送信の両方のための軟バッファの必要な構成設定について説明した。以下では、ユニキャストデータパケットおよびマルチキャストデータパケットを受信したときの軟合成を用いるＨＡＲＱプロトコルの実際の動作について説明する。ＨＡＲＱプロセスの分配は図６に従うものと想定する。しかしながら、この特定の分配は本発明を制限するものではなく、１つの例示的な可能な構成設定にすぎないことを理解されたい。さらには、以下の説明部分も一例にすぎない。例えば、ＡＣＫ／ＮＡＣＫシグナリングに関するＭＮおよびｅＮＢの挙動は、本発明の一般的な原理において本質的なものではなく、したがって、当業者には、本発明のさまざまな実施形態による動作に影響を及ぼすことなく、これらの挙動を変更することができる。これらの説明は、本発明の原理を実際に実施する方法を完全に理解することを支援するにすぎないことを理解されたい。

同様に、ＤＬ許可シグナリングに関する想定も単なる例であり、本発明の原理において本質的なものではない。

軟合成を用いるＨＡＲＱをマルチキャストに対してもサポートするとき、ユニキャストＤＬ送信のためのＨＡＲＱプロトコルの動作は、軟バッファがマルチキャストデータ送信と共有されることによってユニキャストデータに利用可能なＨＡＲＱプロセスの数が６に減少すること以外には、変化しない。結果として、ｅＮＢは、ユニキャストデータパケットを送信しようとするとき、そのユニキャストデータパケットの正しい送信が保証されるように、使用するＨＡＲＱプロセスを、最初に決定する。６つの利用可能なユニキャストＨＡＲＱプロセス１〜６のうちの１つを選択し、関連付けられている送信バッファ領域にユニキャストデータパケットを格納する。例えば、ｅＮＢはＨＡＲＱプロセス３を選択する。

次に、ｅＮＢは、移動ノードがユニキャストデータパケットを受信できるようにする目的で、制御チャネル上でＤＬ許可をＭＮに送信する。ユニキャストデータパケットのためのこの許可シグナリングは、例えばユニキャストデータパケットを送るリソースを示すことに加えて、ｅＮＢによって選択されたＨＡＲＱプロセスを識別するＨＡＲＱプロセスＩＤ ３も含んでいる（［背景技術］における第１層／第２層制御シグナリングを参照）。次に、ｅＮＢは、ユニキャストデータパケットを実際に移動ノードに送る。ＭＮは、最初に許可シグナリングを受信するため、ユニキャストデータパケットが送信されるであろうことを認識しており、エアインタフェースからそのユニキャストデータパケットを取得することができる。そのユニキャストデータパケットを復号できないとき、ＭＮは、ユニキャストデータパケットの許可シグナリングによって受け取ったＨＡＲＱプロセスＩＤによって示されるプロセス（プロセス３）に関連付けられている軟バッファ領域に、そのユニキャストデータパケットを格納する。さらに、ＭＮは、ｅＮＢにＮＡＣＫを送信する。すでに前述したように、ＮＡＣＫが属しているデータパケットをｅＮＢが識別するための可能な方法はいくつか存在する。例えば、ＡＣＫ／ＮＡＣＫを特定のタイミングにおいてＭＮから送信することができ、したがって、ｅＮＢは、前に送信した任意のデータパケットについて、それに対するＡＣＫ／ＮＡＣＫがいつ到着するかを認識している。さらには、ｅＮＢが、前に送信したデータパケットにＡＣＫ／ＮＡＣＫを正しく対応させるための別の可能な方法が、当業者には明らかであろう。

ｅＮＢは、ＮＡＣＫに関連付けられる正しいデータパケットおよび対応するＨＡＲＱプロセスＩＤを識別した後、ＨＡＲＱプロセス３に関連付けられる送信バッファ領域からデータパケットを取得し、そのユニキャストデータパケットをＭＮに再送信する。再送信には、対応する同じＨＡＲＱプロセス（すなわちＨＡＲＱプロセス３）を使用する。ユニキャストデータパケットの再送信の許可シグナリングは、この場合も、対応するＨＡＲＱプロセスＩＤを含んでいる。さらには、許可シグナリングは、まもなく行われるＤＬ送信がデータパケットの最初の送信なのか再送信なのかを明示的に示すこともできる。

移動ノードは、再送信されたユニキャストデータパケットを受信したとき、その受信したユニキャストデータパケットが、ＨＡＲＱプロセス３に関連付けられている軟バッファ領域に格納されているデータの再送データパケットであることを、許可シグナリングからすでに認識することができる。したがって、ＭＮは、最初のユニキャストデータパケットと再送信されたユニキャストデータパケットとを合成し、これにより、該当するユニキャストデータパケットを正しく復号することができる。

この結果として、ＭＮはｅＮＢにＡＣＫを送信する。さらに、ＭＮは、ＨＡＲＱプロセス３に関連付けられている軟バッファ領域をフラッシュし、なぜなら、ユニキャストデータパケットが正しく復号され、中に格納されているデータがもはや不要であるためである。ｅＮＢも、ＨＡＲＱプロセス３に対応する自身の送信バッファ領域からユニキャストデータパケットを削除し、ユニキャストサービスの次のデータパケットの送信を開始することができる。

マルチキャスト送信の場合においては、ＨＡＲＱプロトコルの動作は、ユニキャストの場合と比較して異なる。前述したように、マルチキャスト送信は、ＨＡＲＱプロセスＩＤによって特定のＨＡＲＱプロセスに割り当てられない。その理由は、ＨＡＲＱのステータス（すなわち、ＨＡＲＱプロセスの利用状況）が、マルチキャストデータパケットを受信する複数のＵＥの間で同期していないためである。ＭＮがマルチキャストデータパケットをマルチキャストによって送信されたデータパケットとして認識できるようにする目的で、代わりにマルチキャストＩＤを定義することができ、このＩＤをＤＬ許可の中のＨＡＲＱプロセスＩＤフィールドにおいてシグナリングする。しかしながら、データパケットがマルチキャストによって送信されたことをＭＮに示すための別の可能な方法も、いくつか存在する（例えば、ＤＬ許可シグナリングにおける別のＩＤまたは別のフィールド）。

さらに、ｅＮＢは、マルチキャストデータパケットを送信しようとするとき、そのマルチキャストデータパケットのＤＬ許可シグナリングの中で、上述したマルチキャストＩＤを送信する。ｅＮＢは、マルチキャストデータパケットを送信バッファに格納することができる。次に、そのマルチキャストデータパケットを移動ノードに送信し、移動ノードは、ＤＬ許可シグナリングによって指示されたそのデータパケットを受信する。次に、ＭＮは、許可シグナリングの中のマルチキャストＩＤに基づいてデータパケットをマルチキャストデータパケットとして識別した後、そのデータパケットの復号を試みる。ＭＮは、データパケットを正しく復号できなかった場合、２つの可能なＨＡＲＱプロセス７およびプロセス８のうちのいずれかのＨＡＲＱプロセスを自身で選択する。例えば、ＨＡＲＱプロセス８が別のマルチキャストサービスの別のマルチキャストデータパケットのためにすでに使用されているならば、ＭＮは、空いているＨＡＲＱプロセス７をマルチキャストデータパケット用に選択し、ＨＡＲＱプロセス７に関連付けられる軟バッファ領域にマルチキャストデータパケットを格納する。同時に、ＭＮは、ｅＮＢによってどのように構成設定されているかに応じて、データパケットの再送信を要求するためｅＮＢにＮＡＣＫを送ることができる。上述したように、ＭＮは、マルチキャストデータパケットに対してｅＮＢにＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ）をシグナリングするように明示的に構成設定されている必要がある。ｅＮＢは、ＮＡＣＫメッセージを、ＮＡＣＫの中の特殊な識別子によって、または、すでに上述したように、移動ノードからＡＣＫ／ＮＡＣＫを送信するのに使用される特定のタイミングによって、送信バッファに格納されている正しい最初のデータパケットに関連付ける。

ユニキャスト送信の場合とは異なり、１つの移動ノードからのＮＡＣＫによって、マルチキャストデータの再送信が必ずトリガーされるとは限らない。あるマルチキャストデータパケットについて再送信を行うべきであるかを決定するのは、ｅＮＢのスケジューラである。

ｅＮＢは、再送信することを決定した場合、送信バッファから最初のマルチキャストデータパケットを取得し、そのマルチキャストデータパケットの再送信を実行する。これに相応して、ＤＬ許可をＭＮにシグナリングすることもできる。次に、ＭＮは、ＤＬ許可によって示されたマルチキャストデータパケットを受信し、この場合にもＤＬ許可の中で送信されたマルチキャストＩＤに基づいて、そのデータパケットをマルチキャストデータパケットとして識別する。さらには、ＭＮは、そのマルチキャストデータパケットが、ＨＡＲＱプロセス７に関連付けられている軟バッファ領域に格納されている前に受信したデータパケットの再送信であることを、例えば再送信の特定のタイミングから認識する。したがって、両方のマルチキャストデータパケットを合成して実際のマルチキャストデータパケットを正しく復号し、正しく復号された場合には、ＡＣＫメッセージをｅＮＢに送信するように、ＭＮを構成設定することができる。次に、ＭＮは、ＨＡＲＱプロセス７に関連付けられる対応する軟バッファ領域をフラッシュし、なぜなら、このデータがもはや必要ないためである。

移動ノードからのＡＣＫメッセージを受信したときのｅＮＢの動作は、同様にｅＮＢのスケジューラが決定する。しかしながら、ｅＮＢが十分なＡＣＫを受信したならば、そのマルチキャストデータパケットを送信バッファから削除することができ、マルチキャストサービスの次のマルチキャストデータパケットを送信する。

上に詳しく説明したように、本発明の第１の態様によると、ユニキャストおよびマルチキャストのためのＨＡＲＱプロトコルの動作を厳密に分離することによって、ユニキャスト送信およびマルチキャスト送信を同時に行うための効果的な軟バッファ管理を提供することが可能である。

さらに、この態様では、ＭＮがマルチキャストデータパケットを受信し、これを正しく復号することができず、したがって、ＭＮ自身が決定するＨＡＲＱプロセスに関連付けられる軟バッファ領域内にそのマルチキャストデータパケットを保存することを想定している。対応するＮＡＣＫメッセージをｅＮＢに送信することができ、しかしながら、ｅＮＢは、何らかの理由（例えば、ｅＮＢが十分なＮＡＣＫを受信していない）のとき、そのマルチキャストデータパケットを再送信しないことを決定する。この場合、ＨＡＲＱプロセスが確保されるが、関連付けられている軟バッファ領域に格納されているデータに対する再送信マルチキャストデータパケットが受信されることはない。このことは、ＭＮのリソース管理にマイナスに影響する。この問題を回避する目的で、例えばタイマーが経過することによってトリガーされたとき、そのマルチキャストＨＡＲＱプロセスの軟バッファ領域をフラッシュすることができる。いま、マルチキャストデータの再送信が、最初の送信が行われてから所定の時間窓内に行われ、かつ再送信の最大回数が１回のみであると想定すると、マルチキャストデータを軟バッファに格納するときに必ずＭＮにおいてタイマーを開始することができる。より詳細には、ＭＮがマルチキャストデータパケットを適切な軟バッファ領域に格納するときにタイマーを開始することができる。そして、タイマーが経過した時点で、ＭＮはバッファをフラッシュする。これによって、ＨＡＲＱプロセスおよびそれに関連付けられている軟バッファ領域が使用されることなく長時間にわたり確保されることが回避される。

以下では、本発明の第２の態様を中心に説明し、この態様においては、マルチキャスト送信を「通常の」ユニキャスト送信とみなし、したがってＨＡＲＱプロトコルの動作に関して同様に扱う。ＨＡＲＱプロトコルのユニキャスト動作とマルチキャスト動作とが厳密に分けられて独立している本発明の第１の態様とは異なり、本発明の第２の態様によると、ＨＡＲＱ動作は、ユニキャストおよびマルチキャストに依存する。具体的には、ユニキャスト送信およびマルチキャスト送信は、同じＨＡＲＱプロセスおよび関連付けられる軟バッファ領域を使用する。すでに上述したように、ユニキャスト送信のＨＡＲＱプロトコルが正しく動作するためには、ｅＮＢにおけるスケジューラが、ＤＬユニキャスト送信に使用できるＨＡＲＱプロセスを認識している必要がある。このことは、本発明の第１の態様においては、ユニキャストとマルチキャストとを分離しておくことによって達成されていた。本発明の第２の態様には、この分離が適用されないため、受信された（かつ正しく送信されなかった）マルチキャストデータパケットに対してＭＮによって選択されるプロセスをｅＮＢは認識しておらず、この情報をユニキャスト送信のために利用することができない。

マルチキャストデータを軟バッファに格納するための特定の規則を定義する必要があり、この規則はＭＮのみならずｅＮＢも認識している。

本発明の第１の態様と比較すると、ユニキャストおよびマルチキャストのために軟バッファを構成設定する必要はない。すなわち、ＨＡＲＱプロセスの分配は実行されない。さらに、プロセスそれぞれがユニキャスト送信およびマルチキャスト送信に使用され得るため、特定のサービスのピークデータレートに従って軟バッファ領域の大きさを設定することも不可能である。結果として、各ＨＡＲＱプロセスに同じ量の軟バッファを関連付けることができる。

あるいは、ＨＡＲＱプロセスに関連付けられている軟バッファ領域が、さまざまな量の軟バッファを有することもできる。軟バッファの初期構成設定は、ＭＮのオペレータ（operator）によって実行および決定することができる。

しかしながら、特定のＭＮがマルチキャスト送信に対して軟合成機能を使用しているかをｅＮＢが認識していることは有利であり、なぜなら、軟合成のサポートはＭＮにおいてオプションにすぎないためである。認識していない場合、ｅＮＢは、ＭＮが軟合成を適用しており、したがって受信したマルチキャスト送信に対するＨＡＲＱプロセスを選択するためのＭＮ内の規則にも従うものと、つねに想定する。このことは、ＭＮが実際にはマルチキャスト送信に対して軟合成を使用していない場合に、ＨＡＲＱプロセスの利用が非効率的なものとなる。したがって、ＭＮがマルチキャストに対する軟合成をサポートするか否かを決定した後、その決定をｅＮＢにシグナリングする。図５に示したものに類似するシグナリングフローを、この場合にも適用することができる。

さらには、ＭＮがマルチキャストデータの送信に使用する予定であるＨＡＲＱプロセスの最大数を、ＵＥがｅＮＢに示すこともできる。この点において、ＭＮは、マルチキャストに対する軟合成のサポートについて決定した後、次に、マルチキャストデータに対して自身がサポートするＨＡＲＱプロセスの最大数を決定することができる。マルチキャスト送信のＨＡＲＱ動作のために移動ノードが使用する予定であるＨＡＲＱプロセスの最大数をｅＮＢが認識していなければ、ｅＮＢは、最悪の想定（例えば、移動ノードが、サブスクライブしているすべてのＭＢＭＳサービスに対して軟合成をサポートする）を行わざるを得ないことがある。したがって、移動ノードとｅＮＢとの間でステータスを同期させることができるようにする目的で、ｅＮＢは、マルチキャスト送信に使用されるＨＡＲＱプロセスの最大数を認識しているべきである。本発明の別の実施形態においては、移動局が軟合成を用いるＨＡＲＱ動作をサポートする特定のＭＢＭＳサービスについても、ｅＮＢに知らせることができる。

図７は、ＨＡＲＱプロセスの例示的なステータスを示しており、以下では、正しく受信されなかったマルチキャストデータパケットに対する軟合成がサポートされるようにＨＡＲＱプロセスを選択するための規則の使用について、この図に基づいて説明する。図から明らかであるように、ＨＡＲＱプロセス１，３，４，６，７，８）はユニキャスト送信によってすでに占有されている。ＨＡＲＱプロセス２および５は空いており、ユニキャスト送信またはマルチキャスト送信のいずれかに使用することができる。

なお、以下では特定の規則を中心に説明するが、別の規則を定義することもできる。ＭＮおよびｅＮＢの両方に既知である任意の規則によって、空いている特定のＨＡＲＱプロセスにユニキャストデータパケットを正しく割り当てるための十分な情報をｅＮＢに提供できることが、当業者には明らかであろう。

以下の規則によると、ＭＮは、データを正しく復号できなかった場合に、最初のＨＡＲＱプロセス（ＨＡＲＱプロセスＩＤ＝１）を起点として最初の空いているＨＡＲＱプロセスにマルチキャスト送信を格納する。空いているＨＡＲＱプロセスとは、関連付けられている軟バッファ領域にその時点においてデータが格納されていないプロセスである。図７によるＨＡＲＱプロトコルのステータスを参照し、ＭＮは、（正しく復号されなかった）受信されたマルチキャストデータパケットをＨＡＲＱプロセス２に割り当て、なぜなら、ＨＡＲＱプロセス２は、空いているＨＡＲＱプロセスのうちＨＡＲＱプロセスＩＤが最も小さいプロセスであるためである。したがって、ｅＮＢのスケジューラは、ＤＬユニキャスト送信に対してこのＨＡＲＱプロセスを使用しない。より詳細には、ｅＮＢは、自身がそれまでに送信したユニキャスト送信に基づいて、ＨＡＲＱプロセス１，３，４，６，７，８のステータスを認識している。さらには、ｅＮＢは、いま送信したばかりのマルチキャストデータパケットが、ｅＮＢにも格納されている規則に従うＨＡＲＱプロセスＩＤにＭＮによって割り当てられるであろうことを推測する。したがって、ｅＮＢは、ＨＡＲＱプロセス２がもはや利用可能ではなく、マルチキャストデータパケットの送信のために確保されていることを認識する。したがって、ｅＮＢは、次回のユニキャスト送信をＨＡＲＱプロセス５（残っている唯一の利用可能なＨＡＲＱプロセス）に割り当てる。

あるいは、別の規則として、空いているＨＡＲＱプロセスのうちＨＡＲＱプロセスＩＤが最も高いプロセスを使用するようにＭＮに指示することができ、この場合、ＭＮは、受信したが正しく復号できなかったマルチキャストデータパケットに、図７におけるＨＡＲＱプロセス５を割り当てる。当業者には、このように別の規則も創案できるであろう。

本発明の第１の態様による、軟バッファ領域をフラッシュする動作と同様に、マルチキャストデータパケットの入った軟バッファ領域をフラッシュするための規則を確立しておく必要がある。この場合も、フラッシュ動作をタイマーによってトリガーすることができ、タイマーは、マルチキャストデータパケットを特定の軟バッファ領域に格納するときに開始することができる。

本発明の第２の態様におけるＨＡＲＱ動作は、本発明の第１の態様によるＨＡＲＱ動作と比較して異なる点として、マルチキャスト送信がユニキャスト送信に依存し、ユニキャスト送信がマルチキャスト送信に依存する。すなわち、マルチキャストに使用されるＨＡＲＱプロセスは、ユニキャスト送信に使用されるＨＡＲＱプロセスのその時点のステータスに依存する。

したがって、ユニキャスト送信に対するＨＡＲＱフィードバックに誤りが発生してＭＮとｅＮＢとの間でＨＡＲＱバッファのステータスが同期していない場合、移動ノードが、ｅＮＢによって予測されるものとは異なるＨＡＲＱプロセスにマルチキャストデータパケットを格納するという状況が起こりうる。例えば、図７のＨＡＲＱプロセスを考えると、ＨＡＲＱプロセス２に割り当てられているユニキャストデータパケットをＭＮが受信する。ＭＮは、そのユニキャストデータパケットを正しく復号し、ｅＮＢにＡＣＫメッセージを送信する。しかしながら、フィードバックの誤りに起因して、ｅＮＢはこのユニキャストデータパケットに対してＮＡＣＫメッセージを受信する。結果として、ｅＮＢは、ＭＮがそのユニキャストデータパケットを正しく復号できなかったものと認識し、そのユニキャストデータパケットの再送信を行う。さらには、その後にマルチキャストデータパケットがＭＮに送信される場合、ＭＮは、そのマルチキャストデータパケットを受信して復号に失敗したとき、上述した規則に従ってそのマルチキャストデータパケットをＨＡＲＱプロセス２に割り当てる。しかしながら、ｅＮＢは、そのマルチキャストデータパケットに対応するＮＡＣＫをＭＮから受信したとき、ＭＮがそのマルチキャストデータパケットをＨＡＲＱプロセス５に格納したものと予測する。

結果として、いくつかの衝突が起こりうる。このような問題は本発明の第１の態様によるＨＡＲＱ動作においては存在せず、なぜなら、ＨＡＲＱプロトコルの動作がユニキャストデータ送信とマルチキャストデータ送信との間で厳密に分けられているためである。

本発明のもう１つの実施形態は、上述したさまざまな実施形態を、ハードウェアおよびソフトウェアを使用して実施することに関する。本発明のさまざまな実施形態は、コンピューティングデバイス（プロセッサ）を使用して実施または実行できることが認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはその他のプログラマブルロジックデバイスとすることができる。本発明のさまざまな実施形態は、これらのデバイスの組合せによって実行あるいは具体化することもできる。

さらに、本発明のさまざまな実施形態は、ソフトウェアモジュールによって実施することもでき、これらのソフトウェアモジュールは、プロセッサによって実行される、あるいはハードウェアにおいて直接実行される。さらに、ソフトウェアモジュールとハードウェア実装とを組み合わせることも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納することができる。

ここまでの段落では、本発明のさまざまな実施形態およびそのバリエーションを説明してきた。本発明には、具体的な実施形態に示したように、広義に記載されている本発明の概念または範囲から逸脱することなく、膨大なバリエーションもしくは変更形態を創案できることが、当業者には理解されるであろう。

さらに、ほとんどの実施形態は、３ＧＰＰをベースとする通信システムに関連して概説してあり、ここまでの説明において使用されている専門用語は、主として３ＧＰＰの専門用語に関連していることに留意されたい。しかしながら、専門用語と、さまざまな実施形態の説明とが、３ＧＰＰをベースとするアーキテクチャに関連していることは、本発明の原理および発想をそのようなシステムに限定することを意図するものではない。

さらに、上の［背景技術］のセクションに示した詳細な説明は、本明細書中に説明した、ほとんどが３ＧＰＰに固有な例示的な実施形態を深く理解することを意図したものであり、移動通信ネットワークにおけるプロセスおよび機能の、説明した特定の実施形態に、本発明を制限するものではないことを理解されたい。しかしながら、本文書に提案されている改良・改善は、［背景技術］のセクションに説明したアーキテクチャにただちに適用することができる。さらに、本発明のコンセプトは、３ＧＰＰによって現在討議されているＬＴＥ ＲＡＮにおいても、ただちに使用することができる。

Claims (18)

1. ユニキャスト送信モードおよびマルチキャスト送信モードにおいて無線制御エンティティから移動ノードにデータパケットを送信する方法であって、再送プロトコルが、前記ユニキャストデータパケットおよび前記マルチキャストデータパケットを送信するために複数のプロセスを使用し、前記再送プロトコルが、それぞれが前記再送プロトコルの前記複数のプロセスの１つに関連付けられる複数の領域、から成る、前記移動ノードにおける受信バッファを使用して、前記移動ノードによって正しく復号できなかった受信されたデータパケットを、対応する再送データパケットと一緒に後から使用できるように、格納し、
   前記移動ノードが、前記移動ノードにおける前記再送プロトコルの前記受信バッファを、前記ユニキャスト送信モードおよび前記マルチキャスト送信モードにおいて使用できるように構成設定する構成設定ステップであって、前記受信バッファがユニキャストセクションとマルチキャストセクションとに分割され、前記受信バッファの前記複数の領域と、関連付けられている前記複数のプロセスとが、前記ユニキャストセクションおよび前記マルチキャストセクションの間で分配される、前記構成設定ステップと、
   前記ユニキャストセクションおよび前記マルチキャストセクションの間での前記領域および関連付けられている前記プロセスの前記分配について、前記移動ノードが前記無線制御エンティティに知らせる通知ステップと、
   前記無線制御エンティティによって、ユニキャストデータパケットを前記移動ノードに送信する第１の送信ステップであって、前記ユニキャストデータパケットが、前記受信バッファの前記ユニキャストセクションに属しているプロセスに割り当てられている、前記第１の送信ステップと、
   前記無線制御エンティティによって、マルチキャストデータパケットを前記移動ノードに送信する第２の送信ステップであって、前記マルチキャストデータパケットが、前記受信バッファの前記マルチキャストセクションに割り当てられている、前記第２の送信ステップと、
   を含んでいる、方法。
2. 前記移動ノードが、前記無線制御エンティティからマルチキャストデータパケットを受信した時点で、前記マルチキャストデータパケットを正しく復号できない場合に、前記マルチキャストデータパケットを、前記マルチキャストセクションに属しているプロセスに割り当てる、請求項１に記載の方法。
3. 前記再送プロトコルの前記受信バッファを構成設定する前記構成設定ステップが、
   前記ユニキャストセクションおよび前記マルチキャストセクションに割り当てられるプロセスの数を決定する決定ステップと、
   前記ユニキャストセクションおよび前記マルチキャストセクションに割り当てられる前記プロセスのそれぞれに関連付けられる、前記受信バッファの前記対応する領域を構成する、前記受信バッファの量、を決定する決定ステップと、
   を含んでおり、
   プロセスの前記数と、前記ユニキャストセクションおよび前記マルチキャストセクションに割り当てられるプロセスに関連付けられる領域それぞれの受信バッファの前記量とが、前記無線制御エンティティに知らされる、
   請求項１または請求項２に記載の方法。
4. 前記領域の前記分配について前記無線制御エンティティに知らせる前記通知ステップが、
   前記移動ノードから前記無線制御エンティティに構成設定情報メッセージを送信する第３の送信ステップであって、前記構成設定情報メッセージがビットマップを備えており、前記ビットマップの各ビットが、前記再送プロトコルの前記複数のプロセスのうちの１つのプロセスに対応しており、前記ビットマップの各ビットが、前記対応するプロセスが前記受信バッファの前記ユニキャストセクションに属しているのかまたは前記マルチキャストセクションに属しているのか、を示している、前記第３の送信ステップ、
   を含んでいる、
   請求項１または請求項３に記載の方法。
5. 前記領域の前記分配について前記無線制御エンティティに知らせる前記通知ステップが、
   前記移動ノードから前記無線制御エンティティに構成設定情報メッセージを送信する第４の送信ステップであって、前記構成設定情報メッセージが、前記複数のプロセスのうち前記受信バッファの前記ユニキャストセクションに割り当てられているプロセスの識別情報を備えている、もしくは、前記複数のプロセスのうち前記受信バッファの前記マルチキャストセクションに割り当てられているプロセスの識別情報を備えている、またはその両方を備えている、前記第４の送信ステップ、
   を含んでいる、
   請求項１から請求項３のいずれかに記載の方法。
6. 受信されたマルチキャストデータパケットを格納している、前記マルチキャストセクションの領域が、タイマーが経過した時点で空にされ、前記タイマーが、前記再送プロトコルが前記マルチキャストセクションの前記領域に前記マルチキャストデータパケットを格納するときに開始される、請求項１から請求項５のいずれかに記載の方法。
7. ユニキャスト送信モードおよびマルチキャスト送信モードにおいて移動ノードにデータパケットを送信する無線制御エンティティであって、再送プロトコルが、前記ユニキャストデータパケットおよび前記マルチキャストデータパケットを送信するために複数のプロセスを使用し、前記再送プロトコルが、それぞれが前記再送プロトコルの前記複数のプロセスの１つに関連付けられる複数の領域、から成る、前記移動ノードにおける受信バッファを使用して、前記移動ノードによって正しく復号できなかった受信されたデータパケットを、対応する再送データパケットと一緒に後から使用できるように、中に格納し、
   ユニキャストセクションおよびマルチキャストセクションへの前記受信バッファの分割についてと、前記ユニキャストセクションおよび前記マルチキャストセクションの間での前記領域および関連付けられている前記プロセスの分配についての情報を、前記移動ノードから受信するようにされている受信器と、
   ユニキャストデータパケットを前記移動ノードに送信するようにされている送信器であって、前記ユニキャストデータパケットが、前記受信バッファの前記ユニキャストセクションに属しているプロセスに割り当てられている、前記送信器と、
   を備えており、
   前記送信器が、マルチキャストデータパケットを前記移動ノードに送信するようにさらにされており、前記マルチキャストデータパケットが、前記受信バッファの前記マルチキャストセクションに割り当てられている、
   無線制御エンティティ。
8. 前記移動ノードが、前記ユニキャストセクションおよび前記マルチキャストセクションに割り当てられるプロセスの数を決定し、前記ユニキャストセクションおよび前記マルチキャストセクションに割り当てられる前記プロセスのそれぞれに関連付けられる、前記受信バッファの前記対応する領域を構成する、前記受信バッファの量、を決定し、
   前記受信器が、決定されたプロセスの前記数と、プロセスに関連付けられる領域それぞれの決定された受信バッファの前記量と、に関する情報を、前記移動ノードから受信するようにさらにされている、
   請求項７に記載の無線制御エンティティ。
9. 前記受信器が、ビットマップを備えている構成設定情報メッセージを前記移動ノードから受信するようにさらにされており、前記ビットマップの各ビットが、前記再送プロトコルの前記複数のプロセスのうちの１つのプロセスに対応しており、前記ビットマップの各ビットが、前記対応するプロセスが前記受信バッファの前記ユニキャストセクションに属しているのかまたは前記マルチキャストセクションに属しているのか、を示している、
   請求項７または請求項８に記載の無線制御エンティティ。
10. 前記受信器が、構成設定情報メッセージを前記移動ノードから受信するようにさらにされており、前記構成設定情報メッセージが、前記複数のプロセスのうち前記受信バッファの前記ユニキャストセクションに割り当てられているプロセスの識別情報を備えている、もしくは、前記複数のプロセスのうち前記受信バッファの前記マルチキャストセクションに割り当てられているプロセスの識別情報を備えている、またはその両方を備えている、
    請求項７または請求項８に記載の無線制御エンティティ。
11. 前記送信器が、前記移動ノードにおいて前記マルチキャストデータパケットを受信できるようにする第２の制御情報、を前記移動ノードに送信するようにさらにされており、前記第２の制御情報が、対応するデータパケットがマルチキャスト送信モードにおいて前記移動ノードに送信されることを示す所定のインジケータ、を備えている、
    請求項７から請求項１０のいずれかに記載の無線制御エンティティ。
12. ユニキャスト送信モードおよびマルチキャスト送信モードにおいて無線制御エンティティから送信されるデータパケットを受信する移動ノードであって、再送プロトコルが、前記ユニキャストデータパケットおよび前記マルチキャストデータパケットを送信するために複数のプロセスを使用し、前記再送プロトコルが、それぞれが前記再送プロトコルの前記複数のプロセスの１つに関連付けられる複数の領域、から成る、前記移動ノードにおける受信バッファを使用して、前記移動ノードによって正しく復号できなかった受信されたデータパケットを、対応する再送データパケットと一緒に後から使用できるように、格納し、
    前記再送プロトコルの前記受信バッファを、前記ユニキャスト送信モードおよび前記マルチキャスト送信モードにおいて使用できるように構成設定するようにされているプロセッサであって、前記構成設定が、
    前記受信バッファをユニキャストセクションとマルチキャストセクションとに分割するステップと、
    前記受信バッファの前記複数の領域と、関連付けられている前記複数のプロセスとを、前記ユニキャストセクションおよび前記マルチキャストセクションの間で分配するステップと、
    によって行われる、前記プロセッサと、
    前記受信バッファの前記ユニキャストセクションに属しているプロセスに割り当てられているユニキャストデータパケットを、前記無線制御エンティティから受信するようにされている受信器と、
    を備えており、
    前記受信器が、前記受信バッファの前記マルチキャストセクションに割り当てられているマルチキャストデータパケットを、前記無線制御エンティティから受信するようにさらにされている、
    移動ノード。
13. 受信されたマルチキャストデータパケットを、自身が正しく復号できない場合に、前記マルチキャストセクションに属しているプロセスに割り当てるようにされているプロセッサ、
    をさらに備えている、請求項１２に記載の移動ノード。
14. 前記プロセッサが、前記ユニキャストセクションおよび前記マルチキャストセクションに割り当てられるプロセスの数を決定するようにさらにされており、
    前記プロセッサが、前記ユニキャストセクションおよび前記マルチキャストセクションに割り当てられる前記プロセスのそれぞれに関連付けられる、前記受信バッファの前記対応する領域を構成する、前記受信バッファの量、を決定するようにさらにされており、
    プロセスの前記数と、プロセスに関連付けられる領域それぞれの受信バッファの前記量とを、前記無線制御エンティティに知らせるようにされている送信器、
    をさらに備えている、請求項１２または請求項１３に記載の移動ノード。
15. ビットマップを備えている構成設定メッセージを前記無線制御エンティティに送信するようにされている送信器であって、前記ビットマップの各ビットが前記複数のプロセスのうちの１つのプロセスに対応しており、前記ビットマップの各ビットが、前記対応するプロセスが前記ユニキャストセクションに属しているのかまたは前記マルチキャストセクションに属しているのか、を示している、前記送信器、
    をさらに備えている、請求項１２から請求項１４のいずれかに記載の移動ノード。
16. 構成設定メッセージを前記無線制御エンティティに送信するようにされている送信器であって、前記構成設定メッセージが、前記複数のプロセスのうち前記ユニキャストセクションに割り当てられているプロセスの識別情報を備えている、もしくは、前記マルチキャストセクションに割り当てられているプロセスの識別情報を備えている、またはその両方を備えている、前記送信器、
    をさらに備えている、請求項１２から請求項１４のいずれかに記載の移動ノード。
17. 前記受信器が、前記移動ノードにおいて前記マルチキャストデータパケットを受信できるようにする第２の制御情報、を前記無線制御エンティティから受信するようにさらにされており、前記第２の制御情報が、対応するデータパケットがマルチキャスト送信モードにおいて前記移動ノードに送信されることを示す所定のインジケータ、を備えており、
    前記プロセッサが、前記受信されたマルチキャストデータパケットを、前記第２の制御情報における前記所定のインジケータに基づいて、前記マルチキャスト送信モードにおいて送信されたデータパケットとして識別するようにされており、
    前記プロセッサが、前記マルチキャストデータパケットを自身が正しく復号できない場合に、前記マルチキャストデータパケットを、前記マルチキャストセクションに属しているプロセスに関連付けられている領域に格納するように、さらにされている、
    請求項１２から請求項１６のいずれかに記載の移動ノード。
18. 前記プロセッサが、受信されたマルチキャストデータパケットを格納している、前記受信バッファの領域を、タイマーが経過した時点で空にするようにされており、
    前記プロセッサが、前記受信バッファの前記領域に前記マルチキャストデータパケットが格納されるとき、前記タイマーを開始するようにされている、
    請求項１２から請求項１７のいずれかに記載の移動ノード。

Images