JP5174202B2 - 無線通信における適応性のあるサーバ選択の方法およびシステム - Google Patents

Description

３５Ｕ．Ｓ．Ｃ．§１１９の下の優先権主張
この特許出願は、２００５年８月１６日に申請され、その譲受人に譲渡され、ここに引用文献として明らかに組込まれた米国の仮出願第６０／７０８，５２９号「Methods and Systems for Adaptive Server Selection in Wireless Communications」への優先権を要求する。

この開示は、一般に通信システムに関係がある。より具体的には、ここに示された実施例は、無線通信における適応性のあるサーバ選択に関係がある。

無線通信システムは複数のユーザに様々なタイプの通信（例えば音声、データ等）を供給するために広く展開される。そのようなシステムは、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）または他の多元接続技術に基づいている。無線通信システムは、ＩＳ−９５、ｃｄｍａ２０００、ＩＳ−８５６、Ｗ−ＣＤＭＡ、ＴＤ−ＳＣＤＭＡおよび他の標準のような１つ以上の標準を実施するように設計される。

無線通信システムがさらに高いデータレートでますます多くのユーザに種々のサービスを提供するために努力するとき、この発明の解決すべき課題はサービスの品質を向上させてネットワーク効率を改善することである。

無線通信システムの実施例を示す。 「１ｘＥＶ−ＤＯリリース０」および「１ｘＥＶ−ＤＯレビジョンＡ」型システムにおけるソフトハンドオフ・タイムラインの実施例を示す。 「１ｘＥＶ−ＤＯリリース０」および「１ｘＥＶ−ＤＯレビジョンＡ」型システムにおけるソフトハンドオフ・タイムラインの実施例を示す。 「１ｘＥＶ−ＤＯリリース０」および「１ｘＥＶ−ＤＯレビジョンＡ」型システムにおけるソフトハンドオフ・タイムラインの実施例を示す。 ＤＳＣおよびＤＲＣチャネルのタイムラインを操作する実施例を示す。 ＤＲＣカバー変更の実施例を示す。 第１のソフトハンドオフ・シナリオで起こるイベントのシーケンスの実施例を示す。 第２のソフトハンドオフ・シナリオで起こるイベントのシーケンスの実施例を示す。 第３のソフトハンドオフ・シナリオで起こるイベントのシーケンスの実施例を示す。 第４のソフトハンドオフ・シナリオで起こるイベントのシーケンスの実施例を示す。 いくつかの示された実施例を実施するために使用される処理のフローチャートを示す。 いくつかの示された実施例を実施するために使用される処理のフローチャートを示す。 いくつかの示された実施例を実施するために使用される処理のフローチャートを示す。 いくつかの示された実施例を実施するために使用される処理のフローチャートを示す。 いくつかの示された実施例が実施される装置のブロック図を示す。 いくつかの示された実施例が実施される装置のブロック図を示す。 いくつかの示された実施例が実施される装置のブロック図を示す。 ＤＲＣＬｏｃｋビットを設定するのに関連したヒステリシスの実施例を示す。 ＤＲＣ消去マッピングに関する処理のフローチャートを示す。 図１７で示された特徴を実施するために使用される処理のフローチャートを示す。 図１７で示された特徴を実施するために使用される処理のフローチャートを示す。 図１７で示された特徴を実施するために使用される処理のフローチャートを示す。 図１７で示された特徴を実施するために使用される処理のフローチャートを示す。 図１７で示された特徴を実施するために使用される処理のフローチャートを示す。 図１７で示された特徴を実施するために使用される処理のフローチャートを示す。 図１７で示された特徴を実施するために使用される処理のフローチャートを示す。 図１７で示された特徴を実施するために使用される処理のフローチャートを示す。 図１７で示された特徴を実施するために使用される処理のフローチャートを示す。 図１７および図１８Ａ−Ｉで示された特徴を実施するために使用される処理のフローチャートを示す。 いくつかの示された実施例が実施される装置のブロック図を示す。

ここに示された実施例は、無線通信における適応性のあるサーバ選択の提供のための方法とシステムに関係がある。

ここに示されたアクセス・ポイント（ＡＰ）は、基地局トランシーバ・システム（ＢＴＳ）、アクセス・ネットワーク・トランシーバ（ＡＮＴ）、モデムプール・トランシーバ（ＭＰＴ）またはノードＢ（例えば、Ｗ−ＣＤＭＡ型システムにおいて）などの機能を含みおよび/または実施してもよい。セルはＡＰによってサービスされたカバレージエリアを指す。セルはさらに１つ以上のセクタを含んでもよい。さらに、アクセスネットワーク制御装置（ＡＮＣ）は、中核ネットワーク（例えば、パケット・データ・ネットワーク）とインターフェースし、アクセス端末（ＡＴ）および中核ネットワーク間でデータパケットをルート設定するように構成された通信システムの部分を指し、各種無線アクセスおよびリンク保守機能（ソフトハンドオフのような）を行ない、無線送信機および受信機などを制御する。ＡＮＣは、第２、第３または第４世代無線ネットワークで見られるように、基地局制御装置（ＢＳＣ）の機能を含みおよび/または実施してもよい。ＡＮＣおよび１つ以上のＡＰが、アクセス・ネットワーク（ＡＮ）の一部を構成してもよい。

ここに示されたＡＴは、無線電話、携帯電話、ラップトップ・コンピュータ、マルチメディア無線デバイス、無線通信パソコン（ＰＣ）カード、携帯情報端末（ＰＤＡ）、外部または内蔵モデムなどを含む（しかし限定するものではない）様々なタイプの装置を指す。ＡＴは、無線チャネルおよび/または有線チャネル（例えば、光ファイバまたは同軸ケーブル経由の）を通して通信する任意のデータ装置であるかもしれない。ＡＴはまた、アクセス・ユニット、アクセスノード、加入者ユニット、移動局、移動デバイス、移動ユニット、携帯電話、モバイル、遠隔局、遠隔端末、遠隔ユニット、ユーザ装置、ユーザ設備、ハンドヘルド装置など様々な名前を持っている。異なるＡＴがシステムに組み入れられてもよい。ＡＴは移動または静止であってもよく、通信システムの全体にわたって分散してもよい。ＡＴは、与えられた瞬間で、順方向リンク（ＦＬ）および/または逆方向リンク（ＲＬ）上の１つ以上のＡＰと通信し得る。

図１は多くのユーザを支援するように構成された無線通信システム１００を示し、さらに以下で述べられるように、様々な開示された実施例および態様が実施されてもよい。例の方法で、システム１００はセル１０２ａ−１０２ｇを含む多くのセル１０２のための通信を提供し、各セルは対応するＡＰ１０４（ＡＰ１０４ａ−１０４ｇのような）によってサービスされる。各セルは１つ以上のセクタにさらに分割されてもよい。ＡＴ１０６ａ−１０６ｋを含む様々なＡＴ１０６は、システムの全体にわたって分散する。各ＡＴ１０６は、例えば、ＡＴが活発かどうかおよびそれがソフトハンドオフにあるかどうかに依存して、与えられた瞬間に順方向リンクおよび/または逆方向リンク上の１つ以上のＡＰ１０４と通信してもよい。

図１では、矢印による実線はＡＰからＡＴへ情報（例えばデータ）送信を示している。各々矢印による破線は、以下にさらに記述されるように、ＡＴがそれぞれのＡＰからパイロットおよび他のシグナリング／参照信号を受信していること（例えば、ＡＴの活発な組のもの）を示している。明瞭さと単純性のために、逆方向リンク通信は、図１で明示的に示されない。

高速パケット・データ（ＨＲＰＤ）システム（例えば、「１ｘＥＶ−ＤＯリリース０」型システムとしてここに参照された「ｃｄｍａ２０００高速パケット・データ・エアー・インターフェース・スペック」３ＧＰＰ２Ｃ．Ｓ００２４−０バージョン４．０、２００２年１０月２５日、「１ｘＥＶ−ＤＯレビジョンＡ」型システムとしてここに参照された「ｃｄｍａ２０００高速パケット・データ・エアー・インターフェース・スペック」３ＧＰＰ２Ｃ．Ｓ００２４−Ａ、バージョン２、２００５年７月などで指定されたような）において、例えば、順方向リンクの送信はフレームのシーケンスに分割され、各フレームはさらにタイムスロット（例えば、それぞれ１．６６７ミリセカンドの持続をもつ１６スロット）に分割され、各スロットは複数の時分割多重化チャネルを含んでいる。

図２Ａ−２Ｃは、ＡＴがソースセクタ（例えば、セクタＡ）から目標セクタ（例えば、セクタＢ）へその順方向リンクサービス・セクタを切換える状況に関係している、「１ｘＥＶ−ＤＯリリース０」および「１ｘＥＶ−ＤＯレビジョンＡ」型システムにおけるソフトハンドオフ・タイムラインの実施例を示す。ＡＴがその順方向リンクのサービス・セクタを切換えるべきトリガーは、順方向リンク・チャネル条件、例えば、図２Ａに示されおよびさらに以下に述べられるように、予め定められた方式にしたがって、ソースセクタからのそれより一貫して高い目標セクタからの（例えば、パイロットおよび/または他の順方向リンク信号測定に基づいた）フィルタにかけられた信号対干渉および雑音（ＳＩＮＲ）比に起因してもよい。

「１ｘＥＶ−ＤＯリリース０」型システムにおいて、図２Ｂで示されるように、ＡＴはデータレート制御（ＤＲＣ）チャネルを使用して、順方向リンク上の送信に関連した選択されたサービス・セクタおよび所望のデータレートをＡＮに示す。ＤＲＣチャネルはまた、チャネル品質情報に関連するフィードバックメカニズムをＡＮに提供する。ＤＲＣのデータ部分およびセクタ部分は、それぞれ「ＤＲＣレート」および「ＤＲＣカバー」としてここに呼ばれる。ＤＲＣレートおよびＤＲＣカバーは「ＤＲＣ値」を構成する。

ＤＲＣカバーは任意のＤＲＣ変更境界、例えば、以下の式のスロットＴにおいて変更されてもよい。

（Ｔ＋１−ＦｒａｍｅＯｆｆｓｅｔ）ｍｏｄＤＲＣＬｅｎｇｔｈ＝０ 式（１）
ここに、ＦｒａｍｅＯｆｆｓｅｔはスロットの単位で測定され、ｍｏｄはモジュール演算を表わし、ＤＲＣＬｅｎｇｔｈは持続中のスロットの所定数（例えば、８スロット）である。ＤＲＣカバーおよびＤＲＣレートは送信が終わった後に半分のスロットに効果を生じ、事実上ＤＲＣＬｅｎｇｔｈと等しい多くのスロットについてとどまる。

ソフトおよびソフターハンドオフの両方について、ナル・カバーの２つのＤＲＣ長さの最低は、次の例が示すように異なるＤＲＣカバー（例えば、セクタＡからセクタＢへ切換えることに関係された）間で必要かもしれない。

１）ＡＴの現在のＤＲＣカバーがセクタ・カバーである場合、ＡＴの次のＤＲＣカバーは異なるセクタ・カバーではないかもしれない。それは単に同じセクタ・カバーまたはナル・カバーかもしれない。

２）ＡＴの最も最近のセクタ・カバーがセクタＡに相当する場合、セクタＢから受信したパケットがセクタＡから受信したパケットに時間内にオーバーラップしないことをＡＴが決めるまで、ＡＴはセクタＢに対応するセクタ・カバーを使用しなくてもよい。

ＤＲＣ変更境界にあるスロットｎの終わりで、そのＤＲＣをセクタＡからＢへ切換えることをＡＴが決定する状況を考慮する。スロット（ｎ＋１）からスロット（ｎ＋ＤＲＣＬｅｎｇｔｈ）への実際上メディア・アクセス制御（ＭＡＣ）層のＤＲＣカバーは、まだセクタＡにあり、また、ＡＴはこの時間中ＡＮによって送信のためスケジュールされるかもしれない。その結果、ＡＴは、セクタＢにＤＲＣカバーを即座に変更することができないかもしれない。したがって、ナル・カバーはスロット（ｎ＋１）からスロット（ｎ＋ＤＲＣＬｅｎｇｔｈ）に送信される必要がある。ＡＮはスロット（ｎ＋ＤＲＣＬｅｎｇｔｈ）においてＡＴへのパケットをスケジュールしてもよい。パケットが特別なデータレート（例えば、１６のスロット上の１０２４ビットを備えたレート・インデックス１）である場合、それは、ＤＲＣ変更と該当データパケット送信の間の時間オフセットである長さ１０２４チップのプリアンブルを持っていてもよい。ＡＴは、それがスロット（ｎ＋ＤＲＣＬｅｎｇｔｈ＋１）のためのＤＲＣカバーを決定する場合、それのためのパケットがないかどうか分からないかもしれない。したがって、ナル・カバーはスロット（ｎ＋ＤＲＣＬｅｎｇｔｈ＋１）から（ｎ＋２×ＤＲＣＬｅｎｇｔｈ）へ送信される必要がある。そのように、少なくとも２つのナル・カバーがＤＲＣカバー変更間で必要とされるかもしれない。

セクタＡおよびセクタＢが、同じセルにない（例えば、ソフトハンドオフ中）の場合、ＡＮＣはそれがＡＴにサービスを始める前に、セクタＢへデータを転送する必要があるかもしれない。ＤＲＣカバー変更の検知で、図２Ｂで示されるように、ソフトハンドオフを示すためＡＮＣに対して、セクタＡがメッセージ（例えば「ＦｏｒｗａｒｄＳｔｏｐｐｅｄ」）を送信し、セクタＢがまたメッセージ（例えば「ＦｏｒｗａｒｄＤｅｓｉｒｅｄ」）を送信するかもしれない。したがって、ＡＴは、ソフトハンドオフ中に、少なくとも１つのＡＰ−ＡＮＣラウンド・トリップ時間プラス２ＤＲＣＬｅｎｇｔｈｓの間サービスされないかもしれない。ソフターハンドオフについては、非サービス時間は少なくとも２ＤＲＣＬｅｎｇｔｈｓかもしれない。非サービス時間は、図２Ｂで示されたように「サービス供給停止」（または「暗い時間」）とここに名付けられてもよい。サービス供給停止は、「ボイス・オーバ・インターネット・プロトコル（ＶｏＩＰ）」データのような、遅れに敏感なアプリケーションのために損失を引き起こすかもしれない。

ハンドオフ中にサービス供給停止を減少するために、データソース制御（ＤＳＣ）チャネルが導入されてもよく（「１ｘＥＶ−ＤＯレビジョンＡ」型システムにおけるように）、順方向リンク上でサービス・セルまたはデータソースを表わしている。ＡＴは、順方向リンク上で選択されたサービス・セルをＡＮに示すためにＤＳＣチャネルを使用し、順方向リンク上で選択されたサービス・セクタをＡＮに示すためにＤＲＣチャネルを使用してもよい。ＡＴとＡＮに関してサーバ選択を促進するＤＳＣチャネルの使用の例が以下に述べられる。

図２Ｂおよび２Ｃは、「１ｘＥＶ−ＤＯリリース０」および「１ｘＥＶ−ＤＯレビジョン１」型システムにおけるソフトハンドオフ・タイムラインの比較を示す。例証と明瞭さのため、最小のナルＤＲＣカバーの場合だけが明示的に示される。ソフトハンドオフおよびソフターハンドオフの両方について、ＤＲＣ再指示の前に何らかの進行中のパケットがある場合、ＡＴは、パケットの全部が満了するまでナルＤＲＣカバーを送かもしれないことに注意せよ。（これは、「１ｘＥＶ−ＤＯリリース０」および「１ｘＥＶ−ＤＯレビジョンＡ」型システムの両方での場合である）。

ＤＳＣは変更することが許されるところで、ＤＳＣは予め定められた境界をもつように構成されてもよい。例えば、ＤＳＣは以下のようなスロットＴで変更してもよい。

（Ｔ＋１＋１５×ＦｒａｍｅＯｆｆｓｅｔ）ｍｏｄＤＳＣＬｅｎｇｔｈ＝０ 式（２）
ここに、ＤＳＣＬｅｎｇｔｈは所定個数のスロットの持続（例えば、１６スロット）かもしれない。上に記述されるように、ＤＲＣはスロットＴで以下のように変更してもよい。

（Ｔ＋１−ＦｒａｍｅＯｆｆｓｅｔ）ｍｏｄＤＳＣＬｅｎｇｔｈ＝０ 式（３）
ＤＳＣは送信が終わってから１スロットの効果を生じ、実際にＤＳＣＬｅｎｇｔｈスロットにとどまってもよい；ところが、ＤＲＣは送信が終わってから半分のスロットの効果を生じ、実際にＤＲＣＬｅｎｇｔｈと等しい数のスロットにとどまってもよい。

ＤＲＣはＤＳＣに一致してもよい。例えば、ＤＲＣカバーがセクタ・カバーである場合、ＤＳＣによって示されたデータソースはＡＴの活発な組に含まれており、データソースに関連したＤＲＣＬｏｃｋビットは「１」に設定され、したがってＤＲＣカバーによって示されたセクタは、ＤＲＣの送信にしたがっている次のＤＲＣＬｅｎｇｔｈスロット中に実際に存在するＤＳＣによって示されたデータソースに属してもよい。

ＤＳＣはハンドオフの初期の表示として使用されてもよく、それによって、ＡＰとＡＮＣの間で、キュー・トランスファ（即ち、「Ｑ転送」）に関連したサービス供給停止が、最小化されるかまたは本質的に除去されることを可能にする。実施例では、ＡＴの活発な組中の複数のＡＰは、ＤＳＣ長さ境界（例えばスロット単位で）より前にＤＳＣを検知することを試みてもよい。任意のセクタがＤＳＣの可能な変更を報告する場合、ＡＮＣは、ＡＴの活発な組におけるセクタのうちのいくつかまたはすべてへ、促進フロー（ＥＦ）アプリケーション（例えば、ＶｏＩＰパケットのような遅れに敏感なデータ）に関連したデータをマルチキャストし始めてもよい。マルチキャスト・メカニズムの例はさらに以下に述べられる。マルチキャストは、ＤＲＣカバーがそれを指し始める場合に、セクタＢがサービスに準備することを可能にする。

ナル・カバーの最低２つのＤＲ長さがまた、ソフトおよびソフターハンドオフのための「１ｘＥＶ−ＤＯ レビジョンＡ」型システムにおいて必要であるかもしれない。そのように、ソフトハンドオフにおけるＥＦデータのためのサービス供給停止はナル・カバーの２つのＤＲＣＬｅｎｇｔｈｓに減らされるかもしれない。ソフターハンドオフについては、それはナル・カバーの２つのＤＲＣＬｅｎｇｔｈｓのままであるかもしれない。そのようなシステムでのソフトハンドオフおよびソフターハンドオフの間の差は、任意のＤＲＣ変更境界において後者が起こるということかもしれない。

例の方法により、図３は２つのスロットのＤＲＣＬｅｎｇｔｈおよび８つのスロットのＤＳＣＬｅｎｇｔｈのためのＤＳＣチャネル・タイムラインの実施例を示す。

図４は、ＤＲＣカバー変更の実施例を示す。ＤＲＣ ＡおよびＤＲＣ Ｂは、それぞれセルＡおよびセルＢに関連したＤＲＣカバーを表わす。ＤＲＣ ＮＵＬＬは、ナル・カバーを備えたＤＲＣを示す。ＰＫＴ ＡまたはＰＫＴ Ｂは、セルＡまたはセルＢからの新しいパケットの潜在的なスタートを示す。ＰＫＴ ＮＵＬＬは、ナル・カバーされたＤＲＣのために新しいパケットがないことを示す。

いくつかの実施例では、厳しい長期的なインバランスを回避するために、ＤＳＣは弱い逆方向リンクによりセルを指さなくてもよい。例えば、ＡＴがその活発な組のセクタから「０」に設定されたＤＲＣＬｏｃｋビットを受信する場合、ＡＴは、そのセクタに関連したデータソースにそのＤＳＣを指示しなくてもよい（例えば、ソフトハンドオフを始めるＡＴを回避するため）。

ソフトハンドオフ中に、ＤＳＣ／ＤＲＣ再指示は、例えば、最悪の場合に２つのＤＳＣＬｅｎｇｔｈｓまで遅らせるかもしれない。その結果、短いＤＳＣＬｅｎｇｔｈは悪いチャネル条件により遅れおよび可能なサービスの低下を減少するのに望ましいかもしれない。他方では、より高い送信電力はそのような場合、ＤＳＣチャネル信頼度を維持するために必要かもしれない。したがって、より短い遅れの利益に対して追加のオーバヘッドを評価する必要がある。

ＤＳＣ／ＤＲＣ再指示は、例えば、異なるセクタからのフィルタにかけられた順方向リンクＳＩＮＲ測定に基づいて、ＡＴによって始められてもよい。一次の無限のインパルス応答（ＩＩＲ）フィルタが使用され得る（例えば、６４スロットの時定数で）。セクタＡに現在のサービス・セクタ、およびＡＴの活発な組中の他のセクタをセクタＢとしよう。ここに「クレジット」と名付けられ、Ｃ_Ｂによって表示されたパラメータは、セクタＢのために維持され、以下のように更新されてもよい：
Ｃ_Ｂ（ｎ＋１）＝ｍａｘ（０，Ｃ_Ｂ（ｎ）＋Δ（ｎ）） 式（４）
ここに、

上記において、ＳＩＮＲ_Ａ（ｎ）およびＳＩＮＲ_Ｂ（ｎ）はそれぞれフィルタをかけられたパイロットＳＩＮＲ測定値を表わし、また、ｎは時間インデックス表す。ＸとＹは予め定められた閾値（例えば、ｄＢで測られた）であるかもしれない。ここに「ＳｏｆｔｅｒＨａｎｄｏｆｆＤｅｌａｙ」および「ＳｏｆｔＨａｎｄｏｆｆＤｅｌａｙ」と名付けられた２つのハンドオフ・パラメータは、ＡＴがそれぞれ同じおよび異なるセルに属するソースセクタから目標セクタへＤＲＣを切換える場合、最小の割込み／遅延時間に関係している。いくつかの実施例では、そのようなハンドオフ・パラメータの値はスロットの単位（例えば、８つのスロット）であってもよい。例えば、ＳｏｆｔｅｒＨａｎｄｏｆｆＤｅｌａｙ＝８スロット、およびＳｏｆｔＨａｎｄｏｆｆＤｅｌａｙ＝６４スロットが使用されてもよい（例えば、「１ｘＥＶ−ＤＯリリース０」または「１ｘＥＶ−ＤＯレビジョンＡ」型システムのいずれかで）。これらのパラメータは、例えば蓄積されたクレジットを閾値と比較するのに使用される。

「１ｘＥＶ−ＤＯリリース０」型システムにおいて、ソフトおよびソフターハンドオフの両方のために、再指示に必要とされるクレジットの数はＳｏｆｔＨａｎｄｏｆｆＤｅｌａｙと等しいかもしれない。ハンドオフがサービス供給停止を引き起こすので、クレジットの大きな閾値はＡＴハンドオフを始める頻度を制限するかもしれない。

「１ｘＥＶ−ＤＯレビジョンＡ」型システムでは、サービス供給停止の減少により、より小さな閾値が使用されてもよい。例えば：
・ＡＴがソフターのみのハンドオフにある場合（例えば、同じセルに属するその活発な組のすべてのメンバー）、クレジット上の閾値は最大（１，ＳｏｆｔｅｒＨａｎｄｏｆｆＤｅｌａｙ−ＤＲＣＬｅｎｇｔｈ）により与えられてもよい；
・そうでなければ、閾値は最大（１，ＳｏｆｔＨａｎｄｏｆｆＤｅｌａｙ−ＤＳＣＬｅｎｇｔｈ）により与えられてもよい。

閾値がＡＴの活発な組の構成によって（ＡＴが再指示しようとしているそのセクタに対立するものとして）決定されてもよいことに注意を要す。クレジットは、ソフター再指示のためのＤＲＣ変更境界およびソフト再指示のためのＤＳＣ境界で計算され得る。頻繁なＤＳＣ／ＤＲＣ再指示を回避するために、ＡＴがタイマの満了前に別に再指示を開始しないように、ソフト／ソフター再指示が起こるとき、タイマがセットされてもよい。いくつかの実施例では、タイマ満了期間は、ＳｏｆｔｅｒＨａｎｄｏｆｆＤｅｌａｙとＳｏｆｔＨａｎｄｏｆｆＤｅｌａｙとでそれぞれ等しいかもしれない。（そのように、ＳｏｆｔｅｒＨａｎｄｏｆｆＤｅｌａｙとＳｏｆｔＨａｎｄｏｆｆＤｅｌａｙは、ソフターおよびソフトハンドオフのコストを表示してもよい）。

「１ｘＥＶ−ＤＯリリース０」型システムでは、セクタに再指示と関係するＡＰからＡＮＣへ２つのメッセージがあってもよい：例えば、セクタＡからのここに「ＦｏｒｗａｒｄＳｔｏｐｐｅｄ」と名付けられたメッセージ、およびセクタＢからのここに「ＦｏｒｗａｒｄＤｅｓｉｒｅｄ」と名付けられた別のメッセージ。これらのメッセージは、セクタＡからセクタＢへのＱ転送を実行するため、ＡＮＣにより処理され、サービス供給停止はこのＱ転送と関係している（図２Ｂで示されたように）。「１ｘＥＶ−ＤＯレビジョンＡ」型システムにおいて、連続データサービス（例えば、ＥＦデータ／フロー）は、ＤＳＣチャネルの使用によって可能になるかもしれない。そのようなものは、ＤＳＣ変更境界の前にＤＳＣチャネルをデコードし、ＤＳＣ境界における早期検出および最終検出の間で、ＡＴの活発な組中の幾つかまたはすべてのセクタに対して、ＡＮＣにデータをマルチキャストさせることにより実行されてもよい。いくつかの状況で、逆送トラヒックへの衝撃を制限するように、マルチキャストはＥＦ適用（例えば、ＶｏＩＰデータのような遅れに敏感なデータ）にのみ適用され得る。

実施例において、ＡＴの活発な組中の各セクタはＤＳＣチャネルをデコードすることを試みてもよい。最終決定はここにＴ_ｄとして表わされるＤＳＣ境界でなされる。Ｔ_ｄにおいて、蓄積されたエネルギーが閾値より大きい場合、最大に蓄積されたエネルギーを有するＤＳＣ値は次のＤＳＣＬｅｎｇｔｈに対して実際にＤＳＣとして宣言され、そうでなければ、ＤＳＣ消去が宣言され得る。

Ｑ転送を容易にしおよびＴ_ｄのまわりの多重スロット・パケットを制限するために、初期決定が望ましいかもしれない。例えば、各ＡＰは、予め定められた（例えば、システム全体で構成された）スロットの数（例えば、１２スロット）によりＴ_ｄを進行する時間Ｔ_ｐｄでＤＳＣ復号決定を提供してもよい。同じエネルギー閾値がＴ_ｄで最終決定として使用されてもよい。これらの早期検出が最終決定として信頼できない状況があってもよい；しかしながら、そのようなものは、Ｔ_ｐｄとＴ_ｄの間のデータ送信のマルチキャスト特質によって補正されてもよい。

次の用語が、ＡＮＣとＡＰ（例えば、ＡＴの活発な組中のもの）の間のマルチキャストを含む状況で使用されてもよい：
・ サービスＡＰ：ＡＮＣへメッセージ（例えば、ＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄ）を広告しており、ＡＮＣへ第２のメッセージ（例えば、ＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄ）を広告するまで、サービスＡＰと見なされるＡＰ。（サービス・セクタは、サービスＡＰによってサービスされたセクタを指す）。

・ 活発なサービスＡＰ：ＡＮＣへＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄメッセージを広告しており、ＡＴにデータをサービスしているＡＮＣによって考慮されるＡＰ。

・ 非サービスＡＰ：ＡＮＣへＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄメッセージを広告しており、ＡＮＣへＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄメッセージを広告するまで、非サービスＡＰと見なされるＡＰ。（非サービス・セクタは、非サービスＡＰによってサービスされたセクタを指す）。

ＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄとＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄのメッセージに加えて、ＤＳＣチャネルに関連したデコードされた値の変化をＡＮＣに示すために、ここに「ＤＳＣＣｈａｎｇｅｄＩｎｄ」と名付けられた新しいメッセージがＡＰによって使用されてもよい。この指示はＡＴの活発な組中の任意のサービスＡＰによって出され、以下のうちの１つを示す：
・ ＡＴがハンドオフするように意図するＡＰの識別を示すＤＳＣ値。この場合、ＤＳＣ変更時間も提供され、示されたＤＳＣ値が効果を現わす時を示す。

・ ＡＰがＤＳＣチャネルを成功裡にデコードすることができなかったことを示す消去。

ハンドオフ・メッセージは以下条件の下で生成され、以下にテーブル１で示される：
・ ＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄ：ＡＰはＡＴから受信したＤＳＣチャネルを成功裡にデコードし、デコードされたＤＳＣ値はそれ自身の（または自己）ＤＳＣ値と同じである。これはＴ_ｐｄとＴ_ｄで生成されるかもしれない。

・ ＤＳＣＣｈａｎｇｅｄＩｎｄ（消去された）：ＡＰはＡＴから受信したＤＳＣチャネルをデコードすることができない。これはＴ_ｐｄとＴ_ｄで生成されるかもしれない。

・ ＤＳＣＣｈａｎｇｅｄＩｎｄ（変更された）：ＡＰはＡＴから受信したＤＳＣチャネルを成功裡にデコードし、デコードされたＤＳＣ値はそれ自身のＤＳＣ値とは異なる。これはＴ_ｐｄで生成されるかもしれない。

・ ＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄ：ＤＳＣ値がスロットの構成可能な数に対するそれ自身のＤＳＣ値と同じではないことをＡＰが成功裡に決めた場合、これが生成される。これはＴ_ｄで生成されるかもしれない。

以下のテーブル１は、ハンドオフ中のメッセージと時刻の組合せを示す。

いくつかの状況で、様々なハンドオフ・メッセージは以下を除いてＡＮＣで任意の順に受信されるかもしれない：ＤＳＣＣｈａｎｇｅｄＩｎｄは直ちにＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄに続かないかもしれない。

ＡＮＣは、次のイベントのうちの１つの受信上でマルチキャスト状態に入るかもしれない：
・ 活発なサービスＡＰからのＤＳＣＣｈａｎｇｅｄＩｎｄ。ＤＳＣＣｈａｎｇｅｄＩｎｄの受信は、ＤＳＣチャネルの状態が変わったことを示す。そのようなものは、ＤＳＣチャネルデコーディングが成功し、ＤＳＣが他のＡＰを指しているか、または、ＤＳＣチャネルデコーディングが失敗であるかのいずれかを示唆するかもしれない。

・ ＡＴの活発な組中の非サービスＡＰに導くサービスＡＰからのＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄ。

ＡＴの活発な組における１つのサービスＡＰだけがあり、それがどんなＤＳＣ変更も報告していない場合、ＡＮＣはマルチキャスト状態を出るかもしれない。

オリジナルのサービス・セクタがＡＴの活発な組の外に落とす場合、それはＡＮＣにＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄメッセージを送り、マルチキャスト・メカニズムはこの状況を通常取り扱うかもしれない。いくつかの実施例では、ＡＮＣとＡＰの間のデータはユーザ・データグラム・プロトコル（ＵＤＰ）を使用して送信されるかもしれず、一方シグナリングメッセージは信頼性のため送信制御プロトコル（ＴＣＰ）を使用して送信されているかもしれない。

図５は第１のソフトハンドオフ・シナリオで起こるイベントのシーケンスの実施例を示し、そこでは、活発なサービスＡＰ（または単純化のため「ＡＰ１」）および非サービスＡＰ（または単純化のため「ＡＰ２」）の両方が、ＤＳＣ変更を正確に検知することができる。図５で示された様々なステップにおいて：
１．ＡＰ１はＤＳＣチャネルをデコードし、ＡＴがそのＤＳＣをＡＰ１にもはや指示していないことを決める。ＡＰ１は続いてＡＮＣにＤＳＣＣｈａｎｇｅｄＩｎｄメッセージを送り、それは新しいＤＳＣ値、現在の待ち行列レベル、予測された切換え時間などを含んでいてもよい。

２．ＡＮＣは、マルチキャスト状態、例えば、ＡＴの活発な組中のすべてのＡＰに順方向トラヒック（例えば、ＥＦデータ）をマルチキャストする起動に入る。

３．ＡＰ２は、成功裡に時間Ｔ_ｐｄ１でＤＳＣチャネルをデコードし、ＡＮＣにＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄメッセージを送る。

４．時間Ｔ_ｄ１では、ＡＰ１は、ＡＴがＡＰ２に切換わっていると結論を下し、ＡＮＣにＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄメッセージを送る。

５．ＡＮＣは、ＡＰ２であるべきＡＴのために活発なサービスＡＰを設定し、マルチキャストをやめて、ＡＰ２のみに順方向トラヒックを送り始める。

図６は第２のソフトハンドオフ・シナリオで起こるイベントのシーケンスの実施例を示し、そこでは、活発なサービスＡＰ（または「ＡＰ１」）はＤＳＣ変更を正確に検知することができ、また、非サービスＡＰ（または「ＡＰ２」）はＤＳＣ消去を検知する。図６で示された様々なステップにおいて：
１．ＡＰ１はＤＳＣチャネルをデコードし、ＡＴがそのＤＳＣをＡＰ１にもはや指さないことを決める。ＡＰ１は続いてＡＮＣへＤＳＣＣｈａｎｇｅｄＩｎｄメッセージを送り、それは新しいＤＳＣ値、現在の待ち行列レベル、予測された切換え時間などを含んでいてもよい。

２．ＡＮＣは、マルチキャスト状態、例えば、ＡＴの活発な組中のすべてのＡＰへ順方向トラヒックをマルチキャストする起動に入る。

３．ＡＰ２は成功裡にＤＳＣチャネル（それはそれ自体を指している）をデコードし、ＡＮＣにＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄメッセージを送る。

４．ＡＰ２はＤＳＣ消去をデコードし、ＡＮＣにＤＳＣＣｈａｎｇｅｄＩｎｄメッセージを送る。

５．時間Ｔ_ｄ１において、ＡＰ１は、ＡＴがＡＰ２に切換わっていると結論を下し、ＡＮＣにＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄメッセージを送る。ＡＮＣは、ＡＰ２であるべきＡＴのために活発なサービスＡＰを設定する。

６．ＡＰ２は成功裡により多くのＤＳＣ記号（それらはそれ自身の値と同じである）をデコードする。ＡＰ２がたった今ＡＮＣにＤＳＣＣｈａｎｇｅｄＩｎｄメッセージを送ったので、それは、ＡＴがＡＰ２へ実際に切換わっていることをＡＮＣで確認するため他のＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄメッセージを送る。

７．ＡＮＣはマルチキャストすることを止め、ＡＰ２のみに順方向トラヒックを送ることを始める。

図７は、第３のソフトハンドオフ・シナリオで起こるイベントのシーケンスの実施例を示し、そこでＤＳＣ消去の後、活発なサービスＡＰ（または「ＡＰ１」）がＤＳＣ変更を検知し、非サービスＡＰ（または「ＡＰ２」）がＤＳＣ変更を正確に検知することができる。図７で示された様々なステップにおいて：
１．ＡＰ２は成功裡にＤＳＣチャネル（それはそれ自身の値と同じである）をデコードし、ＡＮＣにＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄメッセージを送る。

２．ＡＮＣは、マルチキャスト状態、例えば、ＡＴの活発な組中のすべてのＡＰへ順方向トラヒックをマルチキャストする起動に入る。

３．時間Ｔ_ｄ１において、ＡＰ１はＤＳＣ消去をデコードし、ＡＮＣにＤＳＣＣｈａｎｇｅｄＩｎｄメッセージを送る。

４．ＡＰ１はＤＳＣチャネル（それは異なるＡＰを指している）をデコードし、ＡＮＣにＤＳＣＣｈａｎｇｅｄＩｎｄメッセージを送る。

５．時間Ｔ_ｄ２において、ＡＰ１は、ＡＴがＡＰ２に切換わっていると結論を下し、ＡＮＣにＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄメッセージを送る。ＡＮＣは、ＡＰ２であるべきＡＴのために活発なサービスＡＰを設定する。

６．ＡＮＣはマルチキャストすることを止め、ＡＰ２のみに順方向トラヒックを送ることを始める。

図８は、第４のソフトハンドオフ・シナリオで起こるイベントのシーケンスの実施例を示し、そこでは、活発なサービスＡＰ（または「ＡＰ１」）はＤＳＣ消去から回復し、非サービスＡＰ（または「ＡＰ２」）はＤＳＣ消去から回復する。図８で示された様々なステップにおいて：
１．ＡＰ１はＤＳＣ消去をデコードし、ＡＮＣにＤＳＣＣｈａｎｇｅｄＩｎｄメッセージを送る。

２．ＡＮＣは、マルチキャスト状態、例えば、ＡＴの活発な組中のすべてのＡＰへ順方向トラヒックをマルチキャストする起動に入る。

３．ＡＰ２は成功裡にＤＳＣ（それはそれ自体を指している）をデコードし、ＡＮＣにＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄメッセージを送る。

４．ＡＰ２はＤＳＣ消去をデコードし、ＡＮＣにＤＳＣＣｈａｎｇｅｄＩｎｄメッセージを送る。

５．時間Ｔ_ｄ１において、ＡＰ１は、ＡＴがＡＰ２に切換わっていると結論を下し、ＡＮＣにＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄメッセージを送る。ＡＮＣは、ＡＰ２であるべきＡＴのために活発なサービスＡＰを設定する。

６．ＡＰ２は成功裡により多くのＤＳＣ記号（それらはそれ自身の値と同じである）をデコードする。ＡＰ２がたった今ＡＮＣにＤＳＣＣｈａｎｇｅｄＩｎｄメッセージを送ったので、それは、ＡＴがＡＰ２へ実際に切換わっていることをＡＮＣで確認するため他のＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄメッセージを送る。

７．ＡＮＣはマルチキャストすることを止め、ＡＰ２のみに順方向トラヒックを送ることを始める。

他のハンドオフ・シナリオおよび実施がある。例えば、いくつかの実施例では、ＡＮＣは、マルチキャスト状態にあるＡＴの活発な組中のＡＰの部分集合に順方向トラヒック（例えば、ＥＦデータ）をマルチキャストするかもしれない。上に示されるように、マルチキャストの使用はサービスまたは非サービス・セクタでＤＳＣ消去か誤りを補償するかもしれない。

活発なサービスＡＰが間違ったＤＳＣ検知をなし、それ自体を指すＤＳＣをまだ予期している場合、ＤＳＣＣｈａｎｇｅｄＩｎｄメッセージは送られないかもしれない。従って、他のＡＰがＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄメッセージを送っても、マルチキャスト状態はＴ_ｐｄまたはＴ_ｄで開始しないかもしれない。言いかえれば、ＤＳＣＣｈａｎｇｅｄＩｎｄメッセージが活発なサービス・セクタから送られた後だけ、マルチキャスト状態は開始するかもしれない。

いくつかの実施例において、ＡＰがＤＳＣＣｈａｎｇｅｄＩｎｄまたはＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄのメッセージをＡＮＣに送る場合、それはまたその待ち行列情報を送るかもしれない。例えば、メッセージは送られた最終バイトを示すかもしれない。

いくつかの実施例では、マルチキャスト状態の終わりに、ＡＮＣは、例えば、それぞれのデータ待ち行列をフラッシュするために、もはやサービス・セクタと見なされないすべてのＡＰに命令を発送するかもしれない。これらの命令は、フローの開始および閉鎖とともに送信期間をマークする。ＡＮＣは、各送信期間のために漸増的に（例えば「１」の単位によって）変わるタグ番号でそれが発送する各パケットを関連付けるかもしれない。そのようなものはＡＰでパケットを唯一に識別するのに有用であるかもしれない。

図９は、いくつかの示された実施例（上に記述されたような）を実施するために使用されるかもしれない処理９００のフローチャートを示す。ステップ９１０は複数のＡＰ（例えば、ＡＴの活発な組における）によってサービスされた複数のセクタの各々と関連した順方向リンク（ＦＬ）品質測定基準を決定する。ステップ９２０は決定されたようにＦＬ品質測定基準に関して各セクタにクレジット最高を割り当てる。ステップ９３０は、ＤＳＣ変更境界における非サービス・セクタのために蓄積されたクレジットが予め定められた閾値より大きいかどうか判断し、ここに非サービス・セクタはＡＴのためのサービスＡＰと異なる非サービスＡＰによってサービスされる。ステップ９３０の結果が「ＹＥＳ」である場合、ステップ９４０に続き、サービスＡＰから非サービスＡＰへＤＳＣ値を変更する。ステップ９５０は複数のＡＰにＤＳＣ値を送信する。ステップ９６０はＤＳＣ変更（例えば、ＤＲＣカバーを非サービス・カバーに再指示すること）に従ってＤＲＣカバーを変更する。ステップ９３０の結果が「ＮＯ」である場合、処理９００はステップ９１０に返る。

図１０はいくつかの示された実施例（上に記述したような）を実施するために使用されるかもしれない処理１０００のフローチャートを示す。ステップ１０１０はＡＴ（図９の実施例に記述したような）から受信されたＤＳＣ値をデコードする。ステップ１０２０は、復号が成功するかどうか判断する。ステップ１０２０の結果が「ＹＥＳ」である場合、ステップ１０３０はデコードされたＤＳＣ値に変更があるかどうか判断する。ステップ１０３０の結果が「ＹＥＳ」である場合、ステップ１０４０に続き、ＤＳＣＣｈａｎｇｅｄＩｎｄメッセージをＡＮＣへ送る。ステップ１０３０の結果が「ＮＯ」である場合、処理１０００はステップ１０１０に返る。ステップ１０２０の結果が「ＮＯ」である場合、ステップ１０５０に続き、ＤＳＣＣｈａｎｇｅｄＩｎｄ（消去）メッセージをＡＮＣへ送る。

図１１はいくつかの示された実施例（上に記述したような）を実施するために使用されるかもしれない処理１１００のフローチャートを示す。ステップ１１１０はＡＴ（図９の実施例に記述したような）から受信されたＤＳＣ値をデコードする。ステップ１１２０は、デコードされたＤＳＣ値が自分自身の値（例えば、非サービスＡＰの値）に等しいかどうか判断する。ステップ１１２０の結果が「ＹＥＳ」である場合、ステップ１１３０が続き、ＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄメッセージをＡＮＣへ送る。ステップ１１２０の結果が「ＮＯ」である場合、処理１１００はステップ１１１０に返る。

図１２はいくつかの示された実施例（上に記述したような）を実施するために使用されるかもしれない処理１２００のフローチャートを示す。処理１２００はステップ１２０５でスタートする。ＤＳＣＣｈａｎｇｅｄＩｎｄメッセージがサービスＡＰ（例えば、上に記述されたＡＰ１）から受信したかどうかをステップ１２１０が判断する。ステップ１２１０の結果が「ＹＥＳ」である場合、ステップ１２２０が続き、ＡＴと関連した順方向トラヒック（例えば、ＥＦデータ）を複数のＡＰ（例えば、ＡＴの活発な組のもの）にマルチキャストし始める。ＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄメッセージが非サービスＡＰ（例えば、上に記述されたＡＰ２）から受信されたかどうかをステップ１２３０が判断する。ＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄメッセージがＡＰ１から受信されたかどうかステップ１２４０で判断する。両方のステップ１２３０および１２４０の結果が「ＹＥＳ」である場合、ステップ１２５０が続き、ＡＴのための活発なサービスＡＰであるべきＡＰ２を割り当てる。ステップ１２３０またはステップ１２４０のいずれかの結果が「ＮＯ」である場合、処理１２００はステップ１２２０に返る。

図１２において、ステップ１２１０の結果が「ＮＯ」である場合、ステップ１２６０に続き、ＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄメッセージが非サービスＡＰ（例えば、上に記述されたＡＰ２）から受信されているかどうか決定する。ステップ１２６０の結果が「ＹＥＳ」である場合、ステップ１２７０が続き、ＡＴに関連した順方向トラヒック（例えば、ＥＦデータ）を複数のＡＰ（例えば、ＡＴの活発な組のもの）へマルチキャストし始める。ＤＳＣＣｈａｎｇｅｄＩｎｄメッセージがサービスＡＰ（例えば上に記述されたＡＰ１）から受信されたかどうかステップ１２８０が判断する。ＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄメッセージがＡＰ１から受信されたかどうかステップ１２９０が判断する。両方のステップ１２８０および１２９０の結果が「ＹＥＳ」である場合、処理１２００はステップ１２５０に移る。ステップ１２８０またはステップ１２９０のいずれかの結果が「ＮＯ」である場合、処理１２００はステップ１２７０に返る。ステップ１２６０の結果が「ＮＯ」である場合、処理１２００はステップ１２０５に返る。

図１３は、いくつかの示された実施例（上に記述したような）が実施されるかもしれない装置１３００のブロック図を示す。例の方法により、装置１３００は、複数のＡＰ（例えば、ＡＴの活発な組のもの）によりサービスされた複数のセクタの各々に関係している順方向リンク品質測定基準を決定するように構成されたチャネル品質推定ユニット（またはモジュール）１３１０；ＦＬ品質測定基準に関しての各セクタにクレジットを割り当てるように構成されたクレジット割り当てユニット１３２０；ＡＴ（例えば、ＤＳＣ変更境界において非サービス・セクタのために蓄積されたクレジットが予め定められた閾値より大きな場合）のためのＤＳＣ値を選択／変更するように構成されたＤＳＣ選択ユニット１３３０；複数のＡＰにＤＳＣ値を送信するように構成された送信ユニット１３４０；およびＤＳＣ変更に従ってＤＲＣカバーを選択／変更するように構成されたＤＲＣ選択ユニット１３５０を含んでいるかもしれない。

装置１３００では、チャネル品質推定ユニット１３１０、クレジット割り当てユニット１３２０、ＤＳＣ選択ユニット１３３０、送信するユニット１３４０およびＤＲＣ選択ユニット１３５０は、通信バス１３６０に接続されるかもしれない。演算処理装置１３７０および記憶装置１３８０も通信バス１３６０に接続されるかもしれない。演算処理装置１３７０は様々なユニットの作動を制御および/または調整するように構成されるかもしれない。記憶装置１３８０は、演算処理装置１３７０によって実行される命令を具体化するかもしれない。

装置１３００は、ＡＴ（例えば、図１の中のＡＴ１０６）、または他の通信装置で実施されるかもしれない。

図１４はいくつかの示された実施例（上に記述したような）を実施するために使用されるかもしれない装置１４００のブロック図を示す。例の方法により、装置１４００は、ＡＴから受信されたＤＳＣ値を決定するように構成された復号装置（またはモジュール）１４１０；ＤＳＣ復号（例えば、上に記述されたようなＤＳＣＣｈａｎｇｅｄＩｎｄ、ＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄ、ＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄメッセージまたは同種のもの）に従ってメッセージを生成するように構成されたメッセージ生成ユニット１４２０；およびＡＮＣにこのように生成されたメッセージを送るように構成された送信ユニット１４３０を含んでいるかもしれない。

装置１４００では、復号装置１４１０、メッセージ生成ユニット１４２０および送信ユニット１４３０が通信バス１４４０に接続されるかもしれない。演算処理装置１４５０および記憶装置１４６０も通信バス１４４０に接続されるかもしれない。演算処理装置１４５０は様々なユニットの作動を制御および/または調整するように構成されるかもしれない。記憶装置１４６０は演算処理装置１４５０によって実行される命令を具体化するかもしれない。

装置１４００は、ＡＰ（例えば、上に記述されたＡＰ１またはＡＰ２）、または他のネットワーク・インフラストラクチャ要素で実施されるかもしれない。

図１５はいくつかの示された実施例（上に記述したような）を実施するために使用されるかもしれない装置１５００のブロック図を示す。例の方法で、装置１５００は、ＡＰからメッセージ（例えば、上に記述されたＡＰ１またはＡＰ２からのＤＳＣＣｈａｎｇｅｄＩｎｄ、ＦｏｒｗａｒｄＤｅｓｉｒｅｄＩｎｄまたはＦｏｒｗａｒｄＳｔｏｐｐｅｄＩｎｄメッセージ）を受信するように構成されたメッセージ処理ユニット（またはモジュール）１５１０；複数のＡＰ（例えば、ＡＴの活発な組のもの）へのＡＴに関連した順方向トラヒック（例えば、ＥＦデータ）をマルチキャストするように構成されたマルチキャスティング・ユニット１５２０；およびＡＴのために活発なサービスＡＰを選ぶように構成されたサーバ選択ユニット１５３０を含んでいるかもしれない。

装置１５００では、メッセージ処理ユニット１５１０、マルチキャスティング・ユニット１５２０およびサーバ選択ユニット１５３０は通信バス１５４０に接続されるかもしれない。演算処理装置１５５０および記憶装置１５６０も通信バス１５４０に接続されるかもしれない。演算処理装置１５５０は様々なユニットの作動を制御および/または調整するように構成されるかもしれない。記憶装置１５６０は、演算処理装置１５５０によって実行される命令を具体化するかもしれない。

装置１５００は、ＡＮＣ（上に記述されたような）、または他のネットワーク制御装置手段で実施されるかもしれない。

逆方向リンク・オーバヘッド・チャネル（例えば、ＤＲＣ、ＤＳＣ、逆方向レート指標（ＲＲＩ）、肯定応答（ＡＣＫ）チャネル、など）の送信電力は、パイロット送信電力に固定オフセットで結び付けられるかもしれない。後者は、内側ループ電源制御装置および外側ループ電源制御装置を含んでいるかもしれない電源制御装置によって制御されるかもしれない。例えば、内側ループ電源制御装置は、閾値のまわりであるＡＰにおける受信パイロット電力を維持するように構成され、閾値は次に外側ループ電源制御装置によって決定される。いくつかの状況で、外側ループ電源制御装置による閾値調節はデータ・チャネル性能に基づいているかもしれない。その結果、オーバヘッド・チャネル性能は別々に考慮される必要があるかもしれない。これは、逆方向リンク上のソフトハンドオフの場合には特に重要かもしれない。理由は、オーバヘッド・チャネルではなく、ＡＮＣにおいて選択結合（例えば、ＡＴの活発な組中の複数のＡＰからの復号結果を組み合わせること）からデータ復号が利益を得るかもしれないからである。ＤＲＣ性能は特にインバランスがある状態で不足しているかもしれず、ここにＡＴはそれが最良の順方向リンクを持っている１つのセクタにおいてそのＤＲＣを指示するが、それがよりよい逆方向リンクを有する他のセクタによって電力制御される。

ＤＲＣチャネルに関しては、ＡＰが間違った復号を作り、そのようなものに基づいたパケット送信をスケジュールする場合、パケットが対応するＡＴによって受信されなくなり、送信スロットはすべて浪費で満了するかもしれない。ＡＰがＤＲＣチャネルを成功裡にデコードすることができず、ＤＲＣ消去を宣言する場合、ＡＴはサービスされなくてもよい。遅れに無感覚な（例えば、ベスト・エフォート）データ流を持った複数ユーザの状況で、これはセクタ容量の損害をほとんど引き起こさないかもしれない。したがって、合理的なＤＲＣ消去レートは、低いＤＲＣ復号誤り確率に関して許容されるかもしれない。ＤＲＣ復号中に、最大受信エネルギーを持ったＤＲＣ候補は閾値と比較されるかもしれない。エネルギーが閾値より大きい場合、この候補は実際にＤＲＣになるかもしれない；そうでなければ、ＤＲＣ消去は宣言されるかもしれない。ＤＲＣ送信電力がパイロット電力に結び付けられるので、ＤＲＣエネルギー上の閾値は、受信パイロット電力（ここに「Ｅｃｐ／Ｎｔ」と名付けられた）上の閾値と等価かもしれない。例の方法で、Ｅｃｐ／Ｎｔが例えば−２５ｄＢ程度下に落ちる場合、ＤＲＣ消去は宣言されるかもしれない。

セクタは、フィードバックループを介して、例えば、ＤＲＣＬｏｃｋビットによって、逆方向リンクＳＩＮＲまたはＤＲＣ消去レートをＡＴに供給するかもしれない。各セクタは評価された消去レートに従ってＡＴのためのＤＲＣＬｏｃｋビットを設定するかもしれない。例えば、「１」（「ロック内」）のＤＲＣＬｏｃｋビットは、ＤＲＣ消去レートが受入れ可能であることを示すかもしれない；「０」（「ロック外」）のＤＲＣＬｏｃｋビットは、ＤＲＣ消去レートが受入れがたいことを示すかもしれない。

いくつかのメカニズムが一貫して高い消去レートに悩まされるＡＴのための長い供給停止を回避するために工夫されるかもしれない：例えば、一つは順方向リンク上でＤＲＣＬｏｃｋビットを使用し、高い消去レートのＡＴに示し、かつＡＴをハンドオフへプロンプトする遅いメカニズムかもしれない；他のものはＤＲＣ消去マッピングなどの速いメカニズムかもしれない。

「１ｘＥＶ−ＤＯリリース０」型システムでは、例えば、ＤＲＣＬｏｃｋビットは電源制御チャネルで時分割多重化されるかもしれない。それはＤＲＣＬｏｃｋＰｅｒｉｏｄスロット毎に一度送信され、ＤＲＣＬｏｃｋＬｅｎｇｔｈ毎に繰り返されるかもしれない。（等価なフィードバック・レートは、例えば［６００／（ＤＲＣＬｏｃｋＰｅｒｉｏｄ×ＤＲＣＬｏｃｋＬｅｎｇｔｈ）］Ｈｚかもしれない。）例えば、ＤＲＣＬｏｃｋＰｅｒｉｏｄとＤＲＣＬｏｃｋＬｅｎｇｔｈのためのデフォルト値は８スロットかもしれない。「１ｘＥＶ−ＤＯレビジョンＡ」型システムにおいて、ＤＲＣＬｏｃｋビットは同じＭＡＣチャネルの同相および直角位相上の電源制御ビットと共に送信されるかもしれない。ＤＲＣＬｏｃｋビットは、例えば４スロット毎に一度送信されるかもしれない。パラメータＤＲＣＬｏｃｋＬｅｎｇｔｈはＤＲＣＬｏｃｋビットのために維持されて繰り返すかもしれない。例えば、ＤＲＣＬｏｃｋＬｅｎｇｔｈのためのデフォルト値は１６スロットかもしれない。

ＤＲＣＬｏｃｋビットの値はフィルタにかけられたＤＲＣ消去レートに基づいているかもしれない。各ＤＲＣ消去イベントは２進値にマップされ、ＩＩＲフィルタを更新するために使用されるかもしれない。フィルタにかけられた値は、平均ＤＲＣ消去レートと見なされるかもしれない。例えば、ＩＩＲフィルタのためのデフォルト時定数は３２スロットかもしれない。ヒステリシスはフィルタにかけられたＤＲＣ消去レートを閾値化することに存在するかもしれない。例えば、フィルタにかけられた消去レートが３０％未満である場合、ＤＲＣＬｏｃｋビットは「１」に設定され、フィルタにかけられた消去レートが５０％以上にある場合、ＤＲＣＬｏｃｋビットは「０」に設定されるかもしれない。図１６はＤＲＣＬｏｃｋビットの設定に関連したヒステリシスの実施例を示し、ここにＤＲＣ消去イベントが比較的長い期間０（消去しない）または１（消去する）で一定に止まるかもしれない。このように記述されたフィルタ動作はＤＲＣＬｏｃｋビットを安定にしているが、チャネル変化にゆっくり反応するかもしれない。

ＤＲＣＬｏｃｋビットを設定する際の組み込みの遅れは長いＤＲＣ消去ランレングス（連続するＤＲＣ消去が生じる時限）を意味するかもしれない。これはハンドオフ中に考慮に入れられるかもしれない。ＥＦ（例えば、遅れに敏感な）データについては、これらの消去は受入れがたい量のサービス供給停止に帰着するかもしれない。したがって、順方向リンク上のサービス供給停止を最少化するように構成されたＤＲＣ消去マッピングアルゴリズムのための必要が存在する。

実施例では、ＤＲＣ消去マッピングアルゴリズムは各ＡＴのためにすべてのＤＲＣＬｅｎｇｔｈでＡＰにおいて行なわれるかもしれない。各ＡＴについて、アルゴリズムは、ＡＴのための活発な待ち行列（例えば、ユニキャストかマルチキャスト状態でＡＮＣによって設定された）を持っている各セルで行なわれるかもしれない。ＤＲＣ消去マッピングが活性化される場合、フローは、「制限のある」順方向リンク・スケジューリング（例えば、マルチユーザ・パケットによりサービスされるだけ）に適格であるかもしれない。ＤＲＣ消去マッピングのコストは、順方向リンク・チャネル品質を知ることなくデータを送出し、ＡＴがパケットをデコードすることができない場合、関連する送信スロットを浪費することから発生するかもしれない。したがって、いくつかの状況で、以下すべてに遭遇する場合、ＤＲＣ消去マッピングアルゴリズムは活性化されるかもしれない：
・ ＤＲＣ消去ランレングスが十分に長い。

・ スケジューラにより見られたパケット遅れが十分に長い。

閾値（例えば、ここに「Ｍａｘ＿Ｅｒｓ＿Ｌｅｎ」を名付けた）はＤＲＣ消去ランレングスに関係しているかもしれない。例えば、ＥＦデータ／フロー（例えば、ＶｏＩＰデータ）については、閾値のための設定は０〜１６のスロットの範囲にあるかもしれない。

ＤＲＣ消去マッピングは長いＤＲＣ消去ランレングスに対して強健である必要がある。例えば、ＡＴはサービス・セクタ切換えを行なうかもしれない；しかしながら、消去されたＤＲＣを受信しているセクタはこれに気づいていないかもしれない。この状況で、ＤＳＣチャネルは、さらに以下に示されるように、ＤＲＣ消去マッピング決定を支援するために、優待情報として使用されるかもしれない。

ＡＮＣとＡＰ（上に記述されたような）の間のマルチキャスティング・メカニズムに似ているので、さらに以下に述べられるように、ＤＲＣ消去マッピングアルゴリズムの頑強性を向上させるために、多数のセクタからＡＴへ空中による（ＯＴＡ）マルチキャスティングが行なわれるかもしれない。

図１７は、ＡＰがその活発な組においてこのＡＰを持っている各ＡＴのために行なう処理１７００の実施例を示す。処理１７００はステップ１７０５で開始する。ステップ１７１０は、ＡＴから受信したＤＲＣカバーが削除されるかどうか判断する。ステップ１７１０の結果が「ＮＯ」である場合、ステップ１７２０に続き、ＤＲＣカバーが指しているセクタからＡＴのための送信をスケジュールする。ステップ１７１０の結果が「ＹＥＳ」である場合、ステップ１７３０に続き、ＤＲＣカバー消去基準がＡＴからのＤＲＣカバーに対して合うかどうかを決定する。ＤＲＣカバー消去基準は、例えば、Ｍａｘ＿Ｅｒｓ＿Ｌｅｎなどより大きなＤＲＣ消去ランレングスを含んでいるかもしれない。ステップ１７３０の結果が「ＹＥＳ」である場合、ステップ１７４０に続き、ＡＴから受信されたＤＳＣ値が削除されるかどうかを決定する。ステップ１７４０の結果が「ＮＯ」である場合、ステップ１７５０に続き、ＤＳＣ値がＡＰ（ここに「このセル」と名付けられた）によってサービスされたセルに相当するかどうかを決定する。ステップ１７５０の結果が「ＹＥＳ」である場合、ステップ１７６０に続き、図１９がさらに示すように、ＯＴＡマルチキャスティング（例えば、ＡＴの活発な組、およびこのセルにある複数のセクタからＡＴに順方向トラヒックを送信する）を始める。ステップ１７４０の結果が「ＹＥＳ」である場合、処理１７００は同様にステップ１７６０に進む。

処理１７００において、ステップ１７５０の結果が「ＮＯ」である場合、処理１７００はステップ１７７０で終わる。ステップ１７３０の結果が「ＮＯ」である場合、処理１７００は同様にステップ１７７０に進む。

図１８Ａ−Ｉは、いくつかの実施例中の図１７で示された処理１７００を実行するために使用されるかもしれないいくつかの処理を示す。図１８Ａでは、ステップ１８１０は、ＡＴから受信したＤＲＣカバーが削除されないかどうか（例えば、Ｅｃｐ／Ｎｔが消去閾値より上か）、ＤＲＣカバー（即ち、「ＤＲＣ＿Ｃｏｖｅｒ」）はナルでないかどうか、また、ＤＲＣ＿Ｃｏｖｅｒが最後の成功裡にデコードされたＤＲＣカバー（ここに「ＬＤＣ」と名付けられた）またはＬＤＣと同じであるかどうか、および次に最後の成功裡にデコードされたＤＲＣカバー（ここに「２ＬＤＣ」と名付けられた）がナルであるかどうか判断する。これらのすべての決定の結果が「ＹＥＳ」である場合、ステップ１８１１に続き、最後の有効なＤＲＣカバー（即ち、「Ｌａｓｔ＿Ｖａｌｉｄ＿ＤＲＣ＿Ｃｏｖｅｒ」）をＤＲＣ＿Ｃｏｖｅｒであると設定し、ＤＲＣカバー変更（即ち、「ＤＲＣＣｏｖｅｒＣｈａｎｇｅｄＦｌａｇ」）に関連したフラグをゼロ（即ち、「０」）であると設定する。ＤＲＣＣｏｖｅｒＣｈａｎｇｅｄＦｌａｇはＡＴから受信したＤＲＣカバーに関係している一貫性を示すために使用されるかもしれず、それは、ＤＲＣカバーをＡＴからの１つ以上の前に受信されたＤＲＣカバーと比較することにより決定されるかもしれない。例えば、ＤＲＣＣｏｖｅｒＣｈａｎｇｅｄＦｌａｇは、ＤＲＣカバーがＡＴから前に受信されたＤＲＣカバー（例えば、ＬＤＣ）の少なくとも１つと一致している場合（例えば、本質的に同じまたは同等）、「０」であると設定されるかもしれない。ＤＲＣカバーが有効な場合（例えば、消去されないおよびナルでない）場合、ＤＲＣカバー変更がセクタ切換えによる場合などを含んで（しかし、限定するものではない）、ＤＲＣカバーに関連した一貫性を評価する際に予め定められた基準がまた適用されるかもしれない。

図１８Ｂでは、ステップ１８２０は、ＤＲＣカバーが削除されるかどうか（即ち、「ＤＲＣ＿Ｅｒａｓｕｒｅ」）判断する。ステップ１８２０の結果が「ＮＯ」である場合、ステップ１８２１に続き、（１）２ＬＤＣがＬＤＣである；（２）ＬＤＣがＤＲＣ＿Ｃｏｖｅｒである；（３）最後の有効なＤＲＣインデックス（即ち、「Ｌａｓｔ＿Ｖａｌｉｄ＿ＤＲＣ＿Ｉｎｄｅｘ」）がＤＲＣカバーに関連したＤＲＣレート（即ち、「ＤＲＣ＿Ｒａｔｅ」）である；そして（４）消去の数の計数（即ち、「Ｅｒａｓｕｒｅ＿Ｃｏｕｎｔ」）が「０」である：を設定する。ステップ１８２０の結果が「ＹＥＳ」である場合、ステップ１８２２に続き、Ｅｒａｓｕｒｅ＿ＣｏｕｎｔをＤＲＣＬｅｎｇｔｈによってインクリメントされるにように設定する。

図１８Ｃで、時間Ｔｄの各活発なＡＴについて、ステップ１８３０は、ＡＴから送信されたＤＳＣ値が削除されるかどうか、または、ＤＳＣ値は無効であるかどうか（例えば、ゼロの値を持っているか）を判断する。ステップ１８３０の結果が「ＹＥＳ」である場合、ステップ１８３１に続き、記憶されたＤＳＣ値（即ち、「Ｓｔｏｒｅｄ＿ＤＳＣ＿Ｖａｌｕｅ」）をこのセルに関連したＤＳＣ値（即ち、「Ｔｈｉｓ＿Ｃｅｌｌ＿ＤＳＣ＿Ｖａｌｕｅ」）である；ＤＳＣ消去に関連したフラグ（即ち、「ＤＳＣ＿Ｅｒａｓｅｄ＿Ｆｌａｇ」）を１（即ち、「１」）である；カウンタ（即ち、「ＳｔｏｐＤＲＣＥｒａｓｕｒｅＭａｐ＿ｄｕｅｔｏ＿ＤＳＣＥｒａｓｕｒｅ＿Ｃｏｕｎｔｅｒ」）を、Ｔ_ｐｄ（即ち、ＤＲＣＬｅｎｇｔｈｓの所定数）のような所定期間と等しいと設定する。ステップ１８３０の結果が「ＮＯ」である場合、ステップ１８３２は、Ｓｔｏｒｅｄ＿ＤＳＣ＿ＶａｌｕｅをデコードされたＤＳＣ値（即ち、「ＤＳＣ＿Ｖａｌｕｅ」）である、およびＤＳＣ＿Ｅｒａｓｅｄ＿Ｆｌａｇを「０」であると設定する。

図１８Ｄでは、ステップ１８４０は、Ｓｔｏｒｅｄ＿ＤＳＣ＿Ｖａｌｕｅが最後の有効なＤＳＣ値（即ち、「Ｌａｓｔ＿Ｖａｌｉｄ＿ＤＳＣ＿Ｖａｌｕｅ」）と等しいかどうか判断する。ステップ１８４０の結果が「ＮＯ」である場合、ステップ１８４１に続き、Ｌａｓｔ＿Ｖａｌｉｄ＿ＤＳＣ＿Ｖａｌｕｅを更新することに関連してフラグ（即ち、「ＬａｓｔＶａｌｉｄＤＳＣＶａｌｕｅ＿ｎｅｅｄｓ＿ｔｏ＿ｂｅ＿ｕｐｄａｔｅｄ＿ｆｌａｇ」）を「１」であるように設定する。ステップ１８４２は、Ｓｔｏｒｅｄ＿ＤＳＣ＿ＶａｌｕｅがＴｈｉｓ＿Ｃｅｌｌ＿ＤＳＣ＿Ｖａｌｕｅと等しいかどうか続いて判断する。ステップ１８４２の結果が「ＹＥＳ」である場合、ステップ１８４３に続き、ＤＳＣ切換え（即ち、「ＤＳＣＳｗｉｔｃｈＤｅｌａｙＩｎＳｌｏｔｓ」）のために説明された遅れ（例えば、スロットの単位で測られた）であるようにＤｅｌａｙ＿Ｃｏｕｎｔｅｒを設定する。ステップ１８４２の結果が「ＮＯ」である場合、ステップ１８４４に続き、Ｄｅｌａｙ＿Ｃｏｕｎｔｅｒは「０」に設定される。

図１８Ｅにおいて、すべてのスロットの各活発なＡＴについて、ステップ１８５０は、ＤＳＣ＿Ｅｒａｓｅｄ＿Ｆｌａｇが「１」であるかどうか、ＳｔｏｐＤＲＣＥｒａｓｕｒｅＭａｐ＿ｄｕｅｔｏ＿ＤＳＣＥｒａｓｕｒｅ＿Ｃｏｕｎｔｅｒが「０」以上にあるかどうかを判断する。ステップ１８５０の結果が「ＹＥＳ」である場合、ステップ１８５１に続き、ＳｔｏｐＤＲＣＥｒａｓｕｒｅＭａｐ＿ｄｕｅｔｏ＿ＤＳＣＥｒａｓｕｒｅ＿Ｃｏｕｎｔｅｒを「１」だけディクリメントする。

図１８Ｆにおいて、ステップ１８６０は、ＬａｓｔＶａｌｉｄＤＳＣＶａｌｕｅ＿ｎｅｅｄｓ＿ｔｏ＿ｂｅ＿ｕｐｄａｔｅｄ＿ｆｌａｇが「１」であるかどうか判断する。ステップ１８６０の結果が「ＹＥＳ」である場合、ステップ１８６１に続き、Ｄｅｌａｙ＿Ｃｏｕｎｔｅｒが「０」であるかどうかを判断する。ステップ１８６１の結果が「ＮＯ」である場合、ステップ１８６２に続き、Ｄｅｌａｙ＿Ｃｏｕｎｔｅｒを「１」だけディクリメントする。ステップ１８６１の結果が「ＹＥＳ」である場合、ステップ１８６３に続き、ＬａｓｔＶａｌｉｄＤＳＣＶａｌｕｅ＿ｎｅｅｄｓ＿ｔｏ＿ｂｅ＿ｕｐｄａｔｅｄ＿ｆｌａｇを「０」に、およびＬａｓｔ＿Ｖａｌｉｄ＿ＤＳＣ＿ＶａｌｕｅをＳｔｏｒｅｄ＿ＤＳＣ＿Ｖａｌｕｅに設定する。ステップ１８６４は、Ｓｔｏｒｅｄ＿ＤＳＣ＿ＶａｌｕｅがＴｈｉｓ＿Ｃｅｌｌ＿ＤＳＣ＿Ｖａｌｕｅと同じかどうか続いて判断する。ステップ１８６４の結果が「ＹＥＳ」である場合、ステップ１８６５に続き、ＬａｓｔＶａｌｉｄＤＳＣ＿Ｐｏｉｎｔｉｎｇ＿Ｓｔａｔｅを「１」に設定する。そうでなければ、それは、ステップ１８６６で示されるように「０」であるように設定される。

図１８Ｇでは、ステップ１８７０は、Ｅｒａｓｕｒｅ＿ＣｏｕｎｔがＭａｘ＿Ｅｒｓ＿Ｌｅｎより大きくかどうか、およびＬａｓｔＶａｌｉｄＤＳＣ＿Ｐｏｉｎｔｉｎｇ＿Ｓｔａｔｅが「１」であるかどうか判断する。ステップ１８７０の結果が「ＹＥＳ」である場合、ＡＴは、例えば、ステップ１８７１で示されるようにＥｒａｓｕｒｅ＿Ｍａｐｐｅｄ＿Ｆｌａｇを「１」に設定することにより、このセルからのＤＲＣ消去マッピングに関して適格であるかもしれない。

図１８Ｈでは、ステップ１８８０は、ＤＳＣ＿Ｅｒａｓｅｄ＿Ｆｌａｇが「１」であるかどうか、およびＳｔｏｐＤＲＣＥｒａｓｕｒｅＭａｐ＿ｄｕｅｔｏ＿ＤＳＣＥｒａｓｕｒｅ＿Ｃｏｕｎｔｅｒが「０」であるかどうかを判断する。ステップ１８８０の結果が「ＹＥＳ」である場合、ＡＴは、例えば、ステップ１８８１で示されるようにＥｒａｓｕｒｅ＿Ｍａｐｐｅｄ＿Ｆｌａｇを「０」に設定することにより、セルからのＤＲＣ消去マッピングに関して適格でない。

図１８Ｉでは、ステップ１８９０は、ＤＲＣカバーが削除されないかどうか、およびＤＲＣＣｏｖｅｒＣｈａｎｇｅｄＦｌａｇが「０」であるかどうかを判断する。ステップ１８９０の結果が「ＹＥＳ」である場合、ステップ１８９１に続き、ＤＲＣ＿Ｃｏｖｅｒが指しておりかつ対応するＤＲＣ＿ＲａｔｅであるセクタからＡＴのための送信をスケジュールする。ステップ１８９０の結果が「ＮＯ」である場合、ステップ１８９２に続き、Ｅｒａｓｕｒｅ＿Ｍａｐｐｅｄ＿Ｆｌａｇが「１」であるかどうか判断する。ステップ１８９２の結果が「ＹＥＳ」である場合、ステップ１８９３に続き、以下にさらに述べられるように、ＡＴへのＯＴＡマルチキャスティングを開始する。

図１９は、例えば、ＯＴＡマルチキャスティング・ステップ（上に記述したように）を実行するために処理１９００の実施例を示す。処理１９００はステップ１９０５でスタートする。ステップ１９１０は、ＤＲＣ消去マッピングのために適格である待ち行列にあるＡＴのための任意のデータ（例えば、十分に長いパケット遅れを有する遅れに敏感なフロー）があるかどうか判断する。ステップ１９１０の結果が「ＹＥＳ」である場合、ステップ１９２０に続き、特別のパケットフォーマット（ここに「ＤＲＣ＿ｉｎｄｅｘ＿ｍａｐｐｅｄ」と名付けられた）を使用しているこのセル、およびＡＴの活発な組にある複数のセクタからＡＴのためのデータを送信する。例えば、ＤＲＣインデックスの予め定められた組と互換性をもつマルチユーザ・パケットフォーマットが使用されるかもしれない。ステップ１９２０の結果が「ＮＯ」である場合は、処理１９００はステップ１９３０で終了する。

実施例では、すべてのＤＲＣＬｅｎｇｔｈ間隔について、順方向リンク・プロセッサ（例えば、デジタル信号プロセッサ（ＤＳＰ））は、次のものを含む逆方向リンク・プロセッサ（例えば、ＤＳＰ）から８ビットのＤＲＣ情報を受け取るかもしれない：Ｅｃｐ／Ｎｔが消去閾値（即ち、「ＤＲＣ＿Ｅｒａｓｕｒｅ」）未満かどうかを示す１ビットのＤＲＣ消去フラグ；３ビットのＤＲＣカバー（即ち、「ＤＲＣ＿Ｃｏｖｅｒ」）；４ビットのＤＲＣレート（即ち、「ＤＲＣ＿Ｒａｔｅ」）。Ｔ_ｐｄとＴ_ｄにおいて、順方向リンク・プロセッサはデコードされたＤＳＣ値（即ち、上に記述されたように「ＤＳＣ＿Ｖａｌｕｅ」）を受け取るかもしれない。ＤＲＣ消去マッピングアルゴリズムは以下のように行なわれるかもしれない（例えば、ＤＲＣＬｅｎｇｔｈ毎に一度）：

図２０は、いくつかの示された処理（上に記述したような）を行なうために、ＡＰで実施されるかもしれない装置２０００のブロック図を示す。例の方法で、装置２０００はＤＲＣ評価ユニット（またはモジュール）２０１０、ＤＳＣ評価ユニット２０２０、およびスケジューリング・ユニット２０３０を含んでいるかもしれない。

装置２０００において、ＤＲＣ評価ユニット２０１０はＡＴから受信されたＤＲＣ値を判断し、ＤＲＣカバー消去基準が満たされるかどうかを評価し、受信されたＤＲＣカバーの一貫性を評価し、ＤＲＣ消去マッピングなど（上に記述したような）を行なうように構成されるかもしれない。ＤＳＣ評価ユニット２０２０はＡＴから受信されたＤＳＣ値を判断し、ＤＳＣ消去が生じたかどうかを評価し、ＤＳＣに関して様々な機能など（上に記述されたように）を行なうように構成されるかもしれない。スケジューリング・ユニット２０３０は、上に記述されたように、ＡＴのための送信をスケジュールするように構成されるかもしれない。スケジューリング・ユニット２０３０は、多数のセクタ（上に記述されたような）からＡＴへ順方向トラヒック（例えば、データ）をマルチキャストするように構成されたＯＴＡマルチキャスティング・ユニット２０３５をさらに含んでいるかもしれない。

装置２０００では、ＤＲＣ評価ユニット２０１０、ＤＳＣ評価ユニット２０２０およびスケジューリング・ユニット２０３０（ＯＴＡマルチキャスティング・ユニット２０３５と共に）は、通信バス２０４０に接続されるかもしれない。演算処理装置２０５０および記憶装置２０６０も通信バス２０４０に接続されるかもしれない。演算処理装置２０５０は様々なユニットの作動を制御および/または調整するように構成されるかもしれない。記憶装置２０６０は、演算処理装置２０４０によって実行される命令を具体化するかもしれない。

装置２０００は、ＡＰおよび/または他のネットワーク・インフラストラクチャ手段において実施されてもよい。

ここに（上に記述したように）示された実施例は、無線通信中の適応性のあるサーバ・セクションのいくつかの実施例を提供する。他の実施例および実施がある。ここに示された様々な実施例は、ＡＴ、ＡＰ、ＡＮＣおよび/または他のネットワーク・インフラストラクチャ要素で実施されてもよい。

ここに示された様々なユニット／モジュールおよび実施例は、ハードウェア、ソフトウェア、ファームウェアまたはそれの組合せで実施されてもよい。ハードウェア実施では、様々なユニットは、１つ以上の特定用途向けＩＣ（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、デジタル信号処理装置（ＤＳＰＤ）、フィールドプログラマブルゲートアレー（ＦＰＧＡ）、プロセッサ、マイクロプロセッサ、コントローラ、マイクロコントローラ、プログラマブルロジックデバイス（ＰＬＤ）、他の電子ユニットまたはそれの任意の組合せで実施されてもよい。ソフトウェア実施では、様々なユニットは、ここに記述された機能を行なうモジュール（例えば手順、機能など）で実施されてもよい。ソフトウェア・コードは記憶装置に記憶され、プロセッサ（または演算処理装置）によって実行されてもよい。記憶装置はプロセッサの内部、またはプロセッサの外部で実施されてもよく、外部の場合には、それは技術で既知の様々な手段によってプロセッサに通信的に接続され得る。

様々な示された実施例は、コントローラ、ＡＴおよび放送／マルチキャスト・サービスを提供するための他の手段で実施されてもよい。ここに示された実施例は、データ処理システム、無線通信システム、一方向の放送システム、および効率的な情報送信を望む任意の他のシステムに適用可能かもしれない。

情報及び信号は様々な異なる技術及びプロトコルを使用して表されることを当業者は理解するであろう。例えば、上の記述の至る所で引用されるデータ、指示、命令、情報、信号、ビット、シンボル、及びチップは電圧、電流、電磁波、磁場または粒子、光学場または粒子、またはその任意の組合せによって表される。

ここで開示された実施例に関連して記述された様々な例示の論理ブロック、モジュール、回路、及びアルゴリズム・ステップは、電子ハードウェア、コンピュータ・ソフトウェア、または双方の組合せとして実施できることを当業者はさらに理解するであろう。このハードウェア及びソフトウェアの互換性を明瞭に示すために、様々な例示部品、ブロック、モジュール、回路、及びステップがそれらの機能性に関して一般に上で記述されてきた。そのような機能性がハードウェアまたはソフトウェアとして実施されるかどうかは全体のシステムに課せられた特定の応用及び設計の制約に依存する。熟練技術者は特定の各応用について種々の方法で記述された機能性を実施できるであろうが、そのような実施の決定は本発明の範囲から逸脱するものと解釈されるべきではない。

ここに開示された実施例に関連して記述された様々な例示の論理ブロック、モジュール、及び回路は、一般用途プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラム可能論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェア部品、またはここに記述された機能を実行するために設計されたそのあらゆる組合せによって実施、或いは実行される。一般用途プロセッサはマイクロプロセッサでもよいが、その代りに、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械でもよい。プロセッサはまた計算デバイスの組合せ、例えば、ＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと接続した一以上のマイクロプロセッサ、またはそのような任意の他の構成として実施される。

ここに開示された実施例に関連して記述された方法またはアルゴリズムのステップは、直接ハードウェアにおいて、プロセッサによって実行されるソフトウェア・モジュールにおいて、或いは２つの組合せにおいて組込まれる。ソフトウェア・モジュールはランダム・アクセス・メモリ（ＲＡＭ）、フラッシュ・メモリ、リード・オンリー・メモリ（ＲＯＭ）、電気的にプログラム可能なＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能なプログラム可能なＲＯＭ（ＥＥＰＲＯＭ）、レジスタ、ハードディスク、交換可能ディスク、ＣＤ−ＲＯＭ、または当技術分野において既知の他の型式の記憶媒体に駐在する。典型的な記憶媒体はプロセッサが記憶媒体から情報を読取り、記憶媒体に情報を書込むことができるようにプロセッサに接続される。その代りでは、記憶媒体はプロセッサに一体化してもよい。プロセッサ及び記憶媒体はＡＳＩＣに駐在してもよい。ＡＳＩＣはユーザ端末に駐在してもよい。その代りでは、プロセッサ及び記憶媒体はユーザ端末中に個別部品として駐在してもよい。

開示された実施例の記述は当業者が本発明を行い、或いは使用することを可能にするために提供される。これらの実施例への様々な変更は当業者には直ちに明白であり、ここに定義された一般原理は本発明の精神または範囲から逸脱することなく他の実施例に適用できる。このように、本発明はここに示された実施例に限定されることを意図していないが、ここに開示された原理及び新規な特徴と両立する最も広い範囲を与えられるべきである。

Claims (31)

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. プロセッサに、
    アクセス端末から受信されたデータレート制御（ＤＲＣ）カバーが削除され、前記ＤＲＣカバーに関係したＤＲＣ消去基準が満たされるかどうか判断すること、
    前記ＤＲＣカバーが削除され、前記ＤＲＣ消去基準が満たされると判断された場合に、前記アクセス端末から受信されたデータソース制御（ＤＳＣ）値が削除されるかどうか判断すること、
    前記ＤＲＣカバーが削除されないと判断された場合に、前記ＤＲＣカバーに関連したセクタから前記アクセス端末のための送信をスケジュールすること、
    を実行させるように実行可能であるコード、
    を含む無線通信のためのコンピュータ可読記憶媒体。
31. プロセッサに、
    アクセス端末から受信されたデータレート制御（ＤＲＣ）カバーが削除されるかどうかを判断すること、
    前記ＤＲＣカバーを、前記アクセス端末から以前に受信されたＤＲＣカバーの少なくとも１つと比較すること、
    前記ＤＲＣカバーが削除されない場合に、および前記ＤＲＣカバーが、前記比較に基づいて前記以前に受信されたＤＲＣカバーの少なくとも１つと一致している場合に、前記アクセス端末へ送信をスケジュールすること
    を実行させるように実行可能であるコード、
    を含む無線通信のためのコンピュータ可読記憶媒体。

Images