JP4744457B2

JP4744457B2 - 通信方法および通信装置

Info

Publication number: JP4744457B2
Application number: JP2007016726A
Authority: JP
Inventors: 淳加納; 宏和松波
Original assignee: Kyocera Corp
Current assignee: Kyocera Corp
Priority date: 2007-01-26
Filing date: 2007-01-26
Publication date: 2011-08-10
Anticipated expiration: 2027-01-26
Also published as: JP2008187258A

Description

本発明は、通信方法および通信装置に関するものである。

従来、送信機側から受信機側にデータを伝達させる通信技術は、種々の方式のものが提案されているが、近年では、パケット指向や送信先の自由度等の理由でＩＰ（インターネットプロトコル: Internet Protocol : RFC 791 IETF）に基づく方法が好んで選択されている。また、伝送の目的が音声や動画等のメディアパケット伝送目的である場合は、ＩＰパケットを下位層としてＵＤＰ(ユーザダイアグラムプロトコル: User Datagram Protocol : RFC 768 IETF)、更にその上位層の通信方式としてＲＴＰ(リアルタイムトランスポートプロトコル: A Transport Protocol for Real-Time Applications : RFC 1889 IETF)が好んで用いられている。

ＲＴＰ／ＵＤＰ／ＩＰプロトコルを用いたメディアパケット伝送方式は、デファクトスタンダードとなっていることから、多くの運用共通性確保および相互接続互換性のためには、この方式を選択せざるを得ない場合が多い。

ＲＴＰ／ＵＤＰ／ＩＰプロトコルを用いたメディアパケットストリームを、任意のインターネットノード間で接続するためのＩＰベースの回線交換手段として、ＳＩＰ(Session Initiation Protocol : RFC 3261 IETF)プロトコルがあり、今日ではＶｏＩＰ電話やＩＰベースでのＴＶ電話での回線交換用途に広く用いられている。

また、近年では、デジタル通信方式による通信においても、伝送帯域の大容量化が実現されており、高速なワイヤレス通信手段として、多種多様なインターネットアプリケーションデータを透過させることが可能になってきている。このような高速ワイヤレス通信手段の一例として”High Capacity-Spatial Division Multiple Access (HC-SDMA) WTSC- 2005-032(ATIS/ANSI)”が開示されており、この方式に準拠するシステムの一例としてiBurstシステムが知られている。

ところで、一般に、ワイヤレス伝送方式は、有線伝送方式とは異なり、無線状況如何ではトラフィックデータの伝達が必ずしも保証されないという問題を内包している。すなわち、ワイヤレス伝送方式を用いる限り、無線状況の悪化によってデータ伝送が滞ることは避けられず、また、無線状況如何によっては、データ転送の遅滞が長時間に及ぶことも考えられる。

無線の悪化によるパケットの伝達不能は、直ちにデータ紛失になるわけではない。例えば、ワイヤレスでＩＰに基づく伝送経路を提供する場合には、通常は、デジタルワイヤレス伝送路上のＬ２ＲＬＣ(Radio Link Control)でＡＲＱ(Automatic Repeat reQuest)を実施することにより、受信に失敗したデータを再送させるようにしている。

しかしながら、ＡＲＱを実施すると、無線状況が悪化して伝送が滞った場合には、ＡＲＱによる再送が繰り返し行なわれることになるため、後続データが滞ってゆくことになる。このため、伝送不能期間が長期になる場合には、後続データが送信機側のデータキューに溜まって、著しく遅延して伝達されたり、あるいは、送信機に無限の容量を持つメモリを実装することは不可能であることから、任意に設けられるパケット廃棄基準に従って廃棄されたりすることになる。

一方、インターネットアプリケーションは、一般にそれぞれ個別に、必要とする伝達帯域や許容伝送遅延時間といったサービス品質(ＱｏＳ: Quality of Service)要求を持っている。ＴＣＰ／ＩＰプロトコルを用いたアプリケーションでは、ＴＣＰレベルでの再送とアプリケーションレベルでの再送とが行われる場合が多い。このようなアプリケーションでは、上位層での再送は秒単位のタイマを用いて行なわれるため、下位層でのパケットロスが秒単位での遅延を引き起こし、スループットにインパクトを与えてしまう問題がある。したがって、データ通信が主たる目的である場合では、ＡＲＱによる再送は上位プロトコルによる再送回数を減らす効果があり有効に機能する。

これに対し、ＶｏＩＰアプリケーションでは、通常、上位層でのデータ再送は行なわれず、遅延によって再生機会を逸したＣＯＤＥＣペイロードは、アプリケーションにより廃棄される。したがって、ＶｏＩＰアプリケーションでは、遅延したデータの伝達確実性確保のために、後続するデータの到着遅延を発生させるよりも、許容を超えて遅延するパケットは積極的に廃棄し、後続するデータが実時間で到着する可能性を向上させる方が、主観的画質もしくは音声品質の維持には有効となる場合がある。このように、限度を超えて遅延するパケットについては再送を抑制すれば、ＶｏＩＰアプリケーションに適した伝送路を提供することが可能となる。

このように、同じＩＰに基づくアプリケーションでも、求めるＱｏＳ要求は大きく異なることになる。このような異なるＱｏＳに同時に応える伝送経路を提供する方法として、IntServe(Integrated Service)型ＱｏＳ制御がある。IntServe型ＱｏＳ制御方式は、明示的にネットワークリソースを管理することにより、特定のユーザパケットの流れ（パケットフロー）にＱｏＳを提供し、リアルタイムアプリケーションで要求されるエンドツーエンドＱｏＳを提供する手段となる。

一般に、IntServe型ＱｏＳ制御は「リソースリザベーション（resource reservation）」と呼ばれる帯域予約のメカニズムと、「アドミッション制御（admission control）」と呼ばれる動的なフロー管理メカニズムとによって実現するが、ワイヤレス伝送経路の場合には、リソースリザベーションにより無線上のチャネルを複数確保して異なるＱｏＳ制御を行うように制御し、上位プロトコルの性質に応じてパケット毎に、伝送に用いるパケットフローを選択する手法が用いられる場合がある。つまり、アドミッション制御の煩雑な処理は簡略化して、物理的なチャネルによる帯域分配を行う。このような規格にX.S0011-004-D "cdma2000 Wireless IP Network Standard: Quality of Service and Header Reduction" (3GPP2)等がある。

X.S0011-004-D におけるＱｏＳ制御手法の基本的な考え方は、一つのＰＰＰセッション上に形成されるフローを、複数のサービスインスタンスで構成することにある。サービスインスタンスとは、データ伝送を担う概念的な主体を指し、各ノード間での実装は任意に決定される。X.S0011-004-Dでは、ＰＤＳＮ−ＰＣＦ間でのサービスインスタンスをＡ１０コネクションにより実装する旨、定めている。

X.S0011-004-Dを用いて複数のサービスインスタンスを確立させ、サービスインスタンス毎に異なるＱｏＳを与えることで、きめ細かいＱｏＳ制御を実現させることができる。X.S0011-004-D でのＱｏＳ制御では、メインサービスインスタンスは、一つのＰＰＰ(Point to Point Protocol)セッションにつき一つだけ存在し、他のサービスインスタンスを通らない全てのパケットがここを流れる。

ＭＳ(Mobile Station: X.S0011-004-Dにおける移動機)は、X.S0011-004-D のＱｏＳ制御手法が規定するＲＳＶＰ (Resource reSerVation Protocol)プロトコルによりＰＤＳＮ (Packet Data Serving Node)とネゴシエーションを行い、補助サービスインスタンスを確立させる。補助サービスインスタンスには、ＲＳＶＰプロトコルによってネゴシエーションされたパケット種別選択方法・伝送方法が適用される。X.S0011-004-DにおけるＲＳＶＰは、ＲＦＣで規定されている同名のプロトコルに比べて、ノード間のＱｏＳネゴシエーションに特化したものと位置づけることができる。

パケット種別選択方法としては、特定のＲＴＰセッションを識別することが目的となる場合が多いが、ＩＰパケットに含まれる、ＩＰアドレスやＵＤＰポート番号、ＲＴＰペイロードタイプ、各種のＲＴＰセッションで固有の固定値等で識別できる。

このようにして識別した特定ＲＴＰセッションパケットは、補助サービスインスタンスに、その他のパケットは、メインインスタンスに流すよう制御を行うことにより、特定のＲＴＰセッションにのみ異なるＱｏＳ制御を行うことができる。なお、各サービスインスタンスに関してＱｏＳ制御パラメータを指定する技術に関しては、例えば下記の特許文献１および特許文献２に開示されている。

また、近年では、ワイヤレス伝送路の帯域増加によって、ワイヤレス伝送路を用いての動画像の伝送も可能となってきている。この場合に使用可能な画像コーディックとしては、例えばＨ．２６４があり、これにより高圧縮が可能であるとともに、パケットの欠落にも耐えることが可能となる。

特表２００５−５２９５５４号公報特開平９−２４７１９０号公報

ところが、画像コーディックが生成するパケットには、例えばＨ．２６４の場合、Ｉピクチャフレーム、Ｐピクチャフレーム、Ｂピクチャフレーム等あり、それぞれサイズが異なるとともに、パケットが伝送路上で欠けた場合における受信側再生画像の主観的評価も異なる。

Ｉピクチャフレームは、サイズが大きく、またパケット伝送路上で欠落した場合には、ＧＯＰ(Group Of Picture)時間分画像の再生が滞ることになる。このため、特にワイヤレス伝送路の場合には、帯域が制限されているため、パケット伝送が滞った場合には積極的にパケットを廃棄したいが、Ｉピクチャフレームに関しては、できるだけ廃棄しない方が良い。

逆に、ＢピクチャフレームやＰピクチャフレームは、サイズが小さく、伝送路上でパケットが廃棄されても、受信側における主観的な評価は、Ｉピクチャフレームが欠落した場合よりは落ちないので、ワイヤレス伝送路上でパケット伝送が滞った場合には、Ｉピクチャフレームが廃棄されるよりも、ＢピクチャフレームやＰピクチャフレームを積極的に廃棄するのが望ましい。

一方、補助サービスインスタンスにＲＯＨＣ (Robust Header Compression : RFC 3095 IETF) の圧縮を施せば、大幅な伝送効率の向上が望めるが、Ｉピクチャフレームは、サイズが大きいために、ＲＯＨＣ圧縮においてフラグメントの対象になってしまうことが多く、これによりＲＯＨＣの圧縮率が低下し、伝送効率が低下することが懸念される。これを防止するには、フラグメントが発生するようなサイズの大きなパケットは、補助サービスインスタンスに透過させなければ良いが、Ｉピクチャフレームであるか、他のフレームのピクチャフレームであるかを判断するには、パケットの内部構成に熟知する必要があるとともに、パケットの解析が必要であるため、比較的多くのＣＰＵリソースを消費することになる。

したがって、かかる事情に鑑みてなされた本発明の目的は、ＱｏＳ品質の異なる複数のセッションを用いてパケットを伝送するに際して、ＣＰＵリソースの消費を抑えて、パケットを効率よく伝送できる通信方法および通信装置を提供することにある。

上記目的を達成する請求項１に係る通信方法の発明は、伝送すべきパケットを、第１セッションでは圧縮せずに伝送し、第２セッションでは圧縮して伝送する通信方法において、
前記パケットが、前記第１セッションでの伝送対象パケットか、前記第２セッションでの伝送対象パケットかを判別するパケット種別判別ステップと、
前記パケット種別判別ステップで前記第２セッションでの伝送対象パケットと判別されたパケットのパケットサイズが所定の閾値を超えるか否かを検査するパケットサイズ検査ステップと、
を含み、前記パケット種別判別ステップで前記第２セッションでの伝送対象パケットと判別されたパケットであっても、前記パケットサイズ検査ステップでパケットサイズが前記所定の閾値を超えるパケットは、前記第１セッションで圧縮せずに伝送することを特徴とするものである。

請求項２に係る発明は、請求項１に記載の通信方法において、
前記第２セッションでのパケット圧縮はＲＯＨＣ(Robust Header Compression)により行い、
前記パケットサイズ検査ステップで用いる前記所定の閾値は、前記ＲＯＨＣにおいてパケットが分割されて圧縮されるパケットサイズに基づいて設定することを特徴とするものである。

請求項３に係る発明は、請求項１に記載の通信方法において、
前記第２セッションでのパケット圧縮はＲＯＨＣ(Robust Header Compression)により行い、
前記パケットサイズ検査ステップで用いる前記所定の閾値は、前記ＲＯＨＣに期待する圧縮率に基づいて設定することを特徴とするものである。

請求項４に係る発明は、請求項１乃至３のいずれか一項に記載の通信方法において、
前記第２セッションでの伝送対象パケットは、Ｉピクチャフレームを含むことを特徴とするものである。

さらに、上記目的を達成する請求項５に係る通信装置の発明は、伝送すべきパケットを、第１セッションでは圧縮せずに伝送し、第２セッションでは圧縮して伝送する通信装置において、
前記パケットが、前記第１セッションでの伝送対象パケットか、前記第２セッションでの伝送対象パケットかを判別するパケット種別判別手段と、
前記パケット種別判別手段で前記第２セッションでの伝送対象パケットと判別されたパケットのパケットサイズが所定の閾値を超えるか否かを検査するパケットサイズ検査手段と、
前記パケットサイズ検査ステップでパケットサイズが前記所定の閾値を超えるパケットは、前記第１セッションで圧縮せずに伝送するように制御する制御手段と、
を有することを特徴とするものである。

本発明では、単に、第１セッションでの伝送対象パケットか第２セッションでの伝送対象パケットかを判別するとともに、第２セッションでの伝送対象パケットと判別されたパケットに対しては、そのパケットサイズが所定の閾値を超えるか否かを検査することで、第２セッションでの圧縮対象パケットと判別されたパケットであっても、そのパケットサイズが所定の閾値を超えるパケットは、第１セッションで圧縮せずに伝送するようにしたので、ＣＰＵリソースの消費を抑えて、第２セッションにおける圧縮効率を向上できるとともに、第２セッションに流れるデータ量を抑えて、データの流れをスムースにでき、結果として、第１セッションおよび第２セッションに流れるデータ量を平坦化して、パケットを効率よく伝送することができる。

以下、本発明の実施の形態について、図を参照して説明する。

図１は、本発明に係る通信方法を実施する通信システムの一例の概略構成を示すものである。ここでは、無線通信システムに適用した場合を示しており、本発明に係る通信装置である無線通信端末１は、無線基地局２との間にＴＤＭＡ／ＴＤＤによるデジタルワイヤレスリンクを形成し、無線基地局２を介してＰＰＰパケットを、本発明に係る通信装置であるＰＤＳＮ３まで伝達する。無線基地局２は、無線通信端末１との間にデジタルワイヤレスリンクを形成するととともに、ＰＤＳＮ３との間でＡ１１シグナリングプロトコルを用いてＡ１０コネクションを形成して、無線通信端末１とＰＤＳＮ３との間のＰＰＰパケットを仲介する。

ＰＤＳＮ３は、ＰＰＰサーバとしての機能を有し、無線通信端末１からのＰＰＰ接続要求を受け付けるとともに、グローバルＩＰアドレスを無線通信端末１に割り振る。無線通信端末１は、ＰＤＳＮ３から割り振られたグローバルＩＰアドレスを用いて、インターネット４上に存在する任意のＩＰアドレスのインターネット機器と通信を行う。ここでは、無線通信端末１は、ＳＩＰ（Session Initiation Protocol : RFC 3261 IETF）クライアント機能を有し、ＳＩＰプロトコルを用いてＳＩＰサーバ５および対向のＴＶ電話機６と通信を行うものとする。

図２は、図１に示した本発明に係る無線通信端末１の一例の要部の概略構成を示す機能ブロック図である。この無線通信端末１は、携帯テレビ電話としての機能を有するもので、アンテナ１１、無線通信部１２、制御部１３、Ｈ．２６４ＣＯＤＥＣ（画像コーディック）１４、カメラ部１５、表示部１６、キーパッドを有する入力部１７を備えている。

制御部１３は、パケット種別判別手段を構成するＩＰプロトコルスタック管理部２１およびＲＴＰ／ＵＤＰ／ＩＰパケット管理部２２を有するとともに、無線通信部１２で受信した無線基地局２からの受信パケットを処理する機能として、受信パケットバッファ２３、ＰＰＰパケットヘッダ除去部２４、フロー判定部２５およびＲＯＨＣ展開部２６を有している。また、無線通信部１２から無線基地局２への送信パケットを処理する機能として、パケットサイズ検査部３０を有するとともに、メインサービスインスタンス（第１セッション）に対応付けられたＰＰＰパケット構築部３１および送信バッファ３２と、補助サービスインスタンス（第２セッション）に対応付けられたＲＯＨＣ圧縮部３３、ＰＰＰパケット構築部３４および送信バッファ３５とを有している。さらに、ＩＰプロトコルスタック管理部２１に接続して、ＰＰＰクライアント部３６、ＲＳＶＰクライアント部３７、ＳＩＰプロトコル管理部３８が設けられている。

この無線通信端末１では、図１において、例えば無線通信端末１からの呼接続要求がＳＩＰサーバ５の回線交換により、ＴＶ電話機６とＴＶ電話用のＲＴＰセッションが確立されると、無線通信端末１に備えられたカメラ部１５および表示部１６を用いて、ＴＶ電話機６とのＴＶ電話が可能となる。以下、音声通話に関しては、従来の構成と同様であるので、その詳細な構成および説明は省略して、画像データの通信処理について、図３に示すフローチャートを参照しながら説明する。

カメラ部１５からの画像データは、Ｈ．２６４ＣＯＤＥＣ１４でデジタルデータに変換して制御部１３に供給する。制御部１３では、Ｈ．２６４ＣＯＤＥＣ１４で画像コーディック変換されたＰＰＰｏＥパケットからＰＰＰパケットを抽出して（ステップＳ１）、ＲＯＨＣ圧縮に適合するパケットか否かを判定し（ステップＳ２）、適合する場合には、補助サービスインスタンスに対応するパケットとして、ＲＴＰ／ＵＤＰ／ＩＰパケット管理部２２を経てパケットサイズ検査部３０に供給して、パケットサイズが所定の閾値未満か否かを検査する（ステップＳ３）。

ここで、パケットサイズが閾値未満の場合には、ＰＰＰのプロトコル種別をＲＯＨＣに変更して（ステップＳ４）、補助サービスインスタンスにおいて、ＲＯＨＣ圧縮部３３で圧縮処理し（ステップＳ５）、その後、ＰＰＰパケット構築部３４を経て対応する送信バッファ３５に一旦格納して（ステップＳ６）、無線通信部１２による送信処理に移行し（ステップＳ７）、これによりＰＰＰパケット形式でアンテナ１１からデジタルワイヤレスリンクを用いて送信する。

これに対し、ステップＳ２でＲＯＨＣ圧縮に適合しないと判定されたパケットは、ＩＰプロトコルスタック管理部２１から、メインサービスインスタンスにおいてＰＰＰのプロトコル種別はＩＰのまま変更することなく（ステップＳ８）、ＰＰＰパケット構築部３１を経て対応する送信バッファ３２に一旦格納して（ステップＳ６）、無線通信部１２による送信処理に移行し（ステップＳ７）、ＰＰＰパケット形式でアンテナ１１からデジタルワイヤレスリンクを用いて送信する。

また、ステップＳ２でＲＯＨＣ圧縮に適合するパケットと判定されても、ステップＳ３でパケットサイズ検査部３０によりパケットサイズが閾値以上と判定された場合には、再度、メインサービスインスタンスに振り分けて、同様にして、ＰＰＰのプロトコル種別はＩＰのまま変更することなく（ステップＳ８）、ＰＰＰパケット構築部３１を経て対応する送信バッファ３２に一旦格納して（ステップＳ６）、無線通信部１２による送信処理に移行する（ステップＳ７）。

ここで、ステップＳ３でパケットサイズの検査に用いる閾値は、例えば、ＲＯＨＣ圧縮においてフラグメントが発生するサイズを基準にして設定することができる。すなわち、ＲＯＨＣ圧縮では、大きなパケットを圧縮する際、大き過ぎるパケットは複数のＲＯＨＣパケットに分割してそれぞれを圧縮するが、分割パケット毎に圧縮ヘッダを付与する必要があるため、圧縮効率が低下することが懸念される。このため、あまりにも大きなパケットは、ＲＯＨＣ圧縮を行う必然性がなくなるので、フラグメントが発生するサイズを基準に閾値を設定すれば、ＲＯＨＣの圧縮効率を高めることが可能となる。

また、このパケットサイズの閾値は、ＲＯＨＣ圧縮に期待する圧縮率を基準に設定することもできる。すなわち、ＲＯＨＣ圧縮では、一般に、ＲＴＰ／ＵＤＰ／ＩＰヘッダの合計４０バイトを１〜数バイトに圧縮している。これは、例えばペイロードサイズが２０バイト程度で有る場合は、パケット全体として７０％程度の圧縮率となり非常に有用である。しかしながら、ペイロードサイズが１０００バイト程度で有る場合は、４％程度の圧縮率となり、誤差の範疇となる。このため、あまりにも大きなペイロードサイズの場合は、ＲＯＨＣ圧縮を行う必要性が少ないので、ＲＯＨＣ圧縮に期待する圧縮率を基準に閾値を設定することで、効率よく圧縮することが可能となる。

あるいは、ＲＴＰペイロードタイプが既知で有る場合は、コーディックが生成するパケット種別のサイズ差に基づいて、パケットサイズ閾値を設定することもできる。例えば、Ｈ．２６４画像コーディックの場合、画像サイズにもよるが、Ｉピクチャフレームパケットは２０００バイト弱のサイズとなるのに対して、ＢピクチャフレームやＰピクチャフレームでは５００バイトを超えない場合が多い。したがって、例えば、Ａ１０、ＧＲＥ等の各ヘッダサイズから導かれる全パケットサイズが、ＭＴＵ(Maximum Transmission Unit)値を超えないようなペイロードサイズ（例えば、１４００バイト程度）を、パケットサイズの判定閾値として用いれば、Ｉピクチャフレームとその他のピクチャフレームとを切り分けることが可能となる。

このように、ＲＯＨＣ圧縮に対応するパケットとして補助サービスインスタンスに割り振られたパケットであっても、そのパケットサイズが閾値以上の比較的大きなパケットは、再度メインサービスインスタンスに振り分けて透過させることにより、補助サービスインスタンスでのＲＯＨＣの圧縮効率を向上できるとともに、補助サービスインスタンスに流れるデータ量を抑えることができ、補助サービスインスタンスにおけるデータの流れをスムースにできる。また、結果として、メインサービスインスタンスおよび補助サービスインスタンスに流れるデータ量を平坦化させることができるので、無線リソースを効果的に用いることも可能となる。

また、Ｈ．２６４画像コーディックにおいては、Ｉピクチャフレームの発生頻度がＧＯＰの時間に依存して少ない（通常ＧＯＰ当りＩピクチャフレームの数は１）のに対して、ＢピクチャフレームやＰピクチャフレームは動きを示す画像情報であることから、非常に多い特徴を持っている。このため、Ｉピクチャフレームが欠落すると、次のＧＯＰにおけるＩピクチャフレームを受信するまで、画像の再生が行えないため、ＩピクチャフレームはＢピクチャフレームやＰピクチャフレームに比べて欠落させたくない要求がある。本実施の形態によれば、このようなニーズにも応えることができ、特に、無線状況が悪化しつつある環境において、無線悪化に対する動画像の主観的画質を向上させることができる。つまり、同じ電波出力であれば、無線通信端末１からより遠くはなれている無線基地局２に対して動画像を運搬するデジタルワイヤレス伝送路を提供することができる。

一方、図２において、無線基地局２からＰＰＰパケット形式で送信されたパケットは、アンテナ１１を経て無線通信部１２で受信して制御部１３に供給する。制御部１３では、受信パケットを受信パケットバッファ２３に一旦蓄積して、ＰＰＰパケットヘッダ除去部２４を経てフロー判定部２５に供給する。フロー判定部２５は、デジタルワイヤレスチャネルに対応付けされたサービスインスタンスの種別に応じて、受信パケットをＲＯＨＣ展開部２６またはＩＰプロトコルスタック管理部２１に振り分けるもので、補助サービスインスタンスの受信パケットはＲＯＨＣ展開部２６に、メインサービスインスタンスの受信パケットはＩＰプロトコルスタック管理部２１に、それぞれ振り分ける。ＲＯＨＣ展開部２６では、供給されたＩＰパケットを展開してＲＴＰ／ＵＤＰ／ＩＰパケット管理部２２を経てＨ．２６４ＣＯＤＥＣ１４に供給し、ここで画像データに変換して表示部１６に表示する。

図４は、図１に示した無線基地局２の要部の概略構成を示す機能ブロック図である。無線基地局２は、無線通信端末１との間にワイヤレスデジタルチャネルを確立して無線通信端末とのインターフェースを実現するアンテナ４１および無線通信部４２と、ＰＤＳＮ３とのインターフェースを実現するＡ１０／ＧＲＥ通信部４３と、無線通信部４２およびＡ１０／ＧＲＥ通信部４３の間でのパケットの中継を制御する制御部４４とを有している。

また、制御部４４は、無線通信部４２で受信した無線通信端末１からの受信パケットをＡ１０／ＧＲＥ通信部４４に中継する機能として、受信パケットバッファ４５と、フロー判定部４６と、メインサービスインスタンスに対応付けられたＡ１０／ＧＲＥパケット構築部４７および送信バッファ４８と、補助サービスインスタンスに対応付けられたＡ１０／ＧＲＥパケット構築部４９および送信バッファ５０とを有しており、Ａ１０／ＧＲＥ通信部４４で受信したＰＤＳＮ３からの受信パケットを無線通信部４２に中継する機能として、フロー判定部５１と、メインサービスインスタンスに対応付けられたＰＰＰパケット構築部５２および送信バッファ５３と、補助サービスインスタンスに対応付けられたＰＰＰパケット構築部５４および送信バッファ５５とを有している。

図４において、Ａ１０／ＧＲＥ通信部４３で受信したＰＤＳＮ３からの受信パケットは、フロー判定部５１に送り、ここでＡ１０コネクションに対応付けされたサービスインスタンス種別に従って、メインサービスインスタンスの受信パケットの場合には、ＰＰＰパケット構築部５２を経て送信バッファ５３に、補助サービスインスタンスの受信パケットの場合には、ＰＰＰパケット構築部５４を経て送信バッファ５５に振り分ける。

また、無線通信部４２で受信されて受信パケットバッファ４５に格納された無線通信端末１からの受信パケットは、フロー判定部４６に送り、ここでデジタルワイヤレスチャネルに対応付けされたサービスインスタンス種別に従って、メインサービスインスタンスの受信パケットの場合には、Ａ１０／ＧＲＥパケット構築部４７を経て送信バッファ４８に、補助サービスインスタンスの受信パケットの場合には、Ａ１０／ＧＲＥパケット構築部４９を経て送信バッファ５０に振り分ける。

無線通信端末１、無線基地局２およびＰＤＳＮ３は、X.S0011-004-Dに対応しており、一つのＰＰＰセッションを複数のサービスインスタンスで構成することができる。無線基地局２とＰＤＳＮ３との間のサービスインスタンスは、ＧＲＥ(Generic Routing Encapsulation RFC 2784)プロトコル上のＡ１０コネクションで実現されており、このＡ１０コネクションを一つのＰＰＰセッションで複数確立させることで、複数のサービスインスタンスとして実現する。

無線基地局２は、無線通信端末１からのワイヤレス接続要求により、ＴＤＭＡ／ＴＤＤによるデジタルワイヤレスチャネルを確立する。このＴＤＭＡ／ＴＤＤのフレーム構成の一例を図５に示す。

図５に示すフレーム構成では、１フレームが５ｍsecとなっており、無線通信端末１の送信フレームであるアップリンクフレームおよび無線基地局２の送信フレームであるダウンリンクフレームは、それぞれスロット０〜スロット２の３スロットを有している。アップリンクの１スロットは５４５μsec、ダウンリンクの１スロットは１０９０μsecとなっている。また、アップリンクフレームとダウンリンクフレームとの間には、１０μsecのガードタイムが設けられており、ダウンリンクフレームと次のフレームのアップリンクフレームとの間には、８５μsecのガードタイムが設けられている。

このフレーム構成では、アップリンクおよびダウンリンクともに３スロットを有しているので、それぞれを異なるデジタルワイヤレスチャンネルとして用いることにより、同時に３つのサービスインスタンスを確立することができる。

無線基地局２は、無線通信端末１との間にデジタルワイヤレスチャネルを確立させた場合、デジタルワイヤレスチャネルを、Ａ１１シグナリングプロトコルを用いてＰＤＳＮ３と無線基地局２との間に形成されるＡ１０コネクションに関連づけする。無線基地局２は無線通信端末１からＴＤＭＡ／ＴＤＤ時分割多重数分のデジタルワイヤレス接続要求を受け付けて確立させる制御を行う。

無線通信端末１は、送信するべきデータがある場合には、無線基地局２との間に一つのデジタルワイヤレスチャネルを確立させる。無線基地局２は、無線通信端末１との間にデジタルワイヤレスチャネルが確立すると、Ａ１１シグナリングプロトコルを用いて、ＰＤＳＮ３との間にＡ１０コネクションを確立させ、無線通信端末１との間に確立したデジタルワイヤレスチャネルと関連付けする。このようにして無線通信端末１−無線基地局２−ＰＤＳＮ３との間に、サービスインスタンスが確立する。

無線通信端末１、無線基地局２およびＰＤＳＮ３は、無線通信端末１が未だサービスインスタンスを確立していない状態でサービスインスタンスを確立させた場合には、これをメインサービスインスタンスとして認識して、無線通信端末１はＰＤＳＮ３との間でＰＰＰ確立のための情報交換を行い、グローバルＩＰアドレスを取得する。

これに対し、既にメインサービスインスタンスを確立している状態から、追加のサービスインスタンスを確立した場合は、無線通信端末１、無線基地局２およびＰＤＳＮ３は、当該サービスインスタンスを補助サービスインスタンスであると認識して、無線通信端末１はＰＤＳＮ３との間でのＰＰＰ確立のための情報交換およびグローバルＩＰアドレスの取得は行わない。

図６は、図１に示したＰＤＳＮ３の一例の要部の概略構成を示す機能ブロック図である。ＰＤＳＮ３は、無線基地局２とのインターフェースを実現するＡ１０／ＧＲＥ通信部６１と、リンクレイヤおよびフィジカルレイヤレベルでのインターネット接続インターフェースを実現するＬＬ／ＰＬ送受信部６２と、Ａ１０／ＧＲＥ通信部６１およびＬＬ／ＰＬ送受信部６２の間でのパケットの中継を制御する制御部６３とを有している。

また、制御部６３は、Ａ１０／ＧＲＥ通信部６１で受信した無線基地局２からの受信パケットをＬＬ／ＰＬ送受信部６２に中継する機能として、受信パケットバッファ６５と、フロー判定部６６と、自分（ＰＤＳＮ）向けのパケットを受けるＩＰプロトコルスタック管理部６７と、メインサービスインスタンスに対応付けられたＡ１０／ＧＲＥパケット構築部６８と、補助サービスインスタンスに対応付けられたＡ１０／ＧＲＥパケット構築部６９およびＲＯＨＣ展開部７０と、Ａ１０／ＧＲＥパケット構築部６８やＲＯＨＣ展開部７０を経たパケットをＬＬ／ＰＬ送受信部６２に送信するための送信バッファ７１とを有している。なお、ＩＰプロトコルスタック管理部６７には、ＲＳＶＰサーバ７２およびＰＰＰサーバ７３が接続されている。

また、制御部６３は、インターネット４を介してＬＬ／ＰＬ送受信部６２で受信したＴＶ電話機６からの受信パケットを、Ａ１０／ＧＲＥ通信部６１に中継する機能として、受信パケットバッファ８１と、パケット種別判別手段を構成するパケットフィルタ部８２と、パケットサイズ検査部８３と、補助サービスインスタンスに対応付けされたＲＯＨＣ圧縮部８４、Ａ１０／ＧＲＥパケット構築部８５および送信バッファ８６と、メインサービスインスタンスに対応付けされたＡ１０／ＧＲＥパケット構築部８７および送信バッファ８８とを有している。

以下、インターネット４を介してＬＬ／ＰＬ送受信部６２で受信したＴＶ電話機６からのパケットを、無線基地局２に中継する場合の動作について、図７に示すフローチャートを参照しながら説明する。

ＬＬ／ＰＬ送受信部６２で受信したＴＶ電話機６からの受信パケットは、受信パケットバッファ８１に一時格納された後、パケットフィルタ部８２により、ＲＳＶＰサーバ７２で無線通信端末１とネゴシエーションされた基準に従って、ＲＯＨＣ圧縮に適合するパケットか否かを判定し（ステップＳ１１）、適合する場合には、補助サービスインスタンスに対応するパケットとして、パケットサイズ検査部８３に供給して、パケットサイズが閾値未満か否かを検査する（ステップＳ１２）。なお、このパケットサイズの閾値は、図２および図３において説明した無線通信端末１のパケットサイズ検査部３０におけるパケットサイズ閾値と同様に設定する。

ここで、パケットサイズが閾値未満の場合には、ＰＰＰのプロトコル種別をＲＯＨＣに変更して（ステップＳ１３）、補助サービスインスタンスにおいて、ＲＯＨＣ圧縮部８４で圧縮処理し（ステップＳ１４）、さらに、プロトコル種別としてＲＯＨＣのＰＰＰヘッダを追加する（ステップＳ１５）。その後、Ａ１０／ＧＲＥパケット構築部８５においてＧＲＥ／ＩＰヘッダをカプセル化し（ステップＳ１６）、対応する送信バッファ８６に一旦格納して（ステップＳ１７）、Ａ１０／ＧＲＥ通信部６１による送信処理に移行し（ステップＳ１８）、これにより無線基地局２に送信する。

これに対し、ステップＳ１１でＲＯＨＣ圧縮に適合しないと判定されたパケットは、メインサービスインスタンスに対応するパケットとして、プロトコル種別としてＩＰのＰＰＰヘッダを追加して（ステップＳ１９）、メインサービスインスタンスに対応付けられたＡ１０／ＧＲＥパケット構築部８７においてＧＲＥ／ＩＰヘッダをカプセル化し（ステップＳ１６）、対応する送信バッファ８８に一旦格納して（ステップＳ１７）、Ａ１０／ＧＲＥ通信部６１による送信処理に移行する（ステップＳ１８）。

また、ステップＳ１１でＲＯＨＣ圧縮に適合するパケットとして補助サービスインスタンスに振り分けられたパケットであっても、ステップＳ１２において、パケットサイズが閾値以上と判定された場合には、プロトコル種別としてＩＰのＰＰＰヘッダを追加して（ステップＳ１９）、再度メインサービスインスタンスに振り分け、同様にして、メインサービスインスタンスに対応付けられたＡ１０／ＧＲＥパケット構築部８７においてＧＲＥ／ＩＰヘッダをカプセル化し（ステップＳ１６）、対応する送信バッファ８８に一旦格納して（ステップＳ１７）、Ａ１０／ＧＲＥ通信部６１による送信処理に移行する（ステップＳ１８）。

このように、パケットフィルタ部８２によりＲＯＨＣ圧縮に対応するパケットとして補助サービスインスタンスに振り分けられたパケットであっても、そのパケットサイズが閾値以上の比較的大きなパケットは、再度メインサービスインスタンスに振り分けて透過させることにより、補助サービスインスタンスでのＲＯＨＣの圧縮効率を向上できるとともに、補助サービスインスタンスに流れるデータ量を抑えることができ、補助サービスインスタンスにおけるデータの流れをスムースにできる。

一方、無線基地局２からのパケットを、インターネット４を介してＴＶ電話機６に中継する場合には、Ａ１０／ＧＲＥ通信部６１で受信した無線基地局２からの受信パケットを、受信パケットバッファ６５に一時的に格納する。この受信パケットのうち、メインサービスインスタンスに含まれるパケットには、無線通信端末１からＰＤＳＮ３向けの、例えばＰＰＰやＲＳＶＰといったパケットが存在するので、フロー判定部６６により、自分（ＰＤＳＮ）向けのパケットはＩＰプロトコルスタック管理部６７に送信する。また、メインサービスインスタンスを通る自分宛以外のパケットは、Ａ１０／ＧＲＥパケット構築部６８でヘッダを除去した後、送信バッファ７１を経てＬＬ／ＰＬ送受信部６２に送信し、補助サービスインスタンスに含まれるパケットは、Ａ１０／ＧＲＥパケット構築部６９でヘッダを除去し、さらにＲＯＨＣ展開部７０でＲＯＨＣ展開してＩＰパケットに復元した後、送信バッファ７１を経てＬＬ／ＰＬ送受信部６２に送信する。

図８は、図１に示した無線通信システムにおけるX.S0011-004-Dを用いたデジタルワイヤレスシステムでのサービスインスタンスフローの概略図である。無線通信端末１は、電源投入後、無線基地局２のエリアに存在する場合は、メインサービスインスタンスを確立する。また、無線通信端末１は、ＴＶ電話を開始する際、ＰＤＳＮ３との間でX.S0011-004-Dで規定されるＲＳＶＰプロトコルを用いて補助サービスインスタンスにおけるパケット種別選択方法・伝送方法のネゴシエーションを行う。

ここで、パケット種別選択方法に関しては、ＳＩＰプロトコルによりネゴシエーションした対向ＴＶ電話機６のＩＰアドレスや使用するＵＤＰポート番号、ＲＴＰペイロードがＨ．２６４であることがネゴシエーションされる。また、伝送方式に関しては、当該補助サービスインスタンスにて、ＲＦＣ３０９５で規定されるＲＯＨＣを適用することがネゴシエーションされる。なお、図６において、無線通信端末１には、パケット廃棄処理部３５が設けられており、無線基地局２にも、パケット廃棄処理部５６が設けられており、ＴＶ電話機６には、Ｈ．２６４ＣＯＤＥＣ９１が設けられている。

図９は、図１において無線通信端末１がＴＶ電話機６と補助サービスインスタンスを用いて通信する際のプロトコルスタックの変遷を示すものである。無線通信端末１は、Ｈ．２６４ＣＯＤＥＣ１４が生成したデジタル画像データを、ＰＰＰパケット上のＲＴＰ／ＵＤＰ／ＩＰパケットにＲＯＨＣ圧縮を施して、補助サービスインスタンスに対応するデジタルワイヤレスチャネルを用いて無線基地局２に送信する。

無線基地局２は、無線通信端末１から補助サービスインスタンスに対応するデジタルワイヤレスチャネルに送信されたデータを受信し、その受信データを、補助サービスインスタンスに対応するＡ１０コネクションに対して送信する。ＰＤＳＮ３は、無線基地局２との間の補助サービスインスタンスに対応するＡ１０コネクションからデータを受信して、ＲＯＨＣ展開を行った後、当該データをインターネット４にルーティングする。

ＰＤＳＮ３は、無線通信端末１との間でのネゴシエーションしたパケット種別に合致するＨ．２６４ＲＴＰ／ＵＤＰ／ＩＰパケットをインターネット４から受信すると、ＲＴＰ／ＵＤＰ／ＩＰパケットにＲＯＨＣ圧縮を施した後、ＰＰＰパケットに再構築し、補助サービスインスタンスに対応するＡ１０コネクションを用いて無線基地局２にルーティングする。

無線基地局２は、補助サービスインスタンスに対応するＡ１０コネクションからのデータを補助サービスインスタンスに対応するデジタルワイヤレスチャネルを用いて無線通信端末１に対して送信する。無線通信端末１は、補助サービスインスタンスに対応するデジタルワイヤレスチャネルからデータを受信すると、ＲＯＨＣ展開を行った後、Ｈ．２６４ペイロードを取り出して、Ｈ．２６４ＣＯＤＥＣ１４に送信する。

以上、補助サービスインスタンスに流れるデータについて説明したが、メインサービスインスタンスには、補助サービスインスタンスに流れない全てのデータを流すことになる。この際、メインサービスインスタンスには、ＲＯＨＣ圧縮は施さない。

図１０は、図１において無線通信端末１がＳＩＰサーバ４とメインサービスインスタンスを用いて通信する際のプロトコルスタックの変遷を示すものである。図１０から明らかなように、メインサービスインスタンスでは、ＲＯＨＣ圧縮処理は実施されず、ＰＰＰより上位層で特別な処理は行わない。

図９に示したように、ＲＯＨＣ圧縮は、ＰＰＰ層より上位層によるＱｏＳの一環として機能し、補助サービスインスタンスのＱｏＳ制御となるが、無線基地局２と無線通信端末１との間でのデジタルワイヤレスチャネルでも、メインサービスインスタンスと補助サービスインスタンスの間でＱｏＳ制御が行われる。以下、デジタルワイヤレスチャネル上のＱｏＳについて説明する。

無線通信端末１から無線基地局２に送信されるデータや、無線基地局２から無線通信端末１に送信されるデータは、無線状況の悪化により伝達が滞る場合がある。このような場合、送信データは、送信側の送信バッファに蓄えられ、無線状況が改善し送信可能になるのを待つことになる。しかし、無線状況が改善されない場合もあり、その場合は、後続のデータにより送信バッファが溢れることになるため、より古いデータは廃棄される。

補助サービスインスタンスに流通するパケットは、Ｈ．２６４画像データをＲＴＰペイロードとするＲＴＰ／ＵＤＰ／ＩＰパケットであるので、再送により到着の信頼性を上げるより、パケット廃棄してでも到着の実時間性を確保した方が主観的画像品質は良いといえる。したがって、補助サービスインスタンスでは、送信バッファのサイズを小さくし、３秒程度以上過去のパケットが積極的に廃棄されるよう制御を行う。逆に、メインサービスインスタンスでは、用途が限定されておらず、ＳＩＰプロトコル等のＴＶ電話を維持するための重要なデータが流通することも鑑みて、比較的大きな送信バッファを用意して、パケットの廃棄ができるだけ発生しないように制御する。

このように、メインサービスインスタンスと補助サービスインスタンスとで送信バッファのサイズに差を持たせることにより、メインサービスインスタンスには、パケット欠落を回避しデータの到着信頼性を上げるＱｏＳが与えられ、補助サービスインスタンスには、データの実時間到着の確度を上げるＱｏＳが与えられることになる。

以上説明したように、本実施の形態によれば、フラグメントの対象になるパケットをメインサービスインスタンスに透過させるようにしたので、補助サービスインスタンスでのＲＯＨＣのフラグメントを回避でき、伝送効率をあげることができる。したがって、Ｈ．２６４画像データについては、Ｉピクチャフレームは、メインサービスインスタンスにてベストエフォードＱｏＳを適用して透過することができ、伝送路による欠落を抑えることができる。なお、この場合、受信側では、フレームパケットのリオーダリングが機能するので多少のパケット到着順位の逆転はそれほど問題にならない。また、メインサービスインスタンスにＩピクチャフレームが支配的に流れるようになるので、サービスインスタンス間の平坦化が行え、良好な受信画像を得ることができる。しかも、単にパケットサイズのみで、サービスインスタンスの種別を判定できるので、パケット種別等の判別といった比較的ＣＰＵリソースを消費する処理を行わなくて済む。したがって、ＰＤＳＮのように比較的多数のコネクションを制御するノードにも有効に実装することができる。

なお、本発明は、上述した無線通信に限らず、有線通信および有線通信に用いる通信装置にも有効に適用することができる。

本発明に係る通信方法を実施する無線通信システムの一例の概略構成を示す図である。図１に示した無線通信端末の一例の要部の概略構成を示す機能ブロック図である。図２に示した無線通信端末の要部の動作を説明するためのフローチャートである。図１に示した無線基地局の要部の概略構成を示す機能ブロック図である。図１に示した無線通信端末と無線基地局との間のＴＤＭＡ／ＴＤＤ通信によるフレーム構成の一例を示す図である。図１に示したＰＤＳＮの一例の要部の概略構成を示す機能ブロック図である。図６に示したＰＤＳＮの要部の動作を説明するためのフローチャートである。図１に示した無線通信システムにおけるX.S0011-004-Dを用いたデジタルワイヤレスシステムでのサービスインスタンスフローの概略図である。図１において、無線通信端末がＴＶ電話機と補助サービスインスタンスを用いて通信する際のプロトコルスタックの変遷を示す図である。図１において無線通信端末がＳＩＰサーバとメインサービスインスタンスを用いて通信する際のプロトコルスタックの変遷を示す図である。

符号の説明

１無線通信端末
２無線基地局
３ＰＤＳＮ
４インターネット
５ＳＩＰサーバ
６ＴＶ電話機
１１アンテナ
１２無線通信部
１３制御部
１４Ｈ．２６４ＣＯＤＥＣ
１５カメラ部
１６表示部
１７入力部
２１ＩＰプロトコルスタック管理部
２２ＲＴＰ／ＵＤＰ／ＩＰパケット管理部
２３受信パケットバッファ
２４ＰＰＰパケットヘッダ除去部
２５フロー判定部
２６ＲＯＨＣ展開部
３０パケットサイズ検査部
３１，３４ＰＰＰパケット構築部
３２，３５送信バッファ
３３ＲＯＨＣ圧縮部
３６ＰＰＰクライアント部
３７ＲＳＶＰクライアント部
３８ＳＩＰプロトコル管理部
６１Ａ１０／ＧＲＥ通信部
６２ＬＬ／ＰＬ送受信部
６３制御部
６５受信パケットバッファ
６６フロー判定部
６７ＩＰプロトコルスタック管理部
６８，６９Ａ１０／ＧＲＥパケット構築部
７０ＲＯＨＣ展開部
７１送信バッファ
７２ＲＳＶＰサーバ
７３ＰＰＰサーバ
８１受信パケットバッファ
８２パケットフィルタ部
８３パケットサイズ検査部
８４ＲＯＨＣ圧縮部
８５，８７Ａ１０／ＧＲＥパケット構築部
８６，８８送信バッファ

Claims

伝送すべきパケットを、第１セッションでは圧縮せずに伝送し、第２セッションでは圧縮して伝送する通信方法において、
前記パケットが、前記第１セッションでの伝送対象パケットか、前記第２セッションでの伝送対象パケットかを判別するパケット種別判別ステップと、
前記パケット種別判別ステップで前記第２セッションでの伝送対象パケットと判別されたパケットのパケットサイズが所定の閾値を超えるか否かを検査するパケットサイズ検査ステップと、
を含み、前記パケット種別判別ステップで前記第２セッションでの伝送対象パケットと判別されたパケットであっても、前記パケットサイズ検査ステップでパケットサイズが前記所定の閾値を超えるパケットは、前記第１セッションで圧縮せずに伝送することを特徴とする通信方法。
前記第２セッションでのパケット圧縮はＲＯＨＣ(Robust Header Compression)により行い、
前記パケットサイズ検査ステップで用いる前記所定の閾値は、前記ＲＯＨＣにおいてパケットが分割されて圧縮されるパケットサイズに基づいて設定することを特徴とする請求項１に記載の通信方法。
前記第２セッションでのパケット圧縮はＲＯＨＣ(Robust Header Compression)により行い、
前記パケットサイズ検査ステップで用いる前記所定の閾値は、前記ＲＯＨＣに期待する圧縮率に基づいて設定することを特徴とする請求項１に記載の通信方法。
前記第２セッションでの伝送対象パケットは、Ｉピクチャフレームを含むことを特徴とする請求項１乃至３のいずれか一項に記載の通信方法。
伝送すべきパケットを、第１セッションでは圧縮せずに伝送し、第２セッションでは圧縮して伝送する通信装置において、
前記パケットが、前記第１セッションでの伝送対象パケットか、前記第２セッションでの伝送対象パケットかを判別するパケット種別判別手段と、
前記パケット種別判別手段で前記第２セッションでの伝送対象パケットと判別されたパケットのパケットサイズが所定の閾値を超えるか否かを検査するパケットサイズ検査手段と、
前記パケットサイズ検査ステップでパケットサイズが前記所定の閾値を超えるパケットは、前記第１セッションで圧縮せずに伝送するように制御する制御手段と、
を有することを特徴とする通信装置。