(57)【特許請求の範囲】
【請求項１】
無線通信の方法であって、
パケットのパケットサイズおよびパケットの到来頻度の内の少なくとも１つに基づいて、前記パケットが音声ペイロードを含むのかそれとも制御情報を含むのかを判定するステップと、
少なくとも１つの前のパケットに基づいてパケット・サイズ・マスクを決定するステップと、を含み、前記パケット・サイズ・マスクが前記パケットの前記パケットサイズを決定するために使用される方法。
【請求項２】
請求項１記載の方法において、前記パケットが音声ペイロードを含むのかそれとも制御情報を含むのかを判定する前記ステップが、前記パケットがＲＴＰ（Real Time Protocol）パケットであるのかそれともＲＴＣＰ（Real Time Control Protocol）パケットであるのかを判定するステップを含む方法。
【請求項３】
請求項１記載の方法であって、前記パケット・サイズ・マスクを決定する前記ステップが、前記少なくとも１つの前のパケットに基づいて最も高い頻度のパケット・サイズを決定するステップを含んでおり、また前記パケットが音声ペイロードを含むのかそれとも制御情報を含むのかを判定する前記ステップが、前記パケットと前記パケット・サイズ・マスクとを比較することにより前記パケットが音声ペイロードを含むのかそれとも制御情報を含むのかを判定するステップを含む方法。
【請求項４】
請求項１記載の方法において、前記パケットの前記少なくとも１つのプロパティに基づいて前記パケットが音声ペイロードを含むのかそれとも制御情報を含むのかを判定する前記ステップが、前記パケットの少なくとも１つのプロパティに基づいて、アップリンクを介して伝送されるパケットが音声ペイロードを含むのかそれとも制御情報を含むのかを判定するステップを含む方法。
【請求項５】
請求項１記載の方法であって、前記パケットに関連付けられたポート番号に基づいてパケットが音声ペイロードを含むのかそれとも制御情報を含むのかを判定するステップをさらに含む方法。
【請求項６】
請求項１記載の方法であって、前記パケットが音声ペイロードを含むのかそれとも制御情報を含むのかに基づいて、前記パケットを無線ベアラに経路指定するステップを含む方法。
【請求項７】
請求項１記載の方法であって、前記パケットを前記無線ベアラを介して伝送するステップを含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、通信システムに関し、より詳細には、無線通信システムに関する。
【背景技術】
【０００２】
従来の無線通信システムは、ユーザ装置、加入者装置、およびアクセス端末などの用語でも呼ばれる１つまたは複数の移動体ユニットへの無線接続を提供するアクセス・ポイント、ノードＢ、またはアクセス・ネットワークとも呼ばれる１つまたは複数の基地局を含む。例示的な移動体ユニットは、携帯電話（cellular telephone）、ＰＤＡ（personal data assistant：携帯情報端末）、スマートフォン、テキスト・メッセージング装置、ラップトップ／ノートブック・コンピュータ、デスクトップ・コンピュータなどを含む。各基地局は、基地局に関連付けられた地理的領域またはセル中の移動体ユニットなど、１つまたは複数の移動体ユニットへの無線接続を提供することができる。例えば、基地局は、ＵＭＴＳ（Universal Mobile Telecommunication System）プロトコルに従って、セル内に位置する移動体ユニットへの無線接続を提供することができる。あるいは、基地局は、ＣＤＭＡプロトコル、ＩＥＥＥ８０２．１１プロトコル、ＩＥＥＥ８０２．１６プロトコル、ＩＥＥＥ８０２．２０プロトコル、ブルートゥース（Bluetooth）・プロトコル、および／または他のプロトコルに従って、セル内に位置する移動体ユニットへの無線接続を提供することもできる。
【０００３】
オペレーションにおいて、各移動体ユニットは、１つまたは複数の基地局と無線通信リンク、またはレグ（leg）を維持する。無線通信リンクは、通常、データおよび制御情報を伝送するための１つまたは複数のアップリンクおよび／またはダウンリンク・チャネルを含む。従来、音声トラフィックは、移動体ユニットと基地局および／または無線アクセス・ネットワークの間で持続的な通信が存在するように、回線交換無線ベアラ（bearer）を用いた無線通信を介して伝送される。しかし、乏しい無線資源の使用効率を改善するための手順が、ＡＭＲ（Adaptive Multi-Rate）技法などの進んだ音声コーディング方式で実施されている。アップリンクおよび／またはダウンリンク・チャネルを定義するために使用される多重チャネル化コード（channelization codes ）は、無線通信システムにおける最も限定された資源の１つである。例えば、ＵＭＴＳシステムでは、多重チャネル化コードは、拡散率１２８のウォルシュ符号とすることができ、その場合、１つのセルにおける単一の基地局により、多く見ても１２８の同時接続がサポートできるだけである。さらに、実際のシステムでは、干渉による制限、ソフト・ハンドオーバによるオーバヘッドなどによって、通常、同時接続数は減少する。
【０００４】
ＶｏＩＰ（Voice over Internet Protocol）システムは、インターネットなどのパケット交換ネットワークを用いてデータおよび／または制御情報を送信する。ＶｏＩＰシステムでは、音声データ・フレームは、インターネット・プロトコル・データ・フレームに組み込まれている。２つの異なるタイプのパケットが通常送信される。すなわち、音声ペイロードを搬送するＲＴＰ（Real Time Protocol：実時間プロトコル）パケット、および同期化情報、複数の当事者間での会議通話に使用できる情報などの制御情報を搬送するＲＴＣＰ（Real Time Control Protocol：実時間制御プロトコル）である。ＲＴＰパケットおよびＲＴＣＰパケットは、インターネット・プロトコル・レベルで多重化することができるが、その２タイプのパケットのサービス品質（quality-of-service）要件は異なる。ＲＴＰパケットは、比較的厳しい遅延制約を受ける（すなわち、遅延を許容しない）が、損失に対しては比較的許容することができる。反対に、ＲＴＣＰパケットは、遅延を許容するが、損失に対して非常に影響を受けやすい。さらに、ＲＴＰパケットは、一般に、高い頻度でかつ／または周期的に送信され、また予測可能なサイズを有するが、一方、ＲＴＣＰパケットは、時々かつ／またはばらばらに送信され得るが、より大きくかつ／または変動するサイズを有する。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
３ＧＰＰ（Third Generation Partnership Project）は、ＲＴＰとＲＴＣＰパケット・フローの間を区別するのに使用できる機構を定義することを試みてきており、それにより、２つのパケット・フローを、その異なるプロパティを考慮した異なる無線ベアラに割り当てることが可能となる。具体的には、ＲＬＣ（Radio Link Control）プロトコル・レイヤの異なるオペレーション・モードを使用することができる。すなわち、残存パケット損失（residual packet loss）率が増加する代わりに少ない遅延ジッタを提供するＵＭ（Unacknowledged Mode）ＲＬＣをＲＴＰフローに使用することが可能であり、また大きい遅延ジッタの代わりに低い残存パケット損失率を提供できるＡＭ（Acknowledged Mode）ＲＬＣをＲＴＣＰフローに使用することが可能である。しかし、２つのパケット・フローの間を区別するための受け入れ可能な技法はまだ提案されていない。ＲＴＰとＲＴＣＰパケット・フローの間を区別するための２つの提案された機構、すなわちＲＴＣＰパケットを完全に除去すること、およびＵＤＰ（User Datagram Protocol）ポート番号またはパケット・タイプ・へッダ・フィールドを用いてフロー相互間を区別することは信頼性がないと見なされ、３ＧＰＰによって拒否されている。
【課題を解決するための手段】
【０００６】
本発明は、前述の１つまたは複数の問題の影響に対処することを対象とする。以下では、本発明のいくつかの態様の基本的な理解を提供するために、本発明の簡略化した要約を提供する。その要約は、本発明を網羅的に概観するものではない。それは、本発明の主要なまたは重要なエレメントを識別するものではなく、あるいは本発明の範囲を示すものでもない。その唯一の目的は、後に論ずる、より詳細な説明に対する前置きとして、いくつかの概念を簡略化した形で提示することである。
【０００７】
本発明の一実施形態では、無線通信のための一方法を提供する。本方法は、パケットの少なくとも１つのプロパティに基づいて、パケットが音声ペイロードを含むのかそれとも制御情報を含むのかを判定することを含む。
本発明は、添付の図面と併せて以下の説明を参照することにより理解することができる。図面中、同様の参照番号は、同様のエレメントを識別する。
【発明を実施するための最良の形態】
【０００８】
本発明は、様々な変更形態および代替形態が可能であるが、その特有の諸実施形態を、例として図面で示し本明細書で詳細に説明する。しかし、特有の実施形態に関する本明細書中の説明は、開示された特定の形態に本発明を限定するものではなく、その反対に、添付の特許請求の範囲で定義された本発明の趣旨および範囲に含まれるすべての変更形態、等価な形態、および代替形態をカバーすることを意図していることを理解されたい。
【０００９】
本発明の例示的な諸実施形態を以下に説明する。明確化のために、実装形態のすべての機能を本明細書中で説明していない。かかる実際の実施形態の開発においては、開発者特有の目標を達成するために、実装形態ごとに異なるシステムおよびビジネスに関連する制約の遵守など、数多くの実装形態特有の決定を行わなければならないことを当然理解されよう。さらに、このような開発努力は、複雑で時間のかかることかもしれないが、それにもかかわらず、本開示の利益を受ける当業者が実施する所定の手順であることが理解されよう。
【００１０】
本発明の部分、およびそれに対応する詳細な説明は、ソフトウェア、またはコンピュータ・メモリ内のデータ・ビットに対するオペレーションのアルゴリズムおよび記号表現によって提示される。それらの記述および表現により、当業者は、自分の仕事の実体を他の当業者に効果的に移送できる。本明細書で、また一般に使用されるように、アルゴリズムは、所望の結果に導く一連の自己一貫性のある諸ステップで表される。その諸ステップは、物理量の物理的な処理を必要とするものである。必ずしも必要ではないが、普通、それらの量は、記憶され、転送され、組み合わされ、比較され、またその他の形で処理されることが可能な光学的、電気的、磁気的信号の形を取る。主として共通利用のために、時には、それらの信号をビット、値、エレメント、記号、文字、語句、数字などと呼ぶのが便利なことが分かっている。
【００１１】
しかし、これらのおよび類似の用語は、すべて適切な物理量と関連付けられるべきであり、それらは、その量に適用された便宜的なラベルに過ぎないことに留意されたい。他に特に述べられていない限り、あるいはその議論から明らかではない限り、「処理すること（processing）」、「コンピュータ処理すること（computing）」、「計算すること（calculating）」、「判定すること（determining）」、または「表示すること（displaying）」などの用語は、コンピュータ・システムのレジスタおよびメモリ内の物理量、電子量として表されるデータを処理し、かつそのデータを、コンピュータ・システム・メモリ、レジスタ、もしくは他のこのような情報ストレージ、あるいは伝送装置、表示装置内の物理量として同様に表される他のデータに変換するコンピュータ・システムまたは同様の電子コンピューティング装置のアクションおよびプロセスを指す。
【００１２】
本発明のソフトウェアで実施される態様はまた、通常、プログラム記憶媒体の何らかの形態上にエンコードされ、または伝送媒体の何らかのタイプを介して実施されることに留意されたい。プログラム記憶媒体は、磁気的な物（例えば、フロッピー（登録商標）・ディスクまたはハード・ドライブ）、または光学的な物（例えば、コンパクト・ディスク読出し専用メモリ、すなわち「ＣＤ−ＲＯＭ」）とすることができ、また読出し専用またはランダム・アクセスとすることもできる。同様に、伝送媒体は、ツイストペア線、同軸ケーブル、光ファイバ、または当技術分野で知られている何らかの他の適切な伝送媒体とすることができる。本発明は、所与の実装形態のその態様によって限定されることはない。
【００１３】
次に、添付図を参照して本発明を説明する。説明目的のためだけであり、当業者には周知の詳細により本発明をあいまいにすることのないように、様々な構造、システム、および装置が、図面中で概略的に示されている。そうではあるが、添付図面は、本発明の例示的な諸実施例を記述し説明するために含まれている。本明細書で使用される語および句は、当業者によるこれらの語および句に対する理解と一致した意味を有するものと理解され解釈されるべきである。どんな用語または句の特殊な定義、すなわち、当業者によって理解されている通常のまた慣例の意味とは異なる定義も、本明細書における用語または句の一貫した使用によって暗示されることを意図するものではない。用語または句が、特殊な意味、すなわち、当業者によって理解されている以外の意味を有するように意図されている場合、そのような特殊な定義は、その用語または句に対する特殊な定義を直接かつ明確に提供する定義的方法で本明細書中で明確に記載するものとする。
【００１４】
次に図１を参照すると、通信システム１００の例示的な一実施形態が示されている。その例示的な実施形態では、通信システム１００は、ネットワーク制御装置１１０に通信可能に結合されたネットワーク１０５を含む。図１には単一のネットワーク制御装置１１０
が示されているが、本開示の利益を受ける当業者であれば、任意の数のネットワーク制御装置１１０をネットワーク１０５に通信可能に接続できることを理解されたい。例示の実施形態では、通信システム１００は、ＵＭＴＳ（Universal Mobile Telecommunication System）プロトコルに従って動作する。したがって、ネットワーク１０５はまた、コア・ネットワーク１０５とも呼ばれ、ネットワーク制御装置１１０は、ＲＮＣ（Radio Network Controller）１１０とすることができる。しかし、当業者であれば、本発明が、ＵＭＴＳプロトコルに従って動作する通信システム１００に限定されないことを理解されたい。代替の実施形態では、通信システム１００は、ＧＳＭ（Global System for Mobile communication）プロトコル、ＣＤＭＡもしくはＣＤＭＡ２０００（符号分割多元接続）プロトコル、３Ｇ１Ｘ―ＥＶＤＯプロトコル、１つまたは複数のＩＥＥＥ８０２規格に基づくプロトコル、ブルートゥース・プロトコルなどのプロトコルに従って動作することもできる。さらに、代替の実施形態では、ネットワーク１０５および／またはネットワーク制御装置１１０は、１つまたは複数の有線通信システムに従って動作する有線接続を含むことができる。
【００１５】
ネットワーク制御装置１１０は、１つの基地局１１５に通信可能に結合されている。しかし、本開示の利益を受ける当業者であれば、ネットワーク制御装置１１０は、任意の数の基地局１１５に結合できることを理解されたい。ネットワーク１０５、ネットワーク制御装置１１０、および／または基地局１１５は、前に論じたプロトコルなど、１つまたは複数の無線通信プロトコルによる無線接続を提供する。ＵＭＴＳプロトコルに従って動作する実施形態では、ネットワーク１０５、ネットワーク制御装置１１０、および１つまたは複数の基地局１１５は、総称的に、ＵＴＲＡＮ（UMTS Terrestrial Radio Access Network）と呼ぶことができる。様々な代替の実施形態では、ＵＴＲＡＮはまた、ネットワーク１０５、ネットワーク制御装置１１０、および／または基地局１１５の間で１つまたは複数のインターフェースを含むこともできる。
【００１６】
通信システム１００は、１つまたは複数の移動体ユニット１２０（１〜３）を含む。明確化のために、移動体ユニット１２０（１〜３）を個々にまたはサブセット中で参照するとき添字（１〜３）を使用し、移動体ユニット１２０を総称的に参照するとき添字（１〜３）は削除できるものとする。同じ規則を、以下で参照する他の番号を付したエレメントに適用することができる。例示的な移動体ユニット１２０は、それだけに限らないが、携帯電話（mobile phone）１２０（１）、ＰＤＡ（personal data assistant：携帯情報端末）１２０（２）、スマートフォン（図示せず）、テキスト・メッセージング装置（図示せず）、ラップトップ・コンピュータ１２０（３）、デスクトップ・コンピュータ（図示せず）などを含む。明確化のために、３台の移動体ユニット１２０だけを図１に示す。しかし、本開示の利益を有する当業者であれば、通信システム１００は、任意のタイプの任意の数の移動体ユニット１２０を含むことができることを理解されたい。
【００１７】
移動体ユニット１２０は、ネットワーク制御装置１１０を介してネットワーク１０５へのアクセスを提供できる基地局１１５との１つまたは複数の無線通信リンク１２５を形成することができる。例示の実施形態では、無線通信リンク１２５は、１つまたは複数のアップリンクおよび１つまたは複数のダウンリンクを含むことができる。無線通信リンク１２５はまた、１つまたは複数の無線ベアラと関連付けることのできる１つまたは複数のチャネルを含むことができる。無線ベアラと関連付けられたパケット・フローは、様々なＱｏＳ（サービス品質）基準に従って処理することができる。例えば、ある無線ベアラは、残存パケット損失率が増加する代わりに、少ない遅延ジッタを提供するＵＭ（Unacknowledged Mode）で動作するＲＬＣ（Radio Link Control）プロトコル・レイヤを使用することができる。他の実施例では、他の無線ベアラは、遅延ジッタが多い代わりに、低い残存パケット損失率を提供するＡＭ（Acknowledged Mode）で動作するＲＬＣ（Radio Link Control）プロトコル・レイヤを使用することができる。
【００１８】
無線通信リンク１２５を介して基地局１１５と移動体ユニット１２０の間で伝送されるパケットは、様々なプロパティを有することができ、したがって、様々なサービス品質基準と関連付けられるべきである。例えば、ＲＴＰ（Real-time Transport Protocol）パケットなどの音声ペイロードを含むパケットは、比較的厳しい遅延制約を受けるはずである（すなわち、遅延を許容できない）が、損失に対しては比較的許容することができる。他の実施例では、ＲＴＣＰ（Real-time Transport Control Protocol）パケットなどの制御情報を含むパケットは、比較的遅延を許容できるが、音声ペイロードを含むパケットと比較すると損失に対して比較的影響を受けやすい。したがって、無線通信システム１００の一部が、無線通信リンク１２５のうちの１つを介して送信すべきパケットが、音声ペイロードまたは制御情報を含んでいるかどうかを判定できるとよい。一実施形態では、パケット・サイズおよび／または関連するＵＤＰ（User Datagram Protocol）ポート番号など１つまたは複数のパケット・プロパティを、パケットが音声ペイロードまたは制御情報を含んでいるかどうかを判定するのに使用することができる。次いで、以下で詳細に論ずるように、その判定に基づいて選択された無線ベアラにパケットを経路指定（またはマップ）することができる。
【００１９】
図２は、プロトコル・スタック２００の例示的な一実施形態を概念的に示す。例示の実施形態では、プロトコル・スタック２００は、コーダ／デコーダ（コーデック）２０１、ＲＴＰ（Real-time Transport Protocol）／ＲＴＣＰ（Real-time Control Protocol）レイヤ２０５、ＵＤＰ（User Datagram Protocol）レイヤ２１０、ＩＰ（インターネット・プロトコル）レイヤ２１５、ＰＤＣＰ（Packet Data Convergence Protocol）レイヤ２２５、ＲＬＣ（Radio Link Control）プロトコル・レイヤ２３０を含む。代替の実施形態では、ＲＴＰ／ＲＴＣＰレイヤ２０５は、別個のレイヤではなく、他のプロトコル・レイヤ、アプリケーション、または変換エンティティの一部として実装することもできる。レイヤ２０１、２０５、２１０、２１５、２２５、２３０の動作および／または実装形態は、当業者には知られており、明確化のために、本発明にとって重要なレイヤ２０１、２０５、２１０、２１５、２２５、２３０の動作および／または実装形態の部分だけをここで説明するものとする。さらに、本開示の利益を有する当業者であれば、プロトコル・スタック２００は、ＵＭＴＳ通信システムで使用できる１つの例示的なスタックに過ぎないことを理解されたい。しかし、代替の実施形態では、他のプロトコル・スタックおよび／または他の通信プロトコルを使用することもできる。
【００２０】
コーデック２０１は、ＲＴＰ／ＲＴＣＰレイヤ２０５に情報を提供することができる。一実施形態では、コーデック２０１によって提供される情報は、エンコードされた音声または他の音響情報を含むことができる。例えば、コーデック２０１は、ＡＭＲ（Advanced Multi-Rate）方式に従って、音声情報をエンコードする音声コーダ／デコーダとすることができる。ＲＴＰ／ＲＴＣＰレイヤ２０５は、そのエンコードされた情報をＲＴＰパケットにカプセル化することができ、またＲＴＣＰパケットを用いて制御情報を追加することができる。ＲＴＰおよびＲＴＣＰパケットは共に、ＵＤＰレイヤ２１０、およびＩＰレイヤ２１５を用いて移送することができる。コーデック２０１によって形成されたパケットのサイズは、コーディング方式、ならびにそのパケットが音声情報を含むかそれとも無音情報を含むかに依存することができる。例えば、音声コーディング／デコード方式が変化しない期間中、ＡＭＲ方式により、音声に関係する情報に対して２つの異なるサイズのパケットが作成される。ＡＭＲ音声ペイロードを含むパケットは、選択されたバイト数を有する音声フレームと、６０バイトのＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダを含む。無音期間を示す情報を含むパケットは、選択されたバイト数を有するＡＭＲ  ＳＩＤ（silence frame：無音フレーム）ペイロードと、６０バイトのＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダを含む。異なるＡＭＲコーディング／デコード・レートに対するＲＴＰペイロード・サイズ（ビットで）を表１に一覧表示する。一実施形態では、ＡＭＲ  ＳＩＤ（silence frame）ペイロードを含むパケットのサイズを、ＡＭＲコーディング／デコード・レートから独立させることができる。
【表１】
0005389316.tif 000002
【００２１】
ＲＴＣＰ制御情報を含むパケットは、ＲＴＰ音声関連情報を含むパケットよりも大幅に大きくなり得る。例えば、制御情報を含むＲＴＣＰパケットのサイズは、音声ペイロードを含むＲＴＰパケットのサイズの数倍とすることができる。典型的なＲＴＣＰパケットのサイズは、約１００バイトから約１０００バイト以上の範囲に及ぶことができる。
【００２２】
ＩＰパケットは、ＰＤＣＰレイヤ２２５中またはその上位に実装できるルーティング・エンティティ２３５に提供することができる。ルーティング・エンティティ２３５は、パケットの１つまたは複数のプロパティを用いて、パケットが音声ペイロードを含むのかそれとも制御情報を含むのかを判定することができる。一実施形態では、ルーティング・エンティティ２３５は、パケットのサイズに基づいて、パケットが音声ペイロードを含むのかそれとも制御情報を含むのかを判定することができる。例えば、パケットが、１２．２キロビット／秒のＡＭＲでエンコードされたとき、ＲＴＰパケットなどの音声ペイロードを含むパケットが、約２０ｍｓの期間で、周期的にルーティング・エンティティ２３５に到来する。到来したパケットは、それが音声情報を含む場合、２つのサイズのうちの一方であるはずである。すなわち、音声フレームを含むパケットは、サイズが（３２バイトの１２．２ｋｂｓ  ＡＭＲ  ＲＴＰペイロードに６０バイトのＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダを加えて）９２バイトになり、ＡＭＲ  ＳＩＤフレームなどの無音情報を含むパケットは、（７バイトのＡＭＲ  ＳＩＤ  ＲＴＰペイロードに６０バイトのＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダを加えて）６７バイトのパケット・サイズを有することになる。制御情報を含むパケットは、上記のように、はるかに大きくなるはずである。したがって、音声情報に関連する２つのサイズに相当するパケット・サイズを有する到来パケットは、音声情報を含むパケットとして識別することができる。より大きいパケット・サイズ、例えば、選択された閾値を超えるパケット・サイズを有して到来するパケットは、制御情報を含むパケットとして識別することができる。
【００２３】
いくつかの実施形態では、コーディング／デコード方式を伝送中に変更することができる。例えば、コーデック２０１は、始めに１２．２キロビット／秒のデータ転送レートを使用することができる。次いで、コーデック２０１は、４．７５キロビット／秒などの異なる転送レートに変更することができる。コーディング／デコード方式を変更することは、音声ペイロードおよび／または制御情報に関連するパケット・サイズが変更される結果になり得る。様々のコーディング／デコード方式に関連付けられたいくつかの例示的なＲＴＰペイロード・サイズ（ビットで）を表１に示す。したがって、ルーティング・エンティティ２３５は、受信したパケット・サイズを、音声ペイロードを含むパケットおよび／または制御情報を含むパケットと関連付けることができる。一実施形態では、ルーティング・エンティティ２３５は、１つまたは複数の前に受信したパケットのサイズを示す情報にアクセスし、その１つまたは複数の前に受信したパケットのサイズに基づいて、音声ペイロードおよび／または制御情報に関連付けられたパケット・サイズを決定する。例えば、ルーティング・エンティティ２３５は、受信したパケット・サイズおよび／またはパケットの到来頻度の統計的分析を用いて、音声ペイロードに関連付けられたパケット・サイズ、ＳＩＤペイロードに関連付けられたパケット・サイズ、および／または制御情報に関連付けられたパケット・サイズ閾値を決定することができる。
【００２４】
ルーティング・エンティティ２３５はまた、パケットに関連付けられたＵＤＰポート番号をモニタすることができる。一実施形態では、音声ペイロード（例えば、ＲＴＰパケットに関連付けられたＵＤＰポート番号は、制御情報（例えば、ＲＴＣＰパケット）に関連付けられたＵＤＰポート番号とは異なるものとすることができる。次いで、ルーティング・エンティティ２３５は、受信したパケット・サイズおよび／またはパケットの到来頻度を用いて、音声ペイロードおよび制御情報に対するＵＤＰポート番号を識別することができる。一実施形態では、ルーティング・エンティティ２３５は、音声ペイロードを含むパケットおよび／または制御情報を含むパケットを識別するために、その識別されたＵＤＰポート番号を使用する。例えば、ルーティング・エンティティ２３５は、到来するパケットのヘッダにアクセスして、パケットに割り当てられているＵＤＰポート番号を識別し、それによって、パケットが音声ペイロードを含むのかそれとも制御情報を含むのかを判定することができる。
【００２５】
次いで、ルーティング・エンティティ２３５は、そのパケットを、異なるＰＤＣＰエンティティ２２５およびＲＬＣエンティティ２３０によって表される異なる無線ベアラに提供することができる。異なるＲＬＣエンティティ２３０は、ＵＭ（Unacknowledged Mode）またはＡＭ（Acknowledged Mode）などの異なるモードで動作することができる。一実施形態では、ＩＰパケットは、パケットが音声ペイロードを含むのかそれとも制御情報を含むのかに基づいて、無線ベアラに割り当てられる。例えば、ＲＴＰフロー中のパケットなどの音声ペイロードを含むパケットは、残存パケット損失率が高くなる代わりに、少ない遅延ジッタを提供することができるＵＭ（Unacknowledged Mode）ＲＬＣ無線ベアラ２３５に提供することができる。他の実施形態では、ＲＴＣＰフロー中のパケットなどの制御情報を含むパケットは、より多い遅延ジッタの代わりに、低い残存パケット損失率を提供できるＡＭ（Acknowledged Mode）ＲＬＣ無線ベアラ２４０に提供することができる。ＰＤＣＰエンティティ２２５は、伝送のためにパケットを圧縮できるＲｏＨＣ（Robust Header Compression：ロバスト・ヘッダ圧縮）などの圧縮方式を含むことができる。
【００２６】
図３は、データ・パケットを経路指定するための方法３００の例示的な一実施形態を概念的に示す。例示の実施形態では、１つまたは複数のパケットがアクセスされる（３０５で）。パケットにアクセスすることは、他のロケーションからパケットを受信すること、バッファまたは他のメモリ中に記憶されたパケットにアクセスすること、ならびにパケット・ヘッダなど、パケットの部分にアクセスすることを含むことができる。次いで、アクセスされたパケットが音声ペイロードを含んでいるかどうかが判定される（３１０で）。例えば、１つの最も頻度の高いパケット・サイズ、または複数の比較的頻度の高いパケット・サイズを決定することにより、パケット・サイズ・マスクを決定することができる。一実施形態では、前に詳細に論じたように、音声ペイロードを含むパケットおよび／または無音期間を示すペイロードを含むパケットに関連付けられたパケット・サイズと、パケット・サイズを比較することによって、音声ペイロードを含むパケットを識別することができる（３１０で）。例えば、音声ペイロードを含むパケットは、パケット・サイズ・マスクを用いて識別することができる（３１０で）。あるいは、音声ペイロードを含むパケットは、パケット・ヘッダ中で示されたＵＤＰポート番号を、音声ペイロードを含むパケットに関連付けられたＵＤＰポート番号と比較することによって識別することができる（３１０で）。パケットが音声ペイロードを含む場合、そのパケットを、ＵＭ（Unacknowledged Mode）ＲＬＣ無線ベアラなどの適切な無線ベアラに経路指定することができる（３１５で）。
【００２７】
パケットが音声ペイロードを含まない場合、アクセスしたパケットが制御情報を含むかどうかを判定することができる（３２０で）。一実施形態では、前に詳細に論じたように、制御情報を含むパケットは、パケット・サイズを、制御情報を含むパケットに関連付けられたパケット・サイズ（またはパケット・サイズ閾値）と比較することによって識別することができる（３２０で）。例えば、制御情報を含むパケットは、パケット・サイズ・マスクを用いて識別することができる（３２０で）。あるいは、制御情報を含むパケットは、パケット・ヘッダ中に示されるＵＤＰポート番号を、制御情報を含むパケットに関連付けられたＵＤＰポート番号と比較することによって識別することができる（３２０で）。パケットが制御情報を含む場合、ＡＭ（Acknowledged Mode）ＲＬＣ無線ベアラなどの適切な無線ベアラに経路指定することができる（３２５で）。パケットが音声ペイロードまたは制御情報を含んでいない場合、そのパケットは廃棄される（３３０で）。
【００２８】
図４は、音声ペイロードまたは制御情報を含むパケットをパケットのプロパティと関連付ける方法４００の例示的な一実施形態を概念的に示す。例示の実施形態では、１つまたは複数のパケットにアクセスすることができる（４０５で）。例えば、１つまたは複数の前に受信したパケットにアクセスすることができる（４０５で）。あるいは、１つまたは複数の前に受信したパケットと関連付けられた情報にアクセスすることができる（４０５で）。例えば、１つまたは複数のパケットに関連付けられたパケット・サイズは、バッファまたはメモリに記憶され、次いで、そのバッファまたはメモリにアクセスすることができる（４０５で）。次いで、アクセスされたパケットのパケット・サイズを、アクセスされたパケット、またはアクセスされたパケットのうちの１つまたは複数に関連付けられた情報に基づいて決定することができる（４１０で）。次いで、前に詳細に論じたように、１つまたは複数のパケット・サイズを、音声ペイロードを含むパケットおよび／または制御情報を含むパケットと関連付けることができる（４１５で）。一実施形態では、前に詳細に論じたように、ＵＤＰポート番号などの１つまたは複数のポート番号を、音声ペイロードを含むパケットおよび／または制御情報を含むパケットと関連付けることができる（４２０で）。
【００２９】
コーダ／デコーダの状態もまたモニタすることができる。コーダ／デコーダの状態が変化した場合（４２５で）、パケットがアクセスされ（４０５で）、１つまたは複数のパケット・サイズおよび／またはポート番号を、音声ペイロードおよび／または制御情報と関連付けるために使用することができる（４１５および／または４２０で）。一実施形態では、コーダ／デコーダの状態が変化しない限り、何もアクションを取らなくてよい（４２５で）。しかし、代替の実施形態では、追加のパケットに継続的にまたは周期的にアクセスし（４０５で）、１つまたは複数のパケット・サイズおよび／またはポート番号を、音声ペイロードおよび／または制御情報と関連付けるために、そのパケットを使用することができる（４１５および／または４２０で）。例えば、受信したパケットそれぞれにアクセスし（４０５で）、それを使用して、１つまたは複数のパケット・サイズおよび／またはポート番号と音声ペイロードおよび／または制御情報との関連付けを行い（４１５および／または４２０で）、パケット・サイズおよび／またはポート番号と音声ペイロードおよび／または制御情報との関連付けの統計的有意性を改善することができる。
【００３０】
音声ペイロードを含むパケットと、制御情報を含むパケットの間を区別するための上記技法の諸実施形態は、従来の慣行に対していくつかの利点を提供することができる。例えば、ＲＴＰパケットは、ＲＴＣＰパケットから確実に区別することができ、したがって、それを、２タイプのパケットに対して適切に構成された無線ベアラに経路指定することができる。したがって、ＶｏＩＰアプリケーションをＵＴＲＡＮ中でより効率的に処理することができる。さらに、上記の技法は、上位レイヤからの暗号化によって影響されない。上記の方法で、適切な無線ベアラにパケットを割り当てることはまた、アップリンクおよび／またはダウンリンクの干渉を低減し、したがって、乏しいアップリンクおよび／またはダウンリンクの無線資源を保存することができる。例えば、比較的低いデータ・レートを有する無線ベアラを提案する本方法を用いて割り振ることができる。その結果、より高いデータ・レートに対してチャネル割振り予測を試みる技法よりも、アップリンク・チャネル・エレメントの割振り不足がかなり高くなる可能性がある。音声ペイロードおよび制御情報を含むパケットを識別するためにＵＤＰポート番号を利用する実施形態はまた、コール・フローにおける差別化の信頼性を高めることができる。
【００３１】
上記で開示された特定の諸実施形態は例示的なものに過ぎないが、本明細書による教示の利益を受ける当業者にとって明らかな、異なるが等価な方法で、本発明を変更し実施することが可能である。さらに、以下の特許請求の範囲に記載したもの以外には、本明細書に示した構成または設計の詳細に対して限定することを意図していない。したがって、上記で開示された特定の諸実施形態を改変または変更することが可能であり、またそのような変形形態がすべて、本発明の範囲および趣旨に含まれると見なされることは明らかである。したがって、本明細書で求められている保護は、頭記の特許請求の範囲に記載されている。
【図面の簡単な説明】
【００３２】
【図１】本発明による、通信システムの例示的な一実施形態を示す図である。
【図２】本発明による、プロトコル・スタックの例示的な一実施形態を概念的に示す図である。
【図３】本発明による、データ・パケットを経路指定する方法の例示的な一実施形態を概念的に示す図である。
【図４】本発明による、音声ペイロードまたは制御情報を含むパケットを、そのパケットのプロパティと関連付ける方法の例示的な一実施形態を概念的に示す図である。
【図１】
0005389316.tif 000003
【図２】
0005389316.tif 000004
【図３】
0005389316.tif 000005
【図４】
0005389316.tif 000006