JP2008541643A - シグナリングの圧縮／解凍 - Google Patents

シグナリングの圧縮／解凍 Download PDF

Info

Publication number
JP2008541643A
JP2008541643A JP2008511808A JP2008511808A JP2008541643A JP 2008541643 A JP2008541643 A JP 2008541643A JP 2008511808 A JP2008511808 A JP 2008511808A JP 2008511808 A JP2008511808 A JP 2008511808A JP 2008541643 A JP2008541643 A JP 2008541643A
Authority
JP
Japan
Prior art keywords
parameter information
compression
parameter
message
decompression
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
JP2008511808A
Other languages
English (en)
Other versions
JP2008541643A5 (ja
Inventor
ジーガン リウ
サミ ユティラ
イルッカ ペソネン
Original Assignee
スパイダー ナビゲイションズ エルエルシー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by スパイダー ナビゲイションズ エルエルシー filed Critical スパイダー ナビゲイションズ エルエルシー
Publication of JP2008541643A publication Critical patent/JP2008541643A/ja
Publication of JP2008541643A5 publication Critical patent/JP2008541643A5/ja
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本発明は、パケットデータネットワーク内でシグナリングメッセージを圧縮又は解凍する方法であって、パケットデータネットワークのプロトコルメッセージのヘッダ部分にパラメータ情報を与えることを含む方法に係る。パラメータ情報は、圧縮又は解凍メカニズムの少なくとも１つの処理詳細を指定し、そしてプロトコルメッセージと一緒に、パケットデータネットワークを通してパケットデータネットワークの圧縮又は解凍ファンクションへ転送される。圧縮又は解凍ファンクションにおける圧縮又は解凍メカニズムは、次いで、パラメータ情報に基づいてセットされる。従って、パラメータ情報が直接得られるので、第１又は第１の若干のメッセージの良好な圧縮を達成することができる。
【選択図】図２

Description

本発明は、パケットデータネットワークにおいてシグナリングメッセージを圧縮し又は解凍する方法及び装置に係る。
マルチメディア通信に使用されるＳＩＰ（セッションイニシエーションプロトコル）又はＲＴＳＰ（リアルタイムストリーミングプロトコル）のような多数のアプリケーションプロトコルは、テキストベースのもので、広い帯域巾を有するリンクに対して計画されたものである。従って、それらのメッセージは、サイズに関して最適化されていない。例えば、典型的なＳＩＰメッセージは、数百バイトのものから、２千バイト以上のものまである。ＳＩＰは、ＲＦＣ（コメントのための要求）３２６１においてＩＥＴＦ（インターネットエンジニアリングタスクフォース）により定義され、そして（とりわけ）端−端マルチメディアセッションを確立し、ハンドリングし、リリースするのに使用されるアプリケーション−レイヤプロトコルである。セルラーネットワークの一部分としてワイヤレスハンドセットにおいてこれらプロトコルを計画的に使用する状態では、大きなメッセージサイズが問題となる。低レートＩＰ（インターネットプロトコル）接続では、送信遅延が著しいものとなる。再送信や多数のメッセージがある流れにおいて要求されることを考慮すれば、少なくともコール設定及び特徴呼び出しが悪影響を受ける。
この問題を排除するために、アプリケーションメッセージを健全にロスなし圧縮するものとしてシグナリング圧縮（ＳｉｇＣｏｍｐ）アーキテクチャーが定義されている。ＯＳＩ（オープンシステム相互接続）モデルに関して、ＳｉｇＣｏｍｐアーキテクチャーは、トランスポートレイヤに対する向上として解釈することができる。従って、ＳｉｇＣｏｍｐは、メッセージの送信及び圧縮の両方に対して上位レイヤアプリケーションを与える。ＳｉｇＣｏｍｐは、ＩＥＴＦで標準化されたプロトコルで、アプリケーション−レイヤプロトコルメッセージを圧縮することができる。より詳細には、これは、セッション（コール）設定や、他の多数のアプリケーション、例えば、メッセージングに使用されるＳＩＰメッセージを圧縮するために開発されたものである。ＳｉｇＣｏｍｐの主な目標は、ＳＩＰメッセージのサイズを縮小して、それらを、帯域巾に制限のあるリンク（例えば、セルラー）を経て低い待ち時間で送信できるようにすることである。ＳｉｇＣｏｍｐがないと、送信の待ち時間は、エンドユーザにとって受け容れられないほど長いコール設定時間を招く。ＳｉｇＣｏｍｐの詳細は、ＩＥＴＦにおける次のＲＦＣ、即ちＲＦＣ３３２０、ＲＦＣ３３２１、ＲＦＣ３３２２、ＲＦＣ３４８５及びＲＦＣ３４８６に定義されている。
移動通信におけるその有用性のために、第三世代パートナーシッププロジェクト（３ＧＰＰ）は、少なくともＳＩＰメッセージを圧縮するためにＳｉｇＣｏｍｐの使用を推奨している。それ故、将来の３Ｇ移動ターミナルも、ＳｉｇＣｏｍｐをサポートしなければならない。
ＳｉｇＣｏｍｐアーキテクチャーの送信側は、圧縮器ディスパッチャー、１つ以上の圧縮器、及び状態ハンドラーを備えている。圧縮器ディスパッチャーは、アプリケーションからのインターフェイスとして働く。アプリケーションは、アプリケーションメッセージ及び区画識別子（即ち、アプリケーション特有のメッセージグループに使用される識別子）を圧縮器ディスパッチャーに供給する。圧縮器ディスパッチャーは、リモートエンドポイントへ転送されるべきＳｉｇＣｏｍｐメッセージを返送する特定の圧縮器を呼び出す。状態ハンドラーは、メッセージごとにデータをアップロードする必要性を回避するためにＳｉｇＣｏｍｐメッセージ間に記憶される状態情報を記憶し検索する。
ＳｉｇＣｏｍｐアーキテクチャーの受信側は、解凍器ディスパッチャー、ユニバーサル解凍器バーチャルマシン（ＵＤＶＭ）（解凍を遂行するバーチャルマシン）、及び状態ハンドラーを備えている。解凍器ディスパッチャーは、アプリケーションに向かうインターフェイスとして働く。解凍器ディスパッチャーは、トランスポートレイヤからＳｉｇＣｏｍｐメッセージを受信し、そしてＳｉｇＣｏｍｐメッセージを解凍するＵＤＶＭのインスタンスを呼び出す。次いで、解凍器ディスパッチャーは、それにより得られる解凍されたメッセージをアプリケーションへ転送し、このアプリケーションは、メッセージに対して状態をセーブすることを許そうとする場合に区画識別子を返送することができる。解凍プロセス中に、ＵＤＶＭは、状態ハンドラーを呼び出して、既存の状態にアクセスするか、又は新たな状態を生成することができる。
ＳｉｇＣｏｍｐメッセージは、他のアプリケーションメッセージ、例えば、非圧縮のＳＩＰ及びＲＴＳＰメッセージと共に、トランスポートレイヤにおいてデータパケット流として送信される。ＳｉｇＣｏｍｐメッセージは、それ自身の５ビットデリミッターで識別され、即ち、例えば、送信制御プロトコル（ＴＣＰ）に基づくストリームベースのトランスポートの場合に、１１１１１ビットで開始しそして０ｘＦＦＦビットで終了する。しかしながら、例えば、ユーザデータグラムプロトコル（ＵＤＰ）に基づくメッセージベースのトランスポートでは終了マーキングが必要とされない。トランスポートレイヤデータストリームは、解凍器ディスパッチャーに向けられ、このディスパッチャーは、解凍に対してＳｉｇＣｏｍｐメッセージを識別し、そして非ＳｉｇＣｏｍｐメッセージを、ＳＩＰスタック又はＲＴＳＰのような特定のアプリケーションクライアントへ通すように構成されねばならない。
しかしながら、初期の要求は、圧縮されない。というのは、ＲＦＣ３４８６によれば、次のホップＵＲＩ（ユニフォームリソース識別子）がパラメータ“；ｃｏｍｐ＝ＳｉｇＣｏｍｐ”を含み、且つアウトバウンドプロキシーのＳＩＰ−ＵＲＩがそのパラメータを含まなくなるまで、圧縮が開始されないからである。プロキシーアドレスは、初期登録手順の間に送信装置によって発見され、その後は変化しない。
ＳｉｇＣｏｍｐは、エンドポイントによってサポートされるバージョン番号及びメモリ容量のような幾つかのパラメータを定義する。ＳｉｇＣｏｍｐがメッセージ送信器と受信器との間で作用するためには、それらがこれらパラメータの値について合意しなければならない。現在の解決策では、ＳｉｇＣｏｍｐ受信器が、各アプリケーションプロトコル、例えば、このケースではＳＩＰ、に対して定義されたＳｉｇＣｏｍｐパラメータの最小値をサポートしなければならない。受信器は、最小値より大きな値をオファーしてもよい。このケースでは、受信器は、ドキュメントＵＳ２００５／００８６３２７Ａ１に述べられたように、送信器へ返送されるＳｉｇＣｏｍｐフィードバックメッセージにおいてパラメータ値を通知することができる。これには、幾つかの問題がある。
第１に、ＳｉｇＣｏｍｐは、充分に高速ではない。送信器は、第１メッセージを送信するときに、受信器がＳｉｇＣｏｍｐの新たなバージョンをサポートするか又は指定の最小値より大きな容量を有するか知ることを希望する。もちろん、送信器は、受信器からのＳｉｇＣｏｍｐフィードバックを待機する。しかし、これは、第１メッセージを最適な仕方で圧縮できないことを意味する。問題を更に悪化させることとして、逆方向にメッセージが来る前に送信器が２つ以上のメッセージを送信しなければならない場合がある。これは、第１のメッセージだけでなく複数のメッセージを最適に圧縮できないことを意味する。
第２に、ＳｉｇＣｏｍｐの実施が複雑である。現在のＳｉｇＣｏｍｐアナウンスメント解決策では、後続メッセージに対して余計な容量を利用するために第１メッセージの後に「スイッチ」（例えば、ＳｉｇＣｏｍｐバージョン１からバージョン２へ又は小メモリバッファから大メモリバッファへ）するような実施を必要とする。このような「スイッチ」は、実施に対して著しい複雑さを付加する。
第３に、ＳｉｇＣｏｍｐは、ＳｉｇＣｏｍｐが一方のシグナリング方向にしか適用されない非対称的状態では機能しない。これは、上述したアナウンスメントをＳｉｇＣｏｍｐメッセージの一部分として搬送しなければならないからである。それ故、ＳｉｇＣｏｍｐが他方の方向に適用されない場合には、ＳｉｇＣｏｍｐフィードバックを送信器へ返送することができない。この点に関して、ある無線技術は、非対称的であり、例えば、アップリンクに対して帯域巾が小さく、ダウンリンクに対して帯域巾が大きいことに注意されたい。このケースでは、アップリンクを経て送信されるＳＩＰメッセージだけをＳｉｇＣｏｍｐにより圧縮すればよい。
第４に、ＳｉｇＣｏｍｐでは、圧縮が圧縮アルゴリズムを使用して行なわれる。ＲＦＣ３２２０における重要な考え方は、どんな圧縮アルゴリズムが使用されようとも、解凍が常に可能なことである。解凍は、圧縮を行なうエンドポイントによって供給されるバイトコードを実行するバーチャルマシンを使用することにより行なわれる。しかしながら、バイトコードのサイズは、数百バイトであり、従って、エアインターフェイスを経てバイトコードを送信すると、低い圧縮比を招く。圧縮セッションの寿命（ＲＦＣ３３２０における区画寿命）中には若干のメッセージ（５０未満）しか圧縮されないことがかなり頻繁に起こり、従って、ＳｉｇＣｏｍｐを使用すると、実際に、送信バイトの全量が、圧縮を行わない場合より多くなる。両エンドポイントが圧縮アルゴリズムを自由に選択するので、バイトコードは、通常、両方向に送信されることに注意されたい。今日、バイトコードをアップリンク及びダウンリンクに送信するには、各々７５０バイトの余計なペイロードが必要となる。
更に、ネットワークは、ターミナル装置がどんなアルゴリズムを使用して圧縮を行なうかに影響を及ぼすことは決してない。非常に低速の又は効率の悪いアルゴリズムを使用してもよい。又は、効率的なアルゴリズムを使用してもよいが、これは、非常に多くの処理時間を費やし、従って、ネットワークがサービスできるユーザの数を制限する。
更に、各ターミナルは、通常、常に同じバイトコードを使用し、そして同じ製造者からのターミナルでも、通常、全く同じバイトコードを使用する。従って、同じバイトコードが１時間に数回エアインターフェイスを経て送信され、これは、圧縮の全容量及び利益を低減する。
ネットワーク側での付加的な問題は、バイトコードが多数のターミナルから受け取られるときに、ネットワークが、常に同じバイトコードに対して状態ｉｄを得るためにＳＨＡ−１値を計算する必要があることである。これは、ネットワークサーバーに不必要な処理負荷を発生し、それがサービスできるユーザの数を実際上制限することがある。
他方、ネットワークがバイトコードのセットを記憶した場合には、これがＵＤＶＭ実施を最適化し、従って、記憶されたバイトコードを非常に効率的に処理することができる。例えば、ＬＺ７７アルゴリズムを使用するあるバイトコード解凍に対して、そのバイトコードのためのネットワーク実施として、バーチャルマシン及びバイトコードを全く使用せず、解凍は、より効率的な標準的方法、例えば、ある汎用のプログラミング言語で書かれた解凍ルーチンを使用して行なうようにできることが知られている。これにより、バーチャルマシンでバイトコードを実行するのに比して、非常に多くのクライアントを１つのサーバーでサービスすることができる。
それ故、本発明の目的は、少なくとも前記問題を軽減するより有効なシグナリング圧縮を提供することである。
この目的は、パケットデータネットワーク内でシグナリングメッセージを圧縮又は解凍する方法において、
− 前記パケットデータネットワークのプロトコルメッセージのヘッダ部分にパラメータ情報を与えるステップであって、前記パラメータ情報が圧縮又は解凍メカニズムの少なくとも１つの処理詳細を指定するようなステップと、
− 前記パケットデータネットワークを通して前記パケットデータネットワークの圧縮又は解凍ファンクションに前記プロトコルメッセージを転送するステップと、
− 前記パラメータ情報に基づいて前記圧縮又は解凍ファンクションにおいて前記圧縮又は解凍メカニズムをセットするステップと、
を備えた方法により達成される。
更に、前記目的は、パケットデータネットワーク内でシグナリングメッセージを処理するための装置において、
− 前記パケットデータネットワークから受け取ったプロトコルメッセージのヘッダ部分からパラメータ情報を抽出する手段であって、前記パラメータ情報が圧縮又は解凍メカニズムの少なくとも１つの処理詳細を指定するような手段と、
− 前記装置に設けられて前記シグナリングメッセージを圧縮又は解凍するのに使用される圧縮又は解凍ファンクションを、前記抽出されたパラメータ情報に基づいてセットするための手段と、
を備えた装置によって達成される。
更に、前記目的は、パケットデータネットワークからのシグナリングメッセージを処理するための装置において、
− 前記パケットデータネットワークのプロトコルメッセージのヘッダ部分にパラメータ情報を追加する手段であって、前記パラメータ情報が圧縮又は解凍メカニズムの少なくとも１つの処理詳細を指定するような手段と、
− 前記プロトコルメッセージを前記追加されたパラメータ情報と共に前記パケットデータネットワークへ送信するための手段と、
を備えた装置によって達成される。
従って、例えば、ＳＩＰレベルにおいてプロトコルメッセージのヘッダ部分により圧縮又は解凍パラメータ情報を指示して、送信ユニットが、第１メッセージを送信する前に、受信器の圧縮パラメータ値を決定できるか、或いは受信ユニットが、付加的な専用シグナリングなしに解凍パラメータ値を直接決定できるようにすることが提案される。
これにより、第１又は第１の若干のメッセージの良好な圧縮を達成することができる。更に、圧縮パラメータ情報、例えば、他のエンドポイントのバージョン又は容量を学習した後に「スイッチ」する必要がないので、圧縮の実施を簡単化することができる。
付加的な効果として、一方向のみに使用でき、且つ既存の仕様、例えば、ＲＦＣ３４８６と相互作用し得る極めて簡単なシグナリング圧縮が提供される。
更に、アドバータイズ能力情報を拡張して、おそらく既に知られているバイトコードをアドバータイズすることができ、これは、ネゴシエーション段階中の圧縮比の改善をもたらすと共に、アップリンク方向についても圧縮アルゴリズムを選択できるようにする。更に、これは、解凍アルゴリズムをより効率的にデコードする機会を与える。というのは、バーチャルマシンを使用せずに且つバイトコードなしに、解凍することができるからである。その結果、新たな、更に開発される（外部）圧縮アルゴリズムを導入することもできる。新たなアドバータイズパラメータが追加される場合には、バイトコード記憶に関する情報を一方向比較の場合にも受け取ることができる。
一般的に、送信端において実施する場合には、この装置は、シグナリングメッセージを圧縮して送信する送信器を備え、ここで、受信されるパラメータ情報は、圧縮パラメータ情報である。或いは又、送信端におけるこの装置は、解凍パラメータ情報を受信端に向けて送信してもよい。
受信端において実施する場合には、この装置は、前記シグナリングメッセージを受信して解凍する受信器を備え、ここで、受信されるパラメータ情報は、解凍パラメータ情報である。或いは又、受信端におけるこの装置は、圧縮パラメータ情報を送信端に向けて送信してもよい。
プロトコルメッセージは、例えば、ＳＩＰメッセージ又はＲＴＳＰメッセージのようなアプリケーションレイヤプロトコルメッセージでよい。パラメータ情報は、ＳｉｇＣｏｍｐアーキテクチャーの少なくとも１つのパラメータを含んでもよい。
プロトコルメッセージは、通信のための初期要求に応答して、前記シグナリングメッセージの送信端へ返送されるフィードバックメッセージでよい。
更に、パラメータ情報は、ユニフォームリソース識別子又はＳＩＰメッセージのビア・ヘッダの少なくとも一方に与えることができる。パラメータ情報は、パケットデータネットワークの中間サーバー装置においてユニフォームリソース識別子に追加することができる。更に、パラメータ情報は、パケットデータネットワークのクライアント装置においてビア・ヘッダに追加することもできる。より詳細には、パラメータ情報は、圧縮メカニズムの使用を指示するパラメータにサフィックスとして追加することができる。或いは又、パラメータ情報は、圧縮メカニズムの使用を指示するパラメータとは別のデータフィールドとして追加されてもよい。
一例として、パラメータ情報は、パラメータ情報の開始を指示する所定の第１キャラクタを含むことができる。更に、パラメータ情報は、少なくとも１つのキャラクタと、それに各々続く整数であって、前記少なくとも１つのキャラクタにより表わされたパラメータの対応値を指示する整数とを含むことができる。
本質的ではないが、より特定すると、パラメータ情報は、シグナリング圧縮バージョン、状態メモリサイズ、解凍メモリサイズ、ビット当たりのサイクル数、及び論理的に利用可能な状態のうちの少なくとも１つを指定する。
それとは別に、又はそれに加えて、パラメータ情報は、圧縮又は解凍ファンクションの実施の所有権情報を指定することができる。
解凍パラメータの特定例において、パラメータ情報は、バーチャル解凍マシンによって使用されるべき少なくとも１つのバイトコードを含むことができる。この少なくとも１つのバイトコードは、パケットデータネットワークにおいてアドバータイズすることができる。これは、ＳＩＰメッセージのビア・ヘッダにビア・パラメータとして追加することができる。ビア・パラメータは、バイトコード状態アイデンティティから導出することができる。
更に、少なくとも１つのバイトコードがサポートされない場合には、プロトコルメッセージに応答して送信された応答メッセージにおいて少なくとも１つのバイトコードを変更し又は置き換えることができる。次いで、変更又は置き換えられたバイトコードは、異なるパラメータネームのもとで送信される。任意であるが、少なくとも１つのバイトコードを受信端に記憶することができる。一例として、少なくとも１つのバイトコードをターミナル装置の加入者アイデンティティモジュール（ＳＩＭ）に記憶することができる。記憶は、少なくとも１つのバイトコードに割り当てられたプライオリティに基づいて遂行することができ、従って、古いバイトコードの削除を良好に制御することができる。
それとは別に、又はそれに加えて、少なくとも１つのバイトコードを「セッションイニシエーションプロトコル登録」メッセージのコンタクトヘッダに追加することができる。
更に別の効果的な変形態様は、従属請求項に規定する。
以下、添付図面を参照して、本発明の好ましい実施形態を詳細に説明する。
以下、本発明の好ましい実施形態を、ＲＦＣ３３２０に規定されたＳｉｇＣｏｍｐシグナリング圧縮機構に関して説明する。
ＲＦＣ３３２０のセクション３．３には、５つのＳｉｇＣｏｍｐパラメータが説明されている。それらは、ＳｉｇＣｏｍｐ受信器が、受信したＳｉｇＣｏｍｐメッセージをどのように処理するかに影響を及ぼす。ＳｉｇＣｏｍｐオペレーションを首尾良いものにするために、ＳｉｇＣｏｍｐ送信器は、受信器のこれらパラメータの値を知ることが必要である。５つのＳｉｇＣｏｍｐパラメータは、各々、解凍メモリサイズ(decompression_memory_size)、状態メモリサイズ(state_memory_size)、ビット当たりのサイクル数(cycles_per_bit)、圧縮バージョン(SigComp_version)、及びローカルで利用できる状態（０以上の状態アイテムを含むセット）を定義するのに使用される。
図１は、好ましい実施形態によるネットワーク環境の概略図である。ユーザ装置（ＵＥ）１０又は他のターミナル装置に設けられたＳＩＰユーザエージェント（図示せず）は、無線アクセスネットワーク（図示せず）を経てＳＩＰメッセージを、サービスネットワーク３０のＳＩＰアウトバウンドプロキシーサーバー２０（即ち、第１ホッププロキシーサーバー）、例えば、ＩＰマルチメディアサブシステムのプロキシーコール状態制御ファンクション（Ｐ−ＣＳＣＦ）と交換し、ＩＰベースのネットワーク４０、例えば、インターネットのサービスへのアクセスを得る。第１に、ＵＥ１０及びアウトバウンドプロキシー２０は、一連のメッセージを交換し、ＵＥ１０とアウトバウンドプロキシー２０との間にセキュリティ関連性を確立させる。これらのメッセージは、圧縮されずに送信される。
好ましい実施形態によれば、ＳＩＰレベルにおいて前記ＳｉｇＣｏｍｐパラメータの少なくとも１つを指示するためのメカニズムが導入される。
第１の好ましい実施形態では、前記メカニズムは、２つのコンポーネント又はオプションを有する。
第１に、ＳｉｇＣｏｍｐパラメータは、ＳＩＰ ＵＲＩの一部分として指示することができる。ＳＩＰ ＵＲＩは、コンタクトすることのできるＳＩＰ通信リソース（例えば、ユーザ又はサービス）を識別する。例えば、ＳＩＰクライアントは、ＳＩＰ ＵＲＩにより識別されたＳＩＰサーバーへＳＩＰ要求を送信する。ＳＩＰ ＵＲＩにＳｉｇＣｏｍｐパラメータを含ませることで、ＵＲＩにより識別されるＳＩＰエンティティのＳｉｇＣｏｍｐ能力を自動的に宣言する。これは、送信器が送信する正に第１のＳＩＰメッセージに最も適した仕方で送信器がＳｉｇＣｏｍｐを適用するのを許す。
第２に、ＳｉｇＣｏｍｐパラメータは、ビア・ヘッダフィールドの一部分として指示することができる。ビア・ヘッダフィールドは、ＳＩＰ要求において搬送される。これは、要求に対するＳＩＰ応答をどこに送信すべきか指示する。ＳｉｇＣｏｍｐパラメータをビア・ヘッダフィールドに含ませることにより、ＳＩＰ要求の送信器は、そのＳｉｇＣｏｍｐ容量をそのピアへ通知することができ、従って、ピアは、第１の応答を返送するときに最も適した仕方でＳｉｇＣｏｍｐを適用することができる。
前記オプションは、両方とも、別々に使用されてもよいし、並列コンポーネントとして使用されてもよいことに注意されたい。例えば、第１のコンポーネントは、（プロキシー）サーバーがそのＳｉｇＣｏｍｐパラメータをそのＵＲＩにおいて通知するのを許し、クライアントが、サーバーへ送信される第１の要求メッセージを最適なＳｉｇＣｏｍｐコンフィギュレーションで圧縮できるようにする。第２のコンポーネントは、同じクライアントがそれ自身のＳｉｇＣｏｍｐ容量（サーバーが前もって知らないことのある）を要求のビア・ヘッダフィールドにおいて宣言する上で有用である。サーバーは、それが要求に対して応答を返送するときに、クライアントのＳｉｇＣｏｍｐ容量に基づいてその応答を予め圧縮することができる。
ＳｉｇＣｏｍｐパラメータのフォーマットに関しては、多数の異なる形態で実施できる。しかし、それらは、基本的に、次の２つのオプションに入る。
オプション１：
ＳｉｇＣｏｍｐパラメータは、ＵＲＩ及びビア・ヘッダフィールドの両方に対してＲＦＣ３４８６に定義されたように“ｃｏｍｐ＝ｓｉｇｃｏｍｐ”に対するサフィックスとして追加される。例えば、
Sip:alice@Atlanta.com;comp=sigcomp_VnSnDnCn_Lx
Via:SIP/2.0/UPD
Pc33.Atlanta.com;branch=z9hG4bk776asdhds;comp=sigcomp_VnSnDnCn_Lx
以下、このオプションのフォーマットを説明する。
・ストリング“sigcomp”の後の第１“＿”キャラクタは、ＳｉｇＣｏｍｐパラメータの開始を指示する。
・キャラクタ“Ｖ”、“Ｓ”、“Ｄ”、“Ｃ”及び“Ｌ”は、各々、SigComp_version、state_memory_size、decompression_memory_size、cycle_per_bit、及びlocally available stateを表わす。
・キャラクタ“Ｖ”は、その後に、SigComp_versionを指示する整数が続く。整数は、１桁以上でよい。例えば、“Ｖ１”は、SigComp_version=1を意味し、そして“Ｖ１０”は、SigComp_version=10を意味する。
・同様に、キャラクタ“Ｄ”、“Ｓ”及び“Ｃ”の各々は、その後に、対応値を指示する整数（１桁以上）が続く。しかしながら、整数の額面値は、以下に示すように解釈されねばならず、これは、ＲＦＣ３３２０のセクション３．３．１に定義された考えられる値のスーパーセットを網羅する。この目的は、ＳｉｇＣｏｍｐパラメータストリングをできるだけ短くすることである。
−ｎが整数の額面値を示すとする。
−“Ｓ”の後、ｎが０に等しい場合には、state_memory_size=0バイトであり、さもなければ、state_memory_size=2(10+n)バイトである。
−“Ｄ”の後、前記と同じであるが、ｎは０にならない（というのは、０は、有効なdecomplession_memory_sizeではないからである）。
−“Ｃ”の後、cycles_per_bit=2nとなる。
・“Ｖ”、“Ｓ”、“Ｄ”、“Ｃ”間の順序は、任意であることに注意されたい。例えば、“Ｖ１Ｓ２Ｄ３Ｃ４”は、“Ｖ１Ｄ３Ｃ４Ｓ２”と等価である。これらは、両方とも、SigComp_version=1、state_memory_size=4KB、decompression_memory_size=8KB、及びcycles_per_bit=16を意味する。更に、対応するパラメータがＳｉｇＣｏｍｐ関係仕様により定義されたデフォールト値を有する場合にはそれらの幾つか又は全部を省略できる。例えば、“Ｓ３”は、state_memory_size=8KBを指示し、そして他の全てのＳｉｇＣｏｍｐパラメータ値は、デフォールトと同じである。
・“＿Ｌ”の後のストリングは、ローカルで利用できる状態の状態識別子（完全又は部分のいずれか）の１６進表示である。例えば、“Ｌ４Ｂ７ＥＣＤＥ７ＤＡ４９”は、部分状態識別子（最上位６バイト）が０ｘ４Ｂ７ＥＣＤＥ７ＤＡ４９であるローカルで利用できる状態をＳＩＰエンティティが有することを指示する。詳細については、ＲＦＣ３３２０のセクション３．３．３及び７．２を参照されたい。これは、送信器が、状態の内容を知っている場合に状態アイテムを使用するのを許す。
・注：“＿Ｌｘ”のインスタンスは、ゼロ又は複数ある。特に、“＿Ｌｘ”エレメントの除去は、ＳｉｇＣｏｍｐ規格により指定されたデフォールト状態以外のローカルで利用できる状態をＳＩＰエンティティが有していないことを意味する。
・注：“Ｌｘ”に先行する“＿”は、パージング目的で必要とされる。というのは、上述した例と同様に、“Ｄ”及び“Ｃ”（コンパクトにしたパラメータ名）も“Ｌｘ”に現れることがあるからである。
オプション２：
ＳｉｇＣｏｍｐパラメータは、“comp=”パラメータとは個別のデータフィールドとして追加される。例えば、
sip:alice@Atlanta.com;comp=sigcomp;comp-param=VnSnDnCn_Lx
via:SIP/2.0/UDP
pc33.Atlanta.com;branch=z9hG4bK776asdhds;com=sigcomp;comp-
param=VnSnDnCn_Lx
分離を除いて、ＳｉｇＣｏｍｐパラメータストリングのフォーマットは、オプション１の場合と同じでよい。このオプションの効果は、ＲＦＣ３４８６との相互運用性である。即ち、本発明を実施するＳＩＰエンドポイントが、上述したデータフィールドを、ＲＦＣ３４８６しか実施しない別のＳＩＰエンドポイントへ送信する場合には、後者は、依然として、前者が“comp=sigcomp”フィールドからＳｉｇＣｏｍｐをサポートすると結論付ける。従って、“comp-param”フィールドは、受信器により無視される。その結果、受信器は、送信器の厳密な容量（デフォールト以上の）を知らないことになるだけで、これは、ここに提案する改善を伴わないケースである。更に、このオプションは、ＲＦＣ３４８６と結合されて、ＳｉｇＣｏｍｐ以外の圧縮特徴を指示するための一般的なフレームワークとして使用することができる。即ち、ＲＦＣ３４８６としての“comp=”フィールドは、圧縮アルゴリズムを指示し、一方、ここに提案する“comp-param”は、そのアルゴリズムの付加的な情報（例えば、圧縮パラメータ）を指示する。オプション２は、ＳＩＰ ＵＲＩ及びビア・ヘッダに付加的なフィールドを必要とする。これは、オプション１と比較して、より多くのバイト（即ち“comp-param=”）が必要とされることも意味する。しかしながら、オプション２は、相互運用性及び一般性という効果を発揮する。
又、このメカニズムは、ＳＩＰエンドポイントに対して、ＳｉｇＣｏｍｐ実施に関する所有権情報を指示するように拡張できることにも注意されたい。１つの簡単な仕方は、ＳｉｇＣｏｍｐパラメータフィールドに“＿Ｘｓ”を追加することであり、ここで、“＿”は、デリミッタであり、“Ｘ”は、その所有権エレメントを指示し、そして“ｓ”は、所有権情報を保持するテキストストリングを表わす。受信器は、“Ｘ”フィールドの意味を理解しない場合にはこれを無視することができる。
第２の好ましい実施形態によれば、その考え方は、単に、ネットワーク側でもターミナル装置に１つ以上のバイトコードを記憶すると共に、利用可能なバイトコードを、エアインターフェイスを経て何回も送信する必要がないように、アドバータイズするための方法を提供することである。
圧縮セッションを開始したターミナルに関する第１の例では、ターミナル装置は、圧縮のためにネットワークにより使用される見込みが最も高いバイトコード（１つ又は複数）を既に知っていることをアドバータイズすることにより、ネットワークで圧縮セッションを開始することができる（即ち、区画、例えば、ＳＩＰメソッドＲＥＧＩＳＴＥＲ又はＩＮＶＩＴＥを伴う）。次いで、ネットワークは、それがダウンリンク方向に圧縮を開始するとき、ターミナル装置がアドバータイズしたものと同じバイトコードを使用したい場合には、バイトコードをアップロードする必要が全くない。
ネットワークからバイトコードを受け取ると、ターミナル装置は、バイトコードを永久メモリにも記憶して、おそらく、古いバイトコードの幾つか又は１つに置き換えることができる。従って、圧縮アルゴリズムが進化するときにはアルゴリズムを動的に更新することができ、従来の方法のように、アルゴリズムを固定したり、又は前もって合意したりする必要がない。
又、ネットワークは、ターミナルによって使用される見込みの最も高いバイトコード（１つ又は複数）を、ターミナル装置が知っているバイトコードをアドバータイズしたときには非圧縮応答において、又はローカルで利用できる状態を返送パラメータにおいてアドバータイズする良く知られた方法（詳細についてはＲＦＣ３３２０を参照）を使用することにより圧縮メッセージにおいて、アドバータイズしてもよい。いずれの場合にも、ネットワークがアドバータイズするバイトコードをターミナルが使用するよう選択する場合には、バイトコードをネットワークへ送信する必要がない。
圧縮セッションを開始したターミナルに関する第２の例では、ターミナル装置から新たに受け取ったバイトコードをいかに取り扱うかに相違がある。ターミナルの製造者により正しいものとして公式に確認されていないあるコードを記憶するにはセキュリティ又はリソースの問題があるので、バイトコードを永久メモリに記憶しないのがより安全である。
この第２の好ましい実施形態の基礎となる考え方は、バイトコードを、必須のバイトコード等と共に、ネットワークオペレータ及びターミナル製造者と合意する概念もサポートすることに注意されたい。ターミナル装置におけるバイトコードの幾つかは、決してオーバーライトも新たなアルゴリズムと交換もされないメモリに入れることができる。必須のアルゴリズムの場合、何らかの特定の理由で、ターミナル装置がそのアルゴリズム（及びそのバイトコード）を特に使用し、他のアルゴリズムは使用しないことをネットワークが希望しない限り、その必須のアルゴリズムをアドバータイズする必要がない。
ＳｉｇＣｏｍｐネゴシエーション方法は、ＲＦＣ３４８６に説明されている。これは、;comp=sigcompを使用して、ＳｉｇＣｏｍｐ解凍の容量を指示する。１つの解決策は、おそらく既に知られているバイトコードをアドバータイズできるように容量情報を拡張することである。
要求が送信されると、ビア・ヘッダは、容量及び解凍の意思があるときに;comp=sigcompパラメータを含む。圧縮セッションがまだない場合にはこれを拡張することが容易である。これらの場合には、新たなビア・パラメータ<compression-bytecode>が追加される。この新たなｂｃパラメータは、例えば、次のようにフォーマットすることができる。
;bc=bc_state_id_in_hexadecimal
例えば、バイトコード状態ｉｄが、０ｘ７６ ０ｘ９４ ０ｘ３４ ０ｘＡ３・・０ｘ６Ｃである場合には、ｂｃパラメータは、次の値を有することができる。
;bc=769434A3…6C
状態ｉｄの長さは２０バイトであり、従って、１６進デジットで４０バイトとなる。しかしながら、少なくとも最小アクセス長さのバイトしかパラメータに必要としないように短縮することができる。ここでは、最小アクセス長さが６バイトの場合、少なくとも１２個の１６進デジットがｂｃパラメータに必要となる。又、２つ以上のバイトコードの状態識別子をプライオリティ順に通知することもできる（必ずしも有用ではないが）。
この新たなｂｃパラメータを伴う要求が、例えば、移動ターミナルのようなターミナル装置によって受け取られた場合には、知っているリストからのバイトコードを使用しなければならず、又、他のバイトコードを選択してはならない。これは、ネットワークがサーバーの負荷をバランスできるようにする。というのは、両方向（アップリンク及びダウンリンク）に使用される圧縮アルゴリズムを選択できるからである。
ｂｃパラメータがバイトコードの空きリストを含む場合には、これは、ｂｃパラメータを送信した送信エンティティにより記憶され又は好まれるバイトコードがないことを意味する。しかしながら、送信エンティティは、このメカニズムを知っており、それが知っている又は好むバイトコードを他端がアドバータイズすることを希望する。
ｂｃパラメータを受け取ると、記憶されたバイトコードメカニズムが他端によりサポートされることが知られている。次いで、応答を送信するときに、サポートされたバイトコードをアドバータイズできるように、その応答においてビア・ヘッダを変更することができる。しかしながら、そのパラメータに対して異なるネームを使用しなければならず、さもなければ、他端がビア・ヘッダをコピーして返送したかどうか、又はバイトコードアドバータイズ方法を実際に知っているかどうか区別することができない。その応答において、受け取ったｂｃパラメータコンテンツをドロップするか又は無視することができ、且つｂｃ＿ｒｅｓｐパラメータに置き換えることができる。ｂｃ＿ｒｅｓｐパラメータのコードは、ｂｃパラメータの場合と同じでよい。
サポートされたバイトコードを与える別の方法は、ＲＦＣ３３２０に述べられた返送パラメータメカニズムを圧縮されたメッセージに使用することである。しかしながら、メッセージが圧縮されない場合には、この新たなｂｃ＿ｒｅｓｐパラメータは、既知のバイトコード（１つ又は複数）をアドバータイズする唯一の方法となる。
この場合も、ターミナル装置は、バイトコードを知っていて別のバイトコードを選択しなくてよい場合には、ネットワークがアップリンク方向にも圧縮を選択できるようにするために、ｂｃ＿ｒｅｓｐパラメータでアドバータイズされたバイトコードを使用しなければならない。
ｂｃパラメータを受け取ると、記憶されたバイトコードメカニズムが他端によってサポートされたことが分る。次いで、応答を送信するときに、サポートされたバイトコードをアドバータイズできるようにその応答においてビア・ヘッダを変更することができる。しかしながら、そのパラメータに対して異なるネームを使用しなければならず、さもなければ、他端がビア・ヘッダをコピーして返送したかどうか、又はバイトコードアドバータイズ方法を実際に知っているかどうか区別することができない。その応答において、受け取ったｂｃパラメータコンテンツをドロップするか又は無視することができ、且つｂｃ＿ｒｅｓｐパラメータに置き換えることができる。ｂｃ＿ｒｅｓｐパラメータのコードは、ｂｃパラメータの場合と同じでよい。
図２は、第２の好ましい実施形態によるビア・ヘッダ変更の概略的なシグナリング図である。“comp=sigcomp; bc=e24343…; comp_param=V2”を含むビア・ヘッダを伴う要求が図１のＵＥ１０により使用されて、アウトバウンドプロキシー２０によりおそらく使用されるバイトコードをアドバータイズし、ｓｉｇｃｏｍｐバージョン２がサポートされることを通知する。アウトバウンドプロキシー２０の応答において、ビア・ヘッダは、“comp=sigcomp; bc_resp=…”を含む。ビア・パラメータが変更されるときに、ＵＥ１９は、アウトバウンドプロキシー２０が実際にパラメータを理解することを知る。このメカニズムは、応答が圧縮されずに送信される場合に必要とされる。あるときには、各応答を圧縮しないのが有用であり、又、あるときには、一方向に圧縮するのが有用である。この場合に、ネットワークは、圧縮を希望しないが、ターミナルがそのメッセージを圧縮することを希望する。他のｓｉｇｃｏｍｐパラメータ、例えば、“comp_param_resp=V2”についても同じ種類のビア・ヘッダ変更が有用である。従って、二方向ネゴシエーションが簡単に達成される。
即ち、応答におけるビア・ヘッダの変更は、両方向におけるｓｉｇｃｏｍｐパラメータの交換を許す。もちろん、応答にＳｉｇＣｏｍｐ圧縮が使用される場合には、ビア・ヘッダでパスするｓｉｇｃｏｍｐパラメータはもはや必要とされない。というのは、このときフィードバックメカニズムを使用できるからである。更に、ＳｉｇＣｏｍｐの間であってもｂｃヘッダを使用して、ＵＥ１０が圧縮に使用するアルゴリズムを変更することができる。例えば、ＵＥ１０は、まず、ＤＥＦＬＡＴＥアルゴリズムを使用し、しばらくして、ネットワークは、他のアルゴリズムの方が良好に機能することに気付く。次いで、ビア・ヘッダにおいて他のバイトコードをアドバータイズすることができる。ネットワークは、両方向における圧縮アルゴリズムのマスター制御を行うことができる。
バイトコードの記憶については、多数の解決策が考えられる。１つ又は幾つかのバイトコードをターミナルメモリに永久的に記憶することができる（例えば、必須の又はオペレータが好むバイトコード）。ＳＩＭ（加入者アイデンティティモジュール）カードは、バイトコードｉｄがそのパラメータ（例えば、長さ、最小アクセス長さ、等）と一緒に記憶されて、このバイトコードをターミナルメモリから除去してはならないことを指示する１つの記憶場所でよい。又、ＳＩＭカードは、全バイトコードを記憶することもできる。バイトコードは、ＳＭＳ（ショートメッセージングサービス）ダウンロード、等の良く知られたメカニズムを経て更新することができる。
ターミナル装置は、ＳｉｇＣｏｍｐシグナリングにおいて新たなバイトコードを受け取ると、通常、そのバイトコードをターミナルメモリにも記憶して、ターミナル装置が次に電源オンされたときにそれをアドバータイズできるようにする。ターミナル装置は、限定された記憶容量しか有していないので、この新たなバイトコードを記憶することでメモリから古いバイトコードをある程度削除する必要がある場合には、あるプライオリティアルゴリズムが必要になる。又、メモリにプライオリティの高いバイトコードしかない場合には、バイトコードがターミナルメモリに記憶されないことも考えられる。プライオリティの高いバイトコードは、ＳＩＭカードによりプライオリティの高いバイトコードとして指示されるもの、好ましいバイトコードとしてあるＳＩＰ設定にリンクされるもの、等を含む。プライオリティメカニズムは、種々の既知の方法のいずれかで実施できる。
ネットワーク側では、実現可能な解決策として、移動ターミナルの製造者がそれらのターミナルに使用されるバイトコードに関する情報を与え（少なくとも状態識別子）、次いで、ネットワークがそれらを永久的にどこかに記憶するか又は他の戦略を選択して、バイトコードに対して不必要な記憶が要求されないよう確認することができる。適当なメカニズムを使用して、ターミナル製造者の情報を与えると共に、バイトコードをいかに及び／又はいつ記憶するかも与えることができる。しかしながら、おそらく、新たなバイトコードを記憶する戦略は、ターミナルの戦略とは異なる。
ターミナル装置がそのメモリに多数のバイトコードを記憶した場合には、；ｂｃフィールド又は；ｂｃ＿ｒｅｓｐフィールドにおいてその全部をアドバータイズするのは有用でない。簡単な戦略は、圧縮に使用される最後の１つをアドバータイズすることである。より精巧な戦略は、エンドポイントごとにどんなバイトコードが使用されたか思い出すか、又はバイトコードを接続設定にリンクさせることを含む。この場合も、ＳＩＭは、好ましいバイトコードに関する情報、等を含むことができる。又、多数のバイトコードをアドバータイズすることもできるが、長いアドバータイズメントメッセージを処理する場合には圧縮比が下がるので、入念に取り扱わねばならない。
ネットワーク側では、レジスタが、ユーザにより現在使用されているバイトコードに関する情報を有する。これは、ＲＥＧＩＳＴＥＲメッセージに設けられたコンタクト：ヘッダにこの情報を追加することを必要とする。この場合も、ネットワークは、それがアドバータイズするバイトコードを選択するための他の何らかのメカニズムを有する。ある場合に、全てのユーザがある特定のバイトコードを選択することをネットワークが希望するときには、選択は簡単である。それだけがアドバータイズされ、従って、解凍に対する各ユーザの負荷作用を計算するのは極めて容易である。
上述したように、ｓｉｇｃｏｍｐパラメータと、記憶されたバイトコードに関する情報とを配送することができる。しかしながら、一方向圧縮の場合には、返送フィードバックもビア・ヘッダにおいて送信できれば有用である。
図３は、第１エンドポイントＡ２２０と第２エンドポイントＢ２３０との間でフィードバックデータを送信するための手順の概略シグナリング図である。圧縮が一方向のみである場合には、フィードバックがエンドポイントＡ２２０へ配送されない、というのは、フィードバックデータは、圧縮されたメッセージにおいて配送されるからである。
図３によれば、エンドポイントＡ２２０における圧縮器Ｃは、フィードバックを要求するｓｉｇｃｏｍｐメッセージを、エンドポイントＢ２３０におけるＵＤＶＭへ送信する（ステップ１）。ＵＤＶＭは、圧縮情報を導出し（ステップ２）、そして状態ハンドラーＳＨを経てエンドポイントＢ２３０の圧縮器Ｃを制御し、フィードバック情報を伴う応答を発生する（ステップ３及び４）。フィードバックをビア・ヘッダに追加することにより、圧縮効率を改善することができる。図３におけるエンドポイントＢ２３０の圧縮器Ｃは、ＳｉｇＣｏｍｐメッセージを発生しないので、実際には、圧縮器ではなく、エンドポイントＡ２２０に対する区画及びそのエンドポイントに対するフィードバックを見出した場合にビア・ヘッダが新たなパラメータ“returned-feedback=…;”を含むような非圧縮メッセージを送信する（ステップ５）。エンドポイントＡ２２０のＵＤＶＭは、この新たなパラメータと共にビア・ヘッダを受け取ると（ステップ７）、一致する区画を見出し（もし可能であれば）（ステップ６）、そしてそれがエンドポイントＡ２２０の状態ハンドルＳＨを経て圧縮器Ｃへ送られると、エンドポイントＡ２２０の圧縮器Ｃにおいて、より進歩した圧縮アルゴリズム、例えば、動的圧縮を使用することができる（ステップ９）。
しかしながら、あるデータを圧縮することで実際にメッセージを拡張する場合、例えば、既に圧縮されたデータ、又は使用圧縮アルゴリズムに対して理想的でないデータを圧縮する場合、或いは、例えば、圧縮が非常に多くのリソースを食い、一時的にデアクチベートされるときの重負荷状態の間には、一方向圧縮も考えられることに注意されたい。従って、圧縮されないメッセージもある程度生じるが、他方のエンドポイントの圧縮器へフィードバックを依然として配送することはできる。
この返送フィードバックは、“…comp_param=Fnnnn”のようなビア・ヘッダにおけるｓｉｇｃｏｍｐパラメータの一部分でもあり、又、“bytecode…comp_param=B…”をアドバータイズする別の仕方でもある。
しかしながら、一般に、全体的ＳＩＰメッセージサイズへの作用は、最小でなければならない。ほとんどの時間、ここに提案する向上されたビア・ヘッダは、追加される必要がない。理想的には、それらは、ＳｉｇＣｏｍｐ圧縮がスタートする直前に、例えば、初期のＲＥＧＩＳＴＥＲメッセージのみにおいて必要とされる。従って、ここに提案する余計なフィールドは、幾つかの例外を伴うｓｉｇｃｏｍｐネゴシエーションのほとんどのメッセージにおいて省略することができる。１つの例外として、ターミナルが使用する圧縮アルゴリズムを変更したい場合には、ネットワークによりｂｃヘッダを追加することができる。別の例外として、図３を参照して上述したように、フィードバックが非圧縮メッセージにおいて送信されるときには、フィードバックヘッダが追加される。更に別の例外として、リモートエンドポイントに対する区画が何らかの理由で破壊された場合には、ｓｉｇｃｏｍｐネゴシエーションが再開される。これは、ＮＡＣＫメカニズムによって検出することもできる。
前記パラメータの幾つかは、ＲＥＧＩＳＴＥＲメッセージにおけるコンタクト情報の一部分である。又、それらは、ＵＲＩの一部分であるか、ＲＥＧＩＳＴＥＲメッセージにおける個別のヘッダフィールドである。
要約すれば、パケットデータネットワーク内でシグナリングメッセージを圧縮又は解凍する方法及び装置が説明された。パケットデータネットワークのプロトコルメッセージのヘッダ部分にはパラメータ情報が設けられる。パラメータ情報は、圧縮又は解凍メカニズムの少なくとも１つの処理詳細を指定し、そしてプロトコルメッセージと一緒に、パケットデータネットワークを通してパケットデータネットワークの圧縮又は解凍ファンクションへ転送される。圧縮又は解凍ファンクションにおける圧縮又は解凍メカニズムは、次いで、パラメータ情報に基づいてセットされる。従って、パラメータ情報が直接得られるので、第１又は第１の若干のメッセージの良好な圧縮を達成することができる。
更に、本発明は、上述した好ましい実施形態に限定されず、圧縮又は解凍パラメータが交換されるいかなるパケットデータネットワークにおいても実施できることに注意されたい。パラメータ情報は、いかなる種類のパラメータも定義できると共に、基本的な目的に適したいかなる種類のヘッダ部分を使用してもシグナリング又はアドバータイズすることができる。従って、好ましい実施形態は、特許請求の範囲内で変更し得るものである。
好ましい実施形態によるネットワーク環境の概略図である。 第２の好ましい実施形態によるビア・ヘッダ変形例の概略シグナリング図である。 第２の好ましい実施形態によりフィードバックデータを送信する手順の概略シグナリング図である。

Claims (36)

  1. パケットデータネットワーク内でシグナリングメッセージを圧縮又は解凍する方法において、
    ａ）前記パケットデータネットワークのプロトコルメッセージのヘッダ部分にパラメータ情報を与えるステップであって、前記パラメータ情報が圧縮又は解凍メカニズムの少なくとも１つの処理詳細を指定するようなステップと、
    ｂ）前記パケットデータネットワークを通して前記パケットデータネットワークの圧縮又は解凍ファンクションに前記プロトコルメッセージを転送するステップと、
    ｃ）前記パラメータ情報に基づいて前記圧縮又は解凍ファンクションにおいて前記圧縮又は解凍メカニズムをセットするステップと、
    を備えた方法。
  2. 前記プロトコルメッセージは、アプリケーションレイヤプロトコルメッセージである、請求項１に記載の方法。
  3. 前記アプリケーションレイヤプロトコルメッセージは、セッションイニシエーションプロトコルメッセージ又はリアルタイムストリーミングプロトコルメッセージである、請求項２に記載の方法。
  4. 前記パラメータ情報は、ＳｉｇＣｏｍｐアーキテクチャーの少なくとも１つのパラメータを含む、請求項１から３のいずれかに記載の方法。
  5. 前記プロトコルメッセージは、通信の初期要求に応答して前記シグナリングメッセージの送信端へ返送されるフィードバックメッセージである、請求項１から４のいずれかに記載の方法。
  6. 前記パラメータ情報は、ユニフォームリソース識別子、又はセッションイニシエーションプロトコルメッセージのビア・ヘッダの少なくとも一方に与えられる、請求項１から５のいずれかに記載の方法。
  7. 前記パラメータ情報は、前記パケットデータネットワークの中間サーバー装置において前記ユニフォームリソース識別子に追加される、請求項６に記載の方法。
  8. 前記パラメータ情報は、前記パケットデータネットワークのクライアント装置において前記ビア・ヘッダに追加される、請求項６又は７に記載の方法。
  9. 前記パラメータ情報は、前記圧縮メカニズムの使用を指示するパラメータにサフィックスとして追加される、請求項１から８のいずれかに記載の方法。
  10. 前記パラメータ情報は、前記圧縮メカニズムの使用を指示するパラメータとは別のデータフィールドとして追加される、請求項１から９のいずれかに記載の方法。
  11. 前記パラメータ情報は、前記パラメータ情報の開始を指示する所定の第１キャラクタを含む、請求項９又は１０に記載の方法。
  12. 前記パラメータ情報は、少なくとも１つのキャラクタと、それに各々続く整数であって、前記少なくとも１つのキャラクタにより表わされたパラメータの対応値を指示する整数とを含む、請求項１１に記載の方法。
  13. 前記パラメータ情報は、シグナリング圧縮バージョン、状態メモリサイズ、解凍メモリサイズ、ビット当たりのサイクル数、及びローカルに利用可能な状態、の少なくとも１つを指定する、請求項１２に記載の方法。
  14. 前記パラメータ情報は、前記圧縮又は解凍ファンクションの実施の所有権情報を指定する、請求項１２に記載の方法。
  15. 前記パラメータ情報は、バーチャル解凍マシンにより使用されるべき少なくとも１つのバイトコードを含む、請求項１に記載の方法。
  16. 前記少なくとも１つのバイトコードは、前記パケットデータネットワークにおいてアドバータイズされる、請求項１５に記載の方法。
  17. 前記少なくとも１つのバイトコードは、セッションイニシエーションプロトコルメッセージのビア・ヘッダにビア・パラメータとして追加される、請求項１５又は１６に記載の方法。
  18. 前記ビア・パラメータは、バイトコード状態アイデンティティから導出される、請求項１７に記載の方法。
  19. 前記少なくとも１つのバイトコードがサポートされない場合には、前記少なくとも１つのバイトコードは、前記プロトコルメッセージに応答して送信される応答メッセージにおいて変更され又は置き換えられる、請求項１５から１８のいずれかに記載の方法。
  20. 前記変更され又は置き換えられるバイトコードは、異なるパラメータ名のもとで送信される、請求項１９に記載の方法。
  21. 前記少なくとも１つのバイトコードは、受信端に記憶される、請求項１５から２０のいずれかに記載の方法。
  22. 前記少なくとも１つのバイトコードは、加入者アイデンティティモジュールに記憶される、請求項２１に記載の方法。
  23. 前記記憶は、前記少なくとも１つのバイトコードに割り当てられたプライオリティに基づいて実行される、請求項２１又は２２に記載の方法。
  24. 前記少なくとも１つのバイトコードは、セッションイニシエーションプロトコル登録メッセージのコンタクトヘッダに追加される、請求項１５又は１６に記載の方法。
  25. パケットデータネットワーク内でシグナリングメッセージを処理するための装置において、
    ａ）前記パケットデータネットワークから受け取られたプロトコルメッセージのヘッダ部分からパラメータ情報を抽出する手段であって、前記パラメータ情報が圧縮又は解凍メカニズムの少なくとも１つの処理詳細を指定するような手段と、
    ｂ）前記装置に設けられて前記シグナリングメッセージを圧縮又は解凍するのに使用される圧縮又は解凍ファンクションを、前記抽出されたパラメータ情報に基づいてセットするための手段と、
    を備えた装置。
  26. 前記装置は、前記シグナリングメッセージを圧縮して送信するための送信器を備え、前記パラメータ情報は、圧縮パラメータ情報である、請求項２５に記載の装置。
  27. 前記パラメータ情報は、ユニフォームリソース識別子、又はセッションイニシエーションプロトコルメッセージのビア・ヘッダの少なくとも一方に与えられる、請求項２６に記載の装置。
  28. 前記装置は、前記シグナリングメッセージを受信して解凍するための受信器を備え、前記パラメータ情報は、解凍パラメータ情報である、請求項２５に記載の装置。
  29. 前記解凍パラメータ情報は、バーチャル解凍マシンによって使用されるべき少なくとも１つのバイトコードを含む、請求項２８に記載の装置。
  30. 前記パラメータ情報は、セッションイニシエーションプロトコルメッセージのビア・ヘッダ又はコンタクトヘッダに与えられる、請求項２９に記載の装置。
  31. パケットデータネットワークからのシグナリングメッセージを処理するための装置において、
    ａ）前記パケットデータネットワークのプロトコルメッセージのヘッダ部分にパラメータ情報を追加する手段であって、前記パラメータ情報が圧縮又は解凍メカニズムの少なくとも１つの処理詳細を指定するような手段と、
    ｂ）前記プロトコルメッセージを前記追加されたパラメータ情報と共に前記パケットデータネットワークへ送信するための手段と、
    を備えた装置。
  32. 前記装置は、前記シグナリングメッセージを受信して解凍するための受信器を備え、前記パラメータ情報は、圧縮パラメータ情報である、請求項３１に記載の装置。
  33. 前記圧縮パラメータ情報は、ユニフォームリソース識別子、又はセッションイニシエーションプロトコルメッセージのビア・ヘッダの少なくとも一方に与えられる、請求項３２に記載の装置。
  34. 前記パラメータ情報は、解凍パラメータ情報である、請求項３１に記載の装置。
  35. 前記解凍パラメータ情報は、バーチャル解凍マシンによって使用されるべき少なくとも１つのバイトコードを含む、請求項３４に記載の装置。
  36. 前記パラメータ情報は、セッションイニシエーションプロトコルメッセージのビア・ヘッダ又はコンタクトヘッダに与えられる、請求項２９に記載の装置。
JP2008511808A 2005-05-17 2006-05-16 シグナリングの圧縮／解凍 Ceased JP2008541643A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US68145005P 2005-05-17 2005-05-17
US11/188,768 US7765325B2 (en) 2005-05-17 2005-07-26 Signaling compression/decompression with improved efficiency
PCT/IB2006/001286 WO2006123221A1 (en) 2005-05-17 2006-05-16 Signaling compression/decompression

Publications (2)

Publication Number Publication Date
JP2008541643A true JP2008541643A (ja) 2008-11-20
JP2008541643A5 JP2008541643A5 (ja) 2009-03-12

Family

ID=36928678

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008511808A Ceased JP2008541643A (ja) 2005-05-17 2006-05-16 シグナリングの圧縮／解凍

Country Status (6)

Country Link
US (1) US7765325B2 (ja)
EP (1) EP1900174B1 (ja)
JP (1) JP2008541643A (ja)
KR (1) KR101030469B1 (ja)
CN (1) CN101248642B (ja)
WO (1) WO2006123221A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012114564A (ja) * 2010-11-22 2012-06-14 Ricoh Co Ltd 通信装置

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100361553C (zh) * 2005-07-29 2008-01-09 华为技术有限公司 一种无线终端用户标识保存方法与装置
US8644314B2 (en) * 2006-09-07 2014-02-04 Kyocera Corporation Protocol and method of VIA field compression in session initiation protocol signaling for 3G wireless networks
US20080115125A1 (en) * 2006-11-13 2008-05-15 Cingular Wireless Ii, Llc Optimizing static dictionary usage for signal compression and for hypertext transfer protocol compression in a wireless network
US7796592B2 (en) * 2006-11-13 2010-09-14 At&T Mobility Ii Llc Optimizing static dictionary usage for signal, hypertext transfer protocol and bytecode compression in a wireless network
CN101197825B (zh) * 2006-12-08 2011-12-21 华为技术有限公司 一种传输压缩消息的方法、系统及设备
US7885294B2 (en) * 2007-08-23 2011-02-08 Cisco Technology, Inc. Signaling compression information using routing protocols
US20090154397A1 (en) * 2007-12-17 2009-06-18 Nortel Networks Limited System and method for providing quality of service enablers for third party applications
JP2009206648A (ja) * 2008-02-26 2009-09-10 Nec Corp シグナリングサーバ、データ通信システム、シグナリング処理代行方法およびプログラム
KR101006141B1 (ko) * 2008-11-17 2011-01-07 텔코웨어 주식회사 Ｓｉｐ 메시지 전송 방법
US9172706B2 (en) * 2009-11-23 2015-10-27 At&T Intellectual Property I, L.P. Tailored protection of personally identifiable information
US8982893B2 (en) * 2010-03-04 2015-03-17 Telefonaktiebolaget L M Ericsson (Publ) System and method of quality of service enablement for over the top applications in a telecommunications system
CN103457614B (zh) * 2012-05-31 2016-09-28 国际商业机器公司 射频单元、基带处理单元和基站系统
WO2014110773A1 (zh) 2013-01-17 2014-07-24 华为技术有限公司 一种数据包处理方法和装置
WO2018203982A1 (en) * 2017-05-05 2018-11-08 The Regents Of The University Of California Trans-layer bidirectional robust header compression system
WO2023082244A1 (zh) * 2021-11-15 2023-05-19 海能达通信股份有限公司 群组附着方法及相应设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0477150A (ja) * 1990-07-17 1992-03-11 Nec Corp 音声圧縮比切替方式
JPH10303971A (ja) 1997-04-23 1998-11-13 Nippon Telegr & Teleph Corp <Ntt> メッセージ通信方式
JP2003008680A (ja) * 2001-06-19 2003-01-10 Sony Corp 再生装置および再生方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6950445B2 (en) * 2000-11-16 2005-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Communication system and method for shared context compression
US20040059835A1 (en) * 2002-09-25 2004-03-25 Zhigang Liu Method and system for in-band signaling between network nodes using state announcement or header field mechanisms
US7213143B1 (en) * 2003-01-27 2007-05-01 Nortel Networks Limited Security over a network
US20050144326A1 (en) * 2003-12-05 2005-06-30 Robert Sugar Compartment handling for signaling compression
US7627692B2 (en) * 2004-01-30 2009-12-01 Nokia Corporation Multiplexing of compressed control and user-plane messages
US7348904B2 (en) * 2004-02-19 2008-03-25 Telefonaktiebolaget Lm Ericsson (Publ) Selective updating of compression dictionary
EP1599009A1 (en) 2004-05-17 2005-11-23 Hewlett-Packard Development Company, L.P. Improvements in message-based communications

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0477150A (ja) * 1990-07-17 1992-03-11 Nec Corp 音声圧縮比切替方式
JPH10303971A (ja) 1997-04-23 1998-11-13 Nippon Telegr & Teleph Corp <Ntt> メッセージ通信方式
JP2003008680A (ja) * 2001-06-19 2003-01-10 Sony Corp 再生装置および再生方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
JPN6011031497; 'ＲＦＣ　２３９３：ＩＰ　Ｐａｙｌｏａｄ　Ｃｏｍｐｒｅｓｓｉｏｎ　Ｐｒｏｔｏｃｏｌ　（ＩＰＣｏｍｐ）' ＮＥＴＷＯＲＫ　ＷＯＲＫＩＮＧ　ＧＲＯＵＰ　ＲＥＱＵＥＳＴ　ＦＯＲ　ＣＯＭＭＥＮＴＳ , 1998 *
JPN6011031499; 'Ｃｏｍｐｒｅｓｓｉｎｇ　ｔｈｅ　Ｓｅｓｓｉｏｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ（ＳＩＰ）' ＮＥＴＷＯＲＫ　ＷＯＲＫＩＮＧ　ＧＲＯＵＰ　ＲＥＱＵＥＳＴ　ＦＯＲ　ＣＯＭＭＥＮＴＳ , 2003 *
JPN6011054982; 千村保文: ＩＤＧ情報通信シリーズ　ＳＩＰ教科書 初版, 20030502, 第１２６頁, 株式会社ＩＤＧジャパン *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012114564A (ja) * 2010-11-22 2012-06-14 Ricoh Co Ltd 通信装置

Also Published As

Publication number Publication date
KR101030469B1 (ko) 2011-04-25
CN101248642A (zh) 2008-08-20
KR20080014041A (ko) 2008-02-13
CN101248642B (zh) 2012-07-18
EP1900174B1 (en) 2013-10-02
US7765325B2 (en) 2010-07-27
US20060262812A1 (en) 2006-11-23
EP1900174A1 (en) 2008-03-19
WO2006123221A1 (en) 2006-11-23

Similar Documents

Publication Publication Date Title
US7765325B2 (en) Signaling compression/decompression with improved efficiency
CA2671666C (en) Method, communications node, and memory for dynamic dictionary updating and optimization for compression and decompression of messages
US7430617B2 (en) Method and system for header compression
JP2004096717A (ja) 無線通信システムにおけるプロトコル・メッセージの圧縮
US20080037509A1 (en) Method and communications node for creation and transmission of user specific dictionary for compression and decompression of messages
EP3163837B1 (en) Header compression for ccn messages using a static dictionary
KR20090084865A (ko) 메시지 압축 방법 및 장치
KR20090084864A (ko) 메시지 압축
JP2005506717A (ja) 無線データ通信のための圧縮方法、送信機及び受信機
US8621107B2 (en) State-mediated data signaling used for compression in telecommunication services
WO2007069944A1 (en) Enhanced dynamic compression
EP1719319A1 (en) Method and arrangement for state memory management
WO2010047229A1 (ja) 通信システムおよび通信装置
EP1726139B1 (en) Compression scheme negotiation
JP2010245835A (ja) Ｓｉｐメッセージ圧縮解凍装置および無線基地局
Forte et al. Template-based signaling compression for push-to-talk over cellular (PoC)
WO2023195986A1 (en) Hybrid rohc-rtp stack for small packet applications
Rawat et al. Using sigcomp and rohc in wireless networks

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090113

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090113

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20100625

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110519

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110621

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110921

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20111018

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20111025

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120224

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20120302

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20120323

A045 Written measure of dismissal of application [lapsed due to lack of payment]

Free format text: JAPANESE INTERMEDIATE CODE: A045

Effective date: 20130827