(57)【要約】ＨＤＬＣアクセラレータは、デフレーマおよびフレーマを備え、それぞれＰＰＰパケットに対するデフレーム化およびフレーム化処理を高速化する。デフレーマは、入力インタフェースユニット、検知ユニット、変換ユニット、および出力インタフェースユニットを備えている。
2006507704.tif 000002
【特許請求の範囲】
【請求項１】
デフレーム化すべきデータを受信するように動作可能な入力インタフェースユニットと、
入力インタフェースユニットからの各データバイトを評価して特定の値のバイトを検知するように動作可能な検知ユニットと、
特定の値の検知されたバイトに一部基づいてデフレーム化するために実行される特定のタスクを示す第１組のコントロール信号を提供するように動作可能な状態コントロールユニットと、
デフレーム化データを提供するための特別なデフレーム化スキームにしたがって、第１組のコントロール信号に基づいて受信データをデフレーム化するように動作可能な変換ユニットとを具備するワイヤレス通信デバイス用のデフレーマ。
【請求項２】
デフレーム化すべきデータがＲＦＣ１６６２により規定されたフレームフォーマットにしたがう請求項１記載のデフレーマ。
【請求項３】
入力インタフェースユニットがデフレーム化すべきデータを複数バイトのワードで受信し、各受信ワードに対して検知ユニットによる評価のために一度に１データバイトずつ提供するように動作可能である請求項１記載のデフレーマ。
【請求項４】
検知ユニットが受信データ内のフラグおよびエスケープバイトを検知するように動作可能である請求項１記載のデフレーマ。
【請求項５】
変換ユニットが受信データ内のフラグおよびエスケープバイトを除去するように動作可能である請求項４記載のデフレーマ。
【請求項６】
変換ユニットが、受信データ内の検知された各エスケープバイトに後続するデータバイトをアンエスケープするようにさらに動作可能である請求項５記載のデフレーマ。
【請求項７】
変換ユニットが受信データ内の検知された各フラグバイトに対するヘッダワードを提供するようにさらに動作可能である請求項４記載のデフレーマ。
【請求項８】
変換ユニットがパケットに関係するフレームチェックシーケンス（ＦＣＳ）値に基づいて各デフレーム化パケットを検査するように動作可能である請求項１記載のデフレーマ。
【請求項９】
第２組のコントロール信号を提供して、出力バッファにデフレーム化データを記憶させるように動作可能な出力インタフェースユニットをさらに具備する請求項１記載のデフレーマ。
【請求項１０】
出力インタフェースユニットが、デフレーマにより提供されたデフレーム化データのバイトアラインメントを実行するようにさらに動作可能である請求項９記載のデフレーマ。
【請求項１１】
デフレーマが複数バイトのワードでデフレーム化データを提供するように動作可能である請求項１記載のデフレーマ。
【請求項１２】
デフレーマが各デフレーム化動作においてデータのブロックをデフレーム化するように動作可能である請求項１記載のデフレーマ。
【請求項１３】
データブロックが無線リンクプロトコル（ＲＬＰ）パケットに対応するように動作可能である請求項１２記載のデフレーマ。
【請求項１４】
データブロックに対するデフレーム化パケット数を示す値を記憶するように動作可能な第１のレジスタをさらに具備する請求項１２記載のデフレーマ。
【請求項１５】
変換ユニットがデータブロックの開始に第１のヘッダを提供するようにさらに動作可能である請求項１２記載のデフレーマ。
【請求項１６】
デフレーマが、任意の所定の瞬間に複数の動作状態のうちの１つになり、動作状態はデフレーム化が実行されていないことを示す待機状態と、デフレーム化が実行されていることを示す処理状態とを含む請求項１記載のデフレーマ。
【請求項１７】
動作状態は、エスケープバイトに対する処理を示すエスケープ状態と、デフレーム化データに対するヘッダの発生を示すヘッダ状態とを含む請求項１６記載のデフレーマ。
【請求項１８】
デフレーム化すべきデータのＲＬＰパケットを一度に１ワードずつ受信して、各受信ワードに対して、後続の処理のために一度に１データバイトずつ供給するように動作可能な入力インタフェースユニットであって、ＲＬＰパケットは、ＲＦＣ１６６２により規定されたフォーマットを有する１つ以上の完全なおよび／または部分的なＰＰＰパケットを含む入力インタフェースユニットと、
入力インタフェースユニットからの各データバイトを評価してフラグ、エスケープ、および無効なバイトを検知するように動作可能な検知ユニットと、
フラグおよびエスケープバイトを除去し、各エスケープバイトに続くデータバイトをアンエスケープして、各フラグバイトのためのヘッダワードを供給し、パケットに関係するフレームチェックシーケンス（ＦＣＳ）値に基づいて各デフレーム化パケットを検査することにより、入力インタフェースユニットからの各データバイトを処理するように動作可能な変換ユニットと、
デフレーム化データを供給するように動作可能な出力インタフェースユニットとを具備するワイヤレス通信デバイス用のデフレーマ。
【請求項１９】
デフレーム化すべきデータのＲＬＰパケットを一度に１ワードずつ受信して、各受信ワードに対して、後続の処理のために一度に１データバイトずつ提供するように動作可能な入力インタフェースユニットであって、ＲＬＰパケットはＲＦＣ１６６２により規定されたフォーマットを有する１つ以上の完全なおよび／または部分的なＰＰＰパケットを含む入力インタフェースユニットと、
入力インタフェースユニットからの各データバイトを評価してフラグ、エスケープ、および無効なバイトを検知するように動作可能な検知ユニットと、
フラグおよびエスケープバイトを除去し、各エスケープバイトに続くデータバイトをアンエスケープして、各フラグバイトのためのヘッダワードを供給し、パケットに関係するフレームチェックシーケンス（ＦＣＳ）値に基づいて各デフレーム化パケットを検査することにより、入力インタフェースユニットからの各データバイトを処理するように動作可能な変換ユニットと、
デフレーム化データを供給するように動作可能な出力インタフェースユニットとを具備するワイヤレス通信デバイス用の集積回路。
【請求項２０】
ＲＬＰパケットを一度に１ワードずつ受信することと、
各受信ワードの各バイトを評価してフラグおよびエスケープバイトを検知することと、
各検知されたフラグおよびエスケープバイトを示す状態信号を供給することと、
このフラグおよびエスケープバイトを除去することと、
各検知されたエスケープバイトに続くデータバイトをアンエスケープすることと、
ＰＰＰパケットに関係するＦＣＳ値に基づいて各ＰＰＰパケットを検査することと、
デフレーム化されたデータを供給することとを含む、ＲＦＣ１６６２により規定されたフォーマットを有する１つ以上のＰＰＰパケットで構成されているデータのＲＬＰパケットをデフレーム化する方法。
【請求項２１】
フレーム化すべきデータを受信するように動作可能な入力インタフェースユニットと、
入力インタフェースユニットからの各データバイトを評価して特定の値のバイトを検知するように動作可能な検知ユニットと、
特定の値の検知されたバイトに一部基づいてフレーム化するために実行される特定のタスクを示す第１組のコントロール信号を提供するように動作可能な状態コントロールユニットと、
第１組のコントロール信号に基づき、フレーム化データを提供するための特別なフレーム化スキームにしたがって受信データをフレーム化するように動作可能な変換ユニットとを具備するワイヤレス通信デバイス用のフレーマ。
【請求項２２】
フレーム化されたデータがＲＦＣ１６６２により規定されたフレームフォーマットにしたがう請求項２１記載のフレーマ。
【請求項２３】
入力インタフェースユニットがフレーム化すべきデータを複数バイトのワードで受信し、各受信ワードに対して検知ユニットによる評価のために一度に１データバイトずつ提供するように動作可能である請求項２１記載のフレーマ。
【請求項２４】
変換ユニットが第１のコマンドの受信に応答してフラグバイトを挿入するようにさらに動作可能である請求項２１記載のフレーマ。
【請求項２５】
変換ユニットが第２のコマンドの受信に応答してフレームチェックシーケンス（ＦＣＳ）値を挿入するようにさらに動作可能である請求項２１記載のフレーマ。
【請求項２６】
変換ユニットが特定の値の１つを有するデータバイトを検知すると、エスケープバイトを挿入するように動作可能である請求項２１記載のフレーマ。
【請求項２７】
第２組のコントロール信号を提供して出力バッファにフレーム化データを記憶させるように動作可能な出力インタフェースユニットをさらに具備する請求項２１記載のフレーマ。
【請求項２８】
出力インタフェースユニットがフレーム化データのバイトアラインメントを実行するようにさらに動作可能である請求項２７記載のフレーマ。
【請求項２９】
出力インタフェースユニットが複数バイトのワードでフレーム化データを提供するように動作可能である請求項２７記載のフレーマ。
【請求項３０】
フレーマが各フレーム化動作に対するデータのブロックをフレーム化するように動作可能である請求項２１記載のフレーマ。
【請求項３１】
データブロックは無線リンクプロトコル（ＲＬＰ）パケットに対応する請求項３０記載のフレーマ。
【請求項３２】
フレーマは任意の所定の瞬間に複数の動作状態の１つになり、その動作状態はフレーム化が実行されていないことを示す待機状態とフレーム化が実行されていることを示す処理状態とを含む請求項２１記載のフレーマ。
【請求項３３】
動作状態は、エスケープバイトに対する処理を示すエスケープ状態をさらに含む請求項３２記載のフレーマ。
【請求項３４】
動作状態は、フレーム化パケットに対するフラグバイトの挿入を示すフラグ状態およびフレーム化パケットに対するＦＣＳ値の挿入を示すＦＣＳ状態をさらに含む請求項３２記載のフレーマ。
【請求項３５】
データブロックに対するフレーム化パケットの数を示す値を記憶するように動作可能な第１のレジスタをさらに具備する請求項２１記載のデフレーマ。
【請求項３６】
フレーム化すべきデータのパケットを一度に１ワードずつ受信して、各受信ワードに対して、後続の処理のために一度に１データバイトずつ供給するように動作可能な入力インタフェースユニットと、
入力インタフェースユニットからの各データバイトを評価して特定の値のバイトを検知するように動作可能な検知ユニットと、
エスケープすべき各データバイトに関するエスケープされたバイトを挿入してそのデータバイトをエスケープし、第１のコマンドの受信に応答してフラグバイトを挿入し、さらに第２のコマンドの受信に応答してＦＣＳ値を挿入することにより、インタフェースユニットからの各データバイトを処理して受信データをフレーム化するように動作可能な変換ユニットと、
ＲＦＣ１６６２により規定されたフォーマットを有するフレーム化データを供給するように動作可能な出力インタフェースユニットと
を具備するワイヤレス通信デバイス用のフレーマ。
【請求項３７】
フレーム化すべきデータのパケットを一度に１ワードずつ受信して、各受信ワードに対して、後続の処理のために一度に１データバイトずつ供給するように動作可能な入力インタフェースユニットと、
入力インタフェースユニットからの各データバイトを評価して特定の値のバイトを検知するように動作可能な検知ユニットと、
エスケープすべき各データバイトに対してエスケープされたバイトを挿入してそのデータバイトをエスケープし、第１のコマンドの受信に応答してフラグバイトを挿入し、第２のコマンドの受信に応答してＦＣＳ値を挿入することにより、インタフェースユニットからの各データバイトを処理して受信データをフレーム化するように動作可能な変換ユニットと、
ＲＦＣ１６６２により規定されたフォーマットを有するフレーム化データを供給するように動作可能な出力インタフェースユニットとを具備するワイヤレス通信デバイス用の集積回路。
【請求項３８】
データのパケットを一度に１ワードずつ受信することと、
各受信ワードの各データバイトを評価してエスケープすべきバイトを検知することと、
エスケープすべき各データバイトを示す状態信号を供給することと、
エスケープすべき各データバイトに関するエスケープバイトを挿入してデータバイトをエスケープすることと、
フラグ挿入コマンドの受信に応答してフラグバイトを挿入することと、
ＦＣＳ挿入コマンドの受信に応答してＦＣＳ値を挿入することと、
ＲＦＣ１６６２により規定されたフォーマットを有するフレーム化データを供給することとを含む、ＲＦＣ１６６２により規定されたフォーマットを有するフレーム化データを供給するためにデータのパケットをフレーム化する方法。
【請求項３９】
デフレーム化すべきデータの第１のブロックを受信して、特定の値の第１組のデータバイトを検知し、特別なデフレーム化スキームにしたがって第１のデータブロックをデフレーム化し、第１のデータブロックに関するデフレーム化データを供給するように動作可能なデフレーマと、
フレーム化すべきデータの第２のブロックを受信して、特定の値の第２組のデータバイトを検知して、特別なフレーム化スキームにしたがって第２のデータブロックをフレーム化し、第２のデータブロックに関するフレーム化データを供給するように動作可能なフレーマとを具備するワイヤレス通信デバイス用のＨＤＬＣアクセラレータ。
【請求項４０】
第１のデータブロック中のデフレーム化すべきデータおよび第２のデータブロック用のフレーム化データがそれぞれＲＦＣ１６６２により規定されたフォーマットを有する請求項３９記載のＨＤＬＣアクセラレータ。
【請求項４１】
フレーム化またはデフレーム化すべき各パケットに関するＦＣＳ値を発生するように動作可能な少なくとも１つのフレームチェックシーケンス（ＦＣＳ）発生器をさらに具備する請求項３９記載のＨＤＬＣアクセラレータ。
【請求項４２】
デフレーマからのデフレーム化データを記憶するように動作可能な第１のバッファをさらに具備する請求項３９記載のＨＤＬＣアクセラレータ。
【請求項４３】
フレーマからのフレーム化データを記憶するように動作可能な第２のバッファをさらに具備する請求項４２記載のＨＤＬＣアクセラレータ。
【請求項４４】
第１のバッファに記憶されたデフレーム化データまたは第２のバッファに記憶されたフレーム化データを取り出すように動作可能な少なくとも１つのバッファインタフェースユニットをさらに具備する請求項４３記載のＨＤＬＣアクセラレータ。
【請求項４５】
デフレーマおよびフレーマが複数の可能な動作状態の１つでそれぞれ動作する請求項３９記載のＨＤＬＣアクセラレータ。
【請求項４６】
デフレーム化すべきデータの第１のブロックを受信して、特定の値の第１組のデータバイトを検知し、特別なデフレーム化スキームにしたがって第１のデータブロックをデフレーム化し、第１のデータブロックに関するデフレーム化データを供給するように動作可能なデフレーマと、
フレーム化すべきデータの第２のブロックを受信して、特定の値の第２組のデータバイトを検知し、特別なフレーム化スキームにしたがって第２のデータブロックをフレーム化し、第２のデータブロックに関するフレーム化データを供給するように動作可能なフレーマと、
それぞれデフレーマおよびフレーマによるデフレーム化およびフレーム化を指示するように動作可能なコントローラとを具備するワイヤレス通信デバイス。
【請求項４７】
デフレーマからのデフレーム化データを記憶するように動作可能な第１のバッファと、
フレーマからのフレーム化データを記憶するように動作可能な第２のバッファとをさらに具備する請求項４６記載のデバイス。
【請求項４８】
Ｎビット値を記憶するように動作可能なラッチと、
ラッチと直列かつ環状に結合されている複数（Ｍ）の１ビットＣＲＣ発生器とを具備し、
各１ビットＣＲＣ発生器が、
先行する１ビットＣＲＣ発生器またはラッチからのＮビット値と各入力データビットとを受信して、受信されたＮビット値のＮ−１下位ビット（ＬＳＢ）を２だけスケーリングし、実行されている多項式に対応する予め決められた値をスケーリングされた値に選択的に加算して、１ビットＣＲＣ発生器に関するＮビット出力として、選択的に加算された結果を供給するように動作可能であるマルチビットＣＲＣ発生器。
【請求項４９】
Ｍが８である請求項４８記載のマルチビットＣＲＣ発生器。
【請求項５０】
Ｎが１６である請求項４８記載のマルチビットＣＲＣ発生器。
【請求項５１】
各１ビットＣＲＣ発生器は、
受信したＮビット値の最上位ビット（ＭＳＢ）に入力データビットを加算して、コントロール値を供給するように動作可能な第１の加算器と、
スケーリングされた値に予め決められた値を加算して、合計された値を供給するように動作可能な第２の加算器と、
コントロール値が０の場合にスケーリングされた値を供給し、コントロール値が１の場合に合計された値を供給するように動作可能であり、マルチプレクサの出力が１ビットＣＲＣ発生器に対するＮビット出力であるマルチプレクサとを有する請求項４８記載のマルチビットＣＲＣ発生器。
【請求項５２】
各１ビットＣＲＣ発生器は、
受信したＮビット値の最上位ビット（ＭＳＢ）に入力データビットを加算して、コントロール値を供給するように動作可能な第１の加算器と、
コントロール値が１の場合は予め決められた値を供給し、コントロール値が０の場合は０を供給するように動作可能なゲートと、
スケーリングされた値にゲートからの出力値を加算して、１ビットＣＲＣ発生器に対するＮビットの出力を供給するように動作可能な第２の加算器とを有する請求項４８記載のマルチビットＣＲＣ発生器。
【発明の詳細な説明】
【発明の分野】
【０００１】
この発明は一般的にデータ通信に関し、特にＰＰＰパケットをフレーム化およびデフレーム化するための“ハイレベルデータリンクコントロール”（ＨＤＬＣ）ハードウェアアクセラレータに関する。
【発明の背景】
【０００２】
インターネットのようなコンピュータネットワークの爆発的な発達は、これらのネットワークによる莫大な量のデータトラフィックをサポート可能な高速データレートインフラストラクチャに対する要求を引き起こしている。おおよそインターネットの発達と同時に、非常にさまざまなサービスをサポートすることが可能なワイヤレス通信の配置および受け入れがある。次世代ワイヤレス通信システムはデータおよび音声通信を提供するためにインターネットによりもたらされるデータトラフィックを考慮して効果的に設計される。
【０００３】
クライアントとサーバとの間のデータ通信は、一般的にいくつもの通信およびネットワークエレメントを経由して構築される。例えば、ワイヤレスリンクを通して遠隔でサーバにアクセスするために、端末はアクセスポイントを有するワイヤレスリンクを経由して通信し、さらにルータ、ハブ、ブリッジなどを介してサーバと通信する。これらのエレメントは互いにオープンモデルまたは所有モデルに基づいて定義される特定のプロトコルを介して通信する。
【０００４】
一般的に、標準規格インターネットデータ通信は、インターネットプロトコル（ＩＰ）レイヤの上位で動作するトランスミッションコントロールプロトコル（ＴＣＰ）レイヤを介してサポートされ、さらにポイントツーポイントプロトコル（ＰＰＰ）レイヤの上位で動作する。これらのレイヤは、オープンシステムインターコネクション基準モデルにより定義され、ＯＳＩモデルとして一般的に参照され、よく知られている技術である。ワイヤレス通信は、例えばＩＳ−８５６で規定される高速データレート（ＨＤＲ）レイヤのような物理レイヤの上位で動作する無線リンクプロトコル（ＲＬＰ）を介してサポートされる。
【０００５】
したがって、ワイヤレス通信デバイスは、パケットデータ通信に対してＰＰＰ、およびワイヤレス通信に対してＲＬＰをサポートする必要がある。特に、各プロトコルレイヤはそのプロトコルの送信単位に関するフォーマットを定義し、これはＲＬＰレイヤに対して“パケット”、およびＰＰＰレイヤに対して“フレーム”である。一般的に、各ＰＰＰフレームは、ＰＰＰパケットをカプセル化することによりもたらされる。
【０００６】
通常、ＰＰＰパケットデータをリカバするためのＲＬＰパケットの処理およびＰＰＰパケットを形成するためのＲＬＰパケットデータの処理は、プロセッサ上でソフトウェアを実行することにより行われる。各ＲＬＰパケット中のＰＰＰパケットデータをリカバするために、ソフトウェアは一般的にＲＬＰパケットの各バイトを取り出し、そのバイト上で何らかの処理を実行する必要があるかを決定し、そして、（もしあれば）必要な処理を行う必要がある。ＰＰＰとＲＬＰとの間におけるデータの“変換”は、プロセッサの処理能力の大きな割合を消費してしまう。これは、ワイヤレス通信デバイスのためにさらに速いプロセッサを必要し、および／またはそのデバイスにより提供される機能および特徴を制限する。そのうえ、一般的にソフトウェアで変換を行うためには追加的なメモリが必要である。
【０００７】
したがって、ＲＬＰパケットからＰＰＰパケットデータをリカバし、ＲＬＰパケットデータからＰＰＰパケットを形成することが可能なハードウェアアクセラレータに対する技術的な必要性が存する。
【発明の開示】
【発明の概要】
【０００８】
ＨＤＬＣアクセラレータは、ＰＰＰパケットに対するデフレーム化およびフレーム化処理を高速化するためにここに提供される。特に、専用のハードウェアＨＤＬＣデフレーマは、ＲＬＰパケットをデフレーム化してＰＰＰパケットデータをリカバするために提供され、専用のハードウェアＨＤＬＣフレーマは、ＲＬＰパケットデータからＰＰＰパケットをフレーム化するために提供される。デフレーマおよびフレーマは、十分なハードウェア回路を有するので、最小限のソフトウェアコントロールがデフレーム化およびフレーム化をそれぞれ実行するために必要とされる。
【０００９】
ある特定の実施形態は、ワイヤレス通信デバイス内で使われるためのデフレーマを提供する。デフレーマは、入力インタフェースユニット、検知ユニット、変換ユニット、および出力インタフェースユニットを備える。入力インタフェースユニットは、例えばデフレーム化すべきデータのＲＬＰパケットを一度に１ワード受信して、受信された各ワードを次の処理のために一度に１データバイトずつ提供する。ＲＬＰパケットはインターネット標準規格ＲＦＣ１６６２により規定されているフォーマットを有する１つ以上の完全なおよび／または部分的なＰＰＰパケットを含む。検知ユニットは、入力インタフェースユニットからの各データバイト評価して特別なバイト（例えば、フラグ、エスケープ、および無効なバイト）を検知する。変換ユニットは、フラグおよびエスケープバイトを除去して、各エスケープバイトの後続のデータバイトを（例えば、“０ｘ２０”でデータバイトを排他的論理和演算することにより）“アンエスケーピング”し、各フラグバイトに関するヘッダワードを供給して、各デフレーム化パケットをそのパケットに関係するフレームチェックシーケンス（ＦＣＳ）に基づいて検査することにより、入力インタフェースユニットからのデータをデフレーム化する。出力インタフェースユニットは、デフレーム化データを提供し、さらにデフレーム化データを提供する際にバイトアラインメントを実行する。また、デフレーマは、デフレーム化のために実行される特定のタスク（例えば、ヘッダの挿入、エスケープバイトの除去など）を示すコントロール信号を提供するように動作可能な状態コントロールユニットを備える。
【００１０】
別の特定の実施形態はワイヤレス通信デバイス内で用いられるフレーマを提供する。フレーマは、入力インタフェースユニット、検知ユニット、変換ユニット、および出力インタフェースユニットを備える。入力インタフェースユニットは、フレーム化すべきデータのパケットを１度に１ワードずつ受信し、受信された各ワードを次の処理のために一度に１データバイトずつ提供する。検知ユニットは、入力インタフェースユニットからの各データバイトを評価して特定の値のバイト（例えば、エスケープ化すべき必要のあるバイト）を検知する。変換ユニットは、エスケープ化すべき各データバイトに対してエスケープバイトを挿入し、フラグバイト挿入コマンドの受信に応答してフラグバイトを挿入し、ＦＣＳ値挿入コマンドの受信に応答してＦＣＳ値を挿入することにより、入力インタフェースユニットからのデータをフレーム化する。出力インタフェースユニットは、ＲＦＣ１６６２に規定されるフォーマットを有するフレーム化データを提供する。また、フレーマは、フレーム化のために実行される特定のタスク（例えば、フラグの挿入、エスケープバイトの挿入、ＦＣＳの挿入など）を示すコントロール信号を提供するように動作可能な状態コントロールユニットを備える。
【００１１】
発明のさまざまな観点および実施形態は、さらに以下で詳細に説明する。さらに、発明は、以下でさらに詳細に記載されるように、デジタル信号プロセッサ、集積回路、方法、ワイヤレス通信デバイス、端末、基地局、システム、および、発明のさまざまな観点、実施形態、および特徴を構成する他の器具およびエレメントを提供する。
【詳細な説明】
【００１２】
図１は、音声やデータ通信をサポート可能な通信システム１００の一実施形態を示す図である。システム１００は、例えば、固定された環境、携帯可能な環境、または移動可能な環境においてワイヤレスインターネットサービスを提供するのに使用される。システム１００は、ワイヤラインリンクおよび／またはワイヤレスリンクを介してさまざまなデバイス１０８をインタフェースする多数のアクセス端末１１０を備える（単純にするために１端末、１デバイスのみが図１に示されている）。デバイス１０８は、例えば、コンピュータ、電気器具、パーソナルデジタルアシスタント（ＰＤＡ）、セットトップボックス、プリンタなどである。
【００１３】
それぞれのアクセス端末１１０は１つ以上のアクセスポイント１２０とワイヤレスリンクを介して通信を行う（単純にするために図１では、１つのアクセスポイントのみが示されている）。アクセス端末とアクセスポイントの無線リンクは、（例えば、ＣＤＭＡ，ＴＤＭＡ，ＦＤＭＡなどの）さまざまな技術に基づき、多様な設計を用いて実現される。各アクセスポイント１２０は、そのカバレッジエリア内に位置する多数のアクセス端末１１０に対するデータ送信をサポートする。各アクセスポイント１２０は、高速通信リンク（例えばＴ1／Ｅ１またはイーサネット（登録商標））を介して１つ以上のルータ１３０にさらに結合する。それぞれのルータ１３０はアクセスポイント、他のネットワーク要素（例えばローカルサーバ１４２ａ）、それに結合されたネットワーク（例えばＩＰネットワーク１４０）間のトラフィックを指示する。ＩＰネットワーク１４０は、他のネットワークエレメント（例えばリモートサーバ１４２ｂ）やローカルエリアネットワーク（ＬＡＮ）または、パケットデータサービングノード（ＰＤＳＮ）などと結合する。
【００１４】
アクセス端末１１０は、例えば端末、セルラ電話機、ハンドセット、モデム、モジュールなどのさまざまな物理的な実施形態で構成される。アクセス端末１１０は、ワイヤレスモデムとデータインタフェースを備え、（例えば、ＣＤＭＡなどの）ワイヤレスネットワークを介してユーザがサーバにアクセスすることができるようにする。このデータインタフェースは、アクセス端末１１０がワイヤラインリンクおよび／またはワイヤレスリンクを介して他のデバイスとインタフェースできるようにする。
【００１５】
また、図１は、ウェブブラウジングセッション中における通信システム１００のプロトコルスタックの特定の実施形態を示す。ユーザは、ユーザのコンピュータ（クライアント）において、ウェブブラウザアプリケーションを実行して、ローカルサーバ１４２ａやリモートサーバ１４２ｂのようなサーバ上に記憶されているデータにアクセスする。ウェブブラウジングセッションが確立された後、クライアント１０８からサーバ１４２への、通信経路のさまざまなエレメントにおけるプロトコルスタックを図１の下方に示す。
【００１６】
図１に示したプロトコルスタックは、特定の実施を表す。クライアントやサーバは、クライアントとサーバとの間で通信をサポートするＴＣＰおよびＩＰの上位で動作するウェブアプリケーションを実行する。クライアントとアクセス端末との間の通信はイーサネットまたは他の何らかのインタフェースを介して行われる。また、アクセス端末とアクセスポイントとの通信はＲＬＰおよびＨＤＲ（これらは無線リンクプロトコルである）の上位にあるＩＰおよびＰＰＰ（これらは標準のインターネットプロトコルである）を介して行われる。他のネットワークエレメント間における通信は、図１に示すように行われる。また、その他のプロトコルを使用してクライアントとサーバと間の通信を容易にしてもよい。
【００１７】
図２は、アクセス端末１１０ｘの特定の実施形態のブロック図である。この実施形態では、アクセス端末１１０ｘは、受信経路と送信経路とを介して双方向通信を提供することができる。
【００１８】
受信経路においては、１つ以上の送信された信号がアンテナ２１２により受信され、デュプレクサ（Ｄ）２１４を通してルーティングされ、受信機（ＲＣＶＲ）２１６に与えられる。受信機２１６は、受信信号を調整（例えば、フィルタ、増幅、およびダウンコンバート）し、調整された信号をデジタル化して、データサンプルを提供する。そして、復調器（ＤＥＭＯＤ）２２２は、データサンプルを処理して復調データを生成する。ＣＤＭＡシステムでは、復調器２２２による処理には、（１）擬似ランダムノイズ（ＰＮ）シーケンスまたは逆スクランブルコードでデータサンプルを逆拡散すること、（２）チャネル化コード（例えば、ウォルシュコードまたはＯＶＳＦコード）で逆拡散されたデータをデカバすること、および（３）復元されたパイロットでデカバされたデータを復調して、復調データを供給することが含まれてもよい。
【００１９】
デコーダ２２４は、送信システムにおいて用いられるインターリービングおよびコーディングスキームと相補的であるデインターリービングおよびデコーディングスキームにしたがって、各データフレームまたはパケットをデインターリーブして、デコードする。例えば、重畳、ターボおよび／またはブロックデコーディングのそれぞれが送信機システムで行われる場合には、ビタビ、ターボおよび／またはブロックデコーディングが行われてもよい。
【００２０】
デコードされたデータはＣＤＭＡシステムで通常用いられる巡回冗長検査（ＣＲＣ）コードに基づいて、フレームエラーについてさらに検査される。デコードされたデータは、メインコントローラ２３０に与えられてもよく、および／または記憶ユニット（例えば、メモリ２３２など）に記憶させてもよい。
【００２１】
送信経路においては、アクセス端末１１０ｘから送信されるべきデータは、処理のためにエンコーダ２５２へ供給される。エンコーダ２５２は、ＣＲＣ、重畳、ターボおよび／またはブロックコーディングの任意の組み合わせを含む特定のコーディングスキームにしたがって、受信データをコード化する。コード化データは特定のインターリービングスキームにしたがってインターリーブされ、インターリーブされたデータは変調器（ＭＯＤ）２５４によりさらに処理される。ＣＤＭＡシステムでは、変調器２５４による処理には、チャネル化コードを用いてデータをカバーすること、およびＰＮシーケンスまたはスクランブルコードを用いてカバーされたデータを拡散することが含まれてもよい。そして、変調データは、変調信号を生成するために、送信機（ＴＭＴＲ）２５６により調整され（例えば、フィルタ、増幅、およびダウンコンバートされ）、この変調信号はデュプレクサ２１４を通してルーティングされて、アンテナ２１２を介して送信される。
【００２２】
メインコントローラ２３０は、音声／データ通信のためのさまざまな処理機能を実行することができ、さらにアクセス端末１１０ｘ内でさまざまな処理ユニットの動作を指示するために使用されてもよい。メインコントローラ２３０は、縮小命令セットコンピューティング（ＲＩＳＣ）プロセッサ、複雑命令セットコンピューティング（ＣＩＳＣ）プロセッサなどのようなさまざまな設計に基づき構成される。“ハイレベルデータリンクコントロール”（ＨＤＬＣ）アクセラレータ２４０は、以下でさらに詳細に説明するように、１つのプロトコルでパケットデータを処理して、別のプロトコルでパケットを復元または形成する。入力／出力（Ｉ／Ｏ）インタフェースユニット２４２は、外部デバイス１０８（例えば、コンピュータなど）にインタフェースを提供する。
【００２３】
図２に示した実施形態において、システムバス２２８は、アクセス端末１１０ｘ内のさまざまな処理ユニットを相互接続する。システムバス２２８は、アドバンスドシステムバス（ＡＳＢ）、アドバンスド周辺バス（ＡＰＢ）、または、他の任意のバス設計により構成される。処理ユニットのいくつかは、特定用途向け集積回路（ＡＳＩＣ）内で構成することもできる。例えば、ＡＳＩＣ２２０は、図２の処理ユニット２２２ないし２５４を含むように設計されてもよい。
【００２４】
図１に示すように、アクセス端末はアクセスポイントとの通信のためにＩＰ、ＰＰＰ、ＲＬＰ、およびＨＤＲをサポートするように設計される。各プロトコルは、そのプロトコル送信ユニットのためのフォーマットを具体的に規定し、これはＲＬＰに対して“パケット”および、ＰＰＰに対して“フレーム”である。各ＰＰＰフレームは、一般的には、ヘッダおよび／またはトレーラでＰＰＰパケットをカプセル化することによって形成される。
【００２５】
図３Ａは、ＰＰＰ  ＨＤＬＣ状のフレーム構造に基づいたフレームフォーマット３１０を示した図であり、ＰＰＰ  ＨＤＬＣ状のフレーム構造は、“ＨＤＬＣ状のフレーム化におけるＰＰＰ”と題するインターネット標準規格ＲＦＣ１６６２で説明され、この標準規格は、参照によりここに組み込まれている。フレームフォーマットは、フラグフィールド３１２、アドレスフィールド３１４、コントロールフィールド３１６、プロトコルフィールド３１８、情報フィールド３２０、パディングフィールド３２２、およびフレームチェックシーケンス（ＦＣＳ）フィールド３２４を含む。フラグフィールド３１２は、ＰＰＰパケットの開始または終了を表し、“０ｘ７ｅ”の値を持つ。ＦＣＳフィールド３２４は、フィールド３１４ないし３２２までのデータに基づいて生成された、１６ビットあるいは３２ビットの値を含む。このＦＣＳ値はＰＰＰパケットが正確に受信されたか誤って受信されたかどうかを決定するために使用される。他のすべてのフィールドは、前述したＲＦＣ１６６２の文書で規定されている。
【００２６】
ＰＰＰパケットは、上位レイヤからＰＰＰレイヤに渡される基本データ単位であり、ＰＰＰフレームのデータペイロードである。ＰＰＰパケットデータは、下位レイヤ（例えば、ＲＬＰレイヤ）のデータペイロードであるＰＰＰフレームを得るために“フレーム化”される。ＲＬＰパケットはＲＬＰレイヤのペイロードであり、１つまたは複数の部分的なおよび／または完全なＰＰＰフレームを含み、各ＰＰＰフレームはＰＰＰフレームのデータペイロードである１つＰＰＰパケットを含む。
【００２７】
図３Ｂは、ＲＬＰパケット３３０のシーケンスとＰＰＰフレーム３４０のシーケンスとの間の関係を示した図である。各ＲＬＰパケットは、例えばＣＤＭＡ標準規格によって決定されるような、ある一定の期間のものであるとして一般的に定義され、これは１０ミリ秒または２０ミリ秒であってもよい。所定のデータレートに対して、各ＲＬＰパケットは、特定数のビットを含む。対照的に、ＰＰＰフレームは可変長でもよい。したがって、ＲＬＰパケットおよびＰＰＰフレームの境界は、明確な関係によって定義されない。ＲＬＰパケットは、１つのＰＰＰフレーム、複数のＰＰＰフレーム、あるいはＰＰＰフレームの一部のみを含んでもよい。各ＲＬＰパケットの開始はシステムタイムに合わせられ、各ＰＰＰフレームの開始はフラグバイト（図３Ｂで“Ｆ”として示され、“０ｘ７ｅ”の値を持つ）により示される。
【００２８】
一般的には、１つのプロトコルからなるデータは、別のプロトコルに対して適切にフォーマットされたデータを提供するために処理される必要がある。例えば、アクセス端末により受信されたアクセスポイントからのワイヤレスデータ送信のために“デフレーム化”が実行される。この場合、アクセス端末において、ＲＬＰパケットは物理レイヤから受信され、ＲＬＰパケット内のＰＰＰパケットデータを復元するためにデフレーム化が必要となる。その後、デフレーム化ＰＰＰパケットデータは、高位のレイヤに提供される。これに対して、フレーム化は、アクセス端末からアクセスポイントへのワイヤレスデータ送信のために実行される。この場合、アクセス端末では、ＰＰＰパケットデータが高位レイヤから受信されて、フレーム化ＰＰＰパケットを形成するためにフレーム化され、物理レイヤへのＲＬＰパケットに供給される。デフレーム化およびフレーム化の動作は以下でさらに詳しく記述される。
【００２９】
従来、ＰＰＰパケットデータをフレーム化およびデフレーム化するためにソフトウェアが用いられる。デフレーム化動作を実行してＲＬＰパケットからＰＰＰパケットデータを復元するためにまず１つ以上のＲＬＰパケットがＲＬＰバッファに記憶される。そして、ソフトウェアはＲＬＰバッファ内の各バイトを取り出し、必要ならばそのバイトを処理し、各ＰＰＰパケットに関するＦＣＳ値（例えば、ＣＲＣ値）を検査し、デフレーム化ＰＰＰパケットデータを別のバッファに記憶させる。このデフレーム化処理は一般的に、十分な量の処理能力と追加的な記憶を必要とする。ＲＬＰパケットデータを処理してＰＰＰパケットを形成するためのフレーム化動作も処理能力と記憶を必要とする。
【００３０】
ある観点では、デフレーム化およびフレーム化処理を高速化するために、ＨＤＬＣアクセラレータが提供される。特に、専用のハードウェアＨＤＬＣデフレーマは、ＲＬＰパケットをデフレーム化してＰＰＰパケットデータを復元するためにするために提供され、専用のハードウェアＨＤＬＣフレーマは、ＲＦＣ１６６２にしたがって、ＰＰＰパケットをＰＰＰフレームにフレーム化するために提供される。
【００３１】
図４は、ＰＰＰパケットのためのフレーム化およびデフレーム化を実行するために用いられる、ＨＤＬＣアクセラレータ２４０ｘのブロック図である。ＨＤＬＣアクセラレータ２４０ｘは、図２のＨＤＬＣアクセラレータ２４０の一実施形態である。ＨＤＬＣアクセラレータ２４０ｘは、ＨＤＬＣアクセラレータ２４０ｘのさまざまな動作を指示するメインコントローラ２３０と（例えば、システムバス２２８を介して）インタフェースする。図４に示される実施形態において、ＨＤＬＣアクセラレータ２４０ｘは、デフレーマ４１０、フレーマ４２０、ＦＣＳ発生器４１６および４２６、ならびに出力バッファインタフェースユニット４１８および４２８を備えている。
【００３２】
デフレーマ４１０は、ＲＬＰパケット内のＰＰＰパケットを受信してデフレーム化し、デフレーム化ＰＰＰパケットデータをデフレーマ出力バッファ２３２ａに提供する。デフレーマ４１０は、デフレーム化動作をコントロールする状態コントロールユニット４１２と、実際のデフレーム化（例えば、受信されたＰＰＰパケット内のフラグやエスケープバイトを除去し、各ＰＰＰパケットに関するＦＣＳ値を検査する）を実行するデフレーミングロジックユニット４１４とを備える。これに対応して、フレーマ４２０はＰＰＰパケットデータを受信してＲＬＰパケットにフレーム化し、フレーム化ＰＰＰパケットをフレーマ出力バッファ２３２ｂに提供する。フレーマ４２０は、フレーム化動作をコントロールする状態コントロールユニット４２２と、実際のフレーム化（例えば、フラグやエスケープバイトを挿入し、各フレーム化ＰＰＰパケットに関するＦＣＳ値を生成して挿入する）を実行するフレーミングロジックユニット４２４とを備える。状態コントロールユニット４１２および４２２は、２つの別々の有限状態機械（ＦＳＭ）として、または１つに一体化されたＦＳＭとして構成されてもよい。
【００３３】
ＦＣＳ発生器４１６および４２６は、デフレーム化およびフレーム化動作のためのＦＣＳ値をそれぞれ生成するために使用される（または１つのＦＣＳ発生器がフレーマとデフレーマとに共有されてもよい）。デフレーム化動作において、ＦＣＳ値が使用されて、ＰＰＰパケットがエラー検査をパスするかどうかが決定される。フレーム化動作において、ＦＣＳ値は各ＰＰＰパケットの終わりに追加される。ＦＣＳ発生器４１６および４２６は、ＣＲＣまたは他の任意のエラー検知コーディングスキームにより実現してもよく、以下でさらに詳しく記述される。
【００３４】
デフレーマおよびフレーマ出力バッファ２３２ａおよび２３２ｂは、デフレーマ４１０およびフレーマ４２０の出力をそれぞれ記憶する。出力バッファ２３２ａおよび２３２ｂは、図２のメモリ２３２の一部として構成されてもよい。出力バッファインタフェースユニット４１８および４２８は、デフレーマおよびフレーマ出力バッファ２３２ａおよび２３２ｂからそれぞれデータを読み取る。インタフェースユニット４１８および４２８は、アクセススキームをサポートするためにそれぞれ設計されていてもよく、これによって、完全なＰＰＰパケットにまたはデフレーマおよびフレーマの出力バッファのコンテンツ全体にアクセスするために、１つの読み取り動作が実行される。
【００３５】
ある実施形態において、フレーム化およびデフレーム化動作を実行するためのハードウェア回路は、サイズ、コスト、およびシステムバスへの負荷を削減するために共有されてもよい。
【００３６】
ＨＤＬＣアクセラレータ２４０ｘは、前述のＲＦＣ１６６２標準規格のようなさまざまな標準規格を実現するために使用されてもよい。ハイレベルデータリンクコントロールは、ＩＳＯ／ＩＥＣ３３０９：１９９１（Ｅ）からの文書でも記述されており、これは国際標準化機構、第４版、１９９１年６月１日付、“情報技術−システム間の遠隔通信および情報交換−ハイレベルデータリンクコントロール（ＨＤＬＣ）プロシージャ−フレーム構造”と題されており、参照によりここに組み込まれている。
【００３７】
（ＨＤＬＣデフレーム化）  
デフレーム化動作において、デフレーマにはＲＬＰパケットが提供され、ＲＬＰパケットは、部分的なＰＰＰパケット、１つの完全なパケット、または複数の完全または部分的なＰＰＰパケットを含む。それぞれの完全なＰＰＰパケットは図３Ａに示したように、フラグ、アドレス、コントロール、プロトコル、情報、パディングおよびＦＣＳフィールドを含んでいる。そして、デフレーマは、ＲＬＰパケット内のＰＰＰパケットをデフレーム化するために次の１組のタスクを行う。
【００３８】
・フラグバイト（“０ｘ７ｅ”）を除去する。  
・ＲＬＰパケット内に出現した各エスケープバイト（“０ｘ７ｄ”）を除去し、“０ｘ２０”で排他的論理和演算することにより、エスケープバイトに続く後続バイトを復元する。  
・それぞれ完全なＰＰＰパケットに対してＦＣＳを検査する。  
・デフレーマ出力バッファにデフレーム化ＰＰＰパケットデータを記憶させる際にバイトアラインメントを実行する。  
・ＲＬＰパケットのためのデフレーム化ＰＰＰパケットデータを（例えば、後述する記憶フォーマットを使用して）デフレーマ出力バッファに記憶させる。
【００３９】
上述したＲＦＣ１６６２標準規格で記述されているように、各ＰＰＰパケットは、フラグバイトにより各サイドがマーキングされ、これはデフレーマにより除去される。フレーム化中に、フレーム化されているデータ内のあるバイトは、（１）そのようなバイトのそれぞれの前にエスケープバイトを挿入して、（２）そのようなバイトの５番目のビットを“０ｘ２０”と排他的論理和演算することで反転させることにより、“エスケープ”されていてもよい。エスケープされるべきその特定のバイトは、非同期コントロールキャラクタマップ（ＡＣＣＭ）により定義される。デフレーム化中には、これらのバイトを“アンエスケープ”するために逆の動作が行われる。デフレーム化タスクは、以下でさらに詳しく説明する。
【００４０】
明瞭にするために、いくつかの観点と実施形態とが以下に記述され、そこでは、デフレーム化が各ＲＬＰパケット上で行われ、各ＲＬＰパケットに対するデフレーム化ＰＰＰパケットデータがデフレーマ出力バッファに記憶される。デフレーム化は、データの他の何らかの単位（すなわち、他の何らかのサイズのデータのブロック）上で行われてもよく、これは本発明の範囲内である。
【００４１】
デフレーマは、デフレーム化のためにＲＬＰパケットを受信する。このＲＬＰパケットは部分的なＰＰＰパケットまたは、１つ以上の完全なおよび／または部分的なＰＰＰパケットを含んでいてよく、完全なＰＰＰパケットのそれぞれは図３Ａに示したフィールド３１２ないし３２４から構成されている。デフレーマはフィールド３１２のフラグバイトおよびエスケープバイトを除去して、その他の処理を実行する。その後デフレーマは、フィールド３１４ないし３２２からなる各デフレーム化ＰＰＰパケットをデフレーマ出力バッファに供給する。
【００４２】
図５Ａは、デフレーマ出力バッファ２３２ａ用の記憶フォーマットの特定の実施形態の図である。実施形態では、デフレーム化され出力バッファに記憶された全部または部分的なＰＰＰパケットのそれぞれに対して、ヘッダワードがデフレーマ出力バッファに供給される。特に、ヘッダワード５１２ａは最初のデフレーム化ＰＰＰパケットに対して供給され、ヘッダワード５１２ｂは後続の各デフレーム化ＰＰＰパケットに対して供給される。ＲＬＰパケットは１つまたは複数の完全なおよび／または部分的なＰＰＰパケットを含むので、１つまたは複数のヘッダが出力バッファに供給され記憶されてもよい。
【００４３】
各ヘッダワードは、デフレーマ出力バッファでデータを処理するために高位レイヤにより（例えば、メインコントローラ２３０上で実行されるソフトウェアにより）利用される情報を含む。ある実施形態では、各ヘッダワードは３つのフィールド、すなわちfcs_passビット(“Ａ”)５１４ａ、PPP_endビット(“Ｂ”)５１４ｂ、およびPPP_length（バイト単位）フィールド(“Ｃ”)５１４ｃを含む。fcs_passビットは、ＰＰＰパケットがフレーム検査をパスしたかどうかを示し、このフレーム検査は完全なＰＰＰパケットが受信された場合にのみ有効である。PPP_endビットは、現在のデフレーマ出力バッファ内に完全なＰＰＰパケットが含まれているかどうかを示す。このビットはＰＰＰパケットが次のデフレーマ出力バッファに続くことを示すためにゼロ（“０”）にセットされる。PPP_lengthフィールドはデフレーマ出力バッファ内に含まれるＰＰＰパケットの長さを（バイト単位で）示す。
【００４４】
図５Ａに示すように、各ヘッダワードの後にデフレーム化ＰＰＰパケットデータが続き、このパケットデータはPPP_lengthフィールドで分かるように任意の長さである。１つ以上のＰＰＰパケットが所定のＲＬＰパケットに対してデフレーム化されてデフレーマ出力バッファに記憶されることから、多くの短いＰＰＰパケットが１つのＲＬＰパケットに含まれるという最悪のシナリオを処理できるようにするため、デフレーマ出力バッファは所定の大きさに作られる。
【００４５】
図５Ｂはデフレーム化動作に関するバイトアラインメントおよびＲＬＰパケットとデフレーマ出力バッファとの関係を図示した図である。この例では、２つのＲＬＰパケットが順にデフレーム化されることとなっている。最初のＲＬＰパケットは、矢印により示されるように、２つの開始オフセットでＲＬＰバッファに記憶される。この開始オフセットは高位レイヤにより提供されてもよい。この例では、１つの長いＰＰＰパケットが複数のＲＬＰパケットに及んでいる。
【００４６】
デフレーム化動作を実行するために、まず一番目のＲＬＰパケット（ＲＬＰ１）がデフレーマに送信または書き込まれる。ＲＬＰパケットはＲＬＰバッファを完全に満たしていなくてもよく、最初のバイト位置で開始し、または最後のバイト位置で終了してＲＬＰバッファに書き込まれていなくてもよい。図５Ｂに示す例では、ＲＬＰバッファ内のＲＬＰ１に関する最初のワードは、“０１”および“０２”の２バイトのみからなる部分的なワードである。この部分的なワードは、バイト送信を用いて一度に１バイトずつデフレーマに送信できる。ワード境界に達した後、バイト送信より早いワード送信を用いて、一度に１ワードずつ全てのワードがデフレーマに送信される。特に、デフレーマに複数のワードを（ここでも、一度に１ワードずつ）送信するために、シングルバースト書き込み動作が実行されてもよい。実施形態では、ワードは４バイトを含んでいるが、他のワード長が用いられてもよく、これは本発明の範囲内である。ＲＬＰ１の最後の３バイトもバイト送信を用いてデフレーマに送信される。実施形態では、ＲＬＰバッファ内の有効なバイトのみがデフレーマに送信される。
【００４７】
最初のＲＬＰパケットはデフレーマによりデフレーム化され、デフレーマ出力バッファに記憶される。図５Ｂに示すように、ＲＬＰ１に関して、デフレーマ出力バッファはＲＬＰ１内のＰＰＰパケットに対するヘッダワード５１２ｘ、そしてデフレーム化ＰＰＰパケットに対するデータを含む。この例では、ＰＰＰパケットが次のＲＬＰパケットに続くので、ＲＬＰ１の最後のバイト（“０５”）は現在の出力バッファに記憶されず、かわりに次の出力バッファに記憶される。このように、デフレーマ出力バッファ内のバイトはワード境界で可能な限り整列され、出力バッファ内に記憶されたデータの取り出しと処理を簡単にする。
【００４８】
次に、２番目のＲＬＰパケット（ＲＬＰ２）も同様にデフレーマに送信され、処理される。ここでも、ＲＬＰ２に関する最初のワード（バイト“０６”のみを含む）を送信するためにバイト送信を用いてよい。その後、後続するすべてのワードに対してワード送信が実行される。そして最後に、１つのバイト“０７”のみからなる最後のワードのためにバイト送信が実行される。
【００４９】
２番目のＲＬＰパケットはデフレーム化され、デフレーマ出力バッファに記憶される。ＲＬＰ２に関して、デフレーマ出力バッファはＲＬＰ２内のＰＰＰパケットに対するヘッダワード５１２ｙ、およびデフレーム化ＰＰＰパケットに対するデータを含む。出力バッファ内の最初のデータワードは前のＲＬＰパケットから持ち越されたバイト“０５”を含み、これはデータワードの最初に含まれる。この例では、ＰＰＰパケットはこのＲＬＰパケット内で終わるので、バイト“０７”で終わる最後の部分的なワードがデフレーマ出力バッファに書き込まれる。
【００５０】
図５Ａおよび５Ｂに示されるデフレーマ出力バッファ用記憶フォーマットは、バイトをワード境界に（可能な限り）整列する。そして、これにより、高位レイヤ（例えば、メインコントローラ）が、デフレーマ出力バッファに記憶されたデフレーム化ＰＰＰパケット上でバイトアラインメント動作を実行しなくてもよいようになる。バイトアラインメントは、デフレーム化動作内のタスクの１つとしてデフレーマにより行われてもよいが、他のデフレーマ設計はこのバイトアラインメントタスクを省略してもよく、これも本発明の範囲内である。
【００５１】
ある実施形態では、ＲＬＰパケット内のすべての有効なバイトをデフレーマへ送信すると、dwrite_doneコマンドが（例えば、メインコントローラにより）デフレーマに発行される。そうするとデフレーマは、前のＲＬＰパケットからデフレーム化されたＰＰＰパケットの数を示すために、deframer_lengthレジスタを更新する。その後、処理されたばかりのＲＬＰパケットに対してデフレーマ出力バッファからデフレーム化ＰＰＰパケットを取り出すためにバースト読み取りが実行され、デフレーム化のために次のＲＬＰパケットが同時にデフレーマへ供給されてもよい。
【００５２】
図６Ａは、図４のデフレーマ４１０の特定の実施形態であるデフレーマ４１０ｘのブロック図である。デフレーマ４１０ｘは状態コントロールユニット４１２およびデフレーミングロジックユニット４１４を備え、さらに入力インタフェースユニット６１０、検知ユニット６２０、変換ユニット６３０、および出力インタフェース６４０を備える。これらのユニットの簡単な説明が以下で記述され、より詳細な説明はその次に提供される。
【００５３】
入力インタフェースユニット６１０は、デフレーム化すべきＰＰＰパケットを含むＲＬＰパケットデータを（例えば、システムバス２２８を介して）受信し、（例えば、メインコントローラ２３０からの）信号をコントロールし、一度に１バイトずつ検知ユニット６２０へ受信データを供給する。検知ユニット６２０は、受信データ内の特定のタイプのバイト（例えば、フラグ、エスケープ、および無効バイト）を検知し、いつこれらのバイトが検知されたかを示す信号を提供する。
【００５４】
変換ユニット６３０は、ＰＰＰパケットをデフレーム化するための処理を実行し、この処理にはフラグやエスケープバイトの除去、ＦＣＳ値を使用したそれぞれ完全なＰＰＰパケットの検査が含まれる。変換ユニット６３０は、デフレーマ出力バッファに記憶されたそれぞれ完全なまたは部分的なＰＰＰパケット用および出力バッファの終了用のヘッダワードをさらに提供する。最初に、まずデフレーマ出力バッファの開始用またはそれぞれの新しいＰＰＰパケット用にヘッダワードが書き込まれ、PPP_lengthフィールドは知られていない。出力インタフェースユニット６４０の内部のアドレス発生器は、各パケットがデフレーム化された後にヘッダ位置に戻り、この処理されたＰＰＰパケットのヘッダに関する情報fcs_pass、PPP_end、およびPPP_lengthが更新される。このように、デフレーマがフラグバイトに出会うたびに、各ＰＰＰパケットに対するデフレーム化の終了時にヘッダが更新される。また、デフレーマがdwrite_doneコマンドに出会うたびにヘッダへジャンプして戻り、ヘッダを更新する。deframer_lengthレジスタは、１つのＲＬＰパケットがデフレーム化された後にデフレーマ出力バッファ内に有効なヘッダがいくつ含まれているかをメインコントローラに知らせるために使用される。
【００５５】
出力インタフェースユニット６４０はヘッダデータとデフレーム化ＰＰＰパケットデータとを受信し、このデータをデフレーマ出力バッファに供給する。出力インタフェースユニット６４０はアドレス発生器とコントロール信号発生器とをさらに備え、これらは出力バッファに対してアドレスおよびコントロール信号をそれぞれ発生するために用いられる。
【００５６】
図７は、デフレーム化を実行するためのプロセス７００の一実施形態を示すフローチャートである。プロセス７００は、ＲＬＰパケットをデフレーマに送信する（または書き込む）ステップ（ブロック７１０）と、デフレーマによりＲＬＰパケットを処理するステップ（ブロック７２０）とを含む。これらのステップは、デフレーマ内部の異なるハードウェア回路により同時に実行されてもよい。デフレーマは各新規データセッションの開始時にリセットされる（ステップ７０８）。
【００５７】
ＲＬＰパケットをデフレーム化するために、始めに、ＲＬＰバッファ内の最初の部分的なワードの先頭バイトをデフレーマに書き込むために、ＲＬＰバッファのワード境界に達するまでバイト送信が実行される。そして、ＲＬＰバッファ内のワード全体をデフレーマに書き込むためにワード書き込みまたはバースト書き込みが行われる（ステップ７１４）。その後、ＲＬＰパケットがワード境界で終了していない場合、最後の部分的なテールバイトをデフレーマに書き込むためにバイト送信が行われる（ステップ７１６）。ＲＬＰバッファ内にあるＲＬＰパケットに関するすべてのデータがデフレーマに送信されるとき、dwrite_doneインジケータが（例えば、図６Ａのdwrite_en信号上で）デフレーマに送られる（ステップ７１８）。そして、次のＲＬＰパケットに対する書き込み動作がＲＬＰバッファの始まりから実行される。
【００５８】
デフレーマはバイトおよびワード送信から受信した各バイトを検査して処理する（ステップ７２２）。デフレーマは、フラグバイトが受信される場合（および、デフレーマ出力バッファの開始の場合にも）に、ヘッダワードを準備し、エスケープバイトを除去し、有効なバイト数だけカウンタをインクリメントする。デフレーマはそれぞれ完全なＰＰＰパケットに関するＦＣＳ値も検査する（ステップ７２４）。ＲＬＰパケットの処理が完了すると、デフレーマは処理されたばかりのＲＬＰパケットについてデフレーマ出力バッファに記憶されたデフレーム化ＰＰＰパケット数を表す値をdeframer_lengthレジスタに記憶させる（ステップ７２６）。何らかのＰＰＰパケットバイトがデフレーマ出力バッファの限界の外側のアドレスに書き込まれた場合には、デフレーマはさらにdeframer_errorレジスタをアサートする（ステップ７２８）。
【００５９】
図８はデフレーマ４１０ｘに関する状態の一実施形態の状態図である。実施形態では、任意の所定の時間に、デフレーマは４つの起こりうる状態、待機状態８１０、処理状態８１２、エスケープ状態８１４、ヘッダ状態８１６のうちの１つの状態になる。
【００６０】
・待機状態８１０。デフレーマはまず（例えば、データセッション開始時に）リセットされると待機状態で開始する。デフレーマは、デフレーマにＲＬＰパケットを書き込むための書き込みが開始される前、および書き込みが完了した後にもこの状態である。この状態にある間は、デフレーマはデフレーマ出力バッファに書き込まないが、すでに出力バッファに記憶されているデータは（例えば、メインコントローラによるバースト読み取りを経由して）読み取ることができる。
【００６１】
・処理状態８１２。デフレーマは、デフレーマにＲＬＰパケットを書き込むための書き込みが行われている間は処理状態にある。ＲＬＰパケットは、デフレーム化すべき１つ以上の完全なおよび／または部分的なＰＰＰパケットを含む。デフレーマは、バイトを受信するにしたがって処理し、有効なバイトの各ワードが利用可能であるように（例えば、４番目の有効なバイトごとに）デフレーム化データを連続的にデフレーマ出力バッファに書き込む。
【００６２】
・エスケープ状態８１４。デフレーマは受信したバイトに対してエスケープバイト（“０ｘ０７”）が検知されたときにエスケープ状態に入る。この状態で、エスケープバイトは除去され、後続するバイトは “０ｘ２０”で排他的論理和演算することによってアンエスケープされる。その後デフレーマは処理状態に戻る。
【００６３】
・ヘッダ状態８１６。デフレーマは、（１）フラグバイト（“０ｘ７ｅ”）が受信された場合、または（２）ＲＬＰパケット全体がデフレーマに書き込まれた場合（これは、dwrite_en信号上でdwrite_doneインジケータを受信することにより示される。）にヘッダ状態に入る。上述したように、デフレーマ出力バッファ内の直近のヘッダは、フラグバイトが受信されるか、dwrite_doneコマンドが受信されるときに更新される。デフレーマは関連づけられたＰＰＰパケットに対してヘッダワードのfcs_pass、PPP_end、およびPPP_lengthフィールドをセットして、ヘッダワードをデフレーマ出力バッファに書き込む。実施形態では、デフレーマは更新されたヘッダワードを書き出すために１クロックサイクルごとにヘッダ状態にある。フラグバイトが検知された場合、デフレーマは処理状態に戻る。一方、dwrite_doneインジケータが受信された場合、デフレーマは待機状態に戻る。
【００６４】
図６Ａを再び参照すると、入力インタフェースユニット６１０の内部では、ＲＬＰパケットが一度に１ワードずつマルチプレクサ６１３に書き込まれる。それぞれ受信されたワードに関する４（までの）バイトは、引き続く処理の間、マルチプレクサ６１３から一度に１バイトずつ供給される。選択されたバイト（curr_byteと示される）は、カウンタ６１５からのdbyte_selコントロールにより決定され、ラッチ６１４によりラッチされる。カウンタ６１５には、各ＲＬＰパケットの開始時（すなわち、ＲＬＰパケットの書き込みがdwrite_startコマンドにより初期化されるとき）に、初期値がロードされる。初期値は、ＲＬＰバッファ内の最初の有効なバイトに対するstart_offset値である（図５ＢのＲＬＰ１に対しては２）。その後、受信されたワードの各バイトが最終的に選択されるようにカウンタ６１５は各クロックサイクルについて１ずつインクリメントする。しかし、処理されたＰＰＰパケットに対するヘッダワードがデフレーマ出力バッファに書き込まれるように、フラグバイトが検知されるとカウンタ６１５は一時的に休止する。これは、dwen０x信号でカウンタ６１５のイネーブル入力を駆動することにより達成される。ロジックユニット６１６はいつデフレーマへの書き込みが休止されるべきか（例えば、フラグバイトが処理されているとき）を示すdwait信号を供給する。
【００６５】
dwite_en信号は、ＲＬＰパケットがデフレーマに書き込まれている間中アサートされる。dwrite_en信号は２つの直列結合されたラッチ６１７ａおよび６１７ｂによりラッチされ、信号の遅延バージョンdewen1およびdwen2を提供する。これらは検知ユニット６２０と変換ユニット６３０でそれぞれ使用される。dwrite_enおよびdwen1信号はさらに、論理積ゲート６１８ａおよび６１８ｂによってそれぞれ反転PPP_done信号と論理積演算され、dwen0xおよびdwen1xを形成する。これらはデフレーマ４１０ｘ内のさまざまな回路エレメントをイネーブルするために用いられる。
【００６６】
検知ユニット６２０の内部では、入力インタフェース回路６１０からの各バイト（prev_byteと示される）がラッチ６２２によりラッチされ、さらに比較ロジックユニット６２４ａ、６２４ｂ、６２４ｃに提供される。比較ロジックユニット６２４ａ、６２４ｂ、および６２４ｃは必要な比較を行って、受信バイトがフラグバイトか、エスケープバイトか、または無効バイトか否かをそれぞれ決定し、これらのバイトが検知されるたびにアサートされる信号を提供する。無効バイトは、サポートされている特定のプロトコルまたは、構成によって定義されてもよい。例えば、データ値“０ｘ７ｅ”は“０ｘ７ｅ  ０ｘ７ｅ”として送信され、ここで２番目の“０ｘ７ｅ”は無効とみなされる。ユニット６２４ａ、６２４ｂ、および６２４ｃからの信号はラッチ６２６ａ、６２６ｂ、および６２６ｃによってラッチされて、PPP_done、PPP_esc、およびinvalid_byte信号をそれぞれ提供する。その後ゲート６２７はこれら３つの信号をdwen2信号とともに論理積演算し、dvalid_byte信号を提供する。この信号は受信バイトが有効である（すなわち、フラグ、エスケープ、または無効バイトではない）と検知されるたびにアサートされる。
【００６７】
変換ユニット６３０の内部では、検知ユニット６２０から受信された各バイト（new_byteと示される）は排他的論理和ゲート６３１によって排他的論理和演算され、バイトをアンエスケープする。受信バイトおよび排他的論理和演算されたバイトはマルチプレクサ６３２に提供される。このマルチプレクサ６３２は、デフレーマがエスケープ状態にある場合には排他的論理和演算されたバイトを提供し、そうでなければ受信バイトを提供する。エスケープバイトの検知（つまりPPP_escがアサートされている）を受けるとエスケープ状態に入り、エスケープ状態はescape_state信号がアサートされることによって示される。マルチプレクサ６３２からの出力バイト（buf_byteとして示される）は、３つの直列結合されたラッチ６３３ａ、６３３ｂおよび６３３ｃに提供され、これらはバイト／ワード変換を実行するために用いられる。ＦＣＳ発生器４１６もマルチプレクサ６３２からの出力を受信し、それぞれ完全なＰＰＰパケットを検査するために用いられるＦＣＳ値を発生する。ヘッダ発生器６３４は、デフレーマによって受信される各新規ＰＰＰパケット用およびデフレーマ出力バッファの開始用のヘッダワードを発生する。
【００６８】
図６Ｂは、出力インタフェースユニット６４０の一実施形態の図である。バッファインタフェースユニット６４０の内部において、ヘッダ発生器６３４からヘッダワードが、およびラッチ６３３ａないし６３３ｃからデフレーム化ワードがマルチプレクサ６４２に供給され、マルチプレクサ６４２はデフレーマがヘッダ状態である場合はヘッダワードを、そうでない場合はデフレーム化ワードを供給する。フラグバイトの検知（つまり、PPP_doneがデアサートされている）を受けるとヘッダ状態に入り、ヘッダ状態はheader_state信号がアサートされることによって示される。そして、マルチプレクサ６４２からの出力ワードはデフレーマ出力バッファに書き込まれる。
【００６９】
バッファインタフェースユニット６４０はさらにアドレス発生器６５０とコントロール信号発生器６６０とを備え、これらはデフレーマ出力バッファにデフレーム化ＰＰＰパケットデータを書き込むためのアドレスおよびコントロール信号をそれぞれ発生するために用いられる。アドレス発生器６５０は、デフレーマ出力バッファに書き込まれた有効なバイトの数をカウントするカウンタ６５２を備える。カウンタ６５２には、load_en信号がアサートされるたびにload_valueがロードされる。ある実施形態では、デフレーマリセットまたは新しいＲＬＰパケットが（dwrite_startがアサートされることで示されるように）デフレーマに書き込まれることによりload_en信号がアサートされた場合は、load_value“０ｘ０４”がロードされ、デフレーマがヘッダ状態にあるためにload_en信号がアサートされている場合は、header_addrのload_value +“０ｘ０４”がロードされる。“０ｘ０４”のload_valueをカウンタ６５２にロードすることにより、デフレーマ出力バッファ内の最初のワードは、ヘッダワードのために予約される。フラグバイトの受信により示される各デフレーム化ＰＰＰパケットの最後に、デフレーマはＰＰＰパケットの最後の完全なまたは部分的なワードの出力バッファへの書き込みを強制する。
【００７０】
ヘッダアドレス発生器６５４は、次のヘッダワード（header_addr）に対するアドレスを発生する。次のＰＰＰパケットに対するheader_addrは、ヘッダワードがデフレーマ出力バッファ内の次のワードで記憶されるように、カウンタ６５２からのカウント値に基づいて発生される。発生器６４５は、マルチプレクサ６５６の１つの入力へheader_addrを供給し、カウンタ６５２へload_valueを供給する。（２つのＬＳＢを除く）カウンタ６５２の出力は、デフレーマ出力バッファに対するデフレーム化データアドレスとして用いられ、マルチプレクサ６５６の別の入力に供給される。その後マルチプレクサ６５６は、デフレーマ出力バッファにヘッダワードが書き込まれている場合はヘッダアドレスを供給し、デフレーム化ワードが書き込まれている場合はデータアドレスを供給する。信号発生器６６０はdobuffer_we信号を供給し、この信号は、（１）完全なワードが（例えば４番目の有効バイトごとに）デフレーマ出力バッファに書き込まれるべきで、（２）PPP_done信号がアサートされ、かつ未書き込みの残余バイトがあるときに部分的なワードがＰＰＰパケットの最後に書き込まれるべきである、または（３）ヘッダワードが書き込まれるべきであるたびにアサートされる。
【００７１】
図９Ａおよび図９Ｂは、図６Ａおよび図６Ｂに示す特定のデフレーマ設計により実行されるデフレーム化動作についてのいくつかのイベントに関するタイミング図である。ＲＬＰパケットは、時間Ｔ0で開始して一度に１つずつワードでデフレーマに書き込まれ、各ワードには４バイトまで含まれる。各受信されたワードに対して、dbyte_selコントロールは、処理のためにワードの各バイトを順に選択する。
【００７２】
図９Ａは、フラグバイトに対する処理を示す。時間Ｔ1において新しいＰＰＰパケットの開始を示すフラグバイト（“０ｘ７ｅ”）が検知されると、デフレーマへのＲＬＰデータの書き込みを一時的に休止するためにdwait信号がアサートされる（すなわちロジックハイにされる）。時間Ｔ2において、先のＰＰＰパケットに対する処理の完了を表示するためにPPP_done信号がアサートされ、有効でないバイト（すなわちフラグバイト）の受信を示すためにdvalid_byte信号がデアサートされ、さらにデフレーマ出力バッファに先のＰＰＰパケットの最後の部分的なワードの書き込みを強制するためにdobuffer_we信号がアサートされ、さらに次のＰＰＰパケットに対するヘッダワードが発生される。時間Ｔ3において、デフレーマはヘッダ状態に入り、ヘッダワードがデフレーマ出力バッファに書き込まれる。時間Ｔ4においては、デフレーマは処理状態に戻り、次のＰＰＰパケットの処理が始まり、dvalid_byte信号がアサートされ、dobuffer_we信号がデアサートされる。
【００７３】
図９Ｂは、エスケープバイトに対する処理を示す。時間Ｔ1において、受信されたワードの最後のバイト（例えば、dbyte_sel＝“１１”）が選択されると、メインコントローラが処理を続けられるようにdwait信号がデアサートされる。時間Ｔ2において、エスケープバイトの検知を示すためにPPP_esc信号がアサートされ、有効でないバイト（すなわち、エスケープバイト）の受信を示すためにdvalid_byte信号がデアサートされ、この有効でないバイトは除去される。時間Ｔ3において、デフレーマはエスケープ状態に入り、エスケープバイトに続く次のバイト（“０ｘ５６”）は“０ｘ２０”と排他的論理和演算されて、エスケープされたバイト（“０ｘ７６”）が提供され、dvalid_byte信号がアサートされる。時間Ｔ4において、デフレーマは処理状態に戻り、ＰＰＰパケットの処理が引き続き行われ、４つの有効バイト“０ｘ１２”、“０ｘ３４”、“０ｘ７６”、および“０ｘ７８”をデフレーマ出力バッファに書き込むためにdbuffer_we信号がアサートされる。
【００７４】
（ＨＤＬＣフレーム化）  
フレーム化動作において、フレーマにはフレーム化すべきデータが供給され、フレーム化タスクを実行し、フレーム化ＰＰＰパケットを生成する。各フレーム化ＰＰＰパケットは、図３Ａに示されるように、フラグ、アドレス、コントロール、プロトコル、情報、パディング、およびＦＣＳフィールドを含む。ある実施形態では、フレーマは各フレーム化ＰＰＰパケットに対して次の１組のタスクを実行する。
【００７５】
・フレーム化ＰＰＰパケットの開始にフラグバイトを挿入する。  
・“０ｘ７ｅ”の各バイトを“０ｘ７ｄ  ０ｘ５ｅ”の２バイトに置換する。  
・“０ｘ７ｄ”の各バイトを“０ｘ７ｄ  ０ｘ５ｄ”の２バイトに置換する。  
・ＡＣＣＭがこのように構成される場合、“０ｘ００”から“０ｘ１ｆ”までの各バイトを、そのバイトが後続するエスケープバイト（“０ｘ７ｄ”）で置換する。  
・ＰＰＰパケットに対するＦＣＳ値を発生させ、挿入する。  
・フレーム化ＰＰＰパケットをフレーマ出力バッファに記憶させる。
【００７６】
ある実施形態では、フレーム化すべきデータ（例えば、ＲＬＰパケットデータ）は、書き込み動作中にフレーマに供給される。その後フレーマは、フラグバイトを挿入し、定義されたＡＣＣＭに基づいて何らかの特定の特性を除去することにより、フレーム化ＰＰＰパケットを提供する。
【００７７】
図３Ａを再び参照すると、フレーマはフィールド３１４ないし３２２で構成されるＰＰＰパケットデータを受信する。フレーマは、フィールド３１２に関するフラグバイトを挿入し、フィールド３２４に関するＦＣＳ値を挿入し、フィールド３１２ないし３２４で構成されるフレーム化ＰＰＰパケットを提供する。フレーム化ＰＰＰパケットはフレーマ出力バッファに記憶される。
【００７８】
図１０は、図４のフレーマ４２０の特定の実施形態であるフレーマ４２０ｘのブロック図である。フレーマ４２０ｘは、状態コントロールユニット４２２および、フレーミングロジックユニット４２４を備え、さらに、入力インタフェースユニット１０１０、デコーディングユニット１０２０、変換ユニット１０３０、および出力インタフェースユニット１０４０を備える。これらのユニットの簡単な説明は以下に記述され、さらに詳細な記述も引き続き提供される。
【００７９】
入力インタフェースユニット１０１０はフレーム化すべきデータを受信し、信号をコントロールし、一度に１バイトずつデコーディングユニット１０２０へ受信データを供給する。デコーディングユニット１０２０は、受信データ内の特別なバイトを検知し、いつそのようなそれぞれのバイトが検知されたかという表示を与える。変換ユニット１０３０は受信データをフレーム化するための処理を実行し、この処理には、フラグおよびエスケープバイトの挿入、特別なバイトのエスケーピング、および各フレーム化ＰＰＰパケットに対するＦＣＳ値の発生および挿入が含まれる。出力インタフェースユニット１０４０はフレーム化ＰＰＰパケットデータを受信して、このデータをフレーマ出力バッファに供給する。さらに、出力インタフェースユニット１０４０はアドレス発生器およびコントロール信号発生器を備え、これらは出力バッファにデータを書き込むためにアドレスおよびコントロール信号をそれぞれ発生するために用いられる。
【００８０】
図１１は、フレーム化を実行するためのプロセス１１００の一実施形態のフローチャートである。プロセス１１００は、フレーム化すべきデータをフレーマへ送信するステップ（ブロック１１１０）、およびデータを処理してフレーム化ＰＰＰパケットを供給するステップ（ブロック１１２０）を含む。ある実施形態では、フレーム化すべきデータはＲＬＰバッファから（例えば、ワイヤレスリンクを介して受信された通信から）供給される。これらのステップは、フレーマ内の異なるハードウェア回路によって同時に実行されてもよい。フレーマは各新規データセッションの開始時にリセットされる（ステップ１１０８）。
【００８１】
各フレーム化動作において、フレーム化すべき最初の部分的なワードのヘッドバイトをＲＬＰバッファからフレーマに書き込むために、まず、ワード境界に達するまでバイト送信が行われる（ステップ１１１２）。そして、ＲＬＰバッファ内のワード全体をフレーマに書き込むために、ワード書き込みが行われる（ステップ１１１４）。その後、ＲＬＰパケットがワード境界で終了していない場合、最後の部分的なワードのテールバイトをフレーマに書き込むためにバイト送信が実行される（ステップ１１１６）。また、各ＰＰＰパケットにおいて、フラグバイトとＦＣＳ値とを挿入するためのコマンドがフレーマに供給される（ステップ１１１８）。ＲＬＰバッファのすべての内容がフレーマに書き込まれてしまうと、次のＲＬＰパケットのフレーム化のための書き込み動作がＲＬＰバッファの初めに開始が行われるように、fwrite_doneインジケータがフレーマに供給される。
【００８２】
フレーマは、バイトおよびワード送信から受信された各バイトを検査および処理する（ステップ１１２２）。フレーマは指示されるたびにフラグバイトを挿入し、必要に応じてエスケープバイトを挿入し、およびＡＣＣＭコントロールビットで定義されているそれぞれの特別なバイト（例えば、“０ｘ００”から“０ｘ１ｆ”）を“エスケープ”する。また、フレーマは各フレーム化ＰＰＰパケットに対するＦＣＳ値を発生し、指示されたときにＦＣＳ値を挿入する（ステップ１１２４）。fwrite_doneインジケータにより示されるように、受信データの処理が完了したら、フレーマはフレーマ出力バッファ内に記憶されたフレーム化ＰＰＰパケットの数を表す値をframer_lengthレジスタに記憶させる（ステップ１１２６）。また、何らかのフレーム化ＰＰＰパケットバイトがフレーマ出力バッファの限界の外側のアドレスに書き込まれた場合には、フレーマはframer_errorレジスタをアサートしてもよい（ステップ１１２８）。
【００８３】
図１２は、フレーマ４２０ｘについての状態に関する一実施形態の状態図である。実施形態では、任意の所定の瞬間にフレーマが６つの起こりうる状態、待機状態１２１０、処理状態１２１２、フラグ状態１２１４、エスケープ状態１２１６、ＦＣＳ状態１２１８、およびFCS_escape状態１２２０のうちの１つの状態になる。
【００８４】
・待機状態１２１０。フレーマはまず、リセットされると待機状態で開始する。フレーマは、フレーム化すべきデータをフレーマに書き込むための書き込みが開始される前、および書き込みが完了した後にもこの状態である。この状態にある間は、フレーマはフレーマ出力バッファに書き込まないが、すでに出力バッファに記憶されているデータは読み取ることができる。
【００８５】
・処理状態１２１２。フレーマは、データをフレーマに書き込むための書き込みが行われている間は処理状態にある。フレーマは各受信バイトを処理し、各ワードが利用できるようにフレーム化データを連続的にフレーマ出力バッファに書き込む。受信バイトをエスケープする必要があれば、フレーマはエスケープされたバイト（すなわち、ビット５反転された受信バイト）が後続するエスケープバイト（“０ｘ７ｄ”）を供給する。
【００８６】
・フラグ状態１２１４。flag_cmdが受信されると、フレーマはフラグ状態に入る。この状態で、フレーマは次のＰＰＰパケットのためのフラグバイトを生成する。フレーマは、フラグバイトを供給するために１サイクル間この状態にとどまり、その後処理状態に戻る。
【００８７】
・エスケープ状態１２１６。フレーマはエスケープする必要のあるバイトが受信されるたびにエスケープ状態に入る。そのようなバイトに対して、フレーマは、まだ処理状態にある間にエスケープバイト（“０ｘ７ｄ”）を生成し、その後、エスケープされたバイトを提供するためにエスケープ状態に入る。フレーマはエスケープされたバイトを処理するために１サイクルの間エスケープ状態にとどまり、その後処理状態に戻る。
【００８８】
・ＦＣＳ状態１２１８。フレーマはfcs_cmdを受信したときにＦＣＳ状態に入る。この状態では、フレーマは、ＰＰＰパケットの終わりにＦＣＳ値を追加して、この値をフレーマ出力バッファに書き込む。ＦＣＳ値がエスケープされる必要のある任意のバイトを含む場合は、フレーマはそのようなバイトを処理するためにFCS_escape状態に入る。
【００８９】
・FCS_escape状態１２２０。ＦＣＳ値がエスケープされる必要のあるバイトを含むときは必ず、フレーマはFCS_escape状態に入る。フレーマはエスケープ状態でそのようなそれぞれのバイトに対して同一の処理を実行する。しかしながら、追加のＦＣＳバイトを処理する必要がある場合は、フレーマはその後ＦＣＳ状態に戻る。
【００９０】
図１０を再び参照すると、入力インタフェースユニット１０１０の内部では、フレーム化すべきデータが一度に１ワードずつマルチプレクサ１０１３に書き込まれる。１つの“ノーマルな”バイトは、２サイクルで処理されるエスケープする必要がある特別なバイトを除いて１クロックサイクルで処理されるので、ワード内のバイトの数と各バイトの値にしたがって、（４バイトまでの）ワードは１ないし８サイクルの任意の間、マルチプレクサ入力で保持される。そして、各受信ワードに対する４（までの）バイトは、その後の処理のためにマルチプレクサ１０１３から一度に１バイトずつ提供される。選択されたバイト（curr_byteと示される）は、コントローラ１０１５からのfbyte_selコントロールにより決定され、ラッチ１０１４によりラッチされる。カウンタ１０１５は、フレーマにより受信および処理されたバイトの数をカウントし、受信バイトがエスケープされる必要のある場合には、（１クロックサイクルの間）一時的に休止する。カウンタ１０１５は、図６Ａのカウンタ６１５と同様に構成される。ロジックユニット１０１６は、（例えば、エスケープされる必要のあるバイトが受信されるたびに）いつフレーマへの書き込みを休止すべきかを示すため、fwait信号を供給する。
【００９１】
fwrite_en信号は、フレーム化すべきデータがフレーマに書き込まれている間中アサートされる。fwrite_en信号は、２つの直列結合されたラッチ１０１７ａおよび１０１７ｂによりラッチされ、信号の遅延バージョンfwen1およびfwen2を供給する。これらの信号は、検知ユニット１０２０と変換ユニット１０３０でそれぞれ用いられる。
【００９２】
検知ユニット１０２０の内部では、入力インタフェースユニット１０１０からの各バイト（prev_byteと示される）がラッチ１０２２によりラッチされ、さらにマルチプレクサ１０２３の１つの入力に供給される。マルチプレクサ１０２３はさらに、もう一つの入力でＦＣＳ値を受信し、フレーマがＦＣＳ状態にあればＦＣＳバイトを供給し、そうでなければデータバイトを供給する。ＡＣＣＭユニット１０２４は、あるバイトがエスケープされるべきかどうかを示すコントロール信号を供給する。そして、検知ロジック１０２５は、ＡＣＣＭユニット１０２４からのコントロール信号に基づいて、エスケープされる必要がある受信バイトかどうかを決定し、この状態を示すfcs_escape信号を供給する。この信号は、escape信号を提供するためにラッチ１０２６によりラッチされる。
【００９３】
状態コントロールユニット４２２は、入力インタフェースユニット１０１０からfwen2信号、検知ユニット１０２０からfcs_escape信号およびescape信号、並びに（例えば、メインコントローラ２３０から）fcs_cmd、flag_cmd、およびdone_cmdを受信する。そして、状態コントロールユニット４２２は、受信バイトが有効であると検知されるときは必ずアサートされるfvalid_byte信号、フレーマがＦＣＳ状態にあるか否かを表示するfcs_state信号、および適切な出力バイトを供給するために用いられるout_selコントロール信号を提供する。
【００９４】
変換ユニット１０３０の内部では、検知ユニット１０２０から受信された各バイト（new_byteと示される）は、バイトをアンエスケープするために排他的論理和ゲート１０３１ａにより排他的論理和がとられる。同様に、ＦＣＳ発生器４２６からの各ＦＣＳバイトも、バイトをアンエスケープするために排他的論理和ゲート１０３１ｂにより排他的論理和がとられる。受信データバイト、排他的論理和ゲート１０３１ａおよび１０３１ｂからのそれぞれの排他的論理和データおよびＦＣＳバイト、ＦＣＳバイト、エスケープバイト（“０ｘ７ｄ”）、およびフラグバイト（“０ｘ７ｅ”）は、マルチプレクサ１０３２の６つの入力に供給される。その後マルチプレクサ１０３２は、out_selに基づいて状態コントロールユニット４２２から、入力バイトの１つを出力バイト（buf_byteと示される）として提供する。buf_byteは３つの直列結合されたラッチ１０３３ａ、１０３３ｂ、および１０３３ｃに提供され、これらのラッチはバイトからワードへの変換を実行するために用いられる。ＦＣＳ発生器４２６もマルチプレクサ１０３２からの出力を受信して、各フレーム化ＰＰＰパケットに追加されるＦＣＳ値を発生する。
【００９５】
出力インタフェースユニット１０４０の内部では、ラッチ１０３３ａないし１０３３ｃからのワードがfobuffer_dataとしてフレーマ出力バッファに供給される。また、バッファインタフェースユニット１０４０は、カウンタ１０５０およびコントロール信号発生器１０６０を備え、それぞれフレーム化ＰＰＰパケットをフレーマ出力バッファに書き込むためのアドレスおよびコントロール信号を供給するために用いられる。カウンタ１０５０はフレーマ出力バッファに書き込まれたバイト数をカウントする。実施形態では、カウンタ１０５０は、ソフトウェアコマンドの受信を受けたシステムスタートアップ時、または空の出力バッファへの書き込み動作開始時にリセットされる。信号発生器１０６０は、ワードがフレーマ出力バッファへ書き込まれるたびにアサートされるfobuffer_we信号を供給し、この書き込みは一般的には４番目ごとのバイトであるが、フレーム化ＰＰＰパケットに対して書き込まれるべき最後の部分的なワードについては、より短い場合もある。
【００９６】
図１３は、図１０に示した特定のフレーマ設計により実行されるフレーム化動作におけるいくつかのイベントのタイミング図である。フレーム化すべきデータは、４バイトまで含まれる各ワードでもって、時間Ｔ0から開始して一度に１つずつ、ワードでフレーマに書き込まれる。各受信ワードに対して、fbyte_selコントロール信号が処理のためにワードの各バイトを順番に選択する。
【００９７】
時間Ｔ1でエスケープされる必要があるバイト（“０ｃ７ｅ”）が検知されると、フレーマへのデータの書き込みを一時的に休止するためにfwait信号がアサートされる。時間Ｔ2では、エスケープされる必要があるバイトの検知を表示するためにescape信号がアサートされ、出力バイトとしてエスケープバイト（“０ｃ７ｄ”）が供給される。時間Ｔ3では、フレーマはエスケープ状態に入り、フレーマを値（“０ｘ２０”）と排他的論理和演算することにより受信バイト（“０ｘ７ｅ”）はエスケープされ、エスケープされたバイト（“０ｘ５ｅ”）は出力バイトとして提供される。時間Ｔ4では、フレーマは処理状態に戻って受信バイトの処理を継続する。
【００９８】
図１４は、デフレーマまたはフレーマ出力バッファからデータを読み込むために使用可能な出力バッファインタフェースユニット４１８ｘの一実施形態の図である。バッファインタフェースユニット４１８ｘは、図４のバッファインタフェースユニット４１８および４２８のそれぞれに対して用いることができるものの、以下ではバッファインタフェースユニット４１８について説明する。インタフェースユニット４１８の内部では、レジスタ１４１２はデフレーマ出力バッファから取り込まれたワードの一時的な記憶に用いられ、カウンタ１４１４はバッファに対するアドレスを発生するために用いられる。論理和ゲートはrd_buffer信号およびdone_cmd信号を（例えば、メインコントローラ２３０から）受信し、バッファ出力可能な（dobuf_oe）信号を供給する。dobuf_oe信号は、（１）rd_buffer信号がアサートされることによって示される出力バッファの読み込みが可能である場合、または（２）done_cmd信号がアサートされることによって示されるフレーム化すべきデータの書き込みが完了した場合に、アサートされる。dobuf_oe信号はさらに、カウンタ１４１４のインクリメントを可能にするためにも用いられる。
【００９９】
（フレームチェックシーケンス発生器）  
デフレーム化とフレーム化動作の両方について、ＦＣＳ発生器はデフレーム化またはフレーム化されるそれぞれ完全なＰＰＰパケットに対するＦＣＳ値を発生するために使用される。ＦＣＳ値はパケットが正確に、または誤って受信されたかどうかを検査するために用いられる。ＣＲＣのようなＦＣＳ発生器によりさまざまなエラー検知コード化スキームが実現されうる。
【０１００】
図１５Ａは、ＲＦＣ１６６２により定義される多項式ｘ16＋ｘ12＋ｘ5＋ｘを実行するビットワイズＣＲＣ発生器１５００の一実施形態の図である。ＣＲＣ発生器１５００は、直列に結合された１６個の１ビットラッチ、１５１２ａないし１５１２ｐを備える。modulo-2加算器１５１４ａは、ラッチ１５１２ｅと１５１２ｆとの間に、modulo-2加算器１５１４ｂは、ラッチ１５１２ｌと１５１２ｍとの間に挿入され、modulo-2加算器１５１４ｃはラッチ１５１２ｐの出力に結合される。加算器１５１４ｃは、ＣＲＣ発生中にＰＰＰパケットに関するデータを一度に１ビットずつ受信し、ＣＲＣ値がラッチ１５１２から読み出されている間は０ビットを受信する。スイッチ１５１６ａないし１５１６ｃは、ＣＲＣ発生中はアップポジションであり、ＣＲＣ値が読み出されている間はダウンポジションである。
【０１０１】
図１５Ｂは多項式ｘ16＋ｘ12＋ｘ5＋ｘを実行するバイトワイズＣＲＣ発生器１５２０の一実施形態の図である。ＣＲＣ発生器１５２０は、各クロックサイクルでデータのバイトを受信し、１クロックサイクル内でその内部状態を更新することができる。ＣＲＣ発生器１５２０は、８つの１ビットＣＲＣ発生器１５２２ａないし１５２２ｈ、および環状に直列連結された８ビットラッチ１５２４を備える。各１ビットＣＲＣ発生器１５２２は、前の発生器（またはラッチ）からの１６ビット出力とデータバイトの個々のビットとを受信し、受信データに基づいてその状態を更新し、次の発生器（またはラッチ）に１６ビット出力を提供する。ＰＰＰパケットに対するすべてのバイトがＣＲＣエンコード化された後に、そのパケットに対するＣＲＣ値をラッチ１５２４から読み取ることができる。
【０１０２】
図１５Ｃは、図１５Ｂの１ビットＣＲＣ発生器１５２２ａないし１５２２ｈのそれぞれに用いることのできる１ビットＣＲＣ発生器１５２２ｘの一実施形態の図である。ＣＲＣ発生器１５２２ｘは、前のステージからの１６ビット入力およびＣＲＣエンコード化されるべきデータバイトの１ビットを受信する。１６ビット入力の１５下位ビット（ＬＳＢ）は２で乗算され、マルチプレクサ１５３２の１つの入力と、１６ビット加算器１５３４とに供給される。加算器１５３４は受信した１６ビット値に“０ｂ０００１００００００１００００１”（または、多項式ｘ16＋ｘ12＋ｘ5＋ｘでは“０ｘ１０２１”）を加算し、その結果をマルチプレクサ１５３２の他方の入力に供給する。１６ビット入力の最上位ビット（ＭＳＢ）は、modulo-2加算器１５３６によりデータビットとmodulo-2加算され、その結果として得られるビットｃｘは、マルチプレクサ１５３２に提供されて、入力の１つを選択するために使用される。マルチプレクサ１５３２の出力は、１ビットＣＲＣ発生器１５２２ｘの１６ビット出力を有する。
【０１０３】
図１５Ｄは１ビットＣＲＣ発生器１５２２ｙの一実施形態の図であり、これも図１５Ｂの１ビットＣＲＣ発生器１５２２ａないし１５２２ｈのそれぞれに用いることができる。ＣＲＣ発生器１５２２ｙもまた、前のステージからの１６ビット入力およびＣＲＣエンコード化されるべきデータバイトの１ビットを受信する。１６ビット入力のＭＳＢはmodulo-2加算器１５４６によりデータビットとmodulo-2加算され、その結果として得られるビットｃｘは論理積ゲート１５４４に供給される。論理積ゲート１５４４はまた“０ｘ１０２１”も受信し、ｃｘビットがロジックハイであれば“０ｘ１０２１”を提供し、ｃｘビットがロジックローであれば０を提供する。１６ビット入力の１５ＬＳＢは２で乗算され、１６ビット加算器１５４２により論理積ゲート１５４４からの１６ビット出力と加算され、加算器１５４２からの１６ビット出力は、１ビットＣＲＣ発生器１５２２ｙの１６ビット出力を有する。
【０１０４】
図１５Ｂないし１５Ｄに示されるバイトワイズＣＲＣ設計は、任意のビット数に対してマルチビットＣＲＣ発生を実行するために修正されてもよい。一般的に、１ビットＣＲＣ発生器１５２２の間を通過するビット数は実現される多項式の次数により決定され、ステージの数は同時にＣＲＣエンコード化されるビット数によって決定される。マルチビットＣＲＣ発生器は、ワイヤレス通信システムおよびデータネットワークのような任意の高データレートアプリケーションにおいて好都合に使用できる。
【０１０５】
ＣＲＣ（またはＦＣＳ）値も、技術的に知られているようなルックアップテーブルに基づいて発生できる。
【０１０６】
上述された実施形態では、デフレーム化複数バイトのワードがデフレーマおよびフレーマに書き込まれた場合であっても、各受信バイトに対してデフレーム化およびフレーム化が行われる。他の実施形態では、デフレーム化およびフレーム化が一度にすべてのワードで実行されてもよく、これによりデフレーム化およびフレーム化時間を短縮することができる。
【０１０７】
ここで記述されたＨＤＬＣアクセラレータはワイヤレス通信デバイス（例えば、端末、セルラ電話機、ハンドセットなど）に対して好都合に使用できる。ＨＤＬＣアクセラレータは、他の通信デバイスや電気ユニット（例えば、ネットワーク装置）で使用されてもよい。
【０１０８】
ここで記述されたＨＤＬＣアクセラレータは、さまざまな手段によって構成できる。例えば、ＨＤＬＣアクセラレータ（すなわち、デフレーマ、フレーマ、またはその両方）は、１つ以上の特定用途向け集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、デジタル信号処理デバイス（ＤＳＰＤ）、プログラマブルロジックデバイス（ＰＬＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、ここに記述された機能を実現するように設計された他の電気ユニット、またはそれらの組み合わせによって構成されてもよい。
【０１０９】
参照のため、および特定のセクションを設ける助けとするために、表題がここに含まれている。これらの表題は、そこに記載される概念の範囲に限定することを意図するものではなく、これらの概念は明細書全体を通して別のセクションに適用することができる。
【０１１０】
開示された実施形態についての以上の説明は当業者が本発明を作成しあるいは使用することができるように提供されている。これらの実施形態に対するさまざまな修正は当業者にとって容易に想到でき、ここに定義される一般原理は本発明の精神または範囲を逸脱することなく他の実施形態に適用することができる。したがって、本発明はここに示された実施形態に限定されることを意図するものではなく、ここに開示された原理と新規な特徴とに一致する最も広い範囲に一致すべきである。
【図面の簡単な説明】
【０１１１】
【図１】図１は、音声およびデータ通信をサポート可能な通信システムの一実施形態の図である。
【図２】図２は、アクセス端末の特定の実施形態のブロック図である。
【図３Ａ】図３Ａは、インターネット標準規格ＲＦＣ１６６２で記述されたＰＰＰ  ＨＤＬＣ状のフレーム構造に基づいたフレームフォーマットを示した図である。
【図３Ｂ】図３Ｂは、ＲＬＰパケットのシーケンスとＰＰＰパケットのシーケンスとの関係を示した図である。
【図４】図４は、ＰＰＰパケットのためのフレーム化およびデフレーム化を実行するために用いられる、ＨＤＬＣアクセラレータのブロック図である。
【図５Ａ】図５Ａは、デフレーマ出力バッファ用記憶フォーマットの図である。
【図５Ｂ】図５Ｂは、デフレーム化バイトアラインメントと、ＲＬＰバッファとデフレーマ出力バッファの関係とを図示した図である
【図６Ａ】図６Ａは、デフレーマの一実施形態のブロック図である。
【図６Ｂ】図６Ｂは、デフレーマの一実施形態のブロック図である。
【図７】図７は、デフレーム化を実行するための処理のフローチャートである。
【図８】図８は、デフレーマに関する状態の一実施形態の状態図である。
【図９Ａ】図９Ａは、データをデフレーム化する際のいくつかのイベントに関するタイミング図である。
【図９Ｂ】図９Ｂは、データをデフレーム化する際のいくつかのイベントに関するタイミング図である。
【図１０】図１０は、フレーマの一実施形態のブロック図である。
【図１１】図１１は、フレーム化を実行するための処理のフローチャートである。
【図１２】図１２は、フレーマに関する状態の一実施形態の状態図である。
【図１３】図１３は、データをフレーム化する際のいくつかのイベントに関するタイミング図である。
【図１４】図１４は、出力バッファインタフェースユニットの一実施形態の図である。
【図１５Ａ】図１５Ａは、ビットワイズＣＲＣ発生器の一実施形態の図である。
【図１５Ｂ】図１５Ｂは、バイトワイズＣＲＣ発生器の一実施形態の図である。
【図１５Ｃ】図１５Ｃは、バイトワイズＣＲＣ発生器の一実施形態の図である。
【図１５Ｄ】図１５Ｄは、バイトワイズＣＲＣ発生器の一実施形態の図である。
【図１】
2006507704.tif 000003
【図２】
2006507704.tif 000004
【図３Ａ】
2006507704.tif 000005
【図３Ｂ】
2006507704.tif 000006
【図４】
2006507704.tif 000007
【図５Ａ】
2006507704.tif 000008
【図５Ｂ】
2006507704.tif 000009
【図６Ａ】
2006507704.tif 000010
【図６Ｂ】
2006507704.tif 000011
【図７】
2006507704.tif 000012
【図８】
2006507704.tif 000013
【図９Ａ】
2006507704.tif 000014
【図９Ｂ】
2006507704.tif 000015
【図１０】
2006507704.tif 000016
【図１１】
2006507704.tif 000017
【図１２】
2006507704.tif 000018
【図１３】
2006507704.tif 000019
【図１４】
2006507704.tif 000020
【図１５Ａ】
2006507704.tif 000021
【図１５Ｂ】
2006507704.tif 000022
【図１５Ｃ】
2006507704.tif 000023
【図１５Ｄ】
2006507704.tif 000024
【国際調査報告】
2006507704.tif 000025
2006507704.tif 000026
2006507704.tif 000027
2006507704.tif 000028
2006507704.tif 000029