(57)【要約】パケットサイズをＶｏＩＰ通信に適応させるための方法が提示される。その適応は、パケット伝送時に固有のネットワーク全体の遅延に基づいて通信中に決定される。ネットワーク遅延が、ＶｏＩＰ通信に対する最大許容待ち時間と比較して小さい場合、パケットあたりのペイロードサイズは、伝送される通話に対する効率を最大化するために、増大され得る。あるいは、ネットワーク遅延が大きい場合、パケットあたりのペイロードサイズは、伝送される通話の知覚される品質が容認できることを保証するために、減少され得る。
2009529255.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークにおいてインターネットプロトコルを介する音声（ＶｏＩＰ）通話を通信するための方法であって、該方法は、
特定のＶｏＩＰ通話またはそれらのレッグに対して、個別化されたパケット化インターバルを計算することであって、該計算することは、該通話に対するネットワーク待ち時間特性に基づく、ことと、
該個別化されたインターバルにおいて該通話のパケットを通信することと
を包含する、方法。
【請求項２】
前記パケット化インターバルを計算することは、前記通話に対する前記ネットワーク待ち時間特性を測定または推定することを少なくとも包含する、請求項１に記載の方法。
【請求項３】
前記通話または前記レッグに対して前記パケット化インターバルを計算することは、前記ネットワークの全体的な性能と関連した考慮にさらに基づく、請求項１または請求項２に記載の方法。
【請求項４】
前記考慮は、その時点で前記ネットワークによってサポートされ得るＶｏＩＰ通話の総数を最大化すること、および／または該ネットワーク内の１つ以上のアクセスポイントにおけるローディングを低減することを包含する、請求項３に記載の方法。
【請求項５】
ネットワークにおいてインターネットプロトコルを介する音声（ＶｏＩＰ）通話を通信するための方法であって、該方法は、
２つ以上の通話レッグにおいて該ＶｏＩＰ通話を確立することと、
各レッグに対して、個別化されたパケット化インターバルを計算することであって、該計算することは、該ＶｏＩＰ通話のネットワーク待ち時間特性に基づく、ことと、
該個別化されたパケット化インターバルにおいて各レッグ上の該通話のパケットを通信することと
を包含する、方法。
【請求項６】
各レッグに対して前記個別化されたパケット化インターバルを計算することは、前記通話の異なるレッグに対して、異なる個別化されたパケット化インターバルを計算すること、および／または前記ネットワーク待ち時間特性を測定または推定することを少なくとも包含する、請求項５に記載の方法。
【請求項７】
各レッグに対して前記個別化されたパケット化インターバルを計算することは、前記ネットワークの全体的な性能と関連した考慮にさらに基づく、請求項５に記載の方法。
【請求項８】
前記考慮は、その時点で前記ネットワークによってサポートされ得るＶｏＩＰ通話の総数を最大化すること、および／または該ネットワーク内の１つ以上のアクセスポイントにおけるローディングを低減することを包含する、請求項７に記載の方法。
【請求項９】
インターネットプロトコルを介する音声（ＶｏＩＰ）通話を用いて、ネットワークにおいて通信するためのワイヤレスモバイル通信デバイスにおける方法であって、該方法は、
所定のデータパケットサイズを有するデータとのＶｏＩＰ接続を確立することと、
該ＶｏＩＰ接続の往復の待ち時間を評価することと、
該ＶｏＩＰ接続の該評価された往復の待ち時間を送信することと、
該ＶｏＩＰ接続の該評価された往復の待ち時間に基づいて、サイズを変えられたデータパケットを受信することと
を包含する、方法。
【請求項１０】
前記ＶｏＩＰ接続の前記往復の待ち時間を評価することは、
該ＶｏＩＰ接続の該往復の待ち時間を測定または推定することを包含する、請求項９に記載の方法。
【請求項１１】
前記受信されるデータパケットは、前記ネットワークの全体的な性能と関連した考慮にさらに基づいて、サイズを変えられる、請求項９または請求項１０に記載の方法。
【請求項１２】
前記考慮は、その時点で前記ネットワークによってサポートされ得るＶｏＩＰ接続の総数を最大化すること、および／または該ネットワーク内の１つ以上のアクセスポイントにおけるローディングを低減することを包含する、請求項１１に記載の方法。
【請求項１３】
ネットワークサーバであって、
プロセッサと、
該プロセッサに連結されたネットワークインタフェースカードと、
該プロセッサに連結されたメモリであって、該メモリは、該プロセッサによって実行されたときに、インターネットプロトコルを介する音声（ＶｏＩＰ）通話の第１のレッグを該通話の第１の当事者と確立し、該通話の第２のレッグを該通話の第２の当事者と確立することが可能なコードを格納しており、該メモリはまた、該プロセッサによって実行されたときに、該通話の一方の当事者からの入データを、該通話の他方の当事者のために、一方のパケット化インターバルから、異なるパケット化インターバルに変換するための待ち行列を作成および維持することが可能なコードを格納している、メモリと
を備える、ネットワークサーバ。
【請求項１４】
前記メモリはまた、前記プロセッサによって実行されたときに、前記第１のレッグに対するネットワーク待ち時間特性に基づいて、該第１のレッグに対して前記パケット化インターバルを決定し、前記第２のレッグに対するネットワーク待ち時間特性に基づいて、該第２のレッグに対して前記パケット化インターバルを決定することが可能なコードを格納している、請求項１３に記載のネットワークサーバ。
【請求項１５】
前記ネットワークサーバは、リアルタイムゲートウェイである、請求項１３または請求項１４に記載のネットワークサーバ。
【発明の詳細な説明】
【背景技術】
【０００１】
（背景）
近年、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）のためのＩＥＥＥ８０２．１１規格は、ブロードバンドワイヤレスアクセスネットワークの「最後のマイル（ｌａｓｔ  ｍｉｌｅ）」に対する有力な技術として出現してきた。これらのネットワークの主要な用途が、Ｅメールおよびウェブブラウズなどのベストエフォート型のデータアプリケーションを実行するデバイスへの接続性を提供することにあったのに対して、電話サービスまたはストリーミングビデオなどの、等時性の（ｉｓｏｃｈｒｏｎｏｕｓ）サービスをサポートすることに対する関心が高まっている。インターネットプロトコルを介する音声（ＶｏＩＰ）がＷＬＡＮを介すること（ＶｏＷＬＡＮ）は、現在、最も急成長しているインターネットアプリケーションの１つである。
【０００２】
ＶｏＩＰにおいて、音声信号は、固定されたレートでサンプリングされる。「パケット」は、複数のヘッダ、ペイロードおよび１つ以上のトレイラを含むデータから組み立てられる。ヘッダおよびトレイラは、（ｉ）パケットの起点および宛先に関する情報、（ｉｉ）通話を構成するパケットのストリームにおけるパケットの相対位置に関する情報、（ｉｉｉ）ネットワークによって用いられる通信プロトコルに関する情報、そしてとりわけ、（ｉｖ）エラーチェック情報、を含む。総合すると、ヘッダおよびトレイラは、パケットと関連づけられるオーバヘッドとして示される。ペイロードは、デジタル化音声信号に相当する音声サンプルを含むパケットの一部分である。２つの連続的なパケットの世代間の時間は、パケット化（ｐａｃｋｅｔｉｚａｔｉｏｎ）インターバルとして公知である。一般に、パケットは、一定の長さをもち、パケット化インターバルは、通話を伝送するために用いられるボコーダのタイプによって決定される。典型的なボコーダは、１０〜３０ミリ秒のパケット化インターバルを用いる。例えば、Ｇ．７１１タイプのボコーダは、２０ミリ秒のパケット化インターバルを多く用いる。
【０００３】
短いパケット化インターバルに関して、オーバヘッドに相当するパケットの端数（ｆｒａｃｔｉｏｎ）は、主に、様々なプロトコルレイヤを特徴付けるために必要とされるバイトの数に起因して、多量であり得る。通話の伝送効率は、主として、実際のペイロードに対応するパケットの端数によって決定される。より多量のペイロードを有するより大型のパケットは、通信の効率を上げるけれども、一定の状況下で、増大したパケット化待ち時間に起因する不十分な通話品質をもたらし得る。
【０００４】
多くの場合、ＶｏＩＰ通話に用いられるデバイスは、電池で駆動される可搬型ハンドヘルドデバイスである。短いパケット化インターバルは、電池駆動のモバイル通信デバイス中に蓄積されたエネルギーのより速い消耗をもたらす。なぜなら、デバイスが音声パケットの送信／受信に携わる時間の割合は、各々の短いパケットにおけるオーバヘッドに起因して、同じデータ量に対してより高いからである。より長いパケット化インターバルは、電力使用を減少させ、電池を保持するためのこの情況においてまた望ましい。
【発明の開示】
【課題を解決するための手段】
【０００５】
（概要）
パケットサイズをＶｏＩＰ通信に適応させるための方法が提示される。その適応は、接続の確立時またはパケット伝送時のネットワーク待ち時間に基づいて通信中に決定される。ネットワーク遅延が、ＶｏＩＰ通信に対する最大許容待ち時間と比較して小さい場合、パケットあたりのペイロードサイズは増大され得、すなわち、より長いパケット化インターバルが用いられ得、伝送される通話に対する効率を最大化する。あるいは、ネットワーク遅延が大きい場合、より短いパケット化インターバルは、伝送される通話の知覚される品質が容認できることを保証するために用いられ得る。単一のＶｏＩＰ通話は、２つ以上の連結されたレッグ（ｌｅｇ）に分割され得、各レッグは、異なるパケット化インターバルを用い得る。パケット化インターバルを決定するために、ＶｏＩＰ通話の待ち時間を測定するか、または推定することに加えて、ネットワーク全体の性能尺度もまた考慮され得る。パケット化インターバルは、ネットワークによって同時に収容され得る、ＶｏＩＰ通話の総数を最大化するように調整され得るか、または特に激しいトラヒックを経験する一定のネットワークアクセスポイントにおけるローディングを低減するように調整され得る。
【０００６】
実施形態は、添付の図面の図において、制限ではなく例示として図示され、そこにおいて、同様な参照数字は、対応する相似または同様な要素を示す。
【０００７】
説明図の単純さおよび明快さのために、図において示される要素が必ずしも正確な縮尺で描かれていないことは認識される。例えば、一部の要素の寸法は、他の要素と比較して明快さのために強調され得る。
【発明を実施するための最良の形態】
【０００８】
（詳細な説明）
以下の詳細な説明において、多くの具体的な詳細が、実施形態の完全な理解を提供するために明記される。しかし、実施形態がこれらの具体的な詳細なしに実施され得ることは、当業者によって理解される。他の例において、周知の方法、手順、構成要素および回路は、実施形態を不明瞭にしないために詳細に記述されない。
【０００９】
ＶｏＩＰ通話の伝送効率を増大させるために、より長いパケットが、オーバヘッドと比較してペイロードを増大させるために用いられ得る。しかし、一定の状況下で、より長いパケットは、通話の知覚される品質に負の影響を及ぼし得る。より多くの音声データが各パケットに収容されることから、伝送中の１個のパケットの損失は、通話の知覚される品質に対して、より短いパケットの損失と比べてより重大な影響を有する。Ｐａｃｋｅｔ  Ｌｏｓｓ  Ｃｏｎｃｅａｌｍｅｎｔ（ＰＬＣ）技法は、失われたパケットの効果をマスキングするために用いられ得るが、現在のＰＬＣ技法は、Ｇ．７１１タイプのボコーダに対する２０ミリ秒を超えるサンプルの損失を隠蔽することに対して不十分である。３０〜４０ミリ秒のサンプルは、Ｇ．７２９およびＧ．７２３ボコーダに対して隠蔽され得る。より長いパケット化インターバル（より長いパケットからもたらされる）はまた、通話に対して、増大した待ち時間または増大した伝送遅延に寄与する。最大の目標待ち時間は、国際電気通信連合標準化部門（ＩＴＵ−Ｔ）規格Ｇ．１１４によって規定されたものが、多く用いられる。これは、１５０ミリ秒の最大の単向（口から耳への）遅延が、電話用途に対して満足のいく品質を提供すると述べている。単向の待ち時間を１５０ミリ秒に制限するために、ネットワーク内部のすべての遅延は、計上されて、制御されなければならない。ネットワーク内部の遅延は、例えば、ネットワークを介する伝播遅延および待ち行列遅延、輻輳によるスケジューリング遅延、およびアクセスリンクシリアル化（ａｃｃｅｓｓ  ｌｉｎｋ  ｓｅｒｉａｌｉｚａｔｉｏｎ）遅延、を含む。パケット化インターバルはまた、１００ミリ秒のパケット化インターバルに対する最小の単向の遅延が１００ミリ秒であることにおいて、待ち時間に寄与する。
【００１０】
所与のネットワーク上の１つの通信された通話に対する待ち時間は、非常に変化しやすく、その特定の通話に特有である。待ち時間は、その時点のネットワークトラヒック量、または宛先デバイスに対する起点デバイスの「位置」、すなわち、２つのデバイスを接続するために必要とされる中間のデバイスの数およびタイプ、などの因子に依存する。しかし、現在、用いられるボコーダに対応する標準的なパケット化インターバルが、一般に用いられる。表１は、一般的なボコーダタイプに対して用いられる、典型的なパケット化インターバルを列挙する。これらのボコーダはすべて、コンスタントビットレート（ＣＢＲ）デバイスである。商業的に利用可能なほとんどのＷＬＡＮ移動局は、一定のレートで音声フレームを生成する。しかし、いくつかの商業的に利用可能な移動局は、異なる音声コーディングレートで、かつパケット化インターバルを変化させることによって、異なるボコーダの組をサポートする。新しい移動局は、より柔軟なパケット化インターバル（例えば、一定の最大値までの１０ミリ秒の倍数）の決定を可能にし得る。
【００１１】
【表１】
2009529255.tif 000003
用いられ得る最大のパケット化インターバルは、エンドトゥエンド待ち時間の制約条件に左右され、その時点のネットワーク使用量ならびにネットワーク内の起点デバイスおよび宛先デバイスの位置によって、特定の通話に対して非常に特有であり得る。例えば、通話の時点で、ネットワーク内のアクセスポイント（ＡＰ）の一部が特に激しいトラヒックを経験し得る。通話がこれらのＡＰの１つを介してルーティングする必要が有る場合、増大した待ち時間が予期され得る。実際の通話の時点の実際のエンドトゥエンド待ち時間の関数として、パケット化インターバルを動的に最大化することによって、各通話に対する伝送効率は増大し得、ＶｏＩＰトラヒックをサポートするためのＷＬＡＮネットワークの全体的な効率は最大化し得る。さらに、より長いパケット化インターバルを用いることは、電池式の移動局に対して低減された電力消費量をもたらし得る。
【００１２】
図１は、ＶｏＷＬＡＮ通話のための例示的なパケット構造の概略図である。各パケット１００は、以下の構成要素セグメントを含む。（ｉ）物理レイヤヘッダ（ＰＨＹヘッダ）、媒体アクセス制御ヘッダ（ＭＡＣヘッダ）、および他のレイヤにおける４０バイトのヘッダ（例えば、インターネットプロトコル（ＩＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびリアルタイム伝送プロトコル（ＲＴＰ））を含む、ヘッダ１０２、（ｉｉ）１０〜３０バイト分のデータの相対的に小さなペイロード１０４、そして（ｉｉｉ）受信されたパケットの完全性を保証するために用いられる、巡回冗長検査（ＣＲＣ）値を含む、トレイラ１０６。
【００１３】
図２は、適応型音声パケット化（ＡＶＰ）スキームをサポート可能な例示的なＷＬＡＮシステム２００を示す。ＡＰ２０２、２０４および２０６の集合は、移動局（ＭＳ）２０８および２１０を含む、移動局の集団にワイヤレス適用範囲を提供する。ＬＡＮは、共有された媒体として描かれるけれども、実際には、より一般的に相互接続されたレイヤ２スイッチの集合を含む。ＡＶＰ対応リアルタイムゲートウェイ（ＡＶＰ−ＲＴＧ）サーバ２１２は、ＡＰをサービスする交換回線網上に配置される。ローカルルータ２１４は、ゲートウェイ２１６を介してインターネットおよび／または公衆交換電話網（ＰＳＴＮ；Ｐｕｂｌｉｃ  Ｓｔａｎｄａｒｄ  Ｔｅｌｅｐｈｏｎｅ  Ｎｅｔｗｏｒｋ）との通信を制御する。
【００１４】
移動局２０８、２１０のためのデバイスの例示は、ＩＰ電話、セルラ電話、スマートフォン、携帯情報端末（ＰＤＡ）、ワイヤレスハンドヘルドコンピュータ、ワイヤレスノート型コンピュータ、ワイヤレスラップトップコンピュータ、ワイヤレスデスクトップパソコンなどである。
【００１５】
サーバは、ＡＶＰスキームを特徴とする任意の従来の音声ゲートウェイまたはＲＴＰプロキシであり得る。用語「サーバ」は、コンピュータ（例えば、計算能力、メモリ、および／または接続可能性を有する）と機能的に似ているデバイスを含むことを意図される。本アプリケーションにおいて用いられるような定義に従う典型的なサーバは、限定はされないけれども、任意のコンピュータ（例えば、メインフレーム、コーポレートサーバ、パーソナルコンピュータ、ラップトップ、ＰＤＡ、など）を含み得る。本発明の様々な他の実施形態において、用語「サーバ」は、一般にコンピュータと考えられるのでなく、同様な能力を有するデバイスを含むことを意図される。
【００１６】
図３は、ＩＥＥＥ８０２．１１レガシー移動局と互換であり、図２中に示されるようなネットワークによってサポートされ得る、ＡＶＰのための例示的な方法を示す。この方法において、ＡＰを介するすべての企業内音声トラヒックは、宛先ＡＰに伝わる前にＡＶＰ−ＲＴＧサーバ２１２を介してルーティングされる。すべての企業内音声トラヒックは、単一のＡＰを介して伝わるトラヒック（すなわち、両方の通話者が同じＡＰの適用範囲領域の中にある場合）を含む。ＬＡＮから外行き方向のパケットフローは、変化がないまま、ローカルルータ２１４に直接送られる。接続セットアップおよびＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）メッセージ交換の間、ＡＶＰ−ＲＴＧサーバ２１２は、コーデックタイプおよび往復の待ち時間制約条件に従い、両方の移動局と最大限可能な音声パケット化インターバルを取り決める。内部トラヒックに対する、パケット損失率が、一般に非常に低いことにより、より長いパケットのまれな損失が、通話品質に最小の影響を及ぼす。
【００１７】
３０２において、ＭＳ２０８は、ＡＰ２０２を介する通話要求をＡＶＰ−ＲＴＧサーバ２１２に対して送信することによって、ＭＳ２１０への通話を開始する。この通話要求は、ＭＳ２０８からＡＶＰ−ＲＴＧサーバ２１２へ直接送信され得るか、または通話要求は、ＳＩＰプロキシサーバなどの他の手段を介して転送され得る。３０６において、ＡＶＰ−ＲＴＧサーバ２１２は、２つの「レッグ」が単一のＶｏＩＰ通話を構成するように、ＭＳ２０８およびＭＳ２１０の両者と、ＶｏＩＰ接続を取り決める。各レッグは、移動局（すなわち、２０８または２１０）の１つと、その終端ポイントとしてのＡＶＰ−ＲＴＧサーバ２１２とを有する。３０８において、ＭＳ２０８は、ＡＶＰ−ＲＴＧサーバ２１２との接続の往復の待ち時間を測定する。ＩＰベースの移動局は、例えば、リアルタイム制御プロトコル（ＲＴＣＰ）のＳＲおよびＲＲ（送信側リポートおよび受信側リポート）パケットを用いて、ＲＴＰ接続の遅延およびジッタを容易に測定し得る。３１０において、ＭＳ２０８は、ＡＶＰ−ＲＴＧサーバ２１２に対して待ち時間量（例えば、平均および分散などの往復の遅延の統計量）を送信する。ＡＶＰ−ＲＴＧサーバ２１２は、レッグに対して利用可能な「待ち時間マージン」を決定するために、測定された待ち時間情報を用いる。待ち時間マージンは、すなわち、実際の待ち時間と許容される最大の待ち時間との差である。３１２において、ＡＶＰ−ＲＴＧサーバ２１２は、セッション開始プロトコルおよびセッション記述プロトコル（ＳＩＰ／ＳＤＰ）信号伝送を介して、レッグに対するパケット化インターバルを取り決める。この取り決めは、そのレッグに対する最大の待ち時間制約条件に従い、ＭＳ２０８によってサポートされる最大のパケット化インターバルを決定することにより行われる。３１４〜３１８において、第２のレッグの通信のための、第２の別個のパケット化インターバルが決定される。３２０において、ＡＶＰ−ＲＴＧサーバ２１２は、自動中継器として作用し、一方のレッグからのすべての入データを、ＡＰ２０６にそれらを伝送する前に、他方のレッグのための適切な長さのパケットに再パッケージする。逆方向もまた同様である。この作用は、ＭＳ２０８およびＭＳ２１０に対して透過的である。ＡＶＰ−ＲＴＧサーバ２１２に、各エンドトゥエンド音声接続を２つの別個のレッグに分けさせることは、同じ音声通話の２つのレッグに対して非対称なパケット化インターバルを取り決めることを可能にする。このことは有用であり得、例えば、様々なＩＰベースの移動局が、パケット化インターバルおよび再生バッファに対する様々なサポートされた値の様々な音声コーデックの組を有するからである。
【００１８】
この例示的な方法において、待ち時間は、移動局によって実際に測定されるけれども、待ち時間を測定するための他の方法が代用され得る。例えば、接続の待ち時間は、接続に連結される付加的で別個のデバイスか、またはＡＶＰ−ＲＴＧサーバ自身によって測定され得る。あるいは、待ち時間は、通信デバイスのペアの相対的な位置およびネットワーク特性の知識に基づいて推定されるか、作成され得る。
【００１９】
上記された方法などの、適応型音声パケット化スキームを実装するためのコンピュータ実行可能な命令は、コンピュータ読取り可能な媒体の形式上で格納され得る。コンピュータ読取り可能な媒体は、情報（コンピュータ読取り可能な命令、データ構造、プログラムモジュールまたは他のデータなど）の格納のための任意の方法および技術で実装される、揮発性および不揮発性の媒体、取外し可能および取外し不能の媒体を含む。コンピュータ読取り可能な媒体は、限定はされないけれども、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、コンパクトディスクＲＯＭ（ＣＤ−ＲＯＭ）、デジタルバーサタイルディスク（ＤＶＤ）または他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、または所望される命令を格納するために用いられ得、インターネットまたは他のコンピュータネットワーク形式のアクセスによることを含めて、ＡＶＰ−ＲＴＧ２１２によってアクセスされ得る、すべての他の媒体を含む。
【００２０】
図４は、ＡＶＰ−ＲＴＧサーバのための例示的な内部構成を示す。任意のネットワークサーバと同様に、ＡＶＰ−ＲＴＧサーバ２１２は、プロセッサ４５０、プロセッサ４５０に連結されたネットワークインタフェースカード（ＮＩＣ）４５２、およびプロセッサ４５０に連結されたメモリ４５４を含む。デバイスは、ＷＬＡＮエンタープライズ中の各ＶｏＩＰセッションに対して、別個の待ち行列のペアを維持する。待ち行列は、メモリ４５４中に格納されたコード（図示せず）によって作成され、維持される。コードは、プロセッサ４５０によって実行される。図４において、Ｎ個のアクティブなＶｏＩＰ通話が、それぞれの通話１、２およびＮに対する待ち行列のペア４０２、４０４および４０６を有するＡＶＰ−ＲＴＧサーバによって制御されると仮定する。メモリ４５４に格納されたコード（図示せず）は、プロセッサ４５０によって実行される場合に、当事者とＡＶＰ−ＲＴＧサーバ２１２との間でアクティブなＶｏＩＰ通話のレッグを確立し得る。各ペアの内において、単一の先入れ先出し（ＦＩＦＯ）待ち行列が、ＶｏＩＰセッションに関与する各ＭＳから到着する音声パケットに対して用いられ得る。通話の各レッグに対して取り決められたパケット化インターバルに適合するために、待ち行列に入れられたパケットは、それらが宛先の移動局に伝えられる前に、より短いパケットに（待ち行列４１０におけるように）分割され得るか、またはより大きなパケットに（待ち行列４０８におけるように）集められ１つにされ得る。
【００２１】
上記および図２から図４で概説された例示的な方法において、パケット化インターバルは、通話の２つのレッグのみの測定された待ち時間マージンに従って決定される。パケット化インターバルの決定は、プロセッサ４５０によって実行される場合に、メモリ４５４に格納されたコード（図示せず）によって遂行される。ＡＶＰスキームは、ネットワーク管理レベルでも用いられ得、例えば、ネットワーク輻輳を軽減するためか、または特に激しいトラヒックを経験する一部のＡＰにおけるローディングを低減するために、用いられ得る。そのようなスキームにおいて、パケット化インターバルは、通話に対する待ち時間に加えて、ネットワーク内の異なるＡＰの現在の利用度（ｕｔｉｌｉｚａｔｉｏｎ）および／またはローディングを考慮して決定され得る。
【００２２】
一実施形態において、高度にロードされた（すなわち、輻輳した）アクセスポイントと関連づけられる移動局は、相対的に軽くロードされたＡＰと関連づけられる他の移動局よりも、大きなパケット化インターバルを割り当てられるような、ＡＶＰアルゴリズムによって援助され得る。ＷＬＡＮに渡るＶｏＩＰトラヒックの量が経時変化するときに、ＡＶＰスキームは、ネットワーク内の異なるＡＰ間のロードおよび利用度の均一化を保証するように機能し得る。そのようなアルゴリズムは、非常に変わりやすく、浮動的なエンドユーザ数をともなう、例えば、空港、ホテルまたはコーヒーショップにおける、ＷＬＡＮに対して特別の用途を有する。そのようなアルゴリズムはまた、マルチホップメッシュ（ｍｕｌｔｉ−ｈｏｐ  ｍｅｓｈ）ネットワークに拡張され得、復路（ｂａｃｋｈａｕｌ）の中継容量における相当な改善を結果としてもたらし得る。ＡＶＰスキームを用いることによって、もたらされる容量の改善は、ＩＰベースの移動局およびＡＰの両方に対して、改善された電力保持とも強く関連づけられる。
【００２３】
パケット化インターバルを割り当てるためのＡＶＰアルゴリズムは、新しい通話がブロックされる前に、ネットワークによって同時に収容され得る、ＶｏＩＰ通話の総数を最大化するように公式化され得る。
【００２４】
（ネットワーク容量の最大化）
そのようなアルゴリズムを公式化することにおいて、例えば、最初の新しい通話が利用可能な資源が不十分なためにブロックされる前に、ネットワーク内のすべてのＡＰにおいて収容され得るＶｏＩＰセッションの数を最大化するように要求し得る。そのような分析の例は以下である。
【００２５】
Ｎｉを、単一のＩＥＥＥ８０２．１１のＡＰ、ＡＰｉによって、同時にサポートされ得るＶｏＩＰセッションの最大値とする。ダウンリンク（ＤＬ）およびアップリンク（ＵＬ）パケットに対する伝送時間は、それぞれＴＤＬおよびＴＵＬで示される。
【００２６】
ＶｏＩＰパケットに対するヘッダのオーバヘッドＯＨｈｄｒは、ＲＴＰ、ＵＤＰ、ＩＰ、およびＩＥＥＥ８０２．１１のＭＡＣレイヤのヘッダから成り、
ＯＨｈｄｒ＝ＨＲＴＰ＋ＨＵＤＰ＋ＨＩＰ＋ＨＭＡＣ（ビット）  （１）
ＡＰがＤＬ  ＶｏＩＰパケットを送る場合に、ＭＳがＵＬ  ＶｏＩＰパケット（これもまた、ＡＰによって肯定応答されるべきパケット）を送る前に、ＭＳは、ＤＬパケットの受領に肯定応答すると仮定される。ＡＰのＭＡＣレイヤで被るオーバヘッドは、従って、
ＯＨＡＰ＝ＰＨＹ＋ＳＩＦＳ＋ＡＣＫ（秒）  （２）
同様に、ＭＳ側のＭＡＣレイヤで被るオーバヘッドは、
ＯＨＭＳ＝ＰＨＹ＋ＳＩＦＳ＋ＡＣＫ（秒）  （３）
ここで、ＰＨＹは、物理レイヤヘッダであり、１Ｍｂｐｓで送られる。本発明者等の分析を通じて、本発明者等は、ＭＳがＶｏＩＰトラヒックに対してスケジューリングされた伝達メカニズムを（これが、音声パケットに対して最小のアクセス遅延を保証し得るから）用いると仮定する。なぜならば、ＭＳが、コンテンション（ｃｏｎｔｅｎｔｉｏｎ）に対する要求なしで事前にスケジューリングされた時間間隔で共有されたチャネルにアクセスし得るからである（これは、ＤＩＦＳおよびＣＷｍｉｎ時間が、上の式２および式３から省略される理由である）。
【００２７】
この分析において、パケット損失およびＡＣＫ損失および音声パケット再送に対する必要性の可能性は、無視される。これは、引き出されたＶｏＩＰ容量が、実際の容量上の上限であることを意味する。
ＴＤＬ＋ＴＵＬ＝［２＊（音声ペイロード＋ＯＨｈｄｒ）／
ＴｒａｎｓｍｉｓｓｉｏｎＲａｔｅ］＋ＯＨＡＰ＋ＯＨＭＳ  （４）
ここで、
音声ペイロード＝Ｐｔｉｍｅ＊ＣｏｄｅｃＲａｔｅ  （５）
である。
【００２８】
ここで、ＭＳによって送られたＵＬ音声パケットおよびＡＰから受信されたＤＬ音声パケットの両方が、同じサイズを有し、同じレートで送られると仮定される。次に、ｉ番目のＡＰ、ＡＰｉに対して、ｎｉ個のアクティブなＶｏＩＰセッションがあると仮定される。これらのＶｏＩＰセッションは、ＡＰｉと関連づけられるＭＳで終端する。それゆえに、ｎｉ個のアクティブなＶｏＩＰセッションに起因するＡＰｉの正規化されたローディング（すなわち、利用度）は、次のように表現され得る。
【００２９】
【数１】
2009529255.tif 000004
ここで、Ｎｐｊは、ｊ番目のＶｏＩＰセッションに対して、ＡＰおよびＭＳ（毎秒あたり）の両方によって送られた音声パケットのペアの数であり、Ｎｐｊは、その通話に対してＭＳとＡＰｉとの間のレッグで用いられる、コーデックのパケット化インターバル（Ｐｔｉｍｅｊ）に依存し、
Ｎｐｊ＝１／Ｐｔｉｍｅｊ  （７）
となる。
【００３０】
一般に、ｎｉ個の許可されたＣＢＲ  ＶｏＩＰ通話を有するＡＰｉに対して、サポートされ得るＶｏＩＰセッションの最大値‘Ｎｉ’は、進行中のｎｉ個のセッションをサポートするために必要とされる実際の容量の端数に反比例し、
Ｎｉ∝１／Ｕｉ  （８）
となる。
【００３１】
ネットワーク内のすべてのＡＰによって許可され得る、ＶｏＩＰセッションの数を最大化するために、この最適化問題は、
【００３２】
【数２】
2009529255.tif 000005
と書かれ得る。ここで、Ｍは、ＷＬＡＮエンタープライズ中のＡＰの数である。
【００３３】
これは、凸問題であることから、これは、エンタープライズ中のすべてのＡＰのローディングの合計の最小化（ＭａｘＮｅｔｗｏｒｋＣａｐ公式化）として、
【００３４】
【数３】
2009529255.tif 000006
と書き直され得る。ここで、
【００３５】
【数４】
2009529255.tif 000007
となり、
【００３６】
【数５】
2009529255.tif 000008
の条件に従う。ここで、
【００３７】
【数６】
2009529255.tif 000009
である。Ｐｔｉｍｅｊ，１およびＰｔｉｍｅｊ，２は、ｊ番目の通話の２つのＭＳ側で生成された音声パケットに対応するパケット化インターバル値のペアであり、ＭｉｎＰｔｉｍｅｊ，１およびＭａｘＰｔｉｍｅｊ，１は、ｉ番目のＡＰと関連づけられるｊ番目の通話に対して用いられる、移動局によってサポートされたパケット化インターバル値の下限値および上限値である。ＬＭｊは、ｊ番目のＶｏＩＰセッションに対して利用可能な往復の待ち時間マージンである。ＡＤ（）は、非対称なＰｔｉｍｅｊ，１およびＰｔｉｍｅｊ，２値を用いる結果として、ｊ番目のＶｏＩＰセッションの両レッグで受信される音声パケットを分割／パッキングすることに対して、ＡＶＰ−ＲＴＧサーバで被るＶｏＩＰパケット適応遅延である。Ｄｎｅｔｗｏｒｋは、待ち時間マージン制約条件式１３（例えば、伝播遅延、チャネルアクセス遅延、・・・など）において言及される以外の、ＶｏＩＰパケットによって経験されたすべての遅延構成要素を含むネットワーク遅延である。典型的なＷＬＡＮエンタープライズのセットアップにおける伝播遅延は、典型的なパケット化インターバル期間と比較して無視可能である。なぜならば、有線の配布システム（例えば、イーサネット（登録商標））が、エンタープライズ中の異なるＡＰ間のトラヒック（ＶｏＩＰストリームを含む）を輸送するために用いられるからである。
【００３８】
この最適化問題の特殊な場合において、すべての通話が、同じボコーダおよび同じサンプリングレートをサポートする移動局間で行われる状況を考慮し得る。さらに、ＩＥＥＥ８０２．１１ＷＬＡＮの基本的なＰＨＹレイヤが、ネットワーク内のすべてのＡＰに対して同じであると仮定され得る。この場合に、全体的な最適は、通話の両側の利用可能な待ち時間マージン「ＬＭ」を分割することによって取得され得る（すなわち、Ｐｔｉｍｅ１＝Ｐｔｉｍｅ２＝ＬＭ／２）。アルゴリズム「ＳｐｌｉｔＬＭ」（以下にリストされる）は、特殊な場合の問題を最適に解決するために、単純な発見的アルゴリズムとして用いられ得る。しかし、そのアルゴリズムは、より一般的なＭａｘＮｅｔｗｏｒｋＣａｐ最適化問題に対する、次善の解決策を提供する。
【００３９】
【表２】
2009529255.tif 000010
（特に激しいトラヒックを経験するＡＰにおいて、ＶｏＩＰ容量を最大化すること）
あるいは、エンタープライズ中のすべての「Ｍ」ＡＰの間で、最大のＶｏＩＰトラヒックのロードを有する、ＡＰのＶｏＩＰ容量を最大化することが可能である。そのような分析の例は、（Ｍｉｎ−Ｍａｘ  ＡＰ  Ｕｉｌｉｚａｔｉｏｎ‘ＭＭＡＵ’公式化）に従い、
ｍｉｎ｛ｍａｘＵｉ｝、  ｉ＝１、２、・・・、Ｍ
となり、
【００４０】
【数７】
2009529255.tif 000011
の条件に従う。
以上の、ｍｉｎ−ｍａｘ最適化は、全体的である。すなわち、ＷＬＡＮエンタープライズ中のすべてのアクティブな通話にわたって同時に適用される。
【００４１】
ＡＤ（）における非線形な「シーリング（ｃｅｉｌｉｎｇ）
【００４２】
【数８】
2009529255.tif 000012
」オペレータは、組合せの個別的な整数問題である、ＭａｘＮｅｔｗｏｒｋＣａｐおよびＭｉｎ−Ｍａｘ  ＡＰ  Ｕｔｉｌｉｚａｔｉｏｎの両方の複雑性に若干の試練を付け加える。両方の問題の公式化における目的関数は、等価な凸最適化問題に容易に変換され得るけれども、残念なことに、待ち時間マージン制約条件における非線形性のために、両方の問題を最適に解決することは非常に困難である。
【００４３】
この問題に対して可能性の有る解決法は、貪欲ベースの（ｇｒｅｅｄｙ−ｂａｓｅｄ）発見的アルゴリズムの使用である。２つのそのようなアルゴリズム、「Ｈｅｕｒｉｓｔｉｃ  ＭａｘＮｅｔｗｏｒｋＣａｐ」またはＨｅｕｒｉｓｔｉｃ−１、そして「Ｈｅｕｒｉｓｔｉｃ  Ｍｉｎ−Ｍａｘ  ＡＰ  Ｕｔｉｌｉｚａｔｉｏｎ」またはＨｅｕｒｉｓｔｉｃ−２が、段落［００２８］および段落［００３８］における両方の公式化の近最適解に対して用いられ得る。
【００４４】
両方の発見的アルゴリズムは、費用（ｃｏｓｔ）関数を全体的に最小化するというよりも局所的な最適化技法を展開する。貪欲ベースの解法は、典型的な通話許可制御（Ｃａｌｌ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ）スキームに類似する方式で作用する。そのスキームは、実行可能な解によって、新しく要求された各通話に対してパケット化インターバル値を初期化し、それからＡＰ端に対する最適に近い最小利用度を取得するために、限られた数の隣接する「Ｐｔｉｍｅ」値を試行する。
【００４５】
「Ｈｅｕｒｉｓｔｉｃ  Ｍｉｎ−Ｍａｘ  ＡＰ  Ｕｔｉｌｉｚａｔｉｏｎ」アルゴリズムは、局所的な最適化技法を採用する。その技法は、費用関数を全体的に最小化しようと試みるというよりも、すべての新しく要求されたＶｏＩＰ通話の次善のＰｔｉｍｅ１値およびＰｔｉｍｅ２値のペアを探索する。その解法は、典型的な通話許可制御スキームに類似する方式で作用する。新しく要求された各通話に対して、アルゴリズムは、２つの音声ＭＳ（すなわち、ＡＰ１およびＡＰ２）と関連づけられるＡＰを決定することによって始動する。それから、アルゴリズムは、実行可能な解によって、新しい通話に関係する各ＭＳのパケット化インターバル長（すなわち、Ｐｔｉｍｅ１およびＰｔｉｍｅ２）を初期化する。その解は、ＭＳによってサポートされた最大許容パケット化インターバルと、新しい接続の２つのＭＳ端の間で測定された利用可能な往復の待ち時間マージンの半値との極小値として選択される。これらの初期値は、Ｐｔｉｍｅ１およびＰｔｉｍｅ２に対する初期の最適な（発見的アルゴリズムの情況において次善の）値であり、よりよい実行可能な解が見出されるときに、アルゴリズムの進行中にアップデートされる。
【００４６】
初期化フェーズの後で、Ｐｔｉｍｅ１およびＰｔｉｍｅ２に対する初期化値が同じであるか否かをチェックすることによって、アルゴリズムは進行する（ライン９、１０、および１１）。もし初期化値が同じである場合、近最適解が見出され、アルゴリズムは終端する。なぜなら、Ｐｔｉｍｅ１およびＰｔｉｍｅ２の対称的な初期値の使用が、式１７の待ち時間制約条件を満足するからである。Ｉｎｉｔｉａｌ  Ｐｔｉｍｅ値が異なる場合、アルゴリズムは（ライン１２において）、ＡＰ１がＡＰ２より重くロードされるか否かをチェックする。ＡＰ１のロードが重い場合、アルゴリズムは、Ｐｔｉｍｅ１の可能な限り大きな値を探索する（ライン１３から２０）。そのＰｔｉｍｅ１値は、ＡＰ１の最小のローディングを達成する間の新しい通話の許可を保証する。このことは、Ｐｔｉｍｅ１＝Ｉｎｉｔｉａｌ  Ｐｔｉｍｅ１によって開始し、Ｉｎｉｔｉａｌ  Ｐｔｉｍｅ２に達するまで、Ｐｔｉｍｅ１を繰り返し減算することによって行われる。ｆｏｒループの各繰返しにおいて（ライン１３）、アルゴリズムは、Ｐｔｉｍｅ２の可能な最も大きな値を見出すよう試みる。（ループ繰返しのＰｔｉｍｅ１の現在の値を与えられる）そのＰｔｉｍｅ２値は、待ち時間制約条件を満足し、よりよい解（すなわち、ＡＰ１およびＡＰ２のより低い利用度）を生み出す。なにも見出されない場合、Ｐｔｉｍｅ１は、最小のフレームサイズ（例えば、２０ミリ秒）によって減算され、同じステップは、よりよい解が見出されるか、またはＰｔｉｍｅ１がＩｎｉｔｉａｌ  Ｐｔｉｍｅ２値に達するまで、繰り返される。一方、ＡＰ２がＡＰ１より重くロードされる場合、アルゴリズムは、Ｐｔｉｍｅ２の可能な限り大きな値を探索する（ライン２１から３０）。そのＰｔｉｍｅ２値は、ＡＰ２の最小の利用度を達成する間の新しい通話の許可を保証する。
（Ｍｉｎ−Ｍａｘ  ＡＰ  Ｕｔｉｌｉｚａｔｉｏｎ（ＭＭＡＵ））
【００４７】
【数９−１】
2009529255.tif 000013
【００４８】
【数９−２】
2009529255.tif 000014
「Ｈｅｕｒｉｓｔｉｃ  ＭａｘＮｅｔｗｏｒｋＣａｐ」アルゴリズムは、「Ｈｅｕｒｉｓｔｉｃ  Ｍｉｎ−Ｍａｘ  ＡＰ  Ｕｔｉｌｉｚａｔｉｏｎ」アルゴリズムの変形版である。「Ｈｅｕｒｉｓｔｉｃ  ＭａｘＮｅｔｗｏｒｋＣａｐ」アルゴリズムは、局所的な最適化技法を展開する。その技法は、すべてのＡＰのローディングの１つのノルム（ｎｏｒｍ）の合計を最小化するために、新しく要求されたＶｏＩＰ通話のＰｔｉｍｅ１およびＰｔｉｍｅ２の次善のペアを探索する。アルゴリズム初期化部分は、「Ｈｅｕｒｉｓｔｉｃ  Ｍｉｎ−Ｍａｘ  ＡＰ  Ｕｔｉｌｉｚａｔｉｏｎ」アルゴリズムにおけるものと同一である。初期化フェーズの後で、Ｐｔｉｍｅ１およびＰｔｉｍｅ２に対する初期化値が同じであるか否かをチェックすることによって、アルゴリズムは進行する（図３中のライン９、１０、および１１）。もし初期化値が同じである場合、近最適解は見出され、アルゴリズムは終端する。なぜなら、Ｐｔｉｍｅ１およびＰｔｉｍｅ２の対称的な初期値の使用が、式１３の待ち時間制約条件を満足するからである。Ｉｎｉｔｉａｌ  Ｐｔｉｍｅ値が異なる場合、アルゴリズムは（ライン１２）、Ｉｎｉｔｉａｌ  Ｐｔｉｍｅ１がＩｎｉｔｉａｌ  Ｐｔｉｍｅ２より小さいか否かをチェックする。Ｉｎｉｔｉａｌ  Ｐｔｉｍｅ１がより小さい場合、アルゴリズムは、Ｐｔｉｍｅ１およびＰｔｉｍｅ２の可能な限り大きな値を探索する（ライン１３から２０）。それらのＰｔｉｍｅ値は、ＡＰ１およびＡＰ２の利用度の最小の合計を達成する間の新しい通話の許可を保証する。このことは、Ｐｔｉｍｅ１＝Ｉｎｉｔｉａｌ  Ｐｔｉｍｅ１に固定し、Ｐｔｉｍｅ２＝Ｉｎｉｔｉａｌ  Ｐｔｉｍｅ２に設定することによって行われる。それから、アルゴリズムは、Ｉｎｉｔｉａｌ  Ｐｔｉｍｅ１に達するまで、Ｐｔｉｍｅ２を繰り返し減算する。ｆｏｒループの各繰返しにおいて（ライン１４）、アルゴリズムは、Ｐｔｉｍｅ２の可能な限り大きな値を探索する。（Ｐｔｉｍｅ１の値を与えられる）そのＰｔｉｍｅ２値は、待ち時間制約条件を満足し、よりよい解（すなわち、ＡＰ１およびＡＰ２の利用度のより低い合計）を生み出す。
【００４９】
一方、Ｉｎｉｔｉａｌ  Ｐｔｉｍｅ２がＩｎｉｔｉａｌ  Ｐｔｉｍｅ１より小さい場合、アルゴリズムは、Ｐｔｉｍｅ２をＩｎｉｔｉａｌ  Ｐｔｉｍｅ２に固定し、Ｐｔｉｍｅ１＝Ｉｎｉｔｉａｌ  Ｐｔｉｍｅ１に設定し、Ｐｔｉｍｅ１の可能な限り大きな値を繰り返し探索する（ライン２１から３０）。そのＰｔｉｍｅ１値は、ＡＰ１およびＡＰ２の利用度の最小の合計を達成する間の新しい通話の許可を保証する。
（ＭａｘＮｅｔｗｏｒｋＣａｐ）
【００５０】
【数１０】
2009529255.tif 000015
本発明の主題は、構造的特徴および／または方法論の作用を特定する言語で記述されたけれども、添付の特許請求の範囲において定義される主題が、必ずしも上記された特定の特徴または作用に制限されないことは、理解されるべきである。むしろ、上記された特定の特徴および作用は、特許請求の範囲を実装する例示の様態として開示される。
【図面の簡単な説明】
【００５１】
【図１】図１は、例示的なパケット構造の概略図である。
【図２】図２は、適応型音声パケット化（ＡＶＰ）スキームと互換の例示的なＷＬＡＮシステムの概略図である。
【図３】図３は、図２において示されるＷＬＡＮシステムと互換のＡＶＰに対する例示的な方法のフローチャートである。
【図４】図４は、図３において示される方法と互換の例示的なＡＶＰサーバの概略図である。
【図１】
2009529255.tif 000016
【図２】
2009529255.tif 000017
【図３】
2009529255.tif 000018
【図４】
2009529255.tif 000019
【国際調査報告】
2009529255.tif 000020
2009529255.tif 000021
2009529255.tif 000022