(57)【要約】      （修正有）【課題】ランダムアクセスチャネルと予約指向チャネルとを介して（インターネットゲートウェイといった）ノードと通信する一以上の（加入者宅内機器、ＣＰＥｓといった）端末を備える符号分割多元接続の通信システムにおいて、チャネル間の通信トラヒックを管理する種々のスキームを提供する。【解決手段】所定の端末の出力バッファのローディングがＱ状態に達する程度を調査し（３０２）、Ｑ状態が閾値よりも大きい場合（３１０）、予約指向サブチャネルを指定する符号を所定の端末に割当て、所定の端末に、直交符号分割多元接続（ＯＣＤＭＡ）に基づいて予約指向サブチャネルでデータを送信させ（３２６）、Ｑ状態が閾値未満である場合（３１０）、所定の端末に非同期符号分割多元接続（ＡＣＤＭＡ）に基づいてランダムアクセスチャネルでデータを送信させる（３３０）。【選択図】図３
2010093826.tif 000002
【特許請求の範囲】
【請求項１】
少なくともランダムアクセスチャネルと予約指向チャネルとを介してノードと通信する複数の端末を含む符号分割多元接続（ＣＤＭＡ）の通信システムにおいて、前記ランダムアクセスチャネル及び予約指向チャネルのトラヒックを管理する方法であって、
ａ）データが所定の端末から通信されるトラヒックの特徴を、少なくとも１つの基準と比較し、
ｂ１）前記トラヒックの特徴が、前記少なくとも１つの基準を満たす場合、
１）帯域幅予約要求を送信し、
２）前記帯域幅予約要求を処理及び許可し、
３）前記帯域幅予約要求の前記許可を前記所定の端末に通信し、
４）前記所定の端末に、前記予約指向チャネルでデータを送信させ、又は、
ｂ２）前記トラヒックの特徴が、前記少なくとも１つの基準を満たさない場合、前記所定の端末に、前記ランダムアクセスチャネルでデータを送信させる
方法。
【請求項２】
前記ランダムアクセスチャネルは、予めスケジュールされていないときに、前記端末に対して、前記ランダムアクセスチャネルでデータを通信することを許可するように構成され、
前記予約指向チャネルは、前記ランダムアクセスチャネルよりも全体的に高いデータレートでデータを通信する、
請求項１記載の方法。
【請求項３】
前記端末は、加入者宅内機器（ＣＰＥｓ）であり、
前記ノードは、複数の加入者宅内機器（ＣＰＥｓ）を衛星通信ネットワークを介してインターネットにリンクするゲートウェイである、
請求項１記載の方法。
【請求項４】
前記所定の端末は、前記帯域幅予約要求を送信し、
前記ノードは、前記帯域幅予約要求を処理及び許可し、
前記帯域幅予約要求の許可は、前記ノードから前記所定の端末へ通信される、
請求項１記載の方法。
【請求項５】
前記ランダムアクセスチャネルは、非同期符号分割多元接続（ＡＣＤＭＡ）に基づいてデータを送信し、
前記予約指向チャネルは直交符号分割多元接続（ＯＣＤＭＡ）に基づいてデータを送信する、
請求項１記載の方法。
【請求項６】
前記少なくとも１つの基準は、閾値パケットサイズを含み、
前記比較するステップは、前記閾値パケットサイズを、前記所定の端末からデータが通信されるべきパケットを特徴付けるパケットサイズと比較することを含む、
請求項１記載の方法。
【請求項７】
前記少なくとも１つの基準は、閾値データレートを含み、
前記比較するステップは、前記閾値データレートを、前記所定の端末からデータが通信されるべきパケットを特徴付ける、ある期間に計算された平均データレートと比較することを含む、
請求項１記載の方法。
【請求項８】
前記少なくとも１つの基準は、パケットタイプの表示を含み、
前記比較するステップは、前記パケットタイプの表示を、前記所定の端末からデータが通信されるべきパケットを特徴付けるパケットタイプと比較することを含む、
請求項１記載の方法。
【請求項９】
少なくともランダムアクセスチャネルと予約指向チャネルとを介してノードと通信する複数の端末を含む符号分割多元接続（ＣＤＭＡ）の通信システムにおいて、前記ランダムアクセスチャネル及び予約指向チャネルのトラヒックを管理する方法であって、
ａ）１つの調査結果に達するように、所定の端末からデータが通信されるトラヒックの特徴を、少なくとも１つの基準と比較し、
ｂ）前記調査結果に基づいて、前記所定の端末がビジー状態にあるかどうかを判定し、
ｃ１）前記所定の端末がビジー状態にあると判定された場合、
１）予約指向サブチャネルを指定する符号を前記所定の端末に割当て、
２）前記所定の端末に、前記予約指向サブチャネルでデータを送信させ、又は、
ｃ２）前記所定の端末がビジー状態にはないと判定された場合、前記所定の端末に前記ランダムアクセスチャネルでデータを送信させる、方法。
【請求項１０】
前記の符号を割当てるステップは、
前記所定の端末にウォルシュ符号を割当てる
ことを含む、請求項９記載の方法。
【請求項１１】
前記ランダムアクセスチャネルは、予めスケジュールされていないときに、前記端末に対して、前記ランダムアクセスチャネルでデータを通信することを許可するように構成され、
前記予約指向チャネルは、前記ランダムアクセスチャネルよりも全体的に高いデータレートでデータを通信する、
請求項９記載の方法。
【請求項１２】
前記端末は、加入者宅内機器（ＣＰＥｓ）であり、
前記ノードは、複数の加入者宅内機器（ＣＰＥｓ）を衛星通信ネットワークを介してインターネットにリンクするゲートウェイである、
請求項９記載の方法。
【請求項１３】
前記ランダムアクセスチャネルは、非同期符号分割多元接続（ＡＣＤＭＡ）に基づいてデータを送信し、
前記予約指向チャネルは、直交符号分割多元接続（ＯＣＤＭＡ）に基づいてデータを送信する、
請求項９記載の方法。
【請求項１４】
前記少なくとも１つの基準は、閾値パケットサイズを含み、
前記比較するステップは、前記閾値パケットサイズを、前記所定の端末からデータが通信されるべきパケットを特徴付けるパケットサイズと比較することを含む、
請求項９記載の方法。
【請求項１５】
前記少なくとも１つの基準は、閾値データレートを含み、
前記比較するステップは、前記閾値データレートを、前記所定の端末からデータが通信されるべきパケットを特徴付ける、ある期間にわたって計算された平均データレートと比較することを含む、
請求項９記載の方法。
【請求項１６】
前記少なくとも１つの基準は、パケットタイプの表示を含み、
前記比較するステップは、前記パケットタイプの表示を、前記所定の端末からデータが通信されるべきパケットを特徴付けるパケットタイプと比較することを含む、
請求項９記載の方法。
【請求項１７】
少なくともランダムアクセスチャネルと予約指向チャネルとを介してノードと通信する複数の端末を含む符号分割多元接続（ＣＤＭＡ）の通信システムにおいて、前記ランダムアクセスチャネル及び予約指向チャネルのトラヒックを管理する方法であって、
ａ）所定の端末の出力バッファのローディングがＱ状態に達する程度を調査し、
ｂ）閾値を前記所定の端末の前記Ｑ状態と比較し、
ｃ１）前記Ｑ状態が前記閾値よりも大きい場合、
（１）予約指向サブチャネルを指定する符号を前記所定の端末に割当て、
（２）前記所定の端末に、前記予約指向サブチャネルでデータを送信させ、
ｃ２）前記Ｑ状態が前記閾値未満である場合、前記所定の端末に前記ランダムアクセスチャネルでデータを送信させる、方法。
【請求項１８】
前記Ｑ状態を前記ランダムアクセスチャネルで通信する
ことを更に備える、請求項１７記載の方法。
【請求項１９】
前記ランダムアクセスチャネルは、予めスケジュールされていないときに、前記端末に対して、前記ランダムアクセスチャネルでデータを通信することを許可するように構成され、
前記予約指向チャネルは、前記ランダムアクセスチャネルよりも全体的に高いデータレートでデータを通信する、
請求項１７記載の方法。
【請求項２０】
前記端末は、加入者宅内機器（ＣＰＥｓ）であり、
前記ノードは、複数の加入者宅内機器（ＣＰＥｓ）を衛星通信ネットワークを介してインターネットにリンクするゲートウェイである、
請求項１７記載の方法。
【請求項２１】
前記ランダムアクセスチャネルは、非同期符号分割多元接続（ＡＣＤＭＡ）に基づいてデータを送信し、
前記予約指向チャネルは直交符号分割多元接続（ＯＣＤＭＡ）に基づいてデータを送信する、
請求項１７記載の方法。
【請求項２２】
（２）前記所定の端末に、前記予約指向サブチャネルでデータを送信させた後、
（３）前記所定の端末の少なくとも１つのＱ状態の履歴を分析して、Ｑ状態履歴分析を取得し、
（４）前記Ｑ状態履歴分析に少なくとも部分的に基づいて、
ｉ）現在のデータレートよりも高いデータレートで動作する、より速い予約指向サブチャネルを指定する第１の符号を前記所定の端末に割当てることと、
ｉｉ）前記現在のデータレートと同一のデータレートで動作する、同一速度の予約指向サブチャネルを指定する第２の符号を前記所定の端末に割当てることと、
ｉｉｉ）前記現在のデータレートよりも低いデータレートで動作する、より遅い予約指向サブチャネルを指定する第３の符号を前記所定の端末に割当てることと、
ｉｖ）任意の予約指向サブチャネルを指定する任意の符号を、前記所定の端末から取り消すことと、
を含む組から１つのステップを選択して実行する
ことを更に備える、請求項１７記載の方法。
【請求項２３】
前記第１、第２、及び第３の符号は、それぞれ漸次遅くなるデータレートで動作する、それぞれの予約指向サブチャネルを指定する漸次長くなるウォルシュ符号である、
請求項２２記載の方法。
【請求項２４】
前記Ｑ状態を予約指向サブチャネルで通信する
ことを更に備える、請求項２２記載の方法。
【請求項２５】
前記ランダムアクセスチャネルは、予めスケジュールされていないときに、前記端末に対して、前記ランダムアクセスチャネルでデータを通信することを許可するように構成され、
前記予約指向チャネルは、前記ランダムアクセスチャネルよりも全体的に高いデータレートでデータを通信する、
請求項２２記載の方法。
【請求項２６】
前記端末は、加入者宅内機器（ＣＰＥｓ）であり、
前記ノードは、複数の加入者宅内機器（ＣＰＥｓ）を衛星通信ネットワークを介してインターネットにリンクするゲートウェイである、
請求項２２記載の方法。
【請求項２７】
前記ランダムアクセスチャネルは、非同期符号分割多元接続（ＡＣＤＭＡ）に基づいてデータを送信し、
前記予約指向チャネルは直交符号分割多元接続（ＯＣＤＭＡ）に基づいてデータを送信する、
請求項２２記載の方法。
【請求項２８】
少なくともランダムアクセスチャネルと予約指向チャネルとを介してノードと通信する複数の端末を含む符号分割多元接続（ＣＤＭＡ）の通信システムにおいて、前記ランダムアクセスチャネル及び予約指向チャネルのトラヒックを管理する方法であって、
ａ）所定の端末の出力バッファのローディングが、Ｑ状態に達する程度を調査し、
ｂ）前記所定の端末はビジー状態にあるかどうかを、前記Ｑ状態に少なくとも部分的に基づいて判定し、
ｃ１）前記所定の端末はビジー状態にあると判定された場合、
１）予約指向サブチャネルを指定する符号を前記所定の端末に割当て、
２）前記所定の端末に、前記予約指向サブチャネルでデータを送信させ、又は、
ｃ２）前記所定の端末はビジー状態にはないと判定された場合、前記所定の端末に、前記ランダムアクセスチャネルでデータを送信させる
ことを備える、方法。
【請求項２９】
前記符号は、前記予約指向サブチャネルを指定するウォルシュ符号である、
請求項２８記載の方法。
【請求項３０】
前記ランダムアクセスチャネルは、予めスケジュールされていないときに、前記端末に対して、前記ランダムアクセスチャネルでデータを通信することを許可するように構成され、
前記予約指向チャネルは、前記ランダムアクセスチャネルよりも全体的に高いデータレートでデータを通信する、
請求項２８記載の方法。
【請求項３１】
前記端末は、加入者宅内機器（ＣＰＥｓ）であり、
前記ノードは、複数の加入者宅内機器（ＣＰＥｓ）を衛星通信ネットワークを介してインターネットにリンクするゲートウェイである、
請求項２８記載の方法。
【請求項３２】
前記ランダムアクセスチャネルは、非同期符号分割多元接続（ＡＣＤＭＡ）に基づいてデータを送信し、
前記予約指向チャネルは直交符号分割多元接続（ＯＣＤＭＡ）に基づいてデータを送信する、
請求項２８記載の方法。
【請求項３３】
少なくとも１つのデータ処理装置を有するコンピュータシステムでの実行のためのプログラム命令を記憶するコンピュータプログラム製品であって、その命令は、当該コンピュータシステムによって実行された場合に、当該コンピュータシステムに請求項１の方法を実行させるコンピュータプログラム製品。
【請求項３４】
少なくとも１つのデータ処理装置を有するコンピュータシステムでの実行のためのプログラム命令を記憶するコンピュータプログラム製品であって、その命令は、当該コンピュータシステムによって実行された場合に、当該コンピュータシステムに請求項９の方法を実行させるコンピュータプログラム製品。
【請求項３５】
少なくとも１つのデータ処理装置を有するコンピュータシステムでの実行のためのプログラム命令を記憶するコンピュータプログラム製品であって、その命令は、当該コンピュータシステムによって実行された場合に、当該コンピュータシステムに請求項１７の方法を実行させるコンピュータプログラム製品。
【請求項３６】
少なくとも１つのデータ処理装置を有するコンピュータシステムでの実行のためのプログラム命令を記憶するコンピュータプログラム製品であって、その命令は、当該コンピュータシステムによって実行された場合に、当該コンピュータシステムに請求項２２の方法を実行させるコンピュータプログラム製品。
【請求項３７】
少なくとも１つのデータ処理装置を有するコンピュータシステムでの実行のためのプログラム命令を記憶するコンピュータプログラム製品であって、その命令は、当該コンピュータシステムによって実行された場合に、当該コンピュータシステムに請求項２８の方法を実行させるコンピュータプログラム製品。
【請求項３８】
請求項１記載の方法を実行するように構成された、コンピュータシステム。
【請求項３９】
請求項９記載の方法を実行するように構成された、コンピュータシステム。
【請求項４０】
請求項１７記載の方法を実行するように構成された、コンピュータシステム。
【請求項４１】
請求項２２記載の方法を実行するように構成された、コンピュータシステム。
【請求項４２】
請求項２８記載の方法を実行するように構成された、コンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の異なるＣＤＭＡ（符号分割多重接続）チャネルが存在するデータ通信システムにおけるトラヒックを管理することに関する。特に、本発明は、より低い容量の、「ランダムアクセス」（予約不要の）の非同期のＣＤＭＡチャネルが、より高い容量の、「予約指向（"reservation-oriented"）」の直交ＣＤＭＡチャネルと並んで存在するデータ通信システムにおけるトラヒックを管理することに関する。
【背景技術】
【０００２】
時分割多元接続（ＴＤＭＡ）ベースのシステムでは、利用可能な帯域幅が複数のタイムスロットに分けられる。複数のタイムスロットは更に、２つの一般的なカテゴリー、即ち、ランダムアクセスタイムスロット（ＲＡＴＳ）と予約タイムスロット（ＲＥＴＳ）に分けられる。
【０００３】
ＲＡＴＳは、複数の異なる加入者宅内機器（customer premises equipments）（ＣＰＥｓ）がリソースを求めて競うコンテンションタイムスロットとして割当てられる。ＡＬＯＨＡベースの競合解決プロトコル（contention resolution protocols）は通常、複数の加入者宅内機器（ＣＰＥｓ）間の衝突を解決するのにＲＡＴＳで用いられる。複数のＣＰＥは、小さなパケットをＲＡＴＳで送信して、ＲＥＴＳの帯域幅を要求する。システムに応じて、小さなパケットはＲＡＴＳで送信され得るが、大部分のトラヒックは、まず帯域幅を要求することによってＲＥＴＳで送信される。
【０００４】
ＴＤＭＡシステムは、２つの主要な不利点、即ち、より長いアクセス遅延と、より低い帯域幅効率に苦しむ。予約を獲得する前に、要求がＲＡＴＳで送信される必要があるため、長い遅延がもたらされる。ＲＡＴＳタイムスロットは、過度の衝突及び遅延を回避するために、非常に低いトラヒックローディングで動作される必要がある。これは、ＴＤＭＡシステムの帯域幅効率がより低くなるという結果を招く。
【０００５】
従って、当技術分野には、より短いアクセス遅延と、より高い帯域幅効率を提供する技術に対する必要性がある。この目的のため、符号分割多元接続（ＣＤＭＡ）が採用されてきた。ＣＤＭＡは、複数のユーザ間で最小限の周波数又は時間調整を必要とする一方で、ユーザが同一の名目周波数で動作することを可能にする、と一般的に認識されてきた（Bhargava et al., Digital Communications by Satellite, John Wiley & Sons, ニューヨーク、１９８１年（非特許文献１）、特にチャプター９を参照）。
【０００６】
ＣＤＭＡを導入する様々なアプローチが生まれてきた。即ち、非同期符号分割多元接続（asynchronous code division multiple access）（ＡＣＤＭＡ、ＴＩＡ／ＥＩＡ／ＩＳ９５標準を参照）及び直交符号分割多元接続（orthogonal code division multiple access）（ＯＣＤＭＡ）といった、幾つかの点で異なる複数のＣＤＭＡチャネルは、通信システムの設計に柔軟性を与えてきた。しかし、複数の異なるチャネルタイプを単独の通信システム組み込めるようになるにつれて、当該異なるチャネル上のトラヒックを有効に管理する必要が生じる。例えば、複数の競争的な（contentious）端末間で帯域幅を公平に割当てる一方で、システム全体のスループットを最大化するために、複数の異なるチャネルの使用を最適化する必要性がある。しかし、異なるＣＤＭＡアプローチの複雑さは、最適なトラヒック管理を困難にしている。
【０００７】
従って、当技術分野には、複数の異なるチャネル、特に複数の異なるＣＤＭＡチャネルを有する通信ネットワーク上のトラヒックを有効に管理するための取決め（arrangement）を提供する必要性がある。
【非特許文献１】Bhargava et al., Digital Communications by Satellite, John Wiley & Sons, ニューヨーク、１９８１年
【特許文献１】米国仮出願６０／５０６，２９０号
【特許文献２】米国特許出願１０／４２８，９５３号
【発明の開示】
【０００８】
［要約］
本特許出願は、２００３年９月２５日に出願された、"Managing Traffic in Communications System Having Dissimilar CDMA Channels"と題され、本願の譲受人に譲渡され、本明細書に参照することで明白に組み込まれる、米国仮出願６０／５０６，２９０号（特許文献１）の優先権を主張する。
【０００９】
（例えば）少なくともランダムアクセスチャネル（ＲＡＣＨ）と予約指向チャネル（ＲＥＳＣＨ）とを介して（インターネットゲートウェイといった）ノードと通信する一以上の（加入者宅内機器、ＣＰＥｓといった）端末を備える符号分割多元接続（ＣＤＭＡ）の通信システムにおいて、チャネル間の通信トラヒックを管理する種々のスキームが提供される。所定の端末が送信し得るチャネルに関する判定は、様々な基準に基づき得る。判定は、端末がＲＡＣＨで送信するのかＲＥＳＣＨで送信するのかに関するバイナリの判定であってもよい。あるいは、より識別力のある判定は、より速いＲＥＳＣＨチャネルへのアップグレード、又は、より遅いＲＥＳＣＨチャネルへのダウングレードを含み得る。例えば、実ユーザのウェブブラウジングセッション中のトラヒックの管理における判定は、所定の端末がビジーであるかどうかのインテリジェントな確認を含み得る。トラヒック管理スキームは、例えば、異なるＣＤＭＡチャネル（ＲＥＳＣＨにおける直交符号分割多元接続（ＯＣＤＭＡ）、及びＲＡＣＨにおける非同期符号分割多元接続（ＡＣＤＭＡ））を備える、衛星通信ネットワークのリターンリンクで特に有用な媒体アクセス制御（ＭＡＣ）を提供する。
【００１０】
［詳細な説明］
記載された実施形態の、より完全な認識は、全体を通して同様の符号が同一又は対応する部分を示す添付の図面と共に、以下の詳細な説明を参照することで、一層理解される。
【００１１】
図面に示される実施形態を説明するに際して、明瞭さのために特定の用語が用いられる。しかし、発明は、そのように選択された特定の用語に限定されることを意図されたものではなく、具体的な要素の各々は、同様の目的を達成するために同様に動作する、あらゆる技術的な均等物を含むことが理解されるべきである。
【００１２】
更に、当業者にその実現が周知である特徴及び手続きは、簡潔さのために省略される。例えば、ソフトウェアループの開始及び終了、その機能（functions）を実行するために必要とされる、ネットワークの一方から他方へのパラメータの通信などは、当業者の能力の範囲内であり、従って、その如何なる詳細な提示も省略され得る。
【００１３】
更に、データ通信システムの種々の面、特徴及び実施形態は、フローチャート、フロー図、構成図、又はブロック図として描かれることができる処理として説明され得る。フローチャートは、複数の動作を一連の処理として説明し得るが、動作の多くは並行して、同時に、又は、説明されるのとは異なる順序で実行され得る。特定の実施のために必要とされないか、所望されない動作は、省略され得る。処理は、方法、関数、プロシージャ、ソフトウェア、サブルーチン、サブプログラム、又は、これらの任意の組合せに対応し得る。
【００１４】
トラヒック管理の取決めの実施形態は、加入者宅内機器（ＣＰＥｓ）、及び、地上の通信ネットワークと衛生通信ネットワークとの間のゲートウェイに言及し得る。しかし、トラヒック管理の取決めは一般に、端末、ワークステーション、パーソナルコンピュータなど広範に適用されることが理解される。同様に、トラヒック管理の取決めは一般に、ルータ、スイッチ、プロキシサーバ、ノードなど広範に適用される。更に、ネットワークの特定のロケーションで実施又は実行されるものとして説明される制御機能（functions）といった機能もまた、当該ネットワークの（一又は複数の）他の適当なロケーションで実行され得る。
【００１５】
通信システムの実施形態は、（ＴＩＡ／ＥＩＡ／ＩＳ９５に明記されるものといった）「ランダムアクセスチャネル」、又は、（２００３年５月１日に出願され、"Orthogonal Code Division Multiple Access On Return Link Of Satellite Links"と題された、米国特許出願第１０／４２８，９５３号（特許文献２）に開示されるものといった）予約指向チャネルに言及し得る。これらのチャネルは、例示的なチャネルタイプに過ぎない。即ち、トラヒック管理システムは、他のチャネルタイプにも適用され得る。
【００１６】
本明細書で用いられる種々の用語には、特許請求の範囲を解釈するのに用いられるとき、それらの最も広義で合理的な解釈が与えられるべきである。
【００１７】
簡単に言えば、少なくとも３つのタイプのチャネルが提供され得る。当該チャネルは、本明細書に記載される通信ネットワークの実施形態、即ち、衛星通信ネットワークを含み得るネットワークのリターンリンク（ＲＬ）で使用されるのに適している。３つのタイプのチャネルは、
−ランダムアクセスチャネル（ＲＡＣＨ）は、通信媒体にランダムアクセスを許可する、予約不要の（reservationless）管理方法を使用し、ＡＣＤＭＡ（非同期符号分割多元接続）技術を採用する。従って、ＲＡＣＨは、「ランダムな（スケジュールされていない）」ときにアクセスを提供するが、全体的なデータレートを犠牲にする。
【００１８】
−予約チャネル（REServation CHannel）（ＲＥＳＣＨ）は、ゲートウェイが複数の端末を確実に区別し得るように、（例えば）ゲートウェイによってそれぞれの端末に割当てられる、限定された数の符号（ウォルシュ符号）に基づいて媒体にアクセスを許可する、予約指向の管理方法を使用する。符号は互いに直交であり、異なる端末からの通信が互いに干渉しないことを保証する。従って、ＲＥＳＣＨは、ＯＣＤＭＡ（直交符号分割多元接続）を採用し、ＲＡＣＨのランダムな（スケジュールされていない）アクセス能力によって提供される柔軟性を犠牲にしても、全体的なデータレートの点でＲＡＣＨよりも効率的である。一部の実施形態において、ＲＥＳＣＨは、「常にオンの」チャネルと称されるサブチャネルを備え得る。
【００１９】
ハートビートチャネル（Heartbeat Channel）（ＨＣＨ）は、ＣＰＥとゲートウェイと間のフィードバックチャネルに関連し、従ってＲＡＣＨとＲＥＳＣＨとの間のトラヒックの管理については二次的な関係（concern）である。
【００２０】
ＲＡＣＨ及びＲＥＳＣＨ上のトラヒックは、本明細書に記載される原理に従って管理され得る。まず、チャネルの１つの非限定的な実施の基本的な特徴が記載される。
【００２１】
ＲＡＣＨ。ＲＡＣＨチャネルは、非同期符号分割多元接続（ＡＣＤＭＡ）に基づいており、複数のユーザ端末は、それらが送信すべきデータを有する如何なるときも、予め帯域幅を予約する必要無しに、ＲＡＣＨ上で送信し得る。ＣＤＭＡの原理に準拠して、複数の端末は、それらのデータを長い擬似乱数（ＰＮ）符号を用いて拡散する。端末に使用されるべく多くのＰＮ符号が利用可能であって、各ＰＮ符号は、それぞれのランダムアクセスチャネルを特定する。異なるＲＡＣＨチャネルに対応する異なるＰＮ符号は、同一の搬送周波数で送信され得る。本明細書に記載され、一実施形態で使用されるＲＡＣＨチャネルは、ＴＩＡ／ＥＩＡ／ＩＳ９５標準に記載される構造を有する。
【００２２】
端末は、ＰＮ符号のプールから無作為に選択し、選択されたＰＮ符号を用いてそのデータを拡散し得る。あるいは、ゲートウェイといったノードは、使用すべき端末に符号を割当ててもよい。いずれにしても、ＲＡＣＨ上での各送信は、ゲートウェイ又は他のノードが端末の送信の開始に同期及び検出することを可能にするプリアンブルで始まる。
【００２３】
ＲＡＣＨはまず、端末（加入者宅内機器、即ちＣＰＥ）が一定の時間、休止状態であって、ＲＥＳＣＨの帯域幅を割当てられていないときに、パケットをデータフローの開始時に送信するために、及び、小さなバーストのショートパケットを以下に論じられるように送信するために、電源投入時の（at power up）初期登録に使用され得る。ＲＥＳＣＨの帯域幅は、端末の帯域幅要求と利用可能なＲＥＳＣＨの帯域幅に基づいて、端末のために予約され得る。ＨＣＨは、ゲートウェイによるＲＬ信号強度測定値のための基準信号として、及び、信号対干渉及び雑音比（ＳＩＮＲ）フィードバックをゲートウェイに提供するために、端末に使用される。
【００２４】
ＲＡＣＨで使用される多元接続技術は、非同期ＣＤＭＡ（asynchronous CDMA）である。複数の端末（加入者宅内機器、即ちＣＰＥ）は、それらのデータを多くの擬似雑音（ＰＮ）符号のうちの１つを用いて拡散する。各端末は、例えば、低い（例えば、＜１０−４）パケット誤り率（ＰＥＲ）を達成するために、その受信されたＳＩＮＲが一定の閾値を超えるように、ＲＡＣＨで電力制御される。ＲＡＣＨの容量、許容可能なレベルを下回る符号衝突（code collision）のため、ＰＥＲを維持するために必要とされるＰＮ符号の数、電力制御、及び、ＲＡＣＨでのオーバーロード制御は、当業者によって実施可能であり、それ自体トラヒック管理に関係せず、従って本明細書ではこれ以上の詳細が提示されない。どのパケットがＲＡＣＨで送信されるか、及び、どのパケットがＲＥＳＣＨで送信されるのかを判定するのに使用される手続きは、以下の議論の主題である。
【００２５】
ＲＥＳＣＨ。ＲＥＳＣＨをサポートするのに使用される物理的なチャネル構成は、直交ＣＤＭＡ（ＯＣＤＭＡ）である。長さ１のウォルシュ符号を使用するＴＤＭＡアプローチを考える者がいるかもしれない。ＯＣＤＭＡのチャネル帯域幅は、異なる長さの複数の直交ウォルシュ符号に従って分けられる。リターンリンクにおける端末のデータレート要求に応じて、ＯＣＤＭＡでは、端末に特定の長さの直交ウォルシュ符号が割当てられる。（割当てられたウォルシュ符号により定義される）帯域幅は、特定の期間、端末に割当てられる。物理層チャネルの特定の詳細、及び、ゲートウェイで受信される複数の端末の信号間で直交性を達成するために使用され得るメカニズムの特定の詳細は、当業者によって実施可能であり、従って、それ自体はトラヒック管理に重要ではない。
【００２６】
ＨＣＨ。ハートビートチャネル（ＨＣＨ）は、端末で達成されるＳＩＮＲに関するフィードバック情報をゲートウェイに送信するために、端末によって使用されるリターンリンク（ＲＬ）チャネルである。一実施形態において、端末は、低い（例えば、＜１０−４）ＴＣＰパケット誤り率で端末が復号し得る、最大データレートのインデックスを送信する。ゲートウェイはまた、ＨＣＨ上で端末から受信される信号を、端末からの受信信号強度（received signal strength）（ＲＳＳ）を推定するのに使用する。ＲＬのＲＳＳは、所定の送信電力レベルについてのＲＥＳＣＨのレート制御されたチャネルで達成可能な最大データレートを判定するだけでなく、ＲＡＣＨの固定レートのチャネルを電力制御するのにも用いられる。各端末には、ＨＣＨの帯域幅が割当てられる。
【００２７】
下記は、ＲＡＣＨ及びＲＥＳＣＨ上のユーザデータ及びシグナリングを指示及び管理するのに使用され得る媒体アクセス制御（ＭＡＣ）手続きの記載である。種々のそのようなＭＡＣ手続きが提供される。
【００２８】
一般に、端末が、送信すべきデータを有するが、ＲＥＳＣＨ上の帯域幅割当てを有さないとき、端末は単にそのパケットをＲＡＣＨ上で送信することによってデータフローを開始する。端末のパケットをＲＡＣＨ上で受信すると、ゲートウェイは、端末がデータフローを知らせたと判定し、そうするとゲートウェイは、ＲＥＳＣＨ上の端末に帯域幅を割当てるべきか否かを判定しなければならない。
【００２９】
以下の議論の大部分は、ＨＴＴＰ（ハイパーテキストトランスファープロトコル）トラヒックについての帯域幅管理スキーム（及び含蓄的に、媒体アクセス制御（ＭＡＣ）スキーム）に重点を置いている。ＨＴＴＰトラヒックでは、リターンリンクに接続された、端末のウェブブラウジングアプリケーションは、ＧＥＴ及び肯定応答を運ぶ。ＨＴＴＰフローによって生成されるリターンリンクトラヒックを伝送するためのアプローチは、数多くある。
【００３０】
図１を参照すると、衛星通信ネットワークを含む通信ネットワークのリターンリンク（ＲＬ）が、管理されなければならないトラヒックを有している、トラヒック管理方法のコンテキストが、非限定的な例として図示されている。図１では、種々の「端末」（加入者宅内機器、即ちＣＰＥ）１１０、１２０、…が、それぞれの衛星放送受信アンテナ（satellite dishes）１１１、１２１…を介して衛星１００に、従ってその衛星放送受信アンテナ１５１を介して（インターネットゲートウェイといった）「ノード」にリンクされる。
【００３１】
フォワードリンク（ＦＬ）１３０は、ノードから、複数の端末のうちの任意のものへの通信の方向を示す。逆に、リバースリンク（ＲＬ、時々リターンリンクと称される）１４０は、複数の端末のうちの任意のものからノードへの通信の方向を示す。ＲＬは、上述したＯＣＤＭＡ技術及びＡＣＤＭＡ技術の組合せを用いて実現され得る。
【００３２】
複数のＣＰＥ（端末）は、ゲートウェイ（ノード）と同様に、構造及び動作の点で異なってよい。一般に、端末及びノードは、ＴＣＰ／ＩＰ及びＨＴＴＰといった、互いに互換性のある（compatible）通信プロトコルに従って動作する通信機器を有し、端末がノードを介してインターネットにアクセスできるようにしている。ノード及び端末は、本明細書に記載される分析的な特徴（analytical features）を実行するように構成された、それぞれのプロセッサを備える。ノードはまた、インターネットゲートウェイを導入するときは、ノードがインターネットにアクセスできるようにするためのプロキシサーバも備える。
【００３３】
当業者には、衛星及びノードの帯域幅が、複数の端末間で割当てられなければならないことが、容易に認識される。トラヒック管理は、例えば管理されているトラヒックが、実ユーザのインターネット・ウェブブラウジング・セッションのＴＣＰ／ＩＰ−ＨＴＴＰトラヒックであるときに、特に困難である。そのようなトラヒックは、衛星へのパス及び衛星からのパス、即ち、有意な時間遅延を導入するパスを考察（traverse）しなければならない。本明細書に記載される複数のトラヒック制御アプローチは、ＲＬの多対一の多重化要求が理由で、図１に示されるようなシステムのリターンリンクで使用されるのに、特に有用である。但し、図１のＲＬは、複数のアプローチのうちの１つにすぎない。
【００３４】
一般に、開示されたアプローチは、複数の端末１１０、１２０…のうちの何れが、利用可能な帯域幅よりも多くが許可されるか、本例では衛星１００及びノード１５０に利用可能な帯域幅よりも多くが許可されるかという戦略的な管理を含むが、目的は、利用可能な帯域幅を最大限に利用することである。そのようなアプローチの例は、上述したＲＡＣＨチャネル及びＲＥＳＣＨチャネルへのアクセスを管理する媒体アクセス制御（ＭＡＣ）を有するリンクを含む。
【００３５】
第１の実施形態（図２を参照）。第１の実施形態では、あらゆるトラヒックがＲＡＣＨで伝送される。ＲＡＣＨで送信することの利点は、パケットが、それらが生成され次第、送信されることができ、付加的な予約要求遅延が無いことである。
【００３６】
図２を参照すると、フローチャートは、第１の実施形態の例示的な実施のステップを示す。ブロック２００は、処理の開始を表し、ランダムアクセスチャネルでのデータの送信を示すブロック２１０が続く。ブロック２２０は、処理の終了を表すが、このときデータ送信が完了する。
【００３７】
専らＲＡＣＨで送信することの不利な点には、低い帯域幅効率と低いデータレートが含まれる。
【００３８】
第２の実施形態（図３を参照）。リターンリンクトラヒックを管理する第２のアプローチは、ＨＴＴＰトラヒックに関して記載される。勿論、実施形態はＨＴＴＰトラヒックの実施形態に限定される必要がないことが認識される。即ち、他のタイプのサービスもまた、同様に扱われ得る。
【００３９】
この第２のアプローチでは、所定の端末（ＣＰＥ）からのトラヒックの特徴が分析される。分析されるトラヒック特徴は、ある期間に測定された平均データレート若しくはパケットサイズといった）トラヒック統計値、又は、（パケットタイプといった）トラヒックコンテンツを含み得る。分析されたトラヒック特徴に基づいて、トラヒックはその後、ランダムアクセスチャネル（ＲＡＣＨ）、又は、予約指向チャネル（ＲＥＳＣＨ）の一方で送信される。
【００４０】
一例において、端末は、（ＴＣＰ肯定応答といった）より小さなパケットをＲＡＣＨで送信する。しかし、一定の閾値サイズよりも大きな長さのパケットを送信することを端末が望むときは、端末はＲＥＳＣＨの帯域幅を要求する。従って、ＲＥＳＣＨの帯域幅を要求するために、端末は予約要求パケットをＲＡＣＨで送信する。
【００４１】
図３を参照すると、フローチャートは、第２の実施形態の例示的な実施のステップを示し、ブロック３００は処理の開始を表す。
【００４２】
ブロック３０２は、所定の端末に関するデータトラヒックの分析を示す。例えば、所定の期間における平均データレート又はパケットサイズといった、１つ（又は複数）のトラヒック統計値が、分析される。あるいは、パケットタイプ又は他の基準といった、トラヒックコンテンツが分析される。一実施形態において、実際の分析は端末で行われるが、他の実施形態において、この分析はノードで行われる。
【００４３】
ブロック３１０は、ブロック３０２からのトラヒックコンテンツ又はトラヒック統計値の分析に基づいた判定を示す。分析されたトラヒック統計値が、閾値未満である場合、又は、トラヒックコンテンツが所定の一又は複数の基準を満たさない場合、処理は、端末がＲＡＣＨで送信することを示すブロック３３０に進む。しかし、分析されたトラヒックが閾値を満たすか超える場合、又は、トラヒックコンテンツが所定の一又は複数の基準を満たす場合、処理はブロック３２０に進む。
【００４４】
ブロック３２０は、端末が、１つの実施ではＲＡＣＨで、帯域幅予約要求を送信することを示す。続くブロック３２２は、ノード（ゲートウェイ）が端末の要求を処理し、利用可能な帯域幅に基づいて、端末の要求を許可する。要求の許可を通信するために、ブロック３２４に示されるように、ノードは帯域幅予約符号を端末に送信する。続いて、ブロック３２６は、端末がＲＥＳＣＨで送信することを示す。
【００４５】
ブロック３２０、３２２、３２４は、記載された実施が、端末（ＣＰＥ）とノード（ゲートウェイ）との間で発生する、要求／許可処理を含むことを強調するために点線で描かれている。但し、この要求−許可シーケンスは、端末がＲＥＳＣＨで送信するために予期される唯一のものではない。この第２の実施形態は、各ＲＬ送信に往復の遅延を付加するが、これはＨＴＴＰアプリケーションのページ応答時間を増す。しかし、第２の実施形態は、第１の実施形態で実行されるように、単に全てのデータをＲＡＣＨで送信するよりも、より大きな帯域幅効率を有する。
【００４６】
ブロック３３０及び３２６の双方の後、制御は分析ブロック３０２に戻る。従って、トラヒックコンテンツ又はトラヒック統計値の分析と、その後の、端末がＲＡＣＨで送信するのかＲＥＳＣＨで送信するのかの判定とは、継続的に行われる。
【００４７】
第３の実施形態（図４を参照）。第３のアプローチは、例えばＨＴＴＰデータフローによってリターンリンク（ＲＬ）上に生成されるトラヒックは、バースト的（bursty）であり、圧縮が使用されるときは低いデータレート要求を有するという認識に部分的に基づく。従って、トラヒックを管理する第３のアプローチは、端末が明示的な予約要求処理を経る必要なく、データフローを予約指向チャネル（ＲＥＳＣＨ）の低いデータレートのサブチャネルに割当てることを含む。本記載において、この低いデータレートのサブチャネルは、それが少なくともページ要求／応答トランザクションの時間の間は「オン（"on"）」である（特定の端末に割当てられる）ので、「常にオンの（"always on"）」チャネルと称される。
【００４８】
有利なことに、「常にオンの」チャネルアプローチは、予約要求遅延を回避するが、これは静止衛星システムにおいて有意（約０．５秒）である。「常にオン」のチャネルアプローチの不利点は、ＨＴＴＰトラヒックのバースト性（burstiness）が理由で、チャネルが割当てられ、「オン」である期間にチャネルが常に利用されるとは限らないことである。しかし、「常にオンの」チャネルが割当てられる複数のユーザの一部のみが実際には送信するので、送信する端末は、より高い出力とより高い符号化／変調で送信することを許される。この結果、端末が送信しないときには、より高い帯域幅効率になり、割当てられた帯域幅を完全には利用しない端末を部分的に補償するより高い効率になり、これによって、全体的な（統計的な）多重化利得を達成する。上述したように、このアプローチはＨＴＴＰトラヒックに限定する必要はない。当該アプローチは、他のタイプのサービスにも同様に用いることができる。
【００４９】
「常にオンの」チャネルをフローに割当てるか否かを判定する１つのアプローチが、以下に議論される。このアプローチは、非限定的な例としてのＨＴＴＰトラヒック、特に、人間のユーザがワールドワイドウェブを従来のウェブブラウザでサーフィンしているときに関連するトラヒックに関して記載される。但し、トラヒックはＨＴＴＰ以外でもよいことが理解される。
【００５０】
簡単に言えば、ゲートウェイは、ユーザが実際に所定の端末に向かっているときを、当該端末に関連するトラヒックの分析に基づいて判定しようと試みる。おそらく、トラヒックはＲＡＣＨ上であり、より速いＲＥＳＣＨを使用する許可を端末に認めるであろうウォルシュ符号は割当てられていない。ゲートウェイが、ユーザは所定の端末を積極的に使用している（つまり、端末が「ビジー（"busy"）」であるかどうか）と判定する場合、ゲートウェイはそのＣＰＥ端末に、ＲＥＳＣＨのサブチャネルを使用する許可を当該端末に与えるウォルシュ符号を割当てる。一実施形態では、割当てられたサブチャネルは、そのデータレートがＲＥＳＣＨの大部分の他のトラヒックよりも遅い「常にオンの」サブチャネルである。
【００５１】
ゲートウェイは、ユーザのウェブセッション全体を通じて「常にオンの」チャネルを維持する意図で、端末に関連付けられたトラヒックを継続的にモニタする。アクティブなチャネルのトラヒックの量が一定レベルの活動率（activity）を下回るとき、ゲートウェイは、個人がもはや端末を積極的には使用していないと結論を下し、「常にオンの」チャネルを使用するための端末の許可を取り消す。また、チャネルトラヒックの本質が、「バックグラウンドの」ＨＴＴＰトラヒックのみが送信されていることを示すときは、ゲートウェイは、個人がもはや端末を積極的には使用していないと結論を下し、「常にオンの」チャネルを使用するためのＣＰＥの許可を取り消す。
【００５２】
このように、ゲートウェイの継続的なモニタリング及び割当ての確保及びＲＥＳＣＨの「常にオンの」サブチャネルの取消しは、複数の端末のための「常にオンの」チャネルに割当て可能な、全体的な（統計的な）帯域幅の使用量を増加する。
【００５３】
「常にオンの」チャネルをデータフローに割当てる判定は、端末によって開始されても、ゲートウェイによって開始されてもよい。端末が「常にオンの」チャネルを要求する場合、それは要求をＲＡＣＨで送信するか、要求を他のＲＡＣＨパケットに「便乗させ（"piggyback"）」てもよい。ＨＴＴＰフローが「常にオンの」チャネルに値すると示される前に、その最初の幾つかのパケットは、予約遅延を回避するために、ＲＡＣＨで送信され得る。いずれにしても、ゲートウェイは、帯域幅を認める最終判定権を有する。
【００５４】
「常にオンの」チャネルのスループット（ビット／秒）は、端末が送信するデータの量を、端末が帯域幅割当てを有する時間の長さで割ったものとして定義され得る。「常にオンの」チャネル上での端末の有効な帯域幅効率は、そのスループットを、端末に割当てられる帯域幅の量で割ったもの、つまり、実際に伝送されるビット／秒／Ｈｚとして定義される。
【００５５】
理想的には、ゲートウェイは、それが「常にオンの」チャネルの帯域幅効率がＲＡＣＨの帯域幅効率よりも大きいと予期する場合、ＲＬ上の端末からのデータフローを検出したときに、端末に「常にオンの」チャネルを割当てるべきである。一例において、ＲＥＳＣＨチャネルのスループットは、名目上は約１．５ビット／秒／Ｈｚ（３ＭＨｚのＲＬチャネルで４．５Ｍｂｐｓ）であるのに対して、ＲＡＣＨのそれは約０．３ビット／秒／Ｈｚである。従って、理想的には、「常にオンの」チャネルで送信したいと思うであろう。
【００５６】
しかし、上述したように、「常にオンの」チャネル割当てを有する全ての端末が、それらに各々割当てられた帯域幅を実際に利用しているわけではない。従って、「常にオンの」チャネルでより高い出力で送信し、ＲＥＳＣＨで名目上使用されるよりも、高い符号化／変調を使用することができるであろう。「常にオンの」チャネルで送信する全ての端末の平均及びピークの送信電力は、隣接する衛星の干渉制限によって許される許容可能なレベル未満である必要がある。
【００５７】
「常にオンの」チャネルが端末に割当てられるべきかを判定する際には、例えば、
−データフローのトラヒック特徴に基づくパラメトリックフロー検出アプローチ、又は
−コンテキストベースのフロー検出メカニズム
といった種々のアプローチが取られ得る。
【００５８】
パラメータベースのアプローチは、フローのトラヒック特徴を使用して、フローが、「常にオンの」チャネルの割当てを保証するための充分に高い有効な帯域幅効率を達成するに足るトラヒックを生成するか否かを予測する。このアプローチにおいて、基本的な概念は、「常にオンの」チャネルを、バイト数が不充分であり長く続かないフローに割当てることを控えることである。このアプローチは、ある期間に端末からゲートウェイで受信されるバイトの及び／又は数パケットの数が一定の閾値を超える場合に、「常にオンの」チャネルをフローに割当てることができる。所定の測定期間におけるパケットの数の制限は、「常にオンの」チャネルを、短時間続く、ＤＮＳルックアップといったトランザクションを含むフローに割当てることを防止することを意図したものである。
【００５９】
フローに、当該フローからのパケット数が一定の閾値未満である場合に、「常にオンの」チャネルを割当てないことの難点は、ＨＴＴＰフローでさえも単独のＧＥＴで始まることにある。その場合、「常にオンの」チャネルは、最初のＧＥＴに対する応答が到達し、多くのＧＥＴを生成するまで、ＨＴＴＰフローに割当てられないであろう。続くＧＥＴは、ＲＡＣＨで進むか、１／２秒の予約遅延を被る。ＨＴＴＰフローをより速やかに検出するために、アプローチは、送信されたバイトの数が閾値を超える場合、又は、送信されたパケットの数が閾値を超える場合に、フローとみなし（call）てもよい。
【００６０】
フローが終了するときに「常にオンの」チャネルを無効にする（rescind）ため、終了基準も提供される。
【００６１】
パラメータベースのメカニズムは、フローの最後のパケットに続く一定のハングオーバータイムを上回ってフローが無活動であるときには、「常にオンの」チャネルを無効にする。このアプローチにおける重要なパラメータは、ハングオーバータイムがどのくらいの長さであるべきかである。
【００６２】
長いハングオーバーのアプローチ（多くの分数）は、「常にオンの」チャネルが、ユーザに対してそのウェブブラウジングセッションの間を通して利用可能なことを保証するように意図される。換言すれば、長いハングオーバー時間は、「常にオンの」チャネルが「考慮時間」の間に取り去られないことを保証する。長いハングオーバーの利点は、ユーザが新たなページを要求するとき、「常にオンの」チャネルを要求するための初期遅延が無いことである。もちろん、長いハングオーバーがあれば、帯域幅が考慮時間の間に浪費され、「常にオンの」チャネルは、そのコンピュータが、単にサイトを周期的にリフレッシュするだけといった処理を常に実行している、多くのＣＰＥに割当てられ得る。
【００６３】
短いハングオーバーモデルでは、「常にオンの」チャネルは、フローの最後のパケットに続く短い時間の後に取り去られる。短いハングオーバーモデルは、帯域幅効率を高めるが、ウォルシュ符号再割当ての数を増加させる。短いハングオーバー時間は、「常にオンの」チャネルが、ページ全体の応答が受信される前に取り去られないことを保証するのに充分に長いが、常にオンのチャネルが考慮時間中に解除されるのに充分に短く選択される。
【００６４】
新たなフローの最初の幾つかのパケット（例えば、ページ要求）は、予約遅延を回避するために、ＲＡＣＨで送信される。このアプローチはＲＡＣＨにトラヒックを付加するが、圧縮を用いることはＧＥＴといったパケットのサイズを相当に減少させ、またＲＡＣＨへの付加的な負荷は小さい。従って、ＲＡＣＨでフローの開始を送信することによって、予約に関連する遅延は回避される。
【００６５】
短いハングオーバーモデルにおけるウォルシュ再割当の数は、長いハングオーバーモデルにおけるよりも相当大きいが、「常にオンの」チャネルをセットアップし取り除くためのシグナリング及び要求される処理時間は、ボトルネックになるべきではない。理由は、ＴＤＭＡスキームでは、帯域幅割当てが、「常にオンの」チャネルに対するよりも動的な方法で実行されるからである。考えられるところでは、各ＧＥＴは、多数の予約要求／許可トランザクションだけでなく、大きな遅延をもたらす別個の予約を必要とするであろう。従って、短いハングオーバー時間での「常にオンの」チャネルの割当ての数は、ＴＤＭＡのＲＬを備えるシステムが要求するチャネル予約の数の下限であるべきである。
【００６６】
「常にオンの」チャネルがフローに割当てられるべきか否かを判定する別のアプローチは、コンテキストベースである（上述）。
【００６７】
ＨＴＴＰプロキシを用いる非限定的な例において、ゲートウェイは、ＨＴＴＰアプリケーションが開始されたことを検出し、従って、「常にオンの」チャネルが割当てられる必要があることを判定できる。「常にオンの」チャネルのデータレートさえも、アクセスされているウェブサイトといった他のコンテキスト的な（contextual）情報に基づいて、判定され得る。「常にオンの」チャネルのデータレートは、ページがクライアントプロキシによってどのようにキャッシュされるかに依存し得るので、クライアントプロキシとゲートウェイとの間に、フローのためのＲＬトラヒックの「期待される」量について通信が提供される。同様に、ゲートウェイは、パケットの内容に基づいて、ページ応答が完了して、「常にオンの」チャネルが無効にされ得ることを検出する。
【００６８】
コンテキストベースの「常にオンの」チャネル割当ての有効な帯域幅効率は、ハングオーバー時間をほとんどゼロに減少することができるため、パラメータベースのアプローチよりも高くなるであろう。
【００６９】
コンテキストベースのフロー検出では、フロー検出は実際にはプロキシの拡張である。換言すれば、ウェブブラウザによって生成されるウェブブラウジングトラヒックは、ユーザがプロキシを使用している場合、検出可能である。これらのユーザに対する「常にオンの」チャネルの割当ては、プロキシエンハンスメントの拡張である。もちろん、コンテキストベースのフロー検出は、ＨＴＴＰ以外のタイプのトラヒックに適用されてもよい。
【００７０】
図４を参照すると、フローチャートは、第３の実施形態の例示的な実施のステップを示すが、ブロック４００は処理の開始を示す。
【００７１】
ブロック４１０は、ブロック３０２（図３）と本質的に同一であり得るトラヒックコンテンツ又はトラヒック統計値を分析するステップを示す。従って、その詳細な記載は繰り返さない。
【００７２】
ブロック４２０は、端末が「ビジー」であるか否かの判定を示す。「ビジー」の定義は、特定のネットワークの実施、特に、使用されているプロトコルに依存する。人間のユーザが、単なる「バックグラウンドの」通信の量又はタイプを超える通信リンクを介した通信を引き起こす方法で、端末とのやり取りに積極的に関与しているとみなされる場合、端末は「ビジー」であるとみなされ得る。
【００７３】
例えば、端末が、ＴＣＰ／ＩＰ及びＨＴＴＰを用いてインターネットウェブサイトと通信している場合（図１を参照）、端末がビジーであるか否かの判定は、端末がウェブページをダウンロードするために積極的に要求を送信しているかどうかの分析を含み得る。ウェブページ要求が積極的に送信されており、ウェブページがインタラクティブなウェブブラウジングセッションに見えるもので実際にダウンロードされている場合、端末はビジーであるとみなされ、制御はブロック４４０に進む。しかし、所定の期間に渡ってユーザインタラクションが無い間、ＴＣＰセッションを維持するのに必要とされる最低限のトラヒックといった、最小限の「バックグラウンドの」通信のみが行われている場合、端末はビジーではないとみなされ、制御はブロック４３０に進む
ブロック４３０は、端末がビジーではないとみなされる場合、予約指向サブチャネルの「常にオンの」サブチャネルのための如何なるウォルシュ符号の割当ても取り消される（un-assigned）（無効にされる）（revoked）ことを示す。ウォルシュ符号が既に端末に割当てられていない場合、ブロック４３０は如何なる動作も実行しない。ウォルシュ符号の取消しは端末に通信されるが、当該端末は次に、ブロック４３２で示されるようにＲＡＣＨで送信する。
【００７４】
逆に、ブロック４４０は、端末がビジーであるとみなされる場合、予約指向サブチャネルの「常にオンの」サブチャネルのためのウォルシュ符号が割当てられる。ウォルシュ符号が端末に予め割当てられている場合、ブロック４４０は如何なる動作も実行せず、以前のウォルシュ符号割当ては有効である。如何なる新たなウォルシュ符号割当ても端末に通信されるが、これは次に、ブロック４４２に示されるように、ＲＥＳＣＨで送信する。
【００７５】
ブロック４３２及び４４２の双方の後、処理は分析ブロック４１０に戻る。従って、トラヒック統計値又はトラヒックコンテンツの分析、並びにその後の、端末がビジーであるか否か、及び、端末がＲＡＣＨ又はＲＥＳＣＨのどちらで送信するかの判定は、継続的に行われ得る。
【００７６】
第４の実施形態（図５Ａ、５Ｂを参照）。第４のアプローチでは、端末は最初にそのパケットをＲＡＣＨで送信する。各パケットは、端末の「Ｑ状態（"Q-state"）」を含む。ここで、「Ｑ状態」は、端末の出力バッファ（キュー）にあるデータの量を示す。Ｑ状態の値は、例えば、Ｑ状態の最初のビットの送信時に端末の送信キューに残るバイト数であってもよい。Ｑ状態は、送信されるパケットに様々な方法で含まれ得る。例えば、Ｑ状態は、あらゆるＭＡＣパケットの末尾に付加されてもよく、当該付加は、あるいは送信ＡＳＩＣ（特定用途向け集積回路）によって行われ得る。
【００７７】
端末から受信されるＱ状態に基づいて、ゲートウェイは端末に予約チャネルを割当てることを判定してもよい。この場合、ノード（ゲートウェイ）は、端末に、その割当てられてウォルシュ符号と、それに割当てられた予約チャネルの機関を通知する。
【００７８】
一旦、端末が予約チャネルで送信し始めると、端末はそのＱ状態を送信し続ける。ノードは、端末によって送信されたＱ状態の値に基づいて、端末の予約チャネルのウォルシュ符号を、より短いウォルシュ符号（より高いレートのチャネル）にアップグレードする、現在のチャネルの時間を延長する、又は、より長いウォルシュ符号（より低いデータレートのチャネル）を割当てることを判定し得る。
【００７９】
図５Ａ、５Ｂを参照すると、フローチャートは、第４の実施形態の例示的な実施のステップを示し、ブロック５００は処理の開始を示す。
【００８０】
ブロック５１０は、端末の、ＲＡＣＨでのその出力バッファローディング（Ｑ状態）の送信を示す。ブロック５２０は、Ｑ状態が所定のＱ状態閾値を満たすか、又は超えるかの判定を示す。Ｑ状態が閾値未満である場合、制御は、端末がＲＡＣＨで送信することを示すブロック５３０に進む。
【００８１】
しかし、Ｑ状態が閾値を満たすか超える場合、制御は、予約指向チャネルの「常にオンの」サブチャネルのためのウォルシュ符号の、端末へのノードによる割当てを示す、ブロック５４０に進む。ブロック５４２は、端末が、予約指向チャネルの「常にオンの」サブチャネルでの送信を保証することを示す。ブロック５４４は一般に、端末が予約指向サブチャネルで送信するときに発生する処理を示す。図５Ｂを参照しつつ、ブロック５４４が、より詳細に以下に説明される。
【００８２】
端末が、もはやＲＥＳＣＨで（又は、その「常にオンの」サブチャネルで）送信しないとき、制御はブロック５４４から、端末がＲＥＳＣＨ又はそのサブチャネルで送信しなくなってから、端末がＲＡＣＨで送信することを示す５３０に進む。
【００８３】
ブロック５３０の後、制御はブロック５１０に戻る。このように、端末のＱ状態のモニタリングと、その後の、端末の出力キューローディングは、端末が予約チャネルで送信するのを許可するウォルシュ符号の割り当てを保証するか否かの判定とが、継続的に行われ得る。
【００８４】
ところで図５Ｂを参照すると、予約チャネルの処理（図５Ａのブロック５４４）の詳細が、更に詳しく提示される。
【００８５】
ブロック５５０は、端末の、ＲＥＳＣＨでのその出力バッファローディング（Ｑ状態）の送信を示す。ＲＥＳＣＨでのＱ状態の送信は、ブロック５１０の、ＲＡＣＨでのＱ状態の送信と対照をなす。
【００８６】
ブロック５５２は、ノードの最近のＱ状態の履歴の分析を示す。望ましくは、この分析はノード（ゲートウェイ）で行われるが、このロケーションを用いることは必要ではない。いずれにしても、一以上の最近のＱ状態に基づいて、端末が、幾つかの考え得るチャネル：
−予約指向送信チャネルは全くないが、その代わりにランダムアクセスチャネル（ブロック５６０及び図５Ａに戻る）、
−より遅い速度の予約指向送信チャネル（ブロック５７０、５７２）、
−同一速度の予約指向送信チャネル（ブロック５８０）、又は
−より高速の予約指向チャネル（ブロック５９０、５９２）
のうちの１つを割当てられるに値するかどうかについての判定がなされる。
【００８７】
Ｑ状態の履歴が、端末の出力バッファローディングは、閾値を下回るように、又は他の基準を満たすように減少されつつあることを示す場合、端末の傾向はＲＥＳＣＨを実質的に充分に利用しないことであると結論が出され、従って、端末のウォルシュ符号はブロック５６０で取り消される。ノードは、ウォルシュ符号の取消しを端末に通信し、制御はブロック５６０からブロック５３０（図５Ａ）に戻るが、これはＲＡＣＨでの送信を示す。
【００８８】
Ｑ状態の履歴が、端末の出力バッファローディングは、別の閾値を下回るように、又は他の基準を満たすように減少されつつあることを示す場合、端末の傾向は現在のＲＥＳＣＨを若干充分には利用しないことであると結論が出される。従って、端末の現在のウォルシュ符号は、ブロック５７０において、より長いウォルシュ符号に置き換えられる。ノードは、ウォルシュ符号の変更を端末に通信し、制御は、以前に割当てられたＲＥＳＣＨよりも遅い送信速度を有する新たなＲＥＳＣＨで端末が送信することを示す、ブロック５７２に進む。
【００８９】
Ｑ状態の履歴が、端末の出力バッファローディングはおおよそ安定しているか、他の基準を満たすことを示す場合、端末は現在のＲＥＳＣＨを適切に利用していると結論が出される。従って、端末の現在のウォルシュ符号は変更されないまま残り、有効である。制御は直接ブロック５８０に進むが、ブロック５８０は、端末が今まで送信していた同一のＲＥＳＣＨチャネル（又は、少なくとも、同一の送信速度を有するＲＥＳＣＨチャネル）で送信することを示す。
【００９０】
最後に、Ｑ状態の履歴が、端末の出力バッファローディングが所定の閾値を上回るように、又は他の基準を満たすように増加されつつあることを示す場合、端末の傾向は現在のＲＥＳＣＨを過度に利用すること（over-utilize）であると結論が出される。従って、端末の現在のウォルシュ符号は、ブロック５９０において、より短いウォルシュ符号に置き換えられる。ノードは、ウォルシュ符号の変更を端末に通信し、制御は、以前に割当てられたＲＥＳＣｈよりも速い送信速度を有する新たなＲＥＳＣＨで端末が送信することを示すブロック５９２に進む。
【００９１】
いずれにしても、ブロック５７２、５８０、５９２のうちのいずれかの後、制御はその後のＱ状態の通信のためブロック５５０に戻る。従って、端末の出力バッファキューの分析と、その後の、端末のＱ状態の履歴が異なる速度のＲＥＳＣＨ又はＲＡＣＨさえも保証するか否かの判定とは、継続的に行われ得る。
【００９２】
２以上のＱ状態の履歴を使用することは、端末の出力バッファローディング中の如何なる偽のＱ状態の値又は短期的な例外も「平均する（"averages out"）」。このアプローチは、端末がＲＡＣＨ送信とＲＥＳＣＨ送信（図５Ａ対図５Ｂ）との間で不必要に切り替えられる回数を減少させる。更に、このアプローチは、所定の端末のＱ状態が保証する帯域幅の量を判定するために、高度な分析的な技術が採用されることを可能にする。
【００９３】
この第４の実施形態の特定の実施は、
−「ＣＰＥ」（加入者宅内機器）は、本明細書全体に渡って提示される「端末」をサポートし、
−「ゲートウェイ」は、本明細書全体に渡って提示される「ノード」をサポートし、
−「ＲＡＣＨ」は、ランダムアクセス（予約無しの）チャネルをサポートし、
−「ＲＥＳＣＨ」（予約チャネル）は、予約指向チャネルをサポートし、
−「ＲＬ」（リターンリンク、時には、リバースリンク）は、ＲＡＣＨ、ＲＥＳＣＨ、及びことによると他のチャネルが見出され得る通信ネットワークの一部をサポートし（図１の例を参照）、
−「ＦＬ」（フォワードリンク）は、ネットワークにおいてＲＬとは反対の方向にデータを送信するリンクである（図１の例を参照）
という理解の下、以下に記載される。
【００９４】
ＣＰＥにおけるスケジューラは、ゲートウェイに向けられたＣＰＥのパケットがＲＡＣＨ又はＲＥＳＣＨのどちらで進むのかを判定する。最初のＣＰＥ送信が始まると、それはＲＡＣＨで進む。しかし、その後、ＣＰＥのＲＬの送信キューが蓄積すると、ゲートウェイは、現在のデータ転送のダウンロード処理を加速するために、予約チャネル（ＯＣＤＭＡチャネル上の短いウォルシュ符号）を割当てる必要があり得る。ＣＰＥは、ＲＬのＱ状態の情報を、当該情報をゲートウェイに送信されるあらゆるＭＡＣパケットに付加することで、ゲートウェイに定期的に報告する。ゲートウェイは、ＲＬキューの深さ閾値に基づいて、現在報告されているＲＬのＱ状態が当該閾値を超える場合、ＣＰＥのために予約をする必要があると判定する。これは、より高いレートの予約でキュー・ビルトアップ・ワークロードを空にする方が、ワークロードをクリアアップするために既存のレートに固執するよりも、要する時間が少ないであろう、という推論に基づく。ゲートウェイは次に、ＣＰＥに対する予約にどのレート（短いウォルシュ符号）をどのくらいの期間割当てるべきかを判定しなければならない。レートは、短いウォルシュ符号の利用可能なプールからの最良のレートで判定される。ゲートウェイは次に、当該レートで送信するのに要求される出力がＣＰＥによってサポートできる（即ち、ＣＰＥにおける電力増幅器（ＰＡ）の最大送信電力を超えない）かどうかを判定する。さもなければ、ＣＰＥで要求される送信電力が最大のＰＡ電力を超えないように最良の可能なレートが選択され、予約（短いウォルシュ符号の割当て）がＣＰＥについてなされる。
【００９５】
ゲートウェイは、ＣＰＥに予約を割当てたときから、ＣＰＥからのＱ状態の情報をモニタし続ける。その後のＱ状態の最新情報（updates）が、非減少的である場合、現在の予約は、現在の予約期間の終了を超えて延長されることができる。現在の予約は、最初のＱ状態の情報に基づいて割当てられているので、ＣＰＥは、そのキューサイズをクリアアップするために、現在のより高いＱ状態情報に基づいて、延長された予約期間を与えられる必要がある。延長された予約が保証され得る適用例の典型的な例は、ｆｔｐアップロードの場合である。この場合、連続的なＱ状態の最新情報が、より高い値のＲＬキューサイズで到達し、ゲートウェイは、ＲＬキューからワークロード全体がクリアされるまで、予約期間を延長し続ける必要がある。
【００９６】
また、ゲートウェイが、現在のところ利用可能な短いウォルシュ符号が存在しないことを知る場合、ＣＰＥが（そのＱ状態の情報を介して）予約を得るための資格を得る場合には、それは後で説明されるように短いウォルシュ符号のオーバーロードシナリオで取り扱う。
【００９７】
ゲートウェイは、短いウォルシュ符号の割当て／非割り当てを集中的に調整する。この詳細、及び、短いウォルシュ符号の割当て／非割り当てに要求されるシグナリングは、続くセクションで説明される。
【００９８】
ＣＰＥとゲートウェイで維持される状態変数  
ＣＰＥとゲートウェイの両者は、接続の状態を多くの状態変数によって維持する。ゲートウェイは、これらの状態変数の一部をＣＰＥごとに、即ち、現在登録されており、システムの一部である全てのＣＰＥについて維持する。これらの状態変数は、
・CurrentState−ＲＬ上での送信の現在の状態、即ち、それがＲＡＣＨ上であるかＲＥＳＣＨ上であるかを表す。ＣＰＥがパケットがＲＡＣＨ又はＲＥＳＣＨのいずれかで送信されるべきことをスケジュールすることに基づく。
【００９９】
・QueueSizeCPE−ＣＰＥからの到達するＭＡＣパケットによって報告されるＣＰＥにおける現在の送信キューサイズ（ビット）を示す。キューサイズＣＰＥは、到達するＭＡＣパケットサイズを除いたＲＬのＭＡＣキューサイズを表す。
【０１００】
・QueueSizeGW−ＣＰＥからの新たなＭＡＣパケットの到来の丁度前に、ゲートウェイで維持される、現在の送信キューサイズ（ビット）を表す。
【０１０１】
・QueueDepthThreshold−ＣＰＥが予約の資格を得る、送信キューサイズの閾値（ビット）を表す。
【０１０２】
・CurrentRate−当該ＣＰＥが、ＲＬ上でゲートウェイにパケットを送信する現在のレート（ビット／秒、ｂｐｓ）を表す。ゲートウェイは、この変数をＣＰＥ毎に維持する。
【０１０３】
・CurrentTime−ゲートウェイにおける現在のＣＤＭＡ時間を表す。
【０１０４】
・RTT−静止リンク（geostationary link）の往復の時間（秒）を意味する。ゲートウェイでは、この変数の１つのインスタンス（instance）のみが維持される。
【０１０５】
・GuardTime−１つのビームにおける、任意の２つのＣＰＥによって被り得るＦＬの伝搬遅延の最大差異に等しい。ゲートウェイは、この変数の１つのインスタンスのみを維持する。
【０１０６】
・ResvTime−ゲートウェイによってＣＰＥに割当てられる短いウォルシュ符号予約の予約時間に等しい。ゲートウェイは、この変数のインスタンスをＣＰＥ毎に維持する。
【０１０７】
・StartResvTime−ゲートウェイにおける短いウォルシュ符号予約チャネルの開始時間を表す。CurrentTimeで判定される予約について、（予約がＣＰＥで始まるとき）StartResvTimeは、CurrentTime＋１／２ＲＴＴ＋ゲートウェイにおけるGuardTimeに設定される。ゲートウェイは、ビーム中の全てのＣＰＥが予約メッセージを聞き、それらの予約を予約開始時間に開始できるようにするため、１／２ＲＴＴの平均のＦＬ伝搬遅延のGuardTimeの期間の許可を与える。
【０１０８】
・EndResvTime−ＣＰＥについての短いウォルシュ符号の予約時間の終了を表す。これは、StartResvTime＋ResvTimeに等しい。
【０１０９】
である。
【０１１０】
ＣＰＥ送信手続き  
ＣＰＥは、ゲートウェイに送信されるあらゆるデータパケットにＱ状態の情報を付加する。
【０１１１】
ＣＰＥ受信手続き  
ＣＰＥは、新たな短いウォルシュ符号予約又は現在の予約の終了を示すシグナリングパケットをゲートウェイから受信する。
【０１１２】
新たな短いウォルシュ符号予約がある場合、ＣＰＥは、予約開始時間の始まりにおいて現在の状態をＲＥＳＣＨに等しく設定し、予約は予約終了時間まで続く。一旦、予約が終了すると、将来の送信がＲＥＳＣＨの代わりにＲＡＣＨで発生することを表すために、現在の状態はＲＡＣＨに戻される。
【０１１３】
ＣＰＥが、現在の予約の終了を示すシグナリングの表示を受信する場合、ＣＰＥは、シグナリングメッセージで示された終了時間から、現在の状態をＲＡＣＨに設定する。
【０１１４】
ゲートウェイの要件  
このセクションでは、ゲートウェイの、どの閾値でＣＰＥが短いウォルシュ符号予約を得る資格を得るのかを判定する手続き、ＣＰＥに対する短いウォルシュ符号の割当て／非割り当ての手続き、現在の予約セッションを延長する手続きが論じられる。ゲートウェイの予約アルゴリズムの全体が論じられる。
【０１１５】
ゲートウェイ受信手続き  
ゲートウェイは、ＭＡＣパケットをＣＰＥから受信し、Ｑ状態フィールドを読み、受信したＱ状態にQueueSizeCPE変数を更新する。ＣＰＥが予約を有さない（即ち、その現在の状態がＲＡＣＨである）場合、ゲートウェイはまず、ＣＰＥが短いウォルシュ符号の予約の資格があるかどうかを判定しなければならない。
【０１１６】
ゲートウェイにおける新たな予約手続き  
現在の予約を持たないフローが予約を得る資格を有するかどうか判定するためのＲＬキューの深さ閾値基準は、以下の方程式によって与えられる。  
【数１】
2010093826.tif 000003
【０１１７】
（ＲＬキューの深さ閾値判定）  
上記方程式の簡単な説明は以下の通りである。予約を与えることによってＲＬ送信キュー中のワークロードをクリアするのにかかる時間が、現在の送信レートにおいてＲＬキューをクリアするのにかかる時間、即ち、
【数２】
2010093826.tif 000004
【０１１８】
よりも短い場合のみ予約がなされる。
【０１１９】
不等式のＬＨＳ（左側（left hand side））は、項（RTT/2+RTT/2+GuardTime）を有するが、これは、その後にＣＰＥで予約が開始される往復の総遅延である。ＲＴＴ／２は、その後に結果として予約になるＭＡＣパケットがゲートウェイに到達し、ゲートウェイが予約をする、平均のＲＬ伝搬遅延であり、RTT/2+GuardTimeは、その前にＣＰＥにおいえて予約が開始されるＦＬ伝搬遅延＋GuardTimeを説明する。ＬＨＳの第２の項は、新たなより高速のレートまでの総サービス時間である（それは、RTT+GuardTimeの期間に古いレートで排出されるＲＬキューを説明することに注意されたい）。不等式のＲＨＳ（右側（right hand side））は、ＲＬキューを現在のサービスレートでサービスするための総サービス時間である。
【０１２０】
ゲートウェイにおける短いウォルシュ符号のプールは、Ｗ８、Ｗ１６、Ｗ３２、Ｗ６４、Ｗ１２８及びＷ２５６の短いウォルシュ符号の種々のプールに分割される。利用可能なウォルシュ符号のリストから、ゲートウェイは、一定の制約が満たされるように、最大データレートを備える短いウォルシュ符号を選択する。まず、レートは、全てのＣＰＥから隣接する衛星に放射される総出力が、ＦＣＣ（米国連邦通信委員会）で規定された限度内であるようにするべきである。一旦、短いウォルシュ符号が上記の基準に基づいて選択されると、ゲートウェイは、送信レートに要求される出力（Prequired）をＣＰＥによってサポートできる（即ち、Prequired＜Pmax、ここでPmaxは許容可能な最大ＰＡ送信電力）かどうかを判定する。このレートがサポート可能である場合、レートはRateWCに設定される。さもなければ、ゲートウェイは、何が次善のサポート可能なレートであるかを判定し、それがRateWCに設定される。予約時間ResvTimeは、
【数３】
2010093826.tif 000005
【０１２１】
（資格要求フローのための予約時間の判定）
として計算される。
【０１２２】
予約は、StartResvTime = CurrentTime + 1/2RTT + GuardTimeから開始し、EndResvTime = StartResvTime + ResvTimeまで続く。ゲートウェイはまた、状態変数QueueSizeGWをQueueSizeCPEに更新する。
【０１２３】
短いウォルシュ符号の予約情報（短いウォルシュ符号、StartResvTime、EndResvTime）は、ゲートウェイからＣＰＥにシグナリングメッセージによって運ばれる。ゲートウェイは、このメッセージをＣＰＥにＦＬ制御チャネルで送信する。
【０１２４】
新たな予約をＣＰＥに割当てるアルゴリズム  
ゲートウェイは、Ｑ状態情報（QueueSizeCPE）をＣＰＥから受信する。
【０１２５】
それは、Ｑ状態情報が受信されると、CurrentTimeを更新する。  
if（ＣＰＥが現在、予約を受信していない）
／／予約のための閾値基準をチェック
if（QueueSizeCPE > (RTT + GuardTime)*CurrentRate）
／／利用可能な短いウォルシュ符号があるかどうかをチェック
if(少なくとも１つの短いＷＣについて、CurrentTime > EndResvTime)
１．使用可能な（free）ウォルシュプールと他の制約によって許容される、
最大レートを有する短いウォルシュ符号を選択し、ＣＰＥは要求される送信
出力をサポートできる。そのレートはRateWCによって与えられるものとする。
【０１２６】
２．予約時間、ResvTimeを計算。
【数４】
2010093826.tif 000006
【０１２７】
３．短いウォルシュ符号をＣＰＥにResvTimeの期間、即ち、
StartResvTime = CurrentTime + 1/2RTT + GuardTimeから開始し、
EndResvTime = StartResvTime + ResvTimeまで、割当てる。
【０１２８】
４．予約をＣＰＥにシグナリングメッセージを介して通信。
【０１２９】
endif
endif
endif
（予約を新たなフローに割当てるアルゴリズム）
【０１３０】
既存の予約を有するフローに対する予約を延長  
ゲートウェイによって最初に判定される予約期間は、ＣＰＥが、増加するQueueSizeCPEを有する、その後のＱ状態報告を提供する（即ち、ＣＰＥの送信キューが増加している）場合には、充分でないことがある。そのような場合、ゲートウェイは、ＣＰＥが現在の予約について延長を得る資格があるかどうか、またそうであれば、当該予約はどのくらい延長されるべきかを判定する。
【０１３１】
ゲートウェイはまず、現在のシステム時間、即ちCurrentTimeが、EndResvTimeよりも大きいかどうかを判定する。そうであれば、これは、ＣＰＥがその現在の予約について（その現在の予約がEndResvTimeで失効したため）延長を得られないが、新たな予約処理を経なければならないことを意味する。それは更に、登録延長メッセージが、その現在の予約がEndResvTimeで失効する前に、即ち、CurrentTime < EndResvTime - (1/2RTT + GuardTime) - (送信 + 受信 + 処理遅延)に、ＣＰＥに到達するのに充分な時間があるかどうかをチェックする。無い場合、ゲートウェイは、ＣＰＥに対して予約を延長することができない。現在の予約が失効していない場合、ゲートウェイは、最後のＱ状態報告からのQueueSizeCPEのインクリメンタルな増加／減少を判定する。つまり、ゲートウェイは、deltaQueue = (QueueSizeCPE − QueueSizeGW + CurrentReceivedPacketSize)を判定する。増加があれば、それは、予約の増加をdeltaQueue/RateWCとして計算する。ゲートウェイは、EndResvTime = EndResvTime + deltaQueue/RateWCを更新し、QueueSizeGWもQueueSizeCPEに更新する。ゲートウェイは次に、インクリメンタルな予約情報（短いウォルシュ符号、EndResvTime）をＣＰＥにシグナリングメッセージによって送信する。ゲートウェイは、このメッセージをＣＰＥにＦＬ制御チャネルで送信する。
【０１３２】
ＣＰＥに対する既存の予約を延長するアルゴリズム  
ゲートウェイは、Ｑ状態の情報（QueueSizeCPE）をＣＰＥから受信する。  
if(予約が上記の基準のとおり延長できる)
【数５】
2010093826.tif 000007
【０１３３】
（予約を有するフローに対する予約を延長するアルゴリズム）
【０１３４】
予約レートの変更（ＣＰＥにおいて現在の予約レートを維持できない）  
ＣＰＥの予約期間の間、ゲートウェイは、現在のレートで送信するのに要求されるＣＰＥにおける出力（Pdesired）が、最大ＰＡ送信電力（Pmax）の範囲内かどうかを継続的にモニタする。基準が満たされる場合、ＣＰＥは、現在のレートで送信を継続することを許可される。（レインフェード（rain fade）のように変化するチャネル状態のために）基準が満たされない場合、ゲートウェイは、そのレートテーブルに基づいて許可され得る最大レートを再計算する。
【０１３５】
ゲートウェイは、ＣＰＥに対する現在の予約を取消し、ＦＬ制御チャネル上での新たなレートを有する新たな予約メッセージを介して新たな予約をＣＰＥに通信する。
【０１３６】
新たな予約に対する短いウォルシュ符号の再割当て、ゲートウェイにおけるオーバーロード手続き  
ＣＰＥフローが予約の資格を得ると仮定する。ゲートウェイは、現在処理されている（taken up）任意の短いウォルシュ符号について、CurrentTime > EndResvTimeであるかどうかをチェックする。より積極的なアプローチは、現在処理されている任意の短いウォルシュ符号について、CurrentTime > EndResvTime − 1/2RTT + GuardTimeかどうかをチェックすることであろう。これは、ＣＰＥで同一の短いウォルシュ符号を使用している既存の予約が失効する前に、短いウォルシュ符号を再使用するために予約の判定がゲートウェイによってなされ得ることを意味する。これは、新たな予約はCurrentTime + 1/2RTT + GuardTimeからのみ開始するが、これは、> EndResvTime + 2*GuardTimeであることが保証され、以前の予約はEndResvTimeで終了するので、より有効であり、従って、予約割当ての際に衝突がない。これはまた、短いウォルシュ符号は、2*GuardTimeの期間には利用されていなが、これは、以前の伝統的なアプローチによる再割当ての間の1/2RTT + GuardTimeの期間の浪費に比較すると、大変小さなオーバーヘッドである（GuardTIme << 1/2RTT）ので、予約割当ての効率も改善する。
【０１３７】
上記２つの設計上の選択の間で、より有効なアプローチが採用される、すなわち、ゲートウェイによってCurrentTime > EndResvTime − 1/2RTT + GuardTimeかのチェックがなされる。そうであれば、利用可能な予約が存在し、ゲートウェイは予約を割当てる。そうではなく、利用可能な予約が存在しない場合（短いウォルシュ符号のオーバーロード状態）、ゲートウェイはＣＰＥに対する予約を拒む（すなわち、Ｑ状態情報に基づいて作動せず、予約を提供しない）。
【０１３８】
ゲートウェイにおける予約の割当て／非割当てのシグナリング要件  
ゲートウェイは、ＣＰＥに対する短いウォルシュ符号の予約の割当て及び非割当てを制御及び調整する。予約アルゴリズムによって、短いウォルシュ符号は、現在の予約期間の失効時（EndResvTime）に割当てが取り消され、ＣＰＥは、それが短いウォルシュ符号の予約を放棄したことをゲートウェイに知らせない（not signal）、と仮定される。EndResvTimeは、ＣＰＥに割当てられる最初の（original）予約期間ではなく、予約の複数回の延長後の更新されたEndResvTimeであり得る。ＣＰＥに対する全ての新たな予約割当て及びその後の予約期間の延長について、ゲートウェイは、ＦＬ制御チャネル上で送信されるシグナリングメッセージを介してＣＰＥに明示的に通知する。
【０１３９】
ＣＰＥアルゴリズム  
ＣＰＥは、Ｑ状態情報（QueueSizeCPE）をゲートウェイに向けられたデータパケットで送信する。
【０１４０】
ゲートウェイアルゴリズム  
ゲートウェイは、Ｑ状態情報（QueueSizeCPE）をＣＰＥから受信する。
【０１４１】
それは、Ｑ状態情報が受信されると、CurrentTimeを更新する。
【０１４２】
if(ＣＰＥが現在、予約を受信していない)
／／予約の閾値基準をチェック
if(QueueSizeCPE > (RTT + GuardTime)*CurrentRate)
／／利用可能な短いウォルシュ符号があるかチェック
if(少なくとも１つのＷＣについてCurrentTime > EndResvTime − 1/2RTT + GuardTime)
１．使用可能な（free）ウォルシュプールと他の制約によって許容される、
最大レートを有する短いウォルシュ符号を選択し、ＣＰＥは要求される送信
出力をサポートできる。そのレートはRateWCによって与えられるものとする。
【０１４３】
２．予約時間、ResvTimeを計算。
【数６】
2010093826.tif 000008
【０１４４】
３．短いウォルシュ符号をＣＰＥにResvTimeの期間、即ち、
StartResvTime = CurrentTime + 1/2RTT + GuardTimeから開始し、
EndResvTime = StartResvTime + ResvTimeまで、割当てる。
【０１４５】
４．予約をシグナリングメッセージを介してＣＰＥに通信。
【０１４６】
else
現在、利用可能な短いウォルシュ符号は存在せず、ゲートウェイはＣＰＥに
対する予約を拒む。
【０１４７】
endif
endif
else／／ＣＰＥは現在、予約を受信している
／／ＣＰＥは予約の延長が必要かどうかをチェック
deltaQueue = QueueSizeCPE − QueueSizeGW + CurrentReceivedPacketSize
if(deltaQueue > ０で、予約が延長できる)
IncrementResv = deltaQueue/RateWC
IncrementResvをシグナリングメッセージを介してＣＰＥに通信
EndResvTime = EndResvTime + IncrementResvに更新
endif
QueueSizeCW = QueueSizeCPEに更新
／／ゲートウェイは、ＣＰＥにおいて要求される送信電力が最大ＰＡ送信電力を超えているため、現在の予約レートは維持できないと判定。代わりに、維持できる、より低いレートが通知される。
【０１４８】
if(新たな予約が要求される)
１．新たな短いウォルシュ符号割当てに基づいて、新たなResvTimeを再計算。
【０１４９】
２．短いウォルシュ符号をＣＰＥにResvTimeの期間、即ち、StartResvTime =
CurrentTime + 1/2RTT + GuardTimeから開始し、EndResvTime = StartResvTime
+ ResvTimeまで、割当てる。
【０１５０】
３．シグナリングメッセージを介して新たな予約をＣＰＥに通信し、同時に、ＣＰＥに対する古い予約は無効にする。
【０１５１】
endif
endif
【０１５２】
第５の実施形態（図６を参照）。第４の実施形態の教示の一部は、第３の実施形態に関して記載されたチャネルの「常にオンの」サブチャネルに関連して用いられてもよい。ゲートウェイは、端末が「ビジー」がどうかを当該端末のＱ状態に基づいて判定し、それがビジーである限り、予約指向チャネルの「常にオンの」サブチャネルを使用するように端末を更新し得る。
【０１５３】
図６を参照すると、フローチャートは第５の実施形態の例示的な実施のステップを示し、ブロック６００は処理の開始を示す。
【０１５４】
ブロック６１０は、端末による、端末のＱ状態（出力バッファローディング）のノード（ゲートウェイ）への送信を示す。この送信は、（端末が現在、ＲＥＳＣＨで送信する許可を有するとすれば）ＲＡＣＨ上、又は（端末が現在、ＲＥＳＣＨで送信する許可を有するとすれば）ＲＥＳＣＨ上のいずれかである。
【０１５５】
ブロック６２０は、端末が「ビジー」であるか否かの判定を示す。「ビジー」の定義は、特定のネットワークの実施、特に、使用されているプロトコルに依存する。人間のユーザが、単なる「バックグラウンドの」通信の量又はタイプを超える通信リンクを介した通信を引き起こす方法で、端末とのやり取りに積極的に関与しているとみなされる場合、端末は「ビジー」であるとみなされ得る。ブロック６２０は、ブロック４２０（図４）と本質的に同一であり、その詳細な記載は反復されないであろう。
【０１５６】
ブロック６３０は、端末がビジーではないとみなされる場合、予約指向サブチャネルの「常にオンの」サブチャネルについての如何なるウォルシュ符号も割当てが取り消される（無効にされる）。以前に端末にウォルシュ符号が割当てられたことがない場合、ブロック６３０は如何なる動作も実行しない。ウォルシュ符号の取消しは端末に通信されるが、これはその後ブロック６３２に示されるようにＲＡＣＨで送信する。
【０１５７】
逆に、ブロック６４０は、端末がビジーであるとみなされる場合、予約指向サブチャネルの「常にオンの」サブチャネルについてのウォルシュ符号が端末に割当てられることを示す。以前にウォルシュ符号が端末に割当てられたことがある場合、ブロック６４０は如何なる動作も実行せず、以前のウォルシュ符号割当ては有効なままである。如何なる新たなウォルシュ符号割当ても端末に通信されるが、これはその後ブロック６４２に示されるようにＲＥＳＣＨで送信する。
【０１５８】
ブロック６３２及び６４２の双方の後、制御は分析ブロック６１０に戻る。従って、端末の出力バッファローディングの分析、並びにその後の、端末がビジーであるか否か及びそれがＲＡＣＨ又はＲＥＳＣＨのどちらで送信するのかの判定は、継続的に行われ得る。
【０１５９】
本明細書に記載された方法については、少なくとも１つのデータ処理装置を有するコンピュータシステムでの実行のためのプログラム命令を記憶する（記憶媒体といった）コンピュータプログラム製品も提供され、その命令は、当該コンピュータシステムによって実行されるときに、当該コンピュータシステムに本明細書に記載された方法を行わせる。
【０１６０】
更に、本明細書に記載された方法を行うシステムが提供されるが、当該システムは、少なくとも１つの端末（又は加入者宅内機器）と（ゲートウェイといった）ノードを備える。端末とノード（又はゲートウェイ）等は、当業者によって容易に実施され得る。一般に、これらの要素は、実行される機能に適当であると当業者に公知の技術を採用する、任意の適当なコンピュータとして実施されてもよい。コンピュータ技術の当業者には明白であるだろうが、端末又はノードは、前述の教示に従ってプログラムされた従来の汎用コンピュータを用いて実施されてもよい。ソフトウェア技術の当業者には明白であるだろうが、適当なソフトウェアは、本開示の教示に基づいて、通常のスキルを持つプログラマによって容易に準備することができる。他の利用可能なオペレーティングシステムと動作する、他の適当なプログラミング言語が選択されてもよい。
【０１６１】
汎用コンピュータは、コンピュータハウジングが、ＣＰＵ（中央処理装置）、ＤＲＡＭ（ダイナミックランダムアクセスメモリ）、ＲＯＭ（読み出し専用メモリ）、ＥＰＲＯＭ（消去可能なプログラム可能読み取り専用メモリ）、ＥＥＰＲＯＭ（電気的消去可能プログラマブル読出し専用メモリ）、ＳＲＡＭ（スタティックＲＡＭ）、ＳＤＲＡＭ（シンクロナスダイナミックＲＡＭ）、及びフラッシュＲＡＭ（ランダムアクセスメモリ）といったメモリ、ＡＳＩＣ（特定用途向け集積回路）といった他の特殊用途の論理デバイス、又は、ＧＡＬ（ジェネリックアレイロジック）及び再プログラム可能なＦＰＧＡ（フィールドプログラマブルゲートアレイ）といった構成可能な（configurable）論理デバイスとを収容し得る、前述の方法を実施し得る。
【０１６２】
各コンピュータはまた、複数の入力装置（例えば、キーボード、マイク、及びマウス）、及び、モニタを制御するためのディスプレイコントローラを備えてもよい。また、コンピュータは、フロッピー（登録商標）ディスクドライブ、他の取り外し可能な媒体装置（例えば、コンパクトディスク、テープ、及び取り外し可能な光磁気媒体）、ＳＣＳＩ（小型コンピュータシステムインタフェース）バス、エンハンストＩＤＥ（integrated drive electronics）バス、又はウルトラＤＭＡ（ダイレクトメモリアクセス）バスといった適切なデバイスバスを用いて接続される、ハードディスク又は他の固定された高密度のメディアドライブを備え得る。コンピュータはまた、コンパクトディスクリーダ、コンパクトディスクリーダ／ライタ・ユニット、又はコンパクトディスクジュークボックスを備えてもよいが、これは同一のデバイスバス又は別のデバイスバスに接続され得る。
【０１６３】
上述したように、システムは、少なくとも１つのコンピュータ読み取り可能な媒体を備える。コンピュータ読み取り可能な媒体の例には、コンパクトディスク、ハードディスク、フロッピー（登録商標）ディスク、テープ、光磁気ディスク、ＰＲＯＭ（例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュＥＰＲＯＭ）、ＤＲＡＭ、ＳＲＡＭ、ＳＤＲＡＭ）が含まれる。
【０１６４】
コンピュータ読み取り可能な媒体のうちの任意の一つ又はその組合せに記憶されるのは、コンピュータのハードウェアの双方を制御し、コンピュータが人間のユーザとやり取りすることを可能にして、上述した機能を実行するソフトウェアである。そのようなソフトウェアは、ユーザアプリケーション、デバイスドライバ、オペレーティングシステム、開発ツールなどを含むが、これらに限定されるものではない。
【０１６５】
そのようなコンピュータ読み取り可能な媒体は更に、実行時に、コンピュータに上記に開示された方法を行わせる、コンピュータ実行可能なコード又はコンピュータ実行可能な命令を備えるコンピュータプログラム製品を備える。コンピュータコードは、スクリプト、インタープリタ、ダイナミックリンクライブラリ、ジャバクラス、完全実行可能（complete executable）コード等を含む、但しこれらに限定されない、任意の解釈されたコード又は実行可能なコードであってよい。
【０１６６】
前記から、当業者には、様々な方法、システム、記録媒体上のコンピュータプログラム等が提供されることが明白であろう。
【０１６７】
例えば、図３に基づいて、少なくともランダムアクセスチャネルと予約指向チャネルとを介してノードと通信する複数の端末を含む符号分割多元接続（ＣＤＭＡ）の通信システムにおいて、ランダムアクセスチャネル及び予約指向チャネルのトラヒックを管理する方法が提供される。上記方法は、所定の端末からデータが通信されるトラヒックの特徴を、少なくとも一つの基準と比較することを含む。トラヒックの特徴が少なくとも１つの基準を満たす場合、方法は、帯域幅予約要求を送信し、当該帯域幅予約要求を処理及び許可し、帯域幅予約要求の許可を所定の端末に通信し、所定の端末に予約指向チャネルでデータを送信させることを含む。トラヒックの特徴が、少なくとも１つの基準を満たさない場合、方法は、所定の端末にランダムアクセスチャネルでデータを送信させることを備える。
【０１６８】
ランダムアクセスチャネルは、予めスケジュールされていないときに、端末に対して、ランダムアクセスチャネルでデータを通信することを許可するように構成されてもよく、また、予約指向チャネルは、ランダムアクセスチャネルよりも全体的に高いデータレート（overall data rate）でデータを通信してもよい。
【０１６９】
複数の端末は、複数の加入者宅内機器（ＣＰＥｓ）であってもよく、ノードは、複数のＣＰＥｓを衛星通信ネットワークを介してインターネットにリンクするゲートウェイであってもよい。
【０１７０】
所定の端末は、帯域幅予約要求を送信してもよく、ノードは、帯域幅予約要求を処理及び許可してもよく、帯域幅予約要求の許可は、ノードから所定の端末へ通信される。
【０１７１】
ランダムアクセスチャネルは、非同期符号分割多元接続（ＡＣＤＭＡ）に基づいてデータを送信してもよく、また、予約指向チャネルは直交符号分割多元接続（ＯＣＤＭＡ）に基づいてデータを送信してもよい。
【０１７２】
少なくとも１つの基準は、閾値パケットサイズ（threshold packet size）を含んでもよく、比較するステップは、閾値パケットサイズを、所定の端末からデータが通信されるべきパケットを特徴付けるパケットサイズと比較することを備え得る。
【０１７３】
少なくとも１つの基準は、閾値データレート（threshold data rate）を含んでもよく、比較するステップは、閾値データレートを、前記所定の端末からデータが通信されるべきパケットを特徴付ける、ある期間にわたって（over a time interval）計算された平均データレートと比較することを備え得る。
【０１７４】
少なくとも１つの基準は、パケットタイプの表示（indication）を含んでもよく、比較するステップは、パケットタイプの表示を、所定の端末からデータが通信されるべきパケットを特徴付けるパケットタイプと比較することを備え得る。
【０１７５】
別の例として、図４に基づき、少なくともランダムアクセスチャネルと予約指向チャネルとを介してノードと通信する複数の端末を含む符号分割多元接続（ＣＤＭＡ）の通信システムにおいて、ランダムアクセスチャネル及び予約指向チャネルのトラヒックを管理する方法が提供される。上記方法は、ａ）１つの調査結果（examination result）に達するように、所定の端末からデータが通信されるトラヒックの特徴を、少なくとも１つの基準と比較し、
ｂ）前記調査結果に基づいて、所定の端末がビジー状態にあるかどうかを判定することを備える。所定の端末はビジー状態にあると判定される場合、方法は、予約指向サブチャネルを指定する符号を所定の端末に割当て、所定の端末に、予約指向サブチャネルでデータを送信させることを備える。しかし、所定の端末はビジー状態にはないと判定される場合、方法は、所定の端末に前記ランダムアクセスチャネルでデータを送信させることを備える。
【０１７６】
符号を割当てるステップは、所定の端末にウォルシュ符号を割当てることを備え得る。
【０１７７】
ランダムアクセスチャネルは、予めスケジュールされていないときに、端末に対して、ランダムアクセスチャネルでデータを通信することを許可するように構成されてもよく、また、予約指向チャネルは、ランダムアクセスチャネルよりも全体的に高いデータレートでデータを通信してもよい。
【０１７８】
複数の端末は、複数の加入者宅内機器（ＣＰＥｓ）であってもよく、ノードは、複数のＣＰＥｓを衛星通信ネットワークを介してインターネットにリンクするゲートウェイであってもよい。
【０１７９】
ランダムアクセスチャネルは、非同期符号分割多元接続（ＡＣＤＭＡ）に基づいてデータを送信してもよく、また、予約指向チャネルは、直交符号分割多元接続（ＯＣＤＭＡ）に基づいてデータを送信してもよい。
【０１８０】
少なくとも１つの基準は、閾値パケットサイズを含んでもよく、比較するステップは、閾値パケットサイズを、所定の端末からデータが通信されるべきパケットを特徴付けるパケットサイズと比較することを備え得る。
【０１８１】
少なくとも１つの基準は、閾値データレートを含んでもよく、比較するステップは、閾値データレートを、前記所定の端末からデータが通信されるべきパケットを特徴付ける、ある期間にわたって（over a time interval）計算された平均データレートと比較することを備え得る。
【０１８２】
少なくとも１つの基準は、パケットタイプの表示（indication）を含んでもよく、比較するステップは、パケットタイプの表示を、所定の端末からデータが通信されるべきパケットを特徴付けるパケットタイプと比較することを備え得る。
【０１８３】
別の例として、図５Ａに基づき、少なくともランダムアクセスチャネルと予約指向チャネルとを介してノードと通信する複数の端末を含む符号分割多元接続（ＣＤＭＡ）の通信システムにおいて、ランダムアクセスチャネル及び予約指向チャネルのトラヒックを管理する方法が提供される。上記方法は、所定の端末の出力バッファのローディングがＱ状態に達する程度（degree）を調査し、閾値を所定の端末のＱ状態と比較することを備える。Ｑ状態が閾値よりも大きい場合、方法は、予約指向サブチャネルを指定する符号を所定の端末に割当て、所定の端末に、予約指向サブチャネルでデータを送信させることを備える。しかし、Ｑ状態が閾値未満である場合、方法は、所定の端末にランダムアクセスチャネルでデータを送信させることを備える。
【０１８４】
方法は更に、Ｑ状態をランダムアクセスチャネルで通信することを備えてもよい。
【０１８５】
ランダムアクセスチャネルは、予めスケジュールされていないときに、端末に対して、ランダムアクセスチャネルでデータを通信することを許可するように構成されてもよく、予約指向チャネルは、ランダムアクセスチャネルよりも全体的に高いデータレートでデータを通信してもよい。
【０１８６】
複数の端末は、複数の加入者宅内機器（ＣＰＥｓ）であってもよく、ノードは、複数のＣＰＥｓを衛星通信ネットワークを介してインターネットにリンクするゲートウェイであってもよい。
【０１８７】
ランダムアクセスチャネルは、非同期符号分割多元接続（ＡＣＤＭＡ）に基づいてデータを送信してもよく、また、予約指向チャネルは、直交符号分割多元接続（ＯＣＤＭＡ）に基づいてデータを送信してもよい。
【０１８８】
図５Ｂに基づき、方法は更に、所定の端末に、予約指向サブチャネルでデータを送信させる後、所定の端末の少なくとも１つのＱ状態の履歴を分析して、Ｑ状態履歴分析を取得し（arrive at）、Ｑ状態履歴分析に少なくとも一部は基づいて、ｉ）現在のデータレートよりも高いデータレートで動作する、より速い予約指向サブチャネルを指定する第１の符号を前記所定の端末に割当て、ｉｉ）現在のデータレートと同一のデータレートで動作する、同一速度の予約指向サブチャネルを指定する第２の符号を所定の端末に割当て、ｉｉｉ）現在のデータレートよりも低いデータレートで動作する、より遅い予約指向サブチャネルを指定する第３の符号を所定の端末に割当て、ｉｖ）任意の予約指向サブチャネルを指定する任意の符号を、所定の端末から取り消すことを備える組から１つのステップを選択及び実行することを備え得る。
【０１８９】
第１、第２、及び第３の符号は、それぞれ漸次遅くなる（progressively lower）データレートで動作する、それぞれの予約指向サブチャネルを指定する漸次長くなる（progressively longer）ウォルシュ符号であってもよい。
【０１９０】
方法は更に、Ｑ状態を予約指向サブチャネルで通信することを備え得る。
【０１９１】
ランダムアクセスチャネルは、予めスケジュールされていないときに、端末に対して、ランダムアクセスチャネルでデータを通信することを許可するように構成されてもよく、予約指向チャネルは、ランダムアクセスチャネルよりも全体的に高いデータレートでデータを通信してもよい。
【０１９２】
複数の端末は、複数の加入者宅内機器（ＣＰＥｓ）であってもよく、ノードは、複数のＣＰＥｓを衛星通信ネットワークを介してインターネットにリンクするゲートウェイであってもよい。
【０１９３】
ランダムアクセスチャネルは、非同期符号分割多元接続（ＡＣＤＭＡ）に基づいてデータを送信してもよく、また、予約指向チャネルは、直交符号分割多元接続（ＯＣＤＭＡ）に基づいてデータを送信してもよい。
【０１９４】
更なる例として、図６に基づき、少なくともランダムアクセスチャネルと予約指向チャネルとを介してノードと通信する複数の端末を含む符号分割多元接続（ＣＤＭＡ）の通信システムにおいて、ランダムアクセスチャネル及び予約指向チャネルのトラヒックを管理する方法が提供される。上記方法は、所定の端末の出力バッファのローディングが、Ｑ状態に達する程度を調査し、所定の端末はビジー状態にあるかどうかを、Ｑ状態に少なくとも一部は基づいて判定することを備える。所定の端末はビジー状態にあると判定される場合、方法は、予約指向サブチャネルを指定する符号を所定の端末に割当て、所定の端末に、予約指向サブチャネルでデータを送信させることを備える。しかし、所定の端末はビジー状態にはないと判定される場合、所定の端末に、ランダムアクセスチャネルでデータを送信させる。
【０１９５】
符号は、予約指向サブチャネルを指定するウォルシュ符号であってもよい。
【０１９６】
ランダムアクセスチャネルは、予めスケジュールされていないときに、端末に対して、ランダムアクセスチャネルでデータを通信することを許可するように構成されてもよく、予約指向チャネルは、ランダムアクセスチャネルよりも全体的に高いデータレートでデータを通信してもよい。
【０１９７】
複数の端末は、複数の加入者宅内機器（ＣＰＥｓ）であってもよく、ノードは、複数のＣＰＥｓを衛星通信ネットワークを介してインターネットにリンクするゲートウェイであってもよい。
【０１９８】
ランダムアクセスチャネルは、非同期符号分割多元接続（ＡＣＤＭＡ）に基づいてデータを送信してもよく、また、予約指向チャネルは、直交符号分割多元接続（ＯＣＤＭＡ）に基づいてデータを送信してもよい。
【０１９９】
少なくとも１つのデータ処理装置を有するコンピュータシステムでの実行のためのプログラム命令を記憶する複数のコンピュータプログラム製品が提供され、その命令は、当該コンピュータシステムによって実行されるときに、当該コンピュータシステムに上述した複数の方法を実行させる。
【０２００】
上述した複数の方法を実行するように構成された、複数のコンピュータシステムが提供される。
【０２０１】
前述の実施形態は例にすぎず、本発明を限定するものとして解釈されるべきではない。本教示は、他のタイプの装置に容易に適用することができる。実施形態の記載は、例証となることを意図されており、特許請求の範囲を限定することを意図されてはいない。多くの選択肢、変更、及びバリエーションが、当業者には明白であろう。
【０２０２】
上記の教示に照らせば、本発明の多数の変更や変形が可能である。例えば、トラヒック管理機能ソフトウェア、端末、及びノード又はゲートウェイの特定の実施は、本発明の範囲を逸脱することなく変更されてもよい。勿論、本発明の特定のハードウェア又はソフトウェアの実施は、本発明の範囲内において変更され得る。従って、添付の特許請求の範囲及びその均等物の範囲内で、本発明が、本明細書に具体的に記載されたのとは別な方法で実施され得ることが理解されるべきである。
【図面の簡単な説明】
【０２０３】
【図１】図１は、衛星通信ネットワークを含む通信ネットワークのリターンリンク（ＲＬ）が、管理されなければならないトラヒックを有する、トラヒック管理方法の可能なコンテキストを概略的に示す。
【図２】図２は、端末がランダムアクセスチャネルでのみ送信する、トラヒック管理方法の第１の実施形態のフローチャートを示す。
【図３】図３は、帯域幅予約要求を提出し、許可された後、端末がデータを予約指向チャネルで送信し得る、トラヒック管理方法の第２の実施形態のフローチャートを示し、（ある期間の平均データレート又はパケットサイズといった）トラヒックの統計値が閾値を超える場合、又は、（パケットタイプといった）トラヒックコンテンツが一定の基準を満たす場合、当該帯域幅予約要求は許可される。
【図４】図４は、端末の通信トラヒックの統計値又はコンテンツがモニタされ、モニタされたトラヒックは、端末が「ビジーである（busy）」（ユーザによって積極的に使用されている）ことを示すとみなされるとき、端末が予約指向チャネルの「常にオン」のサブチャネルで送信することが許可される、トラヒック管理方法の第３の実施形態のフローチャートを示す。
【図５Ａ】図５Ａは、端末の「Ｑ状態（"Q-state"）」（端末の出力バッファがロードされる量）をモニタして、そのトラヒックがランダムアクセスチャネルによって伝送されるべきか、又は予約指向チャネルによって伝送されるべきかを判定し、トラヒックが予約指向チャネル（図５Ｂ）によって伝送されるべき場合、端末がその後はより遅い（又は、より速い、若しくは同一速度の）チャネルで送信するように、より長い（又は、より短い、若しくは同一の長さの）ウォルシュ符号が端末に割当てられるかを判定する、トラヒック管理方法の第４の実施形態のフローチャートを示す。
【図５Ｂ】図５Ｂは、端末の「Ｑ状態（"Q-state"）」（端末の出力バッファがロードされる量）をモニタして、そのトラヒックがランダムアクセスチャネルによって伝送されるべきか、又は予約指向チャネルによって伝送されるべきかを判定し、トラヒックが予約指向チャネル（図５Ｂ）によって伝送されるべき場合、端末がその後はより遅い（又は、より速い、若しくは同一速度の）チャネルで送信するように、より長い（又は、より短い、若しくは同一の長さの）ウォルシュ符号が端末に割当てられるかを判定する、トラヒック管理方法の第４の実施形態のフローチャートを示す。
【図６】図６は、端末の「Ｑ状態」（端末の出力バッファがロードされる量）の履歴がモニタされて、予約指向チャネルの「常にオン」のサブチャネルで送信することの端末の許可を認めるか、又は取り消すかを判定する、トラヒック管理方法の第５の実施形態のフローチャートを示す。
【図１】
2010093826.tif 000009
【図２】
2010093826.tif 000010
【図３】
2010093826.tif 000011
【図４】
2010093826.tif 000012
【図５Ａ】
2010093826.tif 000013
【図５Ｂ】
2010093826.tif 000014
【図６】
2010093826.tif 000015
【手続補正書】
【提出日】平成21年12月4日(2009.12.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
少なくともランダムアクセスチャネルと予約指向チャネルとを介してノードと通信する複数の端末を含む符号分割多元接続（ＣＤＭＡ）の通信システムにおいて、前記ランダムアクセスチャネル及び予約指向チャネルのトラヒックを管理する方法であって、
ａ）所定の端末の出力バッファのローディングがＱ状態に達する程度を調査し、
ｂ）閾値を前記所定の端末の前記Ｑ状態と比較し、
ｃ１）前記Ｑ状態が前記閾値よりも大きい場合、
（１）予約指向サブチャネルを指定する符号を前記所定の端末に割当て、
（２）前記所定の端末に、直交符号分割多元接続（ＯＣＤＭＡ）に基づいて前記予約指向サブチャネルでデータを送信させ、
ｃ２）前記Ｑ状態が前記閾値未満である場合、前記所定の端末に非同期符号分割多元接続（ＡＣＤＭＡ）に基づいて前記ランダムアクセスチャネルでデータを送信させる、方法。
【請求項２】
前記Ｑ状態を前記ランダムアクセスチャネルで通信する
ことを更に備える、請求項１記載の方法。
【請求項３】
前記ランダムアクセスチャネルは、予めスケジュールされていないときに、前記端末に対して、前記ランダムアクセスチャネルでデータを通信することを許可するように構成され、
前記予約指向チャネルは、前記ランダムアクセスチャネルよりも全体的に高いデータレートでデータを通信する、
請求項１記載の方法。
【請求項４】
前記端末は、加入者宅内機器（ＣＰＥｓ）であり、
前記ノードは、複数の加入者宅内機器（ＣＰＥｓ）を衛星通信ネットワークを介してインターネットにリンクするゲートウェイである、
請求項１記載の方法。
【請求項５】
（２）前記所定の端末に、前記予約指向サブチャネルでデータを送信させた後、
（３）前記所定の端末の少なくとも１つのＱ状態の履歴を分析して、Ｑ状態履歴分析を取得し、
（４）前記Ｑ状態履歴分析に少なくとも部分的に基づいて、
ｉ）現在のデータレートよりも高いデータレートで動作する、より速い予約指向サブチャネルを指定する第１の符号を前記所定の端末に割当てることと、
ｉｉ）前記現在のデータレートと同一のデータレートで動作する、同一速度の予約指向サブチャネルを指定する第２の符号を前記所定の端末に割当てることと、
ｉｉｉ）前記現在のデータレートよりも低いデータレートで動作する、より遅い予約指向サブチャネルを指定する第３の符号を前記所定の端末に割当てることと、
ｉｖ）任意の予約指向サブチャネルを指定する任意の符号を、前記所定の端末から取り消すことと、
を含む組から１つのステップを選択して実行する
ことを更に備える、請求項１記載の方法。
【請求項６】
前記第１、第２、及び第３の符号は、それぞれ漸次遅くなるデータレートで動作する、それぞれの予約指向サブチャネルを指定する漸次長くなるウォルシュ符号である、
請求項５記載の方法。
【請求項７】
前記Ｑ状態を予約指向サブチャネルで通信する
ことを更に備える、請求項５記載の方法。
【請求項８】
前記ランダムアクセスチャネルは、予めスケジュールされていないときに、前記端末に対して、前記ランダムアクセスチャネルでデータを通信することを許可するように構成され、
前記予約指向チャネルは、前記ランダムアクセスチャネルよりも全体的に高いデータレートでデータを通信する、
請求項５記載の方法。
【請求項９】
前記端末は、加入者宅内機器（ＣＰＥｓ）であり、
前記ノードは、複数の加入者宅内機器（ＣＰＥｓ）を衛星通信ネットワークを介してインターネットにリンクするゲートウェイである、
請求項５記載の方法。
【請求項１０】
少なくともランダムアクセスチャネルと予約指向チャネルとを介してノードと通信する複数の端末を含む符号分割多元接続（ＣＤＭＡ）の通信システムにおいて、前記ランダムアクセスチャネル及び予約指向チャネルのトラヒックを管理する方法であって、
ａ）所定の端末の出力バッファのローディングが、Ｑ状態に達する程度を調査し、
ｂ）前記所定の端末はビジー状態にあるかどうかを、前記Ｑ状態に少なくとも部分的に基づいて判定し、
ｃ１）前記所定の端末はビジー状態にあると判定された場合、
１）予約指向サブチャネルを指定する符号を前記所定の端末に割当て、
２）前記所定の端末に、直交符号分割多元接続（ＯＣＤＭＡ）に基づいて前記予約指向サブチャネルでデータを送信させ、又は、
ｃ２）前記所定の端末はビジー状態にはないと判定された場合、前記所定の端末に、非同期符号分割多元接続（ＡＣＤＭＡ）に基づいて前記ランダムアクセスチャネルでデータを送信させる
ことを備える、方法。
【請求項１１】
前記符号は、前記予約指向サブチャネルを指定するウォルシュ符号である、
請求項１０記載の方法。
【請求項１２】
前記ランダムアクセスチャネルは、予めスケジュールされていないときに、前記端末に対して、前記ランダムアクセスチャネルでデータを通信することを許可するように構成され、
前記予約指向チャネルは、前記ランダムアクセスチャネルよりも全体的に高いデータレートでデータを通信する、
請求項１０記載の方法。
【請求項１３】
前記端末は、加入者宅内機器（ＣＰＥｓ）であり、
前記ノードは、複数の加入者宅内機器（ＣＰＥｓ）を衛星通信ネットワークを介してインターネットにリンクするゲートウェイである、
請求項１０記載の方法。
【請求項１４】
少なくとも１つのデータ処理装置を有するコンピュータシステムでの実行のためのプログラム命令を記憶するコンピュータプログラム製品であって、その命令は、当該コンピュータシステムによって実行された場合に、当該コンピュータシステムに請求項１の方法を実行させるコンピュータプログラム製品。
【請求項１５】
少なくとも１つのデータ処理装置を有するコンピュータシステムでの実行のためのプログラム命令を記憶するコンピュータプログラム製品であって、その命令は、当該コンピュータシステムによって実行された場合に、当該コンピュータシステムに請求項５の方法を実行させるコンピュータプログラム製品。
【請求項１６】
少なくとも１つのデータ処理装置を有するコンピュータシステムでの実行のためのプログラム命令を記憶するコンピュータプログラム製品であって、その命令は、当該コンピュータシステムによって実行された場合に、当該コンピュータシステムに請求項１０の方法を実行させるコンピュータプログラム製品。
【請求項１７】
請求項１記載の方法を実行するように構成された、コンピュータシステム。
【請求項１８】
請求項５記載の方法を実行するように構成された、コンピュータシステム。
【請求項１９】
請求項１０記載の方法を実行するように構成された、コンピュータシステム。
【外国語明細書】
2010093826000001.pdf