JP2016028509A - モバイル端末における高度なリアルタイムｉｐ通信の方法及びシステム - Google Patents

Abstract

【課題】 本発明は、モバイル端末における高度なリアルタイムＩＰ通信の方法及びシステムを提供する。
【解決手段】 ＶｏＩＰ（Voice over Internet Protocol）呼、レガシ回線呼を生成し、ＬＴＥ（Long Term Evolution）モデム及びレガシモデムの両方のモデムを備えたモバイル端末でＬＴＥモデム又はレガシモデムを介してＳＭＳ（Short Message Service）を送信／受信する。さらに、ＲＣＳ（Rich Communications Services）機能の可能なモバイル端末において無線を動的に選択する。ＳＩＰ（Session Initiation Protocol module）スタック機能をモバイル端末にある異なるプロセッサに渡り分散させ、異なるネットワークインタフェースへ向ける。
【選択図】 図２

Description

本発明は、標準ＲＣＳ、ＩＲ．９２、ＩＲ．９４及びＩＭＳ（Internet Protocol Multimedia Subsystem）を利用して、ＲＣＳ（Rich Communications Services）機能を、特にスマートフォン及びタブレットコンピュータのようなクライアント装置に統合するための枠組み及びアーキテクチャに関する。

ＲＣＳは、音声及びＳＭＳ（Short Message Service）のようなレガシ機能に対応しながら、音声、ビデオ、メッセージング、プレゼンス、能力、コンテンツ共有、及び他の形式の通信を含む、同時使用可能な収束した豊かな通信経験を提供するモバイルアプリケーション及びサービスを定めるＧＳＭＡ（Global System for Mobile Communications Association）イニシアチブである。

ＩＰマルチメディアサブシステム又はＩＭＳは、モバイル及び固定マルチメディアサービスを提供したいと望む電気通信オペレータのための標準化された次世代ネットワーク（ＮＧＮ）アーキテクチャである。ＩＭＳは、ＳＩＰ（Session Initiation Protocol）の３ＧＰＰ（３rd Generation Partnership Project）により標準化された実装に基づくＶｏＩＰ（Voice-over-IP）実装を用い、標準的なＩＰ（Internet Protocol）上で動作する。既存の電話システム、パケット及び交換の両者がサポートされる。

ＧＳＭＡ（GSM Association）は、工業基準ＩＲ．９２「IMS Profile for Voice and SMS」、及びビデオを追加するためにＩＲ．９４を定めている。これら２つの工業基準は、参照することにより本願明細書に組み込まれる。

標準的なモバイル端末（電話機、装置）のコアは、モデム（ＬＴＥ（Long Term Evolution）、３Ｇ（Third Generation）又はＬＴＥと３Ｇの両方の組合せ）及びアプリケーションプロセッサを有する。３Ｇモデムは、ＧＳＭ（登録商標）（Global System for Mobile Communications）モデム又はＣＤＭＡ（Code Division Multiple Access）モデムを有する。モバイル端末のユーザ制御は、アプリケーションプロセッサで動作するソフトウェアにより提供される。アプリケーションプロセッサ上のソフトウェアによるモデムの制御は、伝統的に「ＡＴ」コマンドストリングを通じて実行される。例えば、電話番号１-８０５-５５５-１２１２をダイヤルするために、アプリケーションは、モデムに文字列「ATD １８０５５５５１２１２」を送信する。この文字列は、モデムに回線交換呼ＧＳＭ（登録商標）（Global System for Mobile Communications）又はＣＤＭＡ（Code Division Multiple Access）を開始するよう指示する。

図１を参照すると、モデム端末１００内のアプリケーションプロセッサ１１０の標準的なソフトウェアアーキテクチャを示す。アプリケーションプロセッサ１１０により実行されるソフトウェアアーキテクチャは、電話ダイヤラ１２０、ＳＭＳ（Short Message Service）アプリケーション１１５、電話マネジャ１３０、ＳＭＳマネジャ１２５、無線インタフェース層（ＲＩＬ）１０１、モデム１６０を動作するためのモデムドライバ１０４を有する。

例として、ユーザが、電話ダイヤラ１２０又はＳＭＳアプリケーション１１５プログラムを介して発呼するとき又はＳＭＳを送信するとき、電話マネジャ１３０は、無線インタフェース層１０１にコマンドを発行する。無線インタフェース層１０１は、そのコマンドをＡＴコマンドに変換する。ＲＩＬ１０１は、そのメッセージをモデムドライバ１０４へ直接渡し、又は文字列を処理し、モデムドライバ１０４に異なるメッセージを供給して、所要のモデム１６０の機能に影響を与える。

本発明は、モバイル端末における高度なリアルタイムＩＰ通信の方法及びシステムを提供する。

ＶｏＩＰ（Voice over Internet Protocol）呼、レガシ回線呼を生成し、ＬＴＥ（Long Term Evolution）モデム及びレガシモデムの両方のモデムを備えたモバイル端末でＬＴＥモデム又はレガシモデムを介してＳＭＳ（Short Message Service）を送信／受信し、ＬＴＥモデムとレガシモデムとの間で切り替え、モバイル端末にある既存のアプリケーションを用いて全てのレガシモデム機能を提供する方法が開示される。ＳＩＰ（Session Initiation Protocol module）及びＣＳＭ（制御／状態モジュール）サブシステムは、ＶｏＩＰ呼を生成し、ＬＴＥモデムを用いてＩＰを介してＳＭＳを送信／受信する（SMS over Internet Protocol：ＳＭＳｏＩＰ）。コマンドハンドラモジュールは、音声及びＳＭＳメッセージをモデムドライバからＳＩＰ／ＣＳＭへ向け、全ての他のメッセージはレガシモデムに直接渡される。ネットワーク又はモバイル端末により設定された無線ポリシに基づき、ＣＳＭモジュールは、呼又はＳＭＳがＳＩＰモジュール及び（必要に応じて）音声エンジンにより処理されるのかレガシモデムに渡されるのかを決定する。コマンドハンドラモジュールは、音声及びＳＭＳメッセージをレガシモデムからＳＩＰ／ＣＳＭへ向け、全ての他のメッセージは、モデムドライバを通過させられる。

ＲＣＳ（Rich Communications Services）、ＬＴＥ（Long Term Evolution）、レガシモデム及び代替ネットワークインタフェースの可能なモバイル端末において無線を動的に選択する方法も開示される。モバイル端末のＬＴＥプロセッサにある無線ポリシマネジャ（ＲＰＭ）は、通信機能毎に使用すべき無線又はネットワークを選択する。ＲＰＭは、決定を行うためのパラメータ又はルールを設定するためにネットワークオペレータ又はモバイル端末にアクセス可能である。

モバイル端末のＳＩＰ（Session Initiation Protocol module）スタック機能を、単一の認可されたＳＩＰコネクションを用いて、異なるネットワークインタフェースへ向けるための方法が開示される。ＳＩＰスタックとＬＴＥ（Long Term Evolution）ネットワークインタフェース又は任意の他の代替ネットワークインタフェースとの間にあるｖポートリダイレクタ（ＶＰＲ）モジュールは、モバイル端末又は対応する無線ネットワークのオペレータにより選択された無線ポリシに従って全てのＳＩＰパケットをリダイレクトする仮想ネットワークインタフェースを提供する。

モバイル端末のリアルタイムＩＰ（Internet Protocol）通信のＩＰパケットトラフィックをリダイレクトする方法であって、該ＩＰパケットトラフィックは、通常は、別のＳＩＰ（Session Initiation Protocol module）スタック及びＬＴＥプロセッサ外部の関連ソフトウェアを複製することなくＶｏＬＴＥ（Voice-over-Long-Term Evolution）の可能なＬＴＥプロセッサを通り代替ネットワークインタフェースへと通過する、方法が開示される。ｖポートリダイレクタ（ＶＰＲ）モジュールは、ＳＩＰスタックとＶｏＬＴＥの可能なＬＴＥプロセッサとの間に挿入され、通常はＬＴＥモデムを介して代替ネットワークインタフェースデーモンへ送信される全てのＩＰパケットをプロセッサ間通信（ＩＰＣ）メカニズムを用いてリダイレクトする。代替ネットワークインタフェースデーモンは、サブシステムと接続して代替ネットワークインタフェースデーモンにより確立したネットワークコネクションを維持し、代替ネットワークインタフェースデーモンにより確立したネットワークコネクションを介してＩＰパケットトラフィックを送信／受信する。全てのＳＩＰパケットトラフィックは、ＶｏＬＴＥ送信のために用いられるのと実質的に同じ認可されたＳＩＰコネクションを通過する。

ビデオパケットがＬＴＥモデムを介して伝送されるとき、ビデオコーデック機能を実行するアプリケーションプロセッサにより生成され及び／又は消費されるビデオパケットを、モバイル端末のＬＴＥ（Long Term Evolution）プロセッサへリダイレクトする方法が開示される。アプリケーションプロセッサで動作するビデオエンジンは、ＬＴＥモデムへ／からビデオパケットを送信及び受信する。ＬＴＥプロセッサのｖポートリダイレクタ（ＶＰＲ）モジュールは、ＬＴＥビデオベアラチャネルへのアクセスを要求する。ビデオパケットは、プロセッサ間通信（ＩＰＣ）メカニズムを用いてビデオエンジンとＶＰＲとの間で交換される。

モバイル端末上のアプリケーションプロセッサのビデオデータをＶｏＩＰ（Voice-over-Internet-Protocol）又はＶｏＬＴＥ（Voice over Long Term Evolution）に使用可能なＬＴＥ（Long Term Evolution）プロセッサの音声データと同期させる方法が開示される。同期情報は、ＬＴＥプロセッサの音声エンジンとアプリケーションプロセッサのビデオエンジンとの間で、プロセッサ間通信（ＩＰＣ）メカニズムを用いて交換される。ＩＰＣメカニズムは、ビデオエンジンと音声エンジンとの間にあり、ビデオエンジン及び音声エンジンにそれら個々の復号化レートを管理させ、音声及びビデオが同期されるようにする。

ＳＩＰ（Session Initiation Protocol）機能を異なるプロセッサに渡って分散させ、その間、モバイル端末に対して単一の認可されたＳＩＰコネクションを維持する方法が開示される。ｖポートリダイレクタ（ＶＰＲ）モジュールは、モバイル端末のＬＴＥプロセッサに設けられる。ＬＴＥプロセッサのＳＩＰモジュールは、ＶＰＲモジュールに、ＩＰマルチメディアサブシステム（ＩＭＳ）コアへのＳＩＰコネクションを開くよう要求する。ＳＩＰモジュールは、ＶＰＲモジュールコネクションを用いてＩＭＳコアに登録する。ＶＰＲモジュールは、モバイル端末内の他のＳＩＰモジュールがＩＭＳコアへのＶＰＲモジュールコネクションを使用することを許可する。

ＬＴＥ（Long Term Evolution）プロセッサを備えたモバイル端末で、ＬＴＥプロセッサ内のＳＩＰ（Session Initiation Protocol）により確立されたＩＰ（Internet Protocol）コネクションを用いてＲＣＳ（Rich Communications Services）機能を実施する方法が開示される。プロトコルアクセラレータは、モバイル端末のアプリケーションプロセッサに実装され、ＳＩＰ機能を提供する。制御／状態モジュール（ＣＳＭ）は、ＬＴＥプロセッサ内のＳＩＰモジュールにより実行されるべきＳＩＰ機能及びプロトコルアクセラレータで実施されるべきＳＩＰ機能を決定し、その決定に従って、ＬＴＥプロセッサ内のｖポートリダイレクタを介したＲＣＳデータをプロトコルアクセラレータ又はＬＴＥプロセッサ内のＳＩＰモジュールへ転送する。ＳＩＰデータは、ＶｏＩＰ（Voice-over-Internet-Protocol）及びＳＭＳ（Short Message Service）のためにＬＴＥプロセッサ内のＳＩＰモジュールにより確立された単一の認可されたコネクションを介して送信される。

ＬＴＥ（Long Term Evolution）プロセッサを備えたモバイル装置上のＲＣＳ機能が、ＳＩＰ（Session Initiation Protocol）プロトコル機能がＬＴＥプロセッサ内に埋め込まれたＳＩＰスタックの外部で実行されることを要求するとき、二重問題を回避する方法が開示される。ＬＴＥプロセッサ内のＳＩＰスタックは、ネットワークに登録し、ＶｏＩＰ（Voice-over-Internet-Protocol）及びＳＭＳｏＩＰ（Short Message Service over Internet Protocol）のために、ＩＭＳ（Internet Protocol Multimedia Subsystem）コアへの認可されたＳＩＰコネクションを確立する。ＬＴＥプロセッサの外部で動作するＳＩＰ機能を要求する後続のＲＣＳ機能のための且つＬＴＥモデムを通じて送信されるべき全てのＩＰ（Internet Protocol）パケットは、ＩＭＳコアへの単一の認可されたＳＩＰコネクションを維持するＬＴＥプロセッサのｖポートリダイレクタ（ＶＰＲ）を通じて転送される。ＩＭＳコアから入来し、ＬＴＥモデムを介して認可されたＳＩＰコネクションを介して受信されるパケットは、ＶＰＲを通じて、必要に応じて、ＬＴＥプロセッサ又はモバイル端末のアプリケーションプロセッサ内のプロトコルアクセラレータに組み込まれたＳＩＰスタックへ転送される。

本発明のこれらの及び他の目的は、以下の、種々の図面に示された好適な実施形態の詳細な説明を読んだ後に当業者に明らかになるだろう。

伝統的な携帯電話機のソフトウェアアーキテクチャを示す。 ＬＴＥプロセッサへのＶｏＩＰの追加を示す機能ブロック図である。 Ｗｉ−Ｆｉオフロードの追加を示す機能ブロック図である。 Ｗｉ−Ｆｉオフロードを有するビデオ呼の追加を示す機能ブロック図である。 ＲＣＳ機能の追加を示す機能ブロック図である。 Ｗｉ−Ｆｉ（登録商標）オフロードのためにプロトコルアクセラレータからのトラフィックの低減を示す機能ブロック図である。

本願明細書及び特許請求の範囲では、用語「レガシモデム」は、特に、第２世代（２Ｇ）技術、第３世代（３Ｇ）技術、ＧＳＭ（登録商標）（Global System for Mobile Communications）技術、ＣＤＭＡ（Code division Multiple Access）技術、Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access）技術のような技術として定められる。用語「Long-Term Evolutionモデム」及び／又は「ＬＴＥモデム」は、ＬＴＥ（Long-Term Evolution）送信及び／又は受信技術が可能なように構成されたモデムとして定められる。用語「Long-Term Evolutionプロセッサ」及び／又は「ＬＴＥプロセッサ」は、ＬＴＥモデムとして構成され得る計算ユニットとして定められ、ＶｏＬＴＥ（Voice-over-Long-Term Evolution）を含むよう更に構成されても良く、特に、第２世代（２Ｇ）技術、第３世代（３Ｇ）技術、ＧＳＭ（登録商標）（Global System for Mobile Communications）技術、ＣＤＭＡ（Code division Multiple Access）技術、Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access）技術のようなレガシモデム技術の全てのバージョンを含むよう更に構成されても良く、ＬＴＥプロセッサ内に組み込まれても良い。さらに、用語「ネットワークインタフェース」は、モバイル端末と私設若しくは公衆ネットワークとの間の相互接続点として定められる。さらに、用語「代替ネットワークインタフェース」は、特に、Ｗｉ−Ｆｉ（登録商標）技術、ＤＰＲＳ（DECT Packet Radio Services）及びイーサネット（登録商標）技術のような送信及び／又は受信技術のあらゆるバージョンが可能なネットワークインタフェースとして定められ、アプリケーションプロセッサで動作する。さらに、用語「代替ネットワークインタフェースデーモン」は、代替ネットワークインタフェースへの接続を管理するために用いられるアプリケーションプロセッサで動作する処理である。本願明細書及び特許請求の範囲を通じて、特定の技術が特定の使用例として提示されるが、全ての場合において、特定技術の記載は、請求の範囲を特定の技術に限定するものではなく、上述のように一般化することを目的としている。例えば、Ｗｉ−Ｆｉ（登録商標）デーモンの議論は、上述のような任意の又はあらゆるバージョンの代替ネットワークインタフェースデーモンの議論として考えられ、３Ｇモデム技術の議論は、上述のような任意の又はあらゆるバージョンのレガシモデムの議論として考えられるべきである。

本願明細書は、ＳＭＳ（Short Message Service）及びＶｏＬＴＥ（Voice over Long Term Evolution）、ビデオ、ＲＣＳ（Rich Communication Suite）サポート、及びＷｉ−Ｆｉ（登録商標）オフロードをモデム端末に追加する完全なソフトウェアシステムを記載する。このソフトウェアシステムは、ＶｏＬＴＥ機能をＬＴＥプロセッサに追加することで開始する。最後の章（図６）は、音声及びビデオ呼、ＳＭＳｏＩＰ（SMS over Internet Protocol）、ＲＣＳ機能（特に、ＩＭ（instant messaging）、ファイル転送及びコンテンツ共有）、及びＷｉ−Ｆｉ（登録商標）オフロードを含むフル機能のシステムを記載する。本願明細書で開示するのはモジュラアプローチなので、同じ設計及びソフトウェアブロックを用いて、このフル機能のシステムのサブセットを提供することが比較的容易である。例えば、図２は、単にＶｏＬＴＥ、ＳＭＳｏＩＰ及びＳＲＶＣＣ（Single Radio Voice Call Continuity）のための製品であるが、図３はＷｉ−Ｆｉ（登録商標）オフロードを追加しており、図４はビデオ呼を追加している、等である。

＜レガシアーキテクチャへのＶｏＩＰ（ＶｏＬＴＥ）の追加＞
モバイル端末にＶｏＩＰアプリケーションを追加する異なるアプローチがある。１つのアプローチは、現在のアンドロイド電話スタック（図１の電話マネジャ、ＳＭＳマネジャ１２５、ＲＩＬ１０１を参照）と平行して、完全に別個のアプリケーションを作成することである。別のアプローチは、電話スタックに変更を行い、既存の電話マネジャ１３０に、呼がＶｏＩＰ呼（又はレガシ交換呼）でるか否かを決定させ、ＶｏＩＰプロトコルスタック（又はレガシ音声スタック）へ呼を処理するよう指示を送らせることである。

ＬＴＥモデムを介する全ての呼はＶｏＩＰを用いて行われるので、ＬＴＥプロセッサにとって、図１に示すように、電話及びＳＭＳアプリケーションに対して同じＲＩＬインタフェースを提示して、レガシ音声呼及びＳＭＳのための同じコマンドが受け付けられ処理されるようにすることは非常に望ましい。

したがって、ＶｏＩＰ呼、レガシ回線交換呼の確立、ＬＴＥモデム若しくはレガシモデム（２Ｇ、３Ｇ）を介したＳＭＳの送信／受信、及びＬＴＥとレガシモデムとの両方を備えたモバイル端末での（ＩＲ．９２標準により要求されるような）それらの間の切替、音声及びＳＭＳのためにモバイル端末上の既存アプリケーションを用いた（ＳＩＭ登録、ＳＩＭアドレス等のような）全てのレガシモデム機能の提供、並びに全てのレガシモデム機能の保持を可能にする技術が開示される。ＬＴＥプロセッサ上のＳＩＰソフトウェアにより提供されるＶｏＩＰ呼の確立及びＳＭＳの送信／受信のためにＳＩＰスタックのサブシステム及び制御ソフトウェアを追加することに加えて、ソフトウェアモジュールコマンドハンドラは、音声及びＳＭＳメッセージをモデムドライバからＳＩＰ／ＣＳＭサブシステムへ向け、全ての他のメッセージをレガシモデムに直接渡す。ＣＳＭモジュールは、ネットワーク又はモバイル端末により設定された無線ポリシに基づき、呼又はＳＭＳがＳＩＰスタック及び（必要に応じて）音声エンジンにより処理されるのかレガシモデムを通過させられるのかを決定する。また、コマンドハンドラモジュールは、音声及びＳＭＳメッセージをレガシモデムからＳＩＰ／ＣＳＭサブシステムへ向け、全ての他のメッセージは、モデムドライバを通過させられる。

音声、ＳＭＳ、並びにＩＭ、ビデオ呼等のような他の通信機能（一般的にＲＣＳ機能として知られている）のための無線ポリシを、モバイル端末又はモバイルネットワークオペレータにより、機能毎に選択させることを可能にすることが開示される。ソフトウェアモジュールは、音声呼又はＳＭＳメッセージ又は他のＲＣＳ機能のためにどのネットワークインタフェースを用いるかを決定するパラメータ又はルールを設定するために、ネットワーク又はモバイル端末にアクセス可能である。

また、多数の通信機能（一般的にＲＣＳとして知られる、音声、ＳＭＳ、ＩＭ、ビデオ呼、ファイル共有、コンテンツ共有、位置、アドレス帳同期、等を含む）を有するモバイル端末が（ＬＴＥ、３Ｇ、Ｗｉ−Ｆｉ（登録商標）等のような）選択したネットワークインタフェースでこれらの機能のうちの各々を選択的に実行するための、及びモバイル端末又はネットワークオペレータにより動的に制御されるべきネットワークインタフェースの選択のための、又はモバイル端末がこの選択を行うための技術が開示される。ネットワークインタフェースの選択を提供し、どのネットワークインタフェース（例えば、ＬＴＥ、３Ｇ、Ｗｉ−Ｆｉ（登録商標））が（音声又はＩＭ又はビデオ等のような）各通信機能のために用いられるかを決定するためにモバイル端末で動作するＡＬＬ通信アプリケーションにより検査され、異なる通信機能のために無線の選択を変更するためにモバイルネットワークオペレータ又はモバイル端末にアクセス可能なソフトウェアのモジュールが使用できる。

図２に示すように、モバイル端末２００内のＲＩＬ２０５の下に、ＬＴＥプロセッサに電話及びＳＭＳアプリケーションとの（ＶｏＬＴＥ機能のための）ＲＩＬインタフェース１０１を提供するために、追加ＶｏＬＴＥブロックが追加される。モバイル端末２００のＬＴＥプロセッサ２６０は、レガシモデム制御及びユーザプレーンモジュール２７０と、追加ＶｏＬＴＥブロックとを有する。追加ＶｏＬＴＥブロックは、コマンドハンドラ２６５、ＩＳＩ（Internet Service Interface）モジュール２８２、音声エンジンモジュール２８４、ＳＩＰ（Session Initiation Protocol）モジュール２８８、ＯＳＡＬ（Operating System Abstraction Layer）モジュール２８６、制御／状態モジュール（ＣＳＭ）２７５を含む。ＣＳＭ２７５は、無線ポリシマネジャ（ＲＰＭ）２８０を含む。ＲＩＬ（図２に２０５として示す）から追加ＶｏＬＴＥブロック２６５、２８２、２８４、２８８、２８６、２７０、２７５へのコマンドは、標準的なＡＴコマンド又はモデムチップベンダにより規定された独自インタフェースであっても良い。

図２に示したアーキテクチャでは、ＬＴＥ及びレガシモデムを含むＬＴＥプロセッサにとって、コマンド及びイベントは、呼がＩＰネットワーク又はレガシ回線ネットワークを介して確立されるかに拘わらず、同じである。このアーキテクチャの追加ソフトウェアコンポーネントは、次の通りである。

・コマンドハンドラ２６５−このモジュールは、コマンド及びイベントの転送を担う。（モデムドライバを介した）ＲＩＬ２０５からの全ての音声呼及びＳＭＳコマンドは、ＣＳＭモジュール２７５へ転送される。残りのコマンドは、レガシモデムモジュール２７０へと通過する。モデムドライバ２０５からの全ての非音声呼、非ＳＭＳイベントは、コマンドハンドラ２６５に直接渡され、次にレガシモデム２７０へ渡される。音声及びＳＭＳイベントは、コマンドハンドラ２６５により捕らえられ、ＣＳＭ２７５に渡される。

・制御／状態モジュール（ＣＳＭ）２７５は、全ての音声呼及びＳＭＳセッションの管理を担う。

・ＩＳＩモジュール２８２は、レガシモデムモジュール２７０、ＳＩＰモジュール２８８及び音声エンジンモジュール２８４と通信するために、ＣＳＭモジュール２７５にプロトコルに依存しないインタフェースを提供する。

・ＳＩＰ２８８プロトコル。ＳＩＰモジュール２８８は、呼及びＳＭＳメッセージングを管理するために、全ての必要なＳＩＰ動作を実行する。

・音声エンジン２８４は、ＩＳＩ２８２コマンドを用いて、ＣＳＭモジュール２７５により制御される。音声エンジン２８４は、音声サンプルの処理、符号化／復号化、ＡＥＣ（acoustic echo cancellation）、ジッタバッファ及びＰＬＣ（packet loss compensation）を含む全ての音声処理機能を実行する。音声エンジン２８４は、ネットワークを介して送信されるべきＲＴＰ（Real-Time Transport）パケットを生成し、ネットワークから受信したＲＴＰ音声パケットを処理する。

・ＯＳ抽出レイヤ（ＯＳＡＬ）モジュール２８６。ＯＳＡＬモジュール２８６は、コンポーネントを異なるオペレーティングシステム（例えば、ＬＩＮＵＸ（登録商標）、ＲＴＯＳ等）に移植するために、オペレーティングシステム固有の動作を抽出するために用いられる。例えば、ネットワークソケットのオープン及びクローズが含まれる。

・無線ポリシマネジャ（ＲＰＭ）２８０。音声呼をＶｏＩＰとレガシ技術との間で切り替え可能にするＩＲ−９２（ＶｏＬＴＥ）標準に対応するために、ＣＳＭモジュール２７５は、ＲＰＭ２８０サブモジュールを有する。ＲＰＭ２８０サブモジュールは、呼又はＳＭＳメッセージ毎にどのネットワークインタフェースを用いるかについての知的決定を行うよう設計される。ネットワークインタフェース選択の決定がモバイルネットワークオペレータにより行われる構成では、ＲＰＭモジュール２８０は、モバイルネットワークオペレータにより設定された無線ポリシ及びＬＴＥモデム制御プレーンからの情報に従う。

＜使用例：ＶｏＩＰ呼の着信の受け付け＞
モバイル端末２００は、サービスプロバイダに登録された後、音声呼を受信することができる。呼が開始又は受信されると、ＲＩＬモジュール２０５は、ネットワークからの全ての呼状態について、固定間隔でモデムドライバにポーリングする。ＳＩＰモジュール２８８は、ＯＳＡＬモジュール２８６を介してネットワークからの新しいコマンドを傾聴する。

ＶｏＩＰ呼の着信について生じる動作シーケンスを以下に示す。

１．着信呼があるとき、ＯＳＡＬモジュール２８６は、新しいＶｏＩＰセッションへの招待を受信する。

２．ＳＩＰモジュール２８８は、この要求を受信し、ＩＳＩモジュールを介してＣＳＭモジュール２７５へメッセージを送信する。

３．ＣＳＭモジュール２７５は、新しい呼の要求のために、コマンドハンドラ２６５へのイベントを生成する。このイベントは、モデムドライバ（及びＲＩＬ）２０５を介してダイヤラ１２０アプリケーションに渡される。

４．ＣＳＭモジュール２７５は、ＳＩＰモジュール２８８に、ネットワークへ、要求の受信に対して肯定応答するよう命じる。

５．ネットワークは、メッセージが受信されたことの肯定応答を送信する。

６．呼が応答されるのを待っている間、ＲＩＬモジュール２０５は、着信呼の状態について、固定間隔でモデムドライバ２０５にポーリングし続ける。

７．モデムドライバ２０５は、コマンドハンドラ２６５にコマンドを送信する。コマンドハンドラ２６５は、そのコマンドをＣＳＭモジュール２７５に渡す。

８．ＣＳＭモジュール２７５は、呼の現在の状態と共に応答する。

９．ユーザが呼に応答するとき、ダイヤラアプリケーション１２０は、呼に応答するよう、コマンドをモデムドライバ２０５へ送信する。

１０．モデムドライバ２０５は、コマンドハンドラ２６５にコマンドを渡す。コマンドハンドラ２６５は、そのコマンドをＣＳＭモジュール２７５に渡す。

１１．ＣＳＭモジュール２７５は、呼を受け付けるよう、ＳＩＰモジュール２８８に命じる。

１２．ＳＩＰモジュール２８８は、ネットワークに呼が応答されたことを知らせる。

１３．ネットワークは、呼が受け付けられたという肯定応答で応答する。

１４．ＣＳＭモジュール２７５は、音声エンジン２８４に、音声インタフェースとＩＰインタフェースのＲＴＰコネクションとの間で、ＯＳＡＬモジュール２８６を通じて、発呼パーティへの音声のストリーミングを開始するよう命じる。

１５．呼は動作中になる（接続される）。

ＣＳＭモジュール２７５は、次のＲＩＬ２０６ポーリング間隔で、モデムドライバ２０５への状態報告を続ける。

＜使用例：ＶｏＩＰ呼の発信＞
モバイル端末２００は、サービスプロバイダに登録された後、音声呼を開始することができる。ＶｏＩＰ呼の発信について生じる動作シーケンスを以下に示す。

１．ユーザは、ダイヤラアプリケーション１２０で呼を開始する。モデムドライバ２０５は、呼を開始するコマンドを受信する。

２．モデムドライバ２０５は、コマンドハンドラ２６５にコマンドを渡す。コマンドハンドラ２６５は、そのコマンドをＣＳＭモジュール２７５に渡す。

３．ＣＳＭモジュール２７５は、ＲＰＭモジュール２８０に問い合わせ、使用すべき正しいネットワークインタフェースを決定する。この場合、ＬＴＥ ＶｏＩＰが選択される。

４．ＣＳＭモジュール２７５は、呼を開始するよう、ＳＩＰモジュール２８８に知らせる。

５．ネットワークは、「トライング」メッセージで応答する。トライメッセージは、ＯＳＡＬモジュール２８６を介してＳＩＰモジュール２８８に渡される。

６．ＳＩＰモジュール２８８は、ＣＳＭモジュール２７５に新しいメッセージを通知する。ＣＳＭモジュール２７５は、「トライング」メッセージを受信したというメッセージをコマンドハンドラ２６５へ送信することにより、応答する。

７．コマンドハンドラ２６５は、メッセージをモデムドライバ２０５に渡す。

８．ネットワークは、「肯定応答」、メッセージを送信する。このメッセージは、ＯＳＡＬモジュール２８６を介してＳＩＰモジュール２８８に渡される。

９．ＳＩＰモジュール２８８は、ＣＳＭモジュール２７５に情報を渡す。

１０．固定ポーリング間隔で、モデムドライバ２０５は、全ての呼の状態について、ＲＩＬ２０５からコマンドを受信する。

１１．モデムドライバ２０５は、コマンドハンドラ２６５にコマンドを送信する。コマンドハンドラ２６５は、そのコマンドをＣＳＭモジュール２７５に渡す。

１２．ＣＳＭモジュール２７５は、呼の現在の状態を返す。

１３．遠端パーティが応答すると、ＳＩＰモジュール２８８は、ネットワークから（ＯＳＡＬモジュール２８６を介して）、遠端パーティが「受け付けた」（応答した）というメッセージを受信する。

１４．ＳＩＰモジュール２８８は、ＣＳＭモジュール２７５へメッセージを送信する。

１５．ＣＳＭモジュール２７５は、音声エンジン２８４に、音声インタフェースとＩＰインタフェースのＲＴＰコネクションとの間で、ＯＳＡＬモジュール２８６を通じて、着信パーティへの音声のストリーミングを開始するよう命じる。

１６．次のポーリング間隔で、呼状態についての新しい要求が、モデムドライバ２０５からコマンドハンドラ２６５を介してＣＳＭモジュール２７５に渡される。

１７．ＣＳＭモジュール２７５は、呼が応答されたことを報告する。このメッセージは、コマンドハンドラ２６５に渡され、そしてモデムドライバ２０５に渡される。

１８．呼は動作中になる（接続される）。

＜使用例：ＣＳ呼の着信＞
レガシ回線交換（ＣＳ）ネットワークが利用可能なとき、サービスプロバイダは、着信呼をレガシＣＳネットワークを介して転送し得る。ＶｏＩＰ呼の着信応答して生じる動作シーケンスを以下に示す。

１．遠隔ユーザは、レガシＣＳネットワークを介してモバイル端末２００に発呼する。

２．レガシモデム２７０は、ネットワークからコマンドを受信する。

３．レガシモデム２７０は、呼の着信が要求されているという非同期イベントを生成する。

４．コマンドハンドラ２６５は、このイベントをＣＳＭモジュール２７５に渡す。ＣＳＭモジュール２７５は、呼を処理するために初期化される。

５．ＣＳＭモジュール２７５は、コマンドハンドラ２６５へのイベントを生成する。コマンドハンドラ２６５は、このコマンドをモデムドライバ２０５に、そしてダイヤラアプリケーション１２０まで渡す。

６．モデムドライバ２０５は、固定間隔で呼の現在の状態について尋ねるコマンドを受信する。

７．イベント６におけるコマンドは、コマンドハンドラ２６５を用いてＣＳＭモジュール２７５に渡される。

８．ユーザが呼に応答するとき、モデムドライバ２０５は、呼に応答するコマンドを受信する。このコマンドは、コマンドハンドラ２６５を介してＣＳＭモジュール２７５に渡される。

９．ＣＳＭモジュール２７５は、これがレガシ回線交換（ＣＳ）呼であることが分かるので、ＣＳＭモジュール２７５は、コマンドハンドラ２６５を介してレガシモデムモジュール２７０へ（及び続いてネットワークへ）コマンドを送信する。

１０．レガシモデムモジュール２７０は、「呼が受け付けられた」というイベントで応答する。

１１．ＣＳＭモジュール２７５は、このイベントを、レガシモデムモジュール２７０からコマンドハンドラ２６５を通じて受信する。

１２．ＣＳＭモジュール２７５は、「呼が受け付けられた」イベントを、コマンドハンドラ２６５を用いてモデムドライバ２０５に渡す。

１３．呼は動作中になる。

１４．モデムドライバ２０５は、次に呼の状態についてポーリングされるとき、ＣＳＭモジュール２７５から呼が動作中であるという報告を受信する。

＜使用例：ＣＳ呼の発信＞
レガシＣＳネットワークが用いられるとき、発信呼は、レガシモデムモジュール２７０へ転送される。ＣＳ呼の発信について生じる動作シーケンスを以下に示す。

１．ユーザが呼を開始するとき、モデムドライバ２０５は、呼を開始するコマンドを受信する。

２．モデムドライバ２０５は、コマンドハンドラ２６５にコマンドを渡す。コマンドハンドラ２６５は、そのコマンドをＣＳＭモジュール２７５に渡す。

３．ＣＳＭモジュール２７５は、ＲＰＭモジュール２８０に問い合わせ、使用すべき正しいインタフェースを決定する。この場合、レガシモデムインタフェースが選択される。

４．ＣＳＭモジュール２７５は、呼を開始するよう、レガシモデムモジュール２７０に知らせる。

５．固定ポーリング間隔で、モデムドライバ２０５は、全ての呼の状態を要求するＲＩＬ２０５コマンドを受信する。

６．モデムドライバ２０５は、コマンドハンドラ２６５にコマンドを送信する。コマンドハンドラ２６５は、そのコマンドをＣＳＭモジュール２７５に渡す。

７．ＣＳＭモジュール２７５は、コマンドハンドラ２６５を通じてレガシモデムモジュール２７０へコマンドを送信することにより、レガシモデムモジュール２７０に呼の現在の状態について問い合わせる。

８．レガシモデムモジュール２７０は、呼の現在の状態と共に応答する。この情報は、コマンドハンドラ２６５を介してＣＳＭモジュール２７５へ送信される。

９．ＣＳＭモジュール２７５は、コマンドハンドラ２６５を介して、呼の現在の状態と共にモデムドライバ２０５に応答する。

１０．多数のポーリング間隔の後、遠隔パーティが応答する。

１１．次のポーリング間隔で、呼状態についての新しい要求が、モデムドライバ２０５からコマンドハンドラ２６５に、次いでＣＳＭモジュール２７５に渡される。

１２．ＣＳＭモジュール２７５は、コマンドハンドラ２６５を介してコマンドを送信することにより、レガシモデムモジュール２７０に呼の現在の状態について問い合わせる。

１３．レガシモデムモジュール２７０は、「動作中」に変更された呼の現在の状態と共に応答する。この状態は、コマンドハンドラ２６５を介してＣＳＭモジュール２７５へ送信される。

１４．ＣＳＭモジュール２７５は、コマンドハンドラ２６５を介して、呼の現在の状態（つまり、「動作中」）と共にモデムドライバ（ＲＩＬポーリング）２０５に応答する。

１５．呼は動作中になる。

＜使用例：ＵＳＳＤサポート＞
ＧＳＭ（登録商標）サービスプロバイダは、ＵＳＳＤ（Unstructured Supplementary Service Data）と呼ばれるプロトコルを用いて、特定の簡易非音声サービスを提供する。ＬＴＥモデムは、同様のサービスを提供する。

ＧＳＭ（登録商標）を介したＵＳＳＤに対応する動作シーケンスを以下に示す。

１．ユーザは、（モバイル端末２００上のアプリケーションを介して）ＵＳＳＤサービスの要求を開始する。これは、特殊コードをダイヤルすることにより行われる。

２．モデムドライバ２０５は、このダイヤルアウト要求を受信してコマンドハンドラ２６５に渡す。コマンドハンドラ２６５は、この要求をＣＳＭモジュール２７５に渡す。

３．ＣＳＭモジュール２７５は、ＣＳ呼の発信のように、このシーケンスを処理する。ＣＳＭモジュール２７５は、ＲＰＭモジュール２８０に問い合わせ、使用すべき正しいネットワークインタフェースを決定する。この場合、ＧＳＭ（登録商標）が選択される。

４．ＣＳＭモジュール２７５は、このダイヤルコマンドを、コマンドハンドラ２６５を介してレガシモデムモジュール２７０に渡す。

５．レガシモデムモジュール２７０は、（コマンドハンドラ２６５を介して）ＣＳＭモジュール２７５に渡される応答を提供し、コードをネットワークへ転送する。

６．ＣＳＭモジュール２７５は、コマンドハンドラ２６５を介してモデムドライバ２０５に応答を返す。

７．サービスプロバイダがコードを処理した後、未承諾応答が、ネットワークを介してレガシモデムモジュール２７０へ送信される。

８．レガシモデムモジュール２７０は、この応答をコマンドハンドラ２６５に渡す。コマンドハンドラ２６５は、この応答をモデムドライバ２０５に渡す。

ＬＴＥモデム（ネットワーク）を介したＵＳＳＤサービスの要求は、同様のシーケンスに従う。

＜Ｗｉ−Ｆｉ（登録商標）オフロードの追加＞
特定のモバイルネットワークオペレータ（ＭＮＯ）が要求する機能の１つは、ＶｏＩＰ及びＳＭＳｏＩＰがＷｉ−Ｆｉ（登録商標）を介してオフロードされることである。これは、ＬＴＥネットワーク上の無線ネットワークトラフィックを低減する。この機能をモバイル端末に提供するための好適なアプローチは、図３に示すように、ＬＴＥプロセッサにメッセージリダイレクタ及び他のソフトウェアモジュールを追加することである。本願明細書を通じて、登録商標Ｗｉ−Ｆｉは、技術又は保証の出所を意味するのではなく、Wi-Fi AllianceによりＷｉ−Ｆｉ（登録商標）準拠として承認された無線システムを意味する。

したがって、（モバイル端末のアプリケーションプロセッサで）別のＳＩＰスタック及びＬＴＥプロセッサの外部の関連ソフトウェアを重複することなく通常ＬＴＥモデムを通じてＷｉ−Ｆｉ（登録商標）無線へと行くモバイル端末の（ＶｏＩＰ又はＳＭＳｏＩＰ又はVideo over IPのような）リアルタイムＩＰ通信パケットトラフィックをリダイレクトする技術が開示される。ソフトウェアモジュール（又はソフトウェア機能）は、ＳＩＰスタックとＬＴＥモデムとの間に挿入され、通常ＬＴＥモデムを介してＷｉ−Ｆｉ（登録商標）デーモンへ送信される全てのＩＰパケットをプロセッサ間通信（ＩＰＣ）メカニズムを用いてリダイレクトする。Ｗｉ−Ｆｉ（登録商標）デーモンは、Ｗｉ−Ｆｉ（登録商標）サブシステムに接続し、Ｗｉ−Ｆｉ（登録商標）ネットワークとのコネクションを維持し、上述のＩＰトラフィックをＷｉ−Ｆｉ（登録商標）無線ネットワークを介して送信する。ＩＰパケットは、ＬＴＥプロセッサに組み込まれたＳＩＰスタックを用いることにより、Ｗｉ−Ｆｉ（登録商標）を用いて送信されるが、全てのこのようなＳＩＰトラフィックは、ＬＴＥ送信の場合と同様に、認可されたＳＩＰネットワークコネクションを通じて伝送される。

モバイル端末３００のＬＴＥプロセッサ３６０は、レガシモデム制御及びユーザプレーンモジュール３７０、コマンドハンドラ３６５、ＩＳＩ（Internet Service Interface）モジュール３８２、音声エンジンモジュール３８４、ＳＩＰ（Session Initiation Protocol）モジュール３８８、ＯＳＡＬ（Operating System Abstraction Layer）モジュール３８６、制御／状態モジュール（ＣＳＭ）３７５を有する。ＣＳＭ３７５は、無線ポリシマネジャ（ＲＰＭ）３８０を含む。ＶｏＩＰ及びＳＭＳｏＩＰのＷｉ−Ｆｉ（登録商標）を介したオフロードを可能にするために、ＬＴＥプロセッサ３６０がＬＴＥプロセッサ２６０と異なる点は、ＬＴＥプロセッサ３６０が、ｖポートリダイレクタ（ＶＰＲ）３９５及びｖポートモデムデバイス（ＶＰＭＤ）３９０を更に有することである。モバイル端末３００は、ＲＩＬ及びモデムドライバ３０５を更に有し、アプリケーションプロセッサで動作する代替ネットワークインタフェースデーモン３１５及びｖポートアプリケーションデバイス（ＶＰＡＤ）３２０を導入する。ｖポートモデムデバイス（ＶＰＭＤ）３９０及びｖポートアプリケーションデバイス（ＶＰＡＤ）３２０は、プロセッサ間通信（ＩＰＣ）メカニズム３５０として機能的に一緒に考えられても良い。

図３に示した追加された新たなＬＴＥプロセッサソフトウェアモジュール３９０、３９５、３１５、３２０は、Ｗｉ−Ｆｉ（登録商標）オフロードを提供する。

・ｖポートリダイレクタ（ＶＰＲ）３９５は、ネットワークパケットを適正なネットワークインタフェースへ向けるモジュールである。ＳＩＰ、ＲＴＰ、ＲＴＣＰパケットの各々は、ＶＰＲモジュール３９５に渡される。これらのパケットがＬＴＥプロセッサ３６０のネットワークインタフェースに向けられる場合、該パケットは、ＯＳＡＬモジュール３８６へ送信される。これらのパケットがＷｉ−Ｆｉ（登録商標）（又はアプリケーションプロセッサにアクセス可能な他のインタフェース）に向けられる場合、該パケットは、ＶＰＭＤモジュール３９０へ送信される。ＶＰＲ３９５は、ＳＩＰモジュール３８８への仮想ネットワークコネクションとして見えるので、ＳＩＰモジュール３８８は、どの無線インタフェースが用いられているかを知る必要がない。

・ｖポートモデムデバイス（ＤＰＭＤ）３９０。このモジュールは、（ＬＴＥプロセッサにある）ＶＰＲモジュール３９５とアプリケーションプロセッサ３１０にあるＶＰＡＤモジュール３２０との間の通信サービスを提供する。

アプリケーションプロセッサ３１０にある新たなモジュールは次の通りである。

・ｖポートアプリケーションデバイスドライバ（ＶＯＡＤ）３２０は、ＬＴＥプロセッサ３６０のＶＰＭＤモジュール３９０と通信する。

・Ｗｉ−Ｆｉ（登録商標）デーモン３１５。パケットがＷｉ−Ｆｉ（登録商標）インタフェースから受信されると、Ｗｉ−Ｆｉ（登録商標）デーモンは、ＶＰＡＤモジュール３２０にデータを書き込む。ＶＰＡＤモジュール３２０は、ＶＰＭＤモジュール３９０にデータを渡す。ＶＰＭＤモジュール３９０は、ＶＰＲモジュール３９５にデータを渡す。次に、ＶＰＲモジュール３９５は、このデータを、受信したデータの種類に依存してＳＩＰモジュール３８８又は音声エンジン３８４に渡す。同様に、Ｗｉ−Ｆｉ（登録商標）デーモンは、ＶＰＡＤモジュール３２０からのデータを待つ。ＶＰＡＤモジュール３２０からの新しいＳＩＰ又はＲＴＰメッセージは、Ｗｉ−Ｆｉ（登録商標）デーモン３１５に到着すると直ぐにＷｉ−Ｆｉ（登録商標）を介して送信される。

＜Ｗｉ−Ｆｉ（登録商標）デーモン３１５の動作＞
Ｗｉ−Ｆｉ（登録商標）デーモンは、ＬＴＥプロセッサ３６０で動作するモジュールを代表してＷｉ−Ｆｉ（登録商標）ネットワークコネクションを管理する。ＳＩＰモジュール３８８がＷｉ−Ｆｉ（登録商標）インタフェースを用いる必要があるとき、ＳＩＰモジュール３８８は、ＶＰＲモジュール３９５からＷｉ−Ｆｉ（登録商標）コネクションを要求する。ＶＰＲモジュール３９５は、ネットワークコネクションを開設するよう、（ＶＰＭＤ３９０及びＶＰＡＤ３２０のＩＰＣメカニズムを介して）Ｗｉ−Ｆｉ（登録商標）デーモン３１５に連絡する。ＳＩＰモジュール３８８は、ＶＰＲモジュール３９５のコネクションを用いて、ＩＰマルチメディアサブシステム（ＩＭＳ）コアに登録する。登録の完了に成功した後、ＳＩＰモジュール３８８は、ＶｏＩＰ呼及びＳＭＳｏＩＰメッセージを開始又は受信するためにＷｉ−Ｆｉ（登録商標）インタフェースを使用できる。音声エンジン３８４が（例えばＲＴＰ又はＲＴＣＰパケットのために）Ｗｉ−Ｆｉ（登録商標）インタフェースを用いる必要があるとき、音声エンジン３８４は、ＶＰＲモジュール３９５からＷｉ−Ｆｉ（登録商標）コネクションを要求する。

＜使用例：Ｗｉ−Ｆｉ呼の発信＞
Ｗｉ−Ｆｉ（登録商標）呼を開始する前に、Ｗｉ−Ｆｉ（登録商標）無線が、音声呼のために使用する無線になっていなければならない。ＣＳＭモジュール３７５は、ＲＰＭイベントによりＷｉ−Ｆｉ（登録商標）無線に登録するよう命じられる。イベントの後、ＣＳＭモジュール３７５は、Ｗｉ−Ｆｉ（登録商標）を介してサービスプロバイダに登録する。

この例では、Ｗｉ−Ｆｉ（登録商標）アクセスポイントが利用可能であり、アクティブな呼が存在しないとき、ＲＰＭイベントがトリガされる。モバイル端末３００は、サービスプロバイダに登録された後、Ｗｉ−Ｆｉ（登録商標）を介して音声呼を開始することができる。ＶｏＩＰ呼の発信のための動作シーケンスを以下に示す。

１．ユーザが呼を開始するとき、モデムドライバ３０５は、呼を開始するコマンドを受信する。

２．モデムドライバ３０５は、コマンドハンドラ３６５にコマンドを渡す。コマンドハンドラ３６５は、そのコマンドをＣＳＭモジュール３７５に渡す。

３．ＣＳＭモジュール３７５は、ＲＰＭモジュール３８０に問い合わせ、使用すべき正しいネットワークインタフェースを決定する。この場合、Ｗｉ−Ｆｉ（登録商標）ＶｏＩＰが選択される。

４．ＣＳＭモジュール３７５は、Ｗｉ−Ｆｉ（登録商標）を介して呼を開始するよう、（ＩＳＩ３８２を介して）ＳＩＰモジュール３８８に命じる。

５．ＳＩＰモジュール３８８は、ＳＩＰセッションを生成し、パケットをＶＰＲモジュール３９５に渡す。

６．ＶＰＲモジュール３９５は、ＳＩＰセッションがＷｉ−Ｆｉ（登録商標）を介するよう命じられているので、ＶＰＲモジュール３９５は、パケットをＶＰＭＤモジュール３９０に渡す。

７.ＶＰＭＤモジュール３９０は、ＶＰＡＤモジュール３２０までパケットを渡す。

８．Ｗｉ−Ｆｉ（登録商標）デーモン３１５は、ＶＰＡＤモジュール３２０の活動を傾聴する。新しいパケットが利用可能なとき、新しいパケットはＷｉ−Ｆｉ（登録商標）ソケットを介して送信される。

９．ネットワークは、「トライングメッセージ」で応答する。このメッセージは、Ｗｉ−Ｆｉ（登録商標）デーモン３１５／ＶＰＡＤ３２０／ＶＰＭＤ３９０／ＶＰＲ３９５の経路を介して、ＳＩＰモジュール３８８まで戻される。

１０．ＳＩＰモジュール３８８は、ＣＳＭモジュール３７５に新しいメッセージを知らせる。ＣＳＭモジュール３７５は、「トライング」メッセージを受信したというメッセージをコマンドハンドラ３６５へ送信することにより、応答する。

１１．コマンドハンドラ３６５は、メッセージをモデムドライバ３０５に渡す。

１２．ネットワークは、肯定応答を送信する。このメッセージは、Ｗｉ−Ｆｉ（登録商標）デーモン３１５／ＶＰＡＤ３２０／ＶＰＭＤ３９０／ＶＰＲ３９５の経路を介して、ＳＩＰモジュール３８８まで戻される。

１３．ＳＩＰモジュール３８８は、ＣＳＭモジュール３７５に情報を渡す。

１４．固定ポーリング間隔で、モデムドライバ３０５は、全ての呼の状態を要求するＲＩＬ３０５コマンドを受信する。

１５．モデムドライバ３０５は、コマンドハンドラ３６５に要求を送信する。コマンドハンドラ３６５は、そのコマンドをＣＳＭモジュール３７５に渡す。

１６．ＣＳＭモジュール３７５は、呼の現在の状態を返す。

１７．遠端パーティが呼に応答すると、ＳＩＰモジュール３８８は、ネットワークから（Ｗｉ−Ｆｉ（登録商標）デーモンから、ＶＰＲモジュール３９５を介して）、遠端パーティが応答したというメッセージを受信する。

１８．ＳＩＰモジュール３８８は、ＣＳＭモジュール３７５へ新しい状態を送信する。

１９．ＣＳＭモジュール３７５は、音声エンジン３８４に、音声インタフェースとＷｉ−Ｆｉ（登録商標）インタフェースのＲＴＰコネクションとの間で、ＶＰＲ３９５／ＶＰＭＤ３９０／ＶＰＡＤ３２０／Ｗｉ−Ｆｉ（登録商標）デーモン３１５の経路を介して、音声のストリーミングを開始するよう命じる。

２０．次のポーリング間隔で、（コマンドハンドラ３６５を介した）モデムドライバ３０５からの呼状態についての新しい要求に応答して、ＣＳＭモジュール３７５は、呼が応答されたことを報告する。

２１.この「呼が応答された」というメッセージは、コマンドハンドラ３６５に渡され、次にモデムドライバ３０５に渡される。

２２．呼は動作中になる。

当業者は、上述のＷｉ−Ｆｉ（登録商標）上の発信呼のオフロードについての記載が、Ｗｉ−Ｆｉ（登録商標）デーモンを他の形式の代替ネットワークインタフェースデーモンにより置換することにより、及び任意の必要なハードウェア変更を含めることにより、別の形式の代替ネットワークインタフェース上の発信呼のオフロードに容易に変更できることを直ちに理解する。

＜使用例：Ｗｉ−Ｆｉ呼の着信＞
Ｗｉ−Ｆｉ呼を受信する前に、装置は、Ｗｉ−Ｆｉ（登録商標）無線を介してサービスプロバイダに登録されなければならない。前述の使用例は、これがどのように生じ得るかのシナリオを提供した。

装置がＷｉ−Ｆｉ（登録商標）を介して登録された場合の、ＶｏＩＰ着信呼のための動作シーケンスを以下に示す。

１．Ｗｉ−Ｆｉ（登録商標）デーモン３１５は、メッセージについて適切なネットワークソケットを傾聴する。

２．Ｗｉ−Ｆｉ（登録商標）デーモン３１５は、Ｗｉ−Ｆｉ（登録商標）を介して呼の要求を受けると、新しいＶｏＩＰセッションへの招待を受信する。

３．Ｗｉ−Ｆｉ（登録商標）デーモン３１５は、この招待を、ＶＰＡＤ３２０／ＶＰＭＤ３９０／ＶＰＲ３９５の経路を介して、ＳＩＰモジュール３８８へ送信する。

４．ＳＩＰモジュール３８８は、この要求を受信し、（ＩＳＩモジュール３８２を介して）ＣＳＭモジュール３７５へメッセージを送信する。

５．ＣＳＭモジュール３７５は、コマンドハンドラ３６５を介してモデムドライバ３０５に新しい呼の要求を送信する。

６．ＣＳＭモジュール３７５は、ＳＩＰモジュール３８８に、ネットワークへの要求の受信に対する肯定応答送信するよう命じる。この要求は、ＶＰＲモジュール３９５により、Ｗｉ−Ｆｉ（登録商標）デーモン３１５へ転送される。

７．ネットワークは、メッセージが受信されたことの肯定応答を送信する。このメッセージは、Ｗｉ−Ｆｉ（登録商標）デーモン３１５により受信され、ＶＰＡＤ３２０／ＶＰＭＤ３９０／ＶＰＲ３９５の経路を用いて、ＳＩＰモジュール３８８まで転送される。

８．固定ポーリング間隔で、モデムドライバ３０５は、全ての呼の状態を要求するコマンドを受信する。

９．モデムドライバ３０５は、コマンドハンドラ３６５にコマンドを送信する。コマンドハンドラ３６５は、そのコマンドをＣＳＭモジュール３７５に渡す。

１０．ＣＳＭモジュール３７５は、呼の現在の状態を返す。

１１．ユーザが呼に応答するとき、ダイヤラアプリケーション１２０は、呼に応答するよう、コマンドをモデムドライバ３０５へ送信する。

１２．モデムドライバ３０５は、コマンドハンドラ３６５にコマンドを渡す。コマンドハンドラ３６５は、そのコマンドをＣＳＭモジュール３７５に渡す。

１３．ＣＳＭモジュール３７５は、呼を受け付けるよう、ＳＩＰモジュール３８８に命じる。

１４．ＳＩＰモジュール３８８は、ネットワークに呼が応答されたことを知らせる。これは、ＶＰＲモジュール３９５にメッセージを送信することにより行われる。このメッセージは、ＶＰＭＤ３９０／ＶＰＡＤ３２０へ転送され、最終的にはＷｉ−Ｆｉ（登録商標）デーモン３１５を用いてネットワークへ転送される。

１５．ＣＳＭモジュール３７５は、音声エンジン３８４に、音声インタフェースとＷｉ−Ｆｉ（登録商標）インタフェースのＲＴＰコネクションとの間で、ＶＰＲ３９５／ＶＰＭＤ３９０／ＶＰＡＤ３２０／Ｗｉ−Ｆｉ（登録商標）デーモン３１５の経路を介して、音声のストリーミングを開始するよう命じる。

１６．ネットワークは、呼が受け付けられたという肯定応答で応答する。

１７．呼は動作中になる。

１８．ＣＳＭモジュール３７５は、次のポーリング間隔で新しい状態を報告する。

当業者は、上述のＷｉ−Ｆｉ（登録商標）上の呼の受信についての記載が、Ｗｉ−Ｆｉ（登録商標）デーモンを他の形式の代替ネットワークインタフェースデーモンにより置換することにより、及び任意の必要なハードウェア変更を含めることにより、別の形式の代替ネットワークインタフェース上の呼の受信に容易に変更できることを直ちに理解する。

＜ビデオ呼の追加＞
モバイル端末にビデオ呼を追加するために、先ず、ビデオエンジンが追加されなければならない。ビデオコーデックのハードウェアの高速化は、通常、アプリケーションプロセッサにより制御されるハードウェアサブシステムとして提供される。ビデオ呼はアプリケーションプロセッサＣＰＵ上で動作するソフトウェアでも実装できるが、省電力及び費用効率は、ビデオ処理のための別個のハードウェアアクセラレータを用いることを要求する。ＬＴＥプロセッサハードウェアのメモリ及びＣＰＵが限られているので、ビデオコーデックはＬＴＥプロセッサに含まれない。このようなプロセッサは、ドングル又は低コスト電話機のような、ビデオ処理を必要としない種々のアプリケーションで用いられ得るので、コストについて非常に最適化されている。

ビデオ呼機能を提供する際の最初の課題は、ビデオ呼を開始及び管理するための（ビデオダイアラのような）ビデオアプリケーションのためのアプローチである。標準的なＡＴコマンドは、ビデオ呼の静止、アクティブな音声呼へのビデオの追加、呼のビデオ部分の終了、及びビデオ呼の状態報告のような機能を提供しない。ＡＴコマンドセットは、開示のソフトウェアアーキテクチャの下で、これらの機能を提供するために拡張できる。しかしながら、産業界はＡＴコマンドセットから離れつつあるので、このアプローチは望ましくない。多くのモデムチッププロバイダは、現在、ＲＩＬインタフェースの下で独自インタフェースを提案している。開示の設計で取られるアプローチは、ビデオ呼のために必要なデータを制御し、管理し及び通過させるための方法を提供するために、Ｗｉ−Ｆｉ（登録商標）オフロードアーキテクチャを利用することである。

モバイル端末にビデオ呼を追加する際の第２の課題は、音声エンジンを追加する際のオーバヘッド及び制約を最小限に抑えることである。これは、ビデオエンジンが、ビデオアプリケーションソフトウェアの内部に置かれ実行されることを必要とする。これは、ビデオエンジンが、承認の問題及び追加オーバヘッドを有しないで、スクリーンの所望の部分にアクセスできるようにする。

したがって、ビデオコーデック機能を実行するプロセッサにより生成され消費されるビデオパケットをＬＴＥプロセッサへリダイレクトし、（モデムによりサポートされるベアラチャネルを利用して）ビデオパケットがＬＴＥモデムを介して伝送され得るようにする技術が開示される。標準的なＬＴＥプロセッサは、限られたＣＰＵ及びメモリハードウェアしか有しないので、ビデオコーデック機能を実行できない。したがって、ビデオコーデック機能は、付属のアプリケーションプロセッサに実装されなければならない。ビデオパケットをＬＴＥモデムを介してＬＴＥベアラチャネルで伝送させるために、アプリケーションプロセッサで動作するビデオエンジンは、ビデオパケットをＬＴＥモデムへ送信し／から受信する。（アプリケーションプロセッサの）ビデオエンジンとＬＴＥプロセッサとの間のビデオデータフローは、プロセッサ間通信（ＩＰＣ）メカニズムにより処理される。ＬＴＥプロセッサのネットワークパケットリダイレクタモジュールは、ＬＴＥモデム制御機能を用いてベアラチャネルへのアクセスを開く。そして、データが、ビデオエンジンとビデオリダイレクタモジュールとの間でＩＰＣメカニズムを用いて交換される。他の代替ネットワークインタフェース選択肢が存在する場合、アプリケーションプロセッサにあるビデオパケットリダイレクタモジュールは、ビデオデータを、ＬＴＥモデムの代わりに、Ｗｉ−Ｆｉ（登録商標）のような該代替ネットワークインタフェースへリダイレクトする必要がある。ＬＴＥプロセッサ内の制御モジュールは、ビデオデータ及び制御パケットにより用いられるべきネットワークインタフェースの選択を担う。ビデオパケットリダイレクタモジュールを通じて全てのパケットを転送することにより、ビデオトラフィックのための適正なネットワークインタフェースが制御できる。Ｗｉ−Ｆｉ（登録商標）チャネルを介して送信されるビデオパケットは、ビデオパケットリダイレクタモジュールによりＷｉ−Ｆｉ（登録商標）デーモンへリダイレクトされる。このパケットの再転送の方法は、Ｗｉ−Ｆｉ（登録商標）呼の間、音声エンジンと（ＬＴＥプロセッサにある）ネットワークパケットリダイレクタモジュールとの間でパケットを直接交換し次にネットワークパケットリダイレクタモジュールにビデオパケットを（アプリケーションプロセッサにある）Ｗｉ−Ｆｉ（登録商標）デーモンへ返送させるより効率的である。

モバイル端末上のアプリケーションプロセッサのビデオデータを（ＶｏＩＰ又はＶｏＬＴＥに使用可能な）ＬＴＥプロセッサの音声データと同期させる技術も開示される。音声及びビデオパケットを同期させるために、音声エンジンとビデオエンジンとの間で情報が交換されなければならない。音声エンジンとビデオエンジンは、論理的にビデオエンジンと音声エンジンとの間に置かれたプロセッサ間通信（ＩＰＣ）メカニズムを用いて、情報（例えば、パケットが現在聴かれている又は表示されている絶対時間）を交換する。このアプローチは、音声及びビデオエンジンに、それら個々のデコードレートを管理させ、音声及びビデオが同期されるようにする。

図４を参照する。モバイル端末４００のＬＴＥプロセッサ４６０は、レガシモデム制御及びユーザプレーンモジュール４７０、コマンドハンドラ４６５、ＩＳＩ（Internet Service Interface）モジュール４８２、音声エンジンモジュール４８４、ＳＩＰ（Session Initiation Protocol）モジュール４８８、ＯＳＡＬ（Operating System Abstraction Layer）モジュール４８６、ｖポートリダイレクタ（ＶＰＲ）４９５、ｖポートモデムデバイス（ＶＰＭＤ）４９０、制御／状態モジュール（ＣＳＭ）４７５を有する。ＣＳＭモジュール４７５は、無線ポリシマネジャ（ＲＰＭ）４８０を含む。

ビデオ呼を追加するために、モバイル端末４００はモバイル端末３００と異なり、モバイル端末４００のアプリケーションプロセッサ４１０は、ビデオエンジン４３０、ビデオパケットリダイレクタ４４０及び制御／状態インタフェース（ＣＳＩ）４３５を含むビデオアプリケーション４２５を更に有する。モバイル端末４００は、アプリケーションプロセッサで動作するＲＩＬ及びモデムドライバ４０５、Ｗｉ−Ｆｉ（登録商標）デーモン４１５及びｖポートアプリケーションデバイス（ＶＰＡＤ）４２０を更に有する。ｖポートモデムデバイス（ＶＰＭＤ）４９０及びｖポートアプリケーションデバイス（ＶＰＡＤ）４２０は、プロセッサ間通信（ＩＰＣ）メカニズム４５０として機能的に一緒に考えられても良い。

図３に示したビデオ呼のサポートを追加するために追加された新たなアプリケーションプロセッサ４１０のソフトウェアモジュール４２５、４３０、４４０は、次の通りである。

・ＣＳＩモジュール４３５は、ビデオ呼を生成し制御するためにビデオアプリケーション４２５により必要とされるサービスを提供する。

・ビデオエンジン４３０は、ビデオアプリケーション４２５と処理を共有する。ビデオエンジン４３０は、ビデオストリームの符号化及び復号化を担う。さらに、ビデオエンジン４３０は、ジッタバッファを含む。

ＣＳＩモジュール４３５及びビデオエンジン４３０の両者は、ＶＰＡＤモジュール４２０を介してＶＰＭＤモジュール４９０と通信する。この通信経路は、ＣＳＭモジュール４７５に、ＣＳＩモジュール４３５及びビデオエンジン４３０により提供されるビデオ呼機能を制御させ、ビデオ機能が（ＣＳＭモジュール４７５により制御される）音声機能と協調できるようにする。さらに、このアーキテクチャは、ビデオデータをＬＴＥプロセッサ４６０と交換させ、ビデオベアラチャネルに配置され得るようにする。

・ビデオパケットリダイレクタモジュール４４０は、ビデオデータを、モバイルネットワーク（若しくはベアラチャネル）を介して伝送させ、又はＷｉ−Ｆｉ（登録商標）に配置させる。これは、ビデオデータをＷｉ−Ｆｉ（登録商標）を介してより効率的に伝送させ、また、ビデオデータを同じビデオ呼の中で音声データと異なるネットワークを介して伝送できるようにする。

＜使用例：ＬＴＥを介した標準的なビデオ呼＞
ビデオ呼と音声呼との間の主な相違は、コマンドがビデオ呼をサポートするために拡張されていない限り、コマンドがモデムドライバから来ないことである。ビデオ呼の確立のための動作シーケンスを以下に示す。

１．ユーザは、（ビデオアプリケーション４２５内部で）ビデオ呼を開始する。

２．ビデオアプリケーション４２５は、ビデオ呼を生成するためにＣＳＩモジュール４３５と相互作用する。さらに、ビデオアプリケーション４２５は、ビデオエンジン４３０を起動する。

３．ＣＳＩモジュール４３５は、呼を開始するために、ＶＰＡＤモジュール４２０及びＶＰＭＤモジュール４９０を介してＣＳＭモジュール４７５へコマンドを送信する。

４．ＣＳＭモジュール４７５は、ビデオ呼を確立するために、（ＩＳＩ４８２を介して）ＳＩＰモジュール４８８へ必要なコマンドを送信する。

５．次に、ＣＳＭモジュール４７５は、ＶＰＭＤ４９０／ＶＰＡＤ４２０経路を介してＣＳＩモジュール４３５へ進捗を報告する。

６.呼が応答されると、ＣＳＭモジュール４７５は、状態更新を（ＳＩＰモジュール４８８から）ＣＳＩモジュール４３５へ送信する。さらに、ＣＳＭモジュール４７５は、音声及びビデオストリームを開始する。音声ストリームはＬＴＥプロセッサ４６０内に留まる。ＶＰＲモジュール４９５は、音声エンジン４３０とＬＴＥベアラチャネルとの間でパケットを転送するために用いられる。以下の動作は、ビデオストリームを開始するために必要である。

ａ）音声エンジン４８４内に、ビデオエンジン４３０を起動するためにコマンドを送信する制御コードがある。このコマンドは、ＶＰＭＤモジュール４９０及びＶＰＡＤモジュール４２０を介して、ビデオエンジン４３０に渡される。（上述のステップ２で）ビデオエンジン４３０がビデオアプリケーション４２５により起動されたときから、ビデオエンジン４３０は、ＶＰＡＤモジュール４２０からのこのようなコマンドを傾聴している。

ｂ）ビデオエンジン４３０がＶＰＡＤモジュール４２０から開始コマンドを受信すると、ビデオエンジン４３０は、ビデオパケットを送信し始める。

ｃ）ビデオパケットは、ＶＰＡＤ４２０／ＶＰＭＤ４９０を介して、ＶＰＲモジュール４９５へ送信される。次に、ＶＰＲモジュール４９５は、パケットを、適切なビデオベアラチャネルへ転送する。

ｄ）ＶＰＲモジュール４９５が（適切なベアラチャネルから）ビデオパケットを受信すると、ＶＰＲモジュール４９５は、該ビデオパケットを、ＶＰＭＤ４９０／ＶＰＡＤ４２０を介して、ビデオエンジン４３０へ送信する。

７．呼は動作中になる。

＜使用例：ビデオパケットリダイレクタによるＷｉ−Ｆｉビデオ呼＞
Ｗｉ−Ｆｉ（登録商標）を介したビデオ呼の音声機能は、上述のＷｉ−Ｆｉ（登録商標）を介したＶｏＩＰ呼と非常に似た動作をする。しかしながら、（前述の使用例で記載した）ＬＴＥネットワークを介したビデオ呼のためにモバイル端末内の同じデータ経路を用いることにより、Ｗｉ−Ｆｉ（登録商標）デーモン４１５により受信されたビデオデータは、ＬＴＥプロセッサ内のＶＰＲモジュール４９５まで渡され、次にＶＰＲモジュール４９５からビデオエンジン４３０へ（ＶＰＭＤ４９０／ＶＰＡＤ４２０を介して）再転送され戻されなければならない。同様に、全ての送出ビデオパケットは、ビデオエンジン４３０から、ＬＴＥプロセッサ４６０内のＶＰＲモジュール４９５まで送信され、次に、ＶＰＭＤ４９０／ＶＰＡＤ４２０を介してＷｉ−Ｆｉ（登録商標）デーモンまで戻されなければならない。ＬＴＥプロセッサ４６０を通じてビデオデータを転送する処理は、非常に効率が悪い。この非効率を軽減するために、音声パケットリダイレクタ４４０が導入される。

ビデオパケットリダイレクタ４４０により、音声及びビデオデータの転送が、異なるネットワーク（無線）インタフェースに分割され得る。例えば、音声データをＬＴＥ音声ベアラチャネルを介して送信し、同時にビデオをＷｉ−Ｆｉ（登録商標）ネットワークにオフロードすることが可能である。

モバイル端末４００がＷｉ−Ｆｉ（登録商標）を介してサービスプロバイダに登録された後、モバイル端末４００は、Ｗｉ−Ｆｉ（登録商標）を介して呼を送信し及び受信する準備が整う。Ｗｉ−Ｆｉ（登録商標）を介したビデオ呼の確立のために必要な動作シーケンスを以下に示す。

１．ユーザはビデオ呼を開始する。

２．ビデオアプリケーション４２５は、ビデオ呼を生成するためにＣＳＩモジュール４３５と相互作用し、ビデオエンジン４３０を起動する。

３．ＣＳＩモジュール４３５は、呼を開始するために、ＶＰＡＤモジュール４２０及びＶＰＭＤモジュール４９０を介してＣＳＭモジュール４７５へコマンドを送信する。

４．ＣＳＭモジュール４７５は、ビデオ呼を確立するために、ＳＩＰモジュール４８８へ必要なＳＩＰコマンドを送信する。

５．４のＳＩＰコマンドは、ＶＰＲモジュール４９５により、ＶＰＭＤモジュール４９０及びＶＰＡＤモジュール４２０を介してＷｉ−Ｆｉ（登録商標）デーモン４１５へリダイレクトされる。

６．ＩＭＳコアからのＳＩＰイベントがＷｉ−Ｆｉ（登録商標）デーモン４１５により受信されると、これらのＳＩＰイベントは、ＶＰＡＤ４２０／ＶＰＭＤ４９０／ＶＰＲ４９５の経路を介して、ＳＩＰモジュール４８８へ転送される。

７．ＣＳＭモジュール４７５は、ＶＰＭＤモジュール４９０及びＶＰＡＤモジュール４２０介してＣＳＩモジュール４３５へビデオ呼の進捗を報告する。

８.呼が応答されると、ＣＳＭモジュール４７５は、状態更新をＣＳＩモジュール４３５へ送信する。さらに、ＣＳＭモジュール４７５は、音声及びビデオストリームを開始する。Ｗｉ−Ｆｉ（登録商標）デーモンは、音声及びビデオストリームの両方がＷｉ−Ｆｉ（登録商標）を介して伝送されるように特定のネットワークソケットが開かれなければならないことを通知される。

９．以下の動作は、音声ストリームを確立する。

ａ）音声エンジン４８４が送信するために音声パケットを生成すると、音声エンジン４８４は、該パケットを、ＶＰＭＤモジュール４９０、ＶＰＡＤ４モジュール２０及びＶＰＲモジュール４９５を介して、Ｗｉ−Ｆｉ（登録商標）デーモンへ送信する。

ｂ）Ｗｉ−Ｆｉ（登録商標）デーモン４１５が音声パケットを受信すると、Ｗｉ−Ｆｉ（登録商標）デーモン４１５は、該音声パケットを、ＶＰＡＤ４２０／ＶＰＭＤ４９０／ＶＰＲ４９５の経路を介して、音声エンジン４８４へ送信する。

１０．以下の動作は、ビデオストリームを確立する。

ａ）音声エンジン４８４は、ストリーミングを開始するためにビデオエンジン４３０へコマンドを送信する。このコマンドは、ＶＰＭＤモジュール４９０及びＶＰＡＤモジュール４２０を介して、ビデオエンジン４３０に渡される。（上述のステップ２で）ビデオエンジン４３０がビデオアプリケーション４２５により起動されたときから、ビデオエンジン４３０は、このようなコマンドを傾聴している。

b.ｂ）ビデオエンジン４３０がＶＰＡＤモジュール４２０からストリーミングを開始するコマンドを受信すると、ビデオエンジン４３０は、ビデオパケットを送信し始める。

ｃ）送出ビデオパケットは、音声パケットリダイレクタ４４０へ送信される。呼はＷｉ−Ｆｉ（登録商標）インタフェースを用いるので、ビデオパケットリダイレクタ４４０は、パケットをＷｉ−Ｆｉ（登録商標）デーモン４１５へ送信する。（ＬＴＥを介して呼が終了した場合、ビデオパケットは、ＶＰＡＤ４２０／ＶＰＭＤ４９０の経路を介して、ＶＰＲモジュール４９５へ転送される。）
ｄ）Ｗｉ−Ｆｉ（登録商標）デーモン４１５が到来ビデオパケットを受信すると、Ｗｉ−Ｆｉ（登録商標）デーモン４１５は、該音声パケットを、ビデオパケットリダイレクタ４４０を介して、ビデオエンジン４３０へ送信する。

１１．呼は動作中になる。

当業者は、上述のＷｉ−Ｆｉ（登録商標）上のビデオ呼の確立についての記載が、Ｗｉ−Ｆｉ（登録商標）デーモンを他の形式の代替ネットワークインタフェースデーモンにより置換することにより、及び任意の必要なハードウェア変更を含めることにより、別の形式の代替ネットワークインタフェースを用いたビデオ呼の確立に容易に変更できることを直ちに理解する。

＜ＩＭ及び他のＲＣＳ機能の追加＞
（二重登録問題）
モバイル装置でＲＣＳ（Rich Communications Services）を提供する際の良く知られた１つの問題は、二重登録問題である。ユーザが複数のＲＣＳアプリケーションをモバイル装置にダウンロードする場合、各アプリケーションは、自身のＩＭＳ（IP Multimedia Subsystem）スタックを有する。各スタックは、ＲＣＳ機能へのアクセスを得るために、ＩＭＳコアに登録しなければならない。ＩＭＳコアは、モバイル装置毎に１つのみ登録を許可するよう構成される。第２のアプリケーションがサービスプロバイダに登録しようとすると、二重登録問題が生じる。各サービスプロバイダ（及びそのＩＭＳコア）はこの状況を異なる方法で処理するので、ユーザは、一方、他方又は両方のアプリケーションが機能しなくなるのが分かるだろう。

この問題は、装置がＶｏＬＴＥのために利用可能なＬＴＥプロセッサを有するとき、特に顕著である。ＬＴＥプロセッサは、起動のときに、サービスプロバイダ（及びそのＩＭＳコア）に登録しようとする。これは、任意の他のアプリケーションが登録するための機会を得る前に生じる。標準的なＬＴＥプロセッサは完全なＲＣＳ機能を提供しないので、追加アプリケーションは、不足しているＲＣＳ機能にアクセスすることを必ず要求される。そして、これらのアプリケーションは、ＩＭＳコアに登録することができない。

二重登録問題を生じる別の要因は、標準的なＬＴＥプロセッサ上の利用可能なメモリ及びＣＰＵリソースが限られていることである。メモリ空間の不足は、同時にＬＴＥプロセッサで実施できるＳＩＰセッションの数を制限する。ＭＳＲＰ（Message Session Relay Protocol）を用いるＳＩＰセッションは、特にメモリの影響を受け易い。このようなメモリの影響を受け易い機能は、非常に大きなメモリ空間が利用可能なアプリケーションプロセッサで実施される必要がある。このようなセッションの例は、ＩＭ及びファイル転送のようなＲＣＳ機能である。多数のＳＩＰセッションを可能にし、メモリの影響を受け易いＳＩＰセッションをモバイル装置で実施させることを可能にするために、アプリケーションプロセッサにプロトコルアクセラレータを追加する技術が開示される。しかしながら、第２のＳＩＰスタック（プロトコルアクセラレータ）がアプリケーションプロセッサで実施されるとき、上述の二重登録問題が生じる。

モバイル装置上のＲＣＳ機能が、ＳＩＰプロトコル機能がＬＴＥプロセッサ内に埋め込まれたＳＩＰスタックの外部で実行されることを要求するとき、二重問題を回避する技術が開示される。この問題を回避するために、全てのＳＩＰプロトコル動作（例えば、音声、ＳＭＳ、ＩＭ、等）は、同じ認可ＳＩＰコネクションを共有しなければならない。これは、（モバイル装置内の任意のＳＩＰスタックからの）全てのＳＩＰパケットを、単一のＳＩＰコネクションを維持するネットワークパケットリダイレクタモジュールを通じて、ＩＭＳコアへ転送することにより達成できる。ネットワークパケットリダイレクタは、ＩＭＳコアから到来するパケットを、要求に応じてモバイル装置内の所望のＳＩＰスタックへ適正に転送する。

ＲＣＳパケットは、ＲＣＳ機能及びＳＩＰサブシステムを埋め込まれたＬＴＥプロセッサ（つまり、ＶｏＬＴＥを備えたＬＴＥプロセッサ）を有するモバイル装置内で、Ｗｉ−Ｆｉ（登録商標）ネットワークにオフロードされる必要があり得る。ＲＣＳパケットがＷｉ−Ｆｉ（登録商標）（又はＬＴＥ無線に加えて任意の代替ネットワークインタフェース）を介して送信されるとき、ネットワークパケットリダイレクタモジュールは、データをアプリケーションプロセッサにあるＷｉ−Ｆｉ（登録商標）デーモンへ（プロセッサ間通信（ＩＰＣ）メカニズムを介して）再転送し、それらのデータがＷｉ−Ｆｉ（登録商標）を介して送信されるとともに、同じ認可ＳＩＰコネクションを維持できるようにする。上述のようにＳＩＰプロトコルデータをＬＴＥプロセッサにあるネットワークパケットリダイレクタモジュールへ再転送する代わりに、全てのＳＩＰメッセージは、図６に示されるプロトコルアクセラレータを用いてアプリケーションプロセッサで処理できる。したがって、全てのＲＣＳパケットは、Ｗｉ−Ｆｉ（登録商標）でＷｉ−Ｆｉ（登録商標）デーモンを介して送信されるので、余分なデータをＬＴＥプロセッサと交換することを回避する。

モバイル装置でＲＣＳアプリケーションを可能にするため、及び上述の問題を解決するために、図５に示すように以下のアーキテクチャが用いられる。

モバイル端末５００のＬＴＥプロセッサ５６０は、レガシモデム制御及びユーザプレーンモジュール５７０、コマンドハンドラ５６５、ＩＳＩ（Internet Service Interface）モジュール５８２、音声エンジンモジュール５８４、ＳＩＰ（Session Initiation Protocol）モジュール５８８、ＯＳＡＬ（Operating System Abstraction Layer）モジュール５８６、拡張ｖポートリダイレクタ（ＶＰＲ）５９５、ｖポートモデム装置（ＶＰＭＤ）５９０、制御／状態モジュール（ＣＳＭ）５７５を有する。ＣＳＭ５７５は、無線ポリシマネジャ（ＲＰＭ）５８０を含む。

モバイル端末５００のアプリケーションプロセッサ５１０は、ビデオエンジン５３０、ビデオパケットリダイレクタ５４０、ＲＩＬ及びモデムドライバ５０５、Ｗｉ−Ｆｉ（登録商標）デーモン５１５及びｖポートアプリケーションデバイス（ＶＰＡＤ）５２０を含むビデオアプリケーション５２５を有する。モバイル端末５００は、モバイル端末４００と異なり、モバイル端末５００は、拡張制御／状態インタフェース（ＣＳＩ）５３５、プロトコルアクセラレータモジュール５４２、及びビデオ呼を含むＲＣＳアプリケーション５２７、並びに拡張ＶＰＲモジュール５９５も含む。ｖポートモデムデバイス（ＶＰＭＤ）５９０及びｖポートアプリケーションデバイス（ＶＰＡＤ）５２０は、プロセッサ間通信（ＩＰＣ）メカニズム５５０として機能的に一緒に考えられても良い。

ＲＣＳ機能のサポートは、アーキテクチャを大幅に変更しないが、幾つかのソフトウェアモジュールが変更される。

・ＣＳＩモジュール５３５は、ＩＭ、コンテンツ共有、ファイル転送、等を提供するために変更される。これらの新しい機能のためのメッセージは、ＣＳＭモジュール５７５に渡される。データ経路は、変更されない。したがって、ＲＣＳアプリケーションは、ＬＴＥプロセッサ内の同じＶｏＩＰ及びＳＭＳｏＩＰソフトウェアモジュールを使い続ける。

・プロトコルアクセラレータモジュ―ル５４２。ＩＭ又はファイル転送のようなアプリケーションのためのメモリ及びＣＰＵ問題を解決するために、特定のプロトコル機能は、アプリケーションプロセッサにシフトされる必要がある。１つのアプローチは、ＭＳＲＰ（Message Session Relay Protocol）プロトコル（ＩＭメッセージング及びファイル転送のために用いられるプロトコル）をアプリケーションプロセッサに移動させることである。別のアプローチは、ＭＲＳＰに加えて、アプリケーションプロセッサ上に第２のＳＩＰスタックを生成することである。この第２のアプローチは、ＬＴＥプロセッサにあるメモリが許容するより多数のＳＩＰセッションを許容するという利点を有する。オフロードに対応するために設計に追加される新しいモジュールは、図５に示すプロトコルアクセラレータ５４２である。プロトコルアクセラレータモジュール５４２は、ＩＳＩパックプレーン５８２に付随し、ＣＳＭモジュール５７５には、ＩＭ、ファイル転送、等をサポートする別個のプロトコルエンジンのように見える。

・ＶＰＲ５９５。上述のように、ＶＰＲモジュール５９５は、音声、並びにビデオ及びＳＭＳプロトコルメッセージを、ＬＴＥプロセッサ５６０にあるＳＩＰエンジン５８８へ転送する。ＶＰＲモジュール５９５は、ポリシ並びにアプリケーションプロセッサ及びＬＴＥプロセッサにあるメモリの利用可能性に従って、ＳＩＰパケットをＬＴＥプロセッサにあるＳＩＰエンジン５８５又はアプリケーションプロセッサにあるプロトコルアクセラレータ５２０へ転送するように更新される。あるこのようなポリシは、全ての音声及びＳＭＳ ＳＩＰメッセージを、ＬＴＥプロセッサにあるＳＩＰエンジンへ転送し、全ての残りのメッセージ（音声、ビデオ又はＳＭＳトランザクションに関係ないメッセージ）をプロトコルアクセラレータモジュ―ル５４２へ転送することである。全てのＳＩＰメッセージをＶＰＲモジュール５９５を通じて転送することにより、全てのＳＩＰメッセージは（ＳＩＰエンジン５８８又はプロトコルアクセラレータ５２０を用いるかに拘わらず）、同じ認可ＳＩＰコネクションを用いる。

（ＶＰＲの動作）
モバイル端末がネットワークに基づくリアルタイム通信サービスを提供するために、モバイル端末５００にあるＳＩＰユーザエージェントは、ＩＭＳコアに登録しなければならない。ＳＩＰモジュール５８８がネットワークへのコネクションを直接開く代わりに、ＳＩＰモジュール５８８は、ＶＰＲモジュール５９５にネットワークへのコネクションを開くよう依頼することにより、コネクションを開く。ＳＩＰモジュール５８８は、このＶＰＲモジュール５９５コネクションを用いてＩＭＳコアに登録する。このＶＰＲモジュール５９５コネクションがＩＭＳコアに登録されると、ＶＰＲモジュール５９５は、（プロトコルアクセラレータ５４２内にあるような）システム内の他のＳＩＰモジュールがＩＭＳコアへのこのコネクションを使えるようにする。

複数のＳＩＰモジュールにメッセージをＩＭＳコアへ送信させることに加えて、ＶＰＲモジュール５９５は、ＩＭＳコアから適正なＳＩＰスタックへパケットを転送する必要がある。ＶＰＲモジュール５９５は、入来するパケットを調べることにより、これを行う。ＶＰＲモジュール５９５は、入来するパケットを処理するために異なるポリシをサポートするよう書かれ得る。図５に示したアーキテクチャのための標準的なポリシは、ＶＰＲモジュール５９５に、音声及びビデオ呼セッションに関連するＳＩＰパケットをＳＩＰモジュール５８８へ転送させ、全ての他のパケットをプロトコルアクセラレータモジュール５４２へ転送させることである。

このポリシの使用は、入来するＩＭパケットがプロトコルアクセラレータモジュール５４２へ転送され、その間、入来するビデオ呼がＳＩＰモジュール５８８へ転送されることを意味する。

ＶＰＲモジュール５９５は、音声及びビデオ呼をサポートするためのメモリ及びＣＰＵリソースのみを有するＬＴＥプロセッサを備えたモバイル端末が、二重登録問題に出くわすことなく、（プロトコルアクセラレータ５４２内にあるような）第２のＳＩＰスタックを用いて他のＲＣＳ機能をサポートすることを可能にする。

＜使用例：ＬＴＥを介したＩＭ＞
ＲＣＳ ＩＭ（インスタントメッセージング）は、メッセージを送信及び受信するために、ＳＩＰ及びＭＳＲＰプロトコルの両方を必要とする。以下に、あるユーザから別のユーザへＬＴＥを介してメッセージを送信するために必要な動作を示す。

１．モバイル端末５００は、（サービスプロバイダの）ＩＭＳコアにより認証され、ＩＭメッセージを送信及び受信する準備が整う。この認証は、ＶＰＲモジュール５９５を介してＳＩＰモジュール５８８により、ＬＴＥ無線ネットワーク上で実行される。

２．ユーザがメッセージを送信しようとすると、モバイル端末５００にあるＲＣＳアプリケーション５２７は、ＣＳＩモジュール５３５に接続処理を開始するよう命じる。

３．ＣＳＩモジュール５３５は、メッセージセッションへの招待を送信することにより、遠隔パーティとのＳＩＰメッセージングセッションを開始するために、（ＶＰＡＤ５２０／ＶＰＭＤ５９０の経路を介して）ＣＳＭモジュール５７５に連絡する。招待は、第１のＩＭメッセージも含む。

４．ＣＳＭモジュール５７５は、ＲＰＭモジュール５８０を調べ、メッセージがＬＴＥを介して送信されるべきであることを知る。

５．ＳＩＰセッションはメッセージングのためなので、ＣＳＭモジュール５７５は、ＬＴＥを介して新しいＳＩＰセッションを開始するために、（ＶＰＭＤ５９０／ＶＰＡＤ５２０の経路を介して）プロトコルアクセラレータモジュール５４２に連絡する。

６．プロトコルアクセラレータモジュール５４２は、ＳＩＰ招待メッセージを生成し、ＶＰＡＤ５２０／ＶＰＭＤ５９０の経路を介して、ＶＰＲモジュール５９５へ送信する。

７．ＶＰＲモジュール５９５は、該ＳＩＰ招待メッセージをＬＴＥネットワークへ送信する。ＶＰＲモジュール５９５を用いることにより、ＳＩＰメッセージは、上述のステップ１でＳＩＰモジュール５８８により既に設定されている、ＩＭＳコアへの認可されたＳＩＰコネクションを共有できる。

８．ＩＭＳコアは、招待に対する応答（この場合には承諾）を送信する。ＶＰＲモジュール５９５は、これはステップ６で開始された同じメッセージセッションの一部であると決定し、該応答を処理のためにプロトコルアクセラレータモジュール５４２まで渡す。

９．プロトコルアクセラレータモジュール５４２は、ＣＳＭモジュール５７５に、招待が承諾されたことを知らせる。

１０.ＣＳＭモジュール５７５は、承諾通知をＣＳＩモジュール５３５に渡す。ＣＳＩモジュール５３５は、ＣＳＭモジュール５７５に肯定応答を送信するよう命じることにより応答する。

１１．ＣＳＭモジュール５７５は、承諾の受信に対して肯定応答するようプロトコルアクセラレータモジュール５４２に命じる。

１２．プロトコルアクセラレータモジュール５４２は、肯定応答メッセージをＩＭＳコアへＶＰＲモジュール５９５を介して送信する。

１３．ＩＭセッションは動作中になる。ＣＳＩモジュール５３５は、肯定応答メッセージにＩＭメッセージ（本体）を続ける。

１４．この新しいメッセージは、ＣＳＭモジュール５７５に渡される。

１５．ＣＳＭモジュール５７５は、プロトコルアクセラレータモジュール５４２へＩＭメッセージを送信する。

１６．プロトコルアクセラレータモジュール５４２は、ＩＭメッセージを、（ＶＰＡＤ／ＶＰＭＤ ＩＰＣメカニズムを用いて）ＶＰＲモジュール５９５を介してＭＳＲＰを用いてＬＴＥネットワークへ送信する。

１７．ＩＭＳコアは、ＩＭメッセージを受信すると、それを遠隔ユーザへ送信する。

＜使用例：ビデオコンテンツ共有＞
ビデオコンテンツ共有は、音声ストリームを有しない上述のＬＴＥを介したビデオ呼の使用例と正確に同じ動作を必要とする。

＜使用例：ファイル転送＞
ファイル及び画像転送は、上述のＬＴＥを介したＩＭの使用例と非常に似ている。主な相違点は、ＭＳＲＰが単一のファイル転送を複数のＭＳＲＰメッセージに分割することである。

＜Ｗｉ−Ｆｉ（登録商標）オフロードのための最適化＞
上述の図５のプロトコルアクセラレータモジュール５４２に加えて、音声、ＳＭＳ、ビデオ及びＲＣＳ機能のためのＷｉ−Ｆｉ（登録商標）オフロードは、図６に示すプロトコルリダイレクタソフトウェアブロックを追加することにより更に最適化できる。

モバイル端末６００のＬＴＥプロセッサ６６０は、レガシモデム制御及びユーザプレーンモジュール６７０、コマンドハンドラ６６５、ＩＳＩ（Internet Service Interface）モジュール６８２、音声エンジンモジュール６８４、ＳＩＰ（Session Initiation Protocol）モジュール６８８、ＯＳＡＬ（Operating System Abstraction Layer）モジュール６８６、拡張ｖポートリダイレクタ（ＶＰＲ）６９５、ｖポートモデム装置（ＶＰＭＤ）６９０、制御／状態モジュール（ＣＳＭ）６７５を有する。ＣＳＭ６７５は、無線ポリシマネジャ（ＲＰＭ）６８０を含む。

モバイル端末６００のアプリケーションプロセッサ６１０は、ビデオエンジン６３０、ビデオ呼を含むＲＣＳアプリケーション６２７、ビデオパケットリダイレクタ６４０、ＲＩＬ及びモデムドライバ６０５、Ｗｉ−Ｆｉ（登録商標）デーモン６１５及びｖポートアプリケーションデバイス（ＶＰＡＤ）６２０、拡張制御／状態インタフェース（ＣＳＩ）６３５及びプロトコルアクセラレータモジュール６４２を有する。モバイル端末６００は、モバイル端末５００と異なり、モバイル端末６００はプロトコルリダイレクタモジュール６４５も有する。ｖポートモデムデバイス（ＶＰＭＤ）６９０及びｖポートアプリケーションデバイス（ＶＰＡＤ）６２０は、プロセッサ間通信（ＩＰＣ）メカニズム６５０として機能的に一緒に考えられても良い。

・プロトコルリダイレクタモジュール６４５。音声若しくはビデオ呼又はＲＣＳ機能がＷｉ−Ｆｉ（登録商標）を介して設定されるとき、全てのＳＩＰトラフィックは、アプリケーションプロセッサ６１０にあるプロトコルアクセラレータモジュール６４２により管理されるプロトコルリダイレクタモジュール６４５によりリダイレクトされ得る。

以下のモジュールは変更される。

・Ｗｉ−Ｆｉ（登録商標）デーモン６１５。全てのＳＩＰトラフィックは、プロトコルリダイレクタモジュール６４５を通じてプロトコルアクセラレータモジュール６４２へ転送される。ＩＭＳコアに接続される１つのアクティブなＳＩＰスタックしか存在しないので、二重登録問題は排除される。

・ＶＰＲモジュール６９５。全てのＷｉ−Ｆｉ（登録商標）ＳＩＰセッションはプロトコルアクセラレータモジュール６４２により管理されるので、このモジュールは、もはやＳＩＰトラフィックをＷｉ−Ｆｉ（登録商標）デーモンへ転送する必要がない。しかしながら、ＶＰＲモジュール６９５は、依然として（音声エンジン６８４により処理された）音声トラフィックをＷｉ−Ｆｉ（登録商標）デーモンへ転送する必要がある。

図６は、Ｗｉ−Ｆｉ（登録商標）デーモンへプロトコルトラフィックをリダイレクトできる完全なシステムを示す。音声呼は、通常の方法で（ＡＴコマンド又はＣＳＩ６３５コマンドを介して）開始される。呼は、ＬＴＥプロセッサ６６０内のＳＩＰスタックの代わりに、プロトコルアクセラレータモジュール６４２内のＳＩＰスタックを用いて確立される。しかしながら、音声ＲＴＰトラフィックは、依然として、音声エンジン６８４を用いて、ＬＴＥプロセッサ内で生成され終端される。音声のためのＲＴＰパケットは、ＶＰＲモジュール６９５を介して、Ｗｉ−Ｆｉ（登録商標）インタフェースへリダイレクトされる。Ｗｉ−Ｆｉ（登録商標）を介したビデオ呼では、ビデオパケットは、ビデオパケットリダイレクタモジュール６４０を介してＷｉ−Ｆｉ（登録商標）デーモンへリダイレクトされる。

＜使用例：プロトコルアクセラレータによるＷｉ−Ｆｉ（登録商標）上のＩＭ＞
以下に、あるユーザから別のユーザへＷｉ−Ｆｉ（登録商標）を介してメッセージを送信するために必要な動作を示す。

１．モバイル端末６００は、ＩＭＳコアにより認証された後、ＩＭメッセージを送信及び受信する準備が整う。

２．ユーザがメッセージを送信しようとすると、ＲＣＳアプリケーション６２７は、ＣＳＩモジュール６３５に接続処理を開始するよう命じる。

３．ＣＳＩモジュール６３５は、メッセージセッションへの招待を送信することにより、遠隔パーティとのＳＩＰメッセージングセッションを開始するために、（ＶＰＡＤ６２０／ＶＰＭＤ６９０の経路を介して）ＣＳＭモジュール６７５に連絡する。招待には、第１のＩＭメッセージが含まれる。

４．ＣＳＭモジュール６７５は、ＲＰＭモジュール６８０を調べ、メッセージがＷｉ−Ｆｉ（登録商標）を介して送信されるべきであることを知る。

５．ＳＩＰセッションはメッセージングのためなので、ＣＳＭモジュール６７５は、Ｗｉ−Ｆｉ（登録商標）を介して新しいセッションを開始するために、（ＶＰＭＤ６９０／ＶＰＡＤ６２０の経路を介して）プロトコルアクセラレータモジュール６４２に連絡する。

６．プロトコルアクセラレータモジュール６４２は、ＳＩＰ招待メッセージを生成し、プロトコルリダイレクタモジュール６４５へ送信する。

７.プロトコルリダイレクタモジュール６４５は、ＳＩＰメッセージをＷｉ−Ｆｉ（登録商標）デーモン６１５へ送信する。Ｗｉ−Ｆｉ（登録商標）デーモン６１５をプロトコルリダイレクタモジュール６４５と共に用いることにより、ＳＩＰメッセージは、ＩＭＳコアへの認可されたＳＩＰコネクションを共有できる。

８．ＩＭＳコアは、招待に対する応答（この場合には承諾）を送信する。Ｗｉ−Ｆｉ（登録商標）デーモン６１５は、これはステップ６で開始された同じメッセージセッションの一部であると決定し、該応答を処理のためにプロトコルリダイレクタモジュール６４５まで渡す。

９．プロトコルリダイレクタモジュール６４５は、処理のためにプロトコルアクセラレータモジュール６４２にメッセージを渡す。

１０．プロトコルアクセラレータモジュール６４２は、ＣＳＭモジュール６７５に、招待が承諾されたことを知らせる。

１１．ＣＳＭモジュール６７５は、ＣＳＩモジュール６３５にこれを渡す。

１２．プロトコルアクセラレータモジュール６４２は、肯定応答メッセージをＩＭＳコアへプロトコルリダイレクタモジュール６４５を介して送信する。プロトコルリダイレクタモジュール６４５は、ネットワークへの送信のために、ＩＭメッセージをＷｉ−Ｆｉ（登録商標）デーモン６１５へ送信する。

１３．ＩＭセッションは動作中になる。ＣＳＩモジュール５３５は、肯定応答メッセージにＩＭメッセージ（本体）を続ける。

１４.ＩＭメッセージは、ＣＳＭモジュール６７５に渡される。

１５．ＣＳＭモジュール６７５は、プロトコルアクセラレータモジュール６４２へＩＭメッセージを送信する。

１６．プロトコルアクセラレータモジュール６４２は、ＭＳＲＰを用いてＩＭメッセージを送信する。

１７．ＭＲＳＰメッセージは、（プロトコルリダイレクタモジュール６４５を通じてアクセスされる）Ｗｉ−Ｆｉ（登録商標）デーモン６１５を通じてネットワークへ送信される。

１８．ＩＭＳコアは、メッセージを受信すると、それを遠隔ユーザに渡す。

当業者は、上述のＷｉ−Ｆｉ（登録商標）を用いてＩＭメッセージの最適化及び追加についての記載が、Ｗｉ−Ｆｉ（登録商標）デーモンを他の形式の代替ネットワークインタフェースデーモンにより置換することにより、及び任意の必要なハードウェア変更を含めることにより、別の形式の代替ネットワークインタフェースを用いたＩＭメッセージの最適化及び追加に容易に変更できることを直ちに理解する。

＜まとめ＞
本願明細書は、ビデオ、ＲＣＳサポート、及びＷｉ−Ｆｉ（登録商標）オフロードをモバイル端末に追加する完全なソフトウェアシステムを記載した。各実施形態は、図に示した物理的及び機能的構成要素に構築される。それらは、ＶｏＬＴＥをＬＴＥプロセッサに追加することで開始する。最後の章（図６）は、音声及びビデオ呼、ＩＰ上のＳＭＳ（ＳＭＳｏＩＰ）、ＲＣＳ機能（特に、ＩＭ、ファイル転送及びコンテンツ共有、等）、及びＷｉ−Ｆｉ（登録商標）オフロードを含むフル機能のシステムを記載した。モジュラアプローチなので、同じ設計及びソフトウェアブロックを用いて、このフル機能のシステムのサブセットを提供することが比較的容易である。また、これらのサブセット及び／又は組合せは、本発明の一部であると考えられる。例えば、図２は、単にＶｏＬＴＥ、ＳＭＳｏＩＰ及びＳＲＶＣＣのための基本製品であるが、図３はＷｉ−Ｆｉ（登録商標）オフロードを追加しており、図４は音声呼を追加している、等である。

当業者は、本発明の教示を守りつつ、装置及び方法の多くの変更及び代替に直ちに気付くだろう。したがって、上述の開示は、添付の請求の範囲の境界によってのみ限定されると考えられるべきである。

［関連出願の参照］
本願は、米国仮特許出願番号６１／６４５,６３５、出願日２０１２年５月１１日の利益を主張する。該米国仮特許出願は参照されることにより本願明細書に組み込まれる。

２０５ ＲＩＬ及びモデムドライバ
２６０ ＬＴＥプロセッサ
２６５ コマンドハンドラ
２７０ レガシモデム制御及びユーザプレーン
２７５ ＣＳＭ制御／状態モジュール
２８２ ＩＳＩモジュール（プロトコルバックプレーン）
２８４ 音声エンジン
３０５ ＲＩＬ及びモデムドライバ
３１０ アプリケーションプロセッサ
３１５ 代替ネットワークインタフェースデーモン
３２０ ｖポートアプリケーションデバイス（ＶＰＡＤ）
３５０ プロセッサ間通信（ＩＰＣ）メカニズム
３６０ ＬＴＥプロセッサ
３６５ コマンドハンドラ
３７０ レガシモデム制御及びユーザプレーン
３７５ ＣＳＭ制御／状態モジュール
３８２ ＩＳＩモジュール（プロトコルバックプレーン）
３８４ 音声エンジン
３８６ ＯＳアダプションレイヤ（ＯＳＡＬ）
３９０ ｖポートモデムデバイス（ＶＰＭＤ）
３９５ ｖポートリダイレクタ（ＶＰＲ）
４０５ ＲＩＬ及びモデムドライバ
４１０ アプリケーションプロセッサ
４１５ 代替ネットワークインタフェースデーモン
４２０ ｖポートアプリケーションデバイス（ＶＰＡＤ）
４２５ ビデオアプリケーション
４３０ ビデオエンジン
４３５ 制御／状態インタフェース（ＣＳＩ）
４４０ ビデオパケットリダイレクタ
４５０ プロセッサ間通信（ＩＰＣ）メカニズム
４６０ ＬＴＥプロセッサ
４６５ コマンドハンドラ
４７０ レガシモデム制御及びユーザプレーン
４７５ ＣＳＭ制御／状態モジュール
４８２ ＩＳＩモジュール（プロトコルバックプレーン）
４８４ 音声エンジン
４８６ ＯＳアダプションレイヤ（ＯＳＡＬ）
４９０ ｖポートモデムデバイス（ＶＰＭＤ）
４９５ ｖポートリダイレクタ（ＶＰＲ）
５０５ ＲＩＬ及びモデムドライバ
５１０ アプリケーションプロセッサ
５１５ 代替ネットワークインタフェースデーモン
５２０ ｖポートアプリケーションデバイス（ＶＰＡＤ）
５２７ ビデオ呼を含むＲＣＳアプリケーション
５３０ ビデオエンジン
５３５ 制御／状態インタフェース（ＣＳＩ）
５４０ ビデオパケットリダイレクタ
５４２ プロトコルアクセラレータ
５５０ プロセッサ間通信（ＩＰＣ）メカニズム
５６０ ＬＴＥプロセッサ
５６５ コマンドハンドラ
５７０ レガシモデム制御及びユーザプレーン
５７５ ＣＳＭ制御／状態モジュール
５８２ ＩＳＩモジュール（プロトコルバックプレーン）
５８４ 音声エンジン
５８６ ＯＳアダプションレイヤ（ＯＳＡＬ）
５９０ ｖポートモデムデバイス（ＶＰＭＤ）
５９５ ｖポートリダイレクタ（ＶＰＲ）
６０５ ＲＩＬ及びモデムドライバ
６１０ アプリケーションプロセッサ
６１５ 代替ネットワークインタフェースデーモン
６２０ ｖポートアプリケーションデバイス（ＶＰＡＤ）
６２７ ビデオ呼を含むＲＣＳアプリケーション
６３０ ビデオエンジン
６３５ 制御／状態インタフェース（ＣＳＩ）
６４０ ビデオパケットリダイレクタ
６４２ プロトコルアクセラレータ
６４５プロトコルリダイレクタ
６５０ プロセッサ間通信（ＩＰＣ）メカニズム
６６０ ＬＴＥプロセッサ
６６５ コマンドハンドラ
６７０ レガシモデム制御及びユーザプレーン
６７５ ＣＳＭ制御／状態モジュール
６８２ ＩＳＩモジュール（プロトコルバックプレーン）
６８４ 音声エンジン
６８６ ＯＳアダプションレイヤ（ＯＳＡＬ）
６９０ ｖポートモデムデバイス（ＶＰＭＤ）
６９５ ｖポートリダイレクタ（ＶＰＲ）

Claims (14)

1. ビデオパケットがＬＴＥモデムを介して伝送されるとき、ビデオコーデック機能を実行するアプリケーションプロセッサにより生成され及び／又は消費されるビデオパケットを、モバイル端末のＬＴＥ（Long Term Evolution）プロセッサへリダイレクトする方法であって、
   前記アプリケーションプロセッサで動作するビデオエンジンが、ビデオパケットを前記ＬＴＥプロセッサへ／から送信及び受信するステップ、
   前記ＬＴＥプロセッサのｖポートリダイレクタ（ＶＰＲ）モジュールが、ＬＴＥビデオベアラチャネルへのアクセスを要求するステップ、
   プロセッサ間通信（ＩＰＣ）メカニズムを用いて、前記ビデオエンジンと前記ＶＰＲとの間でビデオパケットを交換するステップ、
   を有する方法。
2. ビデオパケットが代替ネットワークインタフェースを介して伝送されるとき、前記方法は、
   制御／状態モジュール（ＣＳＭ）が、無線ポリシマネジャ（ＲＰＭ）を用いて、ビデオパケット及び制御パケットにより用いられるよう前記代替ネットワークインタフェースを設定するステップ、
   どの代替ネットワークインタフェースがビデオパケットのために用いられるかを制御するＣＳＭにより、ＶＰＲを通じてビデオパケットを転送するステップ、
   ビデオパケットが前記代替ネットワークインタフェースを介して送信されるとき、前記ＶＰＲが、ビデオパケットを代替ネットワークインタフェースデーモンへリダイレクトするステップ、
   を更に有する請求項１に記載の方法。
3. 制御／状態モジュール（ＣＳＭ）モジュールにより無線ポリシマネジャ（ＲＰＭ）を用いて決定されたように、代替ネットワークインタフェースデーモン又はＬＴＥモデムへビデオパケットをリダイレクトするビデオパケットリダイレクタ、
   を更に有する請求項２に記載の方法。
4. モバイル端末のアプリケーションプロセッサのビデオデータをＬＴＥ（Long Term Evolution）プロセッサの音声データと同期させる方法であって、前記ＬＴＥプロセッサは、ＶｏＩＰ（Voice-over-Internet-Protocol）又はＶｏＬＴＥ（Voice over Long Term Evolution）のために利用可能であり、前記方法は、
   ＳＩＰ（Session Initiation Protocol）スタックとＬＴＥモデム又は任意の他の代替ネットワークインタフェースとの間にあるｖポートリダイレクタ（ＶＰＲ）が、前記モバイル端末又は対応する無線ネットワークのオペレータにより選択された無線ポリシに従って全てのＳＩＰパケットをリダイレクトするステップ、
   前記ＬＴＥプロセッサの音声エンジンと前記アプリケーションプロセッサのビデオエンジンとの間で、前記ビデオエンジンと前記音声エンジンとの間のプロセッサ間通信（ＩＰＣ）メカニズムを用いて、同期情報を交換するステップであって、前記ビデオエンジン及び前記音声エンジンにそれらの個々の復号化レートを管理させて音声とビデオが同期するようにする、ステップ、
   を有する方法。
5. モバイル端末に対して単一の認可されたＳＩＰ（Session Initiation Protocol）コネクションを維持しながら、ＳＩＰ機能を異なるプロセッサに渡って分散させる方法であって、
   前記モバイル端末のプロセッサにｖポートリダイレクタモジュール（ＶＰＲ）を設けるステップ、
   前記プロセッサにあるＳＩＰモジュールが、前記ＶＰＲモジュールに、ＩＭＳ（Internet Protocol Multimedia Subsystem）コアへのＳＩＰコネクションを開くよう要求するステップ、
   前記ＳＩＰモジュールが、ＶＰＲモジュールコネクションを用いて、前記ＩＭＳコアに登録するステップ、
   前記ＶＰＲモジュールが、前記モバイル端末内の異なるプロセッサにある他のＳＩＰモジュールが前記ＩＭＳコアへの同じＶＰＲモジュールコネクションを使用することを許可するステップ、
   を有する方法。
6. 前記ＶＰＲモジュールが、ＳＩＰパケット毎に対応するＳＩＰモジュールを決定するために、前記ＩＭＳコアから来るＳＩＰパケットを調べるステップ、
   前記ＶＰＲモジュールが、前記ＳＩＰパケットを前記対応するＳＩＰモジュールへ転送するステップ、
   を更に有する請求項５に記載の方法。
7. 前記ＶＰＲモジュールが、音声及びビデオ呼セッションに関連するＳＩＰパケットを、前記プロセッサにある第１のＳＩＰモジュールへ転送し、全ての他のパケットを前記モバイル端末のアプリケーションプロセッサで動作するプロトコルアクセラレータモジュールへ転送するステップ、
   を更に有する請求項６に記載の方法。
8. 前記ＶＰＲモジュールが、ＭＳＲＰ（Message Session Relay Protocol）処理を必要とする全てのメッセージを１つのプロセッサにあるＭＳＲＰスタックへ転送し、全ての他のＳＩＰメッセージを別のプロセッサにあるＳＩＰスタックへ転送するステップ、
   を更に有する請求項６に記載の方法。
9. ＬＴＥ（Long Term Evolution）プロセッサ内のＳＩＰ（Session Initiation Protocol）により確立されたＩＰ（Internet Protocol）コネクションを用いて、前記ＬＴＥプロセッサを備えたモバイル端末でＲＣＳ（Rich Communications Services）機能を実施する方法であって、
   前記モバイル端末のアプリケーションプロセッサにプロトコルアクセラレータを設けてＳＩＰ機能を提供するステップ、
   制御／状態モジュール（ＣＳＭ）が、前記ＬＴＥプロセッサ内の前記ＳＩＰモジュールにより実行されるべきＳＩＰ機能及び前記プロトコルアクセラレータで実施されるべきＳＩＰ機能を決定し、その決定に従って、前記ＬＴＥプロセッサ内のｖポートリダイレクタモジュールを介するＲＣＳデータを、前記プロトコルアクセラレータ又は前記ＬＴＥプロセッサ内の前記ＳＩＰモジュールへ転送するステップ、
   を有し、
   前記ＬＴＥプロセッサ内の前記ＳＩＰモジュールで実行される必要のあるＳＩＰ機能は、前記ＬＴＥプロセッサ内の前記ＳＩＰモジュールへ転送され、ＶｏＩＰ（Voice-over-Internet-Protocol）及びＳＭＳ（Short Message Service）について、前記ＬＴＥプロセッサ内の前記ＳＩＰモジュールにより確立された同じ認可されたＳＩＰコネクションを介してＲＣＳデータが送信されるようにする、方法。
10. 前記ＣＳＭが、前記ＬＴＥプロセッサ内の前記ＳＩＰモジュールにより実行されるべきＳＩＰ機能及び前記プロトコルアクセラレータで実施されるべきＳＩＰ機能を決定するステップであって、該決定は、ＭＳＲＰ（Message Session Relay Protocol）機能を含む前記ＳＩＰ機能により必要とされるメモリ量、前記アプリケーションプロセッサ若しくは前記ＬＴＥプロセッサで利用可能なメモリ量、前記モバイル端末の前記アプリケーションプロセッサ若しくはＬＴＥプロセッサで利用可能なＣＰＵの量、のうちのいずれか１つ又は任意の組合せに従う、ステップ、
    を更に有する請求項９に記載の方法。
11. 前記アプリケーションプロセッサにある前記プロトコルアクセラレータでＭＳＲＰ（Message Session Relay Protocol）のみを実施するステップ、
    前記ＬＴＥプロセッサ内の前記ＶＰＲモジュールが、ＭＳＲＰプロトコルを必要とする全てのメッセージを前記プロトコルアクセラレータへ転送し、全ての他のＳＩＰメッセージを前記ＬＴＥプロセッサ内の前記ＳＩＰモジュールへ転送するステップ、
    を更に有する請求項９に記載の方法。
12. ＬＴＥ（Long Term Evolution）プロセッサを備えたモバイル端末のＲＣＳ（Rich Communication Services）機能が、ＳＩＰ（Session Initiation Protocol）プロトコル機能が前記ＬＴＥプロセッサ内に埋め込まれたＳＩＰスタックの外部で実行されることを要求するとき、二重問題を回避する方法であって、
    前記ＬＴＥプロセッサが、ネットワークに登録し、ＶｏＩＰ（Voice-over-Internet-Protocol）及びＳＭＳｏＩＰ（Short Message Service over Internet Protocol）のためにＩＭＳ（Internet Protocol Multimedia Subsystem）コアへの認可されたＳＩＰコネクションを確立するステップ、
    アプリケーションプロセッサにあるプロトコルアクセラレータにより処理され且つＬＴＥモデムを通じて送信されるべき、後続のＲＣＳ機能のための全てのＩＰ（Internet Protocol）パケットを、前記ＩＭＳコアへの単一の認可されたＳＩＰコネクションを維持する前記ＬＴＥプロセッサのｖポートリダイレクタ（ＶＰＲ）を通じて転送するステップ、
    前記ＩＭＳコアから入来し、前記認可されたＳＩＰコネクションを介して前記ＬＴＥモデムを経由して前記ＶＰＲを通じて受信されるパケットを、必要に応じて、前記ＬＴＥプロセッサに埋め込まれたＳＩＰスタックへ又は前記モバイル端末のアプリケーションプロセッサ内のプロトコルアクセラレータへ転送するステップ、
    を有する方法。
13. 前記ＬＴＥプロセッサは、ＶｏＬＴＥ（Voice-over-Long-Term-Evolution）の準備が整い、埋め込みＳＩＰサブシステムを有し、前記方法は、
    ＲＣＳパケットがＬＴＥネットワークインタフェースに加えて代替ネットワークインタフェースを介して送信されるとき、前記ＶＰＲが、プロセッサ間通信（ＩＰＣ）メカニズムを介して、変更後のＲＣＳパケットを前記アプリケーションプロセッサ内の前記代替ネットワークインタフェースデーモンへ再転送し、単一の認可されたコネクションを維持しながら、前記代替ネットワークインタフェースを介してＲＣＳパケットを送信するステップ、
    を有する請求項１２に記載の方法。
14. 前記ＬＴＥプロセッサは、ＶｏＬＴＥ（Voice-over-Long-Term-Evolution）の準備が整い、埋め込みＳＩＰサブシステムを有し、前記方法は、
    ＲＣＳパケットがＬＴＥ無線に加えて代替ネットワークインタフェースを介して送信されるとき、前記アプリケーションプロセッサの前記プロトコルアクセラレータを用いて前記アプリケーションプロセッサの全てのＳＩＰメッセージを処理し、前記ＲＣＳパケットを前記アプリケーションプロセッサ内の前記代替ネットワークインタフェースデーモンへ転送するステップであって、前記ＲＣＳパケットが前記代替ネットワークインタフェースを介して、単一の認可されたコネクションを介して、及び前記アプリケーションプロセッサと前記ＬＴＥプロセッサとの間で特別なデータ交換を有しないで送信できるようにする、ステップ、
    を更に有する請求項１２に記載の方法。

Images