JP2024504741A - リソース処理方法、装置、端末と記憶媒体 - Google Patents

リソース処理方法、装置、端末と記憶媒体 Download PDF

Info

Publication number
JP2024504741A
JP2024504741A JP2023545366A JP2023545366A JP2024504741A JP 2024504741 A JP2024504741 A JP 2024504741A JP 2023545366 A JP2023545366 A JP 2023545366A JP 2023545366 A JP2023545366 A JP 2023545366A JP 2024504741 A JP2024504741 A JP 2024504741A
Authority
JP
Japan
Prior art keywords
resource
terminal
collision
conflicting
transmission
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023545366A
Other languages
English (en)
Inventor
▲歡▼ 王
子超 ▲紀▼
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vivo Mobile Communication Co Ltd
Original Assignee
Vivo Mobile Communication Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vivo Mobile Communication Co Ltd filed Critical Vivo Mobile Communication Co Ltd
Publication of JP2024504741A publication Critical patent/JP2024504741A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/25—Control channels or signalling for resource management between terminals via a wireless link, e.g. sidelink
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/02—Selection of wireless resources by user or terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/04—Error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1825—Adaptation of specific ARQ protocol parameters according to transmission conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1854—Scheduling and prioritising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/53—Allocation or scheduling criteria for wireless resources based on regulatory allocation policies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
    • H04W72/543—Allocation or scheduling criteria for wireless resources based on quality criteria based on requested quality, e.g. QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H04W72/566—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/40—Resource management for direct mode communication, e.g. D2D or sidelink
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Figure 2024504741000001
本出願は、リソース処理方法、装置、端末と記憶媒体を提供し、この方法は、第一の端末がターゲット操作を実行することを含み、前記ターゲット操作は、衝突リソースを検出することと、衝突リソースに対し、衝突処理操作を実行することと、前記第一の端末の物理サイドリンクチャネルの相手側である第二の端末のリソースに基づいてＳＬリソース選択を行うこととのうちの少なくとも一つを含み、ここで、前記衝突リソースは、ＳＬリソース間の衝突と、ＳＬリソースと非ＳＬリソースとの間の衝突とのうちの少なくとも一つを含む。

Description

（関連出願の相互参照）
本出願は、２０２１年０１月２６日に中国で提出された中国特許出願Ｎｏ．２０２１１０１０６３４０．２の優先権を主張しており、同出願の内容のすべては、ここに参照として取り込まれる。
本出願は、通信技術分野に関し、特にリソース処理方法、装置、端末と記憶媒体に関する。
いくつかの通信システム（例えば、第５世代移動通信（５ｔｈ－Ｇｅｎｅｒａｔｉｏｎ、５Ｇ）システム）におけるサイドリンク（ｓｉｄｅｌｉｎｋ、ＳＬ）リソース割り当ては、ネットワーク機器スケジューリングモードと端末自律リソース選択モードとを含み、ここで、ネットワーク機器スケジューリングモードは、ネットワーク機器が下りリンクシグナリングによって端末の伝送リソースを通知することを指し、端末自律リソース選択モードは、端末がリソースプールにおいて使用可能な伝送リソースを選択することを指す。しかしながら現在端末がＳＬリソースを選択することは、直接に選択することであり、例えば、リソースプールにおいてリソースをランダムに選択し、このように端末のＳＬの処理能力が比較的低くなることを引き起こす。
本出願の実施例は、端末のＳＬの処理能力が比較的低いという問題を解決することができるリソース処理方法、装置、端末と記憶媒体を提供する。
第一の態様によれば、本出願の実施例は、リソース処理方法を提供し、この方法は、
第一の端末がターゲット操作を実行することを含み、ここで、前記ターゲット操作は、
衝突リソースを検出することと、
衝突リソースに対し、衝突処理操作を実行することと、
前記第一の端末の物理サイドリンクチャネルの相手側である第二の端末のリソースに基づいてＳＬリソース選択を行うこととのうちの少なくとも一つを含み、
ここで、前記衝突リソースは、
ＳＬリソース間の衝突と、
ＳＬリソースと非ＳＬリソースとの間の衝突とのうちの少なくとも一つを含む。
第二の態様によれば、本出願の実施例は、リソース処理装置を提供し、この装置は、
ターゲット操作を実行するための実行モジュールを含み、ここで、前記ターゲット操作は、
衝突リソースを検出することと、
衝突リソースに対し、衝突処理操作を実行することと、
前記リソース処理装置を含む第一の端末の物理サイドリンクチャネルの相手側である第二の端末のリソースに基づいてサイドリンクＳＬリソース選択を行うこととのうちの少なくとも一つを含み、
ここで、前記衝突リソースは、
サイドリンクＳＬリソース間の衝突と、
ＳＬリソースと非ＳＬリソースとの間の衝突とのうちの少なくとも一つを含む。
第三の態様によれば、本出願の実施例は、端末を提供し、前記端末は、第一の端末であり、メモリと、プロセッサと、前記メモリに記憶され、且つ前記プロセッサ上で運行できるプログラム又は命令とを含み、前記プログラム又は命令が前記プロセッサにより実行される時に、本出願の実施例によるリソース処理方法におけるステップを実現する。
第四の態様によれば、本出願の実施例は、可読記憶媒体を提供し、前記可読記憶媒体上にはプログラム又は命令が記憶されており、前記プログラム又は命令がプロセッサにより実行される時に、本出願の実施例によるリソース処理方法におけるステップを実現する。
第五の態様によれば、本出願の実施例は、コンピュータプログラム製品を提供し、前記コンピュータプログラム製品が非一時的記憶媒体に記憶されており、前記コンピュータプログラム製品が少なくとも一つのプロセッサにより実行されて、本出願の実施例によるリソース処理方法におけるステップを実現する。
第六の態様によれば、本出願の実施例は、通信機器を提供し、前記通信機器は、本出願の実施例によるリソース処理方法におけるステップを実行するように構成される。
本出願の実施例では、第一の端末は、ターゲット操作を実行し、ここで、前記ターゲット操作は、衝突リソースを検出することと、衝突リソースに対し、衝突処理操作を実行することと、前記第一の端末の物理サイドリンクチャネルの相手側である第二の端末のリソースに基づいてＳＬリソース選択を行うこととのうちの少なくとも一つを含み、ここで、前記衝突リソースは、ＳＬリソース間の衝突と、ＳＬリソースと非ＳＬリソースとの間の衝突とのうちの少なくとも一つを含む。上記ターゲット操作によって、端末のＳＬの処理能力を向上させることができる。
本出願の実施例に適用可能な無線通信システムの構造図である。 本出願の実施例によるリソース処理方法のフローチャートである。 本出願の実施例によるシナリオ概略図である。 本出願の実施例によるシナリオ概略図である。 本出願の実施例によるシナリオ概略図である。 本出願の実施例によるシナリオ概略図である。 本出願の実施例によるシナリオ概略図である。 本出願の実施例によるリソース処理装置の構造図である。 本出願の実施例による端末の構造図である。
以下は、本出願の実施例における図面を結び付けながら、本出願の実施例における技術案を明瞭に記述し、明らかに、記述された実施例は、本出願の一部の実施例であり、すべての実施例ではない。本出願における実施例に基づき、当業者により得られたすべての他の実施例は、いずれも本出願の保護範囲に属する。
本出願の明細書と特許請求の範囲における用語である「第一」、「第二」などは、類似している対象を区別するものであり、特定の順序又は前後手順を記述するためのものではない。理解すべきこととして、このように使用されるデータは、適切な場合に交換可能であり、それにより本出願の実施例は、ここで図示又は記述されたもの以外の順序で実施されることが可能であり、且つ「第一」、「第二」によって区別される対象は、一般的には同一種類であり、対象の個数を限定せず、例えば第一の対象は、一つであってもよく、複数であってもよい。なお、明細書及び請求項における「及び／又は」は、接続される対象のうちの少なくとも一つを表し、文字である「／」は、一般的には前後関連対象が「又は」の関係であることを表す。
指摘すべきこととして、本出願の実施例に記述された技術は、ロングタームエボリューション型（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ、ＬＴＥ）／ＬＴＥの進化（ＬＴＥ－Ａｄｖａｎｃｅｄ、ＬＴＥ－Ａ）システムに限らず、他の無線通信システム、例えば符号分割多重接続（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ、ＣＤＭＡ）、時分割多重接続（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ、ＴＤＭＡ）、周波数分割多重接続（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ、ＦＤＭＡ）、直交周波数分割多重接続（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ、ＯＦＤＭＡ）、単一キャリア周波数分割多重接続（Ｓｉｎｇｌｅ－ｃａｒｒｉｅｒ Ｆｒｅｑｕｅｎｃｙ－Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ、ＳＣ－ＦＤＭＡ）と他のシステムにも適用できる。本出願の実施例における用語である「システム」と「ネットワーク」は、常に交換可能に使用され、記述された技術は、以上に言及されたシステムとラジオ技術に用いられてもよく、他のシステムとラジオ技術に用いられてもよい。しかしながら、以下の記述は、例示の目的でニューラジオ（Ｎｅｗ Ｒａｄｉｏ、ＮＲ）システムを記述しているとともに、以下の大部分の記述においてＮＲ用語を使用しており、これらの技術は、ＮＲシステム応用以外の応用、例えば第六世代（６ｔｈ Ｇｅｎｅｒａｔｉｏｎ、６Ｇ）通信システムに適用されてもよい。
図１を参照すると、図１は、本発明の実施例が適用可能な通信システムの構造図であり、図１に示すように、端末１１、端末１２とネットワーク機器１３を含み、ここで、端末１１と端末１２との間は、サイドリンク（Ｓｉｄｅｌｉｎｋ又は側リンク、エッジリンクなどと呼ばれ、且つＳＬと略称されてもよい）を介して通信でき、ネットワーク機器１３は、エアインターフェース（Ｕｕ）によって上り下りリンク（ｕｐｌｉｎｋ ａｎｄ ｄｏｗｎｌｉｎｋ）を使用して端末１１と端末１２のうちの少なくとも一つと通信を行うことができる。
端末１１は、携帯電話、タブレットパソコン（Ｔａｂｌｅｔ Ｃｏｍｐｕｔｅｒ）、ラップトップコンピュータ（Ｌａｐｔｏｐ Ｃｏｍｐｕｔｅｒ）（又は、ノートパソコンと呼ばれる）、パーソナルデジタルアシスタント（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ、ＰＤＡ）、パームトップコンピュータ、ネットブック、ウルトラモバイルパーソナルコンピュータ（ｕｌｔｒａ－ｍｏｂｉｌｅ ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ、ＵＭＰＣ）、モバイルインターネットディバイス（Ｍｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ Ｄｅｖｉｃｅ、ＭＩＤ）又は車載機器（ＶＵＥ）、歩行者端末（ＰＵＥ）、能力の低減された機器（Ｒｅｄｕｃｅｄ Ｃａｐａｂｉｌｉｔｙ Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ＲｅｄＣａｐ ＵＥ）などの端末側機器であってもよく、ここで、ＲｅｄＣａｐ ＵＥは、ウェアラブルデバイス、工業用センサ、ビデオモニタリング機器などを含んでもよく、ウェアラブルデバイスは、ブレスレット、イヤホン、メガネなどを含む。説明すべきこととして、本出願の実施例は、端末１１の具体的なタイプを限定するものではない。
ネットワーク機器１３は、基地局又はコアネットワークであってもよく、ここで、基地局は、ノードＢ、進化ノードＢ、アクセスポイント、ベーストランシーバステーション（Ｂａｓｅ Ｔｒａｎｓｃｅｉｖｅｒ Ｓｔａｔｉｏｎ、ＢＴＳ）、ラジオ基地局、ラジオ送受信機、ベーシックサービスセット（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ、ＢＳＳ）、拡張サービスセット（Ｅｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｓｅｔ、ＥＳＳ）、Ｂノード、進化型Ｂノード（ｅＮＢ）、家庭用Ｂノード、家庭用進化型Ｂノード、ワイアレスローカルエリアネットワーク（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋｓ、ＷＬＡＮ）アクセスポイント、ワイヤレスフィデリティ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ、ＷｉＦｉ）ノード、トランスミッションポイント（Ｔｒａｎｓｍｉｔｔｉｎｇ Ｒｅｃｅｉｖｉｎｇ Ｐｏｉｎｔ、ＴＲＰ）又は当分野における他のある適切な用語と呼ばれてもよく、同じ技術的効果が達成される限り、前記基地局は、特定の技術用語に限らず、説明すべきこととして、本出願の実施例においてＮＲシステムにおける基地局のみを例にするが、基地局の具体的なタイプを限定するものではない。
以下では、図面を結び付けながら、具体的な実施例及びその応用シナリオによって本出願の実施例によるリソース処理方法、装置、端末と記憶媒体を詳細に説明する。
図２を参照すると、図２は、本出願の実施例によるリソース処理方法のフローチャートであり、図２に示すように、以下のようなステップを含む。
ステップ２０１、第一の端末は、ターゲット操作を実行し、ここで、前記ターゲット操作は、
衝突リソースを検出することと、
衝突リソースに対し、衝突処理操作を実行することと、
前記第一の端末の物理サイドリンクチャネルの相手側である第二の端末のリソースに基づいてＳＬリソース選択を行うこととのうちの少なくとも一つを含む。
上記第一の端末は、ＳＬの送信端であってもよく、またＳＬの受信端であってもよい。上記第二の端末は、ＳＬの送信端又は受信端（送信端又は受信端は、相手側と総称される）であってもよく、且つ第一の端末は、複数の第二の端末に対応してもよく、例えば、一つの第二の端末は、ＳＬの送信端であり、別の第二の端末は、ＳＬの受信端である。上記物理サイドリンクチャネルは、物理サイドリンク制御チャネル（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ、ＰＳＣＣＨ）、物理サイドリンク共有チャネル（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ、ＰＳＳＣＨ）又は物理サイドリンクフィードバックチャネル（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｆｅｅｄｂａｃｋ ｃｈａｎｎｅｌ、ＰＳＦＣＨ）であってもよい。
上記の、衝突リソースを検出することは、上記第一の端末に関連するリソースに衝突リソースが存在するかどうかを検出することであってもよい。例えば、第一の端末のＳＬ送信に用いられるリソース、第一の端末のＳＬ受信に用いられるリソースと上りリンク（ｕｐｌｉｎｋ、ＵＬ）リソースなどのうちの少なくとも一つに衝突リソースが含まれるかどうかを検出する。
本出願の実施例では、上記衝突リソースは、
ＳＬリソース間の衝突と、
ＳＬリソースと非ＳＬリソースとの間の衝突とのうちの少なくとも一つを含む。
上記ＳＬリソースは、ＳＬ伝送に用いられるリソースを指し、例えば、ＰＳＣＣＨリソース、ＰＳＳＣＨリソース、ＰＳＦＣＨリソースである。
上記ＳＬリソース間の衝突は、複数のＳＬリソースに一部又は全部の重なりが存在することであってもよい。
上記非ＳＬリソースは、第一の端末とネットワーク機器が通信を行うリソースであってもよく、例えば、上りリンク送信リソース（ＵＬ ＴＸリソース）又は下りリンク受信リソース（ＤＬ ＲＸリソース）である。又は上記非ＳＬリソースは、ＷＩＦＩリソース、ブルートゥース（登録商標）リソース、ジグビー（ｚｉｇｂｅｅ、低速短距離伝送の無線ネットワークプロトコル）リソースなどであってもよい。
上記ＳＬリソースと非ＳＬリソースとの間の衝突は、ＳＬリソースと非ＳＬリソースに一部又は全部の重なりが存在することであってもよい。
説明すべきこととして、本出願の実施例では、衝突リソースは、少なくとも二つのリソースにリソース重なり又は潜在的なリソース重なりが存在することを指してもよい。ここで、潜在的なリソース重なりは、少なくとも二つのリソースについて、ある時刻にリソース重なりが検出されたが、別のいくつかの時刻における検出によりリソース重なりが存在しない可能性があることを指し、例えば、いくつかの端末は、リソースを再選択したため、再選択する前にリソース重なりが存在するが、再選択した後にリソース重なりが存在しなくなる可能性がある。また、リソース重なり又は潜在的なリソース重なりは、リソースが時間上で一部又は全部重なることを指してもよく、例えば、同じスロット／サブスロット／符号／サブフレームが存在し、リソース重なりは、周波数領域リソース重なり又は時間周波数リソース重なりであってもよい。
また、本出願の実施例では、衝突リソースは、ぶつかり衝突リソースと呼ばれてもよい。
上記の、衝突リソースに対し、衝突処理操作を実行することは、衝突リソースを検出し、又は衝突リソースを通知するシグナリングを受信した場合に、衝突リソースに対して衝突処理操作を実行することであってもよく、例えば、衝突リソースを廃棄し、衝突リソースに対応する伝送を廃棄し又はリソース再選択を実行するなどである。
説明すべきこととして、本出願の実施例では、上記衝突リソースは、検出によって決定されてもよく、第二の端末のシグナリングにより通知されてもよい。さらに、第一の端末は、衝突リソースを検出した後に、第二の端末にこの衝突リソースを通知してもよい。
上記の、第二の端末のリソースに基づいてＳＬリソース選択を行うことは、第二の端末のリソースと重ならないＳＬリソースを選択し、又は第二の端末のリソースに対応するフィードバックリソースと重ならないＳＬリソースを選択することであってもよい。
本出願の実施例では、上記ステップによって衝突リソースを検出することと、衝突リソースに対し、衝突処理操作を実行することと、第二の端末のリソースに基づいてＳＬリソース選択を行うこととのうちの少なくとも一つを実現することができ、このように端末のＳＬの能力を向上させることができる。例えば、衝突リソースを検出することによって第一の端末に関連する衝突リソースを決定することができ、それによって第一の端末のリソース検出効果を向上させ、第二の端末のリソースに基づいてＳＬリソース選択を行うため、このようにリソース衝突を低減させ又は回避することで、ＳＬの伝送信頼性を向上させることができ、衝突リソースに対して衝突処理操作を実行するため、それによってＳＬの伝送信頼性を向上させることができ、さらに伝送衝突の発生を低減させ又は回避し、リソース利用率を向上させることができる。
一つの選択的な実施の形態として、前記の、衝突リソースを検出することは、
前記第一の端末がリソース情報に基づいて、衝突リソースを検出することを含み、
ここで、前記リソース情報は、
前記第一の端末のリソースと、少なくとも一つの第二の端末のリソースとのうちの少なくとも一つを表すために用いられる。
ここで、上記第一の端末のリソースは、第一の端末により選択されたリソース又は第一の端末により予約されたリソース、又は第一の端末が占有する必要があるリソースであってもよく、例えば、第一の端末により選択された、ＳＬ送信に用いられるリソースである。上記第二の端末のリソースは、第二の端末により選択されたリソース又は第二の端末により予約されたリソース、又は第二の端末が占有する必要があるリソースであってもよく、例えば、第二の端末により選択された、ＳＬ送信に用いられるリソースである。
ここで、少なくとも一つの第二の端末のリソースは、第二の端末によりシグナリングによって通知されたリソースであってもよく、例えば、第二の端末がリソースを選択した後に、ブロードキャストシグナリング又はユニキャストシグナリングによって第一の端末に第二の端末により選択されたリソースを通知する。
上記第一の端末がリソース情報に基づいて、衝突リソースを検出することは、第一の端末のリソースにおいて衝突リソースが存在するかどうかを検出し、又は第一の端末のリソースと少なくとも一つの第二の端末のリソースとの間に衝突リソースが存在するかどうかを検出することであってもよい。
この実施の形態では、リソース情報に基づいて衝突リソースが存在するかどうかを正確に検出することができる。
選択的に、前記第一の端末がリソース情報に基づいて、衝突リソースを検出することは、
前記第一の端末が前記リソース情報と少なくとも一つの前記第二の端末の識別子に基づいて、衝突リソースを検出することを含む。
上記少なくとも一つの前記第二の端末の識別子は、リソースに対応する第二の端末を識別するために用いられてもよく、このように上記リソース情報と少なくとも一つの第二の端末の識別子によって第一の端末とリソース衝突が存在する第二の端末を正確に決定することができ、それによって検出効果をさらに向上させる。
選択的に、前記少なくとも一つの第二の端末のリソースは、
前記第一の端末により受信されたＳＬ制御情報によって決定された少なくとも一つの第二の端末のリソースを含み、ここで、前記ＳＬ制御情報は、
リソース予約情報と、予約リソースに関連する端末識別子とのうちの少なくとも一つを含む。
ここで、上記リソース予約情報は、ＰＳＣＣＨ／ＰＳＳＣＨリソース予約情報であってもよく、上記予約リソースに関連する端末識別子は、予約リソースのターゲット識別子（ｄｅｓｔｉｎａｔｉｏｎ ＩＤ）又は予約リソースのソース識別子（ｓｏｕｒｃｅ ＩＤ）であってもよい。上記予約リソースは、非周期的及び／又は周期的に予約されたリソースを含んでもよい。
この実施の形態では、上記ＳＬ制御情報によって少なくとも一つの第二の端末のリソースを正確に決定することができる。
また、上記ＳＬ制御情報は、ＰＳＣＣＨとＰＳＳＣＨとのうちの少なくとも一つを復調することによって得られたＳＬ制御情報であってもよい。
例えば、上記第二の端末が第一の端末にＰＳＣＣＨ／ＰＳＳＣＨを送信する送信端である場合に、第一の端末は、第二の端末により送信されたＳＬ制御情報を復調してＰＳＣＣＨ／ＰＳＳＣＨリソース予約情報とＰＳＣＣＨ／ＰＳＳＣＨリソースに関連するターゲット識別子を取得して、ＰＳＣＣＨ／ＰＳＳＣＨリソースのＰＳＣＣＨ／ＰＳＳＣＨが第一の端末に送信されるかどうかを判断する。例えば、第一の端末は、ＳＬ制御情報（例えば、ＰＳＣＣＨ）における一番目のチャネル状態情報フィールド（１ｓｔ ｓｔａｇｅ ＳＣＩ）を復調してリソース予約情報を取得し、ＰＳＳＣＨにおける二番目のチャネル状態情報フィールド（２ｎｄ ｓｔａｇｅ ＳＣＩ）を復調してリソースに関連するターゲット識別子を取得して、リソースが第一の端末に送信されるかどうかを判断する。
説明すべきこととして、本出願の実施例では、非周期的な予約リソースは、対応する端末に関連してもよく、即ち非周期的に予約されたリソースによってこのリソース伝送のターゲット端末を判断することができ、それによってＳＬ制御情報においてターゲット識別子が運ばれなくてもよい。無論、本出願の実施例では、いくつかのシナリオにおいて周期的に予約されたリソースは、対応する端末と関係があってもよく、即ち周期的に予約されたリソースによってこのリソース伝送のターゲット端末を判断することができる。また、本出願の実施例では、ターゲット識別子によって非周期的に予約又は周期的に予約されたリソース上の情報が第一の端末に送信されるかどうかを承知することができ、無論、上位層ターゲット識別子を結び付け、連携判断を行うこともあり、これに対して本出願の実施例では限定しない。
また例えば、上記第二の端末が第一の端末により送信されたＰＳＣＣＨ／ＰＳＳＣＨを受信する受信端である場合に、第一の端末は、ＳＬ制御情報を復調してＰＳＣＣＨ／ＰＳＳＣＨリソース予約情報と前記リソースに関連するソース識別子を取得して、このＰＳＣＣＨ／ＰＳＳＣＨリソースに対応するＰＳＣＣＨ／ＰＳＳＣＨが上記第二の端末からのものであるかどうかを判断する。例えば、ＰＳＣＣＨにおける一番目のチャネル状態情報フィールド（１ｓｔ ｓｔａｇｅ ＳＣＩ）を復調してリソース予約情報を取得し、ここで、予約リソースは、非周期的及び／又は周期的に予約されたリソースを含んでもよく、且つ少なくとも非周期的に予約されたリソースについて、予約リソースが第一の端末からのものであるかどうかを判断することができ、またＰＳＳＣＨにおける二番目のチャネル状態情報フィールド（２ｎｄ ｓｔａｇｅ ＳＣＩ）を復調して予約リソースに関連するソース識別子を取得して、予約リソースが第一の端末からのものであるかどうかを判断することができる。例えば、少なくともソース識別子によって非周期的に予約されたリソース上の情報送信が第一の端末からのものであることを承知することができ、無論、上位層ソース識別子を結び付け、連携判断を行うこともあり、これに対して本出願の実施例では限定しない。
説明すべきこととして、本出願の実施例では、ＳＬ制御情報によって少なくとも一つの第二の端末のリソースを決定することを限定せず、例えば、いくつかのシナリオにおいて、さらに上位層シグナリングによって少なくとも一つの第二の端末のリソースを承知してもよい。
以下では、６つのシナリオによって本出願の実施例の衝突リソース検出に対して例を挙げて説明する。
シナリオ１
このシナリオにおいて、第一の端末は、ＵＥ１であり、ＵＥ０とＵＥ２は、第二の端末とする。このシナリオは、図３に示すとおりであり、伝送ぶつかり衝突が発生するかどうかを判断することは、
ＵＥ１が、複数の送信端（ＵＥ２、ＵＥ０）間にＰＳＣＣＨ／ＰＳＳＣＨリソース重なり／潜在的なリソース重なりが存在し（例えば、これらのＰＳＣＣＨ／ＰＳＳＣＨリソースの時間周波数リソースに一部又は全部の重なりが存在する）且つ少なくとも一つの送信端がＵＥ１に情報を送信することを検出すれば、リソース衝突が存在すると決定することを含む。
シナリオ２
このシナリオにおいて、第一の端末は、ＵＥ１であり、ＵＥ０とＵＥ２は、第二の端末とする。このシナリオは、図４に示すように、ＳＬ同時送信衝突検出を含み、例えば、ＰＳＦＣＨ ＴＸとＰＳＦＣＨ ＴＸとの衝突を含む。ＳＬ同時送信衝突が発生するかどうかを判断することは、
ＵＥ１が、複数の送信端（ＵＥ２、ＵＥ０）のＰＳＣＣＨ／ＰＳＳＣＨリソースに対応するＰＳＦＣＨリソースにリソース重なり／潜在的なリソース重なりが存在し（例えば、これらのＰＳＣＣＨ／ＰＳＳＣＨリソースの時間周波数リソースに一部又は全部の重なりが存在する）、且つ少なくとも二つの送信端がＵＥ１に情報を送信することを検出すれば、ＰＳＦＣＨ ＴＸとＰＳＦＣＨ ＴＸとのリソース衝突が存在することを含む。
シナリオ３
このシナリオは、図５に示すように、ＳＬ送受信の二重方式衝突検出を含み、例えば、ＰＳＳＣＨ ＴＸとＰＳＳＣＨ ＲＸとの衝突を含み、またＰＳＦＣＨ ＴＸとＰＳＦＣＨ ＲＸとの衝突をさらに含む。ＳＬ送受信の二重衝突が発生するかどうかを判断することは、少なくとも以下のような少なくとも一つを含む。
一、第一の端末は、ＵＥ１であり、ＵＥ０とＵＥ２は、第二の端末とする。
図５の左に示すＰＳＳＣＨ ＴＸとＰＳＳＣＨ ＲＸとの衝突について、それは、
ＵＥ１が、そのＰＳＣＣＨ／ＰＳＳＣＨリソースと、その送信端（ＵＥ２）によりＵＥ１に情報を送信するＰＳＣＣＨ／ＰＳＳＣＨリソースとに、リソース重なり／潜在的なリソース重なりが存在する（例えば、これらのＰＳＣＣＨ／ＰＳＳＣＨリソースが時間上で重なり／同一のｓｌｏｔ／ｓｕｂ－ｓｌｏｔ／ｓｙｍｂｏｌ／ｓｕｂ－ｆｒａｍｅにある）ことを検出すれば、ＰＳＳＣＨ ＴＸとＰＳＳＣＨ ＲＸとのリソース衝突が存在すると判断することを含んでもよく、
図５の右に示すＰＳＦＣＨ ＴＸとＰＳＦＣＨ ＲＸとの衝突について、それは、
ＵＥ１が、そのＰＳＣＣＨ／ＰＳＳＣＨリソースに対応するＰＳＦＣＨリソースと、その送信端（ＵＥ２）によりＵＥ１に情報を送信するＰＳＣＣＨ／ＰＳＳＣＨリソースに対応するＰＳＦＣＨリソースとに、リソース重なりが存在する（例えば、時間で重なり／同一のＰＳＦＣＨオケージョンにある）ことを検出すれば、ＰＳＦＣＨ ＴＸとＰＳＦＣＨ ＲＸとのリソース衝突が存在すると決定することを含んでもよい。
二、第一の端末は、ＵＥ２であり、ＵＥ１は、第二の端末とする。
図５の左に示すＰＳＳＣＨ ＴＸとＰＳＳＣＨ ＲＸとの衝突について、それは、
ＵＥ２が、そのＰＳＣＣＨ／ＰＳＳＣＨリソースと、このＰＳＣＣＨ／ＰＳＳＣＨリソースのＰＳＣＣＨ／ＰＳＳＣＨ受信端（ＵＥ１）のＰＳＣＣＨ／ＰＳＳＣＨリソースとに、リソース重なり／潜在的なリソース重なりが存在する（例えば、時間で重なり／同一のｓｌｏｔ／ｓｕｂ－ｓｌｏｔ／ｓｙｍｂｏｌ／ｓｕｂ－ｆｒａｍｅにある）ことを検出すれば、ＰＳＳＣＨ ＴＸとＰＳＳＣＨ ＲＸとのリソース衝突が存在すると判断することを含んでもよく、
図５の右に示すＰＳＦＣＨ ＴＸとＰＳＦＣＨ ＲＸとの衝突について、それは、
ＵＥ２が、そのＰＳＣＣＨ／ＰＳＳＣＨリソースに対応するＰＳＦＣＨリソースと、このＰＳＣＣＨ／ＰＳＳＣＨリソースのＰＳＣＣＨ／ＰＳＳＣＨ受信端（ＵＥ１）の情報を送信するＰＳＣＣＨ／ＰＳＳＣＨリソースに対応するＰＳＦＣＨリソースとに、リソース重なり／潜在的なリソース重なりが存在する（例えば、時間で重なり／同一のＰＳＦＣＨオケージョンにある）ことを検出すれば、ＰＳＦＣＨ ＴＸとＰＳＦＣＨ ＲＸとのリソース衝突が存在することを含んでもよい。
シナリオ４
このシナリオにおいて、第一の端末は、ＵＥ１であり、ＵＥ０とＵＥ２は、第二の端末とする。このシナリオは、図６に示すように、ＵＬとＳＬ送受信の二重衝突、又はＵＬとＳＬ同時送信衝突検出を含み、例えば、ＵＬ ＴＸとＰＳＳＣＨ ＲＸとの衝突、ＵＬ ＴＸとＰＳＦＣＨ ＴＸとの衝突を含む。ＵＬとＳＬ送受信の二重衝突／ＵＬとＳＬ同時送信衝突が発生するかどうかを判断することは、少なくとも以下のような少なくとも一つを含む。
図６の左に示すＵＬ ＴＸとＰＳＳＣＨ ＲＸとの衝突について、それは、
ＵＥ１が、そのＵＬ ＴＸリソースと、その送信端（ＵＥ２）によりＵＥ１に情報を送信するＰＳＣＣＨ／ＰＳＳＣＨリソースとに、リソース重なり／潜在的なリソース重なりが存在する（リソースが時間上で重なり／同一のｓｌｏｔ／ｓｕｂ－ｓｌｏｔ／ｓｙｍｂｏｌ／ｓｕｂ－ｆｒａｍｅにある）ことを検出すれば、ＵＬ ＴＸとＰＳＳＣＨ ＲＸとのリソース衝突が存在することを含んでもよく、
図６の右に示すＵＬ ＴＸとＰＳＦＣＨ ＴＸとの衝突について、それは、
ＵＥ１が、そのＵＬ ＴＸリソースと、その送信端（ＵＥ２）によりＵＥ１に情報を送信するＰＳＣＣＨ／ＰＳＳＣＨリソースに対応するＰＳＦＣＨリソースとに、リソース重なり／潜在的なリソース重なりが存在する（リソースが時間上で重なり／同一のｓｌｏｔ／ｓｕｂ－ｓｌｏｔ／ｓｙｍｂｏｌ／ｓｕｂ－ｆｒａｍｅにある）ことを検出すれば、ＵＬ ＴＸとＰＳＦＣＨ ＴＸとのリソース衝突が存在することを含んでもよい。
シナリオ５
このシナリオにおいて、第一の端末は、ＵＥ１であり、ＵＥ０とＵＥ２は、第二の端末とする。このシナリオは、図７に示すように、ＵＬとＳＬ送受信の二重衝突、又はＵＬとＳＬ同時送信衝突を含み、例えば、ＵＬ ＴＸとＰＳＳＣＨ ＴＸとの衝突、ＵＬ ＴＸとＰＳＦＣＨ ＲＸとの衝突を含む。ＵＬとＳＬ送受信の二重衝突／ＵＬとＳＬ同時送信衝突が発生するかどうかを判断することは、少なくとも以下のような少なくとも一つを含む。
図７の左に示すＵＬ ＴＸとＰＳＳＣＨ ＴＸとの衝突について、それは、ＵＥ１が、ＵＬ ＴＸリソースと、ＵＥ１の情報を送信するＰＳＣＣＨ／ＰＳＳＣＨリソースとに、リソース重なり／潜在的なリソース重なりが存在することを検出すれば、ＵＬ ＴＸとＰＳＳＣＨ ＴＸとの衝突が存在すると決定することであってもよく、
図７の右に示すＵＬ ＴＸとＰＳＦＣＨ ＲＸとの衝突について、それは、
ＵＥ１が、そのＵＬ ＴＸリソースと、ＵＥ１の情報を送信するＰＳＣＣＨ／ＰＳＳＣＨリソースに対応するＰＳＦＣＨリソースとに、リソース重なり／潜在的なリソース重なりが存在する（リソースが時間上で重なり／同一のｓｌｏｔ／ｓｕｂ－ｓｌｏｔ／ｓｙｍｂｏｌ／ｓｕｂ－ｆｒａｍｅにある）ことを検出すれば、ＵＬ ＴＸとＰＳＦＣＨ ＲＸとのリソース衝突が存在すると決定することを含んでもよい。
シナリオ６
このシナリオにおいて、第一の端末は、ＵＥ１であり、ＵＥ０とＵＥ２は、第二の端末とする。伝送衝突が発生するかどうかを判断することは、
ＵＥ１が、複数の送信端（ＵＥ２、ＵＥ０）間にＰＳＣＣＨ／ＰＳＳＣＨリソース重なり／潜在的なリソース重なりが存在し（例えば、これらのＰＳＣＣＨ／ＰＳＳＣＨリソースの時間周波数リソースに一部又は全部の重なりが存在する）且つ少なくとも一つの送信端が前記複数の送信端のうちの別の送信端に情報を送信することを検出すれば、リソース衝突が存在すると決定することを含む。
説明すべきこととして、上記６つのシナリオにおいてＵＬ ＴＸは、ＬＴＥ ＳＬ ＴＸ／ＲＸ、又はいずれか他の技術の伝送（例えば、ＷＩＦＩ、ブルートゥース（登録商標）、ｚｉｇｂｅｅ…）に置き換えられてもよい。また、上記６つのシナリオは、本出願の実施例による衝突リソースに対して例を挙げて説明するためのものに過ぎず、本出願の実施例における衝突リソースは、上記６つのシナリオにおける衝突リソースに限定されるものではない。
一つの選択的な実施の形態として、前記の、衝突リソースに対し、衝突処理操作を実行することは、
前記衝突リソースを検出し、且つ伝送衝突が存在する場合に、前記衝突リソースに対し、衝突処理操作を実行することを含む。
ここで、上記伝送衝突は、上記衝突リソースの真実性を確認することを指してもよく、なぜかというと、実際の応用において、いくつかのリソース衝突が発生する可能性があるが、これらのリソースに伝送衝突が存在しない可能性があるからである。例えば、いくつかのリソースが衝突するが、これらのリソースに対応する伝送ブロック（Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ、ＴＢ）は、すでに伝送に成功した可能性があり、例えば、複数回の伝送のうちの初めての伝送に成功し、又はいくつかのリソース上で端末は、ハイブリッド自動再送要求（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅｑｕｅｓｔ、ＨＡＲＱ）フィードバックを行う必要がない可能性がある。
選択的に、
前記第一の端末が前記衝突リソース上でＴＢを受信する必要があることと、
前記第一の端末が前記衝突リソース上でＴＢを送信する必要があることと、
前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを受信する必要があることと、
前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを送信する必要があることと、のうちの少なくとも一つの場合に、前記伝送衝突が存在すると決定し、
ここで、前記ＴＢは、前記衝突リソースに対応するＴＢであり、前記ＨＡＲＱフィードバックは、前記衝突リソースに対応するＨＡＲＱフィードバックである。
上記衝突リソースに対応するＴＢは、以下のようになってもよく、即ち、上記衝突リソースがＰＳＣＣＨ／ＰＳＳＣＨリソースである場合に、このＴＢがＰＳＣＣＨ／ＰＳＳＣＨリソース上で伝送する必要のあるＴＢであり、又は、上記衝突リソースがＰＳＦＣＨリソースである場合に、上記ＴＢがＰＳＦＣＨリソース衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨ上で伝送されるＴＢである。
上記衝突リソースに対応するＨＡＲＱフィードバックは、この衝突リソース上で行う必要があるＨＡＲＱフィードバックであってもよい。
上記の、ＴＢを受信することは、第二の端末により送信されたＴＢを受信することであり、上記の、ＴＢを送信することは、第二の端末にＴＢを送信することであり、上記の、ＨＡＲＱフィードバックを受信することは、第二の端末により送信されたＨＡＲＱフィードバックを受信することであり、上記の、ＨＡＲＱフィードバックを送信することは、第二の端末にＨＡＲＱフィードバックを送信することである。
上記第一の端末が前記衝突リソース上でＴＢを受信する必要があることは、以下のとおりであってもよく、即ち、上記第一の端末が上記衝突リソースの前に上記ＴＢの復調に成功できないと決定するため、第一の端末が衝突リソース上で受信を行い続ける必要があり、そうすると衝突が実際に存在し、即ち上記伝送衝突が存在する。又は、上記第一の端末が前記衝突リソース上でＴＢを受信する必要があることは、以下のとおりであってもよく、即ち、第一の端末が上記衝突リソースの前にこのＴＢの復調に成功するかどうかを決定することができず（例えば、使用すべきＴＢ伝送リソースが依然としてある）、第一の端末が衝突リソース上で受信を行い続ける必要がある可能性があり、具体的に衝突リソース上で受信を行い続ける必要があるかどうかは、プロトコル約定／配置／予め配置／第一の端末自己判断により決められる。つまり、第一の端末が上記衝突リソースの前にこのＴＢの復調に成功するかどうかを決定することができない場合に、上記伝送衝突が存在するかどうかは、プロトコル約定／配置／予め配置／第一の端末自己判断により決められる。
上記第一の端末が前記衝突リソース上でＴＢを送信する必要があることは、以下のとおりであってもよく、即ち、第一の端末が衝突リソースの前に上記ＴＢの送信に成功できず、第一の端末が衝突リソースで送信を行い続ける必要があり、伝送衝突が存在することを引き起こし、例えば、ＰＳＳＣＨ送信（ＰＳＳＣＨ ＴＸ）とＰＳＳＣＨ受信（ＰＳＳＣＨ ＲＸ）との二重衝突、又はＰＳＦＣＨ送信（ＰＳＦＣＨ ＴＸｓ）とＰＳＦＣＨ受信（ＰＳＦＣＨ ＲＸ）との二重衝突が実際に存在する。
又は、上記第一の端末が前記衝突リソース上でＴＢを送信する必要があることは、以下のとおりであってもよく、即ち、第一の端末が衝突リソースの前に上記ＴＢの送信に成功するかどうかを決定することができず（使用すべきＴＢ伝送リソースが依然としてある）、第一の端末がプロトコル約定／配置／予め配置／自己判断に基づいて衝突リソースで送信を行い続けることを決定し、それにより伝送衝突が存在するようになる。つまり、第一の端末が衝突リソースの前に上記ＴＢの送信に成功するかどうかを決定することができない場合に、上記伝送衝突が存在するかどうかは、プロトコル約定／配置／予め配置／第一の端末自己判断により決められる。
また、第一の端末は、ＨＡＲＱフィードバック状態によって上記ＴＢの送信に成功したかどうかを判断してもよく、例えば、ユニキャスト又はグループキャスト（ｕｎｉｃａｓｔ／ｇｒｏｕｐｃａｓｔ）についてＡＣＫを受信すれば、ＴＢの送信に成功したと決定し、グループキャストについて、いくつかのシナリオでは、ＮＡＣＫを受信していなければＴＢの送信に成功したと決定することができる。
上記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを受信又は送信する必要があることは、以下のとおりであってもよく、即ち、ＰＳＦＣＨ送受信の二重衝突について、第一の端末は、この衝突したＰＳＳＣＨリソース上のＴＢ伝送がＨＡＲＱフィードバックをイネーブルしたかどうか、又はこのＴＢがＨＡＲＱ－ＡＣＫ／ＮＡＣＫをフィードバックする必要があるかどうかを判断する。イネーブルし又はこのＴＢがＨＡＲＱ－ＡＣＫ／ＮＡＣＫをフィードバックする必要があれば、端末が送信端とされる場合に、ＨＡＲＱフィードバックを受信する必要があり、端末が受信端とされる場合に、ＨＡＲＱフィードバックを送信する必要がある。
選択的に、
前記第一の端末が前記衝突リソースの前にすでにＴＢの復調に成功したことと、
前記第一の端末が前記衝突リソースの前にＴＢの送信に成功できることと、
前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを受信する必要がないことと、
前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを送信する必要がないことと、のうちの一つの場合に、前記伝送衝突が存在しないと決定し、
ここで、前記ＴＢは、前記衝突リソースに対応するＴＢであり、前記ＨＡＲＱフィードバックは、前記衝突リソースに対応するＨＡＲＱフィードバックである。
この実施の形態では、第一の端末が前記衝突リソースの前にすでにＴＢの復調に成功すれば、実際に衝突が存在しないと決定し、即ち上記伝送衝突が存在しない。例えば、第一の端末がＴＢ受信を行う時に、複数回のＴＢ伝送のうちのある回のＴＢ伝送は、衝突したＰＳＣＣＨ／ＰＳＳＣＨリソース上で行われ、又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨ上で行われる。ＵＥが前記衝突リソースの前にこのＴＢの復調に成功すれば、第一の端末は、衝突リソース上で受信を行い続ける必要がなくなり、そうすると衝突は、実際に存在しない。
この実施の形態では、第一の端末が前記衝突リソースの前にＴＢの送信に成功できれば、実際に衝突が存在しないと決定し、即ち上記伝送衝突が存在しない。例えば、第一の端末がＴＢの送信を行う時に、複数回のＴＢ伝送のうちのある回のＴＢ伝送は、衝突したリソース上で行われ、又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨ上で行われる。第一の端末が衝突リソースの前にこのＴＢの送信に成功できれば、第一の端末は、衝突リソースで送信を行い続ける必要がなくなり、そうすると衝突は、実際に存在しない。
上記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを受信又は送信する必要がないことは、以下のとおりであってもよく、即ち、ＰＳＦＣＨ送受信の二重衝突について、第一の端末は、この衝突したＰＳＳＣＨリソース上のＴＢ伝送がＨＡＲＱフィードバックをイネーブルしたかどうか、又はこのＴＢがＨＡＲＱ－ＡＣＫ／ＮＡＣＫをフィードバックする必要があるかどうかを判断し、ＨＡＲＱフィードバックをイネーブルしておらず／ＨＡＲＱ－ＡＣＫ／ＮＡＣＫフィードバックを許容しなければ、そうするとこの衝突は、実際に存在せず、即ち上記伝送衝突は、存在しない。
上記実施の形態では、伝送衝突が存在し、即ち実際に衝突が存在する場合にのみ、衝突処理操作を実行してもよく、衝突リソースが存在するが上記伝送衝突が存在せず、即ち実際に衝突が存在しない場合に、衝突処理操作を実行せずに、端末の消費電力を節約する。
一つの選択的な実施の形態として、前記ターゲット操作は、
前記衝突リソースの前の前記衝突リソースに対応するＴＢの最後の伝送が伝送に成功したかどうかを検出することをさらに含む。
上記衝突リソースに対応するＴＢは、以下のようなものであってもよく、即ち、上記衝突リソースがＰＳＣＣＨ／ＰＳＳＣＨリソースである場合に、上記ＴＢがこのＰＳＣＣＨ／ＰＳＳＣＨリソース上で伝送する必要のあるＴＢであり、又は上記衝突リソースがＰＳＦＣＨリソースである場合に、上記ＴＢがＰＳＦＣＨリソース衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソースで伝送されるＴＢである。
上記最後の伝送は、ＴＢ複数回伝送の場合に、上記衝突リソースの前に上記ＴＢの最後の伝送が伝送に成功したかどうかを判断することを指してもよい。例えば、ＴＢ伝送が３回であるように配置し、上記衝突リソースがＴＢの３回目の伝送であれば、上記は、ＴＢの２回目の伝送が伝送に成功したかどうかを判断する。
この実施の形態では、上記最後の伝送が伝送に成功したかどうかを検出するため、このように端末の衝突リソースに対する検出により有利であり、それによって端末の検出効果をさらに向上させ、例えば、上記最後の伝送に成功した時に、上記衝突リソースに伝送衝突が存在しないと直接に認められてもよい。
一つの選択的な実施の形態として、前記の、衝突リソースに対し、衝突処理操作を実行することは、
以下のような少なくとも一つを満たす場合に、前記衝突リソースに対し、衝突処理操作を実行することを含み、即ち、
前記衝突リソースに対応する伝送タイプがターゲット伝送タイプであり、
前記衝突リソースに対応する伝送情報のサービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ、ＱｏＳ）がターゲットＱｏＳであり、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在せず、
前記第一の端末が前記衝突リソース上で複数の物理サイドリンクフィードバックチャネルＰＳＦＣＨを送信することができず、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在する。
上記ターゲット伝送タイプは、プロトコルにより約定され、予め配置され、ネットワークにより指示された特定の伝送タイプであってもよく、例えば、上記ターゲット伝送タイプは、
ユニキャスト（ｕｎｉｃａｓｔ）と、グループキャスト（ｇｒｏｕｐｃａｓｔ）と、ブロードキャスト（ｂｒｏａｄｃａｓｔ）と、グループキャストタイプ１（ｇｒｏｕｐｃａｓｔ ｏｐｔｉｏｎ １）と、グループキャストモード２（ｇｒｏｕｐｃａｓｔ ｏｐｔｉｏｎ ２）とのうちの少なくとも一つを含む。
ここで、上記グループキャストタイプ１（ｇｒｏｕｐｃａｓｔ ｏｐｔｉｏｎ １）、グループキャストモード２（ｇｒｏｕｐｃａｓｔ ｏｐｔｉｏｎ ２）は、プロトコルにおいて定義されたグループキャストタイプ１（ｇｒｏｕｐｃａｓｔ ｏｐｔｉｏｎ １）、グループキャストモード２（ｇｒｏｕｐｃａｓｔ ｏｐｔｉｏｎ ２）であってもよい。
上記衝突リソースに対応する伝送タイプは、衝突したＰＳＣＣＨ／ＰＳＳＣＨリソースにおける伝送タイプ、又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソース上の伝送タイプであってもよく、ここで、ここでのＰＳＦＣＨ衝突は、ＰＳＦＣＨリソース間の衝突、又はＰＳＦＣＨリソースと他のリソース（例えば、ＰＳＳＣＨ／ＰＳＣＣＨ／ＵＬリソース）との間の衝突であってもよい。
上記衝突リソースに対応する伝送情報は、衝突したＰＳＣＣＨ／ＰＳＳＣＨリソースにおける伝送情報、又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソース上の伝送情報であってもよい。
例えば、第一の端末は、衝突したＰＳＣＣＨ／ＰＳＳＣＨリソース上（又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソース上）の伝送タイプを判断し、第一の端末／第二の端末がＰＳＣＣＨ／ＰＳＳＣＨリソース上で伝送する伝送タイプがターゲット伝送タイプであることを検出した場合にのみ、衝突処理操作を実行する。
上記ターゲットＱｏＳは、プロトコルにより定義され、予め配置され又はネットワークにより指示されてもよい。また、本出願の実施例では、ＱｏＳは、優先度又は他のサービス品質情報であってもよい。以下では、ＱｏＳが優先度であることに対して例を挙げて説明する。
第一の端末は、第二の端末の衝突したＰＳＣＣＨ／ＰＳＳＣＨリソース（又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソース）上での伝送優先度が予め定義／配置／予め配置された閾値超え／以上（又は未満／以下）であることを検出した場合にのみ、衝突処理操作を実行し、又は
第一の端末は、第一の端末の衝突したＰＳＣＣＨ／ＰＳＳＣＨリソース（又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソース）上での伝送優先度が予め定義／配置／予め配置された閾値超え／以上（又は未満／以下）であることを検出した場合にのみ、衝突処理操作を実行する。
上記の、前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在しないことは、衝突したＰＳＣＣＨ／ＰＳＳＣＨリソースの後（又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソースの後）にこのＴＢの伝送リソースが依然として存在するかどうかを検出し、存在しなければ、衝突処理操作を実行することであってもよい。
又は、上記の、前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在しないことは、第一の端末が、第二の端末が複数の伝送リソースを採用してＴＢ伝送を行うことを検出し、第一の端末が、上記衝突リソースの後にＴＢの再送リソースが依然として存在することを検出すれば、衝突処理操作を実行せず、第一の端末が、上記衝突リソースの後にＴＢの再送リソースが存在しないことを検出すれば、衝突処理操作を実行することであってもよい。
又は、上記の、前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在しないことは、第一の端末が複数の伝送リソースを採用してＴＢ伝送を行い、上記衝突リソースの後にＴＢの再送リソースが依然として存在すれば、衝突処理操作を実行せず、上記衝突リソースの後にＴＢの再送リソースが存在すれば、衝突処理操作を実行することであってもよい。
上記第一の端末が前記衝突リソース上で複数の物理サイドリンクフィードバックチャネルＰＳＦＣＨを送信することができないことは、ＰＳＦＣＨ同時送信衝突について、第一の端末が衝突した複数のＰＳＦＣＨを同時に送信することができるかどうかを判断し、できなければ、衝突処理操作を実行し、できれば、衝突処理操作を実行しないことであってもよい。
上記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在することは、ＰＳＦＣＨ同時送信衝突について、第一の端末があるＰＳＦＣＨを送信するパワーが閾値未満（又は以下）であれば、衝突処理操作を実行することであってもよい。
上記実施の形態では、上記少なくとも一つを満たす場合にのみ、衝突処理操作を実行するようにすることを実現でき、それによって端末の消費電力を節約し、端末の伝送信頼性を向上させる。上記少なくとも一つが満たされない時に、衝突処理操作を実行しない。さらに、上記実施の形態は、また上記伝送衝突の実施の形態と結び付けて実現されてもよく、例えば、上記伝送衝突が存在し、且つ上記少なくとも一つを満たす場合に、前記衝突リソースに対し、衝突処理操作を実行し、そうでなければ、衝突処理操作を実行しない。
一つの選択的な実施の形態として、前記の、衝突リソースに対し、衝突処理操作を実行することは、
前記衝突リソースが前記第一の端末のＳＬリソースとして指示されたのが初めてである場合に、第一の条件で衝突リソースに対して衝突処理操作を実行すること、又は
前記衝突リソースが前記第一の端末のＳＬリソースとして指示されたのが初めてではない場合に、第二の条件で衝突リソースに対して衝突処理操作を実行することを含み、
ここで、前記第一の条件は、
前記衝突リソースに対応する伝送タイプがターゲット伝送タイプであることと、
前記衝突リソースに対応する伝送情報のサービス品質ＱｏＳがターゲットＱｏＳであることと、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在しないことと、
前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができず、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在することとのうちの少なくとも一つを含み、
前記第二の条件は、
前記衝突リソースに対応する伝送タイプがターゲット伝送タイプであることと、
前記衝突リソースに対応する伝送情報のサービス品質ＱｏＳがターゲットＱｏＳであることと、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在しないことと、
前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができず、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在することとのうちの少なくとも一つをそれぞれ含み、
ここで、前記第一の条件と前記第二の条件は、含まれる内容が異なる。
上記衝突リソースが前記第一の端末のＳＬリソースとして指示されたのが初めてであることは、
衝突リソースを検出し又は衝突処理操作を実行する前に、上記衝突リソースが非周期的予約シグナリングにより指示されたことがなく、周期的予約シグナリングにより指示されたこともないことと、
上記衝突リソースが非周期的なリソース又は周期的なリソースの一番目の周期内のリソースであることと、
衝突リソースを検出し又は衝突処理操作を実行する前に、上記衝突リソースが非周期的予約シグナリングにより指示されたことがないが、周期的な予約シグナリングにより指示されたことがあることと、
衝突リソースを検出し又は衝突処理操作を実行する前に、上記衝突リソースが非周期的予約シグナリングにより指示されたことがないが、前の周期の周期的な予約シグナリングにより指示されたことがあることとのうちのいずれか一つであってもよい。
上記第一の条件と第二の条件は、以上の実施の形態の関連記述を参照してもよく、この実施の形態では第一の条件と前記第二の条件に含まれる内容が異なるため、このように衝突リソースが初めての指示であるかどうかに基づいて異なる処理操作を採用することを実現でき、それによって端末の衝突処理能力をさらに向上させる。例えば、初めての指示である場合にＱｏＳを判断しなくてもよく、初めての指示ではない場合にＱｏＳを判断する必要がある。
一つの選択的な実施の形態として、前記の、衝突リソースに対し、衝突処理操作を実行することは、
ターゲット時刻の検出結果に基づいて、前記衝突リソースに対して衝突処理操作を実行することを含み、ここで、前記ターゲット時刻の検出結果は、
前記衝突リソースと、
伝送衝突が存在するかどうかと、
前記衝突リソースの伝送タイプと、
前記衝突リソースの伝送情報の優先度と、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在するかどうかと、
前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができるかどうか、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在するかどうかとのうちの少なくとも一つを表すために用いられる。
ここで、上記ターゲット時刻は、プロトコルにより定義され、予め配置され又はネットワークにより指示された一つ又は複数の時刻であってもよい。
上記ターゲット時刻の検出結果が上記少なくとも一つを表すために用いられることは、上記ターゲット時刻に、
衝突リソースを検出することと、
伝送衝突が存在するかどうかを検出することと、
前記衝突リソースの伝送タイプを検出することと、
前記衝突リソースの伝送情報の優先度を検出することと、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在するかどうかを検出することと、
前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができるかどうか、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在するかどうかを検出することとのうちの少なくとも一つを実行することができると理解されてもよい。
選択的に、上記前記ターゲット時刻は、
前記第一の端末のＳＬリソースに対してリソース指示を行う前のＴ１時刻と、
前記第一の端末のＳＬリソースに対してリソース指示を行う前のＴ１時刻の前の時刻と、
前記第一の端末のＳＬリソースに対して予約を行う前のＴ１時刻と、
前記第一の端末のＳＬリソースに対して予約を行う前のＴ１時刻の前の時刻と、
前記第一の端末のＳＬリソースの前のＴ２時刻と、
前記第一の端末のＳＬリソースの前のＴ２時刻の前の時刻と、
前記第二の端末のＳＬリソースの前のＴ３時刻と、
前記第二の端末のＳＬリソースの前のＴ３時刻の前の時刻と、
前記第二の端末のＳＬリソースの予約指示シグナリングが送信された後のＴ３時刻と、
前記第二の端末のＳＬリソースの予約指示シグナリングが送信されてから、且つ前記第二の端末のＳＬリソースの予約指示シグナリングが送信された後のＴ３時刻までの時刻と、
前記第二の端末のＳＬリソースの関連する衝突指示シグナリングが送信される前のＴ４時刻と、
前記第二の端末のＳＬリソースの関連する衝突指示シグナリングが送信される前のＴ４時刻の前の時刻とのうちの少なくとも一つを含み、
ここで、前記第二の端末のＳＬリソースは、前記第二の端末が前記第一の端末にＳＬ伝送を行うリソースであり、前記Ｔ１、Ｔ２、Ｔ３とＴ４は、同じ又は異なる時間リソースをそれぞれ表す。
説明すべきこととして、上記Ｔ１、Ｔ２、Ｔ３とＴ４は、プロトコルにより定義され、予め配置され又はネットワークにより指示された時間リソースであってもよく、例えば、Ｔ１、Ｔ２、Ｔ３とＴ４は、数が同じ又は異なるスロット／サブスロット／符号／サブフレームなどをそれぞれ表す。また、これらのＴ１、Ｔ２、Ｔ３とＴ４は、端末の処理時間を含んでもよく、例えば、Ｔ１、Ｔ２、Ｔ３とＴ４は、端末の処理時間よりも大きい時間領域リソースであってもよい。
選択的に、前記の、前記第一の端末のＳＬリソースに対してリソース指示を行うことは、
前記第一の端末のＳＬリソースに対してｉ回目のリソース指示を行うことを含み、ｉは、１以上の整数である。
ここで、上記ｉが１に等しいことは、上記第一の端末のＳＬリソースに対して初めての指示を行うことを表す。例えば、
上記検出を実行する前に、第一の端末のＳＬリソースは、非周期的予約シグナリングにより指示されたことがなく、周期的予約シグナリングにより指示されたこともなく、又は
第一の端末のＳＬリソースは、非周期的なリソースであり、又は周期的なリソースの一番目の周期内のリソースであり、又は
上記検出を実行する前に、第一の端末のＳＬリソースは、非周期的予約シグナリングにより指示されたことがないが、周期的な予約シグナリングにより指示されたことがあり、又は
上記検出を実行する前に、第一の端末のＳＬリソースは、非周期的予約シグナリングにより指示されたことがないが、前の周期の周期的な予約シグナリングにより指示されたことがある。
上記第一の端末のＳＬリソースは、第一の端末が情報を送信するＰＳＣＣＨ／ＰＳＳＣＨリソースを含んでもよい。上記第二の端末のＳＬリソースは、第二の端末が第一の端末に情報を送信するＰＳＣＣＨ／ＰＳＳＣＨリソースを含んでもよい。
一つの選択的な実施の形態として、前記の、衝突リソースを検出することは、
ターゲット時刻に衝突リソースを検出すること、又は
前記ターゲット時刻を含む複数の時刻に衝突リソースを検出することを含む。
ここで、上記ターゲット時刻は、上記説明を参照し、ここで詳細な説明を省略する。
この実施の形態では、端末が少なくとも上記ターゲット時刻に衝突リソースを検出することを実現することができ、他の時刻に検出するかどうかは、第一の端末により決められ、又はプロトコルにより約定され又はネットワークにより配置されてもよい。例えば、第一の端末は、常に衝突検出を行ってもよく、又は第一の端末は、端末に基づいていつ衝突検出を行うかを決めることを実現し、又は第一の端末は、プロトコルにより規定され／制御ノードにより配置され／予め配置された時間に衝突検出を行い、及び／又は他の時間に衝突検出を実行する。
一つの選択的な実施の形態として、前記衝突処理操作は、
リソースを再選択することと、
前記衝突リソースを廃棄することと、
ＨＡＲＱ情報をフィードバックすることと、
前記第一の端末の物理サイドリンクチャネルの相手側である第二の端末に通知することとのうちの少なくとも一つを含む。
上記の、リソースを再選択することは、上記衝突リソースが属するリソースプールにおいて再選択を行ってもよく、他のリソースプールにおいて再選択を行ってもよい。上記の、前記衝突リソースを廃棄することは、前記衝突リソースを廃棄し、他のリソースを選択してもよく、又は前記衝突リソース上のＴＢを廃棄してもよい。上記の、ＨＡＲＱ情報をフィードバックすることは、端末の実際の状況に応じて適切なフィードバックを行ってもよく、例えば、ユニキャストに対し、ＮＡＣＫをフィードバックし、又は情報をフィードバックせず、グループキャストモード１（ｇｒｏｕｐｃａｓｔ ｏｐｔｉｏｎ １）に対し、ＮＡＣＫをフィードバックし、グループキャストモード２（ｇｒｏｕｐｃａｓｔ ｏｐｔｉｏｎ ２）に対し、ＮＡＣＫをフィードバックし、又は情報をフィードバックしない。
上記の、第二の端末に通知することは、上記衝突リソースを第二の端末に通知することであってもよく、第二の端末がこの通知を受信した後に、リソースを再選択することと、前記衝突リソースを廃棄することと、ＨＡＲＱ情報をフィードバックすることなどのうちの少なくとも一つの衝突処理操作を実行してもよい。
この実施の形態では、上記衝突処理操作によってリソース衝突を除去して、伝送の信頼性とリソース利用率を向上させることができる。
本出願の実施例では、衝突処理操作は、衝突したＰＳＣＣＨ／ＰＳＳＣＨリソースを再選択し、又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソースを再選択することを含んでもよい。また、再選択は、衝突し又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソースのみに適用されてもよく、又は衝突し又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソースの周期的なリソースにも適用される。
また、衝突処理操作において、ＴＢが到着した後に、第二の端末がＰＤＢ内のこのＴＢ伝送を乗せられる（いずれか）他のリソースを選択して送信を行うことを許容する。
また、衝突処理操作は、第二の端末がＰＳＣＣＨ／ＰＳＳＣＨ再送を直接に行う（即ちＨＡＲＱフィードバックを無視する）ことを含んでもよい。
以下では、６つのシナリオによって本出願の実施例による衝突処理操作に対して例を挙げて説明する。
シナリオ１
このシナリオは、図３に示すとおりであり、第一の端末は、ＵＥ１であり、ＵＥ０とＵＥ２は、第二の端末であり、具体的には、以下を含んでもよい。
ＵＥ１は、衝突リソースを検出した後に、
ＵＥ１がターゲット相手側（ＵＥ０又はＵＥ２）に衝突したＰＳＣＣＨ／ＰＳＳＣＨリソースを再選択するよう通知し、又はターゲット相手側ＵＥ（ＵＥ２）に前記ＰＳＣＣＨ／ＰＳＳＣＨ送信を放棄し／他の非衝突リソースを採用して送信するよう通知するというような衝突処理操作を取り、ターゲット相手側は、該当する行為を実行してもよい。
ここで、条件を満たす相手側が複数存在する場合に、ＵＥ１は、一部の相手側にトリガーシグナリングを送信してもよい。
例えば、ＵＥ１は、ある特定の伝送タイプ（例えば、ｕｎｉｃａｓｔ）を伝送する相手側にトリガーシグナリングを送信し、
例えば、ＵＥ１は、伝送ＱｏＳ要求が高い／低い（優先度がある閾値超え／以上／未満／以下である）相手側にトリガーシグナリングを送信し、
例えば、ＵＥ１は、直近に予約シグナリングを送信して前記衝突リソースを予約する一つ／複数の相手側ＵＥにトリガーシグナリングを送信し、
例えば、ＵＥ１は、衝突が比較的多いＵＥにトリガーシグナリングを送信する。ＵＥ０の現在のＴＢ伝送がＵＥ２の伝送と衝突するが、ＵＥ２のＴＢ伝送がＵＥ０、３、４、５の伝送といずれも衝突し、ＵＥ２にトリガーシグナリングを送信してもよく、それによって再選択通知回数を減らし、
例えば、ＵＥ１は、ＴＢ伝送に対応する遅延（ＰＤＢ）が比較的長いＵＥにトリガーシグナリングを送信し、遅延が比較的短い送信の成功を保証する。
また、上記一部の相手側の個数、例えば、最大個数／最小個数／個数の範囲などを限定してもよい。
上記トリガーシグナリングは、該当する衝突処理操作を実行するように相手側をトリガーすることができる。
選択的に、ＵＥ１が、相手側が衝突リソースに対してまたリソース再選択（例えば、ｐｒｅ－ｅｍｐｔｉｏｎなどによりトリガーされた再選択）を行ったと判断すれば、この通知を送信する必要がなく、ここで、ＵＥ１は、明示的な指示又は非明示的な方式によって相手側が衝突リソースに対してリソース再選択を行ったかどうかを決定してもよい。
シナリオ２
このシナリオは、図４に示すように、ＳＬ同時送信衝突検出を含み、例えば、ＰＳＦＣＨ ＴＸとＰＳＦＣＨ ＴＸとの衝突を含む。第一の端末は、ＵＥ１であり、ＵＥ０とＵＥ２は、第二の端末であり、具体的には、以下を含んでもよい。
ＵＥ１は、衝突リソースを検出した後に、
ＵＥ１がターゲット相手側ＵＥ（ＵＥ２）にＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソースを再選択するよう通知し、又はターゲット相手側ＵＥ（ＵＥ２）にＰＳＣＣＨ／ＰＳＳＣＨ送信を放棄し／他の非衝突リソースを採用して送信するよう通知するというような処理操作を取り、ターゲット相手側ＵＥは、該当する行為を実行してもよい。
条件を満たす相手側が複数存在する場合に、以下のとおりであってもよい。
ＵＥ１は、一部の相手側ＵＥにトリガーシグナリングを送信する。例えば、ある特定の伝送タイプを伝送する相手側にトリガーシグナリングを送信し、伝送ＱｏＳ要求が高い／低い（優先度がある閾値超え／以上／未満／以下である）ＵＥにトリガーシグナリングを送信する。
前記一部の相手側の個数、例えば、最大個数／最小個数／個数の範囲などを限定してもよい。
シナリオ３
このシナリオは、図５に示すように、送受信の二重方式衝突検出を含み、例えば、ＰＳＳＣＨ ＴＸとＰＳＳＣＨ ＲＸとの衝突、ＰＳＦＣＨ ＴＸとＰＳＦＣＨ ＲＸとの衝突を含む。ＳＬ送受信の二重衝突を検出した後に、以下のような措置のうちの少なくとも一つの処理操作を取る。
一、第一の端末は、ＵＥ１であり、ＵＥ０とＵＥ２は、第二の端末とし、ＵＥ１が衝突リソースを検出すれば、ＵＥ１は、以下のような少なくとも一つの処理操作を取る。
１－１、衝突したＰＳＣＣＨ／ＰＳＳＣＨリソース（又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソース）を再選択し、又は前記ＰＳＣＣＨ／ＰＳＳＣＨ送信を放棄し／他の非衝突リソースを採用して送信を行い、
１－２、ターゲット相手側（ＵＥ２）に衝突したＰＳＣＣＨ／ＰＳＳＣＨリソース（又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソース）を再選択するよう通知し、又はターゲット相手側ＵＥ（ＵＥ２）に前記ＰＳＣＣＨ／ＰＳＳＣＨ送信を放棄し／他の非衝突リソースを採用して送信するよう通知し、ターゲット相手側が該当する行為を実行してもよく、
１－３、衝突ＰＳＣＣＨ／ＰＳＳＣＨリソース（又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソース）の送信／受信を放棄する。例えば、プロトコルにより約定され／制御ノードにより配置され／予め配置されて送信／受信を放棄し、又は優先度に基づいて送信／受信を放棄する（例えば、優先度が低い情報を放棄する）。
ここで、ＵＥ１がＰＳＣＣＨ／ＰＳＳＣＨ送信を放棄すれば、ＵＥ１は、引き続き上記１－１の操作を実行してもよく、
ＵＥ１がＰＳＣＣＨ／ＰＳＳＣＨ受信を放棄すれば、ＵＥ１は、引き続き上記１－２の操作を実行してもよく、
ＵＥ１がＰＳＣＣＨ／ＰＳＳＣＨ受信を放棄する場合に、以下のようなルールに従ってＨＡＲＱフィードバックを行って、相手側の再送を回復させてもよく、即ち、
ユニキャスト（ｕｎｉｃａｓｔ）に対し、ＮＡＣＫをフィードバックし、又は情報をフィードバックせず、例えば、不連続発射（Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｔｒａｎｓｍｉｓｓｉｏｎ、ＤＴＸ）シナリオにおいて情報をフィードバックせず、
グループキャストモード１（ｇｒｏｕｐｃａｓｔ ｏｐｔｉｏｎ １）に対し、ＮＡＣＫをフィードバックし、
グループキャストモード２（ｇｒｏｕｐｃａｓｔ ｏｐｔｉｏｎ ２）に対し、ＮＡＣＫをフィードバックし、又は情報をフィードバックせず、例えば、ＤＴＸシナリオにおいて情報をフィードバックしない。
１－４、図５に示す右のシナリオについて、ＰＳＦＣＨ衝突に対し、ＵＥ１は、ルールに基づいて衝突したＰＳＦＣＨの送信／受信を放棄する。例えば、プロトコルにより約定され／制御ノードにより配置され／予め配置されて「送信」／「受信」を放棄し、又は優先度に基づいて「送信」／「受信」を放棄する（例えば、優先度が低い受信／送信を放棄する）。
二、第一の端末は、ＵＥ２であり、ＵＥ１は、第二の端末とし、ＵＥ１が衝突リソースを検出すれば、ＵＥ１は、以下のような少なくとも一つの処理操作を取る。
２－１、衝突したＰＳＣＣＨ／ＰＳＳＣＨリソース（又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソース）を再選択し、又は前記ＰＳＣＣＨ／ＰＳＳＣＨ送信を放棄し／他の非衝突リソースを採用して送信を行い、
２－２、ターゲット相手側（ＵＥ１）に衝突したＰＳＣＣＨ／ＰＳＳＣＨリソース（又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソース）を再選択するよう通知し、又はターゲット相手側ＵＥ（ＵＥ１）に前記ＰＳＣＣＨ／ＰＳＳＣＨ送信を放棄し／他の非衝突リソースを採用して送信するよう通知し、ターゲット相手側ＵＥが該当する行為を実行してもよい。
シナリオ４
このシナリオにおいて、第一の端末は、ＵＥ１であり、ＵＥ０とＵＥ２は、第二の端末とする。このシナリオは、図６に示すように、ＵＬ／ＳＬ送受信の二重衝突又はＵＬ／ＳＬ同時送信衝突検出を含み、例えば、ＵＬ ＴＸとＰＳＳＣＨ ＲＸとの衝突、ＵＬ ＴＸとＰＳＦＣＨ ＴＸとの衝突を含む。
ＵＥ１がＵＬ／ＳＬ送受信の二重衝突又はＵＬ／ＳＬ同時送信衝突を検出した後に、ＵＥは、以下のような少なくとも一つの処理操作を取る。
１－１、ターゲット相手側（ＵＥ２）に衝突したＰＳＣＣＨ／ＰＳＳＣＨリソース（又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソース）を再選択するよう通知し、又はターゲット相手側（ＵＥ２）に前記ＰＳＣＣＨ／ＰＳＳＣＨ送信を放棄し／他の非衝突リソースを採用して送信するよう通知し、ターゲット相手側ＵＥが該当する行為を実行してもよく、
１－２、ＵＥ１は、衝突したＵＬ送信又はＰＳＣＣＨ／ＰＳＳＣＨ受信、又は衝突したＵＬ送信又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨ受信を放棄する。例えば、プロトコルにより約定され／制御ノードにより配置され／予め配置されて送信／受信を放棄し、又は優先度に基づいて送信／受信を放棄し（例えば、優先度が低い情報を放棄する）、
ここで、ＵＥ１がＵＬ ＴＸ送信を放棄すれば、ＵＥ１は、引き続きこのシナリオにおける上記１－１を実行してもよく、
ＵＥ１がＰＳＣＣＨ／ＰＳＳＣＨ受信を放棄すれば、ＵＥ１は、引き続きこのシナリオにおける上記１－２を実行してもよく、
ＵＥ１がＰＳＣＣＨ／ＰＳＳＣＨ受信を放棄する場合に、以下のようなルールに従ってＨＡＲＱフィードバックを行って、相手側の再送を回復させ、即ち、
ユニキャスト（ｕｎｉｃａｓｔ）に対し、ＮＡＣＫをフィードバックし、又は情報をフィードバックせず、例えば、ＤＴＸシナリオにおいて情報をフィードバックせず、
グループキャストモード１（ｇｒｏｕｐｃａｓｔ ｏｐｔｉｏｎ １）に対し、ＮＡＣＫをフィードバックし、
グループキャストモード２（ｇｒｏｕｐｃａｓｔ ｏｐｔｉｏｎ ２）に対し、ＮＡＣＫをフィードバックし、又は情報をフィードバックせず、例えば、ＤＴＸシナリオにおいて情報をフィードバックしない。
１－３、図６に示す右のシナリオについて、ＰＳＦＣＨ衝突に対し、ＵＥ１は、ルールに基づいて前記のＰＳＦＣＨリソース上での送信又はＵＬ ＴＸの送信を放棄する。例えば、プロトコルにより約定され／制御ノードにより配置され／予め配置されてＰＳＦＣＨ送信／ＵＬ ＴＸを放棄し、又は優先度に基づいてＰＳＦＣＨ送信／ＵＬ ＴＸを放棄する。
シナリオ５
このシナリオにおいて、第一の端末は、ＵＥ１であり、ＵＥ０とＵＥ２は、第二の端末とする。このシナリオは、図７に示すように、ＵＬとＳＬ送受信の二重衝突、又はＵＬとＳＬ同時送信衝突を含み、例えば、ＵＬ ＴＸとＰＳＳＣＨ ＴＸとの衝突、ＵＬ ＴＸとＰＳＦＣＨ ＲＸとの衝突を含む。
ＵＥ１がＵＬ／ＳＬ送受信の二重衝突又はＵＬ／ＳＬ同時送信衝突を検出した後に、ＵＥは、以下のような少なくとも一つの処理操作を取る。
１－１、図７に示す左のシナリオに対し、衝突したＰＳＣＣＨ／ＰＳＳＣＨリソース（又はＰＳＦＣＨ衝突をもたらすＰＳＣＣＨ／ＰＳＳＣＨリソース）を再選択し、又は前記ＰＳＣＣＨ／ＰＳＳＣＨ送信を放棄し／他の非衝突リソースを採用して送信を行い、
１－２、図７に示す右のシナリオに対し、ＰＳＦＣＨ衝突に対し、ルールに基づいてＵＬ ＴＸ又はＰＳＦＣＨ受信を放棄する。例えば、プロトコルにより約定され／制御ノードにより配置され／予め配置されて送信／受信を放棄し、又は優先度に基づいて送信／受信を放棄し、
ＵＥ１がＵＬ ＴＸを放棄すれば、ＵＥ１は、引き続き本シナリオにおける上記１－１を実行してもよく、
ＵＥ１がＰＳＦＣＨ受信を放棄すれば、ＵＥ１は、引き続き本シナリオにおける上記１－１を実行してもよい。
シナリオ６
このシナリオにおいて、第一の端末は、ＵＥ１であり、ＵＥ０とＵＥ２は、第二の端末とする。伝送衝突は、
ＵＥ１が複数の送信端（ＵＥ２、ＵＥ０）間にＰＳＣＣＨ／ＰＳＳＣＨリソース重なり／潜在的なリソース重なりが存在し（例えば、これらのＰＳＣＣＨ／ＰＳＳＣＨリソースの時間周波数リソースに一部又は全部の重なりが存在する）且つ少なくとも一つの送信端が前記複数の送信端のうちの別の送信端に情報を送信することを検出すれば、リソース衝突が存在すると決定することを含む。
上記伝送衝突に対してこのシナリオでは、上記シナリオ１からシナリオ５のうちのいずれか一つの衝突処理操作を実行してもよい。
説明すべきこととして、上記６つのシナリオにおいてＵＬ ＴＸは、ＬＴＥ ＳＬ ＴＸ／ＲＸ、又はいずれか他の技術の伝送（例えば、ＷＩＦＩ、ブルートゥース（登録商標）、ｚｉｇｂｅｅ…）に置き換えられてもよい。また、上記６つのシナリオは、本出願の実施例による衝突処理操作に対して例を挙げて説明するためのものに過ぎず、本出願の実施例における衝突処理操作は、上記６つのシナリオにおける衝突処理操作に限定されるものではない。
一つの選択的な実施の形態として、上記の、第二の端末のリソースに基づいてＳＬリソース選択を行うことは、
ＳＬリソース選択を行う時に、前記第二の端末のリソースを排除することと、
ＳＬリソース選択を行う時に、前記第二の端末のリソースに対応するＰＳＦＣＨに関連するリソースを排除することとのうちの少なくとも一つを含む。
ここで、上記の、第二の端末のリソースに基づいてＳＬリソース選択を行うことは、衝突リソースを検出する前又は衝突リソースを検出した後に行われるリソース選択であってもよい。
上記の、ＳＬリソース選択を行う時に、前記第二の端末のリソースを排除することは、第一の端末が第二の端末のＰＳＣＣＨ／ＰＳＳＣＨリソースの位置する（時間領域及び／又は周波数領域）リソースを排除して、ＳＬリソース選択を行うことであってもよい。
上記の、ＳＬリソース選択を行う時に、前記第二の端末のリソースに対応するＰＳＦＣＨに関連するリソースを排除することは、第二の端末のＰＳＣＣＨ／ＰＳＳＣＨリソースに対応するＰＳＦＣＨオケージョン（ＰＳＦＣＨ ｏｃｃａｓｉｏｎ）の関連ＰＳＣＣＨ／ＰＳＳＣＨオケージョン（ＰＳＣＣＨ／ＰＳＳＣＨ ｏｃｃａｓｉｏｎ（ｓ））を排除することであってもよい。
また、上記排除及び選択は、候補リソースセットのプロセスにおいて実行されてもよく、又は候補リソースセットから伝送リソースを選択するプロセスにおいて実行されてもよい。
この実施の形態では、前記第二の端末のリソースを排除し、前記第二の端末のリソースに対応するＰＳＦＣＨに関連するリソースを排除するため、このように選択されたＳＬリソースが衝突を回避できることを実現することができ、それによってＳＬの伝送信頼性を向上させる。
本出願の実施例では、前記の、前記第二の端末のリソースを排除し又は前記第二の端末のリソースに対応するＰＳＦＣＨに関連するリソースを排除することは、
候補リソースセットを取得するプロセスにおいて前記第二の端末のリソースを排除し又は前記第二の端末のリソースに対応するＰＳＦＣＨに関連するリソースを排除すること、又は
候補リソースセットから伝送リソースを選択するプロセスにおいて前記第二の端末のリソースを排除し又は前記第二の端末のリソースに対応するＰＳＦＣＨに関連するリソースを排除すること、又は
候補リソースセットから伝送リソースを選択する時に、前記第二の端末のリソースを排除し又は前記第二の端末のリソースに対応するＰＳＦＣＨに関連するリソースを排除するまで、リソース再選択を繰り返して行うこと、又は
前記第二の端末のリソースを排除し又は前記第二の端末のリソースに対応するＰＳＦＣＨに関連するリソースを排除するまでリソース再選択ステップを繰り返して行うことを含んでもよい。
前記第二の端末のリソースは、第二の端末により占有されたＰＳＣＣＨ／ＰＳＳＣＨ時間領域リソース、ＰＳＣＣＨ／ＰＳＳＣＨ周波数領域リソース、又はＰＳＣＣＨ／ＰＳＳＣＨ時間周波数リソースであってもよく、
前記第二の端末のリソースに対応するＰＳＦＣＨに関連するリソースは、第二の端末のＰＳＣＣＨ／ＰＳＳＣＨリソースに対応するＰＳＦＣＨ ｏｃｃａｓｉｏｎに対応するＰＳＣＣＨ／ＰＳＳＣＨリソースであってもよい。
本出願の実施例では、第一の端末は、ターゲット操作を実行し、ここで、前記ターゲット操作は、衝突リソースを検出することと、衝突リソースに対し、衝突処理操作を実行することと、前記第一の端末の物理サイドリンクチャネルの相手側である第二の端末のリソースに基づいてＳＬリソース選択を行うこととのうちの少なくとも一つを含み、ここで、前記衝突リソースは、ＳＬリソース間の衝突と、ＳＬリソースと非ＳＬリソースとの間の衝突とのうちの少なくとも一つを含む。このように端末が上記ターゲット操作を実行するため、それによって端末のＳＬの処理能力を向上させることができる。
図８を参照すると、図８は、本発明の実施例によるリソース処理装置の構造図であり、図８に示すように、リソース処理装置８００は、
ターゲット操作を実行するための実行モジュール８０１を含み、ここで、前記ターゲット操作は、
衝突リソースを検出することと、
衝突リソースに対し、衝突処理操作を実行することと、
前記リソース処理装置を含む第一の端末の物理サイドリンクチャネルの相手側である第二の端末のリソースに基づいてサイドリンクＳＬリソース選択を行うこととのうちの少なくとも一つを含み、
ここで、前記衝突リソースは、
サイドリンクＳＬリソース間の衝突と、
ＳＬリソースと非ＳＬリソースとの間の衝突とのうちの少なくとも一つを含む。
選択的に、上記リソース処理装置８００は、
ＳＬ情報を送信するための送信モジュールと、
ＳＬ情報を受信するための受信モジュールとのうちの少なくとも一つをさらに含んでもよい。
選択的に、前記の、衝突リソースを検出することは、
リソース情報に基づいて、衝突リソースを検出することを含み、
ここで、前記リソース情報は、
前記第一の端末のリソースと、少なくとも一つの第二の端末のリソースとのうちの少なくとも一つを表すために用いられる。
選択的に、前記の、リソース情報に基づいて、衝突リソースを検出することは、
前記リソース情報と少なくとも一つの前記第二の端末の識別子に基づいて、衝突リソースを検出することを含む。
選択的に、前記少なくとも一つの第二の端末のリソースは、
前記第一の端末により受信されたＳＬ制御情報によって決定された少なくとも一つの第二の端末のリソースを含み、ここで、前記ＳＬ制御情報は、
リソース予約情報と、予約リソースに関連する端末識別子とのうちの少なくとも一つを含む。
選択的に、前記の、衝突リソースに対し、衝突処理操作を実行することは、
前記衝突リソースを検出し、且つ伝送衝突が存在する場合に、前記衝突リソースに対し、衝突処理操作を実行することを含む。
選択的に、
前記第一の端末が前記衝突リソース上で伝送ブロックＴＢを受信する必要があることと、
前記第一の端末が前記衝突リソース上でＴＢを送信する必要があることと、
前記第一の端末が前記衝突リソース上でハイブリッド自動再送要求ＨＡＲＱフィードバックを受信する必要があることと、
前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを送信する必要があることと、のうちの少なくとも一つの場合に、前記伝送衝突が存在すると決定し、
ここで、前記ＴＢは、前記衝突リソースに対応するＴＢであり、前記ＨＡＲＱフィードバックは、前記衝突リソースに対応するＨＡＲＱフィードバックである。前記ＴＢ又はＨＡＲＱフィードバックの受信又は送信ターゲットは、相手側ＵＥであってもよい。
選択的に、
前記第一の端末が前記衝突リソースの前にすでにＴＢの復調に成功したことと、
前記第一の端末が前記衝突リソースの前にＴＢの送信に成功できることと、
前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを受信する必要がないことと、
前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを送信する必要がないことと、のうちの一つの場合に、前記伝送衝突が存在しないと決定し、
ここで、前記ＴＢは、前記衝突リソースに対応するＴＢであり、前記ＨＡＲＱフィードバックは、前記衝突リソースに対応するＨＡＲＱフィードバックである。前記ＴＢ又はＨＡＲＱフィードバックの受信又は送信ターゲットは、相手側ＵＥであってもよい。
選択的に、前記ターゲット操作は、
前記衝突リソースの前の前記衝突リソースに対応するＴＢの最後の伝送が伝送に成功したかどうかを検出することをさらに含む。
選択的に、前記の、衝突リソースに対し、衝突処理操作を実行することは、
以下のような少なくとも一つを満たす場合に、前記衝突リソースに対し、衝突処理操作を実行することを含み、即ち、
前記衝突リソースに対応する伝送タイプがターゲット伝送タイプであり、
前記衝突リソースに対応する伝送情報のサービス品質ＱｏＳがターゲットＱｏＳであり、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在せず、
前記第一の端末が前記衝突リソース上で複数の物理サイドリンクフィードバックチャネルＰＳＦＣＨを送信することができず、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在する。
選択的に、前記の、衝突リソースに対し、衝突処理操作を実行することは、
前記衝突リソースが前記第一の端末のＳＬリソースとして指示されたのが初めてである場合に、第一の条件で衝突リソースに対して衝突処理操作を実行すること、又は
前記衝突リソースが前記第一の端末のＳＬリソースとして指示されたのが初めてではない場合に、第二の条件で衝突リソースに対して衝突処理操作を実行することを含み、
ここで、前記第一の条件は、
前記衝突リソースに対応する伝送タイプがターゲット伝送タイプであることと、
前記衝突リソースに対応する伝送情報のＱｏＳがターゲットＱｏＳであることと、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在しないことと、
前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができず、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在することとのうちの少なくとも一つを含み、
前記第二の条件は、
前記衝突リソースに対応する伝送タイプがターゲット伝送タイプであることと、
前記衝突リソースに対応する伝送情報のＱｏＳがターゲットＱｏＳであることと、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在しないことと、
前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができず、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在することとのうちの少なくとも一つをそれぞれ含み、
ここで、前記第一の条件と前記第二の条件は、含まれる内容が異なる。
選択的に、前記衝突処理操作は、
リソースを再選択することと、
前記衝突リソースを廃棄することと、
ＨＡＲＱ情報をフィードバックすることと、
前記第一の端末の物理サイドリンクチャネルの相手側である第二の端末に通知することとのうちの少なくとも一つを含む。
選択的に、前記の、衝突リソースに対し、衝突処理操作を実行することは、
ターゲット時刻の検出結果に基づいて、前記衝突リソースに対して衝突処理操作を実行することを含み、ここで、前記ターゲット時刻の検出結果は、
前記衝突リソースと、
伝送衝突が存在するかどうかと、
前記衝突リソースの伝送タイプと、
前記衝突リソースの伝送情報の優先度と、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在するかどうかと、
前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができるかどうか、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在するかどうかとのうちの少なくとも一つを表すために用いられる。
選択的に、前記の、衝突リソースを検出することは、
ターゲット時刻に衝突リソースを検出すること、又は
前記ターゲット時刻を含む複数の時刻に衝突リソースを検出することを含む。
選択的に、前記ターゲット時刻は、
前記第一の端末のＳＬリソースに対してリソース指示を行う前のＴ１時刻と、
前記第一の端末のＳＬリソースに対してリソース指示を行う前のＴ１時刻の前の時刻と、
前記第一の端末のＳＬリソースに対して予約を行う前のＴ１時刻と、
前記第一の端末のＳＬリソースに対して予約を行う前のＴ１時刻の前の時刻と、
前記第一の端末のＳＬリソースの前のＴ２時刻と、
前記第一の端末のＳＬリソースの前のＴ２時刻の前の時刻と、
前記第二の端末のＳＬリソースの前のＴ３時刻と、
前記第二の端末のＳＬリソースの前のＴ３時刻の前の時刻と、
前記第二の端末のＳＬリソースの予約指示シグナリングが送信された後のＴ３時刻と、
前記第二の端末のＳＬリソースの予約指示シグナリングが送信されてから、且つ前記第二の端末のＳＬリソースの予約指示シグナリングが送信された後のＴ３時刻までの時刻と、
前記第二の端末のＳＬリソースの関連する衝突指示シグナリングが送信される前のＴ４時刻と、
前記第二の端末のＳＬリソースの関連する衝突指示シグナリングが送信される前のＴ４時刻の前の時刻とのうちの少なくとも一つを含み、
ここで、前記第二の端末のＳＬリソースは、前記第二の端末が前記第一の端末にＳＬ伝送を行うリソースであり、前記Ｔ１、Ｔ２、Ｔ３とＴ４は、同じ又は異なる時間リソースをそれぞれ表す。
選択的に、前記の、前記第一の端末のＳＬリソースに対してリソース指示を行うことは、
前記第一の端末のＳＬリソースに対してｉ回目のリソース指示を行うことを含み、ｉは、１以上の整数である。
選択的に、前記の、第二の端末のリソースに基づいてＳＬリソース選択を行うことは、
ＳＬリソース選択を行う時に、前記第二の端末のリソースを排除することと、
ＳＬリソース選択を行う時に、前記第二の端末のリソースに対応するＰＳＦＣＨに関連するリソースを排除することとのうちの少なくとも一つを含む。
本出願の実施例によるリソース処理装置は、図２の方法の実施例における各プロセスを実現することができ、説明の繰り返しを回避するために、ここでこれ以上説明せず、且つ端末のＳＬの処理能力を向上させることができる。
説明すべきこととして、本出願の実施例におけるリソース処理装置は、装置であってもよく、第一の端末における部材、集積回路、又はチップであってもよい。
図９は、本出願の実施例を実現する通信機器のハードウェア構造概略図である。
この通信機器９００は、無線周波数ユニット９０１、ネットワークモジュール９０２、オーディオ出力ユニット９０３、入力ユニット９０４、センサ９０５、表示ユニット９０６、ユーザ入力ユニット９０７、インターフェースユニット９０８、メモリ９０８、及びプロセッサ９１０などの部材を含むが、それらに限らない。
当業者であれば理解できるように、通信機器９００は、各部材に給電する電源（例えば、電池）をさらに含んでもよく、電源は、電源管理システムによってプロセッサ９１０にロジック的に接続されてもよく、それにより電源管理システムによって充放電管理及び消費電力管理などの機能を実現することができる。図９に示す通信機器構造は、通信機器に対する限定を構成せず、通信機器は、図示された部材の数よりも多く又は少ない部材、又はいくつかの部材の組み合わせ、又は異なる部材の配置を含んでもよく、ここでこれ以上説明しない。
プロセッサ９１０は、ターゲット操作を実行するために用いられ、ここで、前記ターゲット操作は、
衝突リソースを検出することと、
衝突リソースに対し、衝突処理操作を実行することと、
前記リソース処理装置を含む第一の端末の物理サイドリンクチャネルの相手側である第二の端末のリソースに基づいてサイドリンクＳＬリソース選択を行うこととのうちの少なくとも一つを含み、
ここで、前記衝突リソースは、
サイドリンクＳＬリソース間の衝突と、
ＳＬリソースと非ＳＬリソースとの間の衝突とのうちの少なくとも一つを含む。
選択的に、前記の、衝突リソースを検出することは、
リソース情報に基づいて、衝突リソースを検出することを含み、
ここで、前記リソース情報は、
前記第一の端末のリソースと、少なくとも一つの第二の端末のリソースとのうちの少なくとも一つを表すために用いられる。
選択的に、前記の、リソース情報に基づいて、衝突リソースを検出することは、
前記リソース情報と少なくとも一つの前記第二の端末の識別子に基づいて、衝突リソースを検出することを含む。
選択的に、前記少なくとも一つの第二の端末のリソースは、
前記第一の端末により受信されたＳＬ制御情報によって決定された少なくとも一つの第二の端末のリソースを含み、ここで、前記ＳＬ制御情報は、
リソース予約情報と、予約リソースに関連する端末識別子とのうちの少なくとも一つを含む。
選択的に、前記の、衝突リソースに対し、衝突処理操作を実行することは、
前記衝突リソースを検出し、且つ伝送衝突が存在する場合に、前記衝突リソースに対し、衝突処理操作を実行することを含む。
選択的に、
前記第一の端末が前記衝突リソース上で伝送ブロックＴＢを受信する必要があることと、
前記第一の端末が前記衝突リソース上でＴＢを送信する必要があることと、
前記第一の端末が前記衝突リソース上でハイブリッド自動再送要求ＨＡＲＱフィードバックを受信する必要があることと、
前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを送信する必要があることと、のうちの少なくとも一つの場合に、前記伝送衝突が存在すると決定し、
ここで、前記ＴＢは、前記衝突リソースに対応するＴＢであり、前記ＨＡＲＱフィードバックは、前記衝突リソースに対応するＨＡＲＱフィードバックである。前記ＴＢ又はＨＡＲＱフィードバックの受信又は送信ターゲットは、相手側ＵＥであってもよい。
選択的に、
前記第一の端末が前記衝突リソースの前にすでにＴＢの復調に成功したことと、
前記第一の端末が前記衝突リソースの前にＴＢの送信に成功できることと、
前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを受信する必要がないことと、
前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを送信する必要がないことと、のうちの一つの場合に、前記伝送衝突が存在しないと決定し、
ここで、前記ＴＢは、前記衝突リソースに対応するＴＢであり、前記ＨＡＲＱフィードバックは、前記衝突リソースに対応するＨＡＲＱフィードバックである。前記ＴＢ又はＨＡＲＱフィードバックの受信又は送信ターゲットは、相手側ＵＥであってもよい。
選択的に、前記ターゲット操作は、
前記衝突リソースの前の前記衝突リソースに対応するＴＢの最後の伝送が伝送に成功したかどうかを検出することをさらに含む。
選択的に、前記の、衝突リソースに対し、衝突処理操作を実行することは、
以下のような少なくとも一つを満たす場合に、前記衝突リソースに対し、衝突処理操作を実行することを含み、即ち、
前記衝突リソースに対応する伝送タイプがターゲット伝送タイプであり、
前記衝突リソースに対応する伝送情報のサービス品質ＱｏＳがターゲットＱｏＳであり、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在せず、
前記第一の端末が前記衝突リソース上で複数の物理サイドリンクフィードバックチャネルＰＳＦＣＨを送信することができず、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在する。
選択的に、前記の、衝突リソースに対し、衝突処理操作を実行することは、
前記衝突リソースが前記第一の端末のＳＬリソースとして指示されたのが初めてである場合に、第一の条件で衝突リソースに対して衝突処理操作を実行すること、又は
前記衝突リソースが前記第一の端末のＳＬリソースとして指示されたのが初めてではない場合に、第二の条件で衝突リソースに対して衝突処理操作を実行することを含み、
ここで、前記第一の条件は、
前記衝突リソースに対応する伝送タイプがターゲット伝送タイプであることと、
前記衝突リソースに対応する伝送情報のＱｏＳがターゲットＱｏＳであることと、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在しないことと、
前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができず、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在することとのうちの少なくとも一つを含み、
前記第二の条件は、
前記衝突リソースに対応する伝送タイプがターゲット伝送タイプであることと、
前記衝突リソースに対応する伝送情報のＱｏＳがターゲットＱｏＳであることと、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在しないことと、
前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができず、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在することとのうちの少なくとも一つをそれぞれ含み、
ここで、前記第一の条件と前記第二の条件は、含まれる内容が異なる。
選択的に、前記衝突処理操作は、
リソースを再選択することと、
前記衝突リソースを廃棄することと、
ＨＡＲＱ情報をフィードバックすることと、
前記第一の端末の物理サイドリンクチャネルの相手側である第二の端末に通知することとのうちの少なくとも一つを含む。
選択的に、前記の、衝突リソースに対し、衝突処理操作を実行することは、
ターゲット時刻の検出結果に基づいて、前記衝突リソースに対して衝突処理操作を実行することを含み、ここで、前記ターゲット時刻の検出結果は、
前記衝突リソースと、
伝送衝突が存在するかどうかと、
前記衝突リソースの伝送タイプと、
前記衝突リソースの伝送情報の優先度と、
前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在するかどうかと、
前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができるかどうか、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在するかどうかとのうちの少なくとも一つを表すために用いられる。
選択的に、前記の、衝突リソースを検出することは、
ターゲット時刻に衝突リソースを検出すること、又は
前記ターゲット時刻を含む複数の時刻に衝突リソースを検出することを含む。
選択的に、前記ターゲット時刻は、
前記第一の端末のＳＬリソースに対してリソース指示を行う前のＴ１時刻と、
前記第一の端末のＳＬリソースに対してリソース指示を行う前のＴ１時刻の前の時刻と、
前記第一の端末のＳＬリソースに対して予約を行う前のＴ１時刻と、
前記第一の端末のＳＬリソースに対して予約を行う前のＴ１時刻の前の時刻と、
前記第一の端末のＳＬリソースの前のＴ２時刻と、
前記第一の端末のＳＬリソースの前のＴ２時刻の前の時刻と、
前記第二の端末のＳＬリソースの前のＴ３時刻と、
前記第二の端末のＳＬリソースの前のＴ３時刻の前の時刻と、
前記第二の端末のＳＬリソースの予約指示シグナリングが送信された後のＴ３時刻と、
前記第二の端末のＳＬリソースの予約指示シグナリングが送信されてから、且つ前記第二の端末のＳＬリソースの予約指示シグナリングが送信された後のＴ３時刻までの時刻と、
前記第二の端末のＳＬリソースの関連する衝突指示シグナリングが送信される前のＴ４時刻と、
前記第二の端末のＳＬリソースの関連する衝突指示シグナリングが送信される前のＴ４時刻の前の時刻とのうちの少なくとも一つを含み、
ここで、前記第二の端末のＳＬリソースは、前記第二の端末が前記第一の端末にＳＬ伝送を行うリソースであり、前記Ｔ１、Ｔ２、Ｔ３とＴ４は、同じ又は異なる時間リソースをそれぞれ表す。
選択的に、前記の、前記第一の端末のＳＬリソースに対してリソース指示を行うことは、
前記第一の端末のＳＬリソースに対してｉ回目のリソース指示を行うことを含み、ｉは、１以上の整数である。
選択的に、前記の、第二の端末のリソースに基づいてＳＬリソース選択を行うことは、
ＳＬリソース選択を行う時に、前記第二の端末のリソースを排除することと、
ＳＬリソース選択を行う時に、前記第二の端末のリソースに対応するＰＳＦＣＨに関連するリソースを排除することとのうちの少なくとも一つを含む。
本出願の実施例は、端末のＳＬの処理能力を向上させることができる。
選択的に、本発明の実施例は、通信機器をさらに提供し、前記通信機器は、第二の通信機器であり、プロセッサ９１０と、メモリ９０８と、メモリ９０８に記憶されており、且つ前記プロセッサ９１０上で運行できるプログラム又は命令とを含み、このプログラム又は命令がプロセッサ９１０により実行される時、上記リソース処理方法の実施例の各プロセスを実現し、且つ同じ技術的効果を達成することができる。説明の繰り返しを回避するために、ここでこれ以上説明しない。
本出願の実施例は、可読記憶媒体をさらに提供し、前記可読記憶媒体上にはプログラム又は命令が記憶されており、前記プログラム又は命令がプロセッサにより実行される時、本出願の実施例によるリソース処理方法におけるステップを実現する。
本出願の実施例は、プログラム製品をさらに提供し、前記プログラム製品が非揮発性の記憶媒体に記憶されており、前記プログラム製品が少なくとも一つのプロセッサにより実行されて、本出願の実施例によるリソース処理におけるステップを実現する。
ここで、前記プロセッサは、上記実施例に記載の端末又はネットワーク機器におけるプロセッサである。前記可読記憶媒体は、コンピュータ可読記憶媒体、例えばコンピュータリードオンリーメモリ（Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ、ＲＯＭ）、ランダムアクセスメモリ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ、ＲＡＭ）、磁気ディスク又は光ディスクなどを含む。
本出願の実施例は、チップをさらに提供し、前記チップは、プロセッサと通信インターフェースを含み、前記通信インターフェースは、前記プロセッサと結合され、前記プロセッサは、プログラム又は命令を運行し、本出願の実施例によるリソース処理方法の実施例の各プロセスを実現するために用いられ、且つ同じ技術的効果を達成することができる。説明の繰り返しを回避するために、ここでこれ以上説明しない。
理解すべきこととして、本出願の実施例に言及されたチップは、システムレベルチップ、システムチップ、チップシステム又はシステムオンチップなどと呼ばれてもよい。
本出願の実施例は、コンピュータプログラム製品を提供し、前記コンピュータプログラム製品が非一時的記憶媒体に記憶されており、前記コンピュータプログラム製品が少なくとも一つのプロセッサにより実行されて、上記方法の実施例の各プロセスを実現し、且つ同じ技術的効果を達成することができる。説明の繰り返しを回避するために、ここでこれ以上説明しない。
本出願の実施例は、通信機器を提供し、上記のような方法の各実施例の各プロセスを実現するように構成され、且つ同じ技術的効果を達成することができる。説明の繰り返しを回避するために、ここでこれ以上説明しない。
説明すべきこととして、本明細書では、用語である「含む」、「包含」又はその他の任意の変形は、非排他的な「含む」を意図的にカバーするものであり、それによって一連の要素を含むプロセス、方法、物品又は装置は、それらの要素を含むだけではなく、明確にリストアップされていない他の要素も含み、又はこのようなプロセス、方法、物品又は装置に固有の要素も含む。それ以上の制限がない場合に、「……を１つ含む」という文章で限定された要素について、この要素を含むプロセス、方法、物品又は装置には他の同じ要素も存在することが排除されるものではない。なお、指摘すべきこととして、本出願の実施の形態における方法と装置の範囲は、図示又は討論された順序で機能を実行することに限らず、関わる機能に基づいて基本的に同時である方式又は逆の順序で機能を実行することを含んでもよく、例えば記述されたものとは異なる手順で記述された方法を実行することができるとともに、様々なステップを追加、省略又は組み合わせることができる。また、いくつかの例を参照して記述された特徴は、他の例で組み合わせられることができる。
以上の実施の形態の記述によって、当業者であればはっきりと分かるように上記実施例の方法は、ソフトウェアと必要な汎用ハードウェアプラットフォームの形態によって実現されることができる。無論、ハードウェアによって実現されてもよいが、多くの場合、前者は、より好適な実施の形態である。このような理解を踏まえて、本出願の技術案は、実質には又は従来の技術に寄与した部分がソフトウェア製品の形式によって具現化されてもよい。このコンピュータソフトウェア製品は、一つの記憶媒体（例えばＲＯＭ／ＲＡＭ、磁気ディスク、光ディスク）に記憶され、一台の端末（携帯電話、コンピュータ、サーバ、エアコン、又はネットワーク機器などであってもよい）に本出願の各実施例に記載の方法を実行させるための若干の命令を含む。
以上は、図面を結び付けながら、本出願の実施例を記述したが、本出願は、上記の具体的な実施の形態に限らない。上記の具体的な実施の形態は、例示的なものに過ぎず、制限性のあるものではない。当業者は、本出願の示唆で、本出願の趣旨と特許請求の範囲から逸脱しない限り、多くの形式を行うこともでき、いずれも本出願の保護範囲に属する。
800 リソース処理装置
801 実行モジュール
901 無線周波数ユニット
902 ネットワークモジュール
903 オーディオ出力ユニット
904 入力ユニット
905 センサ
906 表示ユニット
907 ユーザ入力ユニット
908 インターフェースユニット
909 メモリ
910 プロセッサ
この通信機器９００は、無線周波数ユニット９０１、ネットワークモジュール９０２、オーディオ出力ユニット９０３、入力ユニット９０４、センサ９０５、表示ユニット９０６、ユーザ入力ユニット９０７、インターフェースユニット９０８、メモリ９０９、及びプロセッサ９１０などの部材を含むが、それらに限らない。
選択的に、本発明の実施例は、通信機器をさらに提供し、前記通信機器は、第二の通信機器であり、プロセッサ９１０と、メモリ９０９と、メモリ９０９に記憶されており、且つ前記プロセッサ９１０上で運行できるプログラム又は命令とを含み、このプログラム又は命令がプロセッサ９１０により実行される時、上記リソース処理方法の実施例の各プロセスを実現し、且つ同じ技術的効果を達成することができる。説明の繰り返しを回避するために、ここでこれ以上説明しない。

Claims (24)

  1. リソース処理方法であって、
    第一の端末がターゲット操作を実行することを含み、ここで、前記ターゲット操作は、
    衝突リソースを検出することと、
    衝突リソースに対し、衝突処理操作を実行することと、
    前記第一の端末の物理サイドリンクチャネルの相手側である第二の端末のリソースに基づいてサイドリンクＳＬリソース選択を行うこととのうちの少なくとも一つを含み、
    ここで、前記衝突リソースは、
    ＳＬリソース間の衝突と、
    ＳＬリソースと非ＳＬリソースとの間の衝突とのうちの少なくとも一つを含む、リソース処理方法。
  2. 前記の、衝突リソースを検出することは、
    前記第一の端末がリソース情報に基づいて、衝突リソースを検出することを含み、
    ここで、前記リソース情報は、
    前記第一の端末のリソースと、少なくとも一つの第二の端末のリソースとのうちの少なくとも一つを表すために用いられる、請求項１に記載の方法。
  3. 前記第一の端末がリソース情報に基づいて、衝突リソースを検出することは、
    前記第一の端末が前記リソース情報と少なくとも一つの前記第二の端末の識別子に基づいて、衝突リソースを検出することを含む、請求項２に記載の方法。
  4. 前記少なくとも一つの第二の端末のリソースは、
    前記第一の端末により受信されたＳＬ制御情報によって決定された少なくとも一つの第二の端末のリソースを含み、ここで、前記ＳＬ制御情報は、
    リソース予約情報と、予約リソースに関連する端末識別子とのうちの少なくとも一つを含む、請求項２又は３に記載の方法。
  5. 前記の、衝突リソースに対し、衝突処理操作を実行することは、
    前記衝突リソースを検出し、且つ伝送衝突が存在する場合に、前記衝突リソースに対し、衝突処理操作を実行することを含む、請求項１に記載の方法。
  6. 前記第一の端末が前記衝突リソース上で伝送ブロックＴＢを受信する必要があることと、
    前記第一の端末が前記衝突リソース上でＴＢを送信する必要があることと、
    前記第一の端末が前記衝突リソース上でハイブリッド自動再送要求ＨＡＲＱフィードバックを受信する必要があることと、
    前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを送信する必要があることと、のうちの少なくとも一つの場合に、前記伝送衝突が存在すると決定し、
    ここで、前記ＴＢは、前記衝突リソースに対応するＴＢであり、前記ＨＡＲＱフィードバックは、前記衝突リソースに対応するＨＡＲＱフィードバックである、請求項５に記載の方法。
  7. 前記第一の端末が前記衝突リソースの前にすでにＴＢの復調に成功したことと、
    前記第一の端末が前記衝突リソースの前にＴＢの送信に成功できることと、
    前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを受信する必要がないことと、
    前記第一の端末が前記衝突リソース上でＨＡＲＱフィードバックを送信する必要がないことと、のうちの一つの場合に、前記伝送衝突が存在しないと決定し、
    ここで、前記ＴＢは、前記衝突リソースに対応するＴＢであり、前記ＨＡＲＱフィードバックは、前記衝突リソースに対応するＨＡＲＱフィードバックである、請求項５又は６に記載の方法。
  8. 前記ターゲット操作は、
    前記衝突リソースの前の前記衝突リソースに対応するＴＢの最後の伝送が伝送に成功したかどうかを検出することをさらに含む、請求項１に記載の方法。
  9. 前記の、衝突リソースに対し、衝突処理操作を実行することは、
    以下のような少なくとも一つを満たす場合に、前記衝突リソースに対し、衝突処理操作を実行することを含み、即ち、
    前記衝突リソースに対応する伝送タイプがターゲット伝送タイプであり、
    前記衝突リソースに対応する伝送情報のサービス品質ＱｏＳがターゲットＱｏＳであり、
    前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在せず、
    前記第一の端末が前記衝突リソース上で複数の物理サイドリンクフィードバックチャネルＰＳＦＣＨを送信することができず、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在する、請求項１に記載の方法。
  10. 前記の、衝突リソースに対し、衝突処理操作を実行することは、
    前記衝突リソースが前記第一の端末のＳＬリソースとして指示されたのが初めてである場合に、第一の条件で衝突リソースに対して衝突処理操作を実行すること、又は
    前記衝突リソースが前記第一の端末のＳＬリソースとして指示されたのが初めてではない場合に、第二の条件で衝突リソースに対して衝突処理操作を実行することを含み、
    ここで、前記第一の条件は、
    前記衝突リソースに対応する伝送タイプがターゲット伝送タイプであることと、
    前記衝突リソースに対応する伝送情報のＱｏＳがターゲットＱｏＳであることと、
    前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在しないことと、
    前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができず、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在することとのうちの少なくとも一つを含み、
    前記第二の条件は、
    前記衝突リソースに対応する伝送タイプがターゲット伝送タイプであることと、
    前記衝突リソースに対応する伝送情報のＱｏＳがターゲットＱｏＳであることと、
    前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在しないことと、
    前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができず、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在することとのうちの少なくとも一つをそれぞれ含み、
    ここで、前記第一の条件と前記第二の条件は、含まれる内容が異なる、請求項１に記載の方法。
  11. 前記衝突処理操作は、
    リソースを再選択することと、
    前記衝突リソースを廃棄することと、
    ＨＡＲＱ情報をフィードバックすることと、
    前記第一の端末の物理サイドリンクチャネルの相手側である第二の端末に通知することとのうちの少なくとも一つを含む、請求項１に記載の方法。
  12. 前記の、衝突リソースに対し、衝突処理操作を実行することは、
    ターゲット時刻の検出結果に基づいて、前記衝突リソースに対して衝突処理操作を実行することを含み、ここで、前記ターゲット時刻の検出結果は、
    前記衝突リソースと、
    伝送衝突が存在するかどうかと、
    前記衝突リソースの伝送タイプと、
    前記衝突リソースの伝送情報の優先度と、
    前記衝突リソースの後に、前記衝突リソースに対応するＴＢに伝送リソースが存在するかどうかと、
    前記第一の端末が前記衝突リソース上で複数のＰＳＦＣＨを送信することができるかどうか、又は前記第一の端末が、前記衝突リソース上には送信パワーが閾値以下であるＰＳＦＣＨが少なくとも一つ存在するかどうかとのうちの少なくとも一つを表すために用いられる、請求項１に記載の方法。
  13. 前記の、衝突リソースを検出することは、
    ターゲット時刻に衝突リソースを検出すること、又は
    前記ターゲット時刻を含む複数の時刻に衝突リソースを検出することを含む、請求項１に記載の方法。
  14. 前記ターゲット時刻は、
    前記第一の端末のＳＬリソースに対してリソース指示を行う前のＴ１時刻と、
    前記第一の端末のＳＬリソースに対してリソース指示を行う前のＴ１時刻の前の時刻と、
    前記第一の端末のＳＬリソースに対して予約を行う前のＴ１時刻と、
    前記第一の端末のＳＬリソースに対して予約を行う前のＴ１時刻の前の時刻と、
    前記第一の端末のＳＬリソースの前のＴ２時刻と、
    前記第一の端末のＳＬリソースの前のＴ２時刻の前の時刻と、
    前記第二の端末のＳＬリソースの前のＴ３時刻と、
    前記第二の端末のＳＬリソースの前のＴ３時刻の前の時刻と、
    前記第二の端末のＳＬリソースの予約指示シグナリングが送信された後のＴ３時刻と、
    前記第二の端末のＳＬリソースの予約指示シグナリングが送信されてから、且つ前記第二の端末のＳＬリソースの予約指示シグナリングが送信された後のＴ３時刻までの時刻と、
    前記第二の端末のＳＬリソースの関連する衝突指示シグナリングが送信される前のＴ４時刻と、
    前記第二の端末のＳＬリソースの関連する衝突指示シグナリングが送信される前のＴ４時刻の前の時刻とのうちの少なくとも一つを含み、
    ここで、前記第二の端末のＳＬリソースは、前記第二の端末が前記第一の端末にＳＬ伝送を行うリソースであり、前記Ｔ１、Ｔ２、Ｔ３とＴ４は、同じ又は異なる時間リソースをそれぞれ表す、請求項１２又は１３に記載の方法。
  15. 前記の、前記第一の端末のＳＬリソースに対してリソース指示を行うことは、
    前記第一の端末のＳＬリソースに対してｉ回目のリソース指示を行うことを含み、ｉは、１以上の整数である、請求項１４に記載の方法。
  16. 前記の、第二の端末のリソースに基づいてＳＬリソース選択を行うことは、
    ＳＬリソース選択を行う時に、前記第二の端末のリソースを排除することと、
    ＳＬリソース選択を行う時に、前記第二の端末のリソースに対応するＰＳＦＣＨに関連するリソースを排除することとのうちの少なくとも一つを含む、請求項１に記載の方法。
  17. リソース処理装置であって、
    ターゲット操作を実行するための実行モジュールを含み、ここで、前記ターゲット操作は、
    衝突リソースを検出することと、
    衝突リソースに対し、衝突処理操作を実行することと、
    前記リソース処理装置を含む第一の端末の物理サイドリンクチャネルの相手側である第二の端末のリソースに基づいてサイドリンクＳＬリソース選択を行うこととのうちの少なくとも一つを含み、
    ここで、前記衝突リソースは、
    サイドリンクＳＬリソース間の衝突と、
    ＳＬリソースと非ＳＬリソースとの間の衝突とのうちの少なくとも一つを含む、リソース処理装置。
  18. 前記の、衝突リソースを検出することは、
    前記第一の端末がリソース情報に基づいて、衝突リソースを検出することを含み、
    ここで、前記リソース情報は、
    前記第一の端末のリソースと、少なくとも一つの第二の端末のリソースとのうちの少なくとも一つを表すために用いられる、請求項１７に記載の装置。
  19. 前記の、衝突リソースに対し、衝突処理操作を実行することは、
    前記衝突リソースを検出し、且つ伝送衝突が存在する場合に、前記衝突リソースに対し、衝突処理操作を実行することを含む、請求項１８に記載の装置。
  20. 端末であって、第一の端末であり、メモリと、プロセッサと、前記メモリに記憶され、且つ前記プロセッサ上で運行できるプログラム又は命令とを含み、前記プログラム又は命令が前記プロセッサにより実行される時に、請求項１から１６のいずれか１項に記載のリソース処理方法におけるステップを実現する、端末。
  21. 可読記憶媒体であって、前記可読記憶媒体上にはプログラム又は命令が記憶されており、前記プログラム又は命令がプロセッサにより実行される時に、請求項１から１６のいずれか１項に記載のリソース処理方法におけるステップを実現する、可読記憶媒体。
  22. チップであって、プロセッサと通信インターフェースとを含み、前記通信インターフェースは、前記プロセッサと結合され、前記プロセッサは、プログラム又は命令を運行し、請求項１から１６のいずれか１項に記載のリソース処理方法におけるステップを実現するために用いられる、チップ。
  23. コンピュータプログラム製品であって、非一時的記憶媒体に記憶されており、前記プログラム製品が少なくとも一つのプロセッサにより実行されて、請求項１から１６のいずれか１項に記載のリソース処理方法におけるステップを実現する、コンピュータプログラム製品。
  24. 通信機器であって、請求項１から１６のいずれか１項に記載のリソース処理方法におけるステップを実行するように構成される、通信機器。
JP2023545366A 2021-01-26 2022-01-26 リソース処理方法、装置、端末と記憶媒体 Pending JP2024504741A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN202110106340.2 2021-01-26
CN202110106340.2A CN114793348A (zh) 2021-01-26 2021-01-26 资源处理方法、装置、终端和存储介质
PCT/CN2022/073940 WO2022161384A1 (zh) 2021-01-26 2022-01-26 资源处理方法、装置、终端和存储介质

Publications (1)

Publication Number Publication Date
JP2024504741A true JP2024504741A (ja) 2024-02-01

Family

ID=82459710

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023545366A Pending JP2024504741A (ja) 2021-01-26 2022-01-26 リソース処理方法、装置、端末と記憶媒体

Country Status (6)

Country Link
US (1) US20230371045A1 (ja)
EP (1) EP4287702A4 (ja)
JP (1) JP2024504741A (ja)
KR (1) KR20230134587A (ja)
CN (1) CN114793348A (ja)
WO (1) WO2022161384A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115373824B (zh) * 2022-10-24 2023-02-03 恒生电子股份有限公司 冲突检测方法、装置、计算设备和计算机可读存储介质
WO2024092765A1 (zh) * 2022-11-04 2024-05-10 Oppo广东移动通信有限公司 Psfch的传输方法、装置、设备及存储介质
CN116249205B (zh) * 2022-12-30 2024-02-09 四川数字交通科技股份有限公司 一种用于资源选择的触发重选方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107645735B (zh) * 2016-07-21 2020-10-30 普天信息技术有限公司 一种V2X网络中sidelink的资源负载测量方法以及装置
GB2552792B8 (en) * 2016-08-08 2019-01-30 Tcl Communication Ltd Methods and devices for resource selection for direct transmissions between wireless devices in a wireless communication system
CN110972195A (zh) * 2018-09-28 2020-04-07 维沃移动通信有限公司 一种传输处理方法、终端及控制节点
CN111194057B (zh) * 2018-11-27 2023-07-18 维沃移动通信有限公司 一种资源排除方法及终端
EP3895494A4 (en) * 2018-12-14 2022-11-02 Fg Innovation Company Limited METHODS AND APPARATUS FOR LIMITING SIDE LINK COMMUNICATIONS COLLISION IN WIRELESS COMMUNICATIONS SYSTEMS
CN112235765B (zh) * 2020-12-16 2021-04-02 北京大唐高鸿数据网络技术有限公司 一种资源选择方法、装置及终端

Also Published As

Publication number Publication date
WO2022161384A1 (zh) 2022-08-04
CN114793348A (zh) 2022-07-26
EP4287702A1 (en) 2023-12-06
KR20230134587A (ko) 2023-09-21
EP4287702A4 (en) 2024-05-22
US20230371045A1 (en) 2023-11-16

Similar Documents

Publication Publication Date Title
JP2024504741A (ja) リソース処理方法、装置、端末と記憶媒体
CN109618415B (zh) 一种d2d通信方法及设备
US20240129901A1 (en) Communication method and apparatus
WO2014100932A1 (zh) 资源竞争的方法、利用资源竞争的方法及其装置
WO2019148485A1 (zh) 一种资源选择方法及装置、计算机存储介质
CN114915391B (zh) 冲突指示方法、装置及电子设备
JP2018519746A (ja) デバイス間通信におけるスケジューリング割り当て送信
CN113766640A (zh) 通信方法及装置
US20240292441A1 (en) Physical sidelink feedback channel resource configuration method,terminal, and network side device
CN107295567A (zh) 一种基于帧结构的无限资源冲突检测方法
JP2023535787A (ja) サイドリンクリソース選択方法及び端末
WO2022206906A1 (zh) 旁链路资源推荐的方法、装置、设备及可读存储介质
WO2021062824A1 (zh) 一种信息处理方法和通信设备
WO2018082230A1 (zh) 一种随机接入方法及站点
WO2024067017A1 (zh) 一种通信方法、装置和系统
US20240306170A1 (en) Methods for contention-based sidelink transmission and reception and related wireless devices
US20250056612A1 (en) Resource determining method and apparatus
WO2024022290A1 (zh) 资源选择方法及终端
WO2022258047A1 (zh) 共享频段上的资源确定方法和设备
WO2022030018A1 (ja) 端末、基地局装置、及びビーム故障リカバリ方法
WO2021072762A1 (zh) 无线通信的方法和终端设备
WO2022030017A1 (ja) 端末、及び基地局装置
WO2022030020A1 (ja) 端末、基地局装置、及びビーム故障リカバリ方法
WO2022141104A1 (zh) 资源选取方法、装置、设备及存储介质
CN118524548A (zh) 副链路sl传输方法、装置及第一终端

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230726

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230726

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240729

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20241029

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20250128