(57)【要約】複数のアプリケーションをサポートするように構成された無線通信システムを寸法合わせする方法である。本方法は、各アプリケーションに対して、このアプリケーションを用いるこの無線通信システムの加入者のパーセンテージを推定するステップを含む。次に、加入者プロフィールが、このアプリケーションに対して、このアプリケーションを使用する加入者の推定されたパーセンテージに少なくとも部分的に基づいて決定される。次に、このアプリケーションの場合の１加入者当たりの最繁時トラフィックの比率が、このアプリケーションの加入者プロフィールに少なくとも部分的に基づいて決定される。
2004511140.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションをサポートするように構成された無線通信システムを次元合わせする方法において、該方法は、
各アプリケーション毎に、前記アプリケーションを使用する前記無線通信システムのパーセンテージを推定するステップと、
各アプリケーション毎に、前記アプリケーションを使用する加入者の前記推定パーセンテージに少なくとも部分的に基づいて前記アプリケーションの加入者プロフィールを決定するステップと、
各アプリケーション毎に、前記アプリケーションの前記加入者プロフィールに少なくとも部分的に基づいて前記アプリケーションの１加入者当たりの最繁時トラフィック比率を決定するステップと、
を含む、前記方法。
【請求項２】
前記無線通信システムの場合に対して、各アプリケーション毎に決定された１加入者当たりの前記最繁時トラフィック比率から１加入者当たりの合計最繁時トラフィック比率を決定するステップと、
前記無線通信システムの場合に対して、合計トラフィック容量を推定するステップと、
前記無線通信システムの場合に対して、前記推定された合計トラフィック容量を１加入者当たりの前記決定された合計最繁時トラフィック比率で除算することによって、前記無線通信システムがサポートする加入者の数を決定するステップと、
をさらに含む、請求項１に記載の方法。
【請求項３】
１加入者当たりの前記合計最繁時トラフィック比率を、前記無線通信システムの順方向リンクと逆方向リンクとの双方の場合に対して決定する、請求項２に記載の方法。
【請求項４】
各アプリケーション毎に、スケジューラ効率係数を推定するステップと、
各アプリケーション毎に、１加入者当たりの前記最繁時トラフィック比率を、前記推定されたスケジューラ効率係数に少なくとも部分的に基づいて正規化して、要求される生データビットを決定するステップと、
をさらに含む、請求項２に記載の方法。
【請求項５】
前記無線通信システムで１加入者当たりの前記合計最繁時トラフィック比率を決定する前記ステップは、各アプリケーション毎に、前記必要とされる生データビットを合計するステップを含む、請求項４に記載の方法。
【請求項６】
各アプリケーション毎に１加入者当たりの前記最繁時トラフィック比率を正規化する前記ステップは、さらに、エアーインタフェースオーバーヘッドと、ＭＡＣ層フレーミングオーバーヘッドと、ＲＬＰ再送信オーバーヘッドと、の内の少なくとも１つに基づいて実行される、請求項５に記載の方法。
【請求項７】
１加入者当たりの前記最繁時トラフィック比率と、必要とされる生データビットと、１加入者当たりの前記合計最繁時トラフィック比率と、の各々が、１加入者当たりかつ１時間当たりのキロバイト単位で測定され、また、前記合計トラフィック容量が、１時間当たりのキロバイト単位で測定される、請求項５に記載の方法。
【請求項８】
所与のアプリケーションを用いる前記無線通信システムの加入者のパーセンテージを推定する前記ステップは、
第１のパーセンテージは、前記アプリケーションをサポートするベアラーサービスに加入する前記無線通信システムの加入者のパーセンテージである第１のパーセンテージを推定又は測定するステップと、
第２のパーセンテージは、前記それぞれのベアラーサービスに加入し、また、前記アプリケーションを実際の使用する加入者のパーセンテージである第２のパーセンテージを推定又は測定するステップと、
用途倍率を推定するステップと、
前記第１のパーセンテージと、前記第２のパーセンテージと、前記用途倍率と、を乗算するステップと、
を含む、請求項１に記載の方法。
【請求項９】
各アプリケーション毎に加入者プロフィールを決定する前記ステップは、
前記第２のパーセンテージに含まれる平均的加入者が１日当たりに関わり合うアプリケーションセッションの数を推定又は測定するステップと、
各アプリケーションセッションの平均持続時間を推定又は測定するステップと、
アプリケーションセッションの前記測定又は推定数と、各アプリケーションセッション毎の前記測定又は推定平均持続時間と、に基づいて最繁時係数を決定するステップと、
前記決定された最繁時係数に前記第２のパーセンテージを乗算して、前記アプリケーションの前記加入者プロフィールを決定するステップと、
を含む、請求項８に記載の方法。
【請求項１０】
所与のアプリケーションの場合の加入者プロフィールを決定する前記ステップは、前記無線通信システムの総加入者数にわたって前記決定された加入者プロフィールを平均化して、前記アプリケーションの場合の平均的加入者プロフィールを誘導するステップをさらに含む、請求項９に記載の方法。
【請求項１１】
所与のアプリケーションに対して１加入者当たりの前記最繁時トラフィック比率を決定する前記ステップは、
１アプリケーションセッション当たりのバイト数を推定又は測定するステップと、
１アプリケーションセッション当たりの前記推定又は測定されたバイト数に前記決定された加入者プロフィールを乗算するステップと、
を含む、請求項９に記載の方法。
【請求項１２】
前記複数のアプリケーションは、回線交換アプリケーションとパケットデータアプリケーションとの双方を含む、請求項１に記載の方法。
【請求項１３】
全てのパケットデータアプリケーションがトラフィックの対話クラスであると考慮され、全ての回線交換アプリケーションが対話トラフィッククラスであると考慮される、請求項１２に記載の方法。
【請求項１４】
前記無線通信システムの容量は、１セクター当たりで決定される、請求項１に記載の方法。
【請求項１５】
１つ以上のプロセッサに対して、複数のアプリケーションをサポートするように構成された無線通信システムを次元合わせするステップを実行させる１つ以上のシーケンスから成る命令を記憶しているコンピュータ読み取り可能媒体であって、前記ステップは、
各アプリケーション毎に、前記アプリケーションを使用する前記無線通信システムの加入者のパーセンテージを推定するステップと、
各アプリケーション毎に、前記アプリケーションを使用する加入者の前記推定されたパーセンテージに少なくとも部分的に基づいて前記アプリケーションの加入者プロフィールを決定するステップと、
各アプリケーション毎に、前記アプリケーションの前記加入者プロフィールに少なくとも部分的に基づいて前記アプリケーションの場合の１加入者当たりの最繁時トラフィック比率を決定するステップと、
を含む、前記コンピュータ読み取り可能媒体。
【請求項１６】
前記ステップは、
前記無線通信システムに対して、各アプリケーション毎に決定された１加入者当たりの前記最繁時トラフィック比率から１加入者当たりの合計最繁時トラフィック比率を決定するステップと、
前記無線通信システムに対して、合計トラフィック容量を推定するステップと、
前記無線通信システムに対して、前記推定された合計トラフィック容量を１加入者当たりの前記決定された合計最繁時トラフィック比率で除算することによって、前記無線通信システムがサポートする加入者の数を決定するステップと、
をさらに含む、請求項１５に記載のコンピュータ読み取り可能媒体。
【請求項１７】
前記ステップは、
各アプリケーション毎に、スケジューラ効率係数を推定するステップと、
各アプリケーション毎に、１加入者当たりの前記最繁時トラフィックを、前記推定されたスケジューラ効率係数に少なくとも部分的に基づいて正規化して、必要とされる生データビットを決定するステップと、
をさらに含む、請求項１６に記載のコンピュータ読み取り可能媒体。
【請求項１８】
前記無線通信システムに対して１加入者当たりの前記合計最繁時トラフィック比率を決定する前記ステップは、各アプリケーションに対して前記必要とされる生データビットを合計するステップを含む、請求項１７に記載のコンピュータ読み取り可能媒体。
【請求項１９】
複数のアプリケーションをサポートするように構成された無線通信システムを次元合わせするように構成されたシステムにおいて、該システムは、
プロセッサと、
データ記憶領域と、
実行領域と、
を備え、該実行領域は、
各アプリケーション毎に、前記アプリケーションを使用する前記無線通信システムの加入者のパーセンテージを推定するステップと、
各アプリケーション毎に、前記アプリケーションを使用する加入者の前記推定されたパーセンテージに少なくとも部分的に基づいて前記アプリケーションの場合の加入者プロフィールを決定するステップと、
各アプリケーション毎に、前記アプリケーションの場合の１加入者当たりの最繁時トラフィック比率を、前記アプリケーションの場合の前記加入者プロフィールに少なくとも部分的に基づいて決定するステップと、
から構成された前記システム。
【請求項２０】
前記実行領域は、さらに、
前記無線通信システムに対して、各アプリケーション毎に決定された１加入者当たりの前記最繁時トラフィック比率から１加入者当たりの合計最繁時トラフィック比率を決定するステップと、
前記無線通信システムに対して、合計トラフィック容量を推定するステップと、
前記無線通信システムに対して、前記推定された合計トラフィック容量を１加入者当たりの前記決定された合計最繁時トラフィック比率で除算することによって、前記無線通信システムがサポートする加入者の数を決定するステップと、
から構成されている、請求項１９に記載のシステム。
【請求項２１】
前記実行領域は、さらに、
各アプリケーション毎に、スケジューラ効率係数を推定するステップと、
各アプリケーション毎に、１加入者当たりの前記最繁時トラフィック比率を、前記推定されたスケジューラ効率係数に少なくとも部分的に基づいて正規化して、要求される生データビットを決定するステップと、
を含む、請求項２０に記載の方法。
【請求項２２】
前記無線通信システムに対して１加入者当たりの前記合計最繁時トラフィック比率を決定する前記ステップは、各アプリケーションに対して前記必要とされる生データビットを合計するステップを含む、請求項２１に記載のコンピュータ読み取り可能媒体。
【発明の詳細な説明】
【０００１】
（関連出願へのクロスリファレンス）
本出願は、その全てをここに組み込む、２０００年９月２８日に提出された米国仮出願第６０／２３６，９２７号に対する米国特許法§１１９の３５による優先権の利益を主張するものである。
【０００２】
（発明の背景）
（技術分野）
本発明は、一般的には無線通信に関し、より詳しくは、無線通信システムを寸法合わせするシステムと方法に関するものである。
【０００３】
（背景技術）
無線通信システムにおいては、無線システム技術者は、所与の区域内の所与の数のユーザをサポートするために必要とされる基地局の数を決定することが可能でなければならない。本明細書とそれに続くクレームの目的に沿って、このプロセスは、無線通信システムの次元合わせ（ｄｉｍｅｎｓｉｏｎｉｎｇ）と呼ばれる。純粋の回線交換システムにおいては、これは問題とはならないが、パケットデータを組み込むとなると、必要とされる基地局の数を決定するのが困難となる。それは、パケットデータの能力によって、Ｗｅｂアクセスや、ｅメールや、マルチメディアなどの加入者アプリケーションが複雑に混合されたりすることがあり得るからである。これらのアプリケーションによって、無線通信システムにおける容量に影響を与える変数の数が大いに増加する。例えば、新しい変数には、パケットのバースト性や、パケットサイズや、遅延制約や、遅延変動などが含まれる。不運にも、これらの変数を追跡するために用いられてきた従来のパケットデータ統計は、回線交換アプリケーションに影響を与える変数を追跡するために用いられる統計とは相関しない。
【０００４】
特に、音声中心システムの容量測定に従来用いられてきたアーランモデルは、パケットデータアプリケーションには適用不可能である。極めて単純にいえば、アーランモデルは、１秒当たりの入り呼の平均数と、数秒にわたる呼の平均長と、呼を取り上げるために利用可能なラインの数と、を用いるものである。これら３つの変数が周知であれば、アーランの公式を適用して、どのラインの利用できない入り呼のパーセンテージ、すなわち、遮断されるか遅延される呼のパーセンテージを決定することが可能である。
【０００５】
アーランの式は次の形態を取る：
【数１】
2004511140.tif 000003
ここで：ｔ＝入り呼の数；
ｃ＝ラインの数である。
【０００６】
トラフィック（ｔ）は、しばしば、無次元単位「アーラン」で表される。アーラン単位のトラフィックとは、遮断されなかったとしたら占有されるであろうとライン、すなわち、回線の期待値を示す数値である。それは、単位時間当たりの期待される呼の総数、すなわち毎秒当たりの入り呼の平均数に１呼当たりの平均長を乗算することによって分かる。式（１）の左辺は、遮断された呼の割合である。したがって、（ｔ）と（ｃ）が周知であれば、遮断された呼の数を決定することが可能である。
【０００７】
実際には、近代的なシステムでは、式（１）で与えられるより遙かに複雑なモデルが必要とされるが、基本的な原理はそれでも同じである。したがって、無線システムの技術者は、いくつの基地局が必要であるか、また、それらをどこに配置するかを計画する際に、トラフィック（ｔ）と、利用可能な回線の数（ｃ）と、受け入れ可能と考えられる遮断された呼の数と、に目をやる。このようなシステムは複雑であるため、トラフィック（ｔ）は、無線リソース管理スキームやユーザの移動性が呼当たりのトラフィック量に与える影響などの問題を解析する複雑なトラフィックモデルに基づいて決定される。遮断された呼の数は、サービスの等級（ＧＯＳ）と呼ばれる。ＧＯＳを指定し、トラフィック（ｔ）を適切なトラフィックモデルに従って決定することによって、無線システムの技術者は、必要とされる回線の数（ｃ）を決定することが可能である。ＧＯＳは、一般的には、任意の２４時間という期間で、その間に最大の合計トラフィック負荷が発生する６０分という期間である最繁時に適用される。しかしながら、パケットデータアプリケーションでは、ＧＯＳを用いない。その替わりに、パケットデータアプリケーションは、ビットエラー率（ＢＥＲ）で測定されたサービス品質（ＱＯＳ）を用いることを特徴とする。したがって、パケットデータアプリケーションでは、遮断された呼の数に照らし合わせたビットエラーの数に注目する。従来のモデルでは、回線交換アプリケーションにおけるＧＯＳ要件をパケットデータアプリケーションにおけるＱＯＳ要件と同等化する方法は提供されない。
【０００８】
（発明の開示）
本発明のある態様に依れば、回線交換アプリケーションとパケットデータアプリケーションの双方をサポートする無線通信システムを寸法合わせするシステムと方法が、ＧＯＳの要件とＱＯＳの要件を同等化する仕方として提供される。この態様の１つの特徴は、技術者が、この無線通信システムの所与のサービス区域における所与の数のユーザをサポートするに必要とされる基地局の最適数を決定したほうが良いという点である。
【０００９】
１つの実施形態では、各アプリケーション毎にこのアプリケーションを用いる後出の無線通信システムの加入者のパーセンテージが推定される複数のアプリケーションをサポートするように構成された無線通信システムの寸法合わせ方法が提供される。これで、本アプリケーションの場合の加入者のプロフィールが、本アプリケーションを用いる加入者の推定パーセンテージに少なくとも部分的に基づいて決定される。次に、１加入者比率当たりの最繁時トラフィックが、本アプリケーションの加入者プロフィールに少なくとも部分的に基づいて、アプリケーション毎に決定される。
【００１０】
本方法はさらに、無線通信システムの加入者当たりの合計最繁時トラフィックの比率を、各アプリケーションに対する加入者毎の最繁時トラフィックの比率に基づいて決定するステップを含んでいる。これで、無線通信システムの合計トラフィック容量が、推定される。すると、無線通信システムがサポートする加入者の数が、推定の合計トラフィック容量を加入者当たりの合計最繁時トラフィックの比率で除算することによって計算される。
【００１１】
本発明の他の態様、利点及び新規な特徴は、添付図面と一緒に記載された、以下の好ましい実施形態の詳細な説明を読めば明らかであろう。
【００１２】
（発明を実施するための最良の形態）
無線通信システム１００のアーキテクチャを、図１に示す。無線遠隔通信システムにおいては、カバレージエリアは、複数のセルに分割される。システム１００は、相互接続された３つのコンポーネント、すなわちサブシステムに分割されるが：その内訳は、モバイルデバイス１０２に例示される複数のモバイルデバイスと、基地局サブシステム（ＢＳＳ）１０４と、モバイルスイッチングセンター（ＭＳＣ）１１８と、である。一般に、モバイルデバイス１０２は、システム１００に対する加入者によって、搬送されるモバイル装置である。従来は、無線通信システム１００で用いられるモバイルデバイスは、セルラー電話などの音声中心のデバイスであった。しかしながら、最近では、ラップトップやＰＤＡなどのデータ中心のデバイスが、一般的に、モバイルアプリケーション用に設計されている。そのうえ、今日のセルラー電話でさえ、一般的にはデータアプリケーション用として構成されている。
【００１３】
ＢＢＳ１０４は、ＢＴＳ１０８に例示される複数の既知トランシーバ局（ＢＴＳ）と、基地局コントローラ（ＢＳＣ）１１０と、から成っている。ＢＴＳ１０８は、通常は、セルの中心にあって、アンテナ付きの１つ以上の送信機から成り立っている。セルとは、特定のＢＴＳ１０８のカバレージエリアのことである。低出力送信機は、１つのセル内で用いられる周波数が、干渉を防ぐために十分遠隔にあるセルでも使用可能であるように利用される。ＢＴＳ１０８は、無線リンクを確定して、モバイルデバイス１０２を用いてエアーインタフェース１１２を介して無線通信を処理する。各ＢＳＣ１１０は、複数のＢＴＳ１０８を管理する。これには、無線「チャネル」を割り当てて管理する動作と、モバイルデバイス１０２を用いてのあるＢＴＳ１０８から別のＢＴＳ１０８への通信の「ハンドオフ」を制御する動作を伴う。ＢＴＳ１０８とＢＳＣ１１０は、標準化された「Ａｂｉｓ」インタフェース１１４を介して通信し、ＢＳＣ１１０は、標準化されたインタフェース１１６を介してＭＳＣ１１８と通信する。例えば、インタフェース１１６は、標準化された基地局アプリケーションパーツ（ＢＳＡＰ）プロトコル又は標準化されたＳＳ７プロトコルが使用可能である。ＭＳＣ１１８は、モバイルデバイス１０２同士間の通信と、モバイルデバイス１０２と公衆網間の通信を管理する。公衆網の例では、ＭＳＣ１１８は、総合ディジタル通信網（ＩＳＤＮ）１２０と公衆交換電話網（ＰＳＴＮ）１２２とを含むことによりインターフェイスが可能となる。
【００１４】
システム１００は、しばしば、様々なデータサービスをサポートする。例えば、ＭＳＣ１１８は、モバイルデバイス１０２をＩＳＰ１３２を介してインターネットにインタフェースさせる。ＭＳＣ１１８は、ＰＳＴＮ１２０やＩＳＤＮ１２２を介してＩＳＰ１３０にインタフェースさせることが可能であるが、インターネットは、非リアルタイム通信であるパケットデータ通信を採用している。非リアルタイム通信は音声通信の場合には受け入れることができないため、システム１００は、回線交換キャリヤ１３４を用いて、モバイルデバイス１０２との間で通信をやり取りしている。したがって、インターネットに対してＭＳＣ１１８をインタフェースさせる場合には、パケットアセンブラ／ディスアセンブラ（ＰＡＤ）（図示せず）も含まれる。ＰＡＤは、モバイルデバイス１０２からの回線交換通信をパケットデータ通信に変換したりその逆をしたりする。
【００１５】
しかしながら、モバイルデータアプリケーションが普及するに連れて、モバイルデバイス１０２へのより速いデータサービスに対する必要性が発生してきた。インターネットのように、モバイルデータサービスは、非リアルタイムの通信を用いることが可能である。したがって、システム１００のように、無線通信システムは、一般的には、モバイルデバイス１０２とインターネットと間でのパケットデータ通信のためのパケットデータキャリヤ１３６を含んでいる。一般的には、モバイルパケットデータは、ＭＳＣ１１８によっては制御されない。その替わりに、パケットデータサービス網（ＰＤＳＮ）１３８が、パケットデータキャリヤ１３６を介してのモバイル１０２とインターネット間の通信を取り扱う。ＰＤＳＮ１３８は、パケットデータコア網１４０と、認可／認証／アカウント（Ａｕｔｈｏｒｉｚａｔｉｏｎ，Ａｕｔｈｅｎｔｉｃａｔｉｏｎ，ａｎｄ　Ａｃｃｏｕｎｔ）ノード（ＡＡＡ）１４２と、ホームエージェント１４４と、を含んでいる。パケットデータコア網１４０は、モバイルデバイス１０２とインターネットと間のトラフィックのルーティングを扱う。ホームエージェント１４４は、モバイルデバイスに対して、それがそのホーム網から遠隔にある場合にパケットを送信するモバイルデバイスのホームネットワーク上のルーターである。それはまた、移動性結合と呼ばれる登録されたモバイルデバイスの現行のロケーション情報を保持する。ＡＡＡ１４２は、サービスとモバイル１０２の認定とに関連する情報を記憶するサーバである。ＡＡＡサーバはまた、セキュリティパラメータを供給する。
【００１６】
回線交換のそれであろうとパケット交換のそれであろうと、様々なデータサービスには、それぞれ様々なＧＯＳ又はＱＯＳが必要である。今日のインターネットは、「ベストエフォート」と呼ばれてきたサービスを提供する。あるものがパケットを送信すると、その時点で他のトラフィックが提供されれば、ネットワークはそれ自身が提供し得るベストなものとして転送するが、送付のレートすなわちそのパケットが送付されるレートに関する具体的な保証は全くしない。多くのコンピュータアプリケーションは、帯域幅を保証しない状況で極めて自然に動作しており、ベストエフォートサービスは効果的であることが実証されている。ベストエフォートサービスは、利用可能な帯域幅を現行のユーザ間で分割する。アプリケーションを時として少し遅く実行しても、深刻なユーザの不満を常に引き起こすとは限らない。事実、遠隔ファイルアクセスなどのアプリケーションの場合、ベストエフォートサービスは非常に効果的であることが分かっている。もちろん、ベストエフォートサービスは、ある制限内でのみ許容されるものであり、全くふくそうしているネットワークは受け入れることはできない。
【００１７】
ベストエフォートサービスに対する代替物として、トラフィックソースに対して、そのサービス要件を宣言することを要求し、これによって、ネットワークがこのサービスを確保して保証することが可能であるか又は明示的にこの要求を拒否することが可能であるようにするものがある。過剰な帯域幅がある場合、ベストエフォートサービスと確保された帯域幅サービスとの双方が良く相乗作用して、ユーザが満足する。しかしながら、ふくそうがあると、ベストエフォートサービスの場合のように全てのユーザを幾分かでも遅速させるか又は１部のユーザを完全に拒否し、これによって、確保された帯域幅を他のユーザに対して完全に提供するかのどちらかが選択されることになる。リアルタイムオーディオやビデオなどの１部のアプリケーションの場合、確保されたサービスの方が好ましい。その結果、システム１００は、様々なベアラーサービスを介して様々なデータアプリケーションを提供することが可能である。ベアラーサービスのこの種の変動は、ＱＯＳによって記述され、これは、技術社会によって、遅延や、帯域幅や、シェアリング程度に対する保証の程度や、損失レートや、その他の管理をカバーするものであると理解される。
【００１８】
インターネットとモバイルデータパケットアプリケーションは、単一のベストエフォートサービスからＱＯＳの明示的オプションを持った、より複雑なモデルに移行しつつあり、これによって、ビデオやオーディオなどの新たなアプリケーションをサポートしようとしている。回線交換側では、様々なベアラーがＧＯＳによって指定される。例えば、ＣＤＭＡ２０００無線通信システムの１つのトラフィックモデルでは、回線交換音声アプリケーションに対して２つのベアラーサービスオプションを用いている。第１のサービスオプション、すなわちレートセット１は、９．６Ｋｂｐｓから１．２Ｋｂｐｓで動作する。第２のサービスオプション、すなわちレートセット２は、１４．４Ｋｂｐｓから１．２Ｋｂｐｓで動作する。ＣＤＭＡ２０００基格は、レートセット１（９．６ｋｂｐｓ）及びレートセット２（１４．４ｋｂｐｓ）における回線データサービスと、６４ｋｂｐｓにおける新しいサービスオプションとに対応している。この新しいサービスオプションを効果的に使用するには、エンドツーエンドでのＩＳＤＮサービスが必要である。パケットデータアプリケーションの場合、ＣＤＭＡ２０００Ｐｈａｓｅ　１が、１４４ｋｂｐｓという最大パケット交換サービスレートを可能としている。
【００１９】
加入者（エンドユーザ）とソースアプリケーションの視点からすれば、パケット交換データトラフィックパターンを良く特徴付けする４つの主要なクラス、すなわち、対話クラスと、背景クラスと、会話クラスと、ストリーミングクラスが確認されている。対話クラスの要件を満足するＱｏＳを維持するためには、エンドユーザの要件は、ペイロードコンテンツだけではなく要求−応答シーケンスを確保すべきであるということである。対話クラスもまた、非リアルタイムであるとも分類することが可能である。その良い例が、従来のＷｅｂアプリケーションやｅメールである。背景クラスでは、唯一のエンドユーザ要件は、ペイロードコンテンツを確保すべきであるということである。遅延又は遅延の変動は全く予期されていない。背景クラスもまた、非リアルタイムであると分類することが可能である。背景サービスは、ユーザがネットワークに接続された場合に、端末との間でやり取りされるデータを含むことがあり得るが、必ずしもアクティブとは限らない。その例として、株式市場情報や、スポーツニュースや、ｅメールや、ファックスなどがある。他の例としては、ＤＮＳトラフィックや、商業的にも社会的にも関連している他のモバイル情報サービスや、端末特性のソフトウエアダウンロードなどがある。これらのサービスは、低コストであり、しかも空いている帯域幅を使用すべきである。対話クラスにおけるトラフィックは、背景クラスのトラフィックよりスケジューリングの優先度が高く、したがって、背景アプリケーションは、送信リソースを対話アプリケーションがそれを必要としない場合にしか使用しない。ここで、対話クラスで定義されているメールトラフィックの１部もまた、背景クラスの１部であると考えることも可能である。対話クラスと背景クラスは、主として、Ｗｅｂアプリケーションや、ｅメールや、Ｔｅｌｎｅｔや、ＦＴＰや、ニュースのような従来インターネットアプリケーション用のクラスである。どちらのクラスでも、リソースは、動的に確保され、また、対話アプリケーションの応答性は、対話アプリケーションと背景アプリケーションを分離することによって確実なものとされる。
【００２０】
会話クラスでは、基本的なＱｏＳ特性は、ソース情報と情報ストリームの最終宛先間の時間関係（変動）に少ない双方向時間遅延を確保することである。このクラスは、最も時間遅延感知的であり、したがって、必要とあればペイロードコンテンツを犠牲にしても時間遅延を維持しなければならない。対話クラスもまた、リアルタイムと分類することが可能である。このクラス用にと意図されるアプリケーションは音声である。ストリーミングクラスでは、基本的ＱｏＳ特性は、ソース情報と情報ストリームの最終宛先間に時間関係を確保することである。ストリーミングクラストラフィックは、対話クラスのそれほど時間遅延感知的ではない（しかしながら、遅延変動に対しては感知的である）ため、会話クラスよりもエラーレートが良好である。ストリーミングクラスもまた、リアルタイムと分類することが可能である。このクラスの良い例は、Ｗｅｂサイトから得られるビデオ／オーディオのストリーミングである。会話クラスとストリーミングクラスは、音声やビデオのストリーミングのようにリアルタイムトラフィックフローを搬送するようになっている。他方、対話クラスと背景的クラスは、Ｗｅｂアプリケーションやｅメールなどの従来のインターネットアプリケーションを特徴としており、遠隔測定やＰＯＳ（Ｐｏｉｎｔ　ｏｆ　ｓａｌｅ）のような多くの一貫したアプリケーション用のものである。次に示す特徴は、リアルタイムアプリケーション関連のものである：１）１つのセッション（すなわち、「呼」）の持続時間、２）セッション毎に増減するバイト量、３）増減するパケットサイズ、４）１日当たりのセッション（すなわち、「呼」）の数、５）セッション（すなわち、「呼」）の日々の分布。
【００２１】
パケットデータと回線交換のアプリケーションを実現する無線通信システムの次元合わせにおける大きな挑戦は、音声、Ｗｅｂアクセス、ｅメール、マルチメディアなどの加入者アプリケーションの複雑な混合体におけるセクターの容量を決定することである。このようなシステムでは、パケットのバースト性、パケットサイズ、遅延制約、遅延変動などのセクター容量に影響する変数の数は、非常に大きい。ルックアップテーブルとスプレッドシートと伝搬モデルとを使用してマルチステッププロセスを用いるＤｉｍｅｎｓｉｏｎ　Ｔｏｏｌを用いて、このような問題点を克服することが可能である。このようなツールで用いられる方法を、以下に検討する。このツールを開発するに際して、呼モデル変数とデータのスループットに対するそのインパクトに対して、工学上の簡略化が実行される。アーラン数のような、容量を表現する従来の方式は、この場合、パケット交換アプリケーションにはあまり適用可能ではなく、したがって、トラフィックは、最繁時に（順方向リンクと逆方向リンクで）搬送されるビット数で表現され、容量は毎秒当たりのビット数で表現される。
【００２２】
図２は、このツールが用いるマルチステッププロセスを説明するフローチャートである。この明細書の最後にある表１に、マルチステッププロセスを仮説のシステムに適用して得られた１部のサンプル結果を示す。表１のカラムＡに、利用可能なベアラーのサービスとアプリケーションをリストアップする。ステップ２０２で、各アプリケーションに対する加入者の侵透度を決定しなければならず、この侵透度を用いて、所与の時間にいて特定のアプリケーションを用いている全加入者のパーセンテージがわかる。この決定をするために、所与のアプリケーションに関連するベアラーサービスに加入する全加入者のパーセントに実際のこのアプリケーションｍを使用している加入者のパーセントを乗算する。次に、その積に一般的な加入者が実際のアプリケーションを用いる時間のパーセントを近似する用途倍率を乗算する。この計算は、表１の第１のアプリケーションを用いて図示することが可能であるが、このアプリケーションは、パケットデータベアラーサービスを介する、画像を持ったＷｅｂアプリケーションである。カラムＢは、加入者の何パーセントが適用可能なベアラーサービス、この場合はパケットデータベアラーサービス、に加入するかを示す。カラムＣは、Ｗｅｂアプリケーションに加入する加入者のパーセンテージを示す。カラムＦは、これらの加入者がサービスを実際に使用している時間のパーセントを示す。したがって、ステップ２０２は、カラムＢとＣとＦとに格納されている値を乗算してカラムＨにその結果を格納するステップである。ここで考慮されているＷｅｂアプリケーションの場合の計算結果は：．８０ｘ．２０ｘ．５０＝．０８すなわち８％である。
【００２３】
次に、ステップ２０４で、平均的加入者プロフィールが決定される。この決定ステップでは、各アプリケーション（カラムＤ）毎に一般的な加入者が関与している１日当たりのアプリケーションセッションの数を推定し、この推定値に秒単位で表した各セッション毎の平均時間（カラムＥ）を乗算する。次に、この積を、１時間の秒数である３６００で除算して、最繁時係数（カラムＧ）を生成する。ステップ２０２の説明に用いたＷｅｂアプリケーションの分析を継続して、この計算の結果は：（３ｘ２５０）／３６００＝．２０すなわち２０％となる。次に、最繁時係数に、所与の時間に特定のアプリケーションを用いている加入者のパーセント、すなわち、カラムＨの値と、これらのユーザの各々のセッションの数、すなわち、カラムＤに格納されている値と、を乗算して、その結果がカラムＩに格納される。この計算結果は：．２０ｘ．０８ｘ３＝．０４８となる。
【００２４】
言い換えれば、カラムＩに格納されている結果は、無線通信システムにおける全加入者にわたって平均された加入者一人当たりの最繁時の呼／セッションを表している。この計算は各アプリケーション、すなわち、表１のカラムＡにリストアップされている各アプリケーション毎に実行される。次に、プロフィールを用いて、「生データビット」と表示される、各加入者毎の合計最繁時データビット要件を計算する。生データビットは、パケットデータアプリケーションと回線交換アプリケーションとの双方に対する共通の測定判断基準である。一旦、各アプリケーションに対する生データビットが決定されると、これらのビットは、純粋に数学的な仕方で加算することによって、このシステムにおける全てのアプリケーションにわたるユーザ毎のトラフィックを明瞭に記述することが可能である。各アプリケーション毎に生データビットを決定してこれを用いるプロセスと重要性を、以下の検討で明瞭に示す。
【００２５】
ステップ２０６で、平均最繁時トラフィックを、ユーザ一人当たり／１最繁時当たりの合計キロバイト数で計算する。しかしながら、最初に、アプリケーション毎の合計キロバイト数が、セッション毎のパケット呼の数（カラムＪ）に呼当たりのデータグラムの数（カラムＫとＬ）と１データグラム当たりのバイト数（カラムＭとＮ）を乗算することによって決定される。これは、順方向リンクと逆方向リンクの双方に対して実行される。２番目に、アプリケーション毎の合計キロバイト数に、ステップ２０４から得られた平均加入者プロフィールを乗算して、その結果をカラムＯとＰに格納する。ここで、回線交換アプリケーションの場合、呼当たりのデータグラムの数と、データグラム当たりのバイト数は適用されず；したがって、これらのカラムは、表１の回線交換アプリケーションでは空白となっている。この例の場合、１加入者当たりの平均最繁時トラフィックは：
【数２】
2004511140.tif 000004
【００２６】
ここで、表１中の実際の値は、ここで計算された値とは少し異なることがあるが、それは、様々な結果やサブ結果を丸める際に差があるからである。加えて、ステップ２０６で実行される計算もまた、様々なオーバーヘッドビットを生じる。例えば、無線通信システムがＣＤＭＡ２０００である場合、ステップ２０６は、ＣＤＭＡ２０００モデル中に含まれるオーバーヘッドビットを生じることがあり得る。
【００２７】
表１には、ＣＤＭＡ２０００システムのデータが含まれるので、カラムＯとＰに含まれる実際の値は、上記の計算によって予測される値とは異なっている。しかしながら、基本的には、カラムＯとＰの値は、上記の計算を通じて到達するものである。
【００２８】
システム１００のある実施形態では、様々なＱｏＳ要件を持つトラフィッククラスをサポートするマルチユーザスケジューラが実現されていない。その替わりに、これらの実施形態では、ベストエフォート原理に基づいた単一のユーザスケジューラを用いているが、この場合、５秒という遅延制約が一般的には、適度な限度であると考えられている。したがって、この実施形態では、全てのパケットデータアプリケーションが対話クラスのトラフィックであり、回線交換アプリケーション対話クラスであると見なしている。対話クラスは、主として、Ｗｅｂブラウジングなどのアプリケーションで用いられ、また、次のサービスセッション特性を有する：
（１）１つのセッションの持続時間
（２）セッション中の要求の数
（３）セッション毎のバイト量の増減
（４）パケットサイズの増減
（５）ファイルサイズの減少
（６）要求間時間
（７）１日当たりのセッションの数
（８）ユーザーアクセス（レート、ＱｏＳ）（例えば、最大レートを持ったベストエフォート）
（９）１日間でのセッションの分布
【００２９】
表１のカラムＤ、Ｇ、Ｊ、Ｋ、Ｌ、Ｍ、Ｎ内に格納されている値は、このような動作を記述するものである。したがって、今までのほとんど全てのデータは、現時点でＵＭＰＳデフォルト値を有する入力データである。カラムＯとＰは、１加入者当たりの最繁時トラフィックを決定する分析を開始するものである。これは、各アプリケーションに対して実行され、カラムＯとＰは、順方向リンクと逆方向リンクの場合の最繁時の１加入者当たりのキロバイト数を格納する。このトラフィックの合計は、実際には、各アプリケーション毎の最繁時に処理されたペイロードのことである。それは、システム内の全体母集団を考慮した、１加入者当たりの平均値である。これに続く分析によって、様々なオーバーヘッドをこのペイロードに付加し、双方向におけるエアーリンクに関する生データビットを決定することが試行される。
【００３０】
このようなオーバーヘッドの１つは、スケジューラの効率係数であり、これは、ステップ２０８で、パケットデータアプリケーションと回線交換アプリケーションとの双方に対して決定される。パケットデータアプリケーションの場合、様々なデータレートにおけるスケジューラ効率は、データのバースト性、すなわち、そのデューティサイクルと、パケットサイズなどの特性の係数である。ＩＳＯ−２０００−Ａ（ＣＤＭＡ２０００）システム内の順方向リンクスループットのシミュレーションが、その全部を参照してここに組み込み、また、次のスケジューラ効率の計算のための詳細の１部を提供するために用いられる、Ｖｉｅｒｉ　Ｖａｎｇｈｉ、ＩＳ−２０００Ａの順方向リンクスループット（Ｖａｎｇｈｉ）、ＥＷＵ／ＴＴ／Ｒ−００：００２中に提供されている。スケジューラ効率は、順方向リンクと逆方向リンクの場合でそれぞれカラムＳとＴに格納される。各ユーザ毎にこの効率の数字（カラムＳとＴ）と、カラムＯとＰ中のトラフィックと、を用いて、各アプリケーション毎の１００％というスケジューラ効率に対応する生データビットが決定される。１００％というスケジューラ効率は、理想的な数値であり、これは、遅延制約や遅延変動などのシステム中の制約がない場合だけ可能な値であることを心に留めておくこと。
【００３１】
表２に、パケットデータアプリケーションの場合のスケジューラ効率の例示計算を示す。表２のスケジューラ効率は、パケット呼モデルのアクティビティ係数やデューティサイクルと関連している。効率係数は、アクティビティ係数と線形に関連していると仮定する。さらに、一般的に、この方式は、いかなる呼モデルにも適用されるものと仮定され、また、仮定された５秒という遅延制約は、ベストエフォート実現例における最小性能限度であると考えられている。したがって、少なくとも２つのデータレートに付いてアクティビティが分かっていれば、線形方程式をそこから展開して、どのデータレートの場合でもスケジューラ効率を得ることが可能である。
2004511140.tif 000005
【００３２】
表２のスケジューラ効率の呼モデルは、Ｖａｎｇｈｉから得られており、それで、平均パケットサイズは４．１キロバイト、パケット到達間時間は１０秒、さらにセッション持続時間は１０パケットであり、最大遅延が５秒ということになる。ユーザのスケジューラ効率とチャネルアクティビティ係数との間の関係は線形的であると仮定されているので、線形式を上記のデータポイントに適用して、その関係式の勾配と切片を得ることが可能である。次式を用いて勾配を得る：
【数３】
2004511140.tif 000006
【００３３】
切片を得るには、（Ｎ−Ｎ１）＝Ｍｘ（Ａ−Ａ１）を適用するが、ここで、Ａ＝０と置換する；したがって、切片Ｃ＝Ｎ＝０．６８−０．２０２７（０．０８９）＝０．６６２となり、これで、アクティビティ係数Ａの場合のスケジューラ効率Ｎは次式で与えられる：
【数４】
2004511140.tif 000007
【００３４】
この公式は簡略化したものであり、次の論理によって正当化される：ユーザピークデータレートが一定のままで、アクティビティ係数が減少すると、スケジューラは、利用可能な帯域幅を全部利用するためにシステム内でより多くのユーザに対処しなければならない。より多くのユーザとは、直感的にいえば、スケジューラ効率が低下し、式（２）で与えられるモデルにおいては、チャネルアクティビティ係数が低下するに連れて、スケジューラ効率がまさに低下することを暗示する。同様の論理が、チャネルアクティビティ係数が高くなる逆の場合にも当てはまる。ユーザピークデータレートが増し、アクティビティ係数が一定値に維持されると、システム内のユーザの数を減少させて、１ユーザ当たりの平均データレートの増加に対処しなければならない。したがって、増加したデータレートが、スケジューラ効率が減少したことを信号通知したものであり得るが、一方、ユーザの数が減少したことは、その逆で、全般的にスケジューラ効率が同じままであることを暗示するものである。このケースでは、チャネルアクティビティ係数はスケジューラ効率を決定するであろう。このような条件下では、これらの値は双方共が、同じ値のままである。他方、ユーザデータレートが増加するとそれに伴ってアクティビティ係数が比例して減少すれば、スケジューラ効率も低下するが、これはまた、式（２）で与えられるモデルからも分かる。
【００３５】
したがって、表１のどの呼モデルに対しても式（２）を用いて、そのスケジュール効率を計算する。上記の例を継続すると、Ｗｅｂアプリケーションのスケジュール効率係数は、式Ｎ＝０．２０２７ｘＡ＋０．６６２を用いて決定することが可能であり、ここで、この計算が順方向チャネルの場合であるか又は逆方向チャネルの場合であるかによって、Ａを、カラムＯ又はＰに格納されている値をカラムＱまたはＲにそれぞれ格納されているデータレートで除算した値で置き換える。Ｗｅｂアプリケーションの場合、次のように計算される：
【数５】
2004511140.tif 000008
【００３６】
ステップ２０８で、回線交換アプリケーションは、少し異なった扱いを受ける。その目的は、パケットデータアプリケーションについて計算されたのと同じ生データビット数値を達成するように、回線交換アプリケーションを特徴付けすることである。これによって、両者を併合して回線交換とパケット交換との全体のトラフィックビットを得ることが可能となる。音声とファックスなどの他の回線交換アプリケーションとは、リアルタイムであり；したがって、これらは、厳密な遅延変動制約であるだけでなく厳密な遅延制約を有する。したがって、これらは、比較的低い効率係数を有することが明瞭である。サービス等級の従来の概念（すなわち、遮断確率）は、ここでは、非効率係数に変換されるが、これは、パケット交換アプリケーションにおけるスケジューラ効率係数に等しい。アーランＢのモデルとＧＯＳが２％であると考えれば、３６のトランクでは、アーラン容量はたったの２８アーランである。これは、実効的に、効率係数が約２８／３６＝７８％であることを意味する。
【００３７】
ここで、これは新しいトラフィック工学方式であり、パケットデータアプリケーションと回線交換アプリケーションとを１つの測定値に併合するために生成されたものである。アーランＢモデル効率係数は、音声アプリケーションでは、スケジューラ効率係数に等化されている。特定の信号の信号対雑音比を示すために用いられる尺度であるＥｂ／Ｉｏ要件は、音声の場合、パケットデータの場合より約１．３ｄＢだけ大きいので、スケジューラ効率の計算には、１０＾（−１．３／１０）＝７４％に対応する回線交換アプリケーションの場合の別の効率係数が含まれる。これら２つの係数の結果、平均利用効率は５８％となる。したがって、回線交換アプリケーションの場合のカラムＳとＴに格納されている値は、０．５８である。音声呼のアーラン効率を計算するには、コールアドミッション制御という視点から見た音声呼の場合に利用可能な全エアーリンク容量が考慮される。これは、音声呼がコールアドミッションではデータ呼より優先することを意味する。
【００３８】
このポイントに至るプロセスは、主として、エアーインタフェースに対するペイロードとして考慮されていたが、エアーインタフェースと物理的な層におけるフレーミングオーバーヘッドもまた、ステップ２１０で考慮される。簡潔さのためと後で整合が付くようにするために、回線交換音声のこれらの値は、音声アクティビティ係数にひとまとめにされてきた。カラムＵとＶには、順方向リンクと逆方向リンクにおける物理的な層におけるこのフレーミングオーバーヘッドが組み込まれている。データレートが増加するに連れてフレーミングオーバーヘッドが低下することに注意すると興味深い。これは、データレートが高くなると、より多くのビットが同じ２０ミリ秒のフレームに詰め込まれるが、ＣＲＣとテールビットは一定のままであるという事実のせいである。同様のオーバーヘッドが、ＲＬＰ再送信オーバーヘッドだけではなくＲＬＰ／ＭＵＸ−ＰＤＵ／ＬＴＵフレーム中のＭＡＣオーバーヘッドにも当てはまる。ＭＡＣ層のオーバーヘッドを、カラムＷとＸに示す。ＲＬＰ再送信オーバーヘッドをカラムＹとＺに示す。
【００３９】
ステップ２１２で、１加入者当たりの正規化された最繁時トラフィック（正規化されたトラフィック）が、決定される。したがって、この正規化されたトラフィックは、生データビットである。カラムＡＡとＡＢには、直前のステップから得られたオーバーヘッドのインパクトを考慮した正規化されたトラフィックが格納される。様々な回線交換アプリケーションとパケットデータアプリケーションとの生データビットが正規化され、これによって、これらがエアーインタフェース容量という点では同じとなるようにする。このようにして、これらを代数的な仕方で加算する。ステップ２１４では、１加入者当たりの全体の最繁時トラフィック（合計生データビット）が、各アプリケーション毎のカラムＡＡとＡＢとに格納されている値を単に加算するという仕方で計算される。次に、ステップ２１６で、１セクタ当たりの加入者数という点から見た合計セクタ容量が、１加入者当たりのトラフィックを合計セクタ容量で除算することによって決定される。
【００４０】
表３に、それぞれ音声スループットとパケットデータユーザの実効的スループットとパケットデータ生スループットとのセクタ容量を要約してある。表３は、Ｖａｎｇｈｉから誘導した情報に基づいているが、例えば、これらの値は、６０°アンテナ、ＮｏＷ＝−１０５ｄＢｍ、音声Ｅｂ／Ｉｏ＝６ｄＢ、パケットデータＥｂ／Ｉｏ＝４．７ｄＢという条件で決定されている。
2004511140.tif 000009
【００４１】
音声スループットの場合、効率係数は、次の２つの係数がすでに言及されているために非常に低い：第１に、回線交換の音声は、２％というＧＯＳに対してアーランＢ係数を有し、このため、非効率という結果をもたらす；第２に、データと比較して高いＥｂ／Ｉｏ要件は１．３ｄＢすなわち６５％という別の訂正をしている。表３のスループットを用いて、ステップ２１６でセクターの容量を計算する。都市環境と郊外環境の場合のセクター容量は、別々に計算される。したがって、セクター容量がＫｂｐｓ単位で与えられ、最繁時において１ユーザ当たりの生データビットが与えられていれば、セクター容量は、１つの周波数割当毎の１セクター当たりでサポートされるユーザの数で計算される。
【００４２】
これは簡単な方式であるが、回線交換アプリケーションからパケット交換アプリケーションへのパラダイムの変換を理解し、評価するには極めて助けとなる。本実施形態は、必要とされるＱｏＳ当たりの加入者トラフィッククラス、例えば、対話クラスと、背景クラスと、会話クラスと、ストリーミングクラスと、を実施せず、その替わりに、５秒という遅延制約で、ベストエフォート原理に基づいて動作する単一のスケジューラを用いる。しかしながら、ＱｏＳを保証してトラフィッククラスを将来的には変更できるようにされ、この結果、複数クラスのトラフィックが導入されれば効率が増すであろう。表１とモデルの基礎的な仮定とに用いられているいくつかの値は、その全体を参照してここに組み込むＣＤＭＡ２０００　１ｘＲＴＴ、ＥＷＵ／ＵＴ　１５５１−３／ＦＣＰ１０１０７４６の加入者トラフィックモデル、Ｇｅｏｒｇｅ　Ｂｅｒｔｉｎｉから引き出されたものである。
【００４３】
表１に実現されているモデルは、容易に、システム１００のような無線通信システムの容量を決定するツールで用いられるスプレッドシートに変換される。図示するように、この容量分析もまた、セクター毎に基づいて実行することが可能である。次に、この容量分析の結果を用いて、システムを次元合わせして、全ての加入者に対して適切な容量が利用可能となることを保証するようにする。
【００４４】
本発明の実施形態と実現例を示す説明したが、さらに多くの実施形態と実現例が本発明の範囲内で可能であることが明らかであろう。したがって、本発明は、クレーム及びその同等物による以外は制限されないものとする。
2004511140.tif 000010
2004511140.tif 000011
2004511140.tif 000012
【図面の簡単な説明】
本発明で教示する本発明の好ましい実施形態を、制限するためではなく、以下の添付図面に示す。
【図１】
例示の無線通信システムを示すブロック図である。
【図２】
図１に示すシステムなどの無線通信システムの容量を決定する方法を示すフローチャートである。
【図１】
2004511140.tif 000013
【図２】
2004511140.tif 000014
【国際公開パンフレット】
2004511140.tif 000015
2004511140.tif 000016
2004511140.tif 000017
2004511140.tif 000018
2004511140.tif 000019
2004511140.tif 000020
2004511140.tif 000021
2004511140.tif 000022
2004511140.tif 000023
2004511140.tif 000024
2004511140.tif 000025
2004511140.tif 000026
2004511140.tif 000027
2004511140.tif 000028
2004511140.tif 000029
2004511140.tif 000030
2004511140.tif 000031
2004511140.tif 000032
2004511140.tif 000033
2004511140.tif 000034
2004511140.tif 000035
2004511140.tif 000036
2004511140.tif 000037
2004511140.tif 000038
2004511140.tif 000039
2004511140.tif 000040
2004511140.tif 000041
2004511140.tif 000042
2004511140.tif 000043
2004511140.tif 000044
【国際公開パンフレット（コレクトバージョン）】
2004511140.tif 000045
2004511140.tif 000046
【手続補正書】
【提出日】平成15年2月7日(2003.2.7)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のアプリケーションをサポートするように構成された無線通信システムを次元合わせする方法において、該方法は、
各アプリケーション毎に、前記アプリケーションを使用する前記無線通信システムのパーセンテージを推定する（２０２）ステップと、
各アプリケーション毎に、前記アプリケーションを使用する加入者の前記推定パーセンテージに少なくとも部分的に基づいて前記アプリケーションの加入者プロフィールを決定する（２０４）ステップと、
各アプリケーション毎に、前記アプリケーションの前記加入者プロフィールに少なくとも部分的に基づいて前記アプリケーションの１加入者当たりの最繁時トラフィック比率を決定する（２０６）ステップと、
前記無線通信システムの場合に対して、各アプリケーション毎に決定された１加入者当たりの前記最繁時トラフィック比率から１加入者当たりの合計最繁時トラフィック比率を決定する（２０６）ステップと、
前記無線通信システムの場合に対して、合計トラフィック容量を推定するステップと、
前記無線通信システムの場合に対して、前記推定された合計トラフィック容量を１加入者当たりの前記決定された合計最繁時トラフィック比率で除算することによって、前記無線通信システムがサポートする加入者の数を決定するステップと、
を含む、前記方法。
【請求項２】
１加入者当たりの前記合計最繁時トラフィック比率を、前記無線通信システムの順方向リンクと逆方向リンクとの双方の場合に対して決定する、請求項１に記載の方法。
【請求項３】
各アプリケーション毎に、スケジューラ効率係数を推定する（２０８）ステップと、
各アプリケーション毎に、１加入者当たりの前記最繁時トラフィック比率を、前記推定されたスケジューラ効率係数に少なくとも部分的に基づいて正規化して、要求される生データビットを決定する（２１２）ステップと、
をさらに含む、請求項１に記載の方法。
【請求項４】
前記無線通信システムで１加入者当たりの前記合計最繁時トラフィック比率を決定する前記ステップは、各アプリケーション毎に、前記必要とされる生データビットを合計する（２１４）ステップを含む、請求項３に記載の方法。
【請求項５】
各アプリケーション毎に１加入者当たりの前記最繁時トラフィック比率を正規化する（２１２）前記ステップは、さらに、エアーインタフェースオーバーヘッドと、ＭＡＣ層フレーミングオーバーヘッドと、ＲＬＰ再送信オーバーヘッドと、の内の少なくとも１つに基づいて実行される、請求項４に記載の方法。
【請求項６】
１加入者当たりの前記最繁時トラフィック比率と、必要とされる生データビットと、１加入者当たりの前記合計最繁時トラフィック比率と、の各々が、１加入者当たりかつ１時間当たりのキロバイト単位で測定され、また、前記合計トラフィック容量が、１時間当たりのキロバイト単位で測定される、請求項４に記載の方法。
【請求項７】
所与のアプリケーションを用いる前記無線通信システムの加入者のパーセンテージを推定する（２０２）前記ステップは、
第１のパーセンテージは、前記アプリケーションをサポートするベアラーサービスに加入する前記無線通信システムの加入者のパーセンテージである第１のパーセンテージを推定又は測定するステップと、
第２のパーセンテージは、前記それぞれのベアラーサービスに加入し、また、前記アプリケーションを実際の使用する加入者のパーセンテージである第２のパーセンテージを推定又は測定するステップと、
用途倍率を推定するステップと、
前記第１のパーセンテージと、前記第２のパーセンテージと、前記用途倍率と、を乗算するステップと、
を含む、請求項１に記載の方法。
【請求項８】
各アプリケーション毎に加入者プロフィールを決定する前記ステップは、
前記第２のパーセンテージに含まれる平均的加入者が１日当たりに関わり合うアプリケーションセッションの数を推定又は測定するステップと、
各アプリケーションセッションの平均持続時間を推定又は測定するステップと、
アプリケーションセッションの前記測定又は推定数と、各アプリケーションセッション毎の前記測定又は推定平均持続時間と、に基づいて最繁時係数を決定するステップと、
前記決定された最繁時係数に前記第２のパーセンテージを乗算して、前記アプリケーションの前記加入者プロフィールを決定する（２０４）ステップと、
を含む、請求項７に記載の方法。
【請求項９】
所与のアプリケーションの場合の加入者プロフィールを決定する（２０４）前記ステップは、前記無線通信システムの総加入者数にわたって前記決定された加入者プロフィールを平均化して、前記アプリケーションの場合の平均的加入者プロフィールを誘導するステップをさらに含む、請求項８に記載の方法。
【請求項１０】
所与のアプリケーションに対して１加入者当たりの前記最繁時トラフィック比率を決定する（２０６）前記ステップは、
１アプリケーションセッション当たりのバイト数を推定又は測定するステップと、
１アプリケーションセッション当たりの前記推定又は測定されたバイト数に前記決定された加入者プロフィールを乗算するステップと、
を含む、請求項８に記載の方法。
【請求項１１】
前記複数のアプリケーションは、回線交換アプリケーションとパケットデータアプリケーションとの双方を含む、請求項１に記載の方法。
【請求項１２】
全てのパケットデータアプリケーションがトラフィックの対話クラスであると考慮され、全ての回線交換アプリケーションが対話トラフィッククラスであると考慮される、請求項１１に記載の方法。
【請求項１３】
前記無線通信システムの容量は、１セクター当たりで決定される（２１６）、請求項１に記載の方法。
【請求項１４】
１つ以上のプロセッサに対して、複数のアプリケーションをサポートするように構成された無線通信システムを次元合わせするステップを実行させる１つ以上のシーケンスから成る命令を記憶しているコンピュータ読み取り可能媒体であって、前記ステップは、
各アプリケーション毎に、前記アプリケーションを使用する前記無線通信システムの加入者のパーセンテージを推定する（２０２）ステップと、
各アプリケーション毎に、前記アプリケーションを使用する加入者の前記推定されたパーセンテージに少なくとも部分的に基づいて前記アプリケーションの加入者プロフィールを決定する（２０４）ステップと、
各アプリケーション毎に、前記アプリケーションの前記加入者プロフィールに少なくとも部分的に基づいて前記アプリケーションの場合の１加入者当たりの最繁時トラフィック比率を決定する（２０６）ステップと、
前記無線通信システムに対して、各アプリケーション毎に決定された１加入者当たりの前記最繁時トラフィック比率から１加入者当たりの合計最繁時トラフィック比率を決定する（２０６）ステップと、
前記無線通信システムに対して、合計トラフィック容量を推定するステップと、
前記無線通信システムに対して、前記推定された合計トラフィック容量を１加入者当たりの前記決定された合計最繁時トラフィック比率で除算することによって、前記無線通信システムがサポートする加入者の数を決定するステップと、
を含む、前記コンピュータ読み取り可能媒体。
【請求項１５】
前記ステップは、
各アプリケーション毎に、スケジューラ効率係数を推定する（２０８）ステップと、
各アプリケーション毎に、１加入者当たりの前記最繁時トラフィックを、前記推定されたスケジューラ効率係数に少なくとも部分的に基づいて正規化して（２１２）、必要とされる生データビットを決定するステップと、
をさらに含む、請求項１４に記載のコンピュータ読み取り可能媒体。
【請求項１６】
前記無線通信システムに対して１加入者当たりの前記合計最繁時トラフィック比率を決定する（２１４）前記ステップは、各アプリケーションに対して前記必要とされる生データビットを合計するステップを含む、請求項１５に記載のコンピュータ読み取り可能媒体。
【請求項１７】
複数のアプリケーションをサポートするように構成された無線通信システムを次元合わせするように構成されたシステムにおいて、該システムは、
プロセッサと、
データ記憶領域と、
実行領域と、
を備え、該実行領域は、
各アプリケーション毎に、前記アプリケーションを使用する前記無線通信システムの加入者のパーセンテージを推定する（２０２）ステップと、
各アプリケーション毎に、前記アプリケーションを使用する加入者の前記推定されたパーセンテージに少なくとも部分的に基づいて前記アプリケーションの場合の加入者プロフィールを決定する（２０４）ステップと、
各アプリケーション毎に、前記アプリケーションの場合の１加入者当たりの最繁時トラフィック比率を、前記アプリケーションの場合の前記加入者プロフィールに少なくとも部分的に基づいて決定する（２０６）ステップと、
前記無線通信システムに対して、各アプリケーション毎に決定された１加入者当たりの前記最繁時トラフィック比率から１加入者当たりの合計最繁時トラフィック比率を決定する（２０６）ステップと、
前記無線通信システムに対して、合計トラフィック容量を推定するステップと、
前記無線通信システムに対して、前記推定された合計トラフィック容量を１加入者当たりの前記決定された合計最繁時トラフィック比率で除算することによって、前記無線通信システムがサポートする加入者の数を決定するステップと、
から構成された前記システム。
【請求項１８】
前記実行領域は、さらに、
各アプリケーション毎に、スケジューラ効率係数を推定する（２０８）ステップと、
各アプリケーション毎に、１加入者当たりの前記最繁時トラフィック比率を、前記推定されたスケジューラ効率係数に少なくとも部分的に基づいて正規化して（２１２）、要求される生データビットを決定するステップと、
を含む、請求項１７に記載の方法。
【請求項１９】
前記無線通信システムに対して１加入者当たりの前記合計最繁時トラフィック比率を決定する（２１４）前記ステップは、各アプリケーションに対して前記必要とされる生データビットを合計するステップを含む、請求項１８に記載のコンピュータ読み取り可能媒体。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
実際には、近代的なシステムでは、式（１）で与えられるより遙かに複雑なモデルが必要とされるが、基本的な原理はそれでも同じである。したがって、無線システムの技術者は、いくつの基地局が必要であるか、また、それらをどこに配置するかを計画する際に、トラフィック（ｔ）と、利用可能な回線の数（ｃ）と、受け入れ可能と考えられる遮断された呼の数と、に目をやる。このようなシステムは複雑であるため、トラフィック（ｔ）は、無線リソース管理スキームやユーザの移動性が呼当たりのトラフィック量に与える影響などの問題を解析する複雑なトラフィックモデルに基づいて決定される。遮断された呼の数は、サービスの等級（ＧＯＳ）と呼ばれる。ＧＯＳを指定し、トラフィック（ｔ）を適切なトラフィックモデルに従って決定することによって、無線システムの技術者は、必要とされる回線の数（ｃ）を決定することが可能である。ＧＯＳは、一般的には、任意の２４時間という期間で、その間に最大の合計トラフィック負荷が発生する６０分という期間である最繁時に適用される。しかしながら、パケットデータアプリケーションでは、ＧＯＳを用いない。その替わりに、パケットデータアプリケーションは、ビットエラー率（ＢＥＲ）で測定されたサービス品質（ＱｏＳ）を用いることを特徴とする。したがって、パケットデータアプリケーションでは、遮断された呼の数に照らし合わせたビットエラーの数に注目する。従来のモデルでは、回線交換アプリケーションにおけるＧＯＳ要件をパケットデータアプリケーションにおけるＱｏＳ要件と同等化する方法は提供されない。


【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】変更
【補正の内容】
【０００８】
（発明の開示）
本発明のある態様に依れば、回線交換アプリケーションとパケットデータアプリケーションの双方をサポートする無線通信システムを寸法合わせするシステムと方法が、ＧＯＳの要件とＱｏＳの要件を同等化する仕方として提供される。この態様の１つの特徴は、技術者が、この無線通信システムの所与のサービス区域における所与の数のユーザをサポートするに必要とされる基地局の最適数を決定したほうが良いという点である。


【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１６
【補正方法】変更
【補正の内容】
【００１６】
回線交換のそれであろうとパケット交換のそれであろうと、様々なデータサービスには、それぞれ様々なＧＯＳ又はＱｏＳが必要である。今日のインターネットは、「ベストエフォート」と呼ばれてきたサービスを提供する。あるものがパケットを送信すると、その時点で他のトラフィックが提供されれば、ネットワークはそれ自身が提供し得るベストなものとして転送するが、送付のレートすなわちそのパケットが送付されるレートに関する具体的な保証は全くしない。多くのコンピュータアプリケーションは、帯域幅を保証しない状況で極めて自然に動作しており、ベストエフォートサービスは多くのコンピュータアプリケーションにとって効果的であることが実証されている。ベストエフォートサービスは、利用可能な帯域幅を現行のユーザ間で分割する。アプリケーションを時として少し遅く実行しても、深刻なユーザの不満を常に引き起こすとは限らない。事実、遠隔ファイルアクセスなどのアプリケーションの場合、ベストエフォートサービスは非常に効果的であることが分かっている。もちろん、ベストエフォートサービスは、ある制限内でのみ許容されるものであり、全くふくそうしているネットワークは受け入れることはできない。


【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００１７
【補正方法】変更
【補正の内容】
【００１７】
ベストエフォートサービスに対する代替物として、トラフィックソースに対して、そのサービス要件を宣言することを要求し、これによって、ネットワークがこのサービスを確保して保証することが可能であるか又は明示的にこの要求を拒否することが可能であるようにするものがある。過剰な帯域幅がある場合、ベストエフォートサービスと確保された帯域幅サービスとの双方が良く相乗作用して、ユーザが満足する。しかしながら、ふくそうがあると、ベストエフォートサービスの場合のように全てのユーザを幾分かでも遅速させるか又は１部のユーザを完全に拒否し、これによって、確保された帯域幅を他のユーザに対して完全に提供するかのどちらかが選択されることになる。リアルタイムオーディオやビデオなどの１部のアプリケーションの場合、確保されたサービスの方が好ましい。その結果、システム１００は、様々なベアラーサービスを介して様々なデータアプリケーションを提供することが可能である。ベアラーサービスのこの種の変動は、ＱｏＳによって記述され、これは、技術社会によって、遅延や、帯域幅や、シェアリング程度に対する保証の程度や、損失レートや、その他の管理をカバーするものであると理解される。


【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００１８
【補正方法】変更
【補正の内容】
【００１８】
インターネットとモバイルデータパケットアプリケーションは、単一のベストエフォートサービスからＱｏＳの明示的オプションを持った、より複雑なモデルに移行しつつあり、これによって、ビデオやオーディオなどの新たなアプリケーションをサポートしようとしている。回線交換側では、様々なベアラーがＧＯＳによって指定される。例えば、ＣＤＭＡ２０００無線通信システムの１つのトラフィックモデルでは、回線交換音声アプリケーションに対して２つのベアラーサービスオプションを用いている。第１のサービスオプション、すなわちレートセット１は、９．６Ｋｂｐｓから１．２Ｋｂｐｓで動作する。第２のサービスオプション、すなわちレートセット２は、１４．４Ｋｂｐｓから１．２Ｋｂｐｓで動作する。ＣＤＭＡ２０００基格は、レートセット１（９．６ｋｂｐｓ）及びレートセット２（１４．４ｋｂｐｓ）における回線データサービスと、６４ｋｂｐｓにおける新しいサービスオプションとに対応している。この新しいサービスオプションを効果的に使用するには、エンドツーエンドでのＩＳＤＮサービスが必要である。パケットデータアプリケーションの場合、ＣＤＭＡ２０００Ｐｈａｓｅ　１が、１４４ｋｂｐｓという最大パケット交換サービスレートを可能としている。


【手続補正７】
【補正対象書類名】図面
【補正対象項目名】図２
【補正方法】変更
【補正の内容】
【図２】
2004511140.tif 000047
【国際調査報告】
2004511140.tif 000048
2004511140.tif 000049
2004511140.tif 000050