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

データパケット送信方法および装置 Download PDF

Info

Publication number
JP2022549953A
JP2022549953A JP2022519832A JP2022519832A JP2022549953A JP 2022549953 A JP2022549953 A JP 2022549953A JP 2022519832 A JP2022519832 A JP 2022519832A JP 2022519832 A JP2022519832 A JP 2022519832A JP 2022549953 A JP2022549953 A JP 2022549953A
Authority
JP
Japan
Prior art keywords
rlc channel
channel
configuration information
iab
data payload
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2022519832A
Other languages
English (en)
Other versions
JP7482997B2 (ja
Inventor
元萍 朱
玉▲竜▼ 史
菁 ▲劉▼
▲義▼斌 卓
振臻 曹
明▲増▼ 戴
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2022549953A publication Critical patent/JP2022549953A/ja
Application granted granted Critical
Publication of JP7482997B2 publication Critical patent/JP7482997B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/24Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/248Connectivity information update
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/02Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08Access point devices
    • H04W88/085Access point devices with remote components

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

データパケット送信方法および装置が提供される。本方法は、以下のことを含む。IABドナーが、第1の設定情報を決定し、ここで、第1の設定情報は、第1のバックホールリンクBH RLCチャネルを示すために使用され、第1のBH RLCチャネルは、バックホール適応プロトコルBAPレイヤにおいて制御プロトコルデータユニットPDUを送信するために使用される。IABドナーが、第1の設定情報をIABノードに送信する。前述の手順によれば、IABドナーは、第1の設定情報を使用することによって、IABノードがBAPレイヤにおいて第1のBH RLCチャネルを介して制御PDUを送信することを示し、IABノードがBAPレイヤにおいて制御PDUを送信する必要があるとき、ベアラマッピングを実施する。

Description

本出願は、ワイヤレス通信技術の分野に関し、詳細には、データパケット送信方法および装置に関する。
統合されたアクセスおよびバックホール(integrated access and backhaul,IAB)ネットワーク技術が、第5世代(5th generation,5G)モバイル通信システムに導入されている。ワイヤレス送信の解決策が、IABネットワークにおけるアクセスリンク(access link)とバックホールリンク(backhaul link)の両方に使用され、光ファイバの導入を避け、導入コストを低減し、導入のフレキシビリティを改善する。IABネットワークは、IABノード(IAB node)およびIABドナー(IAB donor)を含む。端末側デバイスは、IABノードにアクセスすることがあり、端末側デバイスのトラフィックデータは、ワイヤレスバックホールリンクを介してIABノードからIABドナーに送信されることがある。
しかしながら、既存のベアラマッピングは、主に、F1インターフェース上でIABノードとドナーノードとの間で送信されるF1ユーザプレーン(F1 user plane,F1-U)データペイロードおよびF1制御プレーン(F1 control plane,F1-C)データペイロード上で実行される。実際には、IABノードとドナーノードとの間で送信される必要がある他のタイプのデータペイロード、すなわち、F1ユーザプレーンデータペイロードおよびF1制御プレーンデータペイロード以外のデータペイロードが存在する。これらのデータペイロードは、非F1トラフィック(non-F1 traffic)データペイロードとまとめて呼ばれることがある。ワイヤレスバックホールリンク上の非F1トラフィックデータパケットに対するベアラマッピングをどのように実行するかは、従来の技術には関与しておらず、できる限り早く解決される必要がある問題である。
本出願の実装は、データパケット送信方法および装置を提供し、バックホールリンク上でデータペイロードに対するベアマッピングをどのように実行するかという対応する問題を解決する。
第1の態様によれば、本出願の実施形態は、以下のことを含むデータパケット送信方法を提供する。IABドナーが、第1の設定情報を決定し、第1の設定情報は、第1のBH RLCチャネルを示すために使用され、第1のBH RLCチャネルは、BAPレイヤにおいて制御PDUを送信するために使用される。IABドナーが、第1の設定情報をIABノードに送信する。
前述の手順によれば、IABドナーは、第1の設定情報を使用することによって、IABノードがBAPレイヤにおいて第1のBH RLCチャネルを介して制御PDUを送信することを示し、IABノードがBAPレイヤにおいて制御PDUを送信する必要があるとき、ベアラマッピングを実施する。
可能な実装では、第1の設定情報が、第1のBH RLCチャネルのチャネル識別子を含むか、または、
第1の設定情報が、論理チャネル識別子を含み、論理チャネル識別子によって示される論理チャネルは、第1のBH RLCチャネルに対応する。
第2の態様によれば、データパケット送信方法が提供され、本方法は以下のことを含む。IABノードが、BAPレイヤにおいて制御PDUを送信するために使用される第1のBH RLCチャネルを決定する。IABノードが、BAPレイヤにおいて制御PDUを、第1のBH RLCチャネルを介してIABノードの隣接ノードに送信する。
前述の手順によれば、IABドナーは、第1の設定情報を使用することによって、IABノードがBAPレイヤにおいて第1のBH RLCチャネルを介して制御PDUを送信することを示し、IABノードがBAPレイヤにおいて制御PDUを送信する必要があるとき、ベアラマッピングを実施する。
可能な実装では、IABノードがBAPレイヤにおいて制御PDUを送信するために使用される第1のバックホールリンクBH RLCチャネルを決定することは、以下のことを含む。IABノードが、IABドナーから第1の設定情報を取得し、第1の設定情報は、BAPレイヤにおいて制御PDUを送信するために使用される第1のBH RLCチャネルを示すために使用される。IABノードが、第1の設定情報に基づいて第1のBH RLCチャネルを決定する。
可能な実装では、第1の設定情報が、第1のBH RLCチャネルのチャネル識別子を含むか、または、第1の設定情報が、論理チャネル識別子を含み、論理チャネル識別子によって示される論理チャネルは、第1のBH RLCチャネルに対応する。
第3の態様によれば、データパケット送信方法が提供され、本方法は以下のことを含む。IABドナーが、第2の設定情報を決定し、第2の設定情報は、第2のバックホールリンクBH無線リンク制御RLCチャネルを示すために使用され、第2のBH RLCチャネルは、第1のタイプのデータペイロードを送信するために使用され、第1のタイプのデータペイロードは、F1ユーザプレーンF1-UデータペイロードおよびF1制御プレーンF1-Cデータペイロード以外のデータペイロードである。IABドナーが、第2の設定情報をIABノードに送信する。
前述の手順によれば、IABドナーは、第2の設定情報を使用することによって、IABノードが第2のBH RLCチャネルを介して第1のタイプのデータペイロードを送信することを示し、第1のタイプのデータペイロードに関するベアラマッピングを実施する。
可能な実装では、第1のタイプのデータペイロードは、以下の、
運用、管理、および保守OAMトラフィックパケットと、インターネットプロトコルIPアドレスを要求するために使用されるパケットと、インターネットプロトコルセキュリティIPsec送信チャネルを確立するために使用されるパケットと、ストリーム制御トランスポートプロトコルSCTPアソシエーションセットアップパケットと、SCTPアソシエーションシャットダウンパケットと、SCTPアソシエーションハートビートパケットとのうちのいずれか1つを含む。
可能な実装では、第2の設定情報は、以下の、
第1のタイプであって、データペイロードのタイプであり、第2のBH RLCチャネルに対応する第1のタイプと、第1の差別化されたサービス情報であって、第1のタイプおよび/または第2のBH RLCチャネルに対応する第1の差別化されたサービス情報と、第1のフローラベルであって、第1のタイプおよび/または第2のBH RLCチャネルに対応する第1のフローラベルとのうちのいずれか1つまたは複数を含む。
可能な実装では、本方法は、以下のことをさらに含む。IABドナーが、第1のデータペイロードを生成し、第1のデータペイロードは、第1のタイプのデータペイロードである。第1のデータペイロードに対応するパケットヘッダ情報が第1の差別化されたサービス情報を搬送する場合、IABドナーは、第1の差別化されたサービス情報に対応する第2のBH RLCチャネルを介してIABノードに第1のデータパケットを送信するか、または、第1のデータペイロードに対応するパケットヘッダ情報が第1のフローラベルを搬送する場合、IABドナーは、第1のフローラベルに対応する第2のBH RLCチャネルを介してIABノードに第1のデータパケットを送信し、第1のデータパケットは、第1のデータペイロードを含む。
可能な実装では、第2の設定情報は、第2のBH RLCチャネルを識別するために使用される識別情報を含み、識別情報は、第2のBH RLCチャネルのチャネル識別子であるか、または、識別情報は、第2のBH RLCチャネルに対応する論理チャネル識別子である。
第4の態様によれば、データパケット送信方法が提供され、本方法は以下のことを含む。IABノードが、IABドナーから第2の設定情報を受信し、第2の設定情報は、第2のバックホールリンクBH無線リンク制御RLCチャネルを示すために使用され、第2のBH RLCチャネルは、第1のタイプのデータペイロードを送信するために使用され、第1のタイプのデータペイロードは、F1ユーザプレーンF1-UデータペイロードおよびF1制御プレーンF1-Cデータペイロード以外のデータペイロードである。IABノードが、第2の設定情報に基づいて第1のタイプのデータペイロードを送信する。
前述の手順によれば、IABノードは、IABドナーによって送信された第2の設定情報を使用することによって、第1のタイプのデータペイロードが第2のBH RLCチャネルを介して送信されることを決定し、第1のタイプのデータペイロードに関してベアラマッピングを実施する。
可能な実装では、第1のタイプのデータペイロードは、以下の、
運用、管理、および保守OAMトラフィックパケットと、インターネットプロトコルIPアドレスを要求するために使用されるパケットと、インターネットプロトコルセキュリティIPsec送信チャネルを確立するために使用されるパケットと、ストリーム制御トランスポートプロトコルSCTPアソシエーション設定パケットと、SCTPアソシエーションシャットダウンパケットと、SCTPアソシエーションハートビートパケットとのうちのいずれか1つを含む。
可能な実装では、第2の設定情報は、以下の、
第1のタイプであって、データペイロードのタイプであり、第2のBH RLCチャネルに対応する第1のタイプと、第1の差別化されたサービス情報であって、第1のタイプおよび/または第2のBH RLCチャネルに対応する第1の差別化されたサービス情報と、第1のフローラベルであって、第1のタイプおよび/または第2のBH RLCチャネルに対応する第1のフローラベルとのうちのいずれか1つまたは複数を含む。
可能な実装では、第2の設定情報は、第2のBH RLCチャネルを識別するために使用される識別情報を含み、識別情報は、第2のBH RLCチャネルのチャネル識別子であるか、または、識別情報は、第2のBH RLCチャネルに対応する論理チャネル識別子である。
第5の態様によれば、データパケット送信方法が提供され、本方法は以下のことを含む。IABドナーが、第3のデータペイロードに対応するパケットヘッダ情報に基づいて第1のラベルを決定し、第1のラベルは、第3のデータペイロードの出口無線リンク制御RLCチャネルを決定するために使用される。IABドナーが、IABノードに第3のデータパケットを送信し、第3のデータパケットは、第3のデータペイロードおよび第1のバックホール適応プロトコルBAPレイヤヘッダを含み、第1のBAPレイヤヘッダは、第1のラベルを含む。
前述の手順によれば、IABドナーは、第1のラベルを使用して第3のデータペイロードの出口無線リンク制御RLCチャネルを示し、第3のデータペイロードの入口RLCチャネルのみに基づいて第3のデータペイロードの出口RLCチャネルを決定しなくなり、第3のデータペイロードのフレキシブルな送信を実施する。
可能な実装では、IABドナーが第3のデータペイロードに対応するパケットヘッダ情報に基づいて第1のラベルを決定することは、以下のことを含む。
IABドナーが、第3の設定情報を取得する。IABドナーが、第3のデータペイロードに対応するパケットヘッダ情報および第3の設定情報に基づいて第1のラベルを決定し、第3の設定情報は、パケットヘッダ情報内の第1の情報と第1のラベルとの間の対応付けを設定するために使用され、第1の情報は、以下の、
第1の差別化されたサービス情報と、第1のフローラベルと、第1のインターネットプロトコルIPアドレスとのいずれか1つまたは複数を含む。
第6の態様によれば、データパケット送信方法が提供され、本方法は以下のことを含む。第2のIABノードが、第4のデータペイロードを取得する。第2のIABノードが、第4のデータペイロードに対応するパケットヘッダ情報または第4のデータペイロードに対応するメッセージタイプに基づいて第2のラベルを決定し、第2のラベルは、第4のデータペイロードの出口無線リンク制御RLCチャネルを決定するために使用される。第2のIABノードが、第1のIABノードに第4のデータパケットを送信し、第4のデータパケットは、第4のデータペイロードおよび第2のバックホール適応プロトコルBAPレイヤヘッダを含み、第2のBAPレイヤヘッダは、第2のラベルを含む。
可能な実装では、第2のIABノードが第4のデータペイロードに対応するパケットヘッダ情報に基づいて第2のラベルを決定することは、以下のことを含む。
第2のIABノードが、IABドナーから第4の設定情報を受信する。
第2のIABノードが、第4のデータペイロードに対応するパケットヘッダ情報および第4の設定情報に基づいて第2のラベルを決定する。
第4の設定情報は、パケットヘッダ情報内の第2の情報と第2のラベルとの間の対応付けを設定するために使用され、第2の情報は、以下の、
パケットヘッダ情報内の第2の差別化サービス情報と、パケットヘッダ情報内の第2のフローラベルと、パケットヘッダ情報内の第2のIPアドレスと、パケットヘッダ情報内にあり、第4のデータペイロードに対応するデータ無線ベアラ情報と、第4のデータペイロードの第2のタイプと、第4のデータペイロードがF1APメッセージであるとき、F1APメッセージを搬送するSCTPレイヤにおけるストリーム識別子とのうちのいずれか1つまたは複数を含む。
可能な実装では、第2のIABノードが第4のデータペイロードに対応するメッセージタイプに基づいて第2のラベルを決定することは、以下のことを含む。
第2のIABノードが、IABドナーから第4の設定情報を受信する。
第2のIABノードが、第4のデータペイロードに対応するメッセージタイプに基づいて第4の設定情報から第2のラベルを決定する。
第4のデータペイロードは、制御プレーンF1アプリケーションプロトコルF1APメッセージであり、第4の設定情報は、以下の、
第4のデータペイロードの第2のタイプと、第2のタイプに対応する第2のラベルとの1つまたは複数を含み、第2のタイプは、F1APメッセージタイプ、すなわち、
第4のデータペイロードがF1APメッセージであるとき、F1APメッセージを搬送するSCTPレイヤにおけるストリーム識別子と、ストリーム識別子に対応する第2のラベルとのいずれか1つまたは複数である。
第7の態様によれば、データパケット送信方法が提供され、本方法は以下のことを含む。
第1の統合されたアクセスおよびバックホールIABノードが、データパケットを取得し、データパケットは、第2のIABノードからのデータパケットまたはIABドナーからのデータパケットであり、データパケットのバックホール適応プロトコルBAPレイヤヘッダは、第3のラベルを含み、第3のラベルは、データパケットの出口無線リンク制御RLCチャネルを決定するために使用される。
第1のIABノードが、第3のラベルに基づいて第3のRLCチャネル識別子を決定し、第3のRLCチャネル識別子は、データパケットの出口RLCチャネルの識別子である。
第1のIABノードが、第3のRLCチャネル識別子に対応する出口RLCチャネルを介してデータパケットを送信する。
可能な実装では、第1のIABノードが第3のラベルに基づいて第3のRLCチャネル識別子を決定することは、以下のことを含む。
第1のIABノードが、IABドナーから第5の設定情報を受信し、第5の設定情報は、第3のラベルと第3のRLCチャネル識別子との間の対応付けを設定するために使用される。
第1のIABノードが、第3のRLCチャネル識別子として、第5の設定情報内にあり第3のラベルに対応するRLCチャネル識別子を決定する。
代替として、第1のIABノードが、第3のRLCチャネル識別子として、第5の設定情報内にあり第3のラベルに対応するRLCチャネル識別子と第4のRLCチャネル識別子とを決定し、第4のRLCチャネル識別子は、データパケットを受信するための入口RLCチャネルの識別子である。
代替として、第1のIABノードが、第5の設定情報から、第3のラベルに対応する第1のサービス品質QoS識別子を決定し、第3のRLCチャネル識別子として、第5の設定情報内にあり第1のQoS識別子に対応するRLCチャネル識別子を決定する。
代替として、第1のIABノードが、第5の設定情報から、第3のラベルに対応する第1のQoSパラメータを決定し、第3のRLCチャネル識別子として、第5の設定情報内にあり第1のQoSパラメータに対応するRLCチャネル識別子を決定する。
可能な実装では、第5の設定情報は、以下の、
第3のラベルと第3のRLCチャネル識別子との間の対応付けと、
第3のラベル、第4のRLCチャネル識別子、および第3のRLCチャネル識別子の間の対応付けと、
第3のラベルとサービス品質QoS識別子との間の対応付けと、
QoS識別子と第3のRLCチャネル識別子との間の対応付けと、
第3のラベルとQoSパラメータとの間の対応付けと、
QoSパラメータと第3のRLCチャネル識別子との間の対応付けとのいずれか1つまたは複数を含む。
第8の態様によれば、本出願は、通信装置をさらに提供する。通信装置は、前述の態様のいずれか1つにおいて提供された任意の方法を実施する機能を有する。通信装置は、ハードウェアによって実装されることがあるか、または対応するソフトウェアを実行するハードウェアによって実装されることがある。ハードウェアまたはソフトウェアは、前述の機能に対応する1つまたは複数のユニットを含む。
可能な実装では、通信装置は、プロセッサを含み、プロセッサは、前述の方法における第1のIABノード、第2のIABノード、IABドナー、またはIABノードの対応する機能を実行する際に通信装置をサポートするように構成される。通信装置はメモリをさらに含むことがあり、メモリは、プロセッサに結合されることがあり、通信装置に必要なプログラム命令およびデータを記憶する。任意選択で、通信装置は、通信インターフェースをさらに含み、通信インターフェースは、通信装置と、第1のIABノード、第2のIABノード、IABドナー、またはIABノードなどのデバイスとの間の通信をサポートするように構成される。
可能な実装では、通信装置は、前述の方法におけるステップを実施するようにそれぞれ構成された対応する機能ユニットを含む。機能は、ハードウェアによって実装されることがあるか、または対応するソフトウェアを実行するハードウェアによって実装されることがある。ハードウェアまたはソフトウェアは、前述の機能に対応する1つまたは複数のユニットを含む。
可能な実装では、通信装置の構造は、処理ユニットおよび通信ユニットを含む。これらのユニットは、前述の方法の例における対応する機能を実行し得る。詳細に関しては、前述の態様のいずれか1つによる方法における説明を参照されたい。詳細は、本明細書では再び説明されない。
第9の態様によれば、本出願は、プロセッサおよびメモリを含む通信装置を提供する。メモリは、コンピュータ実行可能命令を記憶するように構成され、本装置が動作するとき、プロセッサは、メモリに記憶されたコンピュータ実行可能命令を実行し、その結果、本装置は、前述の態様における方法を実行する。
第10の態様によれば、本出願は、前述の態様におけるステップを実行するように構成されたユニットまたは手段(means)を含む通信装置を提供する。
第11の態様によれば、本出願は、プロセッサおよび通信インターフェースを含む通信装置を提供する。プロセッサは、通信インターフェースを介して別の装置と通信し、前述の態様における方法を実行するように構成される。1つまたは複数のプロセッサが存在する。
第12の態様によれば、本出願は、少なくとも1つのメモリに接続し、少なくとも1つのメモリに記憶されたプログラムを呼び出し、前述の態様における方法を実行するように構成されたプロセッサを含む通信装置を提供する。少なくとも1つのメモリは、装置の内部に配置されることがあり、または装置の外部に配置されることがある。加えて、1つまたは複数のプロセッサが存在する。
第13の態様によれば、本出願は、コンピュータ可読記憶媒体をさらに提供する。コンピュータ可読記憶媒体は、命令を記憶し、命令がコンピュータ上で実行されるとき、コンピュータは、前述の態様における方法を実行することを可能にされる。
第14の態様によれば、本出願は、命令を含むコンピュータプログラム製品をさらに提供し、コンピュータプログラム製品がコンピュータ上で動作するとき、コンピュータは、前述の態様における方法を実行することを可能にされる。
第15の態様によれば、本出願は、前述の態様における方法を実行するように構成されたプロセッサを含むチップシステムをさらに提供する。
第16の態様によれば、本出願は、上記で提供された第1のIABノード、第2のIABノード、およびIABドナーを含むチップシステムをさらに提供する。
本出願の実施形態が適用可能な通信システムの概略図である。 本出願の実施形態によるIABドナーの構造の概略図である。 本出願の実施形態による、RLCチャネル、論理チャネル、およびプロトコルエンティティの間の対応付けの概略図である。 本出願の実施形態による、RLCチャネル、論理チャネル、およびプロトコルエンティティの間の対応付けの概略図である。 本出願の実施形態によるデータパケット送信方法の概略フローチャートである。 本出願の実施形態によるデータパケット送信方法の概略フローチャートである。 本出願の実施形態によるデータパケットの構造の概略図である。 本出願の実施形態によるデータパケット送信方法の概略フローチャートである。 本出願の実施形態によるデータパケットの構造の概略図である。 本出願の実施形態によるデータパケットの構造の概略図である。 本出願の実施形態によるデータパケット送信方法の概略フローチャートである。 本出願の実施形態によるデータパケット送信方法の概略フローチャートである。 本出願の実施形態によるデータパケット送信方法の概略フローチャートである。 本出願の実施形態による、非スタンドアロンモードにおけるネットワークアーキテクチャの概略図である。 本出願の実施形態による通信装置の構造の概略図である。 本出願の実施形態による通信装置の構造の概略図である。
以下では、添付図面を参照して、本出願の実施形態をさらに詳細に説明する。
本出願の実施形態は、様々なモバイル通信システム、例えば、新無線(new radio,NR)システム、ロングタームエボリューション(long term evolution,LTE)システム、ロングタームエボリューションアドバンスト(long term evolution-advanced,LTE-A)システム、発展型ロングタームエボリューション(evolved long term evolution,eLTE)システム、将来の通信システム、および別の通信システムに適用され得る。具体的には、これは本明細書において限定されない。
本出願の実施形態では、端末側デバイスは、ワイヤレストランシーバ機能を有するデバイス、またはデバイス内に配置されることが可能であるチップである。ワイヤレストランシーバ機能を有するデバイスは、ユーザ機器(user equipment,UE)、アクセス端末、加入者ユニット、加入者局、移動局、リモート局、リモート端末、モバイルデバイス、ユーザ端末、ユーザエージェント、またはユーザ装置と呼ばれることもある。実際の適用では、本出願の実施形態における端末側デバイスは、携帯電話(mobile phone)、タブレットコンピュータ(Pad)、ワイヤレストランシーバ機能を有するコンピュータ、仮想現実(virtual reality,VR)端末、拡張現実(augmented reality,AR)端末、産業制御(industrial control)におけるワイヤレス端末、自動運転(self driving)におけるワイヤレス端末、遠隔医療(remote medical)におけるワイヤレス端末、スマートグリッド(smart grid)におけるワイヤレス端末、交通安全(transportation safety)におけるワイヤレス端末、スマートシティ(smart city)におけるワイヤレス端末、スマートホーム(smart home)におけるワイヤレス端末などであり得る。適用のシナリオは、本出願の実施形態において限定されない。本出願では、ワイヤレストランシーバ機能を有するデバイス、およびデバイス内に配置されることが可能であるチップは、まとめて端末側デバイスと呼ばれる。
本出願の実施形態では、ネットワーク側デバイスは、様々な規格における無線アクセスデバイス、例えば、発展型ノードB(evolved NodeB,eNB)、無線ネットワークコントローラ(radio network controller,RNC)、ノードB(NodeB,NB)、基地局コントローラ(base station controller,BSC)、基地トランシーバ局(base transceiver station,BTS)、ホーム基地局(例えば、home evolved NodeB、またはhome NodeB,HNB)、ベースバンドユニット(baseband unit,BBU)、ワイヤレスフィデリティ(wireless fidelity,Wi-Fi)システムにおけるアクセスポイント(access point,AP)、ワイヤレス中継ノード、ワイヤレスバックホールノード、または送信ポイント(transmission reception point,TRPまたはtransmission point,TP)であり得る。ネットワーク側デバイスは、代替として、5G(NR)システムにおけるgNBまたは送信ポイント(TRPまたはTP)、5Gシステムにおける基地局の1つまたは一群のアンテナパネル(複数のアンテナパネルを含む)、gNBまたは送信ポイントを構成するネットワークノード、例えば、ベースバンドユニット(BBU)、中央ユニット分散型ユニット(central unit-distributed unit,CU-DU)アーキテクチャにおけるDUまたはCUなどであり得る。
本出願の実施形態では、ワイヤレス通信ネットワークにおけるIABのシナリオが、いくつかのシナリオを説明するための例として使用される。本出願の実施形態における解決策は、別のワイヤレス通信ネットワークにさらに適用されてよく、対応する名称は、別のワイヤレス通信ネットワークにおける対応する機能の名称と置き換えられてもよいことに留意されたい。
本出願の実施形態の理解を容易にするために、図1に示される通信システムが、本出願の実施形態が適用可能な通信システムを詳細に説明するための例として最初に使用される。図1は、本出願の実施形態が適用可能な通信システムの概略図である。図1に示されるように、通信システムは、基地局と、IABドナーと、IABノード1と、IABノード2と、端末側デバイスとを含む。
本出願のこの実施形態では、統合されたアクセスおよびバックホールをサポートするノードは、IABノードと呼ばれ、IABノードは、中継ノード(relay node,RN)と呼ばれることもある。説明を容易にするために、ノードと中継ノードの両方は、以下でIABノードと呼ばれる。IABノードは、端末側デバイスにワイヤレスアクセスサービスを提供することがあり、端末側デバイスのトラフィックデータまたは制御情報は、ワイヤレスバックホールリンクを介してIABノードからIABドナー(IAB donor)または別のネットワーク側デバイスに送信される。IABノードは、少なくとも1つのモバイル端末(mobile terminal,MT)ユニットおよび少なくとも1つの分散型ユニット(distributed unit,DU)を含み得る。本出願のこの実施形態では、IABノードが1つのMTユニットおよび1つのDUを含む例のみが、説明のために使用される。IABノード内のMTユニットは、IABノードが、IABノードの親ノードおよびIABドナーと通信するための端末として機能することを実施する。IABノード内のDUは、端末側デバイス、またはDUに取り付けられた別のIABノードにアクセスサービスを提供し、F1インターフェースを介してIABドナーと通信することもある。IABノード内のMTユニットは、IABノード内のMT機能エンティティと呼ばれることもあり、IABノード内のDUは、IABノード内のDU機能エンティティと呼ばれることもある。説明を容易にするために、IABノード内のMTユニットとIABノード内のMT機能エンティティの両方は、簡潔に「IABノードMT」と呼ばれ、IABノード内のDUとIABノード内のDU機能エンティティの両方は、簡潔に「IABノードDU」と呼ばれる。
本出願のこの実施形態では、IABドナーは、完全な基地局機能を有するアクセスネットワーク要素であってよく、または集中型ユニット(centralized unit,CU)と分散型ユニット(distributed unit,DU)とが分離された形態のアクセスネットワーク要素であってよい。詳細に関しては、図2を参照されたい。図2では、IABドナーCUは、代替として、制御プレーン(control plane,CP)とユーザプレーン(user plane,UP)とが分離された形態であってよい。例えば、1つのIABドナーCUは、1つのCU-CPと複数のCU-UPとを含む。これは、本出願のこの実施形態において限定されない。
IABドナー内のCUは、IABドナー内のCU機能エンティティと呼ばれることもあり、IABドナー内のDUは、IABドナー内のDU機能エンティティと呼ばれることもある。説明を容易にするために、本出願のこの実施形態では、IABドナー内のCUおよびIABドナー内のCU機能エンティティは、簡潔にIABドナーCUと呼ばれ、IABドナー内のDUおよびIABドナー内のDU機能エンティティは、簡潔にIABドナーDUと呼ばれる。
加えて、図1は、デバイス間のインターフェースの名称をさらに示す。例えば、端末側デバイスとIABノード1との間にはNR Uuインターフェースが存在し、IABノード2とIABドナーとの間にはNR Unインターフェースが存在する。インターフェースの名称は、単なる例であり、インターフェースに対する限定を表すものではない。通信システムのバージョンが変わるとき、対応する名称は、別のワイヤレス通信ネットワークにおける対応する機能の名称と置き換えられてもよい。加えて、基地局が5Gにおける基地局であるとき、IABドナーと基地局との間のインターフェースは、Xnインターフェースであり得る。基地局がLTEにおける基地局であるとき、IABドナーと基地局との間のインターフェースは、X2インターフェースであり得る。
図1に示されるIABネットワークは、マルチホップネットワーキングをサポートする。例えば、図1に示されるIABノード1とIABドナーとの間に中間IABノード(すなわち、IABノード2)が存在する。別の可能なネットワーキングのシナリオでは、IABノード1は、他の中間IABノードなしにIABドナーに直接接続されてもよいか、または、IABノード1とIABドナーとの間に2つ以上の中間IABノードが存在してよい。
図1に示されるIABネットワークは、マルチホップネットワーキングとマルチ接続ネットワーキングの両方をサポートする。複数のリンクを含む少なくとも1つの送信経路が、IABノードによってサービスされる端末側デバイスとIABドナーとの間に存在し得る。IABノードとIABドナーとの間に1つまたは複数の送信経路が存在してもよく、各送信経路は、1つまたは複数のIABノードを含んでよい。送信経路上で、各IABノードは、IABノードにバックホールサービスを提供する隣接ノードを親ノードと見なし、それに応じて、各IABノードは、IABノードの親ノードの子ノードと見なされ得る。例えば、図1に示されるシナリオでは、IABノード2の親ノードは、IABドナーであり、IABドナーは、IABノード2を子ノードと見なす。
別の可能な非スタンドアロン(Non-standalone)マルチ接続ネットワーキングのシナリオでは、IABノードによってサービスされる端末側デバイスは、IABノードへの接続を確立してよく、LTEにおけるUuインターフェースを介して基地局(LTEネットワークにおける発展型NodeB eNB)に直接接続されてもよい。同様に、IABノードは、LTEにおけるUuインターフェースを介して基地局に接続されることがあり、1ホップまたはマルチホップのNRワイヤレスバックホールリンクを介してIABドナーに接続されることもある。IABドナーと基地局とは、X2インターフェースを介して接続される。
本出願のこの実施形態では、いくつかの技術用語、例えば、ノードの前ホップノード、ノードのネクストホップノード、ノードの入口リンク(ingress link)、およびノードの出口リンク(egress link)が使用され得る。以下では、最初に、これらの技術用語について説明する。
ノードの前ホップノード:ノードの前ホップノードは、ノードを含む経路上にあり、ノードの前にデータパケットを受信する、最後のノードである。
ノードのネクストホップノード:ノードのネクストホップノードは、ノードを含む経路上にあり、ノードの後にデータパケットを受信する、第1のノードである。
ノードの入口リンク:ノードの入口リンクは、ノードとノードの前ホップノードとの間のリンクであり、ノードの前ホップリンクと呼ばれることもある。
ノードの出口リンク:ノードの出口リンクは、ノードとノードのネクストホップノードとの間のリンクであり、ノードのネクストホップリンクと呼ばれることもある。
親ノードおよび子ノード:各IABノードは、IABノードにワイヤレスアクセスサービスおよび/またはワイヤレスバックホールサービスを提供するノードを親ノード(parent node)と見なす。それに応じて、各IABノードは、IABノードの親ノードの子ノード(child node)と見なされ得る。代替として、子ノードは、下位レベルノードと呼ばれることもあり、親ノードは、上位レベルノードと呼ばれることもある。
F1インターフェース:本出願のこの実施形態におけるF1インターフェースは、IABノードDUとIABドナーまたはIABドナーCUとの間のインターフェースである。F1インターフェースは、F1*インターフェースなどの名称で呼ばれることもある。説明を容易にするために、本出願のこの実施形態では、インターフェースは、まとめてF1インターフェースと呼ばれ得るが、名称は限定されない。
F1インターフェースは、デバイス内の機能エンティティ間のインターフェースであってもよいことに留意されたい。例えば、DUおよびCUを含む基地局の場合、F1インターフェースは、基地局内のDUと基地局内のCUとの間のインターフェースであり得る。
本出願のこの実施形態では、F1インターフェースは、ユーザプレーンプロトコルおよび制御プレーンプロトコルをサポートする。例えば、F1インターフェースのユーザプレーンプロトコルレイヤは、汎用パケット無線サービス(General Packet Radio Service,GPRS)トンネリングプロトコルユーザプレーン(GPRS Tunneling Protocol User Plane,GTP-U)レイヤと、ユーザデータグラムプロトコル(user datagram protocol,UDP)レイヤと、インターネットプロトコル(internet protocol,IP)レイヤとを含む。任意選択で、F1インターフェースのユーザプレーンプロトコルレイヤは、PDCPレイヤおよび/またはIPセキュリティ(IP Security,略してIPsec)レイヤをさらに含む。
例えば、F1インターフェースの制御プレーンプロトコルレイヤは、F1アプリケーションプロトコル(F1 application protocol,F1AP)レイヤと、ストリーム制御トランスポートプロトコル(stream control transport protocol,SCTP)レイヤと、IPレイヤとを含む。任意選択で、F1インターフェースの制御プレーンプロトコルレイヤは、PDCPレイヤ、IPsecレイヤ、およびデータグラムトランスポートレイヤセキュリティ(datagram transport layer security,略してDTLS)レイヤのうちの1つまたは複数をさらに含む。
加えて、本出願のこの実施形態では、様々なメッセージおよび情報、例えば、第1の設定情報、第2の設定情報、および第3の設定情報について説明するために用語の前に「第1の」、「第2の」、「第3の」などが追加され得るが、「第1の」、「第2の」、「第3の」などは、メッセージ、情報などを区別するために使用されるにすぎず、メッセージ、情報などが限定されることを意味しないことを理解されたい。
図1を参照すると、図3(a)および図3(b)は各々、RLCチャネル、論理チャネル(logical channel,LCH)、およびプロトコルエンティティの間の対応付けの概略図である。図3(a)および図3(b)に示されるように、無線リンク制御(radio link control,RLC)チャネル(channel)は、RLCエンティティとRLCエンティティの上位レイヤプロトコルエンティティとの間のチャネルである。例えば、RLCエンティティの上位レイヤがPDCPエンティティである場合、バックホールリンク上のRLCチャネルは、RLCエンティティとPDCPエンティティとの間のチャネルである。別の例では、RLCエンティティの上位レイヤがバックホール適応プロトコル(Backhaul Adaptation Protocol,BAP)エンティティである場合、バックホールリンク上のRLCチャネルは、RLCエンティティとBAPエンティティとの間のチャネルである。したがって、RLCチャネルは、RLCエンティティの上位レイヤプロトコルエンティティによって具体的に決定される。
論理チャネルは、RLCエンティティとRLCエンティティの下位レイヤプロトコルエンティティとの間のチャネルである。例えば、RLCエンティティの下位レイヤがMACレイヤである場合、論理チャネルは、RLCエンティティとMACエンティティとの間のチャネルである。
IABノードのRLCチャネルは、RLCエンティティに1つずつ対応し、RLCベアラにも1つずつ対応する。
BAPエンティティとRLCエンティティとの関係に関しては、図3(a)に示されるように、1つのBAPエンティティが、複数のRLCエンティティに対応することがあるか、または、図3(b)に示されるように、1つのBAPエンティティが、1つのRLCエンティティに対応することがある。これは、本出願において限定されない。
加えて、BAPレイヤは、以下の能力、すなわち、データパケットにワイヤレスバックホールノード(IABノード)によって識別されることが可能であるルーティング情報(routing information)を追加することと、ワイヤレスバックホールノードによって識別されることが可能であるルーティング情報に基づいてルーティング選択を実行することと、ワイヤレスバックホールノードによって識別されることが可能でありサービス品質(quality of service,QoS)要件に関連付けられた識別情報をデータパケットに追加することと、ワイヤレスバックホールノードを含む複数のリンク上のデータパケットに対してQoSマッピングを実行することと、データパケットタイプ表示情報をデータパケットに追加することと、フロー制御能力を有するノードにフロー制御フィードバック情報を送信することのうちの1つまたは複数を有する。これらの能力を有するプロトコルレイヤの名称は、必ずしもBAPレイヤであるとは限らないか、または、別の名称であってよいことに留意されたい。当業者は、これらの能力を有する任意のプロトコルレイヤが、本出願の実施形態におけるBAPレイヤとして理解されることがあることを理解し得る。BHリンク上のRLCチャネルは、2つのノード間のBHリンク上のトラフィック差別化チャネルとして理解されることがあり、サービス差別化チャネルは、データパケット送信のための特定のサービス品質QoS保証を提供することがある。BHリンク上のRLCチャネルは、物理チャネルではなく論理チャネルとして理解され得る。
本出願のこの実施形態では、BH RLCチャネル、すなわち、BHリンク上のRLCチャネルは、2つのノード間のBHリンク上のトラフィック差別化チャネルとして理解され得る。トラフィック差別化チャネルは、データパケット送信のための特定のサービス品質(quality of service,QoS)保証を提供し得る。BHリンク上のRLCチャネルは、物理チャネルではなく論理チャネルとして理解され得る。
具体的には、BHリンク上のRLCチャネルは、BHリンク上で接続された2つの隣接ノードのピアRLCチャネルとして理解され得る。例えば、図1において、IABドナーDUは、RLCチャネル1およびRLCチャネル2を有し、IABノード1は、RLCチャネル1およびRLCチャネル2を有する。IABドナーDUのRLCチャネル1は、IABノード1のRLCチャネル1のピアであり、IABドナーDUのRLCチャネル2は、IABノード1のRLCチャネル2のピア(peer)である。IABドナーDUとIABノード1との間のBHリンク上のRLCチャネル1は、IABドナーDUのRLCチャネル1およびIABノード1のRLCチャネル1であってよく、IABドナーDUとIABノード1との間のBHリンク上のRLCチャネル2は、IABドナーDUのRLCチャネル2およびIABノード1のRLCチャネル2であってよい。
RLCチャネル、RLCベアラ、および論理チャネルは、1対1の対応付けであるので、本出願のこの実施形態では、3つの説明は、互いに代用し得る。例えば、本出願のこの実施形態では、RLCチャネルは、RLCベアラまたは論理チャネルと置き換えられてよい。同様に、BHリンク上のRLCチャネルは、BHリンク上のRLCベアラまたはBHリンク上の論理チャネルと置き換えられ得る。BHリンク上のRLCベアラは、BHベアラまたはBHリンクベアラと呼ばれることもある。
ノードがデータパケットを受信するときに使用されるRLCチャネルは、入口RLCチャネル(ingress RLC channel)と呼ばれることもあり、データパケットが送信されるときに使用されるRLCチャネルは、出口RLCチャネル(egress RLC channel)と呼ばれることに留意されたい。
前述の説明を参照すると、IABネットワークでは、IABノードとドナーノードとの間で送信されるデータペイロードは、F1トラフィックデータペイロードおよび非F1トラフィック(non-F1 traffic)データペイロードを含み得る。F1トラフィックデータペイロードは、F1ユーザプレーン(F1-U)データペイロードまたはF1制御プレーン(F1-C)データペイロードを含む。非F1トラフィックデータペイロードは、F1ユーザプレーンデータペイロードおよびF1制御プレーンデータペイロード以外のデータペイロードを含み得る。これらのデータペイロードは、本出願の実施形態では、まとめて第1のタイプのデータペイロードと呼ばれる。
現在、非F1トラフィックデータペイロードは、複数の形態であり得る。例えば、非F1トラフィックデータペイロードは、BAPレイヤにおける制御(control)プロトコルデータユニット(Protocol Data Unit,PDU)と、IABノード(特定の実装ではIABノードDUであり得る)の運用、管理、および保守(Operation,Administration,and Maintenance,OAM)トラフィックデータパケットと、ストリーム制御トランスポートプロトコル(stream control transport protocol,SCTP)アソシエーション(association)がIABノード(特定の実装ではIABノードDUであり得る)とIABドナーとの間で確立されるとき、またはSCTPアソシエーションが維持されるときに送信されるデータパケットと、インターネットプロトコルセキュリティ(Internet Protocol Security,IPsec)送信チャネルがIABノード(特定の実装ではIABノードDUであり得る)とIABドナーとの間で確立されるときに関与しているデータパケットとを含み得る。ワイヤレスバックホールリンク上の非F1トラフィックデータペイロードに対するベアラマッピングをどのように実行するかは、従来の技術には関与していない。本出願の実施形態は、ワイヤレスバックホールリンク上の非F1トラフィックデータペイロードに対するベアラマッピングを実行するための方法を提供する。説明が以下に提供される。
実施形態1
BAPレイヤにおける制御PDUが、IABノードとIABドナーとの間で送信される。BAPレイヤにおける制御PDUは、非F1トラフィックデータパケットと見なされることがあり、制御PDUにおいて搬送されるデータペイロードは、F1ユーザプレーンデータペイロードおよびF1制御プレーンデータペイロード以外のデータペイロードである。
本出願のこの実施形態では、BAPレイヤにおける制御PDUは、2つの隣接ノード間で交換される。例えば、子ノードが、制御PDUを親ノードに送信するか、または、親ノードが、制御PDUを子ノードに送信する。子ノードは、IABノードであってよく、親ノードは、別のIABノードであってよいか、または、親ノードは、IABドナー(特定の実装ではIABドナーDUであり得る)であってよい。BAPレイヤにおける制御PDUは、ホップバイホップ制御情報を含み、例えば、フロー制御のために使用されるフィードバック情報を含むか、または、ワイヤレスバックホールリンクが異常であり親ノードによって子ノードに送信される通知を含み得る。ワイヤレスバックホールリンクの異常は、ワイヤレスバックホールリンクの無線リンク障害(radio link failure,略してRLF)、遮断(blockage)、もしくは輻輳(congestion)であることがあるか、またはワイヤレスバックホールリンクのものであり回復されることが可能でない接続などであることがある。BAPレイヤにおけるこの制御PDUは、IPパケットにカプセル化される必要はない。
前述の説明を参照すると、図4は、本出願の実施形態によるデータパケット送信方法の概略フローチャートである。図4を参照されたい。本方法は、以下のステップを含む。
ステップ401:IABドナーが、第1の設定情報を決定する。
第1の設定情報は、第1のBH RLCチャネルを示すために使用され、第1のBH RLCチャネルは、BAPレイヤにおいて制御PDUを送信するために使用される。
ステップ402:IABドナーが、第1の設定情報をIABノードに送信する。
本出願のこの実施形態では、IABドナーは、F1APメッセージまたはRRCメッセージなどの制御プレーンメッセージを使用することによって第1の設定情報を送信してよい。代替として、IABドナー(特定の実装ではIABドナーDUまたはIABドナーCUであり得る)は、IABノードのOAMから第1の設定情報を受信し、次いで、第1の設定情報をIABノードに送信し得る。
IABノードが親ノードを有する場合、IABドナーは、第1の設定情報をIABノードの親ノードに送信してもよいことに留意されたい。特定の処理が、第1の設定情報をIABノードに送信する処理と同じであってよい。詳細は、本明細書では再び説明されない。
例えば、IABドナーがCUおよびDUを含む場合、ステップ401および402は、IABドナーCUによって実行され得る。IABドナーがCUおよびDUを含む場合、IABドナーCUは、IABドナーDUのための第1の設定情報をさらに設定し得る。
例えば、IABドナーCUがCPおよびUPを含む場合、ステップ401および402は、IABドナーCU-CPによって実行され得る。
ステップ403:IABノードは、IABドナーから第1の設定情報を受信する。
ステップ404:IABノードは、第1の設定情報に基づいて、BAPレイヤにおいて制御PDUを送信するために使用される第1のBH RLCチャネルを決定する。
ステップ405:IABノードが、BAPレイヤにおいて制御PDUを、第1のBH RLCチャネルを介してIABノードの隣接ノードに送信する。
IABノードの隣接ノードは、例えば、IABノードの親ノード(親ノードは別のIABノードまたはIABドナー(CUとDUとが分離されたアーキテクチャ内にIABドナーがある特定の実装ではIABドナーDUであり得る)であり得る)、またはIABノードの子ノードであり得る。
ステップ401からステップ403ならびにステップ404およびステップ405は、2つの独立した手順であってよいことに留意されたい。ステップ401からステップ403は、ステップ404の前に実行されてよい。ステップ403を実行した後、IABノードは、BAPレイヤにおいて制御PDUを送信することを決定するとき、実際の状況に基づいてステップ404およびステップ405を実行してよい。
前述の手順によれば、IABドナーは、第1の設定情報を使用することによって、IABノードがBAPレイヤにおいて第1のBH RLCチャネルを介して制御PDUを送信することを示し、IABノードがBAPレイヤにおいて制御PDUを送信する必要があるとき、ベアラマッピングを実施する。
本出願のこの実施形態では、第1の設定情報の複数の実装が存在し得る。可能な実装では、第1の設定情報が、第1のBH RLCチャネルのチャネル識別子を含み得る。この場合、BAPレイヤにおいて制御PDUを送信するとき、IABノードは、第1のBH RLCチャネルのものであり第1の設定情報内にあるチャネル識別子に対応する第1のBH RLCチャネルを介して、BAPレイヤにおいて制御PDUを送信してよい。
別の可能な実装では、第1の設定情報は、論理チャネル識別子(logical channel identifier,LCID)を含んでよく、論理チャネル識別子によって示される論理チャネルは、第1のBH RLCチャネルに対応する。この場合、BAPレイヤにおいて制御PDUを送信するとき、IABノードは、第1の設定情報内の論理チャネル識別子を使用することによって第1のBH RLCチャネルを決定し、第1のBH RLCチャネルを介してBAPレイヤにおいて制御PDUを送信する。
例えば、IABドナー(特定の実装ではIABドナーDUであり得る)は、BAPレイヤにおける制御PDUをIABノードに送信してもよい。この場合、IABドナーDUは、第1の設定情報によって示される第1のBH RLCチャネルに基づいて、BAPレイヤにおいて制御PDUを送信してもよい。詳細に関しては、BAPレイヤにおいてIABノードによって制御PDUを送信する説明を参照されたい。詳細は、本明細書では再び説明されない。
本出願のこの実施形態では、別の可能な実装において、IABドナーは、第1の設定情報を送信しないことがある。この場合、第1のBH RLCチャネルは、事前に合意されることがあり、例えば、第1のBH RLCチャネルのチャネル識別子または第1の論理チャネル識別子が、プロトコルにおいて指定される。第1のBH RLCチャネルの指定されたチャネル識別子または指定された第1の論理チャネル識別子に対応する第1のBH RLCチャネルは、BAPレイヤにおいて制御PDUを送信するために使用される。この場合、IABノードは、事前に合意された第1のBH RLCチャネルのチャネル識別子または第1の論理チャネル識別子に基づいて第1のBH RLCチャネルを決定し、BAPレイヤにおいて第1のBH RLCチャネルを介して制御PDUを送信することがある。それに応じて、IABドナー(特定の実装ではIABドナーDUであり得る)は、事前に合意された第1のBH RLCチャネルのチャネル識別子または第1の論理チャネル識別子に基づいて第1のBH RLCチャネルを決定し、BAPレイヤにおいて第1のBH RLCチャネルを介して制御PDUを送信してもよい。
さらに別の可能な実装では、IABドナーは、第1の設定情報を送信しない。第1のノードがBAPレイヤにおける制御PDUを第2のノードに送信するとき、第1のノードは、BAPレイヤにおける制御PDUにおいて搬送される情報に基づいて、BAPレイヤにおける制御PDUを送信するために使用されるBH RLCチャネルを決定する。第1のノードおよび第2のノードは、1つのバックホールリンクを介して直接接続される。例えば、第1のノードは、IABノードであり、第2のノードは、第1のノードの親ノードであり、第1のノードによって生成されるBAPレイヤにおける制御PDUは、第1のBH RLCチャネルに対応するバッファステータス情報を搬送し、第1のBH RLCチャネルは、第1のノードと第2のノードとの間のリンクに対応するBH RLCチャネルである。この場合、第1のノードは、第1のBH RLCチャネルを介してBAPレイヤにおける制御PDUを第2のノードに送信する。別の例では、第1のノードは、IABノードであり、第2のノードは、第1のノードの親ノードであり、第1のノードによって生成されるBAPレイヤにおける制御PDUは、第1のBH RLCチャネルに対応するバッファステータス情報と、別のBH RLCチャネルに対応するバッファステータス情報とを搬送する。しかしながら、第1のBH RLCチャネルは、別のBH RLCチャネルよりも高い優先度を有し、第1のBH RLCチャネルおよび別のBH RLCチャネルは各々、第1のノードと第2のノードとの間のリンクに対応するBH RLCチャネルである。この場合、第1のノードは、第1のBH RLCチャネルを介してBAPレイヤにおける制御PDUを第2のノードに送信する。
以上は、BAPレイヤにおいて制御PDUをどのように送信するかについて説明している。以下では、別の非F1トラフィックデータペイロードをどのように送信するかについて説明する。
実施形態2
図5は、本出願の実施形態によるデータパケット送信方法の概略フローチャートである。図5を参照されたい。本方法は、以下のステップを含む。
ステップ501:IABドナーが、第2の設定情報を決定する。
第2の設定情報は、第2のBH RLCチャネルを示すために使用され、第2のBH RLCチャネルは、第1のタイプのデータペイロードを送信するために使用され、第1のタイプのデータペイロードは、F1ユーザプレーンF1-UデータペイロードおよびF1制御プレーンF1-Cデータペイロード以外のデータペイロードである。
ステップ502:IABドナーが、第2の設定情報をIABノードに送信する。
本出願のこの実施形態では、IABドナーは、F1APメッセージまたはRRCメッセージなどの制御プレーンメッセージを使用することによって第2の設定情報を送信してよい。代替として、IABドナーは、IABノードのOAMから第2の設定情報を受信し、次いで、第2の設定情報をIABノードに送信し得る。
任意選択で、IABノードが親ノードを有する場合、IABドナーは、第2の設定情報をIABノードの親ノードに送信してもよい。特定の処理が、第2の設定情報をIABノードに送信する処理と同じであってよい。詳細は、本明細書では再び説明されない。
例えば、IABドナーがCUおよびDUを含む場合、ステップ501および502は、IABドナーCUによって実行され得る。IABドナーがCUおよびDUを含む場合、IABドナーCUは、IABドナーDUのための第2の設定情報をさらに設定し得る。代替として、IABドナーDUは、OAMを使用することによって第2の設定情報を取得し得る。
例えば、IABドナーCUがCPおよびUPを含む場合、ステップ501および502は、IABドナーCU-CPによって実行され得る。
ステップ503:IABノードは、IABドナーから第2の設定情報を受信する。
ステップ504:IABノードが、第2の設定情報に基づいて第1のタイプのデータペイロードを送信する。
前述の手順によれば、IABドナーは、第2の設定情報を使用することによって、IABノードが、第2のBH RLCチャネルを介して、F1ユーザプレーンF1-UデータペイロードおよびF1制御プレーンF1-Cデータペイロード以外のデータペイロードを送信することを示し、非F1トラフィックデータペイロードに対するベアラマッピングを実行する。
本出願のこの実施形態では、第2の設定情報は、第2のBH RLCチャネルを識別するために使用される識別情報を含み、識別情報は、第2のBH RLCチャネルのチャネル識別子であるか、または、第2のBH RLCチャネルに対応する論理チャネル識別子であり得る。第2の設定情報は、以下の、
第1のタイプであって、データペイロードのタイプであり、第2のBH RLCチャネルに対応する第1のタイプと、
第1の差別化されたサービス情報であって、第1のタイプおよび/または第2のBH RLCチャネルに対応する第1の差別化されたサービス情報と、
第1のフローラベル(flow label)であって、第1のタイプおよび/または第2のBH RLCチャネルに対応する第1のフローラベルとのうちのいずれか1つまたは複数をさらに含み得る。
差別化されたサービス情報は、差別化されたサービスコードポイント(differentiated services code point,DSCP)、インターネットプロトコルバージョン4(Internet Protocol Version 4,IPv4)パケットヘッダにおけるサービスタイプ(type of service,ToS)、インターネットプロトコルバージョン6(Internet Protocol Version 6,IPv6)パケットヘッダにおけるトラフィッククラス(traffic class)フィールド、IPv6パケットヘッダにおけるトラフィッククラスフィールドの最初の6ビットなどであり得ることに留意されたい。フローラベルはまた、IPv6パケットヘッダにおいて搬送されるフローラベルフィールドを指す。
この実装では、第1のタイプのデータペイロードは、以下の、
IABノードのOAMトラフィックパケットと、
IPアドレスを要求するために使用されるパケット、例えば、DHCP発見(discover)パケットもしくはDHCPオファー(offer)パケットなどの動的ホスト設定プロトコル(Dynamic Host Configuration Protocol,DHCP)パケット、DHCPv6要請(Solicit)パケットもしくはDHCPv6アドバタイズ(Advertise)パケットなどのIPv6用の動的ホスト設定プロトコル(Dynamic Host Configuration Protocol for IPv6、DHCPv6)パケット、IPv6ベースのルータ要請(Router Solicitation)パケット、またはIPv6ベースのルータアドバタイズメント(Router Advertisement)パケットと、
IPsec送信チャネルを確立するために使用されるパケットと、
SCTPアソシエーション保守パケットとのうちのいずれか1つまたは複数を含む。SCTPアソシエーション保守パケットは、データ(data)チャンク(chunk)を含まないSCTPレイヤメッセージであり、データチャンクは、SCTPレイヤの上位レイヤプロトコルレイヤにおけるデータパケットを指す。例えば、SCTPアソシエーション保守パケットは、SCTPアソシエーションセットアップデータパケット、SCTPアソシエーションシャットダウンデータパケット、およびSCTPアソシエーションハートビートデータパケットなどのパケットを含むが、これらに限定されない。
この実装では、ダウンリンク方向において、IABドナーがIABノードに第1のデータペイロードを送信するとき、第1のデータペイロードは、第1のタイプのデータペイロードである。この場合、IABドナー(特定の実装では、IABドナーDU、IABドナーCU、IABドナーCU-CP、またはIABドナーCU-UPであり得る)は、第1のデータペイロードに対応するパケットヘッダ情報を使用して、第1の差別化されたサービス情報または第1のフローラベルを搬送することがある。パケットヘッダ情報は、IPパケットヘッダであってよい。
IABドナー(特定の実装ではIABドナーDUであり得る)は、第1の差別化されたサービス情報に対応する第2のBH RLCチャネルを介してIABノードに第1のデータパケットを送信するか、第1のフローラベルに対応する第2のBH RLCチャネルを介してIABノードに第1のデータパケットを送信するか、または第1のタイプに対応する第2のBH RLCチャネルを介してIABノードに第1のデータパケットを送信することがあり、第1のデータパケットは、第1のデータペイロードを含む。
例えば、前述の説明を参照すると、図6に示されるように、第1のデータパケットは、第1のデータペイロードおよびパケットヘッダ情報を含み、第1のデータパケットは、他の情報をさらに含み得る。詳細は、本明細書では説明されない。上述されるように、第1のデータペイロードは、OAMトラフィックパケット、IPアドレスを要求するために使用されるパケットなどであってよい。パケットヘッダ情報は、IPパケットヘッダであってよい。第1のデータペイロードを取得した後、IABドナーは、対応するパケットヘッダ情報を第1のデータペイロードに追加し、第1のデータパケットを取得する。
この実装では、アップリンク方向において、IABノードが第1のデータペイロードを送信するとき、第1のデータペイロードは、第1のタイプのデータペイロードである。この場合、IABノードは、第1のデータペイロードに対応するパケットヘッダ情報を使用して、第1の差別化されたサービス情報または第1のフローラベルを搬送することがある。IABノードは、第1の差別化されたサービス情報に対応する第2のBH RLCチャネルを介してIABノードのネクストホップノードに第1のデータパケットを送信するか、または第1のフローラベルに対応する第2のBH RLCチャネルを介してIABノードのネクストホップノードに第1のデータパケットを送信することがあり、第1のデータパケットは、第1のデータペイロードと、第1のデータペイロードに対応するパケットヘッダ情報とを含む。代替として、アップリンク方向において、IABノードが第1のデータペイロードを送信するとき、第1のデータペイロードは、第1のタイプのデータペイロードである。この場合、IABノードは、第1のタイプに対応する第2のBH RLCチャネルを介してIABノードのネクストホップノードに第1のデータパケットを送信してよく、第1のデータパケットは、第1のデータペイロードを含む。IABノードのネクストホップノードは、IABノードの親ノードであり、具体的には、IABドナー(例えば、IABドナーDU)または別のIABノードであってよい。
本出願のこの実施形態では、別の可能な実装において、IABドナーは、第2の設定情報を送信しないことがある。この場合、可能な実装では、第2のBH RLCチャネルは、事前に合意されることがあり、例えば、第2のBH RLCチャネルのチャネル識別子または第2の論理チャネル識別子が、プロトコルにおいて指定される。第2のBH RLCチャネルの指定されたチャネル識別子または指定された第2の論理チャネル識別子に対応する第2のBH RLCチャネルは、第1のタイプのデータペイロードを送信するために使用される。この場合、IABノードは、事前に合意された第2のBH RLCチャネルのチャネル識別子または第2の論理チャネル識別子に基づいて第2のBH RLCチャネルを決定し、データペイロードタイプが第1のタイプであるデータパケットを第2のBH RLCチャネルを介して送信することがある。それに応じて、IABドナー(例えば、特定の実装ではIABドナーDUであり得る)は、事前に合意された第2のBH RLCチャネルのチャネル識別子または第2の論理チャネル識別子に基づいて第2のBH RLCチャネルを決定し、データペイロードタイプが第1のタイプであるデータパケットを第2のBH RLCチャネルを介して送信してもよい。例えば、デフォルト(default)の第2のBH RLCチャネルのチャネル識別子は、プロトコルにおいて指定され、チャネル識別子によって指定されたBH RLCチャネルは、デフォルトのBH RLCチャネルであり、第1のタイプのデータペイロードを送信するために使用され得る。
別の可能な実装では、第2のBH RLCチャネルのチャネル識別子または第2の論理チャネル識別子に加えて、以下の、第1のタイプと、第1の差別化されたサービス情報と、第1のタイプと第1の差別化されたサービス情報との間の対応付けと、第1の差別化されたサービス情報と第2のBH RLCチャネルとの間の対応付けと、第1のフローラベルと、第1のタイプと第1のフローラベルとの間の対応付けと、第1のフローラベルと第2のBH RLCチャネルとの間の対応付けとのうちの1つまたは複数が、プリセットされ得る(例えば、プロトコルにおいて指定される)。
この実装では、アップリンク送信の場合、IABノードが第1のタイプのデータペイロードを送信することを決定するとき、IABノードは、第1のタイプのデータペイロードに対応するパケットヘッダ情報を使用して、プリセットされた第1の差別化されたサービス情報またはプリセットされた第1のフローラベルを搬送し、プリセットされた第1の差別化されたサービス情報またはプリセットされた第1のフローラベルに対応する第2のBH RLCチャネルを介して第1のタイプのデータペイロードを送信する。代替として、第1のタイプのデータペイロードを送信することを決定するとき、IABノードは、第1のタイプに対応する第2のBH RLCチャネルを介して第1のタイプのデータペイロードを送信する。ダウンリンク送信の場合、IABドナーが第1のタイプのデータペイロードを送信することを決定するとき、IABドナー(特定の実装では、IABドナーCU、IABドナーCU-UP、またはIABドナーCU-CPであり得る)は、第1のタイプのデータペイロードに対応するパケットヘッダ情報を使用して、プリセットされた第1の差別化されたサービス情報またはプリセットされた第1のフローラベルを搬送し、IABドナー(特定の実装ではIABドナーDUであり得る)は、プリセットされた第1の差別化されたサービス情報またはプリセットされた第1のフローラベルに対応する第2のBH RLCチャネルを介して第1のタイプのデータペイロードを送信する。代替として、第1のタイプのデータペイロードを送信することを決定するとき、IABドナーは、第1のタイプに対応する第2のBH RLCチャネルを介して第1のタイプのデータペイロードを送信する。
別の可能な実装では、IP5タプル情報と、IP5タプル情報と第1の差別化されたサービス情報との間の対応付けと、第1の差別化されたサービス情報と第2のBH RLCチャネルとの間の対応付けとが、プリセットされてよいか、または、IP5タプル情報と、IP5タプル情報と第1のフローラベルとの間の対応付けと、第1のフローラベルと第2のBH RLCチャネルとの間の対応付けとが、プリセットされてよい。IP5タプル情報は、以下の、発信元IPアドレスと、宛先IPアドレスと、発信元ポート番号と、宛先ポート番号と、トランスポートレイヤプロトコルタイプとのうちの少なくとも1つを含む。
この実装では、アップリンク送信の場合、送信されたデータペイロードに対応するIP5タプル情報がプリセットされたIP5タプル情報であると決定するとき、IABノードは、データペイロードに対応するパケットヘッダ情報を使用して、プリセットされた第1の差別化されたサービス情報またはプリセットされた第1のフローラベルを搬送し、プリセットされた第1の差別化されたサービス情報またはプリセットされた第1のフローラベルに対応する第2のBH RLCチャネルを介してデータペイロードを送信する。ダウンリンク送信の場合、IABドナーはまた、同じ方法でデータペイロードを送信する。詳細は、本明細書では再び説明されない。
以上は、BAPレイヤにおける制御PDUおよびSCTPアソシエーションを確立するために使用されるパケットなどの非F1トラフィックデータペイロードをどのように送信するかについて説明している。以下では、F1トラフィックデータペイロードをどのように送信するかについてさらに説明する。実施形態3から実施形態6におけるデータペイロードは各々、別段に指定されなければ、F1ユーザプレーン(F1-U)データペイロードまたはF1制御プレーン(F1-C)データペイロードであることに留意されたい。
図1に示されるIABネットワークでは、IABノード1は、端末側デバイスにアクセスサービスを提供するIABノードであり、IABノード2は、中間IABノードである。IABノードは、中間IABノードとアクセスIABノード(access IAB node)の両方として使用され得ることに留意されたい。例えば、IABノード2は、IABノード1とIABドナーとの間の中間ノードとして使用されてよいが、IABノード1によってサービスされるセルにアクセスする端末側デバイスの場合、IABノード2は、アクセスIABノードとして使用される。
IABノード2とIABノード1との間のワイヤレスバックホールリンク、およびIABノード2とIABドナー(特定の実装ではIABドナーDUであり得る)との間のワイヤレスバックホールリンク上で、1つまたは複数のバックホールリンク(backhaul link,BH)RLCチャネルが、IABドナーの設定に基づいて確立される。バックホールリンクを介してデータパケットを送信するとき、IABノードまたはIABドナー(特定の実装ではIABドナーDUであり得る)は、ベアラマッピングを実行する必要がある。例えば、ベアラマッピングは、ダウンリンク上で送信されるデータパケットに対してIABドナーによって最初に実行される必要がある(特定の実装ではIABドナーDUによって実行され得る)。具体的には、適切なBH RLCチャネルが、データパケットを送信するために、IABノード2とIABドナーとの間のリンク上のBH RLCチャネルから選択される。IABノード1に送信される必要があるデータパケットをIABドナーから受信するとき、IABノード2はまた、データパケットを送信するために、IABノード1とIABノード2との間のリンク上のBH RLCチャネルから適切なBH RLCチャネルを選択する必要がある。
同様に、アップリンク上で送信されるデータパケットの場合、例えば、ベアラマッピングも、IABノード1によって送信されたアップリンクデータパケットに対してIABノード1によって実行される必要がある。具体的には、データパケットをIABノード2に送信するために、BH RLCチャネルが、IABノード1とIABノード2との間のリンク上のBH RLCチャネルから選択される。
従来の技術では、中間IABノードとして使用されるIABノード2がベアラマッピングを実行するとき、IABノード2は、データパケットを受信するために使用される入口BH RLCチャネルに依拠する。具体的には、データパケットの入口BH RLCチャネルに対応する出口BH RLCチャネルは、データパケットを送信するために使用される出口BH RLCチャネルとして使用され得る。しかしながら、この実装は、十分にフレキシブルでない。同じ入口BH RLCチャネルから受信されたデータパケットがネクストホップノードに送信されるとき、データパケットは、送信のために同じ出口BH RLCチャネルにマッピングされることしかできない。その結果、フレキシビリティが乏しく、差別化されたサービス品質(quality of service,QoS)保証が、異なるトラフィックのデータパケットに対して提供されることが可能でなく、データパケットのQoS要件が満たされることが可能でない。
本出願のこの実施形態では、ワイヤレスバックホールリンク上で送信されるデータパケットは、中間IABノードによって使用される追加情報を搬送し、ベアラマッピングを実行することが許可されてよく、その結果、中間IABノードは、ベアラマッピングをよりフレキシブルに実行することができる。追加情報はラベル(label)であってよく、ラベルは、データパケットのバックホール適応プロトコルBAPレイヤヘッダ情報において搬送されてよい。ラベルは、別の名称をさらに有してよいことに留意されたい。本出願のこの実施形態では、ラベルは、説明のための例として使用されるにすぎない。通信規格が変わるとき、対応する名称は、変えられた通信規格における対応する機能の名称と置き換えられてもよい。
以下では、IABドナー、中間IABノード、およびアクセスIABノードの観点からそれぞれ、ワイヤレスバックホールリンク上でベアラマッピングを実行するためにラベルをどのように追加および使用するかについて説明する。
実施形態3
図7は、本出願の実施形態によるデータパケット送信方法の概略フローチャートである。本方法は、以下のステップを含む。
ステップ700:IABドナーが、第3の設定情報を取得する。
第3の設定情報は、第1のラベルと、IABドナーによって取得された第3のデータペイロードに対応するパケットヘッダ情報内の第1の情報との間の対応付けを設定するために使用される。第1の情報は、次の、第1の差別化されたサービス情報と、第1のフローラベルと、第1のIPアドレスとのうちのいずれか1つまたは複数を含み得る。
例えば、本出願のこの実施形態では、第3の設定情報は、以下の、
(1)第1の差別化されたサービス情報および第1の差別化されたサービス情報に対応する第1のラベルであって、
本出願のこの実施形態では、差別化されたサービス情報は、DSCPであってよいか、または、第3のデータペイロードに対応するパケットヘッダ情報がIPv4パケットヘッダであるとき、差別化されたサービス情報は、IPv4パケットヘッダ内のサービスタイプ(type of service,ToS)であってよいか、または、第3のデータペイロードに対応するパケットヘッダ情報がIPv6パケットヘッダであるとき、差別化されたサービス情報は、IPv6パケットヘッダ内のクラスタイプフィールド、IPv6パケットヘッダ内のクラスタイプフィールドの最初の6ビットなどであってよい、第1の差別化されたサービス情報および第1の差別化されたサービス情報に対応する第1のラベルと、
(2)第1のフローラベル(flow label)および第1のフローラベルに対応する第1のラベルであって、
第3のデータペイロードに対応するパケットヘッダ情報がIPv6パケットヘッダであるとき、フローラベルはまた、IPv6パケットヘッダにおいて搬送される情報である、第1のフローラベルおよび第1のフローラベルに対応する第1のラベルと、
(3)第1の差別化されたサービス情報、第1のフローラベル、および対応する第1のラベルと、
(4)第1のIPアドレスおよび第1のIPアドレスに対応する第1のラベルと、
(5)第1のフローラベル、第1のIPアドレス、および対応する第1のラベルと、
(6)第1の差別化されたサービス情報、第1のIPアドレス、および対応する第1のラベルと、
(7)第1の差別化されたサービス情報、第1のフローラベル、第1のIPアドレス、および対応する第1のラベルとのうちのいずれか1つを含み得る。
第3の設定情報内の第1のIPアドレスは、データパケット内の宛先IPアドレスであり得ることに留意されたい。第3の設定情報内の(4)に関しては、第1のIPアドレスは、代替として、データパケットにおける発信元IPアドレスであってよい。
第3の設定情報に基づいて、第3のデータペイロードを取得した後、IABドナーは、第3のデータペイロードに対応するパケットヘッダ情報内の差別化されたサービス情報、フローラベル、およびIPアドレスのうちの1つまたは複数に基づいて第1のラベルを決定し、次いで、第1のラベルおよび第3のデータペイロードをネクストホップノードに送信することがある。詳細に関しては、ステップ701およびステップ702の説明を参照されたい。
任意選択で、本出願のこの実施形態は、以下のステップをさらに含む。
ステップ701:IABドナーは、第3のデータペイロードに対応するパケットヘッダ情報に基づいて第1のラベルを決定する。
具体的には、IABドナーは、第3のデータペイロードに対応するパケットヘッダ情報および第3の設定情報に基づいて第1のラベルを決定する。
第1のラベルは、第3のデータペイロードの出口RLCチャネルを決定するために使用される。
IABドナーは、第3のデータペイロードを含むダウンリンクデータパケットを受信することがあり、ダウンリンクデータパケットの構造は、図8に示され得ることに留意されたい。図8に示されるダウンリンクデータパケットは、第3のデータペイロードおよびパケットヘッダ情報を含み、パケットヘッダ情報は、IPパケットヘッダであってよい。
ステップ702:IABドナーは、第3のデータパケットをIABノードに送信する。
第3のデータパケットは、第3のデータペイロードおよび第1のBAPレイヤヘッダを含み、第1のBAPレイヤヘッダは、第1のラベルを含む。
IABノードが第3のデータパケットを受信した後、第1のラベルに基づいて第3のデータペイロードの出口RLCチャネルをどのように決定するかについての詳細に関しては、以下の説明が参照され得ることに留意されたい。
図8を参照すると、図8に示されるダウンリンクデータパケットを受信した後、IABドナーは、第1のBAPレイヤヘッダをダウンリンクデータパケットに追加して、第3のデータパケットを取得してよい。第3のデータパケットの構造は、図9に示され得る。第3のデータパケットは、第1のBAPレイヤヘッダ、第3のデータペイロードなどを含む。
例えば、IABドナーがCUおよびDUを含む場合、ステップ700からステップ702におけるIABドナーは、具体的には、IABドナーDUであってよく、すなわち、IABドナーDUは、第1のラベルを第3のデータパケット内の第1のBAPレイヤヘッダに追加してよい。それに応じて、IABドナーCU(特定の実装ではIABドナーCU-CPであり得る)は、第3の設定情報をIABドナーDUに送信する。
例えば、第3の設定情報は、IABドナーCUによってIABドナーDUに送信されるF1APメッセージに含まれてよい。
例えば、IABドナーが、CUとDUとが分離されている形態でない場合、IABドナーは、第3の設定情報を取得する必要はなく、IABドナーは、第3の設定情報を生成してよいか、または、OAMから第3の設定情報を取得してよい。
実施形態4
図10は、本出願の実施形態によるデータパケット送信方法の概略フローチャートである。本方法は、以下のステップを含む。
ステップ1000:第2のIABノードが、IABドナーから第4の設定情報を受信する。
第2のIABノードは、アクセスIABノードであり得る。
例えば、IABドナーがCUおよびDUを含む場合、IABドナーCUは、第2のIABノードに関する第4の設定情報を設定し得る。
例えば、IABドナーCUがCPおよびUPを含む場合、IABドナーCU-CPは、第2のIABノードに関する第4の設定情報を設定し得る。
可能な実装では、第4の設定情報は、第2のラベルと第2のIABノードによって取得された第4のデータペイロードに対応するパケットヘッダ情報内の第2の情報との間の対応付けを設定するために使用され、第2のラベルは、第4のデータペイロードの出口RLCチャネルを決定するために使用される。第2の情報は、以下の、
パケットヘッダ情報内の第2の差別化されたサービス情報と、パケットヘッダ情報内の第2のフローラベルと、パケットヘッダ情報内の第2のIPアドレスと、パケットヘッダ情報内にあり、第4のデータペイロードに対応するデータ無線ベアラ情報とのうちのいずれか1つまたは複数を含み得る。
例えば、第4の設定情報は、以下の、
(1)第2のフローラベルおよび第2のフローラベルに対応する第2のラベルと、
(2)第2のフローラベル、第2のIPアドレス、ならびに第2のフローラベルおよび第2のIPアドレスに対応する第2のラベルと、
(3)第2のIPアドレスおよび第2のIPアドレスに対応する第2のラベルと、
(4)第2の差別化されたサービス情報および第2の差別化されたサービス情報に対応する第2のラベルと、
(5)第2の差別化されたサービス情報、第2のIPアドレス、ならびに第2の差別化されたサービス情報および第2のIPアドレスに対応する第2のラベルと、
(6)第2の差別化されたサービス情報、第2のフローラベル、ならびに第2の差別化されたサービス情報および第2のフローラベルに対応する第2のラベルと、
(7)第2の差別化されたサービス情報、第2のフローラベル、第2のIPアドレス、および対応する第2のラベルとのうちのいずれか1つまたは複数を含み得る。
第4の設定情報内の第2のIPアドレスは、宛先IPアドレスであり得ることに留意されたい。第4の設定情報における差別化されたサービス情報およびフローラベルに関しては、第3の設定情報の説明を参照されたい。詳細は、本明細書では再び説明されない。
別の可能な実装では、第4の設定情報は、第4のデータペイロードと第2のラベルとの間の対応付けを設定するために使用される。例えば、第4の設定情報は、以下のもののうちのいずれか1つまたは複数を含み得る。
(8)第4のデータペイロードに対応するデータ無線ベアラ情報、およびデータ無線ベアラ情報に対応する第2のラベル。
この場合、第4のデータペイロードは、ユーザプレーンデータパケットである。
データ無線ベアラ情報は、以下のコンテンツ、すなわち、ユーザプレーンデータパケットで搬送される汎用パケット無線サービス(General Packet Radio Service,GPRS)トンネリングプロトコルユーザプレーン(GPRS Tunneling Protocol User Plane,GTP-U)トンネルエンドポイント識別子(Tunnel endpoint identifier,TEID)と、ユーザプレーンデータパケットにおいて搬送されるGTP TEIDおよびIPアドレスと、ユーザプレーンデータパケットのUE DRB識別子(UEの識別子およびDRB IDに基づいて共同で決定され得る)と、ユーザプレーンデータパケットの論理チャネル識別子とのうちのいずれか1つであり得る。GTP TEIDは、GTPユーザプレーンプロトコルレイヤのヘッダ情報において搬送されるトンネルエンドポイント識別子であり、トンネルエンドポイント識別子は、IABドナーまたはIABドナーCUによって割り振られたアップリンクトンネルエンドポイント識別子であってよく、1つのUEデータ無線ベアラ(data radio bearer,DRB)に対応する。
(9)第4のデータペイロードの第2のタイプ、および第2のタイプに対応する第2のラベル。
この場合、第4のデータペイロードは、F1制御プレーンパケット、すなわち、F1APメッセージである。第2のタイプは、F1APメッセージタイプのうちのいずれか1つまたは複数である。
可能な実装では、以下の2つのF1APメッセージタイプ、すなわち、UE関連(UE associated)F1APメッセージと、非UE関連(non-UE associated)F1APメッセージとが存在し得る。代替として、別の可能な実装では、以下の複数の特定のF1APメッセージタイプ、すなわち、F1セットアップ要求(setup request)、gNB-DU設定更新(configuration update)、UEコンテキストセットアップ応答(UE context setup response)などが存在し得る。具体的には、TS38.874のセクション9.2/8.1に記載されている複数のF1APメッセージにおいてIABドナーDUによってIABドナーCUに送信されるメッセージタイプが含まれ得る。代替として、別の可能な実装では、以下のF1APメッセージタイプ、すなわち、F1APメッセージに含まれるコンテンツ(例えば、UEのRRCメッセージ)に対応するUEシグナリング無線ベアラ(signaling radio bearer,SRB)タイプが存在し得る。
前述の説明は、例にすぎない。F1APメッセージタイプの別の場合が存在し得る。詳細は、本明細書では再び説明されない。
(10)第4のデータペイロードがF1APメッセージであるとき、F1APメッセージを搬送するSCTPレイヤにおけるストリーム識別子(stream ID)、およびストリーム識別子に対応する第2のラベル。
第4の設定情報に基づいて、第2のIABノードが第4のデータペイロードを含むアップリンクデータパケットを取得した後、第2のIABノードは、アップリンクデータパケット内の第2の情報、第4のデータペイロードに対応するデータ無線ベアラ情報、第4のデータペイロードに対応するF1APメッセージタイプ、または第4のデータペイロードを搬送するSCTPレイヤにおけるストリーム識別子に基づいて第2のラベルを決定し、次いで、第2のラベルが追加されたアップリンクデータパケットをネクストホップノードに送信する。詳細に関しては、ステップ1001からステップ1003の説明を参照されたい。
任意選択で、本出願のこの実施形態は、以下のステップをさらに含む。
ステップ1001:第2のIABノードは、第4のデータペイロードを取得する。具体的には、第2のIABノードは、第4のデータペイロードを生成するか、または、第2のIABノードによってサービスされる端末デバイスもしくは子ノードから第4のデータペイロードを受信してよい。
ステップ1002:第2のIABノードは、第2のラベルを決定する。
具体的には、第2のIABノードは、第4のデータペイロードに対応するパケットヘッダ情報、第4のデータペイロードに対応するデータ無線ベアラ情報、第4のデータペイロードに対応するF1APメッセージタイプ、または第4のデータペイロードを搬送するSCTPレイヤにおけるストリーム識別子に基づいて第2のラベルを決定し得る。
ステップ1003:第2のIABノードは、第4のデータパケットを親ノードに送信する。
第4のデータパケットは、第4のデータペイロードおよび第2のBAPレイヤヘッダを含み、第2のBAPレイヤヘッダは、第2のラベルを含む。
実施形態5
図11は、本出願の実施形態によるデータパケット送信方法の概略フローチャートである。本方法は、以下のステップを含む。
ステップ1100:第1のIABノードが、IABドナーから第5の設定情報を受信する。
第5の設定情報は、第3のラベルと第3のRLCチャネル識別子との間の対応付けを設定するために使用される。第3のラベルは、データパケットのBAPレイヤヘッダにおいて搬送され、データパケットの出口RLCチャネルを決定するために第1のIABノードによって使用される。第3のRLCチャネル識別子は、第1のIABノードがデータパケットを送信する出口BH RLCチャネル(すなわち、第3のBH RLCチャネル)を識別するために使用され、第3のBH RLCチャネルの識別子または第3のBH RLCチャネルに対応する論理チャネル識別子であり得る。
例えば、第5の設定情報は、以下のもののうちのいずれか1つまたは複数を含み得る。
(1)第3のラベルおよび対応する第3のRLCチャネル識別子。
(2)第3のラベル、出口リンク識別子、および対応する第3のRLCチャネル識別子。ここで、出口リンク識別子は、第1のIABノードがデータパケットを送信する出口リンクを示すために使用される。具体的には、アップリンク送信の場合、出口リンク識別子は、第1のIABノードの親ノードの識別子(例えば、第1のIABノードに関する、親ノードのBAPレイヤ識別子、親ノードのDU識別子、親ノードのIPアドレス、親ノードのセル識別子、または親ノードのセルグループ識別子)であり得る。ダウンリンク送信の場合、出口リンク識別子は、第1のIABノードの子ノードの識別子(例えば、第1のIABノードによって子ノードに割り振られたF1制御プレーン識別子DU F1AP UE ID、子ノードによってアクセスされた第1のIABノードのセル識別子+第1のIABノードによって子ノードに割り振られたセル無線ネットワーク一時識別子C-RNTI、子ノードのIPアドレス、または子ノードのBAPレイヤ識別子)であり得る。
(3)第3のラベル、第4のRLCチャネル識別子、および対応する第3のRLCチャネル識別子。ここで、第4のRLCチャネル識別子は、第1のIABノードがデータパケットを受信する入口BH RLCチャネル(すなわち、第4のBH RLCチャネル)を識別するために使用され、第4のBH RLCチャネルの識別子または第4のBH RLCチャネルに対応する論理チャネル識別子であり得る。
(4)第3のラベル、入口リンク識別子、第4のRLCチャネル識別子、出口リンク識別子、および対応する第3のRLCチャネル識別子。ここで、第4のRLCチャネル識別子に関しては、(3)の説明を参照し、出口リンク識別子に関しては、(2)の説明を参照されたい。詳細は、本明細書では再び説明されない。入口リンク識別子は、第1のIABノードがデータパケットを受信する入口リンクを示すために使用される。具体的には、アップリンク送信の場合、入口リンク識別子は、第1のIABノードの子ノードの識別子であり得る。子ノードの識別子の具体例に関しては、(2)の説明を参照されたい。ダウンリンク送信の場合、入口リンク識別子は、第1のIABノードの親ノードの識別子であり得る。親ノードの識別子の具体例に関しては、(2)の説明を参照されたい。詳細は、本明細書では再び説明されない。
(5)第3のラベルとQoS識別子との間の対応付け。任意選択で、QoS識別子と第3のRLCチャネル識別子との間の対応付けがさらに含まれる。この対応付けにおいて、第3のラベルは、出口RLCチャネルとの対応付けを直接有しておらず、中間マッピング処理が存在し、すなわち、第3のラベルとQoS識別子との間の対応付けが存在し、QoS識別子と出口RLCチャネルとの間の対応付けが存在する。第3のラベルとQoS識別子との間の対応付けと、QoS識別子と第3のRLCチャネル識別子との間の対応付けの両方が設定されてよく(例えば、第5の設定情報は、第3のラベルと、第3のラベルに対応するQoS識別子と、第3のRLCチャネル識別子とを含む)、または、第3のラベルとQoS識別子との間の対応付けと、QoS識別子と第3のRLCチャネル識別子との間の対応付けは、別個に設定されてよい(例えば、第5の設定情報は、第3のラベルとQoS識別子とを含み、第3のラベルとQoS識別子との間の対応付けを設定し、他の設定情報は、第3のRLCチャネル識別子とQoS識別子とを含み、QoS識別子と第3のRLCチャネル識別子との間の対応付けを設定する)。これは、本出願のこの実施形態において限定されない。
1つのQoS識別子が、1つまたは一群のQoSパラメータ(parameter)を表すために使用され得ることに留意されたい。QoS識別子は、具体的には、QoSクラス識別子(QoS Class Identifier,QCI)、5G QoSインジケータ(5G QoS Indicator,5QI)、QoSフロー識別子(QoS flow identifier,QFI)などであってよい。1つまたは一群のQoSパラメータは、例えば、レイテンシ、パケット損失率、および帯域幅などを含む)。
(6)第3のラベルとQoSパラメータとの間の対応付け、およびQoSパラメータと第3のRLCチャネル識別子との間の対応付け。第3のラベルとQoSパラメータとの間の対応付けと、QoSパラメータと第3のRLCチャネル識別子との間の対応付けの両方が設定されてよく(例えば、第5の設定情報は、第3のラベルと、第3のラベルに対応するQoSパラメータと、第3のRLCチャネル識別子とを含む)、または、第3のラベルとQoSパラメータとの間の対応付けと、QoSパラメータと第3のRLCチャネル識別子との間の対応付けは、別個に設定されてよい(例えば、第5の設定情報は、第3のラベルとQoSパラメータとを含み、第3のラベルとQoSパラメータとの間の対応付けを設定し、他の設定情報は、第3のRLCチャネル識別子とQoSパラメータとを含み、QoSパラメータと第3のRLCチャネル識別子との間の対応付けを設定する)。これは、本出願のこの実施形態において限定されない。
第3のラベルは、任意選択のフィールドとして使用され得ることに留意されたい。データパケットが第3のラベルを搬送しない場合、IABノードに関してIABドナーによって設定される設定情報は、入口RLCチャネルと出口RLCチャネルとの間の対応付け、すなわち、第4のRLCチャネル識別子と第3のRLCチャネル識別子との間の対応付けのみを含み得る。
例えば、IABドナーがCUおよびDUを含む場合、IABドナーCUは、第1のIABノードに関する第5の設定情報を設定し得る。
例えば、IABドナーCUがCPおよびUPを含む場合、IABドナーCU-CPは、第1のIABノードに関する第5の設定情報を設定し得る。
本実施形態では、第1のIABノードは、中間IABノードであり得る。ワイヤレスバックホールリンク上で中間IABノードによって受信されたデータパケット(データパケットはアップリンクデータパケットまたはダウンリンクデータパケットであり得る)は、ラベルを搬送した。したがって、中間IABノードは、データパケットにおいて搬送されたラベルに基づいてベアラマッピングを実行する必要があり、すなわち、データパケットの出口RLCチャネルを選択して、データパケットをネクストホップノードに送信する。本出願のこの実施形態では、中間IABノードは、第5の設定情報に基づいて、受信されたデータパケットに対してベアラマッピングを実行し得る。説明が以下に詳細に提供される。
任意選択で、本出願のこの実施形態は、以下のステップをさらに含む。
ステップ1101:第1のIABノードはデータパケットを取得する。
データパケットは、第2のIABノードからのデータパケットであるか、または、データパケットは、IABドナーからのデータパケットである。
データパケットのバックホール適応プロトコルBAPレイヤヘッダは、第3のラベルを含む。
ステップ1102:第1のIABノードは、第3のラベルに基づいて第3のRLCチャネル識別子を決定する。
例えば、第5の設定情報が、第3のラベル、入口リンク識別子、第4のRLCチャネル識別子、出口リンク識別子、および第3のRLCチャネル識別子を含むとき、第1のIABノードは、データパケットに対するルーティング選択を実行して出口リンク識別子を決定し、次いで、データパケット内の第3のラベルと、データパケットが受信される入口リンクと、データパケットが受信される入口リンク上の第4のRLCチャネルとに基づいて第3のRLCチャネル識別子を決定する。別の場合は説明されない。
ステップ1103:第1のIABノードが、第3のRLCチャネル識別子に対応する出口RLCチャネルを介してデータパケットを送信する。
前述の処理において、第1のIABノードは、第5の設定情報に基づいてデータパケットに対してベアラマッピングを実行する。この解決策は、第1のIABノードがベアラマッピングをよりフレキシブルに実行して、IABネットワークにおいてより細かいQoS保証を提供することを可能にし得る。
実施形態6
図12は、本出願の実施形態によるデータパケット送信方法の概略フローチャートである。本方法は、以下のステップを含む。
ステップ1200:第2のIABノードが、IABドナーから第6の設定情報を受信する。
第2のIABノードは、アクセスIABノードであり得る。
例えば、IABドナーがCUおよびDUを含む場合、IABドナーCUは、第2のIABノードに関する第6の設定情報を設定し得る。
例えば、IABドナーCUがCPおよびUPを含む場合、IABドナーCU-CPは、第2のIABノードに関する第6の設定情報を設定し得る。
第6の設定情報は、第2のIABノードによって送信される必要がある第6のデータペイロードに対応して追加されるパケットヘッダ情報を設定するために使用される。第6のデータペイロードは、第2のIABノードとIABドナー(具体的には、IABドナーCU、またはIABドナーCU-CPであってよい)との間のF1制御プレーン(F1-C)メッセージ、すなわちF1APメッセージであってよい。パケットヘッダ情報は、IPパケットヘッダ内のフィールドであり、具体的には、差別化されたサービス情報および/またはフローラベル(flow label)を含む。
可能な実装では、第6の設定情報は、具体的には、以下のコンテンツ、すなわち、
UE関連F1APメッセージ(UE associated F1AP message)のために指定された第1の差別化されたサービス情報および/または第1のフローラベルと、非UE関連F1APメッセージ(non-UE associated F1AP message)のために指定された第2の差別化されたサービス情報および/または第2のフローラベルとのうちのいずれか1つまたは複数を含む。
別の可能な実装では、第6の設定情報は、具体的には、以下のコンテンツ、すなわち、
第1の端末デバイスの識別子と、第1の端末デバイスのUE関連F1APメッセージのために指定された第1の差別化されたサービス情報および/または第1のフローラベルと、非UE関連F1APメッセージのために指定された第2の差別化されたサービス情報および/または第2のフローラベルとのうちのいずれか1つまたは複数を含む。
第6の設定情報に基づいて、第6のデータペイロードを含むアップリンクデータパケットを取得した後、第2のIABノードは、第6のデータペイロードに対応するF1APメッセージタイプに基づいて、差別化されたサービス情報および/またはIPパケットヘッダに追加されるべきフローラベルを決定し、次いで、差別化されたサービス情報および/またはフローラベルが追加されるアップリンクデータパケットをネクストホップノードに送信する。詳細に関しては、ステップ1201からステップ1203の説明を参照されたい。
任意選択で、本出願のこの実施形態は、以下のステップをさらに含む。
ステップ1201:第2のIABノードは、第6のデータペイロードを取得する。具体的には、第2のIABノードは、第6のデータペイロードを生成し得る。
ステップ1202:第2のIABノードは、第6のデータペイロードに対応する差別化されたサービス情報および/またはフローラベルを決定する。
第2のIABノードは、第6のデータペイロードに対応するF1APメッセージタイプ(例えば、非UE関連F1APメッセージまたはUE関連F1APメッセージ)に基づいて、第6のデータペイロードに対応する差別化されたサービス情報および/もしくはフローラベルを決定してよく、または、第6のデータペイロードがUE関連F1APメッセージであるとき、第2のIABノードは、第1の端末デバイスのものであり第6のデータペイロードに対応する識別子に基づいて、第6のデータペイロードに対応する差別化されたサービス情報および/もしくはフローラベルを決定してよい。具体的には、第6のデータペイロードが非UE関連F1APメッセージであるとき、第6のデータペイロードは、第2の差別化されたサービス情報および/もしくは第2のフローラベルに対応し、または、第6のデータペイロードがUE関連F1APメッセージであるとき、第6のデータペイロードは、第1の差別化されたサービス情報および/もしくは第1のフローラベルに対応する。代替として、第6のデータペイロードが第1の端末デバイスのUE関連F1APメッセージであるとき、第6のデータペイロードは、第1の差別化されたサービス情報および/または第1のフローラベルに対応する。
ステップ1203:第2のIABノードは、第6のデータパケットを親ノードに送信する。
第6のデータパケットは、第6のデータペイロードおよびIPパケットヘッダを含み、IPパケットヘッダは、第6のデータペイロードに対応しステップ1202において決定される、差別化されたサービス情報および/またはフローラベルを含む。任意選択で、第2のIABノードは、第6のデータパケットに含まれる差別化されたサービス情報および/またはフローラベルに基づいて、第6のデータパケットを送信するために使用される出口BH RLCチャネルを決定してよい。
前述の処理では、第2のIABノードは、第6の設定情報に基づいて異なるタイプのF1APメッセージに異なる差別化されたサービス情報および/またはフローラベル値を追加し、その結果、第2のIABノードは、差別化されたサービス情報および/またはフローラベル値に対応するBH RLCチャネルに基づいて、F1APメッセージを送信するために使用されるBH RLCチャネルを決定し、異なるタイプのF1-Cメッセージに関する差別化されたQoS保証を提供することができる。
実施形態7
既存のデュアルコネクティビティ(Dual Connectivity)のシナリオでは、UEは、マスタノード(Master Node,MN)とセカンダリノード(Secondary Node,SN)の両方に接続される。MNおよびSNは、同じアクセス規格を使用してよく(例えば、MNとSNの両方がLTE規格またはNR規格を使用する)、または、異なるアクセス規格を使用してよい(例えば、MNがLTE規格を使用し、SNがNR規格を使用する、または、MNがNR規格を使用し、SNがLTE規格を使用する)。マスターセルグループ(Master Cell Group,MCG)は、MNに関連付けられたサービングセルを含み、少なくとも1つのプライマリセルPCellを含み、任意選択で1つまたは複数のセカンダリセルSCellを含む。同様に、セカンダリセルグループ(Secondary Cell Group,SCG)は、SNに関連付けられたサービングセルを含み、少なくとも1つのプライマリセル(例えば、プライマリセカンダリセル(PSCell))を含み、任意選択で、1つまたは複数のセカンダリセルSCellを含む。MCGリンクは、UEとMNとの間のシングルホップアクセスリンクであり、SCGリンクは、UEとSNとの間のシングルホップアクセスリンクである。
UEが、UEとMNとの間のMCGリンク上で無線リンク障害(Radio Link Failure,RLF)が発生したことを発見するとき、UEは、RRC接続再確立処理をトリガしてMCGリンクを回復する。UEが、UEとSNとの間のSCGリンク上でRLFが発生したことを発見するとき、UEは、RRC接続再確立処理をトリガしないが、MCGを使用することによってSCG障害報告(SCG failure report)をMNに送信し、その結果、MNは、SCGリンクを回復するために、SCG障害回復処理をトリガし、例えば、SCG変更処理をトリガする。3GPPリリース16では、既存のDCが強化され、MCG高速回復メカニズムが導入される。具体的には、UEが、UEとMNとの間のMCGリンク上でRLFが発生したことを発見するとき、UEは、SCG障害メカニズムと同様のメカニズムを使用し、RRC接続再確立処理をトリガしなくなるが、SCGを使用することによってMCG障害報告(MCG failure report)を送信する。
IABのシナリオでは、IABノード(IAB node)は、EN-DC(E-UTRAN NR Dual Connectivity)に基づいて、スタンドアロン(standalone,SA)モードまたは非スタンドアロン(non-standalone,NSA)モードにおいて動作することができる。
本実施形態では、IABノードがNSAモードにおいて動作することが主に考慮される。図13に示されるように、IABノードにサービスを提供するMNはeNBであり、IABノードにサービスを提供するSNはIABドナー(IAB donor)である。MNはLTE規格を使用し、SNはNR規格を使用する。同様に、MCGリンクは、IABノード(すなわち、IABノードMT)とMNとの間のリンクであり、SCGリンクは、IABノード(すなわち、IABノードMT)とSNとの間のリンクである。
IABノードとIABドナーとの間のSCGリンク上でRLFが発生したことをIABノードが検出するとき、IABノードは、MCGリンクを介して、IABノードにサービスを提供するeNBにSCG障害報告を送信し、その結果、eNBは、SCG障害回復処理をトリガしてSCGリンクを回復する。
SCGリンクが回復されることに失敗するか、または回復されることが可能でない(例えば、SCGの変更が失敗するか、またはSCGの解放が実行される)とき、IABノードは、1つのRLF表示情報をIABノードの子ノードに送信する必要があり、その結果、IABノードの子ノードは、対応する処理を実行する。可能な実装では、IABノードの子ノードが、IABノードによって送信されたRLF表示情報を受信するとき、IABノードの子ノードは、MCGを使用することによって、子ノードにサービスを提供するeNBにSCG障害報告を送信する。IABノードの子ノードは、UEまたは別のIABノードであってよい。IABノードにサービスを提供するeNBは、IABノードの子ノードにサービスを提供するeNBと同じであっても異なっていてもよい。これは、本実施形態において限定されない。
本実施形態は、IABマルチホップのシナリオにも適用可能であることに留意されたい。具体的には、IABノードとドナーノードとの間のリンク上に別のIABノードが存在することがあり、すなわち、IABノードが別のIABノードを使用することによってドナーノードに接続されるシナリオである。詳細は、本明細書では説明されない。
本明細書において説明される実施形態は、独立した解決策であってよく、または、内部論理に基づいて組み合わされてよい。これらの解決策はすべて、本出願の保護範囲内に入る。
前述の方法の実施形態において、端末デバイスによって実施される方法および動作は、代替として、端末デバイスにおいて使用され得る構成要素(例えば、チップまたは回路)によって実施されてよく、ネットワークデバイスによって実施される方法および動作は、代替として、ネットワークデバイスにおいて使用され得る構成要素(例えば、チップまたは回路)によって実施されてよいことが理解され得る。
以上は、ネットワーク要素間の相互作用の観点から、本出願において提供される解決策を主に説明する。前述の機能を実装するために、各ネットワーク要素は、各機能を実装するための対応するハードウェア構造および/またはソフトウェアモジュールを含むことが理解され得る。当業者は、本明細書に開示される実施形態を参照して説明される例におけるユニット、アルゴリズム、およびステップが、本発明において、ハードウェアまたはハードウェアとコンピュータソフトウェアとの組合せによって実装されることが可能であることを容易に認識するであろう。機能が、ハードウェアによって実行されるか、またはコンピュータソフトウェアによって駆動されるハードウェアによって実行されるかは、技術的な解決策の特定の用途および設計制約に依存する。当業者は、異なる方法を使用して各特定の用途に関して説明された機能を実装してよいが、実装が本発明の範囲を超えると見なされるべきでない。
図14は、本出願による通信装置の可能な例示的なブロック図である。装置1400は、ソフトウェアまたはハードウェアの形態で存在し得る。装置1400は、処理ユニット1401および通信ユニット1402を含み得る。実装では、通信ユニット1402は、受信ユニットおよび送信ユニットを含み得る。処理ユニット1401は、装置1400の動作を制御および管理するように構成される。通信ユニット1402は、別のネットワークエンティティと通信する際に装置1400をサポートするように構成される。
装置1400が、図4に示される方法の実施形態においてIABドナーの機能を実装するように構成されるとき、以下の動作が実行される。
処理ユニットは、第1の設定情報を決定するように構成され、第1の設定情報は、第1のバックホールリンクBH無線リンク制御RLCチャネルを示すために使用され、第1のBH RLCチャネルは、バックホール適応プロトコルBAPレイヤにおいて制御プロトコルデータユニットPDUを送信するために使用される。
通信ユニットは、第1の設定情報をIABノードに送信するように構成される。
可能な実装では、第1の設定情報が、第1のBH RLCチャネルのチャネル識別子を含むか、または、
第1の設定情報が、論理チャネル識別子を含み、論理チャネル識別子によって示される論理チャネルは、第1のBH RLCチャネルに対応する。
装置1400が、図4に示される方法の実施形態においてIABノードの機能を実装するように構成されるとき、以下の動作が実行される。
処理ユニットは、BAPレイヤにおいて制御プロトコルデータユニットPDUを送信するために使用される第1のバックホールリンクBH無線リンク制御RLCチャネルを決定するように構成される。
通信ユニットは、BAPレイヤにおける制御PDUを、第1のBH RLCチャネルを介してIABノードの隣接ノードに送信するように構成される。
可能な実装では、処理ユニットは、具体的には、
IABドナーから第1の設定情報を取得し、ここで、第1の設定情報は、BAPレイヤにおいて制御PDUを送信するために使用される第1のBH RLCチャネルを示すために使用され、
第1の設定情報に基づいて第1のBH RLCチャネルを決定するように構成される。
可能な実装では、第1の設定情報が、第1のBH RLCチャネルのチャネル識別子を含むか、または、
第1の設定情報が、論理チャネル識別子を含み、論理チャネル識別子によって示される論理チャネルは、第1のBH RLCチャネルに対応する。
装置1400が、図5に示される方法の実施形態においてIABドナーの機能を実装するように構成されるとき、以下の動作が実行される。
処理ユニットが、第2の設定情報を決定するように構成され、第2の設定情報は、第2のバックホールリンクBH無線リンク制御RLCチャネルを示すために使用され、第2のBH RLCチャネルは、第1のタイプのデータペイロードを送信するために使用され、第1のタイプのデータペイロードは、F1ユーザプレーンF1-UデータペイロードおよびF1制御プレーンF1-Cデータペイロード以外のデータペイロードである。
通信ユニットは、第2の設定情報をIABノードに送信するように構成される。
可能な実装では、第1のタイプのデータペイロードは、以下の、
運用、管理、および保守OAMトラフィックパケットと、
インターネットプロトコルIPアドレスを要求するために使用されるパケットと、
インターネットプロトコルセキュリティIPsec送信チャネルを確立するために使用されるパケットと、
ストリーム制御トランスポートプロトコルSCTPアソシエーションセットアップパケットと、
SCTPアソシエーションシャットダウンパケットと、
SCTPアソシエーションハートビートパケットとのうちのいずれか1つを含む。
可能な実装では、第2の設定情報は、以下の、
第1のタイプであって、データペイロードのタイプであり、第2のBH RLCチャネルに対応する第1のタイプと、
第1の差別化されたサービス情報であって、第1のタイプおよび/または第2のBH RLCチャネルに対応する第1の差別化されたサービス情報と、
第1のフローラベルであって、第1のタイプおよび/または第2のBH RLCチャネルに対応する第1のフローラベルとのうちのいずれか1つまたは複数を含む。
可能な実装では、処理ユニットは、
第1のデータペイロードを生成するようにさらに構成され、第1のデータペイロードは、第1のタイプのデータペイロードであり、
第1のデータペイロードに対応するパケットヘッダ情報が第1の差別化されたサービス情報を搬送する場合、通信ユニットは、第1の差別化されたサービス情報に対応する第2のBH RLCチャネルを介してIABノードに第1のデータパケットを送信するようにさらに構成され、または、第1のデータペイロードに対応するパケットヘッダ情報が第1のフローラベルを搬送する場合、通信ユニットは、第1のフローラベルに対応する第2のBH RLCチャネルを介してIABノードに第1のデータパケットを送信するようにさらに構成され、第1のデータパケットは、第1のデータペイロードを含む。
可能な実装では、第2の設定情報は、第2のBH RLCチャネルを識別するために使用される識別情報を含み、識別情報は、第2のBH RLCチャネルのチャネル識別子であるか、または、識別情報は、第2のBH RLCチャネルに対応する論理チャネル識別子である。
装置1400が、図5に示される方法の実施形態においてIABノードの機能を実装するように構成されるとき、以下の動作が実行される。
通信ユニットが、IABドナーから第2の設定情報を受信するように構成され、第2の設定情報は、第2のバックホールリンクBH無線リンク制御RLCチャネルを示すために使用され、第2のBH RLCチャネルは、第1のタイプのデータペイロードを送信するために使用され、第1のタイプのデータペイロードは、F1ユーザプレーンF1-UデータペイロードおよびF1制御プレーンF1-Cデータペイロード以外のデータペイロードである。
処理ユニットは、第2の設定情報に基づいて第1のタイプのデータペイロードを送信するように構成される。
可能な実装では、第1のタイプのデータペイロードは、以下の、
運用、管理、および保守OAMトラフィックパケットと、
インターネットプロトコルIPアドレスを要求するために使用されるパケットと、
インターネットプロトコルセキュリティIPsec送信チャネルを確立するために使用されるパケットと、
ストリーム制御トランスポートプロトコルSCTPアソシエーションセットアップパケットと、
SCTPアソシエーションシャットダウンパケットと、
SCTPアソシエーションハートビートパケットとのうちのいずれか1つを含む。
可能な実装では、第2の設定情報は、以下の、
第1のタイプであって、データペイロードのタイプであり、第2のBH RLCチャネルに対応する第1のタイプと、
第1の差別化されたサービス情報であって、第1のタイプおよび/または第2のBH RLCチャネルに対応する第1の差別化されたサービス情報と、
第1のフローラベルであって、第1のタイプおよび/または第2のBH RLCチャネルに対応する第1のフローラベルとのうちのいずれか1つまたは複数を含む。
可能な実装では、第2の設定情報は、第2のBH RLCチャネルを識別するために使用される識別情報を含み、識別情報は、第2のBH RLCチャネルのチャネル識別子であるか、または、識別情報は、第2のBH RLCチャネルに対応する論理チャネル識別子である。
装置1400は、図7に示される方法の実施形態においてIABドナーの機能をさらに実装してよく、装置1400は、図10に示される方法の実施形態において第2のIABノードの機能をさらに実装してよく、装置1400は、図11に示される方法の実施形態において第1のIABノードの機能をさらに実装してよく、装置1400は、図12に示される方法の実施形態において第2のIABノードの機能をさらに実装してよい。詳細については、前述の説明を参照されたい。詳細は、本明細書では再び説明されない。
図15は、本出願の実施形態による装置1500を示す。図15に示される装置は、図14に示される装置のハードウェア回路の実装であってよい。通信装置は、上記に示されたフローチャートにおいて使用されてよく、前述の方法の実施形態においてIABノードまたはIABドナーの機能を実行する。説明を容易にするために、図15は、通信装置の主要な構成要素のみを示す。
図15に示される装置1500は、少なくとも1つのプロセッサ1501を含む。例えば、プロセッサ1501は、汎用中央処理ユニット(central processing unit,CPU)、汎用プロセッサ、デジタル信号プロセッサ(digital signal processor,DSP)、特定用途向け集積回路(application-specific integrated circuit,ASIC)、フィールドプログラマブルゲートアレイ(field programmable gate array,FPGA)もしくは別のプログラマブル論理デバイス、トランジスタ論理デバイス、ハードウェア構成要素、またはそれらの任意の組合せであってよい。プロセッサは、本出願において開示される内容を参照して説明される様々な例示的な論理ブロック、モジュール、および回路を実装または実行することがある。代替として、プロセッサは、計算機能を実施するプロセッサの組合せ、例えば、1つもしくは複数のマイクロプロセッサの組合せ、またはDSPとマイクロプロセッサとの組合せであってよい。
装置1500は、プログラム命令および/またはデータを記憶するように構成された少なくとも1つのメモリ1502をさらに含んでよい。メモリ1502は、プロセッサ1501に結合される。本出願のこの実施形態における結合は、装置、ユニット、またはモジュールの間の情報交換のための装置、ユニット、またはモジュールの間の間接結合または通信接続であり、電気的、機械的、または他の形態であってよい。プロセッサ1501は、メモリ1502と協働して動作し得る。プロセッサ1501は、メモリ1502に記憶されたプログラム命令を実行し得る。少なくとも1つのメモリのうちの少なくとも1つは、プロセッサに含まれ得る。
装置1500は、送信媒体を介して別のデバイスと通信するように構成された通信インターフェース1503をさらに含んでよく、その結果、装置1500内の装置は、別のデバイスと通信することができる。本出願のこの実施形態では、通信インターフェースは、トランシーバ、回路、バス、モジュール、または別のタイプの通信インターフェースであってよい。本出願のこの実施形態では、トランシーバは、独立した受信機、独立した送信機、トランシーバ機能と統合されたトランシーバ、またはインターフェース回路であってよい。
装置1500は、通信線1504をさらに含んでよい。通信インターフェース1503、プロセッサ1501、およびメモリ1502は、通信線1504を介して互いに接続されてよい。通信線1504は、周辺部品相互接続(peripheral component interconnect,略してPCI)バス、拡張型業界標準アーキテクチャ(extended industry standard architecture,略してEISA)バスなどであってよい。通信線1504は、アドレスバス、データバス、制御バスなどに分類され得る。表現を容易にするために、図15では、通信線を表すために1つの太線のみが使用されているが、これは、1つのバスのみまたは1つのタイプのバスのみが存在することを意味するものではない。
装置1500は、図4に示される方法の実施形態においてIABノードまたはIABドナーの機能を実装してよく、装置1500は、図5に示される方法の実施形態においてIABノードまたはIABドナーの機能をさらに実装してよく、装置1500は、図7に示される方法の実施形態においてIABドナーの機能をさらに実装してよく、装置1500は、図10に示される方法の実施形態において第2のIABノードの機能をさらに実装してよく、装置1500は、図11に示される方法の実施形態において第1のIABノードの機能をさらに実装してよく、装置1500は、図12に示される方法の実施形態において第2のIABノードの機能をさらに実装してよい。詳細については、前述の説明を参照されたい。詳細は、本明細書では再び説明されない。
当業者は、本出願の実施形態が、方法、システム、またはコンピュータプログラム製品として提供され得ることを理解するであろう。したがって、本出願は、ハードウェアのみの実施形態、ソフトウェアのみの実施形態、またはソフトウェアとハードウェアとの組合せを有する実施形態の形態を使用し得る。さらに、本出願は、コンピュータ使用可能なプログラムコードを含む1つまたは複数のコンピュータ使用可能な記憶媒体(限定はされないが、ディスクメモリ、光メモリなどを含む)上に実装されるコンピュータプログラム製品の形態を使用し得る。
本出願は、本出願による方法、デバイス(システム)、およびコンピュータプログラム製品のフローチャートおよび/またはブロック図を参照して説明される。コンピュータプログラム命令が、フローチャートおよび/またはブロック図における各手順および/または各ブロック、ならびにフローチャートおよび/またはブロック図における手順および/またはブロックの組合せを実施するために使用され得ることを理解されたい。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組込みプロセッサ、または別のプログラマブルデータ処理デバイスのプロセッサに提供されてマシンを生成してよく、その結果、コンピュータまたは別のプログラマブルデータ処理デバイスのプロセッサによって実行される命令は、フローチャート内の1つもしくは複数の手順および/またはブロック図内の1つもしくは複数のブロックにおける特定の機能を実装するための装置を生成する。
これらのコンピュータプログラム命令は、代替として、コンピュータまたは別のプログラマブルデータ処理デバイスが特定の方法で動作することを示すことができるコンピュータ可読メモリに記憶されてよく、その結果、コンピュータ可読メモリに記憶された命令は、命令装置を含むアーティファクトを生成する。命令装置は、フローチャート内の1つもしくは複数の手順および/またはブロック図内の1つもしくは複数のブロックにおける特定の機能を実施する。
当業者が、本出願の範囲から逸脱することなく、本出願に対して様々な修正および変形を行うことができることは明らかである。本出願は、本出願のこれらの修正および変形を、それらが本出願の特許請求の範囲およびその均等な技術によって定義される保護の範囲内に入るという条件で網羅することが意図される。
本出願の実装は、データパケット送信方法および装置を提供し、バックホールリンク上でデータペイロードに対するベアマッピングをどのように実行するかという対応する問題を解決する。
1つのQoS識別子が、1つまたは一群のQoSパラメータ(parameter)を表すために使用され得ることに留意されたい。QoS識別子は、具体的には、QoSクラス識別子(QoS Class Identifier,QCI)、5G QoSインジケータ(5G QoS Indicator,5QI)、QoSフロー識別子(QoS flow identifier,QFI)などであってよい。1つまたは一群のQoSパラメータは、例えば、レイテンシ、パケット損失率、および帯域幅などを含む。

Claims (31)

  1. データパケット送信方法であって、
    統合されたアクセスおよびバックホールIABドナーによって第1の設定情報を決定するステップであって、前記第1の設定情報は、第1のバックホールリンクBH無線リンク制御RLCチャネルを示すために使用され、前記第1のBH RLCチャネルは、バックホール適応プロトコルBAPレイヤにおいて制御プロトコルデータユニットPDUを送信するために使用される、ステップと、
    前記IABドナーによって、前記第1の設定情報をIABノードに送信するステップと
    を備える、方法。
  2. 前記第1の設定情報が、前記第1のBH RLCチャネルのチャネル識別子を備えるか、または、
    前記第1の設定情報が、論理チャネル識別子を備え、前記論理チャネル識別子によって示される論理チャネルは、前記第1のBH RLCチャネルに対応する、請求項1に記載の方法。
  3. データパケット送信方法であって、
    統合されたアクセスおよびバックホールIABノードによって、BAPレイヤにおいて制御プロトコルデータユニットPDUを送信するために使用される第1のバックホールリンクBH無線リンク制御RLCチャネルを決定するステップと、
    前記IABノードによって、前記BAPレイヤにおいて前記制御PDUを、前記第1のBH RLCチャネルを介して前記IABノードの隣接ノードに送信するステップと
    を備える、方法。
  4. IABノードによって、BAPレイヤにおいて制御プロトコルデータユニットPDUを送信するために使用される第1のバックホールリンクBH無線リンク制御RLCチャネルを決定する前記ステップは、
    前記IABノードによって、IABドナーから第1の設定情報を取得するステップであって、前記第1の設定情報は、前記BAPレイヤにおいて前記制御PDUを送信するために使用される前記第1のBH RLCチャネルを示すために使用される、ステップと、
    前記IABノードによって、前記第1の設定情報に基づいて前記第1のBH RLCチャネルを決定するステップと
    を備える、請求項3に記載の方法。
  5. 前記第1の設定情報が、前記第1のBH RLCチャネルのチャネル識別子を備えるか、または、
    前記第1の設定情報が、論理チャネル識別子を備え、前記論理チャネル識別子によって示される論理チャネルは、前記第1のBH RLCチャネルに対応する、請求項4に記載の方法。
  6. データパケットのベアラマッピング方法であって、
    統合されたアクセスおよびバックホールIABドナーによって、第2の設定情報を決定するステップであって、前記第2の設定情報は、第2のバックホールリンクBH無線リンク制御RLCチャネルを示すために使用され、前記第2のBH RLCチャネルは、第1のタイプのデータペイロードを送信するために使用され、前記第1のタイプのデータペイロードは、F1ユーザプレーンF1-UデータペイロードおよびF1制御プレーンF1-Cデータペイロード以外のデータペイロードである、ステップと、
    前記IABドナーによって、前記第2の設定情報をIABノードに送信するステップと
    を備える、方法。
  7. 前記第1のタイプのデータペイロードは、以下の、
    運用、管理、および保守OAMトラフィックパケットと、
    インターネットプロトコルIPアドレスを要求するために使用されるパケットと、
    インターネットプロトコルセキュリティIPsec送信チャネルを確立するために使用されるパケットと、
    ストリーム制御トランスポートプロトコルSCTPアソシエーションセットアップパケットと、
    SCTPアソシエーションシャットダウンパケットと、
    SCTPアソシエーションハートビートパケットとのうちのいずれか1つを備える、請求項6に記載の方法。
  8. 前記第2の設定情報は、以下の、
    第1のタイプであって、データペイロードのタイプであり、前記第2のBH RLCチャネルに対応する第1のタイプと、
    第1の差別化されたサービス情報であって、前記第1のタイプおよび/または前記第2のBH RLCチャネルに対応する第1の差別化されたサービス情報と、
    第1のフローラベルであって、前記第1のタイプおよび/または前記第2のBH RLCチャネルに対応する第1のフローラベルとのうちのいずれか1つまたは複数を備える、請求項7に記載の方法。
  9. 前記方法は、
    前記IABドナーによって第1のデータペイロードを生成するステップであって、前記第1のデータペイロードは、前記第1のタイプのデータペイロードである、ステップと、
    前記第1のデータペイロードに対応するパケットヘッダ情報が前記第1の差別化されたサービス情報を搬送する場合、前記IABドナーによって、前記第1の差別化されたサービス情報に対応する前記第2のBH RLCチャネルを介して前記IABノードに第1のデータパケットを送信するか、または、前記第1のデータペイロードに対応するパケットヘッダ情報が前記第1のフローラベルを搬送する場合、前記IABドナーによって、前記第1のフローラベルに対応する前記第2のBH RLCチャネルを介して前記IABノードに第1のデータパケットを送信するステップであって、前記第1のデータパケットは、前記第1のデータペイロードを備える、ステップと
    をさらに備える、請求項8に記載の方法。
  10. 前記第2の設定情報は、前記第2のBH RLCチャネルを識別するために使用される識別情報を備え、前記識別情報は、前記第2のBH RLCチャネルのチャネル識別子であるか、または、前記識別情報は、前記第2のBH RLCチャネルに対応する論理チャネル識別子である、請求項9に記載の方法。
  11. データパケットのベアラマッピング方法であって、
    統合されたアクセスおよびバックホールIABノードによって、IABドナーから第2の設定情報を受信するステップであって、前記第2の設定情報は、第2のバックホールリンクBH無線リンク制御RLCチャネルを示すために使用され、前記第2のBH RLCチャネルは、第1のタイプのデータペイロードを送信するために使用され、前記第1のタイプのデータペイロードは、F1ユーザプレーンF1-UデータペイロードおよびF1制御プレーンF1-Cデータペイロード以外のデータペイロードである、ステップと、
    前記IABノードによって、前記第2の設定情報に基づいて前記第1のタイプのデータペイロードを送信するステップと
    を備えるベアラマッピング方法。
  12. 前記第1のタイプのデータペイロードは、以下の、
    運用、管理、および保守OAMトラフィックパケットと、
    インターネットプロトコルIPアドレスを要求するために使用されるパケットと、
    インターネットプロトコルセキュリティIPsec送信チャネルを確立するために使用されるパケットと、
    ストリーム制御トランスポートプロトコルSCTPアソシエーションセットアップパケットと、
    SCTPアソシエーションシャットダウンパケットと、
    SCTPアソシエーションハートビートパケットとのうちのいずれか1つを備える、請求項11に記載の方法。
  13. 前記第2の設定情報は、以下の、
    第1のタイプであって、データペイロードのタイプであり、前記第2のBH RLCチャネルに対応する第1のタイプと、
    第1の差別化されたサービス情報であって、前記第1のタイプおよび/または前記第2のBH RLCチャネルに対応する第1の差別化されたサービス情報と、
    第1のフローラベルであって、前記第1のタイプおよび/または前記第2のBH RLCチャネルに対応する第1のフローラベルとのうちのいずれか1つまたは複数を備える、請求項12に記載の方法。
  14. 前記第2の設定情報は、前記第2のBH RLCチャネルを識別するために使用される識別情報を備え、前記識別情報は、前記第2のBH RLCチャネルのチャネル識別子であるか、または、前記識別情報は、前記第2のBH RLCチャネルに対応する論理チャネル識別子である、請求項11に記載の方法。
  15. 通信装置であって、
    第1の設定情報を決定するように構成された処理ユニットであって、前記第1の設定情報は、第1のバックホールリンクBH無線リンク制御RLCチャネルを示すために使用され、前記第1のBH RLCチャネルは、バックホール適応プロトコルBAPレイヤにおいて制御プロトコルデータユニットPDUを送信するために使用される、処理ユニットと、
    前記第1の設定情報をIABノードに送信するように構成された通信ユニットと、を備える通信装置。
  16. 前記第1の設定情報が、前記第1のBH RLCチャネルのチャネル識別子を備えるか、または、
    前記第1の設定情報が、論理チャネル識別子を備え、前記論理チャネル識別子によって示される論理チャネルは、前記第1のBH RLCチャネルに対応する、請求項15に記載の装置。
  17. データパケット送信装置であって、
    BAPレイヤにおいて制御プロトコルデータユニットPDUを送信するために使用される第1のバックホールリンクBH無線リンク制御RLCチャネルを決定するように構成された処理ユニットと、
    前記BAPレイヤにおける前記制御PDUを、前記第1のBH RLCチャネルを介して前記IABノードの隣接ノードに送信するように構成された通信ユニットと
    を備えるデータパケット送信装置。
  18. 前記処理ユニットは、特に、
    IABドナーから第1の設定情報を取得し、前記第1の設定情報は、前記BAPレイヤにおいて前記制御PDUを送信するために使用される前記第1のBH RLCチャネルを示すために使用され、
    前記第1の設定情報に基づいて前記第1のBH RLCチャネルを決定する
    ように構成される、請求項17に記載の装置。
  19. 前記第1の設定情報が、前記第1のBH RLCチャネルのチャネル識別子を備えるか、または、
    前記第1の設定情報が、論理チャネル識別子を備え、前記論理チャネル識別子によって示される論理チャネルは、前記第1のBH RLCチャネルに対応する、請求項18に記載の装置。
  20. データパケットのベアラマッピング装置であって、
    第2の設定情報を決定するように構成された処理ユニットであって、前記第2の設定情報は、第2のバックホールリンクBH無線リンク制御RLCチャネルを示すために使用され、前記第2のBH RLCチャネルは、第1のタイプのデータペイロードを送信するために使用され、前記第1のタイプのデータペイロードは、F1ユーザプレーンF1-UデータペイロードおよびF1制御プレーンF1-Cデータペイロード以外のデータペイロードである、処理ユニットと、
    前記第2の設定情報をIABノードに送信するように構成された通信ユニットと
    を備えるベアラマッピング装置。
  21. 前記第1のタイプのデータペイロードは、以下の、
    運用、管理、および保守OAMトラフィックパケットと、
    インターネットプロトコルIPアドレスを要求するために使用されるパケットと、
    インターネットプロトコルセキュリティIPsec送信チャネルを確立するために使用されるパケットと、
    ストリーム制御トランスポートプロトコルSCTPアソシエーションセットアップパケットと、
    SCTPアソシエーションシャットダウンパケットと、
    SCTPアソシエーションハートビートパケットとのうちのいずれか1つを備える、請求項20に記載の装置。
  22. 前記第2の設定情報は、以下の、
    第1のタイプであって、データペイロードのタイプであり、前記第2のBH RLCチャネルに対応する第1のタイプと、
    第1の差別化されたサービス情報であって、前記第1のタイプおよび/または前記第2のBH RLCチャネルに対応する第1の差別化されたサービス情報と、
    第1のフローラベルであって、前記第1のタイプおよび/または前記第2のBH RLCチャネルに対応する第1のフローラベルとのうちのいずれか1つまたは複数を備える、請求項21に記載の装置。
  23. 前記処理ユニットは、
    第1のデータペイロードを生成するようにさらに構成され、前記第1のデータペイロードは、前記第1のタイプのデータペイロードであり、
    前記第1のデータペイロードに対応するパケットヘッダ情報が前記第1の差別化されたサービス情報を搬送する場合、前記通信ユニットは、前記第1の差別化されたサービス情報に対応する前記第2のBH RLCチャネルを介して前記IABノードに第1のデータパケットを送信するようにさらに構成され、または、前記第1のデータペイロードに対応するパケットヘッダ情報が前記第1のフローラベルを搬送する場合、前記通信ユニットは、前記第1のフローラベルに対応する前記第2のBH RLCチャネルを介して前記IABノードに第1のデータパケットを送信するようにさらに構成され、前記第1のデータパケットは、前記第1のデータペイロードを備える、請求項22に記載の装置。
  24. 前記第2の設定情報は、前記第2のBH RLCチャネルを識別するために使用される識別情報を備え、前記識別情報は、前記第2のBH RLCチャネルのチャネル識別子であるか、または、前記識別情報は、前記第2のBH RLCチャネルに対応する論理チャネル識別子である、請求項23に記載の装置。
  25. データパケットのベアラマッピング装置であって、
    IABドナーから第2の設定情報を受信するように構成された通信ユニットであって、前記第2の設定情報は、第2のバックホールリンクBH無線リンク制御RLCチャネルを示すために使用され、前記第2のBH RLCチャネルは、第1のタイプのデータペイロードを送信するために使用され、前記第1のタイプのデータペイロードは、F1ユーザプレーンF1-UデータペイロードおよびF1制御プレーンF1-Cデータペイロード以外のデータペイロードである、通信ユニットと、
    前記第2の設定情報に基づいて前記第1のタイプのデータペイロードを送信するように構成された処理ユニットと
    を備えるベアラマッピング装置。
  26. 前記第1のタイプのデータペイロードは、以下の、
    運用、管理、および保守OAMトラフィックパケットと、
    インターネットプロトコルIPアドレスを要求するために使用されるパケットと、
    インターネットプロトコルセキュリティIPsec送信チャネルを確立するために使用されるパケットと、
    ストリーム制御トランスポートプロトコルSCTPアソシエーションセットアップパケットと、
    SCTPアソシエーションシャットダウンパケットと、
    SCTPアソシエーションハートビートパケットとのうちのいずれか1つを備える、請求項25に記載の装置。
  27. 前記第2の設定情報は、以下の、
    第1のタイプであって、データペイロードのタイプであり、前記第2のBH RLCチャネルに対応する第1のタイプと、
    第1の差別化されたサービス情報であって、前記第1のタイプおよび/または前記第2のBH RLCチャネルに対応する第1の差別化されたサービス情報と、
    第1のフローラベルであって、前記第1のタイプおよび/または前記第2のBH RLCチャネルに対応する第1のフローラベルとのうちのいずれか1つまたは複数を備える、請求項26に記載の装置。
  28. 前記第2の設定情報は、前記第2のBH RLCチャネルを識別するために使用される識別情報を備え、前記識別情報は、前記第2のBH RLCチャネルのチャネル識別子であるか、または、前記識別情報は、前記第2のBH RLCチャネルに対応する論理チャネル識別子である、請求項25に記載の装置。
  29. メモリおよびプロセッサを備える通信装置であって、前記メモリは、命令を記憶するように構成され、前記プロセッサは、前記メモリに記憶された前記命令を実行するように構成され、前記メモリに記憶された前記命令を実行するとき、前記プロセッサは、請求項1乃至14のいずれか一項に記載の方法を実行するように構成される、通信装置。
  30. コンピュータ可読命令を備えるコンピュータ可読記憶媒体であって、通信装置が前記コンピュータ可読命令を読み取って実行するとき、前記通信装置は、請求項1乃至14のいずれか一項に記載の方法を実行することを可能にされる、コンピュータ可読記憶媒体。
  31. コンピュータ可読命令を備えるコンピュータプログラム製品であって、通信装置が前記コンピュータ可読命令を読み取って実行するとき、前記通信装置は、請求項1乃至14のいずれか一項に記載の方法を実行することを可能にされる、コンピュータプログラム製品。
JP2022519832A 2019-09-30 2019-09-30 データパケット送信方法および装置 Active JP7482997B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2019/109728 WO2021062803A1 (zh) 2019-09-30 2019-09-30 一种数据包传输方法及装置

Publications (2)

Publication Number Publication Date
JP2022549953A true JP2022549953A (ja) 2022-11-29
JP7482997B2 JP7482997B2 (ja) 2024-05-14

Family

ID=75336766

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022519832A Active JP7482997B2 (ja) 2019-09-30 2019-09-30 データパケット送信方法および装置

Country Status (6)

Country Link
US (1) US20220225209A1 (ja)
EP (1) EP4044543A4 (ja)
JP (1) JP7482997B2 (ja)
CN (1) CN114467288A (ja)
BR (1) BR112022005876A2 (ja)
WO (1) WO2021062803A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7506835B2 (ja) 2021-10-19 2024-06-26 京セラ株式会社 通信制御方法、中継ノード、セルラ通信システム、チップセット、及びプログラム

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2587653B (en) * 2019-10-03 2023-04-26 Samsung Electronics Co Ltd Flow control
WO2021087924A1 (zh) * 2019-11-07 2021-05-14 华为技术有限公司 一种通信方法及装置
CN115955688B (zh) * 2023-03-03 2023-05-26 新华三技术有限公司 一种应用于5g的数据传输方法、系统、装置及电子设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019182694A1 (en) * 2018-03-19 2019-09-26 Qualcomm Incorporated Qos support in wireless backhaul networks using cellular radio-access technologies

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110035042B (zh) * 2018-01-12 2020-08-07 华为技术有限公司 一种数据传输方法及装置
US10785699B2 (en) * 2018-03-28 2020-09-22 Apple Inc. Next generation node-B (GNB) for integrated access and backhaul (IAB) relay in new radio (NR) networks
US11457372B2 (en) * 2018-07-20 2022-09-27 Lg Electronics Inc. Method and apparatus for supporting link congestion detection in wireless communication system
KR20200032560A (ko) * 2018-09-18 2020-03-26 삼성전자주식회사 무선 통신 시스템에서 데이터를 송수신하는 방법 및 장치

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019182694A1 (en) * 2018-03-19 2019-09-26 Qualcomm Incorporated Qos support in wireless backhaul networks using cellular radio-access technologies

Non-Patent Citations (8)

* Cited by examiner, † Cited by third party
Title
ERICSSON: "Signaling Aspects of BH RLC Channel and BAP Layer Configuration[online]", 3GPP TSG RAN WG3 #105 R3-193734, JPN6023012979, 16 August 2019 (2019-08-16), ISSN: 0005222319 *
HUAWEI, HISILICON: "Bearer mapping decision and configuration details[online]", 3GPP TSG RAN WG2 #107 R2-1910344, JPN6023012977, 16 August 2019 (2019-08-16), ISSN: 0005222317 *
HUAWEI, HISILICON: "Bearer mapping for other traffic[online]", 3GPP TSG RAN WG2 #107 R2-1910329, JPN6023012981, 16 August 2019 (2019-08-16), ISSN: 0005222321 *
QUALCOMM INCORPORATED (RAPPORTEUR): "Offline 106: BAP configuration based on F1 to F7[online]", 3GPP TSG RAN WG2 #107 R2-1911796, JPN6023012975, 30 August 2019 (2019-08-30), ISSN: 0005222315 *
QUALCOMM INCORPORATED: "IAB configuration of BAP-layer forwarding[online]", 3GPP TSG RAN WG2 #107 R2-1909642, JPN6023012980, 30 August 2019 (2019-08-30), ISSN: 0005222320 *
QUALCOMM: "CR to 38.300 on Integrated Access and Backhaul for NR[online]", 3GPP TSG RAN WG2 #107 R2-1911546, JPN6023012974, 30 August 2019 (2019-08-30), ISSN: 0005222314 *
SAMSUNG: "BAP configuration[online]", 3GPP TSG RAN WG2 #107 R2-1910372, JPN6023012976, 16 August 2019 (2019-08-16), ISSN: 0005222316 *
SAMSUNG: "Further discussions on BH RLC CH configuration[online]", 3GPP TSG RAN WG3 #104 R3-192605, JPN6023012978, 2 May 2019 (2019-05-02), ISSN: 0005222318 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7506835B2 (ja) 2021-10-19 2024-06-26 京セラ株式会社 通信制御方法、中継ノード、セルラ通信システム、チップセット、及びプログラム

Also Published As

Publication number Publication date
EP4044543A4 (en) 2022-09-21
WO2021062803A1 (zh) 2021-04-08
JP7482997B2 (ja) 2024-05-14
CN114467288A (zh) 2022-05-10
EP4044543A1 (en) 2022-08-17
US20220225209A1 (en) 2022-07-14
BR112022005876A2 (pt) 2022-06-21

Similar Documents

Publication Publication Date Title
US11102832B2 (en) Method and wireless communication system for handling offloading of DRBs to WLAN carrier
US11510131B2 (en) Configuration method, data transmission method, and apparatus
CN108307472B (zh) 设备直通系统的通信方法及装置、通信系统
US9883441B2 (en) Method and apparatus to route packet flows over two transport radios
CN107006022B (zh) 用户装置、存储装置以及lwa pdu路由方法及装置
WO2019242747A1 (zh) 数据包的发送、接收方法及装置和数据包的传输系统
CN104869666B (zh) 数据无线承载配置方法、数据传输方法及设备
JP7482997B2 (ja) データパケット送信方法および装置
EP2811779A1 (en) System, user equipment and method for implementing multi-network joint transmission
EP3734858A1 (en) Node and communication method
CN111586890B (zh) 一种数据传输方法及装置
JP2019201421A (ja) データ・オフロードのためのパスを確立する方法及び装置
KR20180125450A (ko) 중계 전송 방법과 장치, 및 중계 단말 장비
WO2015032565A1 (en) Selective bearer splitting in cell system
US20180124857A1 (en) Radio access network device, data processing method, and ip packet processing method
CN114503526A (zh) 用于路由和承载映射配置的方法及设备
US20150117310A1 (en) Method and apparatus to route packet flows over two transport radios
US20140219198A1 (en) Method for switching communication connection mode, communication system, base station, transmitter and receiver
US11533769B2 (en) Multi-hop data transmission method and apparatus
US20220264602A1 (en) Communication method and apparatus
US11470661B2 (en) Backhaul channel management for IAB networks
CN114424621B (zh) 一种缓冲区状态报告传输方法及装置
RU2803196C1 (ru) Способ передачи пакета данных и устройство
WO2022205326A1 (en) Integrated access and backhaul donor migration methods and systems
WO2016095598A1 (zh) 一种实现用户面地址互通的方法和装置

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220510

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220510

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230315

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230404

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20230704

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20230904

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231003

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231219

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240319

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240423

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240430

R150 Certificate of patent or registration of utility model

Ref document number: 7482997

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150