JP5348435B2 - ハンドオーバ後のターゲットセルにおける資源割当て - Google Patents

Description

本発明は、通信ノードが接続をソース基地局からターゲット基地局に変更した後の通信システムにおける資源の割当てに関する。本発明は、限定はしないが、特に、ハンドオーバ後のＵＴＲＡＮ（次世代汎用無線アクセスネットワーク（Evolved Universal Radio Access Network）（Ｅ−ＵＴＲＡＮ）とも呼ばれる）のロングタームエボリューション（ＬＴＥ）におけるＵＬ資源割当てに関連する。

移動通信ネットワークでは、ユーザ装置（ＵＥ）が１つの基地局から別の基地局へハンドオーバすることが要求される。ＬＴＥ内ハンドオーバ手順のためのシグナリングシーケンスが、３ＧＰＰ仕様書ＴＳ３６．３００に記載されており、その内容は参照により本明細書に援用される。

しかしながら、ターゲットセルにおける資源割当てに関する仕様は、いまだに詳細には検討されていない。当然、３Ｇ通信に適用可能な種々の頭字語は、当業者に既知であるが、専門外の読者に便宜を図るために、用語集が添付される。

当業者による理解を効率的にするために、本発明を３Ｇシステムの文脈の中で詳細に説明するが、ハンドオーバ手順の原理は、移動装置又はユーザ機器（ＵＥ）がいくつかの他の装置（ｅＮｏｄｅＢに相当する）のうちの１つと通信し、システムの対応する要素が必要に応じて変更される他のシステム、例えば他のＣＤＭＡシステム又は無線システムに適用可能である。

本発明の態様によれば、ソース通信ノードによって割り当てられる資源を用いて、アップリンクデータを前記ソース通信ノードに送信する手段と、前記ソース通信ノードからハンドオーバコマンドを受信する手段と、前記ハンドオーバコマンドを受信するとアップリンクデータをバッファリングする手段と、ターゲット通信ノードと同期する手段と、前記ターゲット通信ノードと同期した後に、バッファリングされたアップリンクデータの量を指示するバッファ状態報告と共に、ハンドオーバ完了メッセージを前記ターゲット通信ノードに送信する手段と、前記ターゲット通信ノードによって割り当てられる資源を用いて、前記ターゲット通信ノードにアップリンクデータを送信する手段と、を含む通信デバイスが提供される。

本発明の別の態様によれば、通信デバイスによって実行される方法であって、ソース通信ノードによって割り当てられる資源を用いて、アップリンクデータを前記ソース通信ノードに送信すること、前記ソース通信ノードからハンドオーバコマンドを受信すること、前記ハンドオーバコマンドを受信するとアップリンクデータをバッファリングすること、ターゲット通信ノードと同期すること、前記ターゲット通信ノードと同期した後に、バッファリングされたアップリンクデータの量を指示するバッファ状態報告と共に、ハンドオーバ完了メッセージを送信すること、前記ターゲット通信ノードによって割り当てられる資源を用いて、前記ターゲット通信ノードにアップリンクデータを送信すること、を含む、方法が提供される。

ハンドオーバ完了メッセージは、ＴＳ３６．３００標準規格において現在規定されているハンドオーバ確認メッセージと同じとしてもよく、又は、たとえば、バッファ状態報告が添付されるので、異なるメッセージとしてもよい。

本方法は、基地局間ハンドオーバ及び基地局内ハンドオーバの双方に用いることができる。

本発明のこれらの特徴及び態様、並びに他の特徴及び態様は、添付の図面を参照しながら説明される以下の例示的な実施形態から明らかになるであろう。

本発明の実施形態を適用可能なタイプの移動通信システムの概略図である。 図１に示されるシステムの一部を形成する基地局の概略図である。 図１に示されるシステムの一部を形成する移動通信デバイスの概略図である。 従来のハンドオーバ過程を示す図である。 従来のハンドオーバ過程を示す図である。 変更されたハンドオーバ過程を示す図である。 変更されたハンドオーバ過程を示す図である。

概説
図１は、移動（セルラー）通信システム１を概略的に示している。この移動通信システムでは、移動電話（ＭＴ）３−０、３−１及び３−２のユーザが、基地局５−１又は５−２のうちの一方及び電話網７を介して、他のユーザ（図示せず）と通信することができる。この実施形態では、ダウンリンク（ＤＬ）の場合、基地局５が、直交周波数分割多元接続（ＯＦＤＭＡ）技法を用いて移動電話３（３−０、３−１、３−２）にデータを送信し、アップリンク（ＵＬ）の場合、移動端末３が、シングルキャリア周波数分割多元接続（ＦＤＭＡ）技法を用いて基地局５（５−１、５−２）にデータを送信する。移動電話３が対応する帯域幅、及び移動電話３に送信する／移動電話３から送信されることになるデータの量に応じて、異なるサブキャリアが、基地局５によって各移動電話３に割り当てられる。移動電話３がソース基地局（たとえば、基地局５−１）のセルからターゲット基地局（たとえば、基地局５−２）に移動するとき、ソース基地局及びターゲット基地局５、並びに移動電話３において、ハンドオーバ（ＨＯ）手順（プロトコル）が実行され、ハンドオーバ過程が制御される。

時間／周波数資源
この実施形態では、利用可能な送信帯域が多数の部分帯域に分割され、各部分帯域は、連続するブロックに配列される多数の連続するサブキャリアを含む。異なる移動電話３は、そのデータを送信するために、異なる時刻において、１つの部分帯域内で異なる資源ブロック（サブキャリア）（複数可）を割り当てられる。

基地局
図２は、この実施形態において使用される基地局５のそれぞれの主要構成要素を示すブロック図である。図示のように、基地局５は、１つ又は複数のアンテナ２３を介して（上述したサブキャリアを使用して）携帯電話３と信号を送受信するように動作可能であると共に、ネットワークインタフェース２５を介して電話網７と信号を送受信するように動作可能である送受信回路２１を備える。コントローラ２７は、メモリ２９に格納されるソフトウエアに従って、送受信回路２１の動作を制御する。ソフトウエアは、特に、オペレーティングシステム３１、ダウンリンクスケジューラ３３及び資源割当てモジュール３４を含む。ダウンリンクスケジューラ３３は、移動電話３との通信において送受信回路２１が送信すべきユーザデータパケットをスケジュールするように動作可能である。資源割当てモジュール３４は、基地局５にアップリンクデータを送信するために移動電話３が用いるための周波数資源を割り当てるように動作可能である。ソフトウエアはハンドオーバモジュール３５も含み、その動作を以下に説明する。

移動電話
図３は、図１に示される各移動電話３の主要構成要素を概略的に示す。図に示されるように、移動電話３は、１つ又は複数のアンテナ７３を介して、基地局５と信号を送受信するように動作可能である送受信回路７１を備える。図に示されるように、移動電話３はコントローラ７５も備える。このコントローラは、移動電話３の動作を制御し、送受信回路７１に、さらにはスピーカ７７、マイクロフォン７９、ディスプレイ８１及びキーパッド８３に接続される。コントローラ７５は、メモリ８５に格納されるソフトウエア命令に従って動作する。図に示されるように、これらのソフトウエア命令は、特に、オペレーティングシステム８７を含む。この実施形態では、メモリは、アップリンクデータバッファ８９も提供する。ハンドオーバ過程を制御するソフトウエアは、ハンドオーバモジュール９１によって与えられ、その動作を以下に説明する。

上記の説明では、理解しやすくするために、基地局５及び移動電話３はいずれも、移動電話３がソース基地局からターゲット基地局に移動するときのハンドオーバ手順を制御する、それぞれの個別のハンドオーバモジュールを有するものとして説明される。このようにして、特定の用途の場合に、たとえば、既存のシステムが本発明を実施するように変更された場合にこれらの機能を提供することができるが、他の用途、たとえば、最初から本発明の特徴を念頭において設計されたシステムでは、ハンドオーバ機能がオペレーティングシステム又はコード全体の中に組み込まれる場合があるので、個別のエンティティとしてのハンドオーバモジュールは区別できない場合がある。これは、他のソフトウエアモジュールについても同じように当てはまる。

ハンドオーバ手順
ここで、ハンドオーバモジュール３５及び９１の動作に関する説明を提供する。以下の説明では、ＵＴＲＡＮのロングタームエボリューション（ＬＴＥ）で使用される用語を使用する。したがって、基地局５を変更している携帯電話３はＵＥと呼ばれ、ソース基地局５−１はソースｅＮｏｄｅＢと呼ばれ、ターゲット基地局５−２はターゲットｅＮｏｄｅＢと呼ばれる。

図４Ａ及び図４Ｂは、ｅＮｏｄｅＢ間ハンドオーバ（ＨＯ）手順のための制御プレーンのための現時点で合意しているシグナリングフローを示す。図に示されるように、そのシーケンスは以下のように進行する。

１．ＵＥが、ルールセットによって、すなわち、システム情報、仕様等によって、「測定報告」を送信するようにトリガされる。

２．ソースｅＮｏｄｅＢが、「測定報告」及びＲＲＭ（無線資源管理）情報に基づいて、ＵＥをターゲットｅＮｏｄｅＢにハンドオフするための判定を行なう。ソースｅＮｏｄｅＢは、ターゲットｅＮｏｄｅＢがハンドオーバすることができるように準備し、ハンドオーバ要求において関連する情報を渡す。関連する情報は、システムアーキテクチャエボリューション（ＳＡＥ）ベアラのＱｏＳプロファイルと、場合によっては、これらのベアラのアクセスストラタム（ＡＳ）構成（すなわち、ＲＬＣ、ＭＡＣ層構成）とを含む。

３．ターゲットｅＮｏｄｅＢが、Ｌ１／Ｌ２でＨＯの準備をし、セル内の各ＵＥを一意に特定するために用いられる新たな「セル無線ネットワーク一時識別子（Ｃ−ＲＮＴＩ）と、場合によっては、いくつかの他のパラメータ、すなわちアクセスパラメータ、「システム情報ブロック」（ＳＩＢ）等とを与えることによって、ソースｅＮｏｄｅＢに応答する。容認されたＨＯ準備を受信した後に、ソースｅＮｏｄｅＢは、ターゲットｅＮｏｄｅＢにユーザデータパケットを転送し始める。

４．ＵＥが、必要なパラメータ、たとえば、新たなＣ−ＲＮＴＩ、可能な開始時間、ターゲットｅＮｏｄｅＢ、ＳＩＢ等を有する「ハンドオーバ（ＨＯ）コマンド」を受信する。図４Ａ及び図４Ｂに示されないが、ＵＥは、ＲＬＣ肯定応答手順で、「ＨＯコマンド」の受信に肯定応答し得る。

５．「ＨＯコマンド」において規定される開始時間の満了後に、ＵＥは、そのアップリンク送信を中止し、ターゲットｅＮｏｄｅＢとの同期を実行し、その後、ＵＬタイミングアドバンス（ＴＡ）を捕捉し始める。

６．ターゲットｅＮｏｄｅＢが、ＵＬ割当て及びタイミングアドバンス情報で応答する。これらの情報は、ターゲットｅＮｏｄｅＢに「ハンドオーバ完了」メッセージを送信するためにＵＥによって用いられ、ターゲットｅＮｏｄｅＢは、そのＵＥのためのハンドオーバ手順を完了する。図示されないが、ターゲットｅＮｏｄｅＢは、ＲＬＣ肯定応答手順で、「ＨＯ完了」の受信に肯定応答し得る。

７ａ．ターゲットｅＮｏｄｅＢが、ソースｅＮｏｄｅＢにＨＯの成功を通知する。その後、ソースｅＮｏｄｅＢは、既に転送されているデータをそのバッファから消去することができる。ソースｅＮｏｄｅＢがそのバッファ内にいくつかのＵＥデータを有する場合、又はネットワークユーザプレーンエンティティ（ＵＰＥ）が依然としてソースｅＮｏｄｅＢにデータを転送している場合には、ソースｅＮｏｄｅＢは依然としてＵＥデータを転送し続ける。

７ｂ．ＵＰＥが適切なユーザパケットをターゲットｅＮｏｄｅＢに直に転送するように、ターゲットｅＮｏｄｅＢがネットワーク移動管理エンティティ（ＭＭＥ）／ＵＰＥへのＵＥ位置情報を更新する。

ハンドオーバ手順の詳細な検討
ソースｅＮｏｄｅＢから、ステップ４において「ＲＲＣハンドオーバコマンド」を受信すると、ＵＥにおいてハンドオーバ実行段階が始まる。「ハンドオーバコマンド」を受信すると、ＵＥはアップリンク送信を中止し、アップリンクパケットのバッファリングを開始し、古いセルから離脱し、ステップ５においてターゲットセルとの同期を試みる。

ＵＥがアップリンク同期を達成した後に、ターゲットｅＮｏｄｅＢは、「ハンドオーバ完了」メッセージを送信するためのアップリンク割当てで応答する。ＵＥは、ステップ６において「ハンドオーバ完了メッセージ」を送信し、これによってＵＥにおけるＨＯ手順が完了する。

ターゲットｅＮｏｄｅＢにおいて「ハンドオーバ完了メッセージ」が受信された後に、ターゲットｅＮｏｄｅＢは、ダウンリンクバッファの状態、及びソースｅＮｏｄｅＢから受信した（ソースｅＮｏｄｅＢによってＵＥに提供されていたサービスを特定する）ＱｏＳパラメータに基づいて、ダウンリンクＵ−プレーンデータのための資源の適切な割当てを行なう。ターゲットｅＮｏｄｅＢは、ＵＥのためのアップリンクＵ−プレーン資源を割り当てなければならない。ターゲットｅＮｏｄｅＢは、ＵＥ内のアップリンクバッファ状態の推測及びＱｏＳパラメータに基づいて、これを果たすことができる。しかしながら、ハンドオーバ直後のターゲットセル内でのそのようなアップリンクＵ−プレーン資源割当ては、ＵＥがターゲットセルとの同期を試みている間にいかなるＵＬ送信も実行できなかったことを考えると、次善であろう。ＵＥがアップリンクデータを送信できない時間中に、ＵＥは、その内部バッファ８９内にそのデータをバッファリングする。ＵＥがアップリンクデータをターゲットｅＮｏｄｅＢに送信することができる時間までに、アップリンクバッファ８９内に大量のアップリンクデータパケットが入っている場合がある。ＵＥが、そのバッファのレベルを迅速に下げることができるように、ターゲットｅＮｏｄｅＢは、このアップリンクＵ−プレーンデータのために、ターゲットセル内の十分な資源を割り当てなければならない。

上記のハンドオーバ実行手順は、ｅＮｏｄｅＢ間ハンドオーバのシナリオのための手順であるが、ＵＬにおけるスケジューリング及び資源割当てに関する限り、ｅＮｏｄｅＢ内ハンドオーバの場合にも同じく当てはまる。

要求されるアップリンク資源需要を推測することに対する一代替形態として、ターゲットｅＮｏｄｅＢは、ＵＥによってソースｅＮｏｄｅＢに送信された最後のバッファ状態報告及びＱｏＳパラメータに基づいて、ＵＥへの初期割当てを行なうことができる。その後、ＵＥは、アップリンク送信の休止に起因して上昇したバッファレベルを下げるために、アップリンクバッファ状態報告を送信することによって、付加的なアップリンク資源を要求することができる。しかしながら、このためには、ソースｅＮｏｄｅＢが、ＵＥ毎の最新のアップリンクバッファ状態報告を格納し、ハンドオーバ手順中に、それをターゲットｅＮｏｄｅＢに転送しなければならない。

それゆえ、好ましい実施形態では、ＵＥが「ハンドオーバ完了」メッセージを送信するときに、そのメッセージに直前のアップリンクバッファ状態報告を添付するように、上記のハンドオーバ手順がわずかに変更される。その際、ターゲットｅＮｏｄｅＢは、この情報を用いて、ＵＥによって必要とされる、要求されるアップリンク資源を正確に割り当てることができる。この変更されたハンドオーバ手順は図５Ａ及び図５Ｂに示されており、先に検討された他の技法よりも優れた数多くの利点を有する。

１．ｅＮｏｄｅＢ間ハンドオーバの場合、ソースｅＮｏｄｅＢは、ＵＥ毎に最新のＵＬバッファ状態報告を格納し、それをターゲットｅＮｏｄｅＢに転送する必要はない。この結果として、ｅＮｏｄｅＢにおけるメモリ要件が緩和され、ｅＮｏｄｅＢ間のＸ２インタフェース上のシグナリング負荷が軽減される。

２．ｅＮｏｄｅＢ内ハンドオーバの場合、バッファ状態報告が、格納されてソースからターゲットセルＵＬスケジューリングエンティティに転送される必要はない。

３．アップリンク資源の正確な割当てがハンドオーバ直後に実行されるので、ＵＥが、さらに多くの資源を要求する必要はなく、結果としてＬ２シグナリングオーバヘッドが低減される。

変更及び代替
上記において詳細な一実施形態を説明した。本明細書において具現される本発明から利益を依然として享受しながら、上記の実施形態に対する数多くの変更及び代替を実施することができることは、当業者には理解されよう。例示にすぎないが、ここで、数多くのこれらの代替及び変更を説明する。

上記の実施形態では、移動電話に基づく通信システムを説明した。任意の通信システムにおいて、本出願において記載されるハンドオーバ技法を利用することができることは当業者には理解されよう。詳細には、電磁信号又は音響信号のいずれかを用いてデータを搬送する有線又は無線系通信システムにおいて、これらのハンドオーバ技法の多くを用いることができる。一般的な場合には、基地局及び移動電話は、互いに通信する通信ノード又は通信デバイスと見なすことができる。ｅＮｏｄｅＢ内ハンドオーバでは、ソース通信ノード及びターゲット通信ノードは、１つの基地局内の個別のスケジューリングエンティティによって形成されるであろう。他の通信ノード又は通信デバイスは、たとえば、携帯情報端末、ラップトップコンピュータ、ウェブブラウザ等のユーザデバイスを含むことがある。

上記の実施形態では、多数のソフトウエアモジュールを説明した。それらのソフトウエアモジュールは、コンパイルされた形で又はコンパイルされていない形で提供することができ、コンピュータネットワークを介する信号として又は記録媒体上で基地局又は移動電話に供給されることができることは、当業者には理解されよう。さらに、このソフトウエアの一部又は全体によって実行される機能は、１つ又は複数の専用のハードウエア回路を用いて実行されてもよい。しかしながら、ソフトウエアであれば基地局５及び移動電話３を更新するのが容易であるので、その機能を更新するために、ソフトウエアモジュールを使用することが好ましい。

３ＧＰＰ用語集
ＬＴＥ−（ＵＴＲＡＮの）ロングタームエボリューション
ｅＮｏｄｅＢ−Ｅ−ＵＴＲＡＮノードＢ
ＵＥ−ユーザ機器−移動通信デバイス
ＤＬ−ダウンリンク−基地局から移動装置へのリンク
ＵＬ−アップリンク−移動装置から基地局へのリンク
ＭＭＥ−モビリティ管理エンティティ
ＵＰＥ−ユーザプレーンエンティティ
ＨＯ−ハンドオーバ
ＲＬＣ−無線リンク制御
ＲＲＣ−無線資源制御
ＲＲＭ−無線資源管理
ＳＡＥ−システムアーキテクチャエボリューション
Ｃ−ＲＮＴＩ−セル無線ネットワーク一時識別子
ＳＩＢ−システム情報ブロック
Ｕプレーン−ユーザプレーン
Ｘ２インタフェース−２つのｅＮｏｄｅＢ間のインタフェース

以下は、本発明を現在提案されている３ＧＰＰ ＬＴＥ標準規格において実施することができる方法の詳細な説明である。種々の特徴が重要又は必要であるとして説明されるが、これは、例えば、標準規格によって課される他の要件に起因して、提案されている３ＧＰＰ ＬＴＥ標準規格に対しての場合のみであり得る。したがって、これらの記載は本発明を制限するものとして決して解釈されるべきではない。

序論
ＬＴＥ内ハンドオーバ手順のためのシグナリングシーケンスがＴＳ３６．３００において獲得されているが、ターゲットセル内の資源割当てに関する仕様は、いまだに詳細には検討されていない。この提案では、本発明者は、ハンドオーバ及びＵＬバッファ状態報告の処理後の、ターゲットセルにおけるＵＬ資源割当てに関するいくつかのさらに細かい事柄を検討する。

検討
移動性に関する「通常の」シグナリングフローを調査すると、ハンドオーバ手順は、無線状態が変化すること、ＵＥが測定報告を送信すること、ネットワークが判定を行いターゲットセルを準備すること、ネットワークがＵＥにセルを変更するように指示すること、ＵＥがＬ１を再構成してターゲットセルに同期すること、データが送信されてターゲットセルにおいて受信されること、及びソースセル内の資源が解放されることから成ることを確認することができる。

ｅＮｏｄｅＢ間ハンドオーバ手順の場合に合意した制御プレーンのためのシグナリングフローを概括し、さらに検討するための基礎として用いる。シグナリングシーケンスのための草案Ｓｔａｇｅ２ＴＳからの記載も含まれる。

以下はＭＭＥ／ＵＰＥ間ＨＯ手順のさらに詳細な説明である。

１．ＵＥが、ルールセットによって、すなわち、システム情報、仕様等によって、「測定報告」を送信するようにトリガされる。

２．ソースｅＮＢが、「測定報告」及びＲＲＭ情報に基づいて、ＵＥをハンドオフするための判定を行なう。ソースｅＮＢは、ターゲットｅＮＢがハンドオーバすることができるように準備し、「ハンドオーバ要求」において関連する情報を渡す。関連する情報は、ＳＡＥベアラのＱｏＳプロファイルと、場合によっては、これらのベアラのＡＳ構成（ＦＦＳ）とを含む。

３．ターゲットｅＮＢが、Ｌ１／Ｌ２でＨＯの準備をし、新たなＣ−ＲＮＴＩと、場合によっては、いくつかの他のパラメータ、すなわちアクセスパラメータ、ＳＩＢ等とを与えることによって、ソースｅＮＢに応答する。容認されたＨＯ準備を受信した後に、ソースｅＮＢは、ターゲットｅＮＢにユーザデータパケットを転送し始める。

４．ＵＥが、必要なパラメータ、すなわち、新たなＣ−ＲＮＴＩ、可能な開始時間、ターゲットｅＮＢ、ＳＩＢ等を有する「ハンドオーバコマンド」を受信する。ＵＥは、ＲＬＣ肯定応答手順で、「ＨＯコマンド」の受信に肯定応答する必要があり得る。

５．「ＨＯコマンド」内の開始時間の満了後に、ＵＥは、ターゲットｅＮＢとの同期を実行し、その後、ＵＬタイミングアドバンスを捕捉し始める。

６．ネットワークが、ＵＬ割当て及びタイミングアドバンスで応答する。これらは、ターゲットｅＮＢに「ハンドオーバ完了」を送信するためにＵＥによって用いられ、ターゲットｅＮＢは、そのＵＥのためのハンドオーバ手順を完了する。ＮＷは、ＲＬＣ肯定応答手順で、「ＨＯ完了」の受信に肯定応答する必要があり得る。

７ａ．ターゲットｅＮＢはソースｅＮＢにＨＯの成功を通知する。その後、ソースｅＮＢは、既に転送されているデータをそのバッファから消去することができる。ソースｅＮＢが、そのバッファ内にいくつかのＵＥデータを有する場合、又はＵＰＥが依然としてソースｅＮＢにデータを転送している場合には、ソースｅＮＢは依然としてＵＥデータを転送し続ける。

７ｂ．ＵＰＥがターゲットｅＮＢに直にパケットを転送することを可能にするために、ＭＭＥ／ＵＰＥへのＵＥ位置情報が更新される。

４．１ハンドオーバ実行手順の詳細な検討
ソースｅＮｏｄｅＢから、ステップ４において「ＲＲＣハンドオーバコマンド」を受信すると、ＵＥにおいてハンドオーバ実行段階が始まる。「ハンドオーバコマンド」を受信すると、ＵＥはＵＬ送信を中止し、ＵＬパケットのバッファリングを開始し、古いセルから離脱し、ステップ５においてターゲットセルとの同期を試みることになっている。

ＵＥがＵＬ同期を達成した後に、ｅＮｏｄｅＢは、「ハンドオーバ完了メッセージ」を送信するためのＵＬ割当てで応答する。ＵＥは、ステップ６において「ハンドオーバ完了メッセージ」を送信することになっており、これによってＵＥにおけるＨＯ手順が完了する。

ターゲットｅＮｏｄｅＢにおいて「ハンドオーバ完了メッセージ」が受信された後に、ターゲットｅＮｏｄｅＢは、ＤＬバッファの状態、及びソースｅＮｏｄｅＢから受信したＱｏＳパラメータに基づいて、ＤＬ−Ｕプレーンデータのための資源を適切に割り当てることになっている。しかしながら、ＵＬ−Ｕプレーンデータの場合、ターゲットｅＮｏｄｅＢは、ＵＥ内のＵＬのバッファ状態の推測及びＱｏＳパラメータに基づいて、資源を割り当てることができる。ＨＯ直後のターゲットセル内でのそのようなＵＬ−Ｕプレーン資源割当ては、ＵＥがターゲットセルとの同期を試みている間にいかなるＵＬ送信も実行できなかったことを考えると、次善であろう。これによって、大量のＵＬデータパケットが、ハンドオーバ実行段階中にＵＥ内にバッファリングされる可能性があり、ターゲットセルにおいてＵＬ−Ｕプレーンデータのために十分な量の資源を割り当てることによって、バッファレベルが迅速に下げられる必要がある。

上記のハンドオーバ実行手順は、ｅＮＢ間ハンドオーバのシナリオのための手順であるが、ＵＬにおけるスケジューリング及び資源割当てに関する限り、ｅＮＢ内ハンドオーバの場合にも同じく当てはまる。

４．２．ＨＯ後のＵＬにおける資源割当て
上記の態様を考えると、ハンドオーバ実行段階直後に、Ｕ−プレーンデータのために適した量のＵＬ資源がターゲットセルにおいて割り当てられる必要がある。これを果たすために取り得る方法は、以下に説明する２ステップ手法又は１ステップ手法のいずれかを有することである。

２ステップ手法
ステップ１：最初に、ソースセルにおいてＵＥによって送信された最後のバッファ状態報告及びＱｏＳパラメータに基づいて、ターゲットセルにおいてＵＬ資源が割り当てられる。

ステップ２：その後ＵＥが、ＵＬ送信の休止に起因して上昇したバッファレベルを下げるためにＵＬバッファ状態報告を後に送信することによって、付加的なＵＬ資源を要求することになっている。

１ステップ手法
ステップ１：ＵＥが、「ハンドオーバ完了メッセージ」と共にＵＬバッファ状態報告を送信し、それに応じて、ｅＮＢがＵＬ資源を割り当てる。

２つの手法を比較すると、本発明者は、１ステップ手法が２ステップ手法よりも大きな利点を有するものと考える。

１ステップ手法によれば、以下の利点が確認される。

１．ｅＮｏｄｅＢ間ＨＯの場合、ソースｅＮｏｄｅＢは、ＵＥ毎に最新のＵＬバッファ状態報告を格納し、ｅＮｏｄｅＢ間ハンドオーバ中に、それをターゲットｅＮｏｄｅＢに転送する必要はない。この結果として、メモリ要件が緩和され、Ｘ２インタフェース上のシグナリング負荷が軽減されるであろう。

２．ｅＮＢ内ハンドオーバの場合も同様に、バッファ状態報告が、格納されてソースからターゲットセルＵＬスケジューリングエンティティに転送される必要はない。

３．アップリンク資源の正確な割当てがハンドオーバ直後に実行されるので、ＵＥが、さらに多くの資源を要求する必要はなく、結果としてＬ２シグナリングオーバヘッドが低減される。

結論
本明細書において、本発明者は、ハンドオーバ実行段階を詳細に検討し、ＵＬバッファ状態報告の処理及びターゲットセルにおけるＵＬ資源割当てを提案する。

ハンドオーバ実行段階の始めに（すなわち、ハンドオーバコマンドを受信すると）、ＵＥはＵＬ送信を中止し、ターゲットセルとの同期を試みる。ＵＥ内のバッファは、ターゲットセルにおけるＨＯ後に、ＵＥがＵＬ許可を受信するまで、データパケットを蓄積し続けるであろう。ＵＬ送信の休止に起因して上昇したバッファレベルが迅速に下げられるように、ネットワークはターゲットセル内のＵＬ資源を正確に割り当てる必要がある。

ターゲットセルにおいてＵＬ資源割当てを最適にするために、本発明者は、ＵＥによってハンドオーバ完了メッセージと共にＵＬバッファ状態報告が送信されることを提案する。これは、最新のＵＬバッファ状態報告を格納すること、及びハンドオーバ中に、それをターゲットセル／ｅＮｏｄｅＢ ＭＡＣエンティティに転送することを不要にするであろう。

ここでの検討からの重要な点を取り入れて、本明細書からＴＳ３６．３００の中に含めることを提案する。

本願は、２００７年２月５日に出願された英国特許出願第０７０２１６９．４号に基づいており、当該出願からの優先権の利益を主張するものであり、この特許出願の開示はその全体が参照により本明細書に援用される。

Claims (9)

1. ソース通信ノードによって割り当てられる資源を用いて、アップリンクデータを前記ソース通信ノードに送信する手段と、
   前記ソース通信ノードからハンドオーバコマンドを受信する手段と、
   前記ハンドオーバコマンドを受信するとアップリンクデータをバッファリングする手段と、
   ターゲット通信ノードと同期する手段と、
   前記ターゲット通信ノードと同期した後に、バッファリングされたアップリンクデータの量を指示するバッファ状態報告と共に、ハンドオーバ完了メッセージを前記ターゲット通信ノードに送信する手段と、
   前記ターゲット通信ノードによって割り当てられる資源を用いて、前記ターゲット通信ノードにアップリンクデータを送信する手段と、
   を含む通信デバイス。
2. 前記アップリンクデータを送信する手段は、バッファリングされるデータレベルを低減するために、前記ソース通信ノードにアップリンクデータを送信するために用いる資源よりも多くの前記資源を、前記ターゲット通信ノードにアップリンクデータを送信するために使用する、請求項１に記載の通信デバイス。
3. ハンドオーバコマンドを受信する手段により受信される前記ハンドオーバコマンドは、基地局内ハンドオーバを始めるためのものである、請求項１又は２に記載の通信デバイス。
4. 通信デバイスによって実行される方法であって、
   ソース通信ノードによって割り当てられる資源を用いて、アップリンクデータを前記ソース通信ノードに送信すること、
   前記ソース通信ノードからハンドオーバコマンドを受信すること、
   前記ハンドオーバコマンドを受信するとアップリンクデータをバッファリングすること、
   ターゲット通信ノードと同期すること、
   前記ターゲット通信ノードと同期した後に、バッファリングされたアップリンクデータの量を指示するバッファ状態報告と共に、ハンドオーバ完了メッセージを送信すること、
   前記ターゲット通信ノードによって割り当てられる資源を用いて、前記ターゲット通信ノードにアップリンクデータを送信すること、
   を含む、方法。
5. 前記アップリンクデータを送信するステップは、バッファリングされるデータレベルを低減するために、前記ソース通信ノードにアップリンクデータを送信するステップにおいて用いられる資源よりも多くの前記資源を、前記ターゲット通信ノードにアップリンクデータを送信するために使用する、請求項４に記載の方法。
6. 基地局内ハンドオーバの間に実行される、請求項４又は５に記載の方法。
7. 通信デバイスから、前記通信デバイスにおいてハンドオーバコマンドの受信に応じてバッファリングされたアップリンクデータの量を指示するバッファ状態報告と共に、ハンドオーバ完了メッセージを受信する手段と、
   前記通信デバイスから、前記バッファリングされたアップリンクデータを受信する手段と、を含むターゲット通信ノード。
8. ターゲット通信ノードにより実行される方法であって、通信デバイスから、前記通信デバイスにおいてハンドオーバコマンドの受信に応じてバッファリングされたアップリンクデータの量を指示するバッファ状態報告と共に、ハンドオーバ完了メッセージを受信すること、
   前記通信デバイスから、前記バッファリングされたアップリンクデータを受信すること、を含むターゲット通信ノードにより実行される方法。
9. コンピュータに、請求項４〜６、８のいずれか１項に記載の方法を実現させるためのプログラム。
   

Images