JP7482997B2 - データパケット送信方法および装置 - Google Patents

Description

本出願は、ワイヤレス通信技術の分野に関し、詳細には、データパケット送信方法および装置に関する。

統合されたアクセスおよびバックホール（ｉｎｔｅｇｒａｔｅｄ ａｃｃｅｓｓ ａｎｄ ｂａｃｋｈａｕｌ，ＩＡＢ）ネットワーク技術が、第５世代（５ｔｈ ｇｅｎｅｒａｔｉｏｎ，５Ｇ）モバイル通信システムに導入されている。ワイヤレス送信の解決策が、ＩＡＢネットワークにおけるアクセスリンク（ａｃｃｅｓｓ ｌｉｎｋ）とバックホールリンク（ｂａｃｋｈａｕｌ ｌｉｎｋ）の両方に使用され、光ファイバの導入を避け、導入コストを低減し、導入のフレキシビリティを改善する。ＩＡＢネットワークは、ＩＡＢノード（ＩＡＢ ｎｏｄｅ）およびＩＡＢドナー（ＩＡＢ ｄｏｎｏｒ）を含む。端末側デバイスは、ＩＡＢノードにアクセスすることがあり、端末側デバイスのトラフィックデータは、ワイヤレスバックホールリンクを介してＩＡＢノードからＩＡＢドナーに送信されることがある。

しかしながら、既存のベアラマッピングは、主に、Ｆ１インターフェース上でＩＡＢノードとドナーノードとの間で送信されるＦ１ユーザプレーン（Ｆ１ ｕｓｅｒ ｐｌａｎｅ，Ｆ１－Ｕ）データペイロードおよびＦ１制御プレーン（Ｆ１ ｃｏｎｔｒｏｌ ｐｌａｎｅ，Ｆ１－Ｃ）データペイロード上で実行される。実際には、ＩＡＢノードとドナーノードとの間で送信される必要がある他のタイプのデータペイロード、すなわち、Ｆ１ユーザプレーンデータペイロードおよびＦ１制御プレーンデータペイロード以外のデータペイロードが存在する。これらのデータペイロードは、非Ｆ１トラフィック（ｎｏｎ－Ｆ１ ｔｒａｆｆｉｃ）データペイロードとまとめて呼ばれることがある。ワイヤレスバックホールリンク上の非Ｆ１トラフィックデータパケットに対するベアラマッピングをどのように実行するかは、従来の技術には関与しておらず、できる限り早く解決される必要がある問題である。

本出願の実装は、データパケット送信方法および装置を提供し、バックホールリンク上でデータペイロードに対するベアラマッピングをどのように実行するかという対応する問題を解決する。

第１の態様によれば、本出願の実施形態は、以下のことを含むデータパケット送信方法を提供する。ＩＡＢドナーが、第１の設定情報を決定し、第１の設定情報は、第１のＢＨ ＲＬＣチャネルを示すために使用され、第１のＢＨ ＲＬＣチャネルは、ＢＡＰレイヤにおいて制御ＰＤＵを送信するために使用される。ＩＡＢドナーが、第１の設定情報をＩＡＢノードに送信する。

前述の手順によれば、ＩＡＢドナーは、第１の設定情報を使用することによって、ＩＡＢノードがＢＡＰレイヤにおいて第１のＢＨ ＲＬＣチャネルを介して制御ＰＤＵを送信することを示し、ＩＡＢノードがＢＡＰレイヤにおいて制御ＰＤＵを送信する必要があるとき、ベアラマッピングを実施する。

可能な実装では、第１の設定情報が、第１のＢＨ ＲＬＣチャネルのチャネル識別子を含むか、または、
第１の設定情報が、論理チャネル識別子を含み、論理チャネル識別子によって示される論理チャネルは、第１のＢＨ ＲＬＣチャネルに対応する。

第２の態様によれば、データパケット送信方法が提供され、本方法は以下のことを含む。ＩＡＢノードが、ＢＡＰレイヤにおいて制御ＰＤＵを送信するために使用される第１のＢＨ ＲＬＣチャネルを決定する。ＩＡＢノードが、ＢＡＰレイヤにおいて制御ＰＤＵを、第１のＢＨ ＲＬＣチャネルを介してＩＡＢノードの隣接ノードに送信する。

前述の手順によれば、ＩＡＢドナーは、第１の設定情報を使用することによって、ＩＡＢノードがＢＡＰレイヤにおいて第１のＢＨ ＲＬＣチャネルを介して制御ＰＤＵを送信することを示し、ＩＡＢノードがＢＡＰレイヤにおいて制御ＰＤＵを送信する必要があるとき、ベアラマッピングを実施する。

可能な実装では、ＩＡＢノードがＢＡＰレイヤにおいて制御ＰＤＵを送信するために使用される第１のバックホールリンクＢＨ ＲＬＣチャネルを決定することは、以下のことを含む。ＩＡＢノードが、ＩＡＢドナーから第１の設定情報を取得し、第１の設定情報は、ＢＡＰレイヤにおいて制御ＰＤＵを送信するために使用される第１のＢＨ ＲＬＣチャネルを示すために使用される。ＩＡＢノードが、第１の設定情報に基づいて第１のＢＨ ＲＬＣチャネルを決定する。

可能な実装では、第１の設定情報が、第１のＢＨ ＲＬＣチャネルのチャネル識別子を含むか、または、第１の設定情報が、論理チャネル識別子を含み、論理チャネル識別子によって示される論理チャネルは、第１のＢＨ ＲＬＣチャネルに対応する。

第３の態様によれば、データパケット送信方法が提供され、本方法は以下のことを含む。ＩＡＢドナーが、第２の設定情報を決定し、第２の設定情報は、第２のバックホールリンクＢＨ無線リンク制御ＲＬＣチャネルを示すために使用され、第２のＢＨ ＲＬＣチャネルは、第１のタイプのデータペイロードを送信するために使用され、第１のタイプのデータペイロードは、Ｆ１ユーザプレーンＦ１－ＵデータペイロードおよびＦ１制御プレーンＦ１－Ｃデータペイロード以外のデータペイロードである。ＩＡＢドナーが、第２の設定情報をＩＡＢノードに送信する。

前述の手順によれば、ＩＡＢドナーは、第２の設定情報を使用することによって、ＩＡＢノードが第２のＢＨ ＲＬＣチャネルを介して第１のタイプのデータペイロードを送信することを示し、第１のタイプのデータペイロードに関するベアラマッピングを実施する。

可能な実装では、第１のタイプのデータペイロードは、以下の、
運用、管理、および保守ＯＡＭトラフィックパケットと、インターネットプロトコルＩＰアドレスを要求するために使用されるパケットと、インターネットプロトコルセキュリティＩＰｓｅｃ送信チャネルを確立するために使用されるパケットと、ストリーム制御トランスポートプロトコルＳＣＴＰアソシエーションセットアップパケットと、ＳＣＴＰアソシエーションシャットダウンパケットと、ＳＣＴＰアソシエーションハートビートパケットとのうちのいずれか１つを含む。

可能な実装では、第２の設定情報は、以下の、
第１のタイプであって、データペイロードのタイプであり、第２のＢＨ ＲＬＣチャネルに対応する第１のタイプと、第１の差別化されたサービス情報であって、第１のタイプおよび／または第２のＢＨ ＲＬＣチャネルに対応する第１の差別化されたサービス情報と、第１のフローラベルであって、第１のタイプおよび／または第２のＢＨ ＲＬＣチャネルに対応する第１のフローラベルとのうちのいずれか１つまたは複数を含む。

可能な実装では、本方法は、以下のことをさらに含む。ＩＡＢドナーが、第１のデータペイロードを生成し、第１のデータペイロードは、第１のタイプのデータペイロードである。第１のデータペイロードに対応するパケットヘッダ情報が第１の差別化されたサービス情報を搬送する場合、ＩＡＢドナーは、第１の差別化されたサービス情報に対応する第２のＢＨ ＲＬＣチャネルを介してＩＡＢノードに第１のデータパケットを送信するか、または、第１のデータペイロードに対応するパケットヘッダ情報が第１のフローラベルを搬送する場合、ＩＡＢドナーは、第１のフローラベルに対応する第２のＢＨ ＲＬＣチャネルを介してＩＡＢノードに第１のデータパケットを送信し、第１のデータパケットは、第１のデータペイロードを含む。

可能な実装では、第２の設定情報は、第２のＢＨ ＲＬＣチャネルを識別するために使用される識別情報を含み、識別情報は、第２のＢＨ ＲＬＣチャネルのチャネル識別子であるか、または、識別情報は、第２のＢＨ ＲＬＣチャネルに対応する論理チャネル識別子である。

第４の態様によれば、データパケット送信方法が提供され、本方法は以下のことを含む。ＩＡＢノードが、ＩＡＢドナーから第２の設定情報を受信し、第２の設定情報は、第２のバックホールリンクＢＨ無線リンク制御ＲＬＣチャネルを示すために使用され、第２のＢＨ ＲＬＣチャネルは、第１のタイプのデータペイロードを送信するために使用され、第１のタイプのデータペイロードは、Ｆ１ユーザプレーンＦ１－ＵデータペイロードおよびＦ１制御プレーンＦ１－Ｃデータペイロード以外のデータペイロードである。ＩＡＢノードが、第２の設定情報に基づいて第１のタイプのデータペイロードを送信する。

前述の手順によれば、ＩＡＢノードは、ＩＡＢドナーによって送信された第２の設定情報を使用することによって、第１のタイプのデータペイロードが第２のＢＨ ＲＬＣチャネルを介して送信されることを決定し、第１のタイプのデータペイロードに関してベアラマッピングを実施する。

可能な実装では、第１のタイプのデータペイロードは、以下の、
運用、管理、および保守ＯＡＭトラフィックパケットと、インターネットプロトコルＩＰアドレスを要求するために使用されるパケットと、インターネットプロトコルセキュリティＩＰｓｅｃ送信チャネルを確立するために使用されるパケットと、ストリーム制御トランスポートプロトコルＳＣＴＰアソシエーション設定パケットと、ＳＣＴＰアソシエーションシャットダウンパケットと、ＳＣＴＰアソシエーションハートビートパケットとのうちのいずれか１つを含む。

可能な実装では、第２の設定情報は、以下の、
第１のタイプであって、データペイロードのタイプであり、第２のＢＨ ＲＬＣチャネルに対応する第１のタイプと、第１の差別化されたサービス情報であって、第１のタイプおよび／または第２のＢＨ ＲＬＣチャネルに対応する第１の差別化されたサービス情報と、第１のフローラベルであって、第１のタイプおよび／または第２のＢＨ ＲＬＣチャネルに対応する第１のフローラベルとのうちのいずれか１つまたは複数を含む。

可能な実装では、第２の設定情報は、第２のＢＨ ＲＬＣチャネルを識別するために使用される識別情報を含み、識別情報は、第２のＢＨ ＲＬＣチャネルのチャネル識別子であるか、または、識別情報は、第２のＢＨ ＲＬＣチャネルに対応する論理チャネル識別子である。

第５の態様によれば、データパケット送信方法が提供され、本方法は以下のことを含む。ＩＡＢドナーが、第３のデータペイロードに対応するパケットヘッダ情報に基づいて第１のラベルを決定し、第１のラベルは、第３のデータペイロードの出口無線リンク制御ＲＬＣチャネルを決定するために使用される。ＩＡＢドナーが、ＩＡＢノードに第３のデータパケットを送信し、第３のデータパケットは、第３のデータペイロードおよび第１のバックホール適応プロトコルＢＡＰレイヤヘッダを含み、第１のＢＡＰレイヤヘッダは、第１のラベルを含む。

前述の手順によれば、ＩＡＢドナーは、第１のラベルを使用して第３のデータペイロードの出口無線リンク制御ＲＬＣチャネルを示し、第３のデータペイロードの入口ＲＬＣチャネルのみに基づいて第３のデータペイロードの出口ＲＬＣチャネルを決定しなくなり、第３のデータペイロードのフレキシブルな送信を実施する。

可能な実装では、ＩＡＢドナーが第３のデータペイロードに対応するパケットヘッダ情報に基づいて第１のラベルを決定することは、以下のことを含む。

ＩＡＢドナーが、第３の設定情報を取得する。ＩＡＢドナーが、第３のデータペイロードに対応するパケットヘッダ情報および第３の設定情報に基づいて第１のラベルを決定し、第３の設定情報は、パケットヘッダ情報内の第１の情報と第１のラベルとの間の対応付けを設定するために使用され、第１の情報は、以下の、
第１の差別化されたサービス情報と、第１のフローラベルと、第１のインターネットプロトコルＩＰアドレスとのいずれか１つまたは複数を含む。

第６の態様によれば、データパケット送信方法が提供され、本方法は以下のことを含む。第２のＩＡＢノードが、第４のデータペイロードを取得する。第２のＩＡＢノードが、第４のデータペイロードに対応するパケットヘッダ情報または第４のデータペイロードに対応するメッセージタイプに基づいて第２のラベルを決定し、第２のラベルは、第４のデータペイロードの出口無線リンク制御ＲＬＣチャネルを決定するために使用される。第２のＩＡＢノードが、第１のＩＡＢノードに第４のデータパケットを送信し、第４のデータパケットは、第４のデータペイロードおよび第２のバックホール適応プロトコルＢＡＰレイヤヘッダを含み、第２のＢＡＰレイヤヘッダは、第２のラベルを含む。

可能な実装では、第２のＩＡＢノードが第４のデータペイロードに対応するパケットヘッダ情報に基づいて第２のラベルを決定することは、以下のことを含む。

第２のＩＡＢノードが、ＩＡＢドナーから第４の設定情報を受信する。

第２のＩＡＢノードが、第４のデータペイロードに対応するパケットヘッダ情報および第４の設定情報に基づいて第２のラベルを決定する。

第４の設定情報は、パケットヘッダ情報内の第２の情報と第２のラベルとの間の対応付けを設定するために使用され、第２の情報は、以下の、
パケットヘッダ情報内の第２の差別化サービス情報と、パケットヘッダ情報内の第２のフローラベルと、パケットヘッダ情報内の第２のＩＰアドレスと、パケットヘッダ情報内にあり、第４のデータペイロードに対応するデータ無線ベアラ情報と、第４のデータペイロードの第２のタイプと、第４のデータペイロードがＦ１ＡＰメッセージであるとき、Ｆ１ＡＰメッセージを搬送するＳＣＴＰレイヤにおけるストリーム識別子とのうちのいずれか１つまたは複数を含む。

可能な実装では、第２のＩＡＢノードが第４のデータペイロードに対応するメッセージタイプに基づいて第２のラベルを決定することは、以下のことを含む。

第２のＩＡＢノードが、ＩＡＢドナーから第４の設定情報を受信する。

第２のＩＡＢノードが、第４のデータペイロードに対応するメッセージタイプに基づいて第４の設定情報から第２のラベルを決定する。

第４のデータペイロードは、制御プレーンＦ１アプリケーションプロトコルＦ１ＡＰメッセージであり、第４の設定情報は、以下の、
第４のデータペイロードの第２のタイプと、第２のタイプに対応する第２のラベルとの１つまたは複数を含み、第２のタイプは、Ｆ１ＡＰメッセージタイプ、すなわち、
第４のデータペイロードがＦ１ＡＰメッセージであるとき、Ｆ１ＡＰメッセージを搬送するＳＣＴＰレイヤにおけるストリーム識別子と、ストリーム識別子に対応する第２のラベルとのいずれか１つまたは複数である。

第７の態様によれば、データパケット送信方法が提供され、本方法は以下のことを含む。

第１の統合されたアクセスおよびバックホールＩＡＢノードが、データパケットを取得し、データパケットは、第２のＩＡＢノードからのデータパケットまたはＩＡＢドナーからのデータパケットであり、データパケットのバックホール適応プロトコルＢＡＰレイヤヘッダは、第３のラベルを含み、第３のラベルは、データパケットの出口無線リンク制御ＲＬＣチャネルを決定するために使用される。

第１のＩＡＢノードが、第３のラベルに基づいて第３のＲＬＣチャネル識別子を決定し、第３のＲＬＣチャネル識別子は、データパケットの出口ＲＬＣチャネルの識別子である。

第１のＩＡＢノードが、第３のＲＬＣチャネル識別子に対応する出口ＲＬＣチャネルを介してデータパケットを送信する。

可能な実装では、第１のＩＡＢノードが第３のラベルに基づいて第３のＲＬＣチャネル識別子を決定することは、以下のことを含む。

第１のＩＡＢノードが、ＩＡＢドナーから第５の設定情報を受信し、第５の設定情報は、第３のラベルと第３のＲＬＣチャネル識別子との間の対応付けを設定するために使用される。

第１のＩＡＢノードが、第３のＲＬＣチャネル識別子として、第５の設定情報内にあり第３のラベルに対応するＲＬＣチャネル識別子を決定する。

代替として、第１のＩＡＢノードが、第３のＲＬＣチャネル識別子として、第５の設定情報内にあり第３のラベルに対応するＲＬＣチャネル識別子と第４のＲＬＣチャネル識別子とを決定し、第４のＲＬＣチャネル識別子は、データパケットを受信するための入口ＲＬＣチャネルの識別子である。

代替として、第１のＩＡＢノードが、第５の設定情報から、第３のラベルに対応する第１のサービス品質ＱｏＳ識別子を決定し、第３のＲＬＣチャネル識別子として、第５の設定情報内にあり第１のＱｏＳ識別子に対応するＲＬＣチャネル識別子を決定する。

代替として、第１のＩＡＢノードが、第５の設定情報から、第３のラベルに対応する第１のＱｏＳパラメータを決定し、第３のＲＬＣチャネル識別子として、第５の設定情報内にあり第１のＱｏＳパラメータに対応するＲＬＣチャネル識別子を決定する。

可能な実装では、第５の設定情報は、以下の、
第３のラベルと第３のＲＬＣチャネル識別子との間の対応付けと、
第３のラベル、第４のＲＬＣチャネル識別子、および第３のＲＬＣチャネル識別子の間の対応付けと、
第３のラベルとサービス品質ＱｏＳ識別子との間の対応付けと、
ＱｏＳ識別子と第３のＲＬＣチャネル識別子との間の対応付けと、
第３のラベルとＱｏＳパラメータとの間の対応付けと、
ＱｏＳパラメータと第３のＲＬＣチャネル識別子との間の対応付けとのいずれか１つまたは複数を含む。

第８の態様によれば、本出願は、通信装置をさらに提供する。通信装置は、前述の態様のいずれか１つにおいて提供された任意の方法を実施する機能を有する。通信装置は、ハードウェアによって実装されることがあるか、または対応するソフトウェアを実行するハードウェアによって実装されることがある。ハードウェアまたはソフトウェアは、前述の機能に対応する１つまたは複数のユニットを含む。

可能な実装では、通信装置は、プロセッサを含み、プロセッサは、前述の方法における第１のＩＡＢノード、第２のＩＡＢノード、ＩＡＢドナー、またはＩＡＢノードの対応する機能を実行する際に通信装置をサポートするように構成される。通信装置はメモリをさらに含むことがあり、メモリは、プロセッサに結合されることがあり、通信装置に必要なプログラム命令およびデータを記憶する。任意選択で、通信装置は、通信インターフェースをさらに含み、通信インターフェースは、通信装置と、第１のＩＡＢノード、第２のＩＡＢノード、ＩＡＢドナー、またはＩＡＢノードなどのデバイスとの間の通信をサポートするように構成される。

可能な実装では、通信装置は、前述の方法におけるステップを実施するようにそれぞれ構成された対応する機能ユニットを含む。機能は、ハードウェアによって実装されることがあるか、または対応するソフトウェアを実行するハードウェアによって実装されることがある。ハードウェアまたはソフトウェアは、前述の機能に対応する１つまたは複数のユニットを含む。

可能な実装では、通信装置の構造は、処理ユニットおよび通信ユニットを含む。これらのユニットは、前述の方法の例における対応する機能を実行し得る。詳細に関しては、前述の態様のいずれか１つによる方法における説明を参照されたい。詳細は、本明細書では再び説明されない。

第９の態様によれば、本出願は、プロセッサおよびメモリを含む通信装置を提供する。メモリは、コンピュータ実行可能命令を記憶するように構成され、本装置が動作するとき、プロセッサは、メモリに記憶されたコンピュータ実行可能命令を実行し、その結果、本装置は、前述の態様における方法を実行する。

第１０の態様によれば、本出願は、前述の態様におけるステップを実行するように構成されたユニットまたは手段（ｍｅａｎｓ）を含む通信装置を提供する。

第１１の態様によれば、本出願は、プロセッサおよび通信インターフェースを含む通信装置を提供する。プロセッサは、通信インターフェースを介して別の装置と通信し、前述の態様における方法を実行するように構成される。１つまたは複数のプロセッサが存在する。

第１２の態様によれば、本出願は、少なくとも１つのメモリに接続し、少なくとも１つのメモリに記憶されたプログラムを呼び出し、前述の態様における方法を実行するように構成されたプロセッサを含む通信装置を提供する。少なくとも１つのメモリは、装置の内部に配置されることがあり、または装置の外部に配置されることがある。加えて、１つまたは複数のプロセッサが存在する。

第１３の態様によれば、本出願は、コンピュータ可読記憶媒体をさらに提供する。コンピュータ可読記憶媒体は、命令を記憶し、命令がコンピュータ上で実行されるとき、コンピュータは、前述の態様における方法を実行することを可能にされる。

第１４の態様によれば、本出願は、命令を含むコンピュータプログラム製品をさらに提供し、コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、前述の態様における方法を実行することを可能にされる。

第１５の態様によれば、本出願は、前述の態様における方法を実行するように構成されたプロセッサを含むチップシステムをさらに提供する。

第１６の態様によれば、本出願は、上記で提供された第１のＩＡＢノード、第２のＩＡＢノード、およびＩＡＢドナーを含むチップシステムをさらに提供する。

本出願の実施形態が適用可能な通信システムの概略図である。 本出願の実施形態によるＩＡＢドナーの構造の概略図である。 本出願の実施形態による、ＲＬＣチャネル、論理チャネル、およびプロトコルエンティティの間の対応付けの概略図である。 本出願の実施形態による、ＲＬＣチャネル、論理チャネル、およびプロトコルエンティティの間の対応付けの概略図である。 本出願の実施形態によるデータパケット送信方法の概略フローチャートである。 本出願の実施形態によるデータパケット送信方法の概略フローチャートである。 本出願の実施形態によるデータパケットの構造の概略図である。 本出願の実施形態によるデータパケット送信方法の概略フローチャートである。 本出願の実施形態によるデータパケットの構造の概略図である。 本出願の実施形態によるデータパケットの構造の概略図である。 本出願の実施形態によるデータパケット送信方法の概略フローチャートである。 本出願の実施形態によるデータパケット送信方法の概略フローチャートである。 本出願の実施形態によるデータパケット送信方法の概略フローチャートである。 本出願の実施形態による、非スタンドアロンモードにおけるネットワークアーキテクチャの概略図である。 本出願の実施形態による通信装置の構造の概略図である。 本出願の実施形態による通信装置の構造の概略図である。

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

本出願の実施形態は、様々なモバイル通信システム、例えば、新無線（ｎｅｗ ｒａｄｉｏ，ＮＲ）システム、ロングタームエボリューション（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ，ＬＴＥ）システム、ロングタームエボリューションアドバンスト（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ－ａｄｖａｎｃｅｄ，ＬＴＥ－Ａ）システム、発展型ロングタームエボリューション（ｅｖｏｌｖｅｄ ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ，ｅＬＴＥ）システム、将来の通信システム、および別の通信システムに適用され得る。具体的には、これは本明細書において限定されない。

本出願の実施形態では、端末側デバイスは、ワイヤレストランシーバ機能を有するデバイス、またはデバイス内に配置されることが可能であるチップである。ワイヤレストランシーバ機能を有するデバイスは、ユーザ機器（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ，ＵＥ）、アクセス端末、加入者ユニット、加入者局、移動局、リモート局、リモート端末、モバイルデバイス、ユーザ端末、ユーザエージェント、またはユーザ装置と呼ばれることもある。実際の適用では、本出願の実施形態における端末側デバイスは、携帯電話（ｍｏｂｉｌｅ ｐｈｏｎｅ）、タブレットコンピュータ（Ｐａｄ）、ワイヤレストランシーバ機能を有するコンピュータ、仮想現実（ｖｉｒｔｕａｌ ｒｅａｌｉｔｙ，ＶＲ）端末、拡張現実（ａｕｇｍｅｎｔｅｄ ｒｅａｌｉｔｙ，ＡＲ）端末、産業制御（ｉｎｄｕｓｔｒｉａｌ ｃｏｎｔｒｏｌ）におけるワイヤレス端末、自動運転（ｓｅｌｆ ｄｒｉｖｉｎｇ）におけるワイヤレス端末、遠隔医療（ｒｅｍｏｔｅ ｍｅｄｉｃａｌ）におけるワイヤレス端末、スマートグリッド（ｓｍａｒｔ ｇｒｉｄ）におけるワイヤレス端末、交通安全（ｔｒａｎｓｐｏｒｔａｔｉｏｎ ｓａｆｅｔｙ）におけるワイヤレス端末、スマートシティ（ｓｍａｒｔ ｃｉｔｙ）におけるワイヤレス端末、スマートホーム（ｓｍａｒｔ ｈｏｍｅ）におけるワイヤレス端末などであり得る。適用のシナリオは、本出願の実施形態において限定されない。本出願では、ワイヤレストランシーバ機能を有するデバイス、およびデバイス内に配置されることが可能であるチップは、まとめて端末側デバイスと呼ばれる。

本出願の実施形態では、ネットワーク側デバイスは、様々な規格における無線アクセスデバイス、例えば、発展型ノードＢ（ｅｖｏｌｖｅｄ ＮｏｄｅＢ，ｅＮＢ）、無線ネットワークコントローラ（ｒａｄｉｏ ｎｅｔｗｏｒｋ ｃｏｎｔｒｏｌｌｅｒ，ＲＮＣ）、ノードＢ（ＮｏｄｅＢ，ＮＢ）、基地局コントローラ（ｂａｓｅ ｓｔａｔｉｏｎ ｃｏｎｔｒｏｌｌｅｒ，ＢＳＣ）、基地トランシーバ局（ｂａｓｅ ｔｒａｎｓｃｅｉｖｅｒ ｓｔａｔｉｏｎ，ＢＴＳ）、ホーム基地局（例えば、ｈｏｍｅ ｅｖｏｌｖｅｄ ＮｏｄｅＢ、またはｈｏｍｅ ＮｏｄｅＢ，ＨＮＢ）、ベースバンドユニット（ｂａｓｅｂａｎｄ ｕｎｉｔ，ＢＢＵ）、ワイヤレスフィデリティ（ｗｉｒｅｌｅｓｓ ｆｉｄｅｌｉｔｙ，Ｗｉ－Ｆｉ）システムにおけるアクセスポイント（ａｃｃｅｓｓ ｐｏｉｎｔ，ＡＰ）、ワイヤレス中継ノード、ワイヤレスバックホールノード、または送信ポイント（ｔｒａｎｓｍｉｓｓｉｏｎ ｒｅｃｅｐｔｉｏｎ ｐｏｉｎｔ，ＴＲＰまたはｔｒａｎｓｍｉｓｓｉｏｎ ｐｏｉｎｔ，ＴＰ）であり得る。ネットワーク側デバイスは、代替として、５Ｇ（ＮＲ）システムにおけるｇＮＢまたは送信ポイント（ＴＲＰまたはＴＰ）、５Ｇシステムにおける基地局の１つまたは一群のアンテナパネル（複数のアンテナパネルを含む）、ｇＮＢまたは送信ポイントを構成するネットワークノード、例えば、ベースバンドユニット（ＢＢＵ）、中央ユニット分散型ユニット（ｃｅｎｔｒａｌ ｕｎｉｔ－ｄｉｓｔｒｉｂｕｔｅｄ ｕｎｉｔ，ＣＵ－ＤＵ）アーキテクチャにおけるＤＵまたはＣＵなどであり得る。

本出願の実施形態では、ワイヤレス通信ネットワークにおけるＩＡＢのシナリオが、いくつかのシナリオを説明するための例として使用される。本出願の実施形態における解決策は、別のワイヤレス通信ネットワークにさらに適用されてよく、対応する名称は、別のワイヤレス通信ネットワークにおける対応する機能の名称と置き換えられてもよいことに留意されたい。

本出願の実施形態の理解を容易にするために、図１に示される通信システムが、本出願の実施形態が適用可能な通信システムを詳細に説明するための例として最初に使用される。図１は、本出願の実施形態が適用可能な通信システムの概略図である。図１に示されるように、通信システムは、基地局と、ＩＡＢドナーと、ＩＡＢノード１と、ＩＡＢノード２と、端末側デバイスとを含む。

本出願のこの実施形態では、統合されたアクセスおよびバックホールをサポートするノードは、ＩＡＢノードと呼ばれ、ＩＡＢノードは、中継ノード（ｒｅｌａｙ ｎｏｄｅ，ＲＮ）と呼ばれることもある。説明を容易にするために、ノードと中継ノードの両方は、以下でＩＡＢノードと呼ばれる。ＩＡＢノードは、端末側デバイスにワイヤレスアクセスサービスを提供することがあり、端末側デバイスのトラフィックデータまたは制御情報は、ワイヤレスバックホールリンクを介してＩＡＢノードからＩＡＢドナー（ＩＡＢ ｄｏｎｏｒ）または別のネットワーク側デバイスに送信される。ＩＡＢノードは、少なくとも１つのモバイル端末（ｍｏｂｉｌｅ ｔｅｒｍｉｎａｌ，ＭＴ）ユニットおよび少なくとも１つの分散型ユニット（ｄｉｓｔｒｉｂｕｔｅｄ ｕｎｉｔ，ＤＵ）を含み得る。本出願のこの実施形態では、ＩＡＢノードが１つのＭＴユニットおよび１つのＤＵを含む例のみが、説明のために使用される。ＩＡＢノード内のＭＴユニットは、ＩＡＢノードが、ＩＡＢノードの親ノードおよびＩＡＢドナーと通信するための端末として機能することを実施する。ＩＡＢノード内のＤＵは、端末側デバイス、またはＤＵに取り付けられた別のＩＡＢノードにアクセスサービスを提供し、Ｆ１インターフェースを介してＩＡＢドナーと通信することもある。ＩＡＢノード内のＭＴユニットは、ＩＡＢノード内のＭＴ機能エンティティと呼ばれることもあり、ＩＡＢノード内のＤＵは、ＩＡＢノード内のＤＵ機能エンティティと呼ばれることもある。説明を容易にするために、ＩＡＢノード内のＭＴユニットとＩＡＢノード内のＭＴ機能エンティティの両方は、簡潔に「ＩＡＢノードＭＴ」と呼ばれ、ＩＡＢノード内のＤＵとＩＡＢノード内のＤＵ機能エンティティの両方は、簡潔に「ＩＡＢノードＤＵ」と呼ばれる。

本出願のこの実施形態では、ＩＡＢドナーは、完全な基地局機能を有するアクセスネットワーク要素であってよく、または集中型ユニット（ｃｅｎｔｒａｌｉｚｅｄ ｕｎｉｔ，ＣＵ）と分散型ユニット（ｄｉｓｔｒｉｂｕｔｅｄ ｕｎｉｔ，ＤＵ）とが分離された形態のアクセスネットワーク要素であってよい。詳細に関しては、図２を参照されたい。図２では、ＩＡＢドナーＣＵは、代替として、制御プレーン（ｃｏｎｔｒｏｌ ｐｌａｎｅ，ＣＰ）とユーザプレーン（ｕｓｅｒ ｐｌａｎｅ，ＵＰ）とが分離された形態であってよい。例えば、１つのＩＡＢドナーＣＵは、１つのＣＵ－ＣＰと複数のＣＵ－ＵＰとを含む。これは、本出願のこの実施形態において限定されない。

ＩＡＢドナー内のＣＵは、ＩＡＢドナー内のＣＵ機能エンティティと呼ばれることもあり、ＩＡＢドナー内のＤＵは、ＩＡＢドナー内のＤＵ機能エンティティと呼ばれることもある。説明を容易にするために、本出願のこの実施形態では、ＩＡＢドナー内のＣＵおよびＩＡＢドナー内のＣＵ機能エンティティは、簡潔にＩＡＢドナーＣＵと呼ばれ、ＩＡＢドナー内のＤＵおよびＩＡＢドナー内のＤＵ機能エンティティは、簡潔にＩＡＢドナーＤＵと呼ばれる。

加えて、図１は、デバイス間のインターフェースの名称をさらに示す。例えば、端末側デバイスとＩＡＢノード１との間にはＮＲ Ｕｕインターフェースが存在し、ＩＡＢノード２とＩＡＢドナーとの間にはＮＲ Ｕｎインターフェースが存在する。インターフェースの名称は、単なる例であり、インターフェースに対する限定を表すものではない。通信システムのバージョンが変わるとき、対応する名称は、別のワイヤレス通信ネットワークにおける対応する機能の名称と置き換えられてもよい。加えて、基地局が５Ｇにおける基地局であるとき、ＩＡＢドナーと基地局との間のインターフェースは、Ｘｎインターフェースであり得る。基地局がＬＴＥにおける基地局であるとき、ＩＡＢドナーと基地局との間のインターフェースは、Ｘ２インターフェースであり得る。

図１に示されるＩＡＢネットワークは、マルチホップネットワーキングをサポートする。例えば、図１に示されるＩＡＢノード１とＩＡＢドナーとの間に中間ＩＡＢノード（すなわち、ＩＡＢノード２）が存在する。別の可能なネットワーキングのシナリオでは、ＩＡＢノード１は、他の中間ＩＡＢノードなしにＩＡＢドナーに直接接続されてもよいか、または、ＩＡＢノード１とＩＡＢドナーとの間に２つ以上の中間ＩＡＢノードが存在してよい。

図１に示されるＩＡＢネットワークは、マルチホップネットワーキングとマルチ接続ネットワーキングの両方をサポートする。複数のリンクを含む少なくとも１つの送信経路が、ＩＡＢノードによってサービスされる端末側デバイスとＩＡＢドナーとの間に存在し得る。ＩＡＢノードとＩＡＢドナーとの間に１つまたは複数の送信経路が存在してもよく、各送信経路は、１つまたは複数のＩＡＢノードを含んでよい。送信経路上で、各ＩＡＢノードは、ＩＡＢノードにバックホールサービスを提供する隣接ノードを親ノードと見なし、それに応じて、各ＩＡＢノードは、ＩＡＢノードの親ノードの子ノードと見なされ得る。例えば、図１に示されるシナリオでは、ＩＡＢノード２の親ノードは、ＩＡＢドナーであり、ＩＡＢドナーは、ＩＡＢノード２を子ノードと見なす。

別の可能な非スタンドアロン（Ｎｏｎ－ｓｔａｎｄａｌｏｎｅ）マルチ接続ネットワーキングのシナリオでは、ＩＡＢノードによってサービスされる端末側デバイスは、ＩＡＢノードへの接続を確立してよく、ＬＴＥにおけるＵｕインターフェースを介して基地局（ＬＴＥネットワークにおける発展型ＮｏｄｅＢ ｅＮＢ）に直接接続されてもよい。同様に、ＩＡＢノードは、ＬＴＥにおけるＵｕインターフェースを介して基地局に接続されることがあり、１ホップまたはマルチホップのＮＲワイヤレスバックホールリンクを介してＩＡＢドナーに接続されることもある。ＩＡＢドナーと基地局とは、Ｘ２インターフェースを介して接続される。

本出願のこの実施形態では、いくつかの技術用語、例えば、ノードの前ホップノード、ノードのネクストホップノード、ノードの入口リンク（ｉｎｇｒｅｓｓ ｌｉｎｋ）、およびノードの出口リンク（ｅｇｒｅｓｓ ｌｉｎｋ）が使用され得る。以下では、最初に、これらの技術用語について説明する。

ノードの前ホップノード：ノードの前ホップノードは、ノードを含む経路上にあり、ノードの前にデータパケットを受信する、最後のノードである。

ノードのネクストホップノード：ノードのネクストホップノードは、ノードを含む経路上にあり、ノードの後にデータパケットを受信する、第１のノードである。

ノードの入口リンク：ノードの入口リンクは、ノードとノードの前ホップノードとの間のリンクであり、ノードの前ホップリンクと呼ばれることもある。

ノードの出口リンク：ノードの出口リンクは、ノードとノードのネクストホップノードとの間のリンクであり、ノードのネクストホップリンクと呼ばれることもある。

親ノードおよび子ノード：各ＩＡＢノードは、ＩＡＢノードにワイヤレスアクセスサービスおよび／またはワイヤレスバックホールサービスを提供するノードを親ノード（ｐａｒｅｎｔ ｎｏｄｅ）と見なす。それに応じて、各ＩＡＢノードは、ＩＡＢノードの親ノードの子ノード（ｃｈｉｌｄ ｎｏｄｅ）と見なされ得る。代替として、子ノードは、下位レベルノードと呼ばれることもあり、親ノードは、上位レベルノードと呼ばれることもある。

Ｆ１インターフェース：本出願のこの実施形態におけるＦ１インターフェースは、ＩＡＢノードＤＵとＩＡＢドナーまたはＩＡＢドナーＣＵとの間のインターフェースである。Ｆ１インターフェースは、Ｆ１^*インターフェースなどの名称で呼ばれることもある。説明を容易にするために、本出願のこの実施形態では、インターフェースは、まとめてＦ１インターフェースと呼ばれ得るが、名称は限定されない。

Ｆ１インターフェースは、デバイス内の機能エンティティ間のインターフェースであってもよいことに留意されたい。例えば、ＤＵおよびＣＵを含む基地局の場合、Ｆ１インターフェースは、基地局内のＤＵと基地局内のＣＵとの間のインターフェースであり得る。

本出願のこの実施形態では、Ｆ１インターフェースは、ユーザプレーンプロトコルおよび制御プレーンプロトコルをサポートする。例えば、Ｆ１インターフェースのユーザプレーンプロトコルレイヤは、汎用パケット無線サービス（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ，ＧＰＲＳ）トンネリングプロトコルユーザプレーン（ＧＰＲＳ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ Ｕｓｅｒ Ｐｌａｎｅ，ＧＴＰ－Ｕ）レイヤと、ユーザデータグラムプロトコル（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ，ＵＤＰ）レイヤと、インターネットプロトコル（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ，ＩＰ）レイヤとを含む。任意選択で、Ｆ１インターフェースのユーザプレーンプロトコルレイヤは、ＰＤＣＰレイヤおよび／またはＩＰセキュリティ（ＩＰ Ｓｅｃｕｒｉｔｙ，略してＩＰｓｅｃ）レイヤをさらに含む。

例えば、Ｆ１インターフェースの制御プレーンプロトコルレイヤは、Ｆ１アプリケーションプロトコル（Ｆ１ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌ，Ｆ１ＡＰ）レイヤと、ストリーム制御トランスポートプロトコル（ｓｔｒｅａｍ ｃｏｎｔｒｏｌ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ，ＳＣＴＰ）レイヤと、ＩＰレイヤとを含む。任意選択で、Ｆ１インターフェースの制御プレーンプロトコルレイヤは、ＰＤＣＰレイヤ、ＩＰｓｅｃレイヤ、およびデータグラムトランスポートレイヤセキュリティ（ｄａｔａｇｒａｍ ｔｒａｎｓｐｏｒｔ ｌａｙｅｒ ｓｅｃｕｒｉｔｙ，略してＤＴＬＳ）レイヤのうちの１つまたは複数をさらに含む。

加えて、本出願のこの実施形態では、様々なメッセージおよび情報、例えば、第１の設定情報、第２の設定情報、および第３の設定情報について説明するために用語の前に「第１の」、「第２の」、「第３の」などが追加され得るが、「第１の」、「第２の」、「第３の」などは、メッセージ、情報などを区別するために使用されるにすぎず、メッセージ、情報などが限定されることを意味しないことを理解されたい。

図１を参照すると、図３（ａ）および図３（ｂ）は各々、ＲＬＣチャネル、論理チャネル（ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ，ＬＣＨ）、およびプロトコルエンティティの間の対応付けの概略図である。図３（ａ）および図３（ｂ）に示されるように、無線リンク制御（ｒａｄｉｏ ｌｉｎｋ ｃｏｎｔｒｏｌ，ＲＬＣ）チャネル（ｃｈａｎｎｅｌ）は、ＲＬＣエンティティとＲＬＣエンティティの上位レイヤプロトコルエンティティとの間のチャネルである。例えば、ＲＬＣエンティティの上位レイヤがＰＤＣＰエンティティである場合、バックホールリンク上のＲＬＣチャネルは、ＲＬＣエンティティとＰＤＣＰエンティティとの間のチャネルである。別の例では、ＲＬＣエンティティの上位レイヤがバックホール適応プロトコル（Ｂａｃｋｈａｕｌ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ，ＢＡＰ）エンティティである場合、バックホールリンク上のＲＬＣチャネルは、ＲＬＣエンティティとＢＡＰエンティティとの間のチャネルである。したがって、ＲＬＣチャネルは、ＲＬＣエンティティの上位レイヤプロトコルエンティティによって具体的に決定される。

論理チャネルは、ＲＬＣエンティティとＲＬＣエンティティの下位レイヤプロトコルエンティティとの間のチャネルである。例えば、ＲＬＣエンティティの下位レイヤがＭＡＣレイヤである場合、論理チャネルは、ＲＬＣエンティティとＭＡＣエンティティとの間のチャネルである。

ＩＡＢノードのＲＬＣチャネルは、ＲＬＣエンティティに１つずつ対応し、ＲＬＣベアラにも１つずつ対応する。

ＢＡＰエンティティとＲＬＣエンティティとの関係に関しては、図３（ａ）に示されるように、１つのＢＡＰエンティティが、複数のＲＬＣエンティティに対応することがあるか、または、図３（ｂ）に示されるように、１つのＢＡＰエンティティが、１つのＲＬＣエンティティに対応することがある。これは、本出願において限定されない。

加えて、ＢＡＰレイヤは、以下の能力、すなわち、データパケットにワイヤレスバックホールノード（ＩＡＢノード）によって識別されることが可能であるルーティング情報（ｒｏｕｔｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）を追加することと、ワイヤレスバックホールノードによって識別されることが可能であるルーティング情報に基づいてルーティング選択を実行することと、ワイヤレスバックホールノードによって識別されることが可能でありサービス品質（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ，ＱｏＳ）要件に関連付けられた識別情報をデータパケットに追加することと、ワイヤレスバックホールノードを含む複数のリンク上のデータパケットに対してＱｏＳマッピングを実行することと、データパケットタイプ表示情報をデータパケットに追加することと、フロー制御能力を有するノードにフロー制御フィードバック情報を送信することのうちの１つまたは複数を有する。これらの能力を有するプロトコルレイヤの名称は、必ずしもＢＡＰレイヤであるとは限らないか、または、別の名称であってよいことに留意されたい。当業者は、これらの能力を有する任意のプロトコルレイヤが、本出願の実施形態におけるＢＡＰレイヤとして理解されることがあることを理解し得る。ＢＨリンク上のＲＬＣチャネルは、２つのノード間のＢＨリンク上のトラフィック差別化チャネルとして理解されることがあり、サービス差別化チャネルは、データパケット送信のための特定のサービス品質ＱｏＳ保証を提供することがある。ＢＨリンク上のＲＬＣチャネルは、物理チャネルではなく論理チャネルとして理解され得る。

本出願のこの実施形態では、ＢＨ ＲＬＣチャネル、すなわち、ＢＨリンク上のＲＬＣチャネルは、２つのノード間のＢＨリンク上のトラフィック差別化チャネルとして理解され得る。トラフィック差別化チャネルは、データパケット送信のための特定のサービス品質（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ，ＱｏＳ）保証を提供し得る。ＢＨリンク上のＲＬＣチャネルは、物理チャネルではなく論理チャネルとして理解され得る。

具体的には、ＢＨリンク上のＲＬＣチャネルは、ＢＨリンク上で接続された２つの隣接ノードのピアＲＬＣチャネルとして理解され得る。例えば、図１において、ＩＡＢドナーＤＵは、ＲＬＣチャネル１およびＲＬＣチャネル２を有し、ＩＡＢノード１は、ＲＬＣチャネル１およびＲＬＣチャネル２を有する。ＩＡＢドナーＤＵのＲＬＣチャネル１は、ＩＡＢノード１のＲＬＣチャネル１のピアであり、ＩＡＢドナーＤＵのＲＬＣチャネル２は、ＩＡＢノード１のＲＬＣチャネル２のピア（ｐｅｅｒ）である。ＩＡＢドナーＤＵとＩＡＢノード１との間のＢＨリンク上のＲＬＣチャネル１は、ＩＡＢドナーＤＵのＲＬＣチャネル１およびＩＡＢノード１のＲＬＣチャネル１であってよく、ＩＡＢドナーＤＵとＩＡＢノード１との間のＢＨリンク上のＲＬＣチャネル２は、ＩＡＢドナーＤＵのＲＬＣチャネル２およびＩＡＢノード１のＲＬＣチャネル２であってよい。

ＲＬＣチャネル、ＲＬＣベアラ、および論理チャネルは、１対１の対応付けであるので、本出願のこの実施形態では、３つの説明は、互いに代用し得る。例えば、本出願のこの実施形態では、ＲＬＣチャネルは、ＲＬＣベアラまたは論理チャネルと置き換えられてよい。同様に、ＢＨリンク上のＲＬＣチャネルは、ＢＨリンク上のＲＬＣベアラまたはＢＨリンク上の論理チャネルと置き換えられ得る。ＢＨリンク上のＲＬＣベアラは、ＢＨベアラまたはＢＨリンクベアラと呼ばれることもある。

ノードがデータパケットを受信するときに使用されるＲＬＣチャネルは、入口ＲＬＣチャネル（ｉｎｇｒｅｓｓ ＲＬＣ ｃｈａｎｎｅｌ）と呼ばれることもあり、データパケットが送信されるときに使用されるＲＬＣチャネルは、出口ＲＬＣチャネル（ｅｇｒｅｓｓ ＲＬＣ ｃｈａｎｎｅｌ）と呼ばれることに留意されたい。

前述の説明を参照すると、ＩＡＢネットワークでは、ＩＡＢノードとドナーノードとの間で送信されるデータペイロードは、Ｆ１トラフィックデータペイロードおよび非Ｆ１トラフィック（ｎｏｎ－Ｆ１ ｔｒａｆｆｉｃ）データペイロードを含み得る。Ｆ１トラフィックデータペイロードは、Ｆ１ユーザプレーン（Ｆ１－Ｕ）データペイロードまたはＦ１制御プレーン（Ｆ１－Ｃ）データペイロードを含む。非Ｆ１トラフィックデータペイロードは、Ｆ１ユーザプレーンデータペイロードおよびＦ１制御プレーンデータペイロード以外のデータペイロードを含み得る。これらのデータペイロードは、本出願の実施形態では、まとめて第１のタイプのデータペイロードと呼ばれる。

現在、非Ｆ１トラフィックデータペイロードは、複数の形態であり得る。例えば、非Ｆ１トラフィックデータペイロードは、ＢＡＰレイヤにおける制御（ｃｏｎｔｒｏｌ）プロトコルデータユニット（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ，ＰＤＵ）と、ＩＡＢノード（特定の実装ではＩＡＢノードＤＵであり得る）の運用、管理、および保守（Ｏｐｅｒａｔｉｏｎ，Ａｄｍｉｎｉｓｔｒａｔｉｏｎ，ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ，ＯＡＭ）トラフィックデータパケットと、ストリーム制御トランスポートプロトコル（ｓｔｒｅａｍ ｃｏｎｔｒｏｌ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ，ＳＣＴＰ）アソシエーション（ａｓｓｏｃｉａｔｉｏｎ）がＩＡＢノード（特定の実装ではＩＡＢノードＤＵであり得る）とＩＡＢドナーとの間で確立されるとき、またはＳＣＴＰアソシエーションが維持されるときに送信されるデータパケットと、インターネットプロトコルセキュリティ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ，ＩＰｓｅｃ）送信チャネルがＩＡＢノード（特定の実装ではＩＡＢノードＤＵであり得る）とＩＡＢドナーとの間で確立されるときに関与しているデータパケットとを含み得る。ワイヤレスバックホールリンク上の非Ｆ１トラフィックデータペイロードに対するベアラマッピングをどのように実行するかは、従来の技術には関与していない。本出願の実施形態は、ワイヤレスバックホールリンク上の非Ｆ１トラフィックデータペイロードに対するベアラマッピングを実行するための方法を提供する。説明が以下に提供される。

実施形態１
ＢＡＰレイヤにおける制御ＰＤＵが、ＩＡＢノードとＩＡＢドナーとの間で送信される。ＢＡＰレイヤにおける制御ＰＤＵは、非Ｆ１トラフィックデータパケットと見なされることがあり、制御ＰＤＵにおいて搬送されるデータペイロードは、Ｆ１ユーザプレーンデータペイロードおよびＦ１制御プレーンデータペイロード以外のデータペイロードである。

本出願のこの実施形態では、ＢＡＰレイヤにおける制御ＰＤＵは、２つの隣接ノード間で交換される。例えば、子ノードが、制御ＰＤＵを親ノードに送信するか、または、親ノードが、制御ＰＤＵを子ノードに送信する。子ノードは、ＩＡＢノードであってよく、親ノードは、別のＩＡＢノードであってよいか、または、親ノードは、ＩＡＢドナー（特定の実装ではＩＡＢドナーＤＵであり得る）であってよい。ＢＡＰレイヤにおける制御ＰＤＵは、ホップバイホップ制御情報を含み、例えば、フロー制御のために使用されるフィードバック情報を含むか、または、ワイヤレスバックホールリンクが異常であり親ノードによって子ノードに送信される通知を含み得る。ワイヤレスバックホールリンクの異常は、ワイヤレスバックホールリンクの無線リンク障害（ｒａｄｉｏ ｌｉｎｋ ｆａｉｌｕｒｅ，略してＲＬＦ）、遮断（ｂｌｏｃｋａｇｅ）、もしくは輻輳（ｃｏｎｇｅｓｔｉｏｎ）であることがあるか、またはワイヤレスバックホールリンクのものであり回復されることが可能でない接続などであることがある。ＢＡＰレイヤにおけるこの制御ＰＤＵは、ＩＰパケットにカプセル化される必要はない。

前述の説明を参照すると、図４は、本出願の実施形態によるデータパケット送信方法の概略フローチャートである。図４を参照されたい。本方法は、以下のステップを含む。

ステップ４０１：ＩＡＢドナーが、第１の設定情報を決定する。

第１の設定情報は、第１のＢＨ ＲＬＣチャネルを示すために使用され、第１のＢＨ ＲＬＣチャネルは、ＢＡＰレイヤにおいて制御ＰＤＵを送信するために使用される。

ステップ４０２：ＩＡＢドナーが、第１の設定情報をＩＡＢノードに送信する。

本出願のこの実施形態では、ＩＡＢドナーは、Ｆ１ＡＰメッセージまたはＲＲＣメッセージなどの制御プレーンメッセージを使用することによって第１の設定情報を送信してよい。代替として、ＩＡＢドナー（特定の実装ではＩＡＢドナーＤＵまたはＩＡＢドナーＣＵであり得る）は、ＩＡＢノードのＯＡＭから第１の設定情報を受信し、次いで、第１の設定情報をＩＡＢノードに送信し得る。

ＩＡＢノードが親ノードを有する場合、ＩＡＢドナーは、第１の設定情報をＩＡＢノードの親ノードに送信してもよいことに留意されたい。特定の処理が、第１の設定情報をＩＡＢノードに送信する処理と同じであってよい。詳細は、本明細書では再び説明されない。

例えば、ＩＡＢドナーがＣＵおよびＤＵを含む場合、ステップ４０１および４０２は、ＩＡＢドナーＣＵによって実行され得る。ＩＡＢドナーがＣＵおよびＤＵを含む場合、ＩＡＢドナーＣＵは、ＩＡＢドナーＤＵのための第１の設定情報をさらに設定し得る。

例えば、ＩＡＢドナーＣＵがＣＰおよびＵＰを含む場合、ステップ４０１および４０２は、ＩＡＢドナーＣＵ－ＣＰによって実行され得る。

ステップ４０３：ＩＡＢノードは、ＩＡＢドナーから第１の設定情報を受信する。

ステップ４０４：ＩＡＢノードは、第１の設定情報に基づいて、ＢＡＰレイヤにおいて制御ＰＤＵを送信するために使用される第１のＢＨ ＲＬＣチャネルを決定する。

ステップ４０５：ＩＡＢノードが、ＢＡＰレイヤにおいて制御ＰＤＵを、第１のＢＨ ＲＬＣチャネルを介してＩＡＢノードの隣接ノードに送信する。

ＩＡＢノードの隣接ノードは、例えば、ＩＡＢノードの親ノード（親ノードは別のＩＡＢノードまたはＩＡＢドナー（ＣＵとＤＵとが分離されたアーキテクチャ内にＩＡＢドナーがある特定の実装ではＩＡＢドナーＤＵであり得る）であり得る）、またはＩＡＢノードの子ノードであり得る。

ステップ４０１からステップ４０３ならびにステップ４０４およびステップ４０５は、２つの独立した手順であってよいことに留意されたい。ステップ４０１からステップ４０３は、ステップ４０４の前に実行されてよい。ステップ４０３を実行した後、ＩＡＢノードは、ＢＡＰレイヤにおいて制御ＰＤＵを送信することを決定するとき、実際の状況に基づいてステップ４０４およびステップ４０５を実行してよい。

前述の手順によれば、ＩＡＢドナーは、第１の設定情報を使用することによって、ＩＡＢノードがＢＡＰレイヤにおいて第１のＢＨ ＲＬＣチャネルを介して制御ＰＤＵを送信することを示し、ＩＡＢノードがＢＡＰレイヤにおいて制御ＰＤＵを送信する必要があるとき、ベアラマッピングを実施する。

本出願のこの実施形態では、第１の設定情報の複数の実装が存在し得る。可能な実装では、第１の設定情報が、第１のＢＨ ＲＬＣチャネルのチャネル識別子を含み得る。この場合、ＢＡＰレイヤにおいて制御ＰＤＵを送信するとき、ＩＡＢノードは、第１のＢＨ ＲＬＣチャネルのものであり第１の設定情報内にあるチャネル識別子に対応する第１のＢＨ ＲＬＣチャネルを介して、ＢＡＰレイヤにおいて制御ＰＤＵを送信してよい。

別の可能な実装では、第１の設定情報は、論理チャネル識別子（ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ ｉｄｅｎｔｉｆｉｅｒ，ＬＣＩＤ）を含んでよく、論理チャネル識別子によって示される論理チャネルは、第１のＢＨ ＲＬＣチャネルに対応する。この場合、ＢＡＰレイヤにおいて制御ＰＤＵを送信するとき、ＩＡＢノードは、第１の設定情報内の論理チャネル識別子を使用することによって第１のＢＨ ＲＬＣチャネルを決定し、第１のＢＨ ＲＬＣチャネルを介してＢＡＰレイヤにおいて制御ＰＤＵを送信する。

例えば、ＩＡＢドナー（特定の実装ではＩＡＢドナーＤＵであり得る）は、ＢＡＰレイヤにおける制御ＰＤＵをＩＡＢノードに送信してもよい。この場合、ＩＡＢドナーＤＵは、第１の設定情報によって示される第１のＢＨ ＲＬＣチャネルに基づいて、ＢＡＰレイヤにおいて制御ＰＤＵを送信してもよい。詳細に関しては、ＢＡＰレイヤにおいてＩＡＢノードによって制御ＰＤＵを送信する説明を参照されたい。詳細は、本明細書では再び説明されない。

本出願のこの実施形態では、別の可能な実装において、ＩＡＢドナーは、第１の設定情報を送信しないことがある。この場合、第１のＢＨ ＲＬＣチャネルは、事前に合意されることがあり、例えば、第１のＢＨ ＲＬＣチャネルのチャネル識別子または第１の論理チャネル識別子が、プロトコルにおいて指定される。第１のＢＨ ＲＬＣチャネルの指定されたチャネル識別子または指定された第１の論理チャネル識別子に対応する第１のＢＨ ＲＬＣチャネルは、ＢＡＰレイヤにおいて制御ＰＤＵを送信するために使用される。この場合、ＩＡＢノードは、事前に合意された第１のＢＨ ＲＬＣチャネルのチャネル識別子または第１の論理チャネル識別子に基づいて第１のＢＨ ＲＬＣチャネルを決定し、ＢＡＰレイヤにおいて第１のＢＨ ＲＬＣチャネルを介して制御ＰＤＵを送信することがある。それに応じて、ＩＡＢドナー（特定の実装ではＩＡＢドナーＤＵであり得る）は、事前に合意された第１のＢＨ ＲＬＣチャネルのチャネル識別子または第１の論理チャネル識別子に基づいて第１のＢＨ ＲＬＣチャネルを決定し、ＢＡＰレイヤにおいて第１のＢＨ ＲＬＣチャネルを介して制御ＰＤＵを送信してもよい。

さらに別の可能な実装では、ＩＡＢドナーは、第１の設定情報を送信しない。第１のノードがＢＡＰレイヤにおける制御ＰＤＵを第２のノードに送信するとき、第１のノードは、ＢＡＰレイヤにおける制御ＰＤＵにおいて搬送される情報に基づいて、ＢＡＰレイヤにおける制御ＰＤＵを送信するために使用されるＢＨ ＲＬＣチャネルを決定する。第１のノードおよび第２のノードは、１つのバックホールリンクを介して直接接続される。例えば、第１のノードは、ＩＡＢノードであり、第２のノードは、第１のノードの親ノードであり、第１のノードによって生成されるＢＡＰレイヤにおける制御ＰＤＵは、第１のＢＨ ＲＬＣチャネルに対応するバッファステータス情報を搬送し、第１のＢＨ ＲＬＣチャネルは、第１のノードと第２のノードとの間のリンクに対応するＢＨ ＲＬＣチャネルである。この場合、第１のノードは、第１のＢＨ ＲＬＣチャネルを介してＢＡＰレイヤにおける制御ＰＤＵを第２のノードに送信する。別の例では、第１のノードは、ＩＡＢノードであり、第２のノードは、第１のノードの親ノードであり、第１のノードによって生成されるＢＡＰレイヤにおける制御ＰＤＵは、第１のＢＨ ＲＬＣチャネルに対応するバッファステータス情報と、別のＢＨ ＲＬＣチャネルに対応するバッファステータス情報とを搬送する。しかしながら、第１のＢＨ ＲＬＣチャネルは、別のＢＨ ＲＬＣチャネルよりも高い優先度を有し、第１のＢＨ ＲＬＣチャネルおよび別のＢＨ ＲＬＣチャネルは各々、第１のノードと第２のノードとの間のリンクに対応するＢＨ ＲＬＣチャネルである。この場合、第１のノードは、第１のＢＨ ＲＬＣチャネルを介してＢＡＰレイヤにおける制御ＰＤＵを第２のノードに送信する。

以上は、ＢＡＰレイヤにおいて制御ＰＤＵをどのように送信するかについて説明している。以下では、別の非Ｆ１トラフィックデータペイロードをどのように送信するかについて説明する。

実施形態２
図５は、本出願の実施形態によるデータパケット送信方法の概略フローチャートである。図５を参照されたい。本方法は、以下のステップを含む。

ステップ５０１：ＩＡＢドナーが、第２の設定情報を決定する。

第２の設定情報は、第２のＢＨ ＲＬＣチャネルを示すために使用され、第２のＢＨ ＲＬＣチャネルは、第１のタイプのデータペイロードを送信するために使用され、第１のタイプのデータペイロードは、Ｆ１ユーザプレーンＦ１－ＵデータペイロードおよびＦ１制御プレーンＦ１－Ｃデータペイロード以外のデータペイロードである。

ステップ５０２：ＩＡＢドナーが、第２の設定情報をＩＡＢノードに送信する。

本出願のこの実施形態では、ＩＡＢドナーは、Ｆ１ＡＰメッセージまたはＲＲＣメッセージなどの制御プレーンメッセージを使用することによって第２の設定情報を送信してよい。代替として、ＩＡＢドナーは、ＩＡＢノードのＯＡＭから第２の設定情報を受信し、次いで、第２の設定情報をＩＡＢノードに送信し得る。

任意選択で、ＩＡＢノードが親ノードを有する場合、ＩＡＢドナーは、第２の設定情報をＩＡＢノードの親ノードに送信してもよい。特定の処理が、第２の設定情報をＩＡＢノードに送信する処理と同じであってよい。詳細は、本明細書では再び説明されない。

例えば、ＩＡＢドナーがＣＵおよびＤＵを含む場合、ステップ５０１および５０２は、ＩＡＢドナーＣＵによって実行され得る。ＩＡＢドナーがＣＵおよびＤＵを含む場合、ＩＡＢドナーＣＵは、ＩＡＢドナーＤＵのための第２の設定情報をさらに設定し得る。代替として、ＩＡＢドナーＤＵは、ＯＡＭを使用することによって第２の設定情報を取得し得る。

例えば、ＩＡＢドナーＣＵがＣＰおよびＵＰを含む場合、ステップ５０１および５０２は、ＩＡＢドナーＣＵ－ＣＰによって実行され得る。

ステップ５０３：ＩＡＢノードは、ＩＡＢドナーから第２の設定情報を受信する。

ステップ５０４：ＩＡＢノードが、第２の設定情報に基づいて第１のタイプのデータペイロードを送信する。

前述の手順によれば、ＩＡＢドナーは、第２の設定情報を使用することによって、ＩＡＢノードが、第２のＢＨ ＲＬＣチャネルを介して、Ｆ１ユーザプレーンＦ１－ＵデータペイロードおよびＦ１制御プレーンＦ１－Ｃデータペイロード以外のデータペイロードを送信することを示し、非Ｆ１トラフィックデータペイロードに対するベアラマッピングを実行する。

本出願のこの実施形態では、第２の設定情報は、第２のＢＨ ＲＬＣチャネルを識別するために使用される識別情報を含み、識別情報は、第２のＢＨ ＲＬＣチャネルのチャネル識別子であるか、または、第２のＢＨ ＲＬＣチャネルに対応する論理チャネル識別子であり得る。第２の設定情報は、以下の、
第１のタイプであって、データペイロードのタイプであり、第２のＢＨ ＲＬＣチャネルに対応する第１のタイプと、
第１の差別化されたサービス情報であって、第１のタイプおよび／または第２のＢＨ ＲＬＣチャネルに対応する第１の差別化されたサービス情報と、
第１のフローラベル（ｆｌｏｗ ｌａｂｅｌ）であって、第１のタイプおよび／または第２のＢＨ ＲＬＣチャネルに対応する第１のフローラベルとのうちのいずれか１つまたは複数をさらに含み得る。

差別化されたサービス情報は、差別化されたサービスコードポイント（ｄｉｆｆｅｒｅｎｔｉａｔｅｄ ｓｅｒｖｉｃｅｓ ｃｏｄｅ ｐｏｉｎｔ，ＤＳＣＰ）、インターネットプロトコルバージョン４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ４，ＩＰｖ４）パケットヘッダにおけるサービスタイプ（ｔｙｐｅ ｏｆ ｓｅｒｖｉｃｅ，ＴｏＳ）、インターネットプロトコルバージョン６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ６，ＩＰｖ６）パケットヘッダにおけるトラフィッククラス（ｔｒａｆｆｉｃ ｃｌａｓｓ）フィールド、ＩＰｖ６パケットヘッダにおけるトラフィッククラスフィールドの最初の６ビットなどであり得ることに留意されたい。フローラベルはまた、ＩＰｖ６パケットヘッダにおいて搬送されるフローラベルフィールドを指す。

この実装では、第１のタイプのデータペイロードは、以下の、
ＩＡＢノードのＯＡＭトラフィックパケットと、
ＩＰアドレスを要求するために使用されるパケット、例えば、ＤＨＣＰ発見（ｄｉｓｃｏｖｅｒ）パケットもしくはＤＨＣＰオファー（ｏｆｆｅｒ）パケットなどの動的ホスト設定プロトコル（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ，ＤＨＣＰ）パケット、ＤＨＣＰｖ６要請（Ｓｏｌｉｃｉｔ）パケットもしくはＤＨＣＰｖ６アドバタイズ（Ａｄｖｅｒｔｉｓｅ）パケットなどのＩＰｖ６用の動的ホスト設定プロトコル（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｆｏｒ ＩＰｖ６、ＤＨＣＰｖ６）パケット、ＩＰｖ６ベースのルータ要請（Ｒｏｕｔｅｒ Ｓｏｌｉｃｉｔａｔｉｏｎ）パケット、またはＩＰｖ６ベースのルータアドバタイズメント（Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ）パケットと、
ＩＰｓｅｃ送信チャネルを確立するために使用されるパケットと、
ＳＣＴＰアソシエーション保守パケットとのうちのいずれか１つまたは複数を含む。ＳＣＴＰアソシエーション保守パケットは、データ（ｄａｔａ）チャンク（ｃｈｕｎｋ）を含まないＳＣＴＰレイヤメッセージであり、データチャンクは、ＳＣＴＰレイヤの上位レイヤプロトコルレイヤにおけるデータパケットを指す。例えば、ＳＣＴＰアソシエーション保守パケットは、ＳＣＴＰアソシエーションセットアップデータパケット、ＳＣＴＰアソシエーションシャットダウンデータパケット、およびＳＣＴＰアソシエーションハートビートデータパケットなどのパケットを含むが、これらに限定されない。

この実装では、ダウンリンク方向において、ＩＡＢドナーがＩＡＢノードに第１のデータペイロードを送信するとき、第１のデータペイロードは、第１のタイプのデータペイロードである。この場合、ＩＡＢドナー（特定の実装では、ＩＡＢドナーＤＵ、ＩＡＢドナーＣＵ、ＩＡＢドナーＣＵ－ＣＰ、またはＩＡＢドナーＣＵ－ＵＰであり得る）は、第１のデータペイロードに対応するパケットヘッダ情報を使用して、第１の差別化されたサービス情報または第１のフローラベルを搬送することがある。パケットヘッダ情報は、ＩＰパケットヘッダであってよい。

ＩＡＢドナー（特定の実装ではＩＡＢドナーＤＵであり得る）は、第１の差別化されたサービス情報に対応する第２のＢＨ ＲＬＣチャネルを介してＩＡＢノードに第１のデータパケットを送信するか、第１のフローラベルに対応する第２のＢＨ ＲＬＣチャネルを介してＩＡＢノードに第１のデータパケットを送信するか、または第１のタイプに対応する第２のＢＨ ＲＬＣチャネルを介してＩＡＢノードに第１のデータパケットを送信することがあり、第１のデータパケットは、第１のデータペイロードを含む。

例えば、前述の説明を参照すると、図６に示されるように、第１のデータパケットは、第１のデータペイロードおよびパケットヘッダ情報を含み、第１のデータパケットは、他の情報をさらに含み得る。詳細は、本明細書では説明されない。上述されるように、第１のデータペイロードは、ＯＡＭトラフィックパケット、ＩＰアドレスを要求するために使用されるパケットなどであってよい。パケットヘッダ情報は、ＩＰパケットヘッダであってよい。第１のデータペイロードを取得した後、ＩＡＢドナーは、対応するパケットヘッダ情報を第１のデータペイロードに追加し、第１のデータパケットを取得する。

この実装では、アップリンク方向において、ＩＡＢノードが第１のデータペイロードを送信するとき、第１のデータペイロードは、第１のタイプのデータペイロードである。この場合、ＩＡＢノードは、第１のデータペイロードに対応するパケットヘッダ情報を使用して、第１の差別化されたサービス情報または第１のフローラベルを搬送することがある。ＩＡＢノードは、第１の差別化されたサービス情報に対応する第２のＢＨ ＲＬＣチャネルを介してＩＡＢノードのネクストホップノードに第１のデータパケットを送信するか、または第１のフローラベルに対応する第２のＢＨ ＲＬＣチャネルを介してＩＡＢノードのネクストホップノードに第１のデータパケットを送信することがあり、第１のデータパケットは、第１のデータペイロードと、第１のデータペイロードに対応するパケットヘッダ情報とを含む。代替として、アップリンク方向において、ＩＡＢノードが第１のデータペイロードを送信するとき、第１のデータペイロードは、第１のタイプのデータペイロードである。この場合、ＩＡＢノードは、第１のタイプに対応する第２のＢＨ ＲＬＣチャネルを介してＩＡＢノードのネクストホップノードに第１のデータパケットを送信してよく、第１のデータパケットは、第１のデータペイロードを含む。ＩＡＢノードのネクストホップノードは、ＩＡＢノードの親ノードであり、具体的には、ＩＡＢドナー（例えば、ＩＡＢドナーＤＵ）または別のＩＡＢノードであってよい。

本出願のこの実施形態では、別の可能な実装において、ＩＡＢドナーは、第２の設定情報を送信しないことがある。この場合、可能な実装では、第２のＢＨ ＲＬＣチャネルは、事前に合意されることがあり、例えば、第２のＢＨ ＲＬＣチャネルのチャネル識別子または第２の論理チャネル識別子が、プロトコルにおいて指定される。第２のＢＨ ＲＬＣチャネルの指定されたチャネル識別子または指定された第２の論理チャネル識別子に対応する第２のＢＨ ＲＬＣチャネルは、第１のタイプのデータペイロードを送信するために使用される。この場合、ＩＡＢノードは、事前に合意された第２のＢＨ ＲＬＣチャネルのチャネル識別子または第２の論理チャネル識別子に基づいて第２のＢＨ ＲＬＣチャネルを決定し、データペイロードタイプが第１のタイプであるデータパケットを第２のＢＨ ＲＬＣチャネルを介して送信することがある。それに応じて、ＩＡＢドナー（例えば、特定の実装ではＩＡＢドナーＤＵであり得る）は、事前に合意された第２のＢＨ ＲＬＣチャネルのチャネル識別子または第２の論理チャネル識別子に基づいて第２のＢＨ ＲＬＣチャネルを決定し、データペイロードタイプが第１のタイプであるデータパケットを第２のＢＨ ＲＬＣチャネルを介して送信してもよい。例えば、デフォルト（ｄｅｆａｕｌｔ）の第２のＢＨ ＲＬＣチャネルのチャネル識別子は、プロトコルにおいて指定され、チャネル識別子によって指定されたＢＨ ＲＬＣチャネルは、デフォルトのＢＨ ＲＬＣチャネルであり、第１のタイプのデータペイロードを送信するために使用され得る。

別の可能な実装では、第２のＢＨ ＲＬＣチャネルのチャネル識別子または第２の論理チャネル識別子に加えて、以下の、第１のタイプと、第１の差別化されたサービス情報と、第１のタイプと第１の差別化されたサービス情報との間の対応付けと、第１の差別化されたサービス情報と第２のＢＨ ＲＬＣチャネルとの間の対応付けと、第１のフローラベルと、第１のタイプと第１のフローラベルとの間の対応付けと、第１のフローラベルと第２のＢＨ ＲＬＣチャネルとの間の対応付けとのうちの１つまたは複数が、プリセットされ得る（例えば、プロトコルにおいて指定される）。

この実装では、アップリンク送信の場合、ＩＡＢノードが第１のタイプのデータペイロードを送信することを決定するとき、ＩＡＢノードは、第１のタイプのデータペイロードに対応するパケットヘッダ情報を使用して、プリセットされた第１の差別化されたサービス情報またはプリセットされた第１のフローラベルを搬送し、プリセットされた第１の差別化されたサービス情報またはプリセットされた第１のフローラベルに対応する第２のＢＨ ＲＬＣチャネルを介して第１のタイプのデータペイロードを送信する。代替として、第１のタイプのデータペイロードを送信することを決定するとき、ＩＡＢノードは、第１のタイプに対応する第２のＢＨ ＲＬＣチャネルを介して第１のタイプのデータペイロードを送信する。ダウンリンク送信の場合、ＩＡＢドナーが第１のタイプのデータペイロードを送信することを決定するとき、ＩＡＢドナー（特定の実装では、ＩＡＢドナーＣＵ、ＩＡＢドナーＣＵ－ＵＰ、またはＩＡＢドナーＣＵ－ＣＰであり得る）は、第１のタイプのデータペイロードに対応するパケットヘッダ情報を使用して、プリセットされた第１の差別化されたサービス情報またはプリセットされた第１のフローラベルを搬送し、ＩＡＢドナー（特定の実装ではＩＡＢドナーＤＵであり得る）は、プリセットされた第１の差別化されたサービス情報またはプリセットされた第１のフローラベルに対応する第２のＢＨ ＲＬＣチャネルを介して第１のタイプのデータペイロードを送信する。代替として、第１のタイプのデータペイロードを送信することを決定するとき、ＩＡＢドナーは、第１のタイプに対応する第２のＢＨ ＲＬＣチャネルを介して第１のタイプのデータペイロードを送信する。

別の可能な実装では、ＩＰ５タプル情報と、ＩＰ５タプル情報と第１の差別化されたサービス情報との間の対応付けと、第１の差別化されたサービス情報と第２のＢＨ ＲＬＣチャネルとの間の対応付けとが、プリセットされてよいか、または、ＩＰ５タプル情報と、ＩＰ５タプル情報と第１のフローラベルとの間の対応付けと、第１のフローラベルと第２のＢＨ ＲＬＣチャネルとの間の対応付けとが、プリセットされてよい。ＩＰ５タプル情報は、以下の、発信元ＩＰアドレスと、宛先ＩＰアドレスと、発信元ポート番号と、宛先ポート番号と、トランスポートレイヤプロトコルタイプとのうちの少なくとも１つを含む。

この実装では、アップリンク送信の場合、送信されたデータペイロードに対応するＩＰ５タプル情報がプリセットされたＩＰ５タプル情報であると決定するとき、ＩＡＢノードは、データペイロードに対応するパケットヘッダ情報を使用して、プリセットされた第１の差別化されたサービス情報またはプリセットされた第１のフローラベルを搬送し、プリセットされた第１の差別化されたサービス情報またはプリセットされた第１のフローラベルに対応する第２のＢＨ ＲＬＣチャネルを介してデータペイロードを送信する。ダウンリンク送信の場合、ＩＡＢドナーはまた、同じ方法でデータペイロードを送信する。詳細は、本明細書では再び説明されない。

以上は、ＢＡＰレイヤにおける制御ＰＤＵおよびＳＣＴＰアソシエーションを確立するために使用されるパケットなどの非Ｆ１トラフィックデータペイロードをどのように送信するかについて説明している。以下では、Ｆ１トラフィックデータペイロードをどのように送信するかについてさらに説明する。実施形態３から実施形態６におけるデータペイロードは各々、別段に指定されなければ、Ｆ１ユーザプレーン（Ｆ１－Ｕ）データペイロードまたはＦ１制御プレーン（Ｆ１－Ｃ）データペイロードであることに留意されたい。

図１に示されるＩＡＢネットワークでは、ＩＡＢノード１は、端末側デバイスにアクセスサービスを提供するＩＡＢノードであり、ＩＡＢノード２は、中間ＩＡＢノードである。ＩＡＢノードは、中間ＩＡＢノードとアクセスＩＡＢノード（ａｃｃｅｓｓ ＩＡＢ ｎｏｄｅ）の両方として使用され得ることに留意されたい。例えば、ＩＡＢノード２は、ＩＡＢノード１とＩＡＢドナーとの間の中間ノードとして使用されてよいが、ＩＡＢノード１によってサービスされるセルにアクセスする端末側デバイスの場合、ＩＡＢノード２は、アクセスＩＡＢノードとして使用される。

ＩＡＢノード２とＩＡＢノード１との間のワイヤレスバックホールリンク、およびＩＡＢノード２とＩＡＢドナー（特定の実装ではＩＡＢドナーＤＵであり得る）との間のワイヤレスバックホールリンク上で、１つまたは複数のバックホールリンク（ｂａｃｋｈａｕｌ ｌｉｎｋ，ＢＨ）ＲＬＣチャネルが、ＩＡＢドナーの設定に基づいて確立される。バックホールリンクを介してデータパケットを送信するとき、ＩＡＢノードまたはＩＡＢドナー（特定の実装ではＩＡＢドナーＤＵであり得る）は、ベアラマッピングを実行する必要がある。例えば、ベアラマッピングは、ダウンリンク上で送信されるデータパケットに対してＩＡＢドナーによって最初に実行される必要がある（特定の実装ではＩＡＢドナーＤＵによって実行され得る）。具体的には、適切なＢＨ ＲＬＣチャネルが、データパケットを送信するために、ＩＡＢノード２とＩＡＢドナーとの間のリンク上のＢＨ ＲＬＣチャネルから選択される。ＩＡＢノード１に送信される必要があるデータパケットをＩＡＢドナーから受信するとき、ＩＡＢノード２はまた、データパケットを送信するために、ＩＡＢノード１とＩＡＢノード２との間のリンク上のＢＨ ＲＬＣチャネルから適切なＢＨ ＲＬＣチャネルを選択する必要がある。

同様に、アップリンク上で送信されるデータパケットの場合、例えば、ベアラマッピングも、ＩＡＢノード１によって送信されたアップリンクデータパケットに対してＩＡＢノード１によって実行される必要がある。具体的には、データパケットをＩＡＢノード２に送信するために、ＢＨ ＲＬＣチャネルが、ＩＡＢノード１とＩＡＢノード２との間のリンク上のＢＨ ＲＬＣチャネルから選択される。

従来の技術では、中間ＩＡＢノードとして使用されるＩＡＢノード２がベアラマッピングを実行するとき、ＩＡＢノード２は、データパケットを受信するために使用される入口ＢＨ ＲＬＣチャネルに依拠する。具体的には、データパケットの入口ＢＨ ＲＬＣチャネルに対応する出口ＢＨ ＲＬＣチャネルは、データパケットを送信するために使用される出口ＢＨ ＲＬＣチャネルとして使用され得る。しかしながら、この実装は、十分にフレキシブルでない。同じ入口ＢＨ ＲＬＣチャネルから受信されたデータパケットがネクストホップノードに送信されるとき、データパケットは、送信のために同じ出口ＢＨ ＲＬＣチャネルにマッピングされることしかできない。その結果、フレキシビリティが乏しく、差別化されたサービス品質（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ，ＱｏＳ）保証が、異なるトラフィックのデータパケットに対して提供されることが可能でなく、データパケットのＱｏＳ要件が満たされることが可能でない。

本出願のこの実施形態では、ワイヤレスバックホールリンク上で送信されるデータパケットは、中間ＩＡＢノードによって使用される追加情報を搬送し、ベアラマッピングを実行することが許可されてよく、その結果、中間ＩＡＢノードは、ベアラマッピングをよりフレキシブルに実行することができる。追加情報はラベル（ｌａｂｅｌ）であってよく、ラベルは、データパケットのバックホール適応プロトコルＢＡＰレイヤヘッダ情報において搬送されてよい。ラベルは、別の名称をさらに有してよいことに留意されたい。本出願のこの実施形態では、ラベルは、説明のための例として使用されるにすぎない。通信規格が変わるとき、対応する名称は、変えられた通信規格における対応する機能の名称と置き換えられてもよい。

以下では、ＩＡＢドナー、中間ＩＡＢノード、およびアクセスＩＡＢノードの観点からそれぞれ、ワイヤレスバックホールリンク上でベアラマッピングを実行するためにラベルをどのように追加および使用するかについて説明する。

実施形態３
図７は、本出願の実施形態によるデータパケット送信方法の概略フローチャートである。本方法は、以下のステップを含む。

ステップ７００：ＩＡＢドナーが、第３の設定情報を取得する。

第３の設定情報は、第１のラベルと、ＩＡＢドナーによって取得された第３のデータペイロードに対応するパケットヘッダ情報内の第１の情報との間の対応付けを設定するために使用される。第１の情報は、次の、第１の差別化されたサービス情報と、第１のフローラベルと、第１のＩＰアドレスとのうちのいずれか１つまたは複数を含み得る。

例えば、本出願のこの実施形態では、第３の設定情報は、以下の、
（１）第１の差別化されたサービス情報および第１の差別化されたサービス情報に対応する第１のラベルであって、
本出願のこの実施形態では、差別化されたサービス情報は、ＤＳＣＰであってよいか、または、第３のデータペイロードに対応するパケットヘッダ情報がＩＰｖ４パケットヘッダであるとき、差別化されたサービス情報は、ＩＰｖ４パケットヘッダ内のサービスタイプ（ｔｙｐｅ ｏｆ ｓｅｒｖｉｃｅ，ＴｏＳ）であってよいか、または、第３のデータペイロードに対応するパケットヘッダ情報がＩＰｖ６パケットヘッダであるとき、差別化されたサービス情報は、ＩＰｖ６パケットヘッダ内のクラスタイプフィールド、ＩＰｖ６パケットヘッダ内のクラスタイプフィールドの最初の６ビットなどであってよい、第１の差別化されたサービス情報および第１の差別化されたサービス情報に対応する第１のラベルと、
（２）第１のフローラベル（ｆｌｏｗ ｌａｂｅｌ）および第１のフローラベルに対応する第１のラベルであって、
第３のデータペイロードに対応するパケットヘッダ情報がＩＰｖ６パケットヘッダであるとき、フローラベルはまた、ＩＰｖ６パケットヘッダにおいて搬送される情報である、第１のフローラベルおよび第１のフローラベルに対応する第１のラベルと、
（３）第１の差別化されたサービス情報、第１のフローラベル、および対応する第１のラベルと、
（４）第１のＩＰアドレスおよび第１のＩＰアドレスに対応する第１のラベルと、
（５）第１のフローラベル、第１のＩＰアドレス、および対応する第１のラベルと、
（６）第１の差別化されたサービス情報、第１のＩＰアドレス、および対応する第１のラベルと、
（７）第１の差別化されたサービス情報、第１のフローラベル、第１のＩＰアドレス、および対応する第１のラベルとのうちのいずれか１つを含み得る。

第３の設定情報内の第１のＩＰアドレスは、データパケット内の宛先ＩＰアドレスであり得ることに留意されたい。第３の設定情報内の（４）に関しては、第１のＩＰアドレスは、代替として、データパケットにおける発信元ＩＰアドレスであってよい。

第３の設定情報に基づいて、第３のデータペイロードを取得した後、ＩＡＢドナーは、第３のデータペイロードに対応するパケットヘッダ情報内の差別化されたサービス情報、フローラベル、およびＩＰアドレスのうちの１つまたは複数に基づいて第１のラベルを決定し、次いで、第１のラベルおよび第３のデータペイロードをネクストホップノードに送信することがある。詳細に関しては、ステップ７０１およびステップ７０２の説明を参照されたい。

任意選択で、本出願のこの実施形態は、以下のステップをさらに含む。

ステップ７０１：ＩＡＢドナーは、第３のデータペイロードに対応するパケットヘッダ情報に基づいて第１のラベルを決定する。

具体的には、ＩＡＢドナーは、第３のデータペイロードに対応するパケットヘッダ情報および第３の設定情報に基づいて第１のラベルを決定する。

第１のラベルは、第３のデータペイロードの出口ＲＬＣチャネルを決定するために使用される。

ＩＡＢドナーは、第３のデータペイロードを含むダウンリンクデータパケットを受信することがあり、ダウンリンクデータパケットの構造は、図８に示され得ることに留意されたい。図８に示されるダウンリンクデータパケットは、第３のデータペイロードおよびパケットヘッダ情報を含み、パケットヘッダ情報は、ＩＰパケットヘッダであってよい。

ステップ７０２：ＩＡＢドナーは、第３のデータパケットをＩＡＢノードに送信する。

第３のデータパケットは、第３のデータペイロードおよび第１のＢＡＰレイヤヘッダを含み、第１のＢＡＰレイヤヘッダは、第１のラベルを含む。

ＩＡＢノードが第３のデータパケットを受信した後、第１のラベルに基づいて第３のデータペイロードの出口ＲＬＣチャネルをどのように決定するかについての詳細に関しては、以下の説明が参照され得ることに留意されたい。

図８を参照すると、図８に示されるダウンリンクデータパケットを受信した後、ＩＡＢドナーは、第１のＢＡＰレイヤヘッダをダウンリンクデータパケットに追加して、第３のデータパケットを取得してよい。第３のデータパケットの構造は、図９に示され得る。第３のデータパケットは、第１のＢＡＰレイヤヘッダ、第３のデータペイロードなどを含む。

例えば、ＩＡＢドナーがＣＵおよびＤＵを含む場合、ステップ７００からステップ７０２におけるＩＡＢドナーは、具体的には、ＩＡＢドナーＤＵであってよく、すなわち、ＩＡＢドナーＤＵは、第１のラベルを第３のデータパケット内の第１のＢＡＰレイヤヘッダに追加してよい。それに応じて、ＩＡＢドナーＣＵ（特定の実装ではＩＡＢドナーＣＵ－ＣＰであり得る）は、第３の設定情報をＩＡＢドナーＤＵに送信する。

例えば、第３の設定情報は、ＩＡＢドナーＣＵによってＩＡＢドナーＤＵに送信されるＦ１ＡＰメッセージに含まれてよい。

例えば、ＩＡＢドナーが、ＣＵとＤＵとが分離されている形態でない場合、ＩＡＢドナーは、第３の設定情報を取得する必要はなく、ＩＡＢドナーは、第３の設定情報を生成してよいか、または、ＯＡＭから第３の設定情報を取得してよい。

実施形態４
図１０は、本出願の実施形態によるデータパケット送信方法の概略フローチャートである。本方法は、以下のステップを含む。

ステップ１０００：第２のＩＡＢノードが、ＩＡＢドナーから第４の設定情報を受信する。

第２のＩＡＢノードは、アクセスＩＡＢノードであり得る。

例えば、ＩＡＢドナーがＣＵおよびＤＵを含む場合、ＩＡＢドナーＣＵは、第２のＩＡＢノードに関する第４の設定情報を設定し得る。

例えば、ＩＡＢドナーＣＵがＣＰおよびＵＰを含む場合、ＩＡＢドナーＣＵ－ＣＰは、第２のＩＡＢノードに関する第４の設定情報を設定し得る。

可能な実装では、第４の設定情報は、第２のラベルと第２のＩＡＢノードによって取得された第４のデータペイロードに対応するパケットヘッダ情報内の第２の情報との間の対応付けを設定するために使用され、第２のラベルは、第４のデータペイロードの出口ＲＬＣチャネルを決定するために使用される。第２の情報は、以下の、
パケットヘッダ情報内の第２の差別化されたサービス情報と、パケットヘッダ情報内の第２のフローラベルと、パケットヘッダ情報内の第２のＩＰアドレスと、パケットヘッダ情報内にあり、第４のデータペイロードに対応するデータ無線ベアラ情報とのうちのいずれか１つまたは複数を含み得る。

例えば、第４の設定情報は、以下の、
（１）第２のフローラベルおよび第２のフローラベルに対応する第２のラベルと、
（２）第２のフローラベル、第２のＩＰアドレス、ならびに第２のフローラベルおよび第２のＩＰアドレスに対応する第２のラベルと、
（３）第２のＩＰアドレスおよび第２のＩＰアドレスに対応する第２のラベルと、
（４）第２の差別化されたサービス情報および第２の差別化されたサービス情報に対応する第２のラベルと、
（５）第２の差別化されたサービス情報、第２のＩＰアドレス、ならびに第２の差別化されたサービス情報および第２のＩＰアドレスに対応する第２のラベルと、
（６）第２の差別化されたサービス情報、第２のフローラベル、ならびに第２の差別化されたサービス情報および第２のフローラベルに対応する第２のラベルと、
（７）第２の差別化されたサービス情報、第２のフローラベル、第２のＩＰアドレス、および対応する第２のラベルとのうちのいずれか１つまたは複数を含み得る。

第４の設定情報内の第２のＩＰアドレスは、宛先ＩＰアドレスであり得ることに留意されたい。第４の設定情報における差別化されたサービス情報およびフローラベルに関しては、第３の設定情報の説明を参照されたい。詳細は、本明細書では再び説明されない。

別の可能な実装では、第４の設定情報は、第４のデータペイロードと第２のラベルとの間の対応付けを設定するために使用される。例えば、第４の設定情報は、以下のもののうちのいずれか１つまたは複数を含み得る。

（８）第４のデータペイロードに対応するデータ無線ベアラ情報、およびデータ無線ベアラ情報に対応する第２のラベル。

この場合、第４のデータペイロードは、ユーザプレーンデータパケットである。

データ無線ベアラ情報は、以下のコンテンツ、すなわち、ユーザプレーンデータパケットで搬送される汎用パケット無線サービス（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ，ＧＰＲＳ）トンネリングプロトコルユーザプレーン（ＧＰＲＳ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ Ｕｓｅｒ Ｐｌａｎｅ，ＧＴＰ－Ｕ）トンネルエンドポイント識別子（Ｔｕｎｎｅｌ ｅｎｄｐｏｉｎｔ ｉｄｅｎｔｉｆｉｅｒ，ＴＥＩＤ）と、ユーザプレーンデータパケットにおいて搬送されるＧＴＰ ＴＥＩＤおよびＩＰアドレスと、ユーザプレーンデータパケットのＵＥ ＤＲＢ識別子（ＵＥの識別子およびＤＲＢ ＩＤに基づいて共同で決定され得る）と、ユーザプレーンデータパケットの論理チャネル識別子とのうちのいずれか１つであり得る。ＧＴＰ ＴＥＩＤは、ＧＴＰユーザプレーンプロトコルレイヤのヘッダ情報において搬送されるトンネルエンドポイント識別子であり、トンネルエンドポイント識別子は、ＩＡＢドナーまたはＩＡＢドナーＣＵによって割り振られたアップリンクトンネルエンドポイント識別子であってよく、１つのＵＥデータ無線ベアラ（ｄａｔａ ｒａｄｉｏ ｂｅａｒｅｒ，ＤＲＢ）に対応する。

（９）第４のデータペイロードの第２のタイプ、および第２のタイプに対応する第２のラベル。

この場合、第４のデータペイロードは、Ｆ１制御プレーンパケット、すなわち、Ｆ１ＡＰメッセージである。第２のタイプは、Ｆ１ＡＰメッセージタイプのうちのいずれか１つまたは複数である。

可能な実装では、以下の２つのＦ１ＡＰメッセージタイプ、すなわち、ＵＥ関連（ＵＥ ａｓｓｏｃｉａｔｅｄ）Ｆ１ＡＰメッセージと、非ＵＥ関連（ｎｏｎ－ＵＥ ａｓｓｏｃｉａｔｅｄ）Ｆ１ＡＰメッセージとが存在し得る。代替として、別の可能な実装では、以下の複数の特定のＦ１ＡＰメッセージタイプ、すなわち、Ｆ１セットアップ要求（ｓｅｔｕｐ ｒｅｑｕｅｓｔ）、ｇＮＢ－ＤＵ設定更新（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｕｐｄａｔｅ）、ＵＥコンテキストセットアップ応答（ＵＥ ｃｏｎｔｅｘｔ ｓｅｔｕｐ ｒｅｓｐｏｎｓｅ）などが存在し得る。具体的には、ＴＳ３８．８７４のセクション９．２／８．１に記載されている複数のＦ１ＡＰメッセージにおいてＩＡＢドナーＤＵによってＩＡＢドナーＣＵに送信されるメッセージタイプが含まれ得る。代替として、別の可能な実装では、以下のＦ１ＡＰメッセージタイプ、すなわち、Ｆ１ＡＰメッセージに含まれるコンテンツ（例えば、ＵＥのＲＲＣメッセージ）に対応するＵＥシグナリング無線ベアラ（ｓｉｇｎａｌｉｎｇ ｒａｄｉｏ ｂｅａｒｅｒ，ＳＲＢ）タイプが存在し得る。

前述の説明は、例にすぎない。Ｆ１ＡＰメッセージタイプの別の場合が存在し得る。詳細は、本明細書では再び説明されない。

（１０）第４のデータペイロードがＦ１ＡＰメッセージであるとき、Ｆ１ＡＰメッセージを搬送するＳＣＴＰレイヤにおけるストリーム識別子（ｓｔｒｅａｍ ＩＤ）、およびストリーム識別子に対応する第２のラベル。

第４の設定情報に基づいて、第２のＩＡＢノードが第４のデータペイロードを含むアップリンクデータパケットを取得した後、第２のＩＡＢノードは、アップリンクデータパケット内の第２の情報、第４のデータペイロードに対応するデータ無線ベアラ情報、第４のデータペイロードに対応するＦ１ＡＰメッセージタイプ、または第４のデータペイロードを搬送するＳＣＴＰレイヤにおけるストリーム識別子に基づいて第２のラベルを決定し、次いで、第２のラベルが追加されたアップリンクデータパケットをネクストホップノードに送信する。詳細に関しては、ステップ１００１からステップ１００３の説明を参照されたい。

任意選択で、本出願のこの実施形態は、以下のステップをさらに含む。

ステップ１００１：第２のＩＡＢノードは、第４のデータペイロードを取得する。具体的には、第２のＩＡＢノードは、第４のデータペイロードを生成するか、または、第２のＩＡＢノードによってサービスされる端末デバイスもしくは子ノードから第４のデータペイロードを受信してよい。

ステップ１００２：第２のＩＡＢノードは、第２のラベルを決定する。

具体的には、第２のＩＡＢノードは、第４のデータペイロードに対応するパケットヘッダ情報、第４のデータペイロードに対応するデータ無線ベアラ情報、第４のデータペイロードに対応するＦ１ＡＰメッセージタイプ、または第４のデータペイロードを搬送するＳＣＴＰレイヤにおけるストリーム識別子に基づいて第２のラベルを決定し得る。

ステップ１００３：第２のＩＡＢノードは、第４のデータパケットを親ノードに送信する。

第４のデータパケットは、第４のデータペイロードおよび第２のＢＡＰレイヤヘッダを含み、第２のＢＡＰレイヤヘッダは、第２のラベルを含む。

実施形態５
図１１は、本出願の実施形態によるデータパケット送信方法の概略フローチャートである。本方法は、以下のステップを含む。

ステップ１１００：第１のＩＡＢノードが、ＩＡＢドナーから第５の設定情報を受信する。

第５の設定情報は、第３のラベルと第３のＲＬＣチャネル識別子との間の対応付けを設定するために使用される。第３のラベルは、データパケットのＢＡＰレイヤヘッダにおいて搬送され、データパケットの出口ＲＬＣチャネルを決定するために第１のＩＡＢノードによって使用される。第３のＲＬＣチャネル識別子は、第１のＩＡＢノードがデータパケットを送信する出口ＢＨ ＲＬＣチャネル（すなわち、第３のＢＨ ＲＬＣチャネル）を識別するために使用され、第３のＢＨ ＲＬＣチャネルの識別子または第３のＢＨ ＲＬＣチャネルに対応する論理チャネル識別子であり得る。

例えば、第５の設定情報は、以下のもののうちのいずれか１つまたは複数を含み得る。

（１）第３のラベルおよび対応する第３のＲＬＣチャネル識別子。

（２）第３のラベル、出口リンク識別子、および対応する第３のＲＬＣチャネル識別子。ここで、出口リンク識別子は、第１のＩＡＢノードがデータパケットを送信する出口リンクを示すために使用される。具体的には、アップリンク送信の場合、出口リンク識別子は、第１のＩＡＢノードの親ノードの識別子（例えば、第１のＩＡＢノードに関する、親ノードのＢＡＰレイヤ識別子、親ノードのＤＵ識別子、親ノードのＩＰアドレス、親ノードのセル識別子、または親ノードのセルグループ識別子）であり得る。ダウンリンク送信の場合、出口リンク識別子は、第１のＩＡＢノードの子ノードの識別子（例えば、第１のＩＡＢノードによって子ノードに割り振られたＦ１制御プレーン識別子ＤＵ Ｆ１ＡＰ ＵＥ ＩＤ、子ノードによってアクセスされた第１のＩＡＢノードのセル識別子＋第１のＩＡＢノードによって子ノードに割り振られたセル無線ネットワーク一時識別子Ｃ－ＲＮＴＩ、子ノードのＩＰアドレス、または子ノードのＢＡＰレイヤ識別子）であり得る。

（３）第３のラベル、第４のＲＬＣチャネル識別子、および対応する第３のＲＬＣチャネル識別子。ここで、第４のＲＬＣチャネル識別子は、第１のＩＡＢノードがデータパケットを受信する入口ＢＨ ＲＬＣチャネル（すなわち、第４のＢＨ ＲＬＣチャネル）を識別するために使用され、第４のＢＨ ＲＬＣチャネルの識別子または第４のＢＨ ＲＬＣチャネルに対応する論理チャネル識別子であり得る。

（４）第３のラベル、入口リンク識別子、第４のＲＬＣチャネル識別子、出口リンク識別子、および対応する第３のＲＬＣチャネル識別子。ここで、第４のＲＬＣチャネル識別子に関しては、（３）の説明を参照し、出口リンク識別子に関しては、（２）の説明を参照されたい。詳細は、本明細書では再び説明されない。入口リンク識別子は、第１のＩＡＢノードがデータパケットを受信する入口リンクを示すために使用される。具体的には、アップリンク送信の場合、入口リンク識別子は、第１のＩＡＢノードの子ノードの識別子であり得る。子ノードの識別子の具体例に関しては、（２）の説明を参照されたい。ダウンリンク送信の場合、入口リンク識別子は、第１のＩＡＢノードの親ノードの識別子であり得る。親ノードの識別子の具体例に関しては、（２）の説明を参照されたい。詳細は、本明細書では再び説明されない。

（５）第３のラベルとＱｏＳ識別子との間の対応付け。任意選択で、ＱｏＳ識別子と第３のＲＬＣチャネル識別子との間の対応付けがさらに含まれる。この対応付けにおいて、第３のラベルは、出口ＲＬＣチャネルとの対応付けを直接有しておらず、中間マッピング処理が存在し、すなわち、第３のラベルとＱｏＳ識別子との間の対応付けが存在し、ＱｏＳ識別子と出口ＲＬＣチャネルとの間の対応付けが存在する。第３のラベルとＱｏＳ識別子との間の対応付けと、ＱｏＳ識別子と第３のＲＬＣチャネル識別子との間の対応付けの両方が設定されてよく（例えば、第５の設定情報は、第３のラベルと、第３のラベルに対応するＱｏＳ識別子と、第３のＲＬＣチャネル識別子とを含む）、または、第３のラベルとＱｏＳ識別子との間の対応付けと、ＱｏＳ識別子と第３のＲＬＣチャネル識別子との間の対応付けは、別個に設定されてよい（例えば、第５の設定情報は、第３のラベルとＱｏＳ識別子とを含み、第３のラベルとＱｏＳ識別子との間の対応付けを設定し、他の設定情報は、第３のＲＬＣチャネル識別子とＱｏＳ識別子とを含み、ＱｏＳ識別子と第３のＲＬＣチャネル識別子との間の対応付けを設定する）。これは、本出願のこの実施形態において限定されない。

１つのＱｏＳ識別子が、１つまたは一群のＱｏＳパラメータ（ｐａｒａｍｅｔｅｒ）を表すために使用され得ることに留意されたい。ＱｏＳ識別子は、具体的には、ＱｏＳクラス識別子（ＱｏＳ Ｃｌａｓｓ Ｉｄｅｎｔｉｆｉｅｒ，ＱＣＩ）、５Ｇ ＱｏＳインジケータ（５Ｇ ＱｏＳ Ｉｎｄｉｃａｔｏｒ，５ＱＩ）、ＱｏＳフロー識別子（ＱｏＳ ｆｌｏｗ ｉｄｅｎｔｉｆｉｅｒ，ＱＦＩ）などであってよい。１つまたは一群のＱｏＳパラメータは、例えば、レイテンシ、パケット損失率、および帯域幅などを含む。

（６）第３のラベルとＱｏＳパラメータとの間の対応付け、およびＱｏＳパラメータと第３のＲＬＣチャネル識別子との間の対応付け。第３のラベルとＱｏＳパラメータとの間の対応付けと、ＱｏＳパラメータと第３のＲＬＣチャネル識別子との間の対応付けの両方が設定されてよく（例えば、第５の設定情報は、第３のラベルと、第３のラベルに対応するＱｏＳパラメータと、第３のＲＬＣチャネル識別子とを含む）、または、第３のラベルとＱｏＳパラメータとの間の対応付けと、ＱｏＳパラメータと第３のＲＬＣチャネル識別子との間の対応付けは、別個に設定されてよい（例えば、第５の設定情報は、第３のラベルとＱｏＳパラメータとを含み、第３のラベルとＱｏＳパラメータとの間の対応付けを設定し、他の設定情報は、第３のＲＬＣチャネル識別子とＱｏＳパラメータとを含み、ＱｏＳパラメータと第３のＲＬＣチャネル識別子との間の対応付けを設定する）。これは、本出願のこの実施形態において限定されない。

第３のラベルは、任意選択のフィールドとして使用され得ることに留意されたい。データパケットが第３のラベルを搬送しない場合、ＩＡＢノードに関してＩＡＢドナーによって設定される設定情報は、入口ＲＬＣチャネルと出口ＲＬＣチャネルとの間の対応付け、すなわち、第４のＲＬＣチャネル識別子と第３のＲＬＣチャネル識別子との間の対応付けのみを含み得る。

例えば、ＩＡＢドナーがＣＵおよびＤＵを含む場合、ＩＡＢドナーＣＵは、第１のＩＡＢノードに関する第５の設定情報を設定し得る。

例えば、ＩＡＢドナーＣＵがＣＰおよびＵＰを含む場合、ＩＡＢドナーＣＵ－ＣＰは、第１のＩＡＢノードに関する第５の設定情報を設定し得る。

本実施形態では、第１のＩＡＢノードは、中間ＩＡＢノードであり得る。ワイヤレスバックホールリンク上で中間ＩＡＢノードによって受信されたデータパケット（データパケットはアップリンクデータパケットまたはダウンリンクデータパケットであり得る）は、ラベルを搬送した。したがって、中間ＩＡＢノードは、データパケットにおいて搬送されたラベルに基づいてベアラマッピングを実行する必要があり、すなわち、データパケットの出口ＲＬＣチャネルを選択して、データパケットをネクストホップノードに送信する。本出願のこの実施形態では、中間ＩＡＢノードは、第５の設定情報に基づいて、受信されたデータパケットに対してベアラマッピングを実行し得る。説明が以下に詳細に提供される。

任意選択で、本出願のこの実施形態は、以下のステップをさらに含む。

ステップ１１０１：第１のＩＡＢノードはデータパケットを取得する。

データパケットは、第２のＩＡＢノードからのデータパケットであるか、または、データパケットは、ＩＡＢドナーからのデータパケットである。

データパケットのバックホール適応プロトコルＢＡＰレイヤヘッダは、第３のラベルを含む。

ステップ１１０２：第１のＩＡＢノードは、第３のラベルに基づいて第３のＲＬＣチャネル識別子を決定する。

例えば、第５の設定情報が、第３のラベル、入口リンク識別子、第４のＲＬＣチャネル識別子、出口リンク識別子、および第３のＲＬＣチャネル識別子を含むとき、第１のＩＡＢノードは、データパケットに対するルーティング選択を実行して出口リンク識別子を決定し、次いで、データパケット内の第３のラベルと、データパケットが受信される入口リンクと、データパケットが受信される入口リンク上の第４のＲＬＣチャネルとに基づいて第３のＲＬＣチャネル識別子を決定する。別の場合は説明されない。

ステップ１１０３：第１のＩＡＢノードが、第３のＲＬＣチャネル識別子に対応する出口ＲＬＣチャネルを介してデータパケットを送信する。

前述の処理において、第１のＩＡＢノードは、第５の設定情報に基づいてデータパケットに対してベアラマッピングを実行する。この解決策は、第１のＩＡＢノードがベアラマッピングをよりフレキシブルに実行して、ＩＡＢネットワークにおいてより細かいＱｏＳ保証を提供することを可能にし得る。

実施形態６
図１２は、本出願の実施形態によるデータパケット送信方法の概略フローチャートである。本方法は、以下のステップを含む。

ステップ１２００：第２のＩＡＢノードが、ＩＡＢドナーから第６の設定情報を受信する。

第２のＩＡＢノードは、アクセスＩＡＢノードであり得る。

例えば、ＩＡＢドナーがＣＵおよびＤＵを含む場合、ＩＡＢドナーＣＵは、第２のＩＡＢノードに関する第６の設定情報を設定し得る。

例えば、ＩＡＢドナーＣＵがＣＰおよびＵＰを含む場合、ＩＡＢドナーＣＵ－ＣＰは、第２のＩＡＢノードに関する第６の設定情報を設定し得る。

第６の設定情報は、第２のＩＡＢノードによって送信される必要がある第６のデータペイロードに対応して追加されるパケットヘッダ情報を設定するために使用される。第６のデータペイロードは、第２のＩＡＢノードとＩＡＢドナー（具体的には、ＩＡＢドナーＣＵ、またはＩＡＢドナーＣＵ－ＣＰであってよい）との間のＦ１制御プレーン（Ｆ１－Ｃ）メッセージ、すなわちＦ１ＡＰメッセージであってよい。パケットヘッダ情報は、ＩＰパケットヘッダ内のフィールドであり、具体的には、差別化されたサービス情報および／またはフローラベル（ｆｌｏｗ ｌａｂｅｌ）を含む。

可能な実装では、第６の設定情報は、具体的には、以下のコンテンツ、すなわち、
ＵＥ関連Ｆ１ＡＰメッセージ（ＵＥ ａｓｓｏｃｉａｔｅｄ Ｆ１ＡＰ ｍｅｓｓａｇｅ）のために指定された第１の差別化されたサービス情報および／または第１のフローラベルと、非ＵＥ関連Ｆ１ＡＰメッセージ（ｎｏｎ－ＵＥ ａｓｓｏｃｉａｔｅｄ Ｆ１ＡＰ ｍｅｓｓａｇｅ）のために指定された第２の差別化されたサービス情報および／または第２のフローラベルとのうちのいずれか１つまたは複数を含む。

別の可能な実装では、第６の設定情報は、具体的には、以下のコンテンツ、すなわち、
第１の端末デバイスの識別子と、第１の端末デバイスのＵＥ関連Ｆ１ＡＰメッセージのために指定された第１の差別化されたサービス情報および／または第１のフローラベルと、非ＵＥ関連Ｆ１ＡＰメッセージのために指定された第２の差別化されたサービス情報および／または第２のフローラベルとのうちのいずれか１つまたは複数を含む。

第６の設定情報に基づいて、第６のデータペイロードを含むアップリンクデータパケットを取得した後、第２のＩＡＢノードは、第６のデータペイロードに対応するＦ１ＡＰメッセージタイプに基づいて、差別化されたサービス情報および／またはＩＰパケットヘッダに追加されるべきフローラベルを決定し、次いで、差別化されたサービス情報および／またはフローラベルが追加されるアップリンクデータパケットをネクストホップノードに送信する。詳細に関しては、ステップ１２０１からステップ１２０３の説明を参照されたい。

任意選択で、本出願のこの実施形態は、以下のステップをさらに含む。

ステップ１２０１：第２のＩＡＢノードは、第６のデータペイロードを取得する。具体的には、第２のＩＡＢノードは、第６のデータペイロードを生成し得る。

ステップ１２０２：第２のＩＡＢノードは、第６のデータペイロードに対応する差別化されたサービス情報および／またはフローラベルを決定する。

第２のＩＡＢノードは、第６のデータペイロードに対応するＦ１ＡＰメッセージタイプ（例えば、非ＵＥ関連Ｆ１ＡＰメッセージまたはＵＥ関連Ｆ１ＡＰメッセージ）に基づいて、第６のデータペイロードに対応する差別化されたサービス情報および／もしくはフローラベルを決定してよく、または、第６のデータペイロードがＵＥ関連Ｆ１ＡＰメッセージであるとき、第２のＩＡＢノードは、第１の端末デバイスのものであり第６のデータペイロードに対応する識別子に基づいて、第６のデータペイロードに対応する差別化されたサービス情報および／もしくはフローラベルを決定してよい。具体的には、第６のデータペイロードが非ＵＥ関連Ｆ１ＡＰメッセージであるとき、第６のデータペイロードは、第２の差別化されたサービス情報および／もしくは第２のフローラベルに対応し、または、第６のデータペイロードがＵＥ関連Ｆ１ＡＰメッセージであるとき、第６のデータペイロードは、第１の差別化されたサービス情報および／もしくは第１のフローラベルに対応する。代替として、第６のデータペイロードが第１の端末デバイスのＵＥ関連Ｆ１ＡＰメッセージであるとき、第６のデータペイロードは、第１の差別化されたサービス情報および／または第１のフローラベルに対応する。

ステップ１２０３：第２のＩＡＢノードは、第６のデータパケットを親ノードに送信する。

第６のデータパケットは、第６のデータペイロードおよびＩＰパケットヘッダを含み、ＩＰパケットヘッダは、第６のデータペイロードに対応しステップ１２０２において決定される、差別化されたサービス情報および／またはフローラベルを含む。任意選択で、第２のＩＡＢノードは、第６のデータパケットに含まれる差別化されたサービス情報および／またはフローラベルに基づいて、第６のデータパケットを送信するために使用される出口ＢＨ ＲＬＣチャネルを決定してよい。

前述の処理では、第２のＩＡＢノードは、第６の設定情報に基づいて異なるタイプのＦ１ＡＰメッセージに異なる差別化されたサービス情報および／またはフローラベル値を追加し、その結果、第２のＩＡＢノードは、差別化されたサービス情報および／またはフローラベル値に対応するＢＨ ＲＬＣチャネルに基づいて、Ｆ１ＡＰメッセージを送信するために使用されるＢＨ ＲＬＣチャネルを決定し、異なるタイプのＦ１－Ｃメッセージに関する差別化されたＱｏＳ保証を提供することができる。

実施形態７
既存のデュアルコネクティビティ（Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ）のシナリオでは、ＵＥは、マスタノード（Ｍａｓｔｅｒ Ｎｏｄｅ，ＭＮ）とセカンダリノード（Ｓｅｃｏｎｄａｒｙ Ｎｏｄｅ，ＳＮ）の両方に接続される。ＭＮおよびＳＮは、同じアクセス規格を使用してよく（例えば、ＭＮとＳＮの両方がＬＴＥ規格またはＮＲ規格を使用する）、または、異なるアクセス規格を使用してよい（例えば、ＭＮがＬＴＥ規格を使用し、ＳＮがＮＲ規格を使用する、または、ＭＮがＮＲ規格を使用し、ＳＮがＬＴＥ規格を使用する）。マスターセルグループ（Ｍａｓｔｅｒ Ｃｅｌｌ Ｇｒｏｕｐ，ＭＣＧ）は、ＭＮに関連付けられたサービングセルを含み、少なくとも１つのプライマリセルＰＣｅｌｌを含み、任意選択で１つまたは複数のセカンダリセルＳＣｅｌｌを含む。同様に、セカンダリセルグループ（Ｓｅｃｏｎｄａｒｙ Ｃｅｌｌ Ｇｒｏｕｐ，ＳＣＧ）は、ＳＮに関連付けられたサービングセルを含み、少なくとも１つのプライマリセル（例えば、プライマリセカンダリセル（ＰＳＣｅｌｌ））を含み、任意選択で、１つまたは複数のセカンダリセルＳＣｅｌｌを含む。ＭＣＧリンクは、ＵＥとＭＮとの間のシングルホップアクセスリンクであり、ＳＣＧリンクは、ＵＥとＳＮとの間のシングルホップアクセスリンクである。

ＵＥが、ＵＥとＭＮとの間のＭＣＧリンク上で無線リンク障害（Ｒａｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ，ＲＬＦ）が発生したことを発見するとき、ＵＥは、ＲＲＣ接続再確立処理をトリガしてＭＣＧリンクを回復する。ＵＥが、ＵＥとＳＮとの間のＳＣＧリンク上でＲＬＦが発生したことを発見するとき、ＵＥは、ＲＲＣ接続再確立処理をトリガしないが、ＭＣＧを使用することによってＳＣＧ障害報告（ＳＣＧ ｆａｉｌｕｒｅ ｒｅｐｏｒｔ）をＭＮに送信し、その結果、ＭＮは、ＳＣＧリンクを回復するために、ＳＣＧ障害回復処理をトリガし、例えば、ＳＣＧ変更処理をトリガする。３ＧＰＰリリース１６では、既存のＤＣが強化され、ＭＣＧ高速回復メカニズムが導入される。具体的には、ＵＥが、ＵＥとＭＮとの間のＭＣＧリンク上でＲＬＦが発生したことを発見するとき、ＵＥは、ＳＣＧ障害メカニズムと同様のメカニズムを使用し、ＲＲＣ接続再確立処理をトリガしなくなるが、ＳＣＧを使用することによってＭＣＧ障害報告（ＭＣＧ ｆａｉｌｕｒｅ ｒｅｐｏｒｔ）を送信する。

ＩＡＢのシナリオでは、ＩＡＢノード（ＩＡＢ ｎｏｄｅ）は、ＥＮ－ＤＣ（Ｅ－ＵＴＲＡＮ ＮＲ Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ）に基づいて、スタンドアロン（ｓｔａｎｄａｌｏｎｅ，ＳＡ）モードまたは非スタンドアロン（ｎｏｎ－ｓｔａｎｄａｌｏｎｅ，ＮＳＡ）モードにおいて動作することができる。

本実施形態では、ＩＡＢノードがＮＳＡモードにおいて動作することが主に考慮される。図１３に示されるように、ＩＡＢノードにサービスを提供するＭＮはｅＮＢであり、ＩＡＢノードにサービスを提供するＳＮはＩＡＢドナー（ＩＡＢ ｄｏｎｏｒ）である。ＭＮはＬＴＥ規格を使用し、ＳＮはＮＲ規格を使用する。同様に、ＭＣＧリンクは、ＩＡＢノード（すなわち、ＩＡＢノードＭＴ）とＭＮとの間のリンクであり、ＳＣＧリンクは、ＩＡＢノード（すなわち、ＩＡＢノードＭＴ）とＳＮとの間のリンクである。

ＩＡＢノードとＩＡＢドナーとの間のＳＣＧリンク上でＲＬＦが発生したことをＩＡＢノードが検出するとき、ＩＡＢノードは、ＭＣＧリンクを介して、ＩＡＢノードにサービスを提供するｅＮＢにＳＣＧ障害報告を送信し、その結果、ｅＮＢは、ＳＣＧ障害回復処理をトリガしてＳＣＧリンクを回復する。

ＳＣＧリンクが回復されることに失敗するか、または回復されることが可能でない（例えば、ＳＣＧの変更が失敗するか、またはＳＣＧの解放が実行される）とき、ＩＡＢノードは、１つのＲＬＦ表示情報をＩＡＢノードの子ノードに送信する必要があり、その結果、ＩＡＢノードの子ノードは、対応する処理を実行する。可能な実装では、ＩＡＢノードの子ノードが、ＩＡＢノードによって送信されたＲＬＦ表示情報を受信するとき、ＩＡＢノードの子ノードは、ＭＣＧを使用することによって、子ノードにサービスを提供するｅＮＢにＳＣＧ障害報告を送信する。ＩＡＢノードの子ノードは、ＵＥまたは別のＩＡＢノードであってよい。ＩＡＢノードにサービスを提供するｅＮＢは、ＩＡＢノードの子ノードにサービスを提供するｅＮＢと同じであっても異なっていてもよい。これは、本実施形態において限定されない。

本実施形態は、ＩＡＢマルチホップのシナリオにも適用可能であることに留意されたい。具体的には、ＩＡＢノードとドナーノードとの間のリンク上に別のＩＡＢノードが存在することがあり、すなわち、ＩＡＢノードが別のＩＡＢノードを使用することによってドナーノードに接続されるシナリオである。詳細は、本明細書では説明されない。

本明細書において説明される実施形態は、独立した解決策であってよく、または、内部論理に基づいて組み合わされてよい。これらの解決策はすべて、本出願の保護範囲内に入る。

前述の方法の実施形態において、端末デバイスによって実施される方法および動作は、代替として、端末デバイスにおいて使用され得る構成要素（例えば、チップまたは回路）によって実施されてよく、ネットワークデバイスによって実施される方法および動作は、代替として、ネットワークデバイスにおいて使用され得る構成要素（例えば、チップまたは回路）によって実施されてよいことが理解され得る。

以上は、ネットワーク要素間の相互作用の観点から、本出願において提供される解決策を主に説明する。前述の機能を実装するために、各ネットワーク要素は、各機能を実装するための対応するハードウェア構造および／またはソフトウェアモジュールを含むことが理解され得る。当業者は、本明細書に開示される実施形態を参照して説明される例におけるユニット、アルゴリズム、およびステップが、本発明において、ハードウェアまたはハードウェアとコンピュータソフトウェアとの組合せによって実装されることが可能であることを容易に認識するであろう。機能が、ハードウェアによって実行されるか、またはコンピュータソフトウェアによって駆動されるハードウェアによって実行されるかは、技術的な解決策の特定の用途および設計制約に依存する。当業者は、異なる方法を使用して各特定の用途に関して説明された機能を実装してよいが、実装が本発明の範囲を超えると見なされるべきでない。

図１４は、本出願による通信装置の可能な例示的なブロック図である。装置１４００は、ソフトウェアまたはハードウェアの形態で存在し得る。装置１４００は、処理ユニット１４０１および通信ユニット１４０２を含み得る。実装では、通信ユニット１４０２は、受信ユニットおよび送信ユニットを含み得る。処理ユニット１４０１は、装置１４００の動作を制御および管理するように構成される。通信ユニット１４０２は、別のネットワークエンティティと通信する際に装置１４００をサポートするように構成される。

装置１４００が、図４に示される方法の実施形態においてＩＡＢドナーの機能を実装するように構成されるとき、以下の動作が実行される。

処理ユニットは、第１の設定情報を決定するように構成され、第１の設定情報は、第１のバックホールリンクＢＨ無線リンク制御ＲＬＣチャネルを示すために使用され、第１のＢＨ ＲＬＣチャネルは、バックホール適応プロトコルＢＡＰレイヤにおいて制御プロトコルデータユニットＰＤＵを送信するために使用される。

通信ユニットは、第１の設定情報をＩＡＢノードに送信するように構成される。

可能な実装では、第１の設定情報が、第１のＢＨ ＲＬＣチャネルのチャネル識別子を含むか、または、
第１の設定情報が、論理チャネル識別子を含み、論理チャネル識別子によって示される論理チャネルは、第１のＢＨ ＲＬＣチャネルに対応する。

装置１４００が、図４に示される方法の実施形態においてＩＡＢノードの機能を実装するように構成されるとき、以下の動作が実行される。

処理ユニットは、ＢＡＰレイヤにおいて制御プロトコルデータユニットＰＤＵを送信するために使用される第１のバックホールリンクＢＨ無線リンク制御ＲＬＣチャネルを決定するように構成される。

通信ユニットは、ＢＡＰレイヤにおける制御ＰＤＵを、第１のＢＨ ＲＬＣチャネルを介してＩＡＢノードの隣接ノードに送信するように構成される。

可能な実装では、処理ユニットは、具体的には、
ＩＡＢドナーから第１の設定情報を取得し、ここで、第１の設定情報は、ＢＡＰレイヤにおいて制御ＰＤＵを送信するために使用される第１のＢＨ ＲＬＣチャネルを示すために使用され、
第１の設定情報に基づいて第１のＢＨ ＲＬＣチャネルを決定するように構成される。

可能な実装では、第１の設定情報が、第１のＢＨ ＲＬＣチャネルのチャネル識別子を含むか、または、
第１の設定情報が、論理チャネル識別子を含み、論理チャネル識別子によって示される論理チャネルは、第１のＢＨ ＲＬＣチャネルに対応する。

装置１４００が、図５に示される方法の実施形態においてＩＡＢドナーの機能を実装するように構成されるとき、以下の動作が実行される。

処理ユニットが、第２の設定情報を決定するように構成され、第２の設定情報は、第２のバックホールリンクＢＨ無線リンク制御ＲＬＣチャネルを示すために使用され、第２のＢＨ ＲＬＣチャネルは、第１のタイプのデータペイロードを送信するために使用され、第１のタイプのデータペイロードは、Ｆ１ユーザプレーンＦ１－ＵデータペイロードおよびＦ１制御プレーンＦ１－Ｃデータペイロード以外のデータペイロードである。

通信ユニットは、第２の設定情報をＩＡＢノードに送信するように構成される。

可能な実装では、第１のタイプのデータペイロードは、以下の、
運用、管理、および保守ＯＡＭトラフィックパケットと、
インターネットプロトコルＩＰアドレスを要求するために使用されるパケットと、
インターネットプロトコルセキュリティＩＰｓｅｃ送信チャネルを確立するために使用されるパケットと、
ストリーム制御トランスポートプロトコルＳＣＴＰアソシエーションセットアップパケットと、
ＳＣＴＰアソシエーションシャットダウンパケットと、
ＳＣＴＰアソシエーションハートビートパケットとのうちのいずれか１つを含む。

可能な実装では、第２の設定情報は、以下の、
第１のタイプであって、データペイロードのタイプであり、第２のＢＨ ＲＬＣチャネルに対応する第１のタイプと、
第１の差別化されたサービス情報であって、第１のタイプおよび／または第２のＢＨ ＲＬＣチャネルに対応する第１の差別化されたサービス情報と、
第１のフローラベルであって、第１のタイプおよび／または第２のＢＨ ＲＬＣチャネルに対応する第１のフローラベルとのうちのいずれか１つまたは複数を含む。

可能な実装では、処理ユニットは、
第１のデータペイロードを生成するようにさらに構成され、第１のデータペイロードは、第１のタイプのデータペイロードであり、
第１のデータペイロードに対応するパケットヘッダ情報が第１の差別化されたサービス情報を搬送する場合、通信ユニットは、第１の差別化されたサービス情報に対応する第２のＢＨ ＲＬＣチャネルを介してＩＡＢノードに第１のデータパケットを送信するようにさらに構成され、または、第１のデータペイロードに対応するパケットヘッダ情報が第１のフローラベルを搬送する場合、通信ユニットは、第１のフローラベルに対応する第２のＢＨ ＲＬＣチャネルを介してＩＡＢノードに第１のデータパケットを送信するようにさらに構成され、第１のデータパケットは、第１のデータペイロードを含む。

可能な実装では、第２の設定情報は、第２のＢＨ ＲＬＣチャネルを識別するために使用される識別情報を含み、識別情報は、第２のＢＨ ＲＬＣチャネルのチャネル識別子であるか、または、識別情報は、第２のＢＨ ＲＬＣチャネルに対応する論理チャネル識別子である。

装置１４００が、図５に示される方法の実施形態においてＩＡＢノードの機能を実装するように構成されるとき、以下の動作が実行される。

通信ユニットが、ＩＡＢドナーから第２の設定情報を受信するように構成され、第２の設定情報は、第２のバックホールリンクＢＨ無線リンク制御ＲＬＣチャネルを示すために使用され、第２のＢＨ ＲＬＣチャネルは、第１のタイプのデータペイロードを送信するために使用され、第１のタイプのデータペイロードは、Ｆ１ユーザプレーンＦ１－ＵデータペイロードおよびＦ１制御プレーンＦ１－Ｃデータペイロード以外のデータペイロードである。

処理ユニットは、第２の設定情報に基づいて第１のタイプのデータペイロードを送信するように構成される。

可能な実装では、第１のタイプのデータペイロードは、以下の、
運用、管理、および保守ＯＡＭトラフィックパケットと、
インターネットプロトコルＩＰアドレスを要求するために使用されるパケットと、
インターネットプロトコルセキュリティＩＰｓｅｃ送信チャネルを確立するために使用されるパケットと、
ストリーム制御トランスポートプロトコルＳＣＴＰアソシエーションセットアップパケットと、
ＳＣＴＰアソシエーションシャットダウンパケットと、
ＳＣＴＰアソシエーションハートビートパケットとのうちのいずれか１つを含む。

可能な実装では、第２の設定情報は、以下の、
第１のタイプであって、データペイロードのタイプであり、第２のＢＨ ＲＬＣチャネルに対応する第１のタイプと、
第１の差別化されたサービス情報であって、第１のタイプおよび／または第２のＢＨ ＲＬＣチャネルに対応する第１の差別化されたサービス情報と、
第１のフローラベルであって、第１のタイプおよび／または第２のＢＨ ＲＬＣチャネルに対応する第１のフローラベルとのうちのいずれか１つまたは複数を含む。

可能な実装では、第２の設定情報は、第２のＢＨ ＲＬＣチャネルを識別するために使用される識別情報を含み、識別情報は、第２のＢＨ ＲＬＣチャネルのチャネル識別子であるか、または、識別情報は、第２のＢＨ ＲＬＣチャネルに対応する論理チャネル識別子である。

装置１４００は、図７に示される方法の実施形態においてＩＡＢドナーの機能をさらに実装してよく、装置１４００は、図１０に示される方法の実施形態において第２のＩＡＢノードの機能をさらに実装してよく、装置１４００は、図１１に示される方法の実施形態において第１のＩＡＢノードの機能をさらに実装してよく、装置１４００は、図１２に示される方法の実施形態において第２のＩＡＢノードの機能をさらに実装してよい。詳細については、前述の説明を参照されたい。詳細は、本明細書では再び説明されない。

図１５は、本出願の実施形態による装置１５００を示す。図１５に示される装置は、図１４に示される装置のハードウェア回路の実装であってよい。通信装置は、上記に示されたフローチャートにおいて使用されてよく、前述の方法の実施形態においてＩＡＢノードまたはＩＡＢドナーの機能を実行する。説明を容易にするために、図１５は、通信装置の主要な構成要素のみを示す。

図１５に示される装置１５００は、少なくとも１つのプロセッサ１５０１を含む。例えば、プロセッサ１５０１は、汎用中央処理ユニット（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ，ＣＰＵ）、汎用プロセッサ、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ，ＤＳＰ）、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ，ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ，ＦＰＧＡ）もしくは別のプログラマブル論理デバイス、トランジスタ論理デバイス、ハードウェア構成要素、またはそれらの任意の組合せであってよい。プロセッサは、本出願において開示される内容を参照して説明される様々な例示的な論理ブロック、モジュール、および回路を実装または実行することがある。代替として、プロセッサは、計算機能を実施するプロセッサの組合せ、例えば、１つもしくは複数のマイクロプロセッサの組合せ、またはＤＳＰとマイクロプロセッサとの組合せであってよい。

装置１５００は、プログラム命令および／またはデータを記憶するように構成された少なくとも１つのメモリ１５０２をさらに含んでよい。メモリ１５０２は、プロセッサ１５０１に結合される。本出願のこの実施形態における結合は、装置、ユニット、またはモジュールの間の情報交換のための装置、ユニット、またはモジュールの間の間接結合または通信接続であり、電気的、機械的、または他の形態であってよい。プロセッサ１５０１は、メモリ１５０２と協働して動作し得る。プロセッサ１５０１は、メモリ１５０２に記憶されたプログラム命令を実行し得る。少なくとも１つのメモリのうちの少なくとも１つは、プロセッサに含まれ得る。

装置１５００は、送信媒体を介して別のデバイスと通信するように構成された通信インターフェース１５０３をさらに含んでよく、その結果、装置１５００内の装置は、別のデバイスと通信することができる。本出願のこの実施形態では、通信インターフェースは、トランシーバ、回路、バス、モジュール、または別のタイプの通信インターフェースであってよい。本出願のこの実施形態では、トランシーバは、独立した受信機、独立した送信機、トランシーバ機能と統合されたトランシーバ、またはインターフェース回路であってよい。

装置１５００は、通信線１５０４をさらに含んでよい。通信インターフェース１５０３、プロセッサ１５０１、およびメモリ１５０２は、通信線１５０４を介して互いに接続されてよい。通信線１５０４は、周辺部品相互接続（ｐｅｒｉｐｈｅｒａｌ ｃｏｍｐｏｎｅｎｔ ｉｎｔｅｒｃｏｎｎｅｃｔ，略してＰＣＩ）バス、拡張型業界標準アーキテクチャ（ｅｘｔｅｎｄｅｄ ｉｎｄｕｓｔｒｙ ｓｔａｎｄａｒｄ ａｒｃｈｉｔｅｃｔｕｒｅ，略してＥＩＳＡ）バスなどであってよい。通信線１５０４は、アドレスバス、データバス、制御バスなどに分類され得る。表現を容易にするために、図１５では、通信線を表すために１つの太線のみが使用されているが、これは、１つのバスのみまたは１つのタイプのバスのみが存在することを意味するものではない。

装置１５００は、図４に示される方法の実施形態においてＩＡＢノードまたはＩＡＢドナーの機能を実装してよく、装置１５００は、図５に示される方法の実施形態においてＩＡＢノードまたはＩＡＢドナーの機能をさらに実装してよく、装置１５００は、図７に示される方法の実施形態においてＩＡＢドナーの機能をさらに実装してよく、装置１５００は、図１０に示される方法の実施形態において第２のＩＡＢノードの機能をさらに実装してよく、装置１５００は、図１１に示される方法の実施形態において第１のＩＡＢノードの機能をさらに実装してよく、装置１５００は、図１２に示される方法の実施形態において第２のＩＡＢノードの機能をさらに実装してよい。詳細については、前述の説明を参照されたい。詳細は、本明細書では再び説明されない。

当業者は、本出願の実施形態が、方法、システム、またはコンピュータプログラム製品として提供され得ることを理解するであろう。したがって、本出願は、ハードウェアのみの実施形態、ソフトウェアのみの実施形態、またはソフトウェアとハードウェアとの組合せを有する実施形態の形態を使用し得る。さらに、本出願は、コンピュータ使用可能なプログラムコードを含む１つまたは複数のコンピュータ使用可能な記憶媒体（限定はされないが、ディスクメモリ、光メモリなどを含む）上に実装されるコンピュータプログラム製品の形態を使用し得る。

本出願は、本出願による方法、デバイス（システム）、およびコンピュータプログラム製品のフローチャートおよび／またはブロック図を参照して説明される。コンピュータプログラム命令が、フローチャートおよび／またはブロック図における各手順および／または各ブロック、ならびにフローチャートおよび／またはブロック図における手順および／またはブロックの組合せを実施するために使用され得ることを理解されたい。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組込みプロセッサ、または別のプログラマブルデータ処理デバイスのプロセッサに提供されてマシンを生成してよく、その結果、コンピュータまたは別のプログラマブルデータ処理デバイスのプロセッサによって実行される命令は、フローチャート内の１つもしくは複数の手順および／またはブロック図内の１つもしくは複数のブロックにおける特定の機能を実装するための装置を生成する。

これらのコンピュータプログラム命令は、代替として、コンピュータまたは別のプログラマブルデータ処理デバイスが特定の方法で動作することを示すことができるコンピュータ可読メモリに記憶されてよく、その結果、コンピュータ可読メモリに記憶された命令は、命令装置を含むアーティファクトを生成する。命令装置は、フローチャート内の１つもしくは複数の手順および／またはブロック図内の１つもしくは複数のブロックにおける特定の機能を実施する。

当業者が、本出願の範囲から逸脱することなく、本出願に対して様々な修正および変形を行うことができることは明らかである。本出願は、本出願のこれらの修正および変形を、それらが本出願の特許請求の範囲およびその均等な技術によって定義される保護の範囲内に入るという条件で網羅することが意図される。

Claims (21)

1. データパケット送信方法であって、
   統合されたアクセスおよびバックホール（ＩＡＢ）ドナーによって第１の設定情報を決定するステップであって、前記第１の設定情報は、バックホール適応プロトコル（ＢＡＰ）レイヤにおいて制御プロトコルデータユニット（ＰＤＵ）を送信するために使用される第１のバックホールリンク（ＢＨ）無線リンク制御（ＲＬＣ）チャネルを示す、ステップと、
   前記ＩＡＢドナーによって、前記第１の設定情報をＩＡＢノードに送信するステップと
   を備える、方法。
2. 前記第１の設定情報が、前記第１のＢＨ ＲＬＣチャネルのチャネル識別子を備えるか、または、
   前記第１の設定情報が、論理チャネル識別子を備え、前記論理チャネル識別子によって示される論理チャネルは、前記第１のＢＨ ＲＬＣチャネルに対応する、請求項１に記載の方法。
3. データパケット送信方法であって、
   統合されたアクセスおよびバックホール（ＩＡＢ）ノードによってＩＡＢドナーから、バックホール適応プロトコル（ＢＡＰ）レイヤにおいて制御プロトコルデータユニット（ＰＤＵ）を送信するために使用される第１のバックホールリンク（ＢＨ）無線リンク制御（ＲＬＣ）チャネルを示す第１の設定情報を受信するステップと、
   前記ＩＡＢノードによって前記第１の設定情報に基づいて、前記ＢＡＰレイヤにおいて前記制御ＰＤＵを送信するために使用される前記第１のＢＨ ＲＬＣチャネルを決定するステップと、
   前記ＩＡＢノードによって、前記ＢＡＰレイヤにおいて前記制御ＰＤＵを、前記第１のＢＨ ＲＬＣチャネルを介して前記ＩＡＢノードの隣接ノードに送信するステップと
   を備える、方法。
4. 前記第１の設定情報が、前記第１のＢＨ ＲＬＣチャネルのチャネル識別子を備えるか、または、
   前記第１の設定情報が、論理チャネル識別子を備え、前記論理チャネル識別子によって示される論理チャネルは、前記第１のＢＨ ＲＬＣチャネルに対応する、請求項３に記載の方法。
5. データパケットのベアラマッピング方法であって、
   統合されたアクセスおよびバックホール（ＩＡＢ）ドナーによって、第２の設定情報を決定するステップであって、前記第２の設定情報は、第１のタイプのデータペイロードの送信用である第２のバックホールリンク（ＢＨ）無線リンク制御（ＲＬＣ）チャネルを示し、前記第１のタイプのデータペイロードは、バックホール適応プロトコル（ＢＡＰ）レイヤにおける制御プロトコルデータユニット（ＰＤＵ）、Ｆ１ユーザプレーン（Ｆ１－Ｕ）データペイロードおよびＦ１制御プレーン（Ｆ１－Ｃ）データペイロード以外のデータペイロードである、ステップと、
   前記ＩＡＢドナーによって、前記第２の設定情報をＩＡＢノードに送信するステップと
   を備える、方法。
6. 前記第１のタイプのデータペイロードは、以下の、
   運用、管理、および保守（ＯＡＭ）トラフィックパケットと、
   インターネットプロトコル（ＩＰ）アドレスを要求するために使用されるパケットと、
   インターネットプロトコルセキュリティ（ＩＰｓｅｃ）送信チャネルを確立するために使用されるパケットと、
   ストリーム制御トランスポートプロトコル（ＳＣＴＰ）アソシエーションセットアップパケットと、
   ＳＣＴＰアソシエーションシャットダウンパケットと、
   ＳＣＴＰアソシエーションハートビートパケットとのうちのいずれか１つを備える、請求項５に記載の方法。
7. 前記第２の設定情報は、以下の、
   第１のタイプであって、データペイロードのタイプであり、前記第２のＢＨ ＲＬＣチャネルに対応する第１のタイプと、
   第１の差別化されたサービス情報であって、前記第１のタイプおよび／または前記第２のＢＨ ＲＬＣチャネルに対応する第１の差別化されたサービス情報と、
   第１のフローラベルであって、前記第１のタイプおよび／または前記第２のＢＨ ＲＬＣチャネルに対応する第１のフローラベルとのうちのいずれか１つまたは複数を備える、請求項５または６に記載の方法。
8. 前記方法は、
   前記ＩＡＢドナーによって第１のデータペイロードを生成するステップであって、前記第１のデータペイロードは、前記第１のタイプのデータペイロードである、ステップと、
   前記第１のデータペイロードに対応するパケットヘッダ情報が第１の差別化されたサービス情報を搬送する場合、前記ＩＡＢドナーによって、前記第１の差別化されたサービス情報に対応する前記第２のＢＨ ＲＬＣチャネルを介して前記ＩＡＢノードに第１のデータパケットを送信するか、または、前記第１のデータペイロードに対応するパケットヘッダ情報が第１のフローラベルを搬送する場合、前記ＩＡＢドナーによって、前記第１のフローラベルに対応する前記第２のＢＨ ＲＬＣチャネルを介して前記ＩＡＢノードに第１のデータパケットを送信するステップであって、前記第１のデータパケットは、前記第１のデータペイロードを備える、ステップと
   をさらに備える、請求項５から７のいずれか一項に記載の方法。
9. 前記第２の設定情報は、前記第２のＢＨ ＲＬＣチャネルを識別する識別情報を備え、前記識別情報は、前記第２のＢＨ ＲＬＣチャネルのチャネル識別子であるか、または、前記識別情報は、前記第２のＢＨ ＲＬＣチャネルに対応する論理チャネル識別子である、請求項５から８のいずれか一項に記載の方法。
10. データパケットのベアラマッピング方法であって、
    統合されたアクセスおよびバックホール（ＩＡＢ）ノードによって、ＩＡＢドナーから第２の設定情報を受信するステップであって、前記第２の設定情報は、第１のタイプのデータペイロードの送信用である第２のバックホールリンク（ＢＨ）無線リンク制御（ＲＬＣ）チャネルを示し、前記第１のタイプのデータペイロードは、バックホール適応プロトコル（ＢＡＰ）レイヤにおける制御プロトコルデータユニット（ＰＤＵ）、Ｆ１ユーザプレーン（Ｆ１－Ｕ）データペイロードおよびＦ１制御プレーン（Ｆ１－Ｃ）データペイロード以外のデータペイロードである、ステップと、
    前記ＩＡＢノードによって、前記第２の設定情報に基づいて前記第１のタイプのデータペイロードを送信するステップと
    を備えるベアラマッピング方法。
11. 前記第１のタイプのデータペイロードは、以下の、
    運用、管理、および保守（ＯＡＭ）トラフィックパケットと、
    インターネットプロトコル（ＩＰ）アドレスを要求するために使用されるパケットと、
    インターネットプロトコルセキュリティ（ＩＰｓｅｃ）送信チャネルを確立するために使用されるパケットと、
    ストリーム制御トランスポートプロトコル（ＳＣＴＰ）アソシエーションセットアップパケットと、
    ＳＣＴＰアソシエーションシャットダウンパケットと、
    ＳＣＴＰアソシエーションハートビートパケットとのうちのいずれか１つを備える、請求項１０に記載の方法。
12. 前記第２の設定情報は、以下の、
    第１のタイプであって、データペイロードのタイプであり、前記第２のＢＨ ＲＬＣチャネルに対応する第１のタイプと、
    第１の差別化されたサービス情報であって、前記第１のタイプおよび／または前記第２のＢＨ ＲＬＣチャネルに対応する第１の差別化されたサービス情報と、
    第１のフローラベルであって、前記第１のタイプおよび／または前記第２のＢＨ ＲＬＣチャネルに対応する第１のフローラベルとのうちのいずれか１つまたは複数を備える、請求項１０または１１に記載の方法。
13. 前記第２の設定情報は、前記第２のＢＨ ＲＬＣチャネルを識別するために使用される識別情報を備え、前記識別情報は、前記第２のＢＨ ＲＬＣチャネルのチャネル識別子であるか、または、前記識別情報は、前記第２のＢＨ ＲＬＣチャネルに対応する論理チャネル識別子である、請求項１０から１２のいずれか一項に記載の方法。
14. メモリおよびプロセッサを備える通信装置であって、前記メモリは、命令を記憶するように構成され、前記プロセッサは、前記メモリに記憶された前記命令を実行するように構成され、前記メモリに記憶された前記命令は、前記プロセッサによって実行されて、前記装置に、請求項１または２に記載の方法を実行させる、通信装置。
15. メモリおよびプロセッサを備える通信装置であって、前記メモリは、命令を記憶するように構成され、前記プロセッサは、前記メモリに記憶された前記命令を実行するように構成され、前記メモリに記憶された前記命令は、前記プロセッサによって実行されて、前記装置に、請求項３または４に記載の方法を実行させる、通信装置。
16. メモリおよびプロセッサを備える通信装置であって、前記メモリは、命令を記憶するように構成され、前記プロセッサは、前記メモリに記憶された前記命令を実行するように構成され、前記メモリに記憶された前記命令は、前記プロセッサによって実行されて、前記装置に、請求項５から９のいずれか一項に記載の方法を実行させる、通信装置。
17. メモリおよびプロセッサを備える通信装置であって、前記メモリは、命令を記憶するように構成され、前記プロセッサは、前記メモリに記憶された前記命令を実行するように構成され、前記メモリに記憶された前記命令は、前記プロセッサによって実行されて、前記装置に、請求項１０から１３のいずれか一項に記載の方法を実行させる、通信装置。
18. 記録されたプログラムを有するコンピュータ可読記憶媒体であって、前記プログラムはコンピュータに、請求項１または２に記載の方法を実行させる、コンピュータ可読記憶媒体。
19. 記録されたプログラムを有するコンピュータ可読記憶媒体であって、前記プログラムはコンピュータに、請求項３または４に記載の方法を実行させる、コンピュータ可読記憶媒体。
20. 記録されたプログラムを有するコンピュータ可読記憶媒体であって、前記プログラムはコンピュータに、請求項５乃至９のいずれか一項に記載の方法を実行させる、コンピュータ可読記憶媒体。
21. 記録されたプログラムを有するコンピュータ可読記憶媒体であって、前記プログラムはコンピュータに、請求項１０乃至１３のいずれか一項に記載の方法を実行させる、コンピュータ可読記憶媒体。

Images