特許 6771489 無線通信システムにおける複数個のサブフレーム上の上りリンク承認に基づいてＡＣＫ／ＮＡＣＫを指示する方法及びその装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6771489

(24)【登録日】2020年10月1日

(45)【発行日】2020年10月21日

(54)【発明の名称】無線通信システムにおける複数個のサブフレーム上の上りリンク承認に基づいてＡＣＫ／ＮＡＣＫを指示する方法及びその装置

(51)【国際特許分類】

   H04W 72/14 20090101AFI20201012BHJP

   H04W 28/04 20090101ALI20201012BHJP

【ＦＩ】

   H04W72/14

   H04W28/04 110

【請求項の数】8

【全頁数】29

(21)【出願番号】特願2017-556736(P2017-556736)

(86)(22)【出願日】2016年5月18日

(65)【公表番号】特表2018-522436(P2018-522436A)

(43)【公表日】2018年8月9日

(86)【国際出願番号】KR2016005240

(87)【国際公開番号】WO2016190592

(87)【国際公開日】20161201

【審査請求日】2019年5月13日

(31)【優先権主張番号】62/165,213

(32)【優先日】2015年5月22日

(33)【優先権主張国】US

(31)【優先権主張番号】62/172,820

(32)【優先日】2015年6月9日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502032105

【氏名又は名称】エルジー エレクトロニクス インコーポレイティド

(74)【代理人】

【識別番号】100109841

【弁理士】

【氏名又は名称】堅田 健史

(74)【代理人】

【識別番号】230112025

【弁護士】

【氏名又は名称】小林 英了

(74)【代理人】

【識別番号】230117802

【弁護士】

【氏名又は名称】大野 浩之

(74)【代理人】

【識別番号】100131451

【弁理士】

【氏名又は名称】津田 理

(74)【代理人】

【識別番号】100167933

【弁理士】

【氏名又は名称】松野 知紘

(74)【代理人】

【識別番号】100174137

【弁理士】

【氏名又は名称】酒谷 誠一

(74)【代理人】

【識別番号】100184181

【弁理士】

【氏名又は名称】野本 裕史

(72)【発明者】

【氏名】リ，スンヨン

(72)【発明者】

【氏名】イ，スンジュン

【審査官】 三枝 保裕

(56)【参考文献】

【文献】 欧州特許出願公開第０２１６１９６０（ＥＰ，Ａ２）

【文献】 国際公開第２０１３／１６４１０５（ＷＯ，Ａ１）

【文献】 特表２０１１−５２０３７８（ＪＰ，Ａ）

【文献】 特表２０１１−５３０９２７（ＪＰ，Ａ）

【文献】 Alcatel-Lucent，Multi-Process Transmission Technique to Improve Uplink Coverage for LTE[online]，3GPP TSG-RAN WG1#51b R1-080443，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_51b/Docs/R1-080443.zip＞，２００８年 １月１８日

【文献】 Alcatel-Lucent，On the Time Duration Field in the Uplink Scheduling Grant[online]，3GPP TSG-RAN WG1#51 R1-074991，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_51/Docs/R1-074991.zip＞，２００７年１１月 ９日

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｗ ４／００−９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

無線通信システムにおいて動作する端末（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）に対する方法であって、
基地局から上りリンク承認を受信した時、タイマーを作動させ、前記上りリンク承認は、前記タイマーが作動する間に有効であるステップと、
前記タイマーの作動中に、データが生成された時、前記上りリンク承認上で前記データを送信するステップと、
サブフレームで前記送信されたデータに対する肯定（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ；ＡＣＫ）指示子及び否定（Ｎｅｇａｔｉｖｅ−Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ；ＮＡＣＫ）指示子をモニタするステップと、
前記サブフレームで前記肯定指示子が受信されなかった時、又は否定指示子が受信された時、前記タイマーが作動中であるか否かを判定するステップと、
前記タイマーが作動中であるとの判定に基づいて、前記上りリンク承認上で前記データを再送信するステップと、
前記タイマーが作動中でないとの判定に基づいて、前記上りリンク承認を廃棄し、前記データを維持するステップと、
を含む、方法。

【請求項2】

前記上りリンク承認が廃棄される時、バッファ状態報告（Ｂｕｆｆｅｒ ｓｔａｔｕｓ ｒｅｐｏｒｔｉｎｇ；ＢＳＲ）をトリガーするステップをさらに含む、請求項１に記載の方法。

【請求項3】

前記タイマーの値は無線リソース制御（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ；ＲＲＣ）信号を介して基地局によって設定されたり、あらかじめ設定されたり、又は上りリンクリソースと共に受信される、請求項１に記載の方法。

【請求項4】

前記タイマー値は、２つ以上の連続するサブフレームである、請求項３に記載の方法。

【請求項5】

無線通信システムにおいて動作する端末（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）であって、
無線通信（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ；ＲＦ）モジュールと、
前記無線通信モジュールと相互動作するプロセッサと、
を備え、
前記プロセッサは、
基地局から上りリンク承認を受信した時、タイマーを作動させ、前記上りリンク承認は、前記タイマーが作動する間に有効であり、
前記タイマーの作動中に、データが生成された時、前記上りリンク承認上で前記データを送信し、
サブフレームで前記送信されたデータに対する肯定（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ；ＡＣＫ）指示子及び否定（Ｎｅｇａｔｉｖｅ−Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ；ＮＡＣＫ）指示子をモニタし、
前記サブフレームで前記肯定指示子が受信されなかった時、又は否定指示子が受信された時、前記タイマーが作動中であるか否かを判定し、
前記タイマーが作動中であるとの判定に基づいて、前記上りリンク承認上で前記データを再送信し、
前記タイマーが作動中でないとの判定に基づいて、前記上りリンク承認を廃棄し、前記データを維持する、
端末。

【請求項6】

前記プロセッサは、さらに、前記上りリンク承認が廃棄される時、バッファ状態報告（Ｂｕｆｆｅｒ ｓｔａｔｕｓ ｒｅｐｏｒｔｉｎｇ；ＢＳＲ）をトリガーする、請求項５に記載の端末。

【請求項7】

前記タイマーの値は無線リソース制御（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ；ＲＲＣ）信号を介して基地局によって設定されたり、あらかじめ設定されたり、又は上りリンクリソースと共に受信される、請求項５に記載の端末。

【請求項8】

前記タイマー値は、２つ以上の連続するサブフレームである、請求項７に記載の端末。

【発明の詳細な説明】

【技術分野】

【0001】

[1] 本発明は無線通信システムに関し、特に、無線通信システムにおける複数個のサブフレーム上の上りリンク承認に基づいてＡＣＫ／ＮＡＣＫを指示する方法及びその装置に関する。

【背景技術】

【0002】

[2] 本発明を適用できる無線通信システムの一例として、３ＧＰＰ ＬＴＥ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ；以下、“ＬＴＥ”という）通信システムについて概略的に説明する。

【0003】

[3] 図１は、無線通信システムの一例として、Ｅ−ＵＭＴＳ網の構造を概略的に示した図である。Ｅ−ＵＭＴＳ（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）は、既存のＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）から進化したシステムであって、現在、３ＧＰＰで基礎的な標準化作業を進めている。一般に、Ｅ−ＵＭＴＳは、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）システムと称することもできる。ＵＭＴＳ及びＥ−ＵＭＴＳの技術規格（ｔｅｃｈｎｉｃａｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ）の詳細な内容は、それぞれ「３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ；Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｇｒｏｕｐ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ」のＲｅｌｅａｓｅ ７とＲｅｌｅａｓｅ ８を参照することができる。

【0004】

[4] 図１を参照すると、Ｅ−ＵＭＴＳは、端末（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ；ＵＥ）、基地局（ｅＮｏｄｅ Ｂ；ｅＮＢ）、及びネットワーク（Ｅ−ＵＴＲＡＮ）の終端に位置し、外部ネットワークと接続される接続ゲートウェイ（Ａｃｃｅｓｓ Ｇａｔｅｗａｙ；ＡＧ）を含む。基地局は、ブロードキャストサービス、マルチキャストサービス及び／またはユニキャストサービスのために多重データストリームを同時に送信することができる。

【0005】

[5] 一つの基地局には一つ以上のセルが存在する。セルは、１．２５Ｍｈｚ、２．５Ｍｈｚ、５Ｍｈｚ、１０Ｍｈｚ、１５Ｍｈｚ、２０Ｍｈｚなどの帯域幅のうち一つに設定され、多くの端末にダウンリンクまたはアップリンク送信サービスを提供する。互いに異なるセルは、互いに異なる帯域幅を提供するように設定することができる。基地局は、多数の端末に対するデータ送受信を制御する。ダウンリンク（Ｄｏｗｎｌｉｎｋ；ＤＬ）データに対して、基地局は、ダウンリンクスケジューリング情報を送信し、該当の端末にデータが送信される時間／周波数領域、符号化、データサイズ、ＨＡＲＱ（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ａｎｄ ｒｅＱｕｅｓｔ）関連情報などを知らせる。また、アップリンク（Ｕｐｌｉｎｋ；ＵＬ）データに対して、基地局は、アップリンクスケジューリング情報を該当の端末に送信し、該当の端末が使用可能な時間／周波数領域、符号化、データサイズ、ＨＡＲＱ関連情報などを知らせる。各基地局間には、ユーザトラフィックまたは制御トラフィックの送信のためのインターフェースを使用することができる。核心網（Ｃｏｒｅ Ｎｅｔｗｏｒｋ；ＣＮ）は、ＡＧ及び端末のユーザ登録などのためのネットワークノードなどで構成することができる。ＡＧは、複数のセルで構成されるＴＡ（Ｔｒａｃｋｉｎｇ Ａｒｅａ）単位で端末の移動性を管理する。

【0006】

[6] 無線通信技術は、ＷＣＤＭＡに基づいてＬＴＥまで開発されてきたが、ユーザと事業者の要求と期待は持続的に増加している。また、他の無線接続技術が継続して開発されているので、今後、競争力を有するためには新たな技術進化が要求され、ビット当たりの費用減少、サービス可用性増大、融通性のある周波数バンドの使用、単純構造と開放型インターフェース、端末の適切なパワー消耗などが要求される。

【発明の概要】

【発明が解決しようとする課題】

【0007】

[7] 上記の問題点を解決するために考案された本発明の目的は、無線通信システムにおいて多数のサブフレームに対する上りリンク承認に基づいてＡＣＫ／ＮＡＣＫ指示を行う方法及び装置にある。本発明で遂げようとする技術的課題は以上に言及した技術的課題に制限されず、言及していない他の技術的課題は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者にとって明確に理解できるだろう。

【課題を解決するための手段】

【0008】

[8] 本発明の前記目的は請求範囲に記載したような無線通信システムにおける使用者端末（ＵＥ）の動作方法を提供することによって達成できる。

【0009】

[9] 本発明の他の態様において、請求範囲に記載したような通信装置が提供される。

【0010】

[10] 前記一般的な説明と以下の本発明の詳細な説明はいずれも例示的なもので、特許請求範囲に記載したような本発明をより詳細に説明するためのものである。

【発明の効果】

【0011】

[11] 本発明によれば、多重ＵＬ承認に対する多重ＰＤＣＣＨの伝送を防止することができる。これは、ＵＬ承認が有効な特定期間（多重サブフレーム）を提供することによって実現することができる。本発明は、特に、伝送可能となる時を概略予測できるデータに対するシグナリングのオーバーヘッドが減るという効果がある。

【0012】

[12] 本発明から得られる効果は、以上で言及した効果に制限されず、言及していない他の効果は、添付の図面と共に説明される以下の記載から、本発明の属する技術の分野における通常の知識を有する者にとっては明らかになるであろう。

【0013】

[13] 本明細書に添付する図面は、本発明に関する理解を提供するためのものであり、本発明の様々な実施の形態を示し、明細書の記載と共に本発明の原理を説明するためのものである。

【図面の簡単な説明】

【0014】

【図1】[14] 無線通信システムの一例であり、Ｅ―ＵＭＴＳネットワーク構造を概略的に示す図である。

【図2A】[15] 図２ＡはＥ―ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ―Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）構造を示すブロック図である。

【図2B】図２Ｂは一般的なＥ―ＵＴＲＡＮとＥＰＣの構造を示すブロック図である。

【図3】[16] ３ＧＰＰ無線接続網規格に基づく端末とＥ―ＵＴＲＡＮとの間における無線インターフェースプロトコル（Ｒａｄｉｏ Ｉｎｔｅｒｆａｃｅ Ｐｒｏｔｏｃｏｌ）の制御平面（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ）及びユーザ平面（Ｕｓｅｒ Ｐｌａｎｅ）の構造を示す図である。

【図4】[17] Ｅ―ＵＭＴＳシステムで用いられる物理チャネル構造の一例を示す図である。

【図5】[18] 本発明の実施例に係る通信装置を示すブロック図である。

【図6】[19] 競合ベース送信を行うための図の例示である。

【図7】[20] 競合ベースＳＲ手順を行うための図の例示である。

【図8】[21] 競合ベース送信を行うための図の例示である。

【図9】[22] ＵＥ側におけるＭＡＣ構造概要を示す図である。

【図10】[23] 上りリンク承認受信に対する概念図である。

【図11】[24] 本発明の実施例によって無線通信システムにおいてバッファ状態報告のトリガーに対する概念図である。

【図12】[25] 本発明の実施例によって無線通信システムにおいてバッファ状態報告をトリガーする例を示す図である。

【図13】[26] 本発明の実施例によって無線通信システムにおいて多数のサブフレームで上りリンク承認を設定するための概念図である。

【図14】本発明の実施例によって無線通信システムにおいて多数のサブフレームで上りリンク承認を設定するための概念図である。

【図15】[27] 本発明の実施例によって無線通信システムにおいて多数のサブフレームで上りリンク承認に基づいてＡＣＫ／ＮＡＣＫ指示を行うための概念図である。

【図16】本発明の実施例によって無線通信システムにおいて多数のサブフレームで上りリンク承認に基づいてＡＣＫ／ＮＡＣＫ指示を行うための概念図である。

【発明を実施するための形態】

【0015】

[28] ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）は、ヨーロッパシステム、ＧＳＭ（Ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、及びＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）に基盤したＷＣＤＭＡ（Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）で動作する３世代（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ、３Ｇ）非対称移動通信システムである。ＵＭＴＳのＬＴＥ（Ｌｏｎｇ―Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）は、ＵＭＴＳを規格化する３ＧＰＰによって議論中にある。

【0016】

[29] ３ＧＰＰ ＬＴＥは、高速パケット通信を可能にする技術である。ユーザ及び提供者の費用を減少させ、サービス品質を改善し、カバレッジ（ｃｏｖｅｒａｇｅ）及びシステム容量を拡張及び改善することを目的とするＬＴＥ課題のための多くの方法が提案された。３Ｇ ＬＴＥは、上位―レベル要求であって、ビット（ｂｉｔ）当たりの費用減少、増加したサービス可用性、周波数帯域の柔軟性、単純な構造、開放型インターフェース、及び端末の適切な電力消耗を要求する。

【0017】

[30] 以下で、添付の図面を参照して説明した本発明の各実施例により、本発明の構成、作用及び他の特徴が容易に理解され得るだろう。以下で説明する各実施例は、本発明の技術的特徴が３ＧＰＰシステムに適用された各例である。

【0018】

[31] 本明細書は、ＬＴＥシステム及びＬＴＥ―Ａシステムを用いて本発明の各実施例を説明するが、これは例示に過ぎない。したがって、本発明の各実施例は、前記定義に該当するいずれの通信システムにも適用することができる。また、本明細書は、ＦＤＤ方式を基準にして本発明の実施例に対して説明するが、これは例示であって、本発明の実施例は、Ｈ―ＦＤＤ方式又はＴＤＤ方式にも容易に変形して適用することができる。

【0019】

[32] 図２Ａは、Ｅ―ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ―Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）網構造を示すブロック図である。Ｅ―ＵＭＴＳは、ＬＴＥシステムと称することもできる。通信網は、ＩＭＳ及びパケットデータを通じたＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）などの多様なサービスを提供するために広く配置される。

【0020】

[33] 図２Ａに示したように、Ｅ―ＵＭＴＳ網は、Ｅ―ＵＴＲＡＮ（ｅｖｏｌｖｅｄ ＵＭＴＳ ｔｅｒｒｅｓｔｒｉａｌ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ）、ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）、及び一つ以上の端末を含む。Ｅ―ＵＴＲＡＮは、一つ以上のｅＮＢ（ｅｖｏｌｖｅｄ ＮｏｄｅＢ）２０を含むことができ、複数の端末１０が一つのセルに位置することができる。一つ以上のＥ―ＵＴＲＡＮ ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／ＳＡＥ（Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ）ゲートウェイ３０は、ネットワークの終端に位置し、外部ネットワークに接続することもできる。

【0021】

[34] 本明細書において、「ダウンリンク（ｄｏｗｎｌｉｎｋ）」は、ｅＮＢ２０から端末１０への通信を称し、「アップリンク（ｕｐｌｉｎｋ）」は、端末１０からｅＮＢ２０への通信を称する。端末１０は、ユーザによって運搬される通信装備を称し、また、移動局（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ、ＭＳ）、ユーザ端末（Ｕｓｅｒ Ｔｅｒｍｉｎａｌ、ＵＴ）、加入者ステーション（Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ、ＳＳ）又は無線デバイスと称することもできる。

【0022】

[35] 図２Ｂは、一般的なＥ―ＵＴＲＡＮと一般的なＥＰＣの構造を示すブロック図である。

【0023】

[36] 図２Ｂに示したように、ｅＮＢ２０は、ユーザ平面及び制御平面のエンドポイント（ｅｎｄ ｐｏｉｎｔ）をＵＥ１０に提供する。ＭＭＥ／ＳＡＥゲートウェイ３０は、セッション及び移動性管理機能のエンドポイントをＵＥ１０に提供する。ｅＮＢ２０及びＭＭＥ／ＳＡＥゲートウェイ３０は、Ｓ１インターフェースを介して接続することができる。

【0024】

[37] ｅＮＢ２０は、一般にＵＥ１０と通信する固定局であって、基地局（ＢＳ）又はアクセスポイント（ａｃｃｅｓｓ ｐｏｉｎｔ）と称することもある。一つのｅＮＢ２０はセルごとに配置することができる。ユーザトラフィック又は制御トラフィックを送信するためのインターフェースをｅＮＢ２０間で使用することができる。

【0025】

[38] ＭＭＥは、ｅＮＢ２０に対するＮＡＳシグナリング、ＮＡＳシグナリング保安、ＡＳ保安制御、３ＧＰＰ接続ネットワーク間の移動性のためのインター（ｉｎｔｅｒ）ＣＮノードシグナリング、（ページング再送信の制御及び実行を含む。）遊休モード（ｉｄｌｅ ｍｏｄｅ）ＵＥ接近性（Ｒｅａｃｈａｂｉｌｉｔｙ）、（遊休モード及び活性モード（ａｃｔｉｖｅ ｍｏｄｅ）のＵＥのための）トラッキング領域リスト管理、ＰＤＮ ＧＷ及びサービングＧＷ選択、ＭＭＥ変化が伴うハンドオーバーのためのＭＭＥ選択、２Ｇ又は３Ｇ ３ＧＰＰ接続ネットワークへのハンドオーバーのためのＳＧＳＮ選択、ローミング、認証、専用ベアラ設定を含むベアラ管理、（ＥＴＷＳ及びＣＭＡＳを含む）ＰＷＳメッセージ送信のためのサポートを含む多様な機能を行う。ＳＡＥゲートウェイホストは、パー―ユーザ（Ｐｅｒ―ｕｓｅｒ）ベースのパケットフィルタリング（例えば、深層パケット検査を使用）、適法なインターセプション（Ｌａｗｆｕｌ Ｉｎｔｅｒｃｅｐｔｉｏｎ）、ＵＥ ＩＰアドレス割り当て、ダウンリンクでの送信（Ｔｒａｎｓｐｏｒｔ）レベルパケットマーキング、ＵＬ及びＤＬサービスレベル課金、ゲーティング及びレート強化、ＡＰＮ―ＡＭＢＲに基づいたＤＬレート強化を含む多様な機能を提供する。ＭＭＥ／ＳＡＥゲートウェイ３０は、明確性のために、本明細書で単純に「ゲートウェイ」と称する。しかし、ＭＭＥ／ＳＡＥゲートウェイ３０は、ＭＭＥ及びＳＡＥゲートウェイの両者を全て含む。

【0026】

[39] 複数のノードは、ｅＮＢ２０とゲートウェイ３０との間でＳ１インターフェースを介して接続することができる。各ｅＮＢ２０は、Ｘ２インターフェースを介して相互接続することができ、各隣接ｅＮＢは、Ｘ２インターフェースを有するメッシュネットワーク構造（ｍｅｓｈｅｄ ｎｅｔｗｏｒｋ ｓｔｒｕｃｔｕｒｅ）を有することができる。

【0027】

[40] 図２Ｂに示したように、ｅＮＢ２０は、ゲートウェイ３０に対する選択、無線リソース制御（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ、ＲＲＣ）活性化の間、ゲートウェイに向かうルーティング、ページングメッセージのスケジューリング及び送信、ブロードキャストチャネル（ＢＣＣＨ）情報のスケジューリング及び送信、アップリンク及びダウンリンクの全てにおける各ＵＥ１０のための動的リソース割り当て、ｅＮＢ測定の構成及び準備、無線ベアラ制御、無線承認制御（Ｒａｄｉｏ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ、ＲＡＣ）、及びＬＴＥ＿ＡＣＴＩＶＥ状態での接続移動性制御などの各機能を行うことができる。ＥＰＣにおいて、ゲートウェイ３０は、ページング発信、ＬＴＥ＿ＩＤＬＥ状態管理、ユーザ平面暗号化、システム構造エボリューション（Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ、ＳＡＥ）ベアラ制御、及び非―接続層（Ｎｏｎ―Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ、ＮＡＳ）シグナリングの暗号化及び無欠性保護などの各機能を行うことができる。

【0028】

[41] ＥＰＣは、移動性管理エンティティ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ、ＭＭＥ）、サービング―ゲートウェイ（ｓｅｒｖｉｎｇ―ｇａｔｅｗａｙ、Ｓ―ＧＷ）、及びパケットデータネットワーク―ゲートウェイ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ―Ｇａｔｅｗａｙ、ＰＤＮ―ＧＷ）を含む。ＭＭＥは、主に各端末の移動性を管理する目的で用いられる接続及び可用性に対する情報を有する。Ｓ―ＧＷは、Ｅ―ＵＴＲＡＮを終端点として有するゲートウェイであり、ＰＤＮ―ＧＷは、パケットデータネットワーク（ＰＤＮ）を終端点として有するゲートウェイである。

【0029】

[42] 図３は、３ＧＰＰ無線接続網規格を基盤にした端末とＥ―ＵＴＲＡＮとの間の無線インターフェースプロトコルの制御平面及びユーザ平面の構造を示す図である。制御平面は、端末（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ；ＵＥ）とネットワークがコールを管理するために用いる各制御メッセージが送信される通路を意味する。ユーザ平面は、アプリケーション層で生成されたデータ、例えば、音声データ又はインターネットパケットデータなどが送信される通路を意味する。

【0030】

[43] 第１層である物理層は、物理チャネル（Ｐｈｙｓｉｃａｌ Ｃｈａｎｎｅｌ）を用いて上位層に情報送信サービス（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｒａｎｓｆｅｒ Ｓｅｒｖｉｃｅ）を提供する。物理層は、上位にある媒体接続制御（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層とは送信チャネル（Ｔｒａｎｓｐｏｒｔ Ｃｈａｎｎｅｌ）を介して接続されている。前記送信チャネルを介して媒体接続制御層と物理層との間にデータが移動する。送信側と受信側の物理層間には、物理チャネルを介してデータが移動する。前記物理チャネルは、時間と周波数を無線リソースとして活用する。具体的に、物理チャネルは、ダウンリンクでＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）方式で変調され、アップリンクでＳＣ―ＦＤＭＡ（Ｓｉｎｇｌｅ Ｃａｒｒｉｅｒ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）方式で変調される。

【0031】

[44] 第２層の媒体接続制御（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ；ＭＡＣ）層は、論理チャネル（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ）を介して上位層である無線リンク制御（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ；ＲＬＣ）層にサービスを提供する。第２層のＲＬＣ層は、信頼性のあるデータ送信をサポートする。ＲＬＣ層の機能は、ＭＡＣ内部の機能ブロックで具現することもできる。第２層のＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）層は、帯域幅の狭い無線インターフェースでＩＰバージョン４（ＩＰ ｖｅｒｓｉｏｎ ４、ＩＰｖ４）パケットやＩＰバージョン６（ＩＰｖ６）パケットのようなＩＰ（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）パケットを効率的に送信するために不必要な制御情報を減少させるヘッダー圧縮（Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）機能を行う。

【0032】

[45] 第３層の最下部に位置した無線リソース制御（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ；ＲＲＣ）層は、制御平面のみで定義される。ＲＲＣ層は、各無線ベアラ（Ｒａｄｉｏ Ｂｅａｒｅｒ；ＲＢ）の設定（Ｃｏｎｆｉｇｕｒａｔｉｏｎ）、再設定（Ｒｅ―ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び解除（Ｒｅｌｅａｓｅ）と関連して論理チャネル、送信チャネル及び物理チャネルの制御を担当する。ＲＢは、端末とネットワークとの間のデータ伝達のために第２層によって提供されるサービスを意味する。このために、端末とネットワークのＲＲＣ層は、互いにＲＲＣメッセージを交換する。

【0033】

[46] ｅＮＢの一つのセルは、１．２５ＭＨｚ、２．５ＭＨｚ、５ＭＨｚ、１０ＭＨｚ、１５ＭＨｚ及び２０ＭＨｚなどの各帯域のうち一つで動作するように設定することができ、帯域でダウンリンク又はアップリンク送信サービスを提供するように設定することができる。異なる各セルは、異なる各帯域を提供するように設定することもできる。

【0034】

[47] Ｅ―ＵＴＲＡＮから端末への送信のためのダウンリンク送信チャネル（Ｄｏｗｎｌｉｎｋ ｔｒａｎｓｐｏｒｔ Ｃｈａｎｎｅｌ）は、システム情報を送信するＢＣＨ（Ｂｒｏａｄｃａｓｔ Ｃｈａｎｎｅｌ）、各ページングメッセージを送信するＰＣＨ（Ｐａｇｉｎｇ Ｃｈａｎｎｅｌ）、及びユーザトラフィック又は各制御メッセージを送信するためのダウンリンク共有チャネル（Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ、ＳＣＨ）を含む。ダウンリンクマルチキャスト又はブロードキャストサービスのトラフィック又は制御メッセージの場合、ダウンリンクＳＣＨを介して送信することもでき、又は別途のダウンリンクＭＣＨ（Ｍｕｌｔｉｃａｓｔ Ｃｈａｎｎｅｌ）を介して送信することもできる。

【0035】

[48] 端末からネットワークにデータを送信するアップリンク送信チャネルとしては、初期制御メッセージを送信するＲＡＣＨ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）と、その他にユーザトラフィックや制御メッセージを送信するアップリンクＳＣＨ（Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）とがある。送信チャネルの上位にあり、送信チャネルにマップされる論理チャネルとしては、ＢＣＣＨ（Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＰＣＣＨ（Ｐａｇｉｎｇ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＣＣＣＨ（Ｃｏｍｍｏｎ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＭＣＣＨ（Ｍｕｌｔｉｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、及びＭＴＣＨ（Ｍｕｌｔｉｃａｓｔ Ｔｒａｆｆｉｃ Ｃｈａｎｎｅｌ）などがある。

【0036】

[49] 図４は、Ｅ―ＵＭＴＳシステムで使用する物理チャネル構造の一例を示した図である。物理チャネルは、時間軸上にある多数のサブフレームと、周波数軸上にある多数のサブキャリア（Ｓｕｂ―ｃａｒｒｉｅｒ）とで構成される。ここで、一つのサブフレーム（Ｓｕｂ―ｆｒａｍｅ）は、時間軸上に複数のシンボル（Ｓｙｍｂｏｌ）で構成される。一つのサブフレームは、複数のリソースブロック（Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ）で構成され、一つのリソースブロックは、複数のシンボル及び複数のサブキャリアで構成される。また、各サブフレームは、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、すなわち、Ｌ１／Ｌ２制御チャネルのために該当のサブフレームの特定シンボル（例えば、１番目のシンボル）の特定サブキャリアを用いることができる。図４には、Ｌ１／Ｌ２制御情報送信領域（ＰＤＣＣＨ）とデータ領域（ＰＤＳＣＨ）を示した。一実施例において、１０ｍｓの無線フレーム（ｒａｄｉｏ ｆｒａｍｅ）が使用され、一つの無線フレームは１０個のサブフレーム（ｓｕｂｆｒａｍｅ）で構成される。また、一つのサブフレームは二つの連続するスロットで構成される。一つのスロットの長さは０．５ｍｓである。また、一つのサブフレームは多数のＯＦＤＭシンボルで構成され、多数のＯＦＤＭシンボルのうち一部のシンボル（例えば、１番目のシンボル）は、Ｌ１／Ｌ２制御情報を送信するために使用することができる。データ送信のための時間単位である送信時間間隔（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ、ＴＴＩ）は１ｍｓである。

【0037】

[50] 基地局と端末は、一般に特定制御信号又は特定サービスデータを除いては、送信チャネルであるＤＬ―ＳＣＨを用いる物理チャネルであるＰＤＳＣＨを介してデータを送信／受信する。ＰＤＳＣＨのデータがいずれの端末（一つ又は複数の端末）に送信されるもので、前記各端末がどのようにＰＤＳＣＨデータを受信してデコード（ｄｅｃｏｄｉｎｇ）しなければならないのかに対する情報などは、ＰＤＣＣＨに含まれて送信される。

【0038】

[51] 例えば、特定ＰＤＣＣＨが「Ａ」というＲＮＴＩ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｔｙ）でＣＲＣマスク（ｍａｓｋｉｎｇ）されており、「Ｂ」という無線リソース（例えば、周波数位置）及び「Ｃ」という送信形式情報（例えば、送信ブロックサイズ、変調方式、コーディング情報など）を用いて送信されるデータに関する情報が特定サブフレームを通じて送信されると仮定する。この場合、セル内の端末は、自身が有しているＲＮＴＩ情報を用いてＰＤＣＣＨをモニタし、「Ａ」ＲＮＴＩを有している一つ以上の端末があると、前記各端末はＰＤＣＣＨを受信し、受信したＰＤＣＣＨの情報を通じて「Ｂ」と「Ｃ」によって指示されるＰＤＳＣＨを受信する。

【0039】

[52] 図５は、本発明の実施例に係る通信装置のブロック図である。

【0040】

[53] 図５に示された装置は、上述したメカニズムを行うように適応されたユーザ装置（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ＵＥ）及び／又はｅＮＢであってもよいが、同じ作業を行う任意の装置であってもよい。

【0041】

[54] 図５に示したように、装置は、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）／マイクロプロセッサ１１０及びＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）モジュール（送受信機；１３５）を含むこともできる。ＤＳＰ／マイクロプロセッサ１１０は、送受信機１３５に電気的に接続されて送受信機１３５を制御する。装置は、設計者の選択によって、電力管理モジュール１０５、バッテリ１５５、ディスプレイ１１５、キーパッド１２０、ＳＩＭカード１２５、メモリデバイス１３０、スピーカー１４５及び入力デバイス１５０をさらに含むこともできる。

【0042】

[55] 特に、図５は、ネットワークから要求メッセージを受信するように構成された受信機１３５、及びネットワークに送／受信タイミング情報を送信するように構成された送信機１３５を含む端末を示してもよい。このような受信機と送信機は送受信機１３５を構成できる。端末は、送受信機（受信機及び送信機、１３５）に接続されたプロセッサ１１０をさらに含むこともできる。

【0043】

[56] また、図５は、端末に要求メッセージを送信するように構成された送信機１３５、及び端末から送受信タイミング情報を受信するように構成された受信機１３５を含むネットワーク装置を示してもよい。送信機及び受信機は送受信機１３５を構成することもできる。ネットワークは、送信機及び受信機に接続されたプロセッサ１１０をさらに含む。このプロセッサ１１０は、送受信タイミング情報に基づいて遅延（ｌａｔｅｎｃｙ）を計算することもできる。

【0044】

[57] 図６は、競合ベース送信を行うための図の例示である。

【0045】

[58] アンローディング又は部分ローディングネットワークにおける典型的なインターネットトラフィックに対するレイテンシ（ｌａｔｅｎｃｙ）減少のための簡単でありながら効率的な一方法は、事前割り当て（Ｐｒｅ−ａｌｌｏｃａｔｉｏｎ）である。事前割り当ては、ＵＥがスケジューリング要求を送信せず、ＵＥにＵＬパケットを送信する機会を提供する事前スケジューリング（ｐｒｅ−ｓｃｈｅｄｕｌｉｎｇ）の形態である。同期化（ｉｎ−ｓｙｎｃ）要求時にスケジューリング要求手順には１０ｍｓが必要であり、これは、ＵＬリソースが端末のために事前スケジュールされないと、ＬＴＥが元のＬＴＥ要求仕様２５．９１３において定義された往復１０ｍｓ（片道２×５ｍｓ）遅延の元来のＲＡＮレイテンシ要求事項を支援できなくする。

【0046】

[59] 事前割り当ては、これらのリソースブロックが他のＵＥからの実際トラフィックに使用されないとき、送信するものを有しているＵＥにリソースブロック承認を提供する。ネットワークのための一つの可能性は、ＵＥからの或る肯定（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）（例えば、ピング（Ｐｉｎｇ）又はＴＣＰ ＡＣＫ）を必要とする可能性のある下りリンクパケットを用いて、ＵＬリソースのかかる事前割り当てをトリガーすることである。また、より一般化した方式が考慮されてもよい。

【0047】

[60] 事前割り当ては半静的（Ｓｅｍｉ−ｐｅｒｓｉｓｔｅｎｔ）スケジューリングなどの他の形態の事前スケジューリングと異なることに注意されたい。事前割り当ては、実際トラフィックによって使用されない時にＰＤＣＣＨを用いてＵＬリソースを承認（ｇｒａｎｔ）する。これに対し、半静的スケジューリングは、ＰＤＣＣＨ上における反復的なスケジューリング無しでＵＥに規則的な割り当てを提供する。

【0048】

[61] 一方、競合ベース（ｃｏｎｔｅｎｔｉｏｎ ｂａｓｅｄ（ＣＢ））送信の目標は、上りリンク同期化されたＵＥが、あらかじめスケジューリング要求を送らないで上りリンクデータを送信するようにすることにある。これは、レイテンシ及びシグナリングオーバーヘッドを減少させることができる。小さいデータパケットに対して、小さいパケットは、スケジュールされたチャネルよりもＣＢチャネル状でいっそう効率的に送信されるというトレードオフポイントが存在し得る。

【0049】

[62] ＣＢチャネルの一般的な特性は、データパケットが互いに衝突し得ることからエラーレートが増加するということである。衝突は、チャネルの最大スループットを減少させ、スループットは、提供されるロード（ｌｏａｄ）に敏感になる。提供されたロードがチャネル容量を超えて増加するように許容されると、衝突可能性は急に増加し、システムは不安定になり、スループットは減少する。したがって、ＣＢ送信が無競合（ｃｏｎｔｅｎｔｉｏｎ ｆｒｅｅ（ＣＦ））上りリンク送信と干渉しなく、ｅＮＢがＣＢ送信のためにリソースを割り当てる効率且つ迅速な手段を有することが最も重要である。

【0050】

[63] 上述のことを達成するための一方法は、ＣＦ上りリンク送信のために残していない上りリンクリソースブロックでのみＣＢ送信を許容することである。ＣＢ送信のための上りリンクリソースブロックの動的割り当ては、下りリンク物理制御チャネル（ＰＤＣＣＨ）を使用することによって達成することができる。ＰＤＣＣＨを使用することによって、ＣＢ承認がサブフレームごとに使用されないリソースに割り当てられ、上りリンクＣＦ送信のスケジューリングは影響を受けない。このような方式で、ＣＢリソースの静的割り当ては避けることができ、ＣＢリソースを上りリンクロードによって動的に割り当てることができる。

【0051】

[64] ＣＢ−ＲＮＴＩ（Ｃｏｎｔｅｎｔｉｏｎ Ｂａｓｅｄ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒｓ）がＰＤＣＣＨ上でＣＢ上りリンク承認を識別するために導入される。ＣＢ上りリンク承認はＲｅｌ−８ＵＥと同じフォーマットを有することができ、すなわち、上りリンクＣＢ送信に用いられるリソースブロック、変調及びコーディング方式、及び伝送フォーマットを特定することができる。Ｒｅｌ−１０ ＵＥは、自身の専用Ｃ−ＲＮＴＩにアドレスされた承認に加えて、それらのＣＢ−ＲＮＴＩにアドレスされたＣＢ上りリンク承認を聴取する（ｌｉｓｔｅｎ）ことができる。セル内の利用可能なＣＢ−ＲＮＴＩはＲＲＣ接続セットアップの間にそれぞれのＵＥにブロードキャスト又はシグナルされ得る。この方式は、Ｒｅｌ−１０以前のＵＥがＣＢ−ＲＮＴＩにアドレスされた承認をデコードできず、以前方式と互換が可能である。

【0052】

[65] 共通リソースが用いられることから、ＵＥを識別するために固有のＵＥ識別子がＭＡＣ ＰＤＵに必要である。Ｃ−ＲＮＴＩ ＭＡＣ制御エレメントをＣＢ上りリンクリソース上で送信されるそれぞれのＭＡＣ ＰＤＵに追加することができる。

【0053】

[66] ＵＥは専用ＣＦ承認を持っておらず、ＣＢ上りリンク承認上でのみ送信するように許容されなければならない。ＵＥは制限された数のサブフレームに対するＣＢリソースだけを使用するように許容され、これで衝突解決を改善する。ＣＢ送信と共に、ＵＥはスケジューリング要求も送信して無競合リソースを要求することができる。しかし、単一キャリア上りリンク特性を維持すべく、それらが同じサブフレームで送信され得ないことに注意されたい。

【0054】

[67] 競合ベース送信方式は、図６に示すとおりである。

【0055】

[68] 図６を参照すると、ｅＮｏｄｅＢはブロードキャスト又は専用シグナリングによって利用可能なＣＢ−ＲＮＴＩをＵＥに知らせる（Ａ）。ＵＥはＣＢ−ＲＮＴＩを受信し、利用可能なＣＢ承認に対するＰＤＣＣＨをモニタし始める（Ｂ）。ｅＮｏｄｅＢはＰＤＣＣＨ上でＣＢ承認をスケジュールし（Ｃ）、ＵＥはＣＢ承認を検出して、送信されるデータのＬ２＆Ｌ１プロセシングを行う（Ｄ）。ＵＥはＣＢ承認を用いてＰＵＳＣＨ上でデータを送信する（Ｅ）。

【0056】

[69] 提案された形態において、ＣＢ送信は同期化されたＵＥのためにのみ支援される。この形態において、現在の仕様への変更は小さいことが予想され、ＭＡＣ及びＲＲＣ仕様に主に影響を与えることができる。セクション３に提示されたとおり、例えば、ＴＣＰ性能において認知可能な利得が存在する。

【0057】

[70] 非同期化されたＵＥをカバーするために概念を拡張すると、物理層仕様に対する実質的な変更が必要である。非同期化されたＵＥに対して、送信はサブフレーム境界内で合わないことがあり、重複送信を避けるためにガード（ｇｕａｒｄ）時間が必要であり得る。また、ｅＮＢ受信機を同期化するために或る形態のプリアンブルが必要であってもよい。非同期化されたＵＥにＣＢ送信を拡張することが利得においては小さいと予想される。同期化されたＵＥに対する利得は６ｍｓ差の反復からもたらされる。非同期化されたＵＥに対しては、これは、後でＵＥが同期化されることがあるため、単にトランザクション（ｔｒａｎｓａｃｔｉｏｎ）ごとに一回発生し得る。したがって、非同期化されたＵＥからのＣＢ送信は、価値のあるソリューションとして考慮しない。

【0058】

[71] 図７は、競合ベースＳＲ手順を行うための図の例示である。

【0059】

[72] Ｒｅｌ−８において、ＳＲリソース及びシーケンスはＲＲＣシグナリングによってＵＥに割り当てられる。もちろん、より高いＰＵＣＣＨリソース消費を犠牲してより短いＳＲ周期性が得られる。理論的なＳＲ容量はＰＲＢ当たりに１８個のＵＥであり、１８０個のＵＥが支援されると、ＰＲＢの数は１８０／１８＝１０である。１ｍｓ ＳＲ期間において１０ＭＨｚ帯域幅が想定されると、ＳＲに２０％のリソースが用いられるはずであり、これは重い制御チャネル負担である。したがって、一つより多いＵＥがＳＲリソースを共有することを考慮する。

【0060】

[73] 図７は、ＳＲがどのように共有され得るかを示している。ｅＮＢはいくつかのＵＥのためにＲＲＣシグナリングを用いて同じＳＲリソースを設定する（Ｓ７０１）。ＵＥは、設定されたＳＲリソースを用いてＳＲをｅＮＢに送信する（Ｓ７０３）。衝突ＳＲがないと、ｅＮＢはＰＵＳＣＨ承認を割り当てる（Ｓ７０５）。ＵＥはＰＵＳＣＨ上で上りリンクデータを送信する（Ｓ７０７）。

【0061】

[74] ＳＲを共有するために２つのオプションを考慮することができる。

【0062】

[75] オプション１は、ＵＬ承認が、共有ＵＥのグループごとに設定される新しいＳＲ−ＲＮＴＩ（共有ＳＲ ＲＮＴＩ）にアドレスされることである。オプション２は、ＰＵＣＣＨフォーマット１ａ及びフォーマット１ｂがＳＲに用いられることである。例えば、フォーマット１ａが用いられると、２個のＵＥを識別することができ、フォーマット１ｂでは、４個のＵＥを識別することができる。ｅＮＢがフォーマット１ａ及び／又は１ｂを用いてＳＲを受信した後、識別されたＵＥに規則的なＵＬ承認を割り当てることができる。

【0063】

[76] 次に、１つより多いＵＥがＴＴＩ（衝突）において同じＰＵＣＣＨ−ＳＲリソースを使用する時のハンドリングについて説明する。

【0064】

[77] オプション１に対して、ｅＮＢはＰＵＣＣＨ−ＳＲ衝突がいつ起きるかを話すことができない；ｅＮＢはＵＬ送信のためのリソースを承認（ｇｒａｎｔ）し、１つより多いＵＥはそのリソースを使用する。ＰＵＳＣＨ送信は失敗するはずである。ｅＮＢは、この場合、そのリソースを共有するそれぞれのＵＥのＣ−ＲＮＴＩに承認を提供してもよく又は何にもしなくてもよい。ＳＲを送った後にＵＬ承認が受信されないと、ＵＥはＳＲを再び送ることができるが、若干の（ランダム又はＵＥ特定）遅延を適用し、同時にＳＲを送信した他のＵＥとの続く衝突を避ける必要がある。このようなソリューションの効率は、ＵＬ承認内の選択されたＭＣＳのロバスト性（ｒｏｂｕｓｔｎｅｓｓ）の度合及び衝突確率（ｃｏｌｌｉｓｉｏｎ ｐｒｏｂａｂｉｌｉｔｙ）に依存する：（すなわち、ＭＣＳがかなり剛健であれば、第１非衝突送信はたびたびデコードに成功し、失敗した送信は衝突によって誘発されたものと想定できる）。

【0065】

[78] オプション２に対して、ＳＲ衝突はｅＮＢにとってのＤＴＸ検出をもたらし、上りリンク承認が与えられないことがある。ＵＥ挙動はオプション１におけると類似であってもよい。ｅＮＢが衝突受信又は高い干渉受信を区別できれば、さらなる研究が可能である。ｅＮＢが区別できれば、衝突されたリソースを共有する全てのＵＥに対してそれぞれＵＬリソースを割り当てることができ、これは、衝突後にバックオフ（ｂａｃｋｏｆｆ）によって誘発された遅延を減少させることに役立つ。

【0066】

[79] 上記分析に基づいて、オプション２はオプション１に比べてより簡単で且つよりリソース効率的なＳＲ衝突処理メカニズムを提供する。また、オプション２では新しいＳＲ−ＲＮＴＩを必要としない。

【0067】

[80] これらのオプションはＰＵＣＣＨ−ＳＲ衝突が発生した場合には非効率的であるが、ＳＲ期間が短いと共に少ないＵＥがこれを共有すれば、衝突確率は低く維持される。

【0068】

[81] 共有ＰＵＣＣＨ−ＳＲ手順はＣＢ−ＰＵＳＣＨと比較され、ＣＢ−ＰＵＳＣＨはｅＮＢがＰＵＳＣＨリソースを使用しなかった時に最良の遅延性能を提供することと結論した。ネットワークがロードされると、共有ＳＲが好ましい。

【0069】

[82] 図８は、競合ベース送信を行うための図の例示である。

【0070】

[83] ＵＥが専用−ＳＲ（Ｄ−ＳＲ）を送信してｅＮＢの応答を待つ必要がないため、競合ベースリソースがＴＴＩごとに利用可能であるとの前提下に、競合ベース送信及び１ｍｓ ＳＲ期間の間に３ｍｓ差が存在し得る。専用の事前割り当てによって同じ性能を達成できるが、ＴＴＩごとに全ＵＥに対する専用リソースを割り当てるには非常に多い費用がかかり得る。ＳＲ関連競合ベース送信は興味深い折衝（ｃｏｍｐｒｏｍｉｓｅ）を提供するが、事前割り当てされたリソースは共有され、このリソースを用いるＵＥの識別はＤ−ＳＲによって行われる。ＳＲ関連競合ベース送信の基本手順は、図８に示す。

【0071】

[84] ｅＮＢはＵＥにＤ−ＳＲ及び共有リソースを設定する（Ｓ８０１）。ＵＬデータが到達すると、ＵＥは専用ＵＬ承認を待たないで共有されたリソース上で“同時に”ＳＲ及びＴＢを送信する（Ｓ８０３）。ｅＮＢは受信したＳＲに基づいて、競合ベースリソースを用いてＵＥを識別することができる。ｅＮＢが衝突発生を意味する同じリソースにリンクされた１つより多いＳＲを受信すると、正確にデコードされるか否かにかかわらずにＴＢをＡＣＫし、ＳＲを送信したそれぞれのＵＥに専用承認を提供、すなわち、Ｒ８／９にフォールバック（ｆａｌｌ ｂａｃｋ）する（ＡＣＫされたＴＢは衝突の場合にＲＬＣ再送信に依存できる。）。ｅＮＢが同じリソースにリンクされた一つのＳＲだけを受信すると、衝突が発生せず、ＴＢが正確にデコードされないとＮＡＣＫであり、そうでないとＡＣＫである。したがって、それぞれのＵＥから、正常Ｒ８／９ ＨＡＲＱは相変らず適用可能である（Ｓ８０５）。

【0072】

[85] 互いに異なるリソースを用いた適応的再送信は、競合ベースリソース上のロードを減少させるＳＲでＵＥが識別されるので、可能である（Ｓ８０７）。

【0073】

[86] 一方、非常に保守的な（ｃｏｎｓｅｒｖａｔｉｖｅ）ＭＣＳはカバレッジを保障するために用いられる必要があるため、リソース利用効率はＰＵＳＣＨ上の競合ベース送信において起きる主要関心事の一つである。ＲＬＣヘッダー（少なくとも１〜２バイト）＋ＵＥアイデンティティのために追加される一つ以上のバイト及び可能なＢＳＲ（２〜４バイト）を有するＭＡＣヘッダーを考慮した主に言及される典型的なＴＣＰ ＡＣＫ使用ケースのＴＢに対する競合ベースリソースは、３〜４ ＰＲＢ（最も保守的なＭＣＳを有する一つのＰＲＢに対する１６ビットＴＢＳ）を必要としてもよいが、適切なＭＣＳを有する専用承認である場合（一つのＰＲＢに対するせいぜい７１２ビットＴＢＳ）、ＴＢを収容するためにはより少ないリソースが必要である。衝突確率を減少させるためにいくつかの競合ベースリソースを残しておくと、専用承認のための容量は相当影響を受け、これは３ｍｓレイテンシ減少最適化をだいぶ費用のかかるものにする。

【0074】

[87] なお、正常ＨＡＲＱ動作はたぶん、上記デコード失敗が衝突によるものであれば、ＮＡＣＫを受信したＵＥからの再送信が役に立たないか又はその状況を悪くさえさせるため、働くことができず、また、ｅＮＢにとって、ＣＢリソースで送信されるＴＢのソフトコンバイニングを作ることが困難（不可能でなければ）である。これに対し、他のＵＥに対してＡＣＫになり得るため、ＡＣＫはＡＣＫとして解釈され得ない。ＴＢがセル境界ＵＥに対する只一つの送信内でデコードされ得ることを保証するためにより多い保守的なＭＣＳが要求されるはずなので、Ｎｏ ＨＡＲＱはリソース効率を悪くさせる。

【0075】

[88] 図９は、ＵＥ側におけるＭＡＣ構造の概要を示す図である。

【0076】

[89] ＭＡＣ層は、論理チャネルマルチプレクシング、ハイブリッドＡＲＱ再送信、上りリンク及び下りリンクスケジューリングをハンドリングする。また、キャリアアグリゲーション（ｃａｒｒｉｅｒ ａｇｇｒｅｇａｔｉｏｎ）が用いられるとき、多数のコンポーネントキャリアにわたってデータマルチプレクシング／デマルチプレクシングを担当する。

【0077】

[90] ＭＡＣはＲＬＣに論理チャネルの形態でサービスを提供する。論理チャネルはそれが伝達する情報のタイプによって定義され、一般的に制御チャネルとして分類され、ＬＴＥシステムを動作させる上で必要な制御及び設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報の送信に用いられたり、トラフィックチャネルとしてユーザデータに用いられる。ＬＴＥのために特定された論理チャネルタイプのセットは、ＢＣＣＨ（Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＰＣＣＨ（Ｐａｇｉｎｇ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＣＣＣＨ（Ｃｏｍｍｏｎ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＤＣＣＨ（Ｄｅｄｉｃａｔｅｄ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＭＣＣＨ（Ｍｕｌｔｉｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＤＴＣＨ（Ｄｅｄｉｃａｔｅｄ Ｔｒａｆｆｉｃ Ｃｈａｎｎｅｌ）、及びＭＴＣＨ（Ｍｕｌｔｉｃａｓｔ Ｔｒａｆｆｉｃ Ｃｈａｎｎｅｌ）を含む。

【0078】

[91] 物理層から、ＭＡＣ層は伝送チャネルの形態でサービスを使用する。伝送チャネルは、情報がどのようにどんな特性を持って無線インタフェースを通じて送信されるかによって定義される。伝送チャネル上のデータは伝送ブロックとして組織される。それぞれの送信時間間隔（ＴＴＩ）において、動的サイズのせいぜい一つの伝送ブロックが空間マルチプレクシングの不在時に端末に／から無線インタフェースを通じて送信される。空間マルチプレクシング（ＭＩＭＯ）の場合、ＴＴＩごとに２個までの伝送ブロックが存在してもよい。

【0079】

[92] 伝送フォーマット（ＴＦ）がそれぞれの伝送ブロックと関連付けられて、伝送ブロックが無線インタフェースを通じてどのように送信されるかを特定する。伝送フォーマットは、伝送ブロックサイズ、変調及びコーディング方式、及びアンテナマッピングに関する情報を含む。伝送フォーマットを変更することによって、ＭＡＣ層は異なるデータレートを実現することができる。したがって、レート制御は伝送フォーマット選択として知られている。

【0080】

[93] 優先順位ハンドリングを支援するために、多数の論理チャネルはＭＡＣ層によって一つの伝送チャネルにマルチプレクシングされてもよく、それぞれの論理チャネルは自身のＲＬＣエンティティを有する。受信機において、ＭＡＣ層は順次的（ｉｎ−ｓｅｑｕｅｎｃｅ）伝達及びＲＬＣによってハンドリングされる他の機能のために対応するデマルチプレクシングをハンドリングし、ＲＬＣ ＰＤＵをそれぞれのＲＬＣエンティティに伝達する。受信機においてデマルチプレクシングを支援するために、ＭＡＣが利用される。それぞれのＲＬＣ ＰＤＵには、ＭＡＣヘッダー内に関連したサブヘッダーが存在する。サブヘッダーはＲＬＣ ＰＤＵが由来した論理チャネル（ＬＣＩＤ）のアイデンティティ及びＰＤＵのバイト長を含む。最後のサブヘッダーであるかどうかを示すフラグも存在する。ＭＡＣヘッダーと共に、一つ又はいくつかのＲＬＣ ＰＤＵ、及び、必要時には、スケジュールされた伝送ブロックサイズを満たすためのパディングが、物理層に伝達される一つの伝送ブロックを形成する。

【0081】

[94] 互いに異なる論理チャネルのマルチプレクシングに加えて、ＭＡＣ層は、いわゆるＭＡＣ制御エレメントを、伝送チャネルを介して送信される伝送ブロックに挿入することもできる。ＭＡＣ制御エレメントはインバンド制御シグナリング、例えば、タイミング−アドバンスコマンド及びランダムアクセス応答に用いられる。制御エレメントはＬＣＩＤフィールド内の留保された（ｒｅｓｅｒｖｅｄ）値で識別され、ＬＣＩＤ値は制御情報のタイプを示す。

【0082】

[95] また、サブヘッダー内の長さフィールドは、固定長を有する制御エレメントのために除去される。

【0083】

[96] ＭＡＣマルチプレクシング機能はまた、キャリアアグリゲーションの場合、多数のコンポーネントキャリアのハンドリングを担当する。キャリアアグリゲーションのための基本原理は、制御シグナリング、スケジューリング及びハイブリッド−ＡＲＱ再送信を含む物理層におけるコンポーネントキャリアの独立したプロセシングであるが、キャリアアグリゲーションはＲＬＣ及びＰＤＣＰには見えない。このため、キャリアアグリゲーションは主にＭＡＣ層において見え、任意のＭＡＣ制御エレメントを含む論理チャネルはマルチプレクシングされて、自身のハイブリッドＡＲＱエンティティを有するそれぞれのコンポーネントキャリアを有するコンポーネントキャリアごとに１つの（空間マルチプレクシングの場合には２つ）伝送ブロックを形成する。

【0084】

[97] 既に有効承認を持っている端末は確実に上りリンクリソースを要求する必要がない。しかし、スケジューラが未来のサブフレームでそれぞれの端末に承認するリソースの量を決定するように許容するために、上述したように、バッファ状況及びパワー利用可能性に関する情報が有用であってもよい。この情報はＭＡＣ制御エレメントを通じて上りリンク送信の一部としてスケジューラに提供される。一つのＭＡＣサブヘッダー内のＬＣＩＤフィールドは、バッファ状態報告の存在を示す留保された値に設定される。

【0085】

[98] ＢＳＲ（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔｉｎｇ）手順は、ＵＥのＵＬバッファ内の送信に利用可能なデータ（ｄａｔａ ａｖａｉｌａｂｌｅ ｆｏｒ ｔｒａｎｓｍｉｓｓｉｏｎ）の量に関する情報をサービングｅＮＢに提供するために用いられる。ＲＲＣは、２個のタイマーであるｐｅｒｉｏｄｉｃＢＳＲ−Ｔｉｍｅｒ及びｒｅｔｘＢＳＲ−Ｔｉｍｅｒを設定（ｃｏｎｆｉｇｕｒｅ）し、それぞれの論理チャネルに対して、論理チャネルをＬＣＧ（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ Ｇｒｏｕｐ）に割り当てる論理チャネルグループを選択的にシグナリングすることによってＢＳＲ報告を制御することができる。

【0086】

[99] ＢＳＲ手順に対して、ＵＥは中断していない全ての無線ベアラーを考慮し、中断しているベアラーを考慮することができる。ＢＳＲは、次のようないずれかのイベントが発生する場合にトリガーされ得る：i）伝送バッファ内に現在存在するものに比べてより高い優先順位のデータが到着した場合、すなわち、現在送信されているものに比べてより高い優先順位を持つ論理チャネルグループ内のデータが到着した場合。これは、スケジューリング決定に影響を与えることができる（すなわち、ＬＣＧに属する論理チャネルに対するＵＬデータがＲＬＣエンティティ又はＰＤＣＰエンティティにおける送信に利用可能となり、そのデータが任意のＬＣＧに属し、データが送信に既に利用可能な論理チャネルの優先順位より高い優先順位で論理チャネルに属したり、ＬＣＧに属する論理チャネルのいずれかに対する送信に利用可能なデータがない場合）。図１０は、上りリンク承認受信に対する概念図である。

【0087】

[100] ＵＬ−ＳＣＨ上で送信するために、ＭＡＣエンティティは（非適応ＨＡＲＱ再送信を除いて）ＰＤＣＣＨ上で又はランダムアクセス応答で動的に受信したり半静的に設定され得る有効上りリンク承認を持たなければならない。要求された送信を行うために、ＭＡＣ層は下位層からＨＡＲＱ情報を受信する。物理層が上りリンク空間マルチプレクシングのために設定されると、ＭＡＣ層は下位層から同じＴＴＩの間に２個までの承認（ＨＡＲＱプロセスごとに１個）を受信することができる。

【0088】

[101] ＵＥがサブフレームＮ上でサブフレームＮ＋Ｋの間に上りリンクデータを送信するための有効上りリンク承認を受信すると、ＵＥは上りリンク承認を用いてサブフレームＮ＋Ｋ上で上りリンクデータを送信する。その後、ＵＥはサブフレームＮ＋Ｋ＋Ｉ上で上りリンクデータの伝送のためのＡＣＫ／ＮＡＣＫフィードバックを受信し、ＵＥがＮＡＣＫ指示を受信すると、ＵＥはサブフレームＮ＋Ｋ＋Ｉ＋Ｊ上でＵＬデータを再送信しなければならない。

【0089】

[102] 具体的に、ＭＡＣエンティティがＣ−ＲＮＴＩ、半静的スケジューリングＣ−ＲＮＴＩ、又は一時的なＣ−ＲＮＴＩを有すると、ＭＡＣエンティティは、それぞれのＴＴＩ、実行するｔｉｍｅＡｌｉｇｎｍｅｎｔＴｉｍｅｒを有するＴＡＧに属するそれぞれのサービングセル及びこのＴＴＩにおいて受信されたそれぞれの承認のために、すなわち、このＴＴＩ及びこのサービングセルに対する上りリンク承認がＭＡＣエンティティのＣ−ＲＮＴＩ又は一時的なＣ−ＲＮＴＩのためにＰＤＣＣＨ上で受信されたり、このＴＴＩに対する上りリンク承認がランダムアクセス応答で受信されると、上りリンク承認がＭＡＣエンティティのＣ−ＲＮＴＩに対するものであり、同じＨＡＲＱプロセスに対するＨＡＲＱで伝達された以前の上りリンク承認がＭＡＣエンティティの半静的スケジューリングＣ−ＲＮＴＩ又は設定された上りリンク承認のために受信された上りリンク承認であれば、ＮＤＩの値にかからずに対応するＨＡＲＱプロセスに対してトグルされたものと見なし、上りリンク承認及び関連したＨＡＲＱ情報をこのＴＴＩにおいてＨＡＲＱエンティティに伝達する。

【0090】

[103] 上りリンクが設定されたそれぞれのサービングセルに対するＭＡＣエンティティに一つのＨＡＲＱエンティティが存在し、これは以前送信の成功又は失敗した受信に対するＨＡＲＱフィードバックを待ちながら継続して送信が発生するようにする多数の並列ＨＡＲＱプロセスを維持する。

【0091】

[104] 与えられたＴＴＩにおいて、ＴＴＩの間に上りリンク承認が指示されると、ＨＡＲＱエンティティは、送信の発生すべきＨＡＲＱプロセスを識別する。また、物理層によってリレーされた受信されたＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ情報）、ＭＣＳ及びリソースを適切なＨＡＲＱプロセスにルーティングする。

【0092】

[105] それぞれのＴＴＩの間に、ＨＡＲＱエンティティは、このＴＴＩと関連したＨＡＲＱプロセスを識別し、それぞれの識別されたＨＡＲＱプロセスの間に、ＭＡＣエンティティはＭＡＣ ＰＤＵを受け取り、Ｍｓｇ３バッファにＭＡＣ ＰＤＵが存在し、上りリンク承認がランダムアクセス応答で受信されると、Ｍｓｇ３バッファから送信し、ＭＡＣ ＰＤＵ及び上りリンク承認及びＨＡＲＱ情報を、識別されたＨＡＲＱプロセスに伝達し、上りリンク承認がＰＤＣＣＨ上で受信されると、識別されたＨＡＲＱプロセスが新しい送信をトリガーするように指示する。

【0093】

[106] それぞれのＨＡＲＱプロセスはＨＡＲＱバッファと関連付けられる。

【0094】

[107] それぞれのＨＡＲＱプロセスは、バッファで現在ＭＡＣ ＰＤＵに対して発生する送信数を示す状態変数ＣＵＲＲＥＮＴ＿ＴＸ＿ＮＢ、及びバッファで現在ＭＡＣ ＰＤＵに対するＨＡＲＱフィードバックを示す状態変数ＨＡＲＱ＿ＦＥＥＤＢＡＣＫを維持することができる。ＨＡＲＱプロセスが確立されると、ＣＵＲＲＥＮＴ＿ＴＸ＿ＮＢは０に初期化されるはずである。

【0095】

[108] リダンダンシーバージョンのシーケンスは、０、２、３、１である。変数ＣＵＲＲＥＮＴ＿ＩＲＶは、リダンダンシーバージョンのシーケンスへのインデックスである。この変数は、アップデートされたモジューロ４である。

【0096】

[109] リソース上で新しい送信が行われ、ＭＣＳはＰＤＣＣＨ又はランダムアクセス応答上で指示される。適応的再送信はリソース上で行われ、提供される場合、ＭＣＳがＰＤＣＣＨ上で指示される。非適応的再送信が同じリソース上で最後に行われる送信の試みに用いられたものと同じＭＣＳで行われる。

【0097】

[110] ＭＡＣエンティティは、ＲＲＣによってＨＡＲＱ送信の最大数及びＭｓｇ３ ＨＡＲＱ送信の最大数に設定され、それらはそれぞれ、ｍａｘＨＡＲＱ−Ｔｘ及びｍａｘＨＡＲＱ−Ｍｓｇ３Ｔｘである。Ｍｓｇ３バッファに保存されたＭＡＣ ＰＤＵの送信を除いて全てのＨＡＲＱプロセス及び全ての論理チャネル上の送信のために、送信の最大数はｍａｘＨＡＲＱ−Ｔｘに設定される。Ｍｓｇ３バッファに保存されたＭＡＣ ＰＤＵの送信のために、送信の最大数はｍａｘＨＡＲＱ−Ｍｓｇ３Ｔｘに設定される。

【0098】

[111] このＴＢに対するＨＡＲＱフィードバックが受信されると、ＨＡＲＱプロセスはＨＡＲＱ＿ＦＥＥＤＢＡＣＫを受信された値に設定する。

【0099】

[112] ＨＡＲＱエンティティが新しい送信を要求すると、ＨＡＲＱプロセスはＣＵＲＲＥＮＴ＿ＴＸ＿ＮＢを０に設定し、ＣＵＲＲＥＮＴ＿ＩＲＶを０に設定し、関連したＨＡＲＱバッファにＭＡＣ ＰＤＵを保存し、ＨＡＲＱエンティティから受信された上りリンク承認を保存し、ＨＡＲＱ＿ＦＥＥＤＢＡＣＫをＮＡＣＫに設定し、後述するように送信を生成する。

【0100】

[113] ＨＡＲＱエンティティが再送信を要求すると、ＨＡＲＱプロセスはＣＵＲＲＥＮＴ＿ＴＸ＿ＮＢを１増加させる。ＨＡＲＱエンティティが適応的再送信を要求すると、ＨＡＲＱプロセスは、ＨＡＲＱエンティティから受信された上りリンク承認を保存し、ＣＵＲＲＥＮＴ＿ＩＲＶをＨＡＲＱ情報から提供されるリダンダンシーバージョン値に対応するインデックスに設定し、ＨＡＲＱ＿ＦＥＥＤＢＡＣＫをＮＡＣＫに設定し、後述するように送信を生成する。ＨＡＲＱエンティティが非適応的再送信を要求すると、ＨＡＲＱ＿ＦＥＥＤＢＡＣＫ＝ＮＡＣＫであれば、ＨＡＲＱプロセスは後述するように送信を生成する。

【0101】

[114] 送信を生成するために、ＨＡＲＱプロセスは物理層でＣＵＲＲＥＮＴ＿ＩＲＶ値に対応するリダンダンシーバージョンを有する保存された上りリンク承認によって送信を生成するように指示し、ＭＡＣ ＰＤＵがＭｓｇ３バッファから得られると、ＣＵＲＲＥＮＴ＿ＩＲＶを１増加させたり；送信時に測定ギャップがない場合及び再送信の場合、再送信はこのＴＴＩにおいてＭｓｇバッファから得られたＭＡＣ ＰＤＵに対する送信と衝突しない。

【0102】

[115] この送信のために、ＨＡＲＱフィードバック時に測定ギャップが存在する場合及びＭＡＣ ＰＤＵがＭｓｇ３バッファから得られない場合、ＨＡＲＱプロセスはこの送信に対するＨＡＲＱフィードバック受信時にＨＡＲＱ＿ＦＥＥＤＢＡＣＫをＡＣＫに設定する。

【0103】

[116] 上記動作を行った後、ＣＵＲＲＥＮＴ＿ＴＸ＿ＮＢ＝送信最大数−１であれば、ＨＡＲＱプロセスはＨＡＲＱバッファをフラッシュ（ｆｌｕｓｈ）する。

【0104】

[117] ＬＴＥにおいて、上りリンクデータを送信するために、ＵＥはｅＮＢから上りリンク承認を得なければならない。効率的な上りリンクリソーススケジューリングのために、ＵＥはバッファ内のデータの量を報告しなければならず、ｅＮＢは報告されたバッファサイズに基づいて上りリンク承認を提供する。この手順は、専用上りリンクリソースがＵＥに与えられてＵＥ間の衝突を避け得るようにする。しかし、ＵＥは、データが送信に利用可能になった後、上りリンクデータを送信するためにしばらく待たなければならない。また、バッファサイズを報告するための上りリンクリソースがない場合、ＵＥは上りリンク送信において追加の遅延をきたすＳＲ又はＲＡ手順を始めることができる。

【0105】

[118] ＤＬ送信において、ｅＮＢがＤＬデータ、例えば、ＴＣＰをＵＥに送信すると、ｅＮＢはＵＥから対応するＵＬデータ、例えば、ＴＣＰ ＡＣＫ／ＮＡＣＫを受信することを期待する可能性がある。ＵＥがＵＬデータを送信する正確なタイミングをｅＮＢが知らなくても、ｅＮＢは、ＵＥがＤＬデータに対応するＵＬデータをｅＮＢに送信する時をヒストリーから概略的に予想したり学習することができる。その後、ｅＮＢは、レイテンシを減少させるために、予想されるＵＬデータ送信のための上りリンクリソースを事前割り当てをしたり又はすることを所望することができる。

【0106】

[119] しかし、同期ＵＬ ＨＡＲＱプロセスであることから、ＵＥがサブフレームＮ上でｅＮＢから上りリンク承認を受信すると、ＵＥはそのサブフレームに対応するＨＡＲＱプロセスを用いてサブフレームＮ＋ｋ上で上りリンクデータを送信する。例えば、ｋはＦＤＤにおいて４である。すなわち、上り承認の受信時に、ＵＥは特定サブフレームと関連している特定ＨＡＲＱプロセスを用いてＵＬ送信を行わなければならず、ここで、特定サブフレームは上りリンク承認の受信タイミングにマップされる。

【0107】

[120] ＤＬデータに対応するＵＬデータは発生の際に正確に知られていないため、i）ＵＥ側においで、ＵＬデータが送信に利用可能になる前に上りリンクリソース要求に対するバッファサイズを報告し、ii）ｅＮＢ側において、正確なタイミングは知らないが、近い未来に発生し得るＵＬ送信に用いられる少なくとも一つのサブフレームに対する上りリンク承認を提供するために新しいメカニズムが必要である。

【0108】

[121] 図１１は、本発明の実施例によって無線通信システムにおいてバッファ状態報告をトリガーするための概念図である。

【0109】

[122] ＵＬ承認の迅速な取得のために、送信される任意のＵＬデータ無しで、ＵＥはバッファ状態報告（ＢＳＲ）をｅＮＢに送信して、予想されるＵＬデータの送信のためのＵＬ承認を要求する。

【0110】

[123] 好ましくは、所定の期間内でＵＥによって生成されると予想される上りリンクデータは“仮想データ”といい、仮想データに対するＵＬ承認を要求するＢＳＲは“仮想ＢＳＲ”という。

【0111】

[124] 具体的に、送信に利用可能な上りリンクデータが現在存在しなくても、ＵＥは、所定の期間内に生成される上りリンクデータがあると予想すれば、仮想ＢＳＲをトリガーすることができる（Ｓ１１０１）。

【0112】

[125] ＵＥは受信したＤＬパケットに基づいてＵＬ仮想データを予想することができる。例えば、ＵＥは、ＴＣＰパケットを含むＰＤＣＰ ＰＤＵを受信すると、近い未来に上りリンクで送信されるべきＴＣＰ ＡＣＫパケットがあると予想できる。

【0113】

[126] 具体的に、ＵＥのＰＤＣＰエンティティがＭＡＣエンティティに、近い未来に仮想データがある旨を指示すると、ＭＡＣエンティティは仮想データに対する仮想ＢＳＲをトリガーする。

【0114】

[127] ＵＥはまた、ＵＬデータを周期的に生成するプロトコルが存在すると、ＵＬ仮想データを予想することができる。例えば、ＵＥ ＰＤＣＰ内のＲＯＨＣ（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）プロトコルは、ＵＥによって予想可能なＲＯＨＣ初期化及びリフラッシュ（ＩＲ）パケットを周期的に生成することができる。

【0115】

[128] 仮想ＢＳＲをトリガーするために、ＵＥはＰＤＣＰ又はＲＬＣ又はＭＡＣエンティティで仮想データを生成することができる。ｅＮＢはＴＣＰパケットのＮ番目の受信ごとにＴＣＰ ＡＣＫパケットに対するＢＳＲをＵＥがトリガーするようにＵＥを設定する。

【0116】

[129] 仮想ＢＳＲがトリガーされる時、ＵＬ承認がないと、ＵＥはスケジューリング要求（ＳＲ）をトリガーする（Ｓ１１０３）。ＳＲは、ＳＲが仮想ＢＳＲによってトリガーされるという指示を含むことができる。

【0117】

[130] 仮想ＢＳＲがトリガーされる時、ＵＬ承認があると、ＵＥは仮想ＢＳＲを送信する（Ｓ１１０５）。

【0118】

[131] 仮想ＢＳＲは仮想データのサイズを含む。

【0119】

[132] 仮想ＢＳＲは、ＢＳＲが仮想データのサイズを報告するとの指示、又はトリガーされたＢＳＲが仮想データに対するものであるとの指示を含むことができる。

【0120】

[133] ｅＮＢがＵＥから仮想データ送信のためのＢＳＲ又はＳＲを受信すると、ｅＮＢはＵＬ承認をＵＥに割り当てる（Ｓ１１０７）。

【0121】

[134] 仮想データに対するＵＬ承認は、i）このＵＬ承認が仮想データに対するものであるとの指示、ii）仮想データに対するＵＬ承認が有効である持続時間（ｔｉｍｅ ｄｕｒａｔｉｏｎ）、又はiii）ＵＥがこのＵＬ承認を用いて送信に使用するＨＡＲＱプロセスＩＤ、を含むことができる。

【0122】

[135] ＵＥがｅＮＢから仮想データに対するＵＬ承認を得ると（Ｓ１１０７）、ＵＥは、実際データが生成される時までＵＬ承認を保存する。ＵＥは、実際データが生成されると、受信されたＵＬ承認上で実際データを送信する（Ｓ１１０９）。

【0123】

[136] 実際データが生成されないと、ＵＥは、仮想データに対するＵＬ承認を廃棄したりＵＬ承認上で仮想ＢＳＲを送信する（Ｓ１１１１）。

【0124】

[137] 仮想データに対するＵＬ承認が有効である持続時間は、ＲＲＣシグナリングを用いてｅＮＢによって設定されたり、仕様において固定される。また、ＵＬ承認がｅＮＢから受信される時にＵＬ承認に持続時間が含まれる。

【0125】

[138] 図１２は、本発明の実施例によって無線通信システムにおいてバッファ状態報告をトリガーする例を示す図である。

【0126】

[139] 送信に利用可能になると概略的に予測可能なデータ、例えば、ＴＣＰ ＡＣＫの送信のためのＵＬ承認について詳しく説明する。

【0127】

[140] ＵＥがＴＣＰパケットを含むＰＤＣＰ ＰＤＵを受信すると（Ｓ１２０１）、ＵＥは、近い未来に上りリンクで送信されるべきＴＣＰ ＡＣＫパケットがあるということを予想するだろう。

【0128】

[141] この場合、ＵＥは仮想ＢＳＲをトリガーして送信する（Ｓ１２０３）。ＵＥが持続期間に仮想ＢＳＲに対する上りリンク承認を受信する時（Ｓ１２０５）、ＵＥが持続期間に実際データ（すなわち、ＴＣＰ ＡＣＫ）を生成できれば、ＵＥは仮想データに対する上りリンク承認を用いてＴＣＰ ＡＣＫを送信することができる（Ｓ１２０７）。実際データが生成されないと、ＵＥは仮想データに対するＵＬ承認を廃棄したり、ＵＬ承認上で仮想ＢＳＲを送信する。

【0129】

[142] 図１３は、本発明の実施例によって無線通信システムにおいて多数のサブフレームで上りリンク承認を設定するための概念図である。

【0130】

[143] “ＬＴＥに対するレイテンシ減少技術に対する研究”という研究項目において、ＴＣＰスループット改善は、レイテンシ減少のためのプロトコル向上の予想結果の一つである。ＴＣＰスループット改善のために、事前スケジューリングによるゼロ遅延を持っているにもかかわらず上りリンク承認を提供する方が有利であるということはかなり明らかである。

【0131】

[144] 事前スケジューリングを達成するには２つの方法がある、すなわち、i）ｅＮＢは１ｍｓの間隔を有するＳＰＳ ＵＬ承認を設定し（方法１）、及びii）ｅＮＢはＵＥからＢＳＲを受信しないで多数サブフレームに対する多数のＵＬ承認を提供する（方法２）。

【0132】

[145] 方法１において、ＵＥは、ｅＮＢからＳＰＳ設定を受信し、ＳＰＳ Ｃ−ＲＮＴＩによってアドレスされた ＰＤＣＣＨの受信時にＳＰＳ ＵＬ承認を初期化（活性化）し、ＲＬＣ／ＰＤＣＰエンティティにおける送信に利用可能なデータがないと上りリンク送信をスキップする。

【0133】

[146] 方法１では、ＳＰＳ ＵＬ承認が一応設定及び初期化（活性化）されると、いなかる追加的なシグナリング無しに解除（ｒｅｌｅａｓｅ）されるまで、設定されたＳＰＳ ＵＬ承認をＵＥが使用することができる。しかし、ＵＥは多数の段階を経てのみＳＰＳ ＵＬ承認を利用できるが、すなわち、ｅＮＢはＳＰＳ設定を提供した後にＳＰＳ ＵＬ承認を初期化（活性化）する。したがって、ＳＰＳ ＵＬ承認が設定されるや否や初期化される必要がある場合にも、ｅＮＢは別の段階を行う必要がある。これは、ＳＰＳ ＵＬ承認を使用するにあたって遅延を発生させる。そして、ＵＥはただ一つのＳＰＳ設定、すなわち、一つの間隔で設定され得る。ＶｏＩＰトラフィック及びＴＣＰ ＡＣＫはその特性において異なるため、一つのＳＰＳ設定でＶｏＩＰトラフィック及びＴＣＰ ＡＣＫを提供することは非効率的であり得る。したがって、ｅＮＢは、予想されるトラフィックによって頻繁にＳＰＳ ＵＬ承認を設定／解除する必要があり得る。

【0134】

[147] 方法２において、ｅＮＢはＵＥからＢＳＲを受信しないでＵＬデータ送信を予測し、ＵＥがＵＬデータを送信できる多数のサブフレームに対する多数のＵＬ承認を提供する。ＵＥ ＵＬ承認を含むＰＤＣＣＨを受信する時、ＲＬＣ／ＰＤＣＰエンティティにおける送信に利用可能なデータがない場合、ＵＥは上りリンク送信をスキップする。

【0135】

[148] この場合、ＳＰＳ ＵＬ承認と同様に、ＵＬ承認を使用する追加の段階、すなわち、設定／初期化がなく、スケジュールされた柔軟性をＴＣＰ ＡＣＫ予測可能性、セルロードなどによって動的を達成することができる。しかし、ｅＮＢが、例えば、ＵＬデータの予測不可能性のことから、多数のサブフレームに対する動的ＵＬ承認を提供することを所望すると、ｅＮＢはＰＤＣＣＨを多数回送信しなければならない。これは自然的にシグナリングオーバーヘッドを増加させる。

【0136】

[149] 上記の２つの方法は既に支援されており、仕様をすこし変更して用いることができる。しかし、上記で説明したとおり、これら２つの方法はシグナリングオーバーヘッド（方法１及び２）及びＵＬ承認を使用する際における遅延（方法１）においてあまり効率的でない。

【0137】

[150] このような問題に基づいて、有効であり且つ設定された多数のサブフレームに利用可能な、デューレーションの長いＵＬ承認を導入する必要がある。

【0138】

[151] 本発明は、多数のＵＬ承認に対する多数のＰＤＣＣＨの送信を避けるためのものである。これは、ＵＬ承認が有効な期間（多数のサブフレーム）を提供することによって実現することができる。送信に利用可能になる時に概略的にしか予測できないデータ、例えば、ＴＣＫ ＡＣＫに対するシグナリングオーバーヘッドを減少させるという利点がある。

【0139】

[152] インターネットの優勢な使用ケースの一つであるＴＣＫ ＡＣＫに対するレイテンシ減少がＴＣＰのスループット改善を招くとすれば、動的ＵＬ承認の改善を討論してみる価値があると見なされる。また、これは、仕様において適当な変化だけを要求する。すなわち、ｅＮＢは、スケジューリングポリシー又はデータ発生の予測可能性を考慮することによって、ＵＬ承認が有効である期間を提供する。

【0140】

[153] ｅＮＢは特定持続期間に有効であるＵＬ承認をＵＥに送信し、ＵＥは特定持続期間においてＵＬ承認が有効であると見なす（Ｓ１３０１）。したがって、ＵＥは、実際データが生成されるまでＵＬ承認を保存する。

【0141】

[154] 特定持続期間において実際データが生成されると、ＵＥは上りリンク承認を用いてデータを送信する（Ｓ１３０３）。特定の持続期間が過ぎるまで実際データが生成されないと、ＵＥは上りリンク承認を廃棄したり（Ｓ１３０５）、ＵＬ承認上で仮想ＢＳＲを送信する。

【0142】

[155] 好ましくは、特定持続期間はＲＲＣシグナリングを用いてｅＮＢによって設定されたり、事前設定されたり上りリンク承認と共に受信される。

【0143】

[156] 好ましくは、上りリンク承認は、ＵＥが生成されると予想したデータ（すなわち、仮想データ）に対するものであり、上りリンク承認は、ＵＥが上りリンク承認が生成されると予想したデータに対するものであるとの指示を含む。

【0144】

[157] 好ましくは、仮想データに対するＵＬ承認は、i）このＵＬ承認が仮想データに対するものであるとの指示、ii）仮想データに対するＵＬ承認が有効である持続期間、又はiii）このＵＬ承認を用いてＵＥが送信に使用するＨＡＲＱプロセスＩＤ、を含むことができる。

【0145】

[158] 好ましくは、ＵＥは、送信のために利用可能な上りリンクデータが現在存在しない場合にも特定の持続期間内に生成される上りリンクデータがあると予想すれば、仮想ＢＳＲをトリガーすることができる。

【0146】

[159] 特定の持続期間が過ぎても特定持続期間においてＵＥがＵＬ承認を用いてデータを送信すると、ＵＥは上りリンク承認を廃棄することができる（Ｓ１３０７）。

【0147】

[160] 好ましくは、特定の持続期間は２つ以上のサブフレームを含む。

【0148】

[161] 図１４は、本発明の実施例によって無線通信システムにおいて多数のサブフレームで上りリンク承認を設定するための概念図である。

【0149】

[162] ＵＥは、上りリンク承認が有効である特定の持続期間をカウントするタイマーを維持することができる。

【0150】

[163] ＵＥがＵＬ承認を受信すると（Ｓ１４０１）、ＵＥはタイマーＴｉｍｅｒＶを起動する（Ｓ１４０３）。ＵＥはＴｉｍｅｒＶが実行される間にＶＵＬ承認が有効であると見なし、ＵＥは、実際データが生成されるまでＵＬ承認を保存する。好ましくは、タイマーの値はＲＲＣシグナリングを用いてｅＮＢによって設定されたり、事前設定されたり、上りリンク承認と共に受信され、タイマーの値は２個のサブフレームより大きいか等しい。

【0151】

[164] ＴｉｍｅｒＶが実行される間に、ＵＬデータが送信に利用可能になると、ＵＥはＵＬ承認を用いてＵＬデータを送信する（Ｓ１４０５）。ＵＥは、ＵＬ承認上でＵＬ送信が行われるサブフレームにマップされるＨＡＲＱプロセスを利用する。

【0152】

[165] そして、ＵＥは、ＵＬ承認上で実際データが送信される時にタイマーを中止する（Ｓ１４０７）。この場合、タイマーが満了しなくても、タイマーが実行される間にＵＥが上りリンク承認を用いてデータを送信した後にＵＬ承認を廃棄することができる（Ｓ１４０９）。ＴｉｍｅｒＶが実行される間に、送信に利用可能になるＵＬデータがないと、ＴｉｍｅｒＶが満了した後にＵＥがＶＵＬ承認を廃棄したり（Ｓ１４１１）、ＵＬ承認上で仮想ＢＳＲを送信する。

【0153】

[166] 好ましくは、上りリンク承認は、ＵＥが生成されると予想したデータ（すなわち、仮想データ）に対するものであり、上りリンク承認は、上りリンク承認が、生成されるはずとＵＥが予想したデータに対するものであるとの指示を含む。

【0154】

[167] 好ましくは、仮想データに対するＵＬ承認は、i）このＵＬ承認が仮想データに対するものであるとの指示、ii）仮想データに対するＵＬ承認が有効な持続期間、又はiii）このＵＬ承認を用いてＵＥが送信に使用するＨＡＲＱプロセスＩＤを含むことができる。

【0155】

[168] 好ましくは、ＵＥは、送信のために利用可能な上りリンクデータが現在存在しない場合にも特定の持続期間内に生成される上りリンクデータがあると予想すれば、仮想ＢＳＲをトリガーすることができる。ＵＥは、持続期間をカウントするタイマーを維持することができる。ＵＥは、仮想データに対するＵＬ承認が受信されるとタイマーを起動し、ＵＬ承認上で実際データが送信されるとタイマーを中止する。タイマーが満了すると、ＵＥがＶＵＬ承認を廃棄したり、ＵＬ承認上で仮想ＢＳＲを送信する。

【0156】

[169] 図１５及び図１６は、本発明の実施例によって無線通信システムにおいて多数のサブフレームで上りリンク承認に基づいてＡＣＫ／ＮＡＣＫ指示を行うための概念図である。

【0157】

[170] “ＵＬ承認＋持続期間”を“ＶＵＬ承認”とし、“持続期間（ｔｉｍｅ ｄｕｒａｔｉｏｎ）”を“Ｔｄ”とする。Ｔｄをカウントするタイマーは“ＴｉｍｅｒＶ”とする。

【0158】

[171] 図１５で、ｅＮＢがＶＵＬ承認をＵＥに与えると（Ｓ１５０１）、ＵＥはタイマーＴｉｍｅｒＶを起動し（Ｓ１５０２）、ｅＮＢは持続期間（Ｔｄ）の間にＶＵＬ承認上のＵＥからのＵＬデータを待つ（Ｓ１５０３）。

【0159】

[172] ＵＥはｅＮＢからＶＵＬ承認を受信し、ＵＥはＴｄの間にＶＵＬ承認が有効であると見なす。

【0160】

[173] 好ましくは、Ｔｄの値はＲＲＣシグナリングを用いてｅＮＢによって設定されたり、事前設定されたり上りリンク承認と共に受信され、タイマーの値は２個のサブフレームより大きいか等しい。

【0161】

[174] 好ましくは、ＶＵＬ承認は、ＵＥが生成されると予想したデータに対するものであり、ＶＵＬ承認は、上りリンク承認が生成されるとＵＥが予想したデータに対するものであるとの指示を含む。好ましくは、Ｔｄの値は２個のサブフレームより大きいか等しい。

【0162】

[175] ＴｉｍｅｒＶが実行される間に、ＶＵＬ承認上でＵＬデータを送信した後（Ｓ１５０４）、ＵＥはサブフレーム上で送信されるデータに対するＡＣＫ指示又はＮＡＣＫ指示をモニターしてｅＮＢからのフィードバックの受信を待つ。

【0163】

[176] ｅＮＢは直ちにＡＣＫをＵＥに送信し、ＵＥからＶＵＬ承認を解除する（Ｓ１５０５）。

【0164】

[177] 送信されるデータに対するＡＣＫ指示がサブフレーム上で受信されなかったり、サブフレーム上で送信されるデータに対するＮＡＣＫ指示が受信されると、ＵＥはＴｉｍｅｒＶが実行されるかを確認する。

【0165】

[178] ＴｉｍｅｒＶが実行される時、ＵＥが行われる送信に対するＡＣＫを受けないか又はＮＡＣＫ指示を受けると、ＵＥは同じＶＵＬ承認を用いてＲＬＣエンティティ又はＭＡＣエンティティでＵＬデータを再送信することができる（Ｓ１５０６）。

【0166】

[179] ｅＮＢがＴｄの間にＶＵＬ承認上でいかなるＵＬデータも受信できないと、ｅＮＢはＴｄが過ぎた後にＮＡＣＫをＵＥに送信する（Ｓ１５０７）。

【0167】

[180] ＴｉｍｅｒＶが満了するまでＵＥがＡＣＫを受信できないと、ＵＥはＵＬ承認を廃棄し（Ｓ１５０８）、ＲＬＣエンティティ又はＭＡＣエンティティでＵＬデータを維持し、ＢＳＲをトリガーしてＵＬデータに対するＵＬ承認を要求する（Ｓ１５０８）。

【0168】

[181] 図１６で、ｅＮＢがＶＵＬ承認をＵＥに与えると（Ｓ１６０１）、ＵＥはタイマーＴｉｍｅｒＶを起動し（Ｓ１６０２）、ｅＮＢは持続期間（Ｔｄ）の間にＶＵＬ承認上のＵＥからのＵＬデータを待つ（Ｓ１６０３）。

【0169】

[182] ＵＥはｅＮＢからＶＵＬ承認を受信し、ＵＥはＴｄの間にＶＵＬ承認が有効であると見なす。

【0170】

[183] 好ましくは、Ｔｄの値は、ＲＲＣシグナリングを用いてｅＮＢによって設定されたり、事前設定されたり上りリンク承認と共に受信され、タイマーの値は２個のサブフレームより大きいか等しい。

【0171】

[184] 好ましくは、ＶＵＬ承認は、生成されるとＵＥが予想したデータに対するものであり、ＶＵＬ承認は、上りリンク承認が生成されるとＵＥが予想したデータに対するものであるとの指示を含む。好ましくは、Ｔｄの値は２個のサブフレームより大きいか等しい。ＴｉｍｅｒＶが実行される間に、ＶＵＬ承認上でＵＬデータを送信した後（Ｓ１６０４）、ＵＥはＲＬＣエンティティ又はＭＡＣエンティティでＵＬデータを維持する。ＵＥはＴｉｍｅｒＶが実行される間に、同じＵＬ承認を用いてＲＬＣエンティティ又はＭＡＣエンティティでＵＬデータを再送信することができる（Ｓ１６０６）。

【0172】

[185] ｅＮＢがＴｄの間にＶＵＬ承認上でＵＬデータを受信すると、ＡＣＫをＵＥに送信したり、Ｔｄの間にＶＵＬ承認上でいかなるＵＬデータも受信できないと、Ｔｄが過ぎた後にＮＡＣＫをＵＥに送信する（Ｓ１６０７）。

【0173】

[186] ｅＮＢの挙動によって、ＴｉｍｅｒＶが満了すると、ＵＥはｅＮＢからのフィードバックをモニタする。フィードバックはＶＵＬ承認を用いて行われるＵＬ送信に対するものである（Ｓ１６０８）。ＶＵＬ承認に対するフィードバックをＵＥがモニタするサブフレームはｅＮＢによって設定される。

【0174】

[187] ＡＣＫが受信されると、ＵＥはＶＵＬ承認上のＵＬデータの送信に成功したと見なす（Ｓ１６０９）。一方、ＮＡＣＫが受信されたりＡＣＫが受信されないと、ＵＥはＶＵＬ承認上のＵＬデータの送信に失敗したと見なし、ＢＳＲをトリガーしてＵＬデータに対するＵＬ承認を要求する（Ｓ１６１０）。

【0175】

[188] 本発明を本発明の特徴又は範囲を逸脱しない範囲で他の特定の形態として具体化できることが、当業者には明らかである。したがって、本発明の範囲は、添付した請求項の合理的解釈によって決定されるべきであり、本発明の同等な範囲内における変更はいずれも本発明の範囲に含まれる。以上説明した実施例は、本発明の構成要素と特徴が所定形態で結合したものである。各構成要素又は特徴は、別の明示的言及がない限り、選択的なものとして考慮される必要がある。各構成要素又は特徴を他の構成要素や特徴と結合しない形態で実施することができる。また、一部の構成要素及び／又は特徴を結合して本発明の実施例を構成することもできる。本発明の実施例において説明される動作の順序は変更されてもよい。ある実施例の一部の構成や特徴が他の実施例に含まれてもよく、又は他の実施例の対応する構成又は特徴に取り替わってもよい。特許請求の範囲において明示的な引用関係にない請求項を結合して実施例を構成したり、出願後の補正によって新しい請求項として含めてもよいことは明らかである。

【0176】

[189] 本発明の実施例において、基地局（ＢＳ）によって行われると説明した特定動作は、上位ノードのＢＳによって行われてもよい。明らかに、ＢＳを含む複数のネットワークノードにおいて、ＭＳとの通信のために行われる様々な動作が基地局によって行われたり、基地局以外の他のネットワークノードによって行われ得ることは明らかである。‘ｅＮＢ’という用語は、‘固定局（ｆｉｘｅｄ ｓｔａｔｉｏｎ）’、‘ＮｏｄｅＢ、‘基地局（ＢＳ）’、アクセスポイントなどに言い換えてもよい。

【0177】

[190] 上述した実施例は、例えば、ハードウェア、ファームウェア、ソフトウェア又はそれらの組み合わせのような様々な手段によって具現されてもよい。

【0178】

[191] ハードウェア設定において、本発明の実施例に係る方法は、一つ以上のＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、ＤＳＰ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、ＤＳＰＤ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｉｎｇ ｄｅｖｉｃｅ）、ＰＬＤ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ）、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどによって具現することができる。

【0179】

[192] ファームウェアやソフトウェアによる具現の場合、本発明の一実施例は、以上で説明した機能又は動作を行うモジュール、手順、関数などの形態によって具現することができる。ソフトウェアコードはメモリーユニットに保存され、プロセッサによって駆動することができる。上記メモリーユニットは上記プロセッサの内部又は外部に位置し、既に公知の様々な手段によって上記プロセッサとデータをやり取りすることができる。

【0180】

[193] 本発明は、本発明の特徴を逸脱しない範囲で他の特定の形態として具体化できるということが当業者には明らかである。したがって、上記の詳細な説明はいずれの面においても制限的に解釈されてはならず、例示的なものとして考慮されなければならない。本発明の範囲は、添付した請求項の合理的解釈によって決定されるべきであり、本発明の同等な範囲内における変更はいずれも本発明の範囲に含まれる。

【産業上の利用可能性】

【0181】

[194] 以上の方法は、３ＧＰＰ ＬＴＥシステムに適用される例示を中心に説明されたが、本発明は、３ＧＰＰ ＬＴＥシステムの他にも様々な無線通信システムに適用可能である。

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】