JP6955576B2 - 第２のサービスの送信における第１のサービスのためのデータのパンクチャバンドリング - Google Patents

第２のサービスの送信における第１のサービスのためのデータのパンクチャバンドリング Download PDF

Info

Publication number
JP6955576B2
JP6955576B2 JP2019552553A JP2019552553A JP6955576B2 JP 6955576 B2 JP6955576 B2 JP 6955576B2 JP 2019552553 A JP2019552553 A JP 2019552553A JP 2019552553 A JP2019552553 A JP 2019552553A JP 6955576 B2 JP6955576 B2 JP 6955576B2
Authority
JP
Japan
Prior art keywords
data
service
transmission
original set
iteration
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.)
Active
Application number
JP2019552553A
Other languages
English (en)
Other versions
JP2020516149A (ja
Inventor
カナー キリク，
カナー キリク，
シェザド アリ アシュラフ，
シェザド アリ アシュラフ，
ユーフェイ ブランケンシップ，
ユーフェイ ブランケンシップ，
ジャン チャン，
ジャン チャン，
ゼンホア ゾウ，
ゼンホア ゾウ，
Original Assignee
テレフオンアクチーボラゲット エルエム エリクソン（パブル）
テレフオンアクチーボラゲット エルエム エリクソン（パブル）
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 テレフオンアクチーボラゲット エルエム エリクソン（パブル）, テレフオンアクチーボラゲット エルエム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エルエム エリクソン（パブル）
Publication of JP2020516149A publication Critical patent/JP2020516149A/ja
Application granted granted Critical
Publication of JP6955576B2 publication Critical patent/JP6955576B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/1867—Arrangements specially adapted for the transmitter end
    • H04L1/189—Transmission or retransmission of more than one copy of a message
    • 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/08—Arrangements for detecting or preventing errors in the information received by repeating transmission, e.g. Verdan system
    • 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/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0009—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
    • H04L1/0013—Rate matching, e.g. puncturing or repetition of code symbols
    • 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]
    • H04L1/1819—Hybrid protocols; Hybrid automatic repeat request [HARQ] with retransmission of additional or different redundancy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0078—Timing of allocation
    • H04L5/0082—Timing of allocation at predetermined intervals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/0446—Resources in time domain, e.g. slots or frames
    • 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
    • H04L2001/0098—Unequal error protection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0044—Arrangements for allocating sub-channels of the transmission path allocation of payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055—Physical resource allocation for ACK/NACK

Description

無線通信は、予測不可能な干渉およびチャネル変動を伴う環境において発生する。HARQ （Hybrid Automatic Repeat Request（ハイブリッド自動再送要求））は、予測不可能な干渉およびチャネル変動に対処するために使用される一般的な技術である。HARQは送信においてデータメッセージを復号することを試みるために、アップリンクまたはダウンリンク送信を受信する無線デバイスを伴う。
図1は、LTEシステムにおいて送信ノード105と受信ノード110との間で使用される従来のHARQ技術のシグナリング図である。最初に、送信機105は、TTI（Transmission Time Interval（送信時間隔））で最大2つのトランスポートブロックを受信ノード110に送信する（ステップ115）。この送信の例は図2に示され、ここで、TTI1は2つのトランスポートブロックを含み、TTI2は2つのトランスポートブロックを含む。次に、受信ノード110は、2つのトランスポートブロックのそれぞれが正常に受信されたかどうか（復号に成功したかどうか）を判定（決定）する（ステップ120）。LTE（Long Term Evolution（ロングタームエボリューション））はTTIごとに最大2つのトランスポートブロックを提供するため、受信ノード110は、各ビットが各トランスポートブロックの成功または失敗を示す2ビットで構成されるHARQ-ACK（ACKnowledgement（確認応答））を送信ノード105に送信する（ステップ125）。
次に、送信機は、HARQ-ACK内のビットの値に基づいて、1つ以上のトランスポートブロックが正常に復号されなかったかどうかを判定する（ステップ130）。正常に復号されなかった場合、送信ノード105は、復号に失敗したトランスポートブロックを受信ノード110に送信する（ステップ135）。次に、受信ノード110は、復号に失敗したトランスポートブロックを、再送信されたトランスポートブロックとソフト合成することによって復号しようと試みる（ステップ140）。ソフト合成のタイプは変化することができ、周知のチェース（Chase）またはインクリメンタル冗長度（Incremental Redundancy）ソフト合成技術を含むことができる。ソフト合成は、復号が成功する確率を大幅に増加させる。
3GPPファミリーの無線システムにおける標準であるLTEは、MBB（Mobile BroadBand（モバイルブロードバンド））トラフィックに対して高度に最適化されている。TTI（サブフレーム）は1msの持続時間を持ち、FDD（Frequency Division Duplex（周波数分割複信））の場合、サブフレームnでデータ送信されるのに対して、HARQ-ACKはサブフレームn+4で送信される。
URLLC （Ultra-Reliable Low Latency Communication）は、10-5以下のエラー確率および1ms以下のエンドツーエンドレイテンシ（待ち時間）を含む、非常に厳しいエラーおよびレイテンシ要件を有するデータサービスである。他のサービスは、LTEにおけるいわゆる短いTTIのような、同様のエラーおよびレイテンシ要件を有する。
第5世代の移動体通信および無線技術はまだ完全には定義されていないが、3GPP内の進んだ草案段階にあり、5G New Radio（NR）アクセス技術に関する研究を含む。したがって、本開示のいくつかの部分ではLTE用語が使用されるが、本開示は5Gで指定されている用語とは異なる用語の使用にもかかわらず、同等の5Gエンティティまたは機能に等しく適用されことが理解されよう。3GPP TR 38.802 V1.0.0（2016-11）は、5G New Radio（NR）Access Technologyに関する現行の合意の概要を提供し、最終仕様はとりわけ、将来の3GPP TS 38.2**系列で公開され得る。
MBBまたはeMBB（拡張MBB）およびURLLCは、両方とも、5Gをターゲットとする広範囲のデータサービスの中にある。最適化された性能を有するサービスを可能にするために、TTI長は異なるサービスに対して異なることが期待され、ここで、TTIはサブフレーム、スロット、またはミニスロットに対応し得る。具体的には、URLLCがMBBと比較してより短いTTI長を有し得る。
MBBとURLLCの両方を同じネットワークに収容する（適応させる）ことは、URLLCの厳しいレイテンシ要件に起因する競合をもたらす。これらの競合はデータが同時に送信される必要がある場合に、MBBおよびURLLCデータのいずれかまたは両方を復号する問題をもたらす可能性がある。HARQは復号問題に対処する一般的な方法であるが、MBBおよびURLLCの両方を収容するネットワークにおいてHARQを実装することはURLLCの厳しいレイテンシ要件のために困難であり得る。具体的には従来のHARQ手順がMBBデータに対して実施することができるが、従来のHARQ手順はURLLCデータの厳しいレイテンシ要件を満たすことができない可能性が高い。
本開示の例示的な態様は、送信ノードにおいて実施される方法を対象とする。送信ノードは、第1のサービスのためのデータが第2のサービスのためのデータが送信される（ことになる）期間中に送信される（ことになる）ことを決定する。ここで、第1のサービスのためのデータは、第2のサービスのためのデータよりも低レイテンシ（短い待ち時間／低遅延）を必要とする。送信ノードはまた、送信または受信の条件を決定し、決定された送信または受信の条件に基づいて、第1のサービスの送信を調整することを決定する。次いで、第2のサービスのためのデータがある期間中に送信される間に、送信ノードは、当該期間中に、第1のサービスのためのデータを送信する（送信ノードは、ある期間中に、第1のサービスのためのデータを送信し、期間中に第2のサービスのデータが送信される。）。ここで、送信は、第1のサービスのためのデータの元のセットと、 第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとを含む。
本開示の他の態様は、この方法を実行するための送信ノード、ならびにプロセッサによって実行されると、プロセッサにこの方法を実行させるコードを備えるコンピュータ可読媒体を対象とする。
本開示の態様は、受信ノードにおいて実施される方法を対象とする。受信ノードは、期間中に送信を受信し、送信に第1のサービスのためのデータおよび第2のサービスのためのデータが含まれていると決定（判断）する。ここで第1のサービスのためのデータは、第2のサービスのためのデータよりも低レイテンシを必要とする。受信ノードはまた、送信に第1のサービスのためのデータの元のセットと、第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しが含まれていると決定し、第1のサービスのためのデータの復号を試行する。
本開示の他の態様は、この方法を実行するための受信ノード、ならびにプロセッサによって実行されると、プロセッサにこの方法を実行させるコードを備えるコンピュータ可読媒体を対象とする。
図1は、従来のHARQプロセスのシグナリング図である。 図2は、従来のトランスポートブロック送信のブロック図である。 図3Aは、例示的なパンクチャされたアップリンク送信およびダウンリンク送信のブロック図である。 図3Bは、例示的なパンクチャされたアップリンク送信およびダウンリンク送信のブロック図である。 図4は、本開示の例示的な実施形態による、繰り返される制御データおよびユーザデータを用いたパンクチャされた送信のブロック図である。 図5は、本開示の例示的な実施形態による、単一の制御データ送信と、周波数ホッピングを伴わない繰り返されるユーザデータ送信とを伴うパンクチャされた送信のブロック図である。 図6は、本開示の例示的な実施形態による、単一の制御データ送信と、周波数ホッピングを伴う繰り返されるユーザデータ送信とを伴うパンクチャされた送信のブロック図である。 図7は、本開示の例示的な実施形態による、単一の制御データ送信と、周波数ホッピングを発明繰り返されるユーザデータ送信とを発明、別のパンクチャされた送信のブロック図である。 図8は、本開示の例示的な実施形態による送信機および受信機のブロック図である。 図9は、本開示の例示的な実施形態による例示的な送信方法のハイレベルフロー図である。 図10は、本開示の例示的な実施形態による例示的な送信方法のフロー図である。 図11は、本開示の例示的な実施形態による例示的な受信方法のハイレベルフロー図である。 図12は、本開示の例示的な実施形態による例示的な受信方法のフロー図である。
同じネットワーク内でURLLCとMBBの両方を収容する1つの方法は、URLLC送信がMBB送信をパンクチャすることを可能にすることであり、その例が図3Aおよび図3Bに示されている。図3AはURLLC送信、すなわち、URLLCアップリンク制御信号部分312と、URLLC PUSCH（物理アップリンク共有チャネル）とアップリンク制御信号部分313とを含むようにパンクチャされているアップリンクMBB送信310の時間-周波数リソースの部分311を示す。図3BはURLLC送信、すなわち、PDCCH（URLLC物理ダウンリンク制御チャネル）およびPDCCH DMRS（復調基準信号）部分322と、URLLC PDSCHおよびPDSCH（物理ダウンリンク共有チャネル）DMRS部分323とを含むようにパンクチャされているダウンリンクMBB送信320の部分321を示す。
このパンクチャリングは同じネットワークにおいてMBBとURLLCの両方を提供することを可能にし、URLLC送信が厳しいタイミング要件を満たすことを可能にするが、送信されたデータの復号において問題が生じる可能性がある。MBB送信は（URLLCと比較して）時間に敏感ではないので、復号の問題は、いくつかの異なるTTIにおいてHARQを使用して対処することができる。例えば、LTEにおいて、1つのサブフレームである1つのTTIは1msの区間（持続時間）を有し、FDDのために、サブフレームnの間に最初に送信されたデータは、サブフレームn+4において再送信される。LTEアップリンクではHARQ再送信タイミングは固定され、HARQ再送信プロセスは典型的には再送信ごとに8msかかる。この遅延は、それほど時間に敏感ではないので、MBBまたはeMBBにとって許容可能であり得る。しかしながら、URLLCは時間に敏感であり、8msまで元の送信から分離された再送信は、再送信されたデータが受信機によって使用されるには到着が遅すぎる可能性が高い。したがって、この従来のHARQ処理は、MBBと同じネットワークにおいてURLLCを適切にサポートすることができない。この説明はMBB送信をパンクチャリングするURLLC送信に関連しているが、本開示は第1のサービスの送信によって第2のサービスの送信をパンクチャリングすることに等しく適用可能であり、第1のサービスは第2のサービスよりも時間に敏感である。言い換えれば、第2のサービスは依然として時間に敏感であることができ、第1のサービスよりも時間に敏感ではない。
本開示の例示的な実施形態は、第1のサービスのように低いレイテンシ要件を有さない第2のサービスのために同時に送信することができる同じネットワークにおいて低いレイテンシを必要とする第1のサービスのための送信を復号する問題に対処する方法を提供する。送信機が、送信パラメータを調整することができないと判定した場合、送信機は初期制御シグナリングを必要とせずに、パンクチャバンドリングを自動的にアクティブ化することができる。パンクチャバンドリングは低レイテンシを必要とする第1のサービスのための元のデータを、元のデータと同じまたは異なって（異なるように／異なる方法で）符号化され得る元のデータの1つまたは複数の繰り返しと共に、第2のサービスのためのデータ送信の同じTTIに送信することを含む。それぞれの場合において、第1のサービスの異なる冗長バージョンまたは繰り返される同じ冗長バージョン（RV）は、第2のサービスの送信をパンクチャする。最初のサービスのデータは、2番目のサービスのデータの1つのトランスポートブロック（TB）、2つのトランスポートブロック、または2つ以上のトランスポートブロックにパンクチャできる。
2番目のサービスのデータを搬送するTTIでの低レイテンシデータの冗長送信により、NACK（Negative ACKnowledgement（否定応答））の送信と通常の再送信と通常の再送信との間の待ち時間がなくなり、低レイテンシデータのレイテンシ要件を満たしながら、低レイテンシデータを正常に復号することが許容される。これはまた、NACK（または正常に復号されたデータのためのACK）を搬送するための制御シグナリングを必要としないので、シグナリング効率を提供し、第2のサービスのTTI内の低レイテンシサービスのためのデータの繰り返しによるロバスト性を提供する。
図4〜図7は、本開示の例示的な実施形態による、低レイテンシデータのための冗長性を有するパンクチャされた送信のブロック図である。これらの例では第1のサービスの元のデータおよび繰り返しの各々が互いに複製であることができ、すなわち、同じ方法で符号化された同じデータであることができ、または各パンクチャされた部分のデータが互いに異なるバージョンであることができ、すなわち、異なって符号化されるが、復号後に復元されることができる同じ基礎となる制御データおよびユーザデータを搬送することができる。後者の場合、符号化は（0,3,2,1）の符号化リストから取ることができ、この場合、数字はインクリメンタル合成に使用される冗長バージョンに対応し、4つを超える繰り返しがある場合、追加の繰り返しは、符号化リストの始めから再び開始する。
図4の送信は、厳しいレイテンシ要件を有さない第2のサービスのための単一のTTI 400であり、厳しいレイテンシ要件を有する第1のサービスのためのデータによって4回パンクチャされる。具体的には、第1のサービスのためのデータがこの例ではURLLC PDCCH+PDCCH DMRSである制御データの元の送信405と、この例ではURLLC PDSCH+PDSCH DMRSであるユーザデータとを含む。第1のサービスのためのデータはまた、3つの繰り返し410a〜410nを含み、その各々は、この例ではURLLC PDCCH+PDCCH DMRSである制御データと、この例ではURLLC PDSCH+PDSCH DMRSであるユーザデータとを含む。図4は元の送信および3つの繰り返しを示すが、送信は図示されているものよりも多いまたは少ない繰り返しを含むことができる。元の送信と第1の繰り返しとの間の間隔、ならびに繰り返し間の間隔はf（ゼロ以上であり得る）とすることができる。言い換えると、この図には時間ギャップが示されているが、元の送信405と繰り返し410a〜410nは時間的に互いに直接隣接することができる。
図5の送信は、厳しいレイテンシ要件を有さない第2のサービスのための単一のTTI 500であり、厳しいレイテンシ要件を有する第1のサービスのためのデータによってパンクチャされる。この例では、元の送信505がこの例ではURLLC PDCCH+PDCCH DMRSである制御データと、この例ではURLLC PDSCH+PDSCH DMRSであるユーザデータとの両方を含む。図4の例とは対照的に、図5の例では、制御データは再送信されず、ユーザデータのみが再送信される（510a〜510n）。さらに、元の送信および繰り返しは時間的に互いに直接隣接しており、周波数において、元の送信および繰り返しは、TTI 500内の特定の時間において周波数リソースのすべてを占有するわけではなく、TTI 500のために使用される周波数リソースの外側に広がる。
図5の例は、第1のサービスのための送信のために周波数ホッピングを使用しない。対照的に、図6の例は、第1のサービスのために周波数ホッピングを使用する。それ以外は、図6の例は図5の例と同じであり、すなわち、元の制御データは再送信されず、ユーザデータは再送信され、元の送信および繰り返しは、単一のパンクチャされた部分のみが存在するように、互いに直接隣接する。したがって、図6では、第2のサービスのためのTTI 600が元の送信605および1つまたは複数の繰り返し610a〜610nを有する単一のパンクチャされた部分を含む。周波数ホッピングのアクティブ化または非アクティブ化は、第1のサービスのPDCCHによって搬送されるダウンリンク制御情報（DCI）内のフィールドによって搬送される、またはより高いレイヤパラメータによって構成され得る。
図7の送信は図6の例のように、周波数ホッピングを使用し、図5および図6の両方の例のように、元の制御データは再送信されず、ユーザデータは再送信され、元の送信および繰り返しは、単一のパンクチャされた部分のみが存在するように、互いに直接隣接する。しかし、この例では、元の送信705および1つまたは複数の繰り返し710a〜710nがTTI 700に割り振られた周波数リソース内に含まれる。
図4〜7はパンクチャされたデータのための特定の時間-周波数リソースの使用を示すが、他の時間-周波数リソースを使用することができる。図4の例では、冗長送信が冗長送信間の第2のサービスのためのデータをインターリーブする代わりに、時間的に互いに直接隣接し、元々送信されたデータに直接隣接することができる。図5〜7の例では、低レイテンシサービスのための元のおよび冗長送信が図4の図解と同様に、第2のサービスのための送信と時間的にインターリーブすることができる。
さらに、冗長送信の数は図示された例から逸脱することができ、本開示は、より少ないまたはより多い数の冗長送信を使用して実施されることができる。最後に、元の送信のために使用される時間リソースおよび／または周波数リソースの特定の量、ならびに低レイテンシサービスのための繰り返しは、図4〜7に示されるものよりも大きくても小さくてもよい。
図4〜7に示されるパンクチャリングをサポートするために送信ノードおよび受信ノードによって実行される方法の詳細を説明する前に、例示的な送信ノードおよび受信ノードの高レベルの説明が以下の本開示のプロセスの実装の詳細を読者が理解するのを助けるために、図8に関連して提示される。図示されるように、送信ノード805は受信ノード850に情報を送信することができ、受信ノード850は、送信ノード805に情報を送信することができる。これを達成するために、送信ノード805は送受信器（トランシーバ）810およびメモリ820に結合されたプロセッサ815を含み、受信ノード850は、送受信器855およびメモリ865に結合されたプロセッサ860を含む。送受信器810および855は、それぞれ、送信ノード805および受信ノード850に無線インターフェースを提供する。プロセッサ815および860は、マイクロプロセッサ、特定用途向け集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）などの任意のタイプのプロセッサとすることができる。
メモリ865は、ソフト合成のための異なる送信を記憶するために使用されるHARQバッファ870を含む。メモリ820および865は、任意のタイプのメモリであってもよく、一時記憶および非一時記憶の両方を含むことができる。非一時的メモリは、関連するプロセッサによって実行されると、プロセッサに本明細書で説明される方法を実行させるコードを含むことができる。非一時的メモリは、コードを記憶するコンピュータ可読媒体を含むことができる。図8は送受信器の使用を示すが、実装に応じて、別個の送信器および受信器を提供することができる。図8は送信ノード805および受信ノード850の高レベル図であり、当業者はそれぞれが、入力装置、他のデバイスへのインターフェース、1つまたは複数のアンテナ、1つまたは複数のディスプレイなどの追加の構成要素を含むことができることを認識するのであろう。
以下の説明は送信ノード805が基地局（例えば、eNB、gNB、または任意の他のタイプの基地局）であり、受信ノード850がUE（ユーザ装置）であると仮定するが、本開示は送信ノード805がUEであり、受信ノード850が基地局である場合にも使用され得る。この場合、第1および第2のサービスのためのデータの送信は少なくとも2つのUEからの送信を含み、すなわち、UEのうちの1つは第1のサービスのためのデータを送信し、別のUEまたは複数の他のUEはTTI中に第2のサービスのためのデータを送信する。第1のサービスのためのデータの1つのUEによる送信は第2のサービスのための他のUEによる送信と調整されることができ、その結果、時間および／または周波数において重複がないか、または最小限の重複である。第1のサービスのためのデータの1つのUEによる送信が時間および／または周波数において、他のUEのうちの少なくとも1つによる送信と重複するように、調整されていない送信を使用することもできる。
送信ノード805によって実行される方法は最初に、図9の高レベルフローチャートに関連して提示され、次に、詳細は図10の説明に関連して説明される。最初に、送信ノード805は、第1のサービスのためのデータが、第2のサービスのためのデータが送信される期間中に送信されることを決定する（ステップ905）。ここで、第1のサービスのためのデータは、第2のサービスのためのデータよりも低レイテンシを必要とする。次いで、送信ノード805は、送信または受信の条件を決定し（ステップ910）、決定された送信または受信の条件に基づいて、第1のサービスの送信を調整することを決定する（ステップ915）。以下で詳細に説明するように、これらの調整は、送信電力、変調、および／または符号化を調整すること、ならびにパンクチャバンドリングを使用することであり得る。説明のためだけに、この例では、送信調整が少なくともパンクチャバンドリングの使用を含むと仮定する。したがって、第2のサービスのためのデータが送信される間に、送信ノード805は、当該期間中に、第1のサービスのためのデータを送信し（送信ノード805は当該期間中に、第1のサービスのためのデータを送信し、第2のサービスのためのデータが送信され）、調整は、第1のサービスのためのデータの元のセットと、第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとを含むことを含む（ステップ920）。
ここで図10のフローチャートを参照すると、送信ノード805のプロセッサ815は最初に、送受信器810を介して、第2の、非低レイテンシサービスのためのデータの送信のための期間中に、送信のための低レイテンシサービスのためのデータを受信する（ステップ1005）。次いで、送信ノード805のプロセッサ815は、送信および／または受信の条件が許容可能であるかどうかを判定する（ステップ1010）。この判定は、信号対雑音比（SNR）、信号対干渉比（SIR）、ブロック誤り率（BLER）などを含む任意の数の要因に基づくことができる。さらに、この判定を行うために使用される情報は、送信ノードに送信／受信状態を報告するための従来のフィードバック技術を使用して得ることができる。
プロセッサ815が、条件が許容可能であると判定した場合（判定ステップ1010からの「Yes」パス）、プロセッサは低レイテンシサービスのためのデータの単一インスタンスを用いて第2の送信をパンクチャし、送受信器810を使用して第1および第2のサービスの両方のためのデータを送信する（ステップ1015）。このパンクチャリングは、（送信ノードが基地局であるかUEであるかに応じて）図3Aおよび図3Bに示されるものと同様の形態をとることができる。パンクチャリングは図3Aおよび図3Bに示されるのと同じ時間および／または周波数リソースを占有する必要はなく、第1のサービスのためのデータは図3Aおよび図3Bに示されるものとは異なる時間および／または周波数位置で第2のサービスのためのデータにパンクチャされる。この送信の重要性は、送信における第1のサービスのデータに対する冗長性を含まないことである。さらに、上述のように、送信ノードが基地局である場合、第1のサービスおよび第2のサービスのために送信されているデータの間には最小の重複（オーバーラップ）が存在するか、または重複が存在しないが、送信ノードがUEである場合、時間および／または周波数において重複が存在し得る。
送信ノード805のプロセッサ815が送信および／または受信状態が許容可能でないと判定した場合（判定ステップ1010からの「No」パス）、プロセッサ815は、低レイテンシサービスをサポートするために送信調整が利用可能であるかどうかを判定する（ステップ1020）。送信調整は、送信電力の増加、変調および／または符号化の変更などを含むことができる。利用可能な送信パラメータ調整がある場合（判定ステップ1020からの「Yes」パス）、送信ノードは、送受信器810を介して、調整された送信パラメータを使用して、第2のサービスのためのデータの送信においてパンクチャされた低レイテンシサービスのためのデータを送信する（ステップ1025）。
送信ノード805がすでに最大電力で送信しているか、またはすでに最もロバストな変調および／または符号化を採用しており、したがって、送信調整が利用可能でない状況が起こり得る。これらの状況は例えば、UEが基地局のセルのエッジにあるとき、高周波数の使用のためにカバレージがスポットであるとき、および望ましくない干渉があるときに起こり得る。これらおよび他の同様の状況では送信調整は利用可能ではないが、第1のサービスの厳しいレイテンシ要件のために、送信ノードがこのデータを受信ノード850に提供することを試みることが依然として必要であり、このことは本開示では第1のサービスのための元のデータと、第1のサービスのための元の1つまたは複数の冗長バージョンとを、単一の送信、たとえば、第2のサービスの単一のTTIで送信することによって達成される。
低レイテンシサービスをサポートするために送信パラメータ調整が利用可能でない場合（判定ステップ1020からの「No」パス）、プロセッサ815は、パンクチャバンドリングを使用して第1のサービスのためのデータを送信することを決定する。具体的には、プロセッサ815が、第1のサービスのための、元の送信と、元の送信の1つまたは複数の繰り返しとを、第2のサービスのための送信にパンクチャする（ステップ1030）。これは、図4〜7に関連して上述した例のいずれか、ならびにその変形を使用して達成することができる。したがって、実装に応じて、1つまたは複数の繰り返しは、制御データおよびユーザデータの両方を含むことができ、またはユーザデータのみを含むことができる。
例示的な実施形態によれば、送信ノード805はTTIにおけるパンクチャバンドリングの存在を明示的にシグナリングすることができ、受信ノード850はブラインド検出を実行することができ、および／または受信ノード850は、ブラインド検出を容易にするために別個のシグナリングを使用して事前設定されることができる。
明示的インジケータ（指標）は、様々な異なる方法で実装することができる。明示的インジケータは第1のサービスのための元のデータの送信に含まれるが、第1のサービスのための繰り返しには含まれないパンクチャリングバンドルインジケータ（PBI）とすることができる。これにより、受信ノードは第1のサービスのための元のデータの送信と、繰り返しとを区別することができ、受信ノードは、元のデータの送信と、繰り返しのうちの1つまたは複数とを使用して、ソフト合成を実行することができる。あるいは、PBIがミニスロットで搬送され得る制御チャネルから送信され得る。PBIはまた、時間／OFDMシンボル／スロットオフセット、PRB（物理リソースブロック）オフセット、または各パンクチャバンドル送信のためのそのような情報のシーケンスのような、次のパンクチャされたリソースブロックに関する情報を搬送して、受信ノードが第1のサービスのための受信された送信を見つけることを支援することができる。
明示的インジケータはまた、第1のサービスのためのパンクチャされたデータのサイズ、すなわち、第1のサービスのための元の送信のためのデータのサイズ、および第2のサービスのためのTTI内の繰り返しのすべてに関する情報を含むことができる。本明細書ではPUNCTURE_BUNDLE_sizeと呼ばれるこのサイズ情報は、第2のサービスのための送信のトランスポートブロック（TB）サイズ、URLLCトランスポートブロックサイズ、チャネル条件などに基づいて計算することができる。PUNCTURE_BUNDLE_SIZEは、図4の例では4で、第1のサービスのための元の送信と繰り返しの量に等しくすることができる。したがって、第1のサービスのためのデータの元の送信と、単一の無線リンク制御（RLC）サービスデータユニット（SDU）から生じる繰り返しとは、第2のサービスのための同じTTIで連続的に送信され、HARQプロセス番号0を有する。
明示的インジケータは、第1のサービスのためのデータが第2のサービスのTTIにどのようにパンクチャされたか、第1のサービスのための元のデータの送信および繰り返しの符号化方式、およびPUNCTURE_BUNDLE_size情報に類似するサイズ情報を受信ノード850に通知する情報をさらに含むことができる。この情報は、ここではパンクチャバンドリング・フィールド（punctureBundlingField）と呼ばれる。一実施形態ではこの情報が第1のサービスのためのデータの元の送信および／または繰り返しのうちの1つまたは複数が受信ノード850によって受信されなかったときなど、パンクチャインジケータの誤検出に関する問題を処理するために、第1のサービスのためのデータの元の送信と繰り返しとの両方に含めることができ、したがって、受信ノード850は元の送信および繰り返しの量に依存することができない。したがって、例えば、受信ノード850が第1のサービスのためのデータおよび第1の繰り返しを受信せず、第2の繰り返しを検出した場合、受信ノード850は、第2の繰り返しおよび任意のさらなる繰り返しを復号することができる（この場合、ソフト合成を実行することができる）。さらに、受信ノード850は第1のサービスのためのデータの元の送信および第1の繰り返しを復号しようと試みるために、以前に受信された送信の部分を調べることができる。
PBIは、PUNCTURE_BUNDLE_SIZEおよびpunctureBundlingFieldと組み合わせて、PUNCTURE_BUNDLE_SIZEと組み合わせて、ならびにパンクチャリング、パンクチャされたエリア、および／または符号化スキームに関連する任意の情報と組み合わせて、それ自体で使用することができる。
明示的なインジケータを提供することに加えて、またはその代わりに、送信ノード805は例えば、無線リソース制御（RRC）メッセージ、MAC（媒体アクセス制御）CE（制御要素）、または他の同様のメッセージングを介して、受信ノード850を設定して、同じPRBおよび可能な限り早いOFDMシンボルを使用するリソースなど、次に送信されるリソースの準静的調整を事前設定することができる。代替的にまたは追加的に、このメッセージングは最初に周波数ホッピングパターンを事前設定することができ、PBIは周波数ホッピングパターンインデックスに対応することができ、または周波数ホッピングを取り消すことができる。
パンクチャバンドリングのブラインド検出は、受信ノード850がパンクチャバンドリングを認識する能力を高めるように実施することができる。例えば、第1のサービスのための元のデータおよび繰り返しの各々の送信は同じ冗長バージョンを使用することができ、すなわち、各々は、所定の時間ウィンドウ内で同じ方法で符号化される。したがって、受信ノード850のプロセッサ860は、第1のデータサービスのための元の送信と、チャネル等化後の同じ信号値を有する繰り返しのQAM（直交振幅変調）シンボルのシーケンスによって、パンクチャバンドリングを検出することができる。したがって、パンクチャされたエリアは繰り返しパターンを含み、したがって、受信ノード850のプロセッサ860は、信号処理に基づいて相関を実行して、第2のサービスのサブフレームスロットなど、事前定義された時間ウィンドウ内のトランスポートブロック長およびバンドリング数に関して、パンクチャバンドルされた送信の存在を推定することができる。第1のサービスおよび1つまたは複数の反復のための元のデータの送信のために同じ冗長バージョンを使用することの別の利点は信号がQAMシンボルレベルで結合され得ることであり、これは、バンドリング利得も達成しながら、受信の複雑さを低減する。
補助ブラインド検出は、受信ノード850に再設定情報を提供して、使用可能なバンドリングパラメータの一部またはほとんどすべてを指定することができる。再設定情報は、無線リソース制御（RRC）メッセージまたは他のL1/L2（レイヤ1またはレイヤ2）シグナリングメッセージなどにおいて、第1のサービスのためのデータの送信とは別に送信される。パンクチャバンドリングの潜在的な存在の通知は、第1のサービスを使用している受信ノード850にセミパーシステントな（半永続的な）変更命令を送信することによって達成することができる。
図10に戻ると、明示的なインジケータが使用される場合、それは、上述の方法でパンクチャされたTTIに含まれる（ステップ1035）。明示的なインジケータがサポートされていない場合、このステップは省略される。送信ノード805のプロセッサ815は次に、送受信器810を使用して、パンクチャされたTTIを受信ノード850に送信する（ステップ1040）。パンクチャされたTTIの送信は、送信ノード805が基地局であるかUEであるかに応じて変化する。送信ノード805が基地局である場合、TTIの送信は、第1のサービスおよび第2のサービスの両方のためのデータを含むことができる。同じことが、送信ノード805がUEであるときに起こり得るが、UEが第1のサービスのためのデータのみを送信し、1つまたは複数の他のUEが第2のサービスのためのデータを送信する可能性がより高いシナリオであり、そのすべてが第2のサービスのTTI中に起こる。
受信ノード850がTTIを受信し、復号しようと試みた後のある時点で、受信ノード850は、第1のサービスのためのHARQフィードバック、すなわちACKまたはNACKを送信ノード805に送信する（ステップ1045）。例示的な実施形態によれば、HARQフィードバックはパンクチャバンドル、すなわち、第1のサービスのための元のデータの送信、およびパンクチャバンドル内のすべての繰り返しのための単一のメッセージである。対照的に、従来のHARQ技術は、最初に送信されたデータおよび各繰り返しのための別個のHARQフィードバックを伴う。したがって、本開示のパンクチャバンドリングは、第1のサービスの厳しいレイテンシ要件を達成するのに役立つだけでなく、パンクチャバンドルにおける繰り返しの数に応じて、少なくとも1つ、場合によってはそれ以上のHARQフィードバック送信を削除することによってオーバヘッドシグナリングを低減する。低減されたシグナリングはHARQをサポートするために消費される無線リソースの数を低減することによって、エアインタフェース効率を向上させるとともに、追加のHARQフィードバック送信によって引き起こされ得る干渉を低減する。
受信ノード850によって実行される方法は最初に、図11のハイレベルフローチャートに関連して提示され、次に、図12の説明に関連して詳細を説明する。最初に、受信ノード850は第2のサービスのためのデータの送信に対応する期間の間に送信を受信し（ステップ1105）、受信した送信が第1および第2のサービスのデータを含むことを決定する（ステップ1110）。次に、受信ノード850は受信した送信が第1のサービスのための元のセットと、第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとを含むことを決定し（ステップ1115）、受信ノードは元のセットを単独で、または第1のサービスのための元のセットの少なくとも1つの繰り返しの1つまたは複数の繰り返しと組み合わせて使用して、第1のサービスのためのデータの復号を試行する（データを復号しようと試みる）（ステップ1120）。
ここで図12を参照すると、受信ノード850のプロセッサ860は最初に、送受信器855を介して、第2のサービスのためのTTIの送信を受信する（ステップ1205）。次に、プロセッサ850は、受信された送信が第1のサービスのためのデータでパンクチャされたかどうかを判定する（ステップ1210）。この判定は、多くの異なる方法で実行することができる。例えば、CRC（Cyclic Redundancy Check（巡回冗長検査））ビットマップを使用して、パンクチャされた部分の後に送信されるコードブロックを示すことができ、一例では、パンクチャされたコードブロックに先行するコードブロックに対してCRC=00000が使用され、パンクチャされたコードブロックの後に続くコードブロックを示すためにCRC=01000が使用される。別の例では、送信ノード805がDCIを使用する第1のサービスのための送信を、スケジュールされたURLLC送信のための意図された受信ノード850のRNTI（無線ネットワーク一時アイデンティティ）に一致するCRCビットマップに割り当てるなど、受信ノード850にブランキング割り当てを提供することができる。送信ノード805はまた、第2の送信のための時間-周波数リソースの少なくとも一部がパンクチャされることを示すブランキングインジケータをTTI中に含めることができる。例えば、受信ノード850は、RRCメッセージを介して、特定の基準信号、例えばURLLC PDCCH DMRSが検出された場合、パンクチャリングを検出するように構成することができる。さらに別の例では、受信ノード850が別々の送信のうちのどれがパンクチャされたかという仮説を生成するために、第2のサービスの2つの別々の送信を比較することなどによって、パンクチャされたデータの存在をブラインドで検出することができる。
プロセッサ860が第2のサービスのためのTTIのパンクチャリングがないと判定した場合（判定ステップ1210からの「No」パス）、プロセッサ860は、第2のサービスのための送信のデータを復号しようと試みる（ステップ1215）。プロセッサ860がパンクチャリングがあると判定した場合（判定ステップ1215からの「Yes」パス）、プロセッサ860は、第1のサービスのための元のデータの送信の位置および繰り返し（の位置）を決定する（ステップ1220）。受信ノード850が第1のサービスのためのデータの位置を決定する方法はネットワークが明示的なインジケータ、ブラインド検出、または補助ブラインド検出を実施するかどうかに依存し、これらの各々は、上述の方法で実施することができる。
次に、受信ノード850のプロセッサ860は、第1のサービスのためのデータの元の送信の復号を試行する（ステップ1225）。正常に復号した場合（成功した場合）（判定ステップ1230からの「Yes」パス）、プロセッサ860は繰り返しを廃棄する（ステップ1235）、なぜなら、それらは第1のサービスのためのデータを復号する必要がなかったためである。正常に復号するかどうかは、CRC（巡回冗長検査）を検査することによるなど、従来の技術に基づくことができる。
復号が成功しなかった場合（判定ステップ1230からの「No」パス）、プロセッサ860は、第1のサービスのための元のデータの送信および1つまたは複数の繰り返しを使用して復号を試みる（ステップ1240）。これは、プロセッサ860が最初に元のデータおよび第1の繰り返しを使用して復号しようと試み、これが成功しない場合、プロセッサ860は元のデータならびに第1および第2の繰り返しを使用して復号しようと試みるなどの反復プロセスとすることができる。プロセッサ860が、第1のサービスのためのデータを正常に復号した場合（判定ステップ1245からの「Yes」パス）、プロセッサ860は使用されていない繰り返しを廃棄し、元の送信と繰り返しに対して正常に復号したことを示す単一のHARQフィードバックを送信する（ステップ1250）。プロセッサ860が、元の送信およびすべての繰り返しを使用して、第1のサービスのためのデータを正常に復号しなかった場合（判定ステップ1245からの「No」パス）、プロセッサ860は元の送信および繰り返しを廃棄し、元の送信と全ての繰り返しに対して復号に失敗したことを示す単一のHARQフィードバックを送信する（ステップ1255）。実装に応じて、送信ノード805は再送信が第1のサービスの厳しいレイテンシ要件を満たすことができると仮定して、元のデータのみとして、または1つまたは複数の繰り返しと共に、第1のサービスのためのデータを再送信することを試みることができる。
ダウンリンクデータの送信に関連して例示的な実施形態を説明した。しかしながら、本開示は、アップリンク送信にも等しく適用可能であり、その場合、図3Aに関連して上述したように、第1のサービスのためのパンクチャされたデータは、ダウンリンクで送信されるPDCCHはなくPUSCHになる。
例示的な実施形態は第2のサービスのための第1のサービスパンクチャリングデータのためのデータを用いて説明されたが、パンクチャリングがない場合にも、本開示のバンドルパンクチャリングを使用することができる。さらに、URLLCが第1のサービスであり、MBBが第2のサービスである例示的な実施形態について説明したが、本開示は大規模な（massive）マシンタイプ通信（mMTC）、マルチメディアブロードキャストマルチキャストサービス（MBMS）など、同じ低レイテンシ要件を有さない任意のタイプの低レイテンシサービスの送信、および任意の他のタイプのサービスのパンクチャリングに等しく適用可能である。
例示的な実施形態は、TTIである第2のサービスの送信のための期間を用いて説明されてきたが、TTIはサブフレーム、スロット、またはミニスロットに対応することができ、したがって、サブフレーム、スロット、またはミニスロットという用語は上記の説明においてTTIの代わりに使用されることができることを認識されたい。
したがって、本明細書で開示される実施形態は、最初に送信されたデータでパンクチャされた送信に繰り返し（反復）を含めることによって、厳しい低レイテンシ要件を有する第1のサービスのためのデータの復号を可能にするための無線通信システム、装置、および方法を提供する。この説明は、本開示を限定することを意図していないことを理解されたい。反対に、例示的な実施形態は、本開示の精神および範囲に含まれる代替処理、修正形態、および均等物を包含することを意図している。さらに、例示的な実施形態の詳細な説明では、本開示の包括的な理解を提供するために、多数の特定の詳細が記載される。しかしながら、当業者は、様々な実施形態がそのような特定の詳細なしに実施され得ることを理解するのであろう。
任意の適切なステップ、方法、または機能は例えば、上記の図のうちの1つまたは複数に示された構成要素および機器によって実行され得るコンピュータプログラム製品を介して実行され得る。例えば、メモリ820および865は、コンピュータプログラムを格納することができるコンピュータ可読手段を含むことができる。コンピュータプログラムはプロセッサ815および860（ならびに送受信器810およびメモリ820ならびに送受信器855およびメモリ865などの任意の動作可能に結合されたエンティティおよびデバイス）に、本明細書で説明する実施形態による方法を実行させる命令を含むことができる。したがって、コンピュータプログラムおよび／またはコンピュータプログラム製品は、本明細書で開示される任意のステップを実行するための手段を提供することができる。
任意の適切なステップ、方法、または機能は、1つまたは複数の機能モジュールまたは回路を介して実行され得る。各機能モジュールはソフトウェア、コンピュータプログラム、サブルーチン、ライブラリ、ソースコード、または、例えば、プロセッサによって実行される任意の他の形態の実行可能命令を備えてもよい。いくつかの実施形態では、各機能モジュールがハードウェアおよび／またはソフトウェアで実装されてもよい。たとえば、1つまたは複数のまたはすべての機能モジュールは、プロセッサ815および／または860によって、場合によってはメモリ820および／または865と協働して実装され得る。したがって、プロセッサ815および／または860ならびにメモリ820および／または865はプロセッサ815および／または860がメモリ820および／または865から命令をフェッチし、フェッチされた命令を実行して、それぞれの機能モジュールが本明細書で開示される任意のステップまたは機能を実行することを可能にするように構成され得る。
本例示的実施形態の特徴および要素は特定の組合せで実施形態に記載されているが、各特徴または要素は実施形態の他の特徴および要素なしで、または本明細書に開示された他の特徴および要素を伴うまたは伴わない様々な組合せで、単独で使用することができる。本出願で提供される方法またはフローチャートはコンピュータまたはプロセッサによる実行のために、コンピュータ可読記憶媒体で有形に具現化されたコンピュータプログラム、ソフトウェア、またはファームウェアで実装され得る。
本明細書は、開示された主題の例を使用して、任意のデバイスまたはシステムを作製および使用すること、ならびに任意の組み込まれた方法を実行することを含めて、任意の当業者がそれを実施することを可能にする。主題の範囲は、特許請求の範囲によって定義され、当業者に想起される他の例を含むことができる。そのような他の例は、特許請求の範囲内にあることが意図される。

Claims (31)

  1. 送信ノードにおいて実施される方法であって、前記方法は、
    第1のサービスのためのデータが、第2のサービスのためのデータが送信される期間中に送信されることを決定することであって、前記第1のサービスのためのデータは前記第2のサービスのためのデータよりも低レイテンシを必要とすることと、
    送信または受信の条件を決定することと、
    前記決定された送信または受信の条件に基づいて、前記第1のサービスの送信を調整することを決定することと、
    前記期間中に前記第1のサービスのためのデータと前記第2のサービスのためのデータを送信することであって、前記第1のサービスの送信の調整は、前記第1のサービスのためのデータの元のセットと、前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとを含む、ことと、
    受信ノードから、前記受信ノードが前記第1のサービスのためのデータを正常に復号したか否かに関して、フィードバックを受信することであって、前記フィードバックは、単一の送信に含まれ、前記データの元のセットと前記少なくとも1つの繰り返しの両方に関連する、方法。
  2. 請求項1に記載の方法であって、前記送信ノードは基地局であり、前記第1および第2のサービスのためのデータの送信は前記第1および第2のサービスのためのデータが時間または周波数において重複しないように、時間または周波数においてインターレースされる、方法。
  3. 請求項1に記載の方法であって、前記送信ノードは第1のユーザ装置であり、第2のユーザ装置は、前記第1のユーザ装置による前記第1のサービスのためのデータの送信と時間または周波数が重複する前記第2のサービスのためのデータを送信する、方法。
  4. 請求項1に記載の方法であって、前記第1のサービスのための送信の調整は、前記第1のサービスのためのデータの送信に使用される送信電力または符号化を調整することを含む、方法。
  5. 請求項1に記載の方法であって、前記第1のサービスのためのデータの元のセットと前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しは同じである、方法。
  6. 請求項1に記載の方法であって、前記第1のサービスのためのデータの元のセットと前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとは、異なって符号化される、方法。
  7. 請求項1に記載の方法であって、前記第1のサービスのためのデータの元のセットと前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しは、前記期間内で時間的に互いに直接隣接して送信される、方法。
  8. 請求項1に記載の方法であって、前記第2のサービスのためのデータが前記第1のサービスのためのデータの元のセットと前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとの間の時間で送信されるように、前記第1のサービスのためのデータの元のセットと前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しは、前記期間内で時間的に分離される、方法。
  9. 請求項1に記載の方法であって、前記期間中の前記送信における前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しの存在の明示的なインジケータを含むことをさらに含む、方法。
  10. 請求項9に記載の方法であって、前記明示的なインジケータは、前記データの元のセットと前記少なくとも1つの繰り返しのサイズに関する情報を含む、方法。
  11. 請求項9に記載の方法であって、前記明示的なインジケータは、前記期間中に前記データの元のセット前記と少なくとも1つの繰り返しがどのように送信されるかに関する情報、および、前記データの元のセットと前記少なくとも1つの繰り返しを符号化するために使用される少なくとも符号化方式に関する情報を含む、方法。
  12. 請求項1に記載の方法であって、前記期間中に前記第1および第2のサービスのためのデータの送信とは別の送信を介して再設定情報を受信ノードに提供することをさらに含む、方法。
  13. 請求項1に記載の方法であって、前記第1のサービスのためのデータの元のセットは、制御部分とユーザデータ部分とを含み、前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しは、前記第1のサービスのためのデータの元のセットの前記制御部分ではなく、前記ユーザデータ部分を繰り返す、方法。
  14. 請求項1に記載の方法であって、前記第1のサービスはURLLC（Ultra-Reliable Low Latency Communication）サービスであり、前記第2のサービスは、MBB（Mobile Broadband）サービスまたは拡張MBBサービスである、方法。
  15. 請求項1に記載の方法であって、前記第1のサービスのためのデータの元のセットと前記少なくとも1つの繰り返しは、前記データの元のセットと前記少なくとも1つの繰り返しが異なる周波数のセットを使用して送信されるように、周波数ホッピングを使用して送信される、方法。
  16. 請求項1に記載の方法であって、前記期間は、前記第2のサービスの送信時間隔（TTI）、スロット、またはミニスロットである、方法。
  17. 受信ノードにおいて実施される方法であって、前記方法は、
    ある期間中に送信を受信することと、
    前記送信が第1のサービスのためのデータおよび第2のサービスのためのデータを含むことを決定することであって、前記第1のサービスのためのデータは、前記第2のサービスのためのデータよりも低レイテンシを必要とする、ことと、
    前記送信が前記第1のサービスのためのデータの元のセットと、前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとを含むことを決定することと、
    前記第1のサービスのためのデータの復号を試行することと、
    前記受信ノードが前記第1のサービスのためのデータを正常に復号したか否かに関して、フィードバックを送信ノードへ送信することであって、前記フィードバックは、単一の送信に含まれ、前記データの元のセットと前記少なくとも1つの繰り返しの両方に関連する、方法。
  18. 請求項17に記載の方法であって、前記試行することは、前記第1のサービスのためのデータの元のセットのみを使用して、前記第1のサービスのためのデータの復号を最初に試行することを含む、方法。
  19. 請求項18に記載の方法であって、前記第1のサービスのためのデータの元のセットのみを使用した前記第1のサービスのためのデータの復号の試行が成功しない場合、前記受信ノードは、前記第1のサービスのためのデータの元のセットと前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとを使用して前記第1のサービスのためのデータの復号を試行する、方法。
  20. 請求項17に記載の方法であって、前記受信した送信は、前記第1および第2のサービスのためのデータが時間または周波数において重複しないように、時間または周波数においてインターレースされた、前記第1および第2のサービスのためのデータを含む、方法。
  21. 請求項17に記載の方法であって、前記受信した送信は、2つの送信ノードからの送信の組み合わせであり、前記第2のサービスのためのデータは、第1のユーザ装置による前記第1のサービスのためのデータの送信と時間または周波数で重複する、方法。
  22. 請求項17に記載の方法であって、前記送信が前記第1および第2のサービスのためのデータを含むことを決定することは、前記送信における明示的なインジケータに基づく、方法。
  23. 請求項22に記載の方法であって、前記明示的なインジケータは、前記データの元のセットと前記少なくとも1つの繰り返しのサイズに関する情報を含む、方法。
  24. 請求項22に記載の方法であって、前記明示的なインジケータは、前記期間中に前記データの元のセット前記少なくとも1つの繰り返しがどのように送信されるかに関する情報、および、前記データの元のセットと前記少なくとも1つの繰り返しを符号化するために使用される少なくとも符号化方式に関する情報を含む、方法。
  25. 請求項17に記載の方法であって、前記送信が前記第1および第2のサービスのためのデータを含むことを決定することは、
    前記受信した送信においてチャネル等化を実行することと、
    チャネル等化の後に、前記受信した送信の異なる部分が同じ信号値を有するシンボルのセットを含むかを判定することを含む、方法。
  26. 請求項17に記載の方法であって、前記送信が前記第1および第2のサービスのためのデータを含むことを決定することは、前記期間中に、前記第1および第2のサービスのためのデータの送信とは別に送信を介して送信ノードから受信した再設定情報に基づく、方法。
  27. 請求項17に記載の方法であって、前記第1のサービスはURLLC（Ultra-Reliable Low Latency Communication）サービスであり、前記第2のサービスは、MBB（Mobile Broadband）サービスまたは拡張MBBサービスである、方法。
  28. 請求項17に記載の方法であって、前記第1のサービスのためのデータの元のセットと前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しは、前記データの元のセットと前記少なくとも1つの繰り返しが異なる周波数のセットを使用して送信されるように、周波数ホッピングを使用して送信される、方法。
  29. 無線送受信器と処理回路とを備える送信ノードであって、
    前記処理回路は、
    第1のサービスのためのデータが、第2のサービスのためのデータが送信される期間中に送信されることを決定し、ここで、前記第1のサービスのためのデータは前記第2のサービスのためのデータよりも低レイテンシを必要とし、
    送信または受信の条件を決定し、
    前記決定された送信または受信の条件に基づいて、前記第1のサービスの送信を調整することを決定し、
    前記期間中に前記第1のサービスのためのデータと前記第2のサービスのためのデータを送信し、ここで、前記送信は、前記第1のサービスのためのデータの元のセットと、前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとを含み、
    受信ノードから、前記受信ノードが前記第1のサービスのためのデータを正常に復号したか否かに関して、フィードバックを受信し、ここで、前記フィードバックは、単一の送信に含まれ、前記データの元のセットと前記少なくとも1つの繰り返しの両方に関連する、ように構成される、送信ノード。
  30. 無線インターフェースと、処理回路とを備える受信ノードであって、
    前記処理回路は、
    ある期間中に送信を受信し、
    前記送信が第1のサービスのためのデータおよび第2のサービスのためのデータを含むことを決定し、ここで、前記第1のサービスのためのデータは、前記第2のサービスのためのデータよりも低レイテンシを必要し、
    前記送信が前記第1のサービスのためのデータの元のセットと、前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとを含むことを決定し、
    前記第1のサービスのためのデータの復号を試行し、
    前記受信ノードが前記第1のサービスのためのデータを正常に復号したか否かに関して、フィードバックを送信ノードへ送信し、ここで、前記フィードバックは、単一の送信に含まれ、前記データの元のセットと前記少なくとも1つの繰り返しの両方に関連する、ように構成される、受信ノード。
  31. 少なくとも1つのプログラマブルプロセッサに、請求項1から28のいずれか1項に記載の方法を実行させるためのコンピュータ可読命令を含むコンピュータプログラム。
JP2019552553A 2017-03-23 2018-03-19 第２のサービスの送信における第１のサービスのためのデータのパンクチャバンドリング Active JP6955576B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CNPCT/CN2017/077810 2017-03-23
CNPCT/CN2017/077810 2017-03-23
PCT/EP2018/056819 WO2018172245A1 (en) 2017-03-23 2018-03-19 Puncture bundling of data for a first service in a transmission of a second service

Publications (2)

Publication Number Publication Date
JP2020516149A JP2020516149A (ja) 2020-05-28
JP6955576B2 true JP6955576B2 (ja) 2021-10-27

Family

ID=61692003

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019552553A Active JP6955576B2 (ja) 2017-03-23 2018-03-19 第２のサービスの送信における第１のサービスのためのデータのパンクチャバンドリング

Country Status (8)

Country Link
US (1) US10659198B2 (ja)
EP (2) EP3602878B1 (ja)
JP (1) JP6955576B2 (ja)
CN (2) CN110637429B (ja)
BR (1) BR112019019622B1 (ja)
MX (1) MX2019011072A (ja)
PL (1) PL3602878T3 (ja)
WO (1) WO2018172245A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018172249A1 (en) 2017-03-23 2018-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Configuring puncture bundles of data for a first service in a transmission of a second service
US11464061B2 (en) * 2017-06-23 2022-10-04 Beijing Xiaomi Mobile Software Co., Ltd. Time-frequency resource preemption determining method and device, and user equipment
JP6955638B2 (ja) * 2017-10-27 2021-10-27 京セラ株式会社 共通の通信リソースを使用するｎｂ（ｎａｒｒｏｗｂａｎｄ）装置および同じ場所に配置されたｍｂｂ（ｍｏｂｉｌｅ ｂｒｏａｄｂａｎｄ）装置へのデータ送信の制御情報
US11477760B2 (en) * 2019-12-19 2022-10-18 Qualcomm Incorporated Frequency diversity techniques for single frequency networks

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2007020996A1 (ja) 2005-08-19 2009-03-26 パナソニック株式会社 無線通信装置および無線通信方法
KR20100073976A (ko) * 2008-12-23 2010-07-01 엘지전자 주식회사 상향링크 전송 전력을 제어하는 방법 및 이를 위한 장치
US9667713B2 (en) * 2011-03-21 2017-05-30 Apple Inc. Apparatus and method for managing peer-to-peer connections between different service providers
CN104702702B (zh) * 2012-01-11 2018-03-23 北京奇虎科技有限公司 一种数据下载系统及方法
CN103402219B (zh) * 2013-07-01 2016-03-23 北京航空航天大学 一种基于tdma数据链异构网的端到端时延的测量与优化方法
US10117268B2 (en) * 2014-09-22 2018-10-30 Qualcomm Incorporated Ultra-low latency LTE downlink frame structure
US10104683B2 (en) * 2015-02-06 2018-10-16 Qualcomm Incorporated Parallel low latency awareness
WO2017029265A1 (en) 2015-08-14 2017-02-23 Telefonaktiebolaget Lm Ericsson (Publ) System information broadcasting in a wireless network
US11129152B2 (en) 2016-02-04 2021-09-21 Lg Electronics Inc. Method and user equipment for receiving dowlink control information, and method and base station for transmitting dowlink control information
KR102458074B1 (ko) * 2016-03-31 2022-10-24 삼성전자 주식회사 이동 통신 시스템에서 이종 서비스 제공 방법 및 장치
US10757687B2 (en) * 2016-05-12 2020-08-25 Qualcomm Incorporated Techniques for communicating feedback in low latency wireless communications
US10097260B2 (en) 2017-02-06 2018-10-09 Qualcomm Incorporated Current indication channel for eMBB/URLLC multiplexing

Also Published As

Publication number Publication date
PL3602878T3 (pl) 2022-10-03
JP2020516149A (ja) 2020-05-28
BR112019019622B1 (pt) 2022-10-18
US20190349136A1 (en) 2019-11-14
BR112019019622A2 (pt) 2020-04-22
BR112019019622A8 (pt) 2022-08-23
CN110637429B (zh) 2022-09-02
CN115765921A (zh) 2023-03-07
US10659198B2 (en) 2020-05-19
MX2019011072A (es) 2019-11-18
WO2018172245A1 (en) 2018-09-27
EP3602878A1 (en) 2020-02-05
CN110637429A (zh) 2019-12-31
EP3602878B1 (en) 2022-06-01
EP4089942A1 (en) 2022-11-16

Similar Documents

Publication Publication Date Title
CN108292976B (zh) 电信装置和方法
US20200112394A1 (en) Code block level error correction and media access control (mac) level hybrid automatic repeat requests to mitigate bursty puncturing and interference in a multi-layer protocol wireless system
US11569941B2 (en) Configuring puncture bundles of data for a first service in a transmission of a second service
US9992004B2 (en) Code block cluster level HARQ
US11677513B2 (en) Retransmission for punctured signals
US20160119105A1 (en) Fountain harq for reliable low latency communication
US20160173232A1 (en) Mitigation of bursty interference
JP6955576B2 (ja) 第２のサービスの送信における第１のサービスのためのデータのパンクチャバンドリング
CN110366833B (zh) 用于确认信令的重传定时

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191113

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191113

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20201105

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20201214

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210226

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20210303

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210903

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20211001

R150 Certificate of patent or registration of utility model

Ref document number: 6955576

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150