(57)【特許請求の範囲】
【請求項１】
無線通信システムにおける端末（ＵＥ）により実行される方法であって、
第１データ通信のために半静的に設定された、第１タイプの資源及び第２タイプの資源を決定し、
前記第２タイプの資源の中にある第１資源をパンクチャリングし、及び、
前記第１データ通信が実行されることが要求される場合に、前記第１資源における前記第１データ通信を実行し、
前記第１データ通信が実行されない場合に、前記第２タイプの資源の中にある第２資源における第２データ通信を実行し、
前記第１データ通信は、前記第２データ通信より相対的に短いレイテンシの要求事項を有する、方法。
【請求項２】
前記相対的に短いレイテンシの要求事項を有する前記第１データ通信は、ＵＲＬＬＣ（Ｕｌｔｒａ  Ｒｅｌｉａｂｌｅ  ａｎｄ  Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）であり、
前記相対的に短いレイテンシの要求事項を有する前記第２データ通信よりも相対的に長いレイテンシの要求事項を有するデータ通信は、ＥＭＢＢ（Ｅｎｈａｎｃｅｄ  Ｍｏｂｉｌｅ  Ｂｒｏａｄｂａｎｄ）である、請求項１に記載の方法。
【請求項３】
前記第１タイプの資源は、パンクチャリングが常に適用される資源を備え、
前記第２タイプの資源は、前記相対的に短いレイテンシの要求事項を有するデータ通信が実行されるか否かに応じて、パンクチャリングが適用される資源を備える、請求項１に記載の方法。
【請求項４】
前記第１タイプの資源は、前記第２タイプの資源に比べて、相対的に小さいサイズを有する、請求項３に記載の方法。
【請求項５】
前記第１タイプの資源は、前記第１タイプの資源に対する別途の基準信号（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ；ＲＳ）を有する、請求項３に記載の方法。
【請求項６】
ネットワークから前記第１タイプの資源又は前記第２タイプの資源の通信方向を指示する情報を受信することを更に含んでなる、請求項１に記載の方法。
【請求項７】
ネットワークから前記第１タイプの資源又は前記第２タイプの資源が有効な時間区間を受信することを更に含んでなる、請求項１に記載の方法。
【請求項８】
ネットワークに前記第１タイプの資源又は前記第２タイプの資源に関する補助情報を送信することを更に含んでなる、請求項１に記載の方法。
【請求項９】
前記補助情報は、前記第１データ通信がどのくらいの期間実行されるかを指示する情報を含む、請求項８に記載の方法。
【請求項１０】
前記補助情報は、前記第１タイプの資源又は前記第２タイプの資源に対する少なくとも一つのパラメータが、前記相対的に短いレイテンシの要求事項を有するデータ通信に適合するか否かに関する情報を含む、請求項８に記載の方法。
【請求項１１】
前記補助情報は、前記第１タイプの資源又は前記第２タイプの資源のリリース情報、或は、前記第１タイプの資源又は前記第２タイプの資源の変更要請情報の少なくとも一つを含む、請求項８に記載の方法。
【請求項１２】
無線通信システムにおける端末（ＵＥ）であって、
前記端末（ＵＥ）は、
送信機受信機と、及び
前記送信機受信機と結合して動作するプロセッサと、を備えてなり、
前記プロセッサは、
第１データ通信のために半静的に設定された、第１タイプの資源及び第２タイプの資源を決定し、及び
前記第２タイプの資源の中にある第１資源をパンクチャリングし、及び、
前記第１データ通信が実行されることが要求される場合に、前記第１資源における前記第１データ通信を実行し、
前記第１データ通信が実行されない場合に、前記第２タイプの資源の中にある第２資源における第２データ通信を実行し、
前記第１データ通信は、前記第２データ通信より相対的に短いレイテンシの要求事項を有する、端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムに関し、より詳細には、無線通信システムにおける端末によって行われるデータ通信実行方法、並びにこれを用いる装置を提供する方法、及びこの方法を用いる装置に関する。
【背景技術】
【０００２】
ＩＴＵ−Ｒ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｏｎ  Ｒａｄｉｏ  ｃｏｍｍｕｎｉｃａｔｉｏｎ  ｓｅｃｔｏｒ）では、３世代以降の次世代移動通信システムであるＩＭＴ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ）−Ａｄｖａｎｃｅｄの標準化作業を進めている。ＩＭＴ−Ａｄｖａｎｃｅｄは、停止及び低速の移動状態で１Ｇｂｐｓ、高速の移動状態で１００Ｍｂｐｓのデータ転送レートでＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ベースのマルチメディアサービス支援を目標とする。
【０００３】
３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）は、ＩＭＴ−Ａｄｖａｎｃｅｄの要求事項を満たすシステム標準としてＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）／ＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ  Ｃａｒｒｉｅｒ−Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）転送方式ベースであるＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）を改善したＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）を準備している。ＬＴＥ−Ａは、ＩＭＴ−Ａｄｖａｎｃｅｄのための有力な候補のうちの一つである。
【０００４】
データ通信には、例えば、ＵＲＬＬＣ（Ｕｌｔｒａ−Ｒｅｌｉａｂｌｅ  ａｎｄ  Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）のような相対的に短いレイテンシ（ｌａｔｅｎｃｙ）の要求事項を有するデータ通信と、例えば、ｅＭＢＢ（ｅｎｈａｎｃｅｄ  Ｍｏｂｉｌｅ  Ｂｒｏａｄｂａｎｄ）のような（ＵＲＬＬＣに比べて）相対的に長いレイテンシの要求事項を有するデータ通信が存在し得る。
【０００５】
ここで、ｅＭＢＢの場合は、相対的に長いレイテンシの要求事項（及び／又は相対的に低い信頼性（ｒｅｌｉａｂｉｌｉｔｙ）の要求事項）を有するデータ通信に該当するので、ダイナミックＤＣＩ（ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｉｎｆｏｒｍａｔｉｏｎ）を介したグラントを用いて動的にデータ通信を行うとしても、（ＵＲＬＬＣに対して動的に通信を行う場合よりは）相対的に問題が生じる余地が低い。
【０００６】
しかし、相対的に短いレイテンシの要求事項（及び／又は相対的に高い信頼性の要求事項）を有するデータ通信に該当するＵＲＬＬＣの場合には、動的にデータ通信を行うために、ＵＬグラントを割り当て、アップリンクを試みるにはオーバーヘッドの問題及びタイムラインの問題が生じ得る。
【０００７】
これに伴って、本発明では、相対的に短いレイテンシの要求事項（及び／又は相対的に高い信頼性の要求事項）を有するデータ通信に対して半静的に設定された資源を介して通信を行う方法と、これを用いる端末に対する構成を提供しようとする。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明が解決しようとする技術的課題は、無線通信システムにおける端末によって行われるデータ通信実行方法、及びこれを用いる装置を提供することにある。
【課題を解決するための手段】
【０００９】
本発明の一実施例に係ると、無線通信システムにおける端末によって行われるデータ通信実行方法において、相対的に短いレイテンシの要求事項を有するデータ通信のために設定された資源を決定し、及び前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行い、前記資源は、半静的に設定された資源であることを特徴とする方法を提供する。
【００１０】
このとき、前記相対的に短いレイテンシの要求事項を有するデータ通信は、ＵＲＬＬＣ（Ｕｌｔｒａ  Ｒｅｌｉａｂｌｅ  ａｎｄ  Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）であり、前記相対的に短いレイテンシの要求事項を有するデータ通信よりも相対的に長いレイテンシの要求事項を有するデータ通信は、ＥＭＢＢ（Ｅｎｈａｎｃｅｄ  Ｍｏｂｉｌｅ  Ｂｒｏａｄｂａｎｄ）であり得る。
【００１１】
このとき、前記資源は、第１タイプの資源又は第２タイプの資源のうちの一つの資源であり、前記第１タイプの資源は、パンクチャリングが常に適用される資源であり、前記第２タイプの資源は、前記相対的に短いレイテンシの要求事項を有するデータ通信が行われるか否かに応じて、パンクチャリングが適用される資源であり得る。
【００１２】
このとき、前記第２タイプの資源では、前記相対的に短いレイテンシの要求事項を有するデータ通信が行われる場合、前記第２タイプの資源がパンクチャリングされ、及び前記相対的に短いレイテンシの要求事項を有するデータ通信が行われない場合、前記第２タイプの資源がパンクチャリングされないことがある。
【００１３】
このとき、特定の区間の間にチャネルの状態が既に設定された閾値よりも良くない場合、端末は、前記第１タイプの資源を用いて、前記相対的に短いレイテンシの要求事項を有するデータ通信を行い得る。
【００１４】
このとき、特定の区間の間にチャネルの状態が既に設定された閾値よりも良い場合、端末は、前記第２タイプの資源を用いて、前記相対的に短いレイテンシの要求事項を有するデータ通信を行い得る。
【００１５】
このとき、前記第１タイプの資源は、前記第２タイプの資源に比べて、相対的に小さいサイズを有し得る。
【００１６】
このとき、前記第１タイプの資源は、前記第１タイプの資源に対する別途の基準信号（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ；ＲＳ）を有し得る。
【００１７】
このとき、前記端末は、ネットワークから前記資源の通信方向を指示する情報を受信し得る。
【００１８】
このとき、前記端末は、ネットワークから前記資源が有効な時間区間を受信し得る。
【００１９】
このとき、前記端末は、ネットワークに前記資源に関する補助情報を送信し得る。
【００２０】
このとき、前記補助情報は、前記資源に対して前記端末がどのくらいの間前記相対的に短いレイテンシの要求事項を有するデータ通信を行うかを指示する情報を含み得る。
【００２１】
このとき、前記補助情報は、前記資源に対するパラメータが、前記相対的に短いレイテンシの要求事項を有するデータ通信に適合するか否かに関する情報を含み得る。
【００２２】
このとき、前記補助情報は、前記資源のリリース情報又は前記資源の変更要請情報の少なくとも一つ以上を含み得る。
【００２３】
本発明の他の実施例に係ると、端末は、無線信号を送信及び受信するＲＦ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）部、及び前記ＲＦ部と結合して動作するプロセッサを含み、前記プロセッサは、相対的に短いレイテンシの要求事項を有するデータ通信のために設定された資源を決定し、及び前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行い、前記資源は半静的に設定された資源であることを特徴とする端末を提供する。
【発明の効果】
【００２４】
本発明に係ると、半静的に設定される資源を用いて、相対的に短いレイテンシの要求事項（及び／又は相対的に高い信頼性の要求事項）を有するデータ通信を行うので、オーバーヘッドの問題及びタイムラインの問題が解決できる。
【図面の簡単な説明】
【００２５】
【図１】本発明が適用され得る無線通信システムを例示する。
【図２】ユーザープレーン（ｕｓｅｒ  ｐｌａｎｅ）に対する無線プロトコルの構造（ｒａｄｉｏ  ｐｒｏｔｏｃｏｌ  ａｒｃｈｉｔｅｃｔｕｒｅ）を示したブロック図である。
【図３】コントロールプレーン（ｃｏｎｔｒｏｌ  ｐｌａｎｅ）に対する無線プロトコルの構造を示したブロック図である。
【図４】プリエンプションベースのｅＭＢＢと、ＵＲＬＬＣ送信の多重化と、プリエンプション指示情報の一例を概略的に示したものである。
【図５】アップリンクの承認がないアップリンク送信繰り返しの一例を概略的に示したものである。
【図６】ＥＭＢＢ構造の一例を概略的に示したものである。
【図７】本発明の一実施例に係る、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法のフローチャートである。
【図８】提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の一例に対するフローチャートである。
【図９】ＥＭＢＢ領域にＲＧ＿ＴＹＰＥ＃Ａの資源とＲＧ＿ＴＹＰＥ＃Ｂの資源が位置する一例を概略的に示した例である。
【図１０】ＥＭＢＢ領域の外にＲＧ＿ＴＹＰＥ＃Ａの資源が位置する一例を概略的に示した例である。
【図１１】ＥＭＢＢに対する基準信号を、ＲＧ＿ＴＹＰＥ＃Ｂの資源が用いる一例を概略的に示した例である。
【図１２】提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の別の例に対するフローチャートである。
【図１３】提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法のまた別の例に対するフローチャートである。
【図１４】提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法のまた別の例に対するフローチャートである。
【図１５】提案方法＃２による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の一例に対するフローチャートである。
【図１６】提案方法＃４による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の一例に対するフローチャートである。
【図１７】本発明の実施例が具現される端末を示したブロック図である。
【発明を実施するための形態】
【００２６】
図１は、本発明が適用され得る無線通信システムを例示する。これは、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）、またはＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）／ＬＴＥ−Ａシステムと呼ばれることができる。
【００２７】
Ｅ−ＵＴＲＡＮは、端末１０（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ、ＵＥ）にコントロールプレーン（ｃｏｎｔｒｏｌ  ｐｌａｎｅ）とユーザープレーン（ｕｓｅｒ  ｐｌａｎｅ）を提供する基地局２０（Ｂａｓｅ  Ｓｔａｔｉｏｎ、ＢＳ）とを含む。端末１０は、固定されるか、または移動性を有することができ、ＭＳ（Ｍｏｂｉｌｅ  ｓｔａｔｉｏｎ）、ＵＴ（Ｕｓｅｒ  Ｔｅｒｍｉｎａｌ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅｒ  Ｓｔａｔｉｏｎ）、ＭＴ（ｍｏｂｉｌｅ  ｔｅｒｍｉｎａｌ）、無線機器（Ｗｉｒｅｌｅｓｓ  Ｄｅｖｉｃｅ）等、他の用語で呼ばれることができる。基地局２０は、端末１０と通信する固定された支点（ｆｉｘｅｄ  ｓｔａｔｉｏｎ）をいい、ｅＮＢ（ｅｖｏｌｖｅｄ-ＮｏｄｅＢ）、ＢＴＳ（Ｂａｓｅ  Ｔｒａｎｓｃｅｉｖｅｒ  Ｓｙｓｔｅｍ）、アクセスポイント（Ａｃｃｅｓｓ  Ｐｏｉｎｔ）等、他の用語で呼ばれることができる。
【００２８】
基地局２０は、Ｘ２インターフェースを介して互いに接続されることができる。基地局２０は、Ｓ１インターフェースを介してＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ  Ｃｏｒｅ）３０、さらに詳細には、Ｓ１-ＭＭＥを介してＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）とＳ１-Ｕを介してＳ−ＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）と接続される。
【００２９】
ＥＰＣ３０は、ＭＭＥ、Ｓ−ＧＷ及びＰ−ＧＷ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ−Ｇａｔｅｗａｙ）から構成される。ＭＭＥは、端末の接続情報または端末の能力に関する情報を有しており、このような情報は、端末の移動性管理に主に使用される。Ｓ−ＧＷは、Ｅ−ＵＴＲＡＮを終端点として有するゲートウェイであり、Ｐ−ＧＷは、ＰＤＮを終端点として有するゲートウェイである。
【００３０】
端末とネットワークとの間の無線インターフェースプロトコル（Ｒａｄｉｏ  Ｉｎｔｅｒｆａｃｅ  Ｐｒｏｔｏｃｏｌ）の層は、通信システムにおいて広く知られた開放型システム間相互接続（Ｏｐｅｎ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ；ＯＳＩ）基準モデルの下位３個層に基づいてＬ１（第１層）、Ｌ２（第２層）、Ｌ３（第３層）に区分されることができるが、この中で第１層に属する物理層は、物理チャネル（Ｐｈｙｓｉｃａｌ  Ｃｈａｎｎｅｌ）を利用した情報送信サービス（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｒａｎｓｆｅｒ  Ｓｅｒｖｉｃｅ）を提供し、第３層に位置するＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）層は、端末とネットワークとの間に無線資源を制御する役割を行う。このために、ＲＲＣ層は、端末と基地局との間のＲＲＣメッセージを交換する。
【００３１】
図２は、ユーザープレーン（ｕｓｅｒ  ｐｌａｎｅ）に対する無線プロトコル構造（ｒａｄｉｏ  ｐｒｏｔｏｃｏｌ  ａｒｃｈｉｔｅｃｔｕｒｅ）を示したブロック図である。図３は、コントロールプレーン（ｃｏｎｔｒｏｌ  ｐｌａｎｅ）に対する無線プロトコル構造を示したブロック図である。ユーザープレーンは、ユーザーデータ送信のためのプロトコルスタック（ｐｒｏｔｏｃｏｌ  ｓｔａｃｋ）で、コントロールプレーンは、制御信号送信のためのプロトコルスタックである。
【００３２】
図２及び３を参照すると、物理層（ＰＨＹ（ｐｈｙｓｉｃａｌ）ｌａｙｅｒ）は、物理チャネル（ｐｈｙｓｉｃａｌ  Ｃｈａｎｎｅｌ）を利用して上位層に情報送信サービス（ｉｎｆｏｒｍａｔｉｏｎ  tｒａｎｓｆｅｒ  sｅｒｖｉｃｅ）を提供する。物理層は、上位層であるＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）層とは送信チャネル（ｔｒａｎｓｐｏｒｔ  ｃｈａｎｎｅｌ）を介して接続されている。送信チャネルを介してＭＡＣ層と物理層との間にデータが移動する。送信チャネルは、無線インターフェースを介してデータがどのようにどんな特徴で送信されるかによって分類される。
【００３３】
互いに異なる物理層の間、すなわち送信機と受信機の物理層の間は、物理チャネルを介してデータが移動する。前記物理チャネルは、ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）方式で変調されることができ、時間と周波数を無線資源として活用する。
【００３４】
ＭＡＣ層の機能は、論理チャネルと送信チャネルとの間のマッピング及び論理チャネルに属するＭＡＣ  ＳＤＵ（ｓｅｒｖｉｃｅ  ｄａｔａ  ｕｎｉｔ）の送信チャネル上へ物理チャネルに提供される送信ブロック（ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ）への多重化／逆多重化を含む。ＭＡＣ層は、論理チャネルを介してＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）層にサービスを提供する。
【００３５】
ＲＬＣ層の機能は、ＲＬＣ  ＳＤＵの接続（ｃｏｎｃａｔｅｎａｔｉｏｎ）、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）及び再結合（ｒｅａｓｓｅｍｂｌｙ）を含む。無線ベアラー（Ｒａｄｉｏ  Ｂｅａｒｅｒ；ＲＢ）が要求する多様なＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）を保障するために、ＲＬＣ層は、透明モード（Ｔｒａｎｓｐａｒｅｎｔ  Ｍｏｄｅ、ＴＭ）、非確認モード（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ、ＵＭ）及び確認モード（Ａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ、ＡＭ）の３通りの動作モードを提供する。ＡＭ  ＲＬＣは、ＡＲＱ（ａｕｔｏｍａｔｉｃ  ｒｅｐｅａｔ  ｒｅｑｕｅｓｔ）を介してエラー訂正を提供する。
【００３６】
ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）層は、コントロールプレーンにおいてのみ定義される。ＲＲＣ層は、無線ベアラーの設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）、再設定（ｒｅ−ｃｏｎｆｉｇｕｒａｔｉｏｎ）及び解除（ｒｅｌｅａｓｅ）と関連して、論理チャネル、送信チャネル及び物理チャネルの制御を担当する。ＲＢは、端末とネットワークとの間のデータ伝達のために、第１層（ＰＨＹ層）及び第２層（ＭＡＣ層、ＲＬＣ層、ＰＤＣＰ層）により提供される論理的経路を意味する。
【００３７】
ユーザープレーンでのＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）層の機能は、ユーザーデータの伝達、ヘッダ圧縮（ｈｅａｄｅｒ  ｃｏｍｐｒｅｓｓｉｏｎ）及び暗号化（ｃｉｐｈｅｒｉｎｇ）を含む。コントロールプレーンでのＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）層の機能は、コントロールプレーンデータの伝達及び暗号化／整合性保護（ｉｎｔｅｇｒｉｔｙ  ｐｒｏｔｅｃｔｉｏｎ）を含む。
【００３８】
ＲＢが設定されるということは、特定サービスを提供するために無線プロトコル層及びチャネルの特性を規定し、各々の具体的なパラメータ及び動作方法を設定する過程を意味する。ＲＢは、またＳＲＢ（Ｓｉｇｎａｌｉｎｇ  ＲＢ）とＤＲＢ（Ｄａｔａ  ＲＢ）の２通りに分けられることができる。ＳＲＢは、コントロールプレーンにおいてＲＲＣメッセージを送信する通路として使用され、ＤＲＢは、ユーザープレーンにおいてユーザデータを送信する通路として使用される。
【００３９】
端末のＲＲＣ層とＥ-ＵＴＲＡＮのＲＲＣ層との間にＲＲＣ接続（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ）が確立されると、端末は、ＲＲＣ接続（ＲＲＣ  ｃｏｎｎｅｃｔｅｄ）状態にあるようになり、そうでない場合、ＲＲＣアイドル（ＲＲＣ  ｉｄｌｅ）状態にあるようになる。
【００４０】
ネットワークにおいて端末にデータを送信するダウンリンク送信チャネルには、システム情報を送信するＢＣＨ（Ｂｒｏａｄｃａｓｔ  Ｃｈａｎｎｅｌ）とその以外にユーザートラフィックまたは制御メッセージを送信するダウンリンクＳＣＨ（Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）がある。ダウンリンクマルチキャストまたはブロードキャストサービスのトラフィックまたは制御メッセージの場合、ダウンリンクＳＣＨを介して送信されることもでき、または別のダウンリンクＭＣＨ（Ｍｕｌｔｉｃａｓｔ  Ｃｈａｎｎｅｌ）を介して送信されることもできる。一方、端末においてネットワークにデータを送信するアップリンク送信チャネルには、初期制御メッセージを送信するＲＡＣＨ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ）とそれ以外にユーザトラフィックまたは制御メッセージを送信するアップリンクＳＣＨ（Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）がある。
【００４１】
送信チャネル上位にあり、送信チャネルにマッピングされる論理チャネル（Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ）には、ＢＣＣＨ（Ｂｒｏａｄｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）、ＰＣＣＨ（Ｐａｇｉｎｇ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）、ＣＣＣＨ（Ｃｏｍｍｏｎ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）、ＭＣＣＨ（Ｍｕｌｔｉｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）、ＭＴＣＨ（Ｍｕｌｔｉｃａｓｔ  Ｔｒａｆｆｉｃ  Ｃｈａｎｎｅｌ）などがある。
【００４２】
物理チャネル（Ｐｈｙｓｉｃａｌ  Ｃｈａｎｎｅｌ）は、時間領域で複数のＯＦＤＭシンボルと周波数領域で複数の副搬送波（Ｓｕｂ-ｃａｒｒｉｅｒ）とから構成される。一つのサブフレーム（Ｓｕｂ-ｆｒａｍｅ）は、時間領域で複数のＯＦＤＭシンボル（Ｓｙｍｂｏｌ）から構成される。資源ブロックは、資源割り当て単位であって、複数のＯＦＤＭシンボルと複数の副搬送波（ｓｕｂ-ｃａｒｒｉｅｒ）から構成される。また、各サブフレームは、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）すなわち、Ｌ１／Ｌ２制御チャネルのために該当サブフレームの特定ＯＦＤＭシンボル（例、第１番目のＯＦＤＭシンボル）の特定副搬送波を利用できる。ＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｔｉｍｅ  Ｉｎｔｅｒｖａｌ）は、サブフレーム送信の単位時間である。
【００４３】
＜Ｖ２Ｘ（ＶＥＨＩＣＬＥ−ＴＯ−Ｘ）通信＞
【００４４】
前述したように、一般にＤ２Ｄ動作は、近接した機器間の信号の送受信という点で多様な長所を有し得る。例えば、Ｄ２Ｄ端末は、高い転送レート及び低い遅延を有し、データ通信を行うことができる。また、Ｄ２Ｄ動作は、基地局に集中するトラフィックを分散させることができ、Ｄ２Ｄ動作を行う端末が中継器の役割をすれば、基地局のカバレッジを拡張させる役割もすることができる。前述したＤ２Ｄ通信の拡張で車両間の信号の送受信を含み、車両（ＶＥＨＩＣＬＥ）と関連した通信を特別にＶ２Ｘ（ＶＥＨＩＣＬＥ−ＴＯ−Ｘ）通信と呼ぶ。
【００４５】
ここで、一例として、Ｖ２Ｘ（ＶＥＨＩＣＬＥ−ＴＯ−Ｘ）における‘Ｘ’の用語は、ＰＥＤＥＳＴＲＩＡＮ（ＣＯＭＭＵＮＩＣＡＴＩＯＮ  ＢＥＴＷＥＥＮ  Ａ  ＶＥＨＩＣＬＥ  ＡＮＤ  Ａ  ＤＥＶＩＣＥ  ＣＡＲＲＩＥＤ  ＢＹ  ＡＮ  ＩＮＤＩＶＩＤＵＡＬ（例）ＨＡＮＤＨＥＬＤ  ＴＥＲＭＩＮＡＬ  ＣＡＲＲＩＥＤ  ＢＹ  Ａ  ＰＥＤＥＳＴＲＩＡＮ、ＣＹＣＬＩＳＴ、ＤＲＩＶＥＲ  ＯＲ  ＰＡＳＳＥＮＧＥＲ）（Ｖ２Ｐ）、ＶＥＨＩＣＬＥ（ＣＯＭＭＵＮＩＣＡＴＩＯＮ  ＢＥＴＷＥＥＮ  ＶＥＨＩＣＬＥＳ）（Ｖ２Ｖ）、ＩＮＦＲＡＳＴＲＵＣＴＵＲＥ／ＮＥＴＷＯＲＫ（ＣＯＭＭＵＮＩＣＡＴＩＯＮ  ＢＥＴＷＥＥＮ  Ａ  ＶＥＨＩＣＬＥ  ＡＮＤ  Ａ  ＲＯＡＤＳＩＤＥ  ＵＮＩＴ  （ＲＳＵ）／ＮＥＴＷＯＲＫ（例）ＲＳＵ  ＩＳ  Ａ  ＴＲＡＮＳＰＯＲＴＡＴＩＯＮ  ＩＮＦＲＡＳＴＲＵＣＴＵＲＥ  ＥＮＴＩＴＹ（例）ＡＮ  ＥＮＴＩＴＹ  ＴＲＡＮＳＭＩＴＴＩＮＧ  ＳＰＥＥＤ  ＮＯＴＩＦＩＣＡＴＩＯＮＳ）ＩＭＰＬＥＭＥＮＴＥＤ  ＩＮ  ＡＮ  ｅＮＢ  ＯＲ  Ａ  ＳＴＡＴＩＯＮＡＲＹ  ＵＥ）（Ｖ２Ｉ／Ｎ）等を意味する。また、一例として、提案方式に関する説明の便宜のために、歩行者（或いは人間）が所持した（Ｖ２Ｐ通信関連）デバイスを“Ｐ−ＵＥ”と名付け、ＶＥＨＩＣＬＥに設置された（Ｖ２Ｘ通信関連）デバイスを“Ｖ−ＵＥ”と名付ける。さらに、一例として、本発明で‘エンティティ（ＥＮＴＩＴＹ）’の用語はＰ−ＵＥ及び／又はＶ−ＵＥ及び／又はＲＳＵ（／ＮＥＴＷＯＲＫ／ＩＮＦＲＡＳＴＲＵＣＴＵＲＥ）と解釈され得る。
【００４６】
Ｖ２Ｘ端末は、事前に定義された（或いはシグナリングされた）リソースプール（ＲＥＳＯＵＲＣＥ  ＰＯＯＬ）上で、メッセージ（或いはチャネル）送信を行うことができる。ここで、リソースプールは、端末がＶ２Ｘ動作を行うように（或いはＶ２Ｘ動作を行うことができる）事前に定義された資源を意味し得る。このとき、リソースプールは、例えば、時間−周波数の側面で定義され得る。
【００４７】
一方、Ｖ２Ｘにおいて、モード３は、基地局によるスケジューリングモードに該当し、モード４は、端末の自律スケジューリングモードに該当し得る。ここで、モード４による端末は、センシング（ＳＥＮＳＩＮＧ）に基づいて送信資源を決定した後、決定された前記送信資源を介してＶ２Ｘ通信を行うことを意味し得る。
【００４８】
＜５Ｇ（５th  ｇｅｎｅｒａｔｉｏｎ）＞
【００４９】
４Ｇ（４thｇｅｎｅｒａｔｉｏｎ）通信システムの商用化以降、増加傾向にある無線データのトラフィック需要を満たすために、改善した５Ｇ（５thｇｅｎｅｒａｔｉｏｎ）通信システム又はｐｒｅ−５Ｇ通信システムを開発するための努力が行われている。このような理由で、５Ｇ通信システム又はｐｒｅ−５Ｇ通信システムは、４Ｇネットワーク以降（Ｂｅｙｏｎｄ  ４Ｇ  Ｎｅｔｗｏｒｋ）の通信システム又はＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システム以降（Ｐｏｓｔ  ＬＴＥ）のシステムと呼ばれている。高いデータ転送レートを達成するために、５Ｇ通信システムは超高周波（ｍｍＷａｖｅ）帯域（例えば、６０ギガ（６０ＧＨｚ）帯域のような）での具現が考慮されている。超高周波帯域での電波の経路損失の緩和及び電波の伝達距離を増加させるために、５Ｇ通信システムではビームフォーミング（ｂｅａｍｆｏｒｍｉｎｇ）、大規模配列多重入出力（ｍａｓｓｉｖｅ  ＭＩＭＯ）、全次元多重入出力（Ｆｕｌｌ  Ｄｉｍｅｎｓｉｏｎａｌ  ＭＩＭＯ、ＦＤ−ＭＩＭＯ）、アレイアンテナ（ａｒｒａｙ  ａｎｔｅｎｎａ）、アナログビーム形成（ａｎａｌｏｇ  ｂｅａｍ−ｆｏｒｍｉｎｇ）、及び大規模アンテナ（ｌａｒｇｅ  ｓｃａｌｅ  ａｎｔｅｎｎａ）技術が論議されている。また、システムのネットワーク改善のために、５Ｇ通信システムでは進化した小型セル、改善した小型セル（ａｄｖａｎｃｅｄ  ｓｍａｌｌ  ｃｅｌｌ）、クラウド無線アクセスネットワーク（ｃｌｏｕｄ  ｒａｄｉｏ  ａｃｃｅｓｓ  ｎｅｔｗｏｒｋ、ｃｌｏｕｄ  ＲＡＮ）、超高密度ネットワーク（ｕｌｔｒａ−ｄｅｎｓｅ  ｎｅｔｗｏｒｋ）、機器間通信（Ｄｅｖｉｃｅ  ｔｏ  Ｄｅｖｉｃｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎ、Ｄ２Ｄ）、無線バックホール（ｗｉｒｅｌｅｓｓ  ｂａｃｋｈａｕｌ）、移動ネットワーク（ｍｏｖｉｎｇ  ｎｅｔｗｏｒｋ）、協力通信（ｃｏｏｐｅｒａｔｉｖｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＣｏＭＰ（Ｃｏｏｒｄｉｎａｔｅｄ  Ｍｕｌｔｉ−Ｐｏｉｎｔｓ）、及び受信干渉除去（ｉｎｔｅｒｆｅｒｅｎｃｅ  ｃａｎｃｅｌｌａｔｉｏｎ）等の技術開発が行われている。その他にも、５Ｇシステムでは、進歩したコーディング変調（Ａｄｖａｎｃｅｄ  Ｃｏｄｉｎｇ  Ｍｏｄｕｌａｔｉｏｎ、ＡＣＭ）方式であるＦＱＡＭ（Ｈｙｂｒｉｄ  Ｆｒｅｑｕｅｎｃｙ  Ｓｈｉｆｔ  Ｋｅｙｉｎｇ  ａｎｄ  Ｑｕａｄｒａｔｕｒｅ  Ａｍｐｌｉｔｕｄｅ  Ｍｏｄｕｌａｔｉｏｎ）及びＳＷＳＣ（Ｓｌｉｄｉｎｇ  Ｗｉｎｄｏｗ  Ｓｕｐｅｒｐｏｓｉｔｉｏｎ  Ｃｏｄｉｎｇ）と、進歩した接続技術であるＦＢＭＣ（Ｆｉｌｔｅｒ  Ｂａｎｋ  Ｍｕｌｔｉ  Ｃａｒｒｉｅｒ）、ＮＯＭＡ（Ｎｏｎ  Ｏｒｔｈｏｇｏｎａｌ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）、及びＳＣＭＡ（Ｓｐａｒｓｅ  Ｃｏｄｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）等が開発されている。
【００５０】
一方、インターネットは、人間が情報を生成し消費する人間中心の連結網から、物など分散した構成要素の間に情報を取り交わして処理するＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ、モノのインターネット）網に進化している。クラウドサーバーなどとの接続を介したビッグデータ（Ｂｉｇ  ｄａｔａ）処理技術などがＩｏＴ技術に結合されたＩｏＥ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｅｖｅｒｙｔｈｉｎｇ）技術も台頭している。ＩｏＴを具現するために、センシング技術、有無線通信及びネットワークインフラ、サービスインターフェース技術、及び保安技術のような技術要素が求められ、最近では、物の間の連結のためのセンサネットワーク（ｓｅｎｓｏｒ  ｎｅｔｗｏｒｋ）、物の通信（Ｍａｃｈｉｎｅ  ｔｏ  Ｍａｃｈｉｎｅ、Ｍ２Ｍ）、ＭＴＣ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などの技術が研究されている。ＩｏＴ環境では、接続された物で生成されたデータを収集、分析し、人間の生に新しい価値を創出する知能型ＩＴ（Ｉｎｔｅｒｎｅｔ  Ｔｅｃｈｎｏｌｏｇｙ）サービスが提供されることができる。ＩｏＴは、既存のＩＴ（ｉｎｆｏｒｍａｔｉｏｎ  ｔｅｃｈｎｏｌｏｇｙ）技術と多様な産業間の融合及び複合を通じて、スマートホーム、スマートビルディング、スマートシティ、スマートカーあるいはコネックティドカー、スマートグリッド、ヘルスケア、スマート家電、先端医療サービスなどの分野に応用されることができる。
【００５１】
これによって、５Ｇ通信システムをＩｏＴ網に適用するための多様な試みが行われている。例えば、センサーネットワーク、物の通信、ＭＴＣなどの技術が５Ｇ通信技術がビームフォーミング、ＭＩＭＯ、及びアレイアンテナなどの技法によって具現されているものである。前記で説明したビッグデータ処理技術としてクラウド無線アクセスネットワークが適用されることも、５Ｇ技術とＩｏＴ技術の融合の一例であると言える。
【００５２】
２０２０年頃に初期の商業化が予想される５世代（５Ｇ）移動通信は、産業及び学界の多様な候補技術に対する全世界の技術活動で、最近ではモメンタムが増加している。５Ｇ移動通信の候補要素は、ビームフォーミング利得を提供し、増加した容量を支援するための、レガシーセルラ周波数帯域から高周波数までの大規模アンテナ技術、多様な要求事項を有する各種サービス／アプリケーションを柔軟に収容するための新たな波形（例えば、新たな無線アクセス技術（ｒａｄｉｏ  ａｃｃｅｓｓ  ｔｅｃｈｎｏｌｏｇｙ；ＲＡＴ））、大規模接続を支援するための新たな多重アクセス方式等を含む。ＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｏｎ）は、２０２０年以降、ＩＭＴ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ）の使用シナリオを、ｅＭＢＢ（ｅｎｈａｎｃｅｄ  ｍｏｂｉｌｅ  ｂｒｏａｄｂａｎｄ）、大規模ＭＴＣ（ｍａｃｈｉｎｅ  ｔｙｐｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＵＲＬＬ（ｕｌｔｒａ  ｒｅｌｉａｂｌｅ  ａｎｄ  ｌｏｗ  ｌａｔｅｎｃｙ）通信のような３つの主要グループに分類した。また、ＩＴＣは、秒当たり２０ギガバイト（Ｇｂ／ｓ）の最大のデータ速度、秒当たり１００メガバイト（Ｍｂ／ｓ）のユーザー経験のデータ速度、３倍のスペクトル効率の改善、時間当たり最大５００キロメートル（ｋｍ／ｈ）の移動性支援、１ミリ秒（ｍｓ）のレイテンシ、１０６個の装置／ｋｍ2の連結密度、１００倍のネットワークエネルギー効率の向上、及び１０Ｍｂ／ｓ／ｍ2の面積のトラフィック容量のような目標の要求事項を明示した。全ての要求事項を同時に満たす必要はないが、５Ｇネットワークの設計は、前記要求事項のうち一部を満たす多様なアプリケーションを使用ケース別に支援することができる柔軟性を提供するための案（ｓｏｌｕｔｉｏｎ）が要求される。
【００５３】
＜ＵＲＬＬＣ（Ｕｌｔｒａ−ｒｅｌｉａｂｉｌｉｔｙ  ｌｏｗ−ｌａｔｅｎｃｙ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）及びｅＭＢＢ（ｅｎｈａｎｃｅｄ  Ｍｏｂｉｌｅ  ＢｒｏｄＢａｎｄ）＞
【００５４】
ＵＲＬＬＣとは、高信頼低遅延通信（Ｕｌｔｒａ−ｒｅｌｉａｂｉｌｉｔｙ  ｌｏｗ−ｌａｔｅｎｃｙ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）の略字であって、ｅＭＢＢ（ｅｎｈａｎｃｅｄ  Ｍｏｂｉｌｅ  ＢｒｏｄＢａｎｄ）通信に比べて、より低いブロックエラー率と、より短い送信単位及びダウンリンクに対するより速いアップリンクのフィードバックを指向している。さらに、ＵＲＬＬＣとｅＭＢＢ通信に関する送信特徴は下記の通りである。
【００５５】
ｅＭＢＢ送信（ｅＭＢＢ  ｔｒａｎｓｍｉｓｓｉｏｎ）
【００５６】
−  相対的に中間乃至高いトラフィックサイズ（Ｒｅｌａｔｉｖｅｌｙ  ｍｅｄｉｕｍ  ｔｏ  ｈｉｇｈ  ｔｒａｆｆｉｃ  ｓｉｚｅ）
【００５７】
−  到着率の多様な範囲（Ｖａｒｉｏｕｓ  ｒａｎｇｅ  ｏｆ  ａｒｒｉｖａｌ  ｒａｔｅ）
【００５８】
−  相対的に長い送信区間、例えば、１ｍｓ（Ｒｅｌａｔｉｖｅｌｙ  ｌｏｎｇ  ｔｒａｎｓｍｉｓｓｉｏｎ  ｄｕｒａｔｉｏｎ  （ｅ．ｇ．１ｍｓ））
【００５９】
ＵＲＬＬＣ送信（ＵＲＬＬＣ  ｔｒａｎｓｍｉｓｓｉｏｎ）
【００６０】
−  相対的に低いトラフィックサイズ（Ｒｅｌａｔｉｖｅｌｙ  ｌｏｗ  ｔｒａｆｆｉｃ  ｓｉｚｅ）
【００６１】
−  相対的に低い到着率（Ｒｅｌａｔｉｖｅｌｙ  ｌｏｗ  ａｒｒｉｖａｌ  ｒａｔｅ）
【００６２】
−  極低レイテンシの要求、例えば、０．５、１ｍｓ（Ｅｘｔｒｅｍｅｌｙ  ｌｏｗ  ｌａｔｅｎｃｙ  ｒｅｑｕｉｒｅｍｅｎｔｓ（ｅ．ｇ．０．５、１  ｍｓ））
【００６３】
−  相対的に短い送信区間、例えば、２ＯＦＤＭシンボル（Ｒｅｌａｔｉｖｅｌｙ  ｓｈｏｒｔ  ｔｒａｎｓｍｉｓｓｉｏｎ  ｄｕｒａｔｉｏｎ（ｅ．ｇ．２ＯＦＤＭ  ｓｙｍｂｏｌｓ））
【００６４】
−  緊急なサービス／メッセージ（Ｕｒｇｅｎｔ  ｓｅｒｖｉｃｅ／ｍｅｓｓａｇｅ）
【００６５】
図４は、プリエンプションベースのｅＭＢＢと、ＵＲＬＬＣ送信の多重化と、プリエンプション指示情報の一例を概略的に示したものである。
【００６６】
Ｒｅｌ−１５  ＮＲにおいて、ＵＲＬＬＣは、ダウンリンクではｅＭＢＢとＵＲＬＬＣ間の効率的な多重化（ｍｕｌｔｉｐｌｅｘｉｎｇ）を支援するための一環として、プリエンプション（ｐｒｅ−ｅｍｐｔｉｏｎ）手続とプリエンプション指示に対する構成及び送信方法を支援する。
【００６７】
より具体的に、Ｒｅｌ−１５  ＮＲにおいて、ＵＲＬＬＣに対するトラフィックは間欠的に発生することを仮定し、前記の場合、ＵＲＬＬＣ送信は、ｅＭＢＢに対する送信途中に発生し得る。
【００６８】
既に送信中である、或いはスケジューリングが完了した他の信号の一部資源を取って他の信号の送信に使用する動作をプリエンプション手続で説明されることができ、これは、間欠的に発生するＵＲＬＬＣ送信をｅＭＢＢ送信リソースの一部を介して、遅延することなく行うことを許容する。
【００６９】
他の信号によって一部情報が損失変更された信号の検出及び複号性能を改善するためには、該当損失及び変更された部分を再度端末に指示し、該当部分を複号時に除外させる必要がある。
【００７０】
Ｒｅｌ−１５  ＮＲにおいては、プリエンプション指示を複数の端末が受信することができるダウンリンク制御情報を介して送信することを支援する。プリエンプション指示の単位は、損失／変更された領域を含むコードブロックグループ、或いはシンボルグループ、或いはリソースブロックとシンボルとの組み合わせグループであり得る。
【００７１】
図５は、アップリンクの承認がないアップリンク送信の繰り返しの一例を概略的に示したものである。
【００７２】
Ｒｅｌ−１５  ＮＲ（Ｎｅｗ  Ｒａｄｉｏ  ａｃｃｅｓｓ  ｔｅｃｈｎｏｌｏｇｙ）において、ＵＲＬＬＣは、アップリンクでは基地局の指示なしで端末がアップリンク送信する動作を支援する。上位層の設定で動作するモードと、上位層で一部情報の設定後にダウンリンク制御情報にアップリンクの承認がないアップリンク送信の活性化を指示するモードがある。
【００７３】
複数の端末は同一のリソースを共有し、互いのアップリンク送信は互いに衝突し得る。従って、Ｒｅｌ−１５  ＮＲにおいては、前記衝突の状況でもアップリンク送信の端末を区分するために、独立した基準信号情報／時間−周波数資源リソースを設定する。
【００７４】
前記衝突時、再送信による遅延を防止するための目的で繰り返し送信を支援する。基地局が一部の繰り返し送信だけで複号を行えるように、繰り返しリソース間の複号に必要な情報を送信周期と送信周期内の繰り返し送信の順で固定／設定する。
【００７５】
一部の実施例において、“サブフレーム”及び“時間スロット”は、相互交換的に使用されることができる。本発明の一部実施例において、“サブフレーム”は送信時間間隔（ＴＴＩ）を指称し、これは、端末のデータの送／受信のための“時間スロット”のアグリゲイション （ａｇｇｒｅｇａｔｉｏｎ）を含み得る。
【００７６】
以下、本発明について説明する。
【００７７】
前述した通り、データ通信には、例えば、ＵＲＬＬＣ（Ｕｌｔｒａ−Ｒｅｌｉａｂｌｅ  ａｎｄ  Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）のような相対的に短いレイテンシ（ｌａｔｅｎｃｙ）の要求事項を有するデータ通信と、例えば、ｅＭＢＢ（ｅｎｈａｎｃｅｄ  Ｍｏｂｉｌｅ  Ｂｒｏａｄｂａｎｄ）のような（ＵＲＬＬＣに比べて）相対的に長いレイテンシの要求事項を有するデータ通信とが存在し得る。
【００７８】
ここで、ｅＭＢＢの場合は、相対的に長いレイテンシの要求事項（及び／又は相対的に低い信頼性（ｒｅｌｉａｂｉｌｉｔｙ）の要求事項）を有するデータ通信に該当するので、ダイナミックＤＣＩ（ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｉｎｆｏｒｍａｔｉｏｎ）を介したグラントを用いて、動的にデータ通信を行うとしても（ＵＲＬＬＣに対して動的に通信を行う場合よりは）相対的に問題が生じる余地が低い。
【００７９】
しかし、相対的に短いレイテンシの要求事項（及び／又は相対的に高い信頼性の要求事項）を有するデータ通信に該当するＵＲＬＬＣの場合には、動的にデータ通信を行うために、ＵＬグラントを割り当て、アップリンクを試みるにはオーバーヘッドの問題及びタイムラインの問題が生じ得る。
【００８０】
これによって、本発明では、相対的に短いレイテンシの要求事項（及び／又は相対的に高い信頼性の要求事項）を有するデータ通信に対して、半静的に設定された資源を介して通信を行う方法と、これを用いる端末に対する構成を提供しようとする。
【００８１】
一例として、下記の提案方式は、（事前に）半静的に設定（／シグナリング）された（周期的な）資源を介して、相対的に短い“ＬＡＴＥＮＣＹ”（及び／又は高い“ＲＥＬＩＡＢＩＬＩＴＹ”の要求事項）を有するデータ（／サービス）通信（例えば、ＵＲＬＬＣ、Ｖ２Ｘ）（ＬＬＴＣ＿ＳＶＣ）を効率的に支援する方法を提案する。
【００８２】
ここで、一例として、以下では説明の便宜のために、（ＬＬＴＣ＿ＳＶＣのために）半静的に設定（／シグナリング）された（周期的な）資源を“ＵＲ＿ＳＰＳＲＳＣ”と名付ける。
【００８３】
ここで、一例として、（以下では説明の便宜のために）（ＬＬＴＣ＿ＳＶＣに比べて）相対的に長い“ＬＡＴＥＮＣＹ”の要求事項（及び／又は低い“ＲＥＬＩＡＢＩＬＩＴＹ”の要求事項）を有するデータ（／サービス）通信（例えば、ＥＭＢＢ）を“ＨＬＴＣ＿ＳＶＣ”と名付ける。
【００８４】
ここで、一例として、（以下では説明の便宜のために）ＨＬＴＣ＿ＳＶＣのために（動的に）設定（／シグナリング）された資源を“ＥＭ＿ＤＹＮＲＳＣ”と名付ける。
【００８５】
ここで、一例として、（本発明で）“重なり（ＯＶＥＲＬＡＰ）”のワーディングは、（Ａ）実際に“（周波数）資源”が（全部又は一部）重なる場合、及び／又は（Ｂ）“（周波数）資源”は重ならないが、同じシンボル（或いはＳＬＯＴ）上に二つのチャネル（／信号）の送信が設定された場合等と解釈され得る。
【００８６】
本発明に対する具体的な実施例を説明するに先だって、説明の便宜のために、相対的に長い“ＬＡＴＥＮＣＹ”の要求事項を有するデータ（／サービス）通信のうちの一つであるＥＭＢＢに対する構造を図を通じて概略的に説明する。
【００８７】
図６は、ＥＭＢＢ構造の一例を概略的に示したものである。
【００８８】
図６によると、ＥＭＢＢ６２０は、時間側でスロット単位で定義されることができる。このとき、ＥＭＢＢ６２０の前段にはＲＳ（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ）６１０が位置し得る。本図では説明の便宜上、ＥＭＢＢの前段にＲＳが位置することを示しているが、本発明におけるＥＭＢＢ構造で、ＲＳが必ずしもＥＭＢＢの前段に位置しなければならないわけではない。また、本発明におけるＥＭＢＢ構造では、必要の際にＲＳがＥＭＢＢの中段、又は後段などに（前段に位置するＲＳとは別に）さらに位置することもある。
【００８９】
図６で説明したＥＭＢＢサービスのための構造は様々なＥＭＢＢ構造のうち一つの例示を説明したものに過ぎず、代表的なチャネル構造に該当しない。即ち、ＥＭＢＢ構造が図６で説明した内容に限定されるわけではない。
【００９０】
ＵＲＬＬＣのチャネル構造については別に示してはいないが、ＵＲＬＬＣのチャネル構造は、ＥＭＢＢチャネル構造の場合に比べて、スロット（ＳＬＯＴ）を構成するシンボルの数が相対的に小さいことがあり、これは、相対的に短いレイテンシ（ＬＡＴＥＣＹ）を支援するためであり得る。
【００９１】
以下、（事前に）半静的に設定（／シグナリング）された（周期的な）資源を介して、相対的に短い“ＬＡＴＥＮＣＹ”（及び／又は高い“ＲＥＬＩＡＢＩＬＩＴＹ”の要求事項）を有するデータ（／サービス）通信（例えば、ＵＲＬＬＣ、Ｖ２Ｘ）（ＬＬＴＣ＿ＳＶＣ）を効率的に支援する方法の実施例を図を通じて説明する。
【００９２】
図７は、本発明の一実施例に係る、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法のフローチャートである。
【００９３】
図７によると、基地局は相対的に短いレイテンシの要求事項を有するデータ通信のために、半静的に設定された資源（例えば、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ）を設定（／シグナリング）することができる（Ｓ７１０）。
【００９４】
ここで、相対的に短いレイテンシ（ＬＡＴＥＮＣＹ）の要求事項を有するデータ通信のために、半静的に設定された資源が用いられる場合、端末が（基地局から受信された）データ（ＤＡＴＡ）送／受信のスケジューリング関連のＤＣＩをデコーディングするのに要求される（プロセシング）時間を減らすことによって、該当通信を効率的に支援することができる。
【００９５】
以降、端末は、前記資源上で相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ７２０）。
【００９６】
例えば、前記相対的に短いレイテンシの要求事項を有するデータ通信は、ＵＲＬＬＣ（Ｕｌｔｒａ  Ｒｅｌｉａｂｌｅ  ａｎｄ  Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）であり、これよりも相対的に長いレイテンシの要求事項を有するデータ通信は、ＥＭＢＢ（Ｅｎｈａｎｃｅｄ  Ｍｏｂｉｌｅ  Ｂｒｏａｄｂａｎｄ）であり得る。
【００９７】
例えば、前記資源は、第１タイプの資源又は第２タイプの資源のうちの一つの資源であり、前記第１タイプの資源は、パンクチャリング（或いはレートマッチング）が常に適用される資源であり、前記第２タイプの資源は、前記相対的に短いレイテンシの要求事項を有するデータ通信が行われるか否かに応じて、パンクチャリング（或いはレートマッチング）が適用される資源であり得る。
【００９８】
このとき、例えば、前記第２タイプの資源では、前記相対的に短いレイテンシの要求事項を有するデータ通信が行われる場合、前記第２タイプの資源がパンクチャリング（或いはレートマッチング）され、及び前記相対的に短いレイテンシの要求事項を有するデータ通信が行われない場合、前記第２タイプの資源がパンクチャリング（或いはレートマッチング）されないことがある。
【００９９】
例えば、前記第１タイプの資源は、前記第２タイプの資源に比べて、相対的に小さいサイズを有し得る。一例として、常に適用されるパンクチャリング（或いはレートマッチング）による性能減少を緩和させるために、タイプ１の場合、タイプ２に比べて相対的に小さいサイズの前記半静的に設定された資源が割り当てられ得る。
【０１００】
例えば、前記第２タイプの場合、前記半静的に設定される資源上に基準信号（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ；ＲＳ）が追加的に（或いは独立に）設定されないことがある。また、第１タイプの場合、前記半静的に設定される資源上に別途の基準信号が設定され得る。
【０１０１】
例えば、前記端末は、ネットワークから前記資源の通信方向を指示する情報を受信し得る。
【０１０２】
例えば、前記端末は、ネットワークから前記資源が有効な時間区間を受信し得る。
【０１０３】
例えば、前記端末は、ネットワークに前記資源に関する補助情報を送信し得る。
【０１０４】
このとき、前記補助情報は、前記資源に対して、前記端末がどのくらいの間前記相対的に短いレイテンシの要求事項を有するデータ通信を行うかを指示する情報を含み得る。このとき、前記補助情報は、前記資源に対するパラメータが、前記相対的に短いレイテンシの要求事項を有するデータ通信に適合するか否かに関する情報を含み得る。このとき、前記補助情報は、前記資源のリリース情報又は前記資源の変更要請情報の少なくとも一つ以上を含み得る。
【０１０５】
以下、説明の便宜のために、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の具体的な例を後述する。
【０１０６】
以下では、端末が相対的に短いレイテンシの要求事項を有するデータ通信のために、半静的に設定された資源を二つのタイプに分けて、無線通信を行う方法について説明する。一例として、前記半静的に設定された二つのタイプの資源（例えば、第１タイプの資源、第２タイプの資源）は、短いレイテンシの要求事項を有するデータ通信をどの程度のレベル／優先順位で保護（ＰＲＯＴＥＣＴＩＯＮ）するかに応じて区分されると見ることもできる。
【０１０７】
［提案方法＃１］  一例として、事前に設定（／シグナリング）された周波数資源（領域）別に（ＵＬ）ＵＲ＿ＳＰＳＲＳＣを指定（／シグナリング）し、各々の（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ上で下記（一部）規則が適用されるようにし得る。
【０１０８】
（例示＃１−１）  一例として、事前に設定（／シグナリング）された（ＵＬ）ＵＲ＿ＳＰＳＲＳＣは、（Ａ）（自身の実際のＬＬＴＣ＿ＳＶＣ送信（及び／又は（ＵＬ）ＵＲ＿ＳＰＳＲＳＣの使用）と関係なく）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣに対するパンクチャリング（或いはレートマッチング）を常に適用させなければならない資源タイプ（ＲＧ＿ＴＹＰＥ＃Ａ）、及び／又は（Ｂ）（自身の）実際のＬＬＴＣ＿ＳＶＣ送信（及び／又は（ＵＬ）ＵＲ＿ＳＰＳＲＳＣの使用）可否に応じて、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣに対するパンクチャリング（或いはレートマッチング）を異なって適用させる資源タイプ（ＲＧ＿ＴＹＰＥ＃Ｂ）に区分され得る。
【０１０９】
ここで、一例として、ＲＧ＿ＴＹＰＥ＃Ｂの場合、実際にＬＬＴＣ＿ＳＶＣ送信が行われる（及び／又は（ＵＬ）ＵＲ＿ＳＰＳＲＳＣが使用）ときのみ、（該当）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣに対するパンクチャリング（或いはレートマッチング）を適用させるようにし得る。
【０１１０】
ここで、一例として、ＲＧ＿ＴＹＰＥ＃Ａは、（同じ（ＳＬＯＴ）時点（及び／又は重なる周波数資源）上で）ＨＬＴＣ＿ＳＶＣ送信なしでＬＬＴＣ＿ＳＶＣ送信のみを行う端末にとって、（該当）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣを（限定的に）利用（及び／又はＲＧ＿ＴＹＰＥ＃Ｂは（同じ（ＳＬＯＴ）時点（及び／又は重なる周波数資源）上で）ＨＬＴＣ＿ＳＶＣ送信とＬＬＴＣ＿ＳＶＣ送信を同時に行う端末にとって、（該当）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣを（限定的に）利用）するようにし得る。
【０１１１】
ここで、一例として、ＲＧ＿ＴＹＰＥ＃Ａを利用する端末間で異なるＲＳ資源（例えば、（ＺＡＤＯＦＦ−ＣＨＵ  ＳＥＱＵＥＮＣＥである場合）ＣＹＣＬＩＣ  ＳＨＩＦＴ（及び／又はＲＯＯＴ  ＩＮＤＥＸ）、（アンテナ）ポートなど）を設定（／シグナリング）することによって、効率的な多重化が行われるようにすることもある。ここで、一例として、（該当）ＲＳ資源割り当て（／シグナリング）は、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ  ＡＣＴＩＶＡＴＩＯＮ  ＤＣＩ（或いは上位層のシグナル（例えば、ＲＲＣ））を介して行われることもある。
【０１１２】
（例示＃１−２）  一例として、（（例示＃１−１）が適用される場合）ＲＧ＿ＴＹＰＥ＃ＡとＲＧ＿ＴＹＰＥ＃Ｂ間に（ＵＬ）ＵＲ＿ＳＰＳＲＳＣのサイズが異なって設定（／シグナリング）され得る。
【０１１３】
ここで、前記説明したように、ＲＧ＿ＴＹＰＥ＃Ａ及び／又はＲＧ＿ＴＹＰＥ＃Ｂは、パンクチャリングが行われ得る資源であるので、ＥＭＢＢのパフォーマンスに直接的な影響を与え得る。特に、ＲＧ＿ＴＹＰＥ＃Ａは、無条件にパンクチャリングが行われるので、ＲＧ＿ＴＹＰＥ＃ＡのサイズがＲＧ＿ＴＹＰＥ＃Ｂよりさらに大きい場合には、相対的にＥＭＢＢの損失が増大するという問題がある。
【０１１４】
前記のような問題点を解決するために、ここで、一例として、（常に適用されるパンクチャリング（或いはレートマッチング）による性能減少を緩和させるために）ＲＧ＿ＴＹＰＥ＃Ａの場合、（ＲＧ＿ＴＹＰＥ＃Ｂに比べて）相対的に小さいサイズの（ＵＬ）ＵＲ＿ＳＰＳＲＳＣが割り当て（／シグナリング）られ得る。
【０１１５】
（例示＃１−３）  一例として、ＲＧ＿ＴＹＰＥ＃Ｂの場合、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ上にＲＳが追加的に（或いは独立に）設定されないことがある。
【０１１６】
ここで、一例として、このような場合、同じ（ＳＬＯＴ）時点（及び／又は重なる周波数資源）上で送信されるＨＬＴＣ＿ＳＶＣ関連の（ＵＬ）ＥＭ＿ＤＹＮＲＳＣ  ＲＳに、ＬＬＴＣ＿ＳＶＣデコーディングチャネルの推定が移行されるようにし得る。
【０１１７】
ここで、一例として、該当規則の適用は、（ＵＬ）ＥＭ＿ＤＹＮＲＳＣに含まれた（ＵＬ）ＵＲ＿ＳＰＳＲＳＣにＬＬＴＣ＿ＳＶＣ送信が行われるとき、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ上のＲＳ（送信）が省略可能であるとも解釈し得る。
【０１１８】
ここで、一例として、（ＲＧ＿ＴＹＰＥ＃Ｂ）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ上でＬＬＴＣ＿ＳＶＣ送信が行われる場合、（（ＵＬ）ＥＭ＿ＤＹＮＲＳＣ上のＨＬＴＣ＿ＳＶＣ送信時とは異なる）事前に設定（／シグナリング）された独立した（シード値（例えば、ＲＮＴＩ、（ＣＥＬＬ）ＩＤ）ベースの）スクランブリングが適用（例えば、基地局が端末のＬＬＴＣ＿ＳＶＣ送信に対するブラインドの検出を容易にするためである）されるようにすることもある。
【０１１９】
ここで、（反対の）一例として、ＲＧ＿ＴＹＰＥ＃Ｂの場合、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ上にＲＳが追加的に（或いは独立に）設定されるようにすることもある。
【０１２０】
また別の一例として、（反面）ＲＧ＿ＴＹＰＥ＃Ａの場合、（特に、（同じ（ＳＬＯＴ）時点（及び／又は重なる周波数資源）上で）ＨＬＴＣ＿ＳＶＣ送信なしでＬＬＴＣ＿ＳＶＣ送信のみが行われるとき）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ上にＲＳが追加的に（或いは独立に）設定され得る。
【０１２１】
以下、理解の便宜のために、提案方法＃１における実施例を図を通じて説明する。
【０１２２】
図８は、提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の一例に対するフローチャートである。
【０１２３】
図８によると、端末は相対的に短いレイテンシの要求事項を有するデータ通信のために半静的に設定された資源を決定することができる（Ｓ８１０）。このとき、前記資源のタイプは、第１タイプ又は第２タイプであり得る。
【０１２４】
例えば、第１タイプは、前記例示＃１−１で説明した（自身の実際のＬＬＴＣ＿ＳＶＣ送信（及び／又は（ＵＬ）ＵＲ＿ＳＰＳＲＳＣの使用）と関係なく）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣに対するパンクチャリング（或いはレートマッチング）を常に適用させなければならない資源タイプ（ＲＧ＿ＴＹＰＥ＃Ａ）（或いはタイプＡ）を意味し得る。また、第２タイプは、前記例示＃１−１で説明した（自身の）実際のＬＬＴＣ＿ＳＶＣ送信（及び／又は（ＵＬ）ＵＲ＿ＳＰＳＲＳＣの使用）可否に応じて、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣに対するパンクチャリング（或いはレートマッチング）を異なって適用させる資源タイプ（ＲＧ＿ＴＹＰＥ＃Ｂ）（或いはタイプＢ）を意味し得る。
【０１２５】
以降、端末は、前記資源のタイプに基づき、前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ８２０）。
【０１２６】
以下、提案方法＃１の理解の便宜のために、ＥＭＢＢスロットにＲＧ＿ＴＹＰＥ＃ＡとＲＧ＿ＴＹＰＥ＃Ｂが位置する例を図を通じて説明する。
【０１２７】
図９は、ＥＭＢＢ領域にＲＧ＿ＴＹＰＥ＃Ａの資源とＲＧ＿ＴＹＰＥ＃Ｂの資源が位置する一例を概略的に示した例である。
【０１２８】
図９によると、ＥＭＢＢ資源領域上に、ＲＧ＿ＴＹＰＥ＃Ａの資源とＲＧ＿ＴＹＰＥ＃Ｂの資源が位置し得る。ここで、ＲＧ＿ＴＹＰＥ＃Ａの資源は第１タイプの資源を、且つＲＧ＿ＴＹＰＥ＃Ｂの資源は第２タイプの資源を意味し得る。
【０１２９】
ここで、第１タイプ（即ち、ＲＧ＿ＴＹＰＥ＃Ａ）の資源は、第２タイプ（即ち、ＲＧ＿ＴＹＰＥ＃Ｂ）の資源に比べて、相対的に高いレベル／優先順位で、ＵＲＬＬＣのオペレーションをする端末の動作を保護するための資源に該当し得る。
【０１３０】
前記説明したように、第１タイプの資源上でＥＭＢＢ動作の実行が設定されたとしても、端末は、前記第１タイプの資源を常にパンクチャリング（或いはレートマッチング）する。
【０１３１】
これによって、他の端末が第１タイプの資源上でＵＲＬＬＣに対する通信を行う場合にこれを保護することができ、相対的に短い“ＬＡＴＥＮＣＹ”（及び／又は高い“ＲＥＬＩＡＢＩＬＩＴＹ”の要求事項）を有するデータ（／サービス）通信（例えば、ＵＲＬＬＣ、Ｖ２Ｘ）（ＬＬＴＣ＿ＳＶＣ）を安定的に支援することができる。
【０１３２】
ここで、第２タイプ（即ち、ＲＧ＿ＴＹＰＥ＃Ｂ）の資源は、前記説明したように、実際にＵＲＬＬＣ動作が行われる場合にのみ、パンクチャリング（或いはレートマッチング）される資源を意味し得る。即ち、実際にＵＲＬＬＣ動作が行われない場合には、前記資源上でパンクチャリング（或いはレートマッチング）が行われず、ＥＭＢＢデータがオーバーライディングされ得る。
【０１３３】
これによって、第２タイプの資源の場合、（ＥＭＢＢデータのスケジューリング関連）グラント検出の誤謬等に影響を受けることがあるので、第１タイプの資源の場合より、相対的にＵＲＬＬＣに対する保護が少なくなることがある。但し、第２タイプの資源は、適応的にＵＲＬＬＣに対するデータが送信されるか、又はＥＭＢＢに対するデータが送信され得るので、第１タイプの資源よりも無線資源の利用効率が増大し得る。
【０１３４】
前記説明した図９では、ＥＭＢＢ（スケジューリング）資源領域上にＲＧ＿ＴＹＰＥ＃Ａの資源（或いは第１タイプの資源）とＲＧ＿ＴＹＰＥ＃Ｂの資源（或いは第２タイプの資源）が位置する構成が示されていた。しかし、ＲＧ＿ＴＹＰＥ＃Ａの資源（或いはＲＧ＿ＴＹＰＥ＃Ｂの資源）が必ずしもＥＭＢＢ（スケジューリング）資源領域上に位置する必要はない（即ち、ＲＧ＿ＴＹＰＥ＃Ａの資源は、ＥＭＢＢの（スケジューリング）支援領域を外れ得る）。これを図を通じて説明すると下記の通りである。
【０１３５】
図１０は、ＥＭＢＢ（スケジューリング）資源領域の外にＲＧ＿ＴＹＰＥ＃Ａの資源が位置する一例を概略的に示した例である。
【０１３６】
図１０によると、ＲＧ＿ＴＹＰＥ＃Ａの資源は図に示されたように、ＥＭＢＢの（スケジューリング）資源領域の外に位置し得る。ここで、ＲＧ＿ＴＹＰＥ＃Ａの資源は第１タイプの資源を、且つＲＧ＿ＴＹＰＥ＃Ｂの資源は第２タイプの資源を意味し得る。
【０１３７】
このように、第１タイプ（即ち、ＲＧ＿ＴＹＰＥ＃Ａ）の資源は、ＥＭＢＢの（スケジューリング）資源領域の外に位置し得るので、第１タイプの資源のための別途の基準信号（ｒｅｆｅｒｅｎｃｅ  ｓｉｇｎａｌ；ＲＳ）が存在し得る。
【０１３８】
図１０のように、第１タイプの資源は、第１タイプの資源のための基準信号が別に設定され得る。また、第２タイプの資源もやはり、例示＃１−３で説明したように、第２タイプの資源のための基準信号が別に設定され得る。
【０１３９】
しかし、第２タイプの資源の場合、必ずしも別の基準信号が設定されなければならないのではなく、第２タイプの資源は、ＥＭＢＢに使用される基準信号を用いて、チャネルの推定も可能である。これを図を通じて説明すると下記の通りである。
【０１４０】
図１１は、ＥＭＢＢに対する基準信号を、ＲＧ＿ＴＹＰＥ＃Ｂの資源が用いる一例を概略的に示した例である。
【０１４１】
図１１によると、例示＃１−３で説明したように、一例として、同じ（ＳＬＯＴ）時点（及び／又は重なる周波数資源）上で送信されるＨＬＴＣ＿ＳＶＣ関連の（ＵＬ）ＥＭ＿ＤＹＮＲＳＣ  ＲＳに、ＬＬＴＣ＿ＳＶＣデコーディングチャネルの推定が移行されるようにし得る。これに関する具体的な内容は前述した通りであるので、具体的な説明は省略する。
【０１４２】
前述したように、端末はＲＧ＿ＴＹＰＥ＃Ａの資源及び／又はＲＧ＿ＴＹＰＥ＃Ｂの資源を用いて、相対的に短いレイテンシの要求事項を有するデータ通信（例えば、ＵＲＬＬＣ）を支援することができる。以下では、説明の便宜のためにＲＧ＿ＴＹＰＥ＃Ａは第１タイプ、ＲＧ＿ＴＹＰＥ＃Ｂは第２タイプと名付けられることができる。
【０１４３】
以下では、第１タイプの資源が設定される実施例、第２タイプの資源が設定される実施例、及び第１タイプの資源及び第２タイプの資源がいずれも設定される実施例を図を通じて各々説明する。
【０１４４】
図１２は、提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の別の例に対するフローチャートである。
【０１４５】
図１２によると、端末は相対的に短いレイテンシの要求事項を有するデータ通信のために半静的に設定された第１タイプの資源を決定することができる（Ｓ１２１０）。
【０１４６】
以降、端末は、前記第１タイプの資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ１２２０）。
【０１４７】
このように、端末が第１タイプの資源を用いて前記データ通信を行う場合、例えば、ＵＲＬＬＣが相対的に高いレベル／優先順位で保護され得る。ここで、第１タイプの資源に関する具体的な内容と、端末が第１タイプの資源上で無線通信を行う具体的な内容は前述した通りである。
【０１４８】
図１３は、提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法のまた別の例に対するフローチャートである。
【０１４９】
図１３によると、端末は、相対的に短いレイテンシの要求事項を有するデータ通信のために半静的に設定された第２タイプの資源を決定することができる（Ｓ１３１０）。
【０１５０】
以降、端末は、前記第２タイプの資源上で、前記相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ１３２０）。
【０１５１】
このように、端末が第２タイプの資源を用いて前記データ通信を行う場合、実際に相対的に短いレイテンシの要求事項を有するデータ通信が行われる場合にのみ、前記第２タイプの資源がパンクチャリングされ、その他の場合には、前記第２資源上で相対的に長いレイテンシを有するデータ通信（例えば、ＥＭＢＢ）が行われ得るので、無線資源の利用効率が増大し得る。ここで、第２タイプの資源に関する具体的な内容と、端末が第２タイプの資源上で無線通信を行う具体的な内容は前述した通りである。
【０１５２】
図１２では、第１タイプの資源が設定された場合を中心に、図１３では、第２タイプの資源が設定された場合を中心に説明した。しかし、これは、必ずしも端末が第１タイプの資源のみを使用しなければならないか、或いは必ずしも端末が第２タイプの資源のみを使用しなければならないということを意味するのではない。即ち、端末は、第１タイプの資源及び第２タイプの資源をいずれも用いて、データ通信を行うこともできる。以下、図を通じて第１タイプの資源及び第２タイプの資源を用いてデータ通信を行う例を説明する。
【０１５３】
図１４は、提案方法＃１による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法のまた別の例に対するフローチャートである。
【０１５４】
図１４によると、相対的に短いレイテンシの要求事項を有するデータ通信のために半静的に設定された第１タイプの資源及び第２タイプの資源を決定することができる（Ｓ１４１０）。
【０１５５】
以降、端末は、前記第１タイプの資源及び／又は前記第２タイプの資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ１４２０）。ここで、第１タイプの資源及び第２タイプの資源に関する具体的な説明と、端末が前記第１タイプの資源及び／又は第２タイプの資源を用いて無線通信を行う具体的な例は、前述した通りである。
【０１５６】
以下では、前記説明した内容に加えて、相対的に短いレイテンシの要求事項を有するデータ通信をより効率的に支援する追加的な構成を説明する。
【０１５７】
［提案方法＃２］  一例として、（事前に）ＵＲ＿ＳＰＳＲＳＣを設定（／シグナリング）し、追加的なシグナリング（例えば、ＤＣＩ）を介して、（該当）ＵＲ＿ＳＰＳＲＳＣの（実際の）用途（／通信方向）（例えば、ＤＬ／ＵＬ  ＵＲ＿ＳＰＳＲＳＣ）を指定し得る。
【０１５８】
ここで、一例として、該当規則が適用される場合、（Ａ）ＤＬ  ＵＲ＿ＳＰＳＲＳＣとＵＬ  ＵＲ＿ＳＰＳＲＳＣが（時間軸で）“ＩＮＴＥＲＬＡＣＩＮＧ”の形態で設定（例えば、（ＬＬＴＣ＿ＳＶＣ関連）ＨＡＲＱ  ＦＥＥＤＢＡＣＫ送／受信に好適な形態）され得、及び／又は（Ｂ）ＤＬ／ＵＬ  ＬＬＴＣ＿ＳＶＣの負荷（比率）によって、（基地局が）ＵＲ＿ＳＰＳＲＳＣの（実際の）用途（／通信方向）を動的に変更することもある。また別の一例として、（事前に）ＤＬ  ＵＲ＿ＳＰＳＲＳＣとＵＬ  ＵＲ＿ＳＰＳＲＳＣが（時間軸で）“ＩＮＴＥＲＬＡＣＩＮＧ”の形態で設定（／シグナリング）されることもある。
【０１５９】
以下、理解の便宜のために、提案方法＃２における実施例を、図を通じて説明する。
【０１６０】
図１５は、提案方法＃２による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の一例に対するフローチャートである。
【０１６１】
図１５によると、端末は、相対的に短いレイテンシの要求事項を有するデータ通信のために半静的に設定された資源を決定することができる（Ｓ１５１０）。ここで、相対的に短いレイテンシの要求事項を有するデータ通信に関する具体的な説明と、前記資源に関する内容は前記説明した通りである。
【０１６２】
端末は、ネットワークから前記資源の用途を指示する情報を受信することができる（Ｓ１５２０）。
【０１６３】
ＮＲ（Ｎｅｗ  Ｒａｄｉｏ  ａｃｃｅｓｓ  ｔｅｃｈｎｏｌｏｇｙ；ＮＲ）では、一つのスロット上にアップリンク及びダウンリンクがいずれも設定され得る。即ち、ＮＲでは、スロット構造が可変的に変更され得、これによって、端末は、（該当）ＵＲ＿ＳＰＳＲＳＣの（実際の）用途（／通信方向）（例えば、ＤＬ／ＵＬ  ＵＲ＿ＳＰＳＲＳＣ）を指定する情報をさらに受信し、可変的なアップリンク及び／又はダウンリンク通信を行うことができる。
【０１６４】
以降、端末は受信された前記情報に基づき、前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ１５３０）。端末が前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行う具体的な例は、前記説明した通りであるので、重複する叙述は省略する。
【０１６５】
［提案方法＃３］  一例として、基地局は、事前に定義された（物理層／上位層）シグナリングを介して、端末に（事前に）設定（／シグナリング）された“ＴＩＭＥ  ＤＵＲＡＴＩＯＮ（／ＷＩＮＤＯＷ）”の間にＵＲ＿ＳＰＳＲＳＣが有効であるかを知らせ得る。
【０１６６】
ここで、一例として、該当規則が適用される場合、端末は有効なＵＲ＿ＳＰＳＲＳＣ上でのみＬＬＴＣ＿ＳＶＣ送／受信動作（／手続）（例えば、ＬＬＴＣ＿ＳＶＣ受信関連の制御チャネルブラインド検出）を行うことになる。
【０１６７】
［提案方法＃４］  一例として、端末は（事前に（或いは現在）設定（／シグナリング）された）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣと関連した下記（一部）“ＡＳＳＩＳＴ  ＩＮＦＯＲＭＡＴＩＯＮ”を基地局に報告し得る。
【０１６８】
ここで、一例として、複数個の（ＵＬ）ＵＲ＿ＳＰＳＲＳＣが（端末に）設定（／シグナリング）された場合、“ＡＳＳＩＳＴ  ＩＮＦＯＲＭＡＴＩＯＮ”は（各々の）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ別に生成／報告されることもある。
【０１６９】
ここで、一例として、特定の端末から、“ＡＳＳＩＳＴ  ＩＮＦＯＲＭＡＴＩＯＮ”を受信した基地局は、該当（特定）端末関連“（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ（／ＲＥＡＣＴＩＶＡＴＩＯＮ）（例えば、周期、サブフレームオフセット、ＲＢの個数、ＭＣＳ）”及び／又は“（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ  ＲＥＬＥＡＳＥ”等を（最終）判断／実行することになる。
【０１７０】
ここで、一例として、（該当）“ＡＳＳＩＳＴ  ＩＮＦＯＲＭＡＴＩＯＮ”は（事前に（或いは現在）設定（／シグナリング）された）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ（或いは、該当用途に（事前に）独立に（或いは追加的に）設定（／シグナリング）された資源）を介して送信するようにすることもある。
【０１７１】
（例示＃４−１）  一例として、事前に（或いは現在）設定（／シグナリング）された（ＵＬ）ＵＲ＿ＳＰＳＲＳＣに対して、端末がどのくらいの間ＬＬＴＣ＿ＳＶＣ送信動作を行うかに対する情報。
【０１７２】
即ち、端末は、前記資源上で、例えば、ＵＲＬＬＣデータアップリンク送信をどれほど行うかに対する情報を送信し得る。端末が送った情報を通じて、端末がこれ以上アップリンク送信を行わないという点をネットワークが知ることになれば、ネットワークは前記資源を他の端末用途として設定し得る。或いは、端末は、前記資源をＥＭＢＢ用途として使用することもある。
【０１７３】
（例示＃４−２）  一例として、事前に（或いは現在）設定（／シグナリング）された（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ関連の周期／サブフレームオフセット／ＲＢの個数／ＭＣＳなどのパラメータが端末の（現在）ＬＬＴＣ＿ＳＶＣ送信に適合するかに対する情報（及び／又は端末の（現在）ＬＬＴＣ＿ＳＶＣ送信に適合した（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ関連（ＥＳＴＩＭＡＴＥＤ）周期／サブフレームオフセット／ＲＢの個数／ＭＣＳなどのパラメータに対する情報及び／又は端末の（（現在）ＬＬＴＣ＿ＳＶＣ送信関連）（ＥＳＴＩＭＡＴＥＤ）パケットサイズ）。
【０１７４】
即ち、端末は、例示＃４−２のように、適合度の情報を送信し得る。端末が送った前記情報を通じて、ネットワークが設定した資源がミスアライアンスされたという点をネットワークが知ることになった場合、ネットワークは前記資源を再設定し得る。
【０１７５】
（例示＃４−３）  一例として、端末に（これ以上）有効ではない（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ（設定）情報及び／又は（特定）（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ関連のＲＥＬＥＡＳＥ要請及び／又は（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ（設定）変更要請。
【０１７６】
以下、理解の便宜のために、提案方法＃４における実施例を図を通じて説明する。
【０１７７】
図１６は、提案方法＃４による、相対的に短いレイテンシの要求事項を有するデータ通信を支援する方法の一例に対するフローチャートである。
【０１７８】
図１６によると、端末は、相対的に短いレイテンシの要求事項を有するデータ通信のために、半静的に設定された資源を決定することができる（Ｓ１６１０）。
【０１７９】
前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行うことができる（Ｓ１６２０）。ここで、前記資源に関する内容は前記説明した通りであるので、説明の便宜のために、重複する内容の叙述は省略する。
【０１８０】
以降、端末は、ネットワークに前記資源と関連した補助情報を送信することができる（Ｓ１６３０）。ここで、端末が送信する補助情報は、前記提案方法＃４で説明した通りであるので、説明の便宜のために、重複する内容の叙述は省略する。
【０１８１】
また別の一例として、基地局は特定の端末に、周波数（／時間）領域上で、ＬＬＴＣ＿ＳＶＣ関連の複数個の（半静的な）（周期的な）アップリンク資源（例えば、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ）を（事前に）設定（／シグナリング）し、そのうちのどれが該当端末に有効な資源であるかを（事前に定義された（物理層／上位層）シグナリングを介して）知らせることもある。
【０１８２】
例えば、基地局はＤＣＩを介して、周波数（／時間）領域上で、ＬＬＴＣ＿ＳＶＣ関連の複数個の（半静的な）（周期的な）アップリンク資源 （例えば、（ＵＬ）ＵＲ＿ＳＰＳＲＳＣ）を（事前に）設定（／シグナリング）し、そのうちのどれが該当端末に有効な資源であるかを、例えば、ＲＲＣシグナリングを介して知らせ得る。
【０１８３】
ここで、一例として、（提案方式に関する）説明の便宜のために、基地局が特定の端末に、二つのシンボルにかけた（ＬＬＴＣ＿ＳＶＣ関連）複数個の（アップリンク）周波数資源を設定（／シグナリング）した状況を仮定する。
【０１８４】
ここで、一例として、このとき、該当端末は（基地局から（さらに）設定（／シグナリング）された）有効な資源上で、ＬＬＴＣ＿ＳＶＣ関連のＳＲ送信には、一番目のシンボル上の（アップリンク）周波数資源のみを使用し、ＬＬＴＣ＿ＳＶＣ関連のデータの送信には一番目／二番目のシンボルにかけた（アップリンク）周波数資源を使用すると仮定する。
【０１８５】
ここで、一例として、このような状況下で、（Ａ）該当端末が（有効な資源上で）ＬＬＴＣ＿ＳＶＣ関連のＳＲ送信とＨＬＴＣ＿ＳＶＣ関連のデータ送信を同時に行わなければならない場合、一番目のシンボル上の（ＬＬＴＣ＿ＳＶＣ関連）（アップリンク）周波数資源上ではＬＬＴＣ＿ＳＶＣ関連のＳＲ送信を行い、二番目のシンボル上の（ＬＬＴＣ＿ＳＶＣ関連）（アップリンク）周波数資源上では、ＨＬＴＣ＿ＳＶＣ関連のデータ送信を行うようにし、及び／又は（Ｂ）該当端末が（有効な資源上で）ＬＬＴＣ＿ＳＶＣ関連のＳＲ送信のみを行わなければならない場合（例えば、ＨＬＴＣ＿ＳＶＣ関連のデータ送信を（同時に）行わない）、一番目／二番目のシンボル上の（ＬＬＴＣ＿ＳＶＣ関連）（アップリンク）周波数資源上でＬＬＴＣ＿ＳＶＣ関連のＳＲを繰り返し送信するようにすることもある。
【０１８６】
また別の一例として、ＬＬＴＣ＿ＳＶＣ関連のダウンリンク（半静的な）（周期的な）通信の場合、（端末にとって）ＡＣＫの場合にのみ、（事前に設定（／シグナリング）されたＨＡＲＱタイムラインによって）ＰＵＣＣＨ（ＳＹＭＢＯＬ）送信を行うようにすることもある。
【０１８７】
ここで、一例として、該当規則が適用される場合、基地局がＬＬＴＣ＿ＳＶＣ関連のダウンリンクの送信を行わなかったときには、（連動した）ＰＵＣＣＨ（ＳＹＭＢＯＬ）を含んだ資源をダウンリンクの用途に変更して使用し得る。
【０１８８】
例えば、端末は、ＡＣＫの場合にのみＰＵＣＣＨ送信を行い、ＮＡＣＫの場合には、ＰＵＣＣＨ送信を行わないことがある。ここで、ＮＡＣＫの場合には、端末が前記のＰＵＣＣＨ送信を行わないので、ネットワークが前記のＰＵＣＣＨ送信が行われるべき資源をダウンリンクのための資源として使用し得る。これによって、本実施例に係る場合には、無線資源を流動的に使用できるので、無線資源の利用効率が増大し得る。
【０１８９】
また別の一例として、ＵＬ  ＵＲ＿ＳＰＳＲＳＣとＵＬ  ＥＭ＿ＤＹＮＲＳＣが（同じＳＬＯＴ上で）“ＦＤＭ”された場合、ＵＬ  ＵＲ＿ＳＰＳＲＳＣ上のＬＬＴＣ＿ＳＶＣ関連の送信のための“ＧＵＡＲＡＮＴＥＥＤ  ＰＯＷＥＲ”（及び／又は（同時送信が行われる場合）ＵＬ  ＵＲ＿ＳＰＳＲＳＣ上の送信とＵＬ  ＥＭ＿ＤＹＮＲＳＣ上の送信間の（送信）電力比率値）が設定（／シグナリング）されることもある。ここで、一例として、該当ＧＵＡＲＡＮＴＥＥＤ  ＰＯＷＥＲ（及び／又は（送信）電力比率値）の適用有無は、（実際）ＵＬ  ＵＲ＿ＳＰＳＲＳＣ上のＬＬＴＣ＿ＳＶＣの送信有無に応じて変わることもある。ここで、一例として、ＤＬ  ＵＲ＿ＳＰＳＲＳＣとＤＬ  ＥＭ＿ＤＹＮＲＳＣが（同じＳＬＯＴ上で）“ＦＤＭ”された場合、事前に設定（／シグナリング）された特定のＲＳパワーに対して（Ａ）該当ＲＳが送信されないシンボル上のデータ（送信）パワー比率、及び／又は（Ｂ）該当ＲＳが送信されるシンボル上のデータ（送信）パワー比率等が（ＤＬ  ＵＲ＿ＳＰＳＲＳＣとＤＬ  ＥＭ＿ＤＹＮＲＳＣ間に）独立に設定（／シグナリング）されることもある。ここで、一例として、前記説明した規則が適用される場合、（ＵＬ／ＤＬ）ＵＲ＿ＳＰＳＲＳＣ上の送信と（ＵＬ／ＤＬ）ＥＭ＿ＤＹＮＲＳＣ上の送信のためのＭＣＳ等が異なって設定（／シグナリング）されることもある。
【０１９０】
前記説明した提案方式に対する一例もまた、本発明の具現方法のうち一つに含まれ得るので、一種の提案方式と見なされ得ることは明白な事実である。また、前記説明した提案方式は、独立に具現されることもあるが、一部提案方式の組み合わせ（或いは併合）の形態で具現されることもある。一例として、本発明の提案方式が適用されるシステムの範囲は、３ＧＰＰ  ＬＴＥシステム以外に他のシステムにも拡張可能である。一例として、本発明の提案方式は、ＬＬＴＣ＿ＳＶＣが動的に割り当てられた資源を介して行われる場合、及び／又はＨＬＴＣ＿ＳＶＣが半静的に設定（／シグナリング）された（周期的な）資源を介して行われる場合にも拡張適用され得る。
【０１９１】
図１７は、本発明の実施例が具現される端末を示したブロック図である。
【０１９２】
図１７を参照すると、端末１１００はプロセッサ１１１０、メモリ１１２０及びＲＦ部（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ  ｕｎｉｔ）１１３０を含む。
【０１９３】
一実施例に係ると、プロセッサ１１１０は、本発明が説明する機能／動作／方法を実施することができる。例えば、プロセッサ１１１０は、相対的に短いレイテンシの要求事項を有するデータ通信のために設定された資源を決定し、及び前記資源上で前記相対的に短いレイテンシの要求事項を有するデータ通信を行うように設定され得る。このとき、前記資源は、半静的に設定された資源であり得る。
【０１９４】
ＲＦ部１１３０は、プロセッサ１１１０と連結され、無線信号を送信及び受信する。
【０１９５】
プロセッサは、ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ）、他のチップセット、論理回路及び／又はデータ処理装置を含み得る。メモリは、ＲＯＭ（ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、フラッシュメモリ、メモリカード、格納媒体及び／又は他の格納装置を含み得る。ＲＦ部は、無線信号を処理するためのベースバンド回路を含み得る。実施例がソフトウェアで具現されるとき、前述した技法は、前述した機能を行うモジュール（過程、機能など）で具現され得る。モジュールはメモリに格納され、プロセッサによって実行されることができる。メモリはプロセッサの内部又は外部にあり得、よく知られている多様な手段でプロセッサと連結され得る。
【０１９６】
また、前記説明した用語に対する定義は、３ＧＰＰ、ＴＳ ３６シリーズと、ＴＳ ３８シリーズの標準スペックの用語に対する内容を参照及び含み得る。
【図１】
0006918124.tif 000002
【図２】
0006918124.tif 000003
【図３】
0006918124.tif 000004
【図４】
0006918124.tif 000005
【図５】
0006918124.tif 000006
【図６】
0006918124.tif 000007
【図７】
0006918124.tif 000008
【図８】
0006918124.tif 000009
【図９】
0006918124.tif 000010
【図１０】
0006918124.tif 000011
【図１１】
0006918124.tif 000012
【図１２】
0006918124.tif 000013
【図１３】
0006918124.tif 000014
【図１４】
0006918124.tif 000015
【図１５】
0006918124.tif 000016
【図１６】
0006918124.tif 000017
【図１７】
0006918124.tif 000018