説明

高性能符号化を可能にする多重化CDMAチャネルの順方向誤り訂正

【課題】ワイヤレスリンクを介するような符号化伝送の利用を最適化するプロトコルに関し、高性能符号化を可能にする多重化CDMAチャネルの順方向誤り訂正に係るデータの通信方法を提供することにある。
【解決手段】この技術では、インターフレームが最初に、無線チャネルの伝送特性に応じて、最適サイズに選択されたセグメントに分割される。各セグメントには位置識別子と冗長チェックサムが割り当てられる。次に各セグメントはブロックに組み立てられ、順方向誤り訂正アルゴリズムがそのブロックに適用されて冗長ビットが生成される。次にFECブロックは有効な通信チャネル間で分割され、受信器に送信される。逆の処理が受信器に適用される。この方法の使用は、エラーデータを含むセグメントだけに適用する必要がある。したがって、高性能の順方向誤り訂正に必要な大きいブロックサイズを使用すると同時に、エラーを回復できないとき全体ブロックを再送するのに必要な待ち時間を最小にできる。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ワイヤレスリンクを介するような符号化伝送の利用を最適化するプロトコルに関する。
【背景技術】
【0002】
低価格パーソナルコンピュータの広範な利用は、一般大衆が低コストでインターネットを含むコンピュータネットワークへアクセスを求める状況を生み出した。この求めは、ラップトップコンピュータ、PDA(個人用携帯型情報端末)などのポータブルデバイス(携帯型装置)にネットワークアクセス機能を備える必要性に移行している。このようなポータブルデバイスのユーザは、現在でも、有線接続を使用するのに慣れているのと同一の簡便性で、コンピュータネットワークにアクセスすることを期待している。
【0003】
残念ながら、高速でインターネットへの低コストのワイヤレスアクセスを提供する、有用で満足のいく解決策はまだ存在しない。現在、既存のセルラー電話(携帯/自動車電話)を使用するワイヤレスモデムのユーザは、例えばウェブページを見ようと試みるとき、困難性を経験している。この原因の少なくとも一部は、セルラー電話ネットワークのアーキテクチャが、本来音声通信をサポートするように設計されており、インターネットに使用するパケットデータ通信プロトコルをサポートしていないという事実による。さらに、広域ネットワークのユーザコネクションに使用されるプロトコルは、ワイヤレスインタフェースを介する効率的な伝送に向いていない。
【0004】
符号分割多重アクセス(CDMA)を使用するシステムのようなワイヤレス通信システムによって多重データリンクを提供するプロトコルが提案されている。例えば、このようなシステムの1つは、本発明者らの同時係属中の米国特許出願第08/992,759号で、発明の名称が“ワイヤレス符号分割多重アクセス通信システムにより多重nB+D ISDN基本速度インタフェースリンクを提供するプロトコル変換と帯域幅低減方法”(1997年12月17日に出願され、本出願の譲受人であるタンティビ・コミュニケーションズ・インコーポレーテッドに譲渡されている)に記載されている。この技術を用いて、ワイヤレスチャネルへのアクセスをさらに効率的に割り当てることによって、ディジタル・セルラー・コネクションにより高速データサービスを提供できる。特に、例えば各サブチャネルに異なる符号を割り当てることにより、標準CDMAチャネル帯域幅内でサブチャネルの数が定義される。この時、各セッションに対して必要に応じて多重サブチャネルを動的に割り当てることにより、与えられたコネクションの瞬間的な必要帯域幅が満たされる。例えば、ウェブページのダウンロード時のように、加入者帯域幅必要条件が比較的高い時間には、サブチャネルが与えられる。ユーザが以前にダウンロードしたウェブページを読む時のように、通信負荷が軽い時間には、帯域幅は開放される。
【0005】
しかし、このようなシステムを実現するには、雑音、マルチパスなどのエラー発生原因の影響を最小にしながら限界ビット速度を達成するために、各種変調と符号化技術の慎重な計画を必要とする。例えば、同一無線周波数搬送波を占めるチャネル間の干渉を最小にするために、変調符号と疑似雑音拡散符号を慎重に選択しなければならない。さらに、フレーム指示ビットをデータストリームに挿入して、転送制御プロトコル/インターネットプロトコル(TCP/IP)通信のような上位層データプロトコルが実行できるようにする必要がある。
【発明の概要】
【発明が解決しようとする課題】
【0006】
前述のシステムは比較的雑音の少ない環境では問題なく機能するが、いくつかの点で最適とは言えない。
【0007】
例えば、巡回冗長検査(CRC)エラーはTCP/IPフレームがエラー状態で受け取られていることを表すが、エラーのあるフレームの受取りがフレーム全ての再送信を要求する場合には、CRCの使用は最適とはいえない。不利なことに、再送信に適応させるためにはアクセスが特に許可されなければならないCDMAのような共有アクセスワイヤレス環境では、再送信を要求するアクセス技術は特に面倒なものとなる。例えば、CDMAシステムでは、エラーは実際には非線形の影響を示し、再送信帯域幅よりも大きい量だけシステム容量を低下させる。したがって、データを再送信する必要性をできるだけ小さくすることが望ましい。
【0008】
順方向誤り訂正(FEC)として知られる技術は、CDMAなどの音声伝送に利用されている多重アクセス変調方法において、一般に使用されている。この技術は、ワイヤレスチャネルを通して送られるビッグループ、すなわち“ブロック”を使用でき、さらに高度な数学的アルゴリズムに従って、追加の冗長ビットの値を決定する。冗長ビットの数はかなり大きくてもよい。例えば、1/2速度、1/3速度、または1/4速度符号を使用するのが一般であり、それにより実際に伝送される1ブロック中のビット数は、それぞれ2、3、4倍に増加する。
【0009】
したがって、順方向誤り訂正符号は、あるビットストリングがエラー状態で受け取られたことを検出するだけでなく、誤り訂正の実行にも使用される。これにより、1ビットまたは複数ビットのエラーのためにパケット全体を再送信する必要は無くなる。このように、順方向誤り訂正は、再送信が実際的でなくおよび/またはコストがかかる衛星放送のような実施において広く使用されてきた。
【0010】
不利な点は、順方向誤り訂正を実施すると、全体処理能力(スループット)が低下することである。ここで、全体処理能力は、有効チャネル帯域幅のメガヘルツ(MHz)当りに伝送されるパケット数で測定される。さらに、最良のエラー性能を得るために、一般に、高性能アルゴリズムに対しては比較的大きいブロックサイズを使用する必要がある。したがって、このような誤り訂正アルゴリズムの実行には、ブロック全体が復号される前に、受信器側でそのブロック全体が有効でなければならないので、待ち時間が発生する。さらに、順方向誤り訂正処理で回復できないエラーが検出されると、ブロックが再送信されている間の待ち時間がさらに発生する。
【課題を解決するための手段】
【0011】
本発明の実施には、ワイヤレス通信プロトコルの実現に関連する物理通信層と、ネットワーク通信プロトコルの実現に関連するネットワーク層との間に配置されたプロトコルコンバータが使用される。
【0012】
すなわち、本発明では、先ず送信器側のプロトコルコンバータが、TCP/IPフレームのようなネットワークフレームをセグメントと呼ばれるより小さい部分に分割する。セグメントサイズは、観測される誤り率に従って変化する。好ましい実施形態では、例えば、最小セグメントサイズは2バイトであり、最大セグメントサイズは512バイトである。1フレーム中の全セグメントサイズは等しい。
【0013】
次に、受信器側でセグメントをフレームに再組立できるように、各セグメントに情報が付加される。具体的には、受信器側でネットワーク層フレームを再構成際に適切な位置に配置されるように、セグメント位置番号が付加される。
【0014】
ここで、セグメントは、本明細書ではブロックと称するグループに配列される。次に、順方向誤り訂正(FEC)アルゴリズムがこのブロック全体に適用される。好ましい実施形態では、ブロックは1331情報ビットを有する。したがって、1/3速度符号を用いて、FEC符号化プロセスが4096ビットの出力FECブロックを供給する。
【0015】
好ましくは、プロトコルは、また、本明細書ではサブチャネルと称する複数の物理層コネクションを用いて、送信器から受信器まで所望の送信速度で、符号化FECブロックを送信する。次に、FECブロックは、各ビットを基準として、割当てサブチャネル間で分割される。次に、FECブロックを構成するビットが、サブチャネル上に送られる。この場合、リンクシーケンス識別子を付加して、送出ブロックがサブチャネル上に送られる順番を識別する。
【0016】
受信器側は、逆の動作を実行するプロトコルコンバータを有し、種々のサブチャネルを通して受け取られたビットが最初にFECブロックに組み立てられる。好ましい実施形態では4096ビットであるFECブロックを逆FECアルゴリズムに提供することにより、冗長符号ビットを取り除き、誤り訂正を実行する。
【0017】
次に、FEC復号化プロセスの出力をセグメントに分割する。その後、各セグメント内の巡回冗長検査情報を比較して、セグメントがエラー状態で受信されたか否かを判定する。エラー状態で受信されている場合は、次に、エラーのある受信セグメントの再送信を要求する。
【0018】
最終的には、受信されたセグメントは完全なネットワーク層フレームに再組立される。
【0019】
送信器側と受信器側の両方のプロトコルコンバータは、観測される受信セグメント誤り率に基づいて、セグメントサイズを動的に調整して、全体処理能力を最適化してもよい。
例えば、受信器側で、不良の巡回冗長検査(CRC)を持つセグメントは廃棄され、“不良”セグメントと見なされる。受け取ったセグメントのシーケンス番号(順序番号)の追跡を続けることにより、受信器は、特定のセグメント、すなわち直前の正常なセグメントと次の正常なセグメントの間のシーケンス番号を持つセグメントが失われていることを判定できる。この後、受信器は不良のセグメントの再送信をシーケンス番号によって明確に要求できる。このいわゆる選択的拒絶構成により、受信器と送信器の両方が、選択的に拒絶されたセグメントの記録から、エラー状態で受信されたフレーム番号を知ることができる。
【0020】
送信したフレーム数、および与えられた無線チャネル上で受信された選択的拒絶指示数のカウントから、送信器はそのチャネルに対する後続の送信セグメントのサイズを動的に調整できる。好ましくは、セグメントサイズは、送信したデータビットの全体数と、情報搬送に成功したビット数との比率に依存する公式に基づいて調整される。
【0021】
個々のセグメントではなく、セグメントグループに順方向誤り訂正を実行することにより、チャネル帯域幅割当ては最適化を維持できる。
【発明の効果】
【0022】
本発明は、TCP/IPのようなパケットを用いるプロトコルを必要とする環境において特に有利である。単一データストリームを伝送するのに必要なチャネル数を効果的に変更できるため、バースト速度にも効果的に順応できる。
【図面の簡単な説明】
【0023】
【図1】携帯型データ処理装置が本発明によるプロトコルコンバータを使用してネットワークを接続するシステムのブロック図である。
【図2A】プロトコルコンバータと多重チャネル送信器の構成を詳しく示す図である。
【図2B】プロトコルコンバータと多重チャネル受信器の構成を詳しく示す図である。
【図3】送信器に配置されたプロトコルコンバータによりネットワーク層フレームをセグメントに分割する方法を示す図である。
【図4】個々のセグメントの図であって、複数セグメントを順方向誤り訂正ブロックに組み立てる方法を詳しく示す図である。
【図5】受信器側のプロトコルコンバータがネットワーク層フレームを再組み立てする方法を示す図である。
【図6】本発明を実現する、送信器に配置されたプロトコルコンバータにより実行される一連のステップを示す図である。
【図7】図6の続きの図である。
【図8】本発明を実現する、受信器に配置されたプロトコルコンバータにより実行されるステップを示す図である。
【発明を実施するための形態】
【0024】
本発明の以下およびその他の目的、形態、および利点は、添付図面に示す本発明の好ましい実施形態の以下の詳細な説明で明らかになるであろう。図面では、同一参照符号は異なる図面においても同一部品を指す。図面は必ずしも縮尺通りでなく、本発明の原理を示すことに重点が置かれている。
【0025】
図1はシステム10のブロック図であり、本発明による高速データ通信サービスを提供するものである。システム10は遠隔加入者ユニット20、多重双方向通信リンク30、ローカルまたはサービスプロバイダユニット40から構成されている。
【0026】
加入者ユニットは、例えばポータブルまたはラップトップコンピュータ、ハンディーPDA(個人用携帯型情報端末)などの端末装置12に接続される。加入者ユニット20はプロトコルコンバータ25を有し、プロトコルコンバータ25が多重チャネルディジタル送受信器26とアンテナ27にデータを次々に提供する。
【0027】
プロトコルコンバータ25はコンピュータ12からデータを受け取り、適切なハードウェアおよび/またはソフトウェアで、既知の通信標準に従って送信に適するフォーマットにデータを変換する。
【0028】
プロトコルコンバータ25は中間プロトコル層を実現し、本発明にしたがって多重チャネル送受信器26で使用するのに適したフォーマットにデータを変換する。以下に詳細を述べるように、ネットワーク層において、プロトコルコンバータ25により提供されたデータは、TCP/IPのような適切なネットワーク通信プロトコルと一致した手法でフォーマットされ、端末装置12をインターネットなどのネットワークを介して他のコンピュータに接続できるのが望ましい。プロトコルコンバータ25とプロトコルのこの説明は単に具体例として示したものであり、他のネットワーク層プロトコルも使用できることは理解されるべきである。
【0029】
多重チャネルディジタル送受信器26は、図示された無線チャネル30のような1つまたは複数の物理的通信リンクへのアクセスを提供する。好ましくは、物理リンクは、CDMA(符号分割多重アクセス)のような既知のディジタル多重化技術を使用してさらに符号化され、与えられた無線チャネル30またはサブチャネル31上で多重トラフィックを提供する。他のワイヤレス通信プロトコルを使用して本発明を有効に活用できることは理解されるところである。
【0030】
例えば1.25MHzの帯域幅を有する、単一の広帯域CDMA搬送チャネル30上に多重符号化サブチャネル31を設けることにより、通信チャネルを実現できる。個々のチャネルは特有のCDMA符号により定義される。代わりに、多重チャネル31は、他のワイヤレス通信プロトコルで提供されるような、単一チャネルの物理的通信媒体によって提供される。重要なことは、各無線チャネル30に固有であるかなりの大きさのビット誤り率によって、サブチャネル31が不利な影響を受ける可能性があることである。
【0031】
サービスプロバイダ装置40はアンテナ42、多重チャネル送受信器46、プロトコルコンバータ45、ならびにモデム、ブリッジ、ゲートウェイおよびルータなどのインタフェース装置48を有し、これらはインターネット49を含むネットワークへの接続を提供するのに必要なものである。
【0032】
サービスプロバイダ40では、多重チャネル送受信器46が、加入者ユニットの多重チャネル送受信器26に類似ではあるが逆の動作をする機能を備える。プログラムコンバータ45についても同様であり、すなわち、加入者ユニット20のプロトコルコンバータ25とは逆の機能を提供する。データはTCP/IPフレームフォーマットでプロトコルコンバータ45から受け取られ、次にインターネット49に渡される。装置40の残りの構成は、ローカルエリアネットワーク、多重ダイヤルアップ接続、TI搬送接続装置、またはインターネット49への他の高速通信リンクなど多数の形態を取ることができる。
【0033】
プロトコルコンバータ25,45に戻って、これらについて詳細に説明する。これらは、多重チャネル送受信器26で使用されるCDMAプロトコルにより提供されるような物理層と、端末装置12およびネットワーク49間の接続を提供するTCP/IPのようなネットワーク層プロトコル間で実行される帯域幅管理機能29を提供する。
【0034】
帯域幅管理機能29は複数のタスクを実行して、多重通信リンク30上で正しく維持される物理層コネクションおよびネットワーク層コネクションの両方を保持する。例えば、特定の物理層コネクションは、コネクションのいずれかの端に位置する端末装置が実際に送信データを有するか否かにかかわらず、同期データビットストリームを連続的に受け取ることを期待する。このような機能はまた、速度適応(rate adaption)、リンク上の多重チャネルの結合、スプーフィング(spoofing)、無線チャネルの設定および分解を含む。
特に、多重チャネル送受信器26で使用するISDNとCDMA(符号分割多重アクセス)変調技術のプロトコルコンバータを実現する詳細は、係属中の特許出願である、Thomas E. GorsuchとCarlo Amalfitanoによる、発明の名称が“ワイヤレス符号分割多重アクセス通信システムによって多重nB+D ISDN基本速度インタフェースリンクを提供するプロトコルコンバータと帯域幅低減技術”(1997年12月17日出願、米国特許出願第08/992,759号)に詳述されている。この出願は本出願の譲受人のタンティビ・コミュニケーションズ・インコーポレーテッドに譲渡されており、本明細書に引用されている。
【0035】
本発明は特に、プロトコルコンバータ25および45で使用される技術に関連するものであり、ビットエラーの発生しやすい環境における送信器と受信器の間の有効処理能力速度を改良するために、多重無線チャネル30の実装多重論理サブチャネル31−1、31−2、…、31−n上を伝送されるデータのフォーマットの技術に関連する。以下の説明では、本明細書におけるコネクションは双方向であり、“送信器”は加入者ユニット20またはサービスプロバイダユニット40のいずれかであると理解されたい。
【0036】
さらに、本明細書における“エラー”は、ネットワーク層のような上位層で見つけられるビットエラーである。本発明は、システムレベル全体のビット誤り率を改良しようとするものであり、絶対的なデータ完全性を保証することを試みるものではない。
【0037】
図2Aおよび2Bでは、本発明に従って実現される順リンクと逆リンクのブロックを詳細に示す。具体的には、加入者側ユニットに関連するプロトコルコンバータ25および多重チャネル送受信器26と、サービスプロバイダユニット40に関連する多重チャネル送受信器46およびプロトコルコンバータ45の詳細を示す。
【0038】
図2Aの下方の逆リンク方向から説明を始める。この逆リンク方向は加入者ユニット20からサービスプロバイダユニット40に送信する方向であって、逆リンクプロトコルコンバータ25はバッファ61、セグメント組立部62、および順方向誤り訂正(FEC)ユニット63から構成される。多重チャネル送受信器26は、擬似雑音(PN)符号発生器64、変調器65、および無線周波数(RF)アップコンバータ66から構成される。
バッファ61は、後述する方法で入力データを受け取る。セグメント組立部62はバッファ61から受け取ったデータを適切なフォーマットで編集し、FECユニット63に供給する。FECユニット63は、順方向誤り訂正アルゴリズムをデータに適用する。この際、リードソロモン(Reed Solomon)、ターボ符号(Turbo Codes)、などの既知の誤り訂正技術を使用する。
【0039】
送受信器66は、この事例では送信器として使用され、取得データをPNシーケンスによって拡散し、適切なチャネル符号化を用いて、割り当てられたサブチャネル31ごとにPN拡散データを変調し、この結果を所望の無線周波数にまで高めて出力する。
【0040】
図2Bの逆リンクの受信器側、つまりサービスプロバイダ40側では、送受信器44が受信器機能を実行する。この事例では、RFダウンコンバータ71の出力が、イコライザ(等化器)72、PN符号逆拡散器73および復号器74を有する多重受信ユニットに供給される。各復調出力は、FEC復調器75、逆セグメント組立部76およびバッファ77を有するプロトコルコンバータブロックに供給される。コントローラ78を使用して、後述する各プロトコルコンバータ機能を制御および/または実行できる。
【0041】
好ましい実施形態では、FEC復号器75はいわゆるトレリス(trellis)復号器を使用する。トレリス復号器は、複数ビットグループを比較して正しく受信されたビットの評価を行うので、トレリス復号器がエラーを発生すると、エラーはグループで発生する傾向がある。
【0042】
類似の機能が順リンクで規定されている。この事例では、プロトコルコンバータ45は入力データを受取り、それをバッファ61、セグメント組立部62およびFECユニット63を通して処理する。送受信器46は多重サブチャネル31上で送信機能を実行する。
送受信器46は、また、多重拡散器64、変調器65およびRFアップコンバータ66を有する。
【0043】
順リンクの受信器側では、逆処理は、RFコンバータ71、ならびに各チャネルのイコライザ72、逆拡散器73、チャネル分離79および復調器74によって提供される。順方向誤り訂正ユニット75、セグメント組立部76およびバッフア77によって、プロトコルコンバータ25が実現する。
【0044】
次に図3を用いて、送信側におけるプロトコルコンバータ25の一例の動作を簡単に述べる。図示のように、ネットワーク層から受け取る入力フレームは比較的大きく、TCP/IPプロトコルの場合には、例えば1480ビット長である。
【0045】
入力フレーム80は最初に小部分セットまたはセグメント81−1、81−2に分割される。個々のセグメント81のサイズは、チャネル30ごとに決定された最適セグメント長に基づいて選択される。例えば、帯域幅管理機能は、随時特定数の有効サブチャネル31を作成するだけでもよい。この有効サブチャネルのサブセットが選択され、次に1サブチャネル上で送信されるセグメントの最適ビット数が選択される。これにより、図に示すように、与えられたフレーム80は4つのサブチャネル31に関連したセグメントに分割される。その後、セグメント81−2に対して種々の最適セグメントサイズで、1フレームに対して9つの有効サブチャネル31が存在してもよい。
【0046】
このように、前に引用した同時係属中の特許出願に記載されたこれらパラメータに対するチャネル30ごとに、最適サブフレームサイズを決定できる。好ましい実施形態では、例えばこれは次式のようになる。
【0047】
【数1】

ここで、Hはフレームのオーバヘッド(バイトで示す)であり、サブフレーム間の共有フレーム同期化フラグ(7e)を含む。また、Xcurrentはサブフレームに割り当てられた現在のデータバイト数、Hcurrentは現在のフレームのオーバヘッド、Rは観測されたサブフレームの誤り率である。
【0048】
好ましい実施形態では、セグメントサイズは、各関連無線チャネル30およびフレームに関連するセグメント81のサイズと同一であり、これによりオーバヘッドを最小にする。但しこれは絶対的な必要条件ではない。
【0049】
フレーム80がセグメント81に分割された後、各セグメント81には追加情報が付加される。例えば、各セグメント81は少なくとも位置識別子82aと、巡回冗長検査(CRC)82bの形式のような完全性チェックサムとから構成される。位置識別子82aは、このセグメントが関連する大きいフレーム80内のセグメント81の位置を表すのに役立つ。完全性チェックサム82bにより、受信器はそのセグメント81がエラー状態で受け取られたか否かを判定できる。
【0050】
次に、各サブチャネル31上をセグメント81が送信される準備がなされる。具体的には、複数のセグメント81がブロック86にまとめられる。各ブロック86のセグメント数は、適用される順方向誤り訂正63,75に依存して適切な数に選択される。例えば、好ましい実施形態では、順方向誤り訂正ブロック86は、全体で1331ビットになる、十分なセグメント数から構成される。適用されるFECアルゴリズムが1/3速度符号である場合、FECブロック86は4096ビット長になる。最後に、FECブロック86は、あるコネクションに割り当てられたサブチャネル31間で分割され、送信される。
【0051】
図4はセグメント81のフォーマットの詳細図である。セグメント81は、前述の位置フィールド82aとCRCフィールド82bを含む複数のフィールドから構成される。これら以外の複数のフィールドもセグメント81の一例内に示されている。具体的には、入力された大きいフレーム80から取られた関連するソースデータを有するデータフィールド82cが存在する。このデータフィールド82cは可変サイズであり、観測された誤り率により特定される最適化パラメータに従って変更できる。好ましい実施形態では、データビット数は、観測された誤り率に依存して、与えられたセグメント内で2〜512に変化できる。前述のように、与えられた入力フレーム80全体の全セグメントは同一サイズに選択される、例えば全セグメントは同一サイズのデータフィールド82cを持つ。
【0052】
さらに、与えられた入力フレームが多重サブチャネル31上に送信されると同時に、この入力フレームは与えられた無線チャネル30上を送信されるセグメントに分割されるだけである。
【0053】
さらに、フレームオフセットフィールド82dを使用して、セグメント81が属するフレーム番号を識別できる。このフレームオフセットフィールドは、システムに含まれる待ち時間があるために、特に使用される。具体的には、セグメント81は、送信された順序と同一の順序で受信器に到達することが必ずしも保証されていない。さらに、あるセグメント81がエラー状態で受信された場合、再送信を要求する必要がある。その結果、1つ以上のブロックに関連する複数のセグメント81を、受信器で与えられた時間に操作する必要性を満たすことができる。これより、フレームオフセットフィールド82dによって、受信器は各セグメントがどの大きいフレーム80に属しているかを区別できる。
【0054】
符号シーケンスフィールド82eを使用して、各フレームの開始時に各サブチャネル31に関連するシーケンス番号を識別できる。これにより、順位の低いチャネル処理がより効果的にセグメントに経路選択される。
【0055】
最後に、メッセージデータフィールド82fを使用して、セグメント81がソースデータ、すなわち有効トラフィックデータまたは制御情報を含むか否かを意図された受取者に対して表示できる。
【0056】
図5は、受信器側で実行される動作を示す。多重サブチャネル31から受け取ったデータビットを最初に収集して、FECブロックを再構成する。
【0057】
次に、FECアルゴリズムを適用して、誤り訂正符号を用いながら1つまたは複数ビットを検出および訂正する。得られた情報は、既知のセグメントサイズを使用してセグメント81に分割される。次に、セグメント81は検査され、位置フィールド82を用いて大きいフレーム80に再構成される。これにより、失われたセグメント81がすべて、受取った位置フィールド82aを比較して検出される。特定の位置または特定のシーケンス番号82eにおけるフレーム中のシーケンス位置フィールドが失われている場合、関連セグメント81がまだ受け取られていないと考えられる。セグメントを正しく受取り、セグメントが失われているか否かを決定するには、一般にデータおよびセグメント81の適切なバッファリングが必要である。バッファサイズは、送信速度、サブチャネル数31、および実質的な伝搬遅延に依存する。
【0058】
セグメント81が失われていることを検出すると、受信器は失われているセグメント81の再送信を要求する。この時点で、送信器は失われたセグメント81の送信を実行する。ある大きいフレーム80中の全セグメント81が受信されると、次に、位置情報82aを使用することにより、セグメント81からのデータを正しい順に配列して、元の大きいフレーム80を再構成する。
【0059】
この時点で、例えばフレームコマンドの終了が発生した時に、大きいフレーム80のいずれかの部分が今なお失われている場合、対応するセグメント81の再送信は指定された位置で要求でき、失われた部分の長さを指定する。
【0060】
位置フィールド82aとシーケンスフィールド82eの両方を使用するため、送信器と受信器の両方は、エラーを有する受信サブフレーム81の数と、エラーの無い受信サブフレーム81の数の比率を認識することができる。また、送信器と受信器は各チャネルの平均サブフレーム長を認識できる。
【0061】
図6は、本発明を実現するため、送信器で実行される一連の動作の詳細なフローチャートである。第1状態100では、大きいフレーム80がネットワーク層のような上位通信層から得られる。次の状態102では、個々のサブチャネル81上のフレーム誤り率のこれまでの観測結果から、送信器が、最適セグメントサイズを計算する。好ましくは、全有効全通信チャネルに対する最適セグメントサイズを計算する。
【0062】
次に状態104では、関連する各有効サブチャネルの最適サイズに従って、ネットワーク層フレーム80が適切な数のセグメント81に分割される。この分割は、また、有効サブチャネルの見積り処理能力に基づく。次にセグメントのリストが作成される。
【0063】
次の状態106では、位置識別子と巡回冗長検査(CRC)符号が各セグメントに加えられる。前述のように、大きいフレーム80内の位置識別子オフセットが次に追加されて、受信器側でフレームを再構成するときに、セグメント81の正しい位置決定を可能にする。
【0064】
次に、FECブロック86が複数セグメント81から組み立てられる。次に、状態108では、FECブロック86が複数に分離され、FECブロック内のビットがそれぞれ複数サブチャネル31の1つに割当てられる。
【0065】
送信器が、受信器側で失われているセグメント81に対する再送信要求を受け取ると、状態110で、最適セグメントサイズが、有効通信サブチャネル31の観測されたフレーム平均値から計算される。次に、状態112で、セグメントリストを使用して、再送信用セグメントを再度待機させる。次に、状態108で、失われたセグメント81の再送信の処理を続行する。
【0066】
図7は送信器で実行される残りの工程を示す。状態114では、チャネルに関するシーケンス番号が各セグメント81に追加される。次の状態116では、“7E”形式のフラグのようなセグメント区切り文字(セパレータ)がセグメントに挿入される。さらに、連続した5つのゼロの後の1に対してデータビットを強制的に設定するようなゼロ挿入が実行される。他の同期化、分離、符号化技術が、この時点でビットがセグメント81に挿入されることを要求することがある。例えば、与えられたチャネル30は、IS−95標準規格で規定された畳み込み符号化を実行し、もしそうならば、ここでこの符号化を実行する。
【0067】
次の状態118では、セグメント81は有効チャネル31上に送られる。論理開始、論理終了および他の制御フレームなど、データの存在しないフレームを同様にこの時点で挿入できる。
【0068】
最終状態120では、送信器はセグメント再送信要求、または正しく受信された大きいフレームの積極的な確認を行う。別のフレーム送信を開始でき、例えば送信中のフレームの完了する前の時点において開始できる。
【0069】
図8は受信器で実行される工程の詳細なシーケンスを示す。最初の状態200では、受信FECフレーム86が、多重サブチャネル31から得られたビットストリームから組立てられる。次の状態201では、FECフレームは、現在のセグメントサイズに従ってセグメント81に分割される。
【0070】
次の状態202では、サブフレーム81が検査される。良好なCRCを有するすべてのセグメントは通過され、次の状態203に達する。不良のCRCを有するすべての受信セグメント81は廃棄される。
【0071】
状態203を続行し、受信器は失われたシーケンス番号を決定する。次に受信器は、送信器に再送信要求を送り返すことにより、シーケンス番号に基づいて失われた部分のセグメントの再送信を要求する。
【0072】
次の状態204では、位置識別子と元の大きいフレーム80の既知の長さから、受信器は元のフレーム80の再構築を実行する。状態206では、再送信要求がすべて処理された後にもフレーム80のいずれかの部分が今なお失われている場合には、再送信要求自体が紛失している可能性があるとして、受信器は位置とサイズによって大きいフレーム80の失われている部分を要求する。
【0073】
状態208では、フレーム80が完全に受信されると、積極的な確認を送信器に送り返す。
【0074】
誤り訂正符号化に先立ってサブチャネル分割工程を最初に適用することにより、誤り訂正符号の完全な利点を得ることができると同時に、再送信の必要があるデータ量を最小にする。特に、トレリス実装FEC復号器75の出力が同時にビットエラーを発生する傾向にあるため、これらのエラーが単一のセグメント81に影響を与えやすい。
【0075】
本発明を好ましい実施形態により図示し、説明してきたが、当業者には、添付の特許請求の範囲に限定された本発明の精神と範囲から逸脱することなく、形状または細部の各種の変更が実行可能であることは理解されるであろう。当業者には通常の実験を行うことなく、本明細者に記載された本発明の特定の実施形態に対する多くの均等物を認識し、または確認できるであろう。このような均等物も特許請求範囲に包含されるものとする。
【符号の説明】
【0076】
20 加入者ユニット(送信器、受信器)
30 無線チャネル
31 サブチャネル
40 基地局(送信器、受信器)
80 フレーム
81 セグメント、
85 セグメントブロック
86 順方向誤り訂正ブロック

【特許請求の範囲】
【請求項1】
データユニットを複数のセグメントに分割するコントローラを有する装置であって、
前記コントローラは、
前記複数のセグメントの各セグメントに誤り検出情報を追加し、
1以上の無線チャネルを介し送信される前記複数のセグメントを有するブロックに対して誤り訂正符号化を実行し、
前記1以上の無線チャネルの観察された特性に基づき、第2データユニットを前記複数のセグメントと異なるセグメントサイズを有する第2の複数のセグメントにさらに分割し、
前記第2の複数のセグメントの各セグメントに誤り検出情報を追加し、
前記1以上の無線チャネルを介し送信される前記第2の複数のセグメントを有する第2ブロックに対して誤り訂正符号化を実行する装置。
【請求項2】
前記複数のセグメントの1つの再送のための要求を受信する受信機をさらに有し、
前記1以上の無線チャネルの観察された特性は、前記再送のための要求に基づく、請求項1記載の装置。
【請求項3】
前記1以上の無線チャネルの観察された特性は、利用可能なサブチャネルの個数を有する、請求項1記載の装置。
【請求項4】
前記誤り訂正符号化は、1/3レートターボ符号化装置を用いた順方向誤り訂正符号化を含む、請求項1記載の装置。
【請求項5】
前記データユニットは、IPパケットから導出される、請求項1記載の装置。
【請求項6】
サービスプロバイダ装置において実現される方法であって、
データユニットを複数のセグメントに分割するステップと、
前記複数のセグメントの各セグメントに誤り検出情報を追加するステップと、
1以上の無線チャネルを介し送信される前記複数のセグメントを有するブロックに対して誤り訂正符号化を実行するステップと、
前記1以上の無線チャネルの観察された特性に基づき、第2データユニットを前記複数のセグメントと異なるセグメントサイズを有する第2の複数のセグメントにさらに分割するステップと、
前記第2の複数のセグメントの各セグメントに誤り検出情報を追加するステップと、
前記1以上の無線チャネルを介し送信される前記第2の複数のセグメントを有する第2ブロックに対して誤り訂正符号化を実行するステップと、
を有する方法。
【請求項7】
前記複数のセグメントの1つの再送のための要求を受信するステップをさらに有し、
前記1以上の無線チャネルの観察された特性は、前記再送のための要求に基づく、請求項6記載の方法。
【請求項8】
前記1以上の無線チャネルの観察された特性は、利用可能なサブチャネルの個数を有する、請求項6記載の方法。
【請求項9】
前記誤り訂正符号化は、1/3レートターボ符号化装置を用いた順方向誤り訂正符号化を含む、請求項6記載の方法。
【請求項10】
前記データユニットは、IPパケットから導出される、請求項6記載の方法。

【図1】
image rotate

【図2A】
image rotate

【図2B】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate


【公開番号】特開2013−48495(P2013−48495A)
【公開日】平成25年3月7日(2013.3.7)
【国際特許分類】
【出願番号】特願2012−268281(P2012−268281)
【出願日】平成24年12月7日(2012.12.7)
【分割の表示】特願2011−133097(P2011−133097)の分割
【原出願日】平成12年2月23日(2000.2.23)
【出願人】(593096712)インテル コーポレイション (931)
【Fターム(参考)】