(57)【要約】　　　（修正有）【課題】伝送用にメッセージを圧縮および復元する方法、装置、システム、およびコンピュータ・ソフトウエアを提供する。【解決手段】伝送用にテキスト・メッセージを圧縮する方法は、テキスト・ストリングをパースして、数値を２進数表示で符号化することと、テキスト・ストリングの複数の値を分析して、該複数の値からの部分ストリングをセッション特有コードブックに写すことを備えるテキスト・メッセージを圧縮する。さらに、テキストメッセージをテンプレートでパースする、異なるテンプレートが、メッセージの各タイプに提供される、セッション特有コードブックが、伝送用に圧縮された第１テキスト・メッセージについて空であり、各メッセージが圧縮される際にエントリが追加される、部分ストリングを静的辞書でパースする、などの方法で圧縮する。【選択図】　　　図３
2004096717.tif 000002
【特許請求の範囲】
【請求項１】
伝送用にテキスト・メッセージを圧縮する方法であって、
テキスト・ストリングをパースして、数値を２進数表示で符号化すること、
テキスト・ストリングの複数の値を分析して、該複数の値からの部分ストリングをセッション特有コードブックに写すことを備えるテキスト・メッセージを圧縮する方法。
【請求項２】
テキスト・メッセージをテンプレートでパースする、請求項１に記載のテキスト・メッセージを圧縮する方法。
【請求項３】
異なるテンプレートが、メッセージの各タイプに提供される、請求項２に記載のメッセージを圧縮する方法。
【請求項４】
セッション特有コードブックが、伝送用に圧縮された第１テキスト・メッセージについて空であり、各メッセージが圧縮される際に、エントリが追加される、請求項１に記載のメッセージを圧縮する方法。
【請求項５】
部分ストリングを静的辞書でパースする、請求項１に記載のテキスト・メッセージを圧縮する方法。
【請求項６】
伝送用圧縮メッセージが、セッション開始プロトコル（ＳＩＰ）、セッション記述プロトコル（ＳＤＰ）、またはリアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）のメッセージである、請求項１に記載のメッセージを圧縮する方法。
【請求項７】
伝送用にメッセージを圧縮する方法であって、
メッセージをテンプレートでパースして、伝送される少なくとも１つのサブストリングを生成すること、
少なくとも１つのサブストリングをセッション特有コードブックのエントリでパースして、圧縮メッセージの第１部分を生成すること、
未知フィールド値のエントリをセッション特有コードブックに写すこと、
あらゆる不整合サブストリングを第１静的辞書のエントリでパースして、圧縮メッセージの第２部分を生成すること、
あらゆる依然として不整合のサブストリングを第２静的辞書のエントリでパースして、圧縮メッセージの第３部分を生成すること、
サブストリングの残りを圧縮アルゴリズムで圧縮すること、
圧縮メッセージの第１部分と、第２部分と、第３部分とを組み合わせて、伝送用圧縮メッセージを獲得することとを備える、メッセージを圧縮する方法。
【請求項８】
異なるテンプレートが、メッセージの各タイプに提供される、請求項７に記載のメッセージを圧縮する方法。
【請求項９】
セッション特有コードブックが、第１圧縮メッセージについて空であり、各メッセージが圧縮される際に、エントリが追加される、請求項７に記載のメッセージを圧縮する方法。
【請求項１０】
伝送用圧縮メッセージが、セッション開始プロトコル（ＳＩＰ）、セッション記述プロトコル（ＳＤＰ）、またはリアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）のメッセージである、請求項７に記載のメッセージを圧縮する方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本出願は、「Ｂｉｎａｒｙ　Ｐｒｏｔｏｃｏｌ　Ｆｏｒ　Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　ｉｎ　ａ　Ｗｉｒｅｌｅｓｓ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｓｙｓｔｅｍ」という名称のＣｈｕａｈらへの同時に提出された出願に関する。
【０００２】
【従来の技術】
本発明は、通信に関し、より具体的には、無線通信システム用のプロトコル・メッセージ圧縮に関する。
【０００３】
セルラ電話とインターネットの２つの通信技術が、一般大衆によって通常使用される。セルラ電話は、ユーザに移動の自由、すなわち位置に関係なく、妥当なサービス品質に到達する可能性を提供する。しかし、セルラ電話によって提供される主要なサービスは、スピーチである。あらゆる種類の使用法（スピーチ、データ、ビデオ、オーディオなど）に対する柔軟性が、インターネットの強みであったが、固定接続と比較的大きな端子を対象としており、いくつかのサービス（インターネット電話など）の品質は、一般に不良であった。技術が進むにつれ、インターネット技術とセルラ技術は、融合しつつある。未来のセルラ「電話」は、ＩＰスタック（インターネット・プロトコル）を含み、ウエッブ・ブラウジング、電子メールなどの他に、ＩＰ上での音声を支援する可能性がある。本質的に、インターネットは、移動性を帯びつつあり、または、セルラ・システムは、観点によっては、電話以上になりつつある。
【０００４】
図１は、従来のネットワーク１０を示し、これは、無線アクセス・ネットワーク（ＲＡＮ）１２とコア・ネットワーク（ＣＮ）１４に分割することができる。ＲＡＮ１２は、無線ユニット１８ａ〜ｂとネットワーク１０の間の無線インタフェース１６ａ〜６を支援するために使用される機器を備える。ＲＡＮ１２は、ＮｏｄｅＢまたは基地局２０ａ〜ｃを含み、これは、リンク（Ｉｕｂリンク）２１ａ〜ｃ上で無線ネットワークまたは基地局制御装置（ＲＮＣ）２２ａ〜ｂに接続される。基地局とＲＮＣの間の境界は、Ｉｕｂインタフェースまたはリンクと呼ばれ、２つのＲＮＣ間のインタフェースは、Ｉｕｒインタフェースと呼ばれる。現在、ＩｕｂインタフェースとＩｕｒインタフェースは、両方とも、ＡＴＭ（同期転送モード）に基づいており、ＡＴＭ切替えは、ＮｏｄｅＢとＲＮＣの間で可能である。
【０００５】
コア・ネットワーク１４は、ネットワーク要素を含み、これは、回路ベースの通信と、ならびにパケット・ベースの通信を支援する。無線ユニット１８ｂと公衆交換電話網（ＰＳＴＮ）２４または他の無線ユニットとの間における回路ベースの通信に対処するために、回路チャネルを確立する際に、基地局２０ｂは、無線インタフェースまたはリンク１６ｂ上で、符号化情報（回路音声または回路切替えデータ）を受信し（アップリンクにおいて）、送信する（ダウンリンクにおいて）。ＲＮＣ２２ｂは、フレーム選択と、符号化と、アクセス・ネットワーク・モビリティの取扱いの役割を担う。ＲＮＣ２２ｂは、回路音声と回路切替えデータを、ＡＴＭ／ＩＰネットワークなどのネットワーク上で３Ｇモバイル切替えセンタ（ＭＳＣ）３０に転送する。３Ｇ−ＭＳＣ３０は、ＭＳＣレベルに関するコール処理とマクロモビリティの役割を担う。３Ｇ−ＭＳＣ３０は、無線ユニット１８ｂとＰＳＴＮ２４の間の接続性を確立する。
【０００６】
本技術分野で通常使用される用語は、「オールＩＰ」および「ＩＰオール・ザ・ウエイ」である。これらの用語は、両方とも、経路がセルラ・リンクを含む場合でも、ＩＰが終端間で使用され、ＩＰが無線ホップ上でも実行される場合に関する。これは、すべてのタイプのトラフィック、ユーザ・データ（音声またはストリーミングなど）および制御信号データの両方、ＳＩＰ（セッション開始プロトコル）またはＲＴＳＰ（リアル・タイム・ストリーミング・プロトコル）に対して実施される。これの利点は、連続的な移動性によって提供される自由と組み合わされたＩＰが導入するサービスの柔軟性である。欠点は、たとえば大きなヘッダとテキスト・ベース・シグナリング・プロトコルなどにより、ＩＰプロトコル・スーツによって通常導入されるオーバーヘッドが比較的大きいことである。
【０００７】
セルラ・システムでは、まばらな無線リソースを効率的な方式で使用するべきである。セルあたりの十分に多数のユーザを支援することが可能であるべきであり、そうでない場合、コストが法外に高くなることになる。周波数スペクトルと、したがって帯域幅とは、セルラ・リンクではコストのかかるリソースであり、慎重に使用されるべきである。
【０００８】
ＲＯＨＣ（ローバスト・ヘッダ圧縮）ワーキング・グループは、リアル・タイム・プロトコル（ＲＴＰ）、ユーザ・データグラム・プロトコル（ＵＤＰ）、およびＩＰパケットのヘッダ部分に対する帯域幅要件を低減する問題をうまく解決した。この障害が取り除かれたので、移動性インターネットの性能を向上させる新しい可能性が生じている。これらの１つは、アプリケーション・シグナリング・プロトコルに関する。ＳＩＰ、ＲＴＳＰ、およびＳＤＰ（セッション記述プロトコル）などのプロトコルは、通常、移動性インターネットのアプリケーションをセット・アップし、かつ制御するために使用される。しかし、プロトコル・メッセージは、サイズが大きく、要求／応答の性質のために遅延を創出する。これらのメッセージの圧縮は、スペクトル効率を増大し、伝送遅延を低減する。
【０００９】
ＳＩＰは、マルチメディア・セッションまたはコールを確立、修正、および終端するためのアプリケーション・レイヤ・プロトコルである。これらのセッションには、インターネット・マルチメディア会議、インターネット電話、および同様の応用分野が含まれる。ＳＩＰは、ＴＣＰ（伝送制御プロトコル）またはＵＤＰに対して使用される。ＳＩＰは、テキスト・ベース・プロトコルであり、ＵＴＦ−８符号化のＩＳＯ１０６４６を使用する。
【００１０】
ＳＤＰを使用して、マルチメディア会議を宣伝し、会議のアドレスと会議のツール特有情報を伝達することが可能である。ＳＤＰは、一般的なリアル・タイム・マルチメディア・セッションの記述目的にも使用される。ＳＤＰは、ＳＩＰメッセージおよびＲＴＳＰメッセージのメッセージ本体において搬送される。ＳＤＰは、テキスト・ベースであり、ＵＴＦ−８符号化のＩＳＯ１０６４６文字集合を使用する。
【００１１】
ＲＴＳＰは、オーディオおよびビデオなど、リアル・タイム特性を有するデータの配信を制御するためのアプリケーション・レベル・プロトコルである。ＲＴＳＰは、ＵＤＰまたはＴＣＰ（あるいは他のプロトコル）をトランスポート・プロトコルとして使用することが可能である。ＲＴＳＰは、テキスト・ベースであり、ＵＴＦ−８符号化のＩＳＯ１０６４６文字集合を使用する。
【００１２】
上記のプロトコルは、多くの類似性を有する。これらの類似性は、この類似性がセルラ無線アクセスに関連して創出する問題の解決法に関する含意を有する。類似性には、以下が含まれる：
・要求および応答の特性。送信側が要求を送信したとき、送信側は、要求が応答を受信するまでアイドル状態のままであり、したがって、ＳＩＰ、ＳＤＰ、またはＲＴＳＰのセッションを終了するために、いくつかの往復時間を必要とする。
・要求および応答は、ＡＳＣＩＩをベースとする。したがって、値２３０を表示するために、３＊８＝２４ビットが使用される。同じ値の２進数表示は、比較すると、わずかに８ビットを必要とするだけである。
・必要な情報をセッションの参加者に提供するために、要求および応答はサイズが大きい。
【００１３】
ＳＩＰとＲＴＳＰは、多くの共通のヘッダ・フィールド名と、方法と、状況コードとを共有する。トラフィック・パターンも同様である。シグナリングは、主にセット・アップ段階中に実施される。ＳＩＰでは、これは、シグナリングの大半が、電話コールまたはマルチメディア・セッションをセット・アップするために実施されることを意味する。ＲＳＴＰでは、シグナリングの大半は、アプリケーション・データの送信前に実施される。
【００１４】
シグナリング・プロトコル・メッセージによって生じる問題を解決する必要性は、狭帯域セルラ・チャネル上で通常のＳＩＰ／ＳＤＰコール・セット・アップ・シーケンスを見ることによって、および簡単なシステム能力の例の結果を研究することによって、明らかになる。これらの結果は、１つのプロトコル・メッセージのサイズを低減することも、システムの能力に利益があることを示唆している。
【００１５】
図２は、間に無線リンクを有する２つの終端点間におけるＳＩＰシグナリングの例と、あるシステム想定下での結果的な遅延とを示す。
一方向遅延は、以下の式により計算される。
一方向遅延＝メッセージサイズ［ビット表示］／リンク・スピード［ビット／秒表示］＋ＲＴＴ［秒表示］／２　　式（１）
上式で、ＲＴＴは、往復時間である。
以下の値を使用した。
ＲＴＴ／２：７０ｍｓｅｃ
リンク・スピード　９．６ｋｂｐｓ
【００１６】
式（１）の遅延の式は、スピーチ・サービス用のＷＣＤＭＡ（広帯域符号分割多重アクセス）無線アクセス法の近似に基づく。たとえば、エラーのために行われる可能性のある再送信によって生じた遅延は無視される。
【００１７】
式（１）を図２の例に示した各ＳＩＰ／ＳＤＰメッセージに適用すると、第１ＳＩＰ／ＳＤＰメッセージから最終までで、４１３０ｍｓｅｃの全遅延が与えられる。図２に表示されたＲＳＶＰとセッション管理（無線ベアラ・セット・アップ）は、式（１）を使用して、約１．５秒を全遅延に追加する。しかし、無線ベアラを確立するために、ＳＩＰ　ＩＮＶＩＴＥメッセージの前にＲＳＶＰとＳＭのシグナリングも存在する可能性があり、これにより、さらに約１．５秒が追加される。
【００１８】
ＴＳＧ（技術仕様グループ）は、ＳＩＰを使用するＧＳＭ（モバイル用大域システム）エッジ（大域進化用改良データ・レート）無線アクセス・ネットワーク（ＧＥＲＡＮ）コール・セット・アップと、通常のＧＳＭコール・セット・アップの比較を実施した。通常のＧＳＭコール・セット・アップでは、時間は約３．６秒であり、ＳＩＰを使用する場合では、コール・セット・アップは、約７．９秒である。
【００１９】
ＳＩＰを使用してコール・セット・アップを低減する第１の解決法は、動的辞書とＬＺＳＳ（Ｌｅｍｐｅｌ−Ｚｉｖ−Ｓｔｏｒｅｒ−Ｓｚｙｍａｎｓｋｉ）圧縮アルゴリズムとを使用することである。動的辞書は、コンテキストに属するパケットが到着し続ける限り、維持される。パケット・フローが依然として能動であるかの判定は、タイマを使用して、またはプロトコルの意味論から実施することができる。この解決法は、各圧縮メッセージに２バイトのオーバーヘッドを導入する。
【００２０】
この第１解決法では、圧縮には、以下の工程が含まれる。
１．メッセージを辞書に付加し、ＬＺＳＳを使用して拡張ファイルを圧縮する
２．辞書に対応する圧縮ファイルの部分を、メッセージ対応する部分から分離する。これは可能であるが、その理由は、ＬＺＳＳは、左から右にファイルを処理し、すでに圧縮された部分は、圧縮が進行する際に変化しないからである。すなわち、辞書自体を圧縮すること、またはメッセージが付加された辞書を圧縮することは、同じ出力を作成する（圧縮メッセージとは別に）。
【００２１】
この第１解決法では、復元には、以下の工程が含まれる。
１．圧縮メッセージを圧縮辞書に附加し、拡張ファイルを復元する。
２．辞書からメッセージを分離する。これは可能であるが、その理由は、辞書の境界が既知であり、メッセージが、辞書に附加されているからである。
【００２２】
この第１解決法の成果は、以下の通りである。第１メッセージ圧縮比は、１．５であり、後続メッセージの圧縮比は、コンプレッサとデコンプレッサの動作モードに応じて、３．１から８．３にわたる。限定コンタクト・モードでは、デコンプレッサは、コンプレッサからのメッセージを承認することができ、それにより、コンプレッサは、デコンプレッサが、コンプレッサと同じ辞書を有することを確認することができる。完全コンタクト・モードでは、コンプレッサとデコンプレッサは、１つのエンティティであり、辞書を共有し、したがって、送信メッセージと受信メッセージの両方を、圧縮プロセスに使用することができる。
【００２３】
第２解決法は、圧縮アルゴリズムとして、ＬＺＪＨ（Ｌｅｍｐｅｌ−Ｚｉｖ−Ｊｅｆｆ−Ｈｅａｔｈ）を使用する。この第２解決法は、事前ロード辞書とマルチパケット・モードを使用し、この場合、辞書は、先行メッセージを使用し、次いでＬＺＪＨ圧縮アルゴリズムを使用して更新される。この第２解決法は、比２．８だけ第１メッセージを低減することができる。
【００２４】
要約すると、Ｌｅｍｐｅｌ−Ｚｉｖタイプのアルゴリズムを使用して、ＳＩＰメッセージを個々に圧縮するとき、圧縮比は、約１．５である。静的辞書が事前ロードされているので、ほとんどの従来の圧縮アルゴリズムは、ＳＩＰメッセージでは３未満の圧縮比をもたらす。コードブックに第１ＩＮＶＩＴＥメッセージをポピュレートしたとき、Ｌｅｍｐｅｌ−Ｚｉｖタイプのアルゴリズムは、圧縮比を５の付近まで向上させる。
【００２５】
【発明が解決しようとする課題】
したがって、システム帯域幅要件とサービス・セット・アップ遅延の両方を考慮するとき、シグナリング遅延と必要な帯域幅をさらに低減するために、より良好な解決法が必要である。
【００２６】
【課題を解決するための手段】
本発明は、メッセージを圧縮するためにマルチパケット圧縮アルゴリズムを使用することによって、コール・セット・アップ時間を短縮するメッセージ圧縮を対象とする。
【００２７】
本発明は、また、無線通信システムにおいてプロトコル・メッセージ圧縮を実施する方法、装置、システム、およびソフトウエアをも対象とする。本発明は、２進符号化、テンプレート、セッション特有コードブック、および／または従来のＬｅｍｐｅｌ−Ｚｉｖベースのアルゴリズムを組み合わせる圧縮アルゴリズムを使用する。本発明は、また、メッセージＩＤと、サービス・プロバイダ・アドレスなどのいくつかのフィールドの２進符号化と、発信者ユーザＩＤと、発信者ユーザ名と、着信者ユーザＩＤと、着信者ユーザ名とを使用し、またドメイン名用にＩＰｖ４フォーマットを使用する。本発明は、また、いくつかのフィールドについて数値の２進符号化を可能にする。本発明は、また、セッション特有コードブックと、修正指標付け機構と、コードブック管理と、セッション履歴とを提供する。さらに、本発明は、固定長サブフィールドと可変長サブフィールドとを有する順応性テンプレートと、ならびに随意選択フィールドを有する順応性テンプレートとを提供する。さらに、本発明は、汎用性無損失テキスト圧縮を提供する。例示的な実施形態では、本発明は、ＳＩＰサーバ／メディア・デュプリケータにおいて、セッション特有コードブックと随意選択辞書を使用することにより、より良好な圧縮を達成する。数値フィールドの２進符号化は、ＩＰアドレスのサイズ、発信者ＩＤ、セッションＩＤなどのサイズの低減にも役立つ。本発明は、また、順応性テンプレート構造も含み、選択テンプレート・フィールドに固定長を使用することを可能にし、長さインジケータまたは区切り文字で可変長フィールドを符号化する。本発明により、随意選択フィールドをテンプレートに挿入して、メモリに記憶する必要のあるテンプレートの全体の数を低減することも可能になる。
【００２８】
一例示的な実施形態では、本発明は、伝送用にテキスト・メッセージを圧縮する方法に関し、該方法は、テキスト・ストリングをパースすることと、２進数表示で数値を符号化することと、テキスト・ストリングの複数の値を分析することと、該複数の値から部分ストリングをセッション特有コードブックに写す（ポピュレート）こととを備える。他の例示的な実施形態では、本発明は、伝送用にメッセージを圧縮する方法を対象とし、該方法は、テンプレートでメッセージをパースして、伝送する少なくとも１つのサブストリングを生成することと、セッション特有コードブックのエントリで少なくとも１つのサブストリングをパースして、圧縮メッセージの第１部分を生成することと、未知フィールド値のエントリをセッション特有コードブックにポピュレートすることと、第１静的辞書のエントリで不整合サブストリングをパースして、圧縮メッセージの第２部分を生成することと、第２静的辞書のエントリで依然として不整合のサブストリングをパースして、圧縮メッセージの第３部分を生成することと、圧縮アルゴリズムでサブストリングの残りを圧縮することと、圧縮メッセージの第１部分と、第２部分と、第３部分とを組み合わせて、伝送用圧縮メッセージを獲得することとを備える。
【００２９】
本発明の他の態様および利点は、以下の詳細な記述を読み、図を参照する際に、明らかになる可能性がある。
【００３０】
【発明の実施の形態】
図３は、本発明のＳＩＰメッセージの圧縮／復元を実施することが可能である環境を示す。図３に示したように、２つのエンティティ１０、１２は、物理チャネル１４によって分離される。各エンティティ１０、１２には、物理レイヤ１６と、ＩＰレイヤ１８と、ＵＤＰ／ＴＣＰレイヤ２０と、本発明の圧縮／復元レイヤ２２と、ＳＩＰレイヤ２４とが含まれる。
【００３１】
図４は、本発明の一例におけるメッセージ圧縮フレームワークを示す。圧縮／復元レイヤ２２の内部では、エンティティ１０および１２には、コンプレッサ１００と、コードブック１０２と、デコンプレッサ１０４とが含まれ、これらを介して、オリジナル・メッセージ１０６と、圧縮メッセージ１０８と、復元メッセージ１１０とがパースされる。
【００３２】
図２に示したように、本発明の圧縮機構は、ＳＩＰアプリケーション２４とＵＤＰおよび／またはＴＣＰ２０との間のレイヤ２２として役立つ。圧縮の目的は、物理レイヤ１４を横断するデータの全体量を低減し、それにより遅延を低減することである。
【００３３】
圧縮アルゴリズムは、オリジナル・メッセージの優先情報がある場合によく機能する。セッション内のＳＩＰメッセージは、ユーザのアドレスおよびポート番号など、多くの共通情報を共有する。
【００３４】
ＳＩＰメッセージは、容易に圧縮することができる多くの繰返しヘッダを有する。圧縮アルゴリズムは、事前ロード辞書、動的辞書、またはテンプレートがある場合に機能することができる。ＳＩＰメッセージ用の例示的な静的辞書を以下に示す。
【００３５】
例示的な静的辞書では：
必要な空白は＜ｓｐ＞で示される
必要な改行復帰は、＜ｃｒ＞で示される
必要な改行は、＜ｌｆ＞で示される
【００３６】
他のすべての可能な空白、改行復帰、改行などは、例示的な静的辞書を使用するとき、破棄されるべきである。
＜静的辞書の開始＞
ＩＮＶＩＴＥ＜ｓｐ＞ｓｉｐ：＜ｓｐ＞ＳＩＰ／２．０＜ｃｒ＞＜１ｆ＞Ｖｉａ：＜ｓｐ＞ＳＩＰ／２．０／ＵＤＰ＜ｓｐ＞：５０６０＜ｃｒ＞＜１ｆ＞
＜ｓｐ＞から＜ｓｐ＞へコールＩＤ：＜ｓｐ＞ＣＳｅｑ：＜ｓｐ＞１＜ｓｐ＞ＩＮＶＩＴＥ＜ｃｒ＞＜１ｆ＞
コンタクト：＜ｓｐ＞コンテンツのタイプ：＜ｓｐ＞アプリケーション／ｓｄｐ＜ｃｒ＞＜１ｆ＞
コンテンツの長さ：＜ｓｐ＞０＜ｃｒ＞＜１ｆ＞ＳＩＰ／２．０＜ｓｐ＞１００＜ｓｐ＞試行＜ｃｒ＞＜１ｆ＞
ＳＩＰ／２．０＜ｓｐ＞１８０＜ｓｐ＞呼出し信号＜ｃｒ＞＜１ｆ＞ＳＩＰ／２．０＜ｓｐ＞２００＜ｓｐ＞ＯＫ＜ｃｒ＞＜１ｆ＞
ＳＩＰ／２．０＜ｓｐ＞１８１＜ｓｐ＞呼＜ｓｐ＞Ｉｓ＜ｓｐ＞ビーイング＜ｓｐ＞転送済み＜ｃｒ＞＜１ｆ＞
ＳＩＰ／２．０＜ｓｐ＞１８２＜ｓｐ＞キューに入れた＜ｃｒ＞＜１ｆ＞ＳＩＰ／２．０＜ｓｐ＞１８３＜ｓｐ＞セッション＜ｓｐ＞
進行
＜ｃｒ＞＜１ｆ＞
ＰＲＡＣＫ＜ｓｐ＞ｓｉｐ：ＣＯＭＥＴ＜ｓｐ＞ｓｉｐ：ＡＣＫ＜ｓｐ＞ｓｉｐ：ＢＹＥ＜ｓｐ＞ｓｉｐ：受容：＜ｓｐ＞受容−
符号化：＜ｓｐ＞受容−言語：＜ｓｐ＞可能にする：＜ｓｐ＞許可：＜ｓｐ＞
コンテンツ符号化：＜ｓｐ＞コンテンツの長さ：＜ｓｐ＞暗号化：＜ｓｐ＞
満了：＜ｓｐ＞隠す：＜ｓｐ＞コンタクト：＜ｓｐ＞最大転送：＜ｓｐ＞
代理認証：＜ｓｐ＞代理許可：＜ｓｐ＞代理要求：＜ｓｐ＞
要求：＜ｓｐ＞応答＜ｓｐ＞キー：＜ｓｐ＞経路：＜ｓｐ＞タイムスタンプ：＜ｓｐ＞
不支援：＜ｓｐ＞ユーザ−エージェント：＜ｓｐ＞ＷＷＷ−認証：＜ｓｐ＞支援：＜ｓｐ＞
遠隔当事者−ＩＤ：＜ｓｐ＞代理要求：＜ｓｐ＞匿名：＜ｓｐ＞
＜静的辞書の終了＞
【００３７】
テンプレートは、順序ストリングの表である。辞書と比較して、固定ヘッダ情報は、伝送する必要がなく、したがって、メッセージのサイズをさらに低減する。各タイプのメッセージに対して、デフォルト・テンプレートを確定することができる。以下は、テンプレートをベースとする符号化の例である。
【００３８】
図５は、テンプレートをベースとする符号化の例である。テンプレートは、テンプレートＩＤ（ＴＩＤ）と、４つの静的フィールド（ｓｓ０、ｓｓ２、ｓｓ４、およびｓｓ６）と、３つのブランク・フィールド（ｂ１、ｂ３、およびｂ５）とを有する。すべてのブランク・フィールドは、可変長を有することが想定されている。話を簡単にするために、フィリング・サブストリング（ｓｓ１、ｓｓ３、およびｓｓ５）は、＜長さ、値＞の形態で符号化される。再び話を簡単にするために、値は、オリジナル・サブストリングの非圧縮形態であることが想定されている。
【００３９】
辞書をベースとする圧縮と比較するとき、テンプレートをベースとする圧縮は、より高い圧縮効率を達成することができるが、その理由は、静的部分の位置と長さの情報が、すでにテンプレートに記憶されており、転送する必要がないからである。
【００４０】
テンプレートは、メッセージの各タイプに対して確定することができる。テンプレートの数が増えるとき、テンプレートに関連付けられたメモリは、問題となる可能性がある。代替として、追加のフィールドをテンプレートに挿入することができる。ヘッダＩＤ（ＨＩＤ）は、各ヘッダに割り当てることができる。次いで、追加のフィールドを所望の位置において＜ＨＩＤ｜Ｌｘ｜ｓｓｘ＞として圧縮ストリングに挿入することができる。
【００４１】
以前の研究で示されているように、第１ＩＮＶＩＴＥメッセージの圧縮比は、テンプレートをベースとする手法でさえ有意ではなかった。ＳＩＰ／ＳＤＰフィールドのコンテンツに関する知識があるので、Ｌｅｍｐｅｌ−Ｚｉｃタイプの圧縮アルゴリズムなど一般的な圧縮アルゴリズムと比較して、圧縮性能を向上させることが可能である。
【００４２】
追加の静的辞書を、いくつかの選択ＳＩＰフィールド値に使用することができる。この辞書は、通常のインターネット・セッションの＜ネットワーク・タイプ＞＜アドレス・タイプ＞フィールドの「ＩＮ　ＩＰ４」など、通常のＳＤＰ値を含むことができる。ほとんどのＵＩＤ（ユーザ識別）は、４バイトによって表すことができる。サービス・プロバイダは、通常、２億５６００万未満の加入者を有し、したがって、４つの最上位ビットを使用して、サービス・プロバイダ識別子と、ユーザ名を表す残りのビットとを表すことができる。数値がフィールドにおいて期待されるとき、２進数表示を使用することができる。
【００４３】
本発明の一例示的な実施形態における圧縮方法は、以下のように要約することができる。
１）整合テンプレートでメッセージをパースして、伝送する必要のあるサブストリングを生成する。
２）セッション特有コードブック（空に初期化されている）でサブストリングをパースして、圧縮メッセージの一部を生成する。
３）未知フィールド値をセッション特有コードブックにポピュレートする。
４）静的辞書で不整合サブストリングをパースして、圧縮メッセージの一部を生成する。
５）随意選択静的辞書で不整合サブストリングをパースして、圧縮メッセージの一部を出力する。
６）ＬＺＳＳでサブストリングの残りを圧縮する。
７）工程）２）および４）〜６）の結果を最終圧縮メッセージとして組み合わせる。
【００４４】
テンプレートのいくつかのサブストリングに、圧縮後、デフォルト長を割り当てることができ、これにより、各フィールドについて１バイト低減することになることに留意されたい。事前に定義した拡張文字を使用して、長さの変化にフラグを立てることが可能である。
【００４５】
上記で概述した例示的な圧縮アルゴリズムは、以下のいくつかの例に適用され、その場合、図６に示したように、成功した簡単なＳＩＰからＳＩＰへのコールが確立される。
例１−メッセージの詳細
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
Ｆ１　ＩＮＶＩＴＥ　ユーザＡ　→　ユーザＢ
ＩＮＶＩＴＥ　ｓｉｐ：ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ　ＳＩＰ／２．０
ＳＩＰ／２．０／ＵＤＰ　ｈｅｒｅ．ｃｏｍ：５０６０を介して
ビッグガイ＜ｓｉｐ：ユーザＡ＠ｈｅｒｅ．ｃｏｍ＞から
リトルガイ＜ｓｉｐ：ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ＞へ
コール−ＩＤ：ｌ２３４５６０１＠ｈｅｒｅ．ｃｏｍ
ＣＳｅｑ：１　ＩＮＶＩＴＥ
コンタクト：＜ｓｉｐ：ユーザＡ＠１００．１０１．１０２．１０３＞
コンテンツのタイプ：アプリケーション／ｓｄｐ
コンテンツの長さ：１４７
ｖ＝０
ｏ＝ユーザＡ　２８９０８４４５２６　２８９０８４４５２６　ＩＮ　ＩＰ４　ｈｅｒｅ．ｃｏｍ
ｓ＝セッションＳＤＰ
ｃ＝ＩＮ　ＩＰ４　１００．１０１．１０２．１０３
ｔ＝０　０
ｍ＝オーディオ４９１７２　ＲＴＰ／ＡＶＰ　０
ａ＝ｒｔｐマップ：０　ＰＣＭＵ／８０００
【００４６】
工程１を適用して、メッセージを整合テンプレートでパースし、伝送する必要のあるサブストリングを生成する。例１では、工程１の結果は以下の通りである。
テンプレートＩＤ：ＴＩＤ
ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ
ｈｅｒｅ．ｃｏｍ：５０６０
ビッグガイ　ユーザＡ＠ｈｅｒｅ．ｃｏｍ
リトルガイ　ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ
１２３４５６０１（”＠ｈｅｒｅ．ｃｏｍ”　は、上記と同じであると想定されている。）
１　ＩＮＶＩＴＥ
＜１００．１０１．１０２．１０３＞（”ｓｉｐ：ユーザＡ＠”　は、上記と同じであると想定されている。）
（”アプリケーション／ｓｄｐ”　は同じであると想定されている。）
１４７
２８９０８４４５２６　（上記から取られた”ユーザＡ”　”ＩＮ　ＩＰ４　ｈｅｒｅ．ｃｏｍ”　”２８９０８４４５２６”　通知のバージョンは、セッションｉｄと同じタイムスタンプである。）
１００．１０１．１０２．１０３
４９１７２　（”オーディオ”　”ＲＴＰ／ＡＶＰ　０”）
ｒｔｐマップ：０　ＰＣＭＵ／８０００．
コメントを除くと、結果的なサブストリングは、以下のようになる。
ＴＩＤ
ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ
ｈｅｒｅ．ｃｏｍ
ビッグガイ　ユーザＡ＠ｈｅｒｅ．ｃｏｍ
リトルガイ　ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ
１２３４５６０１
１　ＩＮＶＩＴＥ
１００．１０１．１０２．１０３
１４７
２８９０８４４５２６
１００．１０１．１０２．１０３
４９１７２
ｒｔｐマップ：０　ＰＣＭＵ／８０００．
【００４７】
工程２を適用して、サブストリングを、セッション特有コードブック（空に初期化）でパースし、圧縮メッセージの一部を生成する。セッション特有コードブックは空なので、出力は生成されない。
【００４８】
工程３を適用して、未知フィールド値をセッション特有コードブックにポピュレートする。結果的なセッション特有コードブックは、後続メッセージの圧縮に使用される。例１では、結果的なセッション特有コードブックは、表１に示した通りである。
【表１】
2004096717.tif 000003
【００４９】
表１では、各ヘッダが、１つのエントリを有することに限定されていないことに留意されたい。さらに、すべての未知フィールドが、コードブックにポピュレートするために使用されるわけではないが、その理由は、ＳＤＰの通知数など、いくつかは、繰り返されない可能性があるからである。次いで、セッション特有コードブックを使用して、同じセッションの後続メッセージを圧縮／復元することができる。コードブック管理は、役立つ可能性があることに留意されたい。たとえば、エントリとの整合が見つけられたとき、１バイトを使用して、セッション・プロファイルのヘッダを示し、他のバイトを使用して、どのエントリがヘッダに整合するかを特定する。
【００５０】
工程４を適用して、上記で示したものなど、不整合サブストリングを標準静的辞書でパースし、圧縮メッセージの一部を生成する。例１では、すべてのヘッダと多くの一定値が、テンプレートに含まれているので、標準静的辞書によりパースすることによって、追加の出力が生成されることはない。
【００５１】
工程５を適用して、不整合サブストリングを静的辞書でパースし、圧縮メッセージの一部を出力する。
【表２】
2004096717.tif 000004
【００５２】
例１では、工程５の結果は、３７バイトまたは３２バイトである。
すべてのドメイン名は、ＳＩＰエンティティの随意選択静的辞書に記憶することが可能であることに留意されたい。例１では、１バイトが、各ドメイン名に割り当てられる。同時に、装置を初期化するとき、４バイトのユーザ・アドレスを伝送ＳＩＰエンティティに割り当てることが可能である。
【００５３】
工程６を適用して、ストリングの残りを、ＬＺＳＳなどの例示的な圧縮アルゴリズムで圧縮する。
【００５４】
ＴＩＤは、１バイトで表すことができる。ユーザｉｄ（ユーザ・アドレスの＠の前のストリング）は、５バイトの長さであり、ユーザ名（リトルガイ）は、１０バイトの長さである。例１では、ＬＺＳＳ圧縮後、せいぜい１６バイトが生成されることになる。
【００５５】
工程７を適用して、工程２および４〜６の出力を最終圧縮メッセージとして組み合わせる。これにより、３７バイトまたは３２バイトと、ＬＺＳＳ圧縮後に生成された１６を得る。
３７＋１６＝５３バイト
または３２＋１６＝４８バイト
上式は、
４２３／５３＝８．０；４２３／４８＝８．８
の圧縮比である。
【００５６】
以下の例は、後続メッセージの工程を記述する。
例２−メッセージの詳細
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
Ｆ２（１００　試行）　ユーザＢ　→　ユーザＡ
ＳＩＰ／２．０　１００　試行
ＳＩＰ／２．０／ＵＤＰ　ｈｅｒｅ．ｃｏｍ：５０６０を介して
ビッグガイ＜ｓｉｐ：ユーザＡ＠ｈｅｒｅ．ｃｏｍ＞から
リトルガイ＜ｓｉｐ：ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ＞へ
コール−ＩＤ：１２３４５６０１＠ｈｅｒｅ．ｃｏｍ
ＣＳｅｑ：　１　ＩＮＶＩＴＥ
コンテンツの長さ：　０
【００５７】
例１からメッセージＦ１を復号した後、ユーザＢは、ＩＮＶＩＴＥメッセージのコンテンツをコードブックにポピュレートした。
【００５８】
工程１を例２に適用して、以下のサブストリングを生成する。
ＴＩＤ
ｈｅｒｅ．ｃｏｍ
ビッグガイ　ユーザＡ＠ｈｅｒｅ．ｃｏｍ
リトルガイ　ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ
１２３４５６０１
１　ＩＮＶＩＴＥ
０
【００５９】
工程２を例２に適用して、表３に示したように、サブストリングを、セッション特有コードブックでパースする。
【表３】
2004096717.tif 000005
【００６０】
８バイトの小計を得る。
アルゴリズムが、コンプレッサとデコンプレッサがコードブック１０２を共有する完全コンタクト・モードにあると想定すると、ユーザＡが、圧縮ＩＮＶＩＴＥメッセージを送信した後、ユーザＡにおけるデコンプレッサ１０４も、セッション特有コードブックにアクセスすることができる。ＩＮＶＩＴＥメッセージがユーザＢによって受信されたとき、ユーザＢは、セッション特有コードブックにポピュレートし、このコードブックは、ユーザＡにおけるセッション特有コードブックと同一になる。それにより、メッセージ（１００試行）が圧縮および復元されたとき、セッション特有コードブックを使用することができる。
【００６１】
工程３を適用して、セッション特有コードブックにポピュレートする。この例では、新しいストリングはない。
【００６２】
工程４を適用して、標準静的辞書は、整合がないことを明らかにし、これにより、０バイトの第２小計を得る。
【００６３】
工程５を適用して、随意選択静的辞書をパースし、表４を生成して、これにより、３バイトの第３小計を得る。
【表４】
2004096717.tif 000006
【００６４】
工程６を適用して、サブストリングの残りを、ＬＺＳＳまたは他の例示的な圧縮アルゴリズムで圧縮する。
【００６５】
ＴＩＤは、１バイトのテンプレート指標であり、これにより、１バイトの第４小計を得る。
【００６６】
工程７を適用して、出力を組み合わせて、
８＋０＋３＋１＝１２バイト
を生成する。これは、１８７／１２＝１５．６の圧縮比である。
例３−メッセージの詳細
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
Ｆ３　１８０　呼出し信号　ユーザＢ　→　ユーザＡ
ＳＩＰ／２．０　１８０　呼出し信号
ＳＩＰ／２．０／ＵＤＰ　ｈｅｒｅ．ｃｏｍ：５０６０を介して
ビッグガイ＜ｓｉｐ：　ユーザＡ＠ｈｅｒｅ．ｃｏｍ＞から
リトルガイ＜ｓｉｐ：　ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ＞へ
コール−ＩＤ：１２３４５６０１＠ｈｅｒｅ．ｃｏｍ
ＣＳｅｑ：　１　ＩＮＶＩＴＥ
コンテンツの長さ：　０
【００６７】
上記と同じ手順を例２に適用すると、結果的なメッセージは１２バイトであり、圧縮比は、１８７／１２＝１５．６である。
例４−メッセージの詳細
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
Ｆ４　２００　ＯＫ　ユーザＢ　→　ユーザＡ
ＳＩＰ／２．０　２００　ＯＫ
ＳＩＰ／２．０／ＵＤＰ　ｈｅｒｅ．ｃｏｍ：５０６０を介して
ビッグガイ＜ｓｉｐ：　ユーザＡ＠ｈｅｒｅ．ｃｏｍ＞から
リトルガイ＜ｓｉｐ：　ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ＞へ
コール−ＩＤ：１２３４５６０１＠ｈｅｒｅ．ｃｏｍ
ＣＳｅｑ：　１　ＩＮＶＩＴＥ
コンタクト：　＜ｓｉｐ：　ユーザＢ＠１１０．１１１．１１２．１１３＞
コンテンツのタイプ：　アプリケーション／ｓｄｐ
コンテンツの長さ：　１４７
ｖ＝０
ｏ＝ユーザＢ　２８９０８４４５２７　２８９０８４４５２７　ＩＮ　ＩＰ４　ｔｈｅｒｅ．ｃｏｍ
ｓ＝セッションＳＤＰ
ｃ＝ＩＮ　ＩＰ４　１１０．１１１．１１２．１１３
ｔ＝０　０
ｍ＝オーディオ３４５６　ＲＴＰ／ＡＶＰ　０
ａ＝ｒｔｐマップ：０　ＰＣＭＵ／８０００
【００６８】
工程１を例４に適用して、以下のサブストリングを生成する。
ＴＩＤ
ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ
ｈｅｒｅ．ｃｏｍ
ビッグガイ　ユーザＡ＠ｈｅｒｅ．ｃｏｍ
リトルガイ　ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ
１２３４５６０１
１　ＩＮＶＩＴＥ
１１０．１１１．１１２．１１３
１４７
２８９０８４４５２７
１１０．１１１．１１２．１１３
３４５６
ｒｔｐマップ：０　ＰＣＭＵ／８０００
【００６９】
工程２を例４に適用して、表５に示したように、セッション特有コードブックでサブストリングをパースし、これにより、１６バイトの第１小計を得る。
【表５】
2004096717.tif 000007
【００７０】
工程３を例４に適用して、表６に示したように、セッション特有コードブックにポピュレートする。
【表６】
2004096717.tif 000008
【００７１】
工程４を例４に適用して、静的辞書に整合がないことを見つけ、これにより、０バイトの第２小計を得る。
【００７２】
工程５を例４に適用して、以下の表７に示したように、いくつかの整合を明らかにし、これにより、１４バイトの第３小計を得る。
【表７】
2004096717.tif 000009
【００７３】
工程６を例４に適用して、ＴＩＤの１バイト・テンプレート指標であるサブストリングの残りをＬＺＳＳで圧縮して、他の１バイトの小計を生成する。
例４の出力を組み合わせると、
１６＋１４＋１＝３１バイトとなり、これは、圧縮比：４０３／３１＝１３である。
【００７４】
例５−メッセージの詳細
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
Ｆ５　ＡＣＫ　ユーザＡ　→　ユーザＢ
ＡＣＫ　ｓｉｐ：　ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ　ＳＩＰ／２．０
ＳＩＰ／２．０／ＵＤＰ　ｈｅｒｅ．ｃｏｍ：５０６０を介して
ビッグガイ＜ｓｉｐ：ユーザＡ＠ｈｅｒｅ．ｃｏｍ＞から
リトルガイ＜ｓｉｐ：ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ＞へ
コール−ＩＤ：　１２３４５６０１＠ｈｅｒｅ．ｃｏｍ
ＣＳｅｑ：　１　ＡＣＫ
コンテンツの長さ：０
上記と同じ手順を例２に適用すると、結果的なメッセージは１２バイトであり、圧縮比は、１９７／１２＝１６．４である。
【００７５】
例６−メッセージの詳細
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
Ｆ６　ＢＹＥ　ユーザＢ　→　ユーザＡ
ＢＹＥ　ｓｉｐ：ユーザＡ＠ｈｅｒｅ．ｃｏｍ　ＳＩＰ／２．０
ＳＩＰ／２．０／ＵＤＰ　ｔｈｅｒｅ．ｃｏｍ：５０６０を介して
リトルガイ＜ｓｉｐ：ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ＞から
ビッグガイ＜ｓｉｐ：ユーザＡ＠ｈｅｒｅ．ｃｏｍ＞へ
ＣＳｅｑ：　１　ＢＹＥ
コンテンツの長さ：　０
工程１を例６に適用すると、以下のサブストリングが生成される。
ＴＩＤ
ユーザＡ＠ｈｅｒｅ．ｃｏｍ
ｔｈｅｒｅ．ｃｏｍ
リトルガイ　ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ
ビッグガイ　ユーザＡ＠ｈｅｒｅ．ｃｏｍ
１２３４５６０１
１　ＢＹＥ
０
【００７６】
工程２を例６に適用して、表８に示したように、サブストリングをセッション特有コードブックでパースして、１０バイトの第１小計を得る。
【表８】
2004096717.tif 000010
【００７７】
工程３を例６に適用して、表９に示したように、セッション特有コードブックにポピュレートする。
【表９】
2004096717.tif 000011
【００７８】
工程４を例６に適用して、標準静的辞書は、整合がないことを明らかにし、これにより、０バイトの第２小計を得る。
【００７９】
工程５を例６に適用して、随意選択静的辞書をパースし、表１０を生成して、これにより、４バイトの第３小計を得る。
【表１０】
2004096717.tif 000012
【００８０】
工程６を例６に適用して、ＴＩＤの１バイト・テンプレート指標であるサブストリングの残りをＬＺＳＳで圧縮して、他の１バイトの小計を生成する。
【００８１】
例６の出力を組み合わせると、１０＋４＋１＝１５バイトとなり、これは、圧縮比１９７／１５＝１３．１である。
【００８２】
例７−メッセージの詳細
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
Ｆ７　２００　ＯＫ　ユーザＡ　→　ユーザＢ
ＳＩＰ／２．０　２００　ＯＫ
ＳＩＰ／２．０／ＵＤＰ　ｔｈｅｒｅ．ｃｏｍ：５０６０を介して
リトルガイ＜ｓｉｐ：ユーザＢ＠ｔｈｅｒｅ．ｃｏｍ＞から
ビッグガイ＜ｓｉｐ：ユーザＡ＠ｈｅｒｅ．ｃｏｍ＞へ
コールＣａｌｌ−ＩＤ：１２３４５６０１＠ｈｅｒｅ．ｃｏｍ
ＣＳｅｑ：　１　ＢＹＥ
コンテンツの長さ：　０
上記と同じ手順を例２に適用すると、結果的なメッセージは１２バイトであり、圧縮比は、１８１／１２＝１５．１である。
【００８３】
図７は、他のメッセージについて、本発明の方法によって達成される圧縮比を示す。
【００８４】
要約すると、セッション特有コードブックを使用する以前の研究では、コードブックには、メッセージのフィールドがそのままポピュレートしており、「から」フィールドで指標付けされている。本発明の例示的な実施形態では、フィールド値は、フィールド全体の他に分析され、キーワードが抽出される。その結果、本発明のコードブックは、より多くの整合を生成し、メモリは、穏当に増大するだけである。
【００８５】
さらに、先行研究では、ユーザ・アドレス用の直接的な表検索は、メモリ要件が大きく、探索時間が長いために、回避されていた。さらに、ドメイン名のルックアップ表は、すべてのＳＩＰエンティティの随意選択静的辞書に記憶される。プッシュアンドトーク・サービスを提供するサービス・プロバイダの数は非常に限定されているので、１バイトを各ドメイン名に割り当てることができる。
【００８６】
プッシュ・ツー・トーク・サービスでは、ＳＩＰサーバ／プロキシ・サーバ／リダイレクト・サーバは、ネットワーク側に配置され、これにより、完全なユーザ・アドレス探索を実施するのに十分強力であることが推定される。したがって、４バイトの２進ＩＤが、各ユーザ・アドレスに割り当てられる。この４バイトＩＤは、装置が初期化されるとき、各ＳＩＰエンティティにも割り当てられる。したがって、ＩＮＶＩＴＥメッセージでは、モバイル装置は、アドレスをこの４バイトＩＤで簡単に置き換えることができる。
【００８７】
さらに、本発明を圧縮に関して記述してきたが、当業者なら、復元工程は、上述した圧縮工程の反対であることを理解するであろう。
【００８８】
本発明は、セッション間辞書フィーチャを実施することもできる。装置が、最近のユーザ・アドレスの履歴をメモリに記憶するようにプログラムされた場合、最終セッションのＩＮＶＩＴＥメッセージをさらに低減することを期待することができる。さらに、グループ・サービスを購入する者に対して、サービス・プロバイダは、４バイト２進ＩＤを有するユーザ・アドレスをマップする小さいルックアップ表を提供することができる。この手法により、ユーザ・アドレスの圧縮（４バイト２進ＩＤの使用による）は、第１ＩＮＶＩＴＥメッセージに対しても実施することができる。
【００８９】
本発明は、２進符号化、テンプレート、セッション特有コードブック、および／または従来のＬｅｍｐｅｌ−Ｚｉｖアルゴリズムを組み合わせる圧縮アルゴリズムを使用する。結果的な圧縮ＳＩＰメッセージは、オリジナル・メッセージと比較して、サイズが約１／１０である。
【００９０】
上述したように、この利益の１つまたは複数の理由は、上述した本発明の特徴の１つまたは複数の結果である。これらの特徴には、メッセージＩＤの使用、サービス・プロバイダ・アドレスなどの選択フィールドの２進符号化、発信者ユーザＩＤ、発信者ユーザ名、着信者ユーザＩＤ名、着信者ユーザＩＤ名、およびドメイン名用ＩＰＶ４フォーマットが含まれる。これらの特徴には、また、選択数値の２進符号化、セッション特有コードブックの使用、修正指標付け機構も含まれる。さらに、これらの特徴には、コードブック管理とセッション履歴が含まれる。さらに、これらの特徴には、固定長および可変長を有する順応性テンプレートと、ならびに随意選択フィールドを有する順応性テンプレートとが含まれる。上記の特徴の１つまたは複数の組み合わせは、汎用性無損失テキスト圧縮を提供する際に効果的である。
【００９１】
さらに上述したように、各ＳＩＰエンティティには、コンプレッサ１００とデコンプレッサ０４の両方が含まれる。したがって、情報をコンプレッサ１００とデコンプレッサ１０４の間で共有して、メッセージのサイズをさらに低減することができる。
【００９２】
上記で識別した例は、ＳＩＰプロトコル・メッセージの文脈で記述されているが、これらの例は、ＳＤＰ、ＲＴＳＰ、またはあらゆる他の周知のプロトコルあるいは将来開発されるプロトコルに等しく適用可能である。
【００９３】
さらに、本発明の特徴を方法の文脈で記述してきたが、これらの特徴は、装置、システム、およびソフトウエア・アプリケーションにも適用可能であり、装置システム、またはソフトウエアについて本出願の教示を実現することは、当業者よって達成可能である。
【００９４】
記述は、本発明の原理の適用の単なる例示である。当業者なら、本明細書において示し、記述した例示的な応用例に厳密に従わずに、かつ本発明の精神および範囲から逸脱せずに、これらおよび様々な他の修正、構成、および方法を本発明に対して実施することができることを容易に理解するであろう。
【図面の簡単な説明】
【図１】従来のネットワーク・アーキテクチャの一般的なブロック図である。
【図２】９６００ｂｐｓのリンク・スピードと１４０ｍｓｅｃのＲＴＴとを想定したＳＩＰシグナリング遅延の図である。
【図３】本発明の一例示的な実施形態における圧縮を実施する例示的なアーキテクチャの図である。
【図４】本発明の一例示的な実施形態における例示的なメッセージ圧縮フレームワークを示す図である。
【図５】本発明の一例示的な実施形態における、テンプレートをベースとする符号化を示す図である。
【図６】本発明の一例示的な実施形態における、ユーザＡがコール・ユーザＢを完了する例を示す図である。
【図７】本発明の一例示的な実施形態において達成される圧縮の結果を示す図である。
【図１】
2004096717.tif 000013
【図２】
2004096717.tif 000014
【図３】
2004096717.tif 000015
【図４】
2004096717.tif 000016
【図５】
2004096717.tif 000017
【図６】
2004096717.tif 000018
【図７】
2004096717.tif 000019