JP2008113151A - 通信方法及び装置 - Google Patents

Abstract

【課題】ＲＴＰアプリケーションによらず、ＵＤＰチェックサムの伝送におけるオーバーヘッドを削減することができる通信方法及び装置を提供する。
【解決手段】データを取得するクライアントＰＣ１３と、クライアントＰＣ１３が取得した取得データに応じて、当該データを圧縮するか否かを判断するパケットフィルタ２９と、パケットフィルタ２９による判断の結果、取得データを圧縮する場合には、当該データに応じて、当該データのヘッダ情報に含まれるチェックサムを省略することができるＵＤＰチェックサム除去部３４と、ＵＤＰチェックサム除去部３４によりチェックサムが省略されたデータを送信する無線通信部１８とを含む。
【選択図】図３

Description

本発明は、通信方法及び装置に関し、特に、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：ＩＰ）に基づく通信方法及び装置に関する。

従来、送信機側から受信機側にデータを伝達させる通信技術は様々に考案されているが、昨今では、パケット指向や送信先の自由度等の理由でＩＰに基づく方法が好んで選択されている。
また、伝送の目的が音声や動画等のメディアパケット伝送である場合は、ＩＰパケットを下位層としてユーザデータグラムプロトコル（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ：ＵＤＰ）、更に、その上位層の通信方法としてリアルタイムトランスポートプロトコル（Ｒｅａｌ ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ：ＲＴＰ）が好んで用いられる。

ＲＴＰ／ＵＤＰ／ＩＰを用いたメディアパケット伝送は、デファクトスタンダードとなっており、多くの運用共通性確保のために本方法を選択せざるを得ない場合が多いにもかかわらず、オーバーヘッドが比較的大きくなってしまう。
ＲＴＰ／ＵＤＰ／ＩＰのオーバーヘッドを減らして、より狭い帯域しか持たない伝送経路上でメディアパケットを透過させるための方法として、例えば、「ヘッダ圧縮方法及び装置並びにプログラム」（特許文献１参照）や「圧縮ヘッダデータを送信する方法、装置、およびシステム」（特許文献２参照）等、幾つかのパケットヘッダ圧縮方法が考案されており、その中に、ロバストヘッダコンプレッション（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ：ＲＯＨＣ）がある。

ＲＯＨＣは、連続するパケット間におけるＲＴＰ／ＵＤＰ／ＩＰヘッダの整合性に着目し、既に送信した情報で不変な情報、類推可能な情報、計算により求まる情報は、繰り返し送信せず、類推可能な情報を類推するための情報と、類推不可能、且つ、毎回変わる情報を送信することにより、送信すべきパケットヘッダ情報を圧縮する。ここで、類推不可能、且つ、毎回変わる情報は、ＲＯＨＣ（ＲＦＣ３０９５）のプロファイル１（ＲＴＰプロファイル）ではＵＤＰヘッダにおけるチェックサムのみとなる。ＲＴＰプロファイルでは、通常、ＵＤＰチェックサムが有効な場合、毎回送信が必要となる。

ＲＯＨＣのＲＴＰプロファイルでは、ＵＤＰヘッダにおけるチェックサムが使用抑制されている場合、ＵＤＰチェックサムの送信を省略する。
ＵＤＰでは、ＵＤＰチェックサム情報要素フィールドがオールゼロの場合、受信側でＵＤＰチェックサムを用いた照合を行わない規定となっている。
特開２００２−２０４２６０号公報 特開２００３−３０４２９９号公報

上述した、従来の通信システムにおいて、任意のＲＴＰアプリケーションデータの透過を目標とする場合、通常、ＵＤＰチェックサムの使用を望むか抑制するかを決定するのはＲＴＰアプリケーションであり、伝送経路上では制御することができない。
しかしながら、狭帯域でＲＴＰアプリケーションデータを透過させたい要求は依然として存在し、この場合におけるＵＤＰチェックサムの２バイトを削除できるか否かは大きく影響する。

Ｇ７２９Ａ（８ｋｂｐｓ）コーディックを用いた場合、１ＩＰパケットに２コーディックペイロードを載せる設定では、２０ｍｓｅｃ毎にＲＴＰパケットが流通することになるが、ＵＤＰチェックサムを使用する場合、スループットに換算して０．８Ｋｂｐｓに相当し約１割のオーバーヘッド増加となる。
無線を用いたＩＰパケットの伝送経路では、帯域が９．６Ｋｂｐｓ程度しか確保できない場合がごく普通に起こるため、０．８ｋｂｐｓのオーバーヘッドは無視できず、このオーバーヘッドを削除することが望まれる。
本発明の目的は、ＲＴＰアプリケーションによらず、ＵＤＰチェックサムの伝送におけるオーバーヘッドを削減することができる通信方法及び装置を提供することである。

上記目的を達成するため、本発明に係る通信方法は、送信装置と受信装置との間で行われるデータの通信方法であって、前記送信装置がデータを取得するデータ取得ステップと、前記取得したデータに応じて、当該データを圧縮するか否かを判断する判断ステップと、判断の結果、前記データを圧縮する場合には、当該データに応じて、当該データのヘッダ情報に含まれるチェックサムを省略するようにするチェックサム省略ステップと、チェックサムを省略したチェックサム省略データを前記受信装置に送信する送信ステップと、前記受信装置が前記チェックサム省略データを受信する受信ステップと、受信した前記チェックサム省略データに基づいてデータ復元を行う復元ステップとを含むことを特徴としている。

また、本発明は、前記チェックサム省略ステップにおいて、前記データのデータ伝送量に応じ、当該データのヘッダ情報に含まれるチェックサムを省略するようにすることが好ましい。
また、本発明は、前記チェックサム省略ステップにおいて、前記データのデータ伝送量が、現在の通信帯域における許容伝送量に基づいた基準伝送量を超える場合に、当該データのヘッダ情報に含まれるチェックサムを省略することが好ましい。
また、本発明は、前記チェックサム省略ステップにおいて、前記データを圧縮した後のデータ伝送量が、現在の通信帯域における許容伝送量に基づいた基準伝送量を超える場合に、当該データのヘッダ情報に含まれるチェックサムを省略することが好ましい。

また、本発明に係る通信装置は、データを取得するデータ取得手段と、前記データ取得手段が取得した取得データに応じて、当該データを圧縮するか否かを判断する判断手段と、前記判断手段による判断の結果、前記取得データを圧縮する場合には、当該データに応じて、当該データのヘッダ情報に含まれるチェックサムを省略することができるチェックサム省略手段と、前記チェックサム省略手段によりチェックサムが省略されたデータを送信する送信手段とを含むことを特徴としている。

本発明によれば、ＲＴＰアプリケーションによらず、ＵＤＰチェックサムの伝送におけるオーバーヘッドを削減することができる。

以下、本発明を実施するための最良の形態について図面を参照して説明する。
図１は、本発明の一実施の形態に係る無線端末装置を用いた無線通信システムの概略構成を示す説明図である。図１に示すように、無線端末装置（通信装置）１０を用いた無線通信システム１１は、無線端末装置１０と無線により接続された無線基地局１２、無線端末装置１０に接続されたクライアントＰＣ（Ｃｌｉｅｎｔ Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）１３、クライアントＰＣ１３に接続された音声通話器１４、無線基地局１２にインターネットを介して接続されたＳＩＰサーバ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｓｅｒｖｅｒ）１５、対向ＳＩＰ電話機１６、及び無線基地局１２に接続されたＰＤＳＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｓｅｒｖｉｎｇ Ｎｏｄｅ）１７を有している。

音声通話器１４は、昨今、市販されているＶｏＩＤ通話用の電話機であり、受話用のスピーカ、送話用のマイク、及び各種操作用のキーパット、クライアントＰＣ１３との接続のためのＵＳＢインターフェース等を備えている。
クライアントＰＣ１３は、ＰＰＰｏＥクライアント（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ Ｃｌｉｅｎｔ）として機能し、イーサネット（登録商標）（Ｅｔｈｅｒｎｅｔ（登録商標））経由で無線端末装置１０と接続する。

無線端末装置１０は、ＰＰＰｏＥサーバ機能を有し、ＰＰＰｏＥからの接続要求を受け付ける。つまり、無線端末装置１０は、無線基地局１２と無線リンクにより接続し、クライアントＰＣ１３からのＰＰＰパケットをＰＤＳＮ１７まで伝達する。ＰＤＳＮ１７は、ＰＰＰサーバ及びＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバとしての機能を有し、クライアントＰＣ１３からのＰＰＰ接続要求を受け付けると共に、グローバルＩＰアドレスをクライアントＰＣ１３に渡す。クライアントＰＣ１３は、グローバルＩＰアドレスを用いてインターネットに接続する。

クライアントＰＣ１３には、ＳＩＰに対応したＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アプリケーションがインストールされており、ＳＩＰを介して、ＳＩＰサーバ１５及び対向ＳＩＰ電話機１６と通信を行う。クライアントＰＣ１３からの呼接続要求が、ＳＩＰサーバ１５の導きにより対向ＳＩＰ電話機１６と接続された後、クライアントＰＣ１３にＵＳＢ Ｉ／Ｆ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ ｉｎｔｅｒｆａｃｅ）により接続された音声通話器１４のスピーカ及びマイクを用いて、対向ＳＩＰ電話機１６との音声通話が実現する。音声コーディックは、Ｇ７２９Ａ（８Ｋｂｐｓ）を用いることとする。

図２は、図１の無線通信システムを用いたＶｏＩＰ通話時のプロトコルスタック変遷過程の一例を表により示した説明図である。図２に示すように、無線通信システム１１を用いてＶｏＩＰ通話を行っているとき、クライアントＰＣ１３は、マイクから得た音声データをＧ７２９コーディックによりデジタルデータに変換し、ＲＴＰ／ＵＤＰ／ＩＰパケットに梱包する。クライアントＰＣ１３のＰＰＰｏＥクライアントは、ＲＴＰ／ＵＤＰ／ＩＰパケットをＰＰＰｏＥ／ＩＰパケットにカプセリングし、イーサネットをリンクチャネルに用いて無線端末装置１０に送信する。

無線端末装置１０は、ＰＰＰｏＥパケットをエンカプセルした後、ＲＴＰ／ＵＤＰ／ＩＰの各ヘッダをＲＯＨＣ圧縮し、無線プロトコルを用いて無線基地局１２に伝送する。無線基地局１２は、無線端末装置１０から受信したデータから、Ａ１０／ＧＲＥ（Ｇｅｎｅｒａｌ Ｒｏｕｔｉｎｇ Ｅｎｃａｐｓｕｌａｔｉｏｎ）パケットを構築する。この際、ＲＯＨＣ圧縮されているＲＯＨＣパケットからＲＴＰ／ＵＤＰ／ＩＰパケットに展開する。Ａ１０／ＧＲＥパケットは、イーサネットをリンクチャネルに用いてＰＤＳＮ１７に伝達される。

図３は、図１の無線端末装置の内部構造を示すブロック図である。図３に示すように、無線端末装置１０は、無線通信部１８、送信バッファ１９、ＲＯＨＣ圧縮部２０、送信チャネルコンテキスト保持部２１、変調クラス制御部２２、変調クラス設定閾値保持部２３、受信パケットバッファ２４、ＰＰＰ判定部２５、ＲＯＨＣ展開部２６、受信チャネルコンテキスト保持部２７、ＰＰＰパケット構築部２８、パケットフィルタ２９、ＰＰＰパケット抽出処理部３０、ＰＰＰｏＥパケット構築部３１、ＰＣ Ｉ／Ｆ部３２、及びチェックサム書換部３３を有している。
チェックサム書換部３３は、ＵＤＰチェックサム除去部３４、圧縮後パケットサイズ予測部３５、及び切替スイッチ３６を有している。

ＰＣ Ｉ／Ｆ部３２は、イーサネットからイーサネットパケットを受信する働きを持つ。ＰＣ Ｉ／Ｆ部３２から受信したイーサネットパケットは、ＰＰＰｏＥパケットであるので、ＰＰＰパケット抽出処理部３０により、ＰＰＰパケットにエンカプセルされる。クライアントＰＣ１３は、ＰＰＰｏＥパケットのプロトコル種別をＩＰパケットとしている。パケットフィルタ２９は、ＰＰＰパケットの各ヘッダ情報を参照することにより、ＲＯＨＣ圧縮が必要なパケットであるか否かを判定する。一般に、ＩＰヘッダのプロトコルフィールド、ＲＴＰパケットのペイロード種別等を参照することにより、圧縮目的のパケットか否かを判定することが可能である。

このパケットフィルタ２９は、ＰＰＰパケットがＲＯＨＣ圧縮対象パケットであると判断した場合、ＰＰＰパケットのプロトコル種別をＲＯＨＣプロトコルに書き換え、ＲＯＨＣ圧縮部２０により圧縮を行なう。また、パケットフィルタ２９は、ＰＰＰパケットがＲＯＨＣ圧縮対象パケットではないと判断した場合、ＰＰＰのプロトコル種別をＩＰのまま書き換えず、ＲＯＨＣ圧縮部２０を透過させない（非圧縮のまま）。そして、何れの場合も、ＰＰＰパケットは、送信バッファ１９に格納され、順次、無線基地局１２に送信される。

次に、チェックサム書換部３３について説明する。ＰＰＰパケットの処理に関し、パケットフィルタ２９が、ＰＰＰパケットの内容を参照してＲＯＨＣ圧縮が必要なパケットか否かを判定し、ＲＯＨＣ圧縮が必要な場合は、ＰＰＰのプロトコル種別をＲＯＨＣプロトコルに書き換える。ここまでは、チェックサム書換部３３を設けていない場合と同じであるが、チェックサム書換部３３の切替スイッチ３６がオンである場合、若しくは圧縮後パケットサイズ予測部３５が、予測した圧縮後パケットサイズと現在の無線通信部１８が提供する帯域との比較結果から圧縮率を高める必要があると判断した場合、ＵＤＰチェックサム除去部３４により、ＵＤＰヘッダにおけるチェックサムをオールゼロに書き換える。

このような制御を行うことにより、設定に応じてＵＤＰチェックサムをオールゼロに書き換えることができる。ＵＤＰチェックサムがオールゼロである場合、ＲＯＨＣ圧縮部２０は、ＵＤＰチェックサム２バイトの送信を省略する。よって、無線端末装置１０から送信されるＲＯＨＣパケットは２バイト分少なくなり、帯域を節約することができる。
ここで、チェックサム書換部３３の切替スイッチ３６による、ＵＤＰチェックサムの使用を抑制するか抑制しないかの切り替え処理について、図４を参照して説明する。

図４は、本発明に係る無線端末装置による送信処理の流れを示すフローチャートである。図４に示すように、クライアントＰＣ１３からの受信があると、先ず、ＰＰＰｏＥパケットからＰＰＰパケットを構成する（ステップＳ１０１）。その後、構成したＰＰＰパケットがＲＯＨＣ圧縮適合パケットか否かを判断し（ステップＳ１０２）、判断の結果、ＲＯＨＣ圧縮適合パケットである（ｙｅｓ）場合、ＰＰＰのプロトコル種別をＲＯＨＣに変更する（ステップＳ１０３）。

次に、切替スイッチ３６がオン（ＯＮ）か否かを判断する（ステップＳ１０４）。判断の結果、切替スイッチ３６がオンである（ｙｅｓ）場合、ＵＤＰヘッダのチェックサム部分をオールゼロに変更し（ステップＳ１０５）、その後、ＲＯＨＣ圧縮処理を行う（ステップＳ１０６）。一方、切替スイッチ３６がオンでない（ｎｏ）場合、そのままＲＯＨＣ圧縮処理を行う（ステップＳ１０６）。
なお、切替スイッチ３６は、ＶｏＩＰ通話時にオンになるように設定されるが、この場合、パケットフィルタ２９でＶｏＩＰ用のパケットを把握することにより、オン状態となるように設定しても良い。

ＲＯＨＣ圧縮処理の後、ＲＯＨＣ圧縮処理されたＰＰＰパケットを送信バッファ１９に格納する（ステップＳ１０７）。また、ステップＳ１０２での判断の結果、ＲＯＨＣ圧縮適合パケットでない（ｎｏ）場合、ＰＰＰのプロトコル種別はＩＰのまま変更しない（ステップＳ１０８）で、ＰＰＰパケットを送信バッファ１９に格納する（ステップＳ１０７）。
その後、無線通信部１８による送信処理を行う。

また、ＵＤＰチェックサムの使用を抑制するか抑制しないかの切り替え処理を、チェックサム書換部３３の切替スイッチ３６によるのではなく、現在選択されている変調クラスの帯域と圧縮後のデータ量とを比較して行っても良い。現在選択されている変調クラスの帯域と圧縮後のデータ量とを比較して切り替え処理を行う場合を、図５に示す。
図５は、本発明に係る無線端末装置による送信処理の流れの他の例を示すフローチャートである。図５に示すように、クライアントＰＣ１３からの受信があると、先ず、ＰＰＰｏＥパケットからＰＰＰパケットを構成する（ステップＳ２０１）。その後、構成したＰＰＰパケットがＲＯＨＣ圧縮適合パケットか否かを判断し（ステップＳ２０２）、判断の結果、ＲＯＨＣ圧縮適合パケットである（ｙｅｓ）場合、ＰＰＰのプロトコル種別をＲＯＨＣに変更する（ステップＳ２０３）。

次に、ＲＯＨＣ圧縮前に圧縮サイズを予想する圧縮前サイズ予想処理を行い（ステップＳ２０４）、予想したサイズと現在帯域を比較した結果、圧縮すれば予想サイズ内であるか否かを判断する（ステップＳ２０５）。判断の結果、予想サイズ内である（ｙｅｓ）場合、ＵＤＰヘッダのチェックサム部分をオールゼロに変更し（ステップＳ２０６）、その後、ＲＯＨＣ圧縮処理を行う（ステップＳ２０７）。一方、予想サイズ内でない（ｎｏ）場合、そのままＲＯＨＣ圧縮処理を行う（ステップＳ２０７）。
ＲＯＨＣ圧縮処理の後、ＲＯＨＣ圧縮処理されたＰＰＰパケットを送信バッファ１９に格納する（ステップＳ２０８）。また、ステップＳ２０２での判断の結果、ＲＯＨＣ圧縮適合パケットでない（ｎｏ）場合、ＰＰＰのプロトコル種別はＩＰのまま変更しない（ステップＳ２０９）で、ＰＰＰパケットを送信バッファ１９に格納する（ステップＳ２０８）。

その後、無線通信部１８による送信処理を行う。
ここで、圧縮前サイズ予想処理（ステップＳ２０４）は、圧縮後パケットサイズ予測部３５により行われるが、処理に際し、ＲＯＨＣ圧縮部２０が送信チャネルコンテキスト保持部２１の情報を用いて、一度、ＲＯＨＣ圧縮を行う。この処理によって、圧縮後のパケットサイズを得ることができる。現在の変調クラスの帯域は、変調クラス制御部２２からの情報を参照することにより行う。なお、変調クラス毎のスループットは、例えば、図６に示すデータに従う。

図６は、上り変調クラス毎のスループットを表にして示す説明図である。図６に示すように、変調クラス（ＭＯＤ Ｃｌａｓｓ）１〜８に対応する、変調方法及びコーディングレート（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｒａｔｅｓ）、アップリンクスループット（Ｕｐｌｉｎｋ Ｔｈｒｏｕｇｈｐｕｔ）としてＭＡＣペイロードサイズ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｐａｙｌｏａｄ Ｓｉｚｅ）（ｂｉｔｓ）とスループット（Ｔｈｒｏｕｇｈｐｕｔ）（ｂｐｓ）が示されている。
変調クラス毎にＭＡＣペイロードサイズが導かれるが、これは５ｍｓｅｃ毎のスループットになるので４倍すると、２０ｍｓｅｃ（Ｇ７２９Ａコーディックを２コーディックペイロード／１ＲＴＰパケット）に換算した値が導かれる。これにマージンを加えた値との比較を行い、十分ではない場合、ＵＤＰチェックサムの使用抑制を行うようにする。

上述したように、この発明に係る、無線端末装置１０は、データを取得するデータ取得手段（クライアントＰＣ１３）と、データ取得手段が取得した取得データに応じて、当該データを圧縮するか否かを判断する判断手段（パケットフィルタ２９）と、判断手段による判断の結果、取得データを圧縮する場合には、当該データに応じて、当該データのヘッダ情報に含まれるチェックサムを省略することができるチェックサム省略手段（ＵＤＰチェックサム除去部３４）と、チェックサム省略手段によりチェックサムが省略されたデータを送信する送信手段（無線通信部１８）とを有している。

また、この発明に係る通信方法は、送信装置と受信装置との間で行われるデータの通信方法であって、送信装置がデータを取得するデータ取得ステップと、取得したデータに応じて、当該データを圧縮するか否かを判断する判断ステップと、判断の結果、データを圧縮する場合には、当該データに応じて、当該データのヘッダ情報に含まれるチェックサムを省略するようにするチェックサム省略ステップと、チェックサムを省略したチェックサム省略データを受信装置に送信する送信ステップと、受信装置がチェックサム省略データを受信する受信ステップと、受信した前記チェックサム省略データに基づいてデータ復元を行う復元ステップとを含む。

従って、ＲＴＰアプリケーションによらず、ＵＤＰチェックサムの伝送オーバーヘッドを削減することができる。

また、ＵＤＰチェックサムの使用抑制をユーザの操作に基づいて選択可能にすることにより、ユーザは、ＵＤＰチェックサムが不要であるアプリケーション（本実施の形態では、ＶｏＩＰアプリケーション）では、経路上においてＵＤＰチェックサムの使用を抑制する設定として、狭い帯域でのデータ伝送を実現させ、ＵＤＰチェックサムが必須であるアプリケーションでは、経路上においてＵＤＰチェックサムの使用抑制を行わない設定とすることが、可能になる。

ここで、ＵＤＰチェックサムの使用抑制を行う場合とは、例えば、ヘッダ圧縮後のデータ量が経路における帯域を越えてしまうような場合であるので、可変帯域である伝送経路で帯域がデータ量に対して少なくなった場合に、自動的にＵＤＰチェックサムの使用抑制が働くよう制御することにより、ユーザに煩わしい設定を強要すること無く圧縮率の向上を行い、狭い帯域でのデータ伝送効率を上げることができる。

上述した機能を、可変帯域において、ＲＯＨＣの圧縮後のパケットサイズが帯域に比較して比較的大きくなり問題を生じる場合に設定することで、ＵＤＰチェックサムの使用抑制を行わない場合は、そもそも十分なパケット透過が望めない場合に限定することができ、可変帯域において帯域が狭くなった場合における帯域の増加と近似した効果を得ることができる。
なお、本発明は、上述した実施の形態により説明したが、この実施の形態に限定されるものではない。従って、本発明の趣旨を逸脱することなく変更態様として実施するものも含むものである。

本発明の一実施の形態に係る無線端末装置を用いた無線通信システムの概略構成を示す説明図である。 図１の無線通信システムを用いたＶｏＩＰ通話時のプロトコルスタック変遷過程の一例を表により示した説明図である。 図１の無線端末装置の内部構造を示すブロック図である。 本発明に係る無線端末装置による送信処理を示すフローチャートである。 本発明に係る無線端末装置による送信処理の他の例を示すフローチャートである。 上り変調クラス毎のスループットを表にして示す説明図である。

符号の説明

１０ 無線端末装置
１１ 無線通信システム
１２ 無線基地局
１３ クライアントＰＣ
１４ 音声通話器
１５ ＳＩＰサーバ
１６ 対向ＳＩＰ電話機
１７ ＰＤＳＮ
１８ 無線通信部
１９ 送信バッファ
２０ ＲＯＨＣ圧縮部
２１ 送信チャネルコンテキスト保持部
２２ 変調クラス制御部
２３ 変調クラス設定閾値保持部
２４ 受信パケットバッファ
２５ ＰＰＰ判定部
２６ ＲＯＨＣ展開部
２７ 受信チャネルコンテキスト保持部
２８ ＰＰＰパケット構築部
２９ パケットフィルタ
３０ ＰＰＰパケット抽出処理部
３１ ＰＰＰｏＥパケット構築部
３２ ＰＣ Ｉ／Ｆ部
３３ チェックサム書換部
３４ ＵＤＰチェックサム除去部
３５ 圧縮後パケットサイズ予測部
３６ 切替スイッチ

Claims (5)

1. 送信装置と受信装置との間で行われるデータの通信方法であって、
   前記送信装置がデータを取得するデータ取得ステップと、
   前記取得したデータに応じて、当該データを圧縮するか否かを判断する判断ステップと、
   判断の結果、前記データを圧縮する場合には、当該データに応じて、当該データのヘッダ情報に含まれるチェックサムを省略するようにするチェックサム省略ステップと、
   チェックサムを省略したチェックサム省略データを前記受信装置に送信する送信ステップと、
   前記受信装置が前記チェックサム省略データを受信する受信ステップと、
   受信した前記チェックサム省略データに基づいてデータ復元を行う復元ステップと
   を含むことを特徴とする通信方法。
2. 前記チェックサム省略ステップにおいて、
   前記データのデータ伝送量に応じ、当該データのヘッダ情報に含まれるチェックサムを省略するようにすることを特徴とする請求項１に記載の通信方法。
3. 前記チェックサム省略ステップにおいて、
   前記データのデータ伝送量が、現在の通信帯域における許容伝送量に基づいた基準伝送量を超える場合に、当該データのヘッダ情報に含まれるチェックサムを省略することを特徴とする請求項１に記載の通信方法。
4. 前記チェックサム省略ステップにおいて、
   前記データを圧縮した後のデータ伝送量が、現在の通信帯域における許容伝送量に基づいた基準伝送量を超える場合に、当該データのヘッダ情報に含まれるチェックサムを省略することを特徴とする請求項１に記載の通信方法。
5. データを取得するデータ取得手段と、
   前記データ取得手段が取得した取得データに応じて、当該データを圧縮するか否かを判断する判断手段と、
   前記判断手段による判断の結果、前記取得データを圧縮する場合には、当該データに応じて、当該データのヘッダ情報に含まれるチェックサムを省略することができるチェックサム省略手段と、
   前記チェックサム省略手段によりチェックサムが省略されたデータを送信する送信手段と
   を含むことを特徴とする通信装置。

Images