JP2004531993A

JP2004531993A - キャッシュ及び空白化手法を用いてテキストベースの圧縮を行なうための装置と方法

Info

Publication number: JP2004531993A
Application number: JP2003509745A
Authority: JP
Inventors: ビー．オヘア、ジョン; エム．アレン、アンドリュー; ディ．マギー、ステファン; ユーリンチェン、コリン; マジュムダル、イシタ; ティ．フォスター、ゲリー
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 2001-06-29
Filing date: 2002-06-28
Publication date: 2004-10-14
Also published as: US20030013431A1; CN1522526A; EP1405488A1; US6766147B2; WO2003003695A1

Abstract

テキストベースメッセージを圧縮及び圧縮するための装置と方法。ＴＣＣＢ層１１４、１１５を、移動装置１００とＰ−ＣＳＣＦ１０２に追加する。送信装置では、ＴＣＣＢ圧縮法を呼び出して、送信されるメッセージに含まれる全ての冗長なヘッダ情報を除去する。特定のシーケンスの間、ヘッダのコンテンツが以前送信又は受信されたものと同じであることをＴＣＣＢ圧縮法が検出した場合、ＴＣＣＢ法は、そのヘッダコンテンツを空白にする。受信装置では、ヘッダコンテンツが空白状態であるメッセージをＴＣＣＢ層が受信すると、ＴＣＣＢ解凍法を呼び出して、そのキャッシュ１１５、１２７からヘッダを再構成する。

Description

【技術分野】
【０００１】
本発明は、一般的に、通信システムの分野に関し、特に、テキストベースの圧縮方式に関する。
【背景技術】
【０００２】
現在、電話通信サービスは、主として、回線交換網を介して提供される。急速に台頭しつつある新様式の所謂ＩＰ電話通信は、インターネットプロトコル（ＩＰ）ネットワークを介して、電話通信サービスを提供する。データネットワークを介した音声トラフィック搬送の動因は、音声とデータアプリケーションの統合であるが、このことによって、ビジネスプロセスの効率が高まり、音声通話コストが低減され、また、企業や顧客が数多くの新しいサービスを利用できるようになる。ＩＰ電話通信が提供する柔軟性は、情報交換がネットワークから端末局に移ることにあり、これによって、従来存在しなかった数多くの新しいサービスが利用可能になる。インターネット電話通信とセルラ式電話通信を統合しようとする場合、端末間通話確立遅延及び音声品質という２つの側面が注目される。
【０００３】
セッション起動プロトコル（ＳＩＰ）及びセッション記述プロトコル（ＳＤＰ）等のプロトコルは、通常、通話の確立や切断に用いられる。しかしながら、ＳＩＰやＳＤＰ等のＡＳＣＩＩベースのプロトコルを帯域が限定されたアクセスネットワークで採用すると、通話確立に多大な遅延が生じる。規模が大きいテキストメッセージを無線インターフェイスで送信しても、伝送媒体を極めて非効率的に用いることになる。更に、ＧＳＭ＿ＥＤＧＥ無線アクセスネットワーク（ＧＥＲＡＮ）等、従来の技術を受け継いだ高度時分割多元（ＴＤＭ）セルラ式送受信機には、受信通話ＳＩＰ通信メッセージを送信するために、音声帯域幅を“盗用”しなければならないものがある。音声帯域幅をこのように盗用すると、無音の状態が長く続く可能性がある。
【０００４】
従って、スペクトル効率を向上し、伝送遅延を低減し、また、回線交換システムと比較して遜色の無いレベルのサービス品質を提供するために、テキストベースのメッセージを圧縮する方法に対するニーズがある。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、スペクトル効率を向上し、伝送遅延を低減し、また、回線交換システムと比較して遜色の無いレベルのサービス品質を提供するために、テキストベースのメッセージを圧縮するための方法と装置を提供する。
【課題を解決するための手段】
【０００６】
特に、本発明は、キャッシュ及び空白化手法（ＴＣＣＢ）を用いて、テキストベースの圧縮を行なうための装置と方法を提供する。
【発明の効果】
【０００７】
ＴＣＣＢは、拡張可能であり、様々なアクセス技術で動作することが可能であり、また、その原理は、あらゆるテキストベースのプロトコルに適用し得る。ＴＣＣＢ法の利点は、テキストベースメッセージを圧縮したり解凍したりするために、ユーザ装置（ＵＥ）（例：移動装置）とピアコアネットワークエンティティ（例：プロキシＣＳＣＦ）だけが情報の記憶と検索に関与すればよいことである。
【発明を実施するための最良の形態】
【０００８】
図１は、本発明によるＴＣＣＢ装置及び方法を実現するために用い得る構成を示すブロック図である。好適な実施形態において、この構成には、無線アクセスネットワーク（ＲＡＮ）１０４に接続された移動装置１００とプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）１０２とが含まれる。移動装置１００は、ＲＡＮ１０４に無線インターフェイス１０６を介してＲＡＮ１０４に接続され、また、Ｐ−ＣＳＣＦ１０２は、ＩＰインターフェイス１０８を介してＲＡＮ１０４に接続される。上記構成要素の機能と接続性に関する更に詳細な説明は、ＴＲ２３．８２１ｖ１．０．０（２０００−０６）のセクション５及び３ＧＰＰ＿ＴＳ２３．０６０ｖ４．０．０（２００１−０３）のセクション５．６．１．１を参照されたい。当技術分野で知られているように、移動装置１００及びＰ−ＣＳＣＦ１０２のソフトウェア構成には、通常、マイクロプロセッサ上で走る７層の階層が含まれる。この階層には、上層から下層に向かって、アプリケーション層１１０、１２４；テキストベースプロトコル（ＴＢＰ）層１１２、１２６；ユーザデータグラムプロトコル（ＵＤＰ）層１１６、１３０；トランスミッション・コントロール・プロトコル（ＴＣＰ）層１１８、１３２；ＩＰ層１２０、１３４；及び物理層１２２、１３６が含まれる。ＵＤＰ、ＩＰ、及びＴＣＰ層は、一般的に、下位トランスポート層と呼ばれる。ＯＳＩ参照モデル（７レイヤモデル）については、アンドリュ・Ｓ・タネンバウム（Ａｎｄｒｅｗ＿Ｓ＿Ｔａｎｎｅｎｂａｕｍ）による“コンピュータネットワーク”（第２版）１５−２０頁に詳細に説明してある。本発明は、新たなＴＣＣＢ層１１４、１２８を導入する。好適な実施形態において、ＴＣＣＢ層１１４、１２８は、ＴＢＰ層１１２、１２６と下位トランスポート層との間に位置する。ＴＣＣＢ層１１４、１２８は、圧縮されたメッセージを用いて、移動装置１００とＰ−ＣＳＣＦ１０２が通信可能なように構成されている。移動装置１００において、ＴＣＣＢ層１１４は、移動装置キャッシュ（ＭＤＣ）１１５を含む。Ｐ−ＣＳＣＦ１０２において、ＴＣＣＢ層１２８は、コアネットワークキャッシュ（ＣＮＣ）１２７を含む。本発明によるＴＣＣＢ法を参照して後述するように、移動装置１００とＰ−ＣＳＣＦ１０２との間で送信されるメッセージを圧縮したり解凍したりするために用いられる情報テーブルが、ＭＤＣ１１５とＣＮＣ１２７を用いて記憶される。本発明によるＴＣＣＢ法は、任意の市販のマイクロプロセッサを用いて実現できる。
【０００９】
移動装置１００及びＰ−ＣＳＣＦ１０２双方におけるＴＣＣＢ層１１４、１２８には、本発明による圧縮方法と解凍方法とが含まれる。移動装置１００又はＰ−ＣＳＣＦ１０２の何れかがメッセージ送信の準備が整った場合、ＴＣＣＢ圧縮法が、呼び出され、メッセージに含まれる冗長なヘッダ情報が全て除去される。冗長なヘッダ情報は、受信装置のＭＤＣ１１５又はＣＮＣ１２７に既に記憶された送信装置から発せられる情報である。このことが起こり得るのは、例えば、ヘッダのコンテンツが、特定のセッションの間、以前送信されたメッセージから変化しなかった時である。ＴＣＣＢ圧縮法が、ヘッダのコンテンツは、特定のシーケンスの間、以前送信又は受信されたものと同じであると検出した場合、ＴＣＣＢ法は、ヘッダコンテンツを空白にする。受信装置において、ヘッダコンテンツが空白状態であるメッセージをＴＣＣＢ層が受信した場合、ＴＣＣＢ解凍方法が呼び出され、そのキャッシュからヘッダを再構成する。圧縮方法と解凍方法の詳細については、図２及び３のフローチャートを参照して後述する。
【００１０】
図２は、本発明によるＴＣＣＢ圧縮法の好適な実施形態を示すフロー図である。ステップ２０２において、本方法は、送信されるメッセージの特性（例：タイプ）を判断する。メッセージのタイプの場合、本方法は、メッセージのどのヘッダ（群）が、キャッシュ１１５又は１２７を指す正しいインデックス情報を含むか判断する（ステップ２０４）。例えば、移動装置１００が、メッセージを送信中であれば、キャッシュ１１５を指す正しいインデックス情報は、ステップ２０４で判断される。ステップ２０６において、本方法は、変数“ｉ”を初期化する。この変数は、動作が継続しているメッセージの特定のヘッダを追跡するために用いられる。ステップ２０７において、本方法は、ヘッダ（ｉ）にコンテンツがあるかどうか判断する。ヘッダにコンテンツがある場合、ステップ２０７において、本方法は、ＭＤＣ１１５又はＣＮＣ１２７を指すインデックス情報を用いて、テーブルからヘッダ（ｉ）のコンテンツを抽出する。ステップ２１０において、本方法は、テーブルからの情報がメッセージ中のヘッダ（ｉ）のコンテンツと合致するかどうか判断する。情報が合致しない場合、本方法は、ステップ２１４において、メッセージからのヘッダ（ｉ）のコンテンツをテーブルに記憶する。ステップ２１６において、本方法は、次のヘッダを指すように“ｉ”をインクリメントして処理する。ステップ２１８において、本方法は、メッセージの全てのヘッダが処理されたかどうか判断する。全てのヘッダが処理されていた場合、本方法は、下位トランスポート層１１６、１１８、１２０、１３０、１３２、１３４（図１）の１つにメッセージを転送して、送信する（ステップ２２０）。全てのヘッダが処理されていなかった場合、本方法は、ステップ２０８に戻り、残りのヘッダの処理を継続する。
【００１１】
再度ステップ２０７において、ヘッダ（ｉ）にコンテンツが無い場合、本方法は、ステップ２１６に進み、“ｉ”をインクリメントして、残りのあらゆるヘッダの処理を継続する。再度ステップ２１０において、テーブルからの情報がメッセージのヘッダ（ｉ）のコンテンツに合致する場合、ステップ２１２において、本方法は、ヘッダ（ｉ）がメッセージのタイプであるか、又は、ヘッダ（ｉ）がキャッシュを指すインデックス情報を含むか、判断する。ヘッダ（ｉ）が、メッセージのタイプでなく、また、インデックス情報を含まない場合、本方法は、ヘッダ（ｉ）のコンテンツを空白にする（ステップ２２２）。次に、本方法は、“ｉ”をインクリメントして（ステップ２１６）進み、残りのあらゆるヘッダの処理を継続する。ステップ２１２において、本方法が、ヘッダ（ｉ）は、メッセージのタイプである、又は、キャッシュを指すインデックス情報を含むと判断した場合、本方法は、ステップ２２２を飛び越し、ステップ２１６で“ｉ”をインクリメントして、残りのあらゆるヘッダの処理を継続する。好適な実施形態において、メッセージのタイプを表すヘッダ（要求行）やインデックス情報を含むヘッダは、空白にすることはできない。
【００１２】
図３は、本発明によるＴＣＣＢ解凍法の好適な実施形態を示すフロー図である。ステップ３０２において、本方法は、受信されたメッセージの特性（例：タイプ）を判断する。判断された特性に対して、本方法は、メッセージのどのヘッダ（群）が、キャッシュ１１５又は１２７を指す正しいインデックス情報を含むか判断する（ステップ３０４）。例えば、Ｐ−ＣＳＣＦ１０２が、メッセージを受信中であれば、キャッシュ１２７を指す正しいインデックス情報は、ステップ３０４で判断される。ステップ３０６において、本方法は、変数“ｉ”を１に初期化する。ステップ３０７において、本方法は、ヘッダ（ｉ）が、メッセージネーム及びプロトコルを含むかどうか判断する。この答えが“いいえ”である場合、ステップ３０８において、本方法は、ヘッダ（ｉ）のコンテンツが空白状態であるかどうか判断する。コンテンツが空白状態でない場合、本方法は、ＭＤＣ１１５又はＣＮＣ１２７を指すインデックス情報を用いて、受信メッセージ中のヘッダ（ｉ）のコンテンツをヘッダ（ｉ）に対応するテーブルに記憶する（ステップ３１２）。ステップ３１４において、本方法は、“ｉ”をインクリメントする。ステップ３１６において、本方法は、メッセージの全てのヘッダが処理されたかどうか判断する。全てのヘッダが処理されていた場合、ステップ３１８において、本方法は、ＴＢＰ層１１２、１２６（図１）にメッセージを転送して、処理する。全てのヘッダが処理されていなかった場合、本方法は、ステップ３０８に戻り、残りのヘッダの処理を継続する。
【００１３】
再度ステップ３０７において、答えが“はい”である場合、本方法は、ステップ３１４に進み、“ｉ”をインクリメントして、残りのあらゆるヘッダの処理を継続する。再度ステップ３０８において、メッセージ中のヘッダ（ｉ）のコンテンツが空白状態である場合、本方法は、インデックス情報を用いてヘッダ（ｉ）に対応するキャッシュテーブルにアクセスして、テーブルから情報を抽出しメッセージ中のヘッダ（ｉ）のコンテンツを埋める（ステップ３１０）。次に、本方法は、ステップ３１４で“ｉ”をインクリメントして、残りのあらゆるヘッダの処理を継続する。
【００１４】
ＴＣＣＢ圧縮及び解凍法がどのように動作するか例示するために、移動装置１００のＰ−ＣＳＣＦ１０２への登録例について説明する。この例の特徴は、ＳＩＰメッセージが、移動装置１００とＰ−ＣＳＣＦ１０２との間で交換されることである。しかしながら、任意のテキストベースメッセージを、本発明に用いることができる。第１の例は、移動装置１００起動後における初めての登録である。プロセスを開始するために、ＲＥＧＩＳＴＥＲ要求が、ＭＤ１００（図１）のアプリケーション層１１０からＴＣＣＢ層１１４送信される。本例では、メッセージには、以下のフィールド（ヘッダ）がある。
【００１５】

このメッセージには、８つのヘッダ、即ち、ＲＥＧＩＳＴＥＲ、Ｖｉａ、Ｆｒｏｍ、Ｔｏ、Ｃａｌｌ−ＩＤ、Ｃｓｅｑ、Ｃｏｎｔａｃｔ、及びＥｘｐｉｒｅｓが含まれる。各ヘッダのコンテンツは、コロンの後に示す情報であるが、第１行（要求行）は例外であり、ここでは、コンテンツがメッセージネームの後の全てである。例えば、“ＲＥＧＩＳＴＥＲ”ヘッダのコンテンツは、“ｓｉｐ：ｂｅｌｌ−ｔｅｌ．ｃｏｍＳＩＰ／２．０”である。“Ｖｉａ”ヘッダのコンテンツは、“ＳＩＰ／２．０／ＵＤＰｓａｔｕｒｎ．ｂｅｌｌ−ｔｅｌ．ｃｏｍ”である。
【００１６】
ＴＣＣＢ層１１４、１２８は、圧縮方法を呼び出して、（可能ならば）メッセージを圧縮した後、トランスポート層１１６、１１８、１２０、１３０、１３２、１３４にそれを送り、送信する。図２の圧縮アルゴリズムにおいて、本方法は、ステップ２０２で、メッセージが“ＲＥＧＩＳＴＥＲ”メッセージであると判断する。この判断は、メッセージの要求行（第１行）を見ることによって行なわれる。ステップ２０４において、本方法は、どのヘッダが、要求行に対応するＭＤＣ１１５のテーブルを指す正しいインデックス情報を含むか判断する。好適な実施形態において、“Ｔｏ”ヘッダは、“ＲＥＧＩＳＴＥＲ”メッセージ用のインデックス情報を含む。他の実施形態において、異なるヘッダ又は異なる組み合わせのヘッダが、このインデックス情報を含み得る。ステップ２０６において、本方法は、ＲＥＧＩＳＴＥＲメッセージの第１ヘッダ（ヘッダ（１））を指すように、変数“ｉ”を１に初期化する。ステップ２０７において、本方法は、ＲＥＧＩＳＴＥＲメッセージにコンテンツがあると判断し、ステップ２０８において、“Ｔｏ”ヘッダのコンテンツを、ＭＤＣ１１５の要求行テーブルを指すインデックス情報として用いる。本例において、“ｓｉｐ：ｗａｔｓｏｎ＠ｂｅｌｌ−ｔｅｌ．ｃｏｍ”は、正しいインデックス情報である。ステップ２１０において、本方法は、要求行テーブルのコンテンツが、本例では“ｓｉｐ：ｂｅｌｌ−ｔｅｌ．ｃｏｍＳＩＰ／２．０”であるヘッダ（１）のコンテンツと合致するかどうか判断する。これは、送信される最初のメッセージであることから、このメッセージは、ＭＤＣ１１５にまだ記憶されていない。ステップ２１４において、本方法は、“ｓｉｐ：ｂｅｌｌ−ｔｅｌ．ｃｏｍＳＩＰ／２．０”をＭＤＣ１１５の要求行テーブルに記憶する。
【００１７】
ステップ２１６において、本方法は、“Ｖｉａ”ヘッダ（ヘッダ（２））を指すように“ｉ”をインクリメントして、処理する。ステップ２１８において、本方法は、処理すべきヘッダが更に存在すると判断して、ステップ２０７に戻る。本方法は、全てのヘッダが処理されるまで、ステップ２０７、２０８、２１０、２１４、２１６、及び２１８を繰り返す。本方法は、“Ｔｏ”ヘッダコンテンツをインデックス情報として用いて、そのＭＤＣ１１５中の対応するテーブルとメッセージの各ヘッダのコンテンツとを突き合わせてチェックする。これは、送信される最初のメッセージであることから、ヘッダコンテンツは何れもＭＤＣ１１５に未だ記憶されておらず、また、ヘッダコンテンツは何れも空白にされない。最後のヘッダが処理された時、このメッセージは、（上述したように）圧縮されていない状態で、下位トランスポート層１１４、１１８、１２０の内の１つに送られ、無線インターフェイス１０６を介して、ＲＡＮ１０４に送信される。メッセージは、図４に示すようにＭＤＣ１１５に記憶される。ＲＡＮ１０４は、ＩＰインターフェイス１０８を介して、Ｐ−ＣＳＣＦ１０２にメッセージを転送する。
【００１８】
メッセージを受信すると、Ｐ−ＣＳＣＦ１０２は、本発明による解凍方法を呼び出す。図３において、ステップ３０２で、本方法は、ＲＥＧＩＳＴＥＲメッセージを受信したと判断する。ステップ３０４において、本方法は、ＲＥＧＩＳＴＥＲメッセージの場合、“Ｔｏ”ヘッダがＣＮＣ１２７（図１）を指すインデックス情報を含んでいると判断する。ステップ３０６において、本方法は、受信メッセージの第１ヘッダを指すように“ｉ”を１に初期化する。ステップ３０７において、本方法は、ヘッダ（１）がメッセージネーム及びプロトコルを含まないと判断して、ステップ３０８において、ヘッダ（１）のコンテンツが空白状態でないと判断する。ステップ３１２において、本方法は、インデックス情報を用いて、ヘッダ（１）のコンテンツ“ｓｉｐ：ｂｅｌｌ−ｔｅｌ．ｃｏｍＳＩＰ／２．０”で要求行テーブルを更新する。ステップ３１４において、本方法は、ヘッダ（２）を指すように、“ｉ”をインクリメントする。ステップ３１６において、本方法は、処理すべきヘッダが更に存在すると判断して、全てのヘッダが処理されるまで、ステップ３０７、３０８、３１２、３１４、及び３１６を繰り返す。全てのヘッダが処理されると、メッセージは、ＴＢＰ層１２６に転送され、処理される（ステップ３１８）。ＣＮＣ１２７は、図５に示す値を含む。
【００１９】
本例において、Ｐ−ＣＳＣＦ１０２は、“ＲＥＧＩＳＴＥＲ”メッセージに“２００ＯＫ”メッセージで応答する。２００ＯＫメッセージは、以下の通りである。

２００ＯＫメッセージにはコンテンツが無いことに留意されたい。２００ＯＫメッセージのヘッダは、“ＳＩＰ／２．０２００ＯＫ”である。Ｐ−ＣＳＣＦ１０２は、圧縮方法を呼び出して、ヘッダコンテンツ全てを空白にした後、移動装置１００に送信し得るか判断する。図２において、本方法は、このメッセージが２００ＯＫメッセージであると判断する（ステップ２０２）。ステップ２０４において、本方法は、“Ｔｏ”ヘッダが、２００ＯＫメッセージ用のインデックス情報を含むと判断する。（他の実施形態において、他のヘッダ又は他の組み合わせのヘッダが、このインデックス情報を含み得る。）ステップ２０６において、本方法は、要求行ヘッダ（ヘッダ（１））を指すように、変数“ｉ”を１に初期化する。ステップ２０７において、本方法は、ヘッダ（１）には、コンテンツが無いと判断して、ステップ２１６に進み、“ｉ”をインクリメントする。ステップ２１８において、本方法は、処理すべきヘッダが更に存在すると判断して、ステップ２０７に進む。ステップ２０７において、本方法は、ヘッダ（２）、つまり、“Ｖｉａ”ヘッダにコンテンツがあると判断する。ステップ２０８において、本方法は、“ｓｉｐ：ｗａｔｓｏｎ＠ｂｅｌｌ−ｔｅｌ．ｃｏｍ”を、ＣＮＣ１２７のＶｉａテーブルを指すインデックス情報として用いる。図５に示すように、Ｖｉａテーブルのコンテンツは、“ＳＩＰ／２．０／ＵＤＰｓａｔｕｒｎ．ｂｅｌｌ−ｔｅｌ．ｃｏｍ”である。従って、ステップ２１０において、本方法は、ＣＮＣ１２７のＶｉａテーブルのコンテンツは、メッセージのＶｉａヘッダ（ヘッダ（２））のコンテンツと合致すると判断する。ステップ２１２において、本方法は、ヘッダ（２）が、メッセージのタイプではなく、また、インデックス情報を含まないと判断して、Ｖｉａヘッダのコンテンツを空白にする（ステップ２２２）。次に、本方法は、ステップ２１６に進み“ｉ”をインクリメントする。
【００２０】
ステップ２１８において、本方法は、処理すべきヘッダが更に存在すると判断して、ステップ２０７に進む。ステップ２０７において、本方法は、ヘッダ（３）にコンテンツがあると判断し、ステップ２０８において、“ｓｉｐ：ｗａｔｓｏｎ＠ｂｅｌｌ−ｔｅｌ．ｃｏｍ”を、ＣＮＣ１２７の“Ｆｒｏｍ”テーブルを指すインデックス情報として用いる。図５に示すように、Ｆｒｏｍテーブルのコンテンツは、“＜ｓｉｐ：ｗａｔｓｏｎ＠ｂｅｌｌ−ｔｅｌ．ｃｏｍ＞；ｔａｇ＝１９ａ１”であり、これは、２００ＯＫメッセージ中のＦｒｏｍヘッダのコンテンツと合致する。ステップ２１０において、本方法は、合致したと判断して、ステップ２１２において、Ｆｒｏｍヘッダがメッセージのタイプを示すかどうか、又は、インデックス情報を含むかどうか判断する。この両方の質問に対する答えは“いいえ”であるため、本方法は、Ｆｒｏｍヘッダのコンテンツを空白にして（ステップ２２２）、ステップ２１６で“ｉ”をインクリメントして“Ｃａｌｌ−ＩＤ”ヘッダ（ヘッダ（４））を処理する。
【００２１】
残りのヘッダが処理された後、圧縮された２００ＯＫメッセージは、以下のようになる。即ち、
ＳＩＰ／２．０２００ＯＫ
Ｖｉａ：
Ｆｒｏｍ：
Ｔｏ：ｓｉｐ：ｗａｔｓｏｎ＠ｂｅｌｌ−ｔｅｌ．ｃｏｍ
Ｃａｌｌ−ＩＤ：
Ｃｓｅｑ：
Ｃｏｎｔａｃｔ：
圧縮されたメッセージは、下位トランスポート層１３０、１３２、１３４の内の１つに送られ、移動装置１００に送信される。
【００２２】
移動装置１００のＴＣＣＢ層１１４において、圧縮された２００ＯＫメッセージが受信されると、解凍方法が呼び出される。図３において、本方法は、“２００ＯＫ”メッセージが受信されたと判断する（ステップ３０２）。ステップ３０４において、本方法は、“Ｔｏ”ヘッダのコンテンツは、ＭＤＣ１１５を指すインデックス情報を含むと判断する。ステップ３０６において、変数“ｉ”を１に初期化する。ステップ３０７において、本方法は、ヘッダ（１）がメッセージネーム（２００ＯＫ）及びプロトコル（ＳＩＰ）を含むと判断し、ステップ３１４において、“ｉ”をインクリメントする。ステップ３１６において、本方法は、処理すべきヘッダが更に存在すると判断して、ステップ３０７に進む。ステップ３０７において、本方法は、ヘッダ（２）にメッセージネーム及びプロトコルが含まれないと判断する。ステップ３０８において、本方法は、ヘッダ（２）のコンテンツは、空白状態であると判断して、“ｓｉｐ：ｗａｔｓｏｎ＠ｂｅｌｌ−ｔｅｌ．ｃｏｍ”を用いて、“Ｖｉａ”テーブル（ＳＩＰ／２．０／ＵＤＰｓａｔｕｒｎ．ｂｅｌｌ−ｔｅｌ．ｃｏｍ）から情報を抽出し、メッセージの“Ｖｉａ”ヘッダのコンテンツを埋める。ステップ３１４において、本方法は、ヘッダ（３）を指すように“ｉ”をインクリメントする。ステップ３１６において、本方法は、処理すべきヘッダが更に存在すると判断して、ステップ３０８に進む。本方法は、メッセージ中の全てのヘッダが、ＭＤＣテーブルの情報で埋められるまで、ステップ３０７、３０８、３１０、３１４、及び３１６を繰り返す。ステップ３１８において、解凍されたメッセージが、ＴＢＰ層１１２に転送され、処理される。
【００２３】
本発明による圧縮及び解凍方法は、ＭＤＣ１１５及びＣＮＣ１２７を指す多重レベル索引付けを用いても実現し得る。一例として、“ＩＮＶＩＴＥ”メッセージが移動装置１００からＰ−ＣＳＣＦ１０２に送信される前に、移動装置１００のＰ−ＣＳＣＦ１０２への登録が成功した場合を考える。ＩＮＶＩＴＥメッセージの場合、圧縮及び解凍方法は、必要な場合、“Ｆｒｏｍ“ヘッダコンテンツと“Ｔｏ”ヘッダコンテンツの両方をＭＤＣ１１５及びＣＮＣ１２７を指すインデックス情報として用いる。“Ｆｒｏｍ“コンテンツは、第１レベルの索引付けを提供し、要求に応じて、“Ｔｏ”は、それ以上のレベルの細分性を提供する。ＳＤＰ情報が除去されたＩＮＶＩＴＥメッセージの例を次に示す。
【００２４】

ＴＣＣＢ層１１４は、ＩＮＶＩＴＥメッセージを受信すると、圧縮アルゴリズムを呼び出す。図２において、本方法は、メッセージがＩＮＶＩＴＥメッセージであると判断する（ステップ２０２）。ステップ２０４において、本方法は、 “Ｆｒｏｍ”ヘッダ及び（必要に応じて）“Ｔｏ”ヘッダがＩＮＶＩＴＥメッセージ用のインデックス情報を含むと判断する。ステップ２０６において、本方法は、要求行ヘッダ（ヘッダ（１））を指すように、変数“ｉ”を１に初期化する。ステップ２０７において、本方法は、ヘッダ（１）にコンテンツがあると判断し、ステップ２０８において、“Ｆｒｏｍ”ヘッダコンテンツ（ｓｉｐ：Ｗａｔｓｏｎ＠ｂｅｌｌ−ｔｅｌ．ｃｏｍ）を、ＭＤＣ１１５の要求行テーブルを指すインデックス情報として用いる。ステップ２１０において、本方法は、テーブルコンテンツ（図４参照）が、メッセージのＩＮＶＩＴＥヘッダのコンテンツと合致しないと判断する。コンテンツが合致しないため、本方法は、Ｔｏヘッダコンテンツ（＜ｓｉｐ：ｓｉｍｐｓｏｎ＠ｂｅｌｌ−ｔｅｌ．ｃｏｍ＞）を用いて、ＭＤＣ１１５の要求行テーブルにアクセスする。＜ｓｉｐ：ｓｉｍｐｓｏｎ＠ｂｅｌｌ−ｔｅｌ．ｃｏｍ＞が、Ｉｎｖｉｔｅテーブルを指すインデックス情報として以前用いられていないため、そのインデックスが指すＩｎｖｉｔｅテーブルは、ヘッダのＩＮＶＩＴＥメッセージのコンテンツとは合致しない。ステップ２１４において、本方法は、ＩＮＶＩＴＥメッセージのコンテンツを要求行テーブルに記憶する。ステップ２１６において、本方法は、“ｉ”をインクリメントし、ステップ２１８において、処理すべきヘッダが更に存在すると判断する。
【００２５】
ステップ２０７において、本方法は、ヘッダ（２）にコンテンツがあると判断する。ステップ２０８において、本方法は、ＭＤＣ１１５のＶｉａテーブルを指すインデックス情報として、Ｆｒｏｍヘッダのコンテンツを用いる。図４に示すように、Ｖｉａテーブルのコンテンツは、“ＳＩＰ／２．０／ＵＤＰｓａｔｕｒｎ．ｂｅｌｌ−ｔｅｌ．ｃｏｍ”である。従って、ステップ２１０において、本方法は、ＭＤＣ１１５のＶｉａテーブルのコンテンツは、メッセージのＶｉａヘッダ（ヘッダ（２））のコンテンツと合致すると判断する。合致したことから、Ｖｉａテーブルを指す第２レベルの索引付け（Ｔｏヘッダ）を用いる必要はない。ステップ２１２において、本方法は、ヘッダ（２）が、メッセージのタイプではなく、また、インデックス情報を含まないと判断して、Ｖｉａヘッダのコンテンツを空白にする（ステップ２２２）。次に、本方法は、ステップ２１６に進み“ｉ”をインクリメントする。ステップ２１８において、本方法は、処理すべきヘッダが更に存在すると判断して、ステップ２０７に進む。本方法は、全てのヘッダが処理されるまで、ステップ２０７、２０８、２１０、２１４、２１６、及び２１８を繰り返す。本方法は、まず“Ｆｒｏｍ“ヘッダコンテンツをインデックスとして用いて、ＭＤＣ１１５中の対応するテーブルとメッセージの各ヘッダのコンテンツとを突き合わせてチェックする。また、合致しなかった場合、“Ｔｏ”ヘッダコンテンツを用いて、テーブルに再度アクセスする。二回目も合致しなかった場合、メッセージのヘッダのコンテンツは、Ｔｏヘッダ情報に対応するインデックスが指すテーブルに記憶される。メッセージヘッダが、新しいヘッダ（即ち、本例において、Ｓｕｂｊｅｃｔ及びＣｏｎｔｅｎｔ―ｔｙｐｅのヘッダ等、以前メッセージにまだ用いられていないヘッダ）である場合、メッセージのヘッダのコンテンツは、ＭＤＣテーブルに二回記憶されるが、一回目は、Ｆｒｏｍヘッダインデックス情報に対応する位置に、また、二回目は、Ｔｏヘッダインデックス情報に対応する位置に記憶される。各ヘッダが処理された後、ＭＤＣテーブルは、図６に示す情報を含む。
【００２６】
本例において、メッセージのヘッダコンテンツをＭＤＣテーブルのヘッダコンテンツと比較して分かった合致は、“Ｖｉａ”ヘッダのみである。（図４と６を比較。）ＭＤＣ１１５は、他の全てのフィールドに対して更新されており、“Ｆｒｏｍ“ヘッダコンテンツと“Ｔｏ”ヘッダコンテンツとの組み合わせが、インデックス情報に用いられている。以下の圧縮されたＩＮＶＩＴＥメッセージが、Ｐ−ＣＳＣＦ１０２に送信される。
【００２７】

圧縮されたＩＮＶＩＴＥメッセージを受信すると、Ｐ−ＣＳＣＦ１０２のＴＣＣＢ層１２８は、解凍方法を呼び出す。メッセージがＩＮＶＩＴＥメッセージであると判断すると、本方法は、“Ｆｒｏｍ” 及び“Ｔｏ”ヘッダを用いて、ＣＮＣ１２７にアクセスする。本例において、本方法は、メッセージのＶｉａヘッダのコンテンツをＣＮＣ１２７のＶｉａテーブルの情報で埋める。メッセージ中の他のヘッダに関しては、ＣＮＣ１２７のテーブルが、現在の情報で更新される。
【００２８】
当業者は、本発明による装置及び方法並びに本装置の構成において、本発明の範囲と精神から逸脱することなく、様々な変形や変更を成し得ると認識されるであろう。例えば、エラーチェック及び処理を本方法に組み込むことが可能である。この方法は、圧縮の前に、各メッセージにチェックサムを実施して、その結果をメッセージと共に受信装置の解凍装置に送信できる。メッセージを解凍する際、再構成されたメッセージにチェックサムを実施でき、また、その結果を元の値と比較できる。エラーが検出された場合、エラー処理機能を用いて、アプリケーション層１１０、１２４に通知し得る。
【００２９】
更に、本明細書に述べたテキスト形式よりもむしろ、ビット状のタグをメッセージヘッダに用いてもよい。例えば、ＳＩＰに適用した場合、両ノード（移動装置１００及びＰ−ＣＳＣＦ１０２）のＴＣＣＢ層は、以下のマッピングで初期化し得る。
【００３０】
Ｖｉａ：０ｘ０００１５８
Ｆｒｏｍ：０ｘ０００２５８
Ｔｏ：０ｘ０００３５８
ＣＡＬＬ−ＩＤ：０ｘ０００４５８
Ｃｓｅｑ：０ｘ０００５５８
Ｃｏｎｔａｃｔ−ｌｅｎｇｔｈ：０ｘ０００６５８
圧縮されたメッセージを送信する場合、”Ｖｉａ：”は、０ｘ０００１５８で置き換えられ、また、他のものも同様に置き換えられる。他の選択肢として、ハフマン（Ｈｕｆｆｍａｎ）符号化法を、タグ形式に用いることが可能である。
【００３１】
ＩＮＶＩＴＥメッセージの例で分かるように、多重レベルの索引付けを用いて、情報をキャッシュメモリに記憶したり、検索したりできる。メッセージからの新しい情報を用いて、必要な場合、それ以上のレベルの細分性を提供し得る。実現される索引付けレベルの数は、プロトコルの特性に依存する最適な圧縮比に左右される。例えば、本方法の効率を改善するために、三レベルの索引付けを用いると、更なる圧縮を行なうことができる。
【００３２】
（例：Ｆｒｏｍ：コンテンツ
＋Ｔｏ：コンテンツ
＋Ｃｓｅｑ：コンテンツ）
更なる圧縮は、強制ヘッダ方式が組み込まれたシステムで実現し得る。強制ヘッダ方式は、各メッセージが、或るヘッダを含まねばならない方式である。このようなシステムにおいて、更なる圧縮は、ヘッダコンテンツが空白になっている場合、圧縮されたメッセージにヘッダタイトルを含まないことによって実現し得る。
【図面の簡単な説明】
【００３３】
【図１】本発明によるＴＣＣＢ装置及び方法を実現するために用い得る構成を示すブロック図。
【図２】本発明によるＴＣＣＢ圧縮法の好適な実施形態を示すフロー図。
【図３】本発明によるＴＣＣＢ解凍法の好適な実施形態を示すフロー図。
【図４】登録メッセージを初めて送信した後の移動装置キャッシュの或る瞬間を捉えた図。
【図５】登録メッセージが、ＴＣＣＢ層によって初めて処理された後のコアネットワークキャッシュのある瞬間を捉えた図。
【図６】”ＩＮＶＩＴＥ”メッセージが、ＴＣＣＢ層によって初めて処理された後の移動装置キャッシュのある瞬間を捉えた図。

Claims

メモリを有する送信装置において、複数のヘッダを有するメッセージを圧縮するための方法であって、
前記メッセージの特性を判断する段階と、
前記メッセージの前記特性に基づき、前記メッセージのどの部分が前記第１メモリを指すインデックス情報を含むか判断する段階と、
前記メッセージ中の前記複数の各ヘッダに対して、前記メモリを指す前記インデックス情報を用いて、前記ヘッダのコンテンツが前記メモリに記憶されているかどうか判断する段階と、
前記ヘッダのコンテンツが前記メモリに記憶されている場合、前記メッセージ中の前記ヘッダの前記コンテンツを空白にする段階と、が含まれる方法。
請求項１に記載の方法であって、更に、
前記ヘッダの前記コンテンツがメモリに記憶されていない場合、前記ヘッダの前記コンテンツをメモリに記憶する段階が含まれる方法。
請求項２に記載の方法であって、
前記インデックス情報は、前記メッセージの少なくとも１つの所定のヘッダのコンテンツに対応する方法。
請求項１に記載の方法であって、
前記ヘッダがメッセージタイプを示すか又は前記インデックス情報を含む場合、前記メッセージ中の前記ヘッダの前記コンテンツは、空白にされない方法。
メモリを有する受信装置において、複数のヘッダを有するメッセージを解凍するための方法であって、
前記メッセージの特性を判断する段階と、
前記メッセージの前記特性に基づき、前記メッセージのどの部分が前記メモリを指すインデックス情報を含むか判断する段階と、
前記メッセージ中の前記複数の各ヘッダに対して、前記ヘッダのコンテンツが空白状態であるかどうか判断する段階と、
前記ヘッダの前記コンテンツが空白状態である場合、前記メモリを指す前記インデックス情報を用いて情報を検索し、前記ヘッダの前記コンテンツを埋める段階と、が含まれる方法。
請求項５に記載の方法であって、更に、
前記ヘッダの前記コンテンツが空白状態でない場合、前記メモリを指す前記インデックス情報を用いて、前記ヘッダの前記コンテンツを前記メモリ中の適切な位置に記憶する段階が含まれる方法。
請求項５に記載の方法であって、
前記インデックス情報は、前記メッセージの少なくとも１つの所定のヘッダのコンテンツに対応する方法。
無線インターフェイスを介して送信する前にテキストメッセージを圧縮するための装置において、アプリケーション層、テキストベースプロトコル層、及び物理層を含むソフトウェア構成を有する前記装置であって、更に、
前記メッセージの特性を判断し、
前記メッセージの前記特性に基づき、前記メッセージのどの部分が前記第１メモリを指すインデックス情報を含むか判断し、
前記メッセージ中の複数の各ヘッダに対して、前記メモリを指す前記インデックス情報を用いて、前記ヘッダのコンテンツが前記メモリに記憶されているかどうか判断し、
前記ヘッダのコンテンツが前記メモリに記憶されている場合、前記メッセージ中の前記ヘッダの前記コンテンツを空白にする、ためのテキストベース圧縮／解凍層が含まれる装置。
テキストメッセージを解凍するための装置において、アプリケーション層、テキストベースプロトコル層、及び物理層を含むソフトウェア構成を有する前記装置であって、更に、
前記メッセージの特性を判断し、
前記メッセージの前記特性に基づき、前記メッセージのどの部分が前記メモリを指すインデックス情報を含むか判断し、
前記メッセージ中の複数の各ヘッダに対して、前記ヘッダのコンテンツが空白状態であるかどうか判断し、
前記ヘッダの前記コンテンツが空白状態である場合、前記メモリを指す前記インデックス情報を用いて情報を検索し、前記ヘッダの前記コンテンツを埋める、ためのテキストベース圧縮／解凍層が含まれる装置。