以下、本願における実施形態の添付の図面を参照しながら、本願における実施形態の技術的解決策について説明する。本願の説明では、特に明記しない限り、「/」は「または」を意味する。例えば、A/Bは、AまたはBを表し得る。本明細書において「および/または」という用語は、関連する物体間の関連関係のみを説明し、3つの関係が存在し得ることを表す。例えばAおよび/またはBは、以下の3つの場合、つまり、Aのみが存在すること、AおよびBの両方が存在すること、そしてBのみが存在することを表してもよい。また、特に明記しない限り、本願の説明における「複数の」は、2つ以上を意味する。さらに、本願の実施形態における技術的解決策を明確に説明するために、「第1」および「第2」などの用語は、本願の実施形態では、基本的に同じ機能および目的を有する同じ項目または類似の項目を区別するために使用される。当業者は、「第1」および「第2」などの用語が数または実行順序を限定せず、「第1」および「第2」などの用語が明確な違いを示さないことを理解し得る。
本願の実施形態における技術的解決策は、直交周波数分割多元接続(orthogonal frequency−division multiple access、略してOFDMA)システム、単一キャリア周波数分割多元接続(single carrier FDMA、略してSC−FDMA)システム、およびその他のシステムなどの様々なデータ処理通信システムに適用することができる。「システム」および「ネットワーク」という用語は相互に交換可能であり得る。OFDMAシステムは、進化型ユニバーサル地上無線アクセス(evolved UTRA、略してE−UTRA)、ウルトラモバイルブロードバンド(ultra mobile broadband、略してUMB)などの無線技術を実施することができる。E−UTRAは、ユニバーサル移動電話システム(universal mobile telecommunications system、略してUMTS)の進化版である。第3世代パートナーシッププロジェクト(3rd generation partnership project、略して3GPP)は、長期的な進化(long term evolution、略してLTE)で新しいバージョンのE−UTRAを使用し、LTEに基づいて進化した様々なバージョンを使用する。第5世代(5th−generation、略して5G)通信システムまたは新しい無線(new radio、略してNR)は、研究中の次世代通信システムである。さらに、通信システムは、将来志向の通信技術にさらに適用可能であり得、すべて、本願の実施形態で提供される技術的解決策に適用可能である。
本出願の実施形態で説明されるシステムアーキテクチャおよびサービスシナリオは、本出願の実施形態での技術的解決策をより明確に説明することを意図しており、本出願の実施形態で提供される技術的解決策に対する制限を意味するわけではない。当業者は、ネットワークアーキテクチャの進化および新しいサービスシナリオの出現にともない、本出願の実施形態において提供される技術的解決策が、同様の技術的問題にも適用可能であることを知ることができる。本願の実施形態では、提供された方法がNRシステムまたは5Gネットワークに適用される例が説明のために使用される。しかしながら、本願の実施形態で提供される方法は、他のネットワークにも適用でき、例えば、進化したパケットシステム(evolved packet system、略してEPS)ネットワーク(すなわち、第4世代(4th generation、略して4G)ネットワークのネットワーク)に適用できることに留意されたい。同様に、本願の実施形態で提供される方法がEPSネットワークに適用される場合、本願の実施形態で提供される方法を実行するネットワークノードは、EPSネットワーク内のネットワークノードに置き換えられる。例えば、本願の実施形態で提供される方法が5GネットワークまたはNRシステムに適用される場合、以下の説明における無線バックホールノードは、5Gネットワークにおける無線バックホールノードであり得る。例えば、5Gネットワークの無線バックホールノードはIABノードと呼ばれる場合があり、もちろん別の名前を持つ場合もある。これは、本願の実施形態では特に限定されない。本願の実施形態で提供される方法がEPSネットワークに適用される場合、以下の説明における無線バックホールノードは、EPSネットワークにおける無線バックホールノードであり得る。例えば、EPSネットワークの無線バックホールノードは、リレーノード(relay node、略してRN)と呼ばれ得る。無線バックホールノードは、無線バックホールノードに無線でアクセスするノード(例えば、端末)に無線バックホールサービスを提供するように構成されている。
仮想現実(virtual reality、略してVR)、拡張現実(augmented reality、略してAR)、モノのインターネットなどの技術の進歩にともない、将来のネットワークではより多くの端末があり、ネットワークデータの使用量も増え続けるだろう。市場での端末数の増加とネットワークデータの急速な使用量の増加に適応するために、5Gネットワークの容量にはより高い要件が課せられる。ホットスポットエリアでは、5Gの超大容量要求を満たすため、ネットワーキングに高周波スモールセルを使用することが一般的になりつつある。高周波キャリアは伝搬特性が悪く、ブロックされると大幅に減衰され、カバレッジが小さい。このため、ホットスポットエリアには多数のスモールセルを密に配備する必要がある。これらのスモールセルはIABノードであってもよい。
柔軟で便利なアクセスおよびバックホールソリューションを設計するため、IABシナリオではアクセスリンク(access link、略してAL)とバックホールリンク(backhaul link、略してBL)の両方に無線送信ソリューションが適用される。
IABノードを含むネットワーク(略してIABネットワークと呼ばれる)において、IABノードは、端末に無線アクセスサービスを提供することができ、無線バックホールリンクを介してドナーノード(donor node)に接続されて、ユーザのサービスデータを送信する。IABノードは、ドナーノードを介した有線リンクを介してコアネットワークに接続される(例えば、スタンドアロン5Gアーキテクチャでは、IABノードはドナーノードを介した有線リンクを介して5Gコア(5G core、略して5GC)に接続され、非スタンドアロン5Gアーキテクチャでは、IABノードはeNB(evolved NodeB)を介して制御プレーン(control plane、略してCP)上の進化したパケットコア(EPC)に接続され、ドナーノードおよびeNBを介してユーザプレーン(user plane、略してUP)上のEPCに接続される)。
IABネットワークは、マルチホップIABノードネットワーキングおよびマルチ接続IABノードネットワーキングをサポートする。したがって、端末とドナーノードとの間に複数の送信パスが存在する可能性がある。パス上では、IABノード間、およびIABノードとIABノードにサービスを提供するドナーノードとの間には、決定された階層関係がある。各IABノードは、IABノードにバックホールサービスを提供するノードを親ノードと見なす。同様に、IABノードは親ノードのサブノードと考えられ得る。
例えば、図1を参照すると、IABノード1の親ノードはドナーノードであり、IABノード1は、IABノード2およびIABノード3の親ノードであり、IABノード2およびIABノード3の両方はIABノード4の親ノードであり、IABノード5の親ノードはIABノード2である。端末のアップリンクデータパケットは、1つ以上のIABノードを介してドナーノードに送信され得、次いで、ドナーノードによってモバイルゲートウェイデバイス(例えば、5Gネットワークのユーザプレーン機能(user plane function、略してUPF)ネットワーク要素)に送信され得る。ドナーノードがモバイルゲートウェイデバイスからダウンリンクデータパケットを受信した後、ドナーノードは、1つ以上のIABノードを介してダウンリンクデータパケットを端末に送信する。端末1とドナーノードとの間のデータパケット送信には、端末1→IABノード4→IABノード3→IABノード1→ドナーノード、および端末1→IABノード4→IABノード2→IABノード1→ドナーノードの2つの使用可能なパスがある。端末2とドナーノードとの間のデータパケット送信には、端末2→IABノード4→IABノード3→IABノード1→ドナーノード、端末2→IABノード4→IABノード2→IABノード1→ドナーノード、および端末2→IABノード5→IABノード2→IABノード1→ドナーノードの3つの利用可能なパスがある。
例えば、本願のこの実施形態におけるドナーノードは、ドナー基地局であり得る。ドナーノードは、5GネットワークではIABドナー(IAB donor)またはDgNB(つまり、donor gNodeB)と短く呼ばれることがある。ドナーノードは、完全なエンティティである場合もあれば、集中ユニット(centralized unit、略してCU)形式の場合もあり、分散ユニット(distributed unit、略してDU)は分離されている、つまり、ドナーノードは、集中ユニット(Donor−CU)および分散ユニット(Donor−DU)を含む。本願および添付の図面の実施形態では、ドナーノードがドナーCUおよびドナーDUを含む例は、本願の実施形態で提供される方法を説明するために使用される。しかしながら、本願のこの実施形態におけるドナーノードは、DUおよびCUが分離された形態ではない可能性があることが理解され得る。この場合、本願の図3から図6のドナーノードに含まれるプロトコルスタックは、ドナーノードのDUとドナーノードのCUとの間の通信のためのプロトコルスタックを含む必要はなく、ドナーノードと他のノードとの間の通信用のプロトコルスタックを含むだけでよい。
例えば、本願のこの実施形態におけるIABノードは、移動端末(mobile terminal、略してMT)およびDUとして機能し得る。IABノードがIABノードの親ノードと通信する場合、IABノードは端末と考えられ得る。この場合、IABノードはMTとして機能する。IABノードがIABノードのサブノード(サブノードは端末または他のIABノードの端末部分であり得る)と通信するとき、IABノードはネットワークデバイスと考えられ得る。この場合、IABノードはDUとして機能する。したがって、IABノードはMTおよびDUを含むと見なすことができる。IABノードは、MTを使用して、IABノードの少なくとも1つの親ノードへのバックホール接続を確立できる。IABノードのDUは、端末または他のIABノードのMTにアクセスサービスを提供することができる。例えば、図1Aを参照すると、端末は、IABノード2およびIABノード1を介してドナーノードに接続されている。IABノード1およびIABノード2は、それぞれDUとMTを含む。IABノード2のDUは、端末にアクセスサービスを提供する。IABノード1のDUは、IABノード2のMTにアクセスサービスを提供する。ドナーDUは、IABノード1のMTにアクセスサービスを提供する。
例えば、IABノードは、カスタマ構内設備(customer premises equipment、略してCPE)またはレジデンシャルゲートウェイ(residential gateway、略してRG)などのデバイスであってもよい。本願の実施形態で提供される方法は、ホームアクセス(home access)シナリオにさらに適用され得る。
前述のIABネットワーキングシナリオは単なる例である。マルチホップとマルチ接続を組み合わせたIABシナリオでは、他にも考えられるIABネットワーキングシナリオがある。例えば、ドナーノードに接続されたIABノードと他のドナーノードに接続されたIABノードは、端末にサービスを提供するためのデュアル接続を形成する。考えられるIABネットワーキングシナリオは、ここでは1つずつリストされていない。
IABネットワークでは、データパケットを正しい宛先ノードに転送するために、ルーティング情報がデータパケットで運ばれ得る。ルーティング情報は、データパケットの宛先ノードの識別子である場合もあれば、決定されたルーティングパスを示すために使用されるパスラベルである場合もある。
ルーティング情報がデータパケットの宛先ノードの識別子である場合、宛先ノードに基づいてデータパケットを転送するために使用されるルートマッピングテーブル(または転送テーブルと呼ばれる)は、各転送ノード(例えば、IABノードまたはドナーノードのDU)で構成される。データパケットを受信した後、転送ノードはデータパケット内の宛先ノードの識別子に基づいてルートマッピングテーブルを検索し、一意のネクストホップノードを決定する。ルートマッピングテーブルは、例えば、ドナーノード、ドナーノードのCU、または転送ノード用の転送ノードの親ノードによって構成され得る、というように一元的に構成され得るか、または、例えば、転送ノードと親ノードおよび/またはサブノードとの間で交換される情報に基づいて転送ノードによって生成される、というように分散生成され得、ここで交換される情報は、ノード間の接続のトポロジー情報である。
ルーティング情報が、決定されたルーティングパスを示すために使用されるパスラベルである場合、パスラベルに基づいてデータパケットを転送するために使用されるルートマッピングテーブルは転送ノードで構成され得、転送ノードは、パスラベルおよびルートマッピングテーブルに基づいてネクストホップノードを直接決定することができる。パスラベルがルーティングパス上のノードの識別子を含む場合、転送ノードは、パスラベルのみに基づいてネクストホップノードを直接決定することもできる。このようにして、決定された送信パスは、データパケットの入口ノード(すなわち、パスラベルが追加されるノード)でデータパケットに対して指定されることが理解され得る。
前述の2つのケースはどちらも、ノードルーティングの柔軟性を制限する、つまり、データパケットは、マルチ接続が確立されている一部のノードの1つの決定された送信パスを通じてのみ送信され得る。例えば、図1を参照すると、ルートマッピングテーブルを構成するノードはドナーノードである。ドナーノードが各リンクの実際のステータス(例えば、リンクが混雑しているかどうか、リンクが中断または回復されているかどうか、リンクがブロックされているかどうか(blockage))を時間内に知ることができない場合、ドナーノードによって端末1のデータパケットに構成される送信パスは、ドナーノード→IABノード1→IABノード3→IABノード4→端末1であり得る。送信パス上のIABノード3とIABノード4との間のリンクが混雑または中断されている場合、端末1のデータパケットは、IABノード3からIABノード4への送信に失敗する可能性があり、端末1の大量のデータパケットは、IABノード3に蓄積される。深刻なケースでは、パケット損失が発生する可能性がある。実際には、IABノード1は、IABノード2およびIABノード4を介して端末1のデータパケットを送信することができ、それにより、前述の問題を回避することができる。
ノードのルーティングの柔軟性を改善するために、本願の実施形態は、ネットワークノードを提供し、これは、具体的には、以下の説明では第1のノード、第5のノード、第1の無線デバイス、ネットワークデバイス、または第6のノードであり得る。ネットワークノードのハードウェア構造の概略図については、図2を参照されたい。図2はネットワークノード20のハードウェア構造の概略図である。ネットワークノード20は、少なくとも1つのプロセッサ201と、通信バス202と、メモリ203と、少なくとも1つの通信インタフェース204とを含む。
プロセッサ201は、汎用中央処理装置(central processing unit、略してCPU)、マイクロプロセッサ、特定用途向け集積回路(application−specific integrated circuit、略してASIC)、または本願のソリューションでプログラムの実行を制御するように構成された1つ以上の集積回路であってもよい。
通信バス202は、前述したコンポーネント間で情報を送信するためのチャネルを含んでもよい。
通信インタフェース204は、トランシーバなどの任意の装置であってもよく、他のデバイス、またはイーサネット、無線アクセスネットワーク(radio access network、略してRAN)、もしくはWLANなどの通信ネットワークと通信するように構成される。
メモリ203は、読み取り専用メモリ(read−only memory、略してROM)、または静的な情報や命令を保管できる別種の静的ストレージデバイス、ランダムアクセスメモリ(random access memory、略してRAM)、または情報や命令を保管できる別種の動的ストレージデバイスであってもよく、あるいは電気的消去可能プログラム可能読み取り専用メモリ(electrically erasable programmable read−only memory、略してEEPROM)、コンパクトディスク読み取り専用メモリ(compact disc read−only memory、略してCD−ROM)、または他のコンパクトディスクストレージ、または光学式ディスクストレージ(圧縮光ディスク、レーザーディスク(登録商標)、光ディスク、デジタル多用途ディスク、ブルーレイ光ディスクなどを含む)、磁気式ディスクストレージ媒体または他の磁気式ストレージデバイス、または命令かデータ構造の形をとる期待されたプログラムコードを携帯または保管でき、なおかつコンピュータによってアクセスできる他の何らかの媒体であってもよく、ただしこれらに限定されない。メモリは、独立して存在してもよく、バスを介してプロセッサに接続される。代わりに、メモリは、プロセッサと統合されてもよい。
メモリ203は、本出願の解決策を実行するためのアプリケーションプログラムコードを記憶するように構成され、プロセッサ201は、実行を制御する。プロセッサ201は、本願の以降の実施形態で提供される方法を実施するため、メモリ203に保管されたアプリケーションプログラムコードを実行するように構成される。
具体的な実施に際して、一実施形態では、プロセッサ201は、1つ以上のCPU、例えば、図2のCPU0およびCPU1を含み得る。
一実施形態における具体的な実施に際して、ネットワークノード20は、複数のプロセッサを、例えば図2のプロセッサ201とプロセッサ208とを含んでもよい。各プロセッサは、シングルコア(single−CPU)プロセッサまたはマルチコア(multi−CPU)プロセッサであり得る。プロセッサはこの場合、データ(例えば、コンピュータプログラム命令)を処理するための1つまたは複数のデバイス、回路、および/または処理コアであり得る。
一実施形態における具体的な実施に際して、ネットワークノード20は出力デバイス205と入力デバイス206とをさらに含んでもよい。
本願のネットワーク要素は、端末、ドナーノード、および無線バックホールノード(例えば、IABノード)を含む。本願の実施形態の端末は、ユーザ機器(user equipment、略してUE)、アクセス端末、サブスクライバユニット、サブスクライバステーション、モバイルステーション、リモートステーション、リモート端末、モバイルデバイス、ユーザ端末、無線通信デバイス、ユーザエージェント、またはユーザ装置と呼ばれることもあることに留意されたい。あるいは、端末は無線ローカルエリアネットワーク(wireless local area networks、略してWLAN)内のステーション(station、略してST)であってもよく、またはセル方式電話機、コードレス電話機、セッションイニシエーションプロトコル(session initiation protocol、略してSIP)電話機、ワイヤレスローカルループ(wireless local loop、略してWLL)ステーション、個人用デジタル補助装置(personal digital assistant、略してPDA)デバイス、無線通信機能を有する手持ち型デバイス、計算デバイス、または無線モデムに接続された他の処理デバイス、車載デバイス、またはウェアラブルデバイス(ウェアラブルインテリジェントデバイスと呼ばれることもある)であってもよい。あるいは、端末は、次世代通信システムの端末であってもよく、例えば、5Gの端末、または将来の進化した公共地上移動体ネットワーク(public land mobile network、略してPLMN)の端末、またはNR通信システムの端末であってもよい。
以下に説明する方法をよりよく理解するために、以下に記載するいくつかのプロトコル層およびプロトコル層に関連する添付の図面がすべて本明細書に記載されている。
デバイス上のプロトコル層は、無線リソース制御(radio resource control、略してRRC)層、パケットデータ収束プロトコル(packet data convergence protocol、略してPDCP)層、無線リンク制御(radio link control、略してRLC層)、メディアアクセス制御(media access control、MAC)層、物理層(physical layer、略してPHY)、T1アプリケーションプロトコル(T1 application protocol、略してT1AP)層、Adapt(アダプテーション)層、F1アプリケーションプロトコル(F1 application protocol、略してF1AP)層、ストリーム制御伝送プロトコル(stream control transmission protocol、略してSCTP)層、インターネットプロトコル(internet protocol、略してIP)層、L2(layer 2)層、およびL1((layer 1)層のうちの1つ以上を含む。L2層はリンク層である。例えば、L2層は、オープンシステム相互接続(open systems interconnection、略してOSI)参照モデルのデータリンク層であり得る。L1層は物理層でもよい。例えば、L1層はOSI参照モデルの物理層であり得る。
Adapt層は、アダプテーション層(adaptation layer)を表す。Adapt層は、以下の機能、すなわち、無線バックホールノードに識別可能なルーティング情報をデータパケットに追加すること、無線バックホールノードに識別可能なルーティング情報に基づいてルート選択を実行すること、サービス品質(quality of service、略してQoS)要件に関連し、無線バックホールノードに識別可能な識別情報をデータパケットに追加すること、無線バックホールノードを含む複数のリンクでデータパケットのQoSマッピングを実行すること、パケットタイプ指示情報をデータパケットに追加すること、およびフロー制御機能を有するノードにフロー制御フィードバック情報を送信することのうちの少なくとも1つを有する。これらの機能を有するプロトコル層の名前は、必ずしもAdapt層であるとは限らないことに留意されたい。当業者は、これらの機能を有する任意のプロトコル層が、本願の実施形態ではAdapt層として理解され得ることを理解し得る。例えば、Adapt層は、バックホールアダプテーションプロトコル(backhaul adaptation protocol、略してBAP)層とも呼ばれ得る。
無線バックホールノードで識別可能なルーティング情報は、端末の識別子、端末によってアクセスされるIABノードの識別子、ドナーノードの識別子、ドナーノードのDUの識別子、ドナーノードのCUの識別子、送信パスの識別子などのうちの1つ以上であり得る。
複数のリンク上でのQoSマッピングは、端末の無線ベアラのものであり、データパケットで運ばれる識別子に基づいて、端末の無線ベアラから、無線ベアラ、RLCベアラ(RLC bearer)、RLCチャネル(RLC channel)、または無線バックホールインタフェース上の論理チャネルへのバックホールリンクで実行されるマッピング、または、前ホップリンクでデータパケットを受信するための無線ベアラ、RLCベアラ、RLCチャネル、または論理チャネルから、ネクストホップリンク上でデータパケットを送信するための無線ベアラ、RLCベアラ、RLCチャネル、または論理チャネルへ実行されるマッピング、または、無線バックホールインタフェース上のまたは特定のQoS識別子(例えば、サービス品質クラス識別子(QoS class identifier、略してQCI)、5Gサービス品質識別子(5G QoS identifier、略して5QI)、サービス品質フロー識別子(QoS flow identity、略してQFI)、差別化サービスコードポイント(differentiated services code point、略してDSCP))、またはデータパケットで運ばれるインターネットプロトコルバージョン6(internet protocol version 6、略してIPv6)パケットヘッダのフローラベル(flow label)に基づいて、特定のQoS識別子から、無線ベアラ、RLCベアラ、RLCチャネル、または無線バックホールインタフェース上の論理チャネルへ実行されるマッピングであり得る。
データパケットタイプ指示情報は、BAP層においてカプセル化されたコンテンツが次のタイプのいずれかを含むことを示すために使用され得る:端末のユーザプレーンデータ、端末のRRCメッセージ、IABノードのRRCメッセージ、IABノードとドナーノードまたはドナーノードのCUとの間のインタフェース上の制御層アプリケーションメッセージ(例えば、T1APメッセージ)、IABノードによって生成されたフロー制御フィードバックメッセージなど。ノード上のT1AP層を使用することにより、ノードは他のノード上のピアT1AP層に第1のメッセージを送信できる。第1のメッセージは、ノードまたは他のノードがサービスを提供する端末のコンテキスト管理情報、端末のRRCメッセージ、または2つのノード間のインタフェースの管理に関連するメッセージを含む。T1APプロトコル層のノードによって生成または送信されるメッセージは、T1APメッセージと呼ばれ得る。
QoS要件に関連する識別情報は、端末のQFI、端末の無線ベアラ識別子(例えば、データ無線ベアラ(data radio bearer、略してDRB)または信号無線ベアラ(signaling radio bearer、SRB))、端末のデータ無線ベアラに対応するトンネルエンドポイント識別子(Tunnel endpoint identifier、略してTEID)、DSCPなどであり得る。
例えば、フロー制御機能を含むノードは、IABノード、例えば、ドナーノード、ドナーノードのDU、ドナーノードのCU、またはIABノードの親ノードにバックホールサービスを提供する上流のノードであり得る。フロー制御フィードバック情報の内容は、次の情報のうちの1つ以上を含み得る:IABノードのバッファステータスおよび負荷、IABノードを含むリンクのステータス(例えば、リンクのブロック、リンクの中断、リンクの再開(resume)、またはリンクの品質情報)、IABノードを含むリンクの帯域幅および伝送遅延、IABノードで失われたデータパケットのシーケンス番号、IABノードから端末またはIABノードのサブノードに正常に送信されたデータパケットのシーケンス番号。
BAP層は、RLC層の上およびPDCP層の下に配置することも、プロトコルスタックの他の位置に配置することもできる。BAP層の特定の位置については本願の実施形態では限定されない。
T1AP層は、IABノード(具体的にはIABノードのDU)とドナーノード(またはドナーノードのCU)との間で制御プレーンメッセージを運ぶために使用される。制御プレーンメッセージは、次のメッセージのうちの1つ以上を含む:IABノードとドナーノード(またはドナーノードのCU)との間のインタフェースの管理に関連するメッセージ、IABノードとドナーノード(またはドナーノードのCU)との間の構成更新に関連するメッセージ、IABノードのサブノード(端末、他のIABノードなどを含む)に関連するコンテキスト構成メッセージ、およびIABノードのサブノードのRRCメッセージを運ぶメッセージコンテナ(message container)を含むメッセージ。T1AP層は、PDCP層の上に配置することも、プロトコルスタックの他の位置に配置することもできる。T1AP層の特定の位置については、本願の実施形態では制限されない。
これらの機能を有するプロトコル層の名前は、必ずしもT1AP層である必要はなく、特にIABノードとドナーノード(またはドナーノードのCU)との間のインタフェースに依存することに留意されたい。例えば、IABノードとドナーノード(またはドナーノードのCU)との間のインタフェースがF1インタフェースまたはF1*インタフェースである場合、プロトコル層はF1AP層またはF1*AP層と呼ばれ得る。F1インタフェースまたはF1*インタフェースは、別の名前を有することもできる。これは、本願の実施形態では特に限定されない。当業者は、これらの機能を有する任意のプロトコル層が、本願の実施形態ではT1AP層として理解され得ることを理解し得る。
F1AP層は、DUとCUとの間で制御プレーンメッセージを運ぶように構成されている。制御プレーンメッセージは、次のメッセージのうちの1つ以上を含む:DUとCUとの間のインタフェースの管理に関連するメッセージ、DUとCUとの間の構成更新に関連するメッセージ、DUのサブノード(端末、他のIABノードなどを含む)に関連するコンテキスト構成メッセージ、およびDUのサブノードのRRCメッセージを運ぶメッセージコンテナ(message container)を含むメッセージなど。本明細書のDUは、IABノードのDUおよび/またはドナーノードのDUであり得る。F1AP層は、SCTP層の上に配置することも、プロトコルスタックの他の位置に配置することもできる。F1AP層の特定の位置については、本願の実施形態では制限されない。これらの機能を有するプロトコル層の名前は、必ずしもF1AP層であるとは限らないことに留意されたい。当業者は、これらの機能を有する任意のプロトコル層が、本願の実施形態ではF1AP層として理解され得ることを理解し得る。
理解のための例として、いくつかのプロトコルアーキテクチャが以下に示される。図3から図6に示されるプロトコルスタックアーキテクチャでは、DUはドナーノードのDUであり、CUはドナーノードのCUである。図3から図6に示されるプロトコルスタックアーキテクチャにおける各ノードのプロトコルスタックは、単なる例である。実際の実装では、各ノードのプロトコルスタックに含まれるプロトコル層は、図に示されているものよりも多い場合も少ない場合も、または異なっている場合もある。これは、本願の実施形態では特に限定されない。
図3を参照すると、制御プレーンプロトコルアーキテクチャは、CU、DU、IABノード1、IABノード2、および端末を含む。端末のプロトコルスタックは、上から下に、CUのRRC層およびPDCP層とピアリングされているRRC層およびPDCP層、ならびにIABノード2のRLC層、MAC層、およびPHY層とピアリングされているRLC層、MAC層、およびPHY層を順次含む。IABノード2が端末と通信するためのプロトコルスタックは、上から下に、端末のRLC層、MAC層、およびPHY層とピアリングされているRLC層、MAC層、およびPHY層を順次含む。IABノード2がCUと通信するためのプロトコルスタックは、上から下に、CUのT1AP層およびPDCP層とピアリングされているT1AP層およびPDCP層を順次含む。IABノード2がIABノード1と通信するためのプロトコルスタックは、上から下に、IABノード1のBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。IABノード1がIABノード2と通信するためのプロトコルスタックは、上から下に、IABノード2のBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。IABノード1がDUと通信するためのプロトコルスタックは、上から順に、DUのBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。DUがIABノード1と通信するためのプロトコルスタックは、上から下に、IABノード1のBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。DUがCUと通信するためのプロトコルスタックは、上から下に、CUのF1AP層、SCTP層、IP層、L2層、およびL1層とピアリングされているF1AP層、SCTP層、IP層、L2層、およびL1層を順次含む。CUのプロトコルスタックは、上から下に、端末のRRC層およびPDCP層とピアリングされているRRC層およびPDCP層、IABノード2のT1AP層およびPDCP層とピアリングされているT1AP層およびPDCP層、ならびにDUのF1AP層、SCTP層、IP層、L2層、およびL1層とピアリングされているF1AP層、SCTP層、IP層、L2層、およびL1層を順次含む。
DRBまたはRLCベアラ/RLCベアラ/DRBに対応する論理チャネルが、IABノードのT1APメッセージを送信するために無線バックホールインタフェース(図のUnインタフェース)で使用される場合、図3の破線ボックス内のプロトコル層のF1AP層は、一般的なパケット無線サービストンネリングプロトコル(general packet radio service tunneling protocol、略してGTP)層にさらに置き換えられ得、SCTP層は、ユーザデータグラムプロトコル(user datagram protocol、略してUDP)層に置き換えられ得ることに留意されたい。
図3では、IABノード2がCUと通信するためのプロトコルスタックでは、T1AP層はF1AP層に置き換えられ得、PDCP層はSCTP層で置き換えられ得、そしてDUのIP層とピアリングされているIP層は、SCTP層とBAP層との間にさらに含まれ得る。DUがIABノード2と通信するためのプロトコルスタックは、IABノード2のIP層とピアリングされているIP層を含む。あるいは、DUがCUと通信するためのプロトコルスタックは、F1AP層およびSCTP層を含まない場合がある。同様に、CUのプロトコルスタックでは、IABノード2のT1AP層はF1AP層とピアリングされているT1AP層はF1AP層に置き換えられ得、PDCP層はSCTP層に置き換えられ得、あるいはDUのF1AP層およびSCTP層とピアリングされているF1AP層およびSCTP層は、含まれない場合がある。この場合、各ノードのプロトコルスタックアーキテクチャについては、図3Aを参照されたい。
図3Aでは、F1*−Cは、IABノードとドナーノードとの間のF1*インタフェースの制御プレーンを指す。図3に示されるF1AP層、SCTP層、およびIP層に加えて、F1*−Cインタフェースプロトコル層は、F1*−Cインタフェースメッセージ、例えば、データグラムトランスポート層セキュリティ(datagram transport layer security、略してDTLS)層、PDCP層、およびインターネットプロトコルセキュリティ(internet protocol security、略してIPsec)層の1つ以上に対してセキュリティ保護を実行するように構成されたプロトコル層をさらに含み得る。DTLS層は、SCTP層とF1AP層との間に配置され得る。PDCP層は、IABノード2のものであり、かつドナーノードのCUのプロトコル層とピアリングされており、かつF1AP層の下に配置され得るプロトコル層であり得る。IPsec層は、IABノード2のものであり、かつドナーノードのCUのプロトコル層とピアリングされているプロトコル層であり得、IABノード2のプロトコル層であり、かつドナーノードのDUのプロトコル層とピアリングされているプロトコル層であり得、またはドナーノードのDUのものであり、かつドナーノードのCUのプロトコル層とピアリングされており、かつIP層とSCTP層との間に配置され得るプロトコル層であり得る。
図4を参照すると、制御プレーンプロトコルアーキテクチャは、CU、DU、IABノード1、IABノード2、および端末を含む。端末のプロトコルスタックは、上から下に、CUのRRC層およびPDCP層とピアリングされているRRC層およびPDCP層、ならびにIABノード2のRLC層、MAC層、およびPHY層とピアリングされているRLC層、MAC層、およびPHY層を順次含む。IABノード2が端末と通信するためのプロトコルスタックは、上から下に、端末のRLC層、MAC層、およびPHY層とピアリングされているRLC層、MAC層、およびPHY層を順次含む。IABノード2がCUと通信するためのプロトコルスタックは、上から下に、CUのT1AP層およびPDCP層とピアリングされているT1AP層およびPDCP層を順次含む。IABノード2がIABノード1と通信するためのプロトコルスタックは、上から下に、IABノード1のBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。IABノード1がIABノード2と通信するためのプロトコルスタックは、上から下に、IABノード2のBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。IABノード1がDUと通信するためのプロトコルスタックは、上から順に、DUのBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。DUがIABノード2と通信するためのプロトコルスタックは、上から下に、IABノード2のT1AP層、およびPDCP層とピアリングされているT1AP層、およびPDCP層を順次含む。DUがIABノード1と通信するためのプロトコルスタックは、上から下に、IABノード1のBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。DUがCUと通信するためのプロトコルスタックは、上から下に、CUのF1AP層、SCTP層、IP層、L2層、およびL1層とピアリングされているF1AP層、SCTP層、IP層、L2層、およびL1層を順次含む。CUのプロトコルスタックは、上から下に、端末のRRC層およびPDCP層とピアリングされているRRC層およびPDCP層、ならびにDUのF1AP層、SCTP層、IP層、L2層、およびL1層とピアリングされているF1AP層、SCTP層、IP層、L2層、およびL1層を順次含む。
図5を参照すると、ユーザプレーンプロトコルアーキテクチャは、CU、DU、IABノード1、IABノード2、および端末を含む。端末のプロトコルスタックは、上から下に、CUのSDAP層およびPDCP層とピアリングされているSDAP層およびPDCP層、ならびにIABノード2のRLC層、MAC層、およびPHY層とピアリングされているRLC層、MAC層、およびPHY層を順次含む。IABノード2が端末と通信するためのプロトコルスタックは、上から下に、端末のRLC層、MAC層、およびPHY層とピアリングされているRLC層、MAC層、およびPHY層を順次含む。IABノード2がIABノード1と通信するためのプロトコルスタックは、上から下に、IABノード1のBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。IABノード1がIABノード2と通信するためのプロトコルスタックは、上から下に、IABノード2のBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。IABノード1がDUと通信するためのプロトコルスタックは、上から順に、DUのBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。DUがIABノード1と通信するためのプロトコルスタックは、上から下に、IABノード1のBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。DUがCUと通信するためのプロトコルスタックは、上から下に、CUのGTP層、UDP層、IP層、L2層、およびL1層とピアリングされているGTP層、UDP層、IP層、L2層、およびL1層を順次含む。CUのプロトコルスタックは、上から下に、端末のSDAP層およびPDCP層とピアリングされているSDAP層およびPDCP層、ならびにDUのGTP層、UDP層、IP層、L2層、およびL1層とピアリングされているGTP層、UDP層、IP層、L2層、およびL1層を順次含む。
図5Aを参照すると、ユーザプレーンプロトコルアーキテクチャは、CU、DU、IABノード1、IABノード2、および端末を含む。端末のプロトコルスタックは、上から下に、CUのPDCP層とピアリングされているPDCP層、ならびにIABノード2のRLC層、MAC層、およびPHY層とピアリングされているRLC層、MAC層、およびPHY層を順次含む。IABノード2が端末と通信するためのプロトコルスタックは、上から下に、端末のRLC層、MAC層、およびPHY層とピアリングされているRLC層、MAC層、およびPHY層を順次含む。IABノード2がCUと通信するためのプロトコルスタックは、上から下に、CUのGTPユーザプレーン(GTP user plane、略してGTP−U)層およびUDP層とピアリングされているGTPユーザプレーン層およびPDCP層を順次含む。IABノード2がDUと通信するためのプロトコルスタックは、DUのIP層とピアリングされているIP層を含む。IABノード2がIABノード1と通信するためのプロトコルスタックは、上から下に、IABノード1のBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。IABノード1が無線バックホールリンク上でIABノード2と通信するためのプロトコルスタックは、上から下に、IABノード2のBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。IABノード1が無線バックホールリンク上でDUと通信するためのプロトコルスタックは、上から順に、DUのBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。DUが無線バックホールリンク上でIABノード2と通信するためのプロトコルスタックは、IABノード2のIP層とピアリングされているIP層を含む。DUが無線バックホールリンク上でIABノード1と通信するためのプロトコルスタックは、上から下に、IABノード1のBAP層、RLC層、MAC層、およびPHY層とピアリングされているBAP層、RLC層、MAC層、およびPHY層を順次含む。DUが無線バックホールリンク上でCUと通信するためのプロトコルスタックは、上から下に、CUのIP層、L2層、およびL1層とピアリングされているIP層、L2層、およびL1層を順次含む。CUのプロトコルスタックは、上から下に、端末のPDCP層とピアリングされているPDCP層、IABノード2のGTP−U層およびUDP層とピアリングされているGTP−U層とUDP層、ならびにDUのIP層、L2層、およびL1層とピアリングされているIP層、L2層、およびL1層を順次含む。
図5Aでは、F1*−Uは、IABノードとドナーノードとの間のF1*インタフェースのユーザプレーンを指す。図5Aに示されるGTP−U層、UDP層、およびIP層に加えて、F1*−Uインタフェースプロトコル層は、F1*−Uインタフェースメッセージ、例えば、PDCP層およびIPsec層の1つ以上に対してセキュリティ保護を実行するように構成されたプロトコル層をさらに含み得る。PDCP層は、IABノード2のプロトコル層であり、かつドナーノードのCUのプロトコル層とピアリングされており、かつGTP−U層の下に配置され得るプロトコル層であり得る。IPsec層は、IABノード2のものであり、かつドナーノードのCUのプロトコル層とピアリングされているプロトコル層であり得、IABノード2のプロトコル層であり、かつドナーノードのDUのプロトコル層とピアリングされているプロトコル層であり得、またはドナーノードのDUのものであり、かつドナーノードのCUのプロトコル層とピアリングされており、かつIP層とUDP層との間に配置され得るプロトコル層であり得る。
図6を参照すると、ユーザプレーンプロトコルアーキテクチャは、CU、DU、IABノード1、IABノード2、および端末を含む。端末のプロトコルスタックは、上から下に、CUのSDAP層およびPDCP層とピアリングされているSDAP層およびPDCP層、ならびにIABノード2のRLC層、MAC層、およびPHY層とピアリングされているRLC層、MAC層、およびPHY層を順次含む。IABノード2が端末と通信するためのプロトコルスタックは、上から下に、端末のS−RLC層、MAC層、およびPHY層とピアリングされているRLC層、MAC層、およびPHY層を順次含む。IABノード2がIABノード1と通信するためのプロトコルスタックは、上から下に、IABノード1のS−RLC層、BAP層、MAC層、およびPHY層とピアリングされているS−RLC層、BAP層、MAC層、およびPHY層を順次含む。IABノード1がIABノード2と通信するためのプロトコルスタックは、上から下に、IABノード2のS−RLC層、BAP層、MAC層、およびPHY層とピアリングされているS−RLC層、BAP層、MAC層、およびPHY層を順次含む。IABノード1がDUと通信するためのプロトコルスタックは、上から順に、DUのS−RLC層、BAP層、MAC層、およびPHY層とピアリングされているS−RLC層、BAP層、MAC層、およびPHY層を順次含む。DUがIABノード1と通信するためのプロトコルスタックは、上から下に、IABノード1のS−RLC層、BAP層、MAC層、およびPHY層とピアリングされているS−RLC層、BAP層、MAC層、およびPHY層を順次含む。DUがCUと通信するためのプロトコルスタックは、上から下に、CUのGTP層、UDP層、IP層、L2層、およびL1層とピアリングされているGTP層、UDP層、IP層、L2層、およびL1層を順次含む。CUのプロトコルスタックは、上から下に、端末のSDAP層およびPDCP層とピアリングされているSDAP層およびPDCP層、ならびにDUのGTP層、UDP層、IP層、L2層、およびL1層とピアリングされているGTP層、UDP層、IP層、L2層、およびL1層を順次含む。
S−RLC層は、いくつかのRLC層機能を予約する簡略化されたRLC層(simplified RLC)である。簡略化されたプロトコル層は、自動再送要求(automatic repeat request、略してARQ)および再構成(reassemble)機能を有さない。受信側では、S−RLC層は受信データパケット(RLC PDU)を再構成(reassemble)せず、AMモードでACK/NACKフィードバックも実行しない。S−RLC層は、送信側でデータパケットを再送信しないが、データパケット内のRLC SDUでセグメンテーション(segmentation)操作を実行するか、データパケット内のRLC SDUのセグメント(segment)で再セグメンテーション(re−segmentation)操作を実行できる。セグメンテーションまたは再セグメンテーション操作を実行した後、S−RLC層は、新しいRLC PDUを生成するために新しいRLCヘッダを構築し、新しいRLC PDUを処理のために送信側の下位プロトコル層に送達する。
以下の説明をより明確にするために、本願の実施形態における「ホップバイホップ」、「エンドツーエンド」、および「セグメントバイセグメント」の説明はすべて、本明細書で明確にされている。
ノードDとノードEとの間のパスがSノードを含む場合、パス上のノードは、ノードD、ノード1、ノード2、...、ノードS、およびノードEの順になる。
ノードDおよびノードEがそれぞれホップバイホップのピアプロトコル層(例えば、第1のプロトコル層であり得る)を有すると説明される場合、それは、ノードDおよびノード1はそれぞれピアプロトコル層を有し、ノードsおよびノードs+1はそれぞれピアプロトコル層を有し、ノードSおよびノードEはそれぞれピアプロトコル層を有し、sは、0より大きくSより小さい整数であることを示す。
ノードDおよびノードEがそれぞれエンドツーエンドのピアプロトコル層(例えば、第1のプロトコル層であり得る)を有すると説明される場合、それは、ノードDおよびノードEがそれぞれピアプロトコル層を有し、ノードDおよびノード1はピアプロトコル層を有さず、ノードSおよびノードEもピアプロトコル層を有さないことを示す。
ノードDおよびノードEがそれぞれセグメントバイセグメントのピアプロトコル層(例えば、第1のプロトコル層であり得る)を有すると説明される場合、それは、ノードDおよびノードEのセグメントバイセグメントのピアプロトコル層が、ノードDとノードEとの間の複数のエンドツーエンドのピアプロトコル層を使用することによって確立され、データパケットは、他のノードを介して、複数のエンドツーエンドのピアプロトコル層の少なくとも1つの2つのエンドポイント間で転送され得ることを示す。例えば、ノードDおよびノードEのセグメントバイセグメントのピアプロトコル層は、ノードDとノードEとの間の2つのエンドツーエンドのピアプロトコル層を使用することによって確立され得る。例えば、ノードDおよびノードS1(ノード1からノードSのノード)はそれぞれエンドツーエンドのピアプロトコル層を有し、ノードS1およびノードEはそれぞれエンドツーエンドのピアプロトコル層を有し、データパケットは、他のノードを介して、ノードDとノードS1との間、および/またはノードS1とノードEとの間で転送され得る。
例えば、図3および図4を参照すると、IABノード2およびDUはそれぞれホップバイホップピアBAP層を有し、DUおよびCUはそれぞれピアF1AP層を有する。図4では、IABノード2およびDUは、それぞれエンドツーエンドのピアT1AP層を有する。あるいは、IABノード2上のT1AP層の機能が、CUおよびDUのF1AP層の機能と同じである場合、IABノード2とDUを介したCUとの間にセグメントバイセグメントのピアT1AP層があると考えられ得る。図3では、IABノード2およびCUは、それぞれエンドツーエンドのピアT1AP層を有する。
本願のこの実施形態では、特に明記しない限り、ノードDおよびノードEがそれぞれピアプロトコル層を有することは、前述の3つの場合のいずれか1つを指すことができる。もちろん、隣接ノードのプロトコル層もピアリングされている可能性がある。例えば、図3および図4のDUおよびCUのF1AP層は、ピアリングされている。
以下の説明をより明確にするために、本願の実施形態で言及されるいくつかの内容は、本明細書で簡単に説明される。
送信元ノードは、RAN側でデータパケットを送信するための初期ノードである。例えば、アップリンクデータパケットの場合、送信元ノードは、端末、または端末に無線アクセスサービスを提供する無線バックホールノードであり得る。ダウンリンクデータパケットの場合、送信元ノードは、ドナーノード、ドナーノードのCU、またはドナーノードのDUであり得る。
宛先ノードは、RAN側でデータパケットを送信するための最終ノードである。例えば、アップリンクデータパケットの場合、宛先ノードは、ドナーノード、ドナーノードのCU、またはドナーノードのDUであり得る。ダウンリンクデータパケットの場合、宛先ノードは、端末、または端末に無線アクセスサービスを提供する無線バックホールノードであり得る。
QoSラベルはQoSタイプであり、QoS要件を識別するために使用される。例えば、QoSラベルは、5QI、QCI、DSCP、QFIなどであり得る。
リンクは、パス上の2つの隣接ノード間のパスである。
ノードCの下流のノードは、ノードCの後にデータパケットを受信し、ノードCを含むパス上にあるノードである。本願の実施形態におけるノードCは、特定のノードではなく任意のノードである。以下の説明におけるノードDおよびノードEは、ノードCの場合と同様である。例えば、ノードCは、以下の説明における第1のノードであり得る。
ノードCの上流のノードは、ノードCの前にデータパケットを受信し、ノードCを含むパス上にあるノードである。
ノードCのネクストホップノードは、ノードCの後にデータパケットを受信し、ノードCを含むパス上にある第1のノードである。
例えば、図1を参照すると、データパケットがアップリンクデータパケットである場合、パス上では、端末1→IABノード4→IABノード3→IABノード1→ドナーノードであり、IABノード3の下流のノードはIABノード1およびドナーノードであり、IABノード3の上流のノードは端末1およびIABノード4であり、IABノード3のネクストホップノードはIABノード1である。パスは、端末1→IABノード4、IABノード4→IABノード3、IABノード3→IABノード1、およびIABノード1→ドナーノードの4つのリンクを含む。
本願の実施形態は、パス変更方法を提供する。本方法は、無線アクセスネットワークに適用される。無線アクセスネットワークは、端末、無線バックホールノード、およびドナーノードを含む。無線バックホールノードは、無線バックホールノードに無線でアクセスするノードに無線バックホールサービスを提供するように構成されている。端末は、無線バックホールノードを介してドナーノードと通信する。図7に示されるように、本方法は以下のステップを含む。
701.第1のノードは、第1のノードと第2のノードとの間に第1のパスおよび第2のパスを確立する。
第1のノードおよび第2のノードは、どちらも無線アクセスネットワークのノードである。
第1のノードは、完全なドナーノード、ドナーノードのDU、ドナーノードのCU、または無線バックホールノード(例えば、IABノードまたはRN)であり得る。この場合、第2のノードは無線バックホールノードまたは端末であり得る。
第1のノードはまた、無線バックホールノードまたは端末であり得る。この場合、第2のノードは、完全なドナーノード、ドナーノードのDU、ドナーノードのCU、または無線バックホールノードであり得る。
第1のノードは、第1のノードと第2のノードとの間に複数のパスを確立することができ、複数のパスは、第1のパスおよび第2のパスを含むことに留意されたい。第1のパスおよび第2のパスは、複数のパスのうちの任意の2つのパスであり得る。第1のパス上の少なくとも1つのノードは、第2のパス上のノードとは異なる。第1のパスおよび第2のパスの少なくとも1つのパスは、少なくとも2つのリンクを含む。
複数のパスは、1つのメインパスおよび1つ以上のスタンバイパスを含み得る。第1のパスがメインパスである場合、第2のパスはスタンバイパスであり得る。第1のパスがスタンバイパスである場合、第2のパスはメインパスまたはスタンバイパスであり得る。
702.第1のノードは、第1のパスを通じてデータパケットを第2のノードに送信する。
本願の実施形態のデータパケットに含まれるペイロード(payload)は、制御プレーンシグナリングまたはユーザプレーンデータであり得る。あるいは、本願の実施形態におけるデータパケットは、サービスデータユニット(service data unit、略してSDU)またはプロトコルデータユニット(protocol data unit、略してPDU)であり得る。本願の実施形態におけるデータパケットは、ダウンリンクデータパケットまたはアップリンクデータパケットであり得る。
第2のノードが無線バックホールノードの場合、データパケットのペイロードはF1APメッセージであり得(この場合、第2のノードはネットワーク内のDUとして機能し、例えばIABノードのDUであり得る)、またはユーザプレーンデータまたはRRCメッセージであり得る。ユーザプレーンデータまたはRRCメッセージは、第2のノード(この場合、第2のノードは、ネットワーク内の端末として機能し、例えば、IABノードのMTであり得る)に属するか、または第2のノードによってサービスされる端末に属することができる。ユーザプレーンデータまたはRRCメッセージが第2のノードによってサービスされる端末に属する場合、第2のノードはその後、ユーザプレーンデータまたはRRCメッセージを対応する端末に送信することができる。
第2のノードが端末である場合、データパケットのペイロードは、第2のノードのユーザプレーンデータまたはRRCメッセージであり得る。
703.第1のノードがパス変更条件が満たされていると決定すると、第1のノードは、データパケットを第2のノードに送信するために、第1のパスから第2のパスに変更する。
パス変更条件は、次の条件のうちの1つ以上を含み得る。
(1)データパケットがアップリンクデータパケットであり、第1のノードは、第1のプリセット期間内に、第1のネクストホップノードによって割り当てられたスケジューリングリソースを取得しておらず、第1のネクストホップノードは、第1のパス上の第1のノードのネクストホップノードである。
本願のこの実施形態では、第1のノードに割り当てられたスケジューリングリソースは、アップリンクデータパケットを送信するために第1のノードによって使用される無線リソースであり得る。
通信ネットワークにおいて、データパケットがアップリンクデータパケットである場合、ノードのスケジューリングリソース(すなわち、アップリンクデータパケットを送信するために第1のノードによって使用される無線リソース)は、ノードのネクストホップノード(または親ノード)によって割り当てられ得る(またはスケジュールされ得る)ことに留意されたい。ネクストホップノードは、ネクストホップノードとノードとの間のリンクのリンクステータスまたはネクストホップノードのビジー度に基づいて、スケジューリングリソースをノードに割り当てるかどうかを決定する。したがって、本願のこの実施形態では、第1のノードが長期間(例えば、第1のプリセット期間内)に、第1のノードのネクストホップノードによって割り当てられたスケジューリングリソースを取得していない場合、これは、第1のパス上の第1のノードと第1のノードのネクストホップノードとの間のリンクの状態が悪いか、または第1のノードのネクストホップノードのビジー度が高いことを示す。この場合、第1のノードは、第2のパスを通じて第2のノードにデータパケットを送信することができる。
第1のノードがパス変更条件に基づいてパスを変更し、第1のパスがアップリンクデータパケットの送信にリソース保証を提供できないことを学習した場合、第1のノードは、端末のサービスへの影響を回避するために、できるだけ早くパスを変更することができる。
任意選択で、第1のネクストホップノードが、第1のパス上の第1のネクストホップノードの後の任意の2つの下流のノード間のリンクのリンクステータスが悪い、または任意の下流のノードのビジー度が高いと決定した場合、第1のネクストホップノードは、第1のノードにリソースを割り当てない場合がある。この場合、第1のノードから第1のネクストホップノードに送信された後、データパケットが送信され続けることができないことを回避することができる。
本願のこの実施形態におけるリンクの不良なリンクステータスは、リンクの輻輳、リンクの中断、リンクの遮断、不十分なリンクリソースなどであり得ることに留意されたい。ノードのビジー度は、無線リソースの使用率またはノードのバッファステータスによって表され得る。例えば、ノードの無線リソース使用率またはノードのバッファリングされたデータパケットの総データ量が特定の閾値よりも大きい場合、ノードのビジー度が高いと決定され得る。
例えば、図1を参照すると、第1のパスは、IABノード4→IABノード2→IABノード1→ドナーノードであり、第2のパスは、IABノード4→IABノード3→IABノード1→ドナーノードである。第1のノードはIABノード4であり、第2のノードはドナーノードである。IABノード4が、第1のプリセット期間内に、IABノード2によって割り当てられたスケジューリングリソースを取得していない場合、IABノード4は、第2のパスを通じてデータパケットをドナーノードに送信することを決定することができる。IABノード2とIABノード4との間のリンクのステータスが悪いか、IABノード2のビジー度が高い場合、IABノード2は、スケジューリングリソースをIABノード4に割り当てない場合があり、またはIABノード1またはドナーノードのビジー度が高い場合、IABノード4にスケジューリングリソースを割り当てない場合がある。
(2)第1のノードにおいてバッファリングされ、第1のネクストホップノードに送信されるデータパケットの総データ量(data volume)が、第1のプリセット値以上である。
第1のノードと第1のノードのネクストホップノードとの間のリンクのリンクステータスが悪いほど、第1のノードにおいてバッファリングされ、ネクストホップノードに送信されるデータパケットがより多いことを示すことに留意されたい。したがって、第1のノードにおいてバッファリングされて第1のネクストホップノードに送信されるデータパケットが多いほど、第1のノードと第1のネクストホップノードとの間のリンクのリンクステータスが不良であることを示す。この場合、第1のノードは、第2のパスを通じて第2のノードにデータパケットを送信することができる。
さらに、第1のノードは、各ネクストホップノードにバッファスペースを割り当てることができる。この場合、パス変更条件(2)は、次のように置き換えることができる。第1のノードによって第1のパス上の第1のノードのネクストホップノードに割り当てられたバッファスペースの占有率が、第1のプリセット値以上である。
第1のノードがパス変更条件に基づいてパスを変更する場合、第1のノードにおいてバッファリングされたデータパケットが過度に長い時間待機する必要があり、さらにはリンクステータスの不良により破棄されるケース(例えば、バッファオーバーフローによりデータパケットが破棄される)を回避できる。
例えば、図1を参照すると、第1のパスは、IABノード4→IABノード2→IABノード1→ドナーノードであり、第2のパスは、IABノード4→IABノード3→IABノード1→ドナーノードである。第1のノードはIABノード4であり、第2のノードはドナーノードであり、第1のプリセット値は1.5(GB)である。IABノード4においてバッファリングされてIABノード2に送信されるデータパケットの総データ量が2GBであり、IABノード4においてバッファリングされてIABノード3に送信されるデータパケットの総データ量が1GBである場合、IABノード2に送信されるデータパケットの総データ量が第1のプリセット値以上であるとIABノード4が決定した場合、IABノード4は、第2のパスを通じてデータパケットを第2のノードに送信する。
(3)第1のパス上の少なくとも1つのリンクの少なくとも1つのリンク品質評価パラメータが、対応するプリセット値以下である。
1つ以上のリンク品質評価パラメータが存在し得る。リンクの少なくとも1つのリンク品質評価パラメータが対応するプリセット値以下である場合、第1のノードは、リンクのリンクステータスが悪いと決定することができる。言い換えれば、第1のノードは、第1のパス上の1つ以上のリンクのリンクステータスが悪いと決定した場合、第2のパスを通じて第2のノードにデータパケットを送信することができる。
可能な実装では、少なくとも1つのリンク品質評価パラメータは、基準信号受信電力(reference signal received power、略してRSRP)、基準信号受信品質(reference signal received quality、略してRSRQ)、受信信号強度インジケータ(receive signal strength indicator、略してRSSI)、信号対干渉+ノイズ比(signal to interference plus noise ratio、略してSINR)、およびチャネル品質インジケータ(channel quality indicator、略してCQI)のパラメータのうちの少なくとも1つを含む。
RSRP、RSRQ、RSSI、SINR、およびCQIはそれぞれ、アップリンクパラメータまたはダウンリンクパラメータであり得る。第1のノードは、測定を通じて、第1のノードと他のノードとの間のアップリンクおよび/またはダウンリンクのリンク品質評価パラメータを取得し、他のノード間のアップリンクおよび/またはダウンリンクのリンク品質評価パラメータをさらに受信し、これらのリンク品質評価パラメータに基づいて、リンクステータスが十分に良好であるかどうかを決定することができ、それによってユーザデータパケットに高品質の送信サービスを提供する。
例えば、図1に示されるネットワークアーキテクチャに基づいて、IABノード1は、測定を通じて、IABノード2とIABノード1との間のアップリンクのリンク品質評価パラメータと、IABノード3とIABノード1との間のアップリンクのリンク品質評価パラメータとを取得することができる。IABノード1は、IABノード2とIABノード1との間のダウンリンクのリンク品質評価パラメータと、IABノード3とIABノード1との間のダウンリンクのリンク品質評価パラメータとをさらに受信することができ、リンク品質評価パラメータは、IABノード2およびIABノード3によって測定を通じて取得される。IABノード1は、IABノード2とIABノード4との間のアップリンクのリンク品質評価パラメータと、IABノード3とIABノード4との間のアップリンクのリンク品質評価パラメータとをさらに受信することができ、リンク品質評価パラメータは、IABノード2およびIABノード3によって測定を通じて取得される。さらに、IABノード1は、IABノード2とIABノード4との間のダウンリンクのリンク品質評価パラメータと、IABノード3とIABノード4との間のダウンリンクのリンク品質評価パラメータとを受信することができ、リンク品質評価パラメータは、IABノード4によって測定を通じて取得される。
例えば、少なくとも1つのリンク品質評価パラメータはRSRPであり、データパケットはアップリンクデータパケットである。この場合、第1のノードによって測定を通じて取得されたIABノード2とIABノード1との間のアップリンクのRSRPが、RSRPに対応するプリセット値以下であると第1のノードが決定すると、第1のノードは、IABノード2とIABノード1との間のアップリンクのリンクステータスが悪く、ユーザデータパケットに高品質の送信サービスを提供できないと決定する。データパケットがダウンリンクデータパケットである場合、IABノード2とIABノード1との間のダウンリンクのIABノード2によって送信された受信RSRPが、RSRPに対応するプリセット値以下であると第1のノードが決定すると、第1のノードは、IABノード2とIABノード1との間のダウンリンクのステータスが悪いと決定する。他のリンクのリンクステータスを決定するプロセスも同様であり、詳細はここでは再度説明しない。
なお、少なくとも1つのリンク品質評価パラメータが、RSRP、RSRQ、RSSI、SINR、およびCQIという複数のパラメータを含む場合、複数のパラメータのそれぞれが1つのプリセット値に対応し得ることに留意されたい。第1のノードは、リンクに対応する複数のパラメータのそれぞれが対応するプリセット値以下である場合にのみ、リンクのリンクステータスが悪いと決定することができる。
他の可能な実装では、リンク品質評価パラメータは、RSRP、RSRQ、RSSI、SINR、およびCQIのうちの少なくとも2つのパラメータに基づいて計算されたパラメータである。
リンク品質評価パラメータが、RSRP、RSRQ、RSSI、SINR、およびCQIのうちの少なくとも2つのパラメータに基づいて計算されたパラメータである場合、RSRP、RSRQ、RSSI、SINR、およびCQIの異なるパラメータに基づいて計算されたリンク品質評価パラメータは異なる。例えば、RSRPおよびRSRQに基づいて計算されたパラメータは、リンク品質評価パラメータであり得、RSRQおよびRSSIに基づいて計算されたパラメータは、他のリンク品質評価パラメータであり得る。第1のノードは、1つ以上の計算されたリンク品質評価パラメータに基づいて、リンクのリンクステータスが悪いかどうかを決定することができる。
具体的には、第1のノードは、リンク品質評価パラメータを取得するために、RSRP、RSRQ、RSSI、SINR、およびCQIのうちの少なくとも2つのパラメータに対して操作(例えば、合計操作または重み付け操作)を実行することができる。
第1のノードがリンクのリンク品質評価パラメータに基づいてリンクのRSRP、RSRQ、RSSI、SINR、およびCQIの1つ以上のパラメータを取得する方法の場合、リンクのリンクステータスが悪いかどうかは前述の説明を参照されたく、詳細はここでは再度説明しない。
第1のノードがパス変更条件に基づいてパスを変更すると、リンク品質評価パラメータは、リンクによって満たされ得るサービス要件を間接的に表す可能性があるため、第1のパス上のいずれかのリンクのリンク品質評価パラメータが要件を満たしていない場合、第1のノードは、サービス要件が満たされないケースを回避するために、データパケットを第1のパスから送信用の他のパスに変更することができる。
リンクステータスを評価するために使用されるリンク品質評価パラメータは、各ノードがリンク品質評価パラメータに基づいてリンクのリンクステータスを決定できるように、各ノードに構成され得ることに留意されたい。実装例では、各ノードに設定されるリンク品質評価パラメータは、RSRP、SINR、およびCQIを含み得る。他の実装例では、各ノードに構成されるリンク品質評価パラメータは、第1のパラメータおよび第2のパラメータを含み得る。第1のパラメータは、RSRQおよびRSSIに基づいて計算されたリンク品質評価パラメータであり、第2のパラメータは、SINRおよびCQIに基づいて計算されたリンク品質評価パラメータである。
(4)第1のパス上のいずれか1つ以上のリンクが中断される。
リンクの中断は、具体的には次のいくつかの場合である。1.リンクがブロックされている。2.リンクで無線リンク障害(RLF)が発生する。3.リンク上で使用可能なすべてのビーム(beam)でビーム障害(beam failure)が発生する。4.リンク上のエンドノードのMAC層での再送信の量が最大値に達する。5.RLC確認応答モード(acknowledgement mode、略してAM)で、リンク上のエンドノードのRLC層での再送信の量が最大値に達する。
リンクの中断は、アップリンクの中断またはダウンリンクの中断であり得ることに留意されたい。例えば、ノードAがノードBの親ノードであり、データパケットがアップリンクデータパケットである場合、ノードBのRLC層でのデータパケットの再送信の量が最大値に達すると、ノードBは、ノードAとノードBとの間のアップリンクが中断されていると決定することができる。ノードAがノードBの親ノードであり、データパケットがダウンリンクデータパケットである場合、ノードAのRLC層でのデータパケットの再送信の量が最大値に達すると、ノードAは、ノードAとノードBとの間のダウンリンクが中断されていると決定することができる。
第1のノードは、第1のノードと他のノードとの間のアップリンクおよび/またはダウンリンクが中断されているかどうかを決定し、他のノード間のアップリンクおよび/またはダウンリンクが中断されているかどうかを示す情報をさらに受信することができる。
例えば、図1に示されるネットワークアーキテクチャに基づいて、IABノード1は、IABノード2とIABノード1との間のダウンリンク、およびIABノード3とIABノード1との間のダウンリンクが中断されているかどうかを決定することができる。IABノード1は、IABノード2およびIABノード3によって決定され、IABノード2とIABノード1との間のアップリンクと、IABノード3とIABノード1との間のアップリンクが中断されているかどうかを示す情報をさらに受信することができる。IABノード1は、IABノード2およびIABノード3によって決定され、IABノード2とIABノード4との間のダウンリンクと、IABノード3とIABノード4との間のダウンリンクが中断されているかどうかを示す情報をさらに受信することができる。さらに、IABノード1は、IABノード4によって決定され、IABノード2とIABノード4との間のアップリンクと、IABノード3とIABノード4との間のアップリンクが中断されているかどうかを示す情報を受信することができる。
第1のノードがパス変更条件に基づいてパスを変更し、第1のパス上のいずれかのリンクが中断された場合、第1のノードは、データパケットが正しくかつ効果的に送信され得るように、データパケットを第1のパスから送信用の他のパスに変更することができる。
(5)第1のノードがパス変更命令を受信しており、パス変更命令は、データパケットの送信パスを変更するよう指示するために使用される。
第1のノードが、パス変更条件(5)に基づいて、パスを変更するかどうかを決定するとき、任意選択で、この方法は、第5のノードによって、第1のノードにパス変更命令を送信するステップをさらに含む。これに対応して、第1のノードは、第5のノードからパス変更命令を受信する。
第5のノードは、第1のパス上のノードであり得、パス変更命令を第1のノードに直接送信し得るか、またはパス変更命令を1つ以上の他のノードを介して第1のノードに送信し得る。
具体的には、第5のノードは、第5のノードのF1AP層とピアリングされたF1AP層を使用することにより、パス変更命令を第1のノードに送信することができる。これに対応して、第1のノードは、第1のノードのF1AP層とピアリングされたF1AP層を使用することにより、第1のノードのF1AP層で第5のノードからパス変更命令を受信することができる。第1のノードおよび第5のノードは、それぞれピアF1AP層を有することができる。
ネットワーク内の第5のノードおよび第1のノードの役割は次のとおりである。
ケース1:第1のノードはドナーノード、ドナーノードのCU、またはドナーノードのDUであり、データパケットはダウンリンクデータパケットであり、第5のノードは第1のパス上の第1のノードの下流のノードである。
ケース2:第1のノードは無線バックホールノードであり、第5のノードは第1のパス上の第1のノードの下流のノードである。
ケース1およびケース2の場合、第5のノードとデータパケットの宛先ノードとの間のパス上の1つ以上のリンクが混雑または中断されていると決定すると、第5のノードは、第1のノードにパス変更命令を送信することができる。あるいは、他のノード(例えば、ドナーノードまたはドナーノードのCU)によって送信されたパス変更命令を受信した後、第5のノードが、パス変更命令に従って、第1のノードもパスを変更する必要があると決定した場合、第5のノードは、第1のノードにパス変更命令を送信することができる。
ケース3:第1のノードはドナーノードのDUであり、データパケットはダウンリンクデータパケットであり、第5のノードはドナーノードのCUである。
ケース4:第1のノードは無線バックホールノードであり、第5のノードはドナーノードまたはドナーノードのCUである。
パス変更条件に基づいてパスを変更する場合、第1のノードは他のノードの指示に従ってパスを変更する。ある場合には、第5のノードは、ドナーノードまたはドナーノードのCUであり、ドナーノードまたはドナーノードのCUは、ネットワーク内の各リンクのステータスを取得することができる。したがって、第5のノードは、データパケットの正しい送信を保証するために、第1のノードにパスを変更するように正確に指示することができる。他の場合には、第5のノードは、第1のパス上の第1のノードの下流のノードである。第1のパス上のリンクの悪いリンクステータスを認識すると、下流のノードは、データパケットの正しい送信を保証するために、パス変更命令を第1のノードに直接送信して、パスを変更するように第1のノードに指示することができる。
任意選択で、パス変更条件は、以下の条件のうちの少なくとも1つをさらに含む。
(6)データパケットがアップリンクデータパケットであり、第1のノードは、第2のプリセット期間内に、第2のネクストホップノードによって割り当てられたスケジューリングリソースを取得しており、第2のネクストホップノードは、第2のパス上の第1のノードのネクストホップノードである。
(7)第1のノードにおいてバッファリングされ、第2のネクストホップノードに送信されるデータパケットの総データ量が、第2のプリセット値以下である。
(8)第2のパス上の各リンクの少なくとも1つのリンク品質評価パラメータが、対応するプリセット値以上である。
なお、パス変更条件(8)における少なくとも1つのリンク品質評価パラメータは、パス変更条件(3)における少なくとも1つのリンク品質評価パラメータと同じであっても異なっていてもよく、パス変更条件(8)における少なくとも1つのリンク品質評価パラメータに対応するプリセット値は、パス変更条件(3)における少なくとも1つのリンク品質評価パラメータに対応するプリセット値と同じであっても異なっていてもよい。
(9)第2のパス上のリンクのいずれもが中断されていない。
パス変更条件(6)、(7)、(8)、および(9)が満たされているかどうかを第1のノードによって決定する方法は、パス変更条件(1)、(2)、(3)、および(4)が満たされているかどうかを決定する方法と同じであり、詳細は本明細書で再び説明されない。
パス変更条件(6)、(7)、(8)、および(9)が満たされているかどうかを決定することによって、第1のノードはさらに、第2のパス上のリンクのリンクステータスを決定することができる。第2のパス上の各リンクのリンクステータスが良好である場合、第1のノードは、データパケットの正しい送信を保証するために、第2のパスを通じて第2のノードにデータパケットを送信する。さらに、第1のノードは、パスがパス変更条件(6)、(7)、(8)、および(9)を満たすかどうかを決定することによって、第1のノードと第2のノードとの間の複数のパスから第2のパスをさらに選択することができる(言い換えれば、パス変更条件(6)、(7)、(8)、および(9)を満たす複数のパスの中のパスは、第2のパスである)。
前述の実施形態では、第1のプリセット期間、第2のプリセット期間、第1のプリセット値、第2のプリセット値、およびリンク品質評価パラメータに対応するプリセット値は、実際の適用シナリオに基づいて設定することができる。第1のプリセット期間と第2のプリセット期間は同じであっても異なっていてもよく、第1のプリセット値と第2のプリセット値は同じであっても異なっていてもよい。
本願の実施形態におけるデータパケットは、ペイロードおよびプロトコル層ヘッダを含み得る。プロトコル層ヘッダは、宛先ノードの識別子および/またはパスラベルを含み得る。宛先ノードの識別子は、データパケットの宛先ノードを識別するために使用され、パスラベルは、データパケットの送信パスを識別するために使用される。
データパケットが宛先ノードの識別子のみを運ぶ場合、第1のノードは、宛先ノードの識別子と維持されているルートマッピングテーブルとに基づいてルート選択を実行する。第1のノードはデータパケットを変更する必要はなく、第2のネクストホップノードを介して宛先ノードにデータパケットを送信するだけでよい。
データパケットがパスラベルを運ぶ場合、パス変更を実行するとき、第1のノードは、パス変更後に、運ばれたパスラベルをパスに対応するパスラベル(すなわち、第2のパス)に置き換え、次に第2のネクストホップノードを介して宛先ノードにデータパケットを送信することができる。あるいは、第1のノードは、元のパスラベルに加えて第2のパスに対応するパスラベルをカプセル化し、次に、第2のネクストホップノードを介して宛先ノードにデータパケットを送信する。
本願のこの実施形態で提供される方法によれば、パス変更条件が満たされていると決定するとき、第1のノードは、IABネットワークのマルチ接続シナリオで提供される柔軟なルーティング機能を完全に使用できるように、第2のパスを通じて第2のノードにデータパケットを送信できる。データパケットが1つのパスを通じて送信できない場合、データパケットは他のパスを通じて送信されるため、データパケット送信効率とネットワーク信頼性が向上する。
任意選択で、第1のノードは無線バックホールノードまたはドナーノードのDUであり、この方法は次のステップをさらに含む。
(11)第1の無線デバイスは、構成情報を第1のノードに送信し、構成情報は、パス変更条件および/またはルートマッピングテーブルを含む。
第1のノードが無線バックホールノードである場合、第1の無線デバイスはドナーノードまたはドナーノードのCUである、または、第1のノードがドナーノードのDUである場合、第1の無線デバイスはドナーノードのCUである。第1の無線デバイスは、構成情報を第1のノードに直接送信することができ、または構成情報を他のノード(例えば、IABノード)を介して第1のノードに送信することができる。
ルートマッピングテーブルは、データパケットを受信するネクストホップノードを決定するために第1のノードによって使用され、パス変更条件は、パスを変更するかどうかを決定するために第1のノードによって使用される。
第1のノードのパス変更条件およびルートマッピングテーブルは、別々に構成することも、一緒に構成することもできる。さらに、パス変更条件およびルートマッピングテーブルは、第1のノードで事前設定することもできる。例えば、構成情報がパス変更条件を含む場合、ルートマッピングテーブルは第1のノードで事前構成することができ、または、構成情報がルートマッピングテーブルを含む場合、パス変更条件は第1のノードで事前構成することができる。
(12)第1のノードが、第1の無線デバイスから構成情報を受信する。
ステップ(12)の後、第1のノードは、ルートマッピングテーブルに基づいて、データパケットを受信するネクストホップノードを決定し、パス変更条件に基づいて、パスを変更するかどうかを決定することができる。
具体的な実施に際して、ステップ(11)は、第1の無線デバイスによって、第1の無線デバイスの第1のプロトコル層とピアリングされた第1のプロトコル層を使用することによって、構成情報を第1のノードに送信するステップを含み得る。それに対応して、具体的な実施に際して、ステップ(12)は、第1のノードによって、第1のノードの第1のプロトコル層とピアリングされた第1のプロトコル層を使用することによって、第1のノードの第1のプロトコル層において第1の無線デバイスから構成情報を受信するステップを含み得る。
この場合、第1の無線デバイスおよび第1のノードは、それぞれピアの第1のプロトコル層がある。
第1のプロトコル層には、次のいくつかのケースがある。
ケース(1):第1のプロトコル層は、以下の機能、すなわち、第1のノードに識別可能なルーティング情報をデータパケットに追加すること、第1のノードに識別可能なルーティング情報に基づいてルート選択を実行すること、QoS要件に関連し、第1のノードに識別可能な識別情報をデータパケットに追加すること、第1のノードを含む複数のリンクでデータパケットのQoSマッピングを実行すること、パケットタイプ指示情報をデータパケットに追加すること、およびフロー制御機能を有するノードにフロー制御フィードバック情報を送信することのうちの少なくとも1つを有する。
この場合、第1のプロトコル層は前述のBAP層である。
ケース(2):第1のプロトコル層は、第1のノードと第1の無線デバイスとの間で制御プレーンメッセージを運ぶように構成され、制御プレーンメッセージは、以下のメッセージ、すなわち、第1のノードと第1の無線デバイスとの間のインタフェースの管理に関連するメッセージ、第1のノードと第1の無線デバイスとの間のインタフェースの構成更新に関連するメッセージ、第1のノードのサブノードに関連するコンテキスト構成メッセージ、および第1のノードのサブノードのRRCメッセージを運ぶメッセージコンテナを含むメッセージのうちの少なくとも1つを含む。
この場合、第1のノードおよび第1の無線デバイスの一方がドナーノードのCUであり、他方がドナーノードのDUであるとき、第1のプロトコル層は、前述のF1AP層であり得る。第1のノードおよび第1の無線デバイスの一方が無線バックホールノードであり、他方がドナーノードであるとき、第1のプロトコル層は、前述のT1AP層であり得る。第1のノードおよび第1の無線デバイスの一方が無線バックホールノードであり、他方がドナーノードのCUであるとき、第1のプロトコル層は、前述のT1AP層またはF1AP層であり得る。
ケース(3):第1のプロトコル層はRRC層である。
任意選択で、ステップ(12)の後、この方法は、第1のノードによって、第1の無線デバイスに構成応答を送信するステップをさらに含み得、構成応答は、パス変更条件および/またはルートマッピングテーブル構成が完了/失敗/部分的に完了したことを示すために使用される。それに対応して、第1の無線デバイスは、第1のノードから構成応答を受信し、構成応答に基づいて、第1のノードのパス変更条件の構成および/またはルートマッピングテーブルの構成が完了/失敗/部分的に完了したことを決定する。
任意選択で、ステップ702の前に、方法は以下のステップをさらに含む場合がある。
(21)第1のノードは、データパケットで運ばれる第1のルーティング情報を除去し、第1のルーティング情報は、データパケットが通過する少なくとも1つの第3のノードを示すために使用され、第3のノードは、第1のノードの上流のノードである。この場合、具体的な実施に際して、ステップ702は、第1のノードによって、第1のルーティング情報が除去されたデータパケットを第2のノードに送信するために第1のパスから第2のパスに変更するステップを含み得る。
第1のルーティング情報は、データパケットで運ばれるルーティング情報の一部であり得る。任意の方法では、第1のノードが下流のノードについて無効なルーティング情報を除去できるため、データパケット送信効率が向上する。もちろん、第1のノードは代わりにルーティング情報を除去しない可能性もある。代わりに、データパケットを送信する最後のノードが、データパケットのすべてのルーティング情報を除去する。
例えば、図1に示されるネットワークアーキテクチャに基づいて、第1のノードがIABノード1の場合、ドナーノードが3つのルーティング情報(パスラベル1(パスラベル1で指定された送信パスであり、ドナーノード→IABノード1である)、IABノード4の識別子、および端末1の識別子)をデータパケットに追加すると、IABノード1は、ダウンリンクデータパケットを処理するときにパスラベル1を除去することができる。
任意選択で、ステップ702の前に、方法は以下のステップをさらに含む場合がある。
(31)第1のノードは、第2のルーティング情報をデータパケットに追加し、第2のルーティング情報は、データパケットが通過する少なくとも1つの第4のノードを示すために使用され、第4のノードは、第1のノードの下流のノードである。この場合、具体的な実施に際して、ステップ702は、第1のノードによって、第2のルーティング情報が追加されるデータパケットを第2のノードに送信するために第1のパスから第2のパスに変更するステップを含み得る。
あるいは、第1のノードは、ルーティング情報をデータパケットに追加することができ、その結果、後続のノードは、ルーティング情報に基づいてデータパケットを転送する。
例えば、図1に示されるネットワークアーキテクチャに基づいて、第1のノードがIABノード1の場合、ドナーノードが3つのルーティング情報(パスラベル1、IABノード4の識別子、および端末1の識別子)をデータパケットに追加すると、IABノード1は、パスラベル2をデータパケットに追加することができ、パスラベル2によって指定される送信パスは、IABノード1→IABノード2→IABノード4である。
前述の実施形態の具体的な実施に際して、第1のノードが複数のパスを通じて第2のノードにデータパケットを送信する能力を有することを可能にするために、第1のノードとネクストホップノードとの間の1つ以上のスタンバイリンクを第1のノードに構成することができる。これは、具体的には次の2つの方式で実施できる。
方式1:データパケットが宛先ノード、すなわち第2のノード)に基づいて転送され、第1のノードと宛先ノードとの間の複数のパスが第1のノードの複数のネクストホップノードを含む場合、宛先ノードに対応する複数のネクストホップノード(すなわち、第1のノードの複数のネクストホップノード)は、第1のノードのルートマッピングテーブルで構成することができる。言い換えると、ルートマッピングテーブルに基づいてデータパケットを転送する場合、第1のノードは、複数のネクストホップノードを介して宛先ノードにデータパケットを送信することができる。
例えば、図1に示されるネットワークアーキテクチャに基づいて、第1のノードがIABノード1であり、宛先ノードがIABノード4、端末1、または端末2である場合、第1のノードと宛先ノードとの間の複数のパスは、第1のノードの2つのネクストホップノード(IABノード2およびIABノード3)を含む。したがって、第1のノードのルートマッピングテーブルで構成されている宛先ノードに対応する複数のネクストホップノードは、IABノード2およびIABノード3である。詳細については、表1を参照されたい。
任意選択で、データパケットの送信元ノードおよび宛先ノードに対応する複数のネクストホップノードの優先順位、および宛先ノードに対応する複数のネクストホップノードのQoSラベルは、第1のノードのルートマッピングテーブルでさらに構成することができる。
ネクストホップノードの優先度は、第1のノードによってネクストホップノードを選択する優先順位を示すために使用される。第1のノードは、データパケットを宛先ノードに送信するために、優先度の高いネクストホップノードを優先的に選択する。例えば、表1を参照すると、宛先ノードがIABノード4の場合、第1のノードは2つのネクストホップノード(IABノード2とIABノード3)を選択でき、IABノード2およびIABノード3に対応する優先順位は、それぞれ1と2に設定できる。優先度の値が小さいほど優先度が高いことを示す場合、第1のノードは、データパケットを宛先ノードに送信するために、IABノード2を優先的に選択する。
宛先ノードが1つのネクストホップノードのみに対応する場合、または宛先ノードに対応する複数のネクストホップノードの優先度が同じである場合、ネクストホップノードの優先度を示すために使用されるフィールドは、第1のノードのルートマッピングテーブルで構成されていない可能性があることに留意されたい。
ネクストホップノードに対応するQoSラベルは、QoSラベルに対応するQoS要件を満たすデータパケットをネクストホップノードに送信する第1のノードを示すために使用される。
方式2:データパケットがパスラベルに基づいて転送され、第1のノードと宛先ノードとの間の複数のパスが第1のノードの複数のネクストホップノードを含む場合、パスラベルに対応する複数のネクストホップノード(すなわち、第1のノードの複数のネクストホップノード)は、第1のノードのルートマッピングテーブルで構成することができる。言い換えると、ルートマッピングテーブルに基づいてデータパケットを転送する場合、第1のノードは、複数のネクストホップノードを介して宛先ノードにデータパケットを送信することができる。
一例では、図1に示されるネットワークアーキテクチャに基づいて、ダウンリンクデータパケットについて、ドナーノードは、ドナーノードから端末への5つの異なる送信パスを識別するために使用される5つのパスラベルを定義することができる。5つのパスラベルで指定されている送信パスは次のとおりである。
パスラベル1で指定される送信パスは、ドナーノード→IABノード1→IABノード3→IABノード4→端末1である。
パスラベル2で指定される送信パスは、ドナーノード→IABノード1→IABノード2→IABノード4→端末1である。
パスラベル3で指定される送信パスは、ドナーノード→IABノード1→IABノード3→IABノード4→端末2である。
パスラベル4で指定される送信パスは、ドナーノード→IABノード1→IABノード2→IABノード4→端末2である。
パスラベル5で指定される送信パスは、ドナーノード→IABノード1→IABノード2→IABノード5→端末2である。
第1のノードがIABノード1である場合、メインパスおよび対応するネクストホップノードのパスラベルは、第1のノードのルートマッピングテーブルで構成することができ、スタンバイパスおよび対応するネクストホップノードのパスラベルは、第1のノードのルートマッピングテーブルでさらに構成することができる。詳細については、表2を参照されたい。
メインパスおよび対応するネクストホップノードのパスラベルはメインパス情報と呼ばれ得、スタンバイパスおよび対応するネクストホップノードのパスラベルはスタンバイパス情報と呼ばれ得る。
他の例では、図1に示されるネットワークアーキテクチャに基づいて、ドナーノードは、ドナーノードとIABノード4との間、およびドナーノードとIABノード5との間の3つの異なる送信パスを識別するために使用される3つのパスラベルをさらに定義することができる。3つのパスラベルで指定されている送信パスは次のとおりである。
パスラベル1で指定される送信パスは、ドナーノード→IABノード1→IABノード3→IABノード4である。
パスラベル2で指定される送信パスは、ドナーノード→IABノード1→IABノード2→IABノード4である。
パスラベル3で指定される送信パスは、ドナーノード→IABノード1→IABノード2→IABノード5である。
第1のノードがIABノード1である場合、メインパスおよび対応するネクストホップノードのパスラベルは、第1のノードのルートマッピングテーブルで構成することができ、スタンバイパスおよび対応するネクストホップノードのパスラベルは、第1のノードのルートマッピングテーブルでさらに構成することができる。詳細については、表3を参照されたい。
前述のパスラベルは、例としてダウンリンクデータパケットに対して定義されたパスラベルを使用して説明されていることに留意されたい。ドナーノードはまた、アップリンクデータパケットのパスラベル、2つのドナーノードのサービス範囲内のノード間のアップリンクデータパケットまたはダウンリンクデータパケットのパスラベルなどを定義することができる。
本願の一実施形態は、データパケット処理方法をさらに提供する。この実施形態のノードおよび前述の実施形態のノードは、同じノードであっても、異なるノードであってもよい。図8に示されているように、本方法は以下のステップを含む。
801.ネットワークデバイスがデータパケットを取得する。
ネットワークデバイスがドナーノードまたはドナーノードのCUである場合、データパケットはダウンリンクデータパケットである。ネットワークデバイスが端末に無線バックホールサービスを提供する無線バックホールノードである場合、データパケットはアップリンクデータパケットである。
データパケットの宛先ノードが無線バックホールノードである場合、データパケットのペイロードはT1APメッセージであり得る(この場合、宛先ノードはネットワーク内のDUとして機能し、例えば、宛先ノードはIABノードのDUであり得る)。あるいは、データパケットのペイロードは、ユーザプレーンデータまたはRRCメッセージであり得る(この場合、第2のノードはネットワーク内の端末として機能し、例えば、第2のノードはIABノードのMTであり得る)。
データパケットの宛先ノードが端末である場合、データパケットのペイロードは、ユーザプレーンデータまたはRRCメッセージであり得る。この場合、ネットワークデバイスは、端末によってアクセスされる無線バックホールノードを介してデータパケットを端末に送信することができる。無線バックホールノードによって受信されるデータパケットは、BAP PDUであり得る。無線バックホールノードは、BAP PDU内のPDCP PDUを端末に送信し、PDCP PDUは、端末のユーザプレーンデータまたは端末のRRCメッセージを含む。
802.ネットワークデバイスは、データパケットにルーティング情報を追加し、ルーティング情報は、データパケットが通過するいくつかのノードを含み、ネットワークデバイスとデータパケットの宛先ノードとの間の複数の送信パスは、いくつかのノードを含み、複数の送信パスのうちの少なくとも2つは、パブリックノードと、パブリックノードとパブリックノードの複数のネクストホップノードとの間のリンクと、を含む。
具体的には、ネットワークデバイスは、複数のルーティング情報をデータパケットに追加することができ、複数のルーティング情報は、データパケットが通過するいくつかのノードを含む。ルーティング情報は、パスラベルおよび/またはノード識別子を含み得る。例えば、ルーティング情報(またはルーティング情報コンテンツ)は、データパケットの宛先ノードと、送信パス上のいくつかの無線バックホールノードを含み得る。
データパケットは、ペイロードおよびプロトコル層ヘッダを含み得る。ステップ802の後、データパケットのプロトコル層ヘッダは、以下の情報のうちの1つ以上を含み得る:ルーティング情報の量(追加されたルーティング情報の量を示すために使用される)、ルーティング情報タイプ(追加されたルーティング情報のタイプ、例えばパスラベルやノード識別子などを示すために使用される)、ルーティング情報の長さ(追加されたルーティング情報の長さを示すために使用され、長さはビット単位である場合がある)、およびルーティング情報コンテンツ(特定のルーティング情報を示すために使用される)。例えば、前述の情報は、データパケットのBAP層ヘッダ情報で運ばれ得る。
803.ネットワークデバイスがデータパケットを第6のノードに送信する。
第6のノードは、複数の送信パスのうちの任意の2つに含まれるパブリックノードであり、2つの送信パスは、第6のノードと第6のノードの複数のネクストホップノードとの間のリンクをさらに含む。
ネットワークデバイスは、データパケットを第6のノードに直接送信することができ、またはデータパケットを1つ以上のノードを介して第6のノードに送信することができる。
任意選択で、図8に示される方法は、以下のステップ804をさらに含む。
804.第6のノードは、ネットワークデバイスからデータパケットを受信し、データパケットで運ばれるルーティング情報に基づいて複数のネクストホップノードから第7のノードを選択し、データパケットを第7のノードに送信する。
図8に示される方法では、ネットワークデバイスによってデータパケットに追加されるルーティング情報は、決定された送信パスを指定しない。この場合、パブリックノードは、図8に示される方法を使用することにより、必要に応じてネクストホップノードを選択することができる。もちろん、ネットワークデバイスによってデータパケットに追加されるルーティング情報は、代わりに、決定された送信パスを指定することができる。この場合、送信パス上の各ノードは、ルーティング情報に基づいてデータルーティングを実行する。詳細は本明細書では説明されない。
さらに、第6のノードは、ルーティングポリシーおよびデータパケットで運ばれるルーティング情報に基づいて、複数のネクストホップノードから第7のノードを選択することができる。ルーティングポリシーは、ルートマッピングテーブルおよび前述のパス変更条件の1つ以上を含み得るか、または他のルーティングポリシーであり得る。第6のノードは、ルーティングポリシーのルートマッピングテーブルに基づいて複数のネクストホップノードを決定し、次に、ルーティングポリシーの1つ以上のパス変更条件に基づいて、複数のネクストホップノードから第7のノードを決定することができる。
可能な実装において、第6のノードがルーティングポリシーのルートマッピングテーブルに基づいて複数のネクストホップノードを決定している場合、ルーティングポリシーのすべてのパス変更条件が満たされていると第6のノードが決定すると、第6のノードは、スタンバイパス上の第6のノードのネクストホップノード(つまり、第7のノード)を介して、データパケットの宛先ノードにデータパケットを送信することができる。ルーティングポリシーのパス変更条件のいずれも満たされていないと第6のノードが決定した場合、第6のノードは、メインパス上の第6のノードのネクストホップノード(つまり、第7のノード)を介して、データパケットの宛先ノードにデータパケットを送信することができる。
他の可能な実装において、第6のノードがルーティングポリシーのルートマッピングテーブルに基づいて複数のネクストホップノードを決定している場合、ルーティングポリシーのいずれかのパス変更条件が満たされていると第6のノードが決定すると、第6のノードは、スタンバイパス上の第6のノードのネクストホップノード(つまり、第7のノード)を介して、データパケットの宛先ノードにデータパケットを送信することができる。ルーティングポリシーのパス変更条件のいずれも満たされていないと第6のノードが決定した場合、第6のノードは、メインパス上の第6のノードのネクストホップノード(つまり、第7のノード)を介して、データパケットの宛先ノードにデータパケットを送信することができる。
スタンバイパスおよびメインパスはどちらも、第6のノードとデータパケットの宛先ノードとの間のパスである。例えば、第1のノードおよび第6のノードが同一ノードであり、データパケットの宛先ノードが第2のノードである場合、メインパスは前述の第1のパスであり、スタンバイパスは前述の第2のパスであり得る。パス変更条件は、図7に記載された実施形態におけるパス変更条件(1)から(9)のうちの1つ以上を含み得る。
図1に示されるネットワークアーキテクチャを例として使用して、ドナーノードが、端末1に送信される必要があるダウンリンクデータパケットにルーティング情報を追加するプロセスは、以下のとおりである。
ドナーノードは、3つのルーティング情報、すなわちパスラベル1、IABノード4の識別子、および端末1の識別子をデータパケットに追加する。パスラベル1で指定される送信パスは、ドナーノード→IABノード1である。
ドナーノードは、パスラベル1に基づいてダウンリンクデータパケットをIABノード1に送信する。IABノード1は、ルーティングポリシーおよびIABノード4の識別子に基づいて、IABノード2およびIABノード3から1つのノードを選択し、ノードを介してダウンリンクデータパケットをIABノード4に送信する。ダウンリンクデータパケットを受信した後、IABノード4は、ダウンリンクデータパケットを端末1に送信する。
任意選択で、第6のノードがデータパケットを第7のノードに送信する前に、この方法は以下のステップをさらに含む。
(41)第6のノードは、データパケットで運ばれる第3のルーティング情報を除去し、第3のルーティング情報は、データパケットが通過する少なくとも1つの第8のノードを示すために使用され、第8のノードは、第6のノードの上流のノードである。この場合、第6のノードによって第7のノードにデータパケットを送信するステップは、第6のノードによって、第3のルーティング情報が除去されたデータパケットを第7のノードに送信するステップを含む。
第3のルーティング情報は、ネットワークデバイスによってデータパケットに追加されるルーティング情報の一部であり得る。任意の方法では、第6のノードが下流のノードについて無効なルーティング情報を除去できるため、データパケット送信効率が向上する。もちろん、第6のノードは代わりにルーティング情報を除去しない可能性もある。代わりに、データパケットを送信する最後のノード(例えば、端末、ドナーノード、またはドナーノードのDUによってアクセスされるIABノード)は、データパケットのすべてのルーティング情報を除去する。
例えば、図1に示されるネットワークアーキテクチャに基づいて、ドナーノードによってデータパケットに追加される3つのルーティング情報が、パスラベル1、IABノード4の識別子、および端末1の識別子である場合、IABノード1は、ダウンリンクデータパケットを処理するときにパスラベル1を除去することができる。
任意選択で、第6のノードがデータパケットを第7のノードに送信する前に、この方法は以下のステップをさらに含む。
(51)第6のノードは、第4のルーティング情報をデータパケットに追加し、第4のルーティング情報は、データパケットが通過する少なくとも1つの第9のノードを示すために使用され、第9のノードは、第6のノードの下流のノードである。この場合、第6のノードによって第7のノードにデータパケットを送信するステップは、第6のノードによって、第4のルーティング情報が追加されるデータパケットを第7のノードに送信するステップを含む。
あるいは、第6のノードは、ルーティング情報をデータパケットに追加することができ、その結果、後続のノードは、ルーティング情報に基づいてデータパケットを転送する。
例えば、図1に示されるネットワークアーキテクチャに基づいて、ドナーノードによってデータパケットに追加される3つのルーティング情報が、パスラベル1、IABノード4の識別子、および端末1の識別子である場合、IABノード1は、パスラベル2をデータパケットに追加することができ、パスラベル2によって指定される送信パスは、IABノード1→IABノード2→IABノード4であり得る。
本願の実施形態で提供される解決策によれば、ネットワークデバイスは、データパケットに、データパケットの複数の送信パスを示すために使用されるルーティング情報を追加することができ、その結果、いくつかの転送ノードは、ルーティング情報に基づいて、データパケットを送信するための送信パスを自律的に選択することができる。このようにして、柔軟なルーティングが実施される。
上記は主に、ネットワーク要素間の相互作用の観点から、本願の実施形態における解決策を説明している。前述の機能を実施するために、第1のノード、第5のノード、第1の無線デバイス、ネットワークデバイス、または第6のノードなどの各ネットワーク要素は、各機能を実行するための対応するハードウェア構造および/またはソフトウェアモジュールを含むことが理解されよう。本明細書で開示されている実施形態で説明されているユニットおよびアルゴリズムステップの例と組み合わせて、本出願がハードウェアまたはハードウェアとコンピュータソフトウェアとの組み合わせによって実施されることが可能であることを当然当業者は容易に認識する。機能がハードウェアによって実行されるか、またはコンピュータソフトウェアによって駆動されるハードウェアによって実行されるかは、技術的解決策の特定の用途および設計制約に依存する。当業者は、特定の各アプリケーションのために説明した機能を実装するために異なる方法を使用することができるが、このような実装が本出願の範囲外であると考えられるべきではない。
本願の実施形態では、第1のノード、第5のノード、第1の無線デバイス、ネットワークデバイス、第6のノードなどは、前述の方法例に基づいて機能ユニットに分割することができる。例えば、各機能ユニットは、対応する機能に基づいて分割して取得されてもよいし、2つ以上の機能が1つの処理ユニットに統合されてもよい。統合されたユニットは、ハードウェアの形態で実装されてもよく、あるいは、ソフトウェア機能ユニットの形態で実装されてもよい。本出願の実施形態におけるユニット分割は例であり、単なる論理機能分割であることに留意されたい。実際の実装中に、他の分割方法があってもよい。
統合されたユニットが用いられる場合には図9は上記の実施形態のネットワークノード90の可能な概略構成図である。ネットワークノード90は、処理ユニット901および通信ユニット902を含み、さらに記憶ユニット903を含み得る。図9に示される概略構造図は、前述の実施形態における第1のノード、第5のノード、第1の無線デバイス、ネットワークデバイス、または第6のノードの構造を示すために使用され得る。
図9に示される概略構造図を使用して、前述の実施形態における第1のノードの構造を示す場合、処理ユニット901は、第1のノードの動作を制御および管理するように構成される。例えば、処理ユニット901は、図7のプロセス701から703を実行する際の第1のノード、および/または本願の実施形態に記載の他のプロセスにおいて第1のノードによって実行されるアクションをサポートするように構成される。通信ユニット902は、他のネットワークエンティティと通信する、例えば、図7に示される第2のノードと通信する際に第1のノードをサポートするように構成される。記憶ユニット903は、第1のノードのプログラムコードおよびデータを格納するように構成される。
図9に示される概略構造図を使用して、前述の実施形態におけるネットワークデバイスの構造を示す場合、処理ユニット901は、ネットワークデバイスの動作を制御および管理するように構成される。例えば、処理ユニット901は、図8のプロセス801から803を実行する際のネットワークデバイス、および/または本願の実施形態に記載の他のプロセスにおいてネットワークデバイスによって実行されるアクションをサポートするように構成される。通信ユニット902は、他のネットワークエンティティとの通信、例えば図8に示される第6のノードとの通信の際にネットワークデバイスをサポートするように構成される。記憶ユニット903は、ネットワークデバイスのプログラムコードおよびデータを格納するように構成される。
図9に示される概略構造図を使用して、前述の実施形態における第6のノードの構造を示す場合、処理ユニット901は、第6のノードの動作を制御および管理するように構成される。例えば、処理ユニット901は、図8のプロセス804を実行する際の第6のノード、および/または本願の実施形態に記載の他のプロセスにおいて第6のノードによって実行されるアクションをサポートするように構成される。通信ユニット902は、他のネットワークエンティティとの通信、例えば図8に示されるネットワークデバイスとの通信の際に第6のノードをサポートするように構成される。記憶ユニット903は、第6のノードのプログラムコードおよびデータを格納するように構成される。
図9に示される概略構造図を使用して、前述の実施形態における第5のノードの構造を示す場合、処理ユニット901は、第5のノードの動作を制御および管理するように構成される。例えば、処理ユニット901は、本願の実施形態に記載の他のプロセスにおいて第5のノードによって実行されるアクションを実行する際に第5のノードをサポートするように構成される。通信ユニット902は、他のネットワークエンティティと通信する、例えば、図7に示される第1のノードと通信する際に第5のノードをサポートするように構成される。記憶ユニット903は、第5のノードのプログラムコードおよびデータを格納するように構成される。
図9に示される概略構造図を使用して、前述の実施形態における第1の無線デバイスの構造を示す場合、処理ユニット901は、第1の無線デバイスの動作を制御および管理するように構成される。例えば、処理ユニット901は、本願の実施形態に記載の他のプロセスにおいて第1の無線デバイスによって実行されるアクションを実行する際に第1の無線デバイスサポートするように構成される。通信ユニット902は、他のネットワークエンティティと通信する、例えば、図7に示される第1のノードと通信する際に第1の無線デバイスをサポートするように構成される。記憶ユニット903は、第1の無線デバイスのプログラムコードおよびデータを格納するように構成される。
処理ユニット901はプロセッサまたはコントローラであってもよい。通信ユニット902は、通信インタフェース、トランシーバ、トランシーバ回路などであってもよい。通信インタフェースは総称であり、1つ以上のインタフェースを含み得る。記憶ユニット903は、メモリであり得る。処理ユニット901がプロセッサであり、通信ユニット902が通信インタフェースであり、記憶ユニット903がメモリである場合、本願のこの実施形態におけるネットワークノード90は、図2に示されるネットワークノード20であり得る。
この場合、図2に示される概略構造図を使用して、前述の実施形態における第1のノードの構造を示す場合、プロセッサ201は、第1のノードの動作を制御および管理するように構成される。例えば、プロセッサ201は、図7のプロセス701から703を実行する際の第1のノード、および/または本願の実施形態に記載の他のプロセスにおいて第1のノードによって実行されるアクションをサポートするように構成される。通信インタフェース204は、他のネットワークエンティティと通信する、例えば、図7に示される第2のノードと通信する際に第1のノードをサポートするように構成される。メモリ203は、第1のノードのプログラムコードおよびデータを格納するように構成される。
図2に示される概略構造図を使用して、前述の実施形態におけるネットワークデバイスの構造を示す場合、プロセッサ201は、ネットワークデバイスの動作を制御および管理するように構成される。例えば、プロセッサ201は、図8のプロセス801から803を実行する際のネットワークデバイス、および/または本願の実施形態に記載の他のプロセスにおいてネットワークデバイスによって実行されるアクションをサポートするように構成される。通信インタフェース204は、他のネットワークエンティティとの通信、例えば図8に示される第6のノードとの通信の際にネットワークデバイスをサポートするように構成される。メモリ203は、ネットワークデバイスのプログラムコードおよびデータを記憶するように構成される。
図2に示される概略構造図を使用して、前述の実施形態における第6のノードの構造を示す場合、プロセッサ201は、第6のノードの動作を制御および管理するように構成される。例えば、プロセッサ201は、図8のプロセス804を実行する際の第6のノード、および/または本願の実施形態に記載の他のプロセスにおいて第6のノードによって実行されるアクションをサポートするように構成される。通信インタフェース204は、他のネットワークエンティティとの通信、例えば図8に示されるネットワークデバイスとの通信の際に第6のノードをサポートするように構成される。メモリ203は、第6のノードのプログラムコードおよびデータを格納するように構成される。
図2に示される概略構造図を使用して、前述の実施形態における第5のノードの構造を示す場合、プロセッサ201は、第5のノードの動作を制御および管理するように構成される。例えば、プロセッサ201は、本願の実施形態に記載の他のプロセスにおいて第5のノードによって実行されるアクションを実行する際に第5のノードをサポートするように構成される。通信インタフェース204は、他のネットワークエンティティと通信する、例えば、図7に示される第1のノードと通信する際に第5のノードをサポートするように構成される。メモリ203は、第5のノードのプログラムコードおよびデータを格納するように構成される。
図2に示される概略構造図を使用して、前述の実施形態における第1の無線デバイスの構造を示す場合、プロセッサ201は、第1の無線デバイスの動作を制御および管理するように構成される。例えば、プロセッサ201は、本願の実施形態に記載の他のプロセスにおいて第1の無線デバイスによって実行されるアクションを実行する際に第1の無線デバイスサポートするように構成される。通信インタフェース204は、他のネットワークエンティティと通信する、例えば、図7に示される第1のノードと通信する際に第1の無線デバイスをサポートするように構成される。メモリ203は、第1の無線デバイスのプログラムコードおよびデータを格納するように構成される。
本願の一実施形態は命令を含むコンピュータ可読記憶媒体をさらに提供する。命令がコンピュータ上で実行されると、コンピュータは前述の方法を実行することが可能になる。
本願の実施形態は、命令を含むコンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータ上で動作すると、コンピュータは前述の方法を実行することが可能になる。
本願の実施形態はさらに装置を提供し、装置はチップの製品形態で存在する。この装置は、プロセッサ、メモリ、およびトランシーバコンポーネントを含む。トランシーバコンポーネントは、入力/出力回路を含む。メモリは、コンピュータ実行可能命令を格納するように構成されている。プロセッサは、前述の方法を実施するために、メモリに格納されたコンピュータ実行可能命令を実行する。
本願の実施形態は、少なくとも第1のノードおよび第2のノードを含む通信システムをさらに提供し、第5のノードおよび/または第1の無線デバイスをさらに含み得る。
本願の実施形態は、少なくとも前述のネットワークデバイスおよび第6のノードを含む通信システムをさらに提供する。
前述の実施形態の全部または一部は、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組み合わせによって実施され得る。実施形態を実現するためにソフトウェアが使用される場合、実施形態の全部または一部がコンピュータプログラム製品の形態で実現され得る。コンピュータプログラム製品は、1つ以上のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータにロードされて実行されると、本願の実施形態による手順または機能がすべてまたは部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または他のプログラマブル装置であり得る。コンピュータ命令は、コンピュータ可読記憶媒体に格納されてもよいし、1つのコンピュータ可読記憶媒体から他のコンピュータ可読記憶媒体に送信されてもよい。例えば、コンピュータ命令は、有線(例えば、同軸ケーブル、光ファイバ、またはデジタル加入者回線(digital subscriber line、略してDSL))または無線(例えば、赤外線、無線、またはマイクロ波)方式で、あるウェブサイト、コンピュータ、サーバ、またはデータセンタから他のウェブサイト、コンピュータ、サーバ、またはデータセンタに送信されてもよい。コンピュータ可読記憶媒体は、コンピュータがアクセスできる任意の使用可能な媒体、または、1つ以上の使用可能な媒体を統合した、サーバやデータセンタなどのデータ記憶装置であり得る。使用可能な媒体は、磁気式媒体(例えば、フロッピーディスク、ハードディスク、または磁気テープ)、光学式媒体(例えば、DVD)、半導体媒体(例えば、ソリッドステートドライブ(solid state disk、略してSSD))などであってもよい。
本願は実施形態を参照して説明されるが、保護を主張する本願を実施するプロセスにおいて、当業者は、添付の図面、開示された内容、および添付の特許請求の範囲を見ることにより、開示された実施形態の他の変形を理解および実施することができる。特許請求の範囲において、「含む」(comprising)は、他のコンポーネントまたは他のステップを排除するものではなく、「1つの(a)」または「1つの(one)」は、複数の場合を排除するものではない。単一のプロセッサまたは他のユニットは、特許請求の範囲に列挙されているいくつかの機能を実施することができる。従属クレームには互いに異なるいくつかの方策が記録されているが、これは、より良い効果を生み出すために、これらの方策を組み合わせることができないことを意味しない。
本願は、特定の特徴およびその実施形態を参照して説明されているが、本願の精神および範囲から逸脱することなく、それらに様々な修正や組み合わせを行うことができることは明らかである。これに対応して、本明細書および添付の図面は、添付の特許請求の範囲によって定義される本出願の例示の説明にすぎず、本出願の範囲内のあらゆる改変、変形、組み合わせ、または均等物のいずれかまたはすべてを範囲として含むことを意図している。明らかに、当業者は、本出願の趣旨および範囲から逸脱することなく、本出願に対して様々な修正および変形を行うことができる。本願は、添付の特許請求の範囲およびそれらと等価な技術によって規定される保護の範囲内に入るという条件で、本願のこれらの修正および変形を包含することが意図されている。