JP6321643B2 - 複数の基地局に向けての端末の多重的な接続性を可能とする、ベアラのサブセットをハンドオーバさせるためのノード及び方法 - Google Patents

Description

ここで提示される例示的な実施形態は、ソース基地局によりサービスされている無線端末に関連付けられるベアラのサブセットについてのハンドオーバを提供するための、ソース及びターゲット基地局並びにそれらの中での対応する方法を対象とし、無線端末の少なくとも１つのベアラはソース基地局と接続したまま残される。ベアラのサブセットは、無線端末に関連付けられるベアラの総数よりも少ないか又は等しい。

ユーザフレンドリーなスマートフォン及びタブレットの普及によって、モバイルネットワーク上の映像ストリーミングといった高データレートのサービスの使用が日常的になり、モバイルネットワーク内のトラフィックの量を大きく増加させつつある。よって、一層増加するユーザの需要に沿ってモバイルネットワークのキャパシティを増加させ続けることを保証することが、モバイルネットワークコミュニティにおいて強い緊急性を帯びている。ＬＴＥ（Long Term Evolution）といった最新のシステムは、特に干渉軽減技法と連結される場合に、理論的なシャノン限界に非常に近いスペクトル効率を有する。最新の技術をサポートするための現行のネットワークの継続的なアップグレード、及び単位エリア当たりの基地局数の高密度化が、増加するトラフィック需要を充足するために最も広く用いられているアプローチの２つである。

高度な注目を集めているまた別のアプローチは、ヘテロジーニアスネットワークを使用することであり、ヘテロジーニアスネットワークでは、旧来の予め計画されるマクロ基地局（マクロレイヤとして知られる）を、相対的に非計画的なやり方で配備され得る複数の低電力基地局が補完する。３ＧＰＰ（3rd Generation Partnership Project）は、ヘテロジーニアスネットワークのコンセプトを、ＬＴＥリリース１１といったＬＴＥの最新の拡張における研究のコアアイテムの１つとして取り入れた。ヘテロジーニアスネットワークを実現するために、ピコ基地局、フェムト基地局（ホーム基地局若しくはＨｅＮＢとしても知られる）、中継機（relays）、及びＲＲＨ（remote radio heads）といったいくつもの低電力基地局が定義されている。ＬＴＥリリース１２のための初期の議論は既に開始されており、研究のために提案されたアイテムの１つは、１つよりも多くのｅＮＢから１つのユーザ機器（ＵＥ）へ同時にサービスする可能性である。ＬＴＥの現行のレガシーのハンドオーバの仕組みは、これをサポートするために更新されなければならない。

図１は、ヘテロジーニアスネットワークの一例を提供しており、移動端末１０１は、例えばマクロ基地局（あるいは“アンカーｅＮＢ”）４０１Ａからのアンカーフロー及びピコ基地局（あるいは“補助ｅＮＢ”）４０１Ｂからの補助フローといった複数のフローを使用する。ヘテロジーニアスネットワークの使用における問題の１つは、アンカーフロー及び補助フロー上のユーザプレーンベアラをそれぞれいかにマッピングするか、である。単純な解決策は、例えば第１のベアラがアンカーフローを使用し第２のベアラが補助フローを使用する、といったように各ベアラを単一のフロー上にマッピングすることである。

ヘテロジーニアスネットワークにおいてベアラをマッピングするために単一のフローを用いる場合、いくつもの問題が存在する。そうした問題の一例は、頻繁なハンドオーバの必要性である。ユーザデータのスループットを受け入れ可能なレベルに維持するために、ユーザプレーンベアラは、無線リンク条件及び移動端末のスピードに依存して、補助フローからアンカーフローへ又はその逆へと頻繁に“ハンドオーバされ”なければならないかもしれない。さらに、各ハンドオーバは、ネットワークと移動端末との間及びネットワーク内部にもシグナリングをもたらす。多くの移動端末及びピコ基地局があれば、ネットワークノード内のシグナリング負荷はかなりのものになり、おそらくは制限的な要因になり得る。

追加的に、ユーザプレーンベアラのこのハンドオーバの期間中に、データフローに不可避的な“グリッチ（glitch）”がもたらされる。なぜなら、ハンドオーバ手続の持続期間中にデータパケットを送信することはできないからである。データフローは、ソース基地局の代わりにターゲット基地局を介してルーティングされる必要がある。ソース基地局内に所在しているデータは、Ｘ２といったサイト間インタフェースを介して、ターゲット基地局へと転送されることができる。パケットは最終的には移動機（mobile）へと到達することになるとは言え、ある種の定期的なパケット送信に依拠するリアルタイムサービスといったいくつかのサービスは、それでも影響を受けるであろう。よって、所与の移動端末についての頻繁なハンドオーバは、そのため少なくともリアルタイムサービスへの影響を有し得る。

そこで、ここで提示される例示的な実施形態のいくつかの少なくとも１つの例示的な目的は、ヘテロジーニアスネットワークにおいてベアラをマッピングする効率的な手段を提供することである。その例示的な実施形態のいくつかによれば、複数のｅＮＢへのユーザ機器の多重的な接続性の利点を活用する、ハンドオーバのための最適化されたアプローチであって、ＬＴＥにおいて使用されている現在のユーザ機器レベルのアプローチではなくむしろベアラレベルでハンドオーバをトリガし及び／又は実行することの可能なアプローチが提案される。様々なハンドオーバトリガ条件を設定することができ、それら条件と共に、負荷及びユーザ機器／ネットワークのバッファ条件といった他の要因に基づいて、ユーザ機器のベアラのサブセットのみの選択的なハンドオーバが実行される。

ここで議論される例示的な実施形態は、ソース及びターゲットｅＮＢの間で選択的にハンドオーバを実行することを可能とし、それにより、ユーザ機器がターゲットへ完全にハンドオーバされるというレガシーのハンドオーバ実行法よりも高いシステムの柔軟性が生み出される。ここで提示される例示的な実施形態のいくつかの少なくとも１つの例示的な利点は、ターゲットにとって受け入れ可能でないベアラがソースで維持され得るために、全てのユーザ機器のベアラを稼動状態で維持できることである。

他の例示的な利点は、ユーザ機器レベルよりもむしろ１つのベアラレベルでハンドオーバをトリガできることである。例えば、ソースｅＮＢは、自身が有するＶｏＩＰサービスといった不連続性を許容できないベアラを、ソースの無線条件がターゲットよりも非常に低くなるまで維持してよく、一方で、ファイルダウンロードといったキャパシティは大きく欠乏しているものの中断には高い耐性のあるベアラを、ソースでの無線条件がそれほど悪くない場合であってもターゲットへハンドオーバしてよい。

さらなる例示的な利点は、複数のｅＮＢにてデータ負荷を分担しながら、１つのｅＮＢにて制御プレーンを保持できることである。これは、ネットワーク共有といったいくつかの可能性を開く。例えば、複数の事業者が、自身のマクロにおいてのみシグナリング無線ベアラを保持しつつ、データベアラのためにピコノードを共有することができる。

他の例示的な利点は、ソース及び／若しくはターゲットからのハンドオーバ命令の送信、又はターゲットへの測定報告の送信といった、制御プレーンダイバーシティが、多重的な接続性でむしろ簡単になることである。

またさらなる例示的な利点は、補助ノード又はアンカーノード上のＲＬＣをより高速に回復し得ることである。ユーザ機器のコンテキストはアンカー側に所在するために補助側の回復は容易であり、補助側はネットワークから容易にコンテキストを取得し得るためにアンカーの回復もまた高速になる。

従って、例示的な実施形態のいくつかは、ソース基地局における、上記ソース基地局によりサービスされれている無線端末に関連付けられるベアラのサブセットについてのハンドオーバを提供するための方法を対象とする。ベアラの上記サブセットは、上記無線端末に関連付けられる全てのベアラよりも少ないか又は等しい。上記ソース基地局は、無線通信ネットワーク内に含まれる。上記方法は、ハンドオーバ手続についての必要性を判定することを含む。上記方法は、上記無線端末に関連付けられるベアラの上記サブセットを選択すること、をも含む。上記方法は、ベアラの上記サブセットについてのハンドオーバ要求をターゲット基地局へ送信すること、をさらに含み、上記無線端末の少なくとも１つのベアラは、上記ソース基地局に接続したまま残される。

例示的な実施形態のいくつかは、ソース基地局によりサービスされれている無線端末に関連付けられるベアラのサブセットについてのハンドオーバを提供するための上記ソース基地局を対象とする。ベアラの上記サブセットは、上記無線端末に関連付けられる全てのベアラよりも少ないか又は等しい。上記ソース基地局は、無線通信ネットワーク内に含まれる。上記ソース基地局は、ハンドオーバ手続についての必要性を判定するように構成される、処理回路を含む。上記処理回路は、上記無線端末に関連付けられるベアラの上記サブセットを選択するようにさらに構成される。上記ソース基地局は、ベアラの上記サブセットについてのハンドオーバ要求をターゲット基地局へ送信するように構成される無線回路、をさらに含み、上記無線端末の少なくとも１つのベアラは、上記ソース基地局に接続したまま残される。

例示的な実施形態のいくつかは、ターゲット基地局における、ソース基地局によりサービスされれている無線端末に関連付けられるベアラのサブセットについてのハンドオーバを提供するための方法を対象とする。ベアラの上記サブセットは、上記無線端末に関連付けられる全てのベアラよりも少ないか又は等しい。上記ターゲット基地局は、無線通信ネットワーク内に含まれる。上記方法は、上記ソース基地局から、ベアラの上記サブセットについてのハンドオーバ要求を受信すること、を含み、上記無線端末の少なくとも１つのベアラは上記ソース基地局に接続したまま残される。上記方法は、上記ハンドオーバ手続に関連してベアラの上記サブセットの受け入れ可能性を解析すること、をさらに含む。上記方法は、上記ソース基地局へ、上記解析の結果を含むハンドオーバ確認応答メッセージを送信すること、をも含む。

例示的な実施形態のいくつかは、ソース基地局によりサービスされれている無線端末に関連付けられるベアラのサブセットについてのハンドオーバを提供するためのターゲット基地局を対象とする。ベアラの上記サブセットは、上記無線端末に関連付けられる全てのベアラよりも少ないか又は等しい。上記ターゲット基地局は、無線通信ネットワーク内に含まれる。上記ターゲット基地局は、上記ソース基地局から、ベアラの上記サブセットについてのハンドオーバ要求を受信するように構成される無線回路、を含み、上記無線端末の少なくとも１つのベアラは、上記ソース基地局に接続したまま残される。上記ターゲット基地局は、上記ハンドオーバ手続に関連してベアラの上記サブセットの受け入れ可能性を解析するように構成される処理回路、をさらに含む。上記無線回路は、上記ソース基地局へ、解析された上記受け入れ可能性の結果を含むハンドオーバ確認応答メッセージを送信する、ようにさらに構成される。

［定義］
３ＧＰＰ 3rd Generation Partnership Project
ＡＭＢＲ Aggregate Maximum Bit Rate
ＡＰ Application Protocol
ＡＰＮ Access Point Name
ＡＲＰ Allocation and Retention Priority
ＡＲＱ Automatic Repeat reQuest
ＢＣＨ Broadcast Channel
ＣＩＯ Cell Individual Offset
ＣＮ Core Network
ＣＲＳ Cell specific Reference Symbol
ＣＳＧ Closed Subscriber Group
ＤＬ Downlink
ＤＭ Demodulation
ＤＲＢ Data Radio Bearer
Ｅ−ＲＡＢ E-UTRAN Radio Access Bearers
Ｅ−ＵＴＲＡ Evolved Universal Terrestrial Radio Access
Ｅ−ＵＴＲＡＮ Evolved UMTS Terrestrial Radio Access Network
ｅＮＢ／ｅＮｏｄｅＢ enhanced Node B(base station)
ＥＰＣ Evolved Packet Core
ＥＰＳ Evolved Packet System
ＥＭＭ Evolved Packet System Connection Management
ＧＢＲ Guaranteed Bit Rate
ＧＵＭＭＥＩ Globally Unique Mobility Management Entity Identifier
ＨＡＲＱ Hybrid Automatic Repeat reQuest
ＨｅＮＢ Home eNB
ＨＯ Handover
ＨＯＭ Handover Margin
ＨＳＰＡ High-Speed Packet Access
ＩＥ Information Element
ＩＤ Identity
ＩＰ Internet Protocol
ＬＴＥ Long Term Evolution
ＭＡＣ Medium Access Control
ＭＢＲ Maximum Bit Rate
ＭＭＥ Mobility Management Entity
ＭＴＣＰ Multi-path Transmission Control Protocol
ＮＡＳ Non-Access Stratum
ＯＡＭ Operation and Maintenance
ＰＧＷ PDN Gateway
ＰＢＣＨ Physical Broadcast CHannel
ＰＣｅｌｌ Primary Cell
ＰＣＦＩＣＨ Physical Control Format Indicator CHannel
ＰＣＩ Physical Cell Identity
ＰＤＣＣＨ Physical Downlink Control CHannel
ＰＤＣＰ Packet Data Convergence Protocol
ＰＤＮ Packet Data Network
ＰＤＳＣＨ Physical Downlink Shared CHannel
ＰＤＵ Packet Data Unit
ＰＨＩＣＨ Physical Hybrid ARQ Indicator CHannel
ＰＳＳ Primary Synchronization Signal
ＱＣＩ QoS Class Identifier
ＱｏＳ Quality of Service
ＲＬＣ Radio Link Control
ＲＡＢ Radio Access Bearer
ＲＡＴ Radio Access Technology
ＲＥ Resource Element
ＲＬＣ Radio Link Control
ＲＬＦ Radio Link Failure
ＲＲＣ Radio Resource Control
ＲＲＨ Remote Radio Head
ＲＲＭ Radio Resource Management
ＲＳ Reference Signal
ＲＳＣＰ Received Signal Code Power
ＲＳＲＰ Reference Signal Received Power
ＲＳＲＱ Reference Signal Received Quality
Ｒｘ Receive
ＳＧＷ Serving Gateway
ＳＣｅｌｌ Secondary Cell
ＳＣＴＰ Stream Control Transmission Protocol
ＳＤＦ Service Data Flow
ＳＤＵ Service Data Unit
ＳＦＮ System Frame Number
ＳＩＮＲ Signal to Interference plus Noise Ratio
ＳＲＢ Signaling Radio Bearer
ＳＲＶＣＣ Single Radio Voice Call Continuity
ＳＳＳ Secondary Synchronization Signal
ＴＣＰ Transmission Control Protocol
ＴＴＴ Time To Trigger
Ｔｘ Transmit
ＵＥ User Equipment
ＵＬ Uplink
ＵＭＴＳ Universal Mobile Telecommunications System
ＵＴＲＡ Universal Terrestrial Radio Access
ＵＴＲＡＮ Universal Terrestrial Radio Access Network
ＶｏＩＰ Voice over Internet Protocol

上述の内容は、例示的な実施形態の以下のより具体的な説明と共に、添付図面に描かれているように、より詳細に説明されるであろう。添付図面において、同様の参照符号は、異なる図を通じて同じ部分を指す。図面は必ずしも等尺ではなく、代わりに例示的な実施形態を描く際に強調がなされている。

無線端末への同時のアンカー及び補助フローを伴うヘテロジーニアス配備の例示図である。 Ｅ−ＵＴＲＡＮアーキテクチャの例示図である。 Ｅ−ＵＴＲＡＮとＥＰＣとの間の機能分離を描く概略図である。 ユーザプレーンプロトコルスタックである。 制御プレーンプロトコルスタックである。 ユーザプレーン及び制御プレーンデータフローである。 ベアラサービスアーキテクチャの例示図である。 高電力マクロノード及び低電力ピコノードを伴うヘテロジーニアス配備の例示図である。 ヘテロジーニアス配備の例示図であり、ピコノードはそれ自身のセルに対応する。 ヘテロジーニアス配備の例示図であり、ピコノードはそれ自身のセルに対応しない。 マクロ及びピコから端末への同一の送信を伴うＳＦＮ動作の図である。 無線端末がアンカー基地局及び補助基地局の双方との多重的な接続を有するソフトセル動作の図である。 多重的な又は二重の接続性のためのプロトコルアーキテクチャの例示図である。 ハンドオーバトリガの例示図である。 ＬＴＥにおけるＸ２ハンドオーバの一例を示すメッセージ図である。 ここで提示される例示的な実施形態のいくつかに係るソース基地局の例示的なノード構成である。 ここで提示される例示的な実施形態のいくつかに係るターゲット基地局の例示的なノード構成である。 ここで提示される例示的な実施形態のいくつかに係る、図１６のソース基地局の例示的な動作を描いたフロー図である。 ここで提示される例示的な実施形態のいくつかに係る、図１７のターゲット基地局の例示的な動作を描いたフロー図である。

ここで提示される例示的な実施形態の完全な理解を提供するために、限定ではなく説明の目的で、以下の説明において、固有のコンポーネント、エレメント、技法などの特定の詳細が説明される。しかしながら、例としての実施形態は、それら特定の詳細から離れた他のやり方で実践されてもよい。他の例において、よく知られた方法及びエレメントの詳細な説明は、例としての実施形態の説明を曖昧にしないために省略される。

［概要］
ここで提示される例示的な実施形態をよりよく説明するために、まず問題が最初に識別され議論されるであろう。Ｅ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network）は、拡張ノードＢ（ｅＮＢあるいはｅＮｏｄｅＢ）と呼ばれる基地局４０１を含み、基地局４０１は、ユーザ機器に向けたＥ−ＵＴＲＡのユーザプレーン及び制御プレーンプロトコルの終端を提供する。基地局あるいはｅＮＢ４０１は、互いにＸ２インタフェースの手段により相互接続される。ｅＮＢ４０１は、Ｓ１インタフェースの手段によりＥＰＣ（Evolved Packet Core）とも接続され、より具体的には、Ｓ１−ＭＭＥインタフェースの手段によりＭＭＥ（Mobility Management Entity）１１５と、Ｓ１−Ｕインタフェースの手段によりサービングゲートウェイ（ＳＧＷ）１１７と接続される。Ｓ１インタフェースは、ＭＭＥ／ＳＧＷとｅＮＢとの間で、多対多の関係をサポートする。Ｅ−ＵＴＲＡＮアーキテクチャは、図２に示されている。

ｅＮＢ４０１は、無線リソース管理（ＲＲＭ）、無線ベアラ制御、流入制御、サービングゲートウェイに向けたユーザプレーンデータのヘッダ圧縮、サービングゲートウェイに向けたユーザプレーンデータのルーティングといった機能性をホスティングする。ＭＭＥ１１５は、ユーザ機器とＣＮとの間のシグナリングを処理する制御ノードである。ＭＭＥ１１５の主な機能は、ＮＡＳ（Non Access Stratum）プロトコルを介してハンドリングされる、接続管理及びベアラ管理に関する。ＳＧＷ１１７は、ユーザ機器のモビリティのためのアンカーポイントであり、ユーザ機器１０１のページング中の一時的なＤＬデータバッファリング、正確なｅＮＢへのパケットルーティング及び転送、課金のための情報収集、並びに合法的傍受といった他の機能性をも含む。ＰＤＮゲートウェイ（ＰＧＷ）１１９は、ユーザ機器のＩＰアドレス割り当てに加えて、サービス品質（ＱｏＳ）の執行について責任を有するノードである（これは、後のセクションにおいてさらに説明される）。

図３は、３ＧＰＰ ＴＳ３６．３００において言及されている様々なノードの機能性の要約を与え、そこでの言及は様々なノードの機能性の詳細を提供する。図３において、実線のボックスは論理的なノードを示し、破線のボックスは制御プレーンの機能エンティティを示し、網掛けされたボックスは無線プロトコルレイヤを示す。

無線プロトコルアーキテクチャ
Ｅ−ＵＴＲＡＮの無線プロトコルアーキテクチャは、ユーザプレーン及び制御プレーンへと分割される。図４は、ユーザプレーンについてのプロトコルスタックを示している。ユーザプレーンプロトコルスタックは、ＰＤＣＰ（Packet Data Convergence Protocol）、ＲＬＣ（Radio Link Control）、及びＭＡＣ（Medium Access Control）からなり、それらはｅＮＢ４０１において終端される。ＰＤＣＰは、ユーザプレーンにおいてＩＰパケットを管理し、ヘッダ圧縮、セキュリティ、並びにハンドオーバ期間中の並び替え及び再送といった機能性を実行する。ＲＬＣレイヤは、主に、エアインタフェース上で実際に送信されるべきサイズに適合させるための、ＰＤＣＰパケットのセグメント化（及び対応する組立て）について責任を有する。ＲＬＣは、非確認応答モード又は確認応答モードのいずれかで動作可能であり、後者は再送をサポートする。ＭＡＣレイヤは、様々な無線ベアラからのデータの多重化を実行し、パケットのサイズについてＲＬＣへ通知するのはこのＭＡＣレイヤであり、パケットのサイズは各無線ベアラの所要ＱｏＳとユーザ機器１０１にとって利用可能なその時点のキャパシティとに基づいて決定される。

図５は、制御プレーンのプロトコルスタックを示している。ＲＲＣ（Radio Resource Control）レイヤよりも下のレイヤ群は、制御プレーンではヘッダ圧縮が存在しないことを除いて、ユーザプレーンと同じ機能性を実行する。ＲＲＣの主な機能は、システム情報のブロードキャスト、ＲＲＣ接続制御（ＲＲＣ接続の確立、修正及び解放、シグナリング無線ベアラ（ＳＲＢ）及びデータ無線ベアラ（ＤＲＢ）の確立、ハンドオーバ、より下位のプロトコルレイヤの構成、無線リンク障害回復など）、並びに測定の構成及び報告である。ＲＲＣプロトコルの機能性及び手続の詳細は、３ＧＰＰ ＴＳ３６．３３１において見い出され得る。

ユーザ機器あるいは無線端末１０１は、概して、Ｓ１インタフェース上でｅＮＢ４０１の範囲内でｅＮＢ ＵＥ Ｓ１ＡＰ ＩＤで一意に識別される。ＭＭＥ１１５は、ｅＮＢ ＵＥ Ｓ１ＡＰ ＩＤを受信すると、そのユーザ機器１０１のためのユーザ機器関連の論理的なＳ１接続の持続期間にわたってそれを記憶する。一度ＭＭＥ１１５により知得されると、このＩＥは、全てのユーザ機器関連のＳ１−ＡＰシグナリングに含められる。ｅＮＢ ＵＥ Ｓ１ＡＰ ＩＤは、ｅＮＢ４０１の範囲内で一意であり、ユーザ機器は、ハンドオーバ後にターゲットｅＮＢにより新たなＳ１ＡＰ ＩＤを割り当てられる。

ＭＭＥ側からは、ユーザ機器１０１は、ＭＭＥ ＵＥ Ｓ１ＡＰ ＩＤを用いて一意に識別される。ｅＮＢ４０１は、ＭＭＥ ＵＥ Ｓ１ＡＰ ＩＤを受信すると、そのユーザ機器１０１のためのユーザ機器関連の論理的なＳ１接続の持続期間にわたってそれを記憶する。一度ｅＮＢ４０１により知得されると、このＩＥは、全てのユーザ機器関連のＳ１−ＡＰシグナリングに含められる。ＭＭＥ ＵＥ Ｓ１ＡＰ ＩＤは、ＭＭＥ１１５の範囲内で一意であり、ユーザ機器のＭＭＥが変化した場合、例えば異なるＭＭＥへ接続している２つのｅＮＢの間のハンドオーバの場合に、変更される。

ユーザプレーン及び制御プレーンのデータのフローが図６に示されている。（キャリアアグリゲーションのケースのようにユーザ機器がマルチキャリアをサポートしない限り）ユーザ機器１０１ごとに１つのＭＡＣエンティティのみが存在し、このＭＡＣエンティティの下では、迅速な再送のために複数のハイブリッドＡＲＱ（ＨＡＲＱ）プロセスが同時に稼働中であり得る。各無線ベアラについて別個のＲＬＣエンティティが存在し、無線ベアラがＰＤＣＰを使用するように構成される場合、当該ベアラのために１つ別のＰＤＣＰエンティティもまた存在する。ベアラは、ユーザ機器にとって専用である場合にのみ、ＰＤＣＰを使用するように構成される（即ち、マルチキャスト及びブロードキャストデータは制御及びユーザプレーンの双方においてＰＤＣＰを利用せず、ＰＤＣＰは、制御プレーンでは専用制御メッセージのために、ユーザプレーンでは専用ＵＬ／ＤＬデータのためにのみ使用される）。

送信側において、各レイヤは、より上位のレイヤからサービスデータユニット（ＳＤＵ）を受け取り、より下位のレイヤへプロトコルデータユニット（ＰＤＵ）を送出する。例えば、ＲＬＣに向けてはＰＤＣＰ ＰＤＵが送出され、それらはＲＬＣの視点からはＲＬＣ ＳＤＵであり、転じて、ＭＡＣに向けてＲＬＣ ＰＤＵが送出され、それらはＭＡＣの視点からはＭＡＣ ＳＤＵである。受信側では、処理は逆に進められ、即ち、各レイヤはＳＤＵをその上のレイヤへと渡し、それらはＰＤＵとして認知される。

サービス品質
ユーザ機器１０１は、各々が異なるＱｏＳ要件を有しながら同時に稼働する複数のアプリケーションを有するかもしれず、例えば、ＶｏＩＰ、ブラウジング、ファイルダウンロードなどである。これら様々な要件をサポートする目的で、各々がＱｏＳに関連付けられる様々なベアラがセットアップされる。ＥＰＳベアラ／Ｅ−ＲＡＢ（Radio Access Bearer）は、ＥＰＣ／Ｅ−ＵＴＲＡＮ内のベアラレベルＱｏＳ制御のための粒度のレベルである。即ち、同じＥＰＳベアラへマッピングされるサービスデータフロー（ＳＤＦ）は、同じベアラレベルのパケット転送の扱いを受ける（例えば、スケジューリングポリシー、キュー管理ポリシー、レートシェイピングポリシー、ＲＬＣ構成など）。

ユーザ機器１０１がＰＤＮへ接続すると、１つのＥＰＳベアラ／Ｅ−ＲＡＢが確立され、それは、当該ＰＤＮへの常時オン（always-on）のＩＰ接続性をユーザ機器１０１へ提供するために、ＰＤＮ接続の生存期間を通じて確立されたまま残される。当該ベアラを、デフォルトベアラという。同じＰＤＮに向けて確立される任意の追加的なＥＰＳベアラ／Ｅ−ＲＡＢを、専用ベアラ（dedicated bearer）という。デフォルトベアラの初期のベアラレベルのＱｏＳパラメータ値は、加入データに基づいて、ネットワークにより割り当てられる。専用ベアラを確立し又は修正する決定は、ＥＰＣによってのみなされてよく、ベアラレベルのＱｏＳパラメータ値は、常にＥＰＣにより割り当てられる。

ＥＰＳベアラ／Ｅ−ＲＡＢに関連付けられる保証ビットレート（ＧＢＲ）値に関する専用ネットワークリソースがベアラ確立／修正において（例えば、ｅＮＢ内の流入制御機能により）永続的に割り当てられる場合、当該ＥＰＳベアラ／Ｅ−ＲＡＢをＧＢＲベアラという。そうでない場合、ＥＰＳベアラ／Ｅ−ＲＡＢを非ＧＢＲベアラという。デフォルトベアラが非ＧＢＲベアラであるものとされる一方、専用ベアラは、ＧＢＲベアラ又は非ＧＢＲベアラのいずれかであってよい。

ＥＰＳベアラのサービスアーキテクチャが図７に示されている。ＥＰＳベアラのパケットは、ユーザ機器１０１とｅＮＢ４０１との間で無線ベアラ上で移送される。Ｓ１ベアラは、ｅＮＢ４０１とＳＧＷ１１７との間でＥＰＳベアラのパケットを移送する。Ｅ−ＲＡＢは、実質的にはこれら２つのベアラ（即ち、無線ベアラ及びＳ１ベアラ）の連結であり、当該２つのベアラは、１対１の形式でマッピングされる。Ｓ５／Ｓ８ベアラは、ＳＧＷ１１７とＰＧＷ１１９との間でＥＰＳベアラのパケットを移送し、ＥＰＳベアラを完成させる。ここで、Ｅ−ＲＡＢとＳ５／Ｓ８ベアラとの間にも１対１のマッピングが存在する。

ベアラレベル（即ち、ベアラごと又は統合ベアラごと）のＱｏＳパラメータは、ＱＣＩ、ＡＲＰ、ＧＢＴ及びＡＭＢＲである。各ＥＰＳベアラ／Ｅ−ＲＡＢ（ＧＢＲ及び非ＧＢＲ）は、次のベアラレベルＱｏＳパラメータに関連付けられる：ＱＣＩ及びＡＲＰ。ＱｏＳクラスインジケータ（ＱＣＩ）は、ベアラレベルのパケット転送の扱い（例えば、スケジューリングの重み、受け入れ閾値、キュー管理閾値、リンクレイヤプロトコル構成など）を制御するノード固有のパラメータへアクセスするためのリファレンスとして使用されるスカラーであって、ｅＮｏｄｅＢ４０１を所有する事業者により予め構成されている。ＱＣＩは、例えばＰＧＷ１１９及びＳＧＷ１１７といったユーザプレーンチェーン内の他のノードにおけるベアラレベルのパケット転送の扱いを制御するノード固有のパラメータへリファレンスするためにも使用され得る。９つのＱＣＩ値が標準化されており、それらクラスの詳細な要件は、３ＧＰＰ ＴＳ２３．４２０Ａにおいて見い出され得る。ＡＲＰ（Allocation and Retention Priority）は、リソース限界の場合にベアラの確立／修正要求を受け入れ得るか拒絶する必要があるかを決定するために使用される。加えて、ＡＲＰは、例外的なリソース限界（例えば、ハンドオーバ時）の期間中にどのベアラを破棄すべきかを決定するために、ｅＮｏｄｅＢ４０１、ＳＧＷ１１７又はＰＧＷ１１９により使用され得る。

各ＧＢＲベアラは、追加的に、ベアラレベルＱｏＳパラメータであるＧＢＲ及びＭＢＲに関連付けられる。保証ビットレート（ＧＢＲ）は、ＧＢＲベアラにより提供されるものと期待され得るビットレートである。最大ビットレート（ＭＢＲ）は、ＧＢＲベアラにより提供されるものと期待され得る最大のビットレートである。ＭＢＲは、ＧＢＲよりも大きいか又は等しくすることができる。

各ＡＰＮアクセスは、ユーザ機器１０１により、ＡＰＮ別統合最大ビットレート（ＡＰＮ−ＡＭＢＲ）に関連付けられる。ＡＰＮ−ＡＭＢＲは、全ての非ＧＢＲベアラをまたいで、及び同じＡＰＮの全てのＰＤＮ接続をまたいで提供されるものと期待され得る統合的なビットレートについての限度を設定する。ＥＭＭ−ＲＥＧＩＳＴＥＲＥＤ状態にある各ユーザ機器１０１は、ユーザ機器別統合最大ビットレート（ＵＥ−ＡＭＢＲ）として知られるベアラ統合レベルのＱｏＳパラメータに関連付けられる。ＵＥ−ＡＭＢＲは、ユーザ機器１０１の全ての非ＧＢＲベアラをまたいで提供されるものと期待され得る統合的なビットレートを制限する。

ヘテロジーニアスネットワーク及びソフト／共有セル
図８に示したような、重複するカバレッジエリアを伴って運用する異なる送信電力を有する複数のネットワーク送信ノードを含む、いわゆるヘテロジーニアス配備又はヘテロジーニアスネットワークの使用は、セルラーネットワークの興味深い配備戦略であると考えられる。そうした配備において、補助基地局４０１Ｂとして利用され得る低電力ノード（“ピコノード”）は、典型的には、高データレート（メガビット／秒）を提供すると共に、高キャパシティ（ユーザ／平方メートル又はメガビット／秒／平方メートル）を、それが必要とされ／望まれる局所的なエリアにおいて提供するものと想定され、一方で、アンカー基地局４０１Ａとして利用され得る高電力ノード（“マクロノード”）は、エリア全体のカバレッジを提供するものと想定される。実際には、マクロノード４０１Ａは、現在のところ配備されているマクロセルに対応してよく、ピコノード４０１Ｂは、後に配備されるノードであって、マクロセルのカバレッジエリア内の必要な場所でキャパシティ及び／又は達成可能なデータレートを拡張する。

ヘテロジーニアス配備のピコノード４０１Ｂは、図９に示したように、それ自身のセル（“ピコセル”）に対応し得る。これは、ダウンリンク及びアップリンクのデータ送信／受信に加えて、ピコノードがセルに関連付けられる共通信号／チャネルの全セットをも送信することを意味する。ＬＴＥの文脈では、これは、ピコセルの物理セルＩＤ（Physical Cell Identity）に対応するプライマリ及びセカンダリ同期信号（ＰＳＳ及びＳＳＳ）を含む。やはりセルの物理セルＩＤに対応する、セル固有リファレンス信号（ＣＲＳ）もまた含まれる。ＣＲＳは、例えば、ダウンリンク送信のコヒーレントな復調を可能とするダウンリンクチャネル推定のために使用され得る。対応するピコセルのシステム情報を伴うブロードキャストチャネル（ＢＣＨ）がさらに含まれる。

ピコノード４０１Ｂが共通信号／チャネルを送信している際、端末（ＵＥ、ユーザ機器）１０１により、対応するピコセルを検出し及び選択し得る（例えば、接続し得る）。ピコノード４０１Ｂがそれ自身のセルに対応する場合、ＰＤＳＣＨ上のダウンリンクデータ送信に加えて、ＰＤＣＣＨ（並びにＰＣＦＩＣＨ及びＰＨＩＣＨ）上のいわゆるＬ１／Ｌ２制御シグナリングもまた、ピコノードから接続している端末へ送信される。Ｌ１／Ｌ２制御シグナリングは、例えば、セル内の端末へダウンリンク及びアップリンクのスケジューリング情報及びハイブリッドＡＲＱ関連情報を提供する。これは図９に示されている。

代替的に、ヘテロジーニアス配備内のピコノード４０１Ｂは、それ自身のセルに対応しなくてもよく、但し、重畳されるマクロセル４０１Ａのデータレート及びキャパシティの“拡張”を単に提供し得る。これは、“共有セル（shared cell）”あるいは“ソフトセル”として知られることがある。このケースにおいて、少なくともＣＲＳ、ＰＢＣＨ、ＰＳＳ及びＳＳＳは、マクロノード４０１Ａから送信される。ＰＤＳＣＨは、ピコノード４０１Ｂから送信され得る。ピコノード４０１ＢからＣＲＳが送信されないという事実にも関わらず、ＰＤＳＣＨの復調及び検出を可能とするために、ＰＤＳＣＨと併せてピコノード４０１ＢからＤＭ−ＲＳが送信されるべきである。そして、端末により、ユーザ機器固有のリファレンス信号は、ＰＤＳＣＨの復調／検出のために使用され得る。これは図１０に示されている。

上述したようにＣＲＳを送信しないピコノード４０１Ｂからデータを送信することは、端末（“非レガシー端末”）におけるＤＭ−ＲＳのサポートを要する。ＬＴＥでは、ＤＭ−ＲＳベースのＰＤＳＣＨ受信はＲｅｌ−１０においてＦＤＤ向けにサポートされており、一方でＬ１／Ｌ２制御シグナリングについては、ＤＭ−ＲＳベースの受信はＲｅｌ−１１に向けて計画されている。ＤＭ−ＲＳベースのＰＤＳＣＨ受信をサポートしていない端末（“レガシー端末”）について、共有セル設定における１つの可能性は、ＳＦＮ^２タイプの送信を活用することである。基本的には、レガシー端末のために必要な信号及びチャネルの同一のコピーがマクロ４０１Ａ及びピコ４０１Ｂノードから同時に送信される。端末の観点からは、これは単一の送信として見えることになる。図１１に示されているこうした動作は、ＳＩＮＲ利得のみを提供するであろう。これは、高データレートに解釈され得るが、同じセル内でサイトをまたいで送信リソースを再利用することができないために、キャパシティの改善にはならない。

マクロ４０１Ａはカバレッジを提供することができ、ピコ４０１Ｂはキャパシティの向上（即ち、カバレッジの穴を無くす）のためにのみ存在すると想定されてもよく、他の代替的なアーキテクチャは、ユーザ機器が、マクロとの接続性を常に保持し（“アンカー”フローと呼ばれる）、ピコとの接続性をピコのカバレッジエリア内にいる時に追加する（“補助”フローと呼ばれる）ことである。双方の接続がアクティブである場合、補助フローがデータのために使用される一方で、アンカーフローはいずれかの制御シグナリングのために使用されてよい。しかしながら、アンカーフローを介してデータを送信することも依然として可能であろう。このケースを、“多重的な接続性（multiple connectivity）”あるいは“二重の接続性（dual connectivity）”として定義する。これは図１２に示されている。なお、このケースでは、前のケースのように、システム情報はマクロ４０１Ａからのみ送信されるように示されているが、それをピコ４０１Ｂから送信することも依然として可能である。

ソフトセルのためのプロトコルアーキテクチャ
多重的な接続性をサポートする目的で、制御及びユーザプレーンの双方について複数のアーキテクチャオプションが可能である。ユーザプレーンについては、集中的なアプローチを取ることが可能であり、この場合、ＰＤＣＰは（又はＲＬＣでさえも）アンカーでのみ終端され、補助ノードはＲＬＣ（又はＭＡＣでさえも）レベルで終端する。非集中的なアプローチは、補助ノードをＰＤＣＰレベルで終端させることであろう。同様のアプローチを制御プレーンにおいて取ってもよく、例えば、ＰＤＣＰ／ＲＬＣが分散され又は集中化され、但しその上に、ＲＲＣを集中化し又は分散させる追加的な次元を有する。図１３は、例示的な制御及びユーザプレーンのアーキテクチャを示しており、ユーザプレーンは分散的なＰＤＣＰを採用し、一方で制御プレーンはアンカーにおいてＰＤＣＰレベルで集中化されている。なお、図中では、例えばアンカーリンク及び補助リンク上の１つのアプリケーションデータフローに属するパケットを分離する可能性が、マルチパスＴＣＰ（ＭＴＣＰ）のような上位レイヤの統合プロトコルを用いることにより実現され得る。

ユーザ機器測定
ユーザ機器は、主にモビリティをサポートするために、測定結果を報告するように構成され得る。３ＧＰＰ ＴＳ３６．３３１において仕様化されているように、Ｅ−ＵＴＲＡＮは、専用シグナリングの手段により、例えばRRCConnectionReconfigurationメッセージを用いて、RRC_CONNECTED中のユーザ機器に適用可能な測定構成を提供する。

多様な測定構成がユーザ機器へシグナリングされ得る。そうした測定構成の一例は、測定対象（measurement objects）である。測定対象は、例えばキャリア周波数など、何についてユーザ機器が測定を実行すべきかを定義する。測定対象は、考慮すべきセルのリスト（ホワイトリスト又はブラックリスト）に加えて、例えば周波数固有又はセル固有のオフセットといった関連付けられるパラメータをも含み得る。

測定構成の他の例は、報告構成である。報告構成は、周期的又はイベントトリガ型という、ユーザ機器に測定報告を送信させる基準に加えて、ユーザ機器がどの情報を報告すると期待されるかの詳細を含む。報告されるべき情報は、例えば、ＵＭＴＳについての受信信号符号電力（ＲＳＣＰ）又はＬＴＥについてのリファレンス信号受信電力（ＲＳＲＰ）、及びセルの数といった数量を含み得る。

他の例示的な構成は、測定ＩＤ（measurement identities）であり得る。測定ＩＤは、測定結果を識別し、適用可能な測定対象及び報告構成を定義する。各測定ＩＤは、１つの測定対象を１つの報告構成にリンク付けする。複数の測定ＩＤを構成することにより、同じ報告構成に１つよりも多くの測定対象をリンク付けすることに加えて、同じ測定対象に１つよりも多くの報告構成をリンク付けすることが可能である。測定ＩＤは、測定報告における参照番号として使用される。

さらなる構成の例は、数量構成（quantity configurations）である。数量構成は、各測定結果について使用されるべきフィルタリングを定義する。ＲＡＴタイプごとに１つの数量構成が構成され、測定量ごとに１つのフィルタを構成することができる。

また別の例示的な構成は、測定ギャップである。測定ギャップは、例えばユーザ機器が１つの送受信ユニットのみを有しており一度に１つの周波数のみをサポートする場合のインター周波数測定といった測定をユーザ機器が実行し得るように、アップリンク送信又はダウンリンク送信がスケジューリングされないことになる時間ピリオドを定義する。測定ギャップ構成は、全てのギャップ支援型測定について共通である。

Ｅ−ＵＴＲＡＮは、所与の周波数について単一の測定対象のみを構成するが、１つよりも多くの測定ＩＤが同じ測定対象を使用してよい。測定対象及び報告構成について使用される識別子は、全ての測定タイプをまたいで一意である。各報告構成について、報告（ＲＳＣＰ又はＲＳＲＰ）をトリガする数量を構成することが可能である。

ＬＴＥにおいて使用される測定メトリックのいくつかの例は、リファレンス信号受信電力（ＲＳＲＰ）及びリファレンス信号受信品質（ＲＳＲＱ）である。ＲＳＲＰは、信号強度のセル固有の指標であり、ハンドオーバ及びセル再選択の目的で様々なセルをランク付けするために主に使用され、セル固有リファレンス信号（ＲＳ）を搬送するリソースエレメント（ＲＥ）の電力の線形平均として計算される。一方で、ＲＳＲＱは、合計受信広帯域電力をも算入することにより、干渉をも考慮に入れる。

ユーザ機器がそのサービングｅＮＢから受信する測定構成パラメータの１つは、Ｓ指標（S-measure）である。Ｓ指標は、隣接セルの測定をいつ開始すべきかをユーザ機器へ知らせる。サービングセルの測定されたＲＳＲＰがＳ指標を下回る場合、サービングセルの信号がもはやそれほど強くないことが示唆され、ユーザ機器は隣接セルからのＲＳの信号強度の測定を開始する。Ｓ指標は、オプション的なパラメータであり、イントラ周波数、インター周波数及びインターＲＡＴ測定を開始するために異なるＳ指標の値を特定してもよい。ユーザ機器は、一度測定を有効化されると、サービングセル、列挙されたセル（即ち、測定対象の一部として示されたセル群）、及び／又は列挙された周波数上で検出されたセル（即ち、列挙されたセルではないがユーザ機器により検出されたセル群）を報告し得る。

ユーザ機器からの測定報告のトリガを特定する、複数の測定構成パラメータが存在する。ＬＴＥにおいてイントラＲＡＴ測定報告のために仕様化されているイベントトリガ型の基準の一例は、イベントＡ１である。イベントＡ１は、プライマリサービングセル（ＰＣｅｌｌ）が絶対的な閾値よりも良好になった場合にトリガを行う。他の例はイベントＡ２であり、ＰＣｅｌｌが絶対的な閾値よりも劣悪になった場合にトリガを行う。さらなる例はイベントＡ３であり、隣接セルがＰＣｅｌｌに対して相対的に、あるオフセット分を超えるほど良好になった場合にトリガを行う。さらなる例はイベントＡ４であり、隣接セルが絶対的な閾値よりも良好になった場合にトリガを行う。また別の例はイベントＡ５であり、ＰＣｅｌｌがある絶対的な閾値よりも劣悪となり且つ隣接セルが他の絶対的な閾値よりも良好となった場合にトリガを行う。他の例はイベントＡ６であり、隣接セルがセカンダリセル（ＳＣｅｌｌ）に対して相対的に、あるオフセット分を超えるほど良好になった場合にトリガを行う。

インターＲＡＴモビリティのために多様なイベントトリガ型の報告基準が仕様化されている。一例はイベントＢ１であり、隣接セルが絶対的な閾値よりも良好になった場合にトリガを行う。さらなる例はイベントＢ２であり、サービングセルがある絶対的な閾値よりも劣悪となり且つ隣接セルが他の絶対的な閾値よりも良好となった場合にトリガを行う。

ハンドオーバに関する測定報告トリガイベントの一例は、Ａ３であり、その用語が図１３に示されている。イベントＡ３についてのトリガ条件を、次のように定式化することができる：
Ｎ ＞ Ｓ＋ＨＯＭ （１）
ここで、Ｎ及びＳは、それぞれ隣接セル及びサービングセルの信号強度であり、ＨＯＭはハンドオーバマージンである。ＨＯＭは、サービングセルの無線品質とハンドオーバを試行する前に必要とされる無線品質との間の差である。無線品質は、ＲＳＲＰ又はＲＳＲＱのいずれかを用いて測定される（さらなる説明のためには、３ＧＰＰ ＴＳ３６．１３３参照）。

ユーザ機器は、ｅＮＢへイベントＡ３報告を送信することにより、イントラ周波数ハンドオーバ手続をトリガする。このイベントは、ターゲットセルがサービングセルよりマージン“ＨＯＭ”の分だけ良好であることをユーザ機器が測定した場合に生じる。ユーザ機器は、セルに入った際にＲＲＣ上で構成され、ＨＯＭは次の構成可能なパラメータから計算される：
ＨＯＭ＝Ｏｆｓ＋Ｏｃｓ＋Ｏｆｆ−Ｏｆｎ−Ｏｃｎ＋Ｈｙｓ （２）
ここで、Ｏｆｓはサービングセルの周波数固有オフセット、Ｏｃｓはサービングセルのセル固有オフセット（ＣＩＯ）、Ｏｆｆはａ３オフセット、Ｏｆｎは隣接セルの周波数固有オフセット、Ｏｃｎは隣接セルのＣＩＯ、Ｈｙｓはヒステリシスである。

（１）における条件が満たされ、トリガ時間（ＴＴＴ：Time To Trigger）として知られるある時間長にわたって有効なままである場合、ユーザ機器は、サービングｅＮＢへ測定報告を送信する（図１４では、イベントＡ３が時刻Ａにおいて満たされ、測定報告が時刻Ｂにおいて送信されている）。サービングｅＮＢは、測定報告を取得すると、ネイバへ向けたハンドオーバを開始し得る。

イベントトリガ型の報告に加えて、ユーザ機器は、周期的な測定報告を実行するように構成されてもよい。このケースでは、ユーザ機器がイベント発生後のみではなくむしろ即時に報告を開始することを除き、イベントトリガ型の報告用と同じパラメータが構成されてよい。

ハンドオーバ
ハンドオーバは、あらゆるモバイル通信システムの重要な側面の１つであり、システムは、信号強度、負荷条件、サービス要件などといったいくつもの要因に依存して、接続をあるセルから他へと移管することにより、ユーザ機器のサービスの連続性を提供する。効率的／効果的なハンドオーバ（最小回数の不必要なハンドオーバ、最小回数のハンドオーバ失敗、最小のハンドオーバ遅延など）の提供は、エンドユーザのサービス品質（ＱｏＳ）のみならず、モバイルネットワークの全体的なキャパシティ及び性能にも影響するはずである。

ＬＴＥでは、ＵＥにより支援されるネットワーク制御型のハンドオーバが利用される（３ＧＰＰ ＴＳ３６．３００）。ハンドオーバは、ユーザ機器の報告に基づいてなされ、ユーザ機器１０１は、必要とされ且つ可能である場合に、サービスの連続性及び品質を確実にすることになる最も適切なセルへと移動される。

ハンドオーバは、利用可能である都度Ｘ２接続を介して実行され、利用可能でない場合にはＳ１インタフェースを用いて実行される（即ち、コアネットワーク（ＣＮ）が関与する）。Ｘ２ハンドオーバプロセスが図１５に示されている。ハンドオーバ手続は、準備（開始）、実行及び完了という３つのステージへと副次的に分割されることができる。

準備ステージの期間中に、ソースｅＮＢがユーザ機器から取得している測定結果に基づいて、ソースｅＮＢは、接続を他のｅＮＢへとハンドオーバすべきか否かを決定する。ハンドオーバすべきという決定の場合、ソースｅＮＢは、ターゲットｅＮＢへHANDOVER REQUESTメッセージを送信する。ソースｅＮＢは、は、このメッセージ内でＨＯの原因を示さなければならない。ＨＯについての例示的な原因は、無線上の理由（radio reasons）、リソース最適化、及び／又はサービングセル内の負荷の削減であり得る。

よって、ターゲットｅＮＢは、ＨＯがリソース最適化に起因し又はサービングセル内の負荷の削減に起因することを知得する。ターゲットｅＮＢがユーザ機器を受け入れることができる場合、ハンドオーバを開始するためのメッセージがユーザ機器へ送信され、ハンドオーバ実行ステージへと入る。そして、ソースｅＮＢに到来する当該ユーザ機器宛てのＤＬデータは、新たなターゲットｅＮＢへと転送される。

ターゲットｅＮＢとユーザ機器とが同期し、ハンドオーバ確認（handover confirm）メッセージ（図１５のステップ１１）が一度ターゲットｅＮＢにより受信されると、ハンドオーバ完了ステージに入る。ターゲットｅＮＢとの接続の適切なセットアップ（サービングゲートウェイ内のＤＬパスの切り替えを含む）が実行された後、古い接続は解放され、ユーザ機器を宛て先とするソースｅＮＢ内のあらゆる残りのデータはターゲットｅＮＢへと転送される。そして、通常のパケットフローが、ターゲットｅＮＢを通じて保証され得る。

［例示的な実施形態の概略］
ＬＴＥは、現在のところ、ユーザ機器とｅＮＢとの間の１対１の接続のみをサポートしている。そのために、ハンドオーバが開始される場合、ターゲットはユーザ機器の全てのベアラを受け入れるかを問合せられる。過負荷の状況といった何らかの理由でベアラのうちのいくつかがターゲットにて受け入れ不能である場合、ソースは、ハンドオーバをキャンセルする（及び、おそらくは他のターゲット候補を試行する）か、それを受け入れてユーザ機器をターゲットへとハンドオーバさせ、受け入れられないベアラの破棄を招くか、のいずれかであり得る。これは、ユーザの全体的な体験の上で過酷な帰結を有し得る。現行の仕様は、多重的な接続性を可能とするために必要とされる、同じユーザ機器について複数のｅＮＢ内で並列的にベアラをセットアップすることを、許容していない。それは、ＱｏＳ及びＵＬ／ＤＬ要件に依存してベアラの最適な分配を可能とするはずである。

よって、ここで提示される例示的な実施形態のいくつかは、モビリティ手続の上記問題を解決し、ユーザ機器を複数のｅＮＢへ接続する可能性と共に、複数のｅＮＢをまたいだユーザ機器のベアラの分散を可能とする。例示的な実施形態のいくつかによれば、最適化されたハンドオーバのアプローチは、複数のｅＮＢへのユーザ機器の多重的な接続性の利点を活用し、ＬＴＥにおいて使用されている現行のユーザ機器レベルのアプローチよりもむしろ１つのベアラレベルで、ハンドオーバをトリガし及び／又は実行することができる。様々なハンドオーバトリガ条件が設定されてよく、それら条件と共に、負荷及びユーザ機器／ネットワークのバッファ条件といった他の要因に基づいて、ユーザ機器のベアラのサブセットのみの選択的なハンドオーバが実行される。

選択的なハンドオーバは、ユーザ機器に関連付けられるベアラのサブセットのハンドオーバであってよい。理解されるべきこととして、サブセットは空のサブセットであってもよく（例えば、ゼロ個のベアラ）、ベアラの全セットよりも少ない任意の数であってよく、又はユーザ機器に関連付けられるベアラの全セットであってもよい。ここで理解されるべきこととして、選択的なハンドオーバは、多様な異なるサブケースを含み得る。そうしたサブケースの例が以下に提供される：
１）第１のユースケースとして、アンカーは全てのベアラ、ＳＲＢ及びＤＲＢの双方を維持し得る。よって、選択的なハンドオーバは空のハンドオーバとなり得る。ターゲットは単に準備のみを行い、無線ベアラがハンドオーバされることなく、ユーザ機器はターゲットに同期する。
２）第２のユースケースは、アンカーが全てのＳＲＢといくつかのＤＲＢとを維持する一方で、ターゲットがハンドオーバ手続を介してユーザ機器に関連付けられるいくつかのＤＲＢを受け取ることであり得る。
３）第３のユースケースは、アンカーが全てのＳＲＢを維持する一方で、ターゲットへ全てのＤＲＢのハンドオーバが行われることであり得る。
４）第４のユースケースとして、アンカーノードの役割が切り替わり得る。一例として、アンカーの切り替えについての３つの方法が以下に提供される。
ａ．例示的な実施形態のいくつかによれば、ターゲットがアンカーになり（即ち、全てのＳＲＢがターゲットへとハンドオーバされ）、及び全てのＤＲＢは（新たな補助ノードである）ソース内に残され得る。これはユースケース３の逆のシナリオとして見られ得ることが理解されるべきである。
ｂ．例示的な実施形態のいくつかによれば、ターゲットがアンカーになり（即ち、ＳＲＢの全てがターゲットへとハンドオーバされ）、及び、ターゲットがいくつかのＤＲＢをも取得しながら、ＤＲＢのいくつかは依然としてソースに残され得る。これはユースケース２の逆のシナリオとして見られ得ることが理解されるべきである。
ｃ．例示的な実施形態のいくつかによれば、ターゲットがアンカーになり（即ち、ＳＲＢの全てがターゲットへとハンドオーバされ）、及び、ターゲットがＤＲＢの全てをも取得する。完全なハンドオーバとは対照的に、ここではソースとの関係は保持されることが理解されるべきである。これはユースケース１の逆のシナリオとして見られ得ることが理解されるべきである。
５）第５のユースケースとして、選択的なハンドオーバが２つの補助ノードの間で提供され得る。この例示的なユースケースにおいて、アンカーは同じのままであり、いくつかのＤＲＢが２つの間、２つの補助ノードの間で切り替えられる。
６）第６のユースケースとして、アンカー及び補助ノードにおいて制御プレーンの分離（split）が生じ得る。一例として、その分離についての３つの方法が提供される。
ａ．例示的な実施形態のいくつかによれば、ソースは、全てのＤＲＢ及びいくつかのＳＲＢを維持する。ターゲットは、いくつかのＳＲＢをハンドオーバ手続の結果として取得する。
ｂ．例示的な実施形態のいくつかによれば、ソースは、ＤＲＢのいくつか及びＳＲＢのいくつかを維持し得る一方、ターゲットは、ユーザ機器に関連付けられるＳＲＢのいくつか及びＤＲＢのいくつかを選択的なハンドオーバの結果として受け取る。
ｃ．例示的な実施形態のいくつかによれば、ソースは、ＳＲＢのいくつかを維持し得る一方、ターゲットは、無線端末に関連付けられる全てのＤＲＢ及びＳＲＢのいくつかを選択的なハンドオーバの結果として取得する。

例示的な実施形態のさらなる詳細が、対応する副次的な見出しに従って以下に説明される。理解されるべきこととして、ＬＴＥベースのシステムの使用と共に例示的な実施形態が一例として説明されているが、例示的な実施形態はいかなる通信システムにも適用されてよい。また理解されるべきこととして、無線端末及びユーザ機器との語は、互換可能に使用され得る。さらに理解されるべきこととして、補助ノード及び補助基地局との語もまた、互換可能に使用され得る。

ハンドオーバされるべきベアラの選択
例示的な実施形態のいくつかによれば、ソースｅＮＢは、ターゲットｅＮＢに向けてユーザ機器のベアラのサブセットの選択的なハンドオーバを開始することを決定し得る。選択的なハンドオーバのためにどのベアラを選択すべきかを決定するための複数の仕組みが、ソースｅＮＢにより採用可能である。

例示的な実施形態のいくつかによれば、ソースｅＮＢは、どのタイプのベアラが選択的なハンドオーバに含められるべきかを特定する静的なマッピングを有する。非ＧＢＲベアラのみ、ＧＢＲベアラのみ、あるレベルを上回り若しくは下回るＭＢＲを有するＧＢＲベアラのみ、あるレベルを上回り若しくは下回るＧＢＲを有するＧＢＲベアラのみ、又は、ＱＣＩのある（セット）に属するベアラのみ、などといった複数のマッピングルールが使用可能である。

例えば、マクロが良好なカバレッジを有し、ピコノードが高データレートブースティングのために他のキャリア周波数において配備されるという配備シナリオの場合に、静的なマッピングルールは、ピコノードへ向けた選択的なハンドオーバについて高データレートベアラのみを選択することであってよい。

例示的な実施形態のいくつかによれば、ソースｅＮＢは、複数の測定報告構成でユーザ機器を構成し、どのレポートがトリガされるかに依存して、選択的なハンドオーバに含められるべきベアラを決定する。単純な例として、ソースｅＮＢは、Ａ３イベントに基づく２つの測定構成を構成し、各々について異なる閾値を設定し得る。第１の報告がトリガされた場合、ｅＮＢは選択的なハンドオーバのためにあるベアラ（例えば、非ＧＢＲベアラ）を選択し、同様に、第２の報告がトリガされた場合、ｅＮＢは選択的なハンドオーバのために他の種類のベアラ（例えば、ＧＢＲベアラ）を選択し得る。なお、これは一例に過ぎず、他のイベントを用いて様々なベアラを選択することができる。

例示的な実施形態のいくつかによれば、ソースｅＮＢは、様々なベアラのバッファレベルに基づいて、どのベアラをハンドオーバすべきかを決定し得る。例えば、あるレベルを上回るほど又は下回ってバッファが埋まっているベアラのみが、選択的なハンドオーバのために選択される。

例示的な実施形態のいくつかによれば、選択的なハンドオーバに特に適した新たなトリガイベントが定義される。例えば、ある種類のベアラについて特定の閾値レベルよりも上までユーザ機器のバッファが上昇し、且つサービングセルに伴う無線条件が特定の閾値よりも劣悪になった場合にのみトリガされるという、Ａ７イベントが定義され得る。

例示的な実施形態のいくつかによれば、ソースｅＮＢは、ソースｅＮＢ及びターゲットｅＮＢでの負荷状況に基づいて、どのベアラがハンドオーバされるべきかを決定し得る。例えば、ターゲットｅＮＢの負荷が低い（unloaded）場合には、選択的なハンドオーバにより多くのベアラを含めることができる。ソースｅＮＢとターゲットｅＮＢとの間で負荷ステータス情報を交換するために、レガシーのX2 RESOURCE STATUS UPDATEメッセージを採用することができる。

例示的な実施形態のいくつかによれば、ソースｅＮＢは、より早期の測定をトリガするためにより低い閾値を構成してもよく、それら測定結果が受信された場合、サービングｅＮＢは、ターゲットｅＮＢへの選択的なハンドオーバを開始することを決定し得るが、但しそれには空のベアラリストが伴う（即ち、何もハンドオーバされない）。この“空のハンドオーバ”の目的は、ユーザ機器によるターゲットｅＮＢへの同期を可能とすることであり得る。こうした“空の”選択的なハンドオーバが実行され、ユーザ機器がターゲットｅＮＢセルへ同期した場合、サービングセル及びターゲットセルの双方から将来モビリティシグナリングを送信することが可能となる。実施形態のいくつかによれば、ベアラのサブセットは、無線端末又はユーザ機器に関連付けられる全てのベアラを含んでもよい。

例示的な実施形態のいくつかによれば、ソースｅＮＢは、測定構成においてより高い閾値を構成してもよく、そうした測定がトリガされた場合、サービングｅＮＢは、ターゲットｅＮＢへ向けた完全な（レガシーの）ハンドオーバを開始する。理解されるべきこととして、上述した選択の仕組みは、いかなる組合せで使用されてもよい。

ハンドオーバの開始
例示的な実施形態のいくつかによれば、ソースｅＮＢは、ターゲットｅＮＢへ向けてシグナリング無線ベアラのハンドオーバを開始することを決定し得る。ハンドオーバの後、ターゲットはアンカーノード（制御プレーンのための終端ポイント）になり、ソースは補助ノードになる。また、ソースｅＮＢは、このハンドオーバ要求内にいくつかのデータ無線ベアラを含めることを選択してもよい。即ち、ハンドオーバの後に、ソースがユーザ機器のいくつかのデータ無線ベアラを取り扱い得る一方で、ターゲットは全てのシグナリング無線ベアラ及び他のデータ無線ベアラを取り扱うことになる。

そうしたハンドオーバ手続の期間中であって、ユーザプレーン、例えばＰＤＣＰ又はＰＤＣＰ及びＲＬＣがアンカーノードで終端されるケースにおいて、上記仕組みは、全てのユーザプレーンベアラのトラフィックをコアネットワークから新たなアンカーノードへとスイッチングすることを含む。即ち、アンカーノードで終端されるユーザプレーンシナリオでは、アンカーノードの変更を意味するハンドオーバは、ユーザプレーンベアラのトラフィックの終端を古いアンカーノードから新たなアンカーノードへとスイッチングすることをも意味する。この手続において、コアネットワークへ向けたPATH SWITCH REQUESTメッセージは、新たなアンカーノードへ向けた全てのベアラのスイッチングを示すことになり、一方で（ソース及びターゲットセルが同じノード内に所在しないケースにおいて）X2:HANDOVER REQUESTメッセージは、どのベアラトラフィックが新たなアンカーノードセルにてエア上で送信されるものとされるか、及びどれが新たな補助ノードセルにて送信されるものとされるかを新たなアンカーノード（ターゲットノード）に示すであろう。

例示的な実施形態のいくつかによれば、ターゲットｅＮＢは、ソースｅＮＢと同じソフトセルには属さず、例えば、ターゲットｅＮＢは、隣接マクロｅＮＢ又はスタンドアローンセルとして動作しているピコｅＮＢといった独立したｅＮＢである。即ち、関係するユーザ機器にとって、ターゲットｅＮＢは、補助ｅＮＢの役割を演じるであろう。

レガシーのハンドオーバにおいて、ソースｅＮＢは、図１５に示したように、Ｘ２上でHANDOVER REQUESTメッセージを用いて、ターゲットｅＮＢを準備する。このメッセージの内容が表１に示されている。このＸ２ＡＰメッセージは、ソースからのＲＲＣコンテキストを含む透過的なコンテナを含む。選択的なハンドオーバのために、同じ原理が再利用されてよく、但し、ＲＲＣ制御コンテキストはソースｅＮＢ内に残りＥ−ＲＡＢのセットのみがハンドオーバされるように要求されることから、メッセージ内容を修正しなければならない。

例示的な実施形態のいくつかによれば、ハンドオーバ準備シグナリングの期間中に、例えばユーザ機器の全てのベアラをハンドオーバしなければならない完全なハンドオーバといったレガシーハンドオーバよりもむしろ、所与のハンドオーバが選択的なハンドオーバであることを、ターゲットｅＮＢは通知される。ターゲットｅＮＢが同じソースｅＮＢから同じユーザ機器に関係する複数の選択的ハンドオーバ要求を受信するケースでは、それは、エラーとして解釈されるべきではなく、むしろターゲットへ向けてユーザ機器の一層多くのベアラを選択的にハンドオーバさせるという要求として解釈されるべきである。

例示的な実施形態のいくつかによれば、ユーザ機器がアクティブな補助リンクを有している間にアンカー接続が失われた場合、補助ｅＮＢは、アンカーの役割を想定してよく、例えば制御プレーン及びＳＲＢを終端させる。新たなアンカー（古い補助ｅＮＢ）は、ハンドオーバ要求の期間中に受信されたＭＭＥ ＵＥ Ｓ１ＡＰ ＩＤを使用して、ユーザ機器のコンテキストをＭＭＥ（又は任意の他のモビリティ管理ノード）から回復してよく、よって以前のアンカーを介してサービスされていたいかなる無線ベアラをも再確立することができる。

レガシーのX2 HANDOVER REQUESTメッセージは、セットアップされるべきＥ−ＲＡＢのリストを既に含む。選択的なハンドオーバのケースについて、補助セルへハンドオーバすることをアンカーが望むデータ無線ベアラをカバーするためにこのリストを使用し得る。Ｅ−ＲＡＢの残りは、ソースｅＮＢに残ることになる。そのため、このリストはそのまま使用されてよい。しかしながら、Ｅ−ＲＡＢの部分的なリストがX2 HANDOVER REQUESTメッセージに含まれる場合、ターゲットは、X2:HANDOVER REQUESTメッセージ内で列挙されたベアラのスイッチングを示すPATH SWITCH REQUESTメッセージをＭＭＥへ送信するものと想定される。ＴＳ３６．４１３における現行の仕様は、「PATH SWITCH REQUESTメッセージ内のDownlink List IE内のスイッチングされるべきＥ−ＲＡＢがＵＥコンテキストに以前に含まれていた全てのＥ−ＲＡＢを含まない場合、ＭＭＥは、含まれていないＥ−ＲＡＢを暗黙的にｅＮＢによりリリースされたものと見なすものとする」と仕様化している。

上記は、現行の仕様によれば、PATH SWITCH REQUEST内に列挙されておらずユーザ機器に割り当てられているベアラがＭＭＥ（又は何らかの他のモビリティ管理ノード）により自動的に破棄されることになることを意味する。従って、例示的な実施形態のいくつかによれば、そうしたＥ−ＲＡＢの終了を防ぐために、２つの代替案を想起し得る。

第一に、選択的なハンドオーバが進行中であって未列挙のＥ−ＲＡＢが破棄されるべきではないことを示す新たなＩＥで、PATH SWITCH REQUESTメッセージが拡張されるものとする。第二に、ＭＭＥは、例えば、ＯＡＭシステムを介して、PATH SWITCH REQUESTメッセージ内で列挙されていないＥ−ＲＡＢについてＥ−ＥＡＢの終了を回避するように構成されるものとする。後者の決定は、無条件になされるか、又はソースノードのＩＤ（identity）に依存してなされ得る。ソースノードのＩＤは、PATH SWITCH REQUESTメッセージ内のSource MME UE S1AP ID IE及Source MME GUMMEI IEにより導出され得る。

PATH SWITCH REQUESTメッセージのＩＥがいかに拡張され得るかの一例が、表１ａに示されており、Selective Handover Indicator IEと命名される新たなＩＥが、選択的ハンドオーバをいかにＭＭＥへフラグ付けして示し得るかの一例として追加されている。

ユーザ機器のモビリティ／履歴情報
レガシーＬＴＥにおいて、ユーザ機器のモビリティの履歴情報は、ｅＮＢにて保持され、ハンドオーバが実行される際に、X2 HANDOVER REQUESTメッセージを介して、ターゲットｅＮＢへUE History Informationと呼ばれるＩＥ内で伝播される。このＩＥは、ユーザ機器が訪問した最後の１６個までのセルのリストを、セルタイプと、ユーザ機器が対応するセル内に滞在した時間と共に含む。ユーザ機器の履歴情報は、ピンポン的なハンドオーバの検出、ユーザ機器のモビリティ状態の推定といった最適化のために有益であり、ユーザ機器のモビリティ状態の推定は、ＴＴＴといったスピード依存のハンドオーバトリガパラメータをスケーリングするためにさらに使用され得る。ユーザ機器が同時に複数のセルへ接続されることを可能とする多重的な接続性が使用される場合、それに合せてユーザ機器履歴の使用が適応されなければならない。

例示的な実施形態のいくつかによれば、選択的なハンドオーバは、レガシーＬＴＥの完全なハンドオーバと同じ手法で扱われ、ユーザ機器の履歴情報はそれに合せて更新される。例えば、ユーザ機器が時刻ｔ１にてセルＡ内でＩＤＬＥからＣＯＮＮＥＣＴＥＤモードへ移り、時刻ｔ２にてセルＢへと選択的にハンドオーバされ、時刻ｔ３にてセルＢから再移動してセルＡへ戻り、例えば、Ｂへ接続されていた全てのベアラが今や再びＡに関連付けられ、時刻ｔ４にてセルＣへ完全にハンドオーバされた場合、セルＣに向けたハンドオーバ準備の期間中にセルＣをサポートするノードにより受信されるユーザ機器の履歴情報は、表２に示されるエントリーを含むであろう。

例示的な実施形態のいくつかによれば、選択的なハンドオーバはやはり同じ手法で扱われ、但し、セル内のユーザ機器の滞在時間は、完全なハンドオーバの間の、当該セルへユーザ機器がハンドオーバ（完全又は選択的のいずれか）された第１の時刻と当該セルから完全に去った（即ち、対象のセルにベアラが無くＵＥコンテキストも解放された）時刻との間の時間長として測定されるであろう。上と同じ例について、このケースでのユーザ機器の履歴情報は、表３に示されるエントリーのようになる。

例示的な実施形態のいくつかによれば、選択的なハンドオーバはユーザ機器の履歴情報に登録されない。上と同じ例について、このケースでのユーザ機器の履歴情報は、表４に示されるエントリーのようになる。

ユーザ機器の履歴情報を更新するこれら３つの手法の利点は、それらが後方互換的であることである。しかしながら、多重的な接続性に関連する情報が失われる。これを補足するためには、ユーザ機器の履歴情報のＩＥを修正しなければならない。

例示的な実施形態のいくつかにれば、ユーザ機器の履歴情報のＩＥ内にタイムスタンプフィールドが追加され、ユーザ機器がいつセルへとハンドオーバされたかを正確に知らせる。そのため、上と同じ例について、ユーザ機器の履歴情報は、表５に示されるエントリーのようになる。よって、タイムスタンプ及び時間長を見ることにより、セルＣは、ユーザ機器が期間ｔ３−ｔ２の間に双方のセルへと接続されていたことを見出すことができる。

例示的な実施形態のいくつかによれば、ユーザ機器の履歴へ、選択的なハンドオーバを示すためのハンドオーバタイプフィールドが追加される。上と同じ例について、ユーザ機器の履歴情報は、表６のように見えるであろう。

例示的な実施形態のいくつかによれば、その特定のユーザ機器についてｅＮＢにより演じられたアンカー／補助の役割を示す追加的なＩＥが、ユーザ機器の履歴情報内に含められる。この追加的な情報は、障害からの回復の期間中に有益であり得る。上と同じ例について、ユーザ機器の履歴情報は、表７のように見えるであろう。

レガシーのX2 HANDOVER REQUESTメッセージ内の他のＩＥ（即ち、Message Type、Old eNB UE X2AP ID、Cause、Target Cell ID、GUMMEI、Trace Activation、SRVCC Operation Possible及びCSG Membership Status）は、選択的なハンドオーバについてそのまま使用されてよい。

ハンドオーバ確認応答
レガシーのハンドオーバでは、ターゲットｅＮＢがHANDOVER REQUESTメッセージを受信する際に、示されるように、ターゲットｅＮＢは、流入制御（admission control）を実行し、要求内に含まれるデータ無線ベアラのうちの１つ以上を受け入れ得る場合に、図１５に示したようなHANDOVER REQUEST ACKNOWLEDGEメッセージを、Ｘ２上でソースｅＮＢへ向けて送信する。このメッセージの内容が表８に示されている。受け入れられないベアラは、E-RABs Not Admitted List IE内に含まれる。同表から理解することができるように、このメッセージ内の全てのＩＥを、選択的なハンドオーバをサポートするためにそのまま使用することができる。

例示的な実施形態のいくつかによれば、E-RABs Not Admitted List内に何らかのエントリを含むHANDOVER REQUEST ACKNOWLEDGEメッセージが受信された場合、ソースｅＮＢは、それらベアラを自身と共に維持することを決定し、E-RABs Admitted List内に列挙されたもののみをハンドオーバさせる。

例示的な実施形態のいくつかによれば、E-RABs Not Admitted List内に何らかのエントリを含むHANDOVER REQUEST ACKNOWLEDGEメッセージが受信された場合、ソースｅＮＢは、ハンドオーバをキャンセルすることを決定する。ソースは、“部分的なハンドオーバ（partial handover）”という原因の値を伴うX2 HANDOVER CANCELメッセージを用いて、これをターゲットへ通信することができる。

例示的な実施形態のいくつかによれば、E-RABs Not Admitted List内に何らかのエントリを含むHANDOVER REQUEST ACKNOWLEDGEメッセージが受信された場合、ソースｅＮＢは、それらベアラを破棄することを決定し、E-RABs Admitted List内に列挙されたもののみをハンドオーバさせる。

例示的な実施形態のいくつかによれば、ソースｅＮＢは、完全なハンドオーバ要求（レガシーＨＯ）を送出し、E-RABs Not Admitted List内に何らかのエントリが存在するHANDOVER REQUEST ACKNOWLEDGEを取得した場合に、完全なハンドオーバ要求を選択的なハンドオーバへ変更するであろう（ターゲットが選択的なハンドオーバを受け入れることを知っている場合）。これは、いくつかの手法で行われ得る。例えば、ソースｅＮＢは、ターゲットへ向けて“部分的なハンドオーバ”という原因の値を伴うX2 HANDOVER CANCELコマンドを送信することにより、ハンドオーバ要求を明示的にキャンセルし、その後、まさにキャンセルされたハンドオーバにおいてターゲットが受け入れ可能であったベアラのみを含む選択的なHANDOVER REQUESTを送信する。他の例として、ソースは、例えば新たなX2 HANDOVER REQUESTメッセージを送信することにより、完全型から選択型へのハンドオーバの変更を暗黙的に通知してもよい。さらなる例として、ソースｅＮＢは、ターゲットへ以前のハンドオーバ要求を完全型から選択型へ変更することを知らせる、例えばHANDOVER REQUEST UPDATEといった新たなＸ２メッセージを送信してもよい。ソースｅＮＢにより送信されるいかなるメッセージも、選択的ハンドオーバ用のＩＥセットを伴い、ターゲットが受け入れ可能であったベアラのリストを伴って送信され得る。

例示的な実施形態のいくつかによれば、ターゲットｅＮＢは、既にハンドオーバ要求を受信し準備した対象のユーザ機器についてX2 HANDOVER REQUESTを取得し、その新たな要求が選択的ハンドオーバの要求である場合、又はHANDOVER REQUEST UPDATEメッセージを取得した場合、ハンドオーバを選択型へと更新し（即ち、後にユーザ機器が接続した際にＳＲＢのセットアップを試行しないであろう）、X2 HANDOVER REQUEST ACKNOWLEDGEメッセージを再送する。整合性のために、送信者は、X2 HANDOVER REQUESTメッセージ及びHANDOVER REQUEST UPDATEメッセージにおいて、受け入れられることになるベアラのリストを提供してもよく、但し、ターゲットは以前の要求から既にこの情報を有しているため、これは必須とはされない。

例示的な実施形態のいくつかによれば、X2 HANDOVER REQUEST ACKNOWLEDGEメッセージが受信された場合に、ソースｅＮＢは、受け入れられるベアラのサブセットのみをハンドオーバさせることを決定し、残りを自身と共に維持する。これは、上の通りのいくつかの手法で、例えば、ハンドオーバの明示的なキャンセル及び後続する新たな要求、以前の要求を無効化することになる要求の送信、又は新たなＸ２メッセージ（例えば、HANDOVER REQUEST UPDATE）の送信により通信され得る。

例示的な実施形態のいくつかによれば、ターゲットｅＮＢは、既にハンドオーバ要求（完全な又は選択的なハンドオーバのいずれか）を受信し準備した対象のＵＥについてX2 HANDOVER REQUESTを取得し、その新たな要求が選択的ハンドオーバの要求である場合、又はHANDOVER REQUEST UPDATEメッセージを取得した場合、ハンドオーバを選択型へと更新し（以前の要求が選択型でない場合であって、そのケースでは後にユーザ機器が接続した際にＳＲＢのセットアップを試行しないであろう）、X2 HANDOVER REQUEST ACKNOWLEDGEメッセージを再送することになる。このケースでは、X2 HANDOVER REQUESTメッセージ及びHANDOVER REQUEST UPDATEメッセージは、受け入れられることになるベアラを含む（元の受け入れリスト内で列挙されたベアラとは異なるためである）。また、ターゲットは、その更新されるリスト内に含まれるベアラについて予約していたかもしれない任意のリソースを解放する。

後続する選択的なハンドオーバ
例示的な実施形態のいくつかによれば、最初の選択的なハンドオーバの実行後に、いかなる数の後続のハンドオーバが実行されてもよい。従って、例示的な実施形態のいくつかによれば、ターゲットｅＮＢは、選択的なハンドオーバを受け付けた後に、New eNB UE X2AP IDとOld eNB UE X2AP IDとのマッピングを維持する。

例示的な実施形態のいくつかによれば、ソースｅＮＢは、HANDOVER REQUEST ACKNOWLEDGEメッセージについて選択的にハンドオーバを行う場合、New eNB UE X2AP IDとOld eNB UE X2AP IDとのマッピングを維持し、それにより、後にこのマッピングに格納されたNew eNB UE X2AP IDと同じOld eNB UE X2AP IDを有するHANDOVER REQUESTがターゲットｅＮＢから受信された場合に、それが選択的なハンドオーバ後にいくらかの時間を経過してアンカーへ向けて戻ろうとしているユーザ機器であることを知得することができる。

例示的な実施形態のいくつかによれば、アンカーｅＮＢからユーザ機器のベアラのいくつかが選択的にハンドオーバされた先の補助ノードのように動作するｅＮＢは、後に、別の補助ｅＮＢへのユーザ機器の選択的なハンドオーバを実行してもよい。これは、いくつかの手法で実行され得る。一例として、古い補助ノードは、それらベアラの新たな補助ノードへの選択的なハンドオーバを推奨する標識（例えば、X2 HANDOVER REQUESTメッセージ内の新たなＩＥを介して）と共に、アンカーへとベアラをハンドオーバし返してもよい。アンカーは、当該推奨を使用してよく、新たな補助ノードへとベアラをハンドオーバさせ、又はそれを自身と共に維持し若しくは破棄する。

選択的なハンドオーバの他の例は、古い補助ノードが新たな補助ノードへ向けてX2 HANDOVER REQUESTメッセージを送信したが、（例えば、新たなＩＥを介して）そのユーザ機器について責任を有するアンカーノードについての追加的な標識が伴っていた場合であり得る。すると、新たな補助ノードは、アンカーノードへ向けてHANDOVER REQUEST ACKNOWLEDGEメッセージを送信する。アンカーは、これを受信した場合には補助ノードが変更されたものと暗黙的に想定し得る。例えば、古い補助ノードは、使用中のeNB X2 AP ID、即ちアンカーと古い補助ノードとの間のハンドオーバの期間中にNew eNB X2 AP IDにおいて示されたＩＤの代わりに、もともとはOld eNB X2 AP IDとしてアンカーから受信されたOld eNB X2 AP IDを、送信しようとしているHANDOVER REQUESTにおいて使用し得る。

上のケースと同様の他の例は、補助ノードが、新たな補助ノードへの要求の送信後に即座に、新たな補助ノードへ向けた選択的なハンドオーバを開始したことを示す新たなＸ２メッセージをアンカーへと送信することであり得る。そのようにして、補助ノードの再配置が明示的にアンカーにより知得され、アンカーは、新たな補助ノードからのHANDOVER REQUEST ACKNOWLEDGEの受信によってその成功を知得する。

例示的な実施形態のいくつかによれば、古い補助ノードは、X2 HANDOVER REQUESTメッセージを新たな補助ノードへと送信し、X2 HANDOVER REQUEST ACKNOWLEDGEメッセージの取得を待ち受け、これを新たなＸ２メッセージ（例えば、X2 ASSISTING RELOCATION）内に含められる透過的なコンテナ内でアンカーへ向けて転送する。例示的な実施形態のいくつかによれば、アンカーｅＮＢは、補助の再配置が行われたことを見出すと、新たな補助ノード内で使用中のNew eNB UEに基づいて、Old eNB UE X2 AP IDからNew eNB UE X2 AP IDへのマッピングを更新する。

例示的なノード構成
図１６は、ここで説明した例示的な実施形態のいくつかを実行し得るソース基地局又はｅＮＢ４０１Ａの例示的なノード構成を示している。図１６に示した基地局は、アンカー又は補助ｅＮＢであってよいことが理解されるべきである。基地局４０１Ａは、通信データ、命令、及び／若しくはメッセージを受信及び／又は送信するように構成され得る無線回路又は通信ポート４１０Ａを備え得る。無線回路又は通信ポート４１０Ａは任意の数の送受信、受信、及び／又は送信ユニット又は回路として具備されてよいことが理解されるべきである。無線回路又は通信４１０Ａは当該技術で知られている任意の入力又は出力通信ポートの形式であってよいことがさらに理解されるべきである。無線回路又は通信４１０Ａは、ＲＦ回路及びベースバンド処理回路（図示せず）を含み得る。

基地局４０１Ａは、選択的なハンドオーバ又はユーザ機器に関連付けられるベアラのサブセットのハンドオーバを提供するように構成され得る処理ユニット又は回路４２０Ａも備え得る。処理回路４２０Ａは、任意の好適なタイプの計算ユニット、例えば、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）若しくは特定用途向け集積回路（ＡＳＩＣ：application specific integrated circuit）、又は任意の他の形式の回路であり得る。基地局４０１Ａはさらに、任意の好適なタイプのコンピュータ読取可能なメモリであり、かつ、揮発性及び／又は不揮発性のタイプのものであり得る、メモリユニット又は回路４３０Ａを備え得る。メモリ４３０Ａは、受信され、送信され及び／若しくは測定されたデータ、デバイスパラメータ、通信優先度、並びに／又は実行可能なプログラム命令を格納するように構成され得る。

図１７は、ここで説明した例示的な実施形態のいくつかを実行し得るターゲット基地局又はｅＮＢ４０１Ｂの例示的なノード構成を示している。図１７に示した基地局は、アンカー又は補助ｅＮＢであってよいことが理解されるべきである。基地局４０１Ｂは、通信データ、命令、及び／若しくはメッセージを受信及び／又は送信するように構成され得る無線回路又は通信ポート４１０Ｂを備え得る。無線回路又は通信ポート４１０Ｂは任意の数の送受信、受信、及び／又は送信ユニット又は回路として具備されてよいことが理解されるべきである。無線回路又は通信４１０Ｂは当該技術で知られている任意の入力又は出力通信ポートの形式であってよいことがさらに理解されるべきである。無線回路又は通信４１０Ｂは、ＲＦ回路及びベースバンド処理回路（図示せず）を含み得る。

基地局４０１Ｂは、選択的なハンドオーバ又はユーザ機器に関連付けられるベアラのサブセットのハンドオーバを提供するように構成され得る処理ユニット又は回路４２０Ｂも備え得る。処理回路４２０Ｂは、任意の好適なタイプの計算ユニット、例えば、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）若しくは特定用途向け集積回路（ＡＳＩＣ）、又は任意の他の形式の回路であり得る。基地局４０１Ｂはさらに、任意の好適なタイプのコンピュータ読取可能なメモリであり、かつ、揮発性及び／又は不揮発性のタイプのものであり得る、メモリユニット又は回路４３０Ｂを備え得る。メモリ４３０Ｂは、受信され、送信され及び／若しくは測定されたデータ、デバイスパラメータ、通信優先度、並びに／又は実行可能なプログラム命令を格納するように構成され得る。

例示的なノードの動作
図１８は、ここで説明した通りの、選択的なハンドオーバ又はユーザ機器に関連付けられるベアラのサブセットのハンドオーバを提供するための、ソース基地局４０１Ａによりとられ得る例示的な動作を描いたフロー図である。図１８は実線の境界線を用いて例示されたいくつかの動作と破線の境界線を用いて例示されたいくつかの動作とを含むことが理解されるべきである。実線の境界線内に含まれる動作は、最も広い例示的な実施形態に含まれる動作である。破線の境界線内に含まれる動作は、比較的広い例示的な実施形態の動作に含まれ得るか、又は当該動作の一部分であり得るか、又は当該動作に加えて採用され得るさらなる動作である、例示的な実施形態である。これらの動作が順序通りに実行される必要のないことが理解されるべきである。

さらに、上記動作の全てが必ずしも実行されなくてもよいことが理解されるべきである。例示的な動作は、任意の順序で、任意の組み合わせで実行されてよい。上記動作はアンカー基地局により又は補助基地局により実行されてよいこともまた理解されるべきである。

図１８に提示される例示的な実施形態のいくつかにおいて理解されるべきこととして、ソース及びターゲット基地局は、補助−補助ペアリング又はアンカー−補助ペアリングを含み得る。図１８に提示される例示的な実施形態のいくつかによれば、ソース及びターゲット基地局は、異なる双方向通信モードを使用してもよい。そうした双方向通信モードの例は、ＴＤＤ又はＦＤＤである。

例示的な動作８
例示的な実施形態のいくつかによれば、ソース基地局４０１Ａは、ターゲット基地局４０１Ｂから、ハンドオーバ確認応答メッセージを受信８するように構成され得る。ハンドオーバ確認応答メッセージは、無線端末（例えば、ユーザ機器）に関連付けられる全てのベアラに関与する完全なハンドオーバ（例えば、レガシーハンドオーバ）の失敗の標識を提供し得る。ハンドオーバ確認応答メッセージは、ハンドオーバ可能なベアラの識別情報（identification）をさらに含み得る。ターゲット基地局４０１Ｂからハンドオーバ確認応答メッセージを受信するように、無線回路４１０Ａが構成され得る。

よって、完全なハンドオーバが可能ではないと学習した後に、ソース基地局４０１Ａは、例えばハンドオーバされることの可能なものとして確認応答メッセージ内で示されたベアラといった、ベアラのサブセットについての選択的なハンドオーバを開始してもよい。

例示的な動作９
例示的な実施形態のいくつかによれば、ソース基地局４０１Ａは、ターゲット基地局４０１Ｂから、ターゲット基地局負荷ステータスを受信９するように構成され得る。選択的なハンドオーバ手続についての必要性は、ターゲット基地局負荷ステータスに基づいて判定され得る。ターゲット基地局負荷ステータスをターゲット基地局４０１Ｂから受信するように、無線回路４１０が構成され得る。

動作１０
ソース基地局４０１Ａは、例えば選択的なハンドオーバの手続といったハンドオーバ手続についての必要性を判定１０するように構成される。ハンドオーバ手続についての必要性を判定するように、処理回路４２０Ａが構成される。理解されるべきこととして、例示的な動作８及び９は、上記判定がいかに行われ得るかの単なる例である。ハンドオーバ手続についての必要性の判定は、ここで説明した又は当該技術において知られているいかなる手段を介してなされてもよい。

動作１２
ソース基地局４０１Ａは、無線端末に関連付けられるベアラのサブセットを選択１２するようにさらに構成される。無線端末に関連付けられるベアラのサブセットを選択するように、処理回路４２０Ａが構成される。理解されるべきこととして、ベアラのサブセットは、無線端末に関連付けられるベアラの合計数よりも少ないか又は等しい数のベアラである。

例示的な動作１３
例示的な実施形態のいくつかによれば、選択すること１２は、例えば例示的な動作８において説明したようなハンドオーバ確認応答メッセージにおいて識別されたベアラのサブセットを選択すること１３をさらに含んでもよい。ハンドオーバ確認応答メッセージにおいて識別されたベアラのサブセットを選択するように、処理回路４２０Ａが構成され得る。

例示的な動作１４
例示的な実施形態のいくつかによれば、選択すること１２は、ベアラのサブセットを選択するための予め決定されるルールを解析すること１４と、予め決定されるルールの解析に基づいてベアラのサブセットを選択することと、を含んでもよい。ベアラのサブセットを選択するための予め決定されるルールを解析するように、処理回路４２０Ａが構成され得る。

例示的な実施形態のいくつかによれば、上記予め決定されるルールは、非保証ビットレートベアラの選択、保証ビットレートベアラの選択、閾値レベルを上回り又は下回る最大ビットレートを有する保証ビットレートベアラの選択、閾値を上回り又は下回る保証レートを有する保証ビットレートベアラの選択、及び／又は、ＱＣＩに関連するベアラの選択、を含み得る。理解されるべきこととして、これらは単なる例であり、予め決定されるルールは、ここで説明した選択のいかなる手段を含んでよい。

例示的な動作１６
例示的な実施形態のいくつかによれば、選択すること１２は、無線端末に関連付けられるベアラの異なるサブセットに関連して異なる測定報告構成で、無線端末を構成すること１６、を含み得る。無線端末に関連付けられるベアラの異なるサブセットに関連して異なる測定報告構成で無線端末を構成するように、処理回路４２０Ａが構成され得る。

例示的な動作１７
例示的な実施形態のいくつかによれば、構成すること１６は、無線端末から、少なくとも１つの測定報告構成の結果として提供される測定報告を受信すること１７、をさらに含んでよい。無線端末から少なくとも１つの測定報告構成の結果として提供される測定報告を受信するように、無線回路４１０Ａが構成される。

例示的な動作１８
例示的な実施形態のいくつかによれば、構成すること１６及び受信すること１７は、受信される測定報告の結果に基づいて、ベアラのサブセットを選択すること１８、をさらに含んでよい。受信される測定報告の結果に基づいてベアラのサブセットを選択するように、処理回路４２０Ａが構成され得る。

例示的な動作２０
例示的な実施形態のいくつかによれば、選択すること１２は、無線端末の保持されるベアラ基準のモビリティ履歴に基づいて、ベアラのサブセットを選択すること２０、をさらに含む。無線端末の保持されるベアラ基準（bearer based）のモビリティ履歴に基づいてベアラのサブセットを選択するように、処理回路４２０Ａが構成され得る。

例示的な動作２４
例示的な実施形態のいくつかによれば、選択すること１２は、閾値、トリガイベント、無線信号レベル、ベアラのバッファレベル、並びに／又はソース及び／若しくはターゲット基地局での負荷状況、のうちのいずれか１つ以上に基づいて、ベアラのサブセットを選択すること２４、をさらに含む。閾値、トリガイベント、無線信号レベル、ベアラのバッファレベル、並びに／又はソース及び／若しくはターゲット基地局での負荷状況、のうちのいずれか１つ以上に基づいて、ベアラのサブセットを選択するように、処理回路４２０Ａが構成され得る。

例示的な動作２７
例示的な実施形態のいくつかによれば、無線ネットワークは、少なくとも１つのマクロノード又はセルと、高データレートブースティングのための別キャリア若しくは同キャリア周波数における少なくとも１つのピコ若しくは他のマクロノード又はセルと、を含み得る。そうした例示的な実施形態において、選択すること１２は、少なくとも１つのピコ若しくは他のマクロノード又はセルに向けてのハンドオーバ手続のために、高データレートベアラを選択すること２７、をさらに含み得る。少なくとも１つのピコ若しくは他のマクロノード又はセルに向けてのハンドオーバ手続のために高データレートベアラを選択するように、処理回路４２０Ａが構成され得る。

動作２８
ソース基地局は、ベアラのサブセットについてのハンドオーバ要求をターゲット基地局へ送信２８するように構成される。ここで、無線端末の少なくとも１つのベアラは、ソース基地局に接続したまま残される。ベアラのサブセットについてのハンドオーバ要求をターゲット基地局へ送信するように、無線回路４１０Ａが構成される。理解されるべきこととして、上記少なくとも１つのベアラは、ＳＲＢ及び／又はＤＲＢであってよい。理解されるべきこととして、選択的なハンドオーバ、及びソース基地局へ接続したまま残される少なくとも１つのベアラは、［例示的な実施形態の概略］という見出しの下で提供された例示的なユースケースのいずれかによってさらに説明されているであろう。

例示的な動作２９
例示的な実施形態のいくつかによれば、ソース基地局４０１Ａは、ターゲット基地局４０１Ｂから、ベアラのサブセットについてのハンドオーバ手続に関連する確認応答メッセージを受信２９する、ように構成され得る。確認応答メッセージは、ベアラのサブセットのうちの各ベアラについてのハンドオーバ手続の結果を含み得る。無線回路４１０Ａが、ターゲット基地局４０１Ｂから、ベアラのサブセットについてのハンドオーバ手続に関連する確認応答メッセージを受信し得る。

例示的な動作３０
例示的な実施形態のいくつかによれば、受信すること２８は、ベアラのサブセットのうちのあるベアラとの関連付けを、当該ベアラについてハンドオーバ手続の結果が成功ではない場合に、保持（maintain）すること３０、をさらに含んでよい。ベアラのサブセットのうちのベアラとの関連付けを当該ベアラについてハンドオーバ手続の結果が成功ではない場合に保持するように、処理回路４２０Ａが構成され得る。よって、成功裏にハンドオーバされなかったベアラとの関連付けを維持することで、そのベアラの破棄が防止され得る。

例示的な動作３１
例示的な実施形態のいくつかによれば、ソース基地局４０１Ａは、ハンドオーバ手続の完了後に、アンカー基地局又は補助基地局へと移行する、ように構成され得る。ハンドオーバ手続の完了後にソース基地局４０１Ａをアンカー基地局又は補助基地局へと移行するように、処理回路４２０Ａが構成され得る。

例示的な動作３２
例示的な実施形態のいくつかによれば、移行すること３１は、無線端末から、アンカーリンク上の無線リンク障害の標識を受信すること３２、を含み得る。無線端末からアンカーリンク上の無線リンク障害の標識を受信するように、無線回路４１０Ａが構成される。

例示的な動作３３
例示的な実施形態のいくつかによれば、移行すること３１及び受信すること３２は、ソース基地局をアンカー基地局へと移行すること、をさらに含み得る。ソース基地局をアンカー基地局へと移行するように、処理回路４２０Ａが構成され得る。

図１９は、ここで説明した通りの、選択的なハンドオーバ又はユーザ機器に関連付けられるベアラのサブセットのハンドオーバを提供するための、ターゲット基地局４０１Ｂによりとられ得る例示的な動作を描いたフロー図である。図１９は実線の境界線を用いて例示されたいくつかの動作と破線の境界線を用いて例示されたいくつかの動作とを含むことが理解されるべきである。実線の境界線内に含まれる動作は、最も広い例示的な実施形態に含まれる動作である。破線の境界線内に含まれる動作は、比較的広い例示的な実施形態の動作に含まれ得るか、又は当該動作の一部分であり得るか、又は当該動作に加えて採用され得るさらなる動作である、例示的な実施形態である。これらの動作が順序通りに実行される必要のないことが理解されるべきである。

さらに、上記動作の全てが必ずしも実行されなくてもよいことが理解されるべきである。例示的な動作は、任意の順序で、任意の組み合わせで実行されてよい。上記動作はアンカー基地局により又は補助基地局により実行されてよいこともまた理解されるべきである。

図１９に提示される例示的な実施形態のいくつかにおいて理解されるべきこととして、ソース及びターゲット基地局は、補助−補助ペアリング又はアンカー−補助ペアリングを含み得る。図１９に提示される例示的な実施形態のいくつかによれば、ソース及びターゲット基地局は、異なる双方向通信モードを使用してもよい。そうした双方向通信モードの例は、ＴＤＤ又はＦＤＤである。

動作３６
ターゲット基地局４０１Ｂは、ソース基地局４０１Ａから、ベアラのサブセットについてのハンドオーバ要求を受信３６するように構成される。ここで、無線端末の少なくとも１つのベアラはソース基地局に接続したまま残される。ベアラのサブセットについてのハンドオーバ要求を受信するように、受信回路４１０Ｂが構成される。理解されるべきこととして、ベアラのサブセットは、無線端末に関連付けられるベアラの合計数よりも少ないか又は等しい数のベアラを含む。上記少なくとも１つのベアラは、ＳＲＢ及び／又はＤＲＢであってよい。理解されるべきこととして、選択的なハンドオーバ、及びソース基地局へ接続したまま残される少なくとも１つのベアラは、［例示的な実施形態の概略］という見出しの下で提供された例示的なユースケースのいずれかによってさらに説明されているであろう。

動作３８
ターゲット基地局４０１Ｂは、ハンドオーバ手続に関連してベアラのサブセットの受け入れ可能性を解析３８するようにも構成される。ハンドオーバ手続に関連してベアラのサブセットの受け入れ可能性を解析するように、処理回路４２０Ｂが構成される。

動作４０
ターゲット基地局４０１Ｂは、ソース基地局４０１Ａへ、動作３８において説明したような解析の結果を含むハンドオーバ確認応答メッセージを送信４０するようにも構成される。解析の結果を含むハンドオーバ確認応答メッセージをソース基地局４０１Ａへ送信するように、無線回路４１０Ｂが構成される、

例示的な実施形態のいくつかによれば、上記結果は、ハンドオーバ手続に関連するベアラのサブセットのうちの各ベアラについての受け入れ可能性を含み得る。上記結果は、受け入れ可能でない任意のベアラとの関連付けを維持すべきというソース基地局４０１Ａへの標識をさらに含んでもよい。

例示的な動作４２
例示的な実施形態のいくつかによれば、ベアラのサブセットは、（例えば、識別されたベアラをゼロ個含む）空のサブセットであってもよい。そうした例示的な実施形態において、ターゲット基地局４０１Ｂは、無線端末との同期手続を遂行４２するようにさらに構成され得る。無線端末との同期手続を遂行するように、処理回路４２０Ｂが構成され得る。理解されるべきこととして、例示的な実施形態のいくつかによれば、ベアラのサブセットは、無線端末又はユーザ機器に関連付けられる全てのベアラを含んでもよい。

例示的な動作４３
例示的な実施形態のいくつかによれば、ターゲット基地局４０１Ｂは、ハンドオーバ手続の後に、アンカー基地局又は補助基地局へ移行４３するように構成され得る。ハンドオーバ手続の後にアンカー基地局又は補助基地局へターゲット基地局４０１Ｂを移行するように、処理回路４２０Ｂが構成され得る。

例示的な動作４４
例示的な実施形態のいくつかによれば、移行すること４３は、無線端末から、アンカーリンク上の無線リンク障害の標識を受信すること４４をさらに含んでもよい。無線端末からアンカーリンク上の無線リンク障害の標識を受信するように、無線回路４１０Ｂが構成され得る。

例示的な動作４４
例示的な実施形態のいくつかによれば、移行すること４３及び受信すること４４は、ターゲット基地局４０１Ｂをアンカー基地局へと移行すること４５をさらに含んでもよい。ターゲット基地局４０１Ｂをアンカー基地局へと移行するように、処理回路４２０Ｂが構成され得る。

例示的な動作４６
例示的な実施形態のいくつかによれば、ハンドオーバ要求は、無線端末のベアラ基準のモビリティ履歴を含んでもよい。そうした例示的な実施形態において、ターゲット基地局４０１Ｂは、無線端末のベアラ基準のモビリティ履歴を保持４６する、ようにをさら構成され得る。無線端末のベアラ基準のモビリティ履歴を保持するように、処理回路４２０Ｂが構成され得る。

例示的な動作４８
例示的な実施形態のいくつかによれば、ターゲット基地局４０１Ｂは、モビリティ管理ノード（例えば、ＭＭＥ、ＳＧＳＮ又はＳ４−ＳＧＳＮ）へ、成功裏にハンドオーバされたベアラのサブセットのＩＤを含むパススイッチ要求を送信４８するように構成されてもよい。

［一般的記述］
例示的な実施形態を解説するために、３ＧＰＰ ＬＴＥからの専門用語がここで使用されてきたが、このことが、例示的な実施形態の範囲を上述のシステムにのみ限定するものと理解されるべきではないことが、留意されるべきである。ＨＳＰＡ、ＷＣＤＭＡ、ＷｉＭａｘ、ＵＭＢ、ＷｉＦｉ、及びＧＳＭを含む他の無線システムもまた、ここに開示された例示的な実施形態からの恩恵を享受し得る。（予め存在する、プライマリの又は補助的な）ベアラとの用語がデータ無線ベアラ（ＤＲＢ）及び／又はＥＰＳ無線ベアラを表現することも理解されるべきである。

ここに提供された例示的な実施形態の説明は、例示の目的で提示されてきた。この説明は、網羅的であること、又は、例示的な実施形態を、開示された正確な形式に限定することを意図しておらず、上記の教示に照らして修正及び変形が可能であり、又は、提供された実施形態に対する種々の代替例の実施から、修正及び変形が獲得され得る。ここで議論された例は、種々の例示的な実施形態の原理及び特質、並びに、その実践的な応用を解説して、当業者が種々の態様で、そして、企図される特定の用途に適した多様な修正と共に例示的な実施形態を利用することを可能にする目的で、選定され及び説明された。ここで説明された実施形態の特徴は、方法、装置、モジュール、システム、及びコンピュータプログラムプロダクトの全ての考え得る組み合わせで組み合わされてよい。ここに提示された例示的な実施形態が互いに任意に組み合わされて実践され得ることが理解されるべきである。

“含む／備える（comprising）”という語が、列挙された以外の他の要素又はステップの存在を必ずしも除外しないこと、及び、要素に先行する“a”又は“an”という語が、複数個のこのような要素の存在を除外しないことが留意されるべきである。どの参照符号も請求項の範囲を限定しないこと、例示的な実施形態が、少なくとも部分的に、ハードウェア及びソフトウェアの双方により実装され得ること、並びに、複数の“手段（means）”、“ユニット（units）”、又は“デバイス（devices）”が、ハードウェアの同一の品目によって表現されてもよいことが、さらに留意されるべきである。

ユーザ機器といった専門用語が、非限定的であると見なされるべきであることにも留意されたい。デバイス又はユーザ機器は、当該用語がここで使用される場合、インターネット／イントラネットへのアクセス、ウェブブラウザ、オーガナイザ、カレンダー、カメラ（例えば、ビデオ及び／若しくは静止画像カメラ）、サウンドレコーダ（例えばマイクロフォン）、並びに／又はＧＰＳ（global positioning system）システム受信機についての能力を有する無線電話と、セルラー無線電話をデータ処理に組み合わせ得るＰＣＳ（personal communications system）ユーザ機器と、無線電話又は無線通信システムを含むことの可能なＰＤＡ（personal digital assistance）と、ラップトップと、通信能力を有するカメラ（例えば、ビデオ及び／又は静止画像カメラ）と、パーソナルコンピュータ、ホームエンターテインメントシステム、テレビジョンなどといった、送受信可能な任意の他の計算又は通信デバイスと、を含むように、広義に解釈されるべきである。ユーザ機器という用語が、いかなる数の接続されたデバイス、無線端末又はＭ２Ｍ（machine-to-machine）デバイスをも含んでよいことが理解されるべきである。

ここで説明された種々の例示的な実施形態は、方法ステップ又はプロセスの一般的な文脈において説明されており、当該方法ステップ又はプロセスは、１つの側面において、ネットワーク接続された環境においてコンピュータによって実行されるプログラムコードなどのコンピュータ実行可能な命令を含むコンピュータ読取可能な媒体において具現化される、コンピュータプログラムプロダクトによって実装され得る。コンピュータ読取可能な媒体は、限定ではないものの、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、コンパクトディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）などを含む、着脱可能な又は非着脱可能なストレージデバイスを含み得る。概して、プログラムモジュールは、特定のタスクを実行するか、又は特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含み得る。コンピュータ実行可能な命令、関連付けられるデータ構造、及びプログラムモジュールは、ここに開示された方法のステップを実行するためのプログラムコードの代表例である。このような実行可能な命令の特定のシーケンス又は関連付けられるデータ構造は、このようなステップ又はプロセスにおいて説明された機能を実装するための、対応するアクションの代表例である。

図面及び明細書において、例示的な実施形態を開示してきた。しかしながら、これらの実施形態に関して多くの変形及び修正をなすことが可能である。従って、具体的な用語が用いられているものの、それらは、総称的及び説明的な意味においてのみ使用されており、限定の目的では使用されておらず、その実施形態の範囲は、以下の特許請求の範囲により定義される。

Claims (40)

1. ソース基地局（４０１Ａ）における、前記ソース基地局によりサービスされている無線端末（１０１）に関連付けられるベアラのサブセットについてのハンドオーバを提供するための方法であって、ベアラの前記サブセットは、前記無線端末に関連付けられる全てのベアラよりも少なく、前記ソース基地局は、無線通信ネットワーク内に含まれ、前記方法は、
   ハンドオーバ手続についての必要性を判定すること（１０）と、
   前記無線端末に関連付けられるベアラの前記サブセットを選択すること（１２）と、
   前記ソース基地局（４０１Ａ）により、ベアラの前記サブセットについてのハンドオーバ要求をターゲット基地局（４０１Ｂ）へ送信すること（２８）と、前記無線端末の少なくとも１つのベアラは前記ソース基地局に接続したまま残されることと、
   を含み、
   前記選択すること（１２）は、ベアラの前記サブセットを選択するための予め決定されるルールを解析すること（１４）と、前記解析（１４）に基づいてベアラの前記サブセットを選択することと、をさらに含み、前記予め決定されるルールは、
   非保証ビットレートベアラを選択すること、
   保証ビットレートベアラを選択すること、
   閾値レベルを上回り又は下回る最大ビットレートを有する保証ビットレートベアラを選択すること、
   閾値レベルを上回り又は下回るレートで保証される保証ビットレートベアラを選択すること、及び、
   サービス品質クラス識別子に関連してベアラを選択すること、
   のうちのいずれか１つ以上を含む、
   方法。
2. 前記判定すること（１０）は、前記ターゲット基地局（４０１Ｂ）から、ターゲット基地局負荷ステータスを受信すること（９）、をさらに含み、前記ハンドオーバ手続についての前記必要性は、前記ターゲット基地局負荷ステータスに基づいて判定される、請求項１の方法。
3. 前記選択すること（１２）は、
   前記無線端末に関連付けられるベアラの異なるサブセットに関連して異なる測定報告構成で、前記無線端末（１０１）を構成すること（１６）と、
   前記無線端末から、少なくとも１つの測定報告構成の結果として提供される測定報告を受信すること（１７）と、
   受信される前記測定報告の結果に基づいて、ベアラのサブセットを選択すること（１８）と、
   をさらに含む、請求項１〜２のいずれかの方法。
4. 前記選択すること（１２）は、前記無線端末（１０１）の保持されるベアラ基準のモビリティ履歴に基づいて、ベアラの前記サブセットを選択すること（２０）、をさらに含む、請求項１〜３のいずれかの方法。
5. 前記選択すること（１２）は、閾値、トリガイベント、無線信号レベル、ベアラのバッファレベル、並びにソース基地局（４０１Ａ）及び／又はターゲット基地局（４０１Ｂ）での負荷状況、のうちのいずれか１つ以上に基づいて、ベアラの前記サブセットを選択すること（２４）、をさらに含む、請求項１〜４のいずれかの方法。
6. 前記無線通信ネットワークは、少なくとも１つのマクロノード又はセルと、高データレートブースティングのための別キャリア若しくは同キャリア周波数における少なくとも１つのピコ若しくは他のマクロノード又はセルと、を含み、前記選択すること（１２）は、前記少なくとも１つのピコ若しくは前記他のマクロノード又はセルに向けてのハンドオーバ手続のために、高データレートベアラを選択すること（２７）、をさらに含む、請求項１〜５のいずれかの方法。
7. 前記ターゲット基地局（４０１Ｂ）から、ベアラの前記サブセットについての前記ハンドオーバ手続に関連する確認応答メッセージを受信すること（２９）と、前記確認応答メッセージは、ベアラの前記サブセットのうちの各ベアラについての前記ハンドオーバ手続の結果を含むことと、
   ベアラの前記サブセットのうちのあるベアラとの関連付けを、当該ベアラについて前記ハンドオーバ手続の前記結果が成功ではない場合に、保持すること（３０）と、
   をさらに含む、請求項１〜６のいずれかの方法。
8. 前記ハンドオーバ手続の完了後に、アンカー基地局又は補助基地局へと移行すること（３２）、をさらに含む、請求項１〜７のいずれかの方法。
9. 前記ソース基地局（４０１Ａ）は、補助基地局であり、前記移行すること（３２）は、
   前記無線端末（１０１）から、アンカーリンク上の無線リンク障害の標識を受信すること（３１）と、
   前記ソース基地局をアンカー基地局へと移行すること（３３）と、
   をさらに含む、請求項８の方法。
10. 前記ソース（４０１Ａ）及びターゲット（４０１Ｂ）基地局は、補助−補助ペアリング又はアンカー−補助ペアリングを含む、請求項１〜９のいずれかの方法。
11. 前記ソース（４０１Ａ）及びターゲット（４０１Ｂ）基地局は、異なる双方向通信モードを使用し、双方向通信モードは、時間分割複信（ＴＤＤ）又は周波数分割複信（ＦＤＤ）通信モードである、請求項１〜１０のいずれかの方法。
12. ソース基地局によりサービスされている無線端末（１０１）に関連付けられるベアラのサブセットについてのハンドオーバを提供するための前記ソース基地局（４０１Ａ）であって、ベアラの前記サブセットは、前記無線端末に関連付けられる全てのベアラよりも少なく、前記ソース基地局は、無線通信ネットワーク内に含まれ、前記ソース基地局は、
    ハンドオーバ手続についての必要性を判定するように構成され、前記無線端末に関連付けられるベアラの前記サブセットを選択するようにさらに構成される、処理回路（４２０Ａ）と、
    ベアラの前記サブセットについてのハンドオーバ要求をターゲット基地局（４０１Ｂ）へ送信するように構成される無線回路（４１０Ａ）と、
    を含み、
    前記無線端末の少なくとも１つのベアラは、前記ソース基地局に接続したまま残され、
    前記処理回路（４２０Ａ）は、ベアラの前記サブセットを選択するための予め決定されるルールを解析する、ようにさらに構成され、前記予め決定されるルールは、
    非保証ビットレートベアラを選択すること、
    保証ビットレートベアラを選択すること、
    閾値レベルを上回り又は下回る最大ビットレートを有する保証ビットレートベアラを選択すること、
    閾値レベルを上回り又は下回るレートで保証される保証ビットレートベアラを選択すること、及び、
    サービス品質クラス識別子に関連してベアラを選択すること、
    のうちのいずれか１つ以上を含む、
    ソース基地局（４０１Ａ）。
13. 前記無線回路（４１０Ａ）は、前記ターゲット基地局（４０１Ｂ）から、ターゲット基地局負荷ステータスを受信する、ようにさらに構成され、前記処理回路（４２０Ａ）は、前記ハンドオーバ手続についての前記必要性を、前記ターゲット基地局負荷ステータスに基づいて判定する、ように構成される、請求項１２のソース基地局（４０１Ａ）。
14. 前記処理回路（４２０Ａ）は、前記無線端末に関連付けられるベアラの異なるサブセットに関連して異なる測定報告構成で、前記無線端末（１０１）を構成する、ようにさらに構成され、前記無線回路（４１０Ａ）は、前記無線端末から、少なくとも１つの測定報告構成の結果として提供される測定報告を受信する、ように構成され、前記処理回路（４２０Ａ）は、受信される前記測定報告の構成結果に基づいて、ベアラのサブセットを選択する、ようにも構成される、請求項１２〜１３のいずれかのソース基地局（４０１Ａ）。
15. 前記処理回路（４２０Ａ）は、前記無線端末（１０１）のモビリティ履歴を保持する、ようにさらに構成され、ベアラの前記サブセットは、前記無線端末のベアラ基準の前記モビリティ履歴に基づいて選択される、請求項１２〜１４のいずれかのソース基地局（４０１Ａ）。
16. 前記処理回路（４２０Ａ）は、閾値、トリガイベント、無線信号レベル、ベアラのバッファレベル、並びにソース基地局及び／又はターゲット基地局（４０１Ｂ）での負荷状況、のうちのいずれか１つ以上に基づいて、ベアラの前記サブセットを選択する、ようにさらに構成される、請求項１２〜１５のいずれかのソース基地局（４０１Ａ）。
17. 前記無線通信ネットワークは、少なくとも１つのマクロノード又はセルと、高データレートブースティングのための別キャリア若しくは同キャリア周波数における少なくとも１つのピコ若しくは他のマクロセルと、を含み、前記処理回路（４２０Ａ）は、前記少なくとも１つのピコ若しくは前記他のマクロノード又はセルに向けてのハンドオーバ手続のために、高データレートベアラを選択する、ようにさらに構成される、請求項１２〜１６のいずれかのソース基地局（４０１Ａ）。
18. 前記無線回路（４１０Ａ）は、前記ターゲット基地局（４０１Ｂ）から、ベアラの前記サブセットについての前記ハンドオーバ手続に関連する確認応答メッセージを受信する、ようにさらに構成され、前記確認応答メッセージは、ベアラの前記サブセットのうちの各ベアラについての前記ハンドオーバ手続の結果を含み、
    前記処理回路（４２０Ａ）は、ベアラの前記サブセットのうちのあるベアラとの関連付けを、当該ベアラについて前記ハンドオーバ手続の前記結果が成功ではない場合に、保持する、ようにさらに構成される、
    請求項１２〜１７のいずれかのソース基地局（４０１Ａ）。
19. 前記処理回路（４２０Ａ）は、前記ハンドオーバ手続の完了後に、前記ソース基地局をアンカー基地局又は補助基地局へと移行する、ようにさらに構成される、請求項１２〜１８のいずれかのソース基地局（４０１Ａ）。
20. 前記ソース基地局は、補助基地局であり、前記無線回路（４１０Ａ）は、前記無線端末（１０１）から、アンカーリンク上の無線リンク障害の標識を受信する、ようにさらに構成され、前記処理回路（４２０Ａ）は、前記ソース基地局をアンカー基地局へと移行する、ように構成される、請求項１９のソース基地局（４０１Ａ）。
21. 前記ソース及びターゲット（４０１Ｂ）基地局は、補助−補助ペアリング又はアンカー−補助ペアリングを含む、請求項１２〜２０のいずれかのソース基地局（４０１Ａ）。
22. 前記ソース及びターゲット（４０１Ｂ）基地局は、異なる双方向通信モードを使用し、双方向通信モードは、時間分割複信（ＴＤＤ）又は周波数分割複信（ＦＤＤ）通信モードである、請求項１２〜２１のいずれかのソース基地局（４０１Ａ）。
23. ターゲット基地局（４０１Ｂ）における、ソース基地局（４０１Ａ）によりサービスされている無線端末（１０１）に関連付けられるベアラのサブセットについてのハンドオーバを提供するための方法であって、ベアラの前記サブセットは、前記無線端末に関連付けられる全てのベアラよりも少なく、前記ターゲット基地局は、無線通信ネットワーク内に含まれ、前記方法は、
    前記ソース基地局から、ベアラの前記サブセットについてのハンドオーバ要求を受信すること（３６）と、前記無線端末の少なくとも１つのベアラは前記ソース基地局に接続したまま残されることと、
    ハンドオーバ手続に関連してベアラの前記サブセットの受け入れ可能性を解析すること（３８）と、
    前記ソース基地局へ、前記解析（３８）の結果を含むハンドオーバ確認応答メッセージを送信すること（４０）と、
    前記ソース基地局（４０１Ａ）から、少なくとも１つの後続のハンドオーバ要求を受信すること（４９）と、
    を含み、
    各後続のハンドオーバ要求は、前記無線端末（１０１）に関連付けられるベアラのサブセットのみのハンドオーバ要求として扱われる、
    方法。
24. 前記結果は、前記ハンドオーバ手続に関連するベアラの前記サブセットのうちの各ベアラについての受け入れ可能性を含み、前記結果は、受け入れ可能でない任意のベアラとの関連付けを維持すべきという前記ソース基地局（４０１Ａ）への標識をさらに含む、請求項２３の方法。
25. ベアラの前記サブセットは、空のサブセットであり、前記方法は、前記無線端末（１０１）との同期手続を遂行すること（４２）、をさらに含む、請求項２３〜２４のいずれかの方法。
26. 前記ハンドオーバ手続の完了後に、アンカー基地局又は補助基地局へ移行すること（４４）、をさらに含む、請求項２３〜２５のいずれかの方法。
27. 前記ターゲット基地局（４０１Ｂ）は、補助基地局であり、前記移行すること（４４）は、
    前記無線端末（１０１）から、アンカーリンク上の無線リンク障害の標識を受信すること（４３）と、
    前記ターゲット基地局（４０１Ｂ）をアンカー基地局へと移行すること（４５）と、
    をさらに含む、請求項２６の方法。
28. 前記ハンドオーバ要求は、前記無線端末（１０１）のベアラ基準のモビリティ履歴を含み、前記方法は、前記無線端末の前記ベアラ基準のモビリティ履歴を保持すること（４６）、をさらに含む、請求項２３〜２７のいずれかの方法。
29. モビリティ管理ノードへ、成功裏にハンドオーバされたベアラの前記サブセットのＩＤを含むパススイッチ要求を送信すること（４８）、をさらに含む、請求項２３〜２８のいずれかの方法。
30. 前記ソース（４０１Ａ）及びターゲット（４０１Ｂ）基地局は、補助−補助ペアリング又はアンカー−補助ペアリングを含む、請求項２３〜２９のいずれかの方法。
31. 前記ソース（４０１Ａ）及びターゲット（４０１Ｂ）基地局は、異なる双方向通信モードを使用し、双方向通信モードは、時間分割複信（ＴＤＤ）又は周波数分割複信（ＦＤＤ）通信モードである、請求項２３〜３０のいずれかの方法。
32. ソース基地局（４０１Ａ）によりサービスされている無線端末（１０１）に関連付けられるベアラのサブセットについてのハンドオーバを提供するためのターゲット基地局（４０１Ｂ）であって、ベアラの前記サブセットは、前記無線端末に関連付けられる全てのベアラよりも少なく、前記ターゲット基地局は、無線通信ネットワーク内に含まれ、前記ターゲット基地局は、
    前記ソース基地局から、ベアラの前記サブセットについてのハンドオーバ要求を受信するように構成される無線回路（４１０Ｂ）と、
    ハンドオーバ手続に関連してベアラの前記サブセットの受け入れ可能性を解析するように構成される処理回路（４２０Ｂ）と、
    を含み、
    前記無線端末の少なくとも１つのベアラは、前記ソース基地局に接続したまま残され、
    前記無線回路（４１０Ｂ）は、前記ソース基地局へ、解析された前記受け入れ可能性の結果を含むハンドオーバ確認応答メッセージを送信する、ようにさらに構成され、
    前記無線回路（４１０Ｂ）は、前記ソース基地局（４０１Ａ）から、少なくとも１つの後続のハンドオーバ要求を受信する、ようにさらに構成され、前記処理回路（４２０Ｂ）は、各後続のハンドオーバ要求を、前記無線端末（１０１）に関連付けられるベアラのサブセットのみについてのハンドオーバ要求として扱う、ようにさらに構成される、
    ターゲット基地局（４０１Ｂ）。
33. 前記結果は、前記ハンドオーバ手続に関連するベアラの前記サブセットのうちの各ベアラについての受け入れ可能性を含み、前記結果は、受け入れ可能でない任意のベアラとの関連付けを維持すべきという前記ソース基地局（４０１Ａ）への標識をさらに含む、請求項３２のターゲット基地局（４０１Ｂ）。
34. ベアラの前記サブセットは、空のサブセットであり、前記処理回路（４２０Ｂ）は、前記無線端末（１０１）との同期手続を遂行する、ようにさらに構成される、請求項３２〜３３のいずれかのターゲット基地局（４０１Ｂ）。
35. 前記処理回路（４２０Ｂ）は、前記ハンドオーバ手続後に、アンカー基地局又は補助基地局へ移行する、ようにさらに構成される、請求項３２〜３４のいずれかのターゲット基地局（４０１Ｂ）。
36. 前記ターゲット基地局（４０１Ｂ）は、補助基地局であり、
    前記無線回路（４１０Ｂ）は、前記無線端末（１０１）から、アンカーリンク上の無線リンク障害の標識を受信する、ようにさらに構成され、
    前記処理回路（４２０Ｂ）は、前記ターゲット基地局をアンカー基地局へと移行する、ように構成される、
    請求項３５のターゲット基地局（４０１Ｂ）。
37. 前記ハンドオーバ要求は、前記無線端末（１０１）のベアラ基準のモビリティ履歴を含み、前記処理回路（４２０Ｂ）は、前記無線端末の前記ベアラ基準のモビリティ履歴を保持する、ようにさらに構成される、請求項３２〜３６のいずれかのターゲット基地局（４０１Ｂ）。
38. 前記無線回路（４１０Ｂ）は、モビリティ管理ノードへ、成功裏にハンドオーバされたベアラの前記サブセットのＩＤを含むパススイッチ要求を送信する、ようにさらに構成される、請求項３２〜３７のいずれかのターゲット基地局（４０１Ｂ）。
39. 前記ソース及びターゲット基地局は、補助−補助ペアリング又はアンカー−補助ペアリングを含む、請求項３２〜３８のいずれかのターゲット基地局（４０１Ｂ）。
40. 前記ソース（４０１Ａ）及びターゲット基地局は、異なる双方向通信モードを使用し、双方向通信モードは、時間分割複信（ＴＤＤ）又は周波数分割複信（ＦＤＤ）通信モードである、請求項３２〜３９のいずれかのターゲット基地局（４０１Ｂ）。
    

Images