WCDMA(登録商標)無線アクセス技術に基づく第3世代モバイルシステム(3G)は世界中で広範に展開されている。この技術を拡張または発展させる第1段階は、競争力の高い無線アクセス技術を与える、高速下りパケットアクセス(HSDPA:High−Speed Downlink Packet Access)および高速上りパケットアクセス(HSUPA:High Speed Uplink Packet Access)とも呼ばれる拡張された上りリンクを導入することを伴う。3GPPは、ユーザ要求のさらなる増大と新しい無線アクセス技術との競争に備えて、ロング・ターム・エボリューション(LTE:Long Term Evolution)と呼ばれる新しい移動通信システムを導入した。LTEは、高速データおよびメディア伝送、ならびに大容量音声サポートに対するキャリアニーズを、今後10年間にわたって満たすように設計されている。高いビットレートを提供する能力は、LTEにとって重要な尺度である。進化型UMTS地上無線アクセス(UTRA:UMTS Terrestrial Radio Access)およびUMTS地上無線アクセスネットワーク(UTRAN:UMTS Terrestrial Radio Access Network)と呼ばれるロング・ターム・エボリューション(LTE)に関する作業項目(WI:work item)仕様がリリース8(Rel.8 LTE)として最終決定されている。LTEシステムは、低待ち時間および低コストで完全なIPベースの機能を提供する効率的なパケットベースの無線アクセスおよび無線アクセスネットワークを表す。LTEでは、所与のスペクトルを使用して柔軟なシステム展開を達成するために、1.4、3.0、5.0、10.0、15.0、および20.0MHzなどのスケーラブルな複数の伝送帯域幅が指定される。下りリンクでは、シンボルレートが低いためにマルチパス干渉(MPI:multipath interference)に対して固有の耐性があり、サイクリックプレフィックス(CP:cyclic prefix)を使用し、異なる伝送帯域幅構成に対して親和性があるために、直交周波数分割多重化(OFDM:Orthogonal Frequency Division Multiplexing)ベースの無線アクセスが採用された。上りリンクでは、ユーザ機器(UE:user equipment)の送信電力に制限があることを考慮するとピークデータ転送速度の改善よりも広域カバレッジの提供が優先されるため、シングルキャリア周波数分割多元接続(SC‐FDMA:Single‐carrier frequency division multiple access)ベースの無線アクセスが採用された。Rel.8 LTEでは、多入力多出力(MIMO:multiple−input multiple−output)チャネル伝送技術を含む多くの重要なパケット無線アクセス技術が用いられ、非常に効率的な制御シグナリング構造が達成される。
LTEアーキテクチャ
図1に全体的なアーキテクチャを示し、図2にE‐UTRANアーキテクチャのより詳細な図を示す。E‐UTRANはeNBからなり、UEにE‐UTRAユーザプレーン(PDCP/RLC/MAC/PHY)および制御プレーン(RRC)のプロトコル終端を提供する。eNBは、ユーザプレーンのヘッダ圧縮および暗号化の機能を含む物理(PHY:Physical)層、媒体アクセス制御(MAC:Medium Access Control)層、無線リンク制御(RLC:Radio Link Control)層、およびパケットデータ制御プロトコル(PDCP:Packet data Control Protocol)層をホストする。eNBはまた、制御プレーンに対応する無線リソース制御(RRC:Radio Resource Control)機能も提供する。eNBは、無線リソース管理、アドミッション制御、スケジューリング、折衝されたUL QoSの実施、セル情報ブロードキャスト、ユーザプレーンおよび制御プレーンデータの暗号化/解読、DL/ULユーザ・プレーン・パケット・ヘッダの圧縮/解凍を含む多くの機能を果たす。eNBは、X2インターフェースを使用して相互接続される。eNBはまた、S1インターフェースによってEPC(Evolved Packet Core(進化型パケットコア))に、より具体的には、S1‐MMEによってMME(Mobility Management Entity(モビリティ管理エンティティ))と、S1‐Uを介してサービングゲートウェイ(S‐GW)とに接続される。S1インターフェースは、MME/サービングゲートウェイとeNBとの間の多対多の関係をサポートする。SGWは、ユーザ・データ・パケットをルーティング、転送すると同時に、eNB間のハンドオーバ中のユーザプレーンのモビリティアンカとして働き、LTEと他の3GPP技術との間のモビリティのためのアンカとしても働く(S4インターフェースを終端し、2G/3GシステムとPDN GWとの間でトラフィックを中継する)。アイドル状態のUEでは、SGWは、DLデータパスを終端し、UEにDLデータが到着するとページングをトリガする。SGWは、UEコンテキスト、例えば、IPベアラサービスのパラメータ、ネットワーク内部ルーティング情報を管理し、格納する。SGWはまた、合法的傍受の場合にユーザトラフィックの複製を行う。
MMEは、LTEアクセスネットワークの主要な制御ノードである。MMEは、再送信を含むアイドルモードUEの追跡およびページング手順を担当する。MMEは、ベアラアクティブ化/非アクティブ化プロセスに関与し、初期接続時と、コアネットワーク(CN:Core Network)ノードの再配置を伴うLTE内ハンドオーバ時にUEにSGWを選択する役割も担う。MMEはまた、(HSSと対話することによって)ユーザを認証する役割も担う。非アクセス層(NAS:Non−Access Stratum)シグナリングはMMEで終端し、MMEは一時的な識別の生成およびUEへの割当も担当する。MMEは、サービスプロバイダの公衆陸上移動網(PLMN:Public Land Mobile Network)にキャンプオンするUEの権限をチェックし、UEのローミング制限を実施する。MMEは、NASシグナリングの暗号化/完全性保護のためのネットワークにおける終端点であり、セキュリティキー管理を処理する。シグナリングの合法的傍受もMMEによってサポートされる。MMEはまた、SGSNからのMMEで終端するS3インターフェースを用いたLTEと2G/3Gアクセスネットワークとの間のモビリティのための制御プレーン機能も提供する。MMEはまた、ローミングUEのためにホームHSSに対してS6aインターフェースを終了する。
3GPP LTEシステムの下りコンポーネントキャリアは、いわゆるサブフレーム単位で時間・周波数領域で細分される。3GPP LTEでは、各サブフレームは2つの下りスロットに分割され、第1の下りスロットは第1のOFDMシンボル内の制御チャネル領域(PDCCH領域)を含む。各サブフレームは、時間領域における所与の数のOFDMシンボル(3GPP LTE(リリース8)では12または14個のOFDMシンボル)からなり、各OFDMシンボルはコンポーネントキャリアの全帯域幅に及ぶ。よって、OFDMシンボルは各々、それぞれのサブキャリア上で伝送されるいくつかの変調シンボルからなる。
例えば3GPPロング・ターム・エボリューション(LTE)で使用されるように、例えばOFDMを用いたマルチキャリア通信システムを想定すると、スケジューラが割り当てられることのできるリソースの最小単位は、1つの「リソースブロック」である。物理リソースブロック(PRB)は、時間領域における連続したOFDMシンボル(例えば、7個のOFDMシンボル)および周波数領域における連続したサブキャリア(例えば、1つのコンポーネントキャリアに12個のサブキャリア)として定義される。3GPP LTE(リリース8)では、物理リソースブロックはよって、時間領域で1つのスロット、周波数領域で180kHzに対応するリソースエレメントからなる(下りリソースグリッドのさらなる詳細については、例えば、参照により本明細書に組み込まれる、http://www.3gpp.orgで入手可能な非特許文献1、セクション6.2を参照)。
1つのサブフレームは2つのスロットからなり、いわゆる「通常の」CP(サイクリックプレフィックス)が使用される場合は1つのサブフレームに14個のOFDMシンボルがあり、いわゆる「拡張」CPが使用される場合は1つのサブフレームに12個のOFDMシンボルがある。用語の説明のため、以下では、完全なサブフレームに及ぶ同じ連続したサブキャリアに相当する時間・周波数リソースを「リソースブロック対」、または対応する「RB対」または「PRB対」と呼ぶ。
「コンポーネントキャリア」という用語は、周波数領域におけるいくつかのリソースブロックの組み合わせを指す。LTEの将来のリリースでは、「コンポーネントキャリア」という用語は使用されなくなり、代わりに、この用語が「セル」に変更され、「セル」は、下りリソースと任意選択で上りリソースとの組み合わせを指す。下りリソースのキャリア周波数と上りリソースのキャリア周波数との間のリンクは、下りリソース上で伝送されるシステム情報で示される。コンポーネントキャリア構造についての同様の想定が、後のリリースにも当てはまる。
[OSI階層の概要]
図3Aに、LTEアーキテクチャのさらなる考察の基礎となる階層モデルの簡単な概要を示す。
開放型システム間相互接続参照モデル(OSI(Open Systems Interconnection)モデルまたはOSI参照モデル)は、通信およびコンピュータ・ネットワーク・プロトコル設計のための階層化された抽象的記述である。OSIモデルは、システムの機能を一連のレイヤに分割する。各レイヤには、下位のレイヤの機能のみを使用し、上位のレイヤにのみ機能をエクスポートするという特性がある。これら一連のレイヤからなるプロトコル挙動を実装するシステムは、「プロトコルスタック」または「スタック」として知られている。その主な特徴は、あるレイヤが別のレイヤとどのように相互作用するかについての仕様を規定するレイヤ間の結合にある。すなわち、ある製造者によって作成されたレイヤが別の製造者のレイヤからと共に動作することができる。本開示の目的のために、最初の3つのレイヤについてのみ以下でさらに詳細に説明する。
物理層またはレイヤ1の主な目的は、特定の物理媒体(同軸ケーブル、ツイストペア、光ファイバ、無線インターフェースなど)上での情報(ビット)の転送である。物理層は、データを通信チャネル上で伝送される信号(またはシンボル)に変換または変調する。
データリンク層(またはレイヤ2)の目的は、入力データをデータフレームに分割することによって特定の物理層と互換性を有するように情報フローを形成することである(セグメント化および再組立て(Segmentation And Re‐assembly)(SAR)機能)。さらに、データリンク層は、失われたフレームの再送信を要求することによって、潜在的な伝送誤りを検出、修正しうる。データリンク層は通常、アドレス指定機構を提供し、そしてデータ転送速度を受信側容量と整合させるためにフロー制御アルゴリズムを提供しうる。共有媒体が複数の送信側と受信側とによって同時に使用される場合、データリンク層は通常、物理媒体へのアクセスを規制、制御する機構を提供する。
データリンク層によって提供される機能は多数あるので、データリンク層はしばしばサブレイヤ(例えばUMTSではRLC層とMAC層)に細分される。レイヤ2プロトコルの典型的な例が、固定回線ネットワーク用のPPP/HDLC、ATM、フレームリレー、および無線システム用のRLC、LLC、またはMACである。レイヤ2のサブレイヤPDCP、RLCおよびMACに関するより詳細な情報については後述する。本出願では、サブレイヤを「レイヤ」とも呼び、よって本出願で用いる「レイヤ」という用語は必ずしもOSIモデルのレイヤを意味しないことに留意されたい。
ネットワーク層またはレイヤ3は、トランスポート層によって要求されるサービス品質を維持しながら、1つまたは複数のネットワークを介して送信元から宛先へ可変長パケットを転送するための機能的、手順的手段を提供する。通常、ネットワーク層の主な目的は、とりわけネットワークルーティング、ネットワークフラグメンテーション、および輻輳制御の機能を果たすことである。ネットワーク層プロトコルの主な例は、IPインターネットプロトコルまたはX.25である。
レイヤ4からレイヤ7に関しては、アプリケーションおよびサービスによっては、レイヤ3より上位で動作するアプリケーションおよびサービスがしばしば、OSIモデルの様々なレイヤに帰されるべき様々な機能を実装するため、アプリケーションまたはサービスをOSIモデルの特定のレイヤに帰することが難しい場合があることに留意されたい。したがって、特にTCP(UDP)/IPベースのネットワークでは、場合によっては、レイヤ4以上が組み合わされていわゆる「アプリケーション層」を形成する。
[レイヤサービスおよびデータ交換]
以下では、本明細書で使用されるサービス・データ・ユニット(SDU:service data unit)およびプロトコル・データ・ユニット(PDU:protocol data unit)という用語を、図3Bとの関連で定義する。OSIモデルにおけるレイヤ間のパケット交換を一般的に形式的に説明するために、SDUエンティティおよびPDUエンティティが導入された。SDUは、いわゆるサービス・アクセス・ポイント(SAP:service access point)を介してレイヤNに位置するプロトコルにサービスを要求するレイヤN+1のプロトコルから送信される情報の単位(データ/情報ブロック)である。PDUは、同じレイヤNに位置する同じプロトコルの送信側と受信側とのピアプロセス間で交換される情報の単位である。
PDUは、一般に、レイヤN固有のヘッダによって先行され、任意選択でトレーラによって終端される(1つまたは複数の)受信SDUの処理済みバージョンからなるペイロード部によって形成される。(レイヤ1を除いて)これらのピアプロセス間には直接の物理接続がないため、PDUは処理のためにレイヤN−1に転送される。したがって、レイヤNのPDUは、レイヤN−1の観点からは、SDUである。
[LTEユーザプレーン(U‐Plane、UP)および制御プレーン(C‐Plane、CP)プロトコル:]
LTEレイヤ2ユーザプレーン/制御プレーン・プロトコル・スタックは、3つのサブレイヤ、PDCP、RLC、およびMACを含む。
前述したように、送信側では、各レイヤは、そのレイヤがサービスを提供する上位層からSDUを受信し、下位の層にPDUを出力する。RLC層はPDCP層からパケットを受信する。これらのパケットは、PDCPの観点からはPDCP PDUと呼ばれ、RLCの観点からはRLC SDUを表す。RLC層は、下位のレイヤ、すなわちMAC層に提供されるパケットを作成する。RLCによってMAC層に提供されるパケットは、RLCの観点からはRLC PDUであり、MACの観点からはMAC SDUである。受信側では、プロセスが反転され、各レイヤはSDUを上位のレイヤに渡し、そこでSDUはPDUとして受信される。
物理層は本質的にターボ符号化と巡回冗長検査(CRC:cyclic redundancy check)によって保護されたビットパイプを提供するが、リンク層プロトコルは、信頼性、セキュリティおよび完全性を高めることによって上位層へのサービスを強化する。加えて、リンク層は、マルチユーザ媒体アクセスおよびスケジューリングも担当する。LTEリンク層設計の主な課題の1つは、広範な異なるサービスとデータ転送速度とでインターネットプロトコル(IP)のデータフローに必要な信頼性レベルと遅延を提供することである。特に、プロトコルオーバーヘッドが拡張しなければならない。例えば、ボイス・オーバー・アイピー(VoIP:voice over IP)フローは100ミリ秒程度の遅延と最大1%までのパケット損失を許容できると広く想定されている。他方、TCPファイルのダウンロードは、低帯域幅・遅延の製品を使用したリンク上の方がうまくいくことは周知である。結果として、非常に高いデータ転送速度(例えば、100Mb/s)でのダウンロードは、遅延がさらに低いことを必要とし、IPパケット損失に対してVoIPトラフィックよりも敏感であることになる。
全体として、これは部分的に関連し合っているLTEリンク層の3つのサブレイヤによって達成される。パケットデータ収束プロトコル(PDCP:Packet Data Convergence Protocol)副層は、主としてIPヘッダの圧縮および暗号化を担当する。加えて、PDCP副層は、eNB間のハンドオーバが発生した場合の損失なしのモビリティをサポートし、上位層制御プロトコルに完全性保護を提供する。無線リンク制御(RLC)副層は、主にARQ機能を含み、データのセグメント化および連結をサポートする。データのセグメント化および連結により、データ転送速度に関係なくプロトコルのオーバーヘッドが最小化される。最後に、媒体アクセス制御(MAC)副層はHARQを提供し、スケジューリング動作やランダムアクセスなどの媒体アクセスに必要な機能を担当する。
特に、媒体アクセス制御(MAC)層は、LTE無線プロトコルスタックのレイヤ2アーキテクチャにおける最下位のサブレイヤであり、例えば、非特許文献2によって定義されている。下位の物理層への接続はトランスポートチャネルによるものであり、上位のRLC層への接続は論理チャネルによるものである。したがってMAC層は、論理チャネルとトランスポートチャネルとの間の多重化および多重分離を行う。送信側のMAC層は、論理チャネルを介して受信されたMAC SDUからトランスポートブロックとして知られるMAC PDUを構築し、受信側のMAC層は、トランスポートチャネルを介して受信されたMAC PDUからMAC SDUを回復する。
MAC層は、論理チャネルを介してRLC層にデータ転送サービスを提供し(参照により本明細書に組み込まれるTS36.321の5.4項および5.3項を参照)、論理チャネルは、制御データ(例えば、RRCシグナリング)を搬送する制御論理チャネルまたはユーザ・プレーン・データを搬送するトラフィック論理チャネルのどちらかである。他方、MAC層からのデータは、下りリンクまたは上りリンクとして分類されるトランスポートチャネルを介して物理層と交換される。データは、それが無線でどのように伝送されるかに応じて、トランスポートチャネルに多重化される。
物理層は、無線インターフェースを介したデータおよび制御情報の実際の伝送を担う。すなわち、物理層は、送信側の無線インターフェース上でMACトランスポートチャネルからすべての情報を搬送する。物理層によって行われる重要な機能のいくつかには、RRC層のための符号化および変調、リンク適応(AMC)、電力制御、セル探索(初期同期とハンドオーバのための)、および他の測定(LTEシステム内およびシステム間の)が含まれる。物理層は、変調方式、符号化率(すなわち、変調および符号化方式、MCS)、物理リソースブロックの数などの伝送パラメータに基づいて伝送を行う。物理層の機能に関するさらなる情報は、参照により本明細書に組み込まれる非特許文献3に記載されている。
無線リソース制御(RRC)層は、無線インターフェースにおけるUEとeNBとの間の通信、およびいくつかのセルを横切って移動するUEのモビリティを制御する。RRCプロトコルはまた、NAS情報の転送もサポートする。RRC_IDLEのUEでは、RRCは着呼のネットワークからの通知をサポートする。RRC接続制御は、ページング、測定構成および通知、無線リソース構成、初期セキュリティアクティブ化、およびシグナリング無線ベアラ(SRB:Signalling Radio Bearer)とユーザデータを搬送する無線ベアラ(データ無線ベアラ、DRB:Data Radio Bearer)との確立を含む、RRC接続の確立、変更および解放に関連したすべての手順をカバーする。
無線リンク制御(RLC)副層は、主にARQ機能を含み、データのセグメント化および連結をサポートする。すなわち、RLC層は、RLC SDUをMAC層によって指示されるサイズに入れるために、RLC SDUのフレーミングを行う。データのセグメント化および連結により、データ転送速度に関係なくプロトコルのオーバーヘッドが最小化される。RLC層は、論理チャネルを介してMAC層に接続される。各論理チャネルは、異なるタイプのトラフィックを搬送する。RLC層の上位のレイヤは通常PDCP層であるが、場合によっては、RRC層である。すなわち、論理チャネルBCCH(Broadcast Control Channel)、PCCH(Paging Control Channel)およびCCCH(Common Control Channel)上で伝送されるRRCメッセージは、セキュリティ保護を必要とせず、よって、RLC層に直接進み、PDCP層を迂回する。
[RLC再送信プロトコル]
RLCが、欠落したPDUの再送信を要求するように構成されている場合、これを確認モード(AM:Acknowledged Mode)で動作しているという。これは、WCDMA/HSPAで使用される対応する機構と同様である。全体として、RLCには、透過モード(TM:Transparent Mode)、非確認モード(UM:Unacknowledged Mode)、および確認モード(AM)の3つの動作モードがある。各RLCエンティティは、RRCによってこれらのモードのうちの1つで動作するように構成される。
透過モードでは、上位層から受信されたRLC SDUにプロトコルオーバーヘッドが追加されない。特殊な場合には、制限されたセグメント化/再組立て能力での伝送を行うことができる。セグメント化/再組立てが使用されるかどうかは、無線ベアラセットアップ手順において折衝されなければならない。透過モードは、例えば、音声のような非常に遅延に敏感なサービスに使用される。
非確認モードでは、再送信プロトコルが使用されないため、データ配信が保証されない。PDU構造は、上位層における完全性確認のためのシーケンス番号を含む。RLCシーケンス番号に基づき、受信UM RLCエンティティは受信RLC PDUの並べ替えを行うことができる。セグメント化と連結は、データに追加されたヘッダフィールドによって提供される。非確認モードのRLCエンティティは、上りリンクと下りリンクとの間には関連付けが定義されていないため、単方向である。誤ったデータが受信された場合、対応するPDUは構成に応じて廃棄またはマークされる。送信側では、タイマによって指定された一定時間内に送信されないRLC SDUは廃棄され、送信バッファから除去される。上位層から受信されたRLC SDUは、送信側でRLC PDUにセグメント化/連結される。受信側では、しかるべく再組立てが行われる。非確認モードは、誤りのない配信の重要度が配信時間の短さと比べて低いサービス、例えば、特定のRRCシグナリング手順、MBMSなどのセル・ブロードキャスト・サービス、ボイス・オーバー・アイピー(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)を提供する。ポーリングフィールドが「1」に設定されているPDUがある場合、またはRLCデータPDUが欠落していると検出された場合には、RLC受信側は状況通知をトリガする。RLC送信側でRLC状況通知のポーリングをトリガするいくつかのトリガが、参照により本明細書に組み込まれる、非特許文献4の5.2.3項で定義されている。送信側では、送信は送信ウィンドウ内のPDUに対してのみ許可され、送信ウィンドウはRLC状況通知によってのみ更新される。したがって、RLC状況通知が遅延すると、送信ウィンドウを進めることができず、送信が停滞する可能性がある。受信側はトリガされると送信側にRLC状況通知を送信する。
[レイヤ1/レイヤ2制御シグナリング]
スケジュールされたユーザに、ユーザの割当状況、トランスポートフォーマット、および他の伝送関連情報(例えば、HARQ情報、送信電力制御(TPC:transmit power control)コマンド)を知らせるために、L1/L2制御シグナリングが、データと共に下りリンクで送信される。ユーザ割当がサブフレームごとに変化しうると想定して、L1/L2制御シグナリングがサブフレーム内の下りデータと多重化される。ユーザ割当は、TTI(送信時間間隔:Transmission Time Interval)ベースで行われてもよく、その場合TTI長はサブフレームの倍数とすることができることに留意されたい。TTI長は、すべてのユーザについてサービスエリア内で固定されていてもよく、ユーザごとに異なっていてもよく、ユーザごとに動的であってもよい。一般に、L1/2制御シグナリングは、TTI当たり1回だけ送信するのみでよい。一般性を失うことなく、以下ではTTIが1つのサブフレームと等しいと仮定する。
L1/L2制御シグナリングは、物理下り制御チャネル(PDCCH:Physical Downlink Control Channel)上で伝送される。PDCCHは、メッセージを下り制御情報(DCI:Downlink Control Information)として搬送し、DCIは、ほとんどの場合、移動端末またはUEグループのためのリソース割当および他の制御情報を含む1つのサブフレームでいくつかのPDCCHを伝送することができる。
一般に、上り無線リソースまたは下り無線リソースを割り当てるためのL1/L2制御シグナリングで送信される情報(特にLTE(‐A)リリース10)は、以下の項目に分類することができる。
− ユーザID、割り当てられているユーザを示す。これは通常、CRCをユーザIDでマスクすることによってチェックサムに含まれる。
− リソース割当情報、ユーザが割り当てられているリソース(例えば、リソースブロック、RB)を示す。あるいは、この情報はリソースブロック割当(RBA:Resource Block Assignment)と呼ばれる。ユーザが割り当てられているRBの数は動的でありうることに留意されたい。
− キャリアインジケータ、第1のキャリア上で伝送された制御チャネルが、第2のキャリアに関するリソース、すなわち、第2のキャリア上のリソースまたは第2のキャリアに関連したリソースを割り当てる場合に使用される。(クロス・キャリアス・ケジューリング)。
− 用いられた変調方式および符号化率を決定する変調および符号化方式。
− データパケットまたはその一部の再送信に特に有用な新データインジケータ(NDI:new data indicator)および/または冗長バージョン(RV:redundancy version)などのHARQ情報。
− 割り当てられた上りデータまたは制御情報送信の送信電力を調整する電力制御コマンド。
− 適用された循環シフトおよび/または直交カバー・コード・インデックスなどの参照信号情報、割当に関連した参照信号の送信または受信に用いられる。
− 割当の順序を識別するために使用される上りリンクまたは下りリンク割当インデックス、TDDシステムで特に有用である。
− ホッピング情報、例えば、周波数ダイバーシチを増加させるためにリソースホッピングを適用するかどうかおよびどのように適用するかの指示。
− CSI要求、割り当てられたリソース内のチャネル状態情報の送信をトリガするために使用される。
− マルチクラスタ情報、送信が行われるのが単一のクラスタ(連続したRBのセット)においてか、それとも複数のクラスタ(連続したRBの少なくとも2つの非連続のセット)においてかを指示および制御するために使用されるフラグである。マルチクラスタ割当は、3GPP LTE‐(A)リリース10によって導入された。
上記のリストは非網羅的であり、使用されるDCIフォーマットによってはすべての言及された情報項目が各PDCCH伝送に存在する必要はないことに留意されたい。
下り制御情報は、全体サイズが異なり、上述したようにそれらのフィールドに含まれる情報も異なるいくつかのフォーマットで発生する。現在LTEに定義されている様々なDCIフォーマットは以下の通りであり、非特許文献5、セクション5.3.3.1に詳細に記載されている(現行バージョンv13.0.0は、http://www.3gpp.orgで入手することができ、参照により本明細書に組み込まれる)。例えば、以下のDCIフォーマットを使用して、上りリンクのリソース許可を搬送することができる。
− フォーマット0:DCIフォーマット0は、上り送信モード1または2で単一アンテナポート送信を使用した、PUSCHのリソース許可の送信に使用される。
− フォーマット4:DCIフォーマット4は、上り送信モード2で閉ループ空間多重伝送を使用した、PUSCHのスケジューリングに使用される。
[LTEの上りアクセス方式]
上り方式は、スケジュールされたアクセス、すなわちeNBによって制御されたアクセスとコンテンションベースのアクセスの両方を可能にする。
スケジュールされたアクセスの場合、UEは、上りデータ送信のために特定の時間にわたる特定の周波数リソース(すなわち、時間/周波数リソース)を割り当てられる。しかしながら、いくつかの時間/周波数リソースをコンテンションベースのアクセスに割り当てることができる。これらの時間/周波数リソース内で、UEは、最初にスケジュールされずに送信することができる。UEがコンテンションベースのアクセスを行っている1つのシナリオは、例えば、ランダムアクセス、すなわち、UEがセルへの初期アクセスを行っているとき、または上りリソースを要求するためのものである。
スケジュールされたアクセスでは、NodeBスケジューラはユーザに上りデータ送信のための一意の周波数/時間リソースを割り当てる。より具体的には、スケジューラは、どの(1つまたは複数の)UEがどの物理チャネルリソース(周波数)で送信を許可されるか、および移動端末によって送信に使用されるべき対応するトランスポートフォーマットを決定する。
割当情報は、スケジューリング許可を介してUEにシグナリングされ、L1/L2制御チャネル上で送信される。スケジューリング許可メッセージは、UEが周波数帯域のどの部分を使用することを許可されるかの情報、許可の有効期間、およびUEが今後の上り送信に使用しなければならないトランスポートフォーマットを含む。最短有効期間は1サブフレームである。選択された方式によっては、許可メッセージには追加情報も含まれうる。「UEごとの」許可だけがUL‐SCH上で送信する権利を許可するために使用される(すなわち、「RBごとのUEごとの」許可はない)。したがって、UEは、いくつかの規則に従って、割り当てられたリソースを無線ベアラ間で分配する必要がある。HSUPAとは異なり、UEベースのトランスポートフォーマットの選択はない。eNBは何らかの情報、例えば、チャネル品質フィードバックや、通知されたスケジューリング情報や、QoS情報に基づいてトランスポートフォーマットを決定し、UEは選択されたトランスポートフォーマットに従わなければならない。
通常のスケジューリングモードは、下り送信リソースの割当のための下りリンク割当メッセージおよび上り送信リソースの割当のための上りリンク許可メッセージによる動的スケジューリングであり、これらは通常、特定の単一のサブフレームについて有効である。それらのメッセージは、UEのC‐RNTIを使用してPDCCH上で送信される。動的スケジューリングは、TCPなど、トラフィックが集中的で、レートが動的なサービスタイプには効率がよい。
動的スケジューリングに加えて、永続的スケジューリングが定義され、永続的スケジューリングは、無線リソースを、1サブフレームよりも長い期間にわたって半静的に構成してUEに割り当てることを可能にし、よって、サブフレームごとのPDCCH上での特定の下りリンク割当メッセージまたは上りリンク許可メッセージが不要になる。永続的スケジューリングは、データパケットのサイズが小さく、周期的で、半静的なVoIPなどのサービスに有用である。よって、PDCCHのオーバーヘッドは、動的スケジューリングの場合と比較して著しく減少する。
[論理チャネルの優先順位付け、LCP、手順]
上りリンクについては、UEが割り当てられた無線リソースを使用して送信するためにMAC PDUを作成するためのプロセスは完全に標準化されており、これは、UEが、構成された各無線ベアラのQoSを、異なるUE実装間で最適かつ一貫性のある方法で確実に満たすように設計されている。UEは、PDCCH上でシグナリングされた上り送信リソース許可メッセージに基づき、新しいMACに含まれるべき論理チャネルごとのデータ量を決定しなければならず、必要ならば、MAC制御要素のためのスペースも割り当てなければならない。
複数の論理チャネルからのデータを用いてMAC PDUを構築する際に、最も簡単で直感的な方法は絶対優先順位ベースの方法であり、MAC PDU空間は論理チャネル優先順位の降順で論理チャネルに割り当てられる。すなわち、最も優先順位の高い論理チャネルからのデータがまずMAC PDUでサービスされ、続いて次に優先順位の高い論理チャネルからのデータがサービスされ、MAC PDU空間がなくなるまで続く。絶対優先順位ベースの方法は、UE実装に関してはきわめて単純であるが、時として優先順位の低い論理チャネルからのデータの枯渇につながることがある。枯渇とは、優先順位の高い論理チャネルからのデータがすべてのMAC PDU空間を占有するため、優先順位の低い論理チャネルからのデータを送信できないことを意味する。
LTEでは、重要度の順にデータを送信するだけでなく、優先順位の低いデータの枯渇を回避するために、論理チャネルごとに優先ビットレート(PBR:Prioritized Bit Rate)が定義されている。PBRは、論理チャネルに保証されている最小データ転送速度である。たとえ論理チャネルの優先順位が低い場合でも、PBRを保証するために少なくとも少量のMAC PDU空間が割り当てられる。よって、枯渇問題はPBRを使用することで回避できる。
PBRを用いたMAC PDUの構築は、2ラウンドからなる。第1ラウンドでは、各論理チャネルは論理チャネル優先順位の降順でサービスされるが、MAC PDUに含まれる各論理チャネルからのデータ量は、最初は論理チャネルの構成PBR値に対応する量に制限される。すべての論理チャネルがそれらのPBR値までサービスされた後、MAC PDUに空きがある場合、第2ラウンドが行われる。第2ラウンドでは、各論理チャネルは優先順位の降順で再度サービスされる。第1ラウンドと比較した第2ラウンドの主な違いは、優先順位の高いすべての論理チャネルにそれ以上送信すべきデータがない場合にのみ、優先順位の低い各論理チャネルにMAC PDU空間を割り当てることができることである。
MAC PDUは、各構成論理チャネルからのMAC SDUだけでなく、MAC CEも含みうる。パディングBSRを除いて、MAC CEは、MAC層の動作を制御するので、論理チャネルからのMAC SDUよりも優先順位が高い。よって、MAC PDUが構成されるときに、MAC CEは、存在する場合には、最初に含まれるべきであり、残りの空間は論理チャネルからのMAC SDUに使用される。次いで、さらなる空間が残っており、BSRを含めるのに十分な大きさであれば、パディングBSRがトリガされ、MAC PDUに含められる。
論理チャネル優先順位付けは、例えば、本明細書に組み込まれる、非特許文献6の5.4.3.1項で標準化されている。UEが1つのTTIで複数のMAC PDUを送信するように要求されたときにどのMAC PDUにMAC制御要素が含められるかの決定は、UEの実装次第である。
[バッファ状況通知]
UEからeNodeBへのバッファ状況通知(BSR:buffer status reports)は、eNodeBの上りリソース割当、すなわち上りリンクスケジューリングを支援するために使用される。下りリンクでは、eNBスケジューラは各UEに配信されるべきデータ量を明らかに知っている。しかしながら、上り方向では、スケジューリング決定はeNBでなされ、データのバッファはUEにあるので、UL−SCH上で送信される必要があるデータ量を示すためにUEからeNBにBSRを送信しなければならない。
LTEのバッファ状況通知MAC制御要素は、長いBSR(LCG ID#0〜3に対応する4つのバッファ・サイズ・フィールドを有する)または短いBSR(1つのLCG IDフィールドと1つの対応するバッファ・サイズ・フィールドとを有する)のどちらかからなる。バッファ・サイズ・フィールドは、論理チャネルグループのすべての論理チャネルにわたって利用可能なデータの総量を示し、異なるバッファ・サイズ・レベルのインデックスとして符号化されたバイト数で示される(参照により本明細書に組み込まれる、非特許文献6、第6.1.3.1章も参照されたい)。
短いBSRと長いBSRのどちらがUEによって送信されるかは、トランスポートブロック内の利用可能な送信リソース、いくつの論理チャネルグループに空でないバッファがあるか、およびUEで特定のイベントがトリガされるかどうかに依存する。長いBSRは4つの論理チャネルグループについてのデータ量を通知し、短いBSRは最も高い論理チャネルグループだけについてバッファされたデータ量を示す。
論理チャネルグループの概念を導入する理由は、たとえUEが4つを超える論理チャネルを構成していても、個々の論理チャネルごとにバッファ状況を通知すると過剰のシグナリングオーバーヘッドを生じさせることになるからである。したがって、eNBは各論理チャネルを論理チャネルグループに割り当てる。好ましくは、同じ/同様のQoS要件を有する論理チャネルは、同じ論理チャネルグループ内に割り当てられるべきである。
BSRがトリガされたときに、UEにトランスポートブロックにBSRを含めるための上りリソースを割り当てられていない場合、UEは、BSRを送信する上りリソースを割り当てられるようにeNodeBにスケジューリング要求(SR:scheduling request)を送信する。単一ビットスケジューリング要求が物理上り制御チャネル(PUCCH:Physical Uplink Control Channel)上で送信される(専用スケジューリング要求、D−SR)か、またはBSRを送信するための上り無線リソースの割当を要求するランダムアクセス手順(RACH)が行われる。
[本開示の基礎]
[L1/L2処理]
図4に、リンク層プロトコルを介して物理層に至るまでのIPパケットのデータフローを例示的に示す。この図には、各プロトコルサブレイヤがデータユニットに独自のプロトコルヘッダを追加することと、サブフレーム上のトランスポートブロックのマッピングとが示されている。トランスポートブロック(TB)は、物理層にマップされたMAC PDUを表す。
LTEにおけるトランスポートブロックのサブフレームへのマッピングは、いわゆる送信時間間隔(TTI:transmission time interval)内で行われる。一般に、単入力単出力(SISO:single input single output)、すなわち、送信側と受信側が1つのアンテナで動作する場合には、単一のトランスポートブロックが1つのTTIにおいて1つのサブフレームにマップされる。MIMO/MISO(multiple input multiple output/multiple input single output(多入力多出力/多入力単一出力))の場合には、2つのトランスポートブロックに対応する2つのコードワードが、1つのTTIにおいて物理リソースにマップされうる。一般には、3つ以上のトランスポートブロックがマッピングのために考慮されうる。
LTEでは、RLC層はPDCP PDUの連結/セグメント化を行う。
送信側がトランスポートブロック(TB)のサイズを知っている場合、MAC層は論理チャネル優先順位付け(LCP)を行って、各RLCエンティティが送信すべき(下位層、すなわちMAC/PHYに提供すべき)データ量を決定する。各RLCエンティティは、1つまたは複数のRLC SDUを含む1つのRLC PDUを提供する。RLC PDUで終わるRLC SDUごとに、対応するL‐field(長さフィールド)が追加され、これにより受信側は対応するSDUを抽出することができる。最後に含まれるRLC SDUがRLC PDUに完全に収まらない場合、そのRLC SDUはセグメント化される。すなわち、RLC SDUの残りの部分は後続の(1つまたは複数の)RLC PDUで送信されることになる。RLC PDUの最初(最後)のバイトがRLC SDUの最初(最後)のバイトに対応するかどうかは、RLCヘッダに位置する「Framing Info」フラグ(2ビット)によって示される。それ以外に、セグメント化は、いかなるオーバーヘッドの追加をしない。RLCシーケンス番号(SN)は、データの元の順序を再確立し、損失を検出するためにRLC PDUヘッダに追加される。
MACは、異なる論理チャネル識別子(LCID)のRLC PDUを多重化し、対応するサブヘッダをLCIDおよびL‐fieldと共に追加する。トランスポートブロック構造のハイレベル図が図4に示されている。最近、3GPPは、新しい無線(NR:new radio)という名前で第5世代システムの研究作業に着手した。NRは非常に高いデータ転送速度(目下、下りリンクで最大20Gbit/秒、上りリンクで10Gbit/秒)を目標としている。
[本開示の詳細な説明]
移動局または移動ノードまたはユーザ端末またはユーザ機器(UE)は、通信ネットワーク内の物理エンティティである。1つのノードは、複数の機能エンティティを有しうる。機能エンティティとは、ノードまたはネットワークの他の機能エンティティに対して所定の機能セットを実施し、かつ/または提供するソフトウェアまたはハードウェアモジュールを指す。ノードは、ノードをノードが通信するための通信設備または媒体に接続する1つまたは複数のインターフェースを有しうる。同様に、ネットワークエンティティは、機能エンティティを機能エンティティが他の機能エンティティまたはコレスポンデントノードと通信するための通信設備または媒体に接続する論理インターフェースを有しうる。
特許請求の範囲および本出願で使用される「無線リソース」という用語は、時間・周波数無線リソースなどの物理的無線リソースを指すものとして広く理解されたい。
以下の例示的な実施形態は、5G移動通信システムに想定される新しい無線技術のための改善された無線インターフェース層処理を提供する。今のところ、5G移動通信システムに関して合意されている詳細はごくわずかであり、そのため、以下では、実施形態の基礎をなす原理を説明できるように、多くの仮定を行う必要がある。しかしながら、これらの仮定については、本開示の範囲を限定すべきではない単なる例として理解されたい。特許請求の範囲に記載されている本開示の原理は、異なるシナリオに、本明細書に明記されていない方法で適用できることを当業者は理解するであろう。例えば、新しい無線技術は、LTE(‐A)のためにすでに定義されている無線技術から進化することになるが、5G移動通信システムの要件を満たすためにいくつかの変更が予想できる。したがって、様々な実施形態の特定の例示的な実施態様は、(リリース10/11/12/13/14などによる)LTE(‐A)通信システムのためにすでに定義されている手順、メッセージ、機能などを、それらが5G通信システムの新しい無線技術と以下の実施形態について説明される様々な実施態様との両方に等しく適用できる限り、さらに再利用することもできるはずである。
本開示によれば、連結/セグメント化機能は、RLC層からMACエンティティに移される。この手法はいくつかの利点を提供し、例えば、UL grantが受信される前に、(送信が上りリンクで行われる場合)RLC PDUおよび部分的にMAC PDUを端末で事前構築することができる。これにより、それぞれのRLC PDUおよび部分的にMAC PDUを事前構築することによって処理時間が短縮される。RLC層は、MACスケジューリング決定およびRLC PDUサイズ指示(両方ともL1/L2シグナリングによるリソース割当と共に搬送される)を待たなくてよい。これにより、トランスポートブロックを生成する際の処理時間が短縮される。
図5Aに、送信側(TX)と受信側(RX)側とのプロトコル層の主な機能を示す。図から分かるように、送信側では、セグメント化はRLC層と協働してMAC層で行われる。
図5Bに、送信側で行われる基本動作を示す。
a)RLCおよび/またはMAC PDUはPDCP PDUごとに前処理される。すなわち、RLC層はPDCP PDUを連結しない。しかしながら、RLC層は、RLC SDU(PDCP PDU)をさらにセグメント化してよく、これが、PDCP PDUセグメント化の2つの結果、すなわちR1‐PDU1およびR2‐PDU2によって示されている。前処理は、所与の無線条件(例えば、RSSI/RSRPなど)において、特定の高信頼水準で統計的に利用可能な「最小(または代替として平均)許可サイズ」に基づくものとすることができる。そのため、擬似LCPが(推定許可サイズで機能するため)この最小または平均許可サイズで実行され、それに応じてRLCおよびMAC PDUが前処理される。(実際の)許可が受信され、LCPがMAC層で実行されたときに、LCPの結果に基づいて許可されたリソースに収容することができる(すなわち、対応するMAC PDUのサイズが対応するLCIDの許可サイズ以下である)前処理されたRLC PDUの一部が、物理層に提出されることになる。物理層はこれらに対するその処理を即座に、すなわち、時点t1において開始しうる。図5Bでは、前処理されたMACヘッダを添付した事前セグメント化されたR1‐PDU1およびR2‐PDU1を、許可されたリソースに収容することができる。
b)事前セグメント化されたR1‐PDU2およびR2‐PDU2を許可されたリソースに全体として収容することはできず、よって、割当サイズの知識を用いて、LCPが行われた後にこれらのPDUのさらなるセグメント化が必要である。言い換えると、(上記工程後の)残りの許可は、前処理されたPDUがセグメント化されることを必要とし、それらの対応するヘッダが再計算される必要がある。セグメント化は、(すでに前処理され、MAC層に提出されたRLC PDUに対しては)MAC層で、またはRLC層で(RLCはLCPの結果に基づくセグメント化後にヘッダを再計算する)行うことができる。このL2処理の後、結果として得られたMAC PDUの部分(セグメント)は物理層に提出される。物理層は、続いて(すなわち、時点t2において)これらに対するその処理を開始しうる。
図5Bでは、2つの異なるRLCエンティティは異なる論理チャネルに属する。したがって、MACは、論理チャネル優先順位付け手順(LCP)に基づいて、対応するMAC PDUのうちのどちらがどの時点で物理層に提供されるべきであるかも決定する。LCP手順の一例はLTEから知られており、上記の背景技術の項に記載されている。とはいえ、本開示はこれに限定されず、一般に適用可能である。
受信側では、物理層処理の後、対応する逆の工程が行われる。
a)MAC層は、MACヘッダ(基本的にはLCIDフィールドとLengthフィールド)に基づいて多重分離を行い、結果として得られる(1つまたは複数の)MAC SDUをRLCに与える。MAC層がMAC SDUをRLC層に渡すとき、MAC層もセグメント化/連結ヘッダフィールドを保持する。というのは、セグメント化および連結はMACによって行われ、セグメントの並べ替えおよび再組立てはRLCによって行われるからである。これが、MACがRLCにセグメント化ヘッダフィールドを渡す理由である。言い換えると、MAC層はRLCに、MAC SDUだけでなく、セグメント化/連結に関連したMACヘッダの一部も渡す。
b)RLC層は、(1つまたは複数の)完全なRLC SDUをPDCPに転送する前に、(もしあれば)RLC PDUセグメントを再組立てする。PDCPへの完全なRLC SDUの提出は、順不同で行われ、すなわち、例えば、既定の時間内または既定の回数の再送信内に正しく受信されなかったためにセグメントが欠落している場所に「穴」を含む。しかしながら、RLCは、(1つまたは複数の)欠落したPDUおよび(1つまたは複数の)PDUセグメントを追跡する必要がある。ARQはRLCで実行され、そのため、欠落したRLC PDUおよび/またはPDUセグメントがあれば、可能な再送信のために送信側に通知されることになる。ここで、ARQは、タイマTimer1が満了するまで、欠落したRLC PDUおよび/またはPDUセグメントを取得しようとすることになる。Timer1は、穴が最初に現れたとき(または後続/次のRLC SDUがPDCP層に配信されるとき)に開始される。Timer1が満了すると、RLCはPDCP層とRRCに通知する。RRCは、無線リンク障害(RLF:Radio Link Failure)手順をトリガするなどのさらなる措置を講じうる。一般に、TCPのような上位層のエンドツーエンドプロトコルは、さらに正しい配信に対処しうる。
c)PDCP層はRLCから受信した着信PDUをPDCP SN(または、ヘッダから直接利用できる場合はCOUNT、そうでない場合はPDCPヘッダに含まれるSNからCOUNTを推定/計算する必要がある)に基づいて解読する。COUNTの計算は、最後のPDCP SNと直前に受信したPDCP PDUヘッダ内のPDCP SN値との差を用いて最後のCOUNT値を調整することによって行われる。ここで、「最後」とは、正常に解読された前のPDCP PDUを指す。加えて、PDCPは「(1つまたは複数の)穴」がRLCから到着するのを待つ。しかしながら、対応するPDCP PDUが受信される前にRLCからの指示が(Timer1満了時に)来た場合、PDCP SDUは(穴を含めて)上位層に提出される。
上記の手法は、AMだけでなくUMにも適用できる。UMが適用される場合には、RLC層で再送信は行われない。とはいえ、受信側では、RLC PDUまたはRLC PDUセグメントが欠落している場合、RLC SDUがさらに組み立てられ、PDCP層に提供される。
AMでは、RLC PDUおよび/またはPDUセグメントが欠落していることをRLC状況通知が示すと、送信側RLCは、対応する欠落したRLC PDUおよび/またはPDUセグメントを、それを再送信することによって受信側が(1つまたは複数の)セグメントを再組立てするのを支援する適切なヘッダを含めてMAC層に提出する。
あるいは、RLC層は、たとえ対応するRLC PDUの1セグメントのみが欠落していると示されたとしても、RLC PDU全体をMAC層に提出してもよい。加えて、RLC層は、状況通知の詳細(すなわち、状況通知全体)をMAC層と共有する。この手法の利点は、RLCヘッダのオーバーヘッドが減ることである。再セグメント化がRLC層で行われる場合には、RLC層は、ヘッダオーバーヘッドを増やすセグメント化ヘッダフィールドを追加する。この問題を克服するために、完全なRLC PDUがMACに送信され、MACは状況通知に基づいてセグメント化を行う。ユニバーサル(共通)シーケンス番号がレイヤ(PDCP、RLC、MAC)間で使用されているので、RLCの状況通知はMACによって理解される。この場合、MAC層は、この知識およびLCPの結果に基づいて再セグメント化を行い、受信側が(1つまたは複数の)セグメントを再組立てするのを支援する適切なヘッダを含める。
上記の説明では、UMTS/LTE(‐A)規格で用いられる用語である「MAC」、「RLC」および「PDCP」に言及していることに留意されたい。しかしながら、本開示はこれらの規格にも、これらの規格の進歩にも限定されず、使用される用語に関係なく機能しうる。
言い換えると、このフレームワークは、(物理層に対応する)物理リソースへの/からのデータのマッピング/逆マッピングを担当する第1層、(MACに対応する)第2層、ならびに(RLCおよび/またはPDCPに対応する)第3層があるプロトコルスタックとみなすことができる。ここでの「第1層」、「第2層」および「第3層」という用語は、必ずしもOSIモデル層に対応するわけではないことに留意されたい。
プロトコルスタック処理待ち時間の短縮は、第1の物理層、第2層、および第3層を用いて送信側で達成することができ、第2層は第3層から(リソース割当の知識なしで第3層によって生成された)前処理された第3層PDUを受信し、(上りリンクで受信側から、または下りリンクで内部から)物理層のためのリソース割当を受信する。前処理された第3層PDUは、(すでに第3層または第2層で)セグメント化情報を含むヘッダを追加されうる。そのような前処理された第3層PDUは、優先順位が異なりうる複数の論理チャネルに対応する複数の第3層エンティティに提供されうることに留意されたい。したがって、第2層は次いで、優先順位付け手順を行いうる。受信したリソース割当に基づき、またおそらくは優先順位付け手順の結果にも基づき、第2の層は次いで、第1の時点t1に第2層ヘッダとしてセグメント化情報を含む適切な前処理された第3層PDUを第1層に提供し、時点t1より後の時点t2に第1層にデータを提供する前に、おそらくは前処理されたPDUのさらなるセグメント化を行い、ヘッダ内のセグメント化情報をそれに応じて変更する。
第3層がARQを実施する場合、第2層で受信される第3層のPDUは、ARQ状況通知に従ってすでに事前セグメント化されている可能性があることに留意されたい。しかし、この手法は、第3層がARQを実施しない場合にも適用可能である。事前セグメント化は、その場合、過去の割当のいくつかの統計的尺度に基づいて、または他の規則に従って行われてもよく、あるいは全く行われなくてもよい。
さらに、本開示はまた、有利には、二重接続またはmulti‐connectivityにも適用されうる。multi‐connectivityは、接続モードにある複数の受信側/送信側UEを、非理想的バックホールを介して接続された複数の別個のスケジューラによって提供されるE‐UTRAおよびNRの中の無線リソースを利用するように構成するための動作モードである。言い換えると、多重接続では、送信側(端末など)における第3層より上位のレイヤは、複数の基地局(eNB)に送信されるべき同じパケット(IPまたはPDCP)を提供する。その場合、2つ以上の基地局が同じパケットを独立して受信し、よってネットワークが正しく受信する確率が高まる。
multi‐connectivityの概念は、3GPP RAN作業グループで検討中の1つの有望なソリューションであるいわゆる「dual connectivity」と多少類似している、いわゆる「dual connectivity」概念である。「dual connectivity」という用語は、所与のUEが非理想的バックホールと接続された少なくとも2つの異なるネットワークノードによって提供される無線リソースを消費する動作を指すのに使用される。本質的に、UEは、マクロセル(マクロeNB)とスモールセル(セカンダリeNB)の両方と接続されている。さらに、UEのdual connectivityに関与する各eNBは、異なる役割を担いうる。それらの役割は、必ずしもeNBの電力クラスに依存するわけではなく、UE間で異なりうる。しかしながら、異なるデータがUEから異なるeNBに送信されるdual connectivityとは異なり、multi‐connectivityでは、同じIP/PDCPパケットが複数のリンク/セル上で送信される。複数の受信側eNBの間で、1つは、複数の接続を介して受信されたセグメントの再組立てを行うレイヤを実施するマスタeNBとして機能している。マスタeNBはその他のeNBと通信する。
例えば、LTEに関して言うと、PDCP層は、単一接続からmulti connectivityへの切り替え時にすでに行っている他の機能に加えて、再組立て機能も引き継ぐ。ARQは依然としてRLC層(AM内)で実行されてよく、この場合、PDCP層は(完全にまたは部分的に)欠落したPDCP SNの詳細をRLC層と共有する必要がある。PDCP層は、RLC層にセグメントの欠落部分について知らせる。その後、RLC層の受信側エンティティは、RLC層の送信側エンティティに状況通知を送信する。したがって、RLC層とPDCP層とで別個のARQは不要であり、単一接続とmulti‐connectivityのARQがどちらも、RLC層で実行されうることを意味する。あるいは、PDCP層はそれ自体の状況通知を作成してそれをTX‐PDCPエンティティに送信することができる。状況通知は、欠落したPDCP PDUおよび/またはPDUセグメントに関する情報を含むことになる。
上述のように待ち時間短縮および/またはオーバーヘッド削減を可能にするために、本開示は、送信側と受信側とで実施されるべき効率的な階層モデルを提供する。これには、以下のうちの1つまたは複数が含まれる。
− セグメント化を第2層に、すなわち、データを(第3層から)物理リソースにマップするのでリアルタイム処理を行わなければならない物理層のできるだけ近くに移す。これにより、対応する許可が受信される前であっても、共有チャネル上で送信するためのデータを準備する可能性が提供される。(端末実装はこれが可能か否かを利用しうる。言い換えると、端末タイミングが前処理されたPDUを利用するか否かは、実装に任されてよい)。
− 複数のレイヤによってアクセスされる共通制御情報を用いる。通常、階層モデルは、各レイヤがそのレイヤで生成された制御情報にのみアクセスすることを前提としている。これにより、複数のレイヤ、つまり異なるレイヤのPDUのヘッダにおいて重複した複製制御情報が提供されることがある。これは、受信データの並べ替えを可能にするシーケンス番号の場合に該当しうる。複数のレイヤ(PDCPやRLCなど)に共通シーケンス番号が使用されてよく、これによりヘッダのオーバーヘッドが削減される。
− 上位層(第3層、より詳細にはRLCやPDCPなど)がARQ機能をサポートする。したがって、第3層の状況通知に基づいて、第3層はPDUのセグメント化を行う。ここでは、状況通知に基づく第3層PDUのセグメント化は、下位層(第2層、より詳細にはMAC)で行われた受信割当に基づいて行われるセグメント化とは異なりうると仮定される。第3層が状況通知に基づいてセグメント化情報を第2層に提供し、第2層だけが割当と状況通知の両方に基づいてセグメント化を行う場合、同様の利点が達成されうる。この手法により、時間(前処理のおかげで)とリソース(再セグメント化は欠落したセグメントのみの再送信を可能にする)の両方を節約することが可能になる。
[ARQのためのレイヤ2セグメント化、レイヤ3事前セグメント化]
一実施形態によれば、通信システムにおいて無線インターフェース上でデータ受信ノードにデータを送信するためのデータ送信ノードが提供される。プロトコルスタック階層モデルの機能を実施するために、データ送信ノードは、データ受信ノードからフィードバックされた状況通知に従ってARQ再送信を行い、または行わず、(もしあれば)状況通知に含まれるセグメント長情報に基づいて再送信されるべきデータを再セグメント化し、または再セグメント化しないための第3層処理ユニットを含む。再セグメント化は、例えばヘッダとして、セグメント化されたデータにセグメント化制御情報を追加することを含む。このヘッダはまた、第2層でも有利に解釈されて使用され、第3層データユニットと共に第2層に提供される。この実施形態では、再送信プロトコルは第3層によって処理されると仮定され、これは第3層の下位または上位の他のレイヤにおける独立したARQ/HARQプロトコルの適用を排除しない。
データ送信ノードは、第3層処理ユニットから、第3層データユニットを受信し、リソース割当に基づいて第3層データユニットをセグメント化し、第3層データユニットのそれぞれのセグメントと再セグメント化が適用されるべきである場合に変更されるセグメント化制御情報とを含む複数の第2層データユニットを形成するための第2層処理ユニットをさらに含む。リソース割当は、データ受信ノードから受信されるか、またはデータ送信ノードで生成されうる。例えば、送信ノードが端末(UE)である場合、リソース割当(上りリンク許可)は基地局から、すなわちデータ受信ノードから受信されうる。他方、送信ノードが基地局である場合、送信のためのリソース割当は基地局で生成され、MAC層に提供されうる。しかしながら、本開示は、端末間または中継器と端末間または中継器と基地局間の直接通信にも適用可能である。
最後に、データ送信ノードは、第2層から、複数の第2層データユニットのうちの1つまたは複数を受信し、複数の第2層データユニットのうちの1つまたは複数をデータ送信に割り当てられたリソース上にマップするための第1層処理ユニットを含む。
データ送信ノードは、そのヘッダ内にシーケンス番号を提供するための第4層処理ユニットをさらに含みうることに留意されたい。シーケンス番号は、新しい第4層SDUごとに、すなわち、IPパケットごとに増加し、シーケンス番号が既定の最大値を有する間、増加は循環的でありうる。第3層は有利には別のシーケンス番号を提供せず、PDCP層によって提供されたシーケンス番号を含む第4層処理ユニットをカプセル化する。
LTE用語に関しては、第1層は物理層であってよく、第2層はMAC層であってよく、第3層はRLC層であってよく、第4層はPDCPであってよい。しかしながら、第3層は、いくつかの実施形態ではPDCP層とみなされ、または、特に現行のLTEから進化したアーキテクチャの場合には、RLCとPDCPの両方の機能を有する1つの結合レイヤとみなされうることに留意されたい。
図6に、この実施形態による、LTE用語を使用して例示された送信側での処理を示す。送信側は、上りリンクで基地局にデータを送信する端末であってよい。しかしながら、本開示はこれに限定されず、送信側は、別の端末に、または任意の他のノードにデータを送信する端末であってもよい。さらに、本開示は、基地局、または中継ノード、またはデータ送信側である別のノードにも適用されうる。
図6に示すように、1200バイトの長さのIPパケット1がPDCP層に提供され、よってPDCP SDUを形成する。PDCP SDUは、単一のビットでありうるD/Cインジケータを含むヘッダを追加される。このビットは、PDCP PDUの内容がデータPDUかそれとも制御PDUかを示す。この例では、このビットはデータPDUには設定され(すなわち、ビットは1に等しく)、制御PDUには設定されていない(すなわち、ビットは0に等しい)。しかしながら、一般に、設定/未設定は反転されてもよい。PDCPヘッダは、PDCPシーケンス番号(SN)をさらに含む。
PDCP PDU1は(ペイロードが1200バイトであり)、RLC層に送信され、よってRLC SDUを形成する。RLC層は、RLC PDUへの関連RLCヘッダを含む。図から分かるように、RLCヘッダは別のD/Cフラグ、Pフラグ、およびRFフラグを含む。D/Cフラグは、RLC PDUによって制御またはデータが搬送されるかどうかを示し、Pフラグは、受信側(ピアRLCエンティティ)に状況通知を要求するために設定されるポーリングビットである。D/Cフラグが設定されていない場合、状況通知は要求されない。RFフラグは、RLC PDUが完全PDCP PDUであるかそれともPDCP PDUセグメントであるかを示す再セグメント化フラグである。RF値は最初に0に設定され、RLC PDUが完全なPDUであることを示し、次いでRLC PDU1の一部としてMAC層に配信される。この例では、PDCP PDU/IPパケットのデータの初回送信では、RLC層はセグメント化を行わず、むしろMAC層がセグメント化を行う。したがって、初回送信時には、RF値は常に0に設定される。
図6の例では、送信側MACエンティティは、受信した許可に基づいてRLC PDUをセグメント化する必要がある。さらに、この例で想定されている許可サイズは、2つの異なる送信機会において800バイトおよび400バイトである(または800バイトに少なくとも1つの許可が、残りは別の許可を待つ)。よって、MAC層は、MAC SDUに対応するRLC PDUをセグメント化する。RLC PDUのセグメント化後、送信側MACエンティティは、含まれるRLC PDUのセグメントオフセット(SO:segment offset)および最後のセグメントフィールド(LSF:last segment field)を示すために、セグメント化に関連するMACヘッダ部分をそれぞれのMAC PDUに含め、図6にMAC PDU1およびMAC PDU2として示されているMAC PDUを形成する。MAC PDU1は800バイトのペイロードを含み、MAC PDU2は400バイトのペイロードを含む。MAC PDU1とMAC PDU2とはそれぞれTTI0とTTI1とに送信される。次いで、TTI0とTTI1とは、異なるリソース、例えば異なる時間リソースに多重化される。しかしながら、これは、2つのMAC PDUを異なる時点にマップすることに本開示を限定するものではないことに留意されたい。一般には、2つ以上のMAC PDUが、異なるタイプのリソース、例えば、MIMOシステムの異なる周波数や異なるストリーム、直交符号などにマップされうる。
この例のSOフィールドは、元のPDU内のPDUセグメントの位置をバイト単位で示す。具体的には、SOフィールドは、PDUセグメントのデータフィールドの最初のバイトが対応する元のPDUのデータフィールド内の位置を示す。元のPDUのデータフィールドの最初のバイトは、SOフィールド値0で参照される。LSFフィールドは、PDUセグメントの最後のバイトがPDUの最後のバイトに対応するか否かを示す。
MAC層は、MAC PDU1とMAC PDU2とに、論理チャネルID(LCID)や拡張フラグ(E)など、MACヘッダの後に続く他のフィールドがあるか否かを示すさらなるフィールドを含めてよい。値1は、このフィールドの後に少なくとも1つまたは複数のE/LCIDフィールドがあることを示す。値0は、このフィールドの後にこれ以上E/LCIDフィールドがないことを示し、次のバイトがMAC SDUの開始バイトであることを意味する。ヘッダ内にはいくつかのさらなるフィールドまたは予約フィールドがありうる(図には示されていない)。
この実施形態によれば、通信システムにおいて無線インターフェース上でデータ送信ノードからデータを受信するためのデータ受信ノードが開示される。本データ受信ノードは、データ送信に割り当てられたリソースから複数の第2層データユニットのうちの1つまたは複数を逆マップし、複数の逆マップされた第2層データユニットのうちの1つまたは複数を第2層処理ユニットに提供するための第1層処理ユニットを含む。さらに、本データ受信ノードは、複数の第2層データユニットのうちの1つまたは複数からの複数の第3層ユニットセグメントおよびセグメント化制御情報の多重分離を行い、複数の多重分離された第3層ユニットセグメントをセグメント化制御情報と共に第3層処理ユニットに転送するための第2層処理ユニットをさらに含む。本データ受信ノードは、複数の多重分離された第3層ユニットセグメントの並べ替えおよび第3層ユニットへの組立てを行うための第3層処理ユニットをさらに含む。
よって、第2層データユニットの一部である(また特に第2層ヘッダで搬送されうる)セグメント化情報も、第3層で見られ、使用される。よってこの手法は、一方では厳密なレイヤ分離を無視し、他方ではオーバーヘッドを節約し、第3層での並べ替えおよび再組立てを効率的に行うことを可能にする。これは、ARQ手順が第3層で実施される場合、特に有利であるが、これは必須ではなく、本開示を限定するものではない。
例示的な実施態様によれば、データ受信装置内の第3層処理ユニットは、少なくとも1つの第3層ユニットセグメントが正しく受信されたか否かを示す状況通知を搬送する制御データを生成するようにさらに構成される。状況通知は、少なくとも1つの第3層データユニットについての肯定応答もしくは否定応答のうちの少なくとも1つ、および/または第3層データユニットの正しく受信されたセグメントもしくは欠落したセグメントの識別を含みうる。ここで用いられうる状況通知の例示的フォーマットは、非特許文献7、セクション6.2.1.6に記載されている。しかしながら、これは一例にすぎず、状況通知のフォーマットおよび内容は、それが第3層PDUまたはそのセグメントの肯定受信応答および/または否定受信応答を可能にする限り、異なっていてもよいことに留意されたい。
図7に、誤りが発生しやすいチャネル上で受信されたMAC PDU1およびMAC PDU2の例示的な受信処理を示す。図7に示すように、MAC PDU1(800バイトのペイロード)は正しく受信されるが、MAC PDU2(400バイトのペイロード)は失われている(正しく復号され得なかった、すなわちCRCが失敗した)。
MAC層は、RLC PDU1の多重分離を行い、それをRLC層に送信する。次いでRLC層は、MACセグメントの再組立ておよび並べ替えを行う。RLC受信側(RX)は、MAC PDU1に属する800〜1200バイトを正しく受信したことを示す状況通知をRLC送信側(TX)に送信する。RLC PDUセグメントの並べ替えおよび再組立ては、MAC層からのヘッダ情報に基づいて行われる。これは、図7の例では、特にセグメントオフセットおよびLSFインジケータを含む。RLC層のD/Cフィールドは、RLCデータPDUと状況通知のようなRLC制御PDUとの区別を可能にする。
図8に、送信側が(例えば、状況通知に基づいて)第2の欠落したMAC‐PDU2セグメントを知っていると仮定して、RLC送信側における例示的な後続の動作を示す。図8に示すように、この例では、RLC TXは、送信バッファから対応する欠落したパケットの完全なRLC PDUを取り出し、RLC状況通知によって欠落していると示されている400(800〜1200)バイトの新しいセグメント化(再セグメント化)を行う。再セグメント化は適切なRLCヘッダを添付することも含む。RLCヘッダはここでは、バイト単位のオフセットによって再送信されるべきRLC PDUセグメントの位置を示すセグメントオフセットを含む。この例では、801から1200までの欠落した400バイトが再送信されることになるので、セグメント化オフセットSO=801である。次いで欠落した400バイトに対応する再セグメント化されたRLC PDUがMAC層に配信される。
次いでMAC層は、受信したRLC PDUのセグメント化を行い、MAC PDU1(200バイトのデータを含む)とMAC PDU2(同様に200バイトのデータを含む)とを形成し、これらは次いで、初回送信について図6を参照して上述したように、TTI0とTTI1とにそれぞれ送信される。当然ながら、MAC層は一般に、必要な場合にのみセグメント化を行う。ここでこの例では、許可サイズは十分ではなく、それが、MAC層がMAC PDU1とMAC PDU2とを形成する理由である。割当が十分である場合、セグメント化は不要であり、またはおそらく連結が行われる(割当が1つのMAC PDUに必要とされるよりも大きい場合)。
特に、MAC層は、RLCヘッダからSOフィールドおよびLSFフィールドを読み取り、許可サイズに基づいて、すなわちこの例では、200バイトと200バイトのセグメント化サイズをそれぞれ反映するようにそれらを変更する。図8から分かるように、MAC層は、セグメント化されたMAC PDUのそれぞれのヘッダにおいて新しいセグメント化情報、すなわち、初回送信の(再セグメント化されていない)RLC PDU内の再送信されるべきデータの新しいセグメントの位置に対応する、SO=801およびSO=1001とLSFとを提供する。図9に、図8からのMAC PDU1およびMAC PDU2が両方とも正しく受信された例を示す。MAC層は、正しく受信されたMAC PDU1およびMAC PDU2をRLC層に配信する。RLC層は、MACセグメントの並べ替えおよび再組立てを行い、次いで完全なPDCP PDUをPDCP層に配信する。並べ替えは、シーケンス番号(SN)に基づいて行われる。上述したように、有利には、オーバーヘッドを節約するために、PDCP層とRLC層の両方に単一のシーケンス番号が使用される。
言い換えると、RLC RXは、(再送信された、または初回送信後に正しく受信された)RLC PDUのすべてのセグメントを収集し、MACヘッダ情報に基づいてそれらを並べ替え、RLC PDUを再組立てする。再組立てされたPDUは次いで、さらに処理するために、(PDCP、またはPDCPがない場合は直接IPなどの)上位層に提供されうる。
したがって、本開示は、以下の表2に示すように、RANプロトコルスタックの異なるレイヤによって行われる機能を変更する。
以下の表3〜表5に、それぞれのレイヤ、PDCP、RLCおよびMACのヘッダの例を示す。
上記の表では、シーケンス番号の長さは10ビットとして例示されている。しかしながら、これは一例にすぎず本開示を限定するものではないことに留意されたい。すでにLTEでは、無線ベアラの特性に応じて、PDCPシーケンス番号の長さを、5ビット、7ビット、または12ビットとすることができる。当業者には明らかなように、シーケンス番号の長さはシステム設計の問題であり、本開示では任意の長さになるように選択されうる。
図6に示すように、PDCP PDUは受信側のRLC層に送信される。有利には、PDCP層、RLC層およびMAC層は、これらすべてのレイヤによって理解されるユニバーサルシーケンス番号を使用する。この例では、PDCPシーケンス番号が使用され、PDCPシーケンス番号は、3つのレイヤすべてによって、または、SNは下位層では必ずしも必要とされないので、少なくともPDCPとRLCとによって理解される。
RLC層は、RLC PDU、例えば、完全なPDUかセグメント化されたPDUかを示すRFフィールドに、関連するRLCヘッダを含める。RF値は、最初は0に設定され、状況通知がRLC TXに到着すると更新される。送信側は、RLCデータPDUを送信するときに、起こりうる再送信のためにRLC PDUを再送信バッファにまだ格納している。再送信は、状況通知によって受信側から要求されうる。図6から分かるように、次いでRLC PDUはMAC層に配信される。その後、送信側MACエンティティは、上位層(RLC)から受信したMAC SDUに対してセグメント化および/または連結を行って、(1つまたは複数の)MAC PDUを形成する。
各送信機会(TTI)におけるMAC PDUのサイズは、無線チャネル条件およびそのために利用可能な送信リソースに応じて、MAC層自体によって決定され通知される。背景技術の項で述べたように、各TTIで異なる割当が可能になる(例えば、リンク適応を向上させるための様々な変調および符号化方式による異なる量のデータを収容できる)ように共有チャネルに動的スケジューリングが適用されうる。
よって各送信MAC PDUのサイズは異なりうる。送信側MACエンティティは、RLC PDU/MAC SDUを、それらがMACエンティティに到着する順序でMAC PDUに含める。したがって、単一のMAC PDUは、MACが、それぞれのセグメントサイズおよび割り当てられたリソースに応じてセグメント化だけでなく連結も行いうるため、完全なRLC PDUまたはRLC PDUセグメントを含む可能性がある。MAC PDUがN(Nは0よりも大きい整数)個のRLC PDUおよび/またはPDUセグメントを含む場合には、MAC層は、すべてのそれぞれの対応するRLC PDUおよび/またはPDUセグメントについてN−1個のLengthフィールド(L‐field)、すなわち、最後のものを除くRLC PDUおよび/またはPDUセグメントごとに1つのL‐fieldを含むことになる。
受信側では、図7に示すように(図6〜図9の例は連結ではなくセグメント化に関連するのでLIフィールドは示されていない)、MAC層は、ヘッダの長さと、L‐fieldで、MAC PDUの長さの両方を知っているので、実際のデータがどこから開始するかを知っている。ここではヘッダの長さが分かっているものと仮定する。例えば、ヘッダの長さは予め定義されており(例えば規格で指定されており)かつ/またはヘッダのフィールド内に示されていてよい。上記の例では、拡張ビットは、ヘッダが継続するかそれとも終了するかを示すために使用され、それによってヘッダサイズを決定することが可能になる。
MAC層はセグメント化フィールド(SOおよびLSF)を除去することなくMAC PDUの多重分離を行い、次いで多重分離されたRLC PDU/セグメントはRLC層に配信される。受信側RLC層は、RLC PDUセグメントを受信すると、それらが順不同で受信された場合には、それらをまず並べ替えて再組立てする(図9も参照)。MAC層で並べ替えおよび再組立てを行わない利点の1つは、処理時間の短縮である。受信側で1つのセグメントが欠落している場合には、MAC層は再組立ておよび並べ替えを行うことができず、そのため上位層(RLC)への配信に遅延が加わることになる。再組立ておよび並べ替えを遅延させないように、MAC層は、図6を参照して上述したように、セグメント化および連結はMAC層によって行われるため、セグメント化フィールド(SO、LSF)をRLC層に渡す。したがって、RLC層は、MAC層から受信した(1つまたは複数の)セグメント化ヘッダフィールドを読み取り、セグメント化(SO、LSFなど)および連結(LIなど)の(1つまたは複数の)ヘッダフィールドに基づいて、RLC層は、適切な場合には、並べ替えおよび再組立てを行う。したがって、この例では、受信側RLC層がMAC層シグナリングフィールドを理解し、使用しなければならないので、クロスレイヤインタラクションが必要である。
MAC層で順不同に受信されたRLC PDUは、上位層(RLC)に配信される。誤りのない送信をサポートするために受信側RLCにおいてARQ動作が行われる(確認モード)。送信側が欠落したRLC PDUのみを再送信することができるように、受信側は送信側に、RLC PDUの欠落した(1つまたは複数の)PDUまたは(1つまたは複数の)PDUセグメントの情報を示すRLC状況通知を提供する。
欠落した1つまたは複数のPDU/セグメントを伴った状況通知に応答して、RLC層の送信側は、送信バッファから対応する欠落したパケットの完全なRLC PDUを取り出し、RLC状況通知によって示されている欠落した(1つまたは複数の)セグメントに基づいて(再)セグメント化を行う。状況通知の受信後に再セグメント化が行われた場合、RLCはRFフィールドを0から1に変更する。次いで、(再)セグメント化された(1つまたは複数の)PDUがMAC層に配信され、MAC層はRFフラグを読み取る。無線条件は再送信手順の間に悪化しうるので、欠落した1つまたは複数のPDUは、(MAC層によって行われる)再送の前により小さいセグメントに分割(再セグメント化)されなければならない可能性がある。これが図8に示されており、欠落した400バイトのペイロードのRLC PDUは、RLC層において再送信バッファ内の元の1200バイトのペイロードのRLC PDUから取り出され、より小さい200バイトのペイロードのMAC PDUにさらに分割(再セグメント化)される。
[MAC層における再セグメント化]
図8を見ると、RLC送信側が、セグメントの欠落した部分に基づいて、すなわち、正しく受信されなかった、RLC状況通知によって示されMAC層に配信される400バイト長のデータに基づいて再セグメント化を行うので、RLCオーバーヘッドがわずかに増大することが分かる。したがって、RLCでは(SO、RFおよびLSFを含む)再セグメント化ヘッダが必要であり、これによりRLCヘッダのオーバーヘッドが増大する。
オーバーヘッドを削減するために、一実施形態によれば、再セグメント化はMAC層で行われる。
特に、この実施形態によれば、通信システムにおいて無線インターフェース上でデータ受信ノードにデータを送信するためのデータ送信ノードが提供される。データ送信ノードは、データ受信ノードからフィードバックされた状況通知に従って自動再送要求、ARQ、再送信を行うための第3層処理ユニットを含む。データ送信ノードは、第3層処理ユニットから、第3層データユニットを受信し、状況通知に従い、リソース割当に基づいて第3層データユニットをセグメント化し、セグメント化された第3層データユニットのそれぞれのセグメントを含む複数の第2層データユニットを形成するための第2層処理ユニットをさらに含む。第2層から、複数の第2層データユニットを受信し、複数の第2層データユニットをデータ送信に割り当てられたリソース上にマップするための第1層処理ユニットも存在する。
したがって、セグメント化機能は、物理層に最も近いレイヤである第2層に完全に移される。これを選択された例に基づいて図10においてより詳細に示す。
送信側のRLC層は、PDCP PDU(RLC SDU)に、状況通知を要求するポーリングビット(この実施形態がUMではなくAMで適用される場合)と、RLC PDUが搬送するのがペイロード(ユーザ)データかそれとも制御データかを示すD/Cフィールドとを含むヘッダを追加する。RLC層は非確認モードでも動作しうるので、本開示は、ARQを行うRLC層に限定されないことに留意されたい。
RLC TX層は、RLC RXから受信した状況通知をMAC層に配信する。MAC層は、シーケンス番号(SN)、SOstartおよびSOend値などのセグメント化情報を状況通知から読み取り、それに応じてセグメント化を行う。したがって、RLC TXは再送信バッファから完全なRLC PDUを取り出し、それをMAC TXに送信する。これは図10に例示されており、図10には、図8に示すような400バイトのみではなく1200バイトのPDCP SDUデータを有するデータフィールドを含むRLC PDUが示されている。
その後、MAC TX層は、図10に示すように、RLC状況通知によって示され、RLC層によってMAC層に転送されるSOstart、SOend、SNなどのセグメント化情報に基づいてセグメント化を行う。それに従って、MAC PDUヘッダが生成される。図10のヘッダは、LCID(論理チャネル識別)と、さらなるヘッダ情報が存在するか否かを示すEビットと、ここでは、RLC PDU内の搬送セグメントの開始を示すセグメントオフセット(バイト単位でありうる)およびカプセル化されたRLC PDUセグメントがRLC PDU内の最後であるか否かを示す最後のセグメントフィールド(LSF)を含む、セグメント化情報とを含む。図10から分かるように、200バイトと200バイトの2つのセグメントのための801と1001のオフセットがそれぞれシグナリングされる。
図11Aに、非特許文献7で定義されている状況通知(STATUS PDU)を示す。STATUS PDUは、STATUS PDUペイロードとRLC制御PDUヘッダからなる。RLC制御PDUヘッダは、D/CとCPTフィールドからなる。STATUS PDUペイロードは、RLC制御PDUヘッダに続く最初のビットから開始し、1つのACK_SNおよび1つのE1と、NACK_SN、E1およびE2の0個以上のセットと、おそらくは、NACK_SNごとのSOstartとSOendのセットからなる。必要に応じて、オクテット整列を達成するためにSTATUS PDUの終わりに1〜7個のパディングビットが含められる。
図11Bに、RLC状況通知の例示的フォーマットを示す。この例示的な状況通知は、図11Aに例示されたLTE状況通知と類似しており、類似したフィールドを含む。図11Bの状況通知は、RLCシーケンス番号ではなくPDCPシーケンス番号が伝達されるという点で、図11AのLTE状況通知とは異なる。
特に、状況通知は、D/Cフィールドと、PDUが状況PDUであるか否かを示すCPT(コントロールPDUタイプ)フィールドとを含み、状況通知の状況PDUを示す。PDCP ACK_SNは、状況通知(STATUS PDU)において欠落していると通知されていない次の未受信RLCデータPDUのSNを示す10ビットの長さのフィールドである。接頭辞「PDCP」は、ここでは、共通のSNがRLCとPDCP層に使用されており、よって状況通知にも適用されることを強調するものである。
拡張ビット1(E1)は、PDCP NACK_SN、E1、およびE2のセットが後に続くか否かを示す。0に設定されている場合、NACK_SN、E1、およびE2のセットは後に続かず、1に設定されている場合、NACK_SN、E1、およびE2のセットが後に続く。
否定応答SN(NACK_SN)、この例ではPDCP NACK_SNフィールドは、AM RLCエンティティの受信側で失われたと検出されたRLC PDU(またはその一部分)のSNを示す。
拡張ビット2(E2)は、SOstartとSOendのセットが後に続くか否かを示す。0に設定されている場合、SOstartとSOendのセットはこのNACK_SNの後に続かず、1に設定されている場合、SOstartとSOendのセットがこのNACK_SNの後に続く。
36.322によれば、セクション6.2.2.18、セクション6.2.2.19に、これらのSOstartとSOendを次のように記載する。
− SOstart(15ビット):SOstartフィールドは(SOendフィールドと共に)、AM RLCエンティティの受信側で失われたと検出されたSN=NACK_SN(そのSOstartが関連するNACK_SN)を有するRLC PDUの部分を示す。具体的には、SOstartフィールドは、RLC PDUのDataフィールド内のRLC PDUの部分の最初のバイトの位置をバイト単位で示す。
− SOend(15ビット):SOendフィールドは(SOstartフィールドと共に)、AM RLCエンティティの受信側で失われたと検出されたSN=NACK_SN(そのSOendが関連するNACK_SN)を有するRLC PDUの部分を示す。具体的には、SOendフィールドは、RLC PDUのDataフィールド内のAMD PDUの部分の最後のバイトの位置をバイト単位で示す。特別なSOend値「111111111111111」は、AMD PDUの欠落した部分がAMD PDUの最後のバイトまでのすべてのバイトを含むことを示すために使用される。
言い換えると、SOstartとSOendとは、否定応答されたRLC PDUセグメントの開始と終了とをそれぞれ示す。
[セグメント番号]
セグメントオフセット(開始と終了を合わせて)は、通常は長さ30ビットであり、特に小さいセグメントでは、MACサブヘッダのオーバーヘッドを増大させる。
オーバーヘッドを削減するために、この実施形態では、セグメント識別は、よって、第3層データユニット内の第3層データユニットのセグメントのシーケンス番号を示すセグメント番号である。このセグメント番号は、図に示されるように、すなわちSOフィールドの代わりにデータPDUにおいて使用されうる。しかしながら、セグメント番号は有利には、状況通知(STATUS PDU)においてSOstartおよびSOendを置き換えるためにも使用されうる。
一例では、MACサブヘッダ(すなわち、セグメント化に関連したヘッダの部分)は、30ビットのセグメントオフセット(15ビットのSOstartと15ビットのSOend)の代わりに4ビットの長さのセグメント番号を使用することによって削減される。よって、MAC層は、セグメント番号を示す4ビットに基づいてセグメント化を行う。4ビットのセグメント番号は最大16個のセグメントを区別することを可能にする。しかしながら、4という数はここでは例示のためのものにすぎない。対応するユーザプレーン層アーキテクチャに、より多くのまたはより少ないセグメントが必要である場合、もっと多くのビットを使用してこれを行うこともできる。この実施形態の手法は、RLC PDU内の各セグメントの開始と終了の代わりに、セグメントごとのセグメント番号をシグナリングすることによってオーバーヘッドを削減するものである。セグメントの数はオフセットが関連しているRLC PDU内のビット数より確実に小さいので、オーバーヘッドは一般に、オフセットではなくセグメントをアドレス指定することによって節約される。
セグメント番号の使用を送信側について図12に示す。特に、図12には、PDCP層に提供されたIPパケットが示されており、ここで、IPパケットは、D/CフィールドおよびPDCP SNを追加され、このヘッダ情報と共にRLC層に提供される。RLC層は、D/Cフィールドとポーリングフィールドとを含む独自のヘッダを追加することによってPDCP PDUをカプセル化する。ここでは、RLC層でセグメント化が行われないので、RFフィールドは不要である。むしろ、RLC PDU1全体がMAC層に提供される。
図12に示すように、MAC層では、RLC PDUは、800バイトと400バイトとをそれぞれ含む2つのセグメント、セグメント0とセグメント1とに分割される。このセグメント化は、割当サイズに基づいて行われうる。RLC PDUのセグメント化の後、送信側MACエンティティは、MAC PDUを形成する関連するMACヘッダを含む。特に、ヘッダは、含まれるRLC PDUについてのセグメントの長さを示す長さインジケータ(LI)、セグメント番号(例えば上述した4ビット)、最後のセグメントフィールド(LSF)、および0に設定されたフィールドR(再セグメント化が続いて行われないことを示す)を含む。LIフィールドは、1つのMAC PDUが2つ以上のRLC PDUを含む連結の場合に必要である。セグメント化の場合には、許可サイズは知られており、そのため受信側は許可のサイズを知っており、それに応じて逆の動作を行うことができる。
MAC層は次いで、セグメント化情報に基づいて、図12にMAC PDU1およびMAC PDU2として示されている2つのMAC PDUを形成する。MAC PDU1とMAC PDU2とは、それぞれの送信時間間隔TTI0とTTI1とにそれぞれ送信される。
図13に、セグメント番号がセグメントオフセットの代わりに用いられるこの実施形態についての例示的な受信側レイヤ処理を示す。
図13に示すように、受信側では、MAC PDU1が正しく受信され、MAC PDU2が失われる。MAC層は、MAC PDU1を(R、セグメント番号およびLSFを含む)セグメント化ヘッダと共にRLC層に配信し、受信側のRLC層は、欠落した800〜1200バイト(すなわち、MAC PDU2)を示す状況通知を送信側RLCエンティティに送信する。RLC層は次いで、RLCセグメントの再組立ておよび並べ替えを行う。ここでは、最初の800バイトのセグメントだけが正しく受信されており、よってこの例では並べ替えを行う必要はない。
図14に、データ受信側から状況通知を受信した際の例示的な送信側レイヤ処理を示す。図14に示すように、RLC層は再送信バッファから完全なRLC PDUを取り出す(これは、欠落した400バイトだけではなく、RLC PDUに含まれる1200バイトのPDCP SDUデータによって示されている)。MAC層は次いで、RLC状況通知に基づいて再セグメント化を行う。
RLC PDUの再セグメント化の後、送信側MACエンティティは、それぞれの含まれるRLC PDUについての長さ(LI)、3ビットのリセグメント番号、最後のリセグメントフィールド(LRF)およびR=1(再セグメント化が後に続くことを示す)を示すためにそれぞれの再セグメント化MAC PDUに関連するMACヘッダを含め、図14でMAC PDU1およびMAC PDU2として示されているMAC PDUを形成する。
必要ならば、MAC層は、例えば、RLC状況通知で通知された欠落したセグメントが、(LCPの実行後に)対応するLCIDに使用可能な許可に収まらない場合に、セグメント番号の欠落した部分の再セグメント化を行いうる。このために、MACは、例えば3ビット(または必要ならばそれ以上)を使用して、RLC PDUの対応するセグメントの「リセグメント」を識別しうる。
要約すると、第2層処理ユニットは、第2層データユニットのヘッダに、第3層データユニットのセグメント内の第3層データユニットのセグメントのシーケンス番号を示すリセグメント番号を含むセグメント識別を含め、リセグメント番号はセグメント番号より少ないビット数を使用してシグナリングされる。しかしながら、これは本開示を限定するものではないことに留意されたい。セグメント番号とリセグメント番号のサイズは同じであってもよい。「リセグメント」に用いられうる別の用語は、「サブセグメント」である。というのは、それが前のセグメント化の結果として得られるセグメントのサブセグメントだからである。
図14では、再送はさほど頻繁ではなく、よってより大きいオーバーヘッドが許容できると仮定されているので、代替として、セグメントにセグメント番号が使用され、サブセグメントにサブセグメント番号の代わりにセグメントオフセットが使用されうる。
図15に、図14に示すMAC PDU1およびMAC PDU2の再送信を受信した際の受信側レイヤ処理を示す。
図15に示すように、MAC層は、MAC PDU1およびMAC PDU2の多重分離を行い、それらのヘッダの一部を除去する。しかしながら、並べ替えおよび再組立てはRLC層で行われるので、MAC層は、関連するセグメント化ヘッダフィールド(Rフィールド、セグメント番号、LSF、LRFおよびリセグメント番号)を保持する。RLCは次いで、MACセグメントの並べ替えおよび再組立てを行い、その結果(PDCP PDU)をPDCP層に送信する。
[第2層での並べ替えおよび再組立て]
本開示の別の実施形態によれば、受信側はさらに変更される。特に、並べ替えおよび再組立てをRLC層で行う代わりに、MAC層が並べ替えおよび再組立てを行う。その場合、クロスレイヤインタラクションは不要である。この構成では、MAC層は再送信処理の実行も担当する。セグメントのいずれかの部分が欠落している場合、MAC層の受信側エンティティはMAC TXに状況通知を送信する。MAC状況通知はRLC状況通知とわずかに異なる。特に、どの状況通知がどのLCID(論理チャネル)に属するかを区別するために状況通知にLCIDフィールドが設けられる。
言い換えると、通信システムにおいて無線インターフェース上でデータ送信ノードからデータを受信するためのデータ受信ノードであって、本データ受信ノードは、データ送信に割り当てられたリソースから複数の第2層データユニットのうちの1つまたは複数を逆マップし、複数の逆マップされた第2層データユニットのうちの1つまたは複数を第2層処理ユニットに提供するための第1層処理ユニットと、複数の第2層データユニットのうちの1つまたは複数からの複数の第3層ユニットセグメントおよびセグメント化制御情報の多重分離を行い、複数の多重分離された第3層ユニットセグメントをセグメント化制御情報と共に第3層処理ユニットに転送するための第2層処理ユニットと、を含む。さらに、第2層処理ユニットは、複数の多重分離された第3層ユニットセグメントの並べ替えおよび多重分離された第3層ユニットセグメントの第3層データユニットへの組立ても行っている。第2層処理ユニットはまた、データが正しく受信されたか否かを確認し、ピア第2層エンティティに状況通知を送信するようにも構成されうる。受信側のこの実施形態は、セグメント化/連結が上述した第2層で行われる受信側の実施形態に特に適している。
[より多くのリンクに対するより多くのeNBの同じベアラについてのmulti‐connectivity/dual connectivity]
multi‐connectivityの場合、PDCP層は重複したパケットを異なるeNBに配信する。
以下の表7に、各レイヤの主な機能を有するmulti‐connectivityのプロトコルスタックを記載する。
図16に、multi‐connectivityをサポートするこの実施形態によるIPパケット1の新規送信の場合の送信側レイヤ処理を示す。
特に、第1層は物理層であり、第2層は媒体アクセス制御、MAC、層であり、第3層はパケットデータ制御プロトコル、PDCP、層である。しかしながら、PDCP層とRLC層とは1つの層に結合されてもよく、またはRLCがその機能を行ってもよいことに留意されたい。第3層処理ユニットは、無線インターフェース上で、異なるそれぞれの基地局、または一般的にデータ受信ノードに送信するために、同じ第3層データユニットを異なる下位層スタックに提供するように構成される。下位層スタックは、個々に、互いに独立してセグメント化/再組立てを行うことができる。下位層スタックは、物理層とMACとを含みうる。しかしながら、下位層スタックは、RLC層をさらに含んでいてもよい。
やはり上述したように、このレイヤは、現在のLTE層とは異なる名称で呼ばれ、異なる機能を有しうる。一般に、multi‐connectivityには、上位層からパッカーを受信し、それぞれの複数のスタックの下位層に独自のPDUとしてカプセル化されたパケットの複数(2つ以上)のコピーを提供する共通の1つの層がある。複数のスタックは、上記の実施形態のいずれかに記載されているように、別々に、互いに独立してセグメント化および再組立てを処理し、それによって複数のスタックがそれぞれの物理チャネル条件およびデータ受信の状況に適応できることが保証される。
第3層は有利には再送信処理を制御する。上記のmulti‐connectivityのシナリオでは、受信側の各下位層スタックがパケットを正しく受信して再組立てする必要はない。他のすべてのスタックからパケットのセグメントを収集するそれらのうちの1つがパケットを再組立てすることができれば十分である。これによりある種の多様性が提供され、スループットが増加する。
図16に示すように、IPパケット1はPDCP層のPDCPヘッダに添付され、対応するPDCP PDUは2つの異なる基地局、ここではeNB1とeNB2とに送信される。基地局eNB1とeNB2と(ネットワークノード)は、上述したようにプロトコル層をそれぞれ実装する(RLC/MAC/PHY)。eNB1は、RLC PDU1に対応するPDCP PDUを、それぞれ800バイトと400バイトとを含む2つのセグメントMAC PDU1とMAC PDU2とに渡す。異なるセル内のチャネル品質は異なりうるので、eNB2は異なるセグメント化を用いる場合がある。よってこの例では、eNB2は、RLC PDU1を、それぞれ500バイトと700バイトとを含む2つのセグメントMAC PDU1とMAC PDU2とにセグメント化する。RLC層は、確認モードで動作している場合、ARQ機能をさらに担当しうる。しかしながら、上述したように、PDCPはRLC再送信を制御しうる。特に、(それぞれのeNBの)各RLC層は、マスタeNBのPDCPに状況通知を渡すことができ、マスタeNBは、再送信が必要であるか否か、およびパケットのどのセグメントについてかを決定する。PDCPは次いで、それぞれのRLC層に再送信をしかるべく行うように指示する。
図17に受信側の処理を示す。図17に示すように、eNB1は、0〜800バイトを含むMAC PDU1を受信するが、801〜1200バイトのMAC PDU2は失われる。他方、eNB2は、0〜500バイトを含むMAC PDU1を受信するが、501〜1200バイトは、MAC PDU2の欠落により失われる。PDCP層は、中央の並べ替えおよび再組立てを行う。
この実施形態でRLC層において並べ替えおよび再組立てを行わないことの利点は、multi‐connectivityの間の不要な再送信を回避することである。再組立ておよび並べ替えがRLC層で行われた場合には、両方のeNBのRLC層がRLC TXにそれぞれ個別のRLC状況通知を送信することになる(eNB1のRLCは801〜1200バイトの状況通知を送信し、eNB2のRLCは501〜1200バイトの状況通知を送信し、これまでのところ実際に欠落した部分は801〜1200バイトである)。この場合、RLC TXは、RLC RXで廃棄されることになる必要以上のセグメントを再送信することになりうる。
この問題を克服するために、この実施形態のRLC層は、可能な限り透過的に機能し、中央の並べ替えおよび再組立て機能は、PDCP層で実行される。並べ替えおよび再組立てを行うために、セグメント化はMACで行われているので、PDCP層はMAC層のセグメントヘッダ(SOおよびLSF)を理解しなければならない。PDCPは、RLC層についての上記の実施形態で説明したのと同様に、MAC層からPDUを受信し、中央の並べ替えおよび再組立てを行う。それは共通セグメントを重ね合わせ、セグメントの欠落した部分、すなわちeNBのいずれによっても正しく受信されていない部分のみを示す状況通知を送信する。
図17を見ると、MAC PDUは上述したようなセグメント化情報、すなわち、SOおよびLSFを含むことが分かる。しかしながら、その他の実施形態と同様に、セグメント化情報は、代わりにセグメント番号およびセグメントの長さを含んでいてもよい。さらに、図15に、オーバーヘッドを削減するためのRLC層におけるPDCP SNの使用も示す。しかしながら、本開示はこれに限定されず、一般に、現在のLTEの場合と同様に、PDCP層とRLC層とに別々のシーケンス番号が使用されてもよい。上述したように、クロスレイヤ設計は伝送の効率を向上させうる。特に、状況通知は、有利には、協調層(第3、PDCP)の下位のレイヤ(RLC)で送受信され、受信されたセグメントをマッチングし、どのセグメントが送信されるべきかを決定するために協調層に提供される。さらに、MACセグメント化情報は、並べ替えおよび再組立て、ならびに再送信の協調を可能にするために、協調層に渡されうる。
しかしながら、本開示は、PDCPが再送信協調を行わない場合およびセグメントが各リンク上で実際に重複して再送信される場合に、わずかに効率が悪いときでさえも、やはり機能しうることに留意されたい。 有利には、図17において、PDCP RXは、欠落した801〜1200バイトの状況通知を送信する。有利には、この状況通知は両方の(一般的には複数の)eNBに送信され、そのため両方のリンク上で再送信によってダイバーシチが達成される。しかしながら、本開示はこれに限定されず、一般に、再送信のためには、単一の接続が再確立されうる。
図18に示すように、PDCP TXは、状況通知を受信すると、送信バッファから完全なPDCP PDU(1200バイト)を取り出し、PDCP状況通知によって示されている800〜1200バイトの再セグメント化(抽出)を行い、次いで800〜1200バイトのPDUセグメント(リセグメントPDU)がMACに配信される。各eNBのMAC層は、上記の実施形態で説明したように、リソース割当に従って独自のセグメント化を行う。この場合、図18から分かるように、(eNB1に送信する)第1のMACエンティティは、801〜1200バイトを2つのMAC PDU、すなわち、801〜900バイトのMAC PDU1と901〜1200バイトの第2のMAC PDU2とにセグメント化する。他方、(eNB2に送信する)第2のMACエンティティは、801〜1200バイトをバイト801〜1000バイトの第1のMAC PDU1と1001〜1200バイトの第2のMAC PDU2とにセグメント化する。
一般には、代替方法もある。すなわち、前述したように、PDCPは再送信バッファから完全なPDUを取り出し、次いで、PDCP状況通知によって示されている欠落したパケットの再セグメント化を行う。
しかしながら、代替として、PDCP状況通知は、MAC層によって理解されてもよく、したがって、PDCPは、再セグメント化を行うのではなく、完全なPDUをMACに渡す。MACはその場合、PDCP状況通知に基づいてセグメント化を行うことになる。
さらに別の可能な方法は、PDCPがRLCに、セグメントの(1つまたは複数の)欠落した部分について知らせることであろう。その後、RLC層は状況通知をRLC TXに送信する。
それに対応して、図19に、図18の再送信を受信した際の受信側(この上りデータ送信の例ではネットワーク側)を示す。特に、この例では、すべてのセグメントがMACで正しく受信され、多重分離されている。RLCは、基本的に、受信したセグメントをMACから受信したセグメント化情報と共にPDCPに渡し、PDCPは、マルチコネクションのすべてのノード(ここではeNB1とeNB2)から受信したすべてのセグメントの並べ替えおよび再組立てを行う。
図20に、通信システム2000の一部でありチャネル2090上で通信する送信装置2000tと受信装置2000rとを示す。特に、第4層処理ユニット2040t、第3層処理ユニット2030t、第2層処理ユニット2020t、および第1層処理ユニット2010tは、上記実施の形態に記載されているように対応するレイヤの処理を行う。送信部2050は、その(1つまたは複数の)アンテナを介して物理リソース上にマップされた信号を送信する。受信装置2000rは、これに対応して、第4層処理ユニット2040r、第3層処理ユニット2030r、第2層処理ユニット2020r、および第1層処理ユニット2010rと、その(1つまたは複数の)アンテナ上で送信された信号を受信する受信部2060とを含む。
図21に、本開示に係る方法の実施形態のうちの1つを例示する。特に、左側にはデータ送信側で行われる方法を示し、右側にはデータ受信側で行われる方法を例示する。
本送信方法は、第3層SDUを受信する工程2110tと、第3層SDUに基づいて、例えばヘッダを添付することによってPDUを生成する工程2120tと、PDUを第2層に渡す工程2130tとを含む、第3層によって行われる工程を含みうる。次いで第2層処理は、第3層PDUを第2層SDUとして受信する工程2140tと、受信した割当に基づいて(いくつかの実施形態では状況通知にも基づいて)、上述したようにセグメント化または連結を行う工程2150tと、そのように形成されたPDUを第1層に渡す工程2160tとを含みうる。次いで第1層処理は、第2層からSDUを受信する工程2170tと、SDUを物理リソースにマップする工程2180tと、送信する工程2190tとを含む。
受信側では、第1層処理の一部として、受信2190rが行われ、次いでデータは物理リソースから逆マップされ2180r、第2層に渡される2170r。第2層処理は、PDUを受信する工程2160rを含み、PDUを多重分離し2150r、並べ替えおよび再組立てのために第3層に渡す2140r(上述したように、1つの代替の実施形態では、並べ替えおよび再組立ても第2層で行われる)。第3層処理は、PDUを受信する工程2130rと、並べ替えおよび再構成を行う工程2120rと、再組立てされたパケットを上位層に渡す工程2110rとを含む。
さらに、データ受信側での状況通知の送信と、データ送信側で状況通知を受信する工程2128tとを含む、第3層で再送信機構を実装する実施形態がある。状況通知がいくつかのセグメントについての否定応答を含む場合(2125t、「はい」)、再セグメント化は第3層で(あるいは、いくつかの実施形態では第2層で)行われる。
[本開示のハードウェアおよびソフトウェア実装]
他の例示的な実施形態は、ハードウェアおよびソフトウェアを使用した上述の様々な実施形態の実装に関するものである。これに関連して、ユーザ端末(移動端末)およびeNodeB(基地局)が提供される。ユーザ端末および基地局は、受信部、送信部、プロセッサなど、方法に適切に関与する対応するエンティティを含む、本明細書に記載した方法を行うように適合される。
様々な実施形態は、コンピューティングデバイス(プロセッサ)を使用して実装または実行されうることをさらに理解されたい。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ(DSP:digital signal processor)、特定用途向け集積回路(ASIC:application specific integrated circuit)、フィールド・プログラマブル・ゲート・アレイ(FPGA:field programmable logic array)または他のプログラマブル論理回路などであってもよい。これらは、そこに結合されたデータ入出力を含みうる。様々な実施形態は、これらのデバイスの組み合わせによっても実行または具体化されうる。
さらに、様々な実施形態は、プロセッサによって、またはハードウェアにおいて直接実行されるソフトウェアモジュールによって実装されてもよい。また、ソフトウェアモジュールとハードウェア実装との組み合わせも可能である。ソフトウェアモジュールは、例えば、RAM、EPROM、EEPROM、フラッシュメモリ、レジスタ、ハードディスク、CD‐ROM、DVDなどの任意の種類のコンピュータ可読記憶媒体に格納されてよい。
異なる実施形態の個々の特徴は、個別にまたは任意に組み合わせて、別の実施形態の主題としうることにさらに留意されたい。
当業者には、特定の実施形態において示される本開示に対して多くの変形および/または修正が行われうることができることが理解されよう。したがって、本明細書の実施形態は、あらゆる点で例示的であり、限定的ではないとみなされるべきである。
要約すると、本開示は、通信システムにおける受信側と送信側とにおけるレイヤ処理に関するものである。レイヤ処理は、少なくとも第1層、第2層、および第3層における処理を含む。送信側では、第3層は、パケットを受信し、パケットのヘッダを追加し、パケットを第2層に転送する。第2層は、セグメント化を行い、セグメント化されたデータを第1層に提供し、第1層はセグメント化されたデータを物理リソース上にマップする。セグメント化は割り当てられたリソースに基づくものである。再送信は第3層で行われてもよく、よって、第3層は特定のセグメントについて受信したフィードバックに従ってパケットを再セグメント化し、再セグメント化されたデータを下位層に提供しうる。あるいは、フィードバック情報は第2層に提供され、その場合第2層はフィードバック情報を考慮に入れてセグメント化を行う。それに対応して、受信側は、第3層で並べ替えおよび再組立てを行い、またそのための制御情報を第2層から受信する。