JP2008141254A - 通信方法及び送信装置並びに受信装置 - Google Patents

Abstract

【課題】ネットワークトラフィックが上昇することなく、また、ＲｏＨＣサーバを跨いだハンドオーバを行った際にも、通話品質が著しく落ちることがない通信方法及び送信装置並びに受信装置を提供する。
【解決手段】送信装置がパケットを順次取得し、取得したパケットのヘッダ情報に時間を示すタイムスタンプが含まれているとタイムスタンプを削除し、削除圧縮されたパケットを順次受信装置へ送信し、受信圧縮パケットの種類毎に対応付けられた周波数・当該圧縮パケットのデータ長に基づきタイムスタンプ増加値を算出し、初期タイムスタンプとタイムスタンプ増加度の加算値を新規タイムスタンプとし受信圧縮パケットの種類毎の先頭に付加し、以降に順次受信される圧縮パケットにタイムスタンプ増加値を加算したものを新規タイムスタンプとして順次付加し、付加圧縮パケットを復元する、各ステップを含む。
【選択図】図１

Description

本発明は、通信方法及び送信装置並びに受信装置に関し、特に、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）無線システム上でＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を使用した音声通信を行う通信方法及び送信装置並びに受信装置に関する。

現在、ＩＰ無線システム上でＲＴＰ（Ｒｅａｌ ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）を用いてＶｏＩＰアプリケーションを行う場合、無線リソースの低減を図るための技術が検討されている。それは、ＲＴＰパケットヘッダが、音声データに比べ大きくなる傾向があることから考えられている問題である。そこで、無線リソースの低減を行うことを考えて、パケットヘッダ圧縮技術の検討が盛んに行われている。
以下、パケットヘッダ圧縮技術の代表格であるＲｏＨＣ（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）について説明する。

ＲｏＨＣは、主にワイヤレス環境でＶｏＩＰを使用した場合に、上記の問題を解決するために定められたプロトコルであり、ＶｏＩＰパケットの音声データ以外の部分（ＩＰ／ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）／ＲＴＰヘッダ部分）で、変化の生じない部分（スタテック：ｓｔａｔｉｃ）や、「変化が予想可能な部分」を圧縮することにより、ＶｏＩＰパケットのデータサイズを軽減しようとするものである。
ＲｏＨＣのコンプレッサ／デコンプレッサは、ＩＰ／ＵＤＰ／ＲＴＰヘッダ部分で、変化の生じない部分（スタテック）や「変化が予想可能な部分」を、自装置の内部に保持、更新し（これらをコンテキスト情報と呼ぶ）、必要最低限の情報（チェックサム：ＣｈｅｃｋＳＵＭ等変化の予想がつかないデータ）だけを送受信することによって、トラッフィックの負荷を低減するシステムである。

コンテキスト情報では、ＲＴＰパケットのそれぞれの情報（バージョン情報、タイムスタンプ情報、シーケンス情報等）において管理しておき、それぞれの情報に誤りが発生していることが判明した場合は、即座に圧縮率を低下させ、送信するパケットサイズを大きくしている。それにより、ＲｏＨＣが伸張するパケットにおいて誤解や誤りをなくし、円滑なネットワークを提供している。
ここで、ＲｏＨＣによって圧縮されるＩＰ／ＵＤＰ／ＲＴＰヘッダにおいて、各ヘッダのパラメータ詳細と、その中でＲｏＨＣによって圧縮されるＩＰ／ＵＤＰ／ＲＴＰヘッダにおいて、各ヘッダのパラメータ詳細と、その中で「変化が予想可能な部分」を以下に示す。

図１０は、ＩＰパケットのＩＰヘッダフォーマットを示す説明図である。図１１は、ＩＰパケットのＩＰヘッダを詳細に示す説明図である。図１２は、ＵＤＰパケットのＵＤＰヘッダフォーマットを示す説明図である。図１３は、ＵＤＰパケットのＵＤＰヘッダを詳細に示す説明図である。図１４は、ＲＴＰパケットのＲＴＰヘッダフォーマットを示す説明図である。図１５は、ＲＴＰパケットのＲＴＰヘッダを詳細に示す説明図である。なお、ＲＴＰパケットは、ＵＤＰペイロードに含まれ、ＲＴＰヘッダとＲＴＰペイロードから成る。
（クラスの説明）

ＩＮＦＥＲＲＥＤ：他の値や、フレームキャリーなどによって、予測可能なもの。
ＳＴＡＴＩＣ：変化しない情報。
ＳＴＡＴＩＣ−ＤＥＦ：パケットストリームを定義する情報。通常ＳＴＡＴＩＣとして扱う。
ＳＴＡＴＩＣ−ＫＮＯＷＮ：既知（Ｗｅｌｌ−Ｋｎｏｗｎ）のもので、コミュニケーションには必要としない情報（ヘッダ長等）。
ＣＨＡＮＧＩＮＧ：変化する情報。
（ＣＨＡＮＧＩＮＧクラスのパターン）

ＳＴＡＴＩＣ：ＣＨＡＮＧＩＮＧとして規定されたが、ある追加の仮定によりＳＴＡＴＩＣとして定義されるフィールド。
ＳＥＭＩＳＴＡＴＩＣ：通常ＳＴＡＴＩＣだが、時々変化する（変化した値は元に戻る）。
ＲＡＲＥＬＹ−ＣＨＡＮＧＩＮＧ（ＲＣ）：時々変化する（変化後の値を保持する）。
ＡＬＴＥＲＮＡＴＩＮＧ：少ない範囲の数値で変化する。
ＩＲＲＥＧＵＬＡＲ：有用な変更パターンが識別することができないフィールド。

図１６は、従来のＶｏＩＰ使用時のＩＰ無線システムの説明図である。図１６に示すように、ＩＰ無線システム１は、スピーカ、マイク及びキーパッドを備えた携帯電話機２、携帯電話機２が接続された、ＶｏＩＰアプリケーションを格納したクライアントＰＣ３、クライアントＰＣ３が接続された無線端末装置４、無線端末装置４と無線でリンクされた無線基地局５、無線基地局５に接続されたＰＤＳＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｓｅｒｖｉｎｇ Ｎｏｄｅ）６、無線基地局５にインターネットを介して接続されたＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバ７及びＳＩＰ電話機８を有している。

図１７は、従来のＶｏＩＰ使用時のプロトコル変遷例の説明図である。図１７に示すように、携帯電話機２とＰＤＳＮ６の間で、無線端末装置４及び無線基地局５を介して、プロトコルが変遷する。
以下、ＲｏＨＣパケットからＲＴＰパケットへの再構築について説明する。先ず、前提としてＲＴＰ／ＵＤＰ／ＩＰヘッダ（ｈｅａｄｅｒ）は、それぞれコンプレッサ（ｃｏｍｐｒｅｓｓｏｒ）により圧縮が施された後、コンプレッサからデコンプレッサ（ｄｅｃｏｍｐｒｅｓｓｏｒ）に伝送される。伝送される情報は、ｃｏｍｐｒｅｓｓｏｒ／ｄｅｃｏｍｐｒｅｓｓｏｒ双方でコンテキスト（ｃｏｎｔｅｘｔ）と言う情報領域に格納する。

ここで、コンテキスト情報を以下のように分類する。
連続するパケット間で、通常において値が不変なフィールド→スタティックコンテキスト（ｓｔａｔｉｃ ｃｏｎｔｅｘｔ）
スタティックコンテキスト：一度伝送が完了すると、フィールドの内容に変更が生じるか内容が疑わしくなるまでは再送信する必要が無く、一度の伝送でコンテキスト情報が確立される（ＩＰアドレスやバージョン情報等）。

連続するパケット間で、一定のルールによって値が変化することにより推測可能なフィールド→ダイナミックコンテキスト（ｄｙｎａｍｉｃ ｃｏｎｔｅｘｔ）
ダイナミックコンテキスト：コンプレッサとデコンプレッサが同期を取れていると信じるに足る間は、同期用の情報のみを伝送すればよい（ＲＴＰタイムスタンプやＲＴＰシーケンス番号等）。
残るは、不規則に変化し、値の推定が不可能なフィールドのみが毎回伝送する情報（ＵＤＰチェックサム等）。予測が不可能であるため、コンテキストの確立が不可能であり、データとして送信しなければならない。
以上、コンテキストを三種類に分類する。

つまり、コンテキストが完全であれば、３つ目に示している、同期情報と値が推定不可能な情報のみ伝送すれば、デコンプレッサ側でＲＴＰ／ＵＤＰ／ＩＰパケットの再生が可能になる。
図１８は、コンテキストが完全な場合にＲｏＨＣを受信した場合におけるデコンプレッサの動作の模式図である。
このような、従来のパケットヘッダ圧縮技術として、例えば、「ヘッダ圧縮方法及び装置並びにプログラム」（特許文献１参照）が知られている。
特開２００２−２０４２６０号公報

上述したように、無線通信にて音声通話を実現する際、ＲＴＰがよく使用されているが、ＲＴＰパケットは、音声データに比べてパケットヘッダサイズが大きいといわれており、ＲＴＰで音声通話を行うことはトラフィックの上昇に繋がっていた。そこで、この問題を解決するために、ＲｏＨＣに代表されるヘッダ圧縮技術を用いて、ネットワークトラフィックを抑え音声品質の向上に繋げることが考えられている。

しかしながら、ＲｏＨＣを用いても通信状況が悪い状態では、予想に反しトラフィックが上昇することもあり、また、ＲｏＨＣサーバを跨いだハンドオーバを行った際には、通話品質が著しく落ちることが問題視されていた。
本発明の目的は、ネットワークトラフィックが上昇することなく、また、ＲｏＨＣサーバを跨いだハンドオーバを行った際にも、通話品質が著しく落ちることがない通信方法及び送信装置並びに受信装置を提供することである。

上記目的を達成するため、本発明に係る通信方法は、送信装置から受信装置へ、パケットを順次圧縮して送信し、前記受信装置が前記圧縮されたパケットを受信して復元する通信方法において、前記送信装置が、パケットを順次取得するパケット取得ステップと、取得した前記パケットのヘッダ情報に時間を示す値であるタイムスタンプが含まれているか否かを判断するステップと、前記判断の結果、前記データのヘッダ情報にタイムスタンプが含まれている場合には、当該タイムスタンプを削除するステップと、前記タイムスタンプが削除され、かつ、圧縮されたパケットを、順次前記受信装置へ送信するステップと、前記受信装置が、前記圧縮パケットを受信するステップと、前記受信された圧縮パケットの種類毎に対応付けられた周波数、及び当該圧縮パケットのデータ長に基づいて、タイムスタンプにおける加算値を算出するステップと、前記受信された圧縮パケットについて、当該圧縮パケットの種類毎の先頭の圧縮パケットに対しては、任意の時間を示す初期値に、前記加算値を加算した値を示すタイムスタンプを付加し、前記先頭の圧縮パケット以降に順次受信される圧縮パケットに対しては、前記タイムスタンプの値に、前記加算値を順次加算した値でそれぞれ示されるタイムスタンプを順次付加するようにするステップと、前記タイムスタンプが付加された圧縮パケットを復元するステップと、を含むことを特徴としている。

また、本発明は、前記パケットにはシーケンス番号が付加され、前記受信装置は、前記シーケンス番号を含む圧縮パケットを受信した場合には、シーケンス番号が加算されるごとに、前記タイムスタンプを付加するようにすることが好ましい。
また、本発明は、前記受信装置が、前記シーケンス番号を含む圧縮パケットを受信した場合には、当該圧縮パケットを所定数保持するステップと、保持された所定数の圧縮パケットを前記シーケンス番号順に並べ替えるステップと、を更に含み、前記並べ替えられた圧縮パケットについて、順次前記タイムスタンプを付加するようにすることが好ましい。

また、本発明に係る送信装置は、受信装置へ、パケットを順次圧縮して送信する送信装置において、パケットを順次取得するパケット取得手段と、取得した前記パケットのヘッダ情報にタイムスタンプが含まれているか否かを判断する送信側の判断手段と、前記判断の結果、前記データのヘッダ情報に時間を示す値であるタイムスタンプが含まれている場合には、当該タイムスタンプを削除するタイムスタンプ削除手段と、前記タイムスタンプが削除され、かつ、圧縮されたパケットを、順次前記受信装置へ送信する送信手段と、を含むことを特徴としている。

また、本発明に係る受信装置は、送信装置から、順次圧縮されたパケットを受信し、受信した圧縮パケットを復元する受信装置において、前記送信装置から送信された圧縮パケットを受信する受信手段と、受信した圧縮パケットについて、タイムスタンプが含まれているか否かを判断する受信側の判断手段と、前記受信された圧縮パケットの種類毎に対応付けられた周波数、及び当該圧縮パケットのデータ長に基づいて、タイムスタンプ増加値を算出する算出手段と、前記受信された圧縮パケットについて、当該圧縮パケットの種類毎の先頭の圧縮パケットに対しては、任意の時間を示す初期値に、前記加算値を加算した値を示すタイムスタンプを付加し、前記先頭の圧縮パケット以降に順次受信される圧縮パケットに対しては、前記タイムスタンプの値に、前記加算値を順次加算した値でそれぞれ示されるタイムスタンプを順次付加するようにする付加手段と、を含むことを特徴としている。

本発明によれば、ネットワークトラフィックが上昇することなく、また、ＲｏＨＣサーバを跨いだハンドオーバを行った際にも、通話品質が著しく落ちることがない。

以下、本発明を実施するための最良の形態について図面を参照して説明する。
図１は、本発明の一実施の形態に係るＶｏＩＰ使用時のＩＰ無線システムにおけるＲｏＨＣについて示す概略説明図である。図１に示すように、ＶｏＩＰ使用時のＩＰ無線システムを構成する、送信装置であるユーザターミナル（ＵＴ）（ＲｏＨＣクライアント）１０と無線でリンクされた、受信装置である基地局（ＢＳ）１１の間において、ＲｏＨＣによるＲＴＰパケットの圧縮が行われる。
ＵＴ１０は、ＶｏＩＰアプリケーションを格納したＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）１２がＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）接続されており、ＢＳ１１は、ブロードバンド接続されたＲｏＨＣサーバ（ルータ）１３、更に、ＰＤＳＮ１４を介してインターネットに接続されている。

図２は、図１のＩＰ無線システムの送信装置と受信装置の概略構成を示すブロック図である。図２に示すように、ＵＴ１０は、パケットをＲｏＨＣにより順次圧縮して、ＢＳ１１へ送信する。このＵＴ１０は、パケットを順次取得するパケット取得手段１５と、取得したパケットのヘッダ情報にタイムスタンプが含まれているか否かを判断する送信側の判断手段１６と、判断の結果、データのヘッダ情報にタイムスタンプが含まれている場合には、当該タイムスタンプを削除するタイムスタンプ削除手段１７と、タイムスタンプが削除され、かつ、圧縮されたパケットを、順次ＢＳ１１へ送信する送信手段１８とを含んでいる。

ＢＳ１１は、ＵＴ１０から、順次、圧縮されたパケットを受信し、受信した圧縮パケットを復元する。このＢＳ１１は、ＵＴ１０から送信された圧縮パケットを受信する受信手段１９と、受信した圧縮パケットについて、タイムスタンプが含まれているか否かを判断する受信側の判断手段２０と、受信された圧縮パケットの種類毎に対応付けられた周波数、及び当該圧縮パケットのデータ長に基づいて、タイムスタンプ増加値を算出する算出手段２１と、任意の初期値で示された初期タイムスタンプとタイムスタンプ増加値とを加算した値を新規タイムスタンプとして、当該新規タイムスタンプを、受信された圧縮パケットの種類毎の先頭の圧縮パケットに付加するようにする第１の付加手段２２と、先頭の圧縮パケット以降に順次受信される圧縮パケットに、タイムスタンプ増加値を加算したものを新規タイムスタンプとして順次付加するようにする第２の付加手段２３とを含んでいる。

本発明に係る通信方法は、単独でも用いることができるが、主に、ＲｏＨＣを支援するための機能と捉えることができる。そこで、ＲｏＨＣについて説明する。
（ＲｏＨＣの概要）
ＲｏＨＣのコンプレッサ（Ｃｏｍｐｒｅｓｓｏｒ）／デコンプレッサ（Ｄｅｃｏｍｐｒｅｓｓｏｒ）は、ＩＰ／ＵＤＰ／ＲＴＰヘッダ部分で、変化の生じない部分（ｓｔａｔｉｃ）や変化が予想可能な部分を、自装置の内部に保持、更新し（これらをコンテキスト情報と呼ぶ）、必要最低限の情報（チェックサム等、変化の予想がつかないデータ）だけを送受信することによって、トラッフィックの負荷を低減するシステムである。

コンテキスト情報では、ＲＴＰパケットのそれぞれの情報（バージョン情報、タイムスタンプ情報、シーケンス情報等）において管理しておき、それぞれの情報に誤りが発生していることが判明した場合は、即座に圧縮率を低下させ、送信するパケットサイズを大きくしている。それにより、ＲｏＨＣが伸張するパケットにおいて誤解や誤りを無くし、円滑なネットワークを提供している。
本発明は、このＲｏＨＣを支援するための機能と位置づける。

ＲｏＨＣでは、ＲＴＰパケットをパラメータ独自のエンコーディング方式を用いて圧縮を試みる。そのため、コンプレッサ／デコンプレッサ間において、パラメータ別に要求されることがある。その中でもタイムスタンプは、通常は比例的に数値が上昇していくものであるが、サンプリングのタイミングの違いなどで比例的に上昇していく中でも、増分がことなることがある。その場合に、ＲｏＨＣでは、タイムスタンプのパラメータをコンプレッサ／デコンプレッサ間においてやり取りせねばならず、大きなオーバヘッドに繋がっていた。

そこで、本発明では、このタイムスタンプの再交渉を発生させないため、タイムスタンプに、予めコンプレッサとデコンプレッサにおいて異なった発生周期を持たせることにより、音声通話を実現させる方法を提案している。つまり、送信側と受信側とで異なったタイムスタンプ情報をやり取りさせている。この方法を用いることで、ＲｏＨＣのオーバヘッドも減少するため、本発明とＲｏＨＣとを組み合わせることで、より音声品質の向上に繋がることが見込まれる。

ＲＴＰタイムスタンプは、通常、ＲＴＰパケットの正確なスケジューリングのために用いられる情報であり、音声がサンプリングされた瞬間に生成される数値である。具体的には、ＲＴＰパケットの送信時刻を示す。そのため、パケットがばらばらに到着したときであったとしても、この情報を元に並べ替えることができることになる。よって、送信側と受信側とで電話のような音声通話であれば、タイムスタンプを数値まで同じにする必要がなくなり、到着したパケットを並び替えることができればよいことになる。その性質を主に利用している。

本発明の具体的な方法は、先ず、ＲｏＨＣクライアントに対し通常通りにＲＴＰパケット圧縮を行い、その圧縮されたＲｏＨＣパケットの種類よりタイムスタンプ情報が付加されている場合には、その情報を記録し削除する。一方、ＲｏＨＣサーバでは、タイムスタンプ情報が一切届かないが、タイムスタンプフィルタの機能により、ＲｏＨＣサーバにパケットを受信させる前に、タイムスタンプを生成し付加させる。
このとき、ＲｏＨＣクライアントで削除したタイムスタンプとＲｏＨＣサーバで付加したタイムスタンプ情報が、原則として異なっている。そのため、自由なタイムスタンプの編集が可能になる。そして、続くＲｏＨＣパケットに対しては、ＲＴＰのペイロードフォーマットからサンプリング周期を計算し、比例的に上昇するタイムスタンプの数値を計算し、付加又は削除していく。

ＲｏＨＣプロトコル上では、複数のパケットタイプを持ち、タイムスタンプが付加されているパケットの種類は決まっているため、その情報を基に、タイムスタンプをフィルタ情報に用いてタイムスタンプを削除する。
また、タイムスタンプフィルタでは、ＲｏＨＣパケットを複数個保持した上で、タイムスタンプを付与することにしている。これは、パケットの到達順はシーケンス番号により並べ替え、それにより、タイムスタンプを付加していく情報の正確性をより正しいものにする。
（タイムスタンプフィルタの概要）

図３は、クライアントとサーバの間でのパケットのやり取りを示す説明図である。図３に示すように、二つのＲｏＨＣ（クライアントとサーバ）間で、圧縮ＲＴＰパケット（Ｃｏｍｐｒｅｓｓｅｄ ＲＴＰ Ｐａｃｋｅｔ）がやり取りされる。これにより、ＲＴＰタイムスタンプフィルタ（クライアント側とサーバ側）がどのような形で挿入されているか、直ぐに分かるようになっている。
図４は、圧縮されたＲＴＰパケットがＲＴＰタイムスタンプフィルタ機能により変遷する様子の説明図である。なお、図において、パケットは、ＲｏＨＣ ＩＲ パケットのダイナミックチェイン（Ｄｙｎａｍｉｃ Ｃｈａｉｎ）部分である。

図５は、各ブロックの機能を表にして示す説明図である。図５に示すように、各ブロックは以下に示す機能を有している。
コンプレッサは、受信したＲＴＰパケットのヘッダをＲｏＨＣパケットに圧縮するブロックであり、ＩＰ／ＵＤＰ／ＲＴＰヘッダを最低３バイトまで圧縮する。
デコンプレッサは、受信したＲｏＨＣパケットをＲＴＰパケットに伸張するブロックである。
ＲＴＰタイムスタンプフィルタは、圧縮ＲＴＰパケットをフィルタにかけて、タイムスタンプの編集を行う。タイムスタンプ込みの圧縮ＲＴＰパケットであった場合は、タイムスタンプの削除を行い、タイムスタンプ抜きの圧縮ＲＴＰパケットであった場合は、タイムスタンプの追加を行う。

コンテキストは、コンプレッサ／デコンプレッサのそれぞれによって、圧縮、伸張に必要なＲｏＨＣ情報源である。
（タイムスタンプフィルタ機能）
図６は、タイムスタンプフィルタによる処理を示すフローチャートである。図６に示すように、先ず、最初のＩＲパケットよりシーケンス番号（シーケンスナンバ）を取得する（ステップＳ１０１）。次に、パケットを送信されているＲｏＨＣ最下位ビット（Ｌｅｓｓ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｉｔ：ＬＳＢ）と、取得したシーケンス番号を元に、パケットを並び替える（ステップＳ１０２）。

その後、ＲｏＨＣパケットにタイムスタンプ情報が付加されているか否かを判断する（ステップＳ１０３）。判断の結果、タイムスタンプ情報が付加されている（ｙｅｓ）場合、タイムスタンプ情報を削除し（ステップＳ１０４）、初のＲｏＨＣパケットであるか否かを判断する（ステップＳ１０５）。
ステップＳ１０５での判断の結果、初のＲｏＨＣパケットである（ｙｅｓ）場合、タイムスタンプの初期値をランダムに計算した（ステップＳ１０６）後、ペイロードフォーマットからサンプリング周期を計算する（ステップＳ１０７）。一方、初のＲｏＨＣパケットでない（ｎｏ）場合、ペイロードフォーマットからサンプリング周期を計算する（ステップＳ１０７）。サンプリング周期を計算した後、付加すべきタイムスタンプを計算し（ステップＳ１０８）、得られたタイムスタンプを付与して（ステップＳ１０９）、処理を終了する。

一方、ステップＳ１０３での判断の結果、タイムスタンプ情報が付加されていない（ｎｏ）場合、処理を終了する。
つまり、タイムスタンプが付加されているＲＴＰパケットは、ＲＴＰタイムスタンプを削除し、その他のモジュールに移す。また、タイムスタンプが削除されているＲＴＰパケットについては、ＲＴＰタイムスタンプを付加して、その他のモジュールに移す。但し、付加するタイムスタンプは、初めて付加するＲＴＰパケットにはランダム数値を付加し、それ以降のパケットについては、シーケンス番号が挙がる毎にＲＴＰペイロードフォーマット基準に従った増分を行うこととする。なお、付加するタイムスタンプの正確性を増すために、バッファにパケットを複数蓄え、シーケンス番号を元にソートを行った後にタイムスタンプを付加することにする。

本発明では、背景として音声通信を行うこととしているため、バッファ容量として大きな容量はとることはないと考えている。
ここで、ＲＴＰタイムスタンプの付与方法の一例について説明する。
タイムスタンプフィルタ機能を用いてタイムスタンプを削除しているが、削除したタイムスタンプを付加させる方法は、いくつか考えられる。そこで、それに対する一例を以下に示す。
図７は、ＲＴＰタイムスタンプの増分を計算するために必要なペイロードフォーマットテーブルを示す説明図である。

タイムスタンプフィルタ機能によりタイムスタンプが削除されたパケットを検出すると、図７に示すテーブルとペイロードタイプを用いて、それぞれのエンコードに対応したサンプリング周波数を検索する。そして、その周波数とペイロードの長さを用いて、タイムスタンプ周期を計算する。具体的には、以下のような式を用いることでタイムスタンプ周期の計算を行う。
タイムスタンプ周期
＝サンプリング＊（ペイロード長／使用ＣＯＤＥＣ標準フレームレート固定値）

この計算式によりタイムスタンプ周期を計算し、得られたタイムスタンプ周期に基づいて、それぞれのパケットに対し適切なタイムスタンプを付加させていく。つまり、付加させるべきタイムスタンプは、
付加させるべきタイムスタンプ＝ランダム初期値＋タイムスタンプ周期
となる。なお、初期値を割り振るのは初回のＲＴＰパケットにおいてのみである。
図８は、ＩＲパケットの構成を示す説明図である。図８に示すように、圧縮ＲＴＰパケットで最も大きいパケットであるＩＲパケットには、ＲＴＰタイムスタンプが含まれている。

また、ＲＴＰパケットバッファリング方式の一例について説明する。
ＲＴＰパケットバッファリング方式では、シーケンス番号を基にしてシーケンス番号が上がる毎に、タイムスタンプを割り振っていくが、長時間の接続では、パケットの欠損や欠落によりリフレッシュを行う必要が出てくる。但し、送受信間において誤差が生じない状況では、リフレッシュさせる必要性が無くなる。
本方式では、以下の仕組みを用いることによりリフレッシュを行う必要性を排除し、送受信間におけるパケットの送信を減少させることにする。以下に、その一例について説明する。

送信、受信とで誤差を無くすために、受信側では、常に、パケットをバッファリングしていくことにする。但し、リアルタイム性が求められることが多いＲＴＰでのバッファリングであるため、バッファリングする量は、ここでは、４ｂｉｔ分、つまり、１６パケット分とする。そして、バッファリングしたパケットは、シーケンス番号順にソートを行い、その順番通りにタイムスタンプを割り振ることにする。
また、パケットの欠損や欠落等により、シーケンス番号に大きな間隔が生じることがあるが、ここでは、前回取得したシーケンス番号よりも小さな値が出てきた時点で、バッファリングを打ち切る仕組みを用いることにより、パケットの欠落や、欠損に対する耐性を強化する。また、パケットロスなどにより、パケット到達時間がとても大きくなる可能性もあるため、タイムアウト処理も追加する。

図９は、タイムアウト処理の流れを示すフローチャートである。図９に示すように、ループ１を開始する（ステップＳ２０１）。このループ１は、タイムアウトが発生するまで繰り返される。開始後、ＲＴＰパケットを取得し（ステップＳ２０２）、シーケンス番号下位４ｂｉｔを検出する（ステップＳ２０３）。検出後、前回取得したシーケンス番号よりも小さいか否かを判断する（ステップＳ２０４）。

判断の結果、前回取得したシーケンス番号よりも小さい（ｙｅｓ）場合、バッファリングしているパケットに対するタイムスタンプフィルタを行う（ステップＳ２０５）。その後、バッファ領域をクリアし（ステップＳ２０６）、ループ１を終了する（ステップＳ２０７）。一方、前回取得したシーケンス番号よりも小さくない（ｎｏ）場合、パケットをバッファリングした（ステップＳ２０８）後、ループ１を終了する（ステップＳ２０７）。ループ１終了後、処理を終了する。

上述したように、本発明に係る通信方法は、送信装置から受信装置へ、パケットを順次圧縮して送信し、受信装置が圧縮されたパケットを受信して復元する通信方法において、送信装置が、パケットを順次取得するパケット取得ステップと、取得したパケットのヘッダ情報にタイムスタンプが含まれているか否かを判断するステップと、判断の結果、データのヘッダ情報にタイムスタンプが含まれている場合には、当該タイムスタンプを削除するステップと、タイムスタンプが削除され、かつ、圧縮されたパケットを、順次受信装置へ送信するステップと、受信装置が、圧縮パケットを受信するステップと、受信された圧縮パケットの種類毎に対応付けられた周波数、及び当該圧縮パケットのデータ長に基づいて、タイムスタンプ増加値を算出するステップと、任意の初期値で示された初期タイムスタンプとタイムスタンプ増加度とを加算した値を新規タイムスタンプとし、当該新規タイムスタンプを、受信された圧縮パケットの種類毎の先頭の圧縮パケットに付加するようにするステップと、先頭の圧縮パケット以降に順次受信される圧縮パケットに、タイムスタンプ増加値を加算したものを新規タイムスタンプとして順次付加するようにするステップと、新規タイムスタンプが付加された圧縮パケットを復元するステップとを含んでいる。

また、本発明に係る通信方法において、パケットにはシーケンス番号が付加され、受信装置は、シーケンス番号を含む圧縮パケットを受信した場合には、シーケンス番号が加算されるごとに、新規タイムスタンプを付加するようにしている。
また、本発明に係る通信方法において、受信装置が、シーケンス番号を含む圧縮パケットを受信した場合には、当該圧縮パケットを所定数保持するステップと、保持された所定数の圧縮パケットをシーケンス番号順に並べ替えるステップと、を更に含み、並べ替えられた圧縮パケットについて、順次新規タイムスタンプを付加するようにしている。

このように、ＶｏＩＰ（ＲＴＰ）を使用した音声通信において、タイムスタンプは、パケットのスケジューリングのために必要なパラメータとされており、本発明では、そのパラメータにおいて、送信側でタイムスタンプを除去し受信側で新たにタイムスタンプを付け加えることで、ネットワーク上においてタイムスタンプを除去することを可能にする。また、タイムスタンプは、送受信間においてパラメータとしての矛盾を起こさないようにするために、バッファリングを行いながら付加している。

即ち、ＲｏＨＣを用いた無線通信において、音声通信を行う場合、帯域を有効利用するためにＲｏＨＣを用いてＲＴＰパケットの圧縮を行うが、ＲｏＨＣは、複数の圧縮されていないパケットを送受信することにより、圧縮する側と復元する側それぞれで、独自の情報を築き上げるという特性上、その情報が信用できなくなった場合に、複数個の圧縮していないパケットを再度やり取りする必要があり、それが大きなオーバヘッドとなっていることが問題視されていた。本発明では、その問題を回避するためにＲＴＰのタイムスタンプ情報をＲｏＨＣの圧縮する側と復元する側とでそれぞれで計算し、ネットワーク上にＲＴＰのタイムスタンプ情報を流さないようにした。
この方法は、ＲＴＰパケットを圧縮するＲｏＨＣなどにも適用でき、ＲｏＨＣを支援するための方式としても活用できるものである。

つまり、本発明のポイントは、
_{１．ＲＴＰのタイムスタンプ情報を、送信する側と受信する側とでそれぞれ独自に作り上げることにより、ネットワーク上にタイムスタンプ情報を流さなくてよくなる点
２．ネットワーク上にタイムスタンプが流れていないため、ハンドオーバなどの影響も少なくなる点}
３．ＲＴＰパケットバッファリング機能を用いることによって、リフレッシュパケットを送受信させる必要が無くなる点
４．ＲｏＨＣ等代表的なＲＴＰパケット圧縮のための既存技術にも適用できる点
等があげられる。

このため、この発明に係る通信方法にあっては、以下の効果を得ることができる。
１．ＲＴＰタイムスタンプをコンプレッサ／デコンプレッサそれぞれ独自で補うため、圧縮前の状態のパケットサイズを小さく保つことができる。
２．ＲｏＨＣといった従来のパケットヘッダ圧縮技術とも関連させることができる。
３．ＲｏＨＣサーバを組み合わせた場合、バースト状態でパケットが損失しても、タイムスタンプを送信しないため、オーバヘッドが小さくなる。
なお、本発明は、上述した実施の形態により説明したが、この実施の形態に限定されるものではない。従って、本発明の趣旨を逸脱することなく変更態様として実施するものも含むものである。

本発明の一実施の形態に係るＶｏＩＰ使用時のＩＰ無線システムにおけるＲｏＨＣについて示す概略説明図である。 図１のＩＰ無線システムの送信装置と受信装置の概略構成を示すブロック図である。 クライアントとサーバの間でのパケットのやり取りを示す説明図である。 圧縮されたＲＴＰパケットがＲＴＰタイムスタンプフィルタ機能により変遷する様子の説明図である。 各ブロックの機能を表にして示す説明図である。 タイムスタンプフィルタによる処理を示すフローチャートである。 ＲＴＰタイムスタンプの増分を計算するために必要なペイロードフォーマットテーブルを示す説明図である。 ＩＲパケットの構成を示す説明図である。 タイムアウト処理の流れを示すフローチャートである。 ＩＰパケットのＩＰヘッダフォーマットを示す説明図である。 ＩＰパケットのＩＰヘッダを詳細に示す説明図である。 ＵＤＰパケットのＵＤＰヘッダフォーマットを示す説明図である。 ＵＤＰパケットのＵＤＰヘッダを詳細に示す説明図である。 ＲＴＰパケットのＲＴＰヘッダフォーマットを示す説明図である。ＲＴＰパケットのＲＴＰヘッダフォーマットを示す説明図である。 ＲＴＰパケットのＲＴＰヘッダを詳細に示す説明図である。 従来のＶｏＩＰ使用時のＩＰ無線システムの説明図である。 従来のＶｏＩＰ使用時のプロトコル変遷例の説明図である。 コンテキストが完全な場合にＲｏＨＣを受信した場合におけるデコンプレッサの動作の模式図である。

符号の説明

１０ ＵＴ
１１ ＢＳ
１２ ＰＣ
１３ ＲｏＨＣサーバ
１４ ＰＤＳＮ
１５ パケット取得手段
１６ 送信側の判断手段
１７ タイムスタンプ削除手段
１８ 送信手段
１９ 受信手段
２０ 受信側の判断手段
２１ 算出手段
２２ 第１の付加手段
２３ 第２の付加手段

Claims (5)

1. 送信装置から受信装置へ、パケットを順次圧縮して送信し、前記受信装置が前記圧縮されたパケットを受信して復元する通信方法において、
   前記送信装置が、パケットを順次取得するパケット取得ステップと、
   取得した前記パケットのヘッダ情報に時間を示す値であるタイムスタンプが含まれているか否かを判断するステップと、
   前記判断の結果、前記データのヘッダ情報にタイムスタンプが含まれている場合には、当該タイムスタンプを削除するステップと、
   前記タイムスタンプが削除され、かつ、圧縮されたパケットを、順次前記受信装置へ送信するステップと、
   前記受信装置が、前記圧縮パケットを受信するステップと、
   前記受信された圧縮パケットの種類毎に対応付けられた周波数、及び当該圧縮パケットのデータ長に基づいて、タイムスタンプにおける加算値を算出するステップと、
   前記受信された圧縮パケットについて、当該圧縮パケットの種類毎の先頭の圧縮パケットに対しては、任意の時間を示す初期値に、前記加算値を加算した値を示すタイムスタンプを付加し、前記先頭の圧縮パケット以降に順次受信される圧縮パケットに対しては、前記タイムスタンプの値に、前記加算値を順次加算した値でそれぞれ示されるタイムスタンプを順次付加するようにするステップと、
   前記タイムスタンプが付加された圧縮パケットを復元するステップと、
   を含むことを特徴とする通信方法。
2. 前記パケットにはシーケンス番号が付加され、
   前記受信装置は、前記シーケンス番号を含む圧縮パケットを受信した場合には、シーケンス番号が加算されるごとに、前記タイムスタンプを付加するようにする、ことを特徴とする請求項１に記載の通信方法。
3. 前記受信装置が、前記シーケンス番号を含む圧縮パケットを受信した場合には、当該圧縮パケットを所定数保持するステップと、
   保持された所定数の圧縮パケットを前記シーケンス番号順に並べ替えるステップと、を更に含み、
   前記並べ替えられた圧縮パケットについて、順次前記タイムスタンプを付加するようにすることを特徴とする請求項２に記載の通信方法。
4. 受信装置へ、パケットを順次圧縮して送信する送信装置において、
   パケットを順次取得するパケット取得手段と、
   取得した前記パケットのヘッダ情報にタイムスタンプが含まれているか否かを判断する送信側の判断手段と、
   前記判断の結果、前記データのヘッダ情報に時間を示す値であるタイムスタンプが含まれている場合には、当該タイムスタンプを削除するタイムスタンプ削除手段と、
   前記タイムスタンプが削除され、かつ、圧縮されたパケットを、順次前記受信装置へ送信する送信手段と、を含むことを特徴とする送信装置。
5. 送信装置から、順次圧縮されたパケットを受信し、受信した圧縮パケットを復元する受信装置において、
   前記送信装置から送信された圧縮パケットを受信する受信手段と、
   受信した圧縮パケットについて、タイムスタンプが含まれているか否かを判断する受信側の判断手段と、
   前記受信された圧縮パケットの種類毎に対応付けられた周波数、及び当該圧縮パケットのデータ長に基づいて、タイムスタンプ増加値を算出する算出手段と、
   前記受信された圧縮パケットについて、当該圧縮パケットの種類毎の先頭の圧縮パケットに対しては、任意の時間を示す初期値に、前記加算値を加算した値を示すタイムスタンプを付加し、前記先頭の圧縮パケット以降に順次受信される圧縮パケットに対しては、前記タイムスタンプの値に、前記加算値を順次加算した値でそれぞれ示されるタイムスタンプを順次付加するようにする付加手段と、を含むことを特徴とする受信装置。