(57)【要約】  ３ＧＰＰ  Long-Term Evolution/System Architecture Evolutionシステムなどのパケット交換無線通信システムにおいてハンドオーバー中にデータパケットを転送するための方法と装置を開示する。例示的な方法では、送信元基地局ノード（４１０、９００）は、サービスを受けるユーザ端末（１６０）の少なくとも１つの無線ベアラの目標基地局ノード（４３０、９００）へのハンドオーバーが差し迫っていることを判断する（５２０）。送信元基地局ノード（４１０、９００）は、各データパケットの送信状態、各データパケットのサービス要件、またはそれら両方に従って複数のデータパケットを２つ以上のデータフロー分類に分類し（５３０）、そして各データパケットのデータフロー分類に基づきデータパケットのうちの１つまたは複数を目標基地局ノード（４３０、９００）へ選択的に転送する（５４０）。いくつかの実施形態では、送信元基地局ノード（４１０、９００）は、対応するサービス要件を決定するために各パケットのインターネットプロトコルヘッダーを検査する（６１０）ことによりデータパケットを分類する（５３０）。いくつかの実施形態では、送信元基地局ノード（４１０、９００）は、各データパケットの送信状態を判断するために無線リンク制御状態を評価する（６５０）ことによりデータパケットを分類する（５３０）。いずれの場合においても、送信元基地局ノード（４１０、９００）は１つまたは複数の分類に対応するデータパケットを選択的に転送する（５４０）。例えば、信頼できる配信サービス要件に関連するデータパケットは転送されてよいが、最大遅延サービス要件に関連するデータパケットは転送されない。
2010522466.tif 000002
【特許請求の範囲】
【請求項１】
パケット交換無線通信システムにおけるハンドオーバー中にデータパケットを転送するための送信元基地局ノード（４１０、９００）における方法であって、サービスを受けるユーザ端末（１６０）の少なくとも１つの無線ベアラの目標基地局ノード（４３０、９００）へのハンドオーバーが差し迫っているということを判断する工程（５２０）を含む方法において、
前記サービスを受けるユーザ端末（１６０）への送信のために前記送信元基地局ノード（４１０、９００）で受信した複数のデータパケットを、各データパケットの送信状態、各データパケットのサービス要件、またはそれら両方に従って２つ以上のデータフロー分類に分類する工程（５３０）と、
各データパケットの前記データフロー分類に基づいて前記目標基地局ノード（４３０、９００）へ前記データパケットのうちの１つまたは複数を選択的に転送する工程（５４０）とをさらに含むことを特徴とする方法。
【請求項２】
複数のデータパケットを分類する前記工程（５３０）は対応するサービス要件を決定するために各パケットのインターネットプロトコルヘッダーを検査する工程（６１０）を含むことをさらに特徴とする請求項１に記載の方法。
【請求項３】
複数のデータパケットを分類する前記工程（５３０）は、各パケットの前記インターネットプロトコルヘッダーからサービスタイプを決定する工程（６２０）と前記サービスタイプに基づきサービス要件を決定する工程とを含むことをさらに特徴とする請求項２に記載の方法。
【請求項４】
前記インターネットプロトコルヘッダーからサービスタイプを決定する前記工程（６２０）は、サービスタイプを、送信元または送信先アドレス、あるいは前記インターネットプロトコルヘッダーに含まれる送信元または送信先ポートに関連付ける工程を含むことをさらに特徴とする請求項３に記載の方法。
【請求項５】
前記インターネットプロトコルヘッダーからサービスタイプを決定する前記工程（６２０）は、前記インターネットプロトコルヘッダー内のサービスタイプフィールドからサービスタイプを決定する工程を含むことをさらに特徴とする請求項３に記載の方法。
【請求項６】
前記インターネットプロトコルヘッダーからサービスタイプを決定する前記工程（６２０）は、前記インターネットプロトコルヘッダーによって特定されたトランスポートプロトコルからサービスタイプを決定する工程を含むことをさらに特徴とする請求項３に記載の方法。
【請求項７】
複数のデータパケットを分類する前記工程（５３０）は、１つまたは複数のパケットのリアルタイムプロトコルヘッダーを検査する工程（６１０）と、前記リアルタイムプロトコルヘッダーによって特定されたペイロードタイプから対応するサービス要件を決定する工程とを含むことをさらに特徴とする請求項２に記載の方法。
【請求項８】
各データパケットの前記データフロー分類に基づいて前記目標基地局ノード（４３０、９００）へ前記データパケットのうちの１つまたは複数を選択的に転送する前記工程（５４０）は、信頼できる配信サービス要件を有するデータパケットを転送する工程を含むことをさらに特徴とする請求項２に記載の方法。
【請求項９】
各データパケットの前記データフロー分類に基づいて前記目標基地局ノード（４３０、９００）へ前記データパケットのうちの１つまたは複数を選択的に転送する前記工程（５４０）は、最大遅延サービス要件を有するデータパケットを転送しない工程を含むことをさらに特徴とする請求項２に記載の方法。
【請求項１０】
各データパケットの前記データフロー分類に基づいて前記目標基地局ノード（４３０、９００）へ前記データパケットのうちの１つまたは複数を選択的に転送する前記工程（５４０）は、１つまたは複数のデータパケットの最大遅延サービス要件を評価する工程と、前記最大遅延サービス要件を越えるデータパケットを転送しない工程とを含むことをさらに特徴とする請求項２に記載の方法。
【請求項１１】
前記少なくとも１つの無線ベアラは２つ以上のＩＰフローに対応するデータパケットを運ぶ方法であって、複数のデータパケットを分類する前記工程（５３０）は、前記２つ以上のＩＰフローのそれぞれの相対的な優先レベルを決定する工程と、前記ＩＰフローの相対的な優先レベルに従って各ＩＰフローに関連するデータパケットを分類する工程とを含む、ことをさらに特徴とする請求項１に記載の方法。
【請求項１２】
各データパケットの前記データフロー分類に基づいて前記目標基地局ノード（４３０、９００）へ前記データパケットの１つまたは複数を選択的に転送する前記工程（５４０）は、比較的高い優先度レベルを有する第１のＩＰフローに関連するデータパケットを転送する工程と、比較的低い優先度レベルを有する第２のＩＰフローに関連するデータパケットを転送しない工程とを含むことをさらに特徴とする請求項１１に記載の方法。
【請求項１３】
前記少なくとも１つの無線ベアラは、それぞれが１つまたは複数のＩＰフローに対応するデータパケットを運ぶ２つ以上の論理チャネルを含む方法であって、複数のデータパケットを分類する前記工程（５３０）は、前記２つ以上の論理チャネルのそれぞれの相対的な優先レベルを決定する工程と、前記論理チャネルの相対的な優先レベルに従って各論理チャネルに関連するデータパケットを分類する工程とを含むことをさらに特徴とする請求項１に記載に記載の方法。
【請求項１４】
前記２つ以上の論理チャネルのそれぞれの相対的な優先レベルを決定する前記工程は、信頼できる配信サービス要件を有する１つまたは複数のＩＰフローを含む論理チャネルに高い相対的優先レベルを割り当てる工程を含むことをさらに特徴とする請求項１３に記載の方法。
【請求項１５】
各データパケットの前記データフロー分類に基づいて前記目標基地局ノード（４３０、９００）へ前記データパケットの１つまたは複数を選択的に転送する前記工程（５４０）は、比較的高い優先度レベルを有する第１の論理チャネルに関連するデータパケットを転送する工程と、比較的低い優先度レベルを有する第２の論理チャネルに関連するデータパケットを転送しない工程とを含むことをさらに特徴とする請求項１３に記載の方法。
【請求項１６】
複数のデータパケットを分類する前記工程（５３０）は、各データパケットの送信状態を判断するために無線リンク制御（ＲＬＣ）状態を評価する工程（６５０）を含むことをさらに特徴とする請求項１に記載の方法。
【請求項１７】
各データパケットの前記データフロー分類に基づいて前記目標基地局ノード（４３０、９００）へ前記データパケットの１つまたは複数を選択的に転送する前記工程（５４０）は、確認応答されていない送信状態を有するデータパケットを転送する工程と、確認応答済の送信状態を有するデータパケットを転送しない工程とを含むことをさらに特徴とする請求項１６に記載の方法。
【請求項１８】
前記送信元基地局ノード（４１０、９００）によって使用される転送ポリシーを記載する転送情報を前記目標基地局ノード（４３０、９００）へ送信する工程をさらに含むことを特徴とする請求項１に記載の方法。
【請求項１９】
サービスを受けるユーザ端末（１６０）の少なくとも１つの無線ベアラの目標基地局ノード（４３０、９００）へのハンドオーバーが差し迫っているということを判断する（５２０）ように構成された、パケット交換無線通信システムにおける送信元基地局ノード（４１０、９００）であって、
前記送信元基地局ノード（４１０、９００）で受信した複数のデータパケットを、各データパケットの送信状態、各データパケットのサービス要件、またはそれら両方に従って２つ以上のデータフロー分類に分類し（５３０）、
各データパケットの前記データフロー分類に基づいて前記目標基地局ノード（４３０、９００）へ前記データパケットの１つまたは複数を選択的に転送する（５４０）ようにさらに構成されることを特徴とする、送信元基地局ノード（４１０、９００）。
【請求項２０】
対応するサービス要件を決定するために各パケットのインターネットプロトコルヘッダーを検査すること（６１０）により複数のデータパケットを分類する（５３０）ように構成されることをさらに特徴とする請求項１９に記載の送信元基地局ノード（４１０、９００）。
【請求項２１】
各パケットの前記インターネットプロトコルヘッダーからサービスタイプを決定すること（６２０）により複数のデータパケットを分類し（５３０）、前記サービスタイプに基づきサービス要件を決定する（６３０）ように構成されることをさらに特徴とする請求項２０に記載の送信元基地局ノード（４１０、９００）。
【請求項２２】
前記インターネットプロトコルヘッダーからサービスタイプを決定する前記工程（６２０）は前記インターネットプロトコルヘッダーによって特定されたトランスポートプロトコルからサービスタイプを決定する工程を含むことをさらに特徴とする請求項２１の送信元基地局ノード（４１０、９００）。
【請求項２３】
１つまたは複数のパケットのリアルタイムプロトコルヘッダーを検査すること（６１０）により複数のデータパケットを分類し（５３０）、前記リアルタイムプロトコルヘッダーによって特定されたペイロードタイプから対応するサービス要件を決定するように構成されることをさらに特徴とする請求項２０に記載の送信元基地局ノード（４１０、９００）。
【請求項２４】
信頼できる配信サービス要件を有するデータパケットを転送することにより、各データパケットの前記データフロー分類に基づき前記目標基地局ノード（４３０、９００）へ前記データパケットのうちの１つまたは複数を選択的に転送する（５４０）ように構成されることをさらに特徴とする請求項２０に記載の送信元基地局ノード（４１０、９００）。
【請求項２５】
最大遅延サービス要件を有するデータパケットを転送しないことにより、各データパケットの前記データフロー分類に基づき前記目標基地局ノード（４３０、９００）へ前記データパケットのうちの１つまたは複数を選択的に転送する（５４０）ように構成されることをさらに特徴とする請求項２０に記載の送信元基地局ノード（４１０、９００）。
【請求項２６】
前記少なくとも１つの無線ベアラは２つ以上のＩＰフローに対応するデータパケットを運ぶ送信元基地局ノード（４１０、９００）であって、前記２つ以上のＩＰフローのそれぞれの相対的な優先レベルを決定することにより複数のデータパケットを分類し（５３０）、前記ＩＰフローの相対的な優先レベルに従って各ＩＰフローに関連するデータパケットを分類するように構成される、ことをさらに特徴とする請求項１９に記載の送信元基地局ノード（４１０、９００）。
【請求項２７】
前記少なくとも１つの無線ベアラは、それぞれが１つまたは複数のＩＰフローに対応するデータパケットを運ぶ２つ以上の論理チャネルを含む送信元基地局ノード（４１０、９００）であって、前記２つ以上の論理チャネルのそれぞれの相対的な優先レベルを決定することにより複数のデータパケットを分類し（５３０）、前記論理チャネルの相対的優先レベルに従って各論理チャネルに関連するデータパケットを分類するように構成されることをさらに特徴とする請求項１９に記載の送信元基地局ノード（４１０、９００）。
【請求項２８】
前記送信元基地局ノード（４１０、９００）は各データパケットの送信状態を判断するために無線リンク制御（ＲＬＣ）状態を評価することにより複数のデータパケットを分類する（５３０）ように構成されることをさらに特徴とする請求項１９に記載の送信元基地局ノード（４１０、９００）。
【請求項２９】
確認応答されていない送信状態を有するデータパケットを転送し確認応答済の送信状態を有するデータパケットを転送しないことにより、各データパケットの前記データフロー分類に基づき前記目標基地局ノード（４３０、９００）へ前記データパケットの１つまたは複数を選択的に転送する（５４０）ように構成されることをさらに特徴とする請求項２８に記載の送信元基地局ノード（４１０、９００）。
【請求項３０】
前記送信元基地局ノード（４１０、９００）により使用される転送ポリシーを記載する転送情報を前記目標基地局ノード（４３０、９００）へ送信するようにさらに構成されることをさらに特徴とする請求項１９に記載の送信元基地局ノード（４１０、９００）。
【発明の詳細な説明】
【技術分野】
【０００１】
技術分野
本発明は通信システムに関し、特にはlong-term evolution （ＬＴＥ）無線通信システムにおける選択的パケット転送のための方法と装置に関する。
【背景技術】
【０００２】
背景
第３世代パートナーシッププロジェクト（３ＧＰＰ）では、無線通信ネットワークの次世代の設計と仕様が、Long Term Evolution（ＬＴＥ）イニシアチブとして知られた取り組みで進行中である。新しい無線インターフェースの定義と共に、新しいコアネットワークアーキテクチャもまた定義されつつある。この定義はSystem Architecture Evolution（ＳＡＥ）として知られている。図１に示すように、ＬＴＥ／ＳＡＥネットワークは、ユーザおよび制御プレーンを支援する２つのタイプのネットワーク要素、すなわち発展型ＮｏｄｅＢまたは「ｅＮｏｄｅＢ」と呼ばれる拡張基地局１１０とアクセスゲートウェイ（ａＧＷ）１２０とを含む。ｅＮｏｄｅＢ１１０はＬＴＥ無線インターフェースおよび無線資源の管理を提供し、ＡＧＷはユーザプレーンのモビリティアンカポイントを提供し、ＩＰサービスネットワーク１４０（インターネット、イントラネットおよび他のＩＰベースのサービスネットワークを含んでよい）へのゲートウェイを提供する。
【０００３】
最近まで、ＬＴＥモビリティ（すなわち１つのｅＮｏｄｅＢ１１０から別のｅＮｏｄｅＢへのハンドオーバー）に関する議論は、パケットデータコンバージェンスプロトコル（ＰＤＣＰ：Packet Data Convergence Protocol）が一端のＬＴＥアクセスゲートウエイノード１２０において終端され、そして他端のユーザ装置（ＵＥ）１６０において終端されるという仮定に基づいていた。ＰＤＣＰ（レイヤ２の一部）は送信データの暗号化と完全性保護だけでなくＩＰヘッダーの圧縮と復元を行う。主として暗号化目的のためにＰＤＣＰシーケンス番号をユーザーデータに加える。パケットの並べ替えと重複パケットの検出のためにハンドオーバー手順においてこれらのシーケンス番号を使用することができる。図２Ａに、ＵＥ１００、発展型ＮｏｄｅＢ（ｅＮｏｄｅＢ）１１０およびａＧＷ１２０間のレイヤ１とレイヤ２機能の割り振りの従来の理解を例示する。図２Ａに示すように、ＰＤＣＰはａＧＷ１２０において終端し、一方無線リンク制御（ＲＬＣ：Radio Link Control）プロトコルと媒体アクセス制御（Medium Access Control）プロトコルはｅＮｏｄｅＢ１１０において終端する。
【０００４】
ｅＮｏｄｅＢ１１０間ハンドオーバーはａＧＷ１２０の変更を必要としないので、当業者は、図２Ａに示すアーキテクチャを利用するシステムでは典型的なハンドオーバー手順はＰＤＣＰを含む必要はないということを十分に理解するだろう。このアーキテクチャの１つの利点は、ヘッダー圧縮は、再起動されることなく、あるいは無線アクセスネットワークまたはコアネットワーク内の別のノードに移動されることなく、ハンドオーバー処理の間続けることができるという点である。これはアップリンクおよびダウンリンクデータ転送の両方に適用される。
【０００５】
しかしながら最近、３ＧＰＰは、ＰＤＣＰ機能を図２Ｂに示すようにａＧＷではなくｅＮｏｄｅＢ内に設置することを決定した。ＰＤＣＰ機能のｅＮｏｄｅＢへの移動はモビリティに関しいくつかの意味合いを持つ。例えば、ＰＤＣＰにおけるヘッダー圧縮機能はハンドオーバー中に送信元ｅＮｏｄｅＢ１１０から目標ｅＮｏｄｅＢ１１０へ「移動する」。
【０００６】
ヘッダー圧縮はフロー分類を必要とし、各入力ＩＰパケットのヘッダーは、パケットが属するフローと使用すべき対応する圧縮状態とを圧縮器が特定するために検査されなければならない。変化するサービス要件を有する複数のＩＰフローが同じＰＤＣＰインスタンスを共有する場合、ｅＮｏｄｅＢ１１０ではそれらのサービス要件に基づきＩＰパケットを識別し区別することができる。例えば、異なるＩＰフローは、重複パケットの回避、パケットの損失、順序通りの配信、中断時間、および／またはジッタに関して異なる要件を有してよい。
【発明の概要】
【課題を解決するための手段】
【０００７】
発明の概要
パケット交換無線通信ネットワークにおけるハンドオーバー中にパケットを転送するための本発明で権利請求する方法と装置では、送信元基地局は、いくつかのパケットが転送され他のものは転送されないといったパケットの選択的転送を行う。ハンドオーバーの開始時に無線リンクプロトコルにより処理されるパケット（送信に備えて送信元ｅＮｏｄｅＢ内にバッファされた）、および／またはアクセスゲートウェイから入力するパケットに対し転送の決定をすることができる。転送の決定は、無線リンク制御（ＲＬＣ）状態（ＲＬＣ状態通知、ハイブリッド自動再送要求（ＨＡＲＱ：Hybrid Automatic Repeat Request）、またはＲＬＣ再送バッファの内容を含んでよい）、各パケットに対応するＩＰトラヒックのタイプ（ＩＰヘッダーの検査に基づいて決定されるような）、およびそれぞれが１つまたは複数のＩＰフローを含む１つまたは複数の論理チャネルに関連するサービス品質要件のうちの１つまたは複数を使用するパケットの分類に基づいてよい。パケットを分類し、いくつかパケットのみを選択的に転送することにより、各ＩＰフローに関連するサービス要件に関するシステム性能を向上させることができる。これらのサービス要件は例えば、重複回避、保証配信、遅延およびジッタ制限、および順序通りの配信の要件を含んでよいであろう。
【０００８】
以下に例示されるように、これらの転送原理は、ユーザ装置（ＵＥ）と送信元ｅＮｏｄｅＢと目標ｅＮｏｄｅＢにおけるハンドオーバー手順と結合されてよい。一度に１つのベアラに対してハンドオーバーを行うことができる場合（これは現在、ＬＴＥシステムには当てはまらない）、同じ原理はハンドオーバー中のベアラにより運ばれるＩＰフローに適用してよい。したがって、ハンドオーバー対象のベアラにより運ばれる１つまたは複数のＩＰフローに対応するいくつかのパケットは、ＩＰフローおよび／または無線リンク制御状態に関連するサービス要件に従って転送されてよいが、他のものは転送されてはならない。無線インターフェース上のハンドオーバーがすべてのベアラに対し同時である場合、本明細書に記載の原理と方法はベアラレベルにおいても適用することができる。したがって、１つまたは複数のベアラに対応するパケットは、サービス要件および／またはベアラに関連するリンク状態に従って転送されてよいが他のものは転送されてはならない。
【０００９】
したがって、パケット交換無線通信システムにおけるハンドオーバー中にデータパケットを転送するための例示的な方法では、送信元基地局ノードは、サービスを受けるユーザ端末の少なくとも１つの無線ベアラの目標基地局ノードへのハンドオーバーが差し迫っているということを判断する。送信元基地局ノードは、各データパケットの送信状態、各データパケットのサービス要件、またはそれら両方に従って複数のデータパケットを２つ以上のデータフロー分類に分類し、そして各データパケットのデータフロー分類に基づき１つまたは複数のデータパケットを目標基地局ノードへ選択的に転送する。いくつかの実施形態では、送信元基地局ノードは、対応するサービス要件を決定するために各パケットのインターネットプロトコルヘッダーを検査することにより、データパケットを分類する。いくつかの実施形態では、送信元基地局は、各データパケットの送信状態を判断するために無線リンク制御状態を評価することにより、データパケットを分類する。いずれかの場合または両方の場合、送信元基地局は１つまたは複数の分類に対応するデータパケットを選択的に転送する。例えば、信頼できる配信サービス要件に関連するデータパケットは転送されてよいが、最大遅延サービス要件に関連するデータパケットは転送されない。
【００１０】
本発明は、ｅＮｏｄｅＢが、ＩＰパケットの粒度での（すなわちＩＰフロー毎の）ハンドオーバー中に特定要件を満たすことができるという利点がある。例えば、中断時間をＶｏＩＰフローに対し最小化するとともに、同じＰＤＣＰパイプ／ＲＬＣ論理チャネルを共有するＴＣＰフローの信頼性と順序通りの配信を同時に保証することができる。
【図面の簡単な説明】
【００１１】
図面の簡単な説明
【図１】ＬＴＥ／ＳＡＥネットワークを含む通信ネットワークを例示する。
【図２Ａ】図１のネットワーク要素間でのプロトコル資源の１つの割り振りを例示する。
【図２Ｂ】図１のネットワーク要素間でのプロトコル資源の別の割り振りを例示する。
【図３】無線通信システムにおけるハンドオーバー中のユーザプレーンモビリティ問題を例示する。
【図４】無線通信システムにおけるハンドオーバー中のＲＬＣの振る舞いに関するユーザプレーンモビリティ問題を示す。
【図５】無線通信システムにおいてパケットを転送するための例示的な方法を例示する。
【図６Ａ】本発明の１つまたは複数の実施形態による、パケットを分類する方法を例示する。
【図６Ｂ】本発明の１つまたは複数の実施形態による、パケットを分類する方法を例示する。
【図７】本発明の１つまたは複数の実施形態による、パケットを分類する別の方法を例示する。
【図８】本発明のいくつかの実施形態による、パケットを転送する方法を例示する。
【図９】本発明による方法のうちの１つまたは複数を実行するように構成されたｅＮｏｄｅＢを例示する。
【発明を実施するための形態】
【００１２】
詳細な説明
上に検討したように、図１に、ＬＴＥ通信システムのアーキテクチャの基本要素を例示する。ＰＤＣＰ機能（すなわちヘッダ圧縮、暗号化）をｅＮｏｄｅＢ１１０へ移動させた結果、ｅＮｏｄｅＢ１１０はＩＰパケットヘッダを検査することができる。ヘッダー圧縮および／または暗号化が以前の計画どおりにａＧＷ１２０において行われると、ｅＮｏｄｅＢ１１０におけるＩＰヘッダーの検査は不可能であろう。以下でさらに詳細に説明するように、このＩＰヘッダーを検査する能力は、無線通信システムにおけるハンドオーバー中のパケットを転送するための本明細書で開示される方法と装置のいくつかの態様を可能にする。
【００１３】
ＬＴＥシステムでは、ユーザ装置（ＵＥ）への送信が指定されたデータパケットを、送信元ｅＮｏｄｅＢ（すなわちハンドオーバーの決定がなされる前にＵＥをサービスするｅＮｏｄｅＢ）から目標ｅＮｏｄｅＢへ転送することができる。所与のＵＥ向けのダウンリンクパケットはいくつかのＩＰフローに対応することができる。これらＩＰフローのそれぞれは、重複パケット、損失、中断時間、順序通りの配信、遅延およびジッタに対する許容度に関し異なるサービス品質（ＱｏＳ）要件を有してよい。パケットヘッダを検査することにより、ｅＮｏｄｅＢは、異なるＩＰフローに属するパケットを区別することができる。例えば、ｅＮｏｄｅＢは、パケットをいくつかのＩＰフローに分類するために、送信元および送信先アドレス、送信元および送信先ポート、サービスタイプ、トランスポートプロトコルなどのパケットヘッダーデータを使用することができる。当業者には明らかなように、いくつかの場合のｅＮｏｄｅＢによりなされる転送の決定はあるフロータイプに基づき予めプログラムされた規則により駆動されてよいが、他の場合の転送の決定はＩＰヘッダーの内容に基づいてよい。例えば、転送の振る舞いを決定するために、ＩＰパケットヘッダに含まれる「サービスのタイプ」パラメーターを使用することができる。一般的に言えば、所与のＩＰフロー、セッションまたは論理チャネルのサービス要件に関する情報（ＩＰヘッダーからまたは他のものから決定されるにかかわらず）は、ハンドオーバー中の転送の振る舞いを決定するために使用されてよい。システムおよび／またはリンク状態情報もまた転送の決定において利用されてよい。
【００１４】
図３に、ユーザプレーンモビリティに関連する問題のいくつかを例示する。一般的には、重複が無くかつ最小遅延を有する順序通りでかつ無損失の配信の手段を提供することが望ましい。移動端末においてパケットが送信元ｅＮｏｄｅＢおよび目標ｅＮｏｄｅＢの両方から受信された場合、重複が生じ得る。これは例えば、ハンドオーバーが生じた時に送受信パケットがまだ確認応答されていない場合に発生し得る。図３において、これはＰＤＣＰパケットデータ単位（ＰＤＵ）６に関する場合である（ＵＥ３１０により送信元ｅＮｏｄｅＢ３２０から受信されたがハンドオーバー時点では確認応答されていない）。したがって、送信元ｅＮｏｄｅＢ３２０は目標ｅＮｏｄｅＢ３３０にＰＤＣＰ  ＰＤＵ  ６を転送する。ハンドオーバー後、ＰＤＣＰ  ＰＤＵ  ６は再び移動端末３１０に送信される。（このシナリオは無線リンク制御ＡＲＱ方式がハンドオーバー時に「リセット」される場合、すなわち、いかなる無線リンク制御（ＲＬＣ）コンテキストも転送されない場合に最も適用可能であることを当業者は理解するだろう。ＲＬＣコンテキストの転送で、重複は回避することができるが、可能性として付加的な遅延とシステムの複雑性の増加を犠牲にする）。
【００１５】
アクセスゲートウェイからｅＮｏｄｅＢへのインターフェースとｅＮｏｄｅＢからｅＮｏｄｅＢへのインターフェース上での異なる伝達遅延のために、「より若い」パケット（アクセスゲートウェイ３４０により送信された）が転送パケットより早く目標ｅＮｏｄｅＢ３３０に到達すると、パケットの順序外送信が発生し得る。（ＬＴＥでは、これらのインターフェースは、Ｓ１およびＸ２インターフェースとしてそれぞれ知られている）。図３では、これはＰＤＣＰ  ＰＤＵ  ７により最も明瞭に示される。ＰＤＣＰ  ＰＤＵ  ５、６はＰＤＣＰ  ＰＤＵ  ８、９、１０の前に目標ｅＮｏｄｅＢ３３０に到達することができるが、ＰＣＤＰ  ＰＤＵ  ７は送信元ｅＮｏｄｅＢ３２０によりまだ転送されていないので、後で到達しそうである。
【００１６】
上に検討したように、転送は、図３の送信元ｅＮｏｄｅＢ３２０と目標ｅＮｏｄｅＢ３３０などの送信元ｅＮｏｄｅＢと目標ｅＮｏｄｅＢ間のハンドオーバーで一般的には行われる。以前のシステムでは、転送は一般的にはＰＤＣＰエンティティ毎に行われていた。通常、１つのＰＤＣＰエンティティは、遅延および／または中断時間特性を抑制するサービス要件だけでなく、無損失の配信、無重複または順序通りの配信の要件などのサービス要件に関する当該の一組のＱｏｓ特性を有する論理チャネルに対応する。
【００１７】
しかしながら、ＰＤＣＰ論理チャネルは２つ以上の個別のＩＰフローを含むことができる。異なるＩＰフローは、特に重複回避、配信信頼性、順序通りの配信または中断時間および／またはジッタに関し、異なるサービス要件を有してよい。移動中（すなわちハンドオーバー中）のサービスを維持するために、送信元ｅＮｏｄｅＢはＳ１経路が更新される（ルーティングの更新）までパケットを目標ｅＮｏｄｅＢへ転送する。ハンドオーバー中、ＩＰパケットは、送信元ｅＮｏｄｅＢにおいて送信されていてよい。いくつかのＲＬＣパケットデータ単位（ＰＤＵ）は送信されたが確認応答されていないかもしれない。（当業者が十分に理解するように、いくつかのＡＲＱ方式がＰＤＵ毎の確認応答を採用し、他のＡＲＱ方式はそれほど頻繁でないＲＬＣ状態通知に依存してもよい）。いくつかのシステムでは、ＲＬＣはハンドオーバー時にリセットされてよい、すなわちＲＬＣはすべての未完了送信を中断してよい。他のシステムは新しい送信の試みは停止し、進行中の送信を完了しようとしてよい。さらに、他のシステムは、詳細なＲＬＣ状態情報（ＲＬＣコンテキスト）を目標ｅＮｏｄｅＢへ転送することにより容易に動作を続けることができる。以下にさらに詳細に検討されるように、転送処理を改善してシステム性能を向上させるために、サービス要件と送信状態との差異を利用することができる。
【００１８】
ＲＬＣの振る舞いの例を図４に示す。この図はＲＬＣ  ＡＲＱコンテキスト転送の無いシナリオ（重複検出とダウンリンク再順序付けの受信側シーケンス番号が無いことを意味する）を例示する。したがって、ハンドオーバー後の重複の無い順序通りの送信を維持するには、ハンドオーバーの信頼できる状態通知を必要とする。図４の例では、ＰＤＣＰ  ＰＤＵはＡ、Ｂ、Ｃ等とラベルが付けられ、ＲＬＣ  ＰＤＵ（この場合、セグメント化されたＰＤＣＰ  ＰＤＵ）は５、６、７等とラベルが付けられる。同図では、送信元ｅＮｏｄｅＢ４１０はユーザ端末４２０へＲＬＣ  ＰＤＵ  １２までのＲＬＣ  ＰＤＵを送信したが、ＲＬＣ  ＰＤＵ  １０までのＲＬＣ  ＰＤＵの配信を確認するＲＬＣ状態通知のみを受信した。したがって、ハンドオーバー時、ＰＤＣＰ  ＰＤＵ  Ｂの送信は未完了であり、ＰＤＣＰ  ＰＤＵ  Ｂと後に続くＰＤＣＰ  ＰＤＵは目標ｅＮｏｄｅＢ４３０へ転送される。いかなるパケットの送信も状態通知中は停止されなければならない。ハンドオーバーとその結果のＳ１経路切り替え後、後に続くＰＤＣＰ  ＰＤＵは、ＳＡＥゲートウェイ４４０により目標ｅＮｏｄｅＢ４３０に直接供給される。目標ｅＮｏｄｅＢ４３０が順序通りの配信を保証するためには、Ｓ１／Ｘ２プロトコルのサポートが必要かもしれない。一般的には、重複と順序外配信の危険性はハンドオーバー中のレイヤ２の中断遅延に対するトレードオフとすることができる。
【００１９】
パケット転送とＲＬＣの振る舞いは、重複、損失（信頼性）、並べ替えおよび中断時間（遅延とジッタ）に関するサービス要件に関するＩＰフローに影響を与え得ることは明白である。これらのサービス要件のいくつかは、相矛盾する転送目標とＲＬＣ目標を意味するかもしれない。例えば、ＩＰフローまたはベアラが信頼できる状態通知を必要とする場合、このことは一般的に、ハンドオーバーの実行が延期され、遅延とジッタ性能に悪影響を与えることを意味する。異なるＩＰフローが異なるサービス要件に関連付けられると、同じユーザ端末において終端されるＩＰフローに対し相矛盾する転送要件とＲＬＣ要件が存在することになる。
【００２０】
同じＲＬＣ論理接続に関連するすべてのＩＰフローが転送とＲＬＣの振る舞いに関し同じ処理を受ける場合、この問題は悪化するかもしれない。いくつかのシステムでは、すべての論理接続（すなわち同じＰＤＣＰ論理チャネルにおいて論理的にグループ化されたいくつかのフロー）はハンドオーバー中、常に同じように処理されてよく、したがっていくつかのサービス要件を優先し他のサービス要件を犠牲にしてよい。他のシステムでは、ＲＬＣおよび転送ポリシーは１つの論理チャネルと別の論理チャネルでは異なって適用されてよいが、（当該ＰＤＣＰ論理チャネル上で実行される優先ＩＰフロー、セッションまたはサービスのうちの１つまたは複数の特性とは違って）全体の論理チャネルの特性に基づいて適用される。
【００２１】
したがって、パケット転送の効率を向上させる解決策は、以下の特性のうちの１つまたは複数を含むことが好ましい。第１に、１つのＰＤＣＰまたは１つのＲＬＣインスタンスに関連するフローのサブセットに属するパケットを直ちに転送することができなければならない。第２に、各論理接続におけるＩＰフローのうちの１つまたは複数のＩＰフローの優先特性に基づいて、論理接続（論理接続はいくつかのＩＰフローを含んでよい）のサブセットに属するパケットを直ちに転送することができなければならない。第３に、転送の決定を、ＩＰパケットが属するサービスの要件（すなわち所与のＩＰパケットのＩＰフローに関連するサービス要件）に基づかせることができなければならない。最後に、転送ポリシーはＲＬＣ手順の振る舞いとは独立していなければならない。
【００２２】
図５に、先のシステム設計目標のうちの１つまたは複数を満たす、パケット交換無線通信システムにおいてハンドオーバー中にデータパケットを転送する例示的な方法を示す。図５の本方法は、図４に示す送信元ｅＮｏｄｅＢ４１０などのｅＮｏｄｅＢにおいて実施することができる。本方法について、図４の構成部品を参照し以下に説明する。しかしながら、当業者は、以下に述べる方法が他のシステム構成にも適用され得るということを十分に理解するだろう。
【００２３】
本方法はブロック５１０で開始され、ここでユーザ端末４２０は送信元ｅＮｏｄｅＢ４１０に接続される。ブロック５２０では、ハンドオーバーは従来の手段によりトリガされる。例えば、ハンドオーバーはチャネル条件の変化に応じて送信元ｅＮｏｄｅＢ４１０によりトリガされてよい。ブロック５３０では、送信元ｅＮｏｄｅＢ４１０で受信されたパケットは、送信状態、またはパケットに関連するサービス要件、またはそれら両方に従って分類される。分類されるパケットは、現在送信されているパケット（例えば、ＲＬＣレイヤにより依然として処理中のパケット）を含むことができる。分類されるパケットは、送信に備えて送信元ｅＮｏｄｅＢ４１０にバッファされたパケットと、Ｓ１インターフェースの切換え前にアクセスゲートウェイ４４０から目標ｅＮｏｄｅＢ４３０に送信されるパケットとをさらに含むことができる。最後に、ブロック５４０では、パケットはパケット分類に基づいて目標ｅＮｏｄｅＢ４３０に選択的に転送される。
【００２４】
パケットの分類は以下の判定規準：１つまたは複数のパケットに対応するＲＬＣ状態通知；ＨＡＲＱ状態を含むＲＬＣ状態（そのＲＬＣ状態通知および／またはＲＬＣ再送バッファ状態がその一部を形成してもよい）；ＩＰフロー分類（一般的にはＩＰヘッダ検査に基づく）；ＩＰフロー、セッションまたはＲＬＣインスタンスに関連する１つまたは複数のＱｏＳ要件；および１つまたは複数のパケットフィルターのうちの１つまたはいくつかに基づいてよい。特定のＩＰフローまたはフローのタイプに関連する要件の知識もまた分類に使用されてよい。例えば、サービスまたはデータのタイプ（ＶｏＩＰサービス、ＴＣＰまたはＵＤＰトラフィック、ストリーミングデータ（ＲＴＳＰ等）、制御データ、シグナリングデータ等）はそれぞれ、対応するパケットの分類を決定する１つまたは複数のサービス要件に関連付けられてよい。場合によっては、分類は「常に転送する」と「決して転送しない」などのような２つのカテゴリを単に含んでもよい。他の場合では、分類は、より複雑な規則に従うかもしれない追加のカテゴリを含むことができる。したがって、いくつかの分類カテゴリは、システム／ｅＮｏｄｅＢ状況のある組合せのもとに転送されてよいが、他の組合せのもとでは転送されてはならない。状態ベースの転送決定を採用する実施形態などのいくつかの実施形態では、送信元ｅＮｏｄｅＢ４１０により現在使用中の転送ポリシーに関し目標ｅＮｏｄｅＢ４３０に通知するために、「フィルタ情報」を送信元ｅＮｏｄｅＢ４１０から目標ｅＮｏｄｅＢ４３０へ送信することができる。
【００２５】
いくつかの実施形態では、送信元ｅＮｏｄｅＢ４１０のＲＬＣは、移動端末４２０が目標ｅＮｏｄｅＢ４３０に最終的にハンドオーバーされるまでは、パケットに関し導出された同じ情報に基づいて特定パケットの新しい送信を開始することができる。例えば、最大遅延要件に関連する分類に属するパケットは、いくつかの実施形態においては目標ｅＮｏｄｅＢ４３０へは決して転送されないかもしれない（そうすると許容できない遅延を生じ易いからである）。（いくつかの実施形態では、最大遅延を越えるだろうということを前提として、最大遅延要件を有するすべてのパケットに無転送ポリシーが適用されるかもしれない。他の場合では、最大遅延要件は各パケットを転送すべきかどうかを判断するためにパケット毎に評価されてよい）。しかしながら、これらの同じパケットはハンドオーバーが完了するまで、「最善努力原則： best-efforts basis」で送信元ｅＮｏｄｅＢ４１０により送信され続けられてよい。これらの低遅延パケットに即時送信のための優先度を与えるとともに他のパケットに転送を指定することにより、様々なパケット分類のサービス要件は、単独のポリシーがすべてのパケットに適用される場合より、満足され易くなるということを当業者は十分に理解するだろう。
【００２６】
いくつかの実施形態では、目標ｅＮｏｄｅＢ４３０は、Ｓ１インターフェース上でアクセスゲートウェイから受信されるパケットの送信をいつ開始するかを決定するために同様の手法を使用することができる。例えば、順序通りの配信サービス要件に対応するＩＰフローに属するパケットは、目標ｅＮｏｄｅＢ４３０が転送インターフェース上で送信元ｅＮｏｄｅＢ４１０から受信される同じＩＰフローに属する別のパケットを待つ間、意図的に遅らされてもよい。その間、低遅延サービス要件を有する（が順序通りの配信要件を有しない）アクセスゲートウェイから受信されたパケットは、移動端末４２０に直ちに送信されてよいであろう。パケット分類に基づくこれらの送信決定は、ローカル実装とポリシーに基づいてよいが、送信元ｅＮｏｄｅＢ４１０により提供される情報（例えば上に検討されたフィルタ情報）に基づいてもよいであろう。
【００２７】
上述のように、各パケットは、関連するサービス要件、またはパケットの送信状態、またはそれら両方に従って分類されてよい。いくつかの実施形態では、サービス要件に従うパケットの分類は各パケットのＩＰヘッダーを検査することにより達成される。図６Ａに、この処理に基づく例示的な方法を示す。ブロック６１０では、分類されるパケットのＩＰヘッダーが検査される。既に述べたように、ＰＤＣＰ機能をｅＮｏｄｅＢ内に設置することにより、ｅＮｏｄｅＢにおいてＩＰヘッダーを検査できるようになる。（さもないと、パケットが受信される前に行われるヘッダー圧縮と暗号化はＩＰヘッダー検査を妨げるであろう）。ブロック６２０では、サービスタイプはＩＰヘッダーから決定される。いくつかの実施形態では、ＩＰヘッダーの１つまたは複数のフィールドを所定のサービスタイプに関連付けることによりサービスタイプを決定することができる。例えば、ある送信元または送信先アドレス、あるいはある送信元または送信先ポートは特定のサービスタイプに対応するということを知らせてよい。ＩＰヘッダーのプロトコルフィールドにより示されるトランスポートプロトコル（例えばＴＣＰ  ＵＤＰ等）が、特定のサービスタイプを示してもよいしあるいはそれに対応してもよい。サービスタイプもまたヘッダー内のサービスタイプフィールドにより示されてよい。
【００２８】
いくつかの実施形態では、サービス要件は、特定タイプのペイロードに対応するパケットヘッダを検査することにより決定されてよい。例えば、リアルタイム転送プロトコル（ＲＴＰ）データを運ぶパケットはＲＴＰヘッダーを含む。ＲＴＰヘッダーは、ペイロードの形式（例えば符号化）を示すペイロードタイプフィールドを含む。このフィールドからサービス要件を推測することができる。例えば、ビデオデータについては、ｌ−フレームなどのあるフレームタイプはＰ−フレームやＢ−フレームなどの他のフレームより高く優先付けられてよい。
【００２９】
一旦サービスタイプがＩＰパケットに対し決定されると、ブロック６３０で示すように、サービスタイプをサービス要件に関連付けることができる。いくつかの実施形態では、サービスタイプとサービス要件間のマッピングは所定の表に従ってよい。このとき、パケットは、ブロック６４０に示すようにサービスタイプに従って分類される。サービスタイプ毎に単一の分類があってもよいし、いくつかのサービスタイプが単一の分類にマッピングされてもよい。上に検討したように、サービス要件によるパケットの分類は、パケットの転送の選択の基準を与えることができる。次に、上記処理はブロック６５０により示されるように、すべてのパケットが分類されるまで繰り返されてよい。
【００３０】
図６Ｂに、送信状態に従ってパケットを分類する例示的な手順を示す。送信状態による分類は、サービス要件による分類の代わりに、あるいはそれに加えて行われてもよいことを当業者は十分に理解するだろう。ブロック６５０では、１つまたは複数のパケットの送信状態を判断するために、無線リンク制御状態をｅＮｏｄｅＢにおいて評価する。この評価は、ハンドオーバー対象の移動局４２０から受信されたＲＬＣ状態通知の検査を含んでよい。（いくつかの実施形態では、複数のベアラのうちの１つまたは複数のベアラの状態通知を選択的に要求するために、所与の論理チャネルまたは所与のＩＰフローに関連する優先度またはサービス要件を使用することができる）。他の実施形態では、状態通知は、現在のＲＬＣ状態に従って未処理のデータが存在するベアラに対してのみハンドオーバー時に要求されてよい。
【００３１】
ブロック６６０では、パケットはその送信状態に従って分類される。上記処理はブロック６７０に示すように必要に応じ繰り返される。送信状態によるパケット分類は、パケットを確認応答済みクラスと確認応答されていないクラスへ仕分けるのと同じくらい簡単かもしれない。一方、より手の込んだ分類を使用してもよい。例えば、追加の分類は、実際に送信されたがまだ確認応答されていないパケット、あるいはＲＬＣ状態通知の標題を含んでもよい。サービス要件による分類と同様に、送信状態による分類は転送決定を推進するために使用されてよい。多くの実施形態では、実際に確認応答されたパケットは決して転送されることはない。いくつかの実施形態では、送信されたが確認応答されていないパケットは、信頼性サービス要件に関連する場合は転送されてよいであろうが、そうでなければ転送されてはならない。当業者は、様々なパケット分類のうちの任意のものの転送決定を処理するために策定され得る様々な規則を理解するだろう。
【００３２】
上で示したように、パケットは、中でも個別のＩＰフローに関連するサービス要件に従って分類されてよい。いくつかの実施形態では、パケットは、その代りに全体の論理チャネルに関連するサービス要件に従って分類されてよい。単一のＰＤＣＰエンティティおよび／または単一のＬＴＥ無線ベアラに関連付けられてよい論理チャネルは、いくつかのＩＰフローを含むことができる。所与の移動端末４２０は、これらの論理チャネルの２つ以上を一度に受信してもよい。これらの論理チャネルのそれぞれは、異なる優先レベルまたは異なるサービス要件に暗黙的あるいは明示的に関連付けられてもよい。このような場合、高優先度論理チャネルに関連するパケットはハンドオーバー中に転送されてよく、低優先度チャネルに関連するパケットは破棄されてよい。
【００３３】
場合によっては、所与の論理チャネルに関連する優先度またはサービス要件は所定の関係に従ってよい。しかしながら、他の場合では、論理チャネルの優先度またはサービス要件は、チャネルにより運ばれるＩＰフローのうちの１つまたは複数に関連するサービス要件により決定されてよい。
【００３４】
図７に、論理チャネル優先度に従ってパケットを分類する例示的な方法を示す。ブロック７１０では、論理チャネルは、信頼できる配信要件を有するかどうかを判断するために評価される。場合によっては、このような要件は、論理チャネルタイプに基づき、所与の論理チャネルに対し示唆されてよい。他の場合では、ＩＰヘッダーまたは他の情報は、論理チャネルが最優先のＩＰフローとしての資格のある１つまたは複数のＩＰフローを運ぶかどうかを（いくつかの所定の判定基準に従って）判断するために、評価されてよい。したがって、いくつかの実施形態では、論理チャネルは、それが運ぶ最高優先度ＩＰフローに従って１つまたは複数の優先レベルに分類されるかもしれない。当業者には明らかなように、論理チャネルの優先レベルを決定するための他の規則は当然ながら可能である。
【００３５】
図７に示した例では、ブロック７２０に示すように、信頼できる配信要件に関連する論理チャネルには比較的高い優先度分類が割り当てられる。一方、ブロック７４０に示すように、信頼できる配信要件に関連しない論理チャネルには比較的低い優先度分類が割り当てられる。２つ以上の相対的優先レベルに従って論理チャネルを分類するために、（信頼できる配信要件の代わりにあるいはその要件に加えて）他のサービス要件を同様の方法で評価してよい。ブロック７４０では、上記処理は残りの論理チャネルに対し繰り返される。
【００３６】
最後に、ブロック７５０では、パケットはその論理チャネルの優先度に従って分類される。したがっていくつかの実施形態では、比較的高い優先パケットは目標ｅＮｏｄｅＢ４３０へ転送されてよく、比較的低い優先パケットは転送されてならない。他の分類と同様に、論理チャネルの優先度による分類は、転送決定のためだけでなく、ハンドオーバーが完了する前に追加のパケットが送信されるべきかどうかを判断する際にも使用されてよい。さらに、いくつかのシステムはすべての論理チャネルが同時にハンドオーバーされることを要求するかもしれないが、他のシステムは個々の事例毎（すなわち１度に１つ）の論理チャネルまたは無線ベアラのハンドオーバーを許容するかもしれない。このときこれらのシステムでは、本明細書に記載の分類方法は、どの論理チャネルまたは無線ベアラが最初にハンドオーバーされなければならないか、およびいつパケット転送が用いられるべきかを決定するために使用されてよいであろう。
【００３７】
図８に、上記分類手法のうちの１つまたは複数を使用するｅＮｏｄｅＢにおける転送決定のために使用されると考えられる１つの手法を示す。その処理は、既に分類された少なくとも１つのパケットで始まる。ブロック８１０では、パケット送信状態分類が評価される。パケットは確認応答されたということをパケット分類が示す場合、ブロック８４０で示すようにパケットは転送されない。一方、パケットが確認応答されていない場合、それは直ちに転送されないが、その分類についてさらに調べる。したがって、ブロック８２０で、パケットが信頼できる配信要件に従って分類されると、それはブロック８５０に示すように直ちに転送される。そうでない場合、パケットが最大遅延要件に従って分類されるかどうかを判断するために、パケットはブロック８３０で評価される。そうならばパケットは直ちに転送され（ブロック８５０）、そうでなければ転送されない（ブロック８４０）。処理対象の分類済みパケットの残りがなくなるまで、ブロック８６０に示すように上記処理は繰り返される。
【００３８】
図８に例示された処理は、実施され得る幅広い種類の転送規則の１つを示すに過ぎない。また、本発明により可能な幅広い種類の分類と、それらの分類に対応するために実施され得る転送ポリシーにもたらされる多様性とを、当業者は理解するだろう。
【００３９】
図９に、本明細書に記載の方法のうちの１つまたは複数を実行するように構成されたｅＮｏｄｅＢを示す。ｅＮｏｄｅＢ９００は、ｅＮｏｄｅＢ９００とアクセスゲートウェイ間の通信（Ｓ１インターフェースを介す）と、ｅＮｏｄｅＢ９００と別のｅＮｏｄｅＢ間の通信（Ｘ２インターフェースを介す）とのためのインターフェース９１０を含む。ダウンリンクパケットはインターフェース９００を介しアクセスゲートウェイから受信され、パケットプロセッサ９３０に渡される。通常動作中、ダウンリンクデータパケットは、当業者に周知の従来の手段を使用する無線送受信機９２０を使用して、１つまたは複数のユーザ端末に送信される。
【００４０】
パケットプロセッサ９３０（１つまたは複数のマイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ等を含んでよい）は、パケット分類器９３２と転送ポリシーエンジン９３４を含むいくつかの機能を提供するようにプログラムされる。パケットプロセッサ９３０はまた、ｅＮｏｄｅＢ９００内の無線送受信機９２０と他のハードウェアの制御だけでなく、他の処理９３６（例えば、様々なレイヤ１、レイヤ２機能を含む）を含む。当業者に周知のように、パケットプロセッサ９３０は、１つまたは複数のメモリ回路９４０に格納されたソフトウェアおよび／またはファームウェアを実行するように構成されてよい。メモリ回路９４０（フラッシュメモリ、ランダムアクセスメモリ、読み取り専用メモリ、磁性記憶装置、光記憶装置等の様々な組合せの任意のものを含んでよい）は、プログラムコードに加え、本明細書に記載の方法の任意のものを実行する際にパケットプロセッサ９３０により使用される操作データを含んでよい。パケットプロセッサ９３０は、このようにしてパケット交換無線通信システムにおけるハンドオーバー中にパケットを転送するための本明細書に記載の方法のうちの１つまたは複数を実行するように構成されてよい。
【００４１】
当業者はまた、無線通信システムにおけるｅＮｏｄｅＢを参照して本明細書で説明された方法が移動端末４２０での使用に適応され得るということを十分に理解するだろう。したがって、以下の説明は送信元基地局から目標基地局にハンドオーバー中の移動局４２０において実施されるような本発明のいくつかの実施形態に関する。移動局４２０は１つまたは複数のアップリンクベアラ（および／または論理チャネル）を支援することができる。上述のダウンリンクシナリオにおけるように、各アップリンクベアラ／論理チャネルは、許容可能な遅延、重複に対する感度、および損失／信頼性に関し異なる品質特性を有してよい。同様に、各論理チャネルは、それぞれが異なるサービス要件を有する２つ以上のＩＰフローを含むことができる。したがって１つまたは複数の実施形態では、移動局４２０は、複数のベアラの第１のサブセットに関しては目標基地局にデータの未処理のデータ単位を再送信し、かつ複数のベアラの第２のサブセットに関しては目標基地局にデータの未処理のデータ単位を再送信しないように構成されてよい。同様に、端末４２０が遅延、重複と損失に対する感度などの異なる品質特性を有する複数の（ＩＰ）データフローを支援する場合、移動局４２０はデータフローの第１のサブセットに関しては目標基地局にデータの未処理のデータ単位を再送信し、かつデータフローの第２のサブセットに関しては目標基地局にデータの未処理のデータ単位を再送信しないように構成されてよい。論理チャネルまたはＩＰフローに対応するパケットは、上に検討された手法のうちの１つまたは複数に従って分類されてよい。
【００４２】
移動局４２０の別の実施形態は、上述の方法の要素を組み合わすことができる。例えば、移動端末４２０は、ｅＮｏｄｅＢから移動局４２０に送信されたリンクレイヤ状態通知に基づいて未処理のデータ単位の数についての知識を有することができ、この送信状態情報は、パケットを分類しパケットが送信されるべきかどうかを判断するために使用されてよい。いくつかの実施形態では、移動局４２０は１つまたは複数のベアラの状態通知を要求するように構成されてよく、他の実施形態では、移動局４２０はいくつかのＩＰフローのうちの１つまたは複数を運ぶベアラの状態通知を要求するように構成されてよい。
【００４３】
これらおよび他の変形と拡張とを鑑みて、当業者は、前述の説明と添附図面がパケット交換無線通信システムにおけるハンドオーバー中にデータパケットを転送するために本明細書で教示された方法と装置の非限定的な例を表す（本方法および／または装置がＬＴＥシステムまたは別の無線通信システムで採用されるかどうかにかかわらず）ことを理解するだろう。したがって本明細書で教示された本発明の装置と技術は前述の説明と添付図面により限定されるものではない。むしろ、本発明は以下の特許請求の範囲とそれらの法的な等価物によってのみ限定される。
【図１】
2010522466.tif 000003
【図２Ａ】
2010522466.tif 000004
【図２Ｂ】
2010522466.tif 000005
【図３】
2010522466.tif 000006
【図４】
2010522466.tif 000007
【図５】
2010522466.tif 000008
【図６Ａ】
2010522466.tif 000009
【図６Ｂ】
2010522466.tif 000010
【図７】
2010522466.tif 000011
【図８】
2010522466.tif 000012
【図９】
2010522466.tif 000013
【国際調査報告】
2010522466.tif 000014
2010522466.tif 000015
2010522466.tif 000016