[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

JP7420732B2 - ユーザ装置および通信システム - Google Patents

ユーザ装置および通信システム Download PDF

Info

Publication number
JP7420732B2
JP7420732B2 JP2020553994A JP2020553994A JP7420732B2 JP 7420732 B2 JP7420732 B2 JP 7420732B2 JP 2020553994 A JP2020553994 A JP 2020553994A JP 2020553994 A JP2020553994 A JP 2020553994A JP 7420732 B2 JP7420732 B2 JP 7420732B2
Authority
JP
Japan
Prior art keywords
packet
base station
communication
transmission
data
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
JP2020553994A
Other languages
English (en)
Other versions
JPWO2020090920A5 (ja
JPWO2020090920A1 (ja
Inventor
忠宏 下田
満 望月
範行 福井
大地 内野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
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 Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Publication of JPWO2020090920A1 publication Critical patent/JPWO2020090920A1/ja
Publication of JPWO2020090920A5 publication Critical patent/JPWO2020090920A5/ja
Priority to JP2024002294A priority Critical patent/JP2024029220A/ja
Application granted granted Critical
Publication of JP7420732B2 publication Critical patent/JP7420732B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H04W56/003—Arrangements to increase tolerance to errors in transmission or reception timing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • 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/1829—Arrangements specially adapted for the receiver end
    • H04L1/1848—Time-out mechanisms
    • H04L1/1851—Time-out mechanisms using multiple timers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H04W56/0055—Synchronisation arrangements determining timing error of reception due to propagation delay
    • H04W56/0065—Synchronisation arrangements determining timing error of reception due to propagation delay using measurement of signal travel time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H04W56/0055—Synchronisation arrangements determining timing error of reception due to propagation delay
    • H04W56/0095—Synchronisation arrangements determining timing error of reception due to propagation delay estimated based on signal strength
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements

Landscapes

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

Description

本発明は、無線通信技術に関する。
移動体通信システムの規格化団体である３ＧＰＰ（3rd Generation Partnership Project）において、無線区間についてはロングタームエボリューション（Long Term Evolution：ＬＴＥ）と称し、コアネットワークおよび無線アクセスネットワーク（以下、まとめて、ネットワークとも称する）を含めたシステム全体構成については、システムアーキテクチャエボリューション（System Architecture Evolution：ＳＡＥ）と称される通信方式が検討されている（例えば、非特許文献１～５）。この通信方式は３．９Ｇ（3.9 Generation）システムとも呼ばれる。
ＬＴＥのアクセス方式としては、下り方向はＯＦＤＭ（Orthogonal Frequency Division Multiplexing）、上り方向はＳＣ－ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）が用いられる。また、ＬＴＥは、Ｗ－ＣＤＭＡ（Wideband Code Division Multiple Access）とは異なり、回線交換を含まず、パケット通信方式のみになる。
非特許文献１（５章）に記載される、３ＧＰＰでの、ＬＴＥシステムにおけるフレーム構成に関する決定事項について、図１を用いて説明する。図１は、ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。図１において、１つの無線フレーム（Radio frame）は１０ｍｓである。無線フレームは１０個の等しい大きさのサブフレーム（Subframe）に分割される。サブフレームは、２個の等しい大きさのスロット（slot）に分割される。無線フレーム毎に１番目および６番目のサブフレームに下り同期信号（Downlink Synchronization Signal）が含まれる。同期信号には、第一同期信号（Primary Synchronization Signal：Ｐ－ＳＳ）と、第二同期信号（Secondary Synchronization Signal：Ｓ－ＳＳ）とがある。
３ＧＰＰでの、ＬＴＥシステムにおけるチャネル構成に関する決定事項が、非特許文献１（５章）に記載されている。ＣＳＧ（Closed Subscriber Group）セルにおいてもｎｏｎ－ＣＳＧセルと同じチャネル構成が用いられると想定されている。
物理報知チャネル（Physical Broadcast Channel：ＰＢＣＨ）は、基地局装置（以下、単に「基地局」という場合がある）から移動端末装置（以下、単に「移動端末」という場合がある）などの通信端末装置（以下、単に「通信端末」という場合がある）への下り送信用のチャネルである。ＢＣＨトランスポートブロック（transport block）は、４０ｍｓ間隔中の４個のサブフレームにマッピングされる。４０ｍｓタイミングの明白なシグナリングはない。
物理制御フォーマットインジケータチャネル（Physical Control Format Indicator Channel：ＰＣＦＩＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＣＦＩＣＨは、ＰＤＣＣＨｓのために用いるＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボルの数を、基地局から通信端末へ通知する。ＰＣＦＩＣＨは、サブフレーム毎に送信される。
物理下り制御チャネル（Physical Downlink Control Channel：ＰＤＣＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＤＣＣＨは、後述のトランスポートチャネルの１つである下り共有チャネル（Downlink Shared Channel：ＤＬ－ＳＣＨ）のリソース割り当て（allocation）情報、後述のトランスポートチャネルの１つであるページングチャネル（Paging Channel：ＰＣＨ）のリソース割り当て（allocation）情報、ＤＬ－ＳＣＨに関するＨＡＲＱ（Hybrid Automatic Repeat reQuest）情報を通知する。ＰＤＣＣＨは、上りスケジューリンググラント（Uplink Scheduling Grant）を運ぶ。ＰＤＣＣＨは、上り送信に対する応答信号であるＡｃｋ（Acknowledgement）／Ｎａｃｋ（Negative Acknowledgement）を運ぶ。ＰＤＣＣＨは、Ｌ１／Ｌ２制御信号とも呼ばれる。
物理下り共有チャネル（Physical Downlink Shared Channel：ＰＤＳＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＤＳＣＨには、トランスポートチャネルである下り共有チャネル（ＤＬ－ＳＣＨ）、およびトランスポートチャネルであるＰＣＨがマッピングされている。
物理マルチキャストチャネル（Physical Multicast Channel：ＰＭＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＭＣＨには、トランスポートチャネルであるマルチキャストチャネル（Multicast Channel：ＭＣＨ）がマッピングされている。
物理上り制御チャネル（Physical Uplink Control Channel：ＰＵＣＣＨ）は、通信端末から基地局への上り送信用のチャネルである。ＰＵＣＣＨは、下り送信に対する応答信号（response signal）であるＡｃｋ／Ｎａｃｋを運ぶ。ＰＵＣＣＨは、ＣＳＩ（Channel State Information）を運ぶ。ＣＳＩは、ＲＩ（Rank Indicator）、ＰＭＩ（Precoding Matrix Indicator）、ＣＱＩ（Channel Quality Indicator）レポートで構成される。ＲＩとは、ＭＩＭＯにおけるチャネル行列のランク情報である。ＰＭＩとは、ＭＩＭＯにて用いるプリコーディングウェイト行列の情報である。ＣＱＩとは、受信したデータの品質、もしくは通信路品質を示す品質情報である。またＰＵＣＣＨは、スケジューリングリクエスト（Scheduling Request：ＳＲ）を運ぶ。
物理上り共有チャネル（Physical Uplink Shared Channel：ＰＵＳＣＨ）は、通信端末から基地局への上り送信用のチャネルである。ＰＵＳＣＨには、トランスポートチャネルの１つである上り共有チャネル（Uplink Shared Channel：ＵＬ－ＳＣＨ）がマッピングされている。
物理ＨＡＲＱインジケータチャネル（Physical Hybrid ARQ Indicator Channel：ＰＨＩＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＨＩＣＨは、上り送信に対する応答信号であるＡｃｋ／Ｎａｃｋを運ぶ。物理ランダムアクセスチャネル（Physical Random Access Channel：ＰＲＡＣＨ）は、通信端末から基地局への上り送信用のチャネルである。ＰＲＡＣＨは、ランダムアクセスプリアンブル（random access preamble）を運ぶ。
下り参照信号（リファレンスシグナル（Reference Signal）：ＲＳ）は、ＬＴＥ方式の通信システムとして既知のシンボルである。以下の５種類の下りリファレンスシグナルが定義されている。セル固有参照信号（Cell-specific Reference Signal：ＣＲＳ）、ＭＢＳＦＮ参照信号（MBSFN Reference Signal）、ＵＥ固有参照信号（UE-specific Reference Signal）であるデータ復調用参照信号（Demodulation Reference Signal：ＤＭ－ＲＳ）、位置決定参照信号（Positioning Reference Signal：ＰＲＳ）、チャネル状態情報参照信号（Channel State Information Reference Signal：ＣＳＩ－ＲＳ）。通信端末の物理レイヤの測定として、リファレンスシグナルの受信電力（Reference Signal Received Power：ＲＳＲＰ）測定がある。
上り参照信号についても同様に、ＬＴＥ方式の通信システムとして既知のシンボルである。以下の２種類の上りリファレンスシグナルが定義されている。データ復調用参照信号（Demodulation Reference Signal：ＤＭ－ＲＳ）、サウンディング用参照信号（Sounding Reference Signal：ＳＲＳ）である。
非特許文献１（５章）に記載されるトランスポートチャネル（Transport channel）について、説明する。下りトランスポートチャネルのうち、報知チャネル（Broadcast Channel：ＢＣＨ）は、その基地局（セル）のカバレッジ全体に報知される。ＢＣＨは、物理報知チャネル（ＰＢＣＨ）にマッピングされる。
下り共有チャネル（Downlink Shared Channel：ＤＬ－ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＤＬ－ＳＣＨは、基地局（セル）のカバレッジ全体への報知が可能である。ＤＬ－ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。準静的なリソース割り当ては、パーシステントスケジューリング（Persistent Scheduling）ともいわれる。ＤＬ－ＳＣＨは、通信端末の低消費電力化のために通信端末の間欠受信（Discontinuous reception：ＤＲＸ）をサポートする。ＤＬ－ＳＣＨは、物理下り共有チャネル（ＰＤＳＣＨ）へマッピングされる。
ページングチャネル（Paging Channel：ＰＣＨ）は、通信端末の低消費電力を可能とするために通信端末のＤＲＸをサポートする。ＰＣＨは、基地局（セル）のカバレッジ全体への報知が要求される。ＰＣＨは、動的にトラフィックに利用できる物理下り共有チャネル（ＰＤＳＣＨ）のような物理リソースへマッピングされる。
マルチキャストチャネル（Multicast Channel：ＭＣＨ）は、基地局（セル）のカバレッジ全体への報知に使用される。ＭＣＨは、マルチセル送信におけるＭＢＭＳ（Multimedia Broadcast Multicast Service）サービス（ＭＴＣＨとＭＣＣＨ）のＳＦＮ合成をサポートする。ＭＣＨは、準静的なリソース割り当てをサポートする。ＭＣＨは、ＰＭＣＨへマッピングされる。
上りトランスポートチャネルのうち、上り共有チャネル（Uplink Shared Channel：ＵＬ－ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＵＬ－ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。ＵＬ－ＳＣＨは、物理上り共有チャネル（ＰＵＳＣＨ）へマッピングされる。
ランダムアクセスチャネル（Random Access Channel：ＲＡＣＨ）は、制御情報に限られている。ＲＡＣＨは、衝突のリスクがある。ＲＡＣＨは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）へマッピングされる。
ＨＡＲＱについて説明する。ＨＡＲＱとは、自動再送要求（Automatic Repeat reQuest：ＡＲＱ）と誤り訂正（Forward Error Correction）との組合せによって、伝送路の通信品質を向上させる技術である。ＨＡＲＱには、通信品質が変化する伝送路に対しても、再送によって誤り訂正が有効に機能するという利点がある。特に、再送にあたって初送の受信結果と再送の受信結果との合成をすることで、更なる品質向上を得ることも可能である。
再送の方法の一例を説明する。受信側にて、受信データが正しくデコードできなかった場合、換言すればＣＲＣ（Cyclic Redundancy Check）エラーが発生した場合（ＣＲＣ＝ＮＧ）、受信側から送信側へ「Ｎａｃｋ」を送信する。「Ｎａｃｋ」を受信した送信側は、データを再送する。受信側にて、受信データが正しくデコードできた場合、換言すればＣＲＣエラーが発生しない場合（ＣＲＣ＝ＯＫ）、受信側から送信側へ「Ａｃｋ」を送信する。「Ａｃｋ」を受信した送信側は次のデータを送信する。
非特許文献１（６章）に記載される論理チャネル（ロジカルチャネル：Logical channel）について、説明する。報知制御チャネル（Broadcast Control Channel：ＢＣＣＨ）は、報知システム制御情報のための下りチャネルである。論理チャネルであるＢＣＣＨは、トランスポートチャネルである報知チャネル（ＢＣＨ）、あるいは下り共有チャネル（ＤＬ－ＳＣＨ）へマッピングされる。
ページング制御チャネル（Paging Control Channel：ＰＣＣＨ）は、ページング情報（Paging Information）およびシステム情報（System Information）の変更を送信するための下りチャネルである。ＰＣＣＨは、通信端末のセルロケーションをネットワークが知らない場合に用いられる。論理チャネルであるＰＣＣＨは、トランスポートチャネルであるページングチャネル（ＰＣＨ）へマッピングされる。
共有制御チャネル（Common Control Channel：ＣＣＣＨ）は、通信端末と基地局との間の送信制御情報のためのチャネルである。ＣＣＣＨは、通信端末がネットワークとの間でＲＲＣ接続（connection）を有していない場合に用いられる。下り方向では、ＣＣＣＨは、トランスポートチャネルである下り共有チャネル（ＤＬ－ＳＣＨ）へマッピングされる。上り方向では、ＣＣＣＨは、トランスポートチャネルである上り共有チャネル（ＵＬ－ＳＣＨ）へマッピングされる。
マルチキャスト制御チャネル（Multicast Control Channel：ＭＣＣＨ）は、１対多の送信のための下りチャネルである。ＭＣＣＨは、ネットワークから通信端末への１つあるいはいくつかのＭＴＣＨ用のＭＢＭＳ制御情報の送信のために用いられる。ＭＣＣＨは、ＭＢＭＳ受信中の通信端末のみに用いられる。ＭＣＣＨは、トランスポートチャネルであるマルチキャストチャネル（ＭＣＨ）へマッピングされる。
個別制御チャネル（Dedicated Control Channel：ＤＣＣＨ）は、１対１にて、通信端末とネットワークとの間の個別制御情報を送信するチャネルである。ＤＣＣＨは、通信端末がＲＲＣ接続（connection）である場合に用いられる。ＤＣＣＨは、上りでは上り共有チャネル（ＵＬ－ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ－ＳＣＨ）にマッピングされる。
個別トラフィックチャネル（Dedicated Traffic Channel：ＤＴＣＨ）は、ユーザ情報の送信のための個別通信端末への１対１通信のチャネルである。ＤＴＣＨは、上りおよび下りともに存在する。ＤＴＣＨは、上りでは上り共有チャネル（ＵＬ－ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ－ＳＣＨ）へマッピングされる。
マルチキャストトラフィックチャネル（Multicast Traffic channel：ＭＴＣＨ）は、ネットワークから通信端末へのトラフィックデータ送信のための下りチャネルである。ＭＴＣＨは、ＭＢＭＳ受信中の通信端末のみに用いられるチャネルである。ＭＴＣＨは、マルチキャストチャネル（ＭＣＨ）へマッピングされる。
ＣＧＩとは、セルグローバル識別子（Cell Global Identifier）のことである。ＥＣＧＩとは、Ｅ－ＵＴＲＡＮセルグローバル識別子（E-UTRAN Cell Global Identifier）のことである。ＬＴＥ、後述のＬＴＥ－Ａ（Long Term Evolution Advanced）およびＵＭＴＳ（Universal Mobile Telecommunication System）において、ＣＳＧ（Closed Subscriber Group）セルが導入される。
通信端末の位置追跡は、１つ以上のセルからなる区域を単位に行われる。位置追跡は、待受け状態であっても通信端末の位置を追跡し、通信端末を呼び出す、換言すれば通信端末が着呼することを可能にするために行われる。この通信端末の位置追跡のための区域をトラッキングエリアと呼ぶ。
また３ＧＰＰでは、リリース１０として、ロングタームエボリューションアドヴァンスド（Long Term Evolution Advanced：ＬＴＥ－Ａ）の規格策定が進められている（非特許文献３、非特許文献４参照）。ＬＴＥ－Ａは、ＬＴＥの無線区間通信方式を基本とし、それにいくつかの新技術を加えて構成される。
ＬＴＥ－Ａシステムでは、１００ＭＨｚまでのより広い周波数帯域幅（transmission bandwidths）をサポートするために、二つ以上のコンポーネントキャリア（Component Carrier：ＣＣ）を集約する（「アグリゲーション（aggregation）する」とも称する）、キャリアアグリゲーション（Carrier Aggregation：ＣＡ）が検討されている。ＣＡについては、非特許文献１に記載されている。
ＣＡが構成される場合、ＵＥはネットワーク（Network：ＮＷ）と唯一つのＲＲＣ接続（RRC connection）を有する。ＲＲＣ接続において、一つのサービングセルがＮＡＳモビリティ情報とセキュリティ入力を与える。このセルをプライマリセル（Primary Cell：ＰＣｅｌｌ）と呼ぶ。下りリンクで、ＰＣｅｌｌに対応するキャリアは、下りプライマリコンポーネントキャリア（Downlink Primary Component Carrier：ＤＬ ＰＣＣ）である。上りリンクで、ＰＣｅｌｌに対応するキャリアは、上りプライマリコンポーネントキャリア（Uplink Primary Component Carrier：ＵＬ ＰＣＣ）である。
ＵＥの能力（ケーパビリティ（capability））に応じて、セカンダリセル（Secondary Cell：ＳＣｅｌｌ）が、ＰＣｅｌｌとともに、サービングセルの組を形成するために構成される。下りリンクで、ＳＣｅｌｌに対応するキャリアは、下りセカンダリコンポーネントキャリア（Downlink Secondary Component Carrier：ＤＬ ＳＣＣ）である。上りリンクで、ＳＣｅｌｌに対応するキャリアは、上りセカンダリコンポーネントキャリア（Uplink Secondary Component Carrier：ＵＬ ＳＣＣ）である。
一つのＰＣｅｌｌと一つ以上のＳＣｅｌｌとからなるサービングセルの組が、一つのＵＥに対して構成される。
また、ＬＴＥ－Ａでの新技術としては、より広い帯域をサポートする技術（Wider bandwidth extension）、および多地点協調送受信（Coordinated Multiple Point transmission and reception：ＣｏＭＰ）技術などがある。３ＧＰＰでＬＴＥ－Ａのために検討されているＣｏＭＰについては、非特許文献１に記載されている。
また、３ＧＰＰにおいて、将来の膨大なトラフィックに対応するために、スモールセルを構成するスモールｅＮＢ（以下「小規模基地局装置」という場合がある）を用いることが検討されている。例えば、多数のスモールｅＮＢを設置して、多数のスモールセルを構成することによって、周波数利用効率を高めて、通信容量の増大を図る技術などが検討されている。具体的には、ＵＥが２つのｅＮＢと接続して通信を行うデュアルコネクティビティ（Dual Connectivity；ＤＣと略称される）などがある。ＤＣについては、非特許文献１に記載されている。
デュアルコネクティビティ（ＤＣ）を行うｅＮＢのうち、一方を「マスタｅＮＢ（ＭｅＮＢと略称される）」といい、他方を「セカンダリｅＮＢ（ＳｅＮＢと略称される）」という場合がある。
モバイルネットワークのトラフィック量は、増加傾向にあり、通信速度も高速化が進んでいる。ＬＴＥおよびＬＴＥ－Ａが本格的に運用を開始されると、更に通信速度が高速化されることが見込まれる。
さらに、高度化する移動体通信に対して、２０２０年以降にサービスを開始することを目標とした第５世代（以下「５Ｇ」という場合がある）無線アクセスシステムが検討されている。例えば、欧州では、ＭＥＴＩＳという団体で５Ｇの要求事項がまとめられている（非特許文献５参照）。
５Ｇ無線アクセスシステムでは、ＬＴＥシステムに対して、システム容量は１０００倍、データの伝送速度は１００倍、データの処理遅延は１０分の１（１／１０）、通信端末の同時接続数は１００倍として、更なる低消費電力化、および装置の低コスト化を実現することが要件として挙げられている。
このような要求を満たすために、３ＧＰＰでは、リリース１５として、５Ｇの規格検討が進められている（非特許文献６～１８参照）。５Ｇの無線区間の技術は「New Radio Access Technology」と称される（「New Radio」は「ＮＲ」と略称される）。
ＮＲシステムは、ＬＴＥシステム、ＬＴＥ－Ａシステムを基にして検討が進められているが、以下の点でＬＴＥシステム、ＬＴＥ－Ａシステムからの変更および追加が行われている。
ＮＲのアクセス方式としては、下り方向はＯＦＤＭ、上り方向はＯＦＤＭ、ＤＦＴ－ｓ－ＯＦＤＭ（DFT-spread-OFDM）が用いられる。
ＮＲでは、伝送速度向上、処理遅延低減のために、ＬＴＥに比べて高い周波数の使用が可能となっている。
ＮＲにおいては、狭いビーム状の送受信範囲を形成する（ビームフォーミング）とともにビームの向きを変化させる（ビームスイーピング）ことで、セルカバレッジの確保が図られる。
ＮＲのフレーム構成においては、様々なサブキャリア間隔、すなわち、様々なヌメロロジ（Numerology）がサポートされている。ＮＲにおいては、ヌメロロジによらず、１サブフレームは１ミリ秒であり、また、１スロットは１４シンボルで構成される。また、１サブフレームに含まれるスロット数は、サブキャリア間隔１５ｋＨｚのヌメロロジにおいては１つであり、他のヌメロロジにおいては、サブキャリア間隔に比例して多くなる（非特許文献１３（TS38.211 v15.2.0）参照）。
ＮＲにおける下り同期信号は、同期信号バースト（Synchronization Signal Burst；以下、ＳＳバーストと称する場合がある）として、所定の周期で、所定の継続時間をもって基地局から送信される。ＳＳバーストは、基地局のビーム毎の同期信号ブロック（Synchronization Signal Block；以下、ＳＳブロックと称する場合がある）により構成される。基地局はＳＳバーストの継続時間内において各ビームのＳＳブロックを、ビームを変えて送信する。ＳＳブロックは、Ｐ－ＳＳ、Ｓ－ＳＳ、およびＰＢＣＨによって構成される。
ＮＲにおいては、ＮＲの下り参照信号として、位相追尾参照信号（Phase Tracking Reference Signal：ＰＴＲＳ）の追加により、位相雑音の影響の低減が図られている。上り参照信号においても、下りと同様にＰＴＲＳが追加されている。
ＮＲにおいては、スロット内におけるＤＬ／ＵＬの切替えを柔軟に行うために、ＰＤＣＣＨに含まれる情報にスロット構成通知（Slot Format Indication：ＳＦＩ）が追加された。
また、ＮＲにおいては、キャリア周波数帯のうちの一部（以下、Bandwidth Part（ＢＷＰ）と称する場合がある）を基地局がＵＥに対して予め設定し、ＵＥが該ＢＷＰにおいて基地局との送受信を行うことで、ＵＥにおける消費電力の低減が図られる。
３ＧＰＰでは、ＤＣの形態として、ＥＰＣに接続するＬＴＥ基地局とＮＲ基地局によるＤＣ、５Ｇコアシステムに接続するＮＲ基地局によるＤＣ、また、５Ｇコアシステムに接続するＬＴＥ基地局とＮＲ基地局によるＤＣが検討されている（非特許文献１２、１６、１９参照）。
また、３ＧＰＰでは、いくつかの新たな技術が検討されている。例えば、ジッタ特性の向上（非特許文献２０（３ＧＰＰ ＲＰ－１８０９７４）参照）、セルの高速立ち上げ（非特許文献２１（３ＧＰＰ ＲＰ－１８１４６９））、サイドリンクにおけるユニキャスト通信（非特許文献２２（３ＧＰＰ ＲＰ－１８２１１１）参照）などが検討されている。
３ＧＰＰ ＴＳ ３６．３００ Ｖ１５．２．０ ３ＧＰＰ Ｓ１－０８３４６１ ３ＧＰＰ ＴＲ ３６．８１４ Ｖ９．２．０ ３ＧＰＰ ＴＲ ３６．９１２ Ｖ１５．０．０ "Scenarios, requirements and KPIs for 5G mobile and wireless system"、ＩＣＴ－３１７６６９－ＭＥＴＩＳ／Ｄ１．１ ３ＧＰＰ ＴＲ ２３．７９９ Ｖ１４．０．０ ３ＧＰＰ ＴＲ ３８．８０１ Ｖ１４．０．０ ３ＧＰＰ ＴＲ ３８．８０２ Ｖ１４．２．０ ３ＧＰＰ ＴＲ ３８．８０４ Ｖ１４．０．０ ３ＧＰＰ ＴＲ ３８．９１２ Ｖ１４．１．０ ３ＧＰＰ ＲＰ－１７２１１５ ３ＧＰＰ ＴＳ ３７．３４０ Ｖ１５．２．０ ３ＧＰＰ ＴＳ ３８．２１１ Ｖ１５．２．０ ３ＧＰＰ ＴＳ ３８．２１３ Ｖ１５．２．０ ３ＧＰＰ ＴＳ ３８．２１４ Ｖ１５．２．０ ３ＧＰＰ ＴＳ ３８．３００ Ｖ１５．２．０ ３ＧＰＰ ＴＳ ３８．３２１ Ｖ１５．２．０ ３ＧＰＰ ＴＳ ３８．２１２ Ｖ１５．２．０ ３ＧＰＰ ＲＰ－１６１２６６ ３ＧＰＰ ＲＰ－１８０９７４ ３ＧＰＰ ＲＰ－１８１４６９ ３ＧＰＰ ＲＰ－１８２１１１ ３ＧＰＰ ＴＲ２２．８０４ Ｖ１６．１．０ ３ＧＰＰ ＴＳ３６．３２１ Ｖ１５．２．０ ３ＧＰＰ ＲＰ－１６１７８８ ３ＧＰＰ ＴＳ３８．３３１ Ｖ１５．２．１ ３ＧＰＰ ＴＳ３６．２１３ Ｖ１５．３．０
３ＧＰＰにおいて、低遅延と高信頼性の通信（Ultra-reliable and Low Latency Communications；ＵＲＬＬＣ）の要件に加え、低いジッタ特性が求められている（非特許文献２０（３ＧＰＰ ＲＰ－１８０９７４）、非特許文献２３（３ＧＰＰ ＴＲ２２．８０４ Ｖ１６．１．０）参照）。ＵＲＬＬＣの要件を満たすために、パケット複製が用いられる（非特許文献１６参照）。ところが、パケット複製において、受信したパケットを上位レイヤに転送するタイミングについては規定されていない。このことにより、受信タイミングが先となるパケットの復号結果（例：ＣＲＣ結果）によって、受信側装置がパケットを上位レイヤに転送するタイミングが異なる。その結果、レイテンシのばらつき（以下、ジッタと称する場合がある）が生じ、ジッタ特性が悪化するといった問題が生じる。
また、Ｖ２Ｖ（Vehicle to Vehicle）通信のためにサポートされているサイドリンク（SL：Side Link）において、ユニキャスト通信の適用が検討されている。ところが、片方のＵＥから他方のＵＥへの通信は可能であるが、反対方向の通信、すなわち、該他方のＵＥから該片方のＵＥへの通信における送信リソースの設定方法について開示されていない。そのため、反対方向の通信が不可能となり、その結果、ユニキャスト通信における双方向通信が確立できない、という問題が生じる。
本発明は、上記課題に鑑み、アップリンク通信とダウンリンク通信とサイドリンク通信とのうちの少なくとも１つにおいて、低遅延、高信頼性、かつ、低いジッタ特性を実現しうる無線通信技術を提供することを、目的の一つとする。
本発明によれば、サイドリンクにおいて互いに通信可能な複数のユーザ装置と、複数の前記ユーザ装置の各々と無線通信する基地局と、を備える通信システムにおける１つのユーザ装置であって、前記ユーザ装置は、他のユーザ装置に対して、前記サイドリンクにおけるユニキャスト送信のためのリソースに関する設定を要求する要求シグナリングを送信し、前記他のユーザ装置から、前記リソースに関する前記設定に関する情報を受信し、前記要求シグナリングは、優先順位に関する情報を含む。
また、本発明によれば、サイドリンクにおいて互いに通信可能な複数のユーザ装置と、複数の前記ユーザ装置の各々と無線通信する基地局と、を備える通信システムであって、１つのユーザ装置が、他のユーザ装置に対して、前記サイドリンクにおけるユニキャスト送信のためのリソースに関する設定を要求する要求シグナリングを送信し、前記他のユーザ装置から、前記リソースに関する前記設定に関する情報を受信し、前記要求シグナリングは、優先順位に関する情報を含む。
本発明によれば、低遅延、高信頼性、かつ、低いジッタ特性を実現可能である。
本発明の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。
ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。 ３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム２００の全体的な構成を示すブロック図である。 ３ＧＰＰにおいて議論されているＮＲ方式の通信システム２１０の全体的な構成を示すブロック図である。 ＥＰＣに接続するｅＮＢおよびｇＮＢによるＤＣの構成図である。 ＮＧコアに接続するｇＮＢによるＤＣの構成図である。 ＮＧコアに接続するｅＮＢおよびｇＮＢによるＤＣの構成図である。 ＮＧコアに接続するｅＮＢおよびｇＮＢによるＤＣの構成図である。 図２に示す移動端末２０２の構成を示すブロック図である。 図２に示す基地局２０３の構成を示すブロック図である。 ＭＭＥの構成を示すブロック図である。 ５ＧＣの構成を示すブロック図である。 ＬＴＥ方式の通信システムにおいて通信端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。 ＮＲシステムにおけるセルの構成の一例を示す図である。 実施の形態１について、受信側装置が、複製されたパケットのうち後から送信されるパケットの受信タイミングにおいて、パケットを上位レイヤに転送する動作を示す図である。 実施の形態１について、受信側装置が所定のタイミングにおいて受信パケットを上位レイヤに転送する動作を示す図である。 実施の形態１について、受信側装置が、複製されたパケットのうち後から送信されるパケットの受信タイミングにおいて、パケットを上位レイヤに転送する動作の他の例を示す図である。 実施の形態１について、受信側装置が所定のタイミングにおいて受信パケットを上位レイヤに転送する動作の他の例を示す図である。 実施の形態１の変形例１について、複製したパケットを同じキャリア上で送受信する動作を示す図である。 実施の形態１の変形例１について、複製したパケットを同じキャリア上で送受信する動作の他の例を示す図である。 実施の形態１の変形例１について、複製したパケットを同じキャリア上で送受信する動作の他の例を示す図である。 実施の形態１の変形例１について、複製したパケットを同じキャリア上で送受信する動作の他の例を示す図である。 実施の形態１の変形例２について、受信側装置が、レペティションにおける所定の反復回数の途中で、ＨＡＲＱフィードバックおよび上位レイヤへの転送を行う動作を示す図である。 実施の形態１の変形例３について、ジッタクリティカルな論理チャネルとレイテンシ要件がある論理チャネルの両方が存在する場合のＬＣＰの動作を示す図である。 実施の形態１の変形例３について、ジッタクリティカルな論理チャネルにおける優先度のオフセット付与を示す図である。 実施の形態１の変形例３について、ジッタクリティカルな論理チャネルにおける優先度のオフセット付与の他の例を示す図である。 実施の形態１の変形例３について、レイテンシ要件がある論理チャネルにおける優先度のオフセット付与を示す図である。 実施の形態３について、ＳＬ通信の概念図である（ブロードキャスト通信）。 実施の形態３について、ＳＬ通信の概念図である（ユニキャスト通信）。 実施の形態３の変形例１について、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第１例である。 実施の形態３の変形例１について、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第２例である。 実施の形態３の変形例１について、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第３例である。 実施の形態３の変形例１について、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第４例である。 実施の形態３の変形例１について、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第５例である。 実施の形態３の変形例１について、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第６例である。 実施の形態３の変形例１について、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第７例である。 実施の形態５について、ＳＬでの初送および／あるいは再送に用いるリソースをリザベーションする方法の一例を示す概念図である。 実施の形態５について、ＳＬでの初送および／あるいは再送用に、複数セットの周期的リソースをリザベーションする方法の一例を示す概念図である。 実施の形態５について、ＳＬでの初送に用いられるリソースと再送に用いられるリソースとを個別にリザベーションする方法の一例を示す概念図である。 実施の形態５について、ＳＬでの初送と再送に用いられるリソースのグループをリザベーションする方法の一例を示す概念図である。 実施の形態５について、ＳＬでの再送に用いられるリソースを再送時にリザベーションする方法の一例を示す概念図である。
実施の形態１．
図２は、３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム２００の全体的な構成を示すブロック図である。図２について説明する。無線アクセスネットワークは、Ｅ－ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）２０１と称される。通信端末装置である移動端末装置（以下「移動端末（User Equipment：ＵＥ）」という）２０２は、基地局装置（以下「基地局（E-UTRAN NodeB：ｅＮＢ）」という）２０３と無線通信可能であり、無線通信で信号の送受信を行う。
ここで、「通信端末装置」とは、移動可能な携帯電話端末装置などの移動端末装置だけでなく、センサなどの移動しないデバイスも含んでいる。以下の説明では、「通信端末装置」を、単に「通信端末」という場合がある。
移動端末２０２に対する制御プロトコル、例えばＲＲＣ（Radio Resource Control）と、ユーザプレイン（以下、Ｕ－Ｐｌａｎｅと称する場合もある）、例えばＰＤＣＰ（Packet Data Convergence Protocol）、ＲＬＣ（Radio Link Control）、ＭＡＣ（Medium Access Control）、ＰＨＹ（Physical layer）とが基地局２０３で終端するならば、Ｅ－ＵＴＲＡＮは１つあるいは複数の基地局２０３によって構成される。
移動端末２０２と基地局２０３との間の制御プロトコルＲＲＣ（Radio Resource Control）は、報知（Broadcast）、ページング（paging）、ＲＲＣ接続マネージメント（RRC connection management）などを行う。ＲＲＣにおける基地局２０３と移動端末２０２との状態として、ＲＲＣ＿ＩＤＬＥと、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤとがある。
ＲＲＣ＿ＩＤＬＥでは、ＰＬＭＮ（Public Land Mobile Network）選択、システム情報（System Information：ＳＩ）の報知、ページング（paging）、セル再選択（cell re-selection）、モビリティなどが行われる。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、移動端末はＲＲＣ接続（connection）を有し、ネットワークとのデータの送受信を行うことができる。またＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、ハンドオーバ（Handover：ＨＯ）、隣接セル（Neighbor cell）の測定（メジャメント（measurement））などが行われる。
基地局２０３は、１つあるいは複数のｅＮＢ２０７により構成される。またコアネットワークであるＥＰＣ（Evolved Packet Core）と、無線アクセスネットワークであるＥ－ＵＴＲＡＮ２０１とで構成されるシステムは、ＥＰＳ（Evolved Packet System）と称される。コアネットワークであるＥＰＣと、無線アクセスネットワークであるＥ－ＵＴＲＡＮ２０１とを合わせて、「ネットワーク」という場合がある。
ｅＮＢ２０７は、移動管理エンティティ（Mobility Management Entity：ＭＭＥ）、あるいはＳ－ＧＷ（Serving Gateway）、あるいはＭＭＥおよびＳ－ＧＷを含むＭＭＥ／Ｓ－ＧＷ部（以下「ＭＭＥ部」という場合がある）２０４とＳ１インタフェースにより接続され、ｅＮＢ２０７とＭＭＥ部２０４との間で制御情報が通信される。一つのｅＮＢ２０７に対して、複数のＭＭＥ部２０４が接続されてもよい。ｅＮＢ２０７間は、Ｘ２インタフェースにより接続され、ｅＮＢ２０７間で制御情報が通信される。
ＭＭＥ部２０４は、上位装置、具体的には上位ノードであり、基地局であるｅＮＢ２０７と、移動端末（ＵＥ）２０２との接続を制御する。ＭＭＥ部２０４は、コアネットワークであるＥＰＣを構成する。基地局２０３は、Ｅ－ＵＴＲＡＮ２０１を構成する。
基地局２０３は、１つのセルを構成してもよいし、複数のセルを構成してもよい。各セルは、移動端末２０２と通信可能な範囲であるカバレッジとして予め定める範囲を有し、カバレッジ内で移動端末２０２と無線通信を行う。１つの基地局２０３が複数のセルを構成する場合、１つ１つのセルが、移動端末２０２と通信可能に構成される。
図３は、３ＧＰＰにおいて議論されている５Ｇ方式の通信システム２１０の全体的な構成を示すブロック図である。図３について説明する。無線アクセスネットワークは、ＮＧ－ＲＡＮ（Next Generation Radio Access Network）２１１と称される。ＵＥ２０２は、ＮＲ基地局装置（以下「ＮＲ基地局（NG-RAN NodeB：ｇＮＢ）」という）２１３と無線通信可能であり、無線通信で信号の送受信を行う。また、コアネットワークは、５Ｇコア（5G Core：５ＧＣ）と称される。
ＵＥ２０２に対する制御プロトコル、例えばＲＲＣ（Radio Resource Control）と、ユーザプレイン（以下、Ｕ－Ｐｌａｎｅと称する場合もある）、例えばＳＤＡＰ（Service Data Adaptation Protocol）、ＰＤＣＰ（Packet Data Convergence Protocol）、ＲＬＣ（Radio Link Control）、ＭＡＣ（Medium Access Control）、ＰＨＹ（Physical layer）とがＮＲ基地局２１３で終端するならば、ＮＧ－ＲＡＮは１つあるいは複数のＮＲ基地局２１３によって構成される。
ＵＥ２０２とＮＲ基地局２１３との間の制御プロトコルＲＲＣ（Radio Resource Control）の機能はＬＴＥと同様である。ＲＲＣにおけるＮＲ基地局２１３とＵＥ２０２との状態として、ＲＲＣ＿ＩＤＬＥと、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤと、ＲＲＣ＿ＩＮＡＣＴＩＶＥとがある。
ＲＲＣ＿ＩＤＬＥ、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤは、ＬＴＥ方式と同様である。ＲＲＣ＿ＩＮＡＣＴＩＶＥは５ＧコアとＮＲ基地局２１３との間の接続が維持されつつ、システム情報（System Information：ＳＩ）の報知、ページング（paging）、セル再選択（cell re-selection）、モビリティなどが行われる。
ｇＮＢ２１７は、アクセス・移動管理機能（Access and Mobility Management Function：ＡＭＦ）、セッション管理機能（Session Management Function：ＳＭＦ）、あるいはＵＰＦ（User Plane Function）、あるいはＡＭＦ、ＳＭＦおよびＵＰＦを含むＡＭＦ／ＳＭＦ／ＵＰＦ部（以下「５ＧＣ部」という場合がある）２１４とＮＧインタフェースにより接続される。ｇＮＢ２１７と５ＧＣ部２１４との間で制御情報および／あるいはユーザデータが通信される。ＮＧインタフェースは、ｇＮＢ２１７とＡＭＦとの間のＮ２インタフェース、ｇＮＢ２１７とＵＰＦとの間のＮ３インタフェース、ＡＭＦとＳＭＦとの間のＮ１１インタフェース、および、ＵＰＦとＳＭＦとの間のＮ４インタフェースの総称である。一つのｇＮＢ２１７に対して、複数の５ＧＣ部２１４が接続されてもよい。ｇＮＢ２１７間は、Ｘｎインタフェースにより接続され、ｇＮＢ２１７間で制御情報および／あるいはユーザデータが通信される。
ＮＲ基地局２１３も、基地局２０３同様、１つあるいは複数のセルを構成してもよい。１つのＮＲ基地局２１３が複数のセルを構成する場合、１つ１つのセルが、ＵＥ２０２と通信可能に構成される。
ｇＮＢ２１７は、中央ユニット（Central Unit；以下、ＣＵと称する場合がある）２１８と分散ユニット（Distributed Unit；以下、ＤＵと称する場合がある）２１９に分割されていてもよい。ＣＵ２１８は、ｇＮＢ２１７の中に１つ構成される。ＤＵ２１９は、ｇＮＢ２１７の中に１つあるいは複数構成される。ＣＵ２１８は、ＤＵ２１９とＦ１インタフェースにより接続され、ＣＵ２１８とＤＵ２１９との間で制御情報および／あるいはユーザデータが通信される。
図４は、ＥＰＣに接続するｅＮＢおよびｇＮＢによるＤＣの構成を示した図である。図４において、実線はＵ－Ｐｌａｎｅの接続を示し、破線はＣ－Ｐｌａｎｅの接続を示す。図４において、ｅＮＢ２２３－１がマスタ基地局となり、ｇＮＢ２２４－２がセカンダリ基地局となる（このＤＣ構成を、ＥＮ－ＤＣと称する場合がある）。図４において、ＭＭＥ部２０４とｇＮＢ２２４－２との間のＵ－Ｐｌａｎｅ接続がｅＮＢ２２３－１経由で行われる例について示しているが、ＭＭＥ部２０４とｇＮＢ２２４－２との間で直接行われてもよい。
図５は、ＮＧコアに接続するｇＮＢによるＤＣの構成を示した図である。図５において、実線はＵ－Ｐｌａｎｅの接続を示し、破線はＣ－Ｐｌａｎｅの接続を示す。図５において、ｇＮＢ２２４－１がマスタ基地局となり、ｇＮＢ２２４－２がセカンダリ基地局となる（このＤＣ構成を、ＮＲ－ＤＣと称する場合がある）。図５において、５ＧＣ部２１４とｇＮＢ２２４－２との間のＵ－Ｐｌａｎｅ接続がｇＮＢ２２４－１経由で行われる例について示しているが、５ＧＣ部２１４とｇＮＢ２２４－２との間で直接行われてもよい。
図６は、ＮＧコアに接続するｅＮＢおよびｇＮＢによるＤＣの構成を示した図である。図６において、実線はＵ－Ｐｌａｎｅの接続を示し、破線はＣ－Ｐｌａｎｅの接続を示す。図６において、ｅＮＢ２２６－１がマスタ基地局となり、ｇＮＢ２２４－２がセカンダリ基地局となる（このＤＣ構成を、ＮＧ－ＥＮ－ＤＣと称する場合がある）。図６において、５ＧＣ部２１４とｇＮＢ２２４－２との間のＵ－Ｐｌａｎｅ接続がｅＮＢ２２６－１経由で行われる例について示しているが、５ＧＣ部２１４とｇＮＢ２２４－２との間で直接行われてもよい。
図７は、ＮＧコアに接続するｅＮＢおよびｇＮＢによるＤＣの、他の構成を示した図である。図７において、実線はＵ－Ｐｌａｎｅの接続を示し、破線はＣ－Ｐｌａｎｅの接続を示す。図７において、ｇＮＢ２２４－１がマスタ基地局となり、ｅＮＢ２２６－２がセカンダリ基地局となる（このＤＣ構成を、ＮＥ－ＤＣと称する場合がある）。図７において、５ＧＣ部２１４とｅＮＢ２２６－２との間のＵ－Ｐｌａｎｅ接続がｇＮＢ２２４－１経由で行われる例について示しているが、５ＧＣ部２１４とｅＮＢ２２６－２との間で直接行われてもよい。
図８は、図２に示す移動端末２０２の構成を示すブロック図である。図８に示す移動端末２０２の送信処理を説明する。まず、プロトコル処理部３０１からの制御データ、およびアプリケーション部３０２からのユーザデータが、送信データバッファ部３０３へ保存される。送信データバッファ部３０３に保存されたデータは、エンコーダー部３０４へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部３０３から変調部３０５へ直接出力されるデータが存在してもよい。エンコーダー部３０４でエンコード処理されたデータは、変調部３０５にて変調処理が行われる。変調部３０５にて、ＭＩＭＯにおけるプリコーディングが行われてもよい。変調されたデータは、ベースバンド信号に変換された後、周波数変換部３０６へ出力され、無線送信周波数に変換される。その後、アンテナ３０７－１～３０７－４から基地局２０３に送信信号が送信される。図８において、アンテナの数が４つである場合について例示したが、アンテナ数は４つに限定されない。
また、移動端末２０２の受信処理は、以下のように実行される。基地局２０３からの無線信号がアンテナ３０７－１～３０７－４により受信される。受信信号は、周波数変換部３０６にて無線受信周波数からベースバンド信号に変換され、復調部３０８において復調処理が行われる。復調部３０８にて、ウェイト計算および乗算処理が行われてもよい。復調後のデータは、デコーダー部３０９へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部３０１へ渡され、ユーザデータはアプリケーション部３０２へ渡される。移動端末２０２の一連の処理は、制御部３１０によって制御される。よって制御部３１０は、図８では省略しているが、各部３０１～３０９と接続している。図８において、移動端末２０２が送信に用いるアンテナ数と受信に用いるアンテナ数は、同じであってもよいし、異なっていてもよい。
図９は、図２に示す基地局２０３の構成を示すブロック図である。図９に示す基地局２０３の送信処理を説明する。ＥＰＣ通信部４０１は、基地局２０３とＥＰＣ（ＭＭＥ部２０４など）との間のデータの送受信を行う。５ＧＣ通信部４１２は、基地局２０３と５ＧＣ（５ＧＣ部２１４など）との間のデータの送受信を行う。他基地局通信部４０２は、他の基地局との間のデータの送受信を行う。ＥＰＣ通信部４０１、５ＧＣ通信部４１２、および他基地局通信部４０２は、それぞれプロトコル処理部４０３と情報の受け渡しを行う。プロトコル処理部４０３からの制御データ、ならびにＥＰＣ通信部４０１、５ＧＣ通信部４１２、および他基地局通信部４０２からのユーザデータおよび制御データは、送信データバッファ部４０４へ保存される。
送信データバッファ部４０４に保存されたデータは、エンコーダー部４０５へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部４０４から変調部４０６へ直接出力されるデータが存在してもよい。エンコードされたデータは、変調部４０６にて変調処理が行われる。変調部４０６にて、ＭＩＭＯにおけるプリコーディングが行われてもよい。変調されたデータは、ベースバンド信号に変換された後、周波数変換部４０７へ出力され、無線送信周波数に変換される。その後、アンテナ４０８－１～４０８－４より一つもしくは複数の移動端末２０２に対して送信信号が送信される。図９において、アンテナの数が４つである場合について例示したが、アンテナ数は４つに限定されない。
また、基地局２０３の受信処理は以下のように実行される。一つもしくは複数の移動端末２０２からの無線信号が、アンテナ４０８により受信される。受信信号は、周波数変換部４０７にて無線受信周波数からベースバンド信号に変換され、復調部４０９で復調処理が行われる。復調されたデータは、デコーダー部４１０へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部４０３あるいは５ＧＣ通信部４１２あるいはＥＰＣ通信部４０１、他基地局通信部４０２へ渡され、ユーザデータは５ＧＣ通信部４１２、ＥＰＣ通信部４０１および他基地局通信部４０２へ渡される。基地局２０３の一連の処理は、制御部４１１によって制御される。よって制御部４１１は、図９では省略しているが、各部４０１～４１０と接続している。図９において、基地局２０３が送信に用いるアンテナ数と受信に用いるアンテナ数は、同じであってもよいし、異なっていてもよい。
図９は、基地局２０３の構成について示したブロック図であるが、基地局２１３についても同様の構成としてもよい。また、図８および図９について、移動端末２０２のアンテナ数と、基地局２０３のアンテナ数は、同じであってもよいし、異なってもよい。
図１０は、ＭＭＥの構成を示すブロック図である。図１０では、前述の図２に示すＭＭＥ部２０４に含まれるＭＭＥ２０４ａの構成を示す。ＰＤＮ ＧＷ通信部５０１は、ＭＭＥ２０４ａとＰＤＮ ＧＷとの間のデータの送受信を行う。基地局通信部５０２は、ＭＭＥ２０４ａと基地局２０３との間のＳ１インタフェースによるデータの送受信を行う。ＰＤＮ ＧＷから受信したデータがユーザデータであった場合、ユーザデータは、ＰＤＮ ＧＷ通信部５０１から、ユーザプレイン通信部５０３経由で基地局通信部５０２に渡され、１つあるいは複数の基地局２０３へ送信される。基地局２０３から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部５０２から、ユーザプレイン通信部５０３経由でＰＤＮ ＧＷ通信部５０１に渡され、ＰＤＮ ＧＷへ送信される。
ＰＤＮ ＧＷから受信したデータが制御データであった場合、制御データは、ＰＤＮ ＧＷ通信部５０１から制御プレイン制御部５０５へ渡される。基地局２０３から受信したデータが制御データであった場合、制御データは、基地局通信部５０２から制御プレイン制御部５０５へ渡される。
制御プレイン制御部５０５には、ＮＡＳセキュリティ部５０５－１、ＳＡＥベアラコントロール部５０５－２、アイドルステート（Idle State）モビリティ管理部５０５－３などが含まれ、制御プレイン（以下、Ｃ－Ｐｌａｎｅと称する場合もある）に対する処理全般を行う。ＮＡＳセキュリティ部５０５－１は、ＮＡＳ（Non-Access Stratum）メッセージのセキュリティなどを行う。ＳＡＥベアラコントロール部５０５－２は、ＳＡＥ（System Architecture Evolution）のベアラの管理などを行う。アイドルステートモビリティ管理部５０５－３は、待受け状態（アイドルステート（Idle State）；ＬＴＥ－ＩＤＬＥ状態、または、単にアイドルとも称される）のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の１つあるいは複数の移動端末２０２のトラッキングエリアの追加、削除、更新、検索、トラッキングエリアリスト管理などを行う。
ＭＭＥ２０４ａは、１つまたは複数の基地局２０３に対して、ページング信号の分配を行う。また、ＭＭＥ２０４ａは、待受け状態（Idle State）のモビリティ制御（Mobility control）を行う。ＭＭＥ２０４ａは、移動端末が待ち受け状態のとき、および、アクティブ状態（Active State）のときに、トラッキングエリア（Tracking Area）リストの管理を行う。ＭＭＥ２０４ａは、ＵＥが登録されている（registered）追跡領域（トラッキングエリア：Tracking Area）に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。ＭＭＥ２０４ａに接続されるｅＮＢ２０７のＣＳＧの管理、ＣＳＧ ＩＤの管理、およびホワイトリストの管理は、アイドルステートモビリティ管理部５０５－３で行われてもよい。
図１１は、５ＧＣの構成を示すブロック図である。図１１では、前述の図３に示す５ＧＣ部２１４の構成を示す。図１１は、図５にて示す５ＧＣ部２１４に、ＡＭＦの構成、ＳＭＦの構成およびＵＰＦの構成が含まれた場合について示している。Ｄａｔａ Ｎｅｔｗｏｒｋ通信部５２１は、５ＧＣ部２１４とＤａｔａ Ｎｅｔｗｏｒｋとの間のデータの送受信を行う。基地局通信部５２２は、５ＧＣ部２１４と基地局２０３との間のＳ１インタフェース、および／あるいは、５ＧＣ部２１４と基地局２１３との間のＮＧインタフェースによるデータの送受信を行う。Ｄａｔａ Ｎｅｔｗｏｒｋから受信したデータがユーザデータであった場合、ユーザデータは、Ｄａｔａ Ｎｅｔｗｏｒｋ通信部５２１から、ユーザプレイン通信部５２３経由で基地局通信部５２２に渡され、１つあるいは複数の、基地局２０３および／あるいは基地局２１３へ送信される。基地局２０３および／あるいは基地局２１３から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部５２２から、ユーザプレイン通信部５２３経由でＤａｔａ Ｎｅｔｗｏｒｋ通信部５２１に渡され、Ｄａｔａ Ｎｅｔｗｏｒｋへ送信される。
Ｄａｔａ Ｎｅｔｗｏｒｋから受信したデータが制御データであった場合、制御データは、Ｄａｔａ Ｎｅｔｗｏｒｋ通信部５２１からユーザプレイン通信部５２３経由でセッション管理部５２７へ渡される。セッション管理部５２７は、制御データを制御プレイン制御部５２５へ渡す。基地局２０３および／あるいは基地局２１３から受信したデータが制御データであった場合、制御データは、基地局通信部５２２から制御プレイン制御部５２５に渡す。制御プレイン制御部５２５は、制御データをセッション管理部５２７へ渡す。
制御プレイン制御部５２５は、ＮＡＳセキュリティ部５２５－１、ＰＤＵセッションコントロール部５２５－２、アイドルステート（Idle State）モビリティ管理部５２５－３などを含み、制御プレイン（以下、Ｃ－Ｐｌａｎｅと称する場合もある）に対する処理全般を行う。ＮＡＳセキュリティ部５２５－１は、ＮＡＳ（Non-Access Stratum）メッセージのセキュリティなどを行う。ＰＤＵセッションコントロール部５２５－２は、移動端末２０２と５ＧＣ部２１４との間のＰＤＵセッションの管理などを行う。アイドルステートモビリティ管理部５２５－３は、待受け状態（アイドルステート（Idle State）；ＲＲＣ＿ＩＤＬＥ状態、または、単にアイドルとも称される）のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の１つあるいは複数の移動端末２０２のトラッキングエリアの追加、削除、更新、検索、トラッキングエリアリスト管理などを行う。
５ＧＣ部２１４は、１つまたは複数の基地局２０３および／あるいは基地局２１３に対して、ページング信号の分配を行う。また、５ＧＣ部２１４は、待受け状態（Idle State）のモビリティ制御（Mobility Control）を行う。５ＧＣ部２１４は、移動端末が待ち受け状態のとき、インアクティブ状態（Inactive State）および、アクティブ状態（Active State）のときに、トラッキングエリア（Tracking Area）リストの管理を行う。５ＧＣ部２１４は、ＵＥが登録されている（registered）追跡領域（トラッキングエリア：Tracking Area）に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。
次に通信システムにおけるセルサーチ方法の一例を示す。図１２は、ＬＴＥ方式の通信システムにおいて通信端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。通信端末は、セルサーチを開始すると、ステップＳＴ６０１で、周辺の基地局から送信される第一同期信号（Ｐ－ＳＳ）、および第二同期信号（Ｓ－ＳＳ）を用いて、スロットタイミング、フレームタイミングの同期をとる。
Ｐ－ＳＳとＳ－ＳＳとを合わせて、同期信号（Synchronization Signal：ＳＳ）という。同期信号（ＳＳ）には、セル毎に割り当てられたＰＣＩに１対１に対応するシンクロナイゼーションコードが割り当てられている。ＰＣＩの数は５０４通りが検討されている。この５０４通りのＰＣＩを用いて同期をとるとともに、同期がとれたセルのＰＣＩを検出（特定）する。
次に同期がとれたセルに対して、ステップＳＴ６０２で、基地局からセル毎に送信される参照信号（リファレンスシグナル：ＲＳ）であるセル固有参照信号（Cell-specific Reference Signal：ＣＲＳ）を検出し、ＲＳの受信電力（Reference Signal Received Power：ＲＳＲＰ）の測定を行う。参照信号（ＲＳ）には、ＰＣＩと１対１に対応したコードが用いられている。そのコードで相関をとることによって他セルと分離できる。ステップＳＴ６０１で特定したＰＣＩから、該セルのＲＳ用のコードを導出することによって、ＲＳを検出し、ＲＳの受信電力を測定することが可能となる。
次にステップＳＴ６０３で、ステップＳＴ６０２までで検出された一つ以上のセルの中から、ＲＳの受信品質が最もよいセル、例えば、ＲＳの受信電力が最も高いセル、つまりベストセルを選択する。
次にステップＳＴ６０４で、ベストセルのＰＢＣＨを受信して、報知情報であるＢＣＣＨを得る。ＰＢＣＨ上のＢＣＣＨには、セル構成情報が含まれるＭＩＢ（Master Information Block）がマッピングされる。したがって、ＰＢＣＨを受信してＢＣＣＨを得ることで、ＭＩＢが得られる。ＭＩＢの情報としては、例えば、ＤＬ（ダウンリンク）システム帯域幅（送信帯域幅設定（transmission bandwidth configuration：dl-bandwidth）とも呼ばれる）、送信アンテナ数、ＳＦＮ（System Frame Number）などがある。
次にステップＳＴ６０５で、ＭＩＢのセル構成情報をもとに該セルのＤＬ－ＳＣＨを受信して、報知情報ＢＣＣＨの中のＳＩＢ（System Information Block）１を得る。ＳＩＢ１には、該セルへのアクセスに関する情報、セルセレクションに関する情報、他のＳＩＢ（ＳＩＢｋ；ｋ≧２の整数）のスケジューリング情報が含まれる。また、ＳＩＢ１には、トラッキングエリアコード（Tracking Area Code：ＴＡＣ）が含まれる。
次にステップＳＴ６０６で、通信端末は、ステップＳＴ６０５で受信したＳＩＢ１のＴＡＣと、通信端末が既に保有しているトラッキングエリアリスト内のトラッキングエリア識別子（Tracking Area Identity：ＴＡＩ）のＴＡＣ部分とを比較する。トラッキングエリアリストは、ＴＡＩリスト（TAI list）とも称される。ＴＡＩはトラッキングエリアを識別するための識別情報であり、ＭＣＣ（Mobile Country Code）と、ＭＮＣ（Mobile Network Code）と、ＴＡＣ（Tracking Area Code）とによって構成される。ＭＣＣは国コードである。ＭＮＣはネットワークコードである。ＴＡＣはトラッキングエリアのコード番号である。
通信端末は、ステップＳＴ６０６で比較した結果、ステップＳＴ６０５で受信したＴＡＣがトラッキングエリアリスト内に含まれるＴＡＣと同じならば、該セルで待ち受け動作に入る。比較して、ステップＳＴ６０５で受信したＴＡＣがトラッキングエリアリスト内に含まれなければ、通信端末は、該セルを通して、ＭＭＥなどが含まれるコアネットワーク（Core Network，ＥＰＣ）へ、ＴＡＵ（Tracking Area Update）を行うためにトラッキングエリアの変更を要求する。
図１２に示す例においては、ＬＴＥ方式におけるセルサーチから待ち受けまでの動作の例について示したが、ＮＲ方式においては、ステップＳＴ６０３において、ベストセルに加えてベストビームを選択してもよい。また、ＮＲ方式においては、ステップＳＴ６０４において、ビームの情報、例えば、ビームの識別子を取得してもよい。また、ＮＲ方式においては、ステップＳＴ６０４において、リメイニングミニマムＳＩ（Remaining Minimum SI：ＲＭＳＩ）のスケジューリング情報を取得してもよい。ＮＲ方式においては、ステップＳＴ６０５において、ＲＭＳＩを受信するとしてもよい。
コアネットワークを構成する装置（以下「コアネットワーク側装置」という場合がある）は、ＴＡＵ要求信号とともに通信端末から送られてくる該通信端末の識別番号（ＵＥ－ＩＤなど）をもとに、トラッキングエリアリストの更新を行う。コアネットワーク側装置は、通信端末に更新後のトラッキングエリアリストを送信する。通信端末は、受信したトラッキングエリアリストに基づいて、通信端末が保有するＴＡＣリストを書き換える（更新する）。その後、通信端末は、該セルで待ち受け動作に入る。
スマートフォンおよびタブレット型端末装置の普及によって、セルラー系無線通信によるトラフィックが爆発的に増大しており、世界中で無線リソースの不足が懸念されている。これに対応して周波数利用効率を高めるために、小セル化し、空間分離を進めることが検討されている。
従来のセルの構成では、ｅＮＢによって構成されるセルは、比較的広い範囲のカバレッジを有する。従来は、複数のｅＮＢによって構成される複数のセルの比較的広い範囲のカバレッジによって、あるエリアを覆うように、セルが構成されている。
小セル化された場合、ｅＮＢによって構成されるセルは、従来のｅＮＢによって構成されるセルのカバレッジに比べて範囲が狭いカバレッジを有する。したがって、従来と同様に、あるエリアを覆うためには、従来のｅＮＢに比べて、多数の小セル化されたｅＮＢが必要となる。
以下の説明では、従来のｅＮＢによって構成されるセルのように、カバレッジが比較的大きいセルを「マクロセル」といい、マクロセルを構成するｅＮＢを「マクロｅＮＢ」という。また、小セル化されたセルのように、カバレッジが比較的小さいセルを「スモールセル」といい、スモールセルを構成するｅＮＢを「スモールｅＮＢ」という。
マクロｅＮＢは、例えば、非特許文献７に記載される「ワイドエリア基地局（Wide Area Base Station）」であってもよい。
スモールｅＮＢは、例えば、ローパワーノード、ローカルエリアノード、ホットスポットなどであってもよい。また、スモールｅＮＢは、ピコセルを構成するピコｅＮＢ、フェムトセルを構成するフェムトｅＮＢ、ＨｅＮＢ、ＲＲＨ（Remote Radio Head）、ＲＲＵ（Remote Radio Unit）、ＲＲＥ（Remote Radio Equipment）またはＲＮ（Relay Node）であってもよい。また、スモールｅＮＢは、非特許文献７に記載される「ローカルエリア基地局（Local Area Base Station）」または「ホーム基地局（Home Base Station）」であってもよい。
図１３は、ＮＲにおけるセルの構成の一例を示す。ＮＲのセルでは、狭いビームを形成し、方向を変えて送信する。図１３に示す例において、基地局７５０は、ある時間において、ビーム７５１－１を用いて移動端末との送受信を行う。他の時間において、基地局７５０は、ビーム７５１－２を用いて移動端末との送受信を行う。以下同様にして、基地局７５０はビーム７５１－３～７５１－８のうち１つあるいは複数を用いて移動端末との送受信を行う。このようにすることで、基地局７５０は広範囲のセルを構成する。
図１３において、基地局７５０が用いるビームの数を８とする例について示したが、ビームの数は８とは異なっていてもよい。また、図１３に示す例において、基地局７５０が同時に用いるビームの数を１つとしたが、複数であってもよい。
低遅延と高信頼性の通信（Ultra-reliable and Low Latency Communications；ＵＲＬＬＣ）の要件を満たす方法の例として、パケット複製が用いられてもよい。送信側装置は、ＰＤＣＰレイヤにおいてＰＤＣＰ ＰＤＵを複製し、受信側装置に送信してもよい。該パケット複製は、例えば、ＤＣを用いたパケット複製であってもよいし、ＣＡを用いたパケット複製であってもよい。前述において、送信側装置は基地局であってもよいし、ＵＥであってもよい。また、受信側装置は、ＵＥであってもよいし、基地局であってもよい。
しかし、パケット複製において、受信したパケットを上位レイヤに転送するタイミングについては規定されていない。このことにより、送信側装置から受信側装置に対するデータ送信において、レイテンシのばらつき（以下、ジッタと称する場合がある）が生じる。例えば、複製されたパケットの受信タイミングが両パケット間で異なる場合において、受信タイミングが先となるパケットの復号結果（例：ＣＲＣ結果）によって、受信側装置がパケットを上位レイヤに転送するタイミングが異なる。このことにより、データ送信においてレイテンシのばらつきが生じ、その結果、ジッタ特性が悪化するといった問題が生じる。
前述の問題に対する解決策を以下に開示する。
基地局はＵＥに対し、複数のキャリアについて同じ時間リソースへのスケジューリングを行う。複数の該キャリアは、例えば、ＣＡを用いたパケット複製において用いられるキャリアであってもよい。パケット複製に用いられるキャリアについて、同じ時間リソースに対してスケジューリングが行われるとしてもよい。例えば、キャリア間スケジューリングが用いられてもよい。
複数の該キャリアに対する同じ時間リソースへのスケジューリングの要否が、規格で予め決められてもよい。例えば、同じ時間リソースへのスケジューリングの要否が、ＱｏＳパラメータを用いて決められてもよい。ネットワークスライシングに関する情報（例：ＮＳＳＡＩ（Network Slice Selection Assistance Information））が用いられてもよい。該スケジューリングの要否は、ＰＤＵセッション毎に決められてもよいし、ＱｏＳフロー毎に決められてもよいし、ベアラ毎に決められてもよい。
ＱｏＳパラメータには、例えば、ユーザデータの送信周期（以下、Ｃｙｃｌｅ Ｔｉｍｅと称する場合がある）に関する情報が含まれてもよいし、ジッタの許容範囲に関する情報が含まれてもよい。ジッタの許容範囲に関する情報は、例えば、Ｃｙｃｌｅ Ｔｉｍｅに対する割合として与えられてもよいし、特定の時間単位（例：ミリ秒単位、マイクロ秒単位）で与えてもよい。
ＱｏＳパラメータには、ユーザデータの送信タイミングにおける、送信周期に対するオフセットに関する情報が含まれるとしてもよい。該オフセットに関する情報は、例えば、特定の時刻に関する情報として与えられてもよいし、スロット番号を用いた情報として与えられてもよい。該オフセットに関する情報について、サブフレーム番号が用いられてもよいし、シンボル番号が用いられてもよい。
ＱｏＳパラメータには、ジッタの許容範囲に関する情報のみが含まれるとしてもよい。前述において、ジッタの許容範囲に関する情報は、例えば、特定の時間単位（例：ミリ秒単位、マイクロ秒単位）で与えられてもよい。このことにより、例えば、ジッタ特性が要求される通信において、周期的なデータ送信が行われない場合においても、ジッタ特性を向上可能となる。
他の例として、複数の該キャリアに対する同じ時間リソースへのスケジューリングの要否を、上位ＮＷ装置が決めてもよい。上位ＮＷ装置は、例えば、ＡＭＦであってもよいし、ＳＭＦであってもよい。上位ＮＷ装置は、該スケジューリングの要否を、ＱｏＳパラメータを用いて決めてもよいし、ネットワークスライシングに関する情報を用いて決めてもよい。上位ＮＷ装置は、該スケジューリングの要否を、ＰＤＵセッション毎に決めてもよいし、ＱｏＳフロー毎に決めてもよいし、ベアラ毎に決めてもよい。上位ＮＷ装置は基地局に対し、複数キャリアに対する同じ時間リソースへのスケジューリング要否に関する情報を通知してもよい。該通知には、上位ＮＷ装置と基地局との間のインタフェースが用いられてもよい。このことにより、例えば、ジッタ特性を向上可能としつつ、基地局における処理時間を削減可能となる。
他の例として、複数の該キャリアに対する同じ時間リソースへのスケジューリングの要否を、基地局が決めてもよい。基地局は、該スケジューリングの要否を、ＱｏＳパラメータを用いて決めてもよいし、ネットワークスライシングに関する情報を用いて決めてもよい。基地局は、該スケジューリングの要否を、ＰＤＵセッション毎に決めてもよいし、ＱｏＳフロー毎に決めてもよいし、ベアラ毎に決めてもよい。
他の解決策を開示する。受信側装置は、パケット複製において後から受信したパケットの受信タイミングにおいて、受信したパケットを上位レイヤに転送する。該受信側装置は、基地局であってもよいし、ＵＥであってもよい。すなわち、前述の方法が、上り通信において適用されてもよいし、下り通信において適用されてもよい。
受信側装置は、先に受信したパケットを保持してもよい。受信側装置は、先に受信したパケットを、例えば、後から来るパケットを受信するまでの間、保持してもよい。このことにより、例えば、ＵＥは、先に受信したパケットの復号結果によらず、後から送信されたパケットの受信タイミングにおいて、受信パケットを上位レイヤに転送可能となる。その結果、ジッタを削減可能となる。
受信側装置における該パケットの保持は、パケット複製が設定されているベアラに対して適用するとしてもよい。このことにより、例えば、該パケットのジッタ特性を向上しつつ、他のデータの遅延増加を防止可能となる。他の例として、受信側装置における該パケットの保持は、パケット複製がアクティブとなっているベアラに対して適用するとしてもよい。このことにより、例えば、パケット複製が設定されているがデアクティベート（deactivate）されたベアラにおいて、受信側装置は受信データを迅速に上位レイヤに転送可能となる。
受信側装置における該パケットの保持は、例えば、ＰＤＣＰレイヤにて行われてもよい。受信側装置のＰＤＣＰレイヤは、送信側装置のＰＤＣＰレイヤにおいて複製されたパケットの両方を受信したことを用いて、該パケットのうち片方を上位レイヤに転送してもよい。前述における片方の該パケットは、先に受信したパケットであってもよいし、後に受信したパケットであってもよい。受信側装置は、上位レイヤに転送しなかった他方のパケットを破棄してもよい。
他の例として、受信側装置における該パケットの保持が、ＲＬＣレイヤにおいて行われてもよい。例えば、パケット複製に用いられる論理チャネルのデータが保持されるとしてもよい。
他の例として、受信側装置における該パケットの保持が、ＭＡＣレイヤにおいて行われてもよい。例えば、該パケットの送受信に用いられるトランスポートブロックのデータが保持されるとしてもよい。トランスポートブロックのデータの保持は、例えば、該トランスポートブロックに、該パケットの送受信に用いられる論理チャネルとは異なる論理チャネルがマッピングされていない場合において行われるとしてもよい。このことにより、例えば、受信側装置における処理が容易となる。
ＭＡＣレイヤにおいて該パケットの保持を行う他の例として、該パケットの送受信に用いられる論理チャネルのデータが保持されるとしてもよい。受信側装置において受信したトランスポートブロックに多重された論理チャネルデータが保持されてもよい。受信側装置は、該トランスポートブロックに多重された論理チャネルデータのうち、前述の論理チャネルとは異なる論理チャネルのデータを、保持せずに、上位レイヤに転送してもよい。このことにより、例えば、該パケットの送受信に用いられる論理チャネルとは異なる論理チャネルにおけるレイテンシの増加を防止可能となる。
他の例として、受信側装置における該パケットの保持が、ＳＤＡＰ（Service Data Adaptation Protocol）レイヤにて行われてもよいし、上位レイヤ、例えば、アプリケーションレイヤにて行われてもよい。例えば、受信側装置は、後から受信したパケットに関する情報を、ＳＤＡＰレイヤに通知してもよいし、上位レイヤに通知してもよい。
受信側装置における該パケットの保持に関する他の例として、受信側装置は、該パケットを識別する情報のみを保持するとしてもよい。例えば、受信側装置は、該パケットのＰＤＣＰシーケンス番号のみを保持するとしてもよい。受信側装置は、後から受信するパケットの該情報を、保持している該情報と照合してもよい。受信側装置は、後から受信するパケットを上位レイヤに転送するとしてもよい。該転送は、例えば、後から受信するパケットを識別する情報が、受信側装置が保持している該情報に一致することをもって行われるとしてもよい。このことにより、例えば、受信側装置における該パケットの保持に用いられるメモリ量を削減可能となる。
受信側装置が、後から受信したパケットの受信タイミングにおいて上位レイヤへの転送を行うかどうかについて、基地局がＵＥに対して設定してもよい。該設定には、例えば、ＲＲＣシグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよい。前述の設定に関する他の例として、上位ＮＷ装置が基地局経由でＵＥに対して設定してもよい。上位ＮＷ装置は、例えば、ＡＭＦであってもよいし、ＳＭＦであってもよい。該設定には、例えば、ＮＡＳシグナリングが用いられてもよい。
該設定には、受信側装置が後から受信したパケットの受信タイミングにおいて上位レイヤへの転送を行うかどうかについての情報が含まれてもよいし、該パケットの送受信に用いられるベアラに関する情報が含まれてもよいし、該パケットの送受信に用いられる論理チャネルに関する情報が含まれてもよいし、該パケットが送受信されるＱｏＳフローに関する情報が含まれてもよい。
基地局は、ＱｏＳパラメータを用いて前述の設定を行ってもよいし、ネットワークスライシングに関する情報を用いて該設定を行ってもよい。例えば、ＱｏＳパラメータに含まれるジッタ耐性が小さい場合において、受信側装置が後から受信したパケットの受信タイミングにおいて上位レイヤへの転送を行うとしてもよい。他の例として、上位ＮＷ装置は、ＱｏＳパラメータを用いて前述の設定を行ってもよいし、ネットワークスライシングに関する情報を用いて該設定を行ってもよい。ＱｏＳパラメータは、複数のキャリアについて同じ時間リソースへのスケジューリングを行う解決策において開示したＱｏＳパラメータと同様としてもよい。
ＵＥは、該設定を用いて、受信パケットを上位レイヤに転送するタイミングを切替えてもよい。例えば、ＵＥは、下りパケットを上位レイヤに転送するタイミングを、先に受信したパケットの受信タイミングから、後に受信したパケットの受信タイミングに切替えてもよい。逆の切替えが行われてもよい。このことにより、例えば、通信システムにおいて、ジッタ特性が求められる通信とジッタ特性が求められない通信とを柔軟に切替え可能となる。
受信側装置は、該設定によらず、受信パケットを上位レイヤに転送してもよい。前述の転送は、例えば、パケット複製のデアクティベーション（deactivation）の指示が含まれるＭＡＣシグナリングを受信した場合において行われてもよい。受信側装置（例えば、ＵＥ）は、基地局から該ＭＡＣシグナリングを受信した場合において、自ＵＥにて保持している受信パケットを上位レイヤに転送してもよい。該受信パケットは、例えば、パケット複製において先に受信したパケットであってもよい。このことにより、例えば、パケット複製停止後におけるメモリ蓄積量を削減可能となる。
図１４は、本実施の形態１において、受信側装置が、複製されたパケットのうち後から送信されるパケットの受信タイミングにおいて、パケットを上位レイヤに転送する動作を示す図である。図１４は、複製されたパケットがそれぞれ論理チャネル（Logical CHannel；ＬＣＨ）＃１および＃２にマッピングされた場合について示している。また、図１４は、パケット複製にＣＡを用いた場合について示している。また、図１４において、送信側装置からデータが送信される周期をＣｙｃｌｅ Ｔｉｍｅとして示している。
図１４において、受信側装置はＬＣＨ＃１からのパケット１４０１およびＬＣＨ＃２からのパケット１４０２を受信する。パケット１４０１および１４０２は、パケット複製によって複製された互いに同一のパケットである。図１４において、受信側装置はパケット１４０１を先に受信する。受信側装置は、パケット１４０１を、ＬＣＨ＃２からのパケット１４０２を受信するまで保持する（図１４において破線矢印を参照）。受信側装置は、パケット１４０２を受信したタイミングにおいて、パケット１４０１を上位レイヤに転送する（図１４において太矢印を参照）。受信側装置は、後から受信したパケット１４０２を破棄する。
図１４において、パケット１４０１、１４０２の受信からＣｙｃｌｅ Ｔｉｍｅ分の時間経過後、受信側装置はＬＣＨ＃１からのパケット１４０３およびＬＣＨ＃２からのパケット１４０４を受信する。パケット１４０３および１４０４は、パケット複製によって複製された互いに同一のパケットである。受信側装置における動作は、前述のパケット１４０１、１４０２の受信時における動作と同様である。
図１４において、パケット１４０３、１４０４の受信からＣｙｃｌｅ Ｔｉｍｅ分の時間経過後、受信側装置はＬＣＨ＃１からのパケット１４０５およびＬＣＨ＃２からのパケット１４０６を受信する。パケット１４０５および１４０６は、パケット複製によって複製された互いに同一のパケットである。受信側装置における動作は、前述のパケット１４０１、１４０２の受信時における動作と同様である。
図１４において、パケット１４０５、１４０６の受信からＣｙｃｌｅ Ｔｉｍｅ分の時間経過後、受信側装置はＬＣＨ＃１からのパケット１４０７およびＬＣＨ＃２からのパケット１４０８を受信する。パケット１４０７および１４０８は、パケット複製によって複製された互いに同一のパケットである。図１４に示す例において、受信側装置はパケット１４０８を先に受信する。受信側装置は、パケット１４０８を、ＬＣＨ＃１からのパケット１４０７を受信するまで保持する。受信側装置は、パケット１４０７を受信したタイミングにおいて、パケット１４０８を上位レイヤに転送する。受信側装置は、後から受信したパケット１４０７を破棄する。
図１４において、パケット複製にＣＡを用いた例を示したが、パケット複製にＤＣが用いられてもよい。ＤＣを用いたパケット複製の場合、図１４におけるＬＣＨ＃１、＃２が、それぞれマスタ基地局、セカンダリ基地局において用いられてもよい。ＬＣＨ＃１、＃２が、それぞれセカンダリ基地局、マスタ基地局において用いられてもよい。このことにより、例えば、ＵＥと片方の基地局との間の通信経路が遮断（例えば、ブロッキングにより）された場合においても、ＵＥと他方の基地局との間で通信を維持可能となる。その結果、通信の信頼性を向上可能となる。
図１４において、受信側装置が、先に受信したパケットを保持する動作について示した。しかし、受信側装置は、先に受信したパケットの識別子のみを保持してもよい。該識別子は、例えば、ＰＤＣＰシーケンス番号であってもよい。例えば、受信側装置は、先に受信したパケット１４０１のＰＤＣＰシーケンス番号を保持してもよい。受信側装置は、パケット１４０１のＰＤＣＰシーケンス番号以外の情報を破棄してもよい。受信側装置は、後から受信したパケット１４０２のＰＤＣＰシーケンス番号を、保持しているＰＤＣＰシーケンス番号と照合してもよい。例えば、ＰＤＣＰシーケンス番号が、保持しているＰＤＣＰシーケンス番号と一致する場合において、受信側装置はパケット１４０２を上位レイヤに転送してもよい。パケット１４０３、１４０４についても、パケット１４０１、１４０２と同様としてもよい。パケット１４０５、１４０６についても、パケット１４０１、１４０２と同様としてもよい。パケット１４０８、１４０７についても、パケット１４０１、１４０２と同様としてもよい。前述において、受信側装置におけるパケット１４０１に関する動作をパケット１４０８に適用してもよいし、パケット１４０２に関する動作をパケット１４０７に適用してもよい。このことにより、例えば、受信側装置におけるメモリ使用量を削減可能となる。
受信側装置における前述の動作の適用にあたり、以下に示す問題が生じる。すなわち、受信側装置が、受信タイミングが後となるパケットを受信できない場合、例えば、該パケットの受信にあたり復号エラーが生じる場合、受信側装置は、該パケットの再送（例えば、ＨＡＲＱ再送）を待たないと、受信パケットを上位レイヤに転送することができない。このことにより、レイテンシが増大するとともに、ジッタ特性が悪化するといった問題が生じる。
前述の問題点を解決する方法を開示する。
受信側装置は、所定のタイミングにおいて受信パケットを上位レイヤに転送する。受信側装置は、先に受信したパケットを該タイミングまで保持してもよい。受信側装置は、後に受信したパケットを該タイミングまで保持してもよいし、破棄してもよい。受信側装置は、例えば、所定のタイミングが経過した場合において、先に受信したパケットを上位レイヤに転送してもよい。受信側装置において、所定のタイミング経過後の上位レイヤへの転送は、パケット受信後即時行われるとしてもよい。
受信側装置における該パケットの保持は、パケット複製が設定されているベアラに対して適用するとしてもよい。このことにより、例えば、該パケットのジッタ特性を向上しつつ、他のデータの遅延増加を防止可能となる。他の例として、受信側装置における該パケットの保持は、パケット複製がアクティブとなっているベアラに対して適用するとしてもよい。このことにより、例えば、パケット複製が設定されているがデアクティベート（deactivate）されたベアラにおいて、受信側装置は受信データを迅速に上位レイヤに転送可能となる。
受信側装置における該パケットの保持は、ＰＤＣＰレイヤにて行われてもよいし、ＲＬＣレイヤにおいて行われてもよい。例えば、パケット複製に用いられる論理チャネルのデータが保持されるとしてもよい。
他の例として、受信側装置における該パケットの保持が、ＭＡＣレイヤにおいて行われてもよい。例えば、該パケットの送受信に用いられるトランスポートブロックのデータが保持されるとしてもよい。トランスポートブロックのデータの保持は、例えば、該トランスポートブロックに、該パケットの送受信に用いられる論理チャネルとは異なる論理チャネルがマッピングされていない場合において行われるとしてもよい。このことにより、例えば、受信側装置における処理が容易となる。
ＭＡＣレイヤにおいて該パケットの保持を行う他の例として、該パケットの送受信に用いられる論理チャネルのデータが保持されるとしてもよい。受信側装置において受信したトランスポートブロックに多重された論理チャネルデータが保持されてもよい。受信側装置は、該トランスポートブロックに多重された論理チャネルデータのうち、前述の論理チャネルとは異なる論理チャネルのデータを、保持せずに、上位レイヤに転送してもよい。このことにより、例えば、該パケットの送受信に用いられる論理チャネルとは異なる論理チャネルにおけるレイテンシの増加を防止可能となる。
他の例として、受信側装置における該パケットの保持が、ＳＤＡＰ（Servide Data Adaptation Protocol）レイヤにて行われてもよいし、上位レイヤ、例えば、アプリケーションレイヤにて行われてもよい。例えば、受信側装置は、後から受信したパケットに関する情報を、ＳＤＡＰレイヤに通知してもよいし、上位レイヤに通知してもよい。
受信側装置は、所定のタイミングおよび後に受信したパケットの受信タイミングのうち、先に到来するタイミングにおいて該パケットを上位レイヤに転送してもよい。このことにより、例えば、受信側装置におけるメモリ消費量を削減可能となる。前述において、該上位レイヤは、所定のタイミングまで該パケットを保持するとしてもよい。該保持は、例えば、後に受信したパケットの受信タイミングが所定のタイミングよりも先に到来する場合において行われるとしてもよい。このことにより、例えば、該パケットの送受信におけるジッタ特性を向上可能となる。
該タイミングを、基地局が決定してもよい。基地局は、該タイミングに関する情報をＵＥに通知してもよい。基地局からＵＥに対する該タイミングの通知において、ＲＲＣシグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよい。ＵＥは、該情報を用いて、受信パケットを上位レイヤに転送してもよい。ＵＥにおける動作の他の例として、ＵＥは、該情報を用いて、基地局に対して、複製したパケットを送信してもよい。例えば、ＵＥは、基地局における受信パケットの上位レイヤへの転送が該タイミングに間に合うように、複製したパケットを基地局に対して送信してもよい。
他の例として、該タイミングを、上位ＮＷ装置が決定してもよい。上位ＮＷ装置は、ＡＭＦであってもよいし、ＳＭＦであってもよい。上位ＮＷ装置は、該タイミングに関する情報を、基地局経由でＵＥに通知してもよい。該通知には、例えば、ＮＡＳシグナリングが用いられてもよい。
他の例として、該タイミングを、ＵＥが判断してもよい。ＵＥは、該タイミングに関する情報を、基地局に通知してもよい。基地局は、ＵＥが判断した該タイミングを承認してもよいし、否認してもよい。他の例として、基地局は、ＵＥが判断した該タイミングを上位ＮＷ装置に通知してもよい。上位ＮＷ装置は、ＵＥが判断した該タイミングを承認してもよいし、否認してもよい。ＵＥから基地局および／あるいは上位ＮＷ装置への該情報の通知において、ＮＡＳシグナリングが用いられてもよいし、ＲＲＣシグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよい。このことにより、例えば、上りデータ送信時において、送信元となるＵＥが該タイミングを判断可能となる。その結果、通信システムにおける効率化が可能となる。
所定のタイミングに関する情報は、例えば、スロット番号で与えられてもよい。受信側装置は、与えられた番号に対応するスロットにおいて受信パケットを上位レイヤに転送してもよい。他の例として、該情報は、ノンスロット（ミニスロットと称する場合もある）を識別する情報、例えば、ノンスロットの番号を用いて与えられてもよい。受信側装置は、与えられた番号に対応するノンスロットにおいて、受信パケットを上位レイヤに転送してもよい。該情報が、シンボル単位で与えられてもよい。受信側装置は、与えられた番号に対応するシンボルにおいて受信パケットを上位レイヤに転送してもよい。このことにより、例えば、データの送受信が１スロットより短い単位でスケジューリングされている場合においても、ジッタ特性を向上可能となる。所定のタイミングに関する情報は、前述の番号の組み合わせで与えられてもよい。例えば、該情報が、スロット番号とシンボル番号の組み合わせにより与えられてもよい。このことにより、例えば、ジッタ耐性が要求される通信が１スロット周期で行われない場合においても、ジッタ特性を向上可能となる。
所定のタイミングに関する情報に、周期に関する情報が含まれてもよい。該情報は、例えば、非特許文献２３（３ＧＰＰ ＴＲ２２．８０４ Ｖ１６．１．０）に示すサイクルタイム（Cycle Time）であってもよい。該情報は、絶対時間、例えば、ミリ秒単位で与えられてもよいし、サブフレーム単位で与えられてもよいし、スロット単位で与えられてもよいし、シンボル単位で与えられてもよいし、ノンスロット単位で与えられてもよい。受信側装置は、該情報を用いて、受信パケットを上位レイヤに転送するタイミングを導出してもよい。受信側装置は、導出した該タイミングにおいて、受信パケットを上位レイヤに転送してもよい。このことにより、例えば、上位ＮＷ装置あるいは基地局がＵＥに対して、受信パケットを上位レイヤに転送するタイミングをパケット毎に通知することが不要となる。その結果、上位ＮＷ装置あるいは基地局と、ＵＥとの間のシグナリング量を削減可能となる。
所定のタイミングに関する情報に、周期に関する情報とオフセットに関する情報の両方が含まれてもよい。オフセットに関する情報は、例えば、サブフレーム単位で与えられてもよいし、スロット単位で与えられてもよいし、シンボル単位で与えられてもよいし、ノンスロット単位で与えられてもよい。受信側装置は、該情報を用いて、受信パケットを上位レイヤに転送するタイミングを導出してもよい。受信側装置は、導出した該タイミングにおいて、受信パケットを上位レイヤに転送してもよい。このことにより、例えば、前述の効果に加え、受信側装置における該タイミングの導出処理における複雑性を回避可能となる。
受信側装置が所定のタイミングにおいて上位レイヤへの転送を行うかどうかについて、基地局がＵＥに対して設定してもよい。該設定には、例えば、ＲＲＣシグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよい。前述の設定に関する他の例として、上位ＮＷ装置が基地局経由でＵＥに対して設定してもよい。上位ＮＷ装置は、例えば、ＡＭＦであってもよいし、ＳＭＦであってもよい。該設定には、例えば、ＮＡＳシグナリングが用いられてもよい。
所定のタイミングに関する情報が、ＱｏＳパラメータに含まれてもよい。例えば、所定のタイミングに関する情報と、ＱｏＳパラメータの識別子との間の対応付けが行われるとしてもよい。ＱｏＳパラメータは、複数のキャリアについて同じ時間リソースへのスケジューリングを行う解決策において開示したＱｏＳパラメータと同様としてもよい。
ＱｏＳパラメータを用いた前述の設定を、基地局がＵＥに対して行ってもよいし、上位ＮＷ装置が基地局経由でＵＥに対して行ってもよい。他の例として、上位ＮＷ装置が基地局に対し、ＱｏＳパラメータを通知してもよい。基地局は、該ＱｏＳパラメータを用いて、所定のタイミングに関する情報を抽出してもよい。基地局はＵＥに対し、所定のタイミングに関する該情報を通知してもよい。
ＵＥは、該設定を用いて、受信パケットを上位レイヤに転送するタイミングを切替えてもよい。例えば、ＵＥは、下りパケットを上位レイヤに転送するタイミングを、先に受信したパケットの受信タイミングから、所定のタイミングに切替えてもよい。逆の切替えが行われてもよい。他の例として、ＵＥは、下りパケットを上位レイヤに転送するタイミングを、後に受信したパケットの受信タイミングから、所定のタイミングに切替えてもよい。逆の切替えが行われてもよい。他の例として、ＵＥは、下りパケットの上位レイヤへの転送に用いる所定のタイミングを変更してもよい。このことにより、例えば、通信システムにおいて、ジッタ特性が求められる通信とジッタ特性が求められない通信とを柔軟に切替え可能となる。
受信側装置は、ジッタ許容範囲から外れた受信データを破棄してもよい。受信側装置は、例えば、ＱｏＳパラメータを用いて、受信データがジッタ許容範囲内か否かを判断してもよい。このことにより、例えば、通信システムを用いたサービスにおいて、ジッタ許容範囲外のデータによって発生する誤動作を防止可能となる。
基地局は、所定のタイミングを変更してもよい。例えば、送信周期を変更してもよいし、送信周期に対するオフセットを変更してもよい。基地局は、変更後の所定のタイミングを決定し、ＵＥに通知してもよい。他の例として、ＵＥが、変更後の所定のタイミングを判断し、基地局に通知してもよい。基地局は、ＵＥから通知された該タイミングを決定してもよい。このことにより、例えば、通信システムにおけるジッタ特性を確保しつつ、スケジューリングの柔軟性を向上可能となる。
変更後のタイミングは、受信側装置における受信タイミングを用いて決められてもよい。例えば、変更後のタイミングは、受信側装置における受信タイミングの移動平均を用いて決められてもよい。変更後のタイミングの算出は、周期的に行われてもよいし、基地局あるいは上位ＮＷ装置からの指示を用いて行われてもよい。変更後のタイミングの算出を行う周期は、規格で定められていてもよいし、上位ＮＷ装置が基地局および／あるいはＵＥに通知してもよいし、基地局が判断してＵＥに通知してもよい。このことにより、例えば、通信システムにおいて実際に受信されるタイミングを用いて所定のタイミングを決定可能となり、その結果、ジッタ特性を向上可能となる。
所定のタイミングの通知に関する他の例として、送信側装置は、送信データの送信時刻に関する情報を通知してもよいし、受信側装置が受信すべき時刻に関する情報を通知してもよい。受信すべき該時刻は、例えば、受信側装置が上位レイヤにデータを転送すべき時刻であってもよい。該時刻は、例えば、ミリ秒単位の時刻であってもよいし、サブフレーム番号を用いた時刻であってもよいし、スロット番号を用いた時刻であってもよいし、ミニスロット番号を用いた時刻であってもよいし、シンボル番号を用いた時刻であってもよいし、前述のうち複数を組み合わせた時刻であってもよい。送信側装置は、例えば、該送信データにタイムスタンプを付与してもよい。該タイムスタンプは、前述の時刻と同様の情報であってもよい。該タイムスタンプは、上位レイヤにおいて付与されてもよいし、ＳＤＡＰにおいて付与されてもよいし、ＰＤＣＰにおいて付与されてもよいし、ＲＬＣにおいて付与されてもよいし、ＭＡＣにおいて付与されてもよい。他の例として、該送信時刻に関する情報および／あるいは受信すべき該時刻に関する情報が、ＲＲＣシグナリングを用いて通知されてもよいし、ＭＡＣシグナリングを用いて通知されてもよいし、Ｌ１／Ｌ２シグナリングを用いて通知されてもよい。受信側装置は、該送信時刻および／あるいは受信すべき該時刻に関する情報を用いて、所定の該タイミングを導出してもよい。受信側装置は、受信データにおける該タイムスタンプを除去してもよい。所定のタイミングの通知に関する該方法が、例えば、非周期的なデータの送受信に用いられてもよい。このことにより、例えば、非周期的なデータ送受信においても、レイテンシを一定に保持可能となる。すなわち、ジッタを削減可能となる。
受信側装置は、該設定によらず、受信パケットを上位レイヤに転送してもよい。前述の転送は、例えば、パケット複製のデアクティベーション（deactivation）の指示が含まれるＭＡＣシグナリングを受信した場合において行われてもよい。受信側装置（例えば、ＵＥ）は、基地局から該ＭＡＣシグナリングを受信した場合において、自ＵＥにて保持している受信パケットを上位レイヤに転送してもよい。該転送の動作は、例えば、前述のタイミングより前において行われてもよい。このことにより、例えば、パケット複製停止後におけるメモリ蓄積量を削減可能となる。
受信側装置は、パケット複製において、受信結果が正常でない（例えば、復号エラー）パケットの再送を、送信側装置に対して要求しないとしてもよい。該再送は、例えば、ＨＡＲＱ再送であってもよいし、ＲＬＣ再送であってもよい。前述の動作は、複製されたパケットのうち片方の復号結果が正常である場合に行うとよい。このことにより、通信システムにおける効率を向上可能となる。受信側装置のＨＡＲＱエンティティは、受信結果が正常でないパケットの復号結果をＯＫとみなしてもよい。受信側装置のＲＬＣレイヤは、該パケットをＡＣＫとみなしてもよい。例えば、受信側装置のＲＬＣレイヤは、受信ウィンドウを進めてもよい。
図１５は、本実施の形態１において、受信側装置が所定のタイミングにおいて受信パケットを上位レイヤに転送する動作を示す図である。図１５は、複製されたパケットがそれぞれ論理チャネル（Logical CHannel；ＬＣＨ）＃１および＃２にマッピングされた場合について示している。また、図１５は、パケット複製にＣＡを用いた場合について示している。また、図１５において、送信側装置からデータが送信される周期をＣｙｃｌｅ Ｔｉｍｅとして示している。図１５において、図１４と共通する要素には同じ番号を付し、共通する説明を省略する。
図１５において、受信側装置はパケット１４０１を先に受信する。受信側装置は、パケット１４０１受信直後となる所定のタイミング（図１５において破線で示すタイミングを参照）において、パケット１４０１を上位レイヤに転送する。受信側装置は、パケット１４０２を受信する。受信側装置は、後から受信したパケット１４０２を破棄する。
図１５において、パケット１４０１、１４０２の受信からＣｙｃｌｅ Ｔｉｍｅ分の時間経過後、受信側装置はパケット１４０３、１４０４を受信する。受信側装置は、パケット１４０３を先に受信する。受信側装置は、パケット１４０３を保持し、後から送信されるパケット１４０４の受信を試みる。図１５に示す例においては、受信側装置によるパケット１４０４の受信結果が復号エラーとなった場合について示している。受信側装置は、所定のタイミングにおいて、パケット１４０３を上位レイヤに転送する。その後、受信側装置は、ＨＡＲＱ再送がされたパケット１４０４を受信する。受信側装置は、後から受信されたパケット１４０４を破棄する。
図１５において、パケット１４０３、１４０４の受信からＣｙｃｌｅ Ｔｉｍｅ分の時間経過後、受信側装置はパケット１４０５、１４０６を受信する。受信側装置は、パケット１４０５を先に受信し、保持する。受信側装置は、後からパケット１４０６を受信する。受信側装置は、後から受信されたパケット１４０６を破棄する。図１５に示す例においては、パケット１４０５、１４０６の受信タイミングの後に所定タイミングが存在する場合について示している。受信側装置は、所定のタイミングにおいてパケット１４０５を上位レイヤに転送する。
図１５において、パケット１４０５、１４０６の受信からＣｙｃｌｅ Ｔｉｍｅ分の時間経過後、受信側装置はＬＣＨ＃１からのパケット１４０７およびＬＣＨ＃２からのパケット１４０８を受信する。パケット１４０７および１４０８は、図１５に示す例において、受信側装置はパケット１４０８を先に受信する。受信側装置は、パケット１４０８を保持する。受信側装置は、所定のタイミングにおいてパケット１４０８を上位レイヤに転送する。受信側装置は、後から送信されるパケット１４０７を受信し、破棄する。
図１５において、パケット複製にＣＡを用いた例を示したが、図１４と同様、パケット複製にＤＣが用いられてもよい。このことにより、例えば、ＵＥと片方の基地局との間の通信経路が遮断（例えば、ブロッキングにより）された場合においても、ＵＥと他方の基地局との間で通信を維持可能となる。その結果、通信の信頼性を向上可能となる。
本実施の形態１にて開示した解決策が、設定済みグラント（Configured grant）を用いた上り送受信に対して適用されてもよいし、設定済みスケジューリング割り当てを用いた下り送受信に対して適用されてもよい。上り通信において、パケット複製により複製されたパケットの両方ともが設定済みグラントを用いて送受信されてもよい。また、上り通信において、片方のパケットが設定済みグラントを用いて送受信され、他方のパケットが動的グラントを用いて送受信されてもよい。下り通信において、パケット複製により複製されたパケットの両方ともが設定済みスケジューリング割り当てを用いて送受信されてもよい。また、片方のパケットが設定済みスケジューリング割り当てを用いて送受信され、他方のパケットが動的スケジューリング割り当てを用いて送受信されてもよい。このことにより、例えば、パケット複製において基地局はスケジューリングを柔軟に実行可能となる。
設定済みグラントおよび／あるいは設定済みスケジューリング割り当てを用いたパケット複製において、受信側装置は、後から受信したパケットの受信タイミングにおいて、受信したパケットを上位レイヤに転送してもよい。受信側装置は、後から受信したパケットの受信結果（例えば、復号結果）によらず、受信したパケットを上位レイヤに転送してもよい。例えば、受信側装置は、後から受信したパケットが復号エラーである場合においても、先に受信したパケットを上位レイヤに転送してもよい。受信側装置は、後から受信するパケットを送受信する論理チャネルにおいて用いられる設定済みグラントあるいは設定済みスケジューリング割り当ての情報を用いて、後から送信されるパケットのタイミングを導出してもよい。前述の動作は、後から受信したパケットが上り通信においては設定済みグラントを用いて送受信される場合、あるいは、後から受信したパケットが下り通信においては設定済みスケジューリング割り当てを用いて送受信される場合に適用してもよい。また、前述の動作は、先に受信したパケットの受信結果が正常（例えば、復号結果が正常）である場合に行うとよい。このことにより、例えば、受信側装置において後から受信したパケットが復号エラーとなる場合においても、受信側装置はＨＡＲＱ再送を待たずに上位レイヤへのパケットの転送が可能となる。その結果、ジッタ特性を向上可能となる。
受信側装置は、設定済みグラントおよび／あるいは設定済みスケジューリング割り当てを用いたパケット複製において、受信結果が正常でない（例えば、復号エラー）パケットの再送を、送信側装置に対して要求しないとしてもよい。該再送は、例えば、ＨＡＲＱ再送であってもよいし、ＲＬＣ再送であってもよい。前述の動作は、複製されたパケットのうち片方の復号結果が正常である場合に行うとよい。このことにより、通信システムにおける効率を向上可能となる。受信側装置のＨＡＲＱエンティティは、受信結果が正常でないパケットの復号結果をＯＫとみなしてもよい。受信側装置のＲＬＣレイヤは、該パケットをＡＣＫとみなしてもよい。例えば、受信側装置のＲＬＣレイヤは、受信ウィンドウを進めてもよい。
図１６は、本実施の形態１において、受信側装置が、複製されたパケットのうち後から送信されるパケットの受信タイミングにおいて、パケットを上位レイヤに転送する動作の他の例を示す図である。図１６は、複製されたパケットがそれぞれ論理チャネル（Logical CHannel；ＬＣＨ）＃１および＃２にマッピングされた場合について示している。図１６は、ＬＣＨ＃１、＃２に対してそれぞれ設定済みスケジューリング割り当てが行われている場合について示している。図１６において、四角で囲った領域は設定済みスケジューリング割り当てによって割り当てられた時間リソースを示し、そのうち、左下がり斜線を付した領域は、複製されたパケットが送信されるタイミングを示す。また、図１６は、パケット複製にＣＡを用いた場合について示している。また、図１６において、送信側装置からデータが送信される周期をＣｙｃｌｅ Ｔｉｍｅとして示している。図１６において、図１５と共通する要素には同じ番号を付し、共通する説明を省略する。
図１６において、受信側装置はＬＣＨ＃１より送信されるパケット１６０１とＬＣＨ＃２より送信されるパケット１６０２を同時に受信する。パケット１６０１および１６０２は、パケット複製によって複製された互いに同一のパケットである。受信側装置は、パケット１６０１を上位レイヤに転送する。受信側装置は、パケット１６０２を破棄する。
図１６において、パケット１６０１、１６０２の受信からＣｙｃｌｅ Ｔｉｍｅ分の時間経過後、受信側装置はＬＣＨ＃１からのパケット１６０３を、ＬＣＨ＃２からのパケット１６０４よりも先に受信する。パケット１６０３および１６０４は、パケット複製によって複製された互いに同一のパケットである。受信側装置は、パケット１６０３を保持する。受信側装置は、パケット１６０４の受信時において、パケット１６０３を上位レイヤに転送する。受信側装置は、パケット１６０４を破棄する。
図１６において、パケット１６０３、１６０４の受信からＣｙｃｌｅ Ｔｉｍｅ分の時間経過後、受信側装置はＬＣＨ＃２からのパケット１６０６を、ＬＣＨ＃１からのパケット１６０５よりも先に受信する。パケット１６０５および１６０６は、パケット複製によって複製された互いに同一のパケットである。受信側装置は、パケット１６０６を保持する。受信側装置は、パケット１６０５の受信時において、パケット１６０６を上位レイヤに転送する。受信側装置は、パケット１６０５を破棄する。
図１６において、パケット１６０５、１６０６の受信からＣｙｃｌｅ Ｔｉｍｅ分の時間経過後、受信側装置はＬＣＨ＃１からのパケット１６０７を、ＬＣＨ＃２からのパケット１６０８よりも先に受信する。パケット１６０７および１６０８は、パケット複製によって複製された互いに同一のパケットである。受信側装置は、パケット１６０７を保持する。受信側装置は、パケット１６０８の受信時において、パケット１６０７を上位レイヤに転送する。受信側装置は、パケット１６０８を破棄する。
図１６において、パケット複製にＣＡを用いた例を示したが、図１４および図１５と同様、パケット複製にＤＣが用いられてもよい。このことにより、例えば、ＵＥと片方の基地局との間の通信経路が遮断（例えば、ブロッキングにより）された場合においても、ＵＥと他方の基地局との間で通信を維持可能となり、その結果、通信の信頼性を向上可能となる。
図１６において、ＬＣＨ＃１、＃２に対してそれぞれ設定済みスケジューリング割り当てが行われている場合について示した。しかし、ＬＣＨ＃１、ＬＣＨ＃２の片方に対して設定済みスケジューリング割り当てが行われ、他方に対して動的なスケジューリング割り当てが行われていてもよい。前述の割り当ては、下り通信に対して行われてもよい。他の例として、ＬＣＨ＃１、＃２に対してそれぞれ設定済みグラントがなされていてもよい。あるいは、ＬＣＨ＃１、ＬＣＨ＃２の片方に対して設定済みグラントが行われ、他方に対して動的なグラントが行われていてもよい。前述のグラントは、上り通信に対して行われてもよい。このことにより、例えば、パケット複製において基地局はスケジューリングを柔軟に実行可能となる。
図１６において、パケット１６０１～１６０８の受信結果（例えば、復号結果）がいずれも正常である場合について示した。しかし、後から受信するパケットが受信エラー（例えば、ＣＲＣエラー）の場合においても、受信側装置は先に受信したパケットを上位レイヤに転送してもよい。前述の動作は、例えば、後から受信するパケットが設定済みスケジューリング割り当てを用いて送信された場合、または後から受信するパケットが設定済みグラントを用いて送信された場合に適用するとしてもよい。前述の場合において、受信側装置は送信側装置に対して、ＨＡＲＱ再送を要求しないとしてもよいし、ＲＬＣ再送を要求しないとしてもよい。このことにより、例えば、ジッタ特性が向上可能となるとともに、通信システムにおける効率を向上可能となる。
複製された各パケットの送信に用いる設定済みグラントおよび／あるいは設定済みスケジューリング割り当てを、同じタイミングとしてもよい。該タイミングは、例えば、同じ周期としてもよいし、同じタイミングオフセットとしてもよい。該周期は、例えば、複製されるパケットの送信周期と同じとしてもよい。該タイミングオフセットは、例えば、前述の所定のタイミングと同じとしてもよい。このことにより、例えば、ジッタ削減を、通信システムにおいて少ない処理量で実行可能となる。
基地局間で、設定済みグラントおよび／あるいは設定済みスケジューリング割り当てが行われるタイミングに関する情報を通知してもよい。該通知には、例えば、周期に関する情報が含まれてもよいし、タイミングオフセットに関する情報が含まれてもよい。該通知は、例えば、ＤＣを用いたパケット複製において行われてもよい。マスタ基地局が、該タイミングに関する情報をセカンダリ基地局に通知するとしてもよい。セカンダリ基地局は、該情報を用いて該タイミングを決定してもよい。
複製された両パケットの送受信が、設定済みグラントおよび／あるいは設定済みスケジューリング割り当てが行われるタイミングのうち一部において行われるとしてもよい。例えば、設定済みグラントおよび／あるいは設定スケジューリング割り当ての周期が、複製されたパケットの周期と異なる場合において、複製された両パケットの送受信が、該タイミングのうち一部を用いて行われるとしてもよい。このことにより、例えば、基地局とＵＥとの間の通信において、設定済みグラントおよび／あるいは設定済みスケジューリング割り当てを、複製されたパケットの周期に合わせて確保できない場合においても、設定済みグラントおよび／あるいは設定済みスケジューリング割り当てを用いた該パケットの送受信が可能となる。
前述の一部のタイミングに関する情報は、規格で予め決められてもよい。例えば、複製されたパケットの送受信における、前述の所定のタイミングに最も近い、設定済みグラントおよび／あるいは設定済みスケジューリング割り当てが行われるタイミングにおいて、複製されたパケットの送受信が行われるとしてもよい。あるいは、該送受信は、所定のタイミング以前の最も近いタイミングにおいて行われるとしてもよいし、所定のタイミング以降の最も近いタイミングにおいて行われるとしてもよい。
前述の方法が組み合わせて用いられてもよい。例えば、所定のタイミングの直近として、所定のタイミングの前後等間隔にそれぞれ、設定済みグラントおよび／あるいは設定済みスケジューリング割り当てが行われるタイミングが存在する場合において、所定のタイミングの前に存在する設定済みグラントおよび／あるいは設定済みスケジューリング割り当てが用いられてもよい。他の例として、所定のタイミングの後に存在する設定済みグラントおよび／あるいは設定済みスケジューリング割り当てが用いられてもよい。
他の例として、前述の一部のタイミングに関する情報を、基地局が決定してＵＥに通知してもよい。基地局からＵＥに対する通知には、例えば、設定済みグラントおよび／あるいは設定済みスケジューリング割り当てのうち、複製されたパケットの送受信に用いるグラントおよび／あるいは割り当てに関する情報が含まれてもよい。該情報には、例えば、パケットの送受信に用いるグラントおよび／あるいは割り当てのパターンに関する情報が含まれてもよい。該パターンに関する情報は、例えば、パケットの送受信に用いられるか否かを示すビットマップの情報であってもよいし、他の形式の情報であってもよい。複製されたパケットの送受信に用いるグラントおよび／あるいは割り当てに関する情報の他の例として、該パターンの周期に関する情報が含まれてもよいし、該パターンの有効期間に関する情報が含まれてもよい。
一部のタイミングに関する情報の通知には、例えば、ＲＲＣシグナリングが用いられてもよい。このことにより、例えば、基地局からＵＥに対して多くの情報を通知可能となり、その結果、通信システムにおける柔軟性を向上可能となる。他の例として、該通知には、ＭＡＣシグナリングが用いられてもよい。このことにより、例えば、多値変調により、基地局はＵＥに対して多くの情報を通知可能としつつ、基地局からＵＥに対して該情報を迅速に通知可能となる。他の例として、該情報の通知には、Ｌ１／Ｌ２シグナリングが用いられてもよい。このことにより、例えば、基地局からＵＥへの通知をさらに迅速に実行可能となる。
受信側装置が所定のタイミングにおいて受信パケットを上位レイヤに転送する動作を、設定済みグラントまたは設定済みスケジューリング割り当てが行われた場合に適用してもよい。受信側装置における動作、および、上位ＮＷ装置または基地局からＵＥに対する該タイミングの通知は、本実施の形態１にて開示した方法と同様としてもよい。ＵＥから基地局または上位ＮＷ装置に対する該タイミングの通知についても、同様としてもよい。このことにより、例えば、ジッタ特性をさらに向上可能となる。
受信側装置は、所定のタイミングおよび後に受信したパケットの受信タイミングのうち、先に到来するタイミングにおいて該パケットを上位レイヤに転送する動作を、設定済みグラントまたは設定済みスケジューリング割り当てが行われた場合に適用してもよい。このことにより、例えば、受信側装置におけるメモリ消費量を削減可能となる。前述において、該上位レイヤは、所定のタイミングまで該パケットを保持するとしてもよい。該保持は、例えば、後に受信したパケットの受信タイミングが所定のタイミングよりも先に到来する場合において行われるとしてもよい。このことにより、例えば、該パケットの送受信におけるジッタ特性を向上可能となる。
図１７は、本実施の形態１において、受信側装置が所定のタイミングにおいて受信パケットを上位レイヤに転送する動作の他の例を示す図である。図１７は、複製されたパケットがそれぞれ論理チャネル（Logical CHannel；ＬＣＨ）＃１および＃２にマッピングされた場合について示している。図１７は、ＬＣＨ＃１、＃２に対してそれぞれ設定済みスケジューリング割り当てが行われている場合について示している。図１７において、四角で囲った領域は設定済みスケジューリング割り当てによって割り当てられた時間リソースを示し、そのうち、左下がり斜線を付した領域は、複製されたパケットが送信されるタイミングを示す。また、図１７は、パケット複製にＣＡを用いた場合について示している。また、図１７において、送信側装置からデータが送信される周期をＣｙｃｌｅ Ｔｉｍｅとして示している。図１７において、図１６と共通する要素には同じ番号を付し、共通する説明を省略する。
図１７におけるパケット１６０１、１６０２に関する受信側装置の動作は、図１６と同様である。また、パケット１６０３、１６０４に関する受信側装置の動作は、図１６と同様である。なお、図１７において、受信側装置がパケット１６０１、１６０２を受信するタイミングは、所定のタイミングと一致する。また、受信側装置がパケット１６０４を受信するタイミングは、所定のタイミングと一致する。
図１７において、パケット１６０３、１６０４の受信からＣｙｃｌｅ Ｔｉｍｅ分の時間経過後、受信側装置はＬＣＨ＃２からのパケット１６０６を、ＬＣＨ＃１からのパケット１６０５よりも先に受信する。図１７において、受信側装置がパケット１６０６を受信するタイミングは、所定のタイミングと一致する。受信側装置は、パケット１６０６の受信と同時に、パケット１６０６を上位レイヤに転送する。受信側装置は、該タイミングの後においてパケット１６０５を受信する。受信側装置は、パケット１６０５を破棄する。
図１７におけるパケット１６０７、１６０８に関する受信側装置の動作は、図１６と同様である。なお、図１７において、受信側装置がパケット１６０８を受信するタイミングは、所定のタイミングと一致する。
図１７において、パケット複製にＣＡを用いた例を示したが、図１４、図１５および図１６と同様、パケット複製にＤＣが用いられてもよい。このことにより、例えば、ＵＥと片方の基地局との間の通信経路が遮断（例えば、ブロッキングにより）された場合においても、ＵＥと他方の基地局との間で通信を維持可能となり、その結果、通信の信頼性を向上可能となる。
図１７において、ＬＣＨ＃１、＃２に対してそれぞれ設定済みスケジューリング割り当てが行われている場合について示した。しかし、図１６と同様、両ＬＣＨ＃１、＃２に対して設定済みグラントが行われてもよいし、片方のＬＣＨにのみ設定済みスケジューリング割り当てあるいは設定済みグラントが行われてもよい。このことにより、例えば、パケット複製において基地局はスケジューリングを柔軟に実行可能となる。
図１７において、パケット１６０１～１６０８の受信結果（例えば、復号結果）がいずれも正常である場合について示した。しかし、図１６と同様、後から受信するパケットが受信エラー（例えば、ＣＲＣエラー）の場合においても、受信側装置は先に受信したパケットを上位レイヤに転送してもよい。前述の動作は、例えば、後から受信するパケットが設定済みスケジューリング割り当てを用いて送信された場合、または後から受信するパケットが設定済みグラントを用いて送信された場合に適用するとしてもよい。前述の場合において、受信側装置は送信側装置に対して、ＨＡＲＱ再送を要求しないとしてもよいし、ＲＬＣ再送を要求しないとしてもよい。このことにより、例えば、ジッタ特性が向上可能となるとともに、通信システムにおける効率を向上可能となる。
図１７において、受信側装置におけるパケット１６０１、１６０２、１６０４、１６０６、１６０８の受信タイミングがそれぞれ所定のタイミングと一致する場合について示した。しかし、パケット１６０１、１６０２、１６０４、１６０６、１６０８の受信タイミングは、所定のタイミングと一致しなくてもよい。例えば、パケット１６０４の受信タイミングが所定のタイミングより前である場合において、受信側装置は、パケット１６０３を所定のタイミングまで保持してもよい。受信側装置はパケット１６０４を受信してもよい。受信側装置は、パケット１６０４を破棄してもよい。このことにより、例えば、ジッタ特性をさらに向上可能となる。
本実施の形態１において用いられるパケット複製は、例えば、サイドリンクを用いたものであってもよい。例えば、複製された片方のパケットがＵｕインタフェースを用いて送信されてもよいし、他方のパケットが端末間インタフェース（例：ＰＣ５インタフェース）を用いて送信されてもよい。他の例として、複製されたパケットの両方が端末間インタフェース（例：ＰＣ５インタフェース）を用いて送受信されてもよい。このことにより、例えば、サイドリンク通信においても、ジッタを低減可能となる。
本実施の形態１によって、基地局とＵＥとの通信における信頼性を確保しつつ、ジッタ特性を向上可能となる。
実施の形態１の変形例１．
実施の形態１においては、ＣＡあるいはＤＣを用いたパケット複製におけるジッタ特性向上の方法について開示したが、同じキャリアを用いたパケット複製を用いてもよい。該パケット複製は、ＤＣあるいはＣＡを用いるパケット複製とは異なる、新たなパケット複製として設けられてもよい。
複製された両パケットが、互いに異なるトランスポートブロックにマッピングされて送信されてもよい。各トランスポートブロックが同じキャリアにマッピングされて送信されてもよい。このことにより、例えば、１つのキャリアのみを用いる通信においても、信頼性を向上可能となる。
送信側装置は、複製された各パケットを異なるトランスポートブロックにマッピングしてもよい。送信側装置は、基地局であってもよいし、ＵＥであってもよい。送信側装置は、各トランスポートブロックを符号化して生成した各物理チャネルデータを、互いに異なる周波数および／あるいは時間リソースに配置して送信してもよいし、ＭＩＭＯにおける異なるレイヤに配置して送信してもよい。
受信側装置は、受信した信号を用いて、複製された両パケットより生成された各物理チャネル信号を抽出してもよい。受信側装置は、ＵＥであってもよいし、基地局であってもよい。受信側装置は、前述の各物理チャネル信号を用いて、各トランスポートブロックへの復号を行ってもよい。受信側装置は、前述の各物理チャネル信号を用いて、複製された各パケットを生成してもよい。例えば、受信側装置は、前述の各トランスポートブロックを用いて、各パケットを生成してもよい。受信側装置は、複製された各パケットのうちいずれか１つを上位レイヤに転送してもよい。受信側装置は、複製された各パケットのうち、上位レイヤに転送したパケット以外のパケットを破棄してもよい。
受信側装置は、前述の各トランスポートブロックのうち片方のみのＨＡＲＱ再送を要求しないとしてもよい。例えば、受信側装置において片方のトランスポートブロックの復号結果（例えば、ＣＲＣ結果）が正常であり、他方のトランスポートブロックが復号ＮＧであった場合において、受信側装置は送信側装置に対してＨＡＲＱ－ＮＡＣＫを送信しないとしてもよい。受信側装置は該他方のトランスポートブロックに対してもＨＡＲＱ－ＡＣＫとみなしてもよい。受信側装置は送信側装置に対し、該他方のトランスポートブロックに対するＨＡＲＱ－ＡＣＫを送信するとしてもよい。他の例として、受信側装置は送信側装置に対し、該他方のトランスポートブロックに対するＨＡＲＱ－ＮＡＣＫを送信するとしてもよい。送信側装置は、片方のトランスポートブロックに対するＨＡＲＱ－ＡＣＫの受信、および、他方のトランスポートブロックに対するＨＡＲＱ－ＮＡＣＫの受信を用いて、該他方のトランスポートブロックに対するＨＡＲＱ再送を行わないとしてもよい。このことにより、例えば、通信システムにおける効率を向上可能となる。
受信側装置は、複製された各パケットのうち受信結果がＮＧであった片方のパケットについても受信結果をＯＫとみなしてもよい。該動作は、例えば、ＲＬＣレイヤにおいて行われてもよい。
基地局からＵＥに対し、同じキャリアを用いたパケット複製に関する設定を行ってもよい。該設定は、上位ＮＷ装置からＵＥに対して行われてもよい。
該設定は、同じキャリアを用いたパケット複製の実行有無を示す情報を含んでもよいし、同じキャリアを用いたパケット複製の開始あるいは停止に関する情報を含んでもよい。このことにより、例えば、同じキャリアを用いたパケット複製を柔軟に制御可能となる。
該設定は、受信側装置から基地局側装置に対するフィードバックに関する情報を含んでもよい。該情報は、例えば、ＱｏＳパラメータを用いて決められてもよいし、ネットワークスライシングに関する情報を用いて決められてもよい。
該情報は、受信側装置の処理に関する情報を含んでもよい。例えば、該情報は、復号ＮＧであったトランスポートブロックに対するＨＡＲＱ応答を行わないことを示す情報を含んでもよいし、該トランスポートブロックに対してＨＡＲＱ－ＮＡＣＫの応答を行うことを示す情報を含んでもよいし、該トランスポートブロックに対してＨＡＲＱ－ＡＣＫの応答を行うことを示す情報を含んでもよい。前述の情報は、片方のトランスポートブロックが復号ＯＫであった場合に適用されるとしてもよい。受信側装置の処理に関する情報は、他の例として、前述のＨＡＲＱ応答を、ＲＬＣのＡＲＱ応答に読み替えた情報を含んでもよい。このことにより、例えば、ＨＡＲＱ応答を行わないことにより、通信システムにおける効率を向上可能となる。
フィードバックに関する該情報は、送信側装置における処理に関する情報を含んでもよい。例えば、該情報は、送信側装置が、復号ＮＧであったトランスポートブロックに対するＨＡＲＱ再送を行わないことを示す情報を含んでもよいし、ＨＡＲＱ応答がなかったトランスポートブロックに対するＨＡＲＱ再送を行わないことを示す情報を含んでもよい。前述の情報は、片方のトランスポートブロックに対するＨＡＲＱ－ＡＣＫを受信した場合に適用されるとしてもよい。送信側装置の処理に関する情報は、他の例として、前述のＨＡＲＱ再送を、ＲＬＣ再送に読み替えた情報を含んでもよい。このことにより、例えば、ＨＡＲＱ再送を行わないことにより、通信システムにおける効率を向上可能となる。
該設定は、トランスポートブロックの配置方法に関する情報を含んでもよい。トランスポートブロックの配置方法に関する情報として、以下の（１）～（５）を開示する。
（１）周波数リソースを分けた配置。
（２）時間リソースを分けた配置。
（３）ＭＩＭＯにおけるレイヤを分けた配置。
（４）コード多重におけるコードを分けた配置。
（５）上記（１）～（４）の組合せ。
前述の（１）の情報は、複製されたパケットの片方が配置される周波数リソースに関する情報を含んでもよい。該情報は、例えば、該パケットが配置される最初のＲＢ（Resource Block）に関する情報を含んでもよいし、該パケットが配置されるＲＢ数に関する情報を含んでもよいし、該パケットが配置される最後のＲＢ番号に関する情報を含んでもよい。このことにより、例えば、該パケットの配置に関する情報の大きさを削減可能となる。その結果、通信システムの効率を向上可能となる。
前述の（１）の情報は、他の例として、複製されたパケットの片方が配置される周波数リソースの配置パターンに関する情報を含んでもよい。配置パターンに関する該情報は、例えば、配置パターンの周期に関する情報を含んでもよいし、該周期に対するオフセットに関する情報を含んでもよい。該オフセットにあたる周波数リソースにおいて、該片方のパケットの送信が行われるとしてもよい。他の例として、配置パターンを表すビットマップに関する情報が用いられてもよい。このことにより、例えば、複製されたパケットを周波数方向に離散的に配置可能となる。その結果、周波数ダイバーシチの効果を得ることが可能となる。
前述の（１）において、複製されたパケットの他方が配置される周波数リソースに関する情報は、前述の片方のパケットが配置される周波数リソースに関する情報と同様としてもよい。このことにより、例えば、通信システムにおいて複製されたパケットの両方における周波数リソースの配置を柔軟に実行可能となる。
他の例として、前述の（１）において、複製されたパケットの他方が配置される周波数リソースに関する情報は、基地局よりグラントおよび／あるいはスケジューリング割り当てを受けている周波数および／あるいは時間リソースのうち、前述の片方のパケットが配置される周波数リソースを除いた周波数リソースとしてもよい。このことにより、例えば、基地局および／あるいは上位ＮＷ装置からＵＥに対するシグナリング量を削減可能となる。その結果、通信システムの効率を向上可能となる。
前述の（２）の情報は、複製されたパケットの片方が配置される時間リソースに関する情報を含んでもよい。該情報は、例えば、該パケットが配置される最初のシンボル番号に関する情報を含んでもよいし、該パケットが配置されるシンボル数に関する情報を含んでもよいし、該パケットが配置される最後のシンボル番号に関する情報を含んでもよい。このことにより、例えば、該パケットの配置に関する情報の大きさを削減可能となる。その結果、通信システムの効率を向上可能となる。
前述の（２）の情報は、他の例として、複製されたパケットの片方が配置される時間リソースの配置パターンに関する情報を含んでもよい。配置パターンに関する該情報は、例えば、配置パターンの周期に関する情報を含んでもよいし、該周期に対するオフセットに関する情報を含んでもよい。該オフセットにあたる時間リソースにおいて、該片方のパケットの送信が行われるとしてもよい。他の例として、配置パターンを表すビットマップに関する情報が用いられてもよい。このことにより、例えば、複製されたパケットを時間方向に離散的に配置可能となる。その結果、時間ダイバーシチの効果を得ることが可能となる。
前述の（２）において、複製されたパケットの他方が配置される時間リソースに関する情報は、前述の片方のパケットが配置される時間リソースに関する情報と同様としてもよい。このことにより、例えば、通信システムにおいて複製されたパケットの両方における時間リソースの配置を柔軟に実行可能となる。
他の例として、前述の（２）において、複製されたパケットの他方が配置される時間リソースに関する情報は、基地局よりグラントおよび／あるいはスケジューリング割り当てを受けている周波数および／あるいは時間リソースのうち、前述の片方のパケットが配置される時間リソースを除いた時間リソースとしてもよい。このことにより、例えば、基地局および／あるいは上位ＮＷ装置からＵＥに対するシグナリング量を削減可能となる。その結果、通信システムの効率を向上可能となる。
前述の（３）の情報は、複製されたパケットの片方が配置されるレイヤに関する情報を含んでもよいし、複製されたパケットの他方が配置されるレイヤに関する情報を含んでもよい。このことにより、例えば、複製されたパケットの送受信において空間ダイバーシチの効果を得ることが可能となる。
前述の（４）の情報は、複製されたパケットの片方に適用されるコードに関する情報を含んでもよいし、他方のパケットに適用されるコードに関する情報を含んでもよい。前述のコードは、例えば、直交符号（例：アダマール符号、ＺＣ（Zadoff-Chu）符号）であってもよいし、直交符号とは異なる符号であってもよい。このことにより、例えば、単一キャリア、単一レイヤを用いる場合においても、パケット複製を実行可能となる。その結果、信頼性を向上可能となる。
前述の（５）の情報は、例えば、前述の（１）の周波数リソース配置が開始されるタイミングに関する情報（例：シンボル番号）を含んでもよいし、該周波数リソース配置が継続される時間に関する情報（例：シンボル数）を含んでもよいし、該周波数リソース配置が終了されるタイミングに関する情報（例：シンボル番号）を含んでもよい。前述の情報は、複数設けられてもよい。例えば、該周波数リソース配置が、基地局よりグラントおよび／あるいはスケジューリング割り当てを受けている時間リソースにおいて複数回行われる場合において、前述の情報が、該複数回分設けられるとしてもよい。このことにより、例えば、スケジューリングにおける柔軟性を向上可能となるとともに、複製されたパケットの送受信において、時間および周波数ダイバーシチ効果を得ることが可能となる。
前述の（１）～（５）に示す情報の通知において、ＮＡＳシグナリングが用いられてもよいし、ＲＲＣシグナリングが用いられてもよい。このことにより、例えば、上位ＮＷ装置および／あるいは基地局からＵＥに対して多くの情報を通知可能となる。その結果、通信システムにおける柔軟性を向上可能となる。
該通知における他の例として、ＭＡＣシグナリングが用いられてもよい。このことにより、例えば、多値変調により多くの情報を送信可能としつつ、基地局からＵＥに対して迅速に該通知を実行可能となる。
該通知における他の例として、Ｌ１／Ｌ２シグナリングが用いられてもよい。例えば、前述の（１）～（５）に示す情報が、グラントおよび／あるいはスケジューリング割り当てを通知するＤＣＩに含まれてもよいし、異なるＤＣＩに含まれてもよい。このことにより、例えば、基地局からＵＥに対してさらに迅速に該通知を実行可能となる。
該通知にＬ１／Ｌ２シグナリングを用いる他の例として、複製された各パケットに対してＤＣＩが設けられてもよい。例えば、複製された各パケットに対してグラントおよび／あるいはスケジューリング割り当てが行われるとしてもよい。複製された各パケットに対するグラントおよび／あるいはスケジューリング割り当てが、各ＤＣＩに含まれて通知されてもよい。このことにより、例えば、スケジューリングにおける柔軟性を向上可能としつつ、通信システムの設計における複雑性を回避可能となる。
該通知に用いられるシグナリングとして、前述の複数が組み合わせて用いられてもよい。例えば、同じキャリアを用いたパケット複製の開始および／あるいは終了に関する情報の通知にＭＡＣシグナリングが用いられてもよいし、前述の（１）～（５）に示す情報の通知にＬ１／Ｌ２シグナリングが用いられてもよい。このことにより、例えば、基地局からＵＥに通知可能な情報量を確保しつつ、迅速な通知が可能となる。
同じキャリアを用いたパケット複製において、設定済みグラントおよび／あるいは設定済みスケジューリング割り当てが用いられてもよい。設定済みグラントおよび／あるいは設定済みスケジューリング割り当てが用いられる場合における、基地局からＵＥへの設定は、前述において開示した内容と同様であってもよい。該設定は、例えば、基地局からＵＥに対する設定済みグラントおよび／あるいは設定済みスケジューリング割り当ての設定に含まれてもよいし、異なるシグナリングを用いて通知されてもよい。このことにより、例えば、同じキャリアを用いたパケット複製における周波数および／あるいは時間リソースの確保に関する設計の複雑性を回避可能となる。
複製された両パケットのそれぞれが、異なる周波数リソースにマッピングされて送信されてもよい。各パケットの送受信に用いられる各トランスポートブロックが、互いに異なる周波数リソースにマッピングされて送信されてもよい。複製された両パケットが、スケジューリングにより割り当てられた同じ時間リソースに割り当てられてもよい。このことにより、例えば、パケット複製において周波数ダイバーシチ効果が得られる。また、送信側装置は、複製した両パケットを同時に送信可能となり、その結果、例えば、パケットのＨＡＲＱ再送によって発生するレイテンシの揺らぎ、すなわち、ジッタを低減可能となる。
各周波数リソースは、集中的に配置されてもよい。各パケットの送信に用いられる周波数リソースは、互いに隣接していてもよいし、互いに離れていてもよい。周波数リソースの設定は、例えば、ＲＢ単位で行われてもよいし、複数ＲＢ単位で行われてもよい。
基地局はＵＥに対し、各周波数リソースにマッピングされるパケットの情報を通知してもよい。ＵＥは、該情報を用いて、複製されたパケットを各周波数リソースにマッピングして基地局に送信してもよい。あるいは、ＵＥは、該情報を用いて、各周波数リソースにおいて受信した信号から、複製された各パケットを抽出してもよい。
図１８は、複製したパケットを同じキャリア上で送受信する動作について示している。図１８に示す例において、基地局からＵＥに対してグラントとして通知される周波数および時間リソースを太破線で示している。図１８は、複製された片方のパケットがトランスポートブロック＃１にマッピングされ、他方のパケットがトランスポートブロック＃２にマッピングされる例について示す。図１８は、複製された各パケットがマッピングされる各周波数リソースが集中的に、かつ、互いに隣接して配置される場合について示している。図１８において、送信側装置からデータが送信される周期をＣｙｃｌｅ Ｔｉｍｅとして示している。図１８において、制御チャネルおよび／あるいは参照信号等の配置は省略している。
図１８において、基地局よりグラントされた、あるいは割り当てられた時間および周波数リソース１８０１のうち、周波数が高い側の半分の領域１８０２に、トランスポートブロック＃１より生成された物理チャンネルの信号がマッピングされる。リソース１８０１のうち、周波数が低い側の半分の領域１８０３に、トランスポートブロック＃２より生成された物理チャンネルの信号がマッピングされる。
図１８において、リソース１８０４、領域１８０５、領域１８０６については、それぞれ、リソース１８０１、領域１８０２、領域１８０３と同様である。図１８において、リソース１８０７、領域１８０８、領域１８０９については、それぞれ、リソース１８０１、領域１８０２、領域１８０３と同様である。
図１８において、トランスポートブロック＃１より生成された物理チャンネルの信号を領域１８０２、１８０５、１８０８にマッピングし、トランスポートブロック＃２より生成された物理チャンネルの信号を領域１８０３、１８０６、１８０９にマッピングする例について示した。しかし、マッピングされる領域がトランスポートブロック＃１とトランスポートブロック＃２とで入れ替わってもよい。例えば、トランスポートブロック＃１が領域１８０３、１８０６、１８０９にマッピングされ、トランスポートブロック＃２が領域１８０２、１８０５、１８０８にマッピングされてもよい。前述のマッピングは、時間毎に切替わってもよい。例えば、トランスポートブロック＃１が領域１８０２、１８０６、１８０８にマッピングされ、トランスポートブロック＃２が領域１８０３、１８０５、１８０９にマッピングされてもよい。このことにより、例えば、基地局はスケジューリングを柔軟に実行可能となる。
図１８において、トランスポートブロック＃１がマッピングされる領域が、トランスポートブロック＃２がマッピングされる領域と隣接している場合について示した。しかし、これらの領域は離れていてもよい。例えば、領域１８０２、１８０３が、互いに周波数方向に離れていてもよい。領域１８０５、１８０６についても、領域１８０８、１８０９についても、同様としてもよい。前述の場合において、リソース１８０１は、離散的に割り当てるとよい。リソース１８０４、１８０７についても、同様とするとよい。このことにより、例えば、基地局は、離れた２つの領域の間に他のチャネルを割り当て可能となり、その結果、スケジューリングにおける柔軟性が向上する。
他の例として、各周波数リソースは、離散的に配置されてもよい。周波数リソースの配置は、ＲＢ単位で行われてもよいし、複数のＲＢを単位として行われてもよいし、サブキャリア単位で行われてもよい。各パケットの送信に用いられる周波数リソースは、互いに隣接していてもよいし、互いに離れていてもよい。このことにより、例えば、複製された各パケットの送受信において周波数ダイバーシチ効果が得られ、その結果、通信の信頼性を向上可能となる。
図１９は、複製したパケットを同じキャリア上で送受信する他の例について示している。図１９において、基地局からＵＥに対してグラントとして通知される周波数および時間リソースを太破線で示している。図１９は、複製された片方のパケットがトランスポートブロック＃１にマッピングされ、他方のパケットがトランスポートブロック＃２にマッピングされる例について示す。図１９は、複製された各パケットがマッピングされる各周波数リソースが離散的に、かつ、互いに隣接して配置される場合について示している。図１９において、送信側装置からデータが送信される周期をＣｙｃｌｅ Ｔｉｍｅとして示している。図１９において、制御チャネルおよび／あるいは参照信号等の配置は省略している。図１９において、図１８と同様の要素には同じ番号を付し、共通する説明を省略する。
図１９において、基地局よりグラントされた、あるいは割り当てられた時間および周波数リソース１８０１のうち、左下がり斜線にて示す時間及び周波数の領域１９０２に、トランスポートブロック＃１より生成された物理チャンネルの信号がマッピングされる。リソース１８０１のうち、右下がり斜線にて示す時間及び周波数の領域１９０３に、トランスポートブロック＃２より生成された物理チャンネルの信号がマッピングされる。
図１９において、リソース１８０４、領域１９０５、領域１９０６については、それぞれ、リソース１８０１、領域１９０２、領域１９０３と同様である。図１９において、リソース１８０７、領域１９０８、領域１９０９については、それぞれ、リソース１８０１、領域１９０２、領域１９０３と同様である。
図１９においても、図１８と同様、トランスポートブロック＃１より生成された物理チャンネルの信号がマッピングされる領域は、トランスポートブロック＃２より生成された物理チャンネルの信号がマッピングされる領域と入れ替わってもよい。前述のマッピングは、時間毎に切替わってもよい。このことにより、例えば、基地局はスケジューリングを柔軟に実行可能となる。
図１９においても、図１８と同様、トランスポートブロック＃１がマッピングされる領域は、トランスポートブロック＃２がマッピングされる領域と離れていてもよい。前述の場合において、リソース１８０１、１８０４、１８０７は、離散的に割り当てるとよい。このことにより、例えば、基地局は、離れた２つの領域の間に他のチャネルを割り当て可能となり、その結果、スケジューリングにおける柔軟性が向上する。
他の例として、片方のパケットの送信に用いられる周波数リソースが集中的に配置され、他方のパケットの送信に用いられる周波数リソースが分散的に配置されてもよい。分散的に配置された、片方の周波数リソースの間に、他方の周波数リソースが配置されてもよい。このことにより、例えば、基地局による周波数方向のスケジューリングを柔軟に実行可能となる。
複製されたパケットのマッピングに関する他の方法を開示する。複製された両パケットのそれぞれが、異なる時間リソースにマッピングされて送信されてもよい。例えば、両パケットのそれぞれが、異なるシンボルにマッピングされてもよい。各パケットの送受信に用いられる各トランスポートブロックが、互いに異なる時間リソース（例えば、シンボル）にマッピングされて送信されてもよい。複製された両パケットが、スケジューリングにより割り当てられた同じ時間リソース内に割り当てられてもよい。このことにより、例えば、パケット複製において時間ダイバーシチ効果が得られる。また、送信側装置は、複製した両パケットを同じスケジューリングリソース内で送信可能となり、その結果、例えば、パケットのＨＡＲＱ再送によって発生するレイテンシの揺らぎ、すなわち、ジッタを低減可能となる。
各時間リソースは、集中的に配置されてもよいし、分散的に配置されてもよい。該時間リソースは、例えば、シンボル単位で設定されてもよいし、ミニスロット単位で設定されてもよいし、他の単位で設定されてもよい。例えば、該時間リソースが集中的に配置されることにより、通信システムにおける処理量を削減可能となる。他の例として、分散的に配置されることにより、時間ダイバーシチ効果を向上可能となる。
基地局はＵＥに対し、各時間リソースにマッピングされるパケットの情報を通知してもよい。ＵＥは、該情報を用いて、複製されたパケットを各時間リソースにマッピングして基地局に送信してもよい。あるいは、ＵＥは、該情報を用いて、各時間リソースにおいて受信した信号から、複製された各パケットを抽出してもよい。
図２０は、複製したパケットを同じキャリア上で送受信する他の例について示している。図２０において、基地局からＵＥに対してグラントとして通知される周波数および時間リソースを太破線で示している。図２０は、複製された片方のパケットがトランスポートブロック＃１にマッピングされ、他方のパケットがトランスポートブロック＃２にマッピングされる例について示す。図２０は、複製された各パケットがマッピングされる各時間リソースが集中的に配置される場合について示している。図２０において、送信側装置からデータが送信される周期をＣｙｃｌｅ Ｔｉｍｅとして示している。図２０において、制御チャネルおよび／あるいは参照信号等の配置は省略している。図２０において、図１８と同様の要素には同じ番号を付し、共通する説明を省略する。
図２０において、基地局よりグラントされた、あるいは割り当てられた時間および周波数リソース１８０１のうち、左下がり斜線にて示す時間及び周波数の領域２００２に、トランスポートブロック＃１より生成された物理チャンネルの信号がマッピングされる。リソース１８０１のうち、右下がり斜線にて示す時間及び周波数の領域２００３に、トランスポートブロック＃２より生成された物理チャンネルの信号がマッピングされる。
図２０において、リソース１８０４、領域２００５、領域２００６については、それぞれ、リソース１８０１、領域２００２、領域２００３と同様である。図２０において、リソース１８０７、領域２００８、領域２００９については、それぞれ、リソース１８０１、領域２００２、領域２００３と同様である。
図２０においても、図１８と同様、トランスポートブロック＃１より生成された物理チャンネルの信号がマッピングされる領域は、トランスポートブロック＃２より生成された物理チャンネルの信号がマッピングされる領域と入れ替わってもよい。前述のマッピングは、時間毎に切替わってもよい。このことにより、例えば、基地局はスケジューリングを柔軟に実行可能となる。
図２０において、複製された各パケットがマッピングされる各時間リソースが集中的に配置される場合について示した。しかし、これらの時間リソースは分散的に配置されてもよい。例えば、マッピングされるパケットがシンボル毎に入れ替わってもよい。このことにより、例えば、両パケットの送信における時間ダイバーシチ効果を向上可能となる。
複製された両パケットのそれぞれを異なる時間リソースにマッピングする場合において、両パケットが同じスケジューリングリソースにおいて割り当てられる例について開示した。しかし、複製された両パケットは、異なるスケジューリングリソースにおいて割り当てられてもよい。このことにより、例えば、通信システムにおいて、スケジューリングに関する設計の複雑性を回避可能となる。
複製されたパケットのマッピングに関する他の方法を開示する。複製された両パケットのそれぞれが、異なる時間および周波数リソースにマッピングされて送信されてもよい。例えば、ある時間リソース（例えば、シンボル）において、両パケットのそれぞれが、異なる周波数リソースにマッピングされ、他の時間リソースにおいて、各パケットが割り当てられる周波数リソースが切替るとしてもよい。複製された両パケットが、スケジューリングにより割り当てられた同じ時間リソース内に割り当てられてもよい。このことにより、例えば、パケット複製において周波数ダイバーシチ効果および時間ダイバーシチ効果が得られ、その結果、通信の信頼性を向上可能となる。また、送信側装置は、複製した両パケットを同じスケジューリングリソース内で送信可能となり、その結果、例えば、パケットのＨＡＲＱ再送によって発生するレイテンシの揺らぎ、すなわち、ジッタを低減可能となる。
各時間リソースにおいて、各パケットに割り当てられる周波数リソースは、集中的に配置されてもよいし、分散的に配置されてもよい。例えば、集中的に配置されることにより、通信システムにおける処理量を削減可能となる。他の例として、分散的に配置されることにより、周波数ダイバーシチ効果を向上可能となる。
各周波数リソースにおいて、各パケットに割り当てられる時間リソースは、集中的に配置されてもよいし、分散的に配置されてもよい。例えば、集中的に配置されることにより、通信システムにおける処理量を削減可能となる。他の例として、分散的に配置されることにより、時間ダイバーシチ効果を向上可能となる。
基地局はＵＥに対し、各時間および周波数リソースにマッピングされるパケットの情報を通知してもよい。ＵＥは、該情報を用いて、該時間リソースにおいて、複製されたパケットを該周波数リソースにマッピングして基地局に送信してもよい。あるいは、ＵＥは、該情報を用いて、該時間リソースにおいて受信した信号から、複製された各パケットを抽出してもよい。
図２１は、複製したパケットを同じキャリア上で送受信する他の例について示している。図２１において、基地局からＵＥに対してグラントとして通知される周波数および時間リソースを太破線で示している。図２１は、複製された片方のパケットがトランスポートブロック＃１にマッピングされ、他方のパケットがトランスポートブロック＃２にマッピングされる例について示す。図２１は、各時間リソースにおいて、複製された各パケットがマッピングされる各周波数リソースが集中的に配置される場合について示している。図２１において、送信側装置からデータが送信される周期をＣｙｃｌｅ Ｔｉｍｅとして示している。図２１において、制御チャネルおよび／あるいは参照信号等の配置は省略している。図２１において、図１８と同様の要素には同じ番号を付し、共通する説明を省略する。
図２１において、基地局よりグラントされた、あるいは割り当てられた時間および周波数リソース１８０１のうち、左下がり斜線にて示す時間及び周波数の領域２１０２に、トランスポートブロック＃１より生成された物理チャンネルの信号がマッピングされる。リソース１８０１のうち、右下がり斜線にて示す時間及び周波数の領域２１０３に、トランスポートブロック＃２より生成された物理チャンネルの信号がマッピングされる。図２１に示す例においては、スケジューリングにおいてグラントされた、あるいは割り当てられた時間リソースの前半と後半で、トランスポートブロック＃１にマッピングされる周波数リソースとトランスポートブロック＃２にマッピングされるリソースが切替る。
図２１において、リソース１８０４、領域２１０５、領域２１０６については、それぞれ、リソース１８０１、領域２１０２、領域２１０３と同様である。図２１において、リソース１８０７、領域２１０８、領域２１０９については、それぞれ、リソース１８０１、領域２１０２、領域２１０３と同様である。
図２１においても、図１８と同様、トランスポートブロック＃１より生成された物理チャンネルの信号がマッピングされる領域は、トランスポートブロック＃２より生成された物理チャンネルの信号がマッピングされる領域と入れ替わってもよい。前述のマッピングの入れ替わりは、スケジュール割り当て毎に行われてもよい。このことにより、例えば、基地局はスケジューリングを柔軟に実行可能となる。
図２１において、ある周波数リソースにおいて複製された各パケットがマッピングされる各時間リソースが集中的に配置される場合について示した。しかし、これらの時間リソースは分散的に配置されてもよい。例えば、マッピングされるパケットがシンボル毎に入れ替わってもよい。このことにより、例えば、両パケットの送信における時間ダイバーシチ効果を向上可能となる。
複製された両パケットのそれぞれを異なる時間リソースにマッピングする場合において、両パケットが同じスケジューリングリソースにおいて割り当てられる例について開示した。しかし、複製された両パケットは、異なるスケジューリングリソースにおいて割り当てられてもよい。このことにより、例えば、通信システムにおいて、スケジューリングに関する設計の複雑性を回避可能となる。
複製されたパケットのマッピングに関する他の方法を開示する。複製された両パケットのそれぞれが、異なるレイヤに空間多重されて送信されてもよい。複製された両パケットのそれぞれが、異なるコードブックを用いて空間多重されて送信されてもよい。各パケットの送受信に用いられる各トランスポートブロックが、互いに異なるレイヤに空間多重されて送信されてもよいし、互いに異なるコードブックを用いて空間多重されて送信されてもよい。このことにより、各パケットに対する周波数および／あるいは時間リソースの割り当てが不要となり、その結果、通信システムにおける設計の複雑性を回避可能となる。また、送信側装置は、複製した両パケットを同時に送信可能となり、その結果、例えば、パケットのＨＡＲＱ再送によって発生するレイテンシの揺らぎ、すなわち、ジッタを低減可能となる。
基地局はＵＥに対し、各パケットがマッピングされるレイヤに関する情報を通知してもよいし、各パケットに対して用いられるコードブックに関する情報を通知してもよい。ＵＥは、該情報を用いて、複製されたパケットを各レイヤにマッピングして基地局に送信してもよい。あるいはＵＥは、該情報を用いて、基地局より受信した信号から、複製された各パケットを抽出してもよい。他の例として、ＵＥは、基地局から通知されたコードブックに関する情報を用いて、複製されたパケットへの変調処理を行ってもよいし、基地局より受信した信号から、複製された各パケットを抽出してもよい。
複製されたパケットのマッピングに関する他の方法を開示する。複製された両パケットのそれぞれが符号多重されて送信されてもよい。該符号多重に用いられる符号は、例えば、直交符号（例：アダマール符号、ＺＣ（Zadoff-Chu）符号）であってもよいし、直交符号とは異なる符号であってもよい。このことにより、例えば、単一キャリア、単一レイヤを用いる場合においても、パケット複製を実行可能となる。その結果、信頼性を向上可能となる。
複製されたパケットのマッピングに関する他の方法を開示する。例えば、ある時間リソース（例えば、シンボル）において、両パケットのそれぞれが、異なる周波数リソースにマッピングされ、他の時間リソースにおいて、各パケットが割り当てられる周波数リソースが切替るとしてもよい。複製された両パケットが、スケジューリングにより割り当てられた同じ時間リソース内に割り当てられてもよい。このことにより、例えば、パケット複製において周波数ダイバーシチ効果および時間ダイバーシチ効果が得られ、その結果、通信の信頼性を向上可能となる。また、送信側装置は、複製した両パケットを同じスケジューリングリソース内で送信可能となり、その結果、例えば、パケットのＨＡＲＱ再送によって発生するレイテンシの揺らぎ、すなわち、ジッタを低減可能となる。
実施の形態１の本変形例１において開示した方法を、実施の形態１において開示した方法と組み合わせてもよい。例えば、同じキャリアにおいて、複数の設定済みグラントおよび／あるいは複数の設定済みスケジューリング割り当てを行ってもよい。パケット複製において複製された各パケットが、同じキャリアにおいて互いに異なる設定済みグラントおよび／あるいは互いに異なる設定スケジューリング割り当てにマッピングされて送信されてもよい。このことにより、例えば、通信システムにおける設計の複雑性を回避可能とするとともに、単一キャリアを用いる通信においても信頼性を向上可能となる。
実施の形態１の本変形例１において開示した方法を、ジッタ要件のない通信において用いてもよい。例えば、ジッタ要件のない通信において、同じキャリアを用いたパケット複製を行ってもよい。このことにより、例えば、単一キャリアを用いる通信においても信頼性を向上可能となる。
実施の形態１の本変形例１によって、単一キャリアを用いる通信においても、ジッタ特性を向上可能となる。
実施の形態１の変形例２．
実施の形態１および実施の形態１の変形例１においては、ＵＲＬＬＣの要件を満たす方法の例としてパケット複製が用いられる場合について開示したが、レペティション（repetition）が用いられてもよい。
しかし、レペティションにおいて、受信側装置からのＨＡＲＱフィードバック送信は、所定の反復回数の送信が終わった後に行われる。このことにより、受信側装置が、所定の反復回数の途中でデータを受信し、正しく復調および復号できた場合においても、受信側装置は、残りの回数分の受信を待ってからＨＡＲＱフィードバックを行うこととなる。受信側装置における受信データの上位レイヤ（例：ＲＬＣ）への転送についても同様である。その結果、該データの送信におけるレイテンシが悪化するという問題が生じる。
前述の問題に対する解決策を以下に開示する。
受信側装置は、レペティションが行われる送信において、データを正しく復号できた後にＨＡＲＱ－ＡＣＫを送信する。受信側装置は送信側装置へＨＡＲＱ－ＡＣＫを、所定の反復回数の途中で送信してもよい。このことにより、例えば、受信側装置はＨＡＲＱ－ＡＣＫを迅速に送信側装置に通知可能となる。
受信側装置は、レペティションが行われる送信において、データを正しく復号できた後に該データを上位レイヤ（例：ＲＬＣ）に転送してもよい。該転送は、例えば、所定の反復回数の途中で行われてもよい。このことにより、例えば、レペティションを用いた通信における信頼性を確保しつつ、レイテンシを低減可能となる。前述において、受信側装置から送信側装置に対するＨＡＲＱ－ＡＣＫ送信は、所定の反復回数の途中で行われてもよい。このことにより、例えば、受信側装置はＨＡＲＱ応答を送信側装置に迅速に通知可能となる。前述における他の例として、受信側装置は、ＨＡＲＱ－ＡＣＫ送信を、所定の反復回数が終了した後に行ってもよい。このことにより、例えば、ＨＡＲＱ－ＡＣＫ送信用に確保される周波数および／あるいは時間リソースを削減可能となる。その結果、通信システムにおける効率を向上可能となる。
受信側装置は、復号結果がＯＫとなったデータ以降の該データのレペティションを受信しないとしてもよい。このことにより、例えば、受信側装置における消費電力を削減可能となる。
送信側装置は、ＨＡＲＱ－ＡＣＫ受信後の該データのレペティションを送信しないとしてもよい。このことにより、例えば、送信側装置における消費電力を削減可能となるとともに、該データのレペティションに用いる時間および／あるいは周波数リソースを削減可能となる。
該ＨＡＲＱ－ＡＣＫの送信タイミングの候補は、規格で予め定められてもよい。例えば、所定の反復回数の毎回のタイミングが、ＨＡＲＱ－ＡＣＫ送信タイミングの候補として定められてもよい。あるいは、所定の反復回数において複数回（例えば、２回）毎のタイミングが、ＨＡＲＱ－ＡＣＫ送信タイミングの候補として定められてもよい。基地局は、ＨＡＲＱ－ＡＣＫ送信の候補となるタイミングにおける周波数および時間リソースを確保してもよい。基地局はＵＥに対して、該周波数および時間リソースを通知してもよい。該通知は、前述の反復回数に関する情報を含んでもよいし、通信の上りおよび／あるいは下りに関する情報を含んでもよい。ＵＥは、該通知に含まれる周波数および時間リソースにおいて、基地局に対してＨＡＲＱ－ＡＣＫを送信してもよいし、基地局から送信されるＨＡＲＱ－ＡＣＫを受信してもよい。基地局が該リソースを確保できない場合において、受信側装置はＨＡＲＱ－ＡＣＫを送信しないとしてもよい。
該ＨＡＲＱ－ＡＣＫの送信タイミングの候補の決定に関する他の例として、基地局が該候補を決定してＵＥに通知してもよい。基地局が決定する該タイミングの候補は、前述の、規格で定められる該タイミング候補と同様としてもよいし、他の方法で決められてもよい。基地局はＵＥに対して、該周波数および時間リソースを通知してもよい。該通知は、前述の反復回数に関する情報を含んでもよいし、通信の上りおよび／あるいは下りに関する情報を含んでもよいし、該ＨＡＲＱ－ＡＣＫ応答を適用する論理チャネルに関する情報を含んでもよいし、該応答に用いられるシーケンスに関する情報（例：巡回シフト（Cyclic shift））を含んでもよい。基地局は、該ＨＡＲＱ－ＡＣＫ応答に用いられる周波数および／あるいは時間リソースを予め確保してもよい。ＵＥは、該通知に含まれる周波数および時間リソースにおいて、基地局に対してＨＡＲＱ－ＡＣＫを送信してもよいし、基地局から送信されるＨＡＲＱ－ＡＣＫを受信してもよい。基地局が該リソースを確保できない場合において、受信側装置はＨＡＲＱ－ＡＣＫを送信しないとしてもよい。このことにより、例えば、通信システムにおける柔軟なスケジューリングが可能となる。
該ＨＡＲＱ－ＡＣＫの送信タイミングの候補に関する他の例として、所定の反復回数において所定の待ち回数以降の毎回のタイミングが、ＨＡＲＱ－ＡＣＫ送信タイミングの候補として定められてもよい。あるいは、所定の待ち回数以降（例えば、４回目以降）の複数回（例えば、２回）毎のタイミングが、ＨＡＲＱ－ＡＣＫ送信タイミングの候補として定められてもよい。所定の待ち回数は、例えば、ジッタ要件が定められている周期的な通信において、適時の送受信となる回数であってもよい。適時の送受信とは、所定のレイテンシとなる、すなわち、ジッタが生じない、タイミングにおいて行われる送受信であってもよい（以下、同様としてもよい）。このことにより、例えば、受信側装置における上位レイヤへの転送タイミング、および／あるいは、ＨＡＲＱ－ＡＣＫの送信タイミングにおけるばらつきを縮小可能となる。その結果、基地局とＵＥとの通信におけるジッタを低減可能となる。前述の候補は、規格で定められてもよいし、基地局が決定してＵＥに通知してもよい。
基地局は、適時となる送受信タイミングを決定してもよい。基地局はＵＥに対し、適時となる送受信タイミングに関する情報を通知してもよい。該通知には、ＲＲＣシグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよい。該情報は、例えば、送信周期に対するオフセットに関する情報であってもよいし、所定の送信周期において適時となる時刻に関する情報であってもよい。該情報は、周期に関する情報を含んでもよい。該オフセットに関する情報は、例えば、ミリ秒単位で与えられてもよいし、サブフレーム単位で与えられてもよいし、スロット単位で与えられてもよいし、シンボル単位で与えられてもよい。該オフセットに関する情報は、サブキャリア間隔に関する情報を含んでもよい。適時となる該時刻に関する情報は、例えば、ミリ秒単位の時刻として与えられてもよいし、サブフレーム番号で与えられてもよいし、スロット番号で与えられてもよいし、シンボル単位で与えられてもよい。ＵＥは、該情報を用いて、適時となる送受信タイミングを導出してもよい。例えば、ＵＥは、所定の送信周期において適時となる時刻に関する情報に、周期の整数倍を加算し、現在以降の送信周期において適時となる時刻を導出してもよい。他の例として、基地局はＵＥに対し、適時となる送受信時刻のみを通知するとしてもよい。該通知は、例えば、基地局とＵＥとの間で周期的な送信が行われない場合に適用してもよい。このことにより、例えば、ＵＥは適時となる送受信タイミングを導出可能となる。
基地局からＵＥに対する、適時となる送受信タイミングの通知には、例えば、実施の形態１における所定の該タイミングに関する情報の通知方法が用いられるとしてもよい。
ＵＥは、該通知に含まれる論理チャネルを含むトランスポートブロックに対して、本変形例２において開示したＨＡＲＱ応答を行うとしてもよい。ＵＥは、該論理チャネルを含まないトランスポートブロックに対して、本変形例２において開示したＨＡＲＱ応答を適用しないとしてもよい。このことにより、例えば、ＵＥにおける処理量を削減可能となる。
受信側装置が受信データを上位レイヤに転送するタイミングについても、ＨＡＲＱ－ＡＣＫ同様、規格で定められてもよいし、基地局が決定してＵＥに通知してもよい。該通知は、例えば、ＨＡＲＱ－ＡＣＫ応答タイミング候補に関する通知と同様の情報を含んでもよい。このことにより、例えば、データ送受信におけるレイテンシを低減可能となる。
図２２は、受信側装置が、レペティションにおける所定の反復回数の途中で、ＨＡＲＱフィードバックおよび上位レイヤへの転送を行う動作を示す図である。図２２は、送信データが４回繰り返されて送信される例について示している。また、図２２において、送信側装置からデータが送信される周期をＣｙｃｌｅ Ｔｉｍｅとして示している。図２２は、受信側装置から送信側装置へのＨＡＲＱ－ＡＣＫ送信における前述の待ち回数を２とした場合について示す。また、図２２において、所定のジッタ特性が要求される（以下、ジッタクリティカル（jitter-critical）と称する場合がある）通信において、所定の反復回数の途中でＨＡＲＱ応答および上位レイヤへの転送の動作が適用される場合について示す。図２２において、ジッタクリティカルな通信において適時となる受信タイミングを破線で示す。また、図２２は、送信側装置が基地局であり、受信側装置がＵＥである場合について示す。
図２２に示す最初の送信周期におけるデータ送信について、受信側装置は、２回目に送信されるデータ２５０１を復号結果ＯＫとして受信する。データ２５０１は適時の受信タイミング以降に受信されるので、受信側装置はデータ２５０１を上位レイヤに転送する。受信側装置は、データ２５０１の受信結果が復号ＯＫとなったことを用いて、送信側装置に対してＨＡＲＱ－ＡＣＫ信号２５０２を送信する。
図２２に示す２番目の送信周期におけるデータ送信について、受信側装置は、３回目に送信されるデータ２５０３を復号結果ＯＫとして受信する。データ２５０３は適時の受信タイミング以降に受信されるので、受信側装置はデータ２５０３を上位レイヤに転送する。受信側装置は、データ２５０３の受信結果が復号ＯＫとなったことを用いて、送信側装置に対してＨＡＲＱ－ＡＣＫ信号２５０４を送信する。
図２２に示す３番目の送信周期におけるデータ送信について、受信側装置は、１回目に送信されるデータ２５０５を復号結果ＯＫとして受信する。データ２５０５は適時の受信タイミングより前に受信されるので、受信側装置は、適時受信タイミングまでデータ２５０５を保持する。受信側装置は、適時受信タイミング経過後にデータ２５０５を上位レイヤに転送する。また、受信側装置は、データ２５０５の受信結果が復号ＯＫとなったことを用いて、送信側装置に対してＨＡＲＱ－ＡＣＫ信号２５０６を送信する。受信側装置はＨＡＲＱ－ＡＣＫ信号２５０６を、２回目のデータ受信に対するＨＡＲＱ－ＡＣＫ送信タイミングを待って、送信してもよい。
図２２に示す４番目の送信周期におけるデータ送信について、受信側装置は、４回目に送信されるデータ２５０７を復号結果ＯＫとして受信する。データ２５０７は適時の受信タイミング以降に受信されるので、受信側装置はデータ２５０７を上位レイヤに転送する。受信側装置は、データ２５０７の受信結果が復号ＯＫとなったことを用いて、送信側装置に対してＨＡＲＱ－ＡＣＫ信号２５０８を送信する。
図２２において、反復回数を４回とし、ＨＡＲＱ－ＡＣＫを送信するための所定の待ち回数を２回とした場合について示した。しかし、各種回数は他の値であってもよい。例えば、基地局とＵＥとの間の通信環境が悪い場合において、反復回数を４回よりも大きい値に設定してもよいし、待ち回数を２回より大きい値に設定してもよい。このことにより、例えば、レペティションを用いた通信において信頼性を向上可能となる。
図２２において、送信側装置が基地局であり、受信側装置がＵＥである場合、すなわち、下り通信である場合について示した。しかし、送信側装置がＵＥであり、受信側装置が基地局である場合、すなわち、上り通信であっても、図２２の例を応用可能である。他の例として、送信側装置も受信側装置もＵＥである場合、すなわち、サイドリンク通信であっても、図２２の例を応用可能である。このことにより、例えば、下り通信のみならず、上り通信および／あるいはサイドリンク通信においても、ジッタ特性を向上可能となる。
図２２において、受信側装置はＨＡＲＱ－ＡＣＫを、所定の待ち回数以降の受信に対するＨＡＲＱ－ＡＣＫとして送信する場合について示した。しかし、受信側装置は、復号ＯＫとなった時点で、ＨＡＲＱ－ＡＣＫを送信するとしてもよい。このことにより、例えば、復号ＯＫとなった以降のＨＡＲＱ－ＡＣＫ送信リソースを他の信号の送信に使用可能となる。その結果、通信システムにおける効率を向上可能となる。
ＨＡＲＱフィードバックが行われないとしてもよい。例えば、受信側装置は送信側装置に対し、ＨＡＲＱフィードバックを行わないとしてもよい。送信側装置は、送信したデータの全てが受信側装置において復号ＯＫとなったとみなしてもよい。ＨＡＲＱフィードバックを行わない動作は、例えば、レペティションが行われている場合に適用されてもよい。このことにより、例えば、基地局とＵＥとの間におけるシグナリング量が削減可能となるとともに、受信側装置のＨＡＲＱ処理における処理量を削減可能となる。また、このことにより、例えば、基地局はＨＡＲＱフィードバックに用いる周波数および時間リソースを確保不要となり、その結果、通信システムにおける周波数および時間リソースの利用効率を向上可能となる。
ＨＡＲＱフィードバックに関する他の例として、ＨＡＲＱ－ＮＡＣＫのみがフィードバックされるとしてもよい。例えば、受信側装置は送信側装置に対し、ＨＡＲＱ－ＮＡＣＫのみを送信するとしてもよいし、ＨＡＲＱ－ＡＣＫを送信しないとしてもよい。送信側装置は、ＨＡＲＱフィードバックが無かったデータの全てが受信側装置において復号ＯＫとなったとみなしてもよい。ＨＡＲＱ－ＮＡＣＫのみがフィードバックされる動作は、例えば、レペティションが行われている場合に適用されてもよい。このことにより、例えば、基地局とＵＥとの間におけるシグナリング量が削減可能となるとともに、受信側装置のＨＡＲＱ処理における処理量を削減可能となる。また、このことにより、基地局とＵＥとの間の通信における信頼性を向上可能となる。
受信側装置から送信側装置に対するＨＡＲＱフィードバック動作は、規格で予め定められてもよい。該フィードバック動作は、通信方法毎に定められてもよい。例えば、レペティション通信において、ＨＡＲＱ－ＮＡＣＫについてのみ、ＨＡＲＱフィードバックが行われるとしてもよい。また、パケット複製において、ＨＡＲＱフィードバックが行われるとしてもよい。
他の例として、受信側装置から送信側装置に対するＨＡＲＱフィードバック動作は、基地局によって決定されて、ＵＥに通知されてもよい。基地局は該フィードバックの動作を、通信方法毎に決めてもよい。例えば、レペティション通信において、ＨＡＲＱ－ＮＡＣＫについてのみ、ＨＡＲＱフィードバックが行われるとしてもよい。また、パケット複製において、ＨＡＲＱフィードバックが行われるとしてもよい。他の例として、基地局は該フィードバックの動作を、基地局とＵＥとの間の通信状況（例：ＱｏＳ）を用いて決めてもよいし、ネットワークスライシングに関する情報を用いて決めてもよい。例えば、ＳＩＮＲが良い場合において、ＨＡＲＱフィードバックが行われないとしてもよい。また、ＳＩＮＲが悪い場合において、ＨＡＲＱ－ＮＡＣＫのみがフィードバックされるとしてもよい。このことにより、例えば、通信システムにおける効率化が可能となる。
基地局からＵＥに対する該通知において、ＲＲＣシグナリングが用いられてもよい。このことにより、例えば、該通知における情報量を増大可能となる。他の例として、該通知において、ＭＡＣシグナリングが用いられてもよい。このことにより、例えば、ＨＡＲＱ再送による信頼性を確保しつつ、迅速な通知が可能となる。他の例として、Ｌ１／Ｌ２シグナリングが用いられてもよい。このことにより、例えば、基地局とＵＥとの間の通信状況を考慮した迅速な動作決定および迅速な通知が可能となる。
他の例として、受信側装置から送信側装置に対するＨＡＲＱフィードバック動作は、上位ＮＷ装置によって決定されて、ＵＥに対して通知されてもよい。該上位ＮＷ装置は、例えば、ＡＭＦであってもよいし、ＳＭＦであってもよい。上位ＮＷ装置は、該フィードバック動作を、例えば、ＵＥとの通信におけるＱｏＳ要件を用いて決めてもよいし、ネットワークスライシングに関する情報を用いて決めてもよい。該通知は、基地局経由で行われてもよい。該通知において、例えば、ＮＡＳシグナリングが用いられてもよい。このことにより、例えば、基地局とＵＥとの間でＱｏＳ要件に適った通信を実行可能となる。
実施の形態１の本変形例２により、レペティションを用いた通信における信頼性を確保しつつ、レイテンシを削減可能となる。また、ジッタを低減可能となる。
実施の形態１の変形例３．
所定のジッタ特性が要求される（以下、ジッタクリティカル（jitter-critical）と称する場合がある）通信におけるデータ送信と、他の通信におけるデータ送信との間の競合調整において、ＵＥは、ＭＡＣにおけるＬＣＰ（Logical Channel Prioritization）（非特許文献１７参照）を用いてもよい。前述の動作は、上り通信において適用されてもよい。
しかし、ＬＣＰにおいて、優先度を示すパラメータは準静的に与えられる（非特許文献２６（３ＧＰＰ ＴＳ３８．３３１ Ｖ１５．２．１）参照）。このため、例えば、他に優先度の高い論理チャネルのデータが存在する場合において、ＵＥは、ジッタクリティカルな論理チャネルよりも先に、優先度の高い該論理チャネルに、データを割り当てる。このことにより、ジッタクリティカルな論理チャネルにデータを割り当てることができない場合が発生し、その結果、ジッタ特性が悪化するといった問題が生じる。
前述の問題に対する解決策を以下に開示する。
ＵＥは、ジッタクリティカルな論理チャネルにデータを優先的に割り当てる。例えば、ＵＥのＭＡＣレイヤにおけるＬＣＰにおいて、ジッタクリティカルな論理チャネルが、ジッタクリティカルでない論理チャネルよりも、優先的にデータが割り当てられるとしてもよい。
ＬＣＰにおける優先的な該割り当ての例として、ＵＥが、ジッタクリティカルな論理チャネルにデータを優先度順に割り当て、残りの割り当て可能データサイズにおいて、ジッタクリティカルな論理チャネルにデータを優先度順に割り当てるとしてもよい。基地局はＵＥに対し、ジッタクリティカルな通信かどうかを示す情報を通知してもよい。該情報は、基地局からＵＥに送信されるＲＲＣ設定における、論理チャネル設定の中に含まれてもよい。ＵＥは、該情報を用いて、設定された論理チャネルがジッタクリティカルか否かを判断してもよい。このことにより、例えば、ＵＥは、ジッタクリティカルな論理チャネルを優先的に送信可能となり、その結果、ジッタを低減可能となる。
ＬＣＰにおける優先的な該割り当てに関する他の例として、ジッタクリティカルな論理チャネルに対して高い優先度が割り当てられるとしてもよい。ジッタクリティカルな論理チャネルに対して、ＬＣＰにおいて優先度を示すパラメータのうち最高優先度を表す値が割り当てられてもよい。あるいは、最高優先度から順に所定の数までの範囲の値のいずれかが、ジッタクリティカルな論理チャネルに対して、割り当てられるとしてもよい。このことにより、例えば、前述の効果に加えて、基地局はＵＥに対して、ジッタクリティカルな通信かどうかを示す情報を通知不要となり、その結果、通信システムにおける複雑性を回避可能となる。
他の解決策を開示する。ＵＥは、ジッタクリティカルな論理チャネルについて、適時となる送信タイミングにおいて、該論理チャネルのデータを自ＵＥのＭＡＣレイヤに転送する。ＵＥは、適時となる送信タイミングまでの間、ジッタクリティカルな論理チャネルのデータをＭＡＣレイヤに転送せず保持するとしてもよい。このことにより、例えば、決定論的レイテンシ（deterministic latency）、すなわち、レイテンシを一定以上一定以内、といった形で求められる通信において、レイテンシを一定範囲内に収めることが可能となる。
基地局は、適時となる送受信タイミングを決定してもよい。基地局はＵＥに対し、適時となる送受信タイミングに関する情報を通知してもよい。該通知には、ＲＲＣシグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよい。該情報は、例えば、送信周期に対するオフセットに関する情報であってもよいし、所定の送信周期において適時となる時刻に関する情報であってもよい。該情報は、周期に関する情報を含んでもよい。該オフセットに関する情報は、例えば、ミリ秒単位で与えられてもよいし、サブフレーム単位で与えられてもよいし、スロット単位で与えられてもよいし、シンボル単位で与えられてもよい。該オフセットに関する情報は、サブキャリア間隔に関する情報を含んでもよい。適時となる該時刻に関する情報は、例えば、ミリ秒単位の時刻として与えられてもよいし、サブフレーム番号で与えられてもよいし、スロット番号で与えられてもよいし、シンボル単位で与えられてもよい。ＵＥは、該情報を用いて、適時となる送受信タイミングを導出してもよい。例えば、ＵＥは、所定の送信周期において適時となる時刻に関する情報に、周期の整数倍を加算し、現在以降の送信周期において適時となる時刻を導出してもよい。他の例として、基地局はＵＥに対し、適時となる送受信時刻のみを通知するとしてもよい。該通知は、例えば、基地局とＵＥとの間で周期的な送信が行われない場合に適用してもよい。このことにより、例えば、ＵＥは適時となる送受信タイミングを導出可能となる。
該転送の動作あるいは該保持の動作は、上位レイヤ（例えば、アプリケーションレイヤであってもよいし、サービスレイヤと称するレイヤであってもよい。）において行われてもよいし、ＳＤＡＰにおいて行われてもよいし、ＰＤＣＰにおいて行われてもよいし、ＲＬＣにおいて行われてもよい。
他の例として、ＭＡＣレイヤ自身が該論理チャネルのデータを保持してもよい。例えば、ＬＣＰにおいて、所定のタイミングにおいてのみ、ジッタクリティカルな論理チャネルの割り当てが行われるとしてもよい。所定の該タイミングは、該論理チャネルにおいて適時な送信となるタイミングより前のタイミング範囲を含まないとしてもよい。このことにより、例えば、適時より前においてジッタクリティカルな論理チャネルが割り当てられるのを防止可能となり、その結果、ジッタ特性を向上可能となる。
所定の該タイミングは、規格で予め定められてもよい。例えば、所定の該タイミングは、ジッタ許容範囲となるタイミングと同一であってもよいし、ジッタ許容範囲となるタイミングの一部（例：適時から、ジッタ許容範囲の後端までのタイミング）であってもよい。基地局はＵＥに対し、所定の該タイミングを導出するための情報を通知してもよい。所定の該タイミングを導出するための情報は、例えば、ＱｏＳパラメータに含まれてもよいし、基地局からＵＥに送信されるＲＲＣ設定に含まれる論理チャネル設定に含まれてもよい。ＱｏＳパラメータは、実施の形態１において開示したＱｏＳパラメータと同様であってもよい。所定の該タイミングを導出するための情報は、例えば、ジッタ許容範囲に関する情報であってもよい。ジッタ許容範囲に関する情報は、例えば、絶対時間（例：ミリ秒単位、マイクロ秒単位）で与えられてもよいし、サブフレーム数で与えられてもよいし、スロット数で与えられてもよい。あるいは、ジッタ許容範囲に関する情報は、該論理チャネルにおけるデータ送信周期（例えば、Ｃｙｃｌｅ Ｔｉｍｅ）を用いた情報（例：データ送信周期に対する割合）として与えられてもよい。あるいは、ジッタ許容範囲に関する情報は、他の方法で与えられてもよい。ＵＥが所定の該タイミングを導出するための情報として、データ送信周期の情報が含まれてもよいし、適時送信となるタイミングに関する情報（例：スロット番号を用いた情報、シンボル番号を用いた情報）が含まれてもよい。このことにより、例えば、ＵＥにおける所定の該タイミング導出に関して、基地局からＵＥへのシグナリング量を削減可能となる。
所定の該タイミングを、基地局が決定してＵＥに通知してもよい。このことにより、例えば、通信システムにおける柔軟なスケジューリングが可能となる。
基地局はＵＥに対し、所定の該タイミングに関する情報を通知してもよい。該タイミングに関する情報は、例えば、前述の、ＵＥが所定の該タイミングを導出するための情報と同様としてもよい。所定の該タイミングの通知には、例えば、実施の形態１において開示した方法が用いられるとしてもよい。
他の解決策を開示する。複数のジッタクリティカルな論理チャネル間の割り当てにおいて、ジッタ許容範囲が狭い順に割り当てを行うとしてもよい。このことにより、例えば、ジッタ許容範囲が広く優先度の高い論理チャネルと、ジッタ許容範囲が狭く優先度が低い論理チャネルが共存する場合において、ジッタ許容範囲が狭く優先度が低い論理チャネルへの割り当てが可能となる。その結果、ジッタ特性を満足可能となる。
他の例として、ＵＥは、スケジューリング対象のタイミング（例：スロット、ミニスロット、シンボル）から、ジッタ許容範囲を満足可能な時間範囲の後端までの時間が短い順に、論理チャネルを割り当てるとしてもよい。このことにより、例えば、ジッタクリティカルな複数の論理チャネルが異なるタイミングに存在する場合においても、該論理チャネルのジッタ特性を満足可能となる。
他の例として、基地局は、ジッタ許容範囲が狭い論理チャネルに対し、高い優先度を設定するとしてもよい。このことにより、例えば、通信システムの設計における複雑性を回避可能となる。
他の例として、ＵＥは、各論理チャネルにおいて送信可能なデータのサイズを用いて論理チャネル割り当てを決定するとしてもよい。該サイズは、例えば、送信可能なＲＬＣ ＰＤＵのサイズであってもよいし、ＰＤＣＰ ＰＤＵのサイズであってもよいし、ＳＤＡＰ ＰＤＰのサイズであってもよいし、ＳＤＡＰ ＳＤＵのサイズであってもよいし、前述のうち複数の和であってもよい。ＵＥは、例えば、該サイズが大きい順に論理チャネルを割り当てるとしてもよい。このことにより、例えば、通信システムにおけるデータの滞留を減少可能となる。
ジッタクリティカルな論理チャネルとレイテンシ要件がある論理チャネルとの間の割り当てについて、前述の方法を適用してもよい。ＵＥは、ジッタクリティカルな論理チャネルにおけるジッタ許容範囲を、レイテンシ要件に置き換えて適用してもよい。例えば、ＵＥは、スケジューリング対象のタイミング（例：スロット、ミニスロット、シンボル）から、レイテンシ要件および／あるいはジッタ許容範囲を満足可能な時間範囲の後端までの時間が短い順に、論理チャネルを割り当てるとしてもよい。このことにより、例えば、ジッタクリティカルな論理チャネルにおけるジッタ特性と、レイテンシ要件がある論理チャネルのレイテンシ要件の両方を満足可能となる。
他の例として、基地局は、ジッタ許容範囲および／あるいはレイテンシ要件が狭い論理チャネルに対し、高い優先度を設定するとしてもよい。例えば、ＵＥは、ジッタクリティカルな論理チャネルにおけるジッタ許容範囲を、レイテンシ要件に置き換えてもよい。該置き換えにおいて、例えば、ジッタ許容範囲の前端から後端までの時間を、ジッタクリティカルな該論理チャネルにおけるレイテンシ要件としてもよいし、ジッタ許容範囲の中央から後端までの時間を、該レイテンシ要件としてもよい。このことにより、例えば、通信システムの設計における複雑性を回避可能となる。
前述の、ジッタ許容範囲および／あるいはレイテンシ要件に関する情報は、ＱｏＳパラメータに含まれてもよいし、基地局からＵＥに送信されるＲＲＣ設定に含まれる論理チャネル設定に含まれてもよい。該ＱｏＳパラメータは、基地局からＵＥに通知されてもよいし、上位ＮＷ装置から基地局経由でＵＥに通知されてもよいし、上位ＮＷ装置から基地局に対して通知されてもよい。ＱｏＳパラメータは、実施の形態１において開示したＱｏＳパラメータと同様であってもよい。
通信システムにおいて、所定の閾値よりも緩いレイテンシ要件については、レイテンシ要件がないとみなしてもよい。該閾値は、予め規格で定められてもよいし、基地局が決定してＵＥに通知してもよいし、上位ＮＷ装置が決定して基地局に通知してもよい。基地局は上位ＮＷ装置が決定した該閾値をＵＥに通知してもよいし、通知しないとしてもよい。このことにより、例えば、通信システムにおける複雑性を回避可能となる。
レイテンシ要件がある複数論理チャネルの間の割り当てについて、前述の方法を適用してもよい。例えば、ＵＥは、レイテンシ要件までの時間が短い順に、論理チャネルを割り当てるとしてもよい。レイテンシ要件に関する情報についても、前述と同様としてもよい。このことにより、例えば、該複数の論理チャネルにおいて、レイテンシ要件を満足可能となる。
図２３は、ジッタクリティカルな論理チャネルとレイテンシ要件がある論理チャネルの両方が存在する場合のＬＣＰの動作を示す図である。図２３において、ＬＣＨ＃１は、レイテンシ要件がある論理チャネルであり、ＬＣＨ＃２は、ジッタクリティカルな論理チャネルである。
図２３において、まず、スケジューリング単位２８０１への論理チャネルの割り当てを説明する。ＬＣＨ＃１における許容レイテンシは、ＬＣＨ＃２におけるジッタ許容範囲後端までの時間より短い。このことを用いて、ＵＥは、ＬＣＨ＃１のデータ２８０２を、スケジューリング単位２８０１へ割り当てる。
図２３において、スケジューリング単位２８０１の次のスケジューリング単位２８０３への論理チャネルの割り当てを説明する。ＬＣＨ＃２の他に、レイテンシ要件がある論理チャネル、および、ジッタクリティカルな論理チャネルのデータがない。このことから、ＵＥは、ＬＣＨ＃２のデータ２８０４を、スケジューリング単位２８０３へ割り当てる。
他の解決策を開示する。優先度を可変としてもよい。例えば、ジッタクリティカルな通信において、ジッタ許容範囲における優先度を高めてもよい。例えば、ＵＥは、非特許文献１７に示されるプライオリティ（Ｐｒｉｏｒｉｔｙ）値から所定の値（以下、優先度のオフセットと称する場合がある）を減じることで、該論理チャネルにおける優先度を高めてもよい。
減じたプライオリティ値が所定の閾値未満とならないようにしてもよい。ＵＥは、減じたプライオリティ値が所定の閾値未満となる場合において、減じたプライオリティ値を所定の閾値と同じ値としてもよい。所定の閾値は、規格で定められてもよいし、基地局が決定してＵＥに通知してもよい。このことにより、例えば、減じたプライオリティ値が規格で定められる範囲から外れることを防止可能となる。その結果、ＬＣＰにおける誤動作を防止可能となる。他の例として、優先度のオフセットにおいて、優先度を過剰に高くすることを防止可能となる。
優先度のオフセットは、ジッタ許容範囲内で一律の値であってもよい。このことにより、例えば、ＬＣＰにおける設計の複雑性を回避可能となる。
他の例として、優先度のオフセットを、ジッタ許容範囲内で可変としてもよい。例えば、ジッタ許容範囲内において、適時となる受信タイミング以降における優先度のオフセットを、適時となる受信タイミングより前における優先度のオフセットよりも、高い値としてもよい。このことにより、例えば、ＨＡＲＱ再送発生時においても、該再送を優先的に送信可能とし、その結果、ジッタ特性の向上可能となる。
優先度のオフセットを、スケジューリング単位となる時間毎に与えてもよい。例えば、ジッタ許容範囲内において、後の時間になるほど高い値の優先度のオフセットを設定してもよい。このことにより、例えば、前述の効果に加えて、ＬＣＰにおける論理チャネル割り当てを柔軟に実行可能となる。スケジューリング単位となる時間は、サブフレームであってもよいし、スロットであってもよいし、ミニスロットであってもよいし、シンボルであってもよい。
優先度のオフセットは、規格で予め定められてもよい。例えば、一律のオフセット量が定められてもよい。あるいは、スケジューリングタイミング毎のオフセット量が定められてもよい。あるいは、タイミングの範囲とオフセット量の対応付けが定められてもよい。タイミングの範囲とオフセット量の対応付けの例として、ジッタ許容範囲の前端から後端までの範囲を分割し、分割したそれぞれに対してオフセット量が定められるとしてもよい。例えば、ジッタ許容範囲の前端から中央までの範囲におけるオフセット量と、ジッタ許容範囲の中央から後端までの範囲におけるオフセット量が定められてもよい。
優先度のオフセットが適用される論理チャネルが、規格で予め定められてもよい。例えば、優先度のオフセットが、ジッタクリティカルな論理チャネル、および／あるいは、所定の閾値以下のレイテンシ要件を持つ論理チャネルに対して適用されるとしてもよい。このことにより、例えば、該論理チャネルの優先度を他の論理チャネルよりも高くすることが可能となる。その結果、ジッタ要件および／あるいはレイテンシ要件を満足可能となる。
他の例として、優先度のオフセットを基地局が決めてＵＥに通知してもよい。該通知には、例えば、ＲＲＣシグナリングが用いられてもよい。該通知は、論理チャネルに関する情報を含んでもよい。該情報は、オフセット量に関する情報を含んでもよい。ＵＥは、該通知に含まれる論理チャネルに対して、該通知に含まれるオフセットを適用してもよい。オフセット量に関する該情報は、規格で予め定められるオフセット量と同様の情報であってもよい。このことにより、例えば、基地局はＵＥに対して多くの情報を通知可能となるため、優先度のオフセット設定における柔軟性を向上可能となる。
該通知に関する他の例として、ＭＡＣシグナリングが用いられてもよい。該通知は、論理チャネルに関する情報を含んでもよいし、オフセットに関する情報を含んでもよい。オフセットに関する該情報は、規格で予め定められるオフセット量と同様の情報であってもよい。ＵＥは、該通知に含まれる論理チャネルに対して、該通知に含まれるオフセットを適用してもよい。このことにより、例えば、ＵＥは該オフセットを迅速に適用可能となる。
該通知に関する他の例として、Ｌ１／Ｌ２シグナリングが用いられてもよい。該通知は、論理チャネルに関する情報を含んでもよいし、オフセットに関する情報を含んでもよい。該通知は、スケジューリンググラントを含むＤＣＩに含まれてもよいし、異なるＤＣＩに含まれてもよい。また、該通知は、異なるＬ１／Ｌ２シグナリングであってもよい。オフセットに関する該情報は、規格で予め定められるオフセット量と同様の情報であってもよいし、前述のグラントにおいて適用されるオフセット量であってもよい。このことにより、例えば、ＵＥは該オフセットをさらに迅速に適用可能となる。
オフセット量に関する該情報が複数設けられてもよい。複数の該情報は、規格で定められてもよいし、基地局が決定してＵＥに通知してもよいし、上位ＮＷ装置が決定して基地局経由でＵＥに通知してもよい。基地局はＵＥに対し、複数の該情報のうち、使用される情報の識別子を通知してもよい。該識別子の通知には、ＲＲＣシグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよい。該通知は、オフセットが適用される論理チャネルに関する情報を含んでもよい。ＵＥは、該識別子を用いて、使用する情報を導出してもよい。基地局は、使用する情報の決定にあたり、上位ＮＷ装置からの設定、例えば、ＱｏＳパラメータを用いてもよいし、ネットワークスライシングに関する情報を用いて決めてもよい。このことにより、例えば、基地局からＵＥに対するシグナリング量を削減可能となる。
図２４は、ジッタクリティカルな論理チャネルにおける優先度のオフセット付与について示した図である。図２４は、ジッタ許容範囲内において優先度のオフセットをスケジューリング単位となる時間毎に設定する場合について示している。図２４において、ジッタ許容範囲外においては、優先度のオフセット付与を行わない。
図２４において、ジッタ許容範囲内の前端となるスケジューリングタイミングから、適時となるタイミングにおいて、優先度のオフセットが単調増加で設定されている。図２４において、適時となるタイミングから、ジッタ許容範囲の後端となるスケジューリングタイミングにおいては、優先度のオフセットとして一律の値が設定されている。
図２４において、優先度のオフセットをスケジューリング単位となる時間毎に設定する場合について示した。しかし、ジッタ許容範囲内の優先度のオフセットとして一律の値が設定されてもよい。このことにより、例えば、ＵＥのＬＣＰの処理における設計の複雑性を回避可能となる。
ジッタ許容範囲外においても、優先度にオフセットを与えるとしてもよい。例えば、ジッタ許容範囲外において優先度を下げてもよい。このことにより、ジッタ許容範囲外において、該論理チャネルが割り当てられる可能性を低下可能となり、その結果、ジッタ特性を向上可能となる。
他の例として、ジッタ許容範囲の前端より前において優先度を下げ、後端より後ろにおいて優先度を上げてもよい。ジッタ許容範囲の後端の直後から、次の送信周期におけるジッタ許容範囲の前端の直前までの範囲において、優先度のオフセットを単調減少で与えてもよい。このことにより、ジッタ特性を向上しつつ、該論理チャネルにおけるデータ滞留を防止可能となる。
図２５は、ジッタクリティカルな論理チャネルにおける優先度のオフセット付与における他の例について示した図である。図２５において、ジッタ許容範囲内における優先度のオフセットは、図２４と同様である。
図２５において、ジッタ許容範囲外においても優先度のオフセットが付与されている。ジッタ許容範囲外における優先度のオフセットは、優先度を下げる方向のオフセットである。図２５において、ジッタ許容範囲外における優先度のオフセットとして、一律の値が設定されている。
図２５において、図２４と同様、ジッタ許容範囲内の優先度のオフセットとして一律の値が設定されてもよい。このことにより、例えば、ＵＥのＬＣＰの処理における設計の複雑性を回避可能となる。
図２５において、ジッタ許容範囲外における優先度のオフセットを一律な値とする場合について示した。しかし、該オフセットをスケジューリング単位毎に可変としてもよい。例えば、ジッタ許容範囲の前端より前において優先度を下げ、後端より後ろにおいて優先度を上げてもよい。ジッタ許容範囲の後端の直後から、次の送信周期におけるジッタ許容範囲の前端の直前までの範囲において、優先度のオフセットを単調減少で与えてもよい。このことにより、ジッタ特性を向上しつつ、該論理チャネルにおけるデータ滞留を防止可能となる。
優先度へのオフセット付与を、レイテンシ要件がある論理チャネルに適用してもよい。レイテンシ要件がある論理チャネルにおけるオフセット量の設定方法および該設定の通知方法は、ジッタクリティカルな論理チャネルにおけるオフセットと同様としてもよい。タイミングの範囲とオフセット量の対応付けの例として、データ発生時から、レイテンシ要件を満たす後端の送信タイミングまでの範囲を分割し、分割したそれぞれに対してオフセット量が定められるとしてもよい。このことにより、例えば、レイテンシ要件のある論理チャネルに対しても、レイテンシ要件を満たした通信が可能となる。
図２６は、レイテンシ要件がある論理チャネルにおける優先度のオフセット付与について示した図である。図２６は、レイテンシ許容範囲内において、優先度のオフセットをスケジューリング単位となる時間毎に設定する場合について示している。図２６において、レイテンシ許容範囲の起点となる時間は、上りデータ発生時間としている。
図２６に示す例において、データ発生時におけるスケジューリングタイミングから、レイテンシ許容範囲の後端の３つ前のスケジューリングタイミングまでの区間において、優先度のオフセットが時間とともに増加するよう設定されている。図２６において、レイテンシ許容範囲の後端の３つ前のスケジューリングタイミングから、レイテンシ許容範囲の後端までは、優先度のオフセットとして一律の値が設定されている。図２６において、レイテンシ許容範囲外においては、優先度のオフセット付与を行わない。
図２６において、優先度のオフセットをスケジューリング単位となる時間毎に設定する場合について示した。しかし、レイテンシ許容範囲内の優先度のオフセットとして一律の値が設定されてもよい。このことにより、例えば、ＵＥのＬＣＰの処理における設計の複雑性を回避可能となる。
図２６において、優先度のオフセットを、レイテンシ許容範囲内においてのみ設定する例を示した。しかし、レイテンシ許容範囲以降において、優先度のオフセットを設定するとしてもよい。このことにより、例えば、レイテンシ許容範囲以降においてもＵＥはデータを迅速に基地局に送信可能となり、その結果、ＵＥにおけるデータの滞留を防止可能となる。
優先度のオフセットが、設定済みグラントを用いたスケジューリングに適用されてもよい。設定済みグラントにおける優先度のオフセットの適用方法は、実施の形態１の本変形例３において開示した方法と同様としてもよい。このことにより、例えば、設定済みグラントを用いるスケジューリングにおいても、ジッタ特性を満足可能となる。
ジッタクリティカルな論理チャネルが、ジッタクリティカルでない論理チャネルに切替わってもよい。ジッタクリティカルでない論理チャネルが、ジッタクリティカルな論理チャネルに切替わってもよい。
該切替えの判断を基地局が行ってもよい。基地局はＵＥに対し、該切替えに関する情報を通知してもよい。該通知には、例えば、ＲＲＣシグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよい。
他の例として、該切替えの判断を、上位ＮＷ装置が行ってもよい。上位ＮＷ装置はＵＥに対し、該切替えに関する情報を通知してもよい。該通知には、例えば、ＮＡＳシグナリングが用いられてもよい。該切替えの通知は、基地局経由で行われてもよい。
他の例として、該切替えの判断を、ＵＥが行ってもよい。ＵＥは、該切替えに関する情報を、基地局に通知してもよいし、上位ＮＷ装置に通知してもよい。該切替えに関する決定を、基地局が行ってもよいし、上位ＮＷ装置が行ってもよい。基地局および／あるいは上位ＮＷ装置は、該決定に関する情報をＵＥに通知してもよい。
前述の切替えの通知は、論理チャネルに関する情報を含んでもよいし、切替え後のＱｏＳに関する情報を含んでもよい。ＱｏＳに関する情報は、例えば、ジッタ特性に関する情報であってもよいし、レイテンシ要件に関する情報であってもよい。
実施の形態１の本変形例３によって、ジッタクリティカルな通信と他の通信の両方が存在する場合においても、ジッタ特性を向上可能となる。
実施の形態１の変形例４．
ジッタクリティカルな通信において、ジッタ許容範囲から外れたデータを破棄するとしてもよい。該破棄は、上り通信において行われてもよいし、下り通信において行われてもよい。レイテンシ要件がある通信においても、同様としてもよい。
該破棄において、ジッタ許容範囲とは異なる閾値が用いられてもよい。例えば、ジッタ許容範囲よりも広い範囲が設けられてもよい。該広い範囲から外れたデータが破棄されるとしてもよい。レイテンシ要件がある通信においても、同様としてもよい。
該破棄の動作は、送信側装置において行われてもよい。該破棄の動作は、送信側装置のアプリケーションレイヤが行ってもよいし、ＳＤＡＰレイヤが行ってもよいし、ＰＤＣＰレイヤが行ってもよい。ＰＤＣＰレイヤが該破棄の動作を行うにあたり、ＰＤＣＰ ＳＤＵを破棄してもよい。ＰＤＣＰ ＳＤＵの破棄は、例えば、該ＰＤＣＰ ＳＤＵが下位レイヤ（例：ＲＬＣレイヤ）に転送される前において行われるとしてもよい。他の例として、ＰＤＣＰ ＰＤＵが破棄されるとしてもよい。ＰＤＣＰ ＰＤＵの破棄は、例えば、該ＰＤＣＰ ＰＤＵが下位レイヤ（例：ＲＬＣレイヤ）に転送済みである場合において行われるとしてもよい。ＰＤＣＰレイヤがＰＤＣＰ ＰＤＵの破棄を行うにあたり、該ＰＤＣＰ ＰＤＵの送達確認が取れたとみなしてもよい。ＰＤＣＰレイヤにおける送信ウィンドウが進められてもよい。他の例として、ＰＤＣＰ ＳＤＵの破棄とＰＤＣＰ ＰＤＵの破棄が組み合わせて用いられてもよい。
他の例として、該破棄の動作を、送信側装置のＲＬＣレイヤが行ってもよい。ＲＬＣレイヤが該破棄の動作を行うにあたり、ＲＬＣ ＳＤＵを破棄してもよい。ＲＬＣ ＳＤＵの破棄は、例えば、該ＲＬＣ ＳＤＵが下位レイヤ（例：ＭＡＣレイヤ）に転送される前において行われるとしてもよい。他の例として、ＲＬＣ ＰＤＵが破棄されるとしてもよい。ＲＬＣ ＰＤＵの破棄は、例えば、該ＲＬＣ ＰＤＵが下位レイヤ（例：ＭＡＣレイヤ）に転送済みである場合において行われるとしてもよい。ＲＬＣレイヤがＲＬＣ ＰＤＵの破棄を行うにあたり、該ＲＬＣ ＰＤＵの送達確認が取れたとみなしてもよい。ＲＬＣレイヤにおける送信ウィンドウが進められてもよい。他の例として、ＲＬＣ ＳＤＵの破棄とＲＬＣ ＰＤＵの破棄が組み合わせて用いられてもよい。
他の例として、該破棄の動作を、送信側装置のＭＡＣレイヤが行ってもよい。ＭＡＣレイヤが該破棄の動作を行うにあたり、ＬＣＰの処理において該破棄の動作が行われるとしてもよい。
送信側装置の各レイヤにおける該破棄の動作が組み合わせて用いられてもよい。例えば、ＰＤＣＰレイヤがＰＤＣＰ ＳＤＵおよびＰＤＣＰ ＰＤＵを破棄し、ＲＬＣレイヤがＲＬＣ ＰＤＵを破棄するとしてもよい。このことにより、例えば、前述の各レイヤにおけるデータの滞留を防止可能となる。
他の例として、該破棄の動作は、受信側装置において行われてもよい。該破棄の動作は、受信側装置のアプリケーションレイヤが行ってもよいし、ＳＤＡＰレイヤが行ってもよいし、ＰＤＣＰレイヤが行ってもよい。ＰＤＣＰレイヤが該破棄の動作を行うにあたり、ＰＤＣＰ ＰＤＵを破棄してもよい。ＰＤＣＰ ＰＤＵの破棄において、ＰＤＣＰレイヤは該ＰＤＣＰ ＰＤＵを正常受信（ＡＣＫ）とみなしてもよい。ＰＤＣＰレイヤは該ＰＤＣＰ ＰＤＵの破棄にあたり、ＰＤＣＰレイヤの受信ウィンドウを進めてもよい。
他の例として、該破棄の動作は、受信側装置のＲＬＣレイヤにおいて行われてもよい。ＲＬＣレイヤが該破棄の動作を行うにあたり、ＲＬＣ ＰＤＵを破棄してもよい。ＲＬＣ ＰＤＵの破棄において、ＲＬＣレイヤは該ＲＬＣ ＰＤＵを正常受信（ＡＣＫ）とみなしてもよい。ＲＬＣレイヤは該ＲＬＣ ＰＤＵの破棄にあたり、ＲＬＣレイヤの受信ウィンドウを進めてもよい。
他の例として、該破棄の動作は、受信側装置のＭＡＣレイヤにおいて行われてもよい。ＭＡＣレイヤが該破棄の動作を行うにあたり、受信したトランスポートブロックを破棄してもよい。他の例として、該トランスポートブロックから抽出した論理チャネルデータを破棄してもよい。このことにより、例えば、ジッタクリティカルな論理チャネルと他の論理チャネルが同じトランスポートブロックに多重されている場合においても、他の論理チャネルの破棄によるパケットロスを防止可能となる。
該破棄の動作にあたり、受信側装置のＭＡＣレイヤは、破棄するトランスポートブロックにおけるＨＡＲＱフィードバックとして、ＨＡＲＱ－ＡＣＫを送信してもよい。
受信側装置の各レイヤにおける該破棄の動作が組み合わせて用いられてもよい。このことにより、例えば、受信側装置の各レイヤにおけるデータの滞留を防止可能となる。
他の例として、該破棄の動作は、送信側装置と受信側装置の両方において行われてもよい。送信側装置と受信側装置の両方において該破棄の動作が行われるにあたり、実施の形態１の本変形例４において開示した方法が組み合わせて用いられてもよい。このことにより、例えば、通信システムにおけるメモリ使用量を削減可能となる。
該破棄の動作は、規格により予め定められてもよい。例えば、該破棄の有無が定められてもよいし、該破棄を行う主体（例：送信側装置および／あるいは受信側装置）が定められてもよい。
該破棄の動作が、ＱｏＳパラメータを用いて決められてもよい。ＱｏＳパラメータに含まれる情報は、例えば、ジッタ許容範囲に関する情報であってもよいし、レイテンシ要件に関する情報であってもよいし、前述の広い範囲に関する情報であってもよい。ネットワークスライシングに関する情報（例：ＮＳＳＡＩ(Network Slice Selection Assistance Information)）が用いられてもよい。
他の例として、該破棄の動作は、基地局において決められてＵＥに通知されてもよい。該通知には、ＲＲＣシグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよいし、前述のうち複数の組み合わせが用いられてもよい。
他の例として、該破棄の動作は、上位ＮＷ装置において決められてＵＥに通知されてもよい。該通知は、基地局を経由して行われてもよい。該通知には、例えば、ＮＡＳシグナリングが用いられてもよい。あるいは、該通知には、例えば、上位ＮＷ装置と基地局との間のインタフェースに用いられるシグナリングと、前述の、基地局からＵＥへの通知に用いられるシグナリングが組み合わせて用いられてもよい。
基地局および／あるいは上位ＮＷ装置からＵＥに対して通知される該情報は、該破棄の動作が行われるデータを識別する情報を含んでもよい。データを識別する該情報は、例えば、ＰＤＵセッションであってもよいし、ベアラであってもよいし、論理チャネルであってもよいし、ＱｏＳフローであってもよいし、ネットワークスライシングに関する情報であってもよいし、前述のうち複数の組み合わせであってもよい。
他の例として、該情報は、該破棄の動作が行われるＱｏＳの条件（例：閾値）に関する情報を含んでもよい。ＵＥは、該条件を満たすデータについて、該破棄の動作を行うとしてもよい。他の例として、ＵＥは、該条件を満たさないデータについて、該破棄の動作を行うとしてもよい。
他の例として、該情報は、前述の広い範囲に関する情報を含んでもよい。
受信側装置は、ジッタが発生しないタイミングまでデータを保持するとしてもよい。受信側装置は、該タイミングにおいてデータを上位レイヤに転送してもよい。該データの保持は、例えば、アプリケーションレイヤにて行われてもよいし、アプリケーションレイヤへの入力端において行われてもよいし、ＳＤＡＰにおいて行われてもよいし、ＰＤＣＰレイヤにおいて行われてもよいし、ＲＬＣレイヤにおいて行われてもよいし、ＭＡＣレイヤにおいて行われてもよい。レイテンシ要件があるデータについても、同様としてもよい。例えば、受信側装置は、所定のレイテンシとなるタイミングまでデータを保持するとしてもよい。受信側装置は、該タイミングにおいて受信データを上位レイヤに転送してもよい。このことにより、例えば、通信システムを通してのジッタ特性を向上可能となる。
基地局はＵＥに対し、該タイミングに関する情報を通知してもよい。該通知には、ＲＲＣシグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよい。
送信側装置は、送信データの送信時刻に関する情報を通知してもよいし、受信側装置が受信すべき時刻に関する情報を通知してもよい。受信すべき該時刻は、例えば、受信側装置が上位レイヤにデータを転送すべき時刻であってもよい。該時刻は、例えば、ミリ秒単位の時刻であってもよいし、サブフレーム番号を用いた時刻であってもよいし、スロット番号を用いた時刻であってもよいし、ミニスロット番号を用いた時刻であってもよいし、シンボル番号を用いた時刻であってもよいし、前述のうち複数を組み合わせた時刻であってもよい。送信側装置は、例えば、該送信データにタイムスタンプを付与してもよい。該タイムスタンプは、前述の時刻と同様の情報であってもよい。該タイムスタンプは、上位レイヤにおいて付与されてもよいし、ＳＤＡＰにおいて付与されてもよいし、ＰＤＣＰにおいて付与されてもよいし、ＲＬＣにおいて付与されてもよいし、ＭＡＣにおいて付与されてもよい。他の例として、該送信時刻に関する情報が、ＲＲＣシグナリングを用いて通知されてもよいし、ＭＡＣシグナリングを用いて通知されてもよいし、Ｌ１／Ｌ２シグナリングを用いて通知されてもよい。受信側装置は、該送信時刻に関する情報を用いて、該タイミングを導出してもよい。受信側装置は、受信データにおける該タイムスタンプを除去してもよい。このことにより、例えば、データ送受信におけるレイテンシを一定に保持可能となる。すなわち、ジッタを削減可能となる。
実施の形態１の本変形例４によって、ジッタ許容範囲から外れたデータを破棄する。このことにより、通信システムにおける処理量を削減可能とするとともに、該論理チャネルにおけるデータの破棄を実行可能となる。
実施の形態２．
ＮＲのセルにおいて、非特許文献２４（ＴＳ３６．３２１ Ｖ１５．２．０）に示す休止（dormant）状態を適用してもよい。ＵＥは、ｇＮＢからのＭＡＣシグナリングを用いて、該ｇＮＢのセルとの通信状態を休止状態に遷移させてもよいし、アクティブ状態に遷移させてもよい。
ところが、ＣＡを用いたパケット複製用に設定されているセルが休止状態となっている場合において、ｇＮＢは、パケット複製の通信に先立ち、休止状態を解除するためのＭＡＣシグナリングをＵＥに対して通知する必要がある。このことにより、パケット複製の通信の開始が遅れ、レイテンシが増加するといった問題が生じる。
前述の問題に対する解決法を開示する。
パケット複製が設定されたセルについては、休止状態としない。休止状態を無効としてもよい。セルを暗黙的に休止状態に遷移させるために用いるタイマを無効としてもよい。休止ＳＣｅｌｌを暗黙的に通信停止させるために用いるタイマ（例えば、非特許文献２４に示すdormantSCellDeactivationTimer）を無効としてもよい。
他の例として、パケット複製が設定されたセルについては、デアクティベート（deactivate）状態としない。パケット複製が設定されたセルについては、アクティベート（activate）状態あるいは休止状態のみを取るとしてもよい。このことにより、例えば、パケット複製を迅速に再開可能となる。
他の例として、パケット複製がアクティベートされたセルについては、休止状態としないとしてもよい。休止状態を無効としてもよい。セルを暗黙的に休止状態に遷移させるために用いるタイマを無効としてもよい。休止ＳＣｅｌｌを暗黙的に通信停止させるために用いるタイマを無効としてもよい。
他の例として、パケット複製がアクティベートされたセルについては、アクティベート状態としてもよい。該アクティベート状態への遷移は、セルアクティベートを指示するＭＡＣシグナリングなしに行われてもよい。このことにより、例えば、基地局からＵＥに対するシグナリング量を削減可能となる。
パケット複製の動作／停止を指示するＭＡＣシグナリングと、セルの休止／休止解除を指示するＭＡＣシグナリングと、セルのアクティベート／デアクティベートを指示するＭＡＣシグナリングとのうち、２つが統合されてもよいし、３つとも統合されてもよい。このことにより、例えば、基地局からＵＥに対するシグナリング量を削減可能となる。
他の例として、休止状態でないセルを用いてパケット複製が行われるとしてもよい。該セルは、例えば、アクティブ状態のセルであってもよい。このことにより、例えば、セルの休止解除が不要となり、その結果、パケット複製を迅速に実行可能となる。
ＵＥは、パケット複製のＭＡＣシグナリングを、ＳＣｅｌｌ休止／休止解除のＭＡＣシグナリングよりも優先させてもよい。他の例として、ＵＥは、ＳＣｅｌｌ休止／休止解除のＭＡＣシグナリングを、パケット複製のＭＡＣシグナリングよりも優先させてもよい。前述の優先の動作は、両者のＭＡＣシグナリングが同時に送信された場合に適用してもよいし、異なるタイミングで送信された場合に適用してもよい。基地局とＵＥとの間におけるセル状態の齟齬による誤動作を防止可能となる。
パケット複製の動作／停止を指示するＭＡＣシグナリングと、セルの休止／休止解除を指示するＭＡＣシグナリングと、セルのアクティベート／デアクティベートを指示するＭＡＣシグナリングとの組み合わせによる動作が定義されてもよい。このことにより、例えば、基地局とＵＥとの間におけるセル状態の齟齬による誤動作を防止可能となる。
ＳＣｅｌｌ休止が、上り通信と下り通信のそれぞれにおいて適用されてもよい。例えば、上り通信においてＳＣｅｌｌをアクティベートとし、下り通信においてＳＣｅｌｌを休止状態としてもよい。ＳＣｅｌｌのアクティベート／デアクティベート、および、パケット複製についても、同様としてもよい。基地局からＵＥに対する、ＭＡＣシグナリングにおいて、上りか下りかを示す識別子が付加されてもよい。このことにより、例えば、通信システムをより柔軟に運用可能となる。
本実施の形態２における動作を、ＬＴＥに対して適用してもよい。このことにより、例えば、ＬＴＥを用いたパケット複製においても、パケット複製を迅速に実行可能となる。
本実施の形態２により、ＵＥは、休止セルに対してもパケット複製を迅速に実行可能となる。
実施の形態２の変形例１．
ＣＡを用いるＵＥにおいて、ＳＣｅｌｌとの通信を休止してもよい。該ＳＣｅｌｌは、ＬＴＥのセルであってもよいし、ＮＲのセルであってもよいし、更に次世代のセルであってもよい。ＳＣｅｌｌとの通信休止は、基地局がＵＥに対して明示的に指示してもよい。該指示には、例えば、ＭＡＣシグナリングが用いられてもよい。他の例として、ＵＥがＳＣｅｌｌとの通信休止を、暗黙的に行ってもよい。ＵＥが該休止を暗黙的に行う場合において、タイマが用いられてもよい。ＵＥは、該タイマ満了時において、ＳＣｅｌｌとの通信を休止してもよい。ＳＣｅｌｌとの通信を休止したＵＥは、ＳＣｅｌｌとの通信を停止してもよい。
ところが、非特許文献２４において、暗黙的（インプリシット；implicit）なＳＣｅｌｌとの通信休止後に、ＳＣｅｌｌとの通信の暗黙的な停止を行う方法が開示されていない。このことにより、暗黙的なＳＣｅｌｌ通信休止後、さらに暗黙的なＳＣｅｌｌ通信停止を行うことができない。このことにより、ＵＥにおける消費電力が増加するといった問題が生じる。
前述の問題点を解決する方法を開示する。ＵＥは、暗黙的なＳＣｅｌｌ通信休止後、休止ＳＣｅｌｌの暗黙的な通信停止に用いるタイマを開始する。ＵＥは、該タイマ満了時において、休止ＳＣｅｌｌとの通信を停止してもよい。該タイマは、基地局からの明示的な指示による、ＳＣｅｌｌの通信休止時に起動させるタイマ（例えば、非特許文献２４に示すdormantSCellDeactivationTimer）と同じタイマであってもよい。このことにより、例えば、通信システム設計における複雑性を回避可能となる。
該タイマの値は、ＵＥにおけるＳＣｅｌｌ通信休止が明示的に行われた場合と暗黙的に行われた場合とで、同じとしてもよいし、異なるとしてもよい。タイマの値が異なる場合の例として、ＵＥは、該タイマの値から所定の値を減算した値を、該タイマの初期値として用いてもよい。例えば、ＵＥにおけるＳＣｅｌｌ通信休止が暗黙的に行われた場合において、該タイマの初期値として、前述の減算した値が用いられてもよい。このことにより、例えば、ＵＥが休止ＳＣｅｌｌとの通信停止を早く実行可能となり、その結果、ＵＥにおける消費電力を低減可能となる。
他の例として、休止ＳＣｅｌｌとの暗黙的な通信停止に用いるタイマは、基地局からの明示的な指示による、ＳＣｅｌｌとの通信休止時に起動させるタイマと異なっていてもよい。このことにより、例えば、前述と同様の効果が得られる。
実施の形態２の本変形例１により、ＵＥは、ＳＣｅｌｌ休止への暗黙的な遷移後、さらにＳＣｅｌｌ停止への暗黙的な遷移を実行可能となる。その結果、基地局とＵＥとの間のシグナリング量を削減可能となるとともに、ＵＥにおける消費電力を削減可能となる。
実施の形態２の変形例２．
ＵＥは、ＲＲＣ＿ＩＤＬＥあるいはＲＲＣ＿ＩＮＡＣＴＩＶＥステートにおいても、セルの測定を行ってもよい。ＵＥは、該測定結果を基地局に通知してもよい。
ところが、ＲＲＣ＿ＩＤＬＥあるいはＲＲＣ＿ＩＮＡＣＴＩＶＥステートのＵＥにおけるメジャメント方法および該メジャメント結果の通知方法が開示されていない。このため、該ＵＥは該メジャメントを実行できず、また、該メジャメント結果を基地局に通知することができない。
実施の形態２の本変形例２では、前述の問題点を解決する方法を開示する。
ＲＲＣ＿ＩＤＬＥあるいはＲＲＣ＿ＩＮＡＣＴＩＶＥステートのＵＥは、ＳＳブロックを測定するとしてもよい。
基地局はＵＥに対し、該ＵＥが測定するＳＳブロックに関する情報を通知してもよい。該通知は、例えば、ＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤステートから、ＲＲＣ＿ＩＤＬＥあるいはＲＲＣ＿ＩＮＡＣＴＩＶＥステートに遷移する前において行われてもよい。
該情報は、測定対象のセルの識別子を含んでもよいし、測定対象のＳＳブロックの周波数に関する情報を含んでもよいし、該ＳＳブロックの識別子を含んでもよいし、タイミングに関する情報を含んでもよいし、該ＳＳブロックが測定されるサブキャリア間隔に関する情報を含んでもよい。前述のタイミングに関する情報は、例えば、ＵＥが接続中のセルと測定対象のセルとの間のフレームタイミングオフセットに関する情報であってもよいし、該ＳＳブロックが該セルのＳＳバーストにおいて含まれる時間方向の位置に関する情報であってもよい。該情報は複数設けられてもよい。例えば、該情報が、測定対象のセルおよび／あるいはビームの個数分設けられてもよい。ＵＥは、該情報を用いて、ＳＳブロックの測定を行ってもよい。このことにより、例えば、ＲＲＣ＿ＩＤＬＥまたはＲＲＣ＿ＩＮＡＣＴＩＶＥステートのＵＥは迅速にＳＳブロックを測定可能となる。
他の例として、ＲＲＣ＿ＩＤＬＥあるいはＲＲＣ＿ＩＮＡＣＴＩＶＥステートのＵＥは、ＣＳＩ－ＲＳを測定するとしてもよい。基地局はＵＥに対し、該ＵＥが測定するＣＳＩ－ＲＳに関する情報を通知してもよい。該通知は、例えば、ＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤステートから、ＲＲＣ＿ＩＤＬＥあるいはＲＲＣ＿ＩＮＡＣＴＩＶＥステートに遷移する前において行われてもよい。
該情報は、測定対象のセルの識別子を含んでもよいし、ＣＳＩ－ＲＳの周波数に関する情報を含んでもよいし、タイミングに関する情報を含んでもよいし、周波数および時間リソースにおける配置に関する情報を含んでもよいし、該ＣＳＩ－ＲＳが測定されるサブキャリア間隔に関する情報を含んでもよいし、符号パターンに関する情報を含んでもよい。前述のタイミングに関する情報は、例えば、ＵＥが接続中のセルと測定対象のセルとの間のフレームタイミングオフセットに関する情報であってもよい。該情報は複数設けられてもよい。例えば、該情報が、測定対象のセルおよび／あるいはビームの個数分設けられてもよい。ＵＥは、該情報を用いて、ＣＳＩ－ＲＳの測定を行ってもよい。このことにより、例えば、ＲＲＣ＿ＩＤＬＥまたはＲＲＣ＿ＩＮＡＣＴＩＶＥステートのＵＥは迅速にＣＳＩ－ＲＳを測定可能となる。
他の例として、ＲＲＣ＿ＩＤＬＥあるいはＲＲＣ＿ＩＮＡＣＴＩＶＥステートのＵＥは、ＳＳブロックとＣＳＩ－ＲＳの両方を測定するとしてもよい。基地局からＵＥに対する通知は、ＳＳブロックの測定において用いられる通知と、ＣＳＩ－ＲＳの測定において用いられる通知を組み合わせたものであってもよい。このことにより、例えば、基地局は該ＵＥのＲＲＣ接続復帰を迅速に実行可能となる。
ＲＲＣ＿ＩＤＬＥおよび／あるいはＲＲＣ＿ＩＮＡＣＴＩＶＥにおける測定イベント（measurement event）が設けられてもよい。該測定イベントは、セルの測定結果についてのイベントであってもよいし、ビームの測定結果に対するイベントであってもよい。該測定イベントは、例えば、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにおける測定イベントと同様のものであってもよい。他の例として、該測定イベントは、セル再選択（cell reselection）の条件を満足したときに発生するとしてもよい。基地局はＵＥに対し、該測定イベントに関する設定を行ってもよい。ＵＥは、測定イベント発生により、基地局に対して測定結果を報告してもよい。このことにより、例えば、ＵＥはセル測定結果を迅速に基地局に通知可能となる。
該報告は、例えば、ＲＲＣシグナリングを用いて行われてもよい。ＵＥは、該報告にあたり、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤに遷移してもよい。基地局は、該報告終了後において、ＵＥに対し、ＲＲＣ＿ＩＮＡＣＴＩＶＥあるいはＲＲＣ＿ＩＤＬＥへの遷移を指示してもよい。
ＵＥは、基地局に対するＲＡＮ通知エリア更新（RAN Notification Area Update；ＲＮＡＵ）の通知に、メジャメント報告を含めてもよい。ＵＥは、該ＲＮＡＵの通知と併せて、メジャメント報告を通知するとしてもよい。このことにより、例えば、ＵＥは、メジャメント報告のみを通知するために、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤへ遷移不要となる。その結果、ＵＥにおける消費電力を削減可能となる。
他の例として、ＵＥは、基地局に対するトラッキングエリア更新（Tracking Area Update；ＴＡＵ）の通知に、メジャメント報告を含めてもよい。ＵＥは、該ＴＡＵの通知と併せて、メジャメント報告を通知するとしてもよい。このことにより、例えば、ＵＥは、メジャメント報告のみを通知するために、ＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤへ復帰不要となる。その結果、ＵＥにおける消費電力を削減可能となる。
基地局からＵＥへのＲＲＣ＿ＣＯＮＮＥＣＴＥＤ遷移指示において、ＲＲＣ＿ＩＤＬＥあるいはＲＲＣ＿ＩＮＡＣＴＩＶＥへの遷移前に設定済みのＲＲＣパラメータを通知しないとしてもよい。該ＲＲＣパラメータは、例えば、ＰＤＵセッションに関する設定であってもよいし、ベアラ設定であってもよいし、論理チャネル設定であってもよい。該ＲＲＣパラメータは、ＳＤＡＰ設定であってもよいし、ＰＤＣＰ設定であってもよいし、ＲＬＣ設定であってもよいし、ＭＡＣ設定であってもよいし、ＰＨＹ設定であってもよい。ＵＥは、ＲＲＣ＿ＩＤＬＥまたはＲＲＣ＿ＩＮＡＣＴＩＶＥ遷移後において、設定済みのＲＲＣパラメータを保持するとしてもよい。このことにより、基地局からＵＥに対するシグナリング量を削減可能となる。その結果、ＵＥから基地局に対して迅速な測定結果報告が可能となる。
実施の形態２の本変形例２により、ＵＥは、ＲＲＣ＿ＩＤＬＥあるいはＲＲＣ＿ＩＮＡＶＴＩＶＥ状態における測定結果の通知を、少ない消費電力で実行可能となる。
実施の形態３．
３ＧＰＰにおいて、Ｄ２Ｄ（Device to Device）通信、Ｖ２Ｖ（Vehicle to Vehicle）通信のため、サイドリンク（SL:Side Link）がサポートされている（非特許文献１参照）。ＳＬはＰＣ５インタフェースによって規定される。
ＳＬに用いられる物理チャネル（非特許文献１参照）について説明する。物理サイドリンク報知チャネル（ＰＳＢＣＨ：Physical sidelink broadcast channel）は、システムと同期に関連する情報を運び、ＵＥから送信される。
物理サイドリンクディスカバリチャネル（ＰＳＤＣＨ：Physical sidelink discovery channel）は、ＵＥからサイドリンクディスカバリメッセージを運ぶ。
物理サイドリング制御チャネル（ＰＳＣＣＨ：Physical sidelink control channel）は、サイドリンク通信とＶ２Ｘサイドリンク通信のためのＵＥからの制御情報を運ぶ。
物理サイドリンク共有チャネル（ＰＳＳＣＨ：Physical sidelink shared channel）は、サイドリンク通信とＶ２Ｘサイドリンク通信のためのＵＥからのデータを運ぶ。
ＳＬに用いられるトランスポートチャネル（非特許文献１参照）について説明する。サイドリンク報知チャネル（ＳＬ－ＢＣＨ：Sidelink broadcast channel）は、予め決められたトランスポートフォーマットを有し、物理チャネルであるＰＳＢＣＨにマッピングされる。
サイドリンクディスカバリチャネル（ＳＬ－ＤＣＨ：Sidelink discovery channel）は、固定サイズの予め決められたフォーマットの周期的報知送信を有する。また、ＵＥ自動リソース選択（UE autonomous resource selection）とｅＮＢによってスケジュールされたリソースアロケーションの両方をサポートする。ＵＥ自動リソースセレクションでは衝突リスクが有り、ＵＥがｅＮＢによって個別リソースをアロケーションされた時は、衝突は無い。また、ＨＡＲＱコンバイニングをサポートする。ただし、ＨＡＲＱフィードバックはサポートしない。ＳＬ－ＤＣＨは物理チャネルであるＰＳＤＣＨにマッピングされる。
サイドリンク共有チャネル（ＳＬ－ＳＣＨ：Sidelink shared channel）は、報知送信をサポートする。ＵＥ自動リソース選択（UE autonomous resource selection）とｅＮＢによってスケジュールされたリソースアロケーションの両方をサポートする。ＵＥ自動リソースセレクションでは衝突リスクが有り、ＵＥがｅＮＢによって個別リソースをアロケーションされた時は、衝突は無い。また、ＨＡＲＱコンバイニングをサポートする。ただし、ＨＡＲＱフィードバックはサポートしない。また、送信電力、変調、コーディングを変えることによって、動的リンクアダプテーションをサポートする。ＳＬ－ＳＣＨは物理チャネルであるＰＳＳＣＨにマッピングされる。
ＳＬに用いられる論理チャネル（非特許文献１参照）について説明する。サイドリンク報知制御チャネル（ＳＢＣＣＨ；Sidelink Broadcast Control Channel）は、一つのＵＥから他のＵＥにサイドリンクシステム情報を報知するためのサイドリンク用チャネルである。ＳＢＣＣＨはトランスポートチャネルであるＳＬ－ＢＣＨにマッピングされる。
サイドリンクトラフィックチャネル（ＳＴＣＨ；Sidelink Traffic Channel）は一つのＵＥから他のＵＥにユーザ情報を送信するための１対多のサイドリンク用トラフィックチャネルである。ＳＴＣＨはサイドリンク通信能力を有するＵＥとＶ２Ｘサイドリンク通信能力を有するＵＥによってのみ用いられる。２つのサイドリンク通信能力を有するＵＥ間の１対１通信もまたＳＴＣＨで実現される。ＳＴＣＨはトランスポートチャネルであるＳＬ－ＳＣＨにマッピングされる。
３ＧＰＰのＮＲにおいてもＶ２Ｘ通信のサポートが検討されている。ＮＲにおけるＶ２Ｘ通信の検討が、ＬＴＥシステム、ＬＴＥ－Ａシステムを基にして進められているが、以下の点についてＬＴＥシステム、ＬＴＥ－Ａシステムからの変更および追加が行われている。
ＬＴＥではＳＬのＶ２Ｖ通信はブロードキャスト（broadcast）のみであった。ＮＲでは、ＳＬのＶ２Ｖ通信として、ブロードキャストに加え、ユニキャスト（unicast）とグループキャスト（groupcast）のサポートが検討されている（非特許文献２２（３ＧＰＰ ＲＰ－１８２１１１）参照）。
図２７および図２８はＳＬ通信の概念図である。図２７はブロードキャスト通信を示し、図２８はユニキャスト通信を示している。図２７のブロードキャスト通信では、ＵＥ＃１からＵＥ＃２、ＵＥ＃３、ＵＥ＃４へ送信が行われる。図２８のユニキャスト通信では、ＵＥ＃１からＵＥ＃２へ、また、ＵＥ＃２からＵＥ＃１へ通信が行われる。ＵＥ＃１とＵＥ＃２の間で双方向の通信が行われる。ＵＥ＃１とＵＥ＃２の間の通信は、例えば、データであってもよいし、ＨＡＲＱのフィードバック（Ａｃｋ／Ｎａｃｋ）、ＣＳＩ報告等であってもよい。
このように、ＮＲではＳＬの通信にユニキャストのサポートが検討されている。ユニキャストでは、ブロードキャストと異なり双方向の通信が必要となる。たとえば、２つのＵＥ（ＵＥ＃１、ＵＥ＃２）間で、ＵＥ＃１からＵＥ＃２へ送信するだけでなく、ＵＥ＃２からＵＥ＃１への送信が必要となる。ＬＴＥでのＳＬの通信はブロードキャストであったため、ＵＥ＃２からＵＥ＃１への送信は不要であった。
ＳＬの通信では通信用リソースの設定が必要となる。ＬＴＥでは、ＳＬの通信はブロードキャストのみであったため、ＵＥ＃１からＵＥ＃２への送信用リソースの設定のみあれば良かった。しかし、ＮＲでユニキャストが行われる場合、ＵＥ＃１からＵＥ＃２への送信用リソースの設定のみならず、ＵＥ＃２からＵＥ＃１への送信用リソースの設定も必要となる。ＮＲにおいてユニキャストを行うためのＵＥ＃２からＵＥ＃１への送信用リソースの設定方法は未だ決まっておらず、該設定が無いと、双方向の通信ができなくなってしまう。
本実施の形態３ではこのような問題を解決する方法を開示する。
ｇＮＢがＳＬでの通信用のリソースのスケジューリングを行わない場合について開示する。いいかえると、ＵＥがスケジューリングを行う場合について開示する。
一つのＵＥが、ユニキャスト通信用のリソース設定を行う。一つのＵＥは、双方向通信用のリソース設定を行う。リソース設定は、リソースのセンシング、送信用リソースの選択、送信用リソースのリザベーションを含んでもよい。
一つのＵＥは、たとえば、最初にデータ送信を行うＵＥであってもよい。最初にデータ送信を行うＵＥが該データ送信を実施する前に予め、自ＵＥの送信用のリソース設定と、ユニキャスト通信を行うＵＥからの送信用のリソース設定とを行う。
各ＵＥからの送信用リソースは、各ＵＥから送信されるデータ用リソースであってもよいし、ＨＡＲＱのフィードバック（Ａｃｋ／Ｎａｃｋ）、ＣＳＩ報告等用のリソースであってもよい。また、各ＵＥからの送信用リソースは、各ＵＥから送信されるサウンディング用の信号あるいはチャネルのリソースであってもよい。データ用リソースは、初送データ用のリソース、再送データ用のリソースを含んでもよい。
ユニキャスト通信用のリソース設定を行う１つのＵＥは、たとえば、最初に制御用の信号あるいはチャネルを送信するＵＥであってもよい。制御用の信号あるいはチャネルではなく、制御用のシグナリングが送信されてもよい。すなわち、ユニキャスト通信用のリソース設定を行う１つのＵＥは、たとえば、最初に制御用のシグナリングを送信するＵＥであってもよい。
ユニキャスト通信の方法として、最初にユニキャスト通信の接続設立を開始するための制御信号あるいはチャネルあるいはシグナリングを送信してもよい。このような場合に、最初に接続設立を開始するための制御信号あるいはチャネルあるいはシグナリングを送信するＵＥが、ユニキャスト通信用にリソースの設定を行うとよい。
このようにすることで、ユニキャストを実施する一つのＵＥが双方向通信用のリソース設定を行うことになるので、リソース設定制御を簡易にすることが可能となる。また、一つのＵＥがユニキャスト通信のためのリソース設定を行うことになるので、リソース設定を行うＵＥ数を低減させることが可能となる。このため、他のＵＥが使用するリソースとの衝突を低減させることが可能となる。
ユニキャスト通信において、ＨＡＲＱフィードバックに、どのデータに対するＨＡＲＱフィードバックかを示す情報を付随させてもよい。ＨＡＲＱフィードバックに、対応するデータを特定するための情報を含めてもよい。このようにすることで、データを送信したＵＥは、ＨＡＲＱフィードバックがどのデータに対するＨＡＲＱフィードバックなのかを認識することが可能となる。また、前述のように、最初にデータを送信するＵＥが、データに対するＨＡＲＱフィードバックのリソースのリソース設定を行う場合、該データとＨＡＲＱフィードバックのリソースとを関連付けておくとよい。どのデータに対するＨＡＲＱフィードバックかを示す情報を省略できる。
他の方法を開示する。送信するＵＥが送信用のリソース設定を行う。ユニキャスト通信を行うＵＥ各々が、自ＵＥが送信するためのリソース設定を行う。自ＵＥが送信するためのリソースは、データ用リソースであってもよいし、ＨＡＲＱのフィードバック（Ａｃｋ／Ｎａｃｋ）、ＣＳＩ報告等用のリソースであってもよい。また、自ＵＥが送信するためのリソースは、自ＵＥが送信するサウンディング用の信号あるいはチャネルのリソースであってもよい。データ用リソースは、初送データ用のリソース、再送データ用のリソースを含んでもよい。また、自ＵＥが送信するためのリソースは、ユニキャスト通信のための接続設立を開始するための制御信号あるいはチャネルの送信用リソースであってもよい。
ＨＡＲＱフィードバックの場合、ＨＡＲＱフィードバックを送信するＵＥがリソース設定を行う。このため、送信したＨＡＲＱフィードバックが、どのデータに対するＨＡＲＱフィードバック情報なのかを、データ送信したＵＥが認識できなくなる。
このような問題を解決するため、ＨＡＲＱフィードバックを送信する場合、該フィードバックに、対応するデータを特定するための情報を含めるとよい。情報の含め方として、たとえば、フィードバックと該データを特定するための情報とを合わせた情報を設けてもよい。あるいは、フィードバックに該データを特定するための情報をスクランブリングしてもよい。対応するデータを特定するための情報は、例えば、データを送信したＵＥを特定する情報、たとえば、ＵＥ識別子であってもよい。データを送信したＵＥは、自ＵＥの識別子が検出されたフィードバックを、自ＵＥが送信したデータに対するフィードバック情報であるとして認識可能となる。
他の例として、たとえば、送信するＵＥが、データ送信時に送信する制御情報に、データに関連付ける特定の識別子を含めておく。該データを受信したＵＥが、送信するＨＡＲＱフィードバックに、該識別子を含めてもよい。データを送信したＵＥは、該識別子が検出されたフィードバックを、自ＵＥが送信したデータに対するフィードバック情報であるとして認識可能となる。
このようにすることで、たとえＨＡＲＱフィードバックを送信するＵＥが該フィードバック用リソースの設定を実施したとしても、データ送信ＵＥは、データ受信ＵＥからのＨＡＲＱフィードバック情報を受信可能となる。
このようにすることで、一つのＵＥが他のＵＥの送信用リソース設定を行う必要が無くなる。このため、ＵＥ間で、送信用リソース設定に関する情報、たとえばリソースアロケーション情報等が通知不要となる。ＳＬ通信においてＵＥ間のシグナリングを削減可能となる。また、各ＵＥは、自ＵＥによる送信に必要なリソース量に適したリソース設定を実施可能となる。このため、リソースの使用効率を向上させることが可能となる。
他の方法を開示する。ユニキャスト通信において、所定の信号あるいはチャネルの送信用リソースと、それに対して行われるフィードバックあるいは報告等の送信用リソースとを、同一のＵＥが設定するとよい。所定の信号あるいはチャネルを送信するＵＥが、リソース設定を行ってもよい。ユニキャスト通信の遅延時間を削減可能となる。
たとえば、ＨＡＲＱフィードバック用リソースについては、該フィードバックに関連するデータを送信するＵＥが、リソース設定を実施する。例えば、ＵＥ＃１がＵＥ＃２に対してデータを送信し、ＵＥ＃２がＵＥ＃１に対して該データに対するＨＡＲＱフィードバックを送信する。この場合、ＵＥ＃１がＨＡＲＱフィードバック用のリソース設定を行う。ＵＥ＃１が、データ送信用リソース設定と、該データ送信に対するＨＡＲＱフィードバック用リソース設定とをあわせて行う。
双方向でデータ通信が行われるような場合、たとえば、ＵＥ＃１がＵＥ＃２に対してデータを送信し、ＵＥ＃２がＵＥ＃１に対して該データに対するＨＡＲＱフィードバックを送信し、さらに、ＵＥ＃２がＵＥ＃１に対してデータを送信し、ＵＥ＃１がＵＥ＃２に対して該データに対するＨＡＲＱフィードバックを送信する。この場合、ＵＥ＃１が送信するデータと、該データに対してＵＥ＃２が送信するＨＡＲＱフィードバック用のリソース設定とは、ＵＥ＃１が行う。ＵＥ＃２が送信するデータと、該データに対してＵＥ＃１が送信するＨＡＲＱフィードバック用のリソース設定とは、ＵＥ＃２が行う。
このようにすることで、ＨＡＲＱフィードバックの前にＨＡＲＱフィードバックを送信するＵＥがリソース設定を行う必要がなくなる。このため、データ送信からＨＡＲＱフィードバック送信までの期間を短縮可能となる。ユニキャスト通信の遅延時間を削減可能となる。
ＣＳＩ報告用のリソースについて、該ＣＳＩ報告に関連する信号あるいはチャネルを送信するＵＥが、リソース設定を実施してもよい。例えば、ＵＥ＃１がＵＥ＃２に対してＣＳＩ－ＲＳを送信し、ＵＥ＃２がＵＥ＃１に対して、ＣＳＩ－ＲＳ受信結果から導出されるＣＳＩ報告を送信する。この場合、ＵＥ＃１がＣＳＩ報告用のリソース設定を行う。ＵＥ＃１が、ＣＳＩ－ＲＳ送信用リソース設定と該ＣＳＩ－ＲＳに対するＣＳＩ報告用リソース設定とをあわせて行う。双方向の場合も同様である。
このようにすることで、ＣＳＩ報告の前にＣＳＩ報告を送信するＵＥがリソース設定を行う必要がなくなる。このため、ＣＳＩ－ＲＳ送信からＣＳＩ報告送信までの期間を短縮可能となる。ユニキャスト通信の遅延時間を削減可能となる。
他の方法を開示する。自ＵＥが送信用リソースの設定を実施するか否かを設定可能とする。自ＵＥが送信用リソースの設定を実施するか否かの判断指標として以下に５つの具体例を開示する。
（１）サービス種類。
（２）ＱｏＳ。
（３）リソーススケジューリング種類。
（４）送信データ種類。
（５）送信プロトコル。
前述の（１）では、ユニキャストで通信するサービス種類に応じて、自ＵＥが送信用リソースの設定を実施するか否かを判断する。たとえば、ユニキャストで通信するサービスが、非周期的にデータ送信が行われるサービスの場合、自ＵＥが送信用リソースの設定を実施するとしてもよい。一方、非周期的ではなく周期的にデータ送信が行われるサービスの場合、一つのＵＥが送信用リソースの設定を実施するとしてもよい。
データ送信が周期的に行われる場合、データ送信の発生タイミングを導出しやすくなる。このため、送信用リソースの設定を一つのＵＥが行うことが容易になり、制御を簡易にすることが可能となる。
前述の（２）では、ユニキャストで通信するサービスのＱｏＳに応じて、自ＵＥが送信用リソースの設定を実施するか否かを判断する。たとえば、ユニキャストで通信するサービスのＱｏＳとして要求される低遅延特性が所定の閾値よりも大きい場合、自ＵＥが送信用リソースの設定を実施するとしてもよい。一方、要求される低遅延特性が所定の閾値以下の場合、一つのＵＥが送信用リソースの設定を実施するとしてもよい。
低遅延特性が要求されるサービスの場合、一つのＵＥが送信用リソース設定を行うことで、低遅延特性をより向上させることが可能となる。低遅延特性が要求されないサービスの場合、自ＵＥが送信用リソース設定を行うことで、リソース使用効率をより向上させることが可能となる。
ＱｏＳとして低遅延特性を例示した。しかし、他の例として、ＱｏＳは、パケットエラーレート等の信頼性、補償ビットレート等のスルーレート、パケット毎の優先順位等の優先順位などであってもよい。パケット毎の優先順位は、たとえば、ＰＰＰＰ（ProSe Per Packet Priority）であってもよい。
前述の（３）では、ＳＬでの通信に用いるリソーススケジューリング種類に応じて、自ＵＥが送信用リソースの設定を実施するか否かを判断する。たとえば、リソーススケジューリングがダイナミックスケジューリングの場合、自ＵＥが送信用リソースの設定を実施し、ＳＰＳ（semi-persistent scheduling）や、設定済グラント（configured grant）のように予めリソーススケジューリングタイミングが設定されている場合、一つのＵＥが送信用リソースの設定を実施するとしてもよい。
リソーススケジューリングがダイナミックに行われる場合、自ＵＥが送信用リソースの設定を行うことで、リソースの使用効率を向上させることが可能となる。一方、リソーススケジューリングタイミングが設定されるような場合、該送信リソースの設定を一つのＵＥが行うことが容易になり、制御を簡易にすることが可能となる。
前述の（４）では、送信データ種類に応じて、自ＵＥが送信用リソースの設定を実施するか否かを判断する。たとえば、制御プレインの送信、制御情報の送信、あるいは制御シグナリングの送信の場合、自ＵＥが送信用リソースの設定を実施するとしてもよい。一方、ユーザプレインの送信、あるいはデータの送信の場合、一つのＵＥが送信用リソースの設定を実施するとしてもよい。
制御に関する送信の場合、該送信の発生タイミングはダイナミックに生じる場合が多い。このため、自ＵＥが送信用リソースの設定を行うことで、リソースの使用効率を向上させることが可能となる。一方、データ送信の場合、該送信の発生タイミングは予め設定されている場合が多い。このため、一つのＵＥが送信用リソースの設定を行うことが容易になり、制御を簡易にすることが可能となる。
前述の（５）では、送信プロトコルスタックに応じて、自ＵＥが送信用リソースの設定を実施するか否かを判断する。たとえば、ＲＲＣによる送信の場合、自ＵＥが送信用リソースの設定を実施し、ＰＨＹあるいはＭＡＣによる送信の場合、一つのＵＥが送信用リソースの設定を実施するとしてもよい。
ＲＲＣによる送信の場合、送信回数が複数回になる場合や、送信のために要求される遅延特性が緩い場合がある。このため、自ＵＥが送信用リソースの設定を行うことも可能である。一方、ＰＨＹあるいはＭＡＣによる送信の場合、送信回数が少なく、低遅延特性が要求される場合がある。このため、一つのＵＥが送信用リソースの設定を行うことで、低遅延特性を得ることが可能となる。
前述は単に例示であってこれに限らず該判断指標に応じて適宜設定を行ってもよい。
自ＵＥが送信用リソースの設定を実施するか否かの設定は、予め規格等で静的に決めておいてもよい。また、該設定をｇＮＢがＵＥに対して通知してもよい。通知方法は、報知であってもよいし、個別の通知であってもよい。個別に通知する場合、たとえば、ＲＲＣシグナリング、ＭＡＣシグナリング、あるいは、Ｌ１／Ｌ２制御シグナリングを用いてもよい。また、自ＵＥが送信用リソースの設定を実施するか否かが、ＵＥ内に予め設定されてもよい。たとえば、設定情報がＵＥ内ＳＩＭに予め設定（pre-configured）されてもよい。また、設定方法をＵＥ間で通知してもよい。
前述の方法を適宜組み合わせてもよい。たとえば、ユニキャスト通信を実施するにあたって、接続要求処理では送信を行うＵＥの各々が送信用のリソース設定を行い、データ送信とフィードバック送信処理では一つのＵＥがリソース設定を行う。このようにすることで、各処理や送信する信号やチャネル毎に適した効果を得ることが可能となる。
このようにすることで、ＵＥがスケジューリングする場合に、ユニキャスト通信用に対向する各ＵＥからの送信用リソースの設定が可能となり、双方向の通信を可能とする。ＵＥがスケジューリングすることで、ＵＥがｇＮＢのカバレッジ内に存在している場合も、カバレッジ内に存在していない場合にも、開示した方法を適用することができる。それにより、ユニキャスト通信用に対向する各ＵＥからの送信用リソースの設定が可能となり、双方向の通信を可能とする。
ｇＮＢがＳＬのスケジューリングを行う場合について開示する。
ｇＮＢが、送信する各ＵＥに対して送信用のリソース設定を通知する。各ＵＥは、ｇＮＢから通知されたリソース設定に従ってリソースを設定し、該リソースで送信を行う。
ユニキャスト通信を行うＵＥはｇＮＢに対して、ＳＲおよび／あるいはＢＳＲを送信してもよい。ｇＮＢは、各ＵＥから受信したＳＲおよび／あるいはＢＳＲに応じて、ＵＥに対して送信用リソースの設定を行う。各ＵＥからｇＮＢに送信するＳＲおよび／あるいはＢＳＲは、Ｕｕインタフェース上で行われる。ｇＮＢは予めＵＥに対して、ＳＲおよび／あるいはＢＳＲ送信用のリソース設定を通知しておくとよい。このようにすることで、ユニキャストを行う各ＵＥに対して、送信用リソースの設定が可能となる。
ＳＬにおける制御信号／チャネルあるいは制御シグナリングの送信用のリソース設定を、予めｇＮＢがユニキャスト通信を行うＵＥに対して通知しておいてもよい。たとえば、ユニキャスト通信において、ＵＥ間で接続要求処理が実施される場合、該接続要求用の制御信号／チャネルあるいは制御シグナリングの送信用のリソース設定を、予めｇＮＢがＵＥに対して通知する。このようにすることで、ユニキャストのデータ送信が実施される前の処理用にリソースを設定可能とする。
他の方法を開示する。ｇＮＢが一つのＵＥに対して、双方向の送信用のリソース設定を通知する。ｇＮＢは該ＵＥに対して、ユニキャスト通信の送信先ＵＥを示す情報を送信してもよい。ｇＮＢは該ＵＥに対して、送信用リソース設定と、該送信を行うＵＥの識別子とを関連付けて送信してもよい。該リソース設定を通知されたＵＥは、ユニキャスト通信の送信先ＵＥに対して、ｇＮＢから通知されたリソース設定を通知する。各ＵＥは、通知されたリソース設定に従ってリソースを設定し、該リソースで送信を行う。
ユニキャスト通信を行うＵＥはｇＮＢに対して、ＳＲおよび／あるいはＢＳＲを送信してもよい。ＵＥはｇＮＢに対して、ユニキャスト通信の送信先ＵＥを示す情報を送信してもよい。該情報はＵＥ識別子であってもよい。該情報はＳＲおよび／あるいはＢＳＲに含めて通知してもよい。ＳＲおよび／あるいはＢＳＲの送信方法は前述の方法を適用してもよい。ｇＮＢは、ＳＲおよび／あるいはＢＳＲを送信したＵＥから、ユニキャスト通信を行う対向するＵＥを検出し、どちらか１つのＵＥに対して双方向の送信用のリソース設定を通知するとよい。
ユニキャスト通信の送信先ＵＥの送信用リソース設定は、ブラインドで設定してもよい。ＵＥが該設定を、送信先ＵＥからＢＳＲを受信するまでの間、ブラインドで設定してもよい。ｇＮＢが送信先ＵＥのＳＲおよび／あるいはＢＳＲを受信しなくても、送信用リソースの設定が可能となる。言い換えると、送信先ＵＥからのＳＲおよび／あるいはＢＳＲを不要とする。ユニキャスト通信の制御を簡略化でき、また、シグナリング量を削減できる。
このようにすることで、ユニキャストを行う各ＵＥに対して送信用リソースの設定が可能となる。
本実施の形態３で開示した方法とすることで、ユニキャスト通信における各ＵＥの送信用リソースの設定が可能となる。このため、ユニキャスト通信を可能とする。また、データ送信や所定の信号あるいはチャネルの送信用リソースと、それに対して行われるフィードバックあるいは報告等の送信用リソースとを、設定可能となる。このため、ユニキャスト通信の通信品質を向上させることが可能である。
ＵＥは、ＳＬでの通信に使用可能なリソースを判断するため、リソースのセンシングを行う（非特許文献２７）。従来のＬＴＥのＳＬはブロードキャストのみであったため、初送（繰返し送信（repetition）を含む）しかなく再送が無かった。しかし、ユニキャスト通信では再送が発生する。このように、再送が発生するような場合のセンシング方法は不明であり、ユニキャスト通信を可能とするため新たなセンシング方法が求められる。ここでは、ユニキャスト通信用のリソースセンシング方法を開示する。
リソースセンシングにおいて、ユニキャスト通信に用いるリソースの候補から除外するリソースとして、初送用のリソースに加え再送用のリソースを含める。また、初送用のリソースに加えてフィードバック用のリソースを含めてもよい。また、他の信号あるいはチャネルあるいはシグナリング用のリソースを含めてもよい。
リソースセンシングにおいて、前述のような、初送用、再送用、フィードバック用、他の信号／チャネルあるいはシグナリング用に設定されているリソースを全て除外しなくてもよい。たとえば、除外のための閾値を設けてもよい。たとえば、受信電力の閾値を設ける。ＵＥは、これらリソースの受信電力を測定し、測定値が該閾値よりも大きいリソースを除外してもよい。測定する指標を受信電力としたが、受信強度としてもよい。これに限らず他の指標を用いてもよい。
閾値はリソース用途毎に決められてもよい。たとえば、初送用リソースと再送用リソースの除外用閾値を同じとし、フィードバック用リソースの除外用閾値を異ならせてもよい。たとえば、ＦＢ信号は閾値を低くしてＵＥ間の干渉を低減してもよい。このようにすることで、他ＵＥからの干渉を信号によって異ならせることが可能となる。
ＵＥはＳＬでの送信時、ＣＲ（Channel occupied Ratio）を評価する（非特許文献２７）。ＣＲはＵＥが使用するリソースの割合である。具体的には、ＣＲは、送信決定前後合わせた所定の数のサブフレームにおいて、送信に用いられた／用いるサブチャネルの割合である。従来のＬＴＥのＳＬはブロードキャストのみであったため、初送（繰返し送信（repetition）を含む）しかなく再送が無かった。このため、ＣＲでは初送に用いられた／用いるサブチャネルの割合が導出された。
しかし、ユニキャスト通信では再送が発生する。このように、再送が発生するような場合のＣＲ評価方法は不明であり、ユニキャスト通信を可能とするため新たなＣＲ評価方法が求められる。ここでは、ユニキャスト通信用のＣＲ評価方法を開示する。
ＣＲを評価するＵＥについて開示する。ユニキャスト通信においては対向するＵＥ間で双方向の通信が行われる。ユニキャスト通信においては、データあるいはフィードバック等を送信するＵＥが、ＣＲの評価を行う。このようにすることで、ＵＥは、設定したあるいは設定されたリソースで、データあるいはフィードバック等をどの程度送信したらよいかを判断可能となる。ＣＲに関連して予め設定された通信量となるよう送信を制御可能となる。
他の方法を開示する。ユニキャスト通信においては、リソース設定を行うＵＥがＣＲを評価する。このようにすることで、リソース設定時に、ＣＲに関連して予め設定された通信量となるよう、リソースの選択あるいはリソースリザベーションを実施可能となる。このようにＣＲを導出することで、リソース設定時のＵＥ間の混雑回避を実行可能となる。
ＣＲの導出方法について開示する。ユニキャスト通信においては、初送（繰返し送信を含む）に用いられた／用いるサブチャネルの割合を導出する。ユニキャスト通信では再送が発生することになるが、再送を行うか否かは通信品質に左右される。常時再送が発生するとは限らず、将来（たとえば送信決定後）の発生回数は不確定になる。このように再送を含めないことで、不確定な要素を削減することが可能となる。
ＣＲを用いた送信制御において、ＵＥはＣＲに関連して予め設定された通信量となるよう送信を制御する。再送あるいはフィードバックの影響については、該ＣＲに関連して予め設定される通信量に入れ込むようにしてもよい。たとえば、将来の送信においては、平均再送回数あるいは最大再送回数、平均フィードバック回数あるいは最大フィードバック回数に用いるサブチャネルの割合を考慮して、該ＣＲに関連して予め設定される通信量を設定するとよい。このようにすることで、再送あるいはフィードバックの影響を入れ込むことができる。
他の方法を開示する。初送かつ再送に用いられた／用いるサブチャネルの割合を導出する。または、初送かつフィードバックに用いられた／用いるサブチャネルの割合を導出してもよい。または、初送かつ再送かつフィードバックに用いられた／用いるサブチャネルの割合を導出してもよい。将来の再送あるいはフィードバックについては、リソースリザベーションされたサブチャネルとしてもよい。
あるいは、再送あるいはフィードバックの将来の発生回数については、所定の回数を予め設定してもよい。該所定の回数は、たとえば、平均再送回数あるいは最大再送回数、平均フィードバック回数あるいは最大フィードバック回数としてもよい。また、たとえば、通信品質に応じて将来の発生回数を設定してもよい。たとえば、通信品質が所定の値よりも悪い場合は将来の発生回数の回数を大きく設定し、通信品質が所定の値よりも良い場合は将来の発生回数を小さく設定する。
このようにすることで、ＣＲ導出時に再送あるいはフィードバックの影響を入れ込むことができるため、制御を容易にすることができる。ユニキャスト通信において、このようなＣＲ評価方法を用いることで、再送が発生するような場合にもＣＲ評価が可能となり、ＵＥ間の混雑回避の制御を可能とする。
ＮＲではパケット複製がサポートされる。ここでは、ユニキャスト通信を用いたパケット複製の方法を開示する。ユニキャスト通信において対向するＵＥの各々が、ユニキャスト通信用のリソース設定を行う。たとえば、データを送信するＵＥがリソース設定を行うとともに、データを受信するＵＥがリソース設定を行う。これら２つのリソース設定を用いてデータ送信を行う。ＵＥはこれら２つのリソース設定を用いてパケット複製によるデータ送信を行う。
たとえば、ＵＥ＃１がＵＥ＃２にデータ送信を行う場合について開示する。ＵＥ＃１はデータ送信用のリソース設定を行う。また、ＵＥ＃１はＵＥ＃２に対して、データ送信用のリソース設定を要求する。データ送信用リソース設定要求シグナリングを設けて通知してもよい。この要求はＵＥ＃１がデータ送信用リソース設定を行う前に実施してもよい。該要求に、リソース設定に必要な情報を含めるとよい。
リソース設定に必要な情報として、ＱｏＳ、優先順位、データ発生タイミング、データ発生周期、バッファステータス等がある。また、該情報に、要求を送信したＵＥの識別子を含めてもよい。リソース設定要求を受信したＵＥ＃２は、該情報を用いてリソース設定を行う。ＵＥ＃２は、設定したリソース設定をＵＥ＃１に通知する。
このようにすることで、ＵＥ＃１は、自ＵＥと、対向するＵＥ＃２とが設定したリソース設定を認識可能となる。ＵＥ＃１は、ＰＤＣＰでパケット複製を行う。ＵＥ＃１は、複製したパケットの一つを自ＵＥが設定したリソースで送信し、他のパケットをＵＥ＃２が設定したリソースで送信する。リソース設定毎にＬＣＨを設定してもよい。ＵＥ＃１は、複製したパケットを異なるＬＣＨにマッピングし、一つのＬＣＨを自ＵＥが設定したリソースで送信し、他のＬＣＨをＵＥ＃２が設定したリソースで送信する。
このようにすることで、ＵＥ＃１からＵＥ＃２に送信するデータをパケット複製し、複製したパケットを、ＵＥ＃１が設定したリソースと、ＵＥ＃２が設定したリソースとを用いて送信することが可能となる。
ＵＥ＃１でのリソース設定において、ＵＥ＃１がリソースセンシングおよびリソース選択を行う。また、ＵＥ＃２でのリソース設定において、ＵＥ＃２がリソースセンシングおよびリソース選択を行う。ＵＥ＃１がリソースセンシングおよびリソース選択したリソースは、ＵＥ＃２がリソースセンシングおよびリソース選択したリソースと異なる。これは、ＵＥ＃１とＵＥ＃２の位置が異なるため、周辺の他のＵＥの存在状況が異なることが一因である。周辺の他のＵＥの存在状況が異なるため、使用されているリソースの状況も、ＵＥ＃１とＵＥ＃２とで異なるためである。
したがって、ＵＥ＃１が設定したリソースと、ＵＥ＃２が設定したリソースとでは、通信品質が異なることになる。これら通信品質の異なるリソースを、パケット複製されたデータ送信に用いることによって、複製されたパケットデータの送達確率を高めることが可能となる。通信の信頼性を向上させることが可能となる。
実施の形態３の変形例１．
ＬＴＥではＳＬの通信はブロードキャストのみであり、ユニキャストと異なり２つのＵＥ間で通信をするわけでは無かった。いいかえると、ＬＴＥでは２つのＵＥ間の通信は接続無し（Connectionless）の通信であった。ＮＲではＳＬの通信としてユニキャストが検討されている。ＳＬのユニキャスト用に２つのＵＥ間で接続を設立して通信することが提案されているが、しかし、その接続設立方法は不明である。このためユニキャスト通信までの処理が不明である。本変形例１ではこのような問題を解決するための方法を開示する。
ユニキャストでの通信内容の例について開示する。ユニキャスト通信は、一方向のデータあるいはＲＳの送信と、それに対する応答送信のみで構成されてもよい。該データ送信はユーザプレインのデータ送信としてもよい。たとえば、データとそれに対するフィードバック、あるいはデータとＳＲＳ、あるいはＣＳＩ－ＲＳとそれに対するＣＳＩ報告、あるいはＳＲＳとそれに対するＳＲＩなどによって、ユニキャスト通信が構成されてもよい。これらを組合せてもよい。
ユニキャストでの通信内容の他の例について開示する。ユニキャスト通信は、双方向のデータあるいはＲＳの送信と、それに対する応答送信で構成されてもよい。該データ送信はユーザプレインのデータ送信としてもよい。たとえば、双方向のデータとそれに対するフィードバック、あるいは双方向のデータとＳＲＳ、あるいは双方向のＣＳＩ－ＲＳとそれに対するＣＳＩ報告、あるいは双方向のＳＲＳとそれに対するＳＲＩなどによって、ユニキャスト通信が構成されてもよい。これらを組合せてもよい。
ＳＬのユニキャスト用に２つのＵＥ間でのユニキャスト通信までの処理方法を開示する。ＵＥが送信の意思を示すための信号／チャネルを設ける。ＵＥが送信の意思を示すためのシグナリングを設けてもよい。制御用の信号／チャネルあるいはシグナリングを設けてもよい。制御プレインの信号／チャネルあるいはシグナリングを設けてもよい。ＳＬでの送信が発生したＵＥは、送信の意思を示すための信号／チャネルを送信する。該信号／チャネルはブロードキャストで送信してもよい。該信号／チャネルに含める情報として以下に６つの具体例を示す。
（１）送信の意思を示す情報。
（２）サービスに関する情報。
（３）ターゲットＵＥ（双方向通信の対向するＵＥ）に関する情報。
（４）ソースＵＥ（自ＵＥ）に関する情報。
（５）応答用リソース設定に関する情報。
（６）（１）から（５）の組合せ。
前述の（２）のサービスに関する情報は、サービスを特定するための識別子であってもよい。前述の（２）の情報は、サービスのＱｏＳに関する情報を含んでもよい。前述の（２）の情報は、優先順位に関する情報を含んでもよい。
前述の（３）のターゲットＵＥに関する情報は、ＵＥの識別子であってもよい。前述の（３）の情報は、双方向通信の対向するＵＥを特定するための情報であればよい。前述の（３）の情報は、一つまたは複数のターゲットＵＥに関する情報を含んでもよい。前述の（３）の情報は、ターゲットＵＥが含まれるグループの情報であってもよい。たとえば、グループの識別子であってもよい。
前述の（４）のソースＵＥに関する情報は、ＵＥの識別子であってもよい。前述の（４）の情報は、該信号／チャネルを送信するＵＥを特定するための情報であればよい。前述の（４）の情報は、ＵＥの状態を示す情報であってもよい。該情報は、たとえば、ＵＥの位置情報、移動速度情報などであってもよい。前述の（４）の情報は、グループ情報であってもよい。該情報は、ソースＵＥが含まれるグループの情報であってもよい。該情報は、たとえば、グループの識別子であってもよい。
前述の（５）の応答用リソース設定に関する情報は、該信号／チャネルに対してターゲットＵＥからソースＵＥに対して送信する応答信号／チャネル用のリソース設定情報とするとよい。前述の（５）の情報は、リソースアロケーションなどのスケジューリング情報を含んでもよい。応答用リソース設定をターゲットＵＥが実施する場合は、該情報を省略してもよい。
送信の意思を示すための信号／チャネルを新たに設けてもよい。他の方法として、Ｄ２Ｄ通信で用いられていたＰＳＢＣＨを用いてもよい。ＰＳＢＣＨの報知情報として、前述の情報を含めてもよい。ＳＬでの送信が発生したＵＥは、送信の意思を示すため、前述の情報を含めたＰＳＢＣＨを送信する。
他の方法として、Ｄ２Ｄ通信で用いられていたＰＳＤＣＨを用いてもよい。ＰＳＤＣＨに前述の情報を含めてもよい。ＳＬでの送信が発生したＵＥは、送信の意思を示すため、前述の情報を含めたＰＳＤＣＨを送信する。
送信の意思を示すための信号／チャネルは、周期的に送信してもよい。該信号／チャネルは、所定の期間あるいは回数だけ周期的に送信してもよい。所定の期間あるいは回数送信しても、該信号／チャネルに対する応答信号／チャネルを受信しなかった場合、送信の意思を示すための信号／チャネルの送信を停止してもよい。あるいは、再度所定の期間あるいは回数だけ周期的に送信してもよい。所定の再送回数あるいは再送のための期間、該信号／チャネルに対する応答信号／チャネルを受信しなかった場合、送信の意思を示すための信号／チャネルの送信を停止してもよい。また、該信号／チャネルに対する応答信号／チャネルを受信した場合は、送信の意思を示すための信号／チャネルの送信を停止してもよい。
送信の意思を示すための信号／チャネルの送信を停止する条件として、該信号／チャネルに対する応答信号／チャネルを受信しなかった場合を例示したが、対向ＵＥを検出できなかった場合を該停止条件としてもよい。複数のＵＥが存在を示すための信号／チャネルを送信し、ソースＵＥが対向ＵＥを該ＵＥの中から検出するような場合に有効である。
該周期、該所定の期間あるいは回数、所定の再送回数あるいは再送のための期間は、規格等であらかじめ静的に決めてもよい。あるいは、該周期等をｇＮＢがＵＥに対して通知してもよい。あるいは、ＵＥが該周期等を決定してもよい。ＵＥにおいて上位レイヤが該周期等を決定してもよい。
ＵＥが存在を示すための信号／チャネルを設ける。ＵＥが存在を示すためのシグナリングを設けてもよい。制御用の信号／チャネルあるいはシグナリングを設けてもよい。制御プレインの信号／チャネルあるいはシグナリングを設けてもよい。ＵＥは、ソースＵＥからの送信の意思を示すための信号／チャネルを受信し、該信号／チャネルに含まれる情報から、ソースＵＥを対向するＵＥであると判断した場合、該信号／チャネルに対する応答信号／チャネルとして、ＵＥの存在を示すための信号／チャネルを送信する。ＵＥの存在を示すための信号／チャネルはブロードキャストで送信してもよい。ＵＥの存在を示すための信号／チャネルに含める情報として以下に５つの具体例を示す。
（１）存在を示す情報。
（２）サービスに関する情報。
（３）ターゲットＵＥ（自ＵＥ）に関する情報。
（４）ソースＵＥ（双方向通信の対向するＵＥ）に関する情報。
（５）（１）から（４）の組合せ。
前述の（１）の存在を示す情報は、送信の意思を示すための信号／チャネルのターゲットとなるＵＥであることを示す情報としてもよい。該情報を明示して通知することで信頼性を向上させることができる。前述の（３）のターゲットＵＥは自ＵＥである。前述の（４）のソースＵＥは双方向通信の対向するＵＥ、言い換えると送信の意思を示すための信号／チャネルを送信したＵＥである。
前述の（３）のターゲットＵＥ（自ＵＥ）に関する情報は、ＵＥの識別子であってもよい。前述の（３）の情報は、該信号／チャネルを送信するＵＥを特定するための情報であればよい。前述の（３）の情報は、ＵＥの状態を示す情報であってもよい。該情報は、たとえば、ＵＥの位置情報、移動速度情報などであってもよい。前述の（３）の情報は、グループ情報であってもよい。該情報は、自ＵＥが含まれるグループの情報であってもよい。該情報は、たとえば、グループの識別子であってもよい。
前述の（４）のソースＵＥに関する情報は、ＵＥの識別子であってもよい。前述の（４）の情報は、双方向通信の対向するＵＥを特定するための情報であればよい。前述の（４）の情報は、グループ情報であってもよい。該情報は、ソースＵＥが含まれるグループの情報であってもよい。該情報は、たとえば、グループの識別子であってもよい。
ＵＥが存在を示すための信号／チャネルを新たに設けてもよい。他の方法として、ＰＳＣＣＨを用いてもよいし、ＰＳＳＣＨを用いてもよい。ＰＳＣＣＨとＰＳＳＣＨをあわせて用いてもよい。たとえば、ＵＥの存在を示すための信号／チャネルに含める情報を、ＰＳＣＣＨに含めて送信してもよい。また、たとえば、ＵＥの存在を示すための信号／チャネルに含める情報の一部または全部を、ＰＳＳＣＨに含めて送信し、該ＰＳＳＣＨのスケジューリング情報と、ＵＥの存在を示すための信号／チャネルに含める情報の残りとを、ＰＳＣＣＨに含めて通知してもよい。
該信号／チャネルの送信のためのリソース設定は、送信の意思を示すための信号／チャネルに含まれる応答用リソース設定に関する情報を用いてもよい。または、ターゲットＵＥが該信号／チャネル用にリソース設定を行ってもよい。応答用リソース設定に関する情報が含まれない場合に有効である。
接続要求のためのシグナリングを設ける。接続要求のための信号／チャネルを設けてもよい。制御用の信号／チャネルあるいはシグナリングを設けてもよい。制御プレインの信号／チャネルあるいはシグナリングを設けてもよい。ＳＬでの送信が発生したＵＥは、ユニキャストを行う対向するＵＥに対して、ユニキャストのための接続要求シグナリングを送信する。接続要求に含める情報として以下に６つの具体例を示す。
（１）接続要求であることを示す情報。
（２）サービスに関する情報。
（３）ターゲットＵＥ（双方向通信の対向するＵＥ）に関する情報。
（４）ソースＵＥ（自ＵＥ）に関する情報。
（５）接続要求応答用リソース設定に関する情報。
（６）（１）から（５）の組合せ。
前述の（３）のターゲットＵＥに関する情報は、ＵＥの識別子であってもよい。前述の（３）の情報は、双方向通信の対向するＵＥを特定するための情報であればよい。前述の（３）の情報は、一つのターゲットＵＥに関する情報とするとよい。
前述の（５）の接続要求応答用リソース設定に関する情報は、接続要求に対してターゲットＵＥからソースＵＥに対して送信する接続要求応答シグナリングのリソース設定情報とするとよい。前述の（５）の情報は、リソースアロケーションなどのスケジューリング情報を含んでもよい。接続要求応答用リソース設定をターゲットＵＥが実施する場合は、該情報を省略してもよい。
接続要求のための信号／チャネルを新たに設けてもよい。他の方法として、ＰＳＣＣＨを用いてもよいし、ＰＳＳＣＨを用いてもよい。ＰＳＣＣＨとＰＳＳＣＨをあわせて用いてもよい。たとえば、接続要求に含める情報を、ＰＳＣＣＨに含めて送信してもよい。
あるいは、接続要求に含める情報を、ＲＲＣシグナリングで通知してもよいし、ＭＡＣシグナリングで通知してもよい。たとえば、接続要求に含める情報の一部または全部を、ＰＳＳＣＨに含めて送信し、該ＰＳＳＣＨのスケジューリング情報と、接続要求に含める情報の残りとを、ＰＳＣＣＨに含めて通知してもよい。
接続要求シグナリングの送信方法に、送信の意思を示すための信号／チャネルの送信方法を適用してもよい。
接続要求応答シグナリングを設ける。接続要求応答のための信号／チャネルを設けてもよい。制御用の信号／チャネルあるいはシグナリングを設けてもよい。制御プレインの信号／チャネルあるいはシグナリングを設けてもよい。ユニキャストの対向するＵＥは、ソースＵＥからの接続要求シグナリングを受信した場合、接続要求応答シグナリングを送信する。接続要求応答に含める情報として以下に７つの具体例を示す。
（１）接続要求応答に関する情報。
（２）サービスに関する情報。
（３）ターゲットＵＥ（自ＵＥ）に関する情報。
（４）ソースＵＥ（双方向通信の対向するＵＥ）に関する情報。
（５）スケジューリングリクエスト（ＳＲ）。
（６）ＢＳＲ（Buffer Status Report）。
（７）（１）から（６）の組合せ。
前述の（１）の接続要求応答に関する情報として、許可応答、あるいは、拒絶応答などがある。前述の（１）の情報は、理由情報を含んでもよい。あるいは、前述の（１）の情報は、Ａｃｋ、Ｎａｃｋ情報としてもよい。拒絶応答、あるいは、Ｎａｃｋ情報を設けることで、ターゲットＵＥの負荷状況やケーパビリティに応じて、ターゲットＵＥが接続を実施するか否かを判断することが可能となる。
前述の（５）のスケジューリングリクエストは、ターゲットＵＥからソースＵＥに対して送信するデータが存在する場合、あるいは発生する可能性が有る場合に通知するとよい。
前述の（６）のＢＳＲについては、ターゲットＵＥからソースＵＥに対して送信するデータが存在する場合、あるいは発生する可能性が有る場合、バッファしているデータ容量を通知するとよい。あるいは、送信を必要とするデータ量を通知してもよい。バッファしているデータ容量として、ＳＬ用のユーザプレインのプロトコルにバッファしているデータ容量を利用するとよい。たとえば、ＳＬ用のＰＤＣＰおよび／またはＳＬ用のＲＬＣでバッファしているデータ容量を利用するとよい。
前述の（５）および／あるいは（６）を受信したソースＵＥは、ターゲットＵＥに対して、データ送信用のリソース設定を実行するか否か判断可能となる。また、ソースＵＥは、リザベーションするリソース量を判断可能となる。
接続要求応答のための信号／チャネルを新たに設けてもよい。他の方法として、ＰＳＣＣＨを用いてもよいし、ＰＳＳＣＨを用いてもよい。ＰＳＣＣＨとＰＳＳＣＨをあわせて用いてもよい。たとえば、接続要求応答に含める情報を、ＰＳＣＣＨに含めて送信してもよい。
あるいは、接続要求応答に含める情報を、ＲＲＣシグナリングで通知してもよいし、ＭＡＣシグナリングで通知してもよい。たとえば、接続要求応答に含める情報の一部または全部を、ＰＳＳＣＨに含めて送信し、該ＰＳＳＣＨのスケジューリング情報と、接続要求応答に含める情報の残りとを、ＰＳＣＣＨに含めて通知してもよい。
接続要求応答のためのリソース設定に、接続要求シグナリングに含まれる接続要求応答用リソース設定に関する情報を用いてもよい。または、ターゲットＵＥが接続要求応答用にリソース設定を行ってもよい。接続要求応答用リソース設定に関する情報が含まれない場合に有効である。
データ送信用スケジューリングのための信号／チャネルを設ける。ＳＬでの送信が発生したＵＥは、データ送信用スケジューリングのための信号／チャネルを送信する。該信号／チャネルに含める情報として以下に５つの具体例を示す。
（１）データおよび／あるいはフィードバック送信用リソーススケジューリング情報。
（２）サービスに関する情報。
（３）ターゲットＵＥ（双方向通信の対向するＵＥ）に関する情報。
（４）ソースＵＥ（自ＵＥ）に関する情報。
（５）（１）から（４）の組合せ。
前述の（１）のデータおよび／あるいはフィードバック送信用リソーススケジューリング情報として、ソースＵＥからターゲットＵＥへの送信用リソースアロケーション情報、および／あるいは、ターゲットＵＥからソースＵＥへの送信用リソースアロケーション情報を含めるとよい。該リソースアロケーション情報として、データ送信用のリソースアロケーション情報、および／あるいは、フィードバックあるいは報告等の送信用リソースアロケーション情報を含めてもよい。データ送信は、初送データの送信に限らず、繰返し送信、再送データの送信であってもよい。これらの情報を適宜組合せて、データおよび／あるいはフィードバック送信用スケジューリング情報に含めるとよい。
データ送信用スケジューリング情報を送信するための信号／チャネルを新たに設けてもよい。他の方法として、ＰＳＣＣＨを用いてもよい。たとえば、接続要求応答に含める情報を、ＰＳＣＣＨに含めて送信してもよい。
あるいは、接続要求応答に含める情報を、ＲＲＣシグナリングで通知してもよいし、ＭＡＣシグナリングで通知してもよい。たとえば、接続要求応答に含める情報の一部または全部を、ＰＳＳＣＨに含めて送信し、該ＰＳＳＣＨのスケジューリング情報と、接続要求応答に含める情報の残りとを、ＰＳＣＣＨに含めて通知してもよい。
データ送信用スケジューリング情報の送信方法に、送信の意思を示すための信号／チャネルの送信方法を適用してもよい。
データ送信用信号／チャネルを設ける。ＳＬでの送信が発生したＵＥは、データ送信用信号／チャネルを送信する。データ送信用信号／チャネルの送信は、データ送信用スケジューリング情報に従って行われてもよい。データ送信用信号／チャネルに含める情報として以下に７つの具体例を示す。
（１）データ。
（２）ＲＳ。
（３）Ａｃｋ／Ｎａｃｋ。
（４）ＣＳＩ。
（５）ＳＲ。
（６）ＢＳＲ。
（７）（１）から（６）の組合せ。
前述の（２）のＲＳは、データ復調用のＲＳであってもよい。あるいは、前述の（２）のＲＳは、チャネル評価用のＲＳであってもよく、たとえば、ＣＳＩ－ＲＳ、ＳＲＳであってもよい。あるいは、前述の（２）のＲＳは、ポジショニング用のＲＳであってもよい。ＲＳは、データが含まれるチャネルとは別に送信してもよい。（３）のＡｃｋ／Ｎａｃｋ、（４）のＣＳＩ、（５）のＳＲ、（６）のＢＳＲはそれぞれ、単独で送信してもよいし、データと組み合わせて送信してもよい。（３）のＡｃｋ／Ｎａｃｋ等をデータとピギーバックして、データ送信用チャネルで送信してもよい。
データ送信用信号／チャネルを新たに設けてもよい。他の方法として、ＰＳＳＣＨを用いてもよい。
図２９は、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第１例である。図２９は、ＵＥ＿Ａにおいて、ＵＥ＿ＢへのＳＬでの送信データが発生した場合について示している。ＵＥ＿ＡとＵＥ＿Ｂとの間でユニキャストの双方向通信が行われる。ユニキャスト通信までのシーケンスとして、対向ＵＥ検出フェーズと、接続設立フェーズと、データ送信フェーズとを設けてもよい。
図２９の例では、対向ＵＥ検出フェーズは、ステップＳＴ５１０３からステップＳＴ５１０６までのシーケンスからなる。接続設立フェーズはステップＳＴ５１０７からステップ５１０８までのシーケンスからなる。データ送信フェーズはステップＳＴ５１１０からステップＳＴ５１１２までのシーケンスからなる。データ送信フェーズでユニキャスト通信が行われる。
対向ＵＥ検出フェーズおよび／または接続設立フェーズは、制御プレインの処理としてもよい。対向ＵＥ検出フェーズおよび／または接続設立フェーズの通信には、制御プレインのシグナリングを用いてもよい。ＳＬ用のＲＲＣプロトコルを設けてもよい。対向ＵＥ検出フェーズおよび／または接続設立フェーズは、ＳＬ用ＲＲＣプロトコルでの処理としてもよい。このように制御用の処理とすることで、２つのＵＥ間でのユニキャスト通信までの制御処理を容易にすることができる。
ステップＳＴ５１０１で、ＵＥ＿Ａにおいて、ＵＥ＿ＢへのＳＬでの送信データが発生する。ステップＳＴ５１０２で、ＵＥ＿Ａは、送信の意思を示すための信号／チャネル送信用のリソースのセンシング、リソース選択、リソースリザベーションを行う。この際、ＵＥ＿Ａは、存在を示すための信号／チャネル用のリソースのセンシング、リソース選択、リソースリザベーションを行ってもよい。
ステップＳＴ５１０３で、ＵＥ＿Ａは送信の意思を示すための信号／チャネルを送信する。ＵＥ＿Ａは該信号／チャネルをブロードキャストで送信してもよい。これにより、ＵＥ＿Ａは送信データがあることを示すことができる。ステップＳＴ５１０４で、ＵＥ＿Ｂは、ＵＥ＿Ａからの送信の意思を示すための信号／チャネルを受信し、それに含まれる情報から、ＵＥ＿Ａがターゲットあるいはターゲット候補であることを検出する。
ステップＳＴ５１０５で、ＵＥ＿ＢはＵＥ＿Ａに対して存在を示すための信号／チャネルを送信する。該信号／チャネルにソースＵＥの識別子情報を含めることで、該信号／チャネルがＵＥ＿Ａに対する送信であることを示してもよい。あるいは、存在を示すための信号／チャネルの送信用リソースの設定に、ステップＳＴ５１０３で通知された存在応答用のリソース設定情報を用いることで、該信号／チャネルがＵＥ＿Ａに対する送信であることを示してもよい。
複数のＵＥがターゲット候補となってもよく、複数のＵＥがＵＥ＿Ａに対して存在を示すための信号／チャネルを送信してもよい。
ステップＳＴ５１０６で、ＵＥ＿Ａはユニキャストの双方向通信の対向ＵＥを検出する。ＵＥ＿Ａは一度検出したＵＥを記憶しておいてもよい。ＵＥ＿Ａは一度検出したＵＥを、所定の期間、記憶してもよい。たとえば、ＵＥ＿Ａは、所定の期間内に対向ＵＥを検出できなかった場合は、送信の意思を示すための信号／チャネルの送信を停止してもよい。前述の方法を適用してもよい。また、ＵＥ＿Ａは、対向ＵＥを検出した場合、送信の意思を示すための信号／チャネルの送信を停止してもよい。
ステップＳＴ５１０７で、ＵＥ＿Ａは、対向するＵＥ＿Ｂに対して接続要求を送信する。該接続要求を受信したＵＥ＿Ｂは、ステップＳＴ５１０８でＵＥ＿Ａに対して接続要求応答を送信する。図２９の例では、ＵＥ＿Ｂは接続要求応答として接続許可情報を通知する。接続要求用のリソースとして、ステップＳＴ５１０２でリザーブしたリソースを用いてもよい。接続要求応答用のリソースとして、ステップＳＴ５１０２でリザーブした存在応答用のリソースを用いてもよい。接続設立処理のためのリソース設定処理を省略することが可能となる。
ＵＥ＿Ａは、接続要求を送信する前に、新たに、接続要求用のリソースおよび接続要求応答用のリソースのセンシング、リソース選択、リソースリザベーションを行ってもよい。接続設立処理に適したリソース設定が可能となる。
ステップＳＴ５１１０で、ＵＥ＿ＡはＵＥ＿Ｂに対して、データ送信用スケジューリングのための信号／チャネルを送信する。データ送信用スケジューリング情報を、ＰＳＣＣＨに含めて通知する。ステップＳＴ５１１１で、ＵＥ＿Ｂは、自ＵＥ宛のデータ送信用スケジューリング情報が含まれるＰＳＣＣＨを検出する。ステップＳＴ５１１２で、ＵＥ＿Ｂは、検出したＰＳＣＣＨに含まれるデータ送信用スケジューリング情報に従って、ＵＥ＿Ａからのデータを受信する。
また、ステップＳＴ５１１２で、ＵＥ＿Ｂは、ＵＥ＿Ａから受信したデータに対するＨＡＲＱフィードバックを、ＵＥ＿Ａに対して送信してもよい。ＵＥ＿Ｂは、検出したＰＳＣＣＨに含まれるフィードバック用スケジューリング情報に従って、フィードバックを送信する。
この他に、ステップＳＴ５１１２で、ＵＥ＿ＢはＵＥ＿Ａに対して、ＣＳＩ報告を送信してもよい。また、ＵＥ＿ＢはＵＥ＿Ａに対して、データを送信してもよい。ＵＥ＿Ｂは、検出したＰＳＣＣＨに含まれる、ＵＥ＿ＢからＵＥ＿Ａへのリソーススケジューリング情報に従って、より具体的にはＣＳＩ報告用リソーススケジューリング情報、あるいは、データ送信用リソーススケジューリング情報に従って、ＣＳＩあるいはデータを送信する。ＵＥ＿ＡからＵＥ＿Ｂに対して送信するＨＡＲＱフィードバックやＣＳＩ報告、あるいは再送データも同様に送信するとよい。
ＵＥ＿Ａは、データ送信用リソーススケジューリング情報を送信する前に、新たに、ステップＳＴ５１０９で、ステップＳＴ５１１０のデータ送信用リソーススケジューリング用のリソース、および、ステップＳＴ５１１２のユニキャスト通信用のリソースのセンシング、リソース選択、リソースリザベーションを行ってもよい。ユニキャスト通信に適したリソース設定が可能となる。
データ送信用リソーススケジューリング用のリソースおよびユニキャスト通信用のリソースに、ステップＳＴ５１０２や接続要求前にリザーブしたリソースを用いてもよい。リソース設定処理を省略することが可能となる。
一つのＵＥがリソース設定を行う場合について、データ送信用スケジューリング方法を開示する。
ＵＥ＿ＡはＵＥ＿Ｂに対して、初送データ送信に関連するＰＳＣＣＨで、ＵＥ＿ＡからＵＥ＿Ｂへ送信するための初送用のリソーススケジューリング情報と、フィードバック用のリソーススケジューリング情報と、再送用のリソーススケジューリング情報とを通知する。
また、ＵＥ＿ＡはＵＥ＿Ｂに対して、ＵＥ＿ＢからＵＥ＿Ａへ送信するための初送用のリソーススケジューリング情報と、フィードバック用のリソーススケジューリング情報と、再送用のリソーススケジューリング情報とを通知する。これらの情報は、ＵＥ＿ＡからＵＥ＿Ｂに対して行われる初送データ送信に関連するＰＳＣＣＨで通知してもよい。
ＵＥ＿ＢからＵＥ＿Ａへ送信するための初送用のリソーススケジューリング情報と、フィードバック用のリソーススケジューリング情報と、再送用のリソーススケジューリング情報について、ＵＥ＿ＢからＵＥ＿Ａに対してＳＲあるいはＢＳＲが通知された後に、ＵＥ＿ＡからＵＥ＿Ｂにリソース設定および／または通知が行われてもよい。ＵＥ＿Ｂで送信データ発生が無いときにリソース設定を行わなくて済む。このため、リソース使用効率を向上させることが可能となる。
一つのＵＥが双方向の送信用リソース設定を行い、対向するＵＥに通知することで、実施の形態３で開示した効果と同様の効果を得ることができる。
データを送信する各ＵＥがリソース設定を行う場合について、データ送信用スケジューリング方法を開示する。
ＵＥ＿ＡはＵＥ＿Ｂに対して、初送データ送信に関連するＰＳＣＣＨで、ＵＥ＿ＡからＵＥ＿Ｂへ送信するための初送用のリソーススケジューリング情報と、フィードバック用のリソーススケジューリング情報と、再送用のリソーススケジューリング情報とを通知する。
また、ＵＥ＿ＢはＵＥ＿Ａに対して、初送データ送信に関連するＰＳＣＣＨで、ＵＥ＿ＢからＵＥ＿Ａへ送信するための初送用のリソーススケジューリング情報と、フィードバック用のリソーススケジューリング情報と、再送用のリソーススケジューリング情報とを通知する。
データを送信する各ＵＥが送信用リソース設定を行い、対向するＵＥに通知することで、実施の形態３で開示した効果と同様の効果を得ることができる。
前述に開示した方法では、再送用のリソーススケジューリング情報を、初送データ送信に関連するＰＳＣＣＨに含めて通知することを示した。他の方法として、再送用のリソーススケジューリング情報を、再送データ送信に関連するＰＳＣＣＨに含めて通知してもよい。このようにすることで、再送発生後にリソース設定を通知可能となる。たとえば、通信品質が良好で再送が発生しない場合に、再送用にリソースリザベーションを行う必要がなく、リソース使用効率を向上できる。
リソーススケジューリング情報に含める情報として以下に７つの例を開示する。
（１）リソースアロケーション情報。
（２）ＭＣＳ情報。
（３）初送か再送かを示す情報。
（４）リダンダンシーバージョン（RV）情報。
（５）ターゲットＵＥに関する情報。
（６）サービスに関する情報。
（７）（１）から（６）の組合せ。
前述したデータ送信用スケジューリングのための信号／チャネルに含める情報と重複している情報は、どちらかの情報のみとしてもよい。重複する情報を省略することで情報量の削減が図れる。
前述の（１）のリソースアロケーション情報は、リソースの時間（タイミング）情報、リソースの周波数情報、リソースのオフセット情報等を含むとよい。リソースの時間情報は、周期情報であってもよい。
フィードバック用リソースのオフセット情報は、たとえば、データ送信タイミングからの時間オフセットであってもよい。該データ送信タイミングは、初送データ送信タイミングであってもよいし、または、再送データ送信タイミングであってもよい。時間の単位は、秒だけでなく、スロット、サブフレーム、ミニスロット、ＴＴＩ等であってもよい。
このようにすることで、データ送信からフィードバックまでのタイミングオフセットを、データ送信に関連してフィードバックを送信するＵＥに通知することが可能となる。また、初送データ送信タイミングからのオフセットと、再送データ送信タイミングからのオフセットとを設けることで、初送に対するフィードバックのタイミングと、再送に対するフィードバックのタイミングを個別に設定可能となる。
再送用のリソースのオフセット情報は、たとえば、データ送信タイミングからの時間オフセットであってもよい。データ送信タイミングは、初送データ送信タイミングであってもよいし、または、フィードバック送信タイミングであってもよいし、または、再送データ送信タイミングであってもよい。時間の単位は、秒だけでなく、スロット、サブフレーム、ミニスロット、ＴＴＩ等であってもよい。
たとえば、再送用スケジューリング情報を送信するタイミングを再送データを送信するタイミングと異ならせてもよく、このような場合、再送用リソースのオフセット情報を通知することで、再送データを受信可能となる。柔軟なスケジューリングが可能となる。
このようにすることで、データ送信、それに対するフィードバック、および再送の一連の送信用リソースの設定と、対向するＵＥへの通知を行うことが可能となる。それにより、ＨＡＲＱフィードバック制御が可能となり、ユニキャスト通信の通信品質を向上させることが可能となる。
フィードバック用リソースの設定および通知方法について、他の方法を開示する。フィードバック用リソースのタイミング情報と周波数情報を、関連するデータ送信元であるＵＥ＿Ａが設定してもよい。ＵＥ＿Ａがリソース設定を行うとよい。あるいは、フィードバック用リソースのタイミング情報のみＵＥ＿Ａが設定し、フィードバック用リソースの周波数情報は、フィードバック送信元であるＵＥ＿Ｂが設定するとよい。ＵＥ＿ＡからＵＥ＿Ｂに対して、フィードバック用リソースのタイミング情報を通知するとよい。ＵＥ＿Ｂが、ＵＥ＿Ａから通知されたタイミング情報を用いて、リソース設定を行うとよい。
フィードバック用リソース設定のため、所定のリソースセンシング期間を設けてもよい。該期間は、データ用リソース設定のためのセンシング期間と別に設けるとよい。それらの期間を別々に設けることで、たとえば、フィードバック用のリソースが設けられた場合など、該フィードバック用のリソースのセンシングのみを行うことが可能となる。このため、センシング処理を簡略化可能となる。
フィードバック用リソースのタイミングとして、最小オフセットを設定してもよい。オフセット情報は、たとえば、データ送信タイミングからの時間オフセットとしてもよい。時間の単位は、秒だけでなく、スロット、サブフレーム、ミニスロット、ＴＴＩ等であってもよい。最小オフセットはＵＥケーパビリティ情報に含めて、ユニキャスト通信を行う対向するＵＥに通知しておいてもよい。あるいは、最小オフセットはｇＮＢに通知しておいてもよい。このようにすることで、フィードバック送信タイミングとして、データ送信から最適なオフセットを設定可能となる。
このようにすることで、ＳＬにおいて対向するＵＥ（ＵＥ＿ＡとＵＥ＿Ｂ）間でユニキャスト通信用の接続設立が可能となる。このため、対向するＵＥ間でのユニキャスト通信が可能となる。
接続設立フェーズ以前において、ユニキャスト通信用のリソースリザベーションを実施してもよい。ユニキャスト通信用のリソース設定を、該リザベーションしたリソースから選択して設定するとよい。データ送信、それに対するフィードバック、および再送の一連の送信用リソースのリソース設定において、接続設立フェーズ以前においてリザベーションしたリソースを用いるとよい。
このようにすることで、たとえば、一つのユニキャスト接続において複数のユニキャスト通信を行うような場合に、ユニキャスト通信毎にリソースのリザベーションを行わなくて済む。リソース設定の処理を簡略化できる。
たとえば、接続設立フェーズ以前においてリザベーションするリソースを、ユニキャスト通信でリザベーションするリソースよりも広い周波数範囲で設定する。ＵＥ＿Ａは、接続設立フェーズ以前においてリザベーションしたリソースで、チャネル評価用の信号を送信してもよい。チャネル評価用の信号はＣＳＩ－ＲＳであってもよい。あるいは、ＤＭＲＳを用いてもよい。ＵＥ＿Ｂは、チャネル評価用信号を測定して、チャネル状態をＵＥ＿Ａに報告する。チャネル状態の報告をＣＳＩとしてもよい。
このようにすることで、ＵＥ＿Ａは、データ送信に用いているリソースよりも広い周波数範囲のＣＳＩを、ＵＥ＿Ｂから受信できる。このため、ＵＥ＿Ａは、データ送信に用いているリソースの通信品質が悪化した場合に、データ送信に用いているリソースを変更可能となる。より良好な通信品質のリソースをデータ通信用にリソース設定することが可能となり、通信品質を向上させることが可能となる。
逆方向の通信品質測定においても同様である。たとえば、ＵＥ＿Ａは、接続設立フェーズ以前においてリザベーションしたリソースで、サウンディング用に信号、たとえばＳＲＳのリソース設定を行う。ＵＥ＿Ｂは該リソースでＳＲＳを送信する。このようにすることで、ＵＥ＿Ａは、データ送信に用いているリソースよりも広い周波数範囲のＳＲＳを、ＵＥ＿Ｂから受信できる。このため、ＵＥ＿Ａは、ＵＥ＿Ｂからのデータ送信に用いているリソースの通信品質が悪化した場合に、データ送信に用いているリソースを変更可能となる。より良好な通信品質のリソースをデータ通信用にリソース設定することが可能となり、通信品質を向上させることが可能となる。
前述に、ユニキャスト通信までの処理を開示した。次にユニキャスト通信を終了する処理を開示する。ユニキャスト通信の終了処理を実行する条件を設ける。ユニキャスト通信終了処理実行条件として以下に３つの例を開示する。
（１）送信データが無くなった場合。たとえば、送信が所定の期間あるいは回数連続で無くなった場合、送信データが無くなったと判断してもよい。
（２）サービスが終了された場合。
（３）上位レイヤから終了が通知された場合。
ユニキャスト通信終了処理について開示する。ＵＥは、接続終了シグナリングを設けて対向ＵＥに通知する。該通知を受信したＵＥは、ユニキャスト通信用にリザベーションしていたリソースを解放する。たとえば、ＳＬ用のＰＨＹ、ＭＡＣ、ＲＬＣ、ＰＤＣＰおよび／またはＳＤＡＰで設定をリセットするとしてもよい。
ユニキャスト通信終了の完了を示すシグナリングを設けてもよい。ユニキャスト通信用にリザベーションしていたリソースを解放したＵＥは、ユニキャスト通信終了の完了を示すシグナリングを対向するＵＥに通知する。ユニキャスト通信終了完了シグナリングを受信したＵＥは、ユニキャスト通信用にリザベーションしていたリソースを解放する。同様に、たとえば、ＳＬ用のＰＨＹ、ＭＡＣ、ＲＬＣ、ＰＤＣＰおよび／またはＳＤＡＰで設定をリセットするとしてもよい。
このようにすることで、ユニキャスト通信終了処理を実施可能となる。このため、ユニキャスト通信用にリザベーションしていたリソースを解放することが可能となる。他のＵＥが解放されたリソースを使用することが可能となるため、リソースの使用効率を向上させることができる。
ユニキャスト接続を維持したままユニキャスト通信を終了してもよい。たとえば、再度ユニキャスト通信を実施する場合は、データ送信フェーズから行ってもよい。後述する図３５で開示するような方法を用いてもよい。また、ユニキャスト通信が中断するような場合でも、ユニキャスト接続を維持したままとしてもよい。たとえば、ユニキャスト通信が中断するような場合として、長期間データ通信が行われないような場合、あるいは、ＵＥ間での同期がはずれたような場合がある。
ＳＬにおいてリンクフェイラを設けてもよい。所定の期間ＵＥ間で所定の信号／チャネルを受信できない場合にリンクフェイラとする。このようなユニキャスト通信においてリンクフェイラが生じるような場合も、所定の期間ユニキャスト接続を維持してもよい。所定の期間を過ぎてもなおリンクフェイラ状態が続いた場合は、ユニキャスト接続を終了するとしてもよい。
このようにすることで、ユニキャスト接続処理が頻繁に生じるのを回避できる。ユニキャスト接続処理の回数を低減できるため、ＵＥ間のシグナリングを低減可能となる。ユニキャスト接続に使用されるリソースを低減可能となり、他のＵＥが利用可能なリソースを増大させることができる。リソース使用効率を向上できる。また、ユニキャスト接続処理が頻繁に生じるのを回避できるため、ＵＥでの処理が簡易になる。
図３０は、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第２例である。図３０において、図２９と共通するステップについては同じステップ番号を付し、共通する説明を省略する。図３０は、図２９に比べて、存在を示すための信号／チャネルの送信を削減した例である。存在を示すための信号／チャネルの送信の代わりに、接続要求を送信するとよい。
ステップＳＴ５１０３で、ＵＥ＿Ａは送信の意思を示すための信号／チャネルを送信する。該信号／チャネルは、存在を示すための信号／チャネル送信用リソース設定ではなく、接続要求用リソース設定を含むとよい。ステップＳＴ５１０４で、ＵＥ＿Ｂは、ＵＥ＿Ａからの送信の意思を示すための信号／チャネルを受信し、それに含まれる情報から、ＵＥ＿Ａがターゲットあるいはターゲット候補であることを検出する。
ターゲットＵＥ（ＵＥ＿Ｂ）からソースＵＥ（ＵＥ＿Ａ）への接続要求を示すための信号／チャネルを設ける。ステップＳＴ５２０１で、ＵＥ＿ＢはＵＥ＿Ａに対して、接続要求を示すための信号／チャネルを送信する。接続要求を示すための信号／チャネルは、存在を示すための信号／チャネルに含める情報に加え、ＳＲ、ＢＳＲなどの情報を含んでもよい。ＵＥ＿ＢからＵＥ＿Ａに対して送信するデータが存在する場合に、ＳＲ、ＢＳＲなどを、接続要求を示すための信号／チャネルに含めて送信するとよい。また、存在を示す情報のかわりに、接続要求であることを示す情報を、接続要求を示すための信号／チャネルに含めてもよい。
このようにすることで、存在を示す情報の送信ステップを削減できる。また、ＵＥ＿ＡからＵＥ＿Ｂへの接続要求送信ステップも削減可能となる。このため、接続設立に要するシグナリング量を削減することが可能となる。また、図３０の例は、ＳＲ、ＢＳＲなどを含めることが可能な接続要求となるため、複数のＵＥがターゲットＵＥとなる場合よりも一つのＵＥがターゲットＵＥとなる場合により適している。
図３１は、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第３例である。図３１において、図２９と共通するステップについては同じステップ番号を付し、共通する説明を省略する。図３１は、図２９に比べて、送信の意思を示すための信号／チャネル、および、存在を示すための信号／チャネルの送信を削減した例である。ステップＳＴ５１０１においてＳＬでの送信データが発生したＵＥ＿Ａは、ステップＳＴ５３０１において、接続要求送信用および／あるいは接続要求応答用のリソースセンシング、リソース選択、リソースリザベーションを行い、ステップＳＴ５１０７において接続要求シグナリングを送信する。
このように、図３１に開示した方法は、対向ＵＥ検出フェーズを省略した方法である。接続設立フェーズで、対向ＵＥの検出をあわせて実施する。複数のＵＥがターゲットＵＥとなる場合よりも一つのＵＥがターゲットＵＥとなる場合により適している。
ＵＥは、一度ユニキャスト接続を実施したＵＥを記憶しておいてもよい。ＵＥは、一度ユニキャスト接続を実施したＵＥを、所定の期間、記憶しておいてもよい。ＵＥは、一度ユニキャスト接続を実施したＵＥに対して優先的に接続処理を行うとしてもよい。このような場合、対向ＵＥ検出フェーズを省略してもよい。ＵＥ＿Ａは、接続要求を実施し、接続応答を受信できない場合は、対向ＵＥ検出フェーズを行うとしてもよい。一度ユニキャスト接続したＵＥは、近傍に存在する可能性が高いため、対向ＵＥ検出フェーズを行わずに接続設立処理を実施可能となる可能性が高い。したがって、対向ＵＥ検出フェーズを省略できる可能性は高く、ＵＥ間でのシグナリングを低減可能となる。他ＵＥが対向ＵＥ検出フェーズ用のリソースを使用できる場合が生じるため、リソース使用効率を向上できる。
図３２は、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第４例である。図３２において、図２９、図３１と共通するステップについては同じステップ番号を付し、共通する説明を省略する。図３２の例では、ターゲットとなるべきＵＥが最初に、存在を示すための信号／チャネルを送信する。ＳＬでの送信データが発生したＵＥは、他のＵＥから送信されている存在を示すための信号／チャネルを受信して、ターゲットＵＥを検出する。
ステップＳＴ５４０１で、ＵＥ＿Ｂが、存在を示すための信号／チャネル送信用のリソースセンシング、リソース選択、リソースリザベーションを実施する。ステップＳＴ５４０２でＵＥ＿Ｂは、存在を示すための信号／チャネルを送信する。該信号／チャネルはブロードキャストで送信するとよい。存在を示すための信号／チャネルの送信方法には、前述の送信の意思を示すための信号／チャネルの送信方法を適用するとよい。停止条件としては、存在を示すための信号／チャネルのかわりに、接続要求を用いればよい。
ステップＳＴ５１０１で、ＳＬでの送信データが発生したＵＥ＿Ａは、他のＵＥから送信されている存在を示すための信号／チャネルを受信して（ステップＳＴ５４０２）、ターゲットＵＥを検出する（ステップＳＴ５１０６）。ステップＳＴ５３０１でＵＥ＿Ａは、接続要求送信用および／あるいは接続要求応答用のリソースセンシング、リソース選択、リソースリザベーションを行い、ステップＳＴ５１０７で接続要求シグナリングを送信する。
このようにすることで、ＳＬでの送信データが発生したＵＥが送信の意思を示すための信号／チャネルを送信しなくて済む。このため、ＳＬでの送信データ発生から接続設立フェーズまでの遅延時間を削減可能となる。
ＳＬでの通信をできない状態のＵＥは、存在を示すための信号／チャネルを送信しないとしてもよい。ユニキャスト通信またはユニキャスト接続できない状態のＵＥは、存在を示すための信号／チャネルを送信しないとしてもよい。ＳＬでの通信をできない状態のＵＥは、たとえば、ＳＬ通信のケーパビリティの無いＵＥである。また、たとえばＵＥにおける許容通信処理負荷を超えてしまうような場合、ＵＥはＳＬでの通信をできない状態にある。このようにすることで、存在を示すための信号／チャネルを送信するＵＥを限定することが可能となる。ＵＥ間の信号／チャネルあるいはシグナリングを低減可能となる。ＵＥ間の信号／チャネルあるいはシグナリングに用いられるリソースの使用量を低減できる。
図３３は、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第５例である。図３３において、図２９、図３０と共通するステップについては同じステップ番号を付し、共通する説明を省略する。図３３の例では、ターゲットとなるべきＵＥが最初に、接続要求シグナリングを送信する。ＳＬでの送信データが発生したＵＥは、他のＵＥから送信されている接続要求シグナリングを受信して、ターゲットＵＥを検出する。図３３は図３２に比べて、存在を示すための信号／チャネルの送信を削減した例である。存在を示すための信号／チャネルの送信の代わりに、接続要求を送信するとよい。
ステップＳＴ５５０１で、ＵＥ＿Ｂが、接続要求シグナリング送信用のリソースセンシング、リソース選択、リソースリザベーションを実施する。ステップＳＴ５２０１で、ＵＥ＿Ｂは、接続要求を示すための信号／チャネルを送信する。該信号／チャネルはブロードキャストで送信してもよい。接続要求を示すための信号／チャネルに含める情報は、存在を示すための信号／チャネルに含める情報に加え、ＳＲ、ＢＳＲなどの情報を含んでもよい。ＵＥ＿ＢからＵＥ＿Ａに対して送信するデータが存在する場合に、ＳＲ、ＢＳＲなどを、接続要求を示すための信号／チャネルに含めて送信するとよい。また、存在を示す情報のかわりに、接続要求であることを示す情報を、接続要求を示すための信号／チャネルに含めてもよい。
接続要求シグナリングの送信方法には、前述の送信の意思を示すための信号／チャネルの送信方法を適用するとよい。停止条件としては、存在を示すための信号／チャネルのかわりに、データ送信用リソーススケジューリングを用いればよい。
ステップＳＴ５１０１で、ＳＬでの送信データが発生したＵＥ＿Ａは、他のＵＥから送信されている接続要求シグナリングを受信して（ステップＳＴ５２０１）、ターゲットＵＥを検出する。ステップＳＴ５１０９でＵＥ＿Ａは、データ送信用リソーススケジューリング用および／あるいはユニキャスト通信用のリソースセンシング、リソース選択、リソースリザベーションを行い、ステップＳＴ５１１０でデータ送信用スケジューリングを送信する。
このようにすることで、ＳＬでの送信データが発生したＵＥが送信の意思を示すための信号／チャネルを送信しなくて済む。また、接続要求の前に、存在を示すための信号／チャネルを送信することも不要となる。このため、ＳＬでの送信データ発生からデータ送信フェーズまでの遅延時間を削減可能となる。
図３４は、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第６例である。図３４において、図２９、図３２と共通するステップについては同じステップ番号を付し、共通する説明を省略する。図３４の例では、ターゲットとなるべきＵＥが最初に、存在を示すための信号／チャネルを送信する。ＳＬでの送信データが発生したＵＥは、他のＵＥから送信されている存在を示すための信号／チャネルを受信して、ターゲットＵＥを検出する。
また、図３４の例では図３２の例に比べて、接続設立フェーズが省略されている。ＳＬでの送信データが発生したＵＥは、ターゲットＵＥ検出後、データ送信用スケジューリングを送信する。ＳＬでの送信データが発生したＵＥは、ターゲットＵＥ検出後、データ送信フェーズの処理を実施する。
ステップＳＴ５４０１で、ＵＥ＿Ｂが、存在を示すための信号／チャネル送信用のリソースセンシング、リソース選択、リソースリザベーションを実施する。ステップＳＴ５４０２でＵＥ＿Ｂは、存在を示すための信号／チャネルを送信する。該信号／チャネルはブロードキャストで送信するとよい。存在を示すための信号／チャネルの送信方法には、前述の送信の意思を示すための信号／チャネルの送信方法を適用するとよい。停止条件としては、存在を示すための信号／チャネルのかわりに、データ送信用スケジューリングを用いればよい。
ステップＳＴ５１０１で、ＳＬでの送信データが発生したＵＥ＿Ａは、他のＵＥから送信されている存在を示すための信号／チャネルを受信して（ステップＳＴ５４０２）、ターゲットＵＥを検出する（ステップＳＴ５１０６）。ステップＳＴ５１０９でＵＥ＿Ａは、データ送信用スケジューリング送信用リソースと、ユニキャスト通信用リソースのリソースセンシング、リソース選択、リソースリザベーションを行い、ステップＳＴ５１１０でデータ送信用スケジューリングを送信する。
このようにすることで、接続設立フェーズを省略することが可能となる。このため、ＳＬでの送信データ発生からデータ送信フェーズまでの遅延時間を削減可能となる。
図３５は、ＳＬのユニキャスト用の２つのＵＥ間でのユニキャスト通信までのシーケンスの第７例である。図３５において、図２９と共通するステップについては同じステップ番号を付し、共通する説明を省略する。図３５の例では、ＳＬでの送信データが発生したＵＥは、データ送信用スケジューリングを送信する。図３５は、図２９に比べて、送信の意思を示すための信号／チャネルの送信から接続要求応答までの処理を省略した例である。また、図３５は、対向ＵＥ検出フェーズ、接続設立フェーズを省略した例である。データ送信フェーズで、対向ＵＥの検出をあわせて実施する。複数のＵＥがターゲットＵＥとなる場合よりも一つのＵＥがターゲットＵＥとなる場合により適している。
ステップＳＴ５１０１で、ＳＬでの送信データが発生したＵＥ＿Ａは、ステップＳＴ５１０９でデータ送信用スケジューリング送信用リソースと、ユニキャスト通信用リソースのリソースセンシング、リソース選択、リソースリザベーションを行い、ステップＳＴ５７０１でデータ送信用スケジューリングを送信する。データ送信用スケジューリングはブロードキャストで送信してもよい。ステップＳＴ５１１１で、ＵＥ＿Ｂは、自ＵＥ宛のデータ送信用スケジューリング情報が含まれるＰＳＣＣＨを検出する。ステップＳＴ５１１２で、ＵＥ＿Ｂは、検出したＰＳＣＣＨに含まれるデータ送信用スケジューリング情報に従って、ＵＥ＿Ａからのデータを受信する。
ステップＳＴ５１１２で、ＵＥ＿Ｂは、ＵＥ＿Ａから受信したデータに対するＨＡＲＱフィードバックやＣＳＩ報告、および／あるいは、データを、ＵＥ＿Ａに対して送信してもよい。
このようにすることで、対向ＵＥ検出フェーズ、接続設立フェーズを省略することが可能となる。このため、ＳＬでの送信データ発生からデータ送信フェーズまでの遅延時間を削減可能となる。
ＵＥは、一度ユニキャスト通信を実施したＵＥを記憶しておいてもよい。ＵＥは、一度ユニキャスト通信を実施したＵＥを、所定の期間、記憶しておいてもよい。ＵＥは、一度ユニキャスト通信を実施したＵＥに対して優先的に接続処理を行うとしてもよい。このような場合、対向ＵＥ検出フェーズ、接続設立フェーズを省略してもよい。ＵＥ＿Ａは、データ送信用リソーススケジューリングを送信し、フィードバックを受信できない場合は、対向ＵＥ検出フェーズ、あるいは、接続設立フェーズを行うとしてもよい。一度ユニキャスト通信したＵＥは、近傍に存在する可能性が高いため、対向ＵＥ検出フェーズおよび／あるいは接続設立フェーズを行わずに接続設立処理を実施可能となる可能性が高い。したがって、対向ＵＥ検出フェーズ、接続設立フェーズが省略できる可能性は高く、ＵＥ間でのシグナリングを低減可能となる。他ＵＥが対向ＵＥ検出フェーズ、接続設立フェーズ用のリソースを使用できる場合が生じるため、リソース使用効率を向上できる。
データ送信フェーズにおいて、初送あるいは再送のデータ送信はブロードキャスト通信で実施し、フィードバックや報告等はユニキャスト通信で実施するようにしてもよい。データ送信時にターゲットＵＥを検出できていないような場合に初送あるいは再送のデータ送信をブロードキャスト通信で実施することで、該送信データをターゲットＵＥが検出可能となる。また、ターゲットＵＥは該送信データ（データ送信用リソーススケジューリングを含む）を受信することで、どのＵＥにフィードバックや報告等を送信するかを特定できるので、フィードバックや報告等はユニキャスト通信で実施するとよい。
実施の形態３の本変形例１で開示したような方法とすることで、ＳＬにおいて対向するＵＥ（ＵＥ＿ＡとＵＥ＿Ｂ）間でユニキャスト通信が可能となる。
ＵＥが複数のユニキャスト通信を行う場合、たとえば、複数のユニキャスト通信において送受信タイミングが同じになった場合、ハーフデュプレクス（Half-Duplex）通信のため、一つを除いて送受信不可能になってしまう。ここでは、このような課題を解決する方法を開示する。
ＵＥは一つのユニキャスト通信のための接続のみを行う。二つ以上のユニキャスト通信のための接続を禁止するとしてもよい。以降ユニキャスト通信のための接続をユニキャスト接続と称する場合もある。
既に一つのユニキャスト接続を行っているＵＥは、他のユニキャスト接続を行わない。また、既に一つのユニキャスト接続を行っているＵＥは、存在を示す信号／チャネルを送信しないとしてもよい。また、既に一つのユニキャスト接続を行っているＵＥは、二つ目のユニキャスト接続要求に対して拒否（reject）を応答してもよい。また、既に一つのユニキャスト接続を行っているＵＥは、データ送信用リソーススケジューリングを検索しないとしてもよい。
このようにすることで、ＵＥが二つ以上のユニキャスト通信を不可能とし、送受信不可能となる状態を避けることができる。
他の方法を開示する。優先順位が高いユニキャスト接続を優先する。
既に一つのユニキャスト接続を行っているＵＥは、より優先順位の高い他のユニキャスト接続を行う。この場合、元のユニキャスト接続は終了する。また、既に一つのユニキャスト接続を行っているＵＥは、より優先順位の高い他のユニキャスト接続において、存在を示す信号／チャネルを送信してもよい。この場合、元のユニキャスト接続は終了する。
また、既に一つのユニキャスト接続を行っているＵＥは、二つ目のユニキャスト接続の優先順位がより高い場合、該二つ目のユニキャスト接続要求に対して、承諾応答を通知してもよい。この場合、元のユニキャスト接続は終了する。なお、優先順位が低い場合は拒否（reject）を応答してもよい。また、既に一つのユニキャスト接続を行っているＵＥは、より優先順位の高い他のユニキャスト接続に対するデータ送信用リソーススケジューリングを検索するとしてもよい。この場合、元のユニキャスト接続は終了する。
このようにすることで、ＵＥが二つ以上のユニキャスト通信を不可能としつつ、より優先順位の高いユニキャスト通信の接続を実施可能となる。より優先順位の高いサービスを優先して通信することが可能となる。
前述のユニキャスト通信のための接続を、ユニキャスト通信と読み替えてもよい。たとえば、ＵＥは一つのユニキャスト通信のみを行うとしてもよい。二つ以上のユニキャスト通信を禁止するとしてもよい。このようにすることで、同様に、複数のユニキャスト通信に起因するリソースの重複によって送受信不可能となる状態を避けることができる。たとえば、ユニキャスト通信のための接続設立フェーズを省略するような場合に有効となる。
前述では、ＵＥが各種判断を行うことを示したが、ｇＮＢが各種判断を行ってＵＥを制御してもよい。ｇＮＢがリソースをスケジューリングするような場合に有効である。
他の方法を開示する。複数のユニキャスト接続を実施する。同一のＵＥ間で複数のユニキャスト接続を行う。同一のＵＥ間で複数のユニキャスト接続を禁止しない。たとえば、ＵＥ＿ＡとＵＥ＿Ｂとで複数のユニキャスト接続を実施してもよい。たとえば、図２９で開示したユニキャスト通信までの処理において、接続設立フェーズからの処理の複数を並行して行うとよい。
ＵＥ＿Ａおよび／またはＵＥ＿Ｂは、複数のユニキャスト接続が実施されることを認識している。ＵＥ＿Ａおよび／またはＵＥ＿Ｂは、各ユニキャスト通信で使用するリソースを認識可能となる。ＵＥ＿Ａおよび／またはＵＥ＿Ｂは各々、同一タイミングで送受信の重複が無いように、各ユニキャスト通信で使用するリソースを調整すると良い。このようにすることで、リソースの重複によって送受信不可能となる状態を避けつつ、複数のユニキャスト通信を可能とすることができる。
他の方法を開示する。複数のユニキャスト接続を実施する。ＵＥは、異なるＵＥとの間でユニキャスト接続を行ってもよい。たとえば、ＵＥ＿ＡとＵＥ＿Ｂとでユニキャスト接続を実施し、ＵＥ＿ＣとＵＥ＿Ｂとでユニキャスト接続を実施してもよい。このような場合にはリソースの重複によって送受信不可能となる状態が生じるが、このような課題を解決する方法を開示する。
リソースの再設定を要求するシグナリングを設ける。
一つのＵＥが複数のユニキャスト接続を行う場合、該ＵＥと各ユニキャスト通信において対向するＵＥがリソースセンシングを行う。該対向するＵＥがリソース設定を行うとしてもよい。たとえば、前述の例においては、ＵＥ＿Ｂが複数のユニキャスト接続を行うことになる。この例では、ＵＥ＿ＡとＵＥ＿Ｃとがリソースセンシングを行う。
リソースセンシングにより、ＵＥ＿Ｂが送受信するリソースタイミングが重複した場合は、リソース設定を行ったＵＥに対して、リソース再設定要求を行う。この例では、ＵＥ＿ＢがＵＥ＿Ａへ、あるいは、ＵＥ＿ＢがＵＥ＿Ｃへリソース再設定要求を通知する。リソース再設定要求は、リソースタイミングの再設定要求であってもよい。
リソース再設定要求を受信したＵＥは、リソースを再設定する。たとえば、ＵＥ＿ＡがＵＥ＿Ｂからリソース再設定要求を受信した場合、ＵＥ＿Ａは、たとえばリソースタイミングを変更するなどして、リソース再設定を行う。ＵＥ＿Ａは、再設定したリソース再設定を、ＵＥ＿Ｂに通知するとよい。リソース再設定要求シグナリングに、変更を要求するリソースタイミングを含めてもよい。ＵＥ＿Ａは、リソースを再設定する際に該リソースタイミングを避けることが可能となる。
リソースタイミングが重複したＵＥ、この例ではＵＥ＿Ｂが、リソース設定を変更するユニキャスト通信のリソースタイミングを変えて、リソース設定を行ってもよい。ＵＥ＿Ｂは、タイミングを変えて設定したリソース設定を、該ユニキャスト通信の対向するＵＥに対して通知する。たとえば、ＵＥ＿Ａとのユニキャスト通信のリソースタイミングを変更してリソース設定した場合は、ＵＥ＿ＢはＵＥ＿Ａに対して該リソース設定を通知する。ＵＥ＿Ａは該リソース設定でＵＥ＿Ｂとのユニキャスト通信を行う。
ＵＥ＿ＢがＵＥ＿ＡあるいはＵＥ＿Ｃのどちらにリソース再設定を要求するかの判断例を開示する。たとえば、ＵＥ＿Ｂは、後からリソース設定を通知されたＵＥに対して、リソース再設定を要求するものとする。あるいは、ＵＥ＿Ｂは、後から接続要求の通知されたＵＥに対して、リソース再設定を要求するものとしてもよい。あるいは、ＵＥ＿Ｂは、後から接続設立処理を行ったＵＥに対して、リソース再設定を要求するものとしてもよい。あるいは、ＵＥ＿Ｂは、後からユニキャスト通信用リソーススケジューリングを通知されたＵＥに対して、リソース再設定を要求するものとしてもよい。あるいは、ＵＥ＿Ｂは、優先順位の低いユニキャスト接続の対向するＵＥに対して、リソース再設定を要求するものとしてもよい。あるいは、ＵＥ＿Ｂは、要求される低遅延特性が大きいユニキャスト接続の対向するＵＥに対して、リソース再設定を要求するものとしてもよい。あるいは、ＵＥ＿Ｂは、要求される信頼性が低いユニキャスト接続の対向するＵＥに対して、リソース再設定を要求するものとしてもよい。
このようにすることで、リソースの重複によって送受信不可能となる状態を避けることができ、複数のユニキャスト通信が可能となる。
他の方法を開示する。ＵＥは、リソースセンシングの処理において、対向するＵＥへのＰＳＣＣＨが存在するか否かを検出する。たとえば、ＰＳＣＣＨのＳＣＩにターゲットＵＥの識別子が含まれる場合は、ＵＥは、対向するＵＥと同じＵＥ識別子が含まれるか否かを検出する。対向するＵＥと同じＵＥ識別子が含まれる場合は、ＵＥは、該ＰＳＣＣＨの中のリソースタイミングのリソースを、リソース選択候補から除外する。対向するＵＥと同じＵＥ識別子が含まれない場合、ＵＥは、通常のリソースセンシング処理、リソース選択処理、リソースリザベーション処理を実施すると良い。
このようにすることで、リソースの重複によって送受信不可能となる状態を避けることができ、複数のユニキャスト通信が可能となる。
一つのＵＥが複数のユニキャスト接続を行う場合、該ＵＥがリソースセンシングを行う。該ＵＥがリソース設定を行うとしてもよい。たとえば、前述の例においては、ＵＥ＿Ｂが複数のユニキャスト接続を行うことになる。この例では、ＵＥ＿Ｂがリソースセンシングを行う。
複数接続となることを示す情報を設ける。ＵＥ＿ＢがＵＥ＿ＡあるいはＵＥ＿Ｃへ、ＵＥ＿Ｂが複数接続となることを示す情報を通知する。たとえば、ＵＥ＿Ｂは、後からユニキャスト接続処理を行うＵＥに対して、複数接続となることを示す情報を通知してもよい。たとえば、後からユニキャスト接続処理を行うＵＥがＵＥ＿Ｃの場合、ＵＥ＿ＢはＵＥ＿Ｃに、複数接続となることを示す情報を通知する。
たとえば、存在を示す信号あるいは接続要求応答に、複数接続となることを示す情報を含めて通知してもよい。たとえば、ＵＥ＿ＢがＵＥ＿Ｃに対して、存在を示す信号あるいは接続要求応答を通知するような場合に、ＵＥ＿Ｂは、複数接続となることを示す情報を、存在を示す信号あるいは接続要求応答に含めて、通知してもよい。このようにすることで、シグナリング量が増大するのを防ぐことが可能となる。
複数接続となることを示す情報を受信したＵＥは、複数のユニキャスト接続を行うＵＥに対して、リソース設定を要求する。たとえば、複数接続となることを示す情報を受信したＵＥ＿Ｃは、ＵＥ＿Ｂに対して、リソース設定の要求を通知する。たとえば、複数接続となることを示す情報が含まれる存在を示す信号あるいは接続要求応答を受信したＵＥ＿Ｃは、ＵＥ＿Ｂに対して、リソース設定要求のシグナリングを通知する。
このようにすることで、リソースの重複によって送受信不可能となる状態を避けることができ、複数のユニキャスト通信が可能となる。
ＵＥが接続可能な最大ユニキャスト接続数を設けてもよい。該最大ユニキャスト接続数は、あらかじめ規格等で決められても良いし、ｇＮＢからＵＥに対して通知してもよいし、ＵＥに予め設定されてもよい。最大ユニキャスト接続数をｇＮＢがＵＥに対して通知する場合は、該最大ユニキャスト接続数を、報知情報に含めて通知してもよいし、ＲＲＣ個別シグナリング通知してもよい。
ＵＥが接続可能な最大ユニキャスト接続数を、ＵＥ個別に設定してもよい。ＵＥが接続可能な最大ユニキャスト接続数を、ＵＥ個別に設定するような場合、ＳＬでの通信を用いて、ＵＥ間で通知してもよい。また、該最大ユニキャスト接続数をＵＥがｇＮＢに通知してもよい。ＵＥが接続可能な最大ユニキャスト接続数を、ケーパビリティ情報に含めてもよい。ＵＥは、ＵＥが接続可能な最大ユニキャスト接続数を、ケーパビリティ情報に含めて、他のＵＥに対して、または、ｇＮＢに対して通知してもよい。
このようにすることで、ＵＥが接続可能な最大ユニキャスト接続数を設定でき、ＵＥの能力を超えたユニキャスト接続処理を行わなくて済む。複数のユニキャスト通信を安定して実施可能となる。
一つのユニキャスト通信に対して、一つのユニキャスト接続を実施することを示した。また、一つのユニキャスト接続に対して、一つのユニキャスト通信を行うことを示した。複数のユニキャスト通信に対して、一つのユニキャスト接続を実施してもよい。一つのユニキャスト接続に対して一つのユニキャスト通信を行ってもよい。一つのユニキャスト接続を維持しながら、複数のユニキャスト通信処理を行うと良い。ユニキャスト通信毎にユニキャスト接続設立処理を実施しなくて済むため、ユニキャスト通信までの処理を簡略化可能となる。ユニキャスト通信を実施するまでの遅延時間を削減可能となる。たとえば、低遅延特性が要求されるＶ２Ｖ通信においては有効となる。
一つのサービスによる通信を、一つのユニキャスト通信で実施してもよい。一つのユニキャスト通信に対して、一つのサービスの通信を行う。複数のサービスによる通信を、サービス毎に、一つのユニキャスト通信で実施するようにしてもよい。サービス毎のユニキャスト通信ではなく、アプリケーション毎のユニキャスト通信を実施してもよい。一つのアプリケーションによる通信を、一つのユニキャスト通信で実施してもよい。このようにすることで、サービス毎のリソース設定が可能となる。要求されるサービス毎に適したユニキャスト通信が可能となる。
複数のサービスによる通信を、一つのユニキャスト通信で実施してもよい。サービス毎にユニキャスト通信までの処理を実施しなくて済むため、ユニキャスト通信までの処理を簡略化可能となる。ユニキャスト通信を実施するまでの遅延時間を削減可能となる。たとえば、低遅延特性が要求されるＶ２Ｖ通信においては有効となる。
複数のサービスによる通信を、一つのユニキャスト通信で実施する例を開示する。
サービスに要求されるＱｏＳ毎にユニキャスト通信を行う。ユニキャスト通信は所定のＱｏＳに対応して設けられる。各サービスは、そのＱｏＳに応じて、対応するユニキャスト通信で行われる。ＱｏＳが同じならば、同一のユニキャスト通信となる。ＱｏＳ毎のユニキャスト通信ではなく、複数のＱｏＳからなるＱｏＳグループ毎のユニキャスト通信を実施してもよい。ＱｏＳ毎にユニキャスト通信を行うことで、ＱｏＳに適したユニキャスト通信の設定が可能となる。たとえば、ＱｏＳに適したリソース設定が可能となる。
サービスに要求される優先順位毎に、ユニキャスト通信を行う。優先順位は、例えば、ＰＰＰＰであってもよい。ユニキャスト通信は所定の優先順位に対応して設けられる。各サービスは、その優先順位に応じて、対応するユニキャスト通信で行われる。優先順位が同じならば、同一のユニキャスト通信となる。優先順位毎のユニキャスト通信ではなく、複数の優先順位からなる優先順位グループ毎のユニキャスト通信を実施してもよい。優先順位グループ内の最も高い優先順位に従って、ユニキャスト通信を実施してもよい。優先順位毎にユニキャスト通信を行うことで、優先順位に適したユニキャスト通信の設定が可能となる。たとえば、優先順位に適したリソース設定が可能となる。
他の例を開示する。要求される低遅延特性毎に、ユニキャスト通信を行ってもよい。サービスグループ毎に、ユニキャスト通信を行ってもよい。ＰＤＵセッション毎に、ユニキャスト通信を行ってもよい。ネットワークスライシング毎に、ユニキャスト通信を行ってもよい。ネットワークスライシングのために用いられる識別情報であるネットワークスライスセレクションアシスタンス情報（NSSAI）毎に、ユニキャスト通信を行ってもよい。同様に、各々に適したユニキャスト通信の設定が可能となる。
どのサービスによる通信かを示すための識別子を設けるとよい。該識別子は、サービス識別子であってもよいし、サービスグループ識別子であってもよい。同一のユニキャスト通信内で複数のサービスによる通信を行う際に、該識別子を用いると良い。同一のユニキャスト通信内でどのサービスかを特定可能となる。
識別子として以下に７つの例を開示する。
（１）どのサービスによる通信かを示す識別子。
（２）どのＱｏＳの通信かを示すための識別子。
（３）どの優先順位の通信かを示すための識別子。
（４）どの低遅延特性の通信かを示すための識別子。
（５）どのＰＤＵセッションの通信かを示すための識別子。
（６）どのネットワークスライシングの通信かを示すための識別子。
（７）どのＮＳＳＡＩの通信かを示すための識別子。ＮＳＳＡＩを用いてもよい。
前述の（１）～（７）はそれぞれ、グループを示す識別子であってもよい。このようにすることで、一つのユニキャスト通信で複数のサービスなどに通信を実施可能となる。
該識別子は、接続要求シグナリングに含められてもよいし、データ送信用リソーススケジューリング情報に含められてもよい。該識別子は、ユニキャスト通信までの処理において、制御信号／チャネルあるいは制御シグナリングに含められて通知されてもよい。たとえば、該識別子は、接続要求のためのＲＲＣシグナリングに含められて通知されてもよい。たとえば、該識別子は、データ送信用リソーススケジューリング情報に含められてもよい。該識別子は、ＳＣＩに含められてＰＳＣＣＨで送信されてもよい。また、該識別子は、フィードバック用リソーススケジューリング情報に含められてもよい。該識別子は、ＳＣＩに含められてＰＳＣＣＨで送信されてもよい。
また、該識別子をデータおよび／またはフィードバックに多重してもよい。多重方法として、ＦＤＭ、ＴＤＭ、ＣＤＭを用いるとよい。
前述では、ユニキャスト通信について開示したが、ユニキャスト接続であってもよい。これらの方法をユニキャスト接続に適用することで、一つのユニキャスト接続で、複数サービスの通信が可能となる。サービス毎にユニキャスト接続設立処理を実施しなくて済むため、ユニキャスト通信までの処理を簡略化可能となる。ユニキャスト通信を実施するまでの遅延時間を削減可能となる。たとえば、低遅延特性が要求されるＶ２Ｖ通信においては有効となる。
一つのユニキャスト接続で、複数のリソース設定を行ってもよい。たとえば、一つのユニキャスト通信で、一つのリソース設定を行う。一つのユニキャスト接続で、複数のユニキャスト通信を行う。このようにすることで、一つのユニキャスト接続で、複数のリソース設定を行うことが可能となる。リソース設定は、ＳＰＳ、設定済グラントであってもよい。複数のリソース設定を行うことで、たとえば、複数のサービスに対して、サービス毎に適したリソース設定を可能とする。サービス毎に適したユニキャスト接続を実施可能となる。
一つのユニキャスト通信で、複数のリソース設定を行ってもよい。リソース設定は、ＳＰＳ、設定済グラントであってもよい。一つのユニキャスト通信で複数のリソース設定を行うことで、たとえば、複数のサービスに対して、サービス毎に適したリソース設定を可能とする。サービス毎に適したユニキャスト通信を実施可能となる。
一つのユニキャスト接続で、複数のＳＲおよび／またはＢＳＲを設けてもよい。たとえば、一つのユニキャスト通信で、一つのＳＲおよび／またはＢＳＲを設ける。一つのユニキャスト接続で、複数のユニキャスト通信を行う。このようにすることで、一つのユニキャスト接続で、複数のＳＲおよび／またはＢＳＲの設定を行うことが可能となる。複数のＳＲおよび／またはＢＳＲ設定を行うことで、たとえば、複数のサービスに対して、サービス毎に適したＳＲおよび／またはＢＳＲ設定を可能とする。サービス毎に適したユニキャスト接続を実施可能となる。
一つのユニキャスト通信で、複数のＳＲおよび／またはＢＳＲを設けてもよい。一つのユニキャスト通信で、複数のＳＲおよび／またはＢＳＲ設定を行うことで、たとえば、複数のサービスに対して、サービス毎に適したＳＲおよび／またはＢＳＲ設定を可能とする。サービス毎に適したユニキャスト通信を実施可能となる。
実施の形態４．
ＮＲではＳＬの通信としてユニキャストが検討されている。ＳＬでのユニキャスト通信では、ＨＡＲＱのフィードバック（Ａｃｋ／Ｎａｃｋ）のサポートが検討されている。しかし、ＨＡＲＱフィードバックの送信方法については不明である。このため、ＳＬで他のＵＥからデータを受信したＵＥは、データを送信した該他のＵＥに対してＨＡＲＱフィードバックを送信できないという問題が生じる。
本実施の形態４はこのような問題を解決する方法を開示する。
ＨＡＲＱフィードバックとして、送信されたデータを受信できた場合に送信するＡｃｋと、送信されたデータを受信できなかった場合に送信するＮａｃｋがある。ＳＬでのユニキャスト通信におけるＨＡＲＱフィードバックとして、ＡｃｋとＮａｃｋの両方をサポートする。これによって、データを送信したＵＥは明示的にＡｃｋあるいはＮａｃｋを受信できるため、通信の信頼性を向上させることができる。
他の方法として、Ａｃｋのみをサポートしてもよい。データを送信したＵＥはＡｃｋを受信しなかった場合に再送を行う。Ａｃｋを受信した場合は再送を停止する。Ｎａｃｋを不要とするので、ＵＥ間のシグナリング負荷を低減できる。また、ＵＥによるＮａｃｋ送信が不要となるので消費電力を削減可能となる。
他の方法として、Ｎａｃｋのみをサポートしてもよい。データを送信したＵＥはＮａｃｋを受信した場合に再送を行う。Ｎａｃｋを受信しなかった場合は再送を停止する。このようにすることで、ＵＥ間のシグナリング負荷を低減できる。また、ＵＥによるＡｃｋ送信が不要となるので消費電力を削減可能となる。
Ａｃｋ、あるいは、Ｎａｃｋを受信するための所定の期間を設けておくとよい。該所定の期間を経過した場合は、Ａｃｋ、あるいは、Ｎａｃｋを受信しなかったとするとよい。また、Ａｃｋ，あるいは、Ｎａｃｋを受信するタイミングを予め決めておいてもよい。該所定の期間、あるいは、受信タイミングは、予め規格等で静的に決められてもよいし、データ送信するＵＥがターゲットとするＵＥに対して通知してもよい。該所定の期間、あるいは、受信タイミングを制御情報として、ＰＳＣＣＨに含めて通知してもよい。このようにすることで、データを送信したＵＥがＡｃｋ、Ｎａｃｋを待ち続けることを回避することができる。
ＨＡＲＱフィードバック方法として、ＴＴＩ（Transmission Time Interval）毎にAｃｋあるいはＮａｃｋを判断して通知してもよい。あるいは、コードブロックグループ（CBG;Code Block Group）毎にAｃｋあるいはＮａｃｋを判断して通知してもよい。コードブロック毎の再送を行ってもよい。また、ＮＲでのＳＬの通信において、繰返し送信（repetition）が検討されているが、繰返し送信受信後のＣＢＧ毎にＡｃｋあるいはＮａｃｋを判断して通知してもよい。このように、ＣＢＧ毎のフィードバック方法とすることで、再送用のリソースを削減可能となる。リソース使用効率を向上可能となる。特に、ＵＥ間でリソース衝突が発生しやすいＳＬ通信において有効となる。
ＮＲでのＳＬの通信において、繰返し送信（repetition）が検討されている。繰返し通信が行われた場合のＨＡＲＱフィードバック送信方法については不明である。ここでは繰返し通信が行われた場合のＨＡＲＱフィードバック送信方法について開示する。
繰返し送信の１回の送信毎にＨＡＲＱフィードバックが送信される。データ送信するＵＥが送信を１回行うたびに、受信側ＵＥが該データ送信に対するフィードバック送信を行う。このようにすることで、フィードバック送信を早期に実施可能となり、電波伝搬環境が良好な場合はデータスループットを向上させることが可能となる。
他の方法として、繰返し送信の全送信に対してＨＡＲＱフィードバックが送信される。データ送信するＵＥが繰り返し送信の全送信を行った後に、受信側ＵＥが該全データ送信に対するフィードバック送信を行う。このようにすることで、フィードバック送信に用いるリソースを削減可能となる。ＳＬにおいてリザベーション必要とするリソース量を削減可能となる。リソースの使用効率を向上させることが可能となる。
前述では繰返し送信１回毎にＨＡＲＱフィードバックが送信されるとしたが、繰返し送信ｎ回（ｎは正の整数）の送信毎にＨＡＲＱフィードバックが送信されるとしてもよい。データ送信するＵＥが送信をｎ回行うたびに、受信側ＵＥが該データ送信に対するフィードバック送信を行う。ｎの値は予め規格等で決められても良いし、送信側ＵＥが受信側ＵＥに通知してもよい。ｎの値を制御情報として、初送データのＰＳＣＣＨに含めて通知してもよい。このようにすることで、電波伝搬環境やリソース使用量に応じて適宜最適なフィードバック制御を可能とする。
繰り返し送信の１回の送信毎にＨＡＲＱフィードバックが送信される場合、各繰返し送信に対するＨＡＲＱフィードバックのリソースをどのように設定するかが不明となる。このような問題を解決する方法を開示する。繰返し送信からＨＡＲＱフィードバックまでのタイミングを、各繰返し送信に対するＨＡＲＱフィードバックで同じにするとよい。これにより、どの繰返し送信に対するフィードバックかを送信側ＵＥは認識可能となる。
また、各繰返し送信に対するＨＡＲＱフィードバックの周波数リソースを同じにしてもよい。たとえば同じ番号のＲＢを利用する。あるいは、たとえば同じ番号のサブキャリア範囲を利用してもよい。このようにすることで、周波数軸上のリソースのリザベーションを容易にできる。
他の方法として、各繰返し送信に対するＨＡＲＱフィードバックのリソースを変えてもよい。送信側ＵＥが、各繰返し送信に対するＨＡＲＱフィードバック用に異なるリソースをリザベーションして、受信側ＵＥに通知してもよい。このようにすることで、フェージング等の影響を抑制することが可能となる。
送信データに対するＨＡＲＱフィードバックのマッピング方法について開示する。ＨＡＲＱフィードバックをスロットの最後のシンボルにマッピングしてもよい。ＵｕのＵＬにおいて、ショートＰＵＣＣＨが採用されている。ショートＰＵＣＣＨと同様のマッピングを利用してもよい。
他の方法として、スロットの最初のシンボルにＨＡＲＱフィードバックをマッピングしてもよい。あるいは、最初から所定の数のシンボル内にＨＡＲＱフィードバックをマッピングしてもよい。このようにすることで、送信データに対するフィードバック送信までの期間を削減可能となる。
他の方法として、ＨＡＲＱフィードバックをＳＣＩに含めて送信してもよい。ＨＡＲＱフィードバックを含むＳＣＩは、データを送信するＵＥが送信するのではなく、データを受信したＵＥが送信する。したがって、ＨＡＲＱフィードバックを含むＳＣＩをどのように送信するのかが問題となる。
データが付随しないＳＣＩを設けてもよい。ＰＳＳＣＨが付随しないＰＳＣＣＨを設けて、該ＰＳＣＣＨにＳＣＩをマッピングしてもよい。該ＳＣＩにはＰＳＳＣＨのスケジューリング情報を含めない。データが付随しないＳＣＩに、ＨＡＲＱフィードバックを含める。このようにすることで、少ない情報量で、ＨＡＲＱフィードバックを含むＳＣＩがマッピングされたＰＳＣＣＨを送信可能となる。
なお、データが付随しないＳＣＩを開示したが、該ＳＣＩに、ＣＳＩ報告情報を含めてもよい。あるいは、該ＳＣＩにＳＲを含めてもよい。あるいは、該ＳＣＩにＢＳＲを含めてもよい。このようにすることで、これらの情報を送信するためにＰＳＳＣＨを用いる必要が無くなり、また、少ない情報量のＳＣＩでＰＳＣＣＨを送信可能となる。リソースの使用効率を向上させることができる。
他の方法として、所定の位置の複数のシンボルにＨＡＲＱフィードバックをマッピングしてもよい。ＵｕのＵＬにおいて、ロングＰＵＣＣＨが採用されている。ロングＰＵＣＣＨと同様のマッピングを利用してもよい。あるいは、１スロットの全シンボルにＨＡＲＱフィードバックをマッピングしてもよい。あるいは、１スロットのＲＳがマッピングされているシンボルを除いたシンボルに、ＨＡＲＱフィードバックをマッピングしてもよい。このようにすることで、シンボル数を多く送信可能となるため、フィードバックの通信品質を向上させることが可能となる。
各データ送信からＨＡＲＱフィードバックまでのタイミングおよび／あるいは周波数リソースを、規格等で静的に決めておいてもよい。シグナリングを必要としないため、シグナリング負荷を低減可能となり、また、制御が容易になる。
他の方法として、各データ送信に対するＨＡＲＱフィードバックのタイミングおよび／あるいは周波数リソースを変えてもよい。該タイミングおよび／あるいは周波数リソースに関する情報を、送信側ＵＥが受信側ＵＥに通知してもよい。該タイミングおよび／あるいは周波数リソースに関する情報を、あらかじめＲＲＣシグナリングで通知してもよい。あるいは、該タイミングおよび／あるいは周波数リソースに関する情報を制御情報として、各送信データのＰＳＣＣＨに含めて通知してもよい。たとえば、データ送信からＫスロット後にＨＡＲＱフィードバックを送信する。該ＫスロットをＰＳＣＣＨに含めてもよい。スロット単位に限らず、たとえば、シンボル単位であってもよいし、ノンスロット単位であってもよい。このようにすることで、電波伝搬環境やリソース使用量に応じて適宜最適なフィードバック制御を可能とする。
ＨＡＲＱフィードバック用のリソースのセンシングにおける測定方法について開示する。センシング用のＲＳＲＰあるいはＲＳＳＩ等の測定を、ＰＳＣＣＨで行うとよい。あるいは、該測定をＰＳＣＣＨとＰＳＳＣＨとをあわせて行ってもよい。あるいは、該測定をシンボル単位で行ってもよい。ＲＳＲＰあるいはＲＳＳＩ等の測定をシンボル単位で行うことで、シンボル単位でのリソースリザベーションを可能とし、前述に開示したシンボル単位でのリソースマッピングを可能とできる。
ＳＬでＣＡがサポートされた場合のＨＡＲＱフィードバックの方法を開示する。各コンポーネントキャリア上で送信されたデータに対するＨＡＲＱフィードバックは、該データが送信されたコンポーネントキャリア上で送信する。このようにすることで、リソースリザベーションを同じキャリア上で実施可能となるため、リソースセンシング、リソース選択、リソースリザベーションの処理を簡易にすることが可能となる。
他の方法として、ＳＬでアクティブなコンポーネントキャリアの内、いずれか一つのコンポーネントキャリア上で、ＨＡＲＱフィードバックを送信する。あるいは、アクティブなコンポーネントキャリアを複数のグループに分け、該グループ内でいずれか一つのコンポーネントキャリア上で、ＨＡＲＱフィードバックを送信する。このようにすることで、各キャリアでリソースのリザベーションを実施する必要が無くなる。このため、リソース使用効率を向上させることが可能となる。
ＮＲではＳＬの通信においてグループキャスト（groupcast）のサポートが検討されている。一つのＵＥが複数のＵＥにデータを送信する。複数のＵＥがグループとなる。しかし、グループキャストのＨＡＲＱフィードバック方法についてはなんら開示されていない。ここではグループキャストのＨＡＲＱフィードバック方法について開示する。グループキャストにおいて、ＨＡＲＱフィードバックは複数のＵＥから送信される。
複数のＵＥが、ＨＡＲＱフィードバック用に、どのリソースを用いるかが問題となる。複数のＵＥのＨＡＲＱフィードバック用のリソース設定を、予め行ってもよい。リソース設定の方法は実施の形態３を適用してもよい。このようにすることで、データ送信を行ったＵＥは、複数のＵＥからのＨＡＲＱフィードバックを認識可能となる。
他の方法を開示する。複数のＵＥのＨＡＲＱフィードバックに異なるサイクリックシフトを用いる。ＵＥ毎に異なるサイクリックシフトを用いる。どのサイクリックシフトを用いるかは、データを送信するＵＥが、複数のＵＥに対して、個別に、あらかじめ制御信号／チャネルあるいは制御シグナリングで通知してもよい。どのサイクリックシフトを用いるかの情報を、ＳＣＩに含めて、ＰＳＣＣＨで通知してもよい。
他の方法を開示する。複数のＵＥのＨＡＲＱフィードバックをコード多重する。たとえば、複数のＵＥのＨＡＲＱフィードバックを、ＵＥ毎に異なるスクランブリングコードで、スクランブリングする。どのスクランブリングコードを用いるかは、データを送信するＵＥが、複数のＵＥに対して、個別に、あらかじめ制御信号／チャネルあるいは制御シグナリングで通知してもよい。どのスクランブリングコードを用いるかの情報を、ＳＣＩに含めて、ＰＳＣＣＨで通知してもよい。スクランブリングコードとして、フィードバックを送信するＵＥの識別子を用いてもよい。
このようにすることで、データをグループキャスト送信したＵＥは、複数のＵＥからのＨＡＲＱフィードバックを分別して受信可能となる。複数のＵＥからＨＡＲＱフィードバックを受信したＵＥは、送信したグループのＵＥの少なくとも一つがＡｃｋでなければ再送を行う。再度グループキャストで再送を行う。Ｎａｃｋを受信したＵＥは、再送を受信する。Ａｃｋを送信したＵＥは、再送を受信しなくてもよい。あるいは、Ａｃｋを送信したＵＥは、Ａｃｋが送達されたか不明のため、再送を受信してもよい。複数のＵＥは、再送の受信結果によって、フィードバックを送信する。このようにすることで、グループキャスト通信における通信品質を向上できる。
他の方法として、複数のＵＥからＨＡＲＱフィードバックを受信したＵＥは、ＡｃｋではないＵＥに対して、再送をユニキャスト送信してもよい。すなわち、初送のみグループキャスト通信を行い、再送からはユニキャスト通信を行ってもよい。このようにすることで、複数のＵＥに対して各ＵＥ毎の通信品質を向上可能となる。
本実施の形態４で開示したような方法でＨＡＲＱのフィードバック（Ａｃｋ／Ｎａｃｋ）を行うことで、ＳＬでのユニキャスト通信におけるＨＡＲＱフィードバックが可能となる。このため、ＳＬでのユニキャスト通信における通信品質を向上させることが可能となる。ＳＬにおいて所望のＱｏＳを得る通信を行うことが可能となる。
実施の形態５．
ＬＴＥではＳＬでの通信用にセミパーシステント送信（semi-persistent transmission）がサポートされている（非特許文献２５（ＲＰ－１６１７８８）参照）。セミパーシステント送信では、データ送信用リソースが周期的にリザベーションされ、該リソースでデータ送信可能となる（非特許文献２７の１４．２．１章）。ＮＲにおいてもＳＬでの通信用に設定済グラント（Configured grant）を用いた送信が検討されている。
ＬＴＥではＳＬの通信はブロードキャストのみであった。このためＬＴＥではＨＡＲＱのフィードバックを用いた再送制御は行われなかった。ＮＲでは、ＳＬの通信として、ブロードキャストに加え、ユニキャストとグループキャストのサポートが検討されている（非特許文献２２（３ＧＰＰ ＲＰ－１８２１１１）参照）。このためＮＲではＨＡＲＱのフィードバック送信の検討がなされている。したがって、ＮＲにおいてはＳＬの通信として、ＨＡＲＱフィードバックを用いた再送制御が可能となる。
しかし、ＮＲにおけるＳＬの通信での再送制御方法については不明である。また、リソースリザベーションを用いた送信方法において、再送制御におけるリソースリザベーション方法についても不明である。このため、再送制御ができず、再送制御による通信品質の向上が図れなくなってしまう。
本実施の形態５ではこのような問題を解決するための方法を開示する。
ＳＬでの初送および／あるいは再送に用いられるリソースがリザベーションされる。ＵＥが、ＳＬでの初送および／あるいは再送に用いるリソースをリザベーションしてもよい。リザベーションするリソースは周期的であってもよい。セミパーシステント送信あるいは設定済グラント送信のためのリソースリザベーション方法を適用してもよい。ＳＬでの送信データが発生したＵＥが、該リソースをリザベーションするとしてもよい。
あるいは、ｇＮＢが、ＳＬでの該リソースをリザベーションして、リザベーションしたリソースをＳＬでの送信を実施するＵＥに通知してもよい。ｇＮＢは該ＵＥに対して、リザベーションしたリソースを、ＳＬでのリソースのスケジューリング情報として通知してもよい。該通知にＵｕにおけるＰＤＣＣＨを用いてもよい。
たとえば、ＵＥは、ＳＬでの初送および／あるいは再送用に、１セットの周期的リソースをリザベーションする。ＵＥは該周期的リソースで初送あるいは再送を行う。ＵＥは、初送データを送信後、ＨＡＲＱフィードバックでＮａｃｋを受信したら、次の周期的リソースで再送データを送信する。なお、ＨＡＲＱフィードバックでＮａｃｋを受信したら再送を行うことを開示したが、ＨＡＲＱフィードバックでＡｃｋを受信できなかったら再送を行うとしてもよい。
図３６は、ＳＬでの初送および／あるいは再送に用いるリソースをリザベーションする方法の一例を示す概念図である。ＳＬでの初送および／あるいは再送用に、１セットの周期的リソースがリザベーションされる。図３６において、上段はデータ送信用のリソースを示しており、下段は該データに対するＨＡＲＱフィードバック信号を示している。ＲＲＩ（Resource Reservation Interval）はリソースのリザベーションの周期である。リソースのリザベーションがＲＲＩ周期で行われる。
図３６では、リザベーションする時間軸方向のリソースを1スロットとしているが、複数のスロットがリザベーションされてもよい。また、時間軸方向の単位をスロット単位としているが、スロット単位に限らない。たとえば、時間軸方向の単位は、ノンスロット（ミニスロット）単位であってもよいし、シンボル単位であってもよい。図３６では、リザベーションするリソースの周波数軸方向について記載していないが、周波数軸方向の単位は、ＲＢ単位としてもよいし、ＲＥ単位としてもよい。連続したリソースをリザベーションしてもよいし、非連続したリソースをリザベーションしてもよい。
ＳＬでの送信データが発生したＵＥ（ソースＵＥ）は、図３６に示すように、１セットの周期ＲＲＩの周期的リソースをリザベーションする。該ＵＥは、リザベーションしたリソース７１０１で初送データを送信する。対向するＵＥ（ターゲットＵＥ）が該初送データを受信できない場合、対向するＵＥはＨＡＲＱフィードバック信号として、リソース７１０２でＮａｃｋを送信する。Ｎａｃｋを受信したソースＵＥは、再送データをリザベーションしたリソース７１０３で送信する。
ソースＵＥが、リザベーションしたリソース７１０５で再送を行う、ターゲットＵＥが該再送データを受信できた場合、ターゲットＵＥはＨＡＲＱフィードバック信号としてＡｃｋをリソース７１０６で送信する。Ａｃｋを受信したソースＵＥは、次に発生した初送データを、リザベーションしたリソース７１０７で送信する。このような方法を繰返して再送制御を行う。
リザベーションしたリソースが所定の回数経過した場合、リザベーションするリソースの再選択を行ってもよい。初送に加えて再送も含まれるため、リソース再選択までの所定の回数を最大７５回より大きい値としてもよい。リソース再選択までの所定の回数は、ＲＲＩの値や最大再送回数の値に応じて複数設定してもよい。
ターゲットＵＥがソースＵＥに対して、リソースの再選択を要求してもよい。リソースの再選択要求のための信号あるいはチャネルを新たに設けてもよい。あるいは、リソース再選択要求をＰＳＣＣＨに含めて送信してもよい。あるいは、リソース再選択要求をＰＳＳＣＨに含めて送信してもよい。リソース再選択要求をＰＳＳＣＨでデータと多重して送信してもよい。
他の方法として、リソース再選択要求を、ＨＡＲＱフィードバック（Ａｃｋ／Ｎａｃｋ）に含めて送信してもよい。リソース再選択要求を、ＨＡＲＱフィードバック（Ａｃｋ／Ｎａｃｋ）を送信するチャネルに含めて送信してもよい。該チャネル内でリソース再選択要求をＡｃｋあるいはＮａｃｋと多重して送信してもよい。
他の方法として、ＨＡＲＱフィードバックのＡｃｋを受信できない回数が、所定の回数連続して発生したら、リソース再選択を行うとしてもよい。所定の回数は、予め規格等で静的に決められていてもよいし、ｇＮＢからＵＥに対して通知してもよい。所定の回数は、報知情報として報知してもよいし、ＲＲＣシグナリングで個別に通知してもよい。あるいは、所定の回数をＵＥが選択してもよい。
最大再送回数を設けてもよい。再送が最大再送回数を超えた場合、再送を停止してもよい。最大再送回数は、あらかじめ規格などで静的に決められていてもよいし、ｇＮＢからＵＥに通知してもよい。最大再送回数は、報知情報として報知してもよいし、ＲＲＣシグナリングで個別に通知してもよい。再送が最大再送回数を超えた場合、リソース再選択を実施するとしてもよい。
このようにすることで、たとえば、リザベーションしたリソースの電波伝搬環境の悪化や他ＵＥとの干渉によりデータが送達されないような場合に、リソースの再選択によりリザベーションするリソースを変えることが可能となる。このため、ＳＬでの通信品質を向上させることが可能となる。
また、例えば、サービスのＱｏＳに適した周期を設定してもよい。たとえば、高信頼、低遅延特性が要求されるサービスでは、周期を短くすることで、ＨＡＲＱによる通信品質の向上による高信頼性能と、短周期での再送による低遅延特性とを、得ることが可能となる。
他の方法を開示する。ＳＬでの初送および／あるいは再送に用いられるリソースが複数セット、リザベーションされる。ＵＥが、ＳＬでの初送および／あるいは再送に用いるリソースを複数セット、リザベーションしてもよい。リザベーションする各セットのリソースは周期的であってもよい。セミパーシステント送信あるいは設定済グラント送信のためのリソースリザベーション方法を適用してもよい。ＳＬでの送信データが発生したＵＥが、該リソースをリザベーションするとしてもよい。
あるいは、ｇＮＢが、ＳＬでの該リソースをリザベーションして、リザベーションしたリソースをＳＬでの送信を実施するＵＥに通知してもよい。ｇＮＢは該ＵＥに対して、リザベーションしたリソースをＳＬでのリソースのスケジューリング情報として通知してもよい。該通知にＵｕにおけるＰＤＣＣＨを用いてもよい。
たとえば、ＵＥは、ＳＬでの初送および／あるいは該初送に対する再送を１セットとして、セット毎に周期的リソースをリザベーションし、それにより複数セットのリソースをリザベーションする。ＵＥは該１セットの周期的リソースで初送あるいは該初送に対する再送を行う。ＵＥは、初送データを送信後、ＨＡＲＱフィードバックでＮａｃｋを受信したら、同一セット内の次の周期的リソースで再送データを送信する。なお、ＨＡＲＱフィードバックでＮａｃｋを受信したら再送を行うことを開示したが、ＨＡＲＱフィードバックでＡｃｋを受信できなかったら再送を行うとしてもよい。ＵＥは、ＨＡＲＱフィードバックでAｃｋを受信したら再送を停止する。また、ＵＥは、同一セット内の次の周期的リソースで新たな初送を行ってもよい。
このような周期的リソースの設定を複数セット設けて、ＵＥはセット毎にＳＬでの初送および／あるいは該初送に対する再送を行う。設定するセット数をＨＡＲＱプロセス数と対応づけてもよい。複数のセットの周期的リソースを、時間分割多重してもよいし、あるいは、周波数分割多重してもよいし、あるいは、時間－周波数分割多重してもよい。このようにすることで、複数の初送とそれに対応する再送とを実施することが可能となる。
リザーブする周期的リソースのセット数に最大値を設けてもよい。該最大値は、予め規格等で静的に決められてもよいし、ｇＮＢからＵＥに通知してもよい。該最大値は、報知情報として報知してもよいし、ＲＲＣシグナリングで個別に通知してもよい。実際にリザーブする周期的リソースのセット数は該最大値以下で設定するとよい。実際にリザーブする周期的リソースのセット数は、ＵＥが決定してもよいし、ｇＮＢが決定してもよい。あるいは、実際にリザーブする周期的リソースのセット数は、ＵＥ内に予め設定されていてもよい。
リザーブする周期的リソースの周期を、セット毎に異ならせてもよい。このことを複数のサービスに適用してもよい。すなわち、サービス毎に異なる周期を設定するとよい。例えば、サービス毎のＱｏＳに適した周期を設定することで、サービス毎のＱｏＳ要求を達成可能となる。
リソースの選択は、リソースのセット毎に行ってもよい。リソースのセット毎に、リソース設定を行ってもよい。たとえば、リソースのセットを追加するたびに、リソースの選択を行ってもよい。このようにすることで、必要に応じてリソースリザベーションを実施可能となるため、リソース使用効率を向上させることが可能となる。
リソースの選択は、全リソースのセット、あるいは複数のリソースセットグループ毎に行ってもよい。全リソースのセット、あるいは複数のリソースセットグループ毎に、リソース設定を行ってもよい。たとえば、最初のリソースのセットのリソース選択を行うタイミングで、必要とするリソースのセット数を決定し、該リソースのセットのためのリソース選択を実施する。このようにすることで、リソース選択の処理を多数実施する必要が無くなり、制御を簡易にできる。
リソース再選択までの回数（あるいは時間）を、リソースのセット毎に設定してもよい。リソース再選択までの回数（あるいは時間）を、リソースのセット毎に設定可能となる。たとえば、リソースのセット毎の、リザーブするリソースの周期に応じて、リソース再選択までの回数を設定してもよい。リソース再選択までの回数については前述の方法を適用してもよい。このようにすることで、リソースのセット毎に適したリソース再選択までの回数を設定できる。
リソース再選択までの回数（あるいは時間）を、全リソースのセットで同じに設定してもよい。該設定は、たとえば、全リソースのセットのリソース選択を同じタイミング実施するような場合に適用してもよい。このようにすることで、リソース再選択のタイミングを全リソースのセットで同じにすることができる。このため、リソース再選択の処理を多数実施する必要が無くなり、制御を簡易にできる。
図３７は、ＳＬでの初送および／あるいは再送用に、複数セットの周期的リソースをリザベーションする方法の一例を示す概念図である。
図３７は、２つのセットの周期的リソースを時間分割多重した場合について示している。各セットにおいてリザベーションされたリソースの周期をＲＲＩ－１、ＲＲＩ－２としている。
ＳＬでの送信データが発生したＵＥ（ソースＵＥ）は、まず１つ目のセットとして、周期ＲＲＩ－１の周期的リソースをリザベーションする。ＵＥは、リザベーションしたリソース７２０１で初送データを送信する。１つ目のセットの次のリソースタイミングが来る前に、該ＵＥにさらに送信データが発生した場合、２つ目のセットとして、周期ＲＲＩ－２の周期的リソースをリザベーションする。ＵＥは、リザベーションしたリソース７２０４で、発生した初送データを送信する。このように、複数セットの周期的リソースをリザベーションすることで、次の初送を早期に開始可能となる。
各セットにおけるリザベーションした周期的リソースでの送信方法は、図３６で開示した方法と同様なので説明を省略する。
他の方法を開示する。ＳＬでの初送に用いられるリソースと再送に用いられるリソースとが個別にリザベーションされる。ＵＥが、ＳＬでの初送に用いるリソースと再送に用いるリソースとを個別にリザベーションしてもよい。初送に用いるリソースを１セット、リザベーションし、該初送に対する再送に用いるリソースを１セット、リザベーションする。これら２セットの組合せを複数、リザベーションしてもよい。
リザベーションする初送用および再送用の各セットのリソースは周期的であってもよい。セミパーシステント送信あるいは設定済グラント送信のためのリソースリザベーション方法を適用してもよい。ＳＬでの送信データが発生したＵＥが、該リソースをリザベーションするとしてもよい。
あるいは、ｇＮＢが、ＳＬでの該リソースをリザベーションして、リザベーションしたリソースをＳＬでの送信を実施するＵＥに通知してもよい。ｇＮＢは該ＵＥに対して、リザベーションしたリソースをＳＬでのリソースのスケジューリング情報として通知してもよい。該通知にＵｕにおけるＰＤＣＣＨを用いてもよい。
たとえば、ＵＥは、ＳＬでの初送用に１セットの周期的リソースをリザベーションし、該初送に対する再送用に１セットの周期的リソースをリザベーションする。ＵＥは、初送用の１セットの周期的リソースで初送を行い、再送用の１セットの周期的リソースで再送を行う。
初送用の周期的リソースの周期は、再送用の周期的リソースの周期と異なってもよい。たとえば、初送データの発生タイミングが再送データの発生タイミングと異なる場合、これらの周期を異ならせることによって、各データの発生タイミングに適した周期とすることが可能となる。
ＵＥは、初送用の周期的リソースで初送データを送信後、ＨＡＲＱフィードバックでＮａｃｋを受信したら、再送用の周期的リソースで再送データを送信する。ＵＥは、ＨＡＲＱフィードバックでAｃｋを受信したら、再送を停止する。また、再送停止後、初送用の周期的リソースで新たな初送を行ってもよい。
たとえば、初送の発生タイミングが再送のタイミングより長周期の場合、初送の発生タイミングに応じて初送用リソースの周期をリザベーションし、再送タイミングに応じて再送用リソースをリザベーションする。このようにすることで、短い周期で再送を実施できる。
リソース再選択までの回数（あるいは時間）を、初送のリソースに対して設定してもよい。リソース再選択までの回数を超えたら、初送および再送のリソースのセットの再選択を実施する。このようにすることで、リソース再選択の処理を簡易にすることができる。
リソース再選択までの回数（あるいは時間）を、初送のリソースのセットに対して設定し、再送のリソースのセットに対しても設定してもよい。初送用リソースのセットと、再送用リソースのセットで、リソース再選択までの回数として、異なる回数を設定してもよい。初送用リソース再選択までの回数を超えたら、初送用のリソースのセットの再選択を実施する。再送用リソース再選択までの回数を超えたら、再送用のリソースのセットの再選択を実施する。このようにすることで、初送と再送とで個別に適したリソース再選択までの回数を設定できる。
リソース再選択までの回数（あるいは時間）を、初送のリソースのセットに対して設定し、再送のリソースのセットに対しても設定してもよい。初送用リソースのセットと、再送用リソースのセットで、リソース再選択までの回数として、異なる回数を設定してもよい。初送用リソース再選択までの回数を超えたら、初送用のリソースのセットと再送用のリソースのセットの両方の再選択を実施する。再送用リソース再選択までの回数を超えたら、再送用のリソースのセットのみの再選択を実施する。このようにすることで、不要な再送用のリソースのリザベーションを低減させることが可能となる。リソース使用効率を向上させることで可能となる。
図３８は、ＳＬでの初送に用いられるリソースと再送に用いられるリソースとを個別にリザベーションする方法の一例を示す概念図である。
図３８は、初送用の周期的リソースが１セット、リザベーションされ、再送用の周期的リソースが１セット、リザベーションされる場合について示している。初送用の周期的リソースと再送用の周期的リソースの多重方法として、時間分割多重、周波数分割多重、時間－周波数分割多重がある。図３８は、周波数分割多重の場合について示している。初送用の周期的リソースの周期を初送用ＲＲＩ（RRI for initial TX）とし、再送用の周期的リソースの周期を再送用ＲＲＩ（RRI for re-TX）としている。
ＳＬでの送信データが発生したＵＥ（ソースＵＥ）は、初送用の周期的リソース（周期はRRI for initial TX）を１セット、リザベーションし、再送用の周期的リソース（周期はRRI for re-TX）を１セット、リザベーションする。ソースＵＥは、リザベーションした初送用のリソース７３０１で初送データを送信する。対向するＵＥ（ターゲットＵＥ）が該初送データを受信できない場合、対向するＵＥはＨＡＲＱフィードバック信号としてリソース７３０２でＮａｃｋを送信する。Ｎａｃｋを受信したソースＵＥは再送データを、再送用にリザベーションしたリソース７３０３で送信する。
ソースＵＥが、再送用にリザベーションしたリソース７３０５で再送を行い、ターゲットＵＥが該再送データを受信できた場合、ターゲットＵＥはＨＡＲＱフィードバック信号としてＡｃｋをリソース７３０６で送信する。Ａｃｋを受信したソースＵＥは、次に発生した初送データを、初送用にリザベーションしたリソース７３０８で送信する。このような方法を繰返して再送制御を行う。
このような方法とすることで、前述の１セットで初送と再送を行う方法に比べ、初送の発生タイミングが長周期の場合でも再送の周期を短く設定することが可能となる。それにより、再送までにかかる時間を低減可能となる。このため、低遅延な送信が可能となる。
他の方法を開示する。ＳＬでの初送と再送に用いられるリソースのグループがリザベーションされる。ＵＥが、ＳＬでの初送と再送に用いるリソースのグループをリザベーションしてもよい。初送と再送に用いられるリソースのグループが１セット、リザベーションされてもよい。ＵＥが、ＳＬでの初送と再送に用いるリソースのグループを１セット、リザベーションしてもよい。
これらのセットを複数、リザベーションしてもよい。初送と再送のグループを複数、同時に送信可能となる。一つのグループを一つのＨＡＲＱプロセスに対応させてもよい。複数のＨＡＲＱプロセスを同時に送信可能となる。
リザベーションするリソースグループにおいて、再送用のリソースは周期的であってもよい。リザベーションするリソースグループの各セット間で対応するリソースは、周期的であってもよい。セミパーシステント送信あるいは設定済グラント送信のためのリソースリザベーション方法を適用してもよい。ＳＬでの送信データが発生したＵＥが、該リソースをリザベーションするとしてもよい。
あるいは、ｇＮＢが、ＳＬでの該リソースをリザベーションして、リザベーションしたリソースをＳＬでの送信を実施するＵＥに通知してもよい。ｇＮＢは該ＵＥに対して、リザベーションしたリソースをＳＬでのリソースのスケジューリング情報として通知してもよい。該通知にＵｕにおけるＰＤＣＣＨを用いてもよい。
たとえば、ＵＥは、ＳＬでの初送用のリソースと再送用の周期的リソースとからなるリソースグループをリザベーションする。また、ＵＥは、１セットの周期的リソースグループをリザベーションする。ＵＥは、リソースグループの初送用のリソースで初送を行い、リソースグループの再送用の周期的リソースで再送を行う。
リソースグループの再送用のリソースの周期は、リソースグループの初送用のリソースの周期と異なってもよい。たとえば、初送データの発生タイミングが再送データの発生タイミングと異なる場合、これらの周期を異ならせることによって、各データの発生タイミングに適した周期とすることが可能となる。
ＵＥは、リソースグループの初送用のリソースで初送データを送信後、ＨＡＲＱフィードバックでＮａｃｋを受信したら、リソースグループの再送用の周期的リソースで再送データを送信する。ＵＥは、ＨＡＲＱフィードバックでAｃｋを受信したら、再送を停止する。ＵＥは、周期的リソースグループの初送用のリソースで新たな初送を行ってもよい。
たとえば、初送の発生タイミングが再送のタイミングより長周期の場合、初送の発生タイミングに応じてリソースグループを周期的にリザベーションし、再送タイミングに応じてリソースグループの再送用リソースを周期的にリザベーションする。このようにすることで、再送を短い周期で実施できる。
また、リソースグループにおいて再送用にリザベーションするリソースの数を限定してもよい。たとえば、再送用にリザベーションするリソースの数を、最大再送回数と同じ値に制限する。このようにすることで、不要なリソースのリザベーションを抑制することが可能となる。リソース使用効率を向上させることができる。
リソース再選択までの回数（あるいは時間）は、前述の、初送用の周期的リソースが１セット、リザベーションされ、再送用の周期的リソースが１セット、リザベーションされる場合で開示した方法を適用してもよい。同様の効果を得ることができる。
図３９は、ＳＬでの初送と再送に用いられるリソースのグループをリザベーションする方法の一例を示す概念図である。
図３９は、リソースグループとして、初送用の一つのリソースと再送用の周期的リソースとがリザベーションされ、１セットのリソースグループが周期的にリザベーションされる場合について示している。リソースグループの初送用のリソースと再送用の周期的リソースの多重方法として、時間分割多重、周波数分割多重、時間－周波数分割多重がある。また、リソースグループ間の多重方法として、時間分割多重、周波数分割多重、時間－周波数分割多重がある。図３９では、リソースグループの再送用の周期的リソースの周期を再送用ＲＲＩ（RRI for re-TX）とし、リソースグループの周期的リソースの周期を送信グループ用ＲＲＩ（RRI for TX group）としている。
ＳＬでの送信データが発生したＵＥ（ソースＵＥ）は、リソースグループの初送用のリソースと再送用の周期的リソース（周期はRRI for re-TX）をリザベーションする。また、ソースＵＥは、該リソースグループを周期的（周期はRRI for TX group）に１セット、リザベーションする。ソースＵＥは、リザベーションしたリソースグループの初送用のリソース７４０１で初送データを送信する。対向するＵＥ（ターゲットＵＥ）が該初送データを受信できない場合、対向するＵＥはＨＡＲＱフィードバック信号としてリソース７４０２でＮａｃｋを送信する。Ｎａｃｋを受信したソースＵＥは再送データを、再送用にリザベーションしたリソース７４０３で送信する。
ソースＵＥが、再送用にリザベーションしたリソース７４０５で再送を行い、ターゲットＵＥが該再送データを受信できた場合、ターゲットＵＥはＨＡＲＱフィードバック信号としてＡｃｋをリソース７４０６で送信する。Ａｃｋを受信したソースＵＥは、再送を停止する。ソースＵＥは、次に発生した初送データを、リソースグループの初送用にリザベーションしたリソース７４０７で送信してもよい。このような方法を繰返して再送制御を行う。
このような方法とすることで、初送の発生タイミングが長周期の場合でも再送の周期を短く設定することが可能となる。それにより、再送までにかかる時間を低減可能となる。このため、低遅延な送信が可能となる。また、リソースグループの再送用にリザベーションするリソースの数を限定することで、リソース使用効率を向上させることができる。また、リソースグループのセットを複数、リザベーションしてもよい。複数の初送と再送のグループを同時に送信可能となるため、低遅延で高速な通信が可能となる。
他の方法を開示する。ＳＬでの再送に用いられるリソースは再送時にリザベーションされる。ＵＥが、ＳＬでの再送に用いるリソースを、再送時にリザベーションしてもよい。リザベーションする再送用のリソースは周期的であってもよい。セミパーシステント送信あるいは設定済グラント送信のためのリソースリザベーション方法を適用してもよい。ＳＬで再送が発生したＵＥが、該リソースをリザベーションするとしてもよい。
あるいは、ＳＬでの再送時、ｇＮＢが、再送用リソースをリザベーションして、リザベーションしたリソースを、ＳＬでの送信を実施するＵＥに通知してもよい。ｇＮＢは該ＵＥに対して、リザベーションしたリソースをＳＬでの再送用リソースのスケジューリング情報として通知してもよい。該通知はＵｕにおけるＰＤＣＣＨを用いてもよい。ｇＮＢがスケジューリングすることで、ＳＬにおける他ＵＥとのリソースの衝突を抑制可能となる。
ＵＥがｇＮＢに対して、再送用リソースが必要である旨を通知してもよい。該通知を再送用リソース要求としてもよい。前述のｇＮＢが再送用リソースをリザベーションする方法に、再送用リソース要求を用いてもよい。再送が必要となったＵＥは、ｇＮＢに対して再送用リソース要求を通知する。ＵＥからの再送用リソース要求受信したｇＮＢは、ＳＬでの再送用のリソースをリザベーションする。ｇＮＢは、リザベーションした再送用リソースのスケジューリング情報を、ＵＥに対して通知する。このようにすることで、ｇＮＢが、再送発生時にＵＥに対して再送用のリソースをリザベーション可能となる。
ＵＥがｇＮＢに対して送信する再送用リソース要求は、ＵｕでＵＥからｇＮＢに送信するＳＲを利用してもよい。あるいはＢＳＲを利用してもよい。あるいは、再送用リソース要求を、ＰＵＣＣＨに含めて通知してもよい。ｇＮＢはＵＥに対して予め、ＳＲ用のリソース、あるいはＢＳＲ用のリソース、あるいはＰＵＣＣＨ用のリソースの設定を実施しておくとよい。
ＳＬでの初送に用いられるリソースについては個別にリザベーションされてもよい。ＵＥが、ＳＬでの初送に用いるリソースを個別にリザベーションしてもよい。初送に用いるリソースを１セット、リザベーションする。該初送に対する再送に用いるリソースとして、前述の再送時にリザベーションしたリソースを用いるとよい。
再送用にリザベーションするリソースは周期的であってもよい。初送に用いるリソースは周期的であってもよい。再送用にリザベーションする周期的リソースの数を限定してもよい。たとえば、再送用にリザベーションする周期的リソースの数を、最大再送回数と同じ値に制限してもよい。リソースの使用効率を向上できる。
たとえば、ＵＥは、ＳＬでの初送用の周期的リソースをリザベーションする。また、ＵＥは、再送時、再送用の周期的リソースをリザベーションする。ＵＥは、初送用の周期的リソースで初送を行い、再送が生じたときにリザベーションした再送用の周期的リソースで再送を行う。
初送用の周期的リソースの周期は、再送用の周期的リソースの周期と異なってもよい。たとえば、初送データの発生タイミングが再送データの発生タイミングと異なる場合、これらの周期を異ならせることによって、各データの発生タイミングに適した周期とすることが可能となる。
ＵＥは、初送用のリソースで初送データを送信後、ＨＡＲＱフィードバックでＮａｃｋを受信したら、再送用の周期的ソースをリザベーションする。ＵＥは、リザベーションした再送用の周期的リソースで、再送データを送信する。ＵＥは、ＨＡＲＱフィードバックでAｃｋを受信したら、再送を停止する。ＵＥは、初送用の周期的リソースで新たな初送を行ってもよい。
たとえば、初送の発生タイミングが再送のタイミングより長周期の場合、初送の発生タイミングに応じて初送用の周期的リソースをリザベーションし、再送タイミングに応じて再送用の周期的リソースをリザベーションする。このようにすることで、再送を短い周期で実施できる。
リソース再選択までの回数（あるいは時間）は、前述の、初送用の周期的リソースが１セット、リザベーションされ、再送用の周期的リソースが１セット、リザベーションされる場合で開示した方法を適用してもよい。同様の効果を得ることができる。
図４０は、ＳＬでの再送に用いられるリソースを再送時にリザベーションする方法の一例を示す概念図である。図４０は、初送用に１セットの周期的リソースがリザベーションされ、再送用の周期的リソースが再送時にリザベーションされる場合について示している。初送用のリソースと再送用のリソースの多重方法として、時間分割多重、周波数分割多重、時間－周波数分割多重がある。図４０では、初送用の周期的リソースの周期をＲＲＩとし、再送用の周期的リソースの周期を再送用ＲＲＩ（RRI for re-TX）としている。
ＳＬでの送信データが発生したＵＥ（ソースＵＥ）は、初送用に１セットの周期ＲＲＩの周期的リソースをリザベーションする。ソースＵＥは、リザベーションした初送用のリソース７５０１で初送データを送信する。対向するＵＥ（ターゲットＵＥ）が該初送データを受信できない場合、対向するＵＥはＨＡＲＱフィードバック信号としてＮａｃｋをリソース７５０２で送信する。Ｎａｃｋを受信したソースＵＥは、再送のための周期的リソース（周期はRRI for re-TX）をリザベーションする。ソースＵＥは、リザベーションした再送用の周期的リソース７５０３で再送を行う。
ソースＵＥが、再送用にリザベーションしたリソース７５０５で再送を行い、ターゲットＵＥが該再送データを受信できた場合、ターゲットＵＥはＨＡＲＱフィードバック信号としてＡｃｋをリソース７５０６で送信する。Ａｃｋを受信したソースＵＥは、再送を停止する。ソースＵＥは、次に発生した初送データを、初送用にリザベーションしたリソース７５０８で送信してもよい。このような方法を繰返して再送制御を行う。
再送時に再送用のリソースをリザベーションするため、リソースのセンシング、リソース選択、リソースリザベーションを予め実施するとよい。初送の送信あるいは再送の送信と並行して、リソースセンシング、リソース選択、リソースリザベーションを行ってもよい。ただし、ハーフデュプレクス（Half Duplex）通信の場合は送信と受信を同時にできないため、初送あるいは再送を行っている期間はセンシングあるいはリソース選択を中断するようにしてもよい。
図４０の例では、ソースＵＥが、初送と並行して、符号７５２１、７５２３、７５２５で示す期間においてリソースセンシングを行う。また、ソースＵＥがターゲットＵＥからＮａｃｋを受信し、再送が発生した場合、符号７５２２、７５２４で示す期間において、ソースＵＥはリソースの選択およびリソースリザベーションを行う。ソースＵＥは、リザベーションしたリソースで再送を行う。再送が発生するたびに、再送用リソースのためのリソース選択およびリソースリザベーションが行われてもよい。図４０の例では、再送用のリソースを周期的（周期はRRI for re-TX）にリザベーションしている。このようにすることで、その後に再送が発生した場合も、該周期的リソースを使用可能となる。このため、リソース選択、リソースリザベーションの回数を低減することができる。再送用リソースのリザベーション処理を簡易にすることが可能となる。
このような方法とすることで、再送が発生してから再送用のリソースをリザベーションすればよいので、再送用のリソースを予めリザベーションしておく必要が無くなる。このため、たとえば、ターゲットＵＥが初送データを受信できたような場合に、既に再送用のリソースをリザベーションしているために該リソースが無駄になってしまうということはない。リソースの使用効率を向上させることが可能となる。
他の方法を開示する。ＳＬでの再送に用いられるリソースは再送時にリザベーションされる。ＵＥが、ＳＬでの再送に用いるリソースを、再送時にリザベーションしてもよい。リザベーションする再送用のリソースは周期的であってもよい。セミパーシステント送信あるいは設定済グラント送信のためのリソースリザベーション方法を適用してもよい。ＳＬで再送が発生したＵＥが、該リソースをリザベーションするとしてもよい。
前述で、ｇＮＢが、初送用あるいは再送用のリソースをリザベーションして、リザベーションしたリソースをＵＥに通知することを開示した。ｇＮＢが再送用のリソースをリザベーションしてＵＥに通知する場合のみＨＡＲＱ再送をサポートする、としてもよい。このようにすることで、ＵＥが再送用リソースをリザベーションする必要は無くなる。このため、リザベーションするリソース量を低減することが可能となる。このため、他ＵＥが使用するリソースとの衝突を低減させることが可能となる。ＳＬにおけるユニキャスト通信を高品質、高信頼性で実施することが可能となる。
本実施の形態５では、初送用、再送用、フィードバック用のリソースが周波数方向に連続である例を開示した。これに限らず、初送用、再送用、フィードバック用のリソースは周波数方向に離散的としてもよい。また、本実施の形態５では、初送用、再送用、フィードバック用のリソースは時間方向に１スロットである例を開示した。これに限らず、初送用、再送用、フィードバック用のリソースは時間方向に複数スロット連続としてもよい。
本実施の形態５で開示した方法とすることで、ＳＬにおけるＨＡＲＱフィードバックでＡｃｋを受信できなかった場合の再送用リソースの設定方法が明確となる。このため、ＨＡＲＱフィードバック制御が可能となり、ＳＬにおけるユニキャスト通信を高品質、高信頼性で実施することが可能となる。
ＵＥがリソースリザベーションを行った場合、リソース再選択を実施するまでは該リソースをリザベーションしたままになる。ＵＥはリソース設定において、リソースセンシング、リソース選択を実施する。この際、他のＵＥがリザベーションしたリソースは使用できない場合が生じる。このため、不要なリソースをリザベーションしておくのは、リソース使用効率を低下させることになる。ここでは、このような課題を解決する方法を開示する。
新たな送信データが無くなったＵＥは、初送用リソーススケジューリング情報を含むＳＣＩを送信しない。該ＵＥは、次にリザベーションされている初送用リソースでＰＳＣＣＨを送信しないとしてもよい。対向するＵＥは、次にリザベーションされている初送用リソースでＰＳＣＣＨあるいは該ＳＣＩが無いことを確認し、送信データが無いことを認識できる。他のＵＥは、リソースセンシングにおいて、ＰＳＣＣＨあるいは該ＳＣＩを受信できないため、リザーブされた初送用リソースが使用されていないことを認識する。
リザーブされた初送用リソースが使用されていないことを認識したＵＥは、リソースセンシングにおいて、該リソースを、リザベーションするリソース候補として選択可能となる。このようにすることで、他のＵＥがリソースを使用することが可能となり、リソース使用効率を向上させることができる。
他の方法を開示する。新たな送信が無いことを示す情報を設ける。新たな送信データが無くなったＵＥは、新たな送信が無いことを示す情報を、初送用リソーススケジューリング情報用のＳＣＩに含めて、通知する。該ＵＥは、次にリザベーションされている初送用リソースのＰＳＣＣＨで新たな送信が無いことを通知してもよい。対向するＵＥは、次にリザベーションされている初送用リソースのＰＳＣＣＨあるいは該ＳＣＩに、新たな送信が無いことを示す情報が含まれているか否かを確認し、該情報が含まれている場合は、送信データが無いことを認識できる。他のＵＥは、リソースセンシングにおいて、ＰＳＣＣＨあるいは該ＳＣＩに、新たな送信が無いことを示す情報が含まれているか否かを確認し、該情報が含まれている場合は、リザーブされた初送用リソースが使用されていないことを認識する。
リザーブされた初送用リソースが使用されていないことを認識したＵＥは、リソースセンシングにおいて、該リソースを、リザベーションするリソース候補として選択可能となる。このようにすることで、他のＵＥがリソースを使用することが可能となり、リソース使用効率を向上させることができる。新たな送信が無いことを示す情報を設けることで、ＵＥは明示的に、送信データが無いこと、あるいは、リザーブされた初送用リソースが使用されないことを認識可能となる。明示的な通知によって、誤動作の発生を低減させることができる。
ＵＥが新たな送信データが無くなったと判断する方法を開示する。ＵＥは、所定の期間（回数）連続でデータを送信しない場合、送信データが無くなったと判断する。ＵＥは、所定の期間、送信データバッファにデータが無い場合、送信データが無くなったと判断してもよい。ＵＥは、上位レイヤから送信データが無くなったことを示す情報を通知された場合、送信データが無くなったと判断してもよい。ＵＥは、上位レイヤからサービス終了を示す情報を通知された場合、送信データが無くなったと判断してもよい。このようにすることで、ＵＥは、新たな送信データが無くなったことを判断可能になる。
３ＧＰＰでは、ユニキャスト通信において、従来行われていなかったＨＡＲＱの再送が実施されることが検討されている。ＨＡＲＱの再送が行われる場合について開示する。ＨＡＲＱの再送では、ＵＥがＡｃｋ受信した後に、再送データは送信されない。このため、再送用にリザベーションしたリソースはＡｃｋ受信後に使用されないことになる。
ＵＥは、リソース設定を実施する際に再送用にリザベーションしたリソースを除外する場合がある。このため、他のＵＥが再送用にリザベーションしたリソースを使用できない場合が生じる。したがって、不要な再送用リソースをリザベーションしておくのは、リソース使用効率を低下させることになる。ここでは、このような課題を解決する方法を開示する。
ＨＡＲＱフィードバックのＡｃｋを受信したＵＥは、再送用リソーススケジューリング情報を含むＳＣＩを送信しない。該ＵＥは、次にリザベーションされているリソースでＰＳＣＣＨを送信しないとしてもよい。対向するＵＥは、次にリザベーションされているリソースでＰＳＣＣＨあるいは該ＳＣＩが無いことを確認し、送信データが無いことを認識できる。他のＵＥは、リソースセンシングにおいて、ＰＳＣＣＨあるいは該ＳＣＩを受信できないため、リザーブされた再送用リソースが使用されていないことを認識する。
リザーブされた再送用リソースが使用されていないことを認識したＵＥは、リソースセンシングにおいて、該リソースを、リザベーションするリソース候補として選択可能となる。このようにすることで、他のＵＥがリソースを使用することが可能となり、リソース使用効率を向上させることができる。
他の方法を開示する。再送が無いことを示す情報を設ける。ＨＡＲＱフィードバックのＡｃｋを受信したＵＥは、再送が無いことを示す情報を、再送用リソーススケジューリング情報用のＳＣＩに含めて通知する。該ＵＥは、次にリザベーションされているリソースのＰＳＣＣＨで再送が無いことを通知してもよい。対向するＵＥは、次にリザベーションされているリソースのＰＳＣＣＨあるいは該ＳＣＩに、再送が無いことを示す情報が含まれているか否かを確認し、該情報が含まれている場合は、再送データが無いことを認識できる。他のＵＥは、リソースセンシングにおいて、ＰＳＣＣＨあるいは該ＳＣＩに、再送が無いことを示す情報が含まれているか否かを確認し、該情報が含まれている場合は、リザーブされた再送用リソースが使用されていないことを認識する。
リザーブされた再送用リソースが使用されていないことを認識したＵＥは、リソースセンシングにおいて、該リソースを、リザベーションするリソース候補として選択可能となる。このようにすることで、他のＵＥがリソースを使用することが可能となり、リソース使用効率を向上させることができる。再送が無いことを示す情報を設けることで、ＵＥは明示的に、再送データが無いこと、あるいは、リザーブされた再送用リソースが使用されないことを認識可能となる。明示的な通知によって、誤動作の発生を低減させることができる。
このようにすることで、ＨＡＲＱフィードバックがサポートされた場合でも、リソース使用効率を向上させることが可能となる。
ＨＡＲＱのフィードバック用リソースについて開示する。前述の再送用リソースについて開示した方法を適用すると良い。再送用のリソースが使用されているか否かで、フィードバック用リソースも使用されているか否かを判断する。たとえば、再送用のリソースが使用されている場合は、フィードバック用のリソースも使用されていると判断する。再送用のリソースが使用されていない場合は、フィードバック用にリソースも使用されていないと判断する。
このようにすることで、他のＵＥが、使用されていないフィードバック用リソースを、リザベーションするリソース候補として選択可能となる。このため、さらに、リソース使用効率を向上させることが可能となる。
ユニキャスト通信あるいはグループキャスト通信を行っているＵＥが移動するなどによって、ターゲットＵＥがソースＵＥのカバレッジ内から出てしまう場合が発生する。このような場合、対向するＵＥ間で通信はできなくなるが、ＵＥがリソース再選択を実施するまでは該リソースをリザベーションしたままになる。
ＵＥはリソース設定において、リソースセンシング、リソース選択を実施する。この際、他のＵＥがリザベーションしたリソースは使用できない場合が生じる。このため、不要なリソースをリザベーションしておくのは、リソース使用効率を低下させることになる。ここでは、このような課題を解決する方法を開示する。
ソースＵＥは、ターゲットＵＥからの所定の信号／チャネルあるいはシグナリングを所定の時間（回数）受信できない場合、ソースＵＥのカバレッジ外へ移動したと判断する。所定の信号／チャネルあるいはシグナリングとして以下に６つの例を開示する。
（１）フィードバック。該フィードバックはＨＡＲＱフィードバックであってもよい。
（２）ＣＳＩ。
（３）ＰＳＳＣＨ。
（４）ＲＳ。ＲＳとして、ＳＲＳ、ＤＭＲＳ、ＰＴＲＳなどがある。
（５）ターゲットＵＥからソースＵＥへの応答シグナリング。
（６）（１）から（５）の組合せ。
所定の信号／チャネルあるいはシグナリングは、周期的に送信されるとよい。所定の信号／チャネルあるいはシグナリングは、所定の期間、周期的に送信されてもよい。このようにすることで、ソースＵＥは、ターゲットＵＥがソースＵＥのカバレッジ外へ移動したことを判断可能となる。
ソースＵＥが、ターゲットＵＥがカバレッジ外へ移動したと判断した場合の処理方法を開示する。初送用および／または再送用リソーススケジューリング情報を含むＳＣＩを送信しない。次にリザベーションされているリソースでＰＳＣＣＨを送信しないとしてもよい。他のＵＥは、リソースセンシングにおいて、ＰＳＣＣＨあるいは該ＳＣＩを受信できないため、リザーブされたリソースが使用されていないことを認識する。
リザーブされたリソースが使用されていないことを認識したＵＥは、リソースセンシングにおいて、該リソースを、リザベーションするリソース候補として選択可能となる。このようにすることで、他のＵＥがリソースを使用することが可能となり、リソース使用効率を向上させることができる。
他の方法を開示する。新たな送信が無いことを示す情報を設ける。新たな送信データが無くなったＵＥは、新たな送信が無いことを示す情報を、初送用および／または再送用リソーススケジューリング情報用のＳＣＩに含めて通知する。該ＵＥは、次にリザベーションされているリソースのＰＳＣＣＨで新たな送信が無いことを通知してもよい。他のＵＥは、リソースセンシングにおいて、ＰＳＣＣＨあるいは該ＳＣＩに、新たな送信が無いことを示す情報が含まれているか否かを確認し、該情報が含まれている場合は、リザーブされたリソースが使用されていないことを認識する。このようにすることで、他のＵＥがリソースを使用することが可能となり、リソース使用効率を向上させることができる。
このようにすることで、ターゲットＵＥが、ソースＵＥのカバレッジ外へ移動した場合のリソース使用効率を向上させることが可能となる。
ソースＵＥは、ターゲットＵＥがソースＵＥのカバレッジ外へ移動した場合、該ターゲットＵＥとの間で実施していたユニキャスト通信のための設定をリセットしてもよい。該ユニキャスト通信のみがユニキャスト接続で行われている場合、ユニキャスト通信も終了してもよい。ユニキャスト接続における設定をリセットしてもよい。このようにすることで、ソースＵＥにおける無線リソースを他のサービスや通信に解放することが可能となる。
ターゲットＵＥが、ソースＵＥのカバレッジ外へ移動したか否かの判断方法を開示する。ターゲットＵＥは、ソースＵＥからの所定の信号／チャネルあるいはシグナリングを所定の期間（回数）受信できない場合、送信カバレッジ外へ移動したと判断する。所定の信号／チャネルあるいはシグナリングとして以下に４つの例を開示する。
（１）ＰＳＣＣＨ。
（２）ＰＳＳＣＨ。
（３）ＲＳ。ＲＳとして、ＤＭＲＳ、ＣＳＩ－ＲＳ、ＰＴＲＳなどがある。
（４）（１）から（３）の組合せ。
所定の信号／チャネルあるいはシグナリングは、周期的に送信されるとよい。所定の信号／チャネルあるいはシグナリングは、所定の期間、周期的に送信されてもよい。このようにすることで、ターゲットＵＥは、ソースＵＥのカバレッジ外へ移動したことを判断可能となる。
ターゲットＵＥが、ソースＵＥのカバレッジ外へ移動したと判断した場合の処理方法は、前述の方法、具体的には、ソースＵＥが、ターゲットＵＥがソースＵＥのカバレッジ外へ移動したと判断した場合の処理方法を適用するよい。該方法は、ターゲットＵＥがリソース設定を行うような場合に適用すると良い。
また、ターゲットＵＥは、ソースＵＥのカバレッジ外へ移動した場合、該ソースＵＥとの間で実施していたユニキャスト通信のための設定をリセットしてもよい。該ユニキャスト通信のみがユニキャスト接続で行われている場合、ユニキャスト通信も終了してもよい。ユニキャスト接続における設定をリセットしてもよい。このようにすることで、ターゲットＵＥにおける無線リソースを他のサービスや通信に解放することが可能となる。
前述に開示した方法において、ソースＵＥおよび／またはターゲットＵＥは、リザベーションしたリソースを使用しないことを、ｇＮＢに通知してもよい。ソースＵＥおよび／またはターゲットＵＥは、リソースを解放したことを、ｇＮＢに通知してもよい。たとえば、該通知を、ｇＮＢがスケジューリングする場合に適用することで、ｇＮＢは、使用されていないリソースを他のＵＥのスケジューリングに用いることが可能となる。リソースの使用効率を向上させることが可能となる。
実施の形態３から実施の形態５では、ＳＬでのユニキャスト通信における再送をＳＬで行うことを示した。ＵＥ間のＳＬの通信品質が悪い状態が継続するような場合、ＳＬでは再送が送達されなくなってしまう問題が生じる。このような問題を解決する方法を開示する。
再送データを、Ｕｕを用いて送信する。ＵＥは再送データをｇＮＢに対して送信し、ｇＮＢは該再送データを、再送データの送信先であるターゲットＵＥに対して送信する。該方法はＨＡＲＱフィードバックの再送に適用してもよい。たとえば、ＨＡＲＱ処理が行われるプロトコルで、ＰＣ５からＵｕへの再送データの切替えを行うとよい。前述の方法はＲＬＣ再送に適用してもよい。たとえば、ＲＬＣ再送が行われるプロトコルで、ＰＣ５からＵｕへの再送データの切替えを行うとよい。前述の方法はパケットデータの再送に対して適用してもよい。たとえば、ＰＤＣＰプロトコルでＰＣ５からＵｕへの再送データの切替えを行うと良い。
再送データを送信するＵＥは、ＳＬの通信品質状態を評価し、ＳＬの通信品質状態が所定の期間連続して所定の閾値よりも悪い場合に、ＰＣ５からＵｕへ再送データの切替えを行うとしてもよい。このようにすることで、ＳＬの通信品質が悪い状態が続くような場合であっても、Ｕｕを用いることでＶ２Ｖ通信を可能とする。
前述の各実施の形態およびその変形例は、本発明の例示に過ぎず、本発明の範囲内において、各実施の形態およびその変形例を自由に組合せることができる。また各実施の形態およびその変形例の任意の構成要素を適宜変更または省略することができる。
例えば、前述の各実施の形態およびその変形例において、サブフレームは、第５世代基地局通信システムにおける通信の時間単位の一例である。スケジューリング単位であってもよい。前述の各実施の形態およびその変形例において、サブフレーム単位として記載している処理を、ＴＴＩ単位、スロット単位、サブスロット単位、ミニスロット単位として行ってもよい。
本発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、本発明がそれに限定されるものではない。例示されていない無数の変形例が、本発明の範囲から外れることなく想定され得るものと解される。
２００ 通信システム、２０２ 通信端末装置、２０３ 基地局装置。

Claims (12)

  1. サイドリンクにおいて互いに通信可能な複数のユーザ装置と、
    複数の前記ユーザ装置の各々と無線通信する基地局と、を備える通信システムにおける１つのユーザ装置であって、
    前記ユーザ装置は、
    他のユーザ装置に対して、前記サイドリンクにおけるユニキャスト送信のためのリソースに関する設定を要求する要求シグナリングを送信し、
    前記他のユーザ装置から、前記リソースに関する前記設定に関する情報を受信し、
    前記要求シグナリングは、優先順位に関する情報を含む、
    ユーザ装置。
  2. 前記リソースは、データ送信用リソースである
    請求項１に記載のユーザ装置。
  3. 前記データ送信用リソースは、初送データ用のリソース及び再送データ用のリソースを含む
    請求項２に記載のユーザ装置。
  4. 前記リソースは、チャネル状態情報（ＣＳＩ）報告用のリソースである
    請求項１に記載のユーザ装置。
  5. 前記設定は、リソースのセンシング、送信用リソースの選択、及び送信用リソースのリザベーションの少なくともいずれかを含む
    請求項１に記載のユーザ装置。
  6. 前記ユニキャスト送信に先立ち、接続設立開始のための制御信号、チャネル、又はシグナリングを送信する
    請求項１に記載のユーザ装置。
  7. 前記リソースに関する前記設定を行うべきか否かを、送信データの種別に応じて判断する
    請求項１に記載のユーザ装置。
  8. データとＨＡＲＱフィードバックリソースとを関連付ける
    請求項１に記載のユーザ装置。
  9. 前記ユニキャスト送信のためのリソース候補から、初送用リソース及び再送用リソースを除外する
    請求項１に記載のユーザ装置。
  10. 前記ユニキャスト送信のためのリソース候補から、受信電力の閾値に基づいてリソースを除外する
    請求項１に記載のユーザ装置。
  11. 初送及び再送に用いられた使用リソースの割合を示すチャネル占有率（channel occupied ratio，ＣＲ）を評価する
    請求項１に記載のユーザ装置。
  12. サイドリンクにおいて互いに通信可能な複数のユーザ装置と、
    複数の前記ユーザ装置の各々と無線通信する基地局と、を備える通信システムであって、
    １つのユーザ装置が、
    他のユーザ装置に対して、前記サイドリンクにおけるユニキャスト送信のためのリソースに関する設定を要求する要求シグナリングを送信し、
    前記他のユーザ装置から、前記リソースに関する前記設定に関する情報を受信し、
    前記要求シグナリングは、優先順位に関する情報を含む、
    通信システム。
JP2020553994A 2018-10-31 2019-10-30 ユーザ装置および通信システム Active JP7420732B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2024002294A JP2024029220A (ja) 2018-10-31 2024-01-11 ユーザ装置、基地局および通信システム

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2018204805 2018-10-31
JP2018204805 2018-10-31
PCT/JP2019/042644 WO2020090920A1 (ja) 2018-10-31 2019-10-30 通信システムおよび受信側装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2024002294A Division JP2024029220A (ja) 2018-10-31 2024-01-11 ユーザ装置、基地局および通信システム

Publications (3)

Publication Number Publication Date
JPWO2020090920A1 JPWO2020090920A1 (ja) 2021-09-24
JPWO2020090920A5 JPWO2020090920A5 (ja) 2023-09-06
JP7420732B2 true JP7420732B2 (ja) 2024-01-23

Family

ID=70464462

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2020553994A Active JP7420732B2 (ja) 2018-10-31 2019-10-30 ユーザ装置および通信システム
JP2024002294A Pending JP2024029220A (ja) 2018-10-31 2024-01-11 ユーザ装置、基地局および通信システム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2024002294A Pending JP2024029220A (ja) 2018-10-31 2024-01-11 ユーザ装置、基地局および通信システム

Country Status (5)

Country Link
US (1) US20220046564A1 (ja)
EP (2) EP4271063A3 (ja)
JP (2) JP7420732B2 (ja)
CN (3) CN112913305A (ja)
WO (1) WO2020090920A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11991002B2 (en) * 2018-11-01 2024-05-21 Lg Electronics Inc. Method and apparatus for adjusting threshold for determining HARQ feedback in NR V2X
CN112771897B (zh) * 2019-02-14 2023-06-20 Oppo广东移动通信有限公司 连接管理方法、装置、终端及系统
KR20210045666A (ko) * 2019-10-17 2021-04-27 삼성전자주식회사 무선 통신 시스템에서 제어정보 및 데이터 송수신 방법 및 장치
CN115066850B (zh) * 2020-02-14 2024-08-06 高通股份有限公司 用于nr v2x周期性调度的保留周期性
US11689325B2 (en) * 2020-12-16 2023-06-27 Qualcomm Incorporated Feedback transmission via a sidelink feedback channel resource of a sidelink resource pool
US12021634B2 (en) * 2020-12-17 2024-06-25 Qualcomm Incorporated Resource determination for sidelink hybrid automatic repeat request feedback
WO2024016305A1 (en) * 2022-07-22 2024-01-25 Qualcomm Incorporated Sidelink resource allocation considerations for energy harvesting devices
US20240314712A1 (en) * 2023-03-17 2024-09-19 Qualcomm Incorporated Cell measurements in energy saving mode

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016032252A (ja) 2014-07-30 2016-03-07 ソニー株式会社 装置
JP2018502478A (ja) 2014-11-07 2018-01-25 サムスン エレクトロニクス カンパニー リミテッド 端末にグループメッセージを送信する方法及び装置
WO2018027528A1 (en) 2016-08-09 2018-02-15 Panasonic Intellectual Property Corporation Of America Improved radio resource selection and sensing for v2x transmissions
WO2018145296A1 (zh) 2017-02-10 2018-08-16 华为技术有限公司 一种数据传输的方法、相关设备以及系统

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104135773A (zh) * 2004-09-08 2014-11-05 三菱电机株式会社 移动站、基站、通信系统和通信方法
CN102711197B (zh) * 2007-04-26 2017-02-08 富士通株式会社 移动站
EP2136501B1 (en) * 2008-06-20 2019-12-04 LG Electronics Inc. Method of delivering a PDCP data unit to an upper layer
US7940650B1 (en) * 2008-11-03 2011-05-10 Juniper Networks, Inc. Peer-agnostic TCP socket replication between primary and secondary routing engines
US20100125661A1 (en) * 2008-11-20 2010-05-20 Valtion Teknillinen Tutkimuskesku Arrangement for monitoring performance of network connection
WO2010107255A2 (ko) * 2009-03-19 2010-09-23 엘지전자주식회사 다중 셀 협력통신 방법 및 장치
JP2014143608A (ja) * 2013-01-24 2014-08-07 Ntt Docomo Inc 無線通信システム、無線通信方法、無線基地局及びユーザ端末
FI128272B (en) * 2014-12-16 2020-02-14 Valmet Automation Oy Redundancy in the process control system
US10334586B2 (en) * 2016-01-22 2019-06-25 Qualcomm Incorporated Hybrid automatic repeat request feedback for unicast sidelink communications
KR102669847B1 (ko) * 2017-01-13 2024-05-28 삼성전자 주식회사 무선 통신 시스템에서 데이터 패킷을 전송하는 방법 및 장치
BR112019019804A2 (pt) * 2017-03-23 2020-04-22 Fraunhofer Ges Forschung transmissão de pacote de dados confiável entre entidades de uma rede de acesso de rádio de uma rede de comunicação móvel
US10716094B2 (en) * 2017-03-23 2020-07-14 Ofinno, Llc Packet duplication in a wireless device and wireless network
CN112166572B (zh) * 2018-05-10 2023-08-22 苹果公司 分组数据汇聚协议（pdcp）重复传输的同步控制

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016032252A (ja) 2014-07-30 2016-03-07 ソニー株式会社 装置
JP2018502478A (ja) 2014-11-07 2018-01-25 サムスン エレクトロニクス カンパニー リミテッド 端末にグループメッセージを送信する方法及び装置
WO2018027528A1 (en) 2016-08-09 2018-02-15 Panasonic Intellectual Property Corporation Of America Improved radio resource selection and sensing for v2x transmissions
WO2018145296A1 (zh) 2017-02-10 2018-08-16 华为技术有限公司 一种数据传输的方法、相关设备以及系统

Also Published As

Publication number Publication date
EP3876637A4 (en) 2022-07-27
EP4271063A2 (en) 2023-11-01
US20220046564A1 (en) 2022-02-10
CN118200977A (zh) 2024-06-14
EP3876637A1 (en) 2021-09-08
WO2020090920A1 (ja) 2020-05-07
EP4271063A3 (en) 2024-01-03
JPWO2020090920A1 (ja) 2021-09-24
CN112913305A (zh) 2021-06-04
CN118200978A (zh) 2024-06-14
JP2024029220A (ja) 2024-03-05

Similar Documents

Publication Publication Date Title
JP7507825B2 (ja) 通信システム、基地局装置および通信端末装置
JP7341135B2 (ja) ユーザ装置、基地局および通信システム
JP7361834B2 (ja) 通信システム、基地局および通信端末
US20220311553A1 (en) Communication system, base station, and user apparatus
JP7420732B2 (ja) ユーザ装置および通信システム
WO2020145248A1 (ja) 通信システムおよび通信端末
JP2022185020A (ja) 通信システム、セントラルユニット、およびユーザ装置
WO2021044932A1 (ja) 通信システム、通信端末およびネットワーク
WO2022030520A1 (ja) 通信システムおよび通信端末
JP2023145753A (ja) 通信システム、基地局および通信端末
KR20230161965A (ko) 통신 시스템 및 기지국
WO2023153336A1 (ja) 通信システムおよび基地局
WO2022181525A1 (ja) 通信システムおよび通信端末
US20230284162A1 (en) Communication system and receiver
KR20230147612A (ko) 통신 시스템 및 기지국

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221007

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230818

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230905

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231102

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240111

R150 Certificate of patent or registration of utility model

Ref document number: 7420732

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150