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

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

Info

Publication number
JP6955575B2
JP6955575B2 JP2019552499A JP2019552499A JP6955575B2 JP 6955575 B2 JP6955575 B2 JP 6955575B2 JP 2019552499 A JP2019552499 A JP 2019552499A JP 2019552499 A JP2019552499 A JP 2019552499A JP 6955575 B2 JP6955575 B2 JP 6955575B2
Authority
JP
Japan
Prior art keywords
service
data
transmission
resources
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
JP2019552499A
Other languages
English (en)
Other versions
JP2020511895A (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 JP2020511895A publication Critical patent/JP2020511895A/ja
Application granted granted Critical
Publication of JP6955575B2 publication Critical patent/JP6955575B2/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/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/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
    • 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/0044—Arrangements for allocating sub-channels of the transmission path allocation of payload
    • H04L5/0046—Determination of how many bits are transmitted on different sub-channels
    • 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/0091—Signaling for the administration of the divided path
    • H04L5/0092—Indication of how the channel is divided

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

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の期間中に送信される（ことになる）ことを決定する。第1のサービスのためのデータは、第2のサービスのためのデータよりも低レイテンシ（短い待ち時間／低遅延）を必要とし、第1のサービスのためのデータは、第1のサービスのためのデータの元のセットと、第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとを含む。送信ノードは、利用可能な送信リソースに基づいて、第1のサービスのためのデータによって消費されるリソースを調整する。次いで、第2のサービスのためのデータが第1の期間中に送信される間に、送信ノードは、第1の期間中に、調整されたリソースを使用して第1のサービスのためのデータを送信する（送信ノードは第1の期間中に、調整されたリソースを使用して第1のサービスのためのデータを送信し、第2のサービスのためのデータは、第1の期間中に送信される）。
本開示の他の態様は、この方法を実行するための送信ノード、ならびにプロセッサによって実行されると、プロセッサにこの方法を実行させるコードを備えるコンピュータ可読媒体を対象とする。
本開示の態様は、受信ノードにおいて実施される方法を対象とする。受信ノードは、第1の期間中に送信を受信する。送信は、第1のサービスのためのデータおよび第2のサービスのためのデータを含み、第1のサービスのためのデータは、第2のサービスのためのデータよりも低レイテンシを必要とする。次に、受信ノードは、受信された送信におけるインジケータに基づいて、第1のサービスのためのデータの配置を決定する。受信ノードは、第1のサービスのためのデータの決定された配置に基づいて、第1のサービスのためのデータの復号を試行する。
本開示の他の態様は、この方法を実行するための受信ノード、ならびにプロセッサによって実行されると、プロセッサにこの方法を実行させるコードを備えるコンピュータ可読媒体を対象とする。
図1は、従来のHARQプロセスのシグナリング図である。 図2は、従来のトランスポートブロック送信のブロック図である。 図3Aは、例示的なパンクチャされたアップリンク送信およびダウンリンク送信のブロック図である。 図3Bは、例示的なパンクチャされたアップリンク送信およびダウンリンク送信のブロック図である。 図4は、本開示の例示的な実施形態による、繰り返される制御データおよびユーザデータを用いたパンクチャされた送信のブロック図である。 図5は、本開示の例示的な実施形態による、単一の制御データ送信と、周波数ホッピングを伴わない繰り返されるユーザデータ送信とを伴うパンクチャされた送信のブロック図である。 図6は、本開示の例示的な実施形態による、単一の制御データ送信と、周波数ホッピングを伴う繰り返されるユーザデータ送信とを伴うパンクチャされた送信のブロック図である。 図7は、本開示の例示的な実施形態による、単一の制御データ送信と、周波数ホッピングを発明繰り返されるユーザデータ送信とを発明、別のパンクチャされた送信のブロック図である。 図8は、本開示の例示的な実施形態による送信機および受信機のブロック図である。 図9は、本開示の例示的な実施形態による例示的な送信方法のハイレベルフロー図である。 図10は、本開示の例示的な実施形態による例示的な送信方法のフロー図である。 図11は、本開示の例示的な実施形態による例示的な受信方法のハイレベルフロー図である。 図12は、本開示の例示的な実施形態による例示的な受信方法のフロー図である。 図13は、本開示の例示的な実施形態による例示的な送信方法のハイレベルフロー図である。 図10は、本開示の例示的な実施形態による例示的な送信方法のフロー図である。 図15は、本開示の例示的な実施形態による、第2のサービスの送信期間の終了時に残るリソースを伴うパンクチャされた送信のブロック図である。 図16は、本開示の例示的な実施形態による、第2のサービスのための2つの送信間隔にわたるパンクチャされた送信のブロック図である。 図17は、本開示の例示的な実施形態による、周波数スタックパンクチャード送信のブロック図である。 図18は、本開示の例示的な実施形態による例示的な送信方法のハイレベルフロー図である。 図19は、本開示の例示的な実施形態による、いくつかの受信ノードの第１のサービスの制御データが一緒にグループ化され、受信ノードの数の第１のサービスのユーザデータが一緒にグループ化されるパンクチャ送信のブロック図である。
同じネットワーク内で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のサービスのためのデータを再送信することを試みることができる。
上記の議論は、パンクチャバンドルの様々な構成の高レベルの概要を含む、パンクチャバンドリングのいくつかの態様に対処した。ここで、パンクチャバンドルを構成することについてのより詳細な議論を、図13〜19に関連して提示する。
図13は、本開示の例示的な実施形態による例示的な送信方法のハイレベルフロー図である。最初に、送信ノード805のプロセッサ815は、第2のサービスのためのデータが送信される期間中に第1のサービスのためのデータが送信される（ことになる）ことを決定する（ステップ1305）。第1のサービスのためのデータは、第2のサービスのためのデータよりも低レイテンシ（短い待ち時間／低遅延）を必要とし、第1のサービスのためのデータは、第1のサービスのためのデータの元のセットと、第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとを含む。次に、プロセッサ815は、利用可能な送信リソースに基づいて、第1のサービスのためのデータによって消費されるリソースを調整する（ステップ1310）。以下に詳細に説明するように、この調整は、第2のサービスのためのTTIの残りのリソースを第1のサービスのためのデータで埋めること、または、例えば、意図されたよりも元のデータの繰り返しの数よりも少ない数を含めることによって、パンクチャバンドルのサイズを縮小することを含むことができる。次いで、第2のサービスのためのデータが当該期間中に送信される間に、プロセッサ815は、当該期間中に、調整されたリソースを使用して第1のサービスのためのデータを送信する（プロセッサ815は期間中に、調整されたリソースを使用して第1のサービスのためのデータを送信し、第2のサービスのためのデータは当該期間中に送信される）（ステップ1315）。
次に図14を参照すると、送信ノード805が第1のサービスのために送信すべきデータを有するとき、プロセッサ815は最初に、新しいトランスポートフォーマットが設定されているかどうかを判定する（ステップ1405）。例示的な実施形態によれば、物理層トランスポートフォーマットは、第1のサービスのためのデータの送信の開始前に事前設定され、新しいトランスポートフォーマット信号の受信時に変更される。したがって、新しいトランスポートフォーマットがシグナリングされた場合（判定ステップ1405からの「Yes」パス）、送信ノード805は、新しいトランスポートフォーマットを使用する（ステップ1410）。そうでない場合、送信ノード805は、事前設定されたトランスポートフォーマットを使用し続ける（ステップ1415）。
送信ノードが新しいまたは事前設定されたトランスポートフォーマットを使用することを決定すると、プロセッサ815は、第1のサービスのためのデータを収容するために、第2のサービスに対して、十分なリソースがTTI内にあるかどうかを判定する（ステップ1420）。これはパンクチャバンドルが第2の送信のためにTTIの後の部分で送信される場合であって、第1のサービスのための元の送信と、元の送信の繰り返しのそれぞれとの両方を収容するのに十分なリソースがない場合に起こり得る。例えば、これは第1のサービスのための各々の送信が2つのシンボルを占有し、パンクチャバンドリングが元のデータおよび3つの繰り返し（すなわち、8つのシンボルを占有する4つのミニスロット）を含み、第2のサービスのためのTTIが14シンボルであり、パンクチャリングがTTIの7番目のシンボルの後に起こり、次いで、第1のサービスのための送信が8つのシンボルを占有するが、パンクチャバンドルの挿入の点において、7つのシンボルのみが利用可能である場合に起こり得る。
第1のサービスのすべての送信に十分なリソースがある場合（判定ステップ1420からの「Yes」パス）、送信ノードは、第2のサービスに対するTTIに、第1のサービスのすべての送信を含める（ステップ1425）。また、パンクチャバンドルに続く利用可能なリソースが存在する状況が発生する可能性があり、その一例が図15に示されている。図15は、第2のサービスのTTI 1500内で、第1のサービスのための元の送信1505と、2つの繰り返し1510a、1510bとがパンクチャされることを示している。この例では、リソースエリア1515は、パンクチャバンドルミニスロットの端部（終端）の間の第2のサービスのためのTTIの一部を表す。実装に応じて、このリソースエリア1515は第2のサービスのためのデータを収容するのに十分な大きさではないことがあり、したがって、これらのリソースは、完全に浪費されることがある。
これを回避する1つの方法は、パンクチャバンドルの端部が第2のサービスのためのTTI 1500のスロット境界1525の端部に並ぶように、パンクチャバンドルの開始点を遅延させることである。別の代替処理は、スロット境界1525に最も近い繰り返しに対してより低い符号化レートを採用することを含み得、その結果、この繰り返しがギャップを満たす。上述のパンクチャバンドリングインジケータは、第1のサービスのための各元のデータと繰り返しのデータために使用される符号化フォーマットを明示的に示すために使用されうる。さらに別の代替案は、第2のサービスのためのTTIの残りの時間内に適合するように、最後の繰り返しの長さを短くすることである。例えば、第1のサービスの最後の繰り返しは、通常のミニスロットに使用される2つのシンボルの代わりに、1つのシンボルのミニスロット長を使用することができる。さらに別の代替案によれば、ミニスロットの長さは、最初のサービスのためのデータの最初の送信および繰り返しのうちの1つ以上について増加することができる。例えば、9つの残りのOFDMシンボルが存在し、元の送信および繰り返しの量が3である（すなわち、1つの元の送信および2つの繰り返し）場合、3つのOFDMシンボルが各ミニスロットに割り当てられ得る。
別の代替案は、元の送信および／または繰り返しのうちの1つまたは複数を繰り返して、TTI内の残りのリソースを満たすことである。例えば、1つの元の送信および5つの繰り返しに等しい量のために十分なリソースがあるが、第1のサービスのためのデータが最初に1つの元の送信および3つの繰り返しのために構成された場合、2つの追加の送信が発生することができる（これは元のおよび／または1つ以上の繰り返しを含むことができる）。元の送信および繰り返しの各々が同じ方法でフォーマットされ、符号化される場合、2つの追加の送信は元の送信および繰り返しの両方で同じであり得る（例えば、RV0、RV0、RV0、RV0、RV0、RV0、RV0、RV0）。元の送信および／または1つ以上の繰り返しが異なるようにフォーマットまたは符号化される場合、元のおよび／または繰り返しのうちの2つを繰り返すことができる（例えば、RV0、RV1、RV2、RV3、RV0、RV1）。第2のサービスのためのTTIのフォーマットに応じて、追加された繰り返しは第2のサービスのためのデータの機密情報ビットまたは制御チャネルを収容（適合）するために、TTIの異なる領域において省略され得る。さらに、各パンクチャ領域は少なくとも1つのRV（Redundancy Version）またはRVG（Redundancy Version Group）を含み、これは、1つまたは複数のRVを含むことができる。RVは、典型的には第1のサービスのためのデータのトランスポートブロックに関連付けられる。TBS （トランスポートブロックサイズ）が大きく、例えば、TBSURLLC＞8192ビットであり、コードブロックセグメンテーションを被る稀な状況では、繰り返しおよび関連するRVがCBG（コードブロックグループ）に関連付けられ得る。
図14に戻る前に、図15の第1のサービスのためのデータのフォーマットは、図15の第1のサービスのための制御データが第2のサービスのためのTTIの周波数帯域幅の一部のみを占め、周波数帯域幅の残りの部分が第1のサービスのための対応するユーザデータに割り当てられる点で、以前の図とは異なることに留意されたい。このフォーマッティングは、上述した実施形態でも使用することができる。
図14に戻ると、第1のサービスのためのすべての送信に十分なリソースがない場合（判定ステップ1420からの「No」パス）、プロセッサ815は、不十分なリソースを収容するように第1のサービスの送信を調整する（ステップ1430）。送信を調整する1つの方法は、n+1がTTIの境界上に広がる場合に、元の送信と繰り返しの合計がnに制限されるように、繰り返しの数を減らすことである。数nは事前設定される必要はなく、パンクチャリング（パンクチャバンドリング開始ミニスロット）の開始点、ミニスロットの終了位置（パンクチャバンドリング終了ミニスロット）、およびミニスロット送信の区間から動的に抽出することができ、これらのすべてをパンクチャバンドルインジケータに含めることができる。
受信ノード850が第1のサービスのための送信およびデータの繰り返しの量が低減されたために、第1のサービスのためのデータの復号に成功することができない場合（例えば、利用可能なリソースが元の送信および1つの繰り返しのみを許可する場合）、残りの繰り返しは、復号の成功を可能にするために、許可ベースの方法（すなわち、通常のHARQ手順）でスケジュールされ得る。元の送信および／または1つまたは複数の繰り返しが（例えば、リソースの競合ベースのパンクチャリングにおいて）破損または欠落した場合、許可ベースのスケジューリングを使用することもできる。
第1のサービスのためのデータの送信が利用可能なリソースのためにフォーマットされると（ステップ1425または1430）、プロセッサ815はパンクチャバンドルインジケータを追加する（ステップ1435）。上述のように、パンクチャバンドルインジケータは、パンクチャリングの開始点を識別するためのパンクチャバンドル開始ミニスロットの値と、ミニスロットの終了位置を識別するためのパンクチャバンドル終了ミニスロットの値とを含むことができる。パンクチャバンドルインジケータはまた、パンクチャされたeMBBエリアID開始ミニスロット、パンクチャされたeMBBエリアID終了ミニスロット、およびミニスロット区間（持続時間）の値を含み、これは、第2のサービスのTTI内で発生するパンクチャリングおよび2つ以上のTTIにわたって発生するパンクチャリングを別々に識別することを可能にする。パンクチャバンドリングミニスロットおよびパンクチャされたeMBBエリアミニスロットの開始（始端）および終了（終端）を別々に識別することは、第2のサービスのための複数のパンクチャされたTTIがある場合に有用である。ここで、この例を図16に関連して説明する。
図16では、第2のサービスのためのTTIの境界（スロット境界とも呼ばれる）が1625とラベル付けされている。したがって、図16は第1のサービスのためのデータの元の送信1605と、第1のサービス1610a、1610bのためのデータの2つの繰り返しとを含む第1のTTI（すなわち、第1のスロット）と、第1のサービスのためのデータの元の送信1615と、2つの繰り返し1620a、1620bとを含む第2のTTI（すなわち、m番目のスロット）とを示す。図示されているように、第2のサービスのための第1のTTIはパンクチャeMBBエリア-1 1660として指定され、パンクチャバンドリング開始スロット:1 1665としても指定され、第2のサービスのための最後のパンクチャTTIはパンクチャされたeMBBエリア-k 1660およびパンクチャされたバンドリング終了スロットm 1675として指定される。したがって、パンクチャバンドリングスロットの開始および終了は2つ以上のTTIをカバーし、一方、パンクチャされた各eMBBエリアは、TTIに対応する。したがって、最初のTTIにおける元の送信1605の開始はパンクチャバンドリング開始ミニスロット1630に対応し、最後の繰り返し1620bの終了は、パンクチャバンドリング終了ミニスロット1650に対応する。対照的に、パンクチャされたeMBBエリア-1開始ミニスロット1635およびパンクチャされたeMBBエリア-1終了ミニスロット1640は第1のTTI内のパンクチャされたエリアを定義し、パンクチャされたeMBBエリア-k開始ミニスロット1645およびパンクチャされたeMBBエリア-k終了ミニスロット1655は、第2のTTI内のパンクチャされたエリアを定義する。言い換えると、パンクチャバンドリング開始／終了ミニスロットは、第1のサービスに対して定義され、パンクチャされたeMBBエリア-1開始／終了ミニスロットは、第2のサービスに対して定義される。1つのスロット内に複数のパンクチャされた領域が存在し得るので、パンクチャされたバンドリング終了スロット番号mは、領域ID kよりも小さくなり得る。
再び図14に戻ると、パンクチャバンドルインジケータを追加した後（ステップ1435）、送信ノード805のプロセッサ815は、第2のサービスのリソースブロックが第1のサービスのための2つ以上の送信を収容するのに十分な大きさであるかどうかを判定する（ステップ1440）。リソースブロックが十分に大きい場合（判定ステップ1440からの「Yes」パス）、第1のサービスのためのデータの元の送信および1つまたは複数の繰り返しを周波数にスタックすることができる（ステップ1445）。図17は、元の送信1705と1回の繰り返し1710cが時間的に整列され、周波数にスタックされ、2回の繰り返し1710aと1710dが時間的に整列され、第2のサービスのTTI内の周波数にスタックされる例示的な周波数スタッキングを示す。第1のサービスのための未使用のリソースを有するエリア1715は、上述の調整技術のいずれかを使用して、第1のサービスのためのデータによって占有されることができる。
元の送信および繰り返しの特定の配置は例えば、より低い周波数からより高い周波数に始まり、その後、時間的に始まるようなRVGにおいて、事前に設定することができる。UEの限られた電力のために、周波数領域スタッキングは、典型的には基地局からUEへのダウンリンクにおいてのみ実施される。さらに、アップリンクでは周波数スタッキングによる周波数領域での電力分割（power splitting）が非周波数スタック送信よりも実質的に性能が優れておらず、したがって、アップリンクでは経時的な繰り返し送信がアップリンクの品質向上にとってより有益であり得る。
図17に示す周波数スタッキングは単に例示的なものであり、他の変形例も本開示の範囲内である。例えば、アップリンクおよびダウンリンク送信は周波数スタックされることができ、および／または制御データの送信は、ユーザデータの送信と周波数スタックされることができる。
周波数スタッキングの1つの変形は、第1のサービスのためのデータを低い符号化レートで符号化することである。次いで、符号化されたビットは変調シンボルに形成され、次いで、変調シンボルはOFDMシンボル（複数可）内の周波数リソースにマッピングされる。周波数リソースは、典型的にはデータを搬送することができるリソース要素のセットによって表される。データ搬送リソース要素は、周波数ダイバーシティを達成するために、周波数領域において可能な限り連続していてもよく、または、データ搬送リソース要素が周波数領域において分散されていてもよい。例えば、図17に示される周波数領域バンドリングは、繰り返し／複製を利用する低符号レートと、周波数領域に分散されたリソース要素のブロックへの変調シンボルのマッピングとの両方を使用して達成され得る。
周波数スタッキングの別の変形は、1つ以上のOFDMシンボルが最初のサービスのための1つのデータパックを送信するために使用されるとき、周波数ホッピングを採用することである。周波数ホッピングは、1つのOFDMシンボルにおいて使用される周波数領域リソースが別のOFDMシンボルにおける周波数領域リソースと異なることを可能にし、したがって、周波数領域ダイバーシティを達成することができる。
周波数スタッキングの別の変形は、空間ダイバーシティを組み込む。例えば、周波数領域リソースのM個のブロックが第1のサービスのためのデータを送信するために使用される場合、周波数領域リソースの1つのブロックのために使用されるプリコーディング行列は、周波数領域リソースの別のブロックのために使用されるプリコーディング行列とは異なる。異なるビームが第1のサービスのために同じデータを送信するために使用されるビーム掃引（sweeping）は、空間ダイバーシティを達成するために使用されることができる。より具体的には、空間ダイバーシティ、またはビーム掃引は第1のサービスのためのデータを送信するために2つ以上のOFDMシンボルを使用することによっても、時間領域において使用され得る。
再び図14に戻ると、第2のサービスのリソースブロックが第1のサービスの2つ以上の送信に対応できない場合（判定ステップ1440からの「No」パス）、第1のサービスのための第1の送信および繰り返しは、周波数スタックの代わりに、図15（および他の同様の図）に示される構成と同様に、時間的に整列される（ステップ1450）。元の送信と時間／周波数領域における繰り返しとの整列が決定されると（ステップ1445または1450）、プロセッサ815は第1のサービスのパケットのサイズが固定されており、既知であるかどうかを決定する（ステップ1455）。パケットのサイズが固定され、既知である場合（判定ステップ1455からの「Yes」パス）、プロセッサ815は、第1のサービスのためのMCS（変調および符号化方式）を動的に選択することができる（ステップ1460）。第1のサービスのためのパケットのサイズは、制御システムにおけるフィードバックループのための特定のアラームメッセージおよび／または状態情報パケットについて固定され、知られてもよい。
LTEネットワークでは、チャネル状態に基づいてMCSが選択され、特定のトランスポートブロックサイズの送信に必要なリソースブロックがルックアップテーブルから選択される。第1のサービスのためのデータの元の送信および繰り返しのために異なる符号化を使用するパンクチャバンドリングは、符号化レートを低下させることと同等である。さらに、パンクチャリングのために割り当てられるリソースブロックは制限され得る。したがって、MCSは、パンクチャの数に基づいて決定することができる。一実施形態では、これは第1のサービスのためのデータの送信のための信頼性目標（ターゲット）が所与の無線リソースについて可能な限り高いことを保証されることができるように、より高いMCSインデックスおよび／またはより高いバンドリング数の選択によって、利用可能なリソースを完全に使用するレートマッチングを使用して達成されることができる。例えば、誤差目標が10-6であり、現行のMCS指標設定が10-4のBLER（BLock Error Ratio（ブロック誤り率））目標を有する場合、全誤差目標を達成するために、2つの送信（すなわち、元の送信および1つの繰り返し）を有するバンドル（束）を使用することができる。利用可能なリソースブロックが現MCSを使用して2つの送信を伴うバンドルに対応できない場合、利用可能なリソースブロックが2つの送信を伴うバンドルに対応し、最終的に10-7に達することができるように、MCS指数は（例えば、10-3.5のBLERに達するために）送信の両方において増加され得る。
別の実施形態では、BLER目標（および結果としてMCS）がリソースブロックを効率的に使用するために、パンクチャの数に基づいて調整される。例えば、パンクチャバンドルが、第2のサービスのための1つのTTIに制限され、別のTTIに持ち越されない場合、TTIにおけるパンクチャの数を決定することができる。誤差目標が10-xであり、ここで、xは0以上の任意の実数（しかし、典型的には5以上の実数）とすることができ、y回の送信の束に対して充分な時があり、ここで、yは2以上の整数であり、MCSは10(-x/y)のBLER目標を達成するように選択することができる。
再び図14に戻ると、第1のサービスのためのパケットのサイズが固定されておらず未知である場合（判定ステップ1455からの「No」パス）、第1のサービスのための送信は、固定されたMCを使用して符号化される（ステップ1465）。第1のサービスのための送信が動的に選択された1つ（ステップ1460）または固定されたMCS（ステップ1465）のいずれかを用いて符号化されると、送信ノードのプロセッサ815は、送受信器810を介して第1のサービスのためのデータを受信ノード850に送信する（ステップ1470）。
図18は、本開示の例示的な実施形態による例示的な受信方法のハイレベルフロー図である。最初に、受信ノード850の送受信器855は、第2のサービスのためのデータの送信に対応する期間中に送信を受信し、その送信をプロセッサ860に渡す（ステップ1805）。送信は第1のサービスのためのデータおよび第2のサービスのためのデータを含み、第1のサービスのためのデータは、第2のサービスのためのデータよりも低レイテンシを必要とする。次に、プロセッサ860は、受信された送信におけるインジケータに基づいて、第1のサービスのためのデータの配置を決定する（ステップ1810）。インジケータは上述したパンクチャバンドルインジケータとすることができ、このインジケータの一部として上述した情報のいずれかを含むことができる。次いで、プロセッサ860は、第1のサービスのためのデータの決定された配置に基づいて、第1のサービスのためのデータの復号を試行する（ステップ1815）。
上記の実施形態のいずれにおいても、パンクチャバンドルのいくつかの態様を事前に設定（構成）することができる。例えば、開始スロット、終了スロット、開始ミニスロット、終了ミニスロット、繰り返しの数、繰り返しのタイプ（すなわち、繰り返しと元のデータとの間の同一または異なる符号化）、RVGにおける元のおよび繰り返しのための符号化タイプの組み合わせ、パンクチャされたエリアの数、パンクチャされたエリアのサイズ、パンクチャされたエリアへのパンクチャバンドルの展開などは、例えば、MCS（複数可）、第1のサービスのトランスポートブロックサイズ、および第2のサービスのトランスポートブロックサイズに基づいて事前に定義され得る。例えば、第1および第2のサービスのためのデータが同じMCSを有し、第1および第2のサービスのトランスポートブロックのサイズが知られている場合、パンクチャバンドリングはスロットの所定のミニスロット、例えば、第2のミニスロットにおいて第1のサービスのためのデータの元の送信を有することによって実行され得、第1および第2の繰り返しは、それぞれ、第3および第4のミニスロットにあり得る。スロットは複数のミニスロット、例えば7つのミニスロットから構成することができ、各ミニスロットは2つのOFDMシンボルを有する。パンクチャバンドルインジケータを使用して、この構成を受信ノードに識別することができる。代替として、または追加として、受信ノードは、第2のサービスのためのトランスポートブロックのサイズなどの既知のパラメータに基づいて、ルックアップテーブルを使用して、パンクチャされたエリアと、第1のサービスのための元のおよび繰り返しのデータを決定することができる。この事前設定は、各パンクチャが受信ノード850によって独立して受信され得ることを保証するために各パンクチャされたエリアにおいて必要とされる冗長バージョンに関する情報を有する専用制御領域を使用する通常動作を変更しない。
別の事前設定は、第1のサービスのための制御およびデータを第2のサービスのTTIの別個のエリアに事前設定することであり得、その一例が図19に示されている。図示されているように、いくつかの受信ノード850のための別個の制御データはパンクチャされた制御領域1905に含まれ、いくつかの受信ノード850のための第1のサービスのためのデータはパンクチャされたユーザデータ領域1910に含まれ得る。領域1905および1910は周波数量fによって分離され、周波数量fはゼロより大きくても等しくてもよいが、いずれにしても、できるだけ小さいことが好ましい。制御領域は例えば、パンクチャバンドルインジケータ、受信ノードの識別子、MCSなどを含むことができ、一方、データ領域は、第1のサービスのためのデータのみを含む。したがって、パンクチャされたデータ領域1910に含まれるデータは、第1のサービスのための制御データおよび第1のサービスのためのユーザデータの両方を含むことができるが、第1のサービスのためのユーザデータのフォーマッティング、変調、符号化、および／または位置（ロケーション）を識別する制御データを含まない。
上述の一実施形態では受信ノード850がパンクチャバンドルのための単一のHARQフィードバック（すなわち、ACKまたはNACK）を送信し、これは元の送信およびすべての繰り返しの両方をカバーする。また、受信ノード850が第1のサービスのためのデータの復号に成功した場合、受信ノード850は、残りの繰り返しを廃棄することも説明された。上記の議論は、この構成におけるHARQフィードバックの特定のタイミングに対処しなかった。HARQフィードバックは、第1のサービスのためのデータの復号が成功した後に、またはフィードバックが第1の送信の元のデータに対応する最後の繰り返しを受信した後に、送信されることができる。受信ノードは、繰り返しのいずれも廃棄する必要はなく、第1のサービスのためのデータの復号において、元の送信およびすべての繰り返しを使用することができることを認識されたい。
別の実施形態によれば、送信ノードである基地局は、第1のサービスのための元のデータの復号が失敗したという指示があるとすぐに、即時アップリンク許可を提供することができる。即時アップリンク許可は例えば、第1のサービスのための元のデータの最後の繰り返しの後にスケジュールされることができる。しかしながら、これは、元のパンクチャバンドルを送信する基地局と、第2のサービスの後続のTTIなどの後続の期間に生じる追加の繰り返しとの間の遅延が第1のサービスの低レイテンシ要件を満たすには大きすぎる可能性があるため、リソース効率が悪い。
図13、図14、および図18の方法は、図9〜図12に記載の方法と組み合わせることができる。
例示的な実施形態は、アップリンクおよびダウンリンクの両方で使用できることを理解されたい。
上記の説明では、第1のサービスが第2のサービスよりも低レイテンシを必要とするものとして言及されている。また、第1のサービスは第2のサービスよりも高い信頼性を必要とする可能性があり、したがって、いくつかの態様では、第1のサービスが第2のサービスよりも短い待ち時間および高い信頼性を必要とする。
例示的な実施形態は第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 (23)

  1. 送信ノードにおいて実施される方法であって、前記方法は、
    第1のサービスのためのデータが第2のサービスのためのデータが送信される期間中に送信されることを決定することであって、前記第1のサービスのためのデータは前記第2のサービスのためのデータよりも低レイテンシを必要とし、前記第1のサービスのためのデータは、前記第1のサービスのためのデータの元のセットと、前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとを含むパンクチャリングバンドルである、ことと、
    利用可能な送信リソースに基づいて前記第1のサービスのためのデータによって消費されるリソースを調整することであって、前記調整は、前記期間の残りのリソースを埋めること又は前記パンクチャリングバンドルのサイズを縮小することを含む、ことと、
    前記第2のサービスのためのデータが前記期間中に送信される間に、前記期間中に、前記調整されたリソースを使用して前記第1のサービスのためのデータを送信すること、を含む方法。
  2. 請求項1に記載の方法であって、前記少なくとも1つの繰り返しは少なくとも第1および第2の繰り返しを含み、前記第1のサービスのためのデータによって消費されるリソースの前記調整は、前記期間中に前記送信から前記第1および第2の繰り返しのうちの1つを削除することを含む、方法。
  3. 請求項1に記載の方法であって、前記利用可能な送信リソースは、前記第1のサービスのためのデータによって消費されるリソースの終了と前記期間の終了との間に配置された利用可能なリソースの第1のセットを含み、前記第1のサービスのためのデータによって消費されるリソースの前記調整は、前記第1のサービスのためのデータの元のセットと前記少なくとも1つの繰り返しに続く、利用可能なリソースの前記第1のセットにおける前記第1のサービスのためのデータの元のセットの追加の繰り返しを含むことを含む、方法。
  4. 請求項1に記載の方法であって、前記利用可能な送信リソースは、前記第1のサービスのためのデータによって消費されるリソースの終了と前記期間の終了との間に配置された利用可能なリソースの第1のセットを含み、前記第1のサービスのためのデータによって消費されるリソースの前記調整は、前記利用可能なリソースの前記第1のセットを満たすために、前記少なくとも1つの繰り返しの最後の繰り返しを拡張することを含む、方法。
  5. 請求項4に記載の方法であって、前記最後の繰り返しは、前記最後の繰り返しを符号化するために使用される符号化レートを下げることによって拡張される、方法。
  6. 請求項1に記載の方法であって、さらに、
    前記第2のサービスのリソースブロックが、前記第1のサービスのための2つ以上の送信を収容することができるかどうかを判定することを含む、方法。
  7. 請求項6に記載の方法であって、前記第2のサービスのリソースブロックが前記第1のサービスのための2つ以上の送信を収容することができるとき、前記第1のサービスのためのデータの元のセットと、前記少なくとも1つの繰り返しのうちの少なくとも1つは、前記第1のサービスのためのデータの元のセットと、前記少なくとも1つの繰り返しのうちの少なくとも1つとが、時間的な調整において異なる周波数を占有するように、時間的に整列される、方法。
  8. 請求項1に記載の方法であって、前記第1のサービスのためのデータは制御データおよびユーザデータを含み、前記データの元のセットは前記制御データおよびユーザデータの一部が時間的に整列されているが、異なる周波数を占有する状態で送信される、方法。
  9. 請求項1に記載の方法であって、さらに、
    前記送信が前記第1のサービスためのデータを含むことを示すインジケータを前記期間中の前記送信に含めることを含む、方法。
  10. 請求項9に記載の方法であって、前記インジケータは、記第1のサービスのためのデータの開始および終了を識別する、方法。
  11. 請求項1に記載の方法であって、さらに、
    変調及び符号化方式のセットから変調及び符号化方式を動的に選択することと、
    動的に選択された変調及び符号化方式を使用して前記第1のサービスのためのデータを変調及び符号化することを含む、方法。
  12. 請求項11に記載の方法であって、前記変調および符号化方式は、目標誤り率を達成するために、前記第1のサービスのためのデータの元のセットと前記少なくとも1つの繰り返しの送信量に基づいて動的に選択される、方法。
  13. 請求項12に記載の方法であって、前記第1のサービスのためのデータの元のセットの送信量が調整され、前記変調および符号化方式が、前記目標誤り率を達成するために、前記第1のサービスのためのデータの元のセットと、前記少なくとも1つの繰り返しの前記調整された送信量に基づいて、動的に選択される、方法。
  14. 請求項1に記載の方法であって、前記第1のサービスのためのデータは少なくとも2つの受信ノードのための制御データおよびユーザデータを含み、前記少なくとも2つの受信ノードのための前記制御データは前記期間中の前記送信において時間的に互いに隣接して配置され、前記少なくとも2つの受信ノードのための前記ユーザデータは前記期間中の前記送信において時間的に互いに隣接して配置される、方法。
  15. 請求項1に記載の方法であって、前記送信ノードは基地局であり、前記第1および第2のサービスのためのデータの送信は前記第1および第2のサービスのためのデータが時間または周波数において重複しないように、時間または周波数においてインターレースされる、方法。
  16. 請求項1に記載の方法であって、前記送信ノードは第1のユーザ装置であり、第2のユーザ装置は、前記第1のユーザ装置による前記第1のサービスのためのデータの送信と時間または周波数が重複する前記第2のサービスのためのデータを送信する、方法。
  17. 請求項1に記載の方法であって、前記送信ノードは、前記第1のサービスのためのデータの送信と時間または周波数においてインターレースされた前記第2のサービスのためのデータも送信する第1のユーザ装置である、方法。
  18. 請求項1に記載の方法であって、前記第1のサービスはURLLC（Ultra-Reliable Low Latency Communication）サービスであり、前記第2のサービスは、MBB（Mobile Broadband）サービスまたは拡張MBBサービスである、方法。
  19. 無線インターフェースと、処理回路とを備える送信ノードであって、
    前記処理回路は、
    第1のサービスのためのデータが第2のサービスのためのデータが送信される期間中に送信されることを決定し、ここで、前記第1のサービスのためのデータは前記第2のサービスのためのデータよりも低レイテンシを必要とし、前記第1のサービスのためのデータは、前記第1のサービスのためのデータの元のセットと、前記第1のサービスのためのデータの元のセットの少なくとも1つの繰り返しとを含むパンクチャリングバンドルであり、
    利用可能な送信リソースに基づいて前記第1のサービスのためのデータによって消費されるリソースを調整し、ここで、前記調整は、前記期間の残りのリソースを埋めること又は前記パンクチャリングバンドルのサイズを縮小することを含み、
    前記第2のサービスのためのデータが前記期間中に送信される間に、前記期間中に、前記調整されたリソースを使用して前記第1のサービスのためのデータを送信する、ように構成される、送信ノード。
  20. 請求項19に記載の送信ノードであって、前記少なくとも1つの繰り返しは少なくとも第1および第2の繰り返しを含み、前記第1のサービスのためのデータによって消費されるリソースの前記調整は、前記期間中に前記送信から前記第1および第2の繰り返しのうちの1つを削除することを含む、送信ノード。
  21. 請求項19に記載の送信ノードであって、前記利用可能な送信リソースは、前記第1のサービスのためのデータによって消費されるリソースの終了と前記期間の終了との間に配置された利用可能なリソースの第1のセットを含み、前記第1のサービスのためのデータによって消費されるリソースの前記調整は、前記第1のサービスのためのデータの元のセットと前記少なくとも1つの繰り返しに続く、利用可能なリソースの前記第1のセットにおける前記第1のサービスのためのデータの元のセットの追加の繰り返しを含むことを含む、送信ノード。
  22. 請求項19に記載の送信ノードであって、前記利用可能な送信リソースは、前記第1のサービスのためのデータによって消費されるリソースの終了と前記期間の終了との間に配置された利用可能なリソースの第1のセットを含み、前記第1のサービスのためのデータによって消費されるリソースの前記調整は、前記利用可能なリソースの前記第1のセットを満たすために、前記少なくとも1つの繰り返しの最後の繰り返しを拡張することを含む、送信ノード。
  23. 少なくとも1つのプログラマブルプロセッサに請求項1乃至18の何れか1項に記載の方法を実行させるためのコンピュータ可読命令を有するコンピュータプログラム。
JP2019552499A 2017-03-23 2018-03-19 第２のサービスの送信における第１のサービスのためのデータのパンクチャバンドルの構成 Active JP6955575B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CNPCT/CN2017/077816 2017-03-23
CNPCT/CN2017/077816 2017-03-23
PCT/EP2018/056823 WO2018172249A1 (en) 2017-03-23 2018-03-19 Configuring puncture bundles of data for a first service in a transmission of a second service

Publications (2)

Publication Number Publication Date
JP2020511895A JP2020511895A (ja) 2020-04-16
JP6955575B2 true JP6955575B2 (ja) 2021-10-27

Family

ID=61692004

Family Applications (1)

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

Country Status (8)

Country Link
US (3) US10965402B2 (ja)
EP (2) EP3602879B1 (ja)
JP (1) JP6955575B2 (ja)
CN (2) CN115242356A (ja)
BR (1) BR112019019703A2 (ja)
ES (1) ES2935609T3 (ja)
MX (1) MX2019011125A (ja)
WO (1) WO2018172249A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115242356A (zh) 2017-03-23 2022-10-25 瑞典爱立信有限公司 在第二服务传输中配置第一服务数据的打孔束的方法和装置
KR102444420B1 (ko) * 2018-05-10 2022-09-19 삼성전자 주식회사 광대역 무선 통신 시스템에서 상향링크 시간정렬을 제어하는 방법 및 장치
JP6976920B2 (ja) * 2018-10-30 2021-12-08 ソフトバンク株式会社 無線通信装置、無線通信システム、無線通信方法及びプログラム
US11831571B2 (en) * 2018-10-31 2023-11-28 Qualcomm Incorporated Transport block transmission using different spatial parameters
US11184892B2 (en) * 2018-11-05 2021-11-23 Mediatek Singapore Pte. Ltd. Enhancement of new radio PUSCH for URLLC in mobile communications
US20220173858A1 (en) * 2019-03-28 2022-06-02 Lg Electronics Inc. Method and device for transmitting and receiving sounding reference signal in wireless communication system
US20220166551A1 (en) * 2019-04-02 2022-05-26 Datang Mobile Communications Equipment Co.,Ltd. Information transmission method and user equipment
US11902934B2 (en) * 2020-03-17 2024-02-13 Qualcomm Incorporated Paging enhancement for new radio-unlicensed (NR-U) light
CN115278767A (zh) * 2021-04-30 2022-11-01 华为技术有限公司 一种无线局域网中传输报文的方法及电子设备

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007020996A1 (ja) * 2005-08-19 2007-02-22 Matsushita Electric Industrial Co., Ltd. 無線通信装置および無線通信方法
WO2009126902A2 (en) * 2008-04-11 2009-10-15 Interdigital Patent Holdings, Inc. Methods for transmission time interval bundling in the uplink
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
US8958559B2 (en) * 2011-06-03 2015-02-17 Apple Inc. System and method for secure instant messaging
CN104702702B (zh) 2012-01-11 2018-03-23 北京奇虎科技有限公司 一种数据下载***及方法
EP2635082A1 (en) * 2012-02-29 2013-09-04 Panasonic Corporation Dynamic subframe bundling
CN103402219B (zh) 2013-07-01 2016-03-23 北京航空航天大学 一种基于tdma数据链异构网的端到端时延的测量与优化方法
US10359052B2 (en) 2014-01-24 2019-07-23 Itt Manufacturing Enterprises, Llc Vertical pump having discharge head with flexible element
US10117268B2 (en) 2014-09-22 2018-10-30 Qualcomm Incorporated Ultra-low latency LTE downlink frame structure
US10772021B2 (en) * 2014-12-05 2020-09-08 Qualcomm Incorporated Low latency and/or enhanced component carrier discovery for services and handover
US10104683B2 (en) 2015-02-06 2018-10-16 Qualcomm Incorporated Parallel low latency awareness
US20160361593A1 (en) * 2015-06-10 2016-12-15 Wesley Charles Elliott System, apparatus and method for determining and analyzing sport related activities in conjunction with low latency transmission and processing
CN108141815A (zh) * 2015-08-14 2018-06-08 瑞典爱立信有限公司 无线网络中的***信息广播
CN106488410A (zh) * 2015-09-01 2017-03-08 中兴通讯股份有限公司 发送、接收低时延业务的配置信息的方法和装置
CN106535258A (zh) * 2015-09-10 2017-03-22 中兴通讯股份有限公司 发送超低时延传输信息的方法、装置及***
EP3357291A4 (en) * 2015-10-01 2019-05-22 Nokia Technologies OY APPARATUS AND METHOD FOR POINTING DATA TRANSMISSIONS BECAUSE DATA OF HIGHER PRIORITY
WO2017084903A1 (en) * 2015-11-19 2017-05-26 Sony Corporation Telecommunications apparatus and methods
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 삼성전자 주식회사 이동 통신 시스템에서 이종 서비스 제공 방법 및 장치
US10652759B2 (en) * 2016-04-26 2020-05-12 Futurewei Technologies, Inc. Apparatus and method for radio resource management for high reliability and low latency traffic
US10757687B2 (en) * 2016-05-12 2020-08-25 Qualcomm Incorporated Techniques for communicating feedback in low latency wireless communications
KR102473313B1 (ko) * 2016-06-08 2022-12-02 삼성전자 주식회사 이동 통신 시스템에서 이종 서비스의 제어 정보를 제공하는 방법 및 장치
CN107734678B (zh) * 2016-08-12 2023-05-23 中兴通讯股份有限公司 一种信息传输方法、装置和***
EP3566482A4 (en) * 2017-01-05 2020-08-19 Motorola Mobility LLC RESOURCE RESERVATION
EP3577983A1 (en) * 2017-02-03 2019-12-11 Nokia Technologies Oy Uplink resources for ultra-reliable and low latency communication
US10097260B2 (en) * 2017-02-06 2018-10-09 Qualcomm Incorporated Current indication channel for eMBB/URLLC multiplexing
US11219017B2 (en) * 2017-03-16 2022-01-04 Qualcomm Incorporated Multiplexing different services in wireless communications
MX2019011072A (es) 2017-03-23 2019-11-18 Ericsson Telefon Ab L M Agrupacion por pinchado de datos para un primer servicio en una transmision de un segundo servicio.
CN115242356A (zh) 2017-03-23 2022-10-25 瑞典爱立信有限公司 在第二服务传输中配置第一服务数据的打孔束的方法和装置
KR102342730B1 (ko) * 2017-06-15 2021-12-23 삼성전자주식회사 무선 통신 시스템에서 자원을 할당 및 지시하기 위한 장치 및 방법

Also Published As

Publication number Publication date
ES2935609T3 (es) 2023-03-08
BR112019019703A2 (pt) 2020-04-14
WO2018172249A1 (en) 2018-09-27
MX2019011125A (es) 2019-11-05
US11569941B2 (en) 2023-01-31
US10965402B2 (en) 2021-03-30
EP4207652A1 (en) 2023-07-05
CN110622450B (zh) 2022-05-24
US20210184797A1 (en) 2021-06-17
EP3602879A1 (en) 2020-02-05
JP2020511895A (ja) 2020-04-16
CN110622450A (zh) 2019-12-27
US20230254064A1 (en) 2023-08-10
CN115242356A (zh) 2022-10-25
US20190296861A1 (en) 2019-09-26
EP3602879B1 (en) 2022-12-07

Similar Documents

Publication Publication Date Title
JP6955575B2 (ja) 第２のサービスの送信における第１のサービスのためのデータのパンクチャバンドルの構成
CN112804036B (zh) 用于免授权上行链路传输的harq信令
CN108292976B (zh) 电信装置和方法
JP5607808B2 (ja) 通信システムにおける方法及び装置
EP3582420A1 (en) Methods for enhanced multiplexing in wireless systems
KR20190095326A (ko) 데이터 전송을 위한 방법 및 장치
KR20180013171A (ko) 이동 통신 시스템에서 harq 프로세스 관리 방법 및 장치
KR20070111537A (ko) 자동 재송 요구방식을 이용하는 멀티캐리어 통신 시스템을위한 통신 방법
KR20200003020A (ko) 기지국 장치, 단말기 장치, 무선 통신 시스템, 및 통신 방법
US11451346B2 (en) Communication device, infrastructure equipment and methods
JP6955576B2 (ja) 第２のサービスの送信における第１のサービスのためのデータのパンクチャバンドリング
US20230006779A1 (en) Apparatus and method for transmitting data in wireless communication system
Shariatmadari et al. 5G control channel design for ultra-reliable low-latency communications

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: 20201222

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210115

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20210303

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20210415

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210629

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: 20210906

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: 6955575

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150