JP2024517469A - 信号の送受信方法、装置及び通信システム - Google Patents

Abstract

本発明の実施例は、信号の送受信方法、装置及び通信システムを提供する。該信号の送受信装置は、第１のアクセスバックホール統合ノードドナー集約ユニット（ＩＡＢ－ｄｏｎｏｒ－ＣＵ）に適用され、該装置は第１の送受信部を含み、該第１の送受信部は、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロード要求を送信し、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信されたトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を受信するように構成される。
【選択図】図１４

Description

本発明の実施例は、通信技術の分野に関する。

アクセスバックホール統合（Ｉｎｔｅｇｒａｔｅｄ ａｃｃｅｓｓ ａｎｄ ｂａｃｋｈａｕｌ：ＩＡＢ）は、次世代無線アクセスネットワーク（ＮＧ－ＲＡＮ：ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ）において無線中継の機能を実現する。アクセスバックホール統合ノード（ＩＡＢ－ｎｏｄｅ）は、新しい無線（ｎｅｗ ｒａｄｉｏ：ＮＲ）を介するアクセス及びバックホールをサポートする。ＮＲバックホールのネットワーク側の終点は、ＩＡＢ－ｄｏｎｏｒと呼ばれ、ＩＡＢ機能をサポートするネットワーク装置（例えばｇＮＢ）を表す。

ＩＡＢノードは、シングルホップ又はマルチホップを介して１つのＩＡＢドナー（ＩＡＢ－ｄｏｎｏｒ）に接続することができる。これらのマルチホップの接続は、ＩＡＢドナーをルートノードとする有向非巡回グラフ（ＤＡＧ：Ｄｉｒｅｃｔｅｄ Ａｃｙｃｌｉｃ Ｇｒａｐｈ）のトポロジ構造を形成する。ＩＡＢドナーは、ＩＡＢネットワークトポロジの一元化されたリソース管理、トポロジ管理及びルーティング管理を実行する。

ＩＡＢ－ｎｏｄｅはｇＮＢ－ＤＵ（ｄｉｓｔｒｉｂｕｔｅｄ ｕｎｉｔ：分散ユニット）の機能をサポートする。ＩＡＢ－ｎｏｄｅ ＤＵはＩＡＢ－ＤＵとも呼ばれ、ＩＡＢ－ＤＵは端末装置（ＵＥ）とネクストホップのＩＡＢ－ｎｏｄｅへの無線アクセス（ＮＲ ａｃｃｅｓｓ）インターフェースの終点であり、ＩＡＢ－ｄｏｎｏｒでのｇＮＢ－ＣＵ（ＩＡＢ－ｎｏｄｅ：集約ユニット）へのＦ１プロトコルの終点である。ＩＡＢ－ＤＵは、通常のＵＥ及びＩＡＢ子ノードにサービスを提供することができる。ＩＡＢ－ＤＵは、ネットワーク側装置の機能を実現し、ダウンストリームのｃｈｉｌｄ ＩＡＢ－ｎｏｄｅに接続し、ＵＥ及びダウンストリームのｃｈｉｌｄ ＩＡＢ－ｎｏｄｅにＮＲエアインターフェースを提供し、ＩＡＢ ｄｏｎｏｒ－ＣＵとの間にＦ１接続を確立する。

ｇＮＢ－ＤＵ機能に加えて、ＩＡＢ－ｎｏｄｅは、ＩＡＢ－ＭＴ（ｍｏｂｉｌｅ ｔｅｒｍｉｎａｔｉｏｎ）と称されるＵＥの機能の一部をサポートする。ＩＡＢ－ＭＴは、例えば、他のＩＡＢ－ｎｏｄｅ又はＩＡＢ－ｄｏｎｏｒのｇＮＢ－ＤＵに接続すること、ＩＡＢ－ｄｏｎｏｒでのｇＮＢ－ＣＵに連続すること、及びコアネットワークに連続することのための物理層、レイヤ２、ＲＲＣ及びＮＡＳ機能などを含む。ＩＡＢ－ＭＴは、例えばＵＥ物理層、アクセス（ａｃｃｅｓｓ ｓｔｒａｔｕｍ：ＡＳ）、無線リソース制御（ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ：ＲＲＣ）層、及び非アクセス（ｎｏｎ－ａｃｃｅｓｓ ｓｔｒａｔｕｍ：ＮＡＳ）層などの機能をサポートすることができ、ＩＡＢ親ノードに接続することができる。

ＩＡＢ－ｄｏｎｏｒは、ネットワーク側の終端ノードであり、ＩＡＢ－ｄｏｎｏｒは、バックホール又はアクセスのリンクを介してＩＡＢ－ＭＴ又はＵＥのためにネットワークアクセスを提供する。ＩＡＢ－ｄｏｎｏｒは、ＩＡＢ－ｄｏｎｏｒ－ＣＵ（ｃｅｎｔｒａｌ ｕｎｉｔ）とＩＡＢ－ｄｏｎｏｒ－ＤＵにさらに分けられる。ＩＡＢ－ＤＵとＩＡＢ－ｄｏｎｏｒ－ＣＵとの間は、Ｆ１インターフェースで接続されている。ネットワークを単独で配備するシナリオでは、ｇＮＢとＩＡＢ－ｄｏｎｏｒ－ＣＵとの間はＸｎインターフェースを介して接続される。

パケットのマルチホップルーティング転送をサポートするために、ＩＡＢは、バックホールアダプテーションプロトコル（Ｂａｃｋｈａｕｌ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＢＡＰ）サブレイヤを導入している。ＢＡＰサブレイヤは、無線リンク制御（ＲＬＣ）サブレイヤの上、ＩＰレイヤの下に位置し、パケットのターゲットノード及び経路選択、パケットルーティング転送、ベアラマッピング、フロー制御フィードバック、バックホールリンク障害通知などの機能をサポートする。

図１は、ＩＡＢトポロジ構造の一例の概略図である。図１に示すように、ＩＡＢトポロジ構造１０において、ＩＡＢ－ｎｏｄｅ１００は、ＩＡＢ－ＭＴ機能ユニット１０１とＩＡＢ－ＤＵ機能ユニット１０２とを含み、ＩＡＢ－ＤＵ機能ユニット１０２のインターフェースでの隣接ノードは、子ノード（ｃｈｉｌｄ ｎｏｄｅ）と称され、例えば図１に示す子ノード２０１、２０２、２０３を含む。ＩＡＢ－ＤＵ機能ユニット１０２と子ノード２０１、２０２、２０３との間は、エアインターフェース（Ｕｕ）を介して通信することができる。ＩＡＢ－ＭＴ機能ユニット１０１のインターフェースでの隣接ノードは、親ノード（ｐａｒｅｎｔ ｎｏｄｅ）と称され、例えば図１に示す親ノード３０１、３０２を含む。ＩＡＢ－ＭＴ機能ユニット１０１と親ノード３０１、３０２との間は、エアインターフェース（Ｕｕ）を介して通信することができる。

図１に示すように、ＩＡＢ－ｎｏｄｅ１００から子ノード２０１、２０２、２０３への方向は、ダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）方向と称され、ＩＡＢ－ｎｏｄｅ１００から親ノード３０１、３０２への方向は、アップストリーム（ｕｐｓｔｒｅａｍ）方向と称される。ＩＡＢ－ｄｏｎｏｒ（図示せず）は、該ＩＡＢトポロジ構造１０のために、一元化されたリソース、トポロジ及びルーティングの管理を実行する。

なお、背景技術に関する上記の説明は、単なる本発明の構成をより明確、完全に説明するためのものであり、当業者を理解させるために説明するものである。これらの構成が本発明の背景技術の部分に説明されているから当業者にとって周知の技術であると解釈してはならない。

トポロジ冗長化（ｔｏｐｏｌｏｇｙ ｒｅｄｕｎｄａｎｃｙ）とは、ＩＡＢトポロジネットワークにおいて、ＩＡＢノードのために冗長な経路、即ち第２の経路を確立して、１つのトポロジネットワークにおける部分的なサービスをもう１つのトポロジネットワークにオフロード（ｏｆｆｌｏａｄ）すること、即ち、冗長な経路を介したデータ伝送を意味する。トポロジ冗長化の主な目的は、サービスの負荷均衡を実現し、サービスの中断を低減させ、ネットワークの堅牢性を向上させることである。

従来のドナー内（ｉｎｔｒａ－ＣＵ）トポロジ冗長化手順は、同一のＩＡＢ－ｄｏｎｏｒ－ＣＵでのＩＡＢトポロジにおいて冗長経路の確立及び解放を行うことができ、この手順は、ある程度の経路の多様性及び負荷均衡を達成することができる。同一のＩＡＢ－ｄｏｎｏｒ－ＣＵでのトポロジネットワークで負荷が飽和状態になると、サービスのパフォーマンスに影響を与える。ドナー間（ｉｎｔｅｒ－ＣＵ）トポロジ冗長化は、経路の多様性をさらに向上させ、負荷均衡のニーズをより良好に満足することができる。

しかし、本発明の発明者の発見により、ドナー間のトポロジ的に冗長経路をどのように確立又は解放するかについて、対応する解決策がない。

本発明の実施例は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロード要求を送信し、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を送信することによって、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのネットワークトポロジと第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのネットワークトポロジとの間に冗長経路を確立することができるため、経路の多様性をさらに向上させ、負荷均衡及びサービス中断の低減のニーズをより良好に満足することができる、信号の送受信方法、装置及び通信システムを提供する。

本発明の実施例の１つの態様では、第１のアクセスバックホール統合ノードドナー集約ユニット（ＩＡＢ－ｄｏｎｏｒ－ＣＵ）に適用される、信号の送受信装置であって、該装置は第１の送受信部を含み、前記第１の送受信部は、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロード要求を送信し、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信されたトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を受信するように構成される、装置を提供する。

本発明の実施例のもう１つの態様では、第２のアクセスバックホール統合ノードドナー集約ユニット（ＩＡＢ－ｄｏｎｏｒ－ＣＵ）に適用される、信号の送受信装置であって、該装置は第２の送受信部を含み、前記第２の送受信部は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信されたトラフィックオフロード要求を受信し、前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を送信するように構成される、装置を提供する。

本発明の実施例のもう１つの態様では、ＩＡＢノードに適用される、信号の送受信装置であって、前記ＩＡＢノードは、第１の親ノードに接続されており、前記ＩＡＢノードは、第２の親ノードに既に接続されており、或いは接続される予定であり、前記第１の親ノードは、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、該装置は第３の送受信部を含み、前記第３の送受信部は、前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第１のＲＲＣ再構成メッセージを受信し、前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにＲＲＣ再構成完了メッセージを送信するように構成され、前記第１のＲＲＣ再構成メッセージは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたトラフィックオフロードに同意する応答に応じて生成され、前記第１のＲＲＣ再構成メッセージは、前記ＩＡＢノードのＤＵに割り当てられた少なくとも１つのＴＮＬアドレスを含み、前記ＴＮＬアドレスは、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵにアンカーされ、前記ＲＲＣ再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、前記ＩＡＢノードが前記第１のＲＲＣ再構成メッセージを受信しており、且つ再構成を完了したことを示すために使用される、装置を提供する。

本発明の実施例のもう１つの態様では、ＩＡＢノードの子孫ノードに適用される、信号の送受信装置であって、前記ＩＡＢノードは、第１の親ノードに接続されており、前記ＩＡＢノードは、第２の親ノードに既に接続されており、或いは接続される予定であり、前記第１の親ノードは、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、該装置は第４の送受信部を含み、前記第４の送受信部は、前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第１のＲＲＣ再構成メッセージを受信し、前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにＲＲＣ再構成完了メッセージを送信するように構成され、前記第１のＲＲＣ再構成メッセージは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたトラフィックオフロードに同意する応答に応じて生成され、前記第１のＲＲＣ再構成メッセージは、前記子孫ノードのＤＵに割り当てられた少なくとも１つのＴＮＬアドレスを含み、前記ＴＮＬアドレスは、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵにアンカーされ、前記ＲＲＣ再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、前記子孫ノードが前記第１のＲＲＣ再構成メッセージを受信しており、且つ再構成を完了したことを示すために使用される、装置を提供する。

本発明の実施例のもう１つの態様では、上記の何れかの態様の信号の送受信装置に対応する、信号の送受信方法を提供する。

本発明の実施例の有利な効果は以下の通りである。第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロード要求を送信し、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を送信することによって、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのネットワークトポロジと第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのネットワークトポロジとの間に冗長経路を確立することができる。

下記の説明及び図面に示すように、本発明の特定の実施形態が詳細に開示され、本発明の原理を採用できる方式が示される。なお、本発明の実施形態の範囲はこれらに限定されない。本発明の実施形態は、添付される特許請求の範囲の要旨及び項目の範囲内において、変更されたもの、修正されたもの及び均等的なものを含む。

１つの実施形態に記載された特徴及び／又は示された特徴は、同一又は類似の方式で１つ又はさらに多くの他の実施形態で用いられてもよいし、他の実施形態における特徴と組み合わせてもよいし、他の実施形態における特徴に代わってもよい。

なお、本文では、用語「含む／有する」は、特徴、部材、ステップ又は構成要件が存在することを意味し、１つ又は複数の他の特徴、部材、ステップ又は構成要件の存在又は付加を排除しない。

本発明の実施例の１つの図面及び１つの実施形態に記載された要素及び特徴は、１つ又はさらに多くの図面又は実施形態に示された要素及び特徴と組み合わせてもよい。また、図面において、類似の符号は複数の図面における対応する素子を示し、１つ以上の実施形態に用いられる対応素子を示してもよい。
ＩＡＢトポロジ構造の一例の概略図である。 ドナー間（ｉｎｔｅｒ－ＣＵ）トポロジ冗長化のシナリオにおけるトポロジ伝送経路の一例を示す図である。 実施形態１に係る信号の送受信方法の一例の概略図である。 実施形態２に係る信号の送受信方法の一例の概略図である。 実施例１におけるＩＡＢノードの第２の経路の確立手順の一例の概略図である。 実施例２におけるＩＡＢノードの子孫ノードのためにドナー間の冗長経路を確立する方法の一例の概略図である。 ＩＡＢノードにＳＮを追加して二重接続ノードに変更し、冗長経路を確立することを示す概略図である。 成功したトラフィックオフロード手順の一例の概略図である。 失敗したトラフィックオフロード手順の一例の概略図である。 トラフィックオフロードの開始側による冗長経路解放の一例の概略図である。 トラフィックオフロードの受け入れ側による冗長経路解放の一例の概略図である。 実施形態３に係る信号の送信及び受信方法の一例の概略図である。 実施形態３に係る信号の送信及び受信方法の一例の概略図である。 本発明の実施形態に係る信号の送受信装置の一例の概略図である。 実施形態６に係る信号の送受信装置の一例の概略図である。 実施形態７に係る信号の送受信装置の一例の概略図である。 実施形態８に係る信号の送受信装置の一例の概略図である。 本発明の実施形態に係るネットワーク装置の構成の概略図である。 本発明の実施形態に係る端末装置の概略図である。

本発明の上記及び他の特徴は以下の説明により明らかになる。明細書及び図面において、本発明の特定の実施形態が詳細に開示され、本発明の原理を採用できる実施形態の一部が示される。なお、本発明は説明される実施形態に限定されない。本発明は、添付される特許請求の範囲内の全ての変更されたもの、変形されたもの及び均等的なものを含む。

本発明の実施例では、用語「第１」、「第２」などは、タイトルで異なる要素を区別するために用いられるが、これらの要素の空間的配列又は時間的順序などを表すものではなく、これらの要素はこれらの用語に制限されない。用語「及び／又は」は、関連するリストに列挙された用語の１つ又は複数のうち何れか１つ及び全ての組み合わせを含む。用語「含む」、「包括する」、「有する」などは、列挙された特徴、要素、素子又は構成部材の存在を意味するが、１つ又は複数の他の特徴、要素、素子又は構成部材の存在又は追加を排除するものではない。

本発明の実施例では、単数形の「１つ」、「該」などは複数形を含み、「１種類」又は「１類」と広義的に理解されるべきであり、「１個」に限定されない。また、用語「前記」は、文脈がそうでないことを明確に示さない限り、単数形及び複数形両方を含むと理解されるべきである。また、文脈がそうでないことを明確に示さない限り、用語「に記載の」は「少なくとも一部に記載の」と理解されるべきであり、用語「に基づいて」は「少なくとも一部に基づいて」と理解されるべきである。

本発明の実施例では、用語「通信ネットワーク」又は「無線通信ネットワーク」は、例えば、新しい無線（ｎｅｗ ｒａｄｉｏ：ＮＲ）、ロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、進化したロングタームエボリューション（ＬＴＥ－Ａ、ＬＴＥ－Ａｄｖａｎｃｅｄ）、広帯域符号分割多元接続（ＷＣＤＭＡ(登録商標)：Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、高速パケットアクセス（ＨＳＰＡ：Ｈｉｇｈ－Ｓｐｅｅｄ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）などの任意の通信規格に適合するネットワークを意味してもよい。

また、通信システムにおける装置間の通信は、任意の段階の通信プロトコルに従って行われてもよく、該通信プロトコルは、例えば１Ｇ（ｇｅｎｅｒａｔｉｏｎ）、２Ｇ、２．５Ｇ、２．７５Ｇ、３Ｇ、４Ｇ、４．５Ｇ、５Ｇ、及び新しい無線（ｎｅｗ ｒａｄｉｏ：ＮＲ）等、並びに／又は現在の既知の他の通信プロトコル若しくは将来開発される他の通信プロトコルを含んでもよいが、これらに限定されない。

本発明の実施例では、用語「ネットワーク装置」は、例えば通信システムに端末装置をアクセスさせて該端末装置にサービスを提供する通信システム内の装置を意味する。ネットワーク装置は、アクセスバックホール統合ノード（ＩＡＢ－ｎｏｄｅ）、基地局（ＢＳ：Ｂａｓｅ Ｓｔａｔｉｏｎ）、アクセスポイント（ＡＰ：Ａｃｃｅｓｓ Ｐｏｉｎｔ）、送受信ポイント（ＴＲＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｒｅｃｅｐｔｉｏｎ Ｐｏｉｎｔ）、ブロードキャスト送信機、モビリティ管理エンティティ（ＭＭＥ：Ｍｏｂｉｌｅ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）、ゲートウェイ、サーバ、無線ネットワークコントローラ（ＲＮＣ：Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）、基地局コントローラ（ＢＳＣ：Ｂａｓｅ Ｓｔａｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ）などを含んでもよいが、これらに限定されない。

そのうち、基地局は、ノードＢ（ＮｏｄｅＢ又はＮＢ）、進化ノードＢ（ｅＮｏｄｅＢ又はｅＮＢ）、及び５Ｇ基地局（ｇＮＢ）など、並びにリモート無線ヘッド（ＲＲＨ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｈｅａｄ）、リモート無線ユニット（ＲＲＵ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｕｎｉｔ）、中継装置（ｒｅｌａｙ）又は低電力ノード（例えばｆｅｍｔｏ、ｐｉｃｏなど）を含んでもよいが、これらに限定されない。また、用語「基地局」はそれらの機能の一部又は全てを含んでもよく、各基地局は特定の地理的エリアに対して通信カバレッジを提供してもよい。用語「セル」は、該用語が使用されるコンテキストに応じて、基地局及び／又はそのカバレッジエリアを意味してもよい。

本発明の実施例では、用語「ユーザ装置」（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又は用語「端末装置」（ＴＥ：Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ又はＴｅｒｍｉｎａｌ Ｄｅｖｉｃｅ）は、例えばネットワーク装置を介して通信ネットワークにアクセスし、ネットワークサービスを受ける装置を意味する。端末装置は、固定的なもの又は移動的なものであってもよく、移動局（ＭＳ：Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、端末、加入者ステーション（ＳＳ：Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、アクセス端末（ＡＴ：Ａｃｃｅｓｓ Ｔｅｒｍｉｎａｌ）、ステーションなどと称されてもよい。

そのうち、端末装置は、携帯電話（Ｃｅｌｌｕｌａｒ Ｐｈｏｎｅ）、パーソナルデジタルアシスタント（ＰＤＡ：Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、無線変復調装置、無線通信装置、ハンドヘルドデバイス、マシンタイプ通信装置、ラップトップコンピュータ、コードレス電話、スマートフォン、スマートウォッチ、デジタルカメラなどを含んでもよいが、これらに限定されない。

例えば、モノのインターネット（ＩｏＴ：Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）などのシナリオでは、ユーザ装置は、監視又は測定を行う機器又は装置であってもよく、例えばマシンタイプ通信（ＭＴＣ：Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）端末、車載通信端末、デバイスツーデバイス（Ｄ２Ｄ：Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ）端末、マシンツーマシン（Ｍ２Ｍ：Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）端末などを含んでもよいが、これらに限定されない。

さらに、用語「ネットワーク側」又は「ネットワーク装置側」とは、ネットワークの側を意味し、ある基地局であってもよいし、上記のような１つ又は複数のネットワーク装置を含んでもよい。用語「ユーザ側」又は「端末側」又は「ユーザ端末側」とは、ユーザ又は端末の側を意味し、あるＵＥであってもよいし、上記のような１つ又は複数の端末装置を含んでもよい。

本発明の実施例では、上位層シグナリングは、例えば、無線リソース制御（ＲＲＣ）シグナリングであってもよく、例えば、ＲＲＣメッセージ（ＲＲＣ ｍｅｓｓａｇｅ）と称され、例えばＭＩＢ、システム情報（ｓｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ）、専用ＲＲＣメッセージを含み、或いは、ＲＲＣ ＩＥ（ＲＲＣ ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ）と称される。上位層シグナリングは、例えばＦ１－Ｃシグナリングであってもよく、或いはＦ１ＡＰプロトコルとも称される。なお、本発明はこれらに限定されない。

本発明の各実施形態では、複数のＵＥは、マルチホップのＩＡＢノードを介してＩＡＢ－ｄｏｎｏｒに接続され、最後にネットワークにアクセスし、該ネットワークは例えば５Ｇネットワークである。

図２は、ドナー間（ｉｎｔｅｒ－ＣＵ）トポロジ冗長化のシナリオにおけるトポロジ伝送経路の一例を示す図である。図２におけるＤｏｎｏｒ－ＣＵ１はＩＡＢ－ｄｏｎｏｒ－ＣＵ１とも呼ばれ、Ｄｏｎｏｒ－ＣＵ２はＩＡＢ－ｄｏｎｏｒ－ＣＵ２とも呼ばれる。

図２に示すように、Ｄｏｎｏｒ－ＣＵ１は、ＩＡＢノード３とＩＡＢノード４のＦ１終端（ｔｅｒｍｉｎａｔｉｎｇ）ドナーである。ＩＡＢノード３は、Ｄｏｎｏｒ－ＣＵ１への２つの経路を有する二重接続ノードである。ＩＡＢノード４も、Ｄｏｎｏｒ－ＣＵ１への２つの経路を有してもよい。ＩＡＢノード４がアクセス（ａｃｃｅｓｓ）ＩＡＢノードであることを一例にすると、ＩＡＢノード４からＤｏｎｏｒ－ＣＵ１へのあるデータは、Ｄｏｎｏｒ－ＣＵ１により制御されたトポロジネットワークを介して伝送し（第１の経路と呼ばれ、実線の矢印で示す）、あるデータは、Ｄｏｎｏｒ－ＣＵ２により制御されたトポロジネットワークを介して伝送し（第２の経路と呼ばれ、破線の矢印で示す）、これによって、データ分流、負荷均衡の目的を達成する。同様に、ＩＡＢノード３及びＩＡＢノード３の他の子孫ノード（図示せず）も、アクセスＩＡＢノードとして第２の経路を確立することができる。

図２において、ＩＡＢノード１はＩＡＢノード３の第１の親ノードであり、ＩＡＢノード２はＩＡＢノード３の第２の親ノードであり、ＩＡＢノード４はＩＡＢノード３の子孫ノードである。簡略化のため、図２ではＩＡＢノード４の以下のＵＥは描かれていない。

本発明の各実施形態では、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは、図２におけるＤｏｎｏｒ－ＣＵ１であってもよく、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、図２におけるＤｏｎｏｒ－ＣＵ２であってもよく、ＩＡＢノードは、図２におけるＩＡＢノード３であってもよく、ＩＡＢノード３の子孫ノードは、図２におけるＩＡＢノード４であってもよく、ＩＡＢノード３の第１の親ノードは、図２におけるＩＡＢノード１であってもよく、ＩＡＢノード３の第２の親ノードは、図２におけるＩＡＢノード２であってもよく、ＩＡＢノード３の第１の親ノード（例えば、ＩＡＢノード１）は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、ＩＡＢノード３の第２の親ノード（例えば、ＩＡＢノード２）は、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである。第２のＩＡＢ－ｄｏｎｏｒ－ＤＵは、図２におけるＤｏｎｏｒ－ＤＵ２であってもよい。

図２において、第１の経路と第２の経路の両方が確立されている場合、ＩＡＢノード３が第１の親ノード（例えば、ＩＡＢノード１）に接続されており、且つＩＡＢノード３が第２の親ノード（例えば、ＩＡＢノード２）に接続されている場合である。また、第２の経路が確立されるまで（即ち、本発明の信号の送受信方法が実行される前に）、ＩＡＢノード３と第２の親ノード（例えば、ＩＡＢノード２）とは、既に接続されている状態であってもよいし、まだ接続されていない（即ち、接続される予定である）状態であってもよい。

本発明の各実施形態では、アクセスＩＡＢノードは、ＩＡＢノード（例えば、図２のＩＡＢノード３）及び／又はＩＡＢノードの子孫ノード（例えば、図２のＩＡＢノード４）、又は、二重接続される予定のあるＩＡＢノード（例えば、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ及び第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに接続される予定のあるノード）を含む。

本発明の各実施形態では、ＩＡＢ－ＤＵは、ＩＡＢノードの分散ユニット、即ちＩＡＢのＤＵを表してもよい。ＩＡＢ－ＭＴは、ＩＡＢノードの移動端末、即ちＩＡＢのＭＴを表してもよい。

本発明の各実施形態では、Ｄｏｎｏｒ－ＣＵのトポロジ内のノードは、該ノードのＤＵ部分がＤｏｎｏｒ－ＣＵによって管理されていること、即ち、該ノードのＦ１インターフェースがＤｏｎｏｒ－ＣＵに終端していることを意味する。

本発明の各実施形態では、Ｄｏｎｏｒ－ＣＵとＩＡＢ－ｄｏｎｏｒ－ＣＵとは、同一の意味を有し、置き換えられてもよい。

＜実施形態１＞
本発明の実施形態１は、信号の送受信方法を提供する。該方法は、第１のアクセスバックホール統合ノードドナー集約ユニット（ＩＡＢ－ｄｏｎｏｒ－ＣＵ）に適用される。本発明の実施形態１は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ側から該信号の送受信方法を説明する。ここで、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは、例えば、図２におけるＤｏｎｏｒ－ＣＵ１であってもよい。

図３は、実施形態１に係る信号の送受信方法の一例の概略図である。図３に示すように、該方法は、以下のステップを含む。

ステップ３０１：第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロード要求を送信する。

ステップ３０２：第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信されたトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を受信する。

本発明では、ステップ３０１及びステップ３０２は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵと第２のＩＡＢ－ｄｏｎｏｒ－ＣＵとの間のトポロジ冗長化をサポートすることができるため、経路の多様性をさらに向上させ、負荷均衡のニーズをより良好に満足することができる。

少なくとも１つの態様では、ステップ３０１において送信されるトラフィックオフロード要求は、ＩＡＢノード及び／又は該ＩＡＢノードの子孫ノードのためにドナーに跨る冗長経路を確立する要求を含む。

例えば、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは、第２の経路のルーティング及びＢＨ ＲＬＣチャネルマッピングをサポートするために、ＩＡＢノードから該ＩＡＢノードの子孫ノードへのバックホール無線リンク制御（ＢＨ ＲＬＣ）チャネルの構成及びＢＡＰサブレイヤのルーティングテーブルの構成を行う。これによって、子孫ノードのために冗長経路を確立する。また、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは、トラフィックオフロードに同意する応答に応じて、ＩＡＢノードに対してＢＡＰルート識別子マッピングの構成を行ってもよい。これによって、ＩＡＢノードにおいて、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより制御された第１の経路のトポロジと第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより制御された第２の経路のトポロジとの間のＢＡＰルート変換を実行して、子孫ノードのために冗長経路を確立することができる。また、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは、ユーザ装置コンテキスト変更要求（ＵＥ ＣＯＮＴＥＸＴ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージ又はユーザ装置コンテキスト確立要求（ＵＥ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴ）メッセージを介して、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵからＩＡＢノード及び／又は該ＩＡＢノードの子孫ノードのＤＵへのＦ１－Ｕトンネルを第１の経路から第２の経路に移行（ｍｉｇｒａｔｅ）してもよい。これによって、ＩＡＢノード及び／又は子孫ノードのために冗長経路を確立することができる。

少なくとも１つの態様では、ステップ３０２におけるトラフィックオフロードに同意する応答は、トラフィックオフロード要求を少なくとも部分的に受け入れることを示してもよい。ここで、トラフィックオフロード要求を少なくとも部分的に受け入れることは、幾つかのＴＮＬに関連するＦ１－Ｃトンネルのために冗長経路を確立すること、又は幾つかのＦ１－Ｕトンネルのために冗長経路を確立することを意味する。

少なくとも１つの態様では、ＩＡＢノードが第１の親ノードに接続され、ＩＡＢノードが第２の親ノードにも接続されている場合、トラフィックオフロード要求は、トラフィックオフロード要求メッセージに含まれてもよく、トラフィックオフロード要求メッセージは、例えばＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴメッセージであってもよいし、Ｒｅｄｕｎｄａｎｔ Ｐａｔｈ Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔメッセージであってもよい。トラフィックオフロードに同意する応答は、トラフィックオフロード要求承認メッセージに含まれてもよく、該トラフィックオフロード要求承認メッセージは、例えばＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージである。トラフィックオフロードを拒否する応答は、トラフィックオフロード拒否メッセージに含まれてもよく、該トラフィックオフロード拒否メッセージは、例えばＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴメッセージである。

１つの態様では、トラフィックオフロード要求メッセージは、トラフィックオフロード開始ノードのユーザ装置のＸｎインターフェースでの識別子（ＵＥ ＸｎＡＰ ＩＤ）、及び／又は１つ以上のＦ１－Ｃの識別情報を含んでもよい。ここで、トラフィックオフロード開始ノードは、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵを意味する。ユーザ装置とは、アクセスＩＡＢノード（ＩＡＢ－ｄｏｎｏｒがＩＡＢノードのユーザ装置となる）を意味する。該Ｆ１－Ｃの識別情報は、アクセスＩＡＢノードの１つ以上のＦ１－Ｃのために冗長経路を確立するために使用される。

別の態様では、トラフィックオフロード要求メッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、アクセスＩＡＢノードのＢＡＰアドレス、ＴＮＬアドレス、１つ以上のＦ１－Ｕトンネル識別情報、Ｆ１－Ｃ及び／又は各Ｆ１－ＵトンネルのＩＰヘッダ情報（ＩＰ ｈｅａｄｅｒ ｉｎｆｏｒｍａｔｉｏｎ）、及び各Ｆ１－Ｕトンネルのサービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ：ＱｏＳ）情報のうちの少なくとも１つを含む。

上記２つの態様では、Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルの少なくとも一部についてのトラフィックオフロード要求を受け入れた場合、トラフィックオフロード要求承認メッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルの識別情報、アクセスＩＡＢノードのＤＵのために新たに割り当てられたＴＮＬアドレス、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルのために構成された二重接続されているＩＡＢノードと第２の親ノードとの間のリンクでのＢＨ ＲＬＣチャネル識別子、第２の親ノードのＢＡＰアドレス、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより制御されたトポロジ内のＢＡＰルーティング識別子、及びＩＡＢノードの第２のＢＡＰアドレスのうちの少なくとも１つを含んでもよい。ここで、トラフィックオフロード受け入れノードは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵを意味する。トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤは、アクセスＩＡＢノードの第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのノード内のＸｎインターフェースＩＤを意味する。トラフィック開始ノード及びトラフィック受け入れノードがＭＮ又はＳＮに対応するか否かに応じて、トラフィック開始ノードのＵＥ ＸｎＡＰ ＩＤ及びトラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤは、それぞれＭ－ＮＧ－ＲＡＮ ｎｏｄｅ ＵＥ ＸｎＡＰ ＩＤ（マスタ基地局ノードのＵＥ ＸｎＡＰ ＩＤ）又はＳ－ＮＧ－ＲＡＮ ｎｏｄｅ ＵＥ ＸｎＡＰ ＩＤ（セカンダリ基地局ノードのＵＥ ＸｎＡＰ ＩＤ）と称されてもよい。

上記２つの態様では、全てのＦ１－Ｃ及びＦ１－Ｕトンネルに対するトラフィックオフロード要求を拒否する場合、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、トラフィックオフロード要求拒否メッセージを送信し、該トラフィックオフロード要求拒否メッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤを含む。

少なくとも１つの態様では、ＩＡＢノードが第１の親ノードに接続されており、且つＩＡＢノードが第２の親ノードにも接続されている場合、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵがマスタノード（ＭＮ）であるとき、トラフィックオフロード要求の内容、及びトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード変更準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれる。

少なくとも別の実施形態では、ＩＡＢノードが第１の親ノードに接続されており、且つＩＡＢノードが第２の親ノードに接続されていない場合、トラフィックオフロード要求の内容、及びトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード追加準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ａｄｄｉｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれてもよい。

例えば、トラフィックオフロード要求は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたセカンダリノード追加要求（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージに含まれてもよい。別の例として、トラフィックオフロードに同意する応答は、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたＳＮ追加要求承認（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージに含まれてもよい。

図３に示すように、該方法は、以下のステップをさらに含む。

ステップ３０３：トラフィックオフロードに同意する応答に応じて、ＩＡＢノード及び／又はＩＡＢノードの子孫ＩＡＢノードに第１のＲＲＣ再構成メッセージを送信する。

ステップ３０３において、第１のＲＲＣ再構成メッセージは、ＩＡＢノード（例えば、図２のＩＡＢノード３）及び／又はＩＡＢノードの子孫ノード（例えば、図２のＩＡＢノード４）の分散ユニット（ＤＵ）にそれぞれ割り当てられた少なくとも１つの伝送ネットワーク層（ｔｒａｎｓｐｏｒｔ ｎｅｔｗｏｒｋ ｌａｙｅｒ（ＴＮＬ）又はｔｒａｎｓｐｏｒｔ ｌａｙｅｒ）アドレスを含んでもよい。該ＴＮＬアドレスは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵ（例えば、図２のＤｏｎｏｒ－ＤＵ２）にアンカーされる。

ステップ３０３において、第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）は、該ＩＡＢノードのために構成された第２のＢＡＰアドレスを示すためのフィールドを含み、該フィールドは、例えば、第２のＢＡＰアドレスであることを示すためのｂａｐ－Ａｄｄｒｅｓｓ－ｒｅｄｕｎｄａｎｔ又はｂａｐ－Ａｄｄｒｅｓｓ－ｓｅｃｏｎｄなどである。或いは、第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）におけるＢＡＰアドレスフィールドは、リストを含み、該リストにおける各エントリは、ＢＡＰアドレス及びその関連情報である。例えば、該リストは、ｂａｐ－ＡｄｄｒｅｓｓＬｉｓｔであってもよく、該リストにおける各エントリは、ＢＡＰアドレス及びその関連情報であり、各エントリは、例えば、｛ｂａｐ－Ａｄｄｒｅｓｓ，‘ＭＣＧ’／‘ＳＣＧ’｝又は｛ｂａｐ－Ａｄｄｒｅｓｓ，ｉａｂ－ｄｏｎｏｒ－ＤＵ－ＢＡＰ－Ａｄｄｒｅｓｓ｝などである。これによって、ＩＡＢノード３のために第２のＢＡＰアドレスを割り当てることができる。該第２のＢＡＰアドレスは、冗長経路（即ち、Ｄｏｎｏｒ－ＤＵ２を通る第２の経路）上のＢＡＰルーティング構成に使用されてもよい。

少なくとも１つの態様では、ステップ３０３において、ＩＡＢノード及び／又はその子孫ノードに新しいＴＮＬアドレスが割り当てられた場合、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは、新しいＴＮＬアドレスを該ＩＡＢノード及び／又はその子孫ノードのＤＵと第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのＦ１－Ｃアソシエーションに追加してもよい。

図３に示すように、該信号の送受信方法は、以下のステップをさらに含んでもよい。

ステップ３０４：第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは冗長経路解放要求を送信又は受信する。

ステップ３０５：第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは冗長経路解放要求受け入れメッセージを受信又は送信する。

例えば、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに冗長経路解放要求を送信し、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵから冗長経路解放要求受け入れメッセージを受信する。別の例として、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された冗長経路解放要求を受信し、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに冗長経路解放要求受け入れメッセージを送信する。

少なくとも１つの態様では、冗長経路解放要求は、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、冗長経路を解放する必要のあるＦ１－Ｃに関連するＴＮＬアドレス、又は冗長経路を解放する必要のあるＦ１－Ｕトンネルのユーザプレーン伝送層情報（ＵＰ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｉｎｆｏｒｍａｔｉｏｎ）を含む。ここで、冗長経路は、例えば図２に示す第２の経路である。

少なくとも１つの態様では、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ及び第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにおけるマスタノード（ｍａｓｔｅｒ ｎｏｄｅ：ＭＮ）が冗長経路解放要求を送信した場合、該冗長経路解放要求の内容及び冗長経路解放要求受け入れメッセージの内容は、ＩＥとして、セカンダリ基地局ノード変更準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順に含まれる。

少なくとも１つの態様では、ＩＡＢノードのセカンダリ基地局ノード解放（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｒｅｌｅａｓｅ）手順を行う際に、ＳＮトポロジ内のＩＡＢノードに関連する全ての冗長経路を解放する。

本発明の実施形態１によれば、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵと第２のＩＡＢ－ｄｏｎｏｒ－ＣＵとの間に冗長経路を確立することができるため、経路の多様性をさらに向上させ、負荷均衡及びサービス中断の低減のニーズをより良好に満足することができる。また、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵと第２のＩＡＢ－ｄｏｎｏｒ－ＣＵとの間のトポロジ冗長経路を解放することができる。

＜実施形態２＞
本発明の実施形態２は、少なくとも実施形態１と同様な問題点について、実施形態１の方法に対応する信号の送受信方法を提供する。本発明の実施形態２に係る信号の送受信方法は、第２のアクセスバックホール統合ノードドナー集約ユニット（ＩＡＢ－ｄｏｎｏｒ－ＣＵ）に適用される。本発明の実施形態２は、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵ側から該信号の送受信方法を説明する。ここで、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、例えば、図２におけるＤｏｎｏｒ－ＣＵ２であってもよい。

図４は、実施形態２に係る信号の送受信方法の一例の概略図である。図４に示すように、該方法は、以下のステップを含む。

ステップ４０１：第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信されたトラフィックオフロード要求を受信する。

ステップ４０２：第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を送信する。

本発明では、ステップ４０１及びステップ４０２は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵと第２のＩＡＢ－ｄｏｎｏｒ－ＣＵとの間のトポロジ冗長化をサポートすることができるため、経路の多様性をさらに向上させ、負荷均衡のニーズをより良好に満足することができる。

少なくとも１つの態様では、ステップ４０１におけるトラフィックオフロード要求は、ＩＡＢノード（例えば、図２のＩＡＢノード３）及び／又はＩＡＢノードの子孫ノード（例えば、図２のＩＡＢノード４）のために冗長経路を確立する要求を含む。

ステップ４０２におけるトラフィックオフロードに同意する応答は、トラフィックオフロード要求を少なくとも部分的に受け入れることを示す。ここで、トラフィックオフロード要求を少なくとも部分的に受け入れることは、幾つかのＴＮＬに関連するＦ１－Ｃ又は幾つかのＦ１－Ｕトンネルのために冗長経路を確立することを意味する。

ＩＡＢノードが第１の親ノードに接続されており、且つＩＡＢノードが第２の親ノードに接続されている場合、トラフィックオフロード要求は、トラフィックオフロード要求メッセージに含まれてもよい。トラフィックオフロードに同意する応答は、トラフィックオフロード要求承認メッセージに含まれてもよく、トラフィックオフロード要求承認メッセージは、例えば、ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージであってもよい。トラフィックオフロードを拒否する応答は、トラフィックオフロード拒否メッセージに含まれてもよく、トラフィックオフロード拒否メッセージは、例えば、ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴであってもよい。

トラフィックオフロード要求メッセージは、トラフィックオフロード開始ノードのユーザ装置のＸｎインターフェースでの識別子（ＵＥ ＸｎＡＰ ＩＤ）、及び／又は１つ以上のＦ１－Ｃの識別情報を含んでもよい。該Ｆ１－Ｃの識別情報は、アクセスＩＡＢノードの１つ以上のＦ１－Ｃのために冗長経路を確立するために使用され、該アクセスＩＡＢノードは、ＩＡＢノード及び／又は該ＩＡＢノードの子孫ノード、又は二重接続になろうとしているＩＡＢノードを含む。

トラフィックオフロード要求メッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、アクセスＩＡＢノードのＢＡＰアドレス、ＴＮＬアドレス、１つ以上のＦ１－Ｃ識別情報、１つ以上のＦ１－Ｕトンネル識別情報、Ｆ１－Ｃ及び／又は各Ｆ１－ＵトンネルのＩＰヘッダ情報（ＩＰ ｈｅａｄｅｒ ｉｎｆｏｒｍａｔｉｏｎ）、又は各Ｆ１－Ｕトンネルのサービス品質（ＱｏＳ）情報のうちの少なくとも１つを含んでもよい。

少なくとも１つの態様では、Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルについてのトラフィックオフロード要求を受け入れた場合、トラフィックオフロード要求承認メッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルの識別情報、アクセスＩＡＢノードのＤＵのために新たに割り当てられたＴＮＬアドレス、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルのために構成された二重接続されているＩＡＢノードと第２の親ノードとの間のリンクでのＢＨ ＲＬＣチャネル識別子、第２の親ノードのＢＡＰアドレス、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより制御されたトポロジ内のＢＡＰルーティング識別子、及び該ＩＡＢノードの第２のＢＡＰアドレスのうちの少なくとも１つを含んでもよい。ここで、トラフィックオフロード受け入れノードは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵである。トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤは、アクセスＩＡＢノードの第２のＩＡＢ－ｄｏｎｏｒ－ＣＵノード内のＸｎインターフェース識別子である。

また、全てのＦ１－Ｃ及びＦ１－Ｕトンネルについてのトラフィックオフロード要求を拒否した場合、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロード要求拒否メッセージを送信してもよく、該トラフィックオフロード要求拒否メッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤを含んでもよい。

少なくとも１つの態様では、ＩＡＢノードが第１の親ノードに接続されており、且つＩＡＢノードが第２の親ノードに接続されている場合、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵがマスタノード（ＭＮ）であるとき、トラフィックオフロード要求の内容、及びトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード変更準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれてもよい。

少なくとも１つの態様では、ＩＡＢノードが第１の親ノードに接続されており、且つＩＡＢノードが第２の親ノードに接続されていない場合、トラフィックオフロード要求の内容、及びトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード追加準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ａｄｄｉｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれてもよい。

例えば、トラフィックオフロード要求は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたセカンダリノード追加要求（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージに含まれる。別の例として、トラフィックオフロードに同意する応答は、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたＳＮ追加要求承認（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージに含まれる。

図４に示すように、該方法は、以下のステップ４０３又はステップ４０４をさらに含む。

ステップ４０３：ＩＡＢノードが第２の親ノードに接続されている場合、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、該ＩＡＢノードのモバイル端末（ＭＴ）のユーザ装置（ＵＥ）コンテキストを変更するように第２の親ノードにユーザ装置コンテキスト変更要求（ＵＥ ＣＯＮＴＥＸＴ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージを送信し、少なくとも１つのベアラ（ｂｅａｒｅｒ）を設定する。

ステップ４０４：ＩＡＢノードが第２の親ノードに接続されていない場合、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、該ＩＡＢノードのＭＴのＵＥコンテキストを確立するように第２の親ノードにユーザ装置コンテキスト確立要求（ＵＥ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴ）メッセージを送信し、少なくとも１つのベアラ（ｂｅａｒｅｒ）を設定する。

図４に示すように、該方法は、以下のステップをさらに含む。

ステップ４０５：第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、該ＩＡＢノード及び／又は該ＩＡＢノードの子孫ノードに必要な第２の経路について、該ＩＡＢノードから第２のＩＡＢ－ｄｏｎｏｒ－ＤＵへのＢＨ ＲＬＣチャネルの構成及びＢＡＰサブレイヤのルーティングテーブルの構成を行う。

図４に示すように、該方法は、以下のステップをさらに含む。

ステップ４０６：第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、該ＩＡＢノードのために構成された第２のＢＡＰのアドレスを該ＩＡＢノードのモバイル端末（ＭＴ）に送信する。

例えば、ステップ４０６において、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、該ＩＡＢノードのモバイル端末（ＭＴ）に第２の再構成（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを送信してもよい。該第２のＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージはＢＡＰ構成情報（ｂａｐ－Ｃｏｎｆｉｇ）を含み、ＢＡＰ構成情報は該ＩＡＢノードのために構成された第２のＢＡＰのアドレスを含む。

本発明では、ステップ４０３～ステップ４０３によれば、ＩＡＢノードのために第２の経路を設定することができる。

図４に示すように、該方法は、以下のステップをさらに含む。

ステップ４０７：第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは冗長経路解放要求を受信又は送信する。

ステップ４０８：第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは冗長経路解放要求受け入れメッセージを送信又は受信する。

例えば、ステップ４０７において、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された冗長経路解放要求を受信し、ステップ４０８において、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに冗長経路解放要求受け入れメッセージを送信する。別の例として、ステップ４０７において、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに冗長経路解放要求を送信し、ステップ４０８において、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された冗長経路解放要求受け入れメッセージを受信する。

少なくとも１つの態様では、ステップ４０７の冗長経路解放要求は、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、冗長経路を解放する必要のあるＦ１－Ｃに関連するＴＮＬアドレス、又は冗長経路を解放する必要のあるＦ１－Ｕトンネルのユーザプレーン伝送層情報（ＵＰ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｉｎｆｏｒｍａｔｉｏｎ）を含む。ここで、冗長経路は、例えば、図２に示す第２の経路である。

第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ及び第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにおけるＭＮが冗長経路解放要求を送信した場合、冗長経路解放要求の内容及び冗長経路解放要求受け入れメッセージの内容は、ＩＥとして、セカンダリ基地局ノード変更準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順に含まれてもよい。

ＩＡＢノードのセカンダリ基地局ノード解放（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｒｅｌｅａｓｅ）手順を行う際に、セカンダリノード（ＳＮ）トポロジ内のＩＡＢノード（例えば、図２のＩＡＢノード３）に関連する全ての冗長経路を解放してもよい。

本発明の実施形態２によれば、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵと第２のＩＡＢ－ｄｏｎｏｒ－ＣＵとの間に冗長経路を確立することができるため、経路の多様性をさらに向上させ、負荷均衡及びサービス中断の低減のニーズをより良好に満足することができる。また、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵと第２のＩＡＢ－ｄｏｎｏｒ－ＣＵとの間のトポロジ冗長経路を解放することができる。

以下は、具体的な実施例を参照しながら、実施形態１に係る信号の送受信方法及び実施形態２に係る信号の送受信方法をより具体的に説明する。

（実施例１）
実施例１では、ＩＡＢノード（例えば、図２のＩＡＢノード３）は、２つの異なるＩＡＢ－ｄｏｎｏｒ－ＣＵに二重に接続された状態にあるため、実施例１では、ＩＡＢノード３は、二重接続ＩＡＢノード（Ｄｕａｌ－ｃｏｎｎｅｃｔｉｎｇ ＩＡＢ－ｎｏｄｅ）とも呼ばれる。

Ｆ１インターフェースは、ＩＡＢノードのＭＴが２つの異なるドナーに接続された後に確立される可能性があるため、Ｆ１終端ノードはＭＮである可能性があり、ＳＮである可能性がある。第１の経路において、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ（例えば、図２のＩＡＢ－ｄｏｎｏｒ－ＣＵ１）はＦ１終端ノードであり、本実施例では、マスタノード（ｍａｓｔｅｒ ｎｏｄｅ：ＭＮ）であってもよいし、セカンダリノード（ｓｅｃｏｎｄａｒｙ ｎｏｄｅ：ＳＮ）であってもよい。第２の経路において、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵ（例えば、図２のＩＡＢ－ｄｏｎｏｒ－ＣＵ２）は、非Ｆ１終端（ｎｏｎ－Ｆ１－ｔｅｒｍｉｎａｔｉｎｇ）ノードであり、本実施例では、ＳＮであってもよいし、ＭＮであってもよい。

図５は、実施例１におけるＩＡＢノードの第２の経路の確立手順の一例の概略図である。図５に示すように、該確立手順は、以下のステップを含む。

ステップ１：ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２にトラフィックオフロード要求（例えば、ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ）、即ち、二重接続ＩＡＢノードのために冗長経路を確立する要求を開始する。ＩＡＢ－ｄｏｎｏｒ－ＣＵ２が拒否した場合、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２は、次のステップを行うことなく、トラフィックオフロードを拒否する応答を直接送信する。

ステップ２：ＩＡＢ－ｄｏｎｏｒ－ＣＵ２がトラフィックオフロード要求に同意又は部分的に同意する場合、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２は、二重接続ＩＡＢノードの第２の親ノードのＩＡＢ－ＤＵにＵＥ ＣＯＮＴＥＸＴ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴメッセージを送信して、二重接続ＩＡＢ－ＭＴのＵＥコンテキストを変更し、１つ以上のベアラ（ｂｅａｒｅｒ）を設定する。

ステップ３：二重接続ＩＡＢノードの第２の親ノードのＩＡＢ－ＤＵは、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２にＵＥ ＣＯＮＴＥＸＴ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＳＰＯＮＳＥメッセージを応答する。

ステップ４：二重接続ＩＡＢノードに第２のＢＡＰアドレスを割り当てる必要がある場合、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２は、第２の親ノードのＩＡＢ－ＤＵにダウンリンク無線リンク制御メッセージ転送（例えば、ＤＬ ＲＲＣ ＭＥＳＳＡＧＥ ＴＲＡＮＳＦＥＲ）メッセージを送信し、該ダウンリンク無線リンク制御メッセージ転送は、生成されたＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを含む。このＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、構成された第２のＢＡＰアドレスを含むｂａｐ－Ｃｏｎｆｉｇを含んでもよい。

ステップ５：第２の親ノードは、受信したＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを二重接続ＩＡＢ－ＭＴに転送する。

ステップ６：二重接続ＩＡＢ－ＭＴは、第２の親ノードにＲＲＣ構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージを応答する。

ステップ７：第２の親ノードは、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２にアップリンク無線リンク制御メッセージ転送（ＵＬ ＲＲＣ ＭＥＳＳＡＧＥ ＴＲＡＮＳＦＥＲ）メッセージを送信し、該アップリンク無線リンク制御メッセージ転送は、受信したＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅメッセージを含む。

ステップ８：ＩＡＢ－ｄｏｎｏｒ－ＣＵ２は、第２の経路において二重接続ＩＡＢノードからＩＡＢ－ｄｏｎｏｒ－ＤＵ２へのＢＨ ＲＬＣチャネルの構成とＢＡＰサブレイヤのルーティングテーブルの構成（Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｏｆ ＢＡＰ ｒｏｕｔｅ ａｎｄ ｍａｐｐｉｎｇ ｒｕｌｅｓ ａｌｏｎｇ ｔｈｅ ｓｅｃｏｎｄ ｐａｔｈ ｂｅｔｗｅｅｎ ｄｕａｌ－ｃｏｎｎｅｃｔｉｎｇ ＩＡＢ－ｎｏｄｅ ａｎｄ ｔｈｅ ｓｅｃｏｎｄ ｐａｔｈ ＩＡＢ－ｄｏｎｏｒ－ＤＵ ｖｉａ ｔｈｅ ｓｅｃｏｎｄ ｐａｒｅｎｔ ＩＡＢ－ｎｏｄｅ．）を行う。ステップ８は、より早い段階、例えばステップ２の直後に行ってもよい。

ステップ９：ＩＡＢ－ｄｏｎｏｒ－ＣＵ２はＩＡＢ－ｄｏｎｏｒ－ＣＵ１にトラフィックオフロードに同意するメッセージを応答する。

ステップ１０：ＩＡＢ－ｄｏｎｏｒ－ＣＵ２の応答メッセージの内容（例えば、割り当てられたＴＮＬアドレスなど）に応じて、ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、第１の親ノードのＩＡＢ－ＤＵにＤＬ ＲＲＣ ＭＥＳＳＡＧＥ ＴＲＡＮＳＦＥＲメッセージを送信し、このメッセージは、生成されたＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを含む。このＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、二重接続ＩＡＢ－ＤＵに割り当てられた１つ以上のＴＮＬアドレスを含んでもよく、これらのアドレスは、第２の経路のＩＡＢ－ｄｏｎｏｒ－ＤＵ（例えば、図２のＤｏｎｏｒ－ＤＵ２）にアンカーされる。ＩＡＢ－ｄｏｎｏｒ－ＣＵ２は、Ｄｏｎｏｒ－ＤＵ２からこれらのＴＮＬアドレスをアクティブに取得できます。ＩＰｓｅｃトンネルモードがＦ１及び非Ｆ１トラフィックの保護に使用される場合、割り当てられたＴＮＬアドレスは、外部（ｏｕｔｅｒ）ＩＰアドレスである。二重接続ＩＡＢノードのＦ１－Ｃ又はＦ１－Ｕのために冗長経路が既に確立されている場合は、ＴＮＬアドレスが既に割り当てられているため、再割り当ては不要である。

ステップ１１：第１の親ノードは、受信したＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを二重接続ＩＡＢ－ＭＴに転送する。

ステップ１２：二重接続ＩＡＢ－ＭＴは、第２の親ノードにＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅメッセージを応答する。

ステップ１３：第１の親ノードは、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２にＵＬ ＲＲＣ ＭＥＳＳＡＧＥ ＴＲＡＮＳＦＥＲメッセージを送信し、このメッセージは、受信したＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅメッセージを伝える。

ステップ１５：ステップ１０において新しいＴＮＬアドレスが割り当てられた場合、これらのアドレスを二重接続ＩＡＢ－ＤＵとＩＡＢ－ｄｏｎｏｒ－ＣＵ１とのＦ１－Ｃアソシエーションに追加する（Ａｄｄｉｔｉｏｎ ｏｆ ｎｅｗ ＴＮＬ ａｄｄｒｅｓｓ（ｅｓ） ｔｏ ｄｕａｌ－ｃｏｎｎｅｃｔｉｎｇ ＩＡＢ－ｎｏｄｅ ＤＵ’ｓ Ｆ１－Ｃ ａｓｓｏｃｉａｔｉｏｎｓ．）。ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、第２の経路のＦ１ＡＰメッセージのために新しいＵＬ ＢＨ ｉｎｆｏｒｍａｔｉｏｎ（アップリンクバックホール情報）を構成してもよい。具体的な手順は、例えば、Ｆ１ＡＰのｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅ手順により実現されてもよい。

ステップ１６：ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、ＵＥ ＣＯＮＴＥＸＴ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴメッセージを介して、ＩＡＢ－ｄｏｎｏｒ－ＣＵ１から二重接続ＩＡＢ－ＤＵへのＦ１－Ｕトンネルを第１の経路から第２の経路に移行（ｍｉｇｒａｔｅ）してもよい。

ステップ１７：二重接続ＩＡＢ－ＤＵは、ＵＥ ＣＯＮＴＥＸＴ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＳＰＯＮＳＥメッセージに応答する。

これによって、二重接続ＩＡＢノードの第２の経路を確立することができ、アップリンクユーザデータ（ｕｐｌｉｎｋ ｕｓｅｒ ｄａｔａ）又はダウンリンクユーザデータ（ｄｏｗｎｌｉｎｋ ｕｓｅｒ ｄａｔａ）を第２の経路を介してユーザ装置（ＵＥ）と第１のＩＡＢ－ｄｏｎｏｒ－ＣＵとの間で伝送することができる。

例えば、図５に示すように、第２の経路において、アップリンクユーザデータの伝送順序は、ＵＥ→二重接続ＩＡＢノード→第２の親ノード→第２の経路上の中間ホップＩＡＢノード（Ｉｎｔｅｒｍｅｄｉａｔｅ ｈｏｐ ＩＡＢ－ｄｏｎｏｒ ｏｎ ｔｈｅ ｓｅｃｏｎｄ ｐａｔｈ）→第２の経路上のドナー分散ユニット（例えば、図２のＤｏｎｏｒ－ＤＵ２）→第１のＩＡＢ－ｄｏｎｏｒ－ＣＵである。

別の例として、図５に示すように、第２の経路において、ダウンリンクユーザデータの伝送順序は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ→第２の経路上のドナー分散ユニット（例えば、図２のＤｏｎｏｒ－ＤＵ２）→第２の経路上の中間ホップＩＡＢノード（Ｉｎｔｅｒｍｅｄｉａｔｅ ｈｏｐ ＩＡＢ－ｄｏｎｏｒ ｏｎ ｔｈｅ ｓｅｃｏｎｄ ｐａｔｈ）→第２の親ノード→二重接続ＩＡＢノード→ＵＥである。

実施例１では、ステップ４～７は、二重接続ＩＡＢノードに第２のＢＡＰアドレスを割り当てることである。第２のＢＡＰアドレスは、冗長経路（即ち、第２の経路）上のＢＡＰルーティング構成のために使用されてもよい。二重接続ＩＡＢノードは、ＢＡＰアドレスをマスタセルグループ（ｍａｓｔｅｒ ｃｅｌｌ ｇｒｏｕｐ：ＭＣＧ）／セカンダリセルグループ（ｓｅｃｏｎｄａｒｙ ｃｅｌｌ ｇｒｏｕｐ：ＳＣＧ）又はＭＮ／ＳＮに関連付ける必要がある。二重接続ノードにより受信されたＢＡＰアドレスを有するＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがＭＣＧからのもの又はＳＲＢ１（ＳＲＢ：ｓｉｇｎａｌｌｉｎｇ ｒａｄｉｏ ｂｅａｒｅｒ：シグナリング無線ベアラ）を介して受信されたものである場合、受信されたＢＡＰアドレスをＭＣＧ又はＭＮに関連付ける。二重接続ノードにより受信されたＢＡＰアドレスを有するＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがＳＣＧからのもの又はＳＲＢ３を介して受信されたものである場合、受信されたＢＡＰアドレスをＳＣＧ又はＳＮに関連付ける。

また、別の方法を使用して第２のＢＡＰアドレスを割り当ててもよい。例えば、ステップ４～７を省略し、第２のＢＡＰアドレスをステップ１０～１３に入れ、他のＲＲＣ構成メッセージと共に送信してもよい。これには、既存のＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージフォーマットを変更する必要があり、以下の２つの変更方法がある。

方法１：ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージのｂａｐ－Ｃｏｎｆｉｇ ＩＥ（ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ：情報要素）に、例えばｂａｐ－Ａｄｄｒｅｓｓ－ｒｅｄｕｎｄａｎｔ又はｂａｐ－Ａｄｄｒｅｓｓ－ｓｅｃｏｎｄなどのフィールドを追加し、このフィールドは第２のＢＡＰアドレスを表すことを示す。

方法２：ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージのｂａｐ－Ｃｏｎｆｇ ＩＥにおけるｂａｐ－Ａｄｄｒｅｓｓフィールドをｂａｐ－ＡｄｄｒｅｓｓＬｉｓｔなどのリストに変更する。このリストにおける各エントリは、ＢＡＰアドレスとその関連情報であり、該エントリは、例えば｛ｂａｐ－Ａｄｄｒｅｓｓ，‘ＭＣＧ’／‘ＳＣＧ’｝又は｛ｂａｐ－Ａｄｄｒｅｓｓ，ｉａｂ－ｄｏｎｏｒ－ＤＵ－ＢＡＰ－Ａｄｄｒｅｓｓ｝などである。

（実施例２）
実施例２では、ＩＡＢノード（例えば、図２のＩＡＢノード３）は、２つの異なるＩＡＢ－ｄｏｎｏｒ－ＣＵに二重に接続された状態であるため、実施例２では、ＩＡＢノード３は、二重接続ＩＡＢノード（Ｄｕａｌ－ｃｏｎｎｅｃｔｉｎｇ ＩＡＢ－ｎｏｄｅ）とも呼ばれる。

実施例２は、ＩＡＢノードの子孫ノード（例えば、図２のＩＡＢノード４）のためにドナー間の冗長経路を確立する方法を説明するために使用される。

図６は、実施例２におけるＩＡＢノードの子孫ノードのためにドナー間の冗長経路を確立する方法の一例の概略図である。図示を簡略化するために、子孫ＩＡＢノードと二重接続ＩＡＢノードとの間の可能なノードは示されていない。以下は、図６の図５との相違点について説明するが、同一又は実質的に同様なステップについて、実施例１の説明を参照されたい。

図６に示すように、この確立手順は、以下のステップを含む。

ステップ１：ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２にトラフィックオフロード要求を開始し、該要求は、二重接続ＩＡＢノードの子孫ノードのために冗長経路を確立する要求を含む。

ステップ４～７：ステップ４～７は、実施例１のステップ４～７と同様に、二重接続ＩＡＢノード又は他の子孫ＩＡＢノードが以前に冗長経路を確立していない場合、二重接続ＩＡＢノードに第２のＢＡＰアドレスを割り当てる。また、二重接続ＩＡＢノードに第２のＢＡＰアドレスが既に割り当てられている場合、ステップ４～７は、実行せずにスキップしてもよい。

ステップ８：必要に応じて、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２は、第２の経路において、子孫ノードのために、二重接続ＩＡＢノードからＩＡＢ－ｄｏｎｏｒ－ＤＵ２へのＢＨ ＲＬＣチャネルの構成及びＢＡＰサブレイヤのルーティングテーブルの構成を行う。実施例１の二重接続ＩＡＢノードについての方法と同様である。

ステップ１０：図１のステップ１０と同様に、ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２の応答メッセージに応じて、子孫ＩＡＢノードのために１つ以上のＴＮＬアドレスを構成し、該１つ以上のＴＮＬアドレスは、ＩＡＢ－ｄｏｎｏｒ－ＤＵ２にアンカーされる。

ステップ１４：ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、第２の経路のルーティング及びＢＨ ＲＬＣチャネルマッピングをサポートするために、二重接続ＩＡＢノードから子孫アクセスＩＡＢノードへのＢＨ ＲＬＣチャネルの構成及びＢＡＰサブレイヤのルーティングテーブルの構成（Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｏｆ ＢＡＰ ｒｏｕｔｅ ａｎｄ ｍａｐｐｉｎｇ ｒｕｌｅｓ ａｌｏｎｇ ｔｈｅ ｐａｔｈ ｂｅｔｗｅｅｎ ｄｕａｌ－ｃｏｎｎｅｃｔｉｎｇ ＩＡＢ－ｎｏｄｅ ａｎｄ ｔｈｅ ａｃｃｅｓｓ ＩＡＢ－ｎｏｄｅ ｆｏｒ ｔｈｅ ｒｅｄｕｎｄａｎｔ ｐａｔｈ．）を行う。ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、さらに、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２の応答メッセージ（例えば、ステップ９において送信される）に応じて、２つのトポロジ間のＢＡＰルーティング変換のために、二重接続ＩＡＢノードのためにＢＡＰルーティング識別子マッピングの構成（Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｏｆ ＢＡＰ ｒｏｕｔｉｎｇ ＩＤ ｍａｐｐｉｎｇ）を行う。これらの構成は、より早い段階、例えばステップ１０の直後に行ってもよい。

ステップ１５：ステップ１０において新しいＴＮＬアドレスが割り当てられた場合、これらのアドレスを子孫ＩＡＢ－ＤＵとＩＡＢ－ｄｏｎｏｒ－ＣＵ１とのＦ１－Ｃアソシエーションに追加する。ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、第２の経路のＦ１ＡＰメッセージのために新しいアップリンクバックホール情報（ＵＬ ＢＨ ｉｎｆｏｒｍａｔｉｏｎ）を構成してもよい。

ステップ１６：ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、ＵＥ ＣＯＮＴＥＸＴ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴメッセージを介して、自分から二重接続ＩＡＢノードの子孫ＩＡＢ－ＤＵへのＦ１－Ｕトンネルを第１の経路から第２の経路に移行（ｍｉｇｒａｔｅ）してもよい。

ステップ１７：子孫ＩＡＢ－ＤＵは、ＵＥ ＣＯＮＴＥＸＴ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＳＰＯＮＳＥメッセージを応答する。

これによって、二重接続ＩＡＢノードの子孫ノードの第２の経路を確立することができ、アップリンクユーザデータ（ｕｐｌｉｎｋ ｕｓｅｒ ｄａｔａ）又はダウンリンクユーザデータ（ｄｏｗｎｌｉｎｋ ｕｓｅｒ ｄａｔａ）を第２の経路を介してユーザ装置（ＵＥ）と第１のＩＡＢ－ｄｏｎｏｒ－ＣＵとの間で伝送することができる。

例えば、図６に示すように、第２の経路において、アップリンクユーザデータの伝送順序は、ＵＥ→子孫ノード→二重接続ＩＡＢノード→第２の親ノード→第２の経路上の中間ホップＩＡＢノード（Ｉｎｔｅｒｍｅｄｉａｔｅ ｈｏｐ ＩＡＢ－ｄｏｎｏｒ ｏｎ ｔｈｅ ｓｅｃｏｎｄ ｐａｔｈ）→第２の経路上のドナー分散ユニット（例えば、図２のＤｏｎｏｒ－ＤＵ２）→第１のＩＡＢ－ｄｏｎｏｒ－ＣＵである。

別の例として、図６に示すように、第２の経路において、ダウンリンクユーザデータの伝送順序は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ→第２の経路上のドナー分散ユニット（例えば、図２のＤｏｎｏｒ－ＤＵ２）→第２の経路上の中間ホップＩＡＢノード（Ｉｎｔｅｒｍｅｄｉａｔｅ ｈｏｐ ＩＡＢ－ｄｏｎｏｒ ｏｎ ｔｈｅ ｓｅｃｏｎｄ ｐａｔｈ）→第２の親ノード→二重接続ＩＡＢノード→子孫ノード→ＵＥである。

異なる実装に応じて、子孫ＩＡＢノードのための冗長経路を確立する手順は、二重接続ＩＡＢノードのために冗長経路を確立した後であってもよく、即ち、図６の手順は、図５の手順の後であってもよい。或いは、子孫ＩＡＢノードのために冗長経路を確立する手順は、二重接続ＩＡＢノードのために冗長経路を確立すると同時に行われてもよく、即ち、図６の手順は、図５の手順と同時に行われてもよい。

（実施例３）
実施例３では、ＩＡＢノードの冗長経路が確立される前に、該ＩＡＢノード（例えば、図２のＩＡＢノード３）は単一接続ノードであり、即ち、ＩＡＢノードはＩＡＢ－ｄｏｎｏｒ－ＣＵ１に接続されている。

ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、本トポロジネットワークのトラフィックが過負荷であり、他のＤｏｎｏｒ－ＣＵにより管理されたネットワークトポロジによりトラフィックオフロードが必要であると判断した場合、このＩＡＢノードに対してＳＮ（例えば、図２のＩＡＢ－ｄｏｎｏｒ－ＣＵ２）を追加する操作を行い、即ち、このＩＡＢノードをドナーに跨る（即ち、ｉｎｔｅｒ－ＣＵとなる）二重接続とすると共に、一部のトラフィックをＩＡＢ－ｄｏｎｏｒ－ＣＵ２のトポロジにオフロードして冗長経路を確立する。

図７は、ＩＡＢノードにＳＮを追加して二重接続ノードに変更し、冗長経路を確立することを示す概略図である。説明を簡単にするために、二重接続状態のＩＡＢノードが第２のＢＡＰアドレスを割り当てるステップは、図５のステップ５～７を参照してもよいため、図７には示されていない。以下は、図７に示す手順の図５との相違点を中心に説明するが、同様な部分についてその説明を省略する。

図７の手順は、以下のステップを含む。

ステップ１：ＩＡＢ－ＭＴは、第１の親ノードのＩＡＢ－ＤＵに測定レポート（例えば、ＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔ）メッセージを送信し、このレポートは、このＩＡＢ－ＭＴがＩＡＢ－ｄｏｎｏｒ－ＣＵ１から以前に受信した測定構成（例えば、Ｍｅａｓｕｒｅｍｅｎｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）に基づいて生成されてもよい。

ステップ２：第１の親ノードのＩＡＢ－ＤＵは、受信したＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔを送信するために、ＩＡＢ－ｄｏｎｏｒ－ＣＵ１にＵＬ ＲＲＣ ＭＥＳＳＡＧＥ ＴＲＡＮＳＦＥＲメッセージを送信する。

ステップ３：ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２に対して、ＳＮ追加要求（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージを開始し、このメッセージは、トラフィックオフロード要求、即ち、ＩＡＢノード（例えば、図２のＩＡＢノード３）のために冗長経路を確立する要求を含む。具体的なシグナリングは、実施例４を参照されたい。ＩＡＢ－ｄｏｎｏｒ－ＣＵ２がＳＮを追加する要求を拒否する場合、以下のステップを行うことなく、トラフィックオフロードを拒否する応答を送信してもよい。ＩＡＢ－ｄｏｎｏｒ－ＣＵ２がＳＮを追加する要求に同意し、且つトラフィックオフロードの要求を拒否する場合、以下のステップを行うことなく、直接既存の基準に従ってＳＮを追加する手順を実行する。応答メッセージには、トラフィックオフロードを拒否する内容が含まれる。

ステップ４：トラフィックオフロード要求に同意又は部分的に同意する場合、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２は、ＩＡＢ－ＭＴのＵＥコンテキストを確立するために、ＩＡＢノードの第２の親ノードのＩＡＢ－ＤＵにＵＥ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴメッセージを送信し、１つ以上のベアラ（ｂｅａｒｅｒ）を設定し、該１つ以上のベアラは、ＩＡＢ－ＭＴ自身のシグナリング及びオプションのデータトラフィックのために使用されてもよい。

ステップ５：ＩＡＢノードの第２の親ノードのＩＡＢ－ＤＵは、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２にＵＥ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＳＰＯＮＳＥメッセージを応答する。

ステップ７：ＩＡＢ－ｄｏｎｏｒ－ＣＵ２は、ＩＡＢ－ｄｏｎｏｒ－ＣＵ１にＳＮ追加要求承認（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージを応答し、該メッセージは、トラフィックオフロードに同意するＩＥを含む。

ステップ１２：ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２にセカンダリノード再構成完了（例えば、Ｓ－ＮＯＤＥ ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ ＣＯＭＰＬＥＴＥ）メッセージを送信し、該メッセージは、ＩＡＢノードへの二重接続構成が正常に完了したことを示す。

ステップ１３：ＩＡＢノードは、第２の親ノードのＩＡＢ－ＤＵにおいてランダムアクセス手順を実行する。

図７の他のステップの説明は、実施例１と同様である。また、図７において、ステップ３のメッセージに子孫ＩＡＢノードのために冗長経路を確立する必要がある要求が含まれている場合、実施例２を参照して対応する操作を行ってもよい。

（実施例４）
実施例４は、ＩＡＢ－ｄｏｎｏｒ－ＣＵ１とＩＡＢ－ｄｏｎｏｒ－ＣＵ２との間のシグナリング、即ちＸｎＡＰ（Ｘｎ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：Ｘｎアプリケーションプロトコル）手順を説明するために使用される。ＩＡＢ－ｄｏｎｏｒ－ＣＵ１は、Ｆ１－Ｃ又は１つ以上のＦ１－ＵトンネルをＩＡＢ－ｄｏｎｏｒ－－ＣＵ２のトポロジ冗長経路に移行するためのトラフィックオフロード要求をＩＡＢ－ｄｏｎｏｒ－ＣＵ２に送信する。

実施例１及び２について、新しいＸｎＡＰメッセージと共に、例えばトラフィックオフロード（Ｔｒａｆｆｉｃ Ｏｆｆｌｏａｄ）手順などの新しい二重接続に関連するＸｎＡＰ手順を追加してもよい。

図８は、成功したトラフィックオフロード手順の一例の概略図である。図８に示すように、ＮＧ－ＲＡＮノード１（即ち、ＩＡＢ－ｄｏｎｏｒ－ＣＵ１）は、ＮＧ－ＲＡＮノード２（即ち、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２）にトラフィックオフロード要求のメッセージ、例えばＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴメッセージを送信する。ＮＧ－ＲＡＮノード２は、受け入れ又は部分的な受け入れのメッセージ、例えばＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージを応答する。部分的な受け入れとは、幾つかのＴＮＬに関連するＦ１－Ｃ、又は幾つかのＦ１－Ｕトンネルのために冗長経路を確立することを意味する。

図９は、失敗したトラフィックオフロード手順の一例の概略図である。図９に示すように、ＮＧ－ＲＡＮノード１（即ち、ＩＡＢ－ｄｏｎｏｒ－ＣＵ１）は、ＮＧ－ＲＡＮノード２（即ち、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２）に、トラフィックオフロード要求メッセージ、例えばＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴメッセージを送信する。ＮＧ－ＲＡＮノード２自体に高いトラフィック負荷がある場合、又は他の障害が発生している場合、冗長経路が確立されないように、全てのトラフィックオフロード要求を拒否してもよい。このトラフィックオフロード拒否メッセージは、ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴメッセージと称されてもよく、該メッセージは、失敗の原因（ｃａｕｓｅ）を含んでもよい。

トラフィックオフロード要求メッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、及び／又は１つ以上のＦ１－Ｃの識別情報を含んでもよい。従って、１つ以上のアクセスＩＡＢノードのために冗長経路を確立することができる。これらのアクセスＩＡＢノードは、二重接続ＩＡＢノード又は二重接続になる予定のあるＩＡＢノードであってもよいし、二重接続ＩＡＢノードの子孫ＩＡＢノードであってもよい。トラフィックオフロード要求メッセージは、アクセスＩＡＢノードのＢＡＰアドレスをさらに含んでもよい。Ｆ１－Ｃ識別情報は、ＴＮＬアソシエーション（ａｓｓｏｃｉａｔｉｏｎ）であってもよいし、ＴＮＬアソシエーションの伝送層情報（例えば、ＩＡＢ－ＤＵ制御プレーン伝送層アドレス、即ちＴＮＬアドレス）であってもよい。該ＴＮＬアソシエーションに対してＦ１－Ｃのトラフィックオフロードを行うことを明示的に指示してもよいし、Ｆ１－Ｕの情報を提供せず、該ＴＮＬアソシエーションに対してＦ１－Ｃのトラフィックオフロードを行うことを暗黙的に指示してもよい。

Ｆ１－Ｃに対するトラフィックオフロード要求を受け入れる場合、Ｔｒａｆｆｉｃ Ｏｆｆｌｏａｄ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、該Ｆ１－Ｃの識別情報、ＩＡＢ－ｄｏｎｏｒ－ＤＵ２によりアクセスＩＡＢ－ＤＵのために新たに割り当てられたＴＮＬアドレス、該Ｆ１－Ｃのために構成された二重接続ＩＡＢノードと第２の親ノードとの間のリンク上のＢＨ ＲＬＣチャネル識別子、第２の親ノードのＢＡＰアドレス、ＣＵ２により制御されたトポロジにおけるＢＡＰルーティング識別子（アップリンクとダウンリンクを含む）、可能な二重接続ＩＡＢノードの第２のＢＡＰアドレスなどを含んでもよい。ここで、第２の親ノードのＢＡＰアドレスは、Ｄｏｎｏｒ－ＣＵ１が二重接続ＩＡＢノードのためにルーティングテーブルを構成する際に冗長経路のアップリンクルーティングのネクストホップノードを構成するために使用される。Ｄｏｎｏｒ－ＣＵ２により制御されたトポロジにおけるＢＡＰルーティング識別子は、Ｄｏｎｏｒ－ＣＵ１が二重接続ＩＡＢノードのためにＢＡＰルーティング識別子マッピングを構成する際に使用される、Ｄｏｎｏｒ－ＤＵ２から二重接続ＩＡＢノードへのアップリンク又はダウンリンクのＢＡＰルーティング識別子を意味する。

トラフィックオフロード要求メッセージは、１つ以上のＦ１－Ｕトンネル、即ち、これらのＦ１－Ｕトンネルのために冗長経路を確立することを表すデータ無線ベアラ（ｄａｔａ ｒａｄｉｏ ｂｅａｒｅｒ：ＤＲＢ）の識別情報をさらに含んでもよい。Ｆ１－Ｕトンネル識別情報は、伝送層アドレス及びＧＴＰ－ＴＥＩＤ（ＧＰＲＳ Ｔｕｎｎｅｌｌｉｎｇ Ｐｒｏｔｏｃｏｌ－Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ＩＤ）を含む、ＵＰ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｉｎｆｏｒｍａｔｉｏｎ（ユーザプレーン伝送層情報）であってもよい。要求メッセージは、アクセスＩＡＢノードのＢＡＰアドレス、ＴＮＬアドレス、Ｆ１－ＵのＩＰ ｈｅａｄｅｒ ｉｎｆｏｒｍａｔｉｏｎ（ＩＰヘッダ情報）、ＱｏＳ情報などをさらに含んでもよい。ＩＰヘッダ情報は、Ｄｏｎｏｒ－ＤＵ２でＩＰレイヤからレイヤ２（ｌａｙｅｒ ２）へのトラフィックマッピングを行うために使用され、ＱｏＳ情報は、冗長経路の各ホップにおいてＢＨ ＲＬＣチャネルの選択及び構成を行うために使用される。ＱｏＳ情報は、ＴＲ３８．４７３で定義されたＤＲＢ ＱｏＳ ＩＥであってもよいし、例えば５ＱＩ（５Ｇ ＱｏＳ Ｉｄｅｎｔｉｆｉｅｒ）などのＩＥにおける部分情報であってもよい。Ｆ１－Ｕトンネルのためのトラフィックオフロード要求を受け入れ又は部分的に受け入れる場合、Ｔｒａｆｆｉｃ Ｏｆｆｌｏａｄ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージは、受け入れられたＦ１－Ｕトンネルの識別情報、該Ｆ１－Ｕトンネルのために構成された二重接続ＩＡＢノードと第２の親ノードとの間のリンクでのＢＨ ＲＬＣチャネル識別子をさらに含んでもよく、新しいＴＮＬアドレス、第２の親ノードのＢＡＰアドレス、ＣＵ２により制御されたトポロジ内のＢＡＰルーティング識別子（アップリンクとダウンリンクを含む）、可能な二重接続ＩＡＢノードの第２のＢＡＰアドレスなどをさらに含んでもよい。

既に二重接続があり、且つＭＮがトラフィックオフロード要求を開始する場合、これらの要求と応答メッセージの内容の両方をＩＥとして、既存ＸｎＡＰのＳ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ（セカンダリ基地局ノード変更準備）手順に含めてもよい。即ち、例えばＳ－ＮＯＤＥ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ、Ｓ－ＮＯＤＥ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ、Ｓ－ＮＯＤＥ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＪＥＣＴなどの既存のメッセージを再利用する。ここで、既存のメッセージを再利用する場合、全てのトラフィックオフロード要求を拒否し、且つその他の変更要求に同意するとき、Ｓ－ＮＯＤＥ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージを依然として使用する。変更要求に何れも同意せず、且つトラフィックオフロード要求に何れも同意せず、或いは失敗した場合にのみ、Ｓ－ＮＯＤＥ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＪＥＣＴメッセージを使用する。

実施例３であれば、これらのメッセージの内容をそれぞれＩＥとして、既存のＸｎＡＰ のＳ－ＮＧ－ＲＡＮ ｎｏｄｅ Ａｄｄｉｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ（セカンダリ基地局ノード追加準備）手順に含めてもよい。即ち、例えばＳ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ、Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ、Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＪＥＣＴなどの既存のメッセージを再利用する。ここで、既存のメッセージを再利用する場合、全てのトラフィックオフロード要求を拒否し、且つＳＮ要求の追加に同意したとき、Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージを依然として使用する。ＳＮを追加できず、或いは失敗した場合にのみ、Ｓ－ＮＯＤＥ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＪＥＣＴメッセージを使用する。

（実施例５）
実施例５は、ＩＡＢ－ｄｏｎｏｒ－ＣＵ１とＩＡＢ－ｄｏｎｏｒ－ＣＵ２との間の冗長経路の解放手順を説明するために使用される。

ＮＧ－ＲＡＮノード１（即ち、ＩＡＢ－ｄｏｎｏｒ－ＣＵ１）及びＮＧ－ＲＡＮノード２（即ち、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２）の両方が、冗長経路の解放手順を開始してもよい。解放手順を実現するために、新しい二重接続に関連するＸｎＡＰ手順を追加してもよい。

トラフィックオフロードの開始側（例えば、ＩＡＢ－ｄｏｎｏｒ－ＣＵ１）と受け入れ側（例えば、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２）の両方は、冗長経路解放を開始してもよい。図１０は、トラフィックオフロードの開始側による冗長経路解放の一例の概略図であり、図１１は、トラフィックオフロードの受け入れ側による冗長経路解放の一例の概略図である。

図１０及び図１１に示すように、トラフィックオフロードの開始側（例えば、ＩＡＢ－ｄｏｎｏｒ－ＣＵ１）により開始された冗長経路解放と受け入れ側（例えば、ＩＡＢ－ｄｏｎｏｒ－ＣＵ２）により開始された冗長経路解放とを区別するために、異なるメッセージ名を使用してもよい。例えば、図１０に示すように、トラフィックオフロードの開始側、即ちＦ１終端ドナーノードは、非Ｆ１終端ドナーノードにトラフィックオフロード解放要求（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＬＥＡＳＥ ＲＥＱＵＥＳＴ）メッセージを送信し、非Ｆ１終端ドナーノードは、トラフィックオフロード解放承認（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＬＥＡＳＥ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージを応答してもよい。図１１に示すように、非Ｆ１終端ドナーノードは、Ｆ１終端ドナーノードにトラフィックオフロード解放要求（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＬＥＡＳＥ ＲＥＱＵＩＲＥＤ）メッセージを送信し、Ｆ１終端ドナーノードは、トラフィックオフロード解放確認（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＬＥＡＳＥ ＣＯＮＦＩＲＭ）メッセージを応答してもよい。

ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＬＥＡＳＥ ＲＥＱＵＥＳＴ／ＲＥＱＵＩＲＥＤメッセージは、冗長経路を解放する必要のあるＦ１－Ｃに関連するＴＮＬアドレス、又は冗長経路を解放する必要のあるＦ１－ＵトンネルのＵＰ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｉｎｆｏｒｍａｔｉｏｎを含む。

冗長経路解放の具体的な手順は以下の通りである。必要に応じて、Ｄｏｎｏｒ－ＣＵ１及び／又はＤｏｎｏｒ－ＣＵ２は、冗長経路に関するＢＡＰルーティングエントリを解放し、冗長経路に必要なＢＨ ＲＬＣチャネルを変更又は解放する。必要に応じて、Ｄｏｎｏｒ－ＣＵ１は、二重接続ＩＡＢノード上の関連するＢＡＰルーティング識別子のマッピング情報を削除する。

ＭＮが冗長経路解放手順を開始する場合、上記の要求と応答メッセージの内容をそれぞれＩＥとして、既存のＸｎＡＰのＳ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ（セカンダリ基地局ノード変更準備）手順に含めてもよい。即ち、例えばＳ－ＮＯＤＥ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ、Ｓ－ＮＯＤＥ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥなどの既存のメッセージを再利用する。

Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｒｅｌｅａｓｅ（セカンダリ基地局ノード解放）手順を行う際に、ＳＮトポロジ内の全ての冗長経路を解放する。

＜実施形態３＞
本発明の実施形態３は、少なくとも実施形態１と同様な問題点について、実施形態１の方法に対応する信号の送受信方法を提供する。本発明の実施形態３に係る信号の送受信方法は、ＩＡＢノードに適用される。該ＩＡＢノードは、例えば図２のＩＡＢノード３である。

図１２は、実施形態３に係る信号の送信及び受信方法の一例の概略図である。図１２に示すように、該方法は、以下のステップを含む。

ステップ１２０１：第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第１のＲＲＣ再構成メッセージを受信する。

ステップ１２０２：第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにＲＲＣ再構成完了メッセージを送信する。

ここで、第１のＲＲＣ再構成メッセージは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたトラフィックオフロードに同意する応答に応じて生成される。該第１のＲＲＣ再構成メッセージは、該ＩＡＢノードのＤＵに割り当てられた少なくとも１つのＴＮＬアドレスを含み、該ＴＮＬアドレスは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵにアンカーされる。

第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）は、ＩＡＢノードのために構成された第２のＢＡＰアドレスを示すためのフィールドを含み、或いは、第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）におけるＢＡＰアドレスフィールドは、リストを含み、該リストにおける各エントリは、ＢＡＰアドレス及びその関連情報である。

ステップ１２０２におけるＲＲＣ再構成完了（例えば、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、該ＩＡＢノードが第１のＲＲＣ再構成メッセージを受信したことを示すために使用される。また、ＲＲＣ再構成完了メッセージは、該ＩＡＢノードが再構成を完了したことをさらに示してもよい。

ステップ１２０１及びステップ１２０２によれば、ＩＡＢノードのためにドナーに跨る冗長経路を確立することができる。

図１２に示すように、該方法は、以下のステップをさらに含む。

ステップ１２０３：ＩＡＢノードは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第２のＲＲＣ再構成（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを受信する。

ステップ１２０４：ＩＡＢノードは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージを送信する。

ステップ１２０３において、第２のＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、ＢＡＰ構成情報（ｂａｐ－Ｃｏｎｆｉｇ）を含み、該ＢＡＰ構成情報は、該ＩＡＢノードのために構成された第２のＢＡＰアドレスを含む。ステップ１２０４において、再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、該ＩＡＢノードが該第２のＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信したことを示すために使用される。

図１２に示すように、該方法は、以下のステップをさらに含む。

ステップ１２０５：ＩＡＢノードは、第２のＢＡＰアドレスをマスタセルグループ（ＭＣＧ：ｍａｓｔｅｒ ｃｅｌｌ ｇｒｏｕｐ）／セカンダリセルグループ（ＳＣＧ：ｓｅｃｏｎｄａｒｙ ｃｅｌｌ ｇｒｏｕｐ）又はマスタノード（ＭＮ）／セカンダリノード（ＳＮ）に関連付ける。

例えば、該ＩＡＢノードにより受信された、第２のＢＡＰアドレスを有する該第２のＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがＭＣＧからのもの又はシグナリング無線ベアラ１（ＳＲＢ：ｓｉｇｎａｌｌｉｎｇ ｒａｄｉｏ ｂｅａｒｅｒ）を介して受信されたものである場合、第２のＢＡＰアドレスをＭＣＧ又はＭＮに関連付け、ＩＡＢノードにより受信された、第２のＢＡＰアドレスを有する第２のＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがＳＣＧからのもの又はＳＲＢ３を介して受信されたものである場合、該第２のＢＡＰアドレスをＳＣＧ又はＳＮに関連付ける。

＜実施形態４＞
本発明の実施形態４は、少なくとも実施形態１と同様な問題点について、実施形態１の方法に対応する信号の送受信方法を提供する。本発明の実施形態４に係る信号の送受信方法は、ＩＡＢノードの子孫ノードに適用される。該子孫ノード、例えば図２のＩＡＢノード４である。

図１３は、実施形態３に係る信号の送信及び受信方法の一例の概略図である。図１３に示すように、該方法は、以下のステップを含む。

ステップ１３０１：第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第１のＲＲＣ再構成メッセージを受信する。

ステップ１３０２：第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにＲＲＣ再構成完了メッセージを送信する。

ここで、ステップ１３０１における第１のＲＲＣ再構成メッセージは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたトラフィックオフロードに同意する応答に応じて生成される。該第１のＲＲＣ再構成メッセージは、該子孫ノードのＤＵに割り当てられた少なくとも１つのＴＮＬアドレスを含み、該ＴＮＬアドレスは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵにアンカーされる。

ここで、ステップ１３０２におけるＲＲＣ再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、該子孫ノードが該第１のＲＲＣ再構成メッセージを受信したことを示すために使用される。また、該ＲＲＣ再構成完了メッセージは、該子孫ノードが再構成を完了したことをさらに示してもよい。

実施形態４によれば、ＩＡＢノードの子孫ノードのためにドナーに跨る冗長経路を確立することができる。

＜実施形態５＞
本発明の実施例は、信号の送受信装置を提供する。該装置は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに適用される。該装置は、第１のＤｏｎｏｒ－ＣＵであってもよいし、第１のＤｏｎｏｒ－ＣＵの一部のユニットであってもよい。該装置は、実施形態１の方法に対応する。

図１４は、本発明の実施形態に係る信号の送受信装置の一例の概略図である。図１４に示すように、信号の送受信装置１４００は、第１の送受信部１４０１を含む。

第１の送受信部１４０１は、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロード要求を送信し、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信されたトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を受信するように構成される。

少なくとも１つの態様では、第１の送受信部１４０１は、トラフィックオフロードに同意する応答に応じて、ＩＡＢノード及び／又はＩＡＢノードの子孫ＩＡＢノードに第１のＲＲＣ再構成メッセージを送信するように構成される。

ここで、該第１のＲＲＣ再構成メッセージは、該ＩＡＢノード及び／又は該ＩＡＢノードの子孫ノードのＤＵにそれぞれ割り当てられた少なくとも１つのＴＮＬアドレスを含み、該ＴＮＬアドレスは、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵにアンカーされ、該ＩＡＢノードは、第１の親ノードに接続されており、該第１の親ノードは、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、該ＩＡＢノードは、第２の親ノードに既に接続されており、或いは接続される予定であり、該第２の親ノードは、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである。

少なくとも１つの態様では、該第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）は、該ＩＡＢノードのために構成された第２のＢＡＰアドレスを示すためのフィールドを含み、或いは、該第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）におけるＢＡＰアドレスフィールドは、リストを含み、該リストにおける各エントリは、ＢＡＰアドレス及びその関連情報である。

少なくとも１つの態様では、該第１の送受信部は、新しいＴＮＬアドレスが割り当てられた場合、該新しいＴＮＬアドレスを該ＩＡＢノード及び／又は該ＩＡＢノードの子孫ノードのＤＵと該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵとのＦ１－Ｃアソシエーションに追加するように構成される。

少なくとも１つの態様では、該トラフィックオフロード要求は、ＩＡＢノード及び／又は該ＩＡＢノードの子孫ノードのために冗長経路を確立する要求を含む。

少なくとも１つの態様では、該第１の送受信部１４０１は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが第２の経路のルーティング及びＢＨ ＲＬＣチャネルマッピングをサポートするために、該ＩＡＢノードから該ＩＡＢノードの子孫ノードへのＢＨ ＲＬＣチャネルの構成及びＢＡＰサブレイヤのルーティングテーブルの構成を行うように構成される。

少なくとも１つの態様では、該第１の送受信部１４０１は、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが該トラフィックオフロードに同意する応答に応じて、該ＩＡＢノードに対してＢＡＰルーティング識別子マッピングの構成を行うように構成される。

少なくとも１つの態様では、該第１の送受信部１４０１は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが、ユーザ装置コンテキスト変更要求（ＵＥ ＣＯＮＴＥＸＴ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージ又はユーザ装置コンテキスト確立要求（ＵＥ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴ）メッセージを介して、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵから該ＩＡＢノード及び／又は前記ＩＡＢノードの子孫ノードのＤＵへのＦ１－Ｕトンネルを第１の経路から第２の経路に移行（ｍｉｇｒａｔｅ）するように構成される。

少なくとも１つの態様では、該トラフィックオフロードに同意する応答は、該トラフィックオフロード要求を少なくとも部分的に受け入れることを示す。ここで、該トラフィックオフロード要求を少なくとも部分的に受け入れることは、幾つかのＴＮＬに関連するＦ１－Ｃ又は幾つかのＦ１－Ｕトンネルのために冗長経路を確立することを意味する。

少なくとも１つの態様では、ＩＡＢノードは第１の親ノードに接続されており、該ＩＡＢノードは第２の親ノードに接続されており、該第１の親ノードは該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、該第２の親ノードは該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、該トラフィックオフロード要求は、トラフィックオフロード要求（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ）メッセージに含まれ、該トラフィックオフロードに同意する応答は、トラフィックオフロード要求承認（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージに含まれ、該トラフィックオフロードを拒否する応答は、トラフィックオフロード要求拒否（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴ）メッセージに含まれる。

少なくとも１つの態様では、トラフィックオフロード要求メッセージは、トラフィックオフロード開始ノードのユーザ装置のＸｎインターフェースでの識別子（ＵＥ ＸｎＡＰ ＩＤ）、及び／又は１つ以上のＦ１－Ｃの識別情報を含んでもよい。該Ｆ１－Ｃの識別情報は、アクセスＩＡＢノードの１つ以上のＦ１－Ｃのために冗長経路を確立するために使用され、該アクセスＩＡＢノードは、ＩＡＢノード及び／又は該ＩＡＢノードの子孫ノード、又は二重接続になろうとしているＩＡＢノードを含む。

少なくとも１つの態様では、該トラフィックオフロード要求メッセージは、トラフィックオフロード開始ノードのユーザ装置のＸｎインターフェースでの識別子（ＵＥ ＸｎＡＰ ＩＤ）、アクセスＩＡＢノードのＢＡＰアドレス、ＴＮＬアドレス、１つ以上のＦ１－Ｃ識別情報、１つ以上のＦ１－Ｕトンネル識別情報、Ｆ１－Ｃ及び／又は各Ｆ１－ＵトンネルのＩＰヘッダ情報（ＩＰ ｈｅａｄｅｒ ｉｎｆｏｒｍａｔｉｏｎ）、又は各Ｆ１－ＵトンネルのＱｏＳ情報のうちの少なくとも１つを含む。

少なくとも１つの態様では、Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルについてのトラフィックオフロード要求を受け入れた場合、該トラフィックオフロード要求承認（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージは、該トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルの識別情報、アクセスＩＡＢノードのＤＵのために新たに割り当てられたＴＮＬアドレス、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルのために構成された二重接続されているＩＡＢノードと第２の親ノードとの間のリンクでのＢＨ ＲＬＣチャネル識別子、第２の親ノードのＢＡＰアドレス、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより制御されたトポロジ内のＢＡＰルーティング識別子、及び該ＩＡＢノードの第２のＢＡＰアドレスのうちの少なくとも１つを含む。

少なくとも１つの態様では、全てのＦ１－Ｃ及びＦ１－Ｕトンネルについてのトラフィックオフロード要求を拒否した場合、該トラフィックオフロード要求拒否（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴ）メッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤを含む。

少なくとも１つの態様では、ＩＡＢノードは第１の親ノードに接続されており、該ＩＡＢノードは第２の親ノードに接続されており、該第１の親ノードは該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、該第２の親ノードは該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである。

該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵはマスタノード（ＭＮ）であり、該トラフィックオフロード要求の内容、及び前記トラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード変更準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれる。

少なくとも１つの態様では、ＩＡＢノードは第１の親ノードに接続されており、該ＩＡＢノードは第２の親ノードに接続されておらず、該第１の親ノードは該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、該第２の親ノードは該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである。

該トラフィックオフロード要求の内容、及び該トラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード追加準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ａｄｄｉｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれる。

少なくとも１つの態様では、該トラフィックオフロード要求は、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたセカンダリノード追加要求（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージに含まれる。

少なくとも１つの態様では、該トラフィックオフロードに同意する応答は、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたＳＮ追加要求承認（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージに含まれる。

少なくとも１つの態様では、該トラフィックオフロードを拒否する応答は、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたＳＮ追加要求承認（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージに含まれる。

少なくとも１つの態様では、第１の送受信部１４０１は、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが冗長経路解放要求を送信又は受信し、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが冗長経路解放要求受け入れメッセージを受信又は送信するように構成される。

少なくとも１つの態様では、該冗長経路解放要求は、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、冗長経路を解放する必要のあるＦ１－Ｃに関連するＴＮＬアドレス、又は冗長経路を解放する必要のあるＦ１－Ｕトンネルのユーザプレーン伝送層情報（ＵＰ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｉｎｆｏｒｍａｔｉｏｎ）を含む。

少なくとも１つの態様では、該冗長経路解放要求は、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤを含む。

少なくとも１つの態様では、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ及び該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにおけるＭＮが冗長経路解放要求を送信した場合、該冗長経路解放要求の内容及び該冗長経路解放要求受け入れメッセージの内容は、ＩＥとして、セカンダリ基地局ノード変更準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順に含まれる。

少なくとも１つの態様では、ＩＡＢノードのセカンダリ基地局ノード解放（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｒｅｌｅａｓｅ）手順を行う際に、ＳＮトポロジ内の該ＩＡＢノードに関連する全ての冗長経路を解放する。

第１の送受信部１４０１の詳細な説明について、実施形態１における方法の説明を参照されたい。

＜実施形態６＞
本発明の実施例は、信号の送受信装置を提供する。該装置は、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに適用される。該装置は、第２のＤｏｎｏｒ－ＣＵであってもよいし、第２のＤｏｎｏｒ－ＣＵに構成された構成要素又はコンポーネントであってもよい。該装置は、実施形態２の方法に対応する。

図１５は、実施形態６に係る信号の送受信装置の一例の概略図である。図１５に示すように、信号の送受信装置１５００は、第２の送受信部１５０１を含む。

第２の送受信部１５０１は、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信されたトラフィックオフロード要求を受信し、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を送信するように構成される。

少なくとも１つの態様では、該トラフィックオフロード要求は、ＩＡＢノード及び／又は該ＩＡＢノードの子孫ノードのために冗長経路を確立する要求を含む。

少なくとも１つの態様では、第２の送受信部１５０１は、ＩＡＢノードが第２の親ノードに接続されている場合、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが、該ＩＡＢノードのモバイル端末（ＭＴ）のユーザ装置（ＵＥ）コンテキストを変更するように該第２の親ノードにユーザ装置コンテキスト変更要求（ＵＥ ＣＯＮＴＥＸＴ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージを送信し、少なくとも１つのベアラ（ｂｅａｒｅｒ）を設定するように構成される。ここで、該第２の親ノードは、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである。

少なくとも１つの態様では、第２の送受信部１５０１は、ＩＡＢノードが第２の親ノードに接続されていない場合、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが、該ＩＡＢノードのＭＴのＵＥコンテキストを確立するように該第２の親ノードにユーザ装置コンテキスト確立要求（ＵＥ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴ）メッセージを送信し、少なくとも１つのベアラ（ｂｅａｒｅｒ）を設定するように構成される。

ここで、該第２の親ノードは、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである。

少なくとも１つの態様では、第２の送受信部１５０１は、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが該ＩＡＢノードのモバイル端末（ＭＴ）に第２の再構成（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを送信するように構成される。該第２のＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージはＢＡＰ構成情報（ｂａｐ－Ｃｏｎｆｉｇ）を含み、該ＢＡＰ構成情報は前記ＩＡＢノードのために構成された第２のＢＡＰのアドレスを含む。

少なくとも１つの態様では、第２の送受信部１５０１は、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが、該ＩＡＢノード及び／又は該ＩＡＢノードの子孫ノードに必要な第２の経路について、該ＩＡＢノードから第２のＩＡＢ－ｄｏｎｏｒ－ＤＵへのＢＨ ＲＬＣチャネルの構成及びＢＡＰサブレイヤのルーティングテーブルの構成を行うように構成される。

該第２のＩＡＢ－ｄｏｎｏｒ－ＤＵは、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内にある。

少なくとも１つの態様では、該トラフィックオフロードに同意する応答は、該トラフィックオフロード要求を少なくとも部分的に受け入れることを示す。ここで、該トラフィックオフロード要求を少なくとも部分的に受け入れることは、幾つかのＴＮＬに関連するＦ１－Ｃ又は幾つかのＦ１－Ｕトンネルのために冗長経路を確立することを意味する。

少なくとも１つの態様では、ＩＡＢノードは第１の親ノードに接続されており、該ＩＡＢノードは第２の親ノードに接続されており、該第１の親ノードは該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、該第２の親ノードは該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである。

該トラフィックオフロード要求は、トラフィックオフロード要求（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ）メッセージに含まれ、該トラフィックオフロードに同意する応答は、トラフィックオフロード要求承認（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージに含まれ、該トラフィックオフロードを拒否する応答は、トラフィックオフロード要求拒否（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴ）メッセージに含まれる。

少なくとも１つの態様では、トラフィックオフロード要求メッセージは、トラフィックオフロード開始ノードのユーザ装置のＸｎインターフェースでの識別子（ＵＥ ＸｎＡＰ ＩＤ）、及び／又は１つ以上のＦ１－Ｃの識別情報を含んでもよい。該Ｆ１－Ｃの識別情報は、アクセスＩＡＢノードの１つ以上のＦ１－Ｃのために冗長経路を確立するために使用され、該アクセスＩＡＢノードは、ＩＡＢノード及び／又は該ＩＡＢノードの子孫ノード、又は二重接続になろうとしているＩＡＢノードを含む。

少なくとも１つの態様では、該トラフィックオフロード要求メッセージは、トラフィックオフロード開始ノードのユーザ装置のＸｎインターフェースでの識別子（ＵＥ ＸｎＡＰ ＩＤ）、アクセスＩＡＢノードのＢＡＰアドレス、ＴＮＬアドレス、１つ以上のＦ１－Ｃ識別情報、１つ以上のＦ１－Ｕトンネル識別情報、Ｆ１－Ｃ及び／又は各Ｆ１－ＵトンネルのＩＰヘッダ情報（ＩＰ ｈｅａｄｅｒ ｉｎｆｏｒｍａｔｉｏｎ）、又は各Ｆ１－ＵトンネルのＱｏＳ情報のうちの少なくとも１つを含む。

少なくとも１つの態様では、Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルについてのトラフィックオフロード要求を受け入れた場合、該トラフィックオフロード要求承認（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージは、該トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルの識別情報、アクセスＩＡＢノードのＤＵのために新たに割り当てられたＴＮＬアドレス、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルのために構成された二重接続されているＩＡＢノードと第２の親ノードとの間のリンクでのＢＨ ＲＬＣチャネル識別子、第２の親ノードのＢＡＰアドレス、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより制御されたトポロジ内のＢＡＰルーティング識別子、及び該ＩＡＢノードの第２のＢＡＰアドレスのうちの少なくとも１つを含む。

少なくとも１つの態様では、全てのＦ１－Ｃ及びＦ１－Ｕトンネルについてのトラフィックオフロード要求を拒否した場合、該トラフィックオフロード要求拒否（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴ）メッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤを含み、好ましくは、トラフィックオフロード拒否ノードのＵＥ ＸｎＡＰ ＩＤを含む。

少なくとも１つの態様では、ＩＡＢノードは第１の親ノードに接続されており、該ＩＡＢノードは第２の親ノードに接続されており、該第１の親ノードは該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、該第２の親ノードは前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである。

該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵはマスタノード（ＭＮ）であり、該トラフィックオフロード要求の内容、及び該トラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード変更準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれる。

少なくとも１つの態様では、ＩＡＢノードは第１の親ノードに接続されており、該ＩＡＢノードは第２の親ノードに接続されておらず、該第１の親ノードは該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、該第２の親ノードは該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである。

該トラフィックオフロード要求の内容、及び該トラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード追加準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ａｄｄｉｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれる。

少なくとも１つの態様では、該トラフィックオフロード要求は、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたセカンダリノード追加要求（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージに含まれる。

少なくとも１つの態様では、該トラフィックオフロードに同意する応答は、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたＳＮ追加要求承認（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージに含まれる。

少なくとも１つの態様では、第２の送受信部１５０１は、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが冗長経路解放要求を受信又は送信し、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが冗長経路解放要求受け入れメッセージを送信又は受信するように構成される。

少なくとも１つの態様では、該冗長経路解放要求は、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、冗長経路を解放する必要のあるＦ１－Ｃに関連するＴＮＬアドレス、又は冗長経路を解放する必要のあるＦ１－Ｕトンネルのユーザプレーン伝送層情報（ＵＰ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｉｎｆｏｒｍａｔｉｏｎ）を含む。

少なくとも１つの態様では、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ及び該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにおけるＭＮが冗長経路解放要求を送信した場合、該冗長経路解放要求の内容及び該冗長経路解放要求受け入れメッセージの内容は、ＩＥとして、セカンダリ基地局ノード変更準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順に含まれる。

少なくとも１つの態様では、ＩＡＢノードのセカンダリ基地局ノード解放（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｒｅｌｅａｓｅ）手順を行う際に、ＳＮトポロジ内の該ＩＡＢノードに関連する全ての冗長経路を解放する。

第２の送受信部１５０１の詳細な説明について、実施形態２における方法の説明を参照されたい。

＜実施形態７＞
本発明の実施例は、信号の送受信装置を提供する。該装置は、ＩＡＢノードに適用される。該装置は、ＩＡＢノードであってもよいし、ＩＡＢノードに構成された構成要素又はコンポーネントであってもよい。該装置は、実施形態３の方法に対応する。

図１６は、実施形態７に係る信号の送受信装置の一例の概略図である。図１６に示すように、信号の送受信装置１６００は、第３の送受信部１６０１を含む。

第３の送受信部１６０１は、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第１のＲＲＣ再構成メッセージを受信し、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにＲＲＣ再構成完了メッセージを送信するように構成される。

少なくとも１つの態様では、該第１のＲＲＣ再構成メッセージは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたトラフィックオフロードに同意する応答に応じて生成される。該第１のＲＲＣ再構成メッセージは、該ＩＡＢノードのＤＵに割り当てられた少なくとも１つのＴＮＬアドレスを含み、該ＴＮＬアドレスは、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵにアンカーされる。ここで、該ＲＲＣ再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、該ＩＡＢノードが前記第１のＲＲＣ再構成メッセージを受信したことを示すために使用される。また、該ＲＲＣ再構成完了メッセージは、該ＩＡＢノードが再構成を完了したことをさらに示してもよい。

少なくとも１つの態様では、第３の送受信部１６０１は、該ＩＡＢノードが該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第２のＲＲＣ再構成（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを受信し、該第２のＲＲＣ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージはＢＡＰ構成情報（ｂａｐ－Ｃｏｎｆｉｇ）を含み、該ＢＡＰ構成情報は該ＩＡＢノードのために構成された第２のＢＡＰアドレスを含み、該ＩＡＢノードが該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージを送信するように構成される。

ここで、該再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、該ＩＡＢノードが該第２のＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信したことを示すために使用される。

少なくとも１つの態様では、第３の送受信部１６０１は、該ＩＡＢノードが該第２のＢＡＰアドレスをマスタセルグループ（ＭＣＧ：ｍａｓｔｅｒ ｃｅｌｌ ｇｒｏｕｐ）／セカンダリセルグループ（ＳＣＧ：ｓｅｃｏｎｄａｒｙ ｃｅｌｌ ｇｒｏｕｐ）又はマスタノード（ＭＮ）／セカンダリノード（ＳＮ）に関連付けるように構成される。

少なくとも１つの態様では、該ＩＡＢノードにより受信された、該第２のＢＡＰアドレスを有する該第２のＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがＭＣＧからのもの又はシグナリング無線ベアラ１（ＳＲＢ：ｓｉｇｎａｌｌｉｎｇ ｒａｄｉｏ ｂｅａｒｅｒ）を介して受信されたものである場合、該第２のＢＡＰアドレスをＭＣＧ又はＭＮに関連付け、該ＩＡＢノードにより受信された、該第２のＢＡＰアドレスを有する該第２のＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがＳＣＧからのもの又はＳＲＢ３を介して受信されたものである場合、該第２のＢＡＰアドレスをＳＣＧ又はＳＮに関連付ける。

少なくとも１つの態様では、該第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）は、該ＩＡＢノードのために構成された第２のＢＡＰアドレスを示すためのフィールドを含み、或いは、該第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）におけるＢＡＰアドレスフィールドは、リストを含み、該リストにおける各エントリは、ＢＡＰアドレス及びその関連情報である。

第３の送受信部１６０１の詳細な説明について、実施形態３における方法の説明を参照されたい。

＜実施形態８＞
本発明の実施例は、信号の送受信装置を提供する。該装置は、ＩＡＢノードの子孫ノードに適用される。該装置は、ＩＡＢノードの子孫ノードであってもよいし、ＩＡＢノードの子孫ノードに構成された構成要素又はコンポーネントであってもよい。該装置は、実施形態４の方法に対応する。

図１７は、実施形態８に係る信号の送受信装置の一例の概略図である。図１７に示すように、信号の送受信装置１７００は、第４の送受信部１７０１を含む。

第４の送受信部１７０１は、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第１のＲＲＣ再構成メッセージを受信し、該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにＲＲＣ再構成完了メッセージを送信するように構成される。

ここで、該第１のＲＲＣ再構成メッセージは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより該第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたトラフィックオフロードに同意する応答に応じて生成される。該第１のＲＲＣ再構成メッセージは、該子孫ノードのＤＵに割り当てられた少なくとも１つのＴＮＬアドレスを含み、該ＴＮＬアドレスは、該第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵにアンカーされる。ここで、該ＲＲＣ再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、該子孫ノードが該第１のＲＲＣ再構成メッセージを受信したことを示すために使用される。また、該ＲＲＣ再構成完了メッセージは、該子孫ノードが再構成を完了したことをさらに示してもよい。

第４の送受信部１７０１の詳細な説明について、実施形態４における方法の説明を参照されたい。

＜実施形態９＞
本発明の実施例は、通信システムをさらに提供する。図１を参照してもよく、実施形態１乃至実施形態８と同様な内容についてその説明を省略する。

幾つかの態様では、通信システムは、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵ、ＩＡＢノード及びＩＡＢノードの子孫ノードを含んでもよい。

第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは、実施形態５に係る信号の送受信装置１４００を含む。

第２のＩＡＢ－ｄｏｎｏｒ－ＣＵは、実施形態６に係る信号の送受信装置１５００を含む。

ＩＡＢノードは、実施形態７に係る信号の送受信装置１６００を含む。

ＩＡＢノードの子孫ノードは、実施形態８に係る信号の送受信装置１７００を含む。

ここで、アクセスバックホール統合ノード（ＩＡＢ－ｎｏｄｅ）は、ＩＡＢ－ＭＴ機能ユニット及びＩＡＢ－ＤＵ機能ユニットを含んでもよい。ここで、ＩＡＢ－ＭＴ機能部は、端末装置と同様な構成を有してもよい。ＩＡＢ－ＤＵ機能ユニット、第１のＩＡＢ－ｄｏｎｏｒ ＣＵ及び第２のＩＡＢ－ｄｏｎｏｒ ＣＵは、ネットワーク装置と同様なユニットを有してもよい。

図１８は、本発明の実施形態に係るネットワーク装置の構成の概略図である。図１８に示すように、ネットワーク装置１８００は、プロセッサ１８１０（例えば中央処理装置のＣＰＵ）及びメモリ１８２０を含んでもよい。メモリ１８２０は、プロセッサ１８１０に接続される。メモリ１８２０は、各種のデータを記憶してもよいし、情報処理のプログラム１８３０をさらに記憶し、プロセッサ１８１０の制御で該プログラム１８３０を実行する。

例えば、プロセッサ１８１０は、実施形態１若しくは実施形態２におけるＩＡＢ－ｄｏｎｏｒ ＣＵにより実行される方法、又は実施形態３若しくは実施形態４におけるＩＡＢ－ＤＵにより実行される方法を実現するためのプログラムを実行するように構成されてもよい。

また、図１８に示すように、ネットワーク装置１８００は、送受信機１８４０及びアンテナ１８５０などをさらに含んでもよい。ここで、上記ユニットの機能は従来技術と同様であり、ここでその説明を省略する。なお、ネットワーク装置１８００は、図１８に示す全てのユニットを含む必要がない。また、ネットワーク装置１８００は、図１８に示されていないユニットをさらに含んでもよく、従来技術を参照してもよい。また、ＩＡＢ－ｄｏｎｏｒ－ＣＵとＩＡＢ－ｄｏｎｏｒ－ＤＵは、１つのノードに存在して１つのネットワーク装置ＩＡＢ－ｄｏｎｏｒとなってもよいし、２つのノードに分離してそれぞれネットワーク装置の異なる機能を実現してもよいが、従来技術を参照してもよい。

図１９は、本発明の実施形態に係る端末装置の概略図である。図１９に示すように、端末装置１９００は、プロセッサ１９１０及びメモリ１９２０を含んでもよい。メモリ１９２０は、データ及びプログラムを記憶し、プロセッサ１９１０に接続される。なお、この図は例示的なものであり、他のタイプの構造を用いてこの構造を補足又は置換して、通信機能又は他の機能を実現してもよい。例えば、プロセッサ１９１０は、実施形態３又は実施形態４におけるＩＡＢ－ＭＴにより実行される方法を実現するためのプログラムを実行するように構成されてもよい。

図１９に示すように、端末装置１９００は、通信モジュール１９３０、入力部１９４０、ディスプレイ１９５０、及び電源１９６０などをさらに含んでもよい。ここで、上記ユニットの機能は従来技術と同様であり、ここでその説明を省略する。なお、端末装置１９００は、図１９に示す全てのユニットを含む必要がない。また、端末装置１９００は、図１９に示されていないユニットをさらに含んでもよく、従来技術を参照してもよい。

本発明の実施例では、コンピュータプログラムであって、のＤｏｎｏｒ ＣＵにおいてプログラムを実行する際に、該Ｄｏｎｏｒ ＣＵに実施形態１又は実施形態２に記載の方法を実行させる、プログラムをさらに提供する。

本発明の実施例は、コンピュータプログラムが記憶されている記憶媒体であって、該コンピュータプログラムを実行する際に、該Ｄｏｎｏｒ ＣＵに実施形態１又は実施形態２に記載の方法を実行させる、記憶媒体をさらに提供する。

本発明の実施例では、コンピュータプログラムであって、ＩＡＢ又はその子孫ノードにおいてプログラムを実行する際に、該ＩＡＢ又はその子孫ノードに実施形態３又は実施形態４に記載の信号の送受信方法を実行させる、プログラムをさらに提供する。

本発明の実施例は、コンピュータプログラムが記憶されている記憶媒体であって、該コンピュータプログラムを実行する際に、ＩＡＢ又はその子孫ノードに実施形態３又は実施形態４に記載の信号の送受信方法を実行させる、記憶媒体をさらに提供する。

本発明の以上の装置及び方法は、ハードウェアにより実現されてもよく、ハードウェアとソフトウェアを結合して実現されてもよい。本発明はコンピュータが読み取り可能なプログラムに関し、該プログラムはロジック部により実行される際に、該ロジック部に上述した装置又は構成要件を実現させる、或いは該ロジック部に上述した各種の方法又はステップを実現させることができる。本発明は上記のプログラムを記憶するための記憶媒体、例えばハードディスク、磁気ディスク、光ディスク、ＤＶＤ、フラッシュメモリ等に関する。

本発明の実施例を参照しながら説明した各装置における各処理方法は、ハードウェア、プロセッサにより実行されるソフトウェアモジュール、又は両者の組み合わせで実施されてもよい。例えば、図面に示す機能的ブロック図における１つ若しくは複数、又は機能的ブロック図の１つ若しくは複数の組み合わせは、コンピュータプログラムフローの各ソフトウェアモジュールに対応してもよいし、各ハードウェアモジュールに対応してもよい。これらのソフトウェアモジュールは、図面に示す各ステップにそれぞれ対応してもよい。これらのハードウェアモジュールは、例えばフィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）を用いてこれらのソフトウェアモジュールをハードウェア化して実現されてもよい。

ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、モバイルハードディスク、ＣＤ－ＲＯＭ又は当業者にとって既知の任意の他の形の記憶媒体に位置してもよい。プロセッサが記憶媒体から情報を読み取り、且つ／或いは記憶媒体に情報を書き込むように該記憶媒体をプロセッサに接続してもよいし、記憶媒体がプロセッサの構成部であってもよい。プロセッサ及び記憶媒体はＡＳＩＣに位置してもよい。該ソフトウェアモジュールは移動端末のメモリに記憶されてもよいし、移動端末に挿入されたメモリカードに記憶されてもよい。例えば、機器（例えば移動端末）が比較的に大きい容量のＭＥＧＡ－ＳＩＭカード又は大容量のフラッシュメモリ装置を用いる場合、該ソフトウェアモジュールは該ＭＥＧＡ－ＳＩＭカード又は大容量のフラッシュメモリ装置に記憶されてもよい。

図面に記載されている機能的ブロック図における１つ以上の機能ブロック及び／又は機能ブロックの１つ以上の組合せは、本願に記載されている機能を実行するための汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）又は他のプログラマブル論理デバイス、ディスクリートゲート又はトランジスタ論理装置、ディスクリートハードウェアコンポーネント、又はそれらの任意の適切な組み合わせで実現されてもよい。図面に記載されている機能的ブロック図における１つ以上の機能ブロック及び／又は機能ブロックの１つ以上の組合せは、例えば、コンピューティング機器の組み合わせ、例えばＤＳＰとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサの組み合わせ、ＤＳＰ通信と組み合わせた１つ又は複数のマイクロプロセッサ又は他の任意の構成で実現されてもよい。

以上、具体的な実施形態を参照しながら本発明を説明しているが、上記の説明は、例示的なものに過ぎず、本発明の保護の範囲を限定するものではない。本発明の趣旨及び原理を離脱しない限り、本発明に対して各種の変形及び変更を行ってもよく、これらの変形及び変更も本発明の範囲内のものである。

また、上述の実施例を含む実施形態に関し、更に以下の付記を開示する。

第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ側の方法：
（付記１）
第１のアクセスバックホール統合ノードドナー集約ユニット（ＩＡＢ－ｄｏｎｏｒ－ＣＵ）に適用される、信号の送受信方法であって、
第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロード要求を送信するステップと、
前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信されたトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を受信するステップと、を含む、方法。
（付記２）
前記トラフィックオフロードに同意する応答に応じて、ＩＡＢノード及び／又は前記ＩＡＢノードの子孫ＩＡＢノードに第１のＲＲＣ再構成メッセージを送信するステップ、をさらに含み、
前記第１のＲＲＣ再構成メッセージは、前記ＩＡＢノード及び／又は前記ＩＡＢノードの子孫ノードのＤＵにそれぞれ割り当てられた少なくとも１つのＴＮＬアドレスを含み、前記ＴＮＬアドレスは、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵにアンカーされ、
前記ＩＡＢノードは、第１の親ノードに接続されており、前記第１の親ノードは、前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記ＩＡＢノードは、第２の親ノードに既に接続されており、或いは接続される予定であり、前記第２の親ノードは、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである、付記１に記載の方法。
（付記３）
前記第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）は、前記ＩＡＢノードのために構成された第２のＢＡＰアドレスを示すためのフィールドを含み、或いは、
前記第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）におけるＢＡＰアドレスフィールドは、リストを含み、前記リストにおける各エントリは、ＢＡＰアドレス及びその関連情報である、付記２に記載の方法。
（付記４）
新しいＴＮＬアドレスが割り当てられた場合、前記新しいＴＮＬアドレスを前記ＩＡＢノード及び／又は前記ＩＡＢノードの子孫ノードのＤＵと前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵとのＦ１－Ｃアソシエーションに追加するステップ、をさらに含む、付記２に記載の方法。
（付記５）
前記トラフィックオフロード要求は、ＩＡＢノード及び／又は前記ＩＡＢノードの子孫ノードのために冗長経路を確立する要求を含む、付記１に記載の方法。
（付記６）
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵは、第２の経路のルーティング及びＢＨ ＲＬＣチャネルマッピングをサポートするために、前記ＩＡＢノードから前記ＩＡＢノードの子孫ノードへのＢＨ ＲＬＣチャネルの構成及びＢＡＰサブレイヤのルーティングテーブルの構成を行う、付記５に記載の方法。
（付記７）
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが前記トラフィックオフロードに同意する応答に応じて、前記ＩＡＢノードに対してＢＡＰルーティング識別子マッピングの構成を行うステップ、をさらに含む、付記５に記載の方法。
（付記８）
第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが、ユーザ装置コンテキスト変更要求（ＵＥ ＣＯＮＴＥＸＴ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージ又はユーザ装置コンテキスト確立要求（ＵＥ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴ）メッセージを介して、前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵから前記ＩＡＢノード及び／又は前記ＩＡＢノードの子孫ノードのＤＵへのＦ１－Ｕトンネルを第１の経路から第２の経路に移行（ｍｉｇｒａｔｅ）するステップ、をさらに含む、付記５に記載の方法。
（付記９）
前記トラフィックオフロードに同意する応答は、前記トラフィックオフロード要求を少なくとも部分的に受け入れることを示し、
前記トラフィックオフロード要求を少なくとも部分的に受け入れることは、幾つかのＴＮＬに関連するＦ１－Ｃ又は幾つかのＦ１－Ｕトンネルのために冗長経路を確立することを意味する、付記１に記載の方法。
（付記１０）
ＩＡＢノードは第１の親ノードに接続されており、前記ＩＡＢノードは第２の親ノードに接続されており、前記第１の親ノードは前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、
前記トラフィックオフロード要求は、トラフィックオフロード要求（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ）メッセージに含まれ、前記トラフィックオフロードに同意する応答は、トラフィックオフロード要求承認（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージに含まれ、前記トラフィックオフロードを拒否する応答は、トラフィックオフロード要求拒否（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴ）メッセージに含まれる、付記１に記載の方法。
（付記１１）
前記トラフィックオフロード要求メッセージは、
トラフィックオフロード開始ノードのユーザ装置のＸｎインターフェースでの識別子（ＵＥ ＸｎＡＰ ＩＤ）、アクセスＩＡＢノードのＢＡＰアドレス、ＴＮＬアドレス、１つ以上のＦ１－Ｃ識別情報、１つ以上のＦ１－Ｕトンネル識別情報、Ｆ１－Ｃ及び／又は各Ｆ１－ＵトンネルのＩＰヘッダ情報（ＩＰ ｈｅａｄｅｒ ｉｎｆｏｒｍａｔｉｏｎ）、又は各Ｆ１－ＵトンネルのＱｏＳ情報のうちの少なくとも１つを含む、付記１０に記載の方法。
（付記１２）
Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルについてのトラフィックオフロード要求を受け入れた場合、前記トラフィックオフロード要求承認（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージは、
前記トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルの識別情報、アクセスＩＡＢノードのＤＵのために新たに割り当てられたＴＮＬアドレス、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルのために構成された二重接続されているＩＡＢノードと第２の親ノードとの間のリンクでのＢＨ ＲＬＣチャネル識別子、第２の親ノードのＢＡＰアドレス、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより制御されたトポロジ内のＢＡＰルーティング識別子、及び前記ＩＡＢノードの第２のＢＡＰアドレスのうちの少なくとも１つを含む、付記１１に記載の方法。
（付記１３）
全てのＦ１－Ｃ及びＦ１－Ｕトンネルについてのトラフィックオフロード要求を拒否した場合、前記トラフィックオフロード要求拒否（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴ）メッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤを含む、付記１１に記載の方法。
（付記１４）
ＩＡＢノードは第１の親ノードに接続されており、前記ＩＡＢノードは第２の親ノードに接続されており、前記第１の親ノードは前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵはマスタノード（ＭＮ）であり、前記トラフィックオフロード要求の内容、及び前記トラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード変更準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれる、付記１に記載の方法。
（付記１５）
ＩＡＢノードは第１の親ノードに接続されており、前記ＩＡＢノードは第２の親ノードに接続されておらず、前記第１の親ノードは前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、
前記トラフィックオフロード要求の内容、及び前記トラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード追加準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ａｄｄｉｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれる、付記１に記載の方法。
（付記１６）
前記トラフィックオフロード要求は、前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたセカンダリノード追加要求（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージに含まれる、付記１５に記載の方法。
（付記１７）
前記トラフィックオフロードに同意する応答は、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたＳＮ追加要求承認（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージに含まれる、付記１５に記載の方法。
（付記１８）
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが冗長経路解放要求を送信又は受信するステップと、
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが冗長経路解放要求受け入れメッセージを受信又は送信するステップと、をさらに含む、付記１に記載の方法。
（付記１９）
前記冗長経路解放要求は、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、冗長経路を解放する必要のあるＦ１－Ｃに関連するＴＮＬアドレス、又は冗長経路を解放する必要のあるＦ１－Ｕトンネルのユーザプレーン伝送層情報（ＵＰ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｉｎｆｏｒｍａｔｉｏｎ）を含む、付記１８に記載の方法。
（付記２０）
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ及び前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにおけるＭＮが冗長経路解放要求を送信した場合、
前記冗長経路解放要求の内容及び前記冗長経路解放要求受け入れメッセージの内容は、ＩＥとして、セカンダリ基地局ノード変更準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順に含まれる、付記１８に記載の方法。
（付記２１）
ＩＡＢノードのセカンダリ基地局ノード解放（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｒｅｌｅａｓｅ）手順を行う際に、ＳＮトポロジ内の前記ＩＡＢノードに関連する全ての冗長経路を解放する、付記１に記載の方法。

第２のＩＡＢ－ｄｏｎｏｒ－ＣＵ側の方法：
（付記１）
第２のアクセスバックホール統合ノードドナー集約ユニット（ＩＡＢ－ｄｏｎｏｒ－ＣＵ）に適用される、信号の送受信方法であって、
第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信されたトラフィックオフロード要求を受信するステップと、
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を送信するステップと、を含む、方法。
（付記２）
前記トラフィックオフロード要求は、ＩＡＢノード及び／又は前記ＩＡＢノードの子孫ノードのために冗長経路を確立する要求を含む、付記１に記載の方法。
（付記３）
ＩＡＢノードが第２の親ノードに接続されている場合、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが、前記ＩＡＢノードのモバイル端末（ＭＴ）のユーザ装置（ＵＥ）コンテキストを変更するように前記第２の親ノードにユーザ装置コンテキスト変更要求（ＵＥ ＣＯＮＴＥＸＴ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージを送信し、少なくとも１つのベアラ（ｂｅａｒｅｒ）を設定するステップ、をさらに含み、
前記第２の親ノードは、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである、付記１に記載の方法。
（付記４）
ＩＡＢノードが第２の親ノードに接続されていない場合、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが、前記ＩＡＢノードのＭＴのＵＥコンテキストを確立するように前記第２の親ノードにユーザ装置コンテキスト確立要求（ＵＥ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴ）メッセージを送信し、少なくとも１つのベアラ（ｂｅａｒｅｒ）を設定するステップ、をさらに含み、
前記第２の親ノードは、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである、付記１に記載の方法。
（付記５）
前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが前記ＩＡＢノードのモバイル端末（ＭＴ）に第２の再構成（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを送信するステップであって、前記第２のＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージはＢＡＰ構成情報（ｂａｐ－Ｃｏｎｆｉｇ）を含み、前記ＢＡＰ構成情報は前記ＩＡＢノードのために構成された第２のＢＡＰのアドレスを含む、ステップ、をさらに含む、付記３又は４に記載の方法。
（付記６）
前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが、前記ＩＡＢノード及び／又は前記ＩＡＢノードの子孫ノードに必要な第２の経路について、前記ＩＡＢノードから第２のＩＡＢ－ｄｏｎｏｒ－ＤＵへのＢＨ ＲＬＣチャネルの構成及びＢＡＰサブレイヤのルーティングテーブルの構成を行うステップ、をさらに含み、
前記第２のＩＡＢ－ｄｏｎｏｒ－ＤＵは、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内にある、付記３又は４に記載の方法。
（付記７）
前記トラフィックオフロードに同意する応答は、前記トラフィックオフロード要求を少なくとも部分的に受け入れることを示し、
前記トラフィックオフロード要求を少なくとも部分的に受け入れることは、幾つかのＴＮＬに関連するＦ１－Ｃ又は幾つかのＦ１－Ｕトンネルのために冗長経路を確立することを意味する、付記１に記載の方法。
（付記８）
ＩＡＢノードは第１の親ノードに接続されており、前記ＩＡＢノードは第２の親ノードに接続されており、前記第１の親ノードは前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、
前記トラフィックオフロード要求は、トラフィックオフロード要求（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ）メッセージに含まれ、前記トラフィックオフロードに同意する応答は、トラフィックオフロード要求承認（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージに含まれ、前記トラフィックオフロードを拒否する応答は、トラフィックオフロード要求拒否（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴ）メッセージに含まれる、付記１に記載の方法。
（付記９）
前記トラフィックオフロード要求メッセージは、
トラフィックオフロード開始ノードのユーザ装置のＸｎインターフェースでの識別子（ＵＥ ＸｎＡＰ ＩＤ）、アクセスＩＡＢノードのＢＡＰアドレス、ＴＮＬアドレス、１つ以上のＦ１－Ｃ識別情報、１つ以上のＦ１－Ｕトンネル識別情報、Ｆ１－Ｃ及び／又は各Ｆ１－ＵトンネルのＩＰヘッダ情報（ＩＰ ｈｅａｄｅｒ ｉｎｆｏｒｍａｔｉｏｎ）、又は各Ｆ１－ＵトンネルのＱｏＳ情報のうちの少なくとも１つを含む、付記８に記載の方法。
（付記１０）
Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルについてのトラフィックオフロード要求を受け入れた場合、前記トラフィックオフロード要求承認（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージは、
前記トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルの識別情報、アクセスＩＡＢノードのＤＵのために新たに割り当てられたＴＮＬアドレス、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルのために構成された二重接続されているＩＡＢノードと第２の親ノードとの間のリンクでのＢＨ ＲＬＣチャネル識別子、第２の親ノードのＢＡＰアドレス、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより制御されたトポロジ内のＢＡＰルーティング識別子、及び前記ＩＡＢノードの第２のＢＡＰアドレスのうちの少なくとも１つを含む、付記９に記載の方法。
（付記１１）
全てのＦ１－Ｃ及びＦ１－Ｕトンネルについてのトラフィックオフロード要求を拒否した場合、前記トラフィックオフロード要求拒否（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴ）メッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤを含む、付記９に記載の方法。
（付記１２）
ＩＡＢノードは第１の親ノードに接続されており、前記ＩＡＢノードは第２の親ノードに接続されており、前記第１の親ノードは前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵはマスタノード（ＭＮ）であり、前記トラフィックオフロード要求の内容、及び前記トラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード変更準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれる、付記１に記載の方法。
（付記１３）
ＩＡＢノードは第１の親ノードに接続されており、前記ＩＡＢノードは第２の親ノードに接続されておらず、前記第１の親ノードは前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、
前記トラフィックオフロード要求の内容、及び前記トラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード追加準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ａｄｄｉｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれる、付記１に記載の方法。
（付記１４）
前記トラフィックオフロード要求は、前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたセカンダリノード追加要求（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ）メッセージに含まれる、付記１３に記載の方法。
（付記１５）
前記トラフィックオフロードに同意する応答は、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたＳＮ追加要求承認（Ｓ－ＮＯＤＥ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージに含まれる、付記１３に記載の方法。
（付記１６）
前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが冗長経路解放要求を受信又は送信するステップと、
前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵが冗長経路解放要求受け入れメッセージを送信又は受信するステップと、をさらに含む、付記１に記載の方法。
（付記１７）
前記冗長経路解放要求は、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、冗長経路を解放する必要のあるＦ１－Ｃに関連するＴＮＬアドレス、又は冗長経路を解放する必要のあるＦ１－Ｕトンネルのユーザプレーン伝送層情報（ＵＰ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｉｎｆｏｒｍａｔｉｏｎ）を含む、付記１６に記載の方法。
（付記１８）
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵ及び前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにおけるＭＮが冗長経路解放要求を送信した場合、
前記冗長経路解放要求の内容及び前記冗長経路解放要求受け入れメッセージの内容は、ＩＥとして、セカンダリ基地局ノード変更準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順に含まれる、付記１６に記載の方法。
（付記１９）
ＩＡＢノードのセカンダリ基地局ノード解放（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｒｅｌｅａｓｅ）手順を行う際に、ＳＮトポロジ内の前記ＩＡＢノードに関連する全ての冗長経路を解放する、付記１に記載の方法。

二重接続されているＩＡＢノード側の方法：
（付記１）
ＩＡＢノードに適用される、信号の送受信方法であって、前記ＩＡＢノードは、第１の親ノードに接続されており、前記ＩＡＢノードは、第２の親ノードに既に接続されており、或いは接続される予定であり、前記第１の親ノードは、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、
前記方法は、
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第１のＲＲＣ再構成メッセージを受信するステップと、
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにＲＲＣ再構成完了メッセージを送信するステップと、を含み、
前記第１のＲＲＣ再構成メッセージは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたトラフィックオフロードに同意する応答に応じて生成され、
前記第１のＲＲＣ再構成メッセージは、前記ＩＡＢノードのＤＵに割り当てられた少なくとも１つのＴＮＬアドレスを含み、前記ＴＮＬアドレスは、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵにアンカーされ、
前記ＲＲＣ再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、前記ＩＡＢノードが前記第１のＲＲＣ再構成メッセージを受信したことを示すために使用される、方法。
（付記２）
前記ＩＡＢノードが前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第２のＲＲＣ再構成（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを受信するステップであって、前記第２のＲＲＣ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージはＢＡＰ構成情報（ｂａｐ－Ｃｏｎｆｉｇ）を含み、前記ＢＡＰ構成情報は前記ＩＡＢノードのために構成された第２のＢＡＰアドレスを含む、ステップと、
前記ＩＡＢノードが前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージを送信するステップと、をさらに含み、
前記再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、前記ＩＡＢノードが前記第２のＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信したことを示すために使用される、付記１に記載の方法。
（付記３）
前記ＩＡＢノードが前記第２のＢＡＰアドレスをマスタセルグループ（ＭＣＧ：ｍａｓｔｅｒ ｃｅｌｌ ｇｒｏｕｐ）／セカンダリセルグループ（ＳＣＧ：ｓｅｃｏｎｄａｒｙ ｃｅｌｌ ｇｒｏｕｐ）又はマスタノード（ＭＮ）／セカンダリノード（ＳＮ）に関連付けるステップ、をさらに含む、付記２に記載の方法。
（付記４）
前記ＩＡＢノードにより受信された、前記第２のＢＡＰアドレスを有する前記第２のＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがＭＣＧからのもの又はシグナリング無線ベアラ１（ＳＲＢ：ｓｉｇｎａｌｌｉｎｇ ｒａｄｉｏ ｂｅａｒｅｒ）を介して受信されたものである場合、前記第２のＢＡＰアドレスをＭＣＧ又はＭＮに関連付け、
前記ＩＡＢノードにより受信された、前記第２のＢＡＰアドレスを有する前記第２のＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがＳＣＧからのもの又はＳＲＢ３を介して受信されたものである場合、前記第２のＢＡＰアドレスをＳＣＧ又はＳＮに関連付ける、付記３に記載の方法。
（付記５）
前記第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）は、前記ＩＡＢノードのために構成された第２のＢＡＰアドレスを示すためのフィールドを含み、或いは、
前記第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）におけるＢＡＰアドレスフィールドは、リストを含み、前記リストにおける各エントリは、ＢＡＰアドレス及びその関連情報である、付記１に記載の方法。

子孫ノード側の方法：
（付記１）
ＩＡＢノードの子孫ノードに適用される、信号の送受信方法であって、前記ＩＡＢノードは、第１の親ノードに接続されており、前記ＩＡＢノードは、第２の親ノードに既に接続されており、或いは接続される予定であり、前記第１の親ノードは、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、
前記方法は、
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第１のＲＲＣ再構成メッセージを受信するステップと、
前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにＲＲＣ再構成完了メッセージを送信するステップと、を含み、
前記第１のＲＲＣ再構成メッセージは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたトラフィックオフロードに同意する応答に応じて生成され、
前記第１のＲＲＣ再構成メッセージは、前記子孫ノードのＤＵに割り当てられた少なくとも１つのＴＮＬアドレスを含み、前記ＴＮＬアドレスは、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵにアンカーされ、
前記ＲＲＣ再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、前記子孫ノードが前記第１のＲＲＣ再構成メッセージを受信したことを示すために使用される、方法。

Claims (20)

1. 第１のアクセスバックホール統合ノードドナー集約ユニット（ＩＡＢ－ｄｏｎｏｒ－ＣＵ）に適用される、信号の送受信装置であって、該装置は第１の送受信部を含み、前記第１の送受信部は、
   第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロード要求を送信し、
   前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信されたトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を受信するように構成される、装置。
2. 前記第１の送受信部は、
   前記トラフィックオフロードに同意する応答に応じて、ＩＡＢノード及び／又は前記ＩＡＢノードの子孫ＩＡＢノードに第１のＲＲＣ再構成メッセージを送信するように構成され、
   前記第１のＲＲＣ再構成メッセージは、前記ＩＡＢノード及び／又は前記ＩＡＢノードの子孫ノードのＤＵにそれぞれ割り当てられた少なくとも１つのＴＮＬアドレスを含み、前記ＴＮＬアドレスは、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵにアンカーされ、
   前記ＩＡＢノードは、第１の親ノードに接続されており、前記第１の親ノードは、前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記ＩＡＢノードは、第２の親ノードに既に接続されており、或いは接続される予定であり、前記第２の親ノードは、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードである、請求項１に記載の装置。
3. 前記第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）は、前記ＩＡＢノードのために構成された第２のＢＡＰアドレスを示すためのフィールドを含み、或いは、
   前記第１のＲＲＣ再構成メッセージのＢＡＰ構成情報要素（ｂａｐ－Ｃｏｎｆｉｇ ＩＥ）におけるＢＡＰアドレスフィールドは、リストを含み、前記リストにおける各エントリは、ＢＡＰアドレス及びその関連情報である、請求項２に記載の装置。
4. 前記トラフィックオフロード要求は、ＩＡＢノード及び／又は前記ＩＡＢノードの子孫ノードのために冗長経路を確立する要求を含む、請求項１に記載の装置。
5. 前記第１の送受信部は、
   前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが前記トラフィックオフロードに同意する応答に応じて、前記ＩＡＢノードに対してＢＡＰルーティング識別子マッピングの構成を行うように構成される、請求項４に記載の装置。
6. 前記トラフィックオフロードに同意する応答は、前記トラフィックオフロード要求を少なくとも部分的に受け入れることを示し、
   前記トラフィックオフロード要求を少なくとも部分的に受け入れることは、幾つかのＴＮＬに関連するＦ１－Ｃ又は幾つかのＦ１－Ｕトンネルのために冗長経路を確立することを意味する、請求項１に記載の装置。
7. ＩＡＢノードは第１の親ノードに接続されており、前記ＩＡＢノードは第２の親ノードに接続されており、前記第１の親ノードは前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、
   前記トラフィックオフロード要求は、トラフィックオフロード要求（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ）メッセージに含まれ、前記トラフィックオフロードに同意する応答は、トラフィックオフロード要求承認（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージに含まれ、前記トラフィックオフロードを拒否する応答は、トラフィックオフロード要求拒否（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴ）メッセージに含まれる、請求項１に記載の装置。
8. 前記トラフィックオフロード要求メッセージは、
   トラフィックオフロード開始ノードのユーザ装置のＸｎインターフェースでの識別子（ＵＥ ＸｎＡＰ ＩＤ）、アクセスＩＡＢノードのＢＡＰアドレス、ＴＮＬアドレス、１つ以上のＦ１－Ｃ識別情報、１つ以上のＦ１－Ｕトンネル識別情報、Ｆ１－Ｃ及び／又は各Ｆ１－ＵトンネルのＩＰヘッダ情報（ＩＰ ｈｅａｄｅｒ ｉｎｆｏｒｍａｔｉｏｎ）、又は各Ｆ１－ＵトンネルのＱｏＳ情報のうちの少なくとも１つを含む、請求項７に記載の装置。
9. Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルについてのトラフィックオフロード要求を受け入れた場合、前記トラフィックオフロード要求承認（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージは、
   前記トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルの識別情報、アクセスＩＡＢノードのＤＵのために新たに割り当てられたＴＮＬアドレス、該Ｆ１－Ｃ及び／又はＦ１－Ｕトンネルのために構成された二重接続されているＩＡＢノードと第２の親ノードとの間のリンクでのＢＨ ＲＬＣチャネル識別子、第２の親ノードのＢＡＰアドレス、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより制御されたトポロジ内のＢＡＰルーティング識別子、及び前記ＩＡＢノードの第２のＢＡＰアドレスのうちの少なくとも１つを含む、請求項８に記載の装置。
10. 全てのＦ１－Ｃ及びＦ１－Ｕトンネルについてのトラフィックオフロード要求を拒否した場合、前記トラフィックオフロード要求拒否（ＴＲＡＦＦＩＣ ＯＦＦＬＯＡＤ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴ）メッセージは、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤを含む、請求項８に記載の装置。
11. ＩＡＢノードは第１の親ノードに接続されており、前記ＩＡＢノードは第２の親ノードに接続されておらず、前記第１の親ノードは前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、
    前記トラフィックオフロード要求の内容、及び前記トラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答の内容は、情報要素（ＩＥ）として、ＸｎＡＰのセカンダリ基地局ノード追加準備（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ａｄｄｉｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）手順のメッセージに含まれる、請求項１に記載の装置。
12. 前記第１の送受信部は、
    前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが冗長経路解放要求を送信又は受信し、
    前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵが冗長経路解放要求受け入れメッセージを受信又は送信するように構成される、請求項１に記載の装置。
13. 前記冗長経路解放要求は、トラフィックオフロード開始ノードのＵＥ ＸｎＡＰ ＩＤ、トラフィックオフロード受け入れノードのＵＥ ＸｎＡＰ ＩＤ、冗長経路を解放する必要のあるＦ１－Ｃに関連するＴＮＬアドレス、又は冗長経路を解放する必要のあるＦ１－Ｕトンネルのユーザプレーン伝送層情報（ＵＰ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｉｎｆｏｒｍａｔｉｏｎ）を含む、請求項１２に記載の装置。
14. ＩＡＢノードのセカンダリ基地局ノード解放（Ｓ－ＮＧ－ＲＡＮ ｎｏｄｅ Ｒｅｌｅａｓｅ）手順を行う際に、ＳＮトポロジ内の前記ＩＡＢノードに関連する全ての冗長経路を解放する、請求項１に記載の装置。
15. 第２のアクセスバックホール統合ノードドナー集約ユニット（ＩＡＢ－ｄｏｎｏｒ－ＣＵ）に適用される、信号の送受信装置であって、該装置は第２の送受信部を含み、前記第２の送受信部は、
    第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信されたトラフィックオフロード要求を受信し、
    前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにトラフィックオフロードに同意する応答又はトラフィックオフロードを拒否する応答を送信するように構成される、装置。
16. 前記トラフィックオフロード要求は、ＩＡＢノード及び／又は前記ＩＡＢノードの子孫ノードのために冗長経路を確立する要求を含む、請求項１５に記載の装置。
17. ＩＡＢノードに適用される、信号の送受信装置であって、前記ＩＡＢノードは、第１の親ノードに接続されており、前記ＩＡＢノードは、第２の親ノードに既に接続されており、或いは接続される予定であり、前記第１の親ノードは、第１のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、前記第２の親ノードは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内のノードであり、
    該装置は第３の送受信部を含み、前記第３の送受信部は、
    前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第１のＲＲＣ再構成メッセージを受信し、
    前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵにＲＲＣ再構成完了メッセージを送信するように構成され、
    前記第１のＲＲＣ再構成メッセージは、第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより前記第１のＩＡＢ－ｄｏｎｏｒ－ＣＵに送信されたトラフィックオフロードに同意する応答に応じて生成され、
    前記第１のＲＲＣ再構成メッセージは、前記ＩＡＢノードのＤＵに割り当てられた少なくとも１つのＴＮＬアドレスを含み、前記ＴＮＬアドレスは、前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵのトポロジ内の第２のＩＡＢ－ｄｏｎｏｒ－ＤＵにアンカーされ、
    前記ＲＲＣ再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、前記ＩＡＢノードが前記第１のＲＲＣ再構成メッセージを受信しており、且つ再構成を完了したことを示すために使用される、装置。
18. 前記第３の送受信部は、
    前記ＩＡＢノードが前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵにより送信された第２のＲＲＣ再構成（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを受信し、前記第２のＲＲＣ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージはＢＡＰ構成情報（ｂａｐ－Ｃｏｎｆｉｇ）を含み、前記ＢＡＰ構成情報は前記ＩＡＢノードのために構成された第２のＢＡＰアドレスを含み、
    前記ＩＡＢノードが前記第２のＩＡＢ－ｄｏｎｏｒ－ＣＵに再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージを送信するように構成され、
    前記再構成完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージは、前記ＩＡＢノードが前記第２のＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信したことを示すために使用される、請求項１７に記載の装置。
19. 前記第３の送受信部は、
    前記ＩＡＢノードが前記第２のＢＡＰアドレスをマスタセルグループ（ＭＣＧ：ｍａｓｔｅｒ ｃｅｌｌ ｇｒｏｕｐ）／セカンダリセルグループ（ＳＣＧ：ｓｅｃｏｎｄａｒｙ ｃｅｌｌ ｇｒｏｕｐ）又はマスタノード（ＭＮ）／セカンダリノード（ＳＮ）に関連付けるように構成される、請求項１８に記載の装置。
20. 前記ＩＡＢノードにより受信された、前記第２のＢＡＰアドレスを有する前記第２のＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがＭＣＧからのもの又はシグナリング無線ベアラ１（ＳＲＢ：ｓｉｇｎａｌｌｉｎｇ ｒａｄｉｏ ｂｅａｒｅｒ）を介して受信されたものである場合、前記第２のＢＡＰアドレスをＭＣＧ又はＭＮに関連付け、
    前記ＩＡＢノードにより受信された、前記第２のＢＡＰアドレスを有する前記第２のＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがＳＣＧからのもの又はＳＲＢ３を介して受信されたものである場合、前記第２のＢＡＰアドレスをＳＣＧ又はＳＮに関連付ける、請求項１９に記載の装置。

Images