(57)【要約】  低遅延、高信頼性の無線通信技術を提供する。通信システムは、通信端末（ＵＥ）と、通信端末と無線通信可能に構成された複数の通信装置（移動元ｇＮＢおよび移動先ｇＮＢ）とを含む。通信端末の接続先が第１通信装置（移動元ｇＮＢ）から第２通信装置（移動先ｇＮＢ）に切替わる場合、通信端末は、第２通信装置が送信するタイミングリファレンスと、第２通信装置のタイミングアドバンスとに基づいて、通信端末の時刻を補正する（ステップＳＴ１５１２）。
2020145248.tif 000002
【特許請求の範囲】
【請求項１】
通信端末と、
前記通信端末と無線通信可能に構成された複数の通信装置と
を備える通信システムであって、
前記通信端末の接続先が第１通信装置から第２通信装置に切替わる場合、前記通信端末は、前記第２通信装置が送信するタイミングリファレンスと、前記第２通信装置のタイミングアドバンスとに基づいて、前記通信端末の時刻を補正する、
通信システム。
【請求項２】
前記通信端末は前記タイミングリファレンスの通知要求を、接続完了通知に含めて、前記第２通信装置に送信する、請求項１に記載の通信システム。
【請求項３】
前記第２通信装置は前記タイミングリファレンスを前記第１通信装置に送信し、前記通信端末は前記第１通信装置から、前記第２通信装置の前記タイミングリファレンスを取得する、請求項１に記載の通信システム。
【請求項４】
前記通信端末は前記第２通信装置の前記タイミングアドバンスを推定する、請求項１から請求項３のうちのいずれか１項に記載の通信システム。
【請求項５】
通信装置と無線通信可能に構成された通信端末であって、
前記通信端末の接続先が第１通信装置から第２通信装置に切替わる場合、前記通信端末は、前記第２通信装置が送信するタイミングリファレンスと、前記第２通信装置のタイミングアドバンスとに基づいて、前記通信端末の時刻を補正する、
通信端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信技術に関する。
【背景技術】
【０００２】
移動体通信システムの規格化団体である３ＧＰＰ（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 Communication；ＵＲＬＬＣ）の要件を満たすために、タイムセンシティブネットワーク（Time Sensitive Network；ＴＳＮ）のサポートが検討されている（非特許文献２０（３ＧＰＰ  ＲＰ−１８２０９０）参照）。タイムセンシティブネットワークにおいて、複数のＵＥ間における時刻同期が求められている（非特許文献２３（３ＧＰＰ  ＴＲ２２．８０４  Ｖ１６．１．０）参照）。複数のＵＥ間の時刻同期の方法として、基地局と各ＵＥとの間の時刻同期が検討されている（非特許文献２４（３ＧＰＰ  Ｒ３−１８５８０８）、非特許文献２５（３ＧＰＰ  ＴＳ３６．３３１  Ｖ１５．３．０）、非特許文献２６（３ＧＰＰ  Ｒ２−１８１７１７３）参照）。ところが、モビリティ発生時において、ＵＥは移動先基地局との間の伝搬遅延がわからないので、モビリティ前後でＵＥ時刻が急変する場合がある。このことにより、ＴＳＮを用いるシステムにおいて誤動作発生の問題が生じる。【００５８】
また、ＮＲのサイドリンク（Sidelink；ＳＬ）通信において低遅延特性の要求を満たすため、ＮＲのＳＬ通信におけるプリエンプションの導入が提案されている（非特許文献２２（３ＧＰＰ  Ｒ１−１８１０５９３）、非特許文献２７（３ＧＰＰ  Ｒ１−１８１０７７５）参照）。ところが、ＳＬのプリエンプションの具体的な方法が開示されていないので、ＳＬ通信において、プリエンプションを実施できず、低遅延特性の要求を満たせなくなる、という問題が生じる。【００５９】
本発明は、上記課題に鑑み、ＮＲにおいて、低遅延、高信頼性の無線通信技術を提供することを、目的の一つとする。
【課題を解決するための手段】
【００６０】
本発明によれば、通信端末と、前記通信端末と無線通信可能に構成された複数の通信装置とを備える通信システムであって、前記通信端末の接続先が第１通信装置から第２通信装置に切替わる場合、前記通信端末は、前記第２通信装置が送信するタイミングリファレンスと、前記第２通信装置のタイミングアドバンスとに基づいて、前記通信端末の時刻を補正する、通信システムが提供される。【００６１】
また、本発明によれば、通信装置と無線通信可能に構成された通信端末であって、前記通信端末の接続先が第１通信装置から第２通信装置に切替わる場合、前記通信端末は、前記第２通信装置が送信するタイミングリファレンスと、前記第２通信装置のタイミングアドバンスとに基づいて、前記通信端末の時刻を補正する、通信端末が提供される。
【発明の効果】
【００６２】
本発明によれば、低遅延、高信頼性の無線通信技術を提供することができる。【００６３】
本発明の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。
【図面の簡単な説明】
【００６４】
【図１】ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。
【図２】３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム２００の全体的な構成を示すブロック図である。
【図３】３ＧＰＰにおいて議論されているＮＲ方式の通信システム２１０の全体的な構成を示すブロック図である。
【図４】ＥＰＣに接続するｅＮＢおよびｇＮＢによるＤＣの構成図である。
【図５】ＮＧコアに接続するｇＮＢによるＤＣの構成図である。
【図６】ＮＧコアに接続するｅＮＢおよびｇＮＢによるＤＣの構成図である。
【図７】ＮＧコアに接続するｅＮＢおよびｇＮＢによるＤＣの構成図である。
【図８】図２に示す移動端末２０２の構成を示すブロック図である。
【図９】図２に示す基地局２０３の構成を示すブロック図である。
【図１０】ＭＭＥの構成を示すブロック図である。
【図１１】５ＧＣの構成を示すブロック図である。
【図１２】ＬＴＥ方式の通信システムにおいて通信端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。
【図１３】ＮＲシステムにおけるセルの構成の一例を示す図である。
【図１４】実施の形態１について、ハンドオーバ発生時におけるＵＥ時刻補正の動作の概要を示す図である。
【図１５】実施の形態１について、ハンドオーバ発生時におけるＵＥ時刻補正の動作を示すシーケンス図である。
【図１６】実施の形態１について、ハンドオーバ発生時におけるＵＥ時刻補正の動作の他の例を示すシーケンス図である。
【図１７】実施の形態１について、ハンドオーバ発生時においてＵＥが移動先基地局のＴＡを推定してＵＥ時刻補正の動作を行う例を示すシーケンス図である。
【図１８】実施の形態１の変形例１について、基地局間における時刻の補正の動作の一例を示すシーケンス図である。
【図１９】実施の形態２について、データ送信に用いられるＰＤＵセッションの切替えおよびＵＥが接続する基地局の切替えの動作を示すシーケンス図である。
【図２０】実施の形態２について、データ送信に用いられるＰＤＵセッションの切替えおよびＵＥが接続する基地局の切替えの動作を示すシーケンス図である。
【図２１】実施の形態２について、データ送信に用いられるＰＤＵセッションの切替えおよびＵＥが接続する基地局の切替えの動作の他の例を示すシーケンス図である。
【図２２】実施の形態２について、データ送信に用いられるＰＤＵセッションの切替えおよびＵＥが接続する基地局の切替えの動作の他の例を示すシーケンス図である。
【図２３】実施の形態４について、ＳＬ通信におけるプリエンプションの概要を示す図である。
【図２４】実施の形態４について、ＳＬ通信におけるプリエンプション方法の第１例を示す図である。
【図２５】実施の形態４について、ＳＬ通信におけるプリエンプション方法の第２例を示す図である。
【図２６】実施の形態４について、ＳＬ通信におけるプリエンプション方法の第３例を示す図である。
【図２７】実施の形態４について、ＳＬ通信におけるプリエンプション方法の第４例を示す図である。
【図２８】実施の形態４の変形例１について、ＳＬ通信におけるプリエンプションの概要を示す図である。
【図２９】実施の形態４の変形例１について、ＳＬ通信におけるプリエンプション方法の第１例を示す図である。
【図３０】実施の形態４の変形例１について、ＳＬ通信におけるプリエンプション方法の第２例を示す図である。
【図３１】実施の形態４の変形例１について、ＳＬ通信におけるプリエンプション方法の第３例を示す図である。
【図３２】実施の形態５について、ＵｕのＵＬ用キャリアにＳＬＲＰが設定された場合を示す図である。
【図３３】実施の形態５について、ＵｕのＵＬ用リソースに対してＳＬ通信用にプリエンプションを許可した場合を示す図である。
【図３４】実施の形態５について、ＳＬＲＰ内のリソースに対してＵｕのＵＬ通信用にプリエンプションを許可した場合を示す図である。
【図３５】実施の形態６について、同じキャリア内に２つのＳＬＲＰとＳＬＢＷＰとが構成された場合を示す図である。
【図３６】実施の形態７について、ＳＬにおいて非ＳＵＬに加えてＳＵＬをサポートすることを示す概念図である。
【図３７】実施の形態７について、非ＳＵＬとＳＵＬとでニュメロロジを同じにした場合を示す図である。
【図３８】実施の形態７について、非ＳＵＬとＳＵＬとでニュメロロジを異ならせた場合を示す図である。
【図３９】実施の形態７について、ＳＬ  ＳＵＬでＳＬ通信を行うためのシーケンスの一例を示す図である。
【図４０】実施の形態７について、ＳＬ  ＳＵＬでＳＬ通信を行うためのシーケンスの一例を示す図である。
【図４１】実施の形態７について、ＳＬ  ＳＵＬでＳＬ通信を行うためのシーケンスの他の例を示す図である。
【図４２】実施の形態７について、ＳＬ  ＳＵＬでＳＬ通信を行うためのシーケンスの他の例を示す図である。
【発明を実施するための形態】
【００６５】
実施の形態１．
図２は、３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム２００の全体的な構成を示すブロック図である。図２について説明する。無線アクセスネットワークは、Ｅ−ＵＴＲＡＮ（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）」であってもよい。
【０１１５】
図１３は、ＮＲにおけるセルの構成の一例を示す。ＮＲのセルでは、狭いビームを形成し、方向を変えて送信する。図１３に示す例において、基地局７５０は、ある時間において、ビーム７５１−１を用いて移動端末との送受信を行う。他の時間において、基地局７５０は、ビーム７５１−２を用いて移動端末との送受信を行う。以下同様にして、基地局７５０はビーム７５１−３〜７５１−８のうち１つあるいは複数を用いて移動端末との送受信を行う。このようにすることで、基地局７５０は広範囲のセルを構成する。
【０１１６】
図１３において、基地局７５０が用いるビームの数を８とする例について示したが、ビームの数は８とは異なっていてもよい。また、図１３に示す例において、基地局７５０が同時に用いるビームの数を１つとしたが、複数であってもよい。
【０１１７】
ＴＳＮにおける基地局とＵＥとの間の時刻同期において、基地局はＵＥに対して、時刻同期に関する情報を報知してもよいし、個別に通知してもよい。該情報は、システム情報に含まれてもよいし、ＲＲＣシグナリング、例えば、下り情報通知（DLInformationTransfer）のシグナリングに含まれてもよい。該情報は、時刻参照情報（以下、タイミングリファレンス（timing reference））であってもよい。タイミングリファレンスは、所定のシステムフレームに関する情報と、時刻とを組み合わせた情報、例えば、所定のシステムフレームの末尾における時刻を示す情報であってもよい。ＵＥは、該情報を用いて、自ＵＥ時刻を設定してもよい。
【０１１８】
タイミングリファレンスに含まれる情報において、所定のシステムフレームの代わりに所定のサブフレームに関する情報と、時刻とを組み合わせた情報、例えば、該サブフレーム末尾における時刻を示す情報が用いられてもよい。あるいは、タイミングリファレンスに含まれる情報において、所定のスロットに関する情報と、時刻とを組み合わせた情報、例えば、該スロット末尾における時刻を示す情報が用いられてもよい。前述における末尾の時刻の代わりに、先頭の時刻が用いられてもよい。このことにより、例えば、ＵＥは該時刻までの待ち時間を短縮可能となり、その結果、ＵＥは自ＵＥの時刻設定を迅速に実行可能となる。
【０１１９】
基地局からＵＥに対して送信されるタイミングリファレンスは、例えば、基地局がＧＮＳＳ（Global Navigation Satellite System）あるいはＲＮＳＳ（Regional Navigation Satellite System）より取得した時刻情報を用いて生成したものであってもよいし、位置情報サーバから基地局に対してシグナリングした時刻情報を用いて生成したものであってもよいし、上位ＮＷ装置（例えば、ＡＭＦおよび／あるいはＳＭＦ）が基地局に対してシグナリングした時刻情報を用いて生成したものであってもよいし、時刻サーバから取得した時刻情報を用いて生成したものであってもよい。例えば、上位ＮＷ装置が基地局に対してシグナリングした時刻情報を用いたタイミングリファレンスを基地局がＵＥに送信することにより、通信システム全体における時刻同期が可能となる。
【０１２０】
ＵＥは、該タイミングリファレンスを用いて導出した自ＵＥ時刻について、補正を行ってもよい。該補正は、例えば、基地局とＵＥとの間の伝搬遅延を補正するものであってもよい。該補正において、例えば、タイミングアドバンス（ＴＡ）が用いられてもよい。通信システムにおいて、例えば、ＴＡを、基地局とＵＥとの間の往復の伝搬遅延時間とみなしてもよい。ＵＥは、自ＵＥ時刻に、該ＴＡの半分の値を加算した値を、補正後の自ＵＥ時刻として用いてもよい。
【０１２１】
しかし、ＵＥのモビリティ発生時における時刻同期方法については開示されていない。そのため、モビリティ発生時において、ＵＥは移動先基地局とのスムーズな時刻同期ができない。例えば、移動先基地局とＵＥとの間のＴＡが、移動前基地局とＵＥとの間のＴＡと異なることにより、該ＴＡを用いてＵＥ時刻を補正する際にＵＥ時刻が急変する場合がある。このことにより、ＴＳＮを用いるシステムにおいて誤動作発生の問題が生じる。
【０１２２】
前述の問題に対する解決策を以下に開示する。
【０１２３】
ＵＥは、自ＵＥ時刻補正において、移動先基地局から受信したタイミングリファレンスと、移動先基地局から受信したＴＡとを同時に適用する。すなわち、ＵＥは、該タイミングリファレンスと該ＴＡの片方のみを用いて自ＵＥ時刻の補正を行わないとする。
【０１２４】
ＵＥは、移動先基地局のタイミングリファレンスと移動先基地局のＴＡの両方を同時に用いて、自ＵＥ時刻を補正する。例えば、該タイミングリファレンスに、該ＴＡの半分の値を加算した時刻を、自ＵＥの時刻としてもよい。ＵＥは、該導出以前において、移動元基地局からのタイミングリファレンスおよびＴＡを用いて導出した自ＵＥ時刻をそのまま用いるとしてもよい。
【０１２５】
ＵＥは、移動元基地局から受信したタイミングリファレンスおよび／あるいはＴＡを保持するとしてもよい。該保持は、例えば、移動元基地局から移動先基地局へのハンドオーバ中に行われるとしてもよいし、ハンドオーバ後に行われるとしてもよい。ハンドオーバ後の該保持は例えば、移動先基地局のＴＡおよび移動先基地局のタイミングリファレンスの両方を受信するまでの間、行われてもよい。該保持が、移動元基地局から受信したタイミングリファレンスに対して行われるとしてもよい。ＵＥは、該ＴＡおよび該タイミングリファレンスを用いて、自ＵＥ時刻を導出してもよい。該導出には、自ＵＥのクロックが用いられてもよい。移動元基地局からのＴＡおよびタイミングリファレンスを用いたＵＥ時刻の該導出は、例えば、ハンドオーバ完了までの間継続するとしてもよい。このことにより、例えば、ハンドオーバ失敗時においても、ＵＥは自ＵＥ時刻を維持可能となる。
【０１２６】
ＵＥは、移動先基地局からのタイミングリファレンスおよびＴＡを用いた自ＵＥ時刻補正前において、移動先基地局との上り同期を確立してもよいし、自ＵＥ時刻の該補正と同時に、移動先基地局との上り同期を確立してもよい。該上り同期の確立において、ＵＥは、移動先基地局から受信したＴＡを用いてもよい。ＵＥは、移動先基地局から受信したＴＡと移動元基地局から受信したＴＡの両方を保持するとしてもよい。このことにより、例えば、ＵＥは自ＵＥ時刻を維持しつつ、移動先基地局との上り同期を迅速に確立可能となる。
【０１２７】
ＵＥは、移動先基地局からのタイミングリファレンスおよびＴＡを用いた自ＵＥ時刻補正後において、移動元基地局から受信したＴＡおよび移動元基地局から受信したタイミングリファレンスを解放するとしてもよい。このことにより、例えば、ＵＥにおけるメモリ使用量を削減可能となる。
【０１２８】
図１４は、モビリティ発生時におけるＵＥ時刻補正の動作の概要を示す図である。図１４において、移動元基地局および移動先基地局の時刻は、５Ｇシステムにおいて基準とされる基準時刻と同期しているとする。図１４において、実線で囲まれた四角はＳＦＮを表す。
【０１２９】
図１４に示すタイミング１４０１において、ＵＥは、移動元基地局から自ＵＥまでの伝搬遅延ｄ１を把握しているとする。移動元基地局はＵＥに対し、所定のＳＦＮ末尾における時刻がｔ１である旨のタイミングリファレンスを通知する。ＵＥは、タイミング１４０２において、該ＳＦＮ末尾の信号を受信した時点での自ＵＥの時刻を、タイミングリファレンスに含まれる時刻ｔ１に、該伝搬遅延ｄ１を加算した時刻（ｔ１＋ｄ１）として設定する。
【０１３０】
図１４に示すタイミング１４０３において、ＵＥが移動元基地局から移動先基地局にハンドオーバしたとする。タイミング１４０４において、ＵＥは、移動先基地局から自ＵＥまでの伝搬遅延ｄ２を把握しているとする。移動先基地局はＵＥに対し、前述とは異なる所定のＳＦＮ末尾における時刻がｔ２である旨のタイミングリファレンスを通知する。ＵＥは、タイミング１４０５において、該ＳＦＮ末尾の信号を受信した時点での自ＵＥの時刻を、タイミングリファレンスに含まれる時刻ｔ２に、該伝搬遅延ｄ２を加算した時刻（ｔ２＋ｄ２）として設定し直す。
【０１３１】
図１４において、タイミングリファレンスが所定のＳＦＮ末尾における時刻を示す情報である場合について示したが、所定のサブフレーム末尾における時刻を用いてもよいし、所定のスロット末尾における時刻を用いてもよいし、所定のミニスロット末尾における時刻を用いてもよいし、所定のシンボル末尾における時刻を用いてもよい。前述の末尾における時刻の代わりに、先頭における時刻を用いてもよい。前述の場合において、図１４における実線で囲まれた四角は、サブフレームであってもよいし、スロットであってもよいし、ミニスロットであってもよいし、シンボルであってもよい。このことにより、例えば、ＵＥがタイミングリファレンスを受信してから、該タイミングリファレンスに含まれる所定の時刻までの時間を短縮可能となる。その結果、ＵＥは時刻同期を迅速に実行可能となる。
【０１３２】
基地局は、タイミングリファレンスを報知してもよいし、ＵＥ個別に通知してもよい。タイミングリファレンスの通知には、システム情報が用いられてもよいし、ＲＲＣ個別シグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよい。タイミングリファレンスにＭＡＣシグナリングが用いられる場合の例として、該ＭＡＣシグナリングが含まれるスロットあるいはミニスロットの所定のタイミング（例えば、スロット／ミニスロットの先頭、末尾）における時刻に関する情報が含まれてもよい。タイミングリファレンスにＬ１／Ｌ２シグナリングが用いられる場合の例として、該Ｌ１／Ｌ２シグナリングが含まれるスロットあるいはミニスロットの所定のタイミング（例えば、スロット／ミニスロットの先頭、末尾）における時刻に関する情報が含まれてもよい。
【０１３３】
ＲＲＣ＿ＩＮＡＣＴＩＶＥステートまたはＲＲＣ＿ＩＤＬＥステートのＵＥが、タイミングリファレンスを取得してもよい。該ＵＥは、例えば、基地局から報知されるシステム情報を用いて、タイミングリファレンスを取得してもよい。該ＵＥは、該タイミングリファレンスを用いて、自ＵＥ時刻を設定してもよい。該ＵＥは、自ＵＥ時刻における不確定性（uncertainty）を、該基地局のセル半径を用いて決めてもよい。該セル半径は、例えば、基地局より報知されてもよい。このことにより、例えば、通信システムにおいて、ＵＥのＲＲＣステートによらず、時刻同期が可能となる。
【０１３４】
基地局からＵＥに対するタイミングリファレンス通知は、該ＵＥのみを対象とした通知（例えば、該ＵＥのＣ−ＲＮＴＩが含まれる通知）であってもよいし、複数のＵＥに対する通知であってもよい。該複数のＵＥは、例えば、該ＵＥが属するビーム内の複数のＵＥ（例えば該ビーム内の全てのＵＥ、該ビーム内の一部のＵＥ）であってもよい。該複数のＵＥは、全てのＵＥであってもよい。基地局から該複数のＵＥに対するタイミングリファレンス通知において、例えば、グループ共通ＰＤＣＣＨ（group common PDCCH）が用いられてもよい。このことにより、例えば、基地局は多くのＵＥにタイミングリファレンスを通知可能となり、その結果、通信システムにおける効率を向上可能となる。
【０１３５】
ＵＥは基地局に対し、タイミングリファレンスの通知を要求してもよい。該要求は、例えば、システム情報要求（System Information Request）のシグナリング、例えば、システム情報要求のランダムアクセスプリアンブルを含んだＰＲＡＣＨを用いて行われてもよいし、ＲＲＣ個別シグナリングが用いられてもよい。ＲＲＣ個別シグナリングが用いられる例として、該要求がＲＲＣ再設定完了（RRCReconfigurationComplete）のシグナリングに含まれてもよいし、新たなＲＲＣ個別シグナリングが設けられてもよい。基地局は、該要求をもとに、ＵＥに対してタイミングリファレンスを通知してもよい。このことにより、例えば、ＵＥは、システム情報の報知周期を待たず、迅速にタイミングリファレンスを取得可能となる。
【０１３６】
タイミングリファレンスの要求に関する他の例として、ＵＥは上位ＮＷ装置に対して該要求を行ってもよい。上位ＮＷ装置は、例えば、ＡＭＦであってもよいし、ＳＭＦであってもよい。ＵＥからＳＭＦへの該要求は、ＡＭＦを経由して行われてもよい。該要求には、ＮＡＳシグナリングが用いられてもよい。該要求は、例えば、タイミングリファレンスの受信先となる基地局に関する情報を含んでもよいし、含まなくてもよい。該上位ＮＷ装置は、該要求を用いて、基地局に対し、該ＵＥに対するタイミングリファレンスの通知を指示してもよい。該指示には、例えば、ＮＧインタフェース上のシグナリングが用いられてもよい。該上位ＮＷ装置が指示する先の基地局は、例えば、ＵＥから該上位ＮＷ装置に対する要求に含まれる情報において示される基地局と同じであってもよい。該基地局は、該指示を用いて、ＵＥに対して、タイミングリファレンスを通知してもよい。このことにより、例えば、上位ＮＷ装置は、基地局からＵＥに対するタイミングリファレンス通知を制御可能となり、その結果、通信システムにおける効率を向上可能となる。
【０１３７】
タイミングリファレンスの通知に関する他の例として、ＮＡＳシグナリングが用いられてもよい。上位ＮＷ装置がＵＥに対してタイミングリファレンスを通知してもよい。上位ＮＷ装置は、例えば、ＡＭＦであってもよいし、ＳＭＦであってもよいし、ＵＰＦであってもよい。ＳＭＦはＵＥに対するタイミングリファレンスを、ＡＭＦ経由で行ってもよい。前述の場合において、該上位ＮＷ装置は、基地局のフレームタイミングを取得していてもよい。基地局は上位ＮＷ装置に対し、フレームタイミングに関する情報を通知してもよい。該通知には、例えば、ＮＧインタフェースが用いられてもよい。このことにより、例えば、５Ｇシステム内の、異なる基地局配下のＵＥの間で同期確立が可能となる。他の例として、位置情報サーバがＵＥに対してタイミングリファレンスを通知してもよい。該上位ＮＷ装置は、フレームタイミングの取得の代わりに、サブフレームタイミングを取得してもよいし、スロットタイミングを取得してもよいし、ミニスロットタイミングを取得してもよいし、シンボルタイミングを取得してもよい。
【０１３８】
図１５は、ハンドオーバ発生時におけるＵＥ時刻補正の動作を示すシーケンス図である。図１５は、移動元基地局と移動先基地局のいずれもがＮＲ基地局（ｇＮＢ）である例について示している。また、図１５は、ＵＥが移動先ｇＮＢからのタイミングリファレンスを、移動先ｇＮＢからの下り情報通知（DLInformationTransfer）のシグナリングによって取得する例について示している。図１５において、特に指定のない限り、移動元ｇＮＢと移動先ｇＮＢとの間の通信にはＸｎインタフェースが用いられるとする。
【０１３９】
図１５に示すステップＳＴ１５０１において、移動元ｇＮＢは、ＵＥを移動先ｇＮＢへハンドオーバさせることを決定する。ステップＳＴ１５０２において、移動元ｇＮＢは移動先ｇＮＢに対して、ハンドオーバ要求（Handover Request）を通知する。ステップＳＴ１５０３において、移動先ｇＮＢは許可制御（Admission Control）を行う。
【０１４０】
図１５に示すステップＳＴ１５０４において、移動先ｇＮＢは移動元ｇＮＢに対し、ハンドオーバ要求に対する肯定応答（Handover Request Acknowledge）を通知する。ステップＳＴ１５０５において、移動元ｇＮＢはＵＥに対し、移動先ｇＮＢへのハンドオーバを指示する。該指示には、例えば、ＲＲＣ再設定（RRCReconfiguration）のシグナリングが用いられてもよい。ステップＳＴ１５０６において、ＵＥは、接続先の基地局を移動元ｇＮＢから移動先ｇＮＢに切替える。ステップＳＴ１５０６において、ＵＥは、移動元ｇＮＢから受信したタイミングリファレンスおよびＴＡを用いて導出した自ＵＥ時刻を用いてもよい。ステップＳＴ１５０６において、ＵＥは、移動元ｇＮＢから受信したタイミングリファレンスおよびＴＡを保持してもよい。
【０１４１】
図１５に示すステップＳＴ１５０７において、ＵＥは移動先ｇＮＢに対してＰＲＡＣＨを送信する。ステップＳＴ１５０８において、移動先ｇＮＢはＵＥに対して、ランダムアクセス応答（Random Access Response；ＲＡＲ）を送信する。移動先ｇＮＢは、ステップＳＴ１５０８のＲＡＲに、ＴＡおよび／あるいは上りグラントを含めてＵＥに通知してもよい。ＵＥは、該ＴＡを用いて、ステップＳＴ１５０９において、移動先ｇＮＢとの上り同期を確立してもよい。ステップＳＴ１５０９において、ＵＥは、自ＵＥ時刻の補正を行わないとしてもよい。ＵＥは、該上りグラントを用いて、ステップＳＴ１５１０において、移動先ｇＮＢに対して、ハンドオーバが完了したことを示す情報を通知してもよい。該情報の通知は、例えば、ＲＲＣ再設定完了（RRCReconfigurationComplete）を用いて行われてもよい。
【０１４２】
図１５に示すステップＳＴ１５１１において、移動先ｇＮＢはＵＥに対して、タイミングリファレンスを通知する。該通知には、ＲＲＣシグナリング、例えば、下り情報通知（DLInformationTransfer）が用いられてもよい。ステップＳＴ１５１２において、ＵＥは、ステップＳＴ１５０８にて受信したＴＡ、および、ステップＳＴ１５１１にて受信したタイミングリファレンスを用いて、自ＵＥ時刻補正を行う。該時刻補正は、例えば、該タイミングリファレンスに含まれる時刻に、該ＴＡの半分の値を加算した時刻を、該タイミングリファレンスにて指定された時点での時刻として設定するものであってもよい。ＵＥは、ステップＳＴ１５１２において、移動元ｇＮＢのタイミングリファレンスおよび移動元ｇＮＢのＴＡを破棄してもよい。
【０１４３】
図１５において、タイミングリファレンスの通知にＲＲＣ個別シグナリングが用いられる例について示したが、タイミングリファレンスの通知にシステム情報が用いられてもよい。ＵＥは、システム情報を用いて、タイミングリファレンスを取得してもよい。このことにより、例えば、移動先ｇＮＢから配下のＵＥへのシグナリング量を削減可能となる。
【０１４４】
図１５に示すステップＳＴ１５１０では、ＵＥが移動先ｇＮＢに対して、ハンドオーバが完了したことを示す情報を通知する場合について示した。該通知に、ＵＥから移動先ｇＮＢへのタイミングリファレンス通知要求が含まれてもよい。例えば、ＵＥから移動先ｇＮＢに送信されるＲＲＣ再設定完了（RRCReconfigurationComplete）のシグナリングに、タイミングリファレンス通知要求に関する情報が含まれてもよい。移動先ｇＮＢは、該要求を用いて、ＵＥに対してタイミングリファレンスを通知してもよい。このことにより、例えば、移動先ｇＮＢはＵＥに対してタイミングリファレンスを迅速に通知可能となる。
【０１４５】
移動先基地局のタイミングリファレンスが、ハンドオーバ前にＵＥに通知されてもよい。移動先基地局は、自ｇＮＢのタイミングリファレンスを移動元基地局に通知してもよい。該通知には、基地局間インタフェースにおけるシグナリング（例えばＸｎインタフェース）が用いられてもよい。例えば、該タイミングリファレンスが、ハンドオーバ要求肯定応答のシグナリングに含まれて通知されてもよい。移動元基地局は、該応答のシグナリングを用いて、移動先基地局のタイミングリファレンスをＵＥに通知してもよい。例えば、移動元基地局は、該タイミングリファレンスをハンドオーバ指示のシグナリング（例えばＲＲＣ再設定（RRCReconfiguration））に含めて通知してもよい。ＵＥは、該指示のシグナリングを用いて、移動先基地局のタイミングリファレンスを取得してもよい。ＵＥは、移動先基地局から受信するＴＡ、および、該タイミングリファレンスを用いて、自ＵＥ時刻の補正を行ってもよい。該補正は、例えば、該ＴＡ受信後において行われてもよい。このことにより、例えば、ＵＥは自ＵＥ時刻補正を迅速に実行可能となる。
【０１４６】
図１６は、ハンドオーバ発生時におけるＵＥ時刻補正の動作の他の例を示すシーケンス図である。図１６は、移動元基地局と移動先基地局のいずれもがＮＲ基地局（ｇＮＢ）である例について示している。また、図１６は、ＵＥが移動先ｇＮＢからのタイミングリファレンスをハンドオーバ指示を利用して取得する例について示している。図１６において、図１５と共通する処理には同じステップ番号を付し、共通する説明を省略する。
【０１４７】
図１６に示すステップＳＴ１５０１〜ＳＴ１５０３は、図１５と同様である。
【０１４８】
図１６に示すステップＳＴ１６０４において、移動先ｇＮＢは移動元ｇＮＢに対し、ハンドオーバ要求に対する肯定応答（Handover Request Acknowledge）を通知する。移動先ｇＮＢは該応答に、自ｇＮＢのタイミングリファレンスを含めて移動元ｇＮＢに通知する。ステップＳＴ１６０５において、移動元ｇＮＢはＵＥに対し、移動先ｇＮＢへのハンドオーバを指示する。移動元ｇＮＢは該指示に、移動先ｇＮＢのタイミングリファレンスを含めてＵＥに通知する。該指示には、例えば、ＲＲＣ再設定（RRCReconfiguration）のシグナリングが用いられてもよい。ステップＳＴ１５０６において、ＵＥは、接続先の基地局を移動元ｇＮＢから移動先ｇＮＢに切替える。ステップＳＴ１５０６において、ＵＥは、ステップＳＴ１６０５において受信したハンドオーバ指示から、移動先ｇＮＢのタイミングリファレンスを取得する。ステップＳＴ１５０６において、ＵＥは、移動元ｇＮＢから受信したタイミングリファレンスおよびＴＡを用いて導出した自ＵＥ時刻を用いてもよい。ステップＳＴ１５０６において、ＵＥは、移動元ｇＮＢから受信したタイミングリファレンスおよびＴＡを保持してもよい。
【０１４９】
図１６に示すステップＳＴ１５０７〜ＳＴ１５０９は、図１５と同様である。
【０１５０】
図１６に示すステップＳＴ１６１１において、ＵＥは、ステップＳＴ１５０８にて受信したＴＡ、および、ステップＳＴ１６０５にて受信したタイミングリファレンスを用いて、自ＵＥ時刻補正を行う。該時刻補正の方法は、図１５において開示した例と同様であってもよい。ＵＥは、ステップＳＴ１６１１において、移動元ｇＮＢのタイミングリファレンスおよび移動元ｇＮＢのＴＡを破棄してもよい。
【０１５１】
図１６に示すステップＳＴ１５１０は、図１５と同様である。
【０１５２】
ＵＥは、複数回受信したタイミングリファレンスのうち、最新のタイミングリファレンスのみを用いるとしてもよい。例えば、ＵＥが、基地局から報知されたタイミングリファレンスと、個別に通知されたタイミングリファレンスとの両方を受信した場合において、ＵＥは、後から受信したタイミングリファレンスのみを用いるとしてもよい。ＵＥは、先に受信したタイミングリファレンスを破棄してもよい。このことにより、例えば、ＵＥ時刻の精度を向上可能となる。
【０１５３】
他の解決策を開示する。ＵＥは、移動先基地局のＴＡを推定してもよい。ＵＥは、推定した該ＴＡおよび移動先基地局からのタイミングリファレンスを用いて、自ＵＥ時刻を補正してもよい。ＵＥは、移動先基地局からの伝搬遅延と、移動元基地局からの伝搬遅延との間の差分を用いて、移動先基地局のＴＡを推定してもよい。ＵＥにおける該推定は、例えば、移動先基地局および移動元基地局の送信時におけるスロットタイミング（フレームタイミングであってもよい、以下、同様）が同じである場合において適用可能としてもよい。ＵＥにおける該推定は、例えば、ＴＲＰ（Transmission Reception Point）間のモビリティにおいて適用されるとしてもよい。このことにより、例えば、ＵＥはランダムアクセス処理開始前に自ＵＥ時刻を補正可能となる。
【０１５４】
ＵＥは、移動元基地局のスロットタイミングを保持してもよい。ＵＥは、移動元基地局のＴＡを保持してもよい。ＵＥは、移動先基地局のスロットタイミングを取得してもよい。ＵＥは、移動先基地局のスロットタイミングと移動先基地局のスロットタイミングの差分と、移動元基地局からＴＡとを用いて、移動先基地局のＴＡを導出してもよい。例えば、ＵＥは、移動先基地局のスロットタイミングと移動先基地局のスロットタイミングの差分を倍にした値を移動元基地局からのＴＡに加算した値を、移動先基地局からのＴＡとして推定してもよい。このことにより、例えば、ＵＥは、移動先基地局とのランダムアクセス処理実行以前に自ＵＥ時刻を補正可能となる。前述において、ＵＥは、移動先基地局とのランダムアクセス処理を行わないとしてもよい。ＵＥは、推定した該ＴＡを用いて、移動先基地局との上り同期を確立してもよい。このことにより、例えば、ＵＥはハンドオーバ処理を迅速に実行可能となる。
【０１５５】
移動元基地局からＵＥへのハンドオーバ指示のシグナリングに、移動元基地局と移動先基地局のフレームタイミングに関する情報が含まれてもよい。該情報は、例えば、両基地局のフレームタイミングが同じか否かを示す情報であってもよいし、ＴＡ推定の実行有無に関する情報であってもよいし、両基地局間のフレームタイミングの差分に関する情報であってもよい。差分に関する該情報は、両基地局の送信時における情報であってもよい。ＵＥは、該情報を用いて、ＴＡ推定を行ってもよいし、行わなくてもよいし、ＴＡ推定の実行有無を決定してもよい。このことにより、例えば、ＵＥはＴＡ推定を迅速に実行可能となる。
【０１５６】
移動元基地局は、移動先基地局のスロットタイミングに関する情報を取得してもよい。移動元基地局は、該情報の取得を、例えば、セルサーチを用いて行ってもよい。移動元基地局は、取得した該情報を用いて、移動元基地局と移動先基地局のフレームタイミングに関する情報を導出してもよい。移動元基地局と移動先基地局のフレームタイミングに関する情報は、前述と同様であってもよい。移動元基地局は、導出した該情報をＵＥに通知してもよい。他の例として、移動先基地局が、移動元基地局のスロットタイミングに関する情報を取得するとしてもよい。移動先基地局は、該情報の取得を、例えば、セルサーチを用いて行ってもよい。移動先基地局は、取得した該情報を用いて、移動元基地局と移動先基地局のスロットタイミングに関する情報を、移動元基地局に通知してもよい。例えば、移動元基地局は、該情報をＵＥに通知してもよい。このことにより、例えば、移動元基地局あるいは移動先基地局は、互いの基地局のスロットタイミングに関する情報を取得可能となる。
【０１５７】
移動先ｇＮＢのフレームタイミングを、ＵＥが取得してもよい。ＵＥにおける該取得の動作は、例えば、メジャメント実行中において行われてもよい。ＵＥは、移動元ｇＮＢに対し、取得した該タイミングに関する情報を通知してもよいし、移動元ｇＮＢのフレームタイミングと移動先ｇＮＢのフレームタイミングの差分に関する情報を通知してもよい。前述の通知は、例えば、ＵＥから移動元ｇＮＢへのメジャメント結果報告に含められて行われてもよい。移動元ｇＮＢは、該通知を用いて、移動先ｇＮＢとＵＥとの間の接続におけるＴＡを導出してもよい。該ＴＡを、移動先ｇＮＢが導出して移動元ｇＮＢに通知するとしてもよい。移動元ｇＮＢは、該ＴＡをＵＥに通知してもよい。該通知は、例えば、移動元ｇＮＢからＵＥに対するハンドオーバ指示に含められて行われてもよい。このことにより、例えば、ＵＥは該ＴＡを迅速に取得可能となり、その結果、ＵＥは移動先ｇＮＢと迅速な同期確立が可能となる。
【０１５８】
図１７は、ハンドオーバ発生時においてＵＥが移動先基地局のＴＡを推定してＵＥ時刻補正の動作を行う例を示すシーケンス図である。図１７は、移動元基地局と移動先基地局のいずれもがＮＲ基地局（ｇＮＢ）である例について示している。図１７は、移動元ｇＮＢと移動先ｇＮＢのフレームタイミングが同一である例について示している。また、図１７は、ＵＥが移動先ｇＮＢからのタイミングリファレンスを、ハンドオーバ指示を利用して取得する例について示している。図１７において、図１５、図１６と共通する処理には同じステップ番号を付し、共通する説明を省略する。
【０１５９】
図１７に示すステップＳＴ１７０１において、ＵＥは、移動元ｇＮＢからＳＳブロックを受信し、移動元ｇＮＢのフレームタイミングを取得する。
【０１６０】
図１７に示すステップＳＴ１５０１〜ＳＴ１５０３は、図１５と同様である。ステップＳＴ１６０４、ＳＴ１６０５、ＳＴ１５０６は、図１６と同様である。
【０１６１】
図１７に示すステップＳＴ１７０７において、ＵＥは、移動先ｇＮＢからＳＳブロックを受信し、移動先ｇＮＢのフレームタイミングを取得する。ステップＳＴ１７０８において、ＵＥは、ステップＳＴ１７０１によって取得した移動元ｇＮＢのフレームタイミングと、ステップＳＴ１７０７によって取得した移動先ｇＮＢのフレームタイミングを用いて、移動先ｇＮＢにおけるＴＡを推定する。ステップＳＴ１７１１において、ＵＥは、ステップＳＴ１７０８において推定したＴＡ、および、ステップＳＴ１６０５にて受信したタイミングリファレンスを用いて、自ＵＥ時刻補正を行う。該時刻補正の方法は、図１５において開示した例と同様であってもよい。ＵＥは、ステップＳＴ１７１１において、移動元ｇＮＢのタイミングリファレンスおよび移動元ｇＮＢのＴＡを破棄してもよい。
【０１６２】
図１７に示すステップＳＴ１５０７〜ＳＴ１５０９、ＳＴ１６１１、ＳＴ１５１０は、図１５と同様である。
【０１６３】
図１７では、ＵＥが自ＵＥ時刻補正を２回行う例について示した。このことにより、例えば、ＵＥは、ハンドオーバ後の時刻を迅速に取得可能としつつ、２回目の補正により高精度の時刻を取得可能となる。
【０１６４】
図１７では、ＵＥが自ＵＥ時刻補正を２回行う例について示したが、自ＵＥ時刻補正は１回のみであってもよい。例えば、図１７に示すステップＳＴ１６１１を行わないとしてもよい。このことにより、例えば、ＵＥにおける処理量を削減可能となる。
【０１６５】
図１７では、ＵＥが、移動先ｇＮＢからＳＳブロックを受信するステップＳＴ１７０７を、移動先ｇＮＢへの切替えステップＳＴ１５０６の後に行う例について示した。これに対し、移動先ｇＮＢからのＳＳブロックの受信は、移動先ｇＮＢへの切替えの前に行ってもよい。例えば、ＵＥは、ステップＳＴ１５０１のハンドオーバ決定の前におけるメジャメントにおいて、移動先ｇＮＢからＳＳブロックを受信し、移動先ｇＮＢからのフレームタイミングを保持してもよい。このことにより、例えば、ＵＥは、移動先ｇＮＢへの切替え後、移動先ＴＡ推定を迅速に実行可能となる。
【０１６６】
ＵＥは、移動先ｇＮＢからのＴＡのみを用いて、自ＵＥ時刻補正を行ってもよい。該補正は、例えば、移動元ｇＮＢと移動先ｇＮＢの間で時刻が同期している場合に行われてもよい。移動元ｇＮＢはＵＥに対し、移動先ｇＮＢとの間での時刻同期に関する情報を通知してもよい。該情報は、例えば、時刻同期の有無に関する情報であってもよいし、時刻同期の精度に関する情報であってもよい。ＵＥは、該時刻同期に関する情報および移動先ｇＮＢからのＴＡを用いて、自ＵＥにおける時刻補正を行ってもよい。このことにより、例えば、ＵＥは、移動先ｇＮＢからタイミングリファレンスを受信不要となり、その結果、ＵＥ時刻補正を迅速に実行可能となる。
【０１６７】
ＵＥは、受信したタイミングリファレンスを破棄してもよい。例えば、該タイミングリファレンスにおいて含まれるＳＦＮ到達以前にＵＥがハンドオーバした場合において、ＵＥは該タイミングリファレンスを破棄してもよい。他の例として、ＵＥが複数のタイミングリファレンスを受信した場合において、ＵＥは、最新ではないタイミングリファレンスを破棄してもよい。このことにより、例えば、ＵＥ時刻の誤動作を防止可能となる。
【０１６８】
ＵＥは、該タイミングリファレンスにおいて含まれるＳＦＮ到達以前にハンドオーバした場合において、ハンドオーバ以前のＳＦＮを基準として自ＵＥ時刻を設定あるいは補正してもよい。このことにより、例えば、基地局とＵＥとの間におけるシグナリングを削減可能となる。
【０１６９】
ＵＥは、自ＵＥ時刻の不確定性を拡大してもよい。該不確定性の拡大量は、自ＵＥのクロック精度を用いて決められてもよい。例えば、自ＵＥの単位時間当たりのクロック誤差に、前回自ＵＥ時刻補正を行ってから、あるいは前回の不確定性拡大を行ってからの経過時間を乗じた値が、該不確定性の拡大量であってもよい。該拡大の動作は、ハンドオーバ発生時に行われてもよいし、ハンドオーバが発生しない場合において行われてもよい。該拡大の動作は、例えば、基地局からのタイミングリファレンスを受信しない間、行われるとしてもよい。
【０１７０】
他の例として、ＵＥは該不確定性の拡大を、ハンドオーバ発生時に行ってもよい。該拡大は、移動先基地局からのタイミングリファレンス受信時において行われてもよいし、移動先基地局からのＴＡを受信していない場合において行われるとしてもよい。例えば、ＵＥは、移動先基地局のセル半径の半分の距離の伝搬遅延に相当する時間の値を、該不確定性に加算してもよい。ＵＥは、移動先基地局からのＴＡを、該セル半径の半分の距離の伝搬遅延に相当する時間の値と仮定してもよい。ＵＥは、移動先基地局からのタイミングリファレンスおよび仮定した該ＴＡを用いて、ＵＥ時刻の補正を行ってもよい。このことにより、例えば、ＵＥはハンドオーバ後のＵＥ時刻を迅速に導出可能となる。
【０１７１】
本実施の形態１における方法は、基地局間モビリティとして例示したハンドオーバ以外にも、ＤＵ間モビリティおよび／あるいはＴＲＰ間モビリティに適用されてもよい。このことにより、例えば、基地局が複数のＤＵおよび／あるいはＴＲＰを有する場合においても、モビリティにおけるＵＥの時刻急変を防止可能となる。その結果、通信システムにおける誤動作を防止可能となる。
【０１７２】
ここで、基地局、ＤＵ、およびＴＲＰは、ＵＥと無線通信可能に構成された通信装置という点で共通する。そのため、基地局間モビリティ、ＤＵ間モビリティ、およびＴＲＰ間モビリティを、通信装置間モビリティと称することも可能である。
【０１７３】
本実施の形態１における方法が、ＵＥの、通信装置間の移動に適用されてもよい。例えば、ＴＡが変更となった場合において、本実施の形態１における方法が適用されてもよい。ＵＥは、変更後のＴＡと、ＴＡ変更後に受信したタイミングリファレンスとを同時に用いて、自ＵＥ時刻を補正するとしてもよい。このことにより、例えば、ＴＡ変更時における自ＵＥ時刻の急変を防止可能となり、その結果、通信システムにおける誤動作を防止可能となる。
【０１７４】
通信装置間の該移動において、ＵＥは、前回の自ＵＥ時刻補正時と、ＴＡ変更後との間における、下りフレームタイミングの差分、および、変更後のＴＡを用いて、自ＵＥ時刻を補正してもよい。ＵＥは、該差分の導出にあたり、前回の自ＵＥ時刻補正時における下りフレームタイミングに関する情報を保持してもよい。該補正は、ＵＥがＴＡ変更後にタイミングリファレンスを受信する前に行われてもよい。このことにより、例えば、ＵＥは、変更後のＴＡを受信した後において、自ＵＥ時刻を迅速に補正可能となる。
【０１７５】
本実施の形態１により、モビリティ発生時におけるＵＥ時刻の急変を防止可能となる。その結果、ＴＳＮを用いるシステムにおける誤動作を防止可能となる。
【０１７６】
実施の形態１の変形例１．
ＴＳＮにおける基地局とＵＥとの間の時刻同期が、ＤＣを用いる場合に適用されてもよい。
【０１７７】
ＵＥは、マスタ基地局および／あるいはセカンダリ基地局からタイミングリファレンスを受信する毎に、自ＵＥ時刻補正を行う。
【０１７８】
ＵＥは、マスタ基地局からのタイミングリファレンスを優先してもよい。例えば、ＵＥは、セカンダリ基地局から送信されるタイミングリファレンスを破棄してもよい。このことにより、例えば、通信システムにおける複雑性を回避可能となる。
【０１７９】
他の例として、ＵＥは、セカンダリ基地局からのタイミングリファレンスを優先してもよい。例えば、マスタ基地局がｅＮＢであり、セカンダリ基地局がｇＮＢである場合において、ＵＥは、セカンダリ基地局からのタイミングリファレンスを優先してもよい。該ｇＮＢは、該ｅＮＢよりも高精度であるとしてもよい。このことにより、例えば、ＵＥ時刻を高精度に維持可能となる。
【０１８０】
他の例として、ＵＥは、どちらの基地局からのタイミングリファレンスを優先させるかを決めてもよい。ＵＥにおける該決定には、例えば、各基地局の時刻の精度に関する情報が用いられてもよい。例えば、ＵＥは、精度が高い基地局からのタイミングリファレンスを優先させてもよい。精度に関する該情報は、例えば、タイミングリファレンスに含まれる不確定性（uncertainty）の情報であってもよい。このことにより、例えば、ＵＥ時刻の精度を向上可能となる。
【０１８１】
他の例として、どちらの基地局からのタイミングリファレンスを優先させるかを、基地局自身が決定してＵＥに通知してもよい。該通知において、ＲＲＣシグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよい。該決定を行う基地局は、マスタ基地局であってもよいし、セカンダリ基地局であってもよい。基地局における該決定には、例えば、各基地局の時刻の精度に関する情報が用いられてもよい。例えば、マスタ基地局は、精度が高い基地局からのタイミングリファレンスを優先させると決定してもよい。精度に関する該情報は、例えば、タイミングリファレンスに含まれる不確定性（uncertainty）の情報であってもよい。このことにより、例えば、ＵＥ時刻の精度を向上可能となる。
【０１８２】
ＵＥにおける該決定に関する他の例として、実施の形態１の変形例２において開示する、タイミングリファレンスの有効期間が用いられてもよい。例えば、ＵＥは、該有効期間が長い方の基地局からのタイミングリファレンスを優先させてもよい。このことにより、例えば、前述と同様の効果が得られる。基地局における該決定においても、同様としてもよい。
【０１８３】
ＵＥにおける該決定に関する他の例として、該有効期間の最大値が用いられてもよい。マスタ基地局および／あるいはセカンダリ基地局はＵＥに対し、タイミングリファレンスの有効期間の最大値に関する情報を報知してもよいし、個別に通知してもよい。このことにより、例えば、時間経過に伴うタイミングリファレンス更新によって発生する、ＵＥにより決定される該基地局が交互に入れ替わる現象を防止可能となる。基地局における該決定においても、同様としてもよい。
【０１８４】
他の例として、ＵＥがどちらの基地局からのタイミングリファレンスを用いるかに関する情報を、上位ＮＷ装置が該ＵＥに通知してもよい。該上位ＮＷ装置は、５Ｇコア装置、例えば、ＡＭＦであってもよいし、ＳＭＦであってもよい。他の例として、該上位ＮＷ装置は、ＥＰＣ、例えば、ＭＭＥであってもよい。該通知は、例えば、ＮＡＳシグナリングであってもよいし、上位ＮＷ装置と基地局との間のインタフェースにおけるシグナリングと、基地局とＵＥとの間のインタフェースにおけるシグナリング（例えば、ＲＲＣシグナリング、ＭＡＣシグナリング、Ｌ１／Ｌ２シグナリング）の組合せであってもよい。
【０１８５】
他の例として、ＵＥは、複数の時刻を保持してもよい。例えば、マスタ基地局からのタイミングリファレンスを用いて設定および／あるいは補正される時刻と、セカンダリ基地局からのタイミングリファレンスを用いて設定および／あるいは補正される時刻の両方を保持してもよい。このことにより、例えば、マスタ基地局とセカンダリ基地局との間で時刻が異なる場合においても、ＵＥ時刻の急変を防止可能となる。その結果、通信システムにおける誤動作を防止可能となる。
【０１８６】
ＵＥが複数の時刻を保持する他の例として、ＵＥが利用するサービル要件毎に異なるＵＥ時刻が設けられてもよい。例えば、ＵＥは、異なるネットワークスライシング（Network Slicing）毎にＵＥ時刻を保持してもよい。このことにより、例えば、ＵＥが利用する異なるサービス要件における時刻管理を柔軟に実行可能となる。
【０１８７】
タイミングリファレンスの情報に、送信元基地局に関する情報が含まれてもよい。マスタ基地局および／あるいはセカンダリ基地局は、自基地局に関する情報をタイミングリファレンスの情報に含めてＵＥに通知してもよい。基地局に関する該情報は、例えば、マスタ基地局かセカンダリ基地局かを示す識別子であってもよい。ＵＥは、送信元基地に関する情報を用いて、タイミングリファレンスの送信元となる基地局を特定してもよい。
【０１８８】
タイミングリファレンスの情報に、送信元基地局に関する情報が含まれないとしてもよい。ＵＥは、基地局との通信経路に関する情報、例えば、使用ベアラに関する情報を用いて、該データがどちらの時刻と対応付けされるかを決めてもよい。このことにより、例えば、通信システムにおける複雑性を回避可能となる。
【０１８９】
基地局からＵＥに対して送信されるデータに、どちらの基地局からのタイミングリファレンスを用いる時刻であるかを示す情報が含まれてもよいし、付加されてもよい。該情報の含有あるいは付加は、例えば、ＵＰＦが行ってもよいし、ＡＭＦが行ってもよいし、基地局が行ってもよい。基地局が該情報の含有あるいは付加を行う場合において、該情報の含有あるいは付加は、ＲＲＣレイヤが行ってもよいし、ＳＤＡＰレイヤが行ってもよいし、ＲＲＣレイヤあるいはＰＤＣＰレイヤより上位のレイヤが行ってもよいし、ＲＬＣレイヤが行ってもよいし、ＭＡＣレイヤが行ってもよい。基地局からＵＥに対する該情報の通知は、ＲＲＣシグナリングを用いて行われてもよいし、ＳＤＡＰヘッダに含められて行われてもよいし、ＰＤＣＰヘッダに含められて行われてもよいし、ＰＤＣＰ制御ＰＤＵとして行われてもよいし、ＲＬＣヘッダに含められて行われてもよいし、ＲＬＣ制御ＰＤＵとして行われてもよいし、ＭＡＣヘッダに含められて行われてもよいし、ＭＡＣシグナリングとして行われてもよいし、Ｌ１／Ｌ２シグナリングとして行われてもよい。ＵＥは、該情報を用いて、該データがどちらの時刻と対応付けされるかを決めてもよい。
【０１９０】
該データがどちらの基地局からのタイミングリファレンスを用いて処理されるかを、ＵＰＦが決定してもよいし、ＡＭＦが決定してもよい。例えば、Ｕプレインデータについて、ＵＰＦが決定するとしてもよいし、Ｃプレインデータについて、ＡＭＦが決定するとしてもよいし、Ｕプレインデータ、ＣプレインデータともにＡＭＦが決定するとしてもよい。該決定において、例えば、各基地局の時刻の精度に関する情報が用いられてもよい。該情報は、例えば、タイミングリファレンスに含まれる不確定性（uncertainty）の情報であってもよい。該精度に関する情報は、各基地局からＵＰＦおよび／あるいはＡＭＦに対して通知してもよいし、ＵＥがＡＭＦに対して通知してもよい。各基地局からＵＰＦおよび／あるいはＡＭＦへの通知において、ＮＧインタフェースが用いられてもよい。ＵＥからＡＭＦへの通知において、ＮＡＳシグナリングが用いられてもよい。ＡＭＦは、該情報をＵＰＦに通知してもよいし、該決定に関する情報をＵＰＦに通知してもよい。ＡＭＦからＵＰＦへの該通知は、ＳＭＦを経由して行われてもよい。ＵＰＦおよび／あるいはＡＭＦは、例えば、精度の高い時刻を持つ基地局の時刻を用いると判断してもよい。このことにより、例えば、ＵＥ間において高精度の時刻同期が可能となる。
【０１９１】
他の例として、基地局からＵＥに対して送信されるデータに、どちらの基地局からのタイミングリファレンスを用いる時刻であるかを示す情報が含まれないとしてもよい。ＵＥは、基地局との通信経路に関する情報、例えば、使用ベアラに関する情報を用いて、該データがどちらの時刻と対応付けされるかを決めてもよい。
【０１９２】
ＵＥにおける時刻補正方法に関する他の例として、ＵＥは自ＵＥ時刻の不確定性を拡大してもよい。例えば、ＵＥは、マスタ基地局からのタイミングリファレンスを用いて導出した時刻と、セカンダリ基地局からのタイミングリファレンスを用いて導出した時刻とを含む範囲を、自ＵＥ時刻の不確定性として用いてもよい。ＵＥは、自ＵＥ時刻を、前述の両時刻の間に在る値、例えば、両時刻の中央値に設定してもよい。このことにより、例えば、通信システムにおける設計の複雑性を回避可能となる。
【０１９３】
他の解決策を開示する。ＵＥは基地局に対し、時刻の補正を要求してもよい。該基地局は、マスタ基地局であってもよいし、セカンダリ基地局であってもよい。ＵＥからセカンダリ基地局に対して時刻補正要求を送信する場合、ＵＥがセカンダリ基地局に直接、要求を送信してもよいし、マスタ基地局経由でセカンダリ基地局に要求を送信してもよい。該基地局は、該要求を用いて、自基地局の時刻を補正してもよい。
【０１９４】
ＵＥは、各基地局からのタイミングリファレンスの情報を用いて、時刻補正対象の基地局を決定してもよい。補正対象の基地局の決定において、例えば、精度が低い基地局を補正対象としてもよい。このことにより、例えば、精度が高い基地局に合わせて時刻同期が可能となり、その結果、通信システムにおけるＵＥ間の同期を高精度で実施可能となる。補正対象基地局の決定に関する他の例として、精度が高い基地局を補正対象としてもよい。
【０１９５】
基地局の時刻補正における他の例として、ＵＥは上位ＮＷ装置に対し、基地局の時刻の補正要求を通知してもよい。上位ＮＷ装置は、例えば、ＡＭＦであってもよい。ＵＥから上位ＮＷ装置への該通知には、例えば、ＮＡＳシグナリングが用いられてもよい。上位ＮＷ装置は、該要求を該基地局に通知してもよい。該基地局は、該通知を用いて、自基地局の時刻を補正してもよい。
【０１９６】
他の例として、基地局は上位ＮＷに対し、自基地局の時刻に関する情報を通知してもよい。上位ＮＷ装置は、例えば、ＡＭＦであってもよい。上位ＮＷ装置は、該情報を用いて、基地局に対して時刻の補正要求を通知してもよい。該基地局は、該通知を用いて、自基地局の時刻を補正してもよい。
【０１９７】
該要求は、時刻補正の要求であることを示す情報を含んでもよいし、時刻補正対象の基地局に関する情報を含んでもよいし、時刻補正量に関する情報を含んでもよい。時刻補正対象の基地局に関する情報は、例えば、マスタ基地局であるかセカンダリ基地局であるかを示す識別子であってもよい。時刻補正量に関する情報は、例えば、所定の時間単位の補正量として与えられてもよい。基地局は、該要求に含まれる情報を用いて、自身の時刻を補正してもよい。基地局は該ＵＥに対し、該補正が完了したことを示す情報を通知してもよい。該完了の情報の通知は、他方の基地局経由で行われてもよいし、上位ＮＷ装置経由で行われてもよい。
【０１９８】
基地局間において時刻の補正が行われてもよい。該補正は、例えば、ＵＥからの要求を用いて行われてもよい。
【０１９９】
時刻補正対象の基地局は、配下のＵＥに対し、補正後の時刻を用いたタイミングリファレンスを報知してもよいし、通知してもよい。配下の該ＵＥは、該タイミングリファレンスを用いて、自ＵＥ時刻の補正を行ってもよい。このことにより、例えば、通信システム内のＵＥ間における時刻同期が可能となる。
【０２００】
図１８は、基地局間における時刻の補正の動作の一例を示すシーケンス図である。図１８は、ＵＥがマスタ基地局（ＭＮ）に対し、セカンダリ基地局（ＳＮ）の時刻の補正を要求する例について示している。図１８は、ＭＮがＳＮに対し時刻の補正を要求する例について示している。図１８において、ＵＥは、ＭＮ、ＳＮからのＴＡを取得済みであるとする。
【０２０１】
図１８に示すステップＳＴ２００１において、ＭＮはＵＥに対しタイミングリファレンスを通知する。ＵＥは、ＭＮからのタイミングリファレンスを用いて、ＵＥ時刻（以下、ＭＮ参照のＵＥ時刻、と称する場合がある。）を導出する。ステップ２００２において、ＳＮはＵＥに対してタイミングリファレンスを通知する。ＵＥは、ＳＮからのタイミングリファレンスを用いて、ＵＥ時刻（以下、ＳＮ参照のＵＥ時刻、と称する場合がある。）を導出する。
【０２０２】
図１８に示すステップＳＴ２００３において、ＵＥは、ＭＮ参照のＵＥ時刻とＳＮ参照のＵＥ時刻を比較する。両方のＵＥ時刻の比較は、例えば、ＭＮ参照のＵＥ時刻およびその不確定性の範囲と、ＳＮ参照のＵＥ時刻およびその不確定性の範囲において、重複が存在するかどうかを用いて行われてもよい。例えば、該重複が存在する場合において、ＵＥは、両方のＵＥ時刻が一致すると判断してもよい。
【０２０３】
図１８に示すステップＳＴ２００３において両方のＵＥ時刻が一致する場合、ＵＥは、ステップ２００４において、ステップＳＴ２００１およびステップＳＴ２００２にて示される、両基地局のタイミングリファレンスを受信する動作に戻る。ステップＳＴ２００３において両方のＵＥ時刻が異なる場合、ＵＥは、ステップＳＴ２００５において、ＭＮに対して、ＳＮ時刻の補正要求を送信する。該要求は、補正対象がＳＮであることを示す情報を含んでもよいし、時刻の補正量に関する情報を含んでもよい。ＵＥは、該補正量を、両ＵＥ時刻の差分を用いて導出してもよい。
【０２０４】
図１８に示すステップＳＴ２００６において、ＭＮはＳＮに対し、時刻の補正を要求する。該要求は、ＳＮ時刻の補正量に関する情報を含んでもよい。該情報は、ステップＳＴ２００５にてＭＮがＵＥより取得した補正量であってもよい。ステップＳＴ２００７において、ＳＮは、ステップＳＴ２００６において取得した時刻補正量に関する情報を用いて、自基地局の時刻を補正する。
【０２０５】
図１８に示すステップＳＴ２００８において、ＳＮはＭＮに対し、自基地局の時刻補正の完了通知を行う。ステップＳＴ２００９において、ＭＮはＵＥに対し、ＳＮ時刻の補正要求に対する肯定応答を通知する。ステップＳＴ２００９の通知は、ＳＮ時刻の補正完了を示す通知であってもよい。
【０２０６】
図１８に示すステップＳＴ２０１０、ステップＳＴ２０１１は、ステップＳＴ２００１、ＳＴ２００２と同様である。ステップＳＴ２０１１において、ＳＮは、補正後の時刻を用いてタイミングリファレンスを通知する。ＵＥは、ステップＳＴ２０１０、ステップＳＴ２０１１で取得したタイミングリファレンスを用いて、それぞれ、ＭＮ参照のＵＥ時刻、ＳＮ参照のＵＥ時刻を導出する。
【０２０７】
他の解決策を開示する。ＵＥは、マスタ基地局からのタイミングリファレンスを用いて求めた自ＵＥ時刻および該時刻の不確定性の範囲が、セカンダリ基地局からのタイミングリファレンスを用いて求めた自ＵＥ時刻および該時刻の不確定性の範囲と互いに重なる範囲において、自ＵＥの時刻を設定してもよい。ＵＥは、例えば、自ＵＥ時刻を、重なる該範囲の中央値に設定してもよいし、重なる該範囲を含む範囲を自ＵＥ時刻の不確定性の範囲と定めてもよい。このことにより、例えば、ＵＥは、２つの基地局からのタイミングリファレンスを用いて自ＵＥ時刻の精度を向上可能となる。
【０２０８】
実施の形態１の本変形例１において開示した基地局の時刻補正の方法を、ハンドオーバについて適用してもよい。このことにより、例えば、基地局間における時刻同期が実現可能となる。
【０２０９】
ハンドオーバ時における基地局の時刻補正の例として、移動元の基地局の時刻が補正されるとしてもよい。ＵＥは、移動先基地局に対し、移動元基地局の時刻補正を要求してもよい。ＵＥから移動先基地局への該要求の通知は、ＵＥが移動先基地局のタイミングリファレンスおよびＴＡを取得した後に行うとしてもよい。ＵＥにおける自ＵＥ時刻の補正は、移動先基地局に対する該要求の通知の前に行ってもよいし、該通知後に行ってもよいし、該通知と同時に行ってもよい。移動先基地局は移動元基地局に対し、時刻の補正を要求してもよい。ＵＥから移動先基地局への該要求、移動先基地局から移動元基地局への該要求に含まれる情報は、前述において開示した情報と同様としてもよい。移動元基地局は、移動先基地局からの該要求を用いて、自基地局の時刻を補正してもよい。
【０２１０】
他の例として、移動先の基地局の時刻が補正されるとしてもよい。ＵＥは、移動先基地局に対し、時刻補正を要求してもよい。ＵＥから移動先基地局への該要求の通知は、ＵＥが移動先基地局のタイミングリファレンスおよびＴＡを取得した後に行うとしてもよい。ＵＥから移動先基地局への該要求に含まれる情報は、前述において開示した情報と同様としてもよい。移動先基地局は、ＵＥからの該要求を用いて、自基地局の時刻を補正してもよい。ＵＥは、補正後の移動先基地局からのタイミングリファレンスおよびＴＡを用いて、自ＵＥ時刻の補正を行うとしてもよい。
【０２１１】
ハンドオーバ時に移動元基地局、移動先基地局の時刻のどちらを補正するかについて、ＵＥが決定してもよい。例えば、時刻の精度が低い基地局の時刻を補正するとしてもよい。他の例として、移動元基地局あるいは移動先基地局が決定してもよい。
【０２１２】
ハンドオーバ時における基地局の時刻補正について、上位ＮＷ装置が基地局に指示するとしてもよい。ＵＥは、各基地局からの時刻補正に関する情報を、上位ＮＷ装置に通知してもよい。該通知には、例えば、ＮＡＳシグナリングが用いられてもよい。上位ＮＷ装置から基地局への指示を用いた該基地局の時刻補正の方法は、前述のＤＣにおいて上位ＮＷ装置を用いた時刻補正の方法と同様としてもよい。
【０２１３】
他の例として、ＵＥは、移動先の基地局からのタイミングリファレンスと移動元基地局からのタイミングリファレンスの両方を用いて、自ＵＥ時刻を決めてもよい。例えば、ＵＥは、移動先基地局からのタイミングリファレンスを用いて求めた自ＵＥ時刻および該時刻の不確定性の範囲が、移動先基地局からのタイミングリファレンスを用いて求めた自ＵＥ時刻および該時刻の不確定性の範囲と重なる範囲において、自ＵＥ時刻を決めてもよい。このことにより、例えば、ＵＥにおける時刻精度を向上可能となる。
【０２１４】
実施の形態１の本変形例１において開示した基地局の時刻補正の方法を、ＵＥの周辺基地局の時刻補正に適用してもよい。該基地局は、ＵＥと接続がされていない基地局であってもよい。前述の方法の該適用は、該周辺基地局と、ＵＥが接続中の基地局との間におけるフレームタイミングの差分が、通信システムにおけるいずれかの装置において既知である場合に適用されるとしてもよい。
【０２１５】
ＵＥは、該周辺基地局のタイミングリファレンスを取得してもよい。ＵＥが取得する該タイミングリファレンスは、該周辺基地局から報知されるものであってもよい。ＵＥは、該周辺基地局のＴＡを、該周辺基地局のフレームタイミングを用いて推定してもよい。該推定は、実施の形態１において開示した方法であってもよい。ＵＥは、該周辺基地局の時刻補正を、ＵＥが接続中の基地局に対して要求してもよい。該要求には、ＲＲＣシグナリングが用いられてもよいし、ＭＡＣシグナリングが用いられてもよいし、Ｌ１／Ｌ２シグナリングが用いられてもよい。ＵＥが接続中の該基地局は、該周辺基地局に対し、時刻補正を要求してもよい。ＵＥから、接続中の基地局に対する要求に含まれる情報、ＵＥが接続中の該基地局から、該周辺基地局に対する要求に含まれる情報は、実施の形態１の本変形例１において開示した情報とそれぞれ同様であってもよい。該周辺基地局は、ＵＥが接続中の該基地局からの該要求を用いて、自基地局の時刻を補正してもよい。
【０２１６】
周辺基地局の時刻補正においても、ハンドオーバ時における基地局の時刻補正と同様、上位ＮＷ装置が基地局に指示するとしてもよい。
【０２１７】
他の例として、ＵＥは、接続先の基地局からのタイミングリファレンスおよび周辺基地局からのタイミングリファレンスを用いて、自ＵＥ時刻を決めてもよい。例えば、ＵＥは、接続先基地局からのタイミングリファレンスを用いて求めた自ＵＥ時刻および該時刻の不確定性の範囲が、周辺基地局からのタイミングリファレンスを用いて求めた自ＵＥ時刻および該時刻の不確定性の範囲と重なる範囲において、自ＵＥ時刻を決めてもよい。前述において、周辺基地局は１つであってもよいし、複数であってもよい。このことにより、例えば、ＵＥにおける時刻精度を向上可能となる。
【０２１８】
本実施の形態１の変形例１における方法が、ＵＥの、通信装置間の移動において適用されてもよい。例えば、ＵＥが複数のＤＵからタイミングリファレンスを受信した場合において、ＵＥは、タイミングリファレンスの精度が高いＤＵからのタイミングリファレンスを用いて自ＵＥ時刻を決定してもよいし、ＵＥは、両方のＤＵからのタイミングリファレンスを用いて求めた自ＵＥ時刻およびその不確定性の範囲が重複する範囲において、自ＵＥ時刻および不確定性の範囲を決定してもよい。このことにより、例えば、ＵＥ時刻の精度を向上可能となる。
【０２１９】
他の例として、ハンドオーバ直前のＵＥは、接続可能なＤＵのうち、タイミングリファレンスの有効期間が長いＤＵを用いて、移動元基地局と通信を行ってもよい。このことにより、例えば、該ＵＥのハンドオーバ中における自ＵＥ時刻の精度悪化を防止可能となる。
【０２２０】
実施の形態１の本変形例１により、ＵＥが時刻同期する基地局が明確になり、その結果、通信システムにおける誤動作を防止可能となる。また、ＤＣにおいて、基地局間の時刻の誤差を補正可能となり、その結果、通信システムにおいて時刻同期可能なＵＥの数を増加可能となる。
【０２２１】
実施の形態１の変形例２．
ＮＲにおいては、ビームフォーミングが用いられるため、ｇＮＢから配下のＵＥへのタイミングリファレンス通知を、複数のビーム方向に対して行う必要がある。そのため、基地局からＵＥへのタイミングリファレンスの送信に時間を要する。その結果、例えばＵＥにおけるクロック精度が低い場合において、ＵＥ時刻の誤差が増大する恐れがある。
【０２２２】
前述の問題を解決する方法を開示する。
【０２２３】
タイミングリファレンスの有効期間を設ける。該有効期間は、ＵＥにおいて設けられてもよい。該有効期間は、予め規格によって定められてもよい。該有効期間は、例えば、固定の値でもよいし、ＵＥのクロック精度を用いて決められてもよい。該有効期間に関する情報が、ＵＥケーパビリティに含まれてもよい。該情報は、例えば、該有効期間であってもよいし、ＵＥにクロック精度に関する情報であってもよい。
【０２２４】
該有効期間に関するタイマが設けられてもよい。該タイマが、基地局に設けられてもよい。ＵＥは、該有効期間に関する情報を基地局に通知してもよい。該通知は、例えば、ＵＥケーパビリティの通知であってもよい。基地局は、該通知を用いて、該ＵＥにおけるタイミングリファレンスの有効期間におけるタイマを設定してもよい。該タイマは、基地局からＵＥに対するタイミングリファレンスの報知あるいは通知によって初期化され、起動するとしてもよい。基地局は、該タイマの満了時においてタイミングリファレンスをＵＥに通知するとしてもよい。このことにより、例えば、ＵＥ時刻の誤差増大を防止可能となる。
【０２２５】
該有効期間に関するタイマが、ＵＥに設けられてもよい。ＵＥは、基地局から報知あるいは通知されるタイミングリファレンスの受信によって該タイマを初期化し、起動するとしてもよい。ＵＥは、該タイマの満了時において、基地局に対してタイミングリファレンスの要求を行うとしてもよい。該要求は、ＲＲＣシグナリングで行われてもよいし、ＭＡＣシグナリングで行われてもよいし、Ｌ１／Ｌ２シグナリングで行われてもよい。基地局は、該要求を用いて、ＵＥに対してタイミングリファレンスを通知してもよい。このことにより、例えば、ＵＥ時刻の誤差増大を防止可能となる。
【０２２６】
他の解決策を開示する。ＵＥは、周期的に報知されるタイミングリファレンスを常に取得するとしてもよい。基地局はＵＥに対して、タイミングリファレンスの報知周期を予め報知あるいは通知してもよい。このことにより、例えば、ＵＥ時刻の誤差増大を防止可能となる。
【０２２７】
他の例として、ＵＥは、周期的に報知されるタイミングリファレンスを、一部の報知周期において取得するとしてもよい。例えば、ＵＥは、該タイミングリファレンスを、複数周期毎に取得するとしてもよい。前述の周期数は、例えば、ＵＥにおけるクロック精度を用いて決められてもよい。このことにより、例えば、ＵＥにおいて一部のタイミングリファレンス報知に対する受信動作が不要となり、その結果、ＵＥにおける消費電力を削減可能となる。
【０２２８】
ＵＥは、タイミングリファレンスの個別通知の要否に関する情報を、基地局に通知してもよい。ＵＥは、例えば、周期的に報知されるタイミングリファレンスの受信のみで時刻精度を十分保持可能な場合において、タイミングリファレンスの個別通知が不要である旨を基地局に通知してもよい。該情報は、例えば、ＵＥケーパビリティに含まれてもよい。基地局は、該情報を用いて、該ＵＥに対してタイミングリファレンスを個別に通知しないとしてもよい。このことにより、例えば、通信システムにおける効率を向上可能となる。
【０２２９】
実施の形態１の本変形例２におけるタイマが、有効期間および／あるいはＴＡにおいて適用されてもよい。ＴＡの有効期間および／あるいはタイマは、非特許文献１７（３ＧＰＰ  ＴＳ  ３８．３２１  Ｖ１５．２．０）に記載のtimeAlignmentTimerとは異なるタイマとして設けられてもよい。該有効期間および／あるいはタイマは、前述のtimeAlignmentTimerよりも短い値としてもよい。ＴＡのタイマの設定方法、動作についても、タイミングリファレンスのタイマと同様としてもよい。例えば、基地局は、ＴＡにおける該タイマ満了時において、ＵＥに対してＴＡを通知してもよい。ＵＥは、該ＴＡを用いて、自ＵＥ時刻を補正してもよい。他の例として、該タイマの値が、ＵＥの移動速度を用いて決められてもよい。該移動速度は、例えば、セル半径方向の移動速度であってもよい。このことにより、例えば、基地局はＵＥ移動によって発生するＴＡ変化を迅速に把握可能となり、その結果、ＵＥ時刻の精度を維持可能となる。
【０２３０】
基地局は、ＵＥの移動速度を、上りＲＳを用いて取得してもよい。例えば、上りＲＳのドップラーシフト量を用いて、ＵＥの移動速度を導出してもよい。該上りＲＳは、例えば、ＤＭＲＳであってもよいし、ＳＲＳであってもよいし、ＰＴＲＳであってもよい。他の例として、ポジショニング用のＲＳであってもよい。
【０２３１】
タイミングリファレンスのタイマとＴＡのタイマが両方用いられるとしてもよい。このことにより、例えば、ＵＥ時刻の精度をさらに向上可能となる。
【０２３２】
実施の形態１の本変形例２により、ＵＥのクロック誤差によって発生する時刻誤差の増大を防止可能となる。
【０２３３】
実施の形態２．
ＴＳＮにおけるＵプレインデータおよび／あるいはＣプレインデータの通信において、レイテンシを一定としてもよい。
【０２３４】
ところが、ハンドオーバ等のモビリティが発生する場合において、モビリティ発生時および発生前後においてレイテンシが変動するという問題が生じる。また、基地局における周波数リソースおよび／あるいは時間リソース等の逼迫により、基地局とＵＥとの間の通信におけるレイテンシが変動するといった問題が生じる。
【０２３５】
前述の問題を解決する方法を開示する。
【０２３６】
ＵＥは複数のＰＤＵセッションを用いて通信を行う。複数の該ＰＤＵセッションは、マスタ基地局を通る経路とセカンダリ基地局を通る経路にそれぞれ設けられてもよい。複数の該ＰＤＵセッションは、１つのネットワークスライシングに対して設定されてもよい。ＵＥは、モビリティが発生しない基地局を通るＰＤＵセッションにおいてデータの送受信を行う。データの送受信が行われるＰＤＵセッションが、複数の該ＰＤＵセッションの間で切替わってもよい。
【０２３７】
例えば、マスタ基地局の切替えが行われる場合において、ＵＥは上りデータ送信経路を、セカンダリ基地局を通る経路に切替えてもよい。ＵＰＦは下りデータ送信経路を、セカンダリ基地局を通る経路に切替えてもよい。
【０２３８】
他の例として、セカンダリ基地局の切替えが行われる場合において、ＵＥは上りデータ送信経路を、マスタ基地局を通る経路に切替えてもよい。ＵＰＦは下りデータ送信経路を、マスタ基地局を通る経路に切替えてもよい。
【０２３９】
マスタ基地局はＵＥに対し、上りデータ送信経路の切替えを指示してもよい。該マスタ基地局は、マスタ基地局の切替えが行われる場合においては、移動元マスタ基地局であってもよい。該指示は、どちらの基地局を通る経路を用いるかを示す情報を含んでもよいし、経路の切替えの対象となるデータに関する情報を含んでもよい。経路の切替えの対象となるデータに関する情報は、例えば、ＱｏＳフローに関する情報であってもよいし、ベアラに関する情報であってもよいし、ＰＤＵセッションに関する情報であってもよい。ＵＥは、該指示を用いて、上りデータ送信に用いる経路を切替えてもよい。このことにより、例えば、送信経路の切替えが必要なデータについてのみ送信経路を切替え可能となり、その結果、切替え先の送信経路における輻輳を防止可能となる。
【０２４０】
ＵＥはマスタ基地局に対し、該指示に対する応答を送信してもよい。このことにより、例えば、ＵＥとマスタ基地局との間で、上りデータ通信経路に関する齟齬を防止可能となり、その結果、通信システムにおける誤動作を防止可能となる。
【０２４１】
ＵＥは、該切替え指示後において、下りデータを、該切替え前の基地局から受信してもよいし、切替え後の基地局から受信してもよい。このことにより、例えば、ＵＰＦにおける下りデータ送信経路の切替え前後における下りデータの欠落を防止可能となる。
【０２４２】
マスタ基地局からＵＥに対する該指示は、ＲＲＣシグナリングであってもよい。例えば、該指示が、ＲＲＣ再設定（RRCReconfiguration）のシグナリングに含まれてもよい。このことにより、例えば、通信システムにおける設計の複雑性を回避可能となる。他の例として、該指示は、ＭＡＣシグナリングであってもよい。例えば、該経路の切替え用のＭＡＣ  ＣＥが設けられてもよい。このことにより、例えば、マスタ基地局はＵＥに対し、上りデータ送信経路の切替えを迅速に通知可能となる。他の例として、該指示は、Ｌ１／Ｌ２シグナリングであってもよい。このことにより、例えば、マスタ基地局はＵＥに対し、該切替えをさらに迅速に通知可能となる。
【０２４３】
ＵＥからマスタ基地局に対する該応答は、ＲＲＣシグナリングであってもよいし、ＭＡＣシグナリングであってもよいし、Ｌ１／Ｌ２シグナリングであってもよい。例えば、該応答が、ＲＲＣ再設定完了（RRCReconfigurationComplete）のシグナリングであってもよいし、該指示を含むＭＡＣ  ＣＥに対するＨＡＲＱ応答であってもよいし、他のシグナリングであってもよい。
【０２４４】
マスタ基地局はＡＭＦに対し、ＵＰＦにおける下りデータ送信経路の切替えを指示してもよい。該マスタ基地局は、マスタ基地局の切替えが行われる場合においては、移動元マスタ基地局であってもよい。ＡＭＦはＵＰＦに対し、該指示を転送してもよい。ＡＭＦからＵＰＦに対する該指示の転送は、ＳＭＦ経由で行われてもよい。該指示は、どちらの基地局を通る経路を用いるかを示す情報を含んでもよいし、経路の切替えの対象となるデータに関する情報を含んでもよい。経路の切替えの対象となるデータに関する情報は、例えば、ＱｏＳフローに関する情報であってもよいし、ＰＤＵセッションに関する情報であってもよい。ＵＰＦは、該指示を用いて、下りデータ送信に用いる経路を切替えてもよい。このことにより、例えば、送信経路の切替えが必要なデータについてのみ送信経路を切替え可能となり、その結果、切替え先の送信経路における輻輳を防止可能となる。
【０２４５】
ＵＰＦはＡＭＦに対し、該指示に対する応答を送信してもよい。該応答の送信は、ＳＭＦを経由して行われてもよい。ＡＭＦは該マスタ基地局に対し、該応答を転送してもよい。このことにより、例えば、上位ＮＷ装置とマスタ基地局との間で、上りデータ通信経路に関する齟齬を防止可能となり、その結果、通信システムにおける誤動作を防止可能となる。
【０２４６】
ＵＰＦは、該切替え指示後において、上りデータを、切替え前の基地局から受信してもよいし、切替え後の基地局から受信してもよい。このことにより、例えば、ＵＥにおける上りデータ送信経路の切替え前後における上りデータの欠落を防止可能となる。
【０２４７】
マスタ基地局からＡＭＦに対する該指示は、ＮＧインタフェースにおけるシグナリングであってもよい。該指示を送信するシグナリングは、既存のシグナリングであってもよいし、新たに設けられてもよい。ＡＭＦからＵＰＦに対する該指示の転送についても、同様としてもよい。ＵＰＦからＡＭＦに対する該指示の応答についても、同様としてもよい。ＡＭＦからＵＥに対する該応答の転送についても、同様としてもよい。
【０２４８】
ＰＤＵセッションに、アクティブ／デアクティブの状態が設けられてもよい。前述の、通信経路の切替えにおいて、ＰＤＵセッションのアクティブ化、デアクティブ化が用いられてもよい。ＵＥおよび／あるいはＵＰＦは、データの送信を、アクティブなＰＤＵセッションを用いて行うとしてもよい。ＵＥおよび／あるいはＵＰＦは、データの受信を、アクティブなＰＤＵセッションにおいて行うとしてもよいし、デアクティブなＰＤＵセッションにおいても可能としてもよい。このことにより、例えば、前述と同様の効果が得られる。
【０２４９】
前述の複数のＰＤＵセッションにおいて、ＵＰＦとＵＥとの間のレイテンシを同じとするとよい。このことにより、例えば、データ送信に用いられるＰＤＵセッションの切替え前後におけるデータ送受信のレイテンシを一定に保持可能となる。
【０２５０】
ＵＥとＵＰＦとの間のデータ送受信において、送信側装置は、送信データの送信時刻に関する情報を通知してもよいし、受信側装置が受信すべき時刻に関する情報を通知してもよい。送信側装置は、ＵＥであってもよいし、ＵＰＦであってもよい。受信側装置は、ＵＰＦであってもよいし、ＵＥであってもよい。受信すべき該時刻は、例えば、受信側装置が上位レイヤにデータを転送すべき時刻であってもよい。該時刻は、例えば、ミリ秒単位の時刻であってもよいし、サブフレーム番号を用いた時刻であってもよいし、スロット番号を用いた時刻であってもよいし、ミニスロット番号を用いた時刻であってもよいし、シンボル番号を用いた時刻であってもよいし、前述のうち複数を組み合わせた時刻であってもよい。送信側装置は、例えば、該送信データにタイムスタンプを付与してもよい。該タイムスタンプは、前述の時刻と同様の情報であってもよい。該タイムスタンプは、上位レイヤにおいて付与されてもよいし、ＳＤＡＰにおいて付与されてもよいし、ＰＤＣＰにおいて付与されてもよいし、ＲＬＣにおいて付与されてもよいし、ＭＡＣにおいて付与されてもよい。他の例として、該送信時刻に関する情報が、ＮＡＳシグナリングを用いて通知されてもよいし、ＲＲＣシグナリングを用いて通知されてもよいし、ＭＡＣシグナリングを用いて通知されてもよいし、Ｌ１／Ｌ２シグナリングを用いて通知されてもよい。受信側装置は、該送信時刻に関する情報を用いて、該タイミングを導出してもよい。受信側装置は、受信データにおける該タイムスタンプを除去してもよい。前述の方法は、ＵＥとＵＰＦとの間における複数のＰＤＵセッションに対して適用するとしてもよい。このことにより、例えば、ＵＥとＵＰＦとの間のデータ送受信におけるレイテンシを、複数のＰＤＵセッションの間で同じとすることが可能となる。
【０２５１】
ＡＭＦは、ＵＰＦおよび／あるいはＵＥに対して、ＵＰＦとＵＥとの間のレイテンシに関する情報を通知してもよい。該情報は、例えば、ＵＰＦとＵＥとの間の通信に求められるレイテンシであってもよい。該通知には、例えば、ＮＧインタフェース上のシグナリングが用いられてもよいし、ＮＡＳシグナリングが用いられてもよい。ＵＰＦおよび／あるいはＵＥは、該情報を用いて、ＵＰＦとＵＥとの間のレイテンシを取得してもよい。
【０２５２】
ＵＥとＵＰＦとの間のデータ送受信における、送信側装置からの送信データの送信時刻に関する情報、および／あるいは受信側装置が受信すべき時刻に関する情報の通知が、周期的なデータ送受信において適用されてもよい。例えば、受信側装置が受信すべき該時刻に関する情報が、周期と、オフセット、すなわち、受信側装置が受信すべき時刻の１つ、との組み合わせであってもよい。該データ送受信が周期的なデータ送受信であることを示す情報が含まれてもよい。ＵＥおよび／あるいはＵＰＦは、該情報を用いて、受信データを上位レイヤに転送してもよい。このことにより、例えば、周期的なデータ送受信においてもレイテンシを一定に維持可能となる。
【０２５３】
図１９および図２０は、本実施の形態２において、データ送信に用いられるＰＤＵセッションの切替えおよびＵＥが接続する基地局の切替えの動作を示すシーケンス図である。図１９と図２０とは、境界線ＢＬ１９２０の位置で、つながっている。図１９および図２０は、ＵＥとＵＰＦとの間でＵプレインデータの送受信が行われる例を示している。図１９および図２０に示す例では、データ送信に用いられるＰＤＵセッションが、移動元マスタ基地局（移動元ＭＮ）を通るＰＤＵセッションから、セカンダリ基地局を通るＰＤＵセッションに切替わり、ＵＥが接続するマスタ基地局が移動元ＭＮから移動先ＭＮに切替わる。
【０２５４】
図１９に示すステップＳＴ２５００、ＳＴ２５０１において、ＵＥとＵＰＦとの間で、移動元ＭＮ経由でデータの送受信が行われる。ステップＳＴ２５００はＵＰＦと移動元ＭＮとの間のデータ送受信を示し、ステップＳＴ２５０１は移動元ＭＮとＵＥとの間のデータ送受信を示す。
【０２５５】
図１９に示すステップＳＴ２５０２において、移動元ＭＮは、自基地局から移動先ＭＮへのマスタ基地局切替えを行うことを決定する。ステップＳＴ２５０２において、移動元ＭＮは、セカンダリ基地局の切替えを行わないことを決定してもよい。
【０２５６】
図１９に示すステップＳＴ２５０５において、移動元ＭＮはＡＭＦに対し、ＵＥとＵＰＦとの間の下りＵプレインデータ送信に用いるＰＤＵセッションを、自基地局経由のＰＤＵセッションから移動元ＳＮ経由のＰＤＵセッションに切替えることを要求する。ステップＳＴ２５０８において、ＡＭＦはＵＰＦに対し該切替えの要求を通知するとともに、ＵＰＦはＡＭＦに対し該切替えの完了通知を行う。該要求の通知および該完了の通知は、ＳＭＦ経由で行われるとしてもよい。ＵＰＦは、該要求の通知を用いて、下りＵプレインデータ送信に用いるＰＤＵセッションを、移動元ＭＮを経由するＰＤＵセッションから移動元ＳＮを経由するＰＤＵセッションに切替える。
【０２５７】
図１９に示すステップＳＴ２５１０およびＳＴ２５１１において、ＵＰＦは移動元ＳＮ経由でＵＥに対し下りＵプレインデータの送信を行う。ステップＳＴ２５１０はＵＰＦから移動元ＳＮへのデータ送信を示し、ステップＳＴ２５１１は移動元ＳＮからＵＥへのデータ送信を示す。ステップＳＴ２５１２およびＳＴ２５１３において、ＵＥは移動元ＭＮ経由でＵＰＦに対し上りＵプレインデータの送信を行う。ステップＳＴ２５１２はＵＥから移動元ＭＮへのデータ送信を示し、ステップＳＴ２５１３は移動元ＭＮからＵＰＦへのデータ送信を示す。
【０２５８】
図１９に示すステップＳＴ２５１４において、ＡＭＦは移動元ＭＮに対し、ステップＳＴ２５０５のＰＤＵセッション切替え要求に対する肯定応答を送信する。該肯定応答の送信は、ステップＳＴ２５０８においてＵＰＦからＡＭＦに対して通知された該切替え完了通知を用いて行われてもよい。
【０２５９】
図１９に示すステップＳＴ２５１５において、移動元ＭＮはＵＥに対して、該ＵＥとＵＰＦとの間の上りＵプレインデータ送信に用いるＰＤＵセッションを、自基地局経由のＰＤＵセッションから移動元ＳＮ経由のＰＤＵセッションに切替えることを指示する。該指示は、例えば、ＲＲＣ再設定（RRCReconfiguration）のシグナリングに含まれてもよい。ＵＥは、該指示を用いて、上りＵプレインデータの送信に用いるＰＤＵセッションを、移動元ＭＮを経由するＰＤＵセッションから移動元ＳＮを経由するＰＤＵセッションに切替える。
【０２６０】
図１９に示すステップＳＴ２５２０、ＳＴ２５２１において、ＵＥとＵＰＦとの間で、移動元ＳＮ経由でデータの送受信が行われる。ステップＳＴ２５２０はＵＰＦと移動元ＳＮとの間のデータ送受信を示し、ステップＳＴ２５２１は移動元ＳＮとＵＥとの間のデータ送受信を示す。
【０２６１】
図１９に示すステップＳＴ２５２２において、ＵＥは移動元ＭＮに対して、ステップＳＴ２５１５の該切替え指示に対する応答を通知する。該応答の通知には、ＲＲＣ再設定完了（RRCReconfigurationComplete）のシグナリングが用いられてもよい。
【０２６２】
図１９に示すステップＳＴ２５２３において、移動元ＭＮは移動先ＭＮに対して、ハンドオーバ要求（Handover Request）を通知する。該通知において、セカンダリ基地局の切替えを行わないことを示す情報が含まれてもよい。ステップＳＴ２５２４において、移動先ＭＮは該ハンドオーバに対する許可制御（Admission Control）を行う。
【０２６３】
図２０に示すステップＳＴ２５２５において、移動先ＭＮは移動元ＳＮに対して、セカンダリ基地局追加要求（Secondary Node Addition Request）を行う。ステップＳＴ２５２６において、移動元ＳＮは移動先ＭＮに対して、セカンダリ基地局追加要求肯定応答（Secondary Node Addition Request Acknowledge）を通知する。
【０２６４】
図２０に示すステップＳＴ２５２７において、移動先ＭＮは移動元ＭＮに対して、ステップＳＴ２５２３のハンドオーバ要求に対する肯定応答（Handover Request Acknowledge）を行う。
【０２６５】
図２０に示すステップＳＴ２５２８において、移動元ＭＮは移動元ＳＮに対して、セカンダリ基地局解放要求（Secondary Node Release Request）を行う。該要求通知後において、ＵＥとＵＰＦとの間の、移動元ＳＮを経由したデータ送受信が継続されていてもよい。移動元ＭＮは、該要求に、移動元ＳＮを経由したデータ送受信を継続することを示す情報を含めてもよい。
【０２６６】
図２０に示すステップＳＴ２５３０およびＳＴ２５３１は、それぞれ、ステップＳＴ２５２０およびＳＴ２５２１と同じである。
【０２６７】
図２０に示すステップＳＴ２５３３において、移動元ＳＮは移動元ＭＮに対して、セカンダリ基地局解放要求に対する肯定応答（Secondary Node Release Request Acknowledge）を通知する。
【０２６８】
図２０に示すステップＳＴ２５３５において、移動元ＭＮはＵＥに対して、自基地局から移動先ＭＮへのハンドオーバを指示する。該指示は、例えば、ＲＲＣ再設定（RRCReconfiguration）のシグナリングに含まれてもよい。該指示に、セカンダリ基地局が変わらないことを示す情報が含まれてもよい。ＵＥは、該指示を用いて、セカンダリ基地局を移動元ＳＮから変更せずに、移動元ＭＮから移動先ＭＮへのハンドオーバを行う。ステップＳＴ２５３７において、ＵＥと移動先ＭＮとの間でランダムアクセス処理が行われる。ステップＳＴ２５３８において、ＵＥは移動先ＭＮに対し、ハンドオーバの完了を通知する。該通知には、例えば、ＲＲＣ再設定完了（RRCReconfigurationComplete）のシグナリングが用いられてもよい。ステップＳＴ２５３９において、移動先ＭＮは移動元ＳＮに対し、セカンダリ基地局再設定完了（Secondary Node Reconfiguration Complete）を通知する。
【０２６９】
図２０に示すステップＳＴ２５４０およびＳＴ２５４１は、それぞれ、ステップＳＴ２５２０およびＳＴ２５２１と同じである。
【０２７０】
図２０に示すステップＳＴ２５４２において、移動先ＭＮはＡＭＦに対し、ＵＥとＵＰＦとの間における、移動元ＭＮ経由のＰＤＵセッションについて、移動元ＭＮ経由から移動先ＭＮに経路を切替える要求を通知する。該要求の通知は、例えば、ＰＤＵセッションパス切替え要求（PDU session path switch request）のシグナリングを用いて行われてもよい。ステップＳＴ２５４５において、ＡＭＦはＵＰＦに対し該切替えの要求を通知するとともに、ＵＰＦはＡＭＦに対し該切替えの完了通知を行う。該要求の通知および該完了の通知は、ＳＭＦ経由で行われるとしてもよい。ＵＰＦは、該要求の通知を用いて、ＵＥとＵＰＦとの間における、移動元ＭＮ経由のＰＤＵセッションについて、移動元ＭＮ経由から移動先ＭＮに経路を切替える。
【０２７１】
図２０に示すステップＳＴ２５４７において、ＡＭＦは移動先ＭＮに対し、ステップＳＴ２５４２のＰＤＵセッションパス切替え要求に対する肯定応答を送信する。該肯定応答の送信は、ステップＳＴ２５４５においてＵＰＦからＡＭＦに対して通知された該切替え完了通知を用いて行われてもよい。
【０２７２】
図２０に示すステップＳＴ２５４８において、移動先ＭＮは移動元ＭＮに対して、ＵＥコンテキストの解放を指示する。該指示は、例えば、ＵＥコンテキスト解放（UE context release）のシグナリングを用いて行われるとしてもよい。
【０２７３】
図２０に示すステップＳＴ２５５０およびＳＴ２５５１は、それぞれ、ステップＳＴ２５２０およびＳＴ２５２１と同じである。
【０２７４】
図１９および図２０において、ステップＳＴ２５０５〜ＳＴ２５１４に示す下りデータ送信用ＰＤＵセッション切替えが、ステップＳＴ２５１５〜ＳＴ２５２２に示す上りデータ送信用ＰＤＵセッション切替えの前に行われる例について開示した。これに対し、該下りデータ送信用ＰＤＵセッション切替えが、該上りデータ送信用ＰＤＵセッション切替えの後に行われてもよい。他の例として、該上りデータ送信用ＰＤＵセッション切替えが、該下りデータ送信用ＰＤＵセッション切替えの途中で行われるとしてもよい。例えば、ステップＳＴ２５１５が、ステップＳＴ２５０５〜ＳＴ２５１４の間に行われてもよい。他の例として、該下りデータ送信用ＰＤＵセッション切替えが、該上りデータ送信用ＰＤＵセッション切替えの途中で行われるとしてもよい。例えば、ステップＳＴ２５０５が、ステップＳＴ２５１５〜ＳＴ２５２２の間に行われてもよい。このことにより、例えば、通信システムにおける柔軟性を向上可能となる。
【０２７５】
図１９および図２０において、Ｕプレインデータの送受信の経路の切替えについて示したが、Ｃプレインにおいても送受信経路の切替えが行われてもよい。Ｃプレインにおける送受信経路切替えにおいて、ＵＥとＡＭＦとの間でＣプレインデータの送受信が行われるとしてもよい。このことにより、例えば、Ｃプレインデータにおいても、基地局の切替わりに伴うレイテンシの変動を防止可能となる。
【０２７６】
図２１および図２２は、本実施の形態２において、データ送信に用いられるＰＤＵセッションの切替えおよびＵＥが接続する基地局の切替えの動作の他の例を示すシーケンス図である。図２１と図２２とは、境界線ＢＬ２１２２の位置で、つながっている。図２１および図２２は、ＵＥとＵＰＦとの間でＵプレインデータの送受信が行われる例を示している。図２１および図２２に示す例では、データ送信に用いられるＰＤＵセッションが、移動元セカンダリ基地局（移動元ＳＮ）を通るＰＤＵセッションから、移動先マスタ基地局を通るＰＤＵセッションに切替わり、ＵＥが接続するセカンダリ基地局が移動元ＳＮから移動先ＳＮに切替わる。ここでは、図２１および図２２に示す動作が、図１９および図２０に示す動作に続いて行われる例を説明する。図２１および図２２において、図１９および図２０と同様の処理には同じステップ番号を付し、共通する説明を省略する。
【０２７７】
図２１に示すステップＳＴ２６００、ＳＴ２６０１において、ＵＥとＵＰＦとの間で、移動元ＳＮ経由でデータの送受信が行われる。ステップＳＴ２６００はＵＰＦと移動元ＳＮとの間のデータ送受信を示し、ＳＴ２６０１は移動元ＳＮとＵＥとの間のデータ送受信を示す。
【０２７８】
図２１に示すステップＳＴ２６０２において、移動先ＭＮは、セカンダリ基地局を移動元ＳＮから移動先ＳＮに切替えることを決定する。
【０２７９】
図２１に示すステップＳＴ２６０５において、移動先ＭＮはＡＭＦに対し、ＵＥとＵＰＦとの間の下りＵプレインデータ送信に用いるＰＤＵセッションを、移動元ＳＮ経由のＰＤＵセッションから自基地局経由のＰＤＵセッションに切替えることを要求する。ステップＳＴ２５０８は、図１９と同様である。ＵＰＦは、該要求の通知を用いて、下りＵプレインデータ送信に用いるＰＤＵセッションを、移動元ＳＮを経由するＰＤＵセッションから移動先ＭＮを経由するＰＤＵセッションに切替える。
【０２８０】
図２１に示すステップＳＴ２６１０およびＳＴ２６１１において、ＵＰＦは移動先ＭＮ経由でＵＥに対し下りＵプレインデータの送信を行う。ステップＳＴ２６１０はＵＰＦから移動先ＭＮへのデータ送信を示し、ステップＳＴ２６１１は移動先ＭＮからＵＥへのデータ送信を示す。ステップＳＴ２６１２およびＳＴ２６１３において、ＵＥは移動元ＳＮ経由でＵＰＦに対し上りＵプレインデータの送信を行う。ステップＳＴ２６１３はＵＥから移動元ＳＮへのデータ送信を示し、ステップＳＴ２６１３は移動元ＳＮからＵＰＦへのデータ送信を示す。
【０２８１】
図２１に示すステップＳＴ２６１４において、ＡＭＦは移動先ＭＮに対し、ステップＳＴ２６０５のＰＤＵセッション切替え要求に対する肯定応答を送信する。該肯定応答の送信は、ステップＳＴ２５０８においてＵＰＦからＡＭＦに対して通知された該切替え完了通知を用いて行われてもよい。
【０２８２】
図２１に示すステップＳＴ２６１５において、移動先ＭＮはＵＥに対して、該ＵＥとＵＰＦとの間の上りＵプレインデータ送信に用いるＰＤＵセッションを、移動元ＳＮ経由のＰＤＵセッションから自基地局経由のＰＤＵセッションに切替えることを指示する。該指示は、例えば、ＲＲＣ再設定（RRCReconfiguration）のシグナリングに含まれてもよい。ＵＥは、該指示を用いて、上りＵプレインデータの送信に用いるＰＤＵセッションを、移動元ＳＮを経由するＰＤＵセッションから移動先ＭＮを経由するＰＤＵセッションに切替える。
【０２８３】
図２１に示すステップＳＴ２６２０、ＳＴ２６２１において、ＵＥとＵＰＦとの間で、移動先ＭＮ経由でデータの送受信が行われる。ステップＳＴ２６２０はＵＰＦと移動先ＭＮとの間のデータ送受信を示し、ステップＳＴ２６２１は移動先ＭＮとＵＥとの間のデータ送受信を示す。
【０２８４】
図２１に示すステップＳＴ２６２２において、ＵＥは移動先ＭＮに対して、ステップＳＴ２６１５の該切替え指示に対する応答を通知する。該応答の通知には、ＲＲＣ再設定完了（RRCReconfigurationComplete）のシグナリングが用いられてもよい。
【０２８５】
図２２に示すステップＳＴ２６２５において、移動先ＭＮは移動先ＳＮに対して、セカンダリ基地局追加要求（Secondary Node Addition Request）を行う。ステップＳＴ２６２６において、移動先ＳＮは移動先ＭＮに対して、セカンダリ基地局追加要求肯定応答（Secondary Node Addition Request Acknowledge）を通知する。
【０２８６】
図２２に示すステップＳＴ２６２８において、移動先ＭＮは移動元ＳＮに対して、セカンダリ基地局解放要求（Secondary Node Release Request）を行う。ステップＳＴ２６３３において、移動元ＳＮは移動先ＭＮに対して、セカンダリ基地局解放要求に対する肯定応答（Secondary Node Release Request Acknowledge）を通知する。
【０２８７】
図２２に示すステップＳＴ２６３５において、移動先ＭＮはＵＥに対して、セカンダリ基地局の、移動元ＳＮから移動先ＳＮへの切替えを指示する。該指示は、例えば、ＲＲＣ再設定（RRCReconfiguration）のシグナリングに含まれてもよい。ＵＥは、該指示を用いて、セカンダリ基地局を移動元ＳＮから移動先ＳＮに変更してもよい。ステップＳＴ２６３６において、ＵＥは移動先ＭＮに対し、ＳＮ基地局切替えの完了を通知する。該通知には、例えば、ＲＲＣ再設定完了（RRCReconfigurationComplete）のシグナリングが用いられてもよい。ステップＳＴ２６３８において、移動先ＭＮは移動先ＳＮに対し、セカンダリ基地局再設定完了（Secondary Node Reconfiguration Complete）を通知する。ステップＳＴ２６３９において、ＵＥと移動先ＳＮとの間でランダムアクセス処理が行われる。
【０２８８】
図２２に示すステップＳＴ２６４０およびＳＴ２６４１は、それぞれ、ステップＳＴ２６２０およびＳＴ２６２１と同じである。
【０２８９】
図２２に示すステップＳＴ２６４２において、移動先ＭＮはＡＭＦに対し、ＵＥとＵＰＦとの間における、移動元ＳＮ経由のＰＤＵセッションについて、移動元ＳＮ経由から移動先ＳＮへの経路の切替えを通知する。該通知は、例えば、ＰＤＵセッションリソース変更要求（PDU session resource modify indication）のシグナリングを用いて行われてもよい。ステップＳＴ２６４５において、ＡＭＦはＵＰＦに対し該切替え通知を転送するとともに、ＵＰＦはＡＭＦに対し該切替えの完了通知を行う。該切替えの通知および該完了の通知は、ＳＭＦ経由で行われるとしてもよい。ＵＰＦは、該切替えの通知を用いて、ＵＥとＵＰＦとの間における、移動元ＳＮ経由のＰＤＵセッションについて、移動元ＳＮ経由から移動先ＳＮに経路を切替える。
【０２９０】
図２２に示すステップＳＴ２６４７において、ＡＭＦは移動先ＭＮに対し、ステップＳＴ２６４２のＰＤＵセッションリソース変更通知に対する確認応答を送信する。該確認応答の送信は、ステップＳＴ２６４５においてＵＰＦからＡＭＦに対して通知された該切替え完了通知を用いて行われてもよい。
【０２９１】
図２２に示すステップＳＴ２６４８において、移動先ＭＮは移動元ＳＮに対して、ＵＥコンテキストの解放を指示する。該指示は、例えば、ＵＥコンテキスト解放（UE context release）のシグナリングを用いて行われるとしてもよい。
【０２９２】
図２２に示すステップＳＴ２６５０およびＳＴ２６５１は、それぞれ、ステップＳＴ２６２０およびＳＴ２６２１と同じである。
【０２９３】
図２１および図２２においても、図１９および図２０と同様、ステップＳＴ２６０５〜ＳＴ２６１４に示す下りデータ送信用ＰＤＵセッション切替えが、ステップＳＴ２６１５〜ＳＴ２６２２に示す上りデータ送信用ＰＤＵセッション切替えの後に行われてもよいし、途中で行われてもよい。また、ステップＳＴ２６１５〜ＳＴ２６２２に示す上りデータ送信用ＰＤＵセッション切替えが、ステップＳＴ２６０５〜ＳＴ２６１４に示す下りデータ送信用ＰＤＵセッション切替えの途中で行われてもよい。このことにより、例えば、通信システムにおける柔軟性を向上可能となる。
【０２９４】
図２１および図２２において、図１９および図２０と同様、Ｃプレインにおいても送受信経路の切替えが行われてもよい。Ｃプレインにおける送受信経路切替えにおいて、ＵＥとＡＭＦとの間でＣプレインデータの送受信が行われるとしてもよいし、ＵＥとＳＭＦとの間でＣプレインデータの送受信が行われるとしてもよい。このことにより、例えば、Ｃプレインデータにおいても、基地局の切替わりに伴うレイテンシの変動を防止可能となる。
【０２９５】
図１９および図２０に示す動作と図２１および図２２に示す動作が交互に行われてもよい。このことにより、例えば、ＵＥが移動し続ける場合においても、ＵＥと上位ＮＷ装置との間におけるデータ送受信のレイテンシを一定に維持可能となる。
【０２９６】
ＵＥが複数のＰＤＵセッションを用いて通信を行う方法において、複数のＵＰＦが用いられてもよい。例えば、異なるＰＤＵセッションのそれぞれが、異なるＵＰＦを通るものであってもよい。複数のＵＰＦが用いられる通信において、非特許文献３０（３ＧＰＰ  ＴＳ２３．５０１  Ｖ１５．３．０）におけるデータネットワーク（Data Network；ＤＮ）上の装置は、該複数のＵＰＦを用いてＵＥとデータ送受信を行うとしてもよい。マスタ基地局はＡＭＦに対して、下りデータ送信経路の切替えを要求してもよい。ＡＭＦはＤＮ上の該装置に対して、該要求を転送してもよい。該転送は、ＳＭＦを経由して行われてもよい。ＤＮ上の該装置は、転送された該要求を用いて、下りデータ送信に用いるＰＤＵセッションを切替えてもよい。マスタ基地局はＵＥに対し、上りデータ送信に用いるＰＤＵセッションの切替えを指示してもよい。マスタ基地局からＵＥに対する該指示は、前述と同様であってもよい。このことにより、例えば、複数のＵＰＦが用いられる通信においても、前述と同様の効果が得られる。
【０２９７】
他の解決策を開示する。レイテンシ要件を満たさない基地局へのハンドオーバを行わないとする。移動元基地局から移動先基地局に対し、レイテンシ要件を通知する。移動先基地局は、該レイテンシ要件を用いて、ハンドオーバの受諾／拒否を決定する。
【０２９８】
レイテンシ要件に関する情報が、移動元基地局から移動先基地局に対して通知されるハンドオーバ要求のシグナリングに含まれてもよい。該情報は、ＵＥが用いるＱｏＳフロー毎に設定されてもよいし、ＵＥが用いるベアラ毎に設定されてもよい。移動先基地局は、該情報を用いて、ＱｏＳフロー毎および／あるいはベアラ毎にハンドオーバの受諾／拒否を決定してもよい。移動先基地局には、ハンドオーバを受諾するＱｏＳフローおよび／あるいはベアラを通知してもよい。
【０２９９】
５Ｇシステム内において、時刻の同期が行われてもよい。例えば、上位ＮＷ装置と基地局との間で時刻同期が行われてもよい。
【０３００】
上位ＮＷ装置は基地局に対し、タイムスタンプを通知してもよい。基地局は上位ＮＷ装置に対して、タイムスタンプを通知してもよい。上位ＮＷ装置は、自装置が送信したタイムスタンプおよび基地局が自装置に送信したタイムスタンプを用いて、自装置から基地局に対する伝送遅延を導出してもよい。上位ＮＷ装置は基地局に対して、該伝送遅延を通知してもよい。基地局は、該伝送遅延を用いて、自基地局の時刻を補正してもよい。
【０３０１】
基地局間で時刻の同期が行われてもよい。基地局間の同期において、前述の、上位ＮＷ装置と基地局との間の時刻同期の方法が適用されてもよいし、実施の形態１の変形例１において開示された方法が適用されてもよい。
【０３０２】
本実施の形態２により、モビリティ発生時においても、通信のレイテンシを一定に維持可能となる。
【０３０３】
実施の形態３．
基地局は、ＵＥに対して送信する下りデータを保持してもよい。保持された該下りデータ（以下、ローカルキャッシュデータと称する場合がある）は、ＵＰＦから基地局に対して送信されてもよい。基地局は、該ローカルキャッシュデータをＵＥに対して送信してもよい。
【０３０４】
ところが、該ＵＥにおいて基地局間ハンドオーバが発生した場合、移動先の基地局はローカルキャッシュデータを保持していない。そのため、ＵＥにおける該データの受信についてレイテンシが増大するといった問題が生じる。
【０３０５】
前述の問題に対する解決法を開示する。
【０３０６】
移動先基地局においても、ローカルキャッシュデータを保持する。該ローカルキャッシュデータが、移動元基地局から送信されるとしてもよい。
【０３０７】
移動元基地局から移動先基地局への該ローカルキャッシュデータの送信は、移動元基地局から移動先基地局に対するハンドオーバ要求送信と同時に行われてもよいし、該ハンドオーバ要求送信の後に行われてもよい。このことにより、例えば、移動先基地局は該ローカルキャッシュデータを迅速に取得可能となる。
【０３０８】
他の例として、移動元基地局から移動先基地局への該ローカルキャッシュデータの送信は、例えば、移動先基地局から移動元基地局に対するハンドオーバ要求肯定応答の後に行われてもよい。このことにより、例えば、移動先基地局がハンドオーバ要求を拒否した場合において、再度選択した移動先基地局へローカルキャッシュデータを送信不要となる。その結果、通信システムにおける効率を向上可能となる。
【０３０９】
他の例として、ＵＰＦが移動先基地局にローカルキャッシュデータを送信してもよい。移動先基地局はＵＰＦに対し、ローカルキャッシュデータの移動先基地局への送信を要求してもよい。このことにより、例えば、基地局間インタフェースの負荷を低減可能となる。
【０３１０】
移動元基地局は、ローカルキャッシュデータを解放してもよい。例えば、移動元基地局がハンドオーバ要求肯定応答を受信した後において該解放の動作を行ってもよい。このことにより、例えば、移動元基地局における使用メモリ量を削減可能となる。
【０３１１】
他の解決策を開示する。複数の基地局が、ローカルキャッシュデータを保持する。複数の該基地局は、例えば、移動元基地局と同じＲＡＮ通知エリア（RAN Notification Area；ＲＮＡ）の基地局であってもよいし、移動元基地局と同じトラッキングエリアの基地局であってもよい。他の例として、ローカルキャッシュデータを保持する基地局を、移動元基地局が決定してもよいし、上位ＮＷ装置が決定してもよい。移動元基地局あるいは上位絵ＮＷ装置は、ローカルキャッシュデータを保持する基地局を、例えば、ＵＥの位置情報を用いて決定してもよい。複数の該基地局によるローカルキャッシュデータ保持は、例えば、ハンドオーバ開始前から行われていてもよい。このことにより、例えば、ハンドオーバ処理時における通信システム上の輻輳を防止可能となる。
【０３１２】
移動元基地局は移動先基地局に対し、ローカルキャッシュデータのうちどのデータから後（あるいはどのデータ以降）をＵＥに送信すべきかを示す情報を通知してもよい。ローカルキャッシュデータにおいて、シーケンス番号が設けられてもよい。該シーケンス番号は、ＰＤＣＰ  ＳＮとは別に設けられるとしてもよい。該シーケンス番号は、例えば、パケット毎に与えられてもよい。該情報は、該シーケンス番号を含んでもよいし、ＰＤＣＰ  ＳＮを含んでもよいし、該シーケンス番号とＰＤＣＰ  ＳＮを組み合わせた情報を含んでもよい。このことにより、例えば、ハンドオーバ後におけるローカルキャッシュデータの重複や欠落を防止可能となる。
【０３１３】
ＵＥは、ローカルキャッシュデータにおいて受信を開始したいデータに関する情報を、基地局に対して通知してもよい。該情報は、該シーケンス番号を含んでもよいし、ＰＤＣＰ  ＳＮを含んでもよいし、該シーケンス番号とＰＤＣＰ  ＳＮを組み合わせた情報を含んでもよい。ＵＥから基地局に対する該通知は、例えば、ＵＥへのデータ通信再開時において行われてもよいし、基地局からＵＥへのデータ通信における早送りおよび／あるいは巻戻しにおいて用いられてもよいし、ＵＥのハンドオーバ時において行われてもよい。ＵＥへのデータ通信再開とは、例えば、ＵＥがＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤに復帰する場合であってもよい。ＵＥは、ＲＲＣ＿ＩＮＡＣＴＩＶＥへの遷移時において、該シーケンス番号を保持してもよいし、ＰＤＣＰ  ＳＮを保持してもよいし、該シーケンス番号とＰＤＣＰ  ＳＮを組み合わせた情報を保持してもよい。このことにより、例えば、基地局からＵＥへのローカルキャッシュデータ送信における柔軟性を向上可能となる。
【０３１４】
ローカルキャッシュデータのシーケンス番号に関する他の例として、該シーケンス番号とＰＤＣＰ  ＳＮとの間に対応付けが行われてもよい。例えば、該シーケンス番号が、ＰＤＣＰ  ＳＮに対し所定のオフセットを加算あるいは減算した値として求められてもよい。前述において、ローカルキャッシュの１つのパケットから１つのＰＤＣＰ  ＰＤＵが生成されるとしてもよい。このことにより、例えば、通信システムにおける複雑性を回避可能となる。
【０３１５】
移動元基地局は、移動先基地局に対し、該オフセットの値に関する情報と、次にＰＤＣＰ  ＰＤＵを生成すべきＰＤＣＰ  ＳＮに関する情報を組み合わせて通知してもよい。このことにより、例えば、基地局間通信におけるシグナリングのサイズを削減可能となる。
【０３１６】
ＵＥは、基地局に対し、ローカルキャッシュデータにおいて受信を開始したいデータにおけるＰＤＣＰ  ＳＮのみを通知してもよい。基地局は、該オフセットの値に関する情報と、該ＰＤＣＰ  ＳＮを用いて、受信を開始したいデータの、ローカルキャッシュデータにおけるシーケンス番号を導出してもよい。他の例として、ＵＥは基地局に対し、受信を開始したいデータにおけるローカルキャッシュデータのシーケンス番号を通知してもよい。基地局は、該シーケンス番号と該オフセットの値に関する情報を用いて、ローカルキャッシュデータにおいて受信を開始したいデータにおけるＰＤＣＰ  ＳＮを導出してもよい。前述の通知は、ＰＤＣＰ制御ＰＤＵを用いて行われてもよいし、ＲＲＣシグナリングを用いて行われてもよい。このことにより、例えば、ＵＥと基地局との間におけるシグナリング量を削減可能となる。
【０３１７】
ローカルキャッシュデータのシーケンス番号に関する他の例として、ＴＣＰのシーケンス番号が用いられてもよい。前述の、移動元基地局から移動先基地局に対する通知に、ＴＣＰシーケンス番号が含まれてもよい。移動元基地局は、ローカルキャッシュデータにおけるＴＣＰシーケンス番号とＰＤＣＰ  ＳＮとの組み合わせに関する情報を保持してもよい。前述の、ＵＥから基地局に対する該通知に、ＴＣＰシーケンス番号が含まれてもよい。このことにより、例えば、通信システムにおいて新たな番号を設けることが不要となり、その結果、通信システムにおける複雑性を回避可能となる。
【０３１８】
本実施の形態３におけるローカルキャッシュデータが、ＵＥから基地局に対して送信する上り通信に対して適用されてもよい。該ローカルキャッシュは、例えば、ＵＥから基地局経由で他のＵＥに対して送信するユーザデータについて用いられるものであってもよい。また、該ローカルキャッシュは、例えば、ＵＥから、該ＵＥのアプリケーションのレイヤにおける対向までの通信速度が大きい場合（例えば、通信距離が大きい、ＵＥと該対向との間に存在するルーティング装置の数が多い）において、基地局において該ＵＥとの通信プロトコル（例えば、ＴＣＰ）を終端するために用いられるものであってもよい。
【０３１９】
上り通信におけるローカルキャッシュデータが、移動元基地局から移動先基地局に対して転送されてもよい。該ローカルキャッシュデータが、複数の基地局において保持されてもよい。
【０３２０】
移動元基地局はＵＥに対し、該ローカルキャッシュデータのうちどのデータから後（あるいはどのデータ以降）をＵＥに送信すべきかを示す情報を通知してもよい。ローカルキャッシュデータにおいて、シーケンス番号が設けられてもよい。該シーケンス番号は、ＰＤＣＰ  ＳＮとは別に設けられるとしてもよい。該シーケンス番号は、例えば、パケット毎に与えられてもよい。ＵＥは、該情報を用いて、移動先基地局に対して上り送信を開始するデータを決定してもよい。このことにより、例えば、上り通信においても、データの重複送信や欠落を防止可能となる。
【０３２１】
本実施の形態３により、ハンドオーバが発生する状況においても、ＵＥは下りおよび／あるいは上り通信のレイテンシを削減可能となる。また、ＵＥは、該下りおよび／あるいは上り通信における信頼性を確保可能となる。
【０３２２】
実施の形態４．
３ＧＰＰにおいて、Ｄ２Ｄ（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）のサポートが検討されている（非特許文献２８（３ＧＰＰ  ＲＰ−１８２１１１）参照）。
【０３３４】
ユニキャスト通信やグループキャスト通信では、ＨＡＲＱのフィードバック（Ａｃｋ／Ｎａｃｋ）、ＣＳＩ報告等のサポートが検討されている。
【０３３５】
ＮＲのＳＬ通信では低遅延特性が要求されている。低遅延特性の要求を満たすため、ＮＲのＳＬ通信において、プリエンプションの導入が提案されている（非特許文献２２（３ＧＰＰ  Ｒ１−１８１０５９３）、非特許文献２７（Ｒ１−１８１０７７５））。プリエンプションは、既に行われているＵＥへのデータ送信を、低遅延特性が要求される他のＵＥへの送信でプリエンプト（pre-empt）する技術である（非特許文献１６（ＴＳ３８．３００））。
【０３３６】
ＳＬにおいては、送信ＵＥは複数のサービスのデータを送信する場合があり、各サービスで受信ＵＥは異なる場合がある。このような場合、プリエンプトされる通信のリソースを受信するＵＥと、プリエンプトする通信のリソースを受信するＵＥとが異なることになる。送信ＵＥは、これらの受信ＵＥに対して、プリエンプトされたこと、プリエンプトすることを各々通知する必要がある。これらの通知に関する方法については未だ開示されていない。
【０３３７】
このようにＳＬにおいてプリエンプションの具体的方法は未だ開示されていない。このため、プリエンプションを実施できないが故に低遅延特性の要求を満たせなくなる、という問題が生じる。本実施の形態４では、このような課題を解決する方法を開示する。
【０３３８】
通常のＳＬの通信では、送信を行うＵＥ（送信ＵＥ）は、ＰＳＳＣＨのリソースアロケーション情報などのスケジューリング情報や、通信ターゲットとなるＵＥ（受信ＵＥ）などを、ＳＬ制御情報（ＳＣＩ）に含めて、ＰＳＣＣＨで送信する。また、送信ＵＥはスケジューリング情報に従ってＰＳＳＣＨを送信する。受信ＵＥは、ＰＳＣＣＨを受信することで、自ＵＥ向けのデータであることを認識し、スケジューリング情報に従って、ＰＳＳＣＨを受信し、データを取得する。
【０３３９】
プリエンプションについて開示する。送信ＵＥは、プリエンプションを示す情報（PI：Preemption Indication）を、ＰＳＣＣＨで送信する。送信ＵＥは、プリエンプションを示す情報を、ＳＣＩに含ませてＰＳＣＣＨで送信してもよい。送信ＵＥは、プリエンプトする通信のリソースアロケーション情報と、プリエンプションを示す情報とを、ＰＳＣＣＨで送信してもよい。送信ＵＥは、プリエンプトする通信のリソースアロケーション情報と、プリエンプションを示す情報とを、ＳＣＩに含ませてＰＳＣＣＨで送信してもよい。送信ＵＥは該情報を、プリエンプトする通信のＰＳＣＣＨで送信してもよい。前述のプリエンプトする通信のリソースアロケーション情報の代わりに、プリエンプトする通信のスケジューリング情報が用いられてもよい。送信ＵＥは、プリエンプトする通信のスケジューリング情報と、プリエンプションを示す情報とを、ＳＣＩに含ませてＰＳＣＣＨで送信してもよい。
【０３４０】
ＳＬにおいて、ＳＬ通信を行う全てのＵＥは、設定されたリソースプールのＰＳＣＣＨを受信可能である。プリエンプトする通信における受信ＵＥと、プリエンプトされる通信における受信ＵＥとの両方が、ＰＳＣＣＨを受信可能となる。このため、プリエンプトする通信における受信ＵＥはリソースアロケーション情報を受信可能となり、プリエンプトされる通信における受信ＵＥはプリエンプションを示す情報を受信可能となる。
【０３４１】
ＳＣＩを２つに分けてもよい。たとえば、ＳＣＩ１、ＳＣＩ２とする。各々のＳＣＩを送信するための２つの異なるチャネルを設けてもよい。たとえば、ＰＳＣＣＨ１、ＰＳＣＣＨ２とする。一方のＰＳＣＣＨ、たとえばＰＳＣＣＨ１は、従来のＰＳＣＣＨと同様にリソースプールが設定された全ＵＥが受信可能とする。他方のＰＳＣＣＨ、例えばＰＳＣＣＨ２は、従来のＰＳＣＣＨとは異なり、一つのＵＥあるいはＵＥグループのみが受信可能とする。
【０３４２】
リソースプールが設定された全ＵＥが受信可能なＰＳＣＣＨ１のＳＣＩ１に、プリエンプションを示す情報を含めてもよい。リソースプールが設定された全ＵＥが受信可能なＰＳＣＣＨ１のＳＣＩ１に、プリエンプトする通信のリソースアロケーション情報と、プリエンプションを示す情報とを含めてもよい。その他の情報をＳＣＩ２に含めてもよい。このようにすることで、プリエンプトする通信における受信ＵＥと、プリエンプトされる通信における受信ＵＥとの両方が、ＰＳＣＣＨ１のＳＣＩ１を受信可能となる。
【０３４３】
プリエンプトされる通信の受信ＵＥは、ＰＳＣＣＨを受信し、ＳＣＩにＰＩが含まれるか否かを判断する。ＰＩが含まれない場合、受信ＵＥは、プリエンプトされていないと判断する。ＰＩが含まれている場合、受信ＵＥは、プリエンプトされていると判断する。プリエンプトされる通信の受信ＵＥは、プリエンプトされていると判断した場合、ＰＳＣＣＨでアロケーションされるリソースを受信しない。
【０３４４】
ＰＩに、プリエンプトされるリソースのアロケーション情報を含めてもよい。このような場合、プリエンプトされる通信の受信ＵＥは、プリエンプトされていると判断すると、ＰＩに含まれるリソースアロケーション情報によってアロケーションされるリソースを受信しない。このようにすることで、プリエンプトされる通信の受信ＵＥは、プリエンプトされたリソースで送信された、他の受信ＵＥへのＰＳＳＣＨを、受信しないようにできる。
【０３４５】
プリエンプトする通信の受信ＵＥは、ＰＳＣＣＨを受信し、ＳＣＩにターゲットＵＥとして自ＵＥの識別子が含まれるか否かを判断する。自ＵＥの識別子が含まれない場合、受信ＵＥは、自ＵＥに対して送信されたデータでは無いと判断して、ＰＳＳＣＨを受信しない。自ＵＥの識別子が含まれる場合受信ＵＥは、自ＵＥに対して送信されたデータであると判断して、ＳＣＩに含まれるスケジューリング情報を用いてＰＳＳＣＨを受信する。このようにすることで、プリエンプトする通信の受信ＵＥは、プリエンプトしたリソースで送信されたＰＳＳＣＨを受信可能となる。
【０３４６】
プリエンプトされる通信のリソースは、リザベーションされたリソースであってもよいし、実際にデータがアロケーションされたリソースであってもよい。リザベーションされたリソースをプリエンプトした場合も前述に開示した方法を適用できる。
【０３４７】
ＰＩに含まれる情報として以下に５つの具体例を開示する。
（１）プリエンプションを示す情報。
（２）プリエンプトされるリソースの情報。
（３）プリエンプトされた場合の受信処理を示す情報。
（４）プリエンプトされる通信の受信ＵＥに関する情報。
（５）（１）から（４）の組合せ。
【０３４８】
前述の（１）について、プリエンプションを示す情報は、プリエンプトされているか否かを示す情報であってもよいし、プリエンプトされていることを示す情報であってもよい。
【０３４９】
前述の（２）について、プリエンプトされるリソースの情報は、リソースのアロケーション情報であってもよい。リソースの情報は時間−周波数情報であってもよい。たとえば、スロット番号、スロット数、ＰＲＢ番号、ＰＲＢ数などがある。時間単位として、ＴＴＩ，スロット、ミニスロット、シンボル、１／ｎシンボル（ｎは正の整数）、ＣＢＧ（Code Block Group）などがある。周波数単位として、ＰＲＢ、サブキャリアなどがある。
【０３５０】
プリエンプトされるリソースの情報は、時間情報だけにしてもよい。この場合、周波数リソースは、既にアロケーションあるいはリザベーションされた周波数リソースと同じとしてもよい。このようにすることで、プリエンプトされるリソースの情報を削減可能となる。
【０３５１】
ＳＬにおけるＲＳを、プリエンプトされるリソースの対象外としてもよい。たとえば、ＤＭＲＳを対象外にしてもよい。たとえば、シンボル単位でプリエンプションを行う場合、ＤＭＲＳを除いたシンボルを、プリエンプトするリソースの対象とするとよい。プリエンプトされた通信の受信ＵＥが、ＤＭＲＳを用いることで、プリエンプトされたリソースを含むスロットにマッピングされたデータを復調できる可能性を向上させることができる。
【０３５２】
前述の（３）について、プリエンプトされた場合の受信処理は、プリエンプトされたリソースのみ受信しない処理であってもよいし、あるいは、プリエンプトされたリソースを含む所定のリソースを受信しない処理であってもよい。所定のリソースは、たとえばスロットなどである。あるいは、所定のリソースは、複数の連続するスロットであってもよい。他の例として、プリエンプトされた場合の受信処理は、一部のリソースがプリエンプトされたデータを全て受信しない処理であってもよい。このようにすることで、受信処理を簡易にすることができる。ここで記載した受信処理はデータ復調処理であってもよい。
【０３５３】
前述の（４）について、プリエンプトされる通信の受信ＵＥに関する情報は、該受信ＵＥを特定するための情報とするとよい。たとえば、該情報はＵＥの識別子であってもよい。プリエンプトされる受信ＵＥを明示的に示すことができ、誤動作の発生を低減させることができる。
【０３５４】
ＰＩを含めるＰＳＣＣＨは、プリエンプトされるリソースのリソースアロケーションを実施するスロット/ミニスロットのＰＳＣＣＨとしてもよい。このようにすることで、プリエンプトされるリソース上でＰＳＣＣＨが送信される場合に、ＰＳＣＣＨでＰＩを通知可能となる。あるいは、ＰＩを含めるＰＳＣＣＨは、プリエンプトされるリソースのリソースアロケーションを実施するスロットの次のＰＳＣＣＨとしてもよい。このようにすることで、プリエンプトされるリソース上でＰＳＣＣＨが送信されない場合にも、ＰＳＣＣＨでＰＩを通知可能となる。
【０３５５】
送信ＵＥは、プリエンプトする通信の受信ＵＥに関する情報を、ＰＳＣＣＨで送信してもよい。送信ＵＥは、プリエンプトする通信の受信ＵＥに関する情報を、プリエンプトする通信のリソースアロケーション情報を含むスケジューリング情報とＰＩとともに、ＳＣＩに含ませて、ＰＳＣＣＨで送信してもよい。プリエンプトする通信の受信ＵＥに関する情報は、該受信ＵＥを特定するための情報とするとよい。該情報は、たとえば、ＵＥの識別子であってもよい。
【０３５６】
プリエンプトする通信の受信ＵＥに関する情報をＰＳＣＣＨで送信する場合、ＰＩの送信を省略してもよい。送信ＵＥは、プリエンプトする通信の受信ＵＥに関する情報と、プリエンプトする通信のリソースアロケーション情報を含むスケジューリング情報とを、ＳＣＩに含ませて、ＰＳＣＣＨで送信する。
【０３５７】
プリエンプトされる通信の受信ＵＥは、ＰＳＳＣＨを受信し、プリエンプトする通信の受信ＵＥに関する情報から、他のＵＥ向けデータであることを認識可能となる。プリエンプトされる通信の受信ＵＥは、リソースアロケーション情報に示されたリソースの受信を行わないとすると良い。
【０３５８】
プリエンプトする通信の受信ＵＥは、ＰＳＣＣＨを受信し、プリエンプトする通信の受信ＵＥに関する情報から、自ＵＥ向けのスケジューリング情報であることを認識し、スケジューリング情報に従って、ＰＳＳＣＨを受信する。
【０３５９】
送信ＵＥは、プリエンプションを行う場合、プリエンプトされる通信の受信ＵＥに対して、プリエンプトされたリソースのみで送信しないとしてもよい。このようにすることで、プリエンプトされる通信の受信ＵＥに対して送信しないデータを最低限にすることが可能となる。他の方法として、送信ＵＥは、プリエンプトされる通信の受信ＵＥに対して、プリエンプトされたリソースを含む所定のリソースで送信しないとしてもよい。所定のリソースは、たとえば、一つまたは複数のＣＢＧ（Code Block Group）であってもよいし、一つまたは複数のスロットであってもよい。たとえば、複数スロットのスケジューリングがなされている場合は、送信ＵＥは、プリエンプトされる通信の受信ＵＥに対して、プリエンプトされたリソースを含む複数のスロットで送信しないとしてもよい。このようにすることで、送信ＵＥの処理を簡易にすることができる。
【０３６０】
送信ＵＥは、プリエンプトされる通信の受信ＵＥに対してスケジューリングを実施しているリソースの内、プリエンプトされたリソース外で送信を実施する場合、該プリエンプトされたリソース外のリソースに送信データをレートマッチングして送信してもよい。送信ＵＥはスケジューリングを実施しているリソースでデータを送信可能となる。レートマッチングに関する情報は、送信ＵＥから受信ＵＥに対して通知するとよい。前述のプリエンプトされた場合の受信処理を示す情報は、送信ＵＥから受信ＵＥに対して、ＰＩに含めて通知されてもよい。
【０３６１】
プリエンプションを行う場合、送信ＵＥにおけるプリエンプトされる通信の受信ＵＥに対する送信処理と、受信ＵＥにおけるプリエンプトされた場合の受信処理を適宜適切に対応づけておいてもよい。たとえば、送信ＵＥが、プリエンプションにおいて、プリエンプトされる通信の受信ＵＥに対して、プリエンプトされたリソースを含む一つのスロットを送信しないとする場合、受信ＵＥにおける受信処理は、プリエンプトされたリソースを含む一つのスロットを受信しない処理としてもよい。このようにした場合、送信ＵＥは、受信ＵＥに対して、前述のプリエンプトされた場合の受信処理を示す情報に代えて、送信ＵＥにおけるプリエンプトされる通信の受信ＵＥに対する送信処理方法を通知してもよい。
【０３６２】
このようにすることで、ＳＬにおけるプリエンプションを可能にする。このため、低遅延特性が要求されるＳＬ通信においてプリエンプションを実施することができ、通信に要求される低遅延特性を満足させることが可能となる。
【０３６３】
図２３は、ＳＬ通信におけるプリエンプションの概要を示す図である。図２３は、プリエンプトされる通信の送信ＵＥとプリエンプトする通信の送信ＵＥは同じであり、プリエンプトされる通信の受信ＵＥとプリエンプトする通信の受信ＵＥとが異なる場合について示している。ＵＥ１は送信ＵＥであり、ＵＥ２はプリエンプトされる通信の受信ＵＥであり、ＵＥ３はプリエンプトする通信の受信ＵＥであるものとする。ＵＥ１からＵＥ３への通信は、より低遅延特性が要求される通信とする。
【０３６４】
ＵＥ１からＵＥ２に対して、リソースのリザベーションが行われる。ここでは、リソースリザベーションが周期的に行われるものとする。図２３の例は、周期的に３スロットのリソースがリザベーションされることを示している。但し、一つのスロットがリザベーションされてもよいし、複数のスロットがリザベーションされてもよい。このように、ＵＥ１からＵＥ２へのリソースリザベーションが既に行われている状態で、ＵＥ１においてＵＥ３へのＳＬの送信がトリガされる。ＵＥ１は送信処理を行い、リソースを選択する。リソース選択は選択ウィンドウ（Selection Window）内で行われる。
【０３６５】
リソース選択ウィンドウの期間を短くすればするほど、送信までの時間が短くなり、低遅延特性が得られる。しかし、リソース選択ウィンドウの期間を短くした場合、選択可能なリソースは低減するので、リソースが既にリザベーションされている可能性が増大する。リザベーションされたリソースをプリエンプト可能とすることで、選択可能なリソースを増大させることができる。
【０３６６】
ＵＥ１は、低遅延特性が要求されるＵＥ３への通信のために、既にＵＥ２に対してリザベーションしているリソースをプリエンプトすることを決定する。ここでは、ＵＥ１は、送信処理後の２番目のスロットをプリエンプトする。ＵＥ１はＵＥ３に対して、プリエンプトしたリソースを用いて送信を行う。ＵＥ１はＵＥ２に対して、プリエンプトされたリソースで送信を行わないとしてもよい。ここでは、ＵＥ１はＵＥ２に対して２番目のスロットで送信を行わない。
【０３６７】
このように、ＵＥ１は、ＵＥ２に対して既にリザベーションしているリソースを、ＵＥ３に対してプリエンプトして送信する。このようにすることで、より低遅延特性が要求されるＵＥ３に対する通信を、低遅延で行うことが可能となる。
【０３６８】
図２４は、ＳＬ通信におけるプリエンプション方法の第１例を示す図である。図２４は、図２３と同様に、プリエンプトするリソースを含む３つのスロットを示している。各スロットにＰＳＣＣＨ、ＰＳＳＣＨ、ＧＡＰ、ＰＳＦＣＨがマッピングされる。ＰＳＣＣＨ、ＰＳＳＣＨは、送信ＵＥから送信される。ＧＡＰは無送信区間である。ＰＳＦＣＨはフィードバック用チャネルであり、ＨＡＲＱのフィードバック（Ａｃｋ、Ｎａｃｋ）、ＣＳＩ報告、ＳＲＳなどを含み、受信ＵＥから送信される。
【０３６９】
図２４は、ＵＥ１からＵＥ２に既に３スロットのリソースがリザベーションされている場合に、２番目のスロットがプリエンプトされる場合について示している。ＵＥ１においてＵＥ３へのＳＬの送信がトリガされ、ＵＥ１はＵＥ３への通信のために、送信処理後の２番目のスロットのリソースをプリエンプトすることを決定する。１番目と３番目のスロットは通常どおりＵＥ２に対して送信を行うため、ＵＥ１からＵＥ２に対してＰＳＣＣＨ、ＰＳＳＣＨが送信される。
【０３７０】
ＰＳＣＣＨにはＳＣＩがマッピングされる。ＳＣＩにスロット構成を含ませてもよい。たとえば、ＰＳＳＣＨ、ＧＡＰ、ＰＳＦＣＨがマッピングされるシンボル数やシンボル番号などの構成を、ＳＣＩに含ませてもよい。このようにすることで、受信ＵＥは送信ＵＥから送信されるスロットの構成を認識可能となる。
【０３７１】
ＵＥ１は、ＵＥ３に対する送信処理後の２番目のスロットを、ＵＥ３の通信用にプリエンプトする。２番目のスロットでは、ＵＥ２へのリソースがプリエンプトされることになる。プリエンプトした２番目のスロットで、ＵＥ１は、ＵＥ３に対するＰＳＣＣＨ、ＰＳＳＣＨを送信する。プリエンプトしたスロットは、ＧＡＰ、ＰＳＦＣＨがマッピングされるように構成されてもよい。ＵＥ１は、ＰＳＳＣＨのリソースアロケーション情報などのスケジューリング情報とＰＩとを、プリエンプトしたスロットのＰＳＣＣＨに含めて、送信する。
【０３７２】
ＰＳＳＣＨのリソースアロケーション情報などのスケジューリング情報をＳＣＩに含め、ＳＣＩとＰＩをＰＳＣＣＨで送信してもよい。ＰＳＳＣＨのリソースアロケーション情報などのスケジューリング情報と、ＰＩとを、ＳＣＩに含めて、ＰＳＣＣＨで送信してもよい。また、ＳＣＩにＵＥ３を特定するための情報を含ませてもよい。
【０３７３】
ＳＬ通信では、どの受信ＵＥもリソースプール内のＰＳＣＣＨを受信可能である。このため、ＵＥ２とＵＥ３の両方が２番目のスロットのＰＳＣＣＨを受信可能となる。ＵＥ２は、受信したＰＳＣＣＨにＰＩが含まれるか否かによって、リソースがプリエンプトされているか否かを判断可能となる。ＰＩが含まれていない場合は、ＵＥ２は、自ＵＥへのスケジューリングであると判断し、スケジューリング情報を用いてＰＳＳＣＨを受信する。ＰＩが含まれている場合は、ＵＥ２は、リソースがプリエンプトされていると判断し、ＰＳＣＣＨでアロケーションされるリソースを受信しない。
【０３７４】
このようにすることで、ＵＥ２が、他のＵＥにプリエンプトされたリソースを誤受信するのを避けることが可能となる。ＵＥ３は、２番目のスロットのＰＳＣＣＨを受信してＰＳＳＣＨが自ＵＥ宛であることを認識し、ＳＣＩに含まれるスケジューリング情報を用いてＰＳＳＣＨを受信することができる。
【０３７５】
このようなプリエンプション方法とすることで、ＳＬ通信においてプリエンプションを可能にする。低遅延特性が要求される通信のために、既にアロケーションあるいはリザベーションされたリソースをプリエンプトすることが可能となる。これにより低遅延特性の要求を満足させることが可能となる。
【０３７６】
ＵＥ１は、ＵＥ３用にプリエンプションを行う場合、ＵＥ２に対して、プリエンプトされたリソースのみ送信しないとしてもよい。このようにすることで、ＵＥ２に対して送信しないデータを最低限にすることが可能となる。他の方法として、ＵＥ１はＵＥ２に対して、プリエンプトされたリソースを含むスロットを送信しないとしてもよい。あるいは、複数スロットのスケジューリングがなされている場合は、ＵＥ１はＵＥ２に対して、プリエンプトされたリソースを含む複数のスロットを送信しないとしてもよい。このようにすることで、ＵＥ１、ＵＥ２の処理を簡易にすることができる。
【０３７７】
ＵＥ１からＵＥ２への送信処理には、ＰＩに含まれる情報の具体例で開示した、プリエンプトされた場合の受信処理に適した設定を用いてもよい。あらかじめこれらの送信処理方法と受信処理方法とを関連付けておいてもよい。どの送信処理方法を用いるか、どの受信処理方法を用いるかは、静的に規格等で決められてもよいし、ｇＮＢが設定してＳＬ通信のＵＥに通知してもよい。あるいは、どの送信処理方法を用いるか、どの受信処理方法を用いるかは、あらかじめＵＥに事前設定（Preconfigured）されてもよい。
【０３７８】
ＵＥ１からＵＥ２に対してリザベーションあるいはスケジューリングしている１番目のスロットをプリエンプトする場合、ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ３に対するスケジューリング情報を通知する。また、ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ２に対するＰＩを通知する。１番目のスロットのＰＳＣＣＨにはＵＥ３に対するスケジューリング情報がマッピングされ、ＵＥ２に対するスケジューリング情報がマッピングされない。このため、ＵＥ２は１番目のスロットのスケジューリング情報を受信できないことになる。このような場合、ＵＥ１の送信処理は、ＵＥ２に対して１番目のスロットで送信しない処理であってもよいし、ＵＥ２の受信処理は、１番目のスロットで受信しない処理であってもよい。
【０３７９】
このようにすることで、ＵＥ２が、１番目のスロットで、ＵＥ３に対するデータを誤受信するのを回避することができる。ＵＥ２は２番目のスロットのＰＳＣＣＨを受信するとよい。ＵＥ１からＵＥ２に対して２番目のスロットでＰＳＳＣＨがスケジューリングされている場合、ＵＥ２は該スケジューリング情報を受信可能となり、ＰＳＳＣＨを受信できる。
【０３８０】
ＵＥ１からＵＥ２に対してリザベーションあるいはスケジューリングしている１番目のスロットをプリエンプトする場合、ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ２に対するＰＩを通知しなくてもよい。ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ３に対するスケジューリング情報のみを通知してもよい。ＵＥ２は１番目のスロットがＵＥ３にスケジューリングされていることを認識した場合、ＵＥ２は１番目のスロットを受信しないとするとよい。このようにすることで、ＵＥ２が、１番目のスロットで、ＵＥ３に対するデータを誤受信するのを回避することができる。
【０３８１】
ＵＥ２に対してプリエンプトされたリソースのデータの処理について開示する。ＵＥ１は、ＵＥ２に対してプリエンプトされたリソースのデータを、残りのリソースで送信してもよい。残りのリソースで送信するため、ＵＥ１はレートマッチングを行ってもよい。このようにすることで、早期にプリエンプトされたデータを送信可能となる。
【０３８２】
他の方法として、ＵＥ１は、ＵＥ２に対してプリエンプトされたリソースのデータを、次にリザベーションしたリソースで送信してもよい。ＮＲのＳＬにおいてリソースの再選択回数を設定してもよい。リザベーションしたリソースによる送信を所定の再選択回数、行った場合、リソース選択を再度実施し、リソースリザベーションをし直す。このようにすることで、自ＵＥでのリソースの独占を回避することができる。
【０３８３】
リザベーションしたリソースによる送信が、所定の再選択回数に到達していない場合、ＵＥ１は、ＵＥ２に対してプリエンプトされたリソースのデータを、次にリザベーションしたリソースで送信する。リザベーションしたリソースによる送信が、所定の再選択回数に到達した場合、ＵＥ１は、リソースの再選択を行ってリソースリザベーションをし直し、新たにリザーブしたリソースで該データを送信する。
【０３８４】
プリエンプトされたリソースのデータ送信用に新たにリザーブされたリソースを用いる場合、再選択回数をカウントしない、としてもよい。再選択回数をデクリメントしないとしてもよい。このようにすることで、プリエンプトされたリソースのデータの送信において、さらに遅延時間が増大するのを回避することが可能となる。
【０３８５】
ＵＥ１は、ＵＥ２に対してプリエンプトされたリソースのデータを送信するために、リソース選択およびリソースリザベーションを新たに行ってもよい。該リソース選択およびリソースリザベーションは、周期的に行われなくてもよいし、あるいは、ダイナミックに実施されてもよい。短期間のリソースリザベーションが行われてもよい。プリエンプトされたリソースが周期的であったとしても、この方法を適用してもよい。このようにすることで、次のリザベーションされたリソースを待つことなく早期に、プリエンプトされたデータを送信可能となる。
【０３８６】
他の方法として、ＵＥ１は、ＵＥ２に対してプリエンプトされたリソースのデータ用の特別な処理を実施しないとしてもよい。ＨＡＲＱフィードバックが適用されている場合には、ＵＥ１は、ＵＥ２に対してプリエンプトされたリソースのデータ用の特別な処理を実施しないとしてもよい。ＨＡＲＱフィードバックが適用されている場合は、ＵＥ１はＨＡＲＱに従うとしてもよい。ＵＥ２は、スケジューリングされたデータを受信できなかった場合、ＵＥ１に対してＮａｃｋを送信する。ＵＥ１はＮａｃｋ受信により再送を行う。ＨＡＲＱ再送においてＵＥ１は、ＳＣＩに、どのデータに対する再送かを示す情報を含めるとよい。どのデータに対する再送かを示す情報は、たとえば、ＨＡＲＱプロセス識別子であってもよい。このようにすることで、ＵＥ２は、スケジューリングされたデータを受信可能となる。
【０３８７】
また、繰返し（repetition）送信が適用され、かつ、ＨＡＲＱフィードバックが適用されている場合には、ＵＥ１は、ＵＥ２に対してプリエンプトされたリソースのデータ用の特別な処理を実施しないとしてもよい。繰返し送信の内の１回の送信がプリエンプトされたとしても、他の繰返し送信によって、ＵＥ２は、スケジューリングされたデータを受信可能となる。
【０３８８】
このように、プリエンプトされたリソースのデータ用の特別な処理を実施しないとすることで、送信ＵＥ、受信ＵＥでのプリエンプション処理を簡易にすることが可能となる。
【０３８９】
図２５は、ＳＬ通信におけるプリエンプション方法の第２例を示す図である。図２５は、図２４と異なり、プリエンプトするリソースを含む３つのスロットが連続してスケジューリングされている場合におけるプリエンプション方法を例示している。連続する３つのスロットでＰＳＣＣＨ、ＰＳＳＣＨ、ＧＡＰ、ＰＳＦＣＨがマッピングされる。ＰＳＣＣＨは連続する３つのスロットの最初のスロットにマッピングされる。ＧＡＰ、ＰＳＦＣＨは連続する３つのスロットの最後のスロットにマッピングされる。
【０３９０】
図２４の例では、プリエンプトされる２番目のスロットのＰＳＣＣＨに、ＰＳＳＣＨのリソースアロケーション情報などのスケジューリング情報とＰＩとを含めた。図２５の例では、ＵＥ１からＵＥ２に対して、連続する３つのスロットを用いてスケジューリングするので、２番目のスロットでＰＳＣＣＨは送信されない。したがって、ＵＥ２は２番目のスロットのＰＳＣＣＨを受信しない。２番目のスロットのＰＳＣＣＨでＰＩを送信したとしても、ＵＥ２はＰＩを受信しないことになる。
【０３９１】
このような問題を解決するため、図２５の例では、ＵＥ１は、ＰＩを、連続してスケジューリングしたスロットの次のスロットのＰＳＣＣＨに含めて送信する。ＵＥ２は、連続してスケジューリングされたスロットの次のスロットのＰＳＣＣＨを受信する。これにより、ＵＥ２は、ＰＳＣＣＨにＰＩが含まれているか否かを判断可能となる。したがって、ＵＥ２は、リソースがプリエンプトされているか否かを判断することができる。
【０３９２】
ＵＥ２は、スケジューリングされた連続スロットにおいてリソースがプリエンプトされているかを判断するまで、受信したデータを保持しておくと良い。リソースがプリエンプトされている場合、ＵＥ２は、プリエンプトされたリソースを除外して、データを受信する。リソースがプリエンプトされていない場合は、ＵＥ２は連続する３スロットからデータを受信する。このようにすることで、ＵＥ２が、プリエンプトされたデータを誤受信することを回避することができる。
【０３９３】
２番目のスロットのＰＳＣＣＨは、ＵＥ１からＵＥ３に対して送信され、該ＰＳＣＣＨにはＰＩを含めない。ＵＥ３は、２番目のスロットのＰＳＣＣＨを受信することで、ＰＳＳＣＨのスケジューリング情報を取得し、ＰＳＳＣＨを受信可能となる。
【０３９４】
ＵＥ１は、ＰＩを、連続してスケジューリングしたスロットの次のスロットのＰＳＣＣＨに含めて送信することを開示したが、他の方法を開示する。ＵＥ１は、ＰＩを、ＵＥ２に対して連続してスケジューリングしたスロットの次のリザベーションしたスロットあるいはアロケーションするスロットのＰＳＣＣＨに含めて、送信してもよい。ＵＥ２は、連続してスケジューリングされたスロットに続く、自ＵＥに対してリザベーションされたスロットあるいはアロケーションされたスロットのＰＳＣＣＨを受信する。これにより、ＵＥ２は、ＰＳＣＣＨにＰＩが含まれているか否かを判断可能となる。したがって、ＵＥ２は、リソースがプリエンプトされているか否かを判断することができる。
【０３９５】
ＵＥ１からＵＥ２に対してリザベーションあるいはスケジューリングしている１番目のスロットをプリエンプトする場合、ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ３に対するスケジューリング情報を通知する。また、ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ２に対するＰＩを通知してもよい。１番目のスロットのＰＳＣＣＨにはＵＥ３に対するスケジューリング情報がマッピングされ、ＵＥ２に対するスケジューリング情報がマッピングされない。このため、ＵＥ２は１番目のスロットのスケジューリング情報を受信できないことになる。このような場合、ＵＥ１の送信処理は、ＵＥ２に対して連続する３つのスロットで送信しない処理であってもよいし、ＵＥ２の受信処理は、連続する３つのスロットで受信しない処理であってもよい。このようにすることで、ＵＥ２が、１番目から３番目のスロットで、ＵＥ３に対するデータを誤受信するのを回避することができる。
【０３９６】
ＵＥ１からＵＥ２に対してリザベーションあるいはスケジューリングしている１番目のスロットをプリエンプトする場合、ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ２に対するＰＩを通知しなくてもよい。ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ３に対するスケジューリング情報のみを通知してもよい。ＵＥ２は１番目のスロットがＵＥ３にスケジューリングされていることを認識した場合、ＵＥ２は連続する３つのスロットを受信しないとするとよい。このようにすることで、ＵＥ２が、１番目から３番目のスロットで、ＵＥ３に対するデータを誤受信するのを回避することができる。
【０３９７】
このようなプリエンプション方法とすることで、ＳＬ通信において、連続した複数スロットでスケジューリングが行われたとしても、プリエンプションを可能にする。
【０３９８】
図２６は、ＳＬ通信におけるプリエンプション方法の第３例を示す図である。図２６は、図２５と同様に、プリエンプトするリソースを含む３つのスロットが連続してスケジューリングされている場合におけるプリエンプション方法を例示している。図２６は、図２５と異なり、プリエンプトするリソースがミニスロットの場合について示している。
【０３９９】
プリエンプトするリソースがミニスロットの場合も、図２６で開示した方法と同様に、ＵＥ１は、ＰＩを、連続してスケジューリングされたスロットの次のスロットのＰＳＣＣＨに含めて送信する。ＵＥ２は、連続してスケジューリングされたスロットの次のスロットのＰＳＣＣＨを受信する。これにより、ＵＥ２はＰＳＣＣＨにＰＩが含まれているか否かを判断可能となる。したがって、ＵＥ２は、リソースがプリエンプトされているか否かを判断することができる。
【０４００】
２番目のスロット内にプリエンプトするミニスロットのＰＳＣＣＨは、ＵＥ１からＵＥ３に対して送信され、該ＰＳＣＣＨにはＰＩを含めない。ＵＥ３は、ミニスロットのＰＳＣＣＨを受信することで、ＰＳＳＣＨのスケジューリング情報を取得し、ＰＳＳＣＨを受信可能となる。
【０４０１】
ＵＥ１からＵＥ２に対してリザベーションあるいはスケジューリングしている１番目のスロットのＰＳＣＣＨ領域を含むリソースをミニスロットでプリエンプトする場合、ＵＥ１は、ミニスロットのＰＳＣＣＨでＵＥ３に対するスケジューリング情報を通知する。また、ＵＥ１はミニスロットのＰＳＣＣＨでＵＥ２に対するＰＩを通知してもよい。ミニスロットのＰＳＣＣＨにはＵＥ３に対するスケジューリング情報がマッピングされ、ＵＥ２に対するスケジューリング情報がマッピングされない。このため、ＵＥ２は連続する３つのスロットのスケジューリング情報を受信できないことになる。このような場合、ＵＥ１の送信処理は、ＵＥ２に対して連続する３つのスロットで送信しない処理であってもよいし、ＵＥ２の受信処理は、連続する３つのスロットで受信しない処理であってもよい。このようにすることで、ＵＥ２が、１番目から３番目のスロットで、ＵＥ３に対するデータを誤受信するのを回避することができる。
【０４０２】
ＵＥ１からＵＥ２に対してリザベーションあるいはスケジューリングしている１番目のスロットのＰＳＣＣＨ領域を含むリソースをミニスロットでプリエンプトする場合、ＵＥ１は、ミニスロットのＰＳＣＣＨでＵＥ２に対するＰＩを通知しなくてもよい。ＵＥ１は、ミニスロットのＰＳＣＣＨでＵＥ３に対するスケジューリング情報のみを通知してもよい。ＵＥ２はミニスロットのリソースでＵＥ３にスケジューリングされていることを認識した場合、ＵＥ２は連続する３つのスロットを受信しないとするとよい。このようにすることで、ＵＥ２が、１番目から３番目のスロットで、ＵＥ３に対するデータを誤受信するのを回避することができる。
【０４０３】
受信ＵＥはＳＬ通信におけるミニスロットのＰＳＣＣＨを受信する必要がある。ＳＬ通信でミニスロットにデータがスケジューリングされた場合、受信ＵＥは該ミニスロットのＰＳＣＣＨを受信する。受信ＵＥは、ミニスロットのＰＳＣＣＨの送信タイミングを知らないと、ＰＳＣＣＨを受信できない。そのため、受信ＵＥがミニスロットのＰＳＳＣＨを受信できないという問題が生じる。ここでは、このような問題を解決する方法を開示する。
【０４０４】
ＳＬにおけるミニスロットの設定方法を開示する。ＳＬでのミニスロットの設定は送信ＵＥが行う。送信ＵＥが、ＳＬでのミニスロットの設定を行い、該設定を受信ＵＥに通知する。該通知には通常のスロットのＰＳＣＣＨを用いてもよい。ミニスロットの設定のための情報として、たとえば、ミニスロットのシンボル数、ＰＳＣＣＨのシンボル数および／あるいはシンボル番号、ＰＳＳＣＨのシンボル数および／あるいはシンボル番号、ＲＳのシンボル数および／あるいはシンボル番号などがある。ＧＡＰ，ＰＳＦＣＨのシンボル数および／あるいはシンボル番号をミニスロットの設定のための情報に含めてもよい。
【０４０５】
通常のスロットとの関係を示す情報をミニスロットの設定のための情報に含めてもよい。通常のスロットとの関係を示す情報は、たとえば、ミニスロットが通常のスロットの何シンボル目から何シンボル目かを示す情報などである。対象となるミニスロットを通常のスロットのシンボル番号で設定するとよい。ミニスロットのＰＳＣＣＨ、ＰＳＳＣＨ、ＧＡＰ、ＰＳＦＣＨについても同様である。このようにすることで、ミニスロットの設定を行うことが可能となる。
【０４０６】
送信ＵＥが受信ＵＥにミニスロットの設定を通知する他の方法を開示する。ミニスロットの設定のための情報は、ＭＡＣシグナリングを用いて通知してもよい。ミニスロットの設定のための情報をＭＡＣ制御情報に含めてもよい。ミニスロットの設定のための情報をＰＣ５シグナリングで通知してもよい。あるいは、ＳＬのユニキャスト通信において対向するＵＥ間でＲＲＣ接続が実施される場合、ＳＬのＲＲＣシグナリングを用いて、ミニスロットの設定のための情報を通知してもよい。ミニスロットの設定のための情報をＳＬのＲＲＣ情報に含めてもよい。
【０４０７】
送信ＵＥが受信ＵＥにミニスロットの設定を通知する他の方法を開示する。送信ＵＥはミニスロットの設定をＰＳＢＣＨで通知する。送信ＵＥはミニスロットの設定を、報知情報に含めて、ＰＳＢＣＨにマッピングして、通知する。このようにすることで、送信ＵＥ毎にミニスロットを設定するような場合に、受信ＵＥに対して個別にミニスロットの設定を通知する必要がなくなる。ＳＬ通信でのシグナリング量を削減することが可能となる。
【０４０８】
ミニスロット設定のアクティベーション（activation）および／あるいはデアクティベーション（deactivation）を示す情報を設けてもよい。以降、該情報をミニスロット設定のact/deact情報と称する。送信ＵＥが受信ＵＥにミニスロット設定のact/deact情報を通知する。該情報の通知には、ミニスロットの設定のための情報の通知方法を適用するとよい。
【０４０９】
たとえば、送信ＵＥは受信ＵＥに、ミニスロットの設定のための情報を通知する。以後、送信ＵＥはミニスロット設定のact情報を通知する。ミニスロットの設定毎に識別子を設けておき、ミニスロット設定のact/deact情報とともに該識別子を通知してもよい。このようにすることで、複数のミニスロット設定が存在するような場合も、どのミニスロット設定をアクティベーションしてよいかを認識可能となる。
【０４１０】
受信ＵＥは、ミニスロット設定のact情報の受信により、ミニスロット設定を適用する。送信ＵＥはミニスロットで送信を行い、受信ＵＥはミニスロットで受信する。送信ＵＥは受信ＵＥにミニスロット設定のdeact情報を通知する。受信ＵＥはミニスロット設定のdeact情報の受信により、ミニスロット設定を解除する。受信ＵＥは通常のスロットの受信を行ってもよい。このようにすることで、ＳＬでミニスロットの設定を終了することが可能となる。
【０４１１】
このようにすることで、ＳＬでミニスロットの設定が可能となり、ミニスロットを用いた送受信が可能となる。
【０４１２】
ＳＬにおけるミニスロットの設定方法について他の方法を開示する。ＳＬでのミニスロットの設定はｇＮＢが行う。ｇＮＢが、ＳＬでのミニスロットの設定を行い、該設定を送信ＵＥに通知する。送信ＵＥは、受信したＳＬでのミニスロットの設定を、受信ＵＥに通知する。該通知にはｇＮＢとＵＥとの間のＵｕインタフェースを用いる。ｇＮＢは、ＳＬでのミニスロット設定のための情報をＤＣＩに含めて、ＳＬ通信の送信ＵＥに対してＰＤＣＣＨで通知するとよい。ダイナミックな設定が可能となる。あるいは、ｇＮＢはＳＬ通信の送信ＵＥに対して、ＳＬでのミニスロット設定情報をＭＡＣシグナリングで通知してもよい。あるいは、ＳＬでのミニスロット設定情報をＲＲＣシグナリングで通知してもよい。受信誤りを低減可能となる。
【０４１３】
ミニスロット設定のための情報は、前述した例を適用するとよい。ＳＬ通信の送信ＵＥから受信ＵＥに対してミニスロットの設定を通知する方法は、前述の方法を適用するとよい。
【０４１４】
ミニスロット設定のact/deactはＳＬ通信の送信ＵＥが設定してもよい。ＳＬ通信の送信ＵＥが、ミニスロット設定のact/deactを設定して、受信ＵＥに通知する。この方法には前述の方法を適用するとよい。送信ＵＥがミニスロット設定のact/deactを設定することで、ＳＬで送信するデータのサービスに応じたミニスロットの設定を可能とする。ミニスロット設定のact/deactまでの設定時間を短縮可能となる。
【０４１５】
ミニスロット設定のact/deactの他の方法を開示する。ミニスロット設定のact/deactはｇＮＢが設定してもよい。ｇＮＢが、ミニスロット設定のact/deactを設定して、ＳＬ通信の送信ＵＥに通知する。ミニスロット設定のact/deact情報を受信した送信ＵＥは、該情報を受信ＵＥに通知するとよい。これらの通知方法には、前述のミニスロット設定のための情報の通知方法を適用するとよい。ｇＮＢがミニスロット設定のact/deactを設定することで、ＳＬ通信を行う他のＵＥへの設定を考慮することが可能となる。ミニスロット設定を行うリソースの衝突を低減することが可能となる。
【０４１６】
このようなプリエンプション方法とすることで、ＳＬ通信においてミニスロットのプリエンプションンを可能にする。
【０４１７】
図２７は、ＳＬ通信におけるプリエンプション方法の第４例を示す図である。図２７は、図２５と同様に、プリエンプトするリソースを含む３つのスロットが連続してスケジューリングされている場合におけるプリエンプション方法を例示している。図２７の例では、ＵＥ３は、３スロット連続のスケジューリングが行われた場合でも、毎スロットのＰＳＣＣＨ領域を受信するようにしておく。このことを規格等で静的に決めておいてもよい。
【０４１８】
あるいは、毎スロットのＰＳＣＣＨ領域を受信することを示す情報を、ｇＮＢが、ＳＬ通信を行うＵＥに対して通知してもよい。ｇＮＢは該情報を、ＳＩＢに含めて報知しても良いし、ＲＲＣシグナリングでＵＥに通知してもよい。あるいは、該情報がＵＥに予め設定されていてもよい。
【０４１９】
他の方法を示す。毎スロットのＰＳＣＣＨ領域を受信することを示す情報、あるいは、毎スロットのＰＳＣＣＨ領域を受信するかしないかを示す情報を、最初のスロットのＰＳＣＣＨに含めてもよい。該情報は、連続した複数スロットでスケジューリングを行う場合のスケジューリング情報を含めるＰＳＣＣＨに含めてもよい。このようにすることで、ＵＥ２は、連続した複数スロットのスケジューリングをＵＥ１から受信することで、毎スロットのＰＳＣＣＨ領域を受信することを示す情報を受信することができる。たとえば、ＵＥ１が２番目のスロットのリソースをＵＥ３にプリンプトする場合、ＵＥ１は、ＵＥ２に対して、毎スロットのＰＳＣＣＨ領域を受信することを示す情報を送信する。このようにすることで、ＵＥ２は、２番目のスロットのＰＳＣＣＨを受信することが可能となる。
【０４２０】
また、ＵＥ１は、ＵＥ２に対するＰＩを、２番目のスロットのＰＳＣＣＨに含めて送信する。図２４の例と同様に、ＵＥ１は、２番目のスロットのＰＳＣＣＨで、ＵＥ３に対するＰＳＳＣＨのリソースアロケーション情報などのスケジューリング情報を含むＳＣＩと、ＵＥ２に対するＰＩと、を送信する。このようにすることで、ＵＥ２はＰＩを受信可能となる。
【０４２１】
ＵＥ１からＵＥ２に対してリザベーションあるいはスケジューリングしている１番目のスロットをプリエンプトする場合、ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ３に対するスケジューリング情報を通知する。また、ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ２に対するＰＩを通知する。１番目のスロットのＰＳＣＣＨにはＵＥ３に対するスケジューリング情報がマッピングされ、ＵＥ２に対するスケジューリング情報がマッピングされない。このため、ＵＥ２は１番目のスロットのスケジューリング情報を受信できないことになる。このような場合、ＵＥ１の送信処理は、ＵＥ２に対して１番目のスロットで送信しない処理であってもよいし、ＵＥ２の受信処理は、１番目のスロットで受信しない処理であってもよい。
【０４２２】
このようにすることで、ＵＥ２が、１番目のスロットで、ＵＥ３に対するデータを誤受信するのを回避することができる。毎スロットのＰＳＣＣＨ領域を受信することが規格等で静的に決められている場合や、ｇＮＢから通知されている場合など、ＵＥが毎スロットのＰＳＣＣＨ領域を受信することになる場合は、ＵＥ２は２番目のスロットのＰＳＣＣＨを受信するとよい。ＵＥ１からＵＥ２に対して２番目のスロットでＰＳＳＣＨがスケジューリングされている場合、該スケジューリング情報を受信可能となり、ＰＳＳＣＨを受信できる。
【０４２３】
ＵＥ１からＵＥ２に対してリザベーションあるいはスケジューリングしている１番目のスロットをプリエンプトする場合、ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ２に対するＰＩを通知しなくてもよい。ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ３に対するスケジューリング情報のみを通知してもよい。ＵＥ２は１番目のスロットがＵＥ３にスケジューリングされていることを認識した場合、ＵＥ２は１番目のスロットを受信しないとするとよい。このようにすることで、ＵＥ２が、１番目のスロットで、ＵＥ３に対するデータを誤受信するのを回避することができる。
【０４２４】
ＰＩに、毎スロットのＰＳＣＣＨ領域を受信することを示す情報を含めてもよい。ＵＥ１は、１番目のスロットのＰＳＣＣＨでＵＥ２に対してＰＩを通知する。これにより、ＵＥ１からＵＥ２に対して2番目のスロットでＰＳＳＣＨがスケジューリングされている場合、該スケジューリング情報を受信可能となり、ＰＳＳＣＨを受信できる。
【０４２５】
図２７で開示したような方法とすることで、図２５あるいは図２６で開示した方法とは異なり、ＵＥ１が、ＵＥ２に対するＰＩを、連続してスケジューリングされた複数スロットの次のスロットで送信する必要がなくなる。このため、ＵＥ２は、ＰＩを早期に受信することによって、リソースがプリエンプトされたか否かの判断を、より早期に実施可能となる。ＵＥ２は、プリエンプトされたリソースを除外してデータの復調を、より早期に実施可能となる。また、ＵＥ２は、次のスロットに含まれるＰＩを受信するまでデータを保持するという動作を行わなくても済む。それにより、ＵＥ２におけるデータバッファ容量を低減できる。
【０４２６】
ＳＬ通信におけるプリエンプション方法の他の例を開示する。ＰＩ送信用のリソースを設ける。ＰＩ送信用のリソースを、プリエンプトされる通信のリザベーションされたリソースあるいはアロケーションするリソース内であって、プリエンプトするリソース外に設けるとよい。ＰＩ送信用のリソースは時間−周波数リソースであってもよい。リソースの時間単位は例えば、スロット、ミニスロット、シンボル、１／ｎシンボルであってもよい。リソースの周波数単位は例えば、ＰＲＢ、サブキャリアであってもよい。
【０４２７】
ＰＩ送信用リソースの構成は例えば、スロット番号、シンボル数、シンボル番号、ＰＲＢ数、ＰＲＢ番号などとするとよい。ＰＩ送信用のリソース構成は予め静的に規格等で決められてもよい。あるいは、ｇＮＢが、ＰＩ送信用リソース構成を決定し、決定したリソース構成を、ＳＬ通信を行うＵＥにＳＩＢで通知してもよい。あるいは、ｇＮＢが、ＰＩ送信用リソース構成を決定し、決定したリソース構成をＳＬ通信の送信ＵＥにＲＲＣシグナリングで通知してもよい。送信ＵＥは受信ＵＥに対して、ＰＳＣＣＨでＰＩ送信用リソース構成を通知してもよい。
【０４２８】
あるいは、ＳＬ通信の送信ＵＥが、ＰＩ送信用リソース構成を決定し、決定した構成を受信ＵＥに通知してもよい。送信ＵＥは受信ＵＥに対して、ＰＳＣＣＨでＰＩ送信用リソース構成を通知してもよい。ＳＬ通信における送信ＵＥおよび／あるいは受信ＵＥは、ＰＩ送信用リソース構成を受信すると、該ＰＩ送信用リソース構成を用いてＰＩの送信、受信が可能となる。
【０４２９】
送信ＵＥは、ＰＩをＰＩ送信用のリソースで送信する。ＰＩを含むチャネルを設けて、ＰＩ送信用のリソースにマッピングしてもよい。ＰＩをＰＳＣＣＨに含めて、ＰＩ送信用のリソースにマッピングしてもよい。受信ＵＥは、ＰＩ送信用リソース構成が通知された場合、該ＰＩ送信用リソースを受信するとしてもよい。
【０４３０】
あるいは、ＰＩ送信用リソース受信のアクティベーションおよび／あるいはデアクティベーションを示す情報を設けてもよい。送信ＵＥは、受信ＵＥに対して、ＰＩ送信用リソース受信のａｃｔ／ｄｅａｃｔ情報をＰＳＣＣＨで送信する。受信ＵＥは、ＰＩ送信用リソース受信のａｃｔ情報を受信した場合に、ＰＩ送信用リソース構成を用いてＰＩ送信用リソースを受信する。受信ＵＥは、ＰＩ送信用リソース受信のｄｅａｃｔ情報を受信した場合に、ＰＩ送信用リソース構成を用いてＰＩ送信用リソースの受信を終了する。
【０４３１】
具体例を開示する。複数の連続スロットでスケジューリングを行う場合、送信ＵＥは、ＰＩ送信用のリソースとして、最後のスロットのＧＡＰの直前のシンボルを用いる。送信ＵＥは該シンボルでＰＩを送信する。送信ＵＥは、最初のスロットのＰＳＣＣＨで、該ＰＩ送信用リソース構成を、受信ＵＥに送信するとよい。このようにすることで、受信ＵＥは、ＰＩ送信用のリソース構成を受信可能となり、該構成を用いてＰＩを受信可能となる。
【０４３２】
このような方法とすることで、複数の連続スロットでのスケジューリングが実施されたリソースをプリエンプトするような場合も、複数の連続スロット内でＰＩを送信可能となる。そのため、図２５、図２６の例とは異なり、送信ＵＥはＰＩを該連続スロットの次のスロットのＰＳＣＣＨで送信しなくて済む。また、受信ＵＥは、ＰＩを受信するために、設定されたＰＩ送信用リソースのみを受信すればよい。そのため、図２７で示した方法とは異なり、受信ＵＥは毎スロットのＰＳＣＣＨを受信しなくて済む。また、受信ＵＥは、ＰＩを受信するために、プリエンプトされる通信のリザベーションされたリソースあるいはアロケーションするリソースを受信すればよい。受信ＵＥでの処理を簡易にすることが可能となる。
【０４３３】
前述の方法では、ＰＩ送信用のリソースを設けることを開示した。送信ＵＥは、ＰＩ送信用リソースでＰＩを送信する。この際、送信ＵＥはデータを送信しない。ここでは、ＳＬ通信におけるプリエンプション方法の他の例を開示する。
【０４３４】
送信ＵＥは、ＰＩ送信用リソースで、ＰＩあるいはＰＩを含むチャネルと、データとを多重して送信する。送信ＵＥは、ＰＳＣＣＨ用のリソースで、ＰＩを含めるＰＳＣＣＨとデータとを多重してもよい。多重方法として、コード多重を用いるとよい。コード多重の方法として、たとえば、ＰＩを含むチャネルに所定のスクランブリングコードを乗じる方法を用いてもよい。あるいは、ＰＩを含むチャネルに所定のＺＣ（Zadoff-Chu）シーケンスを用いてもよい。
【０４３５】
該所定のスクランブリングコードあるいは所定のＺＣシーケンスは、あらかじめ静的に規格等で決められても良いし、送信ＵＥから受信ＵＥに通知されてもよい。このようにすることで、受信ＵＥは、データからＰＩを分別して復調可能となり、ＰＩを受信可能となる。
【０４３６】
データあるいはデータ復調用ＲＳと、ＰＩを含むチャネルとに、異なるスクランブリングコードを乗じてもよい。あるいは、データあるいはデータ復調用ＲＳと、ＰＩを含むチャネルとに、異なるＺＣシーケンスを用いてもよい。これらのスクランブリングコードあるいはＺＣシーケンスは、あらかじめ静的に規格等で決められても良い。あるいは、ｇＮＢが、スクランブリングコードあるいはＺＣシーケンスを決定し、決定したスクランブリングコードあるいはＺＣシーケンスを、ＳＬ通信を行うＵＥに通知してもよい。あるいは、送信ＵＥが、スクランブリングコードあるいはＺＣシーケンスを決定し、決定したスクランブリングコードあるいはＺＣシーケンスを受信ＵＥに通知してもよい。このようにすることで、受信ＵＥは、データとＰＩとを分別して復調可能となり、データとＰＩとを受信可能となる。
【０４３７】
ＳＬ通信におけるプリエンプション方法の他の例を開示する。ＰＩ送信用のリソースを、プリエンプトされる通信のリザベーションされたリソースあるいはアロケーションするリソースの外に設ける。ＰＩ送信用リソース構成は周期的であってもよい。ＰＩ送信用のリソース構成、ＰＩ送信用リソース構成の通知方法、送信ＵＥおよび受信ＵＥでのＰＩ送受信方法については、前述の例、すなわち、ＰＩ送信用のリソースを、プリエンプトされる通信のリザベーションされたリソースあるいはアロケーションするリソース内であって、プリエンプトするリソース外に設ける場合で開示した例を適用するとよい。
【０４３８】
ＳＬ通信を行う送信ＵＥは、ＰＩ送信用リソースを除外して、ＳＬ通信用リソースを選択してリソースリザベーションするとよい。ＳＬ通信用のリソースとＰＩ送信用リソースとの衝突を回避させることが可能となる。
【０４３９】
このようにすることで、ＰＩ送信用のリソースの候補を増大させることが可能となる。また、プリエンプトされる通信のリソースを低減させることなく、ＰＩ送信を行うことが可能となる。
【０４４０】
ＰＩ送信用のリソースを、プリエンプトされる通信のリザベーションされたリソースあるいはアロケーションするリソースの内外に設けてもよい。前述に開示した方法を適用するとよい。
【０４４１】
前述の図の例では、ＵＥ１からＵＥ２に対してリソースのリザベーションが周期的に行われる場合について開示した。本実施の形態４で開示したような方法は、ＵＥ１からＵＥ２に対してリソースのリザベーションあるいはスケジューリングが周期的に行われる場合でなくてもよく、たとえば、ＵＥ１からＵＥ２に対してリソースのリザベーションあるいはスケジューリングが非周期的に行われる場合に適用してもよい。本実施の形態４で開示したような方法は、ＵＥ１からＵＥ２に対してリソースのリザベーションあるいはスケジューリングがダイナミックに行われる場合に適用してもよい。同様の効果を得ることが可能となる。
【０４４２】
プリエンプション可能か否かの判断は送信ＵＥが行うとよい。送信ＵＥは、すでにあるサービスの通信のためにリザベーションあるいはスケジューリングしたリソースを、他のサービスの通信のためにプリエンプトすることが可能か否かを判断する。該判断に、サービスに関する情報を用いてもよい。サービスに関する情報は、例えば、ＱｏＳ情報、ＱＣＩ、ＰＰＰＰ、要求される遅延時間、要求されるスルーレート等であってもよい。
【０４４３】
たとえば、すでにリザベーションあるいはスケジューリングしているサービスよりも、後から発生した送信データのサービスの方が、要求される遅延時間が小さい場合、プリエンプション可能とする。
【０４４４】
具体例を示す。送信ＵＥは、要求遅延時間がＬ１のサービスの通信のためにリソースをリザベーションしている。このような状態において、送信ＵＥにおいて、要求遅延時間がＬ２のサービスの送信データが発生したとする。ここで、要求遅延時間Ｌ２の方が、要求遅延時間Ｌ１より小さい（Ｌ１＞Ｌ２）とする。このように、後から発生したサービスの要求遅延時間が小さい場合、プリエンプション可能とする。送信ＵＥは、これらのサービスの要求遅延時間を比較し、後から発生したサービスの要求遅延時間が小さい場合、プリエンプション可能と判断する。
【０４４５】
これらの判断は、ＳＬのＭＡＣにおいて行われてもよい。ＳＬのＭＡＣが、サービスに関する情報を用いてプリエンプション可能か否かを判断するとよい。ＳＬのＭＡＣは上位レイヤからサービスに関する情報を取得するとよい。ＳＬのＭＡＣでプリエンプション可能か否かを判断することによって、プリエンプトする通信のためのスケジューリングと、プリエンプトされる通信のためのスケジューリングとの協調処理を容易にすることができる。
【０４４６】
本実施の形態４で開示したような方法とすることで、ＳＬにおけるプリエンプションを可能にする。このため、送信ＵＥが複数のサービスのデータを送信する状況において、各サービスで受信ＵＥが異なる場合であっても、低遅延特性が要求されるサービスのＳＬ通信においてプリエンプションを実施することができる。それにより、通信に要求される低遅延特性を満足させることが可能となる。
【０４４７】
実施の形態４の変形例１．
実施の形態４では、プリエンプトされる通信の送信ＵＥとプリエンプトする通信の送信ＵＥが同じ場合におけるプリエンプション方法について開示した。本変形例１では、プリエンプトされる通信の送信ＵＥとプリエンプトする通信の送信ＵＥが異なる場合におけるプリエンプション方法について開示する。
【０４４８】
プリエンプトされる通信の送信ＵＥとプリエンプトする通信の送信ＵＥが異なる場合、プリエンプトされる通信の受信ＵＥに、プリエンプトが行われたことをどのように通知するかだけでなく、プリエンプトされる通信の送信ＵＥに、プリエンプトが行われたことをどのように通知するかが問題となる。プリエンプトされる通信の送信ＵＥが、プリエンプトが行われたことを認識しない場合、該送信ＵＥは、プリエンプトされたリソースでデータ送信を行うことになり、プリエンプトする通信と衝突してしまうからである。該衝突により、プリエンプトされる通信の受信ＵＥも、プリエンプトする通信の受信ＵＥも、データを受信できなくなってしまう。本変形例１においては、このような問題を解決する方法を開示する。
【０４４９】
プリエンプトする通信の送信ＵＥは、プリエンプトするリソースより前のスロットにおける、プリエンプトされる送信ＵＥが受信可能なリソースを用いて、ＰＩ２を送信する。プリエンプトする通信の送信ＵＥは、プリエンプトするリソースより前のスロットにおける、プリエンプトされる送信ＵＥが受信可能なリソースに、ＰＩ２を含むチャネルをマッピングして、ＰＩ２を送信してもよい。プリエンプトする通信の送信ＵＥは、プリエンプトするリソースより前のスロットにおけるＰＳＦＣＨで、ＰＩ２を送信してもよい。
【０４５０】
ＰＩ２はプリエンプションを示す情報である。ＰＩ２に含まれる情報として以下に５つの具体例を開示する。
（１）プリエンプションを示す情報。
（２）プリエンプトされるリソースの情報。
（３）プリエンプトされる場合の送信処理を示す情報。
（４）プリエンプトする通信の送信ＵＥに関する情報。
（５）（１）から（４）の組合せ。
【０４５１】
前述の（１）、（２）はＰＩと同様である。
【０４５２】
前述の（３）について、プリエンプトされる場合の送信処理は、プリエンプトされるリソースのみ送信しない処理であってもよいし、あるいは、プリエンプトされるリソースを含む所定のリソースを送信しない処理であってもよい。所定のリソースは、たとえばスロットなどである。あるいは、所定のリソースは、複数の連続するスロットであってもよい。他の例として、プリエンプトされる場合の送信処理は、一部のリソースがプリエンプトされるデータを全て送信しない処理であってもよい。このようにすることで、送信処理を簡易にすることができる。また、送信処理は、送信停止の処理であってもよいし、送信電力をオフあるいは低減する処理であってもよい。
【０４５３】
前述の（４）について、プリエンプトする通信の送信ＵＥに関する情報は、該送信ＵＥを特定するための情報とするとよい。たとえば、該情報はＵＥの識別子であってもよい。プリエンプトする送信ＵＥを明示的に示すことができ、誤動作の発生を低減させることができる。
【０４５４】
このようにすることで、プリエンプトされた通信の送信ＵＥは、プリエンプトされるリソースより前のスロットの受信用シンボルで、プリエンプトする通信の送信ＵＥから、ＰＩ２を受信することが可能となる。プリエンプトされた通信の送信ＵＥは、ＰＩ２を受信することで、プリエンプトされるリソースを認識可能となる。それにより、プリエンプトされるリソースで送信を停止させる処理などを実施可能となる。
【０４５５】
プリエンプトする通信の送信ＵＥから、プリエンプトする通信の受信ＵＥへ、リソースアロケーションを含むスケジューリング情報を送信する方法、プリエンプトする通信の送信ＵＥから、プリエンプトされる通信の受信ＵＥへ、ＰＩを送信する方法などは、実施の形態４で開示した方法を適用するとよい。
【０４５６】
このようにすることで、プリエンプトされる通信の送信ＵＥとプリエンプトする通信の送信ＵＥが異なる場合においてプリエンプションが可能になる。
【０４５７】
図２８は、ＳＬ通信におけるプリエンプションの概要を示す図である。図２８は、プリエンプトされる通信の送信ＵＥとプリエンプトする通信の送信ＵＥとが異なる場合について示している。ＵＥ１はプリエンプトされる通信の送信ＵＥであり、ＵＥ２はプリエンプトされる通信の受信ＵＥであり、ＵＥ３はプリエンプトする通信の送信ＵＥであり、ＵＥ４はプリエンプトする通信の受信ＵＥであるものとする。ＵＥ３からＵＥ４への通信は、より低遅延特性が要求される通信とする。
【０４５８】
ＵＥ１からＵＥ２に対して、リソースのリザベーションが行われる。ここでは、図２３と同様に、リソースリザベーションが周期的に行われるものとする。このように、ＵＥ１からＵＥ２へのリソースリザベーションが既に行われている状態で、ＵＥ３においてＵＥ４へのＳＬの送信がトリガされる。ＵＥ３は送信処理を行い、リソースを選択する。リソース選択は選択ウィンドウ内で行われる。
【０４５９】
ＵＥ３は、低遅延特性が要求されるＵＥ４への通信のために、既にＵＥ１がＵＥ２に対してリザベーションしているリソースをプリエンプトすることを決定する。ここでは、ＵＥ３は、送信処理後の２番目のスロットをプリエンプトする。ＵＥ３はＵＥ４に対して、プリエンプトしたリソースを用いて送信を行う。ＵＥ１はＵＥ２に対して、プリエンプトされたリソースで送信を行わないとしてもよい。ここでは、ＵＥ１はＵＥ２に対して２番目のスロットで送信を行わない。
【０４６０】
このように、ＵＥ３は、ＵＥ１がＵＥ２に対して既にリザベーションしているリソースを、ＵＥ４に対してプリエンプトして送信する。このようにすることで、より低遅延特性が要求されるＵＥ４に対する通信を、低遅延で行うことが可能となる。
【０４６１】
図２９は、ＳＬ通信におけるプリエンプション方法の第１例を示す図である。図２９は、図２８と同様に、プリエンプトするリソースを含む３つのスロットを示している。各スロットにＰＳＣＣＨ、ＰＳＳＣＨ、ＧＡＰ、ＰＳＦＣＨがマッピングされる。
【０４６２】
図２９は、ＵＥ１からＵＥ２に既に３スロットのリソースがリザベーションされている場合に、２番目のスロットがプリエンプトされる場合について示している。ＵＥ３においてＵＥ４へのＳＬの送信がトリガされ、ＵＥ３はＵＥ４への通信のために、送信処理後の２番目のスロットのリソースをプリエンプトすることを決定する。１番目と３番目のスロットは通常どおりＵＥ１からＵＥ２に対して送信を行うため、ＵＥ１はＵＥ２に対してＰＳＣＣＨ、ＰＳＳＣＨを送信する。
【０４６３】
ＵＥ３は、プリエンプトする２番目のスロットの直前のスロット（すなわち１番目のスロット）における、ＵＥ１が受信可能なシンボルで、ＰＩ２を送信する。ここでは、ＵＥ３はＰＩ２を、ＰＳＦＣＨに含めて、ＵＥ１が受信可能なシンボルで送信する。
【０４６４】
このようにすることで、ＵＥ１は、プリエンプトされる２番目のスロットより前で、ＰＩ２を受信することができる。ＰＩ２を受信したＵＥ１は、プリエンプトされたリソースを認識可能となる。このため、ＵＥ１は、プリエンプトされたリソースで、たとえば送信を停止することができる。ここでは、プリエンプトされた２番目のスロットで、ＵＥ１は送信停止する。このようにすることで、ＵＥ１は、プリエンプトされる２番目のスロットで、ＵＥ３からＵＥ４への通信に干渉を与えないようにすることができる。
【０４６５】
ＵＥ３は、ＵＥ４に対する送信処理後の２番目のスロットを、ＵＥ４の通信用にプリエンプトする。２番目のスロットでは、ＵＥ２へのリソースがプリエンプトされることになる。プリエンプトした２番目のスロットで、ＵＥ３は、ＵＥ４に対するＰＳＣＣＨ、ＰＳＳＣＨを送信する。プリエンプトしたスロットは、ＧＡＰ、ＰＳＦＣＨがマッピングされるように構成されてもよい。ＵＥ３は、ＵＥ４に対するＰＳＳＣＨのリソースアロケーション情報などのスケジューリング情報と、ＵＥ２に対するＰＩとを、プリエンプトしたスロットのＰＳＣＣＨに含めて、送信する。ＰＳＣＣＨはＵＥ２も受信可能なので、ＵＥ３から送信されたＰＳＣＣＨに含まれるＰＩをＵＥ２が受信可能となる。
【０４６６】
このようにすることで、ＵＥ２が、他のＵＥにプリエンプトされたリソースを誤受信するのを避けることが可能となる。ＵＥ４は、２番目のスロットのＰＳＣＣＨを受信してＰＳＳＣＨが自ＵＥ宛であることを認識し、ＳＣＩに含まれるスケジューリング情報を用いてＰＳＳＣＨを受信することができる。
【０４６７】
ＰＩ２あるいはＰＩ２を含むチャネルと、ＰＳＦＣＨとを多重してもよい。プリエンプトする通信の送信ＵＥは、プリエンプトされる送信ＵＥが受信可能なリソースで、ＰＩ２あるいはＰＩ２を含むチャネルと、ＰＳＦＣＨとを多重して送信してもよい。
【０４６８】
ＰＩ２とＰＳＦＣＨとの多重方法について開示する。時間分割多重を用いるとよい。ＵＥ１が受信可能なシンボルを用いて、多重を行うと良い。ＵＥ１が受信可能なシンボルで、ＰＩ２をマッピングするシンボルと、ＰＳＦＣＨをマッピングするシンボルとを異ならせる。このようにすることで、ＵＥ１はＰＩ２とＰＳＦＣＨとを受信可能となる。
【０４６９】
ＰＩ２が有る場合と無い場合とで、スロットフォーマットの設定を変えてもよい。たとえば、ＰＩ２が有る場合はスロット内の受信用シンボルは２とし、ＰＩ２が無い場合はスロット内の受信用シンボルは１とする。このようにすることで、ＰＩ２が無い場合に、ＰＩ２用のシンボルを確保しておく必要がなく、他の用途（たとえば送信用）に該シンボルを使用可能となる。リソース使用効率を向上させることが可能となる。
【０４７０】
ＰＩ２とＰＳＦＣＨとの他の多重方法について開示する。周波数分割多重を用いるとよい。ＵＥ１が受信可能なシンボルの周波数領域を用いて、多重を行うと良い。ＵＥ１が受信可能なシンボルにおいて、ＰＩ２をマッピングする周波数領域（たとえばＰＲＢ）と、ＰＳＦＣＨをマッピングする周波数領域（たとえばＰＲＢ）とを異ならせる。このようにすることで、ＵＥ１はＰＩ２とＰＳＦＣＨとを受信可能となる。
【０４７１】
ＰＩ２とＰＳＦＣＨとの他の多重方法について開示する。コード分割多重を用いるとよい。ＵＥ１が受信可能なシンボルにおいて、スクランブリングコードやＺＣシーケンスを用いて多重すると良い。ＵＥ１が受信可能なシンボルにおいて、ＰＩ２に乗じるスクランブリングコードと、ＰＳＦＣＨに乗じるスクランブリングコードとを異ならせる。このようにすることで、ＵＥ１はＰＩ２とＰＳＦＣＨとを受信可能となる。ＺＣシーケンスのＣＳ（Cyclic Shift）を用いて多重を行ってもよい。同様に効果を得られる。
【０４７２】
ＰＩ２をＰＳＦＣＨに含ませてもよい。たとえば、ＨＡＲＱフィードバック情報とＰＩ２の情報とをＰＳＦＣＨに含ませると良い。たとえば、ＳＬフィードバック制御情報（SFCI（Sidelink Feedback Control information））を設けて、該情報をＰＳＦＣＨにマッピングする。ＳＦＣＩにＨＡＲＱフィードバック情報とＰＩ２の情報とを含ませると良い。
【０４７３】
ＰＩ２をＰＳＦＣＨに含ませて、該ＰＳＦＣＨを他のＵＥからのＰＳＦＣＨと多重してもよい。多重方法は前述の方法を適用するとよい。このようにすることで、ＵＥ１はＰＩ２とＰＳＦＣＨとを受信可能となる。
【０４７４】
このようなプリエンプション方法とすることで、プリエンプトされる通信の送信ＵＥとプリエンプトする通信の送信ＵＥとが異なる場合でも、ＳＬ通信においてプリエンプションを可能にする。低遅延特性が要求される通信のために、既にアロケーションあるいはリザベーションされたリソースをプリエンプトすることが可能となる。これにより低遅延特性の要求を満足させることが可能となる。
【０４７５】
プリエンプトされたリソースのＵＥ１での送信処理およびＵＥ２での受信処理については、実施の形態４で開示した方法を適宜適用すると良い。たとえば、図２４の例で開示した方法を適宜適用すると良い。同様の効果を得ることが可能となる。また、ＵＥ２に対してプリエンプトされたリソースのデータの処理についても実施の形態４で開示した方法を適宜適用すると良い。たとえば、図２４の例で開示した方法を適宜適用すると良い。同様の効果を得ることが可能となる。
【０４７６】
ＵＥ１からＵＥ２に対してリザベーションあるいはスケジューリングしている１番目のスロットをプリエンプトする場合の処理については、実施の形態４で開示した方法を適宜適用すると良い。たとえば、図２４の例で開示した方法を適宜適用すると良い。同様の効果を得ることが可能となる。
【０４７７】
図３０は、ＳＬ通信におけるプリエンプション方法の第２例を示す図である。図３０は、図２９と異なり、プリエンプトするリソースを含む３つのスロットが連続してスケジューリングされている場合におけるプリエンプション方法を例示している。連続する３つのスロットでＰＳＣＣＨ、ＰＳＳＣＨ、ＧＡＰ、ＰＳＦＣＨがマッピングされる。ＰＳＣＣＨは連続する３つのスロットの最初のスロットにマッピングされる。
【０４７８】
従来、ＧＡＰ、ＰＳＦＣＨは、連続する３つのスロットの最後のスロットにマッピングされる。本変形例１では、各スロットに受信用のシンボルをマッピングする。ここでは、受信用のシンボルにＰＳＦＣＨをマッピングしている。
【０４７９】
ＵＥ３は、プリエンプトする２番目のスロットの直前のスロット（すなわち１番目のスロット）における、ＵＥ１が受信可能なシンボルで、ＰＩ２を送信する。ここでは、ＵＥ３はＰＩ２を、ＰＳＦＣＨに含めて、ＵＥ１が受信可能なシンボルで送信する。
【０４８０】
このようにすることで、ＵＥ１は、プリエンプトされる２番目のスロットより前で、ＰＩ２を受信することができる。ＰＩ２を受信したＵＥ１は、プリエンプトされたリソースを認識可能となる。このため、ＵＥ１は、プリエンプトされたリソースで、たとえば送信を停止することができる。ここでは、プリエンプトされた２番目のスロットで、ＵＥ１は送信停止する。このようにすることで、ＵＥ１は、プリエンプトされる２番目のスロットで、ＵＥ３からＵＥ４への通信に干渉を与えないようにすることができる。
【０４８１】
図２９の例では、プリエンプトされる２番目のスロットのＰＳＣＣＨに、ＵＥ３からＵＥ４に対するＰＳＳＣＨのリソースアロケーション情報などのスケジューリング情報と、ＵＥ３からＵＥ２に対するＰＩとを含めた。図３０の例では、ＵＥ１からＵＥ２に対して、連続する３つのスロットを用いてスケジューリングするので、２番目のスロットでＰＳＣＣＨは送信されない。したがって、ＵＥ２は２番目のスロットのＰＳＣＣＨを受信しない。２番目のスロットのＰＳＣＣＨでＰＩを送信したとしても、ＵＥ２はＰＩを受信しないことになる。
【０４８２】
このような問題を解決するため、本変形例１では、ＵＥ３が、ＰＩを、連続してスケジューリングしたスロットの次のスロットのＰＳＣＣＨに含めて送信する。ＵＥ２は、連続してスケジューリングされたスロットの次のスロットのＰＳＣＣＨを受信する。これにより、ＵＥ２は、ＰＳＣＣＨにＰＩが含まれているか否かを判断可能となる。したがって、ＵＥ２は、リソースがプリエンプトされているか否かを判断することができる。
【０４８３】
ＵＥ２は、スケジューリングされた連続スロットにおいてリソースがプリエンプトされているかを判断するまで、受信したデータを保持しておくと良い。リソースがプリエンプトされている場合、ＵＥ２は、プリエンプトされたリソースを除外して、データを受信する。リソースがプリエンプトされていない場合は、ＵＥ２は連続する３スロットからデータを受信する。このようにすることで、ＵＥ２が、プリエンプトされたデータを誤受信することを回避することができる。
【０４８４】
２番目のスロットのＰＳＣＣＨは、ＵＥ３からＵＥ４に対して送信され、該ＰＳＣＣＨにはＰＩを含めない。ＵＥ４は、２番目のスロットのＰＳＣＣＨを受信することで、ＰＳＳＣＨのスケジューリング情報を取得し、ＰＳＳＣＨを受信可能となる。
【０４８５】
プリエンプトされたリソースのＵＥ１での送信処理およびＵＥ２での受信処理については、実施の形態４で開示した方法を適宜適用すると良い。たとえば、図２５の例で開示した方法を適宜適用すると良い。同様の効果を得ることが可能となる。また、ＵＥ２に対してプリエンプトされたリソースのデータの処理についても実施の形態４で開示した方法を適宜適用すると良い。たとえば、図２５の例で開示した方法を適宜適用すると良い。同様の効果を得ることが可能となる。
【０４８６】
ＵＥ１からＵＥ２に対してリザベーションあるいはスケジューリングしている１番目のスロットをプリエンプトする場合の処理については、実施の形態４で開示した方法を適宜適用すると良い。たとえば、図２５の例で開示した方法を適宜適用すると良い。同様の効果を得ることが可能となる。
【０４８７】
このようなプリエンプション方法とすることで、ＳＬ通信において、連続した複数スロットでスケジューリングが行われたとしても、プリエンプションを可能にする。
【０４８８】
図３１は、ＳＬ通信におけるプリエンプション方法の第３例を示す図である。図３１は、図３０と同様に、プリエンプトするリソースを含む３つのスロットが連続してスケジューリングされている場合におけるプリエンプション方法を例示している。図３１は、図３０と異なり、プリエンプトするリソースがミニスロットの場合について示している。
【０４８９】
プリエンプトするリソースがミニスロットの場合も、図３０で開示した方法と同様に、ＵＥ３は、ＰＩを、連続してスケジューリングされたスロットの次のスロットのＰＳＣＣＨに含めて送信する。ＵＥ２は、連続してスケジューリングされたスロットの次のスロットのＰＳＣＣＨを受信する。これにより、ＵＥ２はＰＳＣＣＨにＰＩが含まれているか否かを判断可能となる。したがって、ＵＥ２は、リソースがプリエンプトされているか否かを判断することができる。
【０４９０】
２番目のスロット内にプリエンプトするミニスロットのＰＳＣＣＨは、ＵＥ３からＵＥ４に対して送信され、該ＰＳＣＣＨにはＰＩを含めない。ＵＥ４は、ミニスロットのＰＳＣＣＨを受信することで、ＰＳＳＣＨのスケジューリング情報を取得し、ＰＳＳＣＨを受信可能となる。
【０４９１】
ＵＥ１がＰＩ２を受信した後に、ＵＥ１がＵＥ２に対してＰＳＣＣＨでＰＩを送信してもよい。ＵＥ１は、ＰＩ２を受信することにより、プリエンプトされたリソースを認識することができる。このため、ＵＥ１がＵＥ２に対してＰＩを送信することが可能となる。
【０４９２】
たとえば、ＵＥ１がＰＩ２を受信した後に、ＵＥ１は、ＵＥ２に対して連続してスケジューリングしたスロットの次のスロットのＰＳＣＣＨに、ＰＩを含めて送信する。該スロットのＰＳＣＣＨには、ＰＩがどのＵＥから送信されたかを示す情報、たとえばＵＥの識別子などを含めてもよい。ＰＩに含まれる情報を該スロットのＰＳＣＣＨに含めてもよい。これにより、ＵＥ２はどのＵＥからＰＩが送信されたかを認識可能となる。
【０４９３】
プリエンプトされたリソースのＵＥ１での送信処理およびＵＥ２での受信処理については、実施の形態４で開示した方法を適宜適用すると良い。たとえば、図２６の例で開示した方法を適宜適用すると良い。同様の効果を得ることが可能となる。また、ＵＥ２に対してプリエンプトされたリソースのデータの処理についても実施の形態４で開示した方法を適宜適用すると良い。たとえば、図２６の例で開示した方法を適宜適用すると良い。同様の効果を得ることが可能となる。
【０４９４】
ＵＥ１からＵＥ２に対してリザベーションあるいはスケジューリングしている１番目のスロットのＰＳＣＣＨ領域を含むリソースをミニスロットでプリエンプトする場合の処理については、実施の形態４で開示した方法を適宜適用すると良い。たとえば、図２６の例で開示した方法を適宜適用すると良い。同様の効果を得ることが可能となる。
【０４９５】
実施の形態４で開示したＳＬ通信におけるプリエンプション方法の他の例を、適宜適用してもよい。たとえば、ＰＩ送信用のリソースを設ける方法を適宜適用してもよい。実施の形態４ではＵＥ１がＵＥ２に対してＰＩを送信するが、本変形例１では、ＵＥ３がＵＥ２に対してＰＩを送信する。ＵＥ３がＰＩ送信用リソース構成を認識する必要がある。このため、ｇＮＢがＰＩ送信用リソース構成を、ＳＬ通信を行うＵＥに、ＳＩＢで通知してもよい。あるいは、ｇＮＢが、ＰＩ送信用リソース構成を決定し、ＳＬ通信の送信ＵＥにＲＲＣシグナリングで通知してもよい。これらの方法を適用することで、ＵＥ３はＰＩ送信用リソース構成を認識することが可能となる。
【０４９６】
他の方法として、ＵＥ１がＵＥ３に対してＰＩ送信用リソース構成を通知してもよい。たとえば、ＵＥ１はＲＲＣシグナリング、ＭＡＣシグナリングで、ＵＥ３に、ＰＩ送信用リソース構成を通知する。あるいは、ＵＥ１はＰＳＣＣＨでＰＩ送信用リソース構成を通知してもよい。ＵＥ３は、ＰＳＣＣＨを受信することで、ＰＩ送信用リソース構成を認識可能となる。これにより、ＵＥ３がＵＥ２に対してＰＩを送信可能となる。
【０４９７】
前述の図の例では、ＵＥ１からＵＥ２に対してリソースのリザベーションが周期的に行われる場合について開示した。本変形例１で開示したような方法は、ＵＥ１からＵＥ２に対してリソースのリザベーションあるいはスケジューリングが周期的に行われる場合でなくてもよく、たとえば、ＵＥ１からＵＥ２に対してリソースのリザベーションあるいはスケジューリングが非周期的に行われる場合に適用してもよい。本変形例１で開示したような方法は、ＵＥ１からＵＥ２に対してリソースのリザベーションあるいはスケジューリングがダイナミックに行われる場合に適用してもよい。同様の効果を得ることが可能となる。
【０４９８】
ＳＬ通信においてサービスに関する情報をＰＳＣＣＨに含めるとよい。ＳＬ通信における送信ＵＥは、サービスに関する情報をＰＳＣＣＨに含めて送信する。ＳＬ通信における送信ＵＥは、サービスに関する情報をＳＣＩに含めてＰＳＣＣＨで送信してもよい。ＳＬ通信における送信ＵＥは、サービスに関する情報をＳＣＩ１に含めてＰＳＣＣＨで送信してもよい。このようにすることで、ＳＬ通信におけるＵＥは、ＰＳＣＣＨを受信することで、サービスに関する情報を取得可能となる。
【０４９９】
プリエンプション可能か否かの判断は、プリエンプトする通信における送信ＵＥが行うとよい。該送信ＵＥは、他のＵＥの通信のためにリザベーションあるいはスケジューリングしたリソースを、自ＵＥのサービスの通信のためにプリエンプトすることが可能か否かを判断する。該判断に、サービスに関する情報を用いてもよい。
【０５００】
該送信ＵＥは、他のＵＥの通信のためにリザベーションあるいはスケジューリングしたリソースのＰＳＣＣＨを受信して、サービスに関する情報を取得する。該送信ＵＥは、プリエンプトするリソースより前のリソースのＰＳＣＣＨを受信して、サービスに関する情報を取得してもよい。該送信ＵＥは、他のＵＥのサービスに関する情報と、自ＵＥのサービスに関する情報とを比較し、プリエンプトすることが可能か否かを判断する。サービスに関する情報によるプリエンプト可能か否かの判断方法は、実施の形態４で開示した方法を適用するとよい。
【０５０１】
他の方法として、サービスに関する情報として、プリエンプト可能か否かの情報を設けてもよい。たとえば、最も低遅延特性が要求されるようなサービスに対して、サービスに関する情報として、プリエンプト可能であることを示す情報を含める。プリエンプト可能であることを示す情報が設定されたＵＥは、他のＵＥの通信のためにリザベーションあるいはスケジューリングしたリソースをプリエンプト可能とする。
【０５０２】
このようにすることで、ＳＬにおいて、たとえば、より低遅延特性が要求されるなど、プリエンプションが必要なサービスの通信のために、ＳＬにおけるプリエンプションを可能にする。
【０５０３】
本変形例１で開示したような方法とすることで、プリエンプトされる通信の送信ＵＥとプリエンプトする通信の送信ＵＥが異なる場合においても、ＳＬにおけるプリエンプションを可能にする。このため、プリエンプトする通信の受信ＵＥは早期にデータを受信可能となる。低遅延特性が要求されるサービスのＳＬ通信においてプリエンプションを実施することで、通信に要求される低遅延特性を満足させることが可能となる。
【０５０４】
実施の形態５．
ＳＬ通信用のリソースはリソースプール（以降、ＳＬＲＰと称する）として設定される。ＳＬＲＰは、ＵＥにあらかじめ設定される。あるいは、ｇＮＢがＳＩＢあるいはＲＲＣシグナリングでＵＥにＳＬＲＰを通知する。
【０５０５】
図３２はＵｕのＵＬ用キャリアにＳＬＲＰが設定された場合を示す図である。スロット単位でリソースを示している。網掛けハッチングの部分がＵｕのＵＬ通信に用いられるリソースであり、横線ハッチングの部分がＳＬ通信に用いられるＳＬＲＰである。ＵｕのＵＬで設定されるＢＷＰ（BandWidth Part）の範囲内にＳＬＲＰが設定される。ＳＬＲＰはＳＬ  ＢＷＰの範囲内に設定される。図３２ではＳＬＲＰの周波数範囲とＳＬ  ＢＷＰの周波数範囲を同じにしている。
【０５０６】
このような場合、ＵｕのＵＬ通信とＳＬ通信との間でのプリエンプションが考えられる。しかし、ＵｕのＵＬ通信とＳＬ通信との間でのプリエンプションについてはなんら開示されていない。ここでは、ＵｕのＵＬ通信とＳＬ通信との間でのプリエンプションをどのように扱うかについて開示する。
【０５０７】
ＵｕのＵＬ通信に用いられるリソースを、ＳＬ通信用にプリエンプトしない。ＵｕのＵＬ通信に用いられるリソースを、ＳＬ通信用にプリエンプトすることを禁止する、あるいは、許可しないとしてもよい。ＳＬＲＰ外のリソースを、ＳＬ通信用にプリエンプトしない。ＳＬＲＰ外のリソースを、ＳＬ通信用にプリエンプトすることを禁止する、あるいは、許可しないとしてもよい。
【０５０８】
ＳＬＲＰ内のリソースを、ＵｕのＵＬ通信用にプリエンプトしない。ＳＬＲＰ内のリソースを、ＵｕのＵＬ通信用にプリエンプトすることを禁止する、あるいは、許可しないとしてもよい。ＵｕのＵＬ通信用リソース外のリソースを、ＵｕのＵＬ通信用にプリエンプトしない。ＵｕのＵＬ通信用リソース外のリソースを、ＵｕのＵＬ通信用にプリエンプトすることを禁止する、あるいは、許可しないとしてもよい。
【０５０９】
これらの設定はサービス毎に設定されてもよい。また、一方の設定のみが行われてもよい。
【０５１０】
このようにすることで、ＵｕのＵＬ通信用リソースでＳＬの通信は行われなくなる。また、ＳＬＲＰでＵｕの通信は行われなくなる。通信用のリソースがＵｕのＵＬ通信とＳＬ通信とで分別されることにより、たとえば、同一キャリア上でＵｕのＵＬ通信とＳＬ通信とが実施されるような場合にも、ＵｕのＵＬ通信とＳＬ通信とを容易に多重することができる。これにより、ＮＷ側、端末側ともに、各々の通信処理を簡易にすることができる。
【０５１１】
しかし、ＳＬにおいて低遅延特性が要求されるデータが生じた場合、そのようなデータをＳＬＲＰ外では送信できずに、ＳＬＲＰのタイミングまで待たなければならない場合が生じる。このため、低遅延の要求を満たせなくなる場合が生じる。また、逆の場合も同様である。ＵｕのＵＬにおいて低遅延特性が要求されるデータが生じた場合、そのようなデータをＳＬＲＰでは送信できずに、ＵｕのＵＬ用のリソースタイミングまで待たなければならない場合が生じる。このため、低遅延の要求を満たせなくなる場合が生じる。このような課題を解決する方法を開示する。
【０５１２】
このような課題を解決するため、ＵｕのＵＬ通信とＳＬ通信との間でのプリエンプションを実施してもよい。ＵｕのＵＬ通信に用いられるリソースを、ＳＬ通信用にプリエンプトしてもよい。ＵｕのＵＬ通信に用いられるリソースを、ＳＬ通信用にプリエンプトすることを許可してもよい。ＳＬＲＰ外のリソースを、ＳＬ通信用にプリエンプトしてもよい。ＳＬＲＰ外のリソースを、ＳＬ通信用にプリエンプトすることを許可してもよい。
【０５１３】
プリエンプトされるＵｕのＵＬ通信用リソースは、ＳＬＲＰが含まれるＢＷＰ内に限定してもよい。プリエンプションされるＵｕのＵＬ用リソースは、ＳＬＲＰと同じスロット内に限定してもよい。
【０５１４】
他の方法として、ＵｕのＵＬ用リソースに、ＳＬ通信のプリエンプション用リソースプールを設けてもよい。ＳＬ通信のＵＥに対して、ＳＬプリエンプション用のＲＰが設定される。ＳＬ通信の受信ＵＥは、設定されたＳＬプリエンプション用のＲＰの構成を用いて、ＳＬＲＰだけでなく、ＳＬプリエンプション用のＲＰも受信する。ＳＬ通信の送信ＵＥは、ＳＬＲＰだけでなく、設定されたＳＬプリエンプション用のＲＰの構成を用いて、ＳＬプリエンプション用のＲＰでも送信可能とする。
【０５１５】
図３３はＵｕのＵＬ用リソースに対してＳＬ通信用にプリエンプションを許可した場合を示す図である。スロット単位でリソースを示している。砂状ハッチングの部分がＳＬ通信用にプリエンプトしたリソースである。該プリエンプションにはＵｕのＵＬ用リソースが用いられる。ＳＬ通信用にプリエンプトするリソースは、ＳＬＲＰが含まれるＢＷＰ内に設定している。
【０５１６】
このようにすることで、ＳＬにおいて低遅延特性が要求されるデータが生じた場合、ＵｕのＵＬ用リソースをＳＬ通信用にプリエンプトすることで、ＳＬ通信を行うことが可能となる。特に、次のＳＬＲＰのタイミングまで間隔があくような場合も、それを待たずに、ＳＬ通信を行うことが可能となる。このため、低遅延特性を得ることが可能となる。
【０５１７】
ＳＬＲＰ内のリソースを、ＵｕのＵＬ通信用にプリエンプトしてもよい。ＳＬＲＰ内のリソースを、ＵｕのＵＬ通信用にプリエンプトすることを許可してもよい。ＵｕのＵＬ通信用リソース外のリソースを、ＵｕのＵＬ通信用にプリエンプトしてもよい。ＵｕのＵＬ通信用リソース外のリソースを、ＵｕのＵＬ通信用にプリエンプトすることを許可してもよい。
【０５１８】
プリエンプトされるＳＬ通信用リソースは、ＵｕのＵＬ通信用リソースが含まれるＢＷＰ内に限定してもよい。プリエンプションされるＳＬ通信用リソースは、ＵｕのＵＬ通信用リソースと同じスロット内に限定してもよい。
【０５１９】
図３４はＳＬＲＰ内のリソースに対してＵｕのＵＬ通信用にプリエンプションを許可した場合を示す図である。スロット単位でリソースを示している。斜線ハッチングの部分がＵｕのＵＬ通信用にプリエンプトしたリソースである。該プリエンプションにはＳＬ通信用リソースが用いられる。ＵｕのＵＬ通信用にプリエンプトするリソースは、ＵｕのＵＬ通信用ＢＷＰ内に設定している。
【０５２０】
このようにすることで、ＵｕのＵＬにおいて低遅延特性が要求されるデータが生じた場合、ＳＬ通信用のリソースをＵｕのＵＬ通信にプリエンプトすることで、ＵｕのＵＬ通信を行うことが可能となる。特に、次のＵｕのＵＬ通信用リソースのタイミングまで間隔があくような場合も、それを待たずに、ＵｕのＵＬ通信を行うことが可能となる。ＵｕのＵＬ通信用リソースの使用負荷が高い場合にも、ＳＬ通信用リソースをプリエンプトすることが可能となる。このため、低遅延特性を得ることが可能となる。
【０５２１】
実施の形態６．
ＮＲにおいてＳＬでＢＷＰが用いられることが合意されている（非特許文献２９（Draft Report of 3GPP TSG RAN WG1 #95 v0.2.0(Spokane, USA, 12th-16h November 2018)））。ＳＬの各リソースプール（RP）は一つのＳＬＢＷＰの範囲内に（予め）構成される。図３５は同じキャリア内に２つのＳＬＲＰとＳＬＢＷＰとが構成された場合を示す図である。各ＳＬＢＷＰの周波数範囲内で各ＳＬＲＰが設定される。しかし、ＳＬＢＷＰの具体的な設定方法についてはなんら開示されていない。本実施の形態６では、ＳＬＢＷＰの設定方法について開示する。
【０５２２】
ＳＬＢＷＰは、ＵｕのＵＬのＢＷＰとは別とする。ＳＬＢＷＰは、ＵｕのＵＬで設定されるＢＷＰとは別に設定される。このようにすることで、ＵｕのＵＬのＢＷＰとは異なる周波数帯域で、ＳＬＲＰを設けることが可能となる。ＵｕのＵＬのＢＷＰとは異なる周波数帯域で、ＳＬ通信が可能となる。
【０５２３】
ＳＬＲＰ設定の周波数範囲をＳＬＢＷＰとしてもよい。Ｕｕの通信において、ＢＷＰの設定は、ＵＥに通信可能な周波数範囲を限定するために用いられる。ＳＬにおいても、ＳＬＢＷＰの設定を、ＳＬＲＰ設定の周波数範囲とすることで、ＵＥの通信可能な周波数範囲を、ＳＬＲＰの周波数範囲より広い周波数範囲とする必要が無くなる。ＳＬ通信を行うＵＥの構成を容易にできる。
【０５２４】
一つのＳＬＢＷＰの範囲内に、複数のＳＬＲＰが設定される場合は、該複数のＳＬＲＰの周波数範囲を含む最小の周波数範囲をＳＬＢＷＰとしてもよい。同様に、ＵＥの通信可能な周波数範囲を、設定された複数のＳＬＲＰの周波数範囲を含む最小の周波数範囲より広い周波数範囲とする必要が無くなる。ＳＬ通信を行うＵＥの構成を容易にできる。
【０５２５】
ＵＥへのＳＬＢＷＰの通知方法を開示する。ＵＥに対するＳＬＲＰの設定とＳＬＢＷＰの設定とを別々に行ってもよい。前述のように、ＳＬＲＰの設定は、ＵＥにあらかじめ設定される。あるいは、ｇＮＢがＳＩＢあるいはＲＲＣシグナリングでＵＥにＳＬＲＰの設定を通知する。同様に、ＳＬＢＷＰの設定も、ＵＥにあらかじめ設定される。あるいは、ｇＮＢがＳＩＢあるいはＲＲＣシグナリングでＵＥにＳＬＢＷＰの設定を通知する。ＳＬＢＷＰの設定はＵｕのＵＬのＢＷＰの設定に含めて通知されてもよい。ＵＥに対するＳＬＲＰの設定とＳＬＢＷＰの設定とが個別に行われる場合、どのＳＬＲＰがどのＳＬＢＷＰに対応するかを関連付ける必要がある。
【０５２６】
ＳＬＲＰを特定するためのＳＬＲＰ識別子を設ける。ＳＬＲＰ識別子をＳＬＢＷＰの設定のための情報に含ませるとよい。設定するＳＬＢＷＰに対応するＳＬＲＰのＳＬＲＰ識別子を、該ＳＬＢＷＰの設定のための情報に含ませる。このようにすることで、ＵＥは、ＳＬＲＰとＳＬＢＷＰとの対応を認識することが可能となる。また、ＳＬＲＰとＳＬＢＷＰの設定を個別に柔軟に変更可能となる。変更のためのＳＩＢあるいはＲＲＣシグナリング内の情報量を削減可能となる。
【０５２７】
ＵＥに対するＳＬＢＷＰの設定をＳＬＲＰの設定に含めてもよい。たとえば、設定するＳＬＲＰに、ＳＬＢＷＰの設定のための情報を関連付けることによって、ＳＬＢＷＰの設定をＳＬＲＰの設定に含ませるとよい。このようにすることで、ＵＥに対して設定するシグナリング量を低減可能となる。
【０５２８】
ＳＬＢＷＰの設定のための情報として、ニュメロロジの情報を含めてもよい。ＵＥは、ＳＬＢＷＰのリソースのニュメロロジを認識可能となる。ＳＬＲＰのニュメロロジは、対応するＳＬＢＷＰのニュメロロジとするとよい。ＵＥは、ＳＬＲＰのニュメロロジも認識可能となる。
【０５２９】
ＵＥは、自ＵＥのＳＬ通信可能な周波数範囲に関する情報を、ｇＮＢに通知してもよい。ＵＥのケーパビリティに、該周波数範囲に関する情報を含めてもよい。ＵＥはｇＮＢに対してＵＥケーパビリティを通知してもよい。ｇＮＢは、ＵＥのＳＬ通信可能な周波数範囲に関する情報を用いて、ＵＥに対してＳＬＢＷＰの設定を行う。ｇＮＢはＵＥに対してＳＬＢＷＰの設定を通知する。このようにすることで、ＵＥは、自ＵＥの能力を超えた周波数範囲で通信を行わなくて済む。ＵＥでの誤動作の発生や通信断の発生を低減可能となる。
【０５３０】
ＵＥは、自ＵＥのＳＬ通信可能な周波数範囲に関する情報を、ＳＬ通信における送信ＵＥに通知してもよい。ＵＥのケーパビリティ情報に、周波数範囲に関する情報を含めてもよい。ＳＬ通信のＵＥ間でＵＥケーパビリティを通知してもよい。送信ＵＥは、受信ＵＥのＳＬ通信可能な周波数範囲に関する情報を用いて、ＳＬＢＷＰの設定を行う。たとえば、送信ＵＥは、ＰＳＣＣＨで他のＳＬＢＷＰの設定を行ってもよい。送信ＵＥは、他のＳＬＢＷＰとＳＬＲＰの設定を通知してもよい。このようにすることで、送信ＵＥは、受信ＵＥの能力を超えた周波数範囲で通信を行わなくて済む。ＵＥ間での誤動作の発生や通信断の発生を低減可能となる。
【０５３１】
ＳＬ通信を行うＵＥは、予め設定された周波数範囲で通信を可能としておく、としてもよい。該予め設定された周波数範囲をデフォルトのＳＬＢＷＰとしてもよい。ＵＥ個別にＢＷＰが設定されない限り、デフォルトのＳＬＢＷＰが設定されるとしてもよい。ＳＬＲＰはデフォルトのＳＬＢＷＰの周波数範囲内で設定される。このようにすることで、ＵＥ個別の設定が不要な場合、ＵＥへのシグナリングを省くことができる。また、ＵＥが、セルのカバレッジ外に存在してｇＮＢからＳＬＢＷＰを受信できないような場合にも、デフォルトのＳＬＢＷＰを用いることが可能となる。
【０５３２】
サービス毎にＳＬＢＷＰを設定してもよい。サービス毎のＳＬＢＷＰの周波数範囲内でＳＬＲＰが設定される。あるいは、ＱＣＩ毎にＳＬＢＷＰを設定してもよい。ＱＣＩ毎のＳＬＢＷＰの周波数範囲内でＳＬＲＰが設定される。ＱＣＩではなく、ＳＬで用いられるＱｏＳ指標を用いてもよい。ＳＬＢＷＰは、デフォルトのＳＬＢＷＰであってもよいし、ＵＥ個別に設定するＳＬＢＷＰであってもよい。このようにすることで、サービス毎に適したＳＬＲＰの設定を可能とする。
【０５３３】
本実施の形態６で開示したようなＳＬＢＷＰの設定方法とすることで、ＳＬＢＷＰの設定をＵＥが認識可能となり、ＳＬ通信においてＢＷＰの運用が可能となる。ＵＥはＳＬ通信において、ＳＬＢＷＰの範囲内で通信可能であればよい。また、ｇＮＢはＵＥのＳＬ通信可能な能力に応じてＳＬＢＷＰを設定可能となり、ＳＬＢＷＰの範囲内でＳＬＲＰの設定を可能とする。
【０５３４】
実施の形態７．
ＮＲにおいてＵｕでＳＵＬ（Supplementary UpLink）を運用することがサポートされている（非特許文献１６（ＴＳ３８．３００））。Ｕｕにおいては、ＳＵＬはセル毎に設定され、非ＳＵＬとＳＵＬは同一セルに構成される。また、ｇＮＢはＵＥに対してＳＵＬをＰＤＣＣＨでダイナミックに設定可能である。ダイナミックなＳＵＬの設定は、ＵＥ毎にスロット毎に行われる。
【０５３５】
ＳＬ通信においてＳＵＬを設ける。ＳＵＬを用いてＳＬ通信を行ってもよい。通常のＵＬ、すなわち非ＳＵＬで行われるＳＬ通信の通信品質が劣化するような場合、ＳＵＬを用いることで通信品質を向上させることができる。
【０５３６】
図３６は、ＳＬにおいて非ＳＵＬに加えてＳＵＬをサポートすることを示す概念図である。ＵｕのＵＬにおいて、非ＳＵＬとＳＵＬがサポートされている。送信ＵＥはｇＮＢに対して、非ＳＵＬだけでなくＳＵＬを用いて送信を行うことができる。ＳＬ通信においても非ＳＵＬに加えてＳＵＬがサポートされる。ＳＬ通信の送信ＵＥは受信ＵＥに対して非ＳＵＬだけでなくＳＵＬを用いて送信を行うことができる。
【０５３７】
ＳＬのＳＵＬは、Ｕｕで設定されているＳＵＬと同じとしてもよい。このようにすることで、ＳＬ用のＳＵＬを別途設ける必要が無くなり、ＵＥが複数のＳＵＬで通信を行う必要が無くなる。そのため、ＵＥでの処理を簡略化できる。
【０５３８】
ＳＬのＳＵＬは、Ｕｕで設定されているＳＵＬと異なってもよい。ＳＬにおけるＳＵＬを設定し、該ＳＵＬを用いてＳＬ通信を行ってもよい。このようにすることで、ＳＬ用のＳＵＬをＵｕのＳＵＬと関係なく別途設けることができる。ＳＬでのＳＵＬを柔軟に設定可能となる。たとえば、ＳＬ通信の通信品質に応じてＳＵＬの設定を行うことが可能となる。ＳＬ通信の通信品質を向上させることができる。
【０５３９】
ＳＵＬでのＳＬＲＰ構成を、非ＳＵＬでのＳＬＲＰ構成と同じとしてもよい。このようにすることで、たとえば、ＳＵＬおよび非ＳＵＬで、ＳＬ通信のためのリソースアロケーションを同じにすることができる。
【０５４０】
ＳＵＬでのＳＬＲＰ構成を、非ＳＵＬでのＳＬＲＰ構成と異ならせてもよい。このようにすることで、ＳＵＬでのＳＬＲＰ構成を、ＳＵＬにおける通信負荷に適した設定とすることが可能となる。
【０５４１】
ＳＵＬと非ＳＵＬとでニュメロロジは同じとしてもよい。このようにすることで、たとえば、ＳＬＲＰのタイミングを同じとすることができる。あるいは、ＳＵＬと非ＳＵＬとでニュメロロジを異ならせてもよい。このようにすることで、ＳＵＬと非ＳＵＬの各キャリア周波数に適したニュメロロジとすることができる。
【０５４２】
ＳＵＬでのＳＬＲＰの時間領域の構成を、非ＳＵＬでのＳＬＲＰの時間領域の構成と同じとしてもよい。ＳＬＲＰの設定は、シンボル単位あるいは１／ｎシンボル単位で行ってもよい。このようにすることで、ニュメロロジが異なるような場合にも、時間領域の構成を同じとすることができる。
【０５４３】
時間領域の構成を同じにすることで、たとえば、後述する、送信ＵＥが非ＳＵＬ上のＰＳＣＣＨでＳＵＬ上のＰＳＳＣＨをスケジューリングするような場合に有効となる。非ＳＵＬ上のＳＬＲＰとＳＵＬ上のＳＬＲＰとの時間領域の構成が同じため、非ＳＵＬ上のＰＳＳＣＨの時間領域のスケジューリング情報と、ＳＵＬ上のＰＳＳＣＨの時間領域のスケジューリング情報とを同じにすることができる。このため、ＳＵＬ上のＳＬＲＰを用いたスケジューリング制御を簡易にすることができる。
【０５４４】
ＳＵＬでのＳＬＲＰの時間領域の構成を、非ＳＵＬでのＳＬＲＰの時間領域の構成と異ならせてもよい。時間領域の構成を異ならせることで、送信ＵＥにおける非ＳＵＬでの送信とＳＵＬでの送信とが異なるタイミングになる。このため、ＵＥが送信可能な送信電力を非ＳＵＬでの送信とＳＵＬでの送信とに分配する必要が無くなり、各リンクでの受信品質を向上させることが可能となる。また、受信ＵＥは、非ＳＵＬのＳＬＲＰとＳＵＬのＳＬＲＰとを同時に受信する必要がなくなる。このため、受信ＵＥでの受信処理を簡易にすることができる。
【０５４５】
図３７は、非ＳＵＬとＳＵＬとでニュメロロジを同じにした場合を示す図である。図３７の例では、非ＳＵＬのＳＬＲＰ構成とＳＵＬのＳＬＲＰ構成とを同じにしている。ただし、非ＳＵＬとＳＵＬとで周波数が異なるので、非ＳＵＬのＳＬＲＰの周波数とＳＵＬのＳＬＲＰの周波数とは異なる。図３７は、ＵｕのＵＬ用キャリアにＳＬＲＰが設定された場合を示している。スロット単位でリソースを示している。網掛けハッチングの部分がＵｕのＵＬ通信に用いられるリソースであり、横線ハッチングの部分がＳＬ通信に用いられるＳＬＲＰである。非ＳＵＬ、ＳＵＬともに、ＵｕのＵＬで設定されるＢＷＰの範囲内にＳＬＲＰが設定される。ＳＬＲＰはＳＬ  ＢＷＰの範囲内に設定される。図３７ではＳＬＲＰの周波数範囲とＳＬ  ＢＷＰの周波数範囲を同じにしている。
【０５４６】
図３８は、非ＳＵＬとＳＵＬとでニュメロロジを異ならせた場合を示す図である。図３８の例では、非ＳＵＬとＳＵＬとでＳＬＲＰの時間領域の構成を同じにした場合を示している。スロット単位でリソースを示している。ＳＵＬのシンボル間隔は非ＳＵＬのシンボル間隔の１／２としている。ＳＵＬのサブキャリア間隔（SCS（SubCarrier Spacing））は非ＳＵＬのサブキャリア間隔の２倍となる。ＳＬＲＰの設定を、ＳＵＬのニュメロロジにおける１／２シンボル単位で行う。このようにすることで、非ＳＵＬとＳＵＬとでニュメロロジが異なる場合も、ＳＬＲＰの時間領域の構成を同じにすることができる。
【０５４７】
ＳＬでのＳＵＬ（以降ＳＬ  ＳＵＬと称する場合がある）の設定方法について開示する。ＳＵＬは、ＵＥにあらかじめ設定されてもよい。あるいは、ｇＮＢがＳＩＢあるいはＲＲＣシグナリングでＵＥにＳＵＬの設定を通知してもよい。ＳＬでのＳＵＬに構成するＳＬＲＰの設定方法について開示する。一つのＳＵＬに一つまたは複数のＳＬＲＰが設定されてもよい。一つのＳＬＲＰ構成が一つまたは複数のＳＵＬで設定されてもよい。ＳＵＬと該ＳＵＬで構成されるＳＬＲＰとを関連づけて設定してもよい。ＳＵＬでのＳＬＲＰ構成は、ＵＥにあらかじめ設定されてもよい。あるいは、ｇＮＢがＳＩＢあるいはＲＲＣシグナリングでＵＥに、ＳＵＬでのＳＬＲＰ構成を通知してもよい。
【０５４８】
ＳＵＬの設定とＳＵＬでのＳＬＲＰの設定とは別々に行われてもよい。このような場合に、ＳＵＬを特定するための情報を設けてもよい。該情報はＳＵＬの識別子であってもよい。あるいは、該情報はＳＵＬのキャリア識別子であってもよい。ＳＵＬでのＳＬＲＰの設定のための情報として、関連付けるＳＵＬを特定するための情報を含ませるとよい。このようにすることで、たとえば、ＳＵＬの設定とＳＵＬでのＳＬＲＰの設定とが別々に行われたとしても、ＵＥが、どのＳＵＬでどのＳＬＲＰ構成を設定するかを認識可能となる。
【０５４９】
ＳＬＲＰを特定するための情報を設けてもよい。該情報はＳＬＲＰの識別子であってもよい。ＳＵＬの設定のための情報として、関連付けるＳＬＲＰを特定するための情報を含ませるとよい。このようにすることで、たとえば、ＳＵＬの設定とＳＵＬでのＳＬＲＰの設定とが別々に行われたとしても、ＵＥが、どのＳＵＬでどのＳＬＲＰ構成を設定するかを認識可能となる。
【０５５０】
Ｕｕでの通信とは異なり、ＳＬ通信はセルカバレッジの内外で行われる。ＳＬでのＳＵＬはセル毎に設定されなくてもよい。たとえば、トラッキングエリア（TA）内で同一のＳＵＬを設定してもよい。ＲＲＣ＿Ｉｄｌｅ状態のＵＥが、ＳＬ通信を行う際に、該ＳＵＬを用いることが可能となる。ＲＮＡ（RAN-based Notification Area）内で同一のＳＵＬを設定してもよい。ＲＲＣ＿ｉｎａｃｔｉｖｅ状態のＵＥが、ＳＬ通信を行う際に、該ＳＵＬを用いることが可能となる。
【０５５１】
ＳＬでのＳＵＬをセル毎に設定してもよい。ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態のＵＥが、ＳＬ通信を行う際に、該ＳＵＬを用いることが可能となる。ＳＬでのＳＵＬをＵｕでのＳＵＬと同じとしてもよい。このようにすることで、Ｕｕでの非ＳＵＬとＳＵＬと同じキャリア周波数で、ＳＬ通信を行うことが可能となる。ＵＥでのＳＬ通信処理を簡易にすることができる。
【０５５２】
ＳＬ  ＳＵＬでのスケジューリング方法を開示する。ｇＮＢがスケジューリングを行う場合について開示する。ＳＬ  ＳＵＬか否かを示す情報を設ける。ｇＮＢはＳＵＬか否かを示す情報を、ＤＣＩに含めて、ＳＬ通信における送信ＵＥに対して通知する。ｇＮＢはＳＬ  ＳＵＬの識別子を、ＤＣＩに含めて、送信ＵＥに対して通知してもよい。ｇＮＢはスケジューリング情報を、ＤＣＩに含めて、送信ＵＥに対して通知してもよい。ＳＬ通信における送信ＵＥは、これらの情報を用いることで、ＳＬ  ＳＵＬでＳＬ通信用のリソースを選択可能となる。送信ＵＥは、該リソースで、ＳＬ通信のためのＰＳＣＣＨ、ＰＳＳＣＨを送信する。
【０５５３】
ＵＥは、ＳＬ  ＳＵＬでの送信機能および／あるいは受信機能（以降、送受信機能と称する場合がある）を備える。ＵＥは、ＳＬ  ＳＵＬに関する情報をｇＮＢに通知してもよい。ＳＬ  ＳＵＬに関する情報は、ＳＬ  ＳＵＬでの送受信機能に関する情報を含むとよい。ＳＬ  ＳＵＬでの送受信機能に関する情報として、ＳＬ  ＳＵＬとして送信および／あるいは受信可能なキャリア周波数、帯域、ニュメロロジ、ＭＩＭＯ多重数などがある。
【０５５４】
ＵＥのケーパビリティに、ＳＬ  ＳＵＬに関する情報を含めてもよい。ＵＥはｇＮＢに対してＵＥケーパビリティを通知してもよい。ｇＮＢは、ＵＥのＳＬ  ＳＵＬに関する情報を用いて、ＵＥに対してＳＬ  ＳＵＬの設定を行う。ｇＮＢはＵＥに対してＳＬ  ＳＵＬの設定を通知する。このようにすることで、ＵＥは、自ＵＥの能力を超えたＳＬ  ＳＵＬで通信を行わなくて済む。ＵＥでの誤動作の発生や通信断の発生を低減可能となる。
【０５５５】
ＵＥは、自ＵＥのＳＬ  ＳＵＬに関する情報を、ＳＬ通信における送信ＵＥに通知してもよい。ＵＥのケーパビリティ情報に、ＳＬ  ＳＵＬに関する情報を含めてもよい。ＳＬ通信のＵＥ間でＵＥケーパビリティを通知してもよい。送信ＵＥは、受信ＵＥのＳＬ  ＳＵＬに関する情報を用いて、ＳＬ  ＳＵＬの設定を行う。たとえば、送信ＵＥは、ＰＳＣＣＨでＳＬ  ＳＵＬの設定を行ってもよい。送信ＵＥは、ＳＬ  ＳＵＬと該ＳＵＬ上のＳＬＲＰの設定を通知してもよい。このようにすることで、送信ＵＥは、受信ＵＥの能力を超えたＳＬ  ＳＵＬで通信を行わなくて済む。ＵＥ間での誤動作の発生や通信断の発生を低減可能となる。
【０５５６】
ＳＬ  ＳＵＬ上にＳＬＲＰが設定されたＵＥは、ＳＬ通信を受信する場合、ＳＬ  ＳＵＬ上のＳＬＲＰをサーチする。ＳＬ  ＳＵＬ上のＳＬＲＰのＰＳＣＣＨをＵＥが受信するとしてもよい。ＵＥは、ＳＬ  ＳＵＬ上でのＳＬＲＰの設定通知の受信により、ＳＬＲＰのサーチをアクティベーションする。ＵＥは、ＳＬ  ＳＵＬ上でのＳＬＲＰの開放設定通知の受信により、ＳＬＲＰのサーチをデアクティベーションする。
【０５５７】
ＳＬ  ＳＵＬのアクティベーションあるいはデアクティベーション（act/deact）を示す情報を設けてもよい。ＳＬ  ＳＵＬのａｃｔ/ｄａｃｔ情報を受信したＵＥは、ＳＬ  ＳＵＬでのＳＬＲＰのサーチをアクティベーションあるいはデアクティベーションする。ｇＮＢは、受信ＵＥに対して、ＲＲＣシグナリングでＳＬ  ＳＵＬのａｃｔ/ｄｅａｃｔ情報を通知してもよい。
【０５５８】
ＳＬ  ＳＵＬのａｃｔ／ｄｅａｃｔ情報の利用は、ＳＬでユニキャスト通信あるいはグループキャスト通信が行われる場合に限定してもよい。ＳＬでのユニキャスト通信あるいはグループキャスト通信では、ブロードキャスト通信と異なり、受信ＵＥが特定される。このため、ＳＬ  ＳＵＬのａｃｔ／ｄｅａｃｔ情報を、受信ＵＥに対して、ＲＲＣシグナリングで通知可能となる。ブロードキャスト通信の場合、ａｃｔ／ｄｅａｃｔ情報を、共通情報として、ＳＩＢあるいはＲＲＣシグナリングで通知してもよい。受信ＵＥを特定できない場合に有効となる。
【０５５９】
このように、ＳＬ  ＳＵＬのａｃｔ／ｄｅａｃｔ情報を設けて、受信ＵＥに対して通知することで、ＳＬ  ＳＵＬ上にＳＬＲＰの設定が行われてから該設定が開放されるまで、ＵＥがＳＬＳＵＬ上のＳＬＲＰをサーチし続けずに済む。ＵＥは、ＳＬ  ＳＵＬのａｃｔ情報の受信からｄｅａｃｔ情報の受信まで、ＳＬ  ＳＵＬ上のＳＬＲＰをサーチすれば良くなる。ＵＥの消費電力の低減をはかれる。
【０５６０】
図３９および図４０は、ＳＬ  ＳＵＬでＳＬ通信を行うためのシーケンスの一例を示す図である。図３９と図４０とは、境界線ＢＬ３９４０の位置で、つながっている。図３９および図４０は、ｇＮＢがＳＬ  ＳＵＬの設定とＳＬＲＰの設定を行う場合について示している。また、図３９および図４０は、ｇＮＢとＳＬ通信を行う送信ＵＥと受信ＵＥについて示している。ステップＳＴ５７０１で、ｇＮＢはＳＬ  ＳＵＬの設定を行う。ステップＳＴ５７０２で、ｇＮＢは非ＳＵＬ（nSUL）とＳＵＬでのＳＬＲＰを各々設定する。ステップＳＴ５７０３、ＳＴ５７０４で、ｇＮＢは、ＵＥに対して、ＳＵＬの設定、非ＳＵＬでのＳＬＲＰの設定、ＳＵＬでのＳＬＲＰの設定を通知する。たとえば、ｇＮＢはこれらの設定をＳＩＢに含めて報知する。ＳＬ通信を行う送信ＵＥ、受信ＵＥともにこれらの情報を受信できる。
【０５６１】
ステップＳＴ５７０６で、ＳＬ通信を受信するＵＥは、非ＳＵＬでのＳＬＲＰ内のＰＳＣＣＨを受信し、自ＵＥ向けのＰＳＣＣＨのサーチを開始する。図３９および図４０の例では、受信ＵＥは、ＳＵＬのＳＬＲＰ内のＰＳＣＣＨのサーチを開始しない。ステップＳＴ５７０５で、ＳＬ通信において送信するＵＥは、ｇＮＢに対して、非ＳＵＬ上でユニキャスト通信を実施するため、ＳＲ（Scheduling Request）を送信する。該ＵＥは、該ＳＲとともに、あるいはＳＲの情報として、たとえば、通信の対向となるＵＥ（受信ＵＥ）の識別子、ＳＬ通信のＢＳＲ、ＳＬで通信するサービスに関する情報を通知してもよい。サービスに関する情報は、ＱｏＳ情報、ＱＣＩ、ＰＰＰＰ、要求される遅延時間、要求されるスルーレート等であってもよい。
【０５６２】
ＳＲやこれらの情報は、送信ＵＥからｇＮＢに対して、ＵｕのＵＬを用いて通知される。ＳＲやこれらの情報は、送信ＵＥからｇＮＢに対して、ＰＵＣＣＨを用いて通知されてもよい。早期に通知可能となる。あるいは、ＭＡＣシグナリングあるいはＲＲＣシグナリングを用いてもよい。ＭＡＣシグナリングあるいはＲＲＣシグナリングではＨＡＲＱがサポートされるので、低誤り率で通知可能となる。
【０５６３】
ステップＳＴ５７０７で、ｇＮＢは非ＳＵＬでのＳＬ通信のためのスケジューリングを決定する。ステップＳＴ５７０８で、ｇＮＢは送信ＵＥに対して、非ＳＵＬでのＳＬ通信用スケジューリング情報を通知する。ステップＳＴ５７０９で、送信ＵＥは、受信したスケジューリング情報を用いて送信処理を実施する。ステップＳＴ５７１０で、送信ＵＥは受信ＵＥに対して、ｇＮＢから受信したスケジューリング情報を用いて、ＳＬでの送信を行う。送信ＵＥはＰＳＣＣＨ、ＰＳＳＣＨを送信する。
【０５６４】
送信ＵＥは、ＰＳＣＣＨに、ＳＬ通信を行う受信ＵＥの識別子を含めてもよい。このようにすることで、ステップＳＴ５７０６でＰＳＣＣＨのサーチを行っている受信ＵＥは、送信ＵＥからＰＳＣＣＨを受信し、該ＰＳＣＣＨが自ＵＥ向けであると判断可能となる。送信ＵＥからＰＳＣＣＨを受信した受信ＵＥは、ＰＳＣＣＨに含まれるＰＳＳＣＨのスケジューリング情報を用いて、ＰＳＳＣＨを受信する。これにより、受信ＵＥは送信ＵＥからのデータを受信可能となる。
【０５６５】
受信ＵＥは、該データの受信可否を送信ＵＥに送信してもよい。受信ＵＥはデータの受信可否を、ＨＡＲＱフィードバック情報（Ack/Nack）として送信してもよい。また、受信ＵＥは送信ＵＥに対して、チャネル状態情報（CSI）を送信してもよい。また、受信ＵＥは送信ＵＥに対して、ＳＲＳを送信してもよい。また、受信ＵＥは測定を実施し、送信ＵＥに対して測定結果を送信してもよい。受信ＵＥは測定として、送信ＵＥから受信したＲＳのＲＳＲＰ、ＲＳＲＱの測定を行ってもよい。あるいは、受信ＵＥは、送信ＵＥからのＲＳのＲＳＲＰ、ＲＳＲＱに限らず、一つまたは複数のＰＲＢ、あるいはサブチャネルのＲＳのＲＳＲＰ、ＲＳＲＱの測定を行ってもよい。受信ＵＥは、測定結果を送信ＵＥに送信する。
【０５６６】
ステップＳＴ５７１１で、送信ＵＥは非ＳＵＬ上のＳＬ通信の測定を行う。送信ＵＥは、受信ＵＥから送信されたチャネルあるいは信号を用いて、通信品質の測定を行う。あるいは、送信ＵＥは、受信ＵＥから送信された測定結果を、測定の代わりに用いてもよい。このようにすることで、送信ＵＥは非ＳＵＬでのＳＬ通信における測定情報を得ることができる。また、送信ＵＥは、非ＳＵＬでのＳＬ通信における通信品質を認識することが可能となる。
【０５６７】
ステップＳＴ５７１２で、送信ＵＥはｇＮＢに対して、非ＳＵＬでのＳＬ通信における測定情報を送信する。ステップＳＴ５７１３で、ｇＮＢは、送信ＵＥから受信した測定情報を用いて、ＳＬ通信においてＳＵＬを用いるか否かを決定する。通信品質に所定の閾値を設けてもよい。たとえば、該閾値を下回った場合に、ｇＮＢはＳＬ通信にＳＵＬを用いると決定してもよい。
【０５６８】
ｇＮＢはあらかじめ、所定の閾値を送信ＵＥに通知してもよい。送信ＵＥは、ステップＳＴ５７１１で得た測定結果から、ＳＬ通信にＳＵＬを用いた方が良いか否かを決定する。通信品質が該閾値を下回った場合、送信ＵＥは、ＳＬ通信にＳＵＬが必要と判断し、ステップＳＴ５７１２でｇＮＢに対してＳＬ通信にＳＵＬを用いることを要求してもよい。ステップＳＴ５７１３で、ｇＮＢは、送信ＵＥからの要求に応じて、ＳＬ通信にＳＵＬを使用することを決定してもよい。
【０５６９】
ステップＳＴ５７１４、ＳＴ５７１５で、ｇＮＢはＳＬ  ＳＵＬのａｃｔ情報を通知する。ｇＮＢは、ＳＬ  ＳＵＬでのＳＬＲＰのａｃｔ情報を通知するとしてもよい。ＳＬ  ＳＵＬでのＳＬＲＰのａｃｔ情報の通知により、該ＳＬ  ＳＵＬをアクティベーションする。図３９および図４０の例では、ｇＮＢは送信ＵＥと受信ＵＥに対してＲＲＣシグナリングで、ＳＵＬでのＳＬＲＰのａｃｔ情報を通知している。送信ＵＥ、受信ＵＥは、ｇＮＢに対して、ＳＵＬでのＳＬＲＰのａｃｔ情報を受信完了したことを通知してもよい。該通知にＲＲＣシグナリングを用いてもよい。ＳＵＬでのＳＬＲＰのａｃｔ情報を受信した受信ＵＥは、ステップＳＴ５７０４で受信したＳＵＬでのＳＬＲＰ設定を用いて、ステップＳＴ５７１６でＳＵＬでのＳＬＲＰのＰＳＣＣＨのサーチを開始する。
【０５７０】
ｇＮＢは、ステップＳＴ５７１７でＳＵＬでのＳＬ通信用スケジューリングを行い、ステップＳＴ５７１８で送信ＵＥに対してＳＵＬでのＳＬスケジューリング情報を通知する。ステップＳＴ５７１９で、送信ＵＥは送信処理を行う。ステップＳＴ５７２０で、送信ＵＥは受信ＵＥに対して、ｇＮＢから受信したスケジューリング情報を用いて、ＳＵＬのＳＬでの送信を行う。送信ＵＥはＰＳＣＣＨ、ＰＳＳＣＨの送信を行う。
【０５７１】
送信ＵＥは、ＰＳＣＣＨに、ＳＬ通信を行う受信ＵＥの識別子を含めてもよい。このようにすることで、ステップＳＴ５７１６でＰＳＣＣＨのサーチを行っている受信ＵＥは、送信ＵＥからのＰＳＣＣＨを受信し、該ＰＳＣＣＨが自ＵＥ向けであると判断可能となる。送信ＵＥからＰＳＣＣＨを受信した受信ＵＥは、ＰＳＣＣＨに含まれるＰＳＳＣＨのスケジューリング情報を用いて、ＰＳＳＣＨを受信する。これにより、受信ＵＥは送信ＵＥからのデータを受信可能となる。
【０５７２】
受信ＵＥはＳＵＬ上の通信に、ステップＳＴ５７１０について開示した方法を適用してもよい。受信ＵＥは、フィードバック情報として、該データの受信可否を送信ＵＥに送信してもよい。受信ＵＥはデータの受信可否を、ＨＡＲＱフィードバック情報（Ack/Nack）として送信してもよい。また、受信ＵＥは送信ＵＥに対して、チャネル状態情報（CSI）を送信してもよい。また、受信ＵＥは送信ＵＥに対して、ＳＲＳを送信してもよい。また、受信ＵＥは測定を実施し、送信ＵＥに対して測定結果を送信してもよい。受信ＵＥは測定として、送信ＵＥから受信したＲＳのＲＳＲＰ、ＲＳＲＱの測定を行ってもよい。あるいは、受信ＵＥは、送信ＵＥからのＲＳのＲＳＲＰ、ＲＳＲＱに限らず、一つまたは複数のＰＲＢ、あるいはサブチャネルのＲＳのＲＳＲＰ、ＲＳＲＱの測定を行ってもよい。受信ＵＥは、測定結果を送信ＵＥに送信する。
【０５７３】
ステップＳＴ５７２１で、送信ＵＥはＳＵＬ上のＳＬ通信の測定を行う。送信ＵＥは、受信ＵＥから送信されたチャネルあるいは信号を用いて、通信品質の測定を行う。あるいは、送信ＵＥは、受信ＵＥから送信された測定結果を、測定の代わりに用いてもよい。このようにすることで、送信ＵＥはＳＵＬでのＳＬ通信における測定情報を得ることができる。また、送信ＵＥは、ＳＵＬでのＳＬ通信における通信品質を認識することが可能となる。
【０５７４】
ステップＳＴ５７２２で、送信ＵＥはｇＮＢに対して、ＳＵＬでのＳＬ通信における測定情報を送信する。ｇＮＢは、送信ＵＥから受信した測定情報を用いて、ＳＬ通信において非ＳＵＬを用いるか否かを決定する。通信品質に所定の閾値を設けてもよい。たとえば、該閾値を下回った場合に、ｇＮＢはＳＬ通信に非ＳＵＬを用いると決定してもよい。
【０５７５】
このようにすることで、ＳＵＬ上でのＳＬ通信を可能にする。
【０５７６】
ＳＵＬのデアクティベーションの場合も同様である。たとえば、ステップＳＴ５７２２でＳＵＬのＳＬ通信の測定情報を受信したｇＮＢは、ＳＬ通信用にＳＵＬの使用を終了するか否かを判断する。たとえば、ＳＵＬでのＳＬ通信の通信品質が所定の閾値を下回った場合には、ＳＬ通信用にＳＵＬの使用を終了するとする。ＳＵＬでのＳＬ通信用にＳＵＬの使用終了を決定したｇＮＢは、送信ＵＥと受信ＵＥに対して、ＳＵＬでのＳＬＲＰのｄｅａｃｔ情報を通知する。該ｄｅａｃｔ情報はＲＲＣシグナリングで通知するとよい。送信ＵＥ、受信ＵＥは、ｇＮＢに対して、ＳＵＬでのＳＬＲＰのｄｅａｃｔ情報を受信完了したことを通知してもよい。該受信完了はＲＲＣシグナリングで通知してもよい。ＳＵＬでのＳＬＲＰのｄｅａｃｔ情報を受信した受信ＵＥは、ＳＵＬでのＳＬＲＰのＰＳＣＣＨのサーチを終了する。
【０５７７】
このようにすることで、ＳＬでのＳＵＬの設定が可能となり、また、ＳＵＬ使用のアクティベーション、デアクティベーションが実施可能となる。このため、受信ＵＥはＳＬ  ＳＵＬのａｃｔ情報の受信からｄｅａｃｔ情報の受信まで、ＳＬ  ＳＵＬ上のＳＬＲＰをサーチすれば良くなる。ＵＥの消費電力の低減を図れる。
【０５７８】
図３９および図４０の例では、送信ＵＥ、受信ＵＥは、ＳＵＬでのＳＬＲＰのアクティベーション受信後も、非ＳＵＬでのＳＬ通信を終了していない。送信ＵＥ、受信ＵＥは、非ＳＵＬとＳＵＬとでＳＬ通信を行ってもよい。また、非ＳＵＬにおいても、ＳＬでの非ＳＵＬ使用のアクティベーション、デアクティベーション情報を設けてもよい。ＳＵＬでのａｃｔ／ｄｅａｃｔ情報の通知方法と同様の方法とすることで、非ＳＵＬでも、ＳＬでの非ＳＵＬ使用のアクティベーション、デアクティベーションを実施可能となる。
【０５７９】
ステップＳＴ５７１０では、受信ＵＥが非ＳＵＬでのＳＬ通信の測定を行い、該測定結果を送信ＵＥに送信することを開示した。また、ステップＳＴ５７２０では、受信ＵＥがＳＵＬでのＳＬ通信の測定を行い、該測定結果を送信ＵＥに送信することを開示した。測定を、非ＳＵＬあるいはＳＵＬのどちらか１つに限定しなくてもよい。受信ＵＥが非ＳＵＬとＳＵＬとで測定を行ってもよい。非ＳＵＬとＳＵＬとの測定結果を、送信ＵＥとＳＬ通信を行っているＵＬ上で送信するとよい。
【０５８０】
ｇＮＢは、受信ＵＥあるいは送信ＵＥでの非ＳＵＬの測定結果とＳＵＬの測定結果を用いて、非ＳＵＬでＳＬ通信を行うか、ＳＵＬでＳＬ通信を行うかを決定してもよい。たとえば、非ＳＵＬでのＳＬ通信品質がＳＵＬでのＳＬ通信品質よりも良好な場合に非ＳＵＬでＳＬ通信を行い、ＳＵＬでのＳＬ通信品質が非ＳＵＬでのＳＬ通信品質よりも良好な場合にＳＵＬでＳＬ通信を行うとしてもよい。このようにすることで、通信品質のより良いＳＬ通信を可能にする。
【０５８１】
ＳＬでの非ＳＵＬの使用について、ＳＵＬでのＳＬＲＰのアクティベーション受信により、送信ＵＥ、受信ＵＥは、非ＳＵＬでの送信、受信を終了してもよい。また、ＳＵＬでのＳＬＲＰのデアクティベーション受信により、送信ＵＥ、受信ＵＥは、非ＳＵＬでの送信、受信を開始してもよい。このようにすることで、非ＳＵＬとＳＵＬのどちらか１つのＵＬを用いたＳＬ通信が可能となる。ＵＥは非ＳＵＬとＳＵＬの両方を用いたＳＬ通信が不要となる。受信ＵＥは非ＳＵＬあるいはＳＵＬどちらかのＰＳＣＣＨをサーチすればよい。受信ＵＥの消費電力を低減可能となる。
【０５８２】
図４１および図４２は、ＳＬ  ＳＵＬでＳＬ通信を行うためのシーケンスの一例を示す図である。図４１と図４２とは、境界線ＢＬ４１４２の位置で、つながっている。図４１および図４２において、図３９および図４０と共通するステップについては同じステップ番号を付し、共通する説明を省略する。図４１および図４２の例は、図３９および図４０の例とは、ＳＵＬでのＳＬＲＰのａｃｔ情報の通知方法が異なる。図４１および図４２の例では、ステップＳＴ５８０１で、ｇＮＢは送信ＵＥに対して、ＳＵＬでのＳＬＲＰのａｃｔ情報を送信する。ｇＮＢは、ＳＵＬでのＳＬＲＰのａｃｔ情報を、ＤＣＩに含めて、ＰＤＣＣＨで通知する。このＳＵＬでのＳＬＲＰのａｃｔ情報を受信した送信ＵＥは、ステップＳＴ５８０２で、受信ＵＥに対して、ＳＵＬでのＳＬＲＰのａｃｔ情報を送信する。送信ＵＥは、ＳＬＲＰのａｃｔ情報を、ＳＣＩに含めて、非ＳＵＬで送信するＰＳＣＣＨで通知する。
【０５８３】
受信ＵＥは、非ＳＵＬで送信ＵＥからのＰＳＣＣＨを受信しているため、該ＰＳＣＣＨに含まれる、ＳＵＬでのＳＬＲＰのａｃｔ情報を受信可能となる。受信ＵＥは、ＳＵＬでのＳＬＲＰのａｃｔ情報の受信により、ステップＳＴ５７１６でＳＵＬでのＳＬＲＰのＰＳＣＣＨのサーチを開始可能となる。
【０５８４】
このようにすることで、ＳＬ  ＳＵＬのアクティベーション／デアクティベーションを早期に実施することが可能となる。ダイナミックなＳＬ  ＳＵＬ上でのＳＬ通信を可能にする。このため、さらにＵＥの消費電力の低減を図れる。
【０５８５】
図４１および図４２の例では、送信ＵＥが受信ＵＥへＳＬ  ＳＵＬのアクティベーション／デアクティベーションを通知した。他の例として、ｇＮＢが受信ＵＥに対して、ＳＬＲＰのａｃｔ／ｄｅａｃｔ情報を、ＤＣＩに含めて、ＰＤＣＣＨで通知してもよい。同様の効果を得ることができる。
【０５８６】
図３９および図４０の例ならびに図４１および図４２の例では、ＳＵＬ上でのＳＬ通信において、送信ＵＥから受信ＵＥへのスケジューリングはＳＵＬのＰＳＣＣＨを用いて行われた。他の例を開示する。
【０５８７】
ＳＬ通信において、送信ＵＥから受信ＵＥへのＳＵＬ上のスケジューリングを、非ＳＵＬのＰＳＣＣＨを用いて行ってもよい。ＳＬ通信において、送信ＵＥは受信ＵＥに対して、非ＳＵＬのＰＳＣＣＨでＳＵＬのＰＳＳＣＨのスケジューリングを実施してもよい。受信ＵＥは、非ＳＵＬのＰＳＣＣＨを受信して、ＳＵＬのＰＳＳＣＨのスケジューリングが実施されている場合、該スケジューリングに従ってＳＵＬのＰＳＳＣＨを受信する。
【０５８８】
非ＳＵＬあるいはＳＵＬのどちらのスケジューリング行うかを示す情報を設けてもよい。一つまたは複数の非ＳＵＬおよび一つまたは複数のＳＵＬでＳＬ通信を行うような場合は、どの非ＳＵＬあるいはＳＵＬのスケジューリングを行うかを示す情報を設けてもよい。あるいは、ＳＵＬでスケジューリングを行うことを示す情報を設けてもよい。該情報をＳＣＩに含めてもよい。該情報をＳＣＩに含めてＰＳＣＣＨにマッピングしてもよい。
【０５８９】
非ＳＵＬとＳＵＬとでニュメロロジが異なる場合、非ＳＵＬにおけるスケジューリング情報からＳＵＬにおけるスケジューリング情報を導出するために、各ニュメロロジのシンボル期間あるいはＳＣＳの比に応じた変換を行ってもよい。
【０５９０】
このようにすることで、送信ＵＥはＰＳＣＣＨを非ＳＵＬ上でのみ送信可能となるため、ＰＳＣＣＨの送信処理を簡易にできる。また、受信ＵＥは非ＳＵＬ上でのみＰＳＣＣＨをサーチして受信すればよい。受信ＵＥのＰＳＣＣＨの受信処理を簡易にでき、消費電力の低減を図れる。
【０５９１】
非ＳＵＬあるいはＳＵＬのどちらのスケジューリング行うかを示す情報を、ＳＬ  ＳＵＬのａｃｔ／ｄｅａｃｔ情報とともに用いてもよい。送信ＵＥは、受信ＵＥに対して、ＳＬ  ＳＵＬのａｃｔ情報とＳＵＬ上のＰＳＳＣＨのスケジューリング情報を、ＳＣＩに含めて、非ＳＵＬ上のＰＳＣＣＨで通知する。受信ＵＥは、非ＳＵＬ上のＰＳＣＣＨを受信することで、ＳＬ  ＳＵＬがアクティベーションされたこと、該ＳＵＬ上でＰＳＳＣＨがスケジューリングされたことを認識可能となる。受信ＵＥは、早期にＳＵＬ上でのＰＳＳＣＨを受信可能となる。
【０５９２】
送信ＵＥは、受信ＵＥに対して、ＳＬ  ＳＵＬのｄｅａｃｔ情報と非ＳＵＬ上のＰＳＳＣＨのスケジューリング情報を、ＳＣＩに含めて、非ＳＵＬ上のＰＳＣＣＨで通知する。あるいは、ＳＵＬでスケジューリングを行うことを示す情報を設ける場合は、該情報を通知しない。受信ＵＥは、非ＳＵＬ上のＰＳＣＣＨを受信することで、ＳＬ  ＳＵＬがデアクティベーションされたこと、非ＳＵＬ上でＰＳＳＣＨがスケジューリングされたことを認識可能となる。受信ＵＥは、早期に非ＳＵＬ上でのＰＳＳＣＨを受信可能となる。
【０５９３】
非ＳＵＬあるいはＳＵＬのどちらのスケジューリング行うかを示す情報で、ＳＬ  ＳＵＬのアクティベーション／デアクティベーションを示してもよい。ＳＵＬ上でのスケジューリングを示す場合、ＳＵＬがアクティベーションされるとしてもよい。あるいは、非ＳＵＬ上でのスケジューリングを示す場合、ＳＵＬがデアクティベーションされるとしてもよい。スケジューリング毎に非ＳＵＬあるいはＳＵＬのどちらのスケジューリング行うかを示す情報を送受信することで、ＳＬ  ＳＵＬのアクティベーション／デアクティベーションを実施可能となる。
【０５９４】
ＳＬ通信において、送信ＵＥから受信ＵＥへのＳＵＬ上のスケジューリングを、非ＳＵＬのＰＳＣＣＨを用いて行うことを開示した。これに対し、送信ＵＥから受信ＵＥへの非ＳＵＬ上のスケジューリングを、ＳＵＬのＰＳＣＣＨを用いて行ってもよい。前述の方法を適宜適用するとよい。
【０５９５】
ＳＬ通信において、非ＳＵＬあるいはＳＵＬのどちらかを主のリンクとして設定しておき、送信ＵＥ、受信ＵＥは主のリンク上でＳＬ通信用のＰＳＣＣＨを送受信するとしてもよい。主のリンクは、ＳＬ  ＳＵＬの設定とともに設定されてもよい。あるいは、主のリンクは、ＳＬ  ＳＵＬのアクティベーション／デアクティベーションの設定ともに設定されてもよい。
【０５９６】
このようにすることで、送信ＵＥは、非ＳＵＬあるいはＳＵＬのどちらか一方でＰＳＣＣＨを送信すればよくなるため、送信処理を簡易にすることができる。また、受信ＵＥは非ＳＵＬ上でのみＰＳＣＣＨをサーチして受信すればよい。受信ＵＥのＰＳＣＣＨの受信処理を簡易にでき、消費電力の低減を図れる。また、通信品質、通信範囲、通信負荷等に応じて主のリンクを変更することができるため、通信品質の向上、リソース使用効率の向上、他ＵＥとの使用リソース衝突低減によるＳＬ通信の遅延時間の削減が可能となる。
【０５９７】
ＵｕのＵＬでの非ＳＵＬとＳＵＬの切替えと、ＳＬでの非ＳＵＬとＳＵＬの切替えとを連動させてもよい。たとえば、送信ＵＥが、ｇＮＢによってＵｕのＵＬでＳＵＬが設定された場合、ＳＬ通信においてもＳＬ  ＳＵＬを設定する。このようにすることで、たとえば、ＵｕのＵＬのＳＵＬの周波数バンドとＳＬのＳＵＬの周波数バンドが同じに設定されているような場合に、該周波数バンドを用いた方が良いか否かをＵｕのＵＬで判断可能となる。
【０５９８】
図３９および図４０の例ならびに図４１および図４２の例では、ＳＵＬ上でのデータ送信に対するＨＡＲＱフィードバックはＳＵＬ上で送信されることを開示した。１スロット内に送信ＵＥから受信ＵＥへのシンボルと、受信ＵＥから送信ＵＥへのシンボルが構成されるような場合、ＳＬ通信用にＳＵＬ上でリザベーションされたリソースの、受信ＵＥから送信ＵＥへのシンボルを用いて、ＨＡＲＱフィードバックを送信するとよい。送信ＵＥは、ＳＵＬ上でのデータ送信に対する受信ＵＥからのＨＡＲＱフィードバックを、ＳＵＬ上で受信する。
【０５９９】
受信ＵＥにおけるＨＡＲＱフィードバック送信のためのスケジューリング情報を、ＳＣＩに含めてＰＳＣＣＨにマッピングしてもよい。たとえば、該スケジューリング情報を、ＰＳＣＣＨ送信からＨＡＲＱフィードバック送信までの時間間隔としてもよい。時間単位は例えば、スロット、ミニスロット、サブフレーム、シンボル、ＴＴＩ等であってもよい。
【０６００】
ＰＳＳＣＨとＨＡＲＱフィードバックを同じＳＵＬ上で送信することで、ＰＳＳＣＨに対するＨＡＲＱフィードバックのスケジューリング、特に時間領域のスケジューリングを容易にすることが可能となる。送信ＵＥのスケジューリング制御を容易にすることができ、また、受信ＵＥでのＰＳＳＣＨからＨＡＲＱフィードバックまでの処理を容易にすることが可能となる。
【０６０１】
ＨＡＲＱフィードバックの送信方法の他の例として、ＳＵＬ上でのデータ送信に対するＨＡＲＱフィードバックを非ＳＵＬ上で送信してもよい。ＳＬ通信用に非ＳＵＬ上でリザベーションされたリソースの、受信ＵＥから送信ＵＥへのシンボルを用いて、ＨＡＲＱフィードバックを送信するとよい。送信ＵＥは、ＳＵＬ上でのデータ送信に対する受信ＵＥからのＨＡＲＱフィードバックを、非ＳＵＬ上で受信する。
【０６０２】
このようにすることで、送信ＵＥと受信ＵＥの間の制御チャネルを非ＳＵＬ上で送受信することが可能となる。データの送受信のみをＳＵＬを用いて送受信可能となる。データをＳＵＬ上にオフロードすることが可能となり、非ＳＵＬでの通信負荷を低減させることが可能となる。
【０６０３】
他の例として、非ＳＵＬ上でのデータ送信に対するＨＡＲＱフィードバックを、ＳＵＬ上で送信してもよい。同様の効果を得ることができる。
【０６０４】
ＨＡＲＱフィードバックを非ＳＵＬあるいはＳＵＬのどちらで送信するかを設定可能としてもよい。ＨＡＲＱフィードバックを非ＳＵＬあるいはＳＵＬのどちらで送信するかを示す情報を設けてもよい。送信ＵＥは、該情報を、ＳＣＩに含めてＰＳＣＣＨにマッピングして、受信ＵＥに通知してもよい。該情報を、ＰＳＳＣＨのスケジューリング情報とともに通知してもよい。また、該情報を、ＨＡＲＱフィードバック送信のためのスケジューリング情報に含めてもよい。
【０６０５】
このようにすることで、通信品質、通信範囲、通信負荷等に応じてＨＡＲＱフィードバックを送信するリンクを変更することができるため、通信品質の向上、リソース使用効率の向上、他ＵＥとの使用リソース衝突低減によるＳＬ通信の遅延時間の削減が可能となる。
【０６０６】
ＨＡＲＱフィードバックを非ＳＵＬあるいはＳＵＬのどちらで送信するかを示す情報の通知方法として、送信ＵＥから受信ＵＥに対して、ＰＣ５制御シグナリングを用いてもよい。また、ＲＲＣシグナリングを用いてもよい。あるいは、ＭＡＣシグナリングを用いてもよい。受信誤り率を低減できる。
【０６０７】
ｇＮＢが、ＨＡＲＱフィードバックを非ＳＵＬあるいはＳＵＬのどちらで送信するかを決定してもよい。ｇＮＢは送信ＵＥに対して、該情報をＤＣＩに含めて、ＰＤＣＣＨで通知する。あるいは、該情報の通知に、ＲＲＣシグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。受信誤り率を低減できる。該情報を受信した送信ＵＥは、ＳＬ通信における受信ＵＥに対して該情報を前述の方法を適用して通知するとよい。
【０６０８】
ｇＮＢが受信ＵＥに対して該情報を通知してもよい。同様の方法を用いて通知するとよい。
【０６０９】
ｇＮＢが送信ＵＥに対して、ＨＡＲＱフィードバックを非ＳＵＬあるいはＳＵＬのどちらで送信するかの情報を通知することで、他ＵＥとの使用リソース衝突低減によるＳＬ通信の遅延時間の削減が可能となる。
【０６１０】
図３９および図４０の例ならびに図４１および図４２の例では、ＳＵＬ上のＳＬスケジューリングをｇＮＢが実施することを開示した。他の例を開示する。ＳＬ通信における送信ＵＥがＳＵＬ上のＳＬスケジューリングを実施してもよい。ＳＵＬ上のＳＬＲＰ内からＳＬ通信用のリソースを選択するとよい。送信ＵＥは、ＳＵＬ上のＳＬＲＰ内から使用可能なリソースをセンシングし、使用可能なリソースの中から、ＳＬ通信に用いるリソースを選択しリザーブする。
【０６１１】
受信ＵＥは、前述の方法でＳＵＬ上にＳＬＲＰが設定された場合、あるいは、ＳＵＬ上のＳＬＲＰがアクティベーションされた場合に、ＳＵＬ上のＳＬＲＰ内のＰＳＣＣＨをサーチする。これにより、送信ＵＥからのＰＳＣＣＨを受信可能となる。
【０６１２】
このようにすることで、送信ＵＥがＳＵＬ上のＳＬスケジューリングを実施可能となる。送信ＵＥは、ｇＮＢからのスケジューリングを待たずにＳＵＬ上でのＳＬスケジューリングを実施可能となるため、早期にＳＬ通信を実施可能となる。ＳＬ通信を低遅延で実施可能となる。
【０６１３】
ＳＬ通信を行うＵＥは、ＳＬ  ＳＵＬにおいて同期信号（ＳＳ）を送信してもよい。ＵｕのＳＵＬとＳＬ  ＳＵＬとが同じキャリア周波数の場合は、ＳＬ通信を行うＵＥは、ｇＮＢのＳＳを受信して同期をとればよい。ＳＬ通信を行うＵＥがｇＮＢのカバレッジ外に存在する場合、ＳＬ通信を行うＵＥは、近傍のＳＬ  ＳＵＬでＳＳを送信しているＵＥから、該ＳＳを受信して同期をとるとよい。ＳＬ通信を行うＵＥは、ｇＮＢのカバレッジ内か否か、ＳＳを送信しているＵＥが近傍に存在するか否かを、受信電力あるいは受信品質を用いて判断すると良い。
【０６１４】
該判断用に、受信電力あるいは受信品質の所定の閾値を設けてもよい。たとえば、ＳＬ通信を行うＵＥは、ｇＮＢから、あるいは、ＳＳを送信しているＵＥから、該所定の閾値以上の受信電力を受信した場合、ｇＮＢあるいはＳＳを送信しているＵＥと同期をとるようにする。このようにすることで、非ＳＵＬとＳＵＬとのフレームタイミングを同期させなくてもよく、ＳＵＬでの同期が可能となる。
【０６１５】
実施の形態７で開示したようなＳＵＬの設定方法とすることで、ＳＬ通信においてＳＵＬを用いることが可能となる。このため、非ＳＵＬで行われるＳＬ通信の通信品質が劣化するような場合でもＳＵＬを用いて通信品質を向上させることができる。
【０６１６】
実施の形態８．
ＮＲのＵｕでの通信において、ＲＬＦ（Radio Link Failure）の処理が規定されている（非特許文献１６（ＴＳ３８．３００））。Ｕｕにおける通信のため、ＵＥがｇＮＢと同期はずれを生じた場合にＲＬＦ処理が行われる。ＵＥがｇＮＢと再同期できなかった場合にＲＬＦとなり、ＵＥはセルリセレクションを実施し、ＲＲＣ再設定（RRC_re-establishment）を実行する。ＲＲＣ再設定できない場合、ＵＥは、ＲＲＣ＿Ｉｄｌｅに移行する。
【０６１７】
ＮＲのＳＬでの通信では、ユニキャストやグループキャストのサポートが検討されている。このため、ＳＬ通信においてもＲＬＦの処理方法が要求される。しかし、ＳＬ通信はＵＥとＵＥとの間の通信であり、ＵＥとｇＮＢとの間の通信ではない。このため、ＵＥとｇＮＢとの間の通信のＲＬＦである従来のＲＬＦ処理をなんの工夫も無く適用することができない。
【０６１８】
送信ＵＥと受信ＵＥとでＳＬ通信が不可能となった場合の処理方法が問題となる。たとえば、どのようになったら通信失敗と判断するのか、通信失敗と判断した場合の処理方法をどうするのか、などである。これらの方法が不明の場合、送信ＵＥや受信ＵＥは処理不能あるいは協調した処理ができなくなり、通信が正常に実施されないことになる。本実施の形態８ではこのような課題を解決するための方法を開示する。
【０６１９】
ユニキャストあるいはグループキャスト通信において同期状態にあるか否かの判断方法について開示する。受信ＵＥが同期状態にあるか否かを判断する。同期状態か否かの判断には、ｇＮＢから受信するＰＤＣＣＨではなく、ＰＳＣＣＨを用いる。受信ＵＥは、送信ＵＥから送信されるＰＳＣＣＨを、所定の回数連続で受信できた場合に、同期状態（In-Sync）と判断するとよい。受信ＵＥは、所定の時間継続して受信できた場合に、同期状態と判断してもよい。受信ＵＥは、所定の時間内で所定の回数連続で受信できた場合に、同期状態と判断してもよい。
【０６２０】
受信ＵＥは、送信ＵＥから送信されるＰＳＣＣＨを、所定の回数連続で受信できなかった場合に、同期外れ状態（Out-of-Sync）と判断するとよい。受信ＵＥは、送信ＵＥから送信されるＰＳＣＣＨを、所定の時間継続して受信できなかった場合に、同期外れ状態と判断してもよい。受信ＵＥは、送信ＵＥから送信されるＰＳＣＣＨを、所定の時間内で所定の回数連続で受信できなかった場合に、同期外れ状態と判断してもよい。
【０６２１】
同期状態にあるか否かの判断に用いる所定の回数や所定の時間等の情報は、ｇＮＢから、ＳＬ通信を行うＵＥに、通知されてもよい。該情報は、報知情報に含められて、報知されてもよい。セル毎に該所定の値を決めることができる。あるいは、該情報は、ＲＲＣシグナリングでＵＥ個別に通知されてもよい。あるいは、該情報は、静的に予め規格等で決められていてもよい。あるいは、該情報は、ＳＬ通信のＵＥに予め設定されてもよい。
【０６２２】
所定の回数や所定の時間等の情報は、サービス毎に設定されてもよい。該情報は、サービスのＱｏＳ毎に設定されてもよい。たとえば、サービス毎に要求される遅延時間等に応じて、該所定の値を決めることができる。ｇＮＢからＵＥへの通知方法は前述の方法を適用すると良い。
【０６２３】
他の方法を開示する。ユニキャストあるいはグループキャスト通信において同期状態にあるか否かの判断方法として、ＳＬでのＳＳ（Synchronization Signal）（以降、ＳＬＳＳと称する）を用いてもよい。受信ＵＥは、ＳＬで同期をとるＵＥから送信されるＳＬＳＳ用いて、同期状態にあるか否かを判断する。受信ＵＥは、ＳＬで同期をとるＵＥから送信されるＳＬＳＳを、所定の回数連続で受信できた場合に、同期状態と判断するとよい。受信ＵＥは、ＳＬで同期をとるＵＥから送信されるＳＬＳＳを、所定の回数連続で受信できなかった場合に、同期外れ状態と判断するとよい。
【０６２４】
ＰＳＣＣＨでの同期と同様に、所定の回数ではなく、所定の時間、あるいは、所定の時間内の所定の回数としてもよい。
【０６２５】
ＳＬにおいては、受信ＵＥが同期をとるＵＥと、送信ＵＥとが異なる場合がある。前述のように、ＰＳＣＣＨあるいはＳＬＳＳのどちらで同期状態にあるか否かの判断を行うかを決めておくことで、ＳＬ通信の受信ＵＥは明確に同期状態か否かを判断可能となる。その結果、誤動作の発生を低減可能となる。
【０６２６】
同期状態か否かの判断方法として、ＰＳＣＣＨを用いる方法とＳＬＳＳを用いる方法とを組合せてもよい。たとえば、ＰＳＣＣＨとＳＬＳＳとを合わせて、所定の時間内で所定の回数連続で受信できなかった場合に、同期外れ状態と判断し、そうでない場合に同期状態と判断してもよい。このようにすることで、早期に同期外れの判断が可能となる。次の処理への移行を早期にできる。
【０６２７】
また、たとえば、ＰＳＣＣＨかつＳＬＳＳで各々同期外れ状態となったときに、ユニキャストあるいはグループキャスト通信において同期外れ状態であると判断してもよい。そうでない場合に同期状態と判断してもよい。ＰＳＣＣＨだけ同期外れの場合、ＳＬＳＳだけ同期外れの場合は、同期状態となる。このようにすることで、同期外れ状態に移行する状況を削減できる。できるかぎり、通信状態を維持することができる。
【０６２８】
同期外れの判断をしたＵＥの処理を開示する。ＵＥは再同期を行う。ＰＳＣＣＨを用いて同期外れの判断を行った場合は、ＵＥは送信ＵＥからのＰＳＣＣＨを受信して再同期を行う。このようにすることで、受信ＵＥは送信ＵＥからのＰＳＣＣＨおよびＰＳＳＣＨを受信可能となる。再度ＳＬでのユニキャスト通信が可能となる。
【０６２９】
ＳＬＳＳを用いて同期外れの判断を行った場合は、ＵＥはＳＬＳＳを受信して再同期を行う。ＳＬＳＳの受信は、直近に同期をとっていたＵＥのＳＬＳＳを受信することによって実施してもよい。再同期のためのＳＬＳＳの受信電力や受信品質等の閾値を設け、該閾値以上となったＵＥのＳＬＳＳと同期をとってもよい。
【０６３０】
再同期のためのＳＬＳＳの受信電力や受信品質等の閾値は、同期のためのＳＬＳＳの受信電力や受信品質等の閾値と同じとしてもよい。同期処理の制御を容易にすることができる。あるいは、再同期のためのＳＬＳＳの受信電力や受信品質等の閾値は、同期のためのＳＬＳＳの受信電力や受信品質等の閾値と異ならせてもよい。たとえば、再同期の場合の閾値を同期の場合の閾値よりも低くする。再同期を容易にさせることができ、再度通信可能となるまでの遅延時間を短縮できる。
【０６３１】
ＳＬＳＳを受信して再同期を実施した受信ＵＥは、送信ＵＥからのＰＳＣＣＨを受信する。このようにすることで、受信ＵＥは送信ＵＥからのＰＳＣＣＨとＰＳＳＣＨを受信可能となる。再度ＳＬでのユニキャスト通信が可能となる。
【０６３２】
ＳＬＳＳを用いて同期外れの判断を行った場合、送信ＵＥからのＰＳＣＣＨはまだ受信可能となっている場合がある。このような場合、ＳＬＳＳを受信して再同期を実施した受信ＵＥは、該送信ＵＥからのＰＳＣＣＨを受信継続してもよい。このような場合に、ＳＬでのユニキャスト通信を継続可能となる。
【０６３３】
同期状態か否かの判断方法に応じて、これらの再同期の方法を適宜組合せて用いてもよい。同期外れや再同期の処理を簡易にすることが可能となる。
【０６３４】
受信ＵＥが同期外れ状態になった後に再同期を実施できなかった場合は、ＳＬ通信終了とするとよい。ＳＬにおけるユニキャスト通信あるいはグループキャスト通信が終了したと判断する。ＳＬ通信終了となった受信ＵＥは、新たにＳＬ通信のための同期処理を行い、ＳＬＲＰのＰＳＣＣＨをサーチし、送信ＵＥからのＰＳＣＣＨを受信して、ユニキャスト通信あるいはグループキャスト通信処理を開始する。このようにすることで、ＳＬ通信における通信品質の劣化等により受信ＵＥで同期外れ状態になったような場合も、新たなＳＬ通信を開始可能となる。
【０６３５】
ＳＬ通信終了となった受信ＵＥは、ユニキャスト通信あるいはグループキャスト通信におけるこれらの通信のために設定されているＲＲＣ設定をリリースする。また、ＳＬ通信での各プロトコルの設定をリリースするとしてもよい。たとえば、ＳＬ通信でのＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹ等の設定をリリースする。あるいは、ＳＬ通信でのＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹでバッファされているデータを破棄する。このようにすることで、ＵＥ内の処理負荷の削減やバッファ容量の削減を可能とする。
【０６３６】
また、ＳＬでベアラを設定するような場合、ＳＬ通信終了となった受信ＵＥは、該ベアラ設定をリリースするとしてもよい。ＳＬで設定されたベアラで構成される各プロトコルがリリースされる。同様の効果を得ることができる。
【０６３７】
同期外れ状態開始からの時間をタイマで管理してもよい。同期外れ状態開始からタイマ内で再同期した場合は、同期状態にもどり、タイマをリセットする。同期外れ状態開始からタイマ内に再同期できなかった場合は、ＳＬ通信終了とし、タイマをリセットするとよい。このようにすることで、再同期処理を行う期間が長期化することを回避することができる。
【０６３８】
受信ＵＥは、同期外れ状態になった後に再同期できなかった場合、ユニキャスト通信あるいはグループキャスト通信におけるこれらの通信のために設定されているＲＲＣ設定の一部または全部をリリースしない、あるいは、保持するとしてもよい。たとえば、ＳＬ通信でのＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹ等の設定の一部または全部をリリースしない、あるいは、保持する。あるいは、ＳＬ通信でのＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹでバッファされている一部または全部のデータを破棄しない、あるいは、保持する。
【０６３９】
また、ＳＬでベアラを設定するような場合、受信ＵＥが同期外れ状態になった後に再同期できなかった場合、受信ＵＥは、該ベアラ設定の一部または全部をリリースしない、あるいは、保持するとしてもよい。
【０６４０】
送信ＵＥは、ユニキャスト通信あるいはグループキャスト通信におけるこれらの通信のために設定した、ＲＲＣ設定の一部または全部、あるいは、ベアラ設定の一部または全部を、受信ＵＥが保持している間、保持するとしてもよい。後述する、同期外れ状態開始から再同期までのタイマや、該再同期できなかった時点からＳＬ通信のための同期処理完了までのタイマを考慮して、保持する期間を設定するとよい。送信ＵＥは、該保持する期間を超えても、受信ＵＥとの間で通信が再開されなかった場合は、保持していたＲＲＣ設定の一部または全部、あるいは、ベアラ設定の一部または全部をリリースする。このようにすることで、ＳＬ通信を再開した場合も、保持した該設定を用いることで、早期に通信が可能となる。
【０６４１】
受信ＵＥは、同期外れ状態になった後に再同期できなかった場合、これらの設定の一部または全部を保持したまま、新たにＳＬ通信のための同期処理を行い、ＳＬＲＰのＰＳＣＣＨをサーチし、送信ＵＥからのＰＳＣＣＨを受信して、ユニキャスト通信あるいはグループキャスト通信処理を開始する。このようにすることで、新たなＳＬ通信を開始した場合も、保持した該設定を用いることで、早期に通信が可能となる。
【０６４２】
受信ＵＥは、同期外れ状態になった後に再同期できなかった場合、これらの設定の一部または全部を保持したまま、新たにＳＬ通信のための同期処理を行い、ＳＬＲＰのＰＳＣＣＨをサーチし、送信ＵＥからのＰＳＣＣＨを受信して、ユニキャスト通信あるいはグループキャスト通信処理を開始する。このようにすることで、新たなＳＬ通信を開始した場合も、保持した該設定を用いることで、早期に通信が可能となる。
【０６４３】
受信ＵＥは、同期外れ状態になった後に再同期できなかった場合、これらの設定の一部または全部を保持したまま、さらに、再同期処理を行ってもよい。さらに行う再同期処理は、受信ＵＥが同期外れ状態になった後に行う前述の再同期処理と同様であってもよい。このようにすることで、再同期後、ＳＬ通信を再開した場合も、保持した該設定を用いることで、早期に通信が可能となる。
【０６４４】
同期外れ状態になった後に再同期できなかった場合、該再同期できなかった時点からの時間をタイマで管理してもよい。該再同期できなかった時点からタイマ内で新たにＳＬ通信のための同期処理が完了した場合、同期状態にもどり、タイマをリセットするとよい。あるいは、該再同期できなかった時点からタイマ内で送信ＵＥからのＰＳＣＣＨを受信して同期状態にもどった場合、タイマをリセットしてもよい。あるいは、該再同期できなかった時点からタイマ内で再同期処理が成功した場合は、同期状態に戻り、タイマをリセットするとよい。
【０６４５】
同期外れ状態になった後に再同期できなかった場合、該再同期できなかった時点からのタイマが満了した場合、ＳＬ通信終了とするとよい。ＳＬ通信終了により、保持していたＲＲＣ設定の一部または全部、あるいは、ベアラ設定の一部または全部をリリースする。このようにすることで、早期にＳＬ通信終了に移行でき、前述のＳＬ通信における設定の一部または全部を長期間保持しなくてすむ。
【０６４６】
前述のタイマ、たとえば、同期外れ状態開始から再同期までのタイマや、該再同期できなかった時点からＳＬ通信のための同期処理完了までのタイマは、予め規格等で静的に決められてもよい。あるいは、前述のタイマは送信ＵＥから受信ＵＥに通知されてもよい。該通知にＲＲＣシグナリングを用いてもよい。あるいは、該通知にＰＳＣＣＨ、あるいはＭＡＣシグナリングを用いてもよい。また、ｇＮＢからＵＥに前述のタイマが通知されてもよい。通知方法は前述のＳＬＲＰの通知方法を適用するとよい。あるいは、前述のタイマはＵＥに予め設定されてもよい。このようにすることで、受信ＵＥはタイマ設定を取得することが可能となる。
【０６４７】
これらのタイマは、ＵｕにおけるＲＬＦ処理に用いられるタイマと別に設けてもよい。Ｕｕでの通信とＳＬでの通信とではサービス内容、使用状況、電波伝搬環境などが異なる。そのような違いに適した値を設定可能となる。たとえば、ＵｕにおけるＲＬＦ処理に用いられるタイマよりも、ＳＬ通信における前述のタイマを長くする。これにより、ＳＬ通信がすぐに終了となることを回避することができる。再度ＳＬ通信を開始するためのリソースサーチ、リソース選択、リソースリザベーションなどの処理による遅延時間を削減可能となる。
【０６４８】
送信ＵＥが、ユニキャスト通信あるいはグループキャスト通信における対向ＵＥと同期状態か否かの判断を行ってもよい。受信ＵＥでの同期状態か否かの判断とともに、送信ＵＥでの同期状態か否かの判断が行われてもよい。送信ＵＥでの同期状態か否かの判断は、受信ＵＥから送信される信号あるいはチャネルを用いるとよい。受信ＵＥから送信される信号あるいはチャネルとして、ＳＲＳ、ＨＡＲＱフィードバック、ＣＳＩリポートなどがある。あるいは、ＰＳＦＣＨを用いてもよい。
【０６４９】
送信ＵＥでの同期状態か否かの判断方法は、前述の受信ＵＥでの同期状態か否かの判断方法を適宜適用すると良い。
【０６５０】
送信ＵＥで同期外れ状態になった場合の処理を開示する。送信ＵＥは、リソースを再選択する。他の方法として、送信ＵＥは、ＳＬＲＰを変更してもよい。送信ＵＥは、ＳＬＲＰを変更してリソースの再選択を行ってもよい。このようにすることで、通信品質のより良好なリソースを用いてＳＬ通信を開始することが可能となる。
【０６５１】
送信ＵＥで同期外れ状態が所定の期間経過した場合、ＳＬ通信を終了するとしてもよい。該所定の期間中は、送信ＵＥにおいて、ユニキャスト通信あるいはグループキャスト通信におけるこれらの通信のために設定した、ＲＲＣ設定の一部または全部、あるいは、ベアラ設定の一部または全部を保持するとしてもよい。ＳＬ通信を終了する場合、送信ＵＥは、ユニキャスト通信あるいはグループキャスト通信におけるこれらの通信のために設定した、ＲＲＣ設定の一部または全部、あるいは、ベアラ設定の一部または全部をリリースするとしてもよい。
【０６５２】
送信ＵＥは、ユニキャスト通信あるいはグループキャスト通信の送信データが発生した場合、再度ユニキャスト通信あるいはグループキャスト通信を開始する。このようにすることで、送信ＵＥで同期状態か否かの判断した場合に、送信ＵＥと受信ＵＥとでＳＬ通信が不可能となった場合の処理が実施可能となる。
【０６５３】
ＳＬでのユニキャスト通信あるいはグループキャスト通信が行われている場合、送信ＵＥにおいて、同期をとるＵＥとの同期が外れるような場合が生じる。このような場合、ユニキャスト通信あるいはグループキャスト通信の処理をどのようにするかが問題となる。このような場合、送信ＵＥにおける、同期をとるＵＥとの同期状態か否かの判断、同期外れの場合の処理、同期外れ状態開始から再同期までの処理や、再同期できなかった場合の処理は、前述の、受信ＵＥにおいて開示した方法を適用すると良い。同様の効果を得ることができる。
【０６５４】
ＳＬ通信においては、ＳＬＳＳを受信して同期をとるＵＥと、ユニキャスト通信あるいはグループキャスト通信における対向するＵＥとが異なってもよい。ＳＬＳＳを受信して同期をとるＵＥと、ユニキャスト通信あるいはグループキャスト通信における対向するＵＥとが無関係に選択されてもよい。たとえば、受信電力の最も高いＵＥなど、ＵＥは同期をとるのに最も適したＵＥと同期をとることができる。しかし、このような場合、受信ＵＥは、同期をとるＵＥからの信号と送信ＵＥからの信号を受信しなければならない。このような場合、受信ＵＥは受信処理が複雑となり、消費電力が増大する。このような問題を解決する方法を開示する。
【０６５５】
ユニキャスト通信あるいはグループキャスト通信において、受信ＵＥは、送信ＵＥを同期のためのＵＥとする。受信ＵＥは、送信ＵＥを同期のためのＵＥとして優先順位１番としてもよい。
【０６５６】
受信ＵＥは、送信ＵＥのＳＬＳＳを受信する。また、受信ＵＥは、ＰＳＢＣＨを受信してもよい。受信ＵＥは、ＳＬＳＳとＰＳＢＣＨを受信することで同期処理を行ってもよい。受信ＵＥは、送信ＵＥと同期後、送信ＵＥからのＰＳＣＣＨを受信してもよい。あるいは、受信ＵＥは、送信ＵＥと同期後、送信ＵＥとの間でＳＬでのユニキャスト通信あるいはグループキャスト通信のＲＲＣ設定を設立してもよい。このようにすることで、同期をとるＵＥと、ＳＬ通信を行うＵＥとを同じにできる。このため、受信ＵＥは受信処理を簡易にでき、消費電力を低減可能となる。
【０６５７】
送信ＵＥが、ユニキャスト通信あるいはグループキャスト通信開始の際に、ＳＬＳＳあるいはＳＬＳＳとＰＢＣＨを送信してもよい。受信ＵＥは、該ＳＬＳＳを受信することで同期をとるとよい。該ＳＬＳＳとＰＢＣＨを受信することで同期処理を行ってもよい。このようにすることで、ユニキャスト通信あるいはグループキャスト通信処理として、受信ＵＥは送信ＵＥと同期をとることが可能となる。このため、同期をとるＵＥとＳＬ通信を行うＵＥとを同じにできる。受信ＵＥは受信処理を簡易にでき、消費電力を低減可能となる。
【０６５８】
送信ＵＥと異なるＵＥを、同期をとるＵＥとしていた場合、ユニキャスト通信あるいはグループキャスト通信を行う場合、受信ＵＥは、同期をとるＵＥを送信ＵＥに変更してもよい。受信ＵＥは、送信ＵＥを検出した場合に、同期をとるＵＥを送信ＵＥに変更してもよい。送信ＵＥの検出には、前述の送信ＵＥからのＰＳＣＣＨを用いてもよいし、ＳＳＬＳとＰＳＢＣＨを用いてもよい。このようにすることで、同期をとるＵＥとＳＬ通信を行うＵＥとを同じにできる。
【０６５９】
本実施の形態８で開示したような方法とすることで、送信ＵＥと受信ＵＥとで、たとえＳＬにおけるユニキャスト通信あるいはグループキャスト通信が不可能となった場合でも、通信が正常に終了あるいは再開可能となる。
【０６６０】
実施の形態９．
ＮＲで新たにＲＲＣ＿Ｉｎａｃｔｉｖｅ状態が設けられた（非特許文献１６（ＴＳ３８．３００））。ＵＥがＲＲＣ＿Ｉｎａｃｔｉｖｅ状態にいる場合の、ＳＬ通信用ＳＬＲＰはどのように設定されるかは不明である。これについては未だ開示が無い。ＳＬＲＰの設定がなされないと、ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態にいるＵＥがＳＬ通信を行うことができなくなる。ここではこのような課題を解決する方法を開示する。
【０６６１】
ＲＲＣ＿ｉｎａｃｔｉｖｅ状態で用いるＳＬＲＰを設ける。ｇＮＢはＵＥに対して、ＲＲＣ＿ｉｎａｃｔｉｖｅ状態で用いるＳＬＲＰ構成を通知してもよい。該通知には、前述のＳＬＲＰ構成の通知方法を適用するとよい。あるいは、ＲＲＣ＿ｉｎａｃｔｉｖｅ状態で用いるＳＬＲＰ構成が、ＵＥにあらかじめ設定されてもよい。ＲＲＣ＿ｉｎａｃｔｉｖｅ状態で用いるＳＬＲＰ構成が、他のＳＬＲＰ構成とともに、通知あるいは設定されてもよい。
【０６６２】
このようにすることで、新たに設けられたＲＲＣ＿Ｉｎａｃｔｉｖｅ状態にいるＵＥがＳＬＲＰを用いることが可能となり、ＳＬＲＰのリソースを用いてＳＬ通信が可能となる。
【０６６３】
しかし、ＲＲＣ＿ｉｎａｃｔｉｖｅ状態で用いるＳＬＲＰを別途設けることは、リソースの使用効率の低下を招く。このような課題を解決する方法を開示する。
【０６６４】
ＲＲＣ＿ｉｎａｃｔｉｖｅ状態のＵＥは、ＳＬ通信用にｇＮＢからＳＩＢで報知されるＳＬＲＰ構成を用いる。ＵＥはセル間移動により、移動先のＳＬＲＰ構成が含まれるＳＩＢを受信して、該ＳＬＲＰ構成を用いる。このようにすることで、ＲＲＣ＿ｉｎａｃｔｉｖｅ状態で用いるＳＬＲＰを別途設ける必要が無くなり、リソース使用効率の低下を回避できる。
【０６６５】
他の方法を開示する。ＲＲＣ＿ｉｎａｃｔｉｖｅのＵＥは、ｇＮＢからＲＲＣシグナリングで通知されたＳＬＲＰ構成を用いてもよい。ＵＥ毎のＳＬＲＰ構成を設けてもよい。ｇＮＢは、ＵＥ毎のＳＬＲＰ構成を設定して、ＲＲＣシグナリングでＵＥに通知する。該通知は、ＵＥがＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態の時に行われる。
【０６６６】
ＵＥは、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態の時にｇＮＢよりＲＲＣシグナリングで受信したＳＬＲＰ構成を、ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態移行時も保持する。ＵＥは該ＳＬＲＰ構成を、ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態移行時もリリースしない。このようにすることで、ＲＲＣ＿ｉｎａｃｔｉｖｅのＵＥが、ｇＮＢからＲＲＣシグナリングで通知されたＳＬＲＰ構成を用いることが可能となる。
【０６６７】
ＵＥ毎のＳＬＲＰ構成はＲＮＡ内で設定可能としてもよい。ＲＲＣ＿ＩｎａｃｔｉｖｅのＵＥは、ＲＮＡ内のセル間移動ではＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態に移行しなくてもよい。ＲＮＡ内で設定可能とすることで、ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態のＵＥがセル間移動時にＳＬＲＰ構成を受信するためＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態に移行しなくて済む。ＵＥの処理の複雑化を回避できる。
【０６６８】
ｇＮＢは隣接ｇＮＢに対してＳＬＲＰ構成を通知してもよい。ｇＮＢは、セル毎のＳＬＲＰ構成を通知してもよい。たとえばｇＮＢ間でＳＬＲＰを調整可能となる。また、ｇＮＢは、ＲＲＣシグナリングで通知したＳＬＲＰ構成を通知してもよい。ｇＮＢは、ＵＥコンテキスト情報に、該ＳＬＲＰ構成を含めてもよい。ｇＮＢは隣接ｇＮＢに対して、該ＳＬＲＰ構成を含むＵＥコンテキスト情報を通知してもよい。このようにすることで、ＲＲＣシグナリングで通知したＳＬＲＰ構成をｇＮＢ間で共有することが可能となる。
【０６６９】
ｇＮＢは隣接ｇＮＢに対して、セル毎のＳＬＲＰ構成、および／あるいは、ＲＲＣシグナリングで通知したＳＬＲＰ構成を要求してもよい。また、ｇＮＢは、ＳＬＲＰ構成を含むＵＥコンテキスト情報を要求してもよい。これらの要求に応じて隣接ｇＮＢは、概要求を行ったｇＮＢに、ＳＬＲＰ構成を通知する。このようにすることで、たとえばｇＮＢは、ＳＬＲＰ構成を決定するために、隣接ｇＮＢのＳＬＲＰ構成を要求することができる。
【０６７０】
該ＳＬＲＰ構成を通知する隣接ｇＮＢは、同じＲＮＡ内のｇＮＢであってもよい。また、該ＳＬＲＰ構成を要求する隣接ｇＮＢは、同じＲＮＡ内のｇＮＢであってもよい。このようにすることで、ＲＲＣシグナリングで通知したＳＬＲＰ構成を同一ＲＮＡ内のｇＮＢ間で共有することが可能となる。
【０６７１】
このような方法とすることで、ＵＥは、セルを変更する毎に、変更先でのＳＬＲＰ構成を含むＳＩＢを受信しなくて済む。また、ｇＮＢはＵＥ個別にＳＬＲＰ構成を設定することが可能となるため、ＲＮＡ内で同じＳＬＲＰ構成を用いることが可能となる。
【０６７２】
他の方法を開示する。ＲＮＡ用のＳＬＲＰ構成を設けてもよい。ＲＮＡ用のＳＬＲＰ構成は、ＲＮＡ毎としてもよい。ＲＮＡ用のＳＬＲＰ構成は、ＲＮＡ内で使用可能なＳＬＲＰとする。ＲＮＡ用のＳＬＲＰ構成はあらかじめ決めておいてもよい。ＲＮＡ用のＳＬＲＰ構成は、ＵＥに対して予め設定しておいてもよい。ＲＲＣ＿ＩｎａｃｔｉｖｅのＵＥは、ＲＮＡ内でＲＮＡ用ＳＬＲＰ構成を用いる。
【０６７３】
ＲＮＡ用ＳＬＲＰ構成は、コアネットワークが決めて、ＲＮＡ内の各ｇＮＢに通知してもよい。ＲＮＡ用ＳＬＲＰは、一つのｇＮＢが決めて、ＲＮＡ内の各ｇＮＢに通知してもよい。ｇＮＢはＵＥに対して、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ時に、ＲＲＣシグナリングでＲＮＡ用のＳＬＲＰ構成を通知するとよい。ＲＮＡ用のＳＬＲＰ構成は、前述のＵＥがＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態で通知されるＳＬＲＰ構成と異なっていてもよい。あるいは一部または全部が同じであってもよい。ＲＲＣ＿ＩｎａｃｔｉｖｅのＵＥは、ＲＮＡ内でＲＮＡ用ＳＬＲＰ構成を用いる。
【０６７４】
ｇＮＢはＵＥに対して、ＲＮＡ用のＳＬＲＰ構成をＳＩＢに含めて報知してもよい。ＲＲＣ＿ＩｎａｃｔｉｖｅのＵＥは、ＲＮＡ内でＲＮＡ用ＳＬＲＰ構成を用いる。ＲＮＡ用とすることで、ＵＥは、ＲＮＡ内でのセル間移動では、ＲＮＡ用のＳＬＲＰ構成を含むＳＩＢを受信しなくてよい。セル間移動時のＵＥの処理を簡易にすることができる。
【０６７５】
このようにすることで、たとえば、ＵＥ個別のＳＬＲＰ構成ではなく、ＲＮＡ毎のＳＬＲＰ構成を設定可能となる。ＳＬＲＰ構成を多数用意する必要が無くなるため、リソース使用効率を向上させることができる。
【０６７６】
ＬＴＥでは、ＳＬＲＰの一つとして例外的プール（Exceptional Pool）（以降、ＳＬＥＰと称す）が導入されている。ＳＬＥＰは、ＲＬＦ中、ＲＲＣ＿ＩｄｌｅからＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態への遷移中、リソースプールの変更中、ＨＯ中、セル再選択中に用いられる。３ＧＰＰにおいて、ＮＲのＳＬにおいても、ＳＬＥＰをサポートするかどうかが提案されている（非特許文献３１（Ｒ２−１８１５４４１））。しかし、ＮＲのＳＬにおけるＳＬＥＰの設定方法や使用方法についてはなんら議論が無く、なんら開示されていない。
【０６７７】
前述のように、ＮＲでは新たにＲＲＣ＿Ｉｎａｃｔｉｖｅ状態が設けられている。このようにＬＴＥでは無く、ＮＲで新たに設けられたＲＲＣ＿Ｉｎａｃｔｉｖｅ状態に関連するＳＬＥＰの設定方法や使用方法は不明となる。ここでは、このような課題を解決する方法を開示する。
【０６７８】
ＳＬ通信用にＳＬＥＰを用いる場合、ＵＥはＳＬＥＰのＳＬ通信用リソースをランダムに選択する。リソースセンシングによるリソース選択を不要とするとよい。ＵＥは、ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態からＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態への遷移中は、ＳＬＥＰを用いる。ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態からＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態への遷移には、ｒｅｓｕｍｅ処理を実施する。該ｒｅｓｕｍｅ処理中はＳＬＥＰを用いるとしてもよい。このようにすることで、ＵＥは、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ遷移時にＲＲＣシグナリングによるＳＬＲＰ構成を受信する前、あるいは、該ＳＬＲＰ構成からリソース選択する前に、ＳＬＥＰを用いることが可能となる。
【０６７９】
他の方法を開示する。ＵＥは、ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態からＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態への遷移中は、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態で通知されたＳＬＲＰを用いる。該遷移以前にＳＬＲＰ構成から選択したリソースを、該遷移中も用いてもよい。ＵＥは、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態からＲＲＣ＿Ｉｎａｃｔｉｖｅ状態への遷移後、ＲＲＣ＿Ｃｏｎｎｅｃｅｄ状態で通知されたＳＬＲＰを保持するとよい。これにより、該ＳＬＲＰを用いることが可能となる。
【０６８０】
このようにすることで、ＵＥは、ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ遷移時に、ＲＲＣシグナリングによるＳＬＲＰ構成を受信しなくてすむ。また、ｇＮＢはＵＥに対して、ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態からＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ遷移毎に、ＲＲＣシグナリングによってＳＬＲＰ構成を送信する必要は無くなる。必要な時、たとえばＳＬＲＰ構成を変更したいような場合に通知をすればよくなる。このようにすることで、ＵＥとｇＮＢとの間のシグナリングを削減可能となる。
【０６８１】
ＲＲＣ  Ｉｄｌｅ状態からＲＲＣ＿Ｉｎａｃｔｉｖｅ状態の遷移が設けられた場合、該遷移中は、ＳＬＥＰを用いるとしてもよい。たとえば、ＲＮＡ用のＳＬＲＰがＳＩＢで報知されるような場合に、該ＳＩＢを受信するまで、あるいは、該ＳＩＢで報知されたＳＬＲＰ構成からリソース選択するまでに発生するＳＬ通信において、ＳＬＥＰを用いることが可能となる。
【０６８２】
このように新たな状態遷移中にＳＬＥＰを用いることで、ＵＥが該遷移中に早期にＳＬ通信を実行可能となる。
【０６８３】
ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態のＵＥは、セル間移動においてセルリセレクションを実施する。ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態のＵＥは、セルリセレクション時にＳＬＥＰを用いる。ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態でＳＩＢで報知されたＳＬＲＰを用いる場合に、ＵＥは、セルリセレクション時にＳＬＥＰを用いるとしてもよい。ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態でＲＲＣシグナリングで通知されたＳＬＲＰを用いる場合、ＵＥは、セルリセレクション時にＳＬＥＰを用いるとしてもよい。ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態でＲＮＡ用のＳＬＲＰを用いる場合、ＵＥは、当該ＲＮＡ内のセルリセレクション時にＲＮＡ用のＳＬＲＰを用いるとしてもよい。
【０６８４】
このようにすることで、セルリセレクション時にＲＲＣ＿Ｉｎａｃｔｉｖｅ状態のＵＥは、早期にＳＬ通信を実行可能となる。
【０６８５】
ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態のＵＥは、ＲＮＡ外へのセルリセレクション時にはＳＬＥＰを用いるとしてもよい。ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態のＵＥがＲＮＡ外に移動した場合、ＵＥは、ＲＮＡ  Ｕｐｄａｔｅ処理（RNA Update Procedure）を起動する。ＵＥは、ＲＮＡ  Ｕｐｄａｔｅ処理中は、ＳＬＥＰを用いるとしてもよい。ＲＮＡ外への移動先セルで、ＳＩＢで報知されたＳＬＲＰを受信するまで、あるいは、該ＳＬＲＰ構成からリソース選択が行われるまでは、ＵＥはＳＬＥＰを用いるとしてもよい。
【０６８６】
ＵＥは、ＲＮＡ外への移動先セルで、ＲＲＣシグナリングでＵＥ毎のＳＬＲＰを入手するまで、あるいは、該ＳＬＲＰ上でのリソース選択が行われるまでは、ＳＬＥＰを用いるとしてもよい。ＵＥは、ＲＮＡ外への移動先セルで、ＲＲＣシグナリングでＲＮＡ毎のＳＬＲＰを入手するまで、あるいは、該ＳＬＲＰ上でのリソース選択が行われるまでは、ＳＬＥＰを用いるとしてもよい。ＲＮＡ外への移動先セルにおける、ＵＥ毎あるいはＲＮＡ毎のＳＬＲＰ構成は、ＲＮＡ  Ｕｐｄａｔｅ処理におけるＲＲＣＲｅｌｅａｓｅ  ｗｉｔｈ  ｓｕｓｐｅｎｄ  ｉｎｄｉｃａｔｉｏｎで、ｇＮＢからＵＥに対して通知してもよい。
【０６８７】
このようにすることで、ＲＮＡ外への移動時も、ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態のＵＥは早期にＳＬ通信を実行可能となる。
【０６８８】
ＵＥがＲＮＡ間移動時、移動先ＲＮＡのｇＮＢは、ＵＥ毎のＳＬＲＰ構成を、移動前ＲＮＡのｇＮＢに対して要求してもよい。該要求に対象となるＵＥの識別子を含めるとよい。該要求は、移動先ＲＮＡのｇＮＢがＲＮＡ  Ｕｐｄａｔｅ処理を受信した場合に行うとしてもよい。該要求を受信した移動前ＲＮＡのｇＮＢは、該要求に含まれるＵＥのＵＥ毎のＳＬＲＰ構成を、要求したｇＮＢに対して通知する。このようにすることで、たとえば、ＲＮＡ間移動先ｇＮＢは、ＲＮＡ移動先ｇＮＢで用いられていたＳＬＲＰ構成を考慮したＳＬＲＰの設定を可能とする。
【０６８９】
該要求にはＸｎシグナリングを用いてもよい。ＵＥ毎のＳＬＲＰ構成をＵＥ  ｃｏｎｔｅｘｔに含めてもよい。移動先ＲＮＡのｇＮＢは、ＵＥ  ｃｏｎｔｅｘｔを、移動前ＲＮＡのｇＮＢに対して要求してもよい。該要求を受信した移動前ＲＮＡのｇＮＢは、該要求に含まれるＵＥのＵＥ  ｃｏｎｔｅｘｔを、要求したｇＮＢに対して通知する。ＳＬＲＰ構成を含むＵＥ  ｃｏｎｔｅｘｔの要求および通知には、Ｒｅｔｒｉｅｖｅ  ＵＥ  Ｃｏｎｔｅｘｔ  Ｒｅｑｕｅｓｔ、Ｒｅｔｒｉｅｖｅ  ＵＥ  Ｃｏｎｔｅｘｔ  Ｒｅｓｐｏｎｓｅを用いてもよい。既存のメッセージを用いることでｇＮＢ間シグナリング処理を簡易にすることができる。
【０６９０】
ＲＮＡ毎のＳＬＲＰ構成についても同様の方法を適用してもよい。ＵＥがＲＮＡ間移動時、移動先ＲＮＡのｇＮＢは、ＲＮＡ毎のＳＬＲＰ構成を、移動前ＲＮＡのｇＮＢに対して要求してもよい。該要求は、移動先ＲＮＡのｇＮＢがＲＮＡ  Ｕｐｄａｔｅ処理を受信した場合に行うとしてもよい。該要求を受信した移動前ＲＮＡのｇＮＢは、ＲＮＡ毎のＳＬＲＰ構成を、要求したｇＮＢに対して通知する。該要求にはＸｎシグナリングを用いてもよい。新たなメッセージを設けてもよい。このようにすることで、たとえば、ＲＮＡ間移動先ｇＮＢは、ＲＮＡ移動先ｇＮＢで用いられていたＳＬＲＰ構成を考慮したＳＬＲＰの設定を可能とする。
【０６９１】
ＬＴＥ用のＳＬＥＰとＮＲ用のＳＬＥＰを別に設けるとよい。ＬＴＥ用のＳＬＥＰ構成とＮＲ用のＳＬＥＰ構成とを異ならせることができる。ＬＴＥのセルからＮＲのセルへのハンドオーバ中は、ＮＲ用のＳＬＥＰ構成を用いるとよい。ＮＲのセルからＬＴＥのセルへのハンドオーバ中は、ＬＴＥ用のＳＬＥＰ構成を用いるとよい。ＲＡＴ（Radio Access Technology）間でのハンドオーバ中は、ハンドオーバ先のセルのＳＬＥＰ構成に従うと良い。ＵＥが、ハンドオーバ先でＳＬＲＰ構成を受信するまで、あるいは、ハンドオーバ先のＳＬＲＰ構成内でリソースを選択するまでの間、ハンドオーバ先のセルのＳＬＥＰ構成を用いることで、ハンドオーバ先のシステムに適したＳＬＥＰを用いたＳＬ通信を可能にする。
【０６９２】
ＲＡＴ間のセルリセレクションにおいても同様の方法を適用してもよい。ＬＴＥのセルからＮＲのセルへのセルリセレクション中は、ＮＲ用のＳＬＥＰ構成を用いるとよい。ＮＲのセルからＬＴＥのセルへのセルリセレクション中は、ＬＴＥ用のＳＬＥＰ構成を用いるとよい。ＲＡＴ間でのセルリセレクション中は、セルリセレクション先のセルのＳＬＥＰ構成に従うと良い。ＵＥが、セルリセレクション先でＳＬＲＰ構成を受信するまで、あるいは、セルリセレクション先のＳＬＲＰ構成内でリソースを選択するまでの間、セルリセレクション先のセルのＳＬＥＰ構成を用いることで、セルリセレクション先のシステムに適したＳＬＥＰを用いたＳＬ通信を可能にする。
【０６９３】
ＵＥに対して、ＬＴＥの基地局とＮＲの基地局とでＤＣ（Dual Connectivity）が行われる場合は、ＬＴＥ用のＳＬＥＰとＮＲ用のＳＬＥＰのどちらを用いるかを設定可能としてもよい。カバレッジや電波伝搬状況に応じて設定可能となるため、ＳＬ通信における通信品質を向上可能となる。
【０６９４】
本実施の形態９で開示したような方法によって、ＮＲで新たに設けられたＲＲＣ＿ｉｎａｃｔｉｖｅ状態を含めたＳＬＲＰ構成、ＳＬＥＰ構成の設定および使用が可能となる。また、ＬＴＥとＮＲとの間のハンドオーバやセルリセレクションのようなＲＡＴ間の移動処理、あるいは、異なるＲＡＴ間のＤＣにおいてもＳＬＲＰ構成、ＳＬＥＰ構成の設定および使用が可能となる。これにより、多種多様な状況においてＳＬ通信を可能にすることができる。
【０６９５】
実施の形態１０．
前述したように、３ＧＰＰでＴＳＮのサポートが検討されている。ＳＬ通信を行うＵＥ間でも時刻を合わせたい場合が生じる。たとえば、ＳＬでユニキャスト通信を行う車載のＵＥ間や、隊列走行を行っている車載のＵＥグループ間で、時刻を同期させて自動走行用の制御を実施するような場合である。このような場合、ＵＥ間やＵＥグループ間で時刻同期を行うことが必要となる。
【０６９６】
しかし、ＳＬ通信を行うＵＥ間での時刻同期方法はなんら開示されておらず不明である。このため、ＵＥ間で時刻同期が要求されるようなＳＬ通信ができないという問題が生じる。ＴＳＮでＳＬを用いることができないという問題が生じる。本実施の形態１０ではこのような課題を解決する方法を開示する。
【０６９７】
ｇＮＢが、ＳＬ通信のためのＵＥに対して、時刻同期に関する情報を通知する。時刻同期に関する情報は、実施の形態１で開示した情報を適用するとよい。ＴＳＮにおいて、ｇＮＢは時刻同期に関する情報を、ＴＳＮに用いられるＳＩＢに含めて、報知する。たとえばＬＴＥにおいてはＳＩＢ１６が用いられる。ＮＲにおいても同様に、時刻同期に関する情報を、ＳＩＢに含めて、報知してもよい。ＳＬ通信を行うＵＥは、時刻同期に関する情報を含むＳＩＢを受信して、ｇＮＢからの時刻同期情報を取得するとよい。
【０６９８】
ＳＬ通信を行うＵＥ全てが、ＴＳＮに用いられるＳＩＢを受信しなくてもよい。ＳＬ通信を用いたＴＳＮのサービスを行う場合に、該サービスを行うＵＥが、ＴＳＮに用いられるＳＩＢを受信するとよい。ＳＬ通信を用いたＴＳＮのサービスを行うＵＥは、上位レイヤの要求により、ＴＳＮに用いられるＳＩＢを受信し、時刻同期に関する情報を取得する。
【０６９９】
このようにすることで、ＴＳＮをサポートするｇＮＢのカバレッジ内に存在するＳＬ通信を行うＵＥは、時刻同期情報を取得可能となる。このため、該ＵＥ間で時刻を同期させた制御が可能となる。
【０７００】
ｇＮＢからＳＬ通信のためのＵＥに対して時刻同期に関する情報を通知する他の方法を開示する。ＴＳＮにおいて、ｇＮＢは時刻同期に関する情報を、ＳＬ通信に用いられるＳＩＢに含めて、報知する。たとえばＬＴＥにおいてはＳＩＢ１８やＳＩＢ２１が用いられる。ＮＲにおいても同様に、時刻同期に関する情報を、ＳＩＢに含めて、報知してもよい。ＳＬ通信を行うＵＥは、時刻同期に関する情報を含むＳＩＢを受信して、ｇＮＢからの時刻同期情報を取得するとよい。
【０７０１】
ＳＬ通信を用いたＴＳＮのサービスを行うＵＥは、上位レイヤの要求により、ＳＬ通信に用いられるＳＩＢに含まれる時刻同期に関する情報を取得する。このようにすることで、ＴＳＮをサポートするｇＮＢのカバレッジ内に存在するＳＬ通信を行うＵＥは、時刻同期に関する情報を取得可能となる。このため、該ＵＥ間で時刻を同期させた制御が可能となる。
【０７０２】
ＴＳＮをサポートするｇＮＢのカバレッジ外に存在するＵＥは、該ｇＮＢの有する時刻同期に関する情報を受信できない。このような課題を解決する方法を開示する。時刻同期に関する情報を有するＳＬ通信を行うＵＥは、時刻同期に関する情報を送信してもよい。時刻同期に関する情報を有するＵＥは、例えば、ＴＳＮをサポートするｇＮＢから時刻同期に関する情報を受信したＵＥ、他のＵＥから時刻同期に関する情報を受信したＵＥである。
【０７０３】
ｇＮＢから時刻同期に関する情報を受信したＵＥは、取得した時刻同期に関する情報を、他のＳＬ通信を行うＵＥに対して、ＰＣ５シグナリングで通知してもよい。ｇＮＢから時刻同期情報を受信したＵＥは、取得した時刻同期に関する情報を、ＳＬ用報知情報に含めて、送信してもよい。時刻同期に関する情報を含むＳＬ用報知情報送信用に、新たな物理チャネルが設けられてもよい。あるいは、時刻同期に関する情報を含むＳＬ用報知情報送信用として、ＰＳＢＣＨが用いられてもよい。ＰＳＢＣＨが用いられる場合、既存のチャネルを利用でき、制御の複雑化を回避することができる。
【０７０４】
時刻同期に関する情報として、実施の形態１で開示した情報を適用するとよい。時刻誤差情報として、例えば、ＵＥが有するクロック精度等のＵＥにおける時刻誤差を用いて補正した情報を用いるとしてもよい。このようにすることで、ｇＮＢではなく、ＵＥが、ＴＳＮにおける時刻同期情報を送信可能となる。
【０７０５】
ＳＬ通信を行うＵＥは、ｇＮＢのカバレッジ内に存在する場合、ｇＮＢとタイミング同期をとりＳＬＳＳを送信する。タイミング同期をとるｇＮＢが、時刻同期情報を受信するｇＮＢと異なる場合、ＳＬ通信を行うＵＥは、時刻同期情報に関する情報の中の所定のスロットあるいはサブフレームあるいはシステムフレームに関する情報を、タイミング同期により得たスロットあるいはサブフレームあるいはシステムフレームに関する情報に、補正するとよい。このようにすることで、ＳＬ通信を行うＵＥは、自ＵＥがタイミング同期により得たタイミングを用いた時刻同期情報を、設定および送信可能となる。
【０７０６】
タイミング同期をとるｇＮＢを、ＴＳＮをサポートするｇＮＢとしてもよい。たとえば、ＵＥが、ＴＳＮをサポートするｇＮＢとＴＳＮをサポートしていないｇＮＢの両方のカバレッジ内に存在するような場合、タイミング同期をとるｇＮＢを、ＴＳＮをサポートするｇＮＢとしてもよい。たとえ、タイミング同期をとるｇＮＢからの受信電力が、ＴＳＮをサポートするｇＮＢからの受信電力よりも高いとしても、ＴＳＮをサポートするｇＮＢを選択する。
【０７０７】
このようにすることで、ＴＳＮをサポートするｇＮＢを、タイミング同期をとるｇＮＢとすることが可能となる、このため、ＵＥでのスロットタイミング、サブフレームタイミング、システムフレームタイミングを、ＴＳＮをサポートするｇＮＢと同期できるため、時刻同期情報に関する情報の中の所定のスロットあるいはサブフレームあるいはシステムフレームに関する情報を用いることが可能となる。ＵＥでの時刻同期情報送信処理を容易にすることが可能となる。
【０７０８】
時刻同期に関する情報を受信することが可能か否かを判断するため、ＴＳＮをサポートするｇＮＢからの受信電力あるいは受信品質に所定の閾値を設けてもよい。たとえば、該所定の閾値よりも大きい場合、ＵＥは、時刻同期に関する情報を受信することが可能と判断するとよい。いいかえると、ＵＥは、ＴＳＮをサポートするｇＮＢのカバレッジ内に存在することになる。ＴＳＮをサポートするｇＮＢからの受信電力あるいは受信品質が所定の閾値以下の場合、ＵＥは、ＴＳＮをサポートするｇＮＢのカバレッジ外に存在すると判断する。
【０７０９】
ＵＥが、複数のＴＳＮをサポートするｇＮＢから、時刻同期に関する情報を受信可能な場合、受信電力あるいは受信品質の高い方のｇＮＢからの時刻同期に関する情報を取得して用いてもよい。このようにすることで、時刻同期に関する情報をより確実に取得可能となる。
【０７１０】
あるいは、ＵＥが、複数のＴＳＮをサポートするｇＮＢから、時刻同期に関する情報を受信可能な場合、時刻同期情報の中の時刻誤差の少ない方のｇＮＢからの時刻同期に関する情報を取得して用いてもよい。このようにすることで、自ＵＥが時刻同期に関する情報を送信する場合も、より少ない時刻誤差の情報を設定可能となる。より少ない時刻誤差でＴＳＮをサポート可能となる。
【０７１１】
このようにすることで、ＵＥが、ＴＳＮをサポートするｇＮＢのカバレッジ内に存在する場合、ＵＥはｇＮＢからの時刻同期情報を受信して、ＵＥは該時刻同期情報に適宜補正を加えて時刻同期情報を送信可能となる。
【０７１２】
ＴＳＮをサポートするｇＮＢのカバレッジ外に存在するＳＬ通信を行うＵＥは、他のＵＥから送信される時刻同期に関する情報を含むチャネルを受信して、時刻同期に関する情報を取得する。
【０７１３】
時刻同期に関する情報を受信することが可能か否かを判断するため、他のＵＥからの受信電力あるいは受信品質に所定の閾値を設けてもよい。たとえば、該所定の閾値よりも大きい場合、ＵＥは、時刻同期に関する情報を受信することが可能と判断するとよい。そうでない場合は、ＵＥは、時刻同期に関する情報を受信することは不可能と判断する。不可能な場合は、さらに他のＵＥから送信される時刻同期に関する情報を含むチャネルの受信を試みてもよい。
【０７１４】
ＵＥが、複数の時刻同期に関する情報を送信するＵＥから、時刻同期に関する情報を受信可能な場合、受信電力あるいは受信品質の高い方のＵＥからの時刻同期に関する情報を取得して用いてもよい。このようにすることで、時刻同期に関する情報をより確実に取得可能となる。
【０７１５】
あるいは、ＵＥが、複数の時刻同期に関する情報を送信するＵＥから、時刻同期に関する情報を受信可能な場合、時刻同期情報の中の時刻誤差の少ない方のＵＥからの時刻同期に関する情報を取得して用いてもよい。このようにすることで、自ＵＥが時刻同期に関する情報を送信する場合も、より少ない時刻誤差の情報を設定可能となる。より少ない時刻誤差でＴＳＮをサポート可能となる。
【０７１６】
他のＵＥから時刻同期に関する情報を取得したＵＥは、取得した時刻同期に関する情報を、ＳＬ用報知情報に含めて、送信してもよい。この方法は、前述のｇＮＢから時刻同期情報を受信した場合の処理を適宜適用するとよい。同様の効果を得ることができる。このようにすることで、ＳＬ通信を行うＵＥは、時刻同期に関する情報を受信し、また送信することが可能となる。
【０７１７】
このようにすることで、ＳＬ通信を行うＵＥは、たとえＴＳＮをサポートするｇＮＢのカバレッジ内に存在しなくても、他のＵＥから時刻同期に関する情報を取得することが可能となる。
【０７１８】
ＳＬ通信を行うＵＥが、時刻同期に関する情報を送信する他の方法を開示する。ＳＬ通信を行うＵＥは、時刻同期に関する情報を、ＳＣＩに含めて、ＰＳＣＣＨで送信してもよい。ＳＬ通信を行うＵＥは、送信ＵＥからのＰＳＣＣＨを受信して、時刻同期に関する情報を取得する。このようにＰＳＣＣＨを用いることで、受信ＵＥは、ＳＬ通信用データ受信時に、データ受信に必要なＰＳＣＣＨから、時刻同期に関する情報を取得可能となる。時刻同期に関する情報を早期に送受信可能となる。また、時刻同期に関する情報取得のためにＰＳＢＣＨや他のチャネルの受信を行わなくて済むため、ＵＥでの時刻同期処理を簡易にできる。
【０７１９】
時刻同期に関する情報を、前述に開示したＳＣＩ１に含めてもよい。時刻同期に関する情報を、ＳＣＩ１に含めて、ＰＳＣＣＨ１で通知してもよい。ＳＬ通信においてリソースプールが設定された全ＵＥが、時刻同期に関する情報を受信可能となる。あるいは、時刻同期に関する情報を、ＳＣＩ２に含めてもよい。時刻同期に関する情報を、ＳＣＩ２に含めて、ＰＳＣＣＨ２で通知してもよい。ユニキャスト通信において対向するＵＥ、あるいは、グループキャスト通信において対向するＵＥグループ内のＵＥのみが、該情報を受信可能となる。時刻同期を受信して、時刻を同期させた制御を行うＵＥが前述のように限定されるような場合に有効である。
【０７２０】
ＳＬ通信を行うＵＥが、時刻同期に関する情報を送信する他の方法を開示する。ＳＬ通信を行うＵＥは、時刻同期に関する情報を、ＳＬ通信におけるＲＲＣシグナリングを用いて送信してもよい。たとえば、ユニキャスト通信やグループキャスト通信においてＵＥ間でＲＲＣ接続が実施される場合、対向ＵＥとの間で行われるＲＲＣシグナリングを用いて、時刻同期に関する情報を送信してもよい。ＳＬ通信の送信ＵＥは、時刻同期に関する情報を、ＲＲＣシグナリングに含めて、受信ＵＥに送信する。受信ＵＥは、送信ＵＥからのＲＲＣシグナリングに含まれる時刻同期に関する情報を取得する。
【０７２１】
このようにすることで、ＲＲＣ接続が実施される場合に、ユニキャスト通信やグループキャスト通信を行うＵＥ間で時刻を同期させた制御を可能となる。ＲＲＣシグナリングを用いるため、時刻同期に関する情報量を増やすことが可能となる。
【０７２２】
ＳＬ通信を行うＵＥが、時刻同期に関する情報を送信する他の方法を開示する。ＵＥは、時刻同期に関する情報を、ＳＬ通信におけるＭＡＣシグナリングを用いて、送信してもよい。たとえば、ユニキャスト通信やグループキャスト通信において、対向ＵＥとの間でＭＡＣシグナリングを用いて、時刻同期に関する情報を送信してもよい。ＳＬ通信の送信ＵＥは、時刻同期に関する情報を、ＭＡＣシグナリングに含めて、受信ＵＥに送信する。受信ＵＥは、送信ＵＥからのＭＡＣシグナリングに含まれる時刻同期情報を取得する。ＭＡＣシグナリングはＨＡＲＱフィードバックがサポートされてもよい。このようにすることで、時刻同期に関する情報の受信誤り率を低減させることが可能となる。
【０７２３】
このようにすることで、ＴＳＮをサポートするｇＮＢのカバレッジ外に存在するＵＥも、ＴＳＮをサポートするｇＮＢから時刻同期に関する情報を受信したＵＥや、他の時刻同期に関する情報を有するＵＥから、時刻同期に関する情報を受信可能となる。ＴＳＮをサポートするｇＮＢのカバレッジ内外に存在するＵＥ間で時刻を同期させた制御を可能にする。
【０７２４】
前述の各実施の形態およびその変形例は、本発明の例示に過ぎず、本発明の範囲内において、各実施の形態およびその変形例を自由に組合せることができる。また各実施の形態およびその変形例の任意の構成要素を適宜変更または省略することができる。
【０７２５】
例えば、前述の各実施の形態およびその変形例において、サブフレームは、第５世代基地局通信システムにおける通信の時間単位の一例である。スケジューリング単位であってもよい。前述の各実施の形態およびその変形例において、サブフレーム単位として記載している処理を、ＴＴＩ単位、スロット単位、サブスロット単位、ミニスロット単位として行ってもよい。
【０７２６】
本発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、本発明がそれに限定されるものではない。例示されていない無数の変形例が、本発明の範囲から外れることなく想定され得るものと解される。
【符号の説明】
【０７２７】
２００  通信システム、２０２  通信端末装置、２０３  基地局装置。
【図１】
2020145248.tif 000003
【図２】
2020145248.tif 000004
【図３】
2020145248.tif 000005
【図４】
2020145248.tif 000006
【図５】
2020145248.tif 000007
【図６】
2020145248.tif 000008
【図７】
2020145248.tif 000009
【図８】
2020145248.tif 000010
【図９】
2020145248.tif 000011
【図１０】
2020145248.tif 000012
【図１１】
2020145248.tif 000013
【図１２】
2020145248.tif 000014
【図１３】
2020145248.tif 000015
【図１４】
2020145248.tif 000016
【図１５】
2020145248.tif 000017
【図１６】
2020145248.tif 000018
【図１７】
2020145248.tif 000019
【図１８】
2020145248.tif 000020
【図１９】
2020145248.tif 000021
【図２０】
2020145248.tif 000022
【図２１】
2020145248.tif 000023
【図２２】
2020145248.tif 000024
【図２３】
2020145248.tif 000025
【図２４】
2020145248.tif 000026
【図２５】
2020145248.tif 000027
【図２６】
2020145248.tif 000028
【図２７】
2020145248.tif 000029
【図２８】
2020145248.tif 000030
【図２９】
2020145248.tif 000031
【図３０】
2020145248.tif 000032
【図３１】
2020145248.tif 000033
【図３２】
2020145248.tif 000034
【図３３】
2020145248.tif 000035
【図３４】
2020145248.tif 000036
【図３５】
2020145248.tif 000037
【図３６】
2020145248.tif 000038
【図３７】
2020145248.tif 000039
【図３８】
2020145248.tif 000040
【図３９】
2020145248.tif 000041
【図４０】
2020145248.tif 000042
【図４１】
2020145248.tif 000043
【図４２】
2020145248.tif 000044
【国際調査報告】
2020145248.tif 000045
2020145248.tif 000046
2020145248.tif 000047
2020145248.tif 000048