JP2020507272A

JP2020507272A - 無線通信システムにおけるデータ通信実行方法、及び前記方法を用いる端末

Info

Publication number: JP2020507272A
Application number: JP2019540319A
Authority: JP
Inventors: リ，スンミン; ヤン，スクチェル
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2017-01-26
Filing date: 2018-01-26
Publication date: 2020-03-05
Anticipated expiration: 2038-01-26
Also published as: US20200008179A1; JP6918124B2; EP3565168B1; CN110214431B; WO2018139904A1; KR20190103162A; US10993209B2; EP3565168A1; CN110214431A; EP3565168A4

Abstract

本発明は、無線通信システムにおける端末によって行われるデータ通信実行方法において、相対的に短いレイテンシの要求事項を有するデータ通信のために設定された資源を決定し、及び前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行い、前記資源は、半静的に設定された資源であることを特徴とする方法を提供する。

Description

本発明は、無線通信システムに関し、より詳細には、無線通信システムにおける端末によって行われるデータ通信実行方法、並びにこれを用いる装置を提供する方法、及びこの方法を用いる装置に関する。

ＩＴＵ−Ｒ（ＩｎｔｅｒｎａｔｉｏｎａｌＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎＵｎｉｏｎＲａｄｉｏｃｏｍｍｕｎｉｃａｔｉｏｎｓｅｃｔｏｒ）では、３世代以降の次世代移動通信システムであるＩＭＴ（ＩｎｔｅｒｎａｔｉｏｎａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ）−Ａｄｖａｎｃｅｄの標準化作業を進めている。ＩＭＴ−Ａｄｖａｎｃｅｄは、停止及び低速の移動状態で１Ｇｂｐｓ、高速の移動状態で１００Ｍｂｐｓのデータ転送レートでＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）ベースのマルチメディアサービス支援を目標とする。

３ＧＰＰ（３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ）は、ＩＭＴ−Ａｄｖａｎｃｅｄの要求事項を満たすシステム標準としてＯＦＤＭＡ（ＯｒｔｈｏｇｏｎａｌＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅＡｃｃｅｓｓ）／ＳＣ−ＦＤＭＡ（ＳｉｎｇｌｅＣａｒｒｉｅｒ−ＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅＡｃｃｅｓｓ）転送方式ベースであるＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）を改善したＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）を準備している。ＬＴＥ−Ａは、ＩＭＴ−Ａｄｖａｎｃｅｄのための有力な候補のうちの一つである。

データ通信には、例えば、ＵＲＬＬＣ（Ｕｌｔｒａ−ＲｅｌｉａｂｌｅａｎｄＬｏｗＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ）のような相対的に短いレイテンシ（ｌａｔｅｎｃｙ）の要求事項を有するデータ通信と、例えば、ｅＭＢＢ（ｅｎｈａｎｃｅｄＭｏｂｉｌｅＢｒｏａｄｂａｎｄ）のような（ＵＲＬＬＣに比べて）相対的に長いレイテンシの要求事項を有するデータ通信が存在し得る。

ここで、ｅＭＢＢの場合は、相対的に長いレイテンシの要求事項（及び／又は相対的に低い信頼性（ｒｅｌｉａｂｉｌｉｔｙ）の要求事項）を有するデータ通信に該当するので、ダイナミックＤＣＩ（ｄｏｗｎｌｉｎｋｃｏｎｔｒｏｌｉｎｆｏｒｍａｔｉｏｎ）を介したグラントを用いて動的にデータ通信を行うとしても、（ＵＲＬＬＣに対して動的に通信を行う場合よりは）相対的に問題が生じる余地が低い。

しかし、相対的に短いレイテンシの要求事項（及び／又は相対的に高い信頼性の要求事項）を有するデータ通信に該当するＵＲＬＬＣの場合には、動的にデータ通信を行うために、ＵＬグラントを割り当て、アップリンクを試みるにはオーバーヘッドの問題及びタイムラインの問題が生じ得る。

これに伴って、本発明では、相対的に短いレイテンシの要求事項（及び／又は相対的に高い信頼性の要求事項）を有するデータ通信に対して半静的に設定された資源を介して通信を行う方法と、これを用いる端末に対する構成を提供しようとする。

本発明が解決しようとする技術的課題は、無線通信システムにおける端末によって行われるデータ通信実行方法、及びこれを用いる装置を提供することにある。

本発明の一実施例に係ると、無線通信システムにおける端末によって行われるデータ通信実行方法において、相対的に短いレイテンシの要求事項を有するデータ通信のために設定された資源を決定し、及び前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行い、前記資源は、半静的に設定された資源であることを特徴とする方法を提供する。

このとき、前記相対的に短いレイテンシの要求事項を有するデータ通信は、ＵＲＬＬＣ（ＵｌｔｒａＲｅｌｉａｂｌｅａｎｄＬｏｗＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ）であり、前記相対的に短いレイテンシの要求事項を有するデータ通信よりも相対的に長いレイテンシの要求事項を有するデータ通信は、ＥＭＢＢ（ＥｎｈａｎｃｅｄＭｏｂｉｌｅＢｒｏａｄｂａｎｄ）であり得る。

このとき、前記資源は、第１タイプの資源又は第２タイプの資源のうちの一つの資源であり、前記第１タイプの資源は、パンクチャリングが常に適用される資源であり、前記第２タイプの資源は、前記相対的に短いレイテンシの要求事項を有するデータ通信が行われるか否かに応じて、パンクチャリングが適用される資源であり得る。

このとき、前記第２タイプの資源では、前記相対的に短いレイテンシの要求事項を有するデータ通信が行われる場合、前記第２タイプの資源がパンクチャリングされ、及び前記相対的に短いレイテンシの要求事項を有するデータ通信が行われない場合、前記第２タイプの資源がパンクチャリングされないことがある。

このとき、特定の区間の間にチャネルの状態が既に設定された閾値よりも良くない場合、端末は、前記第１タイプの資源を用いて、前記相対的に短いレイテンシの要求事項を有するデータ通信を行い得る。

このとき、特定の区間の間にチャネルの状態が既に設定された閾値よりも良い場合、端末は、前記第２タイプの資源を用いて、前記相対的に短いレイテンシの要求事項を有するデータ通信を行い得る。

このとき、前記第１タイプの資源は、前記第２タイプの資源に比べて、相対的に小さいサイズを有し得る。

このとき、前記第１タイプの資源は、前記第１タイプの資源に対する別途の基準信号（ｒｅｆｅｒｅｎｃｅｓｉｇｎａｌ；ＲＳ）を有し得る。

このとき、前記端末は、ネットワークから前記資源の通信方向を指示する情報を受信し得る。

このとき、前記端末は、ネットワークから前記資源が有効な時間区間を受信し得る。

このとき、前記端末は、ネットワークに前記資源に関する補助情報を送信し得る。

このとき、前記補助情報は、前記資源に対して前記端末がどのくらいの間前記相対的に短いレイテンシの要求事項を有するデータ通信を行うかを指示する情報を含み得る。

このとき、前記補助情報は、前記資源に対するパラメータが、前記相対的に短いレイテンシの要求事項を有するデータ通信に適合するか否かに関する情報を含み得る。

このとき、前記補助情報は、前記資源のリリース情報又は前記資源の変更要請情報の少なくとも一つ以上を含み得る。

本発明の他の実施例に係ると、端末は、無線信号を送信及び受信するＲＦ（ＲａｄｉｏＦｒｅｑｕｅｎｃｙ）部、及び前記ＲＦ部と結合して動作するプロセッサを含み、前記プロセッサは、相対的に短いレイテンシの要求事項を有するデータ通信のために設定された資源を決定し、及び前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行い、前記資源は半静的に設定された資源であることを特徴とする端末を提供する。

本発明に係ると、半静的に設定される資源を用いて、相対的に短いレイテンシの要求事項（及び／又は相対的に高い信頼性の要求事項）を有するデータ通信を行うので、オーバーヘッドの問題及びタイムラインの問題が解決できる。

本発明が適用され得る無線通信システムを例示する。ユーザープレーン（ｕｓｅｒｐｌａｎｅ）に対する無線プロトコルの構造（ｒａｄｉｏｐｒｏｔｏｃｏｌａｒｃｈｉｔｅｃｔｕｒｅ）を示したブロック図である。コントロールプレーン（ｃｏｎｔｒｏｌｐｌａｎｅ）に対する無線プロトコルの構造を示したブロック図である。プリエンプションベースのｅＭＢＢと、ＵＲＬＬＣ送信の多重化と、プリエンプション指示情報の一例を概略的に示したものである。アップリンクの承認がないアップリンク送信繰り返しの一例を概略的に示したものである。ＥＭＢＢ構造の一例を概略的に示したものである。本発明の一実施例に係る、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法のフローチャートである。提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の一例に対するフローチャートである。ＥＭＢＢ領域にＲＧ＿ＴＹＰＥ＃Ａの資源とＲＧ＿ＴＹＰＥ＃Ｂの資源が位置する一例を概略的に示した例である。ＥＭＢＢ領域の外にＲＧ＿ＴＹＰＥ＃Ａの資源が位置する一例を概略的に示した例である。ＥＭＢＢに対する基準信号を、ＲＧ＿ＴＹＰＥ＃Ｂの資源が用いる一例を概略的に示した例である。提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の別の例に対するフローチャートである。提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法のまた別の例に対するフローチャートである。提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法のまた別の例に対するフローチャートである。提案方法＃２による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の一例に対するフローチャートである。提案方法＃４による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の一例に対するフローチャートである。本発明の実施例が具現される端末を示したブロック図である。

図１は、本発明が適用され得る無線通信システムを例示する。これは、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＭＴＳＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）、またはＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）／ＬＴＥ−Ａシステムと呼ばれることができる。

Ｅ−ＵＴＲＡＮは、端末１０（ＵｓｅｒＥｑｕｉｐｍｅｎｔ、ＵＥ）にコントロールプレーン（ｃｏｎｔｒｏｌｐｌａｎｅ）とユーザープレーン（ｕｓｅｒｐｌａｎｅ）を提供する基地局２０（ＢａｓｅＳｔａｔｉｏｎ、ＢＳ）とを含む。端末１０は、固定されるか、または移動性を有することができ、ＭＳ（Ｍｏｂｉｌｅｓｔａｔｉｏｎ）、ＵＴ（ＵｓｅｒＴｅｒｍｉｎａｌ）、ＳＳ（ＳｕｂｓｃｒｉｂｅｒＳｔａｔｉｏｎ）、ＭＴ（ｍｏｂｉｌｅｔｅｒｍｉｎａｌ）、無線機器（ＷｉｒｅｌｅｓｓＤｅｖｉｃｅ）等、他の用語で呼ばれることができる。基地局２０は、端末１０と通信する固定された支点（ｆｉｘｅｄｓｔａｔｉｏｎ）をいい、ｅＮＢ（ｅｖｏｌｖｅｄ-ＮｏｄｅＢ）、ＢＴＳ（ＢａｓｅＴｒａｎｓｃｅｉｖｅｒＳｙｓｔｅｍ）、アクセスポイント（ＡｃｃｅｓｓＰｏｉｎｔ）等、他の用語で呼ばれることができる。

基地局２０は、Ｘ２インターフェースを介して互いに接続されることができる。基地局２０は、Ｓ１インターフェースを介してＥＰＣ（ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ）３０、さらに詳細には、Ｓ１-ＭＭＥを介してＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）とＳ１-Ｕを介してＳ−ＧＷ（ＳｅｒｖｉｎｇＧａｔｅｗａｙ）と接続される。

ＥＰＣ３０は、ＭＭＥ、Ｓ−ＧＷ及びＰ−ＧＷ（ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋ−Ｇａｔｅｗａｙ）から構成される。ＭＭＥは、端末の接続情報または端末の能力に関する情報を有しており、このような情報は、端末の移動性管理に主に使用される。Ｓ−ＧＷは、Ｅ−ＵＴＲＡＮを終端点として有するゲートウェイであり、Ｐ−ＧＷは、ＰＤＮを終端点として有するゲートウェイである。

端末とネットワークとの間の無線インターフェースプロトコル（ＲａｄｉｏＩｎｔｅｒｆａｃｅＰｒｏｔｏｃｏｌ）の層は、通信システムにおいて広く知られた開放型システム間相互接続（ＯｐｅｎＳｙｓｔｅｍＩｎｔｅｒｃｏｎｎｅｃｔｉｏｎ；ＯＳＩ）基準モデルの下位３個層に基づいてＬ１（第１層）、Ｌ２（第２層）、Ｌ３（第３層）に区分されることができるが、この中で第１層に属する物理層は、物理チャネル（ＰｈｙｓｉｃａｌＣｈａｎｎｅｌ）を利用した情報送信サービス（ＩｎｆｏｒｍａｔｉｏｎＴｒａｎｓｆｅｒＳｅｒｖｉｃｅ）を提供し、第３層に位置するＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）層は、端末とネットワークとの間に無線資源を制御する役割を行う。このために、ＲＲＣ層は、端末と基地局との間のＲＲＣメッセージを交換する。

図２は、ユーザープレーン（ｕｓｅｒｐｌａｎｅ）に対する無線プロトコル構造（ｒａｄｉｏｐｒｏｔｏｃｏｌａｒｃｈｉｔｅｃｔｕｒｅ）を示したブロック図である。図３は、コントロールプレーン（ｃｏｎｔｒｏｌｐｌａｎｅ）に対する無線プロトコル構造を示したブロック図である。ユーザープレーンは、ユーザーデータ送信のためのプロトコルスタック（ｐｒｏｔｏｃｏｌｓｔａｃｋ）で、コントロールプレーンは、制御信号送信のためのプロトコルスタックである。

図２及び３を参照すると、物理層（ＰＨＹ（ｐｈｙｓｉｃａｌ）ｌａｙｅｒ）は、物理チャネル（ｐｈｙｓｉｃａｌＣｈａｎｎｅｌ）を利用して上位層に情報送信サービス（ｉｎｆｏｒｍａｔｉｏｎ tｒａｎｓｆｅｒ sｅｒｖｉｃｅ）を提供する。物理層は、上位層であるＭＡＣ（ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌ）層とは送信チャネル（ｔｒａｎｓｐｏｒｔｃｈａｎｎｅｌ）を介して接続されている。送信チャネルを介してＭＡＣ層と物理層との間にデータが移動する。送信チャネルは、無線インターフェースを介してデータがどのようにどんな特徴で送信されるかによって分類される。

互いに異なる物理層の間、すなわち送信機と受信機の物理層の間は、物理チャネルを介してデータが移動する。前記物理チャネルは、ＯＦＤＭ（ＯｒｔｈｏｇｏｎａｌＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ）方式で変調されることができ、時間と周波数を無線資源として活用する。

ＭＡＣ層の機能は、論理チャネルと送信チャネルとの間のマッピング及び論理チャネルに属するＭＡＣＳＤＵ（ｓｅｒｖｉｃｅｄａｔａｕｎｉｔ）の送信チャネル上へ物理チャネルに提供される送信ブロック（ｔｒａｎｓｐｏｒｔｂｌｏｃｋ）への多重化／逆多重化を含む。ＭＡＣ層は、論理チャネルを介してＲＬＣ（ＲａｄｉｏＬｉｎｋＣｏｎｔｒｏｌ）層にサービスを提供する。

ＲＬＣ層の機能は、ＲＬＣＳＤＵの接続（ｃｏｎｃａｔｅｎａｔｉｏｎ）、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）及び再結合（ｒｅａｓｓｅｍｂｌｙ）を含む。無線ベアラー（ＲａｄｉｏＢｅａｒｅｒ；ＲＢ）が要求する多様なＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）を保障するために、ＲＬＣ層は、透明モード（ＴｒａｎｓｐａｒｅｎｔＭｏｄｅ、ＴＭ）、非確認モード（ＵｎａｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ、ＵＭ）及び確認モード（ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ、ＡＭ）の３通りの動作モードを提供する。ＡＭＲＬＣは、ＡＲＱ（ａｕｔｏｍａｔｉｃｒｅｐｅａｔｒｅｑｕｅｓｔ）を介してエラー訂正を提供する。

ＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）層は、コントロールプレーンにおいてのみ定義される。ＲＲＣ層は、無線ベアラーの設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）、再設定（ｒｅ−ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び解除（ｒｅｌｅａｓｅ）と関連して、論理チャネル、送信チャネル及び物理チャネルの制御を担当する。ＲＢは、端末とネットワークとの間のデータ伝達のために、第１層（ＰＨＹ層）及び第２層（ＭＡＣ層、ＲＬＣ層、ＰＤＣＰ層）により提供される論理的経路を意味する。

ユーザープレーンでのＰＤＣＰ（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ）層の機能は、ユーザーデータの伝達、ヘッダ圧縮（ｈｅａｄｅｒｃｏｍｐｒｅｓｓｉｏｎ）及び暗号化（ｃｉｐｈｅｒｉｎｇ）を含む。コントロールプレーンでのＰＤＣＰ（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ）層の機能は、コントロールプレーンデータの伝達及び暗号化／整合性保護（ｉｎｔｅｇｒｉｔｙｐｒｏｔｅｃｔｉｏｎ）を含む。

ＲＢが設定されるということは、特定サービスを提供するために無線プロトコル層及びチャネルの特性を規定し、各々の具体的なパラメータ及び動作方法を設定する過程を意味する。ＲＢは、またＳＲＢ（ＳｉｇｎａｌｉｎｇＲＢ）とＤＲＢ（ＤａｔａＲＢ）の２通りに分けられることができる。ＳＲＢは、コントロールプレーンにおいてＲＲＣメッセージを送信する通路として使用され、ＤＲＢは、ユーザープレーンにおいてユーザデータを送信する通路として使用される。

端末のＲＲＣ層とＥ-ＵＴＲＡＮのＲＲＣ層との間にＲＲＣ接続（ＲＲＣＣｏｎｎｅｃｔｉｏｎ）が確立されると、端末は、ＲＲＣ接続（ＲＲＣｃｏｎｎｅｃｔｅｄ）状態にあるようになり、そうでない場合、ＲＲＣアイドル（ＲＲＣｉｄｌｅ）状態にあるようになる。

ネットワークにおいて端末にデータを送信するダウンリンク送信チャネルには、システム情報を送信するＢＣＨ（ＢｒｏａｄｃａｓｔＣｈａｎｎｅｌ）とその以外にユーザートラフィックまたは制御メッセージを送信するダウンリンクＳＣＨ（ＳｈａｒｅｄＣｈａｎｎｅｌ）がある。ダウンリンクマルチキャストまたはブロードキャストサービスのトラフィックまたは制御メッセージの場合、ダウンリンクＳＣＨを介して送信されることもでき、または別のダウンリンクＭＣＨ（ＭｕｌｔｉｃａｓｔＣｈａｎｎｅｌ）を介して送信されることもできる。一方、端末においてネットワークにデータを送信するアップリンク送信チャネルには、初期制御メッセージを送信するＲＡＣＨ（ＲａｎｄｏｍＡｃｃｅｓｓＣｈａｎｎｅｌ）とそれ以外にユーザトラフィックまたは制御メッセージを送信するアップリンクＳＣＨ（ＳｈａｒｅｄＣｈａｎｎｅｌ）がある。

送信チャネル上位にあり、送信チャネルにマッピングされる論理チャネル（ＬｏｇｉｃａｌＣｈａｎｎｅｌ）には、ＢＣＣＨ（ＢｒｏａｄｃａｓｔＣｏｎｔｒｏｌＣｈａｎｎｅｌ）、ＰＣＣＨ（ＰａｇｉｎｇＣｏｎｔｒｏｌＣｈａｎｎｅｌ）、ＣＣＣＨ（ＣｏｍｍｏｎＣｏｎｔｒｏｌＣｈａｎｎｅｌ）、ＭＣＣＨ（ＭｕｌｔｉｃａｓｔＣｏｎｔｒｏｌＣｈａｎｎｅｌ）、ＭＴＣＨ（ＭｕｌｔｉｃａｓｔＴｒａｆｆｉｃＣｈａｎｎｅｌ）などがある。

物理チャネル（ＰｈｙｓｉｃａｌＣｈａｎｎｅｌ）は、時間領域で複数のＯＦＤＭシンボルと周波数領域で複数の副搬送波（Ｓｕｂ-ｃａｒｒｉｅｒ）とから構成される。一つのサブフレーム（Ｓｕｂ-ｆｒａｍｅ）は、時間領域で複数のＯＦＤＭシンボル（Ｓｙｍｂｏｌ）から構成される。資源ブロックは、資源割り当て単位であって、複数のＯＦＤＭシンボルと複数の副搬送波（ｓｕｂ-ｃａｒｒｉｅｒ）から構成される。また、各サブフレームは、ＰＤＣＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ）すなわち、Ｌ１／Ｌ２制御チャネルのために該当サブフレームの特定ＯＦＤＭシンボル（例、第１番目のＯＦＤＭシンボル）の特定副搬送波を利用できる。ＴＴＩ（ＴｒａｎｓｍｉｓｓｉｏｎＴｉｍｅＩｎｔｅｒｖａｌ）は、サブフレーム送信の単位時間である。

＜Ｖ２Ｘ（ＶＥＨＩＣＬＥ−ＴＯ−Ｘ）通信＞

前述したように、一般にＤ２Ｄ動作は、近接した機器間の信号の送受信という点で多様な長所を有し得る。例えば、Ｄ２Ｄ端末は、高い転送レート及び低い遅延を有し、データ通信を行うことができる。また、Ｄ２Ｄ動作は、基地局に集中するトラフィックを分散させることができ、Ｄ２Ｄ動作を行う端末が中継器の役割をすれば、基地局のカバレッジを拡張させる役割もすることができる。前述したＤ２Ｄ通信の拡張で車両間の信号の送受信を含み、車両（ＶＥＨＩＣＬＥ）と関連した通信を特別にＶ２Ｘ（ＶＥＨＩＣＬＥ−ＴＯ−Ｘ）通信と呼ぶ。

ここで、一例として、Ｖ２Ｘ（ＶＥＨＩＣＬＥ−ＴＯ−Ｘ）における‘Ｘ’の用語は、ＰＥＤＥＳＴＲＩＡＮ（ＣＯＭＭＵＮＩＣＡＴＩＯＮＢＥＴＷＥＥＮＡＶＥＨＩＣＬＥＡＮＤＡＤＥＶＩＣＥＣＡＲＲＩＥＤＢＹＡＮＩＮＤＩＶＩＤＵＡＬ（例）ＨＡＮＤＨＥＬＤＴＥＲＭＩＮＡＬＣＡＲＲＩＥＤＢＹＡＰＥＤＥＳＴＲＩＡＮ、ＣＹＣＬＩＳＴ、ＤＲＩＶＥＲＯＲＰＡＳＳＥＮＧＥＲ）（Ｖ２Ｐ）、ＶＥＨＩＣＬＥ（ＣＯＭＭＵＮＩＣＡＴＩＯＮＢＥＴＷＥＥＮＶＥＨＩＣＬＥＳ）（Ｖ２Ｖ）、ＩＮＦＲＡＳＴＲＵＣＴＵＲＥ／ＮＥＴＷＯＲＫ（ＣＯＭＭＵＮＩＣＡＴＩＯＮＢＥＴＷＥＥＮＡＶＥＨＩＣＬＥＡＮＤＡＲＯＡＤＳＩＤＥＵＮＩＴ（ＲＳＵ）／ＮＥＴＷＯＲＫ（例）ＲＳＵＩＳＡＴＲＡＮＳＰＯＲＴＡＴＩＯＮＩＮＦＲＡＳＴＲＵＣＴＵＲＥＥＮＴＩＴＹ（例）ＡＮＥＮＴＩＴＹＴＲＡＮＳＭＩＴＴＩＮＧＳＰＥＥＤＮＯＴＩＦＩＣＡＴＩＯＮＳ）ＩＭＰＬＥＭＥＮＴＥＤＩＮＡＮｅＮＢＯＲＡＳＴＡＴＩＯＮＡＲＹＵＥ）（Ｖ２Ｉ／Ｎ）等を意味する。また、一例として、提案方式に関する説明の便宜のために、歩行者（或いは人間）が所持した（Ｖ２Ｐ通信関連）デバイスを“Ｐ−ＵＥ”と名付け、ＶＥＨＩＣＬＥに設置された（Ｖ２Ｘ通信関連）デバイスを“Ｖ−ＵＥ”と名付ける。さらに、一例として、本発明で‘エンティティ（ＥＮＴＩＴＹ）’の用語はＰ−ＵＥ及び／又はＶ−ＵＥ及び／又はＲＳＵ（／ＮＥＴＷＯＲＫ／ＩＮＦＲＡＳＴＲＵＣＴＵＲＥ）と解釈され得る。

Ｖ２Ｘ端末は、事前に定義された（或いはシグナリングされた）リソースプール（ＲＥＳＯＵＲＣＥＰＯＯＬ）上で、メッセージ（或いはチャネル）送信を行うことができる。ここで、リソースプールは、端末がＶ２Ｘ動作を行うように（或いはＶ２Ｘ動作を行うことができる）事前に定義された資源を意味し得る。このとき、リソースプールは、例えば、時間−周波数の側面で定義され得る。

一方、Ｖ２Ｘにおいて、モード３は、基地局によるスケジューリングモードに該当し、モード４は、端末の自律スケジューリングモードに該当し得る。ここで、モード４による端末は、センシング（ＳＥＮＳＩＮＧ）に基づいて送信資源を決定した後、決定された前記送信資源を介してＶ２Ｘ通信を行うことを意味し得る。

＜５Ｇ（５^th ｇｅｎｅｒａｔｉｏｎ）＞

４Ｇ（４^thｇｅｎｅｒａｔｉｏｎ）通信システムの商用化以降、増加傾向にある無線データのトラフィック需要を満たすために、改善した５Ｇ（５^thｇｅｎｅｒａｔｉｏｎ）通信システム又はｐｒｅ−５Ｇ通信システムを開発するための努力が行われている。このような理由で、５Ｇ通信システム又はｐｒｅ−５Ｇ通信システムは、４Ｇネットワーク以降（Ｂｅｙｏｎｄ４ＧＮｅｔｗｏｒｋ）の通信システム又はＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）システム以降（ＰｏｓｔＬＴＥ）のシステムと呼ばれている。高いデータ転送レートを達成するために、５Ｇ通信システムは超高周波（ｍｍＷａｖｅ）帯域（例えば、６０ギガ（６０ＧＨｚ）帯域のような）での具現が考慮されている。超高周波帯域での電波の経路損失の緩和及び電波の伝達距離を増加させるために、５Ｇ通信システムではビームフォーミング（ｂｅａｍｆｏｒｍｉｎｇ）、大規模配列多重入出力（ｍａｓｓｉｖｅＭＩＭＯ）、全次元多重入出力（ＦｕｌｌＤｉｍｅｎｓｉｏｎａｌＭＩＭＯ、ＦＤ−ＭＩＭＯ）、アレイアンテナ（ａｒｒａｙａｎｔｅｎｎａ）、アナログビーム形成（ａｎａｌｏｇｂｅａｍ−ｆｏｒｍｉｎｇ）、及び大規模アンテナ（ｌａｒｇｅｓｃａｌｅａｎｔｅｎｎａ）技術が論議されている。また、システムのネットワーク改善のために、５Ｇ通信システムでは進化した小型セル、改善した小型セル（ａｄｖａｎｃｅｄｓｍａｌｌｃｅｌｌ）、クラウド無線アクセスネットワーク（ｃｌｏｕｄｒａｄｉｏａｃｃｅｓｓｎｅｔｗｏｒｋ、ｃｌｏｕｄＲＡＮ）、超高密度ネットワーク（ｕｌｔｒａ−ｄｅｎｓｅｎｅｔｗｏｒｋ）、機器間通信（ＤｅｖｉｃｅｔｏＤｅｖｉｃｅｃｏｍｍｕｎｉｃａｔｉｏｎ、Ｄ２Ｄ）、無線バックホール（ｗｉｒｅｌｅｓｓｂａｃｋｈａｕｌ）、移動ネットワーク（ｍｏｖｉｎｇｎｅｔｗｏｒｋ）、協力通信（ｃｏｏｐｅｒａｔｉｖｅｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＣｏＭＰ（ＣｏｏｒｄｉｎａｔｅｄＭｕｌｔｉ−Ｐｏｉｎｔｓ）、及び受信干渉除去（ｉｎｔｅｒｆｅｒｅｎｃｅｃａｎｃｅｌｌａｔｉｏｎ）等の技術開発が行われている。その他にも、５Ｇシステムでは、進歩したコーディング変調（ＡｄｖａｎｃｅｄＣｏｄｉｎｇＭｏｄｕｌａｔｉｏｎ、ＡＣＭ）方式であるＦＱＡＭ（ＨｙｂｒｉｄＦｒｅｑｕｅｎｃｙＳｈｉｆｔＫｅｙｉｎｇａｎｄＱｕａｄｒａｔｕｒｅＡｍｐｌｉｔｕｄｅＭｏｄｕｌａｔｉｏｎ）及びＳＷＳＣ（ＳｌｉｄｉｎｇＷｉｎｄｏｗＳｕｐｅｒｐｏｓｉｔｉｏｎＣｏｄｉｎｇ）と、進歩した接続技術であるＦＢＭＣ（ＦｉｌｔｅｒＢａｎｋＭｕｌｔｉＣａｒｒｉｅｒ）、ＮＯＭＡ（ＮｏｎＯｒｔｈｏｇｏｎａｌＭｕｌｔｉｐｌｅＡｃｃｅｓｓ）、及びＳＣＭＡ（ＳｐａｒｓｅＣｏｄｅＭｕｌｔｉｐｌｅＡｃｃｅｓｓ）等が開発されている。

一方、インターネットは、人間が情報を生成し消費する人間中心の連結網から、物など分散した構成要素の間に情報を取り交わして処理するＩｏＴ（ＩｎｔｅｒｎｅｔｏｆＴｈｉｎｇｓ、モノのインターネット）網に進化している。クラウドサーバーなどとの接続を介したビッグデータ（Ｂｉｇｄａｔａ）処理技術などがＩｏＴ技術に結合されたＩｏＥ（ＩｎｔｅｒｎｅｔｏｆＥｖｅｒｙｔｈｉｎｇ）技術も台頭している。ＩｏＴを具現するために、センシング技術、有無線通信及びネットワークインフラ、サービスインターフェース技術、及び保安技術のような技術要素が求められ、最近では、物の間の連結のためのセンサネットワーク（ｓｅｎｓｏｒｎｅｔｗｏｒｋ）、物の通信（ＭａｃｈｉｎｅｔｏＭａｃｈｉｎｅ、Ｍ２Ｍ）、ＭＴＣ（ＭａｃｈｉｎｅＴｙｐｅＣｏｍｍｕｎｉｃａｔｉｏｎ）などの技術が研究されている。ＩｏＴ環境では、接続された物で生成されたデータを収集、分析し、人間の生に新しい価値を創出する知能型ＩＴ（ＩｎｔｅｒｎｅｔＴｅｃｈｎｏｌｏｇｙ）サービスが提供されることができる。ＩｏＴは、既存のＩＴ（ｉｎｆｏｒｍａｔｉｏｎｔｅｃｈｎｏｌｏｇｙ）技術と多様な産業間の融合及び複合を通じて、スマートホーム、スマートビルディング、スマートシティ、スマートカーあるいはコネックティドカー、スマートグリッド、ヘルスケア、スマート家電、先端医療サービスなどの分野に応用されることができる。

これによって、５Ｇ通信システムをＩｏＴ網に適用するための多様な試みが行われている。例えば、センサーネットワーク、物の通信、ＭＴＣなどの技術が５Ｇ通信技術がビームフォーミング、ＭＩＭＯ、及びアレイアンテナなどの技法によって具現されているものである。前記で説明したビッグデータ処理技術としてクラウド無線アクセスネットワークが適用されることも、５Ｇ技術とＩｏＴ技術の融合の一例であると言える。

２０２０年頃に初期の商業化が予想される５世代（５Ｇ）移動通信は、産業及び学界の多様な候補技術に対する全世界の技術活動で、最近ではモメンタムが増加している。５Ｇ移動通信の候補要素は、ビームフォーミング利得を提供し、増加した容量を支援するための、レガシーセルラ周波数帯域から高周波数までの大規模アンテナ技術、多様な要求事項を有する各種サービス／アプリケーションを柔軟に収容するための新たな波形（例えば、新たな無線アクセス技術（ｒａｄｉｏａｃｃｅｓｓｔｅｃｈｎｏｌｏｇｙ；ＲＡＴ））、大規模接続を支援するための新たな多重アクセス方式等を含む。ＩＴＵ（ＩｎｔｅｒｎａｔｉｏｎａｌＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎＵｎｉｏｎ）は、２０２０年以降、ＩＭＴ（ＩｎｔｅｒｎａｔｉｏｎａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ）の使用シナリオを、ｅＭＢＢ（ｅｎｈａｎｃｅｄｍｏｂｉｌｅｂｒｏａｄｂａｎｄ）、大規模ＭＴＣ（ｍａｃｈｉｎｅｔｙｐｅｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＵＲＬＬ（ｕｌｔｒａｒｅｌｉａｂｌｅａｎｄｌｏｗｌａｔｅｎｃｙ）通信のような３つの主要グループに分類した。また、ＩＴＣは、秒当たり２０ギガバイト（Ｇｂ／ｓ）の最大のデータ速度、秒当たり１００メガバイト（Ｍｂ／ｓ）のユーザー経験のデータ速度、３倍のスペクトル効率の改善、時間当たり最大５００キロメートル（ｋｍ／ｈ）の移動性支援、１ミリ秒（ｍｓ）のレイテンシ、１０６個の装置／ｋｍ²の連結密度、１００倍のネットワークエネルギー効率の向上、及び１０Ｍｂ／ｓ／ｍ²の面積のトラフィック容量のような目標の要求事項を明示した。全ての要求事項を同時に満たす必要はないが、５Ｇネットワークの設計は、前記要求事項のうち一部を満たす多様なアプリケーションを使用ケース別に支援することができる柔軟性を提供するための案（ｓｏｌｕｔｉｏｎ）が要求される。

＜ＵＲＬＬＣ（Ｕｌｔｒａ−ｒｅｌｉａｂｉｌｉｔｙｌｏｗ−ｌａｔｅｎｃｙｃｏｍｍｕｎｉｃａｔｉｏｎ）及びｅＭＢＢ（ｅｎｈａｎｃｅｄＭｏｂｉｌｅＢｒｏｄＢａｎｄ）＞

ＵＲＬＬＣとは、高信頼低遅延通信（Ｕｌｔｒａ−ｒｅｌｉａｂｉｌｉｔｙｌｏｗ−ｌａｔｅｎｃｙｃｏｍｍｕｎｉｃａｔｉｏｎ）の略字であって、ｅＭＢＢ（ｅｎｈａｎｃｅｄＭｏｂｉｌｅＢｒｏｄＢａｎｄ）通信に比べて、より低いブロックエラー率と、より短い送信単位及びダウンリンクに対するより速いアップリンクのフィードバックを指向している。さらに、ＵＲＬＬＣとｅＭＢＢ通信に関する送信特徴は下記の通りである。

ｅＭＢＢ送信（ｅＭＢＢｔｒａｎｓｍｉｓｓｉｏｎ）

− 相対的に中間乃至高いトラフィックサイズ（Ｒｅｌａｔｉｖｅｌｙｍｅｄｉｕｍｔｏｈｉｇｈｔｒａｆｆｉｃｓｉｚｅ）

− 到着率の多様な範囲（Ｖａｒｉｏｕｓｒａｎｇｅｏｆａｒｒｉｖａｌｒａｔｅ）

− 相対的に長い送信区間、例えば、１ｍｓ（Ｒｅｌａｔｉｖｅｌｙｌｏｎｇｔｒａｎｓｍｉｓｓｉｏｎｄｕｒａｔｉｏｎ（ｅ．ｇ．１ｍｓ））

ＵＲＬＬＣ送信（ＵＲＬＬＣｔｒａｎｓｍｉｓｓｉｏｎ）

− 相対的に低いトラフィックサイズ（Ｒｅｌａｔｉｖｅｌｙｌｏｗｔｒａｆｆｉｃｓｉｚｅ）

− 相対的に低い到着率（Ｒｅｌａｔｉｖｅｌｙｌｏｗａｒｒｉｖａｌｒａｔｅ）

− 極低レイテンシの要求、例えば、０．５、１ｍｓ（Ｅｘｔｒｅｍｅｌｙｌｏｗｌａｔｅｎｃｙｒｅｑｕｉｒｅｍｅｎｔｓ（ｅ．ｇ．０．５、１ｍｓ））

− 相対的に短い送信区間、例えば、２ＯＦＤＭシンボル（Ｒｅｌａｔｉｖｅｌｙｓｈｏｒｔｔｒａｎｓｍｉｓｓｉｏｎｄｕｒａｔｉｏｎ（ｅ．ｇ．２ＯＦＤＭｓｙｍｂｏｌｓ））

− 緊急なサービス／メッセージ（Ｕｒｇｅｎｔｓｅｒｖｉｃｅ／ｍｅｓｓａｇｅ）

図４は、プリエンプションベースのｅＭＢＢと、ＵＲＬＬＣ送信の多重化と、プリエンプション指示情報の一例を概略的に示したものである。

Ｒｅｌ−１５ＮＲにおいて、ＵＲＬＬＣは、ダウンリンクではｅＭＢＢとＵＲＬＬＣ間の効率的な多重化（ｍｕｌｔｉｐｌｅｘｉｎｇ）を支援するための一環として、プリエンプション（ｐｒｅ−ｅｍｐｔｉｏｎ）手続とプリエンプション指示に対する構成及び送信方法を支援する。

より具体的に、Ｒｅｌ−１５ＮＲにおいて、ＵＲＬＬＣに対するトラフィックは間欠的に発生することを仮定し、前記の場合、ＵＲＬＬＣ送信は、ｅＭＢＢに対する送信途中に発生し得る。

既に送信中である、或いはスケジューリングが完了した他の信号の一部資源を取って他の信号の送信に使用する動作をプリエンプション手続で説明されることができ、これは、間欠的に発生するＵＲＬＬＣ送信をｅＭＢＢ送信リソースの一部を介して、遅延することなく行うことを許容する。

他の信号によって一部情報が損失変更された信号の検出及び複号性能を改善するためには、該当損失及び変更された部分を再度端末に指示し、該当部分を複号時に除外させる必要がある。

Ｒｅｌ−１５ＮＲにおいては、プリエンプション指示を複数の端末が受信することができるダウンリンク制御情報を介して送信することを支援する。プリエンプション指示の単位は、損失／変更された領域を含むコードブロックグループ、或いはシンボルグループ、或いはリソースブロックとシンボルとの組み合わせグループであり得る。

図５は、アップリンクの承認がないアップリンク送信の繰り返しの一例を概略的に示したものである。

Ｒｅｌ−１５ＮＲ（ＮｅｗＲａｄｉｏａｃｃｅｓｓｔｅｃｈｎｏｌｏｇｙ）において、ＵＲＬＬＣは、アップリンクでは基地局の指示なしで端末がアップリンク送信する動作を支援する。上位層の設定で動作するモードと、上位層で一部情報の設定後にダウンリンク制御情報にアップリンクの承認がないアップリンク送信の活性化を指示するモードがある。

複数の端末は同一のリソースを共有し、互いのアップリンク送信は互いに衝突し得る。従って、Ｒｅｌ−１５ＮＲにおいては、前記衝突の状況でもアップリンク送信の端末を区分するために、独立した基準信号情報／時間−周波数資源リソースを設定する。

前記衝突時、再送信による遅延を防止するための目的で繰り返し送信を支援する。基地局が一部の繰り返し送信だけで複号を行えるように、繰り返しリソース間の複号に必要な情報を送信周期と送信周期内の繰り返し送信の順で固定／設定する。

一部の実施例において、“サブフレーム”及び“時間スロット”は、相互交換的に使用されることができる。本発明の一部実施例において、“サブフレーム”は送信時間間隔（ＴＴＩ）を指称し、これは、端末のデータの送／受信のための“時間スロット”のアグリゲイション（ａｇｇｒｅｇａｔｉｏｎ）を含み得る。

以下、本発明について説明する。

前述した通り、データ通信には、例えば、ＵＲＬＬＣ（Ｕｌｔｒａ−ＲｅｌｉａｂｌｅａｎｄＬｏｗＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ）のような相対的に短いレイテンシ（ｌａｔｅｎｃｙ）の要求事項を有するデータ通信と、例えば、ｅＭＢＢ（ｅｎｈａｎｃｅｄＭｏｂｉｌｅＢｒｏａｄｂａｎｄ）のような（ＵＲＬＬＣに比べて）相対的に長いレイテンシの要求事項を有するデータ通信とが存在し得る。

ここで、ｅＭＢＢの場合は、相対的に長いレイテンシの要求事項（及び／又は相対的に低い信頼性（ｒｅｌｉａｂｉｌｉｔｙ）の要求事項）を有するデータ通信に該当するので、ダイナミックＤＣＩ（ｄｏｗｎｌｉｎｋｃｏｎｔｒｏｌｉｎｆｏｒｍａｔｉｏｎ）を介したグラントを用いて、動的にデータ通信を行うとしても（ＵＲＬＬＣに対して動的に通信を行う場合よりは）相対的に問題が生じる余地が低い。

これによって、本発明では、相対的に短いレイテンシの要求事項（及び／又は相対的に高い信頼性の要求事項）を有するデータ通信に対して、半静的に設定された資源を介して通信を行う方法と、これを用いる端末に対する構成を提供しようとする。

一例として、下記の提案方式は、（事前に）半静的に設定（／シグナリング）された（周期的な）資源を介して、相対的に短い“ＬＡＴＥＮＣＹ”（及び／又は高い“ＲＥＬＩＡＢＩＬＩＴＹ”の要求事項）を有するデータ（／サービス）通信（例えば、ＵＲＬＬＣ、Ｖ２Ｘ）（ＬＬＴＣ＿ＳＶＣ）を効率的に支援する方法を提案する。

ここで、一例として、以下では説明の便宜のために、（ＬＬＴＣ＿ＳＶＣのために）半静的に設定（／シグナリング）された（周期的な）資源を“ＵＲ＿ＳＰＳＲＳＣ”と名付ける。

ここで、一例として、（以下では説明の便宜のために）（ＬＬＴＣ＿ＳＶＣに比べて）相対的に長い“ＬＡＴＥＮＣＹ”の要求事項（及び／又は低い“ＲＥＬＩＡＢＩＬＩＴＹ”の要求事項）を有するデータ（／サービス）通信（例えば、ＥＭＢＢ）を“ＨＬＴＣ＿ＳＶＣ”と名付ける。

ここで、一例として、（以下では説明の便宜のために）ＨＬＴＣ＿ＳＶＣのために（動的に）設定（／シグナリング）された資源を“ＥＭ＿ＤＹＮＲＳＣ”と名付ける。

ここで、一例として、（本発明で）“重なり（ＯＶＥＲＬＡＰ）”のワーディングは、（Ａ）実際に“（周波数）資源”が（全部又は一部）重なる場合、及び／又は（Ｂ）“（周波数）資源”は重ならないが、同じシンボル（或いはＳＬＯＴ）上に二つのチャネル（／信号）の送信が設定された場合等と解釈され得る。

本発明に対する具体的な実施例を説明するに先だって、説明の便宜のために、相対的に長い“ＬＡＴＥＮＣＹ”の要求事項を有するデータ（／サービス）通信のうちの一つであるＥＭＢＢに対する構造を図を通じて概略的に説明する。

図６は、ＥＭＢＢ構造の一例を概略的に示したものである。

図６によると、ＥＭＢＢ６２０は、時間側でスロット単位で定義されることができる。このとき、ＥＭＢＢ６２０の前段にはＲＳ（ｒｅｆｅｒｅｎｃｅｓｉｇｎａｌ）６１０が位置し得る。本図では説明の便宜上、ＥＭＢＢの前段にＲＳが位置することを示しているが、本発明におけるＥＭＢＢ構造で、ＲＳが必ずしもＥＭＢＢの前段に位置しなければならないわけではない。また、本発明におけるＥＭＢＢ構造では、必要の際にＲＳがＥＭＢＢの中段、又は後段などに（前段に位置するＲＳとは別に）さらに位置することもある。

図６で説明したＥＭＢＢサービスのための構造は様々なＥＭＢＢ構造のうち一つの例示を説明したものに過ぎず、代表的なチャネル構造に該当しない。即ち、ＥＭＢＢ構造が図６で説明した内容に限定されるわけではない。

ＵＲＬＬＣのチャネル構造については別に示してはいないが、ＵＲＬＬＣのチャネル構造は、ＥＭＢＢチャネル構造の場合に比べて、スロット（ＳＬＯＴ）を構成するシンボルの数が相対的に小さいことがあり、これは、相対的に短いレイテンシ（ＬＡＴＥＣＹ）を支援するためであり得る。

以下、（事前に）半静的に設定（／シグナリング）された（周期的な）資源を介して、相対的に短い“ＬＡＴＥＮＣＹ”（及び／又は高い“ＲＥＬＩＡＢＩＬＩＴＹ”の要求事項）を有するデータ（／サービス）通信（例えば、ＵＲＬＬＣ、Ｖ２Ｘ）（ＬＬＴＣ＿ＳＶＣ）を効率的に支援する方法の実施例を図を通じて説明する。

図７は、本発明の一実施例に係る、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法のフローチャートである。

図７によると、基地局は相対的に短いレイテンシの要求事項を有するデータ通信のために、半静的に設定された資源（例えば、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ）を設定（／シグナリング）することができる（Ｓ７１０）。

ここで、相対的に短いレイテンシ（ＬＡＴＥＮＣＹ）の要求事項を有するデータ通信のために、半静的に設定された資源が用いられる場合、端末が（基地局から受信された）データ（ＤＡＴＡ）送／受信のスケジューリング関連のＤＣＩをデコーディングするのに要求される（プロセシング）時間を減らすことによって、該当通信を効率的に支援することができる。

以降、端末は、前記資源上で相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ７２０）。

例えば、前記相対的に短いレイテンシの要求事項を有するデータ通信は、ＵＲＬＬＣ（ＵｌｔｒａＲｅｌｉａｂｌｅａｎｄＬｏｗＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ）であり、これよりも相対的に長いレイテンシの要求事項を有するデータ通信は、ＥＭＢＢ（ＥｎｈａｎｃｅｄＭｏｂｉｌｅＢｒｏａｄｂａｎｄ）であり得る。

例えば、前記資源は、第１タイプの資源又は第２タイプの資源のうちの一つの資源であり、前記第１タイプの資源は、パンクチャリング（或いはレートマッチング）が常に適用される資源であり、前記第２タイプの資源は、前記相対的に短いレイテンシの要求事項を有するデータ通信が行われるか否かに応じて、パンクチャリング（或いはレートマッチング）が適用される資源であり得る。

このとき、例えば、前記第２タイプの資源では、前記相対的に短いレイテンシの要求事項を有するデータ通信が行われる場合、前記第２タイプの資源がパンクチャリング（或いはレートマッチング）され、及び前記相対的に短いレイテンシの要求事項を有するデータ通信が行われない場合、前記第２タイプの資源がパンクチャリング（或いはレートマッチング）されないことがある。

例えば、前記第１タイプの資源は、前記第２タイプの資源に比べて、相対的に小さいサイズを有し得る。一例として、常に適用されるパンクチャリング（或いはレートマッチング）による性能減少を緩和させるために、タイプ１の場合、タイプ２に比べて相対的に小さいサイズの前記半静的に設定された資源が割り当てられ得る。

例えば、前記第２タイプの場合、前記半静的に設定される資源上に基準信号（ｒｅｆｅｒｅｎｃｅｓｉｇｎａｌ；ＲＳ）が追加的に（或いは独立に）設定されないことがある。また、第１タイプの場合、前記半静的に設定される資源上に別途の基準信号が設定され得る。

例えば、前記端末は、ネットワークから前記資源の通信方向を指示する情報を受信し得る。

例えば、前記端末は、ネットワークから前記資源が有効な時間区間を受信し得る。

例えば、前記端末は、ネットワークに前記資源に関する補助情報を送信し得る。

このとき、前記補助情報は、前記資源に対して、前記端末がどのくらいの間前記相対的に短いレイテンシの要求事項を有するデータ通信を行うかを指示する情報を含み得る。このとき、前記補助情報は、前記資源に対するパラメータが、前記相対的に短いレイテンシの要求事項を有するデータ通信に適合するか否かに関する情報を含み得る。このとき、前記補助情報は、前記資源のリリース情報又は前記資源の変更要請情報の少なくとも一つ以上を含み得る。

以下、説明の便宜のために、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の具体的な例を後述する。

以下では、端末が相対的に短いレイテンシの要求事項を有するデータ通信のために、半静的に設定された資源を二つのタイプに分けて、無線通信を行う方法について説明する。一例として、前記半静的に設定された二つのタイプの資源（例えば、第１タイプの資源、第２タイプの資源）は、短いレイテンシの要求事項を有するデータ通信をどの程度のレベル／優先順位で保護（ＰＲＯＴＥＣＴＩＯＮ）するかに応じて区分されると見ることもできる。

［提案方法＃１］一例として、事前に設定（／シグナリング）された周波数資源（領域）別に（ＵＬ）ＵＲ＿ＳＰＳＲＳＣを指定（／シグナリング）し、各々の（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ上で下記（一部）規則が適用されるようにし得る。

（例示＃１−１）一例として、事前に設定（／シグナリング）された（ＵＬ）ＵＲ＿ＳＰＳＲＳＣは、（Ａ）（自身の実際のＬＬＴＣ＿ＳＶＣ送信（及び／又は（ＵＬ）ＵＲ＿ＳＰＳＲＳＣの使用）と関係なく）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣに対するパンクチャリング（或いはレートマッチング）を常に適用させなければならない資源タイプ（ＲＧ＿ＴＹＰＥ＃Ａ）、及び／又は（Ｂ）（自身の）実際のＬＬＴＣ＿ＳＶＣ送信（及び／又は（ＵＬ）ＵＲ＿ＳＰＳＲＳＣの使用）可否に応じて、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣに対するパンクチャリング（或いはレートマッチング）を異なって適用させる資源タイプ（ＲＧ＿ＴＹＰＥ＃Ｂ）に区分され得る。

ここで、一例として、ＲＧ＿ＴＹＰＥ＃Ｂの場合、実際にＬＬＴＣ＿ＳＶＣ送信が行われる（及び／又は（ＵＬ）ＵＲ＿ＳＰＳＲＳＣが使用）ときのみ、（該当）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣに対するパンクチャリング（或いはレートマッチング）を適用させるようにし得る。

ここで、一例として、ＲＧ＿ＴＹＰＥ＃Ａは、（同じ（ＳＬＯＴ）時点（及び／又は重なる周波数資源）上で）ＨＬＴＣ＿ＳＶＣ送信なしでＬＬＴＣ＿ＳＶＣ送信のみを行う端末にとって、（該当）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣを（限定的に）利用（及び／又はＲＧ＿ＴＹＰＥ＃Ｂは（同じ（ＳＬＯＴ）時点（及び／又は重なる周波数資源）上で）ＨＬＴＣ＿ＳＶＣ送信とＬＬＴＣ＿ＳＶＣ送信を同時に行う端末にとって、（該当）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣを（限定的に）利用）するようにし得る。

ここで、一例として、ＲＧ＿ＴＹＰＥ＃Ａを利用する端末間で異なるＲＳ資源（例えば、（ＺＡＤＯＦＦ−ＣＨＵＳＥＱＵＥＮＣＥである場合）ＣＹＣＬＩＣＳＨＩＦＴ（及び／又はＲＯＯＴＩＮＤＥＸ）、（アンテナ）ポートなど）を設定（／シグナリング）することによって、効率的な多重化が行われるようにすることもある。ここで、一例として、（該当）ＲＳ資源割り当て（／シグナリング）は、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣＡＣＴＩＶＡＴＩＯＮＤＣＩ（或いは上位層のシグナル（例えば、ＲＲＣ））を介して行われることもある。

（例示＃１−２）一例として、（（例示＃１−１）が適用される場合）ＲＧ＿ＴＹＰＥ＃ＡとＲＧ＿ＴＹＰＥ＃Ｂ間に（ＵＬ）ＵＲ＿ＳＰＳＲＳＣのサイズが異なって設定（／シグナリング）され得る。

ここで、前記説明したように、ＲＧ＿ＴＹＰＥ＃Ａ及び／又はＲＧ＿ＴＹＰＥ＃Ｂは、パンクチャリングが行われ得る資源であるので、ＥＭＢＢのパフォーマンスに直接的な影響を与え得る。特に、ＲＧ＿ＴＹＰＥ＃Ａは、無条件にパンクチャリングが行われるので、ＲＧ＿ＴＹＰＥ＃ＡのサイズがＲＧ＿ＴＹＰＥ＃Ｂよりさらに大きい場合には、相対的にＥＭＢＢの損失が増大するという問題がある。

前記のような問題点を解決するために、ここで、一例として、（常に適用されるパンクチャリング（或いはレートマッチング）による性能減少を緩和させるために）ＲＧ＿ＴＹＰＥ＃Ａの場合、（ＲＧ＿ＴＹＰＥ＃Ｂに比べて）相対的に小さいサイズの（ＵＬ）ＵＲ＿ＳＰＳＲＳＣが割り当て（／シグナリング）られ得る。

（例示＃１−３）一例として、ＲＧ＿ＴＹＰＥ＃Ｂの場合、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ上にＲＳが追加的に（或いは独立に）設定されないことがある。

ここで、一例として、このような場合、同じ（ＳＬＯＴ）時点（及び／又は重なる周波数資源）上で送信されるＨＬＴＣ＿ＳＶＣ関連の（ＵＬ）ＥＭ＿ＤＹＮＲＳＣＲＳに、ＬＬＴＣ＿ＳＶＣデコーディングチャネルの推定が移行されるようにし得る。

ここで、一例として、該当規則の適用は、（ＵＬ）ＥＭ＿ＤＹＮＲＳＣに含まれた（ＵＬ）ＵＲ＿ＳＰＳＲＳＣにＬＬＴＣ＿ＳＶＣ送信が行われるとき、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ上のＲＳ（送信）が省略可能であるとも解釈し得る。

ここで、一例として、（ＲＧ＿ＴＹＰＥ＃Ｂ）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ上でＬＬＴＣ＿ＳＶＣ送信が行われる場合、（（ＵＬ）ＥＭ＿ＤＹＮＲＳＣ上のＨＬＴＣ＿ＳＶＣ送信時とは異なる）事前に設定（／シグナリング）された独立した（シード値（例えば、ＲＮＴＩ、（ＣＥＬＬ）ＩＤ）ベースの）スクランブリングが適用（例えば、基地局が端末のＬＬＴＣ＿ＳＶＣ送信に対するブラインドの検出を容易にするためである）されるようにすることもある。

ここで、（反対の）一例として、ＲＧ＿ＴＹＰＥ＃Ｂの場合、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ上にＲＳが追加的に（或いは独立に）設定されるようにすることもある。

また別の一例として、（反面）ＲＧ＿ＴＹＰＥ＃Ａの場合、（特に、（同じ（ＳＬＯＴ）時点（及び／又は重なる周波数資源）上で）ＨＬＴＣ＿ＳＶＣ送信なしでＬＬＴＣ＿ＳＶＣ送信のみが行われるとき）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ上にＲＳが追加的に（或いは独立に）設定され得る。

以下、理解の便宜のために、提案方法＃１における実施例を図を通じて説明する。

図８は、提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の一例に対するフローチャートである。

図８によると、端末は相対的に短いレイテンシの要求事項を有するデータ通信のために半静的に設定された資源を決定することができる（Ｓ８１０）。このとき、前記資源のタイプは、第１タイプ又は第２タイプであり得る。

例えば、第１タイプは、前記例示＃１−１で説明した（自身の実際のＬＬＴＣ＿ＳＶＣ送信（及び／又は（ＵＬ）ＵＲ＿ＳＰＳＲＳＣの使用）と関係なく）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣに対するパンクチャリング（或いはレートマッチング）を常に適用させなければならない資源タイプ（ＲＧ＿ＴＹＰＥ＃Ａ）（或いはタイプＡ）を意味し得る。また、第２タイプは、前記例示＃１−１で説明した（自身の）実際のＬＬＴＣ＿ＳＶＣ送信（及び／又は（ＵＬ）ＵＲ＿ＳＰＳＲＳＣの使用）可否に応じて、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣに対するパンクチャリング（或いはレートマッチング）を異なって適用させる資源タイプ（ＲＧ＿ＴＹＰＥ＃Ｂ）（或いはタイプＢ）を意味し得る。

以降、端末は、前記資源のタイプに基づき、前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ８２０）。

以下、提案方法＃１の理解の便宜のために、ＥＭＢＢスロットにＲＧ＿ＴＹＰＥ＃ＡとＲＧ＿ＴＹＰＥ＃Ｂが位置する例を図を通じて説明する。

図９は、ＥＭＢＢ領域にＲＧ＿ＴＹＰＥ＃Ａの資源とＲＧ＿ＴＹＰＥ＃Ｂの資源が位置する一例を概略的に示した例である。

図９によると、ＥＭＢＢ資源領域上に、ＲＧ＿ＴＹＰＥ＃Ａの資源とＲＧ＿ＴＹＰＥ＃Ｂの資源が位置し得る。ここで、ＲＧ＿ＴＹＰＥ＃Ａの資源は第１タイプの資源を、且つＲＧ＿ＴＹＰＥ＃Ｂの資源は第２タイプの資源を意味し得る。

ここで、第１タイプ（即ち、ＲＧ＿ＴＹＰＥ＃Ａ）の資源は、第２タイプ（即ち、ＲＧ＿ＴＹＰＥ＃Ｂ）の資源に比べて、相対的に高いレベル／優先順位で、ＵＲＬＬＣのオペレーションをする端末の動作を保護するための資源に該当し得る。

前記説明したように、第１タイプの資源上でＥＭＢＢ動作の実行が設定されたとしても、端末は、前記第１タイプの資源を常にパンクチャリング（或いはレートマッチング）する。

これによって、他の端末が第１タイプの資源上でＵＲＬＬＣに対する通信を行う場合にこれを保護することができ、相対的に短い“ＬＡＴＥＮＣＹ”（及び／又は高い“ＲＥＬＩＡＢＩＬＩＴＹ”の要求事項）を有するデータ（／サービス）通信（例えば、ＵＲＬＬＣ、Ｖ２Ｘ）（ＬＬＴＣ＿ＳＶＣ）を安定的に支援することができる。

ここで、第２タイプ（即ち、ＲＧ＿ＴＹＰＥ＃Ｂ）の資源は、前記説明したように、実際にＵＲＬＬＣ動作が行われる場合にのみ、パンクチャリング（或いはレートマッチング）される資源を意味し得る。即ち、実際にＵＲＬＬＣ動作が行われない場合には、前記資源上でパンクチャリング（或いはレートマッチング）が行われず、ＥＭＢＢデータがオーバーライディングされ得る。

これによって、第２タイプの資源の場合、（ＥＭＢＢデータのスケジューリング関連）グラント検出の誤謬等に影響を受けることがあるので、第１タイプの資源の場合より、相対的にＵＲＬＬＣに対する保護が少なくなることがある。但し、第２タイプの資源は、適応的にＵＲＬＬＣに対するデータが送信されるか、又はＥＭＢＢに対するデータが送信され得るので、第１タイプの資源よりも無線資源の利用効率が増大し得る。

前記説明した図９では、ＥＭＢＢ（スケジューリング）資源領域上にＲＧ＿ＴＹＰＥ＃Ａの資源（或いは第１タイプの資源）とＲＧ＿ＴＹＰＥ＃Ｂの資源（或いは第２タイプの資源）が位置する構成が示されていた。しかし、ＲＧ＿ＴＹＰＥ＃Ａの資源（或いはＲＧ＿ＴＹＰＥ＃Ｂの資源）が必ずしもＥＭＢＢ（スケジューリング）資源領域上に位置する必要はない（即ち、ＲＧ＿ＴＹＰＥ＃Ａの資源は、ＥＭＢＢの（スケジューリング）支援領域を外れ得る）。これを図を通じて説明すると下記の通りである。

図１０は、ＥＭＢＢ（スケジューリング）資源領域の外にＲＧ＿ＴＹＰＥ＃Ａの資源が位置する一例を概略的に示した例である。

図１０によると、ＲＧ＿ＴＹＰＥ＃Ａの資源は図に示されたように、ＥＭＢＢの（スケジューリング）資源領域の外に位置し得る。ここで、ＲＧ＿ＴＹＰＥ＃Ａの資源は第１タイプの資源を、且つＲＧ＿ＴＹＰＥ＃Ｂの資源は第２タイプの資源を意味し得る。

このように、第１タイプ（即ち、ＲＧ＿ＴＹＰＥ＃Ａ）の資源は、ＥＭＢＢの（スケジューリング）資源領域の外に位置し得るので、第１タイプの資源のための別途の基準信号（ｒｅｆｅｒｅｎｃｅｓｉｇｎａｌ；ＲＳ）が存在し得る。

図１０のように、第１タイプの資源は、第１タイプの資源のための基準信号が別に設定され得る。また、第２タイプの資源もやはり、例示＃１−３で説明したように、第２タイプの資源のための基準信号が別に設定され得る。

しかし、第２タイプの資源の場合、必ずしも別の基準信号が設定されなければならないのではなく、第２タイプの資源は、ＥＭＢＢに使用される基準信号を用いて、チャネルの推定も可能である。これを図を通じて説明すると下記の通りである。

図１１は、ＥＭＢＢに対する基準信号を、ＲＧ＿ＴＹＰＥ＃Ｂの資源が用いる一例を概略的に示した例である。

図１１によると、例示＃１−３で説明したように、一例として、同じ（ＳＬＯＴ）時点（及び／又は重なる周波数資源）上で送信されるＨＬＴＣ＿ＳＶＣ関連の（ＵＬ）ＥＭ＿ＤＹＮＲＳＣＲＳに、ＬＬＴＣ＿ＳＶＣデコーディングチャネルの推定が移行されるようにし得る。これに関する具体的な内容は前述した通りであるので、具体的な説明は省略する。

前述したように、端末はＲＧ＿ＴＹＰＥ＃Ａの資源及び／又はＲＧ＿ＴＹＰＥ＃Ｂの資源を用いて、相対的に短いレイテンシの要求事項を有するデータ通信（例えば、ＵＲＬＬＣ）を支援することができる。以下では、説明の便宜のためにＲＧ＿ＴＹＰＥ＃Ａは第１タイプ、ＲＧ＿ＴＹＰＥ＃Ｂは第２タイプと名付けられることができる。

以下では、第１タイプの資源が設定される実施例、第２タイプの資源が設定される実施例、及び第１タイプの資源及び第２タイプの資源がいずれも設定される実施例を図を通じて各々説明する。

図１２は、提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の別の例に対するフローチャートである。

図１２によると、端末は相対的に短いレイテンシの要求事項を有するデータ通信のために半静的に設定された第１タイプの資源を決定することができる（Ｓ１２１０）。

以降、端末は、前記第１タイプの資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ１２２０）。

このように、端末が第１タイプの資源を用いて前記データ通信を行う場合、例えば、ＵＲＬＬＣが相対的に高いレベル／優先順位で保護され得る。ここで、第１タイプの資源に関する具体的な内容と、端末が第１タイプの資源上で無線通信を行う具体的な内容は前述した通りである。

図１３は、提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法のまた別の例に対するフローチャートである。

図１３によると、端末は、相対的に短いレイテンシの要求事項を有するデータ通信のために半静的に設定された第２タイプの資源を決定することができる（Ｓ１３１０）。

以降、端末は、前記第２タイプの資源上で、前記相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ１３２０）。

このように、端末が第２タイプの資源を用いて前記データ通信を行う場合、実際に相対的に短いレイテンシの要求事項を有するデータ通信が行われる場合にのみ、前記第２タイプの資源がパンクチャリングされ、その他の場合には、前記第２資源上で相対的に長いレイテンシを有するデータ通信（例えば、ＥＭＢＢ）が行われ得るので、無線資源の利用効率が増大し得る。ここで、第２タイプの資源に関する具体的な内容と、端末が第２タイプの資源上で無線通信を行う具体的な内容は前述した通りである。

図１２では、第１タイプの資源が設定された場合を中心に、図１３では、第２タイプの資源が設定された場合を中心に説明した。しかし、これは、必ずしも端末が第１タイプの資源のみを使用しなければならないか、或いは必ずしも端末が第２タイプの資源のみを使用しなければならないということを意味するのではない。即ち、端末は、第１タイプの資源及び第２タイプの資源をいずれも用いて、データ通信を行うこともできる。以下、図を通じて第１タイプの資源及び第２タイプの資源を用いてデータ通信を行う例を説明する。

図１４は、提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法のまた別の例に対するフローチャートである。

図１４によると、相対的に短いレイテンシの要求事項を有するデータ通信のために半静的に設定された第１タイプの資源及び第２タイプの資源を決定することができる（Ｓ１４１０）。

以降、端末は、前記第１タイプの資源及び／又は前記第２タイプの資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ１４２０）。ここで、第１タイプの資源及び第２タイプの資源に関する具体的な説明と、端末が前記第１タイプの資源及び／又は第２タイプの資源を用いて無線通信を行う具体的な例は、前述した通りである。

以下では、前記説明した内容に加えて、相対的に短いレイテンシの要求事項を有するデータ通信をより効率的に支援する追加的な構成を説明する。

［提案方法＃２］一例として、（事前に）ＵＲ＿ＳＰＳＲＳＣを設定（／シグナリング）し、追加的なシグナリング（例えば、ＤＣＩ）を介して、（該当）ＵＲ＿ＳＰＳＲＳＣの（実際の）用途（／通信方向）（例えば、ＤＬ／ＵＬＵＲ＿ＳＰＳＲＳＣ）を指定し得る。

ここで、一例として、該当規則が適用される場合、（Ａ）ＤＬＵＲ＿ＳＰＳＲＳＣとＵＬＵＲ＿ＳＰＳＲＳＣが（時間軸で）“ＩＮＴＥＲＬＡＣＩＮＧ”の形態で設定（例えば、（ＬＬＴＣ＿ＳＶＣ関連）ＨＡＲＱＦＥＥＤＢＡＣＫ送／受信に好適な形態）され得、及び／又は（Ｂ）ＤＬ／ＵＬＬＬＴＣ＿ＳＶＣの負荷（比率）によって、（基地局が）ＵＲ＿ＳＰＳＲＳＣの（実際の）用途（／通信方向）を動的に変更することもある。また別の一例として、（事前に）ＤＬＵＲ＿ＳＰＳＲＳＣとＵＬＵＲ＿ＳＰＳＲＳＣが（時間軸で）“ＩＮＴＥＲＬＡＣＩＮＧ”の形態で設定（／シグナリング）されることもある。

以下、理解の便宜のために、提案方法＃２における実施例を、図を通じて説明する。

図１５は、提案方法＃２による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の一例に対するフローチャートである。

図１５によると、端末は、相対的に短いレイテンシの要求事項を有するデータ通信のために半静的に設定された資源を決定することができる（Ｓ１５１０）。ここで、相対的に短いレイテンシの要求事項を有するデータ通信に関する具体的な説明と、前記資源に関する内容は前記説明した通りである。

端末は、ネットワークから前記資源の用途を指示する情報を受信することができる（Ｓ１５２０）。

ＮＲ（ＮｅｗＲａｄｉｏａｃｃｅｓｓｔｅｃｈｎｏｌｏｇｙ；ＮＲ）では、一つのスロット上にアップリンク及びダウンリンクがいずれも設定され得る。即ち、ＮＲでは、スロット構造が可変的に変更され得、これによって、端末は、（該当）ＵＲ＿ＳＰＳＲＳＣの（実際の）用途（／通信方向）（例えば、ＤＬ／ＵＬＵＲ＿ＳＰＳＲＳＣ）を指定する情報をさらに受信し、可変的なアップリンク及び／又はダウンリンク通信を行うことができる。

以降、端末は受信された前記情報に基づき、前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ１５３０）。端末が前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行う具体的な例は、前記説明した通りであるので、重複する叙述は省略する。

［提案方法＃３］一例として、基地局は、事前に定義された（物理層／上位層）シグナリングを介して、端末に（事前に）設定（／シグナリング）された“ＴＩＭＥＤＵＲＡＴＩＯＮ（／ＷＩＮＤＯＷ）”の間にＵＲ＿ＳＰＳＲＳＣが有効であるかを知らせ得る。

ここで、一例として、該当規則が適用される場合、端末は有効なＵＲ＿ＳＰＳＲＳＣ上でのみＬＬＴＣ＿ＳＶＣ送／受信動作（／手続）（例えば、ＬＬＴＣ＿ＳＶＣ受信関連の制御チャネルブラインド検出）を行うことになる。

［提案方法＃４］一例として、端末は（事前に（或いは現在）設定（／シグナリング）された）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣと関連した下記（一部）“ＡＳＳＩＳＴＩＮＦＯＲＭＡＴＩＯＮ”を基地局に報告し得る。

ここで、一例として、複数個の（ＵＬ）ＵＲ＿ＳＰＳＲＳＣが（端末に）設定（／シグナリング）された場合、“ＡＳＳＩＳＴＩＮＦＯＲＭＡＴＩＯＮ”は（各々の）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ別に生成／報告されることもある。

ここで、一例として、特定の端末から、“ＡＳＳＩＳＴＩＮＦＯＲＭＡＴＩＯＮ”を受信した基地局は、該当（特定）端末関連“（ＵＬ）ＵＲ＿ＳＰＳＲＳＣＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ（／ＲＥＡＣＴＩＶＡＴＩＯＮ）（例えば、周期、サブフレームオフセット、ＲＢの個数、ＭＣＳ）”及び／又は“（ＵＬ）ＵＲ＿ＳＰＳＲＳＣＲＥＬＥＡＳＥ”等を（最終）判断／実行することになる。

ここで、一例として、（該当）“ＡＳＳＩＳＴＩＮＦＯＲＭＡＴＩＯＮ”は（事前に（或いは現在）設定（／シグナリング）された）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ（或いは、該当用途に（事前に）独立に（或いは追加的に）設定（／シグナリング）された資源）を介して送信するようにすることもある。

（例示＃４−１）一例として、事前に（或いは現在）設定（／シグナリング）された（ＵＬ）ＵＲ＿ＳＰＳＲＳＣに対して、端末がどのくらいの間ＬＬＴＣ＿ＳＶＣ送信動作を行うかに対する情報。

即ち、端末は、前記資源上で、例えば、ＵＲＬＬＣデータアップリンク送信をどれほど行うかに対する情報を送信し得る。端末が送った情報を通じて、端末がこれ以上アップリンク送信を行わないという点をネットワークが知ることになれば、ネットワークは前記資源を他の端末用途として設定し得る。或いは、端末は、前記資源をＥＭＢＢ用途として使用することもある。

（例示＃４−２）一例として、事前に（或いは現在）設定（／シグナリング）された（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ関連の周期／サブフレームオフセット／ＲＢの個数／ＭＣＳなどのパラメータが端末の（現在）ＬＬＴＣ＿ＳＶＣ送信に適合するかに対する情報（及び／又は端末の（現在）ＬＬＴＣ＿ＳＶＣ送信に適合した（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ関連（ＥＳＴＩＭＡＴＥＤ）周期／サブフレームオフセット／ＲＢの個数／ＭＣＳなどのパラメータに対する情報及び／又は端末の（（現在）ＬＬＴＣ＿ＳＶＣ送信関連）（ＥＳＴＩＭＡＴＥＤ）パケットサイズ）。

即ち、端末は、例示＃４−２のように、適合度の情報を送信し得る。端末が送った前記情報を通じて、ネットワークが設定した資源がミスアライアンスされたという点をネットワークが知ることになった場合、ネットワークは前記資源を再設定し得る。

（例示＃４−３）一例として、端末に（これ以上）有効ではない（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ（設定）情報及び／又は（特定）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ関連のＲＥＬＥＡＳＥ要請及び／又は（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ（設定）変更要請。

以下、理解の便宜のために、提案方法＃４における実施例を図を通じて説明する。

図１６は、提案方法＃４による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の一例に対するフローチャートである。

図１６によると、端末は、相対的に短いレイテンシの要求事項を有するデータ通信のために、半静的に設定された資源を決定することができる（Ｓ１６１０）。

前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ１６２０）。ここで、前記資源に関する内容は前記説明した通りであるので、説明の便宜のために、重複する内容の叙述は省略する。

以降、端末は、ネットワークに前記資源と関連した補助情報を送信することができる（Ｓ１６３０）。ここで、端末が送信する補助情報は、前記提案方法＃４で説明した通りであるので、説明の便宜のために、重複する内容の叙述は省略する。

また別の一例として、基地局は特定の端末に、周波数（／時間）領域上で、ＬＬＴＣ＿ＳＶＣ関連の複数個の（半静的な）（周期的な）アップリンク資源（例えば、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ）を（事前に）設定（／シグナリング）し、そのうちのどれが該当端末に有効な資源であるかを（事前に定義された（物理層／上位層）シグナリングを介して）知らせることもある。

例えば、基地局はＤＣＩを介して、周波数（／時間）領域上で、ＬＬＴＣ＿ＳＶＣ関連の複数個の（半静的な）（周期的な）アップリンク資源（例えば、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ）を（事前に）設定（／シグナリング）し、そのうちのどれが該当端末に有効な資源であるかを、例えば、ＲＲＣシグナリングを介して知らせ得る。

ここで、一例として、（提案方式に関する）説明の便宜のために、基地局が特定の端末に、二つのシンボルにかけた（ＬＬＴＣ＿ＳＶＣ関連）複数個の（アップリンク）周波数資源を設定（／シグナリング）した状況を仮定する。

ここで、一例として、このとき、該当端末は（基地局から（さらに）設定（／シグナリング）された）有効な資源上で、ＬＬＴＣ＿ＳＶＣ関連のＳＲ送信には、一番目のシンボル上の（アップリンク）周波数資源のみを使用し、ＬＬＴＣ＿ＳＶＣ関連のデータの送信には一番目／二番目のシンボルにかけた（アップリンク）周波数資源を使用すると仮定する。

ここで、一例として、このような状況下で、（Ａ）該当端末が（有効な資源上で）ＬＬＴＣ＿ＳＶＣ関連のＳＲ送信とＨＬＴＣ＿ＳＶＣ関連のデータ送信を同時に行わなければならない場合、一番目のシンボル上の（ＬＬＴＣ＿ＳＶＣ関連）（アップリンク）周波数資源上ではＬＬＴＣ＿ＳＶＣ関連のＳＲ送信を行い、二番目のシンボル上の（ＬＬＴＣ＿ＳＶＣ関連）（アップリンク）周波数資源上では、ＨＬＴＣ＿ＳＶＣ関連のデータ送信を行うようにし、及び／又は（Ｂ）該当端末が（有効な資源上で）ＬＬＴＣ＿ＳＶＣ関連のＳＲ送信のみを行わなければならない場合（例えば、ＨＬＴＣ＿ＳＶＣ関連のデータ送信を（同時に）行わない）、一番目／二番目のシンボル上の（ＬＬＴＣ＿ＳＶＣ関連）（アップリンク）周波数資源上でＬＬＴＣ＿ＳＶＣ関連のＳＲを繰り返し送信するようにすることもある。

また別の一例として、ＬＬＴＣ＿ＳＶＣ関連のダウンリンク（半静的な）（周期的な）通信の場合、（端末にとって）ＡＣＫの場合にのみ、（事前に設定（／シグナリング）されたＨＡＲＱタイムラインによって）ＰＵＣＣＨ（ＳＹＭＢＯＬ）送信を行うようにすることもある。

ここで、一例として、該当規則が適用される場合、基地局がＬＬＴＣ＿ＳＶＣ関連のダウンリンクの送信を行わなかったときには、（連動した）ＰＵＣＣＨ（ＳＹＭＢＯＬ）を含んだ資源をダウンリンクの用途に変更して使用し得る。

例えば、端末は、ＡＣＫの場合にのみＰＵＣＣＨ送信を行い、ＮＡＣＫの場合には、ＰＵＣＣＨ送信を行わないことがある。ここで、ＮＡＣＫの場合には、端末が前記のＰＵＣＣＨ送信を行わないので、ネットワークが前記のＰＵＣＣＨ送信が行われるべき資源をダウンリンクのための資源として使用し得る。これによって、本実施例に係る場合には、無線資源を流動的に使用できるので、無線資源の利用効率が増大し得る。

また別の一例として、ＵＬＵＲ＿ＳＰＳＲＳＣとＵＬＥＭ＿ＤＹＮＲＳＣが（同じＳＬＯＴ上で）“ＦＤＭ”された場合、ＵＬＵＲ＿ＳＰＳＲＳＣ上のＬＬＴＣ＿ＳＶＣ関連の送信のための“ＧＵＡＲＡＮＴＥＥＤＰＯＷＥＲ”（及び／又は（同時送信が行われる場合）ＵＬＵＲ＿ＳＰＳＲＳＣ上の送信とＵＬＥＭ＿ＤＹＮＲＳＣ上の送信間の（送信）電力比率値）が設定（／シグナリング）されることもある。ここで、一例として、該当ＧＵＡＲＡＮＴＥＥＤＰＯＷＥＲ（及び／又は（送信）電力比率値）の適用有無は、（実際）ＵＬＵＲ＿ＳＰＳＲＳＣ上のＬＬＴＣ＿ＳＶＣの送信有無に応じて変わることもある。ここで、一例として、ＤＬＵＲ＿ＳＰＳＲＳＣとＤＬＥＭ＿ＤＹＮＲＳＣが（同じＳＬＯＴ上で）“ＦＤＭ”された場合、事前に設定（／シグナリング）された特定のＲＳパワーに対して（Ａ）該当ＲＳが送信されないシンボル上のデータ（送信）パワー比率、及び／又は（Ｂ）該当ＲＳが送信されるシンボル上のデータ（送信）パワー比率等が（ＤＬＵＲ＿ＳＰＳＲＳＣとＤＬＥＭ＿ＤＹＮＲＳＣ間に）独立に設定（／シグナリング）されることもある。ここで、一例として、前記説明した規則が適用される場合、（ＵＬ／ＤＬ）ＵＲ＿ＳＰＳＲＳＣ上の送信と（ＵＬ／ＤＬ）ＥＭ＿ＤＹＮＲＳＣ上の送信のためのＭＣＳ等が異なって設定（／シグナリング）されることもある。

前記説明した提案方式に対する一例もまた、本発明の具現方法のうち一つに含まれ得るので、一種の提案方式と見なされ得ることは明白な事実である。また、前記説明した提案方式は、独立に具現されることもあるが、一部提案方式の組み合わせ（或いは併合）の形態で具現されることもある。一例として、本発明の提案方式が適用されるシステムの範囲は、３ＧＰＰＬＴＥシステム以外に他のシステムにも拡張可能である。一例として、本発明の提案方式は、ＬＬＴＣ＿ＳＶＣが動的に割り当てられた資源を介して行われる場合、及び／又はＨＬＴＣ＿ＳＶＣが半静的に設定（／シグナリング）された（周期的な）資源を介して行われる場合にも拡張適用され得る。

図１７は、本発明の実施例が具現される端末を示したブロック図である。

図１７を参照すると、端末１１００はプロセッサ１１１０、メモリ１１２０及びＲＦ部（ｒａｄｉｏｆｒｅｑｕｅｎｃｙｕｎｉｔ）１１３０を含む。

一実施例に係ると、プロセッサ１１１０は、本発明が説明する機能／動作／方法を実施することができる。例えば、プロセッサ１１１０は、相対的に短いレイテンシの要求事項を有するデータ通信のために設定された資源を決定し、及び前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行うように設定され得る。このとき、前記資源は、半静的に設定された資源であり得る。

ＲＦ部１１３０は、プロセッサ１１１０と連結され、無線信号を送信及び受信する。

プロセッサは、ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃｉｎｔｅｇｒａｔｅｄｃｉｒｃｕｉｔ）、他のチップセット、論理回路及び／又はデータ処理装置を含み得る。メモリは、ＲＯＭ（ｒｅａｄ−ｏｎｌｙｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ）、フラッシュメモリ、メモリカード、格納媒体及び／又は他の格納装置を含み得る。ＲＦ部は、無線信号を処理するためのベースバンド回路を含み得る。実施例がソフトウェアで具現されるとき、前述した技法は、前述した機能を行うモジュール（過程、機能など）で具現され得る。モジュールはメモリに格納され、プロセッサによって実行されることができる。メモリはプロセッサの内部又は外部にあり得、よく知られている多様な手段でプロセッサと連結され得る。

また、前記説明した用語に対する定義は、３ＧＰＰ、ＴＳ３６シリーズと、ＴＳ３８シリーズの標準スペックの用語に対する内容を参照及び含み得る。

Claims

無線通信システムにおける端末によって行われるデータ通信実行方法であって、
相対的に短いレイテンシの要求事項を有するデータ通信のために設定された資源を決定し、及び
前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行い、
前記資源は、半静的に設定された資源である、方法。
前記相対的に短いレイテンシの要求事項を有するデータ通信は、ＵＲＬＬＣ（ＵｌｔｒａＲｅｌｉａｂｌｅａｎｄＬｏｗＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ）であり、
前記相対的に短いレイテンシの要求事項を有するデータ通信よりも相対的に長いレイテンシの要求事項を有するデータ通信は、ＥＭＢＢ（ＥｎｈａｎｃｅｄＭｏｂｉｌｅＢｒｏａｄｂａｎｄ）である、請求項１に記載の方法。
前記資源は、第１タイプの資源又は第２タイプの資源のうちの一つの資源であり、
前記第１タイプの資源は、パンクチャリングが常に適用される資源であり、
前記第２タイプの資源は、前記相対的に短いレイテンシの要求事項を有するデータ通信が行われるか否かに応じて、パンクチャリングが適用される資源である、請求項１に記載の方法。
前記第２タイプの資源では、
前記相対的に短いレイテンシの要求事項を有するデータ通信が行われる場合、前記第２タイプの資源がパンクチャリングされ、及び
前記相対的に短いレイテンシの要求事項を有するデータ通信が行われない場合、前記第２タイプの資源がパンクチャリングされない、請求項３に記載の方法。
特定の区間の間にチャネルの状態が既に設定された閾値よりも良くない場合、
端末は、前記第１タイプの資源を用いて、前記相対的に短いレイテンシの要求事項を有するデータ通信を行う、請求項３に記載の方法。
特定の区間の間にチャネルの状態が既に設定された閾値よりも良い場合、端末は、前記第２タイプの資源を用いて、前記相対的に短いレイテンシの要求事項を有するデータ通信を行う、請求項３に記載の方法。
前記第１タイプの資源は、前記第２タイプの資源に比べて、相対的に小さいサイズを有する、請求項３に記載の方法。
前記第１タイプの資源は、前記第１タイプの資源に対する別途の基準信号（ｒｅｆｅｒｅｎｃｅｓｉｇｎａｌ；ＲＳ）を有する、請求項３に記載の方法。
前記端末は、ネットワークから前記資源の通信方向を指示する情報を受信する、請求項１に記載の方法。
前記端末は、ネットワークから前記資源が有効な時間区間を受信する、請求項１に記載の方法。
前記端末は、ネットワークに前記資源に関する補助情報を送信する、請求項１に記載の方法。
前記補助情報は、前記資源に対して前記端末がどのくらいの間前記相対的に短いレイテンシの要求事項を有するデータ通信を行うかを指示する情報を含む、請求項１１に記載の方法。
前記補助情報は、前記資源に対するパラメータが、前記相対的に短いレイテンシの要求事項を有するデータ通信に適合するか否かに関する情報を含む、請求項１１に記載の方法。
前記補助情報は、前記資源のリリース情報又は前記資源の変更要請情報の少なくとも一つ以上を含む、請求項１１に記載の方法。
端末は、
無線信号を送信及び受信するＲＦ（ＲａｄｉｏＦｒｅｑｕｅｎｃｙ）部、及び
前記ＲＦ部と結合して動作するプロセッサを含み、前記プロセッサは、
相対的に短いレイテンシの要求事項を有するデータ通信のために設定された資源を決定し、及び
前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行い、
前記資源は半静的に設定された資源である、端末。