JPWO2010047229A1 - 通信システムおよび通信装置 - Google Patents

Abstract

本発明は、ＳＩＰクライアント１−２、プロキシ２−２およびノード３−２を含んだ通信システムであって、ノード３−２は、ＳＩＰクライアント１−２宛のＳＩＰメッセージを中継する場合、パラメータに設定されている管理情報をＩＤに置き換え、またＩＤと管理情報を関連付けて記憶し、記憶したＩＤが設定されたＳＩＰメッセージを中継する場合、ＩＤをこれに関連付けられた管理情報に置き換え、ＳＩＰクライアント１−２は、受信したＳＩＰメッセージのパラメータにＩＤが設定されている場合、パラメータとＩＤを関連付けて記憶し、また、記憶したパラメータを含んだＳＩＰメッセージを送信する場合、パラメータに対して、これに関連付けられたＩＤを設定する。

Description

本発明は、ＳＩＰ（Session Initiation Protocol）シグナリングに使用するＳＩＰメッセージを圧縮・伸張する機能を有する通信システムおよび通信装置に関する。

ＳＩＰは音声や映像などマルチメディアのセッションを確立するためのプロトコルであり、ＩＥＴＦ（The Internet Engineering Task Force）ＲＦＣ２５４３で規定されている。ＳＩＰで使用するメッセージはＨＴＴＰと同じくテキストで規定されているため、メッセージは一般的に大きなサイズになり、帯域の小さな通信環境で使用する場合、呼設定時間の増大や帯域の浪費などが問題となる。そのため、ＩＥＴＦではＲＦＣ３３２０でＳＩＰシグナリングの圧縮技術ＳｉｇＣｏｍｐ（Signaling Compression）を規定している。このＳｉｇＣｏｍｐでは圧縮解凍アルゴリズムは規定されていないが、暗黙的にはＤｅｆｌａｔｅなどの圧縮アルゴリズムが利用される。これら圧縮アルゴリズムは各パケットに含まれるビットにおける冗長性を除去するバイナリ圧縮を行うものである。

また、下記特許文献１には、ＳＩＰを終端する通信装置同士が、ＳＩＰメッセージを送信する際に冗長なパラメータを削除した短いテキストメッセージを作成・送信し、また、ＳＩＰメッセージを受信する際には送信側で削除されたテキスト構文（パラメータ）を特定してＳＩＰメッセージを復元することにより圧縮効率を向上させる手法が記載されている。

特許第４０４４８４５号公報

しかしながら、上記特許文献１に記載の技術は、ＳＩＰの意味を知っている通信装置（ＳＩＰクライアント（SIP Client）、ＳＩＰプロキシ（SIP Proxy）など）に対してのみ適用が可能である、すなわち、適用可能な区間がＳＩＰを終端する通信装置間に限られ、ＳＩＰの意味を知らない通信装置ではＳＩＰメッセージを圧縮することができない、という問題があった。

通信システムでは、ＳＩＰの意味を知っているＳＩＰプロキシでＳＩＰメッセージの圧縮を行わず、ＳＩＰの意味を知らないノードで圧縮を行うケースも想定される。たとえば、３ＧＰＰ（3rd Generation Partnership Project）で規定されたＰＤＣＰ（Packet Data Convergence Protocol）機能は、ＩＰヘッダなどの圧縮を行う機能であるが、この機能はＳＩＰを終端しない基地局制御装置に実装される。このためＳＩＰメッセージ圧縮もこのノード（基地局制御装置）で行う可能性がある。ＳＩＰメッセージの圧縮も基地局制御装置で行うようにした方が効率的な圧縮が可能となるからである。しかしながら、上記特許文献１に記載の技術は、この様なケースには適用できず、圧縮効率を向上させることができない。

本発明は、上記に鑑みてなされたものであって、ＳＩＰの意味を知らないノードにおいて、ＳＩＰの高効率な圧縮を行う通信システムおよびこれを構成する通信装置を得ることを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、ＳＩＰクライアント、当該ＳＩＰクライアントのプロキシ、および当該ＳＩＰクライアントと当該プロキシの間に位置し、受信したＳＩＰメッセージを中継するノードを含んだ通信システムであって、前記ノードは、前記ＳＩＰクライアント宛のＳＩＰメッセージを中継する場合、受信したＳＩＰメッセージの特定のパラメータに設定されている管理情報をその内容を一意に示すＩＤに置き換え、また当該ＩＤと当該管理情報とを関連付けて記憶し、一方、前記ＳＩＰクライアントから送信されたＳＩＰメッセージでありかつその特定のパラメータに前記記憶したＩＤと同じＩＤが設定されたＳＩＰメッセージを中継する場合、当該ＩＤをこれに関連付けられた管理情報に置き換え、前記ＳＩＰクライアントは、受信したＳＩＰメッセージの特定のパラメータに前記ＩＤが設定されている場合、当該パラメータと当該ＩＤとを関連付けて記憶し、また、当該記憶したパラメータと同じパラメータを含んだＳＩＰメッセージを送信する場合、当該パラメータに対して、これに関連付けられたＩＤを設定することを特徴とする。

この発明によれば、各パラメータの設定値とＩＤとを置き換える処理を実施するノードは、ＳＩＰメッセージに含まれるパラメータのうち、ＩＤに置き換える必要があるパラメータのみを認識していればよく、ＳＩＰプロトコル（ＳＩＰメッセージ内のパラメータへの設定値）の意味を知らなくてもＳＩＰメッセージを圧縮することができる、という効果を奏する。

図１は、本発明にかかる無線通信システムの構成例を示す図である。 図２は、通常の（ＳＩＰメッセージの圧縮を行わない）ＳＩＰシグナリングの一例を示すシーケンス図である。 図３は、実施の形態１の無線通信システムにおけるＳＩＰシグナリングの一例を示すシーケンス図である。 図４は、ＳＩＰメッセージの圧縮を行うノードにおける圧縮対象パラメータの管理方法を示す図である。 図５は、実施の形態２の無線通信システムにおけるＳＩＰシグナリングの一例を示すシーケンス図である。 図６は、実施の形態３の無線通信システムにおけるＳＩＰシグナリングの一例を示すシーケンス図である。 図７は、実施の形態４の無線通信システムにおけるＳＩＰシグナリングの一例を示すシーケンス図である。 図８は、圧縮対象パラメータの管理方法を示す図である。

以下に、本発明にかかる通信システムおよび通信装置の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。

実施の形態１．
図１は、本発明にかかる無線通信システムの構成例を示す図である。本実施の形態の無線通信システムは、音声通信機能を有し、ＳＩＰ終端部となるＳＩＰクライアント（SIP Client）１−１および１−２と、ＳＩＰを実装し、ＳＩＰクライアント１−１および１−２の対向ノードとなるプロキシ（Proxy）２−１および２−２と、ＳＩＰを終端しないが、受信したＳＩＰメッセージの圧縮および伸張（圧縮される前のＳＩＰメッセージの復元）を行うノード３−１および３−２と、を含み、プロキシ２−１および２−２はＳＩＰネットワークに接続されている。また、ノード３−１は、ＳＩＰクライアント１−１とプロキシ２−１との間に位置し、ＳＩＰメッセージを含む各種メッセージ（信号）を中継する。ノード３−２は、ＳＩＰクライアント１−２とプロキシ２−２との間に位置し、ＳＩＰメッセージを含む各種メッセージ（信号）を中継する。なお、各ＳＩＰクライアントと各ノードは無線通信を行う。各ノードは、複数のＳＩＰクライアントを収容可能である。

ここでまず、本実施の形態の無線通信システムにおける特徴的な動作を説明する前に、その前提となるＳＩＰシグナリング制御動作を図１および図２に基づいて説明する。図２は、通常の（ＳＩＰメッセージの圧縮を行わない）ＳＩＰシグナリング（ＳＩＰによる呼設定）を示すシーケンス図であり、一例として、図１の無線通信システムにおいて通常のＳＩＰシグナリングを実行する場合のシーケンスを示している。なお、ＳＩＰメッセージの圧縮を行わないＳＩＰシグナリングでは、図１に示したノード３−１および３−２はＳＩＰメッセージを単に中継するだけなので、図２においては、ノード３−１および３−２の動作の記載を省略している。

図２に示したように、ＳＩＰによる呼設定では、まず通信開始を希望するクライアント（この例ではＳＩＰクライアント１−１）がＩＮＶＩＴＥメッセージを通信相手先のクライアント（ＳＩＰクライアント１−２）に向けて発行（送信）する。このＩＮＶＩＴＥメッセージはプロキシ２−１およびプロキシ２−２を介して相手側に到達するが、各プロキシで中継される際にプロキシに関する情報が追記される。たとえば、プロキシ２−１では、ＩＮＶＩＴＥメッセージのヘッダに含まれるＶｉａパラメータ（図示した「Ｖｉａ：○○○○」に相当）およびＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータ（図示した「Ｒｅｃｏｒｄ−Ｒｏｕｔｅ：○○○○；Ｉｒ」に相当）に対してプロキシ２−１のＵＲＬ情報（図示した「Ｐｒｏｘｙ２−１＿ＵＲＬ」に相当）が追記される。また、各プロキシは、ＩＮＶＩＴＥメッセージ転送（中継）後、このＩＮＶＩＴＥメッセージの送信元のＳＩＰクライアントまたはプロキシに対して１００ Ｔｒｙｉｎｇメッセージを送信する。

上記ＩＮＶＩＴＥメッセージを受信したＳＩＰクライアント１−２は、応答メッセージとして１８０ Ｒｉｎｇｉｎｇメッセージ（以下、単に「Ｒｉｎｇｉｎｇメッセージ」と記載する）を送信する。その際、受信したＩＮＶＩＴＥメッセージに含まれていたＶｉａパラメータおよびＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータの値をそのまま設定する。また、このＲｉｎｇｉｎｇメッセージは、各プロキシにおいてＶｉａパラメータに設定された一部の情報が削除された上で転送（中継）される。たとえばプロキシ２−２では「Ｖｉａ：Ｐｒｏｘｙ２−２＿ＵＲＬ」が削除される。すなわち、各プロキシは、Ｒｉｎｇｉｎｇメッセージを転送する際に、そのＶｉａパラメータに設定されている情報から自身のＵＲＬ情報を削除する。

同様に、上記ＲｉｎｇｉｎｇメッセージにつづいてＳＩＰクライアント１−２からＳＩＰクライアント１−１へ送信された２００ ＯＫメッセージ（以下、単に「ＯＫメッセージ」と記載する）を転送する場合にも、各プロキシは、受信したＯＫメッセージのＶｉａパラメータに設定されている情報から自身のＵＲＬ情報を削除する。

また、ＳＩＰクライアント１−１が、上記ＯＫメッセージを受信し、その応答メッセージとしてＡＣＫメッセージを送信する場合、それに含まれるパラメータの一つであるＲｅｃｏｒｄパラメータ（図示した「Ｒｅｃｏｒｄ：○○○○；Ｉｒ」に相当）には、受信したＯＫメッセージのＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されていた各プロキシのＵＲＬ情報（ＵＲＬ情報のリスト）を、その並び順が逆になるように並べ替えた上で設定する。そして、各プロキシは、ＡＣＫメッセージを転送する場合、受信したＡＣＫメッセージのＲｅｃｏｒｄパラメータに設定されている情報から自身のＵＲＬ情報を削除する。

さらに、ＳＩＰクライアント間で通信を切断する場合、ＢＹＥメッセージを発行するＳＩＰクライアント（図２の例ではＳＩＰクライアント１−２）は、通信を開始する際に受信したＩＮＶＩＴＥメッセージのＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されていた各プロキシのＵＲＬ情報を、そのまま（各ＵＲＬ情報を並べ替えることなく）ＢＹＥメッセージのＲｅｃｏｒｄパラメータに設定する。各プロキシは、ＢＹＥメッセージを転送する場合、受信したＢＹＥメッセージのＶｉａパラメータに設定されている情報に自身のＵＲＬ情報を追記し、またＲｅｃｏｒｄパラメータに設定されている情報からは自身のＵＲＬ情報を削除する。

ＢＹＥメッセージに対してＯＫメッセージを返送する場合、上記ＩＮＶＩＴＥメッセージに対してＯＫメッセージを返送する場合と同様に、受信したメッセージのＶｉａパラメータに設定されていた情報およびＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されていた情報を、そのままＯＫメッセージのＶｉａパラメータおよびＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定する。ただし、ＢＹＥメッセージにはＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータが含まれないため、実際には、Ｖｉａパラメータのみを設定する。各プロキシは、ＯＫメッセージを転送する場合、上記ＩＮＶＩＴＥメッセージに対するＯＫメッセージを転送する場合と同様に、Ｖｉａパラメータに設定されている情報から自身のＵＲＬ情報を削除する。

なお、図２の例では、ＩＮＶＩＴＥメッセージの受信側であるＳＩＰクライアント１−２がＢＹＥメッセージを発行するシーケンスを示したが、ＳＩＰクライアント１−１がＢＹＥメッセージを発行する場合についても同様である。すなわち、ＳＩＰクライアント１−１がＢＹＥメッセージを発行する場合、そのＲｅｃｏｒｄパラメータには、上記ＩＮＶＩＴＥメッセージに対するＯＫメッセージのＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されていた情報（各プロキシのＵＲＬ情報）を設定する。

以上のように、各ＳＩＰメッセージに含まれるＶｉａパラメータ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータ、Ｒｅｃｏｒｄパラメータには相関関係がある。そして、この相関関係は、ＳＩＰプロトコルを終端するＳＩＰクライアントでは暗黙的に既知とみなすことができる。

また、図１に示した無線通信システムでは、ＳＩＰクライアント１−１と１−２との間でＳＩＰメッセージを中継するプロキシ（ＳＩＰメッセージの内容を理解して転送するプロキシ）の数は２であるが、実際には、さらに多くのプロキシが存在する。上記説明からも分かるように、ＳＩＰクライアント間に多くのプロキシが存在する場合には、Ｖｉａパラメータなどに設定される情報が増加し、ＳＩＰメッセージのサイズが大きくなる。ＳＩＰクライアントが無線通信端末である場合など、ＳＩＰメッセージの伝送経路に無線区間が含まれる場合には、ＳＩＰメッセージを圧縮して無線リソースの有効利用を図ることが望まれる。

つづいて、本実施の形態の無線通信システムにおけるシグナリング制御動作を図１および図３に基づいて説明する。図３は、実施の形態１の無線通信システムにおけるＳＩＰシグナリングの一例を示すシーケンス図であり、上記図２で示したシーケンスと同様に、図１に示したＳＩＰクライアント１−１からＳＩＰシグナリングを開始する場合の例を示している。なお、図３は、特に、本実施の形態の無線通信システムにおいてＳＩＰメッセージの圧縮・伸張制御を実行する区間に位置しているＳＩＰクライアント１−２、プロキシ２−２およびノード３−２に注目し、これらの間で実行されるシーケンスを示している。

図３に示したように、通信開始後、プロキシ２−２は、ノード３−２経由でＳＩＰクライアント１−２に対してＩＮＶＩＴＥメッセージを送信するが、このメッセージのヘッダ内のＶｉａパラメータおよびＲｅｃｏｒｄ−ＲｏｕｔｅパラメータにはＵＲＬリストが設定されている。ここで、ＵＲＬリストとは、伝送経路の管理情報であり、ＳＩＰメッセージの経路上の全てのプロキシ（ＳＩＰクライアントを含む場合もある）のＵＲＬを経路上の順番に従って並べたリストである。上述したとおり、各ＳＩＰメッセージに含まれるＶｉａパラメータ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータには相関関係があり、この相関関係は、ＳＩＰプロトコルを終端するＳＩＰクライアントでは暗黙的に既知とみなすことができる。

そのため、ノード３−２は、ＳＩＰメッセージをＳＩＰクライアント１−２へ送信する際、この各種ＵＲＬリストに対して独自のＩＤを割り当て、ヘッダ内のＶｉａパラメータに設定されている情報（ＵＲＬリスト）およびＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されている情報（ＵＲＬリスト）を上記ＩＤに置き換えるとともに、これらの各種ＵＲＬリストと置き換えたＩＤとを対応付けて記憶する。

また、ＳＩＰクライアント１−２は、ＩＮＶＩＴＥメッセージ受信時に、このＩＮＶＩＴＥメッセージに含まれる上記ＩＤをそれが設定されていたパラメータと関連付けて記憶する。なお、各種ＵＲＬリストに対して割り当てるＩＤは、ＵＲＬリストの値各々に対して割り当てる。すなわち、ＩＤは、ＵＲＬリストの種別を示すのではなく、ＵＲＬリストの内容を一意に示す。

上記図２に基づいて説明したように、ＳＩＰクライアント１−２は、Ｒｉｎｇｉｎｇメッセージ、ＯＫメッセージおよびＢＹＥメッセージを送信する場合、それらのヘッダにＶｉａパラメータ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータ、Ｒｅｃｏｒｄパラメータを設定するが、これらの値は受信したＩＮＶＩＴＥメッセージのヘッダに設定されていたＵＲＬリストと同じである。そのため、ＳＩＰクライアント１−２は、ＩＮＶＩＴＥメッセージで通知されたＩＤを、上記各送信メッセージのヘッダに設定してノード３−２経由でプロキシ２−２へ送信する。

ノード３−２は、ＳＩＰクライアント１−２からＳＩＰメッセージを受信した場合、まず、そのヘッダに設定されているＩＤ（ＵＲＬリストを一意に示す情報）に対応するＵＲＬリストを、記憶しておいたＵＲＬリストの中から特定する。次に、受信メッセージのヘッダに設定されているＩＤを上記特定したＵＲＬリストに置き換えた後、プロキシ２−２へ転送する。

図３の例では、ノード３−２は、ＩＮＶＩＴＥメッセージを受信した際に、そのヘッダ内のＶｉａパラメータに設定されているＵＲＬリスト，Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されているＵＲＬリストをそれぞれ、ＩＤ＃１，ＩＤ＃３に置き換えている。また、ＳＩＰクライアント１−２は、ＳＩＰメッセージ（Ｒｉｎｇｉｎｇメッセージ，ＯＫメッセージ，ＢＹＥメッセージ）を送信する場合、それらのヘッダ内のＶｉａパラメータ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータには、本来設定するＵＲＬリストに代えて、これらに対応したＩＤ＃１，ＩＤ＃３をそれぞれ設定している。そして、ノード３−２は、ＳＩＰクライアント１−２からＳＩＰメッセージを受信した場合、そのヘッダ内のＶｉａパラメータおよびＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されているＩＤを対応するＵＲＬリストに置き換えた上でプロキシ２−２へ転送する。

また、図４は、ノード３−２における圧縮対象パラメータ（Ｖｉａパラメータ，Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータ，Ｒｅｃｏｒｄパラメータ）の管理方法を示す図である。図示したように、ノード３−２は、プロキシ２−２から受信したＳＩＰメッセージ内の圧縮対象パラメータに設定されていたＵＲＬリストとＩＤを対応付けて管理する。なお、図４の例では、ノード３−２は、ＳＩＰクライアント１−２ａ、ＳＩＰクライアント１−２ｂ、ＳＩＰクライアント１−２ｃなど複数のＳＩＰクライアントを管理しているが、ＳＩＰクライアントごとにＩＤを管理する必要はない。すなわち、ＩＤに対応するＵＲＬリストをどのクライアントが送信してきたか、どのクライアントに送信すべきか、などを認識しておく必要はない。また、Ｖｉａパラメータ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータ、Ｒｅｃｏｒｄパラメータなどの種別を認識して情報種別毎にＩＤを管理する必要もない。一方、各ＳＩＰクライアントは、セッション情報とＩＤとを対応付けて管理する。なお、ノード３−１およびこれに接続されたＳＩＰクライアントにおける圧縮対象パラメータおよびそのＩＤの管理方法も同様である。

このように、本実施の形態の無線通信システムでは、ＳＩＰクライアントとプロキシとの間でＳＩＰメッセージを中継するノードが、ＳＩＰクライアントへＳＩＰメッセージを中継する際に、中継するメッセージのヘッダに設定されたパラメータのうち、他のメッセージと関連性を有するパラメータ（Ｖｉａパラメータ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータ、Ｒｏｕｔｅ情報）については、各パラメータの内容（設定された情報）をその情報を一意に示すＩＤに置き換えることとした。さらに、ＳＩＰクライアントから受信したＳＩＰメッセージのヘッダに各パラメータの内容を示すＩＤが設定されている場合、当該ＩＤを対応する内容に置き換えた上で中継することとした。また、ＳＩＰクライアントは、ＳＩＰメッセージを送信する場合、そのヘッダに設定するパラメータのうち、他のメッセージと関連性を有するパラメータについては、実際の情報に代えてそれらの内容を一意に示すＩＤを設定することとした。これにより、ＳＩＰメッセージの圧縮効率を向上できる。また、各パラメータの設定値（設定情報）とＩＤとを置き換える処理を実施するノードは、ＳＩＰメッセージのヘッダ内のパラメータのうち、ＩＤに置き換える必要があるパラメータのみを認識できればよく、ＳＩＰプロトコル（ＳＩＰメッセージ内のパラメータへの設定値）の意味を知らなくてよいというメリットが生じる。

実施の形態２．
つづいて、実施の形態２について説明する。なお、本実施の形態の無線通信システムの構成は、上述した実施の形態１と同様である。図５は、実施の形態２の無線通信システムにおけるＳＩＰシグナリングの一例を示すシーケンス図であり、上記図２で示したシーケンスと同様に、図１に示したＳＩＰクライアント１−１からＳＩＰシグナリングを開始する場合の例を示している。なお、図５は、特に、本実施の形態の無線通信システムにおいてＳＩＰメッセージの圧縮・伸張制御を実行する区間に位置しているＳＩＰクライアント１−１、プロキシ２−１およびノード３−１に注目し、これらの間で実行されるシーケンスを示している。以下に、本実施の形態の無線通信システムにおけるシグナリング制御動作を図１および図５に基づいて説明する。なお、実施の形態１と重複する部分については説明を省略する。

通信開始後、シーケンスが正常に進んでいくと、プロキシ２−１は、ノード３−１経由でＳＩＰクライアント１−１に対して、１００ Ｔｒｙｉｎｇメッセージ（以下、単に「Ｔｒｙｉｎｇメッセージ」と記載する）、Ｒｉｎｇｉｎｇメッセージ、ＯＫメッセージを送信する。このとき、これらのＳＩＰメッセージのヘッダにはＶｉａパラメータやＲｅｃｏｒｄ−ＲｏｕｔｅパラメータとしてＵＲＬリストが設定されている。そして、実施の形態１で説明したとおり、各ＳＩＰメッセージに含まれるＶｉａパラメータ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータが有する相関関係は、ＳＩＰプロトコルを終端するＳＩＰクライアントでは暗黙的に既知とみなすことができる。そのため、ノード３−１は、ＳＩＰメッセージをＳＩＰクライアント１−１へ送信する際、この各種ＵＲＬリストに対してＩＤを割り当て、ＶｉａパラメータおよびＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定するＵＲＬリストをこのＩＤで置き換えるとともに、これらの各種ＵＲＬリストをＩＤと対応付けて記憶する。また、ＳＩＰクライアント１−１は、上記ＳＩＰメッセージを受信した場合、そのヘッダ内のＶｉａパラメータやＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されていたＩＤを記憶する。なお、各種ＵＲＬリストに対して割り当てるＩＤは、実施の形態１と同様に、ＵＲＬリストの各値（ＵＲＬ）それぞれに対して割り当てる。

また、ＳＩＰクライアント１−１は、ＯＫメッセージを受信し、これの応答としてＡＣＫメッセージを送信する場合、そのヘッダ内のＶｉａパラメータおよびＲｅｃｏｒｄパラメータを設定するが、Ｖｉａパラメータへの設定値は、その前に受信したＯＫメッセージのＶｉａパラメータに設定されていた値（ＵＲＬリスト）と同じである。また、Ｒｅｃｏｒｄパラメータへの設定値は、受信したＯＫメッセージのＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されていたＵＲＬリストを、その並び順が逆になるように並び替えたものである。したがって、ＳＩＰクライアント１−１は、受信したＯＫメッセージのヘッダ内のＶｉａパラメータに設定されていたＩＤを、ＡＣＫメッセージのヘッダ内のＶｉａパラメータに設定するとともに、受信したＯＫメッセージのヘッダ内のＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されていたＩＤと、そのＩＤが示すＵＲＬリストを逆転する（順番が逆になるように並び替える）ことを指示するコード（もしくは文字列：図５では一例として「Reverse」と記載している）をＡＣＫメッセージのヘッダ内のＲｅｃｏｒｄパラメータに設定し、ノード３−１経由でプロキシ２−１へ送信する。

ノード３−１は、ＳＩＰクライアント１−１からメッセージを受信した場合、まず、そのヘッダ内に設定されている各ＩＤに対応するＵＲＬリストを、記憶しておいたＵＲＬリストの中から特定する。次に、受信メッセージのＶｉａパラメータについては、そこに設定されているＩＤを上記特定したＵＲＬリストの中の対応するＵＲＬリストに置き換え、一方、Ｒｅｃｏｒｄパラメータについては、そこに設定されているＩＤを上記特定したＵＲＬリストの中の対応するＵＲＬリストを逆転させたもの（順番が逆になるように並び替えたもの）に置き換えた後、プロキシ２−１へ転送する。

また、通信を終了する際のＢＹＥメッセージを受信した場合、ＳＩＰクライアント１−１は、受信したＢＹＥメッセージのＶｉａパラメータに設定されていたＩＤを、ＯＫメッセージのＶｉａパラメータに設定して送信する。ノード３−１は、受信したＯＫメッセージのＶｉａパラメータに設定されていたＩＤを、それに対応する設定値（ＵＲＬリスト）に置き換えた後、プロキシ２−１へ転送する。

このように、本実施の形態の無線通信システムでは、ＳＩＰクライアントが、あるＵＲＬリストを含んだ第１のＳＩＰメッセージを受信し、その応答メッセージとして、受信したＵＲＬリストを逆転させて得られたＵＲＬリスト（順番が逆になるように並び替えて得られたＵＲＬリスト）を含んだ第２のＳＩＰメッセージを送信するシーケンスを実行する場合、第１のＳＩＰメッセージを送信するノードは、ＵＲＬリストをＩＤに置き換えた第１のＳＩＰメッセージをＳＩＰクライアントへ送信し、第１のＳＩＰメッセージを受信したＳＩＰクライアントは、受信メッセージに含まれていたＩＤを第２のＳＩＰメッセージに設定するとともに、当該ＩＤに対応するＵＲＬリストを逆転させる旨の指示情報を設定し、この第２のＳＩＰメッセージを受信したノードは、それに含まれているＩＤに対応したＵＲＬリストを指示内容に従って変形し、得られた変形後のＵＲＬリストを当該ＩＤに代えて設定した上で対向するプロキシへ転送することとした。これにより、あるＳＩＰメッセージおよびその応答メッセージに設定するＵＲＬリストが同一ではなく、順番が逆転したＵＲＬリストとなっている場合であっても、冗長パラメータ（ＵＲＬリスト）を圧縮してＳＩＰ圧縮効率を向上させることができる。

なお、本実施の形態で示した制御動作は、実施の形態１で示した制御動作と並行して実施可能（組み合わせることが可能）である。

実施の形態３．
つづいて、実施の形態３について説明する。なお、本実施の形態の無線通信システムの構成は、上述した実施の形態１と同様である。図６は、実施の形態３の無線通信システムにおけるＳＩＰシグナリングの一例を示すシーケンス図であり、上記図２で示したシーケンスと同様に、図１に示したＳＩＰクライアント１−１からＳＩＰシグナリングを開始する場合の例を示している。なお、図６は、特に、本実施の形態の無線通信システムにおいてＳＩＰメッセージの圧縮・伸張制御を実行する区間に位置しているＳＩＰクライアント１−２、プロキシ２−２およびノード３−２に注目し、これらの間で実行されるシーケンスを示している。以下に、本実施の形態の無線通信システムにおけるシグナリング制御動作を図１および図６に基づいて説明する。なお、実施の形態１または２と重複する部分については説明を省略する。

本実施の形態では、ＳＩＰクライアント１−２がＲｉｎｇｉｎｇメッセージを送信する際に、そのＶｉａパラメータとして、ＩＮＶＩＴＥメッセージで受信したＶｉａパラメータ（ＵＲＬリスト）をベースに、リストの一番上のＵＲＬに対して「received=192.0.2.222」という文字列を追加する場合の制御動作について説明する。

受信したＩＮＶＩＴＥメッセージのＶｉａパラメータに設定されたＵＲＬリストの一番上のＵＲＬに対して「received=192.0.2.222」という文字列を追加して得られた情報をＲｉｎｇｉｎｇメッセージのＶｉａパラメータに設定して送信する場合、ＳＩＰクライアント１−２は、ＲｉｎｇｉｎｇメッセージのＶｉａパラメータに対して、ＩＮＶＩＴＥメッセージで通知されたＩＤ（ＩＮＶＩＴＥメッセージのＶｉａパラメータに設定されていたＩＤ）と、当該ＩＤに対応するＵＲＬリストの最初のＵＲＬに文字列を追加することを指示するコード（もしくは文字列：図６では一例として「＋」と記載している）と、追加文字列（図６では「recv=192.0.2.222」と記載している）と、を設定してプロキシ２−２宛に送信する。ノード３−２は、上記Ｒｉｎｇｉｎｇメッセージを受信すると、まず、そのＶｉａパラメータに設定されたＩＤに対応するＵＲＬリストを記憶しておいたＵＲＬリストの中から特定する。次に、受信したＲｉｎｇｉｎｇメッセージのＶｉａパラメータに設定されていたＩＤを上記特定したＵＲＬリストに置き換え、さらに、当該受信メッセージに含まれていた指示情報および追加文字列に従い、置き換えたＵＲＬリストの先頭に文字列を追加した後、プロキシ２−２へ転送する。

以上のような手法を用いることで、受信したＳＩＰメッセージに含まれていたＵＲＬリストを設定し、このＵＲＬリストに対してさらに所定の文字列を追加したＳＩＰメッセージを送信するシーケンスを実行する場合においても、冗長パラメータを削除することができ、ＳＩＰ圧縮効率を向上させることができる。

このように、本実施の形態の無線通信システムでは、ＳＩＰクライアントが、あるＵＲＬリスト含んだ第１のＳＩＰメッセージを受信し、受信したＵＲＬリストの最初のＵＲＬに文字列を追加して得られたＵＲＬリストを含んだ第２のＳＩＰメッセージを送信するシーケンスを実行する場合、第１のＳＩＰメッセージを送信するノードは、ＵＲＬリストをＩＤに置き換えた第１のＳＩＰメッセージをＳＩＰクライアントへ送信し、第１のＳＩＰメッセージを受信したＳＩＰクライアントは、受信メッセージに含まれていたＩＤを第２のＳＩＰメッセージに設定するとともに、当該ＩＤに対応するＵＲＬリストの最初のＵＲＬに対して文字列を追加する旨の指示情報および追加する文字列を設定し、この第２のＳＩＰメッセージを受信したノードは、それに含まれているＩＤに対応したＵＲＬリストを指示内容に従って変形し、得られた変形後のＵＲＬリストを当該ＩＤに代えて設定した上で対向するプロキシへ転送することとした。これにより、ＳＩＰクライアントが受信したＳＩＰメッセージに含まれていたＵＲＬリストを設定し、このＵＲＬリストに対してさらに所定の文字列を追加したＳＩＰメッセージをプロキシへ送信するシーケンスを実行する場合においても、冗長パラメータ（ＵＲＬリスト）を圧縮してＳＩＰ圧縮効率を向上させることができる。

なお、本実施の形態で示した制御動作は、実施の形態１や実施の形態２で示した制御動作と並行して実施可能（組み合わせることが可能）である。

実施の形態４．
つづいて、実施の形態４について説明する。なお、本実施の形態の無線通信システムの構成は、上述した実施の形態１と同様である。図７は、実施の形態４の無線通信システムにおけるＳＩＰシグナリングの一例を示すシーケンス図であり、上記図２で示したシーケンスと同様に、図１に示したＳＩＰクライアント１−１からＳＩＰシグナリングを開始する場合の例を示している。なお、図７は、特に、本実施の形態の無線通信システムにおいてＳＩＰメッセージの圧縮・伸張制御を実行する区間に位置しているＳＩＰクライアント１−２、プロキシ２−２およびノード３−２に注目し、これらの間で実行されるシーケンスを示している。本実施の形態では、実施の形態１、２または３と重複する部分については説明を省略する。

実施の形態１において図２を用いて示したように、ＳＩＰクライアント間で送信されるＩＮＶＩＴＥメッセージのＶｉａパラメータに設定されたＵＲＬリストは、発信者となるＳＩＰクライアント（図２の例ではＳＩＰクライアント１−１）のＵＲＬを含み、このＵＲＬはリストの最後に設定されている。

そのため、本実施の形態のシグナリング制御動作では、ノード３−２およびＳＩＰクライアント１−２は、以下に示す動作を実行することにより、ノード３−２が必要とするメモリ容量を削減する。

図７に示したように、本実施の形態のＳＩＰシグナリングでは、ノード３−２は、プロキシ２−２から受信したＩＮＶＩＴＥメッセージをＳＩＰクライアント１−２へ転送する場合、そのＶｉａパラメータに設定された情報（ＵＲＬリスト）の中の発信者となるＳＩＰクライアントのＵＲＬ（以下、「発信者ＵＲＬ」と記載する）を除いたＵＲＬリストをＩＤに置き換える（図７では一例として「＃1＋SIP/2.0/TCP Client1-1 URL:5060;branch=z9hg4bk74bf9;received=192.0.2.101」に置き換えている）。さらに、Ｖｉａパラメータ以外のパラメータ（Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータ）については、実施の形態１と同様に、設定された情報（ＵＲＬリスト）のすべてをＩＤに置き換える。また、ＩＤに置き換えたＵＲＬリストは、ＩＤと対応付けて記憶しておく。なお、図７では、Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータの記載を省略している。

また、ＳＩＰクライアント１−２は、ＩＮＶＩＴＥメッセージ受信時に、それに含まれる上記ＩＤとＵＲＬ文字列（発信者ＵＲＬ）を記憶する。そして、ＳＩＰクライアント１−２は、Ｒｉｎｇｉｎｇメッセージを送信する場合、そのＶｉａパラメータにはＩＮＶＩＴＥメッセージ受信時に記憶しておいたＩＤとＵＲＬ文字列を設定する。なお、図示するのを省略しているが、ＲｉｎｇｉｎｇメッセージのＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータには、ＩＮＶＩＴＥメッセージ受信時に記憶しておいたＩＤ（ＩＮＶＩＴＥメッセージのＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されていたＩＤ）を設定する。このＳＩＰクライアント１−２の動作は、基本的に実施の形態１で示したＳＩＰクライアント１−２の動作と同じである。すなわち、いずれの動作においても、受信したＩＮＶＩＴＥメッセージのＶｉａパラメータおよびＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されていた情報を記憶しておき、Ｒｉｎｇｉｎｇメッセージを送信する際には、そのＶｉａパラメータおよびＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに対して、ＩＮＶＩＴＥメッセージ受信時に記憶しておいた情報を設定する。

ノード３−２は、ＳＩＰクライアント１−２からＲｉｎｇｉｎｇメッセージを受信した場合、まず、そのヘッダ内のＶｉａパラメータおよびＲｅｃｏｒｄ−Ｒｏｕｔｅパラメータに設定されているＩＤに対応するＵＲＬリストを、記憶しておいたＵＲＬリストの中から特定する。次に、受信メッセージのヘッダに設定されているＩＤを上記特定したＵＲＬリストに置き換え、さらにＶｉａパラメータについては、受信したＲｉｎｇｉｎｇメッセージのＶｉａパラメータに設定されていた発信者ＵＲＬを設定した後、プロキシ２−２へ転送する。

このように、本実施の形態の無線通信システムでは、ＳＩＰメッセージを圧縮した上で転送するノードは、ＳＩＰメッセージを受信した場合、それに含まれているＶｉａパラメータについては発信者ＵＲＬを除いたＵＲＬリストをＩＤに置き換え、また、その他の情報（Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータ）については、ＵＲＬリストすべてをＩＤに置き換えた上で転送することとした。これにより、ノードで管理するＵＲＬリストの中の文字列からＳＩＰクライアントを表現する部位（ＳＩＰクライアントのＵＲＬ）が取り除かれ、ＳＩＰメッセージを圧縮するノードは、中継するプロキシのＵＲＬのみを管理することとなる。そのため、ノードにおいては、管理するＵＲＬリストの文字列が、収容している複数のＳＩＰクライアントで共通になる可能性が高くなる。この結果、ノードが管理するＵＲＬリスト情報量が少なくなり、ノードが必要とするメモリ容量を削減できる。

なお、本実施の形態では、ＶｉａパラメータへＩＤとともに記載するＵＲＬ文字列の一例として「SIP/2.0/TCP Client1-1 URL:5060;branch=z9hg4bk74bf9;received=192.0.2.101」を示したが（図７参照）、このように、ＵＲＬ文字列には、実際のＵＲＬを示す文字列だけでなく、SIP/2.0/TCPといったプロトコルを表現する文字列、ｂｒａｎｃｈなどのオプションが記載可能である。すなわち、Ｖｉａパラメータを圧縮する（ＩＤに置き換える）際に対象とするＵＲＬ文字列は、ＵＲＬを含んだ一般的な文字列を意味する。

このような手法を用いることで、ＵＲＬリストのＵＲＬ部に各種オプションが付与されていても、冗長パラメータを削除することができ、ＳＩＰ圧縮効率を向上させることができる。

また、本実施の形態で示した制御動作は、実施の形態１の変形例であるが、実施の形態２や実施の形態３で示した制御動作と並行して実施可能（組み合わせることが可能）である。

実施の形態５．
つづいて、実施の形態５について説明する。上述した実施の形態の無線通信システムにおいてＳＩＰメッセージの圧縮を行う各ノードは、図４に示した手法で圧縮処理の対象情報（Ｖｉａパラメータ，Ｒｅｃｏｒｄ−Ｒｏｕｔｅパラメータ，Ｒｅｃｏｒｄパラメータ）であるＵＲＬリストを管理することとしたが、本実施の形態では、これとは異なる管理方法について説明する。

図４に示した手法では、各ノードにおいて、たとえばＳＩＰメッセージの圧縮処理を実行するＳＩＰ圧縮部がＵＲＬリストとＩＤの一元管理を行っている。しかし、基地局制御装置などではＳＩＰプロトコルは意識しないものの結果的にＳＩＰクライアントと１：１に対応するコネクションを管理する部位が存在している。たとえば、ユーザごとの無線リソースを管理する部位などである。この部位では無線コネクション情報をＳＩＰクライアントに対応させて管理していることになる。このような場合、ＵＲＬリストを無線コネクション情報と対応付けて管理することができ、ＩＤは一つのＳＩＰクライアントの中でユニークにアサインすればよくなる。たとえば図８に示したように、ノード３−２は、すでに保持している各ＳＩＰクライアント（ＳＩＰクライアント１−２ａ，１−２ｂ，１−２ｃ）との間の無線コネクションの管理情報（図示した無線コネクション情報ａ，無線コネクション情報ｂ，無線コネクション情報ｃ）に対応付けてＵＲＬリストのＩＤを管理することにより、値が同じＩＤの複数利用が可能になる。図８に示したような圧縮対象パラメータの管理方法を適用した場合、図４に示した手法を適用した場合と比較して、ＩＤの値が大きくなるのを防止できる。

ＵＲＬリストとＩＤの対応表は非常に大きくなるケースがあり、このような場合、図４に示した、コネクション（セッション）を意識せずにＵＲＬリストとＩＤを管理する手法では、ＳＩＰクライアントから受信したＳＩＰメッセージ内のＩＤに対応する情報（ＵＲＬリスト）を検索して特定する処理に時間を要するという問題が発生する。しかしながら、図８で示した管理方法を用いると、無線コネクションさえ特定できれば、ターゲットとするＵＲＬリストを短時間で特定することができるので、上記のような問題が発生するのを防止できる。

なお、各実施の形態ではＳＩＰのＶｉａ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅ、Ｒｅｃｏｒｄパラメータを例に説明を行ったが、使用方法がこれらと同様のパラメータであれば、同様の手法で圧縮することが可能である。また、各実施の形態では無線通信システムにおける例を示したが、有線通信システムであってもよく、無線通信システムと同様の効果を奏する。

以上のように、各実施の形態で示した通信システムによれば、ＳＩＰプロトコルの意味を知らないノードがＳＩＰメッセージ圧縮を行う場合であっても、冗長なＳＩＰパラメータの削除と復元が可能になり、より大きなＳＩＰメッセージ圧縮効率を達成することができる。たとえば、プロキシ（ＳＩＰプロキシ）を２０個経由するような構成のネットワークでは、一つのプロキシを表現するＵＲＬが２０文字であるとすると、Ｖｉａ、Ｒｅｃｏｒｄ−ＲｏｕｔｅのＵＲＬリストは各々４００バイトとなり、この二つのパラメータが存在するだけで８００バイトを要する。一方、ＳＩＰメッセージの他のパートはより小さく、ＳＩＰメッセージのサイズの観点ではこのＵＲＬリストが支配的になってくる。本発明ではこのＵＲＬリストをサイズの小さい識別情報（上述したＩＤ）に置き換えるため、大きな圧縮効率を実現できる。

以上のように、本発明にかかる通信システムは、情報伝送量を削減したＳＩＰシグナリングを実現する場合に有用であり、特に、基地局制御装置や基地局などＳＩＰプロトコルを終端しないノードにおいてＳＩＰメッセージの圧縮および伸張を行い、より高い圧縮効率を実現する場合に適している。

１−１、１−２、１−２ａ、１−２ｂ、１−２ｃ ＳＩＰクライアント（ＳＩＰ Ｃｌｉｅｎｔ）
２−１、２−２ プロキシ（Ｐｒｏｘｙ）
３−１、３−２ ノード

Claims (10)

1. ＳＩＰクライアント、当該ＳＩＰクライアントのプロキシ、および当該ＳＩＰクライアントと当該プロキシの間に位置し、受信したＳＩＰメッセージを中継するノードを含んだ通信システムであって、
   前記ノードは、
   前記ＳＩＰクライアント宛のＳＩＰメッセージを中継する場合、受信したＳＩＰメッセージの特定のパラメータに設定されている管理情報をその内容を一意に示すＩＤに置き換え、また当該ＩＤと当該管理情報とを関連付けて記憶し、一方、前記ＳＩＰクライアントから送信されたＳＩＰメッセージでありかつその特定のパラメータに前記記憶したＩＤと同じＩＤが設定されたＳＩＰメッセージを中継する場合、当該ＩＤをこれに関連付けられた管理情報に置き換え、
   前記ＳＩＰクライアントは、
   受信したＳＩＰメッセージの特定のパラメータに前記ＩＤが設定されている場合、当該パラメータと当該ＩＤとを関連付けて記憶し、また、当該記憶したパラメータと同じパラメータを含んだＳＩＰメッセージを送信する場合、当該パラメータに対して、これに関連付けられたＩＤを設定する
   ことを特徴とする通信システム。
2. 前記管理情報を、前記ＳＩＰクライアント宛のＳＩＰメッセージが通過してきた経路上の各プロキシのＵＲＬ、および当該ＳＩＰメッセージの発行元のＵＲＬ、のリストとすることを特徴とする請求項１に記載の通信システム。
3. 前記管理情報を、前記ＳＩＰクライアント宛のＳＩＰメッセージが通過してきた経路上の各プロキシのＵＲＬのリストとすることを特徴とする請求項１に記載の通信システム。
4. 前記管理情報を、前記ＳＩＰクライアント宛のＳＩＰメッセージが通過してきた経路上の各プロキシのＵＲＬをそれぞれ含む複数の文字列、および当該ＳＩＰメッセージの発行元のＵＲＬを含む文字列、のリストとすることを特徴とする請求項１に記載の通信システム。
5. 前記管理情報を、前記ＳＩＰクライアント宛のＳＩＰメッセージが通過してきた経路上の各プロキシのＵＲＬをそれぞれ含む複数の文字列のリストとすることを特徴とする請求項１に記載の通信システム。
6. 前記ＳＩＰクライアントは、さらに、
   前記ＩＤと関連付けて記憶したパラメータに対応するＵＲＬリストまたは文字列リストの各情報の順番を逆転させて得られたリスト、を設定すべきパラメータを含んだＳＩＰメッセージを送信する場合、送信するＳＩＰメッセージの当該パラメータに対して、前記記憶したパラメータに関連付けられたＩＤ、および当該ＩＤを対応するリストに置き換えた後にそのリスト内の各情報の順番を逆転させるように指示する指示情報、を設定し、
   前記ノードは、
   特定のパラメータに前記記憶したＩＤと同じＩＤおよび前記指示情報が設定されたＳＩＰメッセージを前記ＳＩＰクライアントから受信した場合、当該受信メッセージに設定されているＩＤを、これに関連付けられたリストの各情報の順番を逆転させて得られたリストに置き換えて転送する
   ことを特徴とする請求項２〜５のいずれか一つに記載の通信システム。
7. 前記ＳＩＰクライアントは、
   前記記憶したパラメータと同じパラメータを含んだＳＩＰメッセージを送信する場合、当該パラメータに対して、これに関連付けられたＩＤを設定し、さらに必要に応じて、当該ＩＤに関連付けて記憶されているリストの所定位置に文字列を追加するように指示する文字列追加指示情報を設定し、
   前記ノードは、
   特定のパラメータに、前記記憶したＩＤと同じＩＤおよび前記文字列追加指示情報が設定されたＳＩＰメッセージを前記ＳＩＰクライアントから受信した場合には、当該ＩＤをこれに関連付けられたリストに置き換え、さらに、当該指示情報により指示された位置へ指定された文字列を追加し、得られたＳＩＰメッセージを転送する
   ことを特徴とする請求項２〜６のいずれか一つに記載の通信システム。
8. 前記ノードは、前記管理情報をその内容を一意に示すＩＤと関連付けて記憶するにあたって、さらに、これらの情報を前記ＳＩＰクライアントのコネクション情報と対応付けて記憶することを特徴とする請求項１〜７のいずれか一つに記載の通信システム。
9. 請求項１〜８のいずれか一つに記載のノードとして動作することを特徴とする通信装置。
10. 請求項１〜８のいずれか一つに記載のＳＩＰクライアントとして動作することを特徴とする通信装置。

Images