特許第6167166号(P6167166)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 聯發科技股▲ふん▼有限公司の特許一覧

特許6167166移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法
<>
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000002
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000003
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000004
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000005
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000006
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000007
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000008
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000009
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000010
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000011
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000012
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000013
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000014
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000015
  • 特許6167166-移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 図000016
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6167166
(24)【登録日】2017年6月30日
(45)【発行日】2017年7月26日
(54)【発明の名称】移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法
(51)【国際特許分類】
   H04W 72/04 20090101AFI20170713BHJP
【FI】
   H04W72/04 136
   H04W72/04 131
【請求項の数】15
【全頁数】18
(21)【出願番号】特願2015-502074(P2015-502074)
(86)(22)【出願日】2013年3月22日
(65)【公表番号】特表2015-520533(P2015-520533A)
(43)【公表日】2015年7月16日
(86)【国際出願番号】CN2013073052
(87)【国際公開番号】WO2013139299
(87)【国際公開日】20130926
【審査請求日】2014年9月24日
(31)【優先権主張番号】61/615,041
(32)【優先日】2012年3月23日
(33)【優先権主張国】US
(31)【優先権主張番号】13/848,942
(32)【優先日】2013年3月22日
(33)【優先権主張国】US
【前置審査】
(73)【特許権者】
【識別番号】506423280
【氏名又は名称】聯發科技股▲ふん▼有限公司
【氏名又は名称原語表記】MEDIATEK INC.
(74)【代理人】
【識別番号】110001494
【氏名又は名称】前田・鈴木国際特許業務法人
(72)【発明者】
【氏名】チョウ,チー−ミン
(72)【発明者】
【氏名】シュー,チア−チュン
(72)【発明者】
【氏名】ヨハンソン,ペール ヨハン ミーケル
【審査官】 東 昌秋
(56)【参考文献】
【文献】 国際公開第2011/038636(WO,A1)
【文献】 国際公開第2011/025426(WO,A1)
【文献】 China Unicom,Consideration on Improvement of SR Resource Utilization,3GPP TSG-RAN WG2 Meeting #77bis, R2-121432,2012年 3月19日,pp. 1-2,URL,http://www.3gpp.org/ftp/tsg_ran/wg2_rl2/TSGR2_77bis/Docs/R2-121432.zip
【文献】 ZTE,Considerations on PUCCH enhancements,3GPP TSG-RAN WG2 Meeting #77bis, R2-121256,2012年 3月20日,URL,http://www.3gpp.org/ftp/tsg_ran/wg2_rl2/TSGR2_77bis/Docs/R2-121256.zip
【文献】 Renesas Mobile Europe,PUCCH Improvements for Diverse Data Applications,3GPP TSG-RAN WG2 Meeting #77bis, R2-121484,2012年 3月19日,URL,http://www.3gpp.org/ftp/tsg_ran/wg2_rl2/TSGR2_77bis/Docs/R2-121484.zip
【文献】 Nokia Siemens Networks,UE assisted information for eDDA,3GPP TSG-RAN WG2 Meeting #77bis, R2-121201,2012年 3月20日,URL,http://www.3gpp.org/ftp/tsg_ran/wg2_rl2/TSGR2_77bis/Docs/R2-121201.zip
(58)【調査した分野】(Int.Cl.,DB名)
H04W 4/00−99/00
H04B 7/24− 7/26
3GPP TSG RAN WG1−4
SA WG1−2
CT WG1
(57)【特許請求の範囲】
【請求項1】
移動通信ネットワークでユーザー端末(UE)と基地局によって 無線リソース制御(RRC)接続を確立するステップ、
スケジューリングリクエスト(SR)リソースの割り当てに関連する補助情報であって、UEに望ましいSR周期とUEに望ましいSRオフセットに関連したUEに望ましいSR−CONFIGインデックスを含む補助情報を、基地局に提供するステップ、および
前記補助情報に応じて前記基地局から、SRリソース割り当て用のSR周期とSRオフセットと関連するスケジューリングリクエスト(SR)設定を受信するステップを含み、
前記SR周期は、第1のSR周期と第2のSR周期とを含み、前記第1のSR周期は前記基地局にSRを送信するために用いられる方法。
【請求項2】
前記補助情報は、パケット到着間隔(IAT)に関連したトラフィックパターン情報を含む請求項1に記載の方法。
【請求項3】
前記基地局から初期のSR設定を受信するステップ、および
SRの使用を評価し、前記補助情報を前記基地局に送信するかどうかを決定するステップを更に含む請求項1に記載の方法。
【請求項4】
前記基地局に指示を送信し、割り当てられたSRリソースを解除するステップを更に含む請求項1に記載の方法。
【請求項5】
前記指示は、SR−CONFIGインデックスの特定値を含む請求項4に記載の方法。
【請求項6】
前記指示は、パケット到着間隔の特定値を含む請求項4に記載の方法。
【請求項7】
スケジューリングリクエスト(SR)リソースの割り当てに関連する、基地局に提供された補助情報であって、UEに望ましいSR周期とUEに望ましいSRオフセットに関連したUEに望ましいSR−CONFIGインデックスを含む補助情報に応じてユーザー端末(UE)によって前記基地局から、SR用のセットの無線リソースを割り当て、前記割り当てられたSR無線リソースは、第1のSR周期と第2のSR周期と関連付けられるスケジューリングリクエスト(SR)設定を受信するステップ、
前記第1のSR周期を用い、前記基地局にSRを送信するステップ、および
第1の所定のトリガー条件が満たされた後、前記第2のSR周期を用いるステップを含む方法。
【請求項8】
第2の所定のトリガー条件が満たされた後、切り戻され、第1のSR周期をSRの伝送に用いるステップを更に含む請求項7に記載の方法。
【請求項9】
前記第1または第2のトリガー条件は、前記SR設定によって設定されたSRタイマーに基づき、SR設定によって設定されたSRタイマーに基づく請求項8に記載の方法。
【請求項10】
前記第1または第2のトリガー条件は、特定のアプリケーション用のアップリンクデータが前記基地局に送信された時、満たされる請求項8に記載の方法。
【請求項11】
前記特定のアプリケーションは、パワープレファレンス指示を前記基地局に送信することによって示される請求項10に記載の方法。
【請求項12】
前記第1または前記第2のトリガー条件は、不連続受信(DRX)の動作状態に基づく請求項8に記載の方法。
【請求項13】
前記第2のSR周期は、前記第1のSR周期より長く、前記UEが前記第1のSR周期を用いる時、より多くのSRリソースが割り当てられる請求項7に記載の方法。
【請求項14】
前記UEが前記第2のSR周期を用いた時、前記未使用のSRリソースは、他のUEに用いるように、物理アップリンク制御チャネル(PUCCH)用にリサイクルされる請求項13に記載の方法。
【請求項15】
前記UEが前記第2のSR周期を用いた時、前記未使用のSRリソースは、データ伝送に用いるように物理アップリンク共有チャネル(PUSCH)にリサイクルされる請求項13に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、移動通信ネットワークに関し、特に、サービス品質(QoS)リクエストを維持しながらスケジューリングリクエストリソースを割り当て、スケジューリングリクエストの使用率を増加させることに関するものである。
【背景技術】
【0002】
ロングタームエボリューション(LTE)システムは、高ピークデータレート、低遅延、改善されたシステム容量が多くのオペレータによって用いられる。LTEシステムにおいて、発展型ユニバーサル地上波無線アクセスネットワーク(E−UTRAN:Evoled Universal Terrestrial Radio Access Network)は、LTE−Uuインターフェースを介して、複数の移動局と通信する、ユーザー端末(UE:User Equipments)と呼ばれる複数の発展型ノードB(eNBs:evolved Node−Bs)を含む。無線アクセスネットワークは、移動管理エンティティ(MME)、サービングゲートウェイ(S−GW)、およびパケットデータネットワークゲートウェイ(P−GW)を含むコアネットワーク(CN)と更に接続し、エンドツーエンドのサービスを提供する。LTEネットワークはシステム容量を増加させており、すぐに容量の問題に直面することが予測される。携帯電話加入者の指数関数的な増加は、ネットワーク容量の大幅な増加を必要とする。ユーザー数が急増するこの問題と同時に、例えばiPhone、Androidフォン、およびBlackberryフォンユーザーなどのスマートフォンの加入者の急激な機種の上位化もある。
【0003】
例えば、ニュース、天気、およびソーシャルネットワーキングなどの多くのスマートフォンのアプリケーションは、更新用に定期的にネットワークと接続、またはネットワークから切断する。これらのアプリケーションは、大量のシグナリングトラフィックをなお必要とすると同時に、少量のユーザーデータを含んで、セッションの確立と解除をする。結果、コアネットワークは、UEをスマートフォンのアプリケーションに接続した状態にする。多様なデータアプリケーション(DDA)(バックグラウンド/IM)環境において、UEを無線リソース制御(RRC)接続モードに保持することになり、RRC遷移を防止する。より小さいRRC遷移は、不連続受信(DRX)が適切に設定されている場合、同様の省電力性能を有する。
【0004】
しかしながら、物理アップリンク制御チャネル(PUCCH)のための無線リソース使用率は、接続されたUEの数が増加した時、特にスケジューリングリクエスト(SR)リソースがPUCCHに割り当てられた時、問題になる。これは、SRリソースが専用のリソースであり、且つ周期的であるため、SRリソースの浪費は、接続されたUEの数の増加に伴い、線形的に増加する。例えば、10MHz(50個の物理リソースブロック(PRB))の帯域幅で、300のUEが全て接続されている場合、PUCCHの割り当ては、SR周期が5msの時、8個のPRBを必要とする。8個のPRBの中、SRの使用率(使用されているリソース)は、バックグランドトラフィックにおいて0.04%だけである。SR周期が5msから80msに延伸された時でも、SRリソースの使用率は、0.67%だけである。また、より長いSR周期を用いて直接使用率を増加させる時、割り当ては、アクセス遅延を大きく増加させる。より多くのリソースがSRに確保されている場合、より少ないリソースが物理アップリンク制御チャネル(PUCCH)を介してアップリンクデータ伝送に使用可能となり、アップリンク容量を減少する。そのため、トラフィックがより多様になった時、従来の単一のSRリソース割り当ての方式は、ネットワークおよびUEリクエストを十分に、または効果的に満たすことができない可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【0005】
本発明の目的は、SRリソースの使用率を増加し、且つQoSを得ることであり、その解決法が求められている。
【課題を解決するための手段】
【0006】
PUCCHのスケジューリングリクエスト(SR)リソースは、UEがアップリンクデータ用にSR指示を送信するように基地局によって割り当てられる。SRリソースは、専用であり周期的である。各種の方式が本発明に提供され、SRリソースの割り当てをトラフィックパターンに適応させることによってSRリソースの使用率を向上させる。
【0007】
第1の方式では、SRリソースの割り当ては、UEによって提供された補助情報に基づいてより正確に設定される。UEは、eNBに補助情報を提供し、受信した補助情報に基づいてSR設定を決定または調整する。SR設定は、SR周期とSRオフセットに関連付けされたSR設定インデックスを含む。1つの例では、補助情報は、UEに望ましい(UE−preferred)SR設定インデックスを含む。もう1つの例では、補助情報は、UEに望ましいSR周期/オフセット、および/またはパケット到着間隔(IAT)に関連したトラフィックパターン情報を含む。UEは、QoSリクエスト、トラフィックパターン統計、およびDRX設定などの考慮に基づき、補助情報を提供するため、eNBは、より正確にSRリソースを割り当てることができる。UEは、更にリクエストメッセージを送信し、SR割り当てを解除する。
【0008】
第2の方式では、複数のSR周期が設定され、トラフィックパターンに適応される。基地局は、複数のSR周期を用いてセットのSRリソースを設定し、UEは、所定のトリガーイベントに基づいて異なるSR周期を用いる。1つの例では、トリガーイベントは、SR設定によって設定されたSRタイマーに基づく。もう1つの実施形態では、トリガー条件は、特定のアプリケーション用のアップリンクデータが基地局に送信された時、満たされる。トリガー条件は、不連続受信(DRX)の動作状態に基づくこともできる。1つの有利な実施形態では、PUCCHの未使用のSRリソースは、他のUE用に、または物理アップリンク共有チャネル(PUSCH)のデータ伝送用にリサイクルされることができる。異なるSR周期のSRリソースを設定することによって、SRリソースの使用率は、トラフィックパターンに適応される。
【0009】
第3の方式では、複数のSR割り当てが設定され、関連したアプリケーションに適用される。基地局は、所定のアプリケーションに適応された複数のセットのSRリソースを設定し、UEは、対応するアプリケーションに基づいてSR設定を用いる。複数の予め割り当てられたSRリソースが決定され、アプリケーションのサービス品質(QoS)リクエストを満たす。1つの実施形態では、割り当てられたSR無線リソースは、アプリケーションの開始および/または停止に基づき、アクティブ化または非アクティブ化される。複数の予め割り当てられたSR設定でSRリソースの使用は、関連するアプリケーションに適応される。
【0010】
他の実施形態及び利点が以下に詳細に説明される。この概要は、本発明を限定するものではない。本発明は請求項によって限定される。
【図面の簡単な説明】
【0011】
図1図1は、1つの新しい実施形態に基づく無線通信システムのSRリソースの使用率を向上させるいくつかの方式を示す図である。
図2図2は、本発明の特定の実施形態をサポートするUEおよびeNBの簡略化したブロック図である。
図3図3は、SR周期およびSRオフセットと関連したSR設定インデックスを示す図である。
図4図4は、望ましいSR設定インデックスをUEからeNBに提供する第1の実施形態を示す図である。
図5図5は、トラフィックパターンとSRリソース割り当てと関連した関連パラメータを示す図である。
図6図6は、SRリソース割り当て用のUEからeNBに補助情報を提供する第2の実施形態を示す図である。
図7図7は、2つの異なるSR周期を有するSR設定を示す図である。
図8図8は、適応性のSR設定の方法を示す図である。
図9図9は、SRリソースのリサイクルを有する適応性のSR設定の方法を示す図である。
図10図10は、PUSCHのデータ伝送に用いられることができる仮想のPUCCHを示す図である。
図11図11は、異なるアプリケーションに対応する異なるSR設定を示す図である。
図12図12は、所定のアプリケーションの複数のSR設定を設定する方法を示す図である。
図13図13は、1つの新しい実施形態に基づくSRリソース割り当て用の補助情報を提供する方法のフローチャートである。
図14図14は、1つの新しい実施形態に基づくSR設定の適応およびSRリソースのリサイクルを用いる方法のフローチャートである。
図15図15は、1つの新しい実施形態に基づく所定のアプリケーションの複数のSR設定を設定する方法のフローチャートである。
【発明を実施するための形態】
【0012】
以下、本発明の様々な実施形態を詳細に説明する。その実施形態は添付図面に例証されている。
【0013】
図1は、1つの新しい実施形態に基づく無線通信システム100のスケジューリングリクエスト(SR)リソースの使用率を向上させるいくつかの方式を示している。無線通信システム100は、ユーザー端末UE101と基地局eNB102を含む。LTEシステムでは、物理アップリンク共有チャネル(PUSCH)は、UE101からeNB102にアップリンクデータを搬送するように用いられ、物理アップリンク制御チャネル(PUCCH)は、ダウンリンク伝送、スケジューリングリクエスト(SR)、およびチャネル品質表示(CQI)報告に応じて、自動再送リクエスト(ARQ)またはハイブリッド再送リクエスト(HARQ)などの各種のアップリンク制御情報を搬送するように用いられる。UE101がeNB102に送信されるアップリンクデータを有する時、UE101は、PUCCHの割り当てられたSRリソースによってSR指示をeNB102に送信し、それに応じてeNB102からアップリンクグラントを受信し、アップリンクデータがPUSCHによってUE101からeNB102に伝送されることができる。
【0014】
多様なデータアプリケーション(DDA)(バックグラウンド/IM)環境において、UEを無線リソース制御(RRC)接続モードに保持することになり、RRC遷移を防止する。より小さいRRC遷移は、不連続受信(DRX)が適切に設定されている場合、同様の省電力性能を有する。しかしながら、PUCCHに割り当てられたSRリソースは、RRC接続モードの各UE専用であり、周期的である。そのため、SRリソースの浪費は、RRC接続モードの複数のUEの数の増加に伴い、線形的に増加する。ほとんどのUEがRRC接続モードで保持された時、長いSR周期設定(例えば、SR周期=80ms)を用いても、SRリソースの使用率は、なお非常に低い(例えば、0.67%)。また、長いSR周期は、アクセス遅延を大きく増加させる。
【0015】
1つの新しい実施形態では、各種の方式は、SRリソース割り当てをトラフィックパターンに適応させることによって、SRリソースの使用率を向上させる。図1に示されるように、第1の方式#1では、SRリソース割り当てはより正確に設定される。例えば、UE101は、補助情報を提供し、eNB102は、受信した補助情報に基づいてSR設定を決定または調整する。第2の方式#2では、SR周期は、トラフィックパターンに適応される。例えば、eNB102は、複数のSR周期を用いて1セットのSRリソースを設定し、UE101は、所定のイベントに基づいて異なるSR周期を用いる。未使用のSRリソースは、PUSCHのデータ伝送用にeNB102によってリサイクルされることができる。第3の方式#3では、複数のSR割り当ては、関連したアプリケーションに適用される。例えば、eNB102は、所定のアプリケーションに適応された複数のセットのSRリソースを設定し、UE101は、対応するアプリケーションに基づいてSR設定を用いる。追加のSR設定は、対応するアプリケーションの開始および/または停止に基づいてアクティブ化および/または非アクティブ化されることができる。
【0016】
図2は、本発明の特定の実施形態をサポートするUE201およびeNB202の簡略化したブロック図である。アンテナ225は、RF信号を送受信する。RFトランシーバモジュール211は、アンテナ225と接続され、アンテナからRF信号を受信し、受信したRF信号をベースバンド信号に変換し、それらをプロセッサ212に送信する。RFトランシーバ211は、プロセッサ212から、受信したベースバンド信号を変換し、変換した信号をRF信号に変換してアンテナ225に送出する。プロセッサ212は、受信したベースバンド信号を処理し、異なる機能モジュールを呼び出し、UE201の機能を実行する。メモリ213は、プログラム命令とデータ214を保存し、UE201の動作を制御する。
【0017】
同様の設定がeNB202に存在し、アンテナ245は、RF信号を送受信する。RFトランシーバモジュール231は、アンテナ245と接続され、アンテナからRF信号を受信し、受信したRF信号をベースバンド信号に変換し、それらをプロセッサ232に送信する。RFトランシーバ231は、プロセッサ232から、受信したベースバンド信号も変換し、変換した信号をRF信号に変換してアンテナ245に送出する。プロセッサ232は、受信したベースバンド信号を処理し、異なる機能モジュールを呼び出し、eNB202の機能を実行する。メモリ233は、プログラム命令とデータ234を保存し、eNB202の動作を制御する。
【0018】
図2は、本発明の実施形態を実行するUE201およびeNB202の機能モジュールも示している。例えば、RRC管理モジュール221と241は、RRC状態を管理し、RRC接続のステップを実行し、且つRRCシグナリング用にRRC接続を保持する。状態収集モジュール222は、異なるアプリケーションと関連する各種のトラフィックパターンのトラフィック統計を収集する。SR適応モジュール223は、eNB202からSR設定を受け(SR設定モジュール243によって)、必要な場合、SR設定に適応させる。アプリケーションモジュール224は、UE201で動作する各種のアプリケーションを管理する。異なる機能モジュールは、ソフトウェア、ファームウェア、ハードウェア、またはその組み合わせによって実行されることができる。例えば、機能モジュールがプロセッサ212と232によって実行された時(例えばプログラムコード214と234を実行することによって)、UE201に収集させ、補助情報となるトラフィック統計をeNB202に提供し、受信した補助情報に基づき、QoSリクエスト(QoS管理モジュール242によって)にも基づいて、UE201にSRリソース割り当てを設定させ、且つそれに応じてUE201にSR設定を用いて適応させ、QoSを保持しながらSRリソースの使用率を向上させる。
【0019】
図3は、SR周期およびSRオフセットと関連したSR設定インデックスを示している。LTEシステムでは、情報要素(IE)SchedulingRequestConfigは、SRの周期性およびSRサブフレームオフセットを含むSRパラメータを特定するように用いられ、対応するSR設定インデックスと関連する。図3の表300に示されるように、SRの伝送周期性SRPERIODICITYとSRのサブフレームオフセットNOFFSET用のSR設定は、上層より与えられたパラメータsr−ConfigIndex およびISRによって表300に定められる。SR設定インデックスは、0〜157であり、各インデックスは、SRの周期性(例えば、1ms〜80msのSRPERIODICITY)とSRのサブフレームオフセット(例えば、ISRが上層より与えられるNOFFSET)に対応する。SR伝送の例は、式:(10xNf + [Ns/2]) mod SRPERIODICITY = 0、を満たすアップリンクサブフレームであり、その中のNfは、システムフレーム番号であり、Nsは、スロット番号である。
【0020】
伝統的に、eNBは、QoSリクエストに基づいてSR設定を割り当てるが、コアネットワークから受信したQoSリクエストは、eNBがSRリソース割り当てのための最良の解決を決定するのに十分でない可能性がある。例えば、UEは、eNBが長いパケット到着間隔(inter−arrival−time;IAT)を有するトラフィック用に短いSR周期を割り当てるのを避けることができ、UEは、eNBがSRオフセットと第2の層(L2)のバッファに入るアップリンクデータのタイミングをより正確に位置合わせするのを助ける。1つの新しい実施形態では、トラフィックパターンとUE知能(intelligence)に応じて、UEは、その望ましいsr−ConfigIndexをeNBに、特にSRオフセットにフィードバックすることができる。
【0021】
図4は、望ましいSR設定インデックスをUEからeNBに提供する第1の実施形態を示している。ステップ411では、UE401は、eNB402から第1のSR設定#1を受信する。第1のSR設定は、SR周期とSRオフセットと関連した第1のsr−ConfigIndexを含む。しかしながら、このようなSR設定は、UE401に望まれない可能性がある。例えば、UE401は、SRの使用を評価し、低い使用率(poor utilization)を見つける。このため、UE401は、フィードバックを初期化することができる。UE401は、基準のリストに応じてSRの適当な周期性とオフセットを決定する。第1に、UE401は、実行アプリケーションのQoSリクエストを考慮することができる。第2に、UE401は、トラフィックパターンの履歴(history)を考慮し、L2バッファに入るユーザーデータのタイミングを予測する。第3にUE401は、そのDRX設定を考慮することができる。例えば、SRリソースは、DRX動作の期間に、またはDRX動作の期間のわずか前に割り当てられることができる。DRX設定は、UEアクティブ期間(Active Time)を減少する利点を有するため、UEの電力消費を節約するが、より長い遅延も発生させる。そのため、SRの周期性をDRXサイクルと位置合わせすることが望ましい。例えば、SR周期の値の範囲は、1、2、5、10、20、40、および80であり、短DRXサイクルの値の範囲は、2、5、8、10、16、20、32、40、64、80、128、160、256、320、512、および640である。SR設定がDRX cycle = n SR periodを満たすならば望ましい。このような決定がされた後、ステップ412では、UE401は、その望ましいsr−ConfigIndexをeNB402に送信する。望ましいsr−ConfigIndexは、RRCシグナリングメッセージによって(例えばボックス421に表される)、またはメディアアクセス制御(MAC)の制御要素(CE)(例えば、ボックス422に表される)によって送信されることができる。UEの望ましいsr−ConfigIndexを受信した後、eNB402は、現在のPUCCHの負荷と使用可能なリソースを考慮することができ、SR設定を調整するかどうか決定する。調整する場合、ステップ413では、eNB402は、第2のSR設定#2をUE401に送信し、SR設定を調整する。または、eNB402は、明示的に拒絶メッセージを無視するか、または送信することによって、提案を拒絶することができる。
【0022】
望ましいSR設定インデックスの送信に加え、UEは他の補助情報をeNBに報告し、SRリソースの設定の正確さを向上させる。異なるタイプの補助情報がある。一般的に、ULのパケット到着間隔(IAT)の情報は、非常に有用である。このような情報は、2つの隣接のパケット間の時差であるパケット到着間隔の累積分布関数(CDF)曲線または確率密度関数(PDF)図によって表示されることができる。例えば、一系列の点(a sequence of points)(確率vs到着間隔)、または一系列のスロープ(a sequence of slope)によるCDF曲線、およびL2のバッファに入るユーザーデータのIAT用のCDFが用いられることができる。
【0023】
図5は、トラフィックパターンとSRリソース割り当てと関連した関連パラメータを示している。図5の例では、矢印線501は、ULパケット用のIAT値を示し、破線矢印線502は、ユーザーデータがL2バッファに入った後の次のSRの機会までの各種の待ち時間を示している。注意するのは、時にUplink Shapingがスケジューリングリクエストのウェイクアップを減少するように用いられることができることである。その考えは、UEが複数のアップリンクパケットを集約して1つのスケジューリングリクエストを作り出すことである。例えば、図5では、UEは、3つの連続的なバケットを集約し、1つのSRを作り出す。このケースにおいて、SR周期とオフセット上で統計を行っている時、UEは、それらを一つにまとめ、最新のパケットを用いてオフセット(例えば、報告3のオフセット)とSR周期(例えば、報告3のIAT)を計算する。平均のIAT値がSRの周期性を決定するのに非常に役立つことがみられ、平均のIAT値がSRの周期性を決定するのに非常に役立つことがみられる。
【0024】
図6は、SRリソース割り当て用のUEからeNBに補助情報を提供する第2の実施形態を示している。ステップ611では、UE601は、補助情報をeNB602に送信する。補助情報は、ボックス621によって表されるRRCシグナリングによって送信されることができる。例えば、補助情報は、3つのタイプに報告されることができる。第1の報告のタイプでは、一系列のペアが報告され、各ペアは、IAT値と確率からなる。第2の報告のタイプでは、両平均のIATと平均の待ち時間が報告される。第3の報告のタイプでは、推奨されるSR周期(平均のIATに基づき)と推奨されるSRオフセット(平均の待ち時間に基づき)が報告される。注意するのは、推奨されるSR周期は、平均のIATと異なってもよいことである。例えば、UE601は、所定の基準に応じて、緊急でないULパケットを遅延させ、SR指示だけを送信することによって、ULトラフィックシェーピングを行うことができる。また、推奨されるSRオフセットは、ユーザーデータがL2バッファに入る平均の待ち時間でない可能性がある。その代り、ULトラフィックシェーピングが用いられた後の結果であることができる。
【0025】
特定のトラフィックでは、ランダムアクセスSR(RA−SR)によるULアクセスは、専用SR(D−SR)によるULアクセスより、より効果的(遅延とリソース利用に関して)であることができる。しかしながら、現在のLTE仕様は、D−SRが設定された場合、UEがRA−SRを実行するのを防ぐ。このため、D−SRリソースを解除するメカニズムは、このような必要性がある時に望ましい。指示をUEによって提供された補助情報内に挿入することで、前記指示はeNBにUEがSRリソースを解除したいことを知らせることができる。図4に関する第1の実施形態では、UE401は、望ましいsr−ConfigIndexで特定値(例えば、sr−ConfigIndexに使用されていない158)を示し、eNB402は、特定値を1つの指示として解釈し、SRリソースの解除をリクエストする。図6に関する第2の実施形態では、UE601は、平均または推奨されるIAT値用の特定値(例えば、0)を示し、eNB602は、特定値を1つの指示として解釈し、SRリソースの解除をリクエストする。
【0026】
現存するSR設定と補助情報は、ハンドオーバー(HO)動作およびRRC接続の再確立に役立つ可能性がある。HOの間、ソースeNBは、関連するSR設定または補助情報をターゲットeNBにパスすることができ、ターゲットeNBは、SR設定用に関連するSR設定または補助情報を用いることができる。UEがRRCアイドルモードに解除されると、eNBは、SR設定または補助情報を移動管理エンティティ(MME)または隣接セルに送信することができる。後にUEがRRC接続の再確立リクエストをセルに送信した時、セルは既にその情報を有するか、またはMMFから情報を得ることができる。
【0027】
上述の方法では(例えば図1の方式#1)、eNBは、UEのフィードバックに基づき、SRリソースをより正確に割り当てることができる。しかしながら、トラフィックパターンは変わるため、動的にSR設定を適応させるメカニズムが必要である。現在のLTE仕様では、RRCの再設定以外に、SR用に適応するメカニズムはない。タイムアラインメントタイマー(TAT)の終了時にだけ、UEは、SR用にPUCCHリソースを解除する。一般的に、TATは、セルサイズまたはUEの速度に基づいて設定される。TATが長い場合、UEはULの同期に留まり、割り当てられたPUCCHリソースを保持する。UEは、補助情報をeNBに送信し続け、SRの使用率を向上させることができる。しかしながら、このようなメカニズムは、更新頻度に伴ってシグナリングオーバーヘッドを増加させる。頻繁なRRCの再設定と補助情報は、余分なシグナリングオーバーヘッドを要する。UE側の自律的適応は、シグナリングオーバーヘッドの問題を回避することができる。
【0028】
1つの新しい実施形態では(例えば図1の方式#2)、SR周期は、シグナリングオーバーヘッドを増加させることなく、自律的にトラフィックパターンに適応される。バックグラウンドトラフィックと正常なトラフィックは、異なる到着間隔を有することができるため、適応性のSR周期を有するSR割り当ての方式は、SRが実行アプリケーションのトラフィックに適応される場合、SRの効率を向上させる。一般的に、eNBは、複数のSR周期を有するセットのSRリソースを設定することができ、1つのSR周期は、他のより長い。1つの代替例では、UEは、設定の中の1つを用い、次いで所定のイベントに応じて2つの設定の間を切り替える。もう1つの代替例では、UEは、設定の両方を用いて、所定のイベントに基づき、設定をオン/オフにする。全ての場合において、eNBとUEは、同期していなければならない。例えば、eNBは、PUCCHリソースがUEによって用いられるかどうか知らなければならない。
【0029】
図7は、適応用の2つの異なるSR周期を有するSR設定を示している。図7の例では、基地局はUE用にPUCCHにセットの物理無線リソースを割り当てるSR設定を送信する(時間T0で)。SR設定は、2つのSR周期(周期#1と周期#2)を設定する。SR設定は、2つの設定されたSR周期の間を切り替えるように用いられるSRタイマーも含む。第1のSRリソースは、時間T1に発生し、周期#1の第1の設定されたSR周期に応じて周期的に発生する。UEが送信されるアップリンクデータがない場合、SRタイマーは時間T2で終了する。SRタイマーの終了後、eNBは、第2の設定されたSR周期に切り替える。これは、後に続くSRリソースがその後、周期#2のSR周期で周期的に出現することを意味する。時間T3では、ULデータはL2バッファに入り、UEは、時間T4でSRの指示をeNBに送信する。このようなイベントの後、eNBは、周期#1を有する第1の設定されたSR周期などに切り戻す。
【0030】
図8は、適応性のSR設定の方法を示している。ステップ811では、UE801は、SR設定をeNB802から受信する。SR設定は、ボックス821によって表されるRRCシグナリングによって送信されることができる。例えば、SR設定は、sr−PUCCH−ResourceIndexに基づき、PUCCHにセットの物理無線リソースを割り当てる。SR設定は、SR周期とSRオフセットにそれぞれ関連付けされた2つのsr−ConfigIndexも含む。また、SR設定は、SR−Timerを含む。SR−Timerは、SR設定がどのぐらいの有効かを示すように用いられ、SR伝送と同時に再開される。第1のSR設定が無効になった時、第2のSR設定が代わりに有効になる。もう1つの例では、2つのSR周期の間のスイッチングは、特定のアプリケーションのULデータがeNBによって受信された後、発生する。特定のアプリケーションは、パワープレファレンス指示(power preference indication; PPI)を基地局に送信することによって示されることができる。2つの異なるSR周期とSR−Timerを設定することで、適応性のSR設定が得られ、eNB802とUE801の間で切り替えられる余分なシグナリングのない、異なるトラフィックタイプに適応する。
【0031】
タイマーまたはデータ着信を異なるSR設定の間を切り替えるトリガーとして用いる他に、DRX遷移状態が用いられることもできる。第1の例では、アクティブ状態とDRX状態間の遷移は、SR設定間の切り替えに用いられることができる。アクティブ時間中(インアクティビティタイマーまたはオンデュレーション(onDuration)タイマーのいずれかが動作している)、第1のセットのSR設定が用いられる。UEがDRXに入ると、第2のセットのSR設定が用いられる。第2の例では、短いDRXサイクルと長いSRXサイクル間の遷移は、SR設定間の切り替えに用いられることができる。短いDRXサイクルが用いられる時、第1のセットのSR設定が用いられる。長いDRXサイクルが用いられる時、第2のセットのSR設定が用いられる。両実施例では、DRX状態の遷移は、シグナリングオーバーヘッドを発生させることなく、SR設定をトラフィックパターンに自動的に用いることを実現することができる。注意するのは、タイマーまたはデータ着信、またはSR適応用のDRX遷移を用いることは非対称的であることができることである。例えば、長いSR周期が短いSR周期に切り替わるのは、タイマー制御に頼ることができるが、短いSR周期が長いSR周期に切り替わるのは、DRXサイクルの変更に頼ることができる。
【0032】
1つの実施形態では、複数のSR設定は、UEによって提案されることができる。例えば、UEが補助情報を報告する時、UEは、少なくとも2つの望ましいSR設定を提案し、eNBが適応用の複数のSR設定を決定するのを助ける。
【0033】
図9は、SRリソースのリサイクルを有する適応性のSR設定の方法を示している。ステップ911では、UE901は、eNB902からスケジューリングリクエスト設定を受信する。SR設定は、2つの異なる設定されたSR周期でSR伝送用にセットのリソースを割り当てる。ステップ912では、UE901は、第1のSR周期を用いてSR指示を送信する。ステップ913では、トリガーイベントはUE901によって検出される。トリガー条件は、常に同期されるようにUE901とeNB901との間に予め定義される(例えばSRタイマー)。ステップ914では、UE901は、第2のSR周期を用い初めてSR指示を送信する。第2のSR周期が第1のSR周期より長い場合、割り当てられたSRリソースは、完全に用いられない。リソースの使用率を向上させるために、ステップ915では、eNB902は、未使用のSRリソースをリサイクルする。UE901専用の未使用のSRリソースは、PUCCHリソースとして他のUEに再割り当てされることができるか、またはPUCCHリソースとしてデータ伝送用にUEに再割り当てされることができる。
【0034】
図10は、PUSCHのデータ伝送に用いられ得る仮想のPUCCHを示している。適応性のSR設定中、PUCCHの未使用のSRリソースは、PUSCH用にリサイクルされることができる。一般的に、eNBは、UEからの指示に基づき、RRCシグナリングでPUCCH設定を更新することができる。しかしながら、これは、仮にトラフィックパターンが大きく変化し、周波数の更新がリクエストされた場合、余分なシグナリングオーバーヘッドを発生し、eNBからUEにRRC再設定とSR設定を送信する可能性がある。オーバーヘッドを制限するために、仮想のPUCCHの概念が用いられ、既に割り当てられたPUCCHリソースをリサイクルする。仮想のPUCCHとは、割り当てられたPUCCHリソースのサブセットがeNBに指示された時、無効になることを意味する。前記指示は、黙示的または明示的であることができる。図10に示されるように、DDA UE用のPUCCHは、PUSCH領域に近い領域に割り当てられる。例えば、PUCCH領域1001とPUCCH領域1002は、SR伝送用にDDA UEに割り当てられる。1つの例では、SRの周期性がeNBからの指示の後、N倍変わった時、割り当てられたPUCCHの領域は、PUSCH用にリサイクルされる。Nは、所定の番号であることができ、前記指示は、黙示的または明示的であることができる。
【0035】
異なるアプリケーションは、異なるQoSリクエストを有することができ(例えば、遅延、ジッター(jitter)、低下率(dropping rate))、従来の単一のSR設定は、アプリケーションのサブセットの必要に応えることができるだけか、または効率/利用の問題を有するだけである。従って、複数のSR設定が異なるアプリケーションに対して割り当てられることができる場合、PUCCHパフォーマンスまたは効率は向上されることができるUEが複数のSRリソースを有することができる場合、SRの使用は関連するアプリケーションに応用されることができる。全てのアプリケーションからトラフィック用に一般のSRを用いる代わりに、個別のSRが、単一のアプリケーションまたはサブセットのアプリケーションによって用いられることができる。追加のSR設定は、アクティブ化または非アクティブ化されることができる。
【0036】
図11は、異なるアプリケーションに対応する異なるSR設定を示している。時間T1では、アプリケーション1は、動作を開始する。時間T2では、eNBは、第1のSR設定を設定し、UEは、SR指示用にPUCCHのリソースSR1に割り当てられる。時間T3では、アプリケーション2は、動作を開始する。時間T4では、eNBは、第2のSR設定を設定し、UEは、SR指示用にPUCCHのリソースSR2に割り当てられる。注意するのは、両SR1とSR2リソースは、同じ送信時間間隔(TTI)でUEに割り当てられる。このTTIでは、PUCCH上のUEの送信電力を考慮し、UEは、SRの1つを選び、リクエストを作り出し、更に後のシグナリングで情報(アプリケーションと対応のサイズ)を報告することができる。時間T5では、アプリケーション1は動作を停止する。時間T6では、eNBは、第1の割り当てられたSRリソースを解除し、よって、SR2だけがUEに設定される。
【0037】
図12は、所定のアプリケーションの複数のSR設定を設定する方法を示している。ステップ1211では、UE1201は、eNB1202から第1のセットのSRリソースを割り当てる第1のSR設定#1を受信する。ステップ1212では、UE1201は、eNB1202から第2のセットのSRリソースを割り当てる第2のSR設定#2を受信する。ステップ1213では、eNB1202は、セットの所定のイベントをUE1201に伝え、所定のイベントは、予め割り当てられたSRリソースと関連し、SRリソースの使用が所定のイベントによって制御されることができる。例えば、各所定のSRリソースは、アプリケーションのQoSリクエストに基づき、1つ以上のセットの所定のアプリケーションと関連することができる。ステップ1214では、UE1201は、アプリケーション#1の動作を開始し、第1のセットのSRリソースを用いて関連のQoSリクエストに応える。ステップ1215では、UE1201は、アプリケーション#2の動作を開始し、第2のセットのSRリソースを用いる。ステップ1216では、アプリケーション#1は動作を停止し、UE1201は、第1のセットの使用を停止する。ステップ1217では、eNB1202は、他の使用に用いるために、未使用の第1のセットのSRリソースをリサイクルする。
【0038】
セットのリソースの使用の開始と停止は、トラフィックまたは予め定義されることによって自動的に制御されることができる(オン/オフのアプリケーショの、および個別のアプリケーションを識別することによってUE/eNBがSRの使用を同期させる)。1つの例では、アプリケーションの開始/停止は、パワープレファレンス指示(PPI)によって示される。または、セットのリソースの使用の開始と停止は、UEまたはeNBによって明示的に示されることができる。MAC CEまたはRRCメッセージは、望ましいSRの使用をシグナリングし、互いに同期するように用いられることができる。
【0039】
eNBとUEは、SRの使用で同期していなければならず、複数のSR割り当ては、DRX状態の遷移によって、制御(例えば、アクティブ化および/または非アクティブ化)されることができる。2つのSRリソースSR1とSR2が予め割り当てられているとする。1つの例では、DRX ON周期は、第1のSR割り当てSR1と関連付けられることができ、DRX OFF周期は、他のSR割り当てSR2と関連付けられることができる。もう1つの例では、アクティブの時間の時、両SR設定がアクティブ化される。一旦UEがDRXに入ると、第2のSR割り当てSR2は、SR1がアクティブのままで自動的に非アクティブ化される。SRの使用は所定のイベントによって制御されるため、余分なRRCシグナリングがない。
【0040】
全てのアプリケーションによってシェアされる1つだけのSR設定と比べ、アプリケーションが結合したSR設定は、より多くの情報をeNBに提供することができる。特定のSR設定を1つまたはサブセットのアプリケーションと関連付けることは、開始から更なる情報をeNBに提供することができる。例えば、遅延耐性(delay−tolerant)のアプリケーションに割り当てられた特定のリソースでSRの指示を受信した時、eNBは、ULデータが緊急でないことを知り、このような情報は、今後のスケジューリングに用いられることができる。
【0041】
図13は、1つの新しい実施形態に基づくSRリソース割り当て用の補助情報を提供する方法のフローチャートである。ステップ1301では、UEは、基地局とRRC接続を確立する。UEは、RRC接続モードにある。一般的にUEは、SRリソース割り当て用にeNBによって初期のSR設定で設定される。ステップ1302では、UEは、SRリソースの使用率を評価し、補助情報をeNBに送信して、SRリソースの使用率を向上させる必要があるかどうかを決定する。次いで、必要がある場合、ステップ1303では、UEは、補助情報をeNBに提供する。補助情報は、PUCCHのSRリソース割り当てに関連している。1つの例では、補助情報は、UEに望ましい(UE−preferred)SR設定インデックスを含む。もう1つの例では、補助情報は、UEに望ましいSR周期/オフセット、および/またはパケット到着間隔(IAT)に関連したトラフィックパターン情報を含む。ステップ1304では、UEは、補助情報に応じてeNBからSR設定を受信する。SR設定は、SRリソース割り当て用にSR周期とSRオフセットと関連したSR設定インデックスを含む。UEは、QoSリクエスト、トラフィックパターン/統計、およびDRX設定を含んだ考慮に基づき、補助情報を提供するため、eNBは、より正確にSRリソースを割り当てることができる。UEは、更にリクエストメッセージを送信し、SR割り当てを解除する。
【0042】
図14は、1つの新しい実施形態に基づくSR設定の適応およびSRリソースのリサイクルを用いる方法のフローチャートである。ステップ1401では、UEは、基地局からスケジューリングリクエスト(SR)設定を受信する。SR設定は、SR伝送用にセットの無線リソースを割り当て、割り当てられたSRリソースは、第1のSR周期と第2のSR周期と関連付けられる。ステップ1402では、UEは、第1のSR周期を用いてSRの送信をする。ステップ1403では、UEは、第1の所定のトリガー条件が満たされた後、第2のSR周期を用いてSRの送信をする。1つの実施形態では、トリガー条件は、SR設定によって設定されたSRタイマーに基づく。もう1つの実施形態では、トリガー条件は、特定のアプリケーション用のアップリンクデータが基地局に送信された時、満たされる。トリガー条件は、不連続受信(DRX)動作の状態に基づくこともできる。ステップ1404では、UEは、第2の所定のトリガー条件が満たされた後、切り戻され、第1のSR周期を用いる。第2の所定のトリガー条件は、第1のトリガー条件と同じまたは異なってもよい。1つの有利な実施形態では、PUCCHの未使用のSRリソースは、他のUE用に、またはPUSCHのデータ伝送用にリサイクルされることができる。異なるSR周期のSRリソースを設定することによって、SRリソースの使用率は、トラフィックパターンに適応される。
【0043】
図15は、1つの新しい実施形態に基づく所定のアプリケーションの複数のSR設定を設定する方法のフローチャートである。ステップ1501では、UEは、基地局から第1のSR設定を受信する。第1のSR設定は、SR伝送用にPUCCHの第1のセットのリソースを割り当てる。ステップ1502では、UEは、基地局から第2のSR設定を受信する。第2のSR設定は、SR伝送用にPUCCHの第2のセットのリソースを割り当てる。ステップ1503では、UEは、第1のアプリケーションが動作している時、第1のセットのSRリソースを用いる。ステップ1504では、UEは、第2のアプリケーションが動作している時、第2のセットのSRリソースを用いる。ステップ1505では、UEは、第1のアプリケーションが動作を停止した時、第1のセットのSRリソースの使用を停止する。各SR設定は、1つ以上の所定のアプリケーションと関連付けされる。複数の予め割り当てられたSRリソースは、アプリケーションのサービス品質(QoS)リクエストを満たすように決定される。1つの実施形態では、割り当てられたSR無線リソースは、DRX状態の遷移に基づき、アクティブ化または非アクティブ化される。複数の予め割り当てられたSR設定でSRリソースの使用は、関連するアプリケーションに適応される。
【0044】
本発明は、説明のためにある特定の実施の形態に関連して述べられているが本発明はこれを制限するものではない。よって、種々の変更、改造、及び上述の実施の形態の種々の特徴の組み合わせがこの請求項に記載したような本発明の範囲を逸脱せずに行い得る。
【符号の説明】
【0045】
100 無線通信システム
101、201、401、601、801、901、1201 ユーザー端末
102、202、402、602、802、902、1202 基地局
211、231 RFトランシーバモジュール
212、232 プロセッサ
213、233 メモリ
214、234 プログラム命令とデータ
221、241 RRC管理モジュール
224、234 アプリケーション
223 SRアプリケーション
222 状態収集モジュール
225 アンテナ
245 アンテナ
243 SR CONFIG
242 QoS管理モジュール
300 図3の表
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15