特表2016-513896(P2016-513896A)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ホアウェイ・テクノロジーズ・カンパニー・リミテッドの特許一覧
特表2016-513896逐次干渉除去(SIC)をサポートするための前方誤り訂正(FEC)
<>
  • 特表2016513896-逐次干渉除去(SIC)をサポートするための前方誤り訂正(FEC) 図000003
  • 特表2016513896-逐次干渉除去(SIC)をサポートするための前方誤り訂正(FEC) 図000004
  • 特表2016513896-逐次干渉除去(SIC)をサポートするための前方誤り訂正(FEC) 図000005
  • 特表2016513896-逐次干渉除去(SIC)をサポートするための前方誤り訂正(FEC) 図000006
  • 特表2016513896-逐次干渉除去(SIC)をサポートするための前方誤り訂正(FEC) 図000007
  • 特表2016513896-逐次干渉除去(SIC)をサポートするための前方誤り訂正(FEC) 図000008
  • 特表2016513896-逐次干渉除去(SIC)をサポートするための前方誤り訂正(FEC) 図000009
  • 特表2016513896-逐次干渉除去(SIC)をサポートするための前方誤り訂正(FEC) 図000010
  • 特表2016513896-逐次干渉除去(SIC)をサポートするための前方誤り訂正(FEC) 図000011
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】特表2016-513896(P2016-513896A)
(43)【公表日】2016年5月16日
(54)【発明の名称】逐次干渉除去(SIC)をサポートするための前方誤り訂正(FEC)
(51)【国際特許分類】
   H03M 13/19 20060101AFI20160411BHJP
   H04L 1/00 20060101ALI20160411BHJP
   H03M 13/23 20060101ALI20160411BHJP
   H03M 13/29 20060101ALI20160411BHJP
【FI】
   H03M13/19
   H04L1/00 B
   H03M13/23
   H03M13/29
【審査請求】有
【予備審査請求】未請求
【全頁数】19
(21)【出願番号】特願2015-560535(P2015-560535)
(86)(22)【出願日】2014年3月5日
(85)【翻訳文提出日】2015年10月14日
(86)【国際出願番号】CN2014072927
(87)【国際公開番号】WO2014135084
(87)【国際公開日】20140912
(31)【優先権主張番号】13/787,554
(32)【優先日】2013年3月6日
(33)【優先権主張国】US
(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LT,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US
(71)【出願人】
【識別番号】504161984
【氏名又は名称】ホアウェイ・テクノロジーズ・カンパニー・リミテッド
(74)【代理人】
【識別番号】100146835
【弁理士】
【氏名又は名称】佐伯 義文
(74)【代理人】
【識別番号】100140534
【弁理士】
【氏名又は名称】木内 敬二
(72)【発明者】
【氏名】アーロン・カラード
(72)【発明者】
【氏名】モハンマドハディ・バリーグ
【テーマコード(参考)】
5J065
5K014
【Fターム(参考)】
5J065AC02
5J065AD07
5J065AE02
5J065AG08
5J065AH20
5K014BA05
(57)【要約】
独立して復号可能なリソースブロックを生成する前方誤り訂正(FEC)技術は、逐次干渉除去(SIC)復調に有益である。独立して復号可能なリソースブロックを生成するための1つのFEC技術は、実質的にFECコードブロックの全てのビットが単一のリソースブロック内で搬送されるように、ローカルに復号可能なFECコードブロックを一意のリソースブロックにマッピングするステップを含む。ローカルに復号可能なFECコードブロックは、異なるFEC符号化モジュールから、または共通のFEC符号化モジュールから生成されることができる。独立して復号可能なリソースブロックを生成するための別の技術は、情報ビットのストリームを、内側ピアリングパリティビットを高い比率で有する低密度パリティ検査(LDPC)コードブロックに符号化するステップを含む。内側ピアリングパリティビットのこれらの高い比率は、各LDPCコードブロックの実質的な部分が他のLDPCコードブロックによって搬送される情報から独立して復号されることを可能にする。
【特許請求の範囲】
【請求項1】
符号化方法であって、
情報ビットのストリームを取得するステップと、
前記情報ビットのストリームを複数の前方誤り訂正(FEC)コードブロックに符号化するステップであって、各FECコードブロックは独立して復号可能である、ステップと、
前記複数のFECコードブロックを複数のリソースブロックにマッピングするステップであって、各FECコードブロックは前記リソースブロックのうちの単一のリソースブロックにマッピングされる、ステップと、
FECコードブロックのリソースブロックへの前記マッピングに従って、前記複数のFECコードブロックをデータストリームとして送信するステップと
を有する方法。
【請求項2】
前記情報ビットのストリームを複数の前方誤り訂正(FEC)コードブロックに符号化するステップは、
第1のFECコードを使用して、前記情報ビットのストリームをFECビットのストリームに符号化するステップと、
前記FECビットのストリームをFECビットの複数のサブセットに分割するステップと、
複数の2次FECコードのうちの一意の一つを使用してFECビットの各サブセットを符号化して、前記複数のFECコードブロックのうちの対応する一つを取得するステップと
を有する、請求項1に記載の方法。
【請求項3】
前記第1のFECコードと前記複数の2次FECコードとが結合してFECプロダクトコードを形成する、請求項2に記載の方法。
【請求項4】
前記複数の2次FECコードのうちの少なくともいくつかは、異なる符号化レートを利用する、請求項2に記載の方法。
【請求項5】
前記FECビットのサブセットのうちの少なくともいくつかは、異なる数のFECビットを有する、請求項2に記載の方法。
【請求項6】
前記情報ビットのストリームを複数の前方誤り訂正(FEC)コードブロックに符号化するステップは、
第1のFECコードを使用して、前記情報ビットのストリームをFECビットのストリームに符号化するステップと、
前記FECビットのストリームをFECビットの複数のサブセットに分割するステップと、
単一の2次FECコードを使用してFECビットの各サブセットを符号化して、前記複数のFECコードブロックのうちの対応する一つを取得するステップと
を有する、請求項1に記載の方法。
【請求項7】
前記第1のFECコードと前記単一の2次FECコードとが結合してFECプロダクトコード形成する、請求項6に記載の方法。
【請求項8】
前記単一の2次FECコードは、ローカルに復号可能なFECコードブロックを生成するように構成される、請求項6に記載の方法。
【請求項9】
前記単一の2次FECコードは、畳み込みコードである、請求項6に記載の方法。
【請求項10】
前記複数のFECコードブロックを前記複数のリソースブロックにマッピングするステップは、
前記複数のFECコードブロックのそれぞれを一意の仮想リソースブロック(VRB)に割り当てるステップ
を有する、請求項1に記載の方法。
【請求項11】
前記複数のFECコードブロックをデータストリームとして送信するステップは、
FECコードブロックのリソースブロックへの前記マッピングに従って、前記複数のFECコードブロックのそれぞれを複数の物理リソースブロック(PRB)のうちの一意の一つにインターリーブするステップであって、前記複数のFECコードブロックのうちの対応する一つの各ビットは共有PRB内で搬送される、ステップ
を有する、請求項1に記載の方法。
【請求項12】
装置であって、
プロセッサと、
前記プロセッサによる実行のためのプログラムを格納するコンピュータ可読記憶媒体とを有し、前記プログラムは、
情報ビットのストリームを取得するための命令と、
前記情報ビットのストリームを複数の前方誤り訂正(FEC)コードブロックに符号化するための命令であって、各FECコードブロックは独立して復号可能である、命令と、
前記複数のFECコードブロックを複数のリソースブロックにマッピングするための命令であって、各FECコードブロックは前記複数のリソースブロックのうちの単一のリソースブロックにマッピングされる、命令と、
前記複数のFECコードブロックの前記複数のリソースブロックへの前記マッピングに従って、前記複数のFECコードブロックをデータストリームとして送信するための命令と
を含む、装置。
【請求項13】
符号化方法であって、
情報ビットのストリームを取得するステップと、
前記情報ビットのストリームを複数の低密度パリティ検査(LDPC)コードブロックに符号化するステップであって、前記複数のLDPCコードブロックのそれぞれは、そのうちの少なくとも25パーセントが内側ピアリングパリティビットである、パリティビットを有する、ステップと、
前記複数のLDPCコードブロックを複数のリソースブロックにマッピングするステップであって、各LDPCコードブロックは前記リソースブロックのうちの単一のリソースブロックにマッピングされる、ステップと、
LDPCコードブロックのリソースブロックへの前記マッピングに従って、前記複数のLDPCコードブロックをデータストリームとして送信するステップと
を有する方法。
【請求項14】
前記内側ピアリングパリティビットは、対応するLDPCコードブロック内で搬送される情報によって完全に決定される値を有する、請求項13に記載の方法。
【請求項15】
前記内側ピアリングパリティビットは、その各々が対応するLDPCコードブロック内でのみ延伸するパリティ検査リンクによって決定される値を有する、請求項13に記載の方法。
【請求項16】
前記複数のLDPCコードブロックを前記複数のリソースブロックにマッピングするステップは、
前記複数のLDPCコードブロックを複数の仮想リソースブロック(VRB)に割り当てるステップであって、前記複数のLDPCコードブロックのそれぞれは前記複数のVRBのうちの一意の一つに割り当てられる、ステップ
を有する、請求項13に記載の方法。
【請求項17】
前記複数のLDPCコードブロックを前記データストリームとして送信するステップは、
前記複数のLDPCコードブロックのそれぞれを前記データストリームによって搬送される複数の物理リソースブロック(PRB)のうちの一意の一つにインターリーブするステップであって、一定のLDPCコードブロックの各ビットは前記PRBのうちの共通の一つ内で搬送される、ステップ
を有する、請求項13に記載の方法。
【請求項18】
装置であって、
プロセッサと、
前記プロセッサによる実行のためのプログラムを格納するコンピュータ可読記憶媒体とを有し、前記プログラムは、
情報ビットのストリームを取得するための命令と、
前記情報ビットのストリームを複数の低密度パリティ検査(LDPC)コードブロックに符号化するための命令であって、前記複数のLDPCコードブロックのそれぞれは、そのうちの少なくとも25パーセントが内側ピアリングパリティビットである、パリティビットを有する、命令と、
前記複数のLDPCコードブロックを複数のリソースブロックにマッピングするための命令であって、各LDPCコードブロックは前記リソースブロックのうちの単一のリソースブロックにマッピングされる、命令と、
LDPCコードブロックのリソースブロックへの前記マッピングに従って、前記複数のLDPCコードブロックをデータストリームとして送信するための命令と
を含む装置。
【請求項19】
前記内側ピアリングパリティビットは、対応するLDPCコードブロック内で搬送される情報によって完全に決定される値を有する、請求項18に記載の装置。
【請求項20】
前記内側ピアリングパリティビットは、その各々が対応するLDPCコードブロック内でのみ延伸するパリティ検査リンクによって決定される値を有する、請求項18に記載の装置。
【発明の詳細な説明】
【技術分野】
【0001】
本願は、“Forward Error Correction (FEC) to Support Successive Interference Cancellation (SIC)”と題する、2013年3月6日に出願された、米国非仮出願番号13/787,554の利益を主張し、これにより、前記出願は参照によって本明細書に組み込まれる。
【0002】
本発明は、一般に無線通信に関し、詳細な態様においては、逐次干渉除去(SIC)をサポートするために強化された前方誤り訂正(FEC)技術に関する。
【背景技術】
【0003】
逐次干渉除去(SIC)は、サービングデータ送信が1つ以上の干渉データ送信と衝突した干渉信号またはチャネルからサービングデータ送信を復号するために受信機によって使用される技術である。具体的には、サーブされた(served)受信機は、干渉データを(部分的にまたは完全に)復号してもよいとともに、干渉信号からサービングデータ送信を分離するために復号された干渉データを使用してもよい。一度分離させられると、サービングデータ送信は復号される。
【0004】
他方のデータ送信の前に一方のデータ送信が始まるかまたは終わるときにしばしば起こるように、サービングデータ送信と干渉データ送信とが正確に互いに重ならない場合に非効率が生じる。具体的には、従来の前方誤り訂正(FEC)の設計は、干渉データ送信を移送するために使用されるリソースの全体に渡って干渉データ送信のFECビットを分配する。このことは、サーブされた受信機に、それらのリソースブロック(RB)の一部がサービングデータを搬送しないときでさえ、干渉データ送信を搬送する全てのRBを評価するためにSIC復号を実行させようとする。そのように、より効率的なSIC復号を可能にするために、独立して復号可能なRBを生成するFECの設計が望まれる。
【発明の概要】
【課題を解決するための手段】
【0005】
SICをサポートするために強化されたFEC技術を説明する本発明の実施形態によって技術的利点が一般に達成される。
【0006】
一つの態様に従って、符号化方法が提供される。この例においては、前記方法は、情報ビットのストリームを取得するステップと、情報ビットのストリームを独立して復号可能な前方誤り訂正(FEC)コードブロックに符号化するステップとを含む。前記方法は、各FECコードブロックを一意のリソースブロックにマッピングするステップと、前記マッピングに従って、FECコードブロックをデータストリームとして送信するステップとをさらに含む。従って、前記方法は、独立して復号可能なリソースブロックを搬送するデータストリームを生成し、そのことは本明細書で説明される理由によりSIC復号を容易にする。本方法を実行するための装置がまた提供される。
【0007】
別の態様に従って、別の符号化方法が提供される。この例においては、前記方法は、情報ビットのストリームを取得するステップと、情報ビットのストリームを低密度パリティ検査(LDPC)コードブロックに符号化するステップとを含む。各LDPCコードブロックは、そのうちの少なくとも25パーセントが内側ピアリングパリティビットである、パリティビットを有し、そのことはLDPCブロックの大部分が独立して復号されることを可能にする。前記方法は、各LDPCコードブロックを単一のリソースブロックにマッピングするステップと、前記マッピングに従って、LDPCコードブロックをデータストリームとして送信するステップとをさらに含む。本方法を実行するための装置がまた提供される。
【図面の簡単な説明】
【0008】
本発明およびその利点のより十分な理解のために、ここで、添付図面と併せてなされる以下の説明に対して参照が行われる。
【0009】
図1図1は、データを通信するためのネットワークの図を示す。
図2図2は、データを符号化するための従来のFECアーキテクチャの図を示す。
図3図3は、データを符号化するための実施形態のFECアーキテクチャの図を示す。
図4図4は、データを符号化するための別の実施形態のFECアーキテクチャの図を示す。
図5図5は、データを符号化するためのさらに別の実施形態のFECアーキテクチャの図を示す。
図6図6は、データを符号化するための実施形態の方法のフローチャートを示す。
図7図7は、従来のLDPC符号化方式の図を示す。
図8図8は、実施形態のLDPC符号化方式の図を示す。
図9図9は、実施形態の通信装置のブロック図を示す。
【0010】
異なる図における対応する数字および記号は一般に、特に示されない限りは対応する部分を指す。図は、実施形態の適切な態様を明確に示すために描かれており、必ずしも縮尺通りには描かれていない。
【発明を実施するための形態】
【0011】
本実施形態の作成および使用が以下で詳細に説明される。しかしながら、本発明が特定の背景で多種多様に具現されることができる多くの適用可能な発明概念を提供することは理解されるべきである。説明される特定の実施形態は、発明を作成および使用するための特定の方法の単なる例示であって、発明の範囲を限定するものではない。さらに、様々な変更、置換および改変は添付の特許請求の範囲によって定義される発明の精神および範囲から逸脱することなく本明細書においてなされ得ることは理解されるべきである。また、本出願の範囲は本明細書に記載されるプロセス、機械、製造、組成物、手段、方法およびステップの特有の実施形態に限定されるものではない。
【0012】
図1は、一組の送信ポイント(TP)110および120(それぞれ)が共通の時間周波数リソース、すなわち、0〜4でインデックス付けされたリソースブロック(RB)(RB-0、RB-1、RB-2、RB-3、RB-4、RB-5)を介して複数の受信機131〜134にデータを通信するように構成されている、一組の隣接するセル101および102を有するネットワーク100を示す。本明細書で使用されるように、リソースブロック(RB)という用語は、任意のネットワーク内のリソースの任意の集合を指し、そのように明示的に述べられない限り排他的にLTEリソースブロック(RB)を指すものと解釈されるべきではない。例えば、リソースブロックはLTEネットワークとWiMAXや他のネットワークのような非LTEネットワークの両方におけるリソースの集合を含んでもよい。また、リソースブロックは、時間および周波数リソースに限定されず、例えば異なる送信レイヤ等の空間領域内のリソースにも対応することができる。送信ポイント(TP)という用語は、基地局、拡張基地局(eNB)、フェムトセル、ユーザ機器(UE)、携帯端末、中継器および他の無線対応装置を含む無線送信を行うことができる任意の装置を指す。例えば、TPは、符号化された信号を送信するように構成されている端末、基地局、eNB、中継ノード、フェムトセルまたは他の無線装置上に配置される送信機であってもよい。さらに、受信機という用語は、本明細書では、基地局、eNB、フェムトセル、UE、携帯端末、中継器および他の無線対応装置を含む、無線信号を受信することができる任意の装置を指すために使用される。本明細書で説明される無線送信は、アップリンク、ダウンリンク、デバイス・ツー・デバイス(D2D)、ワイヤレスフィデリティ(Wi-Fi)および他の無線送信を含む、任意の無線送信であることができる。
【0013】
前記セル101では、受信機131は、RB-0からRB-4にまたがって第1のデータ送信(data-1)を受信するようにスケジュールされる。セル102では、受信機132は、RB-0およびRB-1にまたがって第2のデータ送信(data-2)を受信するようにスケジュールされ、受信機133は、RB-2およびRB-3にまたがって第3のデータ送信(data-3)を受信するようにスケジュールされ、受信機134は、RB-4にまたがって第3のデータ送信(data-3)を受信するようにスケジュールされる。
【0014】
一つの実施例では、受信機134は、SIC復号技術を使用してRB-4内でdata-4を復号するように構成される。data-1が従来のFECアーキテクチャに従って符号化される場合、RB-4内で通信されるdata-1の部分は独立して復号可能でない。結果として、受信機134はRB-0、RB-1、RB-2およびRB-3内で通信されるdata-1の部分を少なくとも部分的に復号する必要があり得る。その上、RB-0、RB-1、RB-2およびRB-3内で通信されるdata-1のこれらの部分を復号することは、様々な通信パラメータ(例えば、UEオーダリング等)によって、data -3および/またはdata-4を復号することを必要とし得る。したがって、従来のFECの設計は、SIC復号技術に従ってdata-4を取得するためにdata-1、data-2およびdata-3を少なくとも部分的に復号するための受信機134を必要とし得る。
【0015】
図2は、データを符号化するための従来のFECアーキテクチャ200を示す。従来のFECアーキテクチャ200は、N個の情報ビット215(Nは整数)を生成または受信する、情報モジュール210を含む。従来のFECアーキテクチャ200は、情報ビット215をK個のFECビット235(KはNよりも大きい整数)に変換するFECコードモジュール230をさらに含む。FECビット235は情報ビット215の関数であり、情報ビット215に関係する少なくともいくつかのパリティビットを含む。従来のFECアーキテクチャ200は、FECビット235をデータ・ストリーム250にインターリーブするインターリーバモジュール240をさらに含む。特に、インターリーバモジュール240は、FECビット235を複数のリソースブロック251〜253に散在させ、その結果として、リソースブロック251〜253は独立して復号可能でない。いくつかの実施形態では、インターリーバはまた情報モジュール210とFECコードモジュール230との間に存在してもよい。上述の理由により、SIC復号はリソースブロックが独立して復号可能でない場合に難点があり、したがって、改善されたFECアーキテクチャが所望される。
【0016】
本開示の態様は独立して復号可能なRBを生成するFECの設計および方式を提供し、それによって、より効率的なSIC復号を可能にする。いくつかの実施形態では、複数のFEC符号化モジュールが、独立して復号可能なリソースブロックを生成するために利用される。他の実施形態では、低密度パリティ検査(LDPC)符号器は、インナーピアリングパリティビット(inner-peering parity bits)(すなわち、そのパリティ検査リンクはインスタントリソースブロックの外側に延伸しないパリティビット)の割合が高いリソースブロックを生成するように構成され、それによって、それらのリソースブロックの重要な部分が他のリソースブロックを参照せずに復号されることを可能にする。
【0017】
図3は、データを独立して復号可能なリソースブロックに符号化するための実施形態のFECアーキテクチャ300を示す。FECアーキテクチャ300は、N個の情報ビット315を生成または受信する、情報モジュール310を含む。FECアーキテクチャ300は、情報ビット315をM個のFECビット325(MはNよりも大きくKよりも小さい整数)に変換する、FECコード−1モジュール320をさらに含む。FECコード−1モジュールは、畳み込みコード、LDPC、別のプロダクトコード、ブロックコード等のような、任意のFECコードであってもよい。FECビット335は、情報ビット315の関数であり、情報ビット315に関係する少なくともいくつかのパリティビットを含む。FECアーキテクチャ300は、複数のFEC2次コードモジュール331〜333をさらに含む。実施形態のFECアーキテクチャ300は、3つのFEC2次コードモジュール331〜333を有するように描かれるが、他の実施形態のFECアーキテクチャは、異なる数のFEC2次コードモジュール(例えば、2個、4個、5個等)を有してもよい。さらに、情報モジュール310とFECコード−1モジュール320との間、および/またはFECコード−1モジュール320と1つ以上のFEC2次コードモジュール331〜333との間に位置する追加のインターリーバが存在してもよい(図示せず)。いくつかの実施形態では、FECコード−1と1つ以上の2次コードとが結合してFECプロダクトコードを形成してもよい。
【0018】
前記FEC2次コードモジュール331〜333は、FECビット325の特定の部分を符号化してFECビット335の特定の部分を生成するように構成される。具体的には、FEC2次コードモジュール331は、FECビットの第1のセット326を符号化してFECビット336を取得するように構成され、FEC2次コードモジュール332は、FECビットの第2のセット327を符号化してFECビット337を取得するように構成され、FEC2次コードモジュール333は、FECビットの第3のセット328を符号化してFECビット338を取得するように構成される。いくつかの実施形態では、FECビットの各セット326、327および328がFECビット325のうちの等しい数を有するように、FEC2次コードモジュール331〜333によって符号化されるFECビットの数は同じであってもよい。例えば、FECビット325が90ビットを含む場合、そのとき、FECビットの各セット326、327および328は30ビットを含んでもよい。他の実施形態では、FECビットのセット326、327および328のうちの少なくともいくつかがFECビット325のうちの異なる数を有するように、FEC2次コードモジュール331〜333によって符号化されるFECビットの数は異なっていてもよい。例えば、FECビット325が90ビットを含む場合、そのとき、FECビットの第1のセット326は40ビットを有してもよく、FECビットの第2のセット327は30ビットを有してもよく、FECビットの第3のセット327は20ビットを有してもよい。FEC2次コードモジュール331〜333は、他の方法においても異なる場合がある。例えば、FEC2次コードモジュール331〜333は、異なる符号化レートおよび/または異なる符号化方式を利用してもよい。特に、FECビットのセット336〜338のそれぞれは、ビットの他のセットによって搬送される情報/データに依存せずに復号されることができるように、独立して復号可能である。例えば、FECビットのセット336は、FECビットのセット337および338によって搬送される情報に依存することなく復号されることができる。
【0019】
前記FECアーキテクチャ300は、FECビット335をデータストリーム350にインターリーブするための複数のインターリーバモジュール341〜343をさらに含む。より具体的には、インターリーバモジュール341は、FECビットのセット336をデータストリーム350のリソースブロック356に対応する部分にインターリーブするように構成され、インターリーバモジュール342はFECビットのセット337をデータストリーム350のリソースブロック357に対応する部分にインターリーブするように構成され、インターリーバモジュール343はFECビットのセット338をデータストリーム350のリソースブロック358に対応する部分にインターリーブするように構成される。リソースブロック356〜358はリソースの任意の論理的セットを表してもよい。例えば、リソースブロック356〜358は、物理リソースブロック(PRB)、仮想リソースブロック(VRB)、または他のリソースの集合のセットを表してもよい。FECビットの一意のセット336〜338を搬送することによって、リソースブロック356〜358のそれぞれは独立して復号可能である。
【0020】
いくつかの実施形態では、FECコード−1 320は、エラーフロアを回避しながら全体的な性能を提供する高レートコード(例えば、ブロックコード(Block code))であってもよい。一方、FEC2次コードモジュール331〜333は、高効率および/または高信頼性を提供する、より低いレートコード(例えば、ターボコード、LDPCコード、畳み込みコード等)であってもよい。実施形態では、ブラインド検出/シグナリングを簡素化するために、異なるコードレートのオプション(例えば、1/3、2/3、9/10、1等)がFEC2次コードモジュール331〜333に対して利用可能であってもよい。
【0021】
実施形態のFECアーキテクチャ300はFEC符号化の2つのレイヤを示しているが、いくつかの実施形態はより多くのレイヤを含んでもよく、一方で、他の実施形態はFEC符号化の単一のレイヤを含んでもよい。図4は、データを独立して復号可能なリソースブロックに符号化するための実施形態のFECアーキテクチャ400を示す。FECアーキテクチャ400は、FECアーキテクチャ400がFEC符号化の単一のレイヤを含むこと以外は、FECアーキテクチャ300と同様である。具体的には、FECアーキテクチャ400は、情報モジュール410、複数のFECコードモジュール431〜433および複数のインターリーバ441〜443を含む。情報モジュール410は、複数の情報ビット415を生成し、FECコードモジュール431〜433は、情報ビット415をFECビット435に符号化し、インターリーバ441〜443は、FECビットをデータストリーム450にインターリーブする。
【0022】
さらに具体的には、FECコードモジュール431は情報ビットの第1のセット416を符号化してFECビット436を取得するように構成され、FECコードモジュール432は情報ビットの第2のセット417を符号化してFECビット437を取得するように構成され、FECコードモジュール433は情報ビットの第3のセット418を符号化してFECビット438を取得するように構成される。さらに、インターリーバモジュール441はFECビットのセット436をデータストリーム450のリソースブロック456に対応する部分にインターリーブするように構成され、インターリーバモジュール442はFECビットのセット437をデータストリーム450のリソースブロック457に対応する部分にインターリーブするように構成され、インターリーバモジュール443はFECビットのセット438をデータストリーム450のリソースブロック458に対応する部分にインターリーブするように構成される。したがって、リソースブロック456〜458のそれぞれは独立して復号可能である。FECコードモジュール431〜433は、互いに同様であるか、または互いに異なるように構成されてもよく、同じまたは異なるコードレート、符号化構造等を利用してもよい。
【0023】
実施形態のFECアーキテクチャ300および400は別個のFEC符号化モジュールを示しているが、いくつかの実施形態は、複数の、独立して復号可能なFECビットのセットを生成するように構成される単一のFEC符号化モジュールを含んでもよい。図5は、データを独立して復号可能なリソースブロックに符号化するための実施形態のFECアーキテクチャ500を示す。FECアーキテクチャ500は、FECアーキテクチャ400が複数のFECコードモジュールではなく単一の2次FECコードモジュール530を含むこと以外は、FECアーキテクチャ300と同様である。具体的には、FECアーキテクチャ500は、情報モジュール510と、FECコード−1 520と、2次FECコードモジュール530と、複数のインターリーバ541〜543を含む。情報モジュール510は複数の情報ビット515を生成し、その後、FECコード−1 520は情報ビット515の生成物である複数のFECビット525を生成する。次に、2次FECコードモジュール530は、FECビット525を符号化してFECビット535を取得する。より具体的には、2次FECコードモジュール530は、FECビットの第1のセット526を符号化してローカルに復号可能なFECビットのセット536を取得し、FECビットの第2のセット527を符号化してローカルに復号可能なFECビットのセット537を取得し、FECビットの第3のセット528を符号化してローカルに復号可能なFECビットのセット538を取得するように構成される。その後、ローカルに復号可能なFECビットのセット536〜538のそれぞれは、インターリーバモジュール541〜543によってデータストリーム550に別々にインターリーブされる。特に、インターリーバモジュール541は、ローカルに復号可能なFECビットのセット536をデータストリーム550のリソースブロック556に対応する部分にインターリーブし、インターリーバモジュール542は、ローカルに復号可能なFECビットのセット537をデータストリーム550のリソースブロック557に対応する部分にインターリーブし、インターリーバモジュール543は、ローカルに復号可能なFECビットのセット538をデータストリーム550のリソースブロック558に対応する部分にインターリーブする。ローカルに復号可能なFECビットのセットのうちの一意の1つを搬送することによって、リソースブロック556〜558のそれぞれは独立して復号可能である。いくつかの実施形態では、2次FECコードモジュール530は、同じコードレートおよび構造を使用してローカルに復号可能なFECビットのセット536〜538を符号化する。他の実施形態では、2次FECコードモジュール530は、異なるコードレートおよび/または符号化構造を使用してローカルに復号可能なFECビットのセット536〜538を符号化する。いくつかの実施形態では、FECコード−1 520はFECアーキテクチャ500から省略される。
【0024】
図6は、送信機によって実行され得るような、データを独立して復号可能なリソースブロックに符号化するための実施形態の方法600を示す。方法600は、ステップ610で始まり、そこでは、送信機が情報ビットのストリームを受信(またはそうでなければ生成)する。その後、方法600は、ステップ620に進み、そこでは、送信機は情報ビットをFECビットの独立して復号可能な複数のセットに符号化する。ステップ620はFEC符号化の1つまたは複数のレイヤを含んでもよい。次に、方法600はステップ630に進み、そこでは、送信機はFECビットの独立して復号可能なセットのそれぞれを仮想または物理リソースにマッピングする。ステップ630はFECビットの独立して復号可能な各セットをRBまたはRBの集合、例えば、PRB、VRB等にインターリーブするステップを含んでもよい。最後に、方法600はステップ640に進み、そこでは、送信機は、仮想リソースマッピングに従って、FECビットの独立して復号可能なセットを送信する。
【0025】
いくつかの符号化アーキテクチャ(FECまたはそれ以外)はLDPC符号化方式を利用する。図7は、複数のリソースブロック710〜730を介して情報を符号化するための従来のLDPC符号化方式700を示す。示されるように、リソースブロック710〜730のそれぞれは情報ビットとパリティ検査ビットとを有する、パリティ検査ビットは、引数ビットの状態に応じて設定またはクリアされる。例えば、引数ビット711および731が同じ値を共有する場合にパリティビット721はセットされてもよく、または引数ビットが異なる値を有する場合にパリティビット721はクリアされてもよい。従来のLDPC符号化方式700では、多くのパリティビットはインスタンスリソースブロックの外側に延伸する少なくとも1つのパリティ検査リンクを有する。例えば、パリティビット721はリソースブロック720の外側に延伸する2つのパリティ検査リンクを有し、したがって、パリティビット721の値を決定することは引数ビット711および731の値を知ることを必要とし得る。同様に、パリティビット722は、リソースブロック720の外側に延伸するパリティ検査リンクを有し、したがって、パリティビット722の値を決定することは引数ビット712の値を知ることを必要とし得る。そのように、RB720内で搬送される干渉データを復号しようとするSIC受信機は、RB720の部分を取得するためにRB710および/またはRB730を復号またはそうでなければ評価することを必要とされ得る。
【0026】
従来のLDPC方式は、パリティ検査ビットの大部分(例えば、99パーセント以上)がインスタントリソースブロックの外側に延伸する少なくとも1つのパリティ検査リンクを有するように設計される。この設計特性は、従来のLDPC方式が、ノイズを多くのリソースブロックにわたって分散させることによって、平均ブロック誤り率(BER)を低減することを可能にすると同時に、任意の与えられたリソースブロックの大部分が独立して復号可能となることを妨げもする。したがって、より効率的なSIC復号を可能にするLDPC方式が所望される。
【0027】
図8は、複数のリソースブロック810〜830を介して情報を符号化するための実施形態のLDPC方式800を示す。特に、実施形態のLDPC方式800は、従来のLDPC符号化方式700(典型的には1パーセントより低い内側ピアリングパリティビットを含む)よりもパリティビット822のような内側ピアリングパリティビットを高い比率で有する。内側ピアリングパリティビットという語句は、外側のリソースブロック(すなわち、内側ピアリングパリティビットを搬送するインスタンスRB以外のRB)を復号またはそうでなければ評価することなく決定されることができるパリティビットを説明するために本明細書中で使用される。例えば、全ての引数ビットが内側ピアリングパリティビットの値を決定するために知られなければならない場合、そのときはいずれのパリティ検査リンクもインスタンスリソースブロックの外側に延伸することはできない。
【0028】
実施形態のLDPC方式800では、パリティビット822のためのパリティ検査リンクのそれぞれはRB820内で延伸し、そのことは、パリティビット822の値が、外側のリソースブロック810/830を評価することなく決定されることを可能にする。実施形態のLDPC方式800は従来のLDPC方式によって生成されるリソースブロックよりも内側ピアリングパリティビットを高い比率で含むリソースブロック820を生成する一方で、全てのパリティビットが内側ピアリングである必要はない。例えば、パリティビット821は、外側ピアリングパリティビットである。例えば、内側ピアリングパリティビットの比率はシステムのニーズに応じて変化してもよい。例えば、内側ピアリングパリティビットはいくつかの実施形態のLDPC方式では全てのパリティビットのうち約25パーセントを占めてもよく、一方で、他の実施形態のLDPC方式はより高い比率(例えば、35パーセント、またはそれ以上)で内側ピアリングパリティビットを生成してもよい。いずれにしても、実施形態のLDPC方式は、典型的に1パーセントよりも少ない内側ピアリングパリティビットを含む従来のLDPC方式よりも実質的に多くの内側ピアリングパリティビットを有する。
【0029】
図9は、上述の1つ以上の装置(例えば、UE、NB等)と同等であり得る通信装置900の実施形態のブロック図を示す。通信装置900は、プロセッサ904と、メモリ906と、セルラーインタフェース910と、補足無線インタフェース912と、補足インタフェース914を含んでもよく、図9に示されるように設計されてもよい(またはされなくてもよい)。プロセッサ904は、計算および/または他の処理関連タスクを実行することができる任意のコンポーネントであってもよく、メモリ906は、プロセッサ904のためのプログラミングおよび/または命令を格納することができる任意のコンポーネントであってもよい。セルラーインタフェース910は、通信装置900がセルラー信号を使用して通信することを可能にする任意のコンポーネントまたはコンポーネントの集合であってもよく、セルラーネットワークのセルラー接続を介して情報を受信および/または送信するために使用されてもよい。補足無線インタフェース912は、通信装置900がWi-FiまたはBluetooth(登録商標)プロトコルまたは制御プロトコルなどの非セルラー無線プロトコルを介して通信することを可能にする任意のコンポーネントまたはコンポーネントの集合であってもよい。装置900は、例えば、基地局、中継器、モバイルデバイス等の任意の無線対応コンポーネントと通信するために、セルラーインタフェース910および/または補足無線インタフェース912を使用してもよい。補足インタフェース914は、通信装置900がワイヤ・ライン・プロトコル(wire-line protocol)を含む補足プロトコルを介して通信することを可能にする任意のコンポーネントまたはコンポーネントの集合であってもよい。実施形態では、補足インタフェース914は、通信装置900が、バックホール・ネットワーク・コンポーネントのような別のコンポーネントと通信することを可能にしてもよい。
【0030】
本発明およびその利点が詳細に説明されたが、様々な変更、置換および改変が、添付の特許請求の範囲によって定義される本発明の精神および範囲を逸脱することなく本明細書においてなされ得ることは理解されるべきである。また、本願の範囲は、明細書に記載されるプロセス、機械、製造、組成物、手段、方法およびステップの特定の実施形態に限定されるものではない。当業者が本発明の開示から容易に理解するように、本明細書で説明される対応する実施形態と実質的に同じ機能を実行し、または実質的に同じ結果を達成する、現在存在するかまたは後に開発される、プロセス、機械、製造、組成物、手段、方法またはステップは、本発明に基づいて利用されることができる。したがって、添付の特許請求の範囲は、そのようなプロセス、機械、製造、組成物、手段、方法またはステップを範囲内に含むものである。
【符号の説明】
【0031】
100 ネットワーク
101 セル
102 セル
110 送信ポイント(TP)
120 送信ポイント(TP)
131 受信機
132 受信機
133 受信機
134 受信機
200 従来のFECアーキテクチャ
210 情報モジュール
215 情報ビット
230 FECコードモジュール
235 FECビット
240 インターリーバモジュール
250 データ・ストリーム
251 リソースブロック
252 リソースブロック
253 リソースブロック
300 FECアーキテクチャ
310 情報モジュール
315 情報ビット
320 FECコード−1モジュール
325 FECビット
326 FECビットの第1のセット
327 FECビットの第2のセット
328 FECビットの第3のセット
331 FEC2次コードモジュール
332 FEC2次コードモジュール
333 FEC2次コードモジュール
335 FECビット
336 FECビットのセット
337 FECビットのセット
338 FECビットのセット
341 インターリーバモジュール
342 インターリーバモジュール
343 インターリーバモジュール
350 データストリーム
356 リソースブロック
357 リソースブロック
358 リソースブロック
400 FECアーキテクチャ
410 情報モジュール
415 情報ビット
416 情報ビットの第1のセット
417 情報ビットの第2のセット
418 情報ビットの第3のセット
431 FECコードモジュール
432 FECコードモジュール
433 FECコードモジュール
435 FECビット
436 FECビット
437 FECビット
438 FECビット
441 インターリーバ
442 インターリーバ
443 インターリーバ
450 データストリーム
456 リソースブロック
457 リソースブロック
458 リソースブロック
500 FECアーキテクチャ
510 情報モジュール
515 情報ビット
520 FECコード−1
525 FECビット
526 FECビットの第1のセット
527 FECビットの第2のセット
528 FECビットの第3のセット
530 2次FECコードモジュール
535 FECビット
536 FECビットのセット
537 FECビットのセット
538 FECビットのセット
541 インターリーバ
542 インターリーバ
543 インターリーバ
550 データストリーム
556 リソースブロック
557 リソースブロック
558 リソースブロック
700 従来のLDPC符号化方式
710 リソースブロック
711 引数ビット
712 引数ビット
720 リソースブロック
721 パリティビット
722 パリティビット
730 リソースブロック
731 引数ビット
800 LDPC方式
810 リソースブロック
820 リソースブロック
821 パリティビット
822 パリティビット
830 リソースブロック
900 パリティビット
904 プロセッサ
906 メモリ
910 セルラーインタフェース
912 補足無線インタフェース
914 補足インタフェース
図1
図2
図3
図4
図5
図6
図7
図8
図9
【国際調査報告】