本出願における技術的解決策について、添付の図面を参照して以下で説明する。理解しやすいように、本出願に関わる用語および通信プロセスについて、以下で図1から図5を参照して、最初に説明する。
図1は、本出願の実施形態が適用可能であるワイヤレス通信システム100のシステムアーキテクチャの例示的図である。ワイヤレス通信システム100は、ネットワークデバイス110および端末デバイス121~129を含み得る。ネットワークデバイス110は、特定の地理的エリアに通信カバレージを提供することができ、カバレージエリア内の端末と通信することができる。
いくつかの実装形態では、端末デバイスは、サイドリンク(SL)を通して互いと通信し得る。サイドリンク(sidelink)通信は、近接サービス(ProSe)通信、単方向通信、サイドリンク(side link)通信、デバイス間(D2D)通信などと呼ばれる場合もある。
言い換えると、サイドリンクデータが、サイドリンクを介して端末デバイスの間で送信される。サイドリンクデータは、データおよび/または制御シグナリングを含み得る。いくつかの実装形態では、サイドリンクデータは、たとえば、物理サイドリンク制御チャネル(PSCCH)、物理サイドリンク共有チャネル(PSSCH)、PSCCH復調参照信号(DMRS)、PSSCH DMRS、または物理サイドリンクフィードバックチャネル(PSFCH)であり得る。
いくつかの共通サイドリンク通信シナリオについて、図1を参照して以下で説明する。サイドリンク中の端末デバイスがネットワークデバイスのカバレージ内にあるかどうかによって、サイドリンク通信は、3つのシナリオを含み得る。シナリオ1では、端末デバイスは、ネットワークデバイスのカバレージ内でサイドリンク通信を実施する。シナリオ2では、端末デバイスのいくつかが、ネットワークデバイスのカバレージ内でサイドリンク通信を実施する。シナリオ3では、端末デバイスは、ネットワークデバイスのカバレージの外でサイドリンク通信を実施する。
図1に示すように、シナリオ1において、端末デバイス121および122は、サイドリンクを介して互いと通信することができ、端末デバイス121および122は両方とも、ネットワークデバイス110のカバレージ内にあり、または言い換えると、端末デバイス121および122は両方とも、同じネットワークデバイス110のカバレージ内にある。このシナリオでは、ネットワークデバイス110は、端末デバイス121および122へ構成シグナリングを送ってよく、したがって、端末デバイス121および122は、構成シグナリングに基づいて、サイドリンクを介して互いと通信する。
図1に示すように、シナリオ2において、端末デバイス123および124は、サイドリンクを介して互いと通信することができ、端末デバイス123はネットワークデバイス110のカバレージ内にあるが、端末デバイス124はネットワークデバイス110のカバレージの外にある。このシナリオでは、端末デバイス123は、ネットワークデバイス110から構成情報を受信し、構成シグナリングの構成に基づいて、サイドリンクを介して通信する。ただし、端末デバイス124はネットワークデバイス110のカバレージの外にあるので、端末デバイス124は、ネットワークデバイス110から構成情報を受信することができない。この場合、端末デバイス124は、事前構成された構成情報および/またはカバレージ内の端末デバイス123によって送られた構成情報に基づいて、サイドリンク通信の構成を取得すればよく、そうすることによって、取得した構成に基づいて、サイドリンクを介して端末デバイス123と通信する。
いくつかの場合には、端末デバイス123は、サイドリンクを介して通信するように端末デバイス124を構成するために、物理サイドリンクブロードキャストチャネル(PSBCH)を通して端末デバイス124へ構成情報を送り得る。
図1に示すように、シナリオ3において、端末デバイス125~129はすべて、ネットワークデバイス110のカバレージの外にあり、ネットワークデバイス110と通信することができない。この場合、端末デバイスすべてが、事前構成情報に基づいてサイドリンク通信を実施し得る。
いくつかの場合には、ネットワークデバイスのカバレージの外にある端末デバイス127~129が通信クラスタを形成してよく、通信クラスタ中の端末デバイス127~129が互いと通信することができる。さらに、通信クラスタ中の端末デバイス127は、クラスタヘッダ(CH)とも呼ばれる中央制御ノードとして働き得る。それに応じて、通信クラスタ中の他の端末デバイスは、「クラスタメンバー」と呼ばれ得る。
CHとしての端末デバイス127は、通信クラスタの確立を担うこと、クラスタメンバーの加入および離脱、リソース協調、クラスタメンバーへのサイドリンク送信リソースの割振り、およびクラスタメンバーからのサイドリンクフィードバック情報の受信、別の通信クラスタとのリソース協調、ならびに他の機能という機能のうちの1つまたは複数を有し得る。
図1は、ネットワークデバイスおよび複数の端末デバイスを例示的に示していることに留意されたい。任意選択で、ワイヤレス通信システム100は複数のネットワークデバイスを含んでよく、別の数の端末デバイスが各ネットワークデバイスのカバレージ中に含まれてよく、これは、本出願の本実施形態において限定されない。
任意選択で、ワイヤレス通信システム100は、ネットワークコントローラおよびモビリティ管理エンティティなど、他のネットワークエンティティをさらに含んでよく、これは、本出願の本実施形態において限定されない。
本出願の実施形態における技術的解決策は、様々な通信システム、たとえば、第5世代(5G)システムまたは新無線(NR)システム、ロングタームエボリューション(LTE)システム、LTE周波数分割複信(FDD)システム、およびLTE時分割複信(TDD)に適用できることを理解されたい。本出願において提供される技術的解決策は、第6世代モバイル通信システムおよび衛星通信システムなど、将来の通信システムに適用することもできる。
本出願の実施形態における端末デバイスは、ユーザ機器(UE)、アクセス端末、加入者ユニット、加入者局、モバイル、移動局(MS)、モバイル端末(MT)、リモート局、リモート端末、モバイルデバイス、ユーザ端末、ワイヤレス通信デバイス、ユーザエージェント、またはユーザ装置と呼ばれる場合もある。本出願の実施形態における端末デバイスは、音声および/またはデータ接続性をユーザに提供するとともに人々、物、およびワイヤレス接続機能を有するハンドヘルドデバイスまたは車載デバイスなどの機械を接続することが可能なデバイスであってよい。本出願の実施形態における端末デバイスは、モバイルフォン、タブレットコンピュータ(パッド)、ノートブックコンピュータ、パームトップコンピュータ、モバイルインターネットデバイス(MID)、装着可能デバイス、車両、産業用制御でのワイヤレス端末、自動運転でのワイヤレス端末、遠隔手術でのワイヤレス端末、スマートグリッドでのワイヤレス端末、輸送安全性でのワイヤレス端末、スマートシティでのワイヤレス端末、スマートホームでのワイヤレス端末などであってよい。任意選択で、端末デバイスは、基地局として作用するように使われてよい。たとえば、端末デバイスはスケジューリングエンティティとして作用してよく、これは、車車間路車間(V2X)またはD2Dなどにおいて、端末デバイスの間でサイドリンク信号を提供する。たとえば、セルラーフォンと車が、サイドリンクデータを使って互いと通信する。セルラーフォンとスマートホームデバイスが、基地局を通した通信信号の中継なしで、互いと通信する。
本出願の実施形態におけるネットワークデバイスは、端末デバイスと通信するためのデバイスであってよい。ネットワークデバイスは、アクセスネットワークデバイスまたはワイヤレスアクセスネットワークデバイスと呼ばれる場合もある。たとえば、ネットワークデバイスは基地局であってよい。本出願の実施形態におけるネットワークデバイスは、端末デバイスをワイヤレスネットワークに接続する無線アクセスネットワーク(RAN)ノード(またはデバイス)であってよい。基地局は、たとえば、ノードB、発展型ノードB(eNB)、次世代ノードB(gNB)、中継局、送受信ポイント(TRP)、送信ポイント(TP)、アクセスポイント(AP)、マスタeNB MeNB、2次eNB SeNB、マルチスタンダード無線(MSR)ノード、ホーム基地局、ネットワークコントローラ、アクセスノード、無線ノード、送信ノード、トランシーバノード、ベースバンドユニット(BBU)、リモート無線ユニット(RRU)、アクティブアンテナユニット(AAU)、リモート無線ヘッド(RRH)、中央ユニット(CU)、分散ユニット(DU)、および測位ノードという様々な名称を広くカバーしてもよく、それらの名称と交換可能であってもよい。基地局は、マクロ基地局、マイクロ基地局、中継ノード、ドナーノードなど、またはそれらの組合せであってよい。代替として、基地局は、通信モジュール、モデム、または上述したデバイスもしくは装置中に配置されたチップであってよい。代替として、基地局は、モバイル交換センター、D2D、V2X、および機械間(M2M)通信における基地局の機能を前提とするデバイス、6Gネットワークにおけるネットワークサイドデバイス、将来の通信システムにおける基地局の機能を前提とするデバイスなどであってよい。基地局は、同じまたは異なるアクセス技術のネットワークをサポートすることができる。ネットワークデバイスによって使われる具体的な技術および具体的なデバイス形式は、本出願の実施形態において限定されない。
基地局は、固定またはモバイルであってよい。たとえば、ヘリコプターまたはドローンが、モバイル基地局として作用するように構成されてよく、1つまたは複数のセルが、モバイル基地局の位置に従って動き得る。他の例では、ヘリコプターまたはドローンが、別の基地局と通信するデバイスとして働くように構成され得る。
いくつかの展開では、本出願の実施形態におけるネットワークデバイスはCUもしくはDUであってよく、またはネットワークデバイスはCUおよびDUを含む。gNBは、AAUをさらに含み得る。
ネットワークデバイスおよび端末デバイスは、屋内もしくは屋外を含む陸上で展開されてよく、ハンドヘルドもしくは車載であってよく、または水上で展開されてよく、または上空の飛行機、気球、および衛星に展開されてよい。本出願の実施形態において、ネットワークデバイスおよび端末デバイスが置かれるシナリオは限定されない。
本出願における通信デバイスの機能の全部または一部が、ハードウェア上で稼動するソフトウェア機能によって、またはプラットフォーム(クラウドプラットフォームなど)上でインスタンス化された仮想化機能によって実装されてもよいことを理解されたい。
サイドリンク通信技術の開発に伴って、サイドリンク通信技術は、様々な端末デバイスの間の情報交換に関する。図2に示すV2X通信システム200を例としてとると、端末デバイス201と端末デバイス202との間の車車間(V2V)通信は、車両自体の間での情報交換に関する。それぞれ端末デバイス201と端末デバイス203~205との間の路車間(V2I)通信、車両ネットワーク間(V2N)通信、および車歩行者間(V2P)通信は、車両と外部システムとの間の情報交換に関わる。
サイドリンク用の通信スペクトル
通信システムによって使われるスペクトルは、認可スペクトルおよび無認可スペクトルを含む。異なるフィールドへの通信システムの拡張のための重要な方向性は、無認可スペクトルの使用である。たとえば、無認可スペクトル上に展開されるNRはNR-Uと呼ばれる。
現在、サイドリンクは主に、認可スペクトルを使う。サイドリンクは、無認可スペクトルを使う場合もある。無認可スペクトル上で展開されるサイドリンクは、SL-Uと呼ばれ得る。
認可スペクトルと比較して、無認可スペクトルは、認可なしでの共有という特徴を有する。したがって、無認可スペクトルは共有スペクトルとも呼ばれる。事業者にとって、スペクトル共有は、高帯域幅サービスを動的にサポートするように適時に、スペクトル集約を容易にする。スペクトル共有は、認可スペクトルへのアクセスを有しない場合がある運用事業体に対して、通信技術(たとえば、NR)の利益を拡大することもできる。
共有スペクトルは、様々な無線アクセス技術(RAT)システム、たとえば、通常はワイヤレスフィデリティ(WiFi)システムおよびLTEベースのライセンス支援型アクセス(LAA)システムの共存を考慮する必要がある。様々なシステムが、チャネルアクセス公平性およびマルチRAT共存の原理によるスペクトル競合方式で、無認可スペクトル中の周波数帯域を使う。
共有スペクトルでは、どのRATシステムも、無認可スペクトル規制ルールの制約下で通信を実施する必要がある。規制ルールは、電力および電力スペクトル密度レベル、最大チャネル占有時間(COT)、チャネル占有帯域幅、ならびにチャネル監視機構を含む。同じ周波数帯域中で、各システムは、規制ルールの要件を満たし、同じ周波数帯域中で別のRATシステムとの干渉を引き起こさないように、チャネルを合理的に占有し、解放する必要がある。
共有スペクトルの使用のために、RATシステムは、必須チャネル監視技術(たとえば、LBT)を、ネットワークにアクセスするのに利用すればよい。言い換えると、データは、現在のチャネルが占有されていないことが検出されたときにのみ送信することができる。たとえば、サイドリンク端末デバイスがLBTを始動してよく、LBTはカテゴリ1(Cat 1)LBTまたはカテゴリ2(Cat 2)LBTであってよい。
LBTを通してチャネルリソースを取得した後、端末デバイスは、上記規制ルールに基づいてデータを送信する。たとえば、COT限度は、端末デバイスがチャネルリソースを介してデータを送信するとき、満足される必要がある。言い換えると、連続データ送信はCOT時間内に制限されるべきであり、この時間を超えると、端末デバイスは、チャネルを解放し、LBTを再度実施する必要がある。
サイドリンクのためのリソース割振り方法
リソース割振り方法は、端末デバイスのサービスタイプに基づいて判断されてよい。サイドリンク端末デバイスの、主に2つのタイプのサービス、すなわち、定期サービスおよび非定期サービスがある。定期サービスの場合、端末デバイスのサイドリンクデータは概して、定期的である。たとえば、NR V2Xの交通安全サービスでは、サイドリンクデータの一部は、予測可能な時間に到着する可能性がある定期的トラフィックである。非定期サービスの場合、データの到着はランダムであり、データパケットのサイズも可変である。
いくつかの通信システム(たとえば、NR)では、サイドリンクリソースのための2つのリソース構成モード、すなわち、モード1およびモード2が定義される。
モード1において、ネットワークデバイスは、端末デバイス用のサイドリンクリソースをスケジュールする。
現在、モード1には、動的リソース構成およびサイドリンク構成許可という2つの方式があり得る。動的リソース構成では、ネットワークデバイスは、端末デバイスにサイドリンク送信リソースを割り振るためにダウンリンク制御情報(DCI)を送り得る。サイドリンク構成許可方式では、端末デバイスがサイドリンクリソースで構成された後、端末デバイスが、送信されるべきデータを有する場合、端末デバイスは、構成されたサイドリンクリソースを、データを送信するのに使うことができ、ネットワークデバイスに対して別のサイドリンクリソースを要求する必要はない。定期サービスの場合、ネットワークデバイスは一般に、半静的送信リソースを端末デバイスに割り振る。ネットワークデバイスは、直接リンク上で端末デバイス用の送信リソースをスケジュールし、こうすることで、リソース衝突を効果的に回避し、隠れノード問題を解決することができる。
たとえば、図1を参照すると、端末デバイス121~123はネットワークデバイス110のカバレージ内にあり、ネットワークデバイス110は、端末デバイス121~123にサイドリンクリソースを割り振り得る。
モード2において、端末デバイスは、サイドリンクリソースプール中のサイドリンクリソースを独自に選択する。
分散型リソーススケジューリング機構が、このモードでは使われる。サイドリンクリソースプールは、ネットワークデバイスによって構成または事前構成されてよい。いくつかの実施形態では、ネットワークデバイスは、上位レイヤシグナリングを通して、端末デバイスに対するサイドリンクリソースプールを構成し得る。端末デバイスは、リソース監視またはランダム選択に依拠して、ネットワークデバイスによって構成または事前構成されたリソースプールから、時間周波数リソースを別個に選択する。たとえば、図1の端末デバイス124~129はネットワークデバイス110のカバレージの外にあり、端末デバイス124~129は各々、ネットワークデバイスによって構成されたリソースプールからサイドリンクリソースを独自に選択し得る。
定期サービスにおいて、サイドリンクは、予想データ到着時間に、端末デバイス用のサイドリンク通信リソースを、他の端末デバイスとのリソース競合を回避するように確保(または予約)し得る。たとえば、サイドリンク端末デバイスは、サイドリンク制御情報(SCI)の中で確保期間を示すことによって、定期サービスのためのリソース確保をサポートし得る。
モード2において、明らかな定期的特性を有するサービス用に、端末デバイスは、チャネル検知と半永続的スケジューリング(SPS)を組み合わせたリソース割振り機構を実施し得る。この機構は、サービスの定期的特性をフル活用することができる。送信機側が、送信されるべき定期サービスを進めるための定期的送信リソースを予約し、こうすることで、受信機側がリソース状況検知および衝突回避を実施するのを助け、そうすることによって、リソース使用率および送信信頼性を向上させる。
非定期サービスのために、端末デバイスは、検知と1回の送信を組み合わせたリソース割振り機構を実施する。将来のリソース占有を予測し、予約することは不可能なので、比較的高い確率でリソース衝突が起こる。
端末デバイスのチャネル検知プロセスは、リソース検知プロセスおよび/またはリソース選択プロセスを含む。リソース検知は、リソース監視またはリソースプロービングと呼ばれる場合もある。端末デバイスは、専用サイドリンクリソースプールに基づいてリソース検知および選択を実施し、これらは、端末デバイスの間の、可能なリソース衝突を軽減または回避することができる。たとえば、端末デバイスは、検知を用いて、リソースプールからサイドリンク送信リソースを選択し得る。
リソース検知プロセスにおいて、端末デバイスは、SCIを復調することによって、サイドリンクリソースの占有(または予約)を識別してよく、つまり、端末デバイスは、SCIを復調することによって、他の端末デバイスのリソース予約情報を取得することができる。代替として、端末デバイスは、サイドリンクの受信電力を測定することによって、サイドリンクリソースの占有を識別し得る。
定期サービス用に端末デバイスによって予約された送信リソースが確保された後、確保メッセージを受信したすべての他の端末デバイスは、確保されたリソースでの選択および送信を避ける。いくつかの実施形態では、端末デバイスは、他の端末デバイスによって予約されていないか、または他の端末デバイスによって予約されているが比較的低い受信電力を有するリソースをリソースプールから選択すればよく、そうすることによって、リソース衝突確率を下げ、通信信頼性を向上させる。
モード2のリソース割振り機構は、認可または専用スペクトル(周波数範囲)の中ではうまくいく。ただし、無認可スペクトル中で、モード2のリソース割振り機構はいくつかの制限を有する。
モード2のリソース割振り方法がSL-Uに適用されるとき、チャネル監視の不確実性が考慮される必要がある。チャネル監視結果への依存のせいで、サイドリンクは、特定の時間においてリソースを確保するのが難しい。現在、サイドリンクは、無認可チャネル中の時間ウィンドウを確保する。時間ウィンドウは、スロットのグループからなり得る。これらのスロットは定期的に発生する。時間ウィンドウは、可能なチャネル監視失敗を回避するために、予想データ到着時間の前の頃に始まる。時間ウィンドウ中に確保されたリソースは、時間および周波数インターリーブリソースブロック(RB)のセットであってよい。これらのリソースブロックは、チャネルアクセスのために要するリソースとして使われ得る。
さらに、WiFiデバイス、LAAデバイス、拡張ライセンス支援型アクセス(eLAA)デバイス、およびNR-Uデバイスなど、他のタイプのRATの多数のデバイスが、無認可スペクトル中にすでにある。サイドリンク用に要するチャネルリソースは、サイドリンク端末デバイスによって占有され得るだけでなく、別のタイプのRATのデバイスによっても占有され得る。レガシーモード2プロセスは、非サイドリンク端末デバイスによって引き起こされたリソース衝突を識別し、解決することができず、これが、サイドリンク端末デバイスのチャネル監視失敗を引き起こし得る。
さらに、サイドリンク端末デバイスのリソース予約は、他のタイプのRATのデバイスにとっては無効である。これらのデバイスは、サイドリンク端末デバイスによって送られた確保メッセージを監視することもできず、SCIの中のリソース予約情報を受信し、理解することもできない。これらのデバイスは、確保されたリソースと重なるチャネルを占有しようと試み、確保されたリソース上で、クリアチャネルアセスメント(CCA)を絶えず実施する。確保に従う他の端末デバイスにとって、CCA成功の機会はより少なく、SL-Uによるレガシーモード2の使用効率は低下する。したがって、モード2リソース選択は、レガシーデバイスが付近にないとき、より有用である。
サイドリンク端末デバイスがネットワークカバレージ内で動作しているとき、付近の端末デバイスも、予約メッセージをリッスンしない。リソース予約の衝突を減らすために、サイドリンク端末デバイスは、確保信号をネットワークデバイスへフォワードすればよく、ネットワークデバイスは、確保されたリソース上でアップリンク送信をスケジュールするのを避ければよい。
モード2において、端末デバイスは、対応するPSCCH/PSSCHおよびPSFCH用の送信リソースを判断するためのリソース選択手順を実施する。無認可スペクトル上で、端末デバイスは一般に、チャネル監視が成功した後でのみ、リソース選択を開始する。NR-Uとは異なり、サイドリンク端末デバイスは、マルチチャネルアクセスを、スケジュールされ、または指示されるのではなく、別個に実施できる必要がある。
サイドリンクのためのチャネルアクセス
LBTなどのチャネル監視機構を通して、チャネルがアイドルであることを端末デバイスが検出した後、端末デバイスは、データを送信するために、アイドルリソース上でチャネルアクセスを実施する。したがって、LBTなどの監視および回避機構は、チャネルアクセス機構とも呼ばれる。
いくつかのプロトコル(R16/R17)では、サイドリンク対応端末デバイスがスロット単位でチャネルアクセスを実施するが、これはフルスロットチャネルアクセスである。スロットの持続時間が、サブキャリア間隔に関連する。いくつかの通信システム(たとえば、NR)では、複数のサブキャリア間隔をサポートすることができ、無線フレームの構造は、サブキャリア間隔によってわずかに変わる。無線フレームの持続時間およびサブフレームの持続時間は、サブキャリア間隔とともには変わらない。無線フレームの持続時間は常に10msであり、サブフレームの持続時間は常に1msである。
サブフレームは1つまたは複数のスロットからなり、スロットの持続時間はサブキャリア間隔に関連する。たとえば、サブキャリア間隔が15kHzであるとき、1スロットの持続時間は1msであり、これはサブフレームの持続時間と同じである。サブキャリア間隔が30kHzであるとき、1スロットの持続時間は0.5msであり、2つのスロットがサブフレームを形成する。ただし、スロット中のシンボルの数は、サブキャリア間隔とともに変化はせず、スロットの構成タイプのみが変化する。通常、1スロットは14個のシンボルを含む。
14個のシンボルを含むフルスロットに基づくチャネルアクセスにおいて、端末デバイスは、14個ごとのシンボルを、同期時点に基づく送信スタート点として使う。送信スタート点は、チャネルアクセス位置とも呼ばれ得る。このように、端末デバイスがチャネル監視を実施する時点にかかわらず、監視が成功した後、端末デバイスは、チャネルアクセスを実施するための、次の送信スタート点を待つ必要がある。言い換えると、チャネル監視が成功した後、端末デバイスは、データ送信を実施するための次のスロットを待つ必要がある。
図3を参照して、フルスロットチャネルアクセスモードについて、端末デバイスがLBTを通してPSCCH/PSSCHを送信する例を使って以下で説明する。
図3を参照すると、端末デバイスは、スロット310の早期段階においてLBTを完了する。フルスロットチャネルアクセスモードでは、端末デバイスは、PSCCH/PSSCHを送信するためのスロット320を待つ必要がある。図3に示すように、送信スタート点が、スロット320のスタート位置にある。スロット320において、最初のシンボルが自動利得制御(AGC)シンボルとして使われ、AGCシンボルについてのデータは一般に、データ復調には使われない。最後のシンボルが、ガードギャップGAPシンボルである。PSCCH/PSSCHは、AGCとGAPとの間にある。サイドリンクにおいて、スロットは基本的に、アップリンクシンボルもダウンリンクシンボルも搬送しない。
スロット320と比較して、スロット310中のわずかなシンボルのみが、端末デバイスのLBT用に使われる。端末デバイスは、スロット310中のLBTと送信スタート点との間のシンボルを使用することができない。したがって、スロット310中の複数のシンボルにおけるリソースが浪費される。
図3に示すように、スロット310中でLBTを完了した後、端末デバイスは、スロット320中でデータ送信を実施する。共有スペクトル中でのチャネルの可用性は常に保証することができるわけではないので、端末デバイスは、データ送信の前にCCAを実施する必要があり、データ送信は、チャネルがアイドルであることが保証されているときにのみ実施される。たとえば、端末デバイスは、20MHz RBセットに基づいて、LBT帯域幅(BW)におけるチャネルエネルギーを測定し得る。
無認可スペクトルにおいて、データ送信の前のチャネルアクセスは、複数のチャネルアクセスモードを含む。データ送信の前のチャネルアクセスプロセスについては、図4のNR-Uの3つのチャネルアクセスモードを参照して以下で説明する。図4を参照すると、タイプ2A(Type2A)およびタイプ2B(Type2B)チャネルアクセスプロセスが両方とも、チャネル検知ギャップ(検知ギャップ)を有し、タイプ2C(Type2C)はチャネル検知を要しない。
図4のタイプ2Aチャネルアクセスを例としてとると、適切なエネルギー検出閾値に基づいて、チャネル(媒体)がアイドルであることを端末デバイスが検知した後、SL送信の前に遅延期間がある。図4のタイプ2Aのための遅延期間は、25μsである。図4に示すように、25μsの遅延期間は主に、16μsの遅延時間および9μsの競合スロットを含む。端末デバイスは、競合スロットにおいて明示的CCAを実施する。遅延期間は、起こり得るWiFi確認時間(16μs)との衝突を回避することができ、端末デバイスが準備するための時間をつくることもできる。
タイプ2Aチャネルアクセスにおいて、9μsの競合スロットは、短期LBTまたは追加LBTとも呼ばれ得る。チャネルアクセスの遅延期間は、特定の数の追加LBTを設定することによって調節され得る。したがって、タイプ2Aのための遅延期間の最小持続時間は25μsである。
タイプ2Aに基づくチャネルアクセス中に、端末デバイスの準備ができると、送信を直ちに開始するように、追加LBTをクリアすることができる。遅延期間のカウントダウンが完了した後に、端末デバイスがまだ準備ができていない場合、チャネルアクセスは、失敗したと宣言されることになり、このプロセスはやり直されるべきである。いくつかの場合には、別のRATからのデバイスが、そのLBTを完了し、SL-U端末デバイスの次の送信スタート点の前に送信を開始してよい。追加LBTにより、SL-U端末デバイスは、そのような事態を検出し、アクセスを遅らせることができる。たとえば、図3において、端末デバイスが追加の短期LBTをクリアしたとき、WiFiノードがそのLBTを送信スタート点の前にクリア済みである場合、WiFiノードがチャネルを占有する。したがって、送信リソース衝突が起こり、SL-U端末デバイスはアクセスすることができない。
共有スペクトルにおけるチャネルアクセス中、サイドリンクは、データ送信の前に追加LBTをクリアする必要があるが、共有スペクトルの中の他のシステムは、対応する動作を実施する必要がなくてよい。たとえば、WiFiシステムが、どの時点においても非同期に送信を開始することができる。サイドリンクがWiFi類似システムと共存する場合、固定およびまばらであり得る送信スタート点を有するサイドリンクシステムは、リソースを大いに浪費するか、またはシステムスループットに深刻な影響を与えることになる。
上述したように、サイドリンク用の現在のチャネルアクセスモードは、フルスロットチャネルアクセスである。1つのスロット中に、チャネル監視を実施する複数の端末デバイスがあってよい。複数の端末デバイスがすべて、このスロットにおいて監視の実施に成功した場合、複数の端末デバイスはすべて、データ送信を実施するための次のスロットを待つ必要がある。したがって、複数の端末デバイスが、次のスロットの送信スタート点においてリソース衝突を起こす場合がある。
タイプ2Aチャネルアクセスプロセスを例としてとると、チャネルアクセスにおいて起こるリソース衝突について、図5を参照して以下で具体的に説明する。
図5を参照すると、端末デバイス1と端末デバイス2の両方が、スロット510においてLBTを実施する。端末デバイス1は、スロット510の早期段階においてLBTを完了し、PSCCH/PSSCHを送信するためのスロット520を待つ必要がある。端末デバイス1が待っている間、端末デバイス2も、スロット510の後期段階においてLBTを完了する。端末デバイスは両方とも、スロット520においてPSCCH/PSSCHを送信することになる。
図5に示す送信スタート点の前に、端末デバイスは両方とも、追加の短期LBTを用いて、チャネルがアイドルであるかどうかを判断する。追加LBTの競合スロットにおいてチャネルがアイドルであると判断された後でのみ、端末デバイス1または端末デバイス2は、チャネルにアクセスし、データ送信を実施することができる。
図5に示すように、端末デバイス1および端末デバイス2が、スロット510においてLBTのカウントダウンを完了した後、2つの端末デバイスは、送信スタート点の整列の前に、追加LBTにおいてリソース衝突を起こす。
図3に示すリソース浪費および図5に示すリソース衝突は両方とも、スロット単位での、サイドリンク向けのチャネルアクセスに起因する。チャネル監視が成功した後、端末デバイスは、チャネルアクセスを実施するための次のスロットを待つ必要があり、待機時間間隔は比較的長い。
このことに鑑みて、本出願の実施形態は、サイドリンク通信方法および装置を提供する。この方法のスロット構造は、より柔軟なチャネルアクセス位置を提供し、チャネル監視を完了した後に端末デバイスが待つ必要がある時間間隔が短縮され、そうすることによって、リソースの浪費を削減する。本出願の実施形態によるサイドリンク通信方法について、図6を参照して以下で説明する。
図6を参照すると、ステップS610において、端末デバイスが共有スペクトル上でチャネル監視を実施する。
端末デバイスは、サイドリンク通信を実施するデバイスである。端末デバイスは、サイドリンク通信でデータを送信することになっているデバイスであってよい。
端末デバイスは、他の端末デバイスとの、ユニキャスト通信、マルチキャスト通信、またはブロードキャスト通信を実施し得る。いくつかの実施形態では、チャネル監視を実施する端末デバイスは、マルチキャストもしくはブロードキャスト通信を始動するクラスタヘッダであってもよく、マルチキャストもしくはブロードキャスト通信におけるクラスタメンバーであってもよい。たとえば、V2Xでは、チャネル監視を実施する端末デバイスは、他の車両とのマルチキャスト通信を実施する車両であってもよく、マルチキャスト通信における他の車両であってもよい。
いくつかの実施形態では、チャネル監視を実施する端末デバイスは、ネットワークのカバレージ内にあってもよく、ネットワークのカバレージの外にあってもよい。ネットワークのカバレージ内の端末デバイスが、ネットワークデバイスの構成に基づいて、共有スペクトル中でチャネル監視を実施してよい。
チャネル監視は、端末デバイスが、共有スペクトル中で複数のチャネルリソースを監視すること、または目標チャネルリソースを監視することを意味し得る。
チャネルリソースは、共有スペクトル中のリソース、またはサイドリンクにおいて別の端末デバイスによって共有されるCOTリソースであってよい。たとえば、V2Xにおいて、端末デバイスは、付近の車両によって提供されるCOT共有のためにチャネル監視を実施し得る。
いくつかの実施形態では、チャネル監視は、端末デバイスがLBT機構を使ってチャネルリソースを監視すること、または端末デバイスがチャネル検知もしくは他の手段によって監視を実施することを意味し得る。たとえば、端末デバイスは、サイドリンクDMRSの参照信号受信電力(RSRP)の値に基づいて、サイドリンクリソースの占有を判断し得る。
チャネル監視の結果は、監視されるチャネルリソースがアイドルであること、または監視されるチャネルが占有されていることであってよい。チャネル監視の結果が、チャネルが占有されていることである場合、端末デバイスは、アイドルチャネルが見つかるまで、チャネル監視を実施し続けてよい。
ステップS620において、チャネル監視の結果が、チャネルがアイドルであるというものである場合、端末デバイスは、第1の時間ドメイン位置において、第1のサイドリンクチャネルの送信を開始する。
第1の時間ドメイン位置は、端末デバイスのチャネルアクセスの後の送信スタート点であってよい。端末デバイスは、第1の時間ドメイン位置においてサイドリンクデータ送信を実施し得る。
いくつかの実施形態では、第1の時間ドメイン位置は、指定された時間ドメイン位置であり得る。端末デバイスは、第1のサイドリンクチャネルを、指定された時間ドメイン位置において送信するが、これは、送信スタート点の構成によって影響されないので、アクセスがより柔軟になる。たとえば、第1の時間ドメイン位置は、時点同期の後のスロット中の奇数シンボル、または時点同期の後のスロット中の偶数シンボルであってよい。別の例として、第1の時間ドメイン位置は、チャネル監視が完了した後のどのシンボルであってもよい。
図7は、指定された位置でのデータ送信の概略図である。図7を参照すると、スロット710の第9のシンボルがサイドリンク送信スタート点である。スロット710の第1から第5のシンボル中でチャネル監視を完了した後、端末デバイスは、スロット710の第9のシンボル中でチャネルアクセスを実施する。言い換えると、チャネル監視の完了後の第4のシンボルが、第1の時間ドメイン位置として指定されてよい。図7に示すように、端末デバイスは、スロット710中のリソースをデータ送信用に効果的に使用することができ、アクセスするためのスロット720を待つ必要はない。
いくつかの実施形態では、第1の時間ドメイン位置は第1の指示情報に基づいて示され得る。第1の指示情報は、制御シグナリングの中で搬送され得る。たとえば、第1の指示情報は、SCIのスケジューリング指示情報の中で搬送されてよい。
いくつかの実施形態では、第1の時間ドメイン位置は、第1の時間単位に基づいて判断された時間ドメイン位置であり得る。第1の時間単位は、1スロット未満の時間単位であってよい。
可能な実装形態として、第1の時間単位はハーフスロットであり得る。スロットの早期段階においてチャネル監視が成功した後、端末デバイスは、ハーフスロット中にサイドリンク送信を実施してよく、これが、リソースの浪費を減らすのを助ける。このチャネルアクセスモードは、ハーフスロットチャネルアクセスと呼ばれ得る。たとえば、スロットが14個のシンボルを含むとき、ハーフスロットチャネルアクセスは、同期時点に基づいて、シンボルが7つごとに送信スタート点として使われることを意味する。
図8は、ハーフスロットチャネルアクセスの概略図である。図8を参照すると、スロット820のハーフスロット位置が送信スタート点である。スロット810の最後の3つのシンボルおよびスロット820の最初の2つのシンボル中でチャネル監視を完了した後、端末デバイスは、スロット820のハーフスロット位置においてチャネルアクセスを実施する。図8に示すように、スロット820の第2のシンボル中でチャネル監視を完了した後、端末デバイスは、データ送信を実施するための次のスロットを待つ必要がない。
ハーフスロットチャネルアクセスにおける第1の時間単位の持続時間は、サブキャリア間隔に関連する。たとえば、サブキャリア間隔が30kHzであるとき、スロットの持続時間は0.5msであり、第1の時間単位の持続時間は0.25msである。
可能な実装形態として、第1の時間単位は1つまたは複数のシンボルであってよい。複数のシンボルの数は、スロット中のシンボルの総数未満の任意の整数であってよい。複数のシンボルがハーフスロット未満であるとき、監視が成功した後にデータ送信を実施するために端末デバイスが待つ時間間隔は、比較的短い。たとえば、同期時点に基づいて、シンボルが3つごとに送信スタート点として使われる。
1つまたは複数のシンボルが第1の時間単位として使われるとき、第1の時間単位の持続時間は、シンボルの数および各シンボルの持続時間に関連する。各シンボルの持続時間は、サブキャリア間隔に関連する。たとえば、サブキャリア間隔が15kHzであるとき、各シンボルの持続時間は66.7μsである。
可能な実装形態として、第1の時間単位は、1または複数マイクロ秒であってよい。第1の時間単位が複数マイクロ秒であるとき、端末デバイスは、より細かい時間単位に基づいてチャネルアクセスを実施してよい。たとえば、複数の端末デバイスが、同じ時間ドメイン位置においてデータ送信を実施するとき、その時間ドメイン位置の近くのシンボルが、複数のマイクロ秒競合スロットに分割される。言い換えると、第1の時間ドメイン位置は、複数マイクロ秒の粒度で設定される。各端末デバイスは、規格または構成に従って、競合スロットのうちの1つを、送信スタート点として選択すればよい。原則として、複数の端末デバイスが、同じ時間ドメイン位置においてデータ送信を実施する予定であるとき、チャネル監視をより早く完了した端末デバイスが、この位置を占有することを許される。したがって、チャネル監視をより早く完了した端末デバイスが、第1の時間ドメイン位置を優先的に選択することが規定され得る。
第1の時間単位が複数マイクロ秒であるとき、リソース衝突の問題は効果的に解決することができる。理解しやすいように、図5に示すリソース衝突の解決を例としてとり、より精巧なチャネルアクセスモードについて、図9を参照して以下で詳しく説明する。
図9を参照して、図5のリソース衝突が、2つのスロットの接触点において起こることについて検討するが、接触点に隣接する2つのシンボルは分割される。言い換えると、スロット910の最後のシンボル(#13)およびスロット920の最初のシンボル(#0)が、時間単位931に分割される。
図において、スタート点941は端末デバイス1の送信スタート点であり、スタート点942は端末デバイス2の送信スタート点である。端末デバイス1および端末デバイス2は、図5に示す追加LBTをそれぞれの送信スタート点に同期させ、CCAの後に送信を開始してよい。
スタート点941およびスタート点942が、スロット910の最後のシンボル中に発生する場合、端末デバイスは、送信を直ちに開始してよい。スタート点941およびスタート点942がスロット920の最初のシンボル中に発生する場合、端末デバイスは、図9に示すAGCシンボルをマスクすることによって送信を始動してよい。
より細かい時分割を通して、より詳細なマイクロ秒レベルチャネルアクセスが、最大限まで衝突を回避できることが、図9からわかる。図9に示すマルチマイクロ秒スロットに基づくアクセスは、どのシステム指定シンボル中でも起こり得る。
いくつかの実施形態では、1または複数マイクロ秒は、指定時間単位に基づいて判断され得る。指定時間単位は、制御シグナリング中で搬送される指示情報によって指定されてよい。たとえば、SCIは、複数の端末デバイスがチャネルアクセスを実施するときの競合スロットが20マイクロ秒であると規定するのに使われる。
いくつかの実施形態では、代替として、1または複数マイクロ秒は、チャネル監視の持続時間に基づいて判断されてよい。第1の時間単位は、チャネル監視のためのアクセス要件を満足する必要がある。たとえば、9μsという第1の時間単位は、図4に示す追加LBTのための最短時間要件を満足することができる。別の例として、16μsという第1の時間単位は、図4に示すタイプ2Bアクセスモードを満足することができる。別の例として、25μsという第1の時間単位は、図4に示すタイプ2Aアクセスモードを満足することができる。
可能な実装形態として、複数マイクロ秒は、第1の値、または第1の値の整数倍数であってよい。第1の値は、指定時間単位、またはチャネル監視の持続時間に基づいて判断された時間単位であってよい。たとえば、第1の値は、9μs、16μs、または25μsであってよい。
第1のサイドリンクチャネルは、本明細書において限定されない、PSCCH、PSSCH、およびPSFCHなどのチャネルのうちの1つまたは複数を含み得る。
本出願の実施形態は、現行の第3世代パートナーシッププロジェクト(3GPP)プロトコルによってサポートされるフルスロットチャネルアクセスに基づいて、SL-U送信スタート点の数を増やすことを、上記の記述から知ることができる。SL-Uスロット構造は、指定位置アクセス、ハーフスロットアクセス、より精巧なアクセス、および他のアクセスモードをサポートし、これにより、チャネルアクセスの柔軟性が向上し、リソース衝突の確率が低下し、リソースの浪費、およびチャネルアクセス遅延によって引き起こされるアクセス遅延が低減する。
上述したように、サイドリンクモード2のリソーススケジューリング方式において、端末デバイスは、チャネル監視が成功した後にリソース選択を実施する必要がある。端末デバイスによる検知および送信準備処理の持続時間中、別のRATが、チャネルにアクセスし、占有する場合があり、これにより、端末デバイスの前のチャネル監視が無効になる。
このことに鑑みて、本出願の実施形態は、別のサイドリンク通信方法および装置を提案する。この方法では、チャネル監視およびアクセスが成功した後、端末デバイスは、リソース選択なしで、後続送信に要するリソースを取得することができる。サイドリンク通信方法については、図10を参照して以下で詳しく説明する。図10に示す方法は、図6に関連する。したがって、簡潔のために、図6にすでに現れた用語については、図10において再度詳しくは説明しない。
図10を参照すると、ステップS1010において、端末デバイスが共有スペクトルの第1のリソース上でチャネルアクセスを実施する。
チャネルアクセスは、データ送信のための端末デバイスの初回アクセスであり得る。いくつかの実施形態では、チャネルアクセスは、端末デバイスによって実施される初回アクセスのみを含み得る。たとえば、チャネルアクセスは、リソース検知およびアクセスであり得る。いくつかの実施形態では、チャネルアクセスは、端末デバイスによって実施されるチャネル監視および初回アクセスを含み得る。
第1のリソースは、共有スペクトル中の、指定された時間周波数リソースまたは予約された時間周波数リソースであってもよく、共有スペクトル中の別の端末デバイスに対応するリソースプール中の共有リソースであってもよい。端末デバイスは、第1のリソースにおいてチャネルアクセスを実施し、第1のリソースは、アクセスリソースとも呼ばれ得る。
いくつかの実施形態では、第1のリソースとしての共有リソースは、別の端末デバイス用の、ネットワークによって構成されたリソースプール中のリソースであってもよく、チャネル監視を通して別の端末デバイスによって取得されたリソースプール中のリソースであってもよい。たとえば、第1のリソースは、別の端末デバイスのリソースプール中の予約されたリソースであってよい。
いくつかの実施形態では、第1のリソースは、端末デバイスによって、リソース検知およびアクセスを実施するのに使われてよい。第1のリソースは、端末デバイスによって初回アクセスのために要するリソースとして使われてもよく、端末デバイスによってチャネル監視および初回アクセスのために要するリソースとして使われてもよい。たとえば、第1のリソースが、端末デバイスのチャネル監視およびアクセスを決定してよい。
いくつかの実施形態では、第1のリソースは、端末デバイスによって、初回送信に使われ得る。端末デバイスは、第1のリソースの前にチャネル監視を実施してよく、利用可能なチャネルが見つからない場合、端末デバイスは第1のリソースにおいて待てばよい。
いくつかの実施形態では、第1のリソースは、専用周波数範囲において再送信リソース用に使われてもよい。たとえば、第1のリソースは、トランスポートブロック(TB)のいくつかの再送信用に使われてよい。
いくつかの実施形態では、第1のリソースについての情報が、複数の方式で通知され得る。たとえば、専用制御シグナリングが、サイドリンク端末デバイスに対して第1のリソースを通知するのに使用され得る。別の例として、ブロードキャスト情報が、サイドリンク端末デバイスに対して第1のリソースを通知するのに使われ得る。
ステップS1020において、端末デバイスは第1のサイドリンクチャネルを第2のリソース上で送信する。
第2のリソースは、端末デバイスによってチャネル監視を通して発見されたチャネルにとって利用可能な時間周波数リソースであってよい。端末デバイスは、第2のリソース上でデータを送信し、第2のリソースは、送信リソースとも呼ばれ得る。たとえば、第2のリソースは、共有スペクトル中の利用可能なリソースであってもよく、別の端末デバイスのリソースプール中の共有リソースであってもよい。
第2のリソースは、第1のリソースに関連付けられたリソースプール中のリソースブロックであってよい。いくつかの実施形態では、第2のリソースは、連続リソースブロック、単一のリソースブロック、または個別リソースブロックであってよい。
いくつかの実施形態では、第1のリソースが、アクセスのために要するリソースとして使われるとき、第1のリソースは、リソースプール中の第2のリソースに関連付けられ得る。たとえば、第1のリソースは、第2のリソースのインデックスとして働き得る。リソースプール中の第2のリソースは、第1のリソースのインデックスの指示に従ってマップすることができる。
第2のリソースは、チャネル監視が成功した後、端末デバイスによって後続送信のために要するリソースであってよい。たとえば、第1のリソースが第2のリソースのインデックスであるとき、端末デバイスが第1のリソース上でのチャネル監視の実施に成功する限り、リソースインデックスは、サービスの後続送信のために要するリソースをポイントすることができる。端末デバイスは、後続リソース選択を実施することも、リソース割振りを要求することも必要なく、したがって、可能なリソース衝突問題を回避することができる。
いくつかの実施形態では、第1のリソースと第2のリソースとの間の関連付け関係が、複数の方式で通知されてもよい。たとえば、専用制御シグナリングが、サイドリンク端末デバイスに関連付け関係を通知するのに使用されてよい。別の例として、ブロードキャスト情報が、サイドリンク端末デバイスに対して関連付け関係を通知するのに使われ得る。
第1のリソースと第2のリソースとの間の関連付け関係は、1つまたは複数のタイプの情報に基づいて判断され得る。
いくつかの実施形態では、第1のリソースと第2のリソースとの間の関連付け関係は、第1の情報に基づいて判断され得る。第1の情報は、第2のリソースの時間ドメイン位置を示すために使われ得る。たとえば、第1の情報は、時間ドメインスタート位置と、第2のリソースの持続時間とを含み得る。別の例として、第1の情報は、時間ドメインスタート位置と、第2のリソースの終了時間とを含み得る。
可能な実装形態として、第1の情報を表すのにConfigIndexが、時間ドメインスタート位置を表すのにTinitialが、持続時間を表すのにLが使われる。第1の情報は、
ConfigIndex∈[Tinitial,Tinitial+L]
を満足し、上式で、Tinitialは、第2のリソースの時間ドメイン中のスタートシンボルとして、同期時点に基づいて判断され得る。Lは、第2のリソースの持続性のシンボル長であり得る。
可能な実装形態として、第2のリソースの時間ドメインスタート位置は、第1の時間単位の時間ドメインスタート位置、または指示情報によって示される時間ドメインスタート位置であってよい。第1の時間単位は、スロット、ハーフスロット、1つもしくは複数のシンボル、または1もしくは複数マイクロ秒であってよく、本明細書において限定されない。たとえば、スロットが14個のシンボルを含み、第1の時間単位がスロットであるとき、14個ごとのシンボルの時間ドメイン位置は、同期タイムラインに基づくTinitialである。第1の時間単位がハーフスロットであるとき、7つごとのシンボルの時間ドメイン位置は、同期タイムラインに基づくTinitialである。別の例として、指示情報によって指定される時間ドメイン位置はTinitialである。
いくつかの実施形態では、複数の端末デバイスが、第2のリソース上でサイドリンクチャネルを送信する予定であるとき、第1の情報は、1つまたは複数のタイプの情報に基づいて判断され得る。情報は、COTによって共有することができる最大利用可能シンボル数または最大シンボル数など、リソースプール中の利用可能な時間ドメインリソースの最大値であってよい。情報は、リソースプールの時間ドメイン中の第2のリソースの総数、たとえば、Kであってよく、Kは正の整数である。情報は、端末デバイスの数であってもよい。たとえば、あるときには、M個の実際に接続された端末デバイスがあり、Mは、K以下の正の整数であってよい。情報は、時間ドメイン中の各端末デバイスに対応する第2のリソースの数、たとえば、K/Mであってよい。
可能な実装形態として、リソースプール中の時間ドメインリソースは均等に分割される。Tmax個の時間ドメインリソースがKに均等に分割された後、上で言及したLはL=Tmax/Kとして表されてよく、各リソースブロックの第1の情報は、
ConfigIndex∈[Tinitial,Tinitial+(Tmax/K)]
を満足する。
第iのリソースブロックの第1の情報は、
を満足し、上式で、iは、0からK-1の値の整数であり、
は、チャネル監視が成功した後の第iのリソースブロックに対応するサービスのためのチャネルアクセス中の特定のスロット中のシンボルである。
M個の端末デバイスが、第2のリソースが属すリソースプールにアクセスし、時間ドメインリソースが均等に分割されている場合、M個の端末デバイスの中の第iの端末デバイスに対応する第1の情報ConfigIndexは、
を満足し、上式で、iは、0からM-1の値の整数であり、
は、第iの端末デバイスに対応する第2のリソースの時間ドメインスタート位置を表し、Pは、時間ドメイン中の第iの端末デバイスに対応する第2のリソースの数を表し、Tmaxは、リソースプール中の利用可能な時間ドメインリソースの最大値を表し、Kは、リソースプールの時間ドメイン中の第2のリソースの総数を表す。リソースは均等に分割されるので、PはK/Mと定義され得る。
可能な実装形態として、リソースプール中の時間ドメインリソースが均等に分割されない場合がある。たとえば、各リソースブロックのいくつかのシンボルは、差分(differential)シーケンスに従ってソートされてもよく、または増加シーケンスもしくは減少シーケンスに従ってソートされてもよい。
いくつかの実施形態では、第1のリソースと第2のリソースとの間の関連付け関係は、第2の情報に基づいて判断され得る。第2の情報は、第2のリソースの周波数ドメイン位置を示すために使われ得る。たとえば、第2の情報は、周波数ドメインスタート位置と、第2のリソースの周波数ドメインサイズとを含み得る。別の例として、第2の情報は、第2のリソースの周波数ドメインスタート位置および周波数ドメインエンド位置を含み得る。
可能な実装形態として、第2の情報はFreqIndexによって表され得る。FreqIndexは、周波数ドメイン中でどの物理リソースブロック(PRB)から第2のリソースが開始するかを示してもよく、または第2のリソースによって占有される周波数ドメインサイズを示してもよい。たとえば、第2のリソースによって占有されるRBは、1つもしくは複数の連続RBであってもよく、複数の非連続RBであってもよい。別の例として、第2のリソースによって占有される、これらのRBのうちの複数のRBは、固定値であってもよく、端末デバイスまたは送信サービスの優先レベルに従って様々に設定されてもよい。
可能な実装形態として、リソースプール中のRBは、周波数インデックスに基づいてソートされる。たとえば、リソースプールの最低周波数から開始して、RBは、周波数の昇順で番号付けられる。n_SL_PRBは、リソースプール中の第2のリソースの周波数ドメインにおける開始RB番号であってよく、RBoffsetは、周波数ドメイン中の第2のリソースによってオフセットされたRBの数であってよい。したがって、第2の情報は、
FreqIndex∈[n_SL_PRB,n_SL_PRB+RBoffset]
を満足し、上式で、n_SL_PRBは周波数ドメインスタート位置を表し、RBoffsetは周波数ドメインサイズを表す。
いくつかの実施形態では、複数の端末デバイスが、第2のリソース上でサイドリンクチャネルを送信する予定であるとき、第2の情報は、1つまたは複数のタイプの情報に基づいて判断され得る。情報は、帯域幅パート(BWP)の中の最大利用可能リソース数
など、リソースプール中の利用可能な周波数ドメインリソースの最大値であってよい。情報は、リソースプールの周波数ドメイン中の第2のリソースの総数、たとえば、Kであってよい。情報は、端末デバイスの数、たとえば、Mであってよい。情報は、周波数ドメイン中の各端末デバイスに対応する第2のリソースの数、たとえば、K/Mであってよい。
可能な実装形態として、リソースプール中の周波数ドメインリソースは均等に分割される。Nmax個の周波数ドメインリソースがKに均等に分割された後、上で言及したRBoffsetは、RBoffset=Nmax/Kと表されてよく、各リソースブロックの第2の情報は、
FreqIndex∈[n_SL_PRB,n_SL_PRB+(Nmax/K)]
を満足する。
第iのリソースブロックの第2の情報は、
FreqIndex∈[n_SL_PRBi,n_SL_PRBi+(Nmax/K)]、および
n_SL_PRBi=n_SL_PRB0+i×(Nmax/K)
を満足し、上式で、iは、0からK-1の値の整数である。
M個の端末デバイスが、第2のリソースが属すリソースプールにアクセスし、周波数ドメインリソースが均等に分割されている場合、M個の端末デバイスの中の第iの端末デバイスに対応する第2の情報FreqIndexは、
FreqIndex∈[n_SL_PRBi,n_SL_PRBi+P×(Nmax/K)]、および
n_SL_PRBi=n_SL_PRB0+i×P×(Nmax/K)
を満足し、上式で、iは、0からM-1の値の整数であり、n_SL_PRBiは、第iの端末デバイスに対応する第2のリソースの周波数ドメインスタート位置を表し、Pは、周波数ドメイン中の第iの端末デバイスに対応する第2のリソースの数を表し、Nmaxは、リソースプール中の利用可能な周波数ドメインリソースの最大値を表し、Kは、リソースプールの周波数ドメイン中の第2のリソースの総数を表す。リソースは均等に分割されるので、PはK/Mと定義され得る。
可能な実装形態として、リソースプール中の周波数ドメインリソースが均等に分割されない場合がある。たとえば、各リソースブロックのいくつかのRBは、差分シーケンスに従ってソートされてもよく、または増加シーケンスもしくは減少シーケンスに従ってソートされてもよい。
いくつかの実施形態では、第1のリソースと第2のリソースとの間の関連付け関係は、第1の情報および第2の情報に基づいて判断され得る。第1の情報は、第2のリソースの時間ドメイン位置を示すために使われ、第2の情報は、第2のリソースの周波数ドメイン位置を示すために使われる。第2のリソースの位置は、後続リソース衝突を回避するように、第1のリソースのインデックスに基づいて判断されてよい。たとえば、インデックスはIndex(x,y)と表されてよく、ここで、xは第2のリソースの時間ドメインパラメータを表し、yは第2のリソースの周波数ドメインパラメータを表す。
可能な実装形態として、端末デバイスが共有スペクトル上で初回アクセスを実施するための第1のリソースのインデックスは、Index(ConfigIndex,FreqIndex)であってよい。第2のリソースのConfigIndexおよびFreqIndexは、上述した方法に従って判断される。チャネル監視が成功した後、端末デバイスは、PSCCH/PSSCH/PSFCHを送信するための位置を、インデックスに基づいて判断してよい。
可能な実装形態として、複数の端末デバイスがチャネルアクセスを実施した後、リソースプール中の利用可能なリソースは、各端末デバイスに割り振られた時間周波数リソース(ConfigIndex,FreqIndex)を取得するように、端末デバイスの数に基づいて分割されてよい。
可能な実装形態として、リソースプール中の利用可能な時間周波数リソースは均等に分割される。利用可能な時間周波数リソースが、同じサイズの第2のリソースに均等に分割されると、サイドリンクは、ほとんどのチャネルリソースを取得することができる。たとえば、時間周波数リソースがNRBG個のリソースグループに分割されるとき、NRBGはリソースブロックグループ(RBG)の数を表す。NRBGは、リソースプール中のリソースを割り振られ得る端末デバイスの最大許容値も表す。
可能な実装形態として、リソースプール中の利用可能なリソースは、異なるサイズのリソースブロックに分割される。各端末デバイスは、サービス要件に基づいて、異なるサイズの第2のリソース上で送信を実施し得る。たとえば、各リソースブロックのサイズは、差分シーケンスに従ってソートされてもよく、または増加シーケンスもしくは減少シーケンスに従ってソートされてもよい。
理解しやすいように、SL-Uリソースプールを例としてとり、リソースプール中の第2のリソースの均等分割および不均等分割に対応するマッピング関係について、それぞれ図11および図12を参照して以下で説明する。図11は、第2のリソースが均等に分割されているときの第1のリソースと第2のリソースとの間の関連付けの概略図である。図12は、第2のリソースが均等に分割されていないときの第1のリソースと第2のリソースとの間の関連付けの概略図である。
図11を参照すると、時間および周波数インターリーブリソースプールにおいて、水平軸上の各グリッドはスロットを表し、垂直軸上の各グリッドはサブチャネルを表す。3つの端末デバイスが、リソースプール中でチャネルアクセスを実施する。図11に示すように、リソースプール中で、第1のリソースが、異なる端末デバイス用のアクセスリソースとして使われ、対応する3つのリソースブロックのサイズは異なる。第2のリソースが、異なる端末デバイス用の送信リソースとして使われ、対応する3つのリソースブロックのサイズは同じである。言い換えると、端末デバイスのサービス要件またはアクセスリソースのサイズにかかわらず、端末デバイスはすべて、監視が成功した後、同じサイズの送信リソースを取得する。
図11は、第1のリソースと第2のリソースとの間の様々なマッピング関係を記述する。マッピング関係1110はフルスロットチャネルアクセス用であり、マッピング関係1120はハーフスロットチャネルアクセス用であり、マッピング関係1130は指定位置チャネルアクセス用である。
図12は、3つの第2のリソースに対応するリソースブロックのサイズが異なるという点が主に、図11とは異なる。言い換えると、チャネル監視が成功した後で3つの端末デバイスによって取得される送信リソースのサイズが異なる。図12に示すように、マッピング関係1220における第2のリソース用のリソースブロックが最も大きい。大きいサービス要件を有する端末デバイスが、マッピング関係1220において、第1のリソース上でチャネルアクセスを実施し得る。
上記の記述から、端末デバイスが共有スペクトルの第1のリソース上でチャネルアクセスを実施すると、第1のリソースと第2のリソースとの間の関連付け関係に基づいて、端末デバイス用の後続送信リソースを取得できることがわかる。言い換えると、端末デバイスがチャネル監視の実施に成功する限り、後続送信に要するリソースが保証され得る。したがって、端末デバイスはリソース選択を実施する必要がなく、これにより、リソース選択中に、検出に成功したチャネルを別のRATが占有する状況を回避する。
本出願の方法実施形態について、図6~図12を参照して上で詳細に説明した。本出願の装置実施形態について、図13~図15を参照して以下で詳細に説明する。装置実施形態の記述は、方法実施形態の記述に対応し、したがって、詳しく記載しない部分については、上記の方法実施形態に対して参照が行われればよいことを理解されたい。
図13は、本出願の実施形態による通信装置を示す概略ブロック図である。装置1300は、上述したどの端末デバイスであってもよい。図13に示す装置1300は、監視ユニット1310および送信ユニット1320を含む。
監視ユニット1310は、共有スペクトル上でチャネル監視を実施するように構成され得る。
送信ユニット1320は、チャネル監視の結果が、チャネルがアイドルであるというものである場合、第1の時間ドメイン位置において、第1のサイドリンクチャネルの送信を開始するように構成され得る。第1の時間ドメイン位置は、第1の指示情報によって示される時間ドメイン位置、および第1の時間単位に基づいて判断された時間ドメイン位置のうちの1つまたは複数であり、第1の時間単位は1スロットよりも小さい。
任意選択で、第1の時間単位は、ハーフスロット、1つもしくは複数のシンボル、および1もしくは複数マイクロ秒のうちの1つまたは複数を含む。
任意選択で、1または複数マイクロ秒は、指定時間単位、およびチャネル監視の持続時間という情報のうちの1つまたは複数に基づいて判断される。
任意選択で、1または複数マイクロ秒は、第1の値、または第1の値の整数倍数であり、第1の値は、9マイクロ秒、16マイクロ秒、および25マイクロ秒のうちの1つである。
任意選択で、第1の指示情報は、制御シグナリングの中で搬送される。
図14は、本出願の別の実施形態による通信装置を示す概略ブロック図である。装置1400は、上述したどの端末デバイスであってもよい。図14に示す装置1400は、アクセスユニット1410および送信ユニット1420を含む。
アクセスユニット1410は、共有スペクトルの第1のリソース上でチャネルアクセスを実施するように構成されてよく、第1のリソースは、リソースプール中の第2のリソースに関連付けられる。
送信ユニット1420は、第2のリソース上で第1のサイドリンクチャネルを送信するように構成されてよい。
任意選択で、第1のリソースと第2のリソースとの間の関連付け関係は、第2のリソースの時間ドメイン位置を示すための第1の情報、および第2のリソースの周波数ドメイン位置を示すための第2の情報という情報のうちの1つまたは複数に基づいて判断される。
任意選択で、第1の情報は、第2のリソースの時間ドメインスタート位置、第2のリソースの持続時間、および第2のリソースの終了時間という情報のうちの1つまたは複数を含む。
任意選択で、第2のリソースの時間ドメインスタート位置は、第1の時間単位の時間ドメインスタート位置、および指示情報によって示される時間ドメインスタート位置のうちの1つである。第1の時間単位は、スロット、ハーフスロット、1つまたは複数のシンボル、および1または複数マイクロ秒のうちの1つである。
任意選択で、第2の情報は、第2のリソースの周波数ドメインスタート位置、第2のリソースの周波数ドメインサイズ、および第2のリソースの周波数ドメインエンド位置という情報のうちの1つまたは複数を含む。
任意選択で、第1の情報は、リソースプール中の利用可能な時間ドメインリソースの最大値、リソースプールの時間ドメイン中の第2のリソースの総数、端末デバイスの数、および時間ドメイン中の各端末デバイスに対応する第2のリソースの数のうちの1つまたは複数に基づいて判断される。
任意選択で、M個の端末デバイスがあり、M個の端末デバイスの中の第iの端末デバイスに対応する第1の情報ConfigIndexが、
を満足し、上式で、iは0からM-1の値の整数であり、
は、第iの端末デバイスに対応する第2のリソースの時間ドメインスタート位置を表し、Pは、時間ドメイン中の第iの端末デバイスに対応する第2のリソースの数を表し、Tmaxは、リソースプール中の利用可能な時間ドメインリソースの最大値を表し、Kは、リソースプールの時間ドメイン中の第2のリソースの総数を表す。
任意選択で、第2の情報は、リソースプールの、周波数ドメイン中の第2のリソースの総数、端末デバイスの数、リソースプール中の利用可能な周波数ドメインリソースの最大値、および周波数ドメイン中の、各端末デバイスに対応する第2のリソースの数のうちの1つまたは複数に基づいて判断される。
任意選択で、端末デバイスはM個の端末デバイスを含み、M個の端末デバイスの中の第iの端末デバイスに対応する第2の情報FreqIndexが、
FreqIndex∈[n_SL_PRBi,n_SL_PRBi+P×(Nmax/K)]
を満足し、上式で、iは、0からM-1の値の整数であり、n_SL_PRBiは、第iの端末デバイスに対応する第2のリソースの周波数ドメインスタート位置を表し、Pは、周波数ドメイン中の第iの端末デバイスに対応する第2のリソースの数を表し、Nmaxは、リソースプール中の利用可能な周波数ドメインリソースの最大値を表し、Kは、リソースプールの周波数ドメイン中の第2のリソースの総数を表す。
図15は、本出願の実施形態による通信装置を示す概略構造図である。図15における破線は、ユニットまたはモジュールが任意選択であることを示す。装置1500は、上記の方法実施形態において記載した方法を実装するように構成され得る。装置1500は、チップまたは端末デバイスであってよい。
装置1500は、1つまたは複数のプロセッサ1510を含み得る。プロセッサ1510により、装置1500は、上記の方法実施形態において記載した方法を実装することが可能になり得る。プロセッサ1510は、汎用プロセッサまたは専用プロセッサであってよい。たとえば、プロセッサは中央処理ユニット(CPU)であってよい。代替として、プロセッサは、別の汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラム可能ゲートアレイ(FPGA)もしくは別のプログラム可能論理デバイス、個別ゲートもしくはトランジスタ論理デバイス、または個別ハードウェア構成要素であってよい。汎用プロセッサはマイクロプロセッサであってよく、またはプロセッサは、任意の従来のプロセッサなどであってよい。
装置1500は、1つまたは複数のメモリ1520をさらに含み得る。メモリ1520は、プロセッサ1510に、上記の方法実施形態において記載した方法を実施させるようにプロセッサ1510によって実行することができるプログラムを記憶する。メモリ1520は、プロセッサ1510から独立していてもよく、プロセッサ1510に統合されてもよい。
装置1500は、トランシーバ1530をさらに含み得る。プロセッサ1510は、トランシーバ1530を通して別のデバイスまたはチップと通信することができる。たとえば、プロセッサ1510は、トランシーバ1530を通して、別のデバイスまたはチップとの間でデータを送り、受信することができる。
本出願の実施形態は、プログラムを記憶するためのコンピュータ可読記憶媒体をさらに提供する。コンピュータ可読記憶媒体は、本出願の実施形態において提供される端末またはネットワークデバイスに適用することができ、プログラムは、コンピュータに、本出願の様々な実施形態における端末またはネットワークデバイスによって実施されるべき方法を実施させる。
本出願の実施形態は、コンピュータプログラム製品をさらに提供する。コンピュータプログラム製品は、プログラムを含む。コンピュータプログラム製品は、本出願の実施形態において提供される端末またはネットワークデバイスに適用することができ、プログラムは、コンピュータに、本出願の様々な実施形態における端末またはネットワークデバイスによって実施されるべき方法を実施させる。
本出願の実施形態は、コンピュータプログラムをさらに提供する。コンピュータプログラムは、本出願の実施形態において提供される端末またはネットワークデバイスに適用することができ、コンピュータプログラムは、コンピュータに、本出願の様々な実施形態における端末またはネットワークデバイスによって実施されるべき方法を実施させる。
本出願における「システム」および「ネットワーク」という用語は、互換的に使用され得る。さらに、本出願において使われる用語は、本出願の特定の実施形態を説明するためにのみ使われるのであって、本出願を限定することは意図していない。本出願の明細書、特許請求の範囲、および図面における「第1の」、「第2の」、「第3の」、「第4の」などの用語は、特定の順番を記述するためではなく、異なる事物を区別するために使われていることに留意されたい。さらに、「備える」および「有する」という用語ならびにそれらのどの変化形も、非排他的包含をカバーすることを意図している。
本出願の実施形態では、本明細書において言及される「示す」は、直接指示を指す場合があり、または間接指示を指す場合があり、または関連付け関係があることを意味する場合がある。たとえば、AがBを示すということは、Aが直接Bを示す、たとえば、BがAを用いて取得され得ることを意味する場合があり、またはAが間接的にBを示す、たとえば、AがCを示し、BがCを用いて取得され得ることを意味する場合があり、またはAとBとの間に関連付け関係があることを意味する場合がある。
本出願の実施形態において、「対応する」という用語は、その2つの間に直接もしくは間接対応があることを意味する場合があり、またはその2つの間に関連付け関係があることを意味する場合があり、この関連付け関係は、示し示される、もしくは構成し構成される、などの関係であってもよい。
本出願の実施形態において、「事前定義される」または「事前構成される」は、デバイス(たとえば、端末デバイスおよびネットワークデバイスを含む)における関連情報を示すのに使うことができる、対応するコード、テーブル、または他の形をあらかじめ記憶することによって実装されてよく、その特定の実装形態は、本出願において限定されない。たとえば、事前定義されるということは、プロトコル中で定義されることを指し得る。
本出願の実施形態において、「プロトコル」は、通信分野における標準プロトコルを指してよく、たとえば、LTEプロトコル、NRプロトコル、および将来の通信システムに適用される関連プロトコルを含んでよく、これは本出願において限定されない。
本出願の実施形態において、Aに基づいてBを判断することは、Aのみに基づいてBを判断することを意味するのではなく、Bは、Aおよび/または他の情報に基づいて判断されてよい。
本出願の実施形態において、「および/または」という用語は、関連付けられる事物の間の関連付け関係を記述するために使われるにすぎず、3つの関係があり得ることを示す。たとえば、Aおよび/またはBは、Aのみが存在する、AとBの両方が存在する、およびBのみが存在することを示し得る。さらに、本明細書における記号「/」は概して、関連付けられる事物の間の「または」関係を示す。
本出願の実施形態において、上記のプロセスの順序番号は、実行順序を意味しない。プロセスの実行順序は、プロセスの機能および内部論理に従って判断されるべきであり、本出願の実施形態の実装プロセスに対するいかなる限定としても企図されるべきでない。
本出願において提供されるいくつかの実施形態において、開示したシステム、デバイス、および方法は、他のやり方で実装され得ることを理解されたい。たとえば、記載するデバイス実施形態は例にすぎない。たとえば、ユニット区分は、論理的な機能区分にすぎず、実際の実装では他の区分であってよい。たとえば、複数のユニットもしくは構成要素は、別のシステムに組み合わされて、もしくは統合されてよく、またはいくつかの特徴は、無視され、もしくは実施されなくてよい。さらに、示し、または論じた相互結合もしくは直接結合または通信接続は、いくつかのインターフェースを使って実装されてよい。デバイスもしくはユニットの間の間接結合または通信接続は、電子、機械、または他の形で実装されてよい。
別々の構成要素として記述されるユニットは、物理的に分けられても分けられなくてもよく、ユニットとして表示する構成要素は、物理ユニットであってもなくてもよく、すなわち、1つの場所にあるか、または複数のネットワークユニット上に分散されてよい。ユニットの一部または全部は、実施形態の解決策の目的を遂行する実際の必要に従って選択されてよい。
さらに、本出願の実施形態における機能ユニットは、1つの処理ユニットに統合されてもよく、ユニットの各々が、単独で物理的に存在してもよく、または2つ以上のユニットが1つのユニットに統合される。
上記の実施形態のうちの全部または一部は、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せを使うことによって実装され得る。実施形態を実装するのにソフトウェアが使われるとき、上記の実施形態は、完全に、または部分的に、コンピュータプログラム製品の形で実装されてよい。コンピュータプログラム製品は、1つまたは複数のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータ上にロードされ、実行されると、本出願の実施形態による手順または機能が完全に、または部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または別のプログラム可能装置であってよい。コンピュータ命令は、コンピュータ可読記憶媒体に記憶されるか、またはあるコンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体へ送信されてよい。たとえば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバ、またはデータセンターから、ワイヤード(同軸ケーブル、光ファイバー、およびデジタル加入者線(DSL)など)方式またはワイヤレス(赤外線、ワイヤレス、およびマイクロ波など)方式により、別のウェブサイト、コンピュータ、サーバ、またはデータセンターへ送信されてよい。コンピュータ可読記憶媒体は、コンピュータによって可読な任意の使用可能媒体、または1つもしくは複数の使用可能媒体を統合するサーバまたはデータセンターなどのデータ記憶デバイスであってもよい。使用可能媒体は、磁気媒体(たとえば、フロッピーディスク、ハードディスク、または磁気テープ)、光学媒体(たとえば、デジタル多用途ディスク(DVD))、半導体媒体(たとえば、固体状態ドライブ(SSD))などであってよい。
上記の記述は、本出願の特定の実装形態にすぎず、本出願の保護範囲はそれらに限定されない。本出願において開示した技術的範囲内で当業者によって容易に考え出されるいかなる変化または置換えも、本出願の保護範囲に入るものとする。したがって、本出願の保護範囲は、添付の特許請求の範囲の保護範囲の対象であるものとする。