(57)【要約】【課題】不連続受信および／または送信サイクル長が決定される方法の改良を提供する【解決手段】  不連続受信および／または送信サイクル長を決定する方法であって、プロトコルスタック内の上位層から、サイクル長に関連する情報を決定すること、その情報をプロトコルスタック内の下位層に提供すること、およびプロトコルスタックの下位層内において、情報からサイクル長を決定することを含む方法が提供される。【選択図】図１
2010538506.tif 000002
【特許請求の範囲】
【請求項１】
不連続受信および／または送信サイクル長を決定する方法であって、
プロトコルスタック内の上位層から、前記サイクル長に関連する情報を決定すること、
前記プロトコルスタック内の下位層に前記情報を提供すること、および
前記プロトコルスタックの前記下位層において、前記情報から前記サイクル長を決定すること
を含む、方法。
【請求項２】
前記サイクル長に関連する前記情報は、アプリケーション固有の情報を含む、請求項１に記載の方法。
【請求項３】
前記アプリケーション固有の情報は、オブジェクトタイプ、サービスタイプ、オブジェクトサイズ、ファイルサイズ、およびコーデックパラメータのうちの少なくとも１つを含む、請求項２に記載の方法。
【請求項４】
前記情報から前記サイクル長を決定するステップは、所定のアルゴリズムを使用することを含む、請求項１、２、または３に記載の方法。
【請求項５】
前記所定のアルゴリズムは、情報値を各サイクル長に関連付けるマッピングテーブルを含む、請求項４に記載の方法。
【請求項６】
前記上位層はアプリケーション層である、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記上位層はインターネットプロトコル層を含む、請求項１〜５のいずれか一項に記載の方法。
【請求項８】
前記下位層はデータリンク層である、請求項１〜７のいずれか一項に記載の方法。
【請求項９】
基地局において実行される、請求項１〜８のいずれか一項に記載の方法。
【請求項１０】
移動端末でも実行される、請求項９に記載の方法。
【請求項１１】
前記決定されたサイクル長を移動端末に示すステップをさらに含む、請求項９に記載の方法。
【請求項１２】
前記示すステップは、前記プロトコルスタックの前記下位層でのシグナリングを使用して、前記決定されたサイクル長を前記移動端末に送信することを含む、請求項１１に記載の方法。
【請求項１３】
前記示すステップは、前記プロトコルスタックの前記上位層でのシグナリングを使用して、前記決定されたサイクル長を前記移動端末に送信することを含む、請求項１１に記載の方法。
【請求項１４】
前記移動端末はアイドルモードである、請求項１０、１１、１２、または１３に記載の方法。
【請求項１５】
前記移動端末はアクティブモードまたは接続モードである、請求項１０、１１、１２、または１３に記載の方法。
【請求項１６】
通信ネットワーク内で使用される基地局であって、
処理手段を備え、前記処理手段は、
前記基地局のプロトコルスタック内の上位層から、不連続送信および／または受信サイクル長に関連する情報を決定すること、
前記プロトコルスタック内の下位層に前記情報を提供すること、および
前記プロトコルスタックの前記下位層において、前記情報から前記サイクル長を決定すること
を行うように構成される、基地局。
【請求項１７】
前記サイクル長に関連する前記情報は、アプリケーション固有の情報を含む、請求項１６に記載の基地局。
【請求項１８】
前記アプリケーション固有の情報は、オブジェクトタイプ、サービスタイプ、オブジェクトサイズ、ファイルサイズ、およびコーデックパラメータのうちの少なくとも１つを含む、請求項１７に記載の基地局。
【請求項１９】
前記情報から前記サイクル長を決定するように構成された手段は、所定のアルゴリズムを使用するように構成される、請求項１６、１７、または１８に記載の基地局。
【請求項２０】
前記所定のアルゴリズムは、情報値を各サイクル長に関連付けるマッピングテーブルを含む、請求項１９に記載の基地局。
【請求項２１】
前記上位層はアプリケーション層である、請求項１６〜２０のいずれか一項に記載の基地局。
【請求項２２】
前記アプリケーション層はインターネットプロトコル層を含む、請求項２１に記載の基地局。
【請求項２３】
前記下位層はデータリンク層である、請求項１６〜２２のいずれか一項に記載の基地局。
【請求項２４】
前記処理手段は、前記決定されたサイクル長を移動端末に示すようにさらに構成される、請求項１６〜２３のいずれか一項に記載の基地局。
【請求項２５】
前記処理手段は、前記プロトコルスタックの前記下位層でのシグナリングを使用して、前記決定されたサイクル長を前記移動端末に送信することにより、前記決定されたサイクル長を前記移動端末に示すように構成される、請求項２４に記載の基地局。
【請求項２６】
前記処理手段は、前記プロトコルスタックの前記上位層でのシグナリングを使用して、前記決定されたサイクル長を前記移動端末に送信することにより、前記決定されたサイクル長を前記移動端末に示すように構成される、請求項２４に記載の基地局。
【請求項２７】
前記処理手段は、前記移動端末がアイドルモードで動作しているときに、前記決定されたサイクル長を前記移動端末に示すように構成される、請求項２４〜２６のいずれか一項に記載の基地局。
【請求項２８】
前記処理手段は、前記移動端末がアクティブモードまたは接続モードで動作しているときに、前記決定されたサイクル長を前記移動端末に示すように構成される、請求項２４〜２６のいずれか一項に記載の基地局。
【請求項２９】
請求項１６〜２３のいずれか一項に記載の基地局を少なくとも１つ含む通信ネットワーク内で使用される移動端末であって、
処理手段を備え、前記処理手段は、
前記移動端末のプロトコルスタック内の上位層から、不連続送信および／または受信サイクル長に関連する情報を決定すること、
前記プロトコルスタック内の下位層に前記情報を提供すること、および
前記プロトコルスタックの前記下位層において、前記情報から前記サイクル長を決定すること
を行うように構成される、移動端末。
【請求項３０】
前記サイクル長に関連する前記情報は、アプリケーション固有の情報を含む、請求項２９に記載の移動端末。
【請求項３１】
前記アプリケーション固有の情報は、オブジェクトタイプ、サービスタイプ、オブジェクトサイズ、ファイルサイズ、およびコーデックパラメータのうちの少なくとも１つを含む、請求項３０に記載の移動端末。
【請求項３２】
前記情報から前記サイクル長を決定するように構成された手段は、所定のアルゴリズムを使用するように構成される、請求項２９、３０、または３１に記載の移動端末。
【請求項３３】
前記所定のアルゴリズムは、情報値を各サイクル長に関連付けるマッピングテーブルを含む、請求項３２に記載の移動端末。
【請求項３４】
前記上位層はアプリケーション層である、請求項２９〜３３のいずれか一項に記載の移動端末。
【請求項３５】
前記アプリケーション層はインターネットプロトコル層を含む、請求項３４に記載の移動端末。
【請求項３６】
前記下位層はデータリンク層である、請求項２９〜３５のいずれか一項に記載の移動端末。
【請求項３７】
請求項２５に記載の基地局を少なくとも１つ含む通信ネットワーク内で使用される移動端末であって、
前記基地局から受信されるプロトコルスタックの下位層でのシグナリングから、サイクル長を決定するように構成された処理手段
を備える、移動端末。
【請求項３８】
請求項２６に記載の基地局を少なくとも１つ含む通信ネットワーク内で使用される移動端末であって、
前記基地局から受信されるプロトコルスタックの上位層でのシグナリングから、サイクル長を決定するように構成された処理手段
を備える、移動端末。
【請求項３９】
前記移動端末の前記処理手段は、前記移動端末がアイドルモードであるときに動作するように構成される、請求項２９〜３８のいずれか一項に記載の移動端末。
【請求項４０】
前記移動端末の前記処理手段は、前記移動端末がアクティブモードまたは接続モードであるときに動作するように構成される、請求項２９〜３８のいずれか一項に記載の移動端末。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の技術分野
本発明は、広帯域符号分割多元接続（ＷＣＤＭＡ）システムおよびロングタームエボリューション（ＬＴＥ）システムでの不連続送受信に関する。
【背景技術】
【０００２】
発明の背景
広帯域符号分割多元接続（ＷＣＤＭＡ）システムおよびロングタームエボリューション（ＬＴＥ）システムでは、不連続送受信（ＤＲＸ／ＤＴＸ）により、ユーザ装置（ＵＥ）として知られている移動端末が、無線送受信回路をオフに切り替え、それにより、消費電力を劇的に低減できるようにする。例えば、ＷＣＤＭＡネットワークでは、ＵＥがアイドルのとき、または接続モードでＣｅｌｌ＿ＰＣＨ状態またはＵＲＡ＿ＰＣＨ状態にあるとき、ＤＲＸを使用して、消費電力を１００〜４００ｍＡから５〜１０ｍＡに低減することができる。
【０００３】
ＵＥが、パケットを「連続して」送受信するという意味でアクティブである場合、不連続送受信は、消費電力を大幅に低減し、それにより、アクティブモード時間または通話時間（すなわち、ＵＥが、電池を充電する必要なくアクティブ状態を保つことができる時間）が増大する。実際に、ＤＲＸは、ＷＣＤＭＡシステムでの連続パケット接続（ＣＰＣ：Continuous Packet Connectivity）においてサポートされ、これは、「Continuous Packet Connectivity (CPC) for Packet Data Users」（リリース７）という題名で３ＧＰＰ仕様書ＴＲ２５．９０３に述べられている。同様に、ＬＴＥ仕様は、ＵＥがＬＴＥ＿ＡＣＴＩＶＥ状態である間でのＤＲＸをサポートしており、これは、「Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)」という題名で３ＧＰＰ仕様書ＴＳ３６．３００に述べられている。
【０００４】
アクティブモード（ＬＴＥ＿ＡＣＴＩＶＥ等）でＤＲＸを使用する場合、ＤＲＸサイクル長は、ＵＥが十分に低い待ち時間であるが、それでもやはり低消費電力を提供して、データを送信し、かつ／または受信できるように制御される必要がある。ＵＥに関連する基地局は、無線リソース制御（ＲＲＣ）および／または媒体アクセス制御（ＭＡＣ）シグナリングを使用してＤＲＸサイクル長を制御することができ、またはＵＥによるＤＲＸサイクルの自律的な調整に頼ることができる。この後者の場合、無線インタフェースを介するシグナリング量は低減するが、ネットワーク（すなわち、基地局および他のノード）は、ＬＴＥ＿ＡＣＴＩＶＥであるＵＥの現在のＤＲＸサイクルを追跡しなければならない。これは、無線アクセスネットワーク（ＲＡＮ）が、例えば、データバーストを特定のＵＥに（特にＱｏＳ要件に依存して）所定のデッドライン以内に送出する必要がある場合、その特定のＵＥをスケジュール可能でなければならないためである。
【０００５】
アクティブモードである間、ＵＥは、音声サービスおよび様々な（リアルタイム、準リアルタイム、およびベストエフォート）データサービスを使用し、それにより、パケット到着時間間隔（送信時間間隔）は動的に変化する。その結果、ＵＥが受信器および送信器をアクティブ化すべきときおよび非アクティブ化すべきときは、頻繁に変化し得る。換言すれば、「最適な」状況とは、ＵＥがスリープすべき瞬間およびウェイクアップすべき瞬間は、続くパケット到着／送信時間に適応するように動的に制御される。しかし、このような「最適な」（すなわち、完全に動的な）制御の場合、無線インタフェースを介する関連する制御シグナリングは、法外なほど大量になる。
【０００６】
したがって、トラフィックダイナミクスにより、ＤＲＸ／ＤＴＸウェイクアップ時間を理想的な、すなわち最適なＤＲＸ／ＤＴＸ設定に近づける程度と、無線インタフェースを介する必要なシグナリング量との間には、根本的なトレードオフがある。
【０００７】
電池消費と関連する制御シグナリングの複雑性（およびオーバーヘッド）との間のこのトレードオフは、広く認識されており、いくつかの手法が３ＧＰＰ内で提案されている。
【０００８】
「１レベルＤＲＸ／ＤＴＸサイクル」手法として既知の一手法では、いかなる一瞬にも、ＵＥが送受信器回路をオンオフするために従う、ＵＥ内に記憶された単一の所定パターンがある。基地局は、この所定パターンを変更する必要がある場合、制御シグナリングを使用して、その後のウェイクアップ／スリープの瞬間を指定する新たなパターンを指定する。
【０００９】
「２レベルＤＲＸ／ＤＴＸサイクル」手法として既知の代替の手法では、ＵＥが送受信器回路をオンオフするために従う、２つの基本的に独立したパターンが定義される。いかなる時点でも、２つのパターンを使用することにより、ＵＥは、状態を変更する必要がある次の瞬間を計算することができる。あるいは、基地局が明示的なシグナリングを使用して、所定のサイクルパターンのいずれかのアクティブ化および非アクティブ化を行うことができる。２レベル方式は、現在使用中のＤＲＸパターンの頻繁な認識を回避するため、有用である。
【００１０】
ＷＣＤＭＡでの連続パケット接続特徴により、２レベルＤＲＸ方式のアクティブ化が可能である。この手法では、ＵＥは、特定のネットワーク指定持続時間中にサービスに関わらない場合、より長いＤＲＸサイクルに切り替わる。
【００１１】
１レベルまたは２レベルの基本方式のいずれかをＵＥの自律挙動と組み合わせた混成手法も提案されている。この方式では、ＵＥは、トラフィック発着パターンに依存して、現在のＤＲＸパターンを動的かつ適応的に調整する。ＵＥは、ＤＲＸ間隔を調整する際に所定の規則に従うため、かつＵＥおよび基地局は共通の（絶対的な）クロックを共有するため、ＵＥおよび基地局は、いかなる時点でも、現在有効なＤＲＸ間隔について共通の知識を有する。
【００１２】
上の既存の解決策は、制御シグナリングとＤＲＸ／ＤＴＸサイクルの変更または適応とのトレードオフに焦点を合わせている。土台をなす基本的な仮定は、ＵＥも基地局も、トラフィックパターン（ひいてはパケット到着時間間隔）についての十分な（または十分に正確な）知識を有さず、これらメカニズムが本質的に事後対応的なものであることである。
【００１３】
上述したこれらすべての３つの手法（１レベル、２レベルの基地局制御または混成基地局制御、およびＵＥ自律）において、ＤＲＸ／ＤＴＸサイクルならびに対応するウェイクアップ時間およびスリープ時間は、ＵＥおよび基地局の最近の活動に基づいて指定され変更される。例えば、進行中のサービスがウェブ閲覧である場合、ＵＥは、無線チャネルにトラフィック活動がない場合、自律的に、または基地局からの明示的な指示を受けて、ＤＲＸ期間を拡張する。したがって、ＤＲＸサイクルの選択は主に、バッファ内のトラフィック量、トラフィックタイプの統計的モデル、および／またはこれらの組み合わせに基づく。
【００１４】
ＤＲＸサイクルは、サービスまたはトラフィックのタイプについての厳密な情報なしで指定されるため、ＤＲＸパターンは、後続する時間期間（長くとも数秒であり得る）内で予想できるパケット発着パターンについての情報を利用せずに指定される必要がある。したがって、２つの問題が生じる。
【００１５】
第１の問題は、ＵＥが利用するＤＲＸサイクルが、保守的でありすぎる（トラフィックがないときに、ＵＥの送受信器がアクティブである）か、または十分に保守的ではない（スケジュールすべきデータがあるときに、ＵＥの送受信器が非アクティブである）ことである。前者の（ＵＥが保守的すぎる）場合、電池の寿命は短くなる一方で、２番目の場合は、パケット遅延が増大する。
【００１６】
第２の問題は、ＤＲＸサイクルパターンを最新に保つために必要な制御シグナリングが頻繁になりすぎ、結果として、オーバーヘッドひいては無線リソースの無駄が多くなる恐れがあることである。
【００１７】
物理層またはＭＡＣ層での制御シグナリングが、ＤＲＸサイクルを切り替えるために使用される（例えば、ＬＴＥにおいて）。これらチャネルは限られた数のビットを含み、チャネルを不適切または頻繁に使用すると、かなりのオーバーヘッドが生じる。さらに、必要なビット数は、ＤＲＸレベル数の増大と共に増大する（例えば、２レベルＤＲＸの場合には１ビットであり、最高で４レベルまでのＤＲＸの場合には２ビットであり、以下同様である）。別の制限は、シグナリングがオン／オフの性質のものであるため、かつ（ノイズにより）、受信器において誤った（すなわち、反転した）判断をより受けやすいことである。
【００１８】
米国特許出願公開第２００５／００３２５５５号には、移動ユーザ端末の受信回路を断続的にアクティブ化する方法が記載されている。受信回路がアクティブ化される期間は、移動ユーザ端末への最新の呼接続において提供されたサービスのタイプ（例えば、パケットデータ呼、ビデオクリップ、ウェブ閲覧、ＦＴＰセッション）に基づいて決定することができる。
【００１９】
しかし、この方法には、サイクル長を決定するために、移動端末に提供された最新のサービスタイプに頼り、したがって、決定されるサイクル長が、移動端末に提供されることになる次のサービスタイプに特に適しない恐れがあるという欠点がある。
【発明の概要】
【発明が解決しようとする課題】
【００２０】
したがって、本発明の目的は、不連続受信および／または送信サイクル長が決定される方法の改良を提供することである。
【課題を解決するための手段】
【００２１】
発明の概要
本発明の第１の態様によれば、不連続受信および／または送信サイクル長を決定する方法であって、プロトコルスタック内の上位層から、サイクル長に関連する情報を決定すること、その情報をプロトコルスタック内の下位層に提供すること、およびプロトコルスタックの下位層において、情報からサイクル長を決定することを含む、方法が提供される。
【００２２】
本発明の第２の態様によれば、通信ネットワーク内で使用される基地局であって、基地局のプロトコルスタック内の上位層から、不連続送信および／または受信サイクル長に関連する情報を決定すること、その情報をプロトコルスタック内の下位層に提供すること、およびプロトコルスタックの下位層において、情報からサイクル長を決定することを行うように構成された処理手段を備える、基地局が提供される。
【００２３】
本発明の第３の態様によれば、上述したような少なくとも１つの基地局を含む通信ネットワーク内で使用される移動端末であって、移動端末のプロトコルスタック内の上位層から、不連続送信および／または受信サイクル長に関連する情報を決定すること、その情報をプロトコルスタック内の下位層に提供すること、およびプロトコルスタックの下位層において、情報からサイクル長を決定することを行うように構成された処理手段を備える、移動端末が提供される。
【００２４】
本発明の第４の態様によれば、上述したような少なくとも１つの基地局を含む通信ネットワーク内で使用される移動端末であって、基地局から受信されるプロトコルスタックの下位層におけるシグナリングから、サイクル長を決定するように構成された処理手段を備える、移動端末が提供される。
【００２５】
本発明の第５の態様によれば、上述したような少なくとも１つの基地局を含む通信ネットワーク内で使用される移動端末であって、基地局から受信されるプロトコルスタックの上位層におけるシグナリングから、サイクル長を決定するように構成された処理手段を備える、移動端末が提供される。
【００２６】
図面の簡単な説明
これより、単なる例として、以下の図面を参照して本発明について説明する。
【図面の簡単な説明】
【００２７】
【図１】本発明による通信ネットワークを示す。
【図２】本発明の実施形態を示す層モデルである。
【図３】本発明の実施形態によるマッピングテーブルを示す。
【図４】本発明による方法を示すフローチャートである。
【発明を実施するための形態】
【００２８】
好ましい実施形態の詳細な説明
本発明について、広帯域符号分割接続（ＷＣＤＭＡ）システムおよびロングタームエボリューション（ＬＴＥ）システム内での不連続送受信を参照して説明するが、本発明が他の多くの種類の通信ネットワークにも適用可能なことが当業者には理解されよう。
【００２９】
さらに、本明細書では、本発明が、受信器回路の不連続の送信および非アクティブ化を意味する「ＤＲＸ」を参照して考察される場合、別段のことが明示的に示されない限り、本発明が、送信器回路の不連続な送信（ＤＴＸ）および非アクティブ化にも等しく適用可能なことが理解されよう。
【００３０】
図１は、本発明による例示的なＷＣＤＭＡネットワーク２の部分を示す。ネットワーク２は、ＷＣＤＭＡネットワークへのアクセスポイントをユーザ装置に提供する、それぞれ「ノードＢ」として知られる２つの関連する基地局６を有する無線ネットワークコントローラ（ＲＮＣ）４を備える。移動端末８（ユーザ装置−ＵＥまたは移動装置−ＭＥと呼ばれることもある）は、基地局６のうちの１つと通信することにより、サービスを受信する。ＲＮＣ４は、基地局６の動作を制御すると共に、ＷＣＤＭＡネットワーク２へのアクセスポイントを通信ネットワーク１２に（ひいてはインターネットサーバ１０にも）提供する。この図示の実施形態では、移動端末８は、インターネット等の別の通信ネットワーク１２を通してサーバ１０と通信している。サーバ１０は、音声呼、映像呼、ファイルダウンロード等のデータサービスを移動端末８に提供中であり得る。
【００３１】
上述したように、移動端末８は、アイドルモードである（すなわち、ユーザ装置またはインターネットサーバ等の別のピアエンティティとアクティブに通信中ではない）場合、ページングチャネルを監視して、入力呼接続要求をリッスンする。移動端末８の電池寿命を向上させるために、受信器回路は、所定の間隔（ページング時（paging occasion）またはウェイクアップ時（wake up instance）と呼ばれる）中のみアクティブ化されて、入力呼接続要求を探してページングチャネルを監視し、他のすべての時間では、非アクティブ化される。これは不連続受信（ＤＲＸ）として知られており、間隔長は不連続受信サイクル長として知られている。
【００３２】
さらに、移動端末８がアクティブである（すなわち、接続モードである）ときであっても、移動端末８は、ＲＮＣ４からのデータバースト間に受信器回路を非アクティブ化することができる。換言すれば、アクティブモードまたは接続モードのＵＥは、ＤＲＸモードで動作することもできる。したがって、ＤＲＸで動作中の接続モードのＵＥは、ウェイクアップ時のみ、データを受信することができる。
【００３３】
両方の事例において、移動端末８にサービス提供する基地局６および移動端末８自体は、同じＤＲＸサイクル長を使用しなければならず、ＤＲＸサイクルが同期されることを保証しなければならない。これは、ＵＥの受信器がオンに切り替わったとき（すなわち、ＵＥが「起きた」とき）に、基地局６がＵＥに対して（制御またはユーザの普通）データをスケジュールして送信できるようにするためである。
【００３４】
本発明によれば、可変ＤＲＸサイクル長を実施するために必要なネットワークシグナリングを最小に抑えるために、基地局６および／または移動端末８は、プロトコルスタック内の上位層からの情報を使用して、ＤＲＸサイクル長を来るべきデータトラフィックパターンに適応させる。
【００３５】
一実施形態では、基地局６は、移動端末８がピアエンティティ（サーバ１０）に向けて使用する、プロトコルスタックの上位層（ハイパーテキスト転送プロトコル層−ＨＴＴＰ層、ファイル転送プロトコル層−ＦＴＰ層、および／またはリアルタイム制御プロトコル層−ＲＴＣＰ層等）でのシグナリングを調べる。
【００３６】
本発明の例示的な実施形態を図２に示す。この図では、移動端末８（ＵＥ）、基地局６（ＲＡＮ／ｅＮＢ）、およびサーバ１０（ＩＰマルチメディアシステム−ＩＭＳ−サーバ）の動作は、通信およびコンピュータネットワークプロトコル設計の階層化された抽象記述である開放型システム間相互接続（ＯＳＩ）基本参照モデルに従って層に分けられている。
【００３７】
ネットワーク内の各要素は、ＯＳＩモデルからの順序付き層のうちの４つ、特に、ＲＲＣシグナリング、媒体アクセス制御（ＭＡＣ）シグナリング、およびＬ１シグナリングを実施するデータリンク層２０と、インターネットプロトコル（ＩＰ）を実施するネットワーク層２２と、伝送制御プロトコル（ＴＣＰ）およびユーザデータグラムプロトコル（ＵＤＰ）を実施するトランスポート層２４と、アプリケーション層２６とを含むプロトコルスタックを有して示される。
【００３８】
データリンク層２０は、ネットワーク内の要素間でデータを転送し、物理層（データリンク層２０の下にあるが、図２には示されていない）内で発生し得るエラーを検出する手段を提供する。データリンク層２０は、装置と共有媒体との対話を管理する。
【００３９】
ネットワーク層２２は、トランスポート層２４により要求されたサービス品質を維持しながら、１つまたは複数のネットワークを介して、ソース（例えば、サーバ１０）から宛先（例えば、移動端末８）へ可変長データパケットを転送する手段を提供する。ネットワーク層２２は、ネットワークルーティング機能を実行する。
【００４０】
トランスポート層２４は、受信に成功しなかったパケットの再送信開始を含めた、サーバ１０と移動端末８との間でのデータ転送に使用されるリンクの信頼性を制御する。
【００４１】
アプリケーション層２６は、サーバ１０または移動端末８のそれぞれで実行中のアプリケーションプロセスとインタフェースし、それらのアプリケーションサービスを実行する。アプリケーション層２６は、エンドユーザにではなく、ユーザ定義のアプリケーションプロセスにサービスを提供する。
【００４２】
したがって、この実施形態では、基地局６内の不連続受信を実施するプロトコル（この実施形態では、データリンク層２０の部分である）は、（矢印２８で示されるように）「上位の」アプリケーション層２６を調べるか、またはアプリケーション層２６に問い合わせて、来るべきデータトラフィックパターンについての情報を決定するように構成される。好ましい実施形態では、ネットワーク層２２がインターネットプロトコルを使用する場合、ＤＲＸエンティティは、搬送されたＩＰパケットの構造（ＩＰパケットヘッダおよびペイロード内の情報を含む）を調べる。代替の実施形態では、ＤＲＸプロトコルは、ＩＰパケットのペイロードとして搬送されるアプリケーション層パケット（ヘッダ情報およびペイロード情報を含む）を調べる。
【００４３】
この「上位」層の知識が得られると、基地局６は、所定のアルゴリズムを使用して、移動端末８のおおよそのＤＲＸサイクル長を決定する。
【００４４】
したがって、基地局６は、データリンク層２０よりも上位の層（ＲＲＣ層／ＭＡＣ層／ＲＲＣ層）では情報を処理しない。しかし、ＬＴＥシステムでは、ヘッダ圧縮およびパケットデータ収束プロトコル（packet data convergence protocol）が、基地局６によりサポートされる（３ＧＰＰ使用３６．３００内の図４．１参照）。したがって、基地局６は、ＩＰパケットおよびアプリケーション層パケットを含む上位層情報に即時にアクセスすることができる。
【００４５】
情報が上位層から取り込まれると、その情報を、ＤＲＸパラメータを決定するアルゴリズムへの入力として使用することができる。「上位層」サービス品質情報を従来のＤＲＸアルゴリズムに考慮することが既知であるが、基地局６は、ネットワークから受信する下位層シグナリングからこの情報を得る（例えば、ＷＣＤＭＡシステムおよびＬＴＥシステムのそれぞれ内の論理ユニットまたはＳ１インタフェースを介して）。「無線ベアラセットアップ」手順と一般に呼ばれる論理ユニットおよびＳ１シグナリングのプロトコルは、アプリケーションを所定の小さなカテゴリセット（いわゆる、サービス品質（ＱＯＳ）クラスに分類し、粒度の粗い関連パラメータを使用して、トラフィックを特徴付ける。しかし、トラフィックパターン（パケットサイズおよびその到着レート）はランダムであり、そのため、トラフィック挙動を正確に予測することができないため、無線ベアラセットアップ情報に基づいて選択されたＤＲＸサイクルは、理想的な場合よりも短く、または長くなり得る。基地局６において上位層シグナリングを（厳密なオブジェクトサイズまたはファイルサイズおよび詳細なコーデックパラメータを含む）調べて、アプリケーション固有（すなわち、粒度の細かい）情報を決定することにより、これら問題が解消される。
【００４６】
本発明の実施形態によれば、上位層から得られる情報は、入力データ（例えば、音声呼、映像呼、ファイルダウンロード等）が関連する特定のアプリケーションおよびそのアプリケーションに関連する特定の情報（例えば、データレート、合計ファイルサイズ等）を示す。好ましくは、ＤＲＸサイクル長を決定するアルゴリズムは、このアプリケーション固有の情報を考慮して、移動端末８の最良のＤＲＸサイクル長を見つける。
【００４７】
本発明の一実施形態では、基地局８は、マッピングテーブルを使用して、上位層から決定された情報をＤＲＸサイクル長に関連付ける。
【００４８】
ＤＲＸサイクル長の決定に、アプリケーション固有の情報を考慮する、例示的なマッピングテーブルを図３に示す。テーブルの左列には、４つの異なるアプリケーションプロトコルが列挙される。すなわち、ＨＴＴＰ（ウェブベースの情報を処理する）、ＦＴＰ（データファイルのダウンロードを処理する）、音声コーデック（音声呼を処理する）、および映像コーデック（映像呼を処理する）である。
【００４９】
マッピングテーブルの中央列は、所望のＤＲＸサイクル長に影響を及ぼすことができるアプリケーション固有の情報を示す。したがって、ＨＴＴＰプロトコルの場合、アプリケーション固有の情報は、キロバイト（ＫＢ）単位のオブジェクトサイズを示し、ＦＴＰプロトコルの場合、アプリケーション固有の情報は、キロバイト（ＫＢ）単位のファイルサイズを示し、音声コーデックおよび映像コーデックの場合、アプリケーション固有の情報はコーデックタイプを示す。
【００５０】
マッピングテーブルの３列目は、特定のアプリケーションおよびアプリケーション固有の情報の場合のＤＲＸサイクル長を示す。ＨＴＴＰプロトコルおよびＦＴＰプロトコルの場合、ＤＲＸサイクル長は、オブジェクトサイズまたはファイルサイズが増大するにつれて、低減する（すなわち、受信器回路はより頻繁にアクティブ化される）。オブジェクトサイズまたはファイルサイズは、来たるべきトラフィック状況についての知識を基地局８に提供する。さらなる実施形態では、基地局６は、この情報ならびにバッファ状態および無線状況（例えば、経路損失）に関連する情報を使用して、ＤＲＸサイクル長を決定する。
【００５１】
音声コーデックおよび映像コーデックの場合、ＤＲＸサイクルはコーデックタイプ（ＲＴＣＰプロトコルにおいて示される）、特に、音声コーデックおよび映像コーデックのそれぞれのサンプリング周波数に依存する。コーデックの周期についての知識を有することは、ＤＲＸサイクル長を決定するために重要である。
【００５２】
本発明の一実施形態では、移動端末８も「上位」層知識内の情報にアクセスすることができるため（図２に示されるように、定義により）、移動端末８のデータリンク層２０内のＤＲＸプロトコルも、基地局６と同じ所定のアルゴリズム（マッピングテーブル等）を使用して、（移動端末８の）アプリケーション層２６を調べ、移動端末８のおおよそのＤＲＸサイクル長を決定することができる。
【００５３】
この実施形態では、移動端末８および基地局６が、上位層から得られる共通の知識を共有し、同じアルゴリズムを利用して、おおよそのＤＲＸサイクル長を決定するため、装置６と装置８との間で必要な専用制御シグナリングはごくわずかであるか、またはまったくない。したがって、無線リソースが節減される。さらに、これにより、ＤＲＸサイクル長は、ネットワーク内の変わりつつあるサービスまたはサービスタイプに対して素早く適応する。
【００５４】
換言すれば、基地局６と移動端末８との間でのアプリケーション層２６のシグナリングと下位層（ＤＲＸ関連）シグナリングとの間の冗長性がなくなる。
【００５５】
基地局６および移動端末８により使用されるマッピングテーブルは、標準化する（すなわち、所定の規則に従う）こともでき、または基地局６および移動端末８がセッション開始時に決定することもできる。いずれの場合でも、セッション中、無線インタフェースを介してのＤＲＸ関連の制御シグナリングはない。
【００５６】
本発明の代替の実施形態では、基地局６のみが、上位層を調べて、移動端末８のおおよそのＤＲＸサイクル長を決定する。したがって、基地局６は、移動端末８に現在のＤＲＸサイクル長を通知する必要がある。
【００５７】
代替の実施形態の１つでは、データリンク層２０での追加の制御シグナリングが使用されて、移動端末８に現在のＤＲＸサイクル長が通知される。好ましくは、このシグナリングは、従来通りにＲＲＣシグナリングおよび／またはＭＡＣシグナリングを使用して実施される。この実施形態には、基地局６が移動端末８に対する完全な制御を維持すると共に、基地局６および移動端末８の両方が、ＤＲＸサイクル長の決定に同じアルゴリズムを使用していることを保証する必要がないという利点がある。
【００５８】
代替の実施形態のうちの別の実施形態では、基地局６は上位層、特にアプリケーション層２６を使用して、ＤＲＸサイクル長を移動端末８に示す。この実施形態には、上述した実施形態と同じ利点があると共に、追加のデータリンク層２０でのシグナリングが必要ないという利点もある。しかし、アプリケーション層２６は、データリンク層２０よりもかなり遅い時間尺度で動作するため、移動端末８に新たなＤＲＸサイクル長を通知するためにかかる時間は、前の実施形態よりも長い。さらに、ＨＴＴＰまたはＦＴＰ等の既存のアプリケーション層プロトコルへのこのＤＲＸサイクル長データの「背負わせ」は、これらプロトコルに変更を行わなければ、実施が困難であることもある。
【００５９】
図４は、本発明による方法を示す。ステップ１０１において、上位層、例えば、アプリケーション層２６が、ＤＲＸサイクル長の決定に使用できる情報に関して調べられる。ステップ１０３において、この情報は、ＤＲＸサイクル長制御を担当する下位層、例えば、データリンク層２０に提供される。ステップ１０５において、この上位層情報は、ＤＲＸサイクル長の決定に使用できるパラメータに変換される。上述したように、上位層情報はアプリケーション固有の情報であることができる。ステップ１０７において、ＤＲＸパラメータが使用されて、ＤＲＸサイクル長が決定され、上述したように、決定することは、マッピングテーブルを使用することを含むことができる。
【００６０】
基地局６および移動端末８が、ＤＲＸサイクル長の決定に使用できる情報に関して上位層を独立して調べる本発明の実施形態では、装置６、８の両方が図４に示す方法を使用する。
【００６１】
上述した実施形態が、本発明の制限ではなく、当業者が、添付の特許請求の範囲から逸脱せずに多くの代替の実施形態を設計可能なことを示すことに留意されたい。言葉「備える」は、請求項内に列挙された要素またはステップ以外の要素またはステップの存在を除外しない。
【００６２】
さらに、上の実施形態は、アイドルモードおよび接続／アクティブモードの両方においてＤＲＸで動作中の移動端末に適用可能である。移動端末の活動モードは、データ活動に応じてアイドルモードから接続モードに、およびその逆に変化する。本発明は、通常、アクティブモード中に受信される上位（アプリケーション）層パケットの検査に頼る。アイドルモードでのＤＲＸ選択もやはり、最近のアクティブモード中に受信した上位（アプリケーション）層パケットに基づくことができる。
【図１】
2010538506.tif 000003
【図２】
2010538506.tif 000004
【図３】
2010538506.tif 000005
【図４】
2010538506.tif 000006
【手続補正書】
【提出日】平成21年7月2日(2009.7.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
不連続受信および／または送信サイクル長を決定する方法であって、
プロトコルスタック内の上位層から、前記サイクル長に関連する情報を決定すること、
前記プロトコルスタック内の下位層に前記情報を提供すること、および
前記プロトコルスタックの前記下位層において、前記情報から前記サイクル長を決定すること
を含む、方法。
【請求項２】
前記サイクル長に関連する前記情報は、アプリケーション固有の情報を含む、請求項１に記載の方法。
【請求項３】
前記アプリケーション固有の情報は、オブジェクトタイプ、サービスタイプ、オブジェクトサイズ、ファイルサイズ、およびコーデックパラメータのうちの少なくとも１つを含む、請求項２に記載の方法。
【請求項４】
前記情報から前記サイクル長を決定するステップは、所定のアルゴリズムを使用することを含む、請求項１、２、または３に記載の方法。
【請求項５】
前記所定のアルゴリズムは、情報値を各サイクル長に関連付けるマッピングテーブルを含む、請求項４に記載の方法。
【請求項６】
前記上位層はアプリケーション層である、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記上位層はインターネットプロトコル層を含む、請求項１〜５のいずれか一項に記載の方法。
【請求項８】
前記下位層はデータリンク層である、請求項１〜７のいずれか一項に記載の方法。
【請求項９】
基地局において実行される、請求項１〜８のいずれか一項に記載の方法。
【請求項１０】
移動端末でも実行される、請求項９に記載の方法。
【請求項１１】
前記決定されたサイクル長を移動端末に示すステップをさらに含む、請求項９に記載の方法。
【請求項１２】
前記示すステップは、前記プロトコルスタックの前記下位層でのシグナリングを使用して、前記決定されたサイクル長を前記移動端末に送信することを含む、請求項１１に記載の方法。
【請求項１３】
前記示すステップは、前記プロトコルスタックの前記上位層でのシグナリングを使用して、前記決定されたサイクル長を前記移動端末に送信することを含む、請求項１１に記載の方法。
【請求項１４】
前記移動端末はアイドルモードである、請求項１０、１１、１２、または１３に記載の方法。
【請求項１５】
前記移動端末はアクティブモードまたは接続モードである、請求項１０、１１、１２、または１３に記載の方法。
【請求項１６】
通信ネットワーク内で使用される基地局であって、
処理手段を備え、前記処理手段は、
前記基地局のプロトコルスタック内の上位層から、不連続送信および／または受信サイクル長に関連する情報を決定すること、
前記プロトコルスタック内の下位層に前記情報を提供すること、および
前記プロトコルスタックの前記下位層において、前記情報から前記サイクル長を決定すること
を行うように構成される、基地局。
【請求項１７】
前記サイクル長に関連する前記情報は、アプリケーション固有の情報を含む、請求項１６に記載の基地局。
【請求項１８】
前記アプリケーション固有の情報は、オブジェクトタイプ、サービスタイプ、オブジェクトサイズ、ファイルサイズ、およびコーデックパラメータのうちの少なくとも１つを含む、請求項１７に記載の基地局。
【請求項１９】
前記情報から前記サイクル長を決定するように構成された手段は、所定のアルゴリズムを使用するように構成される、請求項１６、１７、または１８に記載の基地局。
【請求項２０】
前記所定のアルゴリズムは、情報値を各サイクル長に関連付けるマッピングテーブルを含む、請求項１９に記載の基地局。
【請求項２１】
前記上位層はアプリケーション層である、請求項１６〜２０のいずれか一項に記載の基地局。
【請求項２２】
前記アプリケーション層はインターネットプロトコル層を含む、請求項２１に記載の基地局。
【請求項２３】
前記下位層はデータリンク層である、請求項１６〜２２のいずれか一項に記載の基地局。
【請求項２４】
前記処理手段は、前記決定されたサイクル長を移動端末に示すようにさらに構成される、請求項１６〜２３のいずれか一項に記載の基地局。
【請求項２５】
前記処理手段は、前記プロトコルスタックの前記下位層でのシグナリングを使用して、前記決定されたサイクル長を前記移動端末に送信することにより、前記決定されたサイクル長を前記移動端末に示すように構成される、請求項２４に記載の基地局。
【請求項２６】
前記処理手段は、前記プロトコルスタックの前記上位層でのシグナリングを使用して、前記決定されたサイクル長を前記移動端末に送信することにより、前記決定されたサイクル長を前記移動端末に示すように構成される、請求項２４に記載の基地局。
【請求項２７】
前記処理手段は、前記移動端末がアイドルモードで動作しているときに、前記決定されたサイクル長を前記移動端末に示すように構成される、請求項２４〜２６のいずれか一項に記載の基地局。
【請求項２８】
前記処理手段は、前記移動端末がアクティブモードまたは接続モードで動作しているときに、前記決定されたサイクル長を前記移動端末に示すように構成される、請求項２４〜２６のいずれか一項に記載の基地局。
【請求項２９】
請求項１６〜２３のいずれか一項に記載の基地局を少なくとも１つ含む通信ネットワーク内で使用される移動端末であって、
処理手段を備え、前記処理手段は、
前記移動端末のプロトコルスタック内の上位層から、不連続送信および／または受信サイクル長に関連する情報を決定すること、
前記プロトコルスタック内の下位層に前記情報を提供すること、および
前記プロトコルスタックの前記下位層において、前記情報から前記サイクル長を決定すること
を行うように構成される、移動端末。
【請求項３０】
前記サイクル長に関連する前記情報は、アプリケーション固有の情報を含む、請求項２９に記載の移動端末。
【請求項３１】
前記アプリケーション固有の情報は、オブジェクトタイプ、サービスタイプ、オブジェクトサイズ、ファイルサイズ、およびコーデックパラメータのうちの少なくとも１つを含む、請求項３０に記載の移動端末。
【請求項３２】
前記情報から前記サイクル長を決定するように構成された手段は、所定のアルゴリズムを使用するように構成される、請求項２９、３０、または３１に記載の移動端末。
【請求項３３】
前記所定のアルゴリズムは、情報値を各サイクル長に関連付けるマッピングテーブルを含む、請求項３２に記載の移動端末。
【請求項３４】
前記上位層はアプリケーション層である、請求項２９〜３３のいずれか一項に記載の移動端末。
【請求項３５】
前記アプリケーション層はインターネットプロトコル層を含む、請求項３４に記載の移動端末。
【請求項３６】
前記下位層はデータリンク層である、請求項２９〜３５のいずれか一項に記載の移動端末。
【請求項３７】
請求項２５に記載の基地局を少なくとも１つ含む通信ネットワーク内で使用される移動端末であって、
前記基地局から受信されるプロトコルスタックの下位層でのシグナリングから、サイクル長を決定するように構成された処理手段
を備える、移動端末。
【請求項３８】
請求項２６に記載の基地局を少なくとも１つ含む通信ネットワーク内で使用される移動端末であって、
前記基地局から受信されるプロトコルスタックの上位層でのシグナリングから、不連続送信および／または受信サイクル長を決定するように構成される処理手段
を備える、移動端末。
【請求項３９】
前記移動端末の前記処理手段は、前記移動端末がアイドルモードであるときに動作するように構成される、請求項２９〜３８のいずれか一項に記載の移動端末。
【請求項４０】
前記移動端末の前記処理手段は、前記移動端末がアクティブモードまたは接続モードであるときに動作するように構成される、請求項２９〜３８のいずれか一項に記載の移動端末。
【手続補正書】
【提出日】平成22年8月3日(2010.8.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
不連続受信および／または送信サイクル長を決定する方法であって、
プロトコルスタック内の上位層から、前記サイクル長に関連する情報を決定すること、
前記プロトコルスタック内の下位層に前記情報を提供すること、および
前記プロトコルスタックの前記下位層において、前記情報から前記サイクル長を決定すること
を含む、方法。
【請求項２】
前記サイクル長に関連する前記情報は、アプリケーション固有の情報を含む、請求項１に記載の方法。
【請求項３】
前記アプリケーション固有の情報は、オブジェクトタイプ、サービスタイプ、オブジェクトサイズ、ファイルサイズ、およびコーデックパラメータのうちの少なくとも１つを含む、請求項２に記載の方法。
【請求項４】
前記情報から前記サイクル長を決定するステップは、所定のアルゴリズムを使用することを含む、請求項１、２、または３に記載の方法。
【請求項５】
前記所定のアルゴリズムは、情報値を各サイクル長に関連付けるマッピングテーブルを含む、請求項４に記載の方法。
【請求項６】
基地局において実行される、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
移動端末でも実行される、請求項６に記載の方法。
【請求項８】
通信ネットワーク内で使用される基地局であって、
処理手段を備え、前記処理手段は、
前記基地局のプロトコルスタック内の上位層から、不連続送信および／または受信サイクル長に関連する情報を決定すること、
前記プロトコルスタック内の下位層に前記情報を提供すること、および
前記プロトコルスタックの前記下位層において、前記情報から前記サイクル長を決定すること
を行うように構成される、基地局。
【請求項９】
請求項８に記載の基地局を少なくとも１つ含む通信ネットワーク内で使用される移動端末であって、
処理手段を備え、前記処理手段は、
前記移動端末のプロトコルスタック内の上位層から、不連続送信および／または受信サイクル長に関連する情報を決定すること、
前記プロトコルスタック内の下位層に前記情報を提供すること、および
前記プロトコルスタックの前記下位層において、前記情報から前記サイクル長を決定すること
を行うように構成される、移動端末。
【国際調査報告】
2010538506.tif 000007
2010538506.tif 000008
2010538506.tif 000009