特許 6092979 ＨＳＵＰＡ無線通信システムの送信ブロッキングを防ぐ方法と装置

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

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

(11)【特許番号】6092979

(24)【登録日】2017年2月17日

(45)【発行日】2017年3月8日

(54)【発明の名称】ＨＳＵＰＡ無線通信システムの送信ブロッキングを防ぐ方法と装置

(51)【国際特許分類】

   H04W 72/12 20090101AFI20170227BHJP

   H04W 72/04 20090101ALI20170227BHJP

【ＦＩ】

   H04W72/12 130

   H04W72/04 136

【請求項の数】16

【全頁数】14

(21)【出願番号】特願2015-204863(P2015-204863)

(22)【出願日】2015年10月16日

(62)【分割の表示】特願2014-419(P2014-419)の分割

【原出願日】2007年8月16日

(65)【公開番号】特開2016-27761(P2016-27761A)

(43)【公開日】2016年2月18日

【審査請求日】2015年11月16日

(31)【優先権主張番号】60/839,198

(32)【優先日】2006年8月21日

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

(73)【特許権者】

【識別番号】596008622

【氏名又は名称】インターデイジタル テクノロジー コーポレーション

(74)【代理人】

【識別番号】110001243

【氏名又は名称】特許業務法人 谷・阿部特許事務所

(72)【発明者】

【氏名】ポール マリニエール

【審査官】 望月 章俊

(56)【参考文献】

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

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

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

【文献】 3GPP TS 25.321 V6.9.0，3GPP，２００６年 ６月

【文献】 Panasonic，Content of E-AGCH，3GPP TSG-RAN WG2#46bis meeting R2-050817，3GPP，２００５年 ４月 ４日

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

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

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

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

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

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

【請求項1】

ネットワークデバイスであって、
無線送信／受信ユニット（ＷＴＲＵ）へ、バッファ状態情報を含む周期的なスケジュール情報の前記ＷＴＲＵによる伝送についての構成情報を送信するように構成された少なくとも１つのプロセッサと、
前記ＷＴＲＵの媒体アクセス制御（ＭＡＣ）フローのデータが伝送され得ないときに、アップリンク制御チャネルにおいて送信時間間隔（ＴＴＩ）内に、スケジュール情報の伝送の代わりに、アップリンクデータチャネルについてのアップリンクグラントが必要とされていることのインジケーションを受信するように構成された受信器と、
を備え、
前記ＴＴＩ内に、前記アップリンクデータチャネルが前記ＷＴＲＵによって伝送されず、
前記少なくとも１つのプロセッサは、前記受信したインジケーションに応答して、前記ＷＴＲＵへアップリンクグラントを送信するようにさらに構成されており、
前記受信器は、前記アップリンクグラントに応じて前記アップリンクデータチャネルにおいて前記ＷＴＲＵから、前記スケジュール情報を受信するようにさらに構成されている、ネットワークデバイス。

【請求項2】

フィードバック情報が、前記アップリンク制御チャネルで、前記アップリンクデータチャネルよりも低い電力レベルで、受信される、請求項１に記載のネットワークデバイス。

【請求項3】

前記ＷＴＲＵが前記アップリンクデータチャネルでアップリンクデータを送信できないことに応じて、フィードバック情報が前記アップリンク制御チャネルで送信される、請求項１に記載のネットワークデバイス。

【請求項4】

前記ネットワークデバイスは、基地局、ノードＢ、サービスノードＢ、ＨＳＵＰＡ（ｈｉｇｈ ｓｐｅｅｄ ｕｐｌｉｎｋ ｐａｃｋｅｔ ａｃｃｅｓｓ）ネットワークデバイス、又は３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）ネットワークデバイスのうちの１つである、請求項１に記載のネットワークデバイス。

【請求項5】

前記スケジュール情報はＨＳＵＰＡ（ｈｉｇｈ ｓｐｅｅｄ ｕｐｌｉｎｋ ｐａｃｋｅｔ ａｃｃｅｓｓ）スケジュール情報である、請求項１に記載のネットワークデバイス。

【請求項6】

前記ＨＳＵＰＡスケジュール情報は周期的に送信される、請求項５に記載のネットワークデバイス。

【請求項7】

前記アップリンク制御チャネルはＥ−ＤＰＣＣＨ（ｅｎｈａｎｃｅｄ ｄｅｄｉｃａｔｅｄ ｐｈｙｓｉｃａｌ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）である、請求項１に記載のネットワークデバイス。

【請求項8】

前記アップリンクデータチャネルは、Ｅ−ＤＰＤＣＨ（ｅｎｈａｎｃｅｄ ｄｅｄｉｃａｔｅｄ ｐｈｙｓｉｃａｌ ｄａｔａ ｃｈａｎｎｅｌ）である、請求項１に記載のネットワークデバイス。

【請求項9】

ネットワークデバイスにより実行される方法であって、
前記ネットワークデバイスにより、無線送信／受信ユニット（ＷＴＲＵ）へ、バッファ状態情報を含む周期的なスケジュール情報の前記ＷＴＲＵによる伝送についての構成情報を送信することと、
前記ネットワークデバイスにより、前記ＷＴＲＵの媒体アクセス制御（ＭＡＣ）フローのデータが伝送され得ないときに、アップリンク制御チャネルにおいて送信時間間隔（ＴＴＩ）内に、スケジュール情報の伝送の代わりに、アップリンクデータチャネルについてのアップリンクグラントが必要とされていることのインジケーションを受信することと、
前記ＴＴＩ内に、前記アップリンクデータチャネルが前記ＷＴＲＵによって伝送されず、
前記ネットワークデバイスにより、前記受信したインジケーションに応答して、前記ＷＴＲＵへアップリンクグラントを送信することと、
前記ネットワークデバイスにより、前記アップリンクグラントに応じて前記アップリンクデータチャネルで前記ＷＴＲＵから、前記スケジュール情報を受信することと、
を備える、方法。

【請求項10】

フィードバック情報が、前記アップリンク制御チャネルで、前記アップリンクデータチャネルよりも低い電力レベルで、受信される、請求項９に記載の方法。

【請求項11】

前記ＷＴＲＵが前記アップリンクデータチャネルでアップリンクデータを送信できないことに応じて、フィードバック情報が前記アップリンク制御チャネルで送信される、請求項９に記載の方法。

【請求項12】

前記ネットワークデバイスは、基地局、ノードＢ、サービスノードＢ、ＨＳＵＰＡ（ｈｉｇｈ ｓｐｅｅｄ ｕｐｌｉｎｋ ｐａｃｋｅｔ ａｃｃｅｓｓ）ネットワークデバイス、又は３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）ネットワークデバイスのうちの１つである、請求項９に記載の方法。

【請求項13】

前記スケジュール情報はＨＳＵＰＡ（ｈｉｇｈ ｓｐｅｅｄ ｕｐｌｉｎｋ ｐａｃｋｅｔ ａｃｃｅｓｓ）スケジュール情報である、請求項９に記載の方法。

【請求項14】

前記ＨＳＵＰＡスケジュール情報は周期的に送信される、請求項１３に記載の方法。

【請求項15】

前記アップリンク制御チャネルはＥ−ＤＰＣＣＨ（ｅｎｈａｎｃｅｄ ｄｅｄｉｃａｔｅｄ ｐｈｙｓｉｃａｌ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）である、請求項９に記載の方法。

【請求項16】

前記アップリンクデータチャネルは、Ｅ−ＤＰＤＣＨ（ｅｎｈａｎｃｅｄ ｄｅｄｉｃａｔｅｄ ｐｈｙｓｉｃａｌ ｄａｔａ ｃｈａｎｎｅｌ）である、請求項９に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、高速上りリンク・パケット・アクセス（ｈｉｇｈ ｓｐｅｅｄ ｕｐｌｉｎｋ ｐａｃｋｅｔ ａｃｃｅｓｓ、ＨＳＵＰＡ）無線通信システムに関する。より具体的には、本発明は、ＨＳＵＰＡ無線通信システムの送信ブロッキングを防ぐ方法と装置に関する。

【背景技術】

【0002】

第３世代パートナーシップ・プロジェクト（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ、３ＧＰＰ）リリース６は、ＨＳＵＰＡにおけるノードＢベースのスケジューリングを通して無線送信／受信ユニット（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ／Ｒｅｃｅｉｖｅ Ｕｎｉｔ、ＷＴＲＵ）送信の高速制御を定めている。この高速制御では、上りリンク（ＵｐＬｉｎｋ、ＵＬ）雑音増加を良好に制御しており、スレッシュホウルドを超えずに、従ってシステム容量を増加させて、より高い平均ＵＬ負荷での動作を可能としている。ＨＳＵＰＡでは、制御とフィードバックは、異なる物理制御チャネルおよび情報要素（Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ、ＩＥ）を通じて起こる。

【0003】

絶対的許可チャネル（Ａｂｓｏｌｕｔｅ Ｇｒａｎｔ Ｃｈａｎｎｅｌ）または相対的許可チャネル（Ｒｅｌａｔｉｖｅ Ｇｒａｎｔ Ｃｈａｎｎｅｌ）によりノードＢ命令を伝達し、一方、エンハンスト個別物理制御チャネル（Ｅｎｈａｎｃｅｄ Ｄｅｄｉｃａｔｅｄ Ｐｈｙｓｉｃａｌ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ、Ｅ−ＤＰＣＣＨ）に、即ちＥ−ＤＰＣＣＨ内の“ハッピービット”に乗せて、ＷＴＲＵフィードバックを送信し、ペイロードにスケジュール情報（Ｓｃｈｅｄｕｌｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ、ＳＩ）を添付する。ＵＬ制御チャネル（ＤＰＣＣＨ）の電力に対する最大電力比でノードＢ命令を表現する。再送信シーケンス番号（Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ、ＲＳＮ）に対する２ビットおよびエンハンスト・トランスポート・フォーマット組合せ表示（Ｅｎｈａｎｃｅｄ Ｔｒａｎｓｐｏｒｔ Ｆｏｒｍａｔ Ｃｏｍｂｉｎａｔｉｏｎ Ｉｎｄｉｃａｔｉｏｎ、Ｅ−ＴＦＣＩ）に対する７ビットと一緒に、Ｅ−ＤＰＣＣＨ内でハッピービットを送信する。エンハンスト・トランスポート・フォーマット組合せ（Ｅｎｈａｎｃｅｄ Ｔｒａｎｓｐｏｒｔ Ｆｏｒｍａｔ Ｃｏｍｂｉｎａｔｉｏｎ、Ｅ−ＴＦＣ）の特定のサイズを意味するため、７ＴＦＣＩビットの全ての組合せを定める。ＳＩのみの送信を意味するため、値“０”（７ビット）を定める。圧縮モードの間を除いて、エンハンスト個別物理データ・チャネル（Ｅｎｈａｎｃｅｄ Ｄｅｄｉｃａｔｅｄ Ｐｈｙｓｉｃａｌ Ｄａｔａ Ｃｈａｎｎｅｌ、Ｅ−ＤＰＤＣＨ）と一緒に、Ｅ−ＤＰＣＣＨを常に送信する。Ｅ−ＤＰＣＣＨのみの送信は起こらない。

【0004】

ＷＴＲＵおよびノードＢは、所定の電力比でどれだけ多くのデータを送信できるか承知しており、ＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）がこの対応を制御する。そのようなスケジュール動作は、遅延に敏感では無いアプリケーションに特によく適するが、しかしながら、高速な資源割付能力を与えれば、より多くの遅延に敏感なアプリケーションを支援するために使用することができる。

【0005】

現行の標準の下では、選択的にデータを分割し、無線リンク制御（ｒａｄｉｏ ｌｉｎｋ ｃｏｎｔｒｏｌ、ＲＬＣ）層でバッファする。媒体アクセス制御（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ、ＭＡＣ）層に配信する、可能なＲＬＣパケット・データ・ユニット（ｐａｃｋｅｔ ｄａｔａ ｕｎｉｔ、ＰＤＵ）サイズの組を、無線資源制御（ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ、ＲＲＣ）信号が構成する。分割が起こる場合、一般的には、数百ビット程度であるようにＰＤＵのサイズを構成し、過剰なオーバヘッドを防ぎ、良好な符号化性能を得る。現行では、ＭＡＣ層では更なる分割はない。従って、新しい送信が起こる場合、ゼロを含む整数のＰＤＵを送らなければならない。

【0006】

ＲＬＣ ＰＤＵのわずかな部分も送出することはできないので、ＷＴＲＵに対するある最小の時間間隔（瞬間）のビットレートが課せられる。例えば、ＰＤＵサイズが３２０ビットで、送信時間間隔（ＴＴＩ）が２ミリ秒（ｍｓ）であるなら、瞬間ビットレートは、ＭＡＣオーバヘッドを含めないで、少なくとも１６０キロビット毎秒（ｋｂｐｓ）である必要がある。そのような瞬間ビットレートはある最小の送信電力比になり、この下では全くＲＬＣ ＰＤＵを送信できない。

【0007】

スケジュール動作の間、許可された電力比がバッファの先頭でＲＬＣ ＰＤＵの送信に必要とする最小値に該当するなら、所定のＭＡＣ−ｄフローからのＷＴＲＵ送信を完全に中断する、即ちブロックすることができる。そのような状況は、多くの理由で、サービス中の無線リンク・セット（即ち、ノードＢ）の制御外で起こる可能性がある。例えば、ＷＴＲＵは、もう一つのノードＢから電力を削減するよう要求する非サービス中の相対的許可（ｒｅｌａｔｉｖｅ ｇｒａｎｔ）を受信してしまう可能性があり、ＷＴＲＵは、サービス中のノードＢからの相対的許可命令または絶対的許可（ａｂｓｏｌｕｔｅ ｇｒａｎｔ）命令を誤ってデコードしてしまう可能性があり、または、ＷＴＲＵは、所定のＭＡＣ−ｄフローに、数個の異なる構成されたＲＬＣ ＰＤＵサイズを持つ可能性があり、通常のＲＬＣ ＰＤＵサイズ以上が送信の対象となる。

【0008】

そのような状況が起こる場合は、ＷＴＲＵは、ＳＩを送信するようスケジュールされた時まで送信できない。その時まで、および、以前のＳＩの送信が、その後の送信に基づきＷＴＲＵバッファが空でないとノードＢが推察するのに十分な程最近に行われない限り、ノードＢは、電力比が最小よりも低下したために、または単にＷＴＲＵが何も送信するものを持っていないたに、送信が停止されたのかどうかを決定する能力を全く持たない。その結果、ＷＴＲＵからの送信は、ＳＩを送信できるまで遅延させられる。

【0009】

この問題点は、遅延に敏感なアプリケーションに対する小さな周期性を持つＳＩ送信（Ｔ＿ＳＩＧ）の構成を課し、それによって、オーバヘッドが増加する。さらに、多数のＲＬＣ ＰＤＵサイズを構成する場合、電力比が余りにも低いために送信を停止したとノードＢが気付いた場合でも、ノードＢはその状況を修正するためどれだけの電力比を適用すべきか分からない。それ故、ノードＢは、正しい電力比は何なのか、試行錯誤で見出さなければならない。これは、不効率な資源割付および／または過剰なスケジュール遅延をもたらす。

【0010】

現状の技術では、スケジュール情報（ｓｃｈｅｄｕｌｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ、ＳＩ）の送信は、３ＧＰＰ ＴＳ ２５．３２１で次のように説明しているある条件化でのみ許容される。即ち、ユーザがゼロの許可（電力比）を持つかまたはユーザのプロセスの全てが非活性化していて、かつユーザが送信すべきデータを有している場合に、Ｅ−ＤＣＨサービス中のＲＬＳ（基地局）の変化に基づいてするか、あるいは、ユーザが許可（Ｇｒａｎｔ）を持っているかいないかに関わらず構成可能な時間間隔で周期的にするかである。その結果、現状の技術が定めるメカニズムと両立できるであろうブロッキング阻止の解決策には、殆んど全ての新しいデータを送信するのと一緒にＳＩを送信するような、非常に低い速度でＳＩを周期的に報告する構成を含めてもよい。しかしながら、各ＳＩが１８ビットを取るため、オーバヘッドが非常に大きく増加する可能性がある。２８０ビットのＭＡＣサービス・データ・ユニット（ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ、ＳＤＵ）サイズおよび１８ビットのＭＡＣ−ｅヘッダ・サイズを仮定すると、これは、約６％の追加オーバヘッドを示すだろう。

【0011】

従って、ＨＳＵＰＡ無線通信システムにおいて、現状技術の制限に左右されない送信ブロッキングの方法と装置を提供することは、利益のあることだろう。

【発明の概要】

【0012】

本発明は送信ブロッキングを防止する方法と装置に関する。媒体アクセス制御−ｄ（ＭＡＣ−ｄ）の送信が停止した場合のスケジュール情報（ｓｃｈｅｄｕｌｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ、ＳＩ）の送信である。トリガ条件を満足する場合、本ＳＩを送信する。

【0013】

例として与え、添付の以下の図とともに理解すべき、好ましい実施形態の以下の説明から、本発明についてさらに詳細な理解をもつ可能性がある。

【図面の簡単な説明】

【0014】

【図1】本発明に従って構成した、ＷＴＲＵとノードＢを示す機能ブロック図である。

【図2】本発明に従い、ＨＳＵＰＡ無線通信システムにおける送信ブロッキングを防ぐ方法のフロー図である。

【図3】本発明のもう一つの実施形態に従い、ＨＳＵＰＡ無線通信システムにおける送信ブロッキングを防ぐ方法のフロー図である。

【図4】本発明のもう一つの実施形態に従い、ＨＳＵＰＡ無線通信システムにおける送信ブロッキングを防ぐ方法のフロー図である。

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

【0015】

今後参照する場合、用語“無線送信／受信ユニット(ｗｉｒｅｌｅｓｓ ｔｒａｎｓｍｉｔ／ｒｅｃｅｉｖｅ ｕｎｉｔ、ＷＴＲＵ）”には、ユーザ機器（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ、ＵＥ）、モバイル局、固定またはモバイル加入者ユニット、ページャ、セルラ電話、携帯情報端末（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ、ＰＤＡ）、コンピュータ、または無線環境において動作可能な他の任意の形態のユーザ装置を含むが、限定はしない。今後参照する場合、用語“基地局”には、ノードＢ、サイト制御装置、アクセス・ポイント（ａｃｃｅｓｓ ｐｏｉｎｔ、ＡＰ）、または無線環境において動作可能な他の任意の形態のインタフェース装置を含むが、限定はしない。

【0016】

図１は、本発明に従って構成したＷＴＲＵ１１０とＮＢ１２０の機能ブロック図１００である。図１に示すように、ＷＴＲＵ１１０はＮＢ１２０と通信状態にあり、両方とも、本発明に従い、無線通信システムにおける送信ブロッキングを防ぐ方法を実行するよう構成される。

【0017】

典型的なＷＴＲＵで見られる可能性のある部品に加えて、ＷＴＲＵ１１０には、プロセッサ１１５、受信器１１６、送信器１１７およびアンテナ１１８を含む。本発明に従い、ＨＳＵＰＡ無線通信システムにおける送信ブロッキングを防ぐ方法を実行するよう、プロセッサ１１５を構成する。受信器１１６および送信器１１７は、プロセッサ１１５と通信状態にある。アンテナ１１８は、受信器１１６および送信器１１７の両方と通信状態にあり、無線データの送信と受信を手助けする。

【0018】

典型的なノードＢで見られる可能性のある部品に加えて、ＮＢ１２０には、プロセッサ１２５、受信器１２６、送信器１２７およびアンテナ１２８を含む。本発明に従い、ＨＳＵＰＡ無線通信システムにおける送信ブロッキングを防ぐ方法を実行するよう、プロセッサ１１５を構成する。受信器１２６および送信器１２７は、プロセッサ１２５と通信状態にある。アンテナ１２８は、受信器１２６および送信器１２７の両方と通信状態にあり、無線データの送信と受信を手助けする。

【0019】

図２は、本発明に従い、ＨＳＵＰＡ無線通信システムにおける送信ブロッキングを防ぐ方法２００のフロー図である。本発明の本実施形態では、ＳＩの送信のために、新しい条件を生成する。ステップ２１０では、ＳＩを送信するトリガ条件を検出する。例えば、現行のゼロではない許可が、特定のＭＡＣ−ｄフローの次のＭＡＣ ＳＤＵ、またはＲＬＣ ＰＤＵを送信するのに必要な最小値より小さいため、任意の、または特別に定めたＭＡＣ−ｄフローを停止する場合、ＳＩのみの送信が起こってもよい。この場合には、所定のＭＡＣ−ｄフローの単一のＰＤＵを送信することが可能でない場合に、トリガ条件が起こり得る。望ましくは、ＭＡＣ−ｄフローは、インデックスで識別または特定されてもよい論理チャネルのグループである。

【0020】

ひとたびトリガ条件を決定すると、特定のＷＴＲＵ１１０はＳＩを送信する（ステップ２２０）。トリガ条件が満たされ、そしてその後周期的に、(例えば、構成可能な区間で）満たされた場合、この送信は一度だけ生起するか、またはトリガ条件が生起する毎に送信が生起してもよい。加えて、ブロッキングのためＳＩの送信をトリガすることに制約されるＭＡＣ−ｄフローのリストを、より高い層により信号伝達してもよく、同様に、条件がひとたび満足した場合は送信の構成可能な周期性により信号伝達してもよい。

【0021】

図３は、本発明のもう一つの実施形態に従い、ＨＳＵＰＡ無線通信システムにおける送信ブロッキングを防ぐ方法３００のフロー図である。ステップ３１０では、トリガ条件を検出する。好ましくは、ステップ３１０で満足するトリガ条件は、実質的には、上記の方法２００のステップ２１０で述べたトリガ条件に類似である。しかしながら、方法２００と異なり、ステップ３１０でトリガ条件を検出すると、ＳＩを送信する代わりに、Ｅ−ＤＰＤＣＨになにも送信せず、Ｅ−ＤＰＣＣＨの全ての１０ビットをゼロ“０”の値に設定する（ステップ３２０）。

【0022】

実際には、ＳＩを実際に送信しない場合を除き、ＳＩのみを最初に送信する場合に関しては、これは同じ設定に相当する。この技術の利点は、必要な送信電力が、ＳＩを実際に送信する場合よりはるかに低下するということである。しかしながら、ネットワークがＥ−ＤＰＣＣＨに何かを送信したことを検出するのに十分高い値で、Ｅ−ＤＰＣＣＨを送信すべきである。加えて、ＷＴＲＵ１１０におけるバッファの状態については、ネットワークに対してもっと少ない情報を利用可能としてもよい。

【0023】

図４は、本発明のもう一つの実施形態に従い、ＨＳＵＰＡ無線通信システムにおける送信ブロッキングを防ぐ方法４００のフロー図である。本発明の本実施形態では、最小電力比を示す改善されたフィードバック即ちＭＡＣ ＳＤＵサイズを利用する。

【0024】

現状の技術では、可能なＭＡＣ ＳＤＵサイズ、または等価なＲＬＣ ＳＤＵサイズは、ＲＲＣ信号を通して、無線ベアラのセットアップまたは再構成で構成される。また、ＮＢ１２０は、ＮＢアプリケーション・パート（ＮＢ ａｐｐｌｉｃａｔｉｏｎ ｐａｒｔ、ＮＢＡＰ）信号を通して、ＰＤＵサイズに気付く。あるサイズのＥ−ＴＦＣ（ＭＡＣ−ｅ ＰＤＵ）を送信するのに必要な電力比許可を、ＷＴＲＵ１１０、ＮＢ１２０およびＲＮＣが知り、ＲＲＣ／ＮＢＡＰ信号を通して任意の変更を信号伝達する。それ故、現行の標準で利用可能な情報を使用して、構成した各々のＲＬＣ ＰＤＵサイズに対して単一のＲＬＣ ＰＤＵを含むＥ−ＴＦＣを送信するため、どれほどの電力比を必要とするかを、ＮＢ１２０は決定することができるであろう。

【0025】

現行の標準で定まる信号伝達を活用して、構成したＲＬＣ ＰＤＵサイズの中で最大のＲＬＣ ＰＤＵサイズを送信するのに必要なものより低い電力比をＷＴＲＵ１１０へ決して信号伝達しないことにより、ＮＢ１２０は問題点の発生頻度を削減できる可能性がある。しかしながら、“下げよ”という非サービス中の相対的許可を受信したため、またはサービス中の許可を誤解したため、ＷＴＲＵ１１０は送信をブロックする可能性が依然として存在するかもしれない。ＷＴＲＵの側で送信のために一列になっている次のＲＬＣ ＰＤＵのサイズに気が付かないため、ＮＢ１２０は最大のＲＬＣ ＰＤＵを仮定すべきである。構成した一つのＲＬＣ ＰＤＵサイズ以上があるとすぐに、ＮＢ１２０は、より小さなＲＬＣ ＰＤＵサイズの一つを使用するときは何時も、ＷＴＲＵ１１０に資源を過剰に割付ける。

【0026】

その結果、ＷＴＲＵ１１０はＮＢ１２０に新しい形式の制御情報を信号伝達してもよく、送信のためにバッファした次のＲＬＣ ＰＤＵのサイズに関して、ＷＴＲＵ１１０に許可すべき最小電力比に気付く可能性がある。この情報は、好ましくは、最小許可情報（Ｍｉｎｉｍｕｍ Ｇｒａｎｔ Ｉｎｆｏｒｍａｔｉｏｎ、ＭＧＩ）として参照されてもよい。

【0027】

方法４００のステップ４１０では、本ＭＧＩを設定する。多くの方法でＭＧＩの設定を達成できる可能性がある。例えば、そのバッファにあるデータを持つ最高の優先度のＭＡＣ−ｄフローの一つに、またはＲＲＣ信号によって構成する可能性のある特定のＭＡＣ−ｄフローに、（即ち、現行のＥ−ＴＦＣを送信した後）送信列内の次のＲＬＣ ＰＤＵのサイズに本ＭＧＩを設定してもよい。加えて、最高の優先度のＭＡＣ−ｄフローの最大バッファのＲＬＣ ＰＤＵのサイズに従って、本ＭＧＩを設定してもよい。また、最高の優先度のＭＡＣ−ｄフローの最大バッファのＲＬＣ ＰＤＵのサイズに従って、または、現行の許可および多くの活性化プロセスで、ある遅延で送信されることが期待される特定のＭＡＣ−ｄフローに、本ＭＧＩを設定してもよい。また、ＲＲＣ信号が本遅延を構成する可能性がある。

【0028】

本ＭＧＩを送信すべきと決定した後、次に本ＭＧＩを符号化する（ステップ４２０）。本ＭＧＩのフィールド値を設定するのに使用するサイズを持つＲＬＣ ＰＤＵを記述するため、“次のＲＬＣ ＰＤＵ”を使用してもよい。次に、各種の方法に従って、本ＭＧＩを符号化してもよい。例えば、５ビットから構成し、３ＧＰＰ ＴＳ ２５．２１２仕様で見られるものと同様のビット・マッピングのようなマッピングで電力比を表すよう、本ＭＧＩを符号化してもよい。この場合には、信号伝達する電力比は、次のＲＬＣ ＰＤＵの送信を許可する最小値であるだろう。

【0029】

或いは、本ＭＧＩは、より少ないビット数で符号化され、電力比を表わしてもよい。しかしながら、この場合には、マッピングは異なっており、３ＧＰＰ ＴＳ ２５．２１２仕様で見るマッピングより低い精度を持ってもよい。例えば、本ＭＧＩを上記で述べた５ビットより少ないビット数で符号化してもよい。加えて、マッピングは事前に確立されている可能性があるであろう。

【0030】

もう一つの代替案では、いかに多くの可能性のあるＲＬＣ ＰＤＵサイズを現わすべきかに依存して、可変ビット数で本ＭＧＩを構成してもよい。例えば、４個の構成したＲＬＣ ＰＤＵサイズがある場合には、２個のＭＧＩビットが必要とされ、各組合せは特定のＲＬＣ ＰＤＵサイズを表わすであろう。注意すべきことは、全ての構成したＲＬＣ ＰＤＵサイズがマッピングされる必要性は必ずしもない、ということである。その結果、ＲＬＣ ＰＤＵサイズのサブセットのみをマッピングする場合、ＷＴＲＵ１１０は、次のＲＬＣ ＰＤＵより大きな最小ＲＬＣ ＰＤＵサイズに従って、本ＭＧＩを設定する。

【0031】

次に、ＷＴＲＵ１１０は本ＭＧＩを送信する（ステップ４３０）。本ＭＧＩのトリガは数種の方法の一つで起る可能性がある。例えば、ひとたびその値が本ＭＧＩ設定に従って変化する場合、本ＭＧＩを送信してもよい。また、新しいＭＡＣ−ｅ送信の特定の数（Ｎ）のそれそれで本ＭＧＩを送信してもよい。ここでＮは無線資源制御装置（ＲＲＣ）によって構成可能である。加えて、少なくとも特定の数（Ｍ）の送信時間間隔（ｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅ ｉｎｔｅｒｖａｌ、ＴＴＩ）の遅延によって、２個の連続したＭＧＩ送信を分離するということが要求される。ここでまた、ＭはＲＲＣによって構成可能である。

【0032】

ひとたび送信されると、望ましくはＭＡＣ−ｅ ＰＤＵと同じ時間に、ＮＢ１２０が本ＭＧＩを受信して復号し（ステップ４４０）、ＮＢ１２０は本ＭＧＩに基づき調整を行う（ステップ４５０）。望ましくは、ＮＢ１２０は電力比を調整して、送信のためバッファした次のＲＬＣ ＰＤＵの送信を可能にする。

【0033】

本発明のもう一つの実施形態では、許可（Ｇｒａｎｔ）のスケジュールの使用を通してデータレートを管理する。この実施形態では、電力比が課したデータレートに関係なく、また、ひとつのＰＤＵまたは複数のＰＤＵのサイズに関係なく、新しい各ＭＡＣ−ｅ送信毎にＭＡＣ−ｄフローの最小数のＰＤＵ（Ｎ_min）に対する送信を許可する。

【0034】

現行の３ＧＰＰ標準、（例えば、ＴＳ ２５．３０９リリース６）の下では、スケジュールされていない送信（非スケジュール送信）またはスケジュールされた許可（スケジュール許可）の両方ではなく、どちらかを通して、ＭＡＣ−ｄフローを管理する。所定のＭＡＣ−ｄフローのための非スケジュール送信を利用して、このＭＡＣ−ｄフローのための現行技術の問題点を克服できるであろうが、このフローによって発生する干渉量に対する制御を失うという犠牲が伴う。

【0035】

しかしながら、本発明の本ハイブリッド・スケジュール／非スケジュール実施形態では、雑音増加安定性の点からスケジュール許可の利点を維持し、一方、単一のＰＤＵ送信のスレッシュホウルドに該当する許可された電力比のため、決して送信を完全にはブロックしないということを確実にしている。ＲＲＣ信号を通して、新しい送信に許可するＮ_minを設定してもよい。

【0036】

Ｎ_minのＰＤＵを送信するために要求する電力比が現行の許可（Ｇｒａｎｔ）より高ければ、数個の選択肢を採用してもよい。望ましくは、ＰＤＵの送信をサポートする現行の許可以上に増加するよう、電力比を許可する。しかしながら、Ｎ_minのＰＤＵをサポートすることが可能な最小Ｅ−ＴＦＣを選択するＷＴＲＵ１１０で、電力比はまた、現行の許可に留まってもよい。同じ電力に対して、このシナリオではより多くのデータを送信するので、このＭＡＣ−ｅ ＰＤＵのため、もっと多くのハイブリッド自動再送要求（ＨＡＲＱ）の再送信を要求するであろう。

【0037】

例えば、ＭＡＣ−ｄフローが２個の構成したＲＬＣ ＰＤＵサイズ、３００ビットおよび６００ビットを持つと仮定すると、ＭＡＣ−ｅ ＰＤＵを送信するために必要な最小電力比は、もし３００ビットの２個のＲＬＣ ＰＤＵを含むなら、（４７／１５）²であると仮定してもよく、もし６００ビットの単一のＲＬＣ ＰＤＵを含むなら、（５３／１５）²であると仮定してもよい。３００ビットのＰＤＵサイズを殆どの時間に送信し、６００ビットのものにまれに遭遇するというシナリオでは、ＷＴＲＵ１１０のために活性化したＨＡＲＱプロセスに対して、ＷＴＲＵ１１０に許可する電力比を（５３／１５）²に維持してもよいだろう。許可のスケジューリングによって管理されるＭＡＣ−ｄフローを有する現行の標準の下で、６００ビットのＲＬＣ ＰＤＵがバッファの先頭に現れた場合、その送信はブロックするであろう。本発明の本実施形態であるハイブリッド非スケジュール／スケジュール解決策で、６００ビットのＲＬＣ ＰＤＵを含むそのＭＡＣ−ｅ ＰＤＵを送信するよう、ＷＴＲＵ１１０を許可するであろうし、再送信を中断しないであろう。このＭＡＣ−ｅ送信のために、干渉は計画よりやや高い可能性があるか、または、現行の許可以上に増加するよう電力比を許可するかしないかに依存して、より多くのＨＡＲＱ再送信がより高い確率で存在する可能性があるだろう。

【0038】

本発明の特徴と要素について、特別の組合せの好ましい実施形態で説明したが、好ましい実施形態の他の特徴および要素がなく、または、本発明の他の特徴および要素を有するまたは有しない各種の組合せにおいて、各特徴または要素を単独に使用できる。本発明で提示した方法またはフローチャートは、コンピュータ・プログラム、ソフトウエア、または、汎用コンピュータまたはプロセッサが実行するためのコンピュータ読取可能な記憶媒体に明白に組込んだファームウエアに実装してもよい。コンピュータ読取可能な記憶媒体の例には、読取専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、レジスタ、キャッシュ・メモリ、半導体メモリ素子、内部ハードデスクおよびリム−バブル・デスクのような磁気媒体、磁気−光媒体、およびＣＤ−ＲＯＭデスクのような光媒体、そしてデジタル多目的デスク（ＤＶＤ）を含む。

【0039】

適当なプロセッサには、例として、汎用プロセッサ、専用プロセッサ、従来プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連動する一つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）回路、任意の他の形式の集積回路（ＩＣ）、および／またはステート・マシンを含む。

【0040】

無線送信／受信ユニット(ｗｉｒｅｌｅｓｓ ｔｒｎｓｍｉｔ／ｒｅｃｅｉｖｅ ｕｎｉｔ、ＷＴＲＵ）、ユーザ機器（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ、ＵＥ）、端末、基地局、無線ネットワーク制御装置（ｒａｄｉｏ ｎｅｔｗｏｒｋ ｃｏｎｔｒｏｌｌｅｒ、ＲＮＣ）、または任意のホストコンピュータにおける用途に無線周波数送信器を実装するため、ソフトウエアと関連するプロセッサを使用してもよい。カメラ、ビデオカメラ・モジュール、ビデオフォン、スピーカフォン、振動デバイス、スピーカ、マイクロフォン、テレビジョン・トランシーバ、ハンドフリー・ヘッドセット、キーボード、ブルートゥース「商標」モジュール、周波数変調（ＦＭ）無線ユニット、液晶ディスプレイ（ＬＣＤ）表示装置、有機発光ダイオード（ＯＬＥＤ）表示装置、デジタル音楽プレヤ、メディアプレーヤ、ビデオゲーム・プレーヤ・モジュール、インターネット・ブラウザ、および／または任意の無線ローカル・エリア・ネットワーク（ＷＬＡＮ）モジュールのようなハードウエアおよび／またはソフトウエアに実装するモジュールと連動して、本ＷＴＲＵを使用してもよい。

【0041】

実施例
１． 少なくとも一つの無線送信／受信ユニット（ｗｉｒｅｌｅｓｓ ｔｒａｎｓｍｉｔ／ｒｅｃｅｉｖｅ ｕｎｉｔ、ＷＴＲＵ）および少なくとも一つのノードＢ（ＮＢ）を含むようにした、無線通信システムにおける送信ブロッキングを防ぐ方法。
２． 媒体アクセス制御−ｄ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ−ｄ、ＭＡＣ−ｄ）フローが停止した場合、スケジュール情報（ｓｃｈｅｄｕｌｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ、ＳＩ）のトリガ送信をさらに備えるようにした、実施例２の方法。
３． トリガ条件を満足する場合、ＳＩを送信することをさらに備えるようにした、任意の先行実施例における方法。
４． トリガ条件を満足する場合、ＳＩを一度送信するようにした、任意の先行実施例における方法。
５． トリガ条件を満足した後、ＳＩを周期的に送信することをさらに備えるようにした、任意の先行実施例における方法。
６． ＳＩを送信する期間を事前に構成するようにした、任意の先行実施例における方法。
７． トリガ条件を満足する毎に、ＳＩを送信するようにした、任意の先行実施例における方法。
８． ＭＡＣ−ｄフローが任意のＭＡＣ−ｄフローを含むようにした、任意の先行実施例における方法。
９． ＭＡＣ−ｄフローが特別に定義するＭＡＣ−ｄフローを含むようにした、任意の先行実施例における方法。
１０． 現行の非ゼロ許可が、前記特定のＭＡＣ−ｄフローの次のＭＡＣサービス・データ・ユニット（ＳＤＵ）または無線リンク制御プロトコル・データ・ユニット(ＲＬＣ ＰＤＵ）の送信に必要な最小値より小さい場合、ＭＡＣ−ｄフローを停止するようにした、任意の先行実施例における方法。
１１． 停止したＭＡＣ−ｄフローの送信に基づき、トリガ条件を検出することをさらに備えるようにした、任意の先行実施例における方法。
１２． エンハンスト個別物理データ・チャネル（ｅｎｈａｎｃｅｄ ｄｅｄｉｃａｔｅｄ ｐｈｙｓｉｃａｌ ｄａｔａ ｃｈａｎｎｅｌ、Ｅ−ＤＰＤＣＨ）上の送信を停止することをさらに備えるようにした、任意の先行実施例における方法。
１３． エンハンスト個別物理制御チャネル（ｅｎｈａｎｃｅｄ ｄｅｄｉｃａｔｅｄ ｐｈｙｓｉｃａｌ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ、Ｅ−ＤＰＣＣＨ）の全てのビットをゼロに設定することをさらに備えるようにした、任意の先行実施例における方法。
１４． 最小許可情報（ＭＧＩ）を設定することをさらに備え、本ＭＧＩが、ＷＴＲＵに許可する最小電力比に関する情報を含むようにした、任意の先行実施例における方法。
１５． ＭＧＩの送信をトリガすることをさらに備えるようにした、任意の先行実施例における方法。
１６． トリガ条件を満足する場合、ＭＧＩを送信することをさらに備えるようにした、任意の先行実施例における方法。
１７． ＭＧＩを符号化することをさらに備えるようにした、任意の先行実施例における方法。
１８． ＭＧＩをＭＡＣ−ｅ ＰＤＵの一部として送信するようにした、任意の先行実施例における方法。
１９． 一列に並んだ次のＲＬＣ ＰＤＵのサイズに基づき、そのバッファにあるデータを持つ最高優先度のＭＡＣ−ｄフローの一つに送信するため、ＭＧＩを設定するようにした、任意の先行実施例における方法。
２０． 前記最高優先度のＭＡＣ−ｄフローの最大バッファのＲＬＣ ＰＤＵのサイズに基づきＭＧＩを設定するようにした、任意の先行実施例における方法。
２１． 特定のＭＡＣ−ｄフローに基づきＭＧＩを設定するようにした、任意の先行実施例における方法。
２２． 無線資源制御装置（ＲＲＣ）信号を通して、ＭＧＩが基づく特定のＭＡＣ−ｄフローを構成するようにした、任意の先行実施例における方法。
２３． 現行の許可および多くの活性化プロセスで、特別な遅延が送信するよう期待する最高優先度のＭＡＣ−ｄフローの最大バッファのＲＬＣ ＰＤＵのサイズに基づき、ＭＧＩを設定するようにした、任意の先行実施例における方法。
２４． ＲＲＣ信号を通して遅延を構成するようにした、任意の先行実施例における方法。
２５． ＭＧＩを、その値が変化する場合、一度だけ送信するようにした、任意の先行実施例における方法。
２６． 特別な数のＭＡＣ−ｄ送信の各々でのＭＧＩを送信するようにした、任意の先行実施例における方法。
２７． 前記ＲＲＣが特別な数を構成するようにした、任意の先行実施例における方法。
２８． 特別な数の送信時間間隔（ＴＴＩ）遅延が二つの連続するＭＧＩ送信を分離するようにした、任意の先行実施例における方法。
２９． 前記ＲＲＣがＴＴＩ遅延を構成するようにした、任意の先行実施例における方法。
３０． 多数のビットと信号伝達の電力比を含むようにした、任意の先行実施例における方法。
３１． ビット数が５であるようにした、任意の先行実施例における方法。
３２． 信号伝達の電力比が、次のＲＬＣ ＰＤＵの送信を許可するだろう最小値であるようにした、任意の先行実施例における方法。
３３． ビット数が可変であるようにした、任意の先行実施例における方法。
３４． ビット数が可能なＲＬＣ ＰＤＵサイズの数に基づくようにした、任意の先行実施例における方法。
３５．０ ＮＢが前記ＭＧＩを受信し、前記ＭＧＩを符号化し、そして前記ＭＧＩに基づき調整するようにした、任意の先行実施例における方法。
３６． スケジュール許可を出すことをさらに備えるようにした、任意の先行実施例における方法。
３７． 新しい各ＭＡＣ−ｅ送信のためのＭＡＣ−ｄフローの最小数のＰＤＵを送信することをさらに備えるようにした、任意の先行実施例における方法。
３８． ＲＲＣ信号を通して、送信する最小数のＰＤＵを構成するようにした、任意の先行実施例における方法。
３９． 最小数のＰＤＵを送信するための要求電力比が現行の許可より大きい場合、前記現行の許可レベル以上に電力比を増加するようにした、任意の先行実施例における方法。
４０． 最小数のＰＤＵを送信するための要求電力比が現行の許可より大きい場合、前記電力比が前記現行の許可レベルに留まるようにした、任意の先行実施例における方法。
４１． ＷＴＲＵが最小エンハンスト・トランスポート・フォーマット組合せ（ｅｎｈａｎｃｅｄ ｔｒａｎｓｐｏｒｔ ｆｏｒｍａｔ ｃｏｍｂｉｎａｔｉｏｎ、Ｅ−ＴＦＣ）を選択し、最小数のＰＤＵをサポートするようにした、任意の先行実施例における方法。
４２． 任意の先行実施例における方法を実行するよう構成したＷＴＲＵ。
４３． 送信器をさらに備えるようにした、実施例４２のＷＴＲＵ。
４４． 受信器をさらに備えるようにした、実施例４２−４３の任意におけるＷＴＲＵ。
４５． 前記受信器および前記送信器と通信状態にあるプロセッサさらに備えるようにした、実施例４２−４４の任意におけるＷＴＲＵ。
４６． ＭＡＣ−ｄフローの送信が停止した場合、ＳＩの送信をトリガするようプロセッサを構成した、実施例４２−４５の任意におけるＷＴＲＵ。
４７． トリガ条件を満足する場合、ＮＢにＳＩを送信するようプロセッサを構成した、実施例４２−４６の任意におけるＷＴＲＵ。
４８． 停止したＭＡＣ−ｄフローの送信に基づいてトリガ条件を検出するようプロセッサを構成した、実施例４２−４７の任意におけるＷＴＲＵ。
４９． エンハンスト個別物理データ・チャネル（ｅｎｈａｎｃｅｄ ｄｅｄｉｃａｔｅｄ ｐｈｙｓｉｃａｌ ｄａｔａ ｃｈａｎｎｅｌ、Ｅ−ＤＰＤＣＨ）に送信を中止するようプロセッサを構成した、実施例４２−４８の任意におけるＷＴＲＵ。
５０． エンハンスト個別物理制御チャネル（ｅｎｈａｎｃｅｄ ｄｅｄｉｃａｔｅｄ ｐｈｙｓｉｃａｌ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ、Ｅ−ＤＰＣＣＨ）の全てのビットをゼロに設定するようプロセッサを構成した、実施例４２−４９の任意におけるＷＴＲＵ。
５１． ＭＧＩを設定するようプロセッサを構成し、本ＭＧＩには、前記ＷＴＲＵに許可する最小電力比に関する情報を含むようにした、実施例４２−５０の任意におけるＷＴＲＵ。
５２． ＭＧＩの送信をトリガするようプロセッサを構成した、実施例４２−５１の任意におけるＷＴＲＵ。
５３． トリガ条件を満足する場合、ＭＧＩを送信するようプロセッサを構成した、実施例４２−５２の任意におけるＷＴＲＵ。
５４． スケジュール許可を受信するようプロセッサを構成した、実施例４２−５３の任意におけるＷＴＲＵ。
５５． 新しい各ＭＡＣ−ｅのための前記ＭＡＣ−ｄフローの最小数のＰＤＵを送信するようプロセッサを構成した、実施例４２−５４の任意におけるＷＴＲＵ。

【図1】

【図2】

【図3】

【図4】