JP2009538040A - ジッタバッファを用いたｖｉｏｐパケットの通信及び処理のための方法及びシステム - Google Patents

Abstract

ＶＯＩＰパケットをジッタバッファを用いて通信及び処理する方法及びシステムが提供される。本方法は、複数の異なる基地局（１１０、２２０）からＶＯＩＰパケットを受信するステップ、受信したＶＯＩＰパケットをジッタバッファにバッファリングするステップ、及びジッタバッファからＶＯＩＰパケットを再生するステップを含む。複数の基地局から受信したＶＯＩＰパケットは同一のＶＯＩＰ送信と関係している。

Description

セルラ通信ネットワークは通常、無線又は有線の接続で結合され、異なるタイプの通信チャネルを介してアクセスされる種々の通信ノードを含む。通信ノードの各々は、通信チャネル上でそれぞれ送受信されるデータを処理するそれぞれのプロトコルスタックを含む。通信システムのタイプによって、種々の通信ノードの動作及び構成が異なり、異なる名称で呼ばれることがある。そのような通信システムは、例えば、符号分割多重アクセス２０００（ＣＤＭＡ２０００）システム、ユニバーサル移動体通信システム（ＵＭＴＳ）等である。

第３世代無線通信プロトコル標準（例えば、３ＧＰＰ−ＵＭＴＳ、３ＧＰＰ２−ＣＤＭＡ２０００等）はアップリンク（ＵＬ）における専用トラフィックチャネル（例えば、移動局（ＭＳ）又はユーザ機器（ＵＥ）から基地局（ＢＳ）又はノードＢへの通信フロー）を採用することがある。専用チャネルはデータ部分（例えば、ＵＭＴＳリリース４／５プロトコルによる専用物理データチャネル（ＤＰＤＣＨ）、ＣＤＭＡ２０００プロトコルによる基本チャネル又は補助チャネル等）及び制御部分（例えば、ＵＭＴＳリリース４／５プロトコルによる専用物理制御チャネル（ＤＰＣＣＨ）、ＣＤＭＡ２０００プロトコルによるパイロット／電力制御サブチャネル等）を含む。

図１はＵＭＴＳプロトコルに従って動作する従来の無線通信システム１００を示す。図１によると、無線通信システム１００は多数のノードＢを含み、各々はそれぞれのカバレッジエリア内のユーザ機器ＵＥ１０５の通信ニーズに対してサービングする。ノードＢ１１０は無線ネットワークコントローラ（ＲＮＣ）１２０に接続される。ＲＮＣ１２０は、例えばＵＭＴＳの場合は、モバイルスイッチングセンター（ＭＳＣ）（不図示）及びサービングＧＰＲＳサポートノード（ＳＧＳＮ）（不図示）を含むコアネットワーク（ＣＮ）１３０に接続される。ＲＮＣ１２０は、ＭＳＣ及びＳＧＳＮを関与させることなくハンドオーバーを自動的に管理するような機能を取り扱う特定のセル及びデータを扱う。ＭＳＣ及びＳＧＳＮは、呼及び／又はデータを無線アクセスネットワーク（ＲＡＮ）又は、例えば、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）(不図示）、ポリシー決定機能（ＰＲＦ）（不図示）及びアプリケーション機能（ＡＦ）（不図示）を含むＣＮ１３０にルーティングする。

図２はＣＤＭＡ２０００・１ｘＥＶ−ＤＯプロトコルに従って動作する従来の無線通信システムを示す。図２によると、無線通信システム２００は多数の基地送受信局（ＢＴＳ）２２０を含み、各々はそれぞれのカバレッジエリア内の移動局（ＭＳ）２０５の通信ニーズに対してサービングする。ＢＴＳ２２０はＲＣＮ２１５に接続される。ＲＮＣはコアネットワーク（ＣＮ）２３０に接続され、それはパケット・データ・サービング・ノード（ＰＤＳＮ）（不図示）を含み、ホーム認証、許可及び会計サーバ（ＡＡＡ）（不図示）に接続される。従来の無線通信システム２００のＢＴＳ２２０及びＲＣＮ２１５は、従来の無線通信システム１００にあるそれぞれの対応部分であるノードＢ１１０及びＲＣＮ１２０と同様に機能する。同様に、無線通信システム２００のＰＤＳＮは無線通信システム１００のＧＧＳＮ及びＳＧＳＮと同様に機能する。

従来的には、高速データ（ＨＳＤＰＡ、ＥＶ−ＤＯ）の送信は単一のＢＴＳ２２０又はノードＢ１１０を介して行われる。高速データの送信は従来的には各ＢＴＳ２２０又はノードＢ１１０の各々でのスケジューリングを要し、ＢＴＳ２２０又はノード１１０間のスケジューリングは同期されないので、高速データは複数の基地受信局ＢＴＳ２２０から単一のＭＳ２０５に、又は複数のノードＢ１１０から単一のＵＥ１０５には送信されない。

逆に、データチャネル（ＤＣＨ）トラフィック（例えばボイスフレーム）は、複数の基地局ＢＴＳ２２０又はノードＢ１１０からボイスフレームを送信するタイミングがほぼ同じである限り、複数の基地局ＢＴＳ２２０又はノードＢ１１０から送信され得る。

ＶＯＩＰフレームを送信するために使用するネットワークはパケットの宛先への到着に種々のネットワーク遅延をもたらす。この種々の遅延はジッタと言われる。ジッタは、ＱＯＳ又はＦＩＦＯに基づくパケットの優先度付けをするルーター内の待ち行列；ネットワーク輻輳における急激な増加又は減少；ＬＡＮ衝突；等のいくつかの理由のために起こる。

ジッタに起因する問題を避けるために、ＶＯＩＰフレームを処理するように設計されたＭＳ２０５又はＵＥ１０５のような従来の末端システムはジッタバッファを含む。ジッタバッファは、ＶＯＩＰフレームを待ち行列に入れ、ＶＯＩＰフレームをフレームのソースによって生成されたのと同じ時間間隔で中継することによってジッタに起因する問題を軽減する。

ジッタバッファに蓄積されたＶＯＩＰフレームは、ＲＴＰヘッダに含まれる次の：タイムスタンプフィールド（音声フレームがいつユーザに再生されるかを示す）；及びシーケンス番号フィールド（本技術においてよく知られるように、各送信音声フレームに対して増分され、ジッタバッファコントローラによってＶＯＩＰフレームの再シーケンスを可能とする）のフィールドを用いてジッタバッファコントローラによって処理される。

従来の装置では、ジッタバッファに蓄積されたＶＯＩＰフレームをプレイバックするためにジッタバッファのプレイバック機構が使用される。プレイバック機構はプレイバック時間に待ち行列の先頭にあるパケットのシーケンス番号及びタイムスタンプをチェックする。プレイバック機構はプレイバック時間中、待ち行列パケットを一通り処理し、各パケットを再生し、又はパケットを除去し「消失パケットプレイバック」を置き換える。例えば、プレイバック機構によって処理されているパケットがシーケンス番号に基づいて決定される「想定されるパケット」である場合には、パケットが再生され、一方、パケットがシーケンス番号に基づいて決定される「想定されるパケット」でない（即ち、次のパケットのシーケンス番号が再生されるべきパケットのシーケンス番号よりも大きい）場合には、「パケット消失プレイバック」機構がそのパケットの代替として使用される。ジッタバッファ内で待ち行列に入れられたパケットの全てがプレイバック機構によって処理されると、プレイバック機構は次のプレイバック時間が来るまで停止する。

本技術でよく知られるように、ジッタバッファの長さは静的又は動的なものであり、それはベンダの実施形態による。さらに、本技術で周知のように、ジッタバッファの長さは下記のように妥協の結果となる。

例えば、ジッタバッファの長さが短すぎる場合、ジッタバッファは充分なジッタを扱えず、ジッタバッファが満杯であるのでパケットは廃棄される。一方、ジッタバッファの長さが長すぎる場合、ジッタバッファは過度の遅延に陥り、ＶＯＩＰフレームを用いる会話を成立させるのに適さない。従来の長さのジッタバッファは通常、リアルタイムデータに値する約２０〜８０ミリ秒に相当する多数のフレームをバッファリングする。

本発明の１以上の実施例はジッタバッファを用いる複数のＢＴＳ又はノードＢからのＶＯＩＰフレームを処理する方法に向けられる。

本発明の実施例はＶＯＩＰパケットを処理する方法を提供する。その方法は、複数の異なる基地局からＶＯＩＰパケットを受信するステップ、その受信したＶＯＩＰパケットをバッファリングするステップ、及びそのバッファリングされたＶＯＩＰパケットを再生するステップを含む。受信ＶＯＩＰパケットは複数の基地局から送信される同じＶＯＩＰ送信に関係する。

本発明の実施例によると、ＶＯＩＰパケットの各々は時間スタンプ及びフレームシーケンス番号を含む。

本発明の実施例によると、本方法はまた、時間スタンプに基づいてＶＯＩＰパケットがしきい値時間点の後に受信されたか、及びＶＯＩＰパケットのフレームシーケンス番号と以前にバッファリングされたＶＯＩＰパケットのフレームシーケンス番号に基づいてＶＯＩＰパケットが以前にバッファリングされたＶＯＩＰパケットの複製かを判定するステップを含む。バッファリングするステップでは、ＶＯＩＰパケットがしきい値時間点の後に受信されず、かつ、以前にバッファリングされたＶＯＩＰパケットの複製でない場合に受信ＶＯＩＰパケットをバッファリングする。ＶＯＩＰパケットがしきい値時間点の後に受信され、又は以前にバッファリングされたＶＯＩＰパケットの複製であると判定された場合、そのＶＯＩＰパケットは廃棄されるのでそのＶＯＩＰパケットはバッファリングされない。

本発明の実施例によると、バッファリングするステップは、フレームシーケンス番号に基づいてＶＯＩＰパケットを待ち行列に入れるステップを含み、再生するステップでは、バッファリングされたＶＯＩＰパケットをＶＯＩＰパケットが待ち行列に入れられた順番で再生する。

本発明の実施例によると、再生するステップでは、プレイバック時間が来たかを判断し、プレイバック時間が来たと判断される時間毎にバッファリングされたＶＯＩＰパケットを再生する。

本発明の実施例はＶＯＩＰパケットを処理するための無線通信装置を提供する。その装置はジッタバッファ及びジッタバッファコントローラを含む。ジッタバッファは、同じＶＯＩＰ送信に関係する複数の異なる基地局から受信した複数のＶＯＩＰパケットをバッファリングする。ジッタバッファコントローラは複数のＶＯＩＰパケットのバッファリング及びバッファリングされたパケットの再生を制御する。

本発明の実施例によると、ジッタバッファコントローラはクロック及びプレイバック機構を含む。クロックはクロック信号を供給し、プレイバック機構はジッタバッファにバッファリングされたＶＯＩＰパケットを再生する。

本発明の実施例は以下の詳細な説明及び添付図面からより完全に理解できる。なお、同様の要素は同様の符号によって表している。これらは例示のためにのみ提供されるものであり、従って、本発明を限定するものではない。

本発明は、本発明の実施例による複数のノードＢ又はＢＴＳから受信したＶＯＩＰフレームを受信及び処理する方法及びシステムに関する。説明の便宜のみのために、本発明の実施例の方法及びシステムは図１及び２に示す従来のシステムによって実装されるものとして記載するが、本発明はそれらのシステムへの実装に限定されないことが理解できる。

図３Ａ及び３Ｂは複数のノードＢ１１０からジッタバッファコントローラ５００及びジッタバッファ５５０を含むＵＥ１０５へのＶＯＩＰパケットの通信を示す。

図３Ａにおいて、コアネットワークＣＮ１３０は、適応型複数レートＡＭＲ会話フレームをＡＭＲコーデック３００から複数のリアルタイムプロトコル（ＲＴＰ）パケットに変換することによって始動する。本技術では周知のように、ＲＴＰ３０５は、オーディオ、ビデオ又はシミュレーションデータのようなリアルタイムデータをマルチキャスト又はユニキャスト・ネットワーク・サービスを介して送信するアプリケーションに適するエンドトゥエンド・ネットワーク・トランスポート機能を提供する。ＲＴＰ３０５は適時な配信を確実にする機構を提供せず、又は他のサービス品質（ＱｏＳ）保証を提供しない。ＲＴＰ３０５は、データ配信の監視を可能とするとともに最小限必要な制御及び識別機能を提供するリアルタイム制御プロトコル（ＲＴＣＰ）（不図示）との関連で使用される。ＲＴＰ３０５及びＲＴＣＰの使用は本技術では公知である。

アプリケーションはユーザデータグラムプロトコル（ＵＤＰ）３１０の上部のＲＴＰ３０５で稼動し、これも本技術で周知の技術である。ＲＴＰ３０５はＵＤＰ３１０の上部で稼動してＵＤＰ３１０の多重化及びチェックサムサービスを利用する。さらに、ＵＤＰパケットをＩＰネットワーク上で移送するために、ＵＤＰパケットはインターネットプロトコル（ＩＰ）パケットでカプセル化され、これも本技術で周知の技術である。

リアルタイムメディアはＲＴＰペイロードとして転送される。ＲＴＰヘッダは、ＲＴＰペイロードのソース、サイズ、符号化タイプ等といったＲＴＰペイロードに関係する情報を含む。ＲＴＰヘッダは、本技術で周知のように、シーケンス番号及びタイムスタンプを含む。連続するＲＴＰパケットのシーケンス番号は各送信ＲＴＰデータパケットについて１ずつ増分され、パケット消失を検出しパケットシーケンスを回復するためにＵＥ１０５及び／ＭＳ２０５の受信機によって使用される。タイムスタンプはＲＴＰデータパケットにおける第１のオクテットのサンプリングインスタントを反映する。サンプリングインスタントは同期及びジッタ計算を可能とするために時間について単調かつ線形に増分するクロックから配信される。従って、タイムスタンプは各ＲＴＰパケットをクロックを用いてリアルタイムに関係させるが、シーケンス番号は各ＲＴＰパケットを他のＲＴＰパケットに関係させる。

図３Ａに示すように、コアネットワークＣＮ１３０は無線アクセスベアラ（ＲＡＢ）割当てリクエストをＲＮＣ１２０に対して発行し、ＶＯＩＰフレームを無線上で搬送するためのＲＡＢの確立をリクエストする。ＲＮＣ１２０はＲＡＢ・ＶＯＩＰフレームを第１のノードＢ１１０（ここではノードＢ１）を介して制御及び転送するための第１のセットの高速データ（ＨＳＤ）チャネルを構成する。例えば、第１のセットのＨＳＤチャネルは：図３ＡでＲＢ＃１として記載されるダウンリンク共有チャネル（ＨＳ−ＰＤＳＣＨ）；ノードＢ１によって排他的に制御される高速共有制御チャネル（ＨＳ−ＳＣＣＨ）（不図示）；及びＵＥ１０５によって排他的に制御され、ノードＢ１で終端されるアップリンク高速専用物理制御チャネル（ＨＳ−ＤＰＣＣＨ）(不図示）を含む。

本発明の実施例によると、ＲＮＣ１２０は、ノードＢ１を用いて転送された同じＲＡＢ・ＶＯＩＰフレームを第２のノードＢ１１０（ここではノードＢ２）を用いて制御及び転送するための、第１のセットと同一の第２のセットのＨＳＤチャネルを構成する。なお、ＲＮＣ１２０は常に第２のセットのＨＳＤチャネルを構成するように構成してもよいし、あるいは特定の状況下でのみ第２のセットのＨＳＤチャネルを構成するように構成してもよい。特定の状況とは、ハンドオーバーモード中などに第１のセットの受信不良が検出された時などである。

ＲＮＣ１２０はＵＥ１０５に追加のＨＳＤセットの構成について制御メッセージを介して通知する。

図３Ａに示すように、本発明の実施例によると、ＲＮＣ１２０は複製器３２０を含む。ＲＮＣ１２０の複製器３２０はＣＮ１３０によって送られたＶＯＩＰフレームを捕らえ、そのＶＯＩＰフレームを第１のダウンリンク共有チャネルＲＢ＃１を介して送る。第２のセットのＨＳＤチャネルが上記のように構成される場合、複製器３２０は第１のダウンリンク共有チャネルＲＢ＃１を介して送られたＶＯＩＰフレームを複製し、複製されたＶＯＩＰフレームを第２のダウンリンク共有チャネルＲＢ＃２を介して送る。

本発明の実施例によると、ノードＢ１を介してＲＢ＃１上で送られるＶＯＩＰフレームとノードＢ２を介してＲＢ＃２上で送られるＶＯＩＰフレームの送信を同期する必要はない。タイミングが重要でない理由は、ＵＥによって受信されるＶＯＩＰフレームは直ちに再生されず、その代わりにＶＯＩＰフレームはジッタバッファ内の待ち行列に入れられるからである。従って、図４に関して詳細を後述するように、ジッタバッファは待ち行列に入ったＶＯＩＰフレームを例えば２０〜８０ミリ秒の遅延の後に再生させる。

本技術において周知のように、ＰＤＣＰエンティティ３３０は、複製器３２０から受信したＶＯＩＰフレームについてのＲＴＰ、ＵＤＰ及びＩＰヘッダの圧縮を実行する。図３Ａにおける無線リンク制御の非アクノリッジモード（ＲＬＣ・ＵＭ）３４０によって示すように、ＶＯＩＰフレームは転送、分割、再組立て、暗号化及び／又はシーケンス付けを受ける。さらに、本技術において周知のように、ＶＯＩＰフレームがＵＥに物理層３６０に送られる前に、ＶＯＩＰフレームはＭＡＣ層３５０で処理される。

本発明の実施例によるＵＥ１０５は、追加のＨＳＤセットが確立されたことを示すＲＮＣ１２０から送られた制御メッセージに応答して複数の基地局からＶＯＩＰフレームを受信するように構成される。

例えば、図３Ｂにおいて、ＵＥ１０５はノードＢ１及びノードＢ２から受信したプロトコルスタックを受信し、処理する。

特に、第１のダウンリンク共有チャネルＲＢ＃１を介してノードＢ１から受信したプロトコルスタックは、物理層３６０、ＭＡＣ層３５０、ＲＬＣ・ＵＭ３４０、ＰＤＣＰエンティティ３３０、ＩＰ３１５及びＵＤＰ３１０において公知の態様で受信及び処理され、そして更なる処理のためにジッタバッファコントローラ５００に送られる。同様に、第２のダウンリンク共有チャネルＲＢ＃２を介してノードＢ２から受信したプロトコルスタックは、物理層３６０、ＭＡＣ層３５０、ＲＬＣ ＵＭ３４０、ＰＤＣＰエンティティ３３０、ＩＰ３１５及びＵＤＰ３１０において公知の態様で受信及び処理され、そして更なる処理のためにジッタバッファコントローラ５００に送られる。

図４は複数のノードＢ１１０又はＢＴＳ２２０から受信したＶＯＩＰフレームを受信及び処理する本発明の実施例による方法のフローチャートである。

図４に示すように、ステップＳ６００において、ジッタバッファコントローラ５００はＶＯＩＰフレームをノードＢ１及びノードＢ２の少なくとも一方から受信する。ステップＳ６１０において、ジッタバッファコントローラ５００は、ＶＯＩＰフレームが相当遅く受信されたのかをそのＶＯＩＰフレームのタイムスタンプに基づいて判定する。例えば、ジッタバッファコントローラ５００はクロック５３０を含み、それはＶＯＩＰフレームが再生されるべき時を特定するタイムスタンプとの関連で用いられる。例えば、ＶＯＩＰフレームが相当遅く、即ち、ジッタバッファ５５０の使用によって許容される遅延の後に、又はプレイバック時間に対応するしきい値時間点の後に到着したことをタイムスタンプが示す場合、図４のステップＳ６２０においてＶＯＩＰフレームは廃棄される。

ジッタバッファコントローラ５００がタイムスタンプに基づいてＶＯＩＰフレームが相当遅くに到着しなかったと判定した場合、ステップＳ６３０において、ジッタバッファコントローラは、ＶＯＩＰフレームが以前にジッタバッファ５５０の待ち行列に入れられたフレームの複製であるかをＶＯＩＰフレームのフレームシーケンス番号に基づいて判定する。例えば、フレームシーケンス番号を有するＶＯＩＰフレームがノードＢ１を介して受信され、ジッタバッファ５５０の待ち行列に入れられた場合、図４のステップＳ６２０に示すように、同じフレームシーケンス番号を有するフレームがノードＢ２を介して受信され、ノードＢ２からの同じフレームシーケンス番号を有するフレームは廃棄される。

ステップＳ６３０において、ジッタバッファコントローラ５００が、ＶＯＩＰフレームが以前にジッタバッファ５５０の待ち行列に入れられたフレームの複製でない場合、ステップＳ６４０において、受信フレームはフレームシーケンス番号に基づいてジッタバッファ５５０の待ち行列に入れられる。例えば、パケットＮ、Ｎ＋２及びＮ＋１がこの順番でジッタバッファコントローラ５００に到着した場合、第１の受信パケットＮがジッタバッファ５５０の待ち行列に入れられ、第２の受信パケットＮ＋２がジッタバッファ５５０の待ち行列に入れられ、第３の受信パケットＮ＋１が到着すると、第３の受信パケットＮ＋１はジッタバッファコントローラ５００によって第１の受信パケットＮと第２の受信パケットＮ＋２の間のジッタバッファ待ち行列に入れられる。

図４のステップＳ６５０において、ジッタバッファコントローラ５００は、ジッタバッファコントローラ５００のクロック５３０に基づいてプレイバック時間が来たかを判定する。プレイバック時間はジッタバッファ５５０によって与えられる遅延に対応し、２０〜８０ミリ秒の範囲内にある。プレイバック時間が来ていない場合、本発明の実施例による方法は図４のステップＳ６００に戻り、他のＶＯＩＰパケットをノードＢ１及びノードＢ２の少なくとも一方から受信する。

代替的に、ステップＳ６５０において、ジッタバッファコントローラ５００が、プレイバック時間が来たと判定した場合、プレイバック機構５２５は、図４のステップＳ６６０に示すように、ジッタバッファ５５０の待ち行列に入れられたＶＯＩＰフレームを再生する。例えば、２０ミリ秒毎にジッタバッファコントローラ５００のプレイバック機構５２５はジッタバッファ５５０の待ち行列に入れられたフレームを再生する。

ジッタバッファコントローラ５００のプレイバック機構５２５は、プレイバック時間に、待ち行列の先頭にあるパケットのフレームシーケンス番号及びタイムスタンプをチェックする。プレイバック中にプレイバック機構は待ち行列に入れられたパケットを進め、各パケットを再生するか、パケットを廃棄して「消失パケットプレイバック」を置き換える。例えば、プレイバック機構５２５によって処理されているパケットがシーケンス番号に基づいて「想定されるパケット」の場合、そのパケットは再生され、一方、そのパケットが「想定されるパケット」でない場合、「消失パケットプレイバック」がそのパケットの代替として用いられる。例えば、「想定されるパケット」ではないパケットに対する代替としてホワイトノイズが再生されることがある。ジッタバッファ５５０の待ち行列に入れられたパケットの全てがプレイバック機構５２５によって処理されると、プレイバック機構は次のプレイバック時間が来るまで停止する。

本発明の実施例がここに記載されたが、等価なものが様々な態様で変形されることは明らかである。そのようなバリエーションは本発明から離れたものとみなされず、そのような全ての変形例は発明の範囲内に含まれるものである。

図１はＵＭＴＳプロトコルによって動作する従来技術の無線通信システムを示す図である。 図２はＣＤＭＡ２０００・１ｘＥＶ−ＤＯプロトコルに従って動作する従来技術の無線通信システムを示す図である。 図３Ａは複数のノードＢからジッタバッファコントローラ及びジッタバッファを含むＵＥへのＶＯＩＰパケットの通信を示す図である。 図３Ｂは複数のノードＢからジッタバッファコントローラ及びジッタバッファを含むＵＥへのＶＯＩＰパケットの通信を示す図である。 図４は複数のノードＢ又はＢＴＳから受信したＶＯＩＰフレームを受信及び処理する本発明の実施例による方法のフローチャートである。

Claims (10)

1. ボイス・オーバー・インターネット・プロトコル（ＶＯＩＰ）パケットを処理する方法であって、
   複数の異なる基地局（１１０、２２０）からＶＯＩＰパケットを受信するステップであって、該ＶＯＩＰパケットが同一のＶＯＩＰ送信と関係している、ステップ、
   受信した該ＶＯＩＰパケットをバッファリングするステップ、及び
   バッファリングされた該ＶＯＩＰパケットを再生するステップ
   からなる方法。
2. 請求項１の方法において、該ＶＯＩＰパケットの各々がタイムスタンプ及びフレームシーケンス番号を含む方法。
3. 請求項２の方法であって、さらに、
   ＶＯＩＰパケットがしきい値時間点の後に受信されたかを該タイムスタンプに基づいて判定するステップ、及び
   該ＶＯＩＰパケットが以前にバッファリングされたＶＯＩＰパケットの複製であるかを該ＶＯＩＰパケットのフレームシーケンス番号と該以前にバッファリングされたＶＯＩＰパケットのフレームシーケンス番号との比較に基づいて判定するステップ
   からなり、
   該バッファリングするステップで、
   該ＶＯＩＰパケットが該しきい値時間点の後に受信されず、かつ、該ＶＯＩＰパケットが該以前にバッファリングされたＶＯＩＰパケットの複製ではない場合に、該受信したＶＯＩＰパケットをバッファリングする方法。
4. 請求項３の方法において、該しきい値時間点が、該バッファリングされたＶＯＩＰパケットが再生されるべきプレイバック時間に対応する方法。
5. 請求項３の方法において、
   該バッファリングするステップが、該ＶＯＩＰパケットを該フレームシーケンス番号に基づいて待ち行列に入れるステップからなり、
   該再生するステップで、該バッファリングされたＶＯＩＰパケットを該ＶＯＩＰパケットが待ち行列に入れられた順番で再生する
   方法。
6. ボイス・オーバー・インターネット・プロトコル（ＶＯＩＰ）パケットを処理するための無線通信装置であって、
   複数の異なる基地局（１１０、２２０）からＶＯＩＰパケットを受信するジッタバッファ（５５０）であって、該ＶＯＩＰパケットが同一のＶＯＩＰ送信と関係している、ジッタバッファ、及び
   該複数のＶＯＩＰパケットのバッファリングを制御し、バッファリングされた該ＶＯＩＰパケットを再生するジッタバッファコントローラ（５００）
   からなる装置。
7. 請求項６の装置において、該複数のＶＯＩＰパケットの各々がタイムスタンプ及びフレームシーケンス番号を含む装置。
8. 請求項７の装置において、該ジッタバッファコントローラが、
   クロック信号を供給するクロック（５３０）を備え、
   該ジッタバッファコントローラが、ＶＯＩＰパケットがしきい値時間点の後に受信されたかを該タイムスタンプに基づいて判定し、該ＶＯＩＰパケットが以前にバッファリングされたＶＯＩＰパケットの複製であるかを該ＶＯＩＰパケットのフレームシーケンス番号及び該ジッタバッファに既にバッファリングされたＶＯＩＰパケットのフレームシーケンス番号に基づいて判定し、該ＶＯＩＰパケットが該しきい値時間点の後に受信されずかつ該ジッタバッファ内のＶＯＩＰパケットの複製ではない場合に、該ジッタバッファに該ＶＯＩＰパケットをバッファリングするよう指示するように適合された装置。
9. 請求項８の装置において、該しきい値時間点が、該バッファリングされたＶＯＩＰパケットが再生されるべきプレイバック時間に対応する装置。
10. 請求項８の装置において、該ジッタバッファコントローラがさらに、
    該バッファリングされたＶＯＩＰパケットをプレイバック時間が来たと判断される時間毎に再生するプレイバック機構（５２５）を備え、
    該ジッタバッファコントローラが、該クロックによって供給されるクロック信号に基づいて該プレイバック時間が来たことを判断する装置。

Images