JP2022544798A - ルーティング方法及び装置 - Google Patents

Abstract

ルーティング方法及び装置が提供される。当該方法は以下を含む。第1のノードはデータパケットを受信する。第1のノードは、データパケット内のバックホール適応プロトコル(BAP)ヘッダを決定し、BAPヘッダは、データパケットの宛先ノードのBAPアドレス及び第1の情報を含み、第1の情報は、BAPヘッダがデータパケットのルーティングパス識別子を含むか否かを決定するために使用される。第1のノードは、BAPヘッダに基づいてBAPヘッダを含むデータパケットを宛先ノードに送信する。上記の方法によって、データパケットを受信した後に、第1のノードは、データパケット内のBAPヘッダを決定し、BAPヘッダに基づいてBAPヘッダを含むデータパケットを宛先ノードに送信する。このように、データパケットのルーティングが可能になり、それにより、IABネットワークにおけるデータパケットオフローディングを実現する。

Description

［関連出願への相互参照］
この出願は、2019年8月15日に中国国家知識産権局に出願された「ROUTING METHOD AND APPARATUS」という名称の中国特許出願第201910755511.7号に対する優先権を主張し、その全内容を参照により援用する。

［技術分野］
この出願は、通信技術の分野に関し、特にルーティング方法及び装置に関する。

第4世代移動通信システムと比較して、第5世代(5G)移動通信は、ネットワーク性能指標に対するより厳しい要件、例えば、1000倍に増加した容量指標、より広いカバレッジ並びに極めて高い信頼性及び極めて低い待ち時間を有する。いくつかのシナリオでは、高周波数搬送波周波数リソースが豊富であるので、高周波数スモールセルネットワーキングは、5Gの極めて高い容量要件を満たすためにホットスポットエリアにおいてますます一般的になっている。しかし、高周波数搬送波は、悪い伝搬特性、障害による極度の減衰、及び限られたカバレッジを有する。したがって、大量の高密度に配備されたスモールセルが必要とされる。対応して、高密度に配備されたスモールセルのための光バックホールを提供することは高コストであり、構成は困難である。したがって、より経済的且つ便利なバックホール解決策が必要とされる。他のシナリオでは、広いカバレッジ要件の観点から、いくつかの遠隔地域においてネットワークカバレッジを提供するために光ファイバを配備することは困難であり高コストである。また、経済的且つ便利なバックホール解決策も早急に必要である。統合アクセス及びバックホール(integrated access and backhaul, IAB)技術は、上記の問題を解決するための概念を提供する。当該技術においてアクセスリンク(access link)及びバックホールリンク(backhaul link)の双方は無線伝送解決策を使用し、ファイバ配備が回避される。

IABネットワークにおいて、中継ノード(relay node, RN)はまた、IABノード(IAB node)とも呼ばれ、ユーザ装置(user equipment, UE)のために無線アクセスサービスを提供してもよい。UEのサービスデータは、無線バックホールリンクを通じてIABドナー(IAB donor)に接続された1つ以上のIABノードにより伝送される。

IABの既存のルーティングメカニズムの議論において、1つのルーティングテーブルがIABノード毎に構成される。各ルーティングテーブルは、以下の情報、すなわち、データパケットの宛先ノード、及び宛先ノードに対応する次ホップノードを少なくとも含む。任意選択で、ルーティングテーブルは、データパケットのルーティングパス識別子を更に含んでもよい。1つの宛先ノードは、1つ以上のルーティングパス識別子に対応してもよい。このルーティングモードでは、どのようにIABノードがデータパケットのルーティングを実現するかが議論されている。

この出願の実施形態は、どのようにIABノードがデータパケットのルーティングを実現するかに関する問題を解決するためのルーティング方法及び装置を提供する。

第1の態様によれば、この出願の実施形態は、ルーティング方法を提供する。当該方法は以下を含む。第1のノードはデータパケットを受信する。第1のノードは、データパケット内のBAPヘッダを決定し、BAPヘッダは、データパケットの宛先ノードのBAPアドレス及び第1の情報を含み、第1の情報は、BAPヘッダがデータパケットのルーティングパス識別子を含むか否かを決定するために使用される。第1のノードは、BAPヘッダに基づいてBAPヘッダを含むデータパケットを宛先ノードに送信する。

上記の方法によって、データパケットを受信した後に、第1のノードは、データパケット内のBAPヘッダを決定し、BAPヘッダは、データパケットの宛先ノードのBAPアドレス及び第1の情報を含む。したがって、この出願のこの実施形態は、BAPヘッダの新たなフォーマットを提供する。さらに、第1のノードは、BAPヘッダ内にあるデータパケットの宛先ノードのBAPアドレス及び第1の情報に基づいて、BAPヘッダを含むデータパケットを宛先ノードに送信してもよく、それにより、データパケットのルーティングを実現する。

可能な設計では、第1の情報はデータパケットのルーティングパス識別子である。データパケットのルーティングパス識別子が予め設定された値である場合、予め設定された値は、データパケットのルーティングパス識別子を無効にするために使用される。上記の設計は、BAPヘッダが統一されたフォーマットを有し、データパケットのルーティングパス識別子が存在するか否かにかかわらず、BAPヘッダの長さが不変のままであることを確保できる。

代替として、第1の情報は指示フィールドを含む。指示フィールドは、BAPヘッダがデータパケットのルーティングパス識別子を含むか否かを示すために使用される。指示フィールドが、BAPヘッダがデータパケットのルーティングパス識別子を含むことを示す場合、第1の情報は、データパケットのルーティングパス識別子を更に含む。上記の設計は、BAPヘッダがデータパケットのルーティングパス識別子を含まないとき、ヘッダオーバヘッドを低減できる。

可能な設計では、第1の情報は、データパケットの送信元ノードのBAPアドレスを更に含む。

可能な設計では、第1のノードがデータパケット内のBAPヘッダを決定することは、第1のノードがデータパケットに追加されたBAPヘッダを決定することを意味してもよい。

可能な設計では、当該方法は以下を更に含む。第1のノードは、データパケットから古いBAPヘッダを削除し、BAPヘッダをデータパケットに追加する。

可能な設計では、当該方法は以下を更に含む。第1のノードは、データパケット内のBAPヘッダと、BAPヘッダ及びルーティングテーブルにおける共通フィールドとに基づいて、データパケットのルーティングパス上の第1のノードの次ホップノードを決定する。

可能な設計では、データパケットのルーティングパスは、第1のノードと宛先ノードの間の第1のパスである。第1のパスは、第1のノードと宛先ノードとの間の第1のデフォルトルーティングパスであるか、第1のパスは、第1のノードのルーティングテーブル内の第1のノードと宛先ノードとの間の少なくとも1つのルーティングパスの中で最高の優先度を有するルーティングパスであるか、或いは、第1のパスは、第1のノードによりバッファされたデータ量と予め設定された閾値との間の予め設定された関係に基づいて、第1のノードと宛先ノードとの間の複数のルーティングパスから第1のノードにより決定されたルーティングパスである。代替として、第1のパスは、予め設定された比率情報に基づいて、第1のノードと宛先ノードとの間の複数のルーティングパスから第1のノードにより決定されたルーティングパスであり、予め設定された比率情報は、複数のルーティングパスのそれぞれに対応する伝送データパケットの数の比率情報である。代替として、第1のパスは、データパケットで搬送された指示情報に基づいて第1のノードにより決定されたルーティングパスである。

上記の設計によって、第1のノードは、第1のノードと宛先ノードとの間のルーティングパスを決定し、第1のノードと宛先ノードとの間のルーティングパスに基づいてデータパケットを宛先ノードに送信し、それにより、IABネットワークにおけるデータパケットオフローディングが実現できる。

可能な設計では、第1のノードがデータパケット内のBAPヘッダを決定することは、第1のノードが、第1のパスの無線リンクが故障又は輻輳しており、且つ、宛先ノード以外の第2のノードが存在すると決定したとき、第1のノードが、データパケット内のBAPヘッダ内の宛先ノードのBAPアドレスを第2のノードのBAPアドレスに変更することを意味してもよい。データパケットはアップリンクデータパケットであり、第2のノードは、変更前の宛先ノードが属する統合アクセス及びバックホール(IAB)ドナーの他の分散ユニットである。

上記の設計によって、第1のノードが、データパケットを宛先ノードに送信するためのルーティングパスの無線リンクが故障又は輻輳していると決定したとき、第1のノードは、データパケットの宛先ノードのBAPアドレスを再決定し、新たな宛先ノードのBAPアドレスに基づいてルーティングを実行してもよい。このように、無線リンクが回復するのを待機せずに、データパケットは、新たな宛先ノードに適時に送信でき、それにより、サービス待ち時間要件をより良く満たす。

可能な設計では、第1のノードがデータパケット内のBAPヘッダを決定することは、第1のノードが、第1のパスの無線リンクが故障又は輻輳しており、且つ、宛先ノード以外の第2のノードが存在すると決定したとき、第1のノードがデータパケット内のBAPヘッダ内の宛先ノードのBAPアドレスを第2のノードのBAPアドレスに変更することを意味してもよい。データパケットはダウンリンクデータパケットであり、第2のノードはデータパケットを受信する端末装置によりアクセスされる他のIABノードである。

上記の設計によって、第1のノードが、データパケットを宛先ノードに送信するためのルーティングパスの無線リンクが故障又は輻輳していると決定したとき、第1のノードは、データパケットの宛先ノードのBAPアドレスを再決定し、新たな宛先ノードのBAPアドレスに基づいてルーティングを実行してもよい。このように、無線リンクが回復するのを待機せずに、データパケットは、新たな宛先ノードに適時に送信でき、それにより、サービス待ち時間要件をより良く満たす。

可能な設計では、第1のノードがBAPヘッダに基づいてBAPヘッダを含むデータパケットを宛先ノードに送信することは、第1のノードが、データパケットのルーティングパスの無線リンクが故障又は輻輳していると決定したとき、第1のノードが第2のパスを通じてBAPヘッダを含むデータパケットを宛先ノードに送信することを意味してもよい。第2のパスは、第1のノードと宛先ノードの間のパスである。

上記の設計によって、第1のノードが、データパケットのルーティングパスが利用不可能であると決定したとき、第1のノードは、データパケットのルーティングパスとして、第1のノードと宛先ノードとの間の新たなルーティングパスを再決定してもよい。このように、無線リンクが回復するのを待機せずに、データパケットは、他のルーティングパスを通じて宛先ノードに適時に送信でき、それにより、サービス待ち時間要件をより良く満たす。

可能な設計では、当該方法は以下を更に含む。データパケットがダウンリンクデータパケットである場合、第1のノードは、宛先ノードのIPアドレスと宛先ノードのBAPアドレスとの間のマッピング関係に基づいて、宛先ノードのBAPアドレスを決定する。

上記の方法によって、第1のノードは、データパケットのルーティングを可能にするために、宛先ノードのBAPアドレスを決定し、それにより、IABネットワークにおけるデータパケットオフローディングを実現する。

可能な設計では、データパケットがアップリンクデータパケットである場合、当該方法は以下を更に含む。第1のノードは、第1のノードのためにIABドナーの集約ユニットにより構成されたIABドナーの分散ユニットのBAPアドレスを宛先ノードのBAPアドレスとして使用するか、或いは、第1のノードは、宛先CU-CPと宛先ノードのBAPアドレスとの間のマッピング関係に基づいて、宛先ノードのBAPアドレスを決定する。

上記の方法によって、第1のノードは、データパケットのルーティングを可能にするために、宛先ノードのBAPアドレスを決定し、それにより、IABネットワークにおけるデータパケットオフローディングを実現する。

可能な設計では、データパケットがアップリンクデータパケットである場合、宛先ノードはIABドナーの分散ユニットであり、第1のノードはアクセスIABノード、又はアクセスIABノードとIABドナーとの間の中間IABノードであり、送信元ノードはアクセスIABノードである。アクセスIABノードは、アップリンクデータパケットを送信する端末デバイスによりアクセスされるノードである。

可能な設計では、データパケットがダウンリンクデータパケットである場合、宛先ノードはアクセスIABノードであり、第1のノードはIABドナーの分散ユニット、又はIABドナーの分散ユニットとアクセスIABノードとの間の中間IABノードであり、送信元ノードはIABドナーの分散ユニットである。アクセスIABノードは、ダウンリンクデータパケットを受信する端末デバイスによりアクセスされるノードである。

第2の態様によれば、この出願の実施形態は、通信装置、例えば、第1のノードを提供する。当該装置は、IABノードでもよく或いはIABノード内のチップでもよく、或いは、当該装置は、donor DUでもよく或いはdonor DU内のチップでもよい。当該装置は、処理ユニット、送信ユニット及び受信ユニットを含んでもよい。ここでの送信ユニット及び受信ユニットは、代替としてトランシーバユニットでもよいことが理解されるべきである。当該装置がIABノード又はdonor DUであるとき、処理ユニットはプロセッサでもよく、送信ユニット及び受信ユニットはトランシーバでもよい。IABノード又はdonor DUは、記憶ユニットを更に含んでもよく、記憶ユニットはメモリでもよい。記憶ユニットは、命令を記憶するように構成され、処理ユニットは、記憶ユニットに記憶された命令を実行し、それにより、端末デバイスは、第1の態様又は第1の態様の可能な設計のうちいずれか1つによる方法を実行する。当該装置がIABノード又はdonor DU内のチップであるとき、処理ユニットはプロセッサでもよく、送信ユニット及び受信ユニットは入力/出力インタフェース、ピン、回路等でもよい。処理ユニットは、記憶ユニットに記憶された命令を実行し、それにより、チップは、第1の態様又は第1の態様の可能な設計のうちいずれかの1つによる方法を実行する。記憶ユニットは、命令を記憶するように構成され、記憶ユニットは、チップ内の記憶ユニット(例えば、レジスタ又はキャッシュ)でもよく、或いは、IABノード又はdonor DU内にあり且つチップの外部に位置する記憶ユニット(例えば、読み取り専用メモリ又はランダムアクセスメモリ)でもよい。

第3の態様によれば、この出願の実施形態は、コンピュータ読み取り可能記憶媒体を更に提供する。コンピュータ読み取り可能記憶媒体は、コンピュータプログラムを記憶し、コンピュータプログラムがコンピュータ上で実行されたとき、コンピュータは、第1の態様による方法を実行することが可能になる。

第4の態様によれば、この出願の実施形態は、プログラムを含むコンピュータプログラム製品を更に提供する。コンピュータプログラム製品がコンピュータ上で実行されたとき、コンピュータは、第1の態様による方法を実行することが可能になる。

第5の態様によれば、この出願の実施形態は、通信システムを更に提供する。通信システムは、送信元ノード、宛先ノード及び少なくとも1つの第1のノードを含む。第1のノードは、データパケットのルーティングパス上の送信元ノードと宛先ノードとの間の中間ノードである。第1のノードは、第1の態様又は第1の態様の可能な設計のうちいずれかの1つによる方法を実行する。

第6の態様によれば、この出願の実施形態は、通信システムを更に提供する。通信システムは、第1のノード及び宛先ノードを含む。第1のノードは、データパケットのルーティングパス上の送信元ノードである。第1のノードは、第1の態様又は第1の態様の可能な設計のうちいずれかの1つによる方法を実行する。

可能な設計では、通信システムは、少なくとも1つの中間ノードを更に含む。中間ノードは、データパケットのルーティングパス上の第1のノードと宛先ノードの間の中間ノードである。中間ノードは、第1の態様又は第1の態様の可能な設計のうちいずれかの1つによる方法を実行する。

第7の態様によれば、この出願の実施形態は、アップリンクデータ伝送方法を提供する。当該方法は以下を含む。第1のノードは、ドナー集約ユニット(donor CU)により構成された宛先集約ユニット・ユーザプレーン(CU-UP)のインターネットプロトコル(IP)アドレスと宛先ノードのバックホール適応プロトコル(BAP)アドレスとの間のマッピング関係を取得し、第1のノードは統合アクセス及びバックホール(IAB)ノードである。第1のノードは、マッピング関係に基づいて宛先ノードのBAPアドレスを決定する。第1のノードは、GPRSトンネリングプロトコル・ユーザプレーン内にあり且つアップリンクデータパケットで搬送されたトンネルエンドポイント識別子に基づいて、第1のノードと宛先ノードとの間の第1のパスを決定する。第1のノードは、宛先ノードのBAPアドレスに基づいて、アップリンクデータパケットを第1のパス上の宛先ノードに送信する。

上記の方法によって、第1のノードは、アップリンクデータパケットで搬送された宛先CU-UPのIPアドレスに基づいて、宛先ノードのBAPアドレスを決定し、それにより、データパケットのルーティングを可能にする。さらに、宛先ノードの異なるBAPアドレスは、異なるサービス要件を有するデータパケット又は異なる終端ノードを有するデータパケットのために構成できる。このように、IABネットワークにおけるデータパケットオフローディングが実現できる。

可能な設計では、第1のノードが、GPRSトンネリングプロトコル・ユーザプレーン内にあり且つアップリンクデータパケットで搬送されたトンネルエンドポイント識別子に基づいて、第1のノードと宛先ノードとの間の第1のパスを決定するとき、第1のノードは、第1のパスとdonor CUにより構成されたトンネルエンドポイント識別子との間のマッピング関係を取得し、マッピング関係と、GPRSトンネリングプロトコル・ユーザプレーン内にあり且つアップリンクデータパケットで搬送されたトンネルエンドポイント識別子とに基づいて、第1のパスを決定する。

可能な設計では、当該方法は以下を更に含む。第1のノードは、BAPヘッダをアップリンクデータパケットに追加することを決定し、BAPヘッダは、宛先ノードのBAPアドレス及び第1のパスの識別子を含む。

可能な設計では、第1のパスは、全体のネットワーク又はdonor CU内で固有であるルーティングパス識別子を有するルーティングパスである。

可能な設計では、宛先ノードはドナー分散ユニット(donor DU)である。

第8の態様によれば、この出願の実施形態は、ダウンリンクデータ伝送方法を提供する。当該方法は以下を含む。第1のノードは、ドナー集約ユニット(donor CU)により構成された宛先ノードのインターネットプロトコル(IP)アドレスと宛先ノードのバックホール適応プロトコル(BAP)アドレスとの間のマッピング関係を取得し、第1のノードはドナー分散ユニット(donor DU)である。第1のノードは、マッピング関係と、ダウンリンクデータパケットで搬送された宛先ノードのIPアドレスとに基づいて、宛先ノードのBAPアドレスを決定する。第1のノードは、ダウンリンクデータパケットで搬送された差別化サービスコードポイント(DSCP)又はフローラベル(flow label)に基づいて、第1のノードと宛先ノードとの間の第1のパスを決定する。第1のノードは、宛先ノードのBAPアドレスに基づいて、ダウンリンクデータパケットを第1のパス上の宛先ノードに送信する。

上記の方法によって、第1のノードは、第1のノードと宛先ノードとの間のルーティングパスを決定し、第1のノードと宛先ノードとの間のルーティングパスに基づいて、データパケットを宛先ノードに送信してもよく、それにより、IABネットワークにおけるデータパケットオフローディングが実現できる。

可能な設計では、第1のノードがダウンリンクデータパケットで搬送された差別化サービスコードポイント(DSCP)又はフローラベルに基づいて、第1のノードと宛先ノードとの間の第1のパスを決定するとき、第1のノードは、第1のパスとdonor CUにより構成されたDSCP又はフローラベルとの間のマッピング関係を取得し、DSCP又はフローラベルとマッピング関係とに基づいて第1のパスを決定する。

可能な設計では、当該方法は以下を更に含む。第1のノードは、BAPヘッダをダウンリンクデータパケットに追加することを決定し、BAPヘッダは、宛先ノードのBAPアドレス及び第1のパスの識別子を含む。

可能な設計では、第1のパスは、全体のネットワーク又はdonor CU内で固有であるルーティングパス識別子を有するルーティングパスである。

可能な設計では、宛先ノードは、ダウンリンクデータパケットを受信する端末デバイスのアクセスIABノードである。

第9の態様によれば、この出願は、コンピュータ読み取り可能記憶媒体を更に提供する。コンピュータ読み取り可能記憶媒体は、コンピュータプログラムを記憶する。コンピュータプログラムがコンピュータ上で実行されたとき、コンピュータは、第7の態様及び第8の態様による方法を実行することが可能になる。

第10の態様によれば、この出願は、プログラムを含むコンピュータプログラム製品を更に提供する。コンピュータプログラム製品がコンピュータ上で実行したとき、コンピュータは、第7の態様及び第8の態様による方法を実行することが可能になる。

第11の態様によれば、この出願は、プロセッサ及びメモリを含む通信装置を更に提供し、メモリは、コンピュータ実行可能命令を記憶するように構成され、プロセッサは、メモリに記憶されたコンピュータ実行可能命令を実行するように構成され、それにより、通信装置は、第7の態様及び第8の態様による方法を実行する。

第12の態様によれば、この出願は、プロセッサ及びインタフェース回路を含む通信装置を更に提供し、インタフェース回路は、コード命令を受信し、コード命令をプロセッサに伝送するように構成され、プロセッサは、コード命令を実行し、第7の態様及び第8の態様による方法を実行する。

この出願による移動通信システムのアーキテクチャの概略図である。 この出願によるプロトコルアーキテクチャの概略図である。 この出願によるIABネットワーキングシナリオの概略図である。 、この出願に従って第1のノードが第2のノードを通じてルーティングを実行することを示す概略図である。 この出願によるBAPヘッダのフォーマットの概略図である この出願によるBAPヘッダのフォーマットの概略図である この出願によるルーティング方法の概略フローチャートである この出願によるIABアップリンク伝送のためのルーティング解決策の第1の概略図である。 この出願によるIABアップリンク伝送のためのルーティング解決策の第2の概略図である。 この出願によるIABダウンリンク伝送のためのルーティング解決策の第1の概略図である。 この出願によるIABダウンリンク伝送のためのルーティング解決策の第2の概略図である。 この出願による装置の構造を示す第1の概略図である。 この出願による装置の構造を示す第2の概略図である。

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

図１は、この出願の実施形態が適用される移動通信システムのアーキテクチャの概略図である。図１に示すように、移動通信システムは、コアネットワークデバイス110、無線アクセスネットワークデバイス120、無線バックホールデバイス130及び少なくとも1つの端末デバイス(例えば、図１における端末デバイス140及び端末デバイス150)を含む。端末デバイスは、無線方式で無線バックホールデバイスに接続され、1つ以上の無線バックホールデバイスを通じて無線アクセスネットワークデバイスに接続される。さらに、いくつかの端末デバイスはまた、無線方式で無線アクセスネットワークデバイスに直接接続されてもよい。無線アクセスネットワークデバイスは、無線又は有線方式でコアネットワークデバイスに接続される。コアネットワークデバイス及び無線アクセスネットワークデバイスは、独立した異なる物理デバイスでもよい。代替として、コアネットワークデバイスの機能及び無線アクセスネットワークデバイスの論理機能は、同じ物理デバイスに統合されてもよい。代替として、コアネットワークデバイスのいくつかの機能及び無線アクセスネットワークデバイスのいくつかの機能は、物理デバイスに統合されてもよい。これは、この出願では限定されない。端末デバイスは、固定位置にあってもよく、或いは、移動可能でもよい。図１に示す移動通信システムは、単なる概略図であり、通信システムは、例えば、図１に示されていない無線中継デバイス又は無線バックホールデバイスを更に含んでもよいことが理解されるべきである。さらに、移動通信システムに含まれるコアネットワークデバイス、無線アクセスネットワークデバイス、無線バックホールデバイス及び端末デバイスの数は、この出願の実施形態では限定されない。

無線アクセスネットワークデバイスは、無線方式で移動通信システムにアクセスするために端末デバイスにより使用されるアクセスデバイスである。無線アクセスネットワークデバイスは、基地局NodeB、進化型基地局eNodeB、5G移動通信システムにおける基地局、将来の移動通信システムにおける基地局、Wi-Fiシステムにおけるアクセスノード等でもよい。この出願のこの実施形態は、無線アクセスネットワークデバイスにより使用される特定の技術及び無線アクセスネットワークデバイスの特定のデバイス形式に対して限定を課さない。端末デバイスはまた、端末(Terminal)、UE、移動局(mobile station, MS)、移動端末(mobile terminal, MT)等とも呼ばれてもよい。

端末デバイスは、携帯電話(mobile phone)、タブレットコンピュータ(Pad)、無線トランシーバ機能を有するコンピュータ、仮想現実(virtual reality, VR)端末デバイス、拡張現実(augmented reality, AR)端末デバイス、産業制御(industrial control)における無線端末、自動運転(self driving)における無線端末、遠隔医療手術(remote medical surgery)における無線端末、スマートグリッド(smart grid)における無線端末、輸送安全(transportation safety)における無線端末、スマートシティ(smart city)における無線端末、スマートホーム(smart home)における無線端末等でもよい。

無線アクセスネットワークデバイス及び端末デバイスは、屋内又は屋外デバイス、ハンドヘルドデバイス又は車載デバイスを含み、陸上に配備されてもよく、或いは、水上に配備されてもよく、或いは、空中の航空機、気球又は人工衛星に配備されてもよい。無線アクセスネットワークデバイス及び端末デバイスの適用シナリオは、この出願の実施形態では限定されない。

無線アクセスネットワークデバイスと端末デバイスとの間の通信、及び端末デバイスの間の通信は、ライセンススペクトル(licensed spectrum)若しくはアンライセンススペクトル(unlicensed spectrum)、又はライセンススペクトル及びアンライセンススペクトルの双方を使用することにより実行されてもよい。無線アクセスネットワークデバイスと端末デバイスとの間の通信、及び端末デバイスの間の通信は、6ギガヘルツ(gigahertz, GHz)の下のスペクトルを使用することにより実行されてもよく、或いは、6GHzの上のスペクトルを使用することにより実行されてもよく、或いは、6GHzの下のスペクトル及び6GHzの上のスペクトルの双方を使用することにより実行されてもよい。無線アクセスネットワークデバイス及び端末デバイスに使用されるスペクトルリソースは、この出願の実施形態では限定されない。

上記のネットワークエレメントは、専用ハードウェア上に実現されたネットワークエレメント、専用ハードウェア上で実行するソフトウェアインスタンス、又は適切なプラットフォーム上の仮想化機能のインスタンスでもよい。さらに、この出願の実施形態は、他の未来指向の通信技術に更に適用可能である。この出願に記載のネットワークアーキテクチャ及びサービスシナリオは、この出願における技術的解決策をより明確に説明することを意図するものであり、この出願において提供される技術的解決策に対する限定を構成しない。当業者は、ネットワークアーキテクチャの進化及び新たなサービスシナリオの出現に伴い、この出願において提供される技術的解決策が同様の技術的課題にも適用可能であることを認識し得る。

高周波数帯域の小さいカバレッジのため、ネットワークのカバレッジ性能を確保するために、マルチホップネットワーキングがIABネットワークにおいて使用されてもよい。サービス伝送信頼性を考慮して、IABノードは、バックホールリンク上の考えられる例外(無線リンクの停止又は遮断(blockage)及び負荷変動等)に対処して伝送信頼性を改善するために、デュアルコネクティビティ(dual connectivity, DC)又はマルチコネクティビティ(multi-connectivity)をサポートしてもよい。したがって、IABネットワークは、マルチホップ及びマルチコネクティビティネットワーキングをサポートしてもよく、複数のルーティングパスが端末デバイスとドナー基地局との間に存在してもよい。パス上に、IABノードの間に、且つ、IABノードとIABノードにサービス提供するドナー基地局との間に特定の階層関係が存在する。具体的には、各IABノードは、IABノードのためにバックホールサービスを提供するノードを親ノードとして扱い、対応して、各IABノードは、IABノードが属する親ノードの子ノードとして扱われることができる。

無線リンクの停止(outage)又は遮断(blockage)は、無線リンク障害又は輻輳を引き起こす可能性があることが理解されるべきである。例えば、建物がUEとIABドナーとの間に存在するとき、UEとIABドナーとの間の無線リンクが遮断される可能性がある。従来技術では、無線リンク障害の原因は以下を主に含む。物理層が、無線リンクに問題が発生し、その問題が或る期間継続していることを示すか、ランダムアクセス障害が発生するか、或いは、無線リンク制御(radio link control, RLC)障害が発生する。無線リンク障害はまた、他の理由により引き起こされる可能性があることが理解されるべきである。これは、この出願のこの実施形態では限定されない。無線リンク輻輳は、リンク上のIABノードにより伝送されるべきバッファされたアップリンク又はダウンリンクデータの量が、特定の閾値を超えることを意味してもよい。

IABノードは、移動端末(mobile termination, MT)部及び分散ユニット(distributed unit, DU)部を含んでもよい。IABノードの親ノードの観点から、IABノードは、親ノードにアクセスする端末デバイスとして考えられてもよく、すなわち、IABノードは、MTの役割を果たす。IABノードの子ノードの観点から、IABノードは、子ノードのためにバックホールサービスを提供するネットワークデバイスとして考えられてもよく、すなわち、IABノードは、DUの役割を果たす。ここでの子ノードは、他のIABノード又は端末デバイスでもよい。

IABドナーは、包括的な基地局機能を有するアクセスネットワークエレメント、例えば、ドナー基地局DgNBでもよく、或いは、集約ユニット(centralized unit, CU)及び分散ユニット(distributed unit, DU)が分離されている形式のアクセスネットワークエレメントでもよい。IABドナーは、端末デバイスにサービス提供するコアネットワーク(例えば、5Gコアネットワーク)エレメントに接続され、IABノードのために無線バックホール機能を提供する。説明を容易にするために、IABドナーの集約ユニットはdonor CUと呼ばれ、IABドナーの分散ユニットはdonor DUと呼ばれる。donor CUはまた、制御プレーン(control plane, CP)及びユーザプレーン(user plane, UP)が分離されている形式でもよい。例えば、CUは1つのCU-CP及び1つ(又は複数)のCU-UPを含んでもよい。

この出願のこの実施形態では、アクセスIABノードは、端末デバイスによりアクセスされるIABノード、すなわち、端末デバイスのためにサービスを提供するIABノードである。IABアップリンク伝送プロセスにおいて、アクセスIABノードは、1つ以上の他のIABノードを通じて、端末デバイスにより宛先donor DUに送信されたアップリンクデータパケットを伝送し、次いで、宛先donor DUは、アップリンクデータパケットを対応するdonor CU-UPに伝送する。IABダウンリンク伝送プロセスにおいて、データパケットが端末デバイスに送信されるべきである場合、donor CU-UPは、端末デバイスに送信されるべきダウンリンクデータパケットを対応するdonor DUに伝送し、donor DUは、1つ以上の他のIABノードを通じて或いは直接バックホールリンクを通じて、ダウンリンクデータパケットを端末デバイスに対応するアクセスIABノードに伝送し、次いで、アクセスIABノードは、受信したダウンリンクデータパケットを端末デバイスに伝送する。データパケットがIABノードに送信されるべきである場合、donor CU-UPは、IABノードに送信されるべきダウンリンクデータパケットを対応するdonor DUに伝送し、donor DUは、1つ以上の他のIABノードを通じて或いは直接バックホールリンクを通じて、ダウンリンクデータパケットをIABノードの親ノードに伝送し、次いで、IABノードの親ノードは、受信したダウンリンクデータパケットをIABノードに伝送する。

IABダウンリンク伝送プロセスにおいて、データパケットが最終的に到着するノード(終端ノードと呼ばれる)が端末デバイスである場合、宛先ノードは、端末デバイスに対応するアクセスIABノードであることが理解されるべきである。終端ノードがIABノードである場合、宛先ノードはIABノードの親ノードである。IABアップリンク伝送プロセスにおいて、終端ノードはdonor CU-UPであり、宛先ノードはdonor CU-UPに対応するdonor DUである。宛先ノードはまた、宛先受信ノードとも呼ばれてもよい。

したがって、この出願のこの実施形態では、データパケットがアップリンクデータパケットである場合、宛先ノードはdonor DUであり、第1のノードはアクセスIABノード、又はアクセスIABノードとIABドナー(中間IABノードと呼ばれる)との間の中間IABノードであり、送信元ノードはアクセスIABノードである。ここでのアクセスIABノードは、アップリンクデータパケットを送信する端末デバイスによりアクセスされるIABノードである。データパケットが端末デバイスに送信されるべきダウンリンクデータパケットである場合、宛先ノードはアクセスIABノードであり、第1のノードはdonor DU又は中間IABノードであり、送信元ノードはdonor DUである。ここでのアクセスIABノードは、ダウンリンクデータパケットを受信する端末デバイスによりアクセスされるノードである。代替として、データパケットが、IABノードに送信されるべきダウンリンクデータパケットである場合、宛先ノードは、IABノードの親ノードであり、第1のノードはdonor DU又は中間IABノードである。

バックホール適応プロトコル(Backhaul Adaptation Protocol, BAP)は、IABネットワークにおいて新たに導入されたプロトコル層である。BAPの主な機能は、IABネットワークにおいてルーティング及びベアラマッピングを完了することである。可能なプロトコルアーキテクチャが図２に示されている。BAP層は、IABドナーのDU側、中間IABノード、及びアクセスIABノードのMT側に存在し、BAP層は、RLCプロトコル層の上に位置する。さらに、中間IABノード(例えば、図２におけるIAB node1)のMT及びDUは、1つのバックホール適応プロトコルエンティティを共有してもよく、或いは、MT及びDUは、1つのバックホール適応プロトコルエンティティをそれぞれ有してもよい。

図３は、IABネットワーキングシナリオの概略図である。IAB node1の親ノードはDgNBであり、IAB node1はIAB node2及びIAB node3の親ノードであり、IAB node2及びIAB node3の双方はIAB node4の親ノードであり、IAB node5の親ノードはIAB node3である。UE1により送信されたアップリンクデータパケットは、1つ以上のIABノードを通じてDgNBに伝送され、次いで、DgNBは、アップリンクデータパケットをモバイルゲートウェイデバイス(例えば、5Gコアネットワークにおけるユーザプレーン機能ユニット)に送信する。モバイルゲートウェイデバイスからダウンリンクデータパケットを受信した後に、DgNBは、1つ以上のIABノードを通じてダウンリンクデータパケットをUE1に送信する。同様に、上記の説明は、UE2にも当てはまる。

UE1とDgNBとの間のデータパケット伝送について、2つのパスが存在する。具体的には、パス1はUE1→IAB node4→IAB node3→IAB node1→DgNBであり、パス2はUE1→IAB node4→IAB node2→IAB node1→DgNBである。

IAB node4はUE1のアクセスIABノードであり、IAB node3及びIAB node1はパス1上の中間IABノードであり、IAB node2及びIAB node1はパス2上の中間IABノードである。DgNBは宛先ノードである。

UE2とDgNBとの間のデータ送信について、3つの利用可能なパスが存在する。具体的には、パス3はUE2→IAB node4→IAB node3→IAB node1→DgNBであり、パス4はUE2→IAB node4→IAB node2→IAB node1→DgNBであり、パス5はUE2→IAB node5→IAB node2→IAB node1→DgNBである。

パス3上で、IAB node4はUE1のアクセスIABノードであり、IAB node3及びIAB node1は中間IABノードである。パス4上で、IAB node4はUE1のアクセスIABノードであり、IAB node2及びIAB node1は中間IABノードである。パス5上で、IAB node5はUE1のアクセスIABノードであり、IAB node2及びIAB node1は中間IABノードである。DgNBは宛先ノードである。

図３に示すIABネットワーキングシナリオは、単なる例であることが理解されるべきである。マルチホップ及びマルチコネクティビティネットワーキングをサポートするIABネットワークに、より多くの他の可能性が存在し、ここでは1つずつ列挙しない。

このことに基づいて、IABノードによるデータパケットのルーティングを実現するために、この出願は以下の実施形態を提供する。

［実施形態1］
この出願は、データパケットの宛先ノード識別子を決定するための方法を提供する。当該方法は、第1のノードが受信したデータパケットの宛先ノードのBAPアドレスを決定するために使用されてもよい。当該方法は、以下のいくつかの可能な設計を含むが、これらに限定されない。

可能な設計では、データパケットがアップリンクデータパケットである場合、第1のノードは、第1のノードのためにdonor CUにより構成された宛先ノードのBAPアドレスを、第1のノードにより受信されたデータパケットの宛先ノードとして使用し、アップリンクデータパケットの宛先ノードのBAPアドレスは、第1のノードのためにdonor CUにより構成される。

他の可能な設計では、データパケットがアップリンクデータパケットである場合、第1のノードは、宛先CU-CPと宛先ノードのBAPアドレスとの間のマッピング関係に基づいて、宛先ノードのBAPアドレスを決定する。宛先CU-CPと宛先ノード識別子との間のマッピング関係は、donor CUにより構成される。

例えば、データパケットがアップリンクデータパケットである場合、第1のノードは、宛先CU-UPのIPアドレスと宛先ノードのBAPアドレスとの間のマッピング関係に基づいて、宛先ノードのBAPアドレスを決定する。宛先CU-UPのIPアドレスと宛先ノード識別子との間のマッピング関係は、donor CUにより構成される。

更に他の可能な設計では、データパケットがアップリンクデータパケット又はダウンリンクデータパケットである場合、第1のノードは、UE識別子、UEベアラ識別子、GPRSトンネリングプロトコル・ユーザプレーン(GPRS Tunnelling Protocol User Plane, GTP-U)内のトンネルエンドポイント識別子、又はIPヘッダ内の差別化サービスコードポイント(differentiated code services point, DSCP)、フローラベル(flow label)若しくはトラフィッククラス(traffic class)のような、データパケットで搬送されたフィールドと、上記の識別子のうちいずれか1つと宛先ノードのBAPアドレスとの間のマッピング関係とに基づいて、宛先ノードのBAPアドレスを決定する。上記の識別子のうちいずれか1つと宛先ノードのBAPアドレスとの間のマッピング関係は、第1のノードのためにdonor CUにより構成される。

更に他の可能な設計では、データパケットがダウンリンクデータパケットである場合、第1のノードは、宛先ノードのIPアドレスと宛先ノードのBAPアドレスとの間のマッピング関係に基づいて、宛先ノードのBAPアドレスを決定する。ダウンリンクデータパケットが端末デバイスに送信されるとき、宛先ノードのIPアドレスは、端末デバイスによりアクセスされるIABノードのIPアドレスである。ダウンリンクデータパケットがIABノードに送信されるとき、宛先ノードのIPアドレスは、IABノードの親ノードのIPアドレスである。宛先ノードのIPアドレスと宛先ノードのBAPアドレスとの間のマッピング関係は、第1のノードのためにdonor CUにより構成される。一例では、データパケットがダウンリンクデータパケットである場合、第1のノードは、ダウンリンクデータパケットで搬送された宛先ノードのIPアドレスと、宛先ノードのIPアドレスと宛先ノードのBAPアドレスとの間の記憶されたマッピング関係とに基づいて、宛先ノードのBAPアドレスを決定する。任意選択で、データパケットがアップリンクデータパケットである場合、宛先ノードのBAPアドレスはdonor DUのBAP IDである。データパケットがダウンリンクデータパケットである場合、宛先ノードのBAPアドレスは、ダウンリンクデータパケットを受信する端末デバイスのアクセスIABノードのBAP ID、又はダウンリンクデータパケットを受信するIABノードの親ノードのBAP IDである。ここでの宛先ノードのBAPアドレスはまた、以下の識別子、すなわち、donor CUにより各IABノードに割り当てられたDU ID、donor CUにより各IABノードに割り当てられたMT ID、進化型ユニバーサル移動通信システム地上無線アクセスネットワークセルグローバル識別子(E-UTRAN cell global identifier, ECGI)、新無線セルグローバル識別子(NR cell global identifier, NCGI)、IABノードのIPアドレス、IAB DUのIPアドレス、又はIAB MTのIPアドレスに置き換えられてもよいことが理解されるべきである。

上記のいくつかの設計では、第1のノードは、宛先ノードのBAPアドレスを決定し、それにより、データパケットのルーティングを可能にする。さらに、異なるサービス要件を有するデータパケット又は異なる終端ノードを有するデータパケットについて、宛先ノードの異なるBAPアドレスが構成できる。このように、IABネットワークにおけるデータパケットオフローディングが実現できる。

［実施形態2］
この出願は、IABノードがデータパケットの宛先ノード識別子を再決定するための方法を更に提供する。当該方法は、第1のノードが受信したデータパケットの宛先ノードのBAPアドレスを再決定するために使用されてもよい。実施形態2は、単独で或いは実施形態1と組み合わせて使用されてもよいことが理解されるべきである。

当該方法は、以下のいくつかの可能な設計を含むが、これらに限定されない。

可能な設計では、donor CUは、第1のノードのために1つの第2のノードの識別子又は複数の第2のノードの識別子を構成する。第1のノードが、データパケットを宛先ノードに送信するためのルーティングパスの無線リンクが故障又は輻輳していると決定し、第1のノードが1つの第2のノードの識別子又は複数の第2のノードの識別子で構成されているとき、第1のノードは、1つの第2のノードの識別子又は複数の第2のノードの識別子のうち1つを、宛先ノードのBAPアドレスとして使用し、ルーティングを実行する。

他の可能な設計では、第1のノードにより受信されたデータパケットは、宛先ノードのBAPアドレスを含み、任意選択で、データパケットは、1つの第2のノードの識別子又は複数の第2のノードの識別子を更に含む。第1のノードが、データパケットを宛先ノードに送信するためのルーティングパスの無線リンクが故障又は輻輳していると決定し、受信したデータパケットが1つの第2のノードの識別子又は複数の第2のノードの識別子を含むとき、第1のノードは、1つの第2のノードの識別子又は複数の第2のノードの識別子のうち1つを、宛先ノードのBAPアドレスとして使用し、ルーティングを実行する。任意選択で、第1のノードは、代替として、受信したデータパケット内のBAPヘッダで搬送された宛先ノードのBAPアドレスを、第2のノードの識別子に置き換えるか、或いは、BAPヘッダを生成するときに第2のノードの識別子を宛先ノードのBAPアドレスとして使用する。

上記の2つの可能な設計について、第2のノードは、宛先ノードのバックアップ宛先ノードとして理解されてもよい。ここでの第2のノードはまた、第2の宛先ノードとも呼ばれてもよい。第1のノードが、データパケットを宛先ノードに送信するためのルーティングパスの無線リンクが故障又は輻輳していると決定する前に、第1のノードにより決定された宛先ノードはまた、第1の宛先ノードとも呼ばれてもよい。データパケットがアップリンクデータパケットである場合、第2のノードは、変更前の宛先ノードが属するIABドナーの他の分散ユニットである。データパケットがダウンリンクデータパケットである場合、第2のノードは、データパケットを受信する端末デバイスによりアクセスされる他のIABノード、又はデータパケットを受信するIABノードの他の親ノードである。

データパケットを宛先ノードに送信するためのルーティングパスの無線リンクが故障又は輻輳していることは、第1のノードと宛先ノードとの間の1ホップ又はマルチホップの無線バックホールリンク上のいずれかの1つ以上のホップ上で無線リンク障害又は輻輳が発生することを意味することが理解されるべきである。第1のノードがデータパケットを宛先ノードに送信するためのルーティングパス上の無線リンク障害又は輻輳を取得するための特定の解決策は、この実施形態では制限されなくてもよい。

第1のノードが、データパケットを宛先ノードに送信するためのルーティングパスの無線リンクが故障又は輻輳していると決定したとき、宛先ノードのBAPアドレスは変更される必要がないことが理解されるべきである。例えば、第1のノードが、第1のノードと宛先ノードとの間に複数のルーティングパスが存在すると決定し、第1のノードが、第1のノードと宛先ノードとの間の現在選択されているルーティングパス上で無線リンク障害又は輻輳が発生したと決定した場合、第1のノードは、第1のノードと宛先ノードとの間のルーティングパス以外のルーティングパスを選択してもよい。この場合、第1のノードは第2のノードを通じてルーティングを実行する必要はない。代替として、第1のノードは、無線リンクが回復するのを待機することを選択してもよい。この場合、第1のノードはまた、第2のノードを通じてルーティングを行う必要もない。

例えば、データパケットがアップリンクデータパケットである場合、図４に示すように、IAB node1は、ルーティングテーブルを照会することにより次ホップノード(IAB node2)情報を取得し、IAB node1とIAB node2との間のアップリンクバックホールリンク上で無線リンク障害(radio link failure, RLF)又は輻輳が発生したと決定してもよい。同じ宛先ノードgNB-DU1に到達できる他の(1つ以上の)ルーティングパス(図４に示すIAB node3を通過するパス)がルーティングテーブルに存在する場合、IAB node1は、宛先ノードのBAPアドレスを変更する必要はない。同じ宛先ノードgNB-DU1に到達できる他のルーティングパスがルーティングテーブルに存在しないが、gNB-DU2及びgNB-DU1が同じIAB donor(又はIAB donor CU-UP)に属する場合、IAB node1はgNB-DU2が新たな宛先ノードであると決定し、gNB-DU2の識別子を宛先ノードのBAPアドレスとして使用する。gNB-DU2及びgNB-DU1が同じIAB donor(又はIAB donor CU-UP)に属することは、IAB node1についてIAB donorにより構成されてもよい。代替として、IAB donorは、各宛先ノードのBAPアドレスについて1つ以上の代替宛先ノードのBAPアドレスを直接構成してもよい(例えば、gNB-DU1の識別子についてIAB donorにより構成された代替宛先ノードのBAPアドレスは、gNB-DU2の識別子である)。同じ宛先受信ノードgNB-DU1に到達できる他のルーティングパスがルーティングテーブルに存在せず、gNB-DU1と同じIAB donor(又はIAB donor CU-UP)に属するノードが存在しない場合、IAB node1は宛先ノードのBAPアドレスを変更せず、無線リンクが回復するのを待機する。

上記の実施形態において提供された方法によって、第1のノードが、宛先ノードにデータパケットを送信するためのルーティングパスの無線リンクが故障又は輻輳していると決定したとき、第1のノードは、データパケットの宛先ノードのBAPアドレスを再決定し、新たな宛先ノードのBAPアドレスに基づいてルーティングを実行してもよい。このように、データパケットは、無線リンクが回復するのを待機せずに、新たな宛先ノードに適時に送信でき、それにより、サービス待ち時間要件をより良く満たす。

［実施形態3］
この出願は、データパケットのルーティングパスを決定するための方法を提供する。当該方法は、第1のノードがデータパケットのルーティングパスを決定するために使用されてもよい。実施形態3は、単独で或いは実施形態1及び実施形態2のうち少なくとも1つと組み合わせて使用されてもよいことが理解されるべきである。

第1のノードと宛先ノードとの間に複数のルーティングパスが存在してもよく、データパケットのルーティングパスは、第1のノードと宛先ノードとの間の第1のパスである。第1のノードは、以下の方式で第1のパスを決定してもよいが、これに限定されない。

方式1:第1のパスは、第1のノードと宛先ノードの間の第1のデフォルトルーティングパスである。

第1のノードと宛先ノードとの間の第1のデフォルトルーティングパスは、第1のノードのためにdonor CUにより構成されてもよい。donor CUは、第1のノードのための第1のデフォルトルーティングパスとしてのルーティングパスを指定してもよい。

方式2:第1のパスは、第1のノードのルーティングテーブル内の第1のノードと宛先ノードの間の少なくとも1つのルーティングパスの中で最高の優先度を有するルーティングパスである。第1のノードのルーティングテーブル情報は、第1のノードのdonor CUにより構成される。

例えば、第1のノードのルーティングテーブルは、第1のノードと宛先ノードとの間の1つ以上のルーティングパスの優先度情報(priority value)を含む。最高の優先度を有するルーティングパスが存在する場合、当該ルーティングパスは第1のパスである。

方式3:第1のパスは、第1のノードによりバッファされたデータ量と予め設定された閾値との間の予め設定された関係に基づいて、第1のノードと宛先ノードとの間の複数のルーティングパスから第1のノードにより決定されたルーティングパスである。

例えば、バッファされたデータ量が予め設定された閾値以下である場合、第1のノードは、第1のノードと宛先ノードとの間のルーティングパスの中で最高の優先度を有するルーティングパスを第1のパスとして選択してもよい。バッファされたデータ量が予め設定された閾値よりも大きい場合、第1のノードは、第1のノードと宛先ノードとの間のルーティングパスの中で2番目に高い優先度を有するルーティングパスを第1のパスとして選択してもよい。上記の説明は単なる例であり、この出願において限定として使用されないことが理解されるべきである。第1のノードは、代替として、他のルーティングパスを選択してもよい。

方式4:第1のパスは、予め設定された比率情報に基づいて、第1のノードと宛先ノードとの間の複数のルーティングパスから第1のノードにより決定されたルーティングパスであり、予め設定された比率情報は、複数のパスのそれぞれに対応する伝送データパケットの数の比率情報である。

例えば、donor CUは、第1のノードと宛先ノードとの間の複数のルーティングパスについて予め設定された比率情報を構成する。第1のノードは、予め設定された比率情報に基づいて、複数のルーティングパスを通じてデータパケットを伝送する。例えば、第1のノードと宛先ノードの間に3つのルーティングパス、すなわち、パス1、パス2及びパス3が存在する。予め設定された比率情報は以下の通りであり、すなわち、パス1を通じて伝送されるデータパケットの数:パス2を通じて伝送されるデータパケットの数:パス3を通じて伝送されるデータパケットの数は2:3:5である。したがって、第1のノードは、予め設定された比率情報に基づいて、パス1、パス2及びパス3を通じてデータパケットを伝送する。

方式5:第1のパスは、データパケットで搬送された指示情報に基づいて第1のノードにより決定されたルーティングパスである。

例えば、データパケットがダウンリンクデータパケット又はアップリンクデータパケットである場合、第1のノードは、UE識別子、UEベアラ識別子、GTP-U内のトンネルエンドポイント識別子、又はIPヘッダ内のDSCP、フローラベル若しくはトラフィッククラスのような、データパケットで搬送されたフィールドに基づいて第1のパスを決定する。上記のフィールドと第1のパスとの間の関係は、CU-CPにより構成されてもよく、或いは、プロトコルにおいて予め定義されてもよい。

任意選択で、第1のパスのルーティングパス識別子は、第1のパス上の全てのIABノードのID情報を含んでもよく、或いは、第1のパスのルーティングパス識別子は、インデックスの形式でもよく、donor CUは、インデックスとルーティングパスとの間の関連付け関係を構成する必要がある。N個のパス識別子は、同じアクセスIABノードと同じ宛先ノードとの間のN個のルーティングパスに対応する。異なるアクセスIABノードと異なる宛先ノードとの間のルーティングパスは、同じルーティングパス識別子を再利用してもよい。代替として、各ルーティングパスは、全体のネットワーク又はCU内で固有のルーティングパス識別子を有する。

例えば、図３におけるIAB node4とDgNBとの間のルーティングパスについて、インデックスとルーティングパスとの間の関連付け関係は以下の通りである。パス1はIAB node4→IAB node3→IAB node1→DgNBに対応し、パス2はIAB node4→IAB node2→IAB node1→DgNBに対応し、パス3はIAB node4→IAB node3→IAB node1→DgNBに対応し、パス4はIAB node4→IAB node2→IAB node1→DgNBに対応する。IAB node5とDgNBとの間のルーティングパスについて、インデックスとルーティングパスとの間の関連付け関係は以下の通りである。パス1はIAB node5→IAB node2→IAB node1→DgNBに対応する。

他の例では、図３における各ルーティングパスは、グローバルに固有のパス識別子に対応してもよい。インデックスとルーティングパスとの間の関連付け関係は以下の通りである。パス1はIAB node4→IAB node3→IAB node1→DgNBに対応し、パス2はIAB node4→IAB node2→IAB node1→DgNBに対応し、パス3はIAB node4→IAB node3→IAB node1→DgNBに対応し、パス4はIAB node4→IAB node2→IAB node1→DgNBに対応し、パス5はIAB node5→IAB node2→IAB node1→DgNBに対応する。

任意選択で、アップリンクデータパケット又はダウンリンクデータパケットについて複製(duplication)機能が第1のノードに構成されている場合、第1のノードは、2つの複製データパケットについて第1のパス及び第3のパスをそれぞれ決定する必要がある。第1のパスは、2つの複製データパケットの中の1つのデータパケットのルーティングパスである。決定方法は、上記の実施形態に記載の方法と同じであり、詳細はここでは再び説明しない。第3のパスは、2つの複製データパケットの中の他のデータパケットのルーティングパスである。第1のノードは、以下の方式で第3パスを決定してもよいが、これに限定されない。

方式1:第3のパスは、第1のノードと宛先ノードの間の第2のデフォルトルーティングパスである。

第1のノードと宛先ノードとの間の第2のデフォルトルーティングパスは、第1のノードのためにdonor CUにより構成されてもよい。donor CUは、第1のノードのためのデフォルトパスとしてのルーティングパスを指定してもよい。任意選択で、第2のデフォルトルーティングパス及び第1のデフォルトルーティングパスは同時に構成されてもよい。

方式2:第3のパスは、第1のノードのルーティングテーブル内の第1のノードと宛先ノードの間のルーティングパスの中で3番目に高い優先度を有するルーティングパスである。第1のノードのルーティングテーブル情報は、第1のノードのdonor CUにより構成される。

例えば、第1のノードのルーティングテーブルは、第1のノードと宛先ノードとの間の1つ以上のルーティングパスの優先度情報(priority value)を含む。3番目に高い優先度を有するルーティングパスが存在する場合、当該ルーティングパスは第3のパスである。

上記の実施形態によって、第1のノードは、第1のノードと宛先ノードとの間のルーティングパスを決定し、第1のノードと宛先ノードとの間のルーティングパスに基づいてデータパケットを宛先ノードに送信してもよく、それにより、IABネットワークにおけるデータパケットオフローディングが実現できる。

［実施形態4］
この出願は、データパケットのルーティングパスを再決定するための方法を提供する。当該方法は、第1のノードがデータパケットのルーティングパスを再決定するために使用されてもよい。実施形態4は、単独で或いは実施形態1、実施形態2及び実施形態3のうち少なくとも1つと組み合わせて使用されてもよいことが理解されるべきである。

いくつかの可能なシナリオ(例えば、無線リンク障害又は輻輳)では、データパケットのルーティングパスは利用不可能である。この場合、第1のノードは、第1のノードと宛先ノードとの間の新たなルーティングパスを、データパケットのルーティングパスとして決定する必要がある。

例えば、第1のノードのルーティングテーブルは、第1のノードと宛先ノードとの間の複数のルーティングパスを含んでもよく、データパケットの現在のルーティングパスは、第1のノードと宛先ノードとの間の複数のルーティングパスの中で最高の優先度を有するルーティングパスでもよい。第1のノードが、最高の優先度を有するルーティングパスが利用不可能であると決定したとき、第1のノードは、2番目に高い優先度を有するルーティングパスを、データパケットのルーティングパスとして選択してもよい。

例えば、第1のノードのルーティングテーブルは、第1のノードと宛先ノードとの間の複数のルーティングパスを含んでもよい。第1のノードが、データパケットの現在のルーティングパスが利用不可能であると決定した場合、データパケットの現在のルーティングパス以外のルーティングパスが、第1のノードと宛先ノードとの間の複数のルーティングパスから、データパケットのルーティングパスとしてランダムに選択されてもよい。

第1のノードが、データパケットの現在のルーティングパスが利用不可能であると決定したとき、第1のノードは、データパケットのルーティングパスを上記の方式で再決定してもよいが、これに限定されないことが理解されるべきである。これは、ここでは単なる例であり、この出願に限定されない。

上記の実施形態によって、第1のノードが、データパケットのルーティングパスが利用不可能であると決定したとき、第1のノードは、第1のノードと宛先ノードとの間の新たなルーティングパスを、データパケットのルーティングパスとして再決定してもよい。このように、データパケットは、無線リンクが回復するのを待機せずに、他のルーティングパスを通じて宛先ノードに適時に送信でき、それにより、サービス待ち時間要件をより良く満たす。

［実施形態5］
この出願は、BAPヘッダフォーマットを指定するための方法を提供する。実施形態5は、単独で或いは実施形態1、実施形態2、実施形態3及び実施形態4のうち少なくとも1つと組み合わせて使用されてもよいことが理解されるべきである。

BAPヘッダは、データパケットの宛先ノードのBAPアドレス及び第1の情報を含む。第1の情報は、BAPヘッダがデータパケットのルーティングパス識別子を含むか否かを決定するために使用される。

BAPヘッダ内の第1の情報は、以下の2つの可能な設計を含んでもよいが、これらに限定されない。

可能な設計では、第1の情報はデータパケットのルーティングパス識別子である。データパケットのルーティングパス識別子が第1の値である場合、データパケットのルーティングパス識別子は無効である。言い換えると、データパケットを受信したノードにより読み取られたルーティングパス識別子が第1の値であるとき、ルーティングパス識別子は無視できる。上記の設計は、BAPヘッダが統一されたフォーマットを有し、データパケットのルーティングパス識別子が存在するか否かにかかわらず、BAPヘッダの長さが不変のままであることを確保できる。

例えば、図５ａに示すように、BAPヘッダは、宛先ノードのBAPアドレス(図５ａにおける宛先ノードのBAP ID)と、データパケットのルーティングパス識別子とを含む。データパケットのルーティングパス識別子が第1の値である場合、データパケットのルーティングパス識別子は無効であり、BAPヘッダがデータパケットのルーティングパス識別子を含まないことを示す。

他の可能な設計では、第1の情報は指示フィールドを含む。指示フィールドは、BAPヘッダがデータパケットのルーティングパス識別子を含むか否かを示すために使用される。指示フィールドが、BAPヘッダがデータパケットのルーティングパス識別子を含むことを示す場合、第1の情報は、データパケットのルーティングパス識別子を更に含む。上記の設計は、BAPヘッダがデータパケットのルーティングパス識別子を含まないとき、ヘッダオーバヘッドを低減できる。

例えば、図５ｂに示すように、BAPヘッダは、1ビットの指示フィールドと、宛先ノードのBAPアドレス(図５ｂにおける宛先ノードのBAP ID)とを含む。指示フィールドが「1」を示す場合、BAPヘッダは、データパケットのルーティングパス識別子を更に含む。指示フィールドが「0」を示す場合、BAPヘッダは、データパケットのルーティングパス識別子を含まない。

任意選択で、BAPヘッダに含まれる宛先ノードのBAPアドレスは、宛先ノードのBAP ID又はBAPアドレスでもよく、或いは、任意選択で、BAPヘッダは、送信元ノードのBAPアドレス、例えば、送信元ノードのBAPアドレスを更に含んでもよい。

任意選択で、BAPヘッダに含まれるルーティングパス識別子は、宛先ノードについての固有のルーティングパス識別子でもよい。代替として、BAPヘッダに含まれるルーティングパス識別子は、送信元ノード及び宛先ノードについての固有のルーティングパス識別子でもよい。この場合、BAPヘッダは、送信元ノードのBAPアドレス、例えば、送信元ノードのBAP ID又はBAPアドレスを更に含む。

例えば、IABネットワークにおいて、IAB nodeAは、N個のルーティングパスの宛先ノードでもよく、N個のルーティングパスは、IAB nodeAと複数のdonor DUとの間のルーティングパスである。IAB nodeAとdonor DUのうち1つとの間にM個のパスが存在し、MはN以下であり、M及びNは正の整数である。データパケットがダウンリンクデータパケットである場合、BAPヘッダに含まれるルーティングパス識別子は、IAB nodeAを宛先ノードとして使用する固有のルーティングパス識別子、又はIAB nodeAを宛先ノードとして使用し且つdonor DUのうち1つを送信元ノードとして使用する固有のルーティングパス識別子でもよい。

任意選択で、BAPヘッダは、ルーティングパス識別子フィールドの長さ指示を更に含む。BAPヘッダに含まれるルーティングパス識別子に対応するフィールドは、IABノードによって変化してもよい。さらに、ルーティングパス識別子に対応するフィールドの長さは、ルーティングパスの数、又はルーティングパス識別子が送信元ノードのBAP ID又はBAPアドレスを含むか否かに依存する。

例えば、IABネットワークにおいて、IAB nodeAは、N個のルーティングパスの宛先ノードでもよく、N個のルーティングパスは、IAB nodeAと複数のdonor DUとの間のルーティングパスである。IAB nodeAとdonor DUのうち1つとの間にM個のパスが存在し、MはN以下であり、M及びNは正の整数である。データパケットがダウンリンクデータパケットである場合、BAPヘッダ内のルーティングパス識別子フィールドの長さは、以下の2つの場合で異なる。したがって、BAPヘッダは、ルーティングパス識別子フィールドの長さ指示を更に含んでもよい。

場合1:BAPヘッダに含まれるルーティングパス識別子は、IAB nodeAを宛先ノードとして使用する固有のルーティングパス識別子である。

場合2:BAPヘッダに含まれるルーティングパス識別子は、IAB nodeAを宛先ノードとして使用し且つdonor DUのうち1つを送信元ノードとして使用する固有のルーティングパス識別子である。

他の例では、IABネットワークにおいて、IAB nodeAはN個のルーティングパスの宛先ノードでもよく、IAB nodeBはK個のルーティングパスの宛先ノードでもよく、KはNと等しくなく、K及びNは正の整数である。データパケットがダウンリンクデータパケットである場合、BAPヘッダ内のルーティングパス識別子フィールドの長さは、以下の2つの場合で異なる。したがって、BAPヘッダは、ルーティングパス識別子フィールドの長さ指示を更に含んでもよい。

場合1:BAPヘッダに含まれるルーティングパス識別子は、IAB nodeAを宛先ノードとして使用する固有のルーティングパス識別子である。

場合2:BAPヘッダに含まれるルーティングパス識別子は、IAB nodeBを宛先ノードとして使用する固有のルーティングパス識別子である。

任意選択で、BAPヘッダは、宛先ノードのBAPアドレスのフィールドの長さ指示を更に含む。BAPヘッダに含まれる宛先ノードのBAPアドレスに対応するフィールドは、IABノードによって変化してもよく、或いは、アップリンク及びダウンリンク伝送方向によって変化してもよい。例えば、ダウンリンクデータパケットについて、ダウンリンクデータパケットに対応する宛先ノードのBAPアドレスは、端末デバイスによりアクセスされるIABノードのBAPアドレスである。全てのアップリンクデータパケットの宛先ノードのBAPアドレスは、donor DUのBAPアドレスである。一般的に、IABノードの数は、donor DUの数よりもはるかに大きい。代替として、BAPヘッダは、データパケットのアップリンク/ダウンリンク指示を更に含む。宛先ノードのBAPアドレスのフィールドの長さは、アップリンク/ダウンリンク指示情報により暗示的に決定される。

donor DU又は各IABノードがデータパケットのルーティングパス識別子を含むか、BAPヘッダ内の送信元ノードのBAPアドレスを含むかは、構成により決定されてもよいことが理解されるべきである。構成は、donor CU-CPにより送信されるRRCメッセージ(IABノードのMT部を構成するために使用される)又はF1-APメッセージ(donor DU又はIABノードのDU部を構成するために使用される)で搬送されてもよい。

図６を参照する。この出願の実施形態は、ルーティング方法を提供する。当該方法は以下のステップを含む。

S601:第1のノードはデータパケットを受信する。

例えば、データパケットがアップリンクデータパケットであり、第1のノードがアップリンクデータパケットを送信する端末デバイスのアクセスIABノードである場合、第1のノードは、端末デバイスからアップリンクデータパケットを受信する。データパケットがダウンリンクデータパケットであり、第1のノードがdonor CUである場合、第1のノードは、CU-UPからダウンリンクデータパケットを受信する。データパケットがアップリンクデータパケットであり、第1のノードが中間IABノードである場合、第1のノードは、前ホップIABノードからデータパケットを受信し、ここでの前ホップIABノードは、第1のノードの子ノードである。データパケットがダウンリンクデータパケットであり、第1のノードが中間IABノードである場合、第1のノードは、前ホップIABノードからデータパケットを受信し、ここでの前ホップIABノードは、第1のノードの親ノードである。

S602:第1のノードは、データパケット内のBAPヘッダ及び次ホップノードを決定する。

BAPヘッダは、データパケットの宛先ノードのBAPアドレス及び第1の情報を含む。第1の情報は、BAPヘッダがデータパケットのルーティングパス識別子を含むか否かを決定するために使用される。

第1のノードがデータパケット内のBAPヘッダを決定することは以下の場合を含む。

場合1:第1のノードは、BAPヘッダをデータパケットに追加する。

一例では、データパケットがアップリンクデータパケットであり、第1のノードがアップリンクデータパケットを送信する端末デバイスのアクセスIABノードである場合、第1のノードは、BAPヘッダをデータパケットに追加する。

他の例では、データパケットがダウンリンクデータパケットであり、第1のノードがdonor CUである場合、第1のノードは、BAPヘッダをデータパケットに追加する。

可能な設計では、第1のノードが中間IABノードである場合、第1のノードは、データパケットからBAPヘッダを削除し、次いで、BAPヘッダをデータパケットに再び追加する。

例えば、ヘッダの追加及びヘッダの削除は、2つのBAPエンティティにより完了され、BAP ID及び/又はパスID(すなわち、データパケットのルーティングパス識別子)の層間の交換を更に必要としてもよい。例えば、ダウンリンクデータパケットについて、IABノードのMTのBAPが親ノードからデータパケットを受信したとき、BAPヘッダが最初に削除され、IABノードのMTがデータパケットをIABノードのDUに送信し、データパケットがDUのBAP層に到達したとき、BAPヘッダがDUのBAP層において再び追加される。

場合2:第1のノードは、データパケット内のBAPヘッダを変更する。

場合2は、一般的に、第1のノードが中間IABであるシナリオについてのものであることが理解されるべきである。BAPヘッダが宛先ノードのBAPアドレス及びデータパケットのルーティングパス識別子を含む場合、中間IABノードは、実施形態1～4において提供される方法を使用することにより、宛先ノードのBAPアドレス及びデータパケットのルーティングパスを決定してもよい。決定された宛先ノードのBAPアドレス及びデータパケットのルーティングパスが、宛先ノードのBAPアドレス及び現在のBAPヘッダ内のデータパケットのルーティングパスと同じである場合、中間IABノードは、データパケットのBAPヘッダを変更する必要はない。同様に、BAPヘッダが宛先ノードのBAPアドレスを含むが、データパケットのルーティングパス識別子を含まない場合、中間IABノードは、実施形態1において提供される方法を使用することにより、宛先ノードのBAPアドレスを決定してもよい。決定された宛先ノードのBAPアドレスが、現在のBAPヘッダ内の宛先ノードのBAPアドレスと同じである場合、中間IABノードは、データパケットのBAPヘッダを変更する必要はない。代替として、中間IABノードが、パケットのルーティングパスの無線リンクが故障又は輻輳していると決定した場合、中間IABノードは、新たな宛先ノードを再決定し、新たな宛先ノードのBAPアドレスを宛先ノードのBAPアドレスとして使用する必要があってもよく、データパケットの新たなルーティングパスを再決定する必要があってもよい。詳細については、実施形態1～4を参照する。

特に、BAPヘッダがデータパケットのルーティングパス識別子を含む場合、第1のノードは、決定されたデータパケットの新たなルーティングパスを使用することによりBAPヘッダを変更すること、第1の情報内のデータパケットのルーティングパス識別子を第1の値に変更すること、又はBAPヘッダがデータパケットのルーティングパス識別子を含まないことを示すように第1の情報の指示フィールドを変更することを選択してもよい。

場合3:第1のノードはBAPヘッダを使用し続ける。

一例では、アップリンクデータパケット又はダウンリンクデータパケットにかかわらず、第1のノードが中間IABノードである場合、前ホップノードから第1のノードにより受信されたデータパケットはBAPヘッダを含み、第1のノードは、データパケットを次ホップノードに伝送するときにBAPヘッダを使用し続ける。

第1のノードは、データパケット内のBAPヘッダと、BAPヘッダ及びルーティングテーブルにおける共通フィールドとに基づいて、データパケットのルーティングパス上の第1のノードの次ホップノードを決定する。第1のノードが次ホップノードを決定することは、以下のシナリオを含むが、これらに限定されない。

シナリオ1:BAPヘッダは、宛先ノードのBAPアドレス及びデータパケットのルーティングパス識別子を含むか、或いは、第1のノードが、実施形態1～4に従って、宛先ノードのBAPアドレス及びデータパケットのルーティングパス識別子を決定している。

第1のノードのルーティングテーブルが宛先ノードのBAPアドレス、宛先ノードに対応する次ホップノード、及び宛先ノードに対応するルーティングパス識別子を含む場合、第1のノードは、宛先ノードのBAPアドレス及びデータパケットのルーティングパス識別子に基づいて、1つの次ホップノードを一意に決定してもよい。

第1のノードのルーティングテーブルが、宛先ノードのBAPアドレス及び宛先ノードに対応する次ホップノードを含むが、宛先ノードに対応するルーティングパス識別子を含まない場合、以下の2つの場合が存在する。宛先ノードが1つの次ホップノードのみに対応する場合、第1のノードは、1つの次ホップノードを一意に決定してもよい。宛先ノードが複数の次ホップノードに対応する場合、第1のノードは、選択動作を実行する必要があり、すなわち、複数の次ホップノードから1つの次ホップノードを選択する必要がある。特定の選択動作は限定されなくてもよい。例えば、第1のノードは、各次ホップノードに対応する優先度パラメータに基づいて、最高の優先度を有する次ホップノードを選択してもよい。donor CUは、第1のノードの次ホップノード毎に優先度パラメータを構成してもよい。次ホップノードの数がNであると仮定する。N個の次ホップノードの中の第iの次ホップノードの優先度パラメータは、N個の次ホップノードの中の第iの次ホップノードの優先度を示すために使用される。

任意選択で、BAPヘッダが宛先ノードのBAPアドレス及びデータパケットのルーティングパス識別子を含むが、宛先ノードのBAPアドレスに対応するルーティングパス識別子がルーティングテーブルに見つからない場合、第1のノードは、BAPヘッダからルーティングパス識別子を削除してもよく、或いは、ルーティングパス識別子を無効にするために、BAPヘッダ内のルーティングパス識別子を第1の値に設定してもよい。
してもよい。

シナリオ2:BAPヘッダは、宛先ノードのBAPアドレスを含むが、データパケットのルーティングパス識別子を含まないか、或いは、第1のノードは、実施形態1及び2に従って宛先ノードのBAPアドレスを決定している。

第1のノードのルーティングテーブルは、宛先ノードのBAPアドレス及び宛先ノードに対応する次ホップノードを含む。宛先ノードが1つの次ホップノードのみに対応する場合、第1のノードは、1つの次ホップノードを一意に決定してもよい。宛先ノードが複数の次ホップノードに対応する場合、第1のノードは、選択動作を実行する必要があり、すなわち、複数の次ホップノードから1つの次ホップノードを選択する必要がある。特定の選択動作は限定されなくてもよい。例えば、第1のノードは、各次ホップノードに対応する優先度パラメータに基づいて、最高の優先度を有する次ホップノードを選択してもよい。

シナリオ3:第1のノードは、実施形態1～4に従って、宛先ノードのBAPアドレス及びデータパケットのルーティングパス識別子を決定している。

第1のノードのルーティングテーブルが宛先ノードのBAPアドレス、宛先ノードに対応する次ホップノード、及び宛先ノードに対応するルーティングパス識別子を含む場合、第1のノードは、決定された宛先ノードのBAPアドレス及びデータパケットのルーティングパス識別子に基づいて、1つの次ホップノードを一意に決定してもよい。

第1のノードのルーティングテーブルが、宛先ノードのBAPアドレス及び宛先ノードに対応する次ホップノードを含むが、宛先ノードに対応するルーティングパス識別子を含まない場合、以下の2つの場合が存在する。宛先ノードが1つの次ホップノードのみに対応する場合、第1のノードは、1つの次ホップノードを一意に決定してもよい。宛先ノードが複数の次ホップノードに対応する場合、第1のノードは、選択動作を実行する必要があり、すなわち、複数の次ホップノードから1つの次ホップノードを選択する必要がある。特定の選択動作は限定されなくてもよい。例えば、第1のノードは、各次ホップノードに対応する優先度パラメータに基づいて、最高の優先度を有する次ホップノードを選択してもよい。

シナリオ4:第1のノードは、実施形態1及び2に従って、宛先ノードのBAPアドレスを決定している。第1のノードのルーティングテーブルは、宛先ノードのBAPアドレス及び宛先ノードに対応する次ホップノードを含む。宛先ノードが1つの次ホップノードのみに対応する場合、第1のノードは、1つの次ホップノードを一意に決定してもよい。宛先ノードが複数の次ホップノードに対応する場合、第1のノードは、選択動作を実行する必要があり、すなわち、複数の次ホップノードから1つの次ホップノードを選択する必要がある。特定の選択動作は限定されなくてもよい。例えば、第1のノードは、各次ホップノードに対応する優先度パラメータに基づいて、最高の優先度を有する次ホップノードを選択してもよい。

シナリオ5:第1のノードのルーティングテーブルが構成されていないか、第1のノードのルーティングテーブルが宛先ノードに対応する次ホップノードを含まないか、或いは、BAPヘッダが宛先ノードのBAPアドレスを含まず、第1のノードが1つの次ホップノードのみを有する場合、第1のノードは、データパケットを固有の次ホップノードに直接ルーティングする。

上記のシナリオ1～シナリオ5は単なる例であり、この出願では限定されないことが理解されるべきである。さらに、第1のノードがデータパケット内のBAPヘッダ及び次ホップノードを決定する順序は、この出願では限定されない。

S603:第1のノードは、BAPヘッダを含むデータパケットをS602において決定された次ホップノードに送信する。

第1のノードは、決定された次ホップノードに基づいて、BAPヘッダを含むデータパケットを次ホップノードに伝送する。次ホップノードは、BAPヘッダを含むデータパケットが宛先ノードに送信されるまで、S601及びS602を繰り返してもよい。BAPヘッダを含むデータパケットを受信した後に、宛先ノードは、BAPヘッダ内の宛先ノードのBAPアドレスを読み取り、宛先ノードが宛先ノードであると決定し、BAPヘッダを削除してもよい。任意選択で、宛先ノードは、BAPヘッダ内の第1の情報を読み取ってもよく、或いは、BAPヘッダ内の第1の情報を読み取るのをスキップしてもよい。

第1のノードがデータパケットの宛先ノードを決定するための方法については、実施形態1及び2の内容に参照が行われてもよく、第1のノードがデータパケットのルーティングパスを決定するための方法については、実施形態3及び4の内容に参照が行われてもよいことが理解されるべきである。詳細は、ここでは再び説明しない。

さらに、上記の実施形態はまた、異なるIABノードの間のルーティングに適用されてもよいことが理解されるべきである。例えば、図３に示すように、IAB node4はデータパケットを生成し、データパケットの宛先ノードはIAB node1である。次いで、IAB node4は、BAPヘッダをデータパケットに追加し、次ホップノードがIAB node2であると決定し、BAPヘッダを含むデータパケットをIAB node2に送信する。IAB node2は、BAPヘッダが変更される必要がないと決定し、BAPヘッダに基づいて次ホップノードがIAB node1であると決定し、BAPヘッダを含むデータパケットをIAB node1に送信する。IAB node1は、BAPヘッダを読み取り、IAB node1が宛先ノードであると決定し、次いで、BAPヘッダを削除してデータパケットを解析する。

上記の方法によって、データパケットを受信した後に、第1のノードは、データパケット内のBAPヘッダを決定し、BAPヘッダに基づいてBAPヘッダを含むデータパケットを宛先ノードに送信する。このように、データパケットのルーティングが可能になり、それにより、IABネットワークにおけるデータパケットオフローディングを実現する。

上記の実施形態に基づいて、IABアップリンク伝送のためのルーティング解決策及びIABダウンリンク伝送のためのルーティング解決策について詳細に説明する。

図７及び図８は、IABアップリンク伝送のためのルーティング解決策の概略図である。

S701:UEは、データパケットを、UEによりアクセスされるIAB node1に送信する。

S702:IABノード1は、BAPヘッダをデータパケットに追加する。

BAPヘッダは、donor DUのBAP ID及び第1の情報を含み、第1の情報は指示フィールドを含み、指示フィールドは「1」を示し、第1の情報はデータパケットのルーティングパス識別子を更に含む。

具体的には、IAB node1は、donor DUのBAP IDを決定するために、IAB node1のIPアドレスと、IAB node1のIPアドレスとdonor DUのBAP IDとの間のマッピング関係とを決定する。

データパケットのルーティングパスは、IAB node1とdonor DUとの間の第1のパスであり、ここでの第1のパスは、IAB node1のルーティングテーブル内で、IAB node1とdonor DUとの間のルーティングパスの中で最高の優先度を有するルーティングパスでもよい。

S703:IAB node1は、次ホップノードを決定する。

具体的には、IAB node1のルーティングテーブルは、donor DUのBAP ID、donor DUに対応する次ホップノード、及びdonor DUに対応するルーティングパス識別子を含む。したがって、IAB node1は、donor DUのBAP ID及びデータパケットのルーティングパス識別子に基づいて、1つの次ホップノード、すなわち、IAB node2を一意に決定してもよい。

S704:IAB node1は、BAPヘッダを含むデータパケットをIAB node2に送信する。

S705:IAB node2は、データパケットからBAPヘッダを削除し、次いで、BAPヘッダを再び追加する。

BAPヘッダは、donor DUのBAP ID及び第1の情報を含み、第1の情報は指示フィールドを含み、指示フィールドは「1」を示し、第1の情報はデータパケットのルーティングパス識別子を更に含む。

具体的には、IAB node2は、donor DUのBAP IDを決定するために、IAB node1のIPアドレスと、IAB node1のIPアドレスとdonor DUのBAP IDとの間のマッピング関係とを決定する。

データパケットのルーティングパスは、IAB node2とdonor DUとの間の第1のパスであり、ここでの第1のパスは、IAB node2のルーティングテーブル内で、IAB node2とdonor DUとの間のルーティングパスの中で最高の優先度を有するルーティングパスでもよい。

S706:IAB node2は、次ホップノードを決定する。

具体的には、IAB node2のルーティングテーブルは、donor DUのBAP ID、donor DUに対応する次ホップノード、及びdonor DUに対応するルーティングパス識別子を含む。したがって、IAB node2は、donor DUのBAP ID及びデータパケットのルーティングパス識別子に基づいて、1つの次ホップノード、すなわち、donor DUを一意に決定してもよい。

S707:IAB node2は、BAPヘッダを含むデータパケットをdonor DUに送信する。

S708:donor DUは、BAPヘッダを読み取り、donor DUが宛先ノードであると決定し、BAPヘッダを削除し、次いで、データパケットをdonor CU-UPに送信する。

図９及び図１０は、IABダウンリンク伝送のためのルーティング解決策の概略図である。

S901:donor CU-UPは、有線伝送を通じてデータパケットをdonor DUに伝送する。

S902:donor DUは、BAPヘッダをデータパケットに追加する。

BAPヘッダは、IAB node1のBAP ID及び第1の情報を含み、第1の情報はデータパケットのルーティングパス識別子であり、データパケットのルーティングパス識別子は第1の値であり、データパケットのルーティングパス識別子を無効にすることを示す。

donor DUは、IAB node1のIPアドレスと、IAB node1のIPアドレスとIAB node1のBAP IDとの間のマッピング関係とに基づいて、IAB node1のBAP IDを決定する。

S903:donor DUは、次ホップノードを決定する。

donor DUのルーティングテーブルは、IAB node1のBAP ID及びIAB node1に対応する次ホップノードを含む。ここで、IAB node1は、1つの次ホップノード、すなわち、IAB node3に対応する。したがって、donor DUは、IAB node3が次ホップノードであると決定する。

S904:donor DUは、BAPヘッダを含むデータパケットをIAB node3に送信する。

S905:IAB node3は、IAB node3とIAB node1との間の無線リンクが故障したと決定し、次いで、IAB node2のBAP IDを宛先ノードのBAPアドレスとして使用することにより、BAPヘッダを変更する。

データパケットを受信するUEによりアクセスされるIABノードは、IAB node1及びIAB node2を含む。

S906:IAB node3は、次ホップノードを決定する。

具体的には、IAB node3のルーティングテーブルは、IAB node2のBAP ID及びIAB node2に対応する次ホップノードを含む。したがって、IAB node3は、IAB node2のBAP IDに基づいて、1つの次ホップノード、すなわち、IAB node2を決定してもよい。

S907:IAB node3は、BAPヘッダを含むデータパケットをIAB node2に送信する。

S908:IAB node2は、BAPヘッダを読み取り、IAB node2が宛先ノードであると決定し、BAPヘッダを削除し、データパケットを特定のUEに送信する。

例えば、IAB node2は、GTP-U内のトンネルエンドポイントID(tunnel end point ID, TEID)に基づいて宛先UEを決定する。

この出願において提供される上記の実施形態では、この出願の実施形態において提供される通信方法の様々な解決策が、各ネットワークエレメント及びネットワークエレメントの間の相互作用の観点から別々に記載されている。上記の機能を実現するために、送信元ノード、ターゲットノード又は第1のノードのような各ネットワークエレメントは、各機能を実行するための対応するハードウェア構造及び/又はソフトウェアモジュールを含むことが理解され得る。当業者は、この明細書に開示の実施形態に記載された例のユニット及びアルゴリズムステップと組み合わせて、この出願がハードウェア又はハードウェアとコンピュータソフトウェアとの組み合わせにより実現できることを容易に認識すべきである。機能がハードウェアにより実行されるかコンピュータソフトウェアにより駆動されるハードウェアにより実行されるかは、技術的解決策の特定の用途及び設計制約条件に依存する。当業者は、特定の用途毎に、記載の機能を実現するために異なる方法を使用し得るが、実現方式がこの出願の範囲を超えるものであると考えられるべきではない。

上記の概念と同じように、図１１に示すように、この出願の実施形態は、装置1100を更に提供する。装置1100は、トランシーバユニット1102及び処理ユニット1101を含む。

一例では、装置1100は、上記の方法において第1のノードの機能を実現するように構成される。装置はIABノードでもよく或いはIABノード内のチップでもよい。代替として、装置はdonor DUでもよく或いはdonor DU内のチップでもよい。トランシーバユニット1102は、データパケットを受信する。処理ユニット1101は、データパケット内のバックホール適応プロトコル(BAP)ヘッダを決定する。BAPヘッダは、データパケットの宛先ノードのBAPアドレス及び第1の情報を含む。第1の情報は、BAPヘッダがデータパケットのルーティングパス識別子を含むか否かを決定するために使用される。処理ユニット1101は、トランシーバユニット1102を通じて、BAPヘッダに基づいてBAPヘッダを含むデータパケットを宛先ノードに送信する。

処理ユニット1101及びトランシーバユニット1102の特定の実行プロセスについては、上記の実施形態における説明を参照する。この出願のこの実施形態におけるモジュールへの分割は例であり、単なる論理的な機能分割であり、実際の実現方式の中で他の分割でもよい。さらに、この出願の実施形態における機能モジュールは、1つのプロセッサに統合されてもよく、或いは、モジュールのそれぞれは物理的に単独で存在してもよく、或いは、2つ以上のモジュールが1つのモジュールに統合されてもよい。統合されたモジュールは、ハードウェアの形式で実現されてもよく、或いは、ソフトウェア機能モジュールの形式で実現されてもよい。

他の任意選択の変形では、装置はチップシステムでもよい。この出願のこの実施形態では、チップシステムは、チップを含んでもよく、或いは、チップ及び他の個別部品を含んでもよい。例えば、装置はプロセッサ及びインタフェースを含み、インタフェースは入力/出力インタフェースでもよい。プロセッサは、処理ユニット1101の機能を実行し、インタフェースは、トランシーバユニット1102の機能を実行する。装置は、メモリを更に含んでもよい。メモリは、プロセッサ上で実行できるプログラムを記憶するように構成される。プログラムを実行したとき、プロセッサは、上記の実施形態における方法を実現する。

上記の概念と同じように、図１２に示すように、この出願の実施形態は、装置1200を更に提供する。装置1200は、通信インタフェース1201、少なくとも1つのプロセッサ1202及び少なくとも1つのメモリ1203を含む。通信インタフェース1201は、伝送媒体を使用することにより他のデバイスと通信するように構成され、それにより、装置1200において使用される装置が他のデバイスと通信してもよい。メモリ1203は、コンピュータプログラムを記憶するように構成される。プロセッサ1202は、メモリ1203に記憶されたコンピュータプログラムを呼び出し、通信インタフェース1201を通じてデータを送信及び受信し、上記の実施形態における方法を実現する。

例えば、装置が第1のノードであるとき、メモリ1203は、コンピュータプログラムを記憶するように構成される。プロセッサ1202は、メモリ1203に記憶されたコンピュータプログラムを呼び出し、通信インタフェース1201を通じて、上記の実施形態においてネットワークデバイスにより実行される方法を実行する。この出願のこの実施形態では、通信インタフェース1201は、トランシーバ、回路、バス、モジュール又は他のタイプの通信インタフェースでもよい。プロセッサ1202は、汎用プロセッサ、デジタルシグナルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ若しくは他のプログラマブルロジックデバイス、ディスクリートゲート若しくはトランジスタ論理デバイス、又はディスクリートハードウェアコンポーネントでもよく、この出願の実施形態において開示される方法、ステップ及び論理ブロック図を実現又は実行してもよい。汎用プロセッサは、マイクロプロセッサ、いずれかの従来のプロセッサ等でもよい。この出願の実施形態を参照して開示される方法のステップは、ハードウェアプロセッサにより直接に実行及び完了されてもよく、或いは、プロセッサ内のハードウェア及びソフトウェアモジュールの組み合わせを使用することにより実行及び完了されてもよい。メモリ1203は、不揮発性メモリ、例えば、ハードディスクドライブ(hard disk drive, HDD)又はソリッドステートドライブ(solid-state drive, SSD)でもよく、或いは、揮発性メモリ(volatile memory)、例えば、ランダムアクセスメモリ(random-access memory, RAM)でもよい。メモリは、命令構造又はデータ構造の形式で想定されるプログラムコードを搬送又は記憶でき且つコンピュータによりアクセスできるいずれかの他の媒体であるが、これに限定されない。この出願のこの実施形態におけるメモリは、代替として、記憶機能を実現できる回路又は他のいずれかの装置でもよい。メモリ1203は、プロセッサ1202に結合される。この出願のこの実施形態における結合は、電気形式、機械形式又は他の形式の装置、ユニット又はモジュールの間の間接結合又は通信接続でもよく、装置、ユニット又はモジュールの間の情報交換のために使用される。他の実現方式では、メモリ1203は、代替として、装置1200の外側に位置してもよい。プロセッサ1202は、メモリ1203と協働してもよい。プロセッサ1202は、メモリ1203に記憶されたプログラム命令を実行してもよい。代替として、少なくとも1つのメモリ1203のうち少なくとも1つはプロセッサ1202に含まれてもよい。通信インタフェース1201とプロセッサ1202とメモリ1203との間の接続媒体は、この出願のこの実施形態では限定されない。例えば、図１２において、この出願のこの実施形態では、メモリ1203、プロセッサ1202及び通信インタフェース1201は、バスを使用することにより接続されてもよい。バスは、アドレスバス、データバス、制御バス等に分類されてもよい。

図１１に示す実施形態における装置は、図１２に示す装置1200を使用することにより実現されてもよいことが理解され得る。具体的には、処理ユニット1101は、プロセッサ1202により実現されてもよく、トランシーバユニット1102は、通信インタフェース1201により実現されてもよい。

この出願の実施形態は、コンピュータ読み取り可能記憶媒体を更に提供する。コンピュータ読み取り可能記憶媒体は、コンピュータプログラムを記憶する。コンピュータプログラムがコンピュータ上で実行されたとき、コンピュータは、上記の実施形態における方法を実行することが可能になる。

この出願の実施形態における方法の全部又は一部は、ソフトウェア、ハードウェア、ファームウェア又はこれらのいずれかの組み合わせを使用することにより実現されてもよい。ソフトウェアが実施形態を実現するために使用されるとき、実施形態の全部又は一部は、コンピュータプログラム製品の形式で実現されてもよい。コンピュータプログラム製品は、1つ以上のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータ上にロードされて実行されたとき、本発明の実施形態による手順又は機能が全部又は一部生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、ネットワークデバイス、ユーザ装置又は他のプログラム可能装置でもよい。コンピュータ命令は、コンピュータ読み取り可能記憶媒体に記憶されてもよく、或いは、コンピュータ読み取り可能記憶媒体から他のコンピュータ読み取り可能記憶媒体に伝送されてもよい。例えば、コンピュータ命令は、有線(例えば、同軸ケーブル、光ファイバ又はデジタル加入者線(digital subscriber line, 略称DSL))又は無線(例えば、赤外線、無線又はマイクロ波)方式で、ウェブサイト、コンピュータ、サーバ又はデータセンタから他のウェブサイト、コンピュータ、サーバ又はデータセンタに伝送されてもよい。コンピュータ読み取り可能記憶媒体は、コンピュータによりアクセス可能ないずれかの使用可能媒体、又は1つ以上の使用可能媒体を統合するサーバ又はデータセンタのようなデータ記憶デバイスでもよい。使用可能媒体は、磁気媒体(例えば、フロッピーディスク、ハードディスク又は磁気テープ)、光媒体(例えば、デジタルビデオディスク(digital video disc, 略称DVD))、半導体媒体(例えば、ソリッドステートドライブSolid State Disk SSD)等でもよい。

上記の実施形態は、単にこの出願の技術的解決策を詳細に説明するために使用される。上記の実施形態の説明は、単に本発明の実施形態における方法の理解を助けることを意図しており、本発明の実施形態に対する限定として解釈されないものとする。当業者により容易に理解される変形又は置換は、本発明の実施形態の保護範囲に含まれるものとする。

［関連出願への相互参照］
この出願は、2019年8月15日に中国国家知識産権局に出願された「ROUTING METHOD AND APPARATUS」という名称の中国特許出願第201910755511.7号に対する優先権を主張する。

Claims (22)

1. アップリンクデータ伝送方法であって、
   第1のノードにより、ドナー集約ユニット(donor CU)により構成された宛先集約ユニット・ユーザプレーン(CU-UP)のインターネットプロトコル(IP)アドレスと宛先ノードのバックホール適応プロトコル(BAP)アドレスとの間のマッピング関係を取得するステップであり、前記第1のノードは統合アクセス及びバックホール(IAB)ノードである、ステップと、
   前記第1のノードにより、前記マッピング関係に基づいて前記宛先ノードの前記BAPアドレスを決定するステップと、
   前記第1のノードにより、GPRSトンネリングプロトコル・ユーザプレーン内にあり且つアップリンクデータパケットで搬送されたトンネルエンドポイント識別子に基づいて、前記第1のノードと前記宛先ノードとの間の第1のパスを決定するステップと、
   前記第1のノードにより、前記宛先ノードの前記BAPアドレスに基づいて、前記アップリンクデータパケットを前記第1のパス上の前記宛先ノードに送信するステップと
   を含む方法。
2. 前記第1のノードにより、GPRSトンネリングプロトコル・ユーザプレーン内にあり且つアップリンクデータパケットで搬送されたトンネルエンドポイント識別子に基づいて、前記第1のノードと前記宛先ノードとの間の第1のパスを決定するステップは、
   前記第1のノードにより、前記donor CUにより構成された前記トンネルエンドポイント識別子と前記第1のパスとの間のマッピング関係を取得するステップと、
   前記マッピング関係と、前記GPRSトンネリングプロトコル・ユーザプレーン内にあり且つ前記アップリンクデータパケットで搬送された前記トンネルエンドポイント識別子とに基づいて、前記第1のパスを決定するステップと
   を含む、請求項１に記載の方法。
3. 前記第1のノードにより、BAPヘッダを前記アップリンクデータパケットに追加することを決定するステップであり、前記BAPヘッダは、前記宛先ノードの前記BAPアドレス及び前記第1のパスの識別子を含む、ステップを更に含む、請求項１又は２に記載の方法。
4. 前記第1のパスは、全体のネットワーク又は前記donor CU内で固有であるルーティングパス識別子を有するルーティングパスである、請求項１乃至３のうちいずれか１項に記載の方法。
5. 前記宛先ノードはドナー分散ユニット(donor DU)である、請求項１乃至４のうちいずれか１項に記載の方法。
6. ダウンリンクデータ伝送方法であって、
   第1のノードにより、ドナー集約ユニット(donor CU)により構成された宛先ノードのインターネットプロトコル(IP)アドレスと前記宛先ノードのバックホール適応プロトコル(BAP)アドレスとの間のマッピング関係を取得するステップであり、前記第1のノードはドナー分散ユニット(donor DU)である、ステップと、
   前記第1のノードにより、前記マッピング関係と、ダウンリンクデータパケットで搬送された前記宛先ノードの前記IPアドレスとに基づいて、前記宛先ノードの前記BAPアドレスを決定するステップと、
   前記第1のノードにより、前記ダウンリンクデータパケットで搬送された差別化サービスコードポイント(DSCP)又はフローラベル(flow label)に基づいて、前記第1のノードと前記宛先ノードとの間の第1のパスを決定するステップと、
   前記第1のノードにより、前記宛先ノードの前記BAPアドレスに基づいて、前記ダウンリンクデータパケットを前記第1のパス上の前記宛先ノードに送信するステップと
   を含む方法。
7. 前記第1のノードにより、前記ダウンリンクデータパケットで搬送された差別化サービスコードポイント(DSCP)又はフローラベル(flow label)に基づいて、前記第1のノードと前記宛先ノードとの間の第1のパスを決定するステップは、
   前記第1のノードにより、前記donor CUにより構成された前記DSCP又は前記フローラベルと前記第1のパスとの間のマッピング関係を取得するステップと、
   前記第1のノードにより、前記DSCP又は前記フローラベルと前記マッピング関係とに基づいて前記第1のパスを決定するステップと
   を含む、請求項６に記載の方法。
8. 前記第1のノードにより、BAPヘッダを前記ダウンリンクデータパケットに追加することを決定するステップであり、前記BAPヘッダは、前記宛先ノードの前記BAPアドレス及び前記第1のパスの識別子を含む、ステップを更に含む、請求項６又は７に記載の方法。
9. 前記第1のパスは、全体のネットワーク又は前記donor CU内で固有であるルーティングパス識別子を有するルーティングパスである、請求項６乃至８のうちいずれか１項に記載の方法。
10. 前記宛先ノードは、前記ダウンリンクデータパケットを受信する端末デバイスのアクセスIABノードである、請求項６乃至９のうちいずれか１項に記載の方法。
11. アップリンクデータ伝送装置であって、
    ドナー集約ユニット(donor CU)により構成された宛先集約ユニット・ユーザプレーン(CU-UP)のインターネットプロトコル(IP)アドレスと宛先ノードのバックホール適応プロトコル(BAP)アドレスとの間のマッピング関係を取得するように構成された処理ユニットであり、当該装置は統合アクセス及びバックホール(IAB)ノードであり、前記マッピング関係に基づいて前記宛先ノードの前記BAPアドレスを決定し、GPRSトンネリングプロトコル・ユーザプレーン内にあり且つアップリンクデータパケットで搬送されたトンネルエンドポイント識別子に基づいて、当該装置と前記宛先ノードとの間の第1のパスを決定するように構成された処理ユニットと、
    前記宛先ノードの前記BAPアドレスに基づいて、前記アップリンクデータパケットを前記第1のパス上の前記宛先ノードに送信するように構成されたトランシーバユニットと
    を含む装置。
12. 前記処理ユニットは、
    前記GPRSトンネリングプロトコル・ユーザプレーン内にあり且つ前記アップリンクデータパケットで搬送された前記トンネルエンドポイント識別子に基づいて、当該装置と前記宛先ノードとの間の前記第1のパスを決定するとき、
    前記第1のパスと前記donor CUにより構成された前記トンネルエンドポイント識別子との間のマッピング関係を取得し、前記マッピング関係と、前記GPRSトンネリングプロトコル・ユーザプレーン内にあり且つ前記アップリンクデータパケットで搬送された前記トンネルエンドポイント識別子とに基づいて、前記第1のパスを決定するように構成される、請求項１１に記載の装置。
13. 前記処理ユニットは、BAPヘッダを前記アップリンクデータパケットに追加することを決定するように構成され、前記BAPヘッダは、前記宛先ノードの前記BAPアドレス及び前記第1のパスの識別子を含む、請求項１１又は１２に記載の装置。
14. 前記第1のパスは、全体のネットワーク又は前記donor CU内で固有であるルーティングパス識別子を有するルーティングパスである、請求項１１乃至１３のうちいずれか１項に記載の装置。
15. 前記宛先ノードはドナー分散ユニット(donor DU)である、請求項１１乃至１４のうちいずれか１項に記載の装置。
16. ダウンリンクデータ伝送装置であって、
    ドナー集約ユニット(donor CU)により構成された宛先ノードのインターネットプロトコル(IP)アドレスと前記宛先ノードのバックホール適応プロトコル(BAP)アドレスとの間のマッピング関係を取得するように構成された処理ユニットであり、当該装置はドナー分散ユニット(donor DU)であり、前記マッピング関係と、ダウンリンクデータパケットで搬送された前記宛先ノードの前記IPアドレスとに基づいて、前記宛先ノードの前記BAPアドレスを決定し、前記ダウンリンクデータパケットで搬送された差別化サービスコードポイント(DSCP)又はフローラベル(flow label)に基づいて、当該装置と前記宛先ノードとの間の第1のパスを決定するように構成された処理ユニットと、
    前記宛先ノードの前記BAPアドレスに基づいて、前記ダウンリンクデータパケットを前記第1のパス上の前記宛先ノードに送信するように構成されたトランシーバユニットと
    を含む装置。
17. 前記処理ユニットは、
    前記ダウンリンクデータパケットで搬送された前記差別化サービスコードポイント(DSCP)又は前記フローラベルに基づいて、当該装置と前記宛先ノードとの間の前記第1のパスを決定するとき、
    前記第1のパスと前記donor CUにより構成された前記DSCP又は前記フローラベルとの間のマッピング関係を取得し、前記DSCP又は前記フローラベルと前記マッピング関係とに基づいて前記第1のパスを決定するように構成される、請求項１６に記載の装置。
18. 前記処理ユニットは、BAPヘッダを前記ダウンリンクデータパケットに追加することを決定するように構成され、前記BAPヘッダは、前記宛先ノードの前記BAPアドレス及び前記第1のパスの識別子を含む、請求項１６又は１７に記載の装置。
19. 前記第1のパスは、全体のネットワーク又は前記donor CU内で固有であるルーティングパス識別子を有するルーティングパスである、請求項１６乃至１８のうちいずれか１項に記載の装置。
20. 前記宛先ノードは、前記ダウンリンクデータパケットを受信する端末デバイスのアクセスIABノードである、請求項１６乃至１９のうちいずれか１項に記載の装置。
21. チップであって、
    当該チップは、電子デバイス内のメモリに結合され、それにより、前記チップは、実行するとき、前記メモリに記憶されたプログラム命令を呼び出し、請求項１乃至１０のうちいずれか１項に記載の方法を実現する、チップ。
22. コンピュータ読み取り可能記憶媒体であって、
    当該コンピュータ読み取り可能記憶媒体はプログラム命令を含み、前記プログラム命令が電子デバイス上で実行したとき、前記電子デバイスは、請求項１乃至１０のうちいずれか１項に記載の方法を実行することが可能になる、コンピュータ読み取り可能記憶媒体。

Images