SIGCOMPUDVMパフォーマンスの最適化のための方法および装置
【解決手段】 通信ネットワークと無線ユーザ機器との間の信号圧縮最適化システムは、縮小されたコンテンツプロセッシング待ち時間が実現可能なとき、最適化されたデコンプレッサを有効に選択し、そうでないときには、受信された復元バイトコードを解釈するユニバーサルデコンプレッサ仮想マシン(UDVM)のような、仮想マシンデコンプレッサを選択する。UDVMがいかなる特定の復元アルゴリズムについて最適化されず、そして、実行前にバイトコードにおいて各ステートメントを分析することに関連づけられた必要条件遅延によって苦しむので、可能なときにいつでもUDVMの使用を回避することが出来ることは、無線で受信されたシグナリングメッセージあるいはメディアコンテンツを表しているという点で、ユーザの経験を高める。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は無線通信のための圧縮方法に関する。
【背景技術】
【0002】
セッションイニシエーションプロトコル(Session Initiation Protocol)(SIP)は、第3世代パートナーシッププロジェクト(Third Generation Partnership Project)(3GPP)リリース5から始まっている、第3世代モバイルネットワークにおいて呼び出し制御のために使用されるプロトコルである。SIPはテキスト符号化(textual encoding)を使用しており、それはSIPに基づいてサービスを作り、SIPへの拡張を設計し、プロトコルをデバッグすることを容易にする。しかしながら、SIPのテキスト符号化は、さらに重大な欠点(drawback)を有しており、SIPメッセージは、例えばモバイル通信のためのグローバルシステム(Global System for Mobile communication)(GSM(登録商標))呼び出し制御において、使用されるプロトコルのものよりも、かなり大きいということはよく知られている。より多くのデータは低帯域幅の無線インタフェースにわたって送信される必要があるので、大きなメッセージサイズは、増大された呼び出しセットアップ遅延を結果としてもたらす。この観察は、呼び出しセットアップ時間を減らすことが出来る解決方法を展開する必要性を作った。そのような1つの解決方法は、インターネット技術タスクフォース(Internet Engineering Task Force)(IETF)によって設計されたシグナリング圧縮(Signaling Compression)(SigComp)プロトコルである。SigCompは、2つのネットワークエレメントの間でアプリケーション層シグナリングの圧縮のためのフレームワークを提供する。SigCompアーキテクチャの中心部分は、ユニバーサルデコンプレッサ仮想マシン(Universal Decompressor Virtual Machine)(UDVM)であり、復元アルゴリズム(decompression algorithms)を実行するために最適化された仮想マシンである。UDVMのために、SigCompは、すべてのSigComp終点(SigComp endpoints)によってサポートされるべき単一のアルゴリズムを命ずる(dictating)代わりに、広範囲の圧縮アルゴリズムをサポートできる。
【0003】
SigCompは、3GPPリリース5 IPマルチメディアサブシステム(IMS)の必須部分である。それは、端末とプロキシ呼び出しセッション制御機能(Proxy Call Session Control Function)(P−CSCF)の間のインタフェースにわたって適用され、それは、IMS内で端末用の第1の接点(contact point)である。SigCompは、呼び出しセットアップのときのアイドル時間を減らすことによってユーザが感じるサービスの質を改善する。それは、さらにネットワークが、加入者ごとの消費されたリソース(resource)の量を減らすことによって、多数のユーザをサポートすることを可能にする。
【0004】
SigCompについての主要なターゲット(primary taeget)は、セルラシステムであり、ここでは、モバイル端末は、さまざまな機能を有しており、検出されていないエラーが、セルラリンク上で導入される可能性がある。SigCompは、また、セルラシステムを含んでいる、限定されたスループットを備えた通信リンクを対応する。
【発明の概要】
【0005】
(米国特許法第119条の下の優先権主張)
この特許出願は、ここでの譲受人に譲渡され、ここにおける参照によりここに明示的に組み込まれる、2006年7月12日に出願された、「SigComp UDVMパフォーマンスの最適化のための方法および装置(“Method and Apparatus for Optimization of SigComp UDVM Performance”)」と題された米国仮特許出願第60/830,545号の優先権を主張する。
【0006】
以下は、開示されたバージョンのさまざまな態様の基本的な理解を提供するために、単純化された概要(summary)を、示す。この概要は、広範囲な全体像ではなく、重要な/決定的なエレメントを識別することも、あるいは、そのようなバージョンの範囲を詳細に描写することも、意図されていない。その目的は、後で示される、より詳細な説明の前置きとして、簡略化された形で説明されたバージョンのいくつかの概念(concepts)を提供することである。
【0007】
一態様は、多数の圧縮アルゴリズムのうちの1つによって圧縮されたデータコンテンツ(data content)を通信することを提供する。各圧縮アルゴリズムは、圧縮されたデータコンテンツからデータコンテンツを作ることが出来る、対応する復元アルゴリズムを有する。増大された柔軟性を与えるために、復元アルゴリズムを実行するのに十分なバイトコードは、バイトコードを解釈するために復元仮想マシンについて意図された圧縮されたデータコンテンツに沿ってデータパケットプロトコルの一部として、送信される。復元アルゴリズムを解釈するのに必要とされた、プロセッシング時間を減らすことによってユーザ経験を高めるために、検出されたバイトコードに関連づけられたマシンコードにおける、復元アルゴリズムのアクセス可能で実行可能なバージョンは、位置づけられ(located)、仮想マシンを使用することよりもむしろデータコンテンツを復元するために、使用される。
【0008】
さらに別の態様においては、少なくとも1つのプロセッサは、復元ソースコードの実行可能なバージョンを位置づけることによって、データコンテンツを復元する方法を実行するように、コンフィギュアされる。特に、第1のモジュールは、ソースコードを検出する。第2のモジュールは、ソースコードに関連づけられた復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づける。第3のモジュールは、復元アルゴリズムの位置づけられたアクセス可能で実行可能なバージョンを利用して、圧縮されたデータコンテンツを復元する。
【0009】
追加の態様において、コンピュータプログラムプロダクトは、コンピュータが少なくとも1つのメッセージにおいて含まれたソースコードをコンピュータが検出するようにさせるための第1セットのコードを含んでいる、コンピュータ可読メディアを有する。第2セットのコードは、コンピュータが、検出されたソースコードに関連づけられた対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づけるようにさせるためである。そのあと、第3セットのコードは、対応する復元アルゴリズムの位置づけられたアクセス可能で実行可能なバージョンを利用して、圧縮されたデータコンテンツをコンピュータが復元するようにさせるためである。
【0010】
さらに別の態様において、マシンコードへのバイトコードの初期コンパイレーションのための手段は、復元アルゴリズムの非常に効率的な実行を提供する。例えば、信号圧縮(SigComp)を使用して圧縮されたセッションイニシエーションプロトコル/セッション記述プロトコル(SIP/SDP)メッセージで、この方法を使用することは、メッセージの呼び出しセットアップ時間と処理の待ち時間(the latency of the processing and call setup times of the message)を短くするであろう。
【0011】
1つのインプリメンテーションにおいては、メカニズムは、受信された各SIP/SDPメッセージの復元のためのユニバーサル復元仮想マシン(UDVM)インタープリタ(interpreter)を実施することを回避するように提供されている。UDVMインタープリタの実行を回避することは、モバイル局上の計算の必要要件を減らし、そして、SIP/SDPプロセッシングにおける潜在的な遅延を減らす。このアプローチは、SIPベースの呼び出しフローのために、呼び出しセットアップ/分解時間を繰り返す。
【0012】
別の態様において、通信デバイスに、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツ(Internet Protocol(IP) Multimedia Subsystem(IMS) data content)を広める方法は、圧縮アルゴリズムでIMSデータコンテンツを圧縮することを備えている。方法は、復元バイトコードを含んでいる、データストラクチャを生成することと、通信デバイス(communication device)に対して、圧縮されたIMSデータコンテンツおよび復元バイトコードを送信することと、をさらに含んでいる。さらに、方法は、通信デバイスからのリクエストにすぐ反応する(responsive)通信デバイスに対して、復元バイトコードの実行可能なバージョンを送信すること、を含んでいる。
【0013】
一態様において、通信デバイスに、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを広めるようにコンフィギュアされた少なくとも1つのプロセッサは、圧縮アルゴリズムでIMSデータコンテンツを圧縮するための第1モジュールを備えている。少なくとも1つのプロセッサは、復元バイトコードを含んでいるデータストラクチャを生成するための第2モジュール、そして、圧縮されたIMSデータコンテンツと復元バイトコードを通信デバイスに対して送信するための第3モジュール、をさらに含んでいる。さらに、少なくとも1つのプロセッサは、通信デバイスからのリクエストにすぐ反応する通信デバイスに対して、復元バイトコードの実行可能なバージョンを送信するための第4のモジュール、を含んでいる。
【0014】
さらなる態様においては、コンピュータプログラムプロダクトは、複数のセットのコードを備えている、コンピュータ可読メディアを含む。第1セットのコードは、圧縮アルゴリズムでインターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを、コンピュータが圧縮するようにさせることが動作可能である。第2セットのコードは、復元バイトコードを含んでいるデータストラクチャを、コンピュータが生成するようにさせることが動作可能である。第3セットのコードは、通信デバイスに対して、圧縮されたIMSデータコンテンツおよび復元バイトコードを、コンピュータが送信するようにさせることが動作可能である。そして、第4セットのコードは、通信デバイスからのリクエストにすぐ反応する通信デバイスに復元バイトコードの実行可能なバージョンをコンピュータが送信するようにさせることが動作可能である。
【0015】
別の態様では、通信デバイスに、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを広めるための装置(apparatus)は、圧縮アルゴリズムでIMSデータコンテンツを圧縮するための手段を備えている。装置は、さらに、復元バイトコードを含んでいるデータストラクチャを生成するための手段と、圧縮されたIMSデータコンテンツと復元バイトコードを通信デバイスに送信するための手段と、を含んでいる。さらに、装置は、通信デバイスからのリクエストにすぐ反応する通信デバイスに復元バイトコードの実行可能なバージョンを送信するための手段、を含んでいる。
【0016】
前述および関連する目的の実現のために、1つまたは複数のバージョンは、この後十分に説明され、そして特許請求の範囲において特に示される、特徴を備えている。以下の説明および添付図面は、詳細に、ある説明のための態様を記述しており、そして、バージョンの原理(principles)が使用されることができる様々な方法のうちのほんの少しを示している。他の利点および新規な特徴は、図面と共に考慮されるとき、以下の詳細な説明から明らかとなるであろう、また、開示されたバージョンは、すべてのそのような態様およびそれらの同等物(equivalents)を含むように意図されている。
【図面の簡単な説明】
【0017】
【図1】図1は、通信ネットワークと通信中である無線デバイスのための信号圧縮最適化システムのブロック図である。
【図2】図2は、図1のシステムの無線デバイスのコンポーネントの一態様の概略図である。
【図3】図3は、第三世代パートナーシッププロジェクト(3GPP)リリース5ネットワークアーキテクチャのさらなる特徴を図示している図1の通信ネットワークと無線デバイスの図である。
【図4】図4は、図1の信号圧縮最適化システムのためのインターネットプロトコル(IP)マルチメディアサブシステム(IMS)のエンティティのコンフィギュレーション図である。
【図5】図5は信号圧縮(SigComp)の終点のロケーションのブロック図である。
【図6】図6は、図5のSigCompの終点のアーキテクチャのブロック図である。
【図7】図7は、図1のシステムによってインプリメントされた信号圧縮最適化の方法のフロー図である。
【図8】図8は、図1の無線デバイスのためのオペレーションの信号圧縮最適化シーケンスのバージョンを図示している図である。
【図9】図9は、図1の無線デバイスのためのオペレーションの信号圧縮最適化シーケンスのバージョンを図示している図である。
【図10】図10は、図1の信号圧縮最適化システムのバージョンを図示している図である。
【図11】図11は、図1の信号圧縮最適化システムのバージョンを図示している図である。
【図12】図12は静的なDEFLATEパフォーマンスを図示しているチャートである。
【図13】図13は、Lempel−Ziv−Storer−Szymanski(LZSS)圧縮アルゴリズムのパフォーマンスを図示しているチャートである。
【発明を実施するための形態】
【0018】
様々な態様が、図面を参照して記述されている。以下の説明においては、説明の目的のために、多くの具体的な詳細な説明が、1つまたは複数の態様の完全な理解を提供するために、示されている。しかしながら、様々な態様は、これらの具体的な詳細なしで実行されることができるということは明白であり得る。他の例においては、よく知られたストラクチャおよびデバイスは、これらのバージョンを簡略に説明するために、ブロック図の形で示されている。
【0019】
装置および方法は、特に、ワイヤレス環境における使用についてよく適していてもよいが、通信ネットワーク、公共ネットワーク、例えばインターネット、プライベートネットワーク、例えば仮想プライベートネットワーク(virtual private networks)(VPN)、ローカルエリアネットワーク、広域ネットワーク、ロングホールネットワーク(long haul networks)、あるいはいずれの他のタイプのデータ通信ネットワーク、を含むがこれに限定されるものではない、いずれのタイプのネットワーク環境において適していてもよい。
【0020】
図1は、通信ネットワーク12と無線ユーザ機器(通信デバイス)14の間の信号圧縮最適化システム10の1つの態様を図示している。通信ネットワーク12内では、マルチメディアコンテンツ(multimedia content)16として図示される、メディアあるいはシグナリング(例えばオーディオ、イメージ、ビデオ、ブライユ等)(一般的には「データ」)は、データ圧縮アルゴリズム20を利用してコンプレッサ18によってデータ圧縮をする(undergoes)。データ復元バイトコード22は、ユーザ機器14の無線通信リンク28に、圧縮されたメディアコンテンツ(compressed media content)26が続く無線通信リンク24による無線送信に適切な形式でソースコードまたはバイトコードを提供する。受信されたバイトコード22にすぐ反応するプロセッサ30は、仮想マシンデコンプレッサの使用を各インスタンスにおいて回避するために、減らされたセットアップの待ち時間について便利であるとき、最適化されたデコンプレッサ32を有効に選択する。代替的に、インプリメンテーションは、最適化されたデコンプレッサ32がアクセス可能でない場合、インスタンスを有することができる。プロセッサ30は、そのあと、ユニバーサルデコンプレッサ仮想マシン(UDVM)34として図示される、仮想マシンデコンプレッサを選択することができる。UDVM34は、例えば受信されたバイトコード22`によって命令されたように、復元アルゴリズムの範囲を柔軟に実行することができる、一般化されたアーキテクチャを有する、しかしながら、UDVM34は、いずれの特定の復元アルゴリズムについて最適化されず、実行前にバイトコード22において各ステートメントを分析することに関連づけられた必要条件遅延によって苦しむ(suffer)。
【0021】
このような実行遅延の有効的な回避を実行するために、プロセッサ30は、バイトコード22``のアクセス可能なコピーは、受信されたバイトコード22``と同じであるということを認識する。バイトコード`を実行するための、実行可能な復元アルゴリズム38の一部としてマシンコード36は、そのあと、最適化されたデコンプレッサ32によって使用される。マシンコード36および/または最適化されたデコンプレッサは、仮想マシンにおいてソースコード(例、バイトコード22`)を解釈することと比較して、復元のための減らされた時間について最適化される。可能なときいつでも、UDVM34の使用を回避することができることによって、ユーザ機器14は、遅延されたセットアップを回避することによってメディアコンテンツプレイヤー38上でメディアコンテンツ(media content)16を表わすことにおいてユーザ経験を高める。
【0022】
マシンコード36は局所的に保存されたライブラリの一部としてアクセスされることができ、局所的にコンパイルされ、今後の使用のために保存されることができ、遠隔ライブラリから無線でアクセスされることができ、リクエストのとき遠隔にコンパイルされ、今後の使用について保存されることができ、および/または、ファームウェアあるいは、最適化されたデコンプレッサに組み込まれた回路構成の他の形として提供されることができるということが、本開示の利益を用いて理解されるべきである。遠隔にコンパイルされたマシンコード36および/またはコンパイルすることにおける遅延は、無線ユーザ機器14についての減らされた複雑さの必要要件と、UDVMにわたって進行中の復元効率性と、における利益によって、相殺されるであろう。
【0023】
いくつかの態様によると、通信デバイス14は、いずれのタイプのコンピュータ化された、コミュニケーション装置を備えることができる。例えば、図1で示されるように、通信デバイス14は、無線のおよび/またはセルラ電話のような、モバイル通信デバイスを備えることができる。代替的に、通信デバイス14は、プロキシ呼び出し/セッション制御機能(P−CSCF)サーバ、ネットワークデバイス、サーバ、コンピュータワークステーション等のような、固定された通信デバイスを備えてもよい。通信デバイス14は、このような説明されたあるいは図示されたデバイスに通信デバイスが限定されないが、携帯情報端末(Personal Digital Assistant)(PDA)、2方法テキストページャ(two-way text pager)、有線あるいは無線通信ポータルを有するポータブルコンピュータ、そして、有線および/または無線の通信ポータルを有するいずれのタイプのコンピュータプラットフォームをさらに含んでいるということは、理解されるべきである。さらに、通信デバイス14は、遠隔センサ、遠隔サーバ、診断ツール、データリレー(data relays)、そして同様のもの、のような遠隔スレーブ(remote-slave)あるいは他の同様デバイスであってもよく、それらのエンドユーザを有さず、無線あるいは有線ネットワークにわたってデータを単に通信する。代替的な態様においては、通信デバイス14は、陸線電話、パーソナルコンピュータ、セットトップボックス、あるいは同様のもののような、有線通信デバイスであってもよい。さらに、単一のタイプあるいは複数の前述のタイプの、任意の数の通信デバイス14のいずれの組み合わせがシステム10において利用されることができるということは、留意されるべきである。したがって、本装置および方法は、有線あるいは無線の通信ポータルを含み、無線モデム、PCメモリカード国際協会(Personal Computer Memory Card International Association)(PCMCIA)カード、アクセス端末、パーソナルコンピュータ、電話、あるいは、それらのいずれの組み合わせ、あるいは、サブコンビネーション(sub-combination)を限定されることなく含んでいる、いずれの形態の有線あるいは無線デバイスあるいはコンピュータモジュール上で、それに応じて実行されることができる。
【0024】
さらに、通信デバイス14は、マルチメディアコンテンツ16をリクエストする、マルチメディアコンテンツ16と相互に作用する、および/またはマルチメディアコンテンツ16をプレイする(playing)ような目的のために、ユーザインタフェース42を含むことができる。このユーザインタフェース42は、通信デバイス14への入力を生成するあるいは受信するのに動作可能な入力デバイス44と、通信デバイス14のユーザによる消費のための情報を生成するおよび/または表わすのに動作可能な出力デバイス46と、を含む。例えば、入力デバイス44は、キーパッドおよび/またはキーボード、マウス、タッチスクリーンディスプレイ、音声認識モジュールに関連づけられたマイクロホン、等のような、少なくとも1つのデバイスを含むことができる。ある態様においては、入力デバイス44は、コンテンツについてのリクエストのユーザ入力、あるいは、追加情報についてのリクエストのユーザ入力、を提供することができる。さらに、例えば、出力デバイス46は、ディスプレイ、オーディオスピーカ、触覚フィードバックメカニズム(haptic feedback mechanism)等を含むことができる。出力デバイス46は、グラフィカルユーザインタフェース、サウンド、バイブレーションのような感覚、等、を生成することができ、そして、そのような出力は、例えば、マルチメディアコンテンツ16の表示に関連付けられることができる(図1)。
【0025】
さらに、通信デバイス14は、デバイスに対して機能性を提供するためにアプリケーションを実行することが動作可能なコンピュータプラットフォーム48を含むことができ、そして、さらに入力デバイス44と出力デバイス46と相互作用することができる。コンピュータプラットフォーム48は、メモリ50を含むことができ、それは、揮発性および不揮発性メモリ部分、例えば読み出し専用および/またはランダムアクセスメモリ(RAMとROM)、電子的消去可能PROM(EEPROM)、フラッシュメモリ、および/またはコンピュータプラットフォームに共通したいずれのメモリ、を備えることができる。さらに、メモリ50は、磁気メディア、光学メディア、テープ、および/またはハードディスク、そしてリムーバブルメモリコンポーネントのような、いずれの第2の、および/または、第3のストレージデバイスと電子ファイルシステムを含んでいる、アクティブメモリとストレージメモリを含むことができる。
【0026】
さらに、コンピュータプラットフォーム48は、プロセッサ52も含むことができ、それは、特定用途向けIC(application-specific integrated circuit)(ASIC)、あるいは他のチップセット、プロセッサ、論理回路、あるいは他のデータ処理デバイスであってもよい。いくつかの態様においては、例えば通信デバイス14がセルラ電話を備えるとき、ASICのような他の論理あるいはプロセッサ52は、メモリ50において、メディア関連アプリケーションと、データ呼び出し、音声呼び出しのようないずれの常駐のソフトウェアコンポーネントとインタフェースでつなぐ(interfaces with)、アプリケーションプログラミングインタフェース(application programming interface)(API)層54を実行することができる。API 54は、個別の通信デバイス上で実行する、実行時間環境であってもよい。1つのそのような実行時間環境は、カリフォルニア州のサンディエゴのクアルコム株式会社によって展開された、無線のためのバイナリ実行時間環境(Binary Runtime Environment for Wireless(R))(BREW(R))ソフトウェアである。他の実行時間環境は、例えば無線コンピューティングデバイス上でアプリケーションの実行を制御することを操作することが利用されることができる。
【0027】
さらに、プロセッサ52は、通信デバイス14の機能性および通信ネットワーク28上の通信デバイスの動作性(operability)を可能にする、ハードウェア、ファームウェア、ソフトウェアおよびそれらの組み合わせにおいて具現化された様々な処理サブシステム56を含んでいてもよい(図1)。例えば、処理サブシステム56は、通信デバイス14のコンポーネント内および/または中同様、他のネットワーキングされたデバイスで、通信をイニシエートすることおよび維持すること、そしてデータを交換すること、を可能にする。一態様において、例えばセルラ電話において、プロセッサ52は、1つの処理サブシステム56または複数の処理サブシステム56の組み合わせを含むことができ、例えば:音声、不揮発性メモリ、ファイルシステム、送信、受信、サーチャ(searcher)、層1、層2、層3、メイン制御、遠隔プロシージャ(remote procedure)、ハンドセット、パワーマネジメント、診断、デジタルシグナルプロセッサ、ボコーダ、メッセージング、コールマネージャ、Bluetooth(R)(登録商標)システム、Bluetooth(R)(登録商標)LPOS、ポジション決定、ポジションエンジン、ユーザインタフェース、スリープ、データサービル、セキュリティ、認証(authentication)、USIM/SIM(ユニバーサル加入者識別モジュール/加入者識別モジュール)、音声サービス、グラフィックス、USB(ユニバーサルシリアルバス)(universal serial bus)、MPEG(ムービングピクチャエキスパートグループ)(Moving Picture Experts Group)プロトコルマルチメディアのようなマルチメディア、GPRS(汎用パケット無線サービス)(General Packet Radio Service)、ショートメッセージサービス(SMS)、ショートボイスサービス(SVS(TM))、ウェブブラウザ等がある。開示された態様については、プロセッサ52のプロセッシングサブシステム56は、コンピュータプラットフォーム48上で実行するアプリケーションと相互作用するいずれのサブシステムコンポーネントを含むことができる。開示された態様については、プロセッサ52のプロセッシングサブシステム56は、コンピュータプラットフォーム48上で実行しているアプリケーションと相互作用する、いずれのサブシステムコンポーネントを含むことができる。
【0028】
コンピュータプラットフォーム48は、通信ネットワーク28(図1)と通信デバイス14との間のコンテンツリクエストと、コンテンツ24(図1)を交換することが動作可能であることに加えて、通信デバイス14の様々なコンポーネント間の通信を可能にする、通信モジュール58をさらに含むことができる。通信モジュール58は、ハードウェア、ファームウェア、それのソフトウェアおよび/またはそれらの組み合わせにおいて具体化されてもよく、そして、イントラデバイス通信およびインターデバイス通信における使用のためのすべてのプロトコルをさらに含むことができる。さらに、通信モジュール58は、ここに説明されている装置および方法にしたがって、情報を送信する、および/または受信することが動作可能であり、例えば、マルチメディアコンテンツ16(図1)をリクエストし、圧縮されたメディア/シグナリングコンテンツ28およびバイトコード22`(図1)を受信する。
【0029】
いくつかの態様において、通信デバイス14のメモリ50は、バックグラウンドプロセスあるいはフォアグラウンドプロセスにおいて、通信ネットワーク12にわたって、マルチメディアコンテンツ16をリトリーブし(retrieve)、保存し、そしてプレイすることが動作可能な、ユーザインタフェースモジュール60をさらに記憶することができる。ユーザインタフェースモジュール40は、ユーザインタフェース42の機能とマルチメディアコンテンツ16のタイプに適切であるメディアプレイヤーを含んでいる、これらの機能を実行することが動作可能で実行可能なインストラクションとデータ、ハードウェア、ソフトウェア、ファームウェアのうちの1つあるいはいずれの組み合わせ、を備えることができる。
【0030】
図3−6を参照すると、信号圧縮最適化システム10の使用の例示的な環境として、ネットワークアーキテクチャ100は、IPマルチメディアサブシステム(IMS)ネットワークのための第3世代パートナーシッププロジェクト(3GPP)と3GPP2標準規格によって指定され、そして、RFC3320、RFC3321およびIMSについての3GPP標準規格(例、3GPP TS 23.228)において定義される、特定タイプの信号圧縮(SigComp)を実行するために開示されている。図3において、ユニバーサルな方法(universal method)は、モバイル通信デバイス(SIPユーザエージェント)と、プロキシ呼び出し/セッション制御機能(P−CSCF)の間で、無線上で送られたSIPシグナリングメッセージを圧縮する。これは、送信された第1メッセージの一部として、復元パーティ(de-compressing party)に復元アルゴリズムを送信している、圧縮パーティ(compressing party)を含む。アルゴリズム(バイトコード22`)を受信するとき復元パーティ(通信デバイス14)は、受信されたバイトコード22`を解釈するメモリ50において、ユニバーサルデコンプレッサ仮想マシン(UDVM)インタープリタ64を実行し、以下のメッセージ(圧縮されたメディア/シグナリングコンテンツ28)を復元する。このアプローチの利点は、そのバイトコードが無線上で供給されているかぎり、いずれの種類のアルゴリズムをサポートする能力(ability)である。例示的なバージョンにおけるメモリ50の呼び出し制御モジュールは、この通信用のプロトコルを定義する、ローカルセッションイニシエーションプロトコル(SIP)とセッション記述プロトコル(SDP)アプリケーション66である。
【0031】
UDVMインタープリタにおいて復元バイトコードを実行することから生じる計算的なオーバーヘッドは、バイトコードにおける各インストラクションが解釈されるとき、遅延を引き起こし、それは、延期呼び出しセットアップ時間のためユーザ経験を損なう(impair)可能性がある。メモリ50におけるデコンプレッサディスパッチャモジュール68は、UDVMインタープリタ64の使用を減らすことによる、通信デバイス14のコンピュータプラットフォーム48によってサポートされた1つまたは複数の最適化インプリメンテーションによって、この遅延を有効に軽減する。
【0032】
第1のインプリメンテーションとして、メモリ50における最適化されたデコンプレッサモジュール70によって実行されることができるマシンコードへのバイトコード22の初期のコンパイレーションは、復元アルゴリズムの非常に効率的な実行を提供する、したがって、次のSIPメッセージプロセッシングおよび呼び出しセットアップ時間の待ち時間(the latency of following SIP messages processing and call setup times)を短くする。その目的のために、デコンプレッサディスパッチャモジュール68は、それぞれが個別の復元マシンコード36と対になる、1つまたは複数の局所的にアクセス可能なバイトコード22``と、受信されたバイトコード22`を比較するために、復元ライブラリ72にアクセスする。マッチ(match)の検出のとき、復元マシンコード36は、UDVMインタープリタ64よりもむしろ最適化されたデコンプレッサモジュール70によって実施されることができる。
【0033】
第2のインプリメンテーションとして、デコンプレッサディスパッチャモジュール68がマッチを検出するのに失敗する新しい受信されたバイトコード22`について、デコンプレッサディスパッチャモジュール68は、それぞれ復元ライブラリ72における、空コードストレージレコード76および空きインデクス78におけるバイトコード22`に沿ってそのあとで保存される、復元マシンコード36を生成するためにメモリ50のコンパイラ74を方向づける。このコンパイレーションは、このバイトコード22`の今後のインスタンスが第1のインプリメンテーションによって取り扱われることができるように、バックグラウンドにおいて生じうる。
【0034】
第3のインプリメンテーションとして、第2のインプリメントにおけるようにマッチを検出するのに失敗するとき、デコンプレッサディスパッチャモジュール68は、外部でコンパイルされるべき、あるいは、今後のインスタンスのための復元マシンコードの周期的にアップデートされたデータベースからリトリーブされるべき、バイトコード22`についてのリクエストを転送する。
【0035】
第4のインプリメンテーションとして、コンピュータプラットフォーム58は、復元について最適化されたデバイスハードウェアにおけるパラレル処理(parallel processing)を可能にすることによってより早いセットアップを容易にする、UDVMハードウェアプロセッサ(例、デジタル信号プロセッサ(DSP))80を有効に含むことができる。デコンプレッサディスパッチャモジュール68は、ローカルのSIP/SDPアプリケーション66の利益についてUDVM64をエミュレートする(emulate)ためにプロキシUDVM82を利用する。
【0036】
図3−6においては、一般に、3GPP TS 23.338、3GPP TS 23.002において説明される3GPPリリース5ネットワークアーキテクチャと一致した(consistent with)通信ネットワーク100は、図1−2の信号圧縮最適化システム10のための操作環境を提供する。特に図3を参照すると、通信ネットワーク100は、コアネットワーク(CN)インフラストラクチャ102と、アクセスネットワーク(AN)インフラストラクチャ104に論理的に分けられる。CNインフラストラクチャ102は、回路スイッチされた(Circuit Switched)(CS)ドメイン106、パケットスイッチされた(Packet Switched)(PS)ドメイン108と、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)110に、論理的に分けられる。UMTS地上波無線アクセスネットワーク(UTRAN)インタフェース104として図示される、ANインフラストラクチャ104は、エレメントが無線ネットワークコントローラ(RNC)114、ノードBエレメント116、そしてユーザ機器(UE)118である、階層無線ネットワークサブシステム(RNS)112によって、形成される。ノードB116は、1つまたは複数のセルをサーブする(serves)論理的なネットワークコンポーネントである。それは、無線セルにおける通信用の、無線伝送/受理ユニットである。RNC114は、1つまたは複数のノードBエレメント116の制御のための機能を備えたネットワークコンポーネントである。RNC114は、複数のUTRANインタフェース104間で、プロトコル交換を扱っている。RNC114は、オペレーションサポートシステムへのアクセスを含む(示されていない)、無線ネットワークサブシステム112の中心化されたオペレーションおよびメンテナンスを提供する。数ある中で、RNC114の機能は、無線リソース制御、アドミッション制御、チャネル割り当て(channel allocation)、ハンドオーバー制御を含む。回路スイッチされたドメイン106に特有のエンティティは、シグナリングゲートウェイ(SGW)119、モバイルスイッチングセンタ(MSC)120、そしてゲートウェイモバイルスイッチングセンタ(Gateway Mobile Switching Centre)(GMSC)122を信号で通信している(signaling)。CSスイッチされたドメイン106は、さらに、このタイプのシグナリングに条件づけられた(constrained)特定のホーム加入者サービス123を含むことができる。MSC120は、無線ネットワークサブシステム112と固定されたネットワークとの間でインタフェースを構成する。GMSC122は、モバイル局(ユーザ機器(UE))118の実際のロケーションへのルーティング(routing)を実行するMSC120である。パケットスイッチされたドメイン108に特定されたエンティティは、サービングGPRSサポートノード(SGSN)124と、ゲートウェイGPRSサポートノード(GGSN)126である。SGSN124およびGGSN126はパケットトラフィック(packet traffic)を扱う。SGSN124は、そのサービスエリア内でモバイル局118にパケットを運ぶ。SGSN124は、1つのセルにおけるユーザ機器118から別のセルにおける機器へと、ローミング加入者(roaming subscriber)をハンドオフする(handing off)ような、モビリティマネジメント機能を実行する。GGSNs126は、パブリックインターネット128、他のモバイルサービスプロバイダのGPRSサービス(ホーム加入者サービス(HSS))130、あるいは、企業イントラネット(示されていない)のような、外部IPネットワークへのインタフェースとして使用される。GGSNs126は、特定のモバイル局122をサービスするSGSNs124に対して、プロトコルデータユニット(PDUs)のトンネリングする(tunnel)のに必要である、ルーティング情報を維持する。
【0037】
IMSコアネットワーク110のIPマルチメディアサブシステム(IMS)エンティティは、モバイルインターネットパラダイム(mobile Internet paradigm)にしたがって、多様なマルチメディアサービスを展開する一般のプラットフォーム(common platform)を作るために、第3世代パートナーシッププロジェクト(3GPP)リリース5の一部として導入された。IMSエンティティは、IPマルチメディア(IM)サービスの供給のためにすべてのコアネットワークエレメントを備え、それらは、例えば、呼び出しセッション制御機能(CSCF)130(すなわち、問い合わせ(Interrogating)、プロキシ、そしてサービング)、IMSメディアゲートウェイ機能(Media Gateway Function)(MGW)131、メディアゲートウェイ制御機能(MGCF)132、そしてマルチメディアリソース機能133である。3GPPごとのIMS CN110は、標準化されたインタフェースによって定義されるようにノードよりもむしろ機能を標準化させる。インプリメンタ(Implementers)は、自由に、2つの機能を単一のノードに組み合わせる、あるいは、2つまたは複数のノードに単一の機能を分けることができる。IMS CN110は、公衆交換電話網(PSTN)134とHSS130のような他のUMTSネットワークのような他のネットワークへの相互接続同様、音声とマルチメディア呼び出しおよびセッション(voice and multimedia calls and sessions)を制御するドメインである。それは、異なる経路をトラバースする、メディアプレーンとシグナリングプレーンを有する。
【0038】
SigCompはIMS CN 110の一部であり、それはSIPシグナリングトラフィックを圧縮するために使用される。IPマルチメディア(IM)ドメインは、コスト削減と新しいサービスの導入を可能にする、例えば、ボイス電話方式、ビデオ電話方式、マルチメディア会議、インスタントメッセージング、そしてリアルタイムインタラクティブゲームである。IMSは、無線ユーザのためのボイス、ビデオ、メッセージング、データおよびウェブベースの技術の収斂(convergence of)およびそれらへのアクセスを可能にし、そして、モバイル通信における成長とインターネットの成長を結合する。IPマルチメディアコアネットワークサブシステム(IMS)は、パブリックランドモバイルネットワーク(PLMN)オペレータがインターネットアプリケーション、サービス、およびプロトコルに基づいた、そして、構築した(built upon)それらの加入者マルチメディアサービスをオファすること(offer)を可能にする。マルチメディアシグナリングおよびベアラトラフィック(bearer traffic)をトランスポートするために、パケットスイッチされたドメインを利用する。パケットスイッチされたドメインは、端末が移動しIMSから動きを隠している間、サービスを維持する。IMSは、回路スイッチされたドメインから独立している。IMドメインは、ユーザとアプリケーションが、マルチプルパーティ間でセッションおよび呼び出しを制御することを可能にする。呼び出しについて必要とされる機能性、セキュリティ、そして質を提供するために、ネットワークリソースを制御し、サポートする。IMドメインは、いずれのUMTSネットワークからそれらがそれら自体のサービスにアクセスすることができるように、ユーザの登録のために、提供する。IMの1つの追加的な役割は、呼び出し参与者(call participants)についての情報、時間、送信且つ受信されたデータの持続時間および容量を含む、呼び出し詳細レコード(Call Detail Records)(CDRs)を生成することである。CDRsは、目的を満たす(charging)ために使用される。
【0039】
図4においては、3GPP TS 23.228ごとのIMSエンティティは、CSCF、MGCF、IMSメディアゲートウェイファンクション(IMS Media Gateway Function)(IMS−MGW)、マルチメディアリソースファンクションコントローラ(MRFC)、マルチメディアリソースファンクションプロセッサ(MRFP)、サブスクリプションロケータファンクション(Subscription Locator Function)(SLF)、ブレイクアウトゲートウェイ制御機能(BGCF)およびアプリケーションサーバ(AS)を含んでおり、なお、ユーザトラフィックをサポートしているインタフェースは、太い線で示されており、シグナリングをサポートしているインタフェースは点線で描かれている。
【0040】
IMSエンティティの役割は、3GPP TS 23.228において説明されている。SIPサーバである、CSCFは、プロキシCSCF(P−CSCF)、サービングCSCF(S−CSCF)138あるいは問い合わせCSCF(I−CSCF)として動作できる。P−CSCFは、IMS CNのためのUEの第1接点である。SigCompメッセージの圧縮および復元を実行するコアネットワークエレメントであるので、SigCompに特別に重要である。このために、P−CSCFは、コンプレッサとデコンプレッサを含む(IMS端末もまた両方を含んでいる)。I−CSCFの役割が特定のユーザのために適切なS−CSCFを見つけることである一方で、S−CSCFは、ネットワークにおいてセッションステートを扱う。MGCFは、プロトコル転換(conversion)を実行し、帯域情報から受信し、CSCFと通信し、CSCFを選択し、呼び出しステートの一部を制御する。IMS−MGWは、スイッチされた回路ネットワークからベアラチャネルを、そして、パケットネットワークからメディアストリームを、終わらせる(terminates)。それは、メディア転換、ベアラ制御、そしてペイロード処理を扱う。MRFCのタスクは、MRFPにおけるメディアストリームリソースを制御し、CDRsを生成し、そして、ASとS−CSCFから来る情報を解釈し、それに応じてMRFPを制御することである。
【0041】
MRFPは、MRFCによって制御されるリソースを提供し、Mbリファレンスの点上でベアラを制御し、メディアストリームをミックスし(mixes)、ソースし(sources)、処理する。登録とセッションのセットアップの間(during)、I−CSCFによってリクエストされるとき、SLFは、必要とされる加入者特定データを含んでいるHSSの名前を供給する。それはさらに登録プロセスの間に、S−CSCFによってクエリされる。BGCFは、PSTNブレイクアウトが生じる予定のネットワークを選択し、使用されるMGCFを選択する。ASは、SIPアプリケーションサーバ、オープンサービスアクセス(OSA)アプリケーションサーバあるいはモバイルエンハンスされたロジックについてのカスタマイズされたアプリケーション(a Customized Application for Mobile Enhanced Logic)(CAMEL)IPマルチメディアサービススイッチング機能(IM−SSF)であってもよい。それは、IMサービスを加えた値をオファする。S−CSCFとASとの間のインタフェースは、ASにおいて常駐しているサービスを提供するために使用される。
【0042】
IPマルチメディアサブシステムは、アクセス独立を達成するために、そして、3GPP TS 23.228ごとのインターネットにわたって電話線(wireline)端末を用いて円滑なオペレーションを維持するために、インターネット技術タスクフォース(IETF)インターネット標準規格に整合(conformant)することを試みる。IMドメインにおいて登録および呼び出し制御のために使用されるシグナリングプロトコルは、セッションイニシエーションプロトコル(SIP)である。SIPは、UEとCSCFとの間で適用される単一のプロトコルである。
【0043】
図5においては、端末に送られたメッセージを圧縮し、端末から受信されたメッセージを復元するエンティティは、P−CSCFであり、UEからS−CSCFまでのSIPシグナリングフローとして描かれている。UEにおいてSigCompで圧縮されたSIPメッセージは、無線インタフェース、UMTS地上波無線アクセスネットワーク(UTRAN)の無線ネットワークコントローラ(RNC)と基地局(BS)を通じて流れる(flow)。SigCompメッセージが復元される場合、UTRANから、それらは、サービングGPRSサポートノード(SGSN)とゲートウェイGPRSサポートノード(SGSN)を通じて、P−CSCFまでトラバースする。P−CSCF前方(onwards)から、SIPメッセージは、非圧縮された状態で送られる。無線アクセスネットワークからよりもむしろネットワークコアから、SigComp圧縮および復元を実行するエンティティを選択することを支持した理由が以下で説明されている。まず初めに、圧縮は、暗号化および暗号解読の点からバウンドして適用されなくてはならず、透過的でなくてはならないので、トラフィック暗号化および暗号解読(decryption)機能のロケーションはさらに、圧縮機能のロケーションに影響を与える。いくつかのトラフィックタイプのパケットコンテンツ(packet content)は、認証されており、完全保護されている、あるいは、暗号化されている。端末からトラフィックを解読し、端末に暗号化する、信頼されたパーティは、モバイルネットワークコアにおいて存在する。もし終点(endpoint)が無線アクセスネットワークから選ばれた場合には、ネットワークデザインおよびパフォーマンスは、モバイルネットワーク内でメッセージキーをトランスファすることによって加えられるであろう複雑さから苦しむであろう。シグナリング圧縮のロケーションに影響を与える別の重要な問題は、ハンドオーバー(handover)である。SigCompにおいては、比較的大きい量の史的なステートが、効率的な圧縮を可能にするために確立される(built up)。復元を実行している終点が変わった場合、このステートは、圧縮効率を維持するために新しいエンティティにトランスファされることが必要となるであろう。この種類の解決方法は、ネットワークに複雑さを付け加えるであろう。復元がP−CSCFにおいて実行されるとき、復元終点(decompressing endpoint)は、アプリケーション層セッションの持続期間について安定したままである。
【0044】
したがって、SigComp機能のロケーションは、モバイル端末にあり、そしてネットワークの内部にあり、すなわちIMSにある。このアプローチは、ヘッダ圧縮と対比しており、圧縮機能は、端末において、そして、無線アクセスネットワークにおいて、位置づけられている。SigCompのケースにおいては、メッセージは、ルーティング情報を含まない、アプリケーションレベルのメッセージである。それらは、トランスポート層プロトコルのペイロードにおいて、搬送され、代わりにIPへのルーティング問題を残す(leave)。SigCompは、トランスポート層プロトコルのヘッダを圧縮しない。トランスポート層プロトコルペイロードのコンテンツに関心のあるエンティティのみ、すなわち2つの通信している終点は、SigCompメッセージを復元する必要がある。
【0045】
SIPシグナリングが端末とP−CSCFの間で圧縮された状態で送られる理由は、無線インタフェースにわたって少しのバイトを節約することではないということは、強調されるべきである。端末がより多くの帯域幅を使用するであろう、マルチメディアセッションを確立するであろうとき、それは少しのバイトのシグナリングを節約するに値しない。圧縮のための主なモチベーションは、無線インタフェースにわたってSIPメッセージを送信することに必要とされた時間を減らすことである。
【0046】
IMSにおいては、セッション制御を実行するプロトコルは、セッションイニシエーションプロトコル(SIP)である。SIPは、本来、既存のマルチメディア会議にユーザを招待するために使用されていたが、今日では、それは、主にマルチメディアセッションを作り、修正し(modify)、そして終了するために使用されている。SigCompは、いずれのテキストベースのプロトコルのメッセージを圧縮するために使用されることができるけれども、主な焦点は、目下SIPメッセージの圧縮上にある。
【0047】
SIPは、扱われたマルチメディアセッションのタイプから独立しており、そして、セッションを説明するために使用されたメカニズムから独立している。マルチメディアセッションを説明するのにもっとも一般的な(common)フォーマットは、セッション記述プロトコル(SDP)である。SDPは、SIPメッセージのボディにおいて搬送される、単なるテキストフォーマット(textual format)である。これが、SigCompがSIPとSDPの両方を効率的に圧縮することができなくてはならない理由である。SIP/SDPの静的ディクショナリは、この目的のために定義される。
【0048】
SIPプロトコルは、いくつかのエンティティを規定しており、それらはユーザエージェント(UAs)、リダイレクトサーバ(redirect servers)、プロキシサーバ、レジストラ(registrars)およびロケーションサーバである。SGPPリリース5、あるいはのちにリリースする、をサポートしている、すべての3G端末は、SIP UAを含んでいる。さらに3GPP2は、SIPを採用する。SIPは、ユーザの現在のロケーションへのリクエストをルーティングし、サービスのためにユーザを認証し権利化し、プロバイダ呼び出しルーティングポリシーをインプリメントし、そしてユーザに特徴を提供することを手助けするために、プロキシサーバを利用する。リダイレクトサーバは、ユーザが到達可能かもしれない場合、代替のロケーションを提供することによってSIP UAsのロケーションにおいて、手助けする。レジストラは、登録を受諾する(accepts)。それは、大抵、リダイレクトサーバあるいはプロキシサーバで同じ場所に配置される。ロケーションサーバは、SIPエンティティではないが、SIPを使用するいずれのアーキテクチャの重要な部分である。ロケーションサーバは、ユーザの可能性のあるロケーションを保存し、戻す。
【0049】
SIPは、ハイパーテキストトランスファプロトコル(Hypertext Transfer Protocol)(HTTP)のような、リクエスト/応答プロトコルであり、それに基づいている。SIPユーザエージェントクライアント(UACs)は、リクエストを送り、ユーザエージェントサーバ(UASs)は、レスポンスを戻す。リクエストのスタートラインは、方法名を宣言し、それは、リクエストの目的を指している。
【0050】
SigComp終点のレイアウトは図5に図示されている。それは、以下のエンティティ:コンプレッサディスパッチャ、1つまたは複数のコンプレッサ、ステートハンドラ、ユニバーサルデコンプレッサ仮想マシン(UDVM)およびデコンプレッサディスパッチャ、を含んでいる。
【0051】
コンプレッサディスパッチャのタスクは、アプリケーションからメッセージを受信し、トランスポート層に各メッセージの圧縮されたバージョンを受け渡すことである。アプリケーションは、各メッセージと一緒にコンパートメント識別子を、コンプレッサディスパッチャに提供しなければならない。コンパートメントは、ピア終点に関連する、メッセージのグルーピングに特有のアプリケーション(an application specific grouping of messages)である。SIPのケースにおいては、コンパートメントは、SIPダイアログに属しているすべてのメッセージによって形成される。コンパートメント識別子は、独自にコンパートメントを識別する。SigCompは、パーコンプレッサベースでコンプレッサを呼び出す、それは、コンパートメント識別子がさらにコンプレッサを識別するために使用されることができるということを意味する。このために、コンパートメント識別子とコンプレッサとの間のマッピングは、維持されなくてはならない。アプリケーションメッセージと一緒にコンパートメント識別子を提供することによって、アプリケーションは、コンプレッサディスパッチャは適切なコンプレッサを位置づけることができるということを確実にする。新しいコンパートメント識別子(a new compartment identifier)が出くわされるたびに、新しいコンプレッサが呼び出される。いったんコンプレッサがアプリケーションメッセージを圧縮すると、SigCompヘッダは、作られ、それに取り付けられる。この後で、コンプレッサディスパッチャは、トランスポート層にSigCompメッセージを受け渡すことができる。アプリケーションがコンパートメントをクローズ(close)したいと願うとき、例えばBYEメッセージを受信し、ファイナルレスポンスを送った後で、コンプレッサディスパッチャにこれを示すべきである。
【0052】
コンプレッサは、アプリケーションメッセージを圧縮するのに使用されるある圧縮アルゴリズムをインプリメントする。SigCompの基礎的なアイデアのうちの一つは、標準規格がすべての終点によって使用されるべき1つの圧縮アルゴリズムの使用をディクテートしていないということである。代わりに、アルゴリズムの選択は、インプリメンテーションの決定として残されている。次に続くのは、各終点が様々な圧縮アルゴリズムの出力を復元することができるべきであるということである。これは、復元機能性を処理する仮想マシンの使用によって可能になる。コンプレッサが圧縮されたアプリケーションメッセージを含んでいるSigCompメッセージを作るとき、それは、メッセージのヘッダへの復元アルゴリズムを含む。この復元アルゴリズムは、バイトコードと呼ばれており、そして、それは、仮想マシン上で実施されることができる形態にコンパイルされてきた。
【0053】
多くの必要条件は、コンプレッサ上に置かれる。まず初めに、それは、透過的(transparent)でなくてはならない(例、コンプレッサは、UDVMがSigCompメッセージを不正確に復元するようにさせる、バイトコードを送らない)。コンプレッサは、成功復元が生じることを確実にするために、アプリケーションメッセージにわたって、完全チェック(integrity check)のいくつかの形態を供給するべきである。メッセージが、遠隔終点で、利用可能なリソースを使用して、復元されることができるということを確実にしなければならない。トランスポートがメッセージベースである場合、それがユーザデータグラムプロトコル(UDP)のケースにおけるとき、コンプレッサは、確実に1つのSigCompメッセージに、各アプリケーションメッセージをマッピングしなくてはならない。トランスポートがストリームベースであり、しかしアプリケーションがそれ自体の内部のメッセージの境界を定義する場合、コンプレッサは、確実に1つのSigCompメッセージに各アプリケーションメッセージをマッピングするべきである。
【0054】
デコンプレッサディスパッチャの役割は、トランスポート層からSigCompメッセージを受信し、各メッセージを復元するためにUDVMの新しいインスタンスを呼び出しし(invoke)、そして、アプリケーションに結果として生じる非圧縮されたメッセージを受け渡すことである。いったんアプリケーションがメッセージを受信すると、それは、コンパートメントにメッセージをマッピングし、デコンプレッサディスパッチャにコンパートメントの識別子を戻す。デコンプレッサディスパッチャは、そのあと、ステートハンドラに識別子を渡し、それは、ステート情報を節約し、適切なコンプレッサに対してフィードバック情報を転送する(forward)ために識別子を使用する。コンパートメント識別子を供給することによって、アプリケーションは、これをするための許可をディスパッチャに承諾する(grants)。
【0055】
ユニバーサルデコンプレッサ仮想マシン(UDVM)は、SigCompメッセージを復元するエンティティである。復元プロセスは、仮想マシン上でバイトコードと呼ばれる、特別コンパイルされたプログラムを実行することにより行なわれる。UDVMは、大いにJava(登録商標)仮想マシンのような仮想マシンであるが、復元アルゴリズムを実行するために最適化されたという違いを備えている。SigCompのケースにおいては、バイトコードにコンパイルされたソースコードは、UDVMアセンブリ(UDVM assembly)と呼ばれ、エンティティのコンパイリング(the entity compiling)はUDVMインタープリタと呼ばれる。バイトコードは、UDVMのマシン言語として考えられることができる。
【0056】
UDVMは、どのように与えられたアプリケーションメッセージを圧縮するかを選択するとき柔軟性を提供する:コンプレッサインプリメンタは、彼の選択のアルゴリズムを選択する自由を有する。圧縮されたデータは、1セットのUDVMインストラクションを含んでいるバイトコードで結合されている。これらのインストラクションは、SigCompメッセージのヘッダにおいて搬送され、そして、それらは、オリジナルデータが受信終点で展開されること(extracted)を可能にする。
【0057】
SigCompは非保護されたトランスポート層上で実行できるので、UDVMの分離したインスタンス(separate instance)は、損害をうけたメッセージがより後のメッセージの復元に影響を与えないということを確実にするためにパーメッセージ基準(a per-message basis)上で呼び出される。しかしながら、復元プロセスの間に、UDVMは、既存のステートにアクセスするようにステートハンドラを呼び出すことができる。この方法で、前のメッセージを復元したUDVMインスタンスのステートは、より後のUDVMインスタンスによって再記憶される(restored)ことができる。
【0058】
UDVMは初期化されるとき、UDVMは、デコンプレッサディスパッチャから追加の圧縮されたデータ、あるいはステートハンドラからステート情報を、リクエストのときのみ、受信できる。復元が行なわれると、UDVMは、復元されたデータを、デコンプレッサディスパッチャに出力する。それがメッセージの終わりに出くわすとき、それは、ディスパッチャにこのことを示し、コンパートメント識別子でそれを提供する。この識別子は、ステート作成リクエストにおいてステートハンドラに受け渡される。ステートハンドラは、対応するコンパートメントのためにリザーブされるステートメモリのロケーションにおいて、ステート情報を記憶するために、コンパートメント識別子を使用する。UDVMはさらに、ステートハンドラにSigCompメッセージにピギーバック方式で輸送されることができるフィードバック情報を転送する。
【0059】
UDVMサイクルは、UDVMインストラクションを実行するのに必要とされるCPUパワーの量の測度(measure)である。UDVMサイクル限度は、SigCompメッセージにおいてビットごとに復元するために使用されることができるUDVMサイクルの数を制限する(restrict)ために使用される。悪意のあるユーザはルーピングコードを含んでいるバイトコードを送る可能性があるので、バイトコードが使用するサイクルの量は、モニタされなくてはならない。しかしながら、サイクル限度は、生じうるダメージの量をただ減らすが、問題を取り去らない。
【0060】
SigCompにおいては、デコンプレッサメモリのサイズは交渉できる(negotiable)。復元側は、圧縮側にデコンプレッサメモリのサイズを通知する(advertises)。デフォルトのサイズは2キロバイトである。圧縮の効率を改善するために、4あるいは8キロバイト、あるいはそれ以上のキロバイトのメモリサイズが、使用されることができる。デコンプレッサメモリは、2つのセクションに分かれており、そのうちの最初のセクションは、復元されたメッセージを記憶するために使用される。他のセクションは、UDVMがバイトコードおよびサーキュラーバッファ(circular buffer)を保持するために使用されており、UDVMメモリのよりも大きいステートの使用を可能にする。このことは、バッファが満たされるとすぐに、UDVMはバッファの初めにコンテンツに上書きすることを開始できるので、可能である。
【0061】
UDVMの分離したインスタンスが、到達する各メッセージを復元するために呼び出されるので、メッセージ間で情報を保持する(retain)ための方法が必要とされる。これはSigCompステートハンドラのタスクであり、受信されたSigCompメッセージ間の情報を保存する。ステートハンドラのおかげで、メッセージが前のメッセージにおいて含まれる情報に関して圧縮されることができるので、圧縮比は、改善される。ステートハンドラは、より後のメッセージが復元されているとき、アクセスのためのステートアイテムを作ることを可能にする。ステートアイテムは、典型的に、非圧縮されたメッセージあるいはUDVMインスタンスのメモリのスナップショットのいずれかを含んでいる。
【0062】
ステートハンドラは、パーコンパートメント基礎上でステートメモリを管理する。ステートアイテム自体を保存すること同様、それは、特定のコンパートメントによって作成されたステートアイテムのリストを維持し、そして、どんなコンパートメントもその割り当てられたメモリを超えないということを確実にする。
【0063】
UDVMインタープリタは、UDVMインストラクションとUDVMアセンブリにリストされたそれらのオペランドを、バイトコード形式に翻訳するエンティティである。UDVMインタープリタは、入力として、UDVMアセンブリソースコードを含んでいるファイルを捉え、そして、それをバイトコードにコンパイルする、それは、仮想マシン上で実施されることができる。
【0064】
信号圧縮最適化システム10の動作環境を説明した状態で、信号圧縮最適化方法400は図7において、図示されている。明瞭にするために、方法は、ブロック414−420の通信デバイス(受信者)部分が後で続く、ブロック402−412の通信ネットワーク(広める)部分に、連続して分離される。方法が複数のエンティティを含んでいるということと、そして、圧縮されたSIP/SDPデータコンテンツの伝播(dissemination)は、通信デバイスから通信ネットワークにさらに送られることが出来るということと、を理解されるべきである。さらに、通信ネットワークあるいは通信デバイスは、そのようなエンティティの様々な組み合わせにおいて、開始し、リレーし、終了する、伝播を備えた複数のエンティティを表わすことができる。
【0065】
ブロック402で始まり、通信ネットワークは、受信通信デバイスのハードウェア/ソフトウェアコンフィギュレーションを得ることによって、信号圧縮最適化システム10の態様を有効に進める(advances)ことができる。このことは、可能性のある通信デバイスの世界(universe)上で最新状態(up to date)のままであることを意図されている包括的なデータベースを必要とし得るであろう、あるいは、ここに開示される信号圧縮最適システム10の他の態様をサポートするそれらに特に集中される。このデータは、OEM製造業者(Original Equipment Manufacturers)(OEM)によって供給されることができる、あるいは、このような通信デバイスの母集団(population)をサポートする、個別の通信デバイスあるいは階層型エンティティ(individual communication devices or hierarchical entities)とのSIP/SDP通信を介して、インタラクティブに(interactively)得られることができる。ブロック404においては、対応する復元ソースコード(バイトコード)にそって、信号圧縮アルゴリズムは選択される。このような選択は、受信者通信デバイス(単数または複数)がUDVMを呼び出すことを通信デバイスに期待するよりもむしろバイトコードの実行可能なバージョンにローカルアクセスを有するかどうかを知って、有効になされうる。ブロック406においては、通信ネットワークは、実行可能なマシンコードを作るために、得られたハードウェア/ソフトウェアのコンフィギュレーションと一致した(consistent with)バイトコードをコンパイルする。このようなコンパイレーションは、リクエストを待ち、そして、そのあと、すぐに送信されることができる。図示されたシーケンスにおいて、ブロック408においては、このコンパイレーションは、リクエストの前に終わっており、リクエストのときに、伝播のためのコンフィギュレーションとバイトコードにしたがって、インデクスがつけられる(indexed)。
【0066】
データコンテンツ(例えば、マルチメディアコンテンツおよび/またはシグナリング)は、ブロック410において、圧縮アルゴリズムにしたがって圧縮される。圧縮されたデータコンテンツは、そのあと、データコンテンツ(例えばマルチメディア、シグナリングなど)を復元する通信デバイス(モバイル端末)で解釈に適切である、選択されたソースコード(「バイトコード」)に沿って、データパケットプロトコルに従って送信される。例示的なインプリメンテーションおいては、ブロック412では、通信ネットワークは、選択されたソースコード(バイトコード)に沿って、データパケットプロトコルに従って圧縮されたデータコンテンツを、無線で送信する。
【0067】
ブロック414においては、通信デバイスは、伝送を無線で受け取る。ブロック416では、伝送されたバイトコードが検出される。ブロック418においては、検出されたバイトコードに関連づけられた復元コードのアクセス可能で実行可能なバージョンは、仮想マシン上のバイトコードのより遅い解釈を回避して、位置づけられる。実行可能なバージョンにアクセスすることは、今後の使用のためにストレージで実行の前に、ローカルのコンパイレーションあるいは遠隔のコンパイレーションを必然的に伴うことができる。実行可能なバージョンは、UDVMインタープリタの使用を避けるために、ハードウェア最適化されたデコンプレッサの他のタイプあるいはデジタル信号処理を使用することを必然的に伴うことができる。ブロック420においては、圧縮されたデータコンテンツは、そのあと、アクセス可能で実行可能なバージョンを使用して、復元される。
【0068】
図8−11においては、図7の方法の4つの特別のインプリメンテーションが図示されている。第1に、図8においては、信号圧縮最適化装置500は、使用されるべき1つのセットの圧縮アルゴリズムがあらかじめ知られているという仮定の上で作られ、これらの復元アルゴリズムのためのマシンコードインプリメンテーションでプロビジョンすることによって、モバイル端末502へと組み込まれる。モバイル端末502上で実行されるシグナリング圧縮(SigComp)最適化のオペレーション504は、ブロック506において、プロキシ呼び出し/セッション制御機能(P−CSCF)510によって通信チャネル508上で送信されたSigCompメッセージに沿って検出された復元バイトコードを比較できる。ブロック512において、SigComp最適化のオペレーション504が正確なマッチ(exact match)が検出されるということを決定する場合、そのときには、ブロック514においてマシンコード復元が実行される。ブロック512において正確なマッチが決定されなかった場合には、そのときには、ブロック516においてユニバーサルデコンプレッサ仮想マシン(UDVM)インタープリタは、復元のためのバイトコード上で呼び起こされる。ローカルSIP/SDPアプリケーション518は、P−CSCFによって最初に(initially)圧縮されたプレーンのSIP/SDPメッセージ(plain SIP/SDP messages)を受信する。したがって、もしアルゴリズムがブロック512において認識されないP−CSCF510(例えば、ローミングの間に、あるいはネットワークアップグレードの後で)によって送られる場合、モバイル端末502は、標準UDVMインタープリタをまだ実行することができるであろう。
【0069】
図9において、代替的な信号圧縮最適化装置600は、プリコンパイルされたアルゴリズムのリストでP−CSCF610から通信チャネル608にわたって受信された復元バイトコードをブロック606において比較するSigComp最適化オペレーション604による“ジャストインタイム”のコンパイレーションを必然的に伴う。もしバイトコードがブロック612においてマッチであるとわかった場合、そのときには、プリコンパイルされたアルゴリズムの関連づけられたマシンコードは、復元のためにブロック614において使用される。ブロック612でマッチが見つからなかった場合には、そのときは、ローカルSIP/SDPアプリケーション618に対してプレーンのSIP/SDPメッセージを提供するいずれかの事象において、バイトコードは、マシンコードにブロック616でコンパイルされ、そのあと、ブロック614が実行される。したがって、このバイトコードはいったんコンパイルされ、そして、すべての以下のセッションイニシエーションプロトコル(SIP)メッセージの復元のために使用される。図9においては、UDVMの使用は、コンパイレーションが実行されるまで待機することによって回避される。この方法は、ターゲット上でバイトコードコンパイレーション機能を必要とする。1つの第1メッセージの後のすべてのメッセージ(All the messages after the first one)は、UDVMインタープリタコードを実行することによって引き起こされたであろう、いずれの処理の非効率を経験しない(do not suffer)。代替的に、コンパイレーションは、現在の通信のためのUDVMインタープリタを呼び起こしている間、今後の使用のためにバックグラウンドにおいて生じてもよい。
【0070】
図10においては、別の代替的な信号圧縮最適化装置700は、バイトコードのコンパイルされたバージョンの使用を拡張し、しかし、ターゲット上でバイトコードをコンパイルする代わりに、マシン(例、コンパイルされた)コードは、ネットワークによって送られる。このマシンコードが該モバイル(mobile in question)に互換性(compatible)があるということを確実にするために、ネットワーク(SigCompサーバ720)は、チャネル708を介してSIPメッセージング機能を使用してモバイル端末702のハードウェア/ソフトウェアバージョンの番号を最初にチェックできる。別のことばに言い換えると、ネットワークは、モバイル局のハードウェア/ソフトウェア(HW/SW)(hardware/software)にしたがって、モバイル局に送るべき必要のある適切なマシンコードを選択する。受信されたマシンコードは、同じマシンコードの後続の再伝送を回避するためにモバイル局の永続メモリ(permanent memory)上で保存されることができる。その目的に、ブロック706におけるSigComp最適化オペレーション704は、P−CSCF710から(form)通信チャネル708にわたって受信された復元バイトコードを比較する。バイトコードマッチがブロック712において決定される場合、そのときは、プリコンパイルされたマシンコードは、ブロック714で実行されることができる。ブロック712においてマッチが見つからなかった場合は、そのときは、バイトコードのプリコンパイルされたバージョンは、SigCompサーバ720からリクエストされ、そして、バイトコードはリストに加えられる(ブロック716)。マシンコードは、ローカルSIP/SDPアプリケーション722に対してプレーンのSIP/SDPメッセージを供給するために、ブロック714において復元を達成する実行について、そのとき、利用可能となる。
【0071】
図11においては、さらに追加の代替的な信号圧縮最適化装置800は、デコンプレッサディスパッチャ804がP−CSCF808から通信チャネル806を介して復元バイトコードでSigCompメッセージを受信する、モバイル端末802を有する。モバイル端末802は、最適化されたハードウェアプロセッサ810を利用する。プロキシUDVM812は、特定のバイトコードでハードウェアプロセッサ810をプログラムし、そのあと、ハードウェアプロセッサ810における復元のためのSigCompを送る。ハードウェアプロセッサは、UDVM解釈のためにプログラムされた汎用目的のDSPあるいは専用アクセレータのいずれであってもよい。プレーンのSIP/SDPメッセージは、そのあと、ローカルSIP/SDPアプリケーション812によって利用される。
【0072】
このシステムおよび方法は、P−CSCFサーバの処理必要要件を減らすためにネットワークサイドに、さらに、適用されることができる。
【0073】
インプリメンテーション。様々なインプリメンテーションが可能である。いくつかの進んだインプリメンテーション、例えばネットワークがモバイル局に対してプリコンパイルされた復元バイナリ(pre-compiled de-compression)を送る方法は、インフラストラクチャベンダー(infrastructure vendor)からいくつかのサポートを必要とするであろう、したがって、標準化のいくつかの形式を必要とするであろう。したがって、いくつかのインプリメンテーションにおいては、例えば3GPP/3GPP2あるいはIETF(インターネット技術タスクフォース)標準規格団体によって促進されるもののような標準規格において、ここに開示されている方法および装置の特徴のうちの少なくともいくつかを含むことは、適切であるかもしれない。
【0074】
実験結果。UDVMのパフォーマンスのいくつかのベンチマーキングを実行した後で、以下が観察される:(1)UDVMインタープリタは、本来の復元アルゴリズムと比較して、約20倍遅く、SIPメッセージを復元する。(2)UDVMがクァルコムMSM6800チップセット上の通常の呼び出しセットアップの間、SIPメッセージを復元するのにかかる時間は、ほとんどアイドルのセントラルプロセッシングユニット(CPU)上で約100msである。この時間は、事前の呼び出しセットアップのシナリオ、例えばPRACKの使用(すなわち、仮レスポンスの受信を認識するSIP方法)、あるいはサービスの質(Quality of Service)(Qos)前提条件、で増える。(3)圧縮効率を改善する、よりよい圧縮アルゴリズムの導入は、いちじるしくUDVM復元時間を増やすであろう。要約するために、本発明は、CPUロードあるいは複雑なSIP呼び出しセットアップフローのケースにおいて、少なくとも100msあるいはそれ以上だけ、呼び出しセットアップ時間を、潜在的に減らすことができる。
【0075】
図12−13は、SURF6800加入者ユニットリファレンスデザインボード上で簡単なUDVMアルゴリズムについてのパフォーマンス結果を図示する。特に、図12−13は、それぞれ、静的DEFLATEおよびLempel−Ziv−Storer−Szymanski(LZSS)復元アルゴリズムのチャートである。LZSSおよびDEFLATEのアルゴリズムは、標準であり、圧縮システムで知られている。DEFLATEは、Lempel−Ziv1977(LZ77)アルゴリズムおよびホフマン符号化の組み合わせを使用する損失のないデータ圧縮アルゴリズムであり、そして、PKZIPファイル保管ツール(PKZIP archiving tool)のバージョン2について、フィルカッツによって当初は定義され、RFC1951において、のちに規定された。LZSS圧縮がベンチマーキングのために使用されるアルゴリズムのうちの1つであったけれども、本発明は、いかなる特定の圧縮アルゴリズムを必要としない。例示的な候補(candidate)は、動的DEFLATEである。しかしながら、DEFLATEアルゴリズムの複雑さは、LZSSの複雑さよりも大きく、パフォーマンス削減がDEFLATEインプリメンテーションにおいてより大きくなるであろうということを意味している。
【0076】
ここに開示された態様に関連して、様々な説明のための論理、論理ブロック、モジュールおよび回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)あるいは他のプログラマブル論理コンポーネント、ディスクリートゲートあるいはトランジスタロジック、ディスクリートハードウェアコンポーネント、あるいはここに説明された機能を実行するように設計されたそれらの任意の組み合わせで、インプリメントあるいは実行されることができる。汎用プロセッサは、マイクロプロセッサであってもよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、あるいはステートマシン(state machine)であってもよい。プロセッサはまた、コンピューティングコンポーネント(computing components)の組み合わせ、例えば、DSPとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、DSPコアと併用しての1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成、としてインプリメントされてもよい。
【0077】
さらに、ここに開示された実施形態に関連して説明された方法あるいはアルゴリズムのステップは、ハードウェアにおいて、プロセッサによって実行されたソフトウェアモジュールにおいて、あるいはこれら2つの組み合わせにおいて、直接的に具現化されることができる。例えば、方法のステップは、個別の方法ステップを実行することが動作可能なプロセッサの1つまたは複数のモジュールにおいて具現化されることができる。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD−ROMあるいは当技術分野において知られている記憶メディアの任意の他の形態において常駐する(reside)ことができる。例示的な記憶メディアは、プロセッサが記憶メディアから情報を読み取ることができ、また記憶メディアに情報を書き込むことができるように、プロセッサに結合される。別の方法では、記憶メディアは、プロセッサと一体化していてもよい。プロセッサと記憶メディアは、ASICにおいて常駐していてもよい。ASICは、ユーザ端末に常駐していてもよい。代替として、プロセッサと記憶メディアは、ユーザ端末におけるディスクリートコンポーネントとして常駐することができる。さらに、例えば、アルゴリズムあるいは方法のステップは、コンピュータが個別の方法のステップを実施するようにさせることが動作可能な1つまたは複数のセットのインストラクションを有しているコンピュータ可読メディア、を備えているコンピュータプログラムプロダクトにおいて具現化されることができる。
【0078】
図1に戻って参照すると、通信ネットワーク12は、いずれのデータおよび/または音声通信ネットワークを備えることができる。例えば、通信ネットワーク28は、いずれの1つあるいはいずれの組み合わせのすべてあるいはいくつかの部分:有線のあるいは無線の電話ネットワーク、地上波電話ネットワーク、衛生電話ネットワーク、赤外線データ協会(Infrared Data Association)(IrDA)ベースのネットワークのような赤外線ネットワーク、短距離無線ネットワーク、Bluetooth(R)(登録商標)技術ネットワーク、ZigBee(登録商標)プロトコルネットワーク、ウルトラ広域(UWB)プロトコルネットワーク、ホーム無線周波数(a home radio frequency)(HomeRF)ネットワーク、共有された無線アクセスプロトコル(shared wireless access protocol)(SWAP)ネットワーク、無線Ethernet(登録商標)ケイパビリティ協会(wireless Ethernet compatibility alliance)(WECA)、無線フィディリティ協会(wireless fidelity alliance)(Wi−Fi協会)ネットワーク、そして802.xxネットワークのような、広域ネットワーク、パケットデータネットワーク、データネットワーク、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)ネットワーク、公衆交換電話網、インターネットのような公共異種通信ネットワーク、プライベート通信ネットワーク、カリフォルニア州のサンディエゴのクアルコム社から入手可能であるメディアFLO(TM)システムを含んでいる、順方向リンク専用(Forward Link Only)(FLO)ネットワークのようなマルチキャストネットワーク、衛星用のDVB−S、ケーブル用のDVB−C、地上波テレビ用のDVB−T、ハンドヘルドのための地上波テレビ用のDVB−Hのような、デジタルビデオブロードキャスティング(digital video broadcasting)(DVB)ネットワーク、そして、ランドモバイル無線ネットワーク、を備えることができる。
【0079】
さらに、通信ネットワーク28のいくつかの態様に含まれることができる電話ネットワークの例は、符号分割多元接続(CDMA)、広帯域符号分割多元接続(WCDMA)、ユニバーサルモバイルテレコミュニケーションシステム(Universal Mobile Telecommunications System)(UMTS)、アドバンスドモバイル電話サービス(advanced mobile phone service)(AMPS),時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交周波数分割多元接続(OFDMA)、モバイル通信のためのグローバルシステム(GSM)、単一キャリア(1X)無線伝送技術(RTT)、エボリューションデータ専用(EV−DO)技術、汎用パケット無線サービス(GPRS)、増データGSM環境(enhanced data GSM environment)(EDGE)、ハイスピードパケット接続(HSPA)、アナログおよびデジタル衛星システム、そして、データ通信ネットワークと無線通信ネットワークのうち少なくとも1つにおいて使用されることができるいずれの他の技術/プロトコルのような、アナログおよびデジタルネットワーク/技術のいずれの組み合わせ、あるいは、ひとつの少なくとも1部分を含んでいる。
【0080】
様々な開示された態様が図示され説明されてきた一方で、このドキュメントの主題の事柄がこれらの態様のみに限定されていないということが明らかとなるであろう。
【0081】
例えば、簡明にするために、通信デバイス14は、マルチメディアコンテンツ16を受信して(復元して)図示されている。本発明の態様と一致したアプリケーションは、そのようなマルチメディアコンテンツのリバースあるいは2方法の伝送を必然的に伴う。例えば、静止イメージあるいはビデオカメラによって生成された、あるいは、そうでなければ通信デバイス14上で保存されたマルチメディアコンテンツは、通信ネットワーク12にアップロードされることができる。さらに通信ネットワーク12は、これからは通信デバイス14にマルチメディアコンテンツ16を送信するための対応する圧縮アルゴリズムおよび同じバイトコードを利用するために、通信デバイス14によって供給されたバイトコードを検出することにすぐ反応することができる。それによって、通信デバイス14は、UDVMインタープリタ62に頼ることなく、最適化された復元技術がサポートされる、マルチメディアコンテンツ16を受信する可能性を増大することができる。
【0082】
したがって、以上の開示は説明のための態様を示すが、様々な変更および修正が、添付された請求項によって定義されるように、説明された態様の範囲から逸脱することなく、ここになされることができる、ということが注意されるべきである。さらに、説明された態様のエレメントは、単数で、説明され、あるいは請求項で記載されているかもしれないが、単数への限定が明確に述べられていない限り、複数も意図されている。
【0083】
さらに、特定の特徴がいくつかのインプリメンテーションのうちの1つのみに関して開示されてきたが、このような特徴は、いずれの与えられたあるいは特定のアプリケーションについて望まれ、利点があるような、他のインプリメンテーションの1つまたは複数の他の特徴と結合されることができる。用語「含む(includes)」および「含んでいる(including)」およびそれらの変形が詳細な説明あるいは特許請求の範囲のいずれかにおいて使用される限り、これらの用語は、用語「備えている(comprising)」と同様な方法で包括的であるように意図されている。さらに、詳細な説明あるいは特許請求の範囲のいずれかにおいて使用される、用語「あるいは(or)」は、「非排他的、または(non-exclusive or)」であることを意味している。
【0084】
さらに、説明された態様および/またはバージョンのエレメントは、単数で、説明され、あるいは請求項で記載されているかもしれないが、単数への限定が明確に述べられていない限り、複数も意図されている。さらに、いずれの態様および/またはバージョンの全部あるいは一部は、そのように述べられなければ、いずれの他の態様および/またはバージョンの全部あるいは一部で、利用されることができる。
【技術分野】
【0001】
本発明は無線通信のための圧縮方法に関する。
【背景技術】
【0002】
セッションイニシエーションプロトコル(Session Initiation Protocol)(SIP)は、第3世代パートナーシッププロジェクト(Third Generation Partnership Project)(3GPP)リリース5から始まっている、第3世代モバイルネットワークにおいて呼び出し制御のために使用されるプロトコルである。SIPはテキスト符号化(textual encoding)を使用しており、それはSIPに基づいてサービスを作り、SIPへの拡張を設計し、プロトコルをデバッグすることを容易にする。しかしながら、SIPのテキスト符号化は、さらに重大な欠点(drawback)を有しており、SIPメッセージは、例えばモバイル通信のためのグローバルシステム(Global System for Mobile communication)(GSM(登録商標))呼び出し制御において、使用されるプロトコルのものよりも、かなり大きいということはよく知られている。より多くのデータは低帯域幅の無線インタフェースにわたって送信される必要があるので、大きなメッセージサイズは、増大された呼び出しセットアップ遅延を結果としてもたらす。この観察は、呼び出しセットアップ時間を減らすことが出来る解決方法を展開する必要性を作った。そのような1つの解決方法は、インターネット技術タスクフォース(Internet Engineering Task Force)(IETF)によって設計されたシグナリング圧縮(Signaling Compression)(SigComp)プロトコルである。SigCompは、2つのネットワークエレメントの間でアプリケーション層シグナリングの圧縮のためのフレームワークを提供する。SigCompアーキテクチャの中心部分は、ユニバーサルデコンプレッサ仮想マシン(Universal Decompressor Virtual Machine)(UDVM)であり、復元アルゴリズム(decompression algorithms)を実行するために最適化された仮想マシンである。UDVMのために、SigCompは、すべてのSigComp終点(SigComp endpoints)によってサポートされるべき単一のアルゴリズムを命ずる(dictating)代わりに、広範囲の圧縮アルゴリズムをサポートできる。
【0003】
SigCompは、3GPPリリース5 IPマルチメディアサブシステム(IMS)の必須部分である。それは、端末とプロキシ呼び出しセッション制御機能(Proxy Call Session Control Function)(P−CSCF)の間のインタフェースにわたって適用され、それは、IMS内で端末用の第1の接点(contact point)である。SigCompは、呼び出しセットアップのときのアイドル時間を減らすことによってユーザが感じるサービスの質を改善する。それは、さらにネットワークが、加入者ごとの消費されたリソース(resource)の量を減らすことによって、多数のユーザをサポートすることを可能にする。
【0004】
SigCompについての主要なターゲット(primary taeget)は、セルラシステムであり、ここでは、モバイル端末は、さまざまな機能を有しており、検出されていないエラーが、セルラリンク上で導入される可能性がある。SigCompは、また、セルラシステムを含んでいる、限定されたスループットを備えた通信リンクを対応する。
【発明の概要】
【0005】
(米国特許法第119条の下の優先権主張)
この特許出願は、ここでの譲受人に譲渡され、ここにおける参照によりここに明示的に組み込まれる、2006年7月12日に出願された、「SigComp UDVMパフォーマンスの最適化のための方法および装置(“Method and Apparatus for Optimization of SigComp UDVM Performance”)」と題された米国仮特許出願第60/830,545号の優先権を主張する。
【0006】
以下は、開示されたバージョンのさまざまな態様の基本的な理解を提供するために、単純化された概要(summary)を、示す。この概要は、広範囲な全体像ではなく、重要な/決定的なエレメントを識別することも、あるいは、そのようなバージョンの範囲を詳細に描写することも、意図されていない。その目的は、後で示される、より詳細な説明の前置きとして、簡略化された形で説明されたバージョンのいくつかの概念(concepts)を提供することである。
【0007】
一態様は、多数の圧縮アルゴリズムのうちの1つによって圧縮されたデータコンテンツ(data content)を通信することを提供する。各圧縮アルゴリズムは、圧縮されたデータコンテンツからデータコンテンツを作ることが出来る、対応する復元アルゴリズムを有する。増大された柔軟性を与えるために、復元アルゴリズムを実行するのに十分なバイトコードは、バイトコードを解釈するために復元仮想マシンについて意図された圧縮されたデータコンテンツに沿ってデータパケットプロトコルの一部として、送信される。復元アルゴリズムを解釈するのに必要とされた、プロセッシング時間を減らすことによってユーザ経験を高めるために、検出されたバイトコードに関連づけられたマシンコードにおける、復元アルゴリズムのアクセス可能で実行可能なバージョンは、位置づけられ(located)、仮想マシンを使用することよりもむしろデータコンテンツを復元するために、使用される。
【0008】
さらに別の態様においては、少なくとも1つのプロセッサは、復元ソースコードの実行可能なバージョンを位置づけることによって、データコンテンツを復元する方法を実行するように、コンフィギュアされる。特に、第1のモジュールは、ソースコードを検出する。第2のモジュールは、ソースコードに関連づけられた復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づける。第3のモジュールは、復元アルゴリズムの位置づけられたアクセス可能で実行可能なバージョンを利用して、圧縮されたデータコンテンツを復元する。
【0009】
追加の態様において、コンピュータプログラムプロダクトは、コンピュータが少なくとも1つのメッセージにおいて含まれたソースコードをコンピュータが検出するようにさせるための第1セットのコードを含んでいる、コンピュータ可読メディアを有する。第2セットのコードは、コンピュータが、検出されたソースコードに関連づけられた対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づけるようにさせるためである。そのあと、第3セットのコードは、対応する復元アルゴリズムの位置づけられたアクセス可能で実行可能なバージョンを利用して、圧縮されたデータコンテンツをコンピュータが復元するようにさせるためである。
【0010】
さらに別の態様において、マシンコードへのバイトコードの初期コンパイレーションのための手段は、復元アルゴリズムの非常に効率的な実行を提供する。例えば、信号圧縮(SigComp)を使用して圧縮されたセッションイニシエーションプロトコル/セッション記述プロトコル(SIP/SDP)メッセージで、この方法を使用することは、メッセージの呼び出しセットアップ時間と処理の待ち時間(the latency of the processing and call setup times of the message)を短くするであろう。
【0011】
1つのインプリメンテーションにおいては、メカニズムは、受信された各SIP/SDPメッセージの復元のためのユニバーサル復元仮想マシン(UDVM)インタープリタ(interpreter)を実施することを回避するように提供されている。UDVMインタープリタの実行を回避することは、モバイル局上の計算の必要要件を減らし、そして、SIP/SDPプロセッシングにおける潜在的な遅延を減らす。このアプローチは、SIPベースの呼び出しフローのために、呼び出しセットアップ/分解時間を繰り返す。
【0012】
別の態様において、通信デバイスに、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツ(Internet Protocol(IP) Multimedia Subsystem(IMS) data content)を広める方法は、圧縮アルゴリズムでIMSデータコンテンツを圧縮することを備えている。方法は、復元バイトコードを含んでいる、データストラクチャを生成することと、通信デバイス(communication device)に対して、圧縮されたIMSデータコンテンツおよび復元バイトコードを送信することと、をさらに含んでいる。さらに、方法は、通信デバイスからのリクエストにすぐ反応する(responsive)通信デバイスに対して、復元バイトコードの実行可能なバージョンを送信すること、を含んでいる。
【0013】
一態様において、通信デバイスに、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを広めるようにコンフィギュアされた少なくとも1つのプロセッサは、圧縮アルゴリズムでIMSデータコンテンツを圧縮するための第1モジュールを備えている。少なくとも1つのプロセッサは、復元バイトコードを含んでいるデータストラクチャを生成するための第2モジュール、そして、圧縮されたIMSデータコンテンツと復元バイトコードを通信デバイスに対して送信するための第3モジュール、をさらに含んでいる。さらに、少なくとも1つのプロセッサは、通信デバイスからのリクエストにすぐ反応する通信デバイスに対して、復元バイトコードの実行可能なバージョンを送信するための第4のモジュール、を含んでいる。
【0014】
さらなる態様においては、コンピュータプログラムプロダクトは、複数のセットのコードを備えている、コンピュータ可読メディアを含む。第1セットのコードは、圧縮アルゴリズムでインターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを、コンピュータが圧縮するようにさせることが動作可能である。第2セットのコードは、復元バイトコードを含んでいるデータストラクチャを、コンピュータが生成するようにさせることが動作可能である。第3セットのコードは、通信デバイスに対して、圧縮されたIMSデータコンテンツおよび復元バイトコードを、コンピュータが送信するようにさせることが動作可能である。そして、第4セットのコードは、通信デバイスからのリクエストにすぐ反応する通信デバイスに復元バイトコードの実行可能なバージョンをコンピュータが送信するようにさせることが動作可能である。
【0015】
別の態様では、通信デバイスに、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを広めるための装置(apparatus)は、圧縮アルゴリズムでIMSデータコンテンツを圧縮するための手段を備えている。装置は、さらに、復元バイトコードを含んでいるデータストラクチャを生成するための手段と、圧縮されたIMSデータコンテンツと復元バイトコードを通信デバイスに送信するための手段と、を含んでいる。さらに、装置は、通信デバイスからのリクエストにすぐ反応する通信デバイスに復元バイトコードの実行可能なバージョンを送信するための手段、を含んでいる。
【0016】
前述および関連する目的の実現のために、1つまたは複数のバージョンは、この後十分に説明され、そして特許請求の範囲において特に示される、特徴を備えている。以下の説明および添付図面は、詳細に、ある説明のための態様を記述しており、そして、バージョンの原理(principles)が使用されることができる様々な方法のうちのほんの少しを示している。他の利点および新規な特徴は、図面と共に考慮されるとき、以下の詳細な説明から明らかとなるであろう、また、開示されたバージョンは、すべてのそのような態様およびそれらの同等物(equivalents)を含むように意図されている。
【図面の簡単な説明】
【0017】
【図1】図1は、通信ネットワークと通信中である無線デバイスのための信号圧縮最適化システムのブロック図である。
【図2】図2は、図1のシステムの無線デバイスのコンポーネントの一態様の概略図である。
【図3】図3は、第三世代パートナーシッププロジェクト(3GPP)リリース5ネットワークアーキテクチャのさらなる特徴を図示している図1の通信ネットワークと無線デバイスの図である。
【図4】図4は、図1の信号圧縮最適化システムのためのインターネットプロトコル(IP)マルチメディアサブシステム(IMS)のエンティティのコンフィギュレーション図である。
【図5】図5は信号圧縮(SigComp)の終点のロケーションのブロック図である。
【図6】図6は、図5のSigCompの終点のアーキテクチャのブロック図である。
【図7】図7は、図1のシステムによってインプリメントされた信号圧縮最適化の方法のフロー図である。
【図8】図8は、図1の無線デバイスのためのオペレーションの信号圧縮最適化シーケンスのバージョンを図示している図である。
【図9】図9は、図1の無線デバイスのためのオペレーションの信号圧縮最適化シーケンスのバージョンを図示している図である。
【図10】図10は、図1の信号圧縮最適化システムのバージョンを図示している図である。
【図11】図11は、図1の信号圧縮最適化システムのバージョンを図示している図である。
【図12】図12は静的なDEFLATEパフォーマンスを図示しているチャートである。
【図13】図13は、Lempel−Ziv−Storer−Szymanski(LZSS)圧縮アルゴリズムのパフォーマンスを図示しているチャートである。
【発明を実施するための形態】
【0018】
様々な態様が、図面を参照して記述されている。以下の説明においては、説明の目的のために、多くの具体的な詳細な説明が、1つまたは複数の態様の完全な理解を提供するために、示されている。しかしながら、様々な態様は、これらの具体的な詳細なしで実行されることができるということは明白であり得る。他の例においては、よく知られたストラクチャおよびデバイスは、これらのバージョンを簡略に説明するために、ブロック図の形で示されている。
【0019】
装置および方法は、特に、ワイヤレス環境における使用についてよく適していてもよいが、通信ネットワーク、公共ネットワーク、例えばインターネット、プライベートネットワーク、例えば仮想プライベートネットワーク(virtual private networks)(VPN)、ローカルエリアネットワーク、広域ネットワーク、ロングホールネットワーク(long haul networks)、あるいはいずれの他のタイプのデータ通信ネットワーク、を含むがこれに限定されるものではない、いずれのタイプのネットワーク環境において適していてもよい。
【0020】
図1は、通信ネットワーク12と無線ユーザ機器(通信デバイス)14の間の信号圧縮最適化システム10の1つの態様を図示している。通信ネットワーク12内では、マルチメディアコンテンツ(multimedia content)16として図示される、メディアあるいはシグナリング(例えばオーディオ、イメージ、ビデオ、ブライユ等)(一般的には「データ」)は、データ圧縮アルゴリズム20を利用してコンプレッサ18によってデータ圧縮をする(undergoes)。データ復元バイトコード22は、ユーザ機器14の無線通信リンク28に、圧縮されたメディアコンテンツ(compressed media content)26が続く無線通信リンク24による無線送信に適切な形式でソースコードまたはバイトコードを提供する。受信されたバイトコード22にすぐ反応するプロセッサ30は、仮想マシンデコンプレッサの使用を各インスタンスにおいて回避するために、減らされたセットアップの待ち時間について便利であるとき、最適化されたデコンプレッサ32を有効に選択する。代替的に、インプリメンテーションは、最適化されたデコンプレッサ32がアクセス可能でない場合、インスタンスを有することができる。プロセッサ30は、そのあと、ユニバーサルデコンプレッサ仮想マシン(UDVM)34として図示される、仮想マシンデコンプレッサを選択することができる。UDVM34は、例えば受信されたバイトコード22`によって命令されたように、復元アルゴリズムの範囲を柔軟に実行することができる、一般化されたアーキテクチャを有する、しかしながら、UDVM34は、いずれの特定の復元アルゴリズムについて最適化されず、実行前にバイトコード22において各ステートメントを分析することに関連づけられた必要条件遅延によって苦しむ(suffer)。
【0021】
このような実行遅延の有効的な回避を実行するために、プロセッサ30は、バイトコード22``のアクセス可能なコピーは、受信されたバイトコード22``と同じであるということを認識する。バイトコード`を実行するための、実行可能な復元アルゴリズム38の一部としてマシンコード36は、そのあと、最適化されたデコンプレッサ32によって使用される。マシンコード36および/または最適化されたデコンプレッサは、仮想マシンにおいてソースコード(例、バイトコード22`)を解釈することと比較して、復元のための減らされた時間について最適化される。可能なときいつでも、UDVM34の使用を回避することができることによって、ユーザ機器14は、遅延されたセットアップを回避することによってメディアコンテンツプレイヤー38上でメディアコンテンツ(media content)16を表わすことにおいてユーザ経験を高める。
【0022】
マシンコード36は局所的に保存されたライブラリの一部としてアクセスされることができ、局所的にコンパイルされ、今後の使用のために保存されることができ、遠隔ライブラリから無線でアクセスされることができ、リクエストのとき遠隔にコンパイルされ、今後の使用について保存されることができ、および/または、ファームウェアあるいは、最適化されたデコンプレッサに組み込まれた回路構成の他の形として提供されることができるということが、本開示の利益を用いて理解されるべきである。遠隔にコンパイルされたマシンコード36および/またはコンパイルすることにおける遅延は、無線ユーザ機器14についての減らされた複雑さの必要要件と、UDVMにわたって進行中の復元効率性と、における利益によって、相殺されるであろう。
【0023】
いくつかの態様によると、通信デバイス14は、いずれのタイプのコンピュータ化された、コミュニケーション装置を備えることができる。例えば、図1で示されるように、通信デバイス14は、無線のおよび/またはセルラ電話のような、モバイル通信デバイスを備えることができる。代替的に、通信デバイス14は、プロキシ呼び出し/セッション制御機能(P−CSCF)サーバ、ネットワークデバイス、サーバ、コンピュータワークステーション等のような、固定された通信デバイスを備えてもよい。通信デバイス14は、このような説明されたあるいは図示されたデバイスに通信デバイスが限定されないが、携帯情報端末(Personal Digital Assistant)(PDA)、2方法テキストページャ(two-way text pager)、有線あるいは無線通信ポータルを有するポータブルコンピュータ、そして、有線および/または無線の通信ポータルを有するいずれのタイプのコンピュータプラットフォームをさらに含んでいるということは、理解されるべきである。さらに、通信デバイス14は、遠隔センサ、遠隔サーバ、診断ツール、データリレー(data relays)、そして同様のもの、のような遠隔スレーブ(remote-slave)あるいは他の同様デバイスであってもよく、それらのエンドユーザを有さず、無線あるいは有線ネットワークにわたってデータを単に通信する。代替的な態様においては、通信デバイス14は、陸線電話、パーソナルコンピュータ、セットトップボックス、あるいは同様のもののような、有線通信デバイスであってもよい。さらに、単一のタイプあるいは複数の前述のタイプの、任意の数の通信デバイス14のいずれの組み合わせがシステム10において利用されることができるということは、留意されるべきである。したがって、本装置および方法は、有線あるいは無線の通信ポータルを含み、無線モデム、PCメモリカード国際協会(Personal Computer Memory Card International Association)(PCMCIA)カード、アクセス端末、パーソナルコンピュータ、電話、あるいは、それらのいずれの組み合わせ、あるいは、サブコンビネーション(sub-combination)を限定されることなく含んでいる、いずれの形態の有線あるいは無線デバイスあるいはコンピュータモジュール上で、それに応じて実行されることができる。
【0024】
さらに、通信デバイス14は、マルチメディアコンテンツ16をリクエストする、マルチメディアコンテンツ16と相互に作用する、および/またはマルチメディアコンテンツ16をプレイする(playing)ような目的のために、ユーザインタフェース42を含むことができる。このユーザインタフェース42は、通信デバイス14への入力を生成するあるいは受信するのに動作可能な入力デバイス44と、通信デバイス14のユーザによる消費のための情報を生成するおよび/または表わすのに動作可能な出力デバイス46と、を含む。例えば、入力デバイス44は、キーパッドおよび/またはキーボード、マウス、タッチスクリーンディスプレイ、音声認識モジュールに関連づけられたマイクロホン、等のような、少なくとも1つのデバイスを含むことができる。ある態様においては、入力デバイス44は、コンテンツについてのリクエストのユーザ入力、あるいは、追加情報についてのリクエストのユーザ入力、を提供することができる。さらに、例えば、出力デバイス46は、ディスプレイ、オーディオスピーカ、触覚フィードバックメカニズム(haptic feedback mechanism)等を含むことができる。出力デバイス46は、グラフィカルユーザインタフェース、サウンド、バイブレーションのような感覚、等、を生成することができ、そして、そのような出力は、例えば、マルチメディアコンテンツ16の表示に関連付けられることができる(図1)。
【0025】
さらに、通信デバイス14は、デバイスに対して機能性を提供するためにアプリケーションを実行することが動作可能なコンピュータプラットフォーム48を含むことができ、そして、さらに入力デバイス44と出力デバイス46と相互作用することができる。コンピュータプラットフォーム48は、メモリ50を含むことができ、それは、揮発性および不揮発性メモリ部分、例えば読み出し専用および/またはランダムアクセスメモリ(RAMとROM)、電子的消去可能PROM(EEPROM)、フラッシュメモリ、および/またはコンピュータプラットフォームに共通したいずれのメモリ、を備えることができる。さらに、メモリ50は、磁気メディア、光学メディア、テープ、および/またはハードディスク、そしてリムーバブルメモリコンポーネントのような、いずれの第2の、および/または、第3のストレージデバイスと電子ファイルシステムを含んでいる、アクティブメモリとストレージメモリを含むことができる。
【0026】
さらに、コンピュータプラットフォーム48は、プロセッサ52も含むことができ、それは、特定用途向けIC(application-specific integrated circuit)(ASIC)、あるいは他のチップセット、プロセッサ、論理回路、あるいは他のデータ処理デバイスであってもよい。いくつかの態様においては、例えば通信デバイス14がセルラ電話を備えるとき、ASICのような他の論理あるいはプロセッサ52は、メモリ50において、メディア関連アプリケーションと、データ呼び出し、音声呼び出しのようないずれの常駐のソフトウェアコンポーネントとインタフェースでつなぐ(interfaces with)、アプリケーションプログラミングインタフェース(application programming interface)(API)層54を実行することができる。API 54は、個別の通信デバイス上で実行する、実行時間環境であってもよい。1つのそのような実行時間環境は、カリフォルニア州のサンディエゴのクアルコム株式会社によって展開された、無線のためのバイナリ実行時間環境(Binary Runtime Environment for Wireless(R))(BREW(R))ソフトウェアである。他の実行時間環境は、例えば無線コンピューティングデバイス上でアプリケーションの実行を制御することを操作することが利用されることができる。
【0027】
さらに、プロセッサ52は、通信デバイス14の機能性および通信ネットワーク28上の通信デバイスの動作性(operability)を可能にする、ハードウェア、ファームウェア、ソフトウェアおよびそれらの組み合わせにおいて具現化された様々な処理サブシステム56を含んでいてもよい(図1)。例えば、処理サブシステム56は、通信デバイス14のコンポーネント内および/または中同様、他のネットワーキングされたデバイスで、通信をイニシエートすることおよび維持すること、そしてデータを交換すること、を可能にする。一態様において、例えばセルラ電話において、プロセッサ52は、1つの処理サブシステム56または複数の処理サブシステム56の組み合わせを含むことができ、例えば:音声、不揮発性メモリ、ファイルシステム、送信、受信、サーチャ(searcher)、層1、層2、層3、メイン制御、遠隔プロシージャ(remote procedure)、ハンドセット、パワーマネジメント、診断、デジタルシグナルプロセッサ、ボコーダ、メッセージング、コールマネージャ、Bluetooth(R)(登録商標)システム、Bluetooth(R)(登録商標)LPOS、ポジション決定、ポジションエンジン、ユーザインタフェース、スリープ、データサービル、セキュリティ、認証(authentication)、USIM/SIM(ユニバーサル加入者識別モジュール/加入者識別モジュール)、音声サービス、グラフィックス、USB(ユニバーサルシリアルバス)(universal serial bus)、MPEG(ムービングピクチャエキスパートグループ)(Moving Picture Experts Group)プロトコルマルチメディアのようなマルチメディア、GPRS(汎用パケット無線サービス)(General Packet Radio Service)、ショートメッセージサービス(SMS)、ショートボイスサービス(SVS(TM))、ウェブブラウザ等がある。開示された態様については、プロセッサ52のプロセッシングサブシステム56は、コンピュータプラットフォーム48上で実行するアプリケーションと相互作用するいずれのサブシステムコンポーネントを含むことができる。開示された態様については、プロセッサ52のプロセッシングサブシステム56は、コンピュータプラットフォーム48上で実行しているアプリケーションと相互作用する、いずれのサブシステムコンポーネントを含むことができる。
【0028】
コンピュータプラットフォーム48は、通信ネットワーク28(図1)と通信デバイス14との間のコンテンツリクエストと、コンテンツ24(図1)を交換することが動作可能であることに加えて、通信デバイス14の様々なコンポーネント間の通信を可能にする、通信モジュール58をさらに含むことができる。通信モジュール58は、ハードウェア、ファームウェア、それのソフトウェアおよび/またはそれらの組み合わせにおいて具体化されてもよく、そして、イントラデバイス通信およびインターデバイス通信における使用のためのすべてのプロトコルをさらに含むことができる。さらに、通信モジュール58は、ここに説明されている装置および方法にしたがって、情報を送信する、および/または受信することが動作可能であり、例えば、マルチメディアコンテンツ16(図1)をリクエストし、圧縮されたメディア/シグナリングコンテンツ28およびバイトコード22`(図1)を受信する。
【0029】
いくつかの態様において、通信デバイス14のメモリ50は、バックグラウンドプロセスあるいはフォアグラウンドプロセスにおいて、通信ネットワーク12にわたって、マルチメディアコンテンツ16をリトリーブし(retrieve)、保存し、そしてプレイすることが動作可能な、ユーザインタフェースモジュール60をさらに記憶することができる。ユーザインタフェースモジュール40は、ユーザインタフェース42の機能とマルチメディアコンテンツ16のタイプに適切であるメディアプレイヤーを含んでいる、これらの機能を実行することが動作可能で実行可能なインストラクションとデータ、ハードウェア、ソフトウェア、ファームウェアのうちの1つあるいはいずれの組み合わせ、を備えることができる。
【0030】
図3−6を参照すると、信号圧縮最適化システム10の使用の例示的な環境として、ネットワークアーキテクチャ100は、IPマルチメディアサブシステム(IMS)ネットワークのための第3世代パートナーシッププロジェクト(3GPP)と3GPP2標準規格によって指定され、そして、RFC3320、RFC3321およびIMSについての3GPP標準規格(例、3GPP TS 23.228)において定義される、特定タイプの信号圧縮(SigComp)を実行するために開示されている。図3において、ユニバーサルな方法(universal method)は、モバイル通信デバイス(SIPユーザエージェント)と、プロキシ呼び出し/セッション制御機能(P−CSCF)の間で、無線上で送られたSIPシグナリングメッセージを圧縮する。これは、送信された第1メッセージの一部として、復元パーティ(de-compressing party)に復元アルゴリズムを送信している、圧縮パーティ(compressing party)を含む。アルゴリズム(バイトコード22`)を受信するとき復元パーティ(通信デバイス14)は、受信されたバイトコード22`を解釈するメモリ50において、ユニバーサルデコンプレッサ仮想マシン(UDVM)インタープリタ64を実行し、以下のメッセージ(圧縮されたメディア/シグナリングコンテンツ28)を復元する。このアプローチの利点は、そのバイトコードが無線上で供給されているかぎり、いずれの種類のアルゴリズムをサポートする能力(ability)である。例示的なバージョンにおけるメモリ50の呼び出し制御モジュールは、この通信用のプロトコルを定義する、ローカルセッションイニシエーションプロトコル(SIP)とセッション記述プロトコル(SDP)アプリケーション66である。
【0031】
UDVMインタープリタにおいて復元バイトコードを実行することから生じる計算的なオーバーヘッドは、バイトコードにおける各インストラクションが解釈されるとき、遅延を引き起こし、それは、延期呼び出しセットアップ時間のためユーザ経験を損なう(impair)可能性がある。メモリ50におけるデコンプレッサディスパッチャモジュール68は、UDVMインタープリタ64の使用を減らすことによる、通信デバイス14のコンピュータプラットフォーム48によってサポートされた1つまたは複数の最適化インプリメンテーションによって、この遅延を有効に軽減する。
【0032】
第1のインプリメンテーションとして、メモリ50における最適化されたデコンプレッサモジュール70によって実行されることができるマシンコードへのバイトコード22の初期のコンパイレーションは、復元アルゴリズムの非常に効率的な実行を提供する、したがって、次のSIPメッセージプロセッシングおよび呼び出しセットアップ時間の待ち時間(the latency of following SIP messages processing and call setup times)を短くする。その目的のために、デコンプレッサディスパッチャモジュール68は、それぞれが個別の復元マシンコード36と対になる、1つまたは複数の局所的にアクセス可能なバイトコード22``と、受信されたバイトコード22`を比較するために、復元ライブラリ72にアクセスする。マッチ(match)の検出のとき、復元マシンコード36は、UDVMインタープリタ64よりもむしろ最適化されたデコンプレッサモジュール70によって実施されることができる。
【0033】
第2のインプリメンテーションとして、デコンプレッサディスパッチャモジュール68がマッチを検出するのに失敗する新しい受信されたバイトコード22`について、デコンプレッサディスパッチャモジュール68は、それぞれ復元ライブラリ72における、空コードストレージレコード76および空きインデクス78におけるバイトコード22`に沿ってそのあとで保存される、復元マシンコード36を生成するためにメモリ50のコンパイラ74を方向づける。このコンパイレーションは、このバイトコード22`の今後のインスタンスが第1のインプリメンテーションによって取り扱われることができるように、バックグラウンドにおいて生じうる。
【0034】
第3のインプリメンテーションとして、第2のインプリメントにおけるようにマッチを検出するのに失敗するとき、デコンプレッサディスパッチャモジュール68は、外部でコンパイルされるべき、あるいは、今後のインスタンスのための復元マシンコードの周期的にアップデートされたデータベースからリトリーブされるべき、バイトコード22`についてのリクエストを転送する。
【0035】
第4のインプリメンテーションとして、コンピュータプラットフォーム58は、復元について最適化されたデバイスハードウェアにおけるパラレル処理(parallel processing)を可能にすることによってより早いセットアップを容易にする、UDVMハードウェアプロセッサ(例、デジタル信号プロセッサ(DSP))80を有効に含むことができる。デコンプレッサディスパッチャモジュール68は、ローカルのSIP/SDPアプリケーション66の利益についてUDVM64をエミュレートする(emulate)ためにプロキシUDVM82を利用する。
【0036】
図3−6においては、一般に、3GPP TS 23.338、3GPP TS 23.002において説明される3GPPリリース5ネットワークアーキテクチャと一致した(consistent with)通信ネットワーク100は、図1−2の信号圧縮最適化システム10のための操作環境を提供する。特に図3を参照すると、通信ネットワーク100は、コアネットワーク(CN)インフラストラクチャ102と、アクセスネットワーク(AN)インフラストラクチャ104に論理的に分けられる。CNインフラストラクチャ102は、回路スイッチされた(Circuit Switched)(CS)ドメイン106、パケットスイッチされた(Packet Switched)(PS)ドメイン108と、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)110に、論理的に分けられる。UMTS地上波無線アクセスネットワーク(UTRAN)インタフェース104として図示される、ANインフラストラクチャ104は、エレメントが無線ネットワークコントローラ(RNC)114、ノードBエレメント116、そしてユーザ機器(UE)118である、階層無線ネットワークサブシステム(RNS)112によって、形成される。ノードB116は、1つまたは複数のセルをサーブする(serves)論理的なネットワークコンポーネントである。それは、無線セルにおける通信用の、無線伝送/受理ユニットである。RNC114は、1つまたは複数のノードBエレメント116の制御のための機能を備えたネットワークコンポーネントである。RNC114は、複数のUTRANインタフェース104間で、プロトコル交換を扱っている。RNC114は、オペレーションサポートシステムへのアクセスを含む(示されていない)、無線ネットワークサブシステム112の中心化されたオペレーションおよびメンテナンスを提供する。数ある中で、RNC114の機能は、無線リソース制御、アドミッション制御、チャネル割り当て(channel allocation)、ハンドオーバー制御を含む。回路スイッチされたドメイン106に特有のエンティティは、シグナリングゲートウェイ(SGW)119、モバイルスイッチングセンタ(MSC)120、そしてゲートウェイモバイルスイッチングセンタ(Gateway Mobile Switching Centre)(GMSC)122を信号で通信している(signaling)。CSスイッチされたドメイン106は、さらに、このタイプのシグナリングに条件づけられた(constrained)特定のホーム加入者サービス123を含むことができる。MSC120は、無線ネットワークサブシステム112と固定されたネットワークとの間でインタフェースを構成する。GMSC122は、モバイル局(ユーザ機器(UE))118の実際のロケーションへのルーティング(routing)を実行するMSC120である。パケットスイッチされたドメイン108に特定されたエンティティは、サービングGPRSサポートノード(SGSN)124と、ゲートウェイGPRSサポートノード(GGSN)126である。SGSN124およびGGSN126はパケットトラフィック(packet traffic)を扱う。SGSN124は、そのサービスエリア内でモバイル局118にパケットを運ぶ。SGSN124は、1つのセルにおけるユーザ機器118から別のセルにおける機器へと、ローミング加入者(roaming subscriber)をハンドオフする(handing off)ような、モビリティマネジメント機能を実行する。GGSNs126は、パブリックインターネット128、他のモバイルサービスプロバイダのGPRSサービス(ホーム加入者サービス(HSS))130、あるいは、企業イントラネット(示されていない)のような、外部IPネットワークへのインタフェースとして使用される。GGSNs126は、特定のモバイル局122をサービスするSGSNs124に対して、プロトコルデータユニット(PDUs)のトンネリングする(tunnel)のに必要である、ルーティング情報を維持する。
【0037】
IMSコアネットワーク110のIPマルチメディアサブシステム(IMS)エンティティは、モバイルインターネットパラダイム(mobile Internet paradigm)にしたがって、多様なマルチメディアサービスを展開する一般のプラットフォーム(common platform)を作るために、第3世代パートナーシッププロジェクト(3GPP)リリース5の一部として導入された。IMSエンティティは、IPマルチメディア(IM)サービスの供給のためにすべてのコアネットワークエレメントを備え、それらは、例えば、呼び出しセッション制御機能(CSCF)130(すなわち、問い合わせ(Interrogating)、プロキシ、そしてサービング)、IMSメディアゲートウェイ機能(Media Gateway Function)(MGW)131、メディアゲートウェイ制御機能(MGCF)132、そしてマルチメディアリソース機能133である。3GPPごとのIMS CN110は、標準化されたインタフェースによって定義されるようにノードよりもむしろ機能を標準化させる。インプリメンタ(Implementers)は、自由に、2つの機能を単一のノードに組み合わせる、あるいは、2つまたは複数のノードに単一の機能を分けることができる。IMS CN110は、公衆交換電話網(PSTN)134とHSS130のような他のUMTSネットワークのような他のネットワークへの相互接続同様、音声とマルチメディア呼び出しおよびセッション(voice and multimedia calls and sessions)を制御するドメインである。それは、異なる経路をトラバースする、メディアプレーンとシグナリングプレーンを有する。
【0038】
SigCompはIMS CN 110の一部であり、それはSIPシグナリングトラフィックを圧縮するために使用される。IPマルチメディア(IM)ドメインは、コスト削減と新しいサービスの導入を可能にする、例えば、ボイス電話方式、ビデオ電話方式、マルチメディア会議、インスタントメッセージング、そしてリアルタイムインタラクティブゲームである。IMSは、無線ユーザのためのボイス、ビデオ、メッセージング、データおよびウェブベースの技術の収斂(convergence of)およびそれらへのアクセスを可能にし、そして、モバイル通信における成長とインターネットの成長を結合する。IPマルチメディアコアネットワークサブシステム(IMS)は、パブリックランドモバイルネットワーク(PLMN)オペレータがインターネットアプリケーション、サービス、およびプロトコルに基づいた、そして、構築した(built upon)それらの加入者マルチメディアサービスをオファすること(offer)を可能にする。マルチメディアシグナリングおよびベアラトラフィック(bearer traffic)をトランスポートするために、パケットスイッチされたドメインを利用する。パケットスイッチされたドメインは、端末が移動しIMSから動きを隠している間、サービスを維持する。IMSは、回路スイッチされたドメインから独立している。IMドメインは、ユーザとアプリケーションが、マルチプルパーティ間でセッションおよび呼び出しを制御することを可能にする。呼び出しについて必要とされる機能性、セキュリティ、そして質を提供するために、ネットワークリソースを制御し、サポートする。IMドメインは、いずれのUMTSネットワークからそれらがそれら自体のサービスにアクセスすることができるように、ユーザの登録のために、提供する。IMの1つの追加的な役割は、呼び出し参与者(call participants)についての情報、時間、送信且つ受信されたデータの持続時間および容量を含む、呼び出し詳細レコード(Call Detail Records)(CDRs)を生成することである。CDRsは、目的を満たす(charging)ために使用される。
【0039】
図4においては、3GPP TS 23.228ごとのIMSエンティティは、CSCF、MGCF、IMSメディアゲートウェイファンクション(IMS Media Gateway Function)(IMS−MGW)、マルチメディアリソースファンクションコントローラ(MRFC)、マルチメディアリソースファンクションプロセッサ(MRFP)、サブスクリプションロケータファンクション(Subscription Locator Function)(SLF)、ブレイクアウトゲートウェイ制御機能(BGCF)およびアプリケーションサーバ(AS)を含んでおり、なお、ユーザトラフィックをサポートしているインタフェースは、太い線で示されており、シグナリングをサポートしているインタフェースは点線で描かれている。
【0040】
IMSエンティティの役割は、3GPP TS 23.228において説明されている。SIPサーバである、CSCFは、プロキシCSCF(P−CSCF)、サービングCSCF(S−CSCF)138あるいは問い合わせCSCF(I−CSCF)として動作できる。P−CSCFは、IMS CNのためのUEの第1接点である。SigCompメッセージの圧縮および復元を実行するコアネットワークエレメントであるので、SigCompに特別に重要である。このために、P−CSCFは、コンプレッサとデコンプレッサを含む(IMS端末もまた両方を含んでいる)。I−CSCFの役割が特定のユーザのために適切なS−CSCFを見つけることである一方で、S−CSCFは、ネットワークにおいてセッションステートを扱う。MGCFは、プロトコル転換(conversion)を実行し、帯域情報から受信し、CSCFと通信し、CSCFを選択し、呼び出しステートの一部を制御する。IMS−MGWは、スイッチされた回路ネットワークからベアラチャネルを、そして、パケットネットワークからメディアストリームを、終わらせる(terminates)。それは、メディア転換、ベアラ制御、そしてペイロード処理を扱う。MRFCのタスクは、MRFPにおけるメディアストリームリソースを制御し、CDRsを生成し、そして、ASとS−CSCFから来る情報を解釈し、それに応じてMRFPを制御することである。
【0041】
MRFPは、MRFCによって制御されるリソースを提供し、Mbリファレンスの点上でベアラを制御し、メディアストリームをミックスし(mixes)、ソースし(sources)、処理する。登録とセッションのセットアップの間(during)、I−CSCFによってリクエストされるとき、SLFは、必要とされる加入者特定データを含んでいるHSSの名前を供給する。それはさらに登録プロセスの間に、S−CSCFによってクエリされる。BGCFは、PSTNブレイクアウトが生じる予定のネットワークを選択し、使用されるMGCFを選択する。ASは、SIPアプリケーションサーバ、オープンサービスアクセス(OSA)アプリケーションサーバあるいはモバイルエンハンスされたロジックについてのカスタマイズされたアプリケーション(a Customized Application for Mobile Enhanced Logic)(CAMEL)IPマルチメディアサービススイッチング機能(IM−SSF)であってもよい。それは、IMサービスを加えた値をオファする。S−CSCFとASとの間のインタフェースは、ASにおいて常駐しているサービスを提供するために使用される。
【0042】
IPマルチメディアサブシステムは、アクセス独立を達成するために、そして、3GPP TS 23.228ごとのインターネットにわたって電話線(wireline)端末を用いて円滑なオペレーションを維持するために、インターネット技術タスクフォース(IETF)インターネット標準規格に整合(conformant)することを試みる。IMドメインにおいて登録および呼び出し制御のために使用されるシグナリングプロトコルは、セッションイニシエーションプロトコル(SIP)である。SIPは、UEとCSCFとの間で適用される単一のプロトコルである。
【0043】
図5においては、端末に送られたメッセージを圧縮し、端末から受信されたメッセージを復元するエンティティは、P−CSCFであり、UEからS−CSCFまでのSIPシグナリングフローとして描かれている。UEにおいてSigCompで圧縮されたSIPメッセージは、無線インタフェース、UMTS地上波無線アクセスネットワーク(UTRAN)の無線ネットワークコントローラ(RNC)と基地局(BS)を通じて流れる(flow)。SigCompメッセージが復元される場合、UTRANから、それらは、サービングGPRSサポートノード(SGSN)とゲートウェイGPRSサポートノード(SGSN)を通じて、P−CSCFまでトラバースする。P−CSCF前方(onwards)から、SIPメッセージは、非圧縮された状態で送られる。無線アクセスネットワークからよりもむしろネットワークコアから、SigComp圧縮および復元を実行するエンティティを選択することを支持した理由が以下で説明されている。まず初めに、圧縮は、暗号化および暗号解読の点からバウンドして適用されなくてはならず、透過的でなくてはならないので、トラフィック暗号化および暗号解読(decryption)機能のロケーションはさらに、圧縮機能のロケーションに影響を与える。いくつかのトラフィックタイプのパケットコンテンツ(packet content)は、認証されており、完全保護されている、あるいは、暗号化されている。端末からトラフィックを解読し、端末に暗号化する、信頼されたパーティは、モバイルネットワークコアにおいて存在する。もし終点(endpoint)が無線アクセスネットワークから選ばれた場合には、ネットワークデザインおよびパフォーマンスは、モバイルネットワーク内でメッセージキーをトランスファすることによって加えられるであろう複雑さから苦しむであろう。シグナリング圧縮のロケーションに影響を与える別の重要な問題は、ハンドオーバー(handover)である。SigCompにおいては、比較的大きい量の史的なステートが、効率的な圧縮を可能にするために確立される(built up)。復元を実行している終点が変わった場合、このステートは、圧縮効率を維持するために新しいエンティティにトランスファされることが必要となるであろう。この種類の解決方法は、ネットワークに複雑さを付け加えるであろう。復元がP−CSCFにおいて実行されるとき、復元終点(decompressing endpoint)は、アプリケーション層セッションの持続期間について安定したままである。
【0044】
したがって、SigComp機能のロケーションは、モバイル端末にあり、そしてネットワークの内部にあり、すなわちIMSにある。このアプローチは、ヘッダ圧縮と対比しており、圧縮機能は、端末において、そして、無線アクセスネットワークにおいて、位置づけられている。SigCompのケースにおいては、メッセージは、ルーティング情報を含まない、アプリケーションレベルのメッセージである。それらは、トランスポート層プロトコルのペイロードにおいて、搬送され、代わりにIPへのルーティング問題を残す(leave)。SigCompは、トランスポート層プロトコルのヘッダを圧縮しない。トランスポート層プロトコルペイロードのコンテンツに関心のあるエンティティのみ、すなわち2つの通信している終点は、SigCompメッセージを復元する必要がある。
【0045】
SIPシグナリングが端末とP−CSCFの間で圧縮された状態で送られる理由は、無線インタフェースにわたって少しのバイトを節約することではないということは、強調されるべきである。端末がより多くの帯域幅を使用するであろう、マルチメディアセッションを確立するであろうとき、それは少しのバイトのシグナリングを節約するに値しない。圧縮のための主なモチベーションは、無線インタフェースにわたってSIPメッセージを送信することに必要とされた時間を減らすことである。
【0046】
IMSにおいては、セッション制御を実行するプロトコルは、セッションイニシエーションプロトコル(SIP)である。SIPは、本来、既存のマルチメディア会議にユーザを招待するために使用されていたが、今日では、それは、主にマルチメディアセッションを作り、修正し(modify)、そして終了するために使用されている。SigCompは、いずれのテキストベースのプロトコルのメッセージを圧縮するために使用されることができるけれども、主な焦点は、目下SIPメッセージの圧縮上にある。
【0047】
SIPは、扱われたマルチメディアセッションのタイプから独立しており、そして、セッションを説明するために使用されたメカニズムから独立している。マルチメディアセッションを説明するのにもっとも一般的な(common)フォーマットは、セッション記述プロトコル(SDP)である。SDPは、SIPメッセージのボディにおいて搬送される、単なるテキストフォーマット(textual format)である。これが、SigCompがSIPとSDPの両方を効率的に圧縮することができなくてはならない理由である。SIP/SDPの静的ディクショナリは、この目的のために定義される。
【0048】
SIPプロトコルは、いくつかのエンティティを規定しており、それらはユーザエージェント(UAs)、リダイレクトサーバ(redirect servers)、プロキシサーバ、レジストラ(registrars)およびロケーションサーバである。SGPPリリース5、あるいはのちにリリースする、をサポートしている、すべての3G端末は、SIP UAを含んでいる。さらに3GPP2は、SIPを採用する。SIPは、ユーザの現在のロケーションへのリクエストをルーティングし、サービスのためにユーザを認証し権利化し、プロバイダ呼び出しルーティングポリシーをインプリメントし、そしてユーザに特徴を提供することを手助けするために、プロキシサーバを利用する。リダイレクトサーバは、ユーザが到達可能かもしれない場合、代替のロケーションを提供することによってSIP UAsのロケーションにおいて、手助けする。レジストラは、登録を受諾する(accepts)。それは、大抵、リダイレクトサーバあるいはプロキシサーバで同じ場所に配置される。ロケーションサーバは、SIPエンティティではないが、SIPを使用するいずれのアーキテクチャの重要な部分である。ロケーションサーバは、ユーザの可能性のあるロケーションを保存し、戻す。
【0049】
SIPは、ハイパーテキストトランスファプロトコル(Hypertext Transfer Protocol)(HTTP)のような、リクエスト/応答プロトコルであり、それに基づいている。SIPユーザエージェントクライアント(UACs)は、リクエストを送り、ユーザエージェントサーバ(UASs)は、レスポンスを戻す。リクエストのスタートラインは、方法名を宣言し、それは、リクエストの目的を指している。
【0050】
SigComp終点のレイアウトは図5に図示されている。それは、以下のエンティティ:コンプレッサディスパッチャ、1つまたは複数のコンプレッサ、ステートハンドラ、ユニバーサルデコンプレッサ仮想マシン(UDVM)およびデコンプレッサディスパッチャ、を含んでいる。
【0051】
コンプレッサディスパッチャのタスクは、アプリケーションからメッセージを受信し、トランスポート層に各メッセージの圧縮されたバージョンを受け渡すことである。アプリケーションは、各メッセージと一緒にコンパートメント識別子を、コンプレッサディスパッチャに提供しなければならない。コンパートメントは、ピア終点に関連する、メッセージのグルーピングに特有のアプリケーション(an application specific grouping of messages)である。SIPのケースにおいては、コンパートメントは、SIPダイアログに属しているすべてのメッセージによって形成される。コンパートメント識別子は、独自にコンパートメントを識別する。SigCompは、パーコンプレッサベースでコンプレッサを呼び出す、それは、コンパートメント識別子がさらにコンプレッサを識別するために使用されることができるということを意味する。このために、コンパートメント識別子とコンプレッサとの間のマッピングは、維持されなくてはならない。アプリケーションメッセージと一緒にコンパートメント識別子を提供することによって、アプリケーションは、コンプレッサディスパッチャは適切なコンプレッサを位置づけることができるということを確実にする。新しいコンパートメント識別子(a new compartment identifier)が出くわされるたびに、新しいコンプレッサが呼び出される。いったんコンプレッサがアプリケーションメッセージを圧縮すると、SigCompヘッダは、作られ、それに取り付けられる。この後で、コンプレッサディスパッチャは、トランスポート層にSigCompメッセージを受け渡すことができる。アプリケーションがコンパートメントをクローズ(close)したいと願うとき、例えばBYEメッセージを受信し、ファイナルレスポンスを送った後で、コンプレッサディスパッチャにこれを示すべきである。
【0052】
コンプレッサは、アプリケーションメッセージを圧縮するのに使用されるある圧縮アルゴリズムをインプリメントする。SigCompの基礎的なアイデアのうちの一つは、標準規格がすべての終点によって使用されるべき1つの圧縮アルゴリズムの使用をディクテートしていないということである。代わりに、アルゴリズムの選択は、インプリメンテーションの決定として残されている。次に続くのは、各終点が様々な圧縮アルゴリズムの出力を復元することができるべきであるということである。これは、復元機能性を処理する仮想マシンの使用によって可能になる。コンプレッサが圧縮されたアプリケーションメッセージを含んでいるSigCompメッセージを作るとき、それは、メッセージのヘッダへの復元アルゴリズムを含む。この復元アルゴリズムは、バイトコードと呼ばれており、そして、それは、仮想マシン上で実施されることができる形態にコンパイルされてきた。
【0053】
多くの必要条件は、コンプレッサ上に置かれる。まず初めに、それは、透過的(transparent)でなくてはならない(例、コンプレッサは、UDVMがSigCompメッセージを不正確に復元するようにさせる、バイトコードを送らない)。コンプレッサは、成功復元が生じることを確実にするために、アプリケーションメッセージにわたって、完全チェック(integrity check)のいくつかの形態を供給するべきである。メッセージが、遠隔終点で、利用可能なリソースを使用して、復元されることができるということを確実にしなければならない。トランスポートがメッセージベースである場合、それがユーザデータグラムプロトコル(UDP)のケースにおけるとき、コンプレッサは、確実に1つのSigCompメッセージに、各アプリケーションメッセージをマッピングしなくてはならない。トランスポートがストリームベースであり、しかしアプリケーションがそれ自体の内部のメッセージの境界を定義する場合、コンプレッサは、確実に1つのSigCompメッセージに各アプリケーションメッセージをマッピングするべきである。
【0054】
デコンプレッサディスパッチャの役割は、トランスポート層からSigCompメッセージを受信し、各メッセージを復元するためにUDVMの新しいインスタンスを呼び出しし(invoke)、そして、アプリケーションに結果として生じる非圧縮されたメッセージを受け渡すことである。いったんアプリケーションがメッセージを受信すると、それは、コンパートメントにメッセージをマッピングし、デコンプレッサディスパッチャにコンパートメントの識別子を戻す。デコンプレッサディスパッチャは、そのあと、ステートハンドラに識別子を渡し、それは、ステート情報を節約し、適切なコンプレッサに対してフィードバック情報を転送する(forward)ために識別子を使用する。コンパートメント識別子を供給することによって、アプリケーションは、これをするための許可をディスパッチャに承諾する(grants)。
【0055】
ユニバーサルデコンプレッサ仮想マシン(UDVM)は、SigCompメッセージを復元するエンティティである。復元プロセスは、仮想マシン上でバイトコードと呼ばれる、特別コンパイルされたプログラムを実行することにより行なわれる。UDVMは、大いにJava(登録商標)仮想マシンのような仮想マシンであるが、復元アルゴリズムを実行するために最適化されたという違いを備えている。SigCompのケースにおいては、バイトコードにコンパイルされたソースコードは、UDVMアセンブリ(UDVM assembly)と呼ばれ、エンティティのコンパイリング(the entity compiling)はUDVMインタープリタと呼ばれる。バイトコードは、UDVMのマシン言語として考えられることができる。
【0056】
UDVMは、どのように与えられたアプリケーションメッセージを圧縮するかを選択するとき柔軟性を提供する:コンプレッサインプリメンタは、彼の選択のアルゴリズムを選択する自由を有する。圧縮されたデータは、1セットのUDVMインストラクションを含んでいるバイトコードで結合されている。これらのインストラクションは、SigCompメッセージのヘッダにおいて搬送され、そして、それらは、オリジナルデータが受信終点で展開されること(extracted)を可能にする。
【0057】
SigCompは非保護されたトランスポート層上で実行できるので、UDVMの分離したインスタンス(separate instance)は、損害をうけたメッセージがより後のメッセージの復元に影響を与えないということを確実にするためにパーメッセージ基準(a per-message basis)上で呼び出される。しかしながら、復元プロセスの間に、UDVMは、既存のステートにアクセスするようにステートハンドラを呼び出すことができる。この方法で、前のメッセージを復元したUDVMインスタンスのステートは、より後のUDVMインスタンスによって再記憶される(restored)ことができる。
【0058】
UDVMは初期化されるとき、UDVMは、デコンプレッサディスパッチャから追加の圧縮されたデータ、あるいはステートハンドラからステート情報を、リクエストのときのみ、受信できる。復元が行なわれると、UDVMは、復元されたデータを、デコンプレッサディスパッチャに出力する。それがメッセージの終わりに出くわすとき、それは、ディスパッチャにこのことを示し、コンパートメント識別子でそれを提供する。この識別子は、ステート作成リクエストにおいてステートハンドラに受け渡される。ステートハンドラは、対応するコンパートメントのためにリザーブされるステートメモリのロケーションにおいて、ステート情報を記憶するために、コンパートメント識別子を使用する。UDVMはさらに、ステートハンドラにSigCompメッセージにピギーバック方式で輸送されることができるフィードバック情報を転送する。
【0059】
UDVMサイクルは、UDVMインストラクションを実行するのに必要とされるCPUパワーの量の測度(measure)である。UDVMサイクル限度は、SigCompメッセージにおいてビットごとに復元するために使用されることができるUDVMサイクルの数を制限する(restrict)ために使用される。悪意のあるユーザはルーピングコードを含んでいるバイトコードを送る可能性があるので、バイトコードが使用するサイクルの量は、モニタされなくてはならない。しかしながら、サイクル限度は、生じうるダメージの量をただ減らすが、問題を取り去らない。
【0060】
SigCompにおいては、デコンプレッサメモリのサイズは交渉できる(negotiable)。復元側は、圧縮側にデコンプレッサメモリのサイズを通知する(advertises)。デフォルトのサイズは2キロバイトである。圧縮の効率を改善するために、4あるいは8キロバイト、あるいはそれ以上のキロバイトのメモリサイズが、使用されることができる。デコンプレッサメモリは、2つのセクションに分かれており、そのうちの最初のセクションは、復元されたメッセージを記憶するために使用される。他のセクションは、UDVMがバイトコードおよびサーキュラーバッファ(circular buffer)を保持するために使用されており、UDVMメモリのよりも大きいステートの使用を可能にする。このことは、バッファが満たされるとすぐに、UDVMはバッファの初めにコンテンツに上書きすることを開始できるので、可能である。
【0061】
UDVMの分離したインスタンスが、到達する各メッセージを復元するために呼び出されるので、メッセージ間で情報を保持する(retain)ための方法が必要とされる。これはSigCompステートハンドラのタスクであり、受信されたSigCompメッセージ間の情報を保存する。ステートハンドラのおかげで、メッセージが前のメッセージにおいて含まれる情報に関して圧縮されることができるので、圧縮比は、改善される。ステートハンドラは、より後のメッセージが復元されているとき、アクセスのためのステートアイテムを作ることを可能にする。ステートアイテムは、典型的に、非圧縮されたメッセージあるいはUDVMインスタンスのメモリのスナップショットのいずれかを含んでいる。
【0062】
ステートハンドラは、パーコンパートメント基礎上でステートメモリを管理する。ステートアイテム自体を保存すること同様、それは、特定のコンパートメントによって作成されたステートアイテムのリストを維持し、そして、どんなコンパートメントもその割り当てられたメモリを超えないということを確実にする。
【0063】
UDVMインタープリタは、UDVMインストラクションとUDVMアセンブリにリストされたそれらのオペランドを、バイトコード形式に翻訳するエンティティである。UDVMインタープリタは、入力として、UDVMアセンブリソースコードを含んでいるファイルを捉え、そして、それをバイトコードにコンパイルする、それは、仮想マシン上で実施されることができる。
【0064】
信号圧縮最適化システム10の動作環境を説明した状態で、信号圧縮最適化方法400は図7において、図示されている。明瞭にするために、方法は、ブロック414−420の通信デバイス(受信者)部分が後で続く、ブロック402−412の通信ネットワーク(広める)部分に、連続して分離される。方法が複数のエンティティを含んでいるということと、そして、圧縮されたSIP/SDPデータコンテンツの伝播(dissemination)は、通信デバイスから通信ネットワークにさらに送られることが出来るということと、を理解されるべきである。さらに、通信ネットワークあるいは通信デバイスは、そのようなエンティティの様々な組み合わせにおいて、開始し、リレーし、終了する、伝播を備えた複数のエンティティを表わすことができる。
【0065】
ブロック402で始まり、通信ネットワークは、受信通信デバイスのハードウェア/ソフトウェアコンフィギュレーションを得ることによって、信号圧縮最適化システム10の態様を有効に進める(advances)ことができる。このことは、可能性のある通信デバイスの世界(universe)上で最新状態(up to date)のままであることを意図されている包括的なデータベースを必要とし得るであろう、あるいは、ここに開示される信号圧縮最適システム10の他の態様をサポートするそれらに特に集中される。このデータは、OEM製造業者(Original Equipment Manufacturers)(OEM)によって供給されることができる、あるいは、このような通信デバイスの母集団(population)をサポートする、個別の通信デバイスあるいは階層型エンティティ(individual communication devices or hierarchical entities)とのSIP/SDP通信を介して、インタラクティブに(interactively)得られることができる。ブロック404においては、対応する復元ソースコード(バイトコード)にそって、信号圧縮アルゴリズムは選択される。このような選択は、受信者通信デバイス(単数または複数)がUDVMを呼び出すことを通信デバイスに期待するよりもむしろバイトコードの実行可能なバージョンにローカルアクセスを有するかどうかを知って、有効になされうる。ブロック406においては、通信ネットワークは、実行可能なマシンコードを作るために、得られたハードウェア/ソフトウェアのコンフィギュレーションと一致した(consistent with)バイトコードをコンパイルする。このようなコンパイレーションは、リクエストを待ち、そして、そのあと、すぐに送信されることができる。図示されたシーケンスにおいて、ブロック408においては、このコンパイレーションは、リクエストの前に終わっており、リクエストのときに、伝播のためのコンフィギュレーションとバイトコードにしたがって、インデクスがつけられる(indexed)。
【0066】
データコンテンツ(例えば、マルチメディアコンテンツおよび/またはシグナリング)は、ブロック410において、圧縮アルゴリズムにしたがって圧縮される。圧縮されたデータコンテンツは、そのあと、データコンテンツ(例えばマルチメディア、シグナリングなど)を復元する通信デバイス(モバイル端末)で解釈に適切である、選択されたソースコード(「バイトコード」)に沿って、データパケットプロトコルに従って送信される。例示的なインプリメンテーションおいては、ブロック412では、通信ネットワークは、選択されたソースコード(バイトコード)に沿って、データパケットプロトコルに従って圧縮されたデータコンテンツを、無線で送信する。
【0067】
ブロック414においては、通信デバイスは、伝送を無線で受け取る。ブロック416では、伝送されたバイトコードが検出される。ブロック418においては、検出されたバイトコードに関連づけられた復元コードのアクセス可能で実行可能なバージョンは、仮想マシン上のバイトコードのより遅い解釈を回避して、位置づけられる。実行可能なバージョンにアクセスすることは、今後の使用のためにストレージで実行の前に、ローカルのコンパイレーションあるいは遠隔のコンパイレーションを必然的に伴うことができる。実行可能なバージョンは、UDVMインタープリタの使用を避けるために、ハードウェア最適化されたデコンプレッサの他のタイプあるいはデジタル信号処理を使用することを必然的に伴うことができる。ブロック420においては、圧縮されたデータコンテンツは、そのあと、アクセス可能で実行可能なバージョンを使用して、復元される。
【0068】
図8−11においては、図7の方法の4つの特別のインプリメンテーションが図示されている。第1に、図8においては、信号圧縮最適化装置500は、使用されるべき1つのセットの圧縮アルゴリズムがあらかじめ知られているという仮定の上で作られ、これらの復元アルゴリズムのためのマシンコードインプリメンテーションでプロビジョンすることによって、モバイル端末502へと組み込まれる。モバイル端末502上で実行されるシグナリング圧縮(SigComp)最適化のオペレーション504は、ブロック506において、プロキシ呼び出し/セッション制御機能(P−CSCF)510によって通信チャネル508上で送信されたSigCompメッセージに沿って検出された復元バイトコードを比較できる。ブロック512において、SigComp最適化のオペレーション504が正確なマッチ(exact match)が検出されるということを決定する場合、そのときには、ブロック514においてマシンコード復元が実行される。ブロック512において正確なマッチが決定されなかった場合には、そのときには、ブロック516においてユニバーサルデコンプレッサ仮想マシン(UDVM)インタープリタは、復元のためのバイトコード上で呼び起こされる。ローカルSIP/SDPアプリケーション518は、P−CSCFによって最初に(initially)圧縮されたプレーンのSIP/SDPメッセージ(plain SIP/SDP messages)を受信する。したがって、もしアルゴリズムがブロック512において認識されないP−CSCF510(例えば、ローミングの間に、あるいはネットワークアップグレードの後で)によって送られる場合、モバイル端末502は、標準UDVMインタープリタをまだ実行することができるであろう。
【0069】
図9において、代替的な信号圧縮最適化装置600は、プリコンパイルされたアルゴリズムのリストでP−CSCF610から通信チャネル608にわたって受信された復元バイトコードをブロック606において比較するSigComp最適化オペレーション604による“ジャストインタイム”のコンパイレーションを必然的に伴う。もしバイトコードがブロック612においてマッチであるとわかった場合、そのときには、プリコンパイルされたアルゴリズムの関連づけられたマシンコードは、復元のためにブロック614において使用される。ブロック612でマッチが見つからなかった場合には、そのときは、ローカルSIP/SDPアプリケーション618に対してプレーンのSIP/SDPメッセージを提供するいずれかの事象において、バイトコードは、マシンコードにブロック616でコンパイルされ、そのあと、ブロック614が実行される。したがって、このバイトコードはいったんコンパイルされ、そして、すべての以下のセッションイニシエーションプロトコル(SIP)メッセージの復元のために使用される。図9においては、UDVMの使用は、コンパイレーションが実行されるまで待機することによって回避される。この方法は、ターゲット上でバイトコードコンパイレーション機能を必要とする。1つの第1メッセージの後のすべてのメッセージ(All the messages after the first one)は、UDVMインタープリタコードを実行することによって引き起こされたであろう、いずれの処理の非効率を経験しない(do not suffer)。代替的に、コンパイレーションは、現在の通信のためのUDVMインタープリタを呼び起こしている間、今後の使用のためにバックグラウンドにおいて生じてもよい。
【0070】
図10においては、別の代替的な信号圧縮最適化装置700は、バイトコードのコンパイルされたバージョンの使用を拡張し、しかし、ターゲット上でバイトコードをコンパイルする代わりに、マシン(例、コンパイルされた)コードは、ネットワークによって送られる。このマシンコードが該モバイル(mobile in question)に互換性(compatible)があるということを確実にするために、ネットワーク(SigCompサーバ720)は、チャネル708を介してSIPメッセージング機能を使用してモバイル端末702のハードウェア/ソフトウェアバージョンの番号を最初にチェックできる。別のことばに言い換えると、ネットワークは、モバイル局のハードウェア/ソフトウェア(HW/SW)(hardware/software)にしたがって、モバイル局に送るべき必要のある適切なマシンコードを選択する。受信されたマシンコードは、同じマシンコードの後続の再伝送を回避するためにモバイル局の永続メモリ(permanent memory)上で保存されることができる。その目的に、ブロック706におけるSigComp最適化オペレーション704は、P−CSCF710から(form)通信チャネル708にわたって受信された復元バイトコードを比較する。バイトコードマッチがブロック712において決定される場合、そのときは、プリコンパイルされたマシンコードは、ブロック714で実行されることができる。ブロック712においてマッチが見つからなかった場合は、そのときは、バイトコードのプリコンパイルされたバージョンは、SigCompサーバ720からリクエストされ、そして、バイトコードはリストに加えられる(ブロック716)。マシンコードは、ローカルSIP/SDPアプリケーション722に対してプレーンのSIP/SDPメッセージを供給するために、ブロック714において復元を達成する実行について、そのとき、利用可能となる。
【0071】
図11においては、さらに追加の代替的な信号圧縮最適化装置800は、デコンプレッサディスパッチャ804がP−CSCF808から通信チャネル806を介して復元バイトコードでSigCompメッセージを受信する、モバイル端末802を有する。モバイル端末802は、最適化されたハードウェアプロセッサ810を利用する。プロキシUDVM812は、特定のバイトコードでハードウェアプロセッサ810をプログラムし、そのあと、ハードウェアプロセッサ810における復元のためのSigCompを送る。ハードウェアプロセッサは、UDVM解釈のためにプログラムされた汎用目的のDSPあるいは専用アクセレータのいずれであってもよい。プレーンのSIP/SDPメッセージは、そのあと、ローカルSIP/SDPアプリケーション812によって利用される。
【0072】
このシステムおよび方法は、P−CSCFサーバの処理必要要件を減らすためにネットワークサイドに、さらに、適用されることができる。
【0073】
インプリメンテーション。様々なインプリメンテーションが可能である。いくつかの進んだインプリメンテーション、例えばネットワークがモバイル局に対してプリコンパイルされた復元バイナリ(pre-compiled de-compression)を送る方法は、インフラストラクチャベンダー(infrastructure vendor)からいくつかのサポートを必要とするであろう、したがって、標準化のいくつかの形式を必要とするであろう。したがって、いくつかのインプリメンテーションにおいては、例えば3GPP/3GPP2あるいはIETF(インターネット技術タスクフォース)標準規格団体によって促進されるもののような標準規格において、ここに開示されている方法および装置の特徴のうちの少なくともいくつかを含むことは、適切であるかもしれない。
【0074】
実験結果。UDVMのパフォーマンスのいくつかのベンチマーキングを実行した後で、以下が観察される:(1)UDVMインタープリタは、本来の復元アルゴリズムと比較して、約20倍遅く、SIPメッセージを復元する。(2)UDVMがクァルコムMSM6800チップセット上の通常の呼び出しセットアップの間、SIPメッセージを復元するのにかかる時間は、ほとんどアイドルのセントラルプロセッシングユニット(CPU)上で約100msである。この時間は、事前の呼び出しセットアップのシナリオ、例えばPRACKの使用(すなわち、仮レスポンスの受信を認識するSIP方法)、あるいはサービスの質(Quality of Service)(Qos)前提条件、で増える。(3)圧縮効率を改善する、よりよい圧縮アルゴリズムの導入は、いちじるしくUDVM復元時間を増やすであろう。要約するために、本発明は、CPUロードあるいは複雑なSIP呼び出しセットアップフローのケースにおいて、少なくとも100msあるいはそれ以上だけ、呼び出しセットアップ時間を、潜在的に減らすことができる。
【0075】
図12−13は、SURF6800加入者ユニットリファレンスデザインボード上で簡単なUDVMアルゴリズムについてのパフォーマンス結果を図示する。特に、図12−13は、それぞれ、静的DEFLATEおよびLempel−Ziv−Storer−Szymanski(LZSS)復元アルゴリズムのチャートである。LZSSおよびDEFLATEのアルゴリズムは、標準であり、圧縮システムで知られている。DEFLATEは、Lempel−Ziv1977(LZ77)アルゴリズムおよびホフマン符号化の組み合わせを使用する損失のないデータ圧縮アルゴリズムであり、そして、PKZIPファイル保管ツール(PKZIP archiving tool)のバージョン2について、フィルカッツによって当初は定義され、RFC1951において、のちに規定された。LZSS圧縮がベンチマーキングのために使用されるアルゴリズムのうちの1つであったけれども、本発明は、いかなる特定の圧縮アルゴリズムを必要としない。例示的な候補(candidate)は、動的DEFLATEである。しかしながら、DEFLATEアルゴリズムの複雑さは、LZSSの複雑さよりも大きく、パフォーマンス削減がDEFLATEインプリメンテーションにおいてより大きくなるであろうということを意味している。
【0076】
ここに開示された態様に関連して、様々な説明のための論理、論理ブロック、モジュールおよび回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)あるいは他のプログラマブル論理コンポーネント、ディスクリートゲートあるいはトランジスタロジック、ディスクリートハードウェアコンポーネント、あるいはここに説明された機能を実行するように設計されたそれらの任意の組み合わせで、インプリメントあるいは実行されることができる。汎用プロセッサは、マイクロプロセッサであってもよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、あるいはステートマシン(state machine)であってもよい。プロセッサはまた、コンピューティングコンポーネント(computing components)の組み合わせ、例えば、DSPとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、DSPコアと併用しての1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成、としてインプリメントされてもよい。
【0077】
さらに、ここに開示された実施形態に関連して説明された方法あるいはアルゴリズムのステップは、ハードウェアにおいて、プロセッサによって実行されたソフトウェアモジュールにおいて、あるいはこれら2つの組み合わせにおいて、直接的に具現化されることができる。例えば、方法のステップは、個別の方法ステップを実行することが動作可能なプロセッサの1つまたは複数のモジュールにおいて具現化されることができる。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD−ROMあるいは当技術分野において知られている記憶メディアの任意の他の形態において常駐する(reside)ことができる。例示的な記憶メディアは、プロセッサが記憶メディアから情報を読み取ることができ、また記憶メディアに情報を書き込むことができるように、プロセッサに結合される。別の方法では、記憶メディアは、プロセッサと一体化していてもよい。プロセッサと記憶メディアは、ASICにおいて常駐していてもよい。ASICは、ユーザ端末に常駐していてもよい。代替として、プロセッサと記憶メディアは、ユーザ端末におけるディスクリートコンポーネントとして常駐することができる。さらに、例えば、アルゴリズムあるいは方法のステップは、コンピュータが個別の方法のステップを実施するようにさせることが動作可能な1つまたは複数のセットのインストラクションを有しているコンピュータ可読メディア、を備えているコンピュータプログラムプロダクトにおいて具現化されることができる。
【0078】
図1に戻って参照すると、通信ネットワーク12は、いずれのデータおよび/または音声通信ネットワークを備えることができる。例えば、通信ネットワーク28は、いずれの1つあるいはいずれの組み合わせのすべてあるいはいくつかの部分:有線のあるいは無線の電話ネットワーク、地上波電話ネットワーク、衛生電話ネットワーク、赤外線データ協会(Infrared Data Association)(IrDA)ベースのネットワークのような赤外線ネットワーク、短距離無線ネットワーク、Bluetooth(R)(登録商標)技術ネットワーク、ZigBee(登録商標)プロトコルネットワーク、ウルトラ広域(UWB)プロトコルネットワーク、ホーム無線周波数(a home radio frequency)(HomeRF)ネットワーク、共有された無線アクセスプロトコル(shared wireless access protocol)(SWAP)ネットワーク、無線Ethernet(登録商標)ケイパビリティ協会(wireless Ethernet compatibility alliance)(WECA)、無線フィディリティ協会(wireless fidelity alliance)(Wi−Fi協会)ネットワーク、そして802.xxネットワークのような、広域ネットワーク、パケットデータネットワーク、データネットワーク、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)ネットワーク、公衆交換電話網、インターネットのような公共異種通信ネットワーク、プライベート通信ネットワーク、カリフォルニア州のサンディエゴのクアルコム社から入手可能であるメディアFLO(TM)システムを含んでいる、順方向リンク専用(Forward Link Only)(FLO)ネットワークのようなマルチキャストネットワーク、衛星用のDVB−S、ケーブル用のDVB−C、地上波テレビ用のDVB−T、ハンドヘルドのための地上波テレビ用のDVB−Hのような、デジタルビデオブロードキャスティング(digital video broadcasting)(DVB)ネットワーク、そして、ランドモバイル無線ネットワーク、を備えることができる。
【0079】
さらに、通信ネットワーク28のいくつかの態様に含まれることができる電話ネットワークの例は、符号分割多元接続(CDMA)、広帯域符号分割多元接続(WCDMA)、ユニバーサルモバイルテレコミュニケーションシステム(Universal Mobile Telecommunications System)(UMTS)、アドバンスドモバイル電話サービス(advanced mobile phone service)(AMPS),時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交周波数分割多元接続(OFDMA)、モバイル通信のためのグローバルシステム(GSM)、単一キャリア(1X)無線伝送技術(RTT)、エボリューションデータ専用(EV−DO)技術、汎用パケット無線サービス(GPRS)、増データGSM環境(enhanced data GSM environment)(EDGE)、ハイスピードパケット接続(HSPA)、アナログおよびデジタル衛星システム、そして、データ通信ネットワークと無線通信ネットワークのうち少なくとも1つにおいて使用されることができるいずれの他の技術/プロトコルのような、アナログおよびデジタルネットワーク/技術のいずれの組み合わせ、あるいは、ひとつの少なくとも1部分を含んでいる。
【0080】
様々な開示された態様が図示され説明されてきた一方で、このドキュメントの主題の事柄がこれらの態様のみに限定されていないということが明らかとなるであろう。
【0081】
例えば、簡明にするために、通信デバイス14は、マルチメディアコンテンツ16を受信して(復元して)図示されている。本発明の態様と一致したアプリケーションは、そのようなマルチメディアコンテンツのリバースあるいは2方法の伝送を必然的に伴う。例えば、静止イメージあるいはビデオカメラによって生成された、あるいは、そうでなければ通信デバイス14上で保存されたマルチメディアコンテンツは、通信ネットワーク12にアップロードされることができる。さらに通信ネットワーク12は、これからは通信デバイス14にマルチメディアコンテンツ16を送信するための対応する圧縮アルゴリズムおよび同じバイトコードを利用するために、通信デバイス14によって供給されたバイトコードを検出することにすぐ反応することができる。それによって、通信デバイス14は、UDVMインタープリタ62に頼ることなく、最適化された復元技術がサポートされる、マルチメディアコンテンツ16を受信する可能性を増大することができる。
【0082】
したがって、以上の開示は説明のための態様を示すが、様々な変更および修正が、添付された請求項によって定義されるように、説明された態様の範囲から逸脱することなく、ここになされることができる、ということが注意されるべきである。さらに、説明された態様のエレメントは、単数で、説明され、あるいは請求項で記載されているかもしれないが、単数への限定が明確に述べられていない限り、複数も意図されている。
【0083】
さらに、特定の特徴がいくつかのインプリメンテーションのうちの1つのみに関して開示されてきたが、このような特徴は、いずれの与えられたあるいは特定のアプリケーションについて望まれ、利点があるような、他のインプリメンテーションの1つまたは複数の他の特徴と結合されることができる。用語「含む(includes)」および「含んでいる(including)」およびそれらの変形が詳細な説明あるいは特許請求の範囲のいずれかにおいて使用される限り、これらの用語は、用語「備えている(comprising)」と同様な方法で包括的であるように意図されている。さらに、詳細な説明あるいは特許請求の範囲のいずれかにおいて使用される、用語「あるいは(or)」は、「非排他的、または(non-exclusive or)」であることを意味している。
【0084】
さらに、説明された態様および/またはバージョンのエレメントは、単数で、説明され、あるいは請求項で記載されているかもしれないが、単数への限定が明確に述べられていない限り、複数も意図されている。さらに、いずれの態様および/またはバージョンの全部あるいは一部は、そのように述べられなければ、いずれの他の態様および/またはバージョンの全部あるいは一部で、利用されることができる。
【特許請求の範囲】
【請求項1】
複数の圧縮アルゴリズムのうちの選択された1つによって圧縮されたデータコンテンツを通信する方法であって、前記圧縮アルゴリズムのそれぞれは、前記圧縮されたデータコンテンツから前記データコンテンツを作ることができる、対応する復元アルゴリズムを有しており、データパケットプロトコルを介してトランスファされた前記圧縮されたデータコンテンツは、前記対応する復元アルゴリズムを実行するために、解釈に適切な復元ソースコードをトランスファする、少なくとも1つのメッセージを備えており、前記データパケットプロトコルは、前記圧縮されたデータコンテンツを含んでいる少なくとも1つのメッセージをさらに備えており、前記方法は、
前記少なくとも1つのメッセージにおいて前記ソースコードを検出することと、
前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づけることと、
前記対応する復元アルゴリズムの前記位置づけられたアクセス可能で実行可能なバージョンを利用している、前記圧縮されたデータコンテンツを復元することと、
を備えている、
方法。
【請求項2】
前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能なバージョンを位置づけることを失敗したことに応じて、前記圧縮されたデータコンテンツを復元するために、前記対応するソースコードを解釈するように仮想マシンを呼び出すこと、をさらに備えている請求項1に記載の方法。
【請求項3】
前記対応するソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能な実行可能なバージョンを位置づけることを失敗したことに応じて、マシンコードへと、前記検出されたソースコードをコンパイルすることと、
前記検出されたソースコードによってインデクスがつけられた前記マシンコードを含んでいるアクセス可能なデータストラクチャを作ることと、
をさらに備えている請求項1に記載の方法。
【請求項4】
遠隔エンティティから前記検出されたソースコードの実行可能なバージョンをリクエストすることと、
前記遠隔エンティティから前記検出されたソースコードの前記実行可能なバージョンを受け取ることと、
をさらに備えている請求項1に記載の方法。
【請求項5】
前記実行可能なバージョンが充てられた、意図されたプロセッサのコンフィギュレーションを確かめることと、前記意図されたプロセッサのための前記ソースコードをコンパイルすることと、をさらに備えている請求項4に記載の方法。
【請求項6】
前記検出されたソースコードからインストラクションを送り、第2のプロセッサに前記圧縮されたデータコンテンツを送る、第1のプロセッサにおいて、プロキシ仮想マシンを呼び出すことと、
前記第2のプロセッサによって復元された前記データコンテンツを表わすことと、
をさらに備えている請求項1に記載の方法。
【請求項7】
前記ソースコードを検出することと、前記圧縮されたデータコンテンツを復元することをさらに備えることは、第3世代パートナーシッププロジェクト(3GPP)パケットデータのトランスポートの一部として、データパケットプロトコルの一貫した信号の圧縮(SigComp)を受信し復元すること、を備えている請求項1に記載の方法。
【請求項8】
前記データコンテンツは、マルチメディアあるいはシグナリングコンテンツを備えており、ユーザに認識可能な形において前記データコンテンツを表すことをさらに備えている、請求項1に記載の方法
【請求項9】
前記データパケット通信を無線で受け取ること、をさらに備えている請求項1に記載の方法。
【請求項10】
前記セッションイニシエーションプロトコル/セッション記述プロトコル(SIP/SDP)データパケット通信を受信すること、をさらに備えている請求項1に記載の方法。
【請求項11】
圧縮されたインターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを受け取るための、復元バイトコードでデータパケット通信チャネルに加えられた装置、であって、前記装置は、
前記復元バイトコードの実行可能なバージョンと、
前記復元バイトコードを検出し、前記復元バイトコードの前記実行可能なバージョンにアクセスする、デコンプレッサディスパッチャと、
プレーンのSIP/SDPメッセージに前記圧縮されたIMSデータコンテンツを処理するために、前記復元バイトコードの前記実行可能なバージョンを実行する、最適化されたデコンプレッサと、
前記プレーンのSIP/SDPメッセージを受信するための、ローカルセッションイニシエーションプロトコル/セッション記述プロトコル(SIP/SDP)アプリケーションと、
を備えている装置。
【請求項12】
ユニバーサルデコンプレッサ仮想マシン(UDVM)、をさらに備えており、前記デコンプレッサディスパッチャは、前記第1の実行可能なバージョンに関連づけられていない第2の復元バイトコードを受信することに応じて前記復元バイトコードを解釈するように前記UDVMを呼び出す、請求項11に記載の装置。
【請求項13】
コンパイラ、をさらに備えており、前記デコンプレッサディスパッチャは、前記第1の復元バイトコードよりもむしろ前記第2の復元バイトコードを検出することに応じて、第2の復元バイトコードに関連づけられた第2の実行可能なバージョンを生成するように、前記コンパイラを指図する、請求項11に記載の装置。
【請求項14】
ネットワークデバイスは、前記装置とSIP/SDP通信中であり、前記デコンプレッサディスパッチャは、前記第1の復元バイトコードよりもむしろ前記第2の復元バイトコードを検出することに応じて、第2の復元バイトコードに関連づけられた第2の実行可能バージョンをリクエストし、受信する、請求項11に記載の装置。
【請求項15】
プロキシユニバーサルデコンプレッサ仮想マシン(UDVM)と、
前記圧縮されたIMSデータコンテンツを復元するために、そして、前記復元バイトコードを解釈するために、前記プロキシUDVMにインタフェース接続されたUDVMインプリメントされたハードウェアと、
をさらに備えている請求項11に記載の装置。
【請求項16】
複数の圧縮アルゴリズムのうちの選択された1つによって圧縮されたデータコンテンツを通信するようにコンフィギュアされた少なくとも1つのプロセッサであって、前記圧縮アルゴリズムのそれぞれは、前記圧縮されたデータコンテンツから前記データコンテンツを作ることができる、対応する復元アルゴリズムを有しており、データパケットプロトコルを介してトランスファされた前記圧縮されたデータコンテンツは、前記対応する復元アルゴリズムを実行するために、解釈に適切な復元ソースコードをトランスファする、少なくとも1つのメッセージを備えており、前記データパケットプロトコルは、前記圧縮されたデータコンテンツを含んでいる少なくとも1つのメッセージをさらに備えており、前記少なくとも1つのプロセッサは、
前記少なくとも1つのメッセージにおいて、前記ソースコードを検出するための第1のモジュールと、
前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づけるための第2のモジュールと、
前記対応する復元アルゴリズムの前記位置づけられたアクセス可能で実行可能なバージョンを利用している、前記圧縮されたデータコンテンツを復元するための第3のモジュールと、
を備えている少なくとも1つのプロセッサ。
【請求項17】
データパケットプロトコル伝送の一部として、複数の圧縮アルゴリズムのうちの選択された1つによって圧縮されたデータコンテンツも含んでいる、少なくとも1つのメッセージにおいて含まれている、ソースコードを、コンピュータに検出させるための第1セットのコードと、なお、前記圧縮アルゴリズムのそれぞれは、前記圧縮されたデータコンテンツから前記データコンテンツを作ることができる対応する復元アルゴリズムを有しており、前記ソースコードは、前記コンピュータによって前記対応する復元アルゴリズムを実行するために解釈に適切である;
前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを前記コンピュータに位置づけさせるための第2セットのコードと;
前記対応する復元アルゴリズムの前記位置づけられたアクセス可能で実行可能なバージョンを利用して前記圧縮されたデータコンテンツを前記コンピュータに復元させるための第3セットのコードと;
を備えているコンピュータ可読メディア、
を備えているコンピュータプログラムプロダクト。
【請求項18】
セッションイニシエーションプロトコル/セッション記述プロトコル(SIP/SDP)データパケット通信において含まれたバイトコードを検出するための手段と、
前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づけるための手段と、
前記対応する復元アルゴリズムの前記位置づけられたアクセス可能で実行可能なバージョンを利用して前記圧縮されたデータコンテンツを復元するための手段と、
を備えている装置。
【請求項19】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを通信デバイスに広げるための装置であって、前記装置は、
圧縮アルゴリズムで前記IMSデータコンテンツを圧縮するコンプレッサと、
復元バイトコードを含んでいるデータストラクチャと、
前記圧縮されたIMSデータコンテンツと復元バイトコードを前記通信デバイスに送信する、データパケット通信チャネルと、
前記通信デバイスに前記復元バイトコードの実行可能なバージョンを得て、送信するために、前記通信デバイスからのリクエストにすぐ反応するプロセッサと、
を備えている装置。
【請求項20】
前記プロセッサは、前記通信デバイスに適した前記復元バイトコードの前記実行可能なバージョンを選択するために、前記通信デバイスのコンフィギュレーションを得る、請求項19に記載の装置。
【請求項21】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを通信デバイスに広げるための方法であって、前記方法は、
圧縮アルゴリズムで前記IMSデータコンテンツを圧縮することと、
復元バイトコードを含んでいるデータストラクチャを生成することと、
前記圧縮されたIMSデータコンテンツと復元バイトコードを前記通信デバイスに送信することと、
前記通信デバイスからのリクエストにすぐ反応する前記通信デバイスに、前記復元バイトコードの実行可能なバージョンを送信することと、
を備えている方法。
【請求項22】
前記通信デバイスに適した前記復元バイトコードの前記実行可能なバージョンを選択するために前記通信デバイスのコンフィギュレーションを得ること、をさらに備えている請求項21に記載の方法。
【請求項23】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを通信デバイスに広げるためにコンフィギュアされた少なくとも1つのプロセッサであって、
圧縮アルゴリズムで前記IMSデータコンテンツを圧縮するための第1のモジュールと、
復元バイトコードを含んでいるデータストラクチャを生成するための第2のモジュールと、
前記通信デバイスに、前記圧縮されたIMSデータコンテンツと復元バイトコードを送信するための第3のモジュールと、
前記通信デバイスからのリクエストにすぐ反応する前記通信デバイスに、前記復元バイトコードの実行可能なバージョンを送信するための第4のモジュールと、
を備えている少なくとも1つのプロセッサ。
【請求項24】
圧縮アルゴリズムでインターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツをコンピュータに圧縮させることが動作可能な第1セットのコードと、
復元バイトコードを含んでいるデータストラクチャを前記コンピュータに生成させることが動作可能な第2セットのコードと、
前記通信デバイスに、前記圧縮されたIMSデータコンテンツと復元バイトコードを前記コンピュータに送信させることが動作可能な第3セットのコードと、
前記通信デバイスからのリクエストにすぐ反応する前記通信デバイスに、前記復元バイトコードの実行可能なバージョンを前記コンピュータに送信させることが動作可能な第4セットのコードと、
を備えているコンピュータプログラムプロダクト を備えているコンピュータ可読メディア。
【請求項25】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを通信デバイスに広げるための装置であって、
圧縮アルゴリズムで前記IMSデータコンテンツを圧縮するための手段と、
復元バイトコードを含んでいるデータストラクチャを生成するための手段と、
前記通信デバイスに、前記圧縮されたIMSデータコンテンツと復元バイトコードを送信するための手段と、
前記通信デバイスからのリクエストにすぐ反応する前記通信デバイスに、前記復元バイトコードの実行可能なバージョンを送信するための手段と、
を備えている装置。
【請求項1】
複数の圧縮アルゴリズムのうちの選択された1つによって圧縮されたデータコンテンツを通信する方法であって、前記圧縮アルゴリズムのそれぞれは、前記圧縮されたデータコンテンツから前記データコンテンツを作ることができる、対応する復元アルゴリズムを有しており、データパケットプロトコルを介してトランスファされた前記圧縮されたデータコンテンツは、前記対応する復元アルゴリズムを実行するために、解釈に適切な復元ソースコードをトランスファする、少なくとも1つのメッセージを備えており、前記データパケットプロトコルは、前記圧縮されたデータコンテンツを含んでいる少なくとも1つのメッセージをさらに備えており、前記方法は、
前記少なくとも1つのメッセージにおいて前記ソースコードを検出することと、
前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づけることと、
前記対応する復元アルゴリズムの前記位置づけられたアクセス可能で実行可能なバージョンを利用している、前記圧縮されたデータコンテンツを復元することと、
を備えている、
方法。
【請求項2】
前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能なバージョンを位置づけることを失敗したことに応じて、前記圧縮されたデータコンテンツを復元するために、前記対応するソースコードを解釈するように仮想マシンを呼び出すこと、をさらに備えている請求項1に記載の方法。
【請求項3】
前記対応するソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能な実行可能なバージョンを位置づけることを失敗したことに応じて、マシンコードへと、前記検出されたソースコードをコンパイルすることと、
前記検出されたソースコードによってインデクスがつけられた前記マシンコードを含んでいるアクセス可能なデータストラクチャを作ることと、
をさらに備えている請求項1に記載の方法。
【請求項4】
遠隔エンティティから前記検出されたソースコードの実行可能なバージョンをリクエストすることと、
前記遠隔エンティティから前記検出されたソースコードの前記実行可能なバージョンを受け取ることと、
をさらに備えている請求項1に記載の方法。
【請求項5】
前記実行可能なバージョンが充てられた、意図されたプロセッサのコンフィギュレーションを確かめることと、前記意図されたプロセッサのための前記ソースコードをコンパイルすることと、をさらに備えている請求項4に記載の方法。
【請求項6】
前記検出されたソースコードからインストラクションを送り、第2のプロセッサに前記圧縮されたデータコンテンツを送る、第1のプロセッサにおいて、プロキシ仮想マシンを呼び出すことと、
前記第2のプロセッサによって復元された前記データコンテンツを表わすことと、
をさらに備えている請求項1に記載の方法。
【請求項7】
前記ソースコードを検出することと、前記圧縮されたデータコンテンツを復元することをさらに備えることは、第3世代パートナーシッププロジェクト(3GPP)パケットデータのトランスポートの一部として、データパケットプロトコルの一貫した信号の圧縮(SigComp)を受信し復元すること、を備えている請求項1に記載の方法。
【請求項8】
前記データコンテンツは、マルチメディアあるいはシグナリングコンテンツを備えており、ユーザに認識可能な形において前記データコンテンツを表すことをさらに備えている、請求項1に記載の方法
【請求項9】
前記データパケット通信を無線で受け取ること、をさらに備えている請求項1に記載の方法。
【請求項10】
前記セッションイニシエーションプロトコル/セッション記述プロトコル(SIP/SDP)データパケット通信を受信すること、をさらに備えている請求項1に記載の方法。
【請求項11】
圧縮されたインターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを受け取るための、復元バイトコードでデータパケット通信チャネルに加えられた装置、であって、前記装置は、
前記復元バイトコードの実行可能なバージョンと、
前記復元バイトコードを検出し、前記復元バイトコードの前記実行可能なバージョンにアクセスする、デコンプレッサディスパッチャと、
プレーンのSIP/SDPメッセージに前記圧縮されたIMSデータコンテンツを処理するために、前記復元バイトコードの前記実行可能なバージョンを実行する、最適化されたデコンプレッサと、
前記プレーンのSIP/SDPメッセージを受信するための、ローカルセッションイニシエーションプロトコル/セッション記述プロトコル(SIP/SDP)アプリケーションと、
を備えている装置。
【請求項12】
ユニバーサルデコンプレッサ仮想マシン(UDVM)、をさらに備えており、前記デコンプレッサディスパッチャは、前記第1の実行可能なバージョンに関連づけられていない第2の復元バイトコードを受信することに応じて前記復元バイトコードを解釈するように前記UDVMを呼び出す、請求項11に記載の装置。
【請求項13】
コンパイラ、をさらに備えており、前記デコンプレッサディスパッチャは、前記第1の復元バイトコードよりもむしろ前記第2の復元バイトコードを検出することに応じて、第2の復元バイトコードに関連づけられた第2の実行可能なバージョンを生成するように、前記コンパイラを指図する、請求項11に記載の装置。
【請求項14】
ネットワークデバイスは、前記装置とSIP/SDP通信中であり、前記デコンプレッサディスパッチャは、前記第1の復元バイトコードよりもむしろ前記第2の復元バイトコードを検出することに応じて、第2の復元バイトコードに関連づけられた第2の実行可能バージョンをリクエストし、受信する、請求項11に記載の装置。
【請求項15】
プロキシユニバーサルデコンプレッサ仮想マシン(UDVM)と、
前記圧縮されたIMSデータコンテンツを復元するために、そして、前記復元バイトコードを解釈するために、前記プロキシUDVMにインタフェース接続されたUDVMインプリメントされたハードウェアと、
をさらに備えている請求項11に記載の装置。
【請求項16】
複数の圧縮アルゴリズムのうちの選択された1つによって圧縮されたデータコンテンツを通信するようにコンフィギュアされた少なくとも1つのプロセッサであって、前記圧縮アルゴリズムのそれぞれは、前記圧縮されたデータコンテンツから前記データコンテンツを作ることができる、対応する復元アルゴリズムを有しており、データパケットプロトコルを介してトランスファされた前記圧縮されたデータコンテンツは、前記対応する復元アルゴリズムを実行するために、解釈に適切な復元ソースコードをトランスファする、少なくとも1つのメッセージを備えており、前記データパケットプロトコルは、前記圧縮されたデータコンテンツを含んでいる少なくとも1つのメッセージをさらに備えており、前記少なくとも1つのプロセッサは、
前記少なくとも1つのメッセージにおいて、前記ソースコードを検出するための第1のモジュールと、
前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づけるための第2のモジュールと、
前記対応する復元アルゴリズムの前記位置づけられたアクセス可能で実行可能なバージョンを利用している、前記圧縮されたデータコンテンツを復元するための第3のモジュールと、
を備えている少なくとも1つのプロセッサ。
【請求項17】
データパケットプロトコル伝送の一部として、複数の圧縮アルゴリズムのうちの選択された1つによって圧縮されたデータコンテンツも含んでいる、少なくとも1つのメッセージにおいて含まれている、ソースコードを、コンピュータに検出させるための第1セットのコードと、なお、前記圧縮アルゴリズムのそれぞれは、前記圧縮されたデータコンテンツから前記データコンテンツを作ることができる対応する復元アルゴリズムを有しており、前記ソースコードは、前記コンピュータによって前記対応する復元アルゴリズムを実行するために解釈に適切である;
前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを前記コンピュータに位置づけさせるための第2セットのコードと;
前記対応する復元アルゴリズムの前記位置づけられたアクセス可能で実行可能なバージョンを利用して前記圧縮されたデータコンテンツを前記コンピュータに復元させるための第3セットのコードと;
を備えているコンピュータ可読メディア、
を備えているコンピュータプログラムプロダクト。
【請求項18】
セッションイニシエーションプロトコル/セッション記述プロトコル(SIP/SDP)データパケット通信において含まれたバイトコードを検出するための手段と、
前記検出されたソースコードに関連づけられた前記対応する復元アルゴリズムのアクセス可能で実行可能なバージョンを位置づけるための手段と、
前記対応する復元アルゴリズムの前記位置づけられたアクセス可能で実行可能なバージョンを利用して前記圧縮されたデータコンテンツを復元するための手段と、
を備えている装置。
【請求項19】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを通信デバイスに広げるための装置であって、前記装置は、
圧縮アルゴリズムで前記IMSデータコンテンツを圧縮するコンプレッサと、
復元バイトコードを含んでいるデータストラクチャと、
前記圧縮されたIMSデータコンテンツと復元バイトコードを前記通信デバイスに送信する、データパケット通信チャネルと、
前記通信デバイスに前記復元バイトコードの実行可能なバージョンを得て、送信するために、前記通信デバイスからのリクエストにすぐ反応するプロセッサと、
を備えている装置。
【請求項20】
前記プロセッサは、前記通信デバイスに適した前記復元バイトコードの前記実行可能なバージョンを選択するために、前記通信デバイスのコンフィギュレーションを得る、請求項19に記載の装置。
【請求項21】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを通信デバイスに広げるための方法であって、前記方法は、
圧縮アルゴリズムで前記IMSデータコンテンツを圧縮することと、
復元バイトコードを含んでいるデータストラクチャを生成することと、
前記圧縮されたIMSデータコンテンツと復元バイトコードを前記通信デバイスに送信することと、
前記通信デバイスからのリクエストにすぐ反応する前記通信デバイスに、前記復元バイトコードの実行可能なバージョンを送信することと、
を備えている方法。
【請求項22】
前記通信デバイスに適した前記復元バイトコードの前記実行可能なバージョンを選択するために前記通信デバイスのコンフィギュレーションを得ること、をさらに備えている請求項21に記載の方法。
【請求項23】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを通信デバイスに広げるためにコンフィギュアされた少なくとも1つのプロセッサであって、
圧縮アルゴリズムで前記IMSデータコンテンツを圧縮するための第1のモジュールと、
復元バイトコードを含んでいるデータストラクチャを生成するための第2のモジュールと、
前記通信デバイスに、前記圧縮されたIMSデータコンテンツと復元バイトコードを送信するための第3のモジュールと、
前記通信デバイスからのリクエストにすぐ反応する前記通信デバイスに、前記復元バイトコードの実行可能なバージョンを送信するための第4のモジュールと、
を備えている少なくとも1つのプロセッサ。
【請求項24】
圧縮アルゴリズムでインターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツをコンピュータに圧縮させることが動作可能な第1セットのコードと、
復元バイトコードを含んでいるデータストラクチャを前記コンピュータに生成させることが動作可能な第2セットのコードと、
前記通信デバイスに、前記圧縮されたIMSデータコンテンツと復元バイトコードを前記コンピュータに送信させることが動作可能な第3セットのコードと、
前記通信デバイスからのリクエストにすぐ反応する前記通信デバイスに、前記復元バイトコードの実行可能なバージョンを前記コンピュータに送信させることが動作可能な第4セットのコードと、
を備えているコンピュータプログラムプロダクト を備えているコンピュータ可読メディア。
【請求項25】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)データコンテンツを通信デバイスに広げるための装置であって、
圧縮アルゴリズムで前記IMSデータコンテンツを圧縮するための手段と、
復元バイトコードを含んでいるデータストラクチャを生成するための手段と、
前記通信デバイスに、前記圧縮されたIMSデータコンテンツと復元バイトコードを送信するための手段と、
前記通信デバイスからのリクエストにすぐ反応する前記通信デバイスに、前記復元バイトコードの実行可能なバージョンを送信するための手段と、
を備えている装置。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【公開番号】特開2013−101655(P2013−101655A)
【公開日】平成25年5月23日(2013.5.23)
【国際特許分類】
【外国語出願】
【出願番号】特願2013−260(P2013−260)
【出願日】平成25年1月4日(2013.1.4)
【分割の表示】特願2009−519687(P2009−519687)の分割
【原出願日】平成19年7月12日(2007.7.12)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.WCDMA
【出願人】(595020643)クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】QUALCOMM INCORPORATED
【Fターム(参考)】
【公開日】平成25年5月23日(2013.5.23)
【国際特許分類】
【出願番号】特願2013−260(P2013−260)
【出願日】平成25年1月4日(2013.1.4)
【分割の表示】特願2009−519687(P2009−519687)の分割
【原出願日】平成19年7月12日(2007.7.12)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.WCDMA
【出願人】(595020643)クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】QUALCOMM INCORPORATED
【Fターム(参考)】
[ Back to top ]