(57)【要約】本発明の一態様によれば、無線通信ネットワークにおいてソースノードからターゲットノードに移動端末をハンドオーバするための方法は、ＲＬＣ−ＵＭベアラ又はＲＬＣ−ＡＭベアラを使用し得るＲＬＣモードにオプションとして関係なく、新たなデータのデータ転送を行うステップを含む。この方法は、ベアラがデータ転送の対象であるのかどうかについて、各ベアラについての移動端末に明瞭な命令を与えるステップを含むことができる。次いでこの命令は、バッファされるパケット及びＰＤＣＰ  ＳＮを処理するために移動端末によって使用され得る。
2010536291.tif 000002
【特許請求の範囲】
【請求項１】
無線通信ネットワークにおいてソースノードからターゲットノードに移動端末をハンドオーバするための方法であって、
前記ソースノードから前記ターゲットノードにデータを転送するかどうかについての決定を行うステップであって、各無線ベアラについての前記決定は、前記ベアラがどの無線リンク制御（ＲＬＣ）モードをサポートするのかに関係なく行われる、決定を行うステップ
を含む方法。
【請求項２】
請求項１に記載の方法であって、前記データを転送するかどうかについての前記決定を行う際に、ラストマイルのパフォーマンスを使用するステップを含む方法。
【請求項３】
請求項１又は２のいずれか１項に記載の方法であって、前記データを転送するかどうかについての前記決定を行う際に、前記移動端末の移動率を使用するステップを含む方法。
【請求項４】
請求項１、２、又は３のいずれか１項に記載の方法であって、データ転送を使用しないと決定する場合、ＰＤＣＰ（パケットデータコンバージェンスプロトコル）ＳＮ（順序番号）をリセットする、方法。
【請求項５】
請求項１、２、３、又は４のいずれか１項に記載の方法であって、ベアラがデータ転送の対象であるのかどうかについて、各ベアラについての前記移動端末に命令を与える、方法。
【請求項６】
請求項５に記載の方法であって、前記命令がハンドオーバ命令メッセージの一部として含まれる、方法。
【請求項７】
請求項１乃至６のいずれか１項に記載の方法であって、前記ターゲットノードにデータを転送しないと決定する場合、前記ＰＤＣＰ順序番号を知られている値で再スタートし、最後に使用されるＰＤＣＰ  ＳＮを前記ターゲットノードに転送しない、方法。
【請求項８】
請求項１乃至７のいずれか１項に記載され、ロングタームエボリューション、ＬＴＥ標準に従って実施される方法。
【請求項９】
無線通信ネットワークにおいてソースノードからターゲットノードに移動端末をハンドオーバするための方法であって、ＲＬＣ−ＵＭモードの無線ベアラに関して前記ソースノードから前記ターゲットノードにデータを転送するステップを含む方法。
【請求項１０】
無線通信ネットワークにおいてソースノードからターゲットノードに移動端末をハンドオーバするための方法であって、ＲＬＣ−ＡＭモードの無線ベアラに関して前記ソースノードから前記ターゲットノードにデータを転送しないステップを含む方法。
【請求項１１】
請求項１乃至１０のいずれか１項に記載される前記方法を実施するように構成される無線通信ネットワーク。
【請求項１２】
無線通信ネットワーク用の意思決定装置であって、情報記憶装置と、前記情報記憶装置から情報を受け取り、ハンドオーバ中にソースノードからターゲットノードにデータを転送するかどうかを決定するために前記情報を使用するように構成される決定プロセッサであって、各無線ベアラについての前記決定は、前記ベアラがどの無線リンク制御（ＲＬＣ）モードをサポートするのかに関係なく行われる、決定プロセッサとを備える意思決定装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信ネットワークにおけるハンドオーバのための方法及び機器に関し、より詳細には３ＧＰＰ（第３世代パートナーシッププロジェクト）Ｅ−ＵＴＲＡＮ（進化型ユニバーサル陸上無線アクセスネットワーク）及びＥ−ＵＴＲＡ（進化型ユニバーサル陸上無線アクセス）規格に従って実施される方法及び機器に関するがそれだけに限られない。
【背景技術】
【０００２】
現在、３ＧＰＰは、参照により本明細書に組み込まれる技術仕様３ＧＰＰ  ＴＳ  ３６．３００  ｖ８．１．０（２００７−０６）及び関連文書に提示されるＥ−ＵＴＲＡ及びＥ−ＵＴＲＡＮの発展を検討している。３ＧＰＰ  ＬＴＥ（ロングタームエボリューション）は、例えば効率やサービスを改善することにより、ＵＭＴＳ（ユニバーサル移動通信システム）標準を向上させることを目標とする。
【０００３】
Ｅ−ＵＴＲＡＮでは、データがＵＥ（ユーザ機器）とネットワークノードｅＮＢ（ＮｏｄｅＢ）との間の無線リンク上のＲＢ（無線ベアラ）上で送信される状態で、ＵＥはｅＮＢと通信する。このｅＮＢは、Ｓ１と称されるインターフェースを介してＭＭＥ／ＳＡＥ  ＧＷ（移動管理エンティティ／システムアーキテクチャエボリューションゲートウェイ）とインターフェースする。Ｅ−ＵＴＲＡＮネットワークは、複数のｅＮＢ及びＭＭＥ／ＳＡＥ  ＧＷを含む。
【０００４】
ＬＴＥでは、すべてのＲＡＮ（無線アクセスネットワーク）機能が各ノード、ｅＮＢに統合される。ダウンリンク・ユーザデータ、つまりＩＰ（インターネット・プロトコル）パケットは、ＳＡＥ  ＧＷからｅＮＢに伝送される。ＵＥが第１のソースｅＮＢから第２のターゲットｅＮＢにハンドオーバされる際、ＳＡＥ  ＧＷはこの第２のｅＮＢのアドレスで更新され、そのターゲットｅＮＢへのデータの送信を開始する。
【０００５】
しかしデータ損失を避けるため、ソースｅＮＢ内で既にバッファされている任意のデータはターゲットｅＮＢに転送されなければならない。さらに、ＳＡＥ  ＧＷが新たなｅＮＢのアドレスで更新される前にＨＯ（ハンドオーバ）手順中にソースｅＮＢに送信されているデータも、ソースｅＮＢによりターゲットｅＮＢに転送される。
【０００６】
ＵＥに送信されるパケットの順番を保つために、ターゲットｅＮＢはＳＡＥ  ＧＷによって送信されるのと同じ順番で無線を介してデータを送信することを目指す必要がある。つまり、まずｅＮＢによってバッファされるデータがターゲットｅＮＢに送信され、その後にＨＯ手順中にＳＡＥ  ＧＷから伝送中のデータが続き、これらすべてが送信されたときにだけ、ターゲットｅＮＢはＳＡＥ  ＧＷから直接受信する新たなデータをＵＥに送信すべきである。
【０００７】
図１に、ＵＥ１に適用されるＨＯ手順に関するメッセージフローを示し、この図はソースｅＮＢ２、ターゲットｅＮＢ３、及びＭＭＥ／ＳＡＥ  ＧＷ４を含むネットワークを示す。ソースｅＮＢ２がＵＥ１からの測定報告に基づいてハンドオーバの決定を行うと、ソースｅＮＢ２はハンドオーバ要求メッセージをターゲットｅＮＢ３に送信する。許可制御ステップ５で、ターゲットｅＮＢ３は要求される資源を構成し、ハンドオーバ要求肯定応答メッセージをソースｅＮＢ２に送信する。ソースｅＮＢ２からＵＥ１へのハンドオーバ命令の後に、ＵＥ１は旧セルから離脱し、ターゲットｅＮＢ３に関連する新たなセルに同期する。さらに、ソースｅＮＢ２においてバッファされるデータパケット及び伝送中の任意のデータパケットが、Ｘ２と称されるインターフェースを介してターゲットｅＮＢ３に転送される。ステップ１０でのＵＥ１からターゲットｅＮＢ３へのハンドオーバ確認メッセージに続き、ハンドオーバ完了メッセージがターゲットｅＮＢ３によりＭＭＥ／ＳＡＥ  ＧＷ４に送信される。ソースｅＮＢ２からのデータパケットは引き続きターゲットｅＮＢ３に送られる。ソースｅＮＢ２から転送されるすべてのデータをこのターゲットｅＮＢが受信すると、その後このターゲットｅＮＢはＭＭＥ／ＳＡＥ  ＧＷからＳ１を介して届く新たなデータを送信することができる。
【０００８】
ソースｅＮＢからターゲットｅＮＢに転送されるデータはＬＴＥでは２つの形式をとり得る。それは、ソースｅＮＢにおいてバッファされるデータの転送と、ソースｅＮＢにおいて新たに届くパケットのＳ１を介した転送とである。無損失ＨＯは、これらのタイプのデータの両方がソースｅＮＢからターゲットｅＮＢに転送されることを要求する。３ＧＰＰ  ＲＡＮ２は、無損失のｅＮＢ間ハンドオーバを行うためのデータ転送原則を議論し、同意している。しかし、無損失ＨＯを適用すべき場合の条件は今のところ議論されていない。
【０００９】
ＵＥにＨＯ命令が送られる前にソースｅＮＢにおいて受信されるすべてのデータが「バッファされた」データとみなされ、従ってＰＤＣＰ（パケットデータコンバージェンスプロトコル）ＳＮ（順序番号）が割り当てられているとは仮定できない。入力パケットには、入力パケットがこのｅＮＢによって受信されるや否やＰＤＣＰ  ＳＮを与えることができ、或いはＰＤＣＰ  ＳＮは、ＵＥへの送出の直前にほぼリアルタイムで与えることができる。最後に使用されるＰＤＣＰ  ＳＮが正しく使用される限り、ＵＥに実際に送信されていないどんなパケットも、Ｓ１を介した新たなデータとして扱うことができる。
【００１０】
バッファされるパケットの転送は、ＲＬＣ（無線リンク制御）状態報告に基づいて行われるべきことも３ＧＰＰ  ＲＡＮ２によって合意された。ＲＬＣ状態報告は、ＲＬＣ−ＡＭ（ＲＬＣ承認モード）が無線ベアラに関して選択されている場合に提供される。このＡＭ（承認モード）は、例えば誤った又は失われたデータパケットを再伝送することを可能にし、非リアルタイム・サービスに適しているので信頼性の向上をもたらす。
【００１１】
ＲＬＣ−ＵＭ（ＲＬＣ不承認モード）では再伝送プロトコルは使用されず、ＲＬＣ状態報告がなく、従ってＲＬＣ−ＵＭに関してデータ転送は想定されていない。この不承認モードは、例えば特定のＲＲＣ（無線資源制御）シグナリングやＶｏＩＰ（ボイスオーバＩＰ）で使用することができる。どちらのＲＬＣモードをとるのかについての選択は、そのベアラに要求される見逃しビット誤り率（ＢＥＲ）及びＨＡＲＱ（ハイブリッド自動再送要求）の動作点に基づく。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】３ＧＰＰ  ＴＳ  ３６．３００  ｖ８．１．０（２００７−０６）
【発明の概要】
【課題を解決するための手段】
【００１３】
本発明の第１の態様によれば、無線通信ネットワークにおいてソースノードからターゲットノードに移動端末をハンドオーバするための方法は、ソースノードからターゲットノードにデータを転送するかどうかについての決定を行うステップであって、各無線ベアラについての決定は、そのベアラがどの無線リンク制御（ＲＬＣ）モードをサポートするのかに関係なく行われる、決定を行うステップを含む。従って本発明による方法では、データ転送はＲＬＣ−ＵＭベアラが使用されようがＲＬＣ−ＡＭベアラが使用されようが関係なく選択でき、無線ベアラごとに選択することができる。これはＲＬＣモードに依存しない柔軟性を提供する。この方法はロングタームエボリューション、ＬＴＥ標準に従って実装されるネットワークに適用できるが、他のタイプのネットワークでも使用することができる。
【００１４】
本発明による方法では、データ転送を実施するかどうかの選択は、そのベアラのＱｏＳ（サービス品質）要件を基準として、並びに例えば費用及び／又は速度など、ラストマイルのパフォーマンスに基づいて決定することができる。データ転送は無線ベアラのＱｏＳ要件を考慮に入れてベアラごとに選択することができるが、必須ではなく、それはデータを転送することを選択する理由は例えばＳ１及びＸ２の遅延量を代わりに又は加えて含み得るためである。例えば、Ｘ２に関するラストマイルトポロジがＳ１基準点に達する場合、データを転送することは事業者にとって高くつき、且つ遅くなる。事業者はこれらの場合についてはデータ転送を使用しないと決めることができる。さらにＵＥの移動率も、データを転送するかどうかについての決定に影響を与え得る。遅く移動するＵＥに対しては、データ転送を実施する価値はない可能性がある。従ってＲＬＣ−ＡＭにとってさえ、このような状況に関してはデータ転送が回避され得る。
【００１５】
Ｓ１リンク又はＭＭＥ  Ｓ−ＧＷリンクが遅い場合、経路切替えが著しく遅れる可能性があり、従ってたとえモードがＲＬＣ−ＵＭであっても、Ｓ１を介してソースノードによって受信される新たな、即ち関連するＳＮのないデータとみなされるパケットを転送することが望ましいことがある。
【００１６】
本発明による別の方法によれば、データ転送を使用しないと決定する場合、どのＲＬＣモードが使用されるのかに関係なくＰＤＣＰ（パケットデータコンバージェンスプロトコル）ＳＮ（順序番号）がリセットされる。
【００１７】
本発明による方法は、ベアラがデータ転送の対象であるのかどうかについて、各ベアラについての移動端末に命令を与えるステップを含むことができる。次いでこの命令は、バッファされるパケット及びＰＤＣＰ  ＳＮを処理するために移動端末によって使用され得る。この命令は、例えばハンドオーバ命令の一部として又は別個のメッセージとして含まれ得る。
【００１８】
以前は、ＲＬＣ−ＡＭではＨＯの後にＰＤＣＰ順序番号がターゲットノードに継続された。これは再順序付け及び無線上のパケット重複を特定するために必須であるとみなされていた。このため、バッファされるパケットの最後に使用されるＰＤＣＰ  ＳＮ及び最後に使用されるＰＤＣＰ  ＳＮが、ソースノードによりターゲットノードに転送された。本発明による方法では、対照的にターゲットノードにデータを転送しないと決定する場合、ＰＤＣＰ順序番号が知られている値で再スタートされ、最後に使用されるＰＤＣＰ  ＳＮはターゲットノードに転送されない。ソースノードとターゲットノードとの間のＸ２インターフェースがＳ１インターフェースに比べて遅い場合、ターゲットノードにＰＤＣＰ  ＳＮ情報を転送することは、ターゲットノードがこのＳＮを待ってからＳ１を介して直接受信する任意の新たなデータを送信しなければならないため、中断時間を増加させる可能性がある。ＰＤＣＰ  ＳＮを再スタートさせることにより、この潜在的中断を回避することができる。
【００１９】
本発明による別の方法によれば、ＲＬＣ−ＵＭではターゲットノードにＰＤＣＰ  ＳＮを転送する必要はなく、ＰＤＣＰ  ＳＮは単純に再スタートされる。
【００２０】
本発明による方法によれば、移動端末はＰＤＣＰがリセットされるべきか継続されるべきかを知る必要があるため、このことを移動端末にシグナリングするための機構が含まれる。データ転送が実施されない場合にＰＤＣＰ  ＳＮが再スタートするように構成される場合、どのＲＬＣモードが使用されていようともＰＤＣＰがリセットされるべきであることを移動端末に知らせるように、データ転送が使用されていないことをその移動端末に信号で伝えることができる。さらに、ベアラがデータ転送の対象でないことを移動端末に指示することは、その移動端末が任意のバッファされるパケットを直ちに上位層に送ることを可能にする。移動端末は、ＰＤＣＰ  ＳＮを知られている値に再初期化することもできる。
【００２１】
本発明の第２の態様によれば、無線通信ネットワークにおいてソースノードからターゲットノードに移動端末をハンドオーバするための方法は、ＲＬＣ−ＵＭモードの無線ベアラに関してソースノードからターゲットノードにデータを転送するステップを含む。
【００２２】
本発明の第３の態様によれば、無線通信ネットワークにおいてソースノードからターゲットノードに移動端末をハンドオーバするための方法は、ＲＬＣ−ＡＭモードの無線ベアラに関してソースノードからターゲットノードにデータを転送しないステップを含む。
【００２３】
本発明の第４の態様によれば、無線通信ネットワークは本発明の任意の態様による方法を実施するように構成される。
【００２４】
本発明の第５の態様によれば、無線通信ネットワーク用の意思決定装置は、情報記憶装置と、その情報記憶装置から情報を受け取り、ハンドオーバ中にソースノードからターゲットノードにデータを転送するかどうかを決定するためにその情報を使用するように構成される決定プロセッサであって、各無線ベアラについての決定は、そのベアラがどの無線リンク制御（ＲＬＣ）モードをサポートするのかに関係なく行われる、決定プロセッサとを備える。この情報記憶装置は固定データ、周期的に更新されるデータ若しくは継続的に改訂されるデータ、又は様々なタイプのデータに関するこれらの組合せを保持することができ、ＱｏＳ要件、移動端末速度、１つ以上のインターフェース上のパフォーマンスなどの情報を含むことができる。この情報を更新するために、ソースノードからのハンドオーバにかけられている移動端末により測定値が提供され得る。この意思決定装置はネットワークノードに含まれてよく、例えば意思決定装置はＬＴＥネットワーク内の各ｅＮＢに含まれてよく、ハンドオーバ手順中にソースノードを構成するｅＮＢは、決定が行われるｅＮＢであり得る。本発明の第５の態様による意思決定装置を、他のタイプのネットワークノードが備えることもできる。
【００２５】
本発明による一部の実施形態及び方法を、例としてのみ添付の図面を参照してこれから説明する。
【図面の簡単な説明】
【００２６】
【図１】ハンドオーバ中のネットワーク及びメッセージングの概略図である。
【図２】本発明による意思決定装置の概略図である。
【図３】ハンドオーバ中のネットワーク及びメッセージングの概略図である。
【図４】ハンドオーバ中のネットワーク及びメッセージングの概略図である。
【発明を実施するための形態】
【００２７】
図２を参照すると、意思決定装置５は、多様なネットワークパラメータに関するデータ、及び図３に示すソースｅＮＢ２との接続が現在確立されている移動端末１に関するデータを含む情報記憶装置６を含む。ＱｏＳデータ６ａ、６ｂのＵＥ速度データ、並びに６ｃのＳ１及びＸ２に関係するインターフェースデータが含まれ得る、この記憶装置６内に保持される情報にプロセッサ７がアクセスし、その情報を使用して、移動端末１がソースｅＮＢ２からターゲットｅＮＢ３にハンドオーバされるときにデータ転送を実施すべきかどうかについての決定を行う。プロセッサ７は、決定を行う際に無線ベアラのＲＬＣモードは考慮に入れない。記憶装置６内に保持されるデータのタイプ、及びそれをどのように決定に適用するのかを適当に選択することは、事業者が展開のシナリオ及び費用に応じてベアラごとにデータ転送を選択的に決めることを可能にする。例えば、事業者は高くつくラストマイル上でデータを転送しないことを選択し、伝送費用を節約することができる。これは、Ｓ１リンクが経路切替えには遅い場合に、並びにパケット損失及び質の悪いサービスを避けるために事業者がデータ転送を選択することを可能にする。
【００２８】
図３を参照すると、ＲＬＣ−ＡＭを有するベアラでは、装置５によりデータ転送を実施しない決定が行われ、この決定はソースｅＮＢ２に伝送される。ステップ７でハンドオーバ命令がＵＥ１に送信されるとき、その命令はデータ転送が実施されていないという情報を含み、そのためこのＵＥはＰＤＣＰ  ＳＮを知られている値にリセットすることを知る。ソースｅＮＢ２はさらに、転送されるデータがないという、図２のステップ７．５として示す通知をターゲットｅＮＢ３に送信する。この「データなし」メッセージを受け取り次第、ターゲットｅＮＢ３はＰＤＣＰ  ＳＮを知られている値にリセットする。この記載した場合ではデータ転送は実施されないが、他の場合ではこのベアラについてデータ転送を実施することができる。その場合には、ハンドオーバ命令７はデータ転送が使用されているという情報を含み、この手順は図１に提示するメッセージングにおいて示すように続行する。
【００２９】
図４を参照すると、ＲＬＣ−ＵＭを有するベアラでは、装置５によりデータ転送を実施する決定が行われ、この決定はソースｅＮＢ２に伝送される。ステップ７でハンドオーバ命令がＵＥ１に送信されるとき、その命令はデータ転送が実施されているという情報を含む。この場合、転送されるデータは新たなデータである。データ転送を実行すべきであるというアラートをターゲットノード３に送信することができるが、ターゲットｅＮＢ３はデータパケットの受信を開始するときにデータ転送を実行すべきであることを知っているので、このアラートは必要ではない可能性がある。この記載した場合ではデータ転送が実施されるが、他の場合ではこのベアラについてデータ転送を実施することができる。
【００３０】
データ転送するかどうかについてＵＥに指示すると、そのＵＥが任意のバッファされるパケットを直ちに上位層に送ることができるので、ＨＯ中断時間を減らす。データ転送が各ベアラについてネットワークによってサポートされているかどうかを知ることはＵＥにとって有用である。特定のベアラに関してデータ転送が使用されていない場合、ＰＤＣＰ処理について２つの可能性があり、ＨＯ手順にわたって順序番号を維持する特定の理由がない。さらに、ＵＥは再順序付けのために欠落した任意のパケットを待つことなく、任意のバッファされるパケットを直ちに上位層に送ることができる。このＵＥはさらに、ＰＤＣＰ  ＳＮを知られている値に直ちに設定することもできる。
【００３１】
一例では、ＶｏＩＰデータベアラでは、ＨＡＲＱ見逃し誤りが十分に良いとみなされ、ＲＬＣ−ＡＭによってもたらされるさらなる遅延はさらなるエンドツーエンド遅延を引き起こすことになるので、事業者はＲＬＣ−ＵＭを使用することを選択し得る。このベアラがデータ転送の対象ではない場合、ソースｅＮＢに向けて伝送中の任意のパケットは失われることになる。このオプションを基に、事業者はこのベアラについてデータ転送を行うことを選択する柔軟性を有する。Ｓ１経路切替え遅延が長い場合、より多くのパケットがソースｅＮＢに届き、それらのパケットは転送されないので失われる結果になり得る。提案した解決策により、ＶｏＩＰフローの特定の展開形態が転送の対象になり得る。
【００３２】
もう一方の動機は、ＲＬＣ−ＡＭを使用してＴＣＰフローを転送しないことである。ラストマイルが高くつき又は遅い場合、事業者はこの展開形態ではデータ転送を使用しないことを選択し得る。この解決策は、データ転送を使用すべきかどうかについて、事業者がベアラごとに、展開シナリオごとに、等、正しい選択を行うことを可能にする。
【００３３】
本発明はその趣旨又は本質的特徴から逸脱することなく他の特定の形態で実施し且つ他の方法で実施することができる。説明した実施形態及び方法は、あらゆる点で説明のためにすぎず、限定的ではないとみなされるべきである。従って本発明の範囲は、前述の説明によってではなく添付の特許請求の範囲によって示す。この特許請求の範囲の均等物の趣意及び範囲内に含まれるすべての変更は特許請求の範囲に記載の範囲内に含まれるものとする。
【図１】
2010536291.tif 000003
【図２】
2010536291.tif 000004
【図３】
2010536291.tif 000005
【図４】
2010536291.tif 000006
【国際調査報告】
2010536291.tif 000007
2010536291.tif 000008
2010536291.tif 000009