(57)【要約】情報のパケットは、制御レイヤおよびストリーム・レイヤを含む第１の部分（４００）と、物理レイヤおよびＭＡＣレイヤを含む第２の部分（４０１）と、を有するプロトコル・スタックにしたがって情報パケットが受信される。第２の部分はまた、到来パケットのグループと、それぞれに関連付けられた誤りステータスとを保持する。第１の部分は、到来パケットのうちの少なくとも１つに関する動作を実行するように第２の部分に指示するアプリケーション・プログラミング・インタフェース（ＡＰＩ１３０１、１３０２、１４０１、１４０２）を起動する。この動作は、パケットに関連付けられた誤りステータスに関連している。
2010526520.tif 000002
【特許請求の範囲】
【請求項１】
物理レイヤ、ＭＡＣレイヤ、制御レイヤ、およびストリーム・レイヤを含むプロトコル・スタックにしたがって情報のパケットを受信するように構成された装置であって、
前記制御レイヤおよびストリーム・レイヤを提供するように構成された受信機スタック処理システムと、
前記物理レイヤおよびＭＡＣレイヤを提供するように構成され、さらに、到来パケットのグループと、それぞれに関連付けられた誤りステータスとを保持するように構成されたメディア処理システムと、
前記受信機スタック処理システムと前記メディア処理システムとの間の通信をサポートする少なくとも１つのアプリケーション・プログラム・インタフェース（ＡＰＩ）とを備え、
前記受信機スタック処理システムは、前記到来パケットのうちの少なくとも１つに関連する動作を実行するように前記メディア処理システムに指示するために、前記少なくとも１つのＡＰＩを起動するように構成され、
前記動作は、前記少なくとも１つのパケットに関連付けられた誤りステータスに関連している装置。
【請求項２】
前記動作は、前記少なくとも１つのパケットに関連付けられた誤りステータスを、前記受信機スタック処理システムに報告することを含む請求項１に記載の装置。
【請求項３】
前記受信機スタック処理システムはさらに、前記少なくとも１つのパケットに関連付けられた誤りの報告に応答して、別のＡＰＩを起動するように構成され、
前記別のＡＰＩはさらに、前記メディア処理システムに対して、前記１つのパケットを破棄するように指示する請求項２に記載の装置。
【請求項４】
前記受信機スタック処理システムは、前記少なくとも１つのパケットに関連付けられた誤りの報告に応答して、別のＡＰＩを起動するように構成され、
前記別のＡＰＩはさらに、前記メディア処理システムに対して、前記パケットのグループを破棄するように指示する請求項２に記載の装置。
【請求項５】
前記動作は、前記少なくとも１つのパケットを破棄することを含む請求項１に記載の装置。
【請求項６】
前記動作は、前記パケットのグループを破棄することを含む請求項１に記載の装置。
【請求項７】
物理レイヤ、ＭＡＣレイヤ、制御レイヤ、およびストリーム・レイヤを含むプロトコル・スタックにしたがって情報のパケットを受信するように構成された装置であって、
前記制御レイヤおよびストリーム・レイヤを提供する第１の処理手段と、
前記物理レイヤおよびＭＡＣレイヤを提供し、さらに、到来パケットのグループと、それぞれに関連付けられた誤りステータスとを保持する第２の処理手段と、
前記第１の処理手段と前記第２の処理手段との間の通信をサポートする少なくとも１つのアプリケーション・プログラム・インタフェース（ＡＰＩ）を提供する手段とを備え、
前記第１の処理手段は、前記到来パケットのうちの少なくとも１つに関連する動作を実行するように前記第２の処理手段に指示するために、前記少なくとも１つのＡＰＩを起動する手段を含み、
前記動作は、前記少なくとも１つのパケットに関連付けられた誤りステータスに関連している装置。
【請求項８】
前記動作は、前記少なくとも１つのパケットに関連付けられた誤りステータスを、前記受信機スタック処理システムに報告することを含む請求項７に記載の装置。
【請求項９】
前記第１の処理手段は、前記少なくとも１つのパケットに関連付けられた誤りの報告に応答して、別のＡＰＩを起動する手段を含み、
前記別のＡＰＩはさらに、前記第２の処理手段に対して、前記１つのパケットを破棄するように指示する請求項８に記載の装置。
【請求項１０】
前記第１の処理手段は、前記少なくとも１つのパケットに関連付けられた誤りの報告に応答して、別のＡＰＩを起動する手段を含み、
前記別のＡＰＩはさらに、前記第２の処理手段に対して、前記パケットのグループを破棄するように指示する請求項８に記載の装置。
【請求項１１】
前記動作は、前記少なくとも１つのパケットを破棄することを含む請求項７に記載の装置。
【請求項１２】
前記動作は、前記パケットのグループを破棄することを含む請求項７に記載の装置。
【請求項１３】
通信方法であって、
制御レイヤおよびストリーム・レイヤを含む第１の部分と、物理レイヤおよびＭＡＣレイヤを含み、到来パケットのグループ、およびそれぞれに関連付けられた誤りステータスを保持する第２の部分と、を有するプロトコル・スタックにしたがって情報のパケットを受信することを備え、
前記第１の部分は、前記到来パケットのうちの少なくとも１つに関連する動作を実行するよう前記第２の部分に指示するためにアプリケーション・プログラミング・インタフェース（ＡＰＩ）を起動し、
前記動作は、前記少なくとも１つのパケットに関連付けられた誤りステータスに関連している方法。
【請求項１４】
前記動作は、前記少なくとも１つのパケットに関連付けられた誤りステータスを前記第１の部分に報告することを含む請求項１３に記載の方法。
【請求項１５】
前記少なくとも１つのパケットに関連付けられた誤りの報告に応答して、前記第１の部分が別のＡＰＩを起動することを含み、
前記別のＡＰＩは、前記少なくとも１つのパケットを破棄するように前記第２の部分に指示する請求項１４に記載の方法。
【請求項１６】
前記少なくとも１つのパケットに関連付けられた誤りの報告に応答して、前記第１の部分が、別のＡＰＩを起動することを含み、
前記別のＡＰＩは、前記第２の部分に対して、前記パケットのグループを破棄するように指示する請求項１４に記載の方法。
【請求項１７】
前記動作は、前記少なくとも１つのパケットを破棄することを含む請求項１３に記載の方法。
【請求項１８】
前記動作は、前記パケットのグループを破棄することを含む請求項１３に記載の方法。
【請求項１９】
装置中の１または複数のプロセッサによって実行可能な命令群を備えた機械読取可能媒体であって、
前記装置は、プロトコル・スタックにしたがって情報のパケットを受信するように構成され、
前記プロトコル・スタックは、物理レイヤおよびＭＡＣレイヤを含み、到来パケットのグループと、それぞれに関連付けられた誤りステータスとを保持するメディア処理システムを用いて実現され、
前記プロトコル・スタックは、制御レイヤおよびストリーム・レイヤを含み、受信機スタック処理システムによって実現され、
前記命令群はさらに、
前記受信機スタック処理システムを実現する受信機スタック・コード・セグメントと、
前記受信機スタック処理システムと前記メディア処理システムとの間の通信をサポートする少なくとも１つのアプリケーション・プログラミング・インタフェース（ＡＰＩ）を実現するアプリケーション・プログラミング・インタフェース・コード・セグメントとを備え、
前記受信機スタック処理システムは、前記到来パケットのうちの少なくとも１つに関連する動作を実行するように前記メディア処理システムに対して指示するために、前記少なくとも１つのＡＰＩを起動し、
前記動作は、前記少なくとも１つのパケットに関連付けられた誤りステータスに関連している機械読取可能媒体。
【請求項２０】
前記動作は、前記少なくとも１つのパケットに関連付けられた誤りステータスを、前記受信機スタック処理システムへ報告することを含む請求項１９に記載の機械読取可能媒体。
【請求項２１】
前記少なくとも１つのパケットに関連付けられた誤りの報告に応答して、前記受信機スタック処理システムが、別のＡＰＩを起動し、
前記別のＡＰＩは、前記メディア処理システムに対して、前記少なくとも１つのパケットを破棄するように指示する請求項２０に記載の機械読取可能媒体。
【請求項２２】
前記受信機スタック処理システムは、前記少なくとも１つのパケットに関連付けられた誤りの報告に応答して、別のＡＰＩを起動し、
前記別のＡＰＩは、前記メディア処理システムに対して、前記パケットのグループを破棄するように指示する請求項２０に記載の機械読取可能媒体。
【請求項２３】
前記動作は、前記少なくとも１つのパケットを破棄することを含む請求項１９に記載の機械読取可能媒体。
【請求項２４】
前記動作は、前記パケットのグループを破棄することを含む請求項１９に記載の機械読取可能媒体。
【発明の詳細な説明】
【優先権主張】
【０００１】
本願は、ともに本願の譲受人に譲渡され、本明細書に参照によって明確に組み込まれている同時係属中の米国特許仮出願６０／９１５，９２９号（２００７年５月３日出願）と６０／９１５，９３１号（２００７年５月４日出願）に対する優先権を主張する。
【同時係属中の特許出願に対する参照】
【０００２】
本願は、本願の譲受人に譲渡され、本明細書に参照によって明確に組み込まれている２００７年７月２５日に出願された同時係属中の米国特許出願１１／８２８，１６７号に対する優先権を主張する。
【技術分野】
【０００３】
本開示は、一般に、通信システムおよび方法に関し、さらに詳しくは、無線通信デバイスにおける受信機のためのアプリケーション・プログラミング・インタフェース（ＡＰＩ）に関する。
【背景技術】
【０００４】
フォワード・リンク・オンリー（ＦＬＯ）は、無線プロバイダの業界をリードするグループによって開発されたデジタル無線技術である。ＦＬＯ技術は、リアル・タイムのコンテンツ・ストリーミング・サービスおよびその他のデータ・サービスの両方のための高品質な受信を達成するために、符号化およびインタリーブにおける進化を利用する。ＦＬＯ技術は、電力消費量に妥協することなく、ロバストなモバイル性能および高い容量を提供しうる。この技術はまた、構成せねばならない送信機数を劇的に減らすことによって、マルチメディア・コンテンツを配信するネットワーク・コストをも低減する。さらに、ＦＬＯ技術ベースのマルチメディア・マルチキャストは、無線オペレータのセルラ・ネットワーク・データ・サービスと音声サービスとを提供し、３Ｇネットワークにおいて使用されるものと同じセルラ・モバイル端末へコンテンツを配信する。
【０００５】
今日、ＦＬＯ技術は、リアル・タイムのマルチメディア・コンテンツを生成し、このコンテンツを、さまざまなネットワークを介して極めて多くのモバイル加入者へブロードキャするために使用されている。これらモバイル加入者は一般に、ＦＬＯ受信機を使用している。これは、一般に「プロトコル・スタック」と称される多くの処理レイヤを備えたリファレンス・モデルを用いて概念的に説明される。おのおのの処理レイヤは、特定の機能を実行する１または複数のエンティティを含む。
【０００６】
ＦＬＯ受信機によって適用されるプロトコル・スタックの魅力的な特徴は、おのおののレイヤが自律しており、これによって、１つのレイヤによって実行される機能は、他のレイヤによって実行される機能と独立して実行されうることである。これによって、他のレイヤに悪影響を及ぼすことなく、１つのレイヤのためにＦＬＯ受信機が改良されるようになる。しかしながら、ＦＬＯ受信機内のレイヤ間のインタフェースを設計する場合、さまざまなチャレンジがある。マルチキャスト・サービスの効率的な受信に関するレイヤ間の効率的な通信は、常に、ＦＬＯ受信機の設計者の目標である。
【発明の概要】
【０００７】
情報のパケットは、制御レイヤおよびストリーム・レイヤを含む第１の部分と、物理レイヤおよびＭＡＣレイヤを含む第２の部分とを有するプロトコル・スタックにしたがって受信されうる。第２の部分はさらに、到来パケットのグループと、それぞれに関連付けられた誤りステータスとを保持する。第１の部分は、到来パケットのうちの少なくとも１つに関連する動作を実行するように第２の部分に指示するために、アプリケーション・プログラミング・インタフェース（ＡＰＩ）を起動する。この動作は、パケットに関連付けられた誤りステータスに関連している。
【図面の簡単な説明】
【０００８】
【図１】図１は、通信システムの例を例示する概念図である。
【図２】図２は、受信機のプロトコル・スタックの例を例示する概念図である。
【図３】図３は、さまざまな受信機と、図２のプロトコル・スタックに対する関係とを例示する概念図である。
【図４】図４は、受信機を動作させるコール・フローの例を例示する図である。
【図５】図５は、受信機を停止させるコール・フローの例を例示する図である。
【図６】図６は、受信機内の受信スタックによって特定の論理チャネルが要求される場合におけるコール・フローの例を例示する図である。
【図７】図７は、無線デバイスが、インフラストラクチャまたはネットワークの有効範囲領域から別へ移動する場合におけるコール・フローの例を例示する図である。
【図８】図８は、受信機が獲得基準を満たさない場合におけるコール・フローの例を例示する図である。
【図９】図９は、受信機がキャッシュ内の制御情報における最新値を検出した場合におけるコール・フローの例を例示する図である。
【図１０】図１０は、オーバヘッド情報をモニタするコール・フローの例を例示する図である。
【図１１】図１１は、ＡＳＩＣ特有のソフトウェア・ブロックのための周波数スキャン・リストを受信機内に設定するためのコール・フローの例を例示する図である。
【図１２】図１２は、プロトコル・スタックにしたがって信号を受信するように構成された装置の機能ブロック図である。
【図１３】図１３は、本発明の典型的な実施形態にしたがったコール・フローを例示する図である。
【図１４】図１４は、本発明の典型的な実施形態にしたがったコール・フローを例示する図である。
【発明を実施するための形態】
【０００９】
添付図面では、無線通信システムのさまざまな態様が、限定ではなく、一例によって例示されている。
【００１０】
添付図面に関連して以下に示す詳細説明は、本発明のさまざまな実施形態の説明として意図されており、本発明が実現される唯一の実施形態を表すことは意図されていない。この詳細説明は、本発明の完全な理解を与えることを目的とした具体的な詳細を含んでいる。しかしながら、本発明は、これら具体的な詳細なしでも実現されうることが当業者に明らかになるであろう。いくつかの事例では、本発明の概念を不明瞭にしないために、周知の構成および構成要素が、ブロック図形式で示される。
【００１１】
以下の詳細説明では、さまざまな概念が、ＦＬＯ技術に関して記載されよう。これらの概念は、本願によく適合するが、当業者であれば、これの概念は、他の技術にも同様に適用可能であることを容易に認識するであろう。したがって、ＦＬＯ技術に対するあらゆる参照は、これら概念が、幅広い応用を持つという理解の下、これら概念を例示することのみ意図されている。
【００１２】
図１は、マルチメディア・コンテンツを生成し、このコンテンツを、さまざまなネットワークを介して多くのモバイル加入者へブロードキャストする通信システム１００を示す。この通信システム１００は、任意の数のコンテンツ・プロバイダ１０２、コンテンツ・プロバイダ・ネットワーク１０４、ブロードキャスト・ネットワーク１０６、および無線アクセス・ネットワーク１０８を含む。通信システム１００はまた、マルチメディア・コンテンツを受信するためにモバイル加入者によって使用される多くのデバイス１１０とともに示される。これらデバイス１１０は、モバイル電話１１２、携帯情報端末（ＰＤＡ）１１４、およびラップトップ・コンピュータ１１６を含む。これらデバイス１１０は、通信システム１００における使用に適したデバイスのうちのほんの幾つかを例示するに過ぎない。図１では３つのデバイスしか示されていないが、当業者に理解されるように、実際には、通信システム１００における使用のために、任意の数の類似のデバイスまたは類似のタイプのデバイスが適していることが注目されるべきである。
【００１３】
コンテンツ・プロバイダ１０２は、通信システム１００内のモバイル加入者へ配信するためのコンテンツを提供する。このコンテンツは、ビデオ、オーディオ、マルチメディア・コンテンツ、クリップ、リアル・タイムおよび非リアル・タイムのコンテンツ、スクリプト、プログラム、データ、あるいはその他任意のタイプの適切なコンテンツを含みうる。コンテンツ・プロバイダ１０２は、広域配信あるいはローカル・エリア配信のために、コンテンツ・プロバイダ・ネットワークへコンテンツを提供する。
【００１４】
コンテンツ・プロバイダ・ネットワーク１０４は、配信用のコンテンツをモバイル加入者へ配信するように動作する有線ネットワークと無線ネットワークとの任意の組み合わせを備える。図１に例示する例では、コンテンツ・プロバイダ・ネットワーク１０４は、ブロードキャスト・ネットワーク１０６を介してコンテンツを配信する。ブロードキャスト・ネットワーク１０６は、高品質のコンテンツをブロードキャストするために設計された有線専用ネットワークと無線専用ネットワークとの任意の組み合わせを備える。これら専用ネットワークは、モバイル・デバイスへシームレスな有効範囲を提供するために、大規模な地理的領域にわたって分布しうる。一般に、この地理的領域は、それぞれが広域コンテンツおよびローカル・エリア・コンテンツへのアクセスを提供するセクタへ分割されよう。
【００１５】
コンテンツ・プロバイダ・ネットワーク１０４はまた、無線アクセス・ネットワーク１０８を介したコンテンツの配信のための（図示しない）コンテンツ・サーバをも含みうる。コンテンツ・サーバは、無線アクセス・ネットワーク１０８内の基地局コントローラ（ＢＳＣ）（図示せず）と通信する。ＢＳＣは、無線アクセス・ネットワーク１０８の地理的範囲に依存して、任意の数の基地トランシーバ局（ＢＴＳ）（図示せず）を管理および制御するために使用されうる。ＢＴＳは、さまざまなデバイス１１０のための広域およびローカル・エリアへのアクセスを提供する。
【００１６】
コンテンツ・プロバイダ１０２によってブロードキャストされたマルチメディア・コンテンツは、１または複数のサービスを含んでいる。サービスは、１または複数の独立したデータ構成要素の集合である。サービスの、独立したおのおののデータ構成要素は、フローと呼ばれる。例として、ケーブル・ニュース・サービスは、ビデオ・フロー、オーディオ・フロー、および制御フローの３つのフローを含むことができる。
【００１７】
サービスは、１または複数の論理チャネルによって搬送される。ＦＬＯアプリケーションでは、論理チャネルはしばしばマルチキャスト論理チャネル（ＭＬＣ）と称される。論理チャネルは、多数の論理サブ・チャネルに分割される。これら論理サブ・チャネルはストリームと呼ばれる。フローはおのおの、１つのストリームで搬送される。論理チャネルのコンテンツは、物理フレーム内のさまざまなネットワークを通して送信される。ＦＬＯアプリケーションでは、物理フレームはしばしばスーパフレームと称される。
【００１８】
図１に示されるさまざまなデバイス１１０へ物理フレームを送信するために使用されるエア・インタフェースは、具体的なアプリケーションおよび設計全体の制約に依存して変わりうる。一般に、ＦＬＯ技術を適用する通信システムは、直交周波数分割多重化（ＯＦＤＭ）を利用する。これはまた、デジタル・オーディオ・ブロードキャスト（ＤＡＢ）、地上デジタル・ビデオ・ブロードキャスト（ＤＶＢ−Ｔ）、および、地上統合サービス・デジタル・ブロードキャスト（ＩＳＤＢ−Ｔ）によっても利用される。ＯＦＤＭは、システム全体の帯域幅を複数（Ｍ個）のサブ・キャリアへ効率的に分割するマルチ・キャリア変調技術である。トーン、値域、周波数チャネル等とも称されるこれらサブ・キャリアは、直交性を与えるために、正確な周波数間隔で配置される。コンテンツは、サブ・キャリアおのおのの位相、振幅、およびその両方を調節することによって、サブ・キャリア上で変調されうる。一般に、直交フェーズ・シフト・キーイング（ＱＰＳＫ）または直交振幅変調（ＱＡＭ）が使用されるが、他の変調スキームもまた使用されうる。
【００１９】
図２は、図１に示すデバイス１１０のうちの１または複数で使用される受信機のためのプロトコル・スタック２００の例を例示する概念図である。プロトコル・スタックは、物理レイヤ２０２、媒体アクセス制御（ＭＡＣ）レイヤ２０４、ストリーム・プレーヤ２０６、制御レイヤ２０８、および多くの上部レイヤ２１０とともに示される。上部レイヤ２１０は、マルチメディア・コンテンツの圧縮を含み、マルチメディア・コンテンツへのアクセスを制御する、複数の機能を提供する。制御レイヤ２０８は、通信システムにおけるデバイスの動作を容易にする制御情報を処理するために使用される。受信機はまた、自己の制御情報と、通信システムの制御情報との同期を維持する制御レイヤを用いる。ストリーム・レイヤ２０６は、上部レイヤ・フローをストリームへ結合する。ストリーム・レイヤは、受信機のプロトコル・スタック２００内の制御レイヤと同じレベルにある。ＭＡＣレイヤ２０４は、論理チャネルに関連付けられた他のメディア・ストリームに属するパケットを多重化する。ＭＡＣレイヤ２０４は、物理レイヤ２０２を介した送受信のために使用される手順を規定する。物理レイヤは、エア・インタフェースのためのチャネル構造、周波数、電力出力変調、および符号化仕様を与える。
【００２０】
図３は、さまざまな受信機ブロックおよびそれらの図２のプロトコル・スタックに対する関係を例示する概念図である。この例において、受信機３００は、受信機ハードウェア・ブロック３０２、ホスト先行ブロック３０４、およびハードウェア・インタフェース・ブロック３０５を含む。受信機ハードウェア・ブロック３０２は、特定用途向けＩＣ（ＡＳＩＣ）として説明されるだろうが、特定のアプリケーションおよび全体的な設計要件に依存して、異なるハードウェア実装を有することもできる。ホスト・プロセッサ・ブロック３０４は、ドライバ・ブロック３０６（ハードウェア特有の抽象レイヤ）、ＡＳＩＣ特有ソフトウェア・ブロック３０８、および受信機スタック・ブロック３１２を備えて示される。アプリケーション・プログラム・インタフェース（ＡＰＩ）３１０は、ＡＳＩＣ特有ソフトウェア・ブロック３０８を、受信機スタック・ブロック３１２へインタフェースするために使用される。
【００２１】
ＡＰＩ３１０の下に位置する受信機ブロックは、集合的にメディア処理システムと称される。メディア処理システムは、プロトコル・スタック２００の物理レイヤ２０２機能およびＭＡＣレイヤ２０４機能を与える。ＡＰＩ３１０の上に位置する受信機スタック・ブロック３１２は、受信機スタック処理システムと称されよう。これは、プロトコル・スタック２００のストリーム・レイヤ２０６機能および制御レイヤ２０８機能を与える。メディア処理システムまたは受信機スタック処理システムにおけるプロトコル機能の正確な区分は、実装に依存する。例として、ＭＡＣレイヤ２０４は、１つの実装の場合、ＡＳＩＣ特有ソフトウェア・ブロック３０８内に局在化されうる一方、別の実装の場合、受信機ハードウェア・ブロック３０２、ドライバ・ブロック３０６、およびＡＳＩＣ特有ソフトウェア・ブロック３０８のようなメディア処理システム内の全てのブロックにわたって分散されうる。
【００２２】
受信機ブロックの機能について記載する。本記載は、本質的に有用であり、おのおののブロックの機能を広く定義している。本開示の全体にわたるさまざまな概念に対する適切な機能のみが記載される。当業者であれば、これらのブロックが本明細書に記載されていない他の機能を提供することができることも認識するだろう。
【００２３】
受信機ハードウェア・ブロック３０２は、無線信号を復調し、物理レイヤによって搬送されたデータを取得する機能を提供する半導体ハードウェアを表す。このブロック３０２は、例えばＲＦフロント・エンド処理、ＡＤＣ、タイミングおよび周波数推定、チャネル推定、ターボ復号等のさまざまな機能を提供する。要約すると、受信機ハードウェア・ブロック３０２は、プロトコル・スタックの完全な物理レイヤ２０２実装を提供する。実装に依存して、このブロック３０２はさらに、完全または部分的なＭＡＣレイヤ２０４機能（例えば、Ｒ−Ｓ復号および／またはＭＡＣレイヤ・インタリーブのような低レベルＭＡＣレイヤ機能）を提供する。
【００２４】
ホスト・プロセッサ・ブロック３０４は、受信機３００内のホスト・プロセッサによって提供される機能を表す。より具体的には、ホスト・プロセッサ・ブロック３０４は、ホスト・プロセッサに存在するホスト・プロセッサ・ハードウェアおよびソフトウェア・インプリメンテーションを表す。ホスト・プロセッサ・ハードウェアは、一例として、例えばマイクロプロセッサのような汎用プロセッサ、および／または、例えばデジタル信号プロセッサ（ＤＳＰ）のようなアプリケーション特有のプロセッサを含む１または複数のプロセッサを用いて実現される。ホスト・プロセッサ・ブロック３０４はさらに、１または複数のプロセッサによって実行されるソフトウェアを格納する機械読取可能媒体を含むことができる。ソフトウェアとは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、またはその他任意の用語で称されようとも、命令群、データ構造、またはプログラム・コードの任意の組み合わせを意味するように広く解釈されるものとする。機械読取可能媒体は、ホスト・プロセッサ・ハードウェアによって全体的または部分的に実現される１または複数のストレージ・デバイスを含むことができる。機械読取可能媒体はさらに、ホスト・プロセッサとは別の１または複数のストレージ・デバイス、送信線、または、データ信号をエンコードする搬送波をも含みうる。当業者であれば、特定のアプリケーションのおのおのについて、記載された機能をホスト・プロセッサ・ブロック３０４のためにどうすれば最良に実施することができるかを認識するだろう。
【００２５】
ホスト・プロセッサ・ブロック３０４は、無線送信から復元された情報を取得し処理するために、受信機ハードウェア・ブロック３０２と通信する。この取得された情報は、制御チャネルで受信された制御情報と、オーバヘッド・チャネルで受信されたコンテンツと、論理チャネルで搬送されたアプリケーション・レイヤ・コンテンツとを含む。
【００２６】
ドライバ・ブロック３０６は、受信機ハードウェア・ブロック３０２と直接的にインタフェースする、ホスト・プロセッサ・ブロック３０４内のドライバ・レベル・ソフトウェアを表す。このドライバ・ブロック３０６は、コントローラ機能（例えば、受信機ハードウェア・ブロック３０２のオンまたはオフ機能）と、データ交換機能（例えば、受信機ハードウェア・ブロック３０２からのデータの取得機能、または、受信されるべき論理チャネルの特性の搬送機能）とを提供する。ドライバ・レベル・ソフトウェアは、ホスト・プロセッサと受信機ハードウェアとの間に存在し、ハードウェア・インタフェース・メカニズムのタイプに特有でありうる。例えば、ドライバ・レベル・ソフトウェアは、アドレス／レジスタがマップされたメモリ、または、ＳＤＩＯのようなパケット・ベースのトランザクション・インタフェースを用いてインプリメントされ、ホスト・プロセッサ内の１または複数のプロセッサと、受信機ハードウェアとの間のハードウェア・インタフェースが割り込みによって駆動されるかに依存して変わりうる。ドライバ・ブロック３０６によって実行されるタスクのいくつかの例は、例えば、初期化、スリープ・トリガまたはウェイクアップ・トリガ、ハードウェア・バッファをメイン・メモリに移したりＩＳＲインプリメーションを提供するようなハードウェアとのデータ交換、および、内部フレーム・スリープ・ロジックをサポートするＭＡＣレイヤ・インプリメンテーションのようなハードウェア・インタラクションを含む。
【００２７】
一般に、ドライバ・ブロック３０６機能は、受信機ハードウェアと密に関わっており、本質的に、時間応答性があると考えられている。したがって、ドライバ・ブロック３０６は、図３に示すその他のブロックに関して、高い優先度が与えられる。例えば、ドライバ・ブロック３０６は、受信機ハードウェアによって受信されたデータを取得するタスク、または、受信機ハードウェアに対して、アプリケーション・レイヤによって要求された周波数に調整するように指示するタスクを実行することができる。
【００２８】
ＡＳＩＣ特有ソフトウェア・ブロック３０８は、ドライバ・ブロック３０６によって取り扱われることのないＭＡＣレイヤ機能を提供する。異なるブロックにまたがってＭＡＣレイヤ機能を分割することに依存して、ブロック３０８は、完全なあるいは部分的なＭＡＣレイヤ機能を提供する。少なくともＡＳＩＣ特有ソフトウェア・ブロック３０８は、一般に、ドライバ・ブロック３０６に委託されることが現実的ではない高レベルＭＡＣ機能を提供するだろう。
【００２９】
受信機スタック・ブロック３１２は、ＡＰＩ３１０を使用して、ＡＳＩＣ特有ソフトウェア・ブロック３０８と通信する。受信機スタック・ブロック３１２は、制御レイヤおよびストリーム・レイヤをインプリメントし、インタフェースにアプリケーション・レイヤ・プロトコルを提供する。受信機スタック・ブロック３１２は、アプリケーション・レイヤによって要求されると、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、指定されたコンテンツを受信するようにトリガする。受信機スタック・ブロック３１２は、ＡＳＩＣ特有ソフトウェア・ブロック３０８からの通知またはコンテンツに対する処理を行い、ＡＳＩＣ特有ソフトウェア・ブロック３０８から受信された任意のコンテンツを、アプリケーション・レイヤ・プロトコルへ配信する。
【００３０】
ＡＰＩ３１０は、ＡＳＩＣ特有ソフトウェア・ブロック３０８が受信機スタック・ブロック３１２と通信することを可能にするインタフェースを規定する。ＡＰＩ３１０によって規定されたインタフェースに付随するあらゆる受信機スタックも同様に、これらインタフェースに付随するＡＳＩＣ特有ソフトウェアとともに動作するだろう。ＡＰＩ３１０は、それぞれが、ＡＳＩＣ特有ソフトウェア・ブロック３０８と受信機スタック・ブロック３１２との間の通信を可能にする前述したインタフェースを規定する複数の個別のＡＰＩを含むＡＰＩ機能を表す。これらＡＰＩの例、および、これらが規定するインタフェースは、以下により詳細に示される。
【００３１】
ハードウェア・インタフェース・ブロック３０５は、ホスト・プロセッサ・ブロック３０４と受信機ハードウェア・ブロック３０２との間に存在するハードウェア・インタフェース・メカニズムを表す。このインタフェースは、通信およびデータ交換機能を提供する。ドライバ・ブロック３０６は、受信機ハードウェア・ブロック３０２とコマンドおよびデータを交換するためにこのインタフェース３０５を使用する。ハードウェア・インタフェース・ブロック３０５は、例えば、専用のバス・インタフェースまたは標準ベースのインタフェース（例えば、ＳＤＩＯ）のような任意の所望のインタフェースでありうる。
【００３２】
さまざまな例が、ＡＰＩ３１０をまたいで受信機３００内で引き起こる通信を例示して示される。次の例は、コール・フローを含む図４乃至１１に関連して説明されよう。これらの図では、実線矢印が、ＡＰＩ３１０をまたいで引き起こる通信を示す。受信機スタック処理システム４００およびメディア処理システム４０１内のブロックで生じる通信および受信機ブロックによってなされる役割は、完全性のためにのみ示される。前述したように、処理システムのうちの何れか（すなわち、ＡＰＩ３１０の同じ側）に局在化するブロック間の通信および個々の受信機ブロックによってなされる実際の役割は、実装に依存しており、実装毎に変わりうる。この通信は、図中において破線で示される。
【００３３】
図４は、受信機をオンするコール・フローの例を例示する図である。ステップ４０２において、受信機スタック処理システム４００からの初期化コマンドが、受信機をイネーブルするためにＡＳＩＣ特有ソフトウェア・ブロック３０８へ送られる。このコマンドは、あるアプリケーション・レイヤのトリガまたは電源オンの結果として送られうる。このコマンドは、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、例えばさまざまな受信機機能を実行する準備としてハードウェアをオンすることのようなあらゆる起動動作を実行させる。
【００３４】
ステップ４０３では、受信機スタック処理システム４００からのコマンドが、ＡＳＩＣ特有ソフトウェア・ブロック３０８へ送られ、受信機３００が無線信号を獲得するための周波数をここから選択する周波数のセットが（帯域幅／チャネル・プランとともに）指定される。周波数のセットおよび帯域幅は、無線デバイスにおいてプロビジョンされた情報から取得されうる。
【００３５】
ステップ４０４では、受信機スタック処理システム４００が、システムを獲得するためのコマンドをＡＳＩＣ特有ソフトウェア・ブロック３０８へ送る。このコマンドは、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、選択された周波数で、オーバヘッド情報を読み取らせる。
【００３６】
ステップ４０５では、ＡＳＩＣ特有ソフトウェア・ブロック３０８から、受信機スタック処理システム４００によって、ネットワーク・イベントが受信され、オーバヘッド情報が、獲得されたオーバヘッド情報のタイプとネットワークＩＤ（すなわち、ローカル・エリア情報または広域情報）とともに獲得されたことが示される。オーバヘッド情報が獲得されると、ＡＳＩＣ特有ソフトウェア・ブロック３０８は、ステップ４０６において、受信機スタック処理システム４００へ制御情報更新メッセージを送り、受信された最新の制御情報シーケンス番号とともに制御情報が利用可能であることが示される。ステップ４０７では、受信機スタック処理システム４００が、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、制御情報を取得するように指示する。これに応答して、ＡＳＩＣ特有ソフトウェア・ブロック３０８は、ステップ４０８において、制御チャネルを読み取り、制御情報のパケットを、フレーム毎に、受信機スタック処理システム４００へ送る。おのおののフレームには、おのおののパケットのシーケンス番号とフレームにおける制御パケットの位置とを特定するサイド情報が含まれている。制御情報全体が受信されたと受信機スタック処理システム４００が判定すると、システム４００は、ステップ４０９において、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、制御チャネルの受信を停止するよう指示する。
【００３７】
図５は、受信機をオフするコール・フローの例を示す図である。ステップ５０１では、受信機をオフするコマンドが、受信機処理システム４００からＡＳＩＣ特有ソフトウェア・ブロック３０８へ送られる。このコマンドは、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、メディア処理システム内の他のブロックが受信機をオフするように指示する。ステップ５０２では、受信機スタック処理システム４００へアクノレッジメントが送り返され、コマンドが受信されたことが示される。
【００３８】
図６は、受信機スタック処理システム４００によって特定の論理チャネルが要求された場合におけるコール・フローの例を例示する図である。これは通常、指定されたフローのコンテンツを受信するように、アプリケーション・レイヤをトリガすることによって引き起こされる。所望のコンテンツが適切な論理チャネルによって受信されるように、制御レイヤは、フローＩＤを、（論理チャネルが送信された周波数とともに）論理チャネルについてマップされたＩＤに変換する。
【００３９】
ステップ６０１では、受信機スタック処理システム４００が、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、特定の論理チャネルＩＤでコンテンツを取得するように指示する。論理チャネルＩＤとともに、論理チャネルの物理レイヤ特性（例えば、周波数、送信モード、外部符号レート）が提供される。さらに、ＡＳＩＣ特有ソフトウェア・ブロック３０８のために、制御パケットのシーケンス番号が提供される。これによって、ＡＳＩＣ特有ソフトウェア・ブロック３０８は、制御レイヤによって保持されている制御情報が現在のものであるか、および、論理チャネルを受信する前に、制御情報を受信する必要があるか、を判定できるようになる。
【００４０】
ステップ６０２では、ＡＳＩＣ特有ソフトウェア３０８が、要求された論理チャネルを取得するコマンドをサービス提供できるか否かをアクノレッジする。
【００４１】
ステップ６０３では、ＡＳＩＣ特有ソフトウェア・ブロック３０８は、受信機ハードウェア・ブロック３０２から取得された論理チャネルでコンテンツを返す。Ｒ−Ｓ復号が実行された後、コンテンツが論理チャネルで返される。ステップ６０４では、受信機スタック処理システム４００がＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、この論理チャネル上でコンテンツを受信することを停止するように要求するまで、コンテンツがフレーム毎に返される。
【００４２】
図７は、デバイスが、インフラストラクチャまたはネットワークの有効範囲領域から別へ移動する場合におけるコール・フローの例を例示する図である。ステップ７０１では、ネットワークまたはインフラストラクチャＩＤの変更があった場合に、移動が検出される。ネットワークまたはインフラストラクチャＩＤは、フレームのオーバヘッド部分に含まれたシステム・パラメータ・メッセージに含まれうる。変更を検出すると、ＡＳＩＣ特有ソフトウェア・ブロック３０８は、受信機スタック処理システム４００に、移動がまさに引き起こることを示すネットワーク・イベントを送る。受信機３００の１つの構成では、ＡＳＩＣ特有ソフトウェア・ブロック３０８が、インジケーションを受信機スタック処理システム４００に送る前に、ヒステリシス・アルゴリズムを実行し、無線デバイスが２つのネットワークまたはインフラストラクチャの間の境界に沿ってローミングする場合にネットワーク・イベントが複数回数トグルされることを回避する。
【００４３】
ステップ７０２では、ＡＳＩＣ特有ソフトウェア・ブロック３０８が、制御情報更新メッセージを受信機スタック処理システム４００へ送り、更新された制御情報が、受信された最新の制御シーケンス番号とともに利用可能であることを示す。ステップ７０３では、受信機スタック処理システム４００が、無線デバイスが移動した新たな領域のための制御情報を取得するようにＡＳＩＣ特有ソフトウェア・ブロック３０８に指示する。これに応答して、ステップ７０４では、ＡＳＩＣ特有ソフトウェア・ブロック３０８が、制御チャネルを読み取り、制御情報のパケットを、受信機スタック処理システム４００へ送信する。おのおののフレームには、フレーム内の制御パケットの位置と、おのおののパケットのシーケンス番号とを識別するサイド情報が含まれる。ステップ７０５では、受信機スタック処理システム４００が、制御情報の全てが受信されたかを判定し、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、制御情報の受信を停止するように指示する。
【００４４】
図８は、たとえばオーバヘッド・チャネルによって、あるいは、受信機によって現在受信されている論理チャネルのいくつかまたは全てによって、誤りが連続的に受信された場合のように、獲得基準を満たさない場合におけるコール・フローの例を例示する図である。ステップ８０１では、受信機がこの基準を満たさない場合、ＡＳＩＣ特有ソフトウェア・ブロック３０８は、受信機スタック処理システム４００へネットワーク・イベント・インジケーションを送る。このインジケーションを受信すると、受信機スタック３１２は、単純に、同じネットワークまたは別のネットワークの獲得を待つ。オプションのユーザ・インジケーションが、アプリケーション・レイヤへ送られ、受信機が、獲得基準を満たさないことが示される。
【００４５】
ステップ８０２では、アクティブな論理チャネルでデータを受信することを停止し、これら論理チャネルを受信するために割り当てられたリソースを空けるように指示するコマンドを、受信機スタック３１２がＡＳＩＣ特有ソフトウェアへ送る。
【００４６】
ステップ８０３においてネットワークの獲得に成功すると、ＡＳＩＣ特有ソフトウェア・ブロック３０８は、ネットワーク・イベント・インジケーションを受信機スタックに送り、獲得が成功したことを示す。獲得されたネットワークが、最後に獲得されたネットワークとは異なる場合、あるいは、制御シーケンス番号が更新された場合、ステップ８０４において、ＡＳＩＣ特有ソフトウェア・ブロック３０８は、受信機スタック処理システム４００へ制御情報更新メッセージを送り、受信された最新の制御シーケンス番号とともに、更新された制御情報が利用可能であることが示される。ステップ８０５では、受信機スタック処理システム４００が、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、獲得されたネットワークのための制御情報を取得するように指示する。これに応答して、ステップ８０６では、ＡＳＩＣ特有ソフトウェア・ブロック３０８が、制御情報を読み取り、制御情報のパケットを、受信機スタック処理システム４００へ送る。おのおののフレームには、処理システム４００内の制御パケットの位置を識別し、制御情報の全体が受信されたことを判定し、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、制御情報の受信を停止するように指示するサイド情報が含まれる。
【００４７】
図９は、受信機が、自己のキャッシュ内の制御情報における最新値を検出した場合におけるコール・フローの例を例示する図である。オーバヘッド・チャネルで受信された制御シーケンス番号が、最後に受信されたものとは異なる場合、最新の制御情報がＡＳＩＣ特有ソフトウェア・ブロック３０８によって検出される。
【００４８】
ステップ９０１では、ＡＳＩＣ特有ソフトウェア・ブロックが、オーバヘッド情報を受信した場合、このブロックは、受信した制御シーケンス番号を、最後に格納されたものと比較する。ステップ９０２では、更新が検出された場合、ＡＳＩＣ特有ソフトウェア・ブロック３０８が、制御情報更新メッセージを受信機スタック処理システム４００へ送り、制御情報における更新値が利用可能であることが示される。ステップ９０３では、受信機スタック処理システム４００が、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、制御情報を取得するように指示する。これに応答して、ステップ９０４では、ＡＳＩＣ特有ソフトウェア・ブロック３０８が、制御情報を読み取り、制御情報のパケットを、受信機スタック処理システム４００へ送信する。おのおののフレームには、フレーム内の制御パケットの位置と、おのおののパケットのシーケンス番号とを識別するサイド情報が含まれる。ステップ９０５では、受信機スタック処理システム４００が、制御情報の全体が受信されたことを判定し、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、制御情報の受信を停止するように指示する。
【００４９】
図１０は、オーバヘッド情報をモニタするためのコール・フローの例を例示する図である。オーバヘッド情報は、フレームのオーバヘッド部分内のシステム・パラメータ・メッセージによって指定されたような所与の周期でモニタされうる。受信機に対してオーバヘッド情報を読み取るように要求するイベントがない場合、受信機は、特定のインタバルで、オーバヘッド情報を読み取ることができる。
【００５０】
ステップ１００１では、受信機スタック処理システム４００が、ＡＳＩＣ特有ソフトウェアに対して、システム・パラメータ・メッセージによって定義された周期に基づいてオーバヘッド情報をモニタするように指示する。ＡＳＩＣ特有ソフトウェア・ブロック３０８は、オーバヘッド情報を読み取らせるようにするイベントがない場合、少なくともこの周期でオーバヘッド情報がモニタされることを保証する。
【００５１】
ステップ１００２では、オーバヘッド情報で受信された制御シーケンス番号が、最後に受信されたものとは異なる場合、制御情報の最新値がＡＳＩＣ特有ソフトウェア・ブロック３０８によって検出される。受信機スタック３１２は、ＡＳＩＣ特有ソフトウェア・ブロック３０８から制御情報更新メッセージを受信し、制御情報の最新値が利用可能であることが示される。ステップ１００３では、受信機スタック処理システム４００が、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、制御情報を取得するように指示する。これに応答して、ステップ１００４では、ＡＳＩＣ特有ソフトウェア・ブロック３０８が、制御情報を読み取り、制御情報のパケットを、受信機スタック処理システム４００へ送る。おのおののフレームには、フレーム内の制御パケットの位置と、おのおののパケットのシーケンス番号とを識別するサイド情報が含まれる。ステップ１００５では、受信機スタック処理システム４００が、制御情報の全体が受信されたことを判定し、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、制御チャネルの受信を停止するように指示する。
【００５２】
ステップ１００６では、オーバヘッド情報の周期的なモニタリングをディセーブルするようにとの指示がなされると、ＡＳＩＣ特有ソフトウェア・ブロック３０８は、このモニタリングをディセーブルする。ステップ１００２乃至１００５は条件付きであり、受信されたオーバヘッド情報において、制御情報の最新値が検出された場合にのみ実行される。
【００５３】
図１１は、ＡＳＩＣ特有ソフトウェア・ブロック３０８に周波数スキャン・リストを設定するコール・フローの例を例示する図である。周波数スキャン・リストは、制御情報内に存在する近隣ローカル・エリア情報から得られる。ＡＳＩＣ特有ソフトウェア・ブロック３０８は、ハンドオフ・アルゴリズムを実行するためにこのスキャン・リストを使用する。
【００５４】
ステップ１１０１では、受信機スタック処理システム４００が、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、制御情報を取得するように指示する。これに応答して、ステップ１１０２では、ＡＳＩＣ特有ソフトウェア・ブロック３０８が、制御チャネルを読み取り、制御情報のパケットを、受信機スタック処理システム４００へ送る。おのおののフレームには、フレーム内の制御情報の位置と、おのおののパケットのシーケンス番号とを識別するサイド情報が含まれる。ステップ１１０３では、受信機スタック処理システム４００が、制御情報の全体が受信されたことを判定し、ＡＳＩＣ特有ソフトウェア・ブロック３０８に対して、制御チャネルの受信を停止するように指示する。
【００５５】
ステップ１１０４では、受信機スタック処理システム４００が、制御情報内の近隣記述メッセージを処理することによって、近隣システムの統合リストを作成する。その後、受信機スタック処理システム４００は、このリストを、ＡＳＩＣ特有ソフトウェア・ブロック３０８へ送る。ＡＳＩＣ特有ソフトウェア・ブロック３０８は、このリストを用いることによってハンドオフ・アルゴリズムを実行し、近隣システムからの信号をモニタする。ステップ１１０５では、近隣システムへのハンドオフが実行されると、宛先システムの広域およびローカル・エリアの差別化要因とともに、インジケーションが受信機スタック処理システム４００へ送られる。ステップ１１０５は条件付きであり、ハンドオフが実行された場合にのみ行われる。ハンドオフの後、新たなシステムが獲得され、これによって受信されたオーバヘッド情報が、さらなるネットワーク・イベントを検出するために用いられる。
【００５６】
従来の無線受信機は、ブロードキャストされたデータを受信しながら、受信したデータ・パケットを処理する。無線受信機におけるより下位のソフトウェア・レイヤは、送信中に失われたパケットを復元することを試みる。送信単位で送信された情報に含まれるこれら復元されたパケットは、下位のソフトウェア・レイヤによって、上位のソフトウェア・レイヤへ送られるパケットのグループ（あるいは、パケット・チェーン）として格納される。パケット・チェーン内に格納されたおのおののパケットに対して、下位のソフトウェア・レイヤは、パケットが誤りをもっているかを示す関連する誤りステータスを保持する。上位のソフトウェア・レイヤは、上位レイヤと下位レイヤとの間の指定されたＡＰＩを用いて、パケット・チェーンからパケットを一度に１つ読み取る。下位ソフトウェア・レイヤによって訂正されない誤りを持つパケットは、（１）上位パケットによって破棄されるか、あるいは、（２）受信されたコンテンツに関連するコンフィグレーション情報にしたがって、アプリケーション・レイヤへ渡されるかの何れかである。上記（１）の状況では、誤りのあるパケットは、下位レイヤから不要に読み取られ、単に破棄される。これは、処理効率に悪影響を及ぼす。
【００５７】
本発明の典型的な実施形態によって、受信機スタック処理システムは、メディア処理システムからのデータをコピーする前に、受信したパケットの誤りステータスを前もって判定できるようになる。これによって、動作がより効率的になり、処理が高速化される。受信機スタック処理システムは、ＡＰＩを起動して、メディア処理システムに対して、パケット・チェーン内の所与のパケットの誤りステータスを報告するように指示する。関連する誤りをパケットが有しているとメディア処理システムが報告した場合、受信機スタック処理システムは、別のＡＰＩを起動して、メディア処理システムに対して、このパケットを破棄するように指示する。このパケットは、受信機スタック処理システムへコピーされない。一方、このパケットが誤りを有していないとメディア処理システムが報告した場合、受信機スタック処理システムは、ＡＰＩを起動して、このパケットを、受信機スタック処理システムへコピーする。この手順は、パケット・チェーン内のおのおののパケットについて繰り返される。
【００５８】
いくつかの状況では、アプリケーション・レイヤは、パケット・チェーンが完全に誤りがないことを求める。したがって、いくつかの実施形態では、受信機スタック処理システムは、ＡＰＩを起動して、メディア処理システムに対して、このパケット・チェーンが、関連する誤りを有しているか、すなわち、このチェーン内の任意のパケットが、関連する誤りを有しているかを報告するように指示する。パケット・チェーンのパケットのいずれかに誤りが存在するとメディア処理システムが報告した場合、受信機スタック処理システムは、ＡＰＩを呼び出し、メディア処理システムに対して、パケット・チェーン全体を破棄するように指示する。図１３は、本発明の典型的な実施形態にしたがった動作を例示するコール・フロー図である。
【００５９】
図１３では、所望の論理チャネルのスーパフレームのパケット・チェーンが、メディア処理システム４０１によって、例えば上述されたような図６の６０１および６０２における動作にしたがって蓄積される。パケット・チェーンがメディア処理システム４００内に配置されると、受信機スタック処理システム４００はＡＰＩ１３０１を起動し、メディア処理システム４０１に対して、このチェーン内の何れかのパケットが、関連する誤りを有しているかを報告するように指示する。もしも有しているのであれば（すなわち、図１３のＦＡＬＳＥリターン）、受信機スタック処理システム４００は、ＡＰＩ１３０２を起動し、メディア処理システムに対して、パケット・チェーン全体を破棄するように指示する。
【００６０】
図１４は、本発明の典型的な実施形態を例示するコール・フロー図である。（６０１および６０２に示す動作によって）メディア処理システム４０１において、パケット・チェーンが準備された後、受信機スタック処理システム４００は、ＡＰＩ１４０１を起動して、メディア処理システム４０１に対し、チェーン内の最初のパケットが、関連する誤りを有しているのかを報告するように指示する。もしも有しているのであれば（すなわち、図１４のＴＲＵＥリターン）、受信機スタック処理システム４００は、ＡＰＩ１４０２を起動し、メディア処理システム４０１に対して、チェーンの最初のパケットを捨てるように指示する（これによって、チェーンの２番目のパケットが、このチェーンの最初のパケットとなる）。一方、ＡＰＩ１４０１に応答して、チェーンの最初のパケットが関連する誤りを有していないとメディア処理システム４００が報告すると（すなわち、図１４のＦＡＬＳＥリターン）、受信機スタック処理システム４００はＡＰＩ１４０３を起動し、メディア処理システム４０１からのチェーンの最初のパケットを、受信機処理システム４００へコピーする動作を開始する（これによって、チェーンの２番目のパケットが、最初のパケットになる）。受信機スタック処理システム４００は、チェーンの全てのパケットが、受信機スタック処理システム４００へコピーされるまで、あるいは、メディア処理システム４０１によって破棄されるまで、適切にＡＰＩ１４０１乃至１４０３を繰り返し起動する。
【００６１】
図１２は、物理レイヤ、ＭＡＣレイヤ、制御レイヤ、およびストリーム・レイヤを備え、プロトコル・スタックにしたがって信号を受信するように構成された装置の機能ブロック図である。この装置１２００は、デバイス１１０（図１を参照）、あるいは、装置内の１または複数のエンティティでありうる。装置１２００は、物理レイヤおよびＭＡＣレイヤを提供するモジュール１２０２と、制御レイヤおよびストリーム・レイヤを提供するモジュール１２０６と、サービス要求をサポートするＡＰＩモジュール１２０４とを含む。
【００６２】
上記記述は、当業者が、本明細書に記載された様々な実施形態を実現できるように与えられた。これらの実施形態へのさまざまな変更は、当業者に容易に明らかになるだろう。そして、本明細書で定められた一般的な原理は、他の実施形態にも当てはまる。したがって、請求項は、本明細書に示された局面に限定されることは意図されず、「１または複数」と明確に述べられていないのであれば、請求項の全スコープは、単数要素に対する言及が「１または１のみ」を意味するものと意図されていない請求項の文言と合致するものと意図される。本開示にわたって記述され、当業者に知られているかあるいは後に知られることになる様々な実施形態の要素に対する全ての構造的および機能的な等価物は、参照によって本明細書に明確に組み込まれ、請求項に包含されることが意図されている。さらに、そのような開示が請求項において明示的に述べられているかに関わらず、本明細書で開示された何れも、公衆に放棄されることは意図されていない。どの請求項要素も、"means for"というフレーズを用いて、あるいは方法請求項の場合であれば"step for"というフレーズを用いて記載されていないのであれば、３５Ｕ．Ｓ．Ｃ１１２条第６パラグラフのプロビジョンの下で解釈されない。
【図１】
2010526520.tif 000003
【図２】
2010526520.tif 000004
【図３】
2010526520.tif 000005
【図４】
2010526520.tif 000006
【図５】
2010526520.tif 000007
【図６】
2010526520.tif 000008
【図７】
2010526520.tif 000009
【図８】
2010526520.tif 000010
【図９】
2010526520.tif 000011
【図１０】
2010526520.tif 000012
【図１１】
2010526520.tif 000013
【図１２】
2010526520.tif 000014
【図１３】
2010526520.tif 000015
【図１４】
2010526520.tif 000016
【国際調査報告】
2010526520.tif 000017
2010526520.tif 000018
2010526520.tif 000019