JP2019511158A - サイドリンクディスカバリオペレーションに参加するＰｒｏＳｅ対応ＵＥのための改良されたアップリンクＨＡＲＱ動作 - Google Patents

サイドリンクディスカバリオペレーションに参加するＰｒｏＳｅ対応ＵＥのための改良されたアップリンクＨＡＲＱ動作 Download PDF

Info

Publication number
JP2019511158A
JP2019511158A JP2018541403A JP2018541403A JP2019511158A JP 2019511158 A JP2019511158 A JP 2019511158A JP 2018541403 A JP2018541403 A JP 2018541403A JP 2018541403 A JP2018541403 A JP 2018541403A JP 2019511158 A JP2019511158 A JP 2019511158A
Authority
JP
Japan
Prior art keywords
transmission
user terminal
data packet
transmission protocol
retransmission
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2018541403A
Other languages
English (en)
Other versions
JP6840764B2 (ja
Inventor
ヨアヒム ロアー
ヨアヒム ロアー
マリック プラティーク バス
マリック プラティーク バス
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JP2019511158A publication Critical patent/JP2019511158A/ja
Application granted granted Critical
Publication of JP6840764B2 publication Critical patent/JP6840764B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/08—Arrangements for detecting or preventing errors in the information received by repeating transmission, e.g. Verdan system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1825—Adaptation of specific ARQ protocol parameters according to transmission conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1887—Scheduling and prioritising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1864—ARQ related signaling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices

Landscapes

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

Abstract

本発明は、アップリンクデータパケット送信のための改良された送信プロトコルに関する。送信プロトコルの送信カウンタが、ユーザ端末がデータパケットについて行った送信回数を数える。ユーザ端末は、サイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。ユーザ端末のプロセッサは、送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したために行われなかったかを判定する。衝突がある場合、プロセッサは、データパケットの衝突する再送信が該データパケットについては送信プロトコルの送信カウンタをインクリメントしないように送信カウンタを動作させる。

Description

本開示は、特にＰｒｏＳｅ対応ユーザ端末においてアップリンクデータ送信の送信プロトコルを実行する方法に関する。また、本開示は、本明細書に記載された方法に関与するユーザ機器および基地局を提供している。
［ＬＴＥ（Long Term Evolution）］
ＷＣＤＭＡ（登録商標）無線アクセス技術をベースとする第３世代移動通信システム（３Ｇ）は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展・進化させるうえでの最初のステップとして、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ：High-Speed Downlink Packet Access）と、エンハンストアップリンク（高速アップリンクパケットアクセス（ＨＳＵＰＡ：High-Speed Uplink Packet Access）とも称する）とが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。
ユーザからのますます増大する需要に対応し、新しい無線アクセス技術に対する競争力を確保する目的で、３ＧＰＰは、ＬＴＥと称される新しい移動通信システムを導入した。ＬＴＥは、今後１０年間にわたり、データおよびメディアの高速伝送ならびに大容量の音声サポートに要求されるキャリアを提供するように設計されている。高いビットレートを提供する能力は、ＬＴＥにおける重要な方策である。
ＬＴＥに関する作業項目（ＷＩ：working item）の仕様は、Ｅ−ＵＴＲＡ（Evolved UMTS Terrestrial Radio Access）およびＥ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network）と称され、最終的にリリース８（ＬＴＥリリース８）として公開される。ＬＴＥシステムは、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークであり、ＩＰベースの全機能を低遅延かつ低コストで提供する。ＬＴＥでは、与えられたスペクトルを用いてフレキシブルなシステム配備を達成するために、スケーラブルな複数の送信帯域幅（例えば、１．４ＭＨｚ、３．０ＭＨｚ、５．０ＭＨｚ、１０．０ＭＨｚ、１５．０ＭＨｚ、および２０．０ＭＨｚ）が指定されている。ダウンリンクには、ＯＦＤＭ（Orthogonal Frequency Division Multiplexing：直交周波数分割多重）をベースとする無線アクセスが採用されている。かかる無線アクセスを採用する理由は、この無線アクセスが低いシンボルレートのため本質的にマルチパス干渉（ＭＰＩ：Multipath Interference）を受けにくいこと、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）が使用されていること、および、さまざまな送信帯域幅の構成に対応可能なことである。アップリンクには、ＳＣ−ＦＤＭＡ（Single-Carrier Frequency Division Multiple Access：シングルキャリア周波数分割多元接続）をベースとする無線アクセスが採用されている。ユーザ機器（ＵＥ）の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるからである。ＬＴＥリリース８／９では、数多くの主要なパケット無線アクセス技術（例えば、ＭＩＭＯ（Multiple-Input Multiple-Output）チャネル伝送技術）が採用され、高効率の制御シグナリング構造が達成されている。
［ＬＴＥのアーキテクチャ］
ＬＴＥの全体的なアーキテクチャは、図１に示してある。Ｅ−ＵＴＲＡＮは、ｅＮｏｄｅＢから構成され、ｅＮｏｄｅＢは、ユーザ機器（ＵＥ：User Equipment）向けの、Ｅ−ＵＴＲＡのユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のプロトコルを終端させる。ｅＮｏｄｅＢ（ｅＮＢ）は、物理（ＰＨＹ）レイヤ、媒体アクセス制御（ＭＡＣ：Medium Access Control）レイヤ、無線リンク制御（ＲＬＣ：Radio Link Control）レイヤ、およびパケットデータ制御プロトコル（ＰＤＣＰ：Packet Data Control Protocol）レイヤ（これらのレイヤはユーザプレーンのヘッダ圧縮および暗号化の機能を含む）をホストする。ｅＮＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ：Radio Resource Control）機能も提供する。ｅＮＢは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクサービス品質（ＱｏＳ：Quality of Service）の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化／復号、ダウンリンク／アップリンクのユーザプレーンパケットヘッダの圧縮／復元など、多くの機能を実行する。複数のｅＮｏｄｅＢは、Ｘ２インタフェースによって互いに接続されている。
また、複数のｅＮｏｄｅＢは、Ｓ１インタフェースによってＥＰＣ（Evolved Packet Core）、より具体的には、Ｓ１−ＭＭＥによってＭＭＥ（Mobility Management Entity：モビリティ管理エンティティ）、Ｓ１−Ｕによってサービングゲートウェイ（ＳＧＷ：Serving Gateway）に接続されている。Ｓ１インタフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多関係をサポートする。ＳＧＷは、ユーザデータパケットをルーティングして転送する一方で、ｅＮｏｄｅＢ間のハンドオーバー時におけるユーザプレーンのモビリティアンカーとして機能し、さらに、ＬＴＥと他の３ＧＰＰ技術との間のモビリティのためのアンカー（Ｓ４インタフェースを終端させ、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間でトラフィックを中継する）として機能する。ＳＧＷは、アイドル状態のユーザ機器に対しては、ダウンリンクデータ経路を終端させ、そのユーザ機器へのダウンリンクデータが到着したときにページングをトリガする。ＳＧＷは、ユーザ機器のコンテキスト（例えばＩＰベアラサービスのパラメータ、ネットワーク内部ルーティング情報）を管理および格納する。さらに、ＳＧＷは、合法的傍受の場合にユーザトラフィックの複製を実行する。
ＭＭＥは、ＬＴＥのアクセスネットワークの主要な制御ノードである。ＭＭＥは、アイドルモードのユーザ機器の追跡およびページング手順（再送信を含む）の役割を担う。ＭＭＥは、ベアラのアクティブ化／非アクティブ化プロセスに関与し、さらには、最初のアタッチ時と、コアネットワーク（ＣＮ：Core Network）ノードの再配置を伴うＬＴＥ内ハンドオーバー時とに、ユーザ機器のＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングはＭＭＥにおいて終端され、ＭＭＥは、一時的なＩＤを生成してユーザ機器に割り当てる役割も担う。ＭＭＥは、サービスプロバイダの公衆陸上移動網（ＰＬＭＮ：Public Land Mobile Network）に入るためのユーザ機器の認証をチェックし、ユーザ機器のローミング制約を実施する。ＭＭＥは、ＮＡＳシグナリングの暗号化／完全性保護においてネットワーク内の終端点であり、セキュリティキーの管理を行う。シグナリングの合法的傍受も、ＭＭＥによってサポートされる。さらに、ＭＭＥは、ＬＴＥのアクセスネットワークと２Ｇ／３Ｇのアクセスネットワークとの間のモビリティのための制御プレーン機能を提供し、ＳＧＳＮからのＳ３インタフェースを終端させる。さらに、ＭＭＥは、ローミングするユーザ機器のためのホームＨＳＳに向かうＳ６ａインタフェースを終端させる。
［ＬＴＥにおけるコンポーネントキャリアの構造］
３ＧＰＰ ＬＴＥシステムのダウンリンクコンポーネントキャリアは、いわゆるサブフレームにおける時間−周波数領域でさらに分割される。３ＧＰＰ ＬＴＥでは、各サブフレームは、図２に示すように２つのダウンリンクスロットに分割されており、第１のダウンリンクスロットが、第１のＯＦＤＭシンボル内に制御チャネル領域（ＰＤＣＣＨ領域）を含んでいる。各サブフレームは、時間領域における所定の数のＯＦＤＭシンボルから構成され（３ＧＰＰ ＬＴＥ（リリース８）では１２個または１４個のＯＦＤＭシンボル）、各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に広がる。したがって、ＯＦＤＭシンボルそれぞれは、それぞれのサブキャリアで送信される複数の変調シンボルから構成される。ＬＴＥでは、各スロットにおける送信信号は、ＮＤＬ ＲＢ×ＮＲＢ ｓｃ本のサブキャリアとＮＤＬ ｓｙｍｂ個のＯＦＤＭシンボルのリソースグリッドによって記述される。ＮＤＬ ＲＢは、帯域幅の中のリソースブロックの数である。数ＮＤＬ ＲＢは、セルにおいて設定されているダウンリンク送信帯域幅に依存し、Ｎｍｉｎ，ＤＬ ＲＢ≦ＮＤＬ ＲＢ≦Ｎｍａｘ，ＤＬ ＲＢを満たし、この場合、Ｎｍｉｎ，ＤＬ ＲＢ＝６およびＮｍａｘ，ＤＬ ＲＢ＝１１０は、それぞれ、現在のバージョンの仕様によってサポートされている最小ダウンリンク帯域幅および最大ダウンリンク帯域幅である。ＮＲＢ ｓｃは、１個のリソースブロックの中のサブキャリアの数である。通常のサイクリックプレフィックスのサブフレーム構造の場合、ＮＲＢ ｓｃ＝１２、ＮＤＬ ｓｙｍｂ＝７である。
例えば３ＧＰＰ ＬＴＥにおいて使用されるような（例えば、ＯＦＤＭを使用する）マルチキャリア通信システムを想定すると、スケジューラによって割り当てることができるリソースの最小単位は、１つの「リソースブロック」である。物理リソースブロック（ＰＲＢ：Physical Resource Block）は、図２に例示したように、時間領域における連続するＯＦＤＭシンボル（例えば７個のＯＦＤＭシンボル）および周波数領域における連続するサブキャリア（例えばコンポーネントキャリアの１２本のサブキャリア）として定義される。したがって、３ＧＰＰ ＬＴＥ（リリース８）では、物理リソースブロックはリソースエレメントから構成され、時間領域における１つのスロットおよび周波数領域における１８０ｋＨｚに対応する（ダウンリンクリソースグリッドに関するさらなる詳細は、例えば、参照により本明細書に非特許文献１（現在のバージョン１３．０．０）の６．２節（３ＧＰＰのウェブサイト（http://www.3gpp.org）で入手可能）を参照）。
１つのサブフレームが２つのスロットで構成されているため、いわゆる「通常の」サイクリックプレフィックス（normal CP）が使用されるときにはサブフレーム内に１４個のＯＦＤＭシンボルが存在し、いわゆる「拡張」サイクリックプレフィックス（extended CP）が使用されるときにはサブフレーム内に１２個のＯＦＤＭシンボルが存在する。専門用語のために、以下で、サブフレーム全体に広がる同一の連続するサブキャリアと同等の時間−周波数リソースは、「リソースブロックペア」または同意義の「ＲＢペア」もしくは「ＰＲＢペア」と呼ばれる。
「コンポーネントキャリア（Component Carrier）」という用語は、周波数領域におけるいくつかのリソースブロックの組合せを示す。ＬＴＥの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、その代わりに、この専門用語はダウンリンクおよびオプションでアップリンクリソースの組合せを示す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンク付けは、ダウンリンクリソースで送信されるシステム情報において指示される。
コンポーネントキャリアの構造に関する同様の想定が以降のリリースにも適用される。
［より広い帯域幅のサポートのためのＬＴＥ−Ａにおけるキャリアアグリゲーション］
世界無線通信会議２００７（ＷＲＣ−０７）において、ＩＭＴ−Ａｄｖａｎｃｅｄの周波数スペクトルが決定された。ＩＭＴ−Ａｄｖａｎｃｅｄのための全体的な周波数スペクトルは決定されたが、実際に利用可能な周波数帯域幅は、地域や国によって異なる。しかしながら、利用可能な周波数スペクトルのアウトラインの決定に続いて、３ＧＰＰにおいて無線インタフェースの標準化が開始された。３ＧＰＰ ＴＳＧ ＲＡＮ ＃３９会合において、「Further Advancements for E-UTRA (LTE-Advanced）」に関する検討項目（Study Item）の記述が承認された。この検討項目は、Ｅ−ＵＴＲＡを進化・発展させるうえで（例えば、ＩＭＴ−Ａｄｖａｎｃｅｄの要求条件を満たすために）考慮すべき技術要素をカバーしている。
ＬＴＥアドバンストシステムがサポートすることができる帯域幅は１００ＭＨｚであり、一方、ＬＴＥシステムは２０ＭＨｚのみをサポートすることができる。今日、無線スペクトルの不足がワイヤレスネットワークの開発のボトルネックになっている。結果として、ＬＴＥ−Ａｄｖａｎｃｅｄシステムのために十分広いスペクトル帯域を見つけることが困難である。したがって、より広い無線スペクトル帯域を獲得するための方法を見つけることが急務であり、キャリアアグリゲーション機能が解決策であり得る。
キャリアアグリゲーションでは、最大で１００ＭＨｚのより広い送信帯域幅をサポートする目的で、２つ以上のコンポーネントキャリアがアグリゲートされる。ＬＴＥ−Ａｄｖａｎｃｅｄシステムでは、ＬＴＥシステムにおけるいくつかのセルが、より広い１つのチャネルにアグリゲートされ、このチャネルは、たとえＬＴＥにおけるこれらのセルが異なる周波数帯域にある場合でも１００ＭＨｚに対して十分に広い。
少なくともコンポーネントキャリアの帯域幅がＬＴＥリリース８／９のセルのサポートされる帯域幅を超えないときには、すべてのコンポーネントキャリアをＬＴＥリリース８／９互換であるように設定することができる。ユーザ機器によってアグリゲートされるすべてのコンポーネントキャリアが必ずしもＬＴＥリリース８／９互換でなくてよい。リリース８／９のユーザ機器がコンポーネントキャリアにキャンプオンすることを回避するため、既存のメカニズム（例：バーリング（barring））を使用することができる。
ユーザ機器は、自身の能力に応じて１つまたは複数のコンポーネントキャリア（複数のサービングセルに対応する）を同時に受信または送信することができる。キャリアアグリゲーションのための受信能力および／または送信能力を備えた、ＬＴＥ−Ａリリース１０のユーザ機器は、複数のサービングセル上で同時に受信および／または送信することができる。これに対して、ＬＴＥリリース８／９のユーザ機器は、コンポーネントキャリアの構造がリリース８／９の仕様に従う場合、１つのみのサービングセル上で受信および送信を行うことができる。
キャリアアグリゲーションは、連続するコンポーネントキャリアおよび不連続なコンポーネントキャリアの両方においてサポートされ、各コンポーネントキャリアは、（３ＧＰＰ ＬＴＥ（リリース８／９）の計算方式（numerology）を使用して）周波数領域における最大１１０個のリソースブロックに制限される。
同一のｅＮｏｄｅＢ（基地局）から送信される、場合によってはアップリンクおよびダウンリンクにおいて異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように、３ＧＰＰ ＬＴＥ−Ａ（リリース１０）互換のユーザ機器を構成することが可能である。設定することのできるダウンリンクコンポーネントキャリアの数は、ユーザ機器のダウンリンクのアグリゲーション能力に依存する。逆に、設定することのできるアップリンクコンポーネントキャリアの数は、ユーザ機器のアップリンクのアグリゲーション能力に依存する。現時点では、移動端末にダウンリンクコンポーネントキャリアよりもアップリンクコンポーネントキャリアを多く設定することはできない。一般的なＴＤＤ配備では、コンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は、アップリンクとダウンリンクとで同一である。同一のｅＮｏｄｅＢから送信されるコンポーネントキャリアは、同一のカバレッジを提供する必要はない。
連続的にアグリゲートされるコンポーネントキャリアの中心周波数の間隔は、３００ｋＨｚの倍数である。これは、３ＧＰＰ ＬＴＥ（リリース８／９）の１００ｋＨｚの周波数ラスターとの互換性を保つと同時に、１５ｋＨｚ間隔のサブキャリアの直交性を維持するためである。アグリゲーションのシナリオによっては、連続するコンポーネントキャリアの間に少数の使用されないサブキャリアを挿入することによって、ｎ×３００ｋＨｚの間隔あけを容易にすることができる。
複数のキャリアをアグリゲートする影響は、ＭＡＣレイヤに及ぶのみである。ＭＡＣレイヤには、アップリンクおよびダウンリンクの両方において、アグリゲートされるコンポーネントキャリアごとに１つのＨＡＲＱエンティティが要求される。コンポーネントキャリアあたりのトランスポートブロックは最大１個である（アップリンクにおけるＳＵ−ＭＩＭＯを使用しない場合）。トランスポートブロックおよびそのＨＡＲＱ再送信（発生時）は、同一のコンポーネントキャリアにマッピングする必要がある。
キャリアアグリゲーションが設定されているとき、移動端末はネットワークとの１つのＲＲＣ接続のみを有する。ＲＲＣ接続の確立／再確立時、１つのセルが、ＬＴＥリリース８／９と同様に、セキュリティ入力（１つのＥＣＧＩ、１つのＰＣＩ、および１つのＡＲＦＣＮ）と、非アクセス層（ＮＡＳ）モビリティ情報（例：ＴＡＩ）とを提供する。ＲＲＣ接続の確立／再確立の後、そのセルに対応するコンポーネントキャリアは、ダウンリンクプライマリセル（ＰＣｅｌｌ）と称される。接続状態では、ユーザ機器あたりつねに１つのダウンリンクＰＣｅｌｌ（ＤＬ ＰＣｅｌｌ）および１つのアップリンクＰＣｅｌｌ（ＵＬ ＰＣｅｌｌ）が設定される。コンポーネントキャリアの設定されたセットおいて、他のセルはセカンダリセル（ＳＣｅｌｌ）と呼ばれ、ＳＣｅｌｌのキャリアはダウンリンクセカンダリコンポーネントキャリア（ＤＬ ＳＣＣ）およびアップリンクセカンダリコンポーネントキャリア（ＵＬ ＳＣＣ）である。１基のＵＥに対して、最大５つのサービングセル（ＰＣｅｌｌを含む）を設定することができる。
［ＭＡＣレイヤ／ＭＡＣエンティティ、ＲＲＣレイヤ、物理レイヤ］
ＬＴＥのＬ２レイヤのユーザプレーン／制御プレーンのプロトコルスタックは、４つのサブレイヤ、すなわちＲＲＣ、ＰＤＣＰ、ＲＬＣ、およびＭＡＣを備えている。媒体アクセス制御（ＭＡＣ）レイヤは、ＬＴＥの無線プロトコルスタックのＬ２アーキテクチャにおける最も下のサブレイヤであり、例えば３ＧＰＰ技術規格である非特許文献２（現在のバージョン１３．０．０）によって定義されている。ＭＡＣレイヤは、下の物理レイヤとはトランスポートチャネルを通じて接続されており、上のＲＬＣレイヤとは論理チャネルを通じて接続されている。したがって、ＭＡＣレイヤは、論理チャネルとトランスポートチャネルとの間の多重化および逆多重化を実行する。送信側におけるＭＡＣレイヤは、論理チャネルを通じて受け取るＭＡＣ ＳＤＵからＭＡＣ ＰＤＵ（トランスポートブロックとしても知られている）を構築し、受信側におけるＭＡＣレイヤは、トランスポートチャネルを通じて受け取るＭＡＣ ＰＤＵからＭＡＣ ＳＤＵを復元する。
ＭＡＣレイヤは、論理チャネルを通じてＲＬＣレイヤにデータ伝送サービスを提供し（参照により本明細書に援用される非特許文献２の５．４節および５．３節を参照）、この論理チャネルは、制御データ（例えばＲＲＣシグナリング）を伝える制御論理チャネル、またはユーザプレーンデータを伝えるトラフィック論理チャネルのいずれかである。その一方で、ＭＡＣレイヤからのデータはトランスポートチャネル（ダウンリンクまたはアップリンクとして分類される）を通じて物理レイヤと交換される。無線を通じた送信方式に応じて、データがトランスポートチャネルに多重化される。
物理レイヤは、データおよび制御情報をエアインタフェースを介して実際に送信する役割を担い、すなわち物理レイヤは、送信側ではＭＡＣトランスポートチャネルからのすべての情報をエアインタフェースを通じて伝える。物理レイヤによって実行されるいくつかの重要な機能としては、符号化および変調、リンクアダプテーション（ＡＭＣ）、電力制御、セルサーチ（最初の同期およびハンドオーバーを目的とする）、ＲＲＣレイヤのための他の測定（ＬＴＥシステムの内側およびシステム間）が挙げられる。物理レイヤは、送信パラメータ（変調方式、符号化率（すなわち変調・符号化方式（ＭＣＳ：Modulation and Coding Scheme））、物理リソースブロックの数など）に基づいて、送信を実行する。物理レイヤの機能に関するさらなる情報は、参照により本明細書に援用される非特許文献３（現在のバージョン１３．０．０）に記載されている。
無線リソース制御（ＲＲＣ）レイヤは、無線インタフェースにおけるＵＥとｅＮＢとの間の通信と、いくつかのセルを横切って移動するＵＥのモビリティを制御する。ＲＲＣプロトコルは、ＮＡＳ（非アクセス層）情報の伝送もサポートする。ＲＲＣ＿ＩＤＬＥ状態にあるＵＥに対しては、ＲＲＣはネットワークからの着信呼の通知をサポートする。ＲＲＣ接続制御は、ＲＲＣ接続の確立、変更、および解除に関連するすべての手順（ページング、測定の設定および報告、無線リソースの設定、最初のセキュリティ起動、シグナリング無線ベアラ（ＳＲＢ：Signalling Radio Bearer）およびユーザデータを伝える無線ベアラ（データ無線ベアラ（ＤＲＢ：Data Radio Bearer））の確立を含む）をカバーする。
無線リンク制御（ＲＬＣ）サブレイヤは主としてＡＲＱ機能を備え、データのセグメント化と連結をサポートする。すなわち、ＲＬＣレイヤは、ＲＬＣ ＳＤＵのフレーム化を行い、ＭＡＣレイヤによって示されたサイズに合わせる。ＲＬＣレイヤとＭＡＣレイヤは、データレートとは無関係にプロトコルオーバーヘッドを最小化する。ＲＬＣレイヤは、論理チャネルを介してＭＡＣレイヤに接続される。各論理チャネルは、様々な種類のトラフィックを伝送する。ＲＬＣレイヤの上位レイヤは、通常はＰＤＣＰレイヤであるが、ＲＲＣレイヤである場合がある。すなわち、論理チャネルであるブロードキャスト制御チャネル（ＢＣＣＨ：Broadcast Control Channel）、ページング制御チャネル（ＰＣＣＨ：Paging Control Channel）、および共通制御チャネル（ＣＣＣＨ：Common Control Channel）で送信されたＲＲＣメッセージは、セキュリティ保護を要求しないため、ＰＤＣＰレイヤを迂回して直接ＲＬＣレイヤに行く。ＲＬＣサブレイヤの主な役割および機能には、次のものが含まれる。
・ ＡＭデータ転送、ＵＭデータ転送、またはＴＭデータ転送をサポートする上位レイヤＰＤＵの転送；
・ ＡＲＱによる誤り訂正；
・ ＴＢのサイズに応じたセグメント化；
・ 必要に応じた再セグメント化（例えば、無線品質（すなわち、サポートされたＴＢサイズ）が変化する場合の再セグメント化）；
・ 同一の無線ベアラのＳＤＵの連結については、さらに検討を要する；
・ 上位レイヤＰＤＵの順次送達；
・ 重複検出；
・ プロトコル誤りの検出およびリカバリ；
・ ＳＤＵ破棄；
・ リセット
ＲＬＣレイヤによって提供されるＡＲＱ機能の詳細については、後に説明する。
［ＬＴＥにおけるアップリンクアクセス方式］
アップリンク送信では、カバレッジを最大にするため、ユーザ端末は高い電力効率で送信する必要がある。Ｅ−ＵＴＲＡのアップリンク送信方式としては、シングルキャリア伝送と、動的な帯域幅割当てのＦＤＭＡとを組み合わせた方式が選択されている。シングルキャリア伝送が選択された主たる理由は、マルチキャリア信号（ＯＦＤＭＡ）と比較して、ピーク対平均電力比（ＰＡＰＲ：Peak to Average Power Ratio）が低いこと、これに対応して電力増幅器の効率が改善されること、カバレッジも改善されること（与えられる端末ピーク電力に対してデータレートがより高いこと）である。各時間間隔において、ｅＮｏｄｅＢは、ユーザデータを送信するための固有の時間／周波数リソースをユーザに割り当て、これによってセル内の直交性が確保される。アップリンクにおける直交多元接続によって、セル内干渉が排除されることでスペクトル効率が高まる。マルチパス伝搬に起因する干渉については、送信信号にサイクリックプレフィックスを挿入することにより基地局（ｅＮｏｄｅＢ）において対処する。
データを送信するために使用される基本的な物理リソースは、１つの時間間隔（例えばサブフレーム）にわたるサイズＢＷｇｒａｎｔの周波数リソースから構成される（符号化された情報ビットはこのリソースにマッピングされる）。なお、サブフレーム（送信時間間隔（ＴＴＩ：Transmission Time Interval）とも称する）が、ユーザデータを送信するための最小の時間間隔である。しかしながら、サブフレームを連結することにより、１ＴＴＩより長い時間にわたる周波数リソースＢＷｇｒａｎｔをユーザに割り当てることができる。
［Ｌ１／Ｌ２制御シグナリング］
スケジューリングされたユーザに、ユーザの割当て状態、トランスポートフォーマット、およびその他の送信関連情報（例：ＨＡＲＱ情報、送信電力制御（ＴＰＣ）コマンド）を知らせる目的で、Ｌ１／Ｌ２制御シグナリングがデータと一緒にダウンリンクで送信される。Ｌ１／Ｌ２制御シグナリングは、サブフレーム内にダウンリンクデータと一緒に多重化される（ユーザ割当てがサブフレーム単位で変化しうるものと想定する）。なお、ユーザ割当てをＴＴＩ（送信時間間隔）ベースで実行することもでき、その場合、ＴＴＩ長をサブフレームの倍数とすることができることに留意されたい。ＴＴＩ長を、サービスエリア内ですべてのユーザに対して一定としてもよいし、異なるユーザに対して異なる長さとしてもよいし、ユーザ毎に動的としてもよい。Ｌ１／Ｌ２制御シグナリングは、一般的にはＴＴＩあたり１回のみ送信されればよい。以下では、一般性を失うことなく、ＴＴＩが１サブフレームに等しいものと想定する。
Ｌ１／Ｌ２制御シグナリングは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ：Physical Downlink Control CHannel）で送信される。ＰＤＣＣＨは、ダウンリンク制御情報（ＤＣＩ：Downlink Control Information）としてメッセージを伝送し、ＤＣＩには、多くの場合、移動端末のための、またはＵＥのグループのためのリソース割当ておよびその他の制御情報が含まれる。いくつかのＰＤＣＣＨを１つのサブフレーム内で送信することができる。
アップリンク無線リソースまたはダウンリンク無線リソースを割り当てる目的でＬ１／Ｌ２制御シグナリングで送られる情報は（特にＬＴＥ（−Ａ）リリース１０）、一般的には以下の項目に分類することができる。
− ユーザ識別情報： 割り当てる対象のユーザを示す。この情報は、一般には、ＣＲＣをユーザ識別情報によってマスクすることによってチェックサムに含まれる。
− リソース割当て情報： ユーザに割り当てられるリソース（例：リソースブロック（ＲＢ））を示す。あるいはこの情報はリソースブロック割当て（ＲＢＡ：Resource Block Assignment）と称される。なお、ユーザに割り当てられるリソースブロック（ＲＢ）の数は動的とすることができる。
− キャリアインジケータ： 第１のキャリアで送信される制御チャネルが、第２のキャリアに関連するリソース（すなわち第２のキャリアのリソースまたは第２のキャリアに関係するリソース）を割り当てる場合に使用される（クロスキャリアスケジューリング）。
− 変調・符号化方式： 採用される変調方式および符号化率を決める。
− ＨＡＲＱ情報： 例えば、データパケットまたはその一部の再送信時に特に有用である、新規データインジケータ（ＮＤＩ：New Data Indicator）や冗長バージョン（ＲＶ：Redundancy Version）。
− 電力制御コマンド： 割り当てられたアップリンクのデータまたは制御情報の送信時の送信電力を調整する。
− 参照信号情報： 例えば、割当てに関連する参照信号の送信または受信に使用される、適用されたサイクリックシフトや直交カバーコードインデックス。
− アップリンク割当てインデックスまたはダウンリンク割当てインデックス： 割当ての順序を識別するために使用され、ＴＤＤシステムにおいて特に有用である。
− ホッピング情報： 例えば、周波数ダイバーシチを増大させる目的でリソースホッピングを適用するか否か、および適用方法の指示情報。
− ＣＳＩ要求： 割り当てられるリソースにおいてチャネル状態情報を送信するようにトリガするために使用される。
− マルチクラスタ情報： シングルクラスタ（ＲＢの連続的なセット）またはマルチクラスタ（連続的なＲＢの少なくとも２つの不連続なセット）で送信を行うかを指示・制御するために使用されるフラグである。マルチクラスタ割当ては、３ＧＰＰ ＬＴＥ−（Ａ）リリース１０によって導入された。
なお、上記リストは、すべてを網羅したものではなく、また、使用されるＤＣＩフォーマットによっては、リストアップした情報項目すべてを各ＰＤＣＣＨ送信に含める必要はないことに留意されたい。
ダウンリンク制御情報は、全体のサイズ、または上述したフィールドに含まれる情報が異なるいくつかのフォーマットの形をとる。ＬＴＥにおいて現在定義されている様々なＤＣＩフォーマットは、以下のとおりであり、参照により本明細書に援用される非特許文献４（現在のバージョン１３．０．０）（３ＧＰＰのウェブサイト（http://www.3gpp.org）で入手可能）の５．３．３．１節「多重化およびコード符号化」（“Multiplexing and channel coding”）に詳しく記載されている。例えば、以下のＤＣＩフォーマットを、アップリンク用のリソースグラントを伝送するために使用することができる。
− フォーマット０： ＤＣＩフォーマット０は、アップリンク送信モード１または２におけるシングルアンテナポート送信を使用したＰＵＳＣＨのためのリソースグラントを送信するために使用される。
− フォーマット４： ＤＣＩフォーマット４は、アップリンク送信モード２における閉ループ空間多重化送信を使用したＰＵＳＣＨのスケジューリングに使用される。
サイドリンクの制御情報については、３ＧＰＰの技術規格である、参照により本明細書に援用される非特許文献４（現在のバージョン１３．０．０）の５．４．３節に定義がある。
［Ｅ−ＵＴＲＡＮ測定・測定用ギャップ］
Ｅ−ＵＴＲＡＮでは、ＵＥを、測定情報を報告するように、例えば、ＵＥのモビリティの制御をサポートするように設定することができる。RRCConnectionReconfigurationメッセージを介して、各測定用設定要素（measurement configuration element）をシグナリングすることができる。例えば、測定用ギャップは、アップリンク送信もダウンリンク送信もスケジューリングされないため、ＵＥが測定を行ってもよい時間を定義する。測定用ギャップは、ギャップを利用した測定（gap-assisted measurements）の全てに共通である。周波数間測定には、ＵＥの性能（例えば、ＵＥが２つの受信部を有するかどうか）に応じて測定用ギャップの設定が必要な場合がある。ＵＥは、サービングセルのキャリア周波数以外のキャリア周波数において動作するＥ−ＵＴＲＡセルを識別する。ＵＥが２つ以上の受信部を有しないのであれば、セルの識別を含む周波数間測定は、周期的な測定用ギャップにおいて行われる。それぞれが６ｍｓのありうる２つのギャップパターンを、ネットワークによって設定することができる。ギャップパターン＃０では４０ｍｓごとにギャップが存在し、ギャップパターン＃１では８０ｍｓごとにギャップが存在する。
例えば、参照信号受信電力（ＲＳＲＰ：Reference Signal Received Power）は、ＵＥによって測定時間にわたる測定帯域幅内のセル固有参照信号の全てについて測定される。
［ＡＲＱ／ハイブリッドＡＲＱ（ＨＡＲＱ）の方式］
ＬＴＥにおいては、信頼性を提供するための２段階の再送信、すなわち、ＭＡＣレイヤにおけるＨＡＲＱおよびＲＬＣレイヤにおける外部ＡＲＱ（outer ARQ）がある。ＲＬＣ再送信メカニズムは、上位レイヤに誤り無くデータを渡す役割を担う。これを達成するために、（再）送信プロトコルは、受信機および送信機におけるＲＬＣエンティティ間で、例えば、送達確認モード（acknowledged mode）で実行される。ＲＬＣレイヤがノイズや予測不能のチャネル変動等による送信誤りを処理することができる場合もあるが、この送信誤りは、多くの場合、ＭＡＣレイヤのＨＡＲＱ再送信プロトコルによって処理される。したがって、ＲＬＣレイヤにおける再送信メカニズムを使用することは、初めは余分に思われるかもしれない。しかしながら、これは余分にはならず、ＲＬＣに基づく再送信メカニズムおよびＭＡＣに基づく再送信メカニズムの両メカニズムを使用することは、実際はフィードバックシグナリングの相違によって十分に動機づけられている。例えば、ＲＬＣ−ＡＲＱメカニズムは、ＭＡＣ ＨＡＲＱメカニズムの場合に起こる可能性があるＮＡＣＫ−ｔｏ−ＡＣＫエラーを処理する。
信頼性の低いチャネルでのパケット伝送システムにおける誤り検出訂正の共通の技術は、ハイブリッド自動再送要求（ＨＡＲＱ：Hybrid Automatic Repeat Request）と呼ばれる。ハイブリッドＡＲＱは、前方誤り訂正（ＦＥＣ：Forward Error Correction）およびＡＲＱの組合せである。ＦＥＣ符号化パケットが送信され、受信機がパケットを正確に復号できない場合（通常、エラーは、ＣＲＣ（Cyclic Redundancy Check：巡回冗長検査）によって検査される）、受信機はパケットの再送信を要求する。
［ＲＬＣ再送信プロトコル］
ＲＬＣが失われたＰＤＵの再送信を要求するように設定される場合、ＲＬＣは送達確認モード（ＡＭ）で動作していると言われる。これは、ＷＣＤＭＡ／ＨＳＰＡにおいて使用される対応するメカニズムと同様である。
全体として、ＲＬＣのための３つの動作モード、すなわち、透過モード（ＴＭ：Transparent Mode）、非送達確認モード（ＵＭ：Unacknowledged Mode）、および送達確認モード（ＡＭ：Acknowledged Mode）がある。各ＲＬＣエンティティは、これらのモードの１つで動作するようにＲＲＣによって設定される。
透過モードでは、上位レイヤから受信されたＲＬＣ ＳＤＵにプロトコルオーバーヘッドが付加されない。特殊なケースでは、限定的なセグメント化／再組立て性能の場合の送信を達成することができる。セグメント化／再組立てが使用されるかを、無線ベアラセットアップ手順において取り決めなければならない。透過モードは、例えば、スピーチのような遅延の影響を非常に受けやすいサービスに使用される。
非送達確認モードでは、再送信プロトコルが使用されていないため、データ送達は保証されない。ＰＤＵの構造には、上位レイヤにおいて完全であること観察するためのシーケンス番号が含まれる。ＲＬＣシーケンス番号に基づいて、受信側ＵＭ ＲＬＣエンティティは、受信されたＲＬＣ ＰＤＵの並べ替えを行うことができる。セグメント化と連結は、データに付加されたヘッダーフィールドによって提供される。非送達確認モードのＲＬＣエンティティは、アップリンクとダウンリンクの間に定義された関連付けがないため一方向的である。誤ったデータが受信される場合、対応するＰＤＵは、設定に応じて破棄されるかマークを付けられる。送信機では、タイマによって規定された一定時間内に送信されないＲＬＣ ＳＤＵは、送信バッファから破棄・除去される。上位レイヤから受信したＲＬＣ ＳＤＵは、送信機側でＲＬＣ ＰＤＵとしてセグメント化／連結される。受信機側では、再組立てが同様に行われる。非送達確認モードは、送達時間の短さと比較して送達に誤りが無いことの重要度が低いサービス（例えば、或るＲＲＣシグナリング手順、ＭＢＭＳ等のセルブロードキャストサービス、およびボイスオーバーＩＰ（ＶｏＩＰ））に使用される。
送達確認モードでは、ＲＬＣレイヤは、自動再送要求（ＡＲＱ：Automatic Repeat Request）プロトコルによる誤り訂正をサポートし、典型的には、誤り無くデータを送達することが最重要であるファイル転送等のＩＰに基づくサービスに使用される。ＲＬＣ再送信は、例えば、ピアＲＬＣ受信側エンティティから受信されたＲＬＣ状況報告（すなわちＡＣＫ／ＮＡＣＫ）に基づいている。送達確認モードは、エアインタフェースのビット誤り率が高い状態において再送信によってパケットデータを高い信頼性で送るために設計されている。誤ったＰＤＵまたは失われたＰＤＵがある場合、送信機が、受信機からＲＬＣ状況報告を受信した際に再送信を行う。
ＡＲＱは、誤ったＰＤＵまたは失われたＰＤＵの再送信のための再送信方式として使用される。例えば、受信されるシーケンス番号を監視することによって、受信側ＲＬＣエンティティは、失われたＰＤＵを識別することができる。この場合、受信側ＲＬＣがＲＬＣ状況報告を生成することができ、送信側ＲＬＣエンティティにフィードバックして、失われたかまたは復号が不成功に終わったＰＤＵの再送信を要求する。送信機がＲＬＣ状況報告をポーリングすることもできる。すなわち、送信側ＲＬＣに受信バッファ状況を知らせる状況報告を受信側ＲＬＣから得るために、ポーリング機能が送信側ＲＬＣによって使用される。状況報告は、ＨＡＲＱの並べ替えが完了する最後のＲＬＣデータＰＤＵまでの、各ＲＬＣデータＰＤＵまたはその一部についての肯定的確認応答（ＡＣＫ）または否定的確認応答情報（ＮＡＣＫ）を提供する。ポーリングフィールドを有するＰＤＵが「１」に設定されるか、またはＲＬＣデータＰＤＵが失われたと検出される場合、受信側ＲＬＣは、状況報告をトリガする。参照として、本明細書に援用される非特許文献５（現在のバージョン１３．０．０）の５．２．３節には、あるトリガが定義されている。これらのトリガは、送信側ＲＬＣにおいてＲＬＣ状況報告のためのポーリングをトリガする。送信機において、送信は、送信ウィンドウ内のＰＤＵについてのみ許可され、送信ウィンドウは、ＲＬＣ状況報告によってのみ更新される。したがって、ＲＬＣ状況報告が遅延している場合、送信ウィンドウを進めることができず、送信が行き詰まる場合もある。
受信機は、トリガされた場合に送信機にＲＬＣ状況報告を送信する。
既に上述の通り、データＰＤＵ送達に加えて、制御ＰＤＵをピアエンティティ間でシグナリングすることができる。
［ＭＡＣ ＨＡＲＱプロトコル］
ＭＡＣレイヤは、ＨＡＲＱエンティティを備える。ＨＡＲＱエンティティは、ＨＡＲＱ送受信動作の役割を担っている。ＨＡＲＱ送信動作には、トランスポートブロックの送信および再送信、ならびにＡＣＫ／ＮＡＣＫシグナリングの受信および処理が含まれる。ＨＡＲＱ受信動作には、トランスポートブロックの受信、受信データの合成、およびＡＣＫ／ＮＡＣＫシグナリングの生成が含まれる。先のトランスポートブロックが復号されている間に、連続的な送信を行うことができるように、最大８つの並行したＨＡＲＱプロセスを使用して、マルチプロセス「ストップアンドウェイト」（ＳＡＷ：Stop-And-Wait）ＨＡＲＱ動作をサポートする。各ＨＡＲＱプロセスは、個別のＳＡＷ動作を実行し、個別のバッファを管理する。
ＨＡＲＱプロトコルによって提供されるフィードバックは、確認応答（ＡＣＫ）または否定的確認応答（ＮＡＣＫ）のいずれかである。ＡＣＫおよびＮＡＣＫは、送信が正確に受信されたか否か（例えば、複合が成功したか）に応じて生成される。さらに、ＨＡＲＱ動作では、ＵＥがＩＲ（Incremental Redundancy）合成を用いて、合成利得を介して追加的な符号化利得を得ることができるように、ｅＮＢは再送信の際に元のトランスポートブロックと異なる符号化バージョンのものを送信することができる。
ＦＥＣ符号化パケットが送信され、受信機がパケットを正確に復号できない場合（通常、エラーは、ＣＲＣ（Cyclic Redundancy Check：巡回冗長検査）によって検査される）、受信機はパケットの再送信を要求する。一般に（また、本明細書を通して）、追加情報を送信することを「（パケットの）再送信」と呼ぶ。この再送信は、一般に、同一の符号化情報を送信することを意味するが、必ずしものこれを意味するわけではない。または、再送信とは、パケットに属する任意の情報（例えば追加的な冗長性情報）を、例えば、様々な冗長バージョンを使用して送信することを意味することもできる。
一般に、ＨＡＲＱ方式は、同期式または非同期式に分類することができ、再送信は、それぞれの場合において、適応的または非適応的である。同期ＨＡＲＱは、各ＨＡＲＱプロセスのトランスポートブロックの再送信が、最初の送信に対して事前に定義された（周期的な）時に行われることを意味する。したがって、受信機に再送信スケジュール、または、例えばＨＡＲＱプロセス番号を示すための明示的なシグナリングは、再送信スケジュールが送信タイミングから推測可能であるため要求されない。
対照的に、非同期ＨＡＲＱでは、最初の送信に対して任意の時に再送信を行うことができ、非同期ＨＡＲＱでは、エアインタフェースの状態に基づいて再送信をスケジューリングする柔軟性が提供される。しかしながら、この場合、正確な合成およびプロトコルの動作が可能になるように、例えば、ＨＡＲＱプロセスを受信機に示す追加的な明示的なシグナリングが要求される。３ＧＰＰ ＬＴＥシステムでは、８つのプロセスを含むＨＡＲＱ動作が使用される。
ＬＴＥでは、非同期−適応ＨＡＲＱ（asynchronous adaptive HARQ）はダウンリンクで使用され、同期ＨＡＲＱがアップリンクで使用される。アップリンクでは、再送信は、例えばアップリンクグラントにおいて送信属性が新たにシグナリングされるかに応じて、適応的であっても、非適応的であってもよい。
アップリンクＨＡＲＱプロトコルの動作では（すなわち、アップリンクデータ送信の確認応答のために）、再送信をスケジューリングする方法についての２つの異なるオプションがある。再送信は、ＮＡＣＫによって「スケジューリングされる」か（同期−非適応再送信（synchronous non-adaptive retransmission）ともいう）、またはＰＤＣＣＨを送信することによってネットワークによって明示的にスケジューリングされる（同期−適応再送信（synchronous adaptive retransmissions）ともいう）。
同期−非適応再送信の場合には、再送信には先のアップリンク送信と同一のパラメータが使用される。すなわち、再送信は同一の物理チャネルリソースでシグナリングされ、各再送信では同一の変調方式／トランスポートフォーマットが使用される。ただし、冗長バージョンは、変化する（すなわち、事前に定義された冗長バージョン（０、２、３、１）の順序で循環する）。
同期−適応再送信がＰＤＣＣＨを介して明示的にスケジューリングされるため、ｅＮｏｄｅＢは、再送信について特定のパラメータを変えることができる。例えば、アップリンクにおける断片化を回避するために異なる周波数リソースに再送信をスケジューリングすることができる。あるいはｅＮｏｄｅＢは、変調方式を変更することもでき、代替的にいずれの冗長バージョンを再送信に使用するかをユーザ機器に示すこともできる。なお、ＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ）およびＰＤＣＣＨシグナリングがＵＬ ＨＡＲＱのＦＤＤ動作と同一のタイミングで行われることに留意されたい。したがって、ユーザ機器は、同期−非適応再送信がトリガされるか（すなわち、ＮＡＣＫのみが受信されるか）、またはｅＮｏｄｅＢが同期−適応再送信を要求するか（すなわち、ＰＤＣＣＨもシグナリングされるか）を一度チェックする必要があるのみである。
ＰＨＩＣＨは、ｅＮｏｄｅＢがＰＵＳＣＨによる送信を正確に受信したかを示すＨＡＲＱフィードバックを伝送する。ＨＡＲＱインジケータは、肯定的確認応答（ＡＣＫ）の場合は０に、否定的確認応答（ＮＡＣＫ）の場合は１に設定される。アップリンクデータ送信のためのＡＣＫ／ＮＡＣＫメッセージを伝送するＰＨＩＣＨは、同一のユーザ端末に関して、物理ダウンリンク制御チャネル（ＰＤＣＣＨ：Physical Downlink Control Channel）と同時に送信されることがある。このような同時送信の場合、ユーザ端末は、ＰＨＩＣＨの内容にかかわらず、ＰＤＣＣＨがユーザ端末に何をすべきと支持しているか（すなわち、新規送信（切り替えられたＮＤＩを含む新規ＵＬグラント）を行うべきであるか、または再送信（適応再送信ともいう）（切り替えられたＮＤＩを含まない新規ＵＬグラント）を行うべきであるか）を判定することができる。端末用のＰＤＣＣＨが検出されない場合、ＰＨＩＣＨの内容が端末のＵＬ ＨＡＲＱ挙動を決定する。端末のＵＬ ＨＡＲＱ挙動を以下に要約する。
ＮＡＣＫ： 端末は、非適応再送信（すなわち、同一のＨＡＲＱプロセスで先に使用されたアップリンクリソースと同一のアップリンクリソースでの再送信）を行う。
ＡＣＫ： 端末はアップリンク再送信を行わず、該ＨＡＲＱプロセスのＨＡＲＱバッファ内のデータを保持する。該ＨＡＲＱプロセスのためのさらなる送信を、ＰＤＣＣＨによる後のグラントによって明示的にスケジューリングする必要がある。そのようなグラントが受信されるまで、端末は「保留状態」となる。
これを、下記の表１に示す。
ＬＴＥのアップリンクＨＡＲＱプロトコルのスケジュールタイミングを、図３に例示する。ｅＮＢは、ＰＤＣＣＨでＵＥに第１のアップリンクグラント３０１を送信し、これに対して、ＵＥはＰＵＳＣＨでｅＮＢに第１のデータ３０２を送信する。ＰＤＣＣＨアップリンクグラントとＰＵＳＣＨ送信との間のタイミングは、現在４ｍｓで固定されている。ｅＮＢは、ＵＥから第１のデータ送信３０２を受信した後に、ＵＥにフィードバック情報（ＡＣＫ／ＮＡＣＫ）、および、場合によっては、受信した送信のためのＵＬグラント３０３を送信する（あるいは、ＵＬ送信が成功した場合、ｅＮＢは、適切な第２のアップリンクグラントを送信することによって新規アップリンク送信をトリガすることができる）。ＰＵＳＣＨ送信と、フィードバック情報を伝送する対応のＰＨＩＣＨとの間のタイミングも、現在４ｍｓで固定されている。したがって、アップリンクＨＡＲＱプロトコルにおける次の（再）送信機会を示すラウンドトリップタイム（ＲＴＴ：Round Trip Time）は、８ｍｓである。これらの８ｍｓの後、ＵＥは、ｅＮＢによって指示された先のデータの再送信３０４を送信してもよい。さらなる動作については、先に送信されたデータパケットの再送信３０４が再び不成功に終わり、ｅＮｏｄｅＢがさらなる再送信を行うようにＵＥに指示する（例えば、ＮＡＣＫ３０５をフィードバックとして送信する）ことが想定される。ＵＥは、ｅＮｏｄｅＢからの指示に応じて、さらなる再送信３０６を行ってもよい。
図３の上部には、サブフレーム番号と共にＨＡＲＱプロセスとサブフレームとの例示的な関連付けが示されている。図３から明らかなように、８つの利用可能なＨＡＲＱプロセスの各々は、対応するサブフレームと循環して関連付けられている。図３の例示的なシナリオでは、最初の送信３０２および最初の送信３０２に対応する再送信３０４および３０６が、同一のＨＡＲＱプロセス番号５によって処理されることが想定されている。
ＵＥにおける測定を行うための測定用ギャップの優先度は、ＨＡＲＱ再送信の優先度より高い。したがって、ＨＡＲＱ再送信が測定用ギャップと衝突する場合は常に、ＨＡＲＱ再送信は行われない。一方、ＰＨＩＣＨによるＨＡＲＱフィードバック送信が測定用ギャップと衝突する場合は常に、ＵＥは、予期されるＨＡＲＱフィードバックの内容としてＡＣＫを想定する。
ダウンリンク制御情報には、ＨＡＲＱ動作の援助となるいくつかのフィールドがある。
・ 新規データインジケータ（ＮＤＩ：New Data Indicator）： トランスポートブロックの送信がスケジューリングされる場合に必ず切り替えられる（すなわち、最初の送信ともいわれる）。「切り替えられる」とは、関連付けられたＨＡＲＱ情報において提供されるＮＤＩビットがこのＨＡＲＱプロセスの先の送信における値と比較して変更された／切り替えられたことを意味する。
・ 冗長バージョン（ＲＶ：Redundancy Version）： 送信または再送信のために選択されたＲＶを示す。
・ ＭＣＳ（Modulation and Coding Scheme）： 変調・符号化方式。
ＨＡＲＱ動作は複雑であり、本出願において完全には説明しない／説明することができない、また、本発明の十分な理解にとって必要でもない。ＨＡＲＱ動作の関連部分が、例えば、非特許文献２（現在のバージョン１３．０．０）の５．４．２節「ＨＡＲＱ動作」に定義されている。以下、この節を引用する。
―――引用開始。―――
５．４．２ ＨＡＲＱ動作
５．４．２．１ ＨＡＲＱエンティティ
ＭＡＣエンティティには、アップリンクが設定されたサービングセルごとにＨＡＲＱエンティティが１つある。ＨＡＲＱエンティティは、先の送信が成功か不成功かについてＨＡＲＱフィードバックを待ちつつ、連続して送信することを可能にする多くの並行ＨＡＲＱプロセスを維持している。
ＨＡＲＱエンティティごとの並行ＨＡＲＱプロセスの数は、第８節の［２］に規定されている。
物理レイヤがアップリンクの空間多重化に対応して設定されている場合［２］、２つのＨＡＲＱプロセスが所定のＴＴＩに関連付けられる。物理レイヤがアップリンクの空間多重化に対応して設定されていない場合、１つのＨＡＲＱプロセスが所定のＴＴＩに関連付けられる。
所定のＴＴＩにおいて、該ＴＴＩに対応するアップリンクグラントが示される場合、ＨＡＲＱエンティティは、送信が行われるべきＨＡＲＱプロセスを識別する。また、ＨＡＲＱエンティティは、物理レイヤによって中継される受信したＨＡＲＱフィードバック（ＡＣＫ／ＮＡＣＫ情報）、ＭＣＳ、およびリソースを適切なＨＡＲＱプロセスにルーティングする。
ＴＴＩバンドリングが設定されている場合、パラメータTTI_BUNDLE_SIZEが、ＴＴＩバンドルのＴＴＩ数を規定する。同一のバンドルの一部である各送信について同一のＨＡＲＱプロセスを呼び出すＴＴＩバンドリング動作は、ＨＡＲＱエンティティに依存する。バンドル内において、ＨＡＲＱ再送信は非適応的であり、TTI_BUNDLE_SIZEに応じて先の送信のフィードバックを待たずにトリガされる。バンドルのＨＡＲＱフィードバックは、バンドルの最後のＴＴＩにおいて送信が行われるか否か（例えば、測定用ギャップが生じた場合）にかかわらず、最後のＴＴＩ（すなわち、TTI_BUNDLE_SIZEに対応するＴＴＩ）に対して受信されるのみである。ＴＴＩバンドルの再送信も、ＴＴＩバンドルである。アップリンクが設定された１つ以上のＳＣｅｌｌがＭＡＣエンティティに設定されている場合、ＴＴＩバンドリングはサポートされない。
ＴＴＩバンドリングは、ＲＮのサブフレーム設定と組み合わせてＥ−ＵＴＲＡＮを用いるＲＮ通信についてはサポートされない。
ランダムアクセス（５．１．５節参照）時のＭｓｇ３の送信については、ＴＴＩバンドリングは適用されない。
各ＴＴＩについて、ＨＡＲＱエンティティは、
− 各ＴＴＩに関連付けられたＨＡＲＱプロセスを識別し、識別された各ＨＡＲＱプロセスについて、
− そのＨＡＲＱプロセスおよびそのＴＴＩのためのアップリンクグラントが示される場合であって、
− 受信したグラントがＰＤＣＣＨにおいて一時的Ｃ−ＲＮＴＩ宛に送信されておらず、かつ、関連付けられたＨＡＲＱ情報において提供されるＮＤＩがそのＨＡＲＱプロセスの以前の送信時の値と比較して切り替えられている場合、または、
− Ｃ−ＲＮＴＩに対応するアップリンクグラントがＰＤＣＣＨで受信され、識別されたプロセスのＨＡＲＱバッファが空である場合、または、
− アップリンクグラントがランダムアクセス応答において受信された場合であって、
− Ｍｓｇ３バッファにＭＡＣ ＰＤＵがあり、アップリンクグラントがランダムアクセス応答において受信された場合、
− 送信するＭＡＣ ＰＤＵをＭｓｇ３バッファから取得する。
− あるいは、Ｍｓｇ３バッファにＭＡＣ ＰＤＵがあり、アップリンクグラントがランダムアクセス応答において受信された場合以外の場合には、
− 送信するＭＡＣ ＰＤＵを「多重化および組立て」（“Multiplexing and assembly”）エンティティから取得し、
− 識別されたＨＡＲＱプロセスにＭＡＣ ＰＤＵおよびアップリンクグラントおよびＨＡＲＱ情報を送達し、
− 識別されたＨＡＲＱプロセスに新規送信をトリガするように指示する。
− あるいは、受信したグラントがＰＤＣＣＨにおいて一時的Ｃ−ＲＮＴＩ宛に送信されておらず、かつ、関連付けられたＨＡＲＱ情報において提供されるＮＤＩがそのＨＡＲＱプロセスの以前の送信時の値と比較して切り替えられている場合、および、Ｃ−ＲＮＴＩに対応するアップリンクグラントがＰＤＣＣＨで受信され、識別されたプロセスのＨＡＲＱバッファが空である場合、および、アップリンクグラントがランダムアクセス応答において受信された場合のいずれでもない場合、
− 識別されたＨＡＲＱプロセスにアップリンクグラントおよびＨＡＲＱ情報（冗長バージョン）を送達し、
− 識別されたＨＡＲＱプロセスに適応再送信を生成するように指示する。
− あるいは、このＨＡＲＱプロセスのＨＡＲＱバッファが空でない場合、
− 識別されたＨＡＲＱプロセスに非適応再送信を生成するように指示する。
以前の送信時の値と比較してＮＤＩが切り替えられたかを判定する際、ＭＡＣエンティティは、ＰＤＣＣＨのすべてのアップリンクグラントにおいて受信された、一時的Ｃ−ＲＮＴＩに対応するＮＤＩを無視するものとする。
５．４．２．２ ＨＡＲＱプロセス
各ＨＡＲＱプロセスには、ＨＡＲＱバッファが関連付けられている。
各ＨＡＲＱプロセスは、バッファ内に現在あるＭＡＣ ＰＤＵについて行われた送信の回数を示す状態変数CURRENT_TX_NB、および現在バッファ内にあるＭＡＣ ＰＤＵについてのＨＡＲＱフィードバックを示す状態変数HARQ_FEEDBACKを維持するものとする。ＨＡＲＱプロセスが確立される場合、CURRENT_TX_NBは初期化されて０になる。
冗長バージョンの順序は０、２、３、１である。変数CURRENT_IRVは、冗長バージョンの順序になる指数である。この変数は、４を法として更新される。
新規送信は、ＰＤＣＣＨまたはランダムアクセス応答において示されたリソースおよびＭＣＳで行われる。適応再送信は、ＰＤＣＣＨにおいて示されたリソースで、および提供された場合、ＰＤＣＣＨにおいて示されたＭＣＳで行われる。非適応再送信は、最後に試みられた送信に使用されたリソースおよびＭＣＳと同一のリソースおよびＭＣＳで行われる。
ＭＡＣエンティティには、ＨＡＲＱの最大送信回数およびＭｓｇ３ ＨＡＲＱの最大送信回数（それぞれ、maxHARQ-TxおよびmaxHARQ-Msg3Tx）がＲＲＣによって設定されている。Ｍｓｇ３バッファに格納されたＭＡＣ ＰＤＵの送信を除くすべてのＨＡＲＱプロセスおよびすべての論理チャネルでの送信については、最大送信回数は、maxHARQ-Txに設定されるものとする。Ｍｓｇ３バッファに格納されたＭＡＣ ＰＤＵの送信については、最大送信回数は、maxHARQ-Msg3Txに設定されるものとする。
ＴＢに対応するＨＡＲＱフィードバックが受信される場合、ＨＡＲＱプロセスは、
− HARQ_FEEDBACKを受信された値に設定する。
ＨＡＲＱエンティティが新規送信を要求する場合、ＨＡＲＱプロセスは、
− CURRENT_TX_NBを０に設定し、
− CURRENT_IRVを０に設定し、
− 関連付けられたＨＡＲＱバッファにＭＡＣ ＰＤＵを格納し、
− ＨＡＲＱエンティティから受信したアップリンクグラントを格納し、
− HARQ_FEEDBACKをＮＡＣＫに設定し、
− 後述のように送信を生成する。
ＨＡＲＱエンティティが再送信を要求する場合、ＨＡＲＱプロセスは、
− CURRENT_TX_NBを１インクリメントし、
− ＨＡＲＱエンティティが適応再送信を要求する場合、
− ＨＡＲＱエンティティから受信したアップリンクグラントを格納し、
− CURRENT_IRVをＨＡＲＱ情報において提供される冗長バージョンの値に対応する指数に設定し、
− HARQ_FEEDBACKをＮＡＣＫに設定し、
− 後述のように送信を生成する。
− あるいは、ＨＡＲＱエンティティが非適応再送信を要求する場合であって、
− HARQ_FEEDBACK＝ＮＡＣＫの場合、
− 後述のように送信を生成する。
注：ＨＡＲＱ ＡＣＫのみを受信する際、ＭＡＣエンティティはＨＡＲＱバッファ内のデータを保持する。
注：測定用ギャップの発生によりＵＬ−ＳＣＨ送信を行うことができない場合、ＨＡＲＱフィードバックは受信されず、次いで非適応再送信が行われる。
送信を生成するために、ＨＡＲＱプロセスは、
− ＭＡＣ ＰＤＵがＭｓｇ３バッファから取得された場合、または、
− 送信用サイドリンクディスカバリギャップが上位レイヤによって設定されておらず、送信時に測定用ギャップが存在せず、また、再送信があるのであれば、Ｍｓｇ３バッファから取得されたＭＡＣ ＰＤＵの送信と再送信がＴＴＩにおいて衝突しない場合、または、
− 送信用サイドリンクディスカバリギャップが上位レイヤによって設定されており、送信時に測定用ギャップが存在せず、また、再送信があるのであれば、Ｍｓｇ３バッファから取得されたＭＡＣ ＰＤＵの送信と再送信が衝突せず、このＴＴＩ内に送信用サイドリンクディスカバリギャップが存在しない場合、または、
− 送信用サイドリンクディスカバリギャップが上位レイヤによって設定されており、送信時に測定用ギャップが存在せず、また、再送信があるのであれば、Ｍｓｇ３バッファから取得されたＭＡＣ ＰＤＵの送信と再送信が衝突せず、送信用サイドリンクディスカバリギャップが存在し、このＴＴＩ内にＳＬ−ＤＣＨでの送信のグラントが存在しない場合、
− CURRENT_IRVの値に対応する冗長バージョンを有する格納されたアップリンクグラントに係る送信を生成するように物理レイヤに指示し、
− CURRENT_IRVを１インクリメントし、
− この送信のＨＡＲＱフィードバックの受信時に測定用ギャップまたは受信用サイドリンクディスカバリギャップが存在し、かつ、ＭＡＣ ＰＤＵがＭｓｇ３バッファから取得されなかった場合、
− この送信のＨＡＲＱフィードバックの受信時にHARQ_FEEDBACKをＡＣＫに設定する。
上記動作を行った後、次いで、ＨＡＲＱプロセスは、
− CURRENT_TX_NB＝最大送信回数−１である場合、
− ＨＡＲＱバッファをフラッシュする。
―――引用終了―――
［ＬＴＥの装置間（Ｄ２Ｄ：Device to Device）近傍サービス（ＰｒｏＳｅ）］
近傍性に基づくアプリケーションおよびサービスは、ソーシャル技術の新しいトレンドである。結びつく分野としては、事業者およびユーザにとって関心のある商用サービスおよび公共安全に関連するサービスが挙げられる。ＬＴＥに近傍サービス（ＰｒｏＳｅ）機能を導入することにより、３ＧＰＰ業界は、この成長の見込まれる市場にサービスを提供することができると同時に、連係してＬＴＥを使用するいくつかの公共安全コミュニティの緊急なニーズに応えることができる。
装置間（Ｄ２Ｄ）通信は、ＬＴＥリリース１２によって導入された技術要素であり、この技術によって、セルラーネットワークに対するアンダーレイ（下層）としてのＤ２Ｄにおいてスペクトル効率を高めることができる。例えば、セルラーネットワークがＬＴＥである場合、データを伝送するすべての物理チャネルは、Ｄ２ＤシグナリングにおいてＳＣ−ＦＤＭＡを使用する。Ｄ２Ｄ通信では、ユーザ機器は、無線基地局を経由せずに、セルラーリソースを使用する直接的なリンクを通じて互いにデータ信号を送信する。本発明全体を通じて、用語「Ｄ２Ｄ」、「ＰｒｏＳｅ」、および「サイドリンク」は同義である。
ＬＴＥにおけるＤ２Ｄ通信は、ディスカバリおよび通信という２つの分野に焦点をあてている。
ＰｒｏＳｅ（近傍サービス）直接ディスカバリ（ProSe Direct Discovery）は、ＰｒｏＳｅ対応ＵＥが、近傍の他の（１基または複数基の）ＰｒｏＳｅ対応ＵＥを、ＰＣ５インタフェースを介してＥ−ＵＴＲＡ直接無線信号を使用して発見するために使用される手順と定義されている。
Ｄ２Ｄ通信では、ＵＥとＵＥが、基地局（ＢＳ）を経由せずに、セルラーリソースを使用して直接的なリンクを通じて互いにデータ信号を送信する。Ｄ２Ｄユーザは、基地局の制御下にある状態で（すなわち、少なくともｅＮＢのカバレッジ内にあるときに）互いに直接通信する。したがって、Ｄ２Ｄでは、セルラーリソースを再利用することによってシステム性能を改善することができる。
Ｄ２Ｄは、アップリンクＬＴＥ周波数帯（ＦＤＤの場合）において動作する、またはカバレッジを提供しているセルのアップリンクサブフレーム（ＴＤＤの場合、ただしカバレッジ外のときを除く）において動作するものと想定される。さらに、Ｄ２Ｄ送信／受信では、与えられたキャリアにおいて全二重を使用しない。個々のユーザ機器の観点からは、与えられたキャリアにおいて、Ｄ２Ｄ信号受信およびＬＴＥアップリンク送信が全二重を使用しない（すなわちＤ２Ｄ信号受信およびＬＴＥアップリンク送信を同時に行うことはできない）。
Ｄ２Ｄ通信では、特定の１基のＵＥ１が送信の役割であるとき（送信側ユーザ機器または送信側端末）、ＵＥ１がデータを送り、別のＵＥ２（受信側ユーザ機器）がそれを受信する。ＵＥ１およびＵＥ２は、送信の役割と受信の役割を交換することができる。ＵＥ１からの送信は、ＵＥ２に類似する１基または複数基のＵＥによって受信することができる。
ユーザプレーンプロトコルに関して、Ｄ２Ｄ通信の観点からの合意の一部を以下に記載する（参照により本明細書に援用される非特許文献６（現在のバージョン１２．０．１）の９．２．２節も参照されたい）。
− ＰＤＣＰ：
・ １：Ｍ Ｄ２Ｄブロードキャスト通信データ（すなわちＩＰパケット）は、通常のユーザプレーンデータとして扱うべきである。
・ １：Ｍ Ｄ２Ｄブロードキャスト通信には、ＰＤＣＰにおけるヘッダ圧縮／圧縮解除を適用することができる。
・ 公共安全に関連するＤ２Ｄブロードキャスト動作では、ＰＤＣＰにおけるヘッダ圧縮にＵモードを使用する。
− ＲＬＣ：
・ １：Ｍ Ｄ２Ｄブロードキャスト通信にはＲＬＣ ＵＭを使用する。
・ セグメント化および再組立てはＲＬＣ ＵＭによってＬ２においてサポートされる。
・ 受信側ユーザ機器は、送信側のピアユーザ機器あたり少なくとも１つのＲＬＣ ＵＭエンティティを維持する必要がある。
・ 最初のＲＬＣ ＵＭデータユニットを受信する前に受信機のＲＬＣ ＵＭエンティティを設定する必要はない。
・ 現時点では、ユーザプレーンデータを送信するＤ２Ｄ通信においてＲＬＣ ＡＭまたはＲＬＣ ＴＭの必要性は認識されていない。
− ＭＡＣ：
・ １：Ｍ Ｄ２Ｄブロードキャスト通信ではＨＡＲＱフィードバックを想定しない。
・ 受信側ユーザ機器は、受信機のＲＬＣ ＵＭエンティティを識別する目的で送信元ＩＤを認識する必要がある。
・ ＭＡＣヘッダには、ＭＡＣレイヤにおけるパケットフィルタリングを可能にするＬ２送信先ＩＤが含まれる。
・ Ｌ２送信先ＩＤは、ブロードキャストアドレス、グループキャストアドレス、またはユニキャストアドレスとすることができる。
・ Ｌ２グループキャスト／ユニキャスト： ＭＡＣヘッダにおいて伝えられるＬ２送信先ＩＤによって、受信されたＲＬＣ ＵＭ ＰＤＵを、たとえそれを受信機のＲＬＣエンティティに渡す前であっても破棄することが可能となる。
・ Ｌ２ブロードキャスト： 受信側ユーザ機器は、すべての送信機からの受信されたすべてのＲＬＣ ＰＤＵを処理し、再組立てしてＩＰパケットを上位レイヤに渡す。
・ ＭＡＣサブヘッダには、（複数の論理チャネルを区別するための）論理チャネルＩＤ（ＬＣＩＤ）が含まれる。
・ Ｄ２Ｄでは、少なくとも多重化／逆多重化、優先順位の処理、およびパディングが有用である。
リリース１２の時間構成では、マルチキャリアの／公衆陸上移動体ネットワーク（ＰＬＭＮ：Public Land Mobile Network）間でのＰｒｏＳｅ動作は、受信側の挙動に制限されていた。つまり、サービングＰＬＭＮとは別のＰＬＭＮに属するディスカバリ用のキャリアを監視するようにＵＥを設定することはできる。しかしながら、リリース１２では、サイドリンク直接ディスカバリアナウンスの送信は、ＰＬＭＮ内の場合に制限されており、設定されたサービングセルの１つ（すなわち、ＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードである場合のＰＣｅｌｌ）においてのみ行うことができる。したがって、潜在的に多くの装置が直接ディスカバリ送信に関与していることによる負荷平衡化問題に関し、ｅＮＢは、ハンドオーバ（すなわち、ＰＣｅｌｌの変更）を行わずには他の（ＰＣｅｌｌ以外の）セルに直接ディスカバリのシグナリングを移動させることができない。さらに、様々な事業者の多くのＵＥが共有することができる専用のＰｒｏＳｅキャリアを直接ディスカバリのために設定すること（すなわちＰＬＭＮ間設定）がいくつかのシナリオにおいて有益になりえる。上記の考えから、リリース１３においてＰｒｏＳｅのために直接ディスカバリのサポートを強化する必要性が生まれた。したがって、リリース１３では、ＰＬＭＮ内およびＰＬＭＮ間について、サービングｅＮＢがいずれの周波数およびＰＬＭＮでディスカバリ送信を行うことができるかをシグナリングする合意がなされた。ＵＥは、他のキャリアのＳＩＢ１９を読み、直接ディスカバリ送信のためのリソースを得ることができる。実質的に、リリース１３では、サービングセルと同一のＰＬＭＮに属する（場合によっては異なるＰＬＭＮに属する）非サービングキャリアおよび／またはセカンダリセルにおいてサイドリンクディスカバリ送信を行うことができる。
［ＰｒｏＳｅ直接通信のレイヤ２リンク］
簡潔に言えば、２基のＵＥの間でＰＣ５インタフェースを通じてセキュアなレイヤ２リンクを確立することによって、１対１のＰｒｏＳｅ直接通信が達成される。各ＵＥは、ユニキャスト通信用のレイヤ２ ＩＤを有し、このレイヤ２ ＩＤは、ＵＥがレイヤ２リンクで送る各フレームのＳｏｕｒｃｅ Ｌａｙｅｒ−２ ＩＤ（送信元レイヤ２ ＩＤ）フィールドと、ＵＥがレイヤ２リンクで受信する各フレームのＤｅｓｔｉｎａｔｉｏｎ Ｌａｙｅｒ−２ ＩＤ（宛先レイヤ２ ＩＤ）に含まれる。ＵＥは、ユニキャスト通信用のレイヤ２ ＩＤが少なくともローカル範囲内で一意であることを確保する必要がある。したがって、ＵＥは、隣接するＵＥとのレイヤ２ ＩＤの衝突を、規定されていないメカニズム（例えば、衝突が検出されたときユニキャスト通信用の新しいレイヤ２ ＩＤを自身で割り当てる）を使用して処理するように準備されているべきである。１対１のＰｒｏＳｅ直接通信のためのレイヤ２リンクは、２基のＵＥのレイヤ２ ＩＤの組合せによって識別される。すなわちＵＥは、同一のレイヤ２ ＩＤを使用して、１対１のＰｒｏＳｅ直接通信のための複数のレイヤ２リンクに関与することができる。
１対１のＰｒｏＳｅ直接通信は、参照により本明細書に援用される非特許文献７（現在のバージョン１３．０．０）の７．１．２節に詳しく説明されているように、次の手順から構成される。
・ ＰＣ５を通じてセキュアなレイヤ２リンクを確立する
・ ＩＰアドレス／プレフィックスを割り当てる
・ ＰＣ５を通じてレイヤ２リンクを維持する
・ ＰＣ５を通じてレイヤ２リンクを解除する
図４は、ＰＣ５インタフェースを通じてセキュアなレイヤ２リンクを確立する方法を示している。
１． 相互認証をトリガする目的で、ＵＥ−１が直接通信要求（Direct Communication Request）メッセージをＵＥ−２に送る。ステップ１を実行するためには、リンク開始側（ＵＥ−１）が相手側（ＵＥ−２）のレイヤ２ ＩＤを知っている必要がある。一例として、リンク開始側は、最初にディスカバリ手順を実行することによって、または相手側を含む１対多のＰｒｏＳｅ通信に参加することによって、相手側のレイヤ２ ＩＤを認識することができる。
２． ＵＥ−２が相互認証の手順を開始する。認証手順が正常に終了すると、ＰＣ５を通じてのセキュアなレイヤ２リンクの確立が完了する。
単独の（中継されない）１対１通信に関与するＵＥは、リンクローカルアドレスを使用することもできる。ＰＣ５シグナリングプロトコルは、ＵＥがＰｒｏＳｅ通信範囲内ではないときに検出するために使用されるキープアライブ機能をサポートする。したがって、このようなＵＥは、レイヤ２リンクの暗黙的な解除に進むことができる。ＰＣ５を通じてのレイヤ２リンクの解除は、他方のＵＥに送信される接続解除要求（Disconnect Request）メッセージを使用することによって実行することができ、他方のＵＥは、関連するすべてのコンテキストデータも削除する。他方のＵＥは、接続解除要求メッセージを受信した時点で、接続解除応答（Disconnect Response）メッセージによって応答し、レイヤ２リンクに関連付けられたすべてのコンテキストデータを削除する。
［ＰｒｏＳｅ直接通信に関連する識別情報］
非特許文献８（現在のバージョン１３．２．０）の８．３節には、ＰｒｏＳｅ直接通信に使用するための次の識別情報が定義されている。
・ ＳＬ−ＲＮＴＩ（サイドリンク無線ネットワーク一時識別子）： ＰｒｏＳｅ直接通信のスケジューリングに使用される一意の識別情報
・ 送信元レイヤ２ ＩＤ： サイドリンクＰｒｏＳｅ直接通信におけるデータの送信機を識別する。送信元レイヤ２ ＩＤは２４ビット長であり、受信機におけるＲＬＣ ＵＭエンティティおよびＰＤＣＰエンティティを識別するため、ＰｒｏＳｅレイヤ２宛先ＩＤおよびＬＣＩＤと一緒に使用される。
・ 宛先レイヤ２ ＩＤ： サイドリンクＰｒｏＳｅ直接通信におけるデータの対象者を識別する。宛先レイヤ２ ＩＤは２４ビット長であり、ＭＡＣレイヤにおいて２つのビットストリングに分割される。
・ １つ目のビットストリングは、宛先レイヤ２ ＩＤの最下位ビット部分（８ビット）であり、サイドリンク制御レイヤ１ ＩＤとして物理レイヤに転送される。これは、サイドリンク制御における意図するデータの対象者を識別し、物理レイヤにおいてパケットをフィルタリングするために使用される。
・ ２つ目のビットストリングは、宛先レイヤ２ ＩＤの最上位ビット部分（１６ビット）であり、ＭＡＣヘッダ内で伝えられる。これは、ＭＡＣレイヤにおいてパケットをフィルタリングするために使用される。
ＵＥにおいてグループを形成するためと、送信元レイヤ２ ＩＤ、宛先レイヤ２ ＩＤ、およびサイドリンク制御レイヤ１ ＩＤを設定するために、非アクセス層シグナリングが必要である。これらの識別情報は、上位レイヤによって提供される、または上位レイヤによって提供される識別情報から導かれる。グループキャストおよびブロードキャストの場合、上位レイヤによって提供されるＰｒｏＳｅ ＵＥ ＩＤが送信元レイヤ２ ＩＤとして直接使用され、上位レイヤによって提供されるＰｒｏＳｅレイヤ２グループＩＤが、ＭＡＣレイヤにおいて宛先レイヤ２ ＩＤとして直接使用される。１対１の通信の場合、上位レイヤが送信元レイヤ２ ＩＤおよび宛先レイヤ２ ＩＤを提供する。
［Ｄ２Ｄディスカバリ−モデルおよびリソース割当て］
ＰｒｏＳｅ直接ディスカバリ（ProSe Direct Discovery）は、ＰｒｏＳｅ対応ＵＥが、近傍の他の（１基または複数基の）ＰｒｏＳｅ対応ＵＥを、ＰＣ５を介してＥ−ＵＴＲＡ直接無線信号を使用して発見するために使用される手順と定義されている。図５は、装置間の直接ディスカバリのためのＰＣ５インタフェースを概略的に示している。
上位レイヤは、ディスカバリ情報のアナウンスおよび監視の許可を処理する。この目的のため、各ＵＥが互いに、事前に定義された信号（ディスカバリ信号（discovery signal）と称する）を交換しなければならない。ＵＥは、必要なときに通信リンクを確立する目的で、ディスカバリ信号を周期的にチェックすることによって、近傍のＵＥのリストを維持する。ディスカバリ信号は、たとえ信号対雑音比（ＳＮＲ：Signal to Noise Ratio）が低い環境においても高い信頼性で検出される必要がある。ディスカバリ信号を周期的に送信することができるように、ディスカバリ信号用のリソースを割り当てる必要がある。
ＰｒｏＳｅ直接ディスカバリには２つのタイプがあり、すなわちオープン型（open）と制限型（restricted）である。オープン型は、発見されるＵＥからの明示的な許可が必要ない場合であり、制限型の発見は、発見されるＵＥからの明示的な許可があるときにのみ行われる。
ＰｒｏＳｅ直接ディスカバリは、例えば、発見される側のユーザ機器からの情報をＵＥ内の特定のアプリケーションのために使用することができるスタンドアロンのサービスイネーブラ（service enabler）とすることができる。アプリケーションは、上記情報（例えば、「近くでタクシーを見つけて」、「コーヒーショップを見つけて」）の使用が許可されているアプリケーションである。さらに、取得した情報に応じて、ＰｒｏＳｅ直接ディスカバリを使用して以降の動作（例えばＰｒｏＳｅ直接通信を開始するなど）を行うことができる。
ＰｒｏＳｅ直接ディスカバリの次のモデルは、参照により本明細書に援用される３ＧＰＰの規格である非特許文献９（現在のバージョン１３．２．０）の５．３節およびその全項に定義されている。
モデルＡ（「私はここです」）：
このモデルは、ＰｒｏＳｅ直接ディスカバリに参加しているＰｒｏＳｅ対応ＵＥのための２つの役割を定義する。
・ アナウンスする側のＵＥ： このＵＥは、発見する許可を有する近傍のＵＥが使用することができる特定の情報をアナウンスする。
・ 監視する側のＵＥ： このＵＥは、アナウンスする側のＵＥの近傍において興味のある特定の情報を監視する。
このモデルでは、アナウンスする側のＵＥは、事前に定義されたディスカバリ時間間隔でディスカバリメッセージをブロードキャストし、これらのメッセージに興味を持っている監視する側のＵＥがメッセージを読み、これらのメッセージを処理する。アナウンスする側のＵＥが自身についての情報（例えば、自身のＰｒｏＳｅアプリケーションコード（ProSe Application Code））をディスカバリメッセージにおいてブロードキャストするため、このモデルを「私はここです」ともいう。
モデルＢ（「そこにいるのは誰ですか？」／「あなたはそこにいますか？」）：
このモデルは、ＰｒｏＳｅ直接ディスカバリに参加するＰｒｏＳｅ対応ＵＥの２つの役割を定義する。
・ 発見する側のＵＥ： このＵＥは、自身が発見したい対象に関する特定の情報を含む要求を送信する。
・ 発見される側のＵＥ： 要求メッセージを受信したＵＥは、発見する側のＵＥの要求に関連する何らかの情報で応答することができる。
発見する側のＵＥが、応答を受け取りたい情報を他のＵＥに送信するため、モデルＢを「そこにいるのは誰ですか？／あなたはそこにいますか？」ともいう。例えば、この情報を、グループに対応するＰｒｏＳｅアプリケーションＩＤについての情報とすることができ、このグループのメンバーが応答することができる。
ディスカバリ情報の内容は、アクセス層（ＡＳ：Access Stratum）に対して透過的であり、アクセス層では、ＰｒｏＳｅ直接ディスカバリの各モデルおよびＰｒｏＳｅ直接ディスカバリのタイプについて区別されない。ＰｒｏＳｅプロトコルは、確実に、アナウンスのために有効なディスカバリ情報のみをアクセス層（ＡＳ）に渡す。
ＵＥは、ｅＮＢ設定にしたがって、ＲＲＣ＿ＩＤＬＥ状態およびＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態のいずれの状態でもディスカバリ情報のアナウンスおよび監視に参加することができる。ＵＥは、半二重の制約を受けるディスカバリ情報をアナウンスおよび監視する。
一般的には、装置の発見は周期的に必要である。さらに、Ｄ２Ｄ装置は、ディスカバリメッセージのシグナリングプロトコルを利用して装置の発見を実行する。例えば、Ｄ２Ｄ対応ＵＥが、自身のディスカバリメッセージを送信することができ、他のＤ２Ｄ対応ＵＥがこのディスカバリメッセージを受信し、この情報を使用して通信リンクを確立することができる。ハイブリッドネットワークの利点として、Ｄ２Ｄ装置がネットワークインフラストラクチャの通信範囲内でもある場合、ｅＮＢなどのネットワークエンティティがディスカバリメッセージの送信や設定を追加的に支援することができる。ディスカバリメッセージの送信や設定をｅＮＢによって調整／制御することは、Ｄ２Ｄのメッセージングと、そのｅＮＢによって制御されているセルラートラフィックとの干渉が確実に発生しないようにするうえでも重要である。さらには、装置のいくつかがネットワークカバレッジの範囲外である場合でも、カバレッジ内の装置がアドホックディスカバリプロトコルを支援することができる。
本説明においてさらに使用される専門用語を定義する目的で、少なくとも以下の２つのタイプのディスカバリ手順が定義されている。
・ＵＥによる自律的リソース選択（以下、タイプ１と呼ぶ）： ディスカバリ情報をアナウンスするためのリソースが特定のＵＥを対象とせずに割り当てられ、さらに以下を特徴とするリソース割当て手順。
○ ディスカバリ情報のアナウンスに使用されるリソースプールの設定をｅＮＢがユーザ機器に提供する。この設定は、例えば、ＳＩＢ（System Information Block）においてシグナリングすることができる。
○ ＵＥは、示されたリソースプールから（１つまたは複数の）無線リソースを自律的に選択し、ディスカバリ情報をアナウンスする。
○ ＵＥは、各ディスカバリ期間中、ランダムに選択されるディスカバリ用リソースでディスカバリ情報をアナウンスすることができる。
・スケジューリングされたリソース割当て（以下、タイプ２と呼ぶ）： ディスカバリ情報をアナウンスするためのリソースが特定のＵＥを対象として割り当てられ、さらに以下を特徴とするリソース割当て手順。
○ ＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードにあるＵＥは、ディスカバリ情報をアナウンスするためのリソースをＲＲＣを介してｅＮＢに要求してもよい。ｅＮＢは、ＲＲＣを介してリソースを割り当てる。
○ リソースは、監視のためにＵＥに設定されるリソースプール内に割り当てられる。
ＲＲＣ＿ＩＤＬＥモードにあるＵＥについては、ｅＮＢは以下のオプションの１つを選択することができる。
・ ｅＮＢは、ディスカバリ情報をアナウンスするためのタイプ１のリソースプールをＳＩＢにおいて提供することができる。ＰｒｏＳｅ直接ディスカバリを許可されているＵＥは、ＲＲＣ＿ＩＤＬＥモードにおいてこれらのリソースを使用してディスカバリ情報をアナウンスする。
・ ｅＮＢは、自身がＤ２Ｄをサポートしているが、ディスカバリ情報をアナウンスするためのリソースを提供しないことを、ＳＩＢにおいて示すことができる。ＵＥは、ディスカバリ情報をアナウンスするためのＤ２Ｄリソースを要求するためには、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードに入る必要がある。
ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるＵＥについて：
・ ＰｒｏＳｅ直接ディスカバリのアナウンスを実行することが許可されているＵＥは、Ｄ２Ｄディスカバリのアナウンスの実行を望むことをｅＮＢに知らせる。
・ ｅＮＢは、そのＵＥがＰｒｏＳｅ直接ディスカバリのアナウンスを許可されているかを、ＭＭＥから受信したＵＥコンテキストを使用して確認する。
・ ｅＮＢは、ディスカバリ情報のアナウンス用にタイプ１のリソースプールまたはタイプ２の専用リソースを使用するように、専用のＲＲＣシグナリングを介してＵＥを設定することができる（またはリソースなし）。
・ ｅＮＢによって割り当てられたリソースは、ａ）ｅＮＢがそのリソースをＲＲＣシグナリングによって設定解除する（de-configure）まで、またはｂ）ＵＥがＩＤＬＥモードに入るまで、有効である。
ＲＲＣ＿ＩＤＬＥモードおよびＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードにある受信側ＵＥは、許可されたタイプ１およびタイプ２のディスカバリ用リソースプールの両方を監視する。ｅＮＢは、ディスカバリ情報を監視するために使用されるリソースプールの設定を、ＳＩＢにおいて提供する。ＳＩＢは、隣接セルにおいてアナウンスするために使用されるディスカバリ用リソースを含んでいてもよい。
非専用の送受信機の場合のキャリア間ディスカバリ性能を高めるために、直接ディスカバリの送受信のために一連のＲＦ送信部／ＲＦ受信部を再利用することができるようにサイドリンクディスカバリギャップが導入される。このギャップは、ネットワーク制御下にあるべきである。
リリース１３では、２つの異なるサイドリンクディスカバリギャップ、すなわち、受信用サイドリンクディスカバリギャップおよび送信用ディスカバリギャップが導入された。２つのギャップの定義を以下に示す。これらの定義は、参照により本明細書に援用される対応する規格である非特許文献２（現在のバージョン１３．０．０）の３．１節からの引用である。
受信用サイドリンクディスカバリギャップ： ランダムアクセス手順中を除き、ＵＥがいかなるサービングセルからのいかなるＤＬチャネルも受信しない時間。
送信用サイドリンクディスカバリギャップ： ランダムアクセス手順中を除き、ＵＬチャネルの送信とサイドリンクディスカバリの送信が同一のサブフレームにおいて行われる場合に、ＵＥがＵＬチャネルの送信よりもサイドリンクディスカバリの送信を優先する時間。
周波数間ディスカバリ、特に、ＰＬＭＮ間ディスカバリにおいて、ｅＮｏｄｅＢがディスカバリ用の他の周波数において使用されているリソースを知らない場合がある。その結果、ｅＮｏｄｅＢは、いつＵＥが周波数間ディスカバリ用のダウンリンク受信およびアップリンク送信をスキップするか（スキップすることが許可されている場合）を知らない。これにより、リソースが無駄になることがある。したがって、ＵＥは、ディスカバリ受信および／またはディスカバリ送信のためにギャップを要求することができる。要求する際、ＵＥは、ＵＥがサイドリンクディスカバリオペレーションの送信用および／または受信用のギャップを必要とするサブフレーム（サービングセルのタイミングに対応するサブフレーム）をｅＮＢに知らせることができる。この場合、ｅＮＢは、提供された情報に基づいて、ＵＥに、送信用および／または受信用のサイドリンクディスカバリギャップを設定する。ディスカバリのために生成されたギャップは、同期およびサブフレームオフセットに必要とされる追加のオーバーヘッドを考慮に入れるべきであり、また、サイドリンクディスカバリに使用される他の周波数への、ＲＦユニットの再チューニングの中断時間を考慮するべきである。
ＵＥがギャップを要求する場合の情報要素が、非特許文献１０において規定されており、ＩＥ ＳＬ−ＧａｐＲｅｑｕｅｓｔと呼ばれる。すなわち、この情報要素は、ＵＥが周波数内または周波数間のサイドリンクディスカバリの受信または送信のために要求するギャップを示す。
ＩＥ ＳＬ−ＧａｐＲｅｑｕｅｓｔは、それ自体がＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎメッセージにおいて運ばれる。ＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎメッセージの抜粋を以下に記載する。
ＳｉｄｅｌｉｎｋＵＥＩｎｆｏｒｍａｔｉｏｎメッセージは、ｅＮＢにサイドリンク情報を示すために使用される。
・ シグナリング無線ベアラ： ＳＲＢ１
・ ＲＬＣ−ＳＡＰ： ＡＭ
・ 論理チャネル： ＤＣＣＨ
・ 方向： ＵＥからＥ−ＵＴＲＡＮへ
上述のように、サイドリンクディスカバリギャップはネットワークにより制御されるものであるから、ｅＮＢは、ＵＥに送信ギャップまたは受信ギャップを設定する。情報要素ＩＥ ＳＬ−ＤｉｓｃＣｏｎｆｉｇは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージにおいてＵＥにシグナリングされ、サイドリンクディスカバリのため専用の設定情報を規定する。
ＳＬ−ＧａｐＣｏｎｆｉｇ
ＩＥ ＳＬ−ＧａｐＣｏｎｆｉｇは、ＵＥが周波数内または周波数間でサイドリンクディスカバリを受信または送信することができるようにＥ−ＵＴＲＡＮによって割り当てられたギャップを示す。
例えば、サイドリンクギャップの長さは、少なくとも４０ｍｓであり、連続するサブフレームにまたがっていてもよいし、またがっていなくてもよい。サイドリンクディスカバリギャップの長さには、ディスカバリオペレーションを行う前にディスカバリ用キャリアのプライマリ同期信号（ＰＳＳ：Primary Synchronization signal）／セカンダリ同期信号（ＳＳＳ：Secondary Synchronization Signal）を得るためにＵＥが必要とする同期オーバーヘッドによる無視できない影響がある。
［ＰｒｏＳｅ直接ディスカバリのための無線プロトコルアーキテクチャ］
図６は、アクセス層プロトコルがＭＡＣおよびＰＨＹのみからなる、ＰｒｏＳｅ直接ディスカバリのための無線プロトコルスタック（アクセス層（ＡＳ））を概略的に示す。ＡＳレイヤは、以下の機能を行う。
・ 上位レイヤ（ＰｒｏＳｅプロトコル）とインタフェースする機能： ＭＡＣレイヤは、上位レイヤ（ＰｒｏＳｅプロトコル）からディスカバリメッセージを受信する。ＩＰレイヤは、ディスカバリメッセージの送信には使用されない。
・ スケジューリングする機能： ＭＡＣレイヤは、上位レイヤから受信されたディスカバリメッセージのアナウンスに使用される無線リソースを決定する。
・ ディスカバリＰＤＵを生成する機能： ＭＡＣレイヤは、ディスカバリメッセージを運ぶＭＡＣ ＰＤＵを形成し、このＭＡＣ ＰＤＵを決定された無線リソースで送信するために物理レイヤに送信する。ＭＡＣヘッダは、付加されない。
ＵＥでは、ＲＲＣプロトコルが、ディスカバリ用リソースプールをＭＡＣに知らせる。また、ＲＲＣは、送信用に割り当てられたタイプ２ＢのリソースをＭＡＣに知らせる。ＭＡＣヘッダは必要ではない。ディスカバリ用のＭＡＣヘッダには、Ｌ２においてフィルタリングを実行するときに参照されるフィールドが含まれない。ＭＡＣレベルにおいてディスカバリメッセージをフィルタリングしても、上位レイヤにおいてＰｒｏＳｅ ＵＥ ＩＤやＰｒｏＳｅアプリケーションＩＤに基づいてフィルタリングを実行することと比較して、処理量や電力が節約されるとは考えられない。受信側ＭＡＣレイヤは、受け取ったディスカバリメッセージすべてを上位レイヤに渡す。ＭＡＣレイヤは、正しく受信されたメッセージのみを上位レイヤに渡す。ディスカバリメッセージが正しく受信されたかをＬ１がＭＡＣレイヤに示すものと想定する。上位レイヤは必ず有効なディスカバリ情報のみをＡＳレイヤに渡すものと想定する。
［ＰｒｏＳｅネットワークアーキテクチャおよびＰｒｏＳｅエンティティ］
図７は、非ローミングの場合の高レベルの例示的なアーキテクチャを示しており、ＵＥ ＡおよびＵＥ Ｂにおける異なるＰｒｏＳｅアプリケーションと、ネットワーク内のＰｒｏＳｅアプリケーションサーバおよびＰｒｏＳｅ機能を含む。図７のアーキテクチャの例は、参照により本明細書に援用される非特許文献９（バージョン１３．０．０）の４．２節「Architectural Reference Model（アーキテクチャの基準モデル）」からの引用である。
これらの機能エンティティは、参照により本明細書に援用される非特許文献９の４．４節「Functional Entities（機能エンティティ）」に提示および詳しく説明されている。ＰｒｏＳｅ機能は、ＰｒｏＳｅに要求されるネットワーク関連動作に使用される論理機能であり、ＰｒｏＳｅの特徴それぞれにおいて異なる役割を果たす。ＰｒｏＳｅ機能は、３ＧＰＰのＥＰＣの一部であり、近傍サービスに関係する認可、認証、データ処理など、関連するネットワークサービスすべてを提供する。ＰｒｏＳｅ直接ディスカバリおよびＰｒｏＳｅ直接通信において、ＵＥは、固有のＰｒｏＳｅ ＵＥ識別情報、他の設定情報、および認証を、ＰｒｏＳｅ機能からＰＣ３基準点（PC3 reference point）を通じて取得することができる。なお、ネットワーク内に複数のＰｒｏＳｅ機能を配備することが可能であるが、図７では、説明を容易にするため、１つのＰｒｏＳｅ機能を示してある。ＰｒｏＳｅ機能は、ＰｒｏＳｅの特徴に応じた異なる役割を実行する主要な３つのサブ機能、すなわち直接提供機能（ＤＰＦ：Direct Provision Function）、直接ディスカバリネーム管理機能（Direct Discovery Name Management Function）、およびＥＰＣレベルディスカバリ機能（EPC-level Discovery Function）、から構成されている。ＤＰＦは、ＰｒｏＳｅ直接ディスカバリおよびＰｒｏＳｅ直接通信を使用するための必要なパラメータをＵＥに提供するために使用される。
ここで、「ＵＥ」とは、例えば以下のＰｒｏＳｅ機能をサポートするＰｒｏＳｅ対応ＵＥを意味する。
・ ＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間でＰＣ３基準点を通じてＰｒｏＳｅ制御情報を交換する
・ ＰＣ５基準点を通じての、他のＰｒｏＳｅ対応ＵＥのオープンＰｒｏＳｅ直接ディスカバリの手順
・ ＰＣ５基準点を通じた１対多のＰｒｏＳｅ直接通信の手順
・ ＰｒｏＳｅ ＵＥとネットワークとの間の中継器として動作するための手順。遠隔のＵＥは、ＰＣ５基準点を通じて、ＰｒｏＳｅ ＵＥとネットワークとの間の中継器と通信する。ＰｒｏＳｅ ＵＥとネットワークとの間の中継器は、レイヤ３パケット転送を使用する。
・ 例えば、ＵＥとネットワークとの間の中継器の検出およびＰｒｏＳｅ直接ディスカバリのために、ＰＣ５基準点を通じて各ＰｒｏＳｅ ＵＥの間で制御情報を交換する
・ 他のＰｒｏＳｅ対応ＵＥとＰｒｏＳｅ機能との間でＰＣ３基準点を通じてＰｒｏＳｅ制御情報を交換する。ＰｒｏＳｅ ＵＥとネットワークとの間の中継器の場合、遠隔のＵＥは、この制御情報を、ＬＴＥ−Ｕｕインタフェースを通じてＰｒｏＳｅ機能に中継されるようにＰＣ５ユーザプレーンを通じて送る。
・ パラメータ（例えば、ＩＰアドレス、ＰｒｏＳｅレイヤ２グループＩＤ、グループセキュリティマテリアル（Group security material）、無線リソースパラメータを含む）を設定する。これらのパラメータは、ＵＥにおいて事前設定することもでき、カバレッジ内にある場合、ＰＣ３基準点を通じたシグナリングによってネットワーク内のＰｒｏＳｅ機能に提供することもできる。
ＰｒｏＳｅアプリケーションサーバは、ＥＰＣ ＰｒｏＳｅユーザＩＤおよびＰｒｏＳｅ機能ＩＤの格納と、アプリケーション層ユーザＩＤとＥＰＣ ＰｒｏＳｅユーザＩＤのマッピングをサポートする。ＰｒｏＳｅアプリケーションサーバ（ＡＳ）は、３ＧＰＰの範囲外のエンティティである。ＵＥにおけるＰｒｏＳｅアプリケーションは、アプリケーション層基準点ＰＣ１を介してＰｒｏＳｅ ＡＳと通信する。ＰｒｏＳｅ ＡＳは、ＰＣ２基準点を介して３ＧＰＰネットワークに接続されている。
［ＰｒｏＳｅ対応ＵＥのためのアップリンクＨＡＲＱ動作］
上述のように、３ＧＰＰは、近傍サービスの標準化を続けてきた。しかしながら、近傍サービスとレガシーＬＴＥ（−Ａ）動作との協調は困難であり、また、これをさらに改良することができる。
3GPP TS 36.211, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)" TS 36.321 3GPP technical standard 36.213 TS 36.212 TS 36.322 3GPP TR 36.843 TR 23.713 3GPP TS 36.300 TS 23.303 3GPP TS36.331
本発明を制限することのない例示的な実施形態において、サイドリンクディスカバリに参加するユーザ端末のアップリンクデータパケット送信のための改良された送信プロトコルの動作を提供する。
本独立請求項は、本発明を制限することのない例示的な実施形態を提供する。有利な実施形態が従属請求項の主題である。
本明細書に記載されたいくつかの態様によれば、送信プロトコルの動作は、改良されている。これらの態様について説明するために、以下を例示的に想定する。具体的には、データパケットのアップリンク送信（および再送信）（例えばサービング基地局への送信）を制御するために、ユーザ端末が送信プロトコルを実行することが想定されている。送信プロトコルの動作では、ユーザ端末がこれまでに行ったデータパケットの送信回数を数える送信カウンタを使用する（送信カウンタには、許容可能な送信の最大限度がある）。さらに、送信プロトコルは、最初の送信のトリガリングを制御するだけでなく、データパケットの再送信を行うメカニズムも提供する。特に、再送信は、受信側（例えば、サービング基地局）が否定的確認応答を提供するか、以前送信したデータパケットの再送信を行うように適当なアップリンクグラントによって明確にＵＥに指示する場合に行われる。
さらに、ユーザ機器は、サイドリンク通信に参加することができ、特に、他のサイドリンク対応ユーザ端末とのサイドリンクディスカバリオペレーションに参加することができ、その目的のために、ユーザ機器には、サイドリンクディスカバリギャップ（ＵＥがサイドリンクディスカバリに参加するために確保された時間）が設定されることが想定されている。換言すれば、ＵＥは、他のユーザ端末を発見することができ（これには、適切なサイドリンクディスカバリメッセージを送信／ブロードキャストすることが含まれうる）、かつ／または、他のユーザ端末から発見されることができる（これには、今度は他のユーザ端末が適切なサイドリンクディスカバリメッセージを送信する対応のリソースを監視すること含まれうる）。
これらのサイドリンクディスカバリギャップにおいて、ｅＮＢに対するＵＥの動作は、ＵＥが、特にサイドリンクディスカバリオペレーションに参加している時は、送信プロトコルの信号（例えば、フィードバック情報や実際のパケット（再）送信）を送信および／または受信しないという点で制限されている。したがって、これらのサイドリンクディスカバリギャップは、送信および／または受信を表していてもよい。
したがって、ユーザ端末は、送信プロトコルを連続的に実行してアップリンクデータパケットの送信および再送信を行いつつ、同時に、他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定されている。本明細書に記載された第１の態様によれば、ユーザ端末は、有利にこれらの２つの種類の動作を調整するように適切に設定されている。上述のように、送信プロトコルによってトリガされるデータパケットの特定の再送信は、これらの再送信がサイドリンクディスカバリギャップの１つと衝突するため結局行うことができない。第１の態様によれば、ＵＥは、これらの衝突を監視することによって、データパケットの再送信が、送信プロトコルによって（例えば、対応するアップリンクグラントを受信した際に）トリガされたが、送信プロトコルの動作がサイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションと何らかの衝突をしたことが理由で行われなかったかを判定する。そのような衝突が判定される場合、衝突し、実行されなかった再送信によって該データパケットについては対応する送信カウンタがインクリメントされないように送信プロトコルは実行される。換言すれば、データパケットの再送信は、この再送信が送信プロトコルによって適切にトリガされたものだったとしても、サイドリンクディスカバリギャップによって妨げられることにより結局行われない場合、ＵＥによってデータパケットの送信として数えられず、無視される（すなわち、該データパケットについては送信プロトコルの送信カウンタを増加させない）。
したがって、設定されたサイドリンクディスカバリギャップにおいてサイドリンクディスカバリオペレーションに参加しているＵＥは、第１の態様に係る特別の方法でデータパケットの再送信を処理する。第１の態様では、該データパケットのための再送信を行う１回以上の対応するさらなる再送信機会をＵＥから奪わないための構成が提供される。したがって、設定されたサイドリンクディスカバリギャップによって付加的に発生するデータパケット損失を回避することができる。
データパケット損失を回避するこの利点は、送信プロトコルの動作の特定のデータパケットについて増大した遅延によって発生しうるコストに対する対策となる。具体的には、衝突する再送信が対応する送信カウンタを増加させないことになり、第１の態様の改良された送信プロトコルの動作は、送信カウンタが送信の最大許容回数に達するのがより後の時点になるため、全体的な送信プロトコルの動作を遅延させる。
第１の態様のより具体的な変形形態では、様々なサイドリンクディスカバリギャップがどのようにＵＥの送信プロトコルの動作と実際に衝突するか、すなわちＵＥが正確に何を監視しなければならないかを扱う。具体的には、ＵＥが設定により有することができるサイドリンクディスカバリギャップは２種類ある。一方を、送信用サイドリンクディスカバリギャップという。送信用サイドリンクディスカバリギャップにおいて、ＵＥは、適切なサイドリンク接続を介して他のユーザ端末にサイドリンクディスカバリメッセージを送信することができる。その結果、送信用サイドリンクディスカバリギャップがＵＥによって使用されることが確実である場合（例えば、ＵＥが対応するサイドリンクチャネルでサイドリンクディスカバリメッセージを送信するための対応するグラントを受信した場合）、ＵＥは、送信プロトコルによってトリガされる。したがって、ＵＥは、妨げられた（すなわち、行われなかった）再送信を含む他のアップリンク送信に対してサイドリンクディスカバリメッセージ送信を優先する。したがって、ＵＥは、衝突を検出し、対応する送信カウンタが衝突の結果として増加しないように対処する。
また、ＵＥには、受信用サイドリンクディスカバリギャップを設定してもよい。受信用サイドリンクディスカバリギャップにおいて、ＵＥは、他のユーザ端末が対応するサイドリンクディスカバリメッセージを送信したかについてサイドリンク接続の対応するリソースを監視する。これらの受信用サイドリンクディスカバリギャップにおいて、ＵＥは、以前送信したデータパケットについての送信プロトコルのフィードバック情報を含む他のダウンリンク信号を受信することができない。したがって、ＵＥは、そのような衝突（この場合、再送信は、トリガされるが、未受信のフィードバック情報が原因で行われない）を検出し、トリガされる再送信によってデータパケットの対応する送信カウンタが増加しないように対処する。
データパケットが衝突する再送信によって該データパケットについては送信カウンタがインクリメントされないことを実現する方法に関して様々な可能性がある。送信プロトコルによって再送信がトリガされるたびに、送信プロトコルが送信カウンタをインクリメントする処理を規定していることが想定されている。１つのオプションでは、この処理では、再送信がサイドリンクディスカバリギャップとの衝突が理由で実際に行われなかったか否かが追加的に考慮される。その場合、第１の態様の第１のオプションによれば、この送信カウンタをインクリメントする処理は行われない。
第１の態様の第２のオプションによれば、再送信がトリガされるたびに、送信プロトコルが送信カウンタを１インクリメントする現在規定されている処理が行われる。しかしながら、送信カウンタのこの最初のインクリメントは、サイドリンクディスカバリギャップとの衝突により当該再送信（最初に送信カウンタのインクリメントをトリガした再送信）を結局行うことができないと判定される場合に、そのデータパケットについて送信カウンタを１減少させるさらなる処理によって補償される。
第１の態様のさらなる変形形態では、データパケットの再送信が送信プロトコルにしたがってトリガされる場合の処理を扱う。例えば、一般に、ＵＥにおいてアップリンクデータパケット送信のために実行される送信プロトコルは、ＵＥに再送信を行うように、または行わないように指示することができる受信側エンティティ（例えば、サービング基地局）によって提供されるフィードバックに反応する。サービング基地局は、以前送信されたデータパケットの再送信を行うようにＵＥに指示する特定のアップリンクグラントをＵＥに提供することができる。このアップリンクグラントには、例えば、再送信がこのアップリンクグラントによってトリガされるのであっても、肯定的確認応答が伴っていてもよい。サービング基地局は、アップリンクグラントによって再送信を要求することによって、再送信のパラメータ（例えば、変調方式、符号化率等）を適合してもよい。これに対し、サービング基地局は、単にＵＥに否定的確認応答を提供してもよい。これにより、ＵＥは、当該データパケットに関連付けられた空ではないバッファ内のデータの再送信をトリガする。ＵＥは、基本的には、再送信を行うために同一の送信パラメータを使用する。
サイドリンクディスカバリオペレーションがアップリンクデータパケット送信の通常動作とは異なるキャリアで行われる結果、通常のアップリンクデータパケット送信の動作とサイドリンクディスカバリオペレーションとを切り替える際にＵＥのハードウェア構成要素の再チューニングが必要になるシナリオにおいて、第１の態様は、厳密に必須というわけではないが特に有利である。例えば、一連の送信部／受信部のみを有するＵＥは、これらの異なる２つのキャリアで同時に動作することができない。そのため、サイドリンクディスカバリオペレーション用および通常のアップリンクデータパケット送信動作用のそれぞれの異なる周波数に一連の受信部／送信部を再チューニングすることが必要になる。
さらに、ＵＥおよびＵＥのサービング基地局において確実に同期した動作を行うために、サービング基地局が、ＵＥと同様に動作するものとする。具体的には、サイドリンクディスカバリギャップにおけるＵＥのサイドリンクディスカバリオペレーションと送信プロトコルの動作との衝突も、サービング基地局によって検出され、それに応じてデータパケット用の送信カウンタが動作される。すなわち、トリガされた再送信を、サイドリンクディスカバリギャップの１つとの衝突により行うことができなかった場合に、ＵＥのデータパケットのトリガされた再送信によって送信カウンタが増加されない。
第２の態様では、上述の課題に対する異なる解決策が提供され、また、送信プロトコルの動作が改良される。第１の態様に関してなされた想定はすべて、第２の態様についても同様になされるものとする。要するに、ＵＥは、アップリンクデータの送信および再送信の制御のための送信プロトコルを実行すると想定される。送信プロトコルには、送信カウンタを使用することも含まれる。ＵＥには、データパケットの許容可能最大送信回数を示す、送信カウンタの動作のためのパラメータが設定されている。任意選択的に、送信カウンタがこの最大値に達する場合、送信プロトコルの、対応するデータパケットを格納する対応の送信バッファがフラッシュされる（すなわち、空になる）。受信側（例えば、サービング基地局）からの対応するフィードバックは、以前送信されたデータパケットの新規送信および再送信をトリガするために使用される。さらに、ＵＥは、ＰｒｏＳｅ対応であることが想定される。したがって、ＵＥは、特に、基地局によって設定されたサイドリンクディスカバリギャップを使用してサイドリンクディスカバリオペレーションに参加する。サイドリンクディスカバリギャップは、送信プロトコルの動作とサイドリンクディスカバリオペレーションとの衝突を引き起こし、ＵＥの基地局との送信プロトコルの動作を制限する。
第１の態様と同様に、第２の態様に係るユーザ端末は、これらの２種類の動作を適切に有利な方式で調整するように設定される。第２の態様に関し、送信プロトコルの動作は、データパケットの再送信が送信プロトコルによってトリガされるたびに、該データパケットについて送信カウンタがインクリメントされる処理を含む。
ここで、第１の態様と同様に、ＵＥは、これらの衝突を監視することによって、データパケットの再送信が、送信プロトコルによって（例えば、対応するアップリンクグラントを受信した際に）トリガされたが、送信プロトコルの動作がサイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションと何らかの衝突をしたことが理由で行われなかったかを判定する。簡潔に言うと、ＵＥは、少なくとも２種類の異なる衝突の１つを監視する。１つ目の衝突は、他のユーザ端末が対応するサイドリンクディスカバリメッセージを送信したかについて、サイドリンク接続の対応するリソースをＵＥが監視する受信サイドリンクディスカバリギャップによって引き起こされるものである。この衝突により、ＵＥは、以前送信したデータパケットの送信プロトコルのフィードバック情報を含む他のダウンリンク信号を受信することができない。２つ目として、送信サイドリンクディスカバリギャップによって、ＵＥは、例えば基地局への通常のアップリンク再送信と、適切なサイドリンク接続を介した他のユーザ端末へのサイドリンクディスカバリメッセージの送信とを同時に行うことができない。
そのような衝突がＵＥによって検出される場合、第２の態様の規定では、増加した許容可能最大送信回数を使用して対応する送信カウンタを動作させることによって、トリガされインクリメントを引き起こした再送信がサイドリンクディスカバリギャップにおいてサイドリンクディスカバリオペレーションによって妨げられたために行われなかったが、送信カウンタはインクリメントされた（場合によっては将来的にインクリメントされる）、ことを考慮に入れる。
対応する送信カウンタの動作に適用可能な許容可能最大送信回数をいかに増加するかについて様々な方法がある。
オプションの１つは、さらなる第２の送信カウンタパラメータを、衝突が検出されたデータパケットについて動作される送信カウンタに使用することである。例えば、この第２の送信カウンタパラメータをサービング基地局によってＵＥに設定することができる。この第２の送信カウンタパラメータによって示される許容可能最大送信回数は、第１の送信カウンタパラメータ（当初、ＵＥにおける送信カウンタは第１の送信カウンタパラメータにしたがって動作した回数）によって設定される許容可能最大送信回数と比較して増加されている。
任意選択的に、ｅＮｏｄｅＢは、サイドリンクディスカバリギャップの長さを認識しているため、ＵＥにおいて何回の再送信機会がサイドリンクディスカバリギャップによって妨げられるかを認識している。したがって、ｅＮｏｄｅＢは、第２の送信カウンタパラメータを設定して、対応する方式でデータパケットの許容可能最大送信回数を増加する。例えば、長さが４０ｍｓのサイドリンクディスカバリギャップは、最大５回の（８ｍｓごとに繰り返される）再送信機会を妨げうるため、データパケットの許容可能最大送信回数を同様に５増加することができる。
第２のオプションでは、上述のように、ＵＥが、衝突を検出するたびに、データパケットの許容可能最大送信回数を自律的にインクリメントする。具体的には、送信プロトコルの動作は、再送信がトリガされる場合に必ず送信カウンタをインクリメントし、ＵＥは、このインクリメントに同調して、衝突の場合（すなわち、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したために、トリガされた再送信が行われなかったとＵＥが判定した場合）に対応する、インクリメントされた送信カウンタに、適用可能な許容可能最大送信回数をインクリメントする。
したがって、送信カウンタの上限（すなわち、許容可能最大送信回数）への到達が早過ぎることはない。このため、ＵＥから、データパケットの再送信を行うための１回以上の対応するさらなる再送信機会が奪われない。したがって、設定されたサイドリンクディスカバリギャップによって付加的に発生するデータパケット損失を回避することができる。
同様に、１つの一般的な第１の態様では、本明細書で開示した技術は、通信システムにおいてアップリンクデータパケット送信のための送信プロトコルを実行するユーザ端末を特徴とする。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。ユーザ端末は、送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したために行われなかったかを判定するプロセッサを備える。さらに、衝突がある場合、プロセッサは、データパケットが衝突する再送信が該データパケットについては送信プロトコルの送信カウンタをインクリメントしないように送信カウンタを動作させる。
同様に、１つの一般的な第２の態様では、本明細書で開示した技術は、通信システムにおいてアップリンクデータパケット送信のための送信プロトコルを実行するユーザ端末を特徴とする。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末には、データパケットの許容可能最大送信回数を設定する第１の送信カウンタパラメータが送信カウンタの動作のために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。ユーザ端末は、データパケットの再送信が送信プロトコルによってトリガされる場合に、該データパケットについて送信カウンタをインクリメントするプロセッサを備える。さらに、プロセッサは、データパケットのトリガされた再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したために行われなかったかを判定する。そして、衝突がある場合、プロセッサは、データパケットの送信カウンタの動作のために第２の送信カウンタパラメータを使用することによって送信カウンタのためにデータパケットの許容可能最大送信回数を増加する。
同様に、１つの一般的な第１の態様では、本明細書で開示した技術は、通信システムにおいてユーザ端末からアップリンクデータパケット送信を受信する基地局を特徴とする。ユーザ端末は、アップリンクデータパケット送信のための送信プロトコルを実行する。ユーザ端末がデータパケットについて行った送信回数を数える第１の送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末がデータパケットについて行った送信回数を数える第２の送信カウンタが、基地局に設定される。ユーザ端末は、サイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように基地局によって設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。基地局は、ユーザ端末の送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したためにユーザ端末によって行われなかったかを判定するプロセッサを備える。そして、衝突がある場合、プロセッサは、データパケットが衝突する送信が該データパケットについては送信プロトコルの第２の送信カウンタをインクリメントしないように第２の送信カウンタを動作させる。
同様に、１つの一般的な第１の態様では、本明細書で開示した技術は、通信システムにおいてアップリンクデータパケット送信のためのユーザ端末における送信プロトコルを実行する方法を特徴とする。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。本方法には、送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したために行われなかったかをユーザ端末が判定するステップが含まれる。そして、衝突がある場合、ユーザ端末は、データパケットが衝突する再送信が該データパケットについては送信プロトコルの送信カウンタをインクリメントしないように送信カウンタを動作させる。
同様に、１つの一般的な第２の態様では、本明細書で開示した技術は、通信システムにおいてユーザ端末からアップリンクデータパケット送信を受信する基地局を特徴とする。端末は、アップリンクデータパケット送信のための送信プロトコルを実行する。ユーザ端末がデータパケットについて行った送信回数を数える第１の送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末がデータパケットについて行った送信回数を数える第２の送信カウンタが、基地局に設定される。第１の送信カウンタパラメータが、第１のおよび第２の送信カウンタの動作のためのデータパケットの許容可能最大送信回数を設定する。ユーザ端末は、サイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように基地局によって設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。基地局は、ユーザ端末においてデータパケットの再送信が送信プロトコルによってトリガされる場合に、該データパケットについて第２の送信カウンタをインクリメントするプロセッサを備える。そして、プロセッサは、ユーザ端末の送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したためにユーザ端末によって行われなかったかを判定する。衝突がある場合、プロセッサは、データパケットの第２の送信カウンタの動作のために第２の送信カウンタパラメータを使用することによって第２の送信カウンタのためにデータパケットの許容可能最大送信回数を増加する。
同様に、１つの一般的な第２の態様では、本明細書で開示した技術は、通信システムにおいてアップリンクデータパケット送信のためのユーザ端末における送信プロトコルを実行する方法を特徴とする。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末には、データパケットの許容可能最大送信回数を設定する第１の送信カウンタパラメータが送信カウンタの動作のために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。本方法には、データパケットの再送信が送信プロトコルによってトリガされる場合に、該データパケットについて送信カウンタをユーザ端末がインクリメントするステップが含まれる。ユーザ端末は、データパケットのトリガされた再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したために行われなかったかを判定する。衝突がある場合、ユーザ端末は、データパケットの送信カウンタの動作のために第２の送信カウンタパラメータを使用することによって送信カウンタのためにデータパケットの許容可能最大送信回数を増加する。
開示されている実施形態のさらなる利益および利点は、本明細書および各図から明らかになるであろう。これらの利益および／または利点は、本明細書および図面に開示したさまざまな実施形態および特徴によって個別に提供され得る。ただし、これらの利益および／または利点の１つまたは複数を得るためにすべてを備える必要はない。
これらの一般的な態様および特定の態様は、システム、方法、コンピュータプログラム、またはこれらの任意の組合せを使用して実施することができる。
以下では、例示的な実施形態について添付の図面を参照しながらより詳細に説明する。
３ＧＰＰ ＬＴＥシステムの例示的なアーキテクチャの図 ３ＧＰＰ ＬＴＥ（リリース８／９）において定義されている、サブフレームのダウンリンクスロットの例示的なダウンリンクリソースグリッドの図 アップリンクの送信および再送信のためのＵＥとｅＮｏｄｅＢとの送信プロトコルの動作を例示する図 ＰｒｏＳｅ通信のためにＰＣ５を通じてレイヤ２リンクを確立する方法の概略図 装置間の直接ディスカバリのためのＰＣ５インタフェースの概略図 ＰｒｏＳｅ直接ディスカバリのための無線プロトコルスタックの概略図 非ローミングの場合のＰｒｏＳｅのための例示的なアーキテクチャモデルの図 第１の実施形態の１つのありうる実装例に係るＵＥの動作のための例示的なシーケンス図 第１の実施形態の他のありうる実装例に係るＵＥの動作のための例示的なシーケンス図 第２の実施形態の実装例に係るＵＥの動作のための例示的なシーケンス図 第２の実施形態のありうる実装例に係るＵＥの動作のための例示的なシーケンス図
「移動局」または「移動ノード」または「ユーザ端末」または「ユーザ機器」は、通信ネットワーク内の物理エンティティである。１つのノードがいくつかの機能エンティティを有していてもよい。機能エンティティとは、所定の一連の機能を実施するソフトウェアモジュールもしくはハードウェアモジュール、および／または、所定の一連の機能をノードまたはネットワークの他の機能エンティティに提供するソフトウェアモジュールもしくはハードウェアモジュールを意味する。ノードは、自身を通信機器または通信設備にアタッチする１つまたは複数のインタフェースを有していてもよい。ノードは、これらのインタフェースを通じて通信することができる。同様に、ネットワークエンティティは、機能エンティティを通信機器または通信設備にアタッチする論理インタフェースを有していてもよい。ネットワークエンティティは、論理インタフェースを通じて別の機能エンティティや通信相手ノードと通信しうる。
本特許請求の範囲および本出願において使用されている「無線リソース」という用語は、物理無線リソース（時間−周波数リソースなど）を意味するものと広義に理解されたい。
本特許請求の範囲および本出願において使用されている「直接通信送信」は、２基のユーザ機器間での直接的な（すなわち、ｅＮＢ等の無線基地局を介さずに）送信を意味するものと広義に理解されたい。また、直通通信送信は、２基のユーザ機器間で直接確立される接続に使用される用語である「直接サイドリンク接続」を通じて行われる。例えば３ＧＰＰでは、Ｄ２Ｄ（装置間）通信、またはＰｒｏＳｅ通信、またはサイドリンク通信という専門用語が使用される。本特許請求の範囲および本出願において使用されている「直接サイドリンク接続」という用語は広義に理解されるべきであり、３ＧＰＰの文脈では、背景技術のセクションに記載したＰＣ５インタフェースを意味するものと理解することができる。
本出願において使用されている「ＰｒｏＳｅ」または、その非短縮形の「近傍サービス」という用語は、背景技術のセクションで例示的に説明したようにＬＴＥシステムにおける近接性に基づくアプリケーションおよびサービスとの関連で用いられる用語である。「Ｄ２Ｄ」等の他の専門用語も、上記関連において使用され、近接サービスのための装置間通信を意味する。さらに、請求項では、「サイドリンクデータ」または「サイドリンク宛先」のような本特許請求の範囲の全体で使用される全般的な専門用語との一貫性のために「サイドリンク論理チャネル」という用語が使用される。「サイドリンク論理チャネル」は、近傍サービス／Ｄ２Ｄのために設定される論理チャネルである。
本特許請求の範囲および本出願において使用されている「サイドリンクディスカバリに参加する」という表現は、ＰｒｏＳｅ対応ＵＥが他のＰｒｏＳｅ対応ＵＥを（例えば、ＵＥがディスカバリメッセージをブロードキャストすることによって）発見する手順およびＰｒｏＳｅ対応ＵＥが他のＰｒｏＳｅ対応ＵＥによって（例えば、ディスカバリメッセージのリスニングを行うことによって）発見される手順を含むものと広義に理解されたい。
背景技術のセクションで説明したように、３ＧＰＰ標準化団体は、キャリア間ディスカバリ性能を高めるために、受信用サイドリンクディスカバリギャップと送信用サイドリンクディスカバリギャップとを区別しつつ、サイドリンクディスカバリギャップを導入することを決定した。これらのサイドリンクディスカバリギャップの時間においては、アップリンクおよびダウンリンクのパケット通信動作は、受信用サイドリンクディスカバリギャップにおいてＵＥがダウンリンクチャネルを受信することができない点、および送信用サイドリンクディスカバリギャップにおいてアップリンクパケット送信を行うことができない（例えば、送信用サイドリンクディスカバリギャップに関し、ＵＥが実際にサイドリンク送信ギャップを使用していることを想定している）点で制限されている。
したがって、ＵｕインタフェースにおけるｅＮＢへのアップリンク送信動作が、新たに導入されたサイドリンクディスカバリギャップと衝突する。アップリンク送信動作は、サイドリンクディスカバリギャップについて現在構想されている最小時間が４０ｍｓであることを考慮すると悪化する。同期式のアップリンクＨＡＲＱ動作の、後の各（再）送信機会の間のラウンドトリップタイムが８ｍｓであるため、時間長が４０ｍｓのサイドリンクディスカバリギャップは相対的に長く、場合によってはアップリンクＨＡＲＱ動作の少なくとも最大５回の（再）送信機会を妨げる。これについては、以下にさらに詳細に説明する。
ＵＥは、データパケット（例えば、ＭＡＣ ＰＤＵ）の最初の送信および再送信を制御するために、（再）送信プロトコル（例えば、ＨＡＲＱ）を実行する。ＵＥは、アップリンク送信を行ってから４ｍｓ後に同期方式で送信プロトコルのフィードバック（ＡＣＫ／ＮＡＣＫ）（および、場合によっては対応するＵＬグラント）を受信する。今度は、新規データパケットのさらなる送信（例えば、新規アップリンク送信のための、切り替えられた新規データインジケータを有するアップリンクグラントが受信される場合）、または以前に受信されたデータパケットの再送信（例えば、切り替えられた新規データインジケータを有しないアップリンクグラントが受信された場合）を、ＰＨＩＣＨを介してＨＡＲＱフィードバックを受信してから４ｍｓ後に行うことができる。
Ｕｕインタフェースにおけるレガシーアップリンク送信プロトコル動作は、少なくとも２つの方法でサイドリンクディスカバリギャップと衝突する場合がある。第１に、ＵＥは、異なるキャリアの他のＵＥのサイドリンクディスカバリメッセージを監視する必要がある受信用サイドリンクディスカバリギャップにおいて、ＨＡＲＱフィードバック（すなわち、ＰＨＩＣＨ）または（適応再送信または新規の最初の送信をトリガする）ＰＤＣＣＨを受信することができない。ＵＥのＨＡＲＱプロセス用のＨＡＲＱバッファが空でない場合（すなわち、ＨＡＲＱバッファが依然として以前送信したデータパケットを含んでいる場合）、ＵＥは、自律的にＨＡＲＱバッファ内の該データの再送信をトリガする。しかしながら、このトリガされた再送信は、ＵＥが該データパケットの先の最初の送信または再送信についてのＨＡＲＱフィードバックとしてｅＮｏｄｅＢからＮＡＣＫを受信した場合にＵＥの物理レイヤに指示されるのみである。すなわち、対応するＨＡＲＱフィードバックがＡＣＫである場合は、再送信は行われない。現在定義されている規格である非特許文献２（バージョン１３．０．０）の５．４．２．２節によれば、ＵＥは、受信サイドリンクディスカバリギャップによって妨げられたＨＡＲＱフィードバックをＡＣＫであると想定することによって、対応するＨＡＲＱプロセスを保留状態にする（例えば、関連付けられたＨＡＲＱバッファはフラッシュされない）。その結果、ＵＥは、空ではないＨＡＲＱバッファに起因して最初はデータパケットの再送信（４ｍｓ後に行われる）をトリガするが、対応するＨＡＲＱプロセスの保留状態（すなわち、フィードバックはＮＡＣＫではなくＡＣＫであったこと）を考慮して再送信を実行しない。
第２に、ＵＥは、送信用サイドリンクディスカバリギャップにおいて、特にＵＥがこの送信サイドリンクディスカバリギャップを実際に使用して対応するサイドリンクディスカバリチャネル（ＳＬ−ＤＣＨ）で送信を行う時、ＵＥは再送信を実行することができない。規格の定義にあるように、サイドリンクディスカバリのいかなる送信もＰＵＳＣＨでのアップリンクにおける（再）送信に優先される。具体的には、現在定義されている規格である非特許文献２（バージョン１３．０．０）の５．４．２．２節によれば、ＴＴＩに送信用サイドリンクディスカバリギャップが設定されていない場合、または、ＴＴＩに送信用サイドリンクディスカバリギャップが設定されているのであれば、このＴＴＩに一般的なサイドリンクディスカバリに関する送信のために設定されたグラントがない場合にのみ、ＨＡＲＱプロトコルは、ＨＡＲＱエンティティが物理レイヤに送信を生成するように指示することができるようにする。
要するに、ＵＥにおける送信プロトコルの動作およびサイドリンクディスカバリギャップの規定が様々なサブフレームにおいて衝突しうるため、ＵＥは、様々な（再）送信機会を使用することができなくなる。
それにもかかわらず、送信プロトコルの動作では、送信プロトコルによって再送信がトリガされるたびに、再送信が実際は行われるか否かとは無関係にデータパケットの送信カウンタを増加する処理が規定されている。具体的には、３ＧＰＰの規格である非特許文献２（現在のバージョン１３．０．０）の５．４．２．２節から明らかなように、再送信が要求される場合に、この送信を実際に生成するかは依然として他の状況（例えば、ＨＡＲＱフィードバックがＮＡＣＫであること、または送信用サイドリンクディスカバリギャップが存在しかつ使用されていること）に依存し、送信カウンタ（ＣＯＵＮＴＥＲ＿ＴＸ＿ＮＢ）は、第１の手順処理において増加される。
同様に、ＵＥは、送信プロトコルによってデータパケットの再送信がトリガされるたびに、サイドリンクディスカバリギャップとの衝突が理由で該再送信が行われない場合でも該データパケットに関連付けられた送信カウンタを増加する。したがって、送信カウンタは、その限度（データパケットについて許容された送信の最大回数）に達しうるため、ＨＡＲＱバッファがフラッシュされ（すなわち、空にされ、内容が削除され）、データパケットが失われる。さらに、ＲＬＣ ＡＭモードにおける外部ＲＬＣ ＡＲＱ手順がそのようなデータパケット損失からのリカバリの役割を担っているため、例えば、失われたデータパケットを識別しＲＬＣ状況報告を送信する受信側エンティティによって後にトリガされる。
ＲＬＣ再送信を行うことは、第１に、データパケットの再送信（ＨＡＲＱ動作後に受信が成功しなかった）が検出され、次いでＲＬＣ状況報告によって要求される必要があることを考慮するとコストがかなり大きい。これにより、追加的な遅延が発生する。さらに、ＵＥは、送信が成功しなかった対応するＲＬＣ ＰＤＵを含むＭＡＣ ＰＤＵを形成するために再びＬＣＰ手順を行う必要がある。
本発明者は、上述した課題の１つまたはいくつかを緩和するため、以下の例示的な実施形態を着想した。
さまざまな実施形態の特定の実装形態は、３ＧＰＰ標準規格によって与えられる、一部が背景技術のセクションで説明されている幅広い仕様の中で実施され、特に重要な特徴は、さまざまな実装形態に関連して以下に説明するように追加される。なお、これらの実施形態は、例えば、背景技術のセクションで説明した３ＧＰＰ ＬＴＥ−Ａ（リリース１０／１１／１２／１３）などの移動通信システムにおいて有利に使用することが可能であるが、これらの実施形態はこの特定の例示的な通信ネットワークでの使用に限定されないことに留意されたい。
以下の説明は、本開示の範囲を制限するものとしてではなく、本開示を深く理解するための実施形態の単なる例として理解されたい。当業者には、請求項に記載されている本開示の一般的な原理を、さまざまなシナリオに、本明細書に明示的には記載されていない方法で適用できることが認識されるはずである。説明を目的として、いくつかの想定がなされているが、これらの想定は以下の実施形態の範囲を制限するものではない。
さらには、上述したように、以下の実施形態は３ＧＰＰ ＬＴＥ−Ａ（リリース１２／１３）環境において実施されうるが、今後のリリースにおいても実施されうる。さまざまな実施形態は、主として、サイドリンクディスカバリ手順にも参加するＰｒｏＳｅ対応ＵＥのための改良されたアップリンクＨＡＲＱ送信プロトコルの動作、および特にサイドリンクディスカバリギャップと（再）送信動作との調整を提供する。したがって、他の機能（すなわちさまざまな実施形態によって変更されない機能）は、背景技術のセクションで説明したものとまったく同一のままであってもよいし、さまざまな実施形態に影響することがないように変更してもよい。他の機能としては、サイドリンク接続を介してサイドリンクデータを送受信するためにＵＥによって行われるサイドリンク送信手順だけでなく、サイドリンクディスカバリギャップの設定およびサイドリンクディスカバリギャップがＵＥによって制御される方法を含む、ＵＥをＰｒｏＳｅに対応するように設定する手順のような他のＰｒｏＳｅ機能が含まれる。さらに、関連する規格に現在定義され、例示的に背景技術のセクションにおいて説明されたＨＡＲＱエンティティ、ＨＡＲＱプロセスおよび対応する送信カウンタ等を含む、ＵＥの送信プロトコル（例えばＭＡＣ ＨＡＲＱやＲＬＣ ＡＲＱ）を通常通り設定することができる。
［第１の実施形態］
以下では、前述した（１つまたは複数の）課題を解決するための第１の実施形態について詳しく説明する。第１の実施形態のさまざまな実装形態および変形形態も説明する。
例として、例えば、自身のサービング基地局にキャリア（例えばＰＣｅｌｌ）を通じてＰＵＳＣＨを介してアップリンクデータパケット送信を行うユーザ端末が想定されている。ＵＥは、少なくとも１つの（再）送信プロトコル（例えばＭＡＣ ＨＡＲＱプロトコル）を実行して、ＭＡＣ ＰＤＵ（データパケットまたはトランスポートブロックともいう）の送信および再送信を制御する。対応するＨＡＲＱエンティティおよびＨＡＲＱプロセスが通常の方式でＵＥに設定される。本明細書に記載された実施形態については、送信ＨＡＲＱエンティティおよび対応するＨＡＲＱプロセスは関連している。アップリンクにおける送信および再送信は、ＵＥのＨＡＲＱ送信プロトコルに制御される。送信カウンタが、各ＨＡＲＱプロセスに設定されることにより、そのＨＡＲＱプロセスにより提供されたデータパケットが既に送信された送信回数が記録される。任意選択的に、送信カウンタが特定のデータパケットの送信の最大回数に達した場合に、送信カウンタを使用してＨＡＲＱプロセスバッファをフラッシュすることができる（したがって、ＨＡＲＱプロセスバッファに格納されたデータパケットを削除することができる）。概して、送信プロトコルの動作（例えば、データパケットの最初の送信をいつ行うか、データパケットの再送信をいつ行うか）は、一般にｅＮＢの制御下にある。ｅＮＢの制御は、例えば、新規送信または再送信のためにＨＡＲＱフィードバックＰＨＩＣＨを介して、および／またはアップリンクグラントをＰＤＣＣＨを介してＵＥに送信することによって行われる。第１の実施形態の特定の実装例によれば、背景技術のセクションにおいて説明したＨＡＲＱプロトコルが使用される。ＨＡＲＱプロトコルは、規格である非特許文献２の、特に、下記に説明するように特定の変更を加えた５．４．２節「ＨＡＲＱ動作」に従っている。
任意選択的に、ＵＥは、上位レイヤ（例えば、ＲＬＣ）においてさらなる（再）送信プロトコルを実行することによって、下位レイヤのＭＡＣレイヤでのＨＡＲＱプロトコル動作中に生じるエラー（例えば、ＮＡＣＫ−ｔｏ−ＡＣＫエラーや損失データパケット）からのさらなるリカバリを行ってもよい。第１の実施形態の特定の実装例によれば、背景技術のセクションにおいて説明したようなＲＬＣ再送信プロトコル動作を使用することができる。
さらに、想定される例示的なシナリオにおいては、ユーザ機器は、ＰｒｏＳｅ通信を行うことができる（ＰｒｏＳｅ対応ＵＥ）、すなわち、ＵＥとＵＥとの間で直接、ｅＮｏｄｅＢを介した迂回なく、それぞれのサイドリンク接続を介して直接Ｄ２Ｄ送信を行うことができる。また、ＰｒｏＳｅ通信では、ＰｒｏＳｅ対応ＵＥは必然的に他のＰｒｏＳｅ対応ＵＥとのサイドリンクディスカバリオペレーションに参加する。すなわち、サイドリンクディスカバリオペレーションへの参加は、事前に定義されたサイドリンクディスカバリ信号を交換して自身の近傍にいる他のＰｒｏＳｅ対応ＵＥを判定し、かつ／または他のＰｒｏＳｅ対応ＵＥに対して可視であることによって行われる。背景技術のセクションにおいて説明したモデルＡ（「私はここです」）やモデルＢ（「そこにいるのは誰ですか？」／「あなたはそこにいますか？」）等の様々なサイドリンクディスカバリモデルを定義することができる。いずれの場合であっても、一般的なままであるために、サイドリンクディスカバリオペレーションに（使用される特定のディスカバリモデルとは無関係に）参加するために、ＵＥは、サイドリンクチャネルを通じてサイドリンクディスカバリメッセージを（例えば、他のＰｒｏＳｅ対応ＵＥを発見するために）送信することができるべきであり、かつ、サイドリンクチャネルを監視し、他のＵＥから送信されたサイドリンクディスカバリメッセージを（例えば、他のＰｒｏＳｅ対応ＵＥによって発見されるために）受信することができるべきである。
さらに、ＰＵＳＣＨ（例えば、ＰＣｅｌｌ）を介してアップリンク送信を行うために使用されるセルとは別のセルでサイドリンク直接ディスカバリが動作するように、キャリア間ＰｒｏＳｅ動作がサポートされることが例示的に想定されている。例えば、ＵＥは、非サービングキャリアおよび／またはセカンダリセルにおいてサイドリンクディスカバリオペレーションを行うように設定されている。したがって、ＵＥは、ＰｒｏＳｅ用の改良された直接ディスカバリをサポートしなければならない。
改良されたサイドリンクディスカバリを支援するために、ＵＥにサイドリンクディスカバリギャップ（すなわち、受信用サイドリンクディスカバリギャップおよび／または送信用サイドリンクディスカバリギャップ）がさらに設定されることが想定される。なお、ＵＥに送信用および受信用のサイドリンクディスカバリギャップの一方のみが設定されるシナリオにも第１の実施形態を同様に適用することができる。また、ＵＥに送信用および受信用のサイドリンクディスカバリギャップの両方が設定されるシナリオにも第１の実施形態を同様に適用することができる。背景技術のセクションにおいて例示的に説明したように、ＵＥの送信動作／受信動作は、サイドリンクディスカバリギャップにおいて制限されている。特に、受信サイドリンクディスカバリギャップにおいて、ＵＥは、ダウンリンクチャネルを受信することができない（但し、ランダムアクセス手順の間を除く。しかしながら、ランダムアクセス手順が本願の各実施形態の機能と関連しないため、以下では無視する）。一方、送信サイドリンクディスカバリギャップにおいて、ＵＥは、ＰＵＳＣＨでの他の「通常の」アップリンク（再）送信に対してあらゆるサイドリンクディスカバリ送信を優先する（すなわち、ＵＥは、既にサイドリンクディスカバリメッセージ送信を行っている場合、または自身のＲＦユニットを再チューニングする場合、送信サイドリンクディスカバリギャップにおいてＨＡＲＱ（再）送信を行うことができない）。しかしながら、ＵＥが送信サイドリンクディスカバリギャップにおいてサイドリンクディスカバリ送信を行わなければ、ＵＥ送信プロトコルの動作は妨げられないため、ＵＥはアップリンクにおけるＨＡＲＱ（再）送信を実際に行うことができる。
第１の実施形態によれば、ＨＡＲＱプロトコル動作と、サイドリンクディスカバリギャップを使用したサイドリンクディスカバリオペレーションとの調整は、以下に説明するように最適化される。第１の実施形態では、トリガされた再送信がサイドリンクディスカバリの並行動作およびサイドリンクディスカバリギャップが理由で行われない場合を判定することができるＵＥが提供される。そのような衝突が生じたとＵＥが判定する場合（すなわち、トリガされた再送信がサイドリンクディスカバリ並行動作のおよびサイドリンクディスカバリギャップが理由で行われないと判定する場合）、ＵＥは、トリガされたが「妨げられた」再送信がＨＡＲＱ送信カウンタをインクリメントしないようにデータパケットの対応するＨＡＲＱ送信カウンタを動作させる。言い換えると、再送信がＨＡＲＱプロトコルによってトリガされたとしても、該再送信は、該データパケットのさらなる（再）送信と見なされない（すなわち、送信カウンタは該データパケットについてはインクリメントされない）。
第１の実施形態のより具体的な変形形態を以下に記載する。ＨＡＲＱ動作とサイドリンクディスカバリギャップに基づいたサイドリンクディスカバリオペレーションとの衝突には様々な理由がありえる。したがって、以下に説明するように、ＵＥは、それぞれが個別にデータのＨＡＲＱ再送信との衝突の原因でありうる送信サイドリンクディスカバリギャップおよび受信サイドリンクディスカバリギャップを識別しつつ、様々な衝突を検出する。
受信サイドリンクディスカバリギャップにおいて、ＵＥは、他のダウンリンクチャネルの受信が妨げられる。これらのダウンリンクチャネルの受信には、以前送信したデータパケットのＰＨＩＣＨを介したＨＡＲＱフィードバックの受信、またはアップリンク再送信（例えば、適応再送信）をスケジューリングするためのＤＣＩを含むＰＤＣＣＨの受信が含まれる。しかしながら、通常、ＨＡＲＱフィードバックは、例えば、受信データの復号がｅＮｏｄｅＢにおいて成功しなかった場合に、非適応再送信を行うようにＵＥを指示するためにｅＮＢによって使用される。例えば、ＮＡＣＫをＨＡＲＱフィードバックとして送信することによって、送信プロトコルが再送信（より具体的には、非適応再送信）を行うことになる。したがって、受信サイドリンクディスカバリギャップにおいてＨＡＲＱフィードバックを受信できないことによって、ＨＡＲＱ動作が妨げられるため、ＵＥは対応するアップリンク再送信を行わない。したがって、ＵＥは、そのような衝突を監視・識別するものとする。適応再送信を行うようにＵＥに指示するＰＤＣＣＨの受信についても同様である。
送信サイドリンクディスカバリギャップにおいては、アップリンクにおける送信よりもサイドリンクディスカバリ送信が優先されるため、ＵＥは、実際にアップリンクにおける送信を行うことが妨げられうる。アップリンクにおける送信には、ＨＡＲＱプロトコルにしたがって行われるあらゆる送信または再送信が含まれる。換言すれば、ＵＥがサブフレーム内でサイドリンクディスカバリメッセージ送信を行う場合、ＵＥはＨＡＲＱ再送信を同時に行うことができない。したがって、再送信がＨＡＲＱプロトコルにおいて（例えば、再送信を要求する明示的なアップリンクグラントを受信することによって）トリガされる場合でも、ＵＥは、送信サイドリンクディスカバリギャップにおける対応するサイドリンクディスカバリオペレーションによって妨げられていることによりこの再送信を実行しない。したがって、ＵＥは、そのような衝突を監視・識別するものとする。
異なる２種類の衝突を上述した。ＵＥは、これらをいずれも監視することにより、送信カウンタを制御する。具体的には、最初は再送信がＨＡＲＱプロトコルにおいてトリガされたとしても（すなわち、ｅＮＢによって指示されたとしても）、送信カウンタは、そのような衝突によって増加されない。
対応するデータパケットの送信カウンタが、妨げられた再送信によって増加されないことを保証するために、次の２つの実装例を提供することができる。
現在の懸案中の規格によれば、ＨＡＲＱプロトコル動作では、データパケットの再送信がトリガされるたびに該データパケットについてＨＡＲＱ送信カウンタをインクリメントする処理が規定されている。第１の実施形態の１つのオプションによれば、送信カウンタを増加するこの処理は、さらに衝突が検出されたかに応じて行われる。その結果、トリガされた再送信と（送信用または受信用の）サイドリンクディスカバリギャップとの衝突をＵＥが検出した場合、送信カウンタをインクリメントする処理は行われない。
図８は、第１の実施形態の上記オプションの実装例に係るユーザ端末のＰｒｏＳｅ動作のありうるシーケンス図を例示的に示す。このシーケンス図から明らかように、送信カウンタをインクリメントする処理は、データパケットの対応する送信がトリガされた後、トリガされた再送信とサイドリンクディスカバリギャップとの衝突が検出されるかに直接依存する。衝突が検出されない場合、送信カウンタをインクリメントすることができ、対応する送信を行うことができる。送信カウンタをインクリメントする処理と、再送信を行う処理との順序は、変更可能であるか、または、これらの処理を並行して行うことができる。
背景技術のセクションにおいて説明したＬＴＥ規格による実装例では、この第１のオプションを以下のように実施することができる。例えば、送信用および／または受信用のサイドリンクディスカバリギャップの発生によりＵＬ−ＳＣＨ送信を行うことができない場合、CURRENT_TX_NBが増加されないことを明確にする補足的な注記を付してもよい。そのような注記を、例えば、非特許文献２の５．４．２．２節に追加することができる。
第１の実施形態の他のオプションによれば、第１のオプションに関する送信カウンタをインクリメントする処理を適合する代わりに、この第２のオプションは、衝突が検出される場合に、データパケットについて送信カウンタをデクリメントする追加処理を導入することに基づいている。したがって、再送信のトリガリングによって送信カウンタがインクリメントされるとしても、衝突がある場合に該データパケットについて送信カウンタをデクリメントする追加処理を規定することによって、送信カウンタは、結局、妨げられた再送信によってはインクリメントされない。このため、妨げられた再送信は、データパケットの送信とは見なされない。
図９は、第１の実施形態の上記第２のオプションの実装例に係るユーザ端末のＰｒｏＳｅ動作のありうるシーケンス図を例示的に示す。図８に示される第１のオプションとの違いが容易に明らかとなるであろう。送信カウンタをインクリメントする処理は、データパケットの再送信をトリガする際に行われるため、再送信とサイドリンクディスカバリギャップとの衝突が検出されるかに影響されない。一方、そのような衝突が検出される場合、送信カウンタはデクリメントされる。
背景技術のセクションにおいて説明したＬＴＥ規格に係る実装例では、この第２のオプションは、以下の『』の行を非特許文献２の５．４．２．２節の対応するＨＡＲＱ動作に加えることにより実現することができる。
――――――――――
５．４．２．２ ＨＡＲＱプロセス
…
上記動作を行った後、次いで、ＨＡＲＱプロセスは、
『送信用または受信用のサイドリンクディスカバリギャップの発生によりＵＬ−ＳＣＨでの再送信を行うことができない場合、
− CURRENT_TX_NB＝CURRENT_TX_NB-1』
− CURRENT_TX_NB＝最大送信回数−１である場合、
− ＨＡＲＱバッファをフラッシュする。
――――――――――
その結果、上述のようにＵＥが、トリガされた再送信の衝突を送信カウンタの動作のために考慮するため、妨げられた再送信によって送信カウンタがインクリメントされなくなる。その結果、ＵＥが再送信を行う対応する機会を失わなくなるため、可能性としては、受信側がデータパケットを復号することができるようになる。したがって、設定されたサイドリンクディスカバリギャップによって発生したデータパケット損失を減少することができ、また、外部ＲＬＣ ＡＲＱを使用する対応の誤り訂正が必要にならない。
第１の実施形態によれば、ｅＮｏｄｅＢも、ＰｒｏＳｅ対応ＵＥについて説明したばかりの方式に対応する方式で適合されるものとする。ＵＥにおける送信プロトコルの制御下におけるデータ送信の受信機であり、かつＵＥのスケジューリングを行う役割を担うエンティティであるｅＮｏｄｅＢも、ＵＥと同様の方式で送信プロトコルの動作を記録する。したがって、ｅＮｏｄｅＢも、ＵＥの送信プロトコルの動作とサイドリンクディスカバリオペレーションとの起こりうる衝突を監視することにより、ＵＥが上記のような妨げられたデータパケットを再送信することによって送信カウンタがインクリメントされないようにｅＮｏｄｅＢ内の送信カウンタを動作させる。これにより必然的に、ｅＮｏｄｅＢは、ＵＥについて上述した衝突と同一の種類の衝突を監視することになる。したがって、同一のデータパケットについてのＵＥの送信カウンタおよびｅＮＢの対応する送信カウンタは、同期される。
第１の実施形態のさらなる実装によれば、測定用ギャップにおけるアップリンクＨＡＲＱプロトコル動作の調整が説明される。背景技術のセクションにおいて説明したように、ＵＥは、ｅＮｏｄｅＢがＵＥに設定する測定用ギャップにおいて特定の測定（例えば、モビリティ測定）を行うことができる。サイドリンクディスカバリギャップの場合と同様に、アップリンクＨＡＲＱ送信プロトコル動作は、ＵＥが測定用ギャップにおいてｅＮｏｄｅＢからダウンリンクチャネルを受信することができない点、および、測定用ギャップにおいてｅＮｏｄｅＢにアップリンク送信を行うことができない点でこれらの測定用ギャップによって制限されている。例えば、規格である非特許文献２の現在定義されたＨＡＲＱプロトコル動作によれば、ＵＥは、測定用ギャップとの衝突によりＰＨＩＣＨを介した予期していたＨＡＲＱフィードバックを受信することができなかった場合、ＡＣＫを受信したと考える。
しかしながら、ＨＡＲＱプロトコル動作とサイドリンクディスカバリギャップとの調整とは対照的に、ＵＥは、再送信が測定用ギャップによって実際には妨げられたか否かとは無関係に、データパケットの再送信がＨＡＲＱプロトコルによってトリガされる場合に必ず該データパケットについて送信カウンタを増加する。その結果、後に測定用ギャップによって妨げられる、データパケットのトリガされた再送信は、サイドリンクディスカバリギャップによって妨げられたトリガされた再送信とは対照的に送信カウンタをインクリメントする。これにより、サイドリンクディスカバリギャップより時間長が非常に小さい測定用ギャップに関するＨＡＲＱプロトコルの動作は単純化される。測定用ギャップがＨＡＲＱプロセスの１つのＨＡＲＱ（再）送信機会を妨げるのみである（すなわち、測定用ギャップが７ｍｓであるのに対し、ＨＡＲＱ ＲＴＴは８ｍｓである）からである。したがって、単純なＨＡＲＱプロトコル動作においてこの１つのＨＡＲＱ送信機会を失うことは、許容可能である。すなわち、ＵＬ ＨＡＲＱ送信および測定用ギャップの衝突をＵＥ側およびｅＮＢ側で検出する必要はない。
［第２の実施形態］
以下、第１の実施形態によって解決されたものと同一の課題（すなわち、発明を実施するための形態の初めに説明した課題）を扱う第２の実施形態を提示する。
第２の実施形態についても第１の実施形態についての想定と同一の想定をすることができる。簡潔に言うと、ＵＥは対応するＨＡＲＱエンティティおよびＨＡＲＱプロセスを有するＭＡＣ ＨＡＲＱプロトコルを実行することにより、ＭＡＣ ＰＤＵ（データパケットまたはトランスポートブロックともいう）の送信および再送信を制御することが想定される。送信カウンタが各アップリンクＨＡＲＱプロセスに設定され、ＵＥには、この送信カウンタおよびＨＡＲＱプロセスによって提供されるデータパケットの許容可能最大送信回数を示す最大カウンタ値が設定される。送信カウンタにおいてこの許容可能最大送信回数に達すると、ＨＡＲＱプロセスの対応するバッファがフラッシュされる。ＵＥは、ＰＨＩＣＨを介してアップリンクＨＡＲＱプロトコル動作におけるフィードバックを受信し、かつ／またはＰＤＣＣＨを介してアップリンクグラントを受信する。第２の実施形態の特定の実装例も、背景技術のセクションにおいて説明したＨＡＲＱプロトコルに基づいていてもよい。ＨＡＲＱプロトコルは、規格である非特許文献２の、特に下記に説明するように特定の変更を加えた５．４．２節「ＨＡＲＱ動作」に従っている。この場合、パラメータmaxHARQ-Txは、送信カウンタに関して使用されるデータパケットの許容可能最大送信回数を示す。
任意選択的に、ＵＥは、上位レイヤ（例えば、ＲＬＣ）においてさらなる（再）送信プロトコルを実行することによって、下位レイヤのＭＡＣレイヤでのＨＡＲＱプロトコル動作中に生じるエラー（例えば、ＮＡＣＫ−ｔｏ−ＡＣＫエラーや損失データパケット）からのさらなるリカバリを行ってもよい。第２の実施形態の特定の実装例によれば、背景技術のセクションにおいて説明したようなＲＬＣ再送信プロトコル動作を使用することができる。
さらに、ＵＥがＰｒｏＳｅ対応であり、事前に定義されたサイドリンクディスカバリ信号を交換することによって、他のＰｒｏＳｅ対応ユーザ端末とのサイドリンクディスカバリオペレーションに参加することが想定されている。さらに、例として、第１の実施形態について既に詳細に説明したようにサイドリンクディスカバリギャップ（受信用サイドリンクディスカバリギャップおよび／または送信用サイドリンクディスカバリギャップ）を設定することによって、キャリア間ＰｒｏＳｅ動作がサポートおよび支援されることが想定されている。つまり、サイドリンクディスカバリギャップがＵＥの送信動作／受信動作を制限することになる。
ここで、第２の実施形態に係るＨＡＲＱプロトコル動作とサイドリンクディスカバリオペレーションとの最適化された調整を、上記の例示的な想定に基づいて説明する。規格において現在規定されるように、データパケットの再送信がトリガされるたびに該データパケットについて送信カウンタをインクリメントするＨＡＲＱプロトコルに規定された処理が、再送信が実際に行われるか、サイドリンクディスカバリオペレーションによって妨げられるかとは無関係に実際に行われる。第１の実施形態の複数の変形形態のように、ＵＥは、ＨＡＲＱプロトコル動作とサイドリンクディスカバリオペレーションとの衝突が発生する場合を判定することができる。すなわち、ＵＥは、トリガされた再送信がサイドリンクディスカバリの並行動作および対応するサイドリンクディスカバリギャップが理由で行われない場合を判定する。
そのような衝突がＵＥによって検出される場合、第２の実施形態に係るＨＡＲＱプロトコル動作では、再送信がサイドリンクディスカバリギャップと衝突したデータパケットの対応する送信カウンタを動作させるために、増加した許容可能最大送信回数を使用するさらなる処理が規定されている。したがって、許容可能最大送信回数の増加によって、データパケットの、トリガはされたが妨げられた再送信による送信カウンタのインクリメントが補償される。
図１０は、第２の実施形態に係るＵＥの動作のためのシーケンス図を例示する。図１０から明らかなように、送信カウンタは、データパケットの再送信がトリガされるとインクリメントされる。一方、衝突が検出される場合、許容可能最大送信回数の値（すなわち、最大送信限度）は増加され、送信カウンタの後の動作に適用される。
第２の実施形態のより具体的な変形形態を以下に記載する。第１の実施形態に関して既に説明したように、ＨＡＲＱ動作とサイドリンクディスカバリオペレーションとの衝突は、少なくとも２つの異なる理由で発生する場合があり、ＵＥは、これらの衝突を監視および検出することができなければならない。
つまり、受信サイドリンクディスカバリギャップにおいて、ＵＥは、他のダウンリンクチャネルの受信が妨げられる。これらのダウンリンクチャネルの受信には、以前送信したデータパケットのＰＨＩＣＨを介したＨＡＲＱフィードバックの受信、および／またはアップリンク再送信（例えば、適応再送信）をスケジューリングするためのＤＣＩを含むＰＤＣＣＨの受信が含まれる。したがって、受信サイドリンクディスカバリギャップにおいてＨＡＲＱフィードバックを受信できないことによって、ＨＡＲＱ動作が妨げられるため、ＵＥは対応するアップリンク再送信を行わない。したがって、ＵＥは、そのような衝突を監視・識別する。送信サイドリンクディスカバリギャップにおいては、アップリンクにおける送信よりもサイドリンクディスカバリ送信が優先されるため、ＵＥは、実際にアップリンクにおける送信を行うことが妨げられうる。アップリンクにおける送信は、ＨＡＲＱプロトコルにしたがって行われるあらゆる送信または再送信である。したがって、ＵＥは、そのような衝突を監視・識別する。
衝突が検出される場合に、特定の送信カウンタの動作に適用されるデータパケットの許容可能最大送信回数を増加する第２の実施形態の様々な実装例がある。
１つのオプションによれば、許容可能最大送信回数のための新規パラメータが使用され、例えば、ｅＮｏｄｅＢによってＵＥに設定される。この新規パラメータ（例としてmaxHARQ-TxSLgapとする）は、トリガされたものの、ＵＥによって同時に実行されるサイドリンクディスカバリによって後に妨げられる再送信によって送信カウンタがインクリメントされる状況に適用可能であるように追加的に導入される。ｅＮｏｄｅＢは、この追加的な衝突用送信カウンタパラメータ（collision-specific transmission counter parameter）を設定・構成する役割を担うことができ、例えば、ＨＡＲＱプロトコル動作を設定する際に（例えば、送信カウンタの動作のための、当初使用されていたパラメータmaxHARQ-Txを提供するのと同時に）ＵＥにこのパラメータを送信することができる。同様に、新規パラメータmaxHARQ-TXSLgapの値を、ＵＥが当初送信カウンタの動作に用いた通常のパラメータmaxHARQ-Txの対応する値より高く設定することができる。ここで、ｅＮｏｄｅＢが通常のパラメータも、ＵＥがサイドリンクディスカバリを行うために使用するサイドリンクギャップの長さも認識していることに留意されたい。同様に、ｅＮｏｄｅＢは、サイドリンクディスカバリギャップにおいてサイドリンクディスカバリオペレーションによって妨げられる可能性がある、ＵＥに利用可能な再送信機会の数も認識する。例えば、サイドリンクディスカバリギャップが４０ｍｓであり、再送信機会が８ｍｓごとに生じることを想定すると（図３を参照）、最大５回の再送信機会が妨げられる可能性がある。したがって、ｅＮｏｄｅＢは、他方の送信カウンタパラメータmaxHARQ-Txの値と比較して、妨げられる再送信機会の数に対応して増加された（例えば、５増加された）値を新規な衝突用パラメータmaxHARQ-TXSLgapとして使用してもよい。
他のオプションによれば、追加的な衝突用パラメータを使用する代わりに、ＵＥは、衝突がある場合に、送信カウンタに適用された許容可能最大送信回数を自身で変更することができる。例えば、ＵＥがトリガされた再送信について発生する衝突を検出する場合、ＵＥは、また、対応する送信カウンタに適用可能な許容可能最大送信回数をインクリメントする（この送信カウンタは、トリガされた再送信により先にインクリメントされている）。図１１は、第２の実施形態におけるこのオプションに従ったＵＥの動作を例示する。図１１から明らかなように、衝突の検出時、ＵＥの動作では、送信カウンタの最大送信限度がインクリメントされる（すなわち、送信カウンタを動作させるための以前に設定された許容可能最大送信回数がインクリメントされる）。
いかなる場合も、後にサイドリンクディスカバリギャップと衝突したために実際には行われなかった、トリガされたデータパケット再送信によってインクリメントされた送信カウンタの許容可能最大送信回数が増加されることにより、データパケットの再送信の衝突が原因でＨＡＲＱバッファがフラッシュされることが回避される。したがって、ＵＥは、サイドリンクディスカバリギャップの後により多くの再送信機会を有するため、受信側エンティティ（すなわち、ｅＮｏｄｅＢ）に首尾よくデータパケットを送信する。
また、第２の実施形態は、先にＵＥについて説明した方式と同様の方式で適合されるｅＮｏｄｅＢを提供する。ＵＥにおける送信プロトコルの制御下におけるデータ送信の受信機であり、かつＵＥの送信および／または再送信のスケジューリングを行う役割を担うエンティティであるｅＮｏｄｅＢも、ＵＥと同様の方式で送信プロトコルの関連部分を実行すべきである。したがって、ｅＮｏｄｅＢも、ＵＥの送信プロトコルの動作とＵＥのサイドリンクディスカバリオペレーションとの起こりうる衝突を監視すべきである。したがって、ｅＮｏｄｅＢも、ＵＥが行ったように、対応する送信カウンタの許容可能最大送信回数を増加する。したがって、同一のデータパケットについてのＵＥにおける送信カウンタ、およびｅＮｏｄｅＢにおける対応する送信カウンタは、同一の方式で動作される。
第１の実施形態に関して既に説明したように、第２の実施形態のさらなる実装には、測定用ギャップにおけるアップリンクＨＡＲＱプロトコル動作の調整が含まれうる。簡潔に言うと、測定用ギャップが、特定の測定を行うためにＵＥによって使用される結果、アップリンクＨＡＲＱ送信プロトコル動作が制限される。例えば、ＵＥは、測定用ギャップにおいてｅＮｏｄｅＢからダウンリンクチャネル（例えば、ＨＡＲＱフィードバック）を受信することができない。また、ＵＥは、測定用ギャップにおいてｅＮｏｄｅＢにアップリンク送信を行うことができない。
上述の第２の実施形態に係るＨＡＲＱプロトコル動作とサイドリンクディスカバリギャップとの調整とは対照的に、ＨＡＲＱプロトコルによってデータパケットの再送信がトリガされるたびに、ＵＥは送信カウンタを増加し、トリガされた再送信と測定用ギャップとの衝突が発生したか否かとは無関係に、送信カウンタを動作させるための最初に設定された許容可能最大送信回数を使用し続ける。
したがって、測定用ギャップによって妨げられた、データパケットのトリガされた再送信は、サイドリンクディスカバリギャップによって妨げられたトリガされた再送信とは対照的に送信カウンタの動作を変更しない。上述のように、これにより、サイドリンクディスカバリギャップより時間長が非常に小さい測定用ギャップに関するＨＡＲＱプロトコル動作が単純化される。
［第３の実施形態］
以下、さらに第１のおよび第２の実施形態によって解決された課題と同一の課題を扱う第３の実施形態を提示する。第３の実施形態についても、第１のおよび第２の実施形態についての想定と同一の想定をすることができる。簡潔に言うと、ＵＥは、対応するＨＡＲＱエンティティおよびＨＡＲＱプロセスを有するＭＡＣアップリンクＨＡＲＱプロトコルを実行することにより、ＭＡＣ ＰＤＵ（データパケットまたはトランスポートブロックともいう）の送信および再送信を制御することが想定される。送信カウンタが各ＨＡＲＱプロセスに設定され、特に、送信カウンタが許容可能最大送信回数に達する場合にデータパケットのＨＡＲＱプロセスに関連付けられたバッファをフラッシュするために使用される。ＵＥは、ＰＨＩＣＨを介してＨＡＲＱプロトコル動作におけるフィードバックを受信し、かつ／またはＰＤＣＣＨを介してアップリンクグラントを受信する。第２の態様の特定の実装例も、背景技術のセクションにおいて説明したＭＡＣ ＨＡＲＱプロトコルに基づいていてもよい。ＭＡＣ ＨＡＲＱプロトコルは、規格である非特許文献２の、特に、下記に説明するようにさらに適合された５．４．２節「ＨＡＲＱ動作」に従っている。
さらに、第３の実施形態における想定では、ＵＥは、上位レイヤ（例えば、ＲＬＣ）において他の（再）送信プロトコルを実行することによって、下位レイヤのＭＡＣレイヤでのＨＡＲＱプロトコル動作中に生じるエラー（例えば、ＮＡＣＫ−ｔｏ−ＡＣＫエラーや損失データパケット）からのさらなるリカバリを行ってもよい。第３の実施形態の特定の実装例によれば、背景技術のセクションにおいて説明したようなＲＬＣ再送信プロトコル動作を使用することができる。
さらに、ＵＥがＰｒｏＳｅ対応であり、事前に定義されたサイドリンクディスカバリ信号を交換することによって、他のＰｒｏＳｅ対応ユーザ端末とのサイドリンクディスカバリオペレーションに参加することが想定されている。さらに、例として、第１の実施形態について既に詳細に説明したようにサイドリンクディスカバリギャップ（受信用サイドリンクディスカバリギャップおよび／または送信用サイドリンクディスカバリギャップ）を設定することによって、キャリア間ＰｒｏＳｅ動作がサポートおよび支援されることが想定されている。要するに、サイドリンクディスカバリギャップは、ＵＥの送信動作／受信動作を制限する。
この第３の実施形態は、ＭＡＣ ＨＡＲＱプロトコル動作を最適化するだけでなくＲＬＣ送信プロトコルの動作、ＭＡＣ ＨＡＲＱプロトコル動作、およびサイドリンクディスカバリオペレーションの調整を最適化する点で第１のおよび第２の実施形態と異なる。第１のおよび第２の実施形態について既に説明したように、ＵＥは、ＭＡＣ ＨＡＲＱプロトコル動作とサイドリンクディスカバリオペレーションとの衝突を検出することができる。すなわち、ＵＥは、トリガされたＨＡＲＱ再送信がサイドリンクディスカバリの並行動作およびサイドリンクディスカバリギャップが理由で行われない場合を判定する。ＭＡＣ ＨＡＲＱプロトコル動作によれば、ＵＥは、再送信が実際に実行されるか、サイドリンクディスカバリオペレーションによって妨げられるかとは無関係に、データパケットの再送信がＨＡＲＱプロトコルによってトリガされるたびに、該データパケットについて送信カウンタをインクリメントする。
第３の実施形態によれば、ＵＥにおけるサイドリンクディスカバリオペレーションとの衝突により失われたデータパケットのＲＬＣ再送信をトリガする新たなトリガが設定される。より具体的には、新たなトリガは、サイドリンクディスカバリギャップとの衝突が原因で行われなかったトリガされた再送信によって送信カウンタがインクリメントされた後にその限度（すなわち許容可能最大送信回数）に達したためにデータパケットを含むＨＡＲＱバッファがフラッシュされたかに依存する。そのような場合、ＭＡＣレイヤは、対応するＲＬＣエンティティに対し、ＨＡＲＱ送信バッファからフラッシュされたＭＡＣ ＰＤＵに含まれていたＲＬＣ ＰＤＵの再送信をスケジューリングすることをトリガする。したがって、この新たな第３の実施形態によって、新たなＭＡＣ／ＲＬＣ相互作用が導入される。
また、外部ＲＬＣ送信プロトコルは、損失データパケット（すなわち、ＲＬＣ ＰＤＵ）を再送信する役割を担う。背景技術のセクションにおいて説明したように、ＲＬＣ再送信は、通常、欠けているシーケンス番号に基づいて損失データパケットを検出したかもしれない受信側エンティティから送信機が対応するＲＬＣ状況報告を受信する場合に送信機においてトリガされる。
第３の実施形態によれば、ＲＬＣ再送信のための新たなトリガが定義されている。この新たなトリガによって、例えば、受信側エンティティは、損失データパケットを最初に検出すること、および、それにより対応するＲＬＣ状況報告を介してＵＥにおける対応するＲＬＣ ＡＭ送信側エンティティに該損失データパケットの再送信を要求することが必要なくなる。この新たなトリガは、送信側で発生する。すなわち、より正確には、ＭＡＣエンティティは、対応するＲＬＣ再送信側エンティティに対して、対応するＲＬＣ再送信を行うことをトリガする。
この新たなトリガは、様々な方式で実装されうる。例えば、ＵＥは、サイドリンクディスカバリギャップと衝突したために実際には行われなかったトリガされた再送信が理由で、送信カウンタがインクリメントされたかを記録してもよく、場合によっては、インクリメントされた回数を記録してもよい。この場合、そのような送信カウンタが許容可能最大送信回数に達することによって、対応するＨＡＲＱバッファがフラッシュされる場合、対応するＲＬＣ再送信がトリガされる。１つの変形例では、送信カウンタの衝突によるインクリメントは１回で十分であり、また、他の変形例では、閾値に基づくアプローチを構想することができる。この変形例では、対応する閾値（例えば、３）が設定され、ＵＥは、そのようなトリガされたが妨げられた再送信に起因して送信カウンタがインクリメントされた回数を（例えば、適切なカウンタによって）数える。そして、データパケットに含まれるＲＬＣ ＰＤＵのＲＬＣ再送信は、対応する送信カウンタが許容可能な再送信の最大回数に達することによって、対応するＨＡＲＱバッファをフラッシュする場合であって、そのようにトリガされたが妨げられた再送信に起因するインクリメントの回数が、かかる再送信に関して以前に設定された衝突閾値以上である場合にのみトリガされる。
他のより単純な実装によれば、データパケット（ＭＡＣ ＰＤＵ）に含まれていたＲＬＣ ＰＤＵのＲＬＣ再送信は、ＨＡＲＱバッファがフラッシュされる条件である送信カウンタの最後のインクリメントが、サイドリンクディスカバリギャップにおける対応するサイドリンクディスカバリオペレーションと衝突することにより実際には妨げられるトリガされた再送信によって引き起こされる場合にトリガされる。
現在のＬＴＥ標準、特に、現在の規格である非特許文献５（現行のバージョン１３．０．０）に基づく第３の実施形態の特定の実施によれば、ＲＬＣ ＰＤＵ再送信のための新たなトリガについての記載を５．２．１節に追加することができる。また、新たなトリガは、ＨＡＲＱプロセスのためのＨＡＲＱプロトコル動作を規定する非特許文献２の５．４．２．２節に含まれうる。ここで、上述の追加的な条件でＨＡＲＱバッファをフラッシュする際に、ＵＥが、対応するＲＬＣエンティティに対して、ＭＡＣ ＰＤＵに含まれていた対応するＲＬＣ ＰＤＵの再送信を行うことをこのＨＡＲＱプロセスで知らせることが規定される。
第１のおよび第２の実施形態に関して既に説明したように、第３の実施形態の実装には、測定用ギャップにおけるアップリンクＨＡＲＱプロトコル動作の調整が含まれうる。
上述の第３の実施形態に係るＲＬＣ再送信を行うための追加のトリガを提供することとは対照的に、トリガされた再送信と測定用ギャップとの衝突に関しては、そのような新たなトリガは予見されない。したがって、送信カウンタが、測定用ギャップによって妨げられたトリガされた再送信によってインクリメントされた後に最大送信限度に達することが理由でＨＡＲＱバッファがフラッシュされる場合、サイドリンクディスカバリギャップによって妨げられたトリガされた再送信によって送信カウンタがインクリメントされた場合とは異なり、対応するＲＬＣ再送信は、ＨＡＲＱバッファがフラッシュされることによってトリガされない。
［さらなる実施形態］
第１の態様によれば、通信システムにおいてアップリンクデータパケット送信のための送信プロトコルを実行する送信側ユーザ端末が提供される。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。ユーザ端末は、送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したために行われなかったかを判定するプロセッサを備える。そして、衝突がある場合、プロセッサは、データパケットが衝突する再送信が該データパケットについては送信プロトコルの送信カウンタをインクリメントしないように送信カウンタをさらに動作させる。
第１の態様に加えて提供される第２の態様によれば、ユーザ機器には、送信用サイドリンクディスカバリギャップが設定される。送信用サイドリンクディスカバリギャップにおいて、ユーザ端末は、サイドリンク接続を介して他のユーザ端末にサイドリンクディスカバリメッセージを送信することができる。プロセッサは、送信用サイドリンクディスカバリギャップとの衝突が理由でデータパケットの再送信を行うことができない場合（好ましくは、ユーザ端末が送信用サイドリンクディスカバリギャップにおいてサイドリンクディスカバリメッセージを送信する場合）、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したためにデータパケットの再送信が行われなかったと判定する。追加または代替として、ユーザ端末には、受信用サイドリンクディスカバリギャップが設定される。受信用サイドリンクディスカバリギャップにおいて、ユーザ端末は、サイドリンク接続を介して他のユーザ端末から送信されるサイドリンクディスカバリメッセージを監視する。プロセッサは、データパケットの以前の送信に関する送信プロトコルのフィードバックが受信用サイドリンクディスカバリギャップとの衝突が理由で受信されない場合、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したためにデータパケットの再送信が行われなかったと判定する。
第１のまたは第２の態様に加えて提供される第３の態様によれば、送信プロトコルは、再送信が送信プロトコルによってトリガされる場合に送信プロトコルの送信カウンタを１インクリメントする処理を規定する。プロセッサは、衝突がある場合に、再送信が送信プロトコルによってトリガされる場合に送信カウンタを１インクリメントする処理を行わないことによって、データパケットが衝突する再送信によって該データパケットについて送信カウンタがインクリメントされないように送信プロトコルを実行する。あるいは、プロセッサは、衝突がある場合に、再送信が送信プロトコルによってトリガされる場合に送信プロトコルの送信カウンタを１インクリメントする処理を行い、次いで、送信カウンタを１減少する処理を行うことによって、データパケットが衝突する再送信によって該データパケットについて送信カウンタがインクリメントされないように送信プロトコルを実行する。
第１の態様から第３の態様の１つに加えて提供される第４の態様によれば、データパケットの再送信は、送信プロトコルと関連付けられたバッファが空ではなく（また、データパケットについて否定的再送信フィードバックが保留されており）、かつ／または、以前送信したデータパケットを再送信するためのアップリンクグラントを基地局から受信する場合に送信プロトコルにしたがってトリガされる。
第１の態様から第４の態様の１つに加えて提供される第５の態様によれば、ユーザ端末は、送信プロトコルにしたがったデータパケットの送信および再送信とは異なる周波数キャリアでサイドリンクディスカバリに参加している。
第１の態様から第５の態様の１つに加えて提供される第６の態様によれば、ユーザ端末には、データパケットの許容可能最大送信回数が設定される。送信プロトコルは、送信カウンタがデータパケットの許容可能最大送信回数の限度に達する場合に送信プロトコルの該データパケットを格納するバッファをフラッシュする処理を規定する。
第１の態様から第６の態様の１つに加えて提供される第７の態様によれば、ユーザ端末には、ユーザ端末がチャネル測定を行うことができる少なくとも１つの測定用ギャップが設定される。ユーザ端末は、測定用ギャップにおいて、送信プロトコルの制御下における信号を送信および／または受信することができない。プロセッサは、送信プロトコルによってトリガされた再送信が、送信プロトコルの動作が測定用ギャップと衝突したために行われなかった場合に、該データパケットについて送信プロトコルの送信カウンタを１インクリメントするように設定される。
第８の態様によれば、通信システムにおいてアップリンクデータパケット送信のためのプロトコルを実行するユーザ端末が提供される。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末には、データパケットの許容可能最大送信回数を設定する第１の送信カウンタパラメータが送信カウンタの動作のために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。ユーザ端末は、データパケットの再送信が送信プロトコルによってトリガされる場合に、該データパケットについて送信カウンタをインクリメントするプロセッサを備える。プロセッサは、データパケットのトリガされた再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したために行われなかったかをさらに判定する。そして、衝突がある場合、プロセッサは、データパケットの送信カウンタの動作のために第２の送信カウンタパラメータを使用することによって送信カウンタのためにデータパケットの許容可能最大送信回数を増加する。
第８の態様に加えて提供される第９の態様によれば、ユーザ端末には、基地局によって、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したために行われなかったデータパケットの再送信のトリガリングによってインクリメントされた送信カウンタに適用可能な第２の送信カウンタパラメータが設定される。任意選択的に、第２の送信カウンタパラメータは、第１の送信カウンタパラメータによって示されるデータパケットの許容可能最大送信回数より大きいデータパケットの許容可能最大送信回数を示し、この増加は、サイドリンクディスカバリギャップの長さに依存する。
第８の態様に加えて提供される第１０の態様によれば、第２の送信カウンタパラメータは、プロセッサが衝突を判定するたびに第１の送信カウンタパラメータをインクリメントすることによってユーザ端末によって生成される。
第８の態様から第１０の態様に加えて提供される第１１の態様によれば、送信プロトコルは、送信カウンタが第１のまたは第２の送信カウンタパラメータによって設定された許容可能最大送信回数に達する場合に、送信プロトコルのデータパケットを格納するバッファをフラッシュする処理を規定している。
第８の態様から第１１の態様に加えて提供される第１２の態様によれば、ユーザ機器には、送信用サイドリンクディスカバリギャップが設定される。送信用サイドリンクディスカバリギャップにおいて、ユーザ端末がサイドリンク接続を介して他のユーザ端末にサイドリンクディスカバリメッセージを送信することができる。プロセッサは、送信用サイドリンクディスカバリギャップとの衝突が理由でデータパケットの再送信を行うことができない場合（好ましくは、ユーザ端末が送信用サイドリンクディスカバリギャップにおいてサイドリンクディスカバリメッセージを送信する場合）、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したためにデータパケットの再送信が行われなかったと判定する。追加または代替として、ユーザ端末には、受信用サイドリンクディスカバリギャップが設定される。受信用サイドリンクディスカバリギャップにおいて、ユーザ端末は、サイドリンク接続を介して他のユーザ端末から送信されるサイドリンクディスカバリメッセージを監視する。プロセッサは、データパケットの以前の送信に関する送信プロトコルのフィードバックが受信用サイドリンクディスカバリギャップとの衝突が理由で受信されない場合、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したためにデータパケットの再送信が行われなかったと判定する。
第１３の態様によれば、通信システムにおいてユーザ端末からアップリンクデータパケット送信を受信する基地局が提供される。ユーザ端末は、アップリンクデータパケット送信のための送信プロトコルを実行し、データパケットについてユーザ端末が行った送信の回数を数える第１の送信カウンタがユーザ端末の送信プロトコルのために構成されている。ユーザ端末がデータパケットについて行った送信回数を数える第２の送信カウンタが、基地局に設定される。ユーザ端末は、サイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように基地局によって設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。基地局は、ユーザ端末の送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したためにユーザ端末によって行われなかったかを判定するプロセッサを備える。そして、衝突がある場合、プロセッサは、データパケットが衝突する送信が該データパケットについては送信プロトコルの第２の送信カウンタをインクリメントしないように第２の送信カウンタを動作させる。
第１４の態様によれば、通信システムにおいてアップリンクデータパケット送信のためのユーザ端末における送信プロトコルを実行する方法が提供される。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。本方法には、送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したために行われなかったかをユーザ端末が判定するステップが含まれる。衝突がある場合、ユーザ端末は、データパケットが衝突する再送信が該データパケットについては送信プロトコルの送信カウンタをインクリメントしないように送信カウンタを動作させる。
第１４の態様に加えて提供される第１５の態様によれば、送信プロトコルは、再送信が送信プロトコルによってトリガされる場合に送信プロトコルの送信カウンタを１インクリメントする処理を規定する。データパケットが衝突する再送信がデータパケットの送信カウンタをインクリメントしないように送信プロトコルを実行するステップでは：
・ 衝突がある場合、再送信が送信プロトコルによってトリガされる場合に送信カウンタを１インクリメントするステップを行わない、または、
・ 衝突がある場合、再送信が送信プロトコルによってトリガされる場合に送信プロトコルの送信カウンタを１インクリメントするステップを行い、かつ、次いで送信カウンタを１減少させるステップを行う。
第１４の態様または第１５の態様に加えて提供される第１６の態様によれば、ユーザ端末には、ユーザ端末がチャネル測定を行うことができる少なくとも１つの測定用ギャップが設定される。ユーザ端末は、測定用ギャップにおいて、送信プロトコルの制御下における信号を送信および／または受信することができない。本方法は、送信プロトコルによってトリガされた再送信が、送信プロトコルの動作が測定用ギャップと衝突したために行われなかった場合に、該データパケットについて送信プロトコルの送信カウンタを１インクリメントするステップをさらに含む。
第１７の態様によれば、通信システムにおいてユーザ端末からアップリンクデータパケット送信を受信する基地局が提供される。ユーザ端末は、アップリンクデータパケット送信のための送信プロトコルを実行する。ユーザ端末がデータパケットについて行った送信回数を数える第１の送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末がデータパケットについて行った送信回数を数える第２の送信カウンタが、基地局に設定される。第１の送信カウンタパラメータが、第１のおよび第２の送信カウンタの動作のためのデータパケットの許容可能最大送信回数を設定する。ユーザ端末は、サイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように基地局によって設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。基地局は、ユーザ端末においてデータパケットの再送信が送信プロトコルによってトリガされる場合に、該データパケットについて第２の送信カウンタをインクリメントするプロセッサを備える。そして、プロセッサは、ユーザ端末の送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したためにユーザ端末によって行われなかったかを判定する。衝突がある場合、プロセッサは、データパケットの第２の送信カウンタの動作のために第２の送信カウンタパラメータを使用することによって第２の送信カウンタのためにデータパケットの許容可能最大送信回数を増加する。
第１８の態様によれば、通信システムにおいてアップリンクデータパケット送信のためのユーザ端末における送信プロトコルを実行する方法が提供される。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末には、データパケットの許容可能最大送信回数を設定する第１の送信カウンタパラメータが送信カウンタの動作のために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および／または受信することができない。本方法は、データパケットの再送信が送信プロトコルによってトリガされる場合にユーザ端末がデータパケットについて送信カウンタをインクリメントするステップと、データパケットのトリガされた再送信が送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したために行われなかったかを判定するステップを含む。そして、衝突がある場合、ユーザ端末は、データパケットの送信カウンタの動作のために第２の送信カウンタパラメータを使用することによって送信カウンタのためにデータパケットの許容可能最大送信回数を増加する。
第１８の態様に加えて提供される第１９の態様によれば、ユーザ端末には、基地局によって、送信プロトコルの動作がサイドリンクディスカバリギャップの１つと衝突したために行われなかったデータパケットの再送信のトリガリングによってインクリメントされた送信カウンタに適用可能な第２の送信カウンタパラメータが設定される。任意選択的に、第２の送信カウンタパラメータは、第１の送信カウンタパラメータによって示されるデータパケットの許容可能最大送信回数より大きいデータパケットの許容可能最大送信回数を示し、この増加は、サイドリンクディスカバリギャップの長さに依存する。
第１８の態様に加えて提供される第２０の態様によれば、第２の送信カウンタパラメータは、プロセッサが衝突を判定するたびに第１の送信カウンタパラメータをインクリメントすることによってユーザ端末によって生成される。
［ハードウェアおよびソフトウェアによる本開示の実施］
他の例示的な実施形態は、上述したさまざまな実施形態を、ハードウェア、ソフトウェア、またはハードウェアと協働するソフトウェアを使用して実施することに関する。これに関連して、ユーザ機器（移動端末）およびｅＮｏｄｅＢ（基地局）を提供する。ユーザ端末は、本明細書に記載されている方法を実行するように適合されており、これらの方法に適切に関与する対応のエンティティ（受信機、送信機、プロセッサなど）を含む。
さまざまな実施形態がコンピューティングデバイス（プロセッサ）を使用して実施または実行されうることがさらに認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuit）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Field Programmable Gate Array）、または、その他プログラマブルロジックデバイスなどである。さまざまな実施形態は、これらのデバイスの組合せによっても実行または具現化されうる。特に、上述の各実施形態の説明において使用される各機能ブロックは、集積回路としてのＬＳＩによって実施することができる。各機能ブロックを個々にチップとして形成してもよいし、１つのチップを、機能的ブロックの一部または全部を含むように形成してもよい。チップは、チップに結合されたデータ入力部およびデータ出力部を有しうる。本明細書においてＬＳＩを、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩということもできる。集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。また、ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）または、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブルプロセッサを利用してもよい。
さらに、さまざまな実施形態は、ソフトウェアモジュールによっても実施され得る。これらのソフトウェアモジュールは、プロセッサによって実行されるか、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭまたはＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納され得る。さらには、複数の異なる実施形態の個々の特徴は、個々に、または任意の組合せにおいて、別の実施形態の主題とすることができることに留意されたい。
具体的な実施形態に示した本開示には、広義に記載されている本発明の概念または範囲から逸脱することなく、さまざまな変更および／または修正を行うことができることが、当業者には理解されるであろう。したがって、本明細書に示した実施形態は、あらゆる点において例示的であり、本発明を制限するものではないものとみなされる。

Claims (20)

  1. 通信システムにおけるアップリンクデータパケット送信のための送信プロトコルを実行するユーザ端末であって、
    前記ユーザ端末が行ったデータパケット送信の回数を数える送信カウンタが前記ユーザ端末の前記送信プロトコルのために設定されており、
    前記ユーザ端末は、前記ユーザ端末のために設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定されており、前記ユーザ端末は、前記サイドリンクディスカバリギャップの間にサイドリンクディスカバリオペレーションに参加している場合、前記送信プロトコルの制御下における信号を送信および／または受信することができず、
    前記ユーザ端末は、
    前記送信プロトコルによってトリガされたデータパケットの再送信が、前記送信プロトコルの動作が前記サイドリンクディスカバリギャップの１つと衝突したために行われなかったかどうかを判定するプロセッサを備え、
    衝突がある場合、前記プロセッサは、さらに、前記データパケットの前記衝突する再送信が前記送信プロトコルの前記データパケットの前記送信カウンタをインクリメントしないように前記送信カウンタを動作させる、
    ユーザ端末。
  2. 前記ユーザ端末は、前記ユーザ端末がサイドリンク接続を介して他のユーザ端末にサイドリンクディスカバリメッセージを送信することができる送信用サイドリンクディスカバリギャップを有するように設定されており、
    前記プロセッサは、
    前記送信用サイドリンクディスカバリギャップとの衝突が理由で前記データパケットの再送信を送信することができない場合、すなわち、前記ユーザ端末が送信用サイドリンクディスカバリギャップの間にサイドリンクディスカバリメッセージを送信する場合に、前記送信プロトコルの動作が前記サイドリンクディスカバリギャップの１つと衝突したために前記データパケットの再送信が行われなかったと判定し、
    かつ／または、
    前記ユーザ端末は、受信用サイドリンクディスカバリギャップを有するように設定されており、前記受信用サイドリンクディスカバリギャップの間、前記ユーザ端末は、サイドリンク接続を介して他のユーザ端末から送信されるサイドリンクディスカバリメッセージの有無をモニタリングし、
    前記プロセッサは、
    前記受信用サイドリンクディスカバリギャップとの衝突が理由で前記送信プロトコルの前記データパケットの以前の送信に関するフィードバックが受信されない場合に、前記送信プロトコルの動作が前記サイドリンクディスカバリギャップの１つと衝突したために前記データパケットの再送信が行われなかったと判定する、
    請求項１に記載のユーザ端末。
  3. 前記送信プロトコルは、再送信が前記送信プロトコルによってトリガされる場合に前記送信プロトコルの前記送信カウンタを１インクリメントする処理を規定しており、
    衝突がある場合、前記プロセッサが、再送信が前記送信プロトコルによってトリガされる場合に前記送信カウンタを１インクリメントする前記処理を行わないことによって、または、
    衝突がある場合、前記プロセッサが、再送信が前記送信プロトコルによってトリガされる場合に前記送信プロトコルの前記送信カウンタを１インクリメントする前記処理を行い、かつ、前記プロセッサが、次いで前記送信カウンタを１減少させる処理を行うことによって、
    前記プロセッサは、前記データパケットの前記衝突する再送信が前記データパケットの前記送信カウンタをインクリメントしないように前記送信プロトコルを実行する、
    請求項１または２に記載のユーザ端末。
  4. 前記送信プロトコルに関連付けられたバッファが空ではない時 かつ、前記データパケットの否定的再送信フィードバックがペンディングとなっている時に、以前に送信された前記データパケットを再送信するためのアップリンクグラントを基地局から受信する場合、
    データパケットの再送信が前記送信プロトコルにしたがってトリガされる、
    請求項１から３のいずれかに記載のユーザ端末。
  5. 前記ユーザ端末は、前記送信プロトコルに従ったデータパケットの送信および再送信とは異なる周波数キャリアで前記サイドリンクディスカバリに参加する、
    請求項１から４のいずれかに記載のユーザ端末。
  6. 前記ユーザ端末は、データパケットの許容可能最大送信回数を有するように設定されており、
    前記送信プロトコルは、前記送信カウンタが前記データパケットの許容可能最大送信回数の限度に到達する場合に前記送信プロトコルの前記データパケットを格納するバッファをフラッシュするステップを規定している、
    請求項１から５のいずれかに記載のユーザ端末。
  7. 前記ユーザ端末は、前記ユーザ端末がチャネル測定を行うことができる少なくとも１つの測定用ギャップを有するように設定されており、
    前記ユーザ端末は、前記測定用ギャップの間、前記送信プロトコルの制御下における信号を送信および／または受信することができず、
    前記プロセッサは、前記送信プロトコルの動作が前記測定用ギャップと衝突したために、前記送信プロトコルによってトリガされた再送信が行われなかった場合に、前記送信プロトコルの前記データパケットの前記送信カウンタを１インクリメントする、
    請求項１から６のいずれかに記載のユーザ端末。
  8. 通信システムにおけるアップリンクデータパケット送信のための送信プロトコルを実行するユーザ端末であって、
    前記ユーザ端末が行ったデータパケット送信の回数を数える送信カウンタが前記ユーザ端末の前記送信プロトコルのために設定されており、
    前記ユーザ端末は、前記送信カウンタの動作のためのデータパケットの許容可能最大送信回数を設定する第１の送信カウンタパラメータを有するように設定されており、
    前記ユーザ端末は、前記ユーザ端末のために設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定されており、前記ユーザ端末は、前記サイドリンクディスカバリギャップの間にサイドリンクディスカバリオペレーションに参加している場合、前記送信プロトコルの制御下における信号を送信および／または受信することができず、
    前記ユーザ端末は、
    データパケットの再送信が前記送信プロトコルによってトリガされる場合に、該データパケットの前記送信カウンタをインクリメントするプロセッサを備え、
    前記プロセッサは、さらに、前記データパケットの前記トリガされた再送信が、前記送信プロトコルの動作が前記サイドリンクディスカバリギャップの１つと衝突したために行われなかったかどうかを判定し、
    衝突がある場合、前記プロセッサは、さらに、前記データパケットの前記送信カウンタの動作のために第２の送信カウンタパラメータを使用することによって前記送信カウンタの前記データパケットの許容可能最大送信回数を増加する、
    ユーザ端末。
  9. 前記ユーザ端末は、基地局によって、前記送信プロトコルの処理が前記サイドリンクディスカバリギャップの１つと衝突したために行われなかったデータパケットの再送信のトリガリングによってインクリメントされた送信カウンタに適用可能な前記第２の送信カウンタパラメータを有するように設定されており、
    前記第２の送信カウンタパラメータは、前記第１の送信カウンタパラメータによって示されるデータパケットの許容可能最大送信回数より大きいデータパケットの許容可能最大送信回数を示し、
    この増加は、前記サイドリンクディスカバリギャップの長さに依存する、
    請求項８に記載のユーザ端末。
  10. 前記第２の送信カウンタパラメータは、前記プロセッサが衝突を判定するたびに前記第１の送信カウンタパラメータを前記ユーザ端末がインクリメントすることによって生成される、
    請求項８に記載のユーザ端末。
  11. 前記送信プロトコルは、前記送信カウンタが前記第１のまたは第２の送信カウンタパラメータによって設定された前記許容可能最大送信回数に到達する場合に、前記送信プロトコルの前記データパケットを格納するバッファをフラッシュするステップを規定している、
    請求項８から１０のいずれかに記載のユーザ端末。
  12. 前記ユーザ端末は、前記ユーザ端末がサイドリンク接続を介して他のユーザ端末にサイドリンクディスカバリメッセージを送信することができる送信用サイドリンクディスカバリギャップを有するように設定されており、
    前記プロセッサは、
    前記送信用サイドリンクディスカバリギャップとの衝突が理由で前記データパケットの再送信を送信することができない場合、すなわち、前記ユーザ端末が送信用サイドリンクディスカバリギャップの間にサイドリンクディスカバリメッセージを送信する場合に、前記送信プロトコルの処理が前記サイドリンクディスカバリギャップの１つと衝突したために前記データパケットの再送信が行われなかったと判定し、
    かつ／または、
    前記ユーザ端末は、受信用サイドリンクディスカバリギャップを有するように設定されており、前記受信用サイドリンクディスカバリギャップの間、前記ユーザ端末は、サイドリンク接続を介して他のユーザ端末から送信されるサイドリンクディスカバリメッセージの有無をモニタリングし、
    前記プロセッサは、
    前記受信用サイドリンクディスカバリギャップとの衝突が理由で前記送信プロトコルの前記データパケットの以前の送信に関するフィードバックが受信されない場合に、前記送信プロトコルの動作が前記サイドリンクディスカバリギャップの１つと衝突したために前記データパケットの再送信が行われなかったと判定する、
    請求項８から１２のいずれかに記載のユーザ端末。
  13. 通信システムにおけるユーザ端末からのアップリンクデータパケット送信を受信する基地局であって、
    前記ユーザ端末は、前記アップリンクデータパケット送信のための送信プロトコルを実行し、
    前記ユーザ端末が行ったデータパケット送信の回数を数える送信カウンタが前記ユーザ端末の前記送信プロトコルのために設定されており、
    前記ユーザ端末が行ったデータパケット送信の回数を数える第２の送信カウンタが前記基地局に設定されており、
    前記ユーザ端末は、サイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリ動作に参加するように前記基地局によって設定されており、
    前記ユーザ端末は、前記サイドリンクディスカバリギャップの間にサイドリンクディスカバリ動作に参加している場合、前記送信プロトコルの制御下における信号を送信および／または受信することができず、
    前記基地局は、
    前記ユーザ端末の前記送信プロトコルによってトリガされたデータパケットの再送信が、前記送信プロトコルの動作が前記サイドリンクディスカバリギャップの１つと衝突したために前記ユーザ端末によって行われなかったかどうかを判定するプロセッサを備え、
    衝突がある場合、前記プロセッサは、さらに、前記データパケットの前記衝突する送信が前記送信プロトコルの前記データパケットの前記第２の送信カウンタをインクリメントしないように前記第２の送信カウンタを動作させる、
    基地局。
  14. ユーザ端末において、通信システムにおけるアップリンクデータパケット送信のための送信プロトコルを実行する方法であって、
    前記ユーザ端末が行ったデータパケット送信の回数を数える送信カウンタが前記ユーザ端末の前記送信プロトコルのために設定されており、
    前記ユーザ端末は、前記ユーザ端末のために設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリ動作に参加するように設定されており、前記ユーザ端末は、前記サイドリンクディスカバリギャップの間にサイドリンクディスカバリ動作に参加している場合、送信プロトコルの制御下における信号を送信および／または受信することができず、
    前記方法は、前記ユーザ端末によって行われる以下のステップ、すなわち、
    前記送信プロトコルによってトリガされたデータパケットの再送信が、前記送信プロトコルの動作が前記サイドリンクディスカバリギャップの１つと衝突したために行われなかったかどうかを判定するステップと、
    衝突がある場合、前記データパケットの前記衝突する再送信が前記送信プロトコルの前記データパケットの前記送信カウンタをインクリメントしないように前記送信カウンタを動作させるステップと、を含む、
    方法。
  15. 前記送信プロトコルは、再送信が前記送信プロトコルによってトリガされる場合に前記送信プロトコルの前記送信カウンタを１インクリメントするステップを規定しており、
    前記データパケットの前記衝突する再送信が前記データパケットの前記送信カウンタをインクリメントしないように前記送信プロトコルを動作させる前記ステップでは、
    衝突がある場合、再送信が前記送信プロトコルによってトリガされる場合に前記送信カウンタを１インクリメントする前記ステップを行わない、または、
    衝突がある場合、再送信が前記送信プロトコルによってトリガされる場合に前記送信プロトコルの前記送信カウンタを１インクリメントする前記ステップを行い、かつ、次いで前記送信カウンタを１減少させるステップを行う、
    請求項１４に記載の方法。
  16. 前記ユーザ端末は、前記ユーザ端末がチャネル測定を行うことができる少なくとも１つの測定用ギャップを有するように設定されており、
    前記ユーザ端末は、前記測定用ギャップの間、前記送信プロトコルの制御下における信号を送信および／または受信することができず、
    前記方法は、前記送信プロトコルの動作が前記測定用ギャップと衝突したために、前記送信プロトコルによってトリガされた再送信が行われなかった場合に、前記送信プロトコルの前記データパケットの前記送信カウンタを１インクリメントするステップをさらに含む、
    請求項１４または１５に記載の方法。
  17. 通信システムにおけるユーザ端末からのアップリンクデータパケット送信を受信する基地局であって、
    前記ユーザ端末は、前記アップリンクデータパケット送信のための送信プロトコルを実行し、
    前記ユーザ端末が行ったデータパケット送信の回数を数える送信カウンタが前記ユーザ端末の前記送信プロトコルのために設定されており、
    前記ユーザ端末が行ったデータパケット送信の回数を数える第２の送信カウンタが前記基地局に設定されており、
    第１の送信カウンタパラメータが、前記第１のおよび第２の送信カウンタの動作のための前記データパケットの許容可能最大送信回数を設定しており、
    前記ユーザ端末は、サイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリ動作に参加するように前記基地局によって設定されており、
    前記ユーザ端末は、前記サイドリンクディスカバリギャップの間にサイドリンクディスカバリ動作に参加している場合、前記送信プロトコルの制御下における信号を送信および／または受信することができず、
    前記基地局は、
    前記ユーザ端末においてデータパケットの再送信が前記送信プロトコルによってトリガされる場合に、該データパケットの前記第２の送信カウンタをインクリメントするプロセッサであって、
    前記ユーザ端末の前記送信プロトコルによってトリガされたデータパケットの再送信が、前記送信プロトコルの動作が前記サイドリンクディスカバリギャップの１つと衝突したために前記ユーザ端末によって行われなかったかどうかを判定するプロセッサを備え、
    衝突がある場合、前記プロセッサは、さらに、前記データパケットの前記２の送信カウンタの動作のために第２の送信カウンタパラメータを使用することによって前記第２の送信カウンタのために前記データパケットの許容可能最大送信回数を増加する、
    基地局。
  18. ユーザ端末において、通信システムにおけるアップリンクデータパケット送信のための送信プロトコルを実行する方法であって、
    前記ユーザ端末が行ったデータパケット送信の回数を数える送信カウンタが前記ユーザ端末の前記送信プロトコルのために設定されており、
    前記ユーザ端末は、前記送信カウンタの動作のためのデータパケットの許容可能最大送信回数を設定する第１の送信カウンタパラメータを有するように設定されており、
    前記ユーザ端末は、前記ユーザ端末のために設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリ動作に参加するように設定されており、前記ユーザ端末は、前記サイドリンクディスカバリギャップの間にサイドリンクディスカバリ動作に参加している場合、送信プロトコルの制御下における信号を送信および／または受信することができず、
    前記方法は、前記ユーザ端末によって行われる以下のステップ、すなわち、
    データパケットの再送信が前記送信プロトコルによってトリガされる場合に、該データパケットの前記送信カウンタをインクリメントするステップと、
    前記データパケットの前記トリガされた再送信が、前記送信プロトコルの動作が前記サイドリンクディスカバリギャップの１つと衝突したために行われなかったかどうかを判定するステップと、
    衝突がある場合、前記データパケットの前記送信カウンタの動作のために第２の送信カウンタパラメータを使用することによって前記送信カウンタの前記データパケットの許容可能最大送信回数を増加するステップと、を含む、
    方法。
  19. 前記ユーザ端末は、基地局によって、前記送信プロトコルの動作が前記サイドリンクディスカバリギャップの１つと衝突したために行われなかったデータパケットの再送信のトリガリングによってインクリメントされた送信カウンタに適用可能な前記第２の送信カウンタパラメータを有するように設定され、
    前記第２の送信カウンタパラメータは、前記第１の送信カウンタパラメータによって示されるデータパケットの許容可能最大送信回数より大きいデータパケットの許容可能最大送信回数を示し、
    この増加は、前記サイドリンクディスカバリギャップの長さに依存する、
    請求項１８に記載の方法。
  20. 前記第２の送信カウンタパラメータは、前記プロセッサが衝突を判定するたびに前記第１の送信カウンタパラメータを前記ユーザ端末がインクリメントするステップを行うことによって生成される、
    請求項１８に記載の方法。
JP2018541403A 2016-02-15 2017-01-27 サイドリンクディスカバリオペレーションに参加するＰｒｏＳｅ対応ＵＥのための改良されたアップリンクＨＡＲＱ動作 Active JP6840764B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP16155699.8A EP3206321B1 (en) 2016-02-15 2016-02-15 Improved uplink harq operation for prose-enabled ues participating in sidelink discovery operation
EP16155699.8 2016-02-15
PCT/EP2017/051833 WO2017140475A1 (en) 2016-02-15 2017-01-27 Improved uplink harq operation for prose-enabled ues participating in sidelink discovery operation

Publications (2)

Publication Number Publication Date
JP2019511158A true JP2019511158A (ja) 2019-04-18
JP6840764B2 JP6840764B2 (ja) 2021-03-10

Family

ID=55411208

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018541403A Active JP6840764B2 (ja) 2016-02-15 2017-01-27 サイドリンクディスカバリオペレーションに参加するＰｒｏＳｅ対応ＵＥのための改良されたアップリンクＨＡＲＱ動作

Country Status (4)

Country Link
US (1) US10667119B2 (ja)
EP (1) EP3206321B1 (ja)
JP (1) JP6840764B2 (ja)
WO (1) WO2017140475A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2021065014A1 (ja) * 2019-10-04 2021-04-08
WO2022080309A1 (ja) * 2020-10-13 2022-04-21 三菱電機株式会社 通信システム

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017193376A1 (en) * 2016-05-13 2017-11-16 Panasonic Intellectual Property Corporation Of America Short latency fast retransmission triggering
WO2018171242A1 (en) * 2017-03-23 2018-09-27 Huawei Technologies Co., Ltd. Configuration, indication and ack/nack for multiple harq grant-free transmission
WO2018174764A1 (en) * 2017-03-24 2018-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Apparatus and method for transmitting packet data units
WO2019031808A1 (en) * 2017-08-07 2019-02-14 Lg Electronics Inc. METHOD FOR TRANSMITTING AND RECEIVING SIGNALS IN A WIRELESS COMMUNICATION SYSTEM AND DEVICE THEREOF
WO2019064161A1 (en) * 2017-09-28 2019-04-04 Nokia Technologies Oy FLEXIBLE FRAME STRUCTURE FOR SUPPORTING QUICK CONTROL INFORMATION DISTRIBUTION
US11277229B2 (en) 2017-09-29 2022-03-15 Lg Electronics Inc. Method and apparatus for flushing HARQ buffer in wireless communication system
EP3484188B1 (en) * 2017-11-13 2022-09-21 Robert Bosch GmbH Road-side network node, method to operate the road-side node, network infrastructure node, method to operate the network infrastructure node, and network setup
CN110022608B (zh) * 2018-01-09 2021-05-28 电信科学技术研究院 一种信息处理方法、装置及设备
WO2019153125A1 (zh) * 2018-02-06 2019-08-15 Oppo广东移动通信有限公司 一种数据传输的方法、设备及计算机存储介质
US20190364424A1 (en) * 2018-05-28 2019-11-28 Qualcomm Incorporated Roll-over of identifiers and keys for unicast vehicle to vehicle communication links
CN110582067B (zh) * 2018-06-08 2022-04-05 华为技术有限公司 一种应答信息的发送和接收方法、通信设备及网络设备
US20200037343A1 (en) * 2018-07-24 2020-01-30 Samsung Electronics Co., Ltd. Method and apparatus for network controlled resource allocation in nr v2x
CN110831224B (zh) 2018-08-07 2021-10-01 维沃移动通信有限公司 一种随机接入方法及终端设备
KR20210035901A (ko) * 2018-08-09 2021-04-01 프라운호퍼-게젤샤프트 추르 푀르데룽 데어 안제반텐 포르슝 에 파우 Urllc 서비스를 위한 낮은 레이턴시 harq 프로토콜
CN112640346A (zh) * 2018-08-09 2021-04-09 康维达无线有限责任公司 用于5g ev2x的侧链路上的广播、多播和单播
CN110912653B (zh) * 2018-09-18 2021-07-16 华为技术有限公司 传输数据的方法和装置
CN110971355B (zh) * 2018-09-28 2021-10-22 华为技术有限公司 上行免动态授权传输的配置方法及通信装置
WO2020085854A1 (ko) * 2018-10-25 2020-04-30 엘지전자 주식회사 무선 통신 시스템에서 사이드링크 harq 피드백과 관련된 정보에 기반하여 자원선택 윈도우를 결정하는 방법 및 장치
KR102234055B1 (ko) * 2018-11-09 2021-03-31 아서스테크 컴퓨터 인코포레이션 무선 통신 시스템에서 사이드링크 통신을 위한 연결을 개선하는 방법 및 장치
US11646822B2 (en) 2018-12-11 2023-05-09 Apple Inc. Groupcast transmission with feedback for intra-platooning and inter-platooning communications
US11539475B2 (en) * 2019-01-04 2022-12-27 Kt Corporation Method and apparatus for transmitting sidelink HARQ feedback information
US11395313B2 (en) * 2019-01-10 2022-07-19 Qualcomm Incorporated Handling packets with different priorities in sidelink systems
CN111526488B (zh) * 2019-02-03 2021-10-15 华为技术有限公司 发送、接收控制信息的方法及装置
EP3942724B1 (en) * 2019-03-22 2023-09-27 Lenovo (Singapore) Pte. Ltd. Harq process for sidelink transmission
US10887056B2 (en) * 2019-05-03 2021-01-05 At&T Intellectual Property I, L.P. Highly reliable hybrid automatic repeat request technologies for new radio sidelink
WO2020223846A1 (en) * 2019-05-05 2020-11-12 Lenovo (Beijing) Limited Sidelink data packet acknowledgment
US20220248387A1 (en) * 2019-06-04 2022-08-04 Lg Electronics Inc. Ue operating method related to transmission and reception of sci in wireless communication system
WO2020246801A1 (ko) * 2019-06-04 2020-12-10 엘지전자 주식회사 무선통신시스템에서 사이드링크 유니캐스트 데이터 수신에 관련된 ue의 동작 방법
US20200396023A1 (en) * 2019-06-14 2020-12-17 Qualcomm Incorporated Downlink decoding feedback for hybrid automatic repeat request-less transmission modes
CN114222271A (zh) * 2019-06-17 2022-03-22 腾讯科技（深圳）有限公司 用于车辆通信的副链路监测方法、装置、介质及电子设备
CN110351029B (zh) * 2019-07-16 2021-11-02 中磊电子（苏州）有限公司 基站及其自动重传调度方法
CN112399475B (zh) * 2019-08-14 2022-11-22 中国移动通信有限公司研究院 Harq码本的确定方法及终端
CN112399588A (zh) * 2019-08-16 2021-02-23 华为技术有限公司 用于传输混合自动重传请求harq反馈信息的方法和装置
CN112398591B (zh) * 2019-08-16 2022-06-10 华为技术有限公司 一种确定侧行链路资源的方法、装置以及系统
US11122554B2 (en) * 2019-08-19 2021-09-14 Lenovo (Singapore) Pte. Ltd. Using a configured feedback resource for feedback
CN114402555B (zh) * 2019-09-30 2024-06-18 华为技术有限公司 一种harq信息指示方法、通信装置及通信系统
KR20220054643A (ko) * 2019-10-03 2022-05-03 엘지전자 주식회사 무선 통신 시스템에서 재전송을 수행하기 위한 방법 및 장치
WO2021071330A1 (ko) * 2019-10-10 2021-04-15 엘지전자 주식회사 Nr v2x에서 harq 피드백 정보를 기지국에게 보고하는 방법 및 장치
US11711683B2 (en) * 2019-10-29 2023-07-25 Qualcomm Incorporated Sidelink discovery procedure
US11652582B2 (en) * 2019-11-04 2023-05-16 Qualcomm Incorporated Acknowledgment feedback techniques in sidelink wireless communications
WO2021092923A1 (zh) * 2019-11-15 2021-05-20 Oppo广东移动通信有限公司 无线通信方法、终端设备和网络设备
ES2945882T3 (es) * 2019-12-03 2023-07-10 Asustek Comp Inc Método y aparato para generar HARQ-ACK de enlace lateral de dispositivo a dispositivo en un sistema de comunicación inalámbrica
US11678392B2 (en) * 2020-03-21 2023-06-13 Qualcomm Incorporated Sidelink communication recovery
US11677453B2 (en) * 2020-03-31 2023-06-13 Qualcomm Incorporated Enabling group leader- or base station-based sidelink transmit power control and radio link management
KR102582091B1 (ko) * 2020-04-09 2023-09-25 엘지전자 주식회사 Nr v2x에서 모드 1 sl 통신을 수행하는 방법 및 장치
EP4136787A1 (en) * 2020-04-14 2023-02-22 IDAC Holdings, Inc. Methods and apparatuses for improved voice coverage
WO2021230644A1 (en) * 2020-05-12 2021-11-18 Lg Electronics Inc. Periodic transmissions for configured grant
US11943825B2 (en) * 2020-07-09 2024-03-26 Qualcomm Incorporated Feedback-based broadcasting of network coded packets with sidelink
US11316648B2 (en) * 2020-07-24 2022-04-26 Wipro Limited Method and system for data packet transmission in downlink
CN115836539A (zh) * 2020-08-14 2023-03-21 华为技术有限公司 通信方法、装置及系统
WO2022086398A1 (en) * 2020-10-22 2022-04-28 Telefonaktiebolaget Lm Ericsson (Publ) User equipment, radio network node and methods performed in a wireless communication network
US11785441B2 (en) * 2021-05-27 2023-10-10 Qualcomm Incorporated Signaling of sidelink beam training reference signal and sidelink discovery message before beam training response
KR20230093576A (ko) * 2021-12-20 2023-06-27 삼성전자주식회사 무선 통신 시스템에서 사이드링크로 연결된 원격단말의 경로 변경을 지원하는 방법 및 장치

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3683576B2 (ja) * 2003-05-21 2005-08-17 シャープ株式会社 無線通信装置、無線通信システム、ワイヤレスａｖシステム、無線伝送方法並びに動作制御プログラム及びそのプログラムを記録した記録媒体
US20070047437A1 (en) * 2005-08-24 2007-03-01 Rainer Bachl Method and apparatus for controlling retransmissions in a wireless communications system
WO2012106843A1 (en) * 2011-02-11 2012-08-16 Renesas Mobile Corporation Signaling method to enable controlled tx deferring in mixed licensed and unlicensed spectrum carrier aggregation in future lte-a networks
GB2506363A (en) * 2012-09-26 2014-04-02 Broadcom Corp Method for controlling automatic repeat request (arq) retransmissions of wireless signals
US9838158B2 (en) * 2013-07-17 2017-12-05 Lg Electronics Inc. Method for reporting a radio link control re-transmission failure and a device therefor
CN104767556B (zh) 2014-01-06 2019-07-23 中兴通讯股份有限公司 一种基于部分干扰对齐的协调波束赋形方法及装置
EP3094031A4 (en) * 2014-01-28 2017-01-11 Huawei Technologies Co., Ltd. User equipment, base station and uplink data scheduling method
EP3270615A4 (en) * 2015-04-10 2019-03-06 Kyocera Corporation WIRELESS TERMINAL AND BASE STATION
JP6829208B2 (ja) * 2015-11-06 2021-02-10 京セラ株式会社 無線端末及び基地局
ES2886752T3 (es) * 2016-02-05 2021-12-20 Asustek Comp Inc Procedimiento y aparato para la reducción de latencia de mensajes de dispositivo a dispositivo (D2D) en un sistema de comunicación inalámbrica

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2021065014A1 (ja) * 2019-10-04 2021-04-08
WO2021065014A1 (ja) * 2019-10-04 2021-04-08 株式会社Ｎｔｔドコモ 端末及び通信方法
JP7420824B2 (ja) 2019-10-04 2024-01-23 株式会社Ｎｔｔドコモ 端末、端末により実行される方法及びシステム
WO2022080309A1 (ja) * 2020-10-13 2022-04-21 三菱電機株式会社 通信システム

Also Published As

Publication number Publication date
EP3206321B1 (en) 2020-07-08
US10667119B2 (en) 2020-05-26
JP6840764B2 (ja) 2021-03-10
WO2017140475A1 (en) 2017-08-24
US20190058986A1 (en) 2019-02-21
EP3206321A1 (en) 2017-08-16

Similar Documents

Publication Publication Date Title
JP6840764B2 (ja) サイドリンクディスカバリオペレーションに参加するＰｒｏＳｅ対応ＵＥのための改良されたアップリンクＨＡＲＱ動作
JP6749388B2 (ja) アップリンク送信インジケーション
JP7076428B2 (ja) Ｖ２ｘ送信用データの改良された初期および再送信
JP6628165B2 (ja) 送信側ユーザ機器および方法
JP5793695B2 (ja) 移動通信における改良されたランダムアクセス手順
JP6590942B2 (ja) サイドリンク制御期間中の複数のＰｒｏＳｅグループ通信
US10433333B2 (en) Method for configuring uplink grants over multiple subframes in a wireless communication system and a device therefor
JP6330033B2 (ja) 二重接続における移動局の通信リンクのアップリンク切替え
JP6752209B2 (ja) ６つ以上のキャリアのキャリアアグリゲーションの場合の改良されたｈａｒｑフィードバックメカニズム
KR20210126510A (ko) 무선 통신 시스템의 네트워크 스케줄링 모드에서 사이드링크 harq(hybrid automatic repeat request)에 대한 시간 간격을 처리하는 방법 및 장치
EP3259866B1 (en) Telecommunication devices and methods
JP6644912B2 (ja) 短レイテンシ高速再送信トリガ
JP2019508931A (ja) ＰｒｏＳｅ通信における自律的なリソース割当ての場合に優先順位に基づいて最適化されるサイドリンクデータ伝送
JP7385044B2 (ja) Ｎｒにおけるマルチキャストのためのハイブリッド自動再送要求（ｈａｒｑ）機構
US10903944B2 (en) Method for determining result of transmission for contention-based PUSCH in a wireless communication system and a device therefor
JP7254064B2 (ja) 無線通信システムにおいてアンカー搬送波に基づいて資源を割り当てるための方法及び装置
JP2018522452A (ja) 自己およびクロスキャリアスケジューリング
JP2018526895A (ja) 部分サブフレームに対する変調次数の適合化
JP2017539123A (ja) アンライセンスキャリアで送信するための改良されたリソース割当て
TW201521487A (zh) 裝置對裝置通訊分散排程
CN116032435A (zh) 用于发送数据单元的通信设备、处理设备及方法
CN114651406B (zh) 多个活动授权配置中的定时器处理
US20180115985A1 (en) Method for transmitting a contention-based pusch in a wireless communication system and a device therefor
JP6899460B2 (ja) 短レイテンシ高速再送信トリガ
JP2020025362A (ja) サイドリンク制御期間における複数のサイドリンク制御送信

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20190823

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20190829

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190905

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200909

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200929

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201204

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210119

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210217

R150 Certificate of patent or registration of utility model

Ref document number: 6840764

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150