(57)【要約】【課題】複数のRATを利用するシステムに関して、異なるRATによって提供される様々な経路を仮定して、コアネットワークとユーザとの間において、データの最適なルーティングを提供する。【解決手段】ワイヤレスネットワークは、現在の規格下で、コアネットワークエンティティからユーザ機器(UE)への1つのパスに続くダウンリンク(DL)パケットを複数の基地局(BS)に送り、基地局の各々からUEに送り得る。UEは、DLパケットを最初に配信するいずれかのBSからDLパケットを受信し、次いで、UEはDLパケットの受信を報告する報告をすべてのBSに返送する。たとえまだパケットを正常に配信していなくても、UEがパケットを受信したことを示す報告を受信するBSは、パケットを廃棄することができる。同じ手順が、UEから複数のBSに、およびBSからコアネットワークエンティティに送られ得るULパケットのために使用され得る。【選択図】図１１
2019083582.tif 000002
【特許請求の範囲】
【請求項１】
データフローのステータスを報告する方法であって、
複数の接続からデータフローが受信されていると決定するステップと、
前記複数の接続のうちの2つ以上の接続上で、前記データフロー上で受信されたパケットのステータスを報告するステップと
を備える、方法。
【請求項２】
前記データフローが、アグリゲーションポイントにおいて分割されたパケットの選択に基づいて決定されたレイヤより下のプロトコルスタック内のレイヤに従って送られる、請求項1に記載の方法。
【請求項３】
ステータスを報告するステップが、パケットデータコンバージェンスプロトコル(PDCP)ステータス報告を送るステップ、または無線リンク制御(RLC)ステータス報告を送るステップを備える、請求項1に記載の方法。
【請求項４】
前記複数の接続の各接続上で同じステータスが送られる、請求項1に記載の方法。
【請求項５】
前記データフローが前記複数の接続から受信されていると決定するステップが、前記データフローが2つ以上の接続上で送られていることを示す構成を受信するステップを備える、請求項1に記載の方法。
【請求項６】
前記受信された構成が、前記データフローが2つ以上の接続上で送られていることを示すベアラタイプを備える、請求項5に記載の方法。
【請求項７】
データフローが複数の接続から受信されていると決定するステップが、2つ以上の接続上で前記データフローの複製パケットを受信するステップを備える、請求項1に記載の方法。
【請求項８】
前記データフローの少なくとも1つのサービス要件に基づいて、前記データフローが2つ以上の接続上で送られることを要求する指示を送るステップをさらに備える、請求項1に記載の方法。
【請求項９】
データフローを送信する方法であって、
データフローが複数の接続上で送信されるべきであると決定するステップであって、前記データフローが、アグリゲーションポイントにおいて分割されたパケットの選択に基づいて決定されたレイヤより下のプロトコルスタック内のレイヤに従って送られる、ステップと、
前記複数の接続のうちの2つ以上の接続上で、前記データフローの少なくとも1つのデータパケットを転送するステップと
を備える、方法。
【請求項１０】
前記決定されたレイヤが、パケットデータコンバージェンスプロトコル(PDCP)レイヤ、または無線リンク制御(RLC)レイヤを備える、請求項9に記載の方法。
【請求項１１】
受信されたデータを示すステータス報告を受信するステップをさらに備える、請求項9に記載の方法。
【請求項１２】
前記ステータス報告が、1つまたは複数のデータパケットが、前記複数の接続のうちの第1の接続上で受信されたことを示し、前記方法が、前記複数の接続のうちの他の接続上で前記1つまたは複数のデータパケットを転送することをやめるステップをさらに備える、請求項11に記載の方法。
【請求項１３】
前記データフローを2つ以上の接続上で送られるように構成する要求を送信するステップをさらに備える、請求項9に記載の方法。
【請求項１４】
前記決定するステップが、前記データフローが2つ以上の接続上で送られるようにする構成を受信するステップを備える、請求項9に記載の方法。
【請求項１５】
前記決定するステップが、前記データフローの少なくとも1つのサービス要件に基づく、請求項9に記載の方法。
【請求項１６】
データフローのステータスを報告するための装置であって、
複数の接続からデータフローが受信されていると決定するための手段と、
前記複数の接続のうちの2つ以上の接続上で、前記データフロー上で受信されたパケットのステータスを報告するための手段と
を備える、装置。
【請求項１７】
前記データフローが、アグリゲーションポイントにおいて分割されたパケットの選択に基づいて決定されたレイヤより下のプロトコルスタック内のレイヤに従って送られる、請求項16に記載の装置。
【請求項１８】
ステータスを報告するための手段が、PDCPステータス報告を送るための、またはRLCステータス報告を送るための手段を備える、請求項16に記載の装置。
【請求項１９】
ステータスを報告するための手段が、前記複数の接続の各接続上で同じステータスを送るための手段を備える、請求項16に記載の装置。
【請求項２０】
前記データフローが前記複数の接続から受信されていると決定するための手段が、前記データフローが2つ以上の接続上で送られていることを示す構成を受信するための手段を備える、請求項16に記載の装置。
【請求項２１】
前記受信された構成が、前記データフローが2つ以上の接続上で送られていることを示すベアラタイプを備える、請求項20に記載の装置。
【請求項２２】
前記データフローが前記複数の接続から受信されていると決定するための手段が、2つ以上の接続上で前記データフローの複製パケットを受信するための手段を備える、請求項16に記載の装置。
【請求項２３】
前記データフローの少なくとも1つのサービス要件に基づいて、前記データフローが2つ以上の接続上で送られることを要求する指示を送るための手段をさらに備える、請求項16に記載の装置。
【請求項２４】
データフローを送信するための装置であって、
データフローが複数の接続上で送信されるべきであると決定するための手段であって、前記データフローが、アグリゲーションポイントにおいて分割されたパケットの選択に基づいて決定されたレイヤより下のプロトコルスタック内のレイヤに従って送られる、手段と、
前記複数の接続のうちの2つ以上の接続上で、前記データフローの少なくとも1つのデータパケットを転送するための手段と
を備える、装置。
【請求項２５】
前記決定されたレイヤが、パケットデータコンバージェンスプロトコル(PDCP)レイヤ、または無線リンク制御(RLC)レイヤを備える、請求項24に記載の装置。
【請求項２６】
受信されたデータを示すステータス報告を受信するための手段をさらに備える、請求項24に記載の装置。
【請求項２７】
前記ステータス報告が、1つまたは複数のデータパケットが、前記複数の接続のうちの第1の接続上で受信されたことを示し、前記装置が、
前記複数の接続のうちの他の接続上で前記1つまたは複数のデータパケットを転送することをやめるための手段をさらに備える、請求項26に記載の装置。
【請求項２８】
前記データフローを2つ以上の接続上で送られるように構成する要求を送信するための手段をさらに備える、請求項24に記載の装置。
【請求項２９】
前記データフローが前記複数の接続上で送信されるべきであると決定するための手段が、前記データフローを2つ以上の接続上で送られるようにする構成を受信するための手段を備える、請求項24に記載の装置。
【請求項３０】
前記データフローが前記複数の接続上で送信されるべきであると決定するための手段が、前記データフローの少なくとも1つのサービス要件に基づいて、前記データフローが前記複数の接続上で送信されるべきであると決定するための手段を備える、請求項24に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、2014年8月19日に出願された米国仮出願第62/039,227号の利益を主張する、2015年1月14日に出願された米国特許出願第14/597,102号に対する優先権を主張し、それらは本出願の譲受人に譲渡され、それらの全体が参照により本明細書に明示的に組み込まれる。
【０００２】
本開示は、一般に、ワイヤレス通信に関し、より詳細には、多重接続性を使用するマルチキャスティングトラフィックのための方法および装置に関する。
【背景技術】
【０００３】
新しいユーザ経験を提供することになる、新しいサービスおよびデバイスを可能にするためのワイヤレス通信システムが開発されている。これを達成する1つの手法は、たとえば、ワイヤレスワイドエリアネットワーク(たとえば、3GおよびLTE)および(たとえば、WiFiおよびミリメートル波(mmW)に基づく)ワイヤレスローカルエリアネットワークからの特徴の組合せを使用して、複数の既存の無線アクセス技術(RAT)を活用することである。この手法は、開発の加速を助け、異なるRATによって提供される様々な利点を利用することができる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
複数のRATを利用するシステムに関する1つの課題は、異なるRATによって提供される様々な経路を仮定して、コアネットワークとユーザとの間でどのようにデータを最適にルーティングするかである。
【課題を解決するための手段】
【０００５】
本開示のいくつかの態様は、データフローのステータスを報告する方法を提供する。本方法は、一般に、複数の接続からデータフローが受信されていると決定することと、複数の接続のうちの2つ以上の接続上で、データフロー上で受信されたパケットのステータスを報告することとを含む。
【０００６】
本開示のいくつかの態様は、データフローを送信する方法を提供する。本方法は、一般に、データフローが複数の接続上で送信されるべきであると決定するステップであって、データフローが、アグリゲーションポイントにおいて分割されたパケットの選択に基づいて決定されたレイヤより下のプロトコルスタック内のレイヤに従って送られる、ステップと、複数の接続上でデータフローのデータを転送するステップとを含む。
【０００７】
本開示のいくつかの態様は、データフローのステータスを報告するための装置を提供する。本装置は、一般に、複数の接続からデータフローが受信されていると決定するための手段と、複数の接続のうちの2つ以上の接続上で、データフロー上で受信されたパケットのステータスを報告するための手段とを含む。
【０００８】
本開示のいくつかの態様は、データフローを送信するための装置を提供する。本装置は、一般に、データフローが複数の接続上で送信されるべきであると決定するための手段であって、データフローが、アグリゲーションポイントにおいて分割されたパケットの選択に基づいて決定されたレイヤより下のプロトコルスタック内のレイヤに従って送られる、手段と、複数の接続のうちの2つ以上の接続上で、データフローの少なくとも1つのデータパケットを転送するための手段とを含む。
【０００９】
態様はまた、上で説明した動作を実行するための様々な装置、システム、コンピュータプログラム製品、および処理システムを提供する。
【図面の簡単な説明】
【００１０】
【図１】本開示の態様が利用され得る、例示的なマルチRATシステムを示す図である。
【図２Ａ】本開示のいくつかの態様による、制御プレーンおよびユーザプレーンルーティングのための例示的なプロトコルレイヤを示す図である。
【図２Ｂ】本開示のいくつかの態様による、制御プレーンおよびユーザプレーンルーティングのための例示的なプロトコルレイヤを示す図である。
【図３】本開示の態様による、例示的な多重接続性プロトコルスタックを示す図である。
【図４】本開示の態様による、例示的なオフロード構成を示す図である。
【図５】本開示の態様による、例示的なユーザプレーン(Uプレーン)分割構成を示す図である。
【図６】本開示の態様による、例示的な制御プレーン(Cプレーン)論理アーキテクチャオプションを示す図である。
【図７】本開示の態様による、例示的な制御プレーン(Cプレーン)NAS論理アーキテクチャオプションを示す図である。
【図８】本開示の態様による、UE、マスタeNodeB(MeNB)、およびセカンダリeNodeB(SeNB)の例示的なコールフロー図である。
【図９Ａ】本開示の態様による、多重接続性を使用するメッセージの例示的な交換を示す図である。
【図９Ｂ】本開示の態様による、多重接続性を使用するメッセージの例示的な交換を示す図である。
【図１０Ａ】本開示の態様による、多重接続性を使用するメッセージの例示的な交換を示す図である。
【図１０Ｂ】本開示の態様による、多重接続性を使用するメッセージの例示的な交換を示す図である。
【図１０Ｃ】本開示の態様による、多重接続性を使用するメッセージの例示的な交換を示す図である。
【図１０Ｄ】本開示の態様による、多重接続性を使用するメッセージの例示的な交換を示す図である。
【図１１】本開示の態様による、ユーザ機器(UE)によって実行され得る例示的な動作を説明する図である。
【図１２】本開示の態様による、eNodeB(eNB)によって実行され得る例示的な動作を説明する図である。
【図１３】本開示の態様による、例示的なユーザ機器のブロック図である。
【図１４】本開示の態様による、例示的な基地局のブロック図である。
【発明を実施するための形態】
【００１１】
本開示の態様は、コアネットワークと、複数の無線アクセス技術(RAT)を介して接続されたユーザ機器(UE)との間でデータをルーティングするために使用され得る技法を提供する。いくつかの態様によれば、現在の標準(たとえば、Rel-12)下で、コアネットワークエンティティからユーザ機器(UE)への1つのパスに続くダウンリンク(DL)パケットが、コアネットワークから複数の基地局(たとえば、eNodeBおよびアクセスポイント)に、および基地局の各々からUEに送られる。UEは、最初にDLパケットを配信するいずれかの基地局(BS)からDLパケットを受信し、次いで、UEはDLパケットの受信を報告する報告(たとえば、ACK)をすべてのBSに返送する。たとえBSがまだパケットを正常に配信していなくても、UEがパケットを受信したことを示す報告を受信するBSは、パケットを廃棄することができる。本開示のいくつかの態様によれば、現在の標準(たとえば、Rel-12)下で、UEからコアネットワークエンティティへの1つのパスに続くアップリンク(UL)パケットが、UEによって複数のBS(たとえば、eNodeBおよびアクセスポイント)に、および基地局からコアネットワークエンティティに送られる。コアネットワークエンティティは、最初にULパケットを配信するいずれかの基地局(BS)からULパケットを受信し、次いで、コアネットワークエンティティは、ULパケットの受信を報告する報告(たとえば、ACK)をすべてのBSに返送する。たとえBSがまだパケットを正常に配信していなくても、UEがパケットを受信したことを示す報告を受信するBSは、パケットを廃棄することができる。
【００１２】
本開示の態様は、多種多様な異なる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 convergence 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上でリソースを解放する。
【００６７】
上述したように、UEが多重接続性(たとえば、デュアルコネクティビティ)を介してコアネットワークに接続されている場合、ベアラのためのデータは、MeNBまたはSeNBを介してUEに、またはUEから送信され得る。
【００６８】
本開示のいくつかの態様によれば、データ配信信頼性要件(たとえば、パケット損失、レイテンシ要件、またはQoS要件)が確実に満たされることを助けるために、いくつかのミッションクリティカルなサービスに対して、UEは、同じ複製パケットをMeNBとSeNBの両方に送るように構成され得る。MeNBとSeNBの両方に複製パケットを送ることによって、たとえば、コアネットワークサーバへのパケットの正常な配信およびタイムリーな配信の確率が高まり得る。同様に、いくつかのサービスのためのダウンリンクパケットも複製され、MeNBとSeNBの両方を介してUEに送られ得る。
【００６９】
本開示の態様によれば、そのような複製パケットは、本明細書では重複配信ベアラと呼ばれる、新しいタイプのベアラを使用して送られ得る。本開示の態様によれば、重複配信ベアラは、多重接続性を介して(たとえば、MeNBおよび1つまたは複数のSeNBを介して)接続されたコアネットワークとUEとの間でデータを交換するために使用され得る。
【００７０】
場合によっては、重複配信ベアラが通信のために使用される場合、MeNBはS1-Uベアラを介してS-GWにUプレーン接続され、MeNBおよびSeNBはX2-Uインターフェースを介して相互接続される。したがって、重複配信ベアラは、図3を参照して上述したように、MCGベアラとSCGベアラの組合せと同様であり得る。
【００７１】
図9Aおよび図9Bは、本開示の態様による、多重接続性を使用してパケットを送信する例を示す。これらの例は、ゲートウェイ(GW)、MeNB、SeNB、およびUE間のメッセージの交換を含む。メッセージの交換は、現在の(たとえば、Rel-10)技法に従って実行され得る。
【００７２】
図9Aを参照すると、(1)において、ゲートウェイ140は、UE110宛てのDLパケットを受信する。(2)において、ゲートウェイは、DLパケットをMeNB120に送り、MeNB120は、たとえば、チャネル条件またはスケジューリング制約に基づいて、パケットをUEに配信することを決定する。MeNBは、UEへの配信前にパケットをバッファリングする。(3)において、MeNBはDLパケットをUEに配信する。(4)において、UEはACKをMeNBに送る。(5)において、UEは、UEがDLパケットを受信したことを示す報告(たとえば、PDCPもしくはRLCステータス報告、または確認応答および非確認応答パケットを示すビットマップ)をMeNBに送る。MeNBが報告を受信すると、MeNBはMeNBのバッファからパケットをフラッシュする。UEへのパケットの配信が失敗した場合、UEはパケットの受信を報告せず、MeNBはパケットをUEに再送信し得る(図示せず)。
【００７３】
図9Bを参照すると、(1)において、ゲートウェイ140は、UE110宛てのDLパケットを受信する。(2)において、ゲートウェイは、DLパケットをMeNB120に送り、MeNB120は、たとえば、チャネル条件またはスケジューリング制約に基づいて、パケットをUEに配信するためにSeNB130に転送することを決定する。MeNBは、パケットをSeNBに転送し、SeNBは、UEへの配信前にパケットをバッファリングする。(3)において、SeNBはDLパケットをUEに配信する。(4)において、UEはACKをSeNBに送る。(5)において、UEは、UEがDLパケットを受信したことを示す報告(たとえば、PDCPもしくはRLCステータス報告、または確認応答および非確認応答パケットを示すビットマップ)をSeNBに送る。SeNBが報告を受信すると、SeNBはSeNBのバッファからパケットをフラッシュする。UEへのパケットの配信が失敗した場合、UEはパケットの受信を報告せず、SeNBはパケットをUEに再送信し得る(図示せず)。
【００７４】
図9Aおよび図9Bに示される例は、単一のSeNBのみを示しているが、本開示はそれに限定されず、より多数のSeNBを含む。図示された例は、コアネットワークエンティティからUEに送られるDLパケットを示しているが、本開示はそれに限定されず、UEからコアネットワークエンティティに送られるULパケットにも同様に適用され得る。
【００７５】
図10A、図10B、図10C、および図10Dは、本開示の態様による、多重接続性を使用して複製パケットを送信する例を示す。これらの例は、ゲートウェイ(GW)、MeNB、SeNB、およびUE間のメッセージの交換を含む。メッセージの交換は、前述したように、重複配信ベアラを使用して実行され得る。
【００７６】
まず図10Aを参照すると、(1)において、ゲートウェイ140は、多重接続性のために構成された、UE宛てのデータフローのDLパケットを受信する。(2)において、ゲートウェイは、DLパケットをMeNB120に送り、MeNB120は、UE110への配信のためにDLパケットの複製をSeNB130に送る。MeNBとSeNBの両方は、UEへの配信を試みる前にパケットをバッファリングする。(3)において、MeNBおよびSeNBはDLパケットをUEに配信しようとする。(4)において、UEは、ACKをMeNBに送り、NAKをSeNBに送る。
【００７７】
図10Aに示される例において、MeNBはパケットを配信することに失敗している(たとえば、干渉のために)。MeNBおよびSeNBは、DLパケットをUEに配信しているときにパケットを送るときに調整しない場合がある。このメッセージの交換は、MeNBおよびSeNBの各々が独立してパケットを送信する(たとえば、MeNBおよびSeNBの各々が、それぞれMeNBおよびSeNBのPDSCH上で送られるようにパケットを独立してスケジューリングし得る)が、ソフトハンドオーバでは、ソースeNBおよびターゲットeNBは、時間およびエアリンクリソースにおけるパケットの送信を調整するという点で、メッセージのソフトハンドオーバ交換とは異なる。さらに、MeNBおよびSeNBの各々は、MACレイヤにおいて別個のACKまたはNAKを受信するが、ソフトハンドオーバでは、ソースeNBおよびターゲットeNBは両方とも、MACレイヤにおいてUEによってソースeNBとターゲットeNBの両方に送られた単一のACKまたはNAKを受信する。
【００７８】
(5)において、UEは、受信パケットは重複配信ベアラを介して受信されたと決定し、UEがDLパケットを受信したことを示す報告(たとえば、PDCPもしくはRLCステータス報告、または確認応答および非確認応答パケットを示すビットマップ)をMeNBおよびSeNBに送る。MeNBおよびSeNBは、UEから報告を受信し、各々が、それらのそれぞれのバッファからパケットをフラッシュする。MeNBは、1006でMeNBがパケットを正常に配信しなかったにもかかわらず、再送信を試みずにパケットをフラッシュする。
【００７９】
図10Bを参照すると、(1)において、ゲートウェイ140は、多重接続性のために構成された、UE宛てのデータフローのDLパケットを受信する。(2)において、ゲートウェイは、DLパケットをMeNB120に送り、MeNB120は、UE110への配信のためにDLパケットの複製をSeNB130に送信する。MeNBとSeNBの両方は、UEへの配信を試みる前にパケットをバッファリングする。
【００８０】
(3)において、MeNBおよびSeNBはDLパケットをUEに配信しようとする。この例では、SeNBはパケットを配信することに失敗している(たとえば、干渉のために)。上記のように、MeNBおよびSeNBは、DLパケットをUEに配信しているときにパケットを送るときに調整しない場合がある。(4)において、UEは、NAKをMeNBに送り、ACKをSeNBに送る。(5)において、UEは、受信パケットは重複配信ベアラを介して受信されたと決定し、UEがDLパケットを受信したことを示す報告(たとえば、PDCPもしくはRLCステータス報告、または確認応答および非確認応答パケットを示すビットマップ)をMeNBおよびSeNBに送る。MeNBおよびSeNBは、UEから報告を受信し、各々が、それらのそれぞれのバッファからパケットをフラッシュする。SeNBは、(3)でSeNBがパケットを正常に配信しなかったにもかかわらず、再送信を試みずにパケットをフラッシュする。
【００８１】
図10Cでは、(1)において、ゲートウェイ140は、多重接続性のために構成された、UE宛てのデータフローのDLパケットを受信する。(2)において、ゲートウェイは、DLパケットをMeNB120に送り、上記のように、MeNBは、DLパケットの複製をUE110への配信のためにSeNB130に送る。上記のように、MeNBとSeNBの両方は、UEへの配信を試みる前にパケットをバッファリングする。
【００８２】
上記と同様に、(3)において、MeNBおよびSeNBはDLパケットをUEに配信する。上記のように、MeNBおよびSeNBは、DLパケットをUEに配信しているときにパケットを送るときに調整しない場合がある。(4)において、UEは、ACKをMeNBに送り、ACKをSeNBに送る。(5)において、UEは、受信パケットは重複配信ベアラを介して受信されたと決定し、UEがDLパケットを受信したことを示す報告(たとえば、PDCPもしくはRLCステータス報告、または確認応答および非確認応答パケットを示すビットマップ)をMeNBおよびSeNBに送る。
【００８３】
MeNBおよびSeNBは、UEから報告を受信し、各々が、それらのそれぞれのバッファからパケットをフラッシュする。いくつかの態様によれば、MeNBおよびSeNBは、パケットを異なる時間に配信し得、UEは、異なる時間の配信の各々に応答して、パケットの受信を報告する報告を送り得る。
【００８４】
図10Dを参照すると、(1)において、ゲートウェイ140は、多重接続性のために構成された、UE宛てのデータフローのDLパケットを受信する。図10A、図10B、および図10Cと同様に、(2)において、ゲートウェイは、DLパケットをMeNB120に送り、MeNB120は、UE110への配信のためにDLパケットの複製をSeNB130に送る。上記のように、MeNBとSeNBの両方は、UEへの配信を試みる前にパケットをバッファリングする。
【００８５】
(3)において、MeNBおよびSeNBはDLパケットをUEに配信しようとするが、両方が失敗する(たとえば、干渉のために)。上記のように、MeNBとSeNBは、配信を試みているときにパケットを送るときに調整しない場合がある。(4)において、UEは、NAKをMeNBに送り、NAKをSeNBに送る。(5)において、MeNBおよびSeNBは、それぞれUEがパケットの受信を報告していないと決定し、UEへのパケットの再送信を試みる。NAKが受信されない場合、MeNBおよびSeNBは、たとえば、(3)でタイマを開始し、(5)で再送信を試みるべきであると決定する前にタイマが終了するのを待つことができる。
【００８６】
図10A、図10B、図10C、および図10Dの例では、MeNBとSeNBの両方がDLパケットをUEに配信しようする。しかしながら、場合によっては、eNBのうちの1つが、他のeNBがDLパケットの配信を試みることができる前に(たとえば、異なる送信遅延、異なる待ち行列遅延、異なるバックホール遅延、または異なる干渉のために)、DLパケットを実際に配信し得る。
【００８７】
eNBが配信を試みていない場合、他のeNBが正常に配信する場合は、通信交換は図10Aおよび図10Bに示されるものと同様であり、UEは、パケットの受信をMeNBとSeNBの両方に報告し、MeNBとSeNBの両方は、それらのそれぞれのバッファからパケットをフラッシュする。MeNBおよびSeNBは、図3に示される例示的なプロトコルスタックを使用して動作し得る。UEからの報告は、MeNBおよびSeNBが、配信されたパケットを、MeNBまたはSeNB上で配信を待つ(たとえば、バッファリングされた)パケットと同じものとして識別し得るように、図3に示される共通PDCPレイヤにおける複製パケットを参照するパケットの識別子(たとえば、パケットシーケンス番号)を参照する。そのような場合、不必要な送信を避けるために、まだ配信していないパケットを参照する報告(たとえば、ACK)を受信するeNBは、そのパケットを配信することを控えることができる。
【００８８】
図10A、図10B、図10Cおよび図10Dに示される例は、それぞれ単一のSeNBのみを示しているが、本開示はそれに限定されず、より多数のSeNBを含む。図9Aおよび図9Bを参照する上記のように、図10A、図10B、図10C、および図10Dの例は、それぞれコアネットワークエンティティからUEに送られるDLパケットを示すが、本開示はそれに限定されず、UEからコアネットワークエンティティに送られるULパケットにも同様に適用され得る。
【００８９】
図11は、本開示の態様による、2つ以上の接続(すなわち、多重接続性)から複製パケットが受信されているデータフローのステータスを報告するための例示的な動作1100を説明する。動作1100は、たとえば、図10A、図10B、図10C、および図10Dに示されるUE110などのUEによって実行され得る。
【００９０】
動作は、1102において、たとえば、UEによって、データフローが複数の接続から受信されていると決定することから始まる。1104において、動作はUEによって継続し、たとえば、複数の接続のうちの2つ以上の接続上で、データフロー上で受信されたパケットのステータスを報告する。これらの動作の例は、上記で図10A、図10B、および図10Cを参照して示されている。
【００９１】
本開示のいくつかの態様によれば、データフローは、アグリゲーションポイントにおいて分割されたパケットの選択に基づいて決定されたレイヤより下のプロトコルスタック内のレイヤに従って送られる。すなわち、アグリゲーションポイント(たとえば、ゲートウェイまたはeNB)は、プロトコルスタック内のレイヤ(たとえば、RLCレイヤまたはPDCPレイヤ)においてデータフローのパケットを分割することを決定し得、データフローは、決定されたレイヤまたはそれより下のレイヤを使用して送られる。いくつかの態様では、決定されたレイヤは、パケットデータコンバージェンスプロトコル(PDCP)レイヤ、または無線リンク制御(RLC)レイヤを備える。
【００９２】
本開示のいくつかの態様によれば、ステータスを報告するステップは、PDCPステータス報告を送るステップ、またはRLCステータス報告を送るステップを備える。すなわち、UEは、PDCPステータス報告、またはパケットの指示を含むRLCステータス報告を送ることによって、パケットのステータスを報告し得る。本開示のいくつかの態様によれば、複数の接続の各接続上で同じステータスが送られる。すなわち、たとえUEがいくつかの接続上ではパケットを正常に受信したが、他の接続上ではパケットを正常に受信しなかったとしても、UEは複数の接続の各々上で同じステータス(たとえば、「正常に受信した」)を報告する。
【００９３】
本開示のいくつかの態様によれば、UEは、データフローを2つ以上の接続上で受信されるように構成する構成(たとえば、RRC構成)を受信し得る。ある態様では、構成(たとえば、RRC構成)は、データフローが2つ以上の接続上で送られていることを示すベアラタイプを構成し得る。すなわち、特定のタイプのベアラ(たとえば、重複配信ベアラ)の使用は、そのタイプのベアラによって搬送されるすべてのデータフローが2つ以上の接続上で送られていることをUEに示し得る。
【００９４】
本開示のいくつかの態様によれば、データフローが複数の接続から受信されていると決定するステップは、2つ以上の接続上でデータフローの複製パケットを受信するステップを備える。すなわち、受信デバイスは、データフローの複製パケットを受信したと決定し、またデータフローが複数の接続から受信されていると決定し得る。
【００９５】
本開示のいくつかの態様によれば、UEは、データフローの少なくとも1つのサービス要件の指示を別のエンティティ(たとえば、コアネットワークエンティティ)に送り得る。たとえば、UEは、データフローが特定のQoSを要求するか、またはサービスを指示することをコアネットワークエンティティ(たとえば、MME)に通知し得、コアネットワークエンティティは、指示されたサービスのQoSを決定する。本開示のいくつかの態様によれば、UEは、データフローの少なくとも1つのサービス要件に基づいて、データフローが2つ以上の接続上で送られることを要求する指示を送り得る。たとえば、UEは、データフローが非常に短いレイテンシを必要とすると決定し、データフローが非常に低いレイテンシを必要とすると決定するステップに基づいて、データフローが複数の接続上で送られることを要求し得る。
【００９６】
図12は、本開示の態様による、複数の接続(すなわち、多重接続性)上でデータフローの複製パケットを送信するための例示的な動作1200を説明する。動作1200は、たとえば、図10A、図10B、図10C、および図10Dに示されるMeNBおよびSeNBなどの基地局(BS)によって実行され得る。
【００９７】
動作は、1202において、たとえば、BSによって、データフローが複数の接続上で送信されるべきであると決定するステップであって、データフローが、アグリゲーションポイントにおいて分割されたパケットの選択に基づいて決定されたレイヤより下のプロトコルスタック内のレイヤに従って送られる、ステップから始まる。すなわち、データフローのアグリゲーションポイント(たとえば、BSまたはゲートウェイ)は、プロトコルスタック内のレイヤ(たとえば、RLCレイヤまたはPDCPレイヤ)でデータフローのパケットを分割することを決定し、次いで、データフローをサービスしている他のデバイス(たとえば、BS)は、(たとえば、ネットワークエンティティによって交換される制御メッセージに基づいて)データフローは複数の接続上で(たとえば、決定されたレイヤまたはそれより下のレイヤを使用して)送られるべきであると決定し得る。1204において、動作はBSによって継続し、たとえば、複数の接続上でデータフローのためのデータ(たとえば、データパケット)を転送する。
【００９８】
本開示のいくつかの態様によれば、決定されたレイヤは、パケットデータコンバージェンスプロトコル(PDCP)レイヤ、または無線リンク制御(RLC)レイヤを備える。たとえば、BSは、PDCPレイヤにおいてデータフローを分割し、複数の接続を介してデータフローの複製PDCPパケットを送ることを決定し得る。
【００９９】
本開示のいくつかの態様によれば、BSは、受信されたデータを示すステータス報告を受信し得る。たとえば、BSは、特定のパケットがUEによって受信されたことを示すステータス報告を受信し得る。ある態様では、ステータス報告は、PDCPステータス報告またはRLCステータス報告を備え得る。別の態様では、ステータス報告は、データが複数の接続のうちの第1の接続上で受信されたことを示し、BSは複数の接続のうちの他の接続上でデータを転送することをやめる。
【０１００】
本開示のいくつかの態様によれば、BSは、データフローを2つ以上の接続上で送られるように構成する要求を送信し得る。ある態様では、データフローを2つ以上の接続上で送られるように構成する要求は、たとえばRRC構成を介して2つ以上の接続上でデータフローを受信するようにUEを構成することを含み得る。ある態様では、構成(たとえば、RRC構成)は、データフローが2つ以上の接続上で送られていることを示すベアラタイプを構成することを備え得る。すなわち、特定のタイプのベアラ(たとえば、重複配信ベアラ)の使用は、そのタイプのベアラによって搬送されるすべてのデータフローが2つ以上の接続上で送られていることを(たとえば、UEに)示し得る。
【０１０１】
本開示のいくつかの態様によれば、BSは、(たとえば、コアネットワークエンティティから)データフローが2つ以上の接続上で送られるようにする構成を受信し得る。本開示のいくつかの態様によれば、BSは、データフローの少なくとも1つのサービス要件に基づいて、データフローは複数の接続上で送信されるべきであると決定し得る。たとえば、BSは、データフローが非常に短いレイテンシを必要とすると決定し、データフローが非常に低いレイテンシを必要とすると決定するステップに基づいて、データフローを複数の接続上で送ると決定し得る。
【０１０２】
図13は、本明細書で提供される態様に従って動作することが可能な多重接続性対応ワイヤレスデバイス1300において利用され得る様々な構成要素を示す。ワイヤレスデバイス1300は、たとえば、図1に示したUE110の1つの実装形態であり得る。
【０１０３】
ワイヤレスデバイス1300は、ワイヤレスデバイス1300の動作を制御する1つまたは複数のプロセッサ1304を含み得る。プロセッサ1304は、中央処理ユニット(CPU)とも呼ばれ得る。プロセッサ1304は、図11および図12を参照して上述したように、データフローのステータスのマルチキャスティングおよび報告を実行するか、またはUEに実行を指示し得る。読取り専用メモリ(ROM)とランダムアクセスメモリ(RAM)の両方を含むことができるメモリ1306は、命令およびデータをプロセッサ1304に提供する。メモリ1306の一部分は、不揮発性ランダムアクセスメモリ(NVRAM)を含む場合もある。プロセッサ1304は、典型的には、メモリ1306内に記憶されたプログラム命令に基づいて論理演算および算術演算を実行する。メモリ1306内の命令は、本明細書で説明された方法を実施するために、たとえば、図11および図12を参照して上述したように、データフローのステータスを報告する、およびマルチキャスティングするために実行可能であり得る。
【０１０４】
ワイヤレスデバイス1300は、多重接続性のための複数のRATを介して通信するための無線1310および1312を含んでもよい。各無線は、たとえば、送信機および受信機を含んでよく、ワイヤレスデバイス1300と様々なRATとの間のデータの送受信を可能にするための任意の他の「RFチェーン」構成要素を含んでもよい。単なる一例として、2つの無線が2つのRATのために示されているが、(たとえば、3つ以上のRATをサポートするために)3つ以上の無線が含まれてもよい。各無線は、単一または複数のアンテナ1316を介して通信することができる。
【０１０５】
ワイヤレスデバイス1300は、トランシーバ1314によって受信された信号のレベルを検出し定量化するために使用することができる信号検出器1318を含むこともできる。信号検出器1318は、総エネルギー、シンボルごとのサブキャリア当りのエネルギー、電力スペクトル密度、および他の信号などの信号を検出することができる。ワイヤレスデバイス1300は、信号を処理する際に使用するためのデジタル信号プロセッサ(DSP)1320を含む場合もある。
【０１０６】
図14は、多重接続性対応ワイヤレスデバイスとの通信に参加することができる、基地局1400内で利用され得る様々な構成要素を示す。基地局1400は、たとえば、図1に示したMeNB120またはSeNB130の1つの実装形態であり得る。
【０１０７】
基地局1400は、基地局1400の動作を制御する1つまたは複数のプロセッサ1404を含み得る。プロセッサ1404は、中央処理ユニット(CPU)とも呼ばれ得る。プロセッサ1404は、図11および図12を参照して上述したように、データフローのステータスのマルチキャスティングおよび報告を実行するか、またはBSに実行を指示し得る。読取り専用メモリ(ROM)とランダムアクセスメモリ(RAM)の両方を含むことができるメモリ1406は、命令およびデータをプロセッサ1404に提供する。メモリ1406の一部分は、不揮発性ランダムアクセスメモリ(NVRAM)を含む場合もある。プロセッサ1404は、典型的には、メモリ1406内に記憶されたプログラム命令に基づいて論理演算および算術演算を実行する。メモリ1406内の命令は、本明細書で説明する方法を実施するために、たとえば、多重接続性UEにサービスするMeNBおよびSeNBについて、図11および図12を参照して上述したように、データフローのステータスを報告する、およびマルチキャスティングするために実行可能であり得る。
【０１０８】
基地局1400は、たとえば、1つまたは複数のRATを介してUEと通信するために1つまたは複数の無線1410を含んでもよい。各無線は、たとえば、送信機および受信機を含んでよく、基地局1400と様々なUEとの間のデータの送受信を可能にするための任意の他の「RFチェーン」構成要素を含んでもよい。各無線は、単一または複数のアンテナ1416を介して通信することができる。基地局1400は、(たとえば、X2バックホール接続を介して)他の基地局と、または(たとえば、S1接続を介して)コアネットワークと通信するためのインターフェース1412を含んでもよい。
【０１０９】
基地局1400は、トランシーバ1414によって受信された信号のレベルを検出し定量化するために使用することができる信号検出器1418を含むこともできる。信号検出器1418は、総エネルギー、シンボルごとのサブキャリア当りのエネルギー、電力スペクトル密度、および他の信号などの信号を検出することができる。基地局1400は、信号を処理する際に使用するためのデジタル信号プロセッサ(DSP)1420を含む場合もある。
【０１１０】
上記で開示したプロセスにおけるステップの特定の順序または階層は、例示的な手法の例であることを理解されたい。設計上の選好に基づいて、プロセスにおけるステップの特定の順序または階層が並べ替えられてもよいことを理解されたい。さらに、いくつかのステップは、組み合わされるか、または省略される場合がある。添付の方法クレームは、様々なステップの要素を見本的な順序で提示したものであり、提示された特定の順序または階層に限定されるものではない。
【０１１１】
さらに、「または」という用語は、排他的な「または」ではなく、むしろ包括的な「または」を意味することを意図している。すなわち、別段に規定されていない限り、または、文脈から明らかでない限り、たとえば、「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  モビリティ完了段階
1100  例示的な動作
1200  例示的な動作
1300  多重接続性対応ワイヤレスデバイス、ワイヤレスデバイス
1304  プロセッサ
1306  メモリ
1310  無線
1312  無線
1314  トランシーバ
1316  アンテナ
1318  信号検出器
1320  デジタル信号プロセッサ(DSP)
1400  基地局
1404  プロセッサ
1406  メモリ
1410  無線
1412  インターフェース
1414  トランシーバ
1416  アンテナ
1418  信号検出器
1420  デジタル信号プロセッサ(DSP)
【図１】
2019083582.tif 000003
【図２Ａ】
2019083582.tif 000004
【図２Ｂ】
2019083582.tif 000005
【図３】
2019083582.tif 000006
【図４】
2019083582.tif 000007
【図５】
2019083582.tif 000008
【図６】
2019083582.tif 000009
【図７】
2019083582.tif 000010
【図８】
2019083582.tif 000011
【図９Ａ】
2019083582.tif 000012
【図９Ｂ】
2019083582.tif 000013
【図１０Ａ】
2019083582.tif 000014
【図１０Ｂ】
2019083582.tif 000015
【図１０Ｃ】
2019083582.tif 000016
【図１０Ｄ】
2019083582.tif 000017
【図１１】
2019083582.tif 000018
【図１２】
2019083582.tif 000019
【図１３】
2019083582.tif 000020
【図１４】
2019083582.tif 000021
【手続補正書】
【提出日】平成31年2月27日(2019.2.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データフローのステータスを報告する方法であって、
パケットデータコンバージェンスプロトコルレイヤまたは無線リンク制御レイヤにおいて、分割されたパケットを有するプロトコルスタック内のレイヤを介して、複数の接続上の複数の基地局から送られる複製パケットを有するデータフローを示す構成を受信するステップと、
前記複数の接続の少なくとも1つの上で前記複数の基地局のうちの1つから前記データフロー内のパケットを受信するステップと、
前記パケットが複製パケットを有すると決定するステップと、
前記パケットの複製を破棄することを前記複数の基地局の少なくとも1つに示すステータスを、前記複数の基地局の前記少なくとも1つに、報告するステップと
を備える、方法。
【請求項２】
ステータスを報告するステップが、パケットデータコンバージェンスプロトコル(PDCP)ステータス報告を送るステップ、または無線リンク制御(RLC)ステータス報告を送るステップを備える、請求項1に記載の方法。
【請求項３】
ステータスを報告するステップが、前記複数の接続の各接続上で前記複数の各基地局に同じステータスを送るステップを備える、
請求項1に記載の方法。
【請求項４】
前記受信された構成が、前記データフローが2つ以上の接続上で送られていることを示すベアラタイプを備える、
請求項1に記載の方法。
【請求項５】
前記ベアラタイプが、重複配信ベアラである、
請求項4に記載の方法。
【請求項６】
前記データフローの少なくとも1つのサービス要件に基づいて、前記データフローが2つ以上の接続上で送られることを要求する指示を送るステップをさらに備える、
請求項1に記載の方法。
【請求項７】
データフローを送信する方法であって、
パケットデータコンバージェンスプロトコルレイヤまたは無線リンク制御レイヤにおいて、分割されたパケットを有するプロトコルスタック内のレイヤを介して、複数の接続上に送られる複製パケットを有するデータフローを決定するステップと、
前記複数の接続上の複数の基地局から前記データフローが送られていることを示す構成を、ユーザ機器に送信するステップと、
前記複数の基地局のうちの第1の基地局から、前記複数の接続のうちの少なくとも1つの接続上で、前記ユーザ機器にパケットを送信するステップと、
前記複数の基地局のうちの第2の基地局に、前記パケットを転送するステップと、
前記パケットの複製を破棄することを示すステータス報告を受信するステップと
を備える、方法。
【請求項８】
前記ステータス報告を前記第2の基地局に転送するステップをさらに備える、
請求項7に記載の方法。
【請求項９】
前記ステータス報告は、前記パケットが前記複数の接続のうちの第1の接続上で受信されたことを示し、前記方法が、前記複数の接続のうちの他の接続上で前記パケットを転送することをやめるステップをさらに備える、
請求項8に記載の方法。
【請求項１０】
前記データフローを2つ以上の接続上で送られるように構成する要求を送信するステップをさらに備える、
請求項7に記載の方法。
【請求項１１】
前記決定するステップが、前記データフローが2つ以上の接続上で送られるようにする別の構成を受信するステップを備える、
請求項7に記載の方法。
【請求項１２】
前記決定するステップが、前記データフローのサービス要件の少なくとも1つに基づく、
請求項7に記載の方法。
【請求項１３】
データフローのステータスを報告する装置であって、
パケットデータコンバージェンスプロトコルレイヤまたは無線リンク制御レイヤにおいて、分割されたパケットを有するプロトコルスタック内のレイヤを介して、複数の接続上の複数の基地局から送られる複製パケットを有するデータフローを示す構成を受信するための手段と、
前記複数の接続の少なくとも1つの上で前記複数の基地局のうちの1つから前記データフロー内のパケットを受信するための手段と、
前記パケットが複製パケットを有すると決定するための手段と、
前記パケットの複製を破棄することを前記複数の基地局の少なくとも1つに示すステータスを、前記複数の基地局の前記少なくとも1つに、報告するための手段と
を備える、装置。
【請求項１４】
ステータスを報告するための手段が、パケットデータコンバージェンスプロトコル(PDCP)ステータス報告を送るための手段、または無線リンク制御(RLC)ステータス報告を送るための手段を備える、請求項13に記載の装置。
【請求項１５】
ステータスを報告するための手段が、前記複数の接続の各接続上で前記複数の各基地局に同じステータスを送るための手段を備える、
請求項13に記載の装置。
【請求項１６】
前記受信された構成が、前記データフローが2つ以上の接続上で送られていることを示すベアラタイプを備える、
請求項13に記載の装置。
【請求項１７】
前記ベアラタイプが、重複配信ベアラである、
請求項16に記載の装置。
【請求項１８】
前記データフローの少なくとも1つのサービス要件に基づいて、前記データフローが2つ以上の接続上で送られることを要求する指示を送るための手段をさらに備える、
請求項13に記載の装置。
【請求項１９】
データフローを送信する装置であって、
パケットデータコンバージェンスプロトコルレイヤまたは無線リンク制御レイヤにおいて、分割されたパケットを有するプロトコルスタック内のレイヤを介して、複数の接続上に送られる複製パケットを有するデータフローを決定するための手段と、
前記複数の接続上の複数の基地局から前記データフローが送られていることを示す構成を、ユーザ機器に送信するための手段と、
前記複数の基地局のうちの第1の基地局から、前記複数の接続のうちの少なくとも1つの接続上で、前記ユーザ機器にパケットを送信するための手段と、
前記複数の基地局のうちの第2の基地局に、前記パケットを転送するための手段と、
前記パケットの複製を破棄することを示すステータス報告を受信するための手段と
を備える、装置。
【請求項２０】
前記ステータス報告を前記第2の基地局に転送するための手段をさらに備える、
請求項19に記載の装置。
【請求項２１】
前記ステータス報告は、前記パケットが前記複数の接続のうちの第1の接続上で受信されたことを示し、前記装置が、前記複数の接続のうちの他の接続上で前記パケットを転送することをやめるための手段をさらに備える、
請求項20に記載の装置。
【請求項２２】
前記データフローを2つ以上の接続上で送られるように構成する要求を送信するための手段をさらに備える、
請求項19に記載の装置。
【請求項２３】
前記決定するための手段が、前記データフローが2つ以上の接続上で送られるようにする別の構成を受信するための手段を備える、
請求項19に記載の装置。
【請求項２４】
前記決定するための手段が、前記データフローのサービス要件の少なくとも1つに基づく、
請求項19に記載の装置。
【請求項２５】
ユーザ機器（UE）において、実行可能であるワイヤレス通信の方法であって、
パケットデータコンバージェンスプロトコルレイヤまたは無線リンク制御レイヤにおいて、分割されたパケットを有するプロトコルスタック内のレイヤを介して、複数のセルから送られる複製パケットを有するデータフローを示す構成を受信するステップと、
前記複数のセルのうちの1つから前記データフロー内のパケットを受信するステップと、
前記パケットが複製パケットを有すると決定するステップと、
前記パケットの複製を破棄することを前記複数のセルの少なくとも1つに示すステータスを、前記複数のセルの前記少なくとも1つに、報告するステップと
を備える、方法。
【請求項２６】
ステータスを報告するステップが、パケットデータコンバージェンスプロトコル(PDCP)ステータス報告を送るステップ、または無線リンク制御(RLC)ステータス報告を送るステップを備える、請求項25に記載の方法。
【請求項２７】
ステータスを報告するステップが、前記複数の各セルに同じステータスを送るステップを備える、
請求項25に記載の方法。
【請求項２８】
前記受信された構成が、前記データフローが2つ以上の接続上で送られていることを示すベアラタイプを備える、
請求項25に記載の方法。
【請求項２９】
前記ベアラタイプが、重複配信ベアラである、
請求項28に記載の方法。
【請求項３０】
前記データフローの少なくとも1つのサービス要件に基づいて、前記データフローが前記複数のセルから送られることを要求する指示を送るステップをさらに備える、
請求項25に記載の方法。
【請求項３１】
ユーザ機器（UE）において、実行可能であるワイヤレス通信の方法であって、
パケットデータコンバージェンスプロトコルレイヤまたは無線リンク制御レイヤにおいて、分割されたパケットを有するプロトコルスタック内のレイヤを介して、複数のセルに送られる複製パケットを有するデータフローを決定するステップと、
前記複数のセルのうちの1つに前記複製パケットを送信するステップと、
前記複製パケットの少なくとも1つを破棄することを示すステータス報告を受信するステップと、
前記ステータス報告に基づいて、前記複製パケットのうちの前記少なくとも1つの送信をやめるステップと
を備える、方法。
【請求項３２】
前記ステータス報告が、パケットデータコンバージェンスプロトコル(PDCP)ステータス報告、または無線リンク制御(RLC)ステータス報告を備える、
請求項31に記載の方法。
【請求項３３】
前記データフローが前記複数のセルに送られていることを示すベアラタイプを備える構成を受信するステップをさらに備える、
請求項31に記載の方法。
【請求項３４】
前記ベアラタイプが、重複配信ベアラである、
請求項33に記載の方法。
【請求項３５】
前記ステータス報告を受信するステップは、前記複数の各セルから、同じステータス報告を受信するステップを備える、
請求項31に記載の方法。
【外国語明細書】
2019083582000001.pdf