JP2009544195A - Ｓｉｇｃｏｍｐｕｄｖｍパフォーマンスの最適化のための方法および装置 - Google Patents

Abstract

通信ネットワークと無線ユーザ機器との間の信号圧縮最適化システムは、縮小されたコンテンツプロセッシング待ち時間が実現可能なとき、最適化されたデコンプレッサを有効に選択し、そうでないときには、受信された復元バイトコードを解釈するユニバーサルデコンプレッサ仮想マシン(ＵＤＶＭ)のような、仮想マシンデコンプレッサを選択する。ＵＤＶＭがいかなる特定の復元アルゴリズムについて最適化されず、そして、実行前にバイトコードにおいて各ステートメントを分析することに関連づけられた必要条件遅延によって苦しむので、可能なときにいつでもＵＤＶＭの使用を回避することが出来ることは、無線で受信されたシグナリングメッセージあるいはメディアコンテンツを表しているという点で、ユーザの経験を高める。

Description

優先権主張

（米国特許法第１１９条の下の優先権主張）
この特許出願は、ここでの譲受人に譲渡され、ここにおける参照によりここに明示的に組み込まれる、２００６年７月１２日に出願された、「ＳｉｇＣｏｍｐ ＵＤＶＭパフォーマンスの最適化のための方法および装置(“Method and Apparatus for Optimization of SigComp UDVM Performance”)」と題された米国仮特許出願第６０／８３０，５４５号の優先権を主張する。

背景

本発明は無線通信のための圧縮方法に関する。

セッションイニシエーションプロトコル(Session Initiation Protocol)（ＳＩＰ）は、第３世代パートナーシッププロジェクト(Third Generation Partnership Project)（３ＧＰＰ）リリース５から始まっている、第３世代モバイルネットワークにおいて呼び出し制御のために使用されるプロトコルである。ＳＩＰはテキスト符号化(textual encoding)を使用しており、それはＳＩＰに基づいてサービスを作り、ＳＩＰへの拡張を設計し、プロトコルをデバッグすることを容易にする。しかしながら、ＳＩＰのテキスト符号化は、さらに重大な欠点(drawback)を有しており、ＳＩＰメッセージは、例えばモバイル通信のためのグローバルシステム(Global System for Mobile communication)（ＧＳＭ）呼び出し制御において、使用されるプロトコルのものよりも、かなり大きいということはよく知られている。より多くのデータは低帯域幅の無線インタフェースにわたって送信される必要があるので、大きなメッセージサイズは、増大された呼び出しセットアップ遅延を結果としてもたらす。この観察は、呼び出しセットアップ時間を減らすことが出来る解決方法を展開する必要性を作った。そのような１つの解決方法は、インターネット技術タスクフォース(Internet Engineering Task Force)（ＩＥＴＦ）によって設計されたシグナリング圧縮(Signaling Compression)（SigComp）プロトコルである。ＳｉｇＣｏｍｐは、２つのネットワークエレメントの間でアプリケーション層シグナリングの圧縮のためのフレームワークを提供する。ＳｉｇＣｏｍｐアーキテクチャの中心部分は、ユニバーサルデコンプレッサ仮想マシン(Universal Decompressor Virtual Machine)（ＵＤＶＭ）であり、復元アルゴリズム(decompression algorithms)を実行するために最適化された仮想マシンである。ＵＤＶＭのために、ＳｉｇＣｏｍｐは、すべてのＳｉｇＣｏｍｐ終点(SigComp endpoints)によってサポートされるべき単一のアルゴリズムを命ずる(dictating)代わりに、広範囲の圧縮アルゴリズムをサ
ポートできる。

ＳｉｇＣｏｍｐは、３ＧＰＰリリース５ ＩＰマルチメディアサブシステム（ＩＭＳ）の必須部分である。それは、端末とプロキシ呼び出しセッション制御機能(Proxy Call Session Control Function)（Ｐ−ＣＳＣＦ）の間のインタフェースにわたって適用され、それは、ＩＭＳ内で端末用の第１の接点(contact point)である。ＳｉｇＣｏｍｐは、呼び出しセットアップのときのアイドル時間を減らすことによってユーザが感じるサービスの質を改善する。それは、さらにネットワークが、加入者ごとの消費されたリソース(resource)の量を減らすことによって、多数のユーザをサポートすることを可能にする。

ＳｉｇＣｏｍｐについての主要なターゲット(primary taeget)は、セルラシステムであり、ここでは、モバイル端末は、さまざまな機能を有しており、検出されていないエラーが、セルラリンク上で導入される可能性がある。ＳｉｇＣｏｍｐは、また、セルラシステムを含んでいる、限定されたスループットを備えた通信リンクを対応する。

以下は、開示されたバージョンのさまざまな態様の基本的な理解を提供するために、単純化された概要(summary)を、示す。この概要は、広範囲な全体像ではなく、重要な／決定的なエレメントを識別することも、あるいは、そのようなバージョンの範囲を詳細に描写することも、意図されていない。その目的は、後で示される、より詳細な説明の前置きとして、簡略化された形で説明されたバージョンのいくつかの概念(concepts)を提供することである。

一態様は、多数の圧縮アルゴリズムのうちの１つによって圧縮されたデータコンテンツ(data content)を通信することを提供する。各圧縮アルゴリズムは、圧縮されたデータコンテンツからデータコンテンツを作ることが出来る、対応する復元アルゴリズムを有する。増大された柔軟性を与えるために、復元アルゴリズムを実行するのに十分なバイトコードは、バイトコードを解釈するために復元仮想マシンについて意図された圧縮されたデータコンテンツに沿ってデータパケットプロトコルの一部として、送信される。復元アルゴリズムを解釈するのに必要とされた、プロセッシング時間を減らすことによってユーザ経験を高めるために、検出されたバイトコードに関連づけられたマシンコードにおける、復元アルゴリズムのアクセス可能で実行可能なバージョンは、位置づけられ(located)、仮想マシンを使用することよりもむしろデータコンテンツを復元するために、使用される。

さらに別の態様においては、少なくとも１つのプロセッサは、復元ソースコードの実行可能なバージョンを位置づけることによって、データコンテンツを復元する方法を実行するように、コンフィギュアされる。特に、第１のモジュールは、ソースコードを検出する。第２のモジュールは、ソースコードに関連づけられた復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づける。第３のモジュールは、復元アルゴリズムの位置づけられたアクセス可能で実行可能なバージョンを利用して、圧縮されたデータコンテンツを復元する。

追加の態様において、コンピュータプログラムプロダクトは、コンピュータが少なくとも１つのメッセージにおいて含まれたソースコードをコンピュータが検出するようにさせるための第１セットのコードを含んでいる、コンピュータ可読メディアを有する。第２セットのコードは、コンピュータが、検出されたソースコードに関連づけられた対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づけるようにさせるためである。そのあと、第３セットのコードは、対応する復元アルゴリズムの位置づけられたアクセス可能で実行可能なバージョンを利用して、圧縮されたデータコンテンツをコンピュータが復元するようにさせるためである。

さらに別の態様において、マシンコードへのバイトコードの初期コンパイレーションのための手段は、復元アルゴリズムの非常に効率的な実行を提供する。例えば、信号圧縮(SigComp)を使用して圧縮されたセッションイニシエーションプロトコル／セッション記述プロトコル（ＳＩＰ／ＳＤＰ）メッセージで、この方法を使用することは、メッセージの呼び出しセットアップ時間と処理の待ち時間(the latency of the processing and call setup times of the message)を短くするであろう。

１つのインプリメンテーションにおいては、メカニズムは、受信された各ＳＩＰ／ＳＤＰメッセージの復元のためのユニバーサル復元仮想マシン（ＵＤＶＭ）インタープリタ(interpreter)を実施することを回避するように提供されている。ＵＤＶＭインタープリタの実行を回避することは、モバイル局上の計算の必要要件を減らし、そして、ＳＩＰ／ＳＤＰプロセッシングにおける潜在的な遅延を減らす。このアプローチは、ＳＩＰベースの呼び出しフローのために、呼び出しセットアップ／分解時間を繰り返す。

別の態様において、通信デバイスに、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）データコンテンツ(Internet Protocol(IP) Multimedia Subsystem(IMS) data content)を広める方法は、圧縮アルゴリズムでＩＭＳデータコンテンツを圧縮することを備えている。方法は、復元バイトコードを含んでいる、データストラクチャを生成することと、通信デバイス(communication device)に対して、圧縮されたＩＭＳデータコンテンツおよび復元バイトコードを送信することと、をさらに含んでいる。さらに、方法は、通信デバイスからのリクエストにすぐ反応する(responsive)通信デバイスに対して、復元バイトコードの実行可能なバージョンを送信すること、を含んでいる。

一態様において、通信デバイスに、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）データコンテンツを広めるようにコンフィギュアされた少なくとも１つのプロセッサは、圧縮アルゴリズムでＩＭＳデータコンテンツを圧縮するための第１モジュールを備えている。少なくとも１つのプロセッサは、復元バイトコードを含んでいるデータストラクチャを生成するための第２モジュール、そして、圧縮されたＩＭＳデータコンテンツと復元バイトコードを通信デバイスに対して送信するための第３モジュール、をさらに含んでいる。さらに、少なくとも１つのプロセッサは、通信デバイスからのリクエストにすぐ反応する通信デバイスに対して、復元バイトコードの実行可能なバージョンを送信するための第４のモジュール、を含んでいる。

さらなる態様においては、コンピュータプログラムプロダクトは、複数のセットのコードを備えている、コンピュータ可読メディアを含む。第１セットのコードは、圧縮アルゴリズムでインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）データコンテンツを、コンピュータが圧縮するようにさせることが動作可能である。第２セットのコードは、復元バイトコードを含んでいるデータストラクチャを、コンピュータが生成するようにさせることが動作可能である。第３セットのコードは、通信デバイスに対して、圧縮されたＩＭＳデータコンテンツおよび復元バイトコードを、コンピュータが送信するようにさせることが動作可能である。そして、第４セットのコードは、通信デバイスからのリクエストにすぐ反応する通信デバイスに復元バイトコードの実行可能なバージョンをコンピュータが送信するようにさせることが動作可能である。

別の態様では、通信デバイスに、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）データコンテンツを広めるための装置(apparatus)は、圧縮アルゴリズムでＩＭＳデータコンテンツを圧縮するための手段を備えている。装置は、さらに、復元バイトコードを含んでいるデータストラクチャを生成するための手段と、圧縮されたＩＭＳデータコンテンツと復元バイトコードを通信デバイスに送信するための手段と、を含んでいる。さらに、装置は、通信デバイスからのリクエストにすぐ反応する通信デバイスに復元バイトコードの実行可能なバージョンを送信するための手段、を含んでいる。

前述および関連する目的の実現のために、１つまたは複数のバージョンは、この後十分に説明され、そして特許請求の範囲において特に示される、特徴を備えている。以下の説明および添付図面は、詳細に、ある説明のための態様を記述しており、そして、バージョンの原理(principles)が使用されることができる様々な方法のうちのほんの少しを示している。他の利点および新規な特徴は、図面と共に考慮されるとき、以下の詳細な説明から明らかとなるであろう、また、開示されたバージョンは、すべてのそのような態様およびそれらの同等物(equivalents)を含むように意図されている。

図１は、通信ネットワークと通信中である無線デバイスのための信号圧縮最適化システムのブロック図である。 図２は、図１のシステムの無線デバイスのコンポーネントの一態様の概略図である。 図３は、第三世代パートナーシッププロジェクト（３ＧＰＰ）リリース５ネットワークアーキテクチャのさらなる特徴を図示している図１の通信ネットワークと無線デバイスの図である。 図４は、図１の信号圧縮最適化システムのためのインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）のエンティティのコンフィギュレーション図である。 図５は信号圧縮（ＳｉｇＣｏｍｐ）の終点のロケーションのブロック図である。 図６は、図５のＳｉｇＣｏｍｐの終点のアーキテクチャのブロック図である。 図７は、図１のシステムによってインプリメントされた信号圧縮最適化の方法のフロー図である。 図８は、図１の無線デバイスのためのオペレーションの信号圧縮最適化シーケンスのバージョンを図示している図である。 図９は、図１の無線デバイスのためのオペレーションの信号圧縮最適化シーケンスのバージョンを図示している図である。 図１０は、図１の信号圧縮最適化システムのバージョンを図示している図である。 図１１は、図１の信号圧縮最適化システムのバージョンを図示している図である。 図１２は静的なＤＥＦＬＡＴＥパフォーマンスを図示しているチャートである。 図１３は、Ｌｅｍｐｅｌ−Ｚｉｖ−Ｓｔｏｒｅｒ−Ｓｚｙｍａｎｓｋｉ（ＬＺＳＳ）圧縮アルゴリズムのパフォーマンスを図示しているチャートである。

詳細な説明

様々な態様が、図面を参照して記述されている。以下の説明においては、説明の目的のために、多くの具体的な詳細な説明が、１つまたは複数の態様の完全な理解を提供するために、示されている。しかしながら、様々な態様は、これらの具体的な詳細なしで実行されることができるということは明白であり得る。他の例においては、よく知られたストラクチャおよびデバイスは、これらのバージョンを簡略に説明するために、ブロック図の形で示されている。

装置および方法は、特に、ワイヤレス環境における使用についてよく適していてもよいが、通信ネットワーク、公共ネットワーク、例えばインターネット、プライベートネットワーク、例えば仮想プライベートネットワーク(virtual private networks)（ＶＰＮ）、ローカルエリアネットワーク、広域ネットワーク、ロングホールネットワーク(long haul networks)、あるいはいずれの他のタイプのデータ通信ネットワーク、を含むがこれに限定されるものではない、いずれのタイプのネットワーク環境において適していてもよい。

図１は、通信ネットワーク１２と無線ユーザ機器（通信デバイス）１４の間の信号圧縮最適化システム１０の１つの態様を図示している。通信ネットワーク１２内では、マルチメディアコンテンツ(multimedia content)１６として図示される、メディアあるいはシグナリング（例えばオーディオ、イメージ、ビデオ、ブライユ等）（一般的には「データ」）は、データ圧縮アルゴリズム２０を利用してコンプレッサ１８によってデータ圧縮をする(undergoes)。データ復元バイトコード２２は、ユーザ機器１４の無線通信リンク２８に、圧縮されたメディアコンテンツ(compressed media content)２６が続く無線通信リンク２４による無線送信に適切な形式でソースコードまたはバイトコードを提供する。受信されたバイトコード２２にすぐ反応するプロセッサ３０は、仮想マシンデコンプレッサの使用を各インスタンスにおいて回避するために、減らされたセットアップの待ち時間について便利であるとき、最適化されたデコンプレッサ３２を有効に選択する。代替的に、インプリメンテーションは、最適化されたデコンプレッサ３２がアクセス可能でない場合、インスタンスを有することができる。プロセッサ３０は、そのあと、ユニバーサルデコンプレッサ仮想マシン（ＵＤＶＭ）３４として図示される、仮想マシンデコンプレッサを選択することができる。ＵＤＶＭ３４は、例えば受信されたバイトコード２２`によって命令されたように、復元アルゴリズムの範囲を柔軟に実行することができる、一般化されたアーキテクチャを有する、しかしながら、ＵＤＶＭ３４は、いずれの特定の復元アルゴリズムについて最適化されず、実行前にバイトコード２２において各ステートメントを分析することに関連づけられた必要条件遅延によって苦しむ(suffer)。

このような実行遅延の有効的な回避を実行するために、プロセッサ３０は、バイトコード２２``のアクセス可能なコピーは、受信されたバイトコード２２``と同じであるということを認識する。バイトコード`を実行するための、実行可能な復元アルゴリズム３８の一部としてマシンコード３６は、そのあと、最適化されたデコンプレッサ３２によって使用される。マシンコード３６および／または最適化されたデコンプレッサは、仮想マシンにおいてソースコード（例、バイトコード２２`）を解釈することと比較して、復元のための減らされた時間について最適化される。可能なときいつでも、ＵＤＶＭ３４の使用を回避することができることによって、ユーザ機器１４は、遅延されたセットアップを回避することによってメディアコンテンツプレイヤー３８上でメディアコンテンツ(media content)１６を表わすことにおいてユーザ経験を高める。

マシンコード３６は局所的に保存されたライブラリの一部としてアクセスされることができ、局所的にコンパイルされ、今後の使用のために保存されることができ、遠隔ライブラリから無線でアクセスされることができ、リクエストのとき遠隔にコンパイルされ、今後の使用について保存されることができ、および／または、ファームウェアあるいは、最適化されたデコンプレッサに組み込まれた回路構成の他の形として提供されることができるということが、本開示の利益を用いて理解されるべきである。遠隔にコンパイルされたマシンコード３６および／またはコンパイルすることにおける遅延は、無線ユーザ機器１４についての減らされた複雑さの必要要件と、ＵＤＶＭにわたって進行中の復元効率性と、における利益によって、相殺されるであろう。

いくつかの態様によると、通信デバイス１４は、いずれのタイプのコンピュータ化された、コミュニケーション装置を備えることができる。例えば、図１で示されるように、通信デバイス１４は、無線のおよび／またはセルラ電話のような、モバイル通信デバイスを備えることができる。代替的に、通信デバイス１４は、プロキシ呼び出し／セッション制御機能（Ｐ−ＣＳＣＦ）サーバ、ネットワークデバイス、サーバ、コンピュータワークステーション等のような、固定された通信デバイスを備えてもよい。通信デバイス１４は、このような説明されたあるいは図示されたデバイスに通信デバイスが限定されないが、携帯情報端末(Personal Digital Assistant)（ＰＤＡ）、２方法テキストページャ(two-way text pager)、有線あるいは無線通信ポータルを有するポータブルコンピュータ、そして、有線および／または無線の通信ポータルを有するいずれのタイプのコンピュータプラットフォームをさらに含んでいるということは、理解されるべきである。さらに、通信デバイス１４は、遠隔センサ、遠隔サーバ、診断ツール、データリレー(data relays)、そして同様のもの、のような遠隔スレーブ(remote-slave)あるいは他の同様デバイスであってもよく、それらのエンドユーザを有さず、無線あるいは有線ネットワークにわたってデータを単に通信する。代替的な態様においては、通信デバイス１４は、陸線電話、パーソナルコンピュータ、セットトップボックス、あるいは同様のもののような、有線通信デバイスであってもよい。さらに、単一のタイプあるいは複数の前述のタイプの、任意の数の通信デバイス１４のいずれの組み合わせがシステム１０において利用されることができるということは、留意されるべきである。したがって、本装置および方法は、有線あるいは無線の通信ポータルを含み、無線モデム、ＰＣメモリカード国際協会(Personal Computer Memory Card International Association)（ＰＣＭＣＩＡ）カード、アクセス端末、パーソナルコンピュータ、電話、あるいは、それらのいずれの組み合わせ、あるいは、サブコンビネーション(sub-combination)を限定されることなく含んでいる、いずれの形態の有線あるいは無線デバイスあるいはコンピュータモジュール上で、それに応じて実行されることができる。

さらに、通信デバイス１４は、マルチメディアコンテンツ１６をリクエストする、マルチメディアコンテンツ１６と相互に作用する、および／またはマルチメディアコンテンツ１６をプレイする(playing)ような目的のために、ユーザインタフェース４２を含むことができる。このユーザインタフェース４２は、通信デバイス１４への入力を生成するあるいは受信するのに動作可能な入力デバイス４４と、通信デバイス１４のユーザによる消費のための情報を生成するおよび／または表わすのに動作可能な出力デバイス４６と、を含む。例えば、入力デバイス４４は、キーパッドおよび／またはキーボード、マウス、タッチスクリーンディスプレイ、音声認識モジュールに関連づけられたマイクロホン、等のような、少なくとも１つのデバイスを含むことができる。ある態様においては、入力デバイス４４は、コンテンツについてのリクエストのユーザ入力、あるいは、追加情報についてのリクエストのユーザ入力、を提供することができる。さらに、例えば、出力デバイス４６は、ディスプレイ、オーディオスピーカ、触覚フィードバックメカニズム(haptic feedback mechanism)等を含むことができる。出力デバイス４６は、グラフィカルユーザインタフェース、サウンド、バイブレーションのような感覚、等、を生成することができ、そして、そのような出力は、例えば、マルチメディアコンテンツ１６の表示に関連付けられることができる（図１）。

さらに、通信デバイス１４は、デバイスに対して機能性を提供するためにアプリケーションを実行することが動作可能なコンピュータプラットフォーム４８を含むことができ、そして、さらに入力デバイス４４と出力デバイス４６と相互作用することができる。コンピュータプラットフォーム４８は、メモリ５０を含むことができ、それは、揮発性および不揮発性メモリ部分、例えば読み出し専用および／またはランダムアクセスメモリ（ＲＡＭとＲＯＭ）、電子的消去可能ＰＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリ、および／またはコンピュータプラットフォームに共通したいずれのメモリ、を備えることができる。さらに、メモリ５０は、磁気メディア、光学メディア、テープ、および／またはハードディスク、そしてリムーバブルメモリコンポーネントのような、いずれの第２の、および／または、第３のストレージデバイスと電子ファイルシステムを含んでいる、アクティブメモリとストレージメモリを含むことができる。

さらに、コンピュータプラットフォーム４８は、プロセッサ５２も含むことができ、それは、特定用途向けＩＣ(application-specific integrated circuit)（ＡＳＩＣ）、あるいは他のチップセット、プロセッサ、論理回路、あるいは他のデータ処理デバイスであってもよい。いくつかの態様においては、例えば通信デバイス１４がセルラ電話を備えるとき、ＡＳＩＣのような他の論理あるいはプロセッサ５２は、メモリ５０において、メディア関連アプリケーションと、データ呼び出し、音声呼び出しのようないずれの常駐のソフトウェアコンポーネントとインタフェースでつなぐ(interfaces with)、アプリケーションプログラミングインタフェース(application programming interface)（ＡＰＩ）層５４を実行することができる。ＡＰＩ ５４は、個別の通信デバイス上で実行する、実行時間環境であってもよい。１つのそのような実行時間環境は、カリフォルニア州のサンディエゴのクアルコム株式会社によって展開された、無線のためのバイナリ実行時間環境(Binary Runtime Environment for Wireless(R))（ＢＲＥＷ(R)）ソフトウェアである。他の実行時間環境は、例えば無線コンピューティングデバイス上でアプリケーションの実行を制御することを操作することが利用されることができる。

さらに、プロセッサ５２は、通信デバイス１４の機能性および通信ネットワーク２８上の通信デバイスの動作性(operability)を可能にする、ハードウェア、ファームウェア、ソフトウェアおよびそれらの組み合わせにおいて具現化された様々な処理サブシステム５６を含んでいてもよい（図１）。例えば、処理サブシステム５６は、通信デバイス１４のコンポーネント内および／または中同様、他のネットワーキングされたデバイスで、通信をイニシエートすることおよび維持すること、そしてデータを交換すること、を可能にする。一態様において、例えばセルラ電話において、プロセッサ５２は、１つの処理サブシステム５６または複数の処理サブシステム５６の組み合わせを含むことができ、例えば：音声、不揮発性メモリ、ファイルシステム、送信、受信、サーチャ(searcher)、層１、層２、層３、メイン制御、遠隔プロシージャ(remote procedure)、ハンドセット、パワーマネジメント、診断、デジタルシグナルプロセッサ、ボコーダ、メッセージング、コールマネージャ、Ｂｌｕｅｔｏｏｔｈ（Ｒ）（登録商標）システム、Ｂｌｕｅｔｏｏｔｈ（Ｒ）（登録商標）ＬＰＯＳ、ポジション決定、ポジションエンジン、ユーザインタフェース、スリープ、データサービル、セキュリティ、認証(authentication)、ＵＳＩＭ／ＳＩＭ（ユニバーサル加入者識別モジュール／加入者識別モジュール）、音声サービス、グラフィックス、ＵＳＢ（ユニバーサルシリアルバス）(universal serial bus)、ＭＰＥＧ（ムービングピクチャエキスパートグループ）(Moving Picture Experts Group)プロトコルマルチメディアのようなマルチメディア、ＧＰＲＳ（汎用パケット無線サービス）(General Packet Radio Service)、ショートメッセージサービス（ＳＭＳ）、ショートボイスサービス（ＳＶＳ（ＴＭ））、ウェブブラウザ等がある。開示された態様については、プロセッサ５２のプロセッシングサブシステム５６は、コンピュータプラットフォーム４８上で実行するアプリケーションと相互作用するいずれのサブシステムコンポーネントを含むことができる。開示された態様については、プロセッサ５２のプロセッシングサブシステム５６は、コンピュータプラットフォーム４８上で実行しているアプリケーションと相互作用する、いずれのサブシステムコンポーネントを含むことができる。

コンピュータプラットフォーム４８は、通信ネットワーク２８（図１）と通信デバイス１４との間のコンテンツリクエストと、コンテンツ２４（図１）を交換することが動作可能であることに加えて、通信デバイス１４の様々なコンポーネント間の通信を可能にする、通信モジュール５８をさらに含むことができる。通信モジュール５８は、ハードウェア、ファームウェア、それのソフトウェアおよび／またはそれらの組み合わせにおいて具体化されてもよく、そして、イントラデバイス通信およびインターデバイス通信における使用のためのすべてのプロトコルをさらに含むことができる。さらに、通信モジュール５８は、ここに説明されている装置および方法にしたがって、情報を送信する、および／または受信することが動作可能であり、例えば、マルチメディアコンテンツ１６（図１）をリクエストし、圧縮されたメディア／シグナリングコンテンツ２８およびバイトコード２２`（図１）を受信する。

いくつかの態様において、通信デバイス１４のメモリ５０は、バックグラウンドプロセスあるいはフォアグラウンドプロセスにおいて、通信ネットワーク１２にわたって、マルチメディアコンテンツ１６をリトリーブし(retrieve)、保存し、そしてプレイすることが動作可能な、ユーザインタフェースモジュール６０をさらに記憶することができる。ユーザインタフェースモジュール４０は、ユーザインタフェース４２の機能とマルチメディアコンテンツ１６のタイプに適切であるメディアプレイヤーを含んでいる、これらの機能を実行することが動作可能で実行可能なインストラクションとデータ、ハードウェア、ソフトウェア、ファームウェアのうちの１つあるいはいずれの組み合わせ、を備えることができる。

図３−６を参照すると、信号圧縮最適化システム１０の使用の例示的な環境として、ネットワークアーキテクチャ１００は、ＩＰマルチメディアサブシステム（ＩＭＳ）ネットワークのための第３世代パートナーシッププロジェクト（３ＧＰＰ）と３ＧＰＰ２標準規格によって指定され、そして、ＲＦＣ３３２０、ＲＦＣ３３２１およびＩＭＳについての３ＧＰＰ標準規格（例、３ＧＰＰ ＴＳ ２３．２２８）において定義される、特定タイプの信号圧縮(SigComp)を実行するために開示されている。図３において、ユニバーサルな方法(universal method)は、モバイル通信デバイス（ＳＩＰユーザエージェント）と、プロキシ呼び出し／セッション制御機能（Ｐ−ＣＳＣＦ）の間で、無線上で送られたＳＩＰシグナリングメッセージを圧縮する。これは、送信された第１メッセージの一部として、復元パーティ(de-compressing party)に復元アルゴリズムを送信している、圧縮パーティ(compressing party)を含む。アルゴリズム（バイトコード２２`）を受信するとき復元パーティ（通信デバイス１４）は、受信されたバイトコード２２`を解釈するメモリ５０において、ユニバーサルデコンプレッサ仮想マシン（ＵＤＶＭ）インタープリタ６４を実行し、以下のメッセージ（圧縮されたメディア／シグナリングコンテンツ２８）を復元する。このアプローチの利点は、そのバイトコードが無線上で供給されているかぎり、いずれの種類のアルゴリズムをサポートする能力(ability)である。例示的なバージョンにおけるメモリ５０の呼び出し制御モジュールは、この通信用のプロトコルを定義する、ローカルセッションイニシエーションプロトコル（ＳＩＰ）とセッション記述プロトコル（ＳＤＰ）アプリケーション６６である。

ＵＤＶＭインタープリタにおいて復元バイトコードを実行することから生じる計算的なオーバーヘッドは、バイトコードにおける各インストラクションが解釈されるとき、遅延を引き起こし、それは、延期呼び出しセットアップ時間のためユーザ経験を損なう(impair)可能性がある。メモリ５０におけるデコンプレッサディスパッチャモジュール６８は、ＵＤＶＭインタープリタ６４の使用を減らすことによる、通信デバイス１４のコンピュータプラットフォーム４８によってサポートされた１つまたは複数の最適化インプリメンテーションによって、この遅延を有効に軽減する。

第１のインプリメンテーションとして、メモリ５０における最適化されたデコンプレッサモジュール７０によって実行されることができるマシンコードへのバイトコード２２の初期のコンパイレーションは、復元アルゴリズムの非常に効率的な実行を提供する、したがって、次のＳＩＰメッセージプロセッシングおよび呼び出しセットアップ時間の待ち時間(the latency of following SIP messages processing and call setup times)を短くする。その目的のために、デコンプレッサディスパッチャモジュール６８は、それぞれが個別の復元マシンコード３６と対になる、１つまたは複数の局所的にアクセス可能なバイトコード２２``と、受信されたバイトコード２２`を比較するために、復元ライブラリ７２にアクセスする。マッチ(match)の検出のとき、復元マシンコード３６は、ＵＤＶＭインタープリタ６４よりもむしろ最適化されたデコンプレッサモジュール７０によって実施されることができる。

第２のインプリメンテーションとして、デコンプレッサディスパッチャモジュール６８がマッチを検出するのに失敗する新しい受信されたバイトコード２２`について、デコンプレッサディスパッチャモジュール６８は、それぞれ復元ライブラリ７２における、空コードストレージレコード７６および空きインデクス７８におけるバイトコード２２`に沿ってそのあとで保存される、復元マシンコード３６を生成するためにメモリ５０のコンパイラ７４を方向づける。このコンパイレーションは、このバイトコード２２`の今後のインスタンスが第１のインプリメンテーションによって取り扱われることができるように、バックグラウンドにおいて生じうる。

第３のインプリメンテーションとして、第２のインプリメントにおけるようにマッチを検出するのに失敗するとき、デコンプレッサディスパッチャモジュール６８は、外部でコンパイルされるべき、あるいは、今後のインスタンスのための復元マシンコードの周期的にアップデートされたデータベースからリトリーブされるべき、バイトコード２２`についてのリクエストを転送する。

第４のインプリメンテーションとして、コンピュータプラットフォーム５８は、復元について最適化されたデバイスハードウェアにおけるパラレル処理(parallel processing)を可能にすることによってより早いセットアップを容易にする、ＵＤＶＭハードウェアプロセッサ（例、デジタル信号プロセッサ（ＤＳＰ））８０を有効に含むことができる。デコンプレッサディスパッチャモジュール６８は、ローカルのＳＩＰ／ＳＤＰアプリケーション６６の利益についてＵＤＶＭ６４をエミュレートする(emulate)ためにプロキシＵＤＶＭ８２を利用する。

図３−６においては、一般に、３ＧＰＰ ＴＳ ２３．３３８、３ＧＰＰ ＴＳ ２３．００２において説明される３ＧＰＰリリース５ネットワークアーキテクチャと一致した(consistent with)通信ネットワーク１００は、図１−２の信号圧縮最適化システム１０のための操作環境を提供する。特に図３を参照すると、通信ネットワーク１００は、コアネットワーク（ＣＮ）インフラストラクチャ１０２と、アクセスネットワーク（ＡＮ）インフラストラクチャ１０４に論理的に分けられる。ＣＮインフラストラクチャ１０２は、回路スイッチされた(Circuit Switched)（ＣＳ）ドメイン１０６、パケットスイッチされた(Packet Switched)（ＰＳ）ドメイン１０８と、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）１１０に、論理的に分けられる。ＵＭＴＳ地上波無線アクセスネットワーク（ＵＴＲＡＮ）インタフェース１０４として図示される、ＡＮインフラストラクチャ１０４は、エレメントが無線ネットワークコントローラ（ＲＮＣ）１１４、ノードＢエレメント１１６、そしてユーザ機器（ＵＥ）１１８である、階層無線ネットワークサブシステム（ＲＮＳ）１１２によって、形成される。ノードＢ１１６は、１つまたは複数のセルをサーブする(serves)論理的なネットワークコンポーネントである。それは、無線セルにおける通信用の、無線伝送／受理ユニットである。ＲＮＣ１１４は、１つまたは複数のノードＢエレメント１１６の制御のための機能を備えたネットワークコンポーネントである。ＲＮＣ１１４は、複数のＵＴＲＡＮインタフェース１０４間で、プロトコル交換を扱っている。ＲＮＣ１１４は、オペレーションサポートシステムへのアクセスを含む（示されていない）、無線ネットワークサブシステム１１２の中心化されたオペレーションおよびメンテナンスを提供する。数ある中で、ＲＮＣ１１４の機能は、無線リソース制御、アドミッション制御、チャネル割り当て(channel allocation)、ハンドオーバー制御を含む。回路スイッチされたドメイン１０６に特有のエンティティは、シグナリングゲートウェイ（ＳＧＷ）１１９、モバイルスイッチングセンタ（ＭＳＣ）１２０、そしてゲートウェイモバイルスイッチングセンタ(Gateway Mobile Switching Centre)（ＧＭＳＣ）１２２を信号で通信している(signaling)。ＣＳスイッチされたドメイン１０６は、さらに、このタイプのシグナリングに条件づけられた(constrained)特定のホーム加入者サービス１２３を含むことができる。ＭＳＣ１２０は、無線ネットワークサブシステム１１２と固定されたネットワークとの間でインタフェースを構成する。ＧＭＳＣ１２２は、モバイル局（ユーザ機器（ＵＥ））１１８の実際のロケーションへのルーティング(routing)を実行するＭＳＣ１２０である。パケットスイッチされたドメイン１０８に特定されたエンティティは、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１２４と、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１２６である。ＳＧＳＮ１２４およびＧＧＳＮ１２６はパケットトラフィック(packet traffic)を扱う。ＳＧＳＮ１２４は、そのサービスエリア内でモバイル局１１８にパケットを運ぶ。ＳＧＳＮ１２４は、1つのセルにおけるユーザ機器１１８から別のセルにおける機器へと、ローミング加入者(roaming subscriber)をハンドオフする(handing off)ような、モビリティマネジメント機能を実行する。ＧＧＳＮｓ１２６は、パブリックインターネット１２８、他のモバイルサービスプロバイダのＧＰＲＳサービス（ホーム加入者サービス（ＨＳＳ））１３０、あるいは、企業イントラネット（示されていない）のような、外部ＩＰネットワークへのインタフェースとして使用される。ＧＧＳＮｓ１２６は、特定のモバイル局１２２をサービスするＳＧＳＮｓ１２４に対して、プロトコルデータユニット（ＰＤＵｓ）のトンネリングする(tunnel)のに必要である、ルーティング情報を維持する。

ＩＭＳコアネットワーク１１０のＩＰマルチメディアサブシステム（ＩＭＳ）エンティティは、モバイルインターネットパラダイム(mobile Internet paradigm)にしたがって、多様なマルチメディアサービスを展開する一般のプラットフォーム(common platform)を作るために、第３世代パートナーシッププロジェクト（３ＧＰＰ）リリース５の一部として導入された。ＩＭＳエンティティは、ＩＰマルチメディア（ＩＭ）サービスの供給のためにすべてのコアネットワークエレメントを備え、それらは、例えば、呼び出しセッション制御機能（ＣＳＣＦ）１３０（すなわち、問い合わせ(Interrogating)、プロキシ、そしてサービング）、ＩＭＳメディアゲートウェイ機能（Media Gateway Function）（ＭＧＷ）１３１、メディアゲートウェイ制御機能（ＭＧＣＦ）１３２、そしてマルチメディアリソース機能１３３である。３ＧＰＰごとのＩＭＳ ＣＮ１１０は、標準化されたインタフェースによって定義されるようにノードよりもむしろ機能を標準化させる。インプリメンタ(Implementers)は、自由に、２つの機能を単一のノードに組み合わせる、あるいは、２つまたは複数のノードに単一の機能を分けることができる。ＩＭＳ ＣＮ１１０は、公衆交換電話網（ＰＳＴＮ）１３４とＨＳＳ１３０のような他のＵＭＴＳネットワークのような他のネットワークへの相互接続同様、音声とマルチメディア呼び出しおよびセッション(voice and multimedia calls and sessions)を制御するドメインである。それは、異なる経路をトラバースする、メディアプレーンとシグナリングプレーンを有する。

ＳｉｇＣｏｍｐはＩＭＳ ＣＮ １１０の一部であり、それはＳＩＰシグナリングトラフィックを圧縮するために使用される。ＩＰマルチメディア（ＩＭ）ドメインは、コスト削減と新しいサービスの導入を可能にする、例えば、ボイス電話方式、ビデオ電話方式、マルチメディア会議、インスタントメッセージング、そしてリアルタイムインタラクティブゲームである。ＩＭＳは、無線ユーザのためのボイス、ビデオ、メッセージング、データおよびウェブベースの技術の収斂(convergence of)およびそれらへのアクセスを可能にし、そして、モバイル通信における成長とインターネットの成長を結合する。ＩＰマルチメディアコアネットワークサブシステム（ＩＭＳ）は、パブリックランドモバイルネットワーク（ＰＬＭＮ）オペレータがインターネットアプリケーション、サービス、およびプロトコルに基づいた、そして、構築した(built upon)それらの加入者マルチメディアサービスをオファすること(offer)を可能にする。マルチメディアシグナリングおよびベアラトラフィック(bearer traffic)をトランスポートするために、パケットスイッチされたドメインを利用する。パケットスイッチされたドメインは、端末が移動しＩＭＳから動きを隠している間、サービスを維持する。ＩＭＳは、回路スイッチされたドメインから独立している。ＩＭドメインは、ユーザとアプリケーションが、マルチプルパーティ間でセッションおよび呼び出しを制御することを可能にする。呼び出しについて必要とされる機能性、セキュリティ、そして質を提供するために、ネットワークリソースを制御し、サポートする。ＩＭドメインは、いずれのＵＭＴＳネットワークからそれらがそれら自体のサービスにアクセスすることができるように、ユーザの登録のために、提供する。ＩＭの1つの追加的な役割は、呼び出し参与者(call participants)についての情報、時間、送信且つ受信されたデータの持続時間および容量を含む、呼び出し詳細レコード(Call Detail Records)（ＣＤＲｓ）を生成することである。ＣＤＲｓは、目的を満たす(charging)ために使用される。

図４においては、３ＧＰＰ ＴＳ ２３．２２８ごとのＩＭＳエンティティは、ＣＳＣＦ、ＭＧＣＦ、ＩＭＳメディアゲートウェイファンクション(IMS Media Gateway Function)（ＩＭＳ−ＭＧＷ）、マルチメディアリソースファンクションコントローラ（ＭＲＦＣ）、マルチメディアリソースファンクションプロセッサ（ＭＲＦＰ）、サブスクリプションロケータファンクション(Subscription Locator Function)（ＳＬＦ）、ブレイクアウトゲートウェイ制御機能（ＢＧＣＦ）およびアプリケーションサーバ（ＡＳ）を含んでおり、なお、ユーザトラフィックをサポートしているインタフェースは、太い線で示されており、シグナリングをサポートしているインタフェースは点線で描かれている。

ＩＭＳエンティティの役割は、３ＧＰＰ ＴＳ ２３．２２８において説明されている。ＳＩＰサーバである、ＣＳＣＦは、プロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、サービングＣＳＣＦ（Ｓ−ＣＳＣＦ）１３８あるいは問い合わせＣＳＣＦ（Ｉ−ＣＳＣＦ）として動作できる。Ｐ−ＣＳＣＦは、ＩＭＳ ＣＮのためのＵＥの第１接点である。ＳｉｇＣｏｍｐメッセージの圧縮および復元を実行するコアネットワークエレメントであるので、ＳｉｇＣｏｍｐに特別に重要である。このために、Ｐ−ＣＳＣＦは、コンプレッサとデコンプレッサを含む（ＩＭＳ端末もまた両方を含んでいる）。Ｉ−ＣＳＣＦの役割が特定のユーザのために適切なＳ−ＣＳＣＦを見つけることである一方で、Ｓ−ＣＳＣＦは、ネットワークにおいてセッションステートを扱う。ＭＧＣＦは、プロトコル転換(conversion)を実行し、帯域情報から受信し、ＣＳＣＦと通信し、ＣＳＣＦを選択し、呼び出しステートの一部を制御する。ＩＭＳ−ＭＧＷは、スイッチされた回路ネットワークからベアラチャネルを、そして、パケットネットワークからメディアストリームを、終わらせる(terminates)。それは、メディア転換、ベアラ制御、そしてペイロード処理を扱う。ＭＲＦＣのタスクは、ＭＲＦＰにおけるメディアストリームリソースを制御し、ＣＤＲｓを生成し、そして、ＡＳとＳ−ＣＳＣＦから来る情報を解釈し、それに応じてＭＲＦＰを制御することである。

ＭＲＦＰは、ＭＲＦＣによって制御されるリソースを提供し、Ｍｂリファレンスの点上でベアラを制御し、メディアストリームをミックスし(mixes)、ソースし(sources)、処理する。登録とセッションのセットアップの間(during)、Ｉ−ＣＳＣＦによってリクエストされるとき、ＳＬＦは、必要とされる加入者特定データを含んでいるＨＳＳの名前を供給する。それはさらに登録プロセスの間に、Ｓ−ＣＳＣＦによってクエリされる。ＢＧＣＦは、ＰＳＴＮブレイクアウトが生じる予定のネットワークを選択し、使用されるＭＧＣＦを選択する。ＡＳは、ＳＩＰアプリケーションサーバ、オープンサービスアクセス（ＯＳＡ）アプリケーションサーバあるいはモバイルエンハンスされたロジックについてのカスタマイズされたアプリケーション(a Customized Application for Mobile Enhanced Logic)(ＣＡＭＥＬ）ＩＰマルチメディアサービススイッチング機能（ＩＭ−ＳＳＦ）であってもよい。それは、ＩＭサービスを加えた値をオファする。Ｓ−ＣＳＣＦとＡＳとの間のインタフェースは、ＡＳにおいて常駐しているサービスを提供するために使用される。

ＩＰマルチメディアサブシステムは、アクセス独立を達成するために、そして、３ＧＰＰ ＴＳ ２３．２２８ごとのインターネットにわたって電話線(wireline)端末を用いて円滑なオペレーションを維持するために、インターネット技術タスクフォース（ＩＥＴＦ）インターネット標準規格に整合(conformant)することを試みる。ＩＭドメインにおいて登録および呼び出し制御のために使用されるシグナリングプロトコルは、セッションイニシエーションプロトコル（ＳＩＰ）である。ＳＩＰは、ＵＥとＣＳＣＦとの間で適用される単一のプロトコルである。

図５においては、端末に送られたメッセージを圧縮し、端末から受信されたメッセージを復元するエンティティは、Ｐ−ＣＳＣＦであり、ＵＥからＳ−ＣＳＣＦまでのＳＩＰシグナリングフローとして描かれている。ＵＥにおいてＳｉｇＣｏｍｐで圧縮されたＳＩＰメッセージは、無線インタフェース、ＵＭＴＳ地上波無線アクセスネットワーク（ＵＴＲＡＮ）の無線ネットワークコントローラ（ＲＮＣ）と基地局（ＢＳ）を通じて流れる(flow)。ＳｉｇＣｏｍｐメッセージが復元される場合、ＵＴＲＡＮから、それらは、サービングＧＰＲＳサポートノード（ＳＧＳＮ）とゲートウェイＧＰＲＳサポートノード（ＳＧＳＮ）を通じて、Ｐ−ＣＳＣＦまでトラバースする。Ｐ−ＣＳＣＦ前方(onwards)から、ＳＩＰメッセージは、非圧縮された状態で送られる。無線アクセスネットワークからよりもむしろネットワークコアから、ＳｉｇＣｏｍｐ圧縮および復元を実行するエンティティを選択することを支持した理由が以下で説明されている。まず初めに、圧縮は、暗号化および暗号解読の点からバウンドして適用されなくてはならず、透過的でなくてはならないので、トラフィック暗号化および暗号解読(decryption)機能のロケーションはさらに、圧縮機能のロケーションに影響を与える。いくつかのトラフィックタイプのパケットコンテンツ(packet content)は、認証されており、完全保護されている、あるいは、暗号化されている。端末からトラフィックを解読し、端末に暗号化する、信頼されたパーティは、モバイルネットワークコアにおいて存在する。もし終点(endpoint)が無線アクセスネットワークから選ばれた場合には、ネットワークデザインおよびパフォーマンスは、モバイルネットワーク内でメッセージキーをトランスファすることによって加えられるであろう複雑さから苦しむであろう。シグナリング圧縮のロケーションに影響を与える別の重要な問題は、ハンドオーバー(handover)である。ＳｉｇＣｏｍｐにおいては、比較的大きい量の史的なステートが、効率的な圧縮を可能にするために確立される(built up)。復元を実行している終点が変わった場合、このステートは、圧縮効率を維持するために新しいエンティティにトランスファされることが必要となるであろう。この種類の解決方法は、ネットワークに複雑さを付け加えるであろう。復元がＰ−ＣＳＣＦにおいて実行されるとき、復元終点(decompressing endpoint)は、アプリケーション層セッションの持続期間について安定したままである。

したがって、ＳｉｇＣｏｍｐ機能のロケーションは、モバイル端末にあり、そしてネットワークの内部にあり、すなわちＩＭＳにある。このアプローチは、ヘッダ圧縮と対比しており、圧縮機能は、端末において、そして、無線アクセスネットワークにおいて、位置づけられている。ＳｉｇＣｏｍｐのケースにおいては、メッセージは、ルーティング情報を含まない、アプリケーションレベルのメッセージである。それらは、トランスポート層プロトコルのペイロードにおいて、搬送され、代わりにＩＰへのルーティング問題を残す(leave)。ＳｉｇＣｏｍｐは、トランスポート層プロトコルのヘッダを圧縮しない。トランスポート層プロトコルペイロードのコンテンツに関心のあるエンティティのみ、すなわち２つの通信している終点は、ＳｉｇＣｏｍｐメッセージを復元する必要がある。

ＳＩＰシグナリングが端末とＰ−ＣＳＣＦの間で圧縮された状態で送られる理由は、無線インタフェースにわたって少しのバイトを節約することではないということは、強調されるべきである。端末がより多くの帯域幅を使用するであろう、マルチメディアセッションを確立するであろうとき、それは少しのバイトのシグナリングを節約するに値しない。圧縮のための主なモチベーションは、無線インタフェースにわたってＳＩＰメッセージを送信することに必要とされた時間を減らすことである。

ＩＭＳにおいては、セッション制御を実行するプロトコルは、セッションイニシエーションプロトコル（ＳＩＰ）である。ＳＩＰは、本来、既存のマルチメディア会議にユーザを招待するために使用されていたが、今日では、それは、主にマルチメディアセッションを作り、修正し(modify)、そして終了するために使用されている。ＳｉｇＣｏｍｐは、いずれのテキストベースのプロトコルのメッセージを圧縮するために使用されることができるけれども、主な焦点は、目下ＳＩＰメッセージの圧縮上にある。

ＳＩＰは、扱われたマルチメディアセッションのタイプから独立しており、そして、セッションを説明するために使用されたメカニズムから独立している。マルチメディアセッションを説明するのにもっとも一般的な(common)フォーマットは、セッション記述プロトコル（ＳＤＰ）である。ＳＤＰは、ＳＩＰメッセージのボディにおいて搬送される、単なるテキストフォーマット(textual format)である。これが、ＳｉｇＣｏｍｐがＳＩＰとＳＤＰの両方を効率的に圧縮することができなくてはならない理由である。ＳＩＰ／ＳＤＰの静的ディクショナリは、この目的のために定義される。

ＳＩＰプロトコルは、いくつかのエンティティを規定しており、それらはユーザエージェント（ＵＡｓ）、リダイレクトサーバ(redirect servers)、プロキシサーバ、レジストラ(registrars)およびロケーションサーバである。ＳＧＰＰリリース５、あるいはのちにリリースする、をサポートしている、すべての３Ｇ端末は、ＳＩＰ ＵＡを含んでいる。さらに３ＧＰＰ２は、ＳＩＰを採用する。ＳＩＰは、ユーザの現在のロケーションへのリクエストをルーティングし、サービスのためにユーザを認証し権利化し、プロバイダ呼び出しルーティングポリシーをインプリメントし、そしてユーザに特徴を提供することを手助けするために、プロキシサーバを利用する。リダイレクトサーバは、ユーザが到達可能かもしれない場合、代替のロケーションを提供することによってＳＩＰ ＵＡｓのロケーションにおいて、手助けする。レジストラは、登録を受諾する(accepts)。それは、大抵、リダイレクトサーバあるいはプロキシサーバで同じ場所に配置される。ロケーションサーバは、ＳＩＰエンティティではないが、ＳＩＰを使用するいずれのアーキテクチャの重要な部分である。ロケーションサーバは、ユーザの可能性のあるロケーションを保存し、戻す。

ＳＩＰは、ハイパーテキストトランスファプロトコル(Hypertext Transfer Protocol)（ＨＴＴＰ）のような、リクエスト／応答プロトコルであり、それに基づいている。ＳＩＰユーザエージェントクライアント（ＵＡＣｓ）は、リクエストを送り、ユーザエージェントサーバ（ＵＡＳｓ）は、レスポンスを戻す。リクエストのスタートラインは、方法名を宣言し、それは、リクエストの目的を指している。

ＳｉｇＣｏｍｐ終点のレイアウトは図５に図示されている。それは、以下のエンティティ：コンプレッサディスパッチャ、１つまたは複数のコンプレッサ、ステートハンドラ、ユニバーサルデコンプレッサ仮想マシン（ＵＤＶＭ）およびデコンプレッサディスパッチャ、を含んでいる。

コンプレッサディスパッチャのタスクは、アプリケーションからメッセージを受信し、トランスポート層に各メッセージの圧縮されたバージョンを受け渡すことである。アプリケーションは、各メッセージと一緒にコンパートメント識別子を、コンプレッサディスパッチャに提供しなければならない。コンパートメントは、ピア終点に関連する、メッセージのグルーピングに特有のアプリケーション(an application specific grouping of messages)である。ＳＩＰのケースにおいては、コンパートメントは、ＳＩＰダイアログに属しているすべてのメッセージによって形成される。コンパートメント識別子は、独自にコンパートメントを識別する。ＳｉｇＣｏｍｐは、パーコンプレッサベースでコンプレッサを呼び出す、それは、コンパートメント識別子がさらにコンプレッサを識別するために使用されることができるということを意味する。このために、コンパートメント識別子とコンプレッサとの間のマッピングは、維持されなくてはならない。アプリケーションメッセージと一緒にコンパートメント識別子を提供することによって、アプリケーションは、コンプレッサディスパッチャは適切なコンプレッサを位置づけることができるということを確実にする。新しいコンパートメント識別子(a new compartment identifier)が出くわされるたびに、新しいコンプレッサが呼び出される。いったんコンプレッサがアプリケーションメッセージを圧縮すると、ＳｉｇＣｏｍｐヘッダは、作られ、それに取り付けられる。この後で、コンプレッサディスパッチャは、トランスポート層にＳｉｇＣｏｍｐメッセージを受け渡すことができる。アプリケーションがコンパートメントをクローズ(close)したいと願うとき、例えばＢＹＥメッセージを受信し、ファイナルレスポンスを送った後で、コンプレッサディスパッチャにこれを示すべきである。

コンプレッサは、アプリケーションメッセージを圧縮するのに使用されるある圧縮アルゴリズムをインプリメントする。ＳｉｇＣｏｍｐの基礎的なアイデアのうちの一つは、標準規格がすべての終点によって使用されるべき１つの圧縮アルゴリズムの使用をディクテートしていないということである。代わりに、アルゴリズムの選択は、インプリメンテーションの決定として残されている。次に続くのは、各終点が様々な圧縮アルゴリズムの出力を復元することができるべきであるということである。これは、復元機能性を処理する仮想マシンの使用によって可能になる。コンプレッサが圧縮されたアプリケーションメッセージを含んでいるＳｉｇＣｏｍｐメッセージを作るとき、それは、メッセージのヘッダへの復元アルゴリズムを含む。この復元アルゴリズムは、バイトコードと呼ばれており、そして、それは、仮想マシン上で実施されることができる形態にコンパイルされてきた。

多くの必要条件は、コンプレッサ上に置かれる。まず初めに、それは、透過的(transparent)でなくてはならない（例、コンプレッサは、ＵＤＶＭがＳｉｇＣｏｍｐメッセージを不正確に復元するようにさせる、バイトコードを送らない）。コンプレッサは、成功復元が生じることを確実にするために、アプリケーションメッセージにわたって、完全チェック(integrity check)のいくつかの形態を供給するべきである。メッセージが、遠隔終点で、利用可能なリソースを使用して、復元されることができるということを確実にしなければならない。トランスポートがメッセージベースである場合、それがユーザデータグラムプロトコル（ＵＤＰ）のケースにおけるとき、コンプレッサは、確実に１つのＳｉｇＣｏｍｐメッセージに、各アプリケーションメッセージをマッピングしなくてはならない。トランスポートがストリームベースであり、しかしアプリケーションがそれ自体の内部のメッセージの境界を定義する場合、コンプレッサは、確実に１つのＳｉｇＣｏｍｐメッセージに各アプリケーションメッセージをマッピングするべきである。

デコンプレッサディスパッチャの役割は、トランスポート層からＳｉｇＣｏｍｐメッセージを受信し、各メッセージを復元するためにＵＤＶＭの新しいインスタンスを呼び出しし(invoke)、そして、アプリケーションに結果として生じる非圧縮されたメッセージを受け渡すことである。いったんアプリケーションがメッセージを受信すると、それは、コンパートメントにメッセージをマッピングし、デコンプレッサディスパッチャにコンパートメントの識別子を戻す。デコンプレッサディスパッチャは、そのあと、ステートハンドラに識別子を渡し、それは、ステート情報を節約し、適切なコンプレッサに対してフィードバック情報を転送する(forward)ために識別子を使用する。コンパートメント識別子を供給することによって、アプリケーションは、これをするための許可をディスパッチャに承諾する(grants)。

ユニバーサルデコンプレッサ仮想マシン（ＵＤＶＭ）は、ＳｉｇＣｏｍｐメッセージを復元するエンティティである。復元プロセスは、仮想マシン上でバイトコードと呼ばれる、特別コンパイルされたプログラムを実行することにより行なわれる。ＵＤＶＭは、大いにＪａｖａ（登録商標）仮想マシンのような仮想マシンであるが、復元アルゴリズムを実行するために最適化されたという違いを備えている。ＳｉｇＣｏｍｐのケースにおいては、バイトコードにコンパイルされたソースコードは、ＵＤＶＭアセンブリ(UDVM assembly)と呼ばれ、エンティティのコンパイリング(the entity compiling)はＵＤＶＭインタープリタと呼ばれる。バイトコードは、ＵＤＶＭのマシン言語として考えられることができる。

ＵＤＶＭは、どのように与えられたアプリケーションメッセージを圧縮するかを選択するとき柔軟性を提供する：コンプレッサインプリメンタは、彼の選択のアルゴリズムを選択する自由を有する。圧縮されたデータは、１セットのＵＤＶＭインストラクションを含んでいるバイトコードで結合されている。これらのインストラクションは、ＳｉｇＣｏｍｐメッセージのヘッダにおいて搬送され、そして、それらは、オリジナルデータが受信終点で展開されること(extracted)を可能にする。

ＳｉｇＣｏｍｐは非保護されたトランスポート層上で実行できるので、ＵＤＶＭの分離したインスタンス(separate instance)は、損害をうけたメッセージがより後のメッセージの復元に影響を与えないということを確実にするためにパーメッセージ基準(a per-message basis)上で呼び出される。しかしながら、復元プロセスの間に、ＵＤＶＭは、既存のステートにアクセスするようにステートハンドラを呼び出すことができる。この方法で、前のメッセージを復元したＵＤＶＭインスタンスのステートは、より後のＵＤＶＭインスタンスによって再記憶される(restored)ことができる。

ＵＤＶＭは初期化されるとき、ＵＤＶＭは、デコンプレッサディスパッチャから追加の圧縮されたデータ、あるいはステートハンドラからステート情報を、リクエストのときのみ、受信できる。復元が行なわれると、ＵＤＶＭは、復元されたデータを、デコンプレッサディスパッチャに出力する。それがメッセージの終わりに出くわすとき、それは、ディスパッチャにこのことを示し、コンパートメント識別子でそれを提供する。この識別子は、ステート作成リクエストにおいてステートハンドラに受け渡される。ステートハンドラは、対応するコンパートメントのためにリザーブされるステートメモリのロケーションにおいて、ステート情報を記憶するために、コンパートメント識別子を使用する。ＵＤＶＭはさらに、ステートハンドラにＳｉｇＣｏｍｐメッセージにピギーバック方式で輸送されることができるフィードバック情報を転送する。

ＵＤＶＭサイクルは、ＵＤＶＭインストラクションを実行するのに必要とされるＣＰＵパワーの量の測度(measure)である。ＵＤＶＭサイクル限度は、ＳｉｇＣｏｍｐメッセージにおいてビットごとに復元するために使用されることができるＵＤＶＭサイクルの数を制限する(restrict)ために使用される。悪意のあるユーザはルーピングコードを含んでいるバイトコードを送る可能性があるので、バイトコードが使用するサイクルの量は、モニタされなくてはならない。しかしながら、サイクル限度は、生じうるダメージの量をただ減らすが、問題を取り去らない。

ＳｉｇＣｏｍｐにおいては、デコンプレッサメモリのサイズは交渉できる(negotiable)。復元側は、圧縮側にデコンプレッサメモリのサイズを通知する(advertises)。デフォルトのサイズは２キロバイトである。圧縮の効率を改善するために、４あるいは８キロバイト、あるいはそれ以上のキロバイトのメモリサイズが、使用されることができる。デコンプレッサメモリは、２つのセクションに分かれており、そのうちの最初のセクションは、復元されたメッセージを記憶するために使用される。他のセクションは、ＵＤＶＭがバイトコードおよびサーキュラーバッファ(circular buffer)を保持するために使用されており、ＵＤＶＭメモリのよりも大きいステートの使用を可能にする。このことは、バッファが満たされるとすぐに、ＵＤＶＭはバッファの初めにコンテンツに上書きすることを開始できるので、可能である。

ＵＤＶＭの分離したインスタンスが、到達する各メッセージを復元するために呼び出されるので、メッセージ間で情報を保持する(retain)ための方法が必要とされる。これはＳｉｇＣｏｍｐステートハンドラのタスクであり、受信されたＳｉｇＣｏｍｐメッセージ間の情報を保存する。ステートハンドラのおかげで、メッセージが前のメッセージにおいて含まれる情報に関して圧縮されることができるので、圧縮比は、改善される。ステートハンドラは、より後のメッセージが復元されているとき、アクセスのためのステートアイテムを作ることを可能にする。ステートアイテムは、典型的に、非圧縮されたメッセージあるいはＵＤＶＭインスタンスのメモリのスナップショットのいずれかを含んでいる。

ステートハンドラは、パーコンパートメント基礎上でステートメモリを管理する。ステートアイテム自体を保存すること同様、それは、特定のコンパートメントによって作成されたステートアイテムのリストを維持し、そして、どんなコンパートメントもその割り当てられたメモリを超えないということを確実にする。

ＵＤＶＭインタープリタは、ＵＤＶＭインストラクションとＵＤＶＭアセンブリにリストされたそれらのオペランドを、バイトコード形式に翻訳するエンティティである。ＵＤＶＭインタープリタは、入力として、ＵＤＶＭアセンブリソースコードを含んでいるファイルを捉え、そして、それをバイトコードにコンパイルする、それは、仮想マシン上で実施されることができる。

信号圧縮最適化システム１０の動作環境を説明した状態で、信号圧縮最適化方法４００は図７において、図示されている。明瞭にするために、方法は、ブロック４１４−４２０の通信デバイス（受信者）部分が後で続く、ブロック４０２−４１２の通信ネットワーク（広める）部分に、連続して分離される。方法が複数のエンティティを含んでいるということと、そして、圧縮されたＳＩＰ／ＳＤＰデータコンテンツの伝播(dissemination)は、通信デバイスから通信ネットワークにさらに送られることが出来るということと、を理解されるべきである。さらに、通信ネットワークあるいは通信デバイスは、そのようなエンティティの様々な組み合わせにおいて、開始し、リレーし、終了する、伝播を備えた複数のエンティティを表わすことができる。

ブロック４０２で始まり、通信ネットワークは、受信通信デバイスのハードウェア／ソフトウェアコンフィギュレーションを得ることによって、信号圧縮最適化システム１０の態様を有効に進める(advances)ことができる。このことは、可能性のある通信デバイスの世界(universe)上で最新状態(up to date)のままであることを意図されている包括的なデータベースを必要とし得るであろう、あるいは、ここに開示される信号圧縮最適システム１０の他の態様をサポートするそれらに特に集中される。このデータは、ＯＥＭ製造業者(Original Equipment Manufacturers)（ＯＥＭ）によって供給されることができる、あるいは、このような通信デバイスの母集団(population)をサポートする、個別の通信デバイスあるいは階層型エンティティ(individual communication devices or hierarchical entities)とのＳＩＰ／ＳＤＰ通信を介して、インタラクティブに(interactively)得られることができる。ブロック４０４においては、対応する復元ソースコード（バイトコード）にそって、信号圧縮アルゴリズムは選択される。このような選択は、受信者通信デバイス（単数または複数）がＵＤＶＭを呼び出すことを通信デバイスに期待するよりもむしろバイトコードの実行可能なバージョンにローカルアクセスを有するかどうかを知って、有効になされうる。ブロック４０６においては、通信ネットワークは、実行可能なマシンコードを作るために、得られたハードウェア／ソフトウェアのコンフィギュレーションと一致した(consistent with)バイトコードをコンパイルする。このようなコンパイレーションは、リクエストを待ち、そして、そのあと、すぐに送信されることができる。図示されたシーケンスにおいて、ブロック４０８においては、このコンパイレーションは、リクエストの前に終わっており、リクエストのときに、伝播のためのコンフィギュレーションとバイトコードにしたがって、インデクスがつけられる(indexed)。

データコンテンツ（例えば、マルチメディアコンテンツおよび／またはシグナリング）は、ブロック４１０において、圧縮アルゴリズムにしたがって圧縮される。圧縮されたデータコンテンツは、そのあと、データコンテンツ（例えばマルチメディア、シグナリングなど）を復元する通信デバイス（モバイル端末）で解釈に適切である、選択されたソースコード（「バイトコード」）に沿って、データパケットプロトコルに従って送信される。例示的なインプリメンテーションおいては、ブロック４１２では、通信ネットワークは、選択されたソースコード（バイトコード）に沿って、データパケットプロトコルに従って圧縮されたデータコンテンツを、無線で送信する。

ブロック４１４においては、通信デバイスは、伝送を無線で受け取る。ブロック４１６では、伝送されたバイトコードが検出される。ブロック４１８においては、検出されたバイトコードに関連づけられた復元コードのアクセス可能で実行可能なバージョンは、仮想マシン上のバイトコードのより遅い解釈を回避して、位置づけられる。実行可能なバージョンにアクセスすることは、今後の使用のためにストレージで実行の前に、ローカルのコンパイレーションあるいは遠隔のコンパイレーションを必然的に伴うことができる。実行可能なバージョンは、ＵＤＶＭインタープリタの使用を避けるために、ハードウェア最適化されたデコンプレッサの他のタイプあるいはデジタル信号処理を使用することを必然的に伴うことができる。ブロック４２０においては、圧縮されたデータコンテンツは、そのあと、アクセス可能で実行可能なバージョンを使用して、復元される。

図８−１１においては、図７の方法の４つの特別のインプリメンテーションが図示されている。第１に、図８においては、信号圧縮最適化装置５００は、使用されるべき１つのセットの圧縮アルゴリズムがあらかじめ知られているという仮定の上で作られ、これらの復元アルゴリズムのためのマシンコードインプリメンテーションでプロビジョンすることによって、モバイル端末５０２へと組み込まれる。モバイル端末５０２上で実行されるシグナリング圧縮（ＳｉｇＣｏｍｐ）最適化のオペレーション５０４は、ブロック５０６において、プロキシ呼び出し／セッション制御機能（Ｐ−ＣＳＣＦ）５１０によって通信チャネル５０８上で送信されたＳｉｇＣｏｍｐメッセージに沿って検出された復元バイトコードを比較できる。ブロック５１２において、ＳｉｇＣｏｍｐ最適化のオペレーション５０４が正確なマッチ(exact match)が検出されるということを決定する場合、そのときには、ブロック５１４においてマシンコード復元が実行される。ブロック５１２において正確なマッチが決定されなかった場合には、そのときには、ブロック５１６においてユニバーサルデコンプレッサ仮想マシン（ＵＤＶＭ）インタープリタは、復元のためのバイトコード上で呼び起こされる。ローカルＳＩＰ／ＳＤＰアプリケーション５１８は、Ｐ−ＣＳＣＦによって最初に(initially)圧縮されたプレーンのＳＩＰ／ＳＤＰメッセージ(plain SIP/SDP messages)を受信する。したがって、もしアルゴリズムがブロック５１２において認識されないＰ−ＣＳＣＦ５１０（例えば、ローミングの間に、あるいはネットワークアップグレードの後で）によって送られる場合、モバイル端末５０２は、標準ＵＤＶＭインタープリタをまだ実行することができるであろう。

図９において、代替的な信号圧縮最適化装置６００は、プリコンパイルされたアルゴリズムのリストでＰ−ＣＳＣＦ６１０から通信チャネル６０８にわたって受信された復元バイトコードをブロック６０６において比較するＳｉｇＣｏｍｐ最適化オペレーション６０４による“ジャストインタイム”のコンパイレーションを必然的に伴う。もしバイトコードがブロック６１２においてマッチであるとわかった場合、そのときには、プリコンパイルされたアルゴリズムの関連づけられたマシンコードは、復元のためにブロック６１４において使用される。ブロック６１２でマッチが見つからなかった場合には、そのときは、ローカルＳＩＰ／ＳＤＰアプリケーション６１８に対してプレーンのＳＩＰ／ＳＤＰメッセージを提供するいずれかの事象において、バイトコードは、マシンコードにブロック６１６でコンパイルされ、そのあと、ブロック６１４が実行される。したがって、このバイトコードはいったんコンパイルされ、そして、すべての以下のセッションイニシエーションプロトコル（ＳＩＰ）メッセージの復元のために使用される。図９においては、ＵＤＶＭの使用は、コンパイレーションが実行されるまで待機することによって回避される。この方法は、ターゲット上でバイトコードコンパイレーション機能を必要とする。１つの第１メッセージの後のすべてのメッセージ(All the messages after the first one)は、ＵＤＶＭインタープリタコードを実行することによって引き起こされたであろう、いずれの処理の非効率を経験しない(do not suffer)。代替的に、コンパイレーションは、現在の通信のためのＵＤＶＭインタープリタを呼び起こしている間、今後の使用のためにバックグラウンドにおいて生じてもよい。

図１０においては、別の代替的な信号圧縮最適化装置７００は、バイトコードのコンパイルされたバージョンの使用を拡張し、しかし、ターゲット上でバイトコードをコンパイルする代わりに、マシン（例、コンパイルされた）コードは、ネットワークによって送られる。このマシンコードが該モバイル(mobile in question)に互換性(compatible)があるということを確実にするために、ネットワーク（ＳｉｇＣｏｍｐサーバ７２０）は、チャネル７０８を介してＳＩＰメッセージング機能を使用してモバイル端末７０２のハードウェア／ソフトウェアバージョンの番号を最初にチェックできる。別のことばに言い換えると、ネットワークは、モバイル局のハードウェア／ソフトウェア（ＨＷ／ＳＷ）(hardware/software)にしたがって、モバイル局に送るべき必要のある適切なマシンコードを選択する。受信されたマシンコードは、同じマシンコードの後続の再伝送を回避するためにモバイル局の永続メモリ(permanent memory)上で保存されることができる。その目的に、ブロック７０６におけるＳｉｇＣｏｍｐ最適化オペレーション７０４は、Ｐ−ＣＳＣＦ７１０から(form)通信チャネル７０８にわたって受信された復元バイトコードを比較する。バイトコードマッチがブロック７１２において決定される場合、そのときは、プリコンパイルされたマシンコードは、ブロック７１４で実行されることができる。ブロック７１２においてマッチが見つからなかった場合は、そのときは、バイトコードのプリコンパイルされたバージョンは、ＳｉｇＣｏｍｐサーバ７２０からリクエストされ、そして、バイトコードはリストに加えられる（ブロック７１６）。マシンコードは、ローカルＳＩＰ／ＳＤＰアプリケーション７２２に対してプレーンのＳＩＰ／ＳＤＰメッセージを供給するために、ブロック７１４において復元を達成する実行について、そのとき、利用可能となる。

図１１においては、さらに追加の代替的な信号圧縮最適化装置８００は、デコンプレッサディスパッチャ８０４がＰ−ＣＳＣＦ８０８から通信チャネル８０６を介して復元バイトコードでＳｉｇＣｏｍｐメッセージを受信する、モバイル端末８０２を有する。モバイル端末８０２は、最適化されたハードウェアプロセッサ８１０を利用する。プロキシＵＤＶＭ８１２は、特定のバイトコードでハードウェアプロセッサ８１０をプログラムし、そのあと、ハードウェアプロセッサ８１０における復元のためのＳｉｇＣｏｍｐを送る。ハードウェアプロセッサは、ＵＤＶＭ解釈のためにプログラムされた汎用目的のＤＳＰあるいは専用アクセレータのいずれであってもよい。プレーンのＳＩＰ／ＳＤＰメッセージは、そのあと、ローカルＳＩＰ／ＳＤＰアプリケーション８１２によって利用される。

このシステムおよび方法は、Ｐ−ＣＳＣＦサーバの処理必要要件を減らすためにネットワークサイドに、さらに、適用されることができる。

インプリメンテーション。様々なインプリメンテーションが可能である。いくつかの進んだインプリメンテーション、例えばネットワークがモバイル局に対してプリコンパイルされた復元バイナリ(pre-compiled de-compression)を送る方法は、インフラストラクチャベンダー(infrastructure vendor)からいくつかのサポートを必要とするであろう、したがって、標準化のいくつかの形式を必要とするであろう。したがって、いくつかのインプリメンテーションにおいては、例えば３ＧＰＰ／３ＧＰＰ２あるいはＩＥＴＦ（インターネット技術タスクフォース）標準規格団体によって促進されるもののような標準規格において、ここに開示されている方法および装置の特徴のうちの少なくともいくつかを含むことは、適切であるかもしれない。

実験結果。ＵＤＶＭのパフォーマンスのいくつかのベンチマーキングを実行した後で、以下が観察される：（１）ＵＤＶＭインタープリタは、本来の復元アルゴリズムと比較して、約２０倍遅く、ＳＩＰメッセージを復元する。（２）ＵＤＶＭがクァルコムＭＳＭ６８００チップセット上の通常の呼び出しセットアップの間、ＳＩＰメッセージを復元するのにかかる時間は、ほとんどアイドルのセントラルプロセッシングユニット（ＣＰＵ）上で約１００ｍｓである。この時間は、事前の呼び出しセットアップのシナリオ、例えばＰＲＡＣＫの使用（すなわち、仮レスポンスの受信を認識するＳＩＰ方法）、あるいはサービスの質(Quality of Service)（Ｑｏｓ）前提条件、で増える。（３）圧縮効率を改善する、よりよい圧縮アルゴリズムの導入は、いちじるしくＵＤＶＭ復元時間を増やすであろう。要約するために、本発明は、ＣＰＵロードあるいは複雑なＳＩＰ呼び出しセットアップフローのケースにおいて、少なくとも１００ｍｓあるいはそれ以上だけ、呼び出しセットアップ時間を、潜在的に減らすことができる。

図１２−１３は、ＳＵＲＦ６８００加入者ユニットリファレンスデザインボード上で簡単なＵＤＶＭアルゴリズムについてのパフォーマンス結果を図示する。特に、図１２−１３は、それぞれ、静的ＤＥＦＬＡＴＥおよびＬｅｍｐｅｌ−Ｚｉｖ−Ｓｔｏｒｅｒ−Ｓｚｙｍａｎｓｋｉ（ＬＺＳＳ）復元アルゴリズムのチャートである。ＬＺＳＳおよびＤＥＦＬＡＴＥのアルゴリズムは、標準であり、圧縮システムで知られている。ＤＥＦＬＡＴＥは、Ｌｅｍｐｅｌ−Ｚｉｖ１９７７（ＬＺ７７）アルゴリズムおよびホフマン符号化の組み合わせを使用する損失のないデータ圧縮アルゴリズムであり、そして、ＰＫＺＩＰファイル保管ツール(PKZIP archiving tool)のバージョン２について、フィルカッツによって当初は定義され、ＲＦＣ１９５１において、のちに規定された。ＬＺＳＳ圧縮がベンチマーキングのために使用されるアルゴリズムのうちの１つであったけれども、本発明は、いかなる特定の圧縮アルゴリズムを必要としない。例示的な候補(candidate)は、動的ＤＥＦＬＡＴＥである。しかしながら、ＤＥＦＬＡＴＥアルゴリズムの複雑さは、ＬＺＳＳの複雑さよりも大きく、パフォーマンス削減がＤＥＦＬＡＴＥインプリメンテーションにおいてより大きくなるであろうということを意味している。

ここに開示された態様に関連して、様々な説明のための論理、論理ブロック、モジュールおよび回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）あるいは他のプログラマブル論理コンポーネント、ディスクリートゲートあるいはトランジスタロジック、ディスクリートハードウェアコンポーネント、あるいはここに説明された機能を実行するように設計されたそれらの任意の組み合わせで、インプリメントあるいは実行されることができる。汎用プロセッサは、マイクロプロセッサであってもよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、あるいはステートマシン(state machine)であってもよい。プロセッサはまた、コンピューティングコンポーネント(computing components)の組み合わせ、例えば、ＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと併用しての１つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成、としてインプリメントされてもよい。

さらに、ここに開示された実施形態に関連して説明された方法あるいはアルゴリズムのステップは、ハードウェアにおいて、プロセッサによって実行されたソフトウェアモジュールにおいて、あるいはこれら２つの組み合わせにおいて、直接的に具現化されることができる。例えば、方法のステップは、個別の方法ステップを実行することが動作可能なプロセッサの１つまたは複数のモジュールにおいて具現化されることができる。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭあるいは当技術分野において知られている記憶メディアの任意の他の形態において常駐する(reside)ことができる。例示的な記憶メディアは、プロセッサが記憶メディアから情報を読み取ることができ、また記憶メディアに情報を書き込むことができるように、プロセッサに結合される。別の方法では、記憶メディアは、プロセッサと一体化していてもよい。プロセッサと記憶メディアは、ＡＳＩＣにおいて常駐していてもよい。ＡＳＩＣは、ユーザ端末に常駐していてもよい。代替として、プロセッサと記憶メディアは、ユーザ端末におけるディスクリートコンポーネントとして常駐することができる。さらに、例えば、アルゴリズムあるいは方法のステップは、コンピュータが個別の方法のステップを実施するようにさせることが動作可能な１つまたは複数のセットのインストラクションを有しているコンピュータ可読メディア、を備えているコンピュータプログラムプロダクトにおいて具現化されることができる。

図１に戻って参照すると、通信ネットワーク１２は、いずれのデータおよび／または音声通信ネットワークを備えることができる。例えば、通信ネットワーク２８は、いずれの1つあるいはいずれの組み合わせのすべてあるいはいくつかの部分：有線のあるいは無線の電話ネットワーク、地上波電話ネットワーク、衛生電話ネットワーク、赤外線データ協会(Infrared Data Association)（ＩｒＤＡ）ベースのネットワークのような赤外線ネットワーク、短距離無線ネットワーク、Ｂｌｕｅｔｏｏｔｈ（Ｒ）（登録商標）技術ネットワーク、ＺｉｇＢｅｅプロトコルネットワーク、ウルトラ広域（ＵＷＢ）プロトコルネットワーク、ホーム無線周波数(a home radio frequency)（ＨｏｍｅＲＦ）ネットワーク、共有された無線アクセスプロトコル(shared wireless access protocol)（ＳＷＡＰ）ネットワーク、無線Ｅｔｈｅｒｎｅｔ（登録商標）ケイパビリティ協会(wireless Ethernet compatibility alliance)(ＷＥＣＡ)、無線フィディリティ協会(wireless fidelity alliance)(Ｗｉ−Ｆｉ協会)ネットワーク、そして８０２．ｘｘネットワークのような、広域ネットワーク、パケットデータネットワーク、データネットワーク、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワーク、公衆交換電話網、インターネットのような公共異種通信ネットワーク、プライベート通信ネットワーク、カリフォルニア州のサンディエゴのクアルコム社から入手可能であるメディアＦＬＯ（ＴＭ）システムを含んでいる、順方向リンク専用(Forward Link Only)（ＦＬＯ）ネットワークのようなマルチキャストネットワーク、衛星用のＤＶＢ−Ｓ、ケーブル用のＤＶＢ−Ｃ、地上波テレビ用のＤＶＢ−Ｔ、ハンドヘルドのための地上波テレビ用のＤＶＢ−Ｈのような、デジタルビデオブロードキャスティング(digital video broadcasting)（ＤＶＢ）ネットワーク、そして、ランドモバイル無線ネットワーク、を備えることができる。

さらに、通信ネットワーク２８のいくつかの態様に含まれることができる電話ネットワークの例は、符号分割多元接続（ＣＤＭＡ）、広帯域符号分割多元接続（ＷＣＤＭＡ）、ユニバーサルモバイルテレコミュニケーションシステム(Universal Mobile Telecommunications System)（ＵＭＴＳ）、アドバンスドモバイル電話サービス(advanced mobile phone service)（ＡＭＰＳ），時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交周波数分割多元接続（ＯＦＤＭＡ）、モバイル通信のためのグローバルシステム（ＧＳＭ）、単一キャリア（１Ｘ）無線伝送技術（ＲＴＴ）、エボリューションデータ専用（ＥＶ−ＤＯ）技術、汎用パケット無線サービス（ＧＰＲＳ）、増データＧＳＭ環境(enhanced data GSM environment)（ＥＤＧＥ）、ハイスピードパケット接続（ＨＳＰＡ）、アナログおよびデジタル衛星システム、そして、データ通信ネットワークと無線通信ネットワークのうち少なくとも1つにおいて使用されることができるいずれの他の技術／プロトコルのような、アナログおよびデジタルネットワーク／技術のいずれの組み合わせ、あるいは、ひとつの少なくとも１部分を含んでいる。

様々な開示された態様が図示され説明されてきた一方で、このドキュメントの主題の事柄がこれらの態様のみに限定されていないということが明らかとなるであろう。

例えば、簡明にするために、通信デバイス１４は、マルチメディアコンテンツ１６を受信して（復元して）図示されている。本発明の態様と一致したアプリケーションは、そのようなマルチメディアコンテンツのリバースあるいは２方法の伝送を必然的に伴う。例えば、静止イメージあるいはビデオカメラによって生成された、あるいは、そうでなければ通信デバイス１４上で保存されたマルチメディアコンテンツは、通信ネットワーク１２にアップロードされることができる。さらに通信ネットワーク１２は、これからは通信デバイス１４にマルチメディアコンテンツ１６を送信するための対応する圧縮アルゴリズムおよび同じバイトコードを利用するために、通信デバイス１４によって供給されたバイトコードを検出することにすぐ反応することができる。それによって、通信デバイス１４は、ＵＤＶＭインタープリタ６２に頼ることなく、最適化された復元技術がサポートされる、マルチメディアコンテンツ１６を受信する可能性を増大することができる。

したがって、以上の開示は説明のための態様を示すが、様々な変更および修正が、添付された請求項によって定義されるように、説明された態様の範囲から逸脱することなく、ここになされることができる、ということが注意されるべきである。さらに、説明された態様のエレメントは、単数で、説明され、あるいは請求項で記載されているかもしれないが、単数への限定が明確に述べられていない限り、複数も意図されている。

さらに、特定の特徴がいくつかのインプリメンテーションのうちの１つのみに関して開示されてきたが、このような特徴は、いずれの与えられたあるいは特定のアプリケーションについて望まれ、利点があるような、他のインプリメンテーションの１つまたは複数の他の特徴と結合されることができる。用語「含む(includes)」および「含んでいる(including)」およびそれらの変形が詳細な説明あるいは特許請求の範囲のいずれかにおいて使用される限り、これらの用語は、用語「備えている(comprising)」と同様な方法で包括的であるように意図されている。さらに、詳細な説明あるいは特許請求の範囲のいずれかにおいて使用される、用語「あるいは(or)」は、「非排他的、または(non-exclusive or)」であることを意味している。

さらに、説明された態様および／またはバージョンのエレメントは、単数で、説明され、あるいは請求項で記載されているかもしれないが、単数への限定が明確に述べられていない限り、複数も意図されている。さらに、いずれの態様および／またはバージョンの全部あるいは一部は、そのように述べられなければ、いずれの他の態様および／またはバージョンの全部あるいは一部で、利用されることができる。

Claims (25)

1. 複数の圧縮アルゴリズムのうちの選択された1つによって圧縮されたデータコンテンツを通信する方法であって、記圧縮アルゴリズムのそれぞれは、前記圧縮されたデータコンテンツから前記データコンテンツを作ることができる、対応する復元アルゴリズムを有しており、データパケットプロトコルを介してトランスファされた前記圧縮されたデータコンテンツは、前記対応する復元アルゴリズムを実行するために、解釈に適切な復元ソースコードをトランスファする、少なくとも１つのメッセージを備えており、前記データパケットプロトコルは、前記圧縮されたデータコンテンツを含んでいる少なくとも１つのメッセージをさらに備えており、前記方法は、
   前記少なくとも１つのメッセージにおいて前記ソースコードを検出することと、
   前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づけることと、
   前記対応する復元アルゴリズムの前記位置づけられたアクセス可能で実行可能なバージョンを利用している、前記圧縮されたデータコンテンツを復元することと、
   を備えている、
   方法。
2. 前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能なバージョンを位置づけることを失敗したことに応じて、前記圧縮されたデータコンテンツを復元するために、前記対応するソースコードを解釈するように仮想マシンを呼び出すこと、をさらに備えている請求項１に記載の方法。
3. 前記対応するソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能な実行可能なバージョンを位置づけることを失敗したことに応じて、マシンコードへと、前記検出されたソースコードをコンパイルすることと、
   前記検出されたソースコードによってインデクスがつけられた前記マシンコードを含んでいるアクセス可能なデータストラクチャを作ることと、
   をさらに備えている請求項１に記載の方法。
4. 遠隔エンティティから前記検出されたソースコードの実行可能なバージョンをリクエストすることと、
   前記遠隔エンティティから前記検出されたソースコードの前記実行可能なバージョンを受け取ることと、
   をさらに備えている請求項１に記載の方法。
5. 前記実行可能なバージョンが充てられた、意図されたプロセッサのコンフィギュレーションを確かめることと、前記意図されたプロセッサのための前記ソースコードをコンパイルすることと、をさらに備えている請求項４に記載の方法。
6. 前記検出されたソースコードからインストラクションを送り、第２のプロセッサに前記圧縮されたデータコンテンツを送る、第１のプロセッサにおいて、プロキシ仮想マシンを呼び出すことと、
   前記第２のプロセッサによって復元された前記データコンテンツを表わすことと、
   をさらに備えている請求項１に記載の方法。
7. 前記ソースコードを検出することと、前記圧縮されたデータコンテンツを復元することをさらに備えることは、第３世代パートナーシッププロジェクト（３ＧＰＰ）パケットデータのトランスポートの一部として、データパケットプロトコルの一貫した信号の圧縮（ＳｉｇＣｏｍｐ）を受信し復元すること、を備えている請求項１に記載の方法。
8. 前記データコンテンツは、マルチメディアあるいはシグナリングコンテンツを備えており、ユーザに認識可能な形において前記データコンテンツを表すことをさらに備えている、請求項１に記載の方法
9. 前記データパケット通信を無線で受け取ること、をさらに備えている請求項１に記載の方法。
10. 前記セッションイニシエーションプロトコル／セッション記述プロトコル（ＳＩＰ／ＳＤＰ）データパケット通信を受信すること、をさらに備えている請求項１に記載の方法。
11. 圧縮されたインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）データコンテンツを受け取るための、復元バイトコードでデータパケット通信チャネルに加えられた装置、であって、前記装置は、
    前記復元バイトコードの実行可能なバージョンと、
    前記復元バイトコードを検出し、前記復元バイトコードの前記実行可能なバージョンにアクセスする、デコンプレッサディスパッチャと、
    プレーンのＳＩＰ／ＳＤＰメッセージに前記圧縮されたＩＭＳデータコンテンツを処理するために、前記復元バイトコードの前記実行可能なバージョンを実行する、最適化されたデコンプレッサと、
    前記プレーンのＳＩＰ／ＳＤＰメッセージを受信するための、ローカルセッションイニシエーションプロトコル／セッション記述プロトコル（ＳＩＰ／ＳＤＰ）アプリケーションと、
    を備えている装置。
12. ユニバーサルデコンプレッサ仮想マシン（ＵＤＶＭ）、をさらに備えており、前記デコンプレッサディスパッチャは、前記第１の実行可能なバージョンに関連づけられていない第２の復元バイトコードを受信することに応じて前記復元バイトコードを解釈するように前記ＵＤＶＭを呼び出す、請求項１１に記載の装置。
13. コンパイラ、をさらに備えており、前記デコンプレッサディスパッチャは、前記第１の復元バイトコードよりもむしろ前記第２の復元バイトコードを検出することに応じて、第２の復元バイトコードに関連づけられた第２の実行可能なバージョンを生成するように、前記コンパイラを指図する、請求項１１に記載の装置。
14. ネットワークデバイスは、前記装置とＳＩＰ／ＳＤＰ通信中であり、前記デコンプレッサディスパッチャは、前記第１の復元バイトコードよりもむしろ前記第２の復元バイトコードを検出することに応じて、第２の復元バイトコードに関連づけられた第２の実行可能バージョンをリクエストし、受信する、請求項１１に記載の装置。
15. プロキシユニバーサルデコンプレッサ仮想マシン（ＵＤＶＭ）と、
    前記圧縮されたＩＭＳデータコンテンツを復元するために、そして、前記復元バイトコードを解釈するために、前記プロキシＵＤＶＭにインタフェース接続されたＵＤＶＭインプリメントされたハードウェアと、
    をさらに備えている請求項１１に記載の装置。
16. 複数の圧縮アルゴリズムのうちの選択された1つによって圧縮されたデータコンテンツを通信するようにコンフィギュアされた少なくとも１つのプロセッサであって、前記圧縮アルゴリズムのそれぞれは、前記圧縮されたデータコンテンツから前記データコンテンツを作ることができる、対応する復元アルゴリズムを有しており、データパケットプロトコルを介してトランスファされた前記圧縮されたデータコンテンツは、前記対応する復元アルゴリズムを実行するために、解釈に適切な復元ソースコードをトランスファする、少なくとも１つのメッセージを備えており、前記データパケットプロトコルは、前記圧縮されたデータコンテンツを含んでいる少なくとも１つのメッセージをさらに備えており、前記少なくとも１つのプロセッサは、
    前記少なくとも１つのメッセージにおいて、前記ソースコードを検出するための第１のモジュールと、
    前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づけるための第２のモジュールと、
    前記対応する復元アルゴリズムの前記位置づけられたアクセス可能で実行可能なバージョンを利用している、前記圧縮されたデータコンテンツを復元するための第３のモジュールと、
    を備えている少なくとも１つのプロセッサ。
17. データパケットプロトコル伝送の一部として、複数の圧縮アルゴリズムのうちの選択された1つによって圧縮されたデータコンテンツも含んでいる、少なくとも１つのメッセージにおいて含まれている、ソースコードを、コンピュータに検出させるための第１セットのコードと、なお、前記圧縮アルゴリズムのそれぞれは、前記圧縮されたデータコンテンツから前記データコンテンツを作ることができる対応する復元アルゴリズムを有しており、前記ソースコードは、前記コンピュータによって前記対応する復元アルゴリズムを実行するために解釈に適切である；
    前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを前記コンピュータに位置づけさせるための第２セットのコードと；
    前記対応する復元アルゴリズムの前記位置づけられたアクセス可能で実行可能なバージョンを利用して前記圧縮されたデータコンテンツを前記コンピュータに復元させるための第３セットのコードと；
    を備えているコンピュータ可読メディア、
    を備えているコンピュータプログラムプロダクト。
18. セッションイニシエーションプロトコル／セッション記述プロトコル（ＳＩＰ／ＳＤＰ）データパケット通信において含まれたバイトコードを検出するための手段と、
    前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づけるための手段と、
    前記対応する復元アルゴリズムの前記位置づけられたアクセス可能で実行可能なバージョンを利用して前記圧縮されたデータコンテンツを復元するための手段と、
    を備えている装置。
19. インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）データコンテンツを通信デバイスに広げるための装置であって、前記装置は、
    圧縮アルゴリズムで前記ＩＭＳデータコンテンツを圧縮するコンプレッサと、
    復元バイトコードを含んでいるデータストラクチャと、
    前記圧縮されたＩＭＳデータコンテンツと復元バイトコードを前記通信デバイスに送信する、データパケット通信チャネルと、
    前記通信デバイスに前記復元バイトコードの実行可能なバージョンを得て、送信するために、前記通信デバイスからのリクエストにすぐ反応するプロセッサと、
    を備えている装置。
20. 前記プロセッサは、前記通信デバイスに適した前記復元バイトコードの前記実行可能なバージョンを選択するために、前記通信デバイスのコンフィギュレーションを得る、請求項１９に記載の装置。
21. インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）データコンテンツを通信デバイスに広げるための方法であって、前記方法は、
    圧縮アルゴリズムで前記ＩＭＳデータコンテンツを圧縮することと、
    復元バイトコードを含んでいるデータストラクチャを生成することと、
    前記圧縮されたＩＭＳデータコンテンツと復元バイトコードを前記通信デバイスに送信することと、
    前記通信デバイスからのリクエストにすぐ反応する前記通信デバイスに、前記復元バイトコードの実行可能なバージョンを送信することと、
    を備えている方法。
22. 前記通信デバイスに適した前記復元バイトコードの前記実行可能なバージョンを選択するために前記通信デバイスのコンフィギュレーションを得ること、をさらに備えている請求項２１に記載の方法。
23. インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）データコンテンツを通信デバイスに広げるためにコンフィギュアされた少なくとも１つのプロセッサであって、
    圧縮アルゴリズムで前記ＩＭＳデータコンテンツを圧縮するための第１のモジュールと、
    復元バイトコードを含んでいるデータストラクチャを生成するための第２のモジュールと、
    前記通信デバイスに、前記圧縮されたＩＭＳデータコンテンツと復元バイトコードを送信するための第３のモジュールと、
    前記通信デバイスからのリクエストにすぐ反応する前記通信デバイスに、前記復元バイトコードの実行可能なバージョンを送信するための第４のモジュールと、
    を備えている少なくとも１つのプロセッサ。
24. 圧縮アルゴリズムでインターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）データコンテンツをコンピュータに圧縮させることが動作可能な第１セットのコードと、
    復元バイトコードを含んでいるデータストラクチャを前記コンピュータに生成させることが動作可能な第２セットのコードと、
    前記通信デバイスに、前記圧縮されたＩＭＳデータコンテンツと復元バイトコードを前記コンピュータに送信させることが動作可能な第３セットのコードと、
    前記通信デバイスからのリクエストにすぐ反応する前記通信デバイスに、前記復元バイトコードの実行可能なバージョンを前記コンピュータに送信させることが動作可能な第４セットのコードと、
    を備えているコンピュータプログラムプロダクト
    を備えているコンピュータ可読メディア。
25. インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）データコンテンツを通信デバイスに広げるための装置であって、
    圧縮アルゴリズムで前記ＩＭＳデータコンテンツを圧縮するための手段と、
    復元バイトコードを含んでいるデータストラクチャを生成するための手段と、
    前記通信デバイスに、前記圧縮されたＩＭＳデータコンテンツと復元バイトコードを送信するための手段と、
    前記通信デバイスからのリクエストにすぐ反応する前記通信デバイスに、前記復元バイトコードの実行可能なバージョンを送信するための手段と、
    を備えている装置。

Images