[LTE(Long Term Evolution)]
WCDMA(登録商標)無線アクセス技術をベースとする第3世代移動通信システム(3G)は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展・進化させるうえでの最初のステップとして、高速ダウンリンクパケットアクセス(HSDPA:High-Speed Downlink Packet Access)と、エンハンストアップリンク(高速アップリンクパケットアクセス(HSUPA:High-Speed Uplink Packet Access)とも称する)とが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。
ユーザからのますます増大する需要に対応し、新しい無線アクセス技術に対する競争力を確保する目的で、3GPPは、LTEと称される新しい移動通信システムを導入した。LTEは、今後10年間にわたり、データおよびメディアの高速伝送ならびに大容量の音声サポートに要求されるキャリアを提供するように設計されている。高いビットレートを提供する能力は、LTEにおける重要な方策である。
LTEに関する作業項目(WI:working item)の仕様は、E−UTRA(Evolved UMTS Terrestrial Radio Access)およびE−UTRAN(Evolved UMTS Terrestrial Radio Access Network)と称され、最終的にリリース8(LTEリリース8)として公開される。LTEシステムは、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークであり、IPベースの全機能を低遅延かつ低コストで提供する。LTEでは、与えられたスペクトルを用いてフレキシブルなシステム配備を達成するために、スケーラブルな複数の送信帯域幅(例えば、1.4MHz、3.0MHz、5.0MHz、10.0MHz、15.0MHz、および20.0MHz)が指定されている。ダウンリンクには、OFDM(Orthogonal Frequency Division Multiplexing:直交周波数分割多重)をベースとする無線アクセスが採用されている。かかる無線アクセスを採用する理由は、この無線アクセスが低いシンボルレートのため本質的にマルチパス干渉(MPI:Multipath Interference)を受けにくいこと、サイクリックプレフィックス(CP:Cyclic Prefix)が使用されていること、および、さまざまな送信帯域幅の構成に対応可能なことである。アップリンクには、SC−FDMA(Single-Carrier Frequency Division Multiple Access:シングルキャリア周波数分割多元接続)をベースとする無線アクセスが採用されている。ユーザ機器(UE)の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるからである。LTEリリース8/9では、数多くの主要なパケット無線アクセス技術(例えば、MIMO(Multiple-Input Multiple-Output)チャネル伝送技術)が採用され、高効率の制御シグナリング構造が達成されている。
[LTEのアーキテクチャ]
LTEの全体的なアーキテクチャは、図1に示してある。E−UTRANは、eNodeBから構成され、eNodeBは、ユーザ機器(UE:User Equipment)向けの、E−UTRAのユーザプレーン(PDCP/RLC/MAC/PHY)および制御プレーン(RRC)のプロトコルを終端させる。eNodeB(eNB)は、物理(PHY)レイヤ、媒体アクセス制御(MAC:Medium Access Control)レイヤ、無線リンク制御(RLC:Radio Link Control)レイヤ、およびパケットデータ制御プロトコル(PDCP:Packet Data Control Protocol)レイヤ(これらのレイヤはユーザプレーンのヘッダ圧縮および暗号化の機能を含む)をホストする。eNBは、制御プレーンに対応する無線リソース制御(RRC:Radio Resource Control)機能も提供する。eNBは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクサービス品質(QoS:Quality of Service)の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化/復号、ダウンリンク/アップリンクのユーザプレーンパケットヘッダの圧縮/復元など、多くの機能を実行する。複数のeNodeBは、X2インタフェースによって互いに接続されている。
また、複数のeNodeBは、S1インタフェースによってEPC(Evolved Packet Core)、より具体的には、S1−MMEによってMME(Mobility Management Entity:モビリティ管理エンティティ)、S1−Uによってサービングゲートウェイ(SGW:Serving Gateway)に接続されている。S1インタフェースは、MME/サービングゲートウェイとeNodeBとの間の多対多関係をサポートする。SGWは、ユーザデータパケットをルーティングして転送する一方で、eNodeB間のハンドオーバー時におけるユーザプレーンのモビリティアンカーとして機能し、さらに、LTEと他の3GPP技術との間のモビリティのためのアンカー(S4インタフェースを終端させ、2G/3GシステムとPDN GWとの間でトラフィックを中継する)として機能する。SGWは、アイドル状態のユーザ機器に対しては、ダウンリンクデータ経路を終端させ、そのユーザ機器へのダウンリンクデータが到着したときにページングをトリガする。SGWは、ユーザ機器のコンテキスト(例えばIPベアラサービスのパラメータ、ネットワーク内部ルーティング情報)を管理および格納する。さらに、SGWは、合法的傍受の場合にユーザトラフィックの複製を実行する。
MMEは、LTEのアクセスネットワークの主要な制御ノードである。MMEは、アイドルモードのユーザ機器の追跡およびページング手順(再送信を含む)の役割を担う。MMEは、ベアラのアクティブ化/非アクティブ化プロセスに関与し、さらには、最初のアタッチ時と、コアネットワーク(CN:Core Network)ノードの再配置を伴うLTE内ハンドオーバー時とに、ユーザ機器のSGWを選択する役割も担う。MMEは、(HSSと対話することによって)ユーザを認証する役割を担う。非アクセス層(NAS:Non-Access Stratum)シグナリングはMMEにおいて終端され、MMEは、一時的なIDを生成してユーザ機器に割り当てる役割も担う。MMEは、サービスプロバイダの公衆陸上移動網(PLMN:Public Land Mobile Network)に入るためのユーザ機器の認証をチェックし、ユーザ機器のローミング制約を実施する。MMEは、NASシグナリングの暗号化/完全性保護においてネットワーク内の終端点であり、セキュリティキーの管理を行う。シグナリングの合法的傍受も、MMEによってサポートされる。さらに、MMEは、LTEのアクセスネットワークと2G/3Gのアクセスネットワークとの間のモビリティのための制御プレーン機能を提供し、SGSNからのS3インタフェースを終端させる。さらに、MMEは、ローミングするユーザ機器のためのホームHSSに向かうS6aインタフェースを終端させる。
[LTEにおけるコンポーネントキャリアの構造]
3GPP LTEシステムのダウンリンクコンポーネントキャリアは、いわゆるサブフレームにおける時間−周波数領域でさらに分割される。3GPP LTEでは、各サブフレームは、図2に示すように2つのダウンリンクスロットに分割されており、第1のダウンリンクスロットが、第1のOFDMシンボル内に制御チャネル領域(PDCCH領域)を含んでいる。各サブフレームは、時間領域における所定の数のOFDMシンボルから構成され(3GPP LTE(リリース8)では12個または14個のOFDMシンボル)、各OFDMシンボルはコンポーネントキャリアの帯域幅全体に広がる。したがって、OFDMシンボルそれぞれは、それぞれのサブキャリアで送信される複数の変調シンボルから構成される。LTEでは、各スロットにおける送信信号は、NDL RB×NRB sc本のサブキャリアとNDL symb個のOFDMシンボルのリソースグリッドによって記述される。NDL RBは、帯域幅の中のリソースブロックの数である。数NDL RBは、セルにおいて設定されているダウンリンク送信帯域幅に依存し、Nmin,DL RB≦NDL RB≦Nmax,DL RBを満たし、この場合、Nmin,DL RB=6およびNmax,DL RB=110は、それぞれ、現在のバージョンの仕様によってサポートされている最小ダウンリンク帯域幅および最大ダウンリンク帯域幅である。NRB scは、1個のリソースブロックの中のサブキャリアの数である。通常のサイクリックプレフィックスのサブフレーム構造の場合、NRB sc=12、NDL symb=7である。
例えば3GPP LTEにおいて使用されるような(例えば、OFDMを使用する)マルチキャリア通信システムを想定すると、スケジューラによって割り当てることができるリソースの最小単位は、1つの「リソースブロック」である。物理リソースブロック(PRB:Physical Resource Block)は、図2に例示したように、時間領域における連続するOFDMシンボル(例えば7個のOFDMシンボル)および周波数領域における連続するサブキャリア(例えばコンポーネントキャリアの12本のサブキャリア)として定義される。したがって、3GPP LTE(リリース8)では、物理リソースブロックはリソースエレメントから構成され、時間領域における1つのスロットおよび周波数領域における180kHzに対応する(ダウンリンクリソースグリッドに関するさらなる詳細は、例えば、参照により本明細書に非特許文献1(現在のバージョン13.0.0)の6.2節(3GPPのウェブサイト(http://www.3gpp.org)で入手可能)を参照)。
1つのサブフレームが2つのスロットで構成されているため、いわゆる「通常の」サイクリックプレフィックス(normal CP)が使用されるときにはサブフレーム内に14個のOFDMシンボルが存在し、いわゆる「拡張」サイクリックプレフィックス(extended CP)が使用されるときにはサブフレーム内に12個のOFDMシンボルが存在する。専門用語のために、以下で、サブフレーム全体に広がる同一の連続するサブキャリアと同等の時間−周波数リソースは、「リソースブロックペア」または同意義の「RBペア」もしくは「PRBペア」と呼ばれる。
「コンポーネントキャリア(Component Carrier)」という用語は、周波数領域におけるいくつかのリソースブロックの組合せを示す。LTEの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、その代わりに、この専門用語はダウンリンクおよびオプションでアップリンクリソースの組合せを示す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンク付けは、ダウンリンクリソースで送信されるシステム情報において指示される。
コンポーネントキャリアの構造に関する同様の想定が以降のリリースにも適用される。
[より広い帯域幅のサポートのためのLTE−Aにおけるキャリアアグリゲーション]
世界無線通信会議2007(WRC−07)において、IMT−Advancedの周波数スペクトルが決定された。IMT−Advancedのための全体的な周波数スペクトルは決定されたが、実際に利用可能な周波数帯域幅は、地域や国によって異なる。しかしながら、利用可能な周波数スペクトルのアウトラインの決定に続いて、3GPPにおいて無線インタフェースの標準化が開始された。3GPP TSG RAN #39会合において、「Further Advancements for E-UTRA (LTE-Advanced)」に関する検討項目(Study Item)の記述が承認された。この検討項目は、E−UTRAを進化・発展させるうえで(例えば、IMT−Advancedの要求条件を満たすために)考慮すべき技術要素をカバーしている。
LTEアドバンストシステムがサポートすることができる帯域幅は100MHzであり、一方、LTEシステムは20MHzのみをサポートすることができる。今日、無線スペクトルの不足がワイヤレスネットワークの開発のボトルネックになっている。結果として、LTE−Advancedシステムのために十分広いスペクトル帯域を見つけることが困難である。したがって、より広い無線スペクトル帯域を獲得するための方法を見つけることが急務であり、キャリアアグリゲーション機能が解決策であり得る。
キャリアアグリゲーションでは、最大で100MHzのより広い送信帯域幅をサポートする目的で、2つ以上のコンポーネントキャリアがアグリゲートされる。LTE−Advancedシステムでは、LTEシステムにおけるいくつかのセルが、より広い1つのチャネルにアグリゲートされ、このチャネルは、たとえLTEにおけるこれらのセルが異なる周波数帯域にある場合でも100MHzに対して十分に広い。
少なくともコンポーネントキャリアの帯域幅がLTEリリース8/9のセルのサポートされる帯域幅を超えないときには、すべてのコンポーネントキャリアをLTEリリース8/9互換であるように設定することができる。ユーザ機器によってアグリゲートされるすべてのコンポーネントキャリアが必ずしもLTEリリース8/9互換でなくてよい。リリース8/9のユーザ機器がコンポーネントキャリアにキャンプオンすることを回避するため、既存のメカニズム(例:バーリング(barring))を使用することができる。
ユーザ機器は、自身の能力に応じて1つまたは複数のコンポーネントキャリア(複数のサービングセルに対応する)を同時に受信または送信することができる。キャリアアグリゲーションのための受信能力および/または送信能力を備えた、LTE−Aリリース10のユーザ機器は、複数のサービングセル上で同時に受信および/または送信することができる。これに対して、LTEリリース8/9のユーザ機器は、コンポーネントキャリアの構造がリリース8/9の仕様に従う場合、1つのみのサービングセル上で受信および送信を行うことができる。
キャリアアグリゲーションは、連続するコンポーネントキャリアおよび不連続なコンポーネントキャリアの両方においてサポートされ、各コンポーネントキャリアは、(3GPP LTE(リリース8/9)の計算方式(numerology)を使用して)周波数領域における最大110個のリソースブロックに制限される。
同一のeNodeB(基地局)から送信される、場合によってはアップリンクおよびダウンリンクにおいて異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように、3GPP LTE−A(リリース10)互換のユーザ機器を構成することが可能である。設定することのできるダウンリンクコンポーネントキャリアの数は、ユーザ機器のダウンリンクのアグリゲーション能力に依存する。逆に、設定することのできるアップリンクコンポーネントキャリアの数は、ユーザ機器のアップリンクのアグリゲーション能力に依存する。現時点では、移動端末にダウンリンクコンポーネントキャリアよりもアップリンクコンポーネントキャリアを多く設定することはできない。一般的なTDD配備では、コンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は、アップリンクとダウンリンクとで同一である。同一のeNodeBから送信されるコンポーネントキャリアは、同一のカバレッジを提供する必要はない。
連続的にアグリゲートされるコンポーネントキャリアの中心周波数の間隔は、300kHzの倍数である。これは、3GPP LTE(リリース8/9)の100kHzの周波数ラスターとの互換性を保つと同時に、15kHz間隔のサブキャリアの直交性を維持するためである。アグリゲーションのシナリオによっては、連続するコンポーネントキャリアの間に少数の使用されないサブキャリアを挿入することによって、n×300kHzの間隔あけを容易にすることができる。
複数のキャリアをアグリゲートする影響は、MACレイヤに及ぶのみである。MACレイヤには、アップリンクおよびダウンリンクの両方において、アグリゲートされるコンポーネントキャリアごとに1つのHARQエンティティが要求される。コンポーネントキャリアあたりのトランスポートブロックは最大1個である(アップリンクにおけるSU−MIMOを使用しない場合)。トランスポートブロックおよびそのHARQ再送信(発生時)は、同一のコンポーネントキャリアにマッピングする必要がある。
キャリアアグリゲーションが設定されているとき、移動端末はネットワークとの1つのRRC接続のみを有する。RRC接続の確立/再確立時、1つのセルが、LTEリリース8/9と同様に、セキュリティ入力(1つのECGI、1つのPCI、および1つのARFCN)と、非アクセス層(NAS)モビリティ情報(例:TAI)とを提供する。RRC接続の確立/再確立の後、そのセルに対応するコンポーネントキャリアは、ダウンリンクプライマリセル(PCell)と称される。接続状態では、ユーザ機器あたりつねに1つのダウンリンクPCell(DL PCell)および1つのアップリンクPCell(UL PCell)が設定される。コンポーネントキャリアの設定されたセットおいて、他のセルはセカンダリセル(SCell)と呼ばれ、SCellのキャリアはダウンリンクセカンダリコンポーネントキャリア(DL SCC)およびアップリンクセカンダリコンポーネントキャリア(UL SCC)である。1基のUEに対して、最大5つのサービングセル(PCellを含む)を設定することができる。
[MACレイヤ/MACエンティティ、RRCレイヤ、物理レイヤ]
LTEのL2レイヤのユーザプレーン/制御プレーンのプロトコルスタックは、4つのサブレイヤ、すなわちRRC、PDCP、RLC、およびMACを備えている。媒体アクセス制御(MAC)レイヤは、LTEの無線プロトコルスタックのL2アーキテクチャにおける最も下のサブレイヤであり、例えば3GPP技術規格である非特許文献2(現在のバージョン13.0.0)によって定義されている。MACレイヤは、下の物理レイヤとはトランスポートチャネルを通じて接続されており、上のRLCレイヤとは論理チャネルを通じて接続されている。したがって、MACレイヤは、論理チャネルとトランスポートチャネルとの間の多重化および逆多重化を実行する。送信側におけるMACレイヤは、論理チャネルを通じて受け取るMAC SDUからMAC PDU(トランスポートブロックとしても知られている)を構築し、受信側におけるMACレイヤは、トランスポートチャネルを通じて受け取るMAC PDUからMAC SDUを復元する。
MACレイヤは、論理チャネルを通じてRLCレイヤにデータ伝送サービスを提供し(参照により本明細書に援用される非特許文献2の5.4節および5.3節を参照)、この論理チャネルは、制御データ(例えばRRCシグナリング)を伝える制御論理チャネル、またはユーザプレーンデータを伝えるトラフィック論理チャネルのいずれかである。その一方で、MACレイヤからのデータはトランスポートチャネル(ダウンリンクまたはアップリンクとして分類される)を通じて物理レイヤと交換される。無線を通じた送信方式に応じて、データがトランスポートチャネルに多重化される。
物理レイヤは、データおよび制御情報をエアインタフェースを介して実際に送信する役割を担い、すなわち物理レイヤは、送信側ではMACトランスポートチャネルからのすべての情報をエアインタフェースを通じて伝える。物理レイヤによって実行されるいくつかの重要な機能としては、符号化および変調、リンクアダプテーション(AMC)、電力制御、セルサーチ(最初の同期およびハンドオーバーを目的とする)、RRCレイヤのための他の測定(LTEシステムの内側およびシステム間)が挙げられる。物理レイヤは、送信パラメータ(変調方式、符号化率(すなわち変調・符号化方式(MCS:Modulation and Coding Scheme))、物理リソースブロックの数など)に基づいて、送信を実行する。物理レイヤの機能に関するさらなる情報は、参照により本明細書に援用される非特許文献3(現在のバージョン13.0.0)に記載されている。
無線リソース制御(RRC)レイヤは、無線インタフェースにおけるUEとeNBとの間の通信と、いくつかのセルを横切って移動するUEのモビリティを制御する。RRCプロトコルは、NAS(非アクセス層)情報の伝送もサポートする。RRC_IDLE状態にあるUEに対しては、RRCはネットワークからの着信呼の通知をサポートする。RRC接続制御は、RRC接続の確立、変更、および解除に関連するすべての手順(ページング、測定の設定および報告、無線リソースの設定、最初のセキュリティ起動、シグナリング無線ベアラ(SRB:Signalling Radio Bearer)およびユーザデータを伝える無線ベアラ(データ無線ベアラ(DRB:Data Radio Bearer))の確立を含む)をカバーする。
無線リンク制御(RLC)サブレイヤは主としてARQ機能を備え、データのセグメント化と連結をサポートする。すなわち、RLCレイヤは、RLC SDUのフレーム化を行い、MACレイヤによって示されたサイズに合わせる。RLCレイヤとMACレイヤは、データレートとは無関係にプロトコルオーバーヘッドを最小化する。RLCレイヤは、論理チャネルを介してMACレイヤに接続される。各論理チャネルは、様々な種類のトラフィックを伝送する。RLCレイヤの上位レイヤは、通常はPDCPレイヤであるが、RRCレイヤである場合がある。すなわち、論理チャネルであるブロードキャスト制御チャネル(BCCH:Broadcast Control Channel)、ページング制御チャネル(PCCH:Paging Control Channel)、および共通制御チャネル(CCCH:Common Control Channel)で送信されたRRCメッセージは、セキュリティ保護を要求しないため、PDCPレイヤを迂回して直接RLCレイヤに行く。RLCサブレイヤの主な役割および機能には、次のものが含まれる。
・ AMデータ転送、UMデータ転送、またはTMデータ転送をサポートする上位レイヤPDUの転送;
・ ARQによる誤り訂正;
・ TBのサイズに応じたセグメント化;
・ 必要に応じた再セグメント化(例えば、無線品質(すなわち、サポートされたTBサイズ)が変化する場合の再セグメント化);
・ 同一の無線ベアラのSDUの連結については、さらに検討を要する;
・ 上位レイヤPDUの順次送達;
・ 重複検出;
・ プロトコル誤りの検出およびリカバリ;
・ SDU破棄;
・ リセット
RLCレイヤによって提供されるARQ機能の詳細については、後に説明する。
[LTEにおけるアップリンクアクセス方式]
アップリンク送信では、カバレッジを最大にするため、ユーザ端末は高い電力効率で送信する必要がある。E−UTRAのアップリンク送信方式としては、シングルキャリア伝送と、動的な帯域幅割当てのFDMAとを組み合わせた方式が選択されている。シングルキャリア伝送が選択された主たる理由は、マルチキャリア信号(OFDMA)と比較して、ピーク対平均電力比(PAPR:Peak to Average Power Ratio)が低いこと、これに対応して電力増幅器の効率が改善されること、カバレッジも改善されること(与えられる端末ピーク電力に対してデータレートがより高いこと)である。各時間間隔において、eNodeBは、ユーザデータを送信するための固有の時間/周波数リソースをユーザに割り当て、これによってセル内の直交性が確保される。アップリンクにおける直交多元接続によって、セル内干渉が排除されることでスペクトル効率が高まる。マルチパス伝搬に起因する干渉については、送信信号にサイクリックプレフィックスを挿入することにより基地局(eNodeB)において対処する。
データを送信するために使用される基本的な物理リソースは、1つの時間間隔(例えばサブフレーム)にわたるサイズBWgrantの周波数リソースから構成される(符号化された情報ビットはこのリソースにマッピングされる)。なお、サブフレーム(送信時間間隔(TTI:Transmission Time Interval)とも称する)が、ユーザデータを送信するための最小の時間間隔である。しかしながら、サブフレームを連結することにより、1TTIより長い時間にわたる周波数リソースBWgrantをユーザに割り当てることができる。
[L1/L2制御シグナリング]
スケジューリングされたユーザに、ユーザの割当て状態、トランスポートフォーマット、およびその他の送信関連情報(例:HARQ情報、送信電力制御(TPC)コマンド)を知らせる目的で、L1/L2制御シグナリングがデータと一緒にダウンリンクで送信される。L1/L2制御シグナリングは、サブフレーム内にダウンリンクデータと一緒に多重化される(ユーザ割当てがサブフレーム単位で変化しうるものと想定する)。なお、ユーザ割当てをTTI(送信時間間隔)ベースで実行することもでき、その場合、TTI長をサブフレームの倍数とすることができることに留意されたい。TTI長を、サービスエリア内ですべてのユーザに対して一定としてもよいし、異なるユーザに対して異なる長さとしてもよいし、ユーザ毎に動的としてもよい。L1/L2制御シグナリングは、一般的にはTTIあたり1回のみ送信されればよい。以下では、一般性を失うことなく、TTIが1サブフレームに等しいものと想定する。
L1/L2制御シグナリングは、物理ダウンリンク制御チャネル(PDCCH:Physical Downlink Control CHannel)で送信される。PDCCHは、ダウンリンク制御情報(DCI:Downlink Control Information)としてメッセージを伝送し、DCIには、多くの場合、移動端末のための、またはUEのグループのためのリソース割当ておよびその他の制御情報が含まれる。いくつかのPDCCHを1つのサブフレーム内で送信することができる。
アップリンク無線リソースまたはダウンリンク無線リソースを割り当てる目的でL1/L2制御シグナリングで送られる情報は(特にLTE(−A)リリース10)、一般的には以下の項目に分類することができる。
− ユーザ識別情報: 割り当てる対象のユーザを示す。この情報は、一般には、CRCをユーザ識別情報によってマスクすることによってチェックサムに含まれる。
− リソース割当て情報: ユーザに割り当てられるリソース(例:リソースブロック(RB))を示す。あるいはこの情報はリソースブロック割当て(RBA:Resource Block Assignment)と称される。なお、ユーザに割り当てられるリソースブロック(RB)の数は動的とすることができる。
− キャリアインジケータ: 第1のキャリアで送信される制御チャネルが、第2のキャリアに関連するリソース(すなわち第2のキャリアのリソースまたは第2のキャリアに関係するリソース)を割り当てる場合に使用される(クロスキャリアスケジューリング)。
− 変調・符号化方式: 採用される変調方式および符号化率を決める。
− HARQ情報: 例えば、データパケットまたはその一部の再送信時に特に有用である、新規データインジケータ(NDI:New Data Indicator)や冗長バージョン(RV:Redundancy Version)。
− 電力制御コマンド: 割り当てられたアップリンクのデータまたは制御情報の送信時の送信電力を調整する。
− 参照信号情報: 例えば、割当てに関連する参照信号の送信または受信に使用される、適用されたサイクリックシフトや直交カバーコードインデックス。
− アップリンク割当てインデックスまたはダウンリンク割当てインデックス: 割当ての順序を識別するために使用され、TDDシステムにおいて特に有用である。
− ホッピング情報: 例えば、周波数ダイバーシチを増大させる目的でリソースホッピングを適用するか否か、および適用方法の指示情報。
− CSI要求: 割り当てられるリソースにおいてチャネル状態情報を送信するようにトリガするために使用される。
− マルチクラスタ情報: シングルクラスタ(RBの連続的なセット)またはマルチクラスタ(連続的なRBの少なくとも2つの不連続なセット)で送信を行うかを指示・制御するために使用されるフラグである。マルチクラスタ割当ては、3GPP LTE−(A)リリース10によって導入された。
なお、上記リストは、すべてを網羅したものではなく、また、使用されるDCIフォーマットによっては、リストアップした情報項目すべてを各PDCCH送信に含める必要はないことに留意されたい。
ダウンリンク制御情報は、全体のサイズ、または上述したフィールドに含まれる情報が異なるいくつかのフォーマットの形をとる。LTEにおいて現在定義されている様々なDCIフォーマットは、以下のとおりであり、参照により本明細書に援用される非特許文献4(現在のバージョン13.0.0)(3GPPのウェブサイト(http://www.3gpp.org)で入手可能)の5.3.3.1節「多重化およびコード符号化」(“Multiplexing and channel coding”)に詳しく記載されている。例えば、以下のDCIフォーマットを、アップリンク用のリソースグラントを伝送するために使用することができる。
− フォーマット0: DCIフォーマット0は、アップリンク送信モード1または2におけるシングルアンテナポート送信を使用したPUSCHのためのリソースグラントを送信するために使用される。
− フォーマット4: DCIフォーマット4は、アップリンク送信モード2における閉ループ空間多重化送信を使用したPUSCHのスケジューリングに使用される。
サイドリンクの制御情報については、3GPPの技術規格である、参照により本明細書に援用される非特許文献4(現在のバージョン13.0.0)の5.4.3節に定義がある。
[E−UTRAN測定・測定用ギャップ]
E−UTRANでは、UEを、測定情報を報告するように、例えば、UEのモビリティの制御をサポートするように設定することができる。RRCConnectionReconfigurationメッセージを介して、各測定用設定要素(measurement configuration element)をシグナリングすることができる。例えば、測定用ギャップは、アップリンク送信もダウンリンク送信もスケジューリングされないため、UEが測定を行ってもよい時間を定義する。測定用ギャップは、ギャップを利用した測定(gap-assisted measurements)の全てに共通である。周波数間測定には、UEの性能(例えば、UEが2つの受信部を有するかどうか)に応じて測定用ギャップの設定が必要な場合がある。UEは、サービングセルのキャリア周波数以外のキャリア周波数において動作するE−UTRAセルを識別する。UEが2つ以上の受信部を有しないのであれば、セルの識別を含む周波数間測定は、周期的な測定用ギャップにおいて行われる。それぞれが6msのありうる2つのギャップパターンを、ネットワークによって設定することができる。ギャップパターン#0では40msごとにギャップが存在し、ギャップパターン#1では80msごとにギャップが存在する。
例えば、参照信号受信電力(RSRP:Reference Signal Received Power)は、UEによって測定時間にわたる測定帯域幅内のセル固有参照信号の全てについて測定される。
[ARQ/ハイブリッドARQ(HARQ)の方式]
LTEにおいては、信頼性を提供するための2段階の再送信、すなわち、MACレイヤにおけるHARQおよびRLCレイヤにおける外部ARQ(outer ARQ)がある。RLC再送信メカニズムは、上位レイヤに誤り無くデータを渡す役割を担う。これを達成するために、(再)送信プロトコルは、受信機および送信機におけるRLCエンティティ間で、例えば、送達確認モード(acknowledged mode)で実行される。RLCレイヤがノイズや予測不能のチャネル変動等による送信誤りを処理することができる場合もあるが、この送信誤りは、多くの場合、MACレイヤのHARQ再送信プロトコルによって処理される。したがって、RLCレイヤにおける再送信メカニズムを使用することは、初めは余分に思われるかもしれない。しかしながら、これは余分にはならず、RLCに基づく再送信メカニズムおよびMACに基づく再送信メカニズムの両メカニズムを使用することは、実際はフィードバックシグナリングの相違によって十分に動機づけられている。例えば、RLC−ARQメカニズムは、MAC HARQメカニズムの場合に起こる可能性があるNACK−to−ACKエラーを処理する。
信頼性の低いチャネルでのパケット伝送システムにおける誤り検出訂正の共通の技術は、ハイブリッド自動再送要求(HARQ:Hybrid Automatic Repeat Request)と呼ばれる。ハイブリッドARQは、前方誤り訂正(FEC:Forward Error Correction)およびARQの組合せである。FEC符号化パケットが送信され、受信機がパケットを正確に復号できない場合(通常、エラーは、CRC(Cyclic Redundancy Check:巡回冗長検査)によって検査される)、受信機はパケットの再送信を要求する。
[RLC再送信プロトコル]
RLCが失われたPDUの再送信を要求するように設定される場合、RLCは送達確認モード(AM)で動作していると言われる。これは、WCDMA/HSPAにおいて使用される対応するメカニズムと同様である。
全体として、RLCのための3つの動作モード、すなわち、透過モード(TM:Transparent Mode)、非送達確認モード(UM:Unacknowledged Mode)、および送達確認モード(AM:Acknowledged Mode)がある。各RLCエンティティは、これらのモードの1つで動作するようにRRCによって設定される。
透過モードでは、上位レイヤから受信されたRLC SDUにプロトコルオーバーヘッドが付加されない。特殊なケースでは、限定的なセグメント化/再組立て性能の場合の送信を達成することができる。セグメント化/再組立てが使用されるかを、無線ベアラセットアップ手順において取り決めなければならない。透過モードは、例えば、スピーチのような遅延の影響を非常に受けやすいサービスに使用される。
非送達確認モードでは、再送信プロトコルが使用されていないため、データ送達は保証されない。PDUの構造には、上位レイヤにおいて完全であること観察するためのシーケンス番号が含まれる。RLCシーケンス番号に基づいて、受信側UM RLCエンティティは、受信されたRLC PDUの並べ替えを行うことができる。セグメント化と連結は、データに付加されたヘッダーフィールドによって提供される。非送達確認モードのRLCエンティティは、アップリンクとダウンリンクの間に定義された関連付けがないため一方向的である。誤ったデータが受信される場合、対応するPDUは、設定に応じて破棄されるかマークを付けられる。送信機では、タイマによって規定された一定時間内に送信されないRLC SDUは、送信バッファから破棄・除去される。上位レイヤから受信したRLC SDUは、送信機側でRLC PDUとしてセグメント化/連結される。受信機側では、再組立てが同様に行われる。非送達確認モードは、送達時間の短さと比較して送達に誤りが無いことの重要度が低いサービス(例えば、或るRRCシグナリング手順、MBMS等のセルブロードキャストサービス、およびボイスオーバーIP(VoIP))に使用される。
送達確認モードでは、RLCレイヤは、自動再送要求(ARQ:Automatic Repeat Request)プロトコルによる誤り訂正をサポートし、典型的には、誤り無くデータを送達することが最重要であるファイル転送等のIPに基づくサービスに使用される。RLC再送信は、例えば、ピアRLC受信側エンティティから受信されたRLC状況報告(すなわちACK/NACK)に基づいている。送達確認モードは、エアインタフェースのビット誤り率が高い状態において再送信によってパケットデータを高い信頼性で送るために設計されている。誤ったPDUまたは失われたPDUがある場合、送信機が、受信機からRLC状況報告を受信した際に再送信を行う。
ARQは、誤ったPDUまたは失われたPDUの再送信のための再送信方式として使用される。例えば、受信されるシーケンス番号を監視することによって、受信側RLCエンティティは、失われたPDUを識別することができる。この場合、受信側RLCがRLC状況報告を生成することができ、送信側RLCエンティティにフィードバックして、失われたかまたは復号が不成功に終わったPDUの再送信を要求する。送信機がRLC状況報告をポーリングすることもできる。すなわち、送信側RLCに受信バッファ状況を知らせる状況報告を受信側RLCから得るために、ポーリング機能が送信側RLCによって使用される。状況報告は、HARQの並べ替えが完了する最後のRLCデータPDUまでの、各RLCデータPDUまたはその一部についての肯定的確認応答(ACK)または否定的確認応答情報(NACK)を提供する。ポーリングフィールドを有するPDUが「1」に設定されるか、またはRLCデータPDUが失われたと検出される場合、受信側RLCは、状況報告をトリガする。参照として、本明細書に援用される非特許文献5(現在のバージョン13.0.0)の5.2.3節には、あるトリガが定義されている。これらのトリガは、送信側RLCにおいてRLC状況報告のためのポーリングをトリガする。送信機において、送信は、送信ウィンドウ内のPDUについてのみ許可され、送信ウィンドウは、RLC状況報告によってのみ更新される。したがって、RLC状況報告が遅延している場合、送信ウィンドウを進めることができず、送信が行き詰まる場合もある。
受信機は、トリガされた場合に送信機にRLC状況報告を送信する。
既に上述の通り、データPDU送達に加えて、制御PDUをピアエンティティ間でシグナリングすることができる。
[MAC HARQプロトコル]
MACレイヤは、HARQエンティティを備える。HARQエンティティは、HARQ送受信動作の役割を担っている。HARQ送信動作には、トランスポートブロックの送信および再送信、ならびにACK/NACKシグナリングの受信および処理が含まれる。HARQ受信動作には、トランスポートブロックの受信、受信データの合成、およびACK/NACKシグナリングの生成が含まれる。先のトランスポートブロックが復号されている間に、連続的な送信を行うことができるように、最大8つの並行したHARQプロセスを使用して、マルチプロセス「ストップアンドウェイト」(SAW:Stop-And-Wait)HARQ動作をサポートする。各HARQプロセスは、個別のSAW動作を実行し、個別のバッファを管理する。
HARQプロトコルによって提供されるフィードバックは、確認応答(ACK)または否定的確認応答(NACK)のいずれかである。ACKおよびNACKは、送信が正確に受信されたか否か(例えば、複合が成功したか)に応じて生成される。さらに、HARQ動作では、UEがIR(Incremental Redundancy)合成を用いて、合成利得を介して追加的な符号化利得を得ることができるように、eNBは再送信の際に元のトランスポートブロックと異なる符号化バージョンのものを送信することができる。
FEC符号化パケットが送信され、受信機がパケットを正確に復号できない場合(通常、エラーは、CRC(Cyclic Redundancy Check:巡回冗長検査)によって検査される)、受信機はパケットの再送信を要求する。一般に(また、本明細書を通して)、追加情報を送信することを「(パケットの)再送信」と呼ぶ。この再送信は、一般に、同一の符号化情報を送信することを意味するが、必ずしものこれを意味するわけではない。または、再送信とは、パケットに属する任意の情報(例えば追加的な冗長性情報)を、例えば、様々な冗長バージョンを使用して送信することを意味することもできる。
一般に、HARQ方式は、同期式または非同期式に分類することができ、再送信は、それぞれの場合において、適応的または非適応的である。同期HARQは、各HARQプロセスのトランスポートブロックの再送信が、最初の送信に対して事前に定義された(周期的な)時に行われることを意味する。したがって、受信機に再送信スケジュール、または、例えばHARQプロセス番号を示すための明示的なシグナリングは、再送信スケジュールが送信タイミングから推測可能であるため要求されない。
対照的に、非同期HARQでは、最初の送信に対して任意の時に再送信を行うことができ、非同期HARQでは、エアインタフェースの状態に基づいて再送信をスケジューリングする柔軟性が提供される。しかしながら、この場合、正確な合成およびプロトコルの動作が可能になるように、例えば、HARQプロセスを受信機に示す追加的な明示的なシグナリングが要求される。3GPP LTEシステムでは、8つのプロセスを含むHARQ動作が使用される。
LTEでは、非同期−適応HARQ(asynchronous adaptive HARQ)はダウンリンクで使用され、同期HARQがアップリンクで使用される。アップリンクでは、再送信は、例えばアップリンクグラントにおいて送信属性が新たにシグナリングされるかに応じて、適応的であっても、非適応的であってもよい。
アップリンクHARQプロトコルの動作では(すなわち、アップリンクデータ送信の確認応答のために)、再送信をスケジューリングする方法についての2つの異なるオプションがある。再送信は、NACKによって「スケジューリングされる」か(同期−非適応再送信(synchronous non-adaptive retransmission)ともいう)、またはPDCCHを送信することによってネットワークによって明示的にスケジューリングされる(同期−適応再送信(synchronous adaptive retransmissions)ともいう)。
同期−非適応再送信の場合には、再送信には先のアップリンク送信と同一のパラメータが使用される。すなわち、再送信は同一の物理チャネルリソースでシグナリングされ、各再送信では同一の変調方式/トランスポートフォーマットが使用される。ただし、冗長バージョンは、変化する(すなわち、事前に定義された冗長バージョン(0、2、3、1)の順序で循環する)。
同期−適応再送信がPDCCHを介して明示的にスケジューリングされるため、eNodeBは、再送信について特定のパラメータを変えることができる。例えば、アップリンクにおける断片化を回避するために異なる周波数リソースに再送信をスケジューリングすることができる。あるいはeNodeBは、変調方式を変更することもでき、代替的にいずれの冗長バージョンを再送信に使用するかをユーザ機器に示すこともできる。なお、HARQフィードバック(ACK/NACK)およびPDCCHシグナリングがUL HARQのFDD動作と同一のタイミングで行われることに留意されたい。したがって、ユーザ機器は、同期−非適応再送信がトリガされるか(すなわち、NACKのみが受信されるか)、またはeNodeBが同期−適応再送信を要求するか(すなわち、PDCCHもシグナリングされるか)を一度チェックする必要があるのみである。
PHICHは、eNodeBがPUSCHによる送信を正確に受信したかを示すHARQフィードバックを伝送する。HARQインジケータは、肯定的確認応答(ACK)の場合は0に、否定的確認応答(NACK)の場合は1に設定される。アップリンクデータ送信のためのACK/NACKメッセージを伝送するPHICHは、同一のユーザ端末に関して、物理ダウンリンク制御チャネル(PDCCH:Physical Downlink Control Channel)と同時に送信されることがある。このような同時送信の場合、ユーザ端末は、PHICHの内容にかかわらず、PDCCHがユーザ端末に何をすべきと支持しているか(すなわち、新規送信(切り替えられたNDIを含む新規ULグラント)を行うべきであるか、または再送信(適応再送信ともいう)(切り替えられたNDIを含まない新規ULグラント)を行うべきであるか)を判定することができる。端末用のPDCCHが検出されない場合、PHICHの内容が端末のUL HARQ挙動を決定する。端末のUL HARQ挙動を以下に要約する。
NACK: 端末は、非適応再送信(すなわち、同一のHARQプロセスで先に使用されたアップリンクリソースと同一のアップリンクリソースでの再送信)を行う。
ACK: 端末はアップリンク再送信を行わず、該HARQプロセスのHARQバッファ内のデータを保持する。該HARQプロセスのためのさらなる送信を、PDCCHによる後のグラントによって明示的にスケジューリングする必要がある。そのようなグラントが受信されるまで、端末は「保留状態」となる。
LTEのアップリンクHARQプロトコルのスケジュールタイミングを、図3に例示する。eNBは、PDCCHでUEに第1のアップリンクグラント301を送信し、これに対して、UEはPUSCHでeNBに第1のデータ302を送信する。PDCCHアップリンクグラントとPUSCH送信との間のタイミングは、現在4msで固定されている。eNBは、UEから第1のデータ送信302を受信した後に、UEにフィードバック情報(ACK/NACK)、および、場合によっては、受信した送信のためのULグラント303を送信する(あるいは、UL送信が成功した場合、eNBは、適切な第2のアップリンクグラントを送信することによって新規アップリンク送信をトリガすることができる)。PUSCH送信と、フィードバック情報を伝送する対応のPHICHとの間のタイミングも、現在4msで固定されている。したがって、アップリンクHARQプロトコルにおける次の(再)送信機会を示すラウンドトリップタイム(RTT:Round Trip Time)は、8msである。これらの8msの後、UEは、eNBによって指示された先のデータの再送信304を送信してもよい。さらなる動作については、先に送信されたデータパケットの再送信304が再び不成功に終わり、eNodeBがさらなる再送信を行うようにUEに指示する(例えば、NACK305をフィードバックとして送信する)ことが想定される。UEは、eNodeBからの指示に応じて、さらなる再送信306を行ってもよい。
図3の上部には、サブフレーム番号と共にHARQプロセスとサブフレームとの例示的な関連付けが示されている。図3から明らかなように、8つの利用可能なHARQプロセスの各々は、対応するサブフレームと循環して関連付けられている。図3の例示的なシナリオでは、最初の送信302および最初の送信302に対応する再送信304および306が、同一のHARQプロセス番号5によって処理されることが想定されている。
UEにおける測定を行うための測定用ギャップの優先度は、HARQ再送信の優先度より高い。したがって、HARQ再送信が測定用ギャップと衝突する場合は常に、HARQ再送信は行われない。一方、PHICHによるHARQフィードバック送信が測定用ギャップと衝突する場合は常に、UEは、予期されるHARQフィードバックの内容としてACKを想定する。
ダウンリンク制御情報には、HARQ動作の援助となるいくつかのフィールドがある。
・ 新規データインジケータ(NDI:New Data Indicator): トランスポートブロックの送信がスケジューリングされる場合に必ず切り替えられる(すなわち、最初の送信ともいわれる)。「切り替えられる」とは、関連付けられたHARQ情報において提供されるNDIビットがこのHARQプロセスの先の送信における値と比較して変更された/切り替えられたことを意味する。
・ 冗長バージョン(RV:Redundancy Version): 送信または再送信のために選択されたRVを示す。
・ MCS(Modulation and Coding Scheme): 変調・符号化方式。
HARQ動作は複雑であり、本出願において完全には説明しない/説明することができない、また、本発明の十分な理解にとって必要でもない。HARQ動作の関連部分が、例えば、非特許文献2(現在のバージョン13.0.0)の5.4.2節「HARQ動作」に定義されている。以下、この節を引用する。
―――引用開始。―――
5.4.2 HARQ動作
5.4.2.1 HARQエンティティ
MACエンティティには、アップリンクが設定されたサービングセルごとにHARQエンティティが1つある。HARQエンティティは、先の送信が成功か不成功かについてHARQフィードバックを待ちつつ、連続して送信することを可能にする多くの並行HARQプロセスを維持している。
HARQエンティティごとの並行HARQプロセスの数は、第8節の[2]に規定されている。
物理レイヤがアップリンクの空間多重化に対応して設定されている場合[2]、2つのHARQプロセスが所定のTTIに関連付けられる。物理レイヤがアップリンクの空間多重化に対応して設定されていない場合、1つのHARQプロセスが所定のTTIに関連付けられる。
所定のTTIにおいて、該TTIに対応するアップリンクグラントが示される場合、HARQエンティティは、送信が行われるべきHARQプロセスを識別する。また、HARQエンティティは、物理レイヤによって中継される受信したHARQフィードバック(ACK/NACK情報)、MCS、およびリソースを適切なHARQプロセスにルーティングする。
TTIバンドリングが設定されている場合、パラメータTTI_BUNDLE_SIZEが、TTIバンドルのTTI数を規定する。同一のバンドルの一部である各送信について同一のHARQプロセスを呼び出すTTIバンドリング動作は、HARQエンティティに依存する。バンドル内において、HARQ再送信は非適応的であり、TTI_BUNDLE_SIZEに応じて先の送信のフィードバックを待たずにトリガされる。バンドルのHARQフィードバックは、バンドルの最後のTTIにおいて送信が行われるか否か(例えば、測定用ギャップが生じた場合)にかかわらず、最後のTTI(すなわち、TTI_BUNDLE_SIZEに対応するTTI)に対して受信されるのみである。TTIバンドルの再送信も、TTIバンドルである。アップリンクが設定された1つ以上のSCellがMACエンティティに設定されている場合、TTIバンドリングはサポートされない。
TTIバンドリングは、RNのサブフレーム設定と組み合わせてE−UTRANを用いるRN通信についてはサポートされない。
ランダムアクセス(5.1.5節参照)時のMsg3の送信については、TTIバンドリングは適用されない。
各TTIについて、HARQエンティティは、
− 各TTIに関連付けられたHARQプロセスを識別し、識別された各HARQプロセスについて、
− そのHARQプロセスおよびそのTTIのためのアップリンクグラントが示される場合であって、
− 受信したグラントがPDCCHにおいて一時的C−RNTI宛に送信されておらず、かつ、関連付けられたHARQ情報において提供されるNDIがそのHARQプロセスの以前の送信時の値と比較して切り替えられている場合、または、
− C−RNTIに対応するアップリンクグラントがPDCCHで受信され、識別されたプロセスのHARQバッファが空である場合、または、
− アップリンクグラントがランダムアクセス応答において受信された場合であって、
− Msg3バッファにMAC PDUがあり、アップリンクグラントがランダムアクセス応答において受信された場合、
− 送信するMAC PDUをMsg3バッファから取得する。
− あるいは、Msg3バッファにMAC PDUがあり、アップリンクグラントがランダムアクセス応答において受信された場合以外の場合には、
− 送信するMAC PDUを「多重化および組立て」(“Multiplexing and assembly”)エンティティから取得し、
− 識別されたHARQプロセスにMAC PDUおよびアップリンクグラントおよびHARQ情報を送達し、
− 識別されたHARQプロセスに新規送信をトリガするように指示する。
− あるいは、受信したグラントがPDCCHにおいて一時的C−RNTI宛に送信されておらず、かつ、関連付けられたHARQ情報において提供されるNDIがそのHARQプロセスの以前の送信時の値と比較して切り替えられている場合、および、C−RNTIに対応するアップリンクグラントがPDCCHで受信され、識別されたプロセスのHARQバッファが空である場合、および、アップリンクグラントがランダムアクセス応答において受信された場合のいずれでもない場合、
− 識別されたHARQプロセスにアップリンクグラントおよびHARQ情報(冗長バージョン)を送達し、
− 識別されたHARQプロセスに適応再送信を生成するように指示する。
− あるいは、このHARQプロセスのHARQバッファが空でない場合、
− 識別されたHARQプロセスに非適応再送信を生成するように指示する。
以前の送信時の値と比較してNDIが切り替えられたかを判定する際、MACエンティティは、PDCCHのすべてのアップリンクグラントにおいて受信された、一時的C−RNTIに対応するNDIを無視するものとする。
5.4.2.2 HARQプロセス
各HARQプロセスには、HARQバッファが関連付けられている。
各HARQプロセスは、バッファ内に現在あるMAC PDUについて行われた送信の回数を示す状態変数CURRENT_TX_NB、および現在バッファ内にあるMAC PDUについてのHARQフィードバックを示す状態変数HARQ_FEEDBACKを維持するものとする。HARQプロセスが確立される場合、CURRENT_TX_NBは初期化されて0になる。
冗長バージョンの順序は0、2、3、1である。変数CURRENT_IRVは、冗長バージョンの順序になる指数である。この変数は、4を法として更新される。
新規送信は、PDCCHまたはランダムアクセス応答において示されたリソースおよびMCSで行われる。適応再送信は、PDCCHにおいて示されたリソースで、および提供された場合、PDCCHにおいて示されたMCSで行われる。非適応再送信は、最後に試みられた送信に使用されたリソースおよびMCSと同一のリソースおよびMCSで行われる。
MACエンティティには、HARQの最大送信回数およびMsg3 HARQの最大送信回数(それぞれ、maxHARQ-TxおよびmaxHARQ-Msg3Tx)がRRCによって設定されている。Msg3バッファに格納されたMAC PDUの送信を除くすべてのHARQプロセスおよびすべての論理チャネルでの送信については、最大送信回数は、maxHARQ-Txに設定されるものとする。Msg3バッファに格納されたMAC PDUの送信については、最大送信回数は、maxHARQ-Msg3Txに設定されるものとする。
TBに対応するHARQフィードバックが受信される場合、HARQプロセスは、
− HARQ_FEEDBACKを受信された値に設定する。
HARQエンティティが新規送信を要求する場合、HARQプロセスは、
− CURRENT_TX_NBを0に設定し、
− CURRENT_IRVを0に設定し、
− 関連付けられたHARQバッファにMAC PDUを格納し、
− HARQエンティティから受信したアップリンクグラントを格納し、
− HARQ_FEEDBACKをNACKに設定し、
− 後述のように送信を生成する。
HARQエンティティが再送信を要求する場合、HARQプロセスは、
− CURRENT_TX_NBを1インクリメントし、
− HARQエンティティが適応再送信を要求する場合、
− HARQエンティティから受信したアップリンクグラントを格納し、
− CURRENT_IRVをHARQ情報において提供される冗長バージョンの値に対応する指数に設定し、
− HARQ_FEEDBACKをNACKに設定し、
− 後述のように送信を生成する。
− あるいは、HARQエンティティが非適応再送信を要求する場合であって、
− HARQ_FEEDBACK=NACKの場合、
− 後述のように送信を生成する。
注:HARQ ACKのみを受信する際、MACエンティティはHARQバッファ内のデータを保持する。
注:測定用ギャップの発生によりUL−SCH送信を行うことができない場合、HARQフィードバックは受信されず、次いで非適応再送信が行われる。
送信を生成するために、HARQプロセスは、
− MAC PDUがMsg3バッファから取得された場合、または、
− 送信用サイドリンクディスカバリギャップが上位レイヤによって設定されておらず、送信時に測定用ギャップが存在せず、また、再送信があるのであれば、Msg3バッファから取得されたMAC PDUの送信と再送信がTTIにおいて衝突しない場合、または、
− 送信用サイドリンクディスカバリギャップが上位レイヤによって設定されており、送信時に測定用ギャップが存在せず、また、再送信があるのであれば、Msg3バッファから取得されたMAC PDUの送信と再送信が衝突せず、このTTI内に送信用サイドリンクディスカバリギャップが存在しない場合、または、
− 送信用サイドリンクディスカバリギャップが上位レイヤによって設定されており、送信時に測定用ギャップが存在せず、また、再送信があるのであれば、Msg3バッファから取得されたMAC PDUの送信と再送信が衝突せず、送信用サイドリンクディスカバリギャップが存在し、このTTI内にSL−DCHでの送信のグラントが存在しない場合、
− CURRENT_IRVの値に対応する冗長バージョンを有する格納されたアップリンクグラントに係る送信を生成するように物理レイヤに指示し、
− CURRENT_IRVを1インクリメントし、
− この送信のHARQフィードバックの受信時に測定用ギャップまたは受信用サイドリンクディスカバリギャップが存在し、かつ、MAC PDUがMsg3バッファから取得されなかった場合、
− この送信のHARQフィードバックの受信時にHARQ_FEEDBACKをACKに設定する。
上記動作を行った後、次いで、HARQプロセスは、
− CURRENT_TX_NB=最大送信回数−1である場合、
− HARQバッファをフラッシュする。
―――引用終了―――
[LTEの装置間(D2D:Device to Device)近傍サービス(ProSe)]
近傍性に基づくアプリケーションおよびサービスは、ソーシャル技術の新しいトレンドである。結びつく分野としては、事業者およびユーザにとって関心のある商用サービスおよび公共安全に関連するサービスが挙げられる。LTEに近傍サービス(ProSe)機能を導入することにより、3GPP業界は、この成長の見込まれる市場にサービスを提供することができると同時に、連係してLTEを使用するいくつかの公共安全コミュニティの緊急なニーズに応えることができる。
装置間(D2D)通信は、LTEリリース12によって導入された技術要素であり、この技術によって、セルラーネットワークに対するアンダーレイ(下層)としてのD2Dにおいてスペクトル効率を高めることができる。例えば、セルラーネットワークがLTEである場合、データを伝送するすべての物理チャネルは、D2DシグナリングにおいてSC−FDMAを使用する。D2D通信では、ユーザ機器は、無線基地局を経由せずに、セルラーリソースを使用する直接的なリンクを通じて互いにデータ信号を送信する。本発明全体を通じて、用語「D2D」、「ProSe」、および「サイドリンク」は同義である。
LTEにおけるD2D通信は、ディスカバリおよび通信という2つの分野に焦点をあてている。
ProSe(近傍サービス)直接ディスカバリ(ProSe Direct Discovery)は、ProSe対応UEが、近傍の他の(1基または複数基の)ProSe対応UEを、PC5インタフェースを介してE−UTRA直接無線信号を使用して発見するために使用される手順と定義されている。
D2D通信では、UEとUEが、基地局(BS)を経由せずに、セルラーリソースを使用して直接的なリンクを通じて互いにデータ信号を送信する。D2Dユーザは、基地局の制御下にある状態で(すなわち、少なくともeNBのカバレッジ内にあるときに)互いに直接通信する。したがって、D2Dでは、セルラーリソースを再利用することによってシステム性能を改善することができる。
D2Dは、アップリンクLTE周波数帯(FDDの場合)において動作する、またはカバレッジを提供しているセルのアップリンクサブフレーム(TDDの場合、ただしカバレッジ外のときを除く)において動作するものと想定される。さらに、D2D送信/受信では、与えられたキャリアにおいて全二重を使用しない。個々のユーザ機器の観点からは、与えられたキャリアにおいて、D2D信号受信およびLTEアップリンク送信が全二重を使用しない(すなわちD2D信号受信およびLTEアップリンク送信を同時に行うことはできない)。
D2D通信では、特定の1基のUE1が送信の役割であるとき(送信側ユーザ機器または送信側端末)、UE1がデータを送り、別のUE2(受信側ユーザ機器)がそれを受信する。UE1およびUE2は、送信の役割と受信の役割を交換することができる。UE1からの送信は、UE2に類似する1基または複数基のUEによって受信することができる。
ユーザプレーンプロトコルに関して、D2D通信の観点からの合意の一部を以下に記載する(参照により本明細書に援用される非特許文献6(現在のバージョン12.0.1)の9.2.2節も参照されたい)。
− PDCP:
・ 1:M D2Dブロードキャスト通信データ(すなわちIPパケット)は、通常のユーザプレーンデータとして扱うべきである。
・ 1:M D2Dブロードキャスト通信には、PDCPにおけるヘッダ圧縮/圧縮解除を適用することができる。
・ 公共安全に関連するD2Dブロードキャスト動作では、PDCPにおけるヘッダ圧縮にUモードを使用する。
− RLC:
・ 1:M D2Dブロードキャスト通信にはRLC UMを使用する。
・ セグメント化および再組立てはRLC UMによってL2においてサポートされる。
・ 受信側ユーザ機器は、送信側のピアユーザ機器あたり少なくとも1つのRLC UMエンティティを維持する必要がある。
・ 最初のRLC UMデータユニットを受信する前に受信機のRLC UMエンティティを設定する必要はない。
・ 現時点では、ユーザプレーンデータを送信するD2D通信においてRLC AMまたはRLC TMの必要性は認識されていない。
− MAC:
・ 1:M D2Dブロードキャスト通信ではHARQフィードバックを想定しない。
・ 受信側ユーザ機器は、受信機のRLC UMエンティティを識別する目的で送信元IDを認識する必要がある。
・ MACヘッダには、MACレイヤにおけるパケットフィルタリングを可能にするL2送信先IDが含まれる。
・ L2送信先IDは、ブロードキャストアドレス、グループキャストアドレス、またはユニキャストアドレスとすることができる。
・ L2グループキャスト/ユニキャスト: MACヘッダにおいて伝えられるL2送信先IDによって、受信されたRLC UM PDUを、たとえそれを受信機のRLCエンティティに渡す前であっても破棄することが可能となる。
・ L2ブロードキャスト: 受信側ユーザ機器は、すべての送信機からの受信されたすべてのRLC PDUを処理し、再組立てしてIPパケットを上位レイヤに渡す。
・ MACサブヘッダには、(複数の論理チャネルを区別するための)論理チャネルID(LCID)が含まれる。
・ D2Dでは、少なくとも多重化/逆多重化、優先順位の処理、およびパディングが有用である。
リリース12の時間構成では、マルチキャリアの/公衆陸上移動体ネットワーク(PLMN:Public Land Mobile Network)間でのProSe動作は、受信側の挙動に制限されていた。つまり、サービングPLMNとは別のPLMNに属するディスカバリ用のキャリアを監視するようにUEを設定することはできる。しかしながら、リリース12では、サイドリンク直接ディスカバリアナウンスの送信は、PLMN内の場合に制限されており、設定されたサービングセルの1つ(すなわち、UEがRRC_CONNECTEDモードである場合のPCell)においてのみ行うことができる。したがって、潜在的に多くの装置が直接ディスカバリ送信に関与していることによる負荷平衡化問題に関し、eNBは、ハンドオーバ(すなわち、PCellの変更)を行わずには他の(PCell以外の)セルに直接ディスカバリのシグナリングを移動させることができない。さらに、様々な事業者の多くのUEが共有することができる専用のProSeキャリアを直接ディスカバリのために設定すること(すなわちPLMN間設定)がいくつかのシナリオにおいて有益になりえる。上記の考えから、リリース13においてProSeのために直接ディスカバリのサポートを強化する必要性が生まれた。したがって、リリース13では、PLMN内およびPLMN間について、サービングeNBがいずれの周波数およびPLMNでディスカバリ送信を行うことができるかをシグナリングする合意がなされた。UEは、他のキャリアのSIB19を読み、直接ディスカバリ送信のためのリソースを得ることができる。実質的に、リリース13では、サービングセルと同一のPLMNに属する(場合によっては異なるPLMNに属する)非サービングキャリアおよび/またはセカンダリセルにおいてサイドリンクディスカバリ送信を行うことができる。
[ProSe直接通信のレイヤ2リンク]
簡潔に言えば、2基のUEの間でPC5インタフェースを通じてセキュアなレイヤ2リンクを確立することによって、1対1のProSe直接通信が達成される。各UEは、ユニキャスト通信用のレイヤ2 IDを有し、このレイヤ2 IDは、UEがレイヤ2リンクで送る各フレームのSource Layer−2 ID(送信元レイヤ2 ID)フィールドと、UEがレイヤ2リンクで受信する各フレームのDestination Layer−2 ID(宛先レイヤ2 ID)に含まれる。UEは、ユニキャスト通信用のレイヤ2 IDが少なくともローカル範囲内で一意であることを確保する必要がある。したがって、UEは、隣接するUEとのレイヤ2 IDの衝突を、規定されていないメカニズム(例えば、衝突が検出されたときユニキャスト通信用の新しいレイヤ2 IDを自身で割り当てる)を使用して処理するように準備されているべきである。1対1のProSe直接通信のためのレイヤ2リンクは、2基のUEのレイヤ2 IDの組合せによって識別される。すなわちUEは、同一のレイヤ2 IDを使用して、1対1のProSe直接通信のための複数のレイヤ2リンクに関与することができる。
1対1のProSe直接通信は、参照により本明細書に援用される非特許文献7(現在のバージョン13.0.0)の7.1.2節に詳しく説明されているように、次の手順から構成される。
・ PC5を通じてセキュアなレイヤ2リンクを確立する
・ IPアドレス/プレフィックスを割り当てる
・ PC5を通じてレイヤ2リンクを維持する
・ PC5を通じてレイヤ2リンクを解除する
図4は、PC5インタフェースを通じてセキュアなレイヤ2リンクを確立する方法を示している。
1. 相互認証をトリガする目的で、UE−1が直接通信要求(Direct Communication Request)メッセージをUE−2に送る。ステップ1を実行するためには、リンク開始側(UE−1)が相手側(UE−2)のレイヤ2 IDを知っている必要がある。一例として、リンク開始側は、最初にディスカバリ手順を実行することによって、または相手側を含む1対多のProSe通信に参加することによって、相手側のレイヤ2 IDを認識することができる。
2. UE−2が相互認証の手順を開始する。認証手順が正常に終了すると、PC5を通じてのセキュアなレイヤ2リンクの確立が完了する。
単独の(中継されない)1対1通信に関与するUEは、リンクローカルアドレスを使用することもできる。PC5シグナリングプロトコルは、UEがProSe通信範囲内ではないときに検出するために使用されるキープアライブ機能をサポートする。したがって、このようなUEは、レイヤ2リンクの暗黙的な解除に進むことができる。PC5を通じてのレイヤ2リンクの解除は、他方のUEに送信される接続解除要求(Disconnect Request)メッセージを使用することによって実行することができ、他方のUEは、関連するすべてのコンテキストデータも削除する。他方のUEは、接続解除要求メッセージを受信した時点で、接続解除応答(Disconnect Response)メッセージによって応答し、レイヤ2リンクに関連付けられたすべてのコンテキストデータを削除する。
[ProSe直接通信に関連する識別情報]
非特許文献8(現在のバージョン13.2.0)の8.3節には、ProSe直接通信に使用するための次の識別情報が定義されている。
・ SL−RNTI(サイドリンク無線ネットワーク一時識別子): ProSe直接通信のスケジューリングに使用される一意の識別情報
・ 送信元レイヤ2 ID: サイドリンクProSe直接通信におけるデータの送信機を識別する。送信元レイヤ2 IDは24ビット長であり、受信機におけるRLC UMエンティティおよびPDCPエンティティを識別するため、ProSeレイヤ2宛先IDおよびLCIDと一緒に使用される。
・ 宛先レイヤ2 ID: サイドリンクProSe直接通信におけるデータの対象者を識別する。宛先レイヤ2 IDは24ビット長であり、MACレイヤにおいて2つのビットストリングに分割される。
・ 1つ目のビットストリングは、宛先レイヤ2 IDの最下位ビット部分(8ビット)であり、サイドリンク制御レイヤ1 IDとして物理レイヤに転送される。これは、サイドリンク制御における意図するデータの対象者を識別し、物理レイヤにおいてパケットをフィルタリングするために使用される。
・ 2つ目のビットストリングは、宛先レイヤ2 IDの最上位ビット部分(16ビット)であり、MACヘッダ内で伝えられる。これは、MACレイヤにおいてパケットをフィルタリングするために使用される。
UEにおいてグループを形成するためと、送信元レイヤ2 ID、宛先レイヤ2 ID、およびサイドリンク制御レイヤ1 IDを設定するために、非アクセス層シグナリングが必要である。これらの識別情報は、上位レイヤによって提供される、または上位レイヤによって提供される識別情報から導かれる。グループキャストおよびブロードキャストの場合、上位レイヤによって提供されるProSe UE IDが送信元レイヤ2 IDとして直接使用され、上位レイヤによって提供されるProSeレイヤ2グループIDが、MACレイヤにおいて宛先レイヤ2 IDとして直接使用される。1対1の通信の場合、上位レイヤが送信元レイヤ2 IDおよび宛先レイヤ2 IDを提供する。
[D2Dディスカバリ−モデルおよびリソース割当て]
ProSe直接ディスカバリ(ProSe Direct Discovery)は、ProSe対応UEが、近傍の他の(1基または複数基の)ProSe対応UEを、PC5を介してE−UTRA直接無線信号を使用して発見するために使用される手順と定義されている。図5は、装置間の直接ディスカバリのためのPC5インタフェースを概略的に示している。
上位レイヤは、ディスカバリ情報のアナウンスおよび監視の許可を処理する。この目的のため、各UEが互いに、事前に定義された信号(ディスカバリ信号(discovery signal)と称する)を交換しなければならない。UEは、必要なときに通信リンクを確立する目的で、ディスカバリ信号を周期的にチェックすることによって、近傍のUEのリストを維持する。ディスカバリ信号は、たとえ信号対雑音比(SNR:Signal to Noise Ratio)が低い環境においても高い信頼性で検出される必要がある。ディスカバリ信号を周期的に送信することができるように、ディスカバリ信号用のリソースを割り当てる必要がある。
ProSe直接ディスカバリには2つのタイプがあり、すなわちオープン型(open)と制限型(restricted)である。オープン型は、発見されるUEからの明示的な許可が必要ない場合であり、制限型の発見は、発見されるUEからの明示的な許可があるときにのみ行われる。
ProSe直接ディスカバリは、例えば、発見される側のユーザ機器からの情報をUE内の特定のアプリケーションのために使用することができるスタンドアロンのサービスイネーブラ(service enabler)とすることができる。アプリケーションは、上記情報(例えば、「近くでタクシーを見つけて」、「コーヒーショップを見つけて」)の使用が許可されているアプリケーションである。さらに、取得した情報に応じて、ProSe直接ディスカバリを使用して以降の動作(例えばProSe直接通信を開始するなど)を行うことができる。
ProSe直接ディスカバリの次のモデルは、参照により本明細書に援用される3GPPの規格である非特許文献9(現在のバージョン13.2.0)の5.3節およびその全項に定義されている。
モデルA(「私はここです」):
このモデルは、ProSe直接ディスカバリに参加しているProSe対応UEのための2つの役割を定義する。
・ アナウンスする側のUE: このUEは、発見する許可を有する近傍のUEが使用することができる特定の情報をアナウンスする。
・ 監視する側のUE: このUEは、アナウンスする側のUEの近傍において興味のある特定の情報を監視する。
このモデルでは、アナウンスする側のUEは、事前に定義されたディスカバリ時間間隔でディスカバリメッセージをブロードキャストし、これらのメッセージに興味を持っている監視する側のUEがメッセージを読み、これらのメッセージを処理する。アナウンスする側のUEが自身についての情報(例えば、自身のProSeアプリケーションコード(ProSe Application Code))をディスカバリメッセージにおいてブロードキャストするため、このモデルを「私はここです」ともいう。
モデルB(「そこにいるのは誰ですか?」/「あなたはそこにいますか?」):
このモデルは、ProSe直接ディスカバリに参加するProSe対応UEの2つの役割を定義する。
・ 発見する側のUE: このUEは、自身が発見したい対象に関する特定の情報を含む要求を送信する。
・ 発見される側のUE: 要求メッセージを受信したUEは、発見する側のUEの要求に関連する何らかの情報で応答することができる。
発見する側のUEが、応答を受け取りたい情報を他のUEに送信するため、モデルBを「そこにいるのは誰ですか?/あなたはそこにいますか?」ともいう。例えば、この情報を、グループに対応するProSeアプリケーションIDについての情報とすることができ、このグループのメンバーが応答することができる。
ディスカバリ情報の内容は、アクセス層(AS:Access Stratum)に対して透過的であり、アクセス層では、ProSe直接ディスカバリの各モデルおよびProSe直接ディスカバリのタイプについて区別されない。ProSeプロトコルは、確実に、アナウンスのために有効なディスカバリ情報のみをアクセス層(AS)に渡す。
UEは、eNB設定にしたがって、RRC_IDLE状態およびRRC_CONNECTED状態のいずれの状態でもディスカバリ情報のアナウンスおよび監視に参加することができる。UEは、半二重の制約を受けるディスカバリ情報をアナウンスおよび監視する。
一般的には、装置の発見は周期的に必要である。さらに、D2D装置は、ディスカバリメッセージのシグナリングプロトコルを利用して装置の発見を実行する。例えば、D2D対応UEが、自身のディスカバリメッセージを送信することができ、他のD2D対応UEがこのディスカバリメッセージを受信し、この情報を使用して通信リンクを確立することができる。ハイブリッドネットワークの利点として、D2D装置がネットワークインフラストラクチャの通信範囲内でもある場合、eNBなどのネットワークエンティティがディスカバリメッセージの送信や設定を追加的に支援することができる。ディスカバリメッセージの送信や設定をeNBによって調整/制御することは、D2Dのメッセージングと、そのeNBによって制御されているセルラートラフィックとの干渉が確実に発生しないようにするうえでも重要である。さらには、装置のいくつかがネットワークカバレッジの範囲外である場合でも、カバレッジ内の装置がアドホックディスカバリプロトコルを支援することができる。
本説明においてさらに使用される専門用語を定義する目的で、少なくとも以下の2つのタイプのディスカバリ手順が定義されている。
・UEによる自律的リソース選択(以下、タイプ1と呼ぶ): ディスカバリ情報をアナウンスするためのリソースが特定のUEを対象とせずに割り当てられ、さらに以下を特徴とするリソース割当て手順。
○ ディスカバリ情報のアナウンスに使用されるリソースプールの設定をeNBがユーザ機器に提供する。この設定は、例えば、SIB(System Information Block)においてシグナリングすることができる。
○ UEは、示されたリソースプールから(1つまたは複数の)無線リソースを自律的に選択し、ディスカバリ情報をアナウンスする。
○ UEは、各ディスカバリ期間中、ランダムに選択されるディスカバリ用リソースでディスカバリ情報をアナウンスすることができる。
・スケジューリングされたリソース割当て(以下、タイプ2と呼ぶ): ディスカバリ情報をアナウンスするためのリソースが特定のUEを対象として割り当てられ、さらに以下を特徴とするリソース割当て手順。
○ RRC_CONNECTEDモードにあるUEは、ディスカバリ情報をアナウンスするためのリソースをRRCを介してeNBに要求してもよい。eNBは、RRCを介してリソースを割り当てる。
○ リソースは、監視のためにUEに設定されるリソースプール内に割り当てられる。
RRC_IDLEモードにあるUEについては、eNBは以下のオプションの1つを選択することができる。
・ eNBは、ディスカバリ情報をアナウンスするためのタイプ1のリソースプールをSIBにおいて提供することができる。ProSe直接ディスカバリを許可されているUEは、RRC_IDLEモードにおいてこれらのリソースを使用してディスカバリ情報をアナウンスする。
・ eNBは、自身がD2Dをサポートしているが、ディスカバリ情報をアナウンスするためのリソースを提供しないことを、SIBにおいて示すことができる。UEは、ディスカバリ情報をアナウンスするためのD2Dリソースを要求するためには、RRC_CONNECTEDモードに入る必要がある。
RRC_CONNECTED状態にあるUEについて:
・ ProSe直接ディスカバリのアナウンスを実行することが許可されているUEは、D2Dディスカバリのアナウンスの実行を望むことをeNBに知らせる。
・ eNBは、そのUEがProSe直接ディスカバリのアナウンスを許可されているかを、MMEから受信したUEコンテキストを使用して確認する。
・ eNBは、ディスカバリ情報のアナウンス用にタイプ1のリソースプールまたはタイプ2の専用リソースを使用するように、専用のRRCシグナリングを介してUEを設定することができる(またはリソースなし)。
・ eNBによって割り当てられたリソースは、a)eNBがそのリソースをRRCシグナリングによって設定解除する(de-configure)まで、またはb)UEがIDLEモードに入るまで、有効である。
RRC_IDLEモードおよびRRC_CONNECTEDモードにある受信側UEは、許可されたタイプ1およびタイプ2のディスカバリ用リソースプールの両方を監視する。eNBは、ディスカバリ情報を監視するために使用されるリソースプールの設定を、SIBにおいて提供する。SIBは、隣接セルにおいてアナウンスするために使用されるディスカバリ用リソースを含んでいてもよい。
非専用の送受信機の場合のキャリア間ディスカバリ性能を高めるために、直接ディスカバリの送受信のために一連のRF送信部/RF受信部を再利用することができるようにサイドリンクディスカバリギャップが導入される。このギャップは、ネットワーク制御下にあるべきである。
リリース13では、2つの異なるサイドリンクディスカバリギャップ、すなわち、受信用サイドリンクディスカバリギャップおよび送信用ディスカバリギャップが導入された。2つのギャップの定義を以下に示す。これらの定義は、参照により本明細書に援用される対応する規格である非特許文献2(現在のバージョン13.0.0)の3.1節からの引用である。
受信用サイドリンクディスカバリギャップ: ランダムアクセス手順中を除き、UEがいかなるサービングセルからのいかなるDLチャネルも受信しない時間。
送信用サイドリンクディスカバリギャップ: ランダムアクセス手順中を除き、ULチャネルの送信とサイドリンクディスカバリの送信が同一のサブフレームにおいて行われる場合に、UEがULチャネルの送信よりもサイドリンクディスカバリの送信を優先する時間。
周波数間ディスカバリ、特に、PLMN間ディスカバリにおいて、eNodeBがディスカバリ用の他の周波数において使用されているリソースを知らない場合がある。その結果、eNodeBは、いつUEが周波数間ディスカバリ用のダウンリンク受信およびアップリンク送信をスキップするか(スキップすることが許可されている場合)を知らない。これにより、リソースが無駄になることがある。したがって、UEは、ディスカバリ受信および/またはディスカバリ送信のためにギャップを要求することができる。要求する際、UEは、UEがサイドリンクディスカバリオペレーションの送信用および/または受信用のギャップを必要とするサブフレーム(サービングセルのタイミングに対応するサブフレーム)をeNBに知らせることができる。この場合、eNBは、提供された情報に基づいて、UEに、送信用および/または受信用のサイドリンクディスカバリギャップを設定する。ディスカバリのために生成されたギャップは、同期およびサブフレームオフセットに必要とされる追加のオーバーヘッドを考慮に入れるべきであり、また、サイドリンクディスカバリに使用される他の周波数への、RFユニットの再チューニングの中断時間を考慮するべきである。
UEがギャップを要求する場合の情報要素が、非特許文献10において規定されており、IE SL−GapRequestと呼ばれる。すなわち、この情報要素は、UEが周波数内または周波数間のサイドリンクディスカバリの受信または送信のために要求するギャップを示す。
IE SL−GapRequestは、それ自体がSidelinkUEInformationメッセージにおいて運ばれる。SidelinkUEInformationメッセージの抜粋を以下に記載する。
SidelinkUEInformationメッセージは、eNBにサイドリンク情報を示すために使用される。
・ シグナリング無線ベアラ: SRB1
・ RLC−SAP: AM
・ 論理チャネル: DCCH
・ 方向: UEからE−UTRANへ
上述のように、サイドリンクディスカバリギャップはネットワークにより制御されるものであるから、eNBは、UEに送信ギャップまたは受信ギャップを設定する。情報要素IE SL−DiscConfigは、RRCConnectionReconfigurationメッセージにおいてUEにシグナリングされ、サイドリンクディスカバリのため専用の設定情報を規定する。
SL−GapConfig
IE SL−GapConfigは、UEが周波数内または周波数間でサイドリンクディスカバリを受信または送信することができるようにE−UTRANによって割り当てられたギャップを示す。
例えば、サイドリンクギャップの長さは、少なくとも40msであり、連続するサブフレームにまたがっていてもよいし、またがっていなくてもよい。サイドリンクディスカバリギャップの長さには、ディスカバリオペレーションを行う前にディスカバリ用キャリアのプライマリ同期信号(PSS:Primary Synchronization signal)/セカンダリ同期信号(SSS:Secondary Synchronization Signal)を得るためにUEが必要とする同期オーバーヘッドによる無視できない影響がある。
[ProSe直接ディスカバリのための無線プロトコルアーキテクチャ]
図6は、アクセス層プロトコルがMACおよびPHYのみからなる、ProSe直接ディスカバリのための無線プロトコルスタック(アクセス層(AS))を概略的に示す。ASレイヤは、以下の機能を行う。
・ 上位レイヤ(ProSeプロトコル)とインタフェースする機能: MACレイヤは、上位レイヤ(ProSeプロトコル)からディスカバリメッセージを受信する。IPレイヤは、ディスカバリメッセージの送信には使用されない。
・ スケジューリングする機能: MACレイヤは、上位レイヤから受信されたディスカバリメッセージのアナウンスに使用される無線リソースを決定する。
・ ディスカバリPDUを生成する機能: MACレイヤは、ディスカバリメッセージを運ぶMAC PDUを形成し、このMAC PDUを決定された無線リソースで送信するために物理レイヤに送信する。MACヘッダは、付加されない。
UEでは、RRCプロトコルが、ディスカバリ用リソースプールをMACに知らせる。また、RRCは、送信用に割り当てられたタイプ2BのリソースをMACに知らせる。MACヘッダは必要ではない。ディスカバリ用のMACヘッダには、L2においてフィルタリングを実行するときに参照されるフィールドが含まれない。MACレベルにおいてディスカバリメッセージをフィルタリングしても、上位レイヤにおいてProSe UE IDやProSeアプリケーションIDに基づいてフィルタリングを実行することと比較して、処理量や電力が節約されるとは考えられない。受信側MACレイヤは、受け取ったディスカバリメッセージすべてを上位レイヤに渡す。MACレイヤは、正しく受信されたメッセージのみを上位レイヤに渡す。ディスカバリメッセージが正しく受信されたかをL1がMACレイヤに示すものと想定する。上位レイヤは必ず有効なディスカバリ情報のみをASレイヤに渡すものと想定する。
[ProSeネットワークアーキテクチャおよびProSeエンティティ]
図7は、非ローミングの場合の高レベルの例示的なアーキテクチャを示しており、UE AおよびUE Bにおける異なるProSeアプリケーションと、ネットワーク内のProSeアプリケーションサーバおよびProSe機能を含む。図7のアーキテクチャの例は、参照により本明細書に援用される非特許文献9(バージョン13.0.0)の4.2節「Architectural Reference Model(アーキテクチャの基準モデル)」からの引用である。
これらの機能エンティティは、参照により本明細書に援用される非特許文献9の4.4節「Functional Entities(機能エンティティ)」に提示および詳しく説明されている。ProSe機能は、ProSeに要求されるネットワーク関連動作に使用される論理機能であり、ProSeの特徴それぞれにおいて異なる役割を果たす。ProSe機能は、3GPPのEPCの一部であり、近傍サービスに関係する認可、認証、データ処理など、関連するネットワークサービスすべてを提供する。ProSe直接ディスカバリおよびProSe直接通信において、UEは、固有のProSe UE識別情報、他の設定情報、および認証を、ProSe機能からPC3基準点(PC3 reference point)を通じて取得することができる。なお、ネットワーク内に複数のProSe機能を配備することが可能であるが、図7では、説明を容易にするため、1つのProSe機能を示してある。ProSe機能は、ProSeの特徴に応じた異なる役割を実行する主要な3つのサブ機能、すなわち直接提供機能(DPF:Direct Provision Function)、直接ディスカバリネーム管理機能(Direct Discovery Name Management Function)、およびEPCレベルディスカバリ機能(EPC-level Discovery Function)、から構成されている。DPFは、ProSe直接ディスカバリおよびProSe直接通信を使用するための必要なパラメータをUEに提供するために使用される。
ここで、「UE」とは、例えば以下のProSe機能をサポートするProSe対応UEを意味する。
・ ProSe対応UEとProSe機能との間でPC3基準点を通じてProSe制御情報を交換する
・ PC5基準点を通じての、他のProSe対応UEのオープンProSe直接ディスカバリの手順
・ PC5基準点を通じた1対多のProSe直接通信の手順
・ ProSe UEとネットワークとの間の中継器として動作するための手順。遠隔のUEは、PC5基準点を通じて、ProSe UEとネットワークとの間の中継器と通信する。ProSe UEとネットワークとの間の中継器は、レイヤ3パケット転送を使用する。
・ 例えば、UEとネットワークとの間の中継器の検出およびProSe直接ディスカバリのために、PC5基準点を通じて各ProSe UEの間で制御情報を交換する
・ 他のProSe対応UEとProSe機能との間でPC3基準点を通じてProSe制御情報を交換する。ProSe UEとネットワークとの間の中継器の場合、遠隔のUEは、この制御情報を、LTE−Uuインタフェースを通じてProSe機能に中継されるようにPC5ユーザプレーンを通じて送る。
・ パラメータ(例えば、IPアドレス、ProSeレイヤ2グループID、グループセキュリティマテリアル(Group security material)、無線リソースパラメータを含む)を設定する。これらのパラメータは、UEにおいて事前設定することもでき、カバレッジ内にある場合、PC3基準点を通じたシグナリングによってネットワーク内のProSe機能に提供することもできる。
ProSeアプリケーションサーバは、EPC ProSeユーザIDおよびProSe機能IDの格納と、アプリケーション層ユーザIDとEPC ProSeユーザIDのマッピングをサポートする。ProSeアプリケーションサーバ(AS)は、3GPPの範囲外のエンティティである。UEにおけるProSeアプリケーションは、アプリケーション層基準点PC1を介してProSe ASと通信する。ProSe ASは、PC2基準点を介して3GPPネットワークに接続されている。
[ProSe対応UEのためのアップリンクHARQ動作]
上述のように、3GPPは、近傍サービスの標準化を続けてきた。しかしながら、近傍サービスとレガシーLTE(−A)動作との協調は困難であり、また、これをさらに改良することができる。
本発明を制限することのない例示的な実施形態において、サイドリンクディスカバリに参加するユーザ端末のアップリンクデータパケット送信のための改良された送信プロトコルの動作を提供する。
本独立請求項は、本発明を制限することのない例示的な実施形態を提供する。有利な実施形態が従属請求項の主題である。
本明細書に記載されたいくつかの態様によれば、送信プロトコルの動作は、改良されている。これらの態様について説明するために、以下を例示的に想定する。具体的には、データパケットのアップリンク送信(および再送信)(例えばサービング基地局への送信)を制御するために、ユーザ端末が送信プロトコルを実行することが想定されている。送信プロトコルの動作では、ユーザ端末がこれまでに行ったデータパケットの送信回数を数える送信カウンタを使用する(送信カウンタには、許容可能な送信の最大限度がある)。さらに、送信プロトコルは、最初の送信のトリガリングを制御するだけでなく、データパケットの再送信を行うメカニズムも提供する。特に、再送信は、受信側(例えば、サービング基地局)が否定的確認応答を提供するか、以前送信したデータパケットの再送信を行うように適当なアップリンクグラントによって明確にUEに指示する場合に行われる。
さらに、ユーザ機器は、サイドリンク通信に参加することができ、特に、他のサイドリンク対応ユーザ端末とのサイドリンクディスカバリオペレーションに参加することができ、その目的のために、ユーザ機器には、サイドリンクディスカバリギャップ(UEがサイドリンクディスカバリに参加するために確保された時間)が設定されることが想定されている。換言すれば、UEは、他のユーザ端末を発見することができ(これには、適切なサイドリンクディスカバリメッセージを送信/ブロードキャストすることが含まれうる)、かつ/または、他のユーザ端末から発見されることができる(これには、今度は他のユーザ端末が適切なサイドリンクディスカバリメッセージを送信する対応のリソースを監視すること含まれうる)。
これらのサイドリンクディスカバリギャップにおいて、eNBに対するUEの動作は、UEが、特にサイドリンクディスカバリオペレーションに参加している時は、送信プロトコルの信号(例えば、フィードバック情報や実際のパケット(再)送信)を送信および/または受信しないという点で制限されている。したがって、これらのサイドリンクディスカバリギャップは、送信および/または受信を表していてもよい。
したがって、ユーザ端末は、送信プロトコルを連続的に実行してアップリンクデータパケットの送信および再送信を行いつつ、同時に、他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定されている。本明細書に記載された第1の態様によれば、ユーザ端末は、有利にこれらの2つの種類の動作を調整するように適切に設定されている。上述のように、送信プロトコルによってトリガされるデータパケットの特定の再送信は、これらの再送信がサイドリンクディスカバリギャップの1つと衝突するため結局行うことができない。第1の態様によれば、UEは、これらの衝突を監視することによって、データパケットの再送信が、送信プロトコルによって(例えば、対応するアップリンクグラントを受信した際に)トリガされたが、送信プロトコルの動作がサイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションと何らかの衝突をしたことが理由で行われなかったかを判定する。そのような衝突が判定される場合、衝突し、実行されなかった再送信によって該データパケットについては対応する送信カウンタがインクリメントされないように送信プロトコルは実行される。換言すれば、データパケットの再送信は、この再送信が送信プロトコルによって適切にトリガされたものだったとしても、サイドリンクディスカバリギャップによって妨げられることにより結局行われない場合、UEによってデータパケットの送信として数えられず、無視される(すなわち、該データパケットについては送信プロトコルの送信カウンタを増加させない)。
したがって、設定されたサイドリンクディスカバリギャップにおいてサイドリンクディスカバリオペレーションに参加しているUEは、第1の態様に係る特別の方法でデータパケットの再送信を処理する。第1の態様では、該データパケットのための再送信を行う1回以上の対応するさらなる再送信機会をUEから奪わないための構成が提供される。したがって、設定されたサイドリンクディスカバリギャップによって付加的に発生するデータパケット損失を回避することができる。
データパケット損失を回避するこの利点は、送信プロトコルの動作の特定のデータパケットについて増大した遅延によって発生しうるコストに対する対策となる。具体的には、衝突する再送信が対応する送信カウンタを増加させないことになり、第1の態様の改良された送信プロトコルの動作は、送信カウンタが送信の最大許容回数に達するのがより後の時点になるため、全体的な送信プロトコルの動作を遅延させる。
第1の態様のより具体的な変形形態では、様々なサイドリンクディスカバリギャップがどのようにUEの送信プロトコルの動作と実際に衝突するか、すなわちUEが正確に何を監視しなければならないかを扱う。具体的には、UEが設定により有することができるサイドリンクディスカバリギャップは2種類ある。一方を、送信用サイドリンクディスカバリギャップという。送信用サイドリンクディスカバリギャップにおいて、UEは、適切なサイドリンク接続を介して他のユーザ端末にサイドリンクディスカバリメッセージを送信することができる。その結果、送信用サイドリンクディスカバリギャップがUEによって使用されることが確実である場合(例えば、UEが対応するサイドリンクチャネルでサイドリンクディスカバリメッセージを送信するための対応するグラントを受信した場合)、UEは、送信プロトコルによってトリガされる。したがって、UEは、妨げられた(すなわち、行われなかった)再送信を含む他のアップリンク送信に対してサイドリンクディスカバリメッセージ送信を優先する。したがって、UEは、衝突を検出し、対応する送信カウンタが衝突の結果として増加しないように対処する。
また、UEには、受信用サイドリンクディスカバリギャップを設定してもよい。受信用サイドリンクディスカバリギャップにおいて、UEは、他のユーザ端末が対応するサイドリンクディスカバリメッセージを送信したかについてサイドリンク接続の対応するリソースを監視する。これらの受信用サイドリンクディスカバリギャップにおいて、UEは、以前送信したデータパケットについての送信プロトコルのフィードバック情報を含む他のダウンリンク信号を受信することができない。したがって、UEは、そのような衝突(この場合、再送信は、トリガされるが、未受信のフィードバック情報が原因で行われない)を検出し、トリガされる再送信によってデータパケットの対応する送信カウンタが増加しないように対処する。
データパケットが衝突する再送信によって該データパケットについては送信カウンタがインクリメントされないことを実現する方法に関して様々な可能性がある。送信プロトコルによって再送信がトリガされるたびに、送信プロトコルが送信カウンタをインクリメントする処理を規定していることが想定されている。1つのオプションでは、この処理では、再送信がサイドリンクディスカバリギャップとの衝突が理由で実際に行われなかったか否かが追加的に考慮される。その場合、第1の態様の第1のオプションによれば、この送信カウンタをインクリメントする処理は行われない。
第1の態様の第2のオプションによれば、再送信がトリガされるたびに、送信プロトコルが送信カウンタを1インクリメントする現在規定されている処理が行われる。しかしながら、送信カウンタのこの最初のインクリメントは、サイドリンクディスカバリギャップとの衝突により当該再送信(最初に送信カウンタのインクリメントをトリガした再送信)を結局行うことができないと判定される場合に、そのデータパケットについて送信カウンタを1減少させるさらなる処理によって補償される。
第1の態様のさらなる変形形態では、データパケットの再送信が送信プロトコルにしたがってトリガされる場合の処理を扱う。例えば、一般に、UEにおいてアップリンクデータパケット送信のために実行される送信プロトコルは、UEに再送信を行うように、または行わないように指示することができる受信側エンティティ(例えば、サービング基地局)によって提供されるフィードバックに反応する。サービング基地局は、以前送信されたデータパケットの再送信を行うようにUEに指示する特定のアップリンクグラントをUEに提供することができる。このアップリンクグラントには、例えば、再送信がこのアップリンクグラントによってトリガされるのであっても、肯定的確認応答が伴っていてもよい。サービング基地局は、アップリンクグラントによって再送信を要求することによって、再送信のパラメータ(例えば、変調方式、符号化率等)を適合してもよい。これに対し、サービング基地局は、単にUEに否定的確認応答を提供してもよい。これにより、UEは、当該データパケットに関連付けられた空ではないバッファ内のデータの再送信をトリガする。UEは、基本的には、再送信を行うために同一の送信パラメータを使用する。
サイドリンクディスカバリオペレーションがアップリンクデータパケット送信の通常動作とは異なるキャリアで行われる結果、通常のアップリンクデータパケット送信の動作とサイドリンクディスカバリオペレーションとを切り替える際にUEのハードウェア構成要素の再チューニングが必要になるシナリオにおいて、第1の態様は、厳密に必須というわけではないが特に有利である。例えば、一連の送信部/受信部のみを有するUEは、これらの異なる2つのキャリアで同時に動作することができない。そのため、サイドリンクディスカバリオペレーション用および通常のアップリンクデータパケット送信動作用のそれぞれの異なる周波数に一連の受信部/送信部を再チューニングすることが必要になる。
さらに、UEおよびUEのサービング基地局において確実に同期した動作を行うために、サービング基地局が、UEと同様に動作するものとする。具体的には、サイドリンクディスカバリギャップにおけるUEのサイドリンクディスカバリオペレーションと送信プロトコルの動作との衝突も、サービング基地局によって検出され、それに応じてデータパケット用の送信カウンタが動作される。すなわち、トリガされた再送信を、サイドリンクディスカバリギャップの1つとの衝突により行うことができなかった場合に、UEのデータパケットのトリガされた再送信によって送信カウンタが増加されない。
第2の態様では、上述の課題に対する異なる解決策が提供され、また、送信プロトコルの動作が改良される。第1の態様に関してなされた想定はすべて、第2の態様についても同様になされるものとする。要するに、UEは、アップリンクデータの送信および再送信の制御のための送信プロトコルを実行すると想定される。送信プロトコルには、送信カウンタを使用することも含まれる。UEには、データパケットの許容可能最大送信回数を示す、送信カウンタの動作のためのパラメータが設定されている。任意選択的に、送信カウンタがこの最大値に達する場合、送信プロトコルの、対応するデータパケットを格納する対応の送信バッファがフラッシュされる(すなわち、空になる)。受信側(例えば、サービング基地局)からの対応するフィードバックは、以前送信されたデータパケットの新規送信および再送信をトリガするために使用される。さらに、UEは、ProSe対応であることが想定される。したがって、UEは、特に、基地局によって設定されたサイドリンクディスカバリギャップを使用してサイドリンクディスカバリオペレーションに参加する。サイドリンクディスカバリギャップは、送信プロトコルの動作とサイドリンクディスカバリオペレーションとの衝突を引き起こし、UEの基地局との送信プロトコルの動作を制限する。
第1の態様と同様に、第2の態様に係るユーザ端末は、これらの2種類の動作を適切に有利な方式で調整するように設定される。第2の態様に関し、送信プロトコルの動作は、データパケットの再送信が送信プロトコルによってトリガされるたびに、該データパケットについて送信カウンタがインクリメントされる処理を含む。
ここで、第1の態様と同様に、UEは、これらの衝突を監視することによって、データパケットの再送信が、送信プロトコルによって(例えば、対応するアップリンクグラントを受信した際に)トリガされたが、送信プロトコルの動作がサイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションと何らかの衝突をしたことが理由で行われなかったかを判定する。簡潔に言うと、UEは、少なくとも2種類の異なる衝突の1つを監視する。1つ目の衝突は、他のユーザ端末が対応するサイドリンクディスカバリメッセージを送信したかについて、サイドリンク接続の対応するリソースをUEが監視する受信サイドリンクディスカバリギャップによって引き起こされるものである。この衝突により、UEは、以前送信したデータパケットの送信プロトコルのフィードバック情報を含む他のダウンリンク信号を受信することができない。2つ目として、送信サイドリンクディスカバリギャップによって、UEは、例えば基地局への通常のアップリンク再送信と、適切なサイドリンク接続を介した他のユーザ端末へのサイドリンクディスカバリメッセージの送信とを同時に行うことができない。
そのような衝突がUEによって検出される場合、第2の態様の規定では、増加した許容可能最大送信回数を使用して対応する送信カウンタを動作させることによって、トリガされインクリメントを引き起こした再送信がサイドリンクディスカバリギャップにおいてサイドリンクディスカバリオペレーションによって妨げられたために行われなかったが、送信カウンタはインクリメントされた(場合によっては将来的にインクリメントされる)、ことを考慮に入れる。
対応する送信カウンタの動作に適用可能な許容可能最大送信回数をいかに増加するかについて様々な方法がある。
オプションの1つは、さらなる第2の送信カウンタパラメータを、衝突が検出されたデータパケットについて動作される送信カウンタに使用することである。例えば、この第2の送信カウンタパラメータをサービング基地局によってUEに設定することができる。この第2の送信カウンタパラメータによって示される許容可能最大送信回数は、第1の送信カウンタパラメータ(当初、UEにおける送信カウンタは第1の送信カウンタパラメータにしたがって動作した回数)によって設定される許容可能最大送信回数と比較して増加されている。
任意選択的に、eNodeBは、サイドリンクディスカバリギャップの長さを認識しているため、UEにおいて何回の再送信機会がサイドリンクディスカバリギャップによって妨げられるかを認識している。したがって、eNodeBは、第2の送信カウンタパラメータを設定して、対応する方式でデータパケットの許容可能最大送信回数を増加する。例えば、長さが40msのサイドリンクディスカバリギャップは、最大5回の(8msごとに繰り返される)再送信機会を妨げうるため、データパケットの許容可能最大送信回数を同様に5増加することができる。
第2のオプションでは、上述のように、UEが、衝突を検出するたびに、データパケットの許容可能最大送信回数を自律的にインクリメントする。具体的には、送信プロトコルの動作は、再送信がトリガされる場合に必ず送信カウンタをインクリメントし、UEは、このインクリメントに同調して、衝突の場合(すなわち、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したために、トリガされた再送信が行われなかったとUEが判定した場合)に対応する、インクリメントされた送信カウンタに、適用可能な許容可能最大送信回数をインクリメントする。
したがって、送信カウンタの上限(すなわち、許容可能最大送信回数)への到達が早過ぎることはない。このため、UEから、データパケットの再送信を行うための1回以上の対応するさらなる再送信機会が奪われない。したがって、設定されたサイドリンクディスカバリギャップによって付加的に発生するデータパケット損失を回避することができる。
同様に、1つの一般的な第1の態様では、本明細書で開示した技術は、通信システムにおいてアップリンクデータパケット送信のための送信プロトコルを実行するユーザ端末を特徴とする。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および/または受信することができない。ユーザ端末は、送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したために行われなかったかを判定するプロセッサを備える。さらに、衝突がある場合、プロセッサは、データパケットが衝突する再送信が該データパケットについては送信プロトコルの送信カウンタをインクリメントしないように送信カウンタを動作させる。
同様に、1つの一般的な第2の態様では、本明細書で開示した技術は、通信システムにおいてアップリンクデータパケット送信のための送信プロトコルを実行するユーザ端末を特徴とする。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末には、データパケットの許容可能最大送信回数を設定する第1の送信カウンタパラメータが送信カウンタの動作のために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および/または受信することができない。ユーザ端末は、データパケットの再送信が送信プロトコルによってトリガされる場合に、該データパケットについて送信カウンタをインクリメントするプロセッサを備える。さらに、プロセッサは、データパケットのトリガされた再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したために行われなかったかを判定する。そして、衝突がある場合、プロセッサは、データパケットの送信カウンタの動作のために第2の送信カウンタパラメータを使用することによって送信カウンタのためにデータパケットの許容可能最大送信回数を増加する。
同様に、1つの一般的な第1の態様では、本明細書で開示した技術は、通信システムにおいてユーザ端末からアップリンクデータパケット送信を受信する基地局を特徴とする。ユーザ端末は、アップリンクデータパケット送信のための送信プロトコルを実行する。ユーザ端末がデータパケットについて行った送信回数を数える第1の送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末がデータパケットについて行った送信回数を数える第2の送信カウンタが、基地局に設定される。ユーザ端末は、サイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように基地局によって設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および/または受信することができない。基地局は、ユーザ端末の送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したためにユーザ端末によって行われなかったかを判定するプロセッサを備える。そして、衝突がある場合、プロセッサは、データパケットが衝突する送信が該データパケットについては送信プロトコルの第2の送信カウンタをインクリメントしないように第2の送信カウンタを動作させる。
同様に、1つの一般的な第1の態様では、本明細書で開示した技術は、通信システムにおいてアップリンクデータパケット送信のためのユーザ端末における送信プロトコルを実行する方法を特徴とする。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および/または受信することができない。本方法には、送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したために行われなかったかをユーザ端末が判定するステップが含まれる。そして、衝突がある場合、ユーザ端末は、データパケットが衝突する再送信が該データパケットについては送信プロトコルの送信カウンタをインクリメントしないように送信カウンタを動作させる。
同様に、1つの一般的な第2の態様では、本明細書で開示した技術は、通信システムにおいてユーザ端末からアップリンクデータパケット送信を受信する基地局を特徴とする。端末は、アップリンクデータパケット送信のための送信プロトコルを実行する。ユーザ端末がデータパケットについて行った送信回数を数える第1の送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末がデータパケットについて行った送信回数を数える第2の送信カウンタが、基地局に設定される。第1の送信カウンタパラメータが、第1のおよび第2の送信カウンタの動作のためのデータパケットの許容可能最大送信回数を設定する。ユーザ端末は、サイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように基地局によって設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および/または受信することができない。基地局は、ユーザ端末においてデータパケットの再送信が送信プロトコルによってトリガされる場合に、該データパケットについて第2の送信カウンタをインクリメントするプロセッサを備える。そして、プロセッサは、ユーザ端末の送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したためにユーザ端末によって行われなかったかを判定する。衝突がある場合、プロセッサは、データパケットの第2の送信カウンタの動作のために第2の送信カウンタパラメータを使用することによって第2の送信カウンタのためにデータパケットの許容可能最大送信回数を増加する。
同様に、1つの一般的な第2の態様では、本明細書で開示した技術は、通信システムにおいてアップリンクデータパケット送信のためのユーザ端末における送信プロトコルを実行する方法を特徴とする。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末には、データパケットの許容可能最大送信回数を設定する第1の送信カウンタパラメータが送信カウンタの動作のために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および/または受信することができない。本方法には、データパケットの再送信が送信プロトコルによってトリガされる場合に、該データパケットについて送信カウンタをユーザ端末がインクリメントするステップが含まれる。ユーザ端末は、データパケットのトリガされた再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したために行われなかったかを判定する。衝突がある場合、ユーザ端末は、データパケットの送信カウンタの動作のために第2の送信カウンタパラメータを使用することによって送信カウンタのためにデータパケットの許容可能最大送信回数を増加する。
開示されている実施形態のさらなる利益および利点は、本明細書および各図から明らかになるであろう。これらの利益および/または利点は、本明細書および図面に開示したさまざまな実施形態および特徴によって個別に提供され得る。ただし、これらの利益および/または利点の1つまたは複数を得るためにすべてを備える必要はない。
これらの一般的な態様および特定の態様は、システム、方法、コンピュータプログラム、またはこれらの任意の組合せを使用して実施することができる。
以下では、例示的な実施形態について添付の図面を参照しながらより詳細に説明する。
「移動局」または「移動ノード」または「ユーザ端末」または「ユーザ機器」は、通信ネットワーク内の物理エンティティである。1つのノードがいくつかの機能エンティティを有していてもよい。機能エンティティとは、所定の一連の機能を実施するソフトウェアモジュールもしくはハードウェアモジュール、および/または、所定の一連の機能をノードまたはネットワークの他の機能エンティティに提供するソフトウェアモジュールもしくはハードウェアモジュールを意味する。ノードは、自身を通信機器または通信設備にアタッチする1つまたは複数のインタフェースを有していてもよい。ノードは、これらのインタフェースを通じて通信することができる。同様に、ネットワークエンティティは、機能エンティティを通信機器または通信設備にアタッチする論理インタフェースを有していてもよい。ネットワークエンティティは、論理インタフェースを通じて別の機能エンティティや通信相手ノードと通信しうる。
本特許請求の範囲および本出願において使用されている「無線リソース」という用語は、物理無線リソース(時間−周波数リソースなど)を意味するものと広義に理解されたい。
本特許請求の範囲および本出願において使用されている「直接通信送信」は、2基のユーザ機器間での直接的な(すなわち、eNB等の無線基地局を介さずに)送信を意味するものと広義に理解されたい。また、直通通信送信は、2基のユーザ機器間で直接確立される接続に使用される用語である「直接サイドリンク接続」を通じて行われる。例えば3GPPでは、D2D(装置間)通信、またはProSe通信、またはサイドリンク通信という専門用語が使用される。本特許請求の範囲および本出願において使用されている「直接サイドリンク接続」という用語は広義に理解されるべきであり、3GPPの文脈では、背景技術のセクションに記載したPC5インタフェースを意味するものと理解することができる。
本出願において使用されている「ProSe」または、その非短縮形の「近傍サービス」という用語は、背景技術のセクションで例示的に説明したようにLTEシステムにおける近接性に基づくアプリケーションおよびサービスとの関連で用いられる用語である。「D2D」等の他の専門用語も、上記関連において使用され、近接サービスのための装置間通信を意味する。さらに、請求項では、「サイドリンクデータ」または「サイドリンク宛先」のような本特許請求の範囲の全体で使用される全般的な専門用語との一貫性のために「サイドリンク論理チャネル」という用語が使用される。「サイドリンク論理チャネル」は、近傍サービス/D2Dのために設定される論理チャネルである。
本特許請求の範囲および本出願において使用されている「サイドリンクディスカバリに参加する」という表現は、ProSe対応UEが他のProSe対応UEを(例えば、UEがディスカバリメッセージをブロードキャストすることによって)発見する手順およびProSe対応UEが他のProSe対応UEによって(例えば、ディスカバリメッセージのリスニングを行うことによって)発見される手順を含むものと広義に理解されたい。
背景技術のセクションで説明したように、3GPP標準化団体は、キャリア間ディスカバリ性能を高めるために、受信用サイドリンクディスカバリギャップと送信用サイドリンクディスカバリギャップとを区別しつつ、サイドリンクディスカバリギャップを導入することを決定した。これらのサイドリンクディスカバリギャップの時間においては、アップリンクおよびダウンリンクのパケット通信動作は、受信用サイドリンクディスカバリギャップにおいてUEがダウンリンクチャネルを受信することができない点、および送信用サイドリンクディスカバリギャップにおいてアップリンクパケット送信を行うことができない(例えば、送信用サイドリンクディスカバリギャップに関し、UEが実際にサイドリンク送信ギャップを使用していることを想定している)点で制限されている。
したがって、UuインタフェースにおけるeNBへのアップリンク送信動作が、新たに導入されたサイドリンクディスカバリギャップと衝突する。アップリンク送信動作は、サイドリンクディスカバリギャップについて現在構想されている最小時間が40msであることを考慮すると悪化する。同期式のアップリンクHARQ動作の、後の各(再)送信機会の間のラウンドトリップタイムが8msであるため、時間長が40msのサイドリンクディスカバリギャップは相対的に長く、場合によってはアップリンクHARQ動作の少なくとも最大5回の(再)送信機会を妨げる。これについては、以下にさらに詳細に説明する。
UEは、データパケット(例えば、MAC PDU)の最初の送信および再送信を制御するために、(再)送信プロトコル(例えば、HARQ)を実行する。UEは、アップリンク送信を行ってから4ms後に同期方式で送信プロトコルのフィードバック(ACK/NACK)(および、場合によっては対応するULグラント)を受信する。今度は、新規データパケットのさらなる送信(例えば、新規アップリンク送信のための、切り替えられた新規データインジケータを有するアップリンクグラントが受信される場合)、または以前に受信されたデータパケットの再送信(例えば、切り替えられた新規データインジケータを有しないアップリンクグラントが受信された場合)を、PHICHを介してHARQフィードバックを受信してから4ms後に行うことができる。
Uuインタフェースにおけるレガシーアップリンク送信プロトコル動作は、少なくとも2つの方法でサイドリンクディスカバリギャップと衝突する場合がある。第1に、UEは、異なるキャリアの他のUEのサイドリンクディスカバリメッセージを監視する必要がある受信用サイドリンクディスカバリギャップにおいて、HARQフィードバック(すなわち、PHICH)または(適応再送信または新規の最初の送信をトリガする)PDCCHを受信することができない。UEのHARQプロセス用のHARQバッファが空でない場合(すなわち、HARQバッファが依然として以前送信したデータパケットを含んでいる場合)、UEは、自律的にHARQバッファ内の該データの再送信をトリガする。しかしながら、このトリガされた再送信は、UEが該データパケットの先の最初の送信または再送信についてのHARQフィードバックとしてeNodeBからNACKを受信した場合にUEの物理レイヤに指示されるのみである。すなわち、対応するHARQフィードバックがACKである場合は、再送信は行われない。現在定義されている規格である非特許文献2(バージョン13.0.0)の5.4.2.2節によれば、UEは、受信サイドリンクディスカバリギャップによって妨げられたHARQフィードバックをACKであると想定することによって、対応するHARQプロセスを保留状態にする(例えば、関連付けられたHARQバッファはフラッシュされない)。その結果、UEは、空ではないHARQバッファに起因して最初はデータパケットの再送信(4ms後に行われる)をトリガするが、対応するHARQプロセスの保留状態(すなわち、フィードバックはNACKではなくACKであったこと)を考慮して再送信を実行しない。
第2に、UEは、送信用サイドリンクディスカバリギャップにおいて、特にUEがこの送信サイドリンクディスカバリギャップを実際に使用して対応するサイドリンクディスカバリチャネル(SL−DCH)で送信を行う時、UEは再送信を実行することができない。規格の定義にあるように、サイドリンクディスカバリのいかなる送信もPUSCHでのアップリンクにおける(再)送信に優先される。具体的には、現在定義されている規格である非特許文献2(バージョン13.0.0)の5.4.2.2節によれば、TTIに送信用サイドリンクディスカバリギャップが設定されていない場合、または、TTIに送信用サイドリンクディスカバリギャップが設定されているのであれば、このTTIに一般的なサイドリンクディスカバリに関する送信のために設定されたグラントがない場合にのみ、HARQプロトコルは、HARQエンティティが物理レイヤに送信を生成するように指示することができるようにする。
要するに、UEにおける送信プロトコルの動作およびサイドリンクディスカバリギャップの規定が様々なサブフレームにおいて衝突しうるため、UEは、様々な(再)送信機会を使用することができなくなる。
それにもかかわらず、送信プロトコルの動作では、送信プロトコルによって再送信がトリガされるたびに、再送信が実際は行われるか否かとは無関係にデータパケットの送信カウンタを増加する処理が規定されている。具体的には、3GPPの規格である非特許文献2(現在のバージョン13.0.0)の5.4.2.2節から明らかなように、再送信が要求される場合に、この送信を実際に生成するかは依然として他の状況(例えば、HARQフィードバックがNACKであること、または送信用サイドリンクディスカバリギャップが存在しかつ使用されていること)に依存し、送信カウンタ(COUNTER_TX_NB)は、第1の手順処理において増加される。
同様に、UEは、送信プロトコルによってデータパケットの再送信がトリガされるたびに、サイドリンクディスカバリギャップとの衝突が理由で該再送信が行われない場合でも該データパケットに関連付けられた送信カウンタを増加する。したがって、送信カウンタは、その限度(データパケットについて許容された送信の最大回数)に達しうるため、HARQバッファがフラッシュされ(すなわち、空にされ、内容が削除され)、データパケットが失われる。さらに、RLC AMモードにおける外部RLC ARQ手順がそのようなデータパケット損失からのリカバリの役割を担っているため、例えば、失われたデータパケットを識別しRLC状況報告を送信する受信側エンティティによって後にトリガされる。
RLC再送信を行うことは、第1に、データパケットの再送信(HARQ動作後に受信が成功しなかった)が検出され、次いでRLC状況報告によって要求される必要があることを考慮するとコストがかなり大きい。これにより、追加的な遅延が発生する。さらに、UEは、送信が成功しなかった対応するRLC PDUを含むMAC PDUを形成するために再びLCP手順を行う必要がある。
本発明者は、上述した課題の1つまたはいくつかを緩和するため、以下の例示的な実施形態を着想した。
さまざまな実施形態の特定の実装形態は、3GPP標準規格によって与えられる、一部が背景技術のセクションで説明されている幅広い仕様の中で実施され、特に重要な特徴は、さまざまな実装形態に関連して以下に説明するように追加される。なお、これらの実施形態は、例えば、背景技術のセクションで説明した3GPP LTE−A(リリース10/11/12/13)などの移動通信システムにおいて有利に使用することが可能であるが、これらの実施形態はこの特定の例示的な通信ネットワークでの使用に限定されないことに留意されたい。
以下の説明は、本開示の範囲を制限するものとしてではなく、本開示を深く理解するための実施形態の単なる例として理解されたい。当業者には、請求項に記載されている本開示の一般的な原理を、さまざまなシナリオに、本明細書に明示的には記載されていない方法で適用できることが認識されるはずである。説明を目的として、いくつかの想定がなされているが、これらの想定は以下の実施形態の範囲を制限するものではない。
さらには、上述したように、以下の実施形態は3GPP LTE−A(リリース12/13)環境において実施されうるが、今後のリリースにおいても実施されうる。さまざまな実施形態は、主として、サイドリンクディスカバリ手順にも参加するProSe対応UEのための改良されたアップリンクHARQ送信プロトコルの動作、および特にサイドリンクディスカバリギャップと(再)送信動作との調整を提供する。したがって、他の機能(すなわちさまざまな実施形態によって変更されない機能)は、背景技術のセクションで説明したものとまったく同一のままであってもよいし、さまざまな実施形態に影響することがないように変更してもよい。他の機能としては、サイドリンク接続を介してサイドリンクデータを送受信するためにUEによって行われるサイドリンク送信手順だけでなく、サイドリンクディスカバリギャップの設定およびサイドリンクディスカバリギャップがUEによって制御される方法を含む、UEをProSeに対応するように設定する手順のような他のProSe機能が含まれる。さらに、関連する規格に現在定義され、例示的に背景技術のセクションにおいて説明されたHARQエンティティ、HARQプロセスおよび対応する送信カウンタ等を含む、UEの送信プロトコル(例えばMAC HARQやRLC ARQ)を通常通り設定することができる。
[第1の実施形態]
以下では、前述した(1つまたは複数の)課題を解決するための第1の実施形態について詳しく説明する。第1の実施形態のさまざまな実装形態および変形形態も説明する。
例として、例えば、自身のサービング基地局にキャリア(例えばPCell)を通じてPUSCHを介してアップリンクデータパケット送信を行うユーザ端末が想定されている。UEは、少なくとも1つの(再)送信プロトコル(例えばMAC HARQプロトコル)を実行して、MAC PDU(データパケットまたはトランスポートブロックともいう)の送信および再送信を制御する。対応するHARQエンティティおよびHARQプロセスが通常の方式でUEに設定される。本明細書に記載された実施形態については、送信HARQエンティティおよび対応するHARQプロセスは関連している。アップリンクにおける送信および再送信は、UEのHARQ送信プロトコルに制御される。送信カウンタが、各HARQプロセスに設定されることにより、そのHARQプロセスにより提供されたデータパケットが既に送信された送信回数が記録される。任意選択的に、送信カウンタが特定のデータパケットの送信の最大回数に達した場合に、送信カウンタを使用してHARQプロセスバッファをフラッシュすることができる(したがって、HARQプロセスバッファに格納されたデータパケットを削除することができる)。概して、送信プロトコルの動作(例えば、データパケットの最初の送信をいつ行うか、データパケットの再送信をいつ行うか)は、一般にeNBの制御下にある。eNBの制御は、例えば、新規送信または再送信のためにHARQフィードバックPHICHを介して、および/またはアップリンクグラントをPDCCHを介してUEに送信することによって行われる。第1の実施形態の特定の実装例によれば、背景技術のセクションにおいて説明したHARQプロトコルが使用される。HARQプロトコルは、規格である非特許文献2の、特に、下記に説明するように特定の変更を加えた5.4.2節「HARQ動作」に従っている。
任意選択的に、UEは、上位レイヤ(例えば、RLC)においてさらなる(再)送信プロトコルを実行することによって、下位レイヤのMACレイヤでのHARQプロトコル動作中に生じるエラー(例えば、NACK−to−ACKエラーや損失データパケット)からのさらなるリカバリを行ってもよい。第1の実施形態の特定の実装例によれば、背景技術のセクションにおいて説明したようなRLC再送信プロトコル動作を使用することができる。
さらに、想定される例示的なシナリオにおいては、ユーザ機器は、ProSe通信を行うことができる(ProSe対応UE)、すなわち、UEとUEとの間で直接、eNodeBを介した迂回なく、それぞれのサイドリンク接続を介して直接D2D送信を行うことができる。また、ProSe通信では、ProSe対応UEは必然的に他のProSe対応UEとのサイドリンクディスカバリオペレーションに参加する。すなわち、サイドリンクディスカバリオペレーションへの参加は、事前に定義されたサイドリンクディスカバリ信号を交換して自身の近傍にいる他のProSe対応UEを判定し、かつ/または他のProSe対応UEに対して可視であることによって行われる。背景技術のセクションにおいて説明したモデルA(「私はここです」)やモデルB(「そこにいるのは誰ですか?」/「あなたはそこにいますか?」)等の様々なサイドリンクディスカバリモデルを定義することができる。いずれの場合であっても、一般的なままであるために、サイドリンクディスカバリオペレーションに(使用される特定のディスカバリモデルとは無関係に)参加するために、UEは、サイドリンクチャネルを通じてサイドリンクディスカバリメッセージを(例えば、他のProSe対応UEを発見するために)送信することができるべきであり、かつ、サイドリンクチャネルを監視し、他のUEから送信されたサイドリンクディスカバリメッセージを(例えば、他のProSe対応UEによって発見されるために)受信することができるべきである。
さらに、PUSCH(例えば、PCell)を介してアップリンク送信を行うために使用されるセルとは別のセルでサイドリンク直接ディスカバリが動作するように、キャリア間ProSe動作がサポートされることが例示的に想定されている。例えば、UEは、非サービングキャリアおよび/またはセカンダリセルにおいてサイドリンクディスカバリオペレーションを行うように設定されている。したがって、UEは、ProSe用の改良された直接ディスカバリをサポートしなければならない。
改良されたサイドリンクディスカバリを支援するために、UEにサイドリンクディスカバリギャップ(すなわち、受信用サイドリンクディスカバリギャップおよび/または送信用サイドリンクディスカバリギャップ)がさらに設定されることが想定される。なお、UEに送信用および受信用のサイドリンクディスカバリギャップの一方のみが設定されるシナリオにも第1の実施形態を同様に適用することができる。また、UEに送信用および受信用のサイドリンクディスカバリギャップの両方が設定されるシナリオにも第1の実施形態を同様に適用することができる。背景技術のセクションにおいて例示的に説明したように、UEの送信動作/受信動作は、サイドリンクディスカバリギャップにおいて制限されている。特に、受信サイドリンクディスカバリギャップにおいて、UEは、ダウンリンクチャネルを受信することができない(但し、ランダムアクセス手順の間を除く。しかしながら、ランダムアクセス手順が本願の各実施形態の機能と関連しないため、以下では無視する)。一方、送信サイドリンクディスカバリギャップにおいて、UEは、PUSCHでの他の「通常の」アップリンク(再)送信に対してあらゆるサイドリンクディスカバリ送信を優先する(すなわち、UEは、既にサイドリンクディスカバリメッセージ送信を行っている場合、または自身のRFユニットを再チューニングする場合、送信サイドリンクディスカバリギャップにおいてHARQ(再)送信を行うことができない)。しかしながら、UEが送信サイドリンクディスカバリギャップにおいてサイドリンクディスカバリ送信を行わなければ、UE送信プロトコルの動作は妨げられないため、UEはアップリンクにおけるHARQ(再)送信を実際に行うことができる。
第1の実施形態によれば、HARQプロトコル動作と、サイドリンクディスカバリギャップを使用したサイドリンクディスカバリオペレーションとの調整は、以下に説明するように最適化される。第1の実施形態では、トリガされた再送信がサイドリンクディスカバリの並行動作およびサイドリンクディスカバリギャップが理由で行われない場合を判定することができるUEが提供される。そのような衝突が生じたとUEが判定する場合(すなわち、トリガされた再送信がサイドリンクディスカバリ並行動作のおよびサイドリンクディスカバリギャップが理由で行われないと判定する場合)、UEは、トリガされたが「妨げられた」再送信がHARQ送信カウンタをインクリメントしないようにデータパケットの対応するHARQ送信カウンタを動作させる。言い換えると、再送信がHARQプロトコルによってトリガされたとしても、該再送信は、該データパケットのさらなる(再)送信と見なされない(すなわち、送信カウンタは該データパケットについてはインクリメントされない)。
第1の実施形態のより具体的な変形形態を以下に記載する。HARQ動作とサイドリンクディスカバリギャップに基づいたサイドリンクディスカバリオペレーションとの衝突には様々な理由がありえる。したがって、以下に説明するように、UEは、それぞれが個別にデータのHARQ再送信との衝突の原因でありうる送信サイドリンクディスカバリギャップおよび受信サイドリンクディスカバリギャップを識別しつつ、様々な衝突を検出する。
受信サイドリンクディスカバリギャップにおいて、UEは、他のダウンリンクチャネルの受信が妨げられる。これらのダウンリンクチャネルの受信には、以前送信したデータパケットのPHICHを介したHARQフィードバックの受信、またはアップリンク再送信(例えば、適応再送信)をスケジューリングするためのDCIを含むPDCCHの受信が含まれる。しかしながら、通常、HARQフィードバックは、例えば、受信データの復号がeNodeBにおいて成功しなかった場合に、非適応再送信を行うようにUEを指示するためにeNBによって使用される。例えば、NACKをHARQフィードバックとして送信することによって、送信プロトコルが再送信(より具体的には、非適応再送信)を行うことになる。したがって、受信サイドリンクディスカバリギャップにおいてHARQフィードバックを受信できないことによって、HARQ動作が妨げられるため、UEは対応するアップリンク再送信を行わない。したがって、UEは、そのような衝突を監視・識別するものとする。適応再送信を行うようにUEに指示するPDCCHの受信についても同様である。
送信サイドリンクディスカバリギャップにおいては、アップリンクにおける送信よりもサイドリンクディスカバリ送信が優先されるため、UEは、実際にアップリンクにおける送信を行うことが妨げられうる。アップリンクにおける送信には、HARQプロトコルにしたがって行われるあらゆる送信または再送信が含まれる。換言すれば、UEがサブフレーム内でサイドリンクディスカバリメッセージ送信を行う場合、UEはHARQ再送信を同時に行うことができない。したがって、再送信がHARQプロトコルにおいて(例えば、再送信を要求する明示的なアップリンクグラントを受信することによって)トリガされる場合でも、UEは、送信サイドリンクディスカバリギャップにおける対応するサイドリンクディスカバリオペレーションによって妨げられていることによりこの再送信を実行しない。したがって、UEは、そのような衝突を監視・識別するものとする。
異なる2種類の衝突を上述した。UEは、これらをいずれも監視することにより、送信カウンタを制御する。具体的には、最初は再送信がHARQプロトコルにおいてトリガされたとしても(すなわち、eNBによって指示されたとしても)、送信カウンタは、そのような衝突によって増加されない。
対応するデータパケットの送信カウンタが、妨げられた再送信によって増加されないことを保証するために、次の2つの実装例を提供することができる。
現在の懸案中の規格によれば、HARQプロトコル動作では、データパケットの再送信がトリガされるたびに該データパケットについてHARQ送信カウンタをインクリメントする処理が規定されている。第1の実施形態の1つのオプションによれば、送信カウンタを増加するこの処理は、さらに衝突が検出されたかに応じて行われる。その結果、トリガされた再送信と(送信用または受信用の)サイドリンクディスカバリギャップとの衝突をUEが検出した場合、送信カウンタをインクリメントする処理は行われない。
図8は、第1の実施形態の上記オプションの実装例に係るユーザ端末のProSe動作のありうるシーケンス図を例示的に示す。このシーケンス図から明らかように、送信カウンタをインクリメントする処理は、データパケットの対応する送信がトリガされた後、トリガされた再送信とサイドリンクディスカバリギャップとの衝突が検出されるかに直接依存する。衝突が検出されない場合、送信カウンタをインクリメントすることができ、対応する送信を行うことができる。送信カウンタをインクリメントする処理と、再送信を行う処理との順序は、変更可能であるか、または、これらの処理を並行して行うことができる。
背景技術のセクションにおいて説明したLTE規格による実装例では、この第1のオプションを以下のように実施することができる。例えば、送信用および/または受信用のサイドリンクディスカバリギャップの発生によりUL−SCH送信を行うことができない場合、CURRENT_TX_NBが増加されないことを明確にする補足的な注記を付してもよい。そのような注記を、例えば、非特許文献2の5.4.2.2節に追加することができる。
第1の実施形態の他のオプションによれば、第1のオプションに関する送信カウンタをインクリメントする処理を適合する代わりに、この第2のオプションは、衝突が検出される場合に、データパケットについて送信カウンタをデクリメントする追加処理を導入することに基づいている。したがって、再送信のトリガリングによって送信カウンタがインクリメントされるとしても、衝突がある場合に該データパケットについて送信カウンタをデクリメントする追加処理を規定することによって、送信カウンタは、結局、妨げられた再送信によってはインクリメントされない。このため、妨げられた再送信は、データパケットの送信とは見なされない。
図9は、第1の実施形態の上記第2のオプションの実装例に係るユーザ端末のProSe動作のありうるシーケンス図を例示的に示す。図8に示される第1のオプションとの違いが容易に明らかとなるであろう。送信カウンタをインクリメントする処理は、データパケットの再送信をトリガする際に行われるため、再送信とサイドリンクディスカバリギャップとの衝突が検出されるかに影響されない。一方、そのような衝突が検出される場合、送信カウンタはデクリメントされる。
背景技術のセクションにおいて説明したLTE規格に係る実装例では、この第2のオプションは、以下の『』の行を非特許文献2の5.4.2.2節の対応するHARQ動作に加えることにより実現することができる。
――――――――――
5.4.2.2 HARQプロセス
…
上記動作を行った後、次いで、HARQプロセスは、
『送信用または受信用のサイドリンクディスカバリギャップの発生によりUL−SCHでの再送信を行うことができない場合、
− CURRENT_TX_NB=CURRENT_TX_NB-1』
− CURRENT_TX_NB=最大送信回数−1である場合、
− HARQバッファをフラッシュする。
――――――――――
その結果、上述のようにUEが、トリガされた再送信の衝突を送信カウンタの動作のために考慮するため、妨げられた再送信によって送信カウンタがインクリメントされなくなる。その結果、UEが再送信を行う対応する機会を失わなくなるため、可能性としては、受信側がデータパケットを復号することができるようになる。したがって、設定されたサイドリンクディスカバリギャップによって発生したデータパケット損失を減少することができ、また、外部RLC ARQを使用する対応の誤り訂正が必要にならない。
第1の実施形態によれば、eNodeBも、ProSe対応UEについて説明したばかりの方式に対応する方式で適合されるものとする。UEにおける送信プロトコルの制御下におけるデータ送信の受信機であり、かつUEのスケジューリングを行う役割を担うエンティティであるeNodeBも、UEと同様の方式で送信プロトコルの動作を記録する。したがって、eNodeBも、UEの送信プロトコルの動作とサイドリンクディスカバリオペレーションとの起こりうる衝突を監視することにより、UEが上記のような妨げられたデータパケットを再送信することによって送信カウンタがインクリメントされないようにeNodeB内の送信カウンタを動作させる。これにより必然的に、eNodeBは、UEについて上述した衝突と同一の種類の衝突を監視することになる。したがって、同一のデータパケットについてのUEの送信カウンタおよびeNBの対応する送信カウンタは、同期される。
第1の実施形態のさらなる実装によれば、測定用ギャップにおけるアップリンクHARQプロトコル動作の調整が説明される。背景技術のセクションにおいて説明したように、UEは、eNodeBがUEに設定する測定用ギャップにおいて特定の測定(例えば、モビリティ測定)を行うことができる。サイドリンクディスカバリギャップの場合と同様に、アップリンクHARQ送信プロトコル動作は、UEが測定用ギャップにおいてeNodeBからダウンリンクチャネルを受信することができない点、および、測定用ギャップにおいてeNodeBにアップリンク送信を行うことができない点でこれらの測定用ギャップによって制限されている。例えば、規格である非特許文献2の現在定義されたHARQプロトコル動作によれば、UEは、測定用ギャップとの衝突によりPHICHを介した予期していたHARQフィードバックを受信することができなかった場合、ACKを受信したと考える。
しかしながら、HARQプロトコル動作とサイドリンクディスカバリギャップとの調整とは対照的に、UEは、再送信が測定用ギャップによって実際には妨げられたか否かとは無関係に、データパケットの再送信がHARQプロトコルによってトリガされる場合に必ず該データパケットについて送信カウンタを増加する。その結果、後に測定用ギャップによって妨げられる、データパケットのトリガされた再送信は、サイドリンクディスカバリギャップによって妨げられたトリガされた再送信とは対照的に送信カウンタをインクリメントする。これにより、サイドリンクディスカバリギャップより時間長が非常に小さい測定用ギャップに関するHARQプロトコルの動作は単純化される。測定用ギャップがHARQプロセスの1つのHARQ(再)送信機会を妨げるのみである(すなわち、測定用ギャップが7msであるのに対し、HARQ RTTは8msである)からである。したがって、単純なHARQプロトコル動作においてこの1つのHARQ送信機会を失うことは、許容可能である。すなわち、UL HARQ送信および測定用ギャップの衝突をUE側およびeNB側で検出する必要はない。
[第2の実施形態]
以下、第1の実施形態によって解決されたものと同一の課題(すなわち、発明を実施するための形態の初めに説明した課題)を扱う第2の実施形態を提示する。
第2の実施形態についても第1の実施形態についての想定と同一の想定をすることができる。簡潔に言うと、UEは対応するHARQエンティティおよびHARQプロセスを有するMAC HARQプロトコルを実行することにより、MAC PDU(データパケットまたはトランスポートブロックともいう)の送信および再送信を制御することが想定される。送信カウンタが各アップリンクHARQプロセスに設定され、UEには、この送信カウンタおよびHARQプロセスによって提供されるデータパケットの許容可能最大送信回数を示す最大カウンタ値が設定される。送信カウンタにおいてこの許容可能最大送信回数に達すると、HARQプロセスの対応するバッファがフラッシュされる。UEは、PHICHを介してアップリンクHARQプロトコル動作におけるフィードバックを受信し、かつ/またはPDCCHを介してアップリンクグラントを受信する。第2の実施形態の特定の実装例も、背景技術のセクションにおいて説明したHARQプロトコルに基づいていてもよい。HARQプロトコルは、規格である非特許文献2の、特に下記に説明するように特定の変更を加えた5.4.2節「HARQ動作」に従っている。この場合、パラメータmaxHARQ-Txは、送信カウンタに関して使用されるデータパケットの許容可能最大送信回数を示す。
任意選択的に、UEは、上位レイヤ(例えば、RLC)においてさらなる(再)送信プロトコルを実行することによって、下位レイヤのMACレイヤでのHARQプロトコル動作中に生じるエラー(例えば、NACK−to−ACKエラーや損失データパケット)からのさらなるリカバリを行ってもよい。第2の実施形態の特定の実装例によれば、背景技術のセクションにおいて説明したようなRLC再送信プロトコル動作を使用することができる。
さらに、UEがProSe対応であり、事前に定義されたサイドリンクディスカバリ信号を交換することによって、他のProSe対応ユーザ端末とのサイドリンクディスカバリオペレーションに参加することが想定されている。さらに、例として、第1の実施形態について既に詳細に説明したようにサイドリンクディスカバリギャップ(受信用サイドリンクディスカバリギャップおよび/または送信用サイドリンクディスカバリギャップ)を設定することによって、キャリア間ProSe動作がサポートおよび支援されることが想定されている。つまり、サイドリンクディスカバリギャップがUEの送信動作/受信動作を制限することになる。
ここで、第2の実施形態に係るHARQプロトコル動作とサイドリンクディスカバリオペレーションとの最適化された調整を、上記の例示的な想定に基づいて説明する。規格において現在規定されるように、データパケットの再送信がトリガされるたびに該データパケットについて送信カウンタをインクリメントするHARQプロトコルに規定された処理が、再送信が実際に行われるか、サイドリンクディスカバリオペレーションによって妨げられるかとは無関係に実際に行われる。第1の実施形態の複数の変形形態のように、UEは、HARQプロトコル動作とサイドリンクディスカバリオペレーションとの衝突が発生する場合を判定することができる。すなわち、UEは、トリガされた再送信がサイドリンクディスカバリの並行動作および対応するサイドリンクディスカバリギャップが理由で行われない場合を判定する。
そのような衝突がUEによって検出される場合、第2の実施形態に係るHARQプロトコル動作では、再送信がサイドリンクディスカバリギャップと衝突したデータパケットの対応する送信カウンタを動作させるために、増加した許容可能最大送信回数を使用するさらなる処理が規定されている。したがって、許容可能最大送信回数の増加によって、データパケットの、トリガはされたが妨げられた再送信による送信カウンタのインクリメントが補償される。
図10は、第2の実施形態に係るUEの動作のためのシーケンス図を例示する。図10から明らかなように、送信カウンタは、データパケットの再送信がトリガされるとインクリメントされる。一方、衝突が検出される場合、許容可能最大送信回数の値(すなわち、最大送信限度)は増加され、送信カウンタの後の動作に適用される。
第2の実施形態のより具体的な変形形態を以下に記載する。第1の実施形態に関して既に説明したように、HARQ動作とサイドリンクディスカバリオペレーションとの衝突は、少なくとも2つの異なる理由で発生する場合があり、UEは、これらの衝突を監視および検出することができなければならない。
つまり、受信サイドリンクディスカバリギャップにおいて、UEは、他のダウンリンクチャネルの受信が妨げられる。これらのダウンリンクチャネルの受信には、以前送信したデータパケットのPHICHを介したHARQフィードバックの受信、および/またはアップリンク再送信(例えば、適応再送信)をスケジューリングするためのDCIを含むPDCCHの受信が含まれる。したがって、受信サイドリンクディスカバリギャップにおいてHARQフィードバックを受信できないことによって、HARQ動作が妨げられるため、UEは対応するアップリンク再送信を行わない。したがって、UEは、そのような衝突を監視・識別する。送信サイドリンクディスカバリギャップにおいては、アップリンクにおける送信よりもサイドリンクディスカバリ送信が優先されるため、UEは、実際にアップリンクにおける送信を行うことが妨げられうる。アップリンクにおける送信は、HARQプロトコルにしたがって行われるあらゆる送信または再送信である。したがって、UEは、そのような衝突を監視・識別する。
衝突が検出される場合に、特定の送信カウンタの動作に適用されるデータパケットの許容可能最大送信回数を増加する第2の実施形態の様々な実装例がある。
1つのオプションによれば、許容可能最大送信回数のための新規パラメータが使用され、例えば、eNodeBによってUEに設定される。この新規パラメータ(例としてmaxHARQ-TxSLgapとする)は、トリガされたものの、UEによって同時に実行されるサイドリンクディスカバリによって後に妨げられる再送信によって送信カウンタがインクリメントされる状況に適用可能であるように追加的に導入される。eNodeBは、この追加的な衝突用送信カウンタパラメータ(collision-specific transmission counter parameter)を設定・構成する役割を担うことができ、例えば、HARQプロトコル動作を設定する際に(例えば、送信カウンタの動作のための、当初使用されていたパラメータmaxHARQ-Txを提供するのと同時に)UEにこのパラメータを送信することができる。同様に、新規パラメータmaxHARQ-TXSLgapの値を、UEが当初送信カウンタの動作に用いた通常のパラメータmaxHARQ-Txの対応する値より高く設定することができる。ここで、eNodeBが通常のパラメータも、UEがサイドリンクディスカバリを行うために使用するサイドリンクギャップの長さも認識していることに留意されたい。同様に、eNodeBは、サイドリンクディスカバリギャップにおいてサイドリンクディスカバリオペレーションによって妨げられる可能性がある、UEに利用可能な再送信機会の数も認識する。例えば、サイドリンクディスカバリギャップが40msであり、再送信機会が8msごとに生じることを想定すると(図3を参照)、最大5回の再送信機会が妨げられる可能性がある。したがって、eNodeBは、他方の送信カウンタパラメータmaxHARQ-Txの値と比較して、妨げられる再送信機会の数に対応して増加された(例えば、5増加された)値を新規な衝突用パラメータmaxHARQ-TXSLgapとして使用してもよい。
他のオプションによれば、追加的な衝突用パラメータを使用する代わりに、UEは、衝突がある場合に、送信カウンタに適用された許容可能最大送信回数を自身で変更することができる。例えば、UEがトリガされた再送信について発生する衝突を検出する場合、UEは、また、対応する送信カウンタに適用可能な許容可能最大送信回数をインクリメントする(この送信カウンタは、トリガされた再送信により先にインクリメントされている)。図11は、第2の実施形態におけるこのオプションに従ったUEの動作を例示する。図11から明らかなように、衝突の検出時、UEの動作では、送信カウンタの最大送信限度がインクリメントされる(すなわち、送信カウンタを動作させるための以前に設定された許容可能最大送信回数がインクリメントされる)。
いかなる場合も、後にサイドリンクディスカバリギャップと衝突したために実際には行われなかった、トリガされたデータパケット再送信によってインクリメントされた送信カウンタの許容可能最大送信回数が増加されることにより、データパケットの再送信の衝突が原因でHARQバッファがフラッシュされることが回避される。したがって、UEは、サイドリンクディスカバリギャップの後により多くの再送信機会を有するため、受信側エンティティ(すなわち、eNodeB)に首尾よくデータパケットを送信する。
また、第2の実施形態は、先にUEについて説明した方式と同様の方式で適合されるeNodeBを提供する。UEにおける送信プロトコルの制御下におけるデータ送信の受信機であり、かつUEの送信および/または再送信のスケジューリングを行う役割を担うエンティティであるeNodeBも、UEと同様の方式で送信プロトコルの関連部分を実行すべきである。したがって、eNodeBも、UEの送信プロトコルの動作とUEのサイドリンクディスカバリオペレーションとの起こりうる衝突を監視すべきである。したがって、eNodeBも、UEが行ったように、対応する送信カウンタの許容可能最大送信回数を増加する。したがって、同一のデータパケットについてのUEにおける送信カウンタ、およびeNodeBにおける対応する送信カウンタは、同一の方式で動作される。
第1の実施形態に関して既に説明したように、第2の実施形態のさらなる実装には、測定用ギャップにおけるアップリンクHARQプロトコル動作の調整が含まれうる。簡潔に言うと、測定用ギャップが、特定の測定を行うためにUEによって使用される結果、アップリンクHARQ送信プロトコル動作が制限される。例えば、UEは、測定用ギャップにおいてeNodeBからダウンリンクチャネル(例えば、HARQフィードバック)を受信することができない。また、UEは、測定用ギャップにおいてeNodeBにアップリンク送信を行うことができない。
上述の第2の実施形態に係るHARQプロトコル動作とサイドリンクディスカバリギャップとの調整とは対照的に、HARQプロトコルによってデータパケットの再送信がトリガされるたびに、UEは送信カウンタを増加し、トリガされた再送信と測定用ギャップとの衝突が発生したか否かとは無関係に、送信カウンタを動作させるための最初に設定された許容可能最大送信回数を使用し続ける。
したがって、測定用ギャップによって妨げられた、データパケットのトリガされた再送信は、サイドリンクディスカバリギャップによって妨げられたトリガされた再送信とは対照的に送信カウンタの動作を変更しない。上述のように、これにより、サイドリンクディスカバリギャップより時間長が非常に小さい測定用ギャップに関するHARQプロトコル動作が単純化される。
[第3の実施形態]
以下、さらに第1のおよび第2の実施形態によって解決された課題と同一の課題を扱う第3の実施形態を提示する。第3の実施形態についても、第1のおよび第2の実施形態についての想定と同一の想定をすることができる。簡潔に言うと、UEは、対応するHARQエンティティおよびHARQプロセスを有するMACアップリンクHARQプロトコルを実行することにより、MAC PDU(データパケットまたはトランスポートブロックともいう)の送信および再送信を制御することが想定される。送信カウンタが各HARQプロセスに設定され、特に、送信カウンタが許容可能最大送信回数に達する場合にデータパケットのHARQプロセスに関連付けられたバッファをフラッシュするために使用される。UEは、PHICHを介してHARQプロトコル動作におけるフィードバックを受信し、かつ/またはPDCCHを介してアップリンクグラントを受信する。第2の態様の特定の実装例も、背景技術のセクションにおいて説明したMAC HARQプロトコルに基づいていてもよい。MAC HARQプロトコルは、規格である非特許文献2の、特に、下記に説明するようにさらに適合された5.4.2節「HARQ動作」に従っている。
さらに、第3の実施形態における想定では、UEは、上位レイヤ(例えば、RLC)において他の(再)送信プロトコルを実行することによって、下位レイヤのMACレイヤでのHARQプロトコル動作中に生じるエラー(例えば、NACK−to−ACKエラーや損失データパケット)からのさらなるリカバリを行ってもよい。第3の実施形態の特定の実装例によれば、背景技術のセクションにおいて説明したようなRLC再送信プロトコル動作を使用することができる。
さらに、UEがProSe対応であり、事前に定義されたサイドリンクディスカバリ信号を交換することによって、他のProSe対応ユーザ端末とのサイドリンクディスカバリオペレーションに参加することが想定されている。さらに、例として、第1の実施形態について既に詳細に説明したようにサイドリンクディスカバリギャップ(受信用サイドリンクディスカバリギャップおよび/または送信用サイドリンクディスカバリギャップ)を設定することによって、キャリア間ProSe動作がサポートおよび支援されることが想定されている。要するに、サイドリンクディスカバリギャップは、UEの送信動作/受信動作を制限する。
この第3の実施形態は、MAC HARQプロトコル動作を最適化するだけでなくRLC送信プロトコルの動作、MAC HARQプロトコル動作、およびサイドリンクディスカバリオペレーションの調整を最適化する点で第1のおよび第2の実施形態と異なる。第1のおよび第2の実施形態について既に説明したように、UEは、MAC HARQプロトコル動作とサイドリンクディスカバリオペレーションとの衝突を検出することができる。すなわち、UEは、トリガされたHARQ再送信がサイドリンクディスカバリの並行動作およびサイドリンクディスカバリギャップが理由で行われない場合を判定する。MAC HARQプロトコル動作によれば、UEは、再送信が実際に実行されるか、サイドリンクディスカバリオペレーションによって妨げられるかとは無関係に、データパケットの再送信がHARQプロトコルによってトリガされるたびに、該データパケットについて送信カウンタをインクリメントする。
第3の実施形態によれば、UEにおけるサイドリンクディスカバリオペレーションとの衝突により失われたデータパケットのRLC再送信をトリガする新たなトリガが設定される。より具体的には、新たなトリガは、サイドリンクディスカバリギャップとの衝突が原因で行われなかったトリガされた再送信によって送信カウンタがインクリメントされた後にその限度(すなわち許容可能最大送信回数)に達したためにデータパケットを含むHARQバッファがフラッシュされたかに依存する。そのような場合、MACレイヤは、対応するRLCエンティティに対し、HARQ送信バッファからフラッシュされたMAC PDUに含まれていたRLC PDUの再送信をスケジューリングすることをトリガする。したがって、この新たな第3の実施形態によって、新たなMAC/RLC相互作用が導入される。
また、外部RLC送信プロトコルは、損失データパケット(すなわち、RLC PDU)を再送信する役割を担う。背景技術のセクションにおいて説明したように、RLC再送信は、通常、欠けているシーケンス番号に基づいて損失データパケットを検出したかもしれない受信側エンティティから送信機が対応するRLC状況報告を受信する場合に送信機においてトリガされる。
第3の実施形態によれば、RLC再送信のための新たなトリガが定義されている。この新たなトリガによって、例えば、受信側エンティティは、損失データパケットを最初に検出すること、および、それにより対応するRLC状況報告を介してUEにおける対応するRLC AM送信側エンティティに該損失データパケットの再送信を要求することが必要なくなる。この新たなトリガは、送信側で発生する。すなわち、より正確には、MACエンティティは、対応するRLC再送信側エンティティに対して、対応するRLC再送信を行うことをトリガする。
この新たなトリガは、様々な方式で実装されうる。例えば、UEは、サイドリンクディスカバリギャップと衝突したために実際には行われなかったトリガされた再送信が理由で、送信カウンタがインクリメントされたかを記録してもよく、場合によっては、インクリメントされた回数を記録してもよい。この場合、そのような送信カウンタが許容可能最大送信回数に達することによって、対応するHARQバッファがフラッシュされる場合、対応するRLC再送信がトリガされる。1つの変形例では、送信カウンタの衝突によるインクリメントは1回で十分であり、また、他の変形例では、閾値に基づくアプローチを構想することができる。この変形例では、対応する閾値(例えば、3)が設定され、UEは、そのようなトリガされたが妨げられた再送信に起因して送信カウンタがインクリメントされた回数を(例えば、適切なカウンタによって)数える。そして、データパケットに含まれるRLC PDUのRLC再送信は、対応する送信カウンタが許容可能な再送信の最大回数に達することによって、対応するHARQバッファをフラッシュする場合であって、そのようにトリガされたが妨げられた再送信に起因するインクリメントの回数が、かかる再送信に関して以前に設定された衝突閾値以上である場合にのみトリガされる。
他のより単純な実装によれば、データパケット(MAC PDU)に含まれていたRLC PDUのRLC再送信は、HARQバッファがフラッシュされる条件である送信カウンタの最後のインクリメントが、サイドリンクディスカバリギャップにおける対応するサイドリンクディスカバリオペレーションと衝突することにより実際には妨げられるトリガされた再送信によって引き起こされる場合にトリガされる。
現在のLTE標準、特に、現在の規格である非特許文献5(現行のバージョン13.0.0)に基づく第3の実施形態の特定の実施によれば、RLC PDU再送信のための新たなトリガについての記載を5.2.1節に追加することができる。また、新たなトリガは、HARQプロセスのためのHARQプロトコル動作を規定する非特許文献2の5.4.2.2節に含まれうる。ここで、上述の追加的な条件でHARQバッファをフラッシュする際に、UEが、対応するRLCエンティティに対して、MAC PDUに含まれていた対応するRLC PDUの再送信を行うことをこのHARQプロセスで知らせることが規定される。
第1のおよび第2の実施形態に関して既に説明したように、第3の実施形態の実装には、測定用ギャップにおけるアップリンクHARQプロトコル動作の調整が含まれうる。
上述の第3の実施形態に係るRLC再送信を行うための追加のトリガを提供することとは対照的に、トリガされた再送信と測定用ギャップとの衝突に関しては、そのような新たなトリガは予見されない。したがって、送信カウンタが、測定用ギャップによって妨げられたトリガされた再送信によってインクリメントされた後に最大送信限度に達することが理由でHARQバッファがフラッシュされる場合、サイドリンクディスカバリギャップによって妨げられたトリガされた再送信によって送信カウンタがインクリメントされた場合とは異なり、対応するRLC再送信は、HARQバッファがフラッシュされることによってトリガされない。
[さらなる実施形態]
第1の態様によれば、通信システムにおいてアップリンクデータパケット送信のための送信プロトコルを実行する送信側ユーザ端末が提供される。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および/または受信することができない。ユーザ端末は、送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したために行われなかったかを判定するプロセッサを備える。そして、衝突がある場合、プロセッサは、データパケットが衝突する再送信が該データパケットについては送信プロトコルの送信カウンタをインクリメントしないように送信カウンタをさらに動作させる。
第1の態様に加えて提供される第2の態様によれば、ユーザ機器には、送信用サイドリンクディスカバリギャップが設定される。送信用サイドリンクディスカバリギャップにおいて、ユーザ端末は、サイドリンク接続を介して他のユーザ端末にサイドリンクディスカバリメッセージを送信することができる。プロセッサは、送信用サイドリンクディスカバリギャップとの衝突が理由でデータパケットの再送信を行うことができない場合(好ましくは、ユーザ端末が送信用サイドリンクディスカバリギャップにおいてサイドリンクディスカバリメッセージを送信する場合)、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したためにデータパケットの再送信が行われなかったと判定する。追加または代替として、ユーザ端末には、受信用サイドリンクディスカバリギャップが設定される。受信用サイドリンクディスカバリギャップにおいて、ユーザ端末は、サイドリンク接続を介して他のユーザ端末から送信されるサイドリンクディスカバリメッセージを監視する。プロセッサは、データパケットの以前の送信に関する送信プロトコルのフィードバックが受信用サイドリンクディスカバリギャップとの衝突が理由で受信されない場合、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したためにデータパケットの再送信が行われなかったと判定する。
第1のまたは第2の態様に加えて提供される第3の態様によれば、送信プロトコルは、再送信が送信プロトコルによってトリガされる場合に送信プロトコルの送信カウンタを1インクリメントする処理を規定する。プロセッサは、衝突がある場合に、再送信が送信プロトコルによってトリガされる場合に送信カウンタを1インクリメントする処理を行わないことによって、データパケットが衝突する再送信によって該データパケットについて送信カウンタがインクリメントされないように送信プロトコルを実行する。あるいは、プロセッサは、衝突がある場合に、再送信が送信プロトコルによってトリガされる場合に送信プロトコルの送信カウンタを1インクリメントする処理を行い、次いで、送信カウンタを1減少する処理を行うことによって、データパケットが衝突する再送信によって該データパケットについて送信カウンタがインクリメントされないように送信プロトコルを実行する。
第1の態様から第3の態様の1つに加えて提供される第4の態様によれば、データパケットの再送信は、送信プロトコルと関連付けられたバッファが空ではなく(また、データパケットについて否定的再送信フィードバックが保留されており)、かつ/または、以前送信したデータパケットを再送信するためのアップリンクグラントを基地局から受信する場合に送信プロトコルにしたがってトリガされる。
第1の態様から第4の態様の1つに加えて提供される第5の態様によれば、ユーザ端末は、送信プロトコルにしたがったデータパケットの送信および再送信とは異なる周波数キャリアでサイドリンクディスカバリに参加している。
第1の態様から第5の態様の1つに加えて提供される第6の態様によれば、ユーザ端末には、データパケットの許容可能最大送信回数が設定される。送信プロトコルは、送信カウンタがデータパケットの許容可能最大送信回数の限度に達する場合に送信プロトコルの該データパケットを格納するバッファをフラッシュする処理を規定する。
第1の態様から第6の態様の1つに加えて提供される第7の態様によれば、ユーザ端末には、ユーザ端末がチャネル測定を行うことができる少なくとも1つの測定用ギャップが設定される。ユーザ端末は、測定用ギャップにおいて、送信プロトコルの制御下における信号を送信および/または受信することができない。プロセッサは、送信プロトコルによってトリガされた再送信が、送信プロトコルの動作が測定用ギャップと衝突したために行われなかった場合に、該データパケットについて送信プロトコルの送信カウンタを1インクリメントするように設定される。
第8の態様によれば、通信システムにおいてアップリンクデータパケット送信のためのプロトコルを実行するユーザ端末が提供される。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末には、データパケットの許容可能最大送信回数を設定する第1の送信カウンタパラメータが送信カウンタの動作のために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および/または受信することができない。ユーザ端末は、データパケットの再送信が送信プロトコルによってトリガされる場合に、該データパケットについて送信カウンタをインクリメントするプロセッサを備える。プロセッサは、データパケットのトリガされた再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したために行われなかったかをさらに判定する。そして、衝突がある場合、プロセッサは、データパケットの送信カウンタの動作のために第2の送信カウンタパラメータを使用することによって送信カウンタのためにデータパケットの許容可能最大送信回数を増加する。
第8の態様に加えて提供される第9の態様によれば、ユーザ端末には、基地局によって、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したために行われなかったデータパケットの再送信のトリガリングによってインクリメントされた送信カウンタに適用可能な第2の送信カウンタパラメータが設定される。任意選択的に、第2の送信カウンタパラメータは、第1の送信カウンタパラメータによって示されるデータパケットの許容可能最大送信回数より大きいデータパケットの許容可能最大送信回数を示し、この増加は、サイドリンクディスカバリギャップの長さに依存する。
第8の態様に加えて提供される第10の態様によれば、第2の送信カウンタパラメータは、プロセッサが衝突を判定するたびに第1の送信カウンタパラメータをインクリメントすることによってユーザ端末によって生成される。
第8の態様から第10の態様に加えて提供される第11の態様によれば、送信プロトコルは、送信カウンタが第1のまたは第2の送信カウンタパラメータによって設定された許容可能最大送信回数に達する場合に、送信プロトコルのデータパケットを格納するバッファをフラッシュする処理を規定している。
第8の態様から第11の態様に加えて提供される第12の態様によれば、ユーザ機器には、送信用サイドリンクディスカバリギャップが設定される。送信用サイドリンクディスカバリギャップにおいて、ユーザ端末がサイドリンク接続を介して他のユーザ端末にサイドリンクディスカバリメッセージを送信することができる。プロセッサは、送信用サイドリンクディスカバリギャップとの衝突が理由でデータパケットの再送信を行うことができない場合(好ましくは、ユーザ端末が送信用サイドリンクディスカバリギャップにおいてサイドリンクディスカバリメッセージを送信する場合)、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したためにデータパケットの再送信が行われなかったと判定する。追加または代替として、ユーザ端末には、受信用サイドリンクディスカバリギャップが設定される。受信用サイドリンクディスカバリギャップにおいて、ユーザ端末は、サイドリンク接続を介して他のユーザ端末から送信されるサイドリンクディスカバリメッセージを監視する。プロセッサは、データパケットの以前の送信に関する送信プロトコルのフィードバックが受信用サイドリンクディスカバリギャップとの衝突が理由で受信されない場合、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したためにデータパケットの再送信が行われなかったと判定する。
第13の態様によれば、通信システムにおいてユーザ端末からアップリンクデータパケット送信を受信する基地局が提供される。ユーザ端末は、アップリンクデータパケット送信のための送信プロトコルを実行し、データパケットについてユーザ端末が行った送信の回数を数える第1の送信カウンタがユーザ端末の送信プロトコルのために構成されている。ユーザ端末がデータパケットについて行った送信回数を数える第2の送信カウンタが、基地局に設定される。ユーザ端末は、サイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように基地局によって設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および/または受信することができない。基地局は、ユーザ端末の送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したためにユーザ端末によって行われなかったかを判定するプロセッサを備える。そして、衝突がある場合、プロセッサは、データパケットが衝突する送信が該データパケットについては送信プロトコルの第2の送信カウンタをインクリメントしないように第2の送信カウンタを動作させる。
第14の態様によれば、通信システムにおいてアップリンクデータパケット送信のためのユーザ端末における送信プロトコルを実行する方法が提供される。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および/または受信することができない。本方法には、送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したために行われなかったかをユーザ端末が判定するステップが含まれる。衝突がある場合、ユーザ端末は、データパケットが衝突する再送信が該データパケットについては送信プロトコルの送信カウンタをインクリメントしないように送信カウンタを動作させる。
第14の態様に加えて提供される第15の態様によれば、送信プロトコルは、再送信が送信プロトコルによってトリガされる場合に送信プロトコルの送信カウンタを1インクリメントする処理を規定する。データパケットが衝突する再送信がデータパケットの送信カウンタをインクリメントしないように送信プロトコルを実行するステップでは:
・ 衝突がある場合、再送信が送信プロトコルによってトリガされる場合に送信カウンタを1インクリメントするステップを行わない、または、
・ 衝突がある場合、再送信が送信プロトコルによってトリガされる場合に送信プロトコルの送信カウンタを1インクリメントするステップを行い、かつ、次いで送信カウンタを1減少させるステップを行う。
第14の態様または第15の態様に加えて提供される第16の態様によれば、ユーザ端末には、ユーザ端末がチャネル測定を行うことができる少なくとも1つの測定用ギャップが設定される。ユーザ端末は、測定用ギャップにおいて、送信プロトコルの制御下における信号を送信および/または受信することができない。本方法は、送信プロトコルによってトリガされた再送信が、送信プロトコルの動作が測定用ギャップと衝突したために行われなかった場合に、該データパケットについて送信プロトコルの送信カウンタを1インクリメントするステップをさらに含む。
第17の態様によれば、通信システムにおいてユーザ端末からアップリンクデータパケット送信を受信する基地局が提供される。ユーザ端末は、アップリンクデータパケット送信のための送信プロトコルを実行する。ユーザ端末がデータパケットについて行った送信回数を数える第1の送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末がデータパケットについて行った送信回数を数える第2の送信カウンタが、基地局に設定される。第1の送信カウンタパラメータが、第1のおよび第2の送信カウンタの動作のためのデータパケットの許容可能最大送信回数を設定する。ユーザ端末は、サイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように基地局によって設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および/または受信することができない。基地局は、ユーザ端末においてデータパケットの再送信が送信プロトコルによってトリガされる場合に、該データパケットについて第2の送信カウンタをインクリメントするプロセッサを備える。そして、プロセッサは、ユーザ端末の送信プロトコルによってトリガされるデータパケットの再送信が、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したためにユーザ端末によって行われなかったかを判定する。衝突がある場合、プロセッサは、データパケットの第2の送信カウンタの動作のために第2の送信カウンタパラメータを使用することによって第2の送信カウンタのためにデータパケットの許容可能最大送信回数を増加する。
第18の態様によれば、通信システムにおいてアップリンクデータパケット送信のためのユーザ端末における送信プロトコルを実行する方法が提供される。ユーザ端末がデータパケットについて行った送信回数を数える送信カウンタが、ユーザ端末の送信プロトコルのために設定される。ユーザ端末には、データパケットの許容可能最大送信回数を設定する第1の送信カウンタパラメータが送信カウンタの動作のために設定される。ユーザ端末は、ユーザ端末に設定されたサイドリンクディスカバリギャップに基づいて他のユーザ端末とのサイドリンクディスカバリオペレーションに参加するように設定される。ユーザ端末は、サイドリンクディスカバリギャップにおけるサイドリンクディスカバリオペレーションに参加する場合、送信プロトコルの制御下における信号を送信および/または受信することができない。本方法は、データパケットの再送信が送信プロトコルによってトリガされる場合にユーザ端末がデータパケットについて送信カウンタをインクリメントするステップと、データパケットのトリガされた再送信が送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したために行われなかったかを判定するステップを含む。そして、衝突がある場合、ユーザ端末は、データパケットの送信カウンタの動作のために第2の送信カウンタパラメータを使用することによって送信カウンタのためにデータパケットの許容可能最大送信回数を増加する。
第18の態様に加えて提供される第19の態様によれば、ユーザ端末には、基地局によって、送信プロトコルの動作がサイドリンクディスカバリギャップの1つと衝突したために行われなかったデータパケットの再送信のトリガリングによってインクリメントされた送信カウンタに適用可能な第2の送信カウンタパラメータが設定される。任意選択的に、第2の送信カウンタパラメータは、第1の送信カウンタパラメータによって示されるデータパケットの許容可能最大送信回数より大きいデータパケットの許容可能最大送信回数を示し、この増加は、サイドリンクディスカバリギャップの長さに依存する。
第18の態様に加えて提供される第20の態様によれば、第2の送信カウンタパラメータは、プロセッサが衝突を判定するたびに第1の送信カウンタパラメータをインクリメントすることによってユーザ端末によって生成される。
[ハードウェアおよびソフトウェアによる本開示の実施]
他の例示的な実施形態は、上述したさまざまな実施形態を、ハードウェア、ソフトウェア、またはハードウェアと協働するソフトウェアを使用して実施することに関する。これに関連して、ユーザ機器(移動端末)およびeNodeB(基地局)を提供する。ユーザ端末は、本明細書に記載されている方法を実行するように適合されており、これらの方法に適切に関与する対応のエンティティ(受信機、送信機、プロセッサなど)を含む。
さまざまな実施形態がコンピューティングデバイス(プロセッサ)を使用して実施または実行されうることがさらに認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ(DSP:Digital Signal Processor)、特定用途向け集積回路(ASIC:Application Specific Integrated Circuit)、フィールドプログラマブルゲートアレイ(FPGA:Field Programmable Gate Array)、または、その他プログラマブルロジックデバイスなどである。さまざまな実施形態は、これらのデバイスの組合せによっても実行または具現化されうる。特に、上述の各実施形態の説明において使用される各機能ブロックは、集積回路としてのLSIによって実施することができる。各機能ブロックを個々にチップとして形成してもよいし、1つのチップを、機能的ブロックの一部または全部を含むように形成してもよい。チップは、チップに結合されたデータ入力部およびデータ出力部を有しうる。本明細書においてLSIを、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIということもできる。集積回路化の手法はLSIに限るものではなく、専用回路または汎用プロセッサで実現してもよい。また、LSI製造後にプログラムすることが可能なFPGA(Field Programmable Gate Array)または、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブルプロセッサを利用してもよい。
さらに、さまざまな実施形態は、ソフトウェアモジュールによっても実施され得る。これらのソフトウェアモジュールは、プロセッサによって実行されるか、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、RAMまたはEPROM、EEPROM、フラッシュメモリ、レジスタ、ハードディスク、CD−ROM、DVDなどに格納され得る。さらには、複数の異なる実施形態の個々の特徴は、個々に、または任意の組合せにおいて、別の実施形態の主題とすることができることに留意されたい。
具体的な実施形態に示した本開示には、広義に記載されている本発明の概念または範囲から逸脱することなく、さまざまな変更および/または修正を行うことができることが、当業者には理解されるであろう。したがって、本明細書に示した実施形態は、あらゆる点において例示的であり、本発明を制限するものではないものとみなされる。