知財求人 - 知財ポータルサイト「IP Force」
▶ テレフオンアクチーボラゲット エル エム エリクソン（パブル）の特許一覧
特表2024-529881統合および無線アクセスバックホールのための一時的かつ適応的な負荷分散のための方法およびシステム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-08-14
(54)【発明の名称】統合および無線アクセスバックホールのための一時的かつ適応的な負荷分散のための方法およびシステム
(51)【国際特許分類】
H04W 28/086 20230101AFI20240806BHJP
H04W 92/20 20090101ALI20240806BHJP
H04W 72/27 20230101ALI20240806BHJP
H04W 16/26 20090101ALI20240806BHJP
【ＦＩ】
H04W28/086
H04W92/20
H04W72/27
H04W16/26
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024501917
(86)(22)【出願日】2022-07-13
(85)【翻訳文提出日】2024-03-08
(86)【国際出願番号】 EP2022069688
(87)【国際公開番号】W WO2023285570
(87)【国際公開日】2023-01-19
(31)【優先権主張番号】63/221,207
(32)【優先日】2021-07-13
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．３ＧＰＰ
２．ＢＬＵＥＴＯＯＴＨ
３．ＺＩＧＢＥＥ
４．ＬｏＲａ
５．ＳＩＧＦＯＸ
(71)【出願人】
【識別番号】598036300
【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）
(74)【代理人】
【識別番号】110003281
【氏名又は名称】弁理士法人大塚国際特許事務所
(72)【発明者】
【氏名】バラク， フィリップ
(72)【発明者】
【氏名】プラダス， ホセ， ルイス
(72)【発明者】
【氏名】ムハンマド， アジマル
(72)【発明者】
【氏名】シュリーヴァスタヴ， リテシュ
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA21
5K067DD11
5K067EE02
5K067EE06
5K067EE10
5K067EE34
(57)【要約】
統合アクセスおよびバックホール（IAB）ネットワークにおける第1のセントラルユニット（CU1）（20）による方法（700）であり、第1のメッセージを第2のCU（CU2）（30）に送信すること（702）、またはCU2から第1のメッセージを受信することを含む。 第1のメッセージは、オフロードされたトラフィックの一部がCU1に戻されるべきであることを示す情報を含み、オフロードされたトラフィックは以前にCU1からCU2にオフロードされたものである。
【選択図】図19
【選択図】図19
【特許請求の範囲】
【請求項1】
統合アクセスおよびバックホール(IAB)ネットワークにおける第1のセントラルユニット(CU1)による方法であって、第1のメッセージを第2のCU(CU2)に送信すること、または前記CU2から第1のメッセージを受信すること、を有し、
前記第1のメッセージは、オフロードされたトラフィックの一部が前記CU1に戻されるべきであることを示す情報を有し、
前記オフロードされたトラフィックは、以前に前記CU1から前記CU2にオフロードされたものである、方法。
【請求項2】
請求項1に記載の方法であって、前記第1のメッセージを送信する前に、前記オフロードされたトラフィックを前記最初のCU1から前記CU2にオフロードすることを有する、方法。
【請求項3】
前記オフロードされたトラフィックは、移行IABノードで終端される、請求項2に記載の方法。
【請求項4】
以前に前記CU1から前記CU2にオフロードされた前記オフロードされたトラフィックの前記一部を受信することをさらに有する、前記方法。
【請求項5】
請求項1から4のいずれか1項に記載の方法であって、前記CU1はF1終端ノードを有し、
前記CU2はF1非終端ノードを有する、方法。
【請求項6】
前記第1のメッセージは、前記オフロードされたトラフィックの前記CU1に戻される前記一部に関連するトラフィック量を示す、請求項1から5のいずれか1項に記載の方法。
【請求項7】
オフロードされたトラフィックの前記CU1に戻される前記一部を処理する能力を前記CU1が有することを判定することをさらに有する、請求項１から６のいずれか1項に記載の方法。
【請求項8】
請求項1から7のいずれか1項に記載の方法であって、条件が満たされたと判定することをさらに含み、前記第1のメッセージは前記条件が満たされたと判定されたことに応答して前記CU2に送信され、前記条件は、タイマーが満了したと判定したこと、
前記ターゲットドナーノードでのトラフィック負荷の増加を特定したこと、
前記ターゲットドナーノードでのトラフィックが閾値を超えて増加したことを特定したこと、
前記ソースドナーノードでのトラフィック負荷の減少を特定したこと、および
前記ソースドナーノードのトラフィックが閾値を超えて減少したことを特定したこと、の1つ以上を含む、方法。
【請求項9】
前記CU2から、前記CU2によって解放されるべき1つ以上のリソースを示す第2のメッセージを受信することをさらに含む、請求項7から8のいずれか1項に記載の方法。
【請求項10】
請求項1から6のいずれか1項に記載の方法であって、前記CU2から前記第1のメッセージを受信することが、オフロードされたトラフィックの前記一部が前記CU1に戻されることを開始し、前記方法が、前記オフロードされたトラフィックの前記一部が前記CU1に戻されていることを判定する第2のメッセージを前記CU2に送信することを有する、方法。
【請求項11】
前記第1のメッセージは、前記オフロードされたトラフィックの前記CU1に戻されるべき前記一部に関連する少なくとも1つの許可されたリソースを示す、請求項1から10のいずれか1項に記載の方法。
【請求項12】
請求項11に記載の方法であって、前記少なくとも1つの許可されたリソースは、ダウンリンクリソース、および／または
アップリンクリソース、の少なくとも一方を含む、方法。
【請求項13】
前記オフロードされたトラフィックの前記CU1に戻されるべき前記一部に関連する情報を、少なくとも1つのIABノードに送信することをさらに含む、請求項1から12のいずれか1項に記載の方法。
【請求項14】
前記少なくとも1つのIABノードに送信される前記情報がルーティングテーブルを含む、請求項13に記載の方法。
【請求項15】
統合アクセスおよびバックホール(IAB)ネットワークにおける第2のセントラルユニット(CU2)による方法であって、第1のメッセージをCU1に送信すること、または前記CU1から第1のメッセージを受信すること、を有し、
前記第1のメッセージは、オフロードされたトラフィックの一部が前記CU1に戻されるべきであることを示す情報を有し、
前記オフロードされたトラフィックは、以前に前記CU1から前記CU2にオフロードされたものである、方法。
【請求項16】
前記第1のメッセージを送信または前記第1のメッセージを受信する前に、前記オフロードされたトラフィックを受信することを有する、請求項15に記載の方法。
【請求項17】
前記オフロードされたトラフィックは、移行IABノードで終端される、請求項16に記載の方法。
【請求項18】
請求項15から17のいずれか1項に記載の方法であって、前記CU1はF1終端ノードを有し、
前記CU2はF1非終端ノードを有する、方法。
【請求項19】
前記第1のメッセージは、前記オフロードされたトラフィックの前記CU1に戻されるべき前記一部に関連するトラフィック量を示す、請求項15から18のいずれか1項に記載の方法。
【請求項20】
前記オフロードされたトラフィックの前記CU1に戻されるべき前記一部を処理する能力を前記CU2が有しないことを判定することをさらに有する、請求項15から19のいずれか1項に記載の方法。
【請求項21】
請求項1から7のいずれか1項に記載の方法であって、条件が満たされたと判定することをさらに含み、前記第1のメッセージは前記条件が満たされたと判定されたことに応答して前記CU1に送信され、前記条件は、タイマーが満了したと判定したこと、
前記ターゲットドナーノードでのトラフィック負荷の増加を特定したこと、
前記ターゲットドナーノードでのトラフィックが閾値を超えて増加したことを特定したこと、
前記ソースドナーノードでのトラフィック負荷の減少を特定したこと、および
前記ソースドナーノードのトラフィックが閾値を超えて減少したことを特定したこと、の1つ以上を含む、方法。
【請求項22】
前記CU1から、前記CU2によって解放されるべき1つ以上のリソースを示す第2のメッセージを受信することをさらに含む、請求項20から21のいずれか1項に記載の方法。
【請求項23】
請求項15から22のいずれか1項に記載の方法であって、前記CU1から前記第1のメッセージを受信することが、オフロードされたトラフィックの前記一部が前記CU1に戻されることを開始し、前記方法が、前記オフロードされたトラフィックの前記一部が前記CU1に戻されていることを判定する第2のメッセージを前記CU1に送信することを有する、方法。
【請求項24】
前記第1のメッセージは、前記オフロードされたトラフィックの前記CU1に戻されるべき前記一部に関連する少なくとも1つの許可されたリソースを示す、請求項15から23のいずれか1項に記載の方法。
【請求項25】
請求項24に記載の方法であって、前記少なくとも1つの許可されたリソースは、ダウンリンクリソース、および／または
アップリンクリソース、の少なくとも一方を含む、方法。
【請求項26】
前記オフロードされたトラフィックの前記CU1に戻されるべき前記一部に関連する情報を、少なくとも1つのIABノードに送信することをさらに含む、請求項15から25のいずれか1項に記載の方法。
【請求項27】
前記少なくとも1つのIABノードに送信される前記情報がルーティングテーブルを含む、請求項26に記載の方法。
【請求項28】
統合アクセスおよびバックホール(IAB)ネットワークにおける第1のセントラルユニット(CU1)であって、第1のメッセージを第2のCU(CU2)に送信すること、または前記CU2から第1のメッセージを受信するように構成され、
前記第1のメッセージは、オフロードされたトラフィックの一部が前記CU1に戻されるべきであることを示す情報を有し、
前記オフロードされたトラフィックは、以前に前記CU1から前記CU2にオフロードされたものである、CU1。
【請求項29】
請求項2から14に記載の方法のいずれかを実行するようにさらに構成された、請求項28に記載のソースドナーノード。
【請求項30】
統合アクセスおよびバックホール(IAB)ネットワークにおける第2のセントラルユニット(CU2)であって、第1のメッセージをCU1に送信する、または前記CU1から第1のメッセージを受信する、ように構成され、
前記第1のメッセージは、オフロードされたトラフィックの一部が前記CU1に戻されるべきであることを示す情報を有し、
前記オフロードされたトラフィックは、以前に前記CU1から前記CU2にオフロードされたものである、CU2。
【請求項31】
請求項16から27に記載の方法のいずれかを実行するようにさらに構成された、請求項30に記載のターゲットドナーノード。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、概して無線通信に関し、より詳細には、統合および無線アクセスバックホールのための一時的かつ適応的な負荷分散のためのシステムおよび方法に関する。
【背景技術】
【0002】
第3世代パートナーシッププロジェクト（3GPP）は、ニューラジオ（IAB）Rel-16で統合アクセスおよび無線アクセスバックホールを完成させ、現在IAB Rel-17の標準化を進めている。
【0003】
ニューラジオ（NR）が短距離ミリ波スペクトルを用いることで、マルチホップバックホーリングによる高密度配備が必要となる。 しかし、すべての基地局に光ファイバを敷設するのはコストがかかりすぎ、時には不可能な場合もある（歴史的な場所など）。IABの主な原理は、バックホールに（ファイバの代わりに）無線リンクを使用することで、トランスポートネットワークを高密度化することなく、セルを柔軟かつ高密度に配置できるようにすることである。IABのユースケースシナリオには、カバレッジの拡大、大量のスモールセルの配置、固定無線アクセス（FWA）（住宅やオフィスビルへのアクセスなど）が含まれる。ミリ波スペクトラムでNRに利用できる帯域幅が広いため、アクセスリンクに使用するスペクトラムを制限することなく、セルフバックホーリングの機会が得られる。その上、NRが本質的に有するマルチビームとMIMO（Multiple Input Multiple Output）のサポートにより、バックホールとアクセスリンクとのクロスリンク干渉が低減され、高密度化が可能になる。
【0004】
IABの研究項目の段階では、NRのセントラルユニット（CU）/分散ユニット（DU）分離アーキテクチャを活用するソリューションを採用することが合意されている。3GPP TR 38.874を参照されたい。 IABノードは、親ノードとの通信に使用されるモバイルターミネーション（MT）も有する。
【0005】
IABの仕様は、NRで規定されている既存の機能やインターフェースを再利用するように努めている。特に、MT、gNodeB-分散ユニット（gNB-DU）、gNodeB-セントラルユニット（gNB-CU）、ユーザプレーン機能（UPF）、アプリケーション管理機能（AMF）、およびセッション管理機能（SMF）、ならびに対応するインタフェースNR Uu（MTとgNBの間）、F1、NG、X2、およびN4が、IABアーキテクチャのベースラインとして使用されている。IABをサポートするためのこれらの機能およびインターフェイスの変更または拡張については、以下においてアーキテクチャの議論の中で説明される。マルチホップ転送のような追加機能は、IABの動作を理解するために必要であり、ある側面では標準化が必要となりうるため、アーキテクチャの議論に含める。
【0006】
MT機能はIABノードのコンポーネントとして規定されている。この検討では、MTはIABノードに常駐し、IABドナーまたは他のIABノードに向けてバックホールUuインタフェースの無線インタフェース層を終端する機能と呼ばれる。
【0007】
図1は、IABネットワークのハイレベルアーキテクチャ図である。 具体的には、図1は、3GPP TR 38.874で議論されている、スタンドアロンモードにおけるIABのリファレンス図である。 IABネットワークは、1つのIABドナーと複数のIABノードを含む。IABドナーは、gNodeB-DU（gNB-DU）、gNodeB-CPU制御プレーン（gNB-CPU-CP）、gNodeB-CPUユーザプレーン（gNB-CPU-UP）、および潜在的に他の機能などの一連の機能から構成される1つの論理ノードとして扱われます。配置において、IABドナーはこれらの機能に従って分割することができ、3GPP NG-RANアーキテクチャで認められているように、すべて同一位置に、あるいは非同一位置に配置することができる。このような分離が用いる場合、IABに関連する局面が生じる可能性がある。また、現在IABドナーが担っている機能の一部は、IAB固有のタスクではないことが明らかになった場合、いずれドナーの外に移動されうる。
【0008】
図2は、Rel-16におけるIABのベースラインユーザプレーン（UP）プロトコルスタックを示す図であり、図3は、Rel-16におけるIABのベースラインコントロールプレーン（CP）プロトコルスタックを示す図である。
【0009】
上述のように、選択されたプロトコルスタックは、Rel-15の現在のCU-DU分割仕様を再利用し、フルユーザプレーンF1-U（GTP-U/UDP/IP）は（通常のDUのように）IABノードで終端され、フルコントロールプレーンF1-C（F1-AP/SCTP/IP）も（通常のDUのように）IABノードで終端される。上述のケースでは、UPとCPの両方のトラフィックを保護するために、ネットワークドメインセキュリティ（NDS）が採用されている（UPの場合はIPsec、CPの場合はデータグラムトランスポートレイヤーセキュリティ（DTLS））。DTLSの代わりにIPsecをCP保護に使用することもできる（この場合、DTLSレイヤーは使用されない）。
【0010】
バックホール適応プロトコル（BAP）と呼ばれる新しいプロトコルレイヤがIABノードとIABドナーに導入され、適切なダウンストリーム／アップストリームノードへのパケットのルーティングに使用されるほか、ベアラのエンドツーエンドのサービス品質（QoS）要件を満たすために、ユーザー機器（UE）のベアラデータを適切なバックホール無線リンク制御（RLC）チャネルにマッピングする（さらに、中間IABノードの入方向／出方向のバックホールRLCチャネル間にもマッピングする）。したがって、BAPレイヤは、例えば、親/子IABノードからの入方向BH RLCチャネルを、子/親IABノードに向かうリンクの出方向BH RLCチャネルにマッピングするなど、バックホール（BH）RLCチャネルの処理を担当する。特に、複数のデータ無線ベアラ（DRB）と、ネットワーク内の異なるIABノードに接続される可能性のある異なるユーザ機器（UE）用のエンドユーザトラフィックを1つのBH RLCチャネルが伝送しうる。
【0011】
3GPPでは、BH RLCチャネルの2つの可能な構成が提供されている。 第1の構成は、BH RLCチャネルと特定のユーザーのDRBとの間の１：１のマッピングを含む。 第2の構成は、異なるUEに関連する可能性のあるN個のDRBが1つのBH RLCチャネルにマッピングされるN:：１のベアラマッピングを含む。最初のケースは、BH RLCチャネルのQoS要求と関連するDRBのQoS要求の間に1:1のマッピングが存在するため、IABノードのスケジューラで簡単に処理できる。しかし、このような1:1構成は、IABノードが多数のUE/DRBにサービスを提供している場合にスケーラブルにするのが容易でない。一方、N:：1構成はより柔軟/スケーラブルではあるが、あるBH RLCチャネルが提供するDRB/UEの量は、別のBH RLCチャネルが提供するDRB/UEの量と異なる可能性があるため、さまざまな提供されるBH RLCチャネル間で公平性を確保することが難しくなる可能性がある。
【0012】
IABノード上でBAPサブレイヤはMT機能に1つのBAPエンティティを含むとともに、DU機能に別の、同一位置に配置されたBAPエンティティを含む。IABドナーDU上でBAPサブレイヤは1つのBAPエンティティのみを含む。各BAPエンティティは送信部と受信部とを有する。BAPエンティティの送信部は、バックホールリンクを介して、IABノードまたはIABドナーDUのBAPエンティティの対応する受信部を有する。
【0013】
図4は、BAPサブレイヤーの機能図の一例を示している。この図は、3GPP TS 38.300で規定されている無線インターフェースプロトコルアーキテクチャに基づいているが、この機能図は実装を制限するものではない。図4の例では、BAPエンティティ上の受信部は、BAPプロトコルデータユニット（PDU）を、同位置に配置されたBAPエンティティ上の送信部に配信する。あるいは、受信部は、BAPサービスデータユニット（SDU）を同位置に配置された送信部に配信してもよい。BAP SDUを引き渡すとき、受信部はBAPヘッダを削除し、送信部は削除前のBAP PDUヘッダに含まれていたのと同じBAPルーティングIDをBAPヘッダに追加する。したがって、この方法でBAP SDUを引き渡すことは、実装上、BAP PDUを渡すことと機能的に等価である。
【0014】
以下のサービスは、BAPサブレイヤから上位レイヤに提供される。
- データ転送、
- データ転送、
【0015】
BAPサブレイヤは、RLCエンティティごとに下位レイヤからの以下のサービスを期待する（詳細な説明は 3GPP TS 38.322 を参照されたい）：
- 承認済み(acknowledged)データ転送サービス、
- 未承認データ転送サービス。
- 承認済み(acknowledged)データ転送サービス、
- 未承認データ転送サービス。
【0016】
BAPサブレイヤは以下の機能をサポートする：
- データ転送、
- 上位レイヤからのパケットのためのBAP宛先とパスの決定、
- 次ホップにルーティングされるパケットの出方向BH RLCチャネルの決定、
- 次ホップへのパケットルーティング、
- 上位レイヤに配信されるトラフィックと、出方向リンクに配信されるトラフィックとの識別、
- フロー制御のフィードバックとポーリングシグナリング。
- データ転送、
- 上位レイヤからのパケットのためのBAP宛先とパスの決定、
- 次ホップにルーティングされるパケットの出方向BH RLCチャネルの決定、
- 次ホップへのパケットルーティング、
- 上位レイヤに配信されるトラフィックと、出方向リンクに配信されるトラフィックとの識別、
- フロー制御のフィードバックとポーリングシグナリング。
【0017】
したがって、BAPレイヤは受信パケットをどのようにルーティングするかを決定するために重要である。ダウンストリームについて、これはパケットが最終的な宛先に到達したかどうかを判断することを意味する。その場合、パケットはアクセスノードとしてこのIABノードに接続されているUEに送信されるか、または正しいパスの別のIABノードに転送される。最初のケースでは、BAPレイヤはIABノード内の上位レイヤにパケットを引き渡す。この上位レイヤは、パケットを様々なQoSフローにマッピングし、パケットに含まれるDRBをマッピングする。2番目のケースでは、代わりに、BAPレイヤは、BAP宛先、パスID、および入方向BH RLCチャネルに基づいて、適切な出方向BH RLCチャネルを決定する。上述した内容は、最終的な宛先が常に特定のドナーDU/CUであることを除き、アップストリームに対しても当てはまる。上述のタスクを達成するため、IABノードのBAPレイヤには、特定のBAP宛先およびパケットのパスに応じて異なりうる入方向RLCチャネルと出方向RLCチャネルとをマッピングするルーティングテーブルを設定する必要がある。したがって、BAPレイヤがパケットの転送先を決定できるように、BAP宛先とパス識別子（ID）とがBAPパケットのヘッダに含まれる。
【0018】
さらに、BAPレイヤはホップバイホップのフロー制御においても重要な役割を担っている。特に、子ノードは、親ノードが子ノードに向かうトラフィックを調整できるよう、子ノードでローカルに発生する可能性のある輻輳について親ノードに通知することができる。親ノードは、子ノードが別の親ノードとの接続を再確立できるよう、親ノードが無線リンク障害（RLF）の問題を受けた場合に子ノードに通知するためにもBAPレイヤを用いることもできる。
【0019】
IABネットワークにおけるトポロジ適応は、無線条件の変化、サービングCUの負荷の変化、無線リンクの障害など、さまざまな理由で必要となりうる。IABトポロジ適応の結果として、IABノードが新しい親（同じCUまたは異なるCUによって制御されうる）に移行（すなわちハンドオーバ）されるか、またはそのようなIABノードによって現在サービスされているトラフィックの一部が新しいルート（同じCUまたは異なるCUによって制御されうる）を介してオフロードされる可能性がある。そのIABノードの新しい親が同じCUまたは異なるCUの制御下にある場合、移行(migration)はそれぞれドナー内移行およびドナー間移行である（本明細書では、CU内移行およびCU間移行とも呼ぶ）。
【0020】
図5は、IABトポロジ適応のための、いくつかの異なる可能性のあるIABノード移行（すなわちトポロジ適応）シナリオの例を示す。 シナリオは複雑さの順序で並んでいる。
【0021】
CU内のケース（A）では、IABノード（e）は、サービスを提供しているUEとともに、同じドナーDU（1）の制御下にある新しい親ノード（IABノード（b））に移される。DU内移行を成功させるには、新しい親ノード（IABノード（b））のDU内でIABノード（e）のMTのUE コンテキストセットアップを確立し、IABノード（e）までのパス中のIABノードのルーティングテーブルを更新し、新しいパスにリソースを割り当てる必要がある。IABノード(e)のIPアドレスは変更されないが、ドナーCU(1)とIABノード(e)のDU間のF1-Uトンネル/接続は、IABノード(b)を経由してリダイレクトされる。
【0022】
CU内のケース(B)の手続き要件/複雑さはケース(A)と同じである。また、新しいIABドナーDU（すなわちDU2）は同じL2ネットワークに接続されているため、IABノード（e）は新しいドナーDUの下で同じIPアドレスを使用することができる。しかし、新しいドナーDU（すなわちDU2）は、ARP（Address Resolution Protocol）などの仕組みを用い、IABノード（e）に対して同じIPアドレスを取得／維持するために、IABノード（e）のL2アドレスを用いてネットワークに通知する必要がある。
【0023】
CU内のケース(C)は、IABノード(e)に新しいIPアドレスを割り当てる必要があるため、ケース(A)よりも複雑である。ドナーCU(1)とIABノード(e)DUとの間のF1-Uトンネル/接続を保護するためにIPsecが用いられる場合、ドナーCU(1)とセキュリティゲートウェイ(SeGW)間のパスセグメントに既存のIPアドレスを使用し、SeGWとIABノード(e)DUとの間のIPsecトンネルに新しいIPアドレスを使用することが可能かもしれない。
【0024】
CU間ケース（D）は、手続き上の要件が最も複雑なケースであり、3GPP Rel-16の範囲を超える新しい仕様手続き（RRC、F1AP、XnAP、Ngシグナリングの強化など）が必要になりうる。
【0025】
3GPP Rel-16仕様では、CU内移行の手順のみが考慮されている。CU間移行では、IABノード動作がターゲットCUで継続可能であり、QoSが低下しないよう、IABノードのコンテキストとそのトラフィックをターゲットCUに移行するためにソースCUとターゲットCUの間で新しいシグナリング手順が必要になる。CU間移行は、3GPP Rel17において規定されるであろう。
【0026】
CU内トポロジ適応の間、ソースとターゲットの両方の親ノードは同じIAB-ドナーCUからサービスを受ける。ターゲット親ノードは、ソース親ノードとは異なるIABドナーDUを使用することができる。ソースパスはさらに、ターゲットパスと共通のノードを有しうる。
【0027】
図6は、ターゲット親ノードがソース親ノードとは異なるIAB-ドナーDUを使用する場合のトポロジ適応手順の一例を示す図である。 図示の通り、IABのCPU内トポロジ適応手順は以下を含む。
1. 移行するIAB-MTは、ソース親ノードIAB-DUにMeasurementReport メッセージを送信する。このレポートは、移行するIAB-MTが以前にIABドナーCUから受信した測定構成に基づいくものである。
2. ソース親ノードIAB-DUは、受信したMeasurementReportを搬送するために、UL RRCメッセージ転送(UL RRC MESSAGE TRANSFER)メッセージを IABドナーCUに送信する。
3. IABドナーCUは、移行するIAB-MTのUEコンテキストを生成し、1つ以上のベアラを設定するために、ターゲット親ノードIAB-DUにUEコンテキストセットアップ要求(UE CONTEXT SETUP REQUEST)メッセージを送信する。これらのベアラは、移行するIAB-MTが、自身のシグナリング、およびオプションとしてデータトラフィックのために使用することができる。
4. ターゲット親ノードIAB-DUは、UEコンテキストセットアップ応答(UE CONTEXT SETUP RESPONSE)メッセージでIABドナーCU に応答する。
5. IABドナーCUは、生成されたRRCReconfigurationメッセージを含むUEコンテキスト変更要求(UE CONTEXT MODIFICATION REQUEST)メッセージをソース親ノードIAB-DUに送信する。RRCReconfiguration メッセージは、ターゲットパス上のUL F1-C/非F1トラフィックマッピングのためのデフォルトのBH RLCチャネルとデフォルトのBAPルーティングID設定とを含む。追加のBH RLCチャンネルを含むこともできる。このステップは、ターゲットIABドナーDU経由でルーティング可能な(1つ以上の)TNLアドレスの割り当てを含む。ソースIABドナーDU経由でルーティング可能な(1以上の)TNLアドレスの代わりに、(1以上の)新しいTNLアドレスをRRCReconfiguration メッセージに含めてもよい。F1および非F1トラフィックを保護するためにIPsecトンネルモードが用いられる場合、割り当てられるTNLアドレスはアウターIPアドレスである。ソースパスとターゲットパスが同じIABドナーDUを使用する場合、TNLアドレスの置換は不要である。UEコンテキスト変更要求メッセージのTransmission Action Indicatorは、移行IABノードへのデータ送信を停止することを示す。
6. ソース親ノードIAB-DUは、受信したRRCReconfigurationメッセージを移行先のIAB-MTに転送する。
7. ソース親ノードIAB-DUは、UEコンテキスト変更応答(UE CONTEXT MODIFICATION RESPONSE)メッセージでIABドナーCUに応答する。
8. ターゲット親ノードIAB-DUでランダムアクセス手順が実行される。
9. 移行IAB-MTはRRCReconfigurationCompleteメッセージでターゲット親ノードIAB-DUに応答する。
10. ターゲット親ノードIAB-DUは、受信したRRCReconfigurationCompleteメッセージを搬送するために、UL RRCメッセージ転送(UL RRC MESSAGE TRANSFER)メッセージをIABドナーCUに送信する。また、移行しているIAB-MTからアップリンクパケットを送信することができ、このパケットはターゲット親ノードIABDUを経由してIABドナーCUに転送される。これらのULパケットは、IAB-MT自身のシグナリングに（およびオプションでデータトラフィックに）属する。
11. IABドナーCUは、ターゲット親IABノードとターゲットIABドナーDUとの間のターゲットパス上のBHRLCチャネルとBAPサブレイヤルーティングエントリを構成するとともに、移行IABノードのターゲットパスに対するターゲットIABドナーDU上のDLマッピングを構成する。これらの構成は、より早い段階、例えばステップ3の直後に行ってもよい。IABドナーCUは、RRCメッセージを用いて移行IAB-MTに追加のBH RLCチャネルを確立することができる。
12. F1-Cコネクションは移行IABノードの(1以上の)新しいTNLアドレスを使用するように切り替えられ、IABドナーCUは移行IABノードへの各GTPトンネルに関連付けられたUL BH情報を更新する。このステップは、各GTPトンネルに関連付けられたUL FTEIDとDL FTEIDについても更新しうる。すべてのF1-Uトンネルは、移行IABノードの(1つ以上の)新しいTNLアドレスを使用するように切り替えられる。このステップは、接続された複数のUEまたは子IAB-MTのF1-Uトンネルに対して更新されたUP構成を提供するために、E1および/またはF1インタフェースにおける非UE関連シグナリングを使用しうる。IABドナーCUは、非UPトラフィックに関連するUL BH情報も更新することができる。実装では、潜在的な競合状態を回避すること、すなわちUE関連手順と非UE関連手順とを用いて競合する設定が同時に実行されないことを保証する必要がある。
13. IABドナーCUは、UEコンテキスト解放コマンド(UL CONTEXT RELEASE COMMAND)メッセージをソース親ノードIAB-DUに送信する。
14. ソース親ノードIAB-DUは移行IAB-MTのコンテキストを解放し、UEコンテキスト解放完了(UL CONTEXT RELEASE COMPLETE)メッセージでIABドナーCUに応答する。
15. IABドナーCUは、ソース親IABノードとソースIABドナーDUとの間のソースパス上のBH RLCチャネルとBAPサブレイヤルーティングエントリとを解放する。
1. 移行するIAB-MTは、ソース親ノードIAB-DUにMeasurementReport メッセージを送信する。このレポートは、移行するIAB-MTが以前にIABドナーCUから受信した測定構成に基づいくものである。
2. ソース親ノードIAB-DUは、受信したMeasurementReportを搬送するために、UL RRCメッセージ転送(UL RRC MESSAGE TRANSFER)メッセージを IABドナーCUに送信する。
3. IABドナーCUは、移行するIAB-MTのUEコンテキストを生成し、1つ以上のベアラを設定するために、ターゲット親ノードIAB-DUにUEコンテキストセットアップ要求(UE CONTEXT SETUP REQUEST)メッセージを送信する。これらのベアラは、移行するIAB-MTが、自身のシグナリング、およびオプションとしてデータトラフィックのために使用することができる。
4. ターゲット親ノードIAB-DUは、UEコンテキストセットアップ応答(UE CONTEXT SETUP RESPONSE)メッセージでIABドナーCU に応答する。
5. IABドナーCUは、生成されたRRCReconfigurationメッセージを含むUEコンテキスト変更要求(UE CONTEXT MODIFICATION REQUEST)メッセージをソース親ノードIAB-DUに送信する。RRCReconfiguration メッセージは、ターゲットパス上のUL F1-C/非F1トラフィックマッピングのためのデフォルトのBH RLCチャネルとデフォルトのBAPルーティングID設定とを含む。追加のBH RLCチャンネルを含むこともできる。このステップは、ターゲットIABドナーDU経由でルーティング可能な(1つ以上の)TNLアドレスの割り当てを含む。ソースIABドナーDU経由でルーティング可能な(1以上の)TNLアドレスの代わりに、(1以上の)新しいTNLアドレスをRRCReconfiguration メッセージに含めてもよい。F1および非F1トラフィックを保護するためにIPsecトンネルモードが用いられる場合、割り当てられるTNLアドレスはアウターIPアドレスである。ソースパスとターゲットパスが同じIABドナーDUを使用する場合、TNLアドレスの置換は不要である。UEコンテキスト変更要求メッセージのTransmission Action Indicatorは、移行IABノードへのデータ送信を停止することを示す。
6. ソース親ノードIAB-DUは、受信したRRCReconfigurationメッセージを移行先のIAB-MTに転送する。
7. ソース親ノードIAB-DUは、UEコンテキスト変更応答(UE CONTEXT MODIFICATION RESPONSE)メッセージでIABドナーCUに応答する。
8. ターゲット親ノードIAB-DUでランダムアクセス手順が実行される。
9. 移行IAB-MTはRRCReconfigurationCompleteメッセージでターゲット親ノードIAB-DUに応答する。
10. ターゲット親ノードIAB-DUは、受信したRRCReconfigurationCompleteメッセージを搬送するために、UL RRCメッセージ転送(UL RRC MESSAGE TRANSFER)メッセージをIABドナーCUに送信する。また、移行しているIAB-MTからアップリンクパケットを送信することができ、このパケットはターゲット親ノードIABDUを経由してIABドナーCUに転送される。これらのULパケットは、IAB-MT自身のシグナリングに（およびオプションでデータトラフィックに）属する。
11. IABドナーCUは、ターゲット親IABノードとターゲットIABドナーDUとの間のターゲットパス上のBHRLCチャネルとBAPサブレイヤルーティングエントリを構成するとともに、移行IABノードのターゲットパスに対するターゲットIABドナーDU上のDLマッピングを構成する。これらの構成は、より早い段階、例えばステップ3の直後に行ってもよい。IABドナーCUは、RRCメッセージを用いて移行IAB-MTに追加のBH RLCチャネルを確立することができる。
12. F1-Cコネクションは移行IABノードの(1以上の)新しいTNLアドレスを使用するように切り替えられ、IABドナーCUは移行IABノードへの各GTPトンネルに関連付けられたUL BH情報を更新する。このステップは、各GTPトンネルに関連付けられたUL FTEIDとDL FTEIDについても更新しうる。すべてのF1-Uトンネルは、移行IABノードの(1つ以上の)新しいTNLアドレスを使用するように切り替えられる。このステップは、接続された複数のUEまたは子IAB-MTのF1-Uトンネルに対して更新されたUP構成を提供するために、E1および/またはF1インタフェースにおける非UE関連シグナリングを使用しうる。IABドナーCUは、非UPトラフィックに関連するUL BH情報も更新することができる。実装では、潜在的な競合状態を回避すること、すなわちUE関連手順と非UE関連手順とを用いて競合する設定が同時に実行されないことを保証する必要がある。
13. IABドナーCUは、UEコンテキスト解放コマンド(UL CONTEXT RELEASE COMMAND)メッセージをソース親ノードIAB-DUに送信する。
14. ソース親ノードIAB-DUは移行IAB-MTのコンテキストを解放し、UEコンテキスト解放完了(UL CONTEXT RELEASE COMPLETE)メッセージでIABドナーCUに応答する。
15. IABドナーCUは、ソース親IABノードとソースIABドナーDUとの間のソースパス上のBH RLCチャネルとBAPサブレイヤルーティングエントリとを解放する。
【0028】
注：ソースパスとターゲットパスとが共通のノードを有する場合、それらのノードのBH RLCチャネルとBAPサブレイヤルーティングエントリは、ステップ15で解放する必要はないかもしれない。
【0029】
ステップ11、12、15は、移行IABノードの子孫ノードに対しても、以下のように実行する必要がある。
・ IABドナーCUは、RRCReconfigurationメッセージにより、ターゲットIABドナーDU経由でルーティング可能な(1以上の)新しいTNLアドレスを子孫ノードに割り当てることができる。
・ 必要であれば、IABドナーCUは、RRCReconfigurationメッセージにより、ターゲットパス上のUL F1-C/非F1トラフィック用のデフォルトのBH RLCチャネルとデフォルトのBAPルーティングIDを含む新しいデフォルトのULマッピングを子孫ノードに提供することもできる。
・ 必要であれば、IABドナーCUは、ステップ11で移行IABノードについて説明したのと同じ方法で、子孫ノードのターゲットパス上のBH RLCチャネル、BAP-サブレイヤルーティングエントリ、および子孫ノード上のBH RLCチャネルマッピングを構成する。
・ 子孫ノードは、ステップ12で移行IABノードについて説明したのと同じ方法で、F1-C接続とF1-Uトンネルとを、新しいIAB-ドナーDUに固定された新しいTNLアドレスに切り替える。
実装に応じて、これらのステップは、移行IABノードのハンドオーバー後に実行することも、ハンドオーバーと並行して実行することもできる。
・ IABドナーCUは、RRCReconfigurationメッセージにより、ターゲットIABドナーDU経由でルーティング可能な(1以上の)新しいTNLアドレスを子孫ノードに割り当てることができる。
・ 必要であれば、IABドナーCUは、RRCReconfigurationメッセージにより、ターゲットパス上のUL F1-C/非F1トラフィック用のデフォルトのBH RLCチャネルとデフォルトのBAPルーティングIDを含む新しいデフォルトのULマッピングを子孫ノードに提供することもできる。
・ 必要であれば、IABドナーCUは、ステップ11で移行IABノードについて説明したのと同じ方法で、子孫ノードのターゲットパス上のBH RLCチャネル、BAP-サブレイヤルーティングエントリ、および子孫ノード上のBH RLCチャネルマッピングを構成する。
・ 子孫ノードは、ステップ12で移行IABノードについて説明したのと同じ方法で、F1-C接続とF1-Uトンネルとを、新しいIAB-ドナーDUに固定された新しいTNLアドレスに切り替える。
実装に応じて、これらのステップは、移行IABノードのハンドオーバー後に実行することも、ハンドオーバーと並行して実行することもできる。
【0030】
注： アップストリーム方向では、ソース親ノードとIABドナーCUとの間のインフライトパケットは、ターゲットパスが確立された後でも配信可能である。
【0031】
注： NRユーザプレーンプロトコル（3GPP TS 38.425）を用いた実装までは、ソースパスのインフライトダウンリンクデータを破棄することができる。
【0032】
注： IABドナーCUは、バックホールリンク上で送信に失敗したダウンリンクデータを、実装によって判断することができる。
【0033】
前述のとおり、3GPP Rel-16では、CU内トポロジ適応手順のみが標準化されている。IAB Rel-17作業項目でCU間移行が重要な機能であることを考慮すると、（IABノード移行による）サービス中断とシグナリング負荷を軽減するために、既存手順の強化が必要である。
【0034】
ドナー間トポロジ適応（別名、CU間移行）のユースケースには、次のようなものがある。
・ ドナー間の負荷分散考えられるシナリオの1つは、IABノードとその親ノードとの間のリンクが輻輳することである。この場合、当該IABノード（ここではトップレベルIABノードと呼ぶ）より下、および当該IABノードを含むネットワークブランチ全体のトラフィックは、別のルートを経由してトップレベルノードに到達するようにリダイレクトされうる。オフロードされたトラフィックの新しいルートが、トップレベルのノードに到達する前に、別のドナー下のネットワークを横断することを含む場合、シナリオはドナー間ルーティングである。オフロードされるトラフィックは、トップレベルIABノードおよびそのサービスを受けるUEで終端するトラフィック、またはトップレベルIABノードを通過し、その子孫IABノードおよびUEで終端するトラフィックの両方を含みうる。この場合、トップレベルIABノードのMT（すなわち、トップレベルIAB-MT）は、別のドナーへのRRC接続を確立することができ（したがって、古いドナーへのRRC接続を解放する）、このノードおよびその子孫デバイスに向かうトラフィックは、現在、新しいドナーを介して送信されるようになる。
・ ドナー間のRLF復旧自身の親リンクでRLFが発生したIABノードは、別のドナーの新しい親に向かってRRCの再確立を試みる（このノードはトップレベルIABノードとも呼ばれる）。3GPPの取り決めによれば、トップレベルノードの子孫IABノードおよびUEが新しいドナーに「従う」場合、トップレベルノードが別のドナーに接続した後も親子関係は保持される。
・ ドナー間の負荷分散考えられるシナリオの1つは、IABノードとその親ノードとの間のリンクが輻輳することである。この場合、当該IABノード（ここではトップレベルIABノードと呼ぶ）より下、および当該IABノードを含むネットワークブランチ全体のトラフィックは、別のルートを経由してトップレベルノードに到達するようにリダイレクトされうる。オフロードされたトラフィックの新しいルートが、トップレベルのノードに到達する前に、別のドナー下のネットワークを横断することを含む場合、シナリオはドナー間ルーティングである。オフロードされるトラフィックは、トップレベルIABノードおよびそのサービスを受けるUEで終端するトラフィック、またはトップレベルIABノードを通過し、その子孫IABノードおよびUEで終端するトラフィックの両方を含みうる。この場合、トップレベルIABノードのMT（すなわち、トップレベルIAB-MT）は、別のドナーへのRRC接続を確立することができ（したがって、古いドナーへのRRC接続を解放する）、このノードおよびその子孫デバイスに向かうトラフィックは、現在、新しいドナーを介して送信されるようになる。
・ ドナー間のRLF復旧自身の親リンクでRLFが発生したIABノードは、別のドナーの新しい親に向かってRRCの再確立を試みる（このノードはトップレベルIABノードとも呼ばれる）。3GPPの取り決めによれば、トップレベルノードの子孫IABノードおよびUEが新しいドナーに「従う」場合、トップレベルノードが別のドナーに接続した後も親子関係は保持される。
【0035】
上記のケースは、トップレベルノードのIAB-MTが一度に1つのドナーのみに接続できることを仮定したものである。しかし、Rel-17の作業では、以下の場合にトップレベルのIAB-MTが同時に2つのドナーに接続できる場合も考慮するであろう。
・ 負荷分散のために、1つのレグを経由してトップレベルIABノードに到達するトラフィックは、ノードが別のドナーに確立したもう1つのレグを経由してトップレベルIABノード（および潜在的にはその子孫ノード）に到達するようにオフロードされうる。
・ RLF復旧のために、壊れたレグを経由してトップレベルのIABノードに到達するトラフィックは、「良好な」レグを経由してそのノードに到達するよう、上述の別のドナーへ向けてリダイレクトされうる。
・ 負荷分散のために、1つのレグを経由してトップレベルIABノードに到達するトラフィックは、ノードが別のドナーに確立したもう1つのレグを経由してトップレベルIABノード（および潜在的にはその子孫ノード）に到達するようにオフロードされうる。
・ RLF復旧のために、壊れたレグを経由してトップレベルのIABノードに到達するトラフィックは、「良好な」レグを経由してそのノードに到達するよう、上述の別のドナーへ向けてリダイレクトされうる。
【0036】
ドナー間トポロジ適応に関して、3GPP Rel-17仕様では以下の2つの選択肢が認められるであろう。
・ プロキシベースのソリューション：トップレベルIAB-MTが一度に1つのドナーのみに接続できると仮定すると、トップレベルIAB-MTは新しいドナーに移行する一方で、同位置に配置されたIAB-DU、およびすべての子孫IAB-MT、IAB-DU、およびUEのF1接続とRRC接続は、ドナー間トポロジ適応後も古いドナーに固定されたままとなる。
・ プロキシベースのソリューションは、トップレベルのIAB-MTが同時に2つのドナーに接続されている場合にも適用可能である。この場合、最上位ノードを通過/で終端するトラフィックの一部または全部が、「他の」ドナーに向かうレグを経由してオフロードされる。
・ 完全移行(full migration)ベースのソリューション：トップレベルノードとその子孫デバイスおよびUEのすべてのF1およびRRCコネクションが新しいドナーに移される。
両ソリューションの詳細は、現在3GPPで議論中である。
・ プロキシベースのソリューション：トップレベルIAB-MTが一度に1つのドナーのみに接続できると仮定すると、トップレベルIAB-MTは新しいドナーに移行する一方で、同位置に配置されたIAB-DU、およびすべての子孫IAB-MT、IAB-DU、およびUEのF1接続とRRC接続は、ドナー間トポロジ適応後も古いドナーに固定されたままとなる。
・ プロキシベースのソリューションは、トップレベルのIAB-MTが同時に2つのドナーに接続されている場合にも適用可能である。この場合、最上位ノードを通過/で終端するトラフィックの一部または全部が、「他の」ドナーに向かうレグを経由してオフロードされる。
・ 完全移行(full migration)ベースのソリューション：トップレベルノードとその子孫デバイスおよびUEのすべてのF1およびRRCコネクションが新しいドナーに移される。
両ソリューションの詳細は、現在3GPPで議論中である。
【0037】
CU間移行のための完全移行ベースのソリューションの1つの問題は、IABノードEから新しいCU（すなわちCU(2)）への新しいF1コネクションが設定され、古いCU（すなわちCU(1)）への古いF1コネクションが解放されることである。
【0038】
F1コネクションの解放と再配置は、以下を引き起こすことで、すべてのUE（すなわちUEc、UEd、およびUEe）、および子孫のIABノード（ならびにそれらのサービスを受けるUE）に影響を与える。
1. トップレベルIABノード（すなわちIABノードE）がサービスを提供するUEおよびIABノードに対するサービスの中断。これらのUEは自身のコネクションの再確立またはハンドオーバ動作が必要となりうるためである（これらUEが同じIABノードの下に存在し続ける場合であっても、3GPPセキュリティ原則により、サービングCU/gNBが変更されるたびに（例えばハンドオーバ時や再確立時などに）、鍵のリフレッシュを実行することが義務付けられており、すなわち、各UEにreconfigurationWithSyncを用いたRRC再構成を送信する必要があるためである）。
2. 多数のUE、IAB-MT、およびIAB-DUが同時に再確立またはハンドオーバを実行する必要があるため、シグナリングストームが発生する。
1. トップレベルIABノード（すなわちIABノードE）がサービスを提供するUEおよびIABノードに対するサービスの中断。これらのUEは自身のコネクションの再確立またはハンドオーバ動作が必要となりうるためである（これらUEが同じIABノードの下に存在し続ける場合であっても、3GPPセキュリティ原則により、サービングCU/gNBが変更されるたびに（例えばハンドオーバ時や再確立時などに）、鍵のリフレッシュを実行することが義務付けられており、すなわち、各UEにreconfigurationWithSyncを用いたRRC再構成を送信する必要があるためである）。
2. 多数のUE、IAB-MT、およびIAB-DUが同時に再確立またはハンドオーバを実行する必要があるため、シグナリングストームが発生する。
【0039】
さらに、特定の実施形態によれば、最上位ノードの子孫ノードの再構成を回避することが好ましい場合がある。つまり、子孫ノードは、トラフィックがCU2経由でプロキシされているという事実を知らないことが望ましいということである。
【0040】
これらの問題に対処するため、トップレベルIABノードが直接または間接的にサービスを提供するUEまたはIABノードをハンドオーバすることなくCU間移行を行うプロキシベースの仕組みが提案されており、これにより、直接および間接的にサービスを受けるUEのハンドオーバがターゲットCUに対して透過的になる。特に、トップレベルIABノードの無線リソース制御（RRC）コネクションのみがターゲットCUに移され、そのF1コネクションのCU側の終端、および直接および間接的にサービスを受けるIABノードとUEのF1コネクションとRRCコネクションのCU側の終端はソースCUに保持される。したがってこの場合、ターゲットCUは、トップレベルIABノードの祖先ノードが、トップレベルノードからターゲットドナーへの、およびターゲットドナーからトップレベルノードへのトラフィックを処理するように適切に設定されていることを確実にするだけでよい。一方、当該トップレベルノードの子孫IABノードの構成は、依然としてソースドナーの制御下にある。したがって、この場合ターゲットドナーは、ネットワークトポロジやQoS要件、または子孫IABノードやUEの構成を知る必要はない。
【0041】
図7は、IABノード3移行前の信号フローの例を示す。 図8は、IABノード3移行後の信号フローの例を示す。 具体的には、図7は、F1接続がCU-1で維持される場合のシグナリング接続を示し、図8は、F1-UがXn上でトンネリングされ、IABノードがターゲットドナーCU（すなわちCU2）に移された後、IABドナーDU-2に透過的に転送される方法を強調している。
【0042】
図9は、ドナー間負荷分散のためのプロキシベースのソリューションの一例を示す。 具体的には、IAB3とその子孫ノードであるIAB4、およびこれら2つのIABノードがサービスを提供しているUEがソリューションに関与する。
【0043】
図9のシナリオに適用すると、プロキシベースのソリューションは以下のように動作する。
・ IAB3-MTは、RRC接続（つまりアソシエーション）をCU1からCU2に変更する。
・ 一方、IAB4-MTおよび、IAB3およびIAB4がサービスを提供するすべてのUEのRRC接続と、IAB3-DUおよびIAB4-DUのF1接続とはCU1に固定されたまま（つまり、CU2に移されない）であるのに対して、これらコネクションの対応するトラフィックは、CU2を経由するパスを用いて、IAB3/IAB4およびそれらがサービスを提供するUEとの間で送受信される。
・ IAB3-MTは、RRC接続（つまりアソシエーション）をCU1からCU2に変更する。
・ 一方、IAB4-MTおよび、IAB3およびIAB4がサービスを提供するすべてのUEのRRC接続と、IAB3-DUおよびIAB4-DUのF1接続とはCU1に固定されたまま（つまり、CU2に移されない）であるのに対して、これらコネクションの対応するトラフィックは、CU2を経由するパスを用いて、IAB3/IAB4およびそれらがサービスを提供するUEとの間で送受信される。
【0044】
そのため、ソースドナー（すなわち、図２～図９のCU1）からトップレベルIABノード（IAB3）およびその子孫（IAB4など）に送信されていたトラフィックは、CU2を経由してオフロード（すなわちプロキシ）される。具体的には、
・ CU1からIAB4への古いトラフィックパス、すなわちCU1 - ドナーDU1 - IAB2 - IAB3 - IAB4は、負荷分散の目的で、CU1 - ドナーDU_2 - IAB5 - IAB3 - IAB4に変更される。
・ CU1からIAB4への古いトラフィックパス、すなわちCU1 - ドナーDU1 - IAB2 - IAB3 - IAB4は、負荷分散の目的で、CU1 - ドナーDU_2 - IAB5 - IAB3 - IAB4に変更される。
【0045】
ここでは、CU1 - CU2 - ドナーDU1 - などの間接的なルーティングではなく、CU1とドナーDU_2との間の直接的なルーティングが適用される（すなわち、CU1 - ドナーDU1 - など......）。直接ルーティングは、例えば、（ソースドナー）CU1とドナーDU2（ターゲットドナーDU）との間のIPルーティングを用いて、または両者間のXnコネクションを用いてサポートすることができる。間接ルーティングでは、CU1-CU2間はXnインターフェイス経由で、CU2-ドナーDU_2間はF1経由またはIPルーティング経由でデータを送信することができる。直接ルーティングと間接ルーティングの両方を、本明細書で説明する実施形態に適用可能である。直接ルーティングの利点は、遅延がより小さくなる可能性が高いことである。
【0046】
3GPPは、ハンドオーバのためのRRCメッセージ（HOコマンド）を受信した後、かつ、ターゲットgNBへのランダムアクセスに成功した後にソースセルを解放するまで、ソースgNBのコネクションを維持するデュアルアクティブプロトコルスタック（DAPS）ハンドオーバー手順を規定している。
【0047】
DAPSハンドオーバーは、RLC-AMまたはRLC-UMベアラに対して使用することができる。DAPSで構成されたDRBについては、さらに以下の原則が適用される。
【0048】
ダウンリンクに関して：
- HOの準備中、転送トンネルは常に確立される。
- ソースgNBは、SN割り当てがターゲットgNBにハンドオーバされ、データ転送が行われるまで、ダウンリンクPDCP（Packet Data Convergence Protocol）シーケンス番号（SN）を割り当てる責任を負う。つまり、ソースgNBは、ハンドオーバ成功(HANDOVER SUCCESS)メッセージを受信し、SNステータス転送(SN STATUS TRANSFER)メッセージをターゲットgNBに送信するまで、ダウンリンクパケットへのPDCP SN割り当てを停止しない。
- ソースgNBによってダウンリンクPDCP SNが割り当てられると、ソースgNBはソース無線リンク上でダウンリンクデータのスケジューリングを開始し、また割り当てられたPDCP SNとともにダウンリンクPDCP SDUをターゲットgNBに転送し始める。
- セキュリティ同期のため、ソースgNBによって割り当てられたPDCP SNを有する転送されたダウンリンクSDUに対してハイパーフレーム番号（HFN）が保持される。ソースgNBは、ターゲットgNBに転送する最初のPDCP SDUのPDCP SNとHFNを示すDL COUNT値を搬送するために、初期ステータス転送(EARLY STATUS TRANSFER)メッセージを送信する。
- HFNとPDCP SNは、SN割り当てがターゲットgNBにハンドオーバされた後も維持される。SNステータス転送(SN STATUS TRANSFER)メッセージは、RLC-UM(Radio Link Control-Unacknowledge Mode)についても、PDCPシーケンス番号をまだ持たないパケットに割り当てる次のDL PDCP SNを示す。
- ハンドオーバ実行期間中、ソースgNBとターゲットgNBとは個別に、ロバストヘッダ圧縮（ROHC）、暗号化、PDCPヘッダの追加を実行する。
- ハンドオーバ実行期間中、UEは、ターゲットgNBからの明示的な解放コマンドによってソースgNBコネクションが解放されるまで、ソースおよびターゲットgNBの両方からダウンリンクデータを受信し続ける。
- ハンドオーバー実行期間中、DAPSで構成されたUEのPDCPエンティティは、並べ替え、重複の検出と破棄、およびPDCP SDUの上位レイヤへの順次配信のための共通機能を維持しながら、各gNBに関連付けられた別個のセキュリティ機能とROHCヘッダ解凍機能とを維持する。PDCP SNの連続性は、DAPSで構成されたRLC AMとUM DRB との両方でサポートされる。
- HOの準備中、転送トンネルは常に確立される。
- ソースgNBは、SN割り当てがターゲットgNBにハンドオーバされ、データ転送が行われるまで、ダウンリンクPDCP（Packet Data Convergence Protocol）シーケンス番号（SN）を割り当てる責任を負う。つまり、ソースgNBは、ハンドオーバ成功(HANDOVER SUCCESS)メッセージを受信し、SNステータス転送(SN STATUS TRANSFER)メッセージをターゲットgNBに送信するまで、ダウンリンクパケットへのPDCP SN割り当てを停止しない。
- ソースgNBによってダウンリンクPDCP SNが割り当てられると、ソースgNBはソース無線リンク上でダウンリンクデータのスケジューリングを開始し、また割り当てられたPDCP SNとともにダウンリンクPDCP SDUをターゲットgNBに転送し始める。
- セキュリティ同期のため、ソースgNBによって割り当てられたPDCP SNを有する転送されたダウンリンクSDUに対してハイパーフレーム番号（HFN）が保持される。ソースgNBは、ターゲットgNBに転送する最初のPDCP SDUのPDCP SNとHFNを示すDL COUNT値を搬送するために、初期ステータス転送(EARLY STATUS TRANSFER)メッセージを送信する。
- HFNとPDCP SNは、SN割り当てがターゲットgNBにハンドオーバされた後も維持される。SNステータス転送(SN STATUS TRANSFER)メッセージは、RLC-UM(Radio Link Control-Unacknowledge Mode)についても、PDCPシーケンス番号をまだ持たないパケットに割り当てる次のDL PDCP SNを示す。
- ハンドオーバ実行期間中、ソースgNBとターゲットgNBとは個別に、ロバストヘッダ圧縮（ROHC）、暗号化、PDCPヘッダの追加を実行する。
- ハンドオーバ実行期間中、UEは、ターゲットgNBからの明示的な解放コマンドによってソースgNBコネクションが解放されるまで、ソースおよびターゲットgNBの両方からダウンリンクデータを受信し続ける。
- ハンドオーバー実行期間中、DAPSで構成されたUEのPDCPエンティティは、並べ替え、重複の検出と破棄、およびPDCP SDUの上位レイヤへの順次配信のための共通機能を維持しながら、各gNBに関連付けられた別個のセキュリティ機能とROHCヘッダ解凍機能とを維持する。PDCP SNの連続性は、DAPSで構成されたRLC AMとUM DRB との両方でサポートされる。
【0049】
アップリンクに関して：
- UEは、ターゲットgNBへのランダムアクセス手順が正常に完了するまで、ULデータをソースgNBに送信する。その後、UEは、ULデータ送信をターゲットgNBに切り替える。
- ターゲットgNBに向けてULデータ送信を切り替えた後も、UEは、ULレイヤ1チャネル状態情報（CSI）フィードバック、ハイブリッド自動再送要求（HARQ）フィードバック、レイヤ2無線リンク制御（RLC）フィードバック、ROHCフィードバック、HARQデータ再送信、およびRLCデータ再送信のソースgNBへの送信を継続する。
- ハンドオーバ実行期間中、UEは、ソースおよびターゲットgNBに向けたアップリンク送信のための個別のセキュリティコンテキストおよびROHCヘッダ圧縮コンテキストを維持する。UEは共通のUL PDCP SN割り当てを維持する。PDCP SNの連続性は、デュアルアクティブプロトコルスタック（DAPS）で構成された無線リンク制御確認モード（RLC AM）とRLC-UM DRBとの両方でサポートされる。
- ハンドオーバ実行期間中、ソースおよびターゲットgNBは、UEから受信したULデータを処理するため、独自のセキュリティおよびROHCヘッダ解凍コンテキストを維持する。
- 転送トンネルの確立は任意である。
- HFNとPDCP SNはターゲットgNBで維持される。SNステータス転送(SN STATUS TRANSFER)メッセージは、RLC-UMであっても、ターゲットが5GCに配信を開始すべき、最初に欠落したPDCP SDUのCOUNTを示す。
- UEは、ターゲットgNBへのランダムアクセス手順が正常に完了するまで、ULデータをソースgNBに送信する。その後、UEは、ULデータ送信をターゲットgNBに切り替える。
- ターゲットgNBに向けてULデータ送信を切り替えた後も、UEは、ULレイヤ1チャネル状態情報（CSI）フィードバック、ハイブリッド自動再送要求（HARQ）フィードバック、レイヤ2無線リンク制御（RLC）フィードバック、ROHCフィードバック、HARQデータ再送信、およびRLCデータ再送信のソースgNBへの送信を継続する。
- ハンドオーバ実行期間中、UEは、ソースおよびターゲットgNBに向けたアップリンク送信のための個別のセキュリティコンテキストおよびROHCヘッダ圧縮コンテキストを維持する。UEは共通のUL PDCP SN割り当てを維持する。PDCP SNの連続性は、デュアルアクティブプロトコルスタック（DAPS）で構成された無線リンク制御確認モード（RLC AM）とRLC-UM DRBとの両方でサポートされる。
- ハンドオーバ実行期間中、ソースおよびターゲットgNBは、UEから受信したULデータを処理するため、独自のセキュリティおよびROHCヘッダ解凍コンテキストを維持する。
- 転送トンネルの確立は任意である。
- HFNとPDCP SNはターゲットgNBで維持される。SNステータス転送(SN STATUS TRANSFER)メッセージは、RLC-UMであっても、ターゲットが5GCに配信を開始すべき、最初に欠落したPDCP SDUのCOUNTを示す。
【0050】
RAN3#110-eミーティングにおいて、RAN3は、2つのドナーへの同時接続のための潜在的なソリューションには、「DAPSのような」ソリューションが含まれうることに合意した。この点に関して、デュアルIABプロトコルスタック（DIPS）と呼ばれるソリューションが3GPPで提案されている。 図10は、DIPSソリューションの一例を示している。
【0051】
DIPSは以下に基づいている。
・ 無線リンク制御（RLC）／媒体アクセス制御（MAC）／物理層（PHY）を含みうる、それぞれが異なるCUに接続する2つの独立したプロトコルスタック。
・ いくつかの共通した機能といくつかの独立した機能を持つ1つまたは2つの独立したBAPエンティティ。
・ 各CUは、調整の必要なしに自身のリソース（アドレス、BH RLCチャネルなど）を割り当て、また、各プロトコルスタックを構成する。
・ 無線リンク制御（RLC）／媒体アクセス制御（MAC）／物理層（PHY）を含みうる、それぞれが異なるCUに接続する2つの独立したプロトコルスタック。
・ いくつかの共通した機能といくつかの独立した機能を持つ1つまたは2つの独立したBAPエンティティ。
・ 各CUは、調整の必要なしに自身のリソース（アドレス、BH RLCチャネルなど）を割り当て、また、各プロトコルスタックを構成する。
【0052】
要するに、このソリューションはDAPSのように2つのプロトコルスタックを有するが、PDCPレイヤの代わりにBAPエンティティがある点が異なる。BAP機能のセットを共通にし、別の機能のセットを親ノードごとに独立させることもできる。
【0053】
このタイプのソリューションは、複雑さを最小限に抑え、ワークアイテムのすべての目標を達成する。なぜなら、
・ 各プロトコルスタックは、現在のシグナリングと手順を使用して個別に構成可能であるため、堅牢性が向上する。最小限のシグナリングのアップデートが必要かもしれない。
・ トップレベルのIABノードだけが再構成される。他のノードやUEにとってはすべて透過的であり、再構成を必要としないため、シグナリング負荷が軽減され、堅牢性が向上する。
・ 2番目のリンクがセットアップされるまで、最初のリンクでデータを流し続けることができるため、サービスの中断をなくすことができる。
・ CU間のIP/BAPアドレスとルートIDの調整が不要になり、複雑さとネットワーク信号が大幅に削減される。
・ 各プロトコルスタックは、現在のシグナリングと手順を使用して個別に構成可能であるため、堅牢性が向上する。最小限のシグナリングのアップデートが必要かもしれない。
・ トップレベルのIABノードだけが再構成される。他のノードやUEにとってはすべて透過的であり、再構成を必要としないため、シグナリング負荷が軽減され、堅牢性が向上する。
・ 2番目のリンクがセットアップされるまで、最初のリンクでデータを流し続けることができるため、サービスの中断をなくすことができる。
・ CU間のIP/BAPアドレスとルートIDの調整が不要になり、複雑さとネットワーク信号が大幅に削減される。
【0054】
CUが負荷分散が必要だと判断すると、CUは第2のCUリソースに対して、特定の（つまりトップレベルの）IABノードのトラフィックの一部をオフロードするよう要求する手順を開始する。CUは構成をネゴシエートし、2番目のCUはIAB-MTの2番目のプロトコルスタックに適用する構成、RLCバックホールチャネル、BAPアドレスなどを準備する。
【0055】
トップレベルIAB-MTは、CUが提供するルーティングルールを使用して、特定のトラフィックを第1または第2のCUにルーティングする。DLにおいて、IAB-MTは、第1CUの制御下にあるノードに到達するために、第2CUからのBAPアドレスを第1CUからのBAPアドレスに変換する。
【0056】
これはすべて、トップレベルIABノード（トラフィックがオフロードされるIABノード）のみが影響を受け、他のノードやUEはこの状況に気付かないことを意味する。この手順はすべて、若干の変更を加えるだけで、現在のシグナリングでも実行できる。
【0057】
図11は、RAN3で合意されたドナー間トポロジ冗長性に関する2つのシナリオを示す。 具体的には、ドナー間トポロジ冗長性に関する2つのシナリオは以下を含む。
- シナリオ1：IABは2つのドナーとマルチ接続されている。
- シナリオ2：IABの親/祖先ノードが2つのドナーとマルチ接続されている。
- シナリオ1：IABは2つのドナーとマルチ接続されている。
- シナリオ2：IABの親/祖先ノードが2つのドナーとマルチ接続されている。
【0058】
これら2つのシナリオにおいて、RAN3は以下の用語を使用する。
- バウンダリIABノード：このノードは、例えば上述の図におけるIAB3であり、2つの異なるドナーCUにそれぞれ接続された2つの異なる親ノードにアクセスする。
- 子孫IABノード：境界IABノードを経由してネットワークにアクセスする(1以上の)ノードで、各ノードは親ノードにシングル接続される。例えばシナリオ2のIAB4である。
- F1終端ノード：境界IABノードおよび(1以上の)子孫ノードのF1インタフェースを終端するドナーCUである。
- 非F1終端ノード：ドナー機能を持つCUで、境界IABノードと(1以上の)子孫ノードのF1インタフェースを終端しないCUである。
- バウンダリIABノード：このノードは、例えば上述の図におけるIAB3であり、2つの異なるドナーCUにそれぞれ接続された2つの異なる親ノードにアクセスする。
- 子孫IABノード：境界IABノードを経由してネットワークにアクセスする(1以上の)ノードで、各ノードは親ノードにシングル接続される。例えばシナリオ2のIAB4である。
- F1終端ノード：境界IABノードおよび(1以上の)子孫ノードのF1インタフェースを終端するドナーCUである。
- 非F1終端ノード：ドナー機能を持つCUで、境界IABノードと(1以上の)子孫ノードのF1インタフェースを終端しないCUである。
【0059】
しかしながら、現在、ある(1つ以上の)課題が存在する。例えば、上述したように、トポロジの適応は、（現在、3GPPでは部分的なドナー間移行と呼ばれている）プロキシベースのソリューションを使用することによって達成することができ、この場合、図9に示すシナリオに関して、トップレベルIAB3-MTは、自身のRRC接続（すなわち、アソシエーション）をCU1からCU2に変更する。一方、IAB4-MTおよび、IAB3およびIAB4がサービスを提供するすべてのUEのRRC接続と、IAB3-DUおよびIAB4-DUのF1接続とはCU1に固定されたままであるのに対して、これらコネクションの対応するトラフィックは、(上述したような)新たなパスを用いて、IAB3/IAB4およびそれらがサービスを提供するUEとの間で送受信されるであろう。
【0060】
とはいえ、以下のことは考慮すべきである。
・ 別のドナーにトラフィックをオフロードする必要性は一時的なものであり（たとえば1日のピーク時）、しばらくすると、トラフィックは最初のドナーのネットワークに戻すことが可能になることが見込まれる。
・ また、ミリ波リンクは一般に非常に安定しており、中断は稀かつ短時間であることが見込まれる。その意味で、トポロジ適応の要因がドナー間RLF復旧であった場合、旧ドナーの下で（旧）親への安定したリンクを（再び）確立することが可能になることが見込まれる。
・ 別のドナーにトラフィックをオフロードする必要性は一時的なものであり（たとえば1日のピーク時）、しばらくすると、トラフィックは最初のドナーのネットワークに戻すことが可能になることが見込まれる。
・ また、ミリ波リンクは一般に非常に安定しており、中断は稀かつ短時間であることが見込まれる。その意味で、トポロジ適応の要因がドナー間RLF復旧であった場合、旧ドナーの下で（旧）親への安定したリンクを（再び）確立することが可能になることが見込まれる。
【0061】
これまでの方法には、別のCUへのプロキシベースの負荷分散を取り消すことが含まれていた。以下のシナリオに対処した。
・ あるドナーに接続されたトップレベルノードについて、トラフィックを取り消すこと、すなわち、別のドナーへのトラフィックオフロードの構成を解除すること（例えば、負荷分散とドナー間RLF復旧の両方のためのプロキシベースのアプローチによる）、すなわち、トラフィックを別のドナー（例えば、第2のCU（CU2））の下のプロキシされた(1以上の)パスから第1のドナー（例えば、第1のCU（CU1））の下の(1以上の)元のパスに戻すこと。
・ トップレベルノードが同時に2つのドナーに接続されている場合について、別のCUへのトラフィックオフロードを取り消すこと。オフロードされたトラフィックは、トップレベルノードのレグから2番目のドナー（例えばCU2）に向かうように移され、最初のドナー（例えばCU1）に向かうように元のレグに戻される。
・ あるドナーに接続されたトップレベルノードについて、トラフィックを取り消すこと、すなわち、別のドナーへのトラフィックオフロードの構成を解除すること（例えば、負荷分散とドナー間RLF復旧の両方のためのプロキシベースのアプローチによる）、すなわち、トラフィックを別のドナー（例えば、第2のCU（CU2））の下のプロキシされた(1以上の)パスから第1のドナー（例えば、第1のCU（CU1））の下の(1以上の)元のパスに戻すこと。
・ トップレベルノードが同時に2つのドナーに接続されている場合について、別のCUへのトラフィックオフロードを取り消すこと。オフロードされたトラフィックは、トップレベルノードのレグから2番目のドナー（例えばCU2）に向かうように移され、最初のドナー（例えばCU1）に向かうように元のレグに戻される。
【0062】
とはいえ、オフロードが設定され、機能するようになった後に、以下を可能にするための方法は不明である。
・ CU1がCU2に追加トラフィックをオフロードすること、
・ CU1が、オフロードの完全な取り消しに対処する代わりに、以前にCU2にオフロードされたトラフィックの一部のオフロードを取り消すこと。
・ CU2が、CU2ドメイン配下のネットワークが輻輳するなど、何らかの理由でCU2が処理できないCU1のトラフィックの一部について、CU1にオフロードの取り消しを要求すること。
・ CU1がCU2に追加トラフィックをオフロードすること、
・ CU1が、オフロードの完全な取り消しに対処する代わりに、以前にCU2にオフロードされたトラフィックの一部のオフロードを取り消すこと。
・ CU2が、CU2ドメイン配下のネットワークが輻輳するなど、何らかの理由でCU2が処理できないCU1のトラフィックの一部について、CU1にオフロードの取り消しを要求すること。
【発明の概要】
【0063】
本開示の所定の態様およびそれらの実施形態は、これらの課題または他の課題に対する解決策を提供しうる。例えば、本明細書に開示される特定の実施形態は、CU1が、以前に実行された移行（完全な移行またはプロキシベースの移行）の構成の1つまたは複数のパラメータを更新する必要があることをCU2に要求するための方法およびシステムに関する。 別の例として、特定の実施形態は、CU2が、以前に実行された移行（完全な移行またはプロキシベースの移行）の構成の1つまたは複数のパラメータを更新する必要があることをCU1に要求するための方法およびシステムに関する。
【0064】
特定の実施形態によれば、IABネットワークのCU1による方法は、CU2に第1のメッセージを送信すること、またはCU2から第1のメッセージを受信することを含む。 第1のメッセージには、オフロードされたトラフィックの一部をCU1に戻すことを示す情報が含まれる。 オフロードされたトラフィックは、以前にCU1からCU2にオフロードされたものである。
【0065】
特定の実施形態によれば、IABネットワークのCU1は、CU2に第1のメッセージを送信するように、またはCU2から第1のメッセージを受信するように構成される。 第1のメッセージには、オフロードされたトラフィックの一部をCU1に戻すことを示す情報が含まれる。 オフロードされたトラフィックは、以前にCU1からCU2にオフロードされたものである。
【0066】
特定の実施形態によれば、IABネットワークのCU2による方法は、CU1に第1のメッセージを送信すること、またはCU1から第1のメッセージを受信することを含む。第1のメッセージは、オフロードされたトラフィックの一部をCU1に戻すことを示す情報を有する。 オフロードされたトラフィックは、以前にCU1からCU2にオフロードされたものである。
【0067】
特定の実施形態によれば、IABネットワークのCU2は、CU1に第1のメッセージを送信するように、またはCU1から第1のメッセージを受信するように構成され、第1のメッセージは、オフロードされたトラフィックの一部をCU1に戻すことを示す情報を有する。 オフロードされたトラフィックは、以前にCU1からCU2にオフロードされたものである。
【0068】
特定の実施形態は、以下の(1つ以上の)技術的利点の1つ以上を提供しうる。 例えば、特定の実施形態は、2つのCUが手順に関与する場合に、トラフィック負荷分散のためのネットワークリソースの動的制御を可能にするという技術的利点を提供することができる。
【0069】
その他の利点は、当業者には容易に明らかであろう。特定の実施形態は、記載された利点を全く有さないことも、いくつか有することも、全て有することもある。
【図面の簡単な説明】
【0070】
開示された実施形態ならびにその特徴および利点をより完全に理解するために、以下の説明を添付図面と併せて参照する。
【0071】
【発明を実施するための形態】
【0072】
本開示で企図される実施形態のいくつかを、添付図面を参照してより完全に説明する。 しかしながら、ここに開示された主題はその範囲に他の実施形態を包含する。開示された主題は、記載された実施形態のみに限定されると解釈されるべきではなく、むしろ、これらの実施形態は、主題の範囲を当業者に知らせるための例として提供される。
【0073】
いくつかの実施形態では、より一般的な用語「ネットワークノード」が使用されることがあり、「ネットワークノード」は、UEと（直接または別のノードを介して）および／または別のネットワークノードと通信する任意のタイプの無線ネットワークノードまたは任意のネットワークノードに対応しうる。ネットワークノードの例としては、NodeB、MeNB、ENB、MCGまたはSCGに属するネットワークノード、基地局（BS）、MSR BSなどのマルチスタンダード無線（MSR）無線ノード、eNodeB、gNodeB、ネットワークコントローラ、無線ネットワークコントローラ（RNC）、基地局コントローラ（BSC）、中継局(リレー）、中継を制御するドナーノード、基地トランシーバ局（BTS）、アクセスポイント（AP）、送信ポイント、送信ノード、RRU、RRH、分散アンテナシステム（DAS）のノード、コアネットワークノード（MSC、MMEなど）、O&M、OSS、SON、測位ノード（E-SMLCなど）、MDT、試験装置（物理ノードまたはソフトウェア）などがある。
【0074】
いくつかの実施形態では、ユーザ機器（UE）または無線機器という非限定的な用語が使用されることがあり、これらの用語は、セルラーまたはモバイル通信システムにおいてネットワークノードおよび／または別のUEと通信する任意のタイプの無線機器を意味しうる。UEの例としては、ターゲットデバイス、デバイス間（D2D）UE、マシンタイプUEまたはマシン間（M2M）通信が可能なUE、PDA、PAD、タブレット、携帯端末、スマートフォン、ノートPC組込み機器（LEE）、ノートPC搭載機器（LME）、USBドングル、UEカテゴリM1、UEカテゴリM2、ProSe UE、V2V UE、V2X UEなどがある。
【0075】
さらに、基地局/gNodeB、UEなどの用語は、非限定的なものと考えるべきであり、特にそれら2つの間の特定の階層関係を意味するものではない。一般に、「gNodeB」は機器1、「UE」は機器2と考えることができ、これら2つの機器は何らかの無線チャネルを介して相互に通信する。 そして以下では、送信機または受信機はgNBまたはUEのいずれかでありうる。
【0076】
特定の実施形態は、プロキシベースのドナー間移行の場合に例証されるものとして説明されているが、本明細書で説明される方法および技術は、ネットワークが、以前にCU1からCU2へ完全に移行された機器を、CU2からCU1へ完全に移行し直す必要があると決定または認識した場合における完全移行ベースのソリューションにも同様に適用可能である。
【0077】
「ドナー間トラフィックオフロード」、「ドナー間移行」、「ドナー間トポロジ適合」という用語は、同じ意味で用いられる。
【0078】
「シングル接続トップレベルノード」という用語は、一度に1つのドナーのみに接続するトップレベルIAB-MTを意味する。
【0079】
「デュアル接続トップレベルノード」という用語は、同時に2つのドナーに接続するトップレベルIAB-MT、または各MTが1つのドナーに接続する2つのMTを有するIABを意味する。
【0080】
「子孫ノード」という用語は、子ノードと、その子ノードの子ノード（以下同様）との両方を意味しうる。
【0081】
「CU1」、「ソースドナー」、「旧ドナー」という用語は同じ意味で用いられる。
【0082】
「CU_2」、「ターゲットドナー」、「新ドナー」という用語は、同じ意味で用いられる。
【0083】
「ドナーDU1」、「ソースドナーDU」、「旧ドナーDU」という用語は、同じ意味で用いられる。
【0084】
「ドナーDU2」、「ターゲットドナーDU」、「新ドナーDU」という用語は、同じ意味で用いられる。
【0085】
「親」という用語は、IABノードまたはIABドナーDUを意味しうる。
【0086】
「移行IABノード」と「トップレベルIABノード」という用語は、同じ意味で用いられる。
・ ドナー間トポロジ適応のためのプロキシベースのソリューションでは、これらはこのノードのIAB-MT（例えば、図9のIAB3-MT）を意味する。なぜなら、トップレベルノードの同位置配置されたIAB-DUでは移行しない（ソースドナーへのF1コネクションを維持する）からである。
・ 完全移行ベースのソリューションでは、ノード全体とその子孫が別のドナーに移行する。
・ ドナー間トポロジ適応のためのプロキシベースのソリューションでは、これらはこのノードのIAB-MT（例えば、図9のIAB3-MT）を意味する。なぜなら、トップレベルノードの同位置配置されたIAB-DUでは移行しない（ソースドナーへのF1コネクションを維持する）からである。
・ 完全移行ベースのソリューションでは、ノード全体とその子孫が別のドナーに移行する。
【0087】
特定の実施形態が基づくシナリオの非限定的な例をいくつか以下に示す。
・ プロキシベースのソリューションを使用した、デュアル接続トップレベルノード（図9のIAB3-MTなど）のドナー間負荷分散。ここで、トップレベルIABノードへ/から/を経由して搬送されるトラフィックは、ターゲットドナーによって引き継がれる（すなわち、プロキシされる）（負荷分散）、すなわち、ソースドナーは、当該IABノードとその親ノードとの間の入方向/出方向BH RLCチャネルに関連するトラフィックを、ターゲットドナーに向かうトップレベルノードのレグにオフロードする。
・ 上記IABノードの親へのリンク上、または上記IABノードの親と親の親との間のリンク上のRLFに起因する、デュアル接続トップレベルノードのドナー間RLF復旧では、上記ノード（すなわちトップレベルノード）のトラフィックがターゲットドナーに向かう上記ノードのレグに完全に移される。
・ IABノードが別のドナーにハンドオーバーする。
・ ローカルドナー間再ルーティング（ULおよび/またはDL）。ドナーまたは宛先IABノードに向かう新たに選択されたパスは、別のドナーを経由する。
・ 上述した例示的なシナリオのいずれにおいても、(プロキシベースのソリューションの代わりに）完全移行ベースのソリューション（前述）が適用される。
・ プロキシベースのソリューションを使用した、デュアル接続トップレベルノード（図9のIAB3-MTなど）のドナー間負荷分散。ここで、トップレベルIABノードへ/から/を経由して搬送されるトラフィックは、ターゲットドナーによって引き継がれる（すなわち、プロキシされる）（負荷分散）、すなわち、ソースドナーは、当該IABノードとその親ノードとの間の入方向/出方向BH RLCチャネルに関連するトラフィックを、ターゲットドナーに向かうトップレベルノードのレグにオフロードする。
・ 上記IABノードの親へのリンク上、または上記IABノードの親と親の親との間のリンク上のRLFに起因する、デュアル接続トップレベルノードのドナー間RLF復旧では、上記ノード（すなわちトップレベルノード）のトラフィックがターゲットドナーに向かう上記ノードのレグに完全に移される。
・ IABノードが別のドナーにハンドオーバーする。
・ ローカルドナー間再ルーティング（ULおよび/またはDL）。ドナーまたは宛先IABノードに向かう新たに選択されたパスは、別のドナーを経由する。
・ 上述した例示的なシナリオのいずれにおいても、(プロキシベースのソリューションの代わりに）完全移行ベースのソリューション（前述）が適用される。
【0088】
特定の実施形態によれば、トップレベルIABノードは、トップレベルIAB-MTと、その同位置配置されたIAB-DU（「同位置配置されたDU」または「トップレベルDU」と呼ばれることもある）から構成される。特定のシナリオでは、それは、2台のMTと1台の同位置配置されたIAB-DUとから構成されうる。本明細書で説明する実施形態のある側面は、ドナー間トポロジ適応のためのプロキシベースのソリューションに関連し、ある側面は、上述の完全移行ベースのソリューションに関連する。
【0089】
特定の実施形態によれば、「子孫デバイスのRRC／F1コネクション」という用語は、子孫IAB-MTおよびUEとドナー（この場合、ソースドナー）とのRRCこねくオンと、トップレベルIABノードの子孫IABノードのトップレベルIAB-DUおよびIAB-DUとドナー（ソースドナー）とのF1コネクションとを意味する。
【0090】
特定の実施形態によれば、CU1とトップレベルIABノードおよび／またはその子孫ノードとの間のトラフィック（プロキシードトラフィックとも呼ばれる）は、CU1と以下のものの間のトラフィックを意味する。
1. トップレベルIABノードの同位置配置されたIAB-DU部（トップレベルIABノードのIAB-MT部が新しいドナーにRRC接続を移行したことによる）、
2. トップレベルIABノードの子孫IABノード、および
3. トップレベルノードおよびその下位ノードがサービスを提供するUE。
1. トップレベルIABノードの同位置配置されたIAB-DU部（トップレベルIABノードのIAB-MT部が新しいドナーにRRC接続を移行したことによる）、
2. トップレベルIABノードの子孫IABノード、および
3. トップレベルノードおよびその下位ノードがサービスを提供するUE。
【0091】
特定の実施形態によれば、トラフィックのオフロードのために、CU1-CU2-ドナーDU2-...という、トラフィックが最初にCU2に向かう間接ルーティングではなく、CU1とドナーDU2との間の直接ルーティング(つまり、CU1-ドナーDU2-....)が適用されることを仮定している。直接ルーティングは、例えば、（ソースドナー）CU1とドナーDU2（ターゲットドナーDU）間のIPルーティング、または両者間のXnコネクションによってサポートされる。間接ルーティングでは、CU1-CU2間はXnインターフェイス経由で、CU2-ドナーDU2間はF1経由またはIPルーティング経由でデータが送信される。直接ルーティングと間接ルーティングの両方を、本明細書で説明する実施形態に適用可能である。直接ルーティングの利点は、遅延がより小さくなる可能性が高いことである。
【0092】
特定の実施形態によれば、ユーザプレーンと制御プレーンの両方のトラフィックが、直接ルーティングと間接ルーティングによって、ソースドナーからターゲットドナーを経由して、トップレベルノードとその子孫へ／から送信されると仮定する。
【0093】
「宛先がIAB-DU」という用語は、最終的な宛先がが当該IAB-DUまたは当該IAB-DUがサービスを提供するUEまたはIAB-MTのいずれかであるトラフィックの両方を含み、トップレベルIAB-DUも含まれる。
【0094】
「データ」という用語は、ユーザープレーン、コントロールプレーントラフィック、および非F1トラフィックの両方を意味する。
【0095】
ここで説明する検討事項は、固定IABノードにもモバイルIABノードにも同様に適用できる。
【0096】
ここで、「旧ドナー」および「CU1」という用語は、以前に「新ドナー」/「CU2」にトラフィックをオフロードしたドナーを意味する。CU1とCU2から移行IABノードへのコネクションが確立済みであることが出発点である。
【0097】
図12は、特定の実施形態に係る、CU1 20(例えばソースドナーノード)とCU2 30(例えばターゲットドナーノード)との間のメッセージ交換を示すシグナリングチャート10の例を示す図である。
【0098】
図12に示すように、CU1 20およびCU2 30のいずれか一方または両方は、40においてトラフィックステータス情報を要求しうる。 特定の実施形態では、(1以上の)要求はタイマまたはトリガベースである。 トラフィックステータス情報の要求に応答して（あるいは、要求より先に、および／または要求を受信することなく）、CU1 20および／またはCU2 30は、50において、トラフィック負荷ステータスを提供しうる。 その後、60において、CU1 20は、CU2 30から取得したトラフィック負荷ステータスに基づいて、またはCU1 20が直接取得した情報に基づいて、対処しうる。 70で、CU1 20は、CU2 30にトラフィックをオフロードするか、または以前にCU2 30にオフロードされたトラフィックを取り消しうる。 後者の場合、CU1 20は、以前にCU2 30にオフロードされたトラフィックの処理を再開する。
【0099】
CU1による動的オフロード要求
【0100】
特定の実施形態によれば、CU1による動的オフロード要求を含む方法は、以下を含む。
・ ステップ1：CU1は、1）追加のトラフィック負荷をCU2にオフロードする、または2）以前にCU2にオフロードされたトラフィックの一部をCU1に戻すことが必要と判断する。以前にオフロードされたトラフィックの一部という言及は、以前にオフロードされたトラフィックの一部のみを意味しうる。
・ ステップ2：CU1がCU2に追加のトラフィックをオフロードすると決定した場合：
・ ステップ2.1：CU1はCU2に追加リソースを要求する。これらのリソースは、ダウンリンク、アップリンク、またはその両方の可能性がある。
・ ステップ2.2：CU2はCU1に対して、否定的、つまり追加リソースを与えないか、あるいは肯定的、つまり追加リソースを与えるかのどちらかを応答する。これらの追加リソースは、ステップ2.1で最初に要求されたリソースとは異なりうる。
・ ステップ2.3：CU2からの応答に基づいて、CU1は、影響を受けるルートおよびUE/ノードについて、IABノードのルーティングテーブルを更新しうる。その結果、追加のCU1トラフィックがCU2経由でオフロードされる。
・ ステップ3：CU1が、以前にオフロードしたトラフィックの一部をCU2に戻すと決定した場合：
・ ステップ3.1：CU1は、CU2に対して、オフロードのためのリソース割り当てを削減可能なこと、すなわち、以前にオフロードされたトラフィックの一部をCU1に戻すことができることを通知しうる。（CU1オフロードトラフィックに割り当てられている）これらのリソースは、ダウンリンク、アップリンク、またはその両方でありうる。
・ ステップ3.2：CU2は、CU1に確認応答で応答しうる。CU2は、CU1に戻されるオフロードされたトラフィックに関連づけられている対応するリソースを解放しうる。
・ ステップ3.3：CU1は、影響を受けるルートおよびUE/ノードについて、IABノードのルーティングテーブルを更新する。その結果、CU1経由のトラフィックが増え、CU2経由のトラフィックが減ることになる(以前にオフロードされたトラフィックの一部がCU1に戻るため)。
・ ステップ1：CU1は、1）追加のトラフィック負荷をCU2にオフロードする、または2）以前にCU2にオフロードされたトラフィックの一部をCU1に戻すことが必要と判断する。以前にオフロードされたトラフィックの一部という言及は、以前にオフロードされたトラフィックの一部のみを意味しうる。
・ ステップ2：CU1がCU2に追加のトラフィックをオフロードすると決定した場合：
・ ステップ2.1：CU1はCU2に追加リソースを要求する。これらのリソースは、ダウンリンク、アップリンク、またはその両方の可能性がある。
・ ステップ2.2：CU2はCU1に対して、否定的、つまり追加リソースを与えないか、あるいは肯定的、つまり追加リソースを与えるかのどちらかを応答する。これらの追加リソースは、ステップ2.1で最初に要求されたリソースとは異なりうる。
・ ステップ2.3：CU2からの応答に基づいて、CU1は、影響を受けるルートおよびUE/ノードについて、IABノードのルーティングテーブルを更新しうる。その結果、追加のCU1トラフィックがCU2経由でオフロードされる。
・ ステップ3：CU1が、以前にオフロードしたトラフィックの一部をCU2に戻すと決定した場合：
・ ステップ3.1：CU1は、CU2に対して、オフロードのためのリソース割り当てを削減可能なこと、すなわち、以前にオフロードされたトラフィックの一部をCU1に戻すことができることを通知しうる。（CU1オフロードトラフィックに割り当てられている）これらのリソースは、ダウンリンク、アップリンク、またはその両方でありうる。
・ ステップ3.2：CU2は、CU1に確認応答で応答しうる。CU2は、CU1に戻されるオフロードされたトラフィックに関連づけられている対応するリソースを解放しうる。
・ ステップ3.3：CU1は、影響を受けるルートおよびUE/ノードについて、IABノードのルーティングテーブルを更新する。その結果、CU1経由のトラフィックが増え、CU2経由のトラフィックが減ることになる(以前にオフロードされたトラフィックの一部がCU1に戻るため)。
【0101】
CU2による動的オフロード要求
【0102】
特定の実施形態によれば、CU2による動的オフロード要求を含む方法は、以下を含む。
・ ステップ1：CU2は、1）CU1から追加のトラフィックを引き受けることができる（以前にCU2がCU1から要求されたリソースを完全には提供できなかった場合）こと、または2）自ドメイン（つまりCU2ドメイン配下の）IABノードからのトラフィック需要の急増など、何らかの理由により移行IABノードへの割り当てリソースを削減する必要があることを判定する。CU1からのオフロード要求と同様に、割り当てられたリソースの削減は、オフロードされたトラフィックの一部のみを意味しうる。
・ ステップ2：CU2が、CU1からトラフィックをオフロードするための追加リソースを提供できると判定した場合：
・ ステップ2.1：CU2はCU1に、CU1からの追加トラフィックを引き受け可能なことを通知する。これらのリソースは、ダウンリンク、アップリンク、またはその両方の可能性がある。CU2はまた、CU1に提供できる追加リソースの量を知らせることができる。
・ ステップ2.2：CU1はCU2に対して、これ以上追加リソースが必要ない場合に否定的に、あるいは、提供されたリソースを受け入れる場合に肯定的に応答することができる。
・ ステップ2.2’：CU2は、手続きをハンドシェイクするために、確認応答をCU1に送信しうる。
・ ステップ2.3：ステップ2.2または2.2’でのCU1からの応答に基づいて、CU1は、影響を受けるルートおよびUE/ノードについて、IABノードのルーティングテーブルを更新しうる。その結果、追加のトラフィックがCU2経由でオフロードされるようになる。
・ ステップ3：CU2が割り当てられたリソースを削減する必要があると判定した場合：
・ ステップ3.1：CU2はCU1にリソース割り当てを減らす必要があることを通知する。これらのリソースは、ダウンリンク、アップリンク、またはその両方の可能性がある。また、通知は、どのリソース（つまりBH RLCチャンネル）が削減/終了されるかも示す。
・ ステップ3.2：CU1は、CU2に以下によって応答しうる。
・ ステップ3.2.1：CU2要求の受諾を示す確認応答、または
・ ステップ3.2.2：あるいは、以前に構成されたものとは異なる構成を含みうる、リソース割り当ての第2の要求。これは、CU2からの要求にしたがって、トラフィックと対応するQoS要件とを適応／調整するために行われる可能性がある。
・ オプションとして、ステップ3.2.2.1：CU2はCU1からの要求に対して、新たな要求を受け入れるか、拒否するか、または別のリソース割り当てを提供することによって応答しうる。このループはステップ2.2に戻ってもよい。
・ ステップ3.3：CU1は、影響を受けるルートおよびUE/ノードについて、IABノードのルーティングテーブルを更新する。その結果、CU1経由のトラフィックが増え、CU2経由のトラフィックが減ることになる。
・ ステップ1：CU2は、1）CU1から追加のトラフィックを引き受けることができる（以前にCU2がCU1から要求されたリソースを完全には提供できなかった場合）こと、または2）自ドメイン（つまりCU2ドメイン配下の）IABノードからのトラフィック需要の急増など、何らかの理由により移行IABノードへの割り当てリソースを削減する必要があることを判定する。CU1からのオフロード要求と同様に、割り当てられたリソースの削減は、オフロードされたトラフィックの一部のみを意味しうる。
・ ステップ2：CU2が、CU1からトラフィックをオフロードするための追加リソースを提供できると判定した場合：
・ ステップ2.1：CU2はCU1に、CU1からの追加トラフィックを引き受け可能なことを通知する。これらのリソースは、ダウンリンク、アップリンク、またはその両方の可能性がある。CU2はまた、CU1に提供できる追加リソースの量を知らせることができる。
・ ステップ2.2：CU1はCU2に対して、これ以上追加リソースが必要ない場合に否定的に、あるいは、提供されたリソースを受け入れる場合に肯定的に応答することができる。
・ ステップ2.2’：CU2は、手続きをハンドシェイクするために、確認応答をCU1に送信しうる。
・ ステップ2.3：ステップ2.2または2.2’でのCU1からの応答に基づいて、CU1は、影響を受けるルートおよびUE/ノードについて、IABノードのルーティングテーブルを更新しうる。その結果、追加のトラフィックがCU2経由でオフロードされるようになる。
・ ステップ3：CU2が割り当てられたリソースを削減する必要があると判定した場合：
・ ステップ3.1：CU2はCU1にリソース割り当てを減らす必要があることを通知する。これらのリソースは、ダウンリンク、アップリンク、またはその両方の可能性がある。また、通知は、どのリソース（つまりBH RLCチャンネル）が削減/終了されるかも示す。
・ ステップ3.2：CU1は、CU2に以下によって応答しうる。
・ ステップ3.2.1：CU2要求の受諾を示す確認応答、または
・ ステップ3.2.2：あるいは、以前に構成されたものとは異なる構成を含みうる、リソース割り当ての第2の要求。これは、CU2からの要求にしたがって、トラフィックと対応するQoS要件とを適応／調整するために行われる可能性がある。
・ オプションとして、ステップ3.2.2.1：CU2はCU1からの要求に対して、新たな要求を受け入れるか、拒否するか、または別のリソース割り当てを提供することによって応答しうる。このループはステップ2.2に戻ってもよい。
・ ステップ3.3：CU1は、影響を受けるルートおよびUE/ノードについて、IABノードのルーティングテーブルを更新する。その結果、CU1経由のトラフィックが増え、CU2経由のトラフィックが減ることになる。
【0103】
オフロードされたトラフィックの一部が発信CU（例えばCU1）に戻されることに対する言及、または以前にオフロードされたトラフィックの一部を取得することは、オフロードされたトラフィックの一部のみに対する言及、またはオフロードされたトラフィックの一部のみを取得することとみなすことができる。そのため、トラフィックの「部分」または「一部」とは、以前にオフロードされたトラフィックの全量未満、すなわち以前にオフロードされたトラフィックの一部のみを意味する。
【0104】
タイマベースのポーリングまたは適応的/動的トラフィック共有のためのオンデマンドステータスチェック
【0105】
特定の実施形態によれば、複数のCUが負荷分散（トラフィックのオフロード）に関与している場合（例えば、上記のセクションの例で提供されたCU1およびCU2）、F1コネクションを有するCU（CU1）は、CU2および／またはトップレベルIABノードに対してタイマを構成しうる。このようなタイマが満了すると、ポーリングされたネットワークエンティティはトラフィックの輻輳ステータスを提供する。このステータスは、単純なフラグ（高負荷(loaded)／低負荷(unloaded)、すなわち、容量がない、容量がある）で示されうる。 あるいは、これはビットレート、つまり、トラフィックをオフロードする必要があるCU（CU1）から、新しいCU（例えばCU2）がどれだけのトラフィックを処理できるかを提供することで示すこともできる。
【0106】
事前に設定された時間ベースのポーリングに関するこのようなフィードバックに基づいて、CU1は、特定の実施形態によれば、追加のトラフィックをオフロードできるかどうか、またはCU2からトラフィックの一部を取り消す必要があるかどうかを判定する。タイマは、明示的に通知されることもあれば、負荷分散のために複数のCUが関与している場合には、暗黙のデフォルト値となることもある。
【0107】
特定の実施形態によれば、ポーリングはタイマに依存せず、CU1またはCU2がオンデマンドでステータスチェックを実行してもよい。しかし、トリガ条件が十分に規定されていない場合に複数のCU間で発生しうる過剰なシグナリングを回避するために、特定の実施形態では、そのようなステータスチェックのトリガまたはイベントを事前に設定しておくことができる。
【0108】
特定の実施形態によれば、そのようなトリガーの例は以下のものであってよい。
・ 特定の実施形態において、トップレベルIABノードのトラフィックに急激な、あるいは緩やか増加がある場合（事前に設定されたある期間に負荷が所定の閾値だけ増加した場合。トラフィック負荷の閾値は（例えば）ビットレートに関して構成することができる）。この場合、追加トラフィックをさらにCU2にオフロードする必要がある。
・ トップレベルIABノードのトラフィック負荷が（設定された所定の閾値まで）低下した場合。これは、CU1がCU2からのトラフィックの一部を取り消す機会を与えうる。
・ トップレベルノードへの／からのトラフィックを処理するCU2の親ノードのいずれかが輻輳状態になった場合（所定の期間に対して所定のマージンだけ）、またはトラフィック負荷が低下した場合（所定の期間に対して所定のマージンだけ）。
・ 特定の実施形態において、トップレベルIABノードのトラフィックに急激な、あるいは緩やか増加がある場合（事前に設定されたある期間に負荷が所定の閾値だけ増加した場合。トラフィック負荷の閾値は（例えば）ビットレートに関して構成することができる）。この場合、追加トラフィックをさらにCU2にオフロードする必要がある。
・ トップレベルIABノードのトラフィック負荷が（設定された所定の閾値まで）低下した場合。これは、CU1がCU2からのトラフィックの一部を取り消す機会を与えうる。
・ トップレベルノードへの／からのトラフィックを処理するCU2の親ノードのいずれかが輻輳状態になった場合（所定の期間に対して所定のマージンだけ）、またはトラフィック負荷が低下した場合（所定の期間に対して所定のマージンだけ）。
【0109】
特定の実施形態によれば、このようなポーリング情報の開始は、ハンドオーバ準備手順またはセカンダリノードセットアップ手順（マスタノード、セカンダリノードデュアル接続手順）の一部など、新しい軽量Xnシグナリングメッセージを使用するか、既存のシグナリングに付加することによって示すことができる。
【0110】
特定の実施形態によれば、そのようなポーリングに対する応答（例えば、トラフィック負荷ステータス応答フラグ）は、新しい軽量シグナリングメッセージである。
【0111】
図13は、いくつかの実施形態に係る通信システム100の例を示す。この例において、通信システム100は、無線アクセスネットワーク(RAN)などのアクセスネットワーク104を含む電気通信ネットワーク102と、1つ以上のコアネットワークノード108を含むコアネットワーク106とを含む。アクセスネットワーク104は、ネットワークノード110aおよび110b(そのうちの1つ以上を一般的にネットワークノード110と呼ぶことがある)、または任意の他の同様の第3世代パートナーシッププロジェクト(3GPP)アクセスノードまたは非3GPPアクセスポイントなどの、1つまたは他のアクセスネットワークノードを含む。ネットワークノード110は、1つ以上の無線コネクションを介してUE112a、112b、112c、および112d(それらのうちの1つ以上を一般的にUE112と呼ぶことがある)をコアネットワーク106に接続することなどによって、ユーザ装置(UE)の直接的または間接的コネクションを可能にする。
【0112】
無線接続を介した例示的な無線通信は、電磁波、電波、赤外線、および/または、有線、ケーブル、または他の物質導体を用いずに情報を搬送するのに適した他のタイプの信号を用いて無線信号を送信および/または受信することを含む。さらに、異なる実施形態において、通信システム100は、任意の数の有線または無線ネットワーク、ネットワークノード、UE、および／または、有線コネクションを介してか無線コネクションを介してかにかかわらずデータおよび／または信号の通信を促進し、または通信に参加し得る任意の他の構成要素またはシステムを含みうる。通信システム100は、任意の種類の通信、電気通信、データ、セルラー、無線ネットワーク、および/または他の同様の種類のシステムを含み、および/またはそれらとインターフェースしうる。
【0113】
UE112は、ネットワークノード110および他の通信装置と無線通信するように配置され、構成され、および/または動作可能な無線機器を含む、多種多様な通信装置のいずれかでありうる。同様に、ネットワークノード110は、UE112と、および/または電気通信ネットワーク102内の他のネットワークノードもしくは機器と、直接的または間接的に通信して、無線ネットワークアクセスなどのネットワークアクセスを可能にし、および／または提供し、および/または電気通信ネットワーク102内の管理などの他の機能を実行するように配置され、能力を有し、構成され、および/または動作可能である。
【0114】
図示の例では、コアネットワーク106がネットワークノード110をホスト116などの1つ以上のホストに接続する。これらのコネクションは、直接的であっても、あるいは1つ以上の中間ネットワークまたはデバイスを介した間接的なものであってもよい。他の例では、ネットワークノードがホストに直接接続されうる。コアネットワーク106は、ハードウェア構成要素およびソフトウェア構成要素で構成された1つ以上のコアネットワークノード(例えば、コアネットワークノード108)を含む。これらの構成要素の機能はUE、ネットワークノード、および/またはホストに関して説明したものと実質的に同様であってよく、したがって、それらの説明は概して、コアネットワークノード108の対応する構成要素にもあてはまる。例示的なコアネットワークノードは、移動交換局(MSC)、モビリティ管理エンティティ(MME)、ホーム加入者サーバ(HSS)、アクセスおよびモビリティ管理機能(AMF)、セッション管理機能(SMF)、認証サーバ機能(AUSF)、加入識別子隠蔽解除機能(SIDF)、統一データ管理(UDM)、セキュリティエッジ保護プロキシ(SEPP)、ネットワークエクスポージャ機能(NEF)、および/またはユーザプレーン機能(UPF)のうちの1つ以上の機能を含む。
【0115】
ホスト116は、アクセスネットワーク104および/または電気通信ネットワーク102のオペレータまたはプロバイダ以外のサービスプロバイダの所有権または制御下にあってよく、サービスプロバイダによって、またはサービスプロバイダに代わって運用されうる。ホスト116は、1つ以上のサービスを提供するために様々なアプリケーションをホストすることができる。そのようなアプリケーションの例には、ライブおよび録画済みのオーディオ/ビデオコンテンツの提供、データ収集サービス、例えば、複数のUEによって検出されたさまざまな周囲の状況に関するデータの取得および編纂、分析機能、ソーシャルメディア、リモート機器を制御し、またはその他の方法でリモート機器とやりとりするための機能、アラームおよび監視センターのための機能、またはサーバによって実行されるその他のこのような機能などが含まれる。
【0116】
全体として、図13の通信システム100は、UE、ネットワークノード、およびホスト間の接続性を実現する。その意味で、通信システムは、以下のものに限定されないが、特定の規格など、あらかじめ定義された規則や手順に従って動作するように構成することができる。移動通信用グローバルシステム(GSM)、ユニバーサル移動通信システム(UMTS)、ロングタームエボリューション(LTE)、および／または他の適切な2G、3G、4G、5G規格、または適用可能な任意の将来世代規格(例えば6G)、電気電子学会(IEEE)802.11規格(WiFi)などの無線ローカルエリアネットワーク(WLAN)規格、および／または、マイクロ波アクセスのための世界的相互運用性(WiMax)、Bluetooth、Z-Wave、近距離無線通信(NFC)、ZigBee、LiFi、および／またはLoRaやSigfoxなどの低電力広域ネットワーク(LPWAN)規格などの他の適切な無線通信標準。
【0117】
いくつかの例において、電気通信ネットワーク102は、3GPPが規格化した機能を実装するセルラーネットワークである。したがって、電気通信ネットワーク102は電気通信ネットワーク102に接続された異なる機器に異なる論理ネットワークを提供するために、ネットワークスライシングをサポートしうる。例えば、電気通信ネットワーク102は、いくつかのUEにURLLC(Ultra Reliable Low Latency Communication)サービスを提供する一方で、他のUEにeMBB(Enhanced Mobile Broadband)サービス、および/またはさらなるUEにmMTC(Massive Machine Type Communication)/Massive IoTサービスを提供しうる。
【0118】
いくつかの例では、UE112が直接的な人間の関与なしに情報を送信および/または受信するように構成されてもよい。例えば、UEは、所定のスケジュールで、内部または外部イベントによってトリガされたとき、またはアクセスネットワーク104からの要求に応答して、アクセスネットワーク104に情報を送信するように設計されてもよい。さらに、UEは、単一またはマルチRATまたはマルチスタンダードモードで動作するように構成されうる。例えば、UEはWi-Fi、NR(New Radio)、およびLTEの任意の1つまたは組合せを用いて動作することができ、すなわち、E-UTRAN(Evolved-UMTS Terrestrial Radio Access Network)New Radio-Dual Connectivity(EN-DC)などのマルチ無線デュアルココネクティビティ(MR-DC)のために構成されうる。
【0119】
この例では、ハブ114がアクセスネットワーク104と通信して、1つ以上のUE(例えばUE112cおよび/または112d)とネットワークノード(例えばネットワークノード110b)との間の間接通信を容易にする。いくつかの例において、ハブ114は、コントローラ、ルータ、コンテンツソースおよび分析、またはUEに関してここで説明される他の通信装置のいずれかでありうる。例えば、ハブ114は、UEによるコアネットワーク106へのアクセスを可能にするブロードバンドルータでありうる。別の例として、ハブ114は、UE内の1つ以上のアクチュエータにコマンドまたは命令を送るコントローラでありうる。コマンドまたは命令は、UE、ネットワークノード110から受信されてもよいし、ハブ114内の実行可能コード、スクリプト、プロセス、または他の命令によるものであってもよい。別の例として、ハブ114はUEデータのための一時記憶として働くデータコレクタであってよく、いくつかの実施形態ではデータの分析または他の処理を実行しうる。別の例として、ハブ114は、コンテンツソースでありうる。例えば、VRヘッドセット、ディスプレイ、ラウドスピーカ、または他のメディア配信デバイスであるUEについて、ハブ114はネットワークノードを介して、VRアセット、ビデオ、オーディオ、または他のメディア、または感覚情報に関連するデータを取り出すことができ、そして、ハブ114は、直接、ローカル処理を実行した後、および/または追加のローカルコンテンツを追加した後、のいずれかでUEに提供する。さらに別の例では、ハブ114は、特に1つ以上のUEが低エネルギーIoTデバイスである場合、UEのプロキシサーバまたはオーケストレータとして機能する。
【0120】
ハブ114は、ネットワークノード110bへの一定の/持続的な、または断続的なコネクションを有しうる。ハブ114はまた、ハブ114とUE(例えばUE 112cおよび/または112d)との間、およびハブ114とコアネットワーク106との間で、異なる通信方式および/またはスケジュールを可能にしうる。他の例では、ハブ114が有線コネクションを介してコアネットワーク106および/または1つ以上のUEに接続される。さらに、ハブ114はアクセスネットワーク104を介してM2Mサービスプロバイダに、および/または直接コネクションを介して別のUEに接続するように構成されうる。いくつかのシナリオでは、UEは、有線コネクションまたは無線コネクションを通じてハブ114を介して接続された状態で、ネットワークノード110との無線コネクションを確立することができる。いくつかの実施形態においてハブ114は、専用ハブ、すなわち、ネットワークノード110bからUEへ、またその逆方向に通信をルーティングすることを主な機能とするハブであってもよい。他の実施形態においてハブ114は、非専用ハブ、すなわち、UEとネットワークノード110bとの間の通信をルーティングするように動作する能力を有するが、さらに、特定のデータチャネルの通信スタートおよび/またはエンドポイントとして動作する能力を有する機器であってもよい。
【0121】
図14は、いくつかの実施形態に係るUE200を示す。本開示において、UEは、ネットワークノードおよび/または他のUEと無線通信が可能であり、無線通信するように構成され、無線通信するように配置され、および/または無線通信するように動作可能な機器を意味する。UEの非限定的な例には、スマートフォン、移動体電話、携帯電話、ボイスオーバーIP(VoIP)電話、無線ローカルループ電話、デスクトップコンピュータ、携帯情報端末(PDA)、無線カメラ、ゲーム機または機器、音楽記憶デバイス、再生機器、ウェアラブル端末機器、無線エンドポイント、移動機、タブレット、ラップトップ、ラップトップ組み込み機器(LEE)、ラップトップ搭載機器(LME)、スマートデバイス、無線カスタマープレミス機器(CPE)、車載または車両組み込み/一体型無線機器などが含まれる。他の例は、狭帯域モノのインターネット(NB-IoT)UE、マシンタイプ通信(MTC)UE、および/または拡張MTC(eMTC)UEを含む、第3世代パートナーシッププロジェクト(3GPP)によって規定される任意のUEを含む。
【0122】
UEは例えば、サイドリンク通信、専用短距離通信(DSRC)、車車間通信(V2V)、車両-インフラストラクチャ間通信(V2I)、または車とあらゆるものとの間の通信(V2X)のための3GPP規格を実装することによって、機器間(D2D)通信をサポートしうる。他の例においてUEは、関連する機器を所有し、かつ/またはそれを操作する人間のユーザという意味では必ずしもユーザを有していなくてもよい。あるいは、UEは人間のユーザへの販売または人間のユーザによる操作が意図されているが、(最初は)特定の人間のユーザに関連付けられていない機器(例えばスマートスプリンクラーコントローラ)を表しうる。あるいは、UEは、エンドユーザへの販売やエンドユーザによる操作を意図していないが、ユーザの利益に関連したり、ユーザの利益のために動作したりすることのできる機器(例えば、スマート電力メータ)を表しうる。
【0123】
UE200は、バス204を介して入力/出力インターフェース206、電源208、メモリ210、通信インターフェース212、および/または任意の他の構成要素、またはそれらの任意の組合せに動作可能に接続される処理回路202を含む。特定のUEは、図14に示す構成要素のすべてまたはサブセットを利用しうる。構成要素間の統合レベルは、UEごとに異なってもよい。さらに、あるUEは、複数のプロセッサ、複数のメモリ、複数の送受信器、複数の送信器、複数の受信器など、構成要素の複数のインスタンスを含みうる。
【0124】
処理回路202は、命令およびデータを処理するように構成され、メモリ210内に機械可読コンピュータプログラムとして格納された命令を実行するように動作可能な任意の順次状態機械を実施するように構成されうる。処理回路202は、(例えば、ディスクリートロジック、フィールドプログラマブルゲートアレイ(FPGA)、特定用途向け集積回路(ASIC)などに)ハードウェアで実施される1つ以上の状態機械、適切なファームウェアとプログラマブルロジックとの組み合わせ、1つ以上の保存されたコンピュータプログラム、マイクロプロセッサまたはデジタル信号プロセッサ(DSP)などの汎用プロセッサと適切なソフトウェアとの組み合わせ、あるいはこれらの任意の組み合わせとして実装されうる。例えば、処理回路202は、複数の中央処理装置(CPU)を含むことができる。
【0125】
この例では、入力/出力インターフェース206が、入力デバイス、出力デバイス、または1つ以上の入力および/または出力デバイスにインターフェースを提供するように構成されうる。出力デバイスの例は、スピーカ、サウンドカード、ビデオカード、ディスプレイ、モニタ、プリンタ、アクチュエータ、エミッタ、スマートカード、別の出力デバイス、またはそれらの任意の組合せを含む。入力デバイスは、ユーザがUE200に情報を取り込むことを可能にしうる。入力デバイスの例には、タッチセンシティブまたはプレゼンスセンシティブディスプレイ、カメラ(例えば、デジタルカメラ、デジタルビデオカメラ、ウェブカメラなど)、マイクロフォン、センサ、マウス、トラックボール、方向キー、トラックパッド、スクロールホイール、スマートカードなどが含まれる。プレゼンスセンシティブディスプレイは、ユーザからの入力を感知するために、容量性または抵抗性タッチセンサを含んでもよい。センサは例えば、加速度計、ジャイロスコープ、傾斜センサ、力センサ、磁力計、光センサ、近接センサ、生体センサなど、またはそれらの任意の組合せでありうる。出力デバイスは、入力デバイスと同じタイプのインタフェースポートを使用できる。例えば、ユニバーサルシリアルバス(USB)ポートは、入力デバイスおよび出力デバイスを提供するために使用されうる。
【0126】
いくつかの実施形態では、電源208がバッテリまたはバッテリパックとして構成される。外部電源(例えば、電気コンセント)、光起電力デバイス、または電力セルなどの他のタイプの電源を使用することができる。電源208は電源208それ自体、および/または外部電源から、入力回路または電力ケーブルなどのインタフェースを介して、UE200の種々の部分に電力を送達するための電力回路をさらに含みうる。送電は例えば、電源208の充電のためのものであってもよい。電力回路は電力が供給されるUE200のそれぞれの構成要素に適した電力を作るために、電源208からの電力に対する任意のフォーマット化、変換、または他の修正を実行しうる。
【0127】
メモリ210は、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、プログラマブル読み出し専用メモリ(PROM)、消去可能プログラマブル読み出し専用メモリ(EPROM)、電気的消去可能プログラマブル読み出し専用メモリ(EEPROM)、磁気ディスク、光ディスク、フロッピーディスク(登録商標)、ハードディスク、リムーバブルカートリッジ、またはフラッシュドライブなどのメモリを含むように構成されうる。一例では、メモリ210が、オペレーティングシステム、ウェブブラウザアプリケーション、ウィジェット、ガジェットエンジン、または他のアプリケーションなどの1つ以上のアプリケーションプログラム214と、対応するデータ216とを含む。メモリ210は、UE200が使用するために、様々なオペレーティングシステムのうちのいずれか、またはオペレーティングシステムの組合せを記憶しうる。
【0128】
メモリ210は、独立ディスク冗長アレイ(RAID)、フラッシュメモリ、USBフラッシュドライブ、外部ハードディスクドライブ、サムドライブ、ペンドライブ、キードライブ、高密度デジタル多用途ディスク(HD-DVD)光ディスクドライブ、内部ハードディスクドライブ、ブルーレイ光ディスクドライブ、ホログラフィックデジタルデータストレージ(HDDS)光ディスクドライブ、外部ミニデュアルインラインメモリモジュール(DIMM)、同期ダイナミックランダムアクセスメモリ(SDRAM)、外部マイクロDIMM SDRAM、USIMおよび/またはISIMなどの1つ以上の加入者識別モジュール(SIM)を含むユニバーサル集積回路カード(UICC)の形態の耐タンパ性モジュールなどのスマートカードメモリ、または他のメモリの任意の組合せなど、いくつかの物理ドライブユニットを含むように構成されうる。UICCは、例えば、組み込み型UICC（eUICC）、統合型UICC（iUICC）、または一般に「SIMカード」として知られる取り外し可能なUICCであってよい。メモリ210は、UE200が、一過性または非一過性の記憶媒体に格納された命令、アプリケーションプログラムなどにアクセスしたり、データをオフロードしたり、データをアップロードしたりすることを可能にしうる。通信システムを利用するものなどの製品は、メモリ210として、またはメモリ210内で、有形物として具現化されてよく、メモリ210は、装置読み取り可能な記憶媒体であっても、装置読み取り可能な記憶媒体を含んでもよい。
【0129】
処理回路202は、通信インターフェース212を用いてアクセスネットワークまたは他のネットワークと通信するように構成されうる。通信インターフェース212は、1つ以上の通信サブシステムを有することができ、さらにアンテナ222を含みうるか、アンテナ222に通信可能に接続されうる。通信インターフェース212は、無線通信が可能な別の機器(例えば、アクセスネットワーク内の別のUEまたはネットワークノード)の1つ以上のリモート送受信器と通信することなどによって通信のために用いられる、1つ以上の送受信器を含みうる。各送受信器はネットワーク通信(例えば、光、電気、周波数割り当てなど)を提供するのに適した送信器218および/または受信器220を含みうる。さらに、送信器218および受信器220は、1つ以上のアンテナ(例えば、アンテナ222)に接続されてよく、また、回路構成要素、ソフトウェアまたはファームウェアを共有してもよいし、別個に実装されてもよい。
【0130】
図示した実施形態では、通信インターフェース212の通信機能が、セルラ通信、Wi-Fi通信、LPWAN通信、データ通信、音声通信、マルチメディア通信、Bluetoothなどの近距離通信、近接通信、測位するための全地球測位システム(GPS)の使用などの位置ベースの通信、別の同様の通信機能、またはそれらの任意の組合せを含みうる。通信は、IEEE802.11、符号分割多元アクセス(CDMA)、広帯域符号分割多元接続(WCDMA(登録商標))、GSM(登録商標)、LTE、ニューラジオ(NR)、UMTS、WiMax、イーサネット(登録商標)、伝送制御プロトコル/インターネットプロトコル(TCP/IP)、同期光ネットワーキング(SONET)、非同期転送モード(ATM)、QUIC、ハイパーテキスト転送プロトコル(HTTP)などの1つ以上の通信プロトコルおよび/または規格に従って実施されうる。
【0131】
センサのタイプにかかわらず、UEは、自身のセンサで取得したデータの出力を、自身の通信インタフェース212およびネットワークノードへの無線コネクションを通じて提供しうる。UEのセンサによって取得したデータは、無線コネクションを通じ、別のUEを経由してネットワークノードへ通信されてもよい。出力は、定期的(例えば、感知された温度を報告する場合は15分ごとに1回)、ランダム(例えば、複数のセンサからの報告による負荷を均等にするため)、トリガイベントに応答して(例えば、水分が検出されると警告が送信される)、要求(例えば、ユーザが開始した要求)に応答して、または連続ストリーミング(例えば、患者のライブビデオフィード)であってよい。
【0132】
別の例として、UEは、無線コネクションを通じてネットワークノードから無線入力を受信するように構成された通信インターフェースに関連するアクチュエータ、モータ、またはスイッチを有する。受信した無線入力に応答して、アクチュエータ、モータ、またはスイッチの状態が変化しうる。例えば、UEは、受信した入力に従って飛行中のドローンの操縦翼面やローターを調整したり、受信した入力に従って医療処置を行うロボットアームを制御したりするモータを有しうる。
【0133】
UEは、モノのインターネット(IoT)機器の形態を有する場合、1つまたは複数のアプリケーション領域で使用するための機器であってよく、これらの領域には、都市ウェアラブル技術、拡張産業アプリケーションおよびヘルスケアなどが含まれるが、これらに限定されない。このようなIoT機器の非限定的な例には、以下のような機器、または以下のような機器に組み込まれる機器が含まれる。インターネットに接続された冷蔵庫または冷凍庫、テレビ、インターネットに接続された照明装置、電力メータ、ロボット掃除機、音声制御スマートスピーカ、ホームセキュリティカメラ、人感センサー、サーモスタット、煙探知機、ドア/窓センサー、洪水/湿度センサ、電気ドアロック、インターネットに接続された呼び鈴、ヒートポンプのような空調システム、自律走行車、監視システム、天候監視装置、車両駐車監視装置、電気自動車充電ステーション、スマートウォッチ、フィットネストラッカー、拡張現実(AR)または仮想現実(VR)用ヘッドマウントディスプレイ、触覚増強または感覚増強用ウェアラブル、散水器、動物またはアイテム追跡装置、植物または動物を監視するセンサ、産業用ロボット、無人航空機(UAV)、心拍数モニタおゆおよび遠隔操作手術ロボットのようなあらゆる種類の医療機器。IoT機器の形態を有するUEは、図14に示したUE200について説明されるような他の構成要素に加えて、IoT機器の意図する用途に応じた回路および/またはソフトウェアを有する。
【0134】
さらに別の具体例として、IoTシナリオでは、UEが、監視および／または測定などを実行し、そのような監視および／または測定などの結果を別のUEおよび／またはネットワークノードに送信する機械または他の機器を表しうる。UEはこの場合、M2M機器であってよく、3GPPの文脈ではMTC機器と呼ばれうる。1つの特定の例として、UEは、3GPP NB-IoT規格を実装しうる。他のシナリオにおいて、UEは、自動車、バス、トラック、船舶および航空機などの乗り物、あるいは、自身の動作状態または自身の動作に関連する他の機能を監視および/または報告する能力を有する他の機器を表しうる。
【0135】
実際には、任意の数のUEが単一のユースケースに関してまとめてに使用されうる。例えば、第1のUEはドローンであるかドローンと一体化されてもよく、(速度センサを介して取得した)ドローンの速度情報を、ドローンを操作するリモートコントローラである第2のUEに提供してもよい。ユーザがリモートコントローラから変更を行うと、第1のUEはドローンの速度を増加または減少させるために、(例えば、アクチュエータを制御することによって)ドローンのスロットルを調整することができる。第1および/または第2のUEはまた、上述した機能の2つ以上を含みうる。例えば、UEは、センサおよびアクチュエータを有し、速度センサおよびアクチュエータの両方のためのデータの通信を処理することができる。
【0136】
図15は、いくつかの実施形態に係るネットワークノード300を示す。本開示において、ネットワークノードは、電気通信ネットワークにおいて、UEと、および/または他のネットワークノードまたは装置と、直接的または間接的に通信する能力を有する、通信するように構成された、通信するように配置された、および/または通信するように動作可能な装置を意味する。ネットワークノードの非限定的な例には、アクセスポイント(AP)(例えば、無線アクセスポイント)、基地局(BS)(例えば、無線基地局、ノードB、進化型ノードB(eNB)およびNRノードB(gNB))が含まれる。
【0137】
基地局は、提供するカバレージの大きさ(別の言い方をすれば、送信電力レベル)に基づいて分類されうる結果、提供するカバレージの大きさに応じて、フェムト基地局、ピコ基地局、マイクロ基地局、またはマクロ基地局と呼ばれうる。基地局は、中継を制御するリレーノードまたはリレードナーノードであってもよい。ネットワークノードはまた、遠隔無線ヘッド(RRH)と呼ばれることもある、集中デジタルユニットおよび/または遠隔無線ユニット(RRU)などの分散型無線基地局の1つ以上の(またはすべての)部分を含みうる。このような遠隔無線ユニットは、アンテナ一体型無線機としてアンテナと一体化されてもよいし、アンテナと一体化されなくてもよい。分散型無線基地局の一部は、分散アンテナシステム(DAS)においてノードと呼ばれることもある。
【0138】
ネットワークノードの他の例には、マルチ送信ポイント(マルチTRP)5Gアクセスノード、MSR BSなどのマルチ標準無線(MSR)装置、無線ネットワーク制御装置(RNC)や基地局制御装置(BSC)などのネットワーク制御装置、ベース送受信局(BTS)、送信ポイント、送信ノード、マルチセル/マルチキャスト調整エンティティ(MCE)、運用保守(O&M)ノード、運用サポートシステム(OSS)ノード、自己組織化ネットワーク(SON)ノード、測位ノード(例えば進化型サービングモバイルロケーションセンター(E-SMLC)など)、および/または最小化ドライブテスト(MDT)が含まれる。
【0139】
ネットワークノード300は、処理回路302、メモリ304、通信インターフェース306、および電源308を含む。ネットワークノード300は、それぞれが個別の構成要素を有しうる物理的に分離された複数の構成要素(例えば、NodeB構成要素とRNC構成要素、またはBTS構成要素とBSC構成要素など)で構成されてもよい。ネットワークノード300が複数の別個の構成要素(例えば、BTSおよびBSC構成要素)を含む特定のシナリオでは、1つ以上の別個の構成要素が複数のネットワークノード間で共有されてもよい。例えば、単一のRNCが複数のノードBを制御してもよい。このようなシナリオでは、ノードBとRNCとのユニークな組み合わせが1つの独立したネットワークノードと見なされうる。いくつかの実施形態においてネットワークノード300は、複数の無線アクセス技術(RAT)をサポートするように構成されうる。そのような実施形態では、いくつかの構成要素は重複しうる(例えば、異なるRATについて別個のメモリ304)一方、いくつかの構成要素は再利用されうる(例えば、同じアンテナ310が異なるRATによって共有されうる)。ネットワークノード300は、ネットワークノード300に統合された様々な無線技術、例えばGSM、WCDMA(登録商標)、LTE、NR、WiFi、Zigbee、Z-wave、LoRaWAN、RFID(Radio Frequency Identification)またはBluetooth無線技術に対応する様々な図示の構成要素の複数のセットを含みうる。これらの無線技術は、ネットワークノード300内で同じまたは異なったチップまたはチップセットおよび他の構成要素に統合されてもよい。
【0140】
処理回路302は、単体で、あるいはメモリ304のような他のネットワーク300の構成要素とともにネットワークノード300の機能を提供するために動作可能な、マイクロプロセッサ、コントローラ、マイクロコントローラ、中央処理装置、デジタル信号プロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、または他の任意の適切なコンピューティングデバイスの1つ以上の組み合わせ、リソース、またはハードウェア、ソフトウェアおよび/またはコード化されたロジックの組み合わせを有しうる。
【0141】
いくつかの実施形態では、処理回路302がシステムオンチップ(SOC)を含む。いくつかの実施形態では、処理回路302が無線周波数(RF)送受信器回路312およびベースバンド処理回路314の1つ以上を含む。いくつかの実施形態で、無線周波数(RF)トランシーバ回路312およびベースバンド処理回路314は、無線ユニットおよびデジタルユニットなどの、別個のチップ(またはチップセット)、基板、またはユニットに存在しうる。代替的な実施形態で、無線周波数トランシーバ回路312およびベースバンド処理回路314の一部または全部は、同一のチップに、あるいは、チップ、基板、またはユニットのセットに存在しうる。
【0142】
メモリ304は、永続記憶装置、半導体メモリ、、リモートマウントメモリ、磁気媒体、光媒体、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、マスストレージメディア(例えば、ハードディスク)、リムーバブルストレージメディア(例えば、フラッシュドライブ、コンパクトディスク(CD)またはデジタルビデオディスク(DVD))、および/または、処理回路302によって使用されうる情報、データ、および/または命令を格納する任意の他の揮発性または不揮発性、非一時的機器可読および／またはコンピュータ実行可能なメモリデバイスを非限定的に含む、任意の形態の揮発性または不揮発性のコンピュータ可読メモリを有しうる。メモリ304は、コンピュータプログラム、ソフトウェア、処理回路302によって実行され、ネットワークノード300によって利用されることが可能なロジック、ルール、コード、テーブル、および/または他の命令の1つ以上を含むアプリケーション、を含む、任意の適切な命令、データ、または情報を格納することができる。メモリ304は、処理回路302によって行われる任意の計算、および/または通信インターフェース306を介して受信される任意のデータを格納するために使用されうる。いくつかの実施形態では、処理回路302とメモリ304とは一体化される。
【0143】
通信インターフェース306は、ネットワークノード、アクセスネットワーク、および/またはUE間のシグナリングおよび/またはデータの有線または無線通信に用いられる。図示するように、通信インターフェース306は、(例えば有線コネクションを通じてネットワークとの間で)データを送信および受信するための(1つ以上の)ポート/端子316を有する。通信インターフェース306はまた、アンテナ310に接続され、あるいはある実施形態ではアンテナ1010の一部であってよい無線フロントエンド回路318を含む。無線フロントエンド回路318は、フィルタ320および増幅器322を有する。無線フロントエンド回路318は、アンテナ310および処理回路302に接続されうる。無線フロントエンド回路は、アンテナ310と処理回路302との間で通信される信号を調整するように構成されうる。無線フロントエンド回路318は、無線コネクションを介して他のネットワークノードまたはUEに送出されるデジタルデータを受信することができる。無線フロントエンド回路318は、フィルタ320および/または増幅器322の組合せを用いて、デジタルデータを適切なチャネルおよび帯域幅パラメータを有する無線信号に変換しうる。次いで、無線信号は、アンテナ310を介して送信されうる。同様に、データを受信するとき、アンテナ310は、無線フロントエンド回路318によってデジタルデータに変換される無線信号を収集することができる。デジタルデータは処理回路302に渡されてよい。他の実施形態で、通信インタフェースは、別の構成要素および/または構成要素の別の組合せを有しうる。
【0144】
特定の代替実施形態では、ネットワークノード300が別個の無線フロントエンド回路318を含まず、代わりに、処理回路302が無線フロントエンド回路を含み、アンテナ310に接続される。同様に、いくつかの実施形態では、RF送受信器回路312の全部または一部が通信インターフェース306の一部である。さらに他の実施形態では、通信インターフェース306が無線ユニット(不図示)の一部として、1つ以上のポートまたは端子316と、無線フロントエンド回路318と、RF送受信器回路312とを含み、通信インターフェース306はデジタルユニット(不図示)の一部であるベースバンド処理回路314と通信する。
【0145】
アンテナ310は、無線信号を送信および/または受信するように構成された1つ以上のアンテナ、またはアンテナアレイを含みうる。アンテナ310は、無線フロントエンド回路318と接続されてよく、データおよび/または信号を無線送信および受信することが可能な任意のタイプのアンテナであってよい。ある実施形態では、アンテナ310がネットワークノード300とは別個であり、インターフェースまたはポートを介してネットワークノード300に接続可能である。
【0146】
アンテナ310、通信インターフェース306、および/または処理回路302は、ネットワークノードによって実行されるものとして説明する任意の受信動作および/またはいくつかの取得動作を実行するように構成されうる。任意の情報、データおよび/または信号は、UE、他のネットワークノードおよび/または任意の他のネットワーク機器から受信されてもよい。同様に、アンテナ310、通信インターフェース306、および/または処理回路302は、ネットワークノードによって実行されるものとして説明する任意の送信動作を実行するように構成されうる。任意の情報、データおよび/または信号は、UE、他のネットワークノードおよび/または任意の他のネットワーク機器に送信されてもよい。
【0147】
電源308は、それぞれの構成要素に適した形態で(例えば、それぞれの構成要素に必要な電圧および電流レベルで)、ネットワークノード300の様々な構成要素に電力を提供する。電源308は、ここで説明する機能を実行するための電力をネットワークノード300の構成要素に供給するための電力管理回路をさらに有してもよいし、電力管理回路に接続されてもよい。例えば、ネットワークノード300は電気ケーブルなどの入力回路またはインターフェースを通じて外部電源(例えば、電力グリッド、電気コンセント)に接続可能であってよく、それによって、外部電源は、電源308の電力回路に電力を供給する。さらなる例として、電源308は、電力回路に接続されるか電力回路と一体化される、バッテリまたはバッテリパックの形態の電源を有しうる。外部電源に障害が発生した場合、バッテリはバックアップ電源を提供しうる。
【0148】
ネットワークノード300の実施形態は、ここで説明される機能のいずれか、および/またはここで説明される主題をサポートするために必要な任意の機能を含む、ネットワークノードの機能のいくつかの態様を提供するための、図15に示されない追加の構成要素を含みうる。例えば、ネットワークノード300は、ネットワークノード300への情報の入力を可能にし、またネットワークノード300からの情報の出力を可能にするユーザインターフェース装置を含むことができる。これにより、ユーザは、ネットワークノード300の診断、保守、修理、および他の管理機能を実行することができる。
【0149】
図16は、ここで説明する様々な態様に係る、図13のホスト116の一実施形態であってもよいホスト400のブロック図である。ここで、ホスト400は、スタンドアロンサーバ、ブレードサーバ、クラウド実装サーバ、分散サーバ、仮想マシン、コンテナ、またはサーバファーム内の処理リソースを含む、ハードウェアおよび/またはソフトウェアの様々な組合せであってもよく、また様々な組み合わせを有してもよい。ホスト400は、1つ以上のサービスを1つ以上のUEに提供することができる。
【0150】
ホスト400は、バス404を介して入力/出力インターフェース406、ネットワークインタフェース408、電源410、メモリ412に動作可能に接続される処理回路402を含む。他の実施形態では他の構成要素が含まれうる。これらの構成要素の機能は図2および3など先の図に関して説明したものと実質的に同様であってよく、したがって、それらの説明は概して、ホスト400の対応する構成要素にもあてはまる。
【0151】
メモリ412は、1つ以上のホストアプリケーションプログラム414と、例えばホスト400のためにUEによって生成されたデータまたはUEのためにホスト400によって生成されたデータであるユーザデータを含みうるデータ416とを含む、1つ以上のコンピュータプログラムを含みうる。ホスト400の実施形態は、図示されている構成要素のサブセットのみ、あるいは全部を利用することができる。ホストアプリケーションプログラム414はコンテナベースのアーキテクチャで実施されてよく、複数の異なるクラス、タイプ、またはUEの実装(例えば、ハンドセット、デスクトップコンピュータ、ウェアラブルディスプレイシステム、ヘッドアップディスプレイシステム）のためのトランスコーディングを含む、ビデオコーデック(例えば、バーサタイルビデオコーディング(VVC)、高効率ビデオコーディング(HEVC)、アドバンストビデオコーディング(AVC)、MPEG、VP9)およびオーディオコーデック(例えば、FLAC、アドバンストオーディオコーディング(AAC)、MPEG、G.711)のサポートを提供することができる。ホストアプリケーションプログラム414はまた、ユーザ認証およびライセンスチェックを提供することができ、コアネットワーク内の、またはコアネットワークのエッジ上の機器などの中央ノードに、健全性、ルート、およびコンテンツ利用可能性を定期的に報告することができる。したがって、ホスト400は、UEのためのオーバーザトップサービスのための別のホストを選択および/または示すことができる。ホストアプリケーションプログラム414は、HTTPライブストリーミング(HLS)プロトコル、リアルタイムメッセージングプロトコル(RTMP)、リアルタイムストリーミングプロトコル(RTSP)、動的適応ストリーミングオーバーHTTP(MPEG-DASH)などの様々なプロトコルをサポートしうる。
【0152】
図17は、いくつかの実施形態によって実施される機能が仮想化されうる仮想化環境500を示すブロック図である。
【0153】
本文脈において仮想化とは、ハードウェアプラットフォーム、ストレージデバイス、ネットワークリソースを仮想化することを含みうる、装置または機器の仮想バージョンを作成することを意味する。ここで、仮想化は、ここで説明される任意の機器またはその構成要素に適用することができ、機能の少なくとも一部が1つ以上の仮想構成要素として実装されるような実装に関する。ここで説明される機能の一部または全部は、ネットワークノード、UE、コアネットワークノード、またはホストとして動作するハードウェアコンピューティングデバイスなどのハードウェアノードの1つまたは複数によってホストされる、1つまたは複数の仮想環境500に実装される1つまたは複数の仮想マシン(VM)によって実行される仮想コンポーネントとして実装されうる。さらに、仮想ノードが無線接続性(例えば、コアネットワークノードまたはホスト)を必要としない実施形態では、ノードは完全に仮想化されうる。
【0154】
アプリケーション502(代替的に、ソフトウェアインスタンス、仮想アプライアンス、ネットワーク機能、仮想ノード、仮想ネットワーク機能などと呼ばれうる)は、ここで開示される実施形態のいくつかの特徴、機能、および/または利点のいくつかを実施するために、仮想化環境Q400で実行される。
【0155】
ハードウェア504は、処理回路、ハードウェア処理回路によって実行可能なソフトウェアおよび/または命令を格納するメモリ、および/または、ネットワークインターフェース、入力/出力インターフェースなど、ここで説明する他のハードウェアデバイスを含む。ソフトウェアは処理回路によって実行されることができ、それにより、1つ以上の仮想化レイヤ506(ハイパーバイザまたは仮想マシンモニタ(VMM)とも呼ばれる)をインスタンス化し、VM508aおよび508b(1つ以上をVM508と総称することがある)を提供し、および/またはここで説明するいくつかの実施形態に関連して説明する機能、特徴および/または利点のいずれかを実行しうる。仮想化レイヤ506は、VM508にはネットワークハードウェアのように見える仮想オペレーティングプラットフォームを提示することができる。
【0156】
VM508は、仮想処理、仮想メモリ、仮想ネットワークワーキングまたはインターフェース、および仮想ストレージを有し、対応する仮想化レイヤ506によって実行されうる。仮想アプライアンス502のインスタンスの様々な実施形態は、VM508の1つ以上に実装されてよく、実装は様々な方法で行われうる。ハードウェアの仮想化は、文脈によってはネットワーク機能仮想化(NFV)と呼ばれる。NFVは、多くのネットワーク装置タイプを、データセンタに存在しうる業界標準の大容量サーバーハードウェア、物理スイッチ、および物理ストレージ、およびカスタマープレミス装置に統合するために使用されうる。
【0157】
NFVの文脈において、VM508は、あたかも物理的な仮想化されていないマシンで稼働しているかのようにプログラムを実行する物理マシンのソフトウェア実装であってよい。VM508の各々、およびそのVMを実行するハードウェア504の一部(そのVM専用のハードウェアおよび/またはそのVMが他のVMと共有するハードウェア)は、別々の仮想ネットワーク要素を形成する。またNFVの文脈において、仮想ネットワーク機能はハードウェア504上の1つ以上のVM508で稼働し、アプリケーション502に対応する特定のネットワーク機能を処理する役割を担う。
【0158】
ハードウェア504は、汎用または特定の構成要素を有するスタンドアロンネットワークノードに実装されうる。ハードウェア504は、仮想化を用いていくつかの機能を実施することができる。あるいは、ハードウェア504は、多くのハードウェアノードが協働し、特にアプリケーション502のライフサイクル管理を監督する管理およびオーケストレーション510を用いて管理される、ハードウェアのより大きなクラスタ(例えば、データセンターまたはCPE内など)の一部であってよい。いくつかの実施形態では、各々が、1つ以上のアンテナに接続されうる1つ以上の送信器と1つ以上の受信器とを含む1つ以上の無線ユニットに、ハードウェア504が接続される。無線ユニットは、1つ以上の適切なネットワークインターフェースを介して他のハードウェアノードと直接通信してよく、無線機能を有する仮想ノード(無線アクセスノードや基地局など)を提供するために仮想コンポーネントと組み合わせて用いられうる。いくつかの実施形態では、いくつかのシグナリングが、ハードウェアノードと無線ユニットとの間の通信のために代替的に使用され得る制御システム512を用いて提供されうる。
【0159】
図18は、いくつかの実施形態に係る、一部が無線である接続を通じ、ネットワークノード604を介してUE606と通信するホスト602の通信ダイヤグラムを示す。
【0160】
様々な実施形態に係る、先の段落で説明した(図12のUE112aおよび/または図13のUE200などの)UE、(図13のネットワークノード110aおよび/または図15のネットワークノード300などの)ネットワークノード、および(図13のホスト116および/または図16のホスト400などの)ホストの実装例について、図18を参照しながら説明する。
【0161】
ホスト400と同様、ホスト602の実施形態は、通信インターフェース、処理回路、およびメモリなどのハードウェアを含む。ホスト602は、ホスト602に格納されるか、ホスト602がアクセス可能で、処理回路によって実行可能なソフトウェアをさらに含む。ソフトウェアは、UE606とホスト602との間に延びるオーバーザトップ(OTT)コネクション650を介して接続するUE606のようなリモートユーザにサービスを提供するように動作可能なホストアプリケーションを含む。サービスをリモートユーザに提供する際に、ホストアプリケーションは、OTTコネクション650を用いて送信されるユーザデータを提供することができる。
【0162】
ネットワークノード604は、ネットワークノード604がホスト602およびUE606と通信することを可能にするハードウェアを含む。コネクション660は、直接的なものであってもよいし、(図13のコアネットワーク106のような)コアネットワークおよび/または1つ以上の公衆、プライベート、もしくはホステッドネットワークなどの1つ以上の他の中間ネットワークを通るものであってもよい。例えば、中間ネットワークは、バックボーンネットワークまたはインターネットであってもよい。
【0163】
UE606は、UE606に格納されるか、UE606がアクセス可能で、処理回路によって実行可能なソフトウェアを含む。ソフトウェアは、ホスト602のサポートにより、UE606を介して人間または人間以外のユーザにサービスを提供するように動作可能であってよい、ウェブブラウザやオペレータ固有”アプリ”などのクライアントアプリケーションを含む。ホスト602において、稼働中のホストアプリケーションは、UE606およびホスト602で終端するOTTコネクション650を介して、稼働中のクライアントアプリケーションと通信することができる。サービスをユーザに提供する際に、UEのクライアントアプリケーションは、ホストのホストアプリケーションから要求データを受信し、要求データに応答してユーザデータを提供してもよい。OTTコネクション650は、要求データおよびユーザデータの両方を転送することができる。UEのクライアントアプリケーションは、OTTコネクション650を通じてホストアプリケーションに提供するユーザデータを生成するためにユーザとやりとりすることができる。
【0164】
OTTコネクション650は、ホスト602とUE606との間のコネクションを提供するために、ホスト602とネットワークノード604との間のコネクション660およびネットワークノード604とUE606との間の無線コネクション670を介して延びることができる。OTTコネクション650が提供されうるコネクション660および無線コネクション670は、ネットワークノード604を介したホスト602とUE606との間の通信を説明するために抽象的に描かれており、中間装置やこれらの装置を介したメッセージの正確なルーティングについては明示的に示されていない。
【0165】
OTTコネクション650を介してデータを送信する例として、ステップ608において、ホスト602はユーザデータを提供する。これは、ホストアプリケーションを実行することによって達成されうる。いくつかの実施形態では、ユーザデータがUE606とやりとりする特定の人間のユーザに関連付けられる。他の実施形態では、明示的な人間とのやりとりなしに、ホスト602とデータを共有するUE606にユーザデータが関連付けられる。ステップ610において、ホスト602は、ユーザデータをUE606に搬送する送信を開始する。ホスト602は、UE606によって送信された要求に応答して送信を開始してもよい。要求は、UE606と人間とのやりとり、またはUE606で実行されるクライアントアプリケーションの動作に起因するものであってよい。送信は、本開示全体にわたって説明される実施形態の教示に従って、ネットワークノード604を介して渡されうる。したがって、ステップ612において、ネットワークノード604は、本開示全体にわたって説明される実施形態の教示に従って、ホスト602が開始した送信において搬送されたユーザデータをUE606に送信する。ステップ614で、UE606は送信によって搬送されるユーザデータを受信する。この受信は、ホスト602によって実行されるホストアプリケーションに関連づけられた、UE606で実行されるクライアントアプリケーションによって実行されてもよい。
【0166】
いくつかの例において、UE606は、ユーザデータをホスト602に提供するクライアントアプリケーションを実行する。ユーザデータは、ホスト602から受信したデータに反応して、または応答して提供されうる。したがって、ステップ616においてUE606はユーザデータを提供してよく、ユーザデータの提供はクライアントアプリケーションを実行することによって達成されてもよい。ユーザデータを提供する際に、クライアントアプリケーションは、UE606の入力/出力インタフェースを通じてユーザから受け取ったユーザ入力をさらに考慮してもよい。ユーザデータが供給された具体的な方法にかかわらず、UE606は、ステップ618で、ネットワークノード604を介してホスト602へ向かうユーザデータの送信を開始する。ステップ620において、本開示全体にわたって説明される実施形態の教示に従って、ネットワークノード604はUE606からユーザデータを受信し、受信したユーザデータのホスト602に向けた送信を開始する。ステップ622において、ホスト602は、UE606によって開始された送信で搬送されるユーザデータを受信する。
【0167】
様々な実施形態のうちの1つ以上は、無線コネクション670が最後のセグメントを形成するOTTコネクション650を使用して、UE606に提供されるOTTサービスの性能を改善する。より正確には、これらの実施形態の教示は、例えばデータレート、レイテンシ、および/または電力消費の1つ以上を改善する可能性があり、それによって、例えばユーザ待機時間の短縮、ファイルサイズの制限緩和、コンテンツ解像度の改善、より良好な応答性、および/またはバッテリ寿命の延長などの利点を提供することができる。
【0168】
例示的なシナリオでは、工場ステータス情報がホスト602によって収集され、分析されうる。別の例として、ホスト602は、地図の作成で用いるためにUEから読み出されたオーディオおよびビデオデータを処理することができる。別の例として、ホスト602は交通渋滞の制御(例えば、信号機の制御)を支援するために、リアルタイムデータを収集し、分析することができる。別の例として、ホスト602は、UEによってアップロードされた監視映像を保存することができる。別の例として、ホスト602は、UEにブロードキャスト、マルチキャスト、またはユニキャストすることができるビデオ、オーディオ、VR、またはARなどのメディアコンテンツを保存したり、それらへのアクセスを制御したりすることができる。他の例として、エネルギー価格設定、発電ニーズのバランスをとるための緊急性のない電力負荷の遠隔制御、位置情報サービス、プレゼンテーションサービス(遠隔装置から収集したデータから図などを編纂するなど)、またはデータの収集、検索、保存、分析および/または送信の他の機能に、ホスト602を用いることができる。
【0169】
いくつかの例において、データレート、レイテンシ、および1つ以上の実施形態が改善する他のネットワーク動作態様を監視するために測定手順が提供されてもよい。さらに、測定結果の変動に応答して、ホスト602とUE606との間のOTTコネクション650を再構成するためのオプションネットワーク機能があってもよい。OTTコネクションを再構成するための測定手順および／またはネットワーク機能は、ホスト602および/またはUE606のソフトウェアおよびハードウェアで実施することができる。いくつかの実施形態において、OTTコネクション650が経由する他の機器の中または他の機器に付随してセンサ（図示せず）を設けることができ、センサは、先に例示した監視量の値を供給することによって、またはソフトウェアが監視量を計算または推定しうる他の物理量の値を供給することによって、測定手順に参加することができる。OTTコネクション650の再構成は、メッセージフォーマット、再送信設定、優先ルーティングなどを含むことができ、再構成は、ネットワークノード604の動作を直接変更する必要はない。このような手順および機能は当技術分野で公知かつ実践されているであろう。特定の実施形態では、計測は、ホスト602によるスループット、伝搬時間、レイテンシなどの測定を容易にする独自のUEシグナリングを伴ってもよい。測定は、ソフトウェアが伝搬時間、エラーなどを監視しながら、OTT接続650を使用して、メッセージ、特に空または「ダミー」メッセージを送信させることによって実施することができる。
【0170】
ここで説明するコンピューティングデバイス(例えば、UE、ネットワークノード、ホスト)はハードウェア構成要素の図示された組合せを含みうるが、他の実施形態は構成要素の組合せが異なるコンピューティングデバイスを有しうる。これらのコンピューティングデバイスは、ここに開示されたタスク、特徴、機能、および方法を実行するために必要なハードウェアおよび/またはソフトウェアの任意の適切な組み合わせを有しうることを理解されたい。ここで説明する決定、計算、取得、または同様の動作は、処理回路によって実行されてもよく、処理回路は、例えば、取得された情報を他の情報に変換し、取得された情報または変換された情報をネットワークノードに格納された情報と比較し、および/または取得された情報または変換された情報に基づいて1つ以上の動作を実行することによって、情報を処理し、当該処理の結果として決定を下すことができる。さらに、構成要素は、より大きなボックス内に位置する単一のボックスとして、または複数のボックス内に入れ子になって描かれているが、実際には、コンピューティングデバイスは、単一の図示された構成要素を構成する複数の異なる物理構成要素を有することができ、機能は、別個の構成要素に分割されうる。例えば、通信インターフェースはここで説明する構成要素のいずれかを含むように構成されてもよいし、および/または構成要素の機能が処理回路と通信インターフェースとに分割されてもよい。別の例では、このような構成要素のいずれかの、計算負荷の高くない機能はソフトウェアまたはファームウェアに実装されてよく、計算負荷の高い機能はハードウェアに実装されてよい。
【0171】
特定の実施形態では、ここで説明した機能の一部または全部は、メモリに格納された命令を実行する処理回路によって提供されてもよく、このメモリは、特定の実施形態では、非一時的コンピュータ可読記憶媒体の形態を有するコンピュータプログラム製品であってよい。代替的な実施形態では、機能の一部または全部は、別個または個別の機器可読記憶媒体に格納された命令を実行することなく、ハードワイヤード方式などによって処理回路が提供してもよい。これらの特定の実施形態のいずれにおいても、非一時的コンピュータ可読記憶媒体に格納された命令を実行するかどうかにかかわらず、処理回路は、説明された機能を実行するように構成されうる。このような機能によって提供される利点は、処理回路単体、またはコンピューティングデバイスの他の構成要素に限らず、コンピューティングデバイス全体、および/またはエンドユーザと無線ネットワークによって広く享受される。
【0172】
図19は、特定の実施形態に係る、IABネットワークのCU1による方法700を示す図である。 方法によれば、ステップ702でCU1は、CU2に第1のメッセージを送信し、またはCU2から第1のメッセージを受信する。 第1のメッセージには、オフロードされたトラフィックの一部をCU1に戻すことを示す情報が含まれる。 オフロードされたトラフィックは、以前にCU1からCU2にオフロードされたものである。
【0173】
特定の実施形態では、第1のメッセージを送信する前に、CU1は、オフロードされたトラフィックを最初のCU1からCU2にオフロードする。
【0174】
特定の実施形態では、オフロードされたトラフィックは、移行IABノードで終端される。
【0175】
特定の実施形態では、CU1は、以前にCU1からCU2にオフロードされたトラフィックの部分を受信する。
【0176】
特定の実施形態では、CU1はF1終端ノードを有し、CU2はF1非終端ノードを有する。
【0177】
特定の実施形態では、第1のメッセージは、オフロードされたトラフィックのうち、CU1に戻される部分に関連するトラフィック量を示す。
【0178】
特定の実施形態では、CU1は、第1のメッセージを送信する前に、オフロードされたトラフィックのうちCU1に戻される部分を処理する能力をCU1が有することを判定する。
【0179】
特定の実施形態では、CU1は、条件が満たされたことを判定し、条件が満たされたことを判定したことに応答して、第1のメッセージがCU2に送信され、条件は、タイマが満了したと判定したこと、ターゲットドナーノードにおけるトラフィック負荷の増加を識別したこと、ターゲットドナーノードにおけるトラフィックが閾値量より増加したことを識別したこと、ソースドナーノードにおけるトラフィック負荷の減少を識別したこと、およびソースドナーノードにおけるトラフィックが閾値量より減少したことを識別したことのうちの少なくとも1つを含む。
【0180】
特定の実施形態では、CU1は、CU2によって解放されるべき少なくとも1つのリソースを示す第2のメッセージをCU2から受信する。
【0181】
特定の実施形態では、CU2からの第1のメッセージは、オフロードされたトラフィックの一部をCU1に戻すことを開始し、方法は、オフロードされたトラフィックの一部がCU1に戻されていることを判定する第2のメッセージをCU2に送信することを含む。
【0182】
特定の実施形態では、第1のメッセージは、オフロードされたトラフィックのうち、CU1に戻される部分に関連付けられた、少なくとも1つの許可されたリソースを示す。
【0183】
特定の実施形態において、少なくとも1つの許可されたリソースは、ダウンリンクリソース、および／または、アップリンクリソースのうちの少なくとも1つを含む。
【0184】
特定の実施形態では、CU1は、少なくとも1つのIABノードに、オフロードされたトラフィックのうち、CU1に戻される部分に関連する情報を送信する。
【0185】
別の特定の実施形態では、少なくとも1つのIABノードに送信される情報はルーティングテーブルを含む。
【0186】
図20は、特定の実施形態に係る、IABネットワークのCU2による方法800を示す図である。方法によれば、802でCU2は、CU1に第1のメッセージを送信し、またはCU1から第1のメッセージを受信する。 第1のメッセージは、オフロードされたトラフィックの一部がCU1に戻されることを示す情報を含み、オフロードされたトラフィックは以前にCU1からCU2にオフロードされたものである。
【0187】
特定の実施形態では、第1のメッセージを送信または受信する前に、CU2はオフロードされたトラフィックを受信する。
【0188】
別の特定の実施形態では、オフロードされたトラフィックは、移行IABノードで終端される。
【0189】
特定の実施形態では、CU1はF1終端ノードを有し、CU2はF1非終端ノードを有する。
【0190】
特定の実施形態では、第1のメッセージは、オフロードされたトラフィックのうち、CU1に戻される部分に関連するトラフィック量を示す。
【0191】
特定の実施形態では、CU2は、オフロードされたトラフィックのうちCU1に戻される部分を処理する能力をCU2が有しないことを判定する。
【0192】
特定の実施形態では、CU2は条件が満たされたことを判定し、条件が満たされたことを判定したことに応答して、第1のメッセージがCU1に送信される。条件は以下の少なくとも1つを含む。 タイマが満了したと判定したこと、ターゲットドナーノードにおけるトラフィック負荷の増加を識別したこと、ターゲットドナーノードにおけるトラフィックが閾値量より増加したことを識別したこと、ソースドナーノードにおけるトラフィック負荷の減少を識別したこと、およびソースドナーノードにおけるトラフィックが閾値量より減少したことを識別したこと。
【0193】
特定の実施形態では、CU2は、CU2によって解放されるべき少なくとも1つのリソースを示す第2のメッセージをCU1から受信する。
【0194】
特定の実施形態では、CU1から第1のメッセージを受信することが、オフロードされたトラフィックの一部がCU1に戻されることを開始し、CU2は、オフロードされたトラフィックの一部がCU1に戻されていることを判定する第2のメッセージをCU1に送信する。
【0195】
特定の実施形態では、第1のメッセージは、オフロードされたトラフィックのうち、CU1に戻される部分に関連付けられた、少なくとも1つの許可されたリソースを示す。
【0196】
特定の実施形態において、少なくとも1つの許可されたリソースは、ダウンリンクリソース、および／または、アップリンクリソースのうちの少なくとも1つを含む。
【0197】
特定の実施形態では、CU2は、少なくとも1つのIABノードに、オフロードされたトラフィックのうち、CU1に戻される部分に関連する情報を送信する。
【0198】
別の特定の実施形態では、少なくとも1つのIABノードに送信される情報はルーティングテーブルを含む。
【0199】
例示的な実施形態
グループAの例示的な実施形態
グループAの例示的な実施形態
【0200】
例示的実施形態A1 統合アクセスおよびバックホール（IAB）ネットワークにおける一時的および／または適応的な負荷分散のための、ユーザ機器による方法であって、上述したユーザ機器のステップ、特徴、または機能のいずれかを単独で、または上述した他のステップ、特徴、または機能との組み合わせで有する、方法。
【0201】
例示的実施形態A2 先の実施形態の方法であって、上述した1つ以上の追加的なユーザ機器のステップ、特徴または機能をさらに含む、方法。
【0202】
例示的実施形態A3 ユーザデータを提供することと、ネットワークノードへの伝送を通じて前記ユーザデータをホストコンピュータに転送することと、をさらに含む、先の実施形態のいずれかの方法。
【0203】
グループBの例示的な実施形態
【0204】
例示的実施形態B1 統合アクセスおよびバックホール（IAB）ネットワークにおける一時的および／または適応的な負荷分散のための、ネットワークノードによって実行される方法であって、上述したユーザ機器のステップ、特徴、または機能のいずれかを単独で、または上述した他のステップ、特徴、または機能との組み合わせで有する、方法。
【0205】
例示的実施形態B2 先の実施形態の方法であって、上述した1つ以上の追加的なネットワークノードのステップ、特徴または機能をさらに含む、方法。
【0206】
例示的実施形態B3 先の実施形態のいずれかの方法であって、 ユーザデータを取得することと、前記ユーザデータをホストまたはユーザ装置に転送することと、をさらに含む、方法。
【0207】
グループCの例示的な実施形態
【0208】
例示的実施形態C1 統合アクセスおよびバックホール（IAB）ネットワークにおける一時的および／または適応的な負荷分散のためのソースドナーノードによる方法であって、前記ソースドナーノードからオフロードされるべきトラフィックおよび／またはターゲットドナーノードからオフロードされるべきトラフィックを決定することと、前記ソースドナーノードからオフロードされるべき前記トラフィックおよび／または前記ターゲットドナーノードからオフロードされるべき前記トラフィックに関連する情報を前記ターゲットドナーノードに送信することと、を含む、方法。
【0209】
例示的実施形態C2 前記トラフィックが移行IABノードに関連するものである、例示的実施形態C1の方法。
【0210】
例示的実施形態C3 前記トラフィックは、前記ソースドナーノードから前記ターゲットドナーノードへのオフロードのために決定される、例示的実施形態C1からC2のいずれか1つの方法。
【0211】
例示的実施形態C4 前記ソースドナーノードから前記ターゲットドナーノードへオフロードされるべき前記トラフィックを前記ソースドナーノードが処理できないことを判定することをさらに含む、例示的実施形態C3の方法。
【0212】
例示的実施形態C5 前記ソースドナーノードから前記ターゲットノードへのオフロードのために前記ソースドナーノードが処理できないトラフィック量を決定することをさらに含み、前記情報が、前記ソースドナーノードから前記ターゲットドナーノードへのオフロードのための前記トラフィック量を示す、例示的実施形態C3からC4のいずれか1つの方法。
【0213】
例示的実施形態C6 前記情報は、前記ソースノードから前記ターゲットノードへオフロードされるべき前記トラフィックのための少なくとも1つの要求されたリソースを含む、例示的実施形態C3からC5の方法。
【0214】
例示的実施形態C7 前記少なくとも1つの要求されたリソースは、ダウンリンクリソース、および／または、アップリンクリソースのうちの少なくとも1つを含む、例示的実施形態C6の方法。
【0215】
例示的実施形態C8 前記ターゲットドナーノードから、少なくとも1つの許可されたリソースを示す応答メッセージを受信することをさらに含む、例示的実施形態C5からC7のいずれか1つの方法。
【0216】
例示的実施形態C9 前記少なくとも1つの許可されたリソースは、前記ターゲットドナーノードに送信された前記情報に示された少なくとも1つの要求されたリソースを含む、例示的実施形態C8の方法。
【0217】
例示的実施形態C10 前記少なくとも1つの許可されたリソースは、前記ターゲットドナーノードに送信された前記情報で要求されたリソースを含まない、例示的実施形態C8の方法。
【0218】
例示的実施形態C11 前記ターゲットドナーノードから、前記ターゲットドナーノードから利用可能なリソースがないことを示す応答メッセージを受信することをさらに含む、例示的実施形態C5からC7のいずれか1つの方法。
【0219】
例示的実施形態C12 前記トラフィックを前記ターゲットドナーノードにオフロードすることをさらに含む、例示的実施形態C3からC11のいずれか1つの方法。
【0220】
例示的実施形態C13 少なくとも1つのIABノードに、前記ターゲットドナーノードにオフロードされるべき前記トラフィックに関連する情報を送信することをさらに含む、例示的実施形態C3からC12のいずれか1つの方法。
【0221】
例示的実施形態C14 前記少なくとも1つのIABノードに送信される前記情報がルーティングテーブルを含む、例示的実施形態C13の方法。
【0222】
例示的実施形態C15 前記トラフィックは、前記ターゲットドナーノードから前記ソースドナーノードへのオフロードのために決定される、例示的実施形態C1からC2のいずれか1つの方法。
【0223】
例示的実施形態C16 前記ターゲットドナーノードから前記ソースドナーノードへオフロードされるべきトラフィックは、以前に前記ソースドナーノードから前記ターゲットドナーノードにオフロードされたトラフィックを含む、例示的実施形態C15の方法。
【0224】
例示的実施形態C17 前記ソースドナーノードが、前記ターゲットドナーノードから前記ソースドナーノードへオフロードされる前記トラフィックを処理できることを判定することをさらに含む、例示的実施形態C15からC16のいずれか1つの方法。
【0225】
例示的実施形態C18 前記ターゲットドナーノードから前記ソースドナーノードへのオフロードのためのトラフィック量を示すメッセージを前記ターゲットドナーノードから受信することをさらに含む、例示的実施形態C15からC17のいずれか1つの方法。
【0226】
例示的実施形態C19 前記ターゲットドナーノードから送信される前記情報が、前記ターゲットドナーノードから前記ソースドナーノードへオフロードされる前記トラフィックに関連する、少なくとも1つの許可されたリソースを示す、例示的実施形態C15からC18のいずれか1つの方法。
【0227】
例示的実施形態C20 前記少なくとも1つの許可されたリソースは、ダウンリンクリソース、および／または、アップリンクリソースのうちの少なくとも1つを含む、例示的実施形態C119の方法。
【0228】
例示的実施形態C21 前記ターゲットドナーノードから、前記ターゲットドナーノードによって解放されるべき1つ以上の解放リソースを示す応答メッセージを受信することをさらに含む、例示的実施形態C15からC20のいずれか1つの方法。
【0229】
例示的実施形態C22 前記少なくとも1つの解放リソースは、前記ターゲットドナーノードに送信された前記情報で特定される前記少なくとも1つの許可されたリソースを含む、例示的実施形態C21の方法。
【0230】
例示的実施形態C23 前記少なくとも1つの解放リソースは、前記ターゲットドナーノードに送信された前記情報で特定される許可されたリソースを含まない、例示的実施形態C21の方法。
【0231】
例示的実施形態C24 前記ターゲットドナーノードから、前記ターゲットドナーノードによって解放されるべきリソースがないことを示す応答メッセージを受信することをさらに含む、例示的実施形態C15からC20のいずれか1つの方法。
【0232】
例示的実施形態C25 記ターゲットドナーノードから前記ソースドナーノードへオフロードされる前記トラフィックの少なくとも一部を受信することをさらに含む、例示的実施形態C15からC23のいずれか1つの方法。
【0233】
例示的実施形態C26 少なくとも1つのIABノードに、前記ターゲットドナーノードから前記ソースドナーノードにオフロードされる前記トラフィックに関連する情報を送信することをさらに含む、例示的実施形態C15からC25のいずれか1つの方法。
【0234】
例示的実施形態C27 前記少なくとも1つのIABノードに送信される前記情報がルーティングテーブルを含む、例示的実施形態C26の方法。
【0235】
例示的実施形態C28 前記ソースドナーノードによってタイマを維持することをさらに含み、前記決定するステップは、前記タイマが満了すると実行される、例示的実施形態C1からC27のいずれか1つの方法。
【0236】
例示的実施形態C29 前記ソースドナーノードによってタイマを維持することをさらに含み、前記情報は前記タイマが満了すると前記ターゲットドナーノードに送信される、例示的実施形態C1からC28のいずれか1つの方法。
【0237】
例示的実施形態C30 前記ターゲットドナーノードに送信される前記情報は、前記ターゲットドナーノードからオフロードされる前記トラフィックおよび/または前記ソースドナーノードから前記ターゲットドナーノードにオフロードされる前記トラフィックを、前記ソースドナーノードが処理する能力を有するか否かを示すトラフィック輻輳ステータスを含む、例示的実施形態C1からC29のいずれか1つの方法。
【0238】
例示的実施形態C31 前記ソースドナーノードによってタイマを維持することをさらに含み、前記トラフィック輻輳ステータスは前記タイマが満了すると前記ターゲットドナーノードに送信される、例示的実施形態C30の方法。
【0239】
例示的実施形態C32 条件が満たされたことを判定することをさらに含み、前記条件が満たされたことを判定したことに応答して、前記トラフィック輻輳ステータスが前記ターゲットドナーノードに送信される、例示的実施形態C30の方法。
【0240】
例示的実施形態C33 前記条件は、トラフィック負荷の増加を識別したこと、トラフィックが閾値を超えて増加したことを識別したこと、トラフィック負荷の減少を識別したこと、およびトラフィックが閾値を超えて減少したことを識別したこと、の少なくとも1つを含む、例示的実施形態C32の方法。
【0241】
例示的実施形態C34 前記ターゲットドナーノードからトラフィック輻輳ステータスを受信することをさらに含み、前記トラフィック輻輳ステータスは、前記ソースドナーノードからオフロードされるべきトラフィックおよび/または前記ターゲットドナーノードから前記ソースドナーノードにオフロードされるべき前記トラフィックを、前記ターゲットドナーノードが処理する能力を有するか否かを示す、例示的実施形態C1からC33のいずれか1つの方法。
【0242】
例示的実施形態C35 前記ターゲットドナーノードに、前記ターゲットドナーノードの前記トラフィック輻輳ステータスの要求を送信することをさらに含む、例示的実施形態C34の方法。
【0243】
例示的実施形態C36 タイマを維持することをさらに含み、前記トラフィック輻輳ステータスの前記要求は前記タイマが満了すると前記ターゲットドナーノードに送信される、例示的実施形態C35の方法。
【0244】
例示的実施形態C37 前記トラフィック輻輳ステータスは、前記ソースドナーノードおよび／または前記ターゲットドナーノードが処理する能力を有するトラフィック量を示す、例示的実施形態C30からC36のいずれか1つの方法。
【0245】
例示的実施形態C38 例示的実施形態C1からC37のいずれか1つの方法であって、さらに、 ユーザデータを提供することと、前記ネットワークノードへの送信を介してホストに前記ユーザデータを転送することと、を含む、方法。
【0246】
例示的実施形態C39 例示的実施形態C1からC38のいずれかの方法を実行するように構成された処理回路を有するソースドナーノード。
【0247】
例示的実施形態C40 例示的実施形態C1からC38の方法のいずれかを実行するように構成されたソースドナーノード。
【0248】
例示的実施形態C41 コンピュータで実行されると、例示的実施形態C1からC38のいずれかの方法を実行する命令を含むコンピュータプログラム。
【0249】
例示的実施形態C42 コンピュータプログラム有するをコンピュータプログラム製品であって、前記コンピュータプログラムは、コンピュータで実行されると、例示的実施形態C1からC38のいずれかの方法を実行する命令を含む、コンピュータプログラム製品。
【0250】
例示的実施形態C43 コンピュータで実行されると、例示的実施形態C1からC38のいずれかの方法を実行する命令を格納する非一時的コンピュータ可読媒体。
【0251】
グループDの例示的な実施形態
【0252】
例示的実施形態D1 統合アクセスおよびバックホール（IAB）ネットワークにおける一時的および／または適応的な負荷分散のためのターゲットドナーノードによる方法であって、前記ターゲットドナーノードからオフロードされるべきトラフィックおよび／またはソースドナーノードからオフロードされるべきトラフィックを決定することと、前記ターゲットドナーノードからオフロードされるべき前記トラフィックおよび／または前記ソースドナーノードからオフロードされるべき前記トラフィックに関連する情報を前記ソースドナーノードに送信することと、を含む、方法。
【0253】
例示的実施形態D2 前記トラフィックが移行IABノードに関連するものである、例示的実施形態D1の方法。
【0254】
例示的実施形態D3 前記トラフィックは、前記ソースドナーノードから前記ターゲットドナーノードへのオフロードのために決定される、例示的実施形態D1からD2のいずれか1つの方法。
【0255】
例示的実施形態D4 前記ソースドナーノードからオフロードされるべき前記トラフィックを決定することは、前記ソースドナーノードから要求を受信することを含み、前記要求は、前記ソースドナーノードからオフロードされるべきトラフィックの量を特定する、例示的実施形態D3の方法。
【0256】
例示的実施形態D5 前記ソースドナーノードからオフロードされるべき前記トラフィックを前記ターゲットドナーノードが処理できることを判定することをさらに含む、例示的実施形態D3からD4の方法。
【0257】
例示的実施形態D6 前記ソースドナーノードから前記ターゲットノードへのオフロードのために前記ターゲットドナーノードが処理できるトラフィック量を決定することをさらに含み、前記情報が、前記ソースドナーノードから前記ターゲットドナーノードへのオフロードのために前記ターゲットドナーノードが処理できる前記トラフィック量を示す、例示的実施形態D3からD5のいずれか1つの方法。
【0258】
例示的実施形態D7 前記情報は、前記ソースノードから前記ターゲットノードへオフロードされるべき前記トラフィックのための少なくとも1つの許可されたリソースを含む、例示的実施形態D3からD6のいずれか1つの方法。
【0259】
例示的実施形態D8 前記少なくとも1つの許可されたリソースは、ダウンリンクリソース、および／または、アップリンクリソースのうちの少なくとも1つを含む、例示的実施形態D7の方法。
【0260】
例示的実施形態D9 前記ソースドナーノードから、前記少なくとも1つの許可されたリソースを受け入れる応答メッセージを受信することをさらに含む、例示的実施形態D7からD8のいずれか1つの方法。
【0261】
例示的実施形態D10 前記ソースドナーノードから、前記ソースドナーノードが前記トラフィックを前記ターゲットドナーノードにオフロードすることを必要としないことを示す応答メッセージを受信することをさらに含む、例示的実施形態D7からD8のいずれか1つの方法。
【0262】
例示的実施形態D11 記ターゲットドナーノードにオフロードされる前記トラフィックの少なくとも一部を受信することをさらに含む、例示的実施形態D3からD10のいずれか1つの方法。
【0263】
例示的実施形態D12 少なくとも1つのIABノードに、前記ターゲットドナーノードにオフロードされるべき前記トラフィックに関連する情報を送信することをさらに含む、例示的実施形態D3からD11のいずれか1つの方法。
【0264】
例示的実施形態D13 前記少なくとも1つのIABノードに送信される前記情報がルーティングテーブルを含む、例示的実施形態D12の方法。
【0265】
例示的実施形態D14 前記トラフィックは、前記ターゲットドナーノードから前記ソースドナーノードへのオフロードのために決定される、例示的実施形態D1からD2のいずれか1つの方法。
【0266】
例示的実施形態D15 前記ターゲットドナーノードからオフロードされるべき前記トラフィックを決定することは、前記ソースドナーノードが前記ターゲットドナーノードからオフロードされるべき前記トラフィックを処理可能であることを示すメッセージを前記ソースドナーノードから受信することを含む、例示的実施形態D14の方法。
【0267】
例示的実施形態D16前記ソースドナーノードからの前記メッセージは、前記ソースドナーノードが処理可能な前記トラフィックの量を示す、例示的実施形態D15の方法。
【0268】
例示的実施形態D17 前記ターゲットドナーノードからオフロードされるべき前記トラフィックを前記ターゲットドナーノードが処理できないことを判定することをさらに含む、例示的実施形態D14からD16の方法。
【0269】
例示的実施形態D18 前記ターゲットドナーノードから前記ソースノードへのオフロードのためのトラフィック量を決定することをさらに含み、前記情報が、前記ターゲットドナーノードから前記ソースドナーノードへのオフロードのための前記トラフィック量を示す、例示的実施形態D14からD17のいずれか1つの方法。
【0270】
例示的実施形態D19 前記ターゲットドナーノードから前記ソースドナーノードへオフロードされるべき前記トラフィックは、以前に前記ソースドナーノードから前記ターゲットドナーノードにオフロードされたトラフィックを含む、例示的実施形態D14からD18のいずれか1つの方法。
【0271】
例示的実施形態D20 前記情報は、前記ターゲットドナーノードから前記ソースノードへオフロードされるべき前記トラフィックに関連する少なくとも1つの解放されたリソースを示す、例示的実施形態D14からD19のいずれか1つの方法。
【0272】
例示的実施形態D21 前記少なくとも1つの解放されたリソースは、ダウンリンクリソース、および／または、アップリンクリソースのうちの少なくとも1つを含む、例示的実施形態D20の方法。
【0273】
例示的実施形態D22 前記ターゲットドナーノードから前記ソースドナーノードへオフロードされるべき前記トラフィックに関連する少なくとも1つの許可されたリソースを示す応答メッセージを、前記ソースドナーノードから受信することをさらに含む、例示的実施形態D20からD22のいずれか1つの方法。
【0274】
例示的実施形態D23 前記応答メッセージ内の前記少なくとも1つの許可されたリソースは、前記ソースドナーノードに送信された前記情報で特定される前記少なくとも1つの解放されたリソースを含む、例示的実施形態D22の方法。
【0275】
例示的実施形態D24前記応答メッセージ内の前記少なくとも1つの許可されたリソースは、前記ターゲットドナーノードによって前記ソースネットワークノードに送信された前記情報で特定される前記解放されたリソースを含まない、例示的実施形態D22の方法。
【0276】
例示的実施形態D25 前記ソースドナーノードから、前記ソースドナーノードによって受け入れられるべきリソースがないことを示す応答メッセージを受信することをさらに含む、例示的実施形態D20からD21のいずれか1つの方法。
【0277】
例示的実施形態D26 前記ソースドナーノードに前記トラフィックの少なくとも一部をオフロードすることをさらに含む、例示的実施形態D14からD25のいずれか1つの方法。
【0278】
例示的実施形態D27 少なくとも1つのIABノードに、前記ターゲットドナーノードから前記ソースドナーノードにオフロードされるべき前記トラフィックに関連する情報を送信することをさらに含む、例示的実施形態D14からD26のいずれか1つの方法。
【0279】
例示的実施形態D28 前記少なくとも1つのIABノードに送信される前記情報がルーティングテーブルを含む、例示的実施形態D27の方法。
【0280】
例示的実施形態D29 前記ターゲットドナーノードによってタイマを維持することをさらに含み、前記決定するステップは、前記タイマが満了すると実行される、例示的実施形態D1からD28のいずれか1つの方法。
【0281】
例示的実施形態D30 前記ターゲットドナーノードによってタイマを維持することをさらに含み、前記情報は前記タイマが満了すると前記ソースドナーノードに送信される、例示的実施形態D1からD29のいずれか1つの方法。
【0282】
例示的実施形態D31 前記ソースドナーノードに送信される前記情報は、前記ソースドナーノードからオフロードされるべき前記トラフィックおよび/または前記ターゲットドナーノードから前記ソースドナーノードにオフロードされるべき前記トラフィックを、前記ターゲットドナーノードが処理する能力を有するか否かを示すトラフィック輻輳ステータスを含む、例示的実施形態D1からD30のいずれか1つの方法。
【0283】
例示的実施形態D32 前記ターゲットドナーノードによってタイマを維持することをさらに含み、前記トラフィック輻輳ステータスは前記タイマが満了すると前記ソースドナーノードに送信される、例示的実施形態D31の方法。
【0284】
例示的実施形態D33 条件が満たされたことを判定することをさらに含み、前記条件が満たされたことを判定したことに応答して、前記トラフィック輻輳ステータスが前記ソースドナーノードに送信される、例示的実施形態D31の方法。
【0285】
例示的実施形態D34 前記条件は、トラフィック負荷の増加を識別したこと、トラフィックが閾値を超えて増加したことを識別したこと、トラフィック負荷の減少を識別したこと、およびトラフィックが閾値を超えて減少したことを識別したこと、の少なくとも1つを含む、例示的実施形態D33の方法。
【0286】
例示的実施形態D35 前記ソースドナーノードからトラフィック輻輳ステータスを受信することをさらに含み、前記トラフィック輻輳ステータスは、前記ソースドナーノードから前記ターゲットドナーノードにオフロードされるべきトラフィックおよび/または前記ターゲットドナーノードから前記ソースドナーノードにオフロードされるべき前記トラフィックを、前記ソースドナーノードが処理する能力を有するか否かを示す、例示的実施形態D1からD34のいずれか1つの方法。
【0287】
例示的実施形態D36 前記ソースドナーノードに、前記ソースドナーノードの前記トラフィック輻輳ステータスの要求を送信することをさらに含む、例示的実施形態D35の方法。
【0288】
例示的実施形態D37 タイマを維持することをさらに含み、前記トラフィック輻輳ステータスの前記要求は前記タイマが満了すると前記ソースドナーノードに送信される、例示的実施形態D36の方法。
【0289】
例示的実施形態D38 前記トラフィック輻輳ステータスは、前記ソースドナーノードおよび／または前記ターゲットドナーノードが処理する能力を有するトラフィック量を示す、例示的実施形態D31からD37のいずれか1つの方法。
【0290】
例示的実施形態D39 ユーザデータを提供することと、ネットワークノードへの伝送を通じて前記ユーザデータをホストに転送することと、をさらに含む、例示的実施形態D1からD38のいずれか1つの方法。
【0291】
例示的実施形態D40 例示的実施形態D1からD39のいずれかの方法を実行するように構成された処理回路を有するターゲットドナーノード。
【0292】
例示的実施形態D41 例示的実施形態D1からD39の方法のいずれかを実行するように構成されたターゲットドナーノード。
【0293】
例示的実施形態D42 コンピュータで実行されると、例示的実施形態D1からD39のいずれかの方法を実行する命令を含むコンピュータプログラム。
【0294】
例示的実施形態D43 コンピュータプログラムを有するコンピュータプログラム製品であって、前記コンピュータプログラムは、コンピュータで実行されると、例示的実施形態D1からD39のいずれかの方法を実行する命令を含む、コンピュータプログラム製品。
【0295】
例示的実施形態D44 コンピュータで実行されると、例示的実施形態D1からD39のいずれかの方法を実行する命令を格納する非一時的コンピュータ可読媒体。
【0296】
グループEの例示的な実施形態
【0297】
例示的実施形態E1 統合アクセスおよびバックホール（IAB）ネットワークにおける一時的および／または適応的負荷分散のためのネットワークノードであって、グループAおよびBの例示的実施形態のいずれかの前記ステップのいずれかを実行するように構成された処理回路と、前記処理回路に電力を供給するように構成された電源回路と、を有する、ネットワークノード。
【0298】
例示的実施形態E2 オーバーザトップ(OTT)サービスを提供するために通信システムで動作するように構成されたホストであって、ユーザデータを提供するように構成された処理回路と、ユーザ装置(UE)への送信のためにセルラネットワーク内のネットワークノードへ前記ユーザデータの送信を開始するように構成されたネットワークインターフェースとを有し、前記ネットワークノードが通信インターフェースおよび処理回路を有し、前記ネットワークノードの前記処理回路は、前記ユーザデータを前記ホストから前記UEに送信するために、グループAおよびBの例示的実施形態のいずれかの任意の動作を実行するように構成される、ホスト。
【0299】
例示的実施形態E3 先の例示的実施形態のホストであって、 前記ホストの前記処理回路は前記ユーザデータを提供するホストアプリケーションを実行するように構成され、前記UEは、前記ホストからのユーザデータの前記送信を受信するために、前記ホストアプリケーションに関連付けられたクライアントアプリケーションを実行するように構成された処理回路を有する、ホスト。
【0300】
例示的実施形態E4 ネットワークノードとユーザ機器（UE）をさらに含む通信システムで動作するように構成されたホストで実施される方法であって、ユーザデータを前記UEに提供することと、前記ネットワークノードを有するセルラネットワークを介してUEに前記ユーザデータを搬送する送信を開始することと、を有し、前記ネットワークノードは、前記ホストから前記UEに前記ユーザデータを送信するために、グループAおよびBの例示的実施形態のいずれかの任意の動作を実行する、方法。
【0301】
例示的実施形態E5 先の例示的実施形態の方法であって、
前記ネットワークノードにおいて、前記UEのために前記ホストによって提供されたユーザデータを送信することをさらに有する、方法。
前記ネットワークノードにおいて、前記UEのために前記ホストによって提供されたユーザデータを送信することをさらに有する、方法。
【0302】
例示的実施形態E6 先の2つの例示的実施形態のいずれかの方法であって、前記ユーザデータは前記UEで稼働するクライアントアプリケーションとやり取りするホストアプリケーションを実行することによってホストで提供され、前記クライアントアプリケーションは前記ホストアプリケーションに関連付けられている、方法。
【0303】
例示的実施形態E7 オーバーザトップサービスを提供するように構成された通信システムであって、前記通信システムはホストを有し、前記ホストは、ユーザ装置(UE)のためのユーザデータを提供するように構成された処理回路と、ここで前記ユーザデータは前記オーバーザトップサービスに関連付けられており、前記UEへの送信のためにセルラネットワークへ向けて前記ユーザデータの送信を開始するように構成されたネットワークインターフェースとを有し、前記ネットワークノードが通信インターフェースおよび処理回路を有し、前記ネットワークノードの前記処理回路は、前記ユーザデータを前記ホストから前記UEに送信するために、グループAおよびBの実施形態のいずれかの任意の動作を実行するように構成されている、通信システム。
【0304】
例示的実施形態E8 さらに、前記ネットワークノードおよび／または前記ユーザ機器を有する、先の例示的実施形態の通信システム。
【0305】
例示的実施形態E9 オーバーザトップ(OTT)サービスを提供するために通信システムで動作するように構成されたホストであって、ユーザデータの受信を開始するように構成された処理回路と、セルラネットワーク内のネットワークノードから前記ユーザデータを受信するように構成されたネットワークインターフェースとを有し、前記ネットワークノードが通信インターフェースおよび処理回路を有し、前記ネットワークノードの前記処理回路は、前記ユーザデータを前記ホストのためにユーザ機器(UE)から受信するために、グループAおよびBの例示的実施形態のいずれかの任意の動作を実行するように構成される、ホスト。
【0306】
例示的実施形態E10 前記ホストの前記処理回路はホストアプリケーションを実行するように構成され、それによって前記ユーザデータを提供し、前記ホストアプリケーションは、前記UEで稼働するクライアントアプリケーションとやり取りするように構成され、前記クライアントアプリケーションは前記ホストアプリケーションに関連付けられている、先の2つの例示的実施形態のホスト。
【0307】
例示的実施形態E11 前記ユーザデータの受信を前記開始することは、前記ユーザデータを要求することを含む、先の2つの実施形態のホスト。
【0308】
例示的実施形態E12 ネットワークノードとユーザ機器（UE）をさらに含む通信システムで動作するように構成されたホストによって実施される方法であって、前記ホストで、前記UEからユーザデータの受信を開始することを含み、ここで前記ユーザデータは前記ネットワークノードが前記UEから受信した伝送を起源とするものであり、前記ネットワークノードは、前記ホストのために前記UEから前記ユーザデータを受信するために、グループAおよびBの例示的実施形態のいずれかの任意の動作を実行する、方法。
【0309】
例示的実施形態E13 前記ネットワークノードにおいて、前記受信したユーザデータを前記ホストに送信することをさらに含む、先の例示的実施形態の方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【手続補正書】
【提出日】2024-03-08
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
統合アクセスおよびバックホール(IAB)ネットワークにおける第1のセントラルユニット(CU1)による方法であって、第1のメッセージを第2のCU(CU2)に送信すること、または前記CU2から第1のメッセージを受信すること、を有し、
前記第1のメッセージは、オフロードされたトラフィックの一部が前記CU1に戻されるべきであることを示す情報を有し、
前記オフロードされたトラフィックは、以前に前記CU1から前記CU2にオフロードされたものである、方法。
【請求項2】
請求項1に記載の方法であって、前記第1のメッセージを送信する前に、前記オフロードされたトラフィックを前記CU1から前記CU2にオフロードすることを有する、方法。
【請求項3】
前記オフロードされたトラフィックは、移行IABノードで終端される、請求項2に記載の方法。
【請求項4】
以前に前記CU1から前記CU2にオフロードされた前記オフロードされたトラフィックの前記一部を受信することをさらに有する、請求項1に記載の方法。
【請求項5】
請求項1に記載の方法であって、前記CU1はF1終端ノードを有し、
前記CU2はF1非終端ノードを有する、方法。
【請求項6】
前記第1のメッセージは、前記オフロードされたトラフィックの前記CU1に戻される前記一部に関連するトラフィック量を示す、請求項1に記載の方法。
【請求項7】
前記オフロードされたトラフィックの前記CU1に戻される前記一部を処理する能力を前記CU1が有することを判定することをさらに有する、請求項1に記載の方法。
【請求項8】
請求項1に記載の方法であって、条件が満たされたと判定することをさらに含み、前記第1のメッセージは前記条件が満たされたと判定されたことに応答して前記CU2に送信され、前記条件は、タイマーが満了したと判定したこと、
前記CU2でのトラフィック負荷の増加を特定したこと、
前記CU2でのトラフィックが閾値を超えて増加したことを特定したこと、
前記CU1でのトラフィック負荷の減少を特定したこと、および
前記CU1のトラフィックが閾値を超えて減少したことを特定したこと、の1つ以上を含む、方法。
【請求項9】
前記CU2から、前記CU2によって解放されるべき1つ以上のリソースを示す第2のメッセージを受信することをさらに含む、請求項7に記載の方法。
【請求項10】
前記第1のメッセージは、前記オフロードされたトラフィックの前記CU1に戻されるべき前記一部に関連する少なくとも1つの許可されたリソースを示す、請求項1に記載の方法。
【請求項11】
前記オフロードされたトラフィックの前記CU1に戻されるべき前記一部に関連する情報を、少なくとも1つのIABノードに送信することをさらに含む、請求項1に記載の方法。
【請求項12】
前記少なくとも1つのIABノードに送信される前記情報がルーティングテーブルを含む、請求項11に記載の方法。
【請求項13】
統合アクセスおよびバックホール(IAB)ネットワークにおける第2のセントラルユニット(CU2)による方法であって、第1のメッセージをCU1に送信すること、または前記CU1から第1のメッセージを受信すること、を有し、
前記第1のメッセージは、オフロードされたトラフィックの一部が前記CU1に戻されるべきであることを示す情報を有し、
前記オフロードされたトラフィックは、以前に前記CU1から前記CU2にオフロードされたものである、方法。
【請求項14】
請求項13に記載の方法であって、前記CU1はF1終端ノードを有し、
前記CU2はF1非終端ノードを有する、方法。
【請求項15】
前記第1のメッセージは、前記オフロードされたトラフィックの前記CU1に戻されるべき前記一部に関連するトラフィック量を示す、請求項13に記載の方法。
【請求項16】
請求項13に記載の方法であって、条件が満たされたと判定することをさらに含み、前記第1のメッセージは前記条件が満たされたと判定されたことに応答して前記CU1に送信され、前記条件は、タイマーが満了したと判定したこと、
前記CU2でのトラフィック負荷の増加を特定したこと、
前記CU2でのトラフィックが閾値を超えて増加したことを特定したこと、
前記CU1でのトラフィック負荷の減少を特定したこと、および
前記CU1のトラフィックが閾値を超えて減少したことを特定したこと、の1つ以上を含む、方法。
【請求項17】
前記CU1から、前記CU2によって解放されるべき1つ以上のリソースを示す第2のメッセージを受信することをさらに含む、請求項16に記載の方法。
【請求項18】
前記第1のメッセージは、前記オフロードされたトラフィックの前記CU1に戻されるべき前記一部に関連する少なくとも1つの許可されたリソースを示す、請求項13に記載の方法。
【請求項19】
請求項18に記載の方法であって、前記少なくとも1つの許可されたリソースは、ダウンリンクリソース、および／または
アップリンクリソース、の少なくとも一方を含む、方法。
【請求項20】
前記オフロードされたトラフィックの前記CU1に戻されるべき前記一部に関連する情報を、少なくとも1つのIABノードに送信することをさらに含む、請求項13に記載の方法。
【請求項21】
統合アクセスおよびバックホール(IAB)ネットワークにおける第1のセントラルユニット(CU1)であって、第1のメッセージを第2のCU(CU2)に送信すること、または前記CU2から第1のメッセージを受信するように構成され、
前記第1のメッセージは、オフロードされたトラフィックの一部がCU1に戻されるべきであることを示す情報を有し、
前記オフロードされたトラフィックは、以前に前記CU1から前記CU2にオフロードされたものである、CU1。
【請求項22】
請求項2から12のいずれか１項に記載の方法を実行するようにさらに構成された、請求項21に記載のCU1。
【請求項23】
統合アクセスおよびバックホール(IAB)ネットワークにおける第2のセントラルユニット(CU2)であって、第1のメッセージをCU1に送信する、または前記CU1から第1のメッセージを受信する、ように構成され、
前記第1のメッセージは、オフロードされたトラフィックの一部がCU1に戻されるべきであることを示す情報を有し、
前記オフロードされたトラフィックは、以前に前記CU1から前記CU2にオフロードされたものである、CU2。
【請求項24】
請求項14から20のいずれか１項に記載の方法を実行するようにさらに構成された、請求項23に記載のCU2。
【国際調査報告】