特許 7604622 論理チャネルＬＣＨ設定方法、通信装置、および通信システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-12-13

(45)【発行日】2024-12-23

(54)【発明の名称】論理チャネルＬＣＨ設定方法、通信装置、および通信システム

(51)【国際特許分類】

   H04W 16/26 20090101AFI20241216BHJP

   H04W 36/18 20090101ALI20241216BHJP

   H04W 76/12 20180101ALI20241216BHJP

   H04W 92/20 20090101ALI20241216BHJP

【ＦＩ】

H04W16/26

H04W36/18

H04W76/12

H04W92/20 110

【請求項の数】 27

(21)【出願番号】P 2023506143

(86)(22)【出願日】2021-07-27

(65)【公表番号】

(43)【公表日】2023-08-22

(86)【国際出願番号】 CN2021108547

(87)【国際公開番号】W WO2022022484

(87)【国際公開日】2022-02-03

【審査請求日】2023-03-02

(31)【優先権主張番号】202010757494.3

(32)【優先日】2020-07-31

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．

【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ

(74)【代理人】

【識別番号】100132481

【弁理士】

【氏名又は名称】赤澤 克豪

(74)【代理人】

【識別番号】100115635

【弁理士】

【氏名又は名称】窪田 郁大

(72)【発明者】

【氏名】▲劉▼ 菁

(72)【発明者】

【氏名】朱 元萍

(72)【発明者】

【氏名】史 玉▲竜▼

【審査官】三枝 保裕

(56)【参考文献】

【文献】Huawei, HiSilicon，Discussion on the R16 other WI features supporting for IAB-MT，3GPP TSG RAN WG2 #110-e R2-2005520，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_110-e/Docs/R2-2005520.zip>，2020年06月12日

【文献】3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Study on Integrated Access and Backhaul; (Release 16)，3GPP TR 38.874 V16.0.0，2018年12月，pp.79-86,89-90

【文献】Qualcomm Incorporated，Per DRB DAPS HO，3GPP TSG RAN WG3 #106 R2-196795，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_106/Docs/R3-196795.zip>，2019年11月22日

【文献】3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 16)，3GPP TS 38.300 V16.2.0，2020年07月24日

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ ７／２４－ ７／２６

Ｈ０４Ｗ ４／００－９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

論理チャネル(ＬＣＨ)設定方法であって、端末の第１のデータ無線ベアラ(ＤＲＢ)が第１のＬＣＨに対応し、前記第１のＬＣＨが、ソースドナーノードに対応するパケットデータコンバージェンスプロトコル(ＰＤＣＰ)データを伝送するためのものであり、前記論理チャネル(ＬＣＨ)設定方法は、
第１のリレーノードによって、前記第１のＤＲＢに対応する第２のＬＣＨの設定情報を生成するステップであって、前記第２のＬＣＨが、ターゲットドナーノードに対応するＰＤＣＰデータを伝送するためのものである、ステップと、
前記第１のリレーノードによって、前記第２のＬＣＨの前記設定情報を前記端末へ送信するステップと
を含み、
前記第１のリレーノードは前記端末のアクセスリレーノードであり、前記ソースドナーノードが第１のリレーノードハンドオーバ中のソースドナーノードであるとともに前記ターゲットドナーノードが前記第１のリレーノードハンドオーバ中のターゲットドナーノードであるか、または前記ソースドナーノードが第２のリレーノードハンドオーバ中のソースドナーノードであるとともに前記ターゲットドナーノードが前記第２のリレーノードハンドオーバ中のターゲットドナーノードであり、第２のリレーノードが、前記第１のリレーノードと前記ソースドナーノードの間のリンク上のリレーノードであり、
前記端末は、第２のインジケーション情報を受信して、前記端末が前記第２のＬＣＨの設定情報を受信し、前記第１のＬＣＨの設定情報が削除される必要があると誤って見なす状況を回避する、
論理チャネル(ＬＣＨ)設定方法。

【請求項2】

前記ソースドナーノードに対応する前記ＰＤＣＰデータは、前記ソースドナーノードに対応するＰＤＣＰ設定情報を用いて処理され、前記ターゲットドナーノードに対応する前記ＰＤＣＰデータは、前記ターゲットドナーノードに対応する前記ＰＤＣＰ設定情報を用いて処理される請求項１に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項3】

前記論理チャネル(ＬＣＨ)設定方法は、
前記第１のリレーノードによって、前記ソースドナーノードまたは前記ターゲットドナーノードから第１のインジケーション情報を受信するステップと、
前記第１のリレーノードによって、前記第１のインジケーション情報に基づいて前記第２のＬＣＨの前記設定情報を生成するステップと
をさらに含む請求項１または２に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項4】

第１のインジケーションは、前記第１のリレーノードによって前記ソースドナーノードから受信されたユーザ機器ＵＥコンテキスト修正要求メッセージで搬送されるか、または前記第１のリレーノードによって前記ターゲットドナーノードから受信されたＵＥコンテキスト設定要求メッセージで搬送される請求項２に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項5】

前記論理チャネル(ＬＣＨ)設定方法は、
前記第１のリレーノードが第１のメッセージを前記ターゲットドナーノードから受信した後に、前記第１のリレーノードによって前記第２のＬＣＨの前記設定情報を生成するステップをさらに含む請求項１または２に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項6】

前記第１のメッセージは、ユーザ機器ＵＥコンテキスト設定要求メッセージである請求項５に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項7】

前記論理チャネル(ＬＣＨ)設定方法は、
前記第１のリレーノードによって前記第２のインジケーション情報を前記端末へ送信するステップであって、前記第２のインジケーション情報は、前記第２のＬＣＨを前記第１のＤＲＢに対して構成するためのものであるか、または前記第１のＤＲＢを２つのＬＣＨと関連付けるように前記端末に示すものである、ステップをさらに含む請求項１乃至６のいずれか一項に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項8】

前記論理チャネル(ＬＣＨ)設定方法は、
前記第１のリレーノードによって第３のインジケーション情報を前記端末へ送信するステップであって、前記第３のインジケーション情報は、前記ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理するように前記端末に示すものである、ステップをさらに含む請求項１乃至７のいずれか一項に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項9】

前記ソースドナーノードは、前記第１のリレーノードハンドオーバ中の前記ソースドナーノードであり、前記ターゲットドナーノードは、前記第１のリレーノードハンドオーバ中の前記ターゲットドナーノードであり、前記論理チャネル(ＬＣＨ)設定方法は、
前記第１のリレーノードが物理アップリンク共有チャネル(ＰＵＳＣＨ)切り換えを実施した後に、または汎用パケット無線サービストンネルプロトコル(ＧＴＰ)トンネルが前記第１のリレーノードと前記ターゲットドナーノードの間に確立された後に、前記第１のリレーノードによって前記第３のインジケーション情報を前記端末へ送信するステップを含む請求項８に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項10】

前記論理チャネル(ＬＣＨ)設定方法は、
前記第１のリレーノードによって第４のインジケーション情報を前記ターゲットドナーノードへ送信するステップであって、前記第４のインジケーション情報は、前記ターゲットドナーノードによって用いられて、前記第１のＬＣＨを削除するように前記端末に示すものである、ステップをさらに含む請求項１乃至９のいずれか一項に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項11】

前記論理チャネル(ＬＣＨ)設定方法は、前記第１のリレーノードが、前記ソースドナーノードに対応するとともに前記第１のリレーノードによってバッファリングされている前記ＰＤＣＰデータを前記端末へ送信することを完了した後に、前記第１のリレーノードによって前記第４のインジケーション情報を前記ターゲットドナーノードへ送信するステップをさらに含む請求項１０に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項12】

前記ソースドナーノードは、前記第１のリレーノードハンドオーバ中のソースドナーノードであり、前記ターゲットドナーノードは、前記第１のリレーノードハンドオーバ中の前記ターゲットドナーノードであり、前記論理チャネル(ＬＣＨ)設定方法は、
前記第１のリレーノードによって、第５のインジケーション情報を前記ターゲットドナーノードから前記ソースドナーノードを介して受信するステップと、
前記第１のリレーノードによって、前記第５のインジケーション情報に基づいて、前記ソースドナーノードとの接続を前記ハンドオーバ中に維持するステップと
をさらに含む請求項１乃至１１のいずれか一項に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項13】

前記論理チャネル(ＬＣＨ)設定方法は、
前記第１のリレーノードによって能力インジケーション情報を前記ターゲットドナーノードへ前記ソースドナーノードを介して送信するステップをさらに含み、前記能力インジケーション情報は、前記第１のリレーノードが、前記ソースドナーノードとの接続を前記ハンドオーバ中に維持する能力をサポートすることを示すものである請求項１２に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項14】

前記第１のＬＣＨは、前記第１のリレーノードと前記ソースドナーノードの間の汎用パケット無線サービストンネルプロトコル－ユーザプレーン（ＧＴＰ－Ｕ）トンネルに対応し、前記第２のＬＣＨは、前記第１のリレーノードと前記ターゲットドナーノードの間のＧＴＰ－Ｕトンネルに対応する請求項１乃至１３のいずれか一項に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項15】

前記論理チャネル(ＬＣＨ)設定方法は、
前記第１のリレーノードによって、前記ターゲットドナーノードにより割り当てられたバックホール適応プロトコル（ＢＡＰ）アドレスについての情報を前記ソースドナーノードを介して受信するステップをさらに含み、前記ターゲットドナーノードにより前記第１のリレーノードに割り当てられたＢＡＰアドレスは、前記ソースドナーノードにより前記第１のリレーノードに割り当てられた前記ＢＡＰアドレスと異なっている請求項１乃至１４のいずれか一項に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項16】

前記論理チャネル(ＬＣＨ)設定方法は、前記第１のリレーノードによって第６のインジケーション情報を前記ターゲットドナーノードから受信するステップをさらに含み、前記第６のインジケーション情報は前記第１のリレーノードに、ＢＡＰ層のデュアル設定を開始、起動、または有効にするように示し、前記ＢＡＰ層の前記デュアル設定は、前記ソースドナーノードに対応するＢＡＰ設定と、前記ターゲットドナーノードに対応するＢＡＰ設定とを備える請求項１乃至１５のいずれか１項に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項17】

論理チャネル(ＬＣＨ)設定方法であって、端末の第１のデータ無線ベアラ(ＤＲＢ)が第１のＬＣＨに対応し、前記第１のＬＣＨが、ソースドナーノードに対応するパケットデータコンバージェンスプロトコル(ＰＤＣＰ)データを伝送するためのものであり、前記論理チャネル(ＬＣＨ)設定方法は、
前記端末によって、第２のＬＣＨの設定情報を第１のリレーノードから受信するステップであって、前記第２のＬＣＨは、ターゲットドナーノードに対応するＰＤＣＰデータを伝送するためのものである、ステップと、
前記端末によって、前記第１のＤＲＢに対して前記第２のＬＣＨを構成するステップと
を含み、
前記第１のリレーノードは前記端末のアクセスリレーノードであり、前記ソースドナーノードが第１のリレーノードハンドオーバ中のソースドナーノードであるとともに前記ターゲットドナーノードが前記第１のリレーノードハンドオーバ中のターゲットドナーノードであるか、または、前記ソースドナーノードが第２のリレーノードハンドオーバ中のソースドナーノードであるとともに前記ターゲットドナーノードが前記第２のリレーノードハンドオーバ中のターゲットドナーノードであり、第２のリレーノードが、前記第１のリレーノードと前記ソースドナーノードの間のリンク上のリレーノードであり、
前記端末は、第２のインジケーション情報を受信して、前記端末が前記第２のＬＣＨの設定情報を受信し、前記第１のＬＣＨの設定情報が削除される必要があると誤って見なす状況を回避する、
論理チャネル(ＬＣＨ)設定方法。

【請求項18】

前記ソースドナーノードに対応する前記ＰＤＣＰデータは、前記ソースドナーノードに対応するＰＤＣＰ設定情報を用いて処理され、前記ターゲットドナーノードに対応する前記ＰＤＣＰデータは、前記ターゲットドナーノードに対応する前記ＰＤＣＰ設定情報を用いて処理される請求項１７に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項19】

前記論理チャネル(ＬＣＨ)設定方法は、
前記端末によって、第１のインジケーション情報を前記第１のリレーノードから受信するステップを含み、
前記端末によって、前記第１のＤＲＢに対して前記第２のＬＣＨを構成する前記ステップは、
前記端末によって、前記第１のインジケーション情報に基づいて、前記第１のＤＲＢに対して前記第２のＬＣＨを構成して、前記第１のＤＲＢを２つのＬＣＨと関連付けるステップを含む請求項１７または１８に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項20】

前記ターゲットドナーノードに対応する前記ＰＤＣＰデータは、前記ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを含み、前記論理チャネル(ＬＣＨ)設定方法は、
前記端末によって、前記第２のインジケーション情報を前記第１のリレーノードから受信するステップと、
前記端末によって、前記第２のインジケーション情報に基づいて、前記ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理して、前記ターゲットドナーノードに対応する前記アップリンクＰＤＣＰデータを取得するステップと
をさらに含む請求項１７乃至１９のいずれか一項に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項21】

前記ターゲットドナーノードに対応する前記ＰＤＣＰデータは、前記ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを含み、前記論理チャネル(ＬＣＨ)設定方法は、
前記端末が前記第２のＬＣＨの前記設定情報を前記ターゲットドナーノードから前記第１のリレーノードを介して受信した後に、前記端末によって、前記ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理して、前記ターゲットドナーノードに対応する前記アップリンクＰＤＣＰデータを取得するステップをさらに含む請求項１７乃至１９のいずれか一項に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項22】

前記論理チャネル(ＬＣＨ)設定方法は、
前記端末によって、第３のインジケーション情報を前記第１のリレーノードから受信するステップと、
前記端末によって、前記第３のインジケーション情報に基づいて前記第１のＬＣＨを削除するステップと
をさらに含む請求項１７乃至２１のいずれか一項に記載の論理チャネル(ＬＣＨ)設定方法。

【請求項23】

少なくとも１つのプロセッサと、前記少なくとも１つのプロセッサに結合されたメモリとを備える通信装置であって、前記少なくとも１つのプロセッサは、請求項１乃至１６のいずれか一項に記載の論理チャネル(ＬＣＨ)設定方法を実施するように構成されている、通信装置。

【請求項24】

少なくとも１つのプロセッサと、前記少なくとも１つのプロセッサに結合されたメモリとを備える通信装置であって、前記少なくとも１つのプロセッサは、請求項１７乃至２２のいずれか一項に記載の論理チャネル(ＬＣＨ)設定方法を実施するように構成されている、通信装置。

【請求項25】

コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体は、請求項１乃至２２のいずれか一項に記載の論理チャネル(ＬＣＨ)設定方法を実装するためのプログラムまたは命令を記憶する、コンピュータ可読記憶媒体。

【請求項26】

コンピュータプログラムであって、前記コンピュータプログラムは命令を含み、前記命令が実行されると、請求項１乃至２２のいずれか一項に記載の前記論理チャネル(ＬＣＨ)設定方法が実施される、コンピュータプログラム。

【請求項27】

通信システムであって、前記通信システムは、請求項１乃至１６のいずれか一項に記載の前記第１のリレーノードと、請求項１７乃至２２のいずれか一項に記載の前記端末とを備える、通信システム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、通信技術の分野に関し、詳細には、データ処理方法、通信装置、および通信システムに関する。

【背景技術】

【0002】

関連出願の相互参照
本出願は、２０２０年７月３１日に中国国家知識産権局に出願された「ＬＯＧＩＣＡＬ ＣＨＡＮＮＥＬ ＬＣＨ ＣＯＮＦＩＧＵＲＡＴＩＯＮ ＭＥＴＨＯＤ， ＣＯＭＭＵＮＩＣＡＴＩＯＮ ＡＰＰＡＲＡＴＵＳ， ＡＮＤ ＣＯＭＭＵＮＩＣＡＴＩＯＮ ＳＹＳＴＥＭ」という名称の中国特許出願第２０２０１０７５７４９４．３号の優先権を主張し、同出願は参照によりその全体が本明細書に組み込まれる。

【0003】

第４世代の移動通信システムと比較して、第５世代（ｆｉｆｔｈ ｇｅｎｅｒａｔｉｏｎ、５Ｇ）移動通信は、様々なネットワーク性能指標に対して全面的により厳しい要件を課している。たとえば、容量指標が１０００倍に増大される必要があり、より広いカバレッジが要求され、また、超高信頼性および超低待ち時間が要求される。統合アクセスおよびバックホールシステム（Ｉｎｔｅｇｒａｔｅｄ ａｃｃｅｓｓ ａｎｄ ｂａｃｋｈａｕｌ、ＩＡＢ）が出現している。ＩＡＢシステムでは、高密度に配置された大量のノードが、端末にとって適応性があるとともに便利なアクセスおよびバックホールサービスを提供して、カバレッジを拡大し、５Ｇのより厳しい性能指標を満たし得る。

【0004】

ＩＡＢシステムなどの中継システムでは、リンク品質などに起因してリレーノードのハンドオーバが発生することがあり、このリレーノードのハンドオーバは、端末のサービス中断を引き起こし得る。その結果、ユーザ体験が大きく低減されることになる。

【発明の概要】

【0005】

本出願の実施形態は、リレーノードハンドオーバ中に端末がサービス中断する確率を低減して端末のサービス継続性を確保するための、論理チャネルＬＣＨ設定方法、通信装置、および通信システムを提供する。

【0006】

以下では、本出願の実施形態で提供されるダウンリンクソリューションについて、第１の態様から第４の態様を参照して説明する。第１の態様から第４の態様は、ダウンリンクソリューションを別々のネットワーク要素の観点から説明しており、第１の態様から第４の態様の内容は相互に参照されることがあることに留意されたい。

【0007】

本出願の実施形態の第１の態様は、論理チャネルＬＣＨ設定方法を提供する。この方法は、リレーノードによって、またはリレーノード内のチップによって実施されてよい。以下では、この方法がリレーノードによって実施される例を用いて説明をする。この方法では、端末の第１のデータ無線ベアラＤＲＢが第１のＬＣＨに対応し、この第１のＬＣＨは、ソースドナーノードに対応するパケットデータコンバージェンスプロトコルＰＤＣＰデータを送信するためのものである。この方法は以下を含む。すなわち、第１のリレーノードが、第１のＤＲＢに対応する第２のＬＣＨの設定情報を生成し、この第２のＬＣＨは、ターゲットドナーノードに対応するＰＤＣＰデータを送信するためのものであり、第１のリレーノードは、第２のＬＣＨの設定情報を端末へ送信する。

【0008】

この方法では、第１のリレーノードは、端末のアクセスリレーノードである。

【0009】

この方法では、ソースドナーノードは、第１のリレーノードハンドオーバ中のソースドナーノードであり、ターゲットドナーノードは、第１のリレーノードハンドオーバ中のターゲットドナーノードである。言い換えると、第１のリレーノードは、ハンドオーバが発生するノードである。代替として、ソースドナーノードは、第２のリレーノードハンドオーバ中のソースドナーノードであり、ターゲットドナーノードは、第２のリレーノードハンドオーバ中のターゲットドナーノードであり、第２のリレーノードは、第１のリレーノードとソースドナーノードの間のリンク上のリレーノードである。言い換えると、第２のリレーノードは、ハンドオーバが発生するノードである。

【0010】

この方法では、第１のＤＲＢは第１のＬＣＨに対応しており、第２のＬＣＨは第１のＤＲＢに対して構成されてよい。第１のＬＣＨは、ソースドナーノードに対応するデータを伝送するためのものであり、第２のＬＣＨは、ターゲットドナーノードに対応するデータを伝送するためのものである。端末は、異なるＬＣＨに基づいて、ソースドナーノードに対応するデータとターゲットドナーノードに対応するデータとを区別し、端末が正しい設定情報を用いてデータを処理することを確実にし、サービス中断の確率を低減し、サービス伝送連続性を改善し得る。

【0011】

可能な実装では、ソースドナーノードに対応するＰＤＣＰデータは、ソースドナーノードに対応するＰＤＣＰ設定情報を用いて処理され、ターゲットドナーノードに対応するＰＤＣＰデータは、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いて処理される。

【0012】

可能な実装では、ソースドナーノードに対応するＰＤＣＰデータは、ソースドナーノードに対応するアップリンクＰＤＣＰデータおよび／またはダウンリンクＰＤＣＰデータを含み、ターゲットドナーノードに対応するＰＤＣＰデータは、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータおよび／またはダウンリンクＰＤＣＰデータを含む。

【0013】

可能な実装では、この方法は以下をさらに含む。すなわち、第１のリレーノードは、ソースドナーノードまたはターゲットドナーノードから第１のインジケーション情報を受信し、第１のリレーノードは、第１のインジケーション情報に基づいて第２のＬＣＨの設定情報を生成する。

【0014】

任意選択で、第１のインジケーション情報は、第１のリレーノードによってソースドナーノードから受信されたユーザ機器ＵＥコンテキスト修正要求メッセージで搬送されるか、または第１のリレーノードによってターゲットドナーノードから受信されたＵＥコンテキスト設定要求メッセージで搬送される。

【0015】

可能な実装では、第１のリレーノードが第１のメッセージをターゲットドナーノードから受信した後に、第１のリレーノードは第２のＬＣＨの設定情報を生成する。

【0016】

任意選択で、第１のメッセージは、ＵＥコンテキスト設定要求メッセージである。

【0017】

可能な実装では、この方法は以下をさらに含む。すなわち、

【0018】

第１のリレーノードは第２のインジケーション情報を端末へ送信する。この第２のインジケーション情報は、第２のＬＣＨを第１のＤＲＢに対して構成するためのものであるか、または第１のＤＲＢを２つのＬＣＨと関連付けるように端末に示すものである。

【0019】

任意選択で、第２のインジケーション情報は、第１のリレーノードによって生成され、第１のリレーノードによって端末へ送信されてもよい。代替として、第２のインジケーション情報は、ターゲットドナーノードによって生成され、ターゲットドナーノードによって第１のリレーノードへ送信され、第１のリレーノードによって端末へ送信されてもよい。

【0020】

可能な実装では、この方法は以下をさらに含む。すなわち、

【0021】

第１のリレーノードは、第３のインジケーション情報を端末へ送信する。この第３のインジケーション情報は、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理するように端末に示すものである。任意選択で、第１のリレーノードはハンドオーバが発生するノードでもよく、または第２のリレーノードはハンドオーバが発生するノードである。第２のリレーノードは第３のインジケーション情報を第１のリレーノードへ送信してもよく、または第１のリレーノードは第３のインジケーション情報を端末へ送信する。

【0022】

任意選択で、ソースドナーノードは、第１のリレーノードハンドオーバ中のソースドナーノードであり、ターゲットドナーノードは、第１のリレーノードハンドオーバ中のターゲットドナーノードである。言い換えると、第１のリレーノードは、ハンドオーバが発生するノードである。この方法は、以下を含む。すなわち、第１のリレーノードが物理アップリンク共有チャネルＰＵＳＣＨ切り換えを実施した後に、またはＧＴＰトンネルが第１のリレーノードとターゲットドナーノードの間に確立された後に、第１のリレーノードは第３のインジケーション情報を端末へ送信する。

【0023】

可能な実装では、この方法は以下をさらに含む。すなわち、

【0024】

第１のリレーノードは、第４のインジケーション情報をターゲットドナーノードへ送信する。この第４のインジケーション情報は、ターゲットドナーノードによって用いられて、第１のＬＣＨを削除するように端末に示すものである。

【0025】

任意選択で、第１のリレーノードが、ソースドナーノードに対応するとともに第１のリレーノードによってバッファリングされているＰＤＣＰデータを端末へ送信することを完了した後に、第１のリレーノードは、第４のインジケーション情報をターゲットドナーノードへ送信する。

【0026】

可能な実装では、ソースドナーノードは、第１のリレーノードハンドオーバ中のソースドナーノードであり、ターゲットドナーノードは、第１のリレーノードハンドオーバ中のターゲットドナーノードである。この方法は以下をさらに含む。すなわち、第１のリレーノードは、第５のインジケーション情報をターゲットドナーノードからソースドナーノードを介して受信し、第１のリレーノードは、第５のインジケーション情報に基づいて、ソースドナーノードとの接続をハンドオーバ中に維持する。

【0027】

可能な実装では、この方法は以下をさらに含む。すなわち、第１のリレーノードは、能力インジケーション情報をソースドナーノードへ送信し、ソースドナーノードは、その能力インジケーション情報をターゲットドナーノードへ送信する。この能力インジケーション情報は、第１のリレーノードが、ソースドナーノードとの接続をハンドオーバ中に維持する能力をサポートすることを示すものである。

【0028】

可能な実装では、第１のＬＣＨは、第１のリレーノードとソースドナーノードの間のＧＴＰ－Ｕトンネルに対応し、第２のＬＣＨは、第１のリレーノードとターゲットドナーノードの間のＧＴＰ－Ｕトンネルに対応する。

【0029】

可能な実装では、この方法は以下をさらに含む。すなわち、第１のリレーノードは、ターゲットドナーノードによって割り当てられたＢＡＰアドレスについての情報をソースドナーノードを介して受信し、ターゲットドナーノードにより第１のリレーノードに割り当てられたＢＡＰアドレスは、ソースドナーノードによって第１のリレーノードに割り当てられたＢＡＰアドレスと異なっている。

【0030】

この実装では、任意選択で、ソースドナーノードに対応するＰＤＣＰデータは、ダウンリンクＰＤＣＰデータを含み、ソースドナーノードに対応するダウンリンクＰＤＣＰデータは、ソースドナーノードによって第１のリレーノードに割り当てられたＢＡＰアドレスを含み、ターゲットドナーノードに対応するＰＤＣＰデータは、ダウンリンクＰＤＣＰデータを含み、ターゲットドナーノードに対応するダウンリンクＰＤＣＰデータは、ターゲットドナーノードによって第１のリレーノードに割り当てられたＢＡＰアドレスを含む。このようにして、第１のリレーノードは、ダウンリンクデータのＢＡＰアドレスに基づいて、ダウンリンクデータがソースドナーノードからのものであるか、それともターゲットドナーノードからのものであるかを決定することができる。

【0031】

可能な実装では、この方法は以下をさらに含む。すなわち、第１のリレーノードは、第６のインジケーション情報をターゲットドナーノードから受信し、この第６のインジケーション情報は第１のリレーノードに、ＢＡＰ層のデュアル設定を開始、起動、または有効にするように示し、ＢＡＰ層のデュアル設定は、ソースドナーノードに対応するＢＡＰ設定と、ターゲットドナーノードに対応するＢＡＰ設定とを含む。

【0032】

本出願の実施形態の第２の態様は、論理チャネルＬＣＨ設定方法を提供する。この方法は、端末によって、または端末内のチップによって実施されてよい。以下では、この方法が端末によって実施される例を用いて説明をする。この方法では、端末の第１のＤＲＢが第１のＬＣＨに対応し、この第１のＬＣＨは、ソースドナーノードに対応するＰＤＣＰデータを伝送するためのものである。この方法は、以下を含む。すなわち、端末は、第２のＬＣＨの設定情報を第１のリレーノードから受信し、この第２のＬＣＨは、ターゲットドナーノードに対応するＰＤＣＰデータを伝送するためのものであり、端末は、第１のＤＲＢに対して第２のＬＣＨを構成する。

【0033】

この方法では、第１のリレーノードは、端末のアクセスリレーノードである。

【0034】

この方法では、ソースドナーノードは第１のリレーノードハンドオーバ中のソースドナーノードであり、ターゲットドナーノードは、第１のリレーノードハンドオーバ中のターゲットドナーノードである。言い換えると、第１のリレーノードは、ハンドオーバが発生するノードである。代替として、ソースドナーノードは第２のリレーノードハンドオーバ中のソースドナーノードであり、ターゲットドナーノードは、第２のリレーノードハンドオーバ中のターゲットドナーノードであり、第２のリレーノードは、第１のリレーノードとソースドナーノードの間のリンク上のリレーノードである。言い換えると、第２のリレーノードは、ハンドオーバが発生するノードである。

【0035】

可能な実装では、ソースドナーノードに対応するＰＤＣＰデータは、ソースドナーノードに対応するＰＤＣＰ設定情報を用いて処理され、ターゲットドナーノードに対応するＰＤＣＰデータは、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いて処理される。

【0036】

可能な実装では、ソースドナーノードに対応するＰＤＣＰデータは、ソースドナーノードに対応するアップリンクＰＤＣＰデータおよび／またはダウンリンクＰＤＣＰデータを含み、ターゲットドナーノードに対応するＰＤＣＰデータは、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータおよび／またはダウンリンクＰＤＣＰデータを含む。

【0037】

可能な実装では、この方法は以下をさらに含む。すなわち、端末は、第１のインジケーション情報を第１のリレーノードから受信する。端末が第１のＤＲＢに対して第２のＬＣＨを構成することは以下を含む。すなわち、端末は、第１のインジケーション情報に基づいて、第１のＤＲＢに対して第２のＬＣＨを構成して、第１のＤＲＢを２つのＬＣＨと関連付ける。

【0038】

可能な実装では、ソースドナーノードに対応するＰＤＣＰデータはダウンリンクＰＤＣＰデータを含み、ターゲットドナーノードに対応するＰＤＣＰデータはダウンリンクＰＤＣＰデータを含む。この方法は以下をさらに含む。すなわち、

【0039】

端末は、第１のリレーノードから、ソースドナーノードに対応するとともに第１のＬＣＨにマッピングされているダウンリンクＰＤＣＰデータを受信し、また、端末は、ソースドナーノードに対応するＰＤＣＰ設定情報を用いて、ソースドナーノードに対応するダウンリンクＰＤＣＰデータを処理し、および／または
端末は、第１のリレーノードから、ターゲットドナーノードに対応するとともに第２のＬＣＨにマッピングされているダウンリンクＰＤＣＰデータを受信し、また、端末は、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いて、ターゲットドナーノードに対応するダウンリンクＰＤＣＰデータを処理する。

【0040】

可能な実装では、ソースドナーノードに対応するＰＤＣＰデータは、アップリンクＰＤＣＰデータを含み、ターゲットドナーノードに対応するＰＤＣＰデータは、アップリンクＰＤＣＰデータを含む。この方法は以下をさらに含む。すなわち、

【0041】

端末は、ソースドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理して、ソースドナーノードに対応するアップリンクＰＤＣＰデータを取得し、ソースドナーノードに対応するアップリンクＰＤＣＰデータを第１のＬＣＨにマッピングし、ソースドナーノードに対応するとともに第１のＬＣＨにマッピングされているアップリンクＰＤＣＰデータを第１のリレーノードへ送信し、および／または
端末は、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理して、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを取得し、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを第２のＬＣＨにマッピングし、ターゲットドナーノードに対応するとともに第２のＬＣＨにマッピングされているアップリンクＰＤＣＰデータを第１のリレーノードへ送信する。

【0042】

可能な実装では、ターゲットドナーノードに対応するＰＤＣＰデータは、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを含む。この方法は以下をさらに含む。すなわち、

【0043】

端末は、第２のインジケーション情報を第１のリレーノードから受信し、
端末は、第２のインジケーション情報に基づいて、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理して、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを取得する。

【0044】

可能な実装では、ターゲットドナーノードに対応するＰＤＣＰデータは、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを含む。この方法は以下をさらに含む。すなわち、

【0045】

端末は、第２のＬＣＨの設定情報をターゲットドナーノードから第１のリレーノードを介して受信した後に、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理して、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを取得する。

【0046】

可能な実装では、この方法は以下をさらに含む。すなわち、端末は、第３のインジケーション情報を第１のリレーノードから受信し、この第３のインジケーション情報に基づいて第１のＬＣＨを削除する。

【0047】

本出願の実施形態の第３の態様は、ＢＡＰアドレス割り当て方法を提供する。この方法は、ソースドナーノードによって、またはソースドナーノード内のチップによって実施されてよい。以下では、この方法がソースドナーノードによって実施される例を用いて説明をする。この方法は、以下を含む。すなわち、ソースドナーノードは、ターゲットドナーノードへ、ソースドナーノードによってアクセスリレーノードに割り当てられたＢＡＰアドレスを送信する。

【0048】

この方法では、ソースドナーノードは、アクセスリレーノードハンドオーバ中の、または中間リレーノードハンドオーバ中のソースドナーノードであり、ターゲットドナーノードは、アクセスリレーノードハンドオーバ中の、または中間リレーノードハンドオーバ中のターゲットドナーノードである。中間リレーノードは、アクセスリレーノードに接続されている。ハンドオーバが発生するリレーノードは、移行リレーノードと呼ばれることがある。

【0049】

任意選択で、この方法は以下をさらに含む。すなわち、ソースドナーノードは、ターゲットドナーノードから、ターゲットドナーノードによってアクセスリレーノードに割り当てられたＢＡＰアドレスを受信し、このＢＡＰアドレスをアクセスリレーノードへ送信する。

【0050】

可能な実装では、ソースドナーノードによってアクセスＩＡＢノードに割り当てられたＢＡＰアドレスは、ターゲットドナーノードによってアクセスＩＡＢノードに割り当てられたＢＡＰアドレスとは異なる。

【0051】

ソースドナーノードとターゲットドナーノードは、別々のＢＡＰアドレスをアクセスリレーノードに割り当てる。したがって、アクセスリレーノードは、ダウンリンクデータを受信した後、ダウンリンクデータで搬送されたＢＡＰアドレスに基づいて、ダウンリンクデータがソースドナーノードからのものであるか、それともターゲットドナーノードからのものであるかを決定し、それにより、ダウンリンクデータが正しい設定情報を用いて処理されて、データ連続性が確保されることが可能である。

【0052】

任意選択で、この方法は以下をさらに含む。すなわち、ソースドナーノードは、第１のインジケーション情報をアクセスリレーノードへ送信し、それにより、アクセスリレーノードは第２のＬＣＨの設定情報を生成する。第１のインジケーション情報は、ＵＥコンテキスト修正要求メッセージで搬送されてよい。任意選択で、アクセスリレーノードは、ハンドオーバが発生するリレーノードである。この方法は以下をさらに含む。すなわち、ソースドナーノードは、第２のインジケーション情報をターゲットドナーノードから受信し、この第２のインジケーション情報をアクセスリレーノードへ送信する。この第２のインジケーション情報は、ソースドナーノードとの接続をハンドオーバ中に維持するようにアクセスリレーノードに示すものである。

【0053】

任意選択で、アクセスリレーノードは、ハンドオーバが発生するリレーノードである。この方法は以下をさらに含む。すなわち、ソースドナーノードは、能力インジケーション情報をアクセスリレーノードから受信する。能力インジケーション情報は、第１のリレーノードが、ソースドナーノードとの接続をハンドオーバ中に維持する能力をサポートすることを示すものであり、ソースドナーノードは、その能力インジケーション情報をターゲットドナーノードへ送信する。

【0054】

本出願の実施形態の第４の態様は、ＢＡＰアドレス割り当て方法を提供する。この方法は、ターゲットドナーノードによって、またはターゲットドナーノード内のチップによって実施されてよい。以下では、この方法がターゲットドナーノードによって実施される例を用いて説明をする。この方法は、以下を含む。すなわち、ターゲットドナーノードは、ソースドナーノードから、ターゲットドナーノードによってアクセスリレーノードに割り当てられたＢＡＰアドレスを受信する。

【0055】

この方法では、ソースドナーノードは、アクセスリレーノードハンドオーバ中の、または中間リレーノードハンドオーバ中のソースドナーノードであり、ターゲットドナーノードは、アクセスリレーノードハンドオーバ中の、または中間リレーノードハンドオーバ中のターゲットドナーノードである。中間リレーノードは、アクセスリレーノードに接続されている。ハンドオーバが発生するリレーノードは、移行リレーノードと呼ばれることがある。

【0056】

任意選択で、この方法は以下をさらに含む。すなわち、ターゲットドナーノードは、ソースドナーノードを介してアクセスＩＡＢノードに、ターゲットドナーノードによってアクセスＩＡＢノードに割り当てられたＢＡＰアドレスを送信する。

【0057】

可能な実装では、ソースドナーノードによってアクセスＩＡＢノードに割り当てられたＢＡＰアドレスは、ターゲットドナーノードによってアクセスＩＡＢノードに割り当てられたＢＡＰアドレスとは異なる。

【0058】

可能な実装では、この方法は以下をさらに含む。すなわち、ターゲットドナーノードは、第１のインジケーション情報をアクセスリレーノードへ送信し、それにより、アクセスリレーノードは第２のＬＣＨの設定情報を生成する。任意選択で、第１のインジケーション情報は、ＵＥコンテキスト設定要求メッセージで搬送される。

【0059】

可能な実装では、この方法は以下をさらに含む。すなわち、ターゲットドナーノードは、第２のインジケーション情報を端末へアクセスリレーノードを介して送信する。この第２のインジケーション情報は、第２のＬＣＨを第１のＤＲＢに対して構成するためのものであるか、または第１のＤＲＢを２つのＬＣＨと関連付けるように端末に示すものである。

【0060】

可能な実装では、この方法は以下をさらに含む。すなわち、ターゲットドナーノードは、アクセスリレーノードによって送信された第３のインジケーション情報を受信する。この第３のインジケーション情報は、ターゲットドナーノードによって用いられて、第１のＬＣＨを削除するように端末に示すものである。

【0061】

可能な実装では、この方法は以下をさらに含む。すなわち、ターゲットドナーノードは、第４のインジケーション情報をアクセスリレーノードへソースドナーノードを介して送信する。この第４のインジケーション情報は、ソースドナーノードとの接続をハンドオーバ中に維持するようにアクセスリレーノードに示すものである。

【0062】

任意選択で、この方法は以下を含む。すなわち、ターゲットドナーノードは、能力インジケーション情報をアクセスリレーノードからソースドナーノードを介して受信する。この能力インジケーション情報は、アクセスリレーノードが、ソースドナーノードとの接続をハンドオーバ中に維持する能力をサポートすることを示すものである。

【0063】

可能な実装では、この方法は以下をさらに含む。すなわち、ターゲットドナーノードは、第５のインジケーション情報をアクセスリレーノードへ送信し、この第５のインジケーション情報はアクセスリレーノードに、ＢＡＰ層のデュアル設定を開始、起動、または有効にするように示し、ＢＡＰ層のデュアル設定は、ソースドナーノードに対応するＢＡＰ設定と、ターゲットドナーノードに対応するＢＡＰ設定とを含む。

【0064】

第１の態様から第４の態様における１つまたは複数の方法は、互いに組み合わされてもよい。加えて、各態様における方法では、複数の可能な実装のうちの１つまたは複数が互いに組み合わされてもよい。

【0065】

本出願の実施形態の第５の態様は、通信装置を提供する。通信装置は、端末でも端末内のチップでもよく、通信装置は、リレーノードでもリレーノード内のチップでもよく、通信装置は、ターゲットドナーノードでもターゲットドナーノード内のチップでもよく、通信装置は、ソースドナーノードでもソースドナーノード内のチップでもよい。通信装置はプロセッサを含み、このプロセッサは、コンピュータプログラムまたは命令を実行して、通信装置が第１の態様から第４の態様による方法を実施することができるように構成される。

【0066】

任意選択で、通信装置はメモリをさらに含む。プロセッサはメモリと結合され、メモリは、コンピュータプログラムまたは命令を記憶するように構成され、プロセッサは、メモリ内のコンピュータプログラムまたは命令を実行するように構成される。

【0067】

任意選択で、通信装置は通信ユニットをさらに含み得る。通信ユニットは、通信装置内の別のデバイスまたは別の構成要素と通信するように構成されている。たとえば、通信装置は端末であり、通信ユニットはトランシーバである。たとえば、通信装置は端末内のチップであり、通信ユニットは、そのチップの入出力回路またはインターフェースである。

【0068】

本出願の実施形態の第６の態様は、通信装置を提供する。通信装置は、端末、リレーノード、ソースドナーノード、またはターゲットドナーノードの動作を前述の方法の態様で実装する機能を有し、第１の態様から第６の態様による方法の態様で説明されているステップまたは機能を実施するように構成された対応する手段（ｍｅａｎｓ）を含む。そのステップまたは機能は、ソフトウェア、ハードウェア、またはハードウェアとソフトウェアの組み合わせによって実装され得る。

【0069】

本出願の実施形態の第７の態様は、チップを提供する。このチップはプロセッサおよびインターフェース回路を含み、インターフェース回路はプロセッサと結合され、プロセッサは、コンピュータプログラムまたは命令を実行して、第１の態様から第４の態様のいずれか１つによる方法を実装するように構成され、また、インターフェース回路は、チップ以外のモジュールと通信するように構成される。

【0070】

本出願の実施形態の第８の態様は、コンピュータ記憶媒体を提供する。このコンピュータ記憶媒体は、第１の態様から第４の態様のうちのいずれか１つによる方法を実装するためのプログラムを記憶する。プログラムが無線通信装置で実行されると、無線通信装置は、第１の態様から第４の態様のうちのいずれか１つによる方法を実施することが可能にされる。

【0071】

本出願の実施形態の第９の態様は、コンピュータプログラム製品を提供する。このプログラム製品は、プログラムを含む。プログラムが実行されると、第１の態様から第４の態様のうちのいずれか１つによる方法が実施される。

【0072】

本出願の実施形態の第１０の態様は、通信システムを提供する。通信システムは、第１の態様から第４の態様までの方法における端末、リレーノード、ソースドナーノード、およびターゲットドナーノードのうちの１つまたは複数を含む。任意選択で、通信システムは、コアネットワーク要素をさらに含み得る。任意選択で、コアネットワーク要素は、ソースドナーノードおよびターゲットドナーノードに接続される。

【図面の簡単な説明】

【0073】

本出願の実施形態における、または背景における技法的ソリューションをより明確に説明するために、以下では、本出願の実施形態または背景を説明するための添付図面について説明する。

【図1】本出願の実施形態による移動通信システム１００の概略図である。

【図2】本出願の実施形態によるＩＡＢネットワーク２００の概略図である。

【図3】本出願の実施形態によるＣＵ－ＤＵ分割アーキテクチャの概略図である。

【図4】本出願の実施形態による、ＣＵ－ＤＵ分割アーキテクチャでのコントロールプレーンプロトコルスタックの概略図である。

【図5】本出願の実施形態による、ＣＵ－ＤＵスプリットアーキテクチャでのユーザプレーンプロトコルスタックの概略図である。

【図6】本出願の実施形態による、ＩＡＢネットワークにおけるコントロールプレーンプロトコルスタックの概略図である。

【図7】本出願の実施形態による、ＩＡＢネットワークにおけるユーザプレーンプロトコルスタックの概略図である。

【図8】本出願の実施形態によるＤＡＰＳの概略図である。

【図9A】本出願の実施形態による、シングルエアインターフェースの場合におけるＤＡＰＳベースのハンドオーバの概略フローチャートである。

【図9B】本出願の実施形態による、シングルエアインターフェースの場合におけるＤＡＰＳベースのハンドオーバの概略フローチャートである。

【図10】本出願の実施形態によるリレーノードハンドオーバの概略図である。

【図11】本出願の実施形態によるドナー－ＣＵ間ハンドオーバの概略図である。

【図12】本出願の実施形態によるデュアルＬＣＨユーザプレーンプロトコルスタックの概略図である。

【図13】本出願の実施形態によるＬＣＨ設定方法の概略フローチャートである。

【図14】本出願の実施形態によるインジケーション方法のフローチャートである。

【図15】本出願の実施形態によるＬＣＨ削除方法のフローチャートである。

【図16】本出願の実施形態によるインジケーション方法のフローチャートである。

【図17A】本出願の実施形態によるドナー－ノード間ハンドオーバ方法の概略図である。

【図17B】本出願の実施形態によるドナー－ノード間ハンドオーバ方法の概略図である。

【図17C】本出願の実施形態によるドナー－ノード間ハンドオーバ方法の概略図である。

【図17D】本出願の実施形態によるドナー－ノード間ハンドオーバ方法の概略図である。

【図17E】本出願の実施形態によるドナー－ノード間ハンドオーバ方法の概略図である。

【図18A】本出願の実施形態による別のドナー－ノード間ハンドオーバ方法の概略図である。

【図18B】本出願の実施形態による別のドナー－ノード間ハンドオーバ方法の概略図である。

【図18C】本出願の実施形態による別のドナー－ノード間ハンドオーバ方法の概略図である。

【図18D】本出願の実施形態による別のドナー－ノード間ハンドオーバ方法の概略図である。

【図19】本出願の実施形態による端末の構造の概略図である。

【図20】本出願の実施形態による通信装置の構造の概略図である。

【図21】本出願の実施形態によるアクセスネットワークデバイスの構造の概略図である。

【図22】本出願の実施形態による通信装置の構造の概略図である。

【発明を実施するための形態】

【0074】

以下では、本出願の実施形態について本出願の実施形態の添付図面を参照して説明する。

【0075】

図１は、本出願の実施形態による通信システム１００のアーキテクチャの概略図である。通信システム１００は、少なくとも１つの端末（たとえば、端末１１０および端末１２０）、少なくとも１つのリレーノード（ｒｅｌａｙ ｎｏｄｅ、ＲＮ）１３０、少なくとも１つのアクセスネットワークデバイス１４０、および少なくとも１つのコアネットワークデバイス１５０を含む。端末１１０および１２０はアクセスネットワークデバイス１４０に接続され、または、端末１１０および１２０はリレーノード１３０を介してアクセスネットワークデバイス１４０に接続される。リレーノード１３０はアクセスネットワークデバイス１４０に接続され、または、リレーノード１３０は別のリレーノードを介してアクセスネットワークデバイス１４０に接続される。アクセスネットワークデバイス１４０は、コアネットワークデバイス１５０に有線で接続される。端末１１０および１２０とリレーノード１３０とアクセスネットワークデバイス１４０とコアネットワークデバイス１５０は、無線でも有線でも接続され得る。これは、本出願において限定されていない。

【0076】

本出願で提供される通信システムは、たとえば、４Ｇアクセス技術をサポートするロングタームエボリューション（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ、ＬＴＥ）システム、５Ｇアクセス技術をサポートするニューラジオ（ｎｅｗ ｒａｄｉｏ、ＮＲ）システム、第３世代パートナーシッププロジェクト（３ｒｄ ｇｅｎｅｒａｔｉｏｎ ｐａｒｔｎｅｒｓｈｉｐ ｐｒｏｊｅｃｔ、３ＧＰＰ）に関連する任意のセルラーシステム、ワイヤレスフィデリティ（ｗｉｒｅｌｅｓｓ ｆｉｄｅｌｉｔｙ、Ｗｉ－Ｆｉ）システム、ワールドワイドインターオペラビリティフォーマイクロウェーブアクセス（ｗｏｒｌｄｗｉｄｅ ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ ｍｉｃｒｏｗａｖｅ ａｃｃｅｓｓ、ＷｉＭＡＸ）システム、マルチ無線アクセス技術（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ、ＲＡＴ）システム、または他の未来志向通信技術を用いるシステムであってよい。本出願において、端末は、無線トランシーバ機能を有するデバイスである。端末は、屋内もしくは屋外端末、ハンドヘルド端末、ウェアラブル端末、または車載端末を含めて陸上に配置されてよく、水面上に（たとえば、船上に）配置されてよく、または空中に（たとえば、ドローン、飛行機、気球、および衛星上に）配置されてよい。端末は、移動電話（ｍｏｂｉｌｅ ｐｈｏｎｅ）、タブレット（Ｐａｄ）、無線トランシーバ機能を有するコンピュータ、仮想現実（ｖｉｒｔｕａｌ ｒｅａｌｉｔｙ、ＶＲ）端末デバイス、拡張現実（ａｕｇｍｅｎｔｅｄ ｒｅａｌｉｔｙ、ＡＲ）端末デバイス、産業制御（ｉｎｄｕｓｔｒｉａｌ ｃｏｎｔｒｏｌ）における無線端末、自動運転（ｓｅｌｆ ｄｒｉｖｉｎｇ）における無線端末、遠隔医療（ｒｅｍｏｔｅ ｍｅｄｉｃａｌ）における無線端末、スマートグリッド（ｓｍａｒｔ ｇｒｉｄ）における無線端末、交通安全（ｔｒａｎｓｐｏｒｔａｔｉｏｎ ｓａｆｅｔｙ）における無線端末、スマートシティ（ｓｍａｒｔ ｃｉｔｙ）における無線端末、スマートホーム（ｓｍａｒｔ ｈｏｍｅ）における無線端末などであり得る。適用シナリオが、本出願の実施形態においては限定されていない。端末はまた、場合により、端末デバイス、ユーザ機器（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ、ＵＥ）、アクセス端末デバイス、局、ＵＥユニット、ＵＥ局、移動局、リモート局、リモート端末デバイス、移動デバイス、ＵＥ端末デバイス、端末デバイス、無線通信デバイス、ＵＥエージェント、ＵＥ装置と呼ばれることも、他の適切な用語で呼ばれることもある。端末は、固定されていても移動可能であってもよい。

【0077】

アクセスネットワークデバイスは、アクセスネットワーク側にあるとともに、通信システムにアクセスする際に端末をサポートするように構成されているデバイスであり得る。アクセスネットワークデバイスは、基地局（ｂａｓｅ ｓｔａｔｉｏｎ、ＢＳ）と呼ばれること、たとえば、４Ｇアクセス技術をサポートする通信システムにおける進化型ＮｏｄｅＢ（ｅｖｏｌｖｅｄ ＮｏｄｅＢ、ｅＮＢ）、５Ｇアクセス技術をサポートする通信システムにおける次世代ＮｏｄｅＢ（次世代ＮｏｄｅＢ、ｇＮＢ）、送信受信点（ｔｒａｎｓｍｉｓｓｉｏｎ ｒｅｃｅｐｔｉｏｎ ｐｏｉｎｔ、ＴＲＰ）、リレーノード（ｒｅｌａｙ ｎｏｄｅ）、アクセスポイント（ａｃｃｅｓｓ ｐｏｉｎｔ、ＡＰ）、Ｗｉ－Ｆｉシステムにおけるアクセスノード、または無線バックホールノードと呼ばれることがある。代替として、アクセスネットワークデバイスは、ドナーノード、ＩＡＢドナー（ＩＡＢ ｄｏｎｏｒ）、ドナーＩＡＢ、ドナー、ドナーｇＮＢ（ｄｏｎｏｒ ｇＮＢ、ＤｇＮＢ）などと呼ばれることもある。基地局は、マクロ基地局、マイクロ基地局、ピコ基地局、スモールセル、中継局などであり得る。複数の基地局は、同一の技術を用いて前述のネットワークをサポートしても、別々の技術を用いて前述のネットワークをサポートしてもよい。基地局は、１つまたは複数の共通サイトもしくは非共通サイトの送信受信ポイント（Ｔｒａｎｓｍｉｓｓｉｏｎ ｒｅｃｅｐｔｉｏｎ ｐｏｉｎｔ、ＴＲＰ）を含み得る。アクセスネットワークデバイスは、代替として、クラウド無線アクセスネットワーク（ｃｌｏｕｄ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ、ＣＲＡＮ）シナリオにおける無線コントローラ、中央ユニット（ｃｅｎｔｒａｌ ｕｎｉｔ、ＣＵ）、および／または分散ユニット（ｄｉｓｔｒｉｂｕｔｅｄ ｕｎｉｔ、ＤＵ）でもよい。アクセスネットワークデバイスは、代替としてサーバ、ウェアラブルデバイス、車載デバイスなどでもよい。以下では、アクセスネットワークデバイスが基地局である例を用いて説明をする。通信システムにおける複数のアクセスネットワークデバイスは、同一の種類の基地局でも、別々の種類の基地局でもよい。基地局は、端末と通信することも、中継局を介して端末デバイスと通信することもある。端末は、異なる技術を用いて複数の基地局と通信し得る。たとえば、端末は、ＬＴＥネットワークをサポートする基地局と通信することも、５Ｇネットワークをサポートする基地局と通信することも、ＬＴＥネットワーク内の基地局と５Ｇネットワーク内の基地局とのデュアル接続をサポートすることもある。

【0078】

コアネットワークデバイスは、１つまたは複数のアクセスネットワークデバイスに接続されてよく、セッション管理、アクセス認証、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ、ＩＰ）アドレス割り当て、およびデータ伝送のうちの１つまたは複数の機能をシステム内の端末に提供し得る。たとえば、コアネットワークデバイスは、４Ｇアクセス技術をサポートする通信システムにおける、モビリティ管理エンティティ（ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ、ＭＭＥ）もしくはサービングゲートウェイ（ｓｅｒｖｉｎｇ ｇａｔｅｗａｙ、ＳＧＷ）、または５Ｇアクセス技術をサポートする通信システムにおける、アクセスモビリティ管理機能（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ、ＡＭＦ）ネットワーク要素もしくはユーザプレーン機能（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ、ＵＰＦ）ネットワーク要素であってよい。コアネットワークデバイスは、代替としてコアネットワーク要素と呼ばれることもある。

【0079】

リレーノードは、無線アクセスサービスおよび／または無線バックホールサービスを提供するノードであり得る。無線アクセスサービスは、無線アクセスリンクを介して提供されるデータおよび／またはシグナリングアクセスサービスであり、無線バックホールサービスは、無線バックホールリンクを介して提供されるデータおよび／またはシグナリングバックホールサービスである。リレーノードは、端末とアクセスネットワークデバイスの間でデータおよび／またはシグナリングを転送するように構成される。１つの態様では、リレーノードは、無線アクセスサービスを端末に、アクセスリンク（ａｃｃｅｓｓ ｌｉｎｋ、ＡＬ）を介して提供する。別の態様では、リレーノードはアクセスネットワークデバイスに、ワンホップまたはマルチホップバックホールリンク（ｂａｃｋｈａｕｌ ｌｉｎｋ、ＢＬ）を介して接続される。

【0080】

リレーノードは、異なる通信システムでは異なる名称を有し得る。たとえば、リレーノードは、無線バックホールノードまたは無線バックホールデバイスと呼ばれることがある。たとえば、５Ｇシステムにおいて、リレーノードは、統合アクセスおよびバックホールノード（ｉｎｔｅｇｒａｔｅｄ ａｃｃｅｓｓ ａｎｄ ｂａｃｋｈａｕｌ ｎｏｄｅ、ＩＡＢ ｎｏｄｅ）と呼ばれることがある。確実なことには、将来の通信システムにおいてリレーノードは、異なる名称を代替として有し得る。これは、本明細書では限定されていない。

【0081】

図２は、本出願の実施形態による統合アクセスおよびバックホール（ｉｎｔｅｇｒａｔｅｄ ａｃｃｅｓｓ ａｎｄ ｂａｃｋｈａｕｌ、ＩＡＢ）ネットワーク２００の概略図である。図２は、図１に示された通信システム１００の適用シナリオである。以下では、図１の端末、リレーノード、およびアクセスネットワークデバイスについて、図２を参照してさらに説明する。

【0082】

図２において、端末１は、図１における端末１１０であってよい。ＩＡＢノード（ｎｏｄｅ）２、ＩＡＢノード３、およびＩＡＢノード１は、図１のリレーノード１３０であってよい。ＩＡＢドナー１は、図１のアクセスネットワークデバイス１４０であってよい。ＩＡＢドナー１は、図１のコアネットワークデバイス１５０に接続されてよい（たとえば、有線で）。ＩＡＢドナーは、ドナーノード（ｄｏｎｏｒ ｎｏｄｅ）、ＤｇＮＢ（すなわち、ドナーｇＮｏｄｅＢ）として参照されても、他の適切な名称でもよい。これは、本出願では限定されていない。

【0083】

ＩＡＢネットワーク２００は、１つまたは複数の端末（分かりやすいように、図２は端末１のみを示す）、１つまたは複数のＩＡＢノード（たとえば、図２は３つのＩＡＢノードを、すなわち、ＩＡＢノード２、ＩＡＢノード３、およびＩＡＢノード１を示す）、および１つまたは複数のドナーノード（分かりやすいように、図２はＩＡＢドナー１のみを示す）を含む。端末１は、１つまたは複数のＩＡＢノードに無線で接続されてよい。各ＩＡＢノードは、１つまたは複数の他のＩＡＢノードに無線で接続されてよく、１つまたは複数のＩＡＢノードは、１つまたは複数のドナーノードに無線で接続されてよい。任意選択で、１つまたは複数のＩＡＢノードは、互いに無線でさらに接続されてもよい。これは、本出願において限定されていない。

【0084】

ＩＡＢネットワークにおいて、端末とドナーノードの間の１つの伝送路は、１つまたは複数のＩＡＢノードを含み得ると理解されてよい。１つのＩＡＢノードが、端末によってアクセスされるノードである場合、そのＩＡＢノードと子ノード（すなわち、端末）の間のリンクは、アクセスリンクと呼ばれることがある。１つのＩＡＢノードが、別のＩＡＢノードによってサービスされる端末にバックホールサービスを提供するノードである場合、そのＩＡＢノードと子ノード（すなわち、別のＩＡＢノード）の間のリンクは、バックホールリンクと呼ばれることがある。たとえば、図２に示されるように、端末１はＩＡＢノード２に無線アクセスリンクを介して接続され、ＩＡＢノード２はＩＡＢノード３に無線バックホールリンクを介して接続され、ＩＡＢノード３はＩＡＢノード１に無線バックホールリンクを介して接続され、ＩＡＢノード１はＩＡＢドナーに無線バックホールリンクを介して接続される。

【0085】

サービス伝送信頼性を確保するために、任意選択で、ＩＡＢネットワークでは、マルチホップＩＡＢノードネットワーキングおよびマルチコネクティビティＩＡＢノードネットワーキングがサポートされる。端末とＩＡＢドナーの間には、複数の伝送路が存在し得る。１つの経路上で、ＩＡＢノード間、およびＩＡＢノードとＩＡＢノードにサービスを提供するドナーノードとの間には、決定された階層関係がある。各ＩＡＢノードは、そのＩＡＢノードにアクセスサービスを提供するノードを親ノードと見なす。それに応じて、各ＩＡＢノードは、そのＩＡＢノードの親ノードの子ノードと見なされ得る。

【0086】

たとえば、図２で、ＩＡＢノード１の親ノードはＩＡＢドナー１であり、ＩＡＢノード１はＩＡＢノード３の親ノードであり、ＩＡＢノード３はＩＡＢノード２の親ノードであり、ＩＡＢノード２は端末１の親ノードである。

【0087】

端末のアップリンクデータパケットは、１つまたは複数のＩＡＢノードを介してドナーノードへ伝送され、次に、ドナーノードによってコアネットワークデバイスへ、たとえばモバイルゲートウェイデバイス（たとえば、５Ｇネットワーク内のユーザプレーン機能（ｕｓｅｒ ｐｌａｎｅ ｆｕｎｃｔｉｏｎ、略称ＵＰＦ）ネットワーク要素）へ送信され得る。端末のダウンリンクデータパケットは、ドナーノードによってコアネットワークデバイス（すなわち、モバイルゲートウェイデバイス）から受信され、次に、１つまたは複数のＩＡＢノードを介して端末へ送信される。

【0088】

たとえば、図２で、端末１とＩＡＢドナー１の間のアップリンクデータパケットの伝送経路は、端末１→ＩＡＢノード２→ＩＡＢノード３→ＩＡＢノード１→ＩＡＢドナー１であり、端末１とＩＡＢドナー１の間のダウンリンクデータパケットの伝送経路は、ＩＡＢドナー１→ＩＡＢノード１→ＩＡＢノード３→ＩＡＢノード２→端末１である。

【0089】

ＩＡＢネットワークでは、１つの伝送路上で、端末によってアクセスされるＩＡＢノードはアクセスＩＡＢノードと呼ばれることがあり、伝送路上の別のＩＡＢノードは中間ＩＡＢノードと呼ばれる。中間ＩＡＢノードは、バックホールサービスを端末に提供することがある。１つのＩＡＢノードは、端末のアクセスＩＡＢノードとして使用されてよく、また、別の端末の中間ＩＡＢノードとして使用されてもよい。

【0090】

たとえば、図２で、経路「端末１→ＩＡＢノード２→ＩＡＢノード３→ＩＡＢノード１→ＩＡＢドナー１」上で、ＩＡＢノード２はアクセスＩＡＢノードであり、ＩＡＢノード３およびＩＡＢノード１は中間ＩＡＢノードである。ＩＡＢノード３は、アクセスサービスをＩＡＢノード２に提供し、かつ／またはバックホールサービスを端末１に提供する。ＩＡＢノード１は、アクセスサービスをＩＡＢノード３に提供し、かつ／またはバックホールサービスを端末１に提供する。端末２（図２には示されていない）がＩＡＢノード３にアクセスする場合、端末１に対してはＩＡＢノード３が中間ＩＡＢノードになり、端末２に対してはＩＡＢノード３がアクセスＩＡＢノードになる。

【0091】

ＩＡＢネットワークにおいて、ＩＡＢノードおよび１つまたは複数の端末によってサービスされる１つまたは複数のＩＡＢノードは、ＩＡＢノードの子孫（ｄｅｓｃｅｎｄａｎｔ）ノードと呼ばれることがある。子孫ノードは、ＩＡＢノードによってサービスされるＩＡＢノード、たとえば、子ノード、孫ノード、およびひ孫ノードと、ＩＡＢノードにアクセスする端末、たとえば、子ノード、孫ノード、およびひ孫ノードにアクセスする端末とを含み得ると理解されてよい。

【0092】

たとえば、図２において、ＩＡＢノード１の子孫ノードは、端末１、ＩＡＢノード２、およびＩＡＢノード３を含む。

【0093】

前述のＩＡＢネットワークは単なる一例にすぎない。マルチホップとマルチコネクティビティが組み合わされたＩＡＢネットワークでは、より多くの他の可能性がＩＡＢネットワークにある。たとえば、ドナーノードと、別のドナーノードによってサービスされるＩＡＢノードとが、二重接続性を形成して端末にサービスする。その可能性は、本明細書では１つずつ列挙されていない。

【0094】

ＩＡＢネットワークでは、ＩＡＢドナーに関して、ＩＡＢドナーは、中央ユニット（ＩＡＢドナーＣＵと呼ばれることがある）と、分散ユニット（ＩＡＢドナーＤＵと呼ばれることがある）とを含み得る。

【0095】

ＩＡＢネットワークでは、ＩＡＢノードに関して、親ノードとしてサービスする場合、ＩＡＢノードは、アクセスネットワークデバイスと同様の役割を果たして、アクセスサービスをＩＡＢノードの子ノードに提供し、たとえば、アップリンクデータ伝送用のアップリンクリソースをスケジューリングによってＩＡＢノードの子ノードに割り当てることがある。ＩＡＢノードが子ノードとしてサービスする場合、ＩＡＢノードにサービスする親ノードに対して、ＩＡＢノードは、端末デバイスの役割を果たし、たとえば、セル選択およびランダムアクセスなどの動作によって親ノードとの接続を確立し、また、アップリンクデータ伝送のためのものであり親ノードによってＩＡＢノード用にスケジュールされている、アップリンクリソースを取得することがある。

【0096】

限定ではなく例として、本出願のこの実施形態では、ＩＡＢノードにあって、端末デバイスの役割を実装する際にＩＡＢノードをサポートする機能ユニットが、ＩＡＢノードの移動端末（ｍｏｂｉｌｅ ｔｅｒｍｉｎａｌ、ＭＴ）機能ユニットと呼ばれ、この機能ユニットは略してＩＡＢ－ＭＴまたはＩＡＢ－ＵＥと呼ばれ、また、ＩＡＢノードにあって、アクセスネットワークデバイスの役割を実装する際にＩＡＢノードをサポートする機能ユニットが、ＩＡＢノードのＤＵ機能ユニットと呼ばれ、この機能ユニットは略してＩＡＢ－ＤＵと呼ばれる。ＩＡＢ－ＭＴおよびＩＡＢ－ＤＵは論理機能ユニットであってよくＩＡＢ－ＭＴおよびＩＡＢ－ＤＵの機能は、ＩＡＢノードによって実装される。代替として、ＩＡＢ－ＭＴとＩＡＢ－ＤＵは物理的分割であってもよく、ＩＡＢ－ＭＴとＩＡＢ－ＤＵは、ＩＡＢノード内の別々の物理デバイスであってよい。

【0097】

図２は、ＩＡＢネットワークを例として用いて説明されていることに留意されたい。図２の内容はまた、ＩＡＢネットワーク以外のリレーネットワークにも適用可能であり、図２の「ＩＡＢ」が「リレー」に置き換えられてよい。たとえば、ＩＡＢノード２がリレーノード２に、ＩＡＢノード３がリレーノード３に、ＩＡＢノード１がリレーノード１に、ＩＡＢドナー１がドナーノード１に置き換えられてよい。ネットワーク要素間の接続関係についての説明に関して、リレーネットワーク内のアクセスリンク、バックホールリンク、親ノード、子ノード、アクセスリレーノード、中間アクセスノードなどでは、ＩＡＢネットワーク２００についての説明を参照する。

【0098】

図３は、本出願の実施形態によるＣＵ－ＤＵ分割アーキテクチャの概略図である。図１のアクセスネットワークデバイス、または図２のＩＡＢドナーは、ＣＵ－ＤＵ分割アーキテクチャを用いることがある。以下では、図３を参照して説明をする。

【0099】

アクセスネットワークデバイス１４０は、クラウド無線アクセスネットワーク（ｃｌｏｕｄ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ、Ｃ－ＲＡＮ）アーキテクチャを用いて実装されてよい。基地局（ここでは、説明のためにｇＮＢが例として用いられている）の一部の機能は、中央ユニット（ｃｅｎｔｒａｌ ｕｎｉｔ、ＣＵ）によって実装され、他の機能は分散ユニット（ｄｉｓｔｒｉｂｕｔｅｄ ｕｎｉｔ、ＤＵ）によって実装される。ＣＵ－ＤＵ分割は、プロトコルスタックによって実施されてよい。可能な手法では、無線リソースコントロール（ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ、ＲＲＣ）層、サービスデータアダプテーションプロトコル（ｓｅｒｖｉｃｅ ｄａｔａ ａｄａｐｔａｔｉｏｎ ｐｒｏｔｏｃｏｌ、ＳＤＡＰ）層、およびパケットデータコンバージェンスプロトコル（ｐａｃｋｅｔ ｄａｔａ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｔｏｃｏｌ、ＰＤＣＰ）層はＣＵ内に配置され、無線リンクコントロール（ｒａｄｉｏ ｌｉｎｋ ｃｏｎｔｒｏｌ、ＲＬＣ）層、メディアアクセスコントロール（ｍｅｄｉａ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ、ＭＡＣ）層、および物理（ｐｈｙｓｉｃａｌ、ＰＨＹ）層はＤＵ内に配置される。ネットワーク拡張を容易にするために、１つのＣＵが１つまたは複数のＤＵに接続されることがある。ＣＵは、インターフェース（たとえば、Ｆ１インターフェース）を介してＤＵに接続され、またＣＵは、インターフェース（たとえば、ＮＧインターフェース）を介してコアネットワークに接続される。

【0100】

実装において、ＣＵは、ユーザプレーン（Ｕｓｅｒ ｐｌａｎｅ、略してＵＰ）（本出願では略してＣＵ－ＵＰと呼ばれる）、およびコントロールプレーン（Ｃｏｎｔｒｏｌ ｐｌａｎｅ、略してＣＰ）（本出願では略してＣＵ－ＣＰと呼ばれる）を含む。

【0101】

シングルエアインターフェースシナリオでは、端末は、ＤＵを介してＣＵにアクセスすることがある。ＵＥのピアＲＬＣ層、ＭＡＣ層、およびＰＨＹ層の機能はＤＵによって実装され、対応するＵＥのＰＤＣＰ層、ＳＤＡＰ層、およびＰＤＣＰ層の機能はＣＵによって実装される。

【0102】

図４は、本出願の実施形態によるＣＵ－ＤＵ分割アーキテクチャでのコントロールプレーンプロトコルスタックの概略図である。図５は、本出願の実施形態によるＣＵ－ＤＵ分割アーキテクチャでのユーザプレーンプロトコルスタックの概略図である。以下では、図４および図５を参照して説明をする。

【0103】

コントロールプレーンについては、図４に示されるように、ＵＥおよびＣＵは、それぞれがピアＲＲＣ層およびＰＤＣＰ層を確立する。ＵＥは、インターフェース（たとえば、Ｕｕインターフェース）を介してＤＵに接続され、ＵＥおよびＤＵは、それぞれがピアＲＬＣ層、ＭＡＣ層、およびＰＨＹ層を確立する。ＤＵは、コントロールプレーンインターフェース（たとえば、Ｆ１－コントロールプレーン（Ｆ１－ｃｏｎｔｒｏｌ ｐｌａｎｅ、Ｆ１－Ｃ）インターフェース）を介してＣＵに接続され、ＤＵおよびＣＵは、それぞれがピアＦ１アプリケーションプロトコル（Ｆ１ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌ、Ｆ１ＡＰ）層、ストリームコントロール伝送プロトコル（ｓｔｒｅａｍ ｃｏｎｔｒｏｌ ｔｒａｎｓｍｉｓｓｉｏｎ ｐｒｏｔｏｃｏｌ、ＳＣＴＰ）層、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ、ＩＰ）層、層（ｌａｙｅｒ、Ｌ）２、および層（ｌａｙｅｒ、Ｌ）１を確立する。

【0104】

ユーザプレーンについては、図５に示されるように、ＵＥおよびＣＵは、それぞれがピアＳＤＡＰ層およびＰＤＣＰ層を確立する。ＵＥは、Ｕｕインターフェースを介してＤＵに接続され、ＵＥおよびＤＵは、それぞれがピアＲＬＣ層、ＭＡＣ層、およびＰＨＹ層を確立する。ＤＵは、Ｆ１－ユーザプレーン（Ｆ１－ｕｓｅｒ ｐｌａｎｅ、Ｆ１－Ｕ）インターフェースを介してＣＵに接続され、ＤＵおよびＣＵは、それぞれがピア汎用パケット無線サービス（ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅ、ＧＰＲＳ）トンネルプロトコル－ユーザプレーン（ＧＰＲＳ ｔｕｎｎｅｌｉｎｇ ｐｒｏｔｏｃｏｌ－ｕｓｅｒ ｐｌａｎｅ、ＧＴＰ－Ｕ）層、ユーザデータグラムプロトコル（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ、ＵＤＰ）層、ＩＰ層、Ｌ２、およびＬ１を確立する。

【0105】

図６は、本出願の実施形態による、ＩＡＢネットワークにおけるコントロールプレーンプロトコルスタックの概略図である。図７は、本出願の実施形態による、ＩＡＢネットワークにおけるユーザプレーンプロトコルスタックの概略図である。以下では、図６および図７を参照して説明をする。

【0106】

ＩＡＢネットワークにおいて、端末のピアＰＨＹ層、ＭＡＣ層およびＲＬＣ層はアクセスＩＡＢノードに置かれ、ＵＥのピアＰＤＣＰ層、ＳＤＡＰ層およびＲＲＣ層はＩＡＢドナーＣＵに置かれる。ＩＡＢドナーＣＵがＣＰおよびＵＰを含む場合、コントロールプレーンについては、ＵＥのピアＰＤＣＰ層およびＲＲＣ層はＩＡＢドナーＣＵのＣＰに置かれ（すなわち、ドナー－ＣＵ－ＣＰ）、ユーザプレーンについては、ＵＥのピアＰＤＣＰ層およびＳＤＡＰ層はＩＡＢドナーＣＵのＵＰに置かれる（すなわち、ドナー－ＣＵ－ＵＰ）。

【0107】

コントロールプレーンについては、図６に示されるように、Ｕｕインターフェースが端末１とＩＡＢノード２のＤＵの間に確立され、ピアプロトコル層はＲＬＣ層、ＭＡＣ層、およびＰＨＹ層を含む。Ｆ１－ＣインターフェースはＩＡＢノード２のＤＵとＩＡＢドナーＣＵ １の間に確立され、ピアプロトコル層はＦ１ＡＰ層およびＳＣＴＰ層を含む。ＩＡＢドナー内のＦ１インターフェースは、ＩＡＢドナーＤＵ １とＩＡＢドナーＣＵ １の間に確立され、ピアプロトコル層はＩＰ層、Ｌ２、およびＬ１を含む。ＢＬは、ＩＡＢノード２とＩＡＢノード３の間、ＩＡＢノード３とＩＡＢノード１の間、およびＩＡＢノード１とＩＡＢドナーＤＵ １の間に確立され、ピアプロトコル層は、バックホール適応プロトコル（Ｂａｃｋｈａｕｌ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＢＡＰ）層、ＲＬＣ層、ＭＡＣ層、およびＰＨＹ層を含む。加えて、端末１およびＩＡＢドナーＣＵ １は、それぞれがピアＲＲＣ層およびＰＤＣＰ層を確立し、ＩＡＢノード２のＤＵ、およびＩＡＢドナーＤＵ １は、それぞれがピアＩＰ層を確立する。

【0108】

シングルエアインターフェースのコントロールプレーンプロトコルスタックと比較して、ＩＡＢネットワーク内のコントロールプレーンプロトコルスタックでは、アクセスＩＡＢノードのＤＵがシングルエアインターフェースのｇＮＢ－ＤＵの機能（すなわち、ピアＲＬＣ層、ＭＡＣ層およびＰＨＹ層を端末で確立し、ピアＦ１ＡＰ層およびＳＣＴＰ層をＣＵで確立する機能）を実装すると知られることが可能である。ＩＡＢネットワーク内のアクセスＩＡＢノードのＤＵは、シングルエアインターフェースのｇＮＢ－ＤＵの機能を実装し、ＩＡＢドナーＣＵは、シングルエアインターフェースのｇＮＢ－ＣＵの機能を実装すると理解されてよい。

【0109】

コントロールプレーンでは、ＵＥのＲＲＣメッセージは、送信のためにアクセスＩＡＢノードとＩＡＢドナーＣＵの間でＦ１ＡＰメッセージ内にカプセル化される。

【0110】

ユーザプレーンについては、図７に示されるように、Ｕｕインターフェースが端末１とＩＡＢノード２のＤＵの間に確立され、ピアプロトコル層はＲＬＣ層、ＭＡＣ層、およびＰＨＹ層を含む。Ｆ１－ＵインターフェースがＩＡＢノード２のＤＵとＩＡＢドナーＣＵ １の間に確立され、ピアプロトコル層はＧＴＰ－Ｕ層およびＵＤＰ層を含む。ＩＡＢドナー内のＦ１インターフェースは、ＩＡＢドナーＤＵ １とＩＡＢドナーＣＵ １の間に確立され、ピアプロトコル層はＩＰ層、Ｌ２、およびＬ１を含む。ＢＬが、ＩＡＢノード２とＩＡＢノード３の間、ＩＡＢノード３とＩＡＢノード１の間、およびＩＡＢノード１とＩＡＢドナーＤＵ １の間に確立され、ピアプロトコル層はＢＡＰ層、ＲＬＣ層、ＭＡＣ層、およびＰＨＹ層を含む。加えて、端末１およびＩＡＢドナーＣＵ １は、それぞれがピアＳＤＡＰ層およびＰＤＣＰ層を確立し、ＩＡＢノード２のＤＵ、およびＩＡＢドナーＤＵ １は、それぞれがピアＩＰ層を確立する。

【0111】

シングルエアインターフェースのユーザプレーンプロトコルスタックと比較して、ＩＡＢネットワーク内のユーザプレーンプロトコルスタックでは、アクセスＩＡＢノードのＤＵがシングルエアインターフェースのｇＮＢ－ＤＵの機能（すなわち、ピアＲＬＣ層、ＭＡＣ層およびＰＨＹ層を端末で確立し、ピアＧＴＰ－Ｕ層およびＵＤＰ層をＩＡＢドナーＣＵ １で確立する機能）を実装すると知られることが可能である。アクセスＩＡＢノードのＤＵは、シングルエアインターフェースのｇＮＢ－ＤＵの機能を実装し、ＩＡＢドナーＣＵは、シングルエアインターフェースのｇＮＢ－ＣＵの機能を実装すると理解されてよい。

【0112】

ユーザプレーンでは、ＵＥのＰＤＣＰデータパケットは、送信のためにアクセスＩＡＢノードとＩＡＢドナーＣＵの間でＧＴＰ－Ｕトンネル内にカプセル化される。ＧＴＰ－Ｕトンネルは、Ｆ１－Ｕインターフェースで確立される。

【0113】

図７で、ＰＤＣＰエンティティ、ＲＬＣエンティティ、および端末のＧＴＰ－Ｕトンネルは、ベアラ粒度で確立され得る。言い換えると、ベアラ、ＰＤＣＰエンティティ、ＲＬＣエンティティ、およびＧＴＰ－Ｕトンネルは、１対１の対応関係にあり得る。

【0114】

論理チャネルが、端末とアクセスＩＡＢノードのＤＵの間に確立される。論理チャネルは、ＲＬＣエンティティとＲＬＣエンティティの下位層エンティティとの間の伝送チャネル、すなわち、ＲＬＣエンティティとＭＡＣエンティティの間の伝送チャネルである。１つのＲＬＣエンティティは、１つの論理チャネルに対応する。ＲＬＣチャネル（ｃｈａｎｎｅｌ）は、アクセスＩＡＢノードのＭＴと中間ＩＡＢノードのＤＵ（たとえば、ＩＡＢノード２のＭＴとＩＡＢノード３のＤＵ）との間、中間ＩＡＢノードのＭＴと中間ＩＡＢノードのＤＵ（たとえば、ＩＡＢノード３のＭＴとＩＡＢノード１のＤＵ）との間、および、中間ＩＡＢノードのＤＵとＩＡＢドナーＤＵ（たとえば、ＩＡＢノード１のＭＴとＩＡＢドナーＤＵ １）との間で確立される。ＲＬＣチャネルは、ＲＬＣエンティティとＲＬＣエンティティの上位層エンティティとの間の伝送チャネルである。たとえば、ＲＬＣエンティティの上位層エンティティが、アダプテーション（バックホールアダプテーションプロトコル（Ｂａｃｋｈａｕｌ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＢＡＰ）とも呼ばれる）層エンティティである場合には、バックホールリンク上のＲＬＣチャネルは、ＲＬＣエンティティとＢＡＰエンティティの間のチャネルである。１つのＲＬＣエンティティが１つのＲＬＣチャネルに対応する。したがって、図７で、ベアラ、ＰＤＣＰエンティティ、ＲＬＣエンティティ、ＧＴＰ－Ｕトンネル、および論理チャネルは、１対１の対応関係にある。

【0115】

図６および図７はそれぞれ、図２に示されたＩＡＢシナリオのプロトコルスタックだけを例として用いて説明されている。１つのＩＡＢノードが１つまたは複数の役割を果たし得ることに留意されたい。ＩＡＢノードは、１つまたは複数の役割のうちの１つまたは複数のプロトコルスタックを有し得る。代替として、ＩＡＢノードは１つのプロトコルスタックを有してよく、ＩＡＢノードの別々の役割に対して、プロトコルスタックにおける別々の役割に対応するプロトコル層が処理に使用されてよい。以下では、ＩＡＢノードが１つまたは複数の役割のうちの１つまたは複数のプロトコルスタックを有する例を用いて説明をする。

【0116】

（１）端末のプロトコルスタック

【0117】

ＩＡＢネットワークにアクセスするとき、ＩＡＢノードが端末の役割を果たし得る。この場合、ＩＡＢノードのＭＴは、端末のプロトコルスタックを有し、たとえば、図６および図７の端末１のプロトコルスタック、すなわち、ＲＲＣ層、ＰＤＣＰ層、ＲＬＣ層、ＭＡＣ層、およびＰＨＹ層を有する。コントロールプレーンでは、ＩＡＢノードのＲＲＣメッセージは、送信のためにＩＡＢノードの親ノードとＩＡＢドナーＣＵの間でＦ１ＡＰメッセージ内にカプセル化される。ユーザプレーンでは、ＩＡＢノードのＰＤＣＰデータパケットは、送信のためにＩＡＢノードの親ノードとＩＡＢドナーＣＵの間でＧＴＰ－Ｕトンネル内にカプセル化される。

【0118】

加えて、ＩＡＢノードがＩＡＢネットワークにアクセスした後に、ＩＡＢノードはなお端末の役割を果たして、たとえば、ＩＡＢノードのアップリンクおよび／またはダウンリンクデータパケット（たとえば、ＯＡＭデータパケット）をＩＡＢドナーで送信し、ＲＲＣ層を介して測定を実施することもある。

【0119】

（２）アクセスＩＡＢノードのプロトコルスタック

【0120】

ＩＡＢノードがＩＡＢネットワークにアクセスした後に、ＩＡＢノードは、アクセスサービスを端末に提供してアクセスＩＡＢノードの役割を果たし得る。この場合、ＩＡＢノードは、アクセスＩＡＢノードのプロトコルスタック、たとえば、図６および図７のＩＡＢノード２のプロトコルスタックを有する。

【0121】

（３）中間ＩＡＢノードのプロトコルスタック

【0122】

ＩＡＢノードがＩＡＢネットワークにアクセスした後に、ＩＡＢノードは、中間ＩＡＢノードの役割を果たし得る。この場合、ＩＡＢノードは、中間ＩＡＢノードのプロトコルスタック、たとえば、図６および図７のＩＡＢノード３またはＩＡＢノード１のプロトコルスタックを有する。

【0123】

ＩＡＢノードは、１つまたは複数の役割のうちの１つまたは複数のプロトコルスタックを有し得る。たとえば、ＩＡＢネットワークにアクセスした後に、ＩＡＢノードは端末の役割、およびアクセスＩＡＢノードの役割を果たし得る。この場合、２つのプロトコルスタックが、ＩＡＢノードとＩＡＢノードの親ノードとの間のインターフェースにあり得る。一方は端末のプロトコルスタックであり、他方は、バックホールサービスを端末に提供するノードのプロトコルスタック（すなわち、アクセスＩＡＢノードのプロトコルスタック）である。別の例では、ＩＡＢネットワークにアクセスした後に、ＩＡＢノードは、端末の役割、および中間ＩＡＢノードの役割を果たし得る。この場合、２つのプロトコルスタックが、ＩＡＢノードとＩＡＢノードの親ノードとの間のインターフェース上にあり得る。一方は端末のプロトコルスタックであり、他方は中間ＩＡＢノードのプロトコルスタックである。さらに別の例として、ＩＡＢネットワークにアクセスした後に、ＩＡＢノードは、端末の役割、アクセスＩＡＢノードの役割、および中間ＩＡＢノードの役割を果たすことができる（たとえば、ＩＡＢノードは、いくつかの端末のためのアクセスＩＡＢノードであってよくまた、いくつかの他の端末のための中間ＩＡＢノードであり、加えて、ＩＡＢノードは、ＩＡＢノードの運用、管理および保守（ｏｐｅｒａｔｉｏｎ、ａｄｍｉｎｉｓｔｒａｔｉｏｎ ａｎｄ ｍａｉｎｔｅｎａｎｃｅ、ＯＡＭ）データパケットをＩＡＢドナーで伝送する必要がある）。この場合、ＩＡＢノードは３つのプロトコルスタックを有し得る。１つは端末のプロトコルスタックであり、１つはアクセスＩＡＢノードのプロトコルスタックであり、もう１つは中間ＩＡＢノードのプロトコルスタックである。

【0124】

図６および図７はそれぞれ、ＩＡＢネットワークを例として用いて説明されていることに留意されたい。図６および図７の内容はまた、ＩＡＢネットワーク以外のリレーネットワークにも当てはまる。リレーネットワークのコントロールプレーンプロトコルスタックのアーキテクチャについては、図６を参照されたい。リレーネットワークのユーザプレーンプロトコルスタックのアーキテクチャについては、図７を参照されたい。

【0125】

シングルエアインターフェースシナリオでは、端末ハンドオーバが発生することがある。端末がソース基地局からターゲット基地局にハンドオーバされるとき、端末はまずソース基地局から切断され、端末のサービス伝送が中断される。端末がターゲット基地局にアクセスした後に、端末のサービス伝送が再開される。端末のサービス伝送中断の問題をシングルエアインターフェースの場合において低減させるために、デュアルアクティブプロトコルスタック（ｄｕａｌ ａｃｔｉｖｅ ｐｒｏｔｏｃｏｌ ｓｔａｃｋ、ＤＡＰＳ）ソリューションが導入される。

【0126】

以下ではまず、シングルエアインターフェースの場合のＤＡＰＳソリューションについて図８から図９Ｂを参照して説明する。

【0127】

図８は、本出願の実施形態によるＤＡＰＳの概略図である。図８に示されるように、ソース基地局は、端末のダウンリンクデータをコアネットワークから受信する。端末ハンドオーバ中、ソース基地局は、受信されたダウンリンクデータの一部分を端末へ送信し、受信されたダウンリンクデータの他の部分をターゲット基地局へ転送してよく（データのこの部分は転送データと呼ばれることがある）、それにより、端末がターゲット基地局にアクセスした後に、ターゲット基地局はデータのその部分を端末へ送信する。ソース基地局およびターゲット基地局は、それぞれのユーザプレーンプロトコルスタックを有する。端末は、２つのプロトコルスタックを有する。一方のプロトコルスタックは、ソース基地局に対応し、対応するＰＨＹエンティティ、ＭＡＣエンティティおよびＲＬＣエンティティを含む。他方のプロトコルスタックはターゲット基地局に対応し、対応するＰＨＹ層、ＭＡＣエンティティおよびＲＬＣエンティティを含む。端末は２つのプロトコルスタックを有するが、端末の転送データに対して、１つのＰＤＣＰエンティティは２つのＲＬＣエンティティと関連付けられており、一方のＲＬＣエンティティはソース基地局に対応し、他方のＲＬＣエンティティはターゲット基地局に対応する。ＰＤＣＰエンティティは、ベアラ粒度で構成され、このことは、端末の１つのベアラが１つのＰＤＣＰエンティティに対応すると理解されてよい。ただし、ＰＤＣＰエンティティにおいては、ヘッダ圧縮（ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎ）、ヘッダ伸張（ｈｅａｄｅｒ ｄｅｃｏｍｐｒｅｓｓｉｏｎ）、セキュリティ処理（ｓｅｃｕｒｉｔｙ ｐｒｏｃｅｓｓｉｎｇ）、ヘッダ追加（ａｄｄ ｈｅａｄｅｒ）、ヘッダ削除（ｒｅｍｏｖｅ ｈｅａｄｅｒ）などの機能が、ソース基地局およびターゲット基地局では互いに独立しており、並べ替え機能は、ソース基地局とターゲット基地局で共通である。並び替えに必要なＰＤＣＰシーケンス番号（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ、ＳＮ）は、ソース基地局によって一様に割り当てられてよい。

【0128】

図９Ａおよび図９Ｂは、本出願の実施形態による、シングルエアインターフェースの場合におけるＤＡＰＳベースのハンドオーバの概略フローチャートである。図９Ａおよび図９Ｂに示されるように、この方法は以下のステップを含む。

【0129】

Ｓ９０１：ソース基地局がハンドオーバ判定を実施する。

【0130】

Ｓ９０１の前に、端末が、図８に示されるソース基地局に対応するプロトコルスタックを確立し、ソース基地局に対応するプロトコルスタックに基づいて、ソース基地局とのアップリンクデータ伝送およびダウンリンクデータ伝送を実施する。

【0131】

Ｓ９０２：ソース基地局は、ハンドオーバ要求メッセージをターゲット基地局へ送信する。

【0132】

ハンドオーバ要求メッセージは端末のコンテキスト情報を含むので、ターゲット基地局は、ターゲット基地局のエアインターフェースリソースの設定情報を端末に対して生成する。

【0133】

Ｓ９０３：ターゲット基地局は、ハンドオーバ要求確認メッセージをソース基地局へ送信する。

【0134】

ハンドオーバ要求確認メッセージは、ターゲット基地局によって生成されたハンドオーバコマンドメッセージを含む。ハンドオーバコマンドメッセージは、ターゲット基地局によって端末に対して生成されたエアインターフェースリソースの設定情報を含む。エアインターフェースリソースの設定情報は、ターゲット基地局によって転送データに割り当てられたエアインターフェースリソースの設定情報を含む。端末の転送データは、ソース基地局によってコアネットワークから受信されターゲット基地局へ転送される端末データを含む。ターゲット基地局は、転送されたデータを端末へ送信する。ターゲット基地局によって転送データに割り当てられたエアインターフェースリソースの設定情報は、ＰＤＣＰ層、ＲＬＣ層、ＭＡＣ層、およびＰＨＹ層のうちの１つまたは複数の設定情報を含む。ＰＤＣＰ層の設定情報は、セキュリティ設定情報および／またはロバストヘッダ圧縮（ｒｏｂｕｓｔ ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎ、ＲＯＨＣ）プロファイル（ｐｒｏｆｉｌｅ）を含み得る。セキュリティ設定情報は、セキュリティアルゴリズム（たとえば、暗号化アルゴリズムおよび／または完全性保護アルゴリズム）および／または鍵関連パラメータを含み得る。

【0135】

Ｓ９０４：ソース基地局は端末へ、ターゲット基地局によって生成されたハンドオーバコマンドメッセージを送信する。

【0136】

ハンドオーバコマンドメッセージは、ターゲット基地局によって端末に対して生成されたエアインターフェースリソースの設定情報を含む。端末は、設定情報に基づいて、図８に示されたターゲット基地局に対応するプロトコルスタックを確立することがある。この場合、端末は、図８に示されている、ソース基地局に対応するプロトコルスタックと、ターゲット基地局に対応するプロトコルスタックとを確立する。

【0137】

任意選択で、ハンドオーバコマンドメッセージは、１つのインジケーション情報を追加で搬送してもよく、このインジケーション情報は、端末の１つのサービスベアラに対応することがあり、ＤＡＰＳハンドオーバが端末のサービスベアラに対して構成されるべきことを示す。サービスベアラは、データ無線ベアラ（ｄａｔａ ｒａｄｉｏ ｂｅａｒｅｒ、ＤＲＢ）であってよい。

【0138】

Ｓ９０５：端末はＤＡＰＳを開始する。

【0139】

端末が、ハンドオーバコマンドメッセージで搬送されたインジケーション情報に基づいて、インジケーション情報に対応するサービスベアラ上でＤＡＰＳ動作を開始した後、端末がこの瞬間にはターゲット基地局に成功裏にアクセスしていないので、端末は、ソース基地局に対応するプロトコルスタックを引き続き用いて、サービスベアラでのソース基地局とのアップリンクデータ伝送およびダウンリンクデータ伝送を実施するとともに、ターゲット基地局にアクセスすることを同時に試みることがある。

【0140】

Ｓ９０６およびＳ９０７では、ソース基地局がシーケンス番号（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ、ＳＮ）ステータスおよびデータを転送する処理について説明する。ソース基地局はターゲット基地局へ、端末についての、コアネットワークから受信されたダウンリンクデータの一部分を転送することがあり、ターゲット基地局は、そのダウンリンクデータの一部分を端末へ送信する。ソース基地局は、データの他の部分を端末へ継続して送信する。

【0141】

Ｓ９０６：ソース基地局は、ＳＮステータスをターゲット基地局へ転送する。

【0142】

Ｓ９０７：ソース基地局は、データをターゲット基地局へ転送する。

【0143】

ソース基地局によってターゲット基地局へ転送される端末データは、ＰＤＣＰサービスデータユニット（ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ、ＳＤＵ）である。ソース基地局は、ＰＤＣＰ ＳＮをＰＤＣＰ ＳＤＵに一様に割り当て、ターゲット基地局へ、ＰＤＣＰ ＳＤＵと、ＰＤＣＰ ＳＤＵに対応するＰＤＣＰ ＳＮとを転送し、それにより、端末がターゲット基地局に成功裏にアクセスした後に、ターゲット基地局は、受け取ったＰＤＣＰ ＳＮとＰＤＣＰ層の設定情報とに基づいてＰＤＣＰ ＳＤＵを処理し、次に、処理されたＰＤＣＰ ＳＤＵを端末へ送信する。

【0144】

Ｓ９０８：端末は、プリアンブル（ｐｒｅａｍｂｌｅ）をターゲット基地局へ送信する。

【0145】

Ｓ９０９：ターゲット基地局は、ランダムアクセス応答（ｒａｎｄｏｍ ａｃｃｅｓｓ ｒｅｓｐｏｎｓｅ、ＲＡＲ）を端末へ送信する。

【0146】

Ｓ９１０：端末は、物理アップリンク共有チャネル（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ、ＰＵＳＣＨ）切り換え（ｓｗｉｔｃｈ）を実施する。

【0147】

ＰＵＳＣＨ切り換えの前に、端末は、ターゲット基地局によって割り当てられたアップリンク（ｕｐｌｉｎｋ、ＵＬ）グラント（ｇｒａｎｔ）を受信する。たとえば、非コンテンションベースのランダムアクセスでは、ＵＬグラントはＳ９０９のＲＡＲで搬送され、コンテンションベースのランダムアクセスでは、ＵＬグラントはダウンリンクコントロール情報（ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ、ＤＣＩ）で搬送され、端末へ送信されてよい。ＵＬグラントを受信した後に、端末は、ＰＵＳＣＨ切り換え動作を実施し、すなわち、ソース基地局とのアップリンクデータ伝送を停止し、ターゲット基地局とのアップリンクデータ伝送を開始する。言い換えると、端末のＰＵＳＣＨがソース基地局からターゲット基地局へ切り換えられる。端末のＰＵＳＣＨがターゲット基地局へ切り換えられ、端末は、ソース基地局とのアップリンクデータ伝送を実施できないものの、端末は、ソース基地局とのダウンリンクデータ伝送は依然として実施できることに留意されたい。

【0148】

Ｓ９０４からＳ９１０では、端末およびソース基地局がダウンリンクデータ伝送およびアップリンクデータ伝送を実施できることが、前述の説明から知られることが可能である。

【0149】

Ｓ９１１：端末は、ＲＲＣ再設定完了メッセージをターゲット基地局へ送信する。

【0150】

端末のＰＵＳＣＨがターゲット基地局へ切り換えられた後に、端末は、ＲＲＣ再設定完了メッセージをターゲット基地局へ、ＵＬグラントによって示されたリソース上で送信してよく、このことは端末がターゲット基地局に成功裏にアクセスしたことを意味し、端末は、ターゲット基地局とのダウンリンクデータ伝送を実施することができる。

【0151】

Ｓ９１２：ターゲット基地局は、ハンドオーバ成功メッセージをソース基地局へ送信して、ダウンリンクデータを端末へ送信することを停止するようにソース基地局に示す。

【0152】

前述の説明から、Ｓ９１１からＳ９１２では、端末とソース基地局がダウンリンクデータ送信を実施することができ、端末とターゲット基地局がダウンリンクデータ送信を実施することができ、また、端末とターゲット基地局がアップリンクデータ送信を実施してよい、と知られることが可能である。

【0153】

具体的には、端末は、ソース基地局によって構成されるＲＯＨＣプロファイル、セキュリティアルゴリズムおよび鍵に基づいて、ソース基地局から受信されたダウンリンクデータを処理し、また、端末は、ターゲット基地局によって構成されるＲＯＨＣプロファイル、セキュリティアルゴリズム、および鍵に基づいて、ターゲット基地局から受信されたダウンリンクデータを処理する。次に、端末は、処理されたパケットを並び替えのためにＰＤＣＰ層のパブリックバッファ（ｂｕｆｆｅｒ）へ送信し、処理されたパケットを上位層へ順次提出する。

【0154】

Ｓ９１３：ソース基地局は、ダウンリンク（ｄｏｗｎｌｉｎｋ、ＤＬ）データをＵＥへ送信することを停止する。

【0155】

ターゲット基地局によって送信されたハンドオーバ成功メッセージを受信した後に、ソース基地局は、端末へのダウンリンクデータの送信を停止し、ソース基地局に残っている端末のダウンリンクデータをターゲット基地局へ、以下のＳ９１４およびＳ９１５によって送信し、ターゲット基地局は、そのダウンリンクデータを端末へ送信する。

【0156】

Ｓ９１４：ソース基地局は、ＳＮステータスをターゲット基地局へ転送する。

【0157】

Ｓ９１５：ソース基地局は、データをターゲット基地局へ転送する。

【0158】

Ｓ９１６：ターゲット基地局は、ＲＲＣメッセージ（ｍｅｓｓａｇｅ）を端末へ送信して、ソース基地局に対応するエアインターフェースリソースを解放するように端末に示す。

【0159】

Ｓ９１７：端末は、ＤＡＰＳからシングルアクティブプロトコルスタックへ切り換わる。

【0160】

端末がシングルアクティブプロトコルスタックに切り換わった後に、端末は、ソース基地局との伝送を、物理アップリンクコントロールチャネル（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ、ＰＵＣＣＨ）伝送などを含めて完全に停止する。

【0161】

前述の説明から、Ｓ９１３からＳ９１７では、端末とターゲット基地局がダウンリンクデータ伝送およびアップリンクデータ伝送を実施すると知られることが可能である。

【0162】

図９Ａおよび図９Ｂのソリューションでは、端末はＤＡＰＳを開始し、それにより、端末は、シングルエアインターフェースの場合での基地局間ハンドオーバ中のソース基地局との接続を維持して、端末のアップリンクデータ伝送およびダウンリンクデータ伝送が中断されないことを確実にし、ユーザ体験を改善することができる。

【0163】

リレーネットワークにおいて、リレーノードハンドオーバが発生することがある。図１０は、本出願の実施形態によるリレーノードハンドオーバの概略図である。図１０に示されるように、リレーノードをソースドナーノードからターゲットドナーノードへハンドオーバすることは、そのソースドナーノードが、リレーノードハンドオーバ中のソースドナーノードであり、そのターゲットドナーノードが、リレーノードハンドオーバ中のターゲットドナーノードであることと理解されてよい。

【0164】

任意選択で、リレーノードハンドオーバは、リレーノードが、リレーノードとリレーノードの子孫ノードとをグループ（ｇｒｏｕｐ）として使用し、そのグループが、ソースドナーノードからターゲットドナーノードへとハンドオーバされるものと理解されてよい。本出願のこの実施形態では、親ノードが変化するノードはリレーノードと呼ばれ、このノードではハンドオーバが発生するかハンドオーバが実施される。

【0165】

任意選択で、ハンドオーバが発生するリレーノードは、ハンドオーバリレーノードまたは移行リレーノードと呼ばれることがある。

【0166】

任意選択で、移行リレーノードは端末の親ノードであってもよい。言い換えると、移行リレーノードは端末に直接接続され、すなわち、移行リレーノードはアクセスリレーノードである（本出願のこの実施形態では、端末によってアクセスされるリレーノードはアクセスリレーノードと呼ばれる）。または、移行リレーノードは端末に、１つまたは複数の他のリレーノードを介して接続されることがあり、すなわち、移行リレーノードは中間リレーノードである（本出願のこの実施形態では、端末にバックホールサービスを提供するリレーノードは中間リレーノードと呼ばれる）。

【0167】

任意選択で、ソースドナーノードがリレーノードハンドオーバ中のソースドナーノードであることは、リレーノードハンドオーバ前のドナーノードがソースドナーノードである、またはハンドオーバ前にリレーノードがソースドナーノードに接続されていることと理解されてよい。リレーノードをソースドナーノードに接続する手法は、本出願では限定されていない。たとえば、ソースドナーノードはリレーノードの親ノードであってよく、またはソースドナーノードは、リレーノードに１つまたは複数の他のリレーノードを介して接続されてよい。

【0168】

任意選択で、ターゲットドナーノードがリレーノードハンドオーバ中のターゲットドナーノードであることは、リレーノードハンドオーバの後のドナーノードがターゲットドナーノードになることと理解されてよいが、リレーノードハンドオーバは最終的に成功することも失敗することもある。このことは、本出願のこの実施形態では限定されていない。リレーノードをターゲットドナーノードに接続する手法は、本出願では限定されていない。たとえば、ターゲットドナーノードはリレーノードの親ノードであってよく、またはターゲットドナーノードは、リレーノードに１つまたは複数の他のリレーノードを介して接続されてよい。

【0169】

任意選択で、リレーノードハンドオーバ中のソース親ノードはソース親ノードと呼ばれることがあり、リレーノードハンドオーバ中のターゲット親ノードは、ターゲット親ノードと呼ばれることがある。リレーノードハンドオーバの前に、リレーノードはソース親ノードに接続され、ソース親ノードはアクセスサービスをリレーノードに提供すると理解されてよい。リレーノードハンドオーバの後に、リレーノードはターゲット親ノードに接続され、このターゲット親ノードはアクセスサービスをリレーノードに提供する。

【0170】

任意選択で、ソース親ノードはソースドナーノードであってよく、またはソース親ノードは、ソースドナーノードにｍ個の他のリレーノードを介して接続され、ここで、ｍは１以上の整数である。ターゲット親ノードはターゲットドナーノードであってよく、またはターゲット親ノードは、ターゲットドナーノードにｎ個の他のリレーノードを介して接続され、ここで、ｎは１以上の整数である。任意選択で、ドナーノードはＣＵおよび／またはＤＵを含み得る。

【0171】

任意選択で、ソースドナーノードはソースＣＵを含み得る。任意選択で、ソースドナーノードはソースＤＵをさらに含み得る。ターゲットドナーノードはターゲットＣＵを含み得る。任意選択で、ターゲットドナーノードはターゲットＤＵをさらに含み得る。ソースＣＵはターゲットＣＵと異なっており、ソースＤＵはターゲットＤＵと異なっている。

【0172】

ソースドナーノードからターゲットドナーノードへのリレーノードのハンドオーバは、ドナー－ノード間ハンドオーバまたはＣＵ間ハンドオーバと呼ばれることがある。

【0173】

ＩＡＢシナリオを参照して、以下では、リレーノードがＩＡＢノードであり、ソースドナーノードがソースＩＡＢドナーＣＵを含み、ターゲットドナーノードがターゲットＩＡＢドナーＣＵを含む例を用いて、ドナー－ノード間ハンドオーバについてさらに説明する。

【0174】

図１１は、本出願の実施形態によるドナー－ＣＵ間ハンドオーバの概略図である。ドナー－ＣＵ間ハンドオーバが図２のＩＡＢノード３に発生する例が用いられる。図１１に示されるように、ハンドオーバ前は、ＩＡＢノード３の親ノード（すなわち、ＩＡＢノード３のソース親ノード）がＩＡＢノード１であり、ソースＩＡＢドナーＤＵがＩＡＢドナーＤＵ １であり、ソースＩＡＢドナーＣＵがＩＡＢドナーＣＵ １である。ハンドオーバ後は、ＩＡＢノード３の親ノード（すなわち、ＩＡＢノード３のターゲット親ノード）がＩＡＢノード４であり、ターゲットＩＡＢドナーＤＵがＩＡＢドナーＤＵ ２であり、ターゲットＩＡＢドナーＣＵがＩＡＢドナーＣＵ ２である。

【0175】

ＩＡＢノード３のハンドオーバは、ＩＡＢノード３のＭＴのハンドオーバと考えられてよい。ソースドナーノードがＩＡＢドナーＣＵ １を含むことがあり、またはソースドナーノードがＩＡＢドナーＣＵ １およびＩＡＢドナーＤＵ １を含むことがある。ターゲットドナーノードがＩＡＢドナーＣＵ ２を含むことがあり、またはターゲットドナーノードがＩＡＢドナーＣＵ ２およびＩＡＢドナーＤＵ ２を含むことがある。

【0176】

図１１は、ドナーノード間ハンドオーバが中間ＩＡＢノードに発生する例だけを用いて説明されているが、ドナーノード間ハンドオーバはまた、アクセスＩＡＢノード（たとえば、ＩＡＢノード２）にも発生し得ることに留意されたい。

【0177】

リレーノードシナリオでは、ドナーノード間ハンドオーバ中に、ハンドオーバを実施するリレーノードに接続されているドナーノードが変化し、このリレーノードは、ソースドナーノードからまず接続を断つ必要がある（すなわち、リレーノードは、そのソースドナーノードから端末のダウンリンクデータを受信できず、また、そのソースドナーノードへ端末のアップリンクデータを送信することができない）。その結果、リレーノードは端末にサービスすることを停止し、端末のデータ伝送が中断される。次に、端末は、リレーノードと端末の間のリンクにＲＬＦが発生したことを検出し、ＲＲＣ再確立手順をトリガしてデータ伝送を再開する。その過程で、端末のサービス伝送が中断されて、ユーザ体験が大きく低減される。

【0178】

したがって、シングルエアインターフェースの場合のＤＡＰＳソリューションがドナーノード間ハンドオーバのシナリオに適用されて、端末の役割を果たすリレーノードのアップリンクデータ伝送およびダウンリンクデータ伝送が中断されないことが確実になり得る。具体的には、リレーノードは、図８に示されたＤＡＰＳの機能をハンドオーバ中に有する。リレーノードは、２つのプロトコルスタックを有する。１つのプロトコルスタックでは、リレーノードのＰＨＹ層、ＭＡＣ層およびＲＬＣ層が、リレーノードのソース親ノードに対応する。別のプロトコルスタックでは、リレーノードのＰＨＹ層、ＭＡＣ層およびＲＬＣ層が、リレーノードのターゲット親ノードに対応する。リレーノードは、１つのＰＤＣＰエンティティを含み、このＰＤＣＰエンティティは、２つのＲＬＣエンティティと関連付けられている。一方のＲＬＣエンティティはソース親ノードに対応し、他方のＲＬＣエンティティはターゲット親ノードに対応する。

【0179】

たとえば、リレーノードは、図９Ａおよび図９Ｂの端末によって実施される動作を実施することがあり、ソースドナーノードは、図９Ａおよび図９Ｂのソース基地局によって実施される動作を実施することがあり、ターゲットドナーノードは、図９Ａおよび図９Ｂのターゲット基地局によって実施される動作を実施することがある。

【0180】

シングルエアインターフェースの場合のＤＡＰＳソリューションがドナーノード間ハンドオーバシナリオに適用された後に、リレーノードのデータ（これは、リレーノードで終了されるデータとして、たとえばＯＡＭデータとして理解されてよい）の送信がリレーノードハンドオーバ中に中断されないことが確実にされることが可能である。さらに、リレーノードは、ハンドオーバ中にバックホールサービスを端末に提供することもある（すなわち、アクセスリレーノードまたは中間リレーノードとして機能する）。ＤＡＰＳソリューションと同様に、リレーノードは、ソース親ノードのピアプロトコルスタックとターゲット親ノードのピアプロトコルスタックとの両方を有することがあり、それにより、ハンドオーバ中にリレーノードは、データ（アップリンクデータおよびダウンリンクデータを含む）を端末とソースドナーノードの間で伝送することがあり、またはデータ（アップリンクデータおよびダウンリンクデータを含む）を端末とターゲットドナーの間で伝送することがある。

【0181】

しかし、端末については、端末は常にリレーノードに接続されており、ハンドオーバが端末に発生せず、端末は、データがソースドナーノードからのものか、それともターゲットドナーノードからのものかを知ることができない。具体的には、ダウンリンクデータについては、端末は、リレーノードから受信されたダウンリンクデータがソースドナーノードからのものか、それともターゲットドナーノードからのものかを知ることができず、アップリンクデータについては、端末は、送信されるアップリンクデータがリレーノードによってソースドナーノードへ送信されるのか、それともターゲットドナーノードへ送信されるのかを知ることができない。説明を容易にするために、ソースドナーノードとの間で受信または送信されるデータは、簡潔にソースドナーノードのデータと呼ばれ、ターゲットドナーノードとの間で受信または送信されるデータは、簡潔にターゲットドナーノードのデータと呼ばれる。

【0182】

ソースドナーノードのデータを処理するために必要な設定情報は、ターゲットドナーノードのデータを処理するために必要な設定情報とは異なっている。言い換えると、ソースドナーノードのデータは、ソースドナーノードの設定情報に基づいて処理される必要があり、ターゲットドナーノードのデータは、ターゲットドナーノードの設定情報に基づいて処理される必要がある。端末は、データパケットを処理するためにソースドナーノードの設定情報またはターゲットドナーノードの設定情報が用いられる必要があるかどうかを知ることができないので、端末のサービスが中断される。

【0183】

たとえば、ダウンリンクデータについては、端末は、受信されたデータパケットがソースドナーノードからのものであるか、それともターゲットドナーノードからのものであるかを知ることができない。その結果、端末は受信されたデータパケットを、正しい設定情報を用いて解析することができない。端末がデータパケットを解析するのに失敗すると、パケットロスが引き起こされ、サービスが中断される。アップリンクデータについては、端末は、アップリンクデータパケットがソースドナーノードへ送信されるべきか、それともターゲットドナーノードへ送信されるべきかを知ることができない。その結果、端末はアップリンクデータを、正しい設定情報を用いて処理することができない。ドナーノードがアップリンクデータを解析するのに失敗すると、パケットロスが発生し、端末のサービスが中断される。

【0184】

加えて、ＤＡＰＳソリューションがドナー－ノード間ハンドオーバシナリオに適用されない場合でも、すなわち、ドナー－ノード間ハンドオーバ中にリレーノードがまずソースドナーノードからの接続を断つ（すなわち、端末のアップリンクデータおよび／またはダウンリンクデータをソースドナーノードで送信できない）場合でも、リレーノードは、ソースドナーノードから以前に受信されているが端末へは送信されていないダウンリンクデータをバッファリングすることがある。この場合、ハンドオーバ中にリレーノードは、ソースドナーノードから受信されている、以前にバッファリングされたダウンリンクデータを端末へさらに継続して送信し得る。リレーノードがターゲットドナーノードに成功裏にハンドオーバされた後に、リレーノードは、ダウンリンクデータをターゲットドナーノードから受信し、ターゲットドナーノードから受信されたそのダウンリンクデータを端末へ送信し得る。したがって、リレーノードのドナーノード間ハンドオーバの故に、端末は、２種類のダウンリンクデータ、すなわち、ソースドナーノードのダウンリンクデータとターゲットドナーノードのダウンリンクデータとを受信し得る。端末は、データを処理するためにソースドナーノードの設定情報またはターゲットドナーノードの設定情報が用いられる必要があるかどうかを知ることができない。その結果、端末のサービスは中断される。

【0185】

これに基づいて、本出願の実施形態は、ドナーノード間ハンドオーバシナリオにおける端末のサービス中断の確率を低減するとともにユーザ体験を改善するためのソリューションを提供する。このソリューションでは、端末のアクセスリレーノードは、端末の１つのベアラ（たとえば、１つのＤＲＢ）に対して２つの論理チャネル（ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ、ＬＣＨ）を構成し得る。一方のＬＣＨは、ソースドナーノードに対応するデータを送信するためのものであり、他方のＬＣＨは、ターゲットドナーノードに対応するデータを送信するためのものである。端末は、別々のＬＣＨに基づいて、ソースドナーノードに対応するデータとターゲットドナーノードに対応するデータとを区別して、端末が正しい設定情報を用いてデータを処理し、サービス中断の確率を低減させ、かつサービス伝送継続性を改善することを確実にし得る。

【0186】

具体的には、本出願のこの実施形態では、端末の１つのベアラに対して、ＧＴＰ－Ｕトンネル（以下では、ソースドナーノードに対応してＧＴＰ－Ｕトンネルと呼ばれる）がアクセスリレーノードとソースドナーノードの間にあり、別のＧＴＰ－Ｕトンネル（以下では、ターゲットドナーノードに対応してＧＴＰ－Ｕトンネルと呼ばれる）がアクセスリレーノードとターゲットドナーノードの間にある。端末の１つのベアラに対して、２つのＬＣＨが端末にある。端末の一方のＬＣＨは、ソースドナーノードに対応しているＧＴＰ－Ｕトンネルに対応し、端末の他方のＬＣＨは、ターゲットドナーノードに対応しているＧＴＰ－Ｕトンネルに対応する。

【0187】

以下では、本出願のこの実施形態における、ドナーノード間ハンドオーバ中のデュアルＬＣＨユーザプレーンプロトコルスタックについて説明する。

【0188】

図１２は、本出願の実施形態による、デュアルＬＣＨユーザプレーンプロトコルスタックの概略図である。

【0189】

端末は、ＰＨＹ層、ＭＡＣ層、ＲＬＣ層、およびＰＤＣＰ層を含む１つのプロトコルスタックを有する。端末のＲＬＣ層、ＭＡＣ層およびＰＨＹ層は、端末の親ノードのＲＬＣ層、ＭＡＣ層およびＰＨＹ層に対応し、端末のＰＤＣＰ層は、ソースドナーノード（すなわち、図１２のＩＡＢドナーＣＵ １）のＰＤＣＰ層と、ターゲットドナーノード（すなわち、図１２のＩＡＢドナーＣＵ ２）のＰＤＣＰ層とに対応する。

【0190】

任意選択で、ＰＤＣＰ層はＰＤＣＰエンティティを含み、ＲＬＣ層はＲＬＣエンティティを含み、ＭＡＣ層はＭＡＣエンティティを含み、ＰＨＹ層はＰＨＹエンティティを含む。端末のＭＡＣエンティティおよびＰＨＹエンティティは端末粒度で構成されており、端末は、１つのＭＡＣエンティティおよび１つのＰＨＹエンティティを有する。端末のＰＤＣＰエンティティは、ベアラ粒度で構成される。端末の１つのベアラに対して、端末は、対応する１つのＰＤＣＰエンティティを有し得る。

【0191】

具体的には、１つのベアラに対して、端末は１つのＰＤＣＰエンティティのみを有するが、ソースドナーノードに対応するＰＤＣＰ設定情報、およびターゲットドナーノードに対応するＰＤＣＰ設定情報が、ＰＤＣＰエンティティに対して構成され、これは、ＰＤＣＰエンティティが、ソースドナーノードに対応するＰＤＣＰ設定情報と、ターゲットドナーノードに対応するＰＤＣＰ設定情報との両方を用いるか維持し得ることと理解されてよく、ここで、ソースドナーノードに対応するＰＤＣＰ設定情報は、ソースドナーノードに対応するデータ（アップリンクデータおよび／またはダウンリンクデータを含む）を処理するためのものでよく、ターゲットドナーノードに対応するＰＤＣＰ設定情報は、ターゲットドナーノードに対応するデータ（アップリンクデータおよび／またはダウンリンクデータを含む）を処理するためのものでよい。

【0192】

端末が２組のＰＤＣＰ設定情報を有し、一方の組のＰＤＣＰ設定情報が、ソースドナーノードに対応しているＰＤＣＰ設定情報に対応し、他方の組のＰＤＣＰ設定情報が、ターゲットドナーノードに対応しているＰＤＣＰ設定情報に対応すると理解されてよい。

【0193】

設定情報が互いに対応するということは、設定情報が一緒に用いられるか、または対で用いられ得ることと理解されてよい。

【0194】

任意選択で、設定情報が互いに対応するということは、設定情報が同じであるということを含み得る。たとえば、端末のＰＤＣＰ設定情報の一方の組は、ソースドナーノードに対応するＰＤＣＰ設定情報と同じであり、および／または、端末のＰＤＣＰ設定情報の他方の組は、ターゲットドナーノードに対応するＰＤＣＰ設定情報と同じである。任意選択で、設定情報が互いに対応することは、その設定情報が異なっていることを含み得る。たとえば、端末のＰＤＣＰ設定情報の一方の組は、ソースドナーノードに対応するＰＤＣＰ設定情報とは異なっており、および／または、端末のＰＤＣＰ設定情報の他方の組は、ターゲットドナーノードに対応するＰＤＣＰ設定情報とは異なっている。

【0195】

任意選択で、端末についての、ソースドナーノードに対応しているＰＤＣＰ設定情報に対応する、ＰＤＣＰ設定情報は、ソースドナーノードによって割り当てられてもよい。たとえば、ソースドナーノードは、ソースドナーノードに対応しているＰＤＣＰ設定情報に対応するＰＤＣＰ設定情報を、リレーノードを介して端末へ送信する。端末についての、ソースドナーノードに対応しているＰＤＣＰ設定情報に対応する、ＰＤＣＰ設定情報は、ソースドナーノードによって割り当てられたＰＤＣＰ設定情報、またはソースドナーノードに対応しているＰＤＣＰ設定情報と呼ばれることがある。同様に、端末についての、ターゲットドナーノードに対応しているＰＤＣＰ設定情報に対応する、ＰＤＣＰ設定情報は、ターゲットドナーノードによって割り当てられてもよい。たとえば、ターゲットドナーノードは、リレーノードを介して、ターゲットドナーノードに対応しているＰＤＣＰ設定情報に対応するＰＤＣＰ設定情報を端末へ送信する。端末についての、ターゲットドナーノードに対応しているＰＤＣＰ設定情報に対応する、ＰＤＣＰ設定情報は、ターゲットドナーノードによって割り当てられたＰＤＣＰ設定情報、またはターゲットドナーノードに対応しているＰＤＣＰ設定情報と呼ばれることがある。

【0196】

具体的には、ＰＤＣＰエンティティでは、ヘッダ圧縮（ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎ）、ヘッダ伸長（ｈｅａｄｅｒ ｄｅｃｏｍｐｒｅｓｓｉｏｎ）、セキュリティ処理（ｓｅｃｕｒｉｔｙ ｐｒｏｃｅｓｓｉｎｇ）、ヘッダ追加（ａｄｄ ｈｅａｄｅｒ）、ヘッダ削除（ｒｅｍｏｖｅ ｈｅａｄｅｒ）などのうちの１つまたは複数の機能が、ソースドナーノードおよびターゲットドナーノードについては互いに独立している。ＰＤＣＰエンティティにおいて、並び替え機能が、ソースドナーノードとターゲットドナーノードでは共通である。詳細については、図８のＰＤＣＰエンティティについての説明を参照されたい。

【0197】

図７とは異なり、端末の１つのＰＤＣＰエンティティが２つのＲＬＣエンティティに対応することがあり、一方のＲＬＣエンティティがソースドナーノードに対応し、他方のＲＬＣエンティティがターゲットドナーノードに対応する。端末は、１つのＭＡＣエンティティを有する。１つの論理チャネルがＭＡＣエンティティと、ソースドナーノードに対応するＲＬＣエンティティとの間にあり、別の論理チャネルがＭＡＣエンティティと、ターゲットドナーノードに対応するＲＬＣエンティティとの間にある。図１２に示されるように、端末の１つのＰＤＣＰエンティティが２つのＲＬＣエンティティに対応し、端末は１つのＭＡＣエンティティのみを有する。ＬＣＨ １がＭＡＣエンティティと、一方のＲＬＣエンティティすなわちＲＬＣ １との間にあり、ＬＣＨ ２がＭＡＣエンティティと、他方のＲＬＣエンティティすなわちＲＬＣ ２との間にある。端末の一方のＲＬＣエンティティは、ソースドナーノードに対応するデータを処理するように構成されており、ＲＬＣエンティティに対応するＬＣＨは、ソースドナーノードに対応するデータを送信するためのものである。端末の他のＲＬＣエンティティは、ターゲットドナーノードに対応するデータを処理するように構成されており、他のＲＬＣエンティティに対応するＬＣＨは、ターゲットドナーノードに対応するデータを送信するためのものである。図１２に示されるように、端末のＲＬＣ １は、ソースドナーノードに対応するデータを処理するように構成されており、ＬＣＨ １は、ソースドナーノードに対応するデータを送信するためのものであり、端末のＲＬＣ ２は、ターゲットドナーノードに対応するデータを処理するように構成されており、ＬＣＨ ２は、ターゲットドナーノードに対応するデータを送信するためのものである。

【0198】

アクセスリレーノードのＤＵ上のプロトコルスタックは、端末のプロトコルスタックと同じであり、本明細書における「同じ」は、「ピアリングされている」として理解されてよい。具体的には、アクセスリレーノードのＤＵは、２つのＲＬＣエンティティ、１つのＭＡＣエンティティおよび１つのＰＨＹエンティティ（端末のそれらにピアリングされている）を有し、その２つのＲＬＣエンティティは端末の２つのＲＬＣエンティティにピアリングされており、１つのＬＣＨが、２つのＲＬＣエンティティそれぞれとＭＡＣエンティティの間にあり、アクセスリレーノードのＤＵの２つのＬＣＨは、端末の２つのＬＣＨにピアリングされている。図１２に示されるように、端末の１つのベアラに対して、ＩＡＢノード２は、２つのＲＬＣエンティティ、すなわちＲＬＣ １およびＲＬＣ ２を有する。ＩＡＢノード２のＲＬＣ １は、端末のＲＬＣ １にピアリングされ、ＩＡＢノード２のＲＬＣ ２は、端末のＲＬＣ ２にピアリングされている。ＬＣＨ、すなわちＬＣＨ １が、ＲＬＣ １とＩＡＢノード２のＭＡＣエンティティとの間にある。ダウンリンク伝送が例として用いられている。ＩＡＢノード２は、データをＩＡＢノード２のＬＣＨ １で送信し、端末１は、そのデータを端末１のＬＣＨ １で受信する。ＬＣＨ、すなわちＬＣＨ ２が、ＲＬＣ ２とＩＡＢノード２のＭＡＣエンティティとの間にある。ダウンリンク伝送が例として用いられている。ＩＡＢノード２は、データをＩＡＢノード２のＬＣＨ ２で送信し、端末１は、そのデータを端末１のＬＣＨ ２で受信する。

【0199】

端末の場合と同様に、アクセスリレーノードのＤＵ上の一方のＲＬＣエンティティは、ソースドナーノードに対応するデータを処理するように構成されており、ＲＬＣエンティティに対応するＬＣＨは、ソースドナーノードに対応するデータを送信するためのものである。アクセスリレーノードのＤＵ上の他のＲＬＣエンティティは、ターゲットドナーノードに対応するデータを処理するように構成されており、他のＲＬＣエンティティに対応するＬＣＨは、ターゲットドナーノードに対応するデータを送信するためのものである。詳細については、ＲＬＣエンティティおよび端末のＬＣＨの内容を参照されたい。詳細は、本明細書では再度説明されない。端末のＬＣＨとアクセスリレーノードは、一緒に用いられても、対で用いられても、対応して用いられてもよく、端末のＬＣＨとアクセスリレーノード（または端末のＬＣＨとアクセスリレーノードの設定情報）は、同じであっても異なっていてもよい。これは、本出願のこの実施形態では限定されていない。

【0200】

対応するＧＴＰ－Ｕトンネルが、アクセスリレーノードのＤＵとソースドナーノードの間、およびアクセスリレーノードのＤＵとターゲットドナーノードの間に、端末のベアラの粒度で確立され得る。たとえば、端末の１つのベアラに対して、対応するＧＴＰトンネルがＩＡＢノード２とＩＡＢドナーＣＵ １の間に確立され、対応するＧＴＰトンネルがまた、ＩＡＢノード２とＩＡＢドナーＣＵ ２の間にも確立される。図１２に示されるように、端末の１つのベアラに対して、ＧＴＰ－ＵトンネルすなわちＧＴＰ－Ｕ １が、ＩＡＢドナーＣＵ １とＩＡＢノード２のＤＵの間にある。ＧＴＰ－Ｕ １は、ソースドナーノードに対応するデータを送信するためのものである。別のＧＴＰ－ＵトンネルすなわちＧＴＰ－Ｕ ２が、ＩＡＢドナーＣＵ ２とＩＡＢノード２のＤＵの間にある。ＧＴＰ－Ｕ ２は、ターゲットドナーノードに対応するデータを送信するためのものである。

【0201】

アクセスリレーノードの１つのＬＣＨが、１つのＧＴＰ－Ｕトンネルに対応する。言い換えると、ＬＣＨとＧＴＰ－Ｕトンネルは１対１の対応関係にある。アップリンク方向では、１つのＬＣＨを介して受信されたデータは、そのＬＣＨに対応するＧＴＰ－Ｕトンネルにマッピングされる。ダウンリンク方向では、１つのＧＴＰ－Ｕトンネルを介して受信されたデータは、そのＧＴＰ－Ｕトンネルに対応するＬＣＨにマッピングされる。図１２を例として用いると、ＩＡＢノード２では、ＬＣＨ １とＧＴＰ－Ｕ １が１対１の対応関係にあり、ＬＣＨ ２とＧＴＰ－Ｕ ２が１対１の対応関係にある。アップリンク方向では、ＬＣＨ １を介して受信されたデータは、ＧＴＰ－Ｕ １にマッピングされてＩＡＢドナーＣＵ １へ送信され、ＬＣＨ ２を介して受信されたデータは、ＧＴＰ－Ｕ ２にマッピングされてＩＡＢドナーＣＵ ２へ送信される。ダウンリンク方向では、ＩＡＢドナーＣＵ １からＧＴＰ－Ｕ １を介して受信されたデータはＬＣＨ １にマッピングされ、ＩＡＢドナーＣＵ ２からＧＴＰ－Ｕ ２を介して受信されたデータはＬＣＨ ２にマッピングされる。

【0202】

たとえば、図１２のソースドナーノード（すなわち、ＩＡＢドナーＣＵ １）に対応するアップリンクデータの送信が例として用いられている。端末１で、ＰＤＣＰエンティティは、ＩＡＢドナーＣＵ １に対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理してよい。次に、ＰＤＣＰエンティティは、端末１のＲＬＣ １へ、ソースドナーノードに対応するＰＤＣＰ設定情報を用いて処理されているアップリンクデータを送信する。端末１のＲＬＣ １は、アップリンクデータを端末１のＭＡＣエンティティへＬＣＨ １を介して送信する。端末１のＭＡＣエンティティは、端末１のＬＣＨ １から受信されたデータをカプセル化し、端末１のＬＣＨ １の識別子をＭＡＣヘッダに付加し得る。端末１のＰＨＹエンティティは、データを処理し、処理されたデータをＩＡＢノード２へ送信する。それに対応して、ＩＡＢノード２がデータを端末１から受信した後に、ＩＡＢノード２のＭＡＣ層はＭＡＣヘッダを解析して、端末のＬＣＨ １の識別子を取得し得る。ＩＡＢノード２は、端末のＬＣＨ １にピアリングされているＬＣＨ、すなわちＩＡＢノード２のＬＣＨ １を介してデータをＲＬＣ １へ送信する。ＩＡＢノード２は、端末のアップリンクデータをＲＬＣ １から抜き出し、そのアップリンクデータを対応するＧＴＰ－Ｕトンネル１にマッピングし、現在のルート設定情報に基づくバックホールリンクを介して、ＧＴＰ－Ｕトンネル１にマッピングされているデータをＩＡＢドナーＣＵ １へさらに送信する。端末のアップリンクデータをＧＴＰ－Ｕトンネル１から抜き出した後に、ＩＡＢドナーＣＵ １は、ＩＡＢドナーＣＵ １に対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理する。

【0203】

ターゲットドナーノード（すなわち、ＩＡＢドナーＣＵ ２）に対応するアップリンクデータの送信は、ソースドナーノードに対応するアップリンクデータの送信と同様である。詳細については、ソースドナーノードに対応するアップリンクデータの送信の内容を参照されたい。

【0204】

別の例として、図１２のソースドナーノード（すなわち、ＩＡＢドナーＣＵ １）に対応するダウンリンクデータの送信が例として用いられている。ＩＡＢドナーＣＵ １は、ＩＡＢドナーＣＵ １に対応するＰＤＣＰ設定情報を用いてダウンリンクデータを処理し、次に、ＩＡＢドナーＣＵ １は、そのダウンリンクデータをＩＡＢノード２のＤＵへＧＴＰ－Ｕトンネル１を介して送信する。ダウンリンクデータをＧＴＰ－Ｕトンネル１から受信した後に、ＩＡＢノード２のＤＵは、そのダウンリンクデータをＧＴＰ－Ｕトンネル１に対応するＲＬＣ １にマッピングする。ＲＬＣ １は、ダウンリンクデータを処理し、処理されたダウンリンクデータをＭＡＣエンティティへＬＣＨ １を介して送信する。ＭＡＣエンティティは、端末１にある、かつＩＡＢノード２のＤＵのＬＣＨ １にピアリングされている、ＬＣＨの識別子（すなわち、端末１のＬＣＨ １の識別子）をＭＡＣヘッダに追加してもよい。ＩＡＢノード２のＤＵのＰＨＹ層で処理された後に、ダウンリンクデータは端末１へ送信される。それに対応して、端末１がデータをＩＡＢノード２のＤＵから受信した後に、端末１のＭＡＣエンティティはＭＡＣヘッダを解析して、端末１のＬＣＨ １の識別子を取得し得る。次に、端末１はデータを端末１のＲＬＣ １へ、端末１のＬＣＨ １を介して送信する。端末１のＲＬＣ １はデータを処理し、処理されたデータを対応するＰＤＣＰエンティティへ送信する。ＰＤＣＰエンティティは、ソースドナーノードに対応する設定情報を用いてダウンリンクデータを処理する。

【0205】

ターゲットドナーノード（すなわち、ＩＡＢドナーＣＵ ２）に対応するダウンリンクデータの送信は、ソースドナーノードに対応するダウンリンクデータの送信と同様である。詳細については、ソースドナーノードに対応するアップリンクデータの送信の内容を参照されたい。

【0206】

アクセスリレーノードのＭＴは、ＢＡＰエンティティ、ＲＬＣエンティティ、ＭＡＣエンティティ、およびＰＨＹエンティティを有する。

【0207】

移行リレーノードのＤＵは、プロトコルスタック（子ノードのＭＴのそれにピアリングされている）を有する。図１２に示されるように、ＩＡＢノード３のＤＵは、ＢＡＰエンティティ、ＲＬＣエンティティ、ＭＡＣエンティティ、およびＰＨＹエンティティ（ＩＡＢノード２のＭＴのそれらにピアリングされている）を有する。

【0208】

任意選択で、ソースドナーノードは、ルーティングルールおよび／またはベアラマッピングルールをアクセスリレーノードとソースドナーノードの間の経路に関して構成してよく、ターゲットドナーノードは、ルーティングルールおよび／またはベアラマッピングルールをアクセスリレーノードとターゲットドナーノードの間の経路に関して構成してよく、そのルーティングルールおよび／またはベアラマッピングルールは信号／データ伝送に用いられる。

【0209】

ソースドナーノードに対応するデータとターゲットドナーノードに対応するデータとの両方が、アクセスリレーノードと移行リレーノードの間の経路で伝送されることが可能であることを確実にするために、ＢＡＰ設定の２つの組が、アクセスリレーノードと移行リレーノードの間の経路上で、１つまたは複数のノード（アクセスリレーノード、移行リレーノード、および他の１つまたは複数の、アクセスリレーノードと移行リレーノードの間のリレーノードを含む）の１つまたは複数のＭＴおよび／またはＤＵでサポートされることが必要である。ＢＡＰ設定の一方の組は、ルーティング設定および／またはベアラマッピング設定を含めて、ソースドナーノードによって提供され、ＢＡＰ設定の他方の組は、ルーティング設定および／またはベアラマッピング設定を含めて、ターゲットドナーノードによって提供される。

【0210】

例では、アクセスリレーノードは移行リレーノードではない。移行リレーノードの親ノードが変化するので、２組のＢＡＰ設定が移行リレーノードに構成される。ＢＡＰ設定の一方の組は、ソースドナーノードによって提供されるルーティング設定および／またはベアラマッピング設定であり、ＢＡＰ設定の他方の組は、ターゲットドナーノードによって提供されるルーティング設定および／またはベアラマッピング設定である。アクセスリレーノードの親ノードが変化しないので、アクセスリレーノードと親ノードの間のリンクへのベアラマッピングは変化しないままであり得るが、アクセスリレーノードと親ノードの間のリンクでのルーティング設定が変化することがある（たとえば、ルーティング設定の際のアクセスリレーノードのＢＡＰアドレスが変化する）。したがって、２組のＢＡＰ設定がアクセスリレーノードに構成され、一方の組のＢＡＰ設定が、ソースドナーノードによって提供されるルーティング設定であり、他方の組のＢＡＰ設定が、ターゲットドナーノードによって提供されるルーティングである。

【0211】

任意選択で、１つまたは複数のノードの１つまたは複数のＭＴ（またはＤＵ）は、１つだけのＢＡＰエンティティを有してもよく、このＢＡＰエンティティは、２組のＢＡＰ設定をサポートする。代替として、１つまたは複数のＭＴ（またはＤＵ）は、２つのＢＡＰエンティティを有してもよく、一方のＢＡＰエンティティは、ソースドナーノードによって提供されたＢＡＰ設定をサポートし、他方のＢＡＰエンティティは、ターゲットドナーノードによって提供されたＢＡＰ設定をサポートする。

【0212】

任意選択で、ターゲットドナーノードは、インジケーション情報を１つまたは複数のノードにソースドナーノードを介して別個に送信してもよい。インジケーション情報のそれぞれは、対応するノードを示して２組のＢＡＰ設定情報を開始する。開始することは、活性化または有効化することと理解されてよく、２つの組のＢＡＰ設定情報を開始することは、ＢＡＰ層のデュアル設定を開始することと理解されてよい。代替として、ソースドナーノードは、インジケーション情報を１つまたは複数のノードへ別個に送信してもよい。

【0213】

ダウンリンクでは、ソースドナーノードからダウンリンクデータを受信した後に、１つまたは複数のノード内のノードが、ダウンリンクデータをそのノードの次ホップノードへ、ソースドナーノードのＢＡＰ設定に基づいて送信し、および／または、ターゲットドナーノードからダウンリンクデータを受信した後に、１つまたは複数のノード内のノードがダウンリンクデータを、そのノードの次ホップノードへ、ターゲットドナーノードのＢＡＰ設定に基づいて送信する。アップリンク方向のデータ送信も同様であり、本明細書では再度説明されない。

【0214】

移行リレーノードのＭＴは、ＤＡＰＳと同様のプロトコルスタックを有する。プロトコルスタックがＤＡＰＳと同様であるということは、移行リレーノードのＭＴが、プロトコルスタック（ソース親ノードのそれにピアリングされている）と、プロトコルスタック（ターゲット親ノードのそれにピアリングされている）とを有すると理解されてよい。移行リレーノードによってソース親ノードから受信されたソースダウンリンクデータは、ソース親ノードに対応するプロトコルスタックを用いて処理されてよく、移行リレーノードによってターゲット親ノードから受信されたターゲットダウンリンクデータは、ターゲット親ノードに対応するプロトコルスタックを用いて処理されてよい。たとえば、図１２に示されるように、ＩＡＢノード３のＭＴは、ＢＡＰエンティティ、ＲＬＣエンティティ、ＭＡＣエンティティ、およびＰＨＹエンティティ（それぞれ、ＩＡＢノード１およびＩＡＢノード４のそれらにピアリングされている）を有する。移行リレーノードは、１つだけのＢＡＰエンティティを有しても、２つのＢＡＰエンティティを有してもよいことに留意されたい。詳細については、前述の説明を参照されたい。

【0215】

任意選択で、１つまたは複数の他のリレーノードがアクセスリレーノードと移行リレーノードの間にあってもよい。この場合、アクセスリレーノードと移行リレーノードの間のリンクに、各ノードのＤＵが、ＢＡＰエンティティ、ＲＬＣエンティティ、ＭＡＣエンティティ、およびＰＨＹエンティティ（子ノードのＭＴのそれらにピアリングされている）を有する。これは、本出願のこの実施形態において限定されていない。

【0216】

任意選択で、アクセスリレーノードと移行リレーノードとは同一のノードであってもよく、すなわち、ハンドオーバがアクセスリレーノードに発生する。この場合、アクセスリレーノードは、図１２の、ＩＡＢノード２のＤＵのプロトコルスタックと、ＩＡＢノード３のＭＴのプロトコルスタックとを有する。

【0217】

図１２に示されるように、ソース親ノードとソースドナーノードの間、またはターゲット親ノードとターゲットドナーノードの間の２つの隣り合うノードは、ピアプロトコルスタックを有する。詳細については、図７の内容を参照されたい。詳細は、本明細書では再度説明されない。

【0218】

前述の実施形態において、ダウンリンクでは、アクセスリレーノードは、別々のＧＴＰ－Ｕトンネルに基づいて、ソースドナーノードに対応するデータおよび／またはターゲットドナーノードに対応するデータを区別して、そのデータを別々のＬＣＨにマッピングし、また、そのデータを端末へ送信し、それにより端末は、ソースドナーノードに対応するデータおよび／またはターゲットドナーノードに対応するデータを区別する。アップリンクでは、アクセスリレーノードは、別々のＬＣＨに基づいて、ソースドナーノードに対応するデータおよび／またはターゲットドナーノードに対応するデータを区別して、そのデータを別々のＧＴＰ－Ｕトンネルにマッピングし、また、そのデータをソースドナーノードおよび／またはターゲットドナーノードへ送信する。

【0219】

別の可能な実装において、ダウンリンクでは、ダウンリンクデータパケットが、ルーティング識別子（ルーティングＩＤ）情報を搬送することがあり、アクセスリレーノードは、そのルーティング識別子情報に基づいて、ソースドナーノードに対応するデータおよび／またはターゲットドナーノードに対応するデータを区別し得る。

【0220】

具体的には、ルーティング識別子情報は、アクセスリレーノードのＢＡＰアドレスおよび経路識別子（ｐａｔｈ ＩＤ）を含み、アクセスリレーノードは、ルーティング識別子情報で搬送されるＢＡＰアドレスに基づいて、ダウンリンクデータパケットがソースドナーノードからのものであるか、それともターゲットドナーノードからのものであるかを区別して、ダウンリンクデータパケットを別々のＬＣＨにさらにマッピングし、ダウンリンクデータパケットを端末へ送信し得る。ソースドナーノードおよびターゲットドナーノードはそれぞれ、２つの異なるＢＡＰアドレスをアクセスリレーノードに割り当て、ソースドナーノードによって送信されたダウンリンクデータパケット内のルーティング識別子情報は、ソースドナーノードによってアクセスリレーノードに割り当てられたＢＡＰアドレスを搬送し、ターゲットドナーノードによって送信されたダウンリンクデータパケット内のルーティング識別子情報は、ターゲットドナーノードによってアクセスリレーノードに割り当てられたＢＡＰアドレスを搬送する。

【0221】

ソースドナーノードによってアクセスリレーノードに割り当てられたＢＡＰアドレスと、ターゲットドナーノードによってアクセスリレーノードに割り当てられたＢＡＰアドレスとが異なることを確実にするために、ハンドオーバ準備処理において、ソースドナーノードは、ソースドナーノードによってアクセスリレーノードに割り当てられたＢＡＰアドレスをターゲットドナーノードに送信してよく、それにより、ターゲットドナーノードは、ソースドナーノードによってアクセスリレーノードに割り当てられたＢＡＰアドレスとは異なるＢＡＰアドレスを生成する。例では、ソースドナーノードは、ソースドナーノードによってアクセスリレーノードに割り当てられたＢＡＰアドレスをハンドオーバ要求メッセージに含め、このハンドオーバ要求メッセージをターゲットドナーノードへ送信してよい。ターゲットドナーノードは、ターゲットドナーノードによってアクセスリレーノードに割り当てられたＢＡＰアドレスをハンドオーバコマンドメッセージ（ＲＲＣ再設定メッセージと呼ばれることもある）に含め、このハンドオーバコマンドメッセージをアクセスリレーノードへソースドナーノードを介して送信してよい。

【0222】

以下では、図１３から図１６を参照して、本出願で提供されるソリューションについて説明する。図１３～図１６の内容と、図１２のプロトコルスタックの内容とは相互に参照されることがある。

【0223】

図１３、図１４、図１５、および図１６の方法では、第１のリレーノードが端末のアクセスリレーノードであり（または、第１のリレーノードが端末の親ノードであると理解されてもよい）、この第１のリレーノードはアクセスリレーノードと呼ばれることもある。ドナーノード間ハンドオーバが第１のリレーノードに発生することがあり、具体的には、第１のリレーノードは、ソースドナーノードからターゲットドナーノードへハンドオーバされる。代替として、ドナーノード間ハンドオーバは、第１のリレーノードとソースドナーノードの間のリンク上のリレーノード（第２のリレーノードと呼ばれることもある）に発生し、具体的には、第１のリレーノードが第２のリレーノードに接続され、第２のリレーノードがソースドナーノードからターゲットドナーノードへハンドオーバされる。ドナーノード間ハンドオーバの内容に関しては、図１０および図１１の内容を参照する。図１１のドナーノード間ハンドオーバは、例として使用される。第１のリレーノードは図１１のＩＡＢノード２であってよく、第２のリレーノードは図１１のＩＡＢノード３であってよく、このＩＡＢノード３は、ＩＡＢドナーＣＵ １からＩＡＢドナーＣＵ ２へハンドオーバされる。

【0224】

図１３は、本出願の実施形態によるＬＣＨ設定方法の概略フローチャートである。図１３に示されるように、図１３の方法は以下のステップを含む。

【0225】

Ｓ１００：ソースドナーノードまたはターゲットドナーノードが、第１のインジケーション情報を第１のリレーノードへ送信する。

【0226】

Ｓ１００は任意選択である。

【0227】

第１のリレーノードは、第１のインジケーション情報に基づいて、第１のベアラに対応する第２のＬＣＨの設定情報を生成し得る。第２のＬＣＨは、ターゲットドナーノードに対応するＰＤＣＰデータを送信するためのものである。

【0228】

任意選択で、第１のインジケーション情報は第１のメッセージで搬送されてよい。

【0229】

任意選択で、Ｓ１００の前に、端末の第１のベアラは第１のＬＣＨに対応し、この第１のＬＣＨは、ソースドナーノードに対応するＰＤＣＰデータを送信するためのものである。

【0230】

任意選択で、本出願では、第１のベアラは第１のデータ無線ベアラ（ｄａｔａ ｒａｄｉｏ ｂｅａｒｅｒ、ＤＲＢ）であってよい。

【0231】

たとえば、第１のリレーノードまたは第２のリレーノードがドナーノード間ハンドオーバを実施する前に、第１のリレーノードは、端末に対する第１のＬＣＨを構成しており、この第１のＬＣＨは、ソースドナーノードに対応するＰＤＣＰデータを送信するためのものである。

【0232】

具体的には、第１のリレーノードまたは第２のリレーノードがドナーノード間ハンドオーバを実施する前に、第１のリレーノードは、第１のベアラのエアインターフェース設定情報を端末へソースドナーノードを介して送信し、この第１のベアラのエアインターフェース設定情報は、第１のリレーノードによって端末に対して生成されたボトム層（ＲＬＣ層、ＭＡＣ層、ＰＨＹ層および第１のＬＣＨのうちの１つまたは複数を含み得る）の設定情報を含む。

【0233】

任意選択で、第１のＬＣＨは図１２の端末のＬＣＨ １であってよく、第２のＬＣＨは図１２の端末のＬＣＨ ２であってよい。詳細については、図１２の内容を参照されたい。

【0234】

第１のインジケーション情報によって示される、複数の種類の内容があり得る。以下では、いくつかの例を参照して説明をする。

【0235】

例では、第１のインジケーション情報はベアラ粒度であってよい。言い換えると、第１のインジケーション情報は、端末の１つのベアラと１対１の対応関係にある。第１のインジケーション情報は、１つのベアラに対応する第２のＬＣＨの設定情報を生成するように第１のリレーノードに示すことがあり、１つのベアラのデータ伝送がドナーノード間ハンドオーバ中に中断されるべきでないことを示すことがあり、ＤＡＰＳハンドオーバが１つのベアラに対して構成されるべきであることを示すことがあり、または他の内容を示すことがある。これは、本出願のこの実施形態では限定されていない。

【0236】

この例では、任意選択で、第１のインジケーション情報は１つのベアラの識別子を含むことがあり、そのベアラは第１のベアラを含む。

【0237】

この例では、第１のリレーノードは、複数の第１のインジケーション情報を受信し、第１のインジケーション情報のそれぞれは、１つのベアラと１対１の対応関係にあり、第１のリレーノードは、端末の１つまたは複数のベアラごとに第２のＬＣＨの設定情報を生成し得る。本出願では、第１のベアラが説明のための例として用いられている。当業者であれば、本出願のこの実施形態における内容が、他の１つまたは複数のベアラの場合にもまた適用可能であることを知り得る。

【0238】

別の例では、第１のインジケーション情報は端末粒度であってよい。言い換えると、第１のインジケーション情報は、特定のベアラを示さない。第１のインジケーション情報は、第１のリレーノードに、第２のＬＣＨの設定情報を端末のベアラごとに生成するように示すことがあり、端末のデータ伝送がドナーノード間ハンドオーバ中に中断されるべきでないことを示すことがあり、ＤＡＰＳハンドオーバが端末に対して構成されるべきであることを示すことがあり、または他の内容を示すことがある。これは、本出願のこの実施形態では限定されていない。

【0239】

この例では、任意選択で、第１のインジケーション情報はベアラの識別子を含まないことがある。

【0240】

この例では、第１のリレーノードは、端末のベアラ（第１のベアラを含む）ごとに第２のＬＣＨの設定情報を生成し得る。本出願では、第１のベアラが説明のための例として用いられている。当業者であれば、本出願のこの実施形態における内容が、他の１つまたは複数のベアラの場合にもまた適用可能であることを知り得る。

【0241】

第１のインジケーション情報は、第１のメッセージで搬送されてよい。ソースドナーノードまたはターゲットドナーノードが第１のメッセージを送信する時点には、複数の状況があり得る。以下では、いくつかの例を参照して説明をする。

【0242】

ドナーノード間ハンドオーバが第１のリレーノードに発生する場合、第１のリレーノードはそのドナーノード間ハンドオーバを検知し得ることに留意されたい。たとえば、第１のリレーノードは、ハンドオーバコマンドをターゲットドナーノードからソースドナーノードを介して受信することがあり、また、第１のリレーノードは、ターゲットドナーノードに対するランダムアクセス要求を開始することがある。次に、ターゲットドナーノードにアクセスした後に、第１のリレーノードは、ターゲットドナーノードとの接続を確立し得る。ドナーノード間ハンドオーバが第２のリレーノードに発生した場合に、第２のリレーノードは、そのドナーノード間ハンドオーバを検知し得る。当業者であれば、第１のリレーノードによって実施される動作が、代替として第２のリレーノードによって実施されてもよいことを理解し得る。ただし、ドナー間ハンドオーバが第２のリレーノードに発生した場合には、第１のリレーノードは、そのハンドオーバを検知しないことがある。しかし、第２のリレーノードがターゲットドナーノードにアクセスし、第２のリレー基地局がターゲットドナーノードとの接続を確立した後に、第２のリレーノードの子孫ノードがターゲットドナーノードとの接続を順次に確立して、データ伝送サービスを端末に提供する。したがって、第１のリレーノードは、ターゲットドナーノードとの接続の確立を検知することができる。したがって、ドナーノード間ハンドオーバが発生したのが第１のリレーノードであるか、それとも第２のリレーノードであるかにかかわらず、第１のリレーノードは、ターゲットドナーノードとの接続を確立する。本明細書における接続の確立は、Ｆ１インターフェースおよびＧＴＰ－Ｕトンネルの一方または両方の確立を含み得る。

【0243】

例では、ターゲットドナーノードとの接続を確立した後に、第１のリレーノードは、第１のメッセージをターゲットドナーノードから受信し得る。

【0244】

任意選択で、この例では、第１のメッセージはＵＥコンテキストセットアップ要求メッセージであってもよい。

【0245】

別の例では、ターゲットドナーノードとの接続を確立する前に、第１のリレーノードは、第１のメッセージをソースドナーノードから受信することがある。

【0246】

具体的には、ソースドナーノードが、ドナーノード間ハンドオーバが第１のリレーノードまたは第２のリレーノードに発生すると決定した場合に、ソースドナーノードは、ハンドオーバ要求メッセージをターゲットドナーノードへ送信し得る。ソースドナーノードがハンドオーバ決定を実施し、ハンドオーバ要求メッセージをターゲットドナーノードへ送信する前に、またはソースドナーノードがハンドオーバ要求メッセージをターゲットドナーノードへ送信した後に、第１のリレーノードは、第１のメッセージをソースドナーノードから受信する。

【0247】

任意選択で、別の例では、第１のメッセージはＵＥコンテキスト修正要求メッセージであってもよい。

【0248】

Ｓ１０１：第１のリレーノードは、第２のＬＣＨの設定情報を生成する。

【0249】

任意選択で、Ｓ１００が存在してもよく、第１のリレーノードは、第１のインジケーション情報に基づいて第２のＬＣＨの設定情報を生成する。

【0250】

任意選択で、Ｓ１００が存在しないこともある。例では、第１のリレーノードが接続確立要求をターゲットドナーノードから受信した後に、第１のリレーノードは、第２のＬＣＨの設定情報を生成する。任意選択で、接続確立要求は、ＧＴＰトンネル確立要求および／またはＦ１インターフェース確立要求であってもよく、または、接続確立要求は別の名称を有してもよい。これは、本出願のこの実施形態では限定されていない。

【0251】

前述の例では、接続確立要求をターゲットドナーノードから受信した後に、第１のリレーノードは、第２のＬＣＨの設定情報を端末のベアラ（第１のベアラを含む）ごとに生成することがある。本明細書では、第１のベアラが説明のための例として用いられている。当業者であれば、本出願のこの実施形態における内容が、他の１つまたは複数のベアラの場合にもまた適用可能であることを知り得る。

【0252】

Ｓ１０２：第１のリレーノードは、第２のＬＣＨの設定情報を端末へ送信する。

【0253】

Ｓ１０１およびＳ１０２によって、第１のリレーノードは、第２のＬＣＨを端末の第１のＤＲＢに対して構成し、それにより、第１のベアラは、第１のＬＣＨおよび第２のＬＣＨに対応すると理解されてよい。

【0254】

任意選択で、第１のベアラが第１のＬＣＨおよび第２のＬＣＨに対応することは、第１のＬＣＨおよび第２のＬＣＨが第１のベアラに対して構成されること、第１のベアラが第１のＬＣＨおよび第２のＬＣＨと関連付けられること、第１のベアラが第１のＬＣＨおよび第２のＬＣＨを使用し得ること、または、第１のベアラが第１のＬＣＨおよび第２のＬＣＨを使用する能力を有するが、実際には、第１のベアラが第１のＬＣＨおよび第２のＬＣＨを使用するかどうかは、ソースドナーノードに対応するＰＤＣＰデータ、およびターゲットドナーノードに対応するＰＤＣＰデータが存在するか否かに依存すること、と理解されてよい。これは、本出願のこの実施形態では限定されていない。たとえば、期間内に、ソースドナーノードに対応するＰＤＣＰデータだけがあり、ターゲットドナーノードに対応するＰＤＣＰデータはない。したがって、第１のＬＣＨだけが使用され、第２のＬＣＨは使用されない。代替として、第１のベアラが第１のＬＣＨおよび第２のＬＣＨに対応することは、第１のベアラが第２のＬＣＨを使用する場合に、第１のＬＣＨが維持される、解放されない、依然としてアクティブ状態にある、などと理解されてよい。

【0255】

任意選択で、第１のベアラが第１のＬＣＨおよび第２のＬＣＨに対応することは、第１のベアラが第１のＬＣＨと第２のＬＣＨの両方に対応することと理解されてよい。具体的には、１つまたは複数の時点または期間において、第１のベアラは、第１のＬＣＨと第２のＬＣＨの両方に対応する。

【0256】

任意選択で、第２のＬＣＨの設定情報は、第２のＬＣＨの識別子、第２のＬＣＨの優先度、および第１のＤＲＢのベアラ識別子のうちの１つまたは複数を含む。

【0257】

第１のＬＣＨは、ソースドナーノードに対応するＰＤＣＰデータを送信するためのものであり、第２のＬＣＨは、ターゲットドナーノードに対応するＰＤＣＰデータを送信するためのものである。

【0258】

任意選択で、第１のＬＣＨは、第１のリレーノードとソースドナーノードの間のＧＴＰ－Ｕトンネルに対応し、第２のＬＣＨは、第１のリレーノードとターゲットドナーノードの間のＧＴＰ－Ｕトンネルに対応する。詳細については、図１２の内容を参照されたい。詳細は、本明細書では再度説明されない。

【0259】

任意選択で、第１のＬＣＨは、ソースドナーノードによって第１のリレーノードに割り当てられたＢＡＰアドレスに対応し、第２のＬＣＨは、ターゲットドナーノードによって第１のリレーノードに割り当てられたＢＡＰアドレスに対応する。詳細については、図１２の内容を参照されたい。詳細は、本明細書では再度説明されない。

【0260】

可能な実装では、Ｓ１０２は以下を含み得る。第１のリレーノードは、第２のＬＣＨの設定情報を端末へターゲットドナーノードを介して送信する。

【0261】

具体的には、第１のリレーノードは、第２のＬＣＨの設定情報をターゲットドナーノードへ送信することがあり、ターゲットドナーノードは第２のメッセージを生成し、この第２のメッセージは第３のメッセージを含み、第３のメッセージは第２のＬＣＨの設定情報を含む。ターゲットドナーノードは、第２のメッセージをソースドナーノードへ送信し、次に、ソースドナーノードは、第３のメッセージを端末へ第１のリレーノードを介して送信する。たとえば、第３のメッセージは、ＲＲＣ再設定メッセージであってもよく、ハンドオーバコマンドと呼ばれることがある。第２のメッセージは、ハンドオーバ要求応答メッセージであってよい。

【0262】

ソースドナーノードは、第３のメッセージをターゲットドナーノードへ転送して、ターゲットドナーノードおよび端末がターゲットドナーノードに対応するＰＤＣＰ設定情報に基づいてセキュリティネゴシエーションを実施する前にターゲットドナーノードが単独でメッセージを端末へ送信できない、という状況を回避する。

【0263】

任意選択で、第２のＬＣＨの設定情報に加えて、第３のメッセージは、第１のベアラのエアインターフェース設定情報、ソースドナーノードに対応するＰＤＣＰ設定情報、ターゲットドナーノードに対応するＰＤＣＰ設定情報、およびターゲットドナーノードによって第１のリレーノードに割り当てられたＢＡＰアドレス、のうちの１つまたは複数をさらに含み得る。第１のベアラのエアインターフェース設定情報およびソースドナーノードに対応するＰＤＣＰ設定情報は、第１のリレーノードまたはソースドナーノードによってターゲットドナーノードへ送信されることがあり、ターゲットドナーノードに対応するＰＤＣＰ設定情報は、ターゲットドナーノードによって生成されることがある。以下で説明をする。

【0264】

任意選択で、第３のメッセージは、第１のベアラのエアインターフェース設定情報を含み得る。任意選択で、第１のベアラのエアインターフェース設定情報は、第１のＬＣＨの設定情報を含み得る。詳細については、前述の説明を参照されたい。第３のメッセージは、第２のＬＣＨの設定情報および第１のベアラのエアインターフェース設定情報を含む。エアインターフェース設定については、端末は、完全設定手法で、端末と第１のリレーノードの間の既存のエアインターフェース設定を、受信された第２のＬＣＨの設定情報と第１のベアラのエアインターフェース設定情報とに置き換え、それにより、端末はデータ伝送を、更新されたエアインターフェース設定に基づいて、第１のリレーノードとともに実施する。第１のベアラに対して２つのＬＣＨが構成され、一方はソースドナーノードに対応するデータを送信するためのものであり、他方はターゲットドナーノードに対応するデータを送信するためのものであり、端末のサービス送信が、第１のリレーノードのハンドオーバ中または第２のリレーノードのハンドオーバ中に中断されないことが確実になる。

【0265】

任意選択で、第３のメッセージは、第１のベアラのエアインターフェース設定情報を含まないことがあるが、第２のＬＣＨの設定情報は含み得る。この場合、端末が第３のメッセージを受信した後に、第１のベアラのエアインターフェース設定に対して、端末は第２のＬＣＨを、第１のベアラの既存のエアインターフェース設定に基づいて増分設定手法で追加して、通信リソースを節約し得る。

【0266】

任意選択で、第３のメッセージは、ターゲットドナーノードに対応するＰＤＣＰ設定情報を含み得るが、ソースドナーノードに対応するＰＤＣＰ設定情報は含まないことがある。第３のメッセージを受信した後に、端末は、第１のベアラのＰＤＣＰエンティティに、ターゲットドナーノードに対応するＰＤＣＰ設定情報を追加する。第３のメッセージを受信する前に、端末の第１のＤＲＢのＰＤＣＰエンティティは、ソースドナーノードに対応するＰＤＣＰ設定情報を含んでいると理解されてよい。第３のメッセージを受信した後に、第１のベアラのＰＤＣＰ設定に対して、端末は、ターゲットドナーノードに対応するＰＤＣＰ設定情報を、第１のベアラの元のＰＤＣＰエンティティに基づいて増分設定手法で追加し得る。加えて、第３のメッセージは、第２のＬＣＨの設定情報と、ターゲットドナーノードに対応するＰＤＣＰ設定情報とを含み、このことは、第２のＬＣＨの設定情報が、ターゲットドナーノードに対応しているＰＤＣＰ設定情報に対応することを暗に示し得る。具体的には、ダウンリンク方向では、第２のＬＣＨを介して端末によって受信されたデータは、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いて処理され、アップリンク方向では、端末は、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いて処理されているアップリンクデータを、第２のＬＣＨを介して送信し得る。

【0267】

任意選択で、第３のメッセージは、ターゲットドナーノードに対応するＰＤＣＰ設定情報およびソースドナーノードに対応するＰＤＣＰ設定情報を含み得る。したがって、第１のベアラのＰＤＣＰ設定に対して、端末は、完全設定手法で、ソースドナーノードに対応するＰＤＣＰ設定情報を、ソースドナーノードに対応するＰＤＣＰ設定情報と、第１のベアラのＰＤＣＰエンティティに対してターゲットドナーノードに対応するＰＤＣＰ設定情報とに置き換えてもよく、それにより、端末はデータ伝送を、第１のリレーノードとともに、更新されたエアインターフェース設定に基づいて実施する。第１のベアラに対して２つのＬＣＨが構成され、一方はソースドナーノードに対応するデータを送信するためのものであり、このデータは、ソースドナーノードに対応するＰＤＣＰ設定情報を用いて処理され、他方はターゲットドナーノードに対応するデータを送信するためのものであり、このデータは、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いて処理されて、端末のサービス送信が第１のリレーノードのハンドオーバ中または第２のリレーノードのハンドオーバ中に中断されないことが確実になる。

【0268】

任意選択で、第１のリレーノードが第２のＬＣＨの設定情報をターゲットドナーノードへ送信する時点には、複数の状況があり得る。たとえば、第１のリレーノードがターゲットドナーノードとの接続を確立した後に、または第１のリレーノードがターゲットドナーノードとの接続を確立する前に、第１のリレーノードは、第２のＬＣＨの設定情報をターゲットドナーノードへ送信する。以下では、いくつかの実装を参照して説明をする。

【0269】

実装では、ターゲットドナーノードとの接続を確立した後に、第１のリレーノードは、第２のＬＣＨの設定情報をターゲットドナーノードへ送信する。

【0270】

たとえば、第１のリレーノードは、第４のメッセージをターゲットドナーノードへ送信し、この第４のメッセージは第２のＬＣＨの設定情報を含む。次に、ターゲットドナーノードは、第２のメッセージをソースドナーノードへ送信し、ソースドナーノードは、第３のメッセージを端末へ送信する。第２のメッセージおよび第３のメッセージの内容については、前述の説明を参照されたい。

【0271】

Ｓ１００が存在する場合、第１のリレーノードがターゲットドナーノードとの接続を確立した後に、第１のリレーノードはまず、ターゲットドナーノードから、第１のインジケーション情報を搬送する第１のメッセージを受信してよく、次に、第１のリレーノードは、第４のメッセージをターゲットドナーノードへ送信する、と理解されてよい。

【0272】

任意選択で、第１のメッセージはＵＥコンテキストセットアップ要求メッセージであってもよく、第４のメッセージはＵＥコンテキストセットアップ応答メッセージであってもよい。

【0273】

任意選択で、Ｓ１００は存在しないことがある。第１のリレーノードが第１のメッセージをターゲットドナーノードから受信した後に、第１のリレーノードは、第２のＬＣＨの設定情報を生成し、次に、第１のリレーノードは、第４のメッセージをターゲットドナーノードへ送信する。詳細については、前述の内容を参照されたい。

【0274】

任意選択で、第４のメッセージは、第１のベアラのエアインターフェース設定情報をさらに含むことがあり、それにより、ターゲットドナーノードによって端末へソースドナーノードを介して転送される第３のメッセージは、第１のベアラのエアインターフェース設定情報を含み得る。

【0275】

任意選択で、第４のメッセージは、第１のベアラのエアインターフェース設定情報を含まなくてもよい。ソースドナーノードが、移行リレーノード（すなわち、第１のリレーノードまたは第２のリレーノード）をソースドナーノードからターゲットドナーノードへハンドオーバすることを決定した後に、ソースドナーノードは、移行リレーノードの子孫ノードのコンテキストをターゲットドナーノードへ送信してもよく、この子孫ノードは端末を含み、移行リレーノードの子孫ノードのコンテキストは端末のコンテキストを含み、端末のコンテキストは、ソースドナーノードに対応するＰＤＣＰ設定情報、および第１のＤＲＢのエアインターフェース設定情報を含む。したがって、ターゲットドナーノードは、ソースドナーノードに対応するＰＤＣＰ設定情報、および第１のＤＲＢのエアインターフェース設定情報を取得し得る。

【0276】

別の実装では、第１のリレーノードがターゲットドナーノードとの接続を確立する前に、第１のリレーノードは、第２のＬＣＨの設定情報をソースドナーノードへ送信し、次に、ソースドナーノードは、第２のＬＣＨの設定情報をターゲットドナーノードへ送信する。

【0277】

第１のリレーノードがターゲットドナーノードとの接続を確立していないので、第１のリレーノードは、情報をターゲットドナーノードへ直接送信できず、情報をターゲットドナーノードへソースドナーノードを介して送信し得ると理解されてよい。

【0278】

たとえば、第１のリレーノードは、第５のメッセージをソースドナーノードへ送信し、ソースドナーノードは、第６のメッセージをターゲットドナーノードへ送信し、この第５のメッセージおよび第６のメッセージは、第２のＬＣＨの設定情報を含む。次に、ターゲットドナーノードは、第２のメッセージをソースドナーノードへ送信し、ソースドナーノードは、第３のメッセージを端末へ送信する。第２のメッセージおよび第３のメッセージの内容については、前述の内容を参照されたい。

【0279】

Ｓ１００が存在する場合、第１のリレーノードがターゲットドナーノードとの接続を確立する前に、第１のリレーノードはまず、ソースドナーノードから、第１のインジケーション情報を搬送する第１のメッセージを受信してよく、次に、第５のメッセージをソースドナーノードへ送信し、ソースドナーノードは、第６のメッセージをターゲットドナーノードへ送信する、と理解されてよい。

【0280】

具体的には、ソースドナーノードが、第１のリレーノードまたは第２のリレーノードがハンドオーバを実施すべきであると決定すると、ソースドナーノードは第１のメッセージを第１のリレーノードへ送信し、次に、第１のリレーノードは第５のメッセージをソースドナーノードへ送信し、それにより、ソースドナーノードは第６のメッセージをターゲットドナーノードへ送信する。

【0281】

任意選択で、第１のメッセージはＵＥコンテキスト修正要求メッセージであってもよく、第５のメッセージはＵＥコンテキスト修正応答メッセージであってもよく、第６のメッセージはハンドオーバ要求メッセージであってもよい。

【0282】

任意選択で、第５のメッセージは第１のベアラのエアインターフェース設定情報を含み得る。代替として、第５のメッセージは第１のベアラのエアインターフェース設定情報を含まなくてもよく、ソースドナーノードは第１のベアラのエアインターフェース設定情報を有する。たとえば、端末がソースドナーノードとの接続を確立する前に、ソースドナーノードは、第１のベアラのエアインターフェース設定情報を第１のリレーノードから受信し、その第１のベアラのエアインターフェース設定情報を記憶する。

【0283】

任意選択で、第６のメッセージは、第１のベアラのエアインターフェース設定情報および／またはソースドナーノードに対応するＰＤＣＰ設定情報を含み得る。任意選択で、第６のメッセージは、ソースドナーノードが移行リレーノード（すなわち、第１のリレーノードまたは第２のリレーノード）をソースドナーノードからターゲットドナーノードへハンドオーバすることを決定した後に、ソースドナーノードによってターゲットドナーノードへ送信されてよい。

【0284】

Ｓ１０３：端末は、第２のインジケーション情報を受信する。

【0285】

端末は、第２のインジケーション情報に基づいて、第１のベアラに対する第２のＬＣＨを構成し得る。

【0286】

第２のインジケーション情報によって示される複数の種類の内容があり得る。以下では、いくつかの例を参照して説明をする。

【0287】

例では、第２のインジケーション情報はベアラ粒度であってよい。言い換えると、第２のインジケーション情報は、１つのベアラと１対１の対応関係にある。第２のインジケーション情報は、第１のＬＣＨおよび第２のＬＣＨを１つのベアラに対して構成するように端末に示してもよく、第２のＬＣＨを１つのベアラに対して構成するように端末に示してもよく、１つのベアラを２つのＬＣＨと、すなわち第１のＬＣＨおよび第２のＬＣＨと関連付けることを示してもよく、１つのベアラの第１のＬＣＨと第２のＬＣＨの両方がベアラのデータ伝送に用いられることを示してもよく、１つのベアラの第１のＬＣＨをそのベアラの第２のＬＣＨと置き換えないように端末に示してもよく、ＰＤＣＰデュアル設定の機能を１つのベアラに対して開始または起動するように端末に示してもよく、このＰＤＣＰデュアル設定は、ソースドナーノードに対応するＰＤＣＰ設定情報、およびターゲットドナーノードに対応するＰＤＣＰ設定情報を含むことがあり、１つのベアラのデータ伝送がドナーノード間ハンドオーバ中に中断されるべきでないことを示すことがあり、ＤＡＰＳハンドオーバが１つのベアラに対して構成されるべきであることを示すことがあり、または他の内容を示すことがある。これは、本出願のこの実施形態では限定されていない。

【0288】

この例では、任意選択で、第２のインジケーション情報は１つのベアラの識別子を含むことがあり、このベアラは第１のベアラを含む。

【0289】

この例では、第１のリレーノードは複数の第２のインジケーション情報を受信し、第２のインジケーション情報のそれぞれは、１つのベアラと１対１の対応関係にある。第１のリレーノードは、端末の１つまたは複数のベアラごとに、そのベアラに対応する第２のＬＣＨを構成し得る。本出願では、第１のベアラが説明のための例として用いられている。当業者であれば、本出願のこの実施形態における内容が、他の１つまたは複数のベアラの場合にもまた適用可能であることを知り得る。

【0290】

別の例では、第２のインジケーション情報は端末粒度であってよい。言い換えると、第２のインジケーション情報は特定のベアラを示さない。第２のインジケーション情報は、第１のリレーノードが第１のＬＣＨおよび第２のＬＣＨを端末のベアラごとに構成することを示し、第２のＬＣＨをベアラごとに構成するように端末に示し、各ベアラを２つのＬＣＨと関連付けることを示し、または各ベアラの第１のＬＣＨをベアラの第２のＬＣＨと置き換えないことなどを示し得る。第２のインジケーション情報によって示され得る他の内容については、第２のインジケーション情報が端末粒度であってよい場合に説明される内容を参照されたい。第２のインジケーション情報によって示される対象が端末または端末の各ベアラである点に、相違がある。代替として、第２のインジケーション情報は、端末のデータ伝送がドナーノード間ハンドオーバ中に中断されるべきでないことを示してもよく、ＤＡＰＳハンドオーバが行われるべきことを示してもよく、または他の内容を示してもよい。これは、本出願のこの実施形態では限定されていない。

【0291】

この例では、任意選択で、第２のインジケーション情報はベアラの識別子を含まないことがある。

【0292】

この例では、第１のリレーノードは、第２のＬＣＨを端末のベアラ（第１のベアラを含む）ごとに構成してもよい。本出願では、第１のベアラが説明のための例として用いられている。当業者であれば、本出願のこの実施形態における内容が、他の１つまたは複数のベアラの場合にもまた適用可能であることを知り得る。この場合、Ｓ１０２で、端末は、１つまたは複数の他のベアラのそれぞれに対応する第２のＬＣＨの設定情報を受信し得る。

【0293】

端末が第２のインジケーション情報を受信する複数の手法がある。以下では、いくつかの可能な実装を参照して説明をする。

【0294】

可能な実装では、ターゲットドナーノードは、第２のインジケーション情報を端末へ第１のリレーノードを介して送信する。

【0295】

この実装では、第２のインジケーション情報はターゲットドナーノードによって生成される。

【0296】

この実装では、第２のインジケーション情報と、Ｓ１０２でターゲットドナーノードによって端末へ送信される第２のＬＣＨの設定情報とは、単一のメッセージで搬送され得る。たとえば、メッセージはＳ１０２での第３のメッセージであり、この第３のメッセージは、第１のベアラのエアインターフェース設定情報、ソースドナーノードに対応するＰＤＣＰ設定情報、およびターゲットドナーノードに対応するＰＤＣＰ設定情報、およびターゲットドナーノードによって第１のリレーノードに割り当てられたＢＡＰアドレスのうちの１つまたは複数をさらに含み得る。詳細については、Ｓ１０２での、リレーノードが第２のＬＣＨの設定情報を端末へターゲットドナーノードを介して送信する処理を参照されたい。

【0297】

別の実装では、第１のリレーノードは、第２のインジケーション情報を端末へ送信する。

【0298】

この実装では、第２のインジケーション情報は、第１のリレーノードによって生成される。

【0299】

任意選択で、第１のリレーノードが第２のＬＣＨの設定情報を生成する場合、第１のリレーノードは、第２のインジケーション情報を生成し、次に、第２のインジケーション情報を端末へ送信してもよい。

【0300】

たとえば、第２のインジケーション情報はＭＡＣ ＣＥで搬送されてもよい。

【0301】

さらに別の実装では、第２のインジケーション情報は、ソースドナーノードによって端末へ送信されることがある。これは、本出願のこの実施形態では限定されていない。

【0302】

端末は、第２のインジケーション情報を受信して、端末が第２のＬＣＨの設定情報を受信し、第１のＬＣＨの設定情報が削除される必要があると誤って見なす状況を、第１のＬＣＨと第２のＬＣＨの両方が端末の第１のベアラに対して構成され、ドナーノード間ハンドオーバ中のデータ伝送中断の確率を低減し、かつサービス連続性を改善できることを確実にするように、回避する。

【0303】

Ｓ１０３は任意選択である。

【0304】

Ｓ１０４：端末は、第１のベアラに対して第２のＬＣＨを構成する。

【0305】

任意選択で、Ｓ１０４の後に、端末は、第１のＬＣＨを介して、ソースドナーノードに対応するＰＤＣＰデータを送信してもよく、また、端末は、第２のＬＣＨを介して、ターゲットドナーノードに対応するＰＤＣＰデータを送信してもよい。以下では、いくつかの実装を参照して説明をする。

【0306】

任意選択で、図１３の方法は以下をさらに含むことができる。ターゲットドナーノードは、アクセスリレーノードと移行リレーノードの間のリンク上の１つまたは複数のノード（アクセスリレーノード、移行リレーノード、およびアクセスリレーノードと移行リレーノードの間の１つまたは複数の他のノードを含む）へ、ソースドナーノードを介して、ＢＡＰ層のデュアル設定を開始するためのインジケーションを送信し、このＢＡＰ層のデュアル設定は、ソースドナーノードに対応するＢＡＰ設定およびターゲットドナーノードに対応するＢＡＰ設定を含む。詳細については、図１２の内容を参照されたい。詳細は、本明細書では再度説明されない。代替として、ソースドナーノードは、１つまたは複数のノードへ、ＢＡＰ層のデュアル設定を開始するためのインジケーションを送信してもよい。

【0307】

任意選択で、図１３の方法では、ソースドナーノードに対応するＰＤＣＰデータは、ダウンリンクＰＤＣＰデータおよび／またはアップリンクＰＤＣＰデータを含む。任意選択で、ターゲットドナーノードに対応するＰＤＣＰデータは、ダウンリンクＰＤＣＰデータおよび／またはアップリンクＰＤＣＰデータを含む。

【0308】

任意選択で、ソースドナーノードに対応するＰＤＣＰデータは、ソースドナーノードに対応するＰＤＣＰ設定情報を用いて処理され、ソースドナーノードまたは端末によって特に処理されてもよい。ターゲットドナーノードに対応するＰＤＣＰデータは、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いて処理され、ターゲットドナーノードまたは端末によって特に処理されてもよい。

【0309】

任意選択で、端末の第１のベアラのＰＤＣＰエンティティは、ソースドナーノードに対応する設定情報およびターゲットドナーノードに対応する設定情報を含む。詳細については、図１２の内容を参照されたい。詳細は、本明細書では再度説明されない。

【0310】

ソースドナーノードに対応するＰＤＣＰデータがダウンリンクＰＤＣＰデータである場合に、第１のＬＣＨが、ソースドナーノードに対応するＰＤＣＰデータを伝送するためのものであることは、第１のＬＣＨが、ソースドナーノードに対応するダウンリンクＰＤＣＰデータを受信するためのものであると理解されてよい。同様に、ターゲットドナーノードに対応するＰＤＣＰデータがダウンリンクＰＤＣＰデータである場合に、第２のＬＣＨが、ターゲットドナーノードに対応するＰＤＣＰデータを伝送するためのものであることは、第２のＬＣＨが、ターゲットドナーノードに対応するＰＤＣＰデータを受信するためのものであると理解されてよい。

【0311】

例では、ソースドナーノードは、ソースドナーノードに対応するＰＤＣＰ設定情報を用いてダウンリンクＰＤＣＰデータを処理し、そのダウンリンクＰＤＣＰデータを第１のリレーノードへ送信する。第１のリレーノードは、第１のＬＣＨへ、ソースドナーノードに対応するダウンリンクＰＤＣＰデータをマッピングし、そのダウンリンクＰＤＣＰデータを端末へ送信する。端末は、第１のリレーノードから、ソースドナーノードに対応するとともに第１のＬＣＨにマッピングされているダウンリンクＰＤＣＰデータを受信し得る（これは端末が、第１のＬＣＨを介して、ソースドナーノードに対応するダウンリンクＰＤＣＰデータを受信すると理解されてよい）。端末は、ソースドナーノードに対応するＰＤＣＰ設定情報を用いて、ソースドナーノードに対応するダウンリンクＰＤＣＰデータを処理する。

【0312】

別の例では、ターゲットドナーノードは、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてダウンリンクＰＤＣＰデータを処理し、そのダウンリンクＰＤＣＰデータを第１のリレーノードへ送信する。第１のリレーノードは、第２のＬＣＨへ、ターゲットドナーノードに対応するダウンリンクＰＤＣＰデータをマッピングし、そのダウンリンクＰＤＣＰデータを端末へ送信する。端末は、第１のリレーノードから、ターゲットドナーノードに対応するとともに第２のＬＣＨにマッピングされているダウンリンクＰＤＣＰデータを受信する（これは端末が、第２のＬＣＨを介して、ターゲットドナーノードに対応するダウンリンクＰＤＣＰデータを受信すると理解されてよい）。端末は、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いて、ターゲットドナーノードに対応するダウンリンクＰＤＣＰデータを処理する。

【0313】

ダウンリンクデータについては、前述の２つの例のうちの１つだけがあることも、前述の２つの例の両方があることもある。任意選択で、ダウンリンクデータについて、ドナーノード間ハンドオーバ処理の際に（本出願のこの実施形態では、この処理は、ソースドナーノードがドナーノード間ハンドオーバを実施すると決定した時点から、移行リレーノードのソース親ノードが移行リレーノードのコンテキストを解放する時点までの処理を含む）、ソースドナーノードが端末へ、ソースドナーノードに対応するダウンリンクＰＤＣＰデータを送信する時点が、ターゲットドナーノードが端末へ、ターゲットドナーノードに対応するダウンリンクＰＤＣＰデータを送信し得る時点と重なることがあり、言い換えると、端末は、ソースドナーノードに対応するダウンリンクＰＤＣＰデータと、ターゲットドナーノードに対応するダウンリンクＰＤＣＰデータとを同時に受信することがある。

【0314】

ソースドナーノードに対応するＰＤＣＰデータがアップリンクＰＤＣＰデータである場合に、第１のＬＣＨが、ソースドナーノードに対応するＰＤＣＰデータを伝送するためのものであることは、第１のＬＣＨが、ソースドナーノードに対応するアップリンクＰＤＣＰデータを送信するためのものであると理解されてよい。同様に、ターゲットドナーノードに対応するＰＤＣＰデータがアップリンクＰＤＣＰデータである場合に、第２のＬＣＨが、ターゲットドナーノードに対応するＰＤＣＰデータを伝送するためのものであることは、第２のＬＣＨが、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを送信するためのものであると理解されてよい。

【0315】

例では、端末は、ソースドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理して、ソースドナーノードに対応するアップリンクＰＤＣＰデータを取得し、ソースドナーノードに対応するアップリンクＰＤＣＰデータを第１のＬＣＨにマッピングし、また、第１のリレーノードへ、ソースドナーノードに対応するとともに第１のＬＣＨにマッピングされているアップリンクＰＤＣＰデータを送信する（これは端末が、第１のＬＣＨを介して、ソースドナーノードに対応するアップリンクＰＤＣＰデータを送信すると理解されてよい）。ソースドナーノードに対応するとともに第１のＬＣＨにマッピングされているアップリンクＰＤＣＰデータを受信した後に、第１のリレーノードは、アップリンクＰＤＣＰデータをソースドナーノードへ送信する。最後に、ソースドナーノードは、ソースドナーノードに対応する設定情報を用いて、アップリンクＰＤＣＰデータを処理する。

【0316】

別の例では、端末は、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理して、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを取得し、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを第２のＬＣＨにマッピングし、第１のリレーノードへ、ターゲットドナーノードに対応するとともに第２のＬＣＨにマッピングされているアップリンクＰＤＣＰデータを送信する（これは端末が、第２のＬＣＨを介して、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを送信すると理解されてよい）。ターゲットドナーノードに対応し第２のＬＣＨにマッピングされているアップリンクＰＤＣＰデータを受信した後に、第１のリレーノードは、アップリンクＰＤＣＰデータをターゲットドナーノードへ送信する。最後に、ターゲットドナーノードは、ターゲットドナーノードに対応する設定情報を用いて、アップリンクＰＤＣＰデータを処理する。

【0317】

任意選択で、ダウンリンクデータに関して、第１のリレーノードは、ダウンリンクデータ伝送に用いられるＧＴＰ－Ｕトンネルに基づいて、ソースドナーノードに対応するダウンリンクＰＤＣＰデータと、ターゲットドナーノードに対応するダウンリンクＰＤＣＰデータとを区別し得る。代替として、第１のリレーノードは、ダウンリンクデータで搬送されるＢＡＰアドレスに基づいて、ソースドナーノードに対応するダウンリンクＰＤＣＰデータと、ターゲットドナーノードに対応するダウンリンクＰＤＣＰデータとを区別し得る。

【0318】

アップリンクデータについては、前述の２つの例のうちの１つだけがあることも、前述の２つの例の両方があることもある。任意選択で、アップリンクデータに関して、ドナーノード間ハンドオーバ中に、端末がソースドナーノードへ、ソースドナーノードに対応するアップリンクＰＤＣＰデータを送信する時点が、端末がターゲットドナーノードへ、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを送信する時点と交互に配置されることがあり、言い換えると、端末は、時に、ソースドナーノードへ、ソースドナーノードに対応するアップリンクＰＤＣＰデータを送信する、または、ターゲットドナーノードへ、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを送信することがある。

【0319】

ダウンリンクデータおよびアップリンクデータの伝送処理については、図１２の内容を参照されたい。詳細は、本明細書では再度説明されない。

【0320】

加えて、移行リレーノード（すなわち、第１のリレーノードまたは第２のリレーノード）がターゲットドナーノードとの接続を確立する前に、端末は、アップリンクデータをソースドナーノードへ送信する。移行リレーノードがターゲットドナーノードとの接続を確立した後に、端末は、アップリンクデータをターゲットドナーノードへ送信する。しかし、端末は、移行リレーノードがターゲットドナーノードとの接続を確立する時点を検知しない。その結果、端末は、ソースドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクＰＤＣＰデータを処理し、そのアップリンクＰＤＣＰデータをソースドナーノードへ送信すべきか、それとも、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクＰＤＣＰデータを処理し、そのアップリンクＰＤＣＰデータをターゲットドナーノードへ送信すべきかを決定することができない。本出願の実施形態は、端末が正しい設定情報を用いてアップリンクデータを処理し、パケットロスによって引き起こされるサービス中断を回避することを確実にするための以下のソリューションを提供する。

【0321】

図１４は、本出願の実施形態によるインジケーション方法のフローチャートである。図１４の方法は、独立して実施されてもよいし、図１３の方法に基づいて実施されてもよい。図１３と図１４の内容は、相互に参照されることがある。

【0322】

図１４の方法では、第１のＬＣＨおよび第２のＬＣＨは、端末の第１のベアラに対して構成される。第１のＬＣＨは、ソースドナーノードに対応するＰＤＣＰデータを伝送するためのものであり、第２のＬＣＨは、ターゲットドナーノードに対応するＰＤＣＰデータを伝送するためのものである。第１のＬＣＨ、第２のＬＣＨ、および第２のＬＣＨを構成する手法については、図１３の内容を参照されたい。

【0323】

図１４に示されるように、図１４の方法は以下のステップを含む。

【0324】

Ｓ２００：端末が第３のインジケーション情報を受信する。端末は、第３のインジケーション情報に基づいて、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理することを決定し得る。

【0325】

任意選択で、第３のインジケーション情報は、データをターゲットドナーノードへ送信するように端末に示してよく、ターゲットドナーノードに対応する設定情報を用いてデータを処理することを端末に示してよく、移行リレーノードがターゲット親ノードにアクセスしたこと、もしくはリレーノードハンドオーバが完了したことを示してよく、または移行リレーノードがＰＵＳＣＨ切り換えを完了したことを示してよい。

【0326】

実装では、ＰＵＳＣＨ切り換えを実施した後に、移行リレーノードは第３のインジケーション情報を端末へ送信する。

【0327】

本出願のこの実施形態では、ＰＵＳＣＨ切り換えを実施することは、移行リレーノードのＰＵＳＣＨをソース親ノードからターゲット親ノードへ切り換えることと理解されてよい。具体的には、移行リレーノードは、元々はＰＵＳＣＨデータ（たとえば、端末のアップリンクＰＤＣＰデータ）をソース親ノードへＰＵＳＣＨを介して送信するが、ここではＰＵＳＣＨデータ（たとえば、端末のアップリンクＰＤＣＰデータ）をターゲット親ノードへＰＵＳＣＨを介して送信する。具体的には、プリアンブルをターゲットドナーノードへ送信し、ターゲットドナーノードによって送信されたランダムアクセス応答（ｒａｎｄｏｍ ａｃｃｅｓｓ ｒｅｓｐｏｎｓｅ、ＲＡＲ）メッセージを受信した後に、移行リレーノードはＰＵＳＣＨ切り換えを実施し、このＲＡＲメッセージはＵＬグラント（ｇｒａｎｔ）リソースを含んでいる。

【0328】

別の実装では、移行リレーノードがターゲットドナーノードに接続された後に、移行リレーノードは第３のインジケーション情報を端末へ送信する。

【0329】

本出願のこの実施形態において、移行リレーノードがターゲットドナーノードに接続されることは、以下を含み得る。Ｆ１インターフェースおよびＧＴＰトンネルが、第１のベアラに対して移行リレーノードとターゲットドナーノードの間で確立され、ならびに／またはルーティング設定およびベアラマッピング設定が、移行リレーノードとターゲットドナーノードの間の経路で完了される。

【0330】

任意選択で、前述の２つの実装において、第３のインジケーション情報は、ダウンリンクデータで搬送されて端末へ送信されてもよく、たとえば、ダウンリンクデータのＭＡＣヘッダフィールドまたはＲＬＣヘッダフィールドで搬送される。代替として、任意選択で、第３のインジケーション情報は、コントロールシグナリングで搬送され、端末へ送信されてもよい。コントロールシグナリングは、ＭＡＣ ＣＥまたはダウンリンクコントロール情報（ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ、ＤＣＩ）であってよい。

【0331】

さらに別の実装では、移行リレーノードのＲＲＣ再設定完了メッセージを受信した後に、ターゲットドナーノードは、第３のインジケーション情報を端末へ送信してもよい。

【0332】

任意選択で、ターゲットドナーノードは、第３のインジケーション情報を端末へＲＲＣメッセージを介して送信してもよい。

【0333】

任意選択で、前述の３つの実装は、端末が第２のＬＣＨの設定情報を、第１のリレーノードがターゲットドナーノードとの接続を確立する前に受信するシナリオに適用され得る。このシナリオでは、移行リレーノードがＰＵＳＣＨ切り換えを実施した後に、または移行リレーノードがターゲットドナーノードとの接続を確立した後に、またはターゲットドナーノードがＲＲＣ再設定完了メッセージを受信した後に、第３のインジケーション情報が端末へ送信されて、以下の状況が回避される。すなわち、端末が第２のＬＣＨの設定情報を受信すると、端末は、ターゲットドナーノードにデフォルトで対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理し、そのアップリンクデータを移行リレーノードに送信するが、移行リレーノードがターゲットドナーノードとの接続を確立していないので、アップリンクデータはソースドナーノードへ送信されることしかできず、ソースドナーノードはアップリンクデータを解析できずに、結果としてアップリンクデータロスが生じる、という状況が回避される。

【0334】

さらに別の実装では、ターゲットドナーノードは、第２のＬＣＨの設定情報と第３のインジケーション情報を一緒に端末へソースドナーノードを介して送信してもよい。たとえば、ターゲットドナーノードは、第２のメッセージをソースドナーノードへ送信し、この第２のメッセージは第３のメッセージを含む。ソースドナーノードは第３のメッセージを端末へ送信し、この第３のメッセージは、第２のＬＣＨの設定情報および第３のインジケーション情報を含む。

【0335】

Ｓ２０１：端末は、第３のインジケーション情報に基づいてアップリンクデータを、ターゲットドナーノードに対応するＰＤＣＰ構成情報を用いて処理する。任意選択で、端末は、第２のＬＣＨに、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータをさらにマッピングし、そのアップリンクＰＤＣＰデータをターゲットドナーノードへ送信してもよい。

【0336】

具体的には、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理した後に、端末は、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを取得し、第２のＬＣＨに、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータをマッピングし、次に、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータを、第２のＬＣＨを介して送信してもよい。ターゲットドナーノードに対応するとともに第２のＬＣＨにマッピングされているアップリンクＰＤＣＰデータを受信した後に、第１のリレーノードは、そのアップリンクＰＤＣＰデータをターゲットドナーノードへ送信する。最後に、ターゲットドナーノードは、ターゲットドナーノードに対応する設定情報を用いて、アップリンクＰＤＣＰデータを処理する。

【0337】

任意選択で、第３のインジケーション情報を受信する前に、端末は、ソースドナーノードに対応するＰＤＣＰ設定情報を用いて、アップリンクＰＤＣＰデータを処理する。第３のインジケーション情報を受信した後に、端末は、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いて、アップリンクＰＤＣＰデータを引き続き処理する。アップリンクＰＤＣＰデータが、ソースドナーノードに対応するＰＤＣＰ設定情報を用いて処理されること、または、アップリンクＰＤＣＰデータが、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いて処理されることの詳細な説明については、図１３の内容を参照されたい。詳細は、本明細書では再度説明されない。

【0338】

図１４の方法では、ドナーノード間ハンドオーバ中に、端末の親ノードは常に変化しないままであることがあり、端末は、移行リレーノードがＰＵＳＣＨ切り換えを実施するときを検知しない。第３のインジケーション情報は端末へ送信され、それにより、端末は、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理することを決定して、端末が正しい設定情報を用いてアップリンクデータを処理することを確実にすること、パケットロスによって引き起こされるサービス中断を回避すること、およびサービス伝送継続性を改善することができる。

【0339】

任意選択で、Ｓ２００およびＳ２０１の別の代替実装では、Ｓ２００およびＳ２０１が存在しなくてもよい。第２のＬＣＨの設定情報を受信した後に、端末はＳ２０２を実施し、具体的には、端末は、ターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理し、第２のＬＣＨに、ターゲットドナーノードに対応するアップリンクＰＤＣＰデータをマッピングし、そのアップリンクＰＤＣＰデータをターゲットドナーノードへ送信する。

【0340】

任意選択で、この実装は、端末が第２のＬＣＨの設定情報を、第１のリレーノードがターゲットドナーノードとの接続を確立した後に受信するシナリオに適用され得る。このシナリオでは、端末が第２のＬＣＨの設定情報を受信すると、端末は、ターゲットドナーノードにデフォルトで対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理し、そのアップリンクデータをターゲットドナーノードへ送信して、サービス伝送の連続性を確保し、シグナリングオーバヘッドを低減させる。

【0341】

図１５は、本出願の実施形態によるＬＣＨ削除方法のフローチャートである。図１５の方法は、独立して実施されてもよいし、図１３および図１４の方法のうちの１つまたは両方に基づいて実施されてもよい。図１３、図１４および図１５の内容は、相互に参照されることがある。

【0342】

図１５の方法では、第１のＬＣＨおよび第２のＬＣＨは、端末の第１のベアラに対して構成される。第１のＬＣＨは、ソースドナーノードに対応するＰＤＣＰデータを伝送するためのものであり、第２のＬＣＨは、ターゲットドナーノードに対応するＰＤＣＰデータを伝送するためのものである。第１のＬＣＨの内容、第２のＬＣＨ、および第２のＬＣＨを構成する手法については、図１４の内容を参照されたい。

【0343】

図１５に示されるように、図１５の方法は以下のステップを含む。

【0344】

Ｓ３０１：第１のリレーノードは、第４のインジケーション情報をターゲットドナーノードへ送信する。

【0345】

第４のインジケーション情報は、ターゲットドナーノードによって用いられて、第１のＬＣＨを削除するように端末に示すものである。

【0346】

実装では、第１のリレーノードが、ソースドナーノードに対応するとともに第１のリレーノードによってバッファリングされているＰＤＣＰデータを端末へ送信することを完了した後に、第１のリレーノードは、第４のインジケーション情報をターゲットドナーノードへ送信する。

【0347】

ソースドナーノードに対応するとともに第１のリレーノードによってバッファリングされているＰＤＣＰデータは、伝送のために端末の第１のＬＣＨにマッピングされるものであり、したがって、第１のＬＣＨに対応するＰＤＣＰデータと呼ばれることもある。

【0348】

この実装では、任意選択で、Ｓ３０１の前に、方法は以下をさらに含む。第１のリレーノードは、第７のメッセージを受信し、この第７のメッセージは、第１のリレーノードとソースドナーノードの間のＦ１インターフェースおよび／またはＧＴＰ－Ｕトンネルを削除するためのものである。第１のリレーノードが第７のメッセージを受信し、ソースドナーノードに対応するとともに第１のリレーノードによってバッファリングされているＰＤＣＰデータを端末へ送信することを完了した後に、第１のリレーノードは、第４のインジケーション情報をターゲットドナーノードへ送信する。

【0349】

例では、この方法は以下をさらに含む。ターゲットドナーノードは、第８のメッセージをソースドナーノードへ送信して、第７のメッセージを第１のリレーノードへ送信するようにソースドナーノードをトリガする。たとえば、第７のメッセージおよび第８のメッセージは、ＵＥコンテキスト解放メッセージであってよい。

【0350】

任意選択で、第７のメッセージは、第１のＬＣＨのＩＤ、および／または第１のリレーノードとソースドナーノードの間のＧＴＰ－Ｕトンネルを削除するように第１のリレーノードに示すためのインジケーション情報を含み得る。

【0351】

任意選択で、第１のリレーノードが、ソースドナーノードに対応するとともに第１のリレーノードによってバッファリングされているＰＤＣＰデータを端末へ送信することを完了することは、第１のリレーノードが、ソースドナーノードに対応するとともに第１のリレーノードによってバッファリングされているＰＤＣＰデータのすべてを端末へ送信したこと、またはソースドナーノードに対応するＰＤＣＰデータが第１のリレーノードでバッファリングされていないこと、または第１のリレーノードで第１のＬＣＨに対応するバッファ（ｂｕｆｆｅｒ）が空であることと理解されてよい。

【0352】

任意選択で、第４のインジケーション情報によって示される内容には複数の状況があり得る。たとえば、第４のインジケーション情報は、第１のＬＣＨを削除することを示してよく、第１のリレーノードが、第１のＬＣＨに対応するとともに第１のリレーノードによってバッファリングされているＰＤＣＰデータを端末へ送信することを完了していることを示してよく、第１のリレーノードで第１のＬＣＨに対応するバッファが空であることを示してよく、または他の内容を示してよい。これは、本出願のこの実施形態では限定されていない。任意選択で、第４のインジケーション情報は、第１のＬＣＨのＩＤおよび／または第１のベアラの識別子を含み得る。

【0353】

任意選択で、第４のインジケーション情報は、ＵＥコンテキスト修正要求（ｒｅｑｕｉｒｅｄ）メッセージで搬送されてよい。Ｓ３０２：ターゲットドナーノードは、第５のインジケーション情報を第１のリレーノードへ送信する。

【0354】

第４のインジケーション情報を受信した後に、ターゲットドナーノードは第５のインジケーション情報を決定し得る。

【0355】

任意選択で、第５のインジケーション情報と第４のインジケーション情報は、同じであっても異なっていてもよい。

【0356】

任意選択で、第５のインジケーション情報によって示される内容には複数の状況があり得る。たとえば、第５のインジケーション情報は、第１のＬＣＨを削除するように端末に示してよく、ＰＤＣＰデュアル設定の機能を解放するように端末に示してよく、ソースドナーノードに対応するＰＤＣＰ設定情報を削除するように端末に示してよく、または他の内容を示してもよい。これは、本出願のこの実施形態では限定されていない。

【0357】

任意選択で、第５のインジケーション情報は、ＲＲＣメッセージで搬送されてよい。ＲＲＣメッセージは、ＵＥコンテキスト修正要求（ｒｅｑｕｅｓｔ）メッセージで搬送される。ＵＥコンテキスト修正要求メッセージは、Ｆ１ＡＰメッセージであってよい。

【0358】

任意選択で、第５のインジケーション情報は、第１のＬＣＨのＩＤおよび／または第１のベアラの識別子を含み得る。

【0359】

Ｓ３０３：第１のリレーノードは、第５のインジケーション情報を端末へ送信する。

【0360】

任意選択で、Ｓ３０３は以下でもよい。第１のリレーノードは、ＲＲＣメッセージを端末へ送信する。

【0361】

Ｓ３０４：端末は、第５のインジケーション情報に基づいて第１のベアラの第１のＬＣＨを削除する。

【0362】

任意選択で、第５のインジケーション情報が第１のＬＣＨのＩＤを含む場合には、端末は、第５のインジケーション情報に基づいて第１のＬＣＨを削除する。

【0363】

任意選択で、第５のインジケーション情報が第１のＬＣＨのＩＤを含まない場合には、第５のインジケーション情報を受信した後に、端末は、第１のＬＣＨをデフォルトで削除してもよく、すなわち、ソースドナーノードに対応するＬＣＨをデフォルトで削除してもよい。

【0364】

任意選択で、図１５の方法は、以下をさらに含み得る。第１のリレーノードは、第１のＬＣＨの設定情報を削除し、第１のリレーノードとソースドナーノードの間のＦ１インターフェースおよびＧＴＰ－Ｕトンネルのうちの一方または両方を削除する、などを行う。例では、Ｓ３０２またはＳ３０３の後、第１のリレーノードは以下の動作、すなわち、第１のＬＣＨの設定情報の削除、第１のリレーノードとソースドナーノードの間のＦ１インターフェースの削除、第１のリレーノードとソースドナーノードの間のＧＴＰ－Ｕトンネルの削除、などのうちの１つまたは複数を実施し得る。Ｓ３０２または３０３の後に、第１のリレーノードは、端末とソースドナーノードの間でメッセージまたはデータを伝送する必要がもはやなく、第１のリレーノードは、第１のＬＣＨの設定情報を削除し、第１のリレーノードとソースドナーノードの間のＦ１インターフェース、および／または第１のリレーノードとソースドナーノードの間のＧＴＰ－Ｕトンネルを削除してリソースを節約する、と理解されてよい。代替として、別の例では、Ｓ３０２の前に、第１のリレーノードは以下の動作、すなわち、第１のリレーノードとソースドナーノードの間のＦ１インターフェースの削除、第１のリレーノードとソースドナーノードの間のＧＴＰ－Ｕトンネルの削除、などのうちの１つまたは複数を実施し得る。

【0365】

図１５の方法では、端末は、ネットワーク側のインジケーションに応じて第１のＬＣＨを削除して、エアインターフェースリソースを節約し得る。加えて、第１のリレーノードが、ソースドナーノードに対応するとともに第１のリレーノードによってバッファリングされているＰＤＣＰデータを端末へ送信することを完了した後に、第１のリレーノードは、第４のインジケーション情報をターゲットドナーノードへ送信し、さらに、ターゲットドナーノードは、第１のＬＣＨを削除するように端末に示し、それにより、端末が第１のＬＣＨを、ソースドナーノードに対応するＰＤＣＰデータのすべてが第１のＬＣＨを介して端末へ送信された後にようやく削除して、データ伝送連続性が確保されるとともに、データ伝送中断（第１のＬＣＨが削除された後に端末が、ソースドナーノードに対応するＰＤＣＰデータを依然として受信するけれども、ソースドナーノードに対応するＰＤＣＰデータを処理または解析することはできないために引き起こされる）が回避される。

【0366】

図１６は、本出願の実施形態によるインジケーション方法の流れ図である。図１６の方法は、独立して実施されることもあるし、図１３、図１４、および図１６の方法のうちの１つまたは複数に基づいて実施されることもある。図１３から図１６の内容は、相互に参照され得る。図１６に示されるように、この方法は、以下のステップを含む。

【0367】

Ｓ４０１：ソースドナーノードは、能力インジケーション情報をターゲットドナーノードへ送信する。

【0368】

任意選択で、能力インジケーション情報は、移行リレーノードが能力をサポートすることを示す。例えば、能力インジケーション情報は、移行リレーノードがハンドオーバ中にソースドナーノードへの接続を維持することをサポートすることを示すか、移行リレーノードがハンドオーバ中にソースドナーノードおよびターゲットドナーノードの両方への接続を維持することをサポートすることを示すか、移行リレーノードがＤＡＰＳをサポートすることを示し得るか、移行リレーノードがハンドオーバ中に並列ＰＤＳＣＨデータ伝送をサポートすることを示し得るか、移行リレーノードがハンドオーバ中に並列ＰＵＳＣＨデータ伝送をサポートすることを示し得るか、または他の内容を示すことがある。これは、本出願のこの実施形態では限定されない。

【0369】

本明細書では、能力インジケーション情報が移行リレーノードの粒度である例が説明のために用いられることに留意されたい。当業者なら、本明細書における能力インジケーション情報は、あるいは端末のベアラの粒度であることもあることを理解し得る。例えば、能力インジケーション情報は、端末の第１のベアラがハンドオーバ中にＤＡＰＳ、並列ＰＤＳＣＨ伝送、またはＰＵＳＣＨ伝送などをサポートすることを示すこともある。これは、本出願のこの実施形態では限定されない。

【0370】

任意選択で、能力インジケーション情報は、ソースドナーノードによって生成されることもある。

【0371】

任意選択で、能力インジケーション情報は、移行リレーノードによってソースドナーノードへ送信されることもある。

【0372】

例では、能力インジケーション情報は、ソースドナーノードによってターゲットドナーノードへ送信されるハンドオーバ要求メッセージで搬送されることがある。

【0373】

任意選択で、この例では、ハンドオーバ要求メッセージは、移行リレーノードおよび移行リレーノードの子孫ノードのコンテキスト情報をさらに含むこともある。移行リレーノードおよび子孫ノードのコンテキスト情報は、移行リレーノードおよび子孫ノードによってアクセスされるリレーノードの識別子（例えばＩＡＢ－ＤＵ ｉｄ）、移行リレーノードおよび子孫ノードによってアクセスされるリレーノード識別子（例えばセルグローバル識別子（ｃｅｌｌ ｇｒｏｕｐ ｉｄｅｎｔｉｆｉｅｒ、ＣＧＩ））、ならびにアクセスされたセルにおける移行リレーノードおよび子孫ノードのセル無線ネットワーク一時識別子（ｃｅｌｌ ｒａｄｉｏ ｎｅｔｗｏｒｋ ｔｅｍｐｏｒａｒｙ ｉｄｅｎｔｉｆｉｅｒ、Ｃ－ＲＮＴＩ）のうちの１つまたは複数を含む。

【0374】

任意選択で、ハンドオーバ要求メッセージは、グループハンドオーバについてのハンドオーバ要求メッセージであることもある。グループハンドオーバは、移行リレーノードがハンドオーバを実施するときに、移行リレーノードの子孫ノードが移行リレーノードとともにハンドオーバを実施することとして理解され得る。移行リレーノードと子孫ノードとは、グループとして見なされ得、このグループが、ハンドオーバを実施する。

【0375】

Ｓ４０１は、任意選択である。

【0376】

Ｓ４０２：ターゲットドナーノードは、第６のインジケーション情報をソースドナーノードへ送信する。

【0377】

例では、第６のインジケーション情報は、ＲＲＣ再構成メッセージで搬送され、ＲＲＣ再構成メッセージは、ターゲットドナーノードによってソースドナーノードへ送信されるハンドオーバ要求応答メッセージで搬送される。ターゲットドナーノードがハンドオーバ要求応答メッセージをソースドナーノードへ送信することは理解され得る。ハンドオーバ要求応答メッセージは、ＲＲＣ再構成メッセージを含み、ＲＲＣ再構成メッセージは、第６のインジケーション情報を含む。

【0378】

任意選択で、Ｓ４０１が存在するときには、ターゲットドナーノードは、能力インジケーション情報に基づいて第６のインジケーション情報を決定する。Ｓ４０２が存在しないときには、ターゲットドナーノードは、移行リレーノードが能力インジケーション情報によって示される能力を有するとデフォルトでみなして、第６のインジケーション情報を生成する。

【0379】

任意選択で、第６のインジケーション情報によって示される内容については、複数の場合があり得る。例えば、第６のインジケーション情報は、移行リレーノードがハンドオーバ中にソースドナーノードへの接続を維持することを示し得るか、移行リレーノードがハンドオーバ中にソースドナーノードおよびターゲットドナーノードの両方への接続を維持することを示し得るか、ソースドナーノードがハンドオーバ中にソースドナーノードに対応するＰＤＣＰデータを移行リレーノードへ送信することになることを示し得るか、移行リレーノードがＤＡＰＳを開始することを示し得るか、移行リレーノードがハンドオーバ中に並列ＰＤＳＣＨデータ伝送を実施することを示し得るか、移行リレーノードがハンドオーバ中に並列ＰＵＳＣＨデータ伝送を実施することを示し得るか、または他の内容を示すことがある。これは、本出願のこの実施形態では限定されない。本出願におけるハンドオーバプロセスは、移行リレーノードがソースドナーノードからＲＲＣ再構成メッセージを受信する時点から、移行リレーノードが移行リレーノードとソース親ノードの間のプロトコルスタックリソースを解放することを示すためのメッセージをターゲットドナーノードから受信する時点までのプロセスを含むことがある。

【0380】

移行リレーノードが並列ＰＤＳＣＨデータ伝送を実施するということは、移行リレーノードがソースドナーノードに対応するＰＤＳＣＨデータおよびターゲットドナーノードに対応するＰＤＳＣＨデータの両方を伝送することがあるものとして理解され得ることに留意されたい。同様に、移行リレーノードが並列ＰＵＳＣＨデータ伝送を実施するということは、移行リレーノードがソースドナーノードに対応するＰＵＳＣＨデータおよびターゲットドナーノードに対応するＰＵＳＣＨデータの両方を伝送することがあるものとして理解され得る。

【0381】

任意選択で、上記は、第６のインジケーション情報が移行ＩＡＢノードの粒度である例を用いて説明を提供するものである。任意選択で、第６のインジケーション情報は、端末のベアラの粒度であることもある。詳細については、能力インジケーション情報が端末のベアラの粒度であることもあるという記述を参照されたい。詳細は、本明細書では、再度説明されない。

【0382】

任意選択で、能力インジケーション情報と第６のインジケーション情報とは、同じであり得、同じ情報要素で搬送されることもあるか、あるいは、能力インジケーション情報と第６のインジケーション情報とが異なることもある。

【0383】

任意選択で、Ｓ４０２は任意選択である。Ｓ４０１またはＳ４０２のいずれかが起こることがあり、Ｓ４０１およびＳ４０２の両方が起こることがある。

【0384】

Ｓ４０３：ソースドナーノードは、第６のインジケーション情報を移行リレーノードへ送信する。

【0385】

例では、第６のインジケーション情報は、ソースドナーノードによって移行リレーノードへ送信されるＲＲＣ再構成メッセージで搬送されることがある。

【0386】

Ｓ４０４：移行リレーノードは、第６のインジケーション情報に基づいて、ハンドオーバ中にソースドナーノードへの接続を維持する。

【0387】

Ｓ４０４は、任意選択である。

【0388】

図１３から図１６の方法のうちの１つまたは複数は、一緒に実装されることもある。以下、図１７Ａから図１８Ｄを参照して、本出願の実施形態における内容についてさらに説明する。図１７Ａから図１７Ｅおよび図１８Ａから図１８Ｄはそれぞれ、図１１のドナーノード間ハンドオーバのシナリオを例として用いて説明される。図１７Ａから図１８Ｄの内容は、図１１のシナリオに適用可能であるだけでなく、別のドナーノード間ハンドオーバのシナリオにも適用可能である。

【0389】

図１７Ａから図１７Ｅおよび図１８Ａから図１８Ｄはそれぞれ、本出願の実施形態によるドナーノード間ハンドオーバ方法の概略図であり、ＩＡＢノード３がＩＡＢノード１からＩＡＢノード４へハンドオーバされるハンドオーバプロセスを説明するものである。このハンドオーバプロセスは、主として、ハンドオーバ準備、ハンドオーバ実行、およびハンドオーバ完了の３つのプロセスに分割される。各プロセスでは、端末は、ＩＡＢドナーＣＵ１および／またはＩＡＢドナーＣＵ２とデータ伝送を実施することがあり、このデータ伝送は、図１７Ａから図１８Ｄでは破線の矢印を用いて示されている。相違点は、図１７Ａから図１７Ｅでは、第１のベアラの第２のＬＣＨがハンドオーバ完了プロセスで端末用に構成されるが、図１８Ａから図１８Ｄでは、第１のベアラの第２のＬＣＨがハンドオーバ準備プロセスで端末用に構成されることにある。以下、図１７Ａから図１７Ｅおよび図１８Ａから図１８Ｄについて別個に説明する。

【0390】

図１７Ａから図１７Ｅに示されるように、この方法は、以下のステップを含む。

【0391】

Ｓ５０１からＳ５０８のプロセスは、ハンドオーバ準備プロセスを説明するものであり、図１７Ａから図１７Ｅの内容と、図１８Ａから図１８Ｄの内容とは、相互に参照され得る。

【0392】

Ｓ５０１：ＩＡＢノード３は、測定報告をＩＡＢドナーＣＵ１へ送信する。

【0393】

ＩＡＢノード３は、ＩＡＢドナーＣＵ１から受信する測定設定に基づいて、アクセスされたＩＡＢノード１のサービングセルおよびＩＡＢノード４による隣接セルサーブを測定して測定報告を取得し、測定報告をＩＡＢドナーＣＵ１へ送信することがある。

【0394】

Ｓ５０２：ＩＡＢドナーＣＵ１は、ハンドオーバ決定を実施する。

【0395】

ＩＡＢドナーＣＵ１は、受信された測定報告に基づいて、ＩＡＢノード３をＩＡＢノード１からＩＡＢノード４へハンドオーバすると決定することがある。

【0396】

例えば、ＩＡＢノード４のセルの信号品質がＩＡＢノード１のセルの信号品質より良好であるときに、ＩＡＢドナーＣＵ１は、ＩＡＢノード３をＩＡＢノード１からＩＡＢノード４へハンドオーバすると決定することがある。

【0397】

Ｓ５０３：ＩＡＢドナーＣＵ１は、ハンドオーバ要求メッセージをＩＡＢドナーＣＵ２へ送信し、このハンドオーバ要求メッセージは、能力インジケーション情報を含む。

【0398】

任意選択で、ハンドオーバ要求メッセージは、ＩＡＢノード３およびＩＡＢノード３の子孫（ｄｅｓｃｅｎｄａｎｔ）ノードのコンテキスト情報を搬送することがある。例えば、ＩＡＢノード３の子孫ノードは、ＩＡＢノード２および端末１を含み、ハンドオーバ要求メッセージは、ＩＡＢノード３、ＩＡＢノード２、および端末１のコンテキスト情報を搬送することがある。詳細については、Ｓ４０１の移行リレーノードおよび移行リレーノードの子孫ノードのコンテキスト情報を参照されたい。

【0399】

ハンドオーバ要求メッセージは、能力インジケーション情報を含むことがある。詳細については、Ｓ４０１の内容を参照されたい。

【0400】

Ｓ５０４：ＩＡＢドナーＣＵ２は、コンテキスト設定要求メッセージをＩＡＢノード４へ送信する。

【0401】

Ｓ５０５：ＩＡＢノード４は、コンテキスト設定応用メッセージをＩＡＢドナーＣＵ２へ送信する。

【0402】

Ｓ５０６：ＩＡＢドナーＣＵ２は、ハンドオーバ要求応答メッセージをＩＡＢドナーＣＵ１へ送信し、ハンドオーバ要求応答メッセージは、第１のＲＲＣ再構成メッセージを含み、第１のＲＲＣ再構成メッセージは、第６のインジケーション情報を含む。

【0403】

第６のインジケーション情報の内容については、Ｓ４０２の内容を参照されたい。

【0404】

Ｓ５０９からＳ５１３のプロセスは、ハンドオーバ実行プロセス、すなわちＩＡＢノード３とＩＡＢドナーＤＵ２の間のランダムアクセスプロセスを説明するものである。

【0405】

Ｓ５０７：ＩＡＢドナーＣＵ１は、第１のＲＲＣ再構成メッセージをＩＡＢノード３へ送信し、第１のＲＲＣ再構成メッセージは、第６のインジケーション情報を含む。

【0406】

Ｓ５０８：ＩＡＢノード３は、第６のインジケーション情報に基づいてＤＡＰＳを開始する。

【0407】

ＤＡＰＳの関連する内容については、図８および図１２の内容を参照されたい。

【0408】

ＩＡＢノード３がＤＡＰＳを開始するということは、ＩＡＢノード３がハンドオーバ中にＩＡＢドナーＣＵ１への接続を維持することがあるものとして理解され得る。

【0409】

Ｓ５０９：ＩＡＢノード３は、プリアンブルをＩＡＢノード４へ送信する。

【0410】

Ｓ５１０：ＩＡＢノード４は、ＲＡＲをＩＡＢノード３へ送信する。

【0411】

Ｓ５１１：ＩＡＢノード３は、ＰＵＳＣＨ切り換え（ｓｗｉｔｃｈ）を実施する。

【0412】

ＩＡＢノード３がＰＵＳＣＨ切り換えを実施するということは、アップリンクデータ（例えば端末のアップリンクデータ）をＩＡＢノード３がＩＡＢノード１へ伝送することを停止し、アップリンクデータ（例えば端末のアップリンクデータ）をＩＡＢノード４へ伝送することを開始する、すなわちＩＡＢノード３のＰＵＳＣＨがＩＡＢノード１からＩＡＢノード４へ切り換えられることとして理解され得る。ＩＡＢノード３のＰＵＳＣＨがＩＡＢノード４に切り換えられ、ＩＡＢノード３はアップリンクデータをＩＡＢノード１へ伝送することはできないが、ＩＡＢノード３は、依然としてダウンリンクデータをＩＡＢノード１へ伝送することはできる。ＰＵＳＣＨ切り換えの内容については、上記の説明を参照されたい。

【0413】

任意選択で、Ｓ５１１の後で、ＩＡＢノード３は、第７のインジケーション情報を端末１へ送信することがあり、端末１は、第７のインジケーション情報に基づいて、ソースドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理することを停止し、処理されたアップリンクデータを第１のＬＣＨにマッピングすることを停止することがある。例えば、第７のインジケーション情報は、アップリンクデータをソースドナーノードに送信することを停止するように端末に示すことがある。これは、ＰＵＳＣＨ切り換えの後で、ＩＡＢノード３が依然としてソースドナーノードに対応するアップリンクデータを受信し、ＩＡＢノード３がソースドナーノードに対応するアップリンクデータをターゲットドナーノードへ送信するが、ターゲットドナーノードはそのアップリンクデータをパーズすることができず、それによりパケットの喪失、データ伝送の中断、およびＩＡＢノード３とターゲットドナーノードの間のノードのバッファリソースの無駄がもたらされる場合を回避する。

【0414】

Ｓ５１２：ＩＡＢノード３は、ＲＲＣ再構成完了メッセージをＩＡＢドナーＤＵ２へ送信する。

【0415】

Ｓ５１３：ＩＡＢドナーＤＵ２は、アップリンクＲＲＣメッセージ転送（ＵＬ ＲＲＣ ｔｒａｎｓｆｅｒ）メッセージをＩＡＢドナーＣＵ２へ送信し、このメッセージは、ＲＲＣ再構成完了メッセージを含む。

【0416】

Ｓ５１４からＳ５３６は、ハンドオーバ完了プロセスを説明するものである。

【0417】

Ｓ５１４：Ｆ１インターフェースが、ＩＡＢノード３とＩＡＢドナーＣＵ２の間で確立される。

【0418】

任意選択で、ＩＡＢドナーＣＵ２におけるＩＡＢノード３のセル識別を取得した後で、ＩＡＢノード３は、ＩＡＢドナーＣＵ２に対するＦ１接続確立手順を開始することがあり、次いで、Ｆ１インターフェースが、ＩＡＢノード３とＩＡＢドナーＣＵ２の間で確立される。

【0419】

Ｓ５１５：Ｆ１インターフェースは、ＩＡＢノード２とＩＡＢドナーＣＵ２の間で確立される。

【0420】

Ｓ５１６からＳ５２１は、第１のベアラの第２のＬＣＨを構成するプロセスを説明するものであり、ここの内容と図１３の内容とは、相互に参照され得る。例えば、Ｓ５１６からＳ５２１は、第１のリレーノードがターゲットドナーノードへの接続を確立した後で、第１のリレーノードが第１のインジケーション情報をターゲットドナーノードから受信し、第１のリレーノードが第２のＬＣＨの設定情報をターゲットドナーノードへ送信する場合に対応することがある。図１３の第１のメッセージは、Ｓ５１６のコンテキスト設定要求メッセージであり、第４のメッセージは、Ｓ５１８のＵＥコンテキスト設定応答メッセージであり、図１３の第２のメッセージは、Ｓ５０６のハンドオーバ要求応答メッセージであり、図１３の第３のメッセージは、Ｓ５１９からＳ５２１の第２のＲＲＣ再構成メッセージであることは理解され得る。

【0421】

Ｓ５１６：ＩＡＢドナーＣＵ２は、ＵＥコンテキスト設定要求メッセージをＩＡＢノード２へ送信し、ＵＥコンテキスト設定要求メッセージは、第１のインジケーション情報を含む。

【0422】

任意選択で、ＵＥコンテキスト設定要求メッセージは、ＧＴＰトンネルを確立するためのものであることがあり、ＧＴＰトンネル確立要求メッセージと呼ばれることがある。任意選択で、ＵＥコンテキスト設定要求メッセージは、ＧＴＰトンネル識別子を含むことがある。

【0423】

Ｓ５１６の別の実装では、ＵＥコンテキスト設定要求メッセージは、第１のインジケーション情報を含まないことがある。

【0424】

Ｓ５１７：ＩＡＢノード２は、第１のベアラに対応する第２のＬＣＨの設定情報を生成する。

【0425】

任意選択で、ＵＥコンテキスト設定要求メッセージが第１のインジケーション情報を含むときには、ＩＡＢノード２は、第１のインジケーション情報に基づいて第２のＬＣＨの設定情報を生成することがある。あるいは、ＵＥコンテキスト設定要求メッセージが第１のインジケーション情報を含まないときには、ＵＥコンテキスト設定要求メッセージを受信した後で、ＩＡＢノード２は、Ｓ５１８で、端末の各ベアラについて第２のＬＣＨの設定情報を生成し、ＵＥコンテキスト設定応答メッセージを介して第２のＬＣＨの設定情報をＩＡＢドナーＣＵ２へ送信することがある。

【0426】

Ｓ５１８：ＩＡＢノード２は、ＵＥコンテキスト設定応答メッセージをＩＡＢドナーＣＵ２へ送信し、ＵＥコンテキスト設定応答メッセージは、第１のベアラに対応する第２のＬＣＨの設定情報を含む。

【0427】

Ｓ５１６からＳ５１８を通じて、ＧＴＰ－Ｕトンネルが、第１のベアラについてＩＡＢノード２とＩＡＢドナーＣＵ２の間で確立されることがあり、ＧＴＰ－Ｕトンネルは、第２のＬＣＨに対応する。

【0428】

任意選択で、Ｓ５１６からＳ５１８では、ルーティング設定およびベアラマッピング設定が、ＩＡＢノード２とＩＡＢドナーＣＵ２の間の経路上で完了することがある。

【0429】

Ｓ５１９：ＩＡＢドナーＣＵ２は、ハンドオーバ要求応答メッセージをＩＡＢドナーＣＵ１へ送信し、ハンドオーバ要求応答メッセージは、第２のＲＲＣ再構成メッセージを含み、第２のＲＲＣ再構成メッセージは、第１のベアラに対応する第２のＬＣＨの設定情報、および第２のインジケーション情報を含む。

【0430】

Ｓ５２０：ＩＡＢドナーＣＵ１は、ＵＥコンテキスト修正要求メッセージをＩＡＢノード２へ送信し、ＵＥコンテキスト修正要求メッセージは、第２のＲＲＣ再構成メッセージを含む。

【0431】

Ｓ５２１：ＩＡＢノード２は、第２のＲＲＣ再構成メッセージを端末へ送信する。

【0432】

第２のＲＲＣ再構成メッセージは、第１のベアラのエアインターフェース設定情報、ソースドナーノードに対応するＰＤＣＰ設定情報、およびターゲットドナーノードに対応するＰＤＣＰ設定情報のうちの１つまたは複数を含む。詳細については、Ｓ１０２の内容を参照されたい。

【0433】

任意選択で、第２のＲＲＣ再構成メッセージは、第３のインジケーション情報をさらに含む。端末１は、第３のインジケーション情報に基づいてターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理し、処理されたアップリンクデータを第２のＬＣＨにマッピングすることがある。あるいは、任意選択で、第２のＲＲＣ再構成メッセージは、第３のインジケーション情報を含まないこともある。端末１が第２のＲＲＣ再構成メッセージを受信した後、第２のＲＲＣ再構成メッセージが第２のＬＣＨの設定情報を搬送する場合には、端末１は、ターゲットドナーノードに対応するＰＤＣＰ設定情報をデフォルトで用いてアップリンクデータを処理し、処理されたアップリンクデータを第２のＬＣＨにマッピングする。

【0434】

Ｓ５２２：端末は、第１のベアラについて第２のＬＣＨを構成する。

【0435】

詳細については、図１３のＳ１０４の内容を参照されたい。

【0436】

Ｓ５２３：ＩＡＢドナーＣＵ２は、ハンドオーバ成功メッセージをＩＡＢドナーＣＵ１へ送信して、ソースダウンリンクデータをＩＡＢノード３へ送信することを停止するようにＩＡＢドナーＣＵ１に示す。

【0437】

Ｓ５２４：ＩＡＢドナーＣＵ１は、ソースダウンリンクデータをＩＡＢノード３へ送信することを停止する。

【0438】

任意選択で、ＩＡＢドナーＣＵ１はソースダウンリンクデータをＩＡＢノード３へ送信することを停止するが、ＩＡＢノード３は、ＩＡＢノード３にバッファリングされたソースダウンリンクデータを端末１へ送信することを継続することもある。

【0439】

Ｓ５２５からＳ５３１は、第１のベアラの第１のＬＣＨを削除するプロセスを説明するものである。ここの内容と図１５の内容とは、相互に参照され得る。例えば、Ｓ５２５のＵＥコンテキスト解放メッセージは、図１５の第７のメッセージであり、Ｓ５２６のＵＥコンテキスト解放メッセージは、図１５の第８のメッセージである。

【0440】

Ｓ５２５：ＩＡＢドナーＣＵ２は、ＵＥコンテキスト解放メッセージをＩＡＢドナーＣＵ１へ送信する。

【0441】

Ｓ５２６：ＩＡＢドナーＣＵ１は、ＵＥコンテキスト解放メッセージをＩＡＢノード２へ送信する。

【0442】

Ｓ５２７：ＩＡＢノード２は、第１のＬＣＨのバッファが空であると決定する。

【0443】

Ｓ５２８：ＩＡＢノード２は、ＵＥコンテキスト修正所用メッセージをＩＡＢドナーＣＵ２へ送信し、このメッセージは、第４のインジケーション情報を含む。

【0444】

第４のインジケーション情報については、図１５の内容を参照されたい。

【0445】

Ｓ５２９：ＩＡＢドナーＣＵ２は、ＵＥコンテキスト修正要求メッセージをＩＡＢノード２へ送信し、このメッセージは、第３のＲＲＣ再構成メッセージを含み、第３のＲＲＣ再構成メッセージは、第５のインジケーション情報を含む。

【0446】

Ｓ５３０：ＩＡＢノード２は、第３のＲＲＣ再構成メッセージを端末１へ送信し、第３のＲＲＣ再構成メッセージは、第５のインジケーション情報を含む。

【0447】

Ｓ５３１：端末は、第５のインジケーション情報に基づいて第１のベアラの第１のＬＣＨを削除する。

【0448】

第５のインジケーション情報については、Ｓ３０２からＳ３０４の内容を参照されたい。

【0449】

Ｓ５３２：ＩＡＢドナーＣＵ２は、Ｆ１ ＡＰメッセージをＩＡＢノード３へ送信して、ＩＡＢノード３とＩＡＢノード１の間のプロトコルスタックリソースを解放するようにＩＡＢノード３に示す。

【0450】

Ｓ５３３：ＩＡＢノード３は、ＤＡＰＳからシングルアクティブプロトコルスタックへ切り換える。

【0451】

シングルアクティブプロトコルスタックは、ＩＡＢノード３が、ターゲット親ノードに対応するプロトコルスタックリソースしか有していないこととして理解され得る。換言すれば、ＩＡＢノード３は、ＩＡＢノード３とＩＡＢノード１の間のプロトコルスタックリソースを解放する。

【0452】

Ｓ５３４：ＩＡＢドナーＣＵ２は、コンテキスト解放メッセージをＩＡＢドナーＣＵ１へ送信する。

【0453】

Ｓ５３５：ＩＡＢドナーＣＵ１は、コンテキスト解放メッセージをＩＡＢノード１へ送信する。

【0454】

Ｓ５３６：ＩＡＢノード１は、ＩＡＢノード３のコンテキストを解放する。

【0455】

図１７Ａから図１７Ｅの方法では、ＩＡＢドナーＣＵ１がハンドオーバ決定を実施する前に、第１のＬＣＨが端末の第１のベアラについて構成され、端末は、ソースドナーノードに対応するダウンリンクＰＤＣＰデータ（以下ではソースダウンリンクデータと略記する）およびソースドナーノードに対応するアップリンクＰＤＣＰデータ（以下ではソースアップリンクデータと略記する）を第１のＬＣＨを通して伝送することがある。ハンドオーバ完了段階では、ＩＡＢノード２がＩＡＢドナーＣＵ２を通して端末の第１のベアラについて第２のＬＣＨを構成した後で、端末は、ターゲットドナーノードに対応するダウンリンクＰＤＣＰデータ（以下ではターゲットダウンリンクデータと略記する）およびターゲットドナーノードに対応するアップリンクＰＤＣＰデータ（以下ではターゲットアップリンクデータと略記する）を第２のＬＣＨを通して伝送することがある。

【0456】

任意選択で、Ｓ５０１からＳ５１１で、ＩＡＢドナーＣＵ１は、ソースダウンリンクデータを端末へ送信することがあり、端末は、ソースアップリンクデータをＩＡＢドナーＣＵ１へ送信することがある。

【0457】

任意選択で、Ｓ５１１からＳ５２２で、ＩＡＢドナーＣＵ１は、ソースダウンリンクデータを端末へ送信することがある。

【0458】

任意選択で、Ｓ５２２からＳ５２４で、ＩＡＢドナーＣＵ１は、ソースダウンリンクデータを端末へ送信することがあり、ＩＡＢドナーＣＵ２は、ターゲットダウンリンクデータを端末へ送信することがあり、端末は、ターゲットアップリンクデータをＩＡＢドナーＣＵ２へ送信することがある。

【0459】

任意選択で、Ｓ５２４からＳ５２７で、ＩＡＢノード３およびＩＡＢノード２は、ＩＡＢノード３またはＩＡＢノード２にバッファリングされたソースダウンリンクデータパケットを端末１へ送信することを継続することがあり、ＩＡＢドナーＣＵ２は、ターゲットダウンリンクデータを端末へ送信することがあり、端末は、ターゲットアップリンクデータをＩＡＢドナーＣＵ２へ送信することがある。

【0460】

任意選択で、Ｓ５２７からＳ５３６で、ＩＡＢドナーＣＵ２は、ターゲットダウンリンクデータを端末へ送信することがあり、端末は、ターゲットアップリンクデータをＩＡＢドナーＣＵ２へ送信することがある。

【0461】

ソースアップリンクデータ、ソースダウンリンクデータ、ターゲットアップリンクデータ、および／またはターゲットダウンリンクデータを処理する方法については、前述の内容を参照されたい。詳細は、本明細書では、再度説明されない。

【0462】

図１７Ａから図１７Ｅの方法では、ＩＡＢノード３のハンドオーバ中に、端末のデータ伝送は常に中断されず、データ伝送の継続性を保証する。

【0463】

図１８Ａから図１８Ｄは、本出願の実施形態による別のドナーノード間ハンドオーバ方法の概略図である。図１８Ａから図１８Ｄに示されるように、この方法は、以下のステップを含む。

【0464】

Ｓ６０１からＳ６１６のプロセスは、ハンドオーバ準備プロセスを説明するものであり、図１７Ａから図１７Ｅの内容と図１８Ａから図１８Ｄの内容とは、相互に参照され得る。

【0465】

Ｓ６０１：ＩＡＢノード３は、測定報告をＩＡＢドナーＣＵ１へ送信する。

【0466】

Ｓ６０２：ＩＡＢドナーＣＵ１は、ハンドオーバ決定を実施する。

【0467】

Ｓ６０３：ＩＡＢドナーＣＵ１は、ハンドオーバ要求メッセージをＩＡＢドナーＣＵ２へ送信し、ハンドオーバ要求メッセージは、能力インジケーション情報を含む。

【0468】

Ｓ６０４からＳ６０６は、第１のベアラの第２のＬＣＨを構成するプロセスを説明するものであり、ここの内容と図１３の内容とは、相互に参照され得る。例えば、Ｓ６０４からＳ６０６は、第１のリレーノードがターゲットドナーノードへの接続を確立する前に、第１のリレーノードが、第１のインジケーション情報をソースドナーノードから受信し、第２のＬＣＨの設定情報をソースドナーノードへ送信し、ソースドナーノードが、第２のＬＣＨの設定情報をターゲットドナーノードへ送信する場合に対応することがある。図１３の第１のメッセージは、Ｓ６０４のＵＥコンテキスト修正要求メッセージであり、図１３の第５のメッセージは、Ｓ６０６のＵＥコンテキスト修正応答メッセージであり、図１３の第６のメッセージは、Ｓ６０９のハンドオーバ要求メッセージであり、図１３の第２のメッセージは、Ｓ６１３のハンドオーバ要求応答メッセージであり、図１３の第１のメッセージは、Ｓ６１３からＳ６１５の第２のＲＲＣ再構成メッセージであることは理解され得る。

【0469】

Ｓ６０４：ＩＡＢドナーＣＵ１は、ＵＥコンテキスト修正要求メッセージをＩＡＢノード２へ送信し、ＵＥコンテキスト修正要求メッセージは、第１のインジケーション情報を含む。

【0470】

Ｓ６０５：ＩＡＢノード２は、第１のベアラに対応する第２のＬＣＨの設定情報を生成する。

【0471】

ＩＡＢノード２は、第１のインジケーション情報に基づいて第２のＬＣＨの設定情報を生成することがある。

【0472】

Ｓ６０６：ＩＡＢノード２は、ＵＥコンテキスト修正応答メッセージをＩＡＢドナーＣＵ１へ送信し、ＵＥコンテキスト修正応答メッセージは、第２のＬＣＨの設定情報を含む。

【0473】

Ｓ６０７：ＩＡＢドナーＣＵ２は、コンテキスト設定要求メッセージをＩＡＢノード４へ送信する。

【0474】

Ｓ６０８：ＩＡＢノード４は、コンテキスト設定応答メッセージをＩＡＢドナーＣＵ２へ送信する。

【0475】

Ｓ６０９：ＩＡＢドナーＣＵ１は、ハンドオーバ要求メッセージをＩＡＢドナーＣＵ２へ送信し、ハンドオーバ要求メッセージは、第２のＬＣＨの設定情報を含む。

【0476】

任意選択で、Ｓ６０９およびＳ６０３のメッセージは、同じハンドオーバ要求メッセージであることがある。

【0477】

任意選択で、Ｓ６０９は、Ｓ６０７の前、Ｓ６０７とＳ６０８の間、またはＳ６０８の後に実施され得る。これは、本出願のこの実施形態では限定されない。

【0478】

Ｓ６１０：ＩＡＢドナーＣＵ２は、ハンドオーバ要求応答メッセージをＩＡＢドナーＣＵ１へ送信し、ハンドオーバ要求応答メッセージは、第１のＲＲＣ再構成メッセージを含み、第１のＲＲＣ再構成メッセージは、第６のインジケーション情報を含む。

【0479】

Ｓ６１１：ＩＡＢドナーＣＵ１は、第１のＲＲＣ再構成メッセージをＩＡＢノード３へ送信し、第１のＲＲＣ再構成メッセージは、第６のインジケーション情報を含む。

【0480】

Ｓ６１２：ＩＡＢノード３は、第６のインジケーション情報に基づいてＤＡＰＳを開始する。

【0481】

Ｓ６１３：ＩＡＢドナーＣＵ２は、ハンドオーバ要求応答メッセージをＩＡＢドナーＣＵ１に送信し、ハンドオーバ要求応答メッセージは、第２のＬＣＨ再構成メッセージを含み、第２のＲＲＣ再構成メッセージは、第１のベアラに対応する第２のＬＣＨの設定情報、および第２のインジケーション情報を含む。

【0482】

Ｓ６１４：ＩＡＢドナーＣＵ１は、ＵＥコンテキスト修正要求メッセージをＩＡＢノード２へ送信し、ＵＥコンテキスト修正要求メッセージは、第２のＲＲＣ再構成メッセージを含む。

【0483】

Ｓ６１５：ＩＡＢノード２は、第２のＲＲＣ再構成メッセージを端末へ送信する。

【0484】

任意選択で、Ｓ６１０およびＳ６１３のメッセージは、同じハンドオーバ要求応答メッセージであることがあり、ハンドオーバ要求応答メッセージは、第１のＲＲＣ再構成メッセージ、および第２のＲＲＣ再構成メッセージを含む。

【0485】

Ｓ６１６：端末は、第１のベアラについて第２のＬＣＨを構成する。

【0486】

Ｓ６１７からＳ６２１のプロセスは、ハンドオーバ実行プロセス、すなわちＩＡＢノード３とＩＡＢドナーＤＵ２の間のランダムアクセスプロセスを説明するものである。

【0487】

Ｓ６１７：ＩＡＢノード３は、プリアンブルをＩＡＢノード４へ送信する。

【0488】

Ｓ６１８：ＩＡＢノード４は、ＲＡＲをＩＡＢノード３へ送信する。

【0489】

Ｓ６１９：ＩＡＢノード３は、ＰＵＳＣＨ切り換え（ｓｗｉｔｃｈ）を実施する。

【0490】

Ｓ６２０：ＩＡＢノード３は、ＲＲＣ再構成完了メッセージをＩＡＢドナーＤＵ２へ送信する。

【0491】

Ｓ６２１：ＩＡＢドナーＤＵ２は、アップリンクＲＲＣメッセージ転送（ＵＬ ＲＲＣ ｔｒａｎｓｆｅｒ）メッセージをＩＡＢドナーＣＵ２へ送信し、このメッセージは、ＲＲＣ再構成完了メッセージを含む。

【0492】

Ｓ６２２：ＩＡＢノード３は、第３のインジケーション情報を端末へ送信する。

【0493】

任意選択で、ＩＡＢノード３は、ＰＵＳＣＨ切り換えを実施した後、またはターゲットドナーノードへの接続を確立した後で、第３のインジケーション情報を端末へ送信することがある。詳細については、Ｓ２００の内容を参照されたい。

【0494】

Ｓ６２３：Ｆ１インターフェースが、ＩＡＢノード３とＩＡＢドナーＣＵ２の間で確立される。

【0495】

Ｓ６２４：Ｆ１インターフェースが、ＩＡＢノード２とＩＡＢドナーＣＵ２の間で確立される。

【0496】

Ｓ６２５：ＩＡＢドナーＣＵ２は、ＵＥコンテキスト設定要求メッセージをＩＡＢノード２へ送信する。

【0497】

Ｓ６２６：ＩＡＢノード２は、ＵＥコンテキスト設定応答メッセージをＩＡＢドナーＣＵ２へ送信する。

【0498】

Ｓ６２７：ＩＡＢドナーＣＵ２は、ハンドオーバ成功メッセージをＩＡＢドナーＣＵ１へ送信して、ソースダウンリンクデータをＩＡＢノード３へ送信することを停止するようにＩＡＢドナーＣＵ１に示す。

【0499】

Ｓ６２８：ＩＡＢドナーＣＵ１は、ソースダウンリンクデータをＩＡＢノード３へ送信することを停止する。

【0500】

Ｓ６２９：ＩＡＢドナーＣＵ２は、ＵＥコンテキスト解放メッセージをＩＡＢドナーＣＵ１へ送信する。

【0501】

Ｓ６３０：ＩＡＢドナーＣＵ１は、ＵＥコンテキスト解放メッセージをＩＡＢノード２へ送信する。

【0502】

Ｓ６３１：ＩＡＢノード２は、第１のＬＣＨのバッファが空であると決定する。

【0503】

Ｓ６３２：ＩＡＢノード２は、ＵＥコンテキスト修正所用メッセージをＩＡＢドナーＣＵ２へ送信し、このメッセージは、第４のインジケーション情報を含む。

【0504】

Ｓ６３３：ＩＡＢドナーＣＵ２は、ＵＥコンテキスト修正要求メッセージをＩＡＢノード２へ送信し、このメッセージは、第３のＲＲＣ再構成メッセージを含み、第３のＲＲＣ再構成メッセージは、第５のインジケーション情報を含む。

【0505】

Ｓ６３４：ＩＡＢノード２は、第３のＲＲＣ再構成メッセージを端末１へ送信し、第３のＲＲＣ再構成メッセージは、第５のインジケーション情報を含む。

【0506】

Ｓ６３５：端末は、第５のインジケーション情報に基づいて第１のベアラの第１のＬＣＨを削除する。

【0507】

Ｓ６３６：ＩＡＢドナーＣＵ２は、Ｆ１メッセージをＩＡＢノード３へ送信して、ＩＡＢノード３とＩＡＢノード１の間のプロトコルスタックリソースを解放するようにＩＡＢノード３に示す。

【0508】

Ｓ６３７：ＩＡＢノード３は、ＤＡＰＳからシングルアクティブプロトコルスタックへ切り換える。

【0509】

Ｓ６３８：ＩＡＢドナーＣＵ２は、コンテキスト解放メッセージをＩＡＢドナーＣＵ１へ送信する。

【0510】

Ｓ６３９：ＩＡＢドナーＣＵ１は、コンテキスト解放メッセージをＩＡＢノード１へ送信する。

【0511】

Ｓ６４０：ＩＡＢノード１は、ＩＡＢノード３のコンテキストを解放する。

【0512】

図１８Ａから図１８Ｄの各ステップの内容については、図１７Ａから図１７Ｅの内容を参照されたい。詳細は、本明細書では、再度説明されない。

【0513】

任意選択で、Ｓ６０１からＳ６２２で、ＩＡＢドナーＣＵ１は、ソースダウンリンクデータを端末に送信することがあり、端末は、ソースアップリンクデータをＩＡＢドナーＣＵ１へ送信することがある。

【0514】

任意選択で、Ｓ６２２からＳ６３０で、ＩＡＢドナーＣＵ１は、ソースダウンリンクデータを端末に送信することがあり、ＩＡＢドナーＣＵ２は、ターゲットダウンリンクデータを端末に送信することがあり、端末は、ソースアップリンクデータをＩＡＢドナーＣＵ２へ送信することがある。

【0515】

任意選択で、Ｓ６３０からＳ６４０で、ＩＡＢドナーＣＵ２は、ターゲットダウンリンクデータを端末へ送信することがあり、端末は、ターゲットアップリンクデータをＩＡＢドナーＣＵ２へ送信することがある。

【0516】

ソースアップリンクデータ、ソースダウンリンクデータ、ターゲットアップリンクデータ、および／またはターゲットダウンリンクデータを処理する方法については、前述の内容を参照されたい。詳細は、本明細書では、再度説明されない。

【0517】

以下、図１９から図２２を参照して、本出願の実施形態で提供される装置について述べる。図１９から図２２の装置は、図１３から図１８Ｄの方法を完了することがある。装置の内容と方法の内容とは、相互に参照され得る。

【0518】

図１９は、本出願の実施形態による端末の構造の概略図である。端末は、前述の方法の実施形態における端末の機能を実装することがある。説明を容易にするために、図１９は、端末の主要な構成要素を示している。図１９には、以下が示されている。

【0519】

端末は、少なくとも１つのプロセッサ６１１、少なくとも１つのトランシーバ６１２、および少なくとも１つのメモリ６１３を含む。プロセッサ６１１と、メモリ６１３と、トランシーバ６１２とは、互いに接続される。任意選択で、端末は、出力デバイス６１４、入力デバイス６１５、および１つまたは複数のアンテナ６１６をさらに含むことがある。アンテナ６１６は、トランシーバ６１２に接続され、出力デバイス６１４および入力デバイス６１５は、プロセッサ６１１に接続される。

【0520】

プロセッサ６１１は、主に、通信プロトコルおよび通信データを処理し、端末全体を制御し、ソフトウェアプログラムを実行し、ソフトウェアプログラムのデータを処理するように構成される。

【0521】

任意選択の実装では、端末は、ベースバンドプロセッサ、および中央処理ユニットを含むことがある。ベースバンドプロセッサは、主に、通信プロトコルおよび通信データを処理するように構成される。中央処理ユニットは、主に、端末デバイス全体を制御し、ソフトウェアプログラムを実行し、ソフトウェアプログラムのデータを処理するように構成される。

【0522】

ベースバンドプロセッサおよび中央処理ユニットの機能は、図１９のプロセッサに統合されることがある。当業者なら、ベースバンドプロセッサおよび中央処理ユニットが、代替として互いに独立したプロセッサであることもあり、バスなどの技術を用いて相互接続されることを理解し得る。当業者なら、端末デバイスが様々なネットワーク標準に適応するために複数のベースバンドプロセッサを含むことがあり、端末デバイスが端末デバイスの処理能力を強化するために複数の中央処理ユニットを含むことがあり、端末デバイスの構成要素が様々なバスを用いて接続されることがあることを理解し得る。ベースバンドプロセッサは、あるいは、ベースバンド処理回路またはベースバンド処理チップと表現されることもある。中央処理ユニットは、あるいは、中央処理回路または中央処理チップと表現されることもある。通信プロトコルおよび通信データを処理する機能は、プロセッサに組み込まれることもあるし、ソフトウェアプログラムの形態でメモリに記憶されることもある。プロセッサは、ソフトウェアプログラムを実行して、ベースバンド処理機能を実装する。

【0523】

メモリ６１３は、主に、ソフトウェアプログラムおよびデータを記憶するように構成される。メモリ６１３は、独立して存在することもあり、プロセッサ６１１に接続される。任意選択で、メモリ６１３とプロセッサ６１１とが互いに一体化される、例えば単一のチップ上に一体化される、すなわちオンチップメモリとなることもあるし、メモリ６１３が独立した記憶要素である。これは、本出願のこの実施形態では限定されない。メモリ６１３は、本出願の実施形態の技術的解決策を実行するためのプログラムコードを記憶することができ、プロセッサ６１１は、このプログラムコードの実行を制御する。様々なタイプの実行されたコンピュータプログラムコードは、プロセッサ６１１のドライバとみなされることもある。

【0524】

トランシーバ６１２は、ベースバンド信号と無線周波数信号の間の変換を実施し、無線周波数信号を処理するように構成されることがある。トランシーバ６１２は、アンテナ６１６に接続されることがある。トランシーバ６１２は、送信機（ｔｒａｎｓｍｉｔｔｅｒ、Ｔｘ）および受信機（ｒｅｃｅｉｖｅｒ、Ｒｘ）を含む。具体的には、１つまたは複数のアンテナ６１６は、無線周波数信号を受信することがある。トランシーバ６１２の受信機Ｒｘは、無線周波数信号をアンテナから受信し、無線周波数信号をデジタルベースバンド信号またはデジタル中間周波数信号に変換し、プロセッサ６１１がこのデジタルベースバンド信号またはデジタル中間周波数信号をさらに処理する、例えば復調処理および復号処理を実施するようにこのデジタルベースバンド信号またはデジタル中間周波数信号をプロセッサ６１１に提供するように構成される。さらに、トランシーバ６１２の送信機Ｔｘは、変調されたデジタルベースバンド信号またはデジタル中間周波数信号をプロセッサ６１１から受信し、この変調されたデジタルベースバンド信号またはデジタル中間周波数信号を無線周波数信号に変換し、この無線周波数信号を１つまたは複数のアンテナ６１６を通して送信するように構成される。具体的には、受信機Ｒｘは、無線周波数信号に対して１つまたは複数のレベルの周波数ダウンミキシング処理およびアナログデジタル変換処理を選択的に実施して、デジタルベースバンド信号またはデジタル中間周波数信号を得ることがある。周波数ダウンミキシング処理とアナログデジタル変換処理の順序は、調節可能である。送信機Ｔｘは、変調されたデジタルベースバンド信号またはデジタル中間周波数信号に対して１つまたは複数のレベルの周波数アップミキシング処理およびデジタルアナログ変換処理を選択的に実施して、無線周波数信号を得ることがある。周波数アップミキシング処理とデジタルアナログ変換処理の順序は、調節可能である。デジタルベースバンド信号およびデジタル中間周波数信号は、デジタル信号と総称されることもある。任意選択で、送信機Ｔｘおよび受信機Ｒｘは、異なる物理構造／回路によって実装されることもあり、または、同じ物理構造／回路によって実装されることもあり、すなわち送信機Ｔｘと受信機Ｒｘとが共に集積化されることもある。

【0525】

トランシーバは、トランシーバユニットまたはトランシーバ装置などと呼ばれることもある。任意選択で、トランシーバ内にあり、受信機能を実装するように構成された構成要素は、受信ユニットとみなされ得、トランシーバ内にあり、送信機能を実装するように構成された構成要素は、送信ユニットとみなされ得る。すなわち、トランシーバユニットは、受信ユニットおよび送信ユニットを含む。受信ユニットは、受信機、入力ポート、または受信回路などと呼ばれることもある。送信ユニットは、送信機または伝送回路などと呼ばれることもある。あるいは、Ｔｘと、Ｒｘと、アンテナとが組み合わされてトランシーバになることもある。

【0526】

出力デバイス６１４は、複数の方式で情報を表示する。例えば、出力デバイス６１４は、液晶ディスプレイ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ、ＬＣＤ）、発光ダイオード（Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ、ＬＥＤ）表示デバイス、陰極線管（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ、ＣＲＴ）表示デバイス、またはプロジェクタ（ｐｒｏｊｅｃｔｏｒ）などであることがある。入力デバイス６１５は、複数の方式でユーザの入力を受け取り得る。例えば、入力デバイス６１５は、マウス、キーボード、タッチスクリーンデバイス、または感知デバイスであることがある。

【0527】

例えば、プロセッサ６１１は、端末が前述の方法の実施形態に記載されるアクションを実施するのをサポートするように構成されることがある。例えば、プロセッサ６１１（例えばベースバンドプロセッサ）は、図１２の端末１のデュアル構成プロトコルスタックの機能を実装し、第１のインジケーション情報を取得し、ソースドナーノードに対応する設定情報またはターゲットドナーノードに対応する設定情報を用いて受信されたダウンリンクデータまたは送信されるアップリンクデータを処理し、ソースドナーノードに対応する設定情報および／またはターゲットドナーノードに対応する設定情報を起動し、ソースドナーノードに対応する設定情報を削除することがある。詳細については、前述の方法の実施形態の内容を参照されたい。

【0528】

例えば、メモリ６１３は、前述の方法の実施形態において端末によって実施される動作を実行するプログラムコードを記憶することがあり、プロセッサ６１１は、実行を制御する。例えば、メモリ６１３は、ソースドナーノードに対応する設定情報および／またはターゲットドナーノードに対応する設定情報を記憶することがあり、メモリ６１３は、インジケーション情報などを記憶することがあり、メモリ６１３は、リレーノードから受信されたダウンリンクデータ、または送信されるアップリンクデータを記憶することがある。詳細については、前述の方法の実施形態の内容を参照されたい。

【0529】

例えば、トランシーバ６１２およびアンテナ６１６は、端末の親ノードとの伝送を実装する、例えばダウンリンクデータを受信する、アップリンクデータを送信する、またはインジケーション情報を受信することがある。詳細については、前述の方法の実施形態の内容を参照されたい。

【0530】

図２０は、本出願の実施形態による通信装置の構造の概略図である。通信装置は、リレーノードであることがあり、前述の方法の実施形態のリレーノードの機能を実装することがある。あるいは、通信装置は、ドナーノードであることもあり、前述の方法の実施形態のソースドナーノードまたはターゲットドナーノードの機能を実装することもある。説明を容易にするために、図２０は、通信装置の主要な構成要素を示している。図２０には、以下が示されている。

【0531】

通信装置は、少なくとも１つのプロセッサ７１１、少なくとも１つのメモリ７１２、少なくとも１つのトランシーバ７１３、少なくとも１つのネットワークインターフェース７１４、および１つまたは複数のアンテナ７１５を含む。プロセッサ７１１と、メモリ７１２と、トランシーバ７１３と、ネットワークインターフェース７１４とは、例えばバスを用いて互いに接続される。本出願のこの実施形態では、この接続は、様々なタイプのインターフェース、伝送線、またはバスなどを含み得る。これは、この実施形態では限定されない。アンテナ７１５は、トランシーバ７１３に接続される。ネットワークインターフェース７１４は、通信装置が通信リンクを通して別のネットワークデバイスに接続されることを可能にするように構成される。

【0532】

トランシーバ７１３、メモリ７１２、およびアンテナ７１５については、同様の機能を実装するために、図１９の関連する説明を参照されたい。

【0533】

通信装置が第１のリレーノードであるときには、プロセッサ７１１は、第１のリレーノードが前述の方法の実施形態に記載されるアクションを実施するのをサポートするように構成されることがある。例えば、プロセッサ７１１は、前述の方法の実施形態において第１のリレーノードによって生成される第２のＬＣＨの設定情報を生成し、この第２のＬＣＨの設定情報を端末へ送信することがある。具体的には、ＧＴＰトンネル確立要求をターゲットドナーノードから受信した後で、第１のリレーノードは、第２のＬＣＨの設定情報を生成することがある。別の例では、プロセッサ７１１は、受信された第１のインジケーション情報に基づいて第２のＬＣＨの設定情報を生成することもある。詳細については、前述の方法の実施形態の内容を参照されたい。

【0534】

トランシーバ７１３およびアンテナ７１５は、第１のリレーノードとソースドナーノードの間の接続、または第１のリレーノードとターゲットドナーノードの間の接続を実装することがある。

【0535】

トランシーバ７１３およびアンテナ７１５は、第１のリレーノードの親ノードおよび／または第１のリレーノードの子ノードとの伝送を実装することがあり、例えば、ソースドナーノードおよび／またはターゲットドナーノードのデータを第１のリレーノードの親ノードから受信する、ソースドナーノードおよび／またはターゲットドナーノードのデータを端末へ送信する、端末のデータを受信する、端末のデータを第１のリレーノードの親ノードへ送信する、別のノード（例えばソースドナーノードおよび／またはターゲットドナーノード）によって生成されたインジケーション情報を第１のリレーノードの親ノードから受信する、受信されたインジケーション情報または第１のリレーノードによって生成されたインジケーション情報を端末へ送信することがある。詳細については、前述の方法の実施形態の内容を参照されたい。

【0536】

メモリ７１２は、前述の方法の実施形態において第１のリレーノードによって実施される動作を実行するためのプログラムコードおよび／またはデータを記憶することがあり、プロセッサ７１１は、実行を制御する。例えば、メモリ７１２は、第１のリレーノードの親ノードおよび／もしくは子ノードから受信されるデータまたはインジケーション情報を記憶することがあり、または、第１のリレーノードによって生成されるインジケーション情報を記憶することがある。詳細については、前述の方法の実施形態の内容を参照されたい。

【0537】

通信装置がターゲットドナーノードであるときには、プロセッサ７１１は、ターゲットドナーノードが前述の方法の実施形態に記載されるアクションを実施するのをサポートするように構成されることがある。例えば、プロセッサ７１１は、前述の方法の実施形態においてターゲットドナーノードによって生成されるインジケーション情報またはデータなどを生成することがある。詳細については、前述の方法の実施形態の内容を参照されたい。

【0538】

トランシーバ７１３およびアンテナ７１５は、ターゲットドナーノードとリレーノードの間の接続を実装することがある。トランシーバ７１３およびアンテナ７１５は、ターゲットドナーノードの子ノードとの伝送を実装することがあり、例えば、データおよび／またはインジケーション情報を子ノードへ送信したり、データおよび／またはインジケーション情報を子ノードから受信したりすることがある。詳細については、前述の方法の実施形態の内容を参照されたい。

【0539】

メモリ７１２は、前述の方法の実施形態においてターゲットドナーノードによって実施される動作を実行するためのプログラムコードおよび／またはデータを記憶することがあり、プロセッサ７１１は、実行を制御する。例えば、メモリ７１２は、別のノードから受信されるデータまたはインジケーション情報を記憶することがあり、または、ターゲットドナーノードによって生成されるデータまたはインジケーション情報を記憶することがある。詳細については、前述の方法の実施形態の内容を参照されたい。

【0540】

ネットワークインターフェース７１４は、ターゲットドナーノードとコアネットワーク要素の間のネットワークインターフェース、例えばＳ１インターフェースを含むことがある。ネットワークインターフェースは、アクセスネットワークデバイスと別のネットワークデバイスの間のネットワークインターフェース、例えばソースドナーノードとターゲットドナーノードの間のネットワークインターフェース、例えばＸ２またはＸｎインターフェースを含むことがある。

【0541】

通信装置がソースドナーノードであるときには、プロセッサ７１１は、ソースドナーノードが前述の方法の実施形態に記載されるアクションを実施するのをサポートするように構成されることがある。例えば、プロセッサ７１１は、前述の方法の実施形態においてソースドナーノードによって生成されるインジケーション情報またはデータなどを生成することがある。詳細については、前述の方法の実施形態の内容を参照されたい。

【0542】

トランシーバ７１３およびアンテナ７１５は、ソースドナーノードとリレーノードの間の接続を実装することがある。トランシーバ７１３およびアンテナ７１５は、ソースドナーノードの子ノードとの伝送を実装することがあり、例えば、データおよび／またはインジケーション情報を子ノードへ送信し、データおよび／またはインジケーション情報を子ノードから受信することがある。詳細については、前述の方法の実施形態の内容を参照されたい。

【0543】

メモリ７１２は、前述の方法の実施形態においてソースドナーノードによって実施される動作を実行するためのプログラムコードおよび／またはデータを記憶することがあり、プロセッサ７１１は、実行を制御する。例えば、メモリ７１２は、別のノードから受信されるデータまたはインジケーション情報を記憶することがあり、または、ソースドナーノードによって生成されるデータまたはインジケーション情報を記憶することがある。詳細については、前述の方法の実施形態の内容を参照されたい。

【0544】

ネットワークインターフェース７１４は、ソースドナーノードとコアネットワーク要素の間のネットワークインターフェース、例えばＳ１インターフェースを含むことがある。ネットワークインターフェースは、アクセスネットワークデバイスと別のネットワークデバイスの間のネットワークインターフェース、例えばターゲットドナーノードとソースドナーノードの間のネットワークインターフェース、例えばＸ２またはＸｎインターフェースを含むことがある。

【0545】

図２１は、本出願の実施形態によるアクセスネットワークデバイスの構造の概略図である。例えば、図２１は、ドナーノードの構造の概略図であり得る。ドナーノードに含まれるＤＵは、ドナーＤＵであることがあり、ドナーノードに含まれるＣＵは、ドナーＣＵであることがある。図２１に示されるように、基地局が、図１、図２、図３、および図１１に示されるシステムで使用され、前述の方法の実施形態におけるドナーノード（ソースドナーノードおよび／またはターゲットドナーノードを含む）の機能を実施することがある。

【0546】

アクセスネットワークデバイスは、１つまたは複数のＤＵ１１０１、および１つまたは複数のＣＵ１１０２を含むことがある。ＤＵ１１０１は、少なくとも１つのアンテナ１１０１１、少なくとも１つの無線周波数ユニット１１０１２、少なくとも１つのプロセッサ１１０１３、および少なくとも１つのメモリ１１０１４を含むことがある。ＤＵ１１０１は、主に、無線周波数信号を送信および受信し、無線周波数信号とベースバンド信号の間の変換を実施し、部分ベースバンド処理を実施するように構成される。ＣＵ１１０２は、少なくとも１つのプロセッサ１１０２２、および少なくとも１つのメモリ１１０２１を含むことがある。ＣＵ１１０２とＤＵ１１０１とは、インターフェースを通して互いに通信することがある。制御プレーン（ｃｏｎｔｒｏｌ ｐｌａｎｅ）インターフェースは、Ｆ１－Ｃであることがあり、ユーザプレーン（ｕｓｅｒ Ｐｌａｎｅ）インターフェースは、Ｆ１－Ｕであることがある。

【0547】

ＣＵ１１０２は、主に、ベースバンド処理を実施すること、および基地局を制御することなどを行うように構成される。ＤＵ１１０１とＣＵ１１０２とは、物理的に一緒に配置されるこがもあり、または、物理的に分離して配置されることもある、すなわち分散型の基地局であることもある。ＣＵ１１０２は、基地局の制御センタであり、処理ユニットと呼ばれることもあり、主に、ベースバンド処理機能を完了するように構成される。例えば、ＣＵ１１０２は、前述の方法の実施形態においてネットワークデバイスに関係する動作手順を実施するように基地局を制御するように構成されることがある。

【0548】

具体的には、ＣＵおよびＤＵのベースバンド処理は、ワイヤレスネットワークのプロトコル層に基づいて分類されることがある。詳細については、図３の内容を参照されたい。

【0549】

さらに、任意選択で、ドナー基地局１１００は、１つまたは複数の無線周波数ユニット（ｒａｄｉｏ ｕｎｉｔｓ、ＲＵｓ）、１つまたは複数のＤＵ、および１つまたは複数のＣＵを含むことがある。ＤＵは、上記の少なくとも１つのプロセッサ１１０１３および上記の少なくとも１つのメモリ１１０１４を含むことがあり、ＲＵは、上記の少なくとも１つのアンテナ１１０１１および上記の少なくとも１つの無線周波数ユニット１１０１２を含むことがあり、ＣＵは、上記の少なくとも１つのプロセッサ１１０２２および上記の少なくとも１つのメモリ１１０２１を含むことがある。

【0550】

例では、ＣＵ１１０２は、１つまたは複数の基板を含むことがあり、複数の基板が、協働で１つのアクセス標準の無線アクセスネットワーク（例えば５Ｇネットワーク）をサポートすることがあり、または、別個に異なるアクセス標準の無線アクセスネットワーク（例えばＬＴＥネットワーク、５Ｇネットワーク、または別のネットワーク）をサポートすることがある。メモリ１１０２１およびプロセッサ１１０２２は、１つまたは複数の基板にサービスすることがある。換言すれば、各基板に独立してメモリおよびプロセッサが配置されることがあり、または、複数の基板が同じメモリおよび同じプロセッサを共有することもある。さらに、必要な回路が、各基板にさらに配置されることがある。ＤＵ１１０１は、１つまたは複数の基板を含むことがあり、複数の基板が、協働で１つのアクセス標準の無線アクセスネットワーク（例えば５Ｇネットワーク）をサポートすることがあり、または、別個に異なるアクセス標準の無線アクセスネットワーク（例えばＬＴＥネットワーク、５Ｇネットワーク、または別のネットワーク）をサポートすることもある。メモリ１１０１４およびプロセッサ１１０１３は、１つまたは複数の基板にサービスすることがある。換言すれば、各基板に独立してメモリおよびプロセッサが配置されることがあり、または、複数の基板が同じメモリおよび同じプロセッサを共有することがある。さらに、必要な回路が、各基板にさらに配置されることがある。

【0551】

例えば、アクセスネットワークデバイスがターゲットドナーノードであるときには、ターゲットドナーノードのＣＵは、ＤＵを通して子ノードとの伝送を実施することがある。例えば、ダウンリンク方向では、ターゲットドナーノードのＣＵは、データ（例えばＰＤＣＰデータ）および／またはインジケーション情報を生成し、次いでＣＵとＤＵの間のインターフェースを通してそのデータをターゲットドナーノードのＤＵに送信することがあり、ターゲットドナーノードのＤＵは、そのデータをアンテナを通してＤＵの子ノードへ送信する。アップリンク方向では、ターゲットドナーノードのＤＵは、アンテナを通して子ノードからデータを受信し、次いでＣＵとＤＵの間のインターフェースを通してそのデータをターゲットドナーノードのＣＵへ送信することがある。

【0552】

例えば、アクセスネットワークデバイスがソースドナーノードであるときには、ソースドナーノードのＣＵは、ＤＵを通して子ノードとの伝送を実施することがある。例えば、ダウンリンク方向では、ソースドナーノードのＣＵは、データ（例えばＰＤＣＰデータ）および／またはインジケーション情報を生成し、次いでＣＵとＤＵの間のインターフェースを通してそのデータをソースドナーノードのＤＵに送信することがあり、ソースドナーノードのＤＵは、そのデータをアンテナを通してＤＵの子ノードへ送信する。アップリンク方向では、ソースドナーノードのＤＵは、アンテナを通して子ノードからデータを受信し、次いでＣＵとＤＵの間のインターフェースを通してそのデータをソースドナーノードのＣＵへ送信することがある。

【0553】

図２２は、本出願の実施形態による通信装置の構造の概略図である。通信装置は、前述の方法の実施形態に記載される方法を実施することがある。詳細については、前述の方法の実施形態の説明を参照されたい。通信装置は、通信デバイス、回路、ハードウェア構成要素、またはチップで使用され得る。例えば、通信装置は、端末、端末内のチップ、ドナーノード（ソースドナーノードもしくはターゲットドナーノードを含む）、ドナーノード（ソースドナーノードもしくはターゲットドナーノードを含む）内のチップ、リレーノード（第１のリレーノードおよび第２のリレーノードを含む）、またはリレーノード内のチップであることがある。

【0554】

装置１９００は、処理ユニット１９０１および通信ユニット１９０２を含む。任意選択で、通信装置１９００は、記憶ユニット１９０３をさらに含む。

【0555】

処理ユニット１９０１は、処理機能を有する装置であることがあり、１つまたは複数のプロセッサを含むことがある。プロセッサは、汎用プロセッサまたは専用プロセッサなどであることがある。プロセッサは、ベースバンドプロセッサまたは中央処理ユニットであることがある。ベースバンドプロセッサは、通信プロトコルおよび通信データを処理するように構成されることがある。中央処理ユニットは、装置（例えばドナーノード、端末、またはチップ）を制御し、ソフトウェアプログラムを実行し、ソフトウェアプログラムのデータを処理するように構成されることがある。

【0556】

通信ユニット１９０２は、信号を入力（受信）または出力（送信）するための装置であることがあり、別のネットワークデバイスまたはデバイス内の別の構成要素との信号伝送を実施するように構成される。

【0557】

記憶ユニット１９０３は、記憶機能を有する装置であることがあり、１つまたは複数のメモリを含むことがある。

【0558】

任意選択で、処理ユニット１９０１と、通信ユニット１９０２と、記憶ユニット１９０３とは、通信バスを用いて接続される。

【0559】

任意選択で、記憶ユニット１９０３は、独立して存在することがあり、通信バスを用いて処理ユニット１９０１に接続される。記憶ユニット１９０３は、あるいは、処理ユニット１９０１に一体化されることがある。

【0560】

任意選択で、本出願のこの実施形態では、通信装置１９００は、端末、またはドナーノード内のチップであることがある。通信ユニット１９０２は、入出力インターフェース、ピン、または回路などであることがある。記憶ユニット１９０３は、レジスタ、キャッシュ、またはＲＡＭなどであることがあり、記憶ユニット１９０３は、処理ユニット１９０１に一体化されることがある。記憶ユニット１９０３は、静的な情報および命令を記憶することができるＲＯＭまたは別のタイプの静的記憶デバイスであることがあり、記憶ユニット１９０３は、処理ユニット１９０１から独立していることがある。任意選択で、ワイヤレス通信技術の発展とともに、トランシーバが、通信装置１９００に一体化されることがある。例えば、図１９に示されるトランシーバ６１２が、通信ユニット１９０２に一体化される。

【0561】

可能な設計では、処理ユニット１９０１は、命令を含むことがあり、この命令がプロセッサ上で実行されて、通信装置１９００が前述の実施形態における端末またはドナーノードの方法を実施することを可能にすることがある。

【0562】

別の可能な設計では、記憶ユニット１９０３は、命令を記憶し、この命令が処理ユニット１９０１上で実行されて、通信装置１９００が前述の実施形態における端末またはドナーノードの方法を実施することを可能にすることがある。任意選択で、記憶ユニット１９０３は、データをさらに記憶することがある。任意選択で、処理ユニット１９０１はまた、命令および／またはデータを記憶することもある。

【0563】

通信装置１９００は、本出願の実施形態における端末であることがある。端末の概略図は、図１９に示され得る。任意選択で、装置１９００の通信ユニット１９０２は、端末のアンテナおよびトランシーバ、例えば図１９のアンテナ６１６およびトランシーバ６１２を含むことがある。任意選択で、通信ユニット１９０２は、出力デバイスおよび入力デバイス、例えば図１９の出力デバイス６１４および入力デバイス６１５をさらに含むことがある。

【0564】

通信装置１９００が本出願の実施形態における端末または端末のチップであることがあるときには、通信装置１９００は、前述の方法の実施形態において端末によって実装される機能を実装することがある。

【0565】

例えば、処理ユニット１９０１は、第１のベアラについて第１のＬＣＨおよび／または第２のＬＣＨを構成し、ソースドナーノードに対応する設定情報またはターゲットドナーノードに対応する設定情報を用いて受信されたダウンリンクデータまたは送信されるアップリンクデータを処理し、ソースドナーノードに対応する設定情報またはターゲットドナーノードに対応する設定情報を用いて処理されたアップリンクデータを第１のＬＣＨまたは第２のＬＣＨにマッピングし、第２のインジケーション情報に基づいてターゲットドナーノードに対応するＰＤＣＰ設定情報を用いてアップリンクデータを処理し、このインジケーション情報に基づいて第１のＬＣＨを削除することがある。通信ユニット１９０２は、端末の親ノードとの伝送を実装することがあり、例えば、ダウンリンクデータを受信する、アップリンクデータを送信する、またはインジケーション情報を受信することがある。

【0566】

通信装置１９００が本出願の実施形態におけるソースドナーノードまたはソースドナーノードのチップであることがあるときには、通信装置１９００は、前述の方法の実施形態におけるソースドナーノードの機能を実装することがある。

【0567】

例えば、処理ユニット１９０１は、前述の方法の実施形態においてソースドナーノードによって生成されるインジケーション情報またはデータを生成することがある。例えば、通信ユニット１９０２は、ソースドナーノードの子ノードとの伝送を実施することがあり、例えば、データおよび／もしくはインジケーション情報を子ノードへ送信する、またはデータおよび／もしくはインジケーション情報を子ノードから受信することがある。

【0568】

通信装置１９００が本出願の実施形態におけるターゲットドナーノードまたはターゲットドナーノードのチップであることがあるときには、通信装置１９００は、前述の方法の実施形態におけるターゲットドナーノードの機能を実装することがある。

【0569】

例えば、処理ユニット１９０１は、前述の方法の実施形態においてターゲットドナーノードによって生成されるインジケーション情報またはデータを生成することがある。例えば、通信ユニット１９０２は、ターゲットドナーノードの子ノードとの伝送を実施することがあり、例えば、データおよび／もしくはインジケーション情報を子ノードへ送信する、またはデータおよび／もしくはインジケーション情報を子ノードから受信することがある。

【0570】

以上、本出願の実施形態の方法の流れ図について説明した。端末は、端末の方法またはステップに対応する機能ユニット（手段）を有することがあり、リレーノードは、リレーノードの方法またはステップに対応する機能ユニットを有することがあり、ソースドナーノード（例えばＣＵおよび／またはＤＵ）は、ソースドナーノード（例えばＣＵおよび／またはＤＵ）の方法またはステップに対応する機能ユニットを有することがあり、ターゲットドナーノード（例えばＣＵおよび／またはＤＵ）は、ターゲットドナーノード（例えばＣＵおよび／またはＤＵ）の方法またはステップに対応する機能ユニットを有することがあり、ソースドナーノードのＣＵは、ソースドナーノードのＣＵの方法またはステップに対応する機能ユニットを有することがあり、リレーシステム内の別のノードは、その別のノードに対応する機能ユニットを有することがあることを理解されたい。前述のモジュールまたはユニットのうちの１つまたは複数は、ソフトウェア、ハードウェア、またはそれらの組合せによって実装され得る。前述のモジュールまたはユニットのうちの任意の１つがソフトウェアによって実装されるときには、そのソフトウェアは、コンピュータプログラム命令の形態で存在し、メモリに記憶される。プロセッサは、プログラム命令を実行して前述の方法の手順を実装するように構成されることがある。

【0571】

本出願のプロセッサは、限定されるわけではないが、ソフトウェアを実行する以下の様々なコンピューティングデバイス、すなわち中央処理ユニット（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、マイクロコントローラユニット（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ ｕｎｉｔ、ＭＣＵ）、または人工知能プロセッサのうちの少なくとも１つを含み得る。各コンピューティングデバイスは、ソフトウェア命令を実行して動作または処理を実施するように構成された１つまたは複数のコアを含むことがある。プロセッサは、別個の半導体チップであることもあるし、別の回路と一体化されて半導体チップになる、例えば別の回路（例えばコーデック回路、ハードウェア加速回路、または様々なバスおよびインターフェース回路）とともにシステムオンチップ（ｓｙｓｔｅｍ ｏｎ ａ ｃｈｉｐ、ＳｏＣ）を形成することもあるし、または特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ、ＡＳＩＣ）にＡＳＩＣの内臓プロセッサとして一体化されることがある。プロセッサと一体化されたＡＳＩＣは、別個にパッケージングされることがあり、または、別の回路と一緒にパッケージングされることがある。プロセッサは、ソフトウェア命令を実行して動作または処理を実施するためのコアを含み、必要なハードウェアアクセラレータ、例えばフィールドプログラマブルゲートアレイ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ、ＦＰＧＡ）、プログラマブル論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＰＬＤ）、または特殊目的論理動作を実施する論理回路をさらに含むことがある。

【0572】

本出願の実施形態におけるメモリは、以下のタイプ、すなわち静的な情報および命令を記憶することができる読取り専用メモリ（ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＲＯＭ）もしくは別のタイプの静的ストレージデバイス、または情報および命令を記憶することができるランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）もしくは別のタイプの動的ストレージデバイスのうちの少なくとも１つを含むことがあり、または、あるいは電気的消去可能プログラマブル読取り専用メモリ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＥＥＰＲＯＭ）であることがある。いくつかのシナリオでは、メモリは、あるいは、コンパクトディスク読取り専用メモリ（ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＣＤ－ＲＯＭ）もしくは別のコンパクトディスクストレージ、光学ディスクストレージ（コンパクト光学ディスク、レーザディスク、光学ディスク、デジタル汎用ディスク、もしくはＢｌｕ－ｒａｙディスクなどを含む）、磁気ディスクストレージ媒体もしくは別の磁気ストレージデバイス、または予想されるプログラムコードを命令もしくはデータ構造の形態で搬送もしくは記憶するために使用されることが可能で、コンピュータにアクセスされることが可能な任意の他の媒体であることがある。ただし、メモリはこれらに限定されない。

【0573】

データバスに加えて、バスは、電力バス、制御バス、およびステータス信号バスなどをさらに含むことがある。ただし、説明を分かりやすくするために、図中の様々なタイプのバスは、バスとして記されている。

【0574】

実装プロセスでは、前述の方法のステップは、プロセッサ内のハードウェアの一体化された論理回路によって実装されることも、またはソフトウェアの形態の命令を用いて実装されることも可能である。本出願の実施形態を参照して開示される方法のステップは、ハードウェアプロセッサによって直接実施されることがあり、またはプロセッサ内のハードウェアとソフトウェアモジュールとの組合せによって実施されることがある。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、読取り専用メモリ、プログラマブル読取り専用メモリ、電気的消去可能プログラマブルメモリ、またはレジスタなど、当技術分野における成熟したストレージ媒体に位置することがある。ストレージ媒体は、メモリ内に位置し、プロセッサは、メモリ内の情報を読み取り、そのプロセッサのハードウェアと組み合わせて前述の方法のステップを完了する。繰り返しを避けるために、詳細は、本明細書では、再度説明されない。

【0575】

本出願の実施形態で提供される方法によれば、本出願の実施形態は、前述の装置および１つまたは複数のネットワークデバイスを含むシステムをさらに提供する。

【0576】

本明細書における第１、第２、第３、第４、および様々な数字は、単に説明を容易にするための区別のために用いられているものであり、本出願の実施形態の範囲を限定することは意図されていないことをさらに理解されたい。これらの数字は、他の数字と置き換えられることもある。

【0577】

本明細書における「および／または」という用語は、関連するオブジェクト間の関連関係のみを述べるものであり、３つの関係が存在し得ることを示していることを理解されたい。例えば、Ａおよび／またはＢは、以下の３つの場合、すなわちＡのみが存在する場合、ＡおよびＢの両方が存在する場合、ならびにＢのみが存在する場合を示し得る。さらに、「／」という文字は、一般に関連するオブジェクトの間の「または」の関係を示す。

【0578】

前述のプロセスの続き番号は、本出願の様々な実施形態における実行順序を意味していないことを理解されたい。プロセスの実行順序は、プロセスの機能および内部論理に基づいて決定されるものとし、本出願の実施形態の実装プロセスに対するいかなる限定とも解釈されないものとする。

【0579】

当業者なら、本出願は、本明細書に開示される実施形態に記載される様々な例示的な論理ブロック（ｉｌｌｕｓｔｒａｔｉｖｅ ｌｏｇｉｃａｌ ｂｌｏｃｋ）およびステップ（ｓｔｅｐ）と組み合わせて、電子ハードウェアによって、またはコンピュータソフトウェアと電子ハードウェアの組合せによって実装されることが可能であることに気づき得る。機能がハードウェアによって実施されるかソフトウェアによって実施されるかは、技術的解決策の個々の応用分野および設計制約条件によって決まる。当業者なら、様々な方法を使用して、記載される機能を各特定の応用分野用に実装し得るが、その実装は、本出願の範囲を逸脱しないとみなされるものとする。

【0580】

本出願で提供されるいくつかの実施形態では、開示されるシステム、装置、および方法は、他の方式で実装されることもあることを理解されたい。例えば、前述の装置の実施形態は、単なる例である。例えば、ユニットの分割は、単に論理的な機能の分割に過ぎず、実際の実装では他の分割になることもある。例えば、複数のユニットまたは構成要素が結合または統合されて別のシステムになることがあり、または、いくつかの特徴が無視される、または実行されないことがある。さらに、表示または記載される相互の結合または直接の結合もしくは通信接続は、いくつかのインターフェースを用いて実装されることがある。装置またはユニット間の間接的な結合または通信接続は、電子形態、機械形態、またはその他の形態で実装され得る。

【0581】

前述の実施形態の全てまたは一部は、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せによって実装され得る。実施形態を実装するためにソフトウェアが使用されるときには、それらの実施形態の全てまたは一部は、コンピュータプログラム製品の形態で実装されることがある。コンピュータプログラム製品は、１つまたは複数のコンピュータ命令を含む。コンピュータプログラム命令がロードされてコンピュータ上で実行されたときに、本出願の実施形態による手順または機能の全てまたは一部が生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、またはその他のプログラマブル装置であることがある。コンピュータ命令は、コンピュータ可読ストレージ媒体に記憶されることがあり、または、コンピュータ可読ストレージ媒体から別のコンピュータ可読ストレージ媒体へ伝送されることがある。例えば、コンピュータ命令は、有線方式（例えば同軸ケーブル、光ファイバ、もしくはデジタル加入者回線（ｄｉｇｉｔａｌ ｓｕｂｓｃｒｉｂｅｒ ｌｉｎｅ、ＤＳＬ））またはワイヤレス方式（例えば赤外線、無線、もしくはマイクロ波）で、ウェブサイト、コンピュータ、サーバ、またはデータセンタから別のウェブサイト、コンピュータ、サーバ、またはデータセンタへ伝送されることがある。コンピュータ可読ストレージ媒体は、コンピュータからアクセス可能な任意の使用可能な媒体、または１つもしくは複数の使用可能な媒体を一体化した、サーバもしくはデータセンタなどのデータストレージデバイスであることがある。使用可能な媒体は、磁気媒体（例えばフロッピーディスク、ハードディスク、もしくは磁気テープ）、光学媒体（例えばデジタル汎用ディスク（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｃ、ＤＶＤ）、または半導体媒体（例えばソリッドステートドライブなどであることがある。

【0582】

以上の説明は、単に本出願の具体的な実装に過ぎず、本出願の保護範囲を限定することは意図されていない。本出願に開示される技術的範囲内の当業者には容易に分かる任意の変形または置換は、本出願の保護範囲に含まれるものとする。したがって、本出願の保護範囲は、特許請求の範囲の保護範囲によって決まるものとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9A】

【図9B】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17A】

【図17B】

【図17C】

【図17D】

【図17E】

【図18A】

【図18B】

【図18C】

【図18D】

【図19】

【図20】

【図21】

【図22】