JP2017530600A - 承認制御および負荷分散 - Google Patents

Abstract

本開示のいくつかの態様は、ワイヤレス通信のための方法および装置に関し、より詳細には、ノードが、サービスに関する負荷分散および承認制御を決定するために、アクティブなサービスおよびモバイルデバイスに関するコンテキストを認識することを可能にするための方法および装置に関する。たとえば、いくつかの態様では、コアネットアークとモバイルデバイスとの間の少なくとも1つのデータフローを管理するためのモバイルデバイスは、データフローまたはデータフローに関するサービスのうちの少なくとも1つが報告されるべきかどうかを決定し、その決定に基づいて第1のノードに報告を送ることができる。この報告は、データフローまたはサービスのうちの少なくとも1つを識別し、サービスまたはデータフローに関連付けられたパケットデータネットワーク(PDN)接続またはベアラを表示することができる。

Description

本出願は、両出願の全体が参照により本明細書に明白に組み込まれている、2014年8月19日に出願した米国仮出願第62/039,221号および2015年1月16日に出願した米国出願第14/599,144号に対する優先権を主張するものである。

本開示は、一般に、ワイヤレス通信に関し、より詳細には、異なる通信リンクを使用してモバイルデバイスとコアネットワークとの間でデータをルーティングするための方法および装置に関する。

新しいユーザ経験を提供することになる、新しいサービスおよびデバイスを可能にするためのワイヤレス通信システムが開発されている。これを達成する1つの手法は、たとえば、ワイヤレスワイドエリアネットワーク(たとえば、3GおよびLTE)および(たとえば、WiFiおよびミリメートル波(mmW)に基づく)ワイヤレスローカルエリアネットワークからの特徴の組合せを使用して、複数の既存の無線アクセス技術(RAT)を活用することである。この手法は、開発の加速を助け、異なるRATによって提供される様々な利点を利用することができる。

複数のRATを利用するシステムに関する1つの課題は、異なるRATによって提供される様々な経路を仮定して、コアネットワークとユーザとの間でどのようにデータを最適にルーティングするかである。

本開示のいくつかの態様は、コアネットワークとモバイルデバイスとの間の少なくとも1つのデータフローを管理するためのモバイルデバイスによるワイヤレス通信の方法を提供する。本方法は、一般に、データフローまたはデータフローに関するサービスのうちの少なくとも1つが報告されるべきかどうかを決定するステップと、その決定に基づいて第1のノードに報告を送るステップであって、報告が、データフローまたはサービスのうちの少なくとも1つを識別し、サービスまたはデータフローに関連付けられたパケットデータネットワーク(PDN)接続またはベアラを表示する、送るステップとを含む。

本開示のいくつかの態様は、少なくとも1つのデータフローを管理するための第2のノードによるワイヤレス通信の方法を提供する。本方法は、一般に、ベアラまたはパケットデータネットワーク(PDN)接続のためにデータフローがアクティブであると決定するステップと、データフローの1つまたは複数のサービス要件に基づいて、第2のノードにおいてデータフローにサービスするか、または第1のノードにおいてデータフローにサービスするかを判定するステップと、データフローの承認に対する要求を第1のノードに送るステップとを含む。

本開示のいくつかの態様は、少なくとも1つのデータフローに関する承認制御を実行するための第1のノードによるワイヤレス通信の方法を提供する。本方法は、一般に、複数のデータフローを含む、ベアラのための少なくとも1つのデータフローの承認に対する要求を第2のノードから受信するステップと、ベアラを用いて少なくとも1つのデータフローにサービスするための、第1のノードにおけるリソースの可用性を評価するステップと、リソースの評価された可用性に少なくとも部分的に基づいて、承認が少なくとも1つのデータフローに与えられるかどうかを第2のノードに表示するステップとを含む。

本開示のいくつかの態様は、第1のノードによるワイヤレス通信の方法を提供する。本方法は、一般に、既存のベアラまたは新しいパケットデータネットワーク(PDN)接続のために少なくとも1つのデータフローがアクティブであると決定するステップであって、データフローが、第1のノードのプロトコルスタックの関連付けられたアグリゲーションレイヤを有する、決定するステップと、データフローにサービスするための、第1のノードにおけるリソースの可用性を評価するステップであって、評価が、第1のノードのプロトコルスタックの関連付けられたアグリゲーションレイヤより下の少なくとも1つのプロトコルレイヤによって管理されたリソースに関する、評価するステップと、第2のノードに関連付けられたデータフローに関する、および第2のノードに関連付けられないデータフローに関する、第1のノードにおけるリソースの可用性を表示するメッセージを第2のノードに送信するステップとを含む。

態様はまた、上で説明した動作を実行するための様々な装置、システム、コンピュータプログラム製品、および処理システムを提供する。

本開示のいくつかの態様による、例示的なワイヤレス環境を示す図である。 本開示のいくつかの態様による、制御プレーンおよびユーザプレーンルーティングのための例示的なプロトコルレイヤを示す図である。 本開示のいくつかの態様による、制御プレーンおよびユーザプレーンルーティングのための例示的なプロトコルレイヤを示す図である。 本開示の態様による、例示的な多重接続性プロトコルスタックを示す図である。 本開示の態様による、例示的なオフロード構成を示す図である。 本開示の態様による、例示的なユーザプレーン(Uプレーン)分割構成を示す図である。 本開示の態様による、例示的な制御プレーン(Cプレーン)論理アーキテクチャオプションを示す図である。 本開示の態様による、例示的な制御プレーン(Cプレーン)非アクセス層(NAS)論理アーキテクチャオプションを示す図である。 本開示の態様による、モバイルデバイス、マスタ基地局、およびセカンダリ基地局の例示的なコールフロー図である。 本開示のいくつかの態様による、サービスのセットおよびUEコンテキストをモビリティ管理エンティティ(MME)に提供するための例示的なコールフロー図である。 本開示のいくつかの態様による、サービスのセットおよびUEコンテキストをRANに提供するための例示的なコールフロー図である。 本開示のいくつかの態様による、コアネットワークとモバイルデバイスとの間の少なくとも1つのデータフローを管理するための例示的な動作を示す図である。 本開示のいくつかの態様による、少なくとも1つのデータフローを管理するための例示的な動作を示す図である。 本開示のいくつかの態様による、少なくとも1つのデータフローに関する承認制御を実行するための例示的な動作を示す図である。 本開示のいくつかの態様による、負荷分散を実行するための例示的な動作を示す図である。 本開示の態様による、例示的なユーザ機器のブロック図である。 本開示の態様による、例示的な基地局のブロック図である。

本開示の態様は、複数の無線アクセス技術(RAT)を介して接続されたコアネットワークとユーザ機器(UE)との間でデータをルーティングするために使用され得る技法を提供する。場合によっては、(複数のRAT間でルーティングされたデータに関する)承認制御判定または負荷分散判定を行っているエンティティは、どの特定のサービスがアクティブ化されているかを考慮することができる。

本開示の態様は、多種多様な異なるRATを介して通信している多種多様な異なるタイプのモバイルデバイスに適用され得る。モバイルデバイスを指すために様々な用語が使用され得る。たとえば、場合によっては、サポートされるRATに応じて、モバイルデバイスは、ワイヤレスデバイス、ユーザ端末(UT)、アクセス端末(AT)、ユーザ機器(UE)、局、移動局、ワイヤレス局、ワイヤレスノードなどと呼ばれる場合がある。同様に、コアネットワークに対するアクセスなど、モバイルデバイスにサービスを提供する基地局を指すために様々な用語が使用され得る。たとえば、場合によっては、それによってサポートされるRATに応じて、基地局は、アクセスポイント(AP)、ノードB、拡張ノードB(eNodeB)、または単にeNBと呼ばれる場合がある。

以下のいくつかの例では、モバイルデバイスはUEと呼ばれ、基地局はeNBと呼ばれる。そのような参照は、本開示の態様を特定の1つまたは複数のRATに限定することを意図せず、理解を促すことを意味する例示的な例の説明を単に助けることを意図する。

添付の図面に関して以下に記載する詳細な説明は、様々な構成の説明として意図されており、本明細書で説明する概念が実践され得る唯一の構成を表すことは意図されていない。詳細な説明は、様々な概念の完全な理解を与えるための具体的な詳細を含む。しかしながら、これらの概念がこれらの具体的な詳細なしに実践され得ることは当業者に明らかであろう。場合によっては、そのような概念を曖昧にすることを回避するために、よく知られている構造および構成要素がブロック図の形態で示される。

次に、電気通信システムのいくつかの態様が、様々な装置および方法を参照しながら提示される。これらの装置および方法について、以下の詳細な説明において説明し、様々なブロック、モジュール、構成要素、回路、ステップ、プロセス、アルゴリズムなど(「要素」と総称される)によって添付の図面に示す。これらの要素は、ハードウェア、ソフトウェア、またはそれらの組合せを使用して実装され得る。そのような要素をハードウェアとして実装するか、またはソフトウェアとして実装するかは、特定の適用例および全体的なシステムに課された設計制約に依存する。

例として、要素、もしくは要素の任意の部分、または要素の任意の組合せは、1つまたは複数のプロセッサを含む「処理システム」を用いて実装され得る。プロセッサの例は、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ(DSP)、フィールドプログラマブルゲートアレイ(FPGA)、プログラマブル論理デバイス(PLD)、ステートマシン、ゲート論理、個別ハードウェア回路、および本開示全体にわたって説明する様々な機能を実行するように構成された他の適切なハードウェアを含む。処理システム内の1つまたは複数のプロセッサは、ソフトウェアを実行し得る。ソフトウェアは、ソフトウェア/ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、または他の名称で呼ばれるかどうかにかかわらず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ファームウェア、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、プロシージャ、関数などを意味するように広く解釈されるべきである。

したがって、1つまたは複数の例示的な実施形態では、説明する機能は、ハードウェア、ソフトウェア、またはそれらの組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、または符号化され得る。コンピュータ可読媒体はコンピュータ記憶媒体を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であってよい。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、PCM(相変化メモリ)、フラッシュメモリ、CD-ROMもしくは他の光ディスク記憶装置、磁気ディスクス記憶装置もしくは他の磁気記憶デバイス、または、命令もしくはデータ構造の形態の所望のプログラムコードを搬送もしくは記憶するために使用することができ、コンピュータによってアクセスすることができる、任意の他の媒体を含み得る。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク（登録商標）(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびBlu-ray（登録商標）ディスク(disc)を含み、ディスク(disk)は通常、データを磁気的に再生し、ディスク(disc)はレーザーを用いてデータを光学的に再生する。上記の組合せは、コンピュータ可読媒体の範囲内に同じく含まれるものとする。

例示的なワイヤレス環境
図1は、コアネットワークとUE110などのワイヤレスデバイスとの間のデータフローを管理するために本開示の態様が利用され得る例示的なワイヤレス環境100を示す。

示すように、UE110は、マスタeNodeB(MeNB)120およびセカンダリeNodeB(SeNB)130など、複数の基地局と通信することが可能であり得る。MeNB120およびSeNB130は、同じRATまたは異なるRATを介して通信することができる。たとえば、MeNB120はワイヤレスワイドエリアネットワーク(WWAN)プロトコル(たとえば、LTE)を介して通信することができるのに対して、SeNB130はワイヤレスローカルエリアネットワーク(WLAN)プロトコル(たとえば、WiFi)を介して通信することができる。

本明細書で使用される場合、MeNBという用語は、一般に、UEに関するS1-MME(モビリティ管理エンティティ)制御プレーンを終了するeNBを指すのに対して、SeNBという用語は、一般に、MeNBではない、UEにサービスするeNBを指す。S1接続は、たとえば、CNゲートウェイ(GW)140を介してコアネットワーク(CN)と通信するためにMeNBまたはSeNBによって使用され得る。たとえば、S1インターフェースは、MeNBまたはSeNBとCN GWとの間のデータプレーンにサービスするS1-Uインターフェースと、制御プレーンにサービスするS1-MMEとを含み得る。

いくつかの態様では、MeNBは、多重接続性を介してUEにサービスするために1つまたは複数のSeNBに接続され得る。MeNBおよびSeNBは、バックホール接続150(たとえば、X2接続)を介して互いと通信することができる。バックホール接続は、直接的でなくてよく、1つまたは複数の中間ノード(たとえば、MME、インターワーキングゲートウェイ機能、またはルータ)を介してルーティングされ得る。SeNBの数は、UEの機能に応じて限定され得る。MeNBは対応するオペレータネットワーク内のモビリティおよびユーザプレーン(Uプレーン)分割手順を協調させることができる。MeNBは「アクセスアグノスティック」と見なされてよく、つまり、MeNBは、UEにサービスすることと、やはり1つまたは複数のSeNBを用いたUプレーン分割のUE構成を管理することの両方のために任意のタイプのRATをサポートすることができる。たとえば、MeNBは、本明細書で説明するように、手順が複数のRATを介してUプレーン分割を管理することを可能にするために、オペレータのコアネットワーク(CN)内に固定された共通Uプレーンを利用することができる。

SeNBは、MeNBのための補助容量のソースとして利用可能であり、UEにサービスするために(MeNBのRATとは)異なるRATを使用することもできる。本開示の態様によれば、SeNBは、UEにサービスすることに限定され、ほとんどの場合、Uプレーン分割のUE構成を制御するために使用可能でない。MeNBのための補助容量としてSeNBを有することは、UEのユーザまたはネットワークオペレータによって開始され得る、機会主義的かつエネルギー効率のよい動作を提供し得る。

バックホール帯域幅能力およびレイテンシ要件に応じて、SeNBはMeNBに緩くまたは密に結合され得る。たとえば、MeNBと密に結合されると見なされるSeNBは、UEに対するSeNBの接続を実質的にMeNBによって管理させることができる。他方で、MeNBと緩く結合されると見なされるSeNBは、たとえば、MeNBからのサービス品質(QoS)などの一般要件を条件に、UEに対するSeNBの接続をSeNBの制御下に委ねることができる。たとえば、MeNBに対する大容量および低レイテンシのバックホールリンクを有するSeNBはMeNBの動作に密に結合され得る。SeNBは、補助ダウンリンク(SDL)として、またはアップリンク(UL)とDLの両方に関する追加セルとして使用され得る。場合によっては、SeNBは、たとえば、ミッションクリティカルなアプリケーションに関して、MeNBの補助的なモビリティロバストネスの達成支援に使用され得る。たとえば、SeNBは、重要な情報の配信のための冗長経路を提供することができ、MeNBが無線リンク障害(RLF)を経験する場合、(SeNBに対する)高速フェイルオーバを提供することもできる。

多重接続性(MC)は、一般に、UEが、図1に示すように、MeNBおよび少なくとも1つのSeNBに接続される(たとえば、無線リソース制御(RRC)接続される)動作モードを指す。図1は、デュアルコネクティビティ(DC)と呼ばれる場合がある、2つの異なるeNBを有するMCの特定の例を示す。MCでは、1次セル(PCell)、および、オプションで、1つまたは複数の2次セル(SCell)を含む、MeNBに関連付けられたサービングセルのグループは、マスタセルグループ(MCG)と呼ばれる場合がある。同様に、SeNBに関連付けられたサービングセルのグループは、2次セルグループ(SCG)と呼ばれる場合がある。

本開示のいくつかの態様は、現在のMeNBを維持しながら、SeNBの1つまたは複数のセルを変更(SCGに追加する、SCGから除去する、またはそれらの構成を修正する)ための手順を含むMC手順を提示する。下でより詳細に説明するように、MC手順は、たとえば、パケットレベル、ベアラレベル、またはアクセスパケットネットワーク(APN)レベルにおいて、MCを使用してデータ通信をオフロードするための様々なオプションを含み得る。

MC手順は、たとえば、UEのMC構成に関するMeNBの機能を別のeNBに転送すること、ならびに、追加のアグリゲーション手順によって、MeNBを変更するハンドオーバ手順を含んでもよい。アグリゲーション手順は、MeNBおよび/またはSeNBの1つまたは複数の2次コンポーネントキャリア(SCC)のセットを変更する(追加する、除去する、または修正する)ための手順を含み得る。場合によっては、アグリゲーションは、1次コンポーネントキャリア(PCC)が一般的なメディアアクセス制御(MAC)レイヤを用いて1つまたは複数の2次コンポーネントキャリア(SCC)を制御することを暗示し得る。

本開示は、同じノード内でのアグリゲーション(たとえば、キャリアアグリゲーション)および無線アクセスネットワーク(RAN)を介したノードにわたるUプレーン分割など、アグリゲーションおよびUプレーン分割のための様々なオプションを提供する。たとえば、多重接続性の場合、データフローは、パケット単位ベースで分割可能であるか、またはベアラ単位ベースで分割(たとえば、S1インターフェースの代わりにX2インターフェースを介して分割)可能である。

場合によっては、Uプレーンは、CNを介して、たとえば、多重接続性を使用したベアラ分割を介して、ノードにわたって分割され得る。すなわち、複数のベアラ、たとえば、図1のベアラAおよびベアラBを介してUEにデータを送るCNは、多重接続性を使用して、1つのベアラをMeNBに割り当て、第2のベアラをSeNBに割り当て、各パケットがどのベアラを横断しているかに基づいて、データパケットをMeNBおよびSeNBに送ることができる。

アグリゲーションおよびUプレーン分割のためのもう1つのオプションは、たとえば、セッション連続性が必要でない場合、(許可される場合)別のオペレータへのオフロードを含み得る非シームレスオフロードである。これは、マルチパス送信制御プロトコル(MP-TCP)が利用可能である場合、パケット単位の分割に相当すると見なすことができ、さもなければ、分割はインターネットプロトコル(IP)フローレベルで生じ得る。もう1つのオプションは、たとえば、より大きい信頼性のために各パケットがMeNBとSeNBの両方によってサービスされるマルチキャスティング(たとえば、バイキャスティング)トラフィックである。

本開示の態様は、アグリゲーション判定およびUプレーン分割判定を行うためのいくつかの考えられる考慮事項について説明する。場合によっては、ノード内のアグリゲーションは共通MACレイヤを利用することができる。アグリゲートPCCおよびSCCは、互換性のある制御チャネルおよびタイミング要件を有し得るが、SCCに関して(たとえば、肯定応答送信のための)別個のULチャネルを必要としない場合がある。

場合によっては、パケット単位のUプレーン分割性能を最適化して、異なるレイテンシおよびリンク誤り率を有するRATにわたって複数のアクセスリンクをサポートすることができる。同様に、認可帯域、共有帯域、および/または無認可帯域にわたって、かつ、同じキャリアを共有するセルに関して、および/または別個のキャリア上のセルに関して、パケット単位のUプレーン分割性能を最適化することができる。

アグリゲーションおよびユーザプレーン分割のための例示的なプロトコルスタック構成
図2Aに示したロングタームエボリューション(LTE)Cプレーンスタック200およびUプレーンスタック210など、ワイヤレス通信プロトコルスタックを参照してUプレーン分割に関する異なるオプションについて説明することができる。Cプレーンでは、非アクセス層(NAS)メッセージが無線リソース制御(RRC)レイヤによって受信され、パケットデータコンバージェンスプロトコル(PDCP:packet data covergence protocol)レイヤ、無線リンク制御(RLC)レイヤ、および無線アクセス制御(MAC)レイヤに伝えられる。Uプレーンでは、IPパケットがPDCPレイヤによって受信され、RLCレイヤおよびMACレイヤに伝えられる。

上述のように、ルーティング判定を行うとき、異なる対応する検討事項を伴う、異なるレベルのUプレーン分割が可能である。たとえば、ベアラ単位またはIPフロー単位の分割の場合、どこで各IPパケットにサービスするかの判定は、ベアラまたはIPフローに関連付けられたトラフィックフローテンプレート(TFT)に基づき得る。この場合、フローのためのすべてのIPパケットは同じサービングノードを介してルーティングされるので、サービングノード間には何の並べ替え問題も存在しないため、異なるサービングノード間に共通PDCPレイヤまたはRLCレイヤは必要とさない場合がある。すなわち、パケットはそれらのパケットがどのベアラまたはフローに属しているかに基づいてルーティングされるため、任意の所与のフローのためのパケットはすべて1つのサービングノードからUEに到着し、受信側UEは、そのノードによって供給されるインジケータからそれらのパケットの正確な順序を決定することができる。

フローのパケットが複数のサービングノードから到着するとき、それらのノードによって使用されるインジケータ(たとえば、シーケンス番号)は競合する場合があり、受信側UEはそれらのパケットの適切な順序を決定することができない。たとえば、ベアラ単位またはIPフロー単位の分割の場合、分割は(たとえば、MCに関する)S1インターフェースを介してサービングゲートウェイ(SGW)において、または(たとえば、WLANインターワーキングに関する)パケットデータネットワークゲートウェイ(PGW)もしくはホームエージェント(HA)において発生し得、結果として、ベアラまたはIPフローのためのパケットを複数のサービングノードに配信させ、それらのサービングノードは、次いで、協調なしに、その独自のインジケータをそれらのパケットに割り振ることができる。UEが正確な順序でパケットを再アセンブルするために、何らかの協調または追加の情報が提供されなければならない。一例として、分割が発生するノードは、特定のパケットを配信するサービングノードにかかわらず、ベアラのためのパケットのシーケンスを決定するパケット識別子を提供することができる。サービングノード間のインターフェース、たとえば、X2インターフェースを介したRAN専用解決策も可能であり得る。

パケット単位ベースのUプレーン分割の場合、サービングノードにわたる(MCに関する)共通PDCPレイヤを利用して、フロー内のパケットを再順序付けすることができるが、RLC再順序付けも可能であり得る。パケット単位ベースのUプレーン分割の場合、どこで各PDCPパケットにサービスするかのパケット単位の判定は、各eNBに関するスケジューリング要件(たとえば、送信時に利用可能な帯域幅)に基づき得る。本開示のいくつかの態様によれば、フロー制御は、MeNBおよびSeNBがどこで各PDCPパケットにサービスするかのパケット単位の決定を行うことを可能にするために、MeNBとSeNBの間で定義され得る。

いくつかのシステム(たとえば、現在のLTE)では、モビリティおよびアグリゲーションは、一般に、UEはCプレーン上で単一のサービングeNBによってサービスされているという原理に基づき、つまり、RRCおよびNASシグナリングは単に単一のeNBを介してUEに送られる。これらのシステムのいくつかのバージョンでは、UEはまた、Uプレーン上で最高で2つまでのサービングeNBによってサービスされることが可能であり、2つのサービングeNBにわたって複数(たとえば、LTEのリリース12では、最高で5つ)のセルによってサービスされることが可能である。

図2Bは、現在のワイヤレス通信システム(たとえば、LTE Rel-10)において、1次コンポーネントキャリア(PCC)f1と2次コンポーネントキャリア(SCC)f2〜f5とを有する、eNBに関するUプレーンプロトコルスタックのためのキャリアアグリゲーションの例示的な構成230を示す。キャリアアグリゲーション(CA)では、単一のサービングeNB内の2次セル(SCell)の再構成、追加、および除去はRRC機能によって実行され得る。同じeNBに属する1次セル(PCell)は、物理アップリンク制御チャネル(PUCCH)の送信のために使用され、NAS情報がPCellから取り出される。キャリアインジケータフィールド(CIF)を介したクロスキャリアスケジューリングは、サービングセル(たとえば、PCell)の物理ダウンリンク制御チャネル(PDCCH)が別のサービングセル上でリソースをスケジュールすることを可能にする。SCellとは異なり、PCellを除去または非アクティブ化することは可能でない場合がある。

UEにサービスしているPCellは、ハンドオーバ手順を用いて(すなわち、セキュリティキー変更およびRACH手順を用いて)変更され得る。あるLTE PCellから別のLTE PCellへのハンドオーバの場合、RRC機能は、また、SCellを追加すること、除去すること、またはターゲットPCellとともに使用するために再構成することもできる。結果として、UEは、ターゲットeNBにハンドオーバ(HO)し、UEにサービスしているSCellに対する接続を再確立せずに、CAを継続することが可能であり得る。UEによる接続の再確立は、UEにサービスしているPCellがRLFを経験するときにトリガされ、SCellがRLFを経験するとき、トリガされない。CAシステム内で動作しているUEは、CAを伴わないシステム内よりも、CAシステム内の利用可能な帯域幅が増大することにより、概して、より高速にデータを受信する。

図3は、MeNBおよびSeNBを(X2接続を介して)リンクするデュアルコネクティビティプロトコルスタックの例示的な構成300を示す。特定のベアラのためのプロトコルスタックは、概して、そのベアラがどのようにセットアップされているかに依存する。たとえば、様々な代替タイプのベアラが存在する。すなわち、MCGベアラ、スプリットベアラ、およびSCGベアラである。MCGベアラ(たとえば、図3の左のベアラ)の場合、MeNBはS1-Uインターフェースを介してS-GWに接続されたUプレーンであり、SeNBはこのベアラに関するユーザプレーンデータのトランスポートに関与しない。スプリットベアラ(たとえば、図3の中央のベアラ)の場合、MeNBはS1-Uインターフェースを介してS-GWに接続されたUプレーンであり、加えて、MeNBおよびSeNBはX2-Uインターフェースを介して相互接続され、MeNBとSeNBの両方がUプレーンデータをUEに配信することを可能にする。SCGベアラ(図3の右のベアラ)の場合、SeNBはS1-Uインターフェースを介してS-GWに直接的に接続される。

シグナリング無線ベアラ(SRB)は、概して、MCGベアラタイプのものであり、したがって、MeNBによって提供される無線リソースを使用する。SCG内の少なくとも1つのセルは、概して、構成されたUL RRC接続を有し、それらのうちの1つは、SRBの存在を必要としない制御手順(たとえば、データスケジューリング)のために使用され得るPUCCHリソースを用いて構成される。上述のように、再構成は、PCellがRLFを経験するときトリガされ得るが、SCellがRLFを経験するときトリガされ得ない。MeNBは、UEの無線リソース管理(RRM)測定構成を維持し、(たとえば、受信された測定報告、またはトラフィック条件もしくはベアラタイプに基づいて)UEに関する追加のリソース(サービングセル)を提供するようにSeNBに要求することを判定することができる。この場合、MeNBおよびSeNBは、X2メッセージ内で搬送されるRRCコンテナ(ノード間メッセージ)によってUE構成についての情報を交換することができる。DCでは、2つのセル無線ネットワーク一時識別子(C-RNTI:cell radio network temporary identifier)は、一般に、1つはMCGとの通信において使用するために、1つはSCGとの通信において使用するために、独立してUEに割り振られる。

例示的なユーザプレーンオフロードオプション
本明細書で使用される場合、オフロードという用語は、概して、経路内のより早期の時点でのデータの分解(すなわち、オフロード)を指す。たとえば、データが(たとえば、MeNBおよびSeNBを介して)ある経路から(たとえば、SeNBだけを介して)より短い経路にルーティングされる場合。たとえば、すべてのデータがMeNBを介してCN内のGWを介してルーティングされる場合、UEはフローに関して最小オフロードで動作することになると考えることができる。すべてのデータがMeNB内でLGWを介してルーティングされる場合、UEはフローに関してローカルオフロードで動作することになると考えることができるが、すべてのデータがSeNB内でLGWを介してルーティングされ、MeNBを横断しない場合、UEはフローに関して最大オフロードで動作することになると考えることができる。

本明細書で使用される場合、ユーザプレーン(Uプレーン)分割という用語は、概して、トラフィックがGWからUEにどのように配信されるかを指す。下でより詳細に説明するように、トラフィックをどこでオフロードするか、およびUプレーン分割をどのように構成するかに関する判定は、データサービス要件および他の考慮事項(たとえば、潜在的なオフロードターゲットの利用可能なリソースおよび無線周波数(RF)条件)に基づき得る。

図4は様々なUプレーンオフロードオプションを示す。第1の構成410では、オペレータサービスおよびボイスオーバーLTE(VoLTE)など、Uプレーンデータに関するGW140はコアネットワーク(CN)内にあり得る。第1の構成では、共通ゲートウェイ140はMeNBおよびSeNBのアップストリームであるため、Uプレーンデータは(コアネットワークの観点から)最小限にオフロードされると説明することができる。

第2の構成420では、GWは、RANにおける選択されたインターネットIPトラフィックオフロード(SIPTO)など、MeNBのサービスエリア内に「ローカル」セッション継続性を必要とするトラフィックのための(ローカルゲートウェイまたは論理ゲートウェイLGWとして示される)MeNBにあり得る。第2の構成では、ローカルゲートウェイ422はMeNBに位置し、つまり、そのようなトラフィックに関するデータ処理(たとえば、ルーティング)は、コアネットアーク内のノードにおいてではなく、MeNBにおいて発生し得るため、「ローカル」セッショントラフィックは、第1の構成におけるトラフィックよりも大きいオフロードである(たとえば、より多くオフロードされている)として説明することができる。

第3の構成430では、LGW432は非シームレストラフィックのためにSeNBにある(たとえば、ローカルネットワークにおけるSIPTO)。第3の構成では、ゲートウェイはSeNBに位置しており、したがって、トラフィックのいずれもMeNBまたはネットワークオペレータゲートウェイを横断しないため、非シームレストラフィックは完全に(すなわち最大限に)オフロードされると説明することができる。UEに提供されるサービスのためのモビリティはオフロードが増大すると低減するが、これは、モビリティ(たとえば、ハンドオーバ)はMeNBによって管理されるが、オフロードされたトラフィックはSeNBを横断し、SeNBによって管理すらされているためである。

データをどこで、どのようにオフロードするかに関する判定は、性能および実装の複雑性にかなりの影響を及ぼし得る。たとえば、RAN内のデータオフロードは、CNにおけるUプレーントラフィック全体を低減し、ローカルサービスに対する効率的なアクセスを可能にし得る。しかしながら、この同じオフロードは、UEがセルを変更する場合、ゲートウェイ機能を再配置または修正する必要性により、非常に移動性のUEに関するユーザ経験に影響を与える可能性があり、ローカルセッション継続性のためのセル間のデータ転送に関するバックホール接続性要件をやはり増大させる可能性がある。

図5は3つの例示的なUプレーン分割オプションを示す。Uプレーン分割構成は、概して、シームレス接続性のために、ベアラがどのように、かつどこでネットワークおよびUEによってサービスされるかを定義する。Uプレーンデータがパケット単位ベースで分割される(パケット分割)か、またはベアラ単位ベースで分割される(ベアラ分割)かに関する判定は、MeNBとSeNBとの間の結合に基づき得る。加えて、これらの判定は、UE能力およびバックホール可用性の機能である。

示すように、第1の構成510では、Uプレーンデータは、SeNB130を介してコアネットワークGW140との間でルーティングされ得る。これは、コアネットワークにおけるベアラ分割の一例である。

第2の構成520は、RANにおけるベアラ単位のUプレーン分割(または、単にベアラ分割)を示す。すなわち、構成510ではコアネットワークによって、構成520ではRANによって、各パケットがどのベアラに関するかに基づいてパケットがルーティングされる。

第3の構成530は、RANにおけるパケット単位のUプレーン分割(または、単にパケット分割)を示す。示すように、この構成では、ベアラのためのいくつかのパケットはMeNBによってサービスされるのに対して、他のパケットはSeNBによってサービスされる。

ベアラ分割の場合、MeNBにおいてSeNBによってサービスされるベアラトラフィックをルーティング、処理、およびバッファリングする必要性は存在しない場合がある。結果として、すべてのトラフィックをMeNBにルーティングする必要性は存在せず、これは、MeNBとSeNBとの間のバックホールリンクに関して厳重性がより低い要件(たとえば、より低い帯域幅要件およびより高いレイテンシトレラント)を可能にし得る。加えて、ベアラ分割は、SeNBにおけるSIPTOおよびコンテンツキャッシングのサポート、ならびに、2つのリンク間に協調フロー制御に関する要件が存在しないため、各リンク上の独立したプロトコルスタックを提供し得る。

場合によっては、パケット分割は、ベアラ分割に優る利点を有し得る。たとえば、ベアラ分割の場合、オフロードは、SGWにおいてトンネル(たとえば、IPSecトンネルまたは他のプロトコルトンネル)を構成するモビリティ管理エンティティ(MME)によって実行される必要があり得、結果として、ベアラの構成に対する動的変更が限定される可能性があり、SeNBモビリティがCNに可視化されることを必要とする場合がある。すなわち、UEがSeNBのサービスエリア(たとえば、セル)から去る場合、CNがUEのためのベアラを再構成することができるように、CNに知らせなければならない。SeNBによって処理されるベアラの場合、SeNB変更に伴って、SeNB間でデータが転送され、ハンドオーバのような割込みが生じる可能性がある。さらに、同じベアラのためのMeNBおよびSeNBにわたる無線リソースの利用は、多くの場合、可能でない場合がある。

パケット分割は、(ルーティング判定は、ベアラ単位ではなく、パケット単位で行われるため)セルにわたってCAのような利得および密粒度の負荷分散を可能にし得る。パケット分割は、セルローディングに基づくより動的なベアラ切替えをやはり可能にすることができ、SeNBモビリティがCNから部分的にまたは完全に隠される可能性があるため、CNシグナリングをやはり低減し得る。すなわち、CNはパケットをRANに転送し、RANがどのSeNB(または、MeNB)がパケットをUEに配信するかを決定するため、CNは、特定のSeNBのサービスエリアから去るUEについて知らされなくてよい。むしろ、ルーティング決定はパケット単位で行われるため、SeNBの変更時に、SeNB間に何のデータ転送も必要とされなくてよく(たとえば、SeNBを変更するとき、パケットは単に、非アクティブ化されているSeNBにルーティングされなくてよく)、したがって、SeNBモビリティに関する要件を緩和する。加えて、同じベアラのためのMeNBおよびSeNBにわたる無線リソースの利用が可能であり得る。

場合によっては、ベアラ分割は、パケット分割に優る利点を有し得る。たとえば、パケット分割は、MeNB内のすべてのトラフィックをルーティングすること、処理すること、およびバッファリングすることを必要とする場合があり、セル間で転送されるデータに関して、ベアラ分割と比べて、バックホール接続性要件をやはり増大し得、パケット分割は、SeNBにおけるSIPTOまたはコンテンツキャッシングを容易にサポートしない。加えて、パケット分割は、協調フロー制御を必要とする場合があり、異なるリンク、ならびにオーバージエア(OTA)およびバックホールレイテンシを明らかにするために(ベアラ分割と比べて)より複雑なプロトコルスタックをもたらし得る。

例示的な制御プレーンオプション
様々なRRC機能が、MCルーティングで使用されるSeNB動作に関連し得る。たとえば、SeNBの共通無線リソース構成、専用無線リソース構成、ならびにSeNBに関する測定およびモビリティ制御はMCルーティングに関連し得る。

図6は、RRCのための例示的な制御プレーン論理アーキテクチャオプションを示す。場合によっては、MeNB120のためのRRCパケットは、SeNB130を介してMeNBに送られ、バックホールを介して転送されること(構成620)、および/またはその逆(構成610)が可能である。この場合、RRCメッセージング(または、他のRAT等価シグナリング)は、パケットに関するターゲット(MeNBであるか、またはSeNBであるか)を識別するためにオーバージエア(OTA)でアドレススキームをサポートしなくてよい。

構成610によって示すように、RRC論理アーキテクチャはMeNB内に単一のRRCインスタンスを含んでよく、SeNBを介して配信される任意のRRCメッセージはMeNB RRCインスタンスを介してトンネリングされる。構成620によって示すように、RRC論理アーキテクチャは、たとえば、別個の独立したインスタンスがエアリンク構成を管理する状態で、MeNBおよびSeNB内に別個のRRC(または、等価)インスタンスを含んでもよい。この場合、UE構成に関してX2を介して協調が必要とされる場合があり、たとえば、MeNBおよびSeNBは協調して、共通のまたは相互互換性の間欠受信(DRX)パラメータをUEに割り当てることができる。

場合によっては、SeNB内で可能にされるRRC機能は、完全なRRC機能の単なるサブセットであり得る(たとえば、SeNBに対する接続およびUプレーン分割構成において、MeNBだけがUEのモビリティを管理する場合)。この場合、MeNB内のRRCインスタンスを1次RRCと見なすことができ、SeNB内のRRCインスタンスを2次RRCと見なすことができる。場合によっては、SeNBはMeNBと比べて異なるRATに関連付けられてよく、これは、MeNBがUEに対するSeNBエアリンクの構成を管理するための要件が存在しない場合があるため、別個のシステムを有することと同様であり得る。

図7は、CプレーンNAS論理アーキテクチャオプションを示す。NAS論理アーキテクチャオプションは、構成710によって示すように、単一のMeNB120を介して下位レイヤトランスポートによってサービスされるMME702内に単一のNASインスタンスを含む。MeNB内のプロトコルスタックは、UEによってMMEと交換されるNASメッセージに関するトランスポートを提供する。この論理アーキテクチャでは、NASアーキテクチャとともに使用されるRRC論理アーキテクチャに応じて、NASメッセージはSeNB130を介して送られても、送られなくてもよい。SeNBを介して送られることになるNASメッセージは、(MMEからUEへの配信のために)MeNBからSeNBに転送されるか、または(UEからMMEへの配信の場合)SeNBからMeNBに転送されてよい。

第2のCプレーンNAS論理アーキテクチャオプションは、構成720によって示すように、MME(たとえば、RRCレイヤ)内でNASインスタンスにメッセージを配信することができるプロトコルレイヤのMeNBおよびSeNBの各々の中に独立したインスタンスを含めることである。第2のNASアーキテクチャでは、MME702は、MeNB120とSeNB130の両方を介してNASメッセージを交換する。そのようなアーキテクチャでは、MMEは、SeNBおよびMeNBと別個の通信を協調させるための能力を用いて単一のNASプロトコルインスタンスを動作させることができる。MME内でNASレイヤと通信するためにSeNB内で実装されるプロトコルレイヤは、基礎をなすプロトコルのサブセットだけを含むことが可能であり、たとえば、SeNB内のRRCレイヤは、下でさらに説明するように、完全なRRCインスタンスのすべての機能をサポートしなくてよい。

CプレーンNASおよびRRC論理アーキテクチャの特定の例示的な実装形態は、MeNB内に単一のNASを有し、MeNBおよびSeNB内に別個のRRC(または、等価)インスタンスを有し得る。別個のRRCインスタンスは、UEにサービスするために、専用リソースおよび共通リソースに関してX2を介して何らかの協調を必要とし得るが、この協調はUEに不可視であり得る。上述のように、SeNB内のRRCインスタンスは完全なRRCの単なるサブセットであり得る(たとえば、MeNBのRRCは、SeNBに対するUEのモビリティおよびUプレーン分割構成を管理する1次RRCとして動作することができ、SeNBのRRCは、通常、完全に実装されるRRCプロトコルインスタンス内に存在することになるモビリティおよびリソース管理機能をサポートせずに、NASメッセージにトランスポートを提供する能力だけを有するなど、限定された機能を備えた2次RRCとして動作することができる)。MeNB内の単一のNASインスタンスからのNASメッセージは、MeNBまたはSeNBに送られてよい。たとえば、MeNB上のRLFの場合の「フェイルオーバ」機構など、特定のUEのためのMeNBとして機能するようにSeNBを再構成するために新しい手順を使用することができる。

例示的な制御プレーンモビリティ
図8は、DCデータ経路がPDCPアグリゲーションに関して破線として示される、Cプレーンモビリティ手順のための例示的なコールフロー図800を示す。示すように、Cプレーンモビリティ手順は4つの一般的な段階で発生し得る。4つの段階は、ハンドオーバおよび多重接続性の両方の間にモビリティに当てはまる。4つの段階は、UEモビリティ構成段階802と、RANモビリティ準備段階804と、モビリティ実行段階806と、モビリティ完了段階808とを含み得る。

UEモビリティ構成段階802は、たとえば、UEが、接続を確立し、MeNBから測定構成を受信することから開始し得る。UEモビリティ構成は、RANがモビリティのためにRFトリガを設定するようにUEを構成することを可能にする。これは、サービングセルおよびネイバーセル(イントラRATとインターRATの両方)に関するRF条件、ならびにサービングセルとネイバーセルとの間の相対条件を含む。UEモビリティ構成は、サービスおよびコンテキストアウェアイベントを含む。たとえば、特定のトラフィックタイプに基づいて、UEは、周波数、もしくはRATに対するモビリティイベントをトリガするための他のリソース、またはある種のタイプ(たとえば、レイテンシもしくは他のQoS態様、UEに関する低電力要件、またはコンテンツタイプ、たとえば、マルチメディアブロードキャストマルチキャストサービス(MBMS)によって定義されるタイプ)のトラフィックに固有のチャネルリソースに関する測定を実行することができる。いくつかの態様では、ネットワークは、UEがHO測定(UE中心の測定トリガ)をいつ実行するかを決定するための、コンテキストおよびサービス構成を含む構成を提供し得る。他の態様では、UEは、コンテキストおよびサービス状態をネットワークに提供し、ネットワークは、その状態に基づいて測定イベントをトリガする(ネットワーク中心の測定トリガ)。UE中心の測定トリガとネットワーク中心の測定トリガは両方とも、たとえば、異なるイベントタイプに関して、単一のシステム内で使用され得る。

RANモビリティ準備段階804の間、UEコンテキストはSeNBまたはターゲットeNBに提供される。たとえば、UEは測定報告をMeNBに送り、MeNBはその測定報告に基づいて、モビリティ判定を行う。MeNBは、次いで、たとえば、承認制御を実行するためにX2接続を介してターゲットeNB(予想されるSeNB)にモビリティ報告を送る。逆方向HOの場合、UEコンテキストは、HOまたはDCイベントの前にターゲットeNBに送られ、たとえば、モビリティ構成に応じて、UE測定報告に基づいてトリガされる。順方向HOの場合、コンテキストは、HOイベントの後に送られ、すなわち、コンテキストを送ることは、UEによるターゲットeNBにおける接続の確立およびソースeNBの識別に応じて、ターゲットeNBからプルするとトリガされる。一般に、多重接続性モビリティイベントに関して逆方向HO手法が予想されることになるが、順方向HO手法も可能である。HOイベントまたはDCイベントの後にコンテキストを送ること(順方向HOモデル)は、HOイベントの前にコンテキストを送ることと比べるとき、複数のターゲットeNBのより効率的な準備の可能性を提供し得る。さらに、HOイベントまたはDCイベントの後にコンテキストを送ることは、クラウドまたはクラスタ内のハンドオーバを区別すること、およびクラウドまたはクラスタ外のBSに対するハンドオーバを可能にし得る。たとえば、クラウド間ハンドオーバの場合、多地点協調(CoMP)概念を拡張して、接続点が変更するとき、変更しないクラウドにわたって単一の論理コンテキストを提供することができ、実際のHO(たとえば、あるeNBから別のeNBにUEに関する制御プレーン機能を転送すること)はクラウド内UEモビリティに関してのみ必要とされ得る。

モビリティ実行段階806の間、UEはSeNBまたはターゲットeNBにおいて接続を確立することができる。新しく確立された接続は、ULデータおよびDLデータがSeNBまたはターゲットeNBを介して通信されることを可能にする。たとえば、SeNBは、X2接続を介してモビリティ要求肯定応答をMeNBに送る。次いで、MeNBは、RRC接続再構成メッセージをUEに送る。UEは、次いで、新しいセルに同期し、ランダムアクセスプリアンブルをSeNBに送り、ランダムアクセス応答をSeNBから受信する。MeNBは、次いで、シーケンス番号(SN)状態転送メッセージをSeNBに送り、データ転送を開始する。この手法は、選択されたIPトラフィックオフロード(SIPTO)およびローカルIPアクセス(LIPA)を介してIP接続を維持しながら、クラスタ間HOを実行する可能性を提供し得る。加えて、この手法は、最適化された手順がHOに関して新しいIPアドレスを割り当てることを可能にし、多重接続性によるミッションクリティカルなアプリケーションのために(現在のHO技法と比べて)分解する前により多くの作成を同様に可能にし得る。必要であれば、MPTCPを使用すること(たとえば、終端間)ができるか、またはアプリケーションは、IPアドレス変更を処理するようにマルチホームもしくは設計され得る。

モビリティ完了段階808の間、ネットワークは、SeNBまたはターゲットeNBを直接指し示すように、SeNBまたはターゲットeNBおよびSGWに関連付けられた任意のトンネルを移動し、HOの場合、ソースeNB上でリソースを解放する。

例示的な承認制御および負荷分散
上述のように、RANに対するUE接続性を管理する一環として、MeNBは、アグリゲーションおよびUプレーン分割オプションに関して、UEに関する判定を行うことができる。SeNB上でサービスセットが変更するか、またはUEコンテキストが変更するとき、MeNBは、UEに関するアグリゲーションおよびUプレーン分割の現在の構成に基づいて、新しいサービスに関する負荷分散または承認制御を実行することを望む場合がある。

コンテキストは、たとえば、モビリティ(たとえば、車、電車、バイク、飛行機、歩行、または静止)、(屋外または屋内、仕事場または自宅、会合中、会議中を含めて)ロケーション、アクセス性およびUE状態(たとえば、ユーザの身体上、充電のためなど、ユーザからの分離、スクリーンオン/オフ、ホルスターポケット内、アクティブ使用)を含み得る。サービスは、たとえば、アプリケーション(たとえば、Facebook、YouTube（登録商標）)またはサービスタイプ(たとえば、音声、ストリーミング、またはダウンロード)を含み得る。

場合によっては、MeNBは、たとえば、データに関するUプレーンがMeNBを介する場合、サービスがアクティブ化されることを認識することができる。たとえば、MeNBは、以下の場合にサービスがアクティブ化されることを認識することができる。すなわち、ノード内のアグリゲーション(たとえば、キャリアアグリゲーション)、RANを介したノードにわたるUプレーン分割(たとえば、S1接続の代わりに、X2接続を介したパケット分割またはベアラ分割を使用した多重接続性)、またはマルチキャスティングトラフィック(たとえば、各パケットが、より高い信頼性のため、MeNBとSeNBの両方によってサービスされる)、である。

いくつかの事例では、MeNBはサービスを確認することができ、たとえば、UEがサービスのために新しいベアラをアクティブ化する場合、MMEは、MeNBにおけるベアラの構成の一部として、サービス要件についてMeNBに知らせることができる。MeNBは、ベアラアクティブ化を理解することができ、いくつかの事例では、SeNBに対するベアラの構成およびハンドオーバを受け持つことができる。他方で、サービスが既存のベアラまたはUプレーン内でアクティブ化されるとき、サービスがアクティブ化されることを示す何のCプレーンシグナリングも存在し得ない場合がある。トラフィックがSeNBにおいてだけ可視であるいくつかの事例では、トラフィックはMeNBを通過しないため、ディープパケット検査(DPI)などの技法は可能でない場合がある。

他の事例では、MeNBはUEサービスを認識することができない。たとえば、CNを介したノードにわたるUプレーン分割(たとえば、多重接続性、ベアラ分割)の場合または非シームレスオフロード(NSO)の場合、MeNBはUEサービスを認識することができない。NSOの事例は、たとえば、オフロードが、他のオペレータによって可能にされ、何のセッション継続性もそのサービスに関して要求されない場合、別のオペレータまたはアクセスネットワークに対するオフロードを含み得る。

本開示の態様は、アクティブなサービスに関する負荷分散および承認制御を決定するために、MeNBがこれらのサービスおよびUEに関するコンテキストを認識することを可能にするためのフレームワークを提供する。

本開示の態様は、サービス(たとえば、新しいサービス)がMeNBにおいてアクティブであると決定するための様々なオプションを提供する。これらのオプションのうちのいくつかは、MeNBが、たとえば、DPIに基づいて、ゲートウェイ(PGWまたはSGW)における検出によって新しいサービスがアクティブである(または、既存のサービスが修正される)と決定する事例に当てはまる。この場合、PGWまたはSGWは、MeNBまたはSeNBに送られた汎用パケット無線サービス(GPRS)トンネリングプロトコル(GTP)トンネル内のサービスに対応するとして直接または間接的にパケットをラベル付けすることができる。たとえば、ベアラIDは、サービス品質クラスインジケータ(QCI)に関連付けられてよく、ベアラ上に到着するパケットは新しいサービスがアクティブであることを表示し得る。

新しいサービスがベアラであり、特定のサービスに関連付けられる、いくつかの事例では、サービスがアクティブ化されるとき、ベアラが確立され得る。すなわち、この場合、MeNBは、ベアラを確立するためのS1メッセージを理解することができ、ベアラをSeNBに移動することもできる。代替として、GTPトンネルは、トンネルエンドポイントに対するサービスを表示するサービスラベル情報要素(IE)を含み得る。GTPトンネルがMeNBにおいて終了する事例では、MeNBはパケットの存在を使用して、UEに関するサービスを決定することができる。GTPトンネルがSeNBにおいて終了する事例では、SeNBは、バックホールを介して、UEに関するサービスについてMeNBに知らせることができる。

代替または追加として、PGWまたはSGWは、サービスのためのパケットが検出されたことを(たとえば、CNシグナリングを介して)MMEに知らせることができる。たとえば、PGWは、検出されたサービスに関して専用のベアラアクティブ化手順を開始することができる。この場合、MMEは、UEに関するサービスのセットに関するコンテキスト更新をMeNBに送ることによって、サービスについてMeNBに直接知らせることができる。たとえば、MMEが、たとえば、PGWシグナリングまたはSGWシグナリングによって開始されるような、UEに関する新しい専用ベアラをMeNBにおいて確立する場合、MMEは間接的にMeNBに知らせることもできる。

サービスがMeNBにおいてアクティブであると決定するための他のオプションは、サービス(または、コンテキスト変更)がUEにおいて開始される事例に当てはまる。この場合、UEは、サービスのセットについて明示的または暗示的のいずれかでMeNBまたはSeNBに知らせることができる。暗示的な場合、UEは、NASシグナリングを使用してサービスを要求することができる。たとえば、UEは、MMEが、UE加入情報および現在のネットワークローディングに基づいて許可するかまたは拒否するかを決定することになるサービスに関するPDN接続を開始することができる。明示的な場合、UEはRRCシグナリングまたはNASシグナリングを使用して、下でさらに説明するように、サービスのアクティブなセットまたはUEのコンテキストを表示することができる。

本開示の態様はまた、MeNB(および/またはSeNB)においてサービスのセットを負荷分散するための様々なオプションを提供する。たとえば、そのようなオプションは、バックホールを介して送られた負荷分散メッセージを含み得る。この場合、MeNBおよびSeNBは、UE単位で、かつサービス単位でバックホールを介して報告を交換して、SeNBおよびMeNBにおける正確な負荷分散を決定することができる。MeNBは、報告を使用して、サービスおよびUEのコンテキストに基づいて、UEにサービスするための異なるオプションから選択することができる。UEにサービスするオプションは、たとえば、ハンドオーバ、CA、MC、または非シームレスオフロードを含み得る。

MeNBは、アクティブなサービスに基づいて、エネルギー効率のよいネットワーク動作を可能にするために、これらの報告を使用することも可能である。たとえば、MeNBは、検出されているサービスとUE測定報告とに基づいて、ネットワーク内のRATをアクティブ化および非アクティブ化することができる。SeNB上の負荷がしきい値を下回り、MeNBが十分な容量を有する場合、MeNBはSeNBからすべてのMCトラフィックを除去し、SeNBを非アクティブ化することができる。同様に、MeNB上の負荷がしきい値を上回る場合、MeNBは、アクティブなサービスとUEコンテキストとに基づいて、SeNB上のトラフィックのうちのいくつかにサービスするために、いくつかのSeNBおよびHOに関していくつかのRATをアクティブ化するか、またはUプレーン分割オプションを使用することができる。

場合によっては、負荷分散および/または承認制御のために使用されるUE報告はオーバージエアで送られてよい。たとえば、UEに関する負荷またはサービス関連情報を交換するために、X2または等価のバックホールインターフェースが存在しない場合、MeNBはオーバージエアでSeNBに送られるようにUE報告を構成することができる。無線周波数(RF)関連条件に関する測定報告に加えて、UEは、SeNBにおけるサービスおよびUEに関するコンテキストに関するサービス品質(QoS)関連測定報告についてMeNBに知らせることができる。このようにして、そのような報告に基づいて、MeNBは、Uプレーン分割が調整される必要があるかどうかを決定することができる。これらの報告は、既存のベアラまたはAPN内の新しいサービス(たとえば、UEまたはSeNBが表示を送らない限り、MeNBがそれらについて認識しないことになるように、MeNBに対する何のCプレーンシグナリングも有さないことになるサービス)がアクティブ化されるときのイベント報告を含めて、サービス単位であり得る。

本開示のいくつかの態様は、UEがサービスのアクティブなセットまたはコンテキストを示すための手順を提供する。UEが、たとえば、トラッキングエリア更新(TAU)/ロケーションエリア更新(LAU)に登録して接続するための接続を確立する時点で、サービスのセットおよびUEコンテキストをネットワークに提供することができる。UEがデータサービス(サービス要求)のために接続する時点で、サービスのセットおよびUEコンテキストをネットワークに提供することができる。UEは、(たとえば、不要なピンポンを制限するために何らかのヒステリシスとの)交換の場合にサービスおよび/またはUEコンテキストを提供することもできる。

場合によっては、UEは、たとえば、サービスのセットまたはコンテキストがいつ実施されるか、またはサービスまたはコンテキストがどの程度長く続くことが予測されるかを表示することができる時間推定をサービスのセットおよびコンテキスト内に提供することができる。上述のように、サービスのセットおよびコンテキストは、MMEに対するNASシグナリングを介して、またはMeNBまたはSeNBに対するRRCシグナリングを介して提供され得る。

図9は、本開示の態様による、サービスのセットおよびUEコンテキストをMMEに提供するための例示的な手順を示す例示的なコールフロー図900を示す。

示すように、UEは、RRCメッセージ内でカプセル化された、RRC UL情報転送メッセージ(1)をサービスのセットおよびUEコンテキストを含むNASメッセージとともにMMEに送ることができる。eNBはNASメッセージ(2)をUL NASトランスポートコンテナ内でMMEに転送する。

MMEは、次いで、オプションで、サービスのセットに関して承認制御(3)を実行して、何のポリシーがMeNBまたはソースeNBに送られるべきか、または表示されたサービスのセットおよびUEコンテキストを仮定すれば、サービス要件をどのようにサポートするかを決定することができる。MMEは、次いで、コンテキストおよびサービスのセットに基づいて、UEに関するポリシーおよびサービス要件を示すためにS1-AP UEコンテキスト修正要求(4)をMeNBまたはソースeNBに送る。

オプションで、MMEは、既存のベアラを修正するか、またはPGW/SGWを用いて新しい専用ベアラを開始して、サービスおよびコンテキストをサポートすることができる。MMEは、コンテキストおよびサービスのセットをeNBに送ることもできる。代替として、MMEは、サービスおよびUEコンテキストに関するRANの挙動を加入者プロファイルID IE内に表示することができる。

加えて、eNBは、S1-AP UEコンテキスト修正要求(4)に応じて、RRCConnectionReconfigurationメッセージ(5)をUEに送って、ベアラまたはUE構成を修正することができる。UEは、次いで、RRCConnectionReconfigurationメッセージに応答して、RRCConnectionReconfigurationCompleteメッセージ(6)を送ることができる。

図10は、本開示の態様による、サービスのセットおよびUEコンテキストをRANに提供するための例示的な手順を示すコールフロー図1000を示す。

示すように、UEは、RRCメッセージ内で、サービスのセットおよびUEコンテキストを含むRRC ULInformatiionTransferメッセージ(1)をMeNBまたはソースeNBに送ることができる。オプションで、eNBは、UEコンテキストおよびサービス表示メッセージ(2)内でサービスおよびコンテキストをMMEに転送する。図10の残りの動作3〜6は、図9を参照して上で説明されたのと同じ方式で実行され得る。

図11は、本開示のいくつかの態様による、コアネットワークとモバイルデバイスとの間の少なくとも1つのデータフローを管理するための例示的な動作1100を示す。動作1100は、UEなどのモバイルデバイスによって実行されてよい。

動作1100は、データフローまたはデータフローに関するサービスのうちの少なくとも1つが報告されるべきかどうかを決定することによって、1102で開始する。1104で、モバイルデバイスは、その決定に基づいて第1のノードに報告を送り、報告は、データフローまたはサービスのうちの少なくとも1つを識別し、サービスまたはデータフローに関連付けられたパケットデータネットワーク(PDN)接続またはベアラを表示する。

場合によっては、本明細書で説明する動作は、適用可能なときだけ実行されてよい。たとえば、いくつかの態様では、決定すること、および送ることは、何らかのタイプのトリガイベントに応じて実行される。そのようなトリガイベントの例は、データフローがアクティブ化されたことを識別すること、またはデータ量がしきい値を超えることを識別することを含む。

場合によっては、モバイルデバイス(UE)はどのデータフローを報告するかを表示する構成を受信する。場合によっては、決定すること、および送ることは、この構成に応じて実行される。場合によっては、この決定は、(たとえば、データフローが第1のノードによって受信されない場合)データフローに関するアグリゲーションポイントのロケーションの関数(function of a location)である。場合によっては、この報告は、無線リソース制御(RRC)シグナリングまたは非アクセス層(NAS)シグナリングのうちの少なくとも1つを使用して送られる。場合によっては、データフローは新しいデータフローを含む。場合によっては、データフローはアプリケーションに関するデータを含む。場合によっては、データフローはサービスに関するデータを含む。

図12は、本開示の態様による、少なくとも1つのデータフローを管理するための例示的な動作1200を示す。動作1200は、たとえば、MeNBなど、MCをUEに提供することができる第2のノードによって実行され得る。

動作1200は、ベアラまたはパケットデータネットワーク(PDN)接続のためにデータフローがアクティブであると決定することによって、1202で開始する。1204で、第2のノードは、データフローの1つまたは複数のサービス要件に基づいて、第2のノードにおいてデータフローにサービスするか、または第1のノードにおいてデータフローにサービスするかを判定する。1206で、第2のノードは、データフローの承認に対する要求を第1のノードに送る。

いくつかの態様によれば、承認に対する要求は、データフローのアグリゲーションのためのプロトコルレイヤの表示を含む。場合によっては、第1のノードおよび第2のノードは、異なるRATを使用して動作する。場合によっては、データフローは新しいデータフローを含む。場合によっては、第2のノードは、どのデータフローを報告するかを表示する構成を送信する。場合によっては、データフローはアプリケーションに関するデータを含む。場合によっては、データフローはサービスに関するデータを含む。

図13は、本開示の態様による、少なくとも1つのデータフローに関する承認制御を実行するための例示的な動作1300を示す。動作1300は、たとえば、SeNBなど、(MCをUEに提供する)第1のノードによって実行され得る。

動作1300は、複数のデータフローを含む、ベアラのためのデータフローの承認に対する要求を第2のノードから受信することによって、1302で開始する。1304で、第1のノードは、ベアラを用いてデータフローにサービスするための、第1のノードにおけるリソースの可用性を評価する。1306で、第1のノードは、リソースの評価された可用性に少なくとも部分的に基づいて、承認が少なくとも1つのデータフローに与えられるかどうかを第2のノードに表示する。

いくつかの態様によれば、承認に対する要求は、データフローのアグリゲーションのためのプロトコルレイヤの表示を含む。場合によっては、評価は、第1のノードにおけるアグリゲーションのためのフロー分割またはパケット分割のプロトコルレイヤより下のプロトコルレイヤによって管理されたリソースに関する。場合によっては、第1のノードおよび第2のノードは、異なるRATを使用して動作する。場合によっては、データフローにサービスするための、第1のノードにおけるリソースの可用性を評価することは、第2のノードからデータフローを受け入れるために利用可能なリソースを決定することを含む。場合によっては、第1のノードは、新しくデータフローがアクティブであると決定し、その決定に基づいて、メッセージを第2のノードに送ることができる。場合によっては、データフローはアプリケーションに関するデータを含む。場合によっては、データフローはサービスに関するデータを含む。

図14は、本開示の態様による、負荷分散を実行するための例示的な動作1400を示す。動作1400は、たとえば、SeNBとして動作する第1のノードによって実行され得る。

動作1400は、第1のノードが既存のベアラまたは新しいパケットデータネットワーク(PDN)接続のために少なくとも1つのデータフローがアクティブであると決定することによって、1402で開始し、データフローは、第1のノードのプロトコルスタックの関連付けられたアグリゲーションレイヤを有する。1404で、第1のノードは、データフローにサービスするための、第1のノードにおけるリソースの可用性を評価し、評価は、第1のノードのプロトコルスタックの関連付けられたアグリゲーションレイヤより下の少なくとも1つのプロトコルレイヤによって管理されたリソースに関する。1406で、第1のノードは、第2のノードに関連付けられたデータフローに関する、および第2のノードに関連付けられないデータフローに関する、第1のノードにおけるリソースの可用性を表示するメッセージを第2のノードに送信する。

いくつかの態様によれば、このメッセージは、少なくとも1つのデータフローに関する第1のノード上のリソース負荷を低減する必要性を表示する。場合によっては、第1のノードは、少なくとも1つのデータフローにサービスすることを終了するための要求を受信することができる。場合によっては、第1のノードは、キャリアまたは無線アクセス技術(RAT)を非アクティブ化するための要求を受信することができ、アクティブなデータフローは、ハンドオーバ(HO)、または少なくとも1つのデータフローに関連付けられた、モバイルデバイスとの接続の非アクティブ化により解放される。場合によっては、それ以上のデータフローがキャリアまたはRAT上でサービスされない場合、第1のノードはそのキャリアまたはそのRATを非アクティブ化することができる。

場合によっては、データフローにサービスするための、第1のノードにおけるリソースの可用性を評価することは、データフローに関連付けられたリソース負荷をしきい値と比較することを含む。場合によっては、第1のノードは、データフローに関する承認に対する要求を第2のノードから前に受信しており、このメッセージは、データフローに関する、第1のノードにおけるリソースの可用性を表示する。場合によっては、データフローは新しいデータフローを含む。場合によっては、データフローはアプリケーションに関するデータを含む。場合によっては、データフローはサービスに関するデータを含む。

図15は、本明細書で提供される態様に従って動作することが可能なMC対応ワイヤレスデバイス1500において利用され得る様々な構成要素を示す。ワイヤレスデバイス1500は、たとえば、図1に示したUE110の1つの実装形態であり得る。

ワイヤレスデバイス1500は、ワイヤレスデバイス1500の動作を制御する1つまたは複数のプロセッサ1504を含み得る。プロセッサ1504は、中央処理ユニット(CPU)とも呼ばれ得る。プロセッサ1504は、図11を参照して上で説明したように、データフローを管理することを実行するか、データフローを管理するようにUEに指示することができる。読取り専用メモリ(ROM)とランダムアクセスメモリ(RAM)の両方を含むことができるメモリ1506は、命令およびデータをプロセッサ1504に提供する。メモリ1506の一部分は、不揮発性ランダムアクセスメモリ(NVRAM)を含む場合もある。プロセッサ1504は、典型的には、メモリ1506内に記憶されたプログラム命令に基づいて論理演算および算術演算を実行する。メモリ1506内の命令は、本明細書で説明する方法を実施するために実行可能であり得る。

ワイヤレスデバイス1500は、MCのための複数のRATを介して通信するための無線1510および1512を含んでもよい。各無線は、たとえば、送信機および受信機を含んでよく、ワイヤレスデバイス1500と様々なRATとの間のデータの送受信を可能にするための任意の他の「RFチェーン」構成要素を含んでもよい。単なる一例として、2つの無線が2つのRATのために示されているが、(たとえば、3つ以上のRATをサポートするために)3つ以上の無線が含まれてもよい。各無線は、単一または複数のアンテナ1516を介して通信することができる。

ワイヤレスデバイス1500は、トランシーバ1514によって受信された信号のレベルを検出し定量化するために使用することができる信号検出器1518を含むこともできる。信号検出器1518は、総エネルギー、シンボルごとのサブキャリア当りのエネルギー、電力スペクトル密度、および他の信号などの信号を検出することができる。ワイヤレスデバイス1500は、信号を処理する際に使用するためのデジタル信号プロセッサ(DSP)1520を含む場合もある。

図16は、MC対応ワイヤレスデバイスとの通信に参加することができる、基地局1600内で利用され得る様々な構成要素を示す。基地局1600は、たとえば、図1に示したMeNB120またはSeNB130の1つの実装形態であり得る。

基地局1600は、基地局1600の動作を制御する1つまたは複数のプロセッサ1604を含み得る。プロセッサ1604は、中央処理ユニット(CPU)とも呼ばれ得る。プロセッサ1604は、図12〜図14を参照して上で説明したように、データを管理すること、または承認制御もしくは負荷分散を実行することができる。読取り専用メモリ(ROM)とランダムアクセスメモリ(RAM)の両方を含むことができるメモリ1606は、命令およびデータをプロセッサ1604に提供する。メモリ1606の一部分は、不揮発性ランダムアクセスメモリ(NVRAM)を含む場合もある。プロセッサ1604は、典型的には、メモリ1606内に記憶されたプログラム命令に基づいて論理演算および算術演算を実行する。メモリ1606内の命令は、図12〜図14を参照して上で説明したように、データを管理すること、または承認制御もしくは負荷分散を実行することなど、(たとえば、DC UEにサービスするMeNBおよびSeNBに関する)本明細書で説明する方法を実装するために実行可能であり得る。

基地局1600は、たとえば、1つまたは複数のRATを介してUEと通信するために1つまたは複数の無線1610を含んでもよい。各無線は、たとえば、送信機および受信機を含んでよく、基地局1600と様々なUEとの間のデータの送受信を可能にするための任意の他の「RFチェーン」構成要素を含んでもよい。各無線は、単一または複数のアンテナ1616を介して通信することができる。基地局1600は、(たとえば、X2バックホール接続を介して)他の基地局と、または(たとえば、S1接続を介して)コアネットワークと通信するためのインターフェース1612を含んでもよい。

基地局1600は、トランシーバ1614によって受信された信号のレベルを検出し定量化するために使用することができる信号検出器1618を含むこともできる。信号検出器1618は、総エネルギー、シンボルごとのサブキャリア当りのエネルギー、電力スペクトル密度、および他の信号などの信号を検出することができる。基地局1600は、信号を処理する際に使用するためのデジタル信号プロセッサ(DSP)1620を含む場合もある。

上記で開示したプロセスにおけるステップの特定の順序または階層は、例示的な手法の例であることを理解されたい。設計上の選好に基づいて、プロセスにおけるステップの特定の順序または階層が並べ替えられてもよいことを理解されたい。さらに、いくつかのステップは、組み合わされるか、または省略される場合がある。添付の方法クレームは、様々なステップの要素を見本的な順序で提示したものであり、提示された特定の順序または階層に限定されるものではない。

さらに、「または」という用語は、排他的な「または」ではなく、むしろ包括的な「または」を意味することを意図している。すなわち、別段に規定されていない限り、または、文脈から明らかでない限り、たとえば、「XはAまたはBを採用する」という句は、自然包括的並べ替えのいずれかを意味するものとする。すなわち、たとえば、「XはAまたはBを採用する」という句は、以下の例のいずれかによって満たされる。XはAを採用する。XはBを採用する。またはXはAとBの両方を採用する。加えて、本出願および添付の特許請求の範囲で使用する冠詞「a」および「an」は、別段に規定されていない限り、または単数形を対象とすることが文脈から明白でない限り、概して「1つまたは複数の」を意味するものと解釈すべきである。項目のリスト「のうちの少なくとも1つ」を言及する句は、単一のメンバーを含むそれらの項目の任意の組合せを指す。一例として、「a、b、またはcのうちの少なくとも1つ」は、a、b、c、a-b、a-c、b-c、およびa-b-cを包含するものである。

上記の説明は、本明細書で説明する様々な態様を、いかなる当業者も実践できるようにするために提供される。これらの態様に対する様々な修正が当業者に容易に明らかになり、本明細書において規定される一般原理は他の態様に適用され得る。したがって、特許請求の範囲は、本明細書で示す態様に限定されるものではなく、文言通りの特許請求の範囲と一致するすべての範囲を与えられるべきであり、単数形の要素への言及は、そのように明記されていない限り、「唯一無二の」ではなく、「1つまたは複数の」を意味するものとする。別段に明記されていない限り、「いくつかの」という用語は1つまたは複数を指している。当業者に知られているか、または後で知られることになる、本開示全体にわたって説明する様々な態様の要素の、すべての構造的および機能的等価物は、参照により本明細書に明確に組み込まれ、特許請求の範囲によって包含されるものとする。さらに、本明細書に開示されるものは、そのような開示が特許請求の範囲において明示的に記載されているかどうかにかかわらず、公に供されることは意図されていない。「ための手段」という句を使用して要素が明確に列挙されていない限り、いかなるクレーム要素もミーンズプラスファンクションとして解釈されるべきではない。

100 ワイヤレス環境
110 UE
120 マスタeNodeB(MeNB)
130 セカンダリeNodeB(SeNB)
140 CNゲートウェイ(GW)
150 バックホール接続
200 ロングタームエボリューション(LTE)Cプレーンスタック
210 Uプレーンスタック
230 eNBに関するUプレーンプロトコルスタックのためのキャリアアグリゲーションの例示的な構成
300 デュアルコネクティビティプロトコルスタックの例示的な構成
410 第1の構成
420 第2の構成
422 ローカルゲートウェイ
430 第3の構成
432 LGW
510 第1の構成、構成
520 第2の構成、構成
530 第3の構成
610 構成
620 構成
702 MME
710 構成
720 構成
800 コールフロー図
802 UEモビリティ構成段階
804 RANモビリティ準備段階
806 モビリティ実行段階
808 モビリティ完了段階
900 コールフロー図
1000 コールフロー図
1100 動作
1200 動作
1300 動作
1400 動作
1500 MC対応ワイヤレスデバイス、ワイヤレスデバイス
1504 プロセッサ
1506 メモリ
1510 無線
1512 無線
1514 トランシーバ
1516 アンテナ
1518 信号検出器
1520 デジタル信号プロセッサ(DSP)
1600 基地局
1604 プロセッサ
1606 メモリ
1610 無線
1612 インターフェース
1614 トランシーバ
1616 アンテナ
1618 信号検出器
1620 デジタル信号プロセッサ(DSP)

Claims (73)

1. コアネットワークとモバイルデバイスとの間の少なくとも1つのデータフローを管理するための前記モバイルデバイスによるワイヤレス通信の方法であって、
   前記データフローまたは前記データフローに関するサービスのうちの少なくとも1つが報告されるべきかどうかを決定するステップと、
   前記決定に基づいて第1のノードに報告を送るステップであって、前記報告が、前記データフローまたは前記サービスのうちの少なくとも1つを識別し、前記サービスまたは前記データフローに関連付けられたパケットデータネットワーク(PDN)接続またはベアラを表示する、送るステップと
   を含む、方法。
2. 前記決定するステップおよび前記送るステップが、前記データフローがアクティブ化されていると識別することに応じて実行される、請求項1に記載の方法。
3. 前記決定するステップおよび前記送るステップが、データの量がしきい値を上回ると識別することに応じて実行される、請求項1に記載の方法。
4. どのデータフローを報告するべきかを表示する構成を受信するステップをさらに含む、請求項1に記載の方法。
5. 前記決定するステップおよび前記送るステップが、前記構成に応じて実行される、請求項4に記載の方法。
6. 前記決定するステップが、前記データフローに関するアグリゲーションポイントのロケーションの関数である、請求項1に記載の方法。
7. 前記決定するステップが、前記データフローが前記第1のノードによって受信されない場合、前記データフローに関するアグリゲーションポイントのロケーションの関数である、請求項6に記載の方法。
8. 前記報告が、無線リソース制御(RRC)シグナリングまたは非アクセス層(NAS)シグナリングのうちの少なくとも1つを使用して送られる、請求項1に記載の方法。
9. 前記データフローが新しいデータフローを含む、請求項1に記載の方法。
10. 前記データフローがアプリケーションに関するデータを含む、請求項1に記載の方法。
11. 前記データフローがサービスに関するデータを含む、請求項1に記載の方法。
12. 少なくとも1つのデータを管理するための第2のノードによるワイヤレス通信の方法であって、
    ベアラまたはパケットデータネットワーク(PDN)接続のためにデータフローがアクティブであると決定するステップと、
    前記データフローの1つまたは複数のサービス要件に基づいて、前記第2のノードにおいて前記データフローにサービスするか、または第1のノードにおいて前記データフローにサービスするかを判定するステップと、
    前記データフローの承認に対する要求を前記第1のノードに送るステップと
    を含む、方法。
13. 承認に対する前記要求が、前記データフローのアグリゲーションのためのプロトコルレイヤの表示を含む、請求項12に記載の方法。
14. 前記第1のノードおよび前記第2のノードが異なるRATを使用して動作する、請求項12に記載の方法。
15. 前記データフローが新しいデータフローを含む、請求項12に記載の方法。
16. どのデータフローを報告するべきかを表示する構成を送信するステップをさらに含む、請求項12に記載の方法。
17. 前記データフローがアプリケーションに関するデータを含む、請求項12に記載の方法。
18. 前記データフローがサービスに関するデータを含む、請求項12に記載の方法。
19. 少なくとも1つのデータフローに関する承認制御を実行するための第1のノードによるワイヤレス通信の方法であって、
    複数のデータフローを含む、ベアラのための前記少なくとも1つのデータフローの承認に対する要求を第2のノードから受信するステップと、
    前記ベアラを用いて前記少なくとも1つのデータフローにサービスするための、前記第1のノードにおけるリソースの可用性を評価するステップと、
    リソースの前記評価された可用性に少なくとも部分的に基づいて、承認が前記少なくとも1つのデータフローに与えられるかどうかを前記第2のノードに表示するステップと
    を含む、方法。
20. 承認に対する前記要求が、前記少なくとも1つのデータフローのアグリゲーションのためのプロトコルレイヤの表示を含む、請求項19に記載の方法。
21. 前記評価が、前記第1のノードにおけるアグリゲーションのためのフロー分割またはパケット分割のプロトコルレイヤより下のプロトコルレイヤによって管理されたリソースに関する、請求項19に記載の方法。
22. 前記第1のノードおよび前記第2のノードが異なるRATを使用して動作する、請求項19に記載の方法。
23. 前記少なくとも1つのデータフローにサービスするための、前記第1のノードにおけるリソースの可用性を前記評価するステップが、前記第2のノードからデータフローを受け入れるために利用可能なリソースを決定するステップを含む、請求項19に記載の方法。
24. 新しいデータフローがアクティブであると決定するステップと、
    前記決定に基づいてメッセージを前記第2のノードに送るステップと
    をさらに含む、請求項19に記載の方法。
25. 前記少なくとも1つのデータフローがアプリケーションに関するデータを含む、請求項19に記載の方法。
26. 前記少なくとも1つのデータフローがサービスに関するデータを含む、請求項19に記載の方法。
27. 第1のノードによるワイヤレス通信の方法であって、
    既存のベアラまたは新しいパケットデータネットワーク(PDN)接続のために少なくとも1つのデータフローがアクティブであると決定するステップであって、前記データフローが、前記第1のノードのプロトコルスタックの関連付けられたアグリゲーションレイヤを有する、決定するステップと、
    前記データフローにサービスするための、前記第1のノードにおけるリソースの可用性を評価するステップであって、前記評価が、前記第1のノードの前記プロトコルスタックの前記関連付けられたアグリゲーションレイヤより下の少なくとも1つのプロトコルレイヤによって管理されたリソースに関する、評価するステップと、
    第2のノードに関連付けられたデータフローに関する、および前記第2のノードに関連付けられないデータフローに関する、前記第1のノードにおけるリソースの前記可用性を表示するメッセージを前記第2のノードに送信するステップと
    を含む、方法。
28. 前記メッセージが、前記少なくとも1つのデータフローに関する前記第1のノード上のリソース負荷を低減する必要性を表示する、請求項27に記載の方法。
29. 前記少なくとも1つのデータフローにサービスすることを終了するための要求を受信するステップをさらに含む、請求項27に記載の方法。
30. キャリアまたは無線アクセス技術(RAT)を非アクティブ化するための要求を受信するステップであって、アクティブなデータフローが、ハンドオーバ(HO)、または前記少なくとも1つのデータフローに関連付けられた、モバイルデバイスとの前記接続の非アクティブ化により解放される、受信するステップをさらに含む、請求項27に記載の方法。
31. それ以上のデータフローがキャリアまたはRAT上でサービスされない場合、前記キャリアまたは前記RATを非アクティブ化するステップをさらに含む、請求項27に記載の方法。
32. 前記データフローにサービスするための、前記第1のノードにおけるリソースの前記可用性を前記評価するステップが、前記データフローに関連付けられたリソース負荷をしきい値と比較するステップを含む、請求項27に記載の方法。
33. 前記第1のノードが、前記データフローに関する承認に対する要求を前記第2のノードから前に受信しており、
    前記メッセージが、前記データフローに関する、前記第1のノードにおけるリソースの前記可用性を表示する
    請求項27に記載の方法。
34. 前記データフローが新しいデータフローを含む、請求項27に記載の方法。
35. 前記データフローがアプリケーションに関するデータを含む、請求項27に記載の方法。
36. 前記データフローがサービスに関するデータを含む、請求項27に記載の方法。
37. コアネットワークとモバイルデバイスとの間の少なくとも1つのデータフローを管理するためのモバイルデバイスであって、
    前記データフローまたは前記データフローに関するサービスのうちの少なくとも1つが報告されるべきかどうかを決定するための手段と、
    前記決定に基づいて第1のノードに報告を送るための手段であって、前記報告が、前記データフローまたは前記サービスのうちの少なくとも1つを識別し、前記サービスまたは前記データフローに関連付けられたパケットデータネットワーク(PDN)接続またはベアラを表示する、送るための手段と
    を含む、モバイルデバイス。
38. 前記決定するための手段および前記送るための手段が、前記データフローがアクティブ化されていると識別することに応じて実行される、請求項37に記載のモバイルデバイス。
39. 前記決定するための手段および前記送るための手段が、データの量がしきい値を上回ると識別することに応じて実行される、請求項37に記載のモバイルデバイス。
40. どのデータフローを報告するべきかを表示する構成を受信するための手段をさらに含む、請求項37に記載のモバイルデバイス。
41. 前記決定するための手段が、前記データフローに関するアグリゲーションポイントのロケーションの関数である、請求項37に記載のモバイルデバイス。
42. 前記データフローが新しいデータフローを含む、請求項37に記載のモバイルデバイス。
43. 前記データフローがアプリケーションに関するデータを含む、請求項37に記載のモバイルデバイス。
44. 前記データフローがサービスに関するデータを含む、請求項37に記載のモバイルデバイス。
45. 少なくとも1つのデータを管理するための第2のノードであって、
    ベアラまたはパケットデータネットワーク(PDN)接続のためにデータフローがアクティブであると決定するための手段と、
    前記データフローの1つまたは複数のサービス要件に基づいて、前記第2のノードにおいて前記データフローにサービスするか、または第1のノードにおいて前記データフローにサービスするかを判定するための手段と、
    前記データフローの承認に対する要求を前記第1のノードに送るための手段と
    を含む、第2のノード。
46. 承認に対する前記要求が、前記データフローのアグリゲーションのためのプロトコルレイヤの表示を含む、請求項45に記載の第2のノード。
47. 前記第1のノードおよび前記第2のノードが異なるRATを使用して動作する、請求項45に記載の第2のノード。
48. 前記データフローが新しいデータフローを含む、請求項45に記載の第2のノード。
49. どのデータフローを報告するべきかを表示する構成を送信するための手段をさらに含む、請求項45に記載の第2のノード。
50. 前記データフローがアプリケーションに関するデータを含む、請求項45に記載の第2のノード。
51. 前記データフローがサービスに関するデータを含む、請求項45に記載の第2のノード。
52. 少なくとも1つのデータフローに関する承認制御を実行するための第1のノードであって、
    複数のデータフローを含む、ベアラのための前記少なくとも1つのデータフローの承認に対する要求を第2のノードから受信するための手段と、
    前記ベアラを用いて前記少なくとも1つのデータフローにサービスするための、前記第1のノードにおけるリソースの可用性を評価するための手段と、
    リソースの前記評価された可用性に少なくとも部分的に基づいて、承認が前記少なくとも1つのデータフローに与えられるかどうかを前記第2のノードに表示するための手段と
    を含む、第1のノード。
53. 承認に対する前記要求が、前記少なくとも1つのデータフローのアグリゲーションのためのプロトコルレイヤの表示を含む、請求項52に記載の第1のノード。
54. 前記評価するための手段が、前記第1のノードにおけるアグリゲーションのためのフロー分割またはパケット分割のプロトコルレイヤより下のプロトコルレイヤによって管理されたリソースに関する、請求項52に記載の第1のノード。
55. 前記第1のノードおよび前記第2のノードが異なるRATを使用して動作する、請求項52に記載の第1のノード。
56. 前記少なくとも1つのデータフローにサービスするための、前記第1のノードにおけるリソースの可用性を前記評価するための手段が、前記第2のノードからデータフローを受け入れるために利用可能なリソースを決定するための手段を含む、請求項52に記載の第1のノード。
57. 新しいデータフローがアクティブであると決定するための手段と、
    前記決定に基づいてメッセージを前記第2のノードに送るための手段と
    をさらに含む、請求項52に記載の第1のノード。
58. 前記少なくとも1つのデータフローがアプリケーションに関するデータを含む、請求項52に記載の第1のノード。
59. 前記少なくとも1つのデータフローがサービスに関するデータを含む、請求項52に記載の第1のノード。
60. 第1のノードであって、
    既存のベアラまたは新しいパケットデータネットワーク(PDN)接続のために少なくとも1つのデータフローがアクティブであると決定するための手段であって、前記データフローが、前記第1のノードのプロトコルスタックの関連付けられたアグリゲーションレイヤを有する、決定するための手段と、
    前記データフローにサービスするための、前記第1のノードにおけるリソースの可用性を評価するための手段であって、前記評価が、前記第1のノードの前記プロトコルスタックの前記関連付けられたアグリゲーションレイヤより下の少なくとも1つのプロトコルレイヤによって管理されたリソースに関する、評価するための手段と、
    第2のノードに関連付けられたデータフローに関する、および前記第2のノードに関連付けられないデータフローに関する、前記第1のノードにおけるリソースの前記可用性を表示するメッセージを前記第2のノードに送信するための手段と
    を含む、第1のノード。
61. 前記メッセージが、前記少なくとも1つのデータフローに関する前記第1のノード上のリソース負荷を低減する必要性を表示する、請求項60に記載の第1のノード。
62. 少なくとも1つのデータフローにサービスすることを終了するための要求を受信するための手段をさらに含む、請求項60に記載の第1のノード。
63. キャリアまたは無線アクセス技術(RAT)を非アクティブ化するための要求を受信するための手段であって、アクティブなデータフローが、ハンドオーバ(HO)、または前記少なくとも1つのデータフローに関連付けられた、モバイルデバイスとの前記接続の非アクティブ化により解放される、受信するための手段をさらに含む、請求項60に記載の第1のノード。
64. それ以上のデータフローがキャリアまたはRAT上でサービスされない場合、前記キャリアまたは前記RATを非アクティブ化するための手段をさらに含む、請求項60に記載の第1のノード。
65. 前記データフローにサービスするための、前記第1のノードにおけるリソースの前記可用性を前記評価するための手段が、前記データフローに関連付けられたリソース負荷をしきい値と比較するための手段を含む、請求項60に記載の第1のノード。
66. 前記第1のノードが、前記データフローに関する承認に対する要求を前記第2のノードから前に受信しており、
    前記メッセージが、前記データフローに関する、前記第1のノードにおけるリソースの前記可用性を表示する
    請求項60に記載の第1のノード。
67. 前記データフローが新しいデータフローを含む、請求項60に記載の第1のノード。
68. 前記データフローがアプリケーションに関するデータを含む、請求項60に記載の第1のノード。
69. 前記データフローがサービスに関するデータを含む、請求項60に記載の第1のノード。
70. 命令を記憶した、コアネットワークとモバイルデバイスとの間の少なくとも1つのデータフローを管理するためのコンピュータ可読記憶媒体であって、前記命令が、前記モバイルデバイスに、
    前記データフローまたは前記データフローに関するサービスのうちの少なくとも1つが報告されるべきかどうかを決定することと、
    前記決定に基づいて第1のノードに報告を送ることであって、前記報告が、前記データフローまたは前記サービスのうちの少なくとも1つを識別し、前記サービスまたは前記データフローに関連付けられたパケットデータネットワーク(PDN)接続またはベアラを表示する、送ることと
    を行わせる、コンピュータ可読記憶媒体。
71. 命令を記憶した、少なくとも1つのデータを管理するためのコンピュータ可読記憶媒体であって、前記命令が、第2のノードに、
    ベアラまたはパケットデータネットワーク(PDN)接続のためにデータフローがアクティブであると決定させ、
    前記データフローの1つまたは複数のサービス要件に基づいて、前記第2のノードにおいて前記データフローにサービスするか、または第1のノードにおいて前記データフローにサービスするかを判定させ、
    前記データフローの承認に対する要求を前記第1のノードに送らせる
    コンピュータ可読記憶媒体。
72. 命令を記憶した、少なくとも1つのデータフローに関する承認制御を実行するためのコンピュータ可読記憶媒体であって、前記命令が、第1のノードに、
    複数のデータフローを含む、ベアラのための前記少なくとも1つのデータフローの承認に対する要求を第2のノードから受信させ、
    前記ベアラを用いて前記少なくとも1つのデータフローにサービスするための、前記第1のノードにおけるリソースの可用性を評価させ、
    リソースの前記評価された可用性に少なくとも部分的に基づいて、承認が前記少なくとも1つのデータフローに与えられるかどうかを前記第2のノードに表示させる
    コンピュータ可読記憶媒体。
73. 命令を記憶したコンピュータ可読記憶媒体であって、前記命令が、第1のノードに、
    既存のベアラまたは新しいパケットデータネットワーク(PDN)接続のために少なくとも1つのデータフローがアクティブであると決定することであって、前記データフローが、前記第1のノードのプロトコルスタックの関連付けられたアグリゲーションレイヤを有する、決定することと、
    前記データフローにサービスするための、前記第1のノードにおけるリソースの可用性を評価することであって、前記評価が、前記第1のノードの前記プロトコルスタックの前記関連付けられたアグリゲーションレイヤより下の少なくとも1つのプロトコルレイヤによって管理されたリソースに関する、評価することと、
    第2のノードに関連付けられたデータフローに関する、および前記第2のノードに関連付けられないデータフローに関する、前記第1のノードにおけるリソースの前記可用性を表示するメッセージを前記第2のノードに送信することと
    を行わせる、コンピュータ可読記憶媒体。

Images