JP5185395B2 - チャネルｍａｐメッセージの既知情報を用いたチャネルデコーディング - Google Patents

チャネルｍａｐメッセージの既知情報を用いたチャネルデコーディング Download PDF

Info

Publication number
JP5185395B2
JP5185395B2 JP2010542222A JP2010542222A JP5185395B2 JP 5185395 B2 JP5185395 B2 JP 5185395B2 JP 2010542222 A JP2010542222 A JP 2010542222A JP 2010542222 A JP2010542222 A JP 2010542222A JP 5185395 B2 JP5185395 B2 JP 5185395B2
Authority
JP
Japan
Prior art keywords
message
hypothesis
map
bits
bit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2010542222A
Other languages
English (en)
Other versions
JP2011509633A (ja
Inventor
リー、チュン・ウォ
パーク、ジョン・ヒョン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2011509633A publication Critical patent/JP2011509633A/ja
Application granted granted Critical
Publication of JP5185395B2 publication Critical patent/JP5185395B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/37—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35
    • H03M13/39—Sequence estimation, i.e. using statistical methods for the reconstruction of the original codes
    • H03M13/41—Sequence estimation, i.e. using statistical methods for the reconstruction of the original codes using the Viterbi algorithm or Viterbi processors
    • H03M13/4107—Sequence estimation, i.e. using statistical methods for the reconstruction of the original codes using the Viterbi algorithm or Viterbi processors implementing add, compare, select [ACS] operations
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/37—Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35
    • H03M13/39—Sequence estimation, i.e. using statistical methods for the reconstruction of the original codes
    • H03M13/3994—Sequence estimation, i.e. using statistical methods for the reconstruction of the original codes using state pinning or decision forcing, i.e. the decoded sequence is forced through a particular trellis state or a particular set of trellis states or a particular decoded symbol
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/65—Purpose and implementation aspects
    • H03M13/6522—Intended application, e.g. transmission or communication standard
    • H03M13/6544—IEEE 802.16 (WIMAX and broadband wireless access)

Landscapes

  • Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Error Detection And Correction (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Description

分野
本発明のある実施形態は、一般に、無線通信に関し、特に、デコーディング無線伝送に関する。
関連技術の説明
ブロードバンド・インターネット・アクセス及びストリーミング・メディア・アプリケーションのような無線通信サービス中の急成長は、より高いデータレートへの需要増加に結びつく。直交周波数分割多重（ＯＦＤＭ）及び直交周波数分割多元接続（ＯＦＤＭＡ）のような多重化スキームの進歩は、次世代無線通信システムにとって重要である。これは、そのようなスキームが従来の単一キャリア変調スキームを超えて、変調効率、スペクトル効率、柔軟性(例えば区別されるサービス品質を許可すること)および強いマルチパスイミュニティを含む多くの利点を備えることができるという事実による。
ＯＦＤＭとＯＦＤＭＡのシステムは、しばしば畳み込み符号器を利用し、誤り訂正を供給する。畳み込みコードを使用して、ｍ／ｎがコーディング速度である場合、データのｍ−ビット・ストリングはｎビットに転換される。ビタビデコーダのようなデコーダは、受信機で使用され、受信されたエンコードされたｎビットをデコードし、オリジナルのｍ−ビット・シーケンスを回復する。たとえ、１以上のエンコードされたｎ−ビットが正確に受信されず、それにより、ビットエラー率における低下が結果として生じても、このスキームは、オリジナルのｍ−ビット・シーケンスが正確にデコードされることをしばしば可能にする。
しかしながら、無線サービスの信頼性および性能要求が常に増加するとともに、連続的にビットエラー率を縮小することに対する進行中の要求がある。
概要
ある実施形態は、ＭＡＰメッセージに対する無線通信伝送のエンコードされたデータビットをデコーディングするための方法を提供する。前記方法は、一般に、ＭＡＰメッセージの内容及び関連する伝送のパラメータのうちの少なくとも一つに関する既知（アプリオリ）情報に基づいてエンコードされたデータビットのビット値のセットを指定する仮説を生成すること、検討から、指定されたビット値と不一致のデコードされたビットのセットを除去すること、及び、出力として、前記仮説によって指定されたビット値と一致するデコードされたビットを選択することによって伝送をデコーディングすること、を含む。
ある実施形態は、メッセージに対する無線伝送を受信し、エンコードされたビットのセットを生成するための受信機フロントエンド、仮説エンジン、デコーダを、一般的に含む無線通信のための受信機を提供する。前記仮説エンジンは、前記メッセージに関する既知情報に基づいてエンコードされたデータビットのビット値のセットをそれぞれ指定する、１以上の仮説を生成するために形成される。前記デコーダは、検討から、前記仮説によって指定された前記ビット値と一致しないデコードされたビットのセットを除去し、出力として、前記仮説の一つによって指定されたビット値と一致するデコードされたビットを選択することによって前記エンコードされたビットをデコードするために形成される。
ある実施形態は、無線通信のための装置を提供する。前記装置は、一般的に、メッセージに対する無線伝送を受信し、エンコードされたビットのセットを生成する手段と、前記メッセージに関する既知情報に基づいて前記エンコードされたデータビットのビット値のセットをそれぞれ指定する、１以上の仮説を生成する手段と、検討から、前記仮説によって指定されたビット値と一致しないデコードされたビットのセットを除去し、出力として、前記仮説の一つによって指定されたビット値と一致するデコードされたビットを選択することによってエンコードされたビットをデコードする手段とを含む。
ある実施形態は、ＭＡＰメッセージに対する無線伝送を受信し、エンコードされたビットのセットを生成するための受信機フロントエンドと、仮説エンジンと、デコーダとを一般的に含む移動装置を提供する。前記仮説エンジンは、前記ＭＡＰメッセージの内容又は過去にデコードされたＭＡＰメッセージとのうちの少なくとも一つに関する既知情報に基づいて前記エンコードされたデータビットのビット値のセットをそれぞれ指定する、１以上の仮説を生成するために形成される。前記デコーダは、検討から、前記仮説によって指定された前記ビット値と一致しないデコードされたビットのセットを除去し、出力として、前記仮説の一つによって指定されたビット値と一致するデコードされたビットを選択することによって前記エンコードされたビットをデコードするために形成される。
本発明の上記に示された特徴が詳細に理解されるために、上記で簡潔に要約された発明のより特別の記述は、ある実施形態への参照によって得られえてもよく、いくらかは添付された図面の中で例示される。しかしながら、添付された図面は、本発明のある実施形態のみを例示し、それゆえにその範囲を制限して考慮されるべきではなく、本発明は他の等しく有効な実施形態を認めてもよいことは、注目される。
図１は、本発明のある実施形態に係る無線システムを例示する。 図２は、本発明のある実施形態に係る無線装置のブロック図である。 図３は、本発明のある実施形態に係る受信機のブロック図及び送信機のブロック図を例示する。 図４Ａ及び４Ｂは、本発明のある実施形態に係る既知デコーダのブロック図を例示する。 図５は、本発明のある実施形態に係るトレリスダイヤグラムの状態移行の一例を例示する。 図６は、本発明のある実施形態に係る既知デコーディングのための例オペレーションのフロー図である。 図６Ａは、本発明のある実施形態に係る既知デコーディングのためのオペレーション例のフロー図である。 図７は、図５のデコーダを既知情報ビットの値の例で例示する。 図８は、本発明のある実施形態にしたがって、トレリスダイヤグラムの例を、デコーディングパスのフルセット及び既知情報ビットに基づいて減少されたデコーディングパスのセットで例示する。 図９は、本発明のある実施形態に係る、既知情報の最初のセットを検討するデコーディングの結果例を例示する。 図１０は、本発明のある実施形態に係る、既知情報の最初のセットを検討するデコーディングの結果例を例示する。 図１１は、本発明のある実施形態に係る既知デコーダ及び仮説エンジンを持つ受信機のブロック図である。 図１２は、本発明のある実施形態に係る仮説エンジンのブロック図である。 図１３は、既知情報ビットに基づいてデコーディング仮説を生成するために使用されてもよいメッセージ・フォーマット例を例示する。 図１４Ａは、既知情報ビットに基づく異なるデコーディング仮説を例示する。 図１４Ｂは、既知情報ビットに基づく異なるデコーディング仮説を例示する。 図１４Ｃは、既知情報ビットに基づく異なるデコーディング仮説を例示する。 図１４Ｄは、既知情報ビットに基づく異なるデコーディング仮説を例示する。 図１４Ｅは、既知情報ビットに基づく異なるデコーディング仮説を例示する。 図１４Ｆは、既知情報ビットに基づく異なるデコーディング仮説を例示する。 図１４Ｇは、既知情報ビットに基づく異なるデコーディング仮説を例示する。 図１５は、本発明のある実施形態に係る、異なるＡＰＩ仮説に対するデコーディングの結果例を例示する。 図１６は、本発明のある実施形態に係る、異なるＡＰＩ仮説に対するデコーディングの結果例を例示する。 図１７は、本発明のある実施形態に係る、異なるＡＰＩ仮説に対するデコーディングの結果例を例示する。 図１８は、並列に多数のデコーディング仮説を評価することが可能な受信機例を例示する。 図１９は、並列に多数のデコーディング仮説を評価するためのオペレーション例を例示する。 図２０は、並列に多数のデコーディング仮説を評価することが可能なデコーダ例を例示する。 図２１は、シーケンシャルな方法で多数のデコーディング仮説を評価することが可能な受信機例を例示する。 図２２は、シーケンシャルな方法で多数のデコーディング仮説を評価するためのオペレーション例を例示する。 図２３は、シーケンシャルな方法で多数のデコーディング仮説を評価することが可能なデコーダ例を例示する。 図２４は、反復する方法で多数のデコーディング仮説を評価することが可能な受信機例を例示する。 図２５は、反復する方法で多数のデコーディング仮説を評価するためのオペレーション例を例示する。 図２６は、ＡＰＩデコーディングが可能な受信機例を、ＤＬ−ＭＡＰメッセージに基づく仮説で例示する。 図２７は、ＡＰＩデコーディングに対するオペレーション例を、ＤＬ−ＭＡＰメッセージに基づく仮説で例示する。 ノーマルＤＬ−ＭＡＰメッセージ・フォーマットの例を例示する。 図２９は、ノーマルＤＬ−ＭＡＰメッセージのＡＰＩデコーディングのためのオペレーション例を例示する。 図３０は、圧縮されたＤＬ-ＭＡＰメッセージ・フォーマットの例を例示する。 図３１は、並列にノーマルＤＬ−ＭＡＰ及び圧縮されたＤＬ−ＭＡＰ仮説を評価することが可能なデコーダ例を例示する。 図３２は、並列にノーマルＤＬ−ＭＡＰ及び圧縮されたＤＬ−ＭＡＰ仮説を評価するためのオペレーション例を例示する。 図３３は、ＡＰＩデコーディングが可能な受信機例を、ＵＬ−ＭＡＰメッセージに基づく仮説で例示する。 図３４は、ＵＬ−ＭＡＰメッセージ・フォーマットの例を例示する。 図３５は、ＵＬ−ＭＡＰメッセージのＡＰＩデコーディングのためのオペレーション例を例示する。 図３６は、基地局でＡＰＩデコーディングが可能な受信機例を、ＢＷ−ＲＥＱ及びＲＮＧ−ＲＥＱメッセージに関する仮説で例示する。 図３７は、ＲＮＧ−ＲＥＱメッセージ・フォーマットの例を例示する。 図３８は、ＢＷ−ＲＥＱメッセージ・フォーマットの例を例示する。 図３９は、ＢＷ−ＲＥＱ及びＲＮＧ−ＲＥＱメッセージのＡＰＩデコーディングのためのオペレーション例を例示する。
詳細な説明
本発明は、一般に、伝送に関する既知情報を使用してエンコードされた無線伝送を畳み込み的にデコーディングするための技術及び装置を提供する。既知情報は、既知情報と一致していないビットを含んでいるものの除去により、可能性のあるデコードされたビットストリームの母集団を有効に縮小するために使用されてもよい。間違いデータを導くこれら「既知の間違いの」パスの除去によって、デコードされたビットの誤り率はいくつかの状況で改善されるだろう。
ここで使用されるように、既知情報の用語は、一般に、既知又は仮定の原因から必ず関連する結果まで進行する情報のような、前もって知られた情報を指す。より非常に詳しく以下に記述されるように、伝送に関連する既知情報の例は、あるメッセージにおける既知情報ビットを含む。標準された又は知られたビット、あるいは過去の伝送におけるそれらの値に基づいた予測可能な値によって指定されるように、そのような既知情報ビットの例は、値を備えた予備ビットを含む。これらの既知ビット位置及びビット値(ここで「ＡＰＩ値」と呼ばれる)は、ＡＰＩ値と対照的な値に対応するパスの除外により、デコーディング性能を改善するために、デコーディング処理の中で使用されることができる。
典型的な無線通信方式
本開示の方法及び装置は広帯域無線通信システムで利用されてもよい。
用語「広帯域無線」は、無線、ボイス、インターネット、および／または、与えられたエリアに関するデータネットワークアクセスを提供する技術を指す。
マイクロ波アクセス用の世界的なインタオペラビリティを表わすＷｉＭＡＸは、長い距離に関して高スループットの広帯域の接続を供給する標準ベースの広帯域無線技術である。今日、ＷｉＭＡＸの２つの主要アプリケーションがある:固定ＷｉＭＡＸ及びモバイルＷｉＭＡＸ。例えば、固定ＷｉＭＡＸアプリケーションは、家及びビジネスへの広帯域アクセスが可能な、ポイント−トゥ−マルチポイントである。モバイルＷｉＭＡＸは、広帯域の速度で携帯ネットワークの十分な移動度を提示する。
モバイルＷｉＭＡＸは、ＯＦＤＭ（直交周波数分割多重）及びＯＦＤＭＡ（直交周波数分割多元接続）技術に基づいている。ＯＦＤＭは、様々な高データレート通信システムにおいて広い採用を最近見つけたディジタル・マルチキャリア変調方式である。ＯＦＤＭで、伝送ビットストリームは、多数のより低いレートサブストリームに分割される。各サブストリームは、多数の直交サブキャリアのうちの1つで変調され、複数の並列サブチャンネルのうちの1つの上に送られる。ＯＦＤＭＡは、ユーザーが異なるタイムスロット中のサブキャリヤを割り当てられる多元接続技術である。ＯＦＤＭＡは、広く変わるアプリケーション、データ率、及びサービス品質必要条件を多くのユーザーに融通することができる柔軟な多元接続技術である。
無線インターネットおよび通信の急成長は、無線通信サービスの分野において高データレートの増加する需要に結びついた。ＯＦＤＡ／ＯＦＤＭＡシステムは、今日最も有望な研究領域のうちの1つ、及び無線通信の次世代の重要な技術と見なされる。これは、ＯＦＤＡ／ＯＦＤＭＡ変調スキームが、従来の単一のキャリア変調スキームを超えて、変調効率、スペクトル効率、柔軟性、及び強いマルチパスイミュニティのような多くの利点を備えることができるという事実による。
ＩＥＥＥ８０２．１６ｘは、固定又は移動広帯域無線アクセス（ＢＷＡ）システムに対するエアー・インターフェースを定義する新興の標準組織である。ＩＥＥＥ８０２．１６ｘは、固定ＢＷＡシステムのために、2004年5月に「IEEE P802.16-REVd/D5-2004」を承認し、移動ＢＷＡシステムのために、2005年10月に「IEEE P802.16e/D12 2005年10月」を公表した。それらの２つの標準は、４つの異なる物理層（ＰＨＹ）及び１つのメディアアクセス制御（ＭＡＣ）層を定義した。４つの物理層のＯＦＤＭ及びＯＦＤＭＡ物理層は、それぞれ固定及び移動ＢＷＡエリアで最もポピュラーである。
環境の例
図1は、本発明の実施形態が基地局１１０から移動局１２０への無線信号を処理するために利用される場合のシステム例を例示する。基地局１１０は、携帯電話タワーのような固定位置で導入される無線通信ステーションとすることができる。移動局１２０は、セルラーハンドセット又は他タイプの移動装置のような、基地局１１０と通信可能な任意の適切なタイプのユーザー設備（ＵＥ）とすることができる。
基地接続（ＯＦＤＭＡ）局１１０及び移動局１２０は、１本以上のアンテナ１１２，１２２をそれそれ使用し、及び、直交周波数分割多重（ＯＦＤＭ）及び直交周波数分割多元接続（ＯＦＤＭＡ）のような変調スキームを使う任意の適切な無線通信技術を使用し、通信を行うことができる。
いくつかの実施形態について、基地局と移動局の間の通信は、標準のＩＥＥＥ８０２．１６(マイクロ波アクセス-ＷｉＭＡＸのための世界的なインタオペラビリティ)及び802.20(移動広帯域無線アクセス−ＭＢＷＡ)ファミリーのような、様々なInstitute of Electrical and Electronics Engineers（ＩＥＥＥ）標準に部分的又は完全に準拠するとしてもよい。
いくつかのアプリケーションにおいて、移動局１２０はリバースリンクを超えて、基地局１２０にデータを送信すると同時に、基地局１１０は、フォワードリンクと一般的に呼ばれるものを超えて移動局にデータを送信するとしてもよい。
より非常に詳しく下に記述されるように、既知情報の異なるタイプは、順方向および逆のリンク伝送に利用可能とすることができる。この既知情報は、基地局１１０と移動局１２０との間のあるメッセージのタイミング及び内容に関する情報を含むとしてもよく、知られている伝送における１ビット以上の値に帰着していてもよい。
ここに記述された技術は、基地局１１０、移動局１２０，又はは両方で実行されたデコーディングで利用されるとしてもよい。より非常に詳しく下に記述されるように、基地局１１０と１２０との間で伝送されるメッセージの異なるタイプに関する既知情報は、伝送において、特別のビット位置の値を決定するために使用されてもよい。
図２は、送信された信号を受信することが可能な受信機のある実施形態のコンポーネント例のブロック図を例示する。１以上のアンテナ２０２は送信機から送信された信号を受信し、それらを無線周波数（ＲＦ）フロントエンド２１０に送ってもよい。ＲＦフロントエンド２１０は、送信された信号を受信し、それらを、自動利得制御（ＡＧＣ）、高速フーリエ変換（ＦＦＴ）ブロック、チャネル推定器、およびキャリア対干渉及び雑音比（ＣＩＮＲ）推定器などのような、デジタル信号処理に対して準備するための任意の適切な回路を含むとしてもよい。
その後、ＲＦフロントエンド２１０からの信号は、任意のサブキャリヤ・デアロケーション、信号デマッピングなどに適切な任意の回路を含むとしてもよい信号処理ブロック２２０に、送られるとしてもよい。信号処理ブロック２２０の出力は、エンコードされたビットのセットである。エンコードされたビットは、対応する伝送に関する既知情報を使用して、エンコードされたビットをデコードするチャンネルデコーダ２３０に、転送される。
既知デコーディング
図３は、本発明の実施形態に係る既知情報に基づいたデコーダオペレーションを実行可能なデコーダ２３０のブロック図である。
例示された例は、例としてビタビデコーディングスキームを示すと同時に、ここに示された既知デコーディング技術は、ターボ・コーディング/デコーディング、低密度パリティチェック（ＬＤＰＣ）コーディング/デコーディング、ＲＳコーディング/デコーディング、ＢＣＨコーディング／デコーディング、及び様々な他のスキームのような、他のタイプのデコーディングスキームに適用されてもよい。
システマティック符号を利用するスキームの場合には、コードされたビットがシステマティックビット(コーディング前の情報)及びパリティビット(エンコードに起因する冗長ビット)を含んでいてもよい。ＡＰＩデコーディングスキームは、システマティックビットに適用されてもよい。換言すれば、ＡＰＩビット値は、使用される特別のシステマティックコードに基づいたシステマティックビットの既知の値を含んでいてもよい。システマティックコードを利用するシステムにＡＰＩを適用するために、受信されたデータのビットは、デコーダのフロントエンドでＡＰＩビット値（既知/／予測された）と取り替えられてもよい。このように、成功するデコーディングの確率は、ＡＰＩをシステマティックデコーダに使用して増加されてもよい。
デコーダ２３０は、ブランチメトリック部２３２、加算・比較・選択（ＡＣＳ）ロジック２３４、トレースバック（ＴＢ）部２３６を含み、「ソフト（又はハード）」受信／エンコード化ビット２４０のセットからデコードされたビット２４６のセットを生成する。ブランチメトリック部は、一般に、コード・アルファベットにおける受信されたシンボル（ビットのセット）と複数のシンボルとの間の正規化された距離を表す、ブランチメトリックデータを演算する機能である。ＡＣＳ部２３４は、一般に、ブランチメトリックデータをコンパイルし、デコーディングパス（Ｋの制約長を仮定する、２Ｋ−１パス）に対するメトリックを生成し、最適なものとして、これらのデコーディングパスのうちの１つを選択する。これらの選択の結果は、記憶された決定からパスを回復する、トレースバック部２３６のメモリに書き込まれる。その後、デコードされたビットのセットは、回復されたパスの移行に基づいて生成されることができる。
デコーダコンポーネントの１以上は、既知情報と一致しないビット値に対応するデコーディングパスの選択を防ぐために、APIビット２５０のセットによって制御されてもよい。換言すれば、ＡＰＩビット２５０は、デコードされているビットのシーケンスの連続におけるあるビット位置で知られる、特別の値(「０」又は「１」)を示すために十分な情報を含むとしてもよい。ＡＰＩビット２５０で指定される値とは別の値を持つどのようなビットストリングであっても、有効なデコードされたビットストリングではない。したがって、デコーダは、パスセレクションの間に、検討から、これらの無効ビットストリングに対応するデコーディングパスを除去してもよい。
図４に例示されるように、いくつかの実施形態について、ＡＣＳ部２３２４は、無効のデコードされたビットストリングに対応するデコーディングパスを除外するためにＡＰＩビット２５０によって制御されるとしてもよい。ＡＣＳオペレーションの間、ＡＰＩビット２５０は、ＡＰＩ値と一致しないエンコードされたビット値に対応する特別のデコーディングパス移行を縮小するために使用されてもよい。
ＡＰＩビット２５０は、一般に、既知情報及びさらにそれらのビット値の状態に基づいて、知られている(あるいは予測可能な)ビット値を持つデコードされたビットストリングにおける１以上のビットを指定するために十分な情報を含む。この情報が伝えられる実際のフォーマットは、異なる実施形態に応じて、及び実際の実装計画にしたがって変わってもよい。
例えば、いくつかの実施形態について、ＡＰＩビット２５０は、ビット位置２５２の指定、ビット値２５４、及び、オプションで、ＡＰＩマスクビット２５６である、３タイプの情報を含んでいてもよい:ビット値２５４がエンコードされたビットの実際の既知の値(「０」又は「１」)を提供している間に、ビット位置２５２は、既知の値を持つビット位置 (エンコードされたシーケンス内の)の指定を提供してもよい。詳細に下で説明される図７は、このフォーマットにしたがって、ビット位置、ビット値、及びマスクビットに対する値の例の例示を供給する。
ＡＰＩビット位置２５２は、トレリス構造における既知／予測されたエンコード化ビットの位置に対応するビット位置を識別してもよい。ある実施形態にしたがって、ＡＰＩビット位置２５２は、他のすべてのビット位置が「未知である」と考えられている間に、既知の値を持つビット位置を明示的に識別してもよい。このように、ビット値２５４における「０」又は「１」の対応ビット値は、トレリス構造における有効な移行を識別し、かつ効果的に無効の移行に関するデコーディングパスを除去するために使用されてもよい。
例えば、図５は、トレリス構造の状態移行の例を３ビットの状態で例示する。例示された例は、１／２及びＫ＝４(３ビット、Ｋ−１、状態レジスタで)のコーディングレートを仮定する。破線矢印は「１」入力ビットに対応する状態移行を示すと同時に、実線矢印は「０」入力ビットに対応する状態移行を示す。
ＡＰＩデコーディングにしたがって、既知の値と一致しない入力ビットに対応する状態移行は検討から除去され、それによって、最終セレクションからのこれらの移行を含むどんなパスも有効に除去する。
例として、もしこの状態のための既知のＡＰＩビット値が「０」ならば、実線を備えた状態移行は評価されるだろう。一方、破線を備えた状態移行は算出される必要はない。なぜなら、それらは選択のために検討されるべきでない無効のパスの一部であるためである。上記のように、これらの移行は、最悪ケースの値に状態メトリックの値を設定することにより、次の移行で有効に除去されてもよい。選択から無効のパスを除去することによりビットエラー率を縮小することに加えて、ＡＰＩビット値に基づく移行の数の除去は、さらにＡＣＳ部で計算の数を減らすことができる。
ある実施形態について、マスク機能は、ＡＰＩマスクビット２５６を利用することによって実現され、ＡＰＩビット値が無視されるべきビット位置を識別する。例えば、標準が変わり、その結果以前に既知のビット値を未知にする場合、そのようなマスク機能は有用で、柔軟性を加えることができる。マスクビットの設定は、効率的にそのような変更を提供するために単純な機構を提供することができる。マスク機能は、さらに、もはや既知の値を持っていないビット位置の識別を削除するためにＡＰＩビット位置２５２を操作することにより実現される。それにより、代替で、ビットマスク値における値を変更すること、及び／又は、すべてにおいてビットマスク値の必要を除去することを供給してもよい。
図６は、ＡＰＩデコーディングのためのオペレーション６００の例を例示する。オペレーションは、既知情報に基づいて仮説を生成することにより６０２で始まる。６０４で、仮説のＡＰＩビット値と一致しないビット値に帰着するデコーディングパスは、削除される。最後に、６０６で、デコーディングは、残りのパスのうちの1つの選択に基づいて行なわれる。
ここに使用されるように、仮説の用語は、一般に、例えば既知の値を持つビット位置を示し、それらのビットに対する値を特定する、ＡＰＩビットの特別のセットを指す。ある実施形態について、より非常に詳しく後述されるように、個別のロジック(ここでは「仮説エンジン」と呼ばれる)は、例えば、ＭＡＣプロセッサからのメッセージ情報に基づいて、１以上の仮説を生成するために提供されてもよい。
図７は、ＡＰＩデコーダに適用される６ビットストリームのための仮説の一例を例示する。例示される仮説は、ＡＰＩビット位置の値[１２３５]によって、ＡＰＩビット値が、デコーディングで使用されるために、ビット位置１，２，３，５に存在する、ことを示す。例示されたスキームにしたがって、対応するＡＰＩビット値[１０１１]は、これらの位置でビットに対するビット値が:ｂｉｔ１＝１、Ｂｉｔ２＝０、ｂｉｔ３＝１、及びｂｉｔ＝１である。ある実施形態について、［００００］のＡＰＩマスクビット値は、マスキング機能がビットのうちのいずれにも適用されないことを示すために使用されてもよい。他方では、ＡＰＩデコーディングからビットを除外すると、マスクビット位置５への［０００１］に例えばマスクビットをセットすることができ、この結果［１０１Ｘ］の有効ビット値が得られる。
もちろん、ＡＰＩマスク機能性は、ＡＰＩビット位置値を制御することにより、同様に実現されてもよい。例として、ビット位置５は、また、対応するＡＰＩビット値［１０１］を用いて、ビット位置値から５を取り除くことにより有効に生成され、結果として［１２３］のビット位置値が得られるとしてもよい。このスキームでは、ＡＰＩビット位置は、個別のマスク値データ構造を必要とすることなく。有効に生成されることができる。
代替スキームでは、ＡＰＩビット値及び対応するＡＰＩマスク値だけが、使用されてもよい。例として、デフォルトにより又はＡＰＩ位置値（例えば［１２３４５６］）におけるすべてのビット位置の明確な指定により、ビット・シーケンスにおけるすべての位置がＡＰＩデコーディングに対して使用されると、仮定されてもよい。いずれの場合も、ＡＰＩマスク値は、対応するＡＰＩビット値を持たないビット位置を指定するために使用されてもよい。例えば［０００１０１］のＡＰＩマスク値は、ビット位置４及び６に対応するＡＰＩビット値が無視されるべきであることを示す値「１」が使用されるとしてもよく、この結果［１０１Ｘ１Ｘ］が得られる。
図８は、図７に示される仮説のＡＰＩビット値がデコーディング中に検討されるデコーディングパスの数を減らすためにどのように適用されることができるかを例示する。上のダイアグラム８１０は、すべての入力ビットが未知と仮定する既存のデコーディングスキームにおいて検討されるであろうダイアグラムを通るすべての可能パスを示す。しかしながら、下のブロックダイアグラム８２０によって例示されるように、ＡＰＩデコーディングスキームは、既知のＡＰＩビット値を使用することに基づいて多くのパス移行を除去して、大幅に減少されたパス数をサーチする探索する。
ＡＰＩビット値に基づくパスの減少は、左から右までダイアグラム８２０を通過することで説明されてもよい。対応する移行に対する既知のＡＰＩ値は、トップを横切ってリストされる。第１の移行について、ビット値は、ゼロ入力ビットに対応する実線パス移行の除去という結果になる既知「１」である。これは、状態ノード１００ｂ，１０１ｂ，１１０ｂ及び１１１ｂへの移行という結果になる。
第２の移行は、破線パス遷移の除去という結果になる「０」の既知ビット値に対応する。これは状態ノード０１０ｂ及び０１１ｂへの移行という結果になる。第３の移行は、実線パス移行の除去という結果になる「１」の既知ビット値に対応する。これは、単一の状態ノード１０１ｂへの移行という結果になる。
しかしながら、第４の移行のビット値は、未知である。したがって、両方の可能移行パスが評価される。これは状態ノード０１０ｂ及び１１０ｂへの移行という結果になる。第５の移行は、実線パス移行の除去という結果になる「１」の既知のビット値に対応する。
これは、状態ノード１０１ｂ及び１１１ｂへの移行という結果になる。第６の移行のビット値は、再び未知である。したがって、両方の可能な移行パスが評価され、状態ノード１０１ｂから状態ノード０１０ｂ，１１０ｂへの移行、及び状態ノード１１１ｂから状態ノード０１１ｂ及び１１１ｂへの移行という結果になる。
これらの残りパスのためのブランチメトリックは、最適パスを選択し、デコードされたビットの対応するセットを生成するために、評価されることができる。無効ビットの連続に対応するデコーディングパスの除去によって、ビット/パケット誤り率は、よりノイズのある環境において期待されるより大きな改良と共に、ＡＰＩデコーディングを使用して改善されることができる。
図９は、ＩＥＥＥ８０２．１６ｅ標準におけるフレームコントロールヘッダ（ＦＣＨ）／ダウンリンクフレームプレフィックス（ＤＬＦＰ）メッセージをシミュレート・デコーディングするための、パケットエラー率（ＰＥＲ）、対、信号ノイズ比（ＳＮＲ）のグラフの一例である。このメッセージのタイプは、２４ビットの情報を含む。これらのうち、５ビットは標準につき０がセットされることになっている予備ビットである。シミュレートされた例において、これらの予備５ビットは、２４ビットストリングにおける対応する位置で「０」の既知のビット値を持つ既知情報として使用される。シミュレーションはさらに以下のような変調とコーディングを仮定する:ＱＰＳＫ、ＴＢＣＣ（ｒ＝１／２）、４の反復係数及び２のデュープリケーション（duplication）係数を持ち、受信側（ＲＸ）における反復最大比結合（ＭＲＣ）を仮定する。
例示されるように、ＡＰＩデコーディングスキームは、ＡＷＧＮ環境における従来のデコーディングスキームに関する改善されたパフォーマンスを示す。例えば、ＡＰＩデコーディングスキームは、従来のデコーディング（ＡＰＩの検討のない）と比較した場合に、ＡＷＧＮチャネルでＰＥＲ１０-2において約０．６ｄＢ0.6dBの利得にを示す。
図１０は、図９と同様のダイアグラムである。しかし、対応するシミュレーションは、受信側（ＲＸ）の反復最大比率結合（ＭＲＣ）とデュープリケーションとの両方を仮定する。例示されるように、この例において、ＡＰＩデコーディングスキームは、ＡＰＩデコーディングスキームなしと比較されるＡＷＧＮチャネルにおいて、ＰＥＲ１０-2において０．７５ｄＢ近くを示す。
仮説エンジン
上述されるように、ある実施形態については、仮説エンジンは、それぞれが、ＡＰＩデコーディングを実行において使用するＡＰＩビット値のセットを含む「仮説」を生成するために提供されてもよい。特別の実装に依存して、仮説エンジンは、一つの仮説、又は、ビットが既知の値でありそれらのビットの既知の値がなにであるかを分かっている異なっていてもよい多数の仮説を生成してもよい。例えば、与えられたシーケンスについて、有効ビットの組み合わせの制限された数だけがある場合、多数の仮説の評価は有用であろう。
図１１は、ＡＰＩデコーダ２３０及び仮説エンジン１１１０を含む受信機回路１１００を例示する。例示されるように、仮説エンジン１１１０は、メディアアクセス制御（ＭＡＣ）プロセッサ１１２０からのメッセージに関する情報を受信し、ＡＰＩデコーダ１１２０による使用のためにＡＰＩビット値（仮説）を生成する。ＡＰＩデコーダ２３０は、仮説エンジン１１１０によって供給されるＡＰＩビット値を使用して受信されたソフト（又はハード）ビットＲｓをデコードすることを開始する。ＡＰＩデコーダ２３０は、メッセージパーサ１１３０に配達される、デコードされたデータビットＲｄえお出力する。
もし、メッセージパーサ１１３０がデコードされたビットがメッセージの一種向けであることを検出した場合、メッセージは解析され、ＭＡＣ(メディアアクセス制御)プロセッサ１１２０に配達される。ＭＡＣプロセッサ１１２０は、プロトコルアナライザの一種として機能してもよい。プロトコルアナライザは、例えば、次の可能メッセージタイプは何か、及び、タイミングは何か決めるために受信されるデータを分析する。
例として、ＭＡＣプロセッサ１１２０は、最初の入力メッセージ(又はデータ)が、ダウンリンクプリアンブルによってフォローされる、ＦＣＨ／ＤＬＦＰメッセージになるだろうということを認識することができる。ある場合には、ＭＡＣプロセッサ１１２０は、例えば、コーディングレート、メッセージ長、又は他のあるパラメータを決定するために、前フレームからのいくつかの情報を使用してもよい。ＭＡＣプロセッサ１１２０は、特別のビット位置に対する既知のビット値(又は予測ビット値)を抽出し、ＡＰＩデコーダへ向けてのＡＰＩ情報を生成するためにそれを使用する仮説エンジン１１１０にこの情報を提供してもよい。
図１２は、ＭＡＣプロセッサ１１２０によって提供される既知情報及びメッセージ情報に基づいてデコーディング仮説を生成するために使用されてもよい仮説エンジン１１１０の例を例示する。例示されるように、仮説エンジンは、メッセージタイプの指示を受信し、メッセージタイプによって指示された対応メッセージを検索し、メッセージのフォーマットは、フォーマットロジック１２２０によって分析される。
ある実施形態について、固定された／既知のビット値(標準にしたがった既知の値への予備ビットセットのような)を備えたビット位置に加えて、仮説は、予測可能な情報で生成されてもよい。例として、ビット情報は、以前に受信されたメッセージ(例えば、コーディングタイプは、あるメッセージから次のものにおそらく変化しないだろう)からの値に基づいて、予測可能かもしれない。
したがって、分類ロジック１２３０は、固定情報、予測情報、可変情報の少なくとも３つのカテゴリーに、与えられたメッセージ中のビット情報を分類してもよい。固定(既知)情報は、一般に、それがいくつかの条件(例えば関連するメッセージのデコーディング結果をチェックした後)の下で知られている初期ステージ又はいくつかのビット値から１００％分かるように、固定される情報を指す。例えば、デコードされるデータの前に配置されることが知られるメッセージ又はデータのように、デコードされるデータに関連するメッセージのデコードされた結果は、分析され、ＡＰＩ情報は、分析された結果から抽出されるとしてもよい。
予測可能な情報は、それが１以上のビットのセットに対して、異なる候補値又はビット組み合わせを供給することができるように、ある条件あるいは仮定の下で、予測可能になりうる情報を含むとしてもよい。異なる候補値は、異なる仮説に含まれていてもよい。例えば、予測可能な情報は、ある条件あるいは仮定の下で予測可能なある情報、又は関連するメッセージのデコーディング結果をチェックした後に予測可能な情報を含んでいてもよい。
可変情報は、一般に、それがＡＰＩビット値(例えば、これらのビット位置に対するＡＰＩビット位置値は「０」にセットされてもよい)として一般に使用されないように、未知か、予測が難しすぎる情報を含む。情報ビットを分類した後に、仮説エンジンの仮説ＡＰＩおよび配達ロジック１２４０は、分類された情報を使用して、ＡＰＩビット値(仮説に対応する個々のセット)の１セット又は複数セットを生成してもよい。例えば、ロジック１２４０は、デコーダ２３０に出力されるために、ＡＰＩビット位置、ビット値、及びマスクストリングを構築してもよい。
ここに示されたＡＰＩデコーディングスキームは、メッセージの様々な異なるタイプに適用されてもよい。例えば、下記に述べられるように、ＡＰＩデコーディングは、（ＦＣＨ）ダウンリンクフレームプレフィックス（ＤＬＦＰ）メッセージ、ノーマルダウンリンクＭＡＰ（ＤＬ−ＭＡＰ）メッセージ、圧縮されたＤＬ−ＭＡＰメッセージ、アップリンクＭＡＰ（ＵＬ−ＭＡＰ）メッセージ、帯域幅リクエスト（ＢＷ−ＲＥＱ）メッセージ、初期レンジングリクエスト(ＩＲＮＧ−ＲＥＱ)メッセージ、などに適用されてもよい。
フレーム制御ヘッダ（ＦＣＨ）ダウンリンクフレームプレフィックス（ＤＬＦＰ）メッセージ１３００は、図１３に示されるように、固定、予測可能、可変として分類されてもよい情報の様々なビットのよい例、及び変数を提供する。ＦＣＨメッセージのフォーマット及び内容は、ＩＥＥＥ８０２．１６ｅ ＯＦＤＭＡ標準で定義される。ＤＬＦＰは、ＦＣＨチャネルの内容である。ＤＬＦＰは、各フレームの初めで伝送されたデータ構造であり、現フレームに関する情報を含み、ＦＣＨにマップされる。したがって、ＤＬＦＰの成功したデコーディングは、全体のフレームを処理するために非常に重要である。いくつかのビットの分類は、例えば、初期の取得状況からファーストメッセージフレームの検出までの移行の後に、時間とともに変わってもよい。
例として、ビットマップフィールド１３１０は、対応するメッセージグループがセグメントによって使用されるかどうか示す各ビット持つ、６ビットを含む。初期の取得状態では、これらのビットは未知である。しかしながら、初期のデコーディング及びメッセージセグメントの指定の後、少なくとも1つのビットは、指定されるだろう(例えば、第１のメッセージグループビットがＡＰＩビット＝「１ＸＸＸＸＸ」に使用されると仮定する)。さらに、ノーマルオペレーション状態において、移動局は、基地局が前フレームにおけるのと同じビットマップを送るとすると、６ビットのすべてを予測できる。
以前に記述されるように、予備フィールド１３２０及び１３２２のビットは、標準が変更されない限り、固定されたままだろう。対照的に、２ビットの反復タイプフィールド１３３０は、予測困難であり、フレームからフレームへ変化することができる。
３ビットのコーディングタイプフィールド１１３４０は、異なる方法で分類され、多くの異なる仮説を生成するために使用されてもよい。例えば、コーディングタイプにどんな条件も設けなかったところ、３ビットのフィールドは、変数として扱われることができるかもしれない。しかしながら、既知情報の使用でこれらのビットのうちのいくつかは、固定するように扱われてもよい。例えば、ＷｉＭａｘの現バージョンが、２つのタイプだけのコーディング、ＴＢＣＣ（０ｂ０００）及びＣＴＣ（０ｂ０１０）をサポートすることが知られている場合、第１及び第３のビットは、「０」(ＡＰＩビット＝「０ｂ０Ｘ０」)の既知のビット値として扱われてもよい。
８ビットの長さフィールド１３５０は、フレームからフレームに変わっていてもよいが、ビットのうちのいくつかは異なる方法で分類されてもよい。例として、長さフィールドに制限を課さないと、すべての８ビットは変数になるだろう。しかしながら、ほとんどの場合、ＤＬ−ＭＡＰの長さは２＾７未満であるだろうから、ＭＳＢは「０」(ＡＰＩビット＝「０ｂ０ＸＸＸＸＸＸＸ」)であると予測されてもよい。この予測が真実でないかもしれないとき、達成されるビット誤り率における改良は、異なる仮説を使用して再デコードしなければならない際に、どんなパフォーマンスペナルティーよりも重要かもしれない。より積極的な仮説は、また、例えば、長さが２＾６(ＡＰＩビット＝「０ｂ００ＸＸＸＸＸＸ」)又は２＾４(ＡＰＩビット=「０ｂ００００ＸＸＸＸ」)未満であると仮定して、同様の方法で生成されてもよい。
図１４Ａ−１４Ｇは、情報と可能な分類と上述の仮定に基づいて、ＦＣＨ／ＤＬＦＰメッセージに対する多数のＡＰＩデコーディング仮説の例を例示する。仮説は、既知のビット値を持つとして扱われるビットの数に基づいて、その仮説がどの程度「積極的か」を一般的に示す異なるレベル（Ｌ０−Ｌ６）を持つように示される。
図１４Ａをまず参照すると、Ｌ０仮説は、各フレームにおける最初のメッセージの場合のように、ＡＰＩビット値がない（仮説がない）場合に対応する。換言すると、メッセージがデコードされていないため、ＡＰＩ値を生成するために使用されてもよいメッセージ情報がない。図１４Ｂは、第１レベル（Ｌ１）仮説を、仮説において使用される予備ビット値だけで例示する。
図１４Ｃは、仮説において使用される予備ビット値に加えビットマップビット値（最初のフレームにおいて指定されるメッセージグループ）を含む、Ｌ２仮説を例示する。図１４Ｄは、Ｌ２仮説に関連し、前フレームにおいて使用されたビットマップビット値の残りを加えるＬ３仮説を例示する。
図１４Ｅは、Ｌ３仮説に関連し、サポートされるコーディングタイプＴＢＣＣ及びＣＴＣに共通のコーディングフィールドビット値を加えるＬ４仮説を例示する。図１４Ｆは、Ｌ４仮説に関連し、長さが２＾６未満であるとする仮定に基づいて、長さフィールドの上位の２ビットを加えるＬ５仮説を例示する。図１４Ｇは、Ｌ５仮説に関連し、長さが２＾４未満であるとする仮定に基づいて、長さフィールドのさらに２ビットを加えるＬ６仮説を例示する。
これらのそれぞれの仮説のビット値は、上記の方法において、誤ったデータに対応する多くのデコーディングパスを除去するために、ＡＰＩデコーダによって使用されてもよい。もちろん、図１４Ｂ−１４Ｇの中で示される仮説は単に典型的である。さらに、より多くの既知のビット値を含めて、例示された仮説が次第により積極的になっていると同時に、当業者は、他の仮説が、これらの例において示されるビット値の異なる組み合わせを使用して生成されてもよいことを認識するだろう。
上述されるように、これらの異なる仮説にしたがうＡＰＩビット値は、誤ったデータに対応するデコーディングパスを除去するために、ＡＰＩデコーダによって使用されてもよい。なぜなら、異なる仮説は異なるＡＰＩビット値を持つため、デコーディング性能は、仮説から仮説で変わってもよい。図１５−１７は、異なるチャネルに関する異なる仮説の間での性能変化を例示するグラフの例を示す。
図１５は、付加的ホワイトガウスノイズ（ＡＷＧＮ）チャネルにおける異なる仮説Ｌ０−Ｌ６に対するＡＰＩデコーディングのシミュレーション結果を示す。シミュレーションにおいて、仮説はすべて正確である(換言すれば、ＡＰＩビット値は実際のエンコードされたビット値と一致すると仮定されている)と仮定されている。
例示されるように、より多くのＡＰＩビットを備えた仮説は、よりよい性能(ビット誤り率が縮小される)を出す。図１６は、ＩＴＵ Ｐｅｄ−Ａ及びＰｅｄ−Ｂチャネルに対して異なる仮説を使用するＡＰＩデコーディングに対する、同様の結果を示す。図１７は、ＩＴＵ Ｖｅｈ−Ａ及びＶｅｈ−Ｂチャネルに対して異なる仮説を使用するＡＰＩデコーディングに対する、同様の結果を示す。
上記のものが本発明のある実施形態に導かれる間に、発明の他の及びさらなるある実施形態は、それの基礎的な範囲から外れずに工夫されてもよく、その範囲は、続く請求項によって決定される。
多数の仮説を処理する方法
上に議論されるように、仮説エンジンは、固定及び予測可能な既知情報に基づいてビット値の仮説を生成する。仮説エンジンは、異なるビット値の組み合わせを仮定することによって、Ｎｃの多数の仮説を生成するために予測可能な情報を使用してもよい。性能を向上させるために、多数の仮説を処理することは望ましいかもしれない。したがって、デコーダは、多数の伝えられた仮説を調査してもよい。ゆえに、処理された仮説の数は、伝えられた仮説、Ｎｃの数と等しいかもしれない。多数の処理された仮説があるが、最も正確な仮説だけが選択されてもよい。
ある実施形態において、受信されたメッセージは、巡回冗長検査（ＣＲＣ）フィールドを含んでいてもよい。ＣＲＣを欠くメッセージについては、選択基準はデコーディングの最終ステージで蓄積された可能性(あるいは蓄積された距離)に基づいてもよい。ＣＲＣがあるメッセージについては、選択基準は、ＣＲＣチェックの結果又は蓄積された可能性のいずれかに基づいてもよい。
多数の仮説を評価するために利用されてもよいいくつかの方法がある。これらの方法は並列、連続、及び反復する評価を含んでいてもよい。並列の評価方法を実現するために、複数のデコーダは、ＮｃのＡＰＩ仮説の１以上を処理する各デコーダで利用される。
対照的に、連続及び反復するデコーディング方法は、単一のデコーダを利用してもよく、一度に単一の仮説を処理する。連続の方法において、デコーダは、Ｎｃ長であるループにおけるすべての仮説を処理する一方で、反復の方法において、デコーダは、それが所定の選択基準しきい値を満たす一つの仮説を見つけるまで仮説の連続をを処理する。
ある実施形態では、仮説の数は、プロセッサの数を超過してもよい。そのような実施形態において、ハイブリッド法は、各プロセッサが並列に動作するために使用されてもよいが、各プロセッサは、連続の又は反復の方法において一つの仮説よりも多く評価する。
図１８は、並列のＡＰＩデコーダ１８３０と、多数の仮説を生成する仮説エンジン１８６０を含む受信機回路を例示する。
例示されるように、仮説エンジン１８６０は、ＭＡＣプロセッサから受信されたメッセージ情報に基づいて、それぞれＡＰＩ（１）からＡＰＩ（Ｎｃ）までのＡＰＩビット値の異なるセットを持つ、Ｎｃの異なる仮説を生成するとしてもよい。仮説エンジンは、例えば、ビット値を予測するために使用される異なる仮定に基づいて、多数の仮説を生成してもよい。上述されるように、仮説のうちのいくつかは、例えば、予測されるビット値の数に基づいて、他のものより積極的と考えられてもよい。
デコード１８３０は、異なる仮説の適用により並列に受信されたビットを複数回デコードすることで、異なる仮説のＡＰＩビット値を使用して、受信されたビットＲｓを事実上デコードする。多数の仮説を評価した後に、デコーダ１８３０は、選択基準のいくつかのタイプに基づいて最高とみなされた仮説を用いて得られたデコードされたデータビットＲDを出力するとしてもよい。
図１９は、並列に、多数の仮説の評価のためのオペレーション１９００の例を例示する。オペレーション１９００は、並列に配列された複数のＡＰＩデコーダ２０００を持つ並列のデコーダ１８３０の実施形態の例を例示する図２０に関して記述されてもよい。
オペレーションは、１９０２で、既知情報に基づいて複数の仮説の生成することにより、始まる。１９０４で、各仮説はデコーダ２０００のうちの1つに送られてもよい。図２０に例示されるように、各仮説は、受信されたビットＲsのデコーディングにおけるデコーダによって使用される上述の情報（例えばビット値、ビット位置、及び／又はビットマスク）のタイプを含むとしてもよい。
各デコーダは、ステップ１９０６及び１９０８で、ＡＰＩデコーディングを実行し、対応する仮説のＡＰＩビット値に基づいてデコーディングパスを除去し、残りのパスから選択を行い、デコードされたビットＲDを生成する。１９１０で、各デコーダは、例えば、デコードされたメッセージがＣＲＣを含まない場合において、最良の仮説を選択するために使用されてもよいクオリティメトリック（ＱＡ）を生成してもよい。もし、メッセージがＣＲＣを含む場合、個別のクオリティメトリックは生成されても、されなくてもよい。１９１２で、各デコーダからのデコーディング結果は比較され、ステップ１９１４で、最良の仮説を使用して得られた結果が選択される。
図２０に例示されるように、もし、デコードされたメッセージがＣＲＣを含む場合、デコーディング結果はＣＲＣロジック２０２０を用いたＣＲＣチェックを実行することにより比較されてもよい。ＣＲＣロジック２０２０は、整合するＣＲＣを持つデコードされた結果を備えた仮説を指定する出力（Ｓx）を生成してもよい。出力Ｓxは、対応するデコードされた結果を出力するために、マルチプレクサとして役割を果たす選択ロジック２０３０を制御するために使用されるとしてもよい。
ＣＲＣチェックの代わりとして(例えば、もしデコードされたメッセージがＣＲＣを持たない場合)、クオリティメトリックは、、最良の仮説を選択するために使用されてもよい。例えば、クオリティメトリックは、蓄積された距離又は可能性の値であってもよい。ＭＬデシジョンロジック２０１０は、最良のクオリティメトリック（例えば、最低の蓄積された距離又は最も高い可能性）を持ったデコードされた結果を用いて仮説を指定する出力（ＳY）を生成して、各デコーダからのクオリティメトリックを評価してもよい。出力（ＳY）は、対応するデコードされた結果を出力するために、選択ロジック２０３０を制御するために使用されるとしてもよい。
図２１は、連続するＡＰＩデコーダ２１３０及び多数の仮説を生成する仮説エンジン２１６０を含む受信機回路を例示する。
例示されるように、仮説エンジン２１６０は、ＮCの異なる仮説を生成し、デコーダ２１３０に対して連続する方法でこれらの仮説を出力する。例えば、例示されたように、仮説エンジン２１６０は、デコーダ２１３０に対して、ＡＰＩビット値、ＡＰＩ（ｃ）を出力してもよく、ここでｃ＝１からＮCである。
デコーダ２１３０は、異なる仮説を適用することによって連続に複数回受信されたビットをデコードして、結果として、異なる仮説のＡＰＩビット値を使用して受信されたビットＲsをデコードする。多数の仮説の評価の後に、デコーダ２１３０は、選択基準のあるタイプに基づいて最良とみなされた仮説を用いて得られるデコードされたデータビットＲDを出力してもよい。
図２２は、連続の方法における多数の仮説を評価するオペレーション２２００の例を例示する。オペレーション２２００は、図２３を用いて図示されてもよい。。図２３は、異なる仮説のＡＰＩビット値に基づいて、連続的に複数回、受信されたビットＲＳのセットをデコーディングするための単一のＡＰＩデコーダ２３００を持つ。
オペレーションは、２２０２で、既知情報に基づいて、複数の仮説の生成することにより、始まる。２２０４で、ビット値ＡＰＩ（ｃ）を持つ仮説のうちの１つが選択され、受信されたビットのデコーディングにおいて使用するために、デコーダ２１３０に送られる。
デコーダは、ステップ２２０６及び２２０８で、ＡＰＩデコーディング、ＡＰＩビット値に基づくデコーディングパスの除去、及びデコードされたビットＲDのセットを生成するために残りのパスからの選択２３３０を実行する。２２１０で、デコーダは、例えば、デコードされたメッセージがＣＲＣ２３２０を含まない場合において、最良の仮説を選択するために使用されもよいクオリティメトリック（ＱＡ）２３１０を生成するとしてもよい。上述されるように、もし、ＣＲＣを含む場合、個別のクオリティメトリックは、生成されても、されなくてもよい。２２１２で、デコーディング結果及びクオリティスコア（もし生成されていれば）は、後の評価のために、メモリ２３４０に記憶される。
２２１４で決定されるように、さらに仮説がある場合、オペレーション２２０４−２２１２は繰り返される。一旦、オペレーションが仮説ごとに実行されたならば、２２１６で、仮説の結果は比較され、２２１８で、最良の仮説を使用して得られた結果が選択される。
図２３に例示されるように、デコーディング結果ＲD（ｃ）及びクオリティメトリックＱＡ（ｃ）は、各仮説について、もし生成されていれば、メモリ２３４０から検索され、最良の仮説を決定するために評価されるとしてもよい。例示されるように、図２０に示されるのと同様の回路類は、ＣＲＣ（ＳX）、及び／又は、対応するデコードされた結果を出力する選択ロジックを制御するためのクオリティメトリック（ＳY）に基づいて、最良の仮説の指定を出力するために使用されてもよい。
図２４は、反復ＡＰＩデコーダ２４３０及び多数の仮説を生成する仮説エンジン２４６０を含む受信機回路を例示する。
図２１の仮説エンジン２１６０のように、仮説エンジン２４６０は、ＮCの異なる仮説を生成し、デコーダ２４３０に連続する方法でこれらの仮説を出力する。図２１のデコーダ２１３０のように、デコーダ２４３０は、異なる仮説を適用することによって連続に複数回受信されたビットをデコードして、結果として、異なる仮説のＡＰＩビット値ＡＰＩ（ｃ）を使用して受信されたビットＲsをデコードするために単一のデコーダ２４７０を利用するとしてもよい。
しかしながら、各々の可能な仮説を評価し、出力結果を比較するよりむしろ、デコーダ２４３０は、しきい値選択基準に対する各仮説の結果を比較してもよい。一旦、仮説が選択基準を満たす結果で評価されれば、対応するデコードされたデータビットはどの残りの仮説についても評価することなく出力されるとしてもよい。
図２５は、反復する方法で多数の仮説を評価するためにオペレーション２５００の例を例示する。オペレーション２５００は、例えば、図２４に示されるコンポーネントによって実行されてもよい。
オペレーションは、２５０２で、既知情報に基づいて複数の仮説を生成することにより、始まる。２５０４で、ビット値ＡＰＩ（ｃ）を持つ仮説の一つが選択され、受信されたビットのデコーディングにおいて使用するために、デコーダ２４３０に送られる。 デコーダは、ステップ２５０６及び２５０８で、ＡＰＩデコーディング、ＡＰＩビット値に基づくデコーディングパスの除去、及びデコードされたビットＲDのセットを生成するために残りのパスからの選択を実行する。
図２２のように、すべての仮説が評価され、結果が比較されるまで待つよりもむしろ、選択される仮説に対して得られる結果は、ステップ２５１２で、（ループの中で）評価される。例示されるように、デコーダ２４３０は、デコードされたビットのセットが選択基準を満たすか決定するためのロジック２４８０を含むとしてもよい。例えば、ロジック２４８０は、ＣＥＣチェック及び／又はクオリティメトリックと所定のしきい値との比較を実行してもよい。
もし、選択基準が満たされない場合（例えば、ＣＲＣチェックは整合しない又はクオリティメトリックはしきい値より下である）、オペレーション２５０４−２５１２は、異なる仮説を評価するために繰り返されてもよい。しかしながら、選択基準が満たされる場合、２５１４で、現在の仮説を使用して得られた結果が選択される。
異なる仮説がこの反復するアプローチにおいて評価される場合の順序は、変わってもよい。例えば、ある実施形態については、より積極的な仮説（より多くの既知／予測されたビット値を備える）は、積極的でない仮説の前に評価されてもよい。ある実施形態について、積極的でない仮説は、より積極的な仮説の前に評価されてもよい。ある実施形態について、ある他のタイプの基準は、仮説が評価に選ばれる順序を決定するために使用されてもよい。
当業者は、多数の仮説を評価するための様々な技術が変更されてもよく、ある場合には組み合わせられてもよいことを認識するだろう。例えば、先に記述されたように、並列でコーダより多くの仮説がある場合、並列及び連続する技術は、並列に複数の仮説を評価するために組み合わせられてもよい。
ＡＰＩ情報を抽出するための典型的なメッセージ
上述したように、ＡＰＩデコーダは、シーケンスに関する既知情報、フォーマット、及び／又はメッセージの各種タイプの内容を使用し、伝送されるメッセージのデコーディングにおいて、ビットエラー率を低減するためにビット値を決定及び／又は予測するとしてもよい。
例として、ＩＥＥＥ８０２．１６ｅ ＯＦＤＭＡ標準によれば、フレーム中の最初のデータ単位は、ノーマルＤＬ−ＭＡＰ又は圧縮されたＤＬ−ＭＡＰ及びＵＬ−ＭＡＰによって後続されるＦＣＨ(フレーム制御ヘッダ)である。フレーム制御ヘッダ（ＦＣＨ）メッセージ、ダウンリンクＭＡＰ（ＤＬ−ＭＡＰ）メッセージ、及びアップリンクＭＡＰ（ＵＬ−ＭＡＰ）メッセージは、既知のＡＰＩビット値を備えたデコーディング仮説を生成するために使用されてもよいメッセージの例である。
上述されるように、ＦＣＨメッセージは、典型的にはＭＡＰ長及びコーディング情報を含み、様々な仮定は、現在の標準、現在サポートされているコーディング、及びマップ長に関する仮定に基づいて、例えば、そのような情報の内容に関して作られてもよい。ＤＬ−ＭＡＰ及びＵＬ−ＭＡＰデータは、典型的には、サブチャンネル及びサブフレーム割り当て及びダウンリンクとアップリンクのフレームのための他の制御情報などのような、資源割り当てに関するデータを提供する。これらのＭＡＰメッセージのフォーマット及び内容に関する情報は、これらのメッセージをデコーディングするためのＡＰＩビット値を生成するために使用されてもよい。
図２６は、既知情報に基づいて、ＤＬ−ＭＡＰメッセージをデコーディング可能な受信機回路を例示する。例示されるように、ＭＡＣプロセッサ２６５０は、仮説エンジン２６６０に、ＤＬ−ＭＡＰタイミング及びメッセージ情報を供給してもよい。仮説エンジン２６６０は、ＡＰＩデコーダ２６３０を制御するために、ＤＬ−ＭＡＰ情報に基づいて、ＡＰＩビット値のセットを生成してもよい。実施形態にしたがって、ＭＡＣプロセッサは、連続的なタイミング及びＤＬ−ＭＡＰ情報 (例えば各フレーム)を提供してもよいし、この情報が変わるとともにそれほど頻繁でなく単に更新してもよい。
ＭＡＣプロセッサ２６５０は、以前にデコードされたビットを分析し、ＣＲＣチェックロジック２６４０及びＨＣＳ８（ヘッダチェック・シーケンス）チェックロジック２６４２からの結果をチェックし、正確なＤＬ−ＭＡＰメッセージが存在するかどうか決定し、仮説エンジン２６６０へ他の既知情報と同様にＤＬ−ＭＡＰ指示情報及びタイミングを提供する。
ＨＣＳ８ロジックは、ノーマルＤＬ−ＭＡＰメッセージを備えるＭＡＣヘッダ（例えばＩＥＥＥ８０２．１６標準の下で定義されたような）に対する８ビットのＣＲＣチェックを行なってもよい。このチェックは、少なくとも、ＭＡＣヘッダが適切にデコードされた場合の指示を提供する。より非常に詳しく下に記述されるように、十分なＣＲＣチェックが失敗する場合(ノーマルＤＬ−ＭＡＰメッセージ全体に対して)、成功したＨＣＳ８チェックは、成功裡にデコードされたＭＡＣヘッダの中の情報が、ＡＰＩビット値を生成するために使用されることを可能にしてもよい。メッセージの残りのデコーディングにおいて援助を行うとしてもよい。
異なるフォーマット及び内容のために、ノーマルＤＬ−ＭＡＰメッセージ及び圧縮されたＤＬ−ＭＡＰPメッセージは、異なるようにデコードされてもよい。ある実施形態について、受信機回路は、適切なメッセージをデコードするために、異なるＡＰＩビット値のセットを生成することができるとしてもよい。図２７は、ノーマル及び圧縮されたＤＬ−ＭＡＰメッセージをデコーディングするためのオペレーションの例を例示する。
２７０２で、ＤＬ−ＭＡＰメッセージの指示は受け取られる。例えば、ＭＡＣプロセッサは、ＤＬ−ＭＡＰがシーケンスにおける次であるメッセージ・シーケンスの既知のタイミングに基づいてこの指示を提供する。ＤＬ−ＭＡＰメッセージがノーマルか圧縮されかにかかわらず、決定は、ステップ２７０４でなされる。ＤＬ−ＭＡＰメッセージがノーマルの場合、メッセージは、２７０６で、ノーマルＤＬ−ＭＡＰメッセージのために生成されたＡＰＩビット値を使用してデコードされる。もし、ＤＬ−ＭＡＰメッセージが圧縮されている場合、ＤＬ−ＭＡＰメッセージは、２７０８で、圧縮されたＤＬ−ＭＡＰのために生成されたＡＰＩビット値を使用してデコードされる。
これらは、これらのオペレーションの例において相互に独立の個別のステップとして示しているが、一方で、ある実施形態について、並列デコーダは、ＤＬ−ＭＡＰメッセージが既知になる前でさえデコーディングが始まることを可能にして、ノーマル及び圧縮されたＤＬ−ＭＡＰメッセージをデコーディングすることに対して、提供されるとしてもよい。デコーディングの後、正確にデコードされたタイプに対するデコーディング結果だけが使用され、他が廃棄されるだろう。
ノーマル及び圧縮されたＤＬ−ＭＡＰメッセージの間の主な違いの１つは、ノーマルＤＬ−ＭＡＰメッセージのに提供されるＭＡＣヘッダである。図２８は、完全なノーマルＤＬ−ＭＡＰメッセージ・フォーマットを例示する。メッセージの最初の部分は、ＭＡＣヘッダの始めからＤｌＳｙｍＤｕｒフィールドまで、固定長を持つ。固定長部分は、多数の可変サイズフィールド、ＤＬ−ＭＡＰ ＩＥフィールド及び、最後にＣＲＣ３２フィールドによって後続される。
したがって、もし、メッセージがノーマルＤＬ−ＭＡＰメッセージであることとして指定されることがでいる場合、いくつかのビット値を生成することは可能である。例えば、ＭＡＣヘッダの多くのフィールドは、終始ある値に固定される。これらのフィールドは、既知のビット値に基づいてＡＰＩデコーダに対する仮説を生成するために使用されることができる。図２８では、固定値を持つフィールドは第１のクロスハッチングで示される。第２のクロスハッチングの印のあるいくつかの予備フィールドも、既知のビット値として扱われ、それらのフィールドに対する値が変わらないと命ずる標準を提供されるとしてもよい。
通信中に終始固定されるいくつかのフィールドがさらにある。しかし、例えば、移動局が基地局と提携することを決定するまで、これらの値は既知ではなくてもよい。第３のクロスハッチングの印のあるフィールドは、基地局と同期した後にＡＰＩデコーディングのために固定フィールドとして扱うことができる。
付加的なビット値も、現在値及び可能な将来値に基づいて決定されてもよい。例えば、フレームナンバーフィールド(ＦｒｍＮｒ)は、各フレームによって単調に増加し、ビット値は複数のフレームにわたって予測可能としてもよい。
ダウンリンクチャネル記述子（ＤＣＤ）カウントフィールド（ＤｃｄＣｎｔ）は各フレームを変更しない一方で、それは、ＤＣＤメッセージの構成における変更を示す機会に、１をインクリメントされるとしてもよい。したがって、すべてのビットを予測することは可能でないかもしれない一方で、もし、現在の値が既知であれば、値が１だけインクリメントされて変わるかもしれないＤＣＤＣｎｔの制限のある値に基づいてビット値を予測することは可能である。前フレームにおける値が０ｘ２（ｂ’００００００１０）の単純な例として、次のフレームにおいて、値は０ｘ２又は０ｘ３（ｂ’００００００１１）となるべきであり、７ＭＳＢのビット値を意味することが予測可能である（ＡＰＩビット値＝ｂ’００００００１Ｘ）。
図２９は、例えば、図２６の受信機によって実行されるとしてもよいノーマルＤＬ−ＭＡＰメッセージのＡＰＩデコーディングに対するオペレーション２９００の例のフロー図である。オペレーション２９００は、２９０２で、ノーマルＤＬ−ＭＡＰメッセージに関するＡＰＩに基づいて、仮説を生成することによって始まる。オペレーションは、フレーム境界で、又は、有効なフレームプリアンブルを検出した後、始まるとしてもよい。例えば、ＭＡＣプロセッサは、ノーマルＤＬ−ＭＡＰ仮説エンジンに対して、ノーマルＤＬ−ＭＡＰ仮説情報を更新及び提供してもよい。ある実施形態について、ノーマルＤＬ−ＭＡＰ仮説情報は、最新の情報が維持されてもよく、ＭＡＣプロセッサは、もし情報が変更されていなければその情報の更新を必要としない。ノーマルＤＬ−ＭＡＰ仮説情報を更新すること及び提供することは、次のフレームに対するフローの終わりで実行されてもよい。
２９０４及び２９０６で、ＡＰＩデコーディングは、ＡＰＩビット値が一致しない検討からデコーディングパスを除去すること、及び残りのパスから選択することにより、実行され、メッセージに対するデコードされたビットのセットを生成する。例えば、ＡＰＩデコーダは、標準の中で事前に定義されるフレーム境界からのＤＬ−ＭＡＰの時間オフセットで、ＤＬ−ＭＡＰでコーディングをデコーディングし始めてもよい。
２９０８で、ＣＲＣチェックは、メッセージが成功裡にデコードしたか決定するために実行される（メッセージの全体で）。例えば、ＡＰＩデコーダの出力は、ＤＬ−ＭＡＰメッセージを確認するために、受信されたＣＲＣ値と計算されたＣＲＣ値を比較するＣＲＣ３２チェッカに入る。もし、ＣＲＣチェックが成功すると、メッセージを送られたものが正確にデコードしたと仮定され、ＤＬ−ＭＡＰは２９１０で進められる。
しかしながら、メッセージ全体でのＣＲＣチェックが失敗の場合、ＭＡＣヘッダチェックコード（ＨＣＳ８）は、少なくとも、ＭＡＣヘッダが正しくデコードしたか見るために、２９１２でチェックされる。ＨＣＳ８チェックが成功であり、２９１６で決定されるように、現在のデコーディングループが「最初の通過」であれば、仮説情報は、２９１８で、例えば、成功してデコードされたＭＡＣヘッダフィールドを用いて、ノーマルＤＬ−ＭＡＰメッセージの残りの部分からの他の固定／予測フィールドを追加して、更新されてもよい。
潜在的に、本質的に、もっと既知のビット値とともに、この更新された仮説の使用により、第２の試みがメッセージのデコードに対して行われてもよい。付加的なビットは、２９０８で成功したＣＲＣチェックでの結果であるとしてもよい。その他の場合、デコーディングは２９１４で失敗したと決定される。
ある実施形態について、同様のＡＰＩデコーディングオペレーションは、圧縮されたＤＬ−ＭＡＰメッセージに対して、固定、予備、及び予測ビット値に基づいて実行されるとしてもよい。
図３０は、圧縮されたＤＬ−ＭＡＰメッセージ・フォーマットを例示する。メッセージの最初の部分、メッセージの開始からＩｅＣｎｔフィールドまで、は、固定長であり、多数の可変サイズＤＬ−ＭＡＰ ＩＥ及び、最後に、ＣＲＣ３２フィールドによって後続される。メッセージを、圧縮されたＤＬ−ＭＡＰメッセージとして指定された後（例えばＭＡＣプロセッサによる）、圧縮されたＭＡＰ指示としてメッセージのタイプを指定するメッセージの最初の３ビットは、第１のクロスハッチングで指定されるように、既知であり、固定される（ｂ’１１０’）だろう。
第２のクロスハッチングで示された予備フィールドは、もし標準がいくつかの目的のためにそのフィールドを変更しなければ、固定され、ＡＰＩデコーディングのために使用されると検討されてもよい。ノーマルＤＬ−ＭＡＰメッセージを持つように、通信の間、終始固定されるいくつかのフィールドがさらにある。しかし、例えば、移動局が基地局と提携することを決定するまで、これらの値は既知とならないとしてもよい。第３のクロスハッチングの印のあるこれらのフィールドは、基地局と同期した後にＡＰＩデコーディングのために固定フィールドとして扱うことができる。
付加的なビット値は、また、ノーマルＤＬ−ＭＡＰで一般的な他のフィールドの現在値及び可能な将来値に基づいて決定されてもよい。これらのフィールドは上述されるようなフレームナンバーフィールド（ＦｒｍＮｒ）及びダウンリンクチャネル記述子（ＤＣＤ）カウントフィールド(ＤｃｄＣｎｔ)を含む。
ある実施形態について、デコーディングロジックは、ノーマル及び圧縮されたＤＬ−ＭＡＰメッセージタイプの間で選択するために提供されてもよい。メッセージ・シーケンスに基づいて、ＤＬ−ＭＡＰがくることは既知でもよい一方で、それがノーマル又は圧縮されたＤＬ−ＭＡＰメッセージのどちらであるかは既知でなくてもよい。
図３１は、並列にノーマル及び圧縮されたＤＬ−ＭＡＰメッセージをデコーディングするための並列ＡＰＩデコーダを含むデコーディングロジック３１００を例示する。図３２は、並列にノーマル及び圧縮されたＤＬ−ＭＡＰメッセージを処理するためのオペレーション３２００の例を例示する。オペレーション３２００は、図３２に示されるコンポーネントによって実行されてもよい。
オペレーション３２００は、３２０２で、ノーマル及び圧縮されたＤＬ−ＭＡＰの両方に対する既知情報に基づいて、仮説を生成することにより、始まる。３２０４及び３２０６で、ＡＰＩデコーディングは、ノーマル及び圧縮されたＤＬ−ＭＡＰ仮説を使用して並列に実行される。例示されるように、デコーダ３１１０は、ノーマルＤＬ−ＭＡＰＡＰＩビット値に基づいてコードされたビットをデコードすると同時に、デコーダ３１１０は、圧縮されたＤＬ−ＭＡＰＡＰＩビット値に基づいて同様にコードされたビットをデコードする。
３２０８で、決定は、ノーマル又は圧縮されたＤＬ−ＭＡＰ仮説のどちらを使用して、ＤＬ−ＭＡＰメッセージが成功してデコードされたかに関して、なされる。そうでなければ、デコーディングはステップ３２１２で失敗する。そうでなければ、ＤＬ−ＭＡＰは、ＤＬ−ＭＡＰメッセージがノーマルか圧縮されているかにかかわらず、３２１０で、出力される。
デコーディングが成功したかどうか決定し、デコーダ間の選択を支援するために、ＤＬ−ＭＡＰ選択ロジック３１３０は、ＣＲＣ３２及び／又はＨＣＳ８チェックを実行することにより、デコードされたデータを確認するために備えられてもよい。もし、ＣＲＣチェックがデコーダ３１２０からの出力について成功であるとした場合、メッセージは圧縮されたＤＬ−ＭＡＰメッセージである。もし、ＣＲＣチェックがデコーダ３１１０からの出力について成功であるとした場合、メッセージはノーマルＤＬ−ＭＡＰメッセージである。上述されるように、成功したＨＣＳ８チェックによって示されるような、ノーマルＤＬ−ＭＡＰのＭＡＣヘッダの部分的な成功したデコーディングの成功は、ＣＲＣチェックが失敗した場合において、ノーマルＤＬ−ＭＡＰに対するデコーディングの他の反復の実行のために使用されるとしてもよい。
上述された並列アプローチの代わりとして、ＤＬ−ＭＡＰは、また、連続するアプローチを使用してデコードされるとしてもよい。例えば、単一のＡＰＩデコーダは、連続する方法で、ノーマル及び圧縮されたＤＬ−ＭＡＰ仮説を試みるために利用されてもよい。
例として、ノーマルＤＬ−ＭＡＰに対する仮説が最初に試みられ、そして、もし、デコーディングが失敗すると、圧縮されたＤＬ−ＭＡＰに対する仮説が使用されるとしてもよい。単一のデコーダの使用は、上述された多数のデコーダの実施形態より少ない電力を消費するとしてもよい。
ある実施形態について、多くの反復を最小化するために、前のＤＬ−ＭＡＰタイプの履歴は、現行フレームのＤＬ−ＭＡＰタイプを予測するために使用されてもよい。換言すれば、もし、最後のＤｌ−ＭＡＰメッセージタイプが圧縮されている場合、圧縮されたＤＬ−ＭＡＰタイプに対応するＡＰＩビット値は、デコーディングに使用されてもよい。もし、圧縮されたＤＬ−ＭＡＰタイプ ＡＰＩデコーディングが失敗すると、ノーマルＤＬ−ＭＡＰタイプに対応するＡＰＩビット値は、後のデコーディング反復において使用されてもよい。
アップリンクＭＡＰ（ＵＬ−ＭＡＰ）メッセージ・フォーマット及び内容に関する既知情報は、また、ＡＰＩビット値を生成し、デコーディングを助けるために使用されてもよい。
ＩＥＥＥ８０２．１６ｅ ＯＦＤＭＡ標準によれば、ＵＬ−ＭＡＰメッセージは、最初のデータトラフィックＤＬ−ＭＡＰ情報エレメント（ＩＥ）によって導かれるバーストにおいて、最初のＭＰＤＵであることは明示される。もし、圧縮されたＵＬ−ＭＡＰ及びＳｕｂ−ＤＬ−ＵＬ−ＭＡＰの両方がフレームに存在しない場合には、移動局は、いくつかの条件がＤＬ−ＭＡＰを解析した後に満たされれば、最初のデータバーストの最初のＭＰＤＵがＵＬ−ＭＡＰメッセージになるだろうと典型的には仮定することができる。この情報を使用して、移動局は、あるポイントでどのタイプのメッセージをデコーダによって出力させることができるかを知り、「既知情報」としてメッセージの「既知の値」を使用することができ、ＡＰＩ復号スキームに基づいたデコーディング性能を改善する。
図３３は、既知情報に基づいて、ＵＬ−ＭＡＰメッセージをデコーディング可能な受信機回路を例示する。ＤＬ−ＭＡＰ及びＵＬ−ＭＡＰメッセージの間のフォーマットの類似性により、受信機回路は、既知情報に基づいてＤＬ−ＭＡＰメッセージをデコーディング可能な図２６の受信機回路と類似な方法で動作するとしてもよい。
例示されるように、ＭＡＣプロセッサ３３５０は、ＵＬ−ＭＡＰタイミング及びメッセージ情報を、仮説エンジン３３６０に提供してもよい。仮説エンジン３３６０は、ＵＬ−ＭＡＰ情報に基づいて、ＡＰＩビット値のセットを生成するとしてもよく、ＡＰＩデコーダ３３３０を制御する。実施形態にしたがって、プロセッサは、連続的なタイミング及びＵＬ−ＭＡＰ情報(例えば各フレーム)を提供してもよく、又は、それほど頻繁でなく情報が変化するときに単に更新するとしてもよい。プロセッサ３３５０は、以前にデコードされたビットを分析し、ＣＲＣチェックロジック３３４０及びＨＣＳ８チェックロジック３３４２からの結果をチェックし、正確なＵＬ−ＭＡＰメッセージが存在するか決定し、他の既知情報と同様に、ＵＬ−ＭＡＰ指示情報及びタイミングを、仮説エンジン３３６０に提供する。
図３４は、ＵＬ−ＭＡＰメッセージ・フォーマットを例示する。メッセージの最初の部分は、ＭＡＣヘッダの始めからＵｉＳｙｍＤｕｒフィールドまで、固定長である。固定長の部分は、多数の可変サイズフィールドＵＬ−ＭＡＰ ＩＥフィールド及び、最後にＣＲＣ３２フィールドによって後続される。
一旦、メッセージがＵＬ−ＭＡＰメッセージであると決定されると、ＭＡＣヘッダ部の多くのフィールドは、固定値のままだろう。これらのフィールドに関するこの既知情報は、ＡＰＩデコーダに対するＡＰＩビット値を生成するために使用されることができる。図において、固定値を持つフィールドは、第１のクロスハッチングによって示される。第２のクロスハッチングによって示されるいくつかの予備フィールドは、また、標準がある目的のためにフィールドのビット値を変更しなければ、ＡＰＩデコーダによって使用されることができる。
また、現在のオペレーティングパラメータに基づいて、予測されることができるいくつかの値を持つ様々なフィールドがある。例として、アップリンクチャネル記述子（ＤＣＤ）カウントＵｃｄＣｎｔフィールドは、ほとんどの場合変更されないだろうが、あるポイントで１を増加されてもよい。したがって、ほとんどの場合、多くのＭＳＢは変わらないだろう。
他の例として、あるフィールドの最大値は、一旦移動局が特定の基地局と提携されると決定されるとしてもよく、それらのフィールドに影響する得られたネットワークパラメータは既知である。例として、一旦、ＲＦ帯域幅、フレーム持続時間及びＵＬ−ＭＡＰ関連ポリシーが得られたならば、割り付けられた開始時刻フィールド（ＡｌｌｏｃＳｔａｒｔＴｉｍｅ）及び／又はアップリンクシンボル持続時間フィールド（ＵｌＳｙｍＤＤＤｕｒ）に対する最大値は算出されることができる。
この例示のため、もし、現在のＲＦ帯域幅が５ＭＨｚ、フレーム持続時間が５ミリセカンドである場合、ＡｌｌｏｃＳｔａｒｔＴｉｍｅの最大値は、ＭＡＰ関連モードにしたがって０ｘ１Ｂ５８又は０ｘ３６Ｂ０とすることができる。もし、最大値が０ｘ３６Ｂ０ならば、１８ＭＳＢはゼロにセットされるだろう。他の例として、現在のＲＦ帯域幅が５ＭＨｚで、フレーム持続時間が５ミリセカンドならば、ＵｌＳｙｍＤｕｒの最大値はＷｉＭＡＸプロファイルにしたふぁって０Ｘ１５になるだろう。したがって、最初の３ＭＳＢB(ビット７−５)は、ゼロにセットされるだろう。
図３５は、ＵＬ−ＭＡＰメッセージをデコーディングするためのオペレーション３５００の例を例示する。オペレーション３５００は、例えば、ＦＣＨに続くＵＬ−ＭＡＰをデコーディングした後、始まるとしてもよい。図３３に示されるように、ＭＡＣプロセッサは、これらのオペレーションのためのＵＬ−ＭＡＰに対して、ＵＬ−ＭＡＰ仮説を更新及び提供するとしてもよい。
オペレーション３５００は、３５０２で、ＵＬ−ＭＡＰに対する既知情報に基づいて、１以上の仮説を生成することによって、始まる。実施形態について、ＵＬ−ＭＡＰ仮説エンジンは、最新の情報を維持するとしてもよく、ＭＡＣプロセッサは、もし情報が変更されていなければその情報の更新を必要としない。ＵＬ−ＭＡＰ仮説情報を更新すること及び提供することは、次のフレームに対するフローの終わりで実行されてもよい。
３５０４及び３５０６で、ＡＰＩデコーダは、ＵＬ−ＭＡＰＡＰＩを用いてデコーディング、ＡＰＩビット値を一致しないデコーディングパスの除去、残りのパスからの選択を始める。ＡＰＩデコーダは、例えば、ＤＬ−ＭＡＰメッセージにある対応するＤＬ−ＭＡＰ ＩＥに記述されるＵＬ−ＭＡＰの時間オフセットで、デコーディングを始めてもよい。
３５０８で、ＣＲＣチェックは、デコードされたメッセージにおいて行なわれる。図３３に例示されるように、ＡＰＩデコーダからのデコードされたビット出力は、ＵＬ−ＭＡＰメッセージを確認するために、受信されたＣＲＣ値と計算されたＣＲＣ値とを比較するＣＲＣ３２チェックロジックに対する出力であるとしてもよい。もしＣＲＣが一致する場合、成功してデコードされたＵＬ−ＭＡＰは、３５１０で、進められる。
ノーマルＤＬ−ＭＡＰのデコーディングに関する上述の類似する方法において、もし、メッセージ全体に対するＣＲＣが確認失敗であるが、ＭＡＣヘッダに対するＨＣＳ８が３５１２で整合した場合には、デコーディングの他の反復３５１４は、３５１８で生成された更新された仮説を用いて実行されるとしてもよい。
例えば、デコードされたＭＡＣヘッダ全体が、ＵＬ−ＭＡＰメッセージの残り部分における他の固定／予測ビット値に加えて、既知の値として使用されてもよい。もし、デコーディングが、この第２の反復の後でさえ失敗する場合には、デコーディングは、３５１４で、失敗と考えられてもよい。
上述された例は、ＵＬ−ＭＡＰ及びＤＬ−ＭＡＰメッセージデコーディングに関して、基地局から移動局に通常に伝送され、主に必要とされるメッセージを持つ。デコーディングメッセージが移動局(あるいは他のタイプの送信機)から伝送された時、同様のタイプのＡＰＩデコーディング動作は、さらに基地局で起こってもよい。
例えば、ＡＰＩデコーディングは、ＷｉＭＡＸにしたがって、レンジングリクエスト（ＲＮＧ−ＲＥＱ）及び帯域幅リクエスト（ＢＷ−ＲＥＱ）メッセージについて適用されてもよい。ＲＮＧ−ＲＥＱ及びＢＷ−ＲＥＱメッセージに関する既知情報に基づいて生成されたビット値を使用するＡＰＩデコーディングオペレーションは、基地局で、ＲＮＧ−ＲＥＱ及びＢＷ−ＲＥＱメッセージデコーディング性能を増すために使用されてもよい。
ＩＥＥＥ８０２．１６ｅ標準にしたがって、移動局がＲＮＧ−ＲＥＱ及び／又はＢＷ−ＲＥＱメッセージを送ることができるように、移動局は、アップリンクにおけるリソース割り当てを要求するために、基地局へＣＤＭＡコードを送るものとする。基地局は、ＵＬ＝ＭＡＰに含まれているＣＤＭＡ＿Ａｌｌｏｃａｔｉｏｎ＿ＩＥを使用して、アップリンクにおけるある量のリソースを割り付けてもよい。
基地局は、実際にメッセージを受け取る前に、ＣＤＭＡ＿Ａｌｌｏｃａｔｉｏｎ＿ＩＥによって割り付けられた範囲に対してどのタイプのメッセージが渡されるのか、知っている。このメッセージは、ＲＮＧ−ＲＥＱメッセージ又はＢＷ−ＲＥＱメッセージになるだろう。この情報に基づいて、基地局は、ＲＮＧ−ＲＥＱ及びＢＷ−ＲＥＱメッセージに関する既知情報に基づいて生成されたビット値を備える仮説を使用して、ＡＰＩデコーディングを実行してもよい。
図３６は、ＲＮＧ−ＲＥＱ及びＢＷ−ＲＥＱメッセージに関する既知情報に基づいてＡＰＩデコーディング可能な受信機回路を例示する。例示されるように、ＭＡＣスケジューラ３６５０は、ＭＡＣプロセッサ３６３０、ＣＤＭＡ＿Ａｌｌｏｃａｔｉｏｎ情報(例えば、タイミング、範囲及び予期されたメッセージタイプを含む)に、情報を提供してもよい。プロセッサ３６３０は、仮説エンジン３６２０に、関連するタイミングと仮説情報を転送するだろう。仮説エンジン３６２０は、既知のビット値を抽出することができ、ＲＮＧ−ＲＥＱ及び／又はＢＷ−ＲＥＱメッセージをデコーディングするための仮説情報を生成する。ＲＮＧ−ＲＥＱ及びＢＷ−ＲＥＱ仮説は、例えば、ノーマル及び圧縮されたＤＬ−ＭＡＰ仮説に関連する上記の説明と同様に、並列又はシーケンシャルな方法で、評価されてもよい。
図３７及び３８は、仮説が生成されてもよいＲＮＧ−ＲＥＱ及びＢＷ−ＲＥＱ・フォーマットを例示する。
まず、図３７を参照すると、ＲＮＧ−ＲＥＱメッセージは６バイトの一般的なＭＡＣヘッダから始まる。ＭＡＣヘッダには、１バイトの管理メッセージタイプが続き、１バイトの予備フィールドが続き、多数のタイプレングス値（ＴＬＶ）フィールドが続き、最後に、３２ビットＣＲＣである。これらのフィールドのうち、この情報のうちのいくらかは固定され、いくらかは予測可能である。
例として、１バイトの管理メッセージタイプは、ＲＮＧ−ＲＥＱメッセージ用の「４」で固定され、１バイトの予備フィールドはすべてゼロである。さらに、ＭＡＣヘッダは、１ビットのヘッダタイプで始まり、１ビットの暗号化コード（ＥＣ）、６ビットのタイプフィールド、及び１ビットの拡張されたＳｕｂ０−ヘッダフィールドが続き、これらのすべては、ＲＮＧ−ＲＥＱメッセージに対してゼロとする。これらのフィールドは、１ビットのＣＲＣインジケータ（ＣＩ）に後続され、これはＲＮＧ−ＲＥＱに対して１であり、２ビットの暗号鍵シーケンス（ＥＫＳ）に後続され、こではすべてゼロであり、ゼロである１ビットの予備ビットに後続される。
ＴＬＶの長さの制限により少なくとも部分的に決定されるとしてもよい長さフィールドは、これらのフィールドに続く。ＴＬＶの長さの制限により少なくとも部分的に決定されてもよい長さフィールドはこれらのフィールドに続く。図３７に示されるように、ＴＬＶの最大の長さは、ＴＬＶの長さに関連されるすべてのＲＮＧ−ＲＥＱを蓄積することにより決定されることができ、ＩＥＥＥ８０２．１６ｅ標準のあるバージョンによって８５バイトをもたらす。したがって、ＲＮＧ−ＲＥＱメッセージは、ＭＡＣヘッダとＣＲＣ３２を含む９７バイトを超過することができない。その結果、底の８ビットだけの長さフィールドが長さを表わすために要求され、残りのＭＳＢはゼロになるだろう。
ＭＡＣヘッダにおける１６ビットの接続識別子（ＣＩＤ）フィールドのすべてあるいは一部は、また、少なくとも２つの方法で予測されるとしてもよい。第１に、基地局は、ＲＮＧ−ＲＥＱのタイプが、割り付けられたＵＬ範囲を通って送られるものについての知識を持つ。なぜなら、それは、それ自体スケジュールしたためである。その範囲が初期レンジングに対してスケジュールされる場合、ＣＩＤはゼロであるべきである。
第２に、もし、基地局がＲＮＧ−ＲＥＱのタイプを知らない場合(例えば、ＣＩＤフィールドがゼロでないとしてもよい)、基地局は、基地局がサポートできる移動局の最大値を使用してもよい。標準は、典型的に、ＲＮＧ−ＲＥＱの中のＣＩＤが基礎的なＣＩＤであり、基礎的なＣＩＤの範囲が１とｍの間(ここでｍは基礎的なＣＩＤの最大値である)であるように命令するとすると、ＣＩＤフィールドの最大値は既知であり、ＭＳＢが知られることを可能にしてもよい。例として、最大のＣＩＤ値が２５５である場合、より低い８ビットだけが必要とされ、残りのＭＳＢはゼロであると仮定することができる。
各ＴＬＶの長さフィールドの値は、ＴＬＶタイプ２１を除き標準によって固定される。
不運にも、タイプを知らずに、仮説として長さ値を使用することは可能ではないかもしれない。しかしながら、仮定が、与えられた仮説のタイプフィールドが正確であれば、対応するＴＬＶビットが使用されてもよい。ＴＶＬ長さフィールドのビット値は、メッセージのＣＲＣ３２が正確でない場合、例えば、第２又はさらなる反復において評価されて、異なる仮説において使用されてもよい。
図３８のＢＷ−ＲＥＱメッセージを参照すると、このメッセージ・フォーマットはわずか６バイトしか持っていない。しかしながら、これらの最初の４ビットは固定値を持ち、これらは既知情報として使用されてもよい。ある実施形態について、個別のデコーダは、上述されたノーマル及び圧縮されたＤＬ−ＭＡＰ仮説を用いたデコーディングオペレーションと類似に、並列に、ＲＮＧ−ＲＥＱ及びＢＷ−ＲＥＱを用いたＡＰＩデコーディングを可能にするために備えられてもよい。あるいは、そのような仮説は連続する方法で評価されてもよい。
図３９は、例えば、図３６の基地局受信機によって実行されてもよい、ＲＮＧ−ＲＥＱ及びＢＷ−ＲＥＱメッセージのＡＰＩデコーディングのためのオペレーション３９００の例のフロー図である。
オペレーション３９００は、ＣＤＭＡ＿ＡＬＬＯＣＡＴＩＯＮ＿ＩＥを送信することによって、３９０２で始まり、移動局とのアップリンク接続である量のリソースを割り当てる。３９０３で、ＣＤＭＡ割り当て情報は、プロセッサ３６６０に提供され、プロセッサ３６６０は、メッセージタイプ、タイミング及び仮説情報３９０４を仮説エンジン３９０４に提供し、３９０６で、ＢＷ＿ＲＥＱ及びＲＮＧ＿ＲＥＱ仮説が生成される。ある実施形態について、仮説情報は仮説エンジンに記憶され、変更された時にのみ(例えばＭＡＣプロセッサによって)更新されてもよい。
３９０８で、基地局は、ＣＤＭＡ＿ＡＬＬＯＣＡＴＩＯＮ範囲でアップリンク信号を待つ。ＣＤＭＡ＿ＡＬＬＯＣＡＴＩＯＮ範囲におけるアップリンク信号は、３９１０で受信される。３９１２で、決定は、信号がＲＮＧ＿ＲＥＱメッセージ又はＢＷ＿ＲＥＱメッセージのどちらに対応するかに関して行われる。
３９１２で決定されるように、もし、信号がＲＮＧ＿ＲＥＱメッセージに対応する場合、信号は、３９１４で、ＲＮＧ＿ＲＥＱ仮説を使用してデコードされる。もし、３９１６で決定されるように、デコードされた信号のＣＲＣが成功とチェックすると、デコーディングは成功であり、３９１８でなんとかして示されてもよい。
たとえＣＲＣが失敗しても、３９２０で、ＨＣＳチェックによって決定される、ヘッダが適切にデコードしたことは可能性がある。もしＨＣＳチェックが失敗する場合、３９２６で、ヘッダは適切にデコードせず、デコーディングは失敗する。
しかしながら、３９２２で決定されるように、ＨＣＳチェックが成功し（ＭＡＣヘッダが適切にデコードされたことを示す）、これが最初のデコーディングループの場合、仮説は、３９２４で、これを反映するために更新されてもよい。デコーディングオペレーションは、更新された仮説（他のＡＰＩビット値に加えてＭＡＣヘッダを含む）を用いて再び実行されるとしてもよい。例えば、ＭＡＣプロセッサは、仮説エンジンに提供される仮説情報を更新してもよい。
もし、この付加的な仮説情報を用いたＡＰＩデコーディングの後、再びＣＲＣが失敗するが、ＨＣＳが再び成功である場合、ＭＡＣプロセッサは、ＴＬＶ項目（アイテム）に関するより積極的な仮定を用いてデコードしてもよい。例えば、第２のデコーディングループ上で（ヘッダビットを用いたＡＰＩデコーディングの後で）、３９２８で決定されたように、ＭＡＣプロセッサは、３９３０で、ＴＬＶ仮定をしてもよい。例として、もし、タイプフィールドが正確であると仮定される場合、ほとんどの長さフィールドは、標準にしたがって既知情報として使用されることができる。ある実施形態については、どれだけのデコーディング反復が許可されるかの制限があってもよい。例えば、ＣＲＣが、ＴＬＶ仮定に基づくこのより積極的なデコーディングの後に再び失敗する場合、たとえＨＣＳが一致したとしても、デコーディング３９３２で失敗する。
戻って３９１２を参照すると、もし、信号がＢＷ＿ＲＥＱメッセージに対応していると、信号は、３９４０で、ＢＷ＿ＲＥＱ仮説を使用してデコードされる。ＢＷ＿ＲＥＱメッセージは、ＨＣＳのみを持ち、ＣＲＣは持たない。したがって、もし、３９４０で、デコードされた信号のＨＣＤが成功とチェックすると、デコーディングは、成功である（３９４４）。もし、ＨＣＳチェックが失敗の場合、３９４６においてデコーディングは失敗である。
基地局でＡＰＩデコーディングを実行することによって、例えば、ここで説明された仮説を用いて、基地局でＲＮＧ−ＲＥＱ及びＢＷ−ＲＥＱメッセージデコーディング性能は、改善されるだろう。
上述された方法の各種オペレーションは、様々なハードウェア及び／又はソフトウエアコンポーネント、及び／又はまたは)図の中で例示された手段プラス機能のブロックに対応するモジュールによって行なわれてもよい。
例えば、図６に例示されているブロック６００−６０６は、図６Ａに例示されている手段プラス関数のブロック６００Ａ−６０６Ａに対応する。
より一般には、相当する対応物の手段プラス機能の図を持つ図で例示される方法がある場合、動作ブロックは、類似の番号付けを持つ手段プラス機能のブロックに対応する。
ここで使用されるように、用語「決定」は種々様々のアクションを包含する。例えば、「決定」は、計算すること、算出すること、処理すること、引き出すこと、調査すること、探すこと(例えば、テーブル、データベース、又は別のデータ構造の中を探すこと)、確認すること、などを含むとしてもよい。さらに、「決定」は受信すること(例えば受信情報)、アクセスすること(例えばメモリ中のデータをアクセスすること)、その他を含むとしてもよい。さらに、「決定」は、分析すること、選択すること、選ぶこと、確立すること、その他を含むとしてもよい。
情報及び信号は、様々な異なるテクノロジー及びテクニックのうちのいずれかを使用して表わされてもよい。例えば、上記の記述の全体にわたって参照されることができるデータ、命令、コマンド、情報、信号などは、電圧、電流、電磁波、磁界又は粒子、光学フィールド又は粒子、あるいはそれの任意の組み合わせによって表わされてもよい。
本開示に関して記述された様々な実例の論理ブロック、モジュール、回路は、メインプロセッサ、デジタルシグナルプロセッサー（ＤＳＰ）、特定用途向け集積回路(ＡＳＩＣ)、フィールドプログラマブルゲートアレイ信号（ＦＰＧＡ）又は他のプログラマブルロジックデバイス、離散的なゲートかトランジスタロジック、離散的なハードウェア構成機器、あるいはそれのここに記述された機能を実行することを目指した任意の組み合わせによって実現又は実行されるとしてもよい。メインプロセッサはマイクロプロセッサでもよい。しかし、代案において、プロセッサは、任意の市販のプロセッサ、コントローラ、マイクロコントローラあるいはステートマシンでもよい。プロセッサは、さらに、例えば、例えばＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと協力する１以上のマイクロプロセッサ、あるいは他のそのような構成など、計算装置の組み合わせとして実現されてもよい。
本開示に関して記述された方法又はアルゴリズムのステップは、ハードウェア、プロセッサによって実行されたソフトウェア・モジュール、あるいは２つの組み合わせで直接具体化されてもよい。ソフトウェア・モジュールは、従来技術で知られている記憶媒体の任意の形式に存在してもよい。使用されることができる記憶媒体のいくつかの例は、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取外し可能ディスク、ＣＤ−ＲＯＭなどを含む。ソフトウェア・モジュールは、単一命令、あるいは多くの命令を含むとしてもよく、いくつかの異なるコードセグメントを超えて、異なるプログラムの間に、および、多数の記憶媒体にわたって、分配されてもよい。記憶媒体は、プロセッサが記録媒体に対して情報を読む及び書き込むことができるように、プロセッサにつながれてもよい、代替として、記憶媒体はプロセッサに統合されるとしてもよい。
ここに示された方法は、上記の方法を達成するための１以上のステップ又はアクションを含む。方法ステップ及び／又はアクションは、請求項の範囲から外れずに、互いに交換されてもよい。換言すれば、ステップ又はアクションの特定の順序が指定されなければ、特定のステップ及び／又はアクションの順序及び／又は使用は、請求項の範囲から外れずに修正されてもよい。
上述された機能は、ハードウェア、ソフトウェア、ファームウェア、あるいはそれらの任意の組み合わせにおいて実装されてもよい。もしソフトウェアで実装されると、機能はコンピュータ読み取り可能媒体についての１以上の命令として格納されてもよい。記憶媒体は、コンピュータによってアクセスすることが可能なあらゆる利用可能とすることができる。制限ではなく例経として、そのようなコンピュータ読み取り可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ又は他の光学ディスク記憶装置、磁気ディスク記憶装置又は他の磁気記憶装置、あるいは、命令又はデータ構造の形式で所望のプログラムコードを運び又は記憶するために使用可能及びコンピュータによってアクセス可能な他のあらゆる媒体、を含むとしてもよい。ここで使用されるディスクは、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、ディジタル・バーサタイル・ディスク（ＤＶＤ）、フロッピー（登録商標）ディスク、及びディスクがレーザーでデータを光学上再生する間にディスクが通常磁気的にデータを再生するブルーレイ（登録商標）ディスク、を含むとしてもよい。
ソフトウェア又は命令も伝送媒体を通して伝送されてもよい。例えば、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者線（ＤＳＬ）、又は赤外線、無線及びマイクロ波のような無線技術を使用して、ソフトウェアがウェブサイト、サーバ、又は他の遠隔ソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、又は赤外線、無線及びマイクロ波のような無線技術は、送信媒体の定義に含まれる。
さらに、図において例示されたような、モジュール及び／又はここに記述された方法及び技術を実行するための他の適切な手段が、適用可能なものとして、ダウンロードされ、及び／又は、移動装置及び／又は基地局によって別の方法で得られることができることは、認識されるべきである。例えば、そのような装置は、ここに記述された方法を実行するための手段の転送を促進するサーバにつなぐことができる。あるいは、ここに記述された様々な方法は、記憶手段（例えばランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、コンパクトディスク（ＣＤ）のような物理記憶媒体又はフロッピ−ディスク、など）を使用して、提供されることができる。移動装置及び／又は基地局が装置は、装置に対して記憶装置を接続又は提供することにより、様々な方法を得ることができる。さらに、装置に対して、ここで説明された方法及び技術を提供するためのあらゆる他の適切な技術が、利用することができる。
請求項は、先に例示された正確な構成及びコンポーネントに制限されないことは理解されるべきである。様々な変形、変更及び変化は、請求項の範囲から外れずに、上述された方法と装置の配置、オペレーション及び詳細で行なわれてもよい。
ここで使用されたように、用語「決定」は、種々様々のアクションを包含する。例えば、「決定」は、計算すること、算出すること、処理すること、引き出すこと、調査すること、探すこと(例えば、テーブル、データベース、又は別のデータ構造の中を探すこと)、確認すること、などを含むとしてもよく、逆もまた同様である。さらに、「決定」は受信すること(例えば受信情報)、アクセスすること(例えばメモリ中のデータをアクセスすること)、その他を含むとしてもよい。さらに、「決定」は、分析すること、選択すること、選ぶこと、確立すること、その他を含むとしてもよく、逆もまた同様である。
情報と信号は、様々な異なるテクノロジー及びテクニックのうちのどれでも使用して表わされてもよい。例えば、上述の全体にわたって参照されることができるデータ、命令、コマンド、情報、信号などは、電圧、電流、電磁波、磁界又は粒子、光学フィールド又は粒子、あるいはそれの任意の組み合わせによって表わされてもよい。
本開示に関して記述された様々な実例の論理ブロック、モジュール、回路は、メインプロセッサ、デジタルシグナルプロセッサー（ＤＳＰ）、特定用途向け集積回路(ＡＳＩＣ)、フィールドプログラマブルゲートアレイ信号（ＦＰＧＡ）又は他のプログラマブルロジックデバイス、離散的なゲートかトランジスタロジック、離散的なハードウェア構成機器、あるいはそれのここに記述された機能を実行することを目指した任意の組み合わせによって実現又は実行されるとしてもよい。メインプロセッサはマイクロプロセッサでもよい。しかし、代案において、プロセッサは、任意の市販のプロセッサ、コントローラ、マイクロコントローラあるいはステートマシンでもよい。プロセッサは、さらに、例えば、例えばＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと協力する１以上のマイクロプロセッサ、あるいは他のそのような構成など、計算装置の組み合わせとして実現されてもよい。
本開示に関して記述された方法又はアルゴリズムのステップは、ハードウェア、プロセッサによって実行されたソフトウェア・モジュール、あるいは２つの組み合わせで直接具体化されてもよい。ソフトウェア・モジュールは、従来技術で知られている記憶媒体の任意の形式に存在してもよい。使用されることができる記憶媒体のいくつかの例は、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取外し可能ディスク、ＣＤ−ＲＯＭなどを含む。ソフトウェア・モジュールは、単一命令、あるいは多くの命令を含むとしてもよく、いくつかの異なるコードセグメントを超えて、異なるプログラムの間に、および、多数の記憶媒体にわたって、分配されてもよい。記憶媒体は、プロセッサが記録媒体に対して情報を読む及び書き込むことができるように、プロセッサにつながれてもよい、代替として、記憶媒体はプロセッサに統合されるとしてもよい。
ここに示された方法は、上記の方法を達成するための１以上のステップ又はアクションを含む。方法ステップ及び／又はアクションは、請求項の範囲から外れずに、互いに交換されてもよい。換言すれば、ステップ又はアクションの特定の順序が指定されなければ、特定のステップ及び／又はアクションの順序及び／又は使用は、請求項の範囲から外れずに修正されてもよい。
上述された機能は、ハードウェア、ソフトウェア、ファームウェア、あるいはそれらの任意の組み合わせにおいて実装されてもよい。もしソフトウェアで実装されると、機能はコンピュータ読み取り可能媒体についての１以上の命令として格納されてもよい。記憶媒体は、コンピュータによってアクセスすることが可能なあらゆる利用可能とすることができる。制限ではなく例経として、そのようなコンピュータ読み取り可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ又は他の光学ディスク記憶装置、磁気ディスク記憶装置又は他の磁気記憶装置、あるいは、命令又はデータ構造の形式で所望のプログラムコードを運び又は記憶するために使用可能及びコンピュータによってアクセス可能な他のあらゆる媒体、を含むとしてもよい。ここで使用されるディスクは、コンパクトディスク（ＣＤ）、レーザーディスク、光ディスク、ディジタル・バーサタイル・ディスク（ＤＶＤ）、フロッピーディスク（Ｒ）、及びディスクがレーザーでデータを光学上再生する間にディスクが通常磁気的にデータを再生するブルーレイ（Ｒ）ディスク、を含むとしてもよい。
ソフトウェア又は命令も伝送媒体を通して伝送されてもよい。例えば、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者線（ＤＳＬ）、又は赤外線、無線及びマイクロ波のような無線技術を使用して、ソフトウェアがウェブサイト、サーバ、又は他の遠隔ソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、又は赤外線、無線及びマイクロ波のような無線技術は、送信媒体の定義に含まれる。
さらに、モジュール及び／又はここに記述された方法及び技術を実行するための他の適切な手段が、適用可能なものとして、ダウンロードされ、及び／又は、移動装置及び／又は基地局によって別の方法で得られることができることは、認識されるべきである。例えば、そのような装置は、ここに記述された方法を実行するための手段の転送を促進するサーバにつなぐことができる。あるいは、ここに記述された様々な方法は、記憶手段（例えばランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、コンパクトディスク（ＣＤ）のような物理記憶媒体又はフロッピ−ディスク、など）を使用して、提供されることができる。移動装置及び／又は基地局が装置は、装置に対して記憶装置を接続又は提供することにより、様々な方法を得ることができる。さらに、装置に対して、ここで説明された方法及び技術を提供するためのあらゆる他の適切な技術が、利用することができる。
請求項が上に例示された正確な配位及びコンポーネントに制限されていないことは理解される。様々な変形、変更及び変化は、請求項の範囲から外れずに、上に記述された方法と装置の配置、オペレーションおよび詳細において行なわれることができる。
先のものが本発明の実施形態に導かれると同時に、本発明の他及びさらなる実施形態はそれの基礎的な範囲から外れずに、工夫されてもよく、また、その範囲は、続く請求項によって決定される。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［１］
メッセージに対する無線通信伝送のエンコードされたデータビットをデコーディングするための方法において、
ＭＡＰメッセージの内容及び関連する伝送のパラメータ：のうちの少なくとも一つに関する既知情報に基づいてエンコードされたデータビットのビット値のセットを指定する仮説を生成すること、
検討から、前記指定されたビット値と不一致のデコードされたビットのセットを除去すること、及び、出力として、前記仮説によって指定された前記ビット値と一致するデコードされたビットを選択することによって伝送をデコーディングすること、
を含む、方法。
［２］
ＭＡＰメッセージは、ノーマルＤＬ−ＭＡＰメッセージ、圧縮されたＤＬ−ＭＡＰメッセージ、ＵＬ−ＭＡＰメッセージ、ＲＮＧ−ＲＥＱメッセージ、及びＢＷ−ＲＥＱメッセージのうちの少なくとも一つを含む、［１］の方法。
［３］
前記メッセージが成功裡にデコードされていないことを決定すること、
前記メッセージのＭＡＣヘッダが成功裡にデコードされていることを決定すること、
前記成功裡にデコードされたＭＡＣヘッダのビット値を指定するために前記仮説を更新すること、
仮定を用いてビット値を指定するために前記仮説を更新すること、
検討から、前記指定されたビット値と不一致のデコードされたビットのセットを除去すること、及び、出力として、前記仮説によって指定された前記ビット値と一致するデコードされたビットを選択することによって伝送を再びデコーディングすること、をさらに含む、［１］の方法。
［４］
前記仮説を生成することは、標準にしたがってすべての時間で固定されている値に基づいて１以上のビット値を指定することを含む、［１］の方法。
［５］
前記仮説を生成することは、過去にデコードされたＭＡＰメッセージにおけるフィールドの値と、やがてデコードされる伝送において変化することが予測されるビットの数とに基づいて、１以上のビット値を指定することを含む、［１］の方法。
［６］
前記フィールドの前記値は単調に増加すると予測される、［５］の方法。
［７］
前記フィールドの前記値は前記オペレーションの間に変化されないと予測される、［５］の方法。
［８］
前記ＭＡＰメッセージはＵＬ−ＭＡＰメッセージであり、
前記仮説を生成することは、ＲＦ帯域幅及びフレーム持続時間の少なくとも一部によって決定されたＭＡＰメッセージ中のフィールドの値に基づいて、１以上のビット値を指定することを含む、［１］の方法。
［９］
前記メッセージはＲＮＧ−ＲＥＱメッセージであり、
前記仮説を生成することは、前記受信されたフィールドのいくつかが正確であるという仮定を用いて標準にしたがって固定されている値に基づいて、１つ以上のビット値を指定することを含む、［１］の方法。
［１０］
無線通信のための受信機において、
メッセージに対する無線伝送を受信し、エンコードされたビットのセットを生成するための受信機フロントエンドと、
前記メッセージに関する既知情報に基づいてエンコードされたデータビットのビット値のセットをそれぞれ指定する、１以上の仮説を生成するための仮説エンジンと、
検討から、前記仮説によって指定された前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、出力として、前記仮説の一つによって指定されたビット値と一致するデコードされたビットを選択することによって前記エンコードされたビットをデコードするために形成されたデコーダと
を具備する、受信機。
［１１］
前記メッセージはレンジリクエスト（ＲＮＧ−ＲＥＱ）メッセージ、帯域幅リクエスト（ＢＷ−ＲＥＱ）メッセージとのうちの少なくとも一つを具備する、［１０］の受信機。
［１２］
前記仮説エンジンは、ＲＮＧ−ＲＥＱメッセージに対応するビット値を指定する少なくとも一つの仮説及びＢＷ−ＲＥＱメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成されている、［１１］の受信機。
［１３］
前記メッセージは、アップリンクＭＡＰ（ＵＬ−ＭＡＰ）メッセージ、ノーマルダウンリンクＭＡＰ（ＤＬ−ＭＡＰ）メッセージ、圧縮されたＤＬ−ＭＡＰメッセージのうちの少なくとも一つを具備する、［１０］の受信機。
［１４］
前記仮説エンジンは、ノーマルＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説及び圧縮されたＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成される、［１３］の受信機。
［１５］
前記デコーダは、ノーマルＤＬ−ＭＡＰメッセージに対応するビット値を指定する前記仮説と圧縮されたＤＬ−ＭＡＰメッセージに対応するビット値を指定する前記仮説とに基づいて、前記エンコードされたビットを、並列にデコーディングするための少なくとも２つのデコーディング回路を具備する、［１４］の受信機。
［１６］
前記メッセージが成功裡にデコードされていないが、前記メッセージのＭＡＣヘッダが成功裡にデコードされたか、決定し、
成功裡にデコードされたＭＡＣヘッダに対応するビット値を指定するために前記仮説を更新するように、前記仮説エンジンに合図し、
検討から、前記更新された仮説によって指示される前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、出力として、前記更新された仮説によって指定されたビット値と一致するデコードされたビットを選択することによって前記エンデコードされたビットをデコードするように、前記デコーダに合図する
ために形成されるロジックをさらに具備する、［１０］の受信機。
［１７］
前記仮説エンジンを生成することは、標準にしたがってすべての時間で固定されている値に基づいて１以上のビット値を指定することによって少なくとも一つの仮説を生成するために形成されている、［１０］の方法。
［１８］
前記仮説エンジンは、過去にデコードされたメッセージにおけるフィールドの値及びやがてデコードされる伝送において変化すると予測されるビットの数に基づいて、１以上のビット値を指定することによって少なくとも一つの仮説を生成するために形成されている、［１０］の受信機。
［１９］
前記フィールドの前記値は単調に増加すると予測される、［１８］の受信機。
［２０］
前記フィールドの前記値は前記オペレーションの間に変化されないと予測される、［１８］の方法。
［２１］
前記メッセージはＵＬ−ＭＡＰメッセージであり、
前記仮説エンジンは、ＲＦ帯域幅及びフレーム持続時間の少なくとも一部によって決定されたＭＡＰメッセージ中のフィールドの値に基づいて、１以上のビット値を指定することによって少なくとも一つの仮説を生成するように形成されている、［１０］の受信機。
［２２］
無線通信のための装置において、
メッセージに対する無線伝送を受信し、エンコードされたビットのセットを生成する手段と、
前記メッセージに関する既知情報に基づいて前記エンコードされたデータビットのビット値のセットをそれぞれ指定する、１以上の仮説を生成する手段と、
検討から、前記仮説によって指定された前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、出力として、前記仮説の一つによって指定されたビット値と一致するデコードされたビットを選択することによってエンコードされたビットをデコードする手段と
を具備する、装置。
［２３］
前記メッセージは、レンジリクエスト（ＲＮＧ−ＲＥＱ）メッセージ、帯域幅リクエスト（ＢＷ−ＲＥＱ）メッセージとのうちの少なくとも一つを具備し、
前記１以上の仮説を生成する手段は、ＲＮＧ−ＲＥＱメッセージに対応するビット値を指定する少なくとも一つの仮説及びＢＷ−ＲＥＱメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成されている、［２２］の装置。
［２４］
前記メッセージは、アップリンクＭＡＰ（ＵＬ−ＭＡＰ）メッセージ、ノーマルダウンリンクＭＡＰ（ＤＬ−ＭＡＰ）メッセージ、圧縮されたＤＬ−ＭＡＰメッセージのうちの少なくとも一つを具備する、［２２］の装置。
［２５］
前記仮説を生成する手段は、ノーマルＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説及び圧縮されたＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成される、［２４］の装置。
［２６］
前記メッセージが成功裡にデコードされていないが、前記メッセージのＭＡＣヘッダが成功裡にデコードされたか、決定する手段と、
成功裡にデコードされたＭＡＣヘッダに対応するビット値を指定するために前記仮説を更新するように、前記仮説を生成する手段に合図する手段と、
検討から、前記更新された仮説によって指定される前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、出力として、前記更新された仮説によって指定されたビット値と一致するデコードされたビットを選択することによって前記エンデコードされたビットをデコードするように、前記デコードする手段に合図する手段と
をさらに具備する、［２２］の装置。
［２７］
移動装置において、
ＭＡＰメッセージに対する無線伝送を受信し、エンコードされたビットのセットを生成するための受信機フロントエンドと、
前記ＭＡＰメッセージの内容又は過去にデコードされたＭＡＰメッセージとのうちの少なくとも一つに関する既知情報に基づいて前記エンコードされたデータビットのビット値のセットをそれぞれ指定する、１以上の仮説を生成するための仮説エンジンと、
検討から、前記仮説によって指定された前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、出力として、前記仮説の一つによって指定されたビット値と一致するデコードされたビットを選択することによって前記エンコードされたビットをデコードするために形成されたデコーダと
を具備する、移動装置。
［２８］
前記ＭＡＰメッセージは、ノーマルダウンリンクＭＡＰ（ＤＬ−ＭＡＰ）メッセージと圧縮されたＤＬ−ＭＡＰメッセージとのうちの少なくとも一つを具備する、［２７］の移動装置。
［２９］
前記仮説エンジンは、ノーマルＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説及び圧縮されたＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成され、
前記デコーダは、ノーマルＤＬ−ＭＡＰメッセージに対応するビット値を指定する前記仮説と圧縮されたＤＬ−ＭＡＰメッセージに対応するビット値を指定する前記仮説とに基づいて、前記エンコードされたビットを、並列にデコーディングするための少なくとも２つのデコーディング回路を具備する、［２７］の移動装置。
［３０］
前記ＭＡＣメッセージが成功裡にデコードされていないが、前記ＭＡＣメッセージのＭＡＣヘッダが成功裡にデコードされたか、決定し、
成功裡にデコードされたＭＡＣヘッダに対応するビット値を指定するために前記仮説を更新するように、前記仮説エンジンに合図し、
検討から、前記更新された仮説によって指定される前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、出力として、前記更新された仮説によって指定されたビット値と一致するデコードされたビットを選択することによって前記デコードされたビットをデコードするように、前記デコーダに合図する
ために形成されるロジックをさらに具備する、［２７］の移動装置。
［３１］
記憶された命令のセットを持つコンピュータ読み取り可能媒体を具備する無線通信のためのコンピュータプログラム製品において、前記命令のセットは１以上のプロセッサによって実行可能であり、前記命令のセットは、
メッセージに対する無線伝送を受信し、エンコードされたビットのセットを生成する命令と、
前記メッセージに関する既知情報に基づいてエンコードされたデータビットのビット値のセットをそれぞれ指定する、１以上の仮説を生成する命令と、
検討から、前記仮説によって指定された前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、出力として、前記仮説の一つによって指定されたビット値と一致するデコードされたビットを選択することによって前記エンコードされたビットをデコードする命令と
を具備する、コンピュータプログラム製品。
［３２］
前記メッセージは、レンジリクエスト（ＲＮＧ−ＲＥＱ）メッセージ、帯域幅リクエスト（ＢＷ−ＲＥＱ）メッセージとのうちの少なくとも一つを具備し、
前記１以上の仮説を生成する命令は、ＲＮＧ−ＲＥＱメッセージに対応するビット値を指定する少なくとも一つの仮説及びＢＷ−ＲＥＱメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成されている、［３１］のコンピュータプログラム製品。
［３３］
前記メッセージは、アップリンクＭＡＰ（ＵＬ−ＭＡＰ）メッセージ、ノーマルダウンリンクＭＡＰ（ＤＬ−ＭＡＰ）メッセージ、圧縮されたＤＬ−ＭＡＰメッセージのうちの少なくとも一つを具備する、［３１］のコンピュータプログラム製品。
［３４］
仮説を生成する前記命令は、ノーマルＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説及び圧縮されたＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成される、［３３］のコンピュータプログラム製品。
［３５］
前記メッセージが成功裡にデコードされていないが、前記メッセージのＭＡＣヘッダが成功裡にデコードされたか、決定する命令と、
成功裡にデコードされたＭＡＣヘッダに対応するビット値を指定するために前記仮説を更新するように、前記仮説を生成する命令に合図する命令と、
検討から、前記更新された仮説によって指定される前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、出力として、前記更新された仮説によって指定されたビット値と一致するデコードされたビットを選択することによって前記エンデコードされたビットをデコードするように、前記デコードする命令に合図する命令と
をさらに具備する、［３１］のコンピュータプログラム製品。

Claims (30)

  1. メッセージに対する無線通信伝送のエンコードされたデータビットをデコーディングするための方法において、
    モバイルアプリケーションパート（ＭＡＰ）メッセージの内容及び関連する伝送のパラメータ：のうちの少なくとも一つに関する既知情報に基づいて前記エンコードされたデータビットのビット値のセットを指定する仮説を生成すること、
    前記指定されたビット値と不一致のデコードされたビットのセットを除去すること、及び、前記仮説によって指定された前記ビット値と一致するデコードされたビットを選択することによって伝送をデコーディングすること、
    前記メッセージが成功裡にデコードされていないことを決定すること、
    前記メッセージのＭＡＣヘッダが成功裡にデコードされていることを決定すること、
    前記成功裡にデコードされたＭＡＣヘッダのビット値を指定するために前記仮説を更新すること、
    前記指定されたビット値と不一致のデコードされたビットのセットを除去すること、及び、前記仮説によって指定された前記ビット値と一致するデコードされたビットを選択することによって伝送を再びデコーディングすること、
    を含む、方法。
  2. 請求項１の方法において、
    ＭＡＰメッセージは、ノーマルダウンリンクモバイルアプリケーションパート（ノーマルＤＬ−ＭＡＰ）メッセージ、圧縮されたダウンリンクモバイルアプリケーションパート（圧縮されたＤＬ−ＭＡＰ）メッセージ、アップリンクモバイルアプリケーションパート（ＵＬ−ＭＡＰ）メッセージ、レンジリクエスト（ＲＮＧ−ＲＥＱ）メッセージ、及び帯域幅リクエスト（ＢＷ−ＲＥＱ）メッセージのうちの少なくとも一つを含む、方法。
  3. 請求項１の方法において、
    前記仮説を生成することは、標準にしたがってすべての時間で固定されている値に基づいて１以上のビット値を指定することを含む、方法。
  4. 請求項１の方法において、
    前記仮説を生成することは、過去にデコードされたＭＡＰメッセージにおけるフィールドの値と、やがてデコードされる伝送において変化することが予測されるビットの数とに基づいて、１以上のビット値を指定することを含む、方法。
  5. 請求項４の方法において、前記フィールドの前記値は単調に増加すると予測される、方法。
  6. 請求項４の方法において、前記フィールドの前記値はオペレーションの間に変化されないと予測される、方法。
  7. 請求項１の方法において、
    前記ＭＡＰメッセージはアップリンクモバイルアプリケーションパート（ＵＬ−ＭＡＰ）メッセージであり、
    前記仮説を生成することは、ＲＦ帯域幅及びフレーム持続時間の少なくとも一部によって決定されたＭＡＰメッセージ中のフィールドの値に基づいて、１以上のビット値を指定することを含む、方法。
  8. 請求項１の方法において、
    前記メッセージはレンジリクエスト（ＲＮＧ−ＲＥＱ）メッセージであり、
    前記仮説を生成することは、前記受信されたフィールドのいくつかが正確であるという仮定を用いて標準にしたがって固定されている値に基づいて、１つ以上のビット値を指定することを含む、方法。
  9. 無線通信のための受信機において、
    メッセージに対する無線伝送を受信し、エンコードされたビットのセットを生成するための受信機フロントエンドと、
    前記メッセージに関する既知情報に基づいて前記エンコードされたデータビットのビット値のセットをそれぞれ指定する、１以上の仮説を生成するための仮説エンジンと、
    前記仮説によって指定された前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、前記仮説の一つによって指定されたビット値と一致するデコードされたビットを選択することによって前記エンコードされたビットをデコードし；
    前記メッセージが成功裡にデコードされていないが、前記メッセージのＭＡＣヘッダが成功裡にデコードされたか、決定し；
    成功裡にデコードされたＭＡＣヘッダに対応するビット値を指定するための前記仮説を更新するように、前記仮説エンジンに合図し；
    前記更新された仮説によって指定される前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、前記更新された仮説によって指定されたビット値と一致するデコードされたビットを選択することによって前記エンデコードされたビットをデコードする；
    ために形成されたデコーダと
    を具備する、受信機。
  10. 請求項９の受信機において、前記メッセージはレンジリクエスト（ＲＮＧ−ＲＥＱ）メッセージ、帯域幅リクエスト（ＢＷ−ＲＥＱ）メッセージとのうちの少なくとも一つを具備する、受信機。
  11. 請求項１０の受信機において、
    前記仮説エンジンは、ＲＮＧ−ＲＥＱメッセージに対応するビット値を指定する少なくとも一つの仮説及びＢＷ−ＲＥＱメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成されている、受信機。
  12. 請求項９の受信機において、
    前記メッセージは、アップリンクモバイルアプリケーションパート（ＵＬ−ＭＡＰ）メッセージ、ノーマルダウンリンクモバイルアプリケーションパート（ノーマルＤＬ−ＭＡＰ）メッセージ、圧縮されたダウンリンクモバイルアプリケーションパート（圧縮されたＤＬ−ＭＡＰ）メッセージのうちの少なくとも一つを具備する、受信機。
  13. 請求項１２の受信機において、
    前記仮説エンジンは、ノーマルＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説及び圧縮されたＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成される、受信機。
  14. 請求項１３の受信機において、
    前記デコーダは、ノーマルＤＬ−ＭＡＰメッセージに対応するビット値を指定する前記仮説と圧縮されたＤＬ−ＭＡＰメッセージに対応するビット値を指定する前記仮説とに基づいて、前記エンコードされたビットを、並列にデコーディングするための少なくとも２つのデコーディング回路を具備する、受信機。
  15. 請求項９の受信機において、
    前記仮説エンジンを生成することは、標準にしたがってすべての時間で固定されている値に基づいて１以上のビット値を指定することによって少なくとも一つの仮説を生成するために形成されている、受信機。
  16. 請求項９の受信機において、
    前記仮説エンジンは、過去にデコードされたメッセージにおけるフィールドの値及びやがてデコードされる伝送において変化すると予測されるビットの数に基づいて、１以上のビット値を指定することによって少なくとも一つの仮説を生成するために形成されている、受信機。
  17. 請求項１６の受信機において、前記フィールドの前記値は単調に増加すると予測される、受信機。
  18. 請求項１６の受信機において、前記フィールドの前記値は前記オペレーションの間に変化されないと予測される、受信機。
  19. 請求項９の受信機において、
    前記メッセージはアップリンクモバイルアプリケーションパート（ＵＬ−ＭＡＰ）メッセージであり、
    前記仮説エンジンは、ＲＦ帯域幅及びフレーム持続時間の少なくとも一部によって決定されたＭＡＰメッセージ中のフィールドの値に基づいて、１以上のビット値を指定することによって少なくとも一つの仮説を生成するように形成されている、受信機。
  20. 無線通信のための装置において、
    メッセージに対する無線伝送を受信し、エンコードされたビットのセットを生成する手段と、
    前記メッセージに関する既知情報に基づいて前記エンコードされたデータビットのビット値のセットをそれぞれ指定する、１以上の仮説を生成する手段と、
    前記仮説によって指定された前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、前記仮説の一つによって指定されたビット値と一致するデコードされたビットを選択することによって前記エンコードされたビットをデコードする手段と、
    前記メッセージが成功裡にデコードされていないが、前記メッセージのＭＡＣヘッダが成功裡にデコードされたか、決定する手段と、
    成功裡にデコードされたＭＡＣヘッダに対応するビット値を指定するための前記仮説を更新するように、前記仮説を生成する手段に合図する手段と、
    前記更新された仮説によって指定される前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、前記更新された仮説によって指定されたビット値と一致するデコードされたビットを選択することによって前記エンデコードされたビットをデコードするように、前記デコードする手段に合図する手段と
    を具備する、装置。
  21. 請求項２０の装置において、
    前記メッセージは、レンジリクエスト（ＲＮＧ−ＲＥＱ）メッセージ、帯域幅リクエスト（ＢＷ−ＲＥＱ）メッセージとのうちの少なくとも一つを具備し、
    前記１以上の仮説を生成する手段は、ＲＮＧ−ＲＥＱメッセージに対応するビット値を指定する少なくとも一つの仮説及びＢＷ−ＲＥＱメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成されている、装置。
  22. 請求項２０の装置において、
    前記メッセージは、アップリンクモバイルアプリケーションパート（ＵＬ−ＭＡＰ）メッセージ、ノーマルダウンリンクモバイルアプリケーションパート（ノーマルＤＬ−ＭＡＰ）メッセージ、圧縮されたモバイルアプリケーションパート（圧縮されたＤＬ−ＭＡＰ）メッセージのうちの少なくとも一つを具備する、装置。
  23. 請求項２２の装置において、
    前記仮説を生成する手段は、ノーマルＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説及び圧縮されたＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成される、装置。
  24. 移動装置において、
    モバイルアプリケーションパート（ＭＡＰ）メッセージに対する無線伝送を受信し、エンコードされたビットのセットを生成するための受信機フロントエンドと、
    前記ＭＡＰメッセージの内容又は過去にデコードされたＭＡＰメッセージとのうちの少なくとも一つに関する既知情報に基づいて前記エンコードされたデータビットのビット値のセットをそれぞれ指定する、１以上の仮説を生成するための仮説エンジンと、
    前記仮説によって指定された前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、前記仮説の一つによって指定されたビット値と一致するデコードされたビットを選択することによって前記エンコードされたビットをデコードするために形成されたデコーダと
    を具備し、
    前記ＭＡＣメッセージが成功裡にデコードされていないが、前記ＭＡＣメッセージのＭＡＣヘッダが成功裡にデコードされたか、決定し、
    成功裡にデコードされたＭＡＣヘッダに対応するビット値を指定するために前記仮説を更新するように、前記仮説エンジンに合図し、
    前記更新された仮説によって指定される前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、前記更新された仮説によって指定されたビット値と一致するデコードされたビットを選択することによって前記デコードされたビットをデコードするように、前記デコーダに合図する、移動装置。
  25. 請求項２４の移動装置において、
    前記ＭＡＰメッセージは、ノーマルダウンリンクモバイルアプリケーションパート（ノーマルＤＬ−ＭＡＰ）メッセージと圧縮されたダウンリンクモバイルアプリケーションパート（圧縮されたＤＬ−ＭＡＰ）メッセージとのうちの少なくとも一つを具備する、移動装置。
  26. 請求項２４の移動装置において、
    前記仮説エンジンは、ノーマルダウンリンクモバイルアプリケーションパート（ノーマルＤＬ−ＭＡＰ）メッセージに対応するビット値を指定する少なくとも一つの仮説及び圧縮されたダウンリンクモバイルアプリケーションパート（圧縮されたＤＬ−ＭＡＰ）メッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成され、
    前記デコーダは、ノーマルＤＬ−ＭＡＰメッセージに対応するビット値を指定する前記仮説と圧縮されたＤＬ−ＭＡＰメッセージに対応するビット値を指定する前記仮説とに基づいて、前記エンコードされたビットを、並列にデコーディングするための少なくとも２つのデコーディング回路を具備する、移動装置。
  27. 命令のセットを具備する無線通信のためのコンピュータ読み取り可能記憶媒体において、前記命令のセットは１以上のプロセッサによって実行可能であり、前記命令のセットは、
    メッセージに対する無線伝送を受信し、エンコードされたビットのセットを生成する命令と、
    前記メッセージに関する既知情報に基づいて前記エンコードされたデータビットのビット値のセットをそれぞれ指定する、１以上の仮説を生成する命令と、
    前記仮説によって指定された前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、前記仮説の一つによって指定されたビット値と一致するデコードされたビットを選択することによって前記エンコードされたビットをデコードする命令と、
    前記メッセージが成功裡にデコードされていないが、前記メッセージのＭＡＣヘッダが成功裡にデコードされたか、決定する命令と、
    成功裡にデコードされたＭＡＣヘッダに対応するビット値を指定するために前記仮説を更新するように、前記仮説を生成する命令に合図する命令と、
    前記更新された仮説によって指定される前記ビット値と一致しないデコードされたビットのセットを除去すること、及び、前記更新された仮説によって指定されたビット値と一致するデコードされたビットを選択することによって前記エンデコードされたビットをデコードするように、前記デコードする命令に合図する命令と
    を具備する、コンピュータ読み取り可能記憶媒体。
  28. 請求項２７のコンピュータ読み取り可能記憶媒体において、
    前記メッセージは、レンジリクエスト（ＲＮＧ−ＲＥＱ）メッセージ、帯域幅リクエスト（ＢＷ−ＲＥＱ）メッセージとのうちの少なくとも一つを具備し、
    前記１以上の仮説を生成する命令は、ＲＮＧ−ＲＥＱメッセージに対応するビット値を指定する少なくとも一つの仮説及びＢＷ−ＲＥＱメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成されている、コンピュータ読み取り可能記憶媒体。
  29. 請求項２７のコンピュータ読み取り可能記憶媒体において、
    前記メッセージは、アップリンクモバイルアプリケーションパート（ＵＬ−ＭＡＰ）メッセージ、ノーマルダウンリンクモバイルアプリケーションパート（ノーマルＤＬ−ＭＡＰ）メッセージ、圧縮されたダウンリンクモバイルアプリケーションパート（圧縮されたＤＬ−ＭＡＰ）メッセージのうちの少なくとも一つを具備する、コンピュータ読み取り可能記憶媒体。
  30. 請求項２９のコンピュータ読み取り可能記憶媒体において、
    仮説を生成する前記命令は、ノーマルＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説及び圧縮されたＤＬ−ＭＡＰメッセージに対応するビット値を指定する少なくとも一つの仮説を生成するために形成される、コンピュータ読み取り可能記憶媒体。
JP2010542222A 2008-01-07 2008-07-17 チャネルｍａｐメッセージの既知情報を用いたチャネルデコーディング Expired - Fee Related JP5185395B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/970,373 2008-01-07
US11/970,373 US8392811B2 (en) 2008-01-07 2008-01-07 Methods and systems for a-priori decoding based on MAP messages
PCT/US2008/070385 WO2009088535A1 (en) 2008-01-07 2008-07-17 Channel decoding with a-priori information on channel-map messages

Publications (2)

Publication Number Publication Date
JP2011509633A JP2011509633A (ja) 2011-03-24
JP5185395B2 true JP5185395B2 (ja) 2013-04-17

Family

ID=39870548

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010542222A Expired - Fee Related JP5185395B2 (ja) 2008-01-07 2008-07-17 チャネルｍａｐメッセージの既知情報を用いたチャネルデコーディング

Country Status (9)

Country Link
US (1) US8392811B2 (ja)
EP (1) EP2243223A1 (ja)
JP (1) JP5185395B2 (ja)
KR (1) KR101250873B1 (ja)
CN (1) CN101911509A (ja)
CA (1) CA2710493A1 (ja)
RU (1) RU2454795C2 (ja)
TW (1) TWI373226B (ja)
WO (1) WO2009088535A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011526437A (ja) * 2008-06-19 2011-10-06 クゥアルコム・インコーポレイテッド 既知情報を使用してフレームを復号化するパフォーマンスを向上するための方法とシステム

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8392811B2 (en) * 2008-01-07 2013-03-05 Qualcomm Incorporated Methods and systems for a-priori decoding based on MAP messages
WO2010001454A1 (ja) * 2008-06-30 2010-01-07 富士通株式会社 無線リソースの割り当て方法、基地局、移動局
US8902828B2 (en) 2009-10-05 2014-12-02 Qualcomm Incorporated Carrier indicator field for cross carrier assignments
US20110124289A1 (en) * 2009-11-20 2011-05-26 Krishna Balachandran Opportunistic Network Interference Cancellation For Wireless Networks
WO2011100583A2 (en) * 2010-02-12 2011-08-18 Yitran Communications Ltd. Digital communication system for use in high noise channels
US8478258B2 (en) * 2010-03-05 2013-07-02 Intel Corporation Techniques to reduce false detection of control channel messages in a wireless network
US8340004B2 (en) * 2010-04-07 2012-12-25 Qualcomm Incorporated Combining transmission with incrementing fields
JP2012165040A (ja) * 2011-02-03 2012-08-30 Sharp Corp 受信装置、受信方法、通信システムおよび通信方法
CN108055110A (zh) * 2012-12-18 2018-05-18 华为技术有限公司 用于先验解码的系统和方法
US8824598B2 (en) * 2012-12-18 2014-09-02 Telefonaktiebolaget L M Ericsson (Publ) System and method for communicating information in a wireless network
EP3039788B1 (en) * 2013-08-29 2021-07-07 Harman International Industries, Incorporated Soft decision decoding method and system thereof
WO2015149868A1 (en) * 2014-04-04 2015-10-08 Telefonaktiebolaget L M Ericsson (Publ) Method and node for improving error rate performance based on packet header information
US10498662B2 (en) * 2015-12-29 2019-12-03 Ondas Networks Inc. System and method for automatic packet field supression in broadband wireless communications systems
US11146356B2 (en) * 2017-05-12 2021-10-12 Telefonaktiebolaget Lm Ericsson (Publ) Adaptive CRC length for beam sweeping
CN110612669B (zh) * 2017-05-24 2021-07-09 华为技术有限公司 译码的方法和装置
CN113709700B (zh) * 2020-05-21 2024-03-26 中信科智联科技有限公司 一种地图数据的处理方法、装置及设备

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5721745A (en) * 1996-04-19 1998-02-24 General Electric Company Parallel concatenated tail-biting convolutional code and decoder therefor
US5721746A (en) * 1996-04-19 1998-02-24 General Electric Company Optimal soft-output decoder for tail-biting trellis codes
JP3205723B2 (ja) * 1997-12-12 2001-09-04 松下電器産業株式会社 Ｃｄｍａ用データ伝送方法及び装置
CN1134131C (zh) 1999-07-22 2004-01-07 西门子公司 数据比特流的差错保护方法
US6608828B1 (en) 1999-09-15 2003-08-19 Ericsson Inc. Methods and systems for decoding headers that are repeatedly transmitted and received along with data on a radio channel
US20040022181A1 (en) * 2002-08-05 2004-02-05 Coffey John T. Pseudo-bit-loading for enhanced performance with standards-compliant air interface for multi-tone wireless lans
GB2400002A (en) 2003-03-27 2004-09-29 Tandberg Television Asa Decoding a concatenated convolutional and block encoded signal by marking known correct bits
US8046662B2 (en) * 2004-08-20 2011-10-25 Broadcom Corporation Method and system for decoding control data in GSM-based systems using inherent redundancy
CA2545950C (en) * 2005-05-06 2013-10-01 Her Majesty The Queen In Right Of Canada, As Represented By The Minister Of Industry Through The Communications Research Centre Canada Iterative non-coherent cpm decoder
US8155247B2 (en) * 2005-08-16 2012-04-10 Telefonaktiebolaget L M Ericsson (Publ) Message decoding with a priori information and soft combining
KR101216079B1 (ko) * 2005-11-30 2012-12-26 엘지전자 주식회사 디지털 방송 시스템 및 처리 방법
US7730385B2 (en) * 2005-11-30 2010-06-01 Motorola, Inc. Method for decoding a received control channel message with a priori information
US7797607B2 (en) * 2005-12-27 2010-09-14 Lg Electronics, Inc. DTV transmitter and method of coding main and enhanced data in DTV transmitter
US7587005B2 (en) * 2006-03-28 2009-09-08 Research In Motion Limited Exploiting known padding data to improve block decode success rate
CN101449465B (zh) 2006-06-01 2015-07-15 艾利森电话股份有限公司 与信道解码有关的方法和设备
KR20080012434A (ko) * 2006-08-03 2008-02-12 삼성전자주식회사 입력 메시지의 특성을 고려한 복호 장치 및 방법
GB0619769D0 (en) * 2006-10-06 2006-11-15 Siemens Ag Variable length coding
US8027284B2 (en) * 2006-11-27 2011-09-27 Ntt Docomo, Inc. Method and apparatus for reliable multicasting in wireless relay networks
KR101048456B1 (ko) * 2007-10-16 2011-07-11 삼성전자주식회사 무선 접속 통신 시스템에서 셀 부하 예측 장치 및 방법
US8259866B2 (en) * 2008-01-04 2012-09-04 Qualcomm Incorporated Decoding scheme using A-priori information about transmitted messages
US8000411B2 (en) 2008-01-04 2011-08-16 Qualcomm Incorporated Decoding scheme using multiple hypotheses about transmitted messages
US8392811B2 (en) * 2008-01-07 2013-03-05 Qualcomm Incorporated Methods and systems for a-priori decoding based on MAP messages
WO2009131416A2 (en) * 2008-04-25 2009-10-29 Samsung Electronics Co., Ltd. Apparatuses and methods for providing emergency service in a wireless communication system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011526437A (ja) * 2008-06-19 2011-10-06 クゥアルコム・インコーポレイテッド 既知情報を使用してフレームを復号化するパフォーマンスを向上するための方法とシステム

Also Published As

Publication number Publication date
KR101250873B1 (ko) 2013-04-04
WO2009088535A1 (en) 2009-07-16
RU2010133230A (ru) 2012-02-20
KR20100114065A (ko) 2010-10-22
EP2243223A1 (en) 2010-10-27
CN101911509A (zh) 2010-12-08
US8392811B2 (en) 2013-03-05
RU2454795C2 (ru) 2012-06-27
JP2011509633A (ja) 2011-03-24
TW200931860A (en) 2009-07-16
US20090177951A1 (en) 2009-07-09
TWI373226B (en) 2012-09-21
CA2710493A1 (en) 2009-07-16

Similar Documents

Publication Publication Date Title
JP5185395B2 (ja) チャネルｍａｐメッセージの既知情報を用いたチャネルデコーディング
US8000411B2 (en) Decoding scheme using multiple hypotheses about transmitted messages
TW201803280A (zh) 利用分段式的冗餘校驗對控制訊號傳遞進行編碼和解碼
US8259866B2 (en) Decoding scheme using A-priori information about transmitted messages
US8259867B2 (en) Methods and systems for turbo decoding in a wireless communication system
EP2599228B1 (en) Decoding techniques for tail-biting codes
US8726138B2 (en) Methods and systems for modified maximum-likelihood based TBCC decoding
TW201843942A (zh) 編解碼方法及其解碼器
EP2567463B1 (en) Technique for processing encoded information in a wireless communication network

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120809

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120821

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121121

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20121218

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130117

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160125

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees