複数のインタフェースを有するモバイルデバイスにおいて、サービス品質を高めるために、複数のセッションにおいてＶｏＩＰ／ＶＩＰ送信をインタリーブすること
第１のモバイルデバイスは、２つのエアインタフェースを有する。第１のモバイルデバイスは、その第１のインタフェースを用いて、第１のセッションにおいて、ＶｏＩＰ／ＶＩＰパケットを第２のデバイスへ送信する。サービス品質が低下すると、第１のデバイスは、第２のエアインタフェースを用いる第２のセッションが確立されるようにする。そして、単一のメディアストリームのパケットを第１のデバイスから第２のデバイスへ通信するために、第１のエアインタフェースと第２のエアインタフェースとの両方が使用される。パケットは、第１および第２のセッションにおいて、インタリーブ方式で送信され、単位時間当たりに、１つのセッションで通信されるパケットの、他のセッションで通信されるパケットに対する比率が、１つのセッションによって提供されるサービス品質の、他のセッションによって提供されるサービス品質に対する比率にしたがって調節される。第２のデバイスは、パケットのデータペイロードの順序付けを行い、もって、単一のメディアストリームを再構築する。
【発明の詳細な説明】
【技術分野】
【０００１】
開示された実施形態は、一般に、ＩＰテレフォニーに関する。
【背景技術】
【０００２】
セルラ電話のようなモバイル通信デバイスは、複数のエアインタフェースを有しうる。一例では、セルラ電話は、従来、ＣＤＭＡ（符号分割多元接続）トランシーバを用いたセルラ電話ネットワークを用いて、比較的長距離にわたって通信をすることができる。セルラ電話のＣＤＭＡトランシーバは、セルラ電話ネットワーク上のセルラＢＴＳ（基地送信機サイト）と通信する。更に、セルラ電話は、ＩＥＥＥ ８０２．１１トランシーバを用いた無線ローカルエリアネットワーク（ＬＡＮ）を用いて、比較的短距離で通信することができる。セルラ電話の８０２．１１トランシーバは、ＬＡＮ上のアクセスポイントと無線で通信する。
【０００３】
第１のパーティは、ＶｏＩＰ（voice over Internet Protocol）技術を用いて第２のパーティへ通話するために、セルラ電話を使用することができる。音声データは、セルラ電話から、アクセスポイントへの８０２．１１無線リンク、ＬＡＮ、及びインターネットを介して、ＩＰパケットによって第２のパーティへと通信される。第１のパーティがそのような通話に従事している場合、第１のパーティが、２つのエアインタフェースを持つモバイル通信デバイスを移動させ、２つのアクティブなインタフェースが、完全よりも少ない有効範囲を持つようになるかもしれない。このような従来式のアプローチは、より良い有効範囲を持つインタフェースを用いることを開始し、より良いインタフェースを用いてＲＴＰのようなリアルタイムトラフィックを送ることを開始する。モバイル通信デバイスは、切り換わったインタフェース条で完全な有効範囲を持つ訳ではないので、サービス品質が影響を受ける。そして、選択されたインタフェースは、インタフェースについての有効範囲が完全に失われるまで、または、その他のインタフェースについての有効範囲が改善するまで、ＲＴＰデータを送るために使用される。解決策が望まれる。
【発明の開示】
【発明の概要】
【０００４】
モバイル通信デバイス（例えば、セルラ電話）は、無線ＬＡＮ（ローカルエリアネットワーク）との無線通信のための１つのエアインタフェースと、セルラ電話ネットワークとのセルラ電話通信のための別のエアインタフェースとを有する。無線ＬＡＮとの無線通信は、例えば、ＩＥＥＥ ８０２．１１に従いうる。セルラ電話ネットワークは、例えば、ＣＤＭＡ（符号分割多元接続）電話ネットワークでありうる。
【０００５】
第１の斬新な局面にしたがって、モバイル通信デバイスは、先ず、第１のセッションにおいて、エアインタフェースのうちの１つを介して、メディアストリームのデータペイロードＶｏＩＰパケットを、ターゲット通信デバイスへ送信するために使用される。ＶｏＩＰパケットは、ＩＰ（Internet Protocol）、ＵＤＰ（User Datagram Protocol）及びＲＴＰ（Real-Time Protocol）を用いて通信される。ＶｏＩＰメディアストリームは、例えば、モバイル通信デバイスを用いた第１のパーティＡと、ターゲット通信デバイスを用いた第２のパーティＢとの間の会話のための音声データを含む。
【０００６】
そして、モバイル通信デバイスの他のエアインタフェースを用いて通話を継続することが望まれる。これは、例えば、初めは短距離無線ＬＡＮインタフェースとして使用されているエアインタフェースによるものかもしれない。パーティＡは、短距離の無線ＬＡＮの有効範囲領域から出るかもしれない。より長距離のセルラ電話エアインタフェースを用いることに切り換えることによって、通話を継続することが望まれる。あるいは、第１のエアインタフェースを用いることから、第２のエアインタフェースへ切り換えることが望まれる。ここで、第１のエアインタフェースは、より長距離のセルラ電話インタフェースであり、第２のエアインタフェースは、より短距離の無線ＬＡＮインタフェースである。最初はセルラ電話エアインタフェースが使用されるが、次に、パーティＡが、無線ＬＡＮの有効範囲領域へ移動する。例えば、パーティＡのセルラ電話プロバイダが、そのセルラ電話ネットワーク上で音声会話を伝送することに課金するのであれば、パーティＡはそのセルラエアインタフェースを用いることをやめ、より費用の安い無線ＬＡＮエアインタフェースを用いて通話を継続することが望ましい。
【０００７】
最初に使用されていたエアインタフェースから別のエアインタフェースへ切り換えることを望む理由に関わらず、パーティＡのモバイル通信デバイスは、パーティＢのターゲット通信デバイスへＳＰＡＷＮ ＳＩＰメッセージを送る。ＳＰＡＷＮ ＳＩＰメッセージは、ＩＰ、ＴＣＰ(Transmission Control Protocol)、及びＳＩＰ(Session Initialization Protocol) を用いて通信される。ターゲットは、ＳＰＡＷＮ識別子を含む２００ ＯＫ ＳＩＰメッセージを送ることによって応答する。その後、モバイル通信デバイスは、他のインタフェースを介してＳＩＰ ＩＮＶＩＴＥ要求をターゲットへ送ることによって、他のエアインタフェースを介した第２のセッションをセットアップする。ＳＩＰ ＩＮＶＩＴＥ要求は、ＳＰＡＷＮ識別子を含んでいる。第２のセッションは初期化され、第１及び第２のセッションの両方が、アクティブなＶｏＩＰセッションとなる。どちらのセッションも、回路切換リンクを含む。ターゲット通信デバイスは、第１のセッションと第２のセッションとを関連付けるＳＩＰ ＩＮＶＩＴＥ要求で受信されるＳＰＡＷＮ識別子を用いる。
【０００８】
第２のセッションが一旦初期化されると、モバイル通信デバイスは、第１のセッションにおいて、メディアストリームのためＶｏＩＰパケットを送信することをやめ、第２のセッションにおいて、メディアストリームのため次のＶｏＩＰパケットを送信する。幾つかの実施形態では、モバイル通信デバイスからターゲットへとハンドオフ制御パケットが送られ、ターゲットに対して、次のＶｏＩＰパケットは第１のセッション内ではもはや受信されないが、第２のセッション内で受信されることを知らせる。他の実施形態では、メディアストリームのデータペイロードＶｏＩＰパケットはもはや第１のセッションにおいてターゲットによって受信されないので、ターゲットは、データペイロードＶｏＩＰパケットを通信するために第２のセッションが使用されているが、メディアストリームのデータペイロードＶｏＩＰパケットは第２のセッションにおいてターゲットによって受信されていると判定する。ＶｏＩＰパケットが、第２のセッションにおいて通信されていると、ターゲットがどのようにして判定するかに関わらず、パーティＡの通信デバイスとパーティＢの通信デバイスとの間の両方向におけるＶｏＩＰパケットのフローは、第２のセッションで生じ、第１のセッションでは生じない。
【０００９】
例えば、データペイロードＶｏＩＰパケットが、会話のための音声データを含んでいる場合、ＶｏＩＰパケットを受信する通信デバイスは、第２のセッションで受信したＶｏＩＰペイロードを、ＦＩＦＯ（first in first out）バッファ内に、第１のセッションで受信したＶｏＩＰパケットのペイロードの後にバッファする。ＶｏＩＰパケットは、ＲＴＰシーケンス番号及びタイムスタンプにしたがってＦＩＦＯ内に順序付けられる。ＦＩＦＯバッファの出力は、通信デバイスのユーザによって聞かれる音に変換される。
【００１０】
２つのセッションがアクティブなままである限り、データペイロードＶｏＩＰパケットのフローは、所望により、１つのセッションから別のセッションへと切り換えることができる。データペイロードＶｏＩＰパケットを通信するために使用されていないセッションは、所望により、停止することができる。第１のセッションを停止するために、モバイル通信デバイスは、ＳＩＰプロトコルにしたがって、ＳＩＰ ＢＹＥメッセージをターゲット通信デバイスへ送る。第２の斬新な局面にしたがって、モバイル通信デバイスは、第１のエアインタフェースと第２のエアインタフェースとの両方を有する。例えば、第１のエアインタフェースは、ローカルエリアネットワーク（ＬＡＮ）上の無線アクセスポイントと無線ＲＦ通信するためのＩＥＥＥ ８０２．１１インタフェースでありうる。例えば、第２のエアインタフェースは、セルラ電話ネットワーク上のアクセスポイントと無線ＲＦ通信するためのＣＤＭＡセルラ電話インタフェースでありうる。
【００１１】
ＶｏＩＰ／ＶＩＰ通話では、モバイル通信デバイスは、モバイル通信デバイスから第２のＩＰデバイスへと第１のセッションにおいてＶｏＩＰ／ＶＩＰパケットを通信するために第１のエアインタフェースを用いる。モバイル通信デバイス内のソフトウェアは、第１のセッションによって与えられたサービス品質に関して定期的に評価する。この評価が、サービス品質が不適当または受け入れられないレベルへ低下したことを示す場合、かつ、第２のエアインタフェースを使用することが可能な場合、モバイル通信デバイスは、モバイル通信デバイスと第２のＩＰデバイスとの間に第２のセッションが確立されるようにする。ここで、第２のセッションは、モバイル通信デバイスの第２のエアインタフェースを用いた通信を含んでいる。
【００１２】
第２のセッションが一旦確立されると、第１のセッションを終了するのではなく、モバイル通信デバイスから第２のＩＰデバイスへと単一のメディアストリームのＶｏＩＰ／ＶＩＰパケットを通信するために、第１のセッションと第２のセッションとの両方が使用される。一例では、単一のメディアストリームは、このモバイル通信デバイスを使用する人の声を表す音声データである。ＶｏＩＰ／ＶＩＰパケットは、インタリーブ方式で、第１のセッションおよび第２のセッションで、第２のＩＰデバイスへ送信される。第２のＩＰデバイスは、第１のセッションおよび第２のセッションからＶｏＩＰ／ＶＩＰパケットを受信する。そして、ＶｏＩＰ／ＶＩＰパケットのデータペイロードを順序付けるためにＲＴＰタイムスタンプおよび／またはＲＴＰシーケンス番号を用いる。これによって、単一のメディアストリームを再構築する。モバイル通信デバイスは、第１のセッションによって与えられるサービス品質と、第２のセッションによって与えられるサービス品質との定期的な評価を行う。１つの実施形態では、第１のセッションにおいてモバイル通信デバイスから送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションに対する比率は、第１のセッションのサービス品質の評価と、第２のセッションのサービス品質の評価との比率である。セッションのサービス品質評価の１つの例は、単位時間当たりに第２のＩＰデバイスによって、セッション内で受信されるパケット数である。第１のセッションにおいてモバイル通信デバイスによって送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションに対する比は、これら２つのセッションにおけるサービス品質の変化する評価を反映するために定期的に調節される。この比率は必ずしも計算された値である必要はないが、所与の期間内に、１つのセッションにおいて、他のセッションに比べて、どれくらい多くのＶｏＩＰ／ＶＩＰパケットが送信されるかを示す固有の結果である。セッションのサービス品質評価は、ＲＴＣＰレポートにおける情報、アクセスポイントから受信した検出信号強度情報、および／またはアクセスポイントから受信した瞬時ビットレート情報を含みうる。
【００１３】
モバイル通信デバイスから送信されるＶｏＩＰ／ＶＩＰパケットの比率が調節されるのと同じ方法で、第１のセッションにおいてモバイル通信デバイスへ送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションにおける場合に対する比率もまた調節される。モバイル通信デバイスから送信されるパケットの比率は、モバイル通信デバイスへ送信されるパケットの比率と同じである必要はない。モバイル通信デバイスおよび第２のＩＰデバイスにおけるサービス品質の評価を行うために使用されるメカニズムは必ずしも同一である必要はない。
【００１４】
更なる実施形態が、以下の詳細記述に記載される。この要約は、発明を定義することを意図していない。本発明は、特許請求の範囲によって定義される。
【詳細な説明】
【００１５】
図１は、１つの斬新な局面にしたがったＩＰ（Internet Protocol）テレフォニー通信システム１の簡略トポロジカルブロック図である。第１のパーティ（図１において「パーティＡ」と示す）は、例えばＩＰ電話２のようなモバイル無線通信デバイスを用いる。ＩＰ電話２は、図１においてＩＰアドレス＃１と示されたＩＰアドレスを有する。もしもＩＰ電話２が、アクセスポイント３の通信範囲内にあるのであれば、ＩＰ電話２は、ＬＡＮ（ローカルエリアネットワーク）４上のアクセスポイント３との短距離無線通信が可能である。この例では、ＩＰ電話２及びアクセスポイント３は、ＩＥＥＥ ８０２．１１仕様にしたがって通信する。ＬＡＮ４は、パーティＡが、ローカル領域内においてＩＰ電話２を移動することができ、アクセスポイントのうち少なくとも１つを経由してＬＡＮ４と通信し続けることができるように、複数のアクセスポイントを含む。
【００１６】
システム１は更に、セルラ電話ネットワーク５を含んでいる。この例において、セルラ電話ネットワーク５は、ＣＤＭＡ（符号分割多元接続）セルラ電話ネットワークである。またＩＰ電話２は、ＣＤＭＡセルラ電話ネットワーク５において、トランシーバを用いて長距離の無線通信を行うことができる。パーティＡは、ＩＰ電話２を用いて、ＣＤＭＡセルラ電話ネットワーク５によって通話を行ったり、受信する。ＩＰ電話２は、ＣＤＭＡセルラ電話通信のみならず、８０２．１１通信も可能であるので、ＩＰ電話２は、デュアルモードＩＰ電話と称される。
【００１７】
ＬＡＮ４及びセルラ電話ネットワーク５はＩＰネットワークに接続される。この例において、ＩＰネットワークは、インターネットすなわち「インターネット」６である。インターネット６は、複数の相互接続したルータを含んでいる。ＳＩＰプロキシ７は、ＬＡＮ４からインターネット６へ、また、インターネット６からＬＡＮ４へとＩＰパケットを通信できるように、ＬＡＮ４とインターネット６との両方に配置される。ＳＩＰプロキシ７は、ＬＡＮ４のＡＴＬＡＮＴＡ１．ＣＯＭドメインのためのインバウンドプロキシとアウトバウンドプロキシとの両方として動作する。ＳＩＰプロキシ７は、ＬＡＮ４上のサーバとして、及び、インターネット６上のクライアントとして動作する。ＳＩＰプロキシ７は、他のＳＩＰプロキシ及びＳＩＰセッション終点との間で、ＳＩＰ要求及びＳＩＰ応答を中継する。
【００１８】
他のＳＩＰプロキシ８は、セルラ電話ネットワーク５、及びインターネット６の両方に配置され、これによって、ＳＩＰプロキシ８は、セルラ電話ネットワーク５からインターネット６へ、及び、インターネット６からセルラ電話ネットワーク５へとＩＰパケットを通信することができる。ＳＩＰプロキシ８は、セルラ電話ネットワーク５のＡＴＬＡＮＴＡ２．ＣＯＭドメインのためのインバンドプロキシ及びアウトバウンドプロキシの両方として動作する。ＳＩＰプロキシ８は、セルラ電話ネットワーク５上のサーバとして、及び、インターネット６上のクライアントとして動作する。ＳＩＰプロキシ８は、他のＳＩＰプロキシ及びＳＩＰセッション終点との間で、ＳＩＰ要求及びＳＩＰ応答を中継する。
【００１９】
第２のパーティ（図１に示す「パーティＢ」）は、ＩＰ電話９のような第２の通信デバイスを有する。この例では、ＩＰ電話９は、モバイルＩＰ電話ではなく、むしろ、固定式の陸線ＩＰ電話である。ＩＰ電話９は、図１においてＩＰアドレス＃２と示されたＩＰアドレスを持っている。ＩＰ電話９は、ＬＡＮ１０を経由してインターネット６に接続される。ＬＡＮ１０は、例えば、パーティＢのインターネットサービスプロバイダ（ＩＳＰ）によって維持されるＬＡＮであるかもしれないし、又は、パーティＢの雇用者によって維持される企業ＬＡＮでもありうる。ＳＩＰプロキシ１１は、ＬＡＮ １０、およびインターネット６に配置される。ＬＡＮ１０からインターネット６へ、及び、インターネット６からＬＡＮ１０へとＩＰパケットを通信できるように、ＬＡＮ１０とインターネット６との両方に配置される。ＳＩＰプロキシ１１は、ＬＡＮ１０のＢＩＬＯＸＩ.ＣＯＭドメインのためのインバンドプロキシと、アウトバウンドプロキシとの両方として動作する。ＳＩＰプロキシ１１は、ＬＡＮ１０上のサーバとして、及び、インターネット６上のクライアントとして動作する。ＳＩＰプロキシ１１は、他のＳＩＰプロキシ及びＳＩＰセッション終点との間で、ＳＩＰ要求及びＳＩＰ応答を中継する。
【００２０】
図２は、ＩＰ電話２及びＳＩＰプロキシ７を示す。プロトコル処理レイヤのスタック１２は、ＳＩＰプロキシ７のハードウェアプラットフォーム上で動作する。ＳＩＰプロキシ７，８及び１１の各々で動作するプロトコル処理レイヤには、このようなスタックがある。スタック１２は、ＭＡＣレイヤ１３、ＩＰレイヤ１４、ＴＣＰレイヤ１５、及びＳＩＰレイヤ１６を含んでいる。ＭＡＣは「媒体アクセス制御」を表わす。ＩＰは「インターネットプロトコル」を表わす。ＴＣＰは「転送制御プロトコル」を表わす。ＳＩＰは「セッション初期化プロトコル」を表わす。ＩＰ電話２内のプロセッサは、プロトコル処理レイヤの類似のスタック１７を実行する。スタック１７は、ＩＰレイヤ１８、ＴＣＰレイヤ１９、及びＳＩＰレイヤ２０を含んでいる。スタック１２，１７の各々は、ＩＰレイヤ及びＴＣＰレイヤを含んでいるので、ＩＰ電話２とＳＩＰプロキシ７との間でＴＣＰ接続を確立することができる。図２では、ＩＰ電話２内の黒い点が、ＩＰ電話２のＩＰアドレス＃１を表わす。ＳＩＰプロキシ７内の黒い点は、ＩＰアドレスを表わす。左端の矢印は、ＩＰ電話２及びＳＩＰプロキシ７内で終端する第１のＴＣＰ接続２１を表わす。ＩＰプロトコル通信は、単なるベストエフォート通信だが、ＩＰに加えてＴＣＰを用いることによって、ＴＣＰ接続２１を介したＩＰ電話２とＳＩＰプロキシ７との間の情報の信頼できる通信が可能となる。ＴＣＰ接続２１が確立され、ＩＰ電話２とＳＩＰプロキシ７との間で維持されるのと同じ方法で、第２のＴＣＰ接続２２が確立され、ＩＰプロトコル処理レイヤとＴＣＰプロトコルレイヤとを含むスタック、及び、ＩＰアドレスを有するインターネット上の他のデバイスとＳＩＰプロキシ７との間で維持される。ＳＩＰプロキシ１１（図１参照）は、そのような１つのデバイスである。図２では、右端の矢印は、ＳＩＰプロキシ７で一端が終端し、ＳＩＰプロキシ１１で他端が終端している第２のＴＣＰ接続２２を表す。
【００２１】
図３は、斬新な方法にしたがった第１のステップのブロック図である。この図では、時間は、垂直のディメンションにおける上端から下端まで及ぶ。“パーティＡ”とラベルされたボックスと、このボックスから下の方向へ伸びる垂線は、ＩＰ電話２を表す。“パーティＢ”とラベルされたボックスと、このボックスから下の方向へ伸びる垂線は、ＩＰ電話９を表す。「ＳＩＰプロキシ＃１」とラベルされた垂線は、ＳＩＰプロキシ７を表わす。「ＳＩＰプロキシ＃２」とラベルされた垂線は、ＳＩＰプロキシ１１を表わす。
【００２２】
ＩＰ電話２内には、ＩＰ電話２がＬＡＮ４と通信している場合に使用されるＳＩＰプロキシの識別情報が格納されている。ＩＰ電話２は、ＩＰ電話２がセルラ電話ネットワーク５と通信している場合に使用される別のＳＩＰプロキシの別の識別情報を格納する。この例において、ＬＡＮ４と通信している場合に使用されるＳＩＰプロキシの識別情報は、ＰＲＯＸＹ１．ＡＴＬＡＮＴＡ１．ＣＯＭである。セルラ電話ネットワーク５と通信している場合に使用されるＳＩＰプロキシの識別情報は、ＰＲＯＸＹ３．ＡＴＬＡＮＴＡ２．ＣＯＭである。ＩＰ電話２はＬＡＮ４と通信しているので、ＩＰ電話２は、識別情報ＰＲＯＸＹ１．ＡＴＬＡＮＴＡ１．ＣＯＭを用い、この識別情報を解釈して、識別されたＳＩＰプロキシのＬＡＮ側のＩＰアドレスを取得する。この識別されたＳＩＰプロキシのＬＡＮ側のＩＰアドレスが、前のＳＩＰトランザクションでアドレスされたＳＩＰプロキシと関連付けられてＩＰ電話２内にキャッシュされると、このキャッシュされたＩＰアドレスは、ＳＩＰプロキシのＬＡＮ側のＩＰアドレスとして使用される。この識別されたＳＩＰプロキシのＬＡＮ側のＩＰアドレスが、ＩＰ電話２内にキャッシュされていないのであれば、ＩＰ電話２は、ＤＮＳサーバ（図示せず）にＤＮＳ要求を送る。ＤＮＳサーバは、この例では、ＬＡＮ４に配置される。ＤＮＳサーバは、各ＳＩＰプロキシに対するＩＰアドレスを含むルックアップテーブルを含む。ＤＮＳサーバは、ＩＰ電話２にＩＰアドレスを送り返すことによって、ＤＮＳ要求に応答する。この例では、ＩＰ電話２のＩＰアドレスは１０．３２．１．１４１である。識別されたＳＩＰプロキシのＬＡＮ側のＩＰアドレスを、ＩＰ電話２がどのようにして取得するかに関わらず、ＩＰ電話２は、ＳＩＰ呼出人又は発信人として動作し、ＩＰ電話２とＳＩＰプロキシ７との間のＴＣＰ接続２１を介して、ＳＩＰプロキシのＬＡＮ側のＩＰアドレスへＳＩＰ ＩＮＶＩＴＥ要求を送る。図３では、パーティＡからＡＴＬＡＮＴＡ１．ＣＯＭへ伸びる一番上の矢印２３は、このＳＩＰ ＩＮＶＩＴＥ要求の送信を示している。
【００２３】
図４は、ＳＩＰ ＩＮＶＩＴＥ要求のブロック図である。ＳＩＰ ＩＮＶＩＴＥ要求のヘッダフィールド部は、ＳＩＰ ＩＮＶＩＴＥ要求が、ＳＩＰアドレスＢＯＢ＠ＢＩＬＯＸＩ．ＣＯＭへ向けられていることを示している。ＳＩＰ ＩＮＶＩＴＥ要求のヘッダフィールド部は、ＳＩＰ ＩＮＶＩＴＥが、ＳＩＰアドレスＡＬＩＣＥ＠ＡＴＬＡＮＴＡ１．ＣＯＭからのものであることを示す。ＳＩＰ ＩＮＶＩＴＥ要求は、ＳＩＰプロキシ７上で終端しているＴＣＰ接続において受信され、ＳＩＰプロキシ７のＳＩＰプロトコル処理レイヤへ提供される。ＳＩＰプロキシ７のＳＩＰプロトコル処理レイヤは、このアドレス情報を検査し、ＢＯＢ＠ＢＩＬＯＸＩ．ＣＯＭを得る。そして、ＳＩＰプロトコル処理レイヤは、ＳＩＰ ＩＮＶＩＴＥ要求をどこへ送信するかを判定するポリシーのセットを用いる。このポリシーのセットは、各ドメインネームに対する関連するＳＩＰプロキシを示す。本例では、ポリシーは、ドメインネームＢＩＬＯＸＩ．ＣＯＭが、関連するＳＩＰプロキシ＃２によってサービス提供されるべきであることを示す。そして、ＳＩＰプロキシ７内のＳＩＰプロトコル処理レイヤは、識別されたＳＩＰプロキシ＃２を解釈し、ＳＩＰプロキシ＃２のインターネット側のＩＰアドレスを決定する。これは、キャッシュされた情報を調べることにより、又は、ＤＮＳサーバルックアップを行うことによってなされうる。ＳＩＰプロキシ＃２のインターネット側ＩＰアドレスが一旦決定されると、ＳＩＰプロキシ７は、ＳＩＰプロキシ＃２へのＴＣＰ接続を確立し、ＳＩＰ ＩＮＶＩＴＥ要求を、インターネット６を介してＳＩＰプロキシ＃２へ転送する（図１参照）。ＳＩＰプロキシ＃２は、ドメインＢＩＬＯＸＩ．ＣＯＭ上にある。ＢＩＬＯＸＩ．ＣＯＭは、ＬＡＮ１０のドメインネームである。図３のブロック図において、ＡＴＬＡＮＴＡ１．ＣＯＭからＢＩＬＯＸＩ．ＣＯＭへ伸びる矢印２４は、ＳＩＰプロキシ７からＳＩＰプロキシ１１へのＳＩＰ ＩＮＶＩＴＥ要求の転送を表わす。
【００２４】
ＳＩＰプロキシ１１は、このＳＩＰ ＩＮＶＩＴＥ要求を受信する。ＳＩＰプロキシ１１上で動作するスタックのＳＩＰレイヤは、ＬＡＮ１０上の全てのデバイスのＩＰアドレスを知っている。ＳＩＰ ＩＮＶＩＴＥ要求の、示されたＳＩＰ呼出先アドレスＢＯＢ＠ＢＩＬＯＸＩ．ＣＯＭから、ＳＩＰプロキシ１１のＳＩＰレイヤは、ＢＯＢ＠ＢＩＬＯＸＩ．ＣＯＭのＩＰアドレスを取得し、ＳＩＰ ＩＮＶＩＴＥ要求を、ＴＣＰ接続を介して、ＩＰ電話９のＩＰアドレス（ＩＰアドレス＃２）へ転送する。図３では、ＢＩＬＯＸＩ．ＣＯＭからパーティＢへ伸びる矢印２５は、この転送を表わす。ＩＰ電話９のスタックのＳＩＰレイヤは、このＳＩＰ ＩＮＶＩＴＥ要求を受信し、ＳＩＰプロトコルにしたがって、２００ ＯＫ ＳＩＰメッセージを返す。２００ ＯＫ ＳＩＰメッセージは、上述した転送処理と逆の処理によって、ＳＩＰプロキシ１１及びＳＩＰプロキシ７を介して、パーティＡ及びＩＰ電話２へ戻される。図３では、この転送は、矢印２６、２７及び２８によって表わされる。
【００２５】
次に、ＩＰ電話２は、２００ ＯＫ ＳＩＰメッセージを受信し、これからＩＰ電話９のＩＰアドレスを得る。そして、ＩＰ電話２は、ＩＰ電話２からＩＰ電話９へのＴＣＰ接続を直接的に確立することができる。２００ ＯＫ ＳＩＰメッセージを受信することに応じて、ＩＰ電話２は、ＴＣＰ接続を介して、ＩＰ電話９へとＳＩＰアクノレッジ（ＡＣＫ）メッセージを送り返す。図３では、これは、パーティＡからパーティＢまで直接伸びている矢印２９によって図示される。
【００２６】
図５は、ＳＩＰ ＩＮＶＩＴＥ要求、２００ ＯＫメッセージ、及びＡＣＫを含むＳＩＰトランザクションを示す。トランザクションの３つ全てのＳＩＰメッセージが、ネットワークを通って同時に伝搬するものとして例示されていているが、ＳＩＰメッセージは、実際には、上述したように、一度に１つ送られ、受信される。ＳＩＰトランザクションの結果は、（パーティＡの）ＩＰアドレス＃１と、（パーティＢの）ＩＰアドレス＃２の初期化である。データペイロードがセッション中に通信されていようともいまいとも、終了していない初期化ＳＩＰセッションは、“アクティブ”であると呼ばれる。本例では、第１のＳＩＰセッションが一旦初期化されると、音声及び／又はビデオデータペイロードを有する第１のＶｏＩＰ／ＶＩＰ（voice over IP or video over IP）が、ＲＴＰ（Real-Time Protocol）プロトコルにしたがって、ＵＤＰ（User Datagram Protocol）パケットによって、ＩＰ電話２のＩＰアドレス＃１とＩＰ電話９のＩＰアドレス＃２との間で通信される。第１のセッションのデータペイロードはＩＰの上のＵＤＰの上のＲＴＰを使用して通信される、一方、第１のセッションの制御パケットは、ＩＰ、ＴＣＰ、及びＳＩＰを用いて通信される。
【００２７】
図６は、ＩＰ電話２とＩＰ電話９との間のこれら第１のＶｏＩＰ／ＶＩＰ ＩＰデータペイロードパケットの幾つかの通信を例示している。この通信は、８０２．１１プロトコルにしたがった、ＬＡＮ４のアクセスポイント３とＩＰ電話２との間の無線通信を含む。８０２．１１は、比較的短距離のＲＦ通信プロトコルである。本例では、パーティＡは、アクセスポイント３から更に遠くへ移動する。ＩＰ電話２は、アクセスポイント３から受信したＲＦ送信の信号強度を検知する。本例では、検知された信号強度の表示は、ＩＰ電話２において、ＩＰ電話２内の８０２．１１トランシーバの受信機増幅器から出力されるＲＳＳＩ（Radio Signal Strength Indicator）信号として利用可能である。アクセスポイント３内の８０２．１１トランシーバの受信機増幅器はまた、ＩＰ電話２から受信したＲＦ送信の信号強度を検知する。この検知された信号強度は、アクセスポイント３からＩＰ電話２へと報告される。このように、ＩＰ電話２は、両方向で受信した送信の強度を認識する。パーティＡ及びＩＰ電話２がアクセスポイント３から離れると、ＩＰ電話２とアクセスポイント３との間の８０２．１１無線リンクの検知された信号強度は、しきい値に達するまで低下する。しきい値に到達すると、ＩＰ電話２は、ＩＰ電話２が、その長距離のセルラ電話トランシーバを用いて第２のＳＩＰセッションを初期するべきであると判定する。ＩＰ電話２は、第１のセッションにおいて、ＳＰＡＷＮメッセージと呼ばれる斬新なＳＩＰメッセージをパーティＡからパーティＢへ送ることによって、この第２のＳＩＰセッションを初期化する。
【００２８】
図７は、ＳＰＡＷＮ ＳＩＰメッセージを例示するブロック図である。
【００２９】
図８は、パーティＡからパーティＢへのＳＰＡＷＮ ＳＩＰメッセージの通信を例示するブロック図である。上述したように、パーティＡからパーティＢへとＩＮＶＩＴＥ ＳＩＰメッセージが通信されるのと同じ方法で、ＳＰＡＷＮ ＳＩＰメッセージもまた、ＩＰ電話２から、８０２．１１無線リンクを介してＬＡＮ４上のアクセスポイント３へ、ＬＡＮ４を介してＳＩＰプロキシ７へ、インターネット６を介してＳＩＰプロキシ１１へ、ＬＡＮ１０を介してパーティＢのＩＰ電話９へ通信される。パーティＢのＩＰ電話９は、ＳＰＡＷＮ ＳＩＰメッセージを受信し、パーティＡのＩＰ電話２に２００ ＯＫ ＳＩＰメッセージを送り返すことにより応答する。しかしながら、この２００ ＯＫ ＳＩＰメッセージは、ＳＰＡＷＮ ＩＤ（ＳＰＡＷＮ識別子）を含んでいる。ＩＰ電話９は、ＦＲＯＭフィールド、ＴＯフィールド、ＣＡＬＬ−ＩＤフィールド、及び第１のセッションのＣＳＥＱ番号のハッシュを生成することによって、ＳＰＡＷＮ ＩＤを生成する。このＳＰＡＷＮ ＩＤは、将来の参照のためにＩＰ電話９内に格納され、第２のセッションが第１のセッションと関連付けられる。本例では、ＳＰＡＷＮ ＩＤは、２００ ＯＫ ＳＩＰメッセージ内のフィールド名“ＳＰＡＷＮ−ＩＤ”に続く１６バイトキャラクタストリングである。ＳＰＡＷＮ ＩＤを含む２００ ＯＫ ＳＩＰメッセージは、ＳＩＰプロキシ１１及びＳＩＰプロキシ７を介してＩＰ電話２に転送される。
【００３０】
図９は、ＳＰＡＷＮ ＳＩＰ要求と、ＳＰＡＷＮ ＩＤ及びＡＣＫを含む２００ ＯＫとを含むＳＩＰトランザクションを例示するブロック図である。例示するように、このトランザクションは第１のＳＩＰセッションにおいて生じる。
【００３１】
図１０は、２００ ＯＫを受信すると、第２のＩＮＶＩＴＥ ＳＩＰ要求を発行する次のステップを例示するブロック図である。ＩＰ電話２内の黒い点はＩＰアドレスを表わす。第２のＩＮＶＩＴＥ要求は、ＳＰＡＷＮ ＩＤを含んでおり、パーティＡのＩＰ電話２からパーティＢのＩＰ電話９へ通信される。この第２のＩＮＶＩＴＥ要求は、ＣＤＭＡセルラ電話リンクを介してＩＰ電話２から、セルラ電話ネットワーク５上のアクセスポイント（ＢＴＳ又は基地送信サイトとも呼ばれる）３０へ通信され、次に、セルラ電話ネットワーク５を介してＳＩＰプロキシ＃３（ＳＩＰプロキシ８）へ通信される。この通信は、ＩＰ電話２におけるＩＰアドレス＃３における一端、及びその他の端において終端するＴＣＰ接続を介して、ＳＩＰプロキシ８のセルラ電話ネットワーク側ＩＰアドレスへ通信される。そして、第２のＩＮＶＩＴＥ要求が、インターネット６を介してＳＩＰプロキシ８から、他のＴＣＰ接続を介してＳＩＰプロキシ１１へと転送される。この第２のＩＮＶＩＴＥ要求は、その後、ＬＡＮ１０を介してＳＩＰプロキシ１１から、別のＴＣＰ接続を介してパーティＢのＩＰ電話９へと転送される。
【００３２】
パーティＢのＩＰ電話９は、既に存在するアクティブセッション（第１のセッション）によって、通常は、到来するＩＮＶＩＴＥ要求を拒絶するが、本発明では、パーティＢのＩＰ電話９内のＳＩＰレイヤ機能が、到来する第２のＩＮＶＩＴＥ要求のＳＰＡＷＮ ＩＤを認識し、それ自身のＲＴＰストリームを開くことを含む第２のセッションを確立アップし、この第２のセッションを第１のセッションに関連付ける。ＩＰ電話９は、ＳＰＡＷＮ ＩＤを、格納されたＳＰＡＷＮ ＩＤのリストと比較することによって、到来する第２のＩＮＶＩＴＥ要求のＳＰＡＷＮ ＩＤを認識する。
【００３３】
図１０Ａは、ＩＰ電話９内で動作するソフトウェアの構造の簡略図である。ＩＰ電話９は、２００ ＯＫ ＳＩＰメッセージを、パーティＡのＩＰ電話２へ返すことによって応答する。ＩＰ電話２は、ＩＰ電話９にＡＣＫを返すことによって、トランザクションを終了する。第２のＩＮＶＩＴＥ要求、２００ ＯＫ、及びＡＣＫは、ＣＤＭＡ無線リンク及びＣＤＭＡ ＢＴＳ３０を介してＩＰ電話２と通信される。
【００３４】
図１１は、アクティブな第１のセッションと、現在初期化されたアクティブな第２のセッションとを例示する図である。第２のセッションはアクティブであるが、データペイロードパケットは、ＩＰ、ＵＤＰ、及びＲＴＰを用いて、第２のセッションにおいて、まだ通信されていない。（ＩＰ電話２とアクセスポイント３との間の８０２．１１通信を含む）第１のセッションは、第１のＣＡＬＬ−ＩＤを有する。一方、（ＩＰ電話２とセルラＢＴＳ３０との間のＣＤＭＡ通信を含む）現在初期化されている第２のセッションは、第２のＣＡＬＬ−ＩＤを有する。
【００３５】
図１２は、ＩＰ電話２とＩＰ電話９との間のペイロードデータメディアフローが、第１のセッションから第２のセッションへと切り換わる（すなわち、「ハンドオフ」される）次のステップを例示する。矢印３１，３２は、パーティＡのＩＰ電話２と、パーティＢのＩＰ電話９との間のペイロードデータメディアフローＶｏＩＰパケットの初期フローを例示する。データ制御ハンドオフパケットが、ＩＰ、ＵＤＰ、及びＲＴＰを用いて、パーティＡのＩＰ電話２から、パーティＢのＩＰ電話９へ送られる。本例では、このデータ制御ハンドオフパケットは、ＳＩＰプロキシ７，１１を介して第１のセッションで通信されるが、このデータ制御ハンドオフパケットはまた、ＳＩＰプロキシ８，１１を介して第２のセッションで通信される。矢印３３は、データ制御ハンドオフパケットの転送を示す。データ制御ハンドオフパケットは、一例として、ＳＷＩＴＣＨ−ＦＲＯＭ：フィールド名と、ＳＷＩＴＣＨ−ＴＯ：フィールド名とを含むＳＩＰメッセージである。データ制御ハンドオフパケットは、ＩＰ電話９へ通信するために使用され、次のデータペイロードパケットが、第２のセッションで送られる。データ制御ハンドオフパケットの起こりうる損失に対処するために、パーティＢは、ＩＰアドレス＃３を用いるパーティＡのＩＰ電話２によって発信された制御パケットを拒否しないことが命じられる。
【００３６】
図１３は、第１のセッションにおいてＩＰ電話２からＩＰ電話９へ通信されるデータペイロードパケットに続くメディアフローハンドオフ制御パケット３４を例示する。
【００３７】
図１４は、メディアフローハンドオフ制御パケット３４のブロック図である。メディアフローハンドオフ制御パケットを送った後、ＩＰ電話２は、第１のセッションにおいて、メディアストリームのデータペイロードを送ることから、第２のセッションにおいて、メディアストリームのデータペイロードを送ることに切り換える。本例におけるメディアストリームは、音声会話である。ＩＰ電話９がメディアフローハンドオフ制御パケットを受信した場合、ＩＰ電話９は、第２のセッションにおいて、次のデータペイロードパケットを受信し、これらパケットのデータペイロードを、ＦＩＦＯ（first-in-first out）メモリ内の、第１のセッションにおいて以前に受信したパケットのデータパケットの後にバッファする。このデータペイロードはＦＩＦＯから出力され、ＲＴＰシーケンス番号及びタイムスタンプにしたがって順序付けられるように、ＩＰ電話９のユーザに提供される。したがって、メディアストリームのデータペイロードは、認識できるほど通話が破壊されることなく、第１のアクティブなセッションから第２のアクティブなセッションへとシームレスに切り換えられる。第１のセッションも第２のセッションも、切換回路部を含んでいない。第１のセッションも第２のセッションも、ＶｏＩＰパケットを含んでおり、ＩＰ電話９は、２つのセッションを知っている。２つのセッションは、３方式の通話を構成しない。更に、ＳＩＰプロキシ７，８，１１は、この斬新なＳＰＡＷＮ方法をサポートする如何なる特別な機能も含まない標準的なＳＩＰプロキシである。図１２では、矢印３４，３５は、第２のセッションにおける次のＶｏＩＰデータペイロードパケットのフローを例示する。
【００３８】
図１５は、データ制御ハンドオフパケットが第１のセッションにおいて通信された後の、第２のセッションにおけるデータペイロードＶｏＩＰパケットのフローを例示する。ＩＰ電話２は、フローデータパケットペイロードＶｏＩＰパケットを、必要に応じて、又は希望に応じて、第１のセッションと第２のセッションとの間で切り換えることができる。
【００３９】
図１６は、次のステップを例示する。このステップでは、ＩＰ電話２が、ＩＰ電話９にＳＩＰ ＢＹＥメッセージを送ることによって、第１のセッションを終了する。８０２．１１無線リンクの信号強度が低下する場合、ＩＰ電話２とアクセスポイント３との間の通信が存在している間、このＳＩＰ ＢＹＥメッセージが送られる。このＢＹＥメッセージが送信され受信された後、第１のセッションが終了し、メディアストリームのためのデータペイロードパケットの通信を維持するために第２のセッションが使用される。
【００４０】
図１７は、第１のセッションが終了した後、第２のセッションにおけるデータペイロードＶｏＩＰパケットのフローを示す。
【００４１】
上述した例は、８０２．１１リンクを有する第１のセッションから、ＣＤＭＡリンクを有する第２のセッションへの切換を含むが、これはそうである必要はない。別の例では、第１のセッションが、ＣＤＭＡ無線リンクを含み、第２のセッションが、８０２．１１無線リンクを含む。そのような状態は、パーティＡが最初はセルラＢＴＳ３０を介したＣＤＭＡ通信を用いており、次に、アクセスポイント３のローカル有効範囲領域に到達する場合に生じる。ＣＤＭＡサービス及び８０２．１１サービスともに、アクセスポイント３のローカル有効範囲領域内で利用可能であるが、上述した本方法は、８０２．１１無線リンクを含む第２のセッションをセットアップするために使用される。その後、データペイロードＶｏＩＰパケットのフローが、ＣＤＭＡ第１のセッションから、８０２．１１第２のセッションへと切り換えられる。ＣＤＭＡリンクの使用に関する課金を避けるために、第２のセッションが一旦アクティブになり、ＶｏＩＰメディアストリームのデータペイロードを取り扱うと、ＣＤＭＡリンクを有する第１のセッションが終了する。
【００４２】
図１８は、代替データフローハンドオフメカニズムを示す。１つのセッションから別のセッションへのデータペイロードＶｏＩＰパケットの切り換えをシグナルするためにハンドオフ制御パケットを送るのではなく、ＩＰ電話２は単に、第２のセッションにおいて、データペイロードＶｏＩＰパケットを通信し始める。矢印３６は、パーティＡからパーティＢへと通信される最初のデータペイロードＶｏＩＰパケットを表す。パーティＢが第１のセッションにおいてデータペイロードＶｏＩＰパケットを受信した場合、パーティＢは、第１のセッションにおいてパーティＡへ送ることを望んでいるあらゆるデータペイロードＶｏＩＰパケットを送ることによって応答する。パーティＢからパーティＡへのデータペイロードＶｏＩＰパケットのフローは、矢印３７によって示される。第１のセッションから第２のセッションへのデータペイロードＶｏＩＰパケットのフローを切り換えるために、パーティＡは単に、第２のセッションにおいて、データペイロードＶｏＩＰパケットをパーティＢへ送ることを開始する。このフローは、矢印３８によって表わされる。パーティＢが、第２のセッションにおいて、データペイロードＶｏＩＰパケットを受信し始めると、パーティＢは、第２のセッションにおいてパーティＡへ送ることを望んでいる次のあらゆるデータペイロードＶｏＩＰパケットを送ることによって応答する。第２のセッションにおけるパーティＢからパーティＡへのデータペイロードＶｏＩＰパケットのフローは、矢印３９によって表される。
【００４３】
パーティＢが、ＩＰ電話において終端するＴＣＰ接続を介してＶｏＩＰデータペイロードパケットが送られるＩＰ電話を有するシステムについて上述したが、パーティＢは、ＩＰ電話を有しておらず、メディアゲートウェイを経由するＩＰテレフォニーを用いることもできる。通話がパーティＢへの通話である場合、このメディアゲートウェイがＶｏＩＰ通話を受信し、パーティＢへの従来式の第２の通話を行い、ＶｏＩＰ通話とこの従来式の第２の通話との間でペイロード情報を中継する。通話がパーティＢから発信された通話である場合、パーティＢが、メディアゲートウェイへ従来式の通話を行い、メディアゲートウェイが、意図する呼出先へと第２のＶｏＩＰ通話を行い、メディアゲートウェイが、従来式の通話とＶｏＩＰ通話との間でペイロード情報を中継する。したがって、メディアゲートウェイは、パーティＢのためのダミーのＩＰ電話として動作する。
【００４４】
上述した例におけるＩＰ電話９は、陸線ＩＰ電話であるが、他の例では、ＩＰ電話９は、（例えば、セルラ電話のような）モバイル無線通信デバイスである。第１及び第２のセッションは、モバイルＩＰ電話か陸線ＩＰ電話かの何れかによって開始することができる。
【００４５】
図１９は、第２の斬新な局面にしたがった方法の図である。モバイル通信デバイスは、第１のエアインタフェースと第２のエアインタフェースとを有する。第１のエアインタフェースは、第１のネットワーク上のトランシーバとモバイル通信デバイスとの間の第１の無線通信リンクによってＶｏＩＰ／ＶＩＰパケットを通信するために利用することができる。第２のエアインタフェースは、第２のネットワーク上のトランシーバとモバイル通信デバイスとの間の第２の無線通信リンクによってＶｏＩＰ／ＶＩＰパケットを通信するために利用することができる。一例において、モバイル通信デバイスは、ＩＰ電話として動作可能なセルラ電話である。図１９の方法が実現される代表的なシステムは、図１に例示するシステムである。セルラ電話はＩＰ電話２である。ＩＰ電話２の第１のエアインタフェースは８０２．１１インタフェースであり、第１の無線通信リンクは、ＩＰ電話２とローカルエリアネットワーク（ＬＡＮ）４との間のセルラ電話リンクである。ＩＰ電話２の第２のエアインタフェースはセルラ電話インタフェースであり、第２の無線通信リンクは、ＩＰ電話２とセルラ電話ネットワーク５との間のセルラ電話リンクである。
【００４６】
図１９に例示する方法におけるステップ１００では、パーティＡが、第１のセッションにおいてパーティＢと通信するために、モバイル通信デバイス（例えばＩＰ電話２）を用いる。記載されている例では、パーティＢはＩＰ電話９を使用している。第１のセッション（例えば、しばしば「ＳＩＰ ＲＴＰセッション」、「ＳＩＰセッション」、または「ＶｏＩＰセッション」と呼ばれるＳＩＰによって確立されたＲＴＰセッション）が、図１乃至図５に関連して上述したような１つの例において確立される。モバイル通信デバイスは、第１のエアインタフェースを使用して、第１のセッションにおいて、メディアストリームのデータペイロードを送信する。
【００４７】
次に（ステップ１０１において）、パーティＡは、図６に関連して上述したように、第１のネットワーク４上の無線アクセスポイント３からＩＰ電話２を移動させる。この移動の結果、ＩＰ電話２と無線アクセスポイント３との間の無線通信リンクによって与えられるサービス品質が低下する。このサービス品質の低下は、例えば、以下のうちの１または複数を含みうる。第１のセッションにおいてＩＰ電話２からＩＰ電話９へ通信することが可能なデータペイロードビットレート（ビット／秒）の減少、第１のセッションにおいてＩＰ電話９からＩＰ電話２へ通信することが可能なデータペイロードビットレート（ビット／秒）の減少、第１のセッションにおいてＩＰ電話２からＩＰ電話９へ単位時間あたりに通信されるＲＴＰパケットの合計数の減少、第１のセッションにおいてＩＰ電話９からＩＰ電話２へ単位時間あたりに通信されるＲＴＰパケットの合計数の減少、ＩＰ電話２からＩＰ電話９への第１のセッションにおける通信中に喪失されるＲＴＰパケット数の増加、ＩＰ電話９からＩＰ電話２への第１のセッションにおける通信中に喪失されるＲＴＰパケット数の増加、ＩＰ電話２またはＩＰ電話９の何れかへ到来するパケットの到着の間におけるジッタの増加、ＩＰ電話２からＩＰ電話９へとパケットを完全に通信するために必要とされる時間（しばしば、レイテンシと呼ばれる）の増加、ＩＰ電話９からＩＰ電話２へとパケットを完全に通信するために必要とされる時間の増加。サービス品質の減少によって、ＩＰ電話２によって、アクセスポイント３によって、あるいはこれら両方によって検出されるように、ＲＦ信号強度が低下することが明らかになりうる。
【００４８】
ＩＰ電話２は、サービス品質の１または複数の表示を使用して、サービス品質の低下を検出する（ステップ１０１）。ＩＰ電話２が、サービス品質の低下を検知することができる多くの方法がある。一例では、ＩＰ電話２は、ＩＰ電話９から、第１セッションにおいて、ＲＴＣＰ（リアルタイム制御プロトコル）受信機レポート（ＲＲ）パケットを受信する。これらＲＴＣＰ受信機レポートは、第１セッションにおいて、ＩＰ電話９上で受信されたパケットの総数を含んでいる。ＩＰ電話２は、引き続くＲＴＣＰ受信機レポートにおけるパケット値の総数から、最初のＲＴＣＰ受信機レポートにおけるパケット値の総数を引くことにより、時間内においてＩＰ電話９へと受信されたパケット数を判定する。ＩＰ電話２は、２つのＲＴＣＰレポート間の時間差を判定し、次に、この時間差から、時間内において受信された判定されたパケット数を分割する。これによって、単位時間毎にＩＰ電話９へ受信される適切なパケット数を得ることができる。この値は、１つの実施形態では、サービス品質の評価として使用される。
【００４９】
ＩＰ電話２は、規則的ベースで定期的にサービス品質の低下を検出するためにこの動作を行い、単位時間毎に第１のセッションにおいてＩＰ電話９上で受信されたパケット数を追跡する。単位時間当たりにＩＰ電話９上で受信されたパケット数が閾レベルを下回った場合、ＩＰ電話２は、第２のＶｏＩＰセッションに対して、ＩＰ電話２とＩＰ電話９との間の通信を確立させる（ステップ１０２）。第２のセッションは、ＩＰ電話２の第２のエアインタフェースを用いて、セルラ電話ネットワーク５上のアクセスポイント３とＩＰ電話２との間の通信を含む。
【００５０】
サービス品質の低下を検出する別の方法は、連続したＲＴＣＰ受信機レポートの到着間ジッタフィールド、喪失カウントフィールド、および／または喪失比（喪失したパケット比）フィールドの使用を含む。これらフィールドにおける値から、到着間ジッタと喪失したパケットの合計数が時間にわたってモニタされる。単位時間毎に喪失したパケット数が、閾レベルよりも増加した場合、あるいは、到着間ジッタが、閾レベルよりも増加した場合には、サービス品質が低下したとの判定がなされる。
【００５１】
第２のセッションは、任意の適切な方法を用いて確立される。ここで記載される例では、図７乃至図１１に関連して上述した方法を用いて第２のセッションが確立される。ＩＰ電話２は、第１のセッションを識別するＳＩＰ ＳＰＡＷＮメッセージをＩＰ電話９へ通信する。ＩＰ電話９は、ＳＩＰ ＯＫメッセージをＩＰ電話２へ戻すことによって応答する。ＳＩＰ ＯＫメッセージは、ＳＰＡＷＮ識別子を含んでいる。そして、ＩＰ電話２は、ＳＰＡＷＮ識別子を含むＳＩＰ ＩＮＶＩＴＥメッセージをＩＰ電話９へ通信する。ＩＰ電話９は、ＳＩＰ ＩＮＶＩＴＥメッセージを受信し、第２のセッションを確立し、ＳＩＰ ＩＮＶＩＴＥメッセージを用いて、第２のセッションを第１のセッションに関連付ける。
【００５２】
第２のセッションが一旦アクティブになると、第１のセッションを終了するのではなく、第２の斬新な局面の方法にしたがってＩＰ電話２とＩＰ電話９との間の単一のメディアストリームのＶｏＩＰ／ＶＩＰパケットを通信するために、第１のセッションと第２のセッションとの両方が同時に使用される。この単一のメディアストリームは、例えば、パーティＡの音声を表す音声データでありうる。音声データメディアストリームは、ＶｏＩＰ／ＶＩＰパケットのデータペイロードで伝送される。例えば、メディアストリームの音声データの４つのセグメントが、以下のようにして、ＩＰ電話２からＩＰ電話９へ通信されうる。すなわち、第１の音声データが、第１のセッションを介して、第１のＶｏＩＰ／ＶＩＰパケットで通信され、次に、第１の音声データに続く第２の音声データが、第２のセッションを介して、第２のＶｏＩＰ／ＶＩＰパケットで通信され、次に、第２の音声データに続く第３の音声データが、第１のセッションを介して、第３のＶｏＩＰ／ＶＩＰパケットで通信され、次に、第３の音声データに続く第４の音声データが、第２のセッションを介して、第４のＶｏＩＰ／ＶＩＰパケットで通信される。したがって、音声データは、２つのセッションを介して、インタリーブ方式で通信される。ＲＴＰプロトコルにしたがって、ＶｏＩＰ／ＶＩＰパケットはそれぞれ、ＲＴＰシーケンス番号と同様、ＲＴＰタイムスタンプを有する。ＩＰ電話９は、第１のセッションおよび第２のセッションを介して、ＩＰ電話９へ到来するＶｏＩＰ／ＶＩＰパケットを受信し、メディアストリームを再構築できるように、ＲＴＰタイムスタンプおよび／またはＲＴＰシーケンス番号を用いてデータペイロードを順序付ける。４つのＶｏＩＰ／ＶＩＰパケットが単一のメディアストリームの音声データを伝送する上述した例では、データペイロードが、第１のデータペイロード、第２のデータペイロード、第３のデータペイロード、第４のデータペイロードのような順序でＩＰ電話９によって順序付けられる。ＩＰ電話９は、データペイロードを適切に順序付けるために、ＲＴＣＰシーケンス番号とＲＴＣＰタイムスタンプとを用いる。適切に順序付けられたデータペイロードは、再構築メディアストリームを構成する。
【００５３】
１つの実施形態では、メディアストリームの同じ数からなるデータペイロードは、単位時間当たりに常に第１のセッションおよび第２のセッションで通信される。あるいは、単位時間当たりに第１のセッションで通信されるデータペイロードの、第２のセッションで通信されるデータペイロードに対する比率は、変えられる。このデータペイロードの比率は、第１のセッションのサービス品質の評価と、第２のセッションのサービス品質の評価との間の関係によって決定される。サービス品質の様々な異なる表示は、セッションのサービス品質の尺度として使用することができる。例えば、ＩＰ電話２は、第１のセッションにおいて、ＩＰ電話９からＲＴＣＰ受信機レポートパケットを受信する。
【００５４】
ＩＰ電話２は、ＲＴＣＰ受信機レポートで受信した合計パケット数を用いて、第１のセッションのサービス品質の評価を行い、第２のセッションのサービス品質の評価を行う（ステップ１０４）。例えば、第１のセッションにおいて、単位時間当たりにＩＰ電話９上で受信されたパケット数が、第２のセッションにおいて、単位時間当たりにＩＰ電話９上で受信されたパケット数よりも低下した場合、ＩＰ電話２とＬＡＮアクセスポイント３との間の第１の無線通信リンクに問題があろう。したがって、ＩＰ電話２は、インタリーブ方式で、第１のセッションおよび第２のセッションを介して、メディアストリームの連続的なデータペイロードを通信する（ステップ１０５）。ここで、ＩＰ電話２から、第１のセッションによって送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションによって送信されるＶｏＩＰ／ＶＩＰパケットに対する比率は、第１のセッションを用いて利用可能な評価済みサービス品質の、第２のセッションを用いて利用可能な評価済みサービス品質に対する比率に設定される。１つのセッションで利用可能なサービスの、他のセッションで利用可能なサービスに対する相対的な品質が変わると、ＩＰ電話２もまた、第１のセッションによって送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションによって送信されるＶｏＩＰ／ＶＩＰパケットに対する比率を変える。第１のセッションか第２のセッションの何れかを用いて利用可能なサービス品質が、ＩＰ電話２からＩＰ電話９へ所望のメディアストリーム情報を通信するのに適切ではない場合、第１のセッションと第２のセッションとを組み合わせた通信機能が適切であるかもしれず、また、通信負荷を共有するために使用され、何れかのセッションのみを用いることでは利用できないサービス品質特性が達成される。
【００５５】
図２０は、第２の斬新な局面にしたがって、ＩＰ電話２からＩＰ電話９へと通信されるＶｏＩＰ／ＶＩＰパケットを図示する簡略図である。この図では、上側の時間軸が、第１のセッションを用いたＩＰ電話２からＩＰ電話９への通信を表す。下側の時間軸は、第２のセッションを用いたＩＰ電話２からＩＰ電話９への通信を表す。時間は左から右へ進む。このブロック図は横軸においてスケールするべきではないが、様々なＶｏＩＰ／ＶＩＰパケットの互いの相対的なタイミングを示すように表される。
【００５６】
先ず、期間１０６では、１乃至４と示された一連のＶｏＩＰ／ＶＩＰが、第１のセッションを用いて通信される。次に、時間１０７において、第１のセッションにおいてサービス品質の低下が検出され、第２のセッションが確立される。その後、５乃至１０と示された６つのＶｏＩＰ／ＶＩＰパケットは、第１のセッションと第２のセッションとの両方を用いて、ＩＰ電話２から、インタリーブ方式で通信される。２つのセッションにおいて単位時間当たりに通信されるＶｏＩＰ／ＶＩＰパケットの数は、同じである。なぜなら、第１のセッションによって提供されるサービス品質の評価は、第２のセッションによって提供されるサービス品質の評価と実質的に同じだからである。図示する例において、この条件は、第１のセッションと第２のセッションとの間のサービス品質の相対的な評価が変わる時間１０８まで続く。第１のセッションによって提供されるサービス品質は、第２のセッションによって提供されるサービス品質よりも２倍良いと判定される。したがって、時間１０８で始まって、第１のセッションでは、第２のセッションよりも、単位時間あたりに２倍の数のＶｏＩＰ／ＶＩＰパケットが通信される。１１乃至１６と示された更に６つのＶｏＩＰ／ＶＩＰパケットが、時間１０８の後に通信されていることが示される。
【００５７】
ＩＰ電話２が、第１のセッションで送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションで送信されるＶｏＩＰ／ＶＩＰパケットに対する比率を定期的に調節するのと同じ方法で、ＩＰ電話９もまた、ＩＰ電話２へ、第１のセッションで送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションで送信されるＶｏＩＰ／ＶＩＰパケットに対する比率を定期的に調節することができる。ＩＰ電話９は、例えば、第１のセッションについて、ＩＰ電話２からＲＴＣＰ受信機レポートを受信し、第２のセッションについても、ＩＰ電話２からＲＴＣＰ受信機レポートを受信しうる。ＩＰ電話９は、これら受信機レポートにおける情報を用いて、第１のセッションによって提供されるサービス品質と、第２のセッションによって提供されるサービス品質との評価を行う。そして、ＩＰ電話９は、１つのセッションによって提供されるサービス品質の評価の、他のセッションによって提供されるサービス品質の評価に対する比率が同じになるように、ＩＰ電話２へ、第１のセッションで通信されたＶｏＩＰ／ＶＩＰパケットの、第２のセッションで通信されたＶｏＩＰ／ＶＩＰパケットに対する比率を調節する。
【００５８】
図２１は、第２の斬新な局面にしたがってＩＰ電話９からＩＰ電話２へ通信されるＶｏＩＰ／ＶＩＰパケットを例示する簡略図である。この図では、第１の６つのＶｏＩＰ／ＶＩＰパケットが、時間１０９の前に、第１のセッションで通信される。ＩＰ電話９は、第１のセッションによって提供されるサービス品質の評価を行い、第２のセッションによって提供されるサービス品質の評価を行う。図示する例では、２つのセッションは、同じサービス品質を提供しているものと判定される。したがって、時間１０９の後、ＩＰ電話９は、第１のセッションにおいてＶｏＩＰ／ＶＩＰパケットの半分を送信し、第２のセッションにおいてその半分を送信する。図２０において、通信されるＶｏＩＰ／ＶＩＰパケットの相対比率が変わる時は、図２１において、通信されるＶｏＩＰ／ＶＩＰパケットの相対比率が変わる時と異なる。これは、２つの方向において使用されるセッションの相対比率が、同じになる必要はないという点を示している。
【００５９】
したがって、到来するメディアストリームのＲＴＰデータペイロードを通信するために、および、発信されるメディアストリームのＲＴＰデータペイロードを通信するために、ＩＰ電話２の両方のエアインタフェースが使用されることが理解される。２つのエアインタフェースのうちの１つを用いることは、それを介する通信が完全に喪失した場合に停止されうる。２つのエアインタフェースのうちの１つを用いることはまた、他のエアインタフェースを介した通信が十分に良好であり、その１つのエアインタフェースのみを用いることを保証できるのであれば停止される。どれだけの数のエアインタフェースを使用するか、および、どれだけの割合にするかの判定は、単純な関数であるか、多くの変数を含む関数でありうる。これら変数は、コスト情報およびサービス品質の表示を示す。
【００６０】
単位時間当たりにセッションにおいて受信される合計パケット数が変わる理由は多くある。第１の無線通信リンクは、ＩＰ電話２からＩＰ電話９への通信パス全体のうちのほんの一部であることが認識される。そのため、セッションで受信される合計パケット数の減少は、データを通信するための第１の無線リンクの能力の低下のせいであるとは全く考えられないかもしれない。したがって、単位時間当たりに受信される合計パケット数を含む上述したものとは異なるサービス品質の評価が適用されうる。一例では、ＲＴＣＰ受信機レポートパケットが適用されず、無線アクセスポイント３が、第１の無線リンクのパフォーマンスに関するサービス品質情報（例えば、瞬時ビットレート情報、および／または、アクセスポイントで検出されたＲＦ信号強度の表示）を保持する。このサービス品質情報は、ＭＡＣレイヤ通信、または、ＲＴＰレイヤやＳＩＰレイヤの下のその他の通信を用いて、無線アクセスポイント３からＩＰ電話２へと通信される。ＩＰ電話２は、セルラアクセスポイント３０から、第２の無線通信リンクに関する同様なサービス品質情報を受信する。２つの無線通信リンクに関するサービス品質情報は、その後、２つのセッションによって与えられる相対的なサービス品質の評価を行うために使用される。
【００６１】
ある特定の実施形態が、説明目的のために上述されたが、本発明はそれに限定されない。第２の斬新な局面における第２のセッションの確立を引き起こすイベントは、全てのケースにおいて、第１のセッションにおけるサービス品質の低下である必要はない。一例では、第１のセッションによって提供されるサービス品質の実質的な低下は検出されず、単位時間当たり通信されるメディアストリームのデータ量が増加し、所望の方法（例えば、所望の最大レイテンシ）でメディアストリームのデータを通信するために第１のセッションはもはや適切ではなくなる。それに応じて、メディアストリームのデータのうちの過剰なデータを通信するために第２のセッションが確立される。過剰なデータが通信され、単位時間当たりに通信されるデータ量がそのオリジナルのレベルへと低下すると、第２のセッションはもはや必要とされず、控えめに使用されるか、あるいは、終了する。したがって、第２の斬新な局面は、第１のセッションに過度に負荷をかけて、第１のセッションの通信における望ましくないレイテンシをもたらしうるデータのスラッグを通信するために使用することができる。そのようなデータスラッグの例は、電話会話の間に通信される静止画像情報およびビデオ情報を含む。第２の斬新な局面の例が、２つのエアインタフェースを介して、インタリーブ方式でパケットを通信するモバイル通信デバイスに関連付けられて上述されたが、モバイル通信デバイスは、３またはそれ以上のエアインタフェースを介し、第２の斬新な局面に従うインタリーブ方式でパケットを通信することができる。したがって、上述した具体的実施形態の様々な特徴の変更、適応、及び組み合わせは、特許請求の範囲で述べられた本発明の範囲から逸脱することなく実施することができる。
【図面の簡単な説明】
【００６２】
【図１】図１は、１つの斬新な局面にしたがったＩＰ（Internet Protocol）テレフォニー通信システム１の簡略トポロジカルブロック図である。
【図２】図２は、図１のシステムにおけるＩＰ電話２とＳＩＰプロキシ７との間のＴＣＰ接続を例示する。
【図３】図３は、斬新な方法にしたがった第１のステップのブロック図である。
【図４】図４は、斬新な方法にしたがって第１のセッションをセットアップするＳＩＰ ＩＮＶＩＴＥ要求のブロック図である。
【図５】図５は、第１のセッションの初期化を例示する。
【図６】図６は、パーティＡが、図１のシステムのアクセスポイント３からＩＰ電話２を移動する第１のセッションを例示する。
【図７】図７は、本斬新な方法にしたがって、ＩＰ電話２からＩＰ電話９へ送られるＳＰＡＷＮ ＳＩＰメッセージの図である。
【図８】図８は、本斬新な方法にしたがって、ＳＰＡＷＮ ＳＩＰメッセージの通信を例示するブロック図を示す。
【図９】図９は、図１のシステムによるＳＰＡＷＮ ＳＩＰメッセージの通信、及び、ＳＰＡＷＮ ＩＤを含む２００ ＯＫ ＳＩＰメッセージを戻すことを例示する。
【図１０】図１０は、本斬新な方法にしたがって第２のセッションを初期化するために、ＩＰ電話２からＩＰ電話９へ第２のＳＩＰ ＩＮＶＩＴＥ要求を送ることを例示する。
【図１０Ａ】図１０Ａは、ＩＰ電話９において実行するソフトウェアの構造の簡略図である。
【図１１】図１１は、アクティブな第１及び第２の両セッションを例示する。
【図１２】図１２は、第１のセッションから第２のセッションへとＶｏＩＰデータパケットを切り換えるようシグナルするために、メディアハンドオフ制御パケットを使用することを例示するブロック図である。
【図１３】図１３は、ＩＰ電話２からＩＰ電話９へのハンドオフ制御パケットの送信を例示する。
【図１４】図１４は、ハンドオフ制御パケットのブロック図である。
【図１５】図１５は、第２のセッションによるデータペイロードのフローを示す。
【図１６】図１６は、第１のセッションを終了するために、ＩＰ電話２からＩＰ電話９へＢＹＥ ＳＩＰメッセージを送信することを例示する。
【図１７】図１７は、第１のセッションの終了後における図１のシステムを例示する。ここで、メディアストリームのデータペイロードＶｏＩＰパケットは、もはや第１のセッションでは通信されていないが、第２のセッションにおいて通信されている。
【図１８】図１８は、メディアストリームのＶｏＩＰデータペイロードパケットが、第１のセッションにおいてもはや通信されていないが、第２のセッションにおいて通信されることをＩＰ電話９が判定する他の方法を例示する。
【図１９】図１９は、第２の斬新な局面にしたがった方法の図である。
【図２０】図２０は、第２の斬新な局面にしたがって、モバイル通信デバイスから第２のＩＰデバイスへ通信されるＶｏＩＰ／ＶＩＰパケットを例示する簡略図である。
【図２１】図２１は、第２の斬新な局面にしたがって、第２のＩＰデバイスからモバイル通信デバイスへ通信されるＶｏＩＰ／ＶＩＰパケットを例示する簡略図である。
【技術分野】
【０００１】
開示された実施形態は、一般に、ＩＰテレフォニーに関する。
【背景技術】
【０００２】
セルラ電話のようなモバイル通信デバイスは、複数のエアインタフェースを有しうる。一例では、セルラ電話は、従来、ＣＤＭＡ（符号分割多元接続）トランシーバを用いたセルラ電話ネットワークを用いて、比較的長距離にわたって通信をすることができる。セルラ電話のＣＤＭＡトランシーバは、セルラ電話ネットワーク上のセルラＢＴＳ（基地送信機サイト）と通信する。更に、セルラ電話は、ＩＥＥＥ ８０２．１１トランシーバを用いた無線ローカルエリアネットワーク（ＬＡＮ）を用いて、比較的短距離で通信することができる。セルラ電話の８０２．１１トランシーバは、ＬＡＮ上のアクセスポイントと無線で通信する。
【０００３】
第１のパーティは、ＶｏＩＰ（voice over Internet Protocol）技術を用いて第２のパーティへ通話するために、セルラ電話を使用することができる。音声データは、セルラ電話から、アクセスポイントへの８０２．１１無線リンク、ＬＡＮ、及びインターネットを介して、ＩＰパケットによって第２のパーティへと通信される。第１のパーティがそのような通話に従事している場合、第１のパーティが、２つのエアインタフェースを持つモバイル通信デバイスを移動させ、２つのアクティブなインタフェースが、完全よりも少ない有効範囲を持つようになるかもしれない。このような従来式のアプローチは、より良い有効範囲を持つインタフェースを用いることを開始し、より良いインタフェースを用いてＲＴＰのようなリアルタイムトラフィックを送ることを開始する。モバイル通信デバイスは、切り換わったインタフェース条で完全な有効範囲を持つ訳ではないので、サービス品質が影響を受ける。そして、選択されたインタフェースは、インタフェースについての有効範囲が完全に失われるまで、または、その他のインタフェースについての有効範囲が改善するまで、ＲＴＰデータを送るために使用される。解決策が望まれる。
【発明の開示】
【発明の概要】
【０００４】
モバイル通信デバイス（例えば、セルラ電話）は、無線ＬＡＮ（ローカルエリアネットワーク）との無線通信のための１つのエアインタフェースと、セルラ電話ネットワークとのセルラ電話通信のための別のエアインタフェースとを有する。無線ＬＡＮとの無線通信は、例えば、ＩＥＥＥ ８０２．１１に従いうる。セルラ電話ネットワークは、例えば、ＣＤＭＡ（符号分割多元接続）電話ネットワークでありうる。
【０００５】
第１の斬新な局面にしたがって、モバイル通信デバイスは、先ず、第１のセッションにおいて、エアインタフェースのうちの１つを介して、メディアストリームのデータペイロードＶｏＩＰパケットを、ターゲット通信デバイスへ送信するために使用される。ＶｏＩＰパケットは、ＩＰ（Internet Protocol）、ＵＤＰ（User Datagram Protocol）及びＲＴＰ（Real-Time Protocol）を用いて通信される。ＶｏＩＰメディアストリームは、例えば、モバイル通信デバイスを用いた第１のパーティＡと、ターゲット通信デバイスを用いた第２のパーティＢとの間の会話のための音声データを含む。
【０００６】
そして、モバイル通信デバイスの他のエアインタフェースを用いて通話を継続することが望まれる。これは、例えば、初めは短距離無線ＬＡＮインタフェースとして使用されているエアインタフェースによるものかもしれない。パーティＡは、短距離の無線ＬＡＮの有効範囲領域から出るかもしれない。より長距離のセルラ電話エアインタフェースを用いることに切り換えることによって、通話を継続することが望まれる。あるいは、第１のエアインタフェースを用いることから、第２のエアインタフェースへ切り換えることが望まれる。ここで、第１のエアインタフェースは、より長距離のセルラ電話インタフェースであり、第２のエアインタフェースは、より短距離の無線ＬＡＮインタフェースである。最初はセルラ電話エアインタフェースが使用されるが、次に、パーティＡが、無線ＬＡＮの有効範囲領域へ移動する。例えば、パーティＡのセルラ電話プロバイダが、そのセルラ電話ネットワーク上で音声会話を伝送することに課金するのであれば、パーティＡはそのセルラエアインタフェースを用いることをやめ、より費用の安い無線ＬＡＮエアインタフェースを用いて通話を継続することが望ましい。
【０００７】
最初に使用されていたエアインタフェースから別のエアインタフェースへ切り換えることを望む理由に関わらず、パーティＡのモバイル通信デバイスは、パーティＢのターゲット通信デバイスへＳＰＡＷＮ ＳＩＰメッセージを送る。ＳＰＡＷＮ ＳＩＰメッセージは、ＩＰ、ＴＣＰ(Transmission Control Protocol)、及びＳＩＰ(Session Initialization Protocol) を用いて通信される。ターゲットは、ＳＰＡＷＮ識別子を含む２００ ＯＫ ＳＩＰメッセージを送ることによって応答する。その後、モバイル通信デバイスは、他のインタフェースを介してＳＩＰ ＩＮＶＩＴＥ要求をターゲットへ送ることによって、他のエアインタフェースを介した第２のセッションをセットアップする。ＳＩＰ ＩＮＶＩＴＥ要求は、ＳＰＡＷＮ識別子を含んでいる。第２のセッションは初期化され、第１及び第２のセッションの両方が、アクティブなＶｏＩＰセッションとなる。どちらのセッションも、回路切換リンクを含む。ターゲット通信デバイスは、第１のセッションと第２のセッションとを関連付けるＳＩＰ ＩＮＶＩＴＥ要求で受信されるＳＰＡＷＮ識別子を用いる。
【０００８】
第２のセッションが一旦初期化されると、モバイル通信デバイスは、第１のセッションにおいて、メディアストリームのためＶｏＩＰパケットを送信することをやめ、第２のセッションにおいて、メディアストリームのため次のＶｏＩＰパケットを送信する。幾つかの実施形態では、モバイル通信デバイスからターゲットへとハンドオフ制御パケットが送られ、ターゲットに対して、次のＶｏＩＰパケットは第１のセッション内ではもはや受信されないが、第２のセッション内で受信されることを知らせる。他の実施形態では、メディアストリームのデータペイロードＶｏＩＰパケットはもはや第１のセッションにおいてターゲットによって受信されないので、ターゲットは、データペイロードＶｏＩＰパケットを通信するために第２のセッションが使用されているが、メディアストリームのデータペイロードＶｏＩＰパケットは第２のセッションにおいてターゲットによって受信されていると判定する。ＶｏＩＰパケットが、第２のセッションにおいて通信されていると、ターゲットがどのようにして判定するかに関わらず、パーティＡの通信デバイスとパーティＢの通信デバイスとの間の両方向におけるＶｏＩＰパケットのフローは、第２のセッションで生じ、第１のセッションでは生じない。
【０００９】
例えば、データペイロードＶｏＩＰパケットが、会話のための音声データを含んでいる場合、ＶｏＩＰパケットを受信する通信デバイスは、第２のセッションで受信したＶｏＩＰペイロードを、ＦＩＦＯ（first in first out）バッファ内に、第１のセッションで受信したＶｏＩＰパケットのペイロードの後にバッファする。ＶｏＩＰパケットは、ＲＴＰシーケンス番号及びタイムスタンプにしたがってＦＩＦＯ内に順序付けられる。ＦＩＦＯバッファの出力は、通信デバイスのユーザによって聞かれる音に変換される。
【００１０】
２つのセッションがアクティブなままである限り、データペイロードＶｏＩＰパケットのフローは、所望により、１つのセッションから別のセッションへと切り換えることができる。データペイロードＶｏＩＰパケットを通信するために使用されていないセッションは、所望により、停止することができる。第１のセッションを停止するために、モバイル通信デバイスは、ＳＩＰプロトコルにしたがって、ＳＩＰ ＢＹＥメッセージをターゲット通信デバイスへ送る。第２の斬新な局面にしたがって、モバイル通信デバイスは、第１のエアインタフェースと第２のエアインタフェースとの両方を有する。例えば、第１のエアインタフェースは、ローカルエリアネットワーク（ＬＡＮ）上の無線アクセスポイントと無線ＲＦ通信するためのＩＥＥＥ ８０２．１１インタフェースでありうる。例えば、第２のエアインタフェースは、セルラ電話ネットワーク上のアクセスポイントと無線ＲＦ通信するためのＣＤＭＡセルラ電話インタフェースでありうる。
【００１１】
ＶｏＩＰ／ＶＩＰ通話では、モバイル通信デバイスは、モバイル通信デバイスから第２のＩＰデバイスへと第１のセッションにおいてＶｏＩＰ／ＶＩＰパケットを通信するために第１のエアインタフェースを用いる。モバイル通信デバイス内のソフトウェアは、第１のセッションによって与えられたサービス品質に関して定期的に評価する。この評価が、サービス品質が不適当または受け入れられないレベルへ低下したことを示す場合、かつ、第２のエアインタフェースを使用することが可能な場合、モバイル通信デバイスは、モバイル通信デバイスと第２のＩＰデバイスとの間に第２のセッションが確立されるようにする。ここで、第２のセッションは、モバイル通信デバイスの第２のエアインタフェースを用いた通信を含んでいる。
【００１２】
第２のセッションが一旦確立されると、第１のセッションを終了するのではなく、モバイル通信デバイスから第２のＩＰデバイスへと単一のメディアストリームのＶｏＩＰ／ＶＩＰパケットを通信するために、第１のセッションと第２のセッションとの両方が使用される。一例では、単一のメディアストリームは、このモバイル通信デバイスを使用する人の声を表す音声データである。ＶｏＩＰ／ＶＩＰパケットは、インタリーブ方式で、第１のセッションおよび第２のセッションで、第２のＩＰデバイスへ送信される。第２のＩＰデバイスは、第１のセッションおよび第２のセッションからＶｏＩＰ／ＶＩＰパケットを受信する。そして、ＶｏＩＰ／ＶＩＰパケットのデータペイロードを順序付けるためにＲＴＰタイムスタンプおよび／またはＲＴＰシーケンス番号を用いる。これによって、単一のメディアストリームを再構築する。モバイル通信デバイスは、第１のセッションによって与えられるサービス品質と、第２のセッションによって与えられるサービス品質との定期的な評価を行う。１つの実施形態では、第１のセッションにおいてモバイル通信デバイスから送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションに対する比率は、第１のセッションのサービス品質の評価と、第２のセッションのサービス品質の評価との比率である。セッションのサービス品質評価の１つの例は、単位時間当たりに第２のＩＰデバイスによって、セッション内で受信されるパケット数である。第１のセッションにおいてモバイル通信デバイスによって送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションに対する比は、これら２つのセッションにおけるサービス品質の変化する評価を反映するために定期的に調節される。この比率は必ずしも計算された値である必要はないが、所与の期間内に、１つのセッションにおいて、他のセッションに比べて、どれくらい多くのＶｏＩＰ／ＶＩＰパケットが送信されるかを示す固有の結果である。セッションのサービス品質評価は、ＲＴＣＰレポートにおける情報、アクセスポイントから受信した検出信号強度情報、および／またはアクセスポイントから受信した瞬時ビットレート情報を含みうる。
【００１３】
モバイル通信デバイスから送信されるＶｏＩＰ／ＶＩＰパケットの比率が調節されるのと同じ方法で、第１のセッションにおいてモバイル通信デバイスへ送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションにおける場合に対する比率もまた調節される。モバイル通信デバイスから送信されるパケットの比率は、モバイル通信デバイスへ送信されるパケットの比率と同じである必要はない。モバイル通信デバイスおよび第２のＩＰデバイスにおけるサービス品質の評価を行うために使用されるメカニズムは必ずしも同一である必要はない。
【００１４】
更なる実施形態が、以下の詳細記述に記載される。この要約は、発明を定義することを意図していない。本発明は、特許請求の範囲によって定義される。
【詳細な説明】
【００１５】
図１は、１つの斬新な局面にしたがったＩＰ（Internet Protocol）テレフォニー通信システム１の簡略トポロジカルブロック図である。第１のパーティ（図１において「パーティＡ」と示す）は、例えばＩＰ電話２のようなモバイル無線通信デバイスを用いる。ＩＰ電話２は、図１においてＩＰアドレス＃１と示されたＩＰアドレスを有する。もしもＩＰ電話２が、アクセスポイント３の通信範囲内にあるのであれば、ＩＰ電話２は、ＬＡＮ（ローカルエリアネットワーク）４上のアクセスポイント３との短距離無線通信が可能である。この例では、ＩＰ電話２及びアクセスポイント３は、ＩＥＥＥ ８０２．１１仕様にしたがって通信する。ＬＡＮ４は、パーティＡが、ローカル領域内においてＩＰ電話２を移動することができ、アクセスポイントのうち少なくとも１つを経由してＬＡＮ４と通信し続けることができるように、複数のアクセスポイントを含む。
【００１６】
システム１は更に、セルラ電話ネットワーク５を含んでいる。この例において、セルラ電話ネットワーク５は、ＣＤＭＡ（符号分割多元接続）セルラ電話ネットワークである。またＩＰ電話２は、ＣＤＭＡセルラ電話ネットワーク５において、トランシーバを用いて長距離の無線通信を行うことができる。パーティＡは、ＩＰ電話２を用いて、ＣＤＭＡセルラ電話ネットワーク５によって通話を行ったり、受信する。ＩＰ電話２は、ＣＤＭＡセルラ電話通信のみならず、８０２．１１通信も可能であるので、ＩＰ電話２は、デュアルモードＩＰ電話と称される。
【００１７】
ＬＡＮ４及びセルラ電話ネットワーク５はＩＰネットワークに接続される。この例において、ＩＰネットワークは、インターネットすなわち「インターネット」６である。インターネット６は、複数の相互接続したルータを含んでいる。ＳＩＰプロキシ７は、ＬＡＮ４からインターネット６へ、また、インターネット６からＬＡＮ４へとＩＰパケットを通信できるように、ＬＡＮ４とインターネット６との両方に配置される。ＳＩＰプロキシ７は、ＬＡＮ４のＡＴＬＡＮＴＡ１．ＣＯＭドメインのためのインバウンドプロキシとアウトバウンドプロキシとの両方として動作する。ＳＩＰプロキシ７は、ＬＡＮ４上のサーバとして、及び、インターネット６上のクライアントとして動作する。ＳＩＰプロキシ７は、他のＳＩＰプロキシ及びＳＩＰセッション終点との間で、ＳＩＰ要求及びＳＩＰ応答を中継する。
【００１８】
他のＳＩＰプロキシ８は、セルラ電話ネットワーク５、及びインターネット６の両方に配置され、これによって、ＳＩＰプロキシ８は、セルラ電話ネットワーク５からインターネット６へ、及び、インターネット６からセルラ電話ネットワーク５へとＩＰパケットを通信することができる。ＳＩＰプロキシ８は、セルラ電話ネットワーク５のＡＴＬＡＮＴＡ２．ＣＯＭドメインのためのインバンドプロキシ及びアウトバウンドプロキシの両方として動作する。ＳＩＰプロキシ８は、セルラ電話ネットワーク５上のサーバとして、及び、インターネット６上のクライアントとして動作する。ＳＩＰプロキシ８は、他のＳＩＰプロキシ及びＳＩＰセッション終点との間で、ＳＩＰ要求及びＳＩＰ応答を中継する。
【００１９】
第２のパーティ（図１に示す「パーティＢ」）は、ＩＰ電話９のような第２の通信デバイスを有する。この例では、ＩＰ電話９は、モバイルＩＰ電話ではなく、むしろ、固定式の陸線ＩＰ電話である。ＩＰ電話９は、図１においてＩＰアドレス＃２と示されたＩＰアドレスを持っている。ＩＰ電話９は、ＬＡＮ１０を経由してインターネット６に接続される。ＬＡＮ１０は、例えば、パーティＢのインターネットサービスプロバイダ（ＩＳＰ）によって維持されるＬＡＮであるかもしれないし、又は、パーティＢの雇用者によって維持される企業ＬＡＮでもありうる。ＳＩＰプロキシ１１は、ＬＡＮ １０、およびインターネット６に配置される。ＬＡＮ１０からインターネット６へ、及び、インターネット６からＬＡＮ１０へとＩＰパケットを通信できるように、ＬＡＮ１０とインターネット６との両方に配置される。ＳＩＰプロキシ１１は、ＬＡＮ１０のＢＩＬＯＸＩ.ＣＯＭドメインのためのインバンドプロキシと、アウトバウンドプロキシとの両方として動作する。ＳＩＰプロキシ１１は、ＬＡＮ１０上のサーバとして、及び、インターネット６上のクライアントとして動作する。ＳＩＰプロキシ１１は、他のＳＩＰプロキシ及びＳＩＰセッション終点との間で、ＳＩＰ要求及びＳＩＰ応答を中継する。
【００２０】
図２は、ＩＰ電話２及びＳＩＰプロキシ７を示す。プロトコル処理レイヤのスタック１２は、ＳＩＰプロキシ７のハードウェアプラットフォーム上で動作する。ＳＩＰプロキシ７，８及び１１の各々で動作するプロトコル処理レイヤには、このようなスタックがある。スタック１２は、ＭＡＣレイヤ１３、ＩＰレイヤ１４、ＴＣＰレイヤ１５、及びＳＩＰレイヤ１６を含んでいる。ＭＡＣは「媒体アクセス制御」を表わす。ＩＰは「インターネットプロトコル」を表わす。ＴＣＰは「転送制御プロトコル」を表わす。ＳＩＰは「セッション初期化プロトコル」を表わす。ＩＰ電話２内のプロセッサは、プロトコル処理レイヤの類似のスタック１７を実行する。スタック１７は、ＩＰレイヤ１８、ＴＣＰレイヤ１９、及びＳＩＰレイヤ２０を含んでいる。スタック１２，１７の各々は、ＩＰレイヤ及びＴＣＰレイヤを含んでいるので、ＩＰ電話２とＳＩＰプロキシ７との間でＴＣＰ接続を確立することができる。図２では、ＩＰ電話２内の黒い点が、ＩＰ電話２のＩＰアドレス＃１を表わす。ＳＩＰプロキシ７内の黒い点は、ＩＰアドレスを表わす。左端の矢印は、ＩＰ電話２及びＳＩＰプロキシ７内で終端する第１のＴＣＰ接続２１を表わす。ＩＰプロトコル通信は、単なるベストエフォート通信だが、ＩＰに加えてＴＣＰを用いることによって、ＴＣＰ接続２１を介したＩＰ電話２とＳＩＰプロキシ７との間の情報の信頼できる通信が可能となる。ＴＣＰ接続２１が確立され、ＩＰ電話２とＳＩＰプロキシ７との間で維持されるのと同じ方法で、第２のＴＣＰ接続２２が確立され、ＩＰプロトコル処理レイヤとＴＣＰプロトコルレイヤとを含むスタック、及び、ＩＰアドレスを有するインターネット上の他のデバイスとＳＩＰプロキシ７との間で維持される。ＳＩＰプロキシ１１（図１参照）は、そのような１つのデバイスである。図２では、右端の矢印は、ＳＩＰプロキシ７で一端が終端し、ＳＩＰプロキシ１１で他端が終端している第２のＴＣＰ接続２２を表す。
【００２１】
図３は、斬新な方法にしたがった第１のステップのブロック図である。この図では、時間は、垂直のディメンションにおける上端から下端まで及ぶ。“パーティＡ”とラベルされたボックスと、このボックスから下の方向へ伸びる垂線は、ＩＰ電話２を表す。“パーティＢ”とラベルされたボックスと、このボックスから下の方向へ伸びる垂線は、ＩＰ電話９を表す。「ＳＩＰプロキシ＃１」とラベルされた垂線は、ＳＩＰプロキシ７を表わす。「ＳＩＰプロキシ＃２」とラベルされた垂線は、ＳＩＰプロキシ１１を表わす。
【００２２】
ＩＰ電話２内には、ＩＰ電話２がＬＡＮ４と通信している場合に使用されるＳＩＰプロキシの識別情報が格納されている。ＩＰ電話２は、ＩＰ電話２がセルラ電話ネットワーク５と通信している場合に使用される別のＳＩＰプロキシの別の識別情報を格納する。この例において、ＬＡＮ４と通信している場合に使用されるＳＩＰプロキシの識別情報は、ＰＲＯＸＹ１．ＡＴＬＡＮＴＡ１．ＣＯＭである。セルラ電話ネットワーク５と通信している場合に使用されるＳＩＰプロキシの識別情報は、ＰＲＯＸＹ３．ＡＴＬＡＮＴＡ２．ＣＯＭである。ＩＰ電話２はＬＡＮ４と通信しているので、ＩＰ電話２は、識別情報ＰＲＯＸＹ１．ＡＴＬＡＮＴＡ１．ＣＯＭを用い、この識別情報を解釈して、識別されたＳＩＰプロキシのＬＡＮ側のＩＰアドレスを取得する。この識別されたＳＩＰプロキシのＬＡＮ側のＩＰアドレスが、前のＳＩＰトランザクションでアドレスされたＳＩＰプロキシと関連付けられてＩＰ電話２内にキャッシュされると、このキャッシュされたＩＰアドレスは、ＳＩＰプロキシのＬＡＮ側のＩＰアドレスとして使用される。この識別されたＳＩＰプロキシのＬＡＮ側のＩＰアドレスが、ＩＰ電話２内にキャッシュされていないのであれば、ＩＰ電話２は、ＤＮＳサーバ（図示せず）にＤＮＳ要求を送る。ＤＮＳサーバは、この例では、ＬＡＮ４に配置される。ＤＮＳサーバは、各ＳＩＰプロキシに対するＩＰアドレスを含むルックアップテーブルを含む。ＤＮＳサーバは、ＩＰ電話２にＩＰアドレスを送り返すことによって、ＤＮＳ要求に応答する。この例では、ＩＰ電話２のＩＰアドレスは１０．３２．１．１４１である。識別されたＳＩＰプロキシのＬＡＮ側のＩＰアドレスを、ＩＰ電話２がどのようにして取得するかに関わらず、ＩＰ電話２は、ＳＩＰ呼出人又は発信人として動作し、ＩＰ電話２とＳＩＰプロキシ７との間のＴＣＰ接続２１を介して、ＳＩＰプロキシのＬＡＮ側のＩＰアドレスへＳＩＰ ＩＮＶＩＴＥ要求を送る。図３では、パーティＡからＡＴＬＡＮＴＡ１．ＣＯＭへ伸びる一番上の矢印２３は、このＳＩＰ ＩＮＶＩＴＥ要求の送信を示している。
【００２３】
図４は、ＳＩＰ ＩＮＶＩＴＥ要求のブロック図である。ＳＩＰ ＩＮＶＩＴＥ要求のヘッダフィールド部は、ＳＩＰ ＩＮＶＩＴＥ要求が、ＳＩＰアドレスＢＯＢ＠ＢＩＬＯＸＩ．ＣＯＭへ向けられていることを示している。ＳＩＰ ＩＮＶＩＴＥ要求のヘッダフィールド部は、ＳＩＰ ＩＮＶＩＴＥが、ＳＩＰアドレスＡＬＩＣＥ＠ＡＴＬＡＮＴＡ１．ＣＯＭからのものであることを示す。ＳＩＰ ＩＮＶＩＴＥ要求は、ＳＩＰプロキシ７上で終端しているＴＣＰ接続において受信され、ＳＩＰプロキシ７のＳＩＰプロトコル処理レイヤへ提供される。ＳＩＰプロキシ７のＳＩＰプロトコル処理レイヤは、このアドレス情報を検査し、ＢＯＢ＠ＢＩＬＯＸＩ．ＣＯＭを得る。そして、ＳＩＰプロトコル処理レイヤは、ＳＩＰ ＩＮＶＩＴＥ要求をどこへ送信するかを判定するポリシーのセットを用いる。このポリシーのセットは、各ドメインネームに対する関連するＳＩＰプロキシを示す。本例では、ポリシーは、ドメインネームＢＩＬＯＸＩ．ＣＯＭが、関連するＳＩＰプロキシ＃２によってサービス提供されるべきであることを示す。そして、ＳＩＰプロキシ７内のＳＩＰプロトコル処理レイヤは、識別されたＳＩＰプロキシ＃２を解釈し、ＳＩＰプロキシ＃２のインターネット側のＩＰアドレスを決定する。これは、キャッシュされた情報を調べることにより、又は、ＤＮＳサーバルックアップを行うことによってなされうる。ＳＩＰプロキシ＃２のインターネット側ＩＰアドレスが一旦決定されると、ＳＩＰプロキシ７は、ＳＩＰプロキシ＃２へのＴＣＰ接続を確立し、ＳＩＰ ＩＮＶＩＴＥ要求を、インターネット６を介してＳＩＰプロキシ＃２へ転送する（図１参照）。ＳＩＰプロキシ＃２は、ドメインＢＩＬＯＸＩ．ＣＯＭ上にある。ＢＩＬＯＸＩ．ＣＯＭは、ＬＡＮ１０のドメインネームである。図３のブロック図において、ＡＴＬＡＮＴＡ１．ＣＯＭからＢＩＬＯＸＩ．ＣＯＭへ伸びる矢印２４は、ＳＩＰプロキシ７からＳＩＰプロキシ１１へのＳＩＰ ＩＮＶＩＴＥ要求の転送を表わす。
【００２４】
ＳＩＰプロキシ１１は、このＳＩＰ ＩＮＶＩＴＥ要求を受信する。ＳＩＰプロキシ１１上で動作するスタックのＳＩＰレイヤは、ＬＡＮ１０上の全てのデバイスのＩＰアドレスを知っている。ＳＩＰ ＩＮＶＩＴＥ要求の、示されたＳＩＰ呼出先アドレスＢＯＢ＠ＢＩＬＯＸＩ．ＣＯＭから、ＳＩＰプロキシ１１のＳＩＰレイヤは、ＢＯＢ＠ＢＩＬＯＸＩ．ＣＯＭのＩＰアドレスを取得し、ＳＩＰ ＩＮＶＩＴＥ要求を、ＴＣＰ接続を介して、ＩＰ電話９のＩＰアドレス（ＩＰアドレス＃２）へ転送する。図３では、ＢＩＬＯＸＩ．ＣＯＭからパーティＢへ伸びる矢印２５は、この転送を表わす。ＩＰ電話９のスタックのＳＩＰレイヤは、このＳＩＰ ＩＮＶＩＴＥ要求を受信し、ＳＩＰプロトコルにしたがって、２００ ＯＫ ＳＩＰメッセージを返す。２００ ＯＫ ＳＩＰメッセージは、上述した転送処理と逆の処理によって、ＳＩＰプロキシ１１及びＳＩＰプロキシ７を介して、パーティＡ及びＩＰ電話２へ戻される。図３では、この転送は、矢印２６、２７及び２８によって表わされる。
【００２５】
次に、ＩＰ電話２は、２００ ＯＫ ＳＩＰメッセージを受信し、これからＩＰ電話９のＩＰアドレスを得る。そして、ＩＰ電話２は、ＩＰ電話２からＩＰ電話９へのＴＣＰ接続を直接的に確立することができる。２００ ＯＫ ＳＩＰメッセージを受信することに応じて、ＩＰ電話２は、ＴＣＰ接続を介して、ＩＰ電話９へとＳＩＰアクノレッジ（ＡＣＫ）メッセージを送り返す。図３では、これは、パーティＡからパーティＢまで直接伸びている矢印２９によって図示される。
【００２６】
図５は、ＳＩＰ ＩＮＶＩＴＥ要求、２００ ＯＫメッセージ、及びＡＣＫを含むＳＩＰトランザクションを示す。トランザクションの３つ全てのＳＩＰメッセージが、ネットワークを通って同時に伝搬するものとして例示されていているが、ＳＩＰメッセージは、実際には、上述したように、一度に１つ送られ、受信される。ＳＩＰトランザクションの結果は、（パーティＡの）ＩＰアドレス＃１と、（パーティＢの）ＩＰアドレス＃２の初期化である。データペイロードがセッション中に通信されていようともいまいとも、終了していない初期化ＳＩＰセッションは、“アクティブ”であると呼ばれる。本例では、第１のＳＩＰセッションが一旦初期化されると、音声及び／又はビデオデータペイロードを有する第１のＶｏＩＰ／ＶＩＰ（voice over IP or video over IP）が、ＲＴＰ（Real-Time Protocol）プロトコルにしたがって、ＵＤＰ（User Datagram Protocol）パケットによって、ＩＰ電話２のＩＰアドレス＃１とＩＰ電話９のＩＰアドレス＃２との間で通信される。第１のセッションのデータペイロードはＩＰの上のＵＤＰの上のＲＴＰを使用して通信される、一方、第１のセッションの制御パケットは、ＩＰ、ＴＣＰ、及びＳＩＰを用いて通信される。
【００２７】
図６は、ＩＰ電話２とＩＰ電話９との間のこれら第１のＶｏＩＰ／ＶＩＰ ＩＰデータペイロードパケットの幾つかの通信を例示している。この通信は、８０２．１１プロトコルにしたがった、ＬＡＮ４のアクセスポイント３とＩＰ電話２との間の無線通信を含む。８０２．１１は、比較的短距離のＲＦ通信プロトコルである。本例では、パーティＡは、アクセスポイント３から更に遠くへ移動する。ＩＰ電話２は、アクセスポイント３から受信したＲＦ送信の信号強度を検知する。本例では、検知された信号強度の表示は、ＩＰ電話２において、ＩＰ電話２内の８０２．１１トランシーバの受信機増幅器から出力されるＲＳＳＩ（Radio Signal Strength Indicator）信号として利用可能である。アクセスポイント３内の８０２．１１トランシーバの受信機増幅器はまた、ＩＰ電話２から受信したＲＦ送信の信号強度を検知する。この検知された信号強度は、アクセスポイント３からＩＰ電話２へと報告される。このように、ＩＰ電話２は、両方向で受信した送信の強度を認識する。パーティＡ及びＩＰ電話２がアクセスポイント３から離れると、ＩＰ電話２とアクセスポイント３との間の８０２．１１無線リンクの検知された信号強度は、しきい値に達するまで低下する。しきい値に到達すると、ＩＰ電話２は、ＩＰ電話２が、その長距離のセルラ電話トランシーバを用いて第２のＳＩＰセッションを初期するべきであると判定する。ＩＰ電話２は、第１のセッションにおいて、ＳＰＡＷＮメッセージと呼ばれる斬新なＳＩＰメッセージをパーティＡからパーティＢへ送ることによって、この第２のＳＩＰセッションを初期化する。
【００２８】
図７は、ＳＰＡＷＮ ＳＩＰメッセージを例示するブロック図である。
【００２９】
図８は、パーティＡからパーティＢへのＳＰＡＷＮ ＳＩＰメッセージの通信を例示するブロック図である。上述したように、パーティＡからパーティＢへとＩＮＶＩＴＥ ＳＩＰメッセージが通信されるのと同じ方法で、ＳＰＡＷＮ ＳＩＰメッセージもまた、ＩＰ電話２から、８０２．１１無線リンクを介してＬＡＮ４上のアクセスポイント３へ、ＬＡＮ４を介してＳＩＰプロキシ７へ、インターネット６を介してＳＩＰプロキシ１１へ、ＬＡＮ１０を介してパーティＢのＩＰ電話９へ通信される。パーティＢのＩＰ電話９は、ＳＰＡＷＮ ＳＩＰメッセージを受信し、パーティＡのＩＰ電話２に２００ ＯＫ ＳＩＰメッセージを送り返すことにより応答する。しかしながら、この２００ ＯＫ ＳＩＰメッセージは、ＳＰＡＷＮ ＩＤ（ＳＰＡＷＮ識別子）を含んでいる。ＩＰ電話９は、ＦＲＯＭフィールド、ＴＯフィールド、ＣＡＬＬ−ＩＤフィールド、及び第１のセッションのＣＳＥＱ番号のハッシュを生成することによって、ＳＰＡＷＮ ＩＤを生成する。このＳＰＡＷＮ ＩＤは、将来の参照のためにＩＰ電話９内に格納され、第２のセッションが第１のセッションと関連付けられる。本例では、ＳＰＡＷＮ ＩＤは、２００ ＯＫ ＳＩＰメッセージ内のフィールド名“ＳＰＡＷＮ−ＩＤ”に続く１６バイトキャラクタストリングである。ＳＰＡＷＮ ＩＤを含む２００ ＯＫ ＳＩＰメッセージは、ＳＩＰプロキシ１１及びＳＩＰプロキシ７を介してＩＰ電話２に転送される。
【００３０】
図９は、ＳＰＡＷＮ ＳＩＰ要求と、ＳＰＡＷＮ ＩＤ及びＡＣＫを含む２００ ＯＫとを含むＳＩＰトランザクションを例示するブロック図である。例示するように、このトランザクションは第１のＳＩＰセッションにおいて生じる。
【００３１】
図１０は、２００ ＯＫを受信すると、第２のＩＮＶＩＴＥ ＳＩＰ要求を発行する次のステップを例示するブロック図である。ＩＰ電話２内の黒い点はＩＰアドレスを表わす。第２のＩＮＶＩＴＥ要求は、ＳＰＡＷＮ ＩＤを含んでおり、パーティＡのＩＰ電話２からパーティＢのＩＰ電話９へ通信される。この第２のＩＮＶＩＴＥ要求は、ＣＤＭＡセルラ電話リンクを介してＩＰ電話２から、セルラ電話ネットワーク５上のアクセスポイント（ＢＴＳ又は基地送信サイトとも呼ばれる）３０へ通信され、次に、セルラ電話ネットワーク５を介してＳＩＰプロキシ＃３（ＳＩＰプロキシ８）へ通信される。この通信は、ＩＰ電話２におけるＩＰアドレス＃３における一端、及びその他の端において終端するＴＣＰ接続を介して、ＳＩＰプロキシ８のセルラ電話ネットワーク側ＩＰアドレスへ通信される。そして、第２のＩＮＶＩＴＥ要求が、インターネット６を介してＳＩＰプロキシ８から、他のＴＣＰ接続を介してＳＩＰプロキシ１１へと転送される。この第２のＩＮＶＩＴＥ要求は、その後、ＬＡＮ１０を介してＳＩＰプロキシ１１から、別のＴＣＰ接続を介してパーティＢのＩＰ電話９へと転送される。
【００３２】
パーティＢのＩＰ電話９は、既に存在するアクティブセッション（第１のセッション）によって、通常は、到来するＩＮＶＩＴＥ要求を拒絶するが、本発明では、パーティＢのＩＰ電話９内のＳＩＰレイヤ機能が、到来する第２のＩＮＶＩＴＥ要求のＳＰＡＷＮ ＩＤを認識し、それ自身のＲＴＰストリームを開くことを含む第２のセッションを確立アップし、この第２のセッションを第１のセッションに関連付ける。ＩＰ電話９は、ＳＰＡＷＮ ＩＤを、格納されたＳＰＡＷＮ ＩＤのリストと比較することによって、到来する第２のＩＮＶＩＴＥ要求のＳＰＡＷＮ ＩＤを認識する。
【００３３】
図１０Ａは、ＩＰ電話９内で動作するソフトウェアの構造の簡略図である。ＩＰ電話９は、２００ ＯＫ ＳＩＰメッセージを、パーティＡのＩＰ電話２へ返すことによって応答する。ＩＰ電話２は、ＩＰ電話９にＡＣＫを返すことによって、トランザクションを終了する。第２のＩＮＶＩＴＥ要求、２００ ＯＫ、及びＡＣＫは、ＣＤＭＡ無線リンク及びＣＤＭＡ ＢＴＳ３０を介してＩＰ電話２と通信される。
【００３４】
図１１は、アクティブな第１のセッションと、現在初期化されたアクティブな第２のセッションとを例示する図である。第２のセッションはアクティブであるが、データペイロードパケットは、ＩＰ、ＵＤＰ、及びＲＴＰを用いて、第２のセッションにおいて、まだ通信されていない。（ＩＰ電話２とアクセスポイント３との間の８０２．１１通信を含む）第１のセッションは、第１のＣＡＬＬ−ＩＤを有する。一方、（ＩＰ電話２とセルラＢＴＳ３０との間のＣＤＭＡ通信を含む）現在初期化されている第２のセッションは、第２のＣＡＬＬ−ＩＤを有する。
【００３５】
図１２は、ＩＰ電話２とＩＰ電話９との間のペイロードデータメディアフローが、第１のセッションから第２のセッションへと切り換わる（すなわち、「ハンドオフ」される）次のステップを例示する。矢印３１，３２は、パーティＡのＩＰ電話２と、パーティＢのＩＰ電話９との間のペイロードデータメディアフローＶｏＩＰパケットの初期フローを例示する。データ制御ハンドオフパケットが、ＩＰ、ＵＤＰ、及びＲＴＰを用いて、パーティＡのＩＰ電話２から、パーティＢのＩＰ電話９へ送られる。本例では、このデータ制御ハンドオフパケットは、ＳＩＰプロキシ７，１１を介して第１のセッションで通信されるが、このデータ制御ハンドオフパケットはまた、ＳＩＰプロキシ８，１１を介して第２のセッションで通信される。矢印３３は、データ制御ハンドオフパケットの転送を示す。データ制御ハンドオフパケットは、一例として、ＳＷＩＴＣＨ−ＦＲＯＭ：フィールド名と、ＳＷＩＴＣＨ−ＴＯ：フィールド名とを含むＳＩＰメッセージである。データ制御ハンドオフパケットは、ＩＰ電話９へ通信するために使用され、次のデータペイロードパケットが、第２のセッションで送られる。データ制御ハンドオフパケットの起こりうる損失に対処するために、パーティＢは、ＩＰアドレス＃３を用いるパーティＡのＩＰ電話２によって発信された制御パケットを拒否しないことが命じられる。
【００３６】
図１３は、第１のセッションにおいてＩＰ電話２からＩＰ電話９へ通信されるデータペイロードパケットに続くメディアフローハンドオフ制御パケット３４を例示する。
【００３７】
図１４は、メディアフローハンドオフ制御パケット３４のブロック図である。メディアフローハンドオフ制御パケットを送った後、ＩＰ電話２は、第１のセッションにおいて、メディアストリームのデータペイロードを送ることから、第２のセッションにおいて、メディアストリームのデータペイロードを送ることに切り換える。本例におけるメディアストリームは、音声会話である。ＩＰ電話９がメディアフローハンドオフ制御パケットを受信した場合、ＩＰ電話９は、第２のセッションにおいて、次のデータペイロードパケットを受信し、これらパケットのデータペイロードを、ＦＩＦＯ（first-in-first out）メモリ内の、第１のセッションにおいて以前に受信したパケットのデータパケットの後にバッファする。このデータペイロードはＦＩＦＯから出力され、ＲＴＰシーケンス番号及びタイムスタンプにしたがって順序付けられるように、ＩＰ電話９のユーザに提供される。したがって、メディアストリームのデータペイロードは、認識できるほど通話が破壊されることなく、第１のアクティブなセッションから第２のアクティブなセッションへとシームレスに切り換えられる。第１のセッションも第２のセッションも、切換回路部を含んでいない。第１のセッションも第２のセッションも、ＶｏＩＰパケットを含んでおり、ＩＰ電話９は、２つのセッションを知っている。２つのセッションは、３方式の通話を構成しない。更に、ＳＩＰプロキシ７，８，１１は、この斬新なＳＰＡＷＮ方法をサポートする如何なる特別な機能も含まない標準的なＳＩＰプロキシである。図１２では、矢印３４，３５は、第２のセッションにおける次のＶｏＩＰデータペイロードパケットのフローを例示する。
【００３８】
図１５は、データ制御ハンドオフパケットが第１のセッションにおいて通信された後の、第２のセッションにおけるデータペイロードＶｏＩＰパケットのフローを例示する。ＩＰ電話２は、フローデータパケットペイロードＶｏＩＰパケットを、必要に応じて、又は希望に応じて、第１のセッションと第２のセッションとの間で切り換えることができる。
【００３９】
図１６は、次のステップを例示する。このステップでは、ＩＰ電話２が、ＩＰ電話９にＳＩＰ ＢＹＥメッセージを送ることによって、第１のセッションを終了する。８０２．１１無線リンクの信号強度が低下する場合、ＩＰ電話２とアクセスポイント３との間の通信が存在している間、このＳＩＰ ＢＹＥメッセージが送られる。このＢＹＥメッセージが送信され受信された後、第１のセッションが終了し、メディアストリームのためのデータペイロードパケットの通信を維持するために第２のセッションが使用される。
【００４０】
図１７は、第１のセッションが終了した後、第２のセッションにおけるデータペイロードＶｏＩＰパケットのフローを示す。
【００４１】
上述した例は、８０２．１１リンクを有する第１のセッションから、ＣＤＭＡリンクを有する第２のセッションへの切換を含むが、これはそうである必要はない。別の例では、第１のセッションが、ＣＤＭＡ無線リンクを含み、第２のセッションが、８０２．１１無線リンクを含む。そのような状態は、パーティＡが最初はセルラＢＴＳ３０を介したＣＤＭＡ通信を用いており、次に、アクセスポイント３のローカル有効範囲領域に到達する場合に生じる。ＣＤＭＡサービス及び８０２．１１サービスともに、アクセスポイント３のローカル有効範囲領域内で利用可能であるが、上述した本方法は、８０２．１１無線リンクを含む第２のセッションをセットアップするために使用される。その後、データペイロードＶｏＩＰパケットのフローが、ＣＤＭＡ第１のセッションから、８０２．１１第２のセッションへと切り換えられる。ＣＤＭＡリンクの使用に関する課金を避けるために、第２のセッションが一旦アクティブになり、ＶｏＩＰメディアストリームのデータペイロードを取り扱うと、ＣＤＭＡリンクを有する第１のセッションが終了する。
【００４２】
図１８は、代替データフローハンドオフメカニズムを示す。１つのセッションから別のセッションへのデータペイロードＶｏＩＰパケットの切り換えをシグナルするためにハンドオフ制御パケットを送るのではなく、ＩＰ電話２は単に、第２のセッションにおいて、データペイロードＶｏＩＰパケットを通信し始める。矢印３６は、パーティＡからパーティＢへと通信される最初のデータペイロードＶｏＩＰパケットを表す。パーティＢが第１のセッションにおいてデータペイロードＶｏＩＰパケットを受信した場合、パーティＢは、第１のセッションにおいてパーティＡへ送ることを望んでいるあらゆるデータペイロードＶｏＩＰパケットを送ることによって応答する。パーティＢからパーティＡへのデータペイロードＶｏＩＰパケットのフローは、矢印３７によって示される。第１のセッションから第２のセッションへのデータペイロードＶｏＩＰパケットのフローを切り換えるために、パーティＡは単に、第２のセッションにおいて、データペイロードＶｏＩＰパケットをパーティＢへ送ることを開始する。このフローは、矢印３８によって表わされる。パーティＢが、第２のセッションにおいて、データペイロードＶｏＩＰパケットを受信し始めると、パーティＢは、第２のセッションにおいてパーティＡへ送ることを望んでいる次のあらゆるデータペイロードＶｏＩＰパケットを送ることによって応答する。第２のセッションにおけるパーティＢからパーティＡへのデータペイロードＶｏＩＰパケットのフローは、矢印３９によって表される。
【００４３】
パーティＢが、ＩＰ電話において終端するＴＣＰ接続を介してＶｏＩＰデータペイロードパケットが送られるＩＰ電話を有するシステムについて上述したが、パーティＢは、ＩＰ電話を有しておらず、メディアゲートウェイを経由するＩＰテレフォニーを用いることもできる。通話がパーティＢへの通話である場合、このメディアゲートウェイがＶｏＩＰ通話を受信し、パーティＢへの従来式の第２の通話を行い、ＶｏＩＰ通話とこの従来式の第２の通話との間でペイロード情報を中継する。通話がパーティＢから発信された通話である場合、パーティＢが、メディアゲートウェイへ従来式の通話を行い、メディアゲートウェイが、意図する呼出先へと第２のＶｏＩＰ通話を行い、メディアゲートウェイが、従来式の通話とＶｏＩＰ通話との間でペイロード情報を中継する。したがって、メディアゲートウェイは、パーティＢのためのダミーのＩＰ電話として動作する。
【００４４】
上述した例におけるＩＰ電話９は、陸線ＩＰ電話であるが、他の例では、ＩＰ電話９は、（例えば、セルラ電話のような）モバイル無線通信デバイスである。第１及び第２のセッションは、モバイルＩＰ電話か陸線ＩＰ電話かの何れかによって開始することができる。
【００４５】
図１９は、第２の斬新な局面にしたがった方法の図である。モバイル通信デバイスは、第１のエアインタフェースと第２のエアインタフェースとを有する。第１のエアインタフェースは、第１のネットワーク上のトランシーバとモバイル通信デバイスとの間の第１の無線通信リンクによってＶｏＩＰ／ＶＩＰパケットを通信するために利用することができる。第２のエアインタフェースは、第２のネットワーク上のトランシーバとモバイル通信デバイスとの間の第２の無線通信リンクによってＶｏＩＰ／ＶＩＰパケットを通信するために利用することができる。一例において、モバイル通信デバイスは、ＩＰ電話として動作可能なセルラ電話である。図１９の方法が実現される代表的なシステムは、図１に例示するシステムである。セルラ電話はＩＰ電話２である。ＩＰ電話２の第１のエアインタフェースは８０２．１１インタフェースであり、第１の無線通信リンクは、ＩＰ電話２とローカルエリアネットワーク（ＬＡＮ）４との間のセルラ電話リンクである。ＩＰ電話２の第２のエアインタフェースはセルラ電話インタフェースであり、第２の無線通信リンクは、ＩＰ電話２とセルラ電話ネットワーク５との間のセルラ電話リンクである。
【００４６】
図１９に例示する方法におけるステップ１００では、パーティＡが、第１のセッションにおいてパーティＢと通信するために、モバイル通信デバイス（例えばＩＰ電話２）を用いる。記載されている例では、パーティＢはＩＰ電話９を使用している。第１のセッション（例えば、しばしば「ＳＩＰ ＲＴＰセッション」、「ＳＩＰセッション」、または「ＶｏＩＰセッション」と呼ばれるＳＩＰによって確立されたＲＴＰセッション）が、図１乃至図５に関連して上述したような１つの例において確立される。モバイル通信デバイスは、第１のエアインタフェースを使用して、第１のセッションにおいて、メディアストリームのデータペイロードを送信する。
【００４７】
次に（ステップ１０１において）、パーティＡは、図６に関連して上述したように、第１のネットワーク４上の無線アクセスポイント３からＩＰ電話２を移動させる。この移動の結果、ＩＰ電話２と無線アクセスポイント３との間の無線通信リンクによって与えられるサービス品質が低下する。このサービス品質の低下は、例えば、以下のうちの１または複数を含みうる。第１のセッションにおいてＩＰ電話２からＩＰ電話９へ通信することが可能なデータペイロードビットレート（ビット／秒）の減少、第１のセッションにおいてＩＰ電話９からＩＰ電話２へ通信することが可能なデータペイロードビットレート（ビット／秒）の減少、第１のセッションにおいてＩＰ電話２からＩＰ電話９へ単位時間あたりに通信されるＲＴＰパケットの合計数の減少、第１のセッションにおいてＩＰ電話９からＩＰ電話２へ単位時間あたりに通信されるＲＴＰパケットの合計数の減少、ＩＰ電話２からＩＰ電話９への第１のセッションにおける通信中に喪失されるＲＴＰパケット数の増加、ＩＰ電話９からＩＰ電話２への第１のセッションにおける通信中に喪失されるＲＴＰパケット数の増加、ＩＰ電話２またはＩＰ電話９の何れかへ到来するパケットの到着の間におけるジッタの増加、ＩＰ電話２からＩＰ電話９へとパケットを完全に通信するために必要とされる時間（しばしば、レイテンシと呼ばれる）の増加、ＩＰ電話９からＩＰ電話２へとパケットを完全に通信するために必要とされる時間の増加。サービス品質の減少によって、ＩＰ電話２によって、アクセスポイント３によって、あるいはこれら両方によって検出されるように、ＲＦ信号強度が低下することが明らかになりうる。
【００４８】
ＩＰ電話２は、サービス品質の１または複数の表示を使用して、サービス品質の低下を検出する（ステップ１０１）。ＩＰ電話２が、サービス品質の低下を検知することができる多くの方法がある。一例では、ＩＰ電話２は、ＩＰ電話９から、第１セッションにおいて、ＲＴＣＰ（リアルタイム制御プロトコル）受信機レポート（ＲＲ）パケットを受信する。これらＲＴＣＰ受信機レポートは、第１セッションにおいて、ＩＰ電話９上で受信されたパケットの総数を含んでいる。ＩＰ電話２は、引き続くＲＴＣＰ受信機レポートにおけるパケット値の総数から、最初のＲＴＣＰ受信機レポートにおけるパケット値の総数を引くことにより、時間内においてＩＰ電話９へと受信されたパケット数を判定する。ＩＰ電話２は、２つのＲＴＣＰレポート間の時間差を判定し、次に、この時間差から、時間内において受信された判定されたパケット数を分割する。これによって、単位時間毎にＩＰ電話９へ受信される適切なパケット数を得ることができる。この値は、１つの実施形態では、サービス品質の評価として使用される。
【００４９】
ＩＰ電話２は、規則的ベースで定期的にサービス品質の低下を検出するためにこの動作を行い、単位時間毎に第１のセッションにおいてＩＰ電話９上で受信されたパケット数を追跡する。単位時間当たりにＩＰ電話９上で受信されたパケット数が閾レベルを下回った場合、ＩＰ電話２は、第２のＶｏＩＰセッションに対して、ＩＰ電話２とＩＰ電話９との間の通信を確立させる（ステップ１０２）。第２のセッションは、ＩＰ電話２の第２のエアインタフェースを用いて、セルラ電話ネットワーク５上のアクセスポイント３とＩＰ電話２との間の通信を含む。
【００５０】
サービス品質の低下を検出する別の方法は、連続したＲＴＣＰ受信機レポートの到着間ジッタフィールド、喪失カウントフィールド、および／または喪失比（喪失したパケット比）フィールドの使用を含む。これらフィールドにおける値から、到着間ジッタと喪失したパケットの合計数が時間にわたってモニタされる。単位時間毎に喪失したパケット数が、閾レベルよりも増加した場合、あるいは、到着間ジッタが、閾レベルよりも増加した場合には、サービス品質が低下したとの判定がなされる。
【００５１】
第２のセッションは、任意の適切な方法を用いて確立される。ここで記載される例では、図７乃至図１１に関連して上述した方法を用いて第２のセッションが確立される。ＩＰ電話２は、第１のセッションを識別するＳＩＰ ＳＰＡＷＮメッセージをＩＰ電話９へ通信する。ＩＰ電話９は、ＳＩＰ ＯＫメッセージをＩＰ電話２へ戻すことによって応答する。ＳＩＰ ＯＫメッセージは、ＳＰＡＷＮ識別子を含んでいる。そして、ＩＰ電話２は、ＳＰＡＷＮ識別子を含むＳＩＰ ＩＮＶＩＴＥメッセージをＩＰ電話９へ通信する。ＩＰ電話９は、ＳＩＰ ＩＮＶＩＴＥメッセージを受信し、第２のセッションを確立し、ＳＩＰ ＩＮＶＩＴＥメッセージを用いて、第２のセッションを第１のセッションに関連付ける。
【００５２】
第２のセッションが一旦アクティブになると、第１のセッションを終了するのではなく、第２の斬新な局面の方法にしたがってＩＰ電話２とＩＰ電話９との間の単一のメディアストリームのＶｏＩＰ／ＶＩＰパケットを通信するために、第１のセッションと第２のセッションとの両方が同時に使用される。この単一のメディアストリームは、例えば、パーティＡの音声を表す音声データでありうる。音声データメディアストリームは、ＶｏＩＰ／ＶＩＰパケットのデータペイロードで伝送される。例えば、メディアストリームの音声データの４つのセグメントが、以下のようにして、ＩＰ電話２からＩＰ電話９へ通信されうる。すなわち、第１の音声データが、第１のセッションを介して、第１のＶｏＩＰ／ＶＩＰパケットで通信され、次に、第１の音声データに続く第２の音声データが、第２のセッションを介して、第２のＶｏＩＰ／ＶＩＰパケットで通信され、次に、第２の音声データに続く第３の音声データが、第１のセッションを介して、第３のＶｏＩＰ／ＶＩＰパケットで通信され、次に、第３の音声データに続く第４の音声データが、第２のセッションを介して、第４のＶｏＩＰ／ＶＩＰパケットで通信される。したがって、音声データは、２つのセッションを介して、インタリーブ方式で通信される。ＲＴＰプロトコルにしたがって、ＶｏＩＰ／ＶＩＰパケットはそれぞれ、ＲＴＰシーケンス番号と同様、ＲＴＰタイムスタンプを有する。ＩＰ電話９は、第１のセッションおよび第２のセッションを介して、ＩＰ電話９へ到来するＶｏＩＰ／ＶＩＰパケットを受信し、メディアストリームを再構築できるように、ＲＴＰタイムスタンプおよび／またはＲＴＰシーケンス番号を用いてデータペイロードを順序付ける。４つのＶｏＩＰ／ＶＩＰパケットが単一のメディアストリームの音声データを伝送する上述した例では、データペイロードが、第１のデータペイロード、第２のデータペイロード、第３のデータペイロード、第４のデータペイロードのような順序でＩＰ電話９によって順序付けられる。ＩＰ電話９は、データペイロードを適切に順序付けるために、ＲＴＣＰシーケンス番号とＲＴＣＰタイムスタンプとを用いる。適切に順序付けられたデータペイロードは、再構築メディアストリームを構成する。
【００５３】
１つの実施形態では、メディアストリームの同じ数からなるデータペイロードは、単位時間当たりに常に第１のセッションおよび第２のセッションで通信される。あるいは、単位時間当たりに第１のセッションで通信されるデータペイロードの、第２のセッションで通信されるデータペイロードに対する比率は、変えられる。このデータペイロードの比率は、第１のセッションのサービス品質の評価と、第２のセッションのサービス品質の評価との間の関係によって決定される。サービス品質の様々な異なる表示は、セッションのサービス品質の尺度として使用することができる。例えば、ＩＰ電話２は、第１のセッションにおいて、ＩＰ電話９からＲＴＣＰ受信機レポートパケットを受信する。
【００５４】
ＩＰ電話２は、ＲＴＣＰ受信機レポートで受信した合計パケット数を用いて、第１のセッションのサービス品質の評価を行い、第２のセッションのサービス品質の評価を行う（ステップ１０４）。例えば、第１のセッションにおいて、単位時間当たりにＩＰ電話９上で受信されたパケット数が、第２のセッションにおいて、単位時間当たりにＩＰ電話９上で受信されたパケット数よりも低下した場合、ＩＰ電話２とＬＡＮアクセスポイント３との間の第１の無線通信リンクに問題があろう。したがって、ＩＰ電話２は、インタリーブ方式で、第１のセッションおよび第２のセッションを介して、メディアストリームの連続的なデータペイロードを通信する（ステップ１０５）。ここで、ＩＰ電話２から、第１のセッションによって送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションによって送信されるＶｏＩＰ／ＶＩＰパケットに対する比率は、第１のセッションを用いて利用可能な評価済みサービス品質の、第２のセッションを用いて利用可能な評価済みサービス品質に対する比率に設定される。１つのセッションで利用可能なサービスの、他のセッションで利用可能なサービスに対する相対的な品質が変わると、ＩＰ電話２もまた、第１のセッションによって送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションによって送信されるＶｏＩＰ／ＶＩＰパケットに対する比率を変える。第１のセッションか第２のセッションの何れかを用いて利用可能なサービス品質が、ＩＰ電話２からＩＰ電話９へ所望のメディアストリーム情報を通信するのに適切ではない場合、第１のセッションと第２のセッションとを組み合わせた通信機能が適切であるかもしれず、また、通信負荷を共有するために使用され、何れかのセッションのみを用いることでは利用できないサービス品質特性が達成される。
【００５５】
図２０は、第２の斬新な局面にしたがって、ＩＰ電話２からＩＰ電話９へと通信されるＶｏＩＰ／ＶＩＰパケットを図示する簡略図である。この図では、上側の時間軸が、第１のセッションを用いたＩＰ電話２からＩＰ電話９への通信を表す。下側の時間軸は、第２のセッションを用いたＩＰ電話２からＩＰ電話９への通信を表す。時間は左から右へ進む。このブロック図は横軸においてスケールするべきではないが、様々なＶｏＩＰ／ＶＩＰパケットの互いの相対的なタイミングを示すように表される。
【００５６】
先ず、期間１０６では、１乃至４と示された一連のＶｏＩＰ／ＶＩＰが、第１のセッションを用いて通信される。次に、時間１０７において、第１のセッションにおいてサービス品質の低下が検出され、第２のセッションが確立される。その後、５乃至１０と示された６つのＶｏＩＰ／ＶＩＰパケットは、第１のセッションと第２のセッションとの両方を用いて、ＩＰ電話２から、インタリーブ方式で通信される。２つのセッションにおいて単位時間当たりに通信されるＶｏＩＰ／ＶＩＰパケットの数は、同じである。なぜなら、第１のセッションによって提供されるサービス品質の評価は、第２のセッションによって提供されるサービス品質の評価と実質的に同じだからである。図示する例において、この条件は、第１のセッションと第２のセッションとの間のサービス品質の相対的な評価が変わる時間１０８まで続く。第１のセッションによって提供されるサービス品質は、第２のセッションによって提供されるサービス品質よりも２倍良いと判定される。したがって、時間１０８で始まって、第１のセッションでは、第２のセッションよりも、単位時間あたりに２倍の数のＶｏＩＰ／ＶＩＰパケットが通信される。１１乃至１６と示された更に６つのＶｏＩＰ／ＶＩＰパケットが、時間１０８の後に通信されていることが示される。
【００５７】
ＩＰ電話２が、第１のセッションで送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションで送信されるＶｏＩＰ／ＶＩＰパケットに対する比率を定期的に調節するのと同じ方法で、ＩＰ電話９もまた、ＩＰ電話２へ、第１のセッションで送信されるＶｏＩＰ／ＶＩＰパケットの、第２のセッションで送信されるＶｏＩＰ／ＶＩＰパケットに対する比率を定期的に調節することができる。ＩＰ電話９は、例えば、第１のセッションについて、ＩＰ電話２からＲＴＣＰ受信機レポートを受信し、第２のセッションについても、ＩＰ電話２からＲＴＣＰ受信機レポートを受信しうる。ＩＰ電話９は、これら受信機レポートにおける情報を用いて、第１のセッションによって提供されるサービス品質と、第２のセッションによって提供されるサービス品質との評価を行う。そして、ＩＰ電話９は、１つのセッションによって提供されるサービス品質の評価の、他のセッションによって提供されるサービス品質の評価に対する比率が同じになるように、ＩＰ電話２へ、第１のセッションで通信されたＶｏＩＰ／ＶＩＰパケットの、第２のセッションで通信されたＶｏＩＰ／ＶＩＰパケットに対する比率を調節する。
【００５８】
図２１は、第２の斬新な局面にしたがってＩＰ電話９からＩＰ電話２へ通信されるＶｏＩＰ／ＶＩＰパケットを例示する簡略図である。この図では、第１の６つのＶｏＩＰ／ＶＩＰパケットが、時間１０９の前に、第１のセッションで通信される。ＩＰ電話９は、第１のセッションによって提供されるサービス品質の評価を行い、第２のセッションによって提供されるサービス品質の評価を行う。図示する例では、２つのセッションは、同じサービス品質を提供しているものと判定される。したがって、時間１０９の後、ＩＰ電話９は、第１のセッションにおいてＶｏＩＰ／ＶＩＰパケットの半分を送信し、第２のセッションにおいてその半分を送信する。図２０において、通信されるＶｏＩＰ／ＶＩＰパケットの相対比率が変わる時は、図２１において、通信されるＶｏＩＰ／ＶＩＰパケットの相対比率が変わる時と異なる。これは、２つの方向において使用されるセッションの相対比率が、同じになる必要はないという点を示している。
【００５９】
したがって、到来するメディアストリームのＲＴＰデータペイロードを通信するために、および、発信されるメディアストリームのＲＴＰデータペイロードを通信するために、ＩＰ電話２の両方のエアインタフェースが使用されることが理解される。２つのエアインタフェースのうちの１つを用いることは、それを介する通信が完全に喪失した場合に停止されうる。２つのエアインタフェースのうちの１つを用いることはまた、他のエアインタフェースを介した通信が十分に良好であり、その１つのエアインタフェースのみを用いることを保証できるのであれば停止される。どれだけの数のエアインタフェースを使用するか、および、どれだけの割合にするかの判定は、単純な関数であるか、多くの変数を含む関数でありうる。これら変数は、コスト情報およびサービス品質の表示を示す。
【００６０】
単位時間当たりにセッションにおいて受信される合計パケット数が変わる理由は多くある。第１の無線通信リンクは、ＩＰ電話２からＩＰ電話９への通信パス全体のうちのほんの一部であることが認識される。そのため、セッションで受信される合計パケット数の減少は、データを通信するための第１の無線リンクの能力の低下のせいであるとは全く考えられないかもしれない。したがって、単位時間当たりに受信される合計パケット数を含む上述したものとは異なるサービス品質の評価が適用されうる。一例では、ＲＴＣＰ受信機レポートパケットが適用されず、無線アクセスポイント３が、第１の無線リンクのパフォーマンスに関するサービス品質情報（例えば、瞬時ビットレート情報、および／または、アクセスポイントで検出されたＲＦ信号強度の表示）を保持する。このサービス品質情報は、ＭＡＣレイヤ通信、または、ＲＴＰレイヤやＳＩＰレイヤの下のその他の通信を用いて、無線アクセスポイント３からＩＰ電話２へと通信される。ＩＰ電話２は、セルラアクセスポイント３０から、第２の無線通信リンクに関する同様なサービス品質情報を受信する。２つの無線通信リンクに関するサービス品質情報は、その後、２つのセッションによって与えられる相対的なサービス品質の評価を行うために使用される。
【００６１】
ある特定の実施形態が、説明目的のために上述されたが、本発明はそれに限定されない。第２の斬新な局面における第２のセッションの確立を引き起こすイベントは、全てのケースにおいて、第１のセッションにおけるサービス品質の低下である必要はない。一例では、第１のセッションによって提供されるサービス品質の実質的な低下は検出されず、単位時間当たり通信されるメディアストリームのデータ量が増加し、所望の方法（例えば、所望の最大レイテンシ）でメディアストリームのデータを通信するために第１のセッションはもはや適切ではなくなる。それに応じて、メディアストリームのデータのうちの過剰なデータを通信するために第２のセッションが確立される。過剰なデータが通信され、単位時間当たりに通信されるデータ量がそのオリジナルのレベルへと低下すると、第２のセッションはもはや必要とされず、控えめに使用されるか、あるいは、終了する。したがって、第２の斬新な局面は、第１のセッションに過度に負荷をかけて、第１のセッションの通信における望ましくないレイテンシをもたらしうるデータのスラッグを通信するために使用することができる。そのようなデータスラッグの例は、電話会話の間に通信される静止画像情報およびビデオ情報を含む。第２の斬新な局面の例が、２つのエアインタフェースを介して、インタリーブ方式でパケットを通信するモバイル通信デバイスに関連付けられて上述されたが、モバイル通信デバイスは、３またはそれ以上のエアインタフェースを介し、第２の斬新な局面に従うインタリーブ方式でパケットを通信することができる。したがって、上述した具体的実施形態の様々な特徴の変更、適応、及び組み合わせは、特許請求の範囲で述べられた本発明の範囲から逸脱することなく実施することができる。
【図面の簡単な説明】
【００６２】
【図１】図１は、１つの斬新な局面にしたがったＩＰ（Internet Protocol）テレフォニー通信システム１の簡略トポロジカルブロック図である。
【図２】図２は、図１のシステムにおけるＩＰ電話２とＳＩＰプロキシ７との間のＴＣＰ接続を例示する。
【図３】図３は、斬新な方法にしたがった第１のステップのブロック図である。
【図４】図４は、斬新な方法にしたがって第１のセッションをセットアップするＳＩＰ ＩＮＶＩＴＥ要求のブロック図である。
【図５】図５は、第１のセッションの初期化を例示する。
【図６】図６は、パーティＡが、図１のシステムのアクセスポイント３からＩＰ電話２を移動する第１のセッションを例示する。
【図７】図７は、本斬新な方法にしたがって、ＩＰ電話２からＩＰ電話９へ送られるＳＰＡＷＮ ＳＩＰメッセージの図である。
【図８】図８は、本斬新な方法にしたがって、ＳＰＡＷＮ ＳＩＰメッセージの通信を例示するブロック図を示す。
【図９】図９は、図１のシステムによるＳＰＡＷＮ ＳＩＰメッセージの通信、及び、ＳＰＡＷＮ ＩＤを含む２００ ＯＫ ＳＩＰメッセージを戻すことを例示する。
【図１０】図１０は、本斬新な方法にしたがって第２のセッションを初期化するために、ＩＰ電話２からＩＰ電話９へ第２のＳＩＰ ＩＮＶＩＴＥ要求を送ることを例示する。
【図１０Ａ】図１０Ａは、ＩＰ電話９において実行するソフトウェアの構造の簡略図である。
【図１１】図１１は、アクティブな第１及び第２の両セッションを例示する。
【図１２】図１２は、第１のセッションから第２のセッションへとＶｏＩＰデータパケットを切り換えるようシグナルするために、メディアハンドオフ制御パケットを使用することを例示するブロック図である。
【図１３】図１３は、ＩＰ電話２からＩＰ電話９へのハンドオフ制御パケットの送信を例示する。
【図１４】図１４は、ハンドオフ制御パケットのブロック図である。
【図１５】図１５は、第２のセッションによるデータペイロードのフローを示す。
【図１６】図１６は、第１のセッションを終了するために、ＩＰ電話２からＩＰ電話９へＢＹＥ ＳＩＰメッセージを送信することを例示する。
【図１７】図１７は、第１のセッションの終了後における図１のシステムを例示する。ここで、メディアストリームのデータペイロードＶｏＩＰパケットは、もはや第１のセッションでは通信されていないが、第２のセッションにおいて通信されている。
【図１８】図１８は、メディアストリームのＶｏＩＰデータペイロードパケットが、第１のセッションにおいてもはや通信されていないが、第２のセッションにおいて通信されることをＩＰ電話９が判定する他の方法を例示する。
【図１９】図１９は、第２の斬新な局面にしたがった方法の図である。
【図２０】図２０は、第２の斬新な局面にしたがって、モバイル通信デバイスから第２のＩＰデバイスへ通信されるＶｏＩＰ／ＶＩＰパケットを例示する簡略図である。
【図２１】図２１は、第２の斬新な局面にしたがって、第２のＩＰデバイスからモバイル通信デバイスへ通信されるＶｏＩＰ／ＶＩＰパケットを例示する簡略図である。
【特許請求の範囲】
【請求項１】
第１のデータペイロード、第２のデータペイロード、第３のデータペイロード、および第４のデータペイロードを通信する方法であって、前記第１のデータペイロードはメディアストリームのデータを含み、前記第２のデータペイロードは前記メディアストリーム内の前記第１のデータペイロードの後のデータを含み、前記第３のデータペイロードは前記メディアストリーム内の前記第２のデータペイロードの後のデータを含み、前記第４のデータペイロードは前記メディアストリーム内の前記第３のデータペイロードの後のデータを含み、前記方法は、
（ａ）第１のＩＰアドレスと第２のＩＰアドレスとの間で、第１のセッションにおいて、第１のＶｏＩＰ／ＶＩＰ（voice over Internet Protocol or video over Internet Protocol）パケットを通信することであって、前記第１のＩＰアドレスは第１のデバイスに関連付けられたＩＰアドレスであり、前記第２のＩＰアドレスは第２のデバイスに関連付けられたＩＰアドレスであり、前記第１のＶｏＩＰ／ＶＩＰパケットを通信することは、前記第１のＶｏＩＰ／ＶＩＰパケットを、第１のネットワーク上のトランシーバと前記第１のデバイスとの間で、第１の無線通信リンクを介して通信することを含み、前記第１のＶｏＩＰ／ＶＩＰパケットは前記第１のデータペイロードを含むことと、
（ｂ）第３のＩＰアドレスと前記第２のＩＰアドレスとの間で、第２のセッションにおいて、第２のＶｏＩＰ／ＶＩＰパケットを通信することであって、前記第３のＩＰアドレスは前記第１のデバイスに関連付けられたＩＰアドレスであり、前記第１のセッションと前記第２のセッションとは同時にアクティブであり、前記第２のＶｏＩＰ／ＶＩＰパケットを通信することは、前記第２のＶｏＩＰ／ＶＩＰパケットを、第２のネットワーク上のトランシーバと前記第１のデバイスとの間で、第２の無線通信リンクを介して通信することを含み、前記第２のＶｏＩＰ／ＶＩＰパケットは前記第２のデータペイロードを含むことと、
（ｃ）前記（ｂ）の後、前記第１の無線通信リンクを介して、前記第１のＩＰアドレスと前記第２のＩＰアドレスとの間で、前記第１のセッションにおいて、第３のＶｏＩＰ／ＶＩＰパケットを通信することであって、前記第３のＶｏＩＰ／ＶＩＰパケットは、前記第３のデータペイロードを含むことと、
（ｄ）前記（ｃ）の後、前記第２の無線通信リンクを介して、前記第２のＩＰアドレスと前記第３のＩＰアドレスとの間で、前記第２のセッションにおいて、第４のＶｏＩＰ／ＶＩＰパケットを通信することであって、前記第４のＶｏＩＰ／ＶＩＰパケットは、前記第４のデータペイロードを含むことと、
（ｅ）前記第１、第２、第３、および第４のデータペイロードを、第１、第２、第３、第４のデータペイロードの順に順序付けることによって、前記第２のデバイスにおいて、前記メディアストリームの少なくとも一部を再構築することと
を備える方法。
【請求項２】
前記第１および第３のＶｏＩＰ／ＶＩＰパケットは、無線ＬＡＮ（local area network）通信プロトコルにしたがって、前記第１の無線通信リンクを介して通信され、前記第２および第４のＶｏＩＰ／ＶＩＰパケットは、セルラ電話通信プロトコルにしたがって、前記第２の無線通信リンクを介して通信され、前記第１の無線デバイスは、ＩＰ電話、セルラ電話、ＰＤＡ（パーソナル・デジタル・アシスタント）、無線通信機能を有するコンピュータからなるグループから採用される請求項１に記載の方法。
【請求項３】
前記第１、第２、第３、および第４のＶｏＩＰ／ＶＩＰパケットは、それぞれがＲＴＰ（Real-Rime Transport Protocol）タイムスタンプを含んでいるＲＴＰパケットであり、前記再構築するステップ（ｅ）は、前記ＲＴＰタイムスタンプを用いて前記順序付けを行うことを含む請求項１に記載の方法。
【請求項４】
前記第１、第２、第３、および第４のＶｏＩＰ／ＶＩＰパケットは、それぞれがＲＴＰ（Real-Rime Transport Protocol）シーケンス番号を含んでいるＲＴＰパケットであり、前記再構築するステップ（ｅ）は、前記ＲＴＰシーケンス番号を用いて前記順序付けを行うことを含む請求項１に記載の方法。
【請求項５】
前記第１のセッションに関するサービス品質情報を含む第１のＲＴＣＰ（Real-Time Control Protocol）受信機レポートを、前記第１のデバイスにおいて受信することと、
前記第１のセッションに関するサービス品質情報を用いて、前記第１のセッションにおいて単位時間当たりに通信されるＶｏＩＰ／ＶＩＰパケットの、前記第２のセッションにおいて単位時間当たりに通信されるＶｏＩＰ／ＶＩＰパケットに対する比率を変えることと
を更に備える請求項１に記載の方法。
【請求項６】
前記第１の無線通信リンクの信号強度である検出済信号強度を示す情報を受信することと、
前記情報を用いて、前記第１のセッションにおいて単位時間当たりに通信されるＶｏＩＰ／ＶＩＰパケットの、前記第２の通信セッションにおいて単位時間当たりに通信されるＶｏＩＰ／ＶＩＰパケットに対する比率を変えることと
を更に備える請求項１に記載の方法。
【請求項７】
前記第１のセッションにおいて、前記第１のデバイスから前記第２のデバイスへと、前記第１のセッションを識別するＳＩＰ（Session Initialization Protocol）ＳＰＡＷＮメッセージを通信することと、
前記第２のデバイスから前記第１のデバイスへ、ＳＰＡＷＮ識別子を含むＳＩＰ ＯＫメッセージを通信することと、
前記第１のデバイスから前記第２のデバイスへ、前記ＳＰＡＷＮ識別子を含むＳＩＰ ＩＮＶＩＴＥメッセージを通信することと、
前記ＳＩＰ ＩＮＶＩＴＥメッセージを前記第２のデバイスにおいて受信することとを更に備え、
前記第２のデバイスは、前記ＳＩＰ ＩＮＶＩＴＥメッセージを用いて、前記第２のセッションを前記第１のセッションに関連付け、前記第２のセッションは、前記ＳＩＰ ＩＮＶＩＴＥメッセージの通信の結果として確立される請求項１に記載の方法。
【請求項８】
前記第１データペイロードのデータ、前記第２のデータペイロードのデータ、前記第３のデータペイロードのデータ、および前記第４のデータペイロードのデータは、音声データ、静止画像データ、ビデオデータからなるグループから採用されるタイプからなる請求項１に記載の方法。
【請求項９】
メディアストリームの複数のデータペイロードを通信する方法であって、
（ａ）モバイル通信デバイスと第２のデバイスとの間に、第１のＶｏＩＰ／ＶＩＰ（Voice over Internet Protocol or Video over Internet Protocol）通信パスを確立することであって、前記第１のＶｏＩＰ／ＶＩＰ通信パスは、前記モバイル通信デバイス上の第１のエアインタフェースと、第１のネットワーク上のアクセスポイントとの間の第１の無線通信リンクを含むことと、
（ｂ）前記モバイル通信デバイスと前記第２のデバイスとの間に、第２のＶｏＩＰ／ＶＩＰ（Voice over Internet Protocol or Video over Internet Protocol）通信パスを確立することであって、前記第２のＶｏＩＰ／ＶＩＰ通信パスは、前記モバイル通信デバイス上の第２のエアインタフェースと、第２のネットワーク上のアクセスポイントとの間の第２の無線通信リンクを含むことと、
（ｃ）前記データペイロードの第１のサブセットを、前記第１のＶｏＩＰ／ＶＩＰ通信パスを介して、前記モバイル通信デバイスから前記第２のデバイスへ通信することと、
（ｄ）前記データペイロードの第２のサブセットを、前記第２のＶｏＩＰ／ＶＩＰ通信パスを介して、前記モバイル通信デバイスから前記第２のデバイスへ通信することと、
（ｅ）前記モバイル通信デバイスから前記第２のデバイスへと前記第１のＶｏＩＰ／ＶＩＰ通信パスを介して通信されるデータペイロードの、前記モバイル通信デバイスから前記第２のデバイスへと前記第２のＶｏＩＰ／ＶＩＰ通信パスを介して通信されるデータペイロードの比率を複数回調節することと、
（ｆ）前記データペイロードの第１および第２のサブセットを前記第２のデバイス上で受信して、前記第１および第２のサブセットのデータペイロードを順序付けして、前記メディアストリームを再構築することと
を備える方法。
【請求項１０】
前記モバイル通信デバイスはセルラ電話であり、前記第１のネットワークはローカルエリアネットワーク（ＬＡＮ）であり、前記第１のエアインタフェースは８０２．１１インタフェースであり、前記第２のネットワークはセルラ電話ネットワークであり、前記第２のエアインタフェースはセルラ電話インタフェースである請求項９に記載の方法。
【請求項１１】
前記比率は、前記（ｅ）において、前記ＶｏＩＰ／ＶＩＰ通信パスによって提供されるサービス品質の第１の評価を行い、前記第２のＶｏＩＰ／ＶＩＰ通信パスによって提供されるサービス品質の第２の評価を行い、その後、前記第１および第２の評価を用いて、前記第１のＶｏＩＰ／ＶＩＰ通信パスを介したデータペイロードの送信と、前記第２のＶｏＩＰ／ＶＩＰ通信パスを介したデータペイロードの送信とを制御することによって調節される請求項９に記載の方法。
【請求項１２】
前記比率は、計算された値ではなく、前記調節の結果である請求項９に記載の方法。
【請求項１３】
モバイル通信デバイスであって、
第１のエアインタフェースと、
第２のエアインタフェースと、
プロトコル処理レイヤのスタックを実行するプロセッサとを備え、
第１のＶｏＩＰ／ＶＩＰデータペイロードが、第１のセッションにおいて、前記第１のエアインタフェースから第２のデバイスへ送信され、第２のＶｏＩＰ／ＶＩＰデータペイロードが、第２のセッションにおいて、前記第２のエアインタフェースから前記第２のデバイスへ送信され、単位時間当たりに、前記第１のエアインタフェースから送信される第１のＶｏＩＰ／ＶＩＰデータペイロードの数の、前記第２のエアインタフェースから送信される第２のＶｏＩＰ／ＶＩＰペイロードの数に対する比率が、前記第１および第２のＶｏＩＰ／ＶＩＰデータペイロードの送信中に複数回調節され、前記第１および第２のＶｏＩＰ／ＶＩＰデータペイロードは、単一のメディアストリームのペイロードであるモバイル通信デバイス。
【請求項１４】
前記プロセッサは、
前記第１のセッションのサービス品質を評価することと、
前記第２のセッションのサービス品質を評価することと
からなる各ステップを実行するためのプロセッサ実行可能命令のセットを実行する請求項１３に記載のモバイル通信デバイス。
【請求項１５】
前記プロセッサは、
前記第１のセッションのサービス品質を評価することと、
前記評価のうちの少なくとも一部に基づいて、前記第２のセッションが確立されるべきであることを決定することと
からなる各ステップを実行するためのプロセッサ実行可能命令のセットを実行するが、前記決定の結果として、前記第２のＶｏＩＰ／ＶＩＰデータペイロードの前記送信に先立って、前記第２のセッションが確立される請求項１４に記載のモバイル通信デバイス。
【請求項１６】
前記プロセッサは、
前記第１のＶｏＩＰ／ＶＩＰデータペイロードを通信する際に含まれる第１のアクセスポイントから、第１の信号強度情報を受信することと、
前記第２のＶｏＩＰ／ＶＩＰデータペイロードを通信する際に含まれる第２のアクセスポイントから、第２の信号強度情報を受信することと、
前記第１の信号強度情報と前記第２の信号強度情報とに少なくとも部分的に基づいて、前記第１のエアインタフェースから送信される前記第１のＶｏＩＰ／ＶＩＰデータペイロードの、前記第２のエアインタフェースから送信される前記第２のＶｏＩＰ／ＶＩＰデータペイロードに対する比率を調節することと
からなる各ステップを実行するためのプロセッサ実行可能命令のセットを実行する請求項１３に記載のモバイル通信デバイス。
【請求項１７】
前記プロセッサは、
前記第１のＶｏＩＰ／ＶＩＰデータペイロードを通信する際に含まれる第１のアクセスポイントから、第１のデータレート情報を受信することと、
前記第２のＶｏＩＰ／ＶＩＰデータペイロードを通信する際に含まれる第２のアクセスポイントから、第２のデータレート情報を受信することと、
前記第１のデータレート情報と前記第２のデータレート情報とに少なくとも部分的に基づいて、前記第１のエアインタフェースから送信される前記第１のＶｏＩＰ／ＶＩＰデータペイロードの、前記第２のエアインタフェースから送信される前記第２のＶｏＩＰ／ＶＩＰデータペイロードに対する比率を調節することと
からなる各ステップを実行するためのプロセッサ実行可能命令のセットを実行する請求項１３に記載のモバイル通信デバイス。
【請求項１８】
前記モバイル通信デバイスはセルラ電話であり、前記第１のセッションはＳＩＰ（Session Initiation Protocol）を用いて確立され、前記第２のセッションはＳＩＰを用いて確立される請求項１３に記載のモバイル通信デバイス。
【請求項１９】
前記比率は、計算された値ではなく、前記調節の結果である請求項１３に記載のモバイル通信デバイス。
【請求項２０】
モバイル通信デバイスであって、
第１のエアインタフェースと、
第２のエアインタフェースと、
前記第１のエアインタフェースから送信された第１のＶｏＩＰパケットの、前記第２のエアインタフェースから送信された第２のＶｏＩＰパケットに対する比率を調節する手段とを備え、
前記第１のＶｏＩＰパケットは第１のセッションにおいて送信され、前記第２のＶｏＩＰパケットは第２のセッションにおいて送信され、前記第１のセッションおよび前記第２のセッションは同時にアクティブであり、前記第１のＶｏＩＰパケットと前記第２のＶｏＩＰパケットとは、単一の音声データメディアストリームのための音声データを含むモバイル通信デバイス。
【請求項２１】
前記手段は、プロセッサ実行可能な命令のセットを実行するプロセッサである請求項２０に記載のモバイル通信デバイス。
【請求項１】
第１のデータペイロード、第２のデータペイロード、第３のデータペイロード、および第４のデータペイロードを通信する方法であって、前記第１のデータペイロードはメディアストリームのデータを含み、前記第２のデータペイロードは前記メディアストリーム内の前記第１のデータペイロードの後のデータを含み、前記第３のデータペイロードは前記メディアストリーム内の前記第２のデータペイロードの後のデータを含み、前記第４のデータペイロードは前記メディアストリーム内の前記第３のデータペイロードの後のデータを含み、前記方法は、
（ａ）第１のＩＰアドレスと第２のＩＰアドレスとの間で、第１のセッションにおいて、第１のＶｏＩＰ／ＶＩＰ（voice over Internet Protocol or video over Internet Protocol）パケットを通信することであって、前記第１のＩＰアドレスは第１のデバイスに関連付けられたＩＰアドレスであり、前記第２のＩＰアドレスは第２のデバイスに関連付けられたＩＰアドレスであり、前記第１のＶｏＩＰ／ＶＩＰパケットを通信することは、前記第１のＶｏＩＰ／ＶＩＰパケットを、第１のネットワーク上のトランシーバと前記第１のデバイスとの間で、第１の無線通信リンクを介して通信することを含み、前記第１のＶｏＩＰ／ＶＩＰパケットは前記第１のデータペイロードを含むことと、
（ｂ）第３のＩＰアドレスと前記第２のＩＰアドレスとの間で、第２のセッションにおいて、第２のＶｏＩＰ／ＶＩＰパケットを通信することであって、前記第３のＩＰアドレスは前記第１のデバイスに関連付けられたＩＰアドレスであり、前記第１のセッションと前記第２のセッションとは同時にアクティブであり、前記第２のＶｏＩＰ／ＶＩＰパケットを通信することは、前記第２のＶｏＩＰ／ＶＩＰパケットを、第２のネットワーク上のトランシーバと前記第１のデバイスとの間で、第２の無線通信リンクを介して通信することを含み、前記第２のＶｏＩＰ／ＶＩＰパケットは前記第２のデータペイロードを含むことと、
（ｃ）前記（ｂ）の後、前記第１の無線通信リンクを介して、前記第１のＩＰアドレスと前記第２のＩＰアドレスとの間で、前記第１のセッションにおいて、第３のＶｏＩＰ／ＶＩＰパケットを通信することであって、前記第３のＶｏＩＰ／ＶＩＰパケットは、前記第３のデータペイロードを含むことと、
（ｄ）前記（ｃ）の後、前記第２の無線通信リンクを介して、前記第２のＩＰアドレスと前記第３のＩＰアドレスとの間で、前記第２のセッションにおいて、第４のＶｏＩＰ／ＶＩＰパケットを通信することであって、前記第４のＶｏＩＰ／ＶＩＰパケットは、前記第４のデータペイロードを含むことと、
（ｅ）前記第１、第２、第３、および第４のデータペイロードを、第１、第２、第３、第４のデータペイロードの順に順序付けることによって、前記第２のデバイスにおいて、前記メディアストリームの少なくとも一部を再構築することと
を備える方法。
【請求項２】
前記第１および第３のＶｏＩＰ／ＶＩＰパケットは、無線ＬＡＮ（local area network）通信プロトコルにしたがって、前記第１の無線通信リンクを介して通信され、前記第２および第４のＶｏＩＰ／ＶＩＰパケットは、セルラ電話通信プロトコルにしたがって、前記第２の無線通信リンクを介して通信され、前記第１の無線デバイスは、ＩＰ電話、セルラ電話、ＰＤＡ（パーソナル・デジタル・アシスタント）、無線通信機能を有するコンピュータからなるグループから採用される請求項１に記載の方法。
【請求項３】
前記第１、第２、第３、および第４のＶｏＩＰ／ＶＩＰパケットは、それぞれがＲＴＰ（Real-Rime Transport Protocol）タイムスタンプを含んでいるＲＴＰパケットであり、前記再構築するステップ（ｅ）は、前記ＲＴＰタイムスタンプを用いて前記順序付けを行うことを含む請求項１に記載の方法。
【請求項４】
前記第１、第２、第３、および第４のＶｏＩＰ／ＶＩＰパケットは、それぞれがＲＴＰ（Real-Rime Transport Protocol）シーケンス番号を含んでいるＲＴＰパケットであり、前記再構築するステップ（ｅ）は、前記ＲＴＰシーケンス番号を用いて前記順序付けを行うことを含む請求項１に記載の方法。
【請求項５】
前記第１のセッションに関するサービス品質情報を含む第１のＲＴＣＰ（Real-Time Control Protocol）受信機レポートを、前記第１のデバイスにおいて受信することと、
前記第１のセッションに関するサービス品質情報を用いて、前記第１のセッションにおいて単位時間当たりに通信されるＶｏＩＰ／ＶＩＰパケットの、前記第２のセッションにおいて単位時間当たりに通信されるＶｏＩＰ／ＶＩＰパケットに対する比率を変えることと
を更に備える請求項１に記載の方法。
【請求項６】
前記第１の無線通信リンクの信号強度である検出済信号強度を示す情報を受信することと、
前記情報を用いて、前記第１のセッションにおいて単位時間当たりに通信されるＶｏＩＰ／ＶＩＰパケットの、前記第２の通信セッションにおいて単位時間当たりに通信されるＶｏＩＰ／ＶＩＰパケットに対する比率を変えることと
を更に備える請求項１に記載の方法。
【請求項７】
前記第１のセッションにおいて、前記第１のデバイスから前記第２のデバイスへと、前記第１のセッションを識別するＳＩＰ（Session Initialization Protocol）ＳＰＡＷＮメッセージを通信することと、
前記第２のデバイスから前記第１のデバイスへ、ＳＰＡＷＮ識別子を含むＳＩＰ ＯＫメッセージを通信することと、
前記第１のデバイスから前記第２のデバイスへ、前記ＳＰＡＷＮ識別子を含むＳＩＰ ＩＮＶＩＴＥメッセージを通信することと、
前記ＳＩＰ ＩＮＶＩＴＥメッセージを前記第２のデバイスにおいて受信することとを更に備え、
前記第２のデバイスは、前記ＳＩＰ ＩＮＶＩＴＥメッセージを用いて、前記第２のセッションを前記第１のセッションに関連付け、前記第２のセッションは、前記ＳＩＰ ＩＮＶＩＴＥメッセージの通信の結果として確立される請求項１に記載の方法。
【請求項８】
前記第１データペイロードのデータ、前記第２のデータペイロードのデータ、前記第３のデータペイロードのデータ、および前記第４のデータペイロードのデータは、音声データ、静止画像データ、ビデオデータからなるグループから採用されるタイプからなる請求項１に記載の方法。
【請求項９】
メディアストリームの複数のデータペイロードを通信する方法であって、
（ａ）モバイル通信デバイスと第２のデバイスとの間に、第１のＶｏＩＰ／ＶＩＰ（Voice over Internet Protocol or Video over Internet Protocol）通信パスを確立することであって、前記第１のＶｏＩＰ／ＶＩＰ通信パスは、前記モバイル通信デバイス上の第１のエアインタフェースと、第１のネットワーク上のアクセスポイントとの間の第１の無線通信リンクを含むことと、
（ｂ）前記モバイル通信デバイスと前記第２のデバイスとの間に、第２のＶｏＩＰ／ＶＩＰ（Voice over Internet Protocol or Video over Internet Protocol）通信パスを確立することであって、前記第２のＶｏＩＰ／ＶＩＰ通信パスは、前記モバイル通信デバイス上の第２のエアインタフェースと、第２のネットワーク上のアクセスポイントとの間の第２の無線通信リンクを含むことと、
（ｃ）前記データペイロードの第１のサブセットを、前記第１のＶｏＩＰ／ＶＩＰ通信パスを介して、前記モバイル通信デバイスから前記第２のデバイスへ通信することと、
（ｄ）前記データペイロードの第２のサブセットを、前記第２のＶｏＩＰ／ＶＩＰ通信パスを介して、前記モバイル通信デバイスから前記第２のデバイスへ通信することと、
（ｅ）前記モバイル通信デバイスから前記第２のデバイスへと前記第１のＶｏＩＰ／ＶＩＰ通信パスを介して通信されるデータペイロードの、前記モバイル通信デバイスから前記第２のデバイスへと前記第２のＶｏＩＰ／ＶＩＰ通信パスを介して通信されるデータペイロードの比率を複数回調節することと、
（ｆ）前記データペイロードの第１および第２のサブセットを前記第２のデバイス上で受信して、前記第１および第２のサブセットのデータペイロードを順序付けして、前記メディアストリームを再構築することと
を備える方法。
【請求項１０】
前記モバイル通信デバイスはセルラ電話であり、前記第１のネットワークはローカルエリアネットワーク（ＬＡＮ）であり、前記第１のエアインタフェースは８０２．１１インタフェースであり、前記第２のネットワークはセルラ電話ネットワークであり、前記第２のエアインタフェースはセルラ電話インタフェースである請求項９に記載の方法。
【請求項１１】
前記比率は、前記（ｅ）において、前記ＶｏＩＰ／ＶＩＰ通信パスによって提供されるサービス品質の第１の評価を行い、前記第２のＶｏＩＰ／ＶＩＰ通信パスによって提供されるサービス品質の第２の評価を行い、その後、前記第１および第２の評価を用いて、前記第１のＶｏＩＰ／ＶＩＰ通信パスを介したデータペイロードの送信と、前記第２のＶｏＩＰ／ＶＩＰ通信パスを介したデータペイロードの送信とを制御することによって調節される請求項９に記載の方法。
【請求項１２】
前記比率は、計算された値ではなく、前記調節の結果である請求項９に記載の方法。
【請求項１３】
モバイル通信デバイスであって、
第１のエアインタフェースと、
第２のエアインタフェースと、
プロトコル処理レイヤのスタックを実行するプロセッサとを備え、
第１のＶｏＩＰ／ＶＩＰデータペイロードが、第１のセッションにおいて、前記第１のエアインタフェースから第２のデバイスへ送信され、第２のＶｏＩＰ／ＶＩＰデータペイロードが、第２のセッションにおいて、前記第２のエアインタフェースから前記第２のデバイスへ送信され、単位時間当たりに、前記第１のエアインタフェースから送信される第１のＶｏＩＰ／ＶＩＰデータペイロードの数の、前記第２のエアインタフェースから送信される第２のＶｏＩＰ／ＶＩＰペイロードの数に対する比率が、前記第１および第２のＶｏＩＰ／ＶＩＰデータペイロードの送信中に複数回調節され、前記第１および第２のＶｏＩＰ／ＶＩＰデータペイロードは、単一のメディアストリームのペイロードであるモバイル通信デバイス。
【請求項１４】
前記プロセッサは、
前記第１のセッションのサービス品質を評価することと、
前記第２のセッションのサービス品質を評価することと
からなる各ステップを実行するためのプロセッサ実行可能命令のセットを実行する請求項１３に記載のモバイル通信デバイス。
【請求項１５】
前記プロセッサは、
前記第１のセッションのサービス品質を評価することと、
前記評価のうちの少なくとも一部に基づいて、前記第２のセッションが確立されるべきであることを決定することと
からなる各ステップを実行するためのプロセッサ実行可能命令のセットを実行するが、前記決定の結果として、前記第２のＶｏＩＰ／ＶＩＰデータペイロードの前記送信に先立って、前記第２のセッションが確立される請求項１４に記載のモバイル通信デバイス。
【請求項１６】
前記プロセッサは、
前記第１のＶｏＩＰ／ＶＩＰデータペイロードを通信する際に含まれる第１のアクセスポイントから、第１の信号強度情報を受信することと、
前記第２のＶｏＩＰ／ＶＩＰデータペイロードを通信する際に含まれる第２のアクセスポイントから、第２の信号強度情報を受信することと、
前記第１の信号強度情報と前記第２の信号強度情報とに少なくとも部分的に基づいて、前記第１のエアインタフェースから送信される前記第１のＶｏＩＰ／ＶＩＰデータペイロードの、前記第２のエアインタフェースから送信される前記第２のＶｏＩＰ／ＶＩＰデータペイロードに対する比率を調節することと
からなる各ステップを実行するためのプロセッサ実行可能命令のセットを実行する請求項１３に記載のモバイル通信デバイス。
【請求項１７】
前記プロセッサは、
前記第１のＶｏＩＰ／ＶＩＰデータペイロードを通信する際に含まれる第１のアクセスポイントから、第１のデータレート情報を受信することと、
前記第２のＶｏＩＰ／ＶＩＰデータペイロードを通信する際に含まれる第２のアクセスポイントから、第２のデータレート情報を受信することと、
前記第１のデータレート情報と前記第２のデータレート情報とに少なくとも部分的に基づいて、前記第１のエアインタフェースから送信される前記第１のＶｏＩＰ／ＶＩＰデータペイロードの、前記第２のエアインタフェースから送信される前記第２のＶｏＩＰ／ＶＩＰデータペイロードに対する比率を調節することと
からなる各ステップを実行するためのプロセッサ実行可能命令のセットを実行する請求項１３に記載のモバイル通信デバイス。
【請求項１８】
前記モバイル通信デバイスはセルラ電話であり、前記第１のセッションはＳＩＰ（Session Initiation Protocol）を用いて確立され、前記第２のセッションはＳＩＰを用いて確立される請求項１３に記載のモバイル通信デバイス。
【請求項１９】
前記比率は、計算された値ではなく、前記調節の結果である請求項１３に記載のモバイル通信デバイス。
【請求項２０】
モバイル通信デバイスであって、
第１のエアインタフェースと、
第２のエアインタフェースと、
前記第１のエアインタフェースから送信された第１のＶｏＩＰパケットの、前記第２のエアインタフェースから送信された第２のＶｏＩＰパケットに対する比率を調節する手段とを備え、
前記第１のＶｏＩＰパケットは第１のセッションにおいて送信され、前記第２のＶｏＩＰパケットは第２のセッションにおいて送信され、前記第１のセッションおよび前記第２のセッションは同時にアクティブであり、前記第１のＶｏＩＰパケットと前記第２のＶｏＩＰパケットとは、単一の音声データメディアストリームのための音声データを含むモバイル通信デバイス。
【請求項２１】
前記手段は、プロセッサ実行可能な命令のセットを実行するプロセッサである請求項２０に記載のモバイル通信デバイス。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１０Ａ】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１０Ａ】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公表番号】特表２００９−５０６６８０（Ｐ２００９−５０６６８０Ａ）
【公表日】平成２１年２月１２日（２００９．２．１２）
【国際特許分類】
【出願番号】特願２００８−５２８２０９（Ｐ２００８−５２８２０９）
【出願日】平成１８年８月２４日（２００６．８．２４）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０３３２７１
【国際公開番号】ＷＯ２００７／０２５１６１
【国際公開日】平成１９年３月１日（２００７．３．１）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公表日】平成２１年２月１２日（２００９．２．１２）
【国際特許分類】
【出願日】平成１８年８月２４日（２００６．８．２４）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０３３２７１
【国際公開番号】ＷＯ２００７／０２５１６１
【国際公開日】平成１９年３月１日（２００７．３．１）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]